This website is no longer actively supported. Please see the Ripple Developer Center for up-to-date documentation and other resources.

Continuous Ledger Close

From Ripple Wiki
Jump to: navigation, search

Continuous ledger close is the ledger timing scheme that was chosen for the ripple network. Essentially, so long as there are valid transactions that are unconfirmed, the network is always trying to close a ledger. This ensures we have a new ledger as soon as possible. If closing a ledger takes 10 seconds, then the network will close a ledger every 10 seconds.

Detailed Operation

If the network is idle, that is no transactions are being performed, a ledger will remain open for 10 to 30 seconds. It will close because every node will generate a first proposal that implicitly triggers ledger closing.

When a transaction is introduced to an idle network, nodes immediately begin to close the ledger with that transaction. This transitions the network from idle to active.

As soon as a node detects a consensus, it will process the consensus transaction set and publish a validation. The validation will include the hash of the consensus transaction set and nodes will consider it also as a "final proposal", pushing any nodes that haven't recognized a consensus yet towards recognizing that a consensus has occurred.

If there are no transactions in the next set, it will close when its idle timer expires in enough nodes. However, if there are leftover transactions not in the previous consensus set, nodes will begin closing the next ledger immediately. They'll announce new initial proposals with the new close time.

Essentially, if there are unconfirmed transactions, the network will be trying to close them. The close time included will be based on the close time of the last ledger and the time consensus was established. The algorithm will be designed such that there will only rarely be disagreement on the close time.

In all cases, the network will try to close a ledger every 30 seconds minimum (except in very unusual cases) in order to provide validations as proof that the network was operating and to prove to clients that transactions didn't take place or that balances are still valid.


Confirmation times are reduced because there are no long idle times with unconfirmed transactions between ledgers.

There is no need to close a ledger in any particular time frame. This means it's more adaptive. If there's a cluster of fast nodes that compose most of the UNL, they'll force the other nodes to close very quickly. If there's poor network conditions, consensus will be delayed. There is no requirement that consensus be reached in any particular time.

Once a ledger has closed, the transaction processing and consensus building portions of the server do not need it any more and it's immutable. If ledgers close often and quickly enough, the client handling part of the server can operate exclusively on these immutable ledgers.

So the open ledger will be accessed only by the live transaction processing portion of the server until it closes. At that time, it will become a candidate ledger, used only by the ledger close and consensus building logic. Once closed, it will become immutable, used only by the client serving part of the server.