We compartmentalize Ethereum into two sections. One, we describe as the native state. Ethereum addresses and balances. Two, we describe as the EVM. An ERC20 token exists within the EVM, we can describe it as EVM addresses and balances.
EVM execution is confirmed by every node. Every node executes the smart contract to arrive at the same answer. This is a form of verifiable computing.
We have computation C() to execute. We give C() to untrusted parties. We assume standard 2/3 fault tolerance, so we send C() to 3 parties. 2 parties return with the same results for C(). We assume the result for C is correct. This is verifiable computing.
There are a few forms of verifiable computing, our two focus areas are;
- Intel SGX (Also known as trusted hardware)
- zk-SNARKs (zero-knowledge succinct non-interactive argument of knowledge)
zk-SNARKs prove with zero knowledge that something is true, and it is provable by providing zero knowledge.
EVM execution occurs on chain because we use multi party consensus to verify computing. We provide proof with zero knowledge that execution occurred in a trusted manner. Execution no longer needs to occur on-chain.
A zero knowledge proof EVM, can ensure verified computing.
With the above we have covered execution. Next, storage. We have secured execution, but we still have outputs, for example ERC20 addresses and balances. We have a zk-proof, that proves that a state transition occurred.
We knew state S1, and we can prove that transition T occurred, we can prove S2. We need S1 and T to prove S2, this is where the tradition merkle comes in. Given merkle M and transition proof T, we can prove that participant P has balance B.
To have verified data, all the chain needs to save is merkle M and proof C.