This has some really questionable assumptions.
Like the part about permanence.
"An important property of a blockchain that users really value is permanence. A digital asset stored on a server will stop existing in 10 years when the company goes bankrupt or loses interest in maintaining that ecosystem. An NFT on Ethereum, on the other hand, is forever."
This is wrong 2 times.
First, there is no general requirement of permanent storage. Its not important at all. It solely depend on the use case. Thats why it is very much inefficient to use a DLT with that property to move value (btc/eth etc.). I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state (aka the balances). Sure the Tx history has use cases and people who need them should store them but making that a technical requirement is only going to degrade performance and drive up Tx cost.
BTW cash does not have a recorded Tx history who thought "p2p cash" should?
Its only because of the way BTC works (chain of all Tx) that this "believe" became common. Its technically not needed at all. There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters. The "validation" is placebo it does nothing. And by running the exact same software as anyone else your validation would simply do the same error if there would be one.
Second, the "forever" is a blatant lie. There is no way to know. Its will exist for however long at least someone is willing to store it. Exactly the same is true if storing is optional. But without the downside of crippling the performance and impose cost on the people running the DLT.
The cost for storage should be paid by the user of the storage.
If I can impose cost on all participants of a decentral system for all eternity with a one time payment then the system is deeply flawed. The possibility for abuse can be limited by simply making it expensive at any given time. But this obviously reduces the usefulness of the whole system especially for value transfer. The idea of an internet of value is to make value move like data, dirt cheap and decentral so no one takes a cut.
When I talk to people in the world about what about blockchains they find exciting, the aspect of permanence really is one of the things that people find attractive. I agree it's use-case dependent, but the problem is that once you go down the use-case-dependence rabbit hole, developers and users have to really think "am I creating something permanent or not"? And once you have to think even a little bit, you lose 50%+ of the magic. Having properties that you just get by default that you don't even have to think to obtain is quite important.
The good news though is that you don't need permanent storage of history to be supported by the base protocol itself. Consensus nodes don't need to know about history to verify the current chain. There are plenty of other mechanisms for storing historical data: bittorrent, centralized archives, Filecoin-style networks, etc etc. You just need the blockchain's throughput to be not _too_ high, so that it's actually possible for these protocols to store what comes out.
Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses", and that's much better than "data could drop at any time if a few people just forget"!
In anthropology I believe it is accepted truth that when you ask people questions regarding motivations or rationalisations for their behavior, particularly group behavior, answers given do not necessarily equate to observed reality, ie. "Oh yeah I'm fully in to decentralisation and taking down the establishment." -> "I want a lambo."
> Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses"
Let's be honest here and acknowledge that we're talking about "permanent unless your particular fork of one particular blockchain collapses". There's a vast chasm between that and all of civilization.
I disagree. If bitcoin or ethereum gets completely killed today, I'm confident you'll still be able to download the chain in four decades (assuming civilisation still exists) out of pure history and data hoarding.
Right. The "value" / perceived value won't be permanent (and may be very subjective and disputed from the start), but in terms of long-term data integrity and availability, blockchains can be useful. An NFT ownership transfer that occurred in 2020 on some blockchain may not be considered too valuable in a hypothetical 2040 world where almost no one is using that (or perhaps any) blockchain anymore, but you can likely at least retrieve that record and be pretty sure the data is accurate and wasn't tampered with.
So a (at-one-point reasonably popular) blockchain or protocol forking or falling out of use won't actually result in that data being lost to time. You'd probably need a major worldwide catastrophe for there to be a significant risk of that.
> but you can likely at least retrieve that record and be pretty sure the data is accurate and wasn't tampered with.
You will have no way to tell if this data came from the legitimate Ethereum blockchain that was in use in 2021, a forked chain, or even a completely fake one which has zero blocks in common with the real one.
The authenticity guarantee in blockchains doesn't come from cryptographic schemes, it comes from the network agreeing on some shared truth. If the network is no more, you have no way to tell the truth.
If the network is totally gone, it's indeed more tricky. But if it still exists, and if there's no indication that the main network and chain was ever disrupted between then and now, you can be pretty confident the data is accurate if you join the network.
If no one uses it anymore or if it's so little-used that it's schismed into tons of other chains over the years, I think you can still probably obtain the original data you're looking for, but it'll take more effort to verify its authenticity.
Especially if the data you're looking for occurred at a time when the network was healthy and intact (like 2020), all you need to do in 2040 is find a block number and corresponding root hash that existed in 2020. I think these'll likely be possible to find even if the network's dead, and you can compare them against several different sources to increase confidence that they're not fake. Then as you scour the internet and download different published blockchain copies, you can truncate it back to that block number and compare the hash.
It's possible your search will be futile and you'll be unable to find a trustworthy record of block numbers and root hashes or that you'll be unable to find a verified 2020 blockchain, but I think your odds will be pretty good if the internet hasn't collapsed. Either way, as Vitalik pointed out, the odds are way higher you'll be able to find that compared to some data you entered into some SaaS in 2020.
> you can be pretty confident the data is accurate if you join the network.
And how do you know the network you're joining is actually the original ethereum network and a completely different blockchain?
Like every peer to peer network in existence, an Ethereum node needs to connect to a reliable first node (a “tracker” in the bittorrent protocol, idk what's the name in the ethereum world). If they are down, you're on your own to join the network, and you have little guarantee that the network you're joining is working on the original ethereum blockchain.
In fact, after the ethereum foundation is gone, what guarantee do you have that you are running an actual ethereum node and not something running a modified protocol?
>And how do you know the network you're joining is actually the original ethereum network and a completely different blockchain?
The "if you join the network" is contingent on the network still being active and widely used; presumably with the Ethereum Foundation or some successor also still being active. I may not've made that fully clear in the first paragraph.
If that were the case, you could ask the same question right now. And the answer is that they publish an official client you can download and should be able to trust. This would be the case in 2040 if the network is still active and the foundation still exists.
If the foundation is gone and the network is mostly dead, then it'd indeed be much harder or perhaps impossible. The second part of my answer covers that scenario:
>If no one uses it anymore or if it's so little-used that it's schismed into tons of other chains over the years, I think you can still probably obtain the original data you're looking for, but it'll take more effort to verify its authenticity.
>Especially if the data you're looking for occurred at a time when the network was healthy and intact (like 2020), all you need to do in 2040 is find a block number and corresponding root hash that existed in 2020. I think these'll likely be possible to find even if the network's dead, and you can compare them against several different sources to increase confidence that they're not fake. Then as you scour the internet and download different published blockchain copies, you can truncate it back to that block number and compare the hash.
>It's possible your search will be futile and you'll be unable to find a trustworthy record of block numbers and root hashes or that you'll be unable to find a verified 2020 blockchain, but I think your odds will be pretty good if the internet hasn't collapsed. Either way, as Vitalik pointed out, the odds are way higher you'll be able to find that compared to some data you entered into some SaaS in 2020.
I agree with this, a durable record of every transaction ever performed is in fact an anti-feature for a digital ledger.
Mimblewimble[0] is one interesting solution to this. Unfortunately, the requirement in current implementations (such as Grin) that both wallets be online to complete a transaction, eliminates some valuable types of transaction, such as sending coin to a cold wallet.
I do think for a 'world computer' like Ethereum, being able to ignore a substantial amount of old state is going to be critical for long-term use.
I also think that "blatant lie" is unnecessarily harsh. A blockchain is aspirationally forever, and it is a massively replicated data structure: it's certainly durable, and I would expect it to last a long time relative to, say, a random torrent.
This is my major concern with the direction Ethereum is going, which I could caricature as "scale up massively and keep everything forever": it becomes so expensive to keep copies of all data, that only large institutional players will bother, and not many of them. This makes blockchain integrity a "take my word for it" kind of thing, and the whole system is only as durable as the increasingly-enormous data centers which hold all that information.
>the whole system is only as durable as the increasingly-enormous data centers which hold all that information.
That is exactly what Ethereum's direction has been for years now. It is centralized on Amazon AWS via Infura's nodes (which they charge access to, mind you). It's not a world computer. It's EC2 with additional complexity (and fees).
Nothing consensus critical on Ethereum runs on Infura nodes. Plenty of people run full nodes on hosted services like Infura, but that applies equally to the original cryptocurrency and current number 2 coin.
The delegation of node operation to third party services is done more for convenience/up-time guarantees than any node operation cost considerations, and Ethereum would be fine if these third party services were all coopted or forced to shut down, because again, Ethereum's consensus protocol has zero dependencies on them.
The blockhcain may be "forever" but the history is definitely is not. Its a lie because the most likely outcome are that Ethereum dies because the history cripples it to an unusable system (its a lie then) or the the history dependency is removed so it can keep working (its a lie then as well because which part of the history is preserved is up to whoever does want to preserve it and no longer "guaranteed by the system")
BTW history-sharding[1] isn't that complicated. If a DLT is build from the ground up with payment in mind and thus history is completely optional then you dont have to do any tech magic. But ofc this is not the case for Ethereum as it was not made for payment.
State expiry/rent is being worked on in Ethereum, and would totally solve the problem of indefinite state size growth. This article, courtesy again of the hard-working Buterin, details the designs under consideration:
If these schemes with inherent MLM-Ponzi structures crash, how long will mining be lucrative enough? Perhaps then mining will distribute to the holders to try to maintain some value or use?
But you conclude with your worry that there are real costs, and zero pitch decks or white papers I've seen include arguably the most important competitive factor: cost of "how people do it now" vs. cost doing it "this new way;" and in-person, real life networks of trust networks has been how we've become as successful as we have as a society - and so works quite well - and doesn't inherently lineup with "trustless" propaganda of these popular blockchains; if blockchain is a valuable tool, say for legal institutions, they could create their own and run it themselves under agreement.
Blockchains don't have a concept of a "current undisputed state". If you managed to create a longer (and valid) Bitcoin chain on your own than the longest one there is at this very moment, and publish it, all other clients will start using it as the new longest chain. And if two equally long chains are published at about the same time, and clients get split, things will probably get resolved in the next block. So, most of the time, the current longest chain won't probably change, and if you discount, say, the 6 newest blocks (using bitcoin as an example), then it will definitely not change. So, the "undisputed state" and the "current state" are actually separate concepts in a PoW blockchain.
Regarding storage, you argument that transactions shouldn't matter, since the important thing is the state. But then we're back to the fundamental problem. Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.
Don't assume blockchains are bitcoin or BTC like systems.
I talk about the "current and undisputed or better indisputable (final) state". Bitcoin does not have this. Hence it can not function without history. This is a property of BTC not one of blockchains in general.
Plenty other systems have a current state and a final state and there is no "better state" that can comer around and replace it. Final really means final. Its often called a closed ledger.
Other systems have checkpoints and what not to reach a similar goal.
BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state.
>Why should we trust a state created from thin air that has no proof of how it was created? That's just a distributed database, which has is uses, but it's not a distributed blockchain.
You have no choice. Either you agree with the current final state or you dont use the blockchain. Your choice is to use it or not. You choice is not to validate or not or validate and fix something if its wrong.
The act of validating doesn't do anything. No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all.
Also its not created out of thin air. It was validated by the code. If there is a mistake it is there because of the code people used back when it happened. If you were there running your node it would have made the same mistake. whats the point to find it now? (beside the fact that it was already found and fixed) It doesn't change the state the state is final. Bugs happen.
If you assume cheating however then well you should assume someone would have screamed back when it happens so you would already know that someone cheated somehow. Whats the point of validating it? you already know you dont want to use that chain. Zero reason to detect the cheating yourself.
We know pretty well from all incidents where blockchains had to be "fixed" there is no way someone would find an unknown incident by the placebo validation act.
No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all.
I'm a bit of a blockchain noob, but isn't this the opposite of how blockchain works?
What I mean is, yes, you can design it the way you're saying, but doesn't that open you up to double-spend attacks and enforced centralization? You need a central ledger at that point, since your "final state" has to come from somewhere.
If you have a final state double-spend attacks are actually impossible. They are based on the fact that someone can insert a transaction then "overwrite" it by providing a longer chain where the transaction didn't happen or went somewhere else.
This is only ever possible if there is no final state.
Also not sure why you would need centralization for what. Simplified a final state is when a majority declares it as final not a central entity does that.
A double spend would have to include both transaction into the final sate which obviously would violate the systems rules. You cant move the same balance again when you already move it away. So that just wont happen because the code does not allow it. The second Tx is simply invalid just like if you would try to move more coins than you have.
If you want to read more about final consensus see https://xrpl.org/consensus-network.html
There are ofc other project with similar concepts this is just the oldest.
Why do you need a blockchain at all then? This is what I really don't get. If you have your "majority" available at all times they just agree on account balances and call it a day. Just like WebMoney did circa 1998.
You dont need a blockchain its a misleading term. There are distributed ledgers that dont requires a chain of blocks.
Also majority in a decentral system is not that simple. It can be done with FBA (Federated Byzantine Agreement).
If that's the case, then yes, account balances are simply agreed on and they call it a day (or technically its called a closed ledger). Then they add the next.
Now ledger are blocks of data and the best way to order them is to chain them with hashes depending on the previous ledger (block). And we are back to "blockchain". Its still misleading the "magic" part isn't the chain of blocks. Its the fact that the double spending problem can be solves without an arbiter of truth.
>Just like WebMoney did circa 1998.
I dont know about the technical way this was implemented back then but most likely the system was operated by a single entity. There is some kind of master balance database and the all other sync with that. A double spending can be prevented by rules applies to the master DB. AKA a write-sync is denied if it violates the balance rules.
This is easy to do centralizes and obviously who ever controls it can circumvent the rules if he wants to.
A majority of nodes who listen to each other (mutual agreement).
>How do you know if you really have a majority or someone is faking a lot of identities and/or hiding a lot of real ones from you?
You decide in advance from which nodes you want to have a majority agreement.
It doesn't matter how many are out there only the ones you listen to matter (for you).
However if you choose 1000 nodes and 900 of them are offline then your node will halt because it can not reach a majority. In other words you are forced to listen to reliable nodes if you want to have a reliable node.
Also if you listen to 10 but they are all owned by a single person. He can lie to your node. In other words you are forced to listen to nodes operated by different entities. In reality there are for example companies, universities, maybe states non-profit organizations etc. Anyone who wants to use it has aligned interest to not collude with others especially competing entities like 2 different banks or payment provider.
This leads to a core of nodes who mostly all listen to each other. If you want to know the final state without even running a node this would be it.
You ask as man nodes as possible form that core of nodes.
What the core or nodes made final is final.
Spinning up thousands of nodes dont matter. No one will listen to them.
They can all listen to each-other then you essentially created a fork.
No one cares, you can no affect what is final and you cant fool anyone unless the voluntary listen to your nodes.
>.... hiding a lot of real ones from you?
The node network is p2p with signed messages there is no hiding.
There is relaying ofc so each messages can go the fastest way possible
but due to privet/public key encryption there is no tampering possible.
If a node would block traffic it just goes another way.
If a node "disappears" its considered offline so it is ignored but only if the rest still reaches majority. If too many go offline the network halts until majority can be reached again.
>And if you later find out you had the wrong "majority" what do you do, if the state is final from your perspective?
There can not be a "wrong majority" unless you listen to the wrong network of nodes.
If you intentionally dont listen to the current core of the network you basically choose to listen to another network aka a fork.
Its like if you listen to BCH instead of BTC you are free to do so.
> BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state.
You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example.
N.B. this issue is nuanced in PoS due to the complete absence of a quantitative fork ranking protocol. The PoW blockchains pow1, pow2, pow3 can be algorithmically ranked according to cumulative hash difficulty unfakeable sans external input (electricity). High difficulty == high certainty. Conversely, the PoS blockchains pos1, pos2, pos3, cannot be compared sans external information/trust. All theoretical finality in PoS is based on trust in central authorities — this type of “finality” is similar to the finality you have in a particular OSS project’s Git history, insofar as the history is dictated by trusted authorities in all cases.
As many commentators have quipped historically, you can build centralized systems on top of decentralized ones, but the reverse isn’t true.
>You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example.
Whats the point? No one wants that beside that LN needs BTC on chain Tx which if you dont arbitrary define as final after some blocks makes it exactly the same - not final.
PoS/PoW is rather irrelevant. we already have solutions to make blocks/ledgers final its doesn't need PoW or PoS its just a properties that BTC doesn't have because it was designed without. There is no fundamental reason why it cant have it.
I don’t quite catch your point. The chances your brain continues functioning over the next twelve minutes is not 100%, but 100% less some infinitesimally small fraction. 99.999999...% is as close physical reality ever comes to 100%.
> PoS/PoW is rather irrelevant
It’s an incredibly relevant fact that PoS blockchains pos1, pos2, pos3 cannot be compared without overtly trusting central authorities to give you the “correct” answer. Conversely, the PoW blockchains pow1, pow2, and pow3 can be objectively ranked by cumulative hashrate using simple mathematical comparisons.
Contrary to popular belief — and despite the endless handwaiving PoS acolytes engage in over social media — PoS blockchains continue to lack a meaningful answer to this predicament which doesn’t boil down to overtly trusting central authorities. Which begs the question: why do they need a blockchain at all?
All block chains in practice require trusting central authorities (trust the code, trust the protocol, trust the math behind it, trust the hardware, trust people to honor their off-chain transactions, trust authorities to help when they don't etc.) so this whole fantasy about 'trustless systems' is meaningless anyway.
You can't create trustless electronic systems for humans. There is simply too much complexity in even the simplest hardware and software for any single person to be able to understand without trusting others. And this doesn't just apply to the 'unwashed masses', but to every single CS researcher, OS programmer or Linus Torvalds.
This is blatantly false. Bitcoin doesn't require anything at all besides the idea of a most work chain humanity produced. You just pick it and that's it. You cant pick wrong, there is no chain bigger.
All other cryptos are a fantasy and cannot provide any comparable guarantees.
It happened multiple times that a longer change was discoed shortly after. So in reality you have to wait some blocks to reduce the risk of a longer chain to almost zero.
Also the trust you missed is that you have to TRUST that at least 50% of the work is produces and controlled (pool owner) by honest humans, because if not they could collude and re-org/double-spend. which essentially means you will pick the wrong chain because they make you think its the longest while secretly mining a longer chain that will eventually repalce the once you picked. There is absolutely no way you would know before its to late so you blindly trust that from an unknown number of people the majority is honest.
If you take mining pools into account you trust a hand full of people who control them.
>All other cryptos are a fantasy and cannot provide any comparable guarantees.
Obvious nonsense, other tech has defined finality. Not pick the longest and if a longer shows up later you switch. These systems provide MORE guarantees.
How do you, personally, know that the chain is correct? Have you ever checked the hashes? Have you ever checked the transactions? Have you ever proved that the math they use is correct? Have you ever read the code for any BTC client?
You're trusting an awful lot of assumptions much more complex than 'the longest chain is right'.
How do you ensure that you got the correct code? Without the correct consensus rules that are encoded in the software, you can't be sure if the blockchain you are following is the right one.
> PoS blockchains pos1, pos2, pos3 cannot be compared without overtly trusting central authorities to give you the “correct” answer.
I have seen you make this point before on here but I don't see how that is true. Can you elaborate? Don't PoS chains typically choose forks based on how much is staked? Last time we discussed this you never explained what is wrong with that approach.
When the PoW chain ‘pow’ forks into pow1 and pow2 with both sides claiming to be the original ‘pow’, the general public can compare the cumulative hashrate of pow1 and pow2 to ascertain legitimacy (see: Bitcoin v Bcash, 2016).
In PoW, external input to the system — electricity — powers hashrate. Electricity is altogether foreign to the context of cryptocurrency, and by necessitating the wasting of electricity on one fork over another, PoW consensus systems ensure miners can vote on only one side of a fork without bearing additional costs.
When the PoS chain ‘pos’ forks into pos1 and pos2, however, with both sides claiming to be the original ‘pos’, there is no hashrate to base our decision on. External inputs are never burned in any PoS chain’s forward progress.
If a Bitcoin v Bcash political fork were to unfold in a pure PoS context, the general public would be faced with a situation where both pos1 and pos2 chains were equally secure. If pos1 claimed to be the rightful heir to the ‘pos’ title while defensively slashing pos2 sympathizers, it wouldn’t harm pos2’s ability to make forward progress on the pos2 chain while pos2 also slashes pos1 sympathizers and equally claims to be the rightful heir to the ‘pos’ title.
It’s as if an OSS project forked with both forks claiming to be the real thing. If both sides are steadfast, it is ultimately up to the public to pick winners and losers based on nothing besides social signaling. See: 2015-2017 block size debate in Bitcoin for pitfalls to this.
Notice how no math is involved whatsoever in the decision to pick pos1 over pos2.
Notice how human intervention is inherently required to reach a decision as to which side of the pos1/pos2 split is given title to ‘pos’.
Pure PoS consensus is substantially similar to Git repos. If people are just going to trust a nebulous human hierarchy to resolve disputes like this, then the system is de facto permissioned, and a public blockchain isn’t required.
I don't understand how the situations you are describing are different between PoW and PoS.
In either case, after a fork, sympathizers of chain A or chain B will start mining/staking on the chain they like.
In either case, members of the public who just want the chain with the most security can pick the one with the most energy burned or most coin-days staked (that's the "hash rate" equivalent/external input with which to base your decision on).
What is the difference? How is human intervention inherently required in the PoS case any more or less than it's required in the PoW case?
If “coin-days staked” is massively higher on one side of a PoS chain fork, that doesn’t impact the other side’s security in the way PoW hashrate imbalances would.
To use a real world example, Bitcoin PoW mining consumes in excess of 100 Terawatt hours of electricity per year. If Bitcoin were to undergo a repeat of 2016 today, and the Bcash blockchain were to be serviced by miners consuming less than 10% of the energy spend of the incumbent (Bitcoin), Bcash could be easily 51% attacked.
But in the PoS corollary to Bitcoin v Bcash, coin-days staked would have no bearing on Bcash’s ability to continue making forward progress. Just so long as it remained difficult to either disrupt 1/3 of Bcash validators or acquire 51% of it, Bcash would continue functioning perfectly well (see: Jude C. Nelson [1]). At that point the rightful heir to the Bitcoin title would have to be determined socially. It could not be determined without top-down human intervention.
> But in the PoS corollary to Bitcoin v Bcash, coin-days staked would have no bearing on Bcash’s ability to continue making forward progress.
How wouldn't it? The ongoing coin-days staked in that fork specifically is what allows it to continue making forward progress. Just like how in a PoW fork, the ongoing consumption of energy in that specific fork is what determines the security of that fork.
The argument you link in that other thread is interesting but it doesn't appear to be exactly what you are talking about. They seem to be describing an attack where nodes are taken offline by the attacker.
> The ongoing coin-days staked in that fork specifically is what allows it to continue making forward progress.
Coin-days staked has no bearing on a pure PoS chain’s risk of being 51% attacked, nor does it have any bearing on the risk 1/3 or more of its validators get disrupted. Not so with PoW hashrate: enormous hashrate imbalances between forked PoW chains directly translate into decreased data immutability per the risk of deep chain reorgs.
Those risks are simply not present in the PoS corollary.
There is nothing wrong with it, the only trusted component is (obviously) in terms of the initial distribution of the staked coins, which is the central feature of proof of stake.
> There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters.
All that matters is the valid history with the largest weight (longest chain rule in PoW). If an invalid branch somehow acquires more weight, it simply gets ignored (except by SPV clients in bitcoin, which trust others to validate). Exchanges/pools that accept an invalid branch are completely untrustworthy and should similarly be ignored.
>All that matters is the valid history with the largest weight (longest chain rule in PoW).
No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems.
Imagine there is a room full of people all have a paper with the exact same transactions in order on it.
Now a new person joins and copies someones paper and then verifies all Tx. Ok, now he only has the chain for one person that's not enough he needs the chain form as much other people as possible to assure he has the longest.
Its perfectly fine to ask the others to only tell him the hash of the whole thing to see if he has the same chain.
So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain.
He just needs to copy the last state (balances) so he can add Tx as well.
(BTC does not have accounts with balances so BTC does not have the concept of "only the last state" but instead of the whole chain only the ends of the tree can be used to reduce the size. but again this is ONLY relevant for BTC and BTC clones/forks its NOT a property of DLTs in general)
The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust.
There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the hash yourself, based on the full transaction history, that your node can be satisfied that it is on the longest chain. _*After*_ you have confirmed that you have the valid chain, it is possible to prune all the history to just the balances and to only validate new blocks as they come in, but in the case of a fork or malicious actors, your node may end up out of sync.
There may be other ways of tackling this issue that I am not aware of, but this problem in particular is one of the fundamental problems that Blockchains / Bitcoin were designed to solve (consensus among peers that is not disrupted by hostile actors). I have yet to see a better solution for this particular problem.
One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?"
However, this is also "zero trust," because you can write a program to verify every tweet as it's tweeted, and run that on a server somewhere.
But, now that I've written this, I suppose Vitalik's "Limits to Blockchain Scalability" addresses this: even if it's theoretically possible to validate the hashes on a supercomputer somewhere, you want your users to be the ones doing this validation, because otherwise it would be possible to compromise the "zero trust" model described above by compromising one twitter account and N verification servers. When N is small, this might be a realistic concern, especially if the verification servers are continuously pulling code changes from a central source code repo.
If you write out to a centralized service like Twitter than you may as well just use a centralized database, it's much more efficient than a blockchain. A core property of a decentralized blockchain is that every person using the chain has equal opportunity to participate in the security of the chain, there are no "blessed users" and you should be able to use it without trusting any other user on it.
>One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?"
The XRPL does this by broadcasting. Every node tells everyone what they think is right, therefore everyone can see who lies and more importantly no one can see who you listen too. Its hard to trick me if you dont even know whom I listen too.
And you cant test it because once you lie to me you lie to everyone and that the last time anyone listened to you.
The "zero trust" thing is an illusion. All decentral systems trust that the majority of something does "the right thing".
Some system use the majority of hashpower other use other metrics and some lets you pick and include or exclude participants.
BTC for example doesn't give you any options you simply trust that from 100% hashpower more than 50% is controlled by honest people. Its not zero trust its more like zero choice trust.
Yes, one thing is unavoidable, you have to assume that the majority is honest else the system simply can not work.
Identifying the majority is however optional. BTC for example does not. You pick the longest chain you can find at a given time. You assume the majority saw the same as the longest. If a longer shows up you switch and again you assume the majority saw that too and switched swell.
Other systems like the XRPL dont assume, every node defines from whom they want a majority.
If 99% of them made a Tx final then there is no way that at a later point in time this final state can be changed because 1% can not ever reach a majority. The only thing that could happen is that the network forks and different parts of the network reach majority on different states. This problem is solved by raising the majority needed to 80% rather than >50% and on top of that is is further reduced by intentionally overlapping the nodes who are defined by each node.
Essentially you need many nodes who listen to each other both ways. So I choose your node to be part of my nodes that must reach majority and you list my node.
If you have 10 nodes all listen to the other 9 and require that form the other 9 80% agree then there is no way the network can ever fork. No 2 different states could ever reach 80%, its just not possible.
Now these 10 nodes are publicly known so if you operate a node you have to pick from these nodes the one you want but you must make sure that your node can not reach a majority without them. So you could pick all 10 and then add for example 5 others. Your node can hen also not fork because the 5 alone can never reach an 80% majority. and so on and on. every new node must have ~80% overlap to prevent forking.
And all of that is super simple because the nodes are public and use public key encryption to identify themself.
> The only thing that could happen is that the network forks and different parts of the network reach majority on different states.
That's the main thing that Bitcoin solved, how to resolve this exact situation. You can't just ignore this problem and claim to have a similarly resilient design.
> This problem is solved by raising the majority needed to 80% rather than >50% and on top of that is is further reduced by intentionally overlapping the nodes who are defined by each node.
The first part just makes it slightly more expensive to do a sybil attack. The second part relies on someone deciding what the overlapping nodes are, now you have to trust them.
> If you have 10 nodes all listen to the other 9 and require that form the other 9 80% agree then there is no way the network can ever fork.
And now you have a network that can't grow beyond 10 nodes, and if more than 10 show up you need to somehow choose the ones that are honest. Or someone needs to decide which nodes get to be the "special 10".
> Now these 10 nodes are publicly known
And chosen by whom? Can you trust the entity that chooses them? Can you trust them not to be hacked and share malicious nodes instead?
The solution is to use the hash power between points of consensus. Aka everyone thinks node A is state last year and here are the next N transactions resulting in the current state X. Sybil attack says no it’s actually B and here are the next N transactions resulting in state Y.
You can compare the effort it takes for history A vs History B. Now, unlike traditional 51% attacks you don’t just need hashing power that instant but instead for very long periods. As such you can compute a minimum history such that actual 51% attacks are significantly cheaper.
That might seem weaker, but Bitcoin’s trust is simply an economic argument. The actual consensus risk is from someone hacking a few nodes thus enabling a 51% attack at near zero cost.
You mean like hacking a few mining pools like 4 and then performer 51% attack at near zero cost. Sounds silly but you get the point. The hacking argument is just not realistic. And it gets less and less relisting to more nodes there are. (and more realistic the fewer mining pools are needed for a 51% attack)
BTW if you would have full control over any 4 XRPL validator nodes at your choice you could do absolutely nothing. No double spend, not even halt the network, nothing at all. You could turn them off and only a few nerds who constantly check the network would notice. User of the actual network would not.
The solution I posted isn’t based on consensus, like Bitcoin even 1 node with a stronger history should win.
Validator nodes aren’t the weak points. It’s as you say the mining pools themselves, internally they need to be coordinated and have access to the Bitcoin network so they can’t be air gapped. So while all major pools have solid network security as they’re major targets, it’s still an actual risk.
The risk is probably way smaller than intentionally collude to make a shitton of money and let it crash and burn.
The perfect exist scam if you want. If china for example would actually put an ultimatum on chines miners to shut down. It could potentially make perfect financial sense to leave with a big boom and make as much money as possible before closing.
Checkpoints are definitely a thing that could be implemented, but you then need to either trust that the software developers have put a valid (or honest) checkpoint into the software... otherwise you are back to trying to determine consensus among hostile actors. A simple >95% consensus on a checkpoint is not enough when it effectively costs fractions of a cent to create thousands or millions of nodes that could all claim to have the "most correct" checkpoint.
Checkpoints are best validated as part of the blockchain. Assuming a weekly checkpoint you’re only using very old checkpoints so valid ones have a lot of hashing power behind them, it’s not based on a popularity contest.
Its based on trusting that never more than 50% hashpower colludes
You still trust its just no defined whom you trust. Its an illusion of no trust.
Any decentral system can somehow be fooled if someone has a majority of "something".
There is simply no way to prevent that.
For BTC this is "something" is hashpower for other system like the XRPL it is the scarcity of mutual trust. But the quorum is actually 80%. And an attacker cannot know how much "mutual trust" his nodes have with others.
>There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y
Thats true but is irrelevant because the node decides whom it asks. And if it gets conflicting answers it would not accept a final state.
As the owner of a node you add a list of other nodes that should be asked.
Lets say you have 20 nodes on that list the fact that someone spins up thousands of nodes doesn't mean anything. No one connects to them and if they do only to send data or receive data that can be validated like a signed Tx. The nodes have no power. Listing to a node is completely voluntary.
Obviously people listen to nodes which are publicly known who operates them and therefore it also clear that they are not operated by the same entities. In reality such nodes are run by exchanges, companies that use the network and universities that do blockchain research. But anyone could its just up to you how you convince anyone to use yours. Maybe you can create one that almost everyone will use. maybe even two. But your army of thousand nameless nodes is never gonna be added by anyone. They are just listing and if they speak no on listens to them.
Also very important is the fact that a successful Sybil attack could not do much that's useful.
Even if all the 20 nodes my node was told to listen to, declares a double spend as final, my node would not. You cant change the code I run and the code says the state is invalid. You created more tokens and that's not possible. It doesn't need to know the Tx that lead to this to know its wrong. The node would simply halt and all I have to do is remove the dishonest nodes from my list an add honest nodes and it keeps going.
And the fact that a node lied is public so once an attack was attempted the node is "burned" no one will ever trust it again.
In other words an immense amount of work and month and month more likely years of luring people into trusting all your nodes would give you the power to halt the network once (or more likely only a certain node) for an indefinite time (because it depend on human interaction) then all your work is toast. Assuming you would even manage to get enough nodes. You dont see who listens to your nodes so you fire blind and only have once shot.
>There may be other ways of tackling this issue that I am not aware of, but this problem in particular is one of the fundamental problems that Blockchains / Bitcoin were designed to solve (consensus among peers that is not disrupted by hostile actors). I have yet to see a better solution for this particular problem.
The fundamental problem it solved was the double-spending problem without an arbitrator of truth.
But it is technically only partially solved because there is no final state.
However if you can reach decentral consensus over anything (a single bit) then the double spending problem isn't even a real problem anymore. If there are 2 conflicting transaction at the same time simply pick one that render the later one invalid because it attempts to move non-existing tokens[1].
>So why even copy the chain first he could just start asking for the hash of the whole thing and if they all have the same there is no point to copy the chain.
Well if I control enough nodes I can send you fake hashes (51% attack).
See other message. Listening to a nodes is voluntary and secret you dont know who or if at all anyone listens to your node. If you simply created a bunch you can be sure no one will listen to them. It doesn't matter how many % they make up.
Imagine a peer goes offline and stuff happens on the network while its offline, when the peer goes back online what state does it follow, remember that it is a decentralized network what peer does it trust? This is where the chain of verifiable transactions come in. Also with this setup it is kind of easy to prevent double spending.
> BTW cash does not have a recorded Tx history
Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually.
Not a problem if its a DLT with final state.
You just need to request the hash of the final state from enough nodes to assure its the real deal. They would all need to lie the same way to trick you. If they are all compromised then the system is rendered useless anyway.
Also basic properties like the total amount of tokens can be validated on the last state alone. You can assure no one added more tokens simply by summing all balances. You dont need any history data for that.
>Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually.
Yeah no, you are moving and stretching the goal post to far here. Notes are unique but that's not a Tx history at all and neither is a Tax form.
>I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state
I don't have anything to add, but this has always struck me as inelegant, especially for Ethereum, which is more of a dApp platform. Can someone point me towards something that can run dApps and maintain current state with distributed consensus _without_ a blockchain (or explain why this is an ignorant question)? Also, what's wrong with truncating the chain after X blocks?
> Also, what's wrong with truncating the chain after X blocks?
I would say nothing. Truncating history isn't explicitly built into the protocol, but that's what most users do in practice. I believe Geth and Parity both prune old state by default. There are "achive" nodes that store all history, but they're in the minority.
Bitcoin Core also has options for pruning old state, and for disabling some validation of old history. Though, unfortunately, it will still download blocks from the genesis even if both options are enabled.
what you're describing is simply a litenode vs a full node. You seem to be nitpicking the 'vision' of crypto in general, which you're right, is a very human thing.
"An important property of a blockchain that users really value is permanence. A digital asset stored on a server will stop existing in 10 years when the company goes bankrupt or loses interest in maintaining that ecosystem. An NFT on Ethereum, on the other hand, is forever."
This is wrong 2 times.
First, there is no general requirement of permanent storage. Its not important at all. It solely depend on the use case. Thats why it is very much inefficient to use a DLT with that property to move value (btc/eth etc.). I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state (aka the balances). Sure the Tx history has use cases and people who need them should store them but making that a technical requirement is only going to degrade performance and drive up Tx cost.
BTW cash does not have a recorded Tx history who thought "p2p cash" should? Its only because of the way BTC works (chain of all Tx) that this "believe" became common. Its technically not needed at all. There is absolutely no reason to recreate the whole chain to come to the current state. You either use the current state or you cant participate. If you would find an error in the chain whatcha gonna do about? Nothing. The current majority accepted state is all that matters. The "validation" is placebo it does nothing. And by running the exact same software as anyone else your validation would simply do the same error if there would be one.
Second, the "forever" is a blatant lie. There is no way to know. Its will exist for however long at least someone is willing to store it. Exactly the same is true if storing is optional. But without the downside of crippling the performance and impose cost on the people running the DLT. The cost for storage should be paid by the user of the storage. If I can impose cost on all participants of a decentral system for all eternity with a one time payment then the system is deeply flawed. The possibility for abuse can be limited by simply making it expensive at any given time. But this obviously reduces the usefulness of the whole system especially for value transfer. The idea of an internet of value is to make value move like data, dirt cheap and decentral so no one takes a cut.