What is left to do, and what are the tradeoffs?
The immediate next step is to finish the implementation and rollout of PeerDAS. From there, it’s a progressive grind to keep increasing the blob count on PeerDAS while carefully watching the network and improving the software to ensure safety. At the same time, we want more academic work on formalizing PeerDAS and other versions of DAS and its interactions with issues such as fork choice rule safety.
Further into the future, we need much more work figuring out the ideal version of 2D DAS and proving its safety properties. We also want to eventually migrate away from KZG to a quantum-resistant, trusted-setup-free alternative. Currently, we do not know of candidates that are friendly to distributed block building.
Even the expensive “brute force” technique of using recursive STARKs to generate proofs of validity for reconstructing rows and columns does not suffice, because while technically a STARK is O(log(n) * log(log(n)) hashes in size (with STIR), in practice a STARK is almost as big as a whole blob.
The realistic paths I see for the long term are:
- Implement ideal 2D DAS
- Stick with 1D DAS, sacrificing sampling bandwidth efficiency and accepting a lower data cap for the sake of simplicity and robustness
- (Hard pivot) abandon DA, and fully embrace Plasma as a primary layer 2 architecture we are focusing on
We can view these along a tradeoff spectrum:
Note that this choice exists even if we decide to scale execution on L1 directly. This is because if L1 is to process lots of TPS, L1 blocks will become very big, and clients will want an efficient way to verify that they are correct, so we would have to use the same technology that powers rollups (ZK-EVM and DAS) at L1.
How does it interact with other parts of the roadmap?
The need for 2D DAS is somewhat lessened, or at least delayed, if data compression (see below) is implemented, and it’s lessened even further if Plasma is widely used. DAS also poses a challenge to distributed block building protocols and mechanisms: while DAS is theoretically friendly to distributed reconstruction, this needs to be combined in practice with inclusion list proposals and their surrounding fork choice mechanics.
Data compression
What problem are we solving?
Each transaction in a rollup takes a significant amount of data space onchain: an ERC20 transfer takes about 180 bytes. Even with ideal data availability sampling, this puts a cap on scalability of layer 2 protocols. With 16 MB per slot, we get:
16000000 / 12 / 180 = 7407 TPS
What if in addition to tackling the numerator, we can also tackle the denominator, and make each transaction in a rollup take fewer bytes onchain?
What is it and how does it work?
The best explanation in my opinion is this diagram from two years ago:
The simplest gains are just zero-byte compression: replacing each long sequence of zero bytes with two bytes representing how many zero bytes there are. To go further, we take advantage of the specific properties of transactions:
- Signature aggregation – we switch from ECDSA signatures to BLS signatures, which have the property that many signatures can be combined together into a single signature that attests for the validity of all of the original signatures. This is not considered for L1 because the computational costs of verification, even with aggregation, are higher, but in a data-scarce environment like L2s, they arguably make sense. The aggregation feature of ERC-4337 presents one path for implementing this.
- Replacing addresses with pointers – if an address was used before, we can replace the 20-byte address with a 4-byte pointer to a location in history. This is needed to achieve the biggest gains, though it takes effort to implement, because it requires (at least a portion of) the blockchain’s history to effectively become part of the state.
- Custom serialization for transaction values – most transaction values have very few digits, eg. 0.25 ETH is represented as 250,000,000,000,000,000 wei. Gas max-basefees and priority fees work similarly. We can thus represent most currency values very compactly with a custom decimal floating point format, or even a dictionary of especially common values.
What are some links to existing research?
- Exploration from sequence.xyz: https://sequence.xyz/blog/compressing-calldata
- Calldata-optimized contracts for L2s, from ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
- An alternative strategy – validity-proof-based rollups (aka ZK rollups) post state diffs instead of transactions: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
- BLS wallet – an implementation of BLS aggregation through ERC-4337: https://github.com/getwax/bls-wallet
What is left to do, and what are the tradeoffs?
The main thing left to do is actually to implement the above schemes. The main tradeoffs are:
- Switching to BLS signatures takes significant effort, and reduces compatibility with trusted hardware chips that can increase security. A ZK-SNARK wrapper around other signature schemes could be used to replace this.
- Dynamic compression (eg. replacing addresses with pointers) complicates client code.
- Posting state diffs to chain instead of transactions reduces auditability, and makes a lot of software (eg. block explorers) not work.
How does it interact with other parts of the roadmap?
Adoption of ERC-4337, and eventually the enshrinement of parts of it in L2 EVMs, can greatly hasten the deployment of aggregation techniques. Enshrinement of parts of ERC-4337 on L1 can hasten its deployment on L2s.
Generalized Plasma
What problem are we solving?
Even with 16 MB blobs and data compression, 58,000 TPS is not necessarily enough to fully take over consumer payments, decentralized social or other high-bandwidth sectors, and this becomes especially true if we start taking privacy into account, which could drop scalability by 3-8x. For high-volume, low-value applications, one option today is a validium, which keeps data off-chain and has an interesting security model where the operator cannot steal users’ funds, but they can disappear and temporarily or permanently freeze all users’ funds. But we can do better.
What is it and how does it work?
Plasma is a scaling solution that involves an operator publishing blocks offchain, and putting the Merkle roots of those blocks onchain (as opposed to rollups, where the full block is put onchain). For each block, the operator sends to each user a Merkle branch proving what happened, or did not happen, to that user’s assets. Users can withdraw their assets by providing a Merkle branch. Importantly, this branch does not have to be rooted in the latest state – for this reason, even if data availability fails, the user can still recover their assets by withdrawing the latest state they have that is available. If a user submits an invalid branch (eg. exiting an asset that they already sent to someone else, or the operator themselves creating an asset out of thin air), an onchain challenge mechanism can adjudicate who the asset rightfully belongs to.
A diagram of a Plasma Cash chain. Transactions spending coin i are put into the i'th position in the tree. In this example, assuming all previous trees are valid, we know that Eve currently owns coin 1, David owns coin 4 and George owns coin 6.
Early versions of Plasma were only able to handle the payments use case, and were not able to effectively generalize further. If we require each root to be verified with a SNARK, however, Plasma becomes much more powerful. Each challenge game can be simplified significantly, because we take away most possible paths for the operator to cheat. New paths also open up to allow Plasma techniques to be extended to a much more general class of assets. Finally, in the case where the operator does not cheat, users can withdraw their funds instantly, without needing to wait for a one-week challenge period.
Alright Reserved: This post was originally written on Vitalik.eth.limo
All the research, posts and mentions belong to the original post and VItalik.eth.limo website.
This post is only intended to showcase plans for the Ethereum blockchain by the founder.
Special thanks to Justin Drake, Francesco, Hsiao-wei Wang, @antonttc and Georgios Konstantopoulos
This is the second part of the post, for the first part click here
