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