zk maxi helping bring research into the mainstream.
zk maxi helping bring research into the mainstream.
Subscribe to pseudotheos
Subscribe to pseudotheos
Share Dialog
Share Dialog
pseudotheoszkSNARKs vs zkSTARKs: a primer
Trying out a longer form article this time to allow a deeper dive into some areas of blockchain research. There are a lot of articles on zero knowledge proofs, and a lot of research papers on SNARKs or STARKs, but very little bridging the intermediate gap. If you haven’t read my introduction to zero knowledge proofs Twitter thread, I strongly recommend it before going further, as a lot of this article builds on top of it. pseudo 🇺🇦 @pseudotheos all these zk terms... what do they mean? what'...
pseudotheosDistinguishing zkEVMs
The Ethereum Virtual Machine (EVM) is the virtual machine that manages state and executes smart contracts on the Ethereum blockchain. zkEVMs, which aim to prove EVM execution through zero-knowledge (ZK) circuitry, have seen significant growth and expansion as an industry over the past year. Many different projects and community efforts have emerged in this space, each taking its own unique approach to the challenges and opportunities presented by the intersection of these two technologies. On...
pseudotheosPBS: Neutralizing the Dark Forest
Domothy and I co-authored this article. PBS is still an active area of research, but this comprehensive post aims to aggregate and summarize where research is so far- and where it’s headed. In the existing architecture, block proposers (previously miners) select transactions in the mempool to build a block. On Ethereum, these consist of validators running a consensus and execution client in tandem. Theoretically, a block builder would select transactions paying the highest fee- but this is no...
pseudotheoszkSNARKs vs zkSTARKs: a primer
Trying out a longer form article this time to allow a deeper dive into some areas of blockchain research. There are a lot of articles on zero knowledge proofs, and a lot of research papers on SNARKs or STARKs, but very little bridging the intermediate gap. If you haven’t read my introduction to zero knowledge proofs Twitter thread, I strongly recommend it before going further, as a lot of this article builds on top of it. pseudo 🇺🇦 @pseudotheos all these zk terms... what do they mean? what'...
pseudotheosDistinguishing zkEVMs
The Ethereum Virtual Machine (EVM) is the virtual machine that manages state and executes smart contracts on the Ethereum blockchain. zkEVMs, which aim to prove EVM execution through zero-knowledge (ZK) circuitry, have seen significant growth and expansion as an industry over the past year. Many different projects and community efforts have emerged in this space, each taking its own unique approach to the challenges and opportunities presented by the intersection of these two technologies. On...
pseudotheosPBS: Neutralizing the Dark Forest
Domothy and I co-authored this article. PBS is still an active area of research, but this comprehensive post aims to aggregate and summarize where research is so far- and where it’s headed. In the existing architecture, block proposers (previously miners) select transactions in the mempool to build a block. On Ethereum, these consist of validators running a consensus and execution client in tandem. Theoretically, a block builder would select transactions paying the highest fee- but this is no...
>100 subscribers
>100 subscribers
Scaling the execution layer via rollups, validiums, and volitions is only one half of a two-part solution. In order for a truly scalable and decentralized blockchain to exist, the data computed and stored on-chain must reside somewhere without high storage or computing requirements. Ten years from now, when significantly more people, institutions, and daily users interact with the blockchain in some way, more efficient state and data storage is required. Separating the monolith requires existing monolithic nodes to fragment into specialized task-specific nodes.
Right now, an Ethereum full node’s size is growing at an average rate of 78% per year.
There are currently ~185 million unique Ethereum addresses. To onboard the world, the data must be stored in such a way where node overhead is minimal. The lower the compute requirements, the more nodes can be run, reducing centralization risk.
In the current monolithic blockchain spec, data and state reside alongside the execution and consensus layers inside the L1. Recent market events show how simply increasing throughput by increasing node workload is unsustainable at the best of times, and ineffective at the worst of times.
The solution to reach the Endgame and solve the scalability trilemma lies in separating the monolith.
The previous article on zkSNARKs vs zkSNARKs focused on the execution layer and the efforts being made to separate it from the monolith by using zero knowledge proofs to bring the execution off-chain. This article covers the other side: data availability and state.
As explained in a recent Twitter thread, Ethereum is a state machine.
Ethereum’s state holds all of the account balances, smart contracts, and storage. Without any adjustments, Ethereum’s state would grow forever, constantly increasing the hardware requirements to run a node until it becomes impossible. The fix is statelessness, but in order to understand it fully, we need to understand what an Ethereum block actually is under the hood.
Each part of an Ethereum block is a trie. Tries (pronounced like trees) are a super efficient way to store data. Ethereum’s state trie is stored alongside the transaction trie and execution trie, which each full node is required to handle by itself currently. Ethereum has two types of data: ephemeral data (account balances) and permanent data (transactions). A diagram of a block’s structure is below.
Technically, the state isn’t gone, but in Stateless Ethereum, it’s been moved from the node to another participant in the network. Instead of the node handling the full state, it holds a block witness- a packet of data that is needed to validate the transactions held in that block. By giving the node only the data it needs and nothing more, it reduces the overhead requirements massively. The below diagram visualizes the block lifecycle in the Stateless Ethereum network.
Much like zero knowledge proofs allow executions off-chain, data availability proofs allow for data to be stored in the same way. This was broken down at a high level in a twitter thread.
The data availability layer, much like the execution layer, requires a mathematical proof which shows that even if the data is off-chain, it is not manipulated, censored, or modified in any way. The magic behind data availability proofs lies within erasure codes. Erasure codes are very common in computer science. Some non-blockchain implementations of erasure coding include satellite communications, CD-ROMs, and QR codes. The first blockchain-specific paper regarding data availability and erasure coding was co-authored by Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin in 2018. In short, it allows for a complete data set to be built from a partial data set in addition to the erasure code.
This means that even if a block producer manipulated a fraction of the data, the producer would be required to withhold over half of the entire set in order to censor due to the erasure code being able to reassemble the missing data. This allows provably secure off-chain data storage, drastically reducing a node’s storage requirements.
According to past research and current work being done by developers, solving the scalability trilemma is possible. Like everything, it’s easier said than done, but within a few years, the technology will become robust, uncensorable, and cheap to use.
Thanks for reading this article! This is the summation of a lot of research to help bridge the knowledge gap. Follow me on Twitter to get notified about future posts and let me know what you think. My content will remain 100% free, forever, and is licensed under CC BY-SA unless otherwise specified.
Diving into Ethereum's world state Ethereum comprises of many constituent parts. This post seeks to de-construct Ethereum to provide you with an understanding of its data storage layer. We will ...
Get the latest ideas, announcements, partnerships, and Web3 news emerging from the Polygon ecosystem.
Data Availability & Scaling Blockchains Introduction With the high transaction fees on Ethereum, scalability has been top-of-mind for many cryptocurrency projects. A popular solution is to separate ...
Scaling the execution layer via rollups, validiums, and volitions is only one half of a two-part solution. In order for a truly scalable and decentralized blockchain to exist, the data computed and stored on-chain must reside somewhere without high storage or computing requirements. Ten years from now, when significantly more people, institutions, and daily users interact with the blockchain in some way, more efficient state and data storage is required. Separating the monolith requires existing monolithic nodes to fragment into specialized task-specific nodes.
Right now, an Ethereum full node’s size is growing at an average rate of 78% per year.
There are currently ~185 million unique Ethereum addresses. To onboard the world, the data must be stored in such a way where node overhead is minimal. The lower the compute requirements, the more nodes can be run, reducing centralization risk.
In the current monolithic blockchain spec, data and state reside alongside the execution and consensus layers inside the L1. Recent market events show how simply increasing throughput by increasing node workload is unsustainable at the best of times, and ineffective at the worst of times.
The solution to reach the Endgame and solve the scalability trilemma lies in separating the monolith.
The previous article on zkSNARKs vs zkSNARKs focused on the execution layer and the efforts being made to separate it from the monolith by using zero knowledge proofs to bring the execution off-chain. This article covers the other side: data availability and state.
As explained in a recent Twitter thread, Ethereum is a state machine.
Ethereum’s state holds all of the account balances, smart contracts, and storage. Without any adjustments, Ethereum’s state would grow forever, constantly increasing the hardware requirements to run a node until it becomes impossible. The fix is statelessness, but in order to understand it fully, we need to understand what an Ethereum block actually is under the hood.
Each part of an Ethereum block is a trie. Tries (pronounced like trees) are a super efficient way to store data. Ethereum’s state trie is stored alongside the transaction trie and execution trie, which each full node is required to handle by itself currently. Ethereum has two types of data: ephemeral data (account balances) and permanent data (transactions). A diagram of a block’s structure is below.
Technically, the state isn’t gone, but in Stateless Ethereum, it’s been moved from the node to another participant in the network. Instead of the node handling the full state, it holds a block witness- a packet of data that is needed to validate the transactions held in that block. By giving the node only the data it needs and nothing more, it reduces the overhead requirements massively. The below diagram visualizes the block lifecycle in the Stateless Ethereum network.
Much like zero knowledge proofs allow executions off-chain, data availability proofs allow for data to be stored in the same way. This was broken down at a high level in a twitter thread.
The data availability layer, much like the execution layer, requires a mathematical proof which shows that even if the data is off-chain, it is not manipulated, censored, or modified in any way. The magic behind data availability proofs lies within erasure codes. Erasure codes are very common in computer science. Some non-blockchain implementations of erasure coding include satellite communications, CD-ROMs, and QR codes. The first blockchain-specific paper regarding data availability and erasure coding was co-authored by Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin in 2018. In short, it allows for a complete data set to be built from a partial data set in addition to the erasure code.
This means that even if a block producer manipulated a fraction of the data, the producer would be required to withhold over half of the entire set in order to censor due to the erasure code being able to reassemble the missing data. This allows provably secure off-chain data storage, drastically reducing a node’s storage requirements.
According to past research and current work being done by developers, solving the scalability trilemma is possible. Like everything, it’s easier said than done, but within a few years, the technology will become robust, uncensorable, and cheap to use.
Thanks for reading this article! This is the summation of a lot of research to help bridge the knowledge gap. Follow me on Twitter to get notified about future posts and let me know what you think. My content will remain 100% free, forever, and is licensed under CC BY-SA unless otherwise specified.
Diving into Ethereum's world state Ethereum comprises of many constituent parts. This post seeks to de-construct Ethereum to provide you with an understanding of its data storage layer. We will ...
Get the latest ideas, announcements, partnerships, and Web3 news emerging from the Polygon ecosystem.
Data Availability & Scaling Blockchains Introduction With the high transaction fees on Ethereum, scalability has been top-of-mind for many cryptocurrency projects. A popular solution is to separate ...
breaking it down
breaking it down
No activity yet