This WILL however likely to create a cartel-like YET DECENTRALIZED spider-web similar to the spider web of routing autonomous domains.
(CENSORING Transactions or failing to sign valid transaction to stifle consensus are really THE ONLY two avenues of attack open to arbitrary conspiracy of attackers, i.e. the worst possible damage is to PAUSE the network, i.e. ledgers will close but they'll be empty at which point nodes responsible for this are easily detected and commented out of the UNL lists)
Let's say all clients share the same UNL at first. Now let us say 5% of the nodes are censoring transactions and therefore not reaching the same updated state of the ledger as the other 95% nodes. This shouldn't be a problem in terms of allowing the network to continue since the ledge will still close (more than 80% still agree with the new ledger). However, if this grows this can eventually lead to more than 20% of the UNL not complying, in which case consensus stops.
This is correct.
Trying to fix the problem at that point would be difficult. Everyone would need to update their UNL to remove the problematic nodes, but it is important to do it in a way that is consistent with everyone else so that people don't end up on different forks. However, since the consensus engine has paused, they have no convenient way to reach a consensus on the new UNL. This is similar to the case in DPOS where more than 50% of the delegates do not include any vote changing transactions and so clients cannot vote out delegates and have to use some alternative way (hard fork) to change the delegates.
This argument WOULD be valid, however its hidden assumptions are not true, so it's not. Let me explain.
Your hidden assumption is that the UNL list is somehow large or quasi-random, it's far from either !
It has taken over a year of reliable operation and 99%+ availability for *some* of the nodes to begin adding it to their UNL lists.
It's an inherently slow social process of REPUTATION BUILDING.
Now, what you describe above would be completely analogous to some global backbones just NOT routing packets that come from their peer backbones, in this kind of scenario, their long sought and fought for reputation would be instantly destroyed and their would be removed from ACL lists in the routing tables thereby wasting the entire investment.
To avoid this, the problematic nodes (or delegates in DPOS) need to be continuously removed from their privileged position before the problem grows out of hand. I understand how this is done in DPOS. The transactions that change the approval voting of delegates are included in the consensus blockchain itself. The same consensus technology that keeps track of who has what funds also determines the changes in the set of active delegates (block producers). But how are these desirable (in the sense that it is beneficial for the future reliability of the network) changes to UNL decided in the case of Ripple and how do they get propagated to all Ripple clients? As far as I see in the whitepaper, there is no mechanism to propagate these changes as part of the consensus algorithm or allow the UNL to dynamically change without user intervention.
This is because there is no need for such, again you assume a pseudo-random initial UNL list, it's far far from it.
It's a very slowly curated and carefully controlled list similar to backbone-to-backbone peering agreements between huge networks.
I worry that this means users are forced to rely on the default node list that comes with their client, which just centralizes power to the developers of the client. Or even if there is some procedure for updating the UNL, it will likely only be accepted by the public if it is approved by more than 80% of the current members of the UNL (the ones who would not be removed by the changes to the UNL). Users want to be sure that there is agreement in the network (no forks) and that ledgers continue closing. If an update to the UNL doesn't have the support of 80% of the current UNL, some users may end up on different forks. So because the Ripple consensus algorithm doesn't include (as far as I can tell) a mechanism for updating the UNL consistently across all users, users will likely have to just go with whatever updates are approved by the vast majority of current UNL members.
Indeed, if you've decided to participate in Ripple consensus, you will not find yourself unsynced and unable to advance only if you include a default curated list as shipped by RL possibly adding a few other well known sites.
But do not confuse USERS with node operators, users simply want to issue digitally signed transactions and have assurance that only such transactions will be reflected in the ledger and those users who ACCEPT payment want finality and irreversibility of such payments. This is similar to web sites and surfers just wanting to exchange some TCP/IP packets while the transport is provided by backbone operators.
This is basically equivalent to DPOS where the only people who get to vote on the delegate candidates are the top 101 active delegates (who each get one vote). Even if a good non-colluding set of of initial members was chosen, can we guarantee that they remain that way over time when the only entities who get to vote for changes to the set are the members in the set themselves? My intuition says that this group can slowly become corrupted over time, and when it does, it becomes very difficult to replace them. In this case corruption would mean that they end up becoming a colluding group that selectively censors transactions to serve the interests of themselves (or the more powerful forces that control them). The check on their power needs to come from outside the set. I think the way to do that is by considering the votes of masses that depend on and use the system. But to avoid Sybil attacks, the only sensible voting power to consider is that of stake in the system. Otherwise, Ripple is only as decentralized as the number of individuals who control the 1000 or so nodes in the UNL. But with delegation of stake, the decentralization can expand to all of the individuals who own the stake (such as BTS). This could eventually become millions or even billions of individuals, whereas we can pretty much guarantee that millions of nodes are not going to be in the UNL because scaling out the validators to that many servers makes the consensus algorithm very inefficient.
Ripple Consensus does not use ownership of XRP or any IOU for voting to arrive at consensus, it simply considers every VALID and digitally signed transaction signed by the supermajority of validators "retired" or admitted into the history inside a particular ledger.
In this regard it's very different from DPOS, the assumption underlying Ripple is that it's relatively inexpensive to run a full rippled node and there will be enough sites doing it simply for the benefit of having lower level latency access to the consensus ledger stream and indeed, it's never been a burden to run such a node ... even though there's been over 10 millino ledgers and total storage is already well over 100 Gigabytes ... after scanning the chain of ledgers once (in memory even) every node can prove the legitimacy of the latest ledger and never need to store the entire ledger chain, although some archival nodes, i.e. the once run by RL will always store the entire chain.
Show Posts
