> 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.
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.