Vitalik Buterin: “More Pessimistic” About Scaling Through Second Layers

Vitalik Buterin, the ethereum co-founder and its most prominent developer, has publicly stated he is becoming a bit pessimistic about scaling through second layer networks like the Lightning Network (LN) or the still in development eth version called Plasma.

“I have been getting more and more pessimistic about off-chain-data L2s over time. Vlad Zamfir is right; they’re just hard to build, require too much application-layer reasoning about incentives, and hard to generalize,” he said.

Buterin is an adviser to Plasma, or at least was during the project’s ICO, OmiseGo, in 2017.

He also appeared to be working closely with its lead developer, Joseph Poon. Two years on, however, Buterin says:

“Data withholding is the single hardest risk to design incentives around!…

Hard to generalize because they require specific reasoning about beneficiaries (who has the right to exit a uniswap contract on a plasma chain? What about the root ENS contract?)

Also Plasma exit games get harder when you can make changes to an account without the recipient’s consent, as you can’t assume honest users know their own latest states.

Channels cannot support “objects of public interest” (eg. Uniswap) at all.”

He specified “off-chain-data L2s” to exclude from his pessimism things like Zk-Snarks based scaling solutions.

In a nutshell, these solutions keep account of movements of funds deposited in a smart contract through snarks by creating mini-sidechains of sorts with the end result being a compression of transactions by kind of bundling them in these sidechain blocks which translates to some data/bytes being stored on chain, but far less than for a plain transaction.

Responding to a question on how putting data on-chain helps, Vitalik Buterin said:

“On-chain you can just do an interactive verification game to figure out who pushed a bad state. IV games favor defenders so strongly you don’t need to care about who has the incentive to defend so much.”

This application of snarks or starks to scalability has come to light only this year with it potentially a solution especially in the back-end as conceptually it could perhaps develop to the point you just copy paste some lines of code and so incorporate it into your dapp.

This method also avoids many pitfalls with LN, Plasma, or the like. Chief among them, there is no need for collateral and there is no, somewhat “manual,” account keeping whereby a file on your own local computer records a transaction.

This “manual” or local record keeping can lead to problems with the solution being trusted intermediaries called watchtowers.

As unappetizing as that may be, there could also be a fundamental technical flaw in that Lightning Network fees may have to cost as much or even more than on-chain fees.

There have been no published models on LN economics, nor even any basic maths as far as we are aware, but recently it was revealed someone is locking $5 million worth of bitcoin to earn $20 in fees on LN per month.

That’s obviously not something that can work, with LN fees so having to be 10 cent to just cover on-chain fees while bitcoin’s on-chain fees themselves are in the cents. That’s while ignoring the need for profits from locking this $5 million, or the cost to create a secure system for this rich LN node/operation, and so on.

In LN they do speak about what can be called channels squared, or factories as they call them, with the aim being to avoid on-chain transactions, and thus fees, but last time we glanced at that, we were told it’s all theoretical.

So there may be some sort of realization that this actually might not quite work as a solution to scalability beyond very small niche cases.

But compression through snarks might work. Sidechains could too especially in a system of smart contracts like in ethereum. There they call it sharding, although with differences but conceptually sort of the same thing.

Now whether either of those two can work in a decentralized and trustless manner, is for the future to say, but we may well actually find out that Nakamoto was ultimately right.

Copyrights Trustnodes.com