18) Smaller shards would limit themselves to ~1k TPS, and be designed so that a laptop could validate them.
That way people really concerned with validating their own transactions could use smaller shards, and apps the require large usage or composability could use the large one
Conversation
21) There were some other ideas whose details I've forgotten -- "big blocks/small blocks", "some small validator that has some power"-- do you remember those?
--
The other set of ideas were about storing state securely and efficiently.
2
2
39
The idea here is basically an anti-censorship tactic. Have two classes of block producers. The lower-performance class ("collectors") would just make batches of transactions; you could have many in parallel. The higher-perf class ("sequencers") would combine batches into blocks.
3
2
32
Only the sequencer would actually "process" txs and compute the state. The key rule is: a sequencer *must* include *all* batchers that the collectors produced. The goal is that even if sequencers are highly centralized, as long as collectors are not, sequencers cannot censor.
2
2
33
Replying to
Ah that makes sense!
How would sequencers deal with conflicting tx's from different batchers?
2
16
Just process them all in sequence and if some transaction's dependencies were invalidated by a previous transaction then that transaction is a no-op?
2
2
16
I'm assuming that whatever mechanism selects who can propose each of the batches would also assign each proposer an index? Alternatively you could order by hash(sequencer_reveal, hash_of_batch), where `sequencer_reveal` is a randao-style hash that the sequencer can't control.
3
1
28
So what you guys then are saying is ... ETH is hentai
1
3
Show more replies