# Portal Integration: Geth & Shisui Nov 14, 2024 at 11am, by @jasoncarver Notes about the discussion ## Basic context Shisui is building a Portal client as a component of larger product goals. They expect to continue development for a while Geth wants to use Portal to access chain history imminently, and probably beacon data to be able to sync without a CL client. Beacon has less time pressure. ## Integration Details ### Structure Geth is roughly a mono-repo, with a couple notable exceptions like the SSZ library. Geth wants to build on the shisui team's work, in a way that is practical to integrate into geth, but with the following constraints: - geth doesn't want in-progress code in the code base, like Portal state network - geth PR review and merge timelines are slow, don't want to slow down shisui progress by merging everything into the mono-repo Geth wants to depend on shisui's Portal implementation, which depends on geth components, like discv5 and other core types like headers, blocks, etc. It could make sense to pull discv5 out into a separate library, to break the cyclic dependency chain. It's also a possibility to extract the core types, but the intuition is that this would be a much larger project. There is a separate, but mostly similar implementation of beacon chain light client. Maybe that can be merged into one. ### DB Geth prefers Shisui to use Pebble instead of sqlite. Some discussion of generalizing the interfaces, to make that switch easier. ## Going forward Shisui engineers mostly in central China, with one in California. Geth mostly Europe-based. The time zone difference is painful, so they will mostly do asynchronous communication, with a few live meetings.