Vitalik Buterin Weighs In On SNARKs For Layer 2

September 24, 2018 11:35 PM

Last week, Ethereum core developer Afri Schoedon said that Ethereum was at max capacity and that Dapp developers should build on other chains. Vitalik Buterin disagreed, arguing that most Dapps are not gas-optimized, and that competition within the space would “push out” suboptimal Dapps. He also emphasized the importance and promise of layer 2 solutions and posted a potential SNARK-utilizing scaling solution on Ethresear.ch to support his argument. 

His proposal attempts to solve some of the major challenges associated with existing second layer solutions.

Many of the layer 2 scaling solutions on Ethereum come with an assumption of liveness, and this is the first problem Buterin’s SNARK-utilizing strategy attempts to solve. 

“Come again?” you ask.

Liveness, in a distributed system (such as a blockchain), refers to the certainty of eventual consensus. In other words, if all nodes in a blockchain network will eventually come to consensus, you can say that you have guaranteed liveness. Take, for example, Ethereum. What if two or more blocks are created at approximately the same time? There must be a way of deciding which block is the “true” block. (There is.) If there were not, then liveness would not be guaranteed. There is a reasonable guarantee of liveness with the established proof-of-work consensus mechanism.

However, second layer solutions (like state channels and plasma) have different consensus mechanisms, and the existing structures for guaranteed liveness don’t hold up because they rely on transacting parties to be online. The problem is rooted in the consensus mechanisms, which vary, but are often proof-of-authority (PoA), or some variation of practical Byzantine fault-tolerant (PBFT) algorithms, which require that transacting parties watch for bad behavior and/or “sign off” on transactions at varying points. These strategies for achieving consensus mean that liveness is not guaranteed.

On Saturday, September 22, on ethresear.ch, Buterin posted a potential on-chain scaling solution to enable 500 transactions per second. The concept is to utilize zk-SNARKs to achieve certainty of block validity. A zk-SNARK is a succinct zero knowledge proof. The “zero knowledge” here means that it is a way for a person to prove the truthfulness of a value without having to reveal the value, or how they know it. The “succinct” part just means that the proof is very short – only a few hundred bytes max.

This isn’t the first time someone has suggested zk-SNARKS for layer 2. Just last week ETHNews covered a project in the works to make a SNARK-verified plasma chain, and that was not the first either. But Vitalik’s solution is not a simple regurgitation of existing projects. Under his framework, there must be two types of users: transacting parties and relayers. Transacting parties are just what they sound like – they are individuals or entities who are transacting with each other. A relayer is a person who takes all those transactions, records them, and then sends them to the main chain to be mined. In this situation, the relayer takes those transactions, combines them, and creates a zk-SNARK. The relayer then submits that SNARK to the main chain to be mined there. Through the use of zk-SNARKS, it is impossible for the relayer to lie. This means that the transacting parties don’t have to be constantly online watching for bad behavior.

This basic system is not entirely new; the zk-SNARK plasma chain referenced above also has transacting parties and a party who compiles those transactions, makes a SNARK, and then relays it to the main chain. But the specifics are different.

For one, it apparently eliminates one major challenge with SNARKs. The thing is, with SNARKS it is impossible to lie about the truthfulness of a claim, but it is possible to leave out necessary data. This is referred to as the “data availability problem.” For example, with the SNARK-verified plasma chain, the operator (which, in Buterin’s framework would be most analogous to the relayer) submits SNARK-verified blocks to the main chain. However, those blocks might be missing information necessary for EDCCs (aka smart contracts) to interact with the block. Buterin says that this mechanism avoids that concern “because all the data needed to update the Merkle tree goes on chain.”

In short, Buterin’s proposal is better than typical plasma solutions because it doesn’t require folks to be online, and it’s better than the existing SNARK-plasma solutions because it doesn’t face data availability issues.

It’s not perfect, though. It never is. One major challenge will be reducing proving time. As a number of commenters have pointed out, it takes a long time to generate a proof. Buterin agreed with these concerns but expressed optimism that this issue would be sorted out soon enough, and that in the meantime it was still a workable mechanism:

“At this point it’s widely known that optimizing SNARK/STARK provers is super-important so I’m sure there will be more and more software engineering work going into it over time.”

“Agree that proof generation time needs to be fast enough and this could be the limiting factor! Though if this becomes a problem then the chain as a whole could still reach ~500 tx/sec with multiple transaction batching gadgets of this type (eg. for different tokens) running in parallel.”

Alison is an editor and occasional writer for ETHNews. She has a master’s in English from the University of Wyoming. She lives in Reno with her pooch and a cat she half likes. Her favorite things to do include binge listening to podcasts, getting her chuckles via dog memes, and spending as much time outside as possible.

Like what you read? Follow us on X @Bitnewsbot to receive the latest Ethereum, zk-SNARKs or other Ethereum ecosystem news.