Another excellent post from @VitalikButerin on trust assumptions in blockchains
By far the most important conclusion IMO is that some degrees of trust are valid - and should be encouraged - as we explore trade offs
@VitalikButerin can you explain why Optimistic rollups have a N/2 of big-N trust for safety evaluation in this article? https://t.co/QiRkfmY0FK
as any single honest observer is enough to open a challenge, it seems that 1 of small-N is the trust model for safety.
RT @VitalikButerin: A post explaining different trust models, particularly how "1 of N", "N/2 of N" and "1 of 1" trust are very different, with an eye to blockchain applications and scaling protocols:
A post explaining different trust models, particularly how "1 of N", "N/2 of N" and "1 of 1" trust are very different, with an eye to blockchain applications and scaling protocols:
He used really strange nomenclature. Normally you call the betrayers t and the total number n.
(Without signatures) you already can show with the Byzantine Generals Problem that you only need
N >= 3t + 1
Once you add signatures, like general1 cannot say to general3 that general2 said attack (while he said to escape) because the signature would show the manipulation, you can reduce the number a bit more. If you have an asynchronous system (one is ahead one is behind and it shall be acceptable) it's much more complex (That's why you built the airplane and the nuclear intercontinental rocket synchronous).
Bitcoin definitely doesn't have 50% (like N/2 like vitalik calls it) trustless stability, that's simple to proof mathematically, maybe really close as the number of players is quite high.
I am confident you break Byzantine tolerance of bitcoin if you add enough delay. The 50% trustless state is maybe achievable with exactly 0 network delay.
I can tell you because the ARINC SaveBus design has huge importance to limit the delay to 1us. And you see how ethereum fucked up completely in mandala because they don't understand the importance of a voting regarding the current time base. Like every variable input needs to be voted on, just like you do it in the design of safety critical systems (remember the Boeing fiasco when you don't vote for one variable...)
Bitcoin has the same problem, introduce a delay of information up to one block and the security drastically goes down, nowhere near 50%. I think I have read it would be only around 33% for bitcoin but can further be reduced, "just" (not so simple but doable) increase communication delay. I am pretty sure you can bring it down to a single malicious actor taking down bitcoin if you can control network delay. It the classic trouble of every critical systems.
In the grand scheme of things, compared to the other trust models I talk about, 2N/3 of N is close enough to N/2 of N that IMO it's okay to lump them in together to basically one category.
\> Bitcoin definitely doesn't have 50% (like N/2 like vitalik calls it) trustless stability, that's simple to proof mathematically, maybe really close as the number of players is quite high.
Though with current internet delays it's \~49% fault tolerance. And Ethereum with its faster block times is something like \~45%. That said, I agree that the risk of higher networking delays is a problem; that is a big part of the reason why I support things like Casper FFG that have latency-independent safety guarantees.
It does have some positive aspects because it is an effective store of energy in a sense.
Imagine a solar cell farm. They build capacity but during production hours they have to store the energy, and they do.
But they can’t build up enough solar cells to work on cloudy days because then on sunny days they produce to much energy that they can’t store it without incurring a massive storage cost overhead on most days.
But, if on sunny days they can take that excess energy and mine bitcoin then they can build out over capacity because it isn’t wasted money. And now on cloudy days they can stop mining and they have enough capacity to power their community and they would not otherwise be able to do that.
In other words, mining bitcoin is a good way to use excessive energy making it economical to build out over capacity.
Channels (incl state channels, lightning network): 1 of 1 trust for liveness (your counterparty can temporarily freeze your funds, though the harms of this can be mitigated if you split coins between multiple counterparties), N/2 of big-N trust for safety (a blockchain 51% attack can steal your coins)
this is wrong, LN has a known problem with safety: HTLC coins (btc in flight) can be stolen in a relatively small parallel attack on many channels due to congestion (so a liveness failure I guess). This attack is unpatchable and makes LN a complete failure. The root of the problem is that in LN on bitcoin it's not possible to distinguish a HTLC theft attempt from one party just being offline, which breaks the fundamental fraud proof security model that requires penalties (without the penalty assumption you have to either assume no layer 1 congestion ever happens, or allow funds to become permanently locked, both aren't practical).
In Vitalik's trust tiers this places LN into N-of-N: you have to trust that no node you have a channel with attempts an attack.
Not sure why it didn't yet happen - maybe LN is simply too small? There's definitely a minimal number of simultaneously attacked channels (and minimal balance) when this starts making financial sense. It's also possible nobody bothered so far.