Conversation

SBF
@SBF_FTX
Replying to
@SBF_FTX
19) b) Another ideas was to split the blockchain into "domains"; this could be e.g. addresses invoking calls, or tx number mod 20. Make it so that each validator is assigned to a domain and can only produce blocks for that one.
3
43
SBF
@SBF_FTX
20) This means that, no matter how large a validator is, it can only ever produce blocks for e.g. 5% of the ecosystem. That forces further decentralization of block production, and means that you need to get a more diverse set of validators on board with a timeline.
1
48
SBF
@SBF_FTX
21) There were some other ideas whose details I've forgotten -- "big blocks/small blocks", "some small validator that has some power"--
@VitalikButerin
do you remember those? -- The other set of ideas were about storing state securely and efficiently.
2
39
SBF
@SBF_FTX
22) The goal here would be two-fold: make sure history can't be rewritten; and that it's easy for a low-powered validator to find out the state of the blockchain. One idea here is just writing the state to the ETH blockchain periodically. Then any ETH node could verify Solana.
2
53
SBF
@SBF_FTX
23) Another idea was to write ZK-proofs of a Merkle tree of the blockchain, or something like that. A third thing that Vitalik brought up: it would be great if each block header contained the full state of the blockchain, so at least verifying that was easy for a laptop.
4
45
SBF
@SBF_FTX
24) I'm probably missing a lot of his thoughts here, and probably misrepresented some too--sorry! But I found the conversation super interesting. There are sometimes tradeoffs between security and speed, but at least we can try to find a pareto maxima.
3
61