<p>There are two separate issues. One is initial synchronization assuming you don't know anything. The other is how servers advance the ledger in synch.</p>

<p>For initial synch, you monitor the network and watch for signed validations from validators you trust. You check the timestamp on them and if they are current, you can then begin tracking the ledger chain. Once you know what they are claiming the current ledger is, you can fetch any data you're missing, walk the hash chains and transactions, and convince yourself that the ledger they are claiming is valid is in fact justified by the transactions attached to it and that it hooks up to your last ledger, if you have one.</p>

<p>Once you are in synch, you can participate in the consensus process. You will see live transactions relayed, you will see proposed transaction sets, you can send your own proposals. When you see a consensus on a transaction set, you apply it to the last ledger, and you then have the next ledger. You can then sign it and send a validation.</p>

<p>The actual timing of the ledger close is a bit complicated. If there are no transactions, a ledger will typically close every 20 seconds. If there are any unconfirmed transactions, the ledger will close two seconds after it opened and the network will try to form a consensus on them. This two seconds gives nodes a chance to finish processing the previous ledger before they need to start processing the new one.</p>

<p>The actual synchronization occurs using a sophisticated delta algorithm. The ledger is a tree so if a branch hasn't changed, you will discover that without having to traverse that branch. Ledger nodes that you need can be fetched from the network and servers will also predictively return nodes they think you will need based on the nodes you said you did need.</p>

<p>For initial fetching of large amounts of history, the server can request a "fetch pack" from any server that has the history. This contains those ledger nodes the server knows are unique to that particular ledger and help to reduce the number of queries needed.</p>

<p>All validated transactions, all ledgers, and all states the network has ever had form a giant hash tree. Once you know the hash of the current ledger, you can walk the hash tree to find any of those things securely and provably. Validations are not in this hash chain though. They are stored separately and individually signed.</p>

CC BY-SA 3.0
2013-04-26T09:57:51.847Z
2013-04-26T18:59:11.697Z
2013-04-26T18:59:11.697Z
David Schwartz
<p>Bitcoin decides on a global clock by the blockchain - every mined block is another tick of that clock.</p>

<p>In Ripple, there is a global ledger that keeps advancing in time - the ledger number keeps increasing all the time, and the ledger represents the state of the system at time t.</p>

<p>What synchronizes this ledger? How do different Ripple nodes know when they should advanced their ledger counter?</p>

CC BY-SA 3.0
2013-04-07T06:49:37.117Z
I believe the Ripple devs have said that it talks to its peers and compares hashes of ledger state. If others disagree, then they change their own ledger state. They haven't released the source though, so we don't really know.
Nick ODell
CC BY-SA 3.0
2013-04-07T22:58:46.303Z
See https://ripple.com/wiki/Consensus
dchapes
<synchronization><ripple><ripple-ledger>
How does Ripple synchronizes its ledger?
ripper234
# How does Ripple synchronizes its ledger?

(Asked by: username_0 on 2013-04-07)

Bitcoin decides on a global clock by the blockchain - every mined block is another tick of that clock.

In Ripple, there is a global ledger that keeps advancing in time - the ledger number keeps increasing all the time, and the ledger represents the state of the system at time t.

What synchronizes this ledger? How do different Ripple nodes know when they should advanced their ledger counter?

**Tags:** synchronization, ripple, ripple-ledger

> **Comments:**
> **username_1**: I believe the Ripple devs have said that it talks to its peers and compares hashes of ledger state. If others disagree, then they change their own ledger state. They haven't released the source though, so we don't really know.  
> **username_2**: See https://ripple.com/wiki/Consensus  

---

## 1 answers

### Answer by username_3 on 2013-04-26. Score: 3 | Accepted answer

There are two separate issues. One is initial synchronization assuming you don't know anything. The other is how servers advance the ledger in synch.

For initial synch, you monitor the network and watch for signed validations from validators you trust. You check the timestamp on them and if they are current, you can then begin tracking the ledger chain. Once you know what they are claiming the current ledger is, you can fetch any data you're missing, walk the hash chains and transactions, and convince yourself that the ledger they are claiming is valid is in fact justified by the transactions attached to it and that it hooks up to your last ledger, if you have one.

Once you are in synch, you can participate in the consensus process. You will see live transactions relayed, you will see proposed transaction sets, you can send your own proposals. When you see a consensus on a transaction set, you apply it to the last ledger, and you then have the next ledger. You can then sign it and send a validation.

The actual timing of the ledger close is a bit complicated. If there are no transactions, a ledger will typically close every 20 seconds. If there are any unconfirmed transactions, the ledger will close two seconds after it opened and the network will try to form a consensus on them. This two seconds gives nodes a chance to finish processing the previous ledger before they need to start processing the new one.

The actual synchronization occurs using a sophisticated delta algorithm. The ledger is a tree so if a branch hasn't changed, you will discover that without having to traverse that branch. Ledger nodes that you need can be fetched from the network and servers will also predictively return nodes they think you will need based on the nodes you said you did need.

For initial fetching of large amounts of history, the server can request a "fetch pack" from any server that has the history. This contains those ledger nodes the server knows are unique to that particular ledger and help to reduce the number of queries needed.

All validated transactions, all ledgers, and all states the network has ever had form a giant hash tree. Once you know the hash of the current ledger, you can walk the hash tree to find any of those things securely and provably. Validations are not in this hash chain though. They are stored separately and individually signed.


---

