Conversation

SBF
@SBF_FTX
Replying to
@SBF_FTX
14) How about Solana? Well, the cost of running a node is dedicating a ~$500 machine to it. Which isn't that much, for a large player in crypto! But it is for a random user. And so in practice only people fairly interested in the ecosystem are likely to run nodes.
8
77
SBF
@SBF_FTX
15) This doesn't necessarily effect literal consensus that much--those players likely had most of the stakeweight anyway, because anyone with large stakeweight could easily get a machine to validate. But it does mean that a random user might not be able to call bullshit.
1
45
SBF
@SBF_FTX
16) You lose the sense of each person, practically speaking, validating their own transactions. ---------- Anyway, enough preamble. What could make a high throughput chain relatively more secure? There were basically two types of suggestions Vitalik had.
1
49
SBF
@SBF_FTX
17) The first was variants on "find some sub-unit and split validation on it". This is what sharding does. Some examples that might work on Solana: a) One huge shard plus lots of small shards. Basically, the 'main' shard would be what Solana is now.
2
45
SBF
@SBF_FTX
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
3
52
SBF
@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
vitalik.eth
@VitalikButerin
Replying to
@SBF_FTX
and
@SBF_Alameda
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
32
vitalik.eth
@VitalikButerin
Replying to
@VitalikButerin
and
@SBF_Alameda
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
33
Show replies