The state of the XRP distributed ledger changes every few seconds. When the nodes that validate the transactions agree on which transactions to validate and add them to the ledger, a new instance, or current state as it is known in other blockchains, is defined. It is given its own serial number which helps to identify it.
XRP Ledger Elements — Source
The new instance will have the metadata of the transactions it contains and information about how that transaction affects the accounts that exist in the network. This information includes:
If an account in an instance is different from the instance immediately before it, the current instance must contain the correcting transactions. In other words, the proof of the change should be recorded.
XRP Ledger Sequence and History — Source
The XRP ledger network has computers that help to distribute and validate transactions or provide information to clients. They are called nodes and are distributed across the network. Client applications like mobile wallets, banks, and electronic trading platforms carry out transactions and transmit them to the nodes. There are two types of nodes:
When a transaction arrives at a node, it is checked using the current state of the ledger to qualify it as a candidate for validation. The node will check whether the account that has requested for a validation of that transaction can fund it. This capacity is either a trust line or an availability of adequate XRP.
After that, the node broadcasts the candidate transaction to its peers to include it in the pool of candidate transactions to be validated.
Since it takes time to broadcast to everyone, Ripple uses a consensus-based mechanism to maintain an identical ledger. This is done via “Chosen validators”. These are nodes that collectively form a trusted subset of validator nodes — they are chosen with an expectation that they are not likely to collude to falsify validations. If this was not done, a malicious attacker could create a fraudulent node group that could orchestrate malpractices in the blockchain.
If a transaction is suggested by enough chosen validators to appear in 80% of suggestions, it is approved to appear in the final approved set that will be used by every node to move to the next stage called validation. Those that do not succeed to be agreed upon will appear in the next round of consensus.
Once the transactions are agreed upon, each node calculates a hash signature for the updated ledger using the identities of the agreed transactions and communicates it to the network. This is akin to suggesting the order and appearance of the final state of the ledger.
If one version of the hash is identical from 80% or above of the nodes, all the other hashes of the remaining small percentage of nodes are discarded, and every node obtains the consensus validation.
If a consensus of the validation is not reached, it means that there were a lot of transactions to pick from or delays in the network causing a pile-up of different candidates of transactions to pick from. The consensus stage has to be repeated to reduce disagreement.
Once consensus is achieved, the nodes update the ledger and start working on a new cycle, considering the transactions that were rejected in the previous round and new transactions that have newly been received from client applications.
This whole process takes an average of 4 seconds to complete.