Hey Gaurav! Thanks for the questions!
Partial history: the reference daemon (i.e. rippled) does not check full history. This mean a validator may sign an invalid ledger and keep the proof of invalidity hidden from users?
rippled can be configured to hold full history, if that’s what you desire. A malicious validator could sign such a ledger, but (a) people don’t trust a single validator and (b) there would be cryptographic proof that the validator did so and nobody would ever trust that validator again.
Ripple records a full ledger state every round with double entry for every account, where each ledger state is identified cryptographically. This ledger is immutable, append only, and validators can only propose what the next ledger will look like in the chain.
Consensus Split: Ripple does not separate consensus-critical code from non-consensus critical code, this is further exasperated by the fact that they do not cryptographically sign their binaries, and require 80% of the UNL nodes to agree. This could result in a attack vectors severely discounted as compared to it’s competitors. e.g. one could convince 21% of UNL to sensor a tx, one could maliciously insert code via their web hosting service, or consensus splits due to a minor feature upgrade inadvertently affecting critical code.
I asked one of the engineers from Ripple, Nik Bougalis, to answer this.
“As of this writing, Ripple makes official binary and source RPM packages for RHEL and CentOS available. Those packages are built on a secure machine and are both verified prior to being signed using Ripple’s well-known PRM public key, available at https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release. Our installation instructions, available at https://ripple.com/build/rippled-setup/#installation-on-centosred-hat-with-yum, include details on how to verify the signatures of downloaded packages and SHA256 checksums for the signed RPMs are publicized in release notes that Ripple publishes online over HTTPS.
In addition, the tips of the master, release and develop GitHub repositories will always contain a version-setting commit that will be PGP signed by a Ripple developer.
Together, these measures ensure that someone interested in installing rippled, whether from a package or from source, can always verify that they have acquired files that have not been tampered with. In the future, as an added layer, we may add support for deterministic builds, allowing anyone interested to verify that a given binary was generated by compiling a given set of source files.
On the topic of separation of the code: the consensus code is already separated, although not as much as it could and should be. That is a work that is well in progress, and once done, it should allow us to split consensus off into a library. In addition to further isolating the consensus-specific code, making it easier to both document and analyze, the separation will also make it easy to create a simulation framework around the consensus engine, allowing anyone to test different topologies and scenarios easily and efficiently.
The facts are simple: Ripple consensus is both fast and robust. The Ripple network has been in continuous operation for more than four years and has successfully closed over 30,000,000 ledgers. This is an impressive track record and one which we are proud to stand behind.”
Low barrier Sybil attacks: As a side affect of the ease of running a validator (as compared to a miner in Bitcoin, or POS token nodes), isn’t there an emminent risk of someone running a lot nodes at little cost to simulate distributed consensus or censorship
A worst case scenario is that consensus fails and the network will pause. It will not proceed to the next round if there is collusion. There are only a few rules that must be followed in order for nodes to validate transactions. If transactions that have followed those rules are not being validated by certain nodes, every validating node will become aware of this and disconnect from the dishonest node.
“The details are very complex, but the core concept is fairly simple. Ripple solves the double-spend problem by consensus.
The analogy I use is an “agreement room”. To walk into the room, you have to agree with everyone who is already in there. If you want to disagree, you have to leave and form your own room. Everyone who is honest wants to get into the biggest room they can with the most people in it.
In the room, people constantly agree on the current state of the system. It’s implemented as a hash tree, so that’s just one 256-bit number.
To perform a transaction, you walk into the big room and read out the transaction. Everyone checks the transaction against their ledger. Assuming there’s no conflicting transaction or other problem, everyone agrees that the transaction is valid and they include it in the set of transactions they believe should be applied.
They then work on any disagreements they have by an avalanche process. Essentially, if someone is voting yes on a transaction that doesn’t have overwhelming majority support, they just change their vote to no. This ensures there’s a quick agreement on a set of transactions.
Once a set of candidate transactions is agreed upon, those transaction are applied and everyone computes the next ledger according to a set of deterministic rules. They all sign it, publish those signatures, and now clients know which transactions have been accepted by the consensus process.
If a transaction doesn’t get in for some reason, but it’s still valid, every honest person in the room will say yes to that transaction in the next round.
So, back to the double spend problem. A double spend is essentially two transactions, each of which is valid if and only if it’s applied before the other. Thus solving the double spend problem “merely” requires agreeing on an order for the two transactions. If everyone agrees which comes first, the problem is solved — the one that comes first is applied and thus the other is invalid.
In the Ripple system, if two transactions are a double spend, one of three things can happen:
One transaction will get voted into a consensus set before the other. In this case, that transaction will be in a ledger signed by all the people in the room, forever invalidating the other.
Both get into the same consensus set (this should almost never happen). In this case, a deterministic rule when the consensus set is applied determines which gets into the ledger, forever blocking the other.
Neither gets into a consensus set because neither gets a majority and both transactions are at around 50%. In this case, every node that sees both transactions (which will quickly be the vast majority of nodes) will vote yes on the transaction that wins by a deterministic rule and no on the transaction that loses by that rule. The one that wins by that deterministic rule will get in the consensus set, be applied to the ledger, and forever block the other.
That’s a gross oversimplification, but it’s inherently fairly complex.