Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharding network topology #12

Open
Mikerah opened this issue Jan 22, 2019 · 6 comments
Open

Sharding network topology #12

Mikerah opened this issue Jan 22, 2019 · 6 comments

Comments

@Mikerah
Copy link

Mikerah commented Jan 22, 2019

Last year, @jannikluhn posted a proposal for a Torus-shaped sharding network. This was before the deprecation of EIP1011. Since then, we have, for the time being, decided on using gossipsub for the pubsub routing algorithm. The underlying network topology for gossipsub is a strongly connected mesh (see this issue.). However, there has been little talk about what the sharding network topology will be or if it has been decided.

I want to bring this up because I think it'll be important for several analyses that will need to be done in the future with regards to how we can make gossipsub more efficient, validator privacy, peer discovery, etc.

@mhchia
Copy link
Collaborator

mhchia commented Jan 22, 2019

It's truly a critical topic to be discussed! From my understanding, gossipsub is based on the existing network topology, and its behavior does not affect the underlying topology. Therefore, I think we also need to take DHT(or any other peer discovery mechanism) into consideration. It affects the topology when performing discovery(e.g. bootstrapping when joining, or resolving a peer ID if some discovery scheme is used when only the peer ID is available).

Besides, how signatures are aggregated is probably a factor affecting the topology.

@Mikerah
Copy link
Author

Mikerah commented Jan 22, 2019

Would it make sense to start compiling a list of viable network topologies and then start simulations of each? Since the testnet is approaching soon, we definitely need to figure out these details sooner, rather than later.

@jannikluhn
Copy link
Collaborator

Unfortunately, we can't simply pick a network topology that we like. It emerges indirectly from the discovery mechanism, the peer selection rules, node lifetimes, potentially latencies and bandwidths, etc. So all we can do is design our protocols in such a way that should lead to a good topology.

In Eth1.0, peers are essentially selected randomly, with the exception of nodes that are "full" already and don't accept new peers. Intuitively, I'd expect a fully homogeneous topology to be perfect for gossipsub, so this seems already close to optimal.

@Mikerah
Copy link
Author

Mikerah commented Jan 23, 2019

@jannikluhn, So are you saying that the sharding topology should be a mesh as in gossipsub, as the fully homogeneous topology (I don't think a star topology would work. It has too many problems for our needs) ? This is very different from the Torus shaped topology that you suggested last year.

@fjl
Copy link

fjl commented Feb 15, 2019

I think random connectivity per shard is sufficient for pubsub and syncing. It has the massive advantage of being unstructured and is a lot harder to attack than any structured topology.

@fjl
Copy link

fjl commented Feb 15, 2019

To clarify: when I say 'random connectivity, I mean we should establish a system like eth 1.0 has, but per-shard. Any node interested in a certain shard should select random peers from the set of all nodes participating in that shard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants