Why doesn’t Near just replicate Ethereum Serenity design?
Alexander Skidanov
3932

I feel like I mis-explained a few things in our conversation, sorry!

> Unlike the previous proposals, no committee is sampled per block

This is not correct. For the sake of completeness, here is how the algorithm works, with some details simplified of exposition.

There are 64 blocks in a cycle. At the beginning of each cycle, validators are randomly shuffled and split into 64 groups, and each of these groups is split into 16 subgroups. Group n is responsible for signing during block n of that cycle, and each of the subgroups is simultaneously responsible for signing a crosslink associated with a particular shard. So these are “committees sampled per block”. However, the FFG beacon chain consensus doesn’t really depend on these committees that strongly, it mostly just cares about what happens all together in this cycle. So effectively, the attestations are used for LMD fork choice *in the short term* (8 seconds) and Casper FFG finalization *in the longer term* (~10–20 minutes)

> the attestations do not provide theoretical guarantees

Not quite true: they provide a ~50% strong theoretical guarantee conditional on the network synchrony assumption holding.

> Besides those reasons, Near aims to enable network operators to run nodes on mobile phones.

This is one of my protocol design goals too!

> with Ethereum’s approach one would need to be constantly online, participating in heavy computations (validating thousands of BLS signatures every few seconds)

It’s worth noting that the network can be structured so that almost all nodes do NOT have to do this. Only a small number of nodes (maybe ~10 for redundancy) need to be actually involved in aggregating each committee.

Also, there are tricks that we can use to make the aggregation itself even more hierarchical, reducing the load to any node to ~10 pairings, if needed.

> On the other hand, Ethereum shard chains depend crucially on participants having synchronized clocks.

There are ways to mitigate this. For example, nodes could maintain a clock which is a median of their local machine’s clock with 25% weight and the implied clocks of other nodes based on the messages they send with 75% weight. That said, the stability properties of different mechanisms for this do need to be studied more.