Conversation

Replying to

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.

SBF

@SBF_FTX

Dec 28, 2020

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

SBF

@SBF_FTX

Dec 28, 2020

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.

SBF

@SBF_FTX

Dec 28, 2020

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.

SBF

@SBF_FTX

Dec 28, 2020

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.

SBF

@SBF_FTX

Dec 28, 2020

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.

SBF

@SBF_FTX

Dec 28, 2020

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.

SBF

@SBF_FTX

Dec 28, 2020

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.

25)

-- how did I do summarizing this? What are your thoughts, in your words?

@aeyakovenko

-- thoughts on the above?

Replying to

Interesting thoughts even if

@solana

is promising it suffer imo of two main issues (to solve ) : 1. A leader validator can stuck the BC 2. Seems you can create a solana token program(like smart contract on ETH) but cannot read the contract on solana bc like you can read on ETH ?

Replying to

(1) isn't true (2) isn't blockchain-level, it's app level. Etherscan built out a neat tool to do this; someone could do it for Solana too (and hopefully will!)

6:41 AM · Dec 28, 2020Twitter Web App

Replying to

(1) medium.com/solana-labs/ma (2) agree (3) solana still a promising tech fast and cheap, some tools(like explorer) has to be improve/develop

Replying to

1 isn't a design flaw, just a known issue/bug that is getting rolled out in the next release cycle. Beta has performed incredibly well since launch, 7b txs between stalls is a Mean Load Between Failures that is larger than anything else out there.

Show replies