A minimal sharding protocol that may be worthwhile as a development target now

What’s the purpose of this function? Why can’t submitVote be called without it?
For every shard and for every notary member there shoud be a submitVote called?

What happens when there are less than N*(2/3) notaries voting for a shard collation?

2 Likes

It seems like it would be better if there was some intermediary staging before clients tried decoding what the canonical chain is. Otherwise it might be difficult to read. Maybe have a canonical headers section of finalized blocks that receive 2N/3 votes? That way clients don’t need to deal with computing what the canonical chain is.

What’s the purpose of this function? Why can’t submitVote be called without it?

addHeader is there to propose headers. submitVote is there to submit a vote approving a header. The two are different.

What happens when there are less than N*(2/3) notaries voting for a shard collation?

Then no collation gets accepted in that period.

We could move the computation into the SMC itself, and have it emit finalized headers as logs, which would simplify the work of light clients at the cost of requiring more gas.

I think this should be extended to

If a client sees that in some shard, for some period, a chunk has been included, >= 2N/3 notaries voted for it and all other accepted headers have a lower period number, it accepts it as part of the canonical chain.

Otherwise it’s possible that a very old chunk that’s been missing just a single vote gets accepted, leading to a huge reorg at the execution layer (or whatever interprets the chunks).

Also, this prevents two chunks being accepted for the same period.

(Unless this is really just supposed to be a placeholder SMC in which case it doesn’t really matter of course.)

What is the incentive for doing do?

Ah, sorry I failed to mention that there’s a time limit for notaries to notarize collations; notarizations for one period have to be submitted before the start of the next period.

1 Like

What is the rationale for allowing anyone to call addHeader ? Someone could just spam a shard by continuously calling the function and submitting invalid collation headers, thus not allowing any new collations to be added to the canonical shard chain

What is the rationale for allowing anyone to call addHeader ?

It will almost certainly be replaced, we just don’t know by what yet. Hence why I said “minimal sharding protocol”. It’s there as a stub.

Can this sampling return different N notaries on different branches of a shard?

What does “included” mean here? addHeader() has been called on the chunk?

Now I guess the sampling happens not on the managed shard but somewhere else, so the sampling is not affected by forks and branches of shards.

But it sometimes sounds like voting happens in the shard, not somewhere else

in some shard, … >= 2N/3 notaries voted for it

so, it might be the case, notaries are chosen in the shard, and voting is recorded in the shard. Different votes are counted on different branches, pointing to different canonical chains.

I’m guessing

  • it’s never mentioned but there is the main chain
  • SMC is deployed on the main chain
  • addHeader and sutmitVote are interfaces of SMC (shard management contract?)

Yes, yes, and yes. :smiley:

1 Like

What’s a “branch of a shard”? There’s no concept of in-shard forking here anymore.

What does “included” mean here? addHeader() has been called on the chunk?

Yes.

Now I guess the sampling happens not on the managed shard but somewhere else, so the sampling is not affected by forks and branches of shards.

Yeah, all votes are put on the main chain.

1 Like

What are the first steps for implementing this…

  1. sharing collations on a p2p network: should it be done on eth capability of devp2p with a new chainID, on Swam, on IPFS, or on something else? Is anybody working on any of these?

  2. writing a main chain contract.

I think both are being done in parallel; Prysmatic is researching p2p network models that are optimized for multi-shard validation.

2 Likes

Hi @yhirai, Raul from Prysmatic Labs here. We’re focused right now on the invariants of phase 1 sharding, which are p2p and local shard state storage. We’re working with go-libp2p and exploring two models: bootstrap nodes for each shard vs. a toroidal network topology for peer discovery as explored in: Torus-shaped sharding network.

2 Likes

An acknowledgement of other implementations would be nice! https://github.com/ethereum/wiki/wiki/Sharding-introduction-and-implementations#implementations.

1 Like