Vitalik Buterin
@vitalik.eth
Simplifying the L1 https://vitalik.eth.limo/general/2025/05/03/simplel1.html
20 replies
103 recasts
464 reactions
Juan Blanco
@juanblanco
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 reply
0 recast
0 reaction
Vitalik Buterin
@vitalik.eth
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 reply
0 recast
2 reactions
Vitalik Buterin
@vitalik.eth
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 replies
0 recast
2 reactions
Juan Blanco
@juanblanco
If the problem is the 32 bytes, an improvement will be to encode / decode packed. But for this it will be required to understand the structure of the message before hand, similar to what MUD does with the table schema. This means each contract will require an understanding of the schema, which it could be easily created for verified contracts for backwards compatibility if needed. But it might also allow us to start thinking of data storage patterns / standards like the one used in MUD for general data (not just games)
0 reply
0 recast
0 reaction
Juan Blanco
@juanblanco
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.
1 reply
0 recast
0 reaction
