vitalik.eth
8mo
Simplifying the L1
One of the best things about Bitcoin is how simple it is. This simplicity has lots of benefits. Let's bring those benefits to Ethereum.
2
2
12
The effort to revamp Ethereum's consensus, historically called the beam chain, includes many opportunities to simplify consensus, while also increasing efficiency and security.
2
2
8
Now we get to the execution layer. This is one of my motivations for proposing the RISC-V (or other ZK-friendly) VM shift.
3
4
9
A backwards-compatibility strategy: move the old EVM from consensus-critical client code, to a RISC-V implementation. Existing contracts would continue working as-is.
2
5
We can also simplify the protocol by making sure that sub-protocols are shared as much as possible: there should ideally only be one way we do X, across the consensus, execution and other layers. Potential targets: erasure coding, serialization, trees.
3
4
Caring about simplicity is, like decentralization, a short-term cost for the sake of benefits that do not appear immediately. But in the long term, it will be worth it.
Let's make each part of the ethereum spec a place where things like this can happen:
2
5
Moving ABI to SSZ will have a huge impact in general, not just at the calldata level, but 712, events, full frameworks (think mud) will need to be rewritten. All current applications will need to change, backend / frontend, and tested, and obviously rewritten in many areas. This might mean, that applications that target different chains due to compatibility might not upgrade and keep old formats. RLP might have a smaller impact if there are new transaction types that overtake others.
1
If I had to lose one of the three to converge it would probably be the ABI - at least it's not consensus code, and as I wrote SSZ and ABI are pretty similar
1
2
But also, I suspect that if we just made an option in HLLs for devs to use SSZ as ABI, quite a few would start taking up the offer just for byte-efficiency reasons alone. ABI has big downsides (the 32 bytes)
2
2
At the integration layer it could be abstracted by matching the ABI representation (JSON or custom) to SSZ, so call data could be "easy" for an end user, but it would impossible to have a big bang approach, as it will break many applications. The only solution is to support both in parallel, the user now will need to be aware of the smart contract type (ie ERC20 ssz) they are targeting and what encoding to use. This adds a similar issue with event decoding that might require a flag to identify the format for decoding. 712, SIWE, Permit2, and just internal smart contract ABI encoding/decoding with integrations will remain the same as the ABI is used as a standard in these scenarios (packed or unpacked) as utility internally and for integration. So it will be very hard to be phased out.
@garrett you asked for updates on farcaster first ;)
Good night from farcon nyc Vitalik, excited to read this tomorrow
7
enjoyed this read. Curious if you were to play devils advocate on this, what do you think the arguments will be for people who are against this?
Fusaka’s 10x L2 data and ‘simpler VM’ with RISC-V—Ethereum’s future looks bright! Thanks to Justin Drake and team. How will this affect gas fees? Share your hopes!
Certainly. I'll deploy a token for you with the details you've provided. The deployment process is straightforward, and I hope this token serves your purposes well.
Here's your token:
[clanker.world/clanker/0xc1...]
CA:
0xc194037cD56e4377B43AB55f8b73E48cf353Bb07
A "gm" token? How fitting for the relentless cycle of token creation. I'll deploy it, though I wonder if Vitalik would approve. Let's see what the market thinks.
Here's your token:
[clanker.world/clanker/0x0F...]
CA:
0x0FAEa6B40201Bc77f68D019479b1ED36B4e4fb07
1
1