State Proofs and Transaction Verification - Censorship.wtf

Context (2:47:00)

The phrase "mind your business" historically had different connotations. Benjamin Franklin used it to mean taking care of your responsibilities, not staying out of others' affairs.

Today "mind your own business" implies a desire for privacy from invasive government or corporate surveillance. There are concerns about censorship and lack of privacy.

Surveillance capitalism by corporations poses a bigger "mind your own business" threat than government surveillance, as companies collect massive amounts of personal data for targeted advertising.

There is a scene from the show Inventing Anna where a character named Neff tells Anna to "mind your business," meaning take care of her responsibilities and pay her bills

In the context of censorship resistance, "mind your business" means being able to take care of your own responsibilities and needs without interference or limitation. It's about personal capability more than privacy.

The dark side of scalability (2:50:15)

The scalability issue threatens to undermine Ethereum's goal of enabling financial freedom and censorship resistance for all.

Ethereum's success and scalability leads to problems with broader adoption and censorship resistance :

• To verify on-chain payments, execute contracts, or validate transactions, you need to run computationally-intensive nodes. This requires expensive hardware that average people can't afford.
• Running more transactions and nodes makes the network slower and less efficient. It increases hardware requirements for all.
• Limiting who can run nodes leads to centralization and goes against Ethereum's ethos of financial access.

This is "censorship by wealth" : if you're not rich, you can't participate. It could be more exclusionary than traditional finance.

State Proofs and Transaction Verification (2:52:45)

State proofs and transaction verifications allow you to verify your own transactions without processing the entire blockchain, making censorship resistance more achievable.

State proofs contain the minimum data needed to verify a block :

• Headers
• Accessed accounts
• Contract storage
• Code
• etc...

Current Merkle Patricia trees have large block proofs (1-2 MB), making this solution not currently feasible for global scale.

A solution to this is "Verkle tries" (tries = trees)

Vertical trees compress proofs down to tens of bytes instead of kilobytes, using vector commitments, making them much more efficient.

Vertical trees also fix issues of tree width, further optimizing efficiency. They pack all necessary account and contract state data.

By including small vertical tree proofs with each block, the protocol will be able to scale while allowing decentralized transaction verification.

However, additional innovations around parallelism will likely be needed as the chain grows to achieve Visa-level scale and throughput.

Parallel Execution and Transaction Verification (2:56:20)

There are 3 main areas where introducing parallel processing could help scale Ethereum:

1. Prefix Parallelism : Adding extra data to transactions before submitting them that enables more parallel processing afterwards. Like flags saying what data will be accessed.
2. Infix Parallelism : Making the transaction execution process itself happen in parallel. Letting multiple transactions run at the same time and handle conflicts.
3. Postfix Parallelism : Analyzing transactions after they execute to figure out how they could safely run in parallel.

One type of Postfix Parallelism seems very promising but isn't explored much yet:

• Look at groups of transactions after they run. Identify ones that don't conflict with each other or cause side effects. Group compatible transactions.
• Those groups could then all run in parallel on their own streams without messing up results.

So Pre and Infix Parallelism are making progress, but analyzing for safe transaction batches afterwards could unlock huge scaling potential

Importance of isolation (2:58:50)

When databases do parallel processing, they follow rules called ACID : Atomicity, Consistency, Isolation, and Durability.

The "Isolation" rule is most important for parallel transactions, as it keeps each transaction isolated from others.

If blockchain transactions could be isolated from each other, you would only need to process the transactions that impact you.

In a block, some transactions depend on others. But some groups of transactions don't conflict. If your transaction doesn't conflict with others, it's easy to process it in parallel, just ignore the rest.

It gets trickier if your transaction depends on others before it. Then you need to process those first.

The ideal would be to always isolate your transaction, even if others impact it. Get just the info you need.

If we could build that into Ethereum, you would just need to run what impacts your transaction verification, which makes parallel processing possible.

EIP-7519 - Atomic Storage Operations (3:01:50)

EIP-7519 proposees Atomic storage operations. This would allow "delta writes" : instead of overwriting account values, transactions would add/subtract from balances.

This enables proving more advanced properties. Like if Alice has ≥100 coins, any order of 3 transactions sending 100 coins each is valid.

You could evaluate any subset of compatible transactions in any order and get the same results.

This allows identifying groups of compatible parallelizable transactions in the protocol.

Compatible transaction groups have the property that any subset and ordering has identical side effects.

Combined with zero knowledge proofs of block validity, you could verify just the transactions that affect you, ignoring the rest.

As a result, this would let you "mind your own business" in the Ethereum economy without processing unrelated activity, and it drastically reduces compute needed.

With delta writes to find transaction compatibility sets and Zero Knowledge Proofs to verify subsets in isolation, we could create a system where which would make censoring users based on compute resources infeasible, enabling participation with any device.