In favor of forkfulness

[JustinDrake]

@vbuterin

I think that depends entirely on what you mean by “main chain”. If you’re referring to overhead incurred by clients, sure, you’re correct.

By “main chain overhead” I mean the overhead measured in messages (per second) that hit the main shard’s blockchain. Measuring the overhead this way is meaningful because onchain messages are the truly costly ones (one has to pay gas for messaging). The “main chain” is its own entity and all participants (clients, validators, voters, etc.) incur the same overhead of 1 message per 75 seconds to verify final votes.

@vbuterin

The proposer would still have to verify 1024 votes within 75 seconds in order to verify any collation they are including in their own blocks

I’ll assume that “proposer” means anyone who wants to verify final votes. (There is no notion of “proposer” or “collation” in the abstract voting model.) To verify a final vote, a proposer has to download a single message. With BLS aggregation that message is 20 bytes and takes marginal time to verify.

@vbuterin

and if they want to have, say, a windback of 10 blocks, then that goes up to 10240 votes within 75 seconds (reminder that this is all per-shard).

BLS aggregation shines here because aggregation can be done across different messages. So a windback of 10 blocks is still a single 20 bytes message verified in marginal time, assuming the existence of “aggregators” that aggregate the final votes posted to the main chain. Without aggregators, a proposer has to download 200 bytes and verify 10 signatures for a windback of 10 blocks.

And the same trick can be done across shards. That is, assuming aggregators, all finals votes across all shards can be simultaneously verified in marginal time with a single 20 bytes message.

@vbuterin

So you’ve found a loophole that can reduce sustained overhead, but not burst overhead.

Assuming aggregators, the burst overhead is constant and marginal, regardless of the burst!

BLS signatures at the protocol-level

I think @vbuterin’s most likely rebuttal ( !) is that BLS signatures are not quantum secure hence we can’t have them at the protocol level. I have a post with an approach to safely deploying fancy crypto. In our case, the super-efficient BLS scheme can be backed by a less efficient signing scheme without aggregation, or be backed by the forkful voting scheme with higher finality latency.