From 77789f670fd43f3a9a9c272b6b3fc99f02ee7e0d Mon Sep 17 00:00:00 2001 From: Mo Morsi Date: Wed, 22 Sep 2021 16:56:01 -0400 Subject: [PATCH 1/2] Add example of Ledger Close Time determination --- .../concepts/payment-system-basics/ledgers.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/content/concepts/payment-system-basics/ledgers.md b/content/concepts/payment-system-basics/ledgers.md index 09e80a0364..4db367043b 100644 --- a/content/concepts/payment-system-basics/ledgers.md +++ b/content/concepts/payment-system-basics/ledgers.md @@ -56,6 +56,28 @@ Since new ledger versions usually close about every 3 to 5 seconds, these rules Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object. +### Example + +Lets say the last close time is 12:00:00: + +**Current consensus round** + +- A validator individually determines that the next close time should be 12:00:03 +- This is then rounded down based on the close time resolution to 12:00:00 +- But since this is not greater than the last close time, it's incremented to 12:00:01 +- The validators then negotiate and agree that the next close time is 12:00:01 + +**Next consensus round** + +- In the next round validators project that the next close time should be 12:00:04 +- This is rounded down based on the close time resolution to 12:00:00 +- But again this is not greater than the last close time, so it's incremented to 12:00:02 + +**Next consensus round after that** + +- Next validators determine that the next close time should be 12:00:05 +- Which is rounded up based on the close time resolution to 12:00:10 +- Since this is greater than the last close time, that value is used ## See Also From f3aca0ccea39abb1919efd723c5fb09225e4cb66 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 29 Nov 2021 14:23:57 -0800 Subject: [PATCH 2/2] Ledger close times example: edits per reviews --- .../concepts/payment-system-basics/ledgers.md | 25 +++++++++++-------- dactyl-config.yml | 2 +- 2 files changed, 15 insertions(+), 12 deletions(-) diff --git a/content/concepts/payment-system-basics/ledgers.md b/content/concepts/payment-system-basics/ledgers.md index 4db367043b..4c38d8f80c 100644 --- a/content/concepts/payment-system-basics/ledgers.md +++ b/content/concepts/payment-system-basics/ledgers.md @@ -58,26 +58,29 @@ Generally speaking, the ledger cannot make any time-based measurements that are ### Example -Lets say the last close time is 12:00:00: +The following examples demonstrate the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**: **Current consensus round** -- A validator individually determines that the next close time should be 12:00:03 -- This is then rounded down based on the close time resolution to 12:00:00 -- But since this is not greater than the last close time, it's incremented to 12:00:01 -- The validators then negotiate and agree that the next close time is 12:00:01 +1. A validator notes that it was **12:00:03** when the ledger closed and entered consensus. The validator includes this close time in its proposals. +2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**. +3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**. +4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**. +5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus.html#validation) that others did the same. + +Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network. **Next consensus round** -- In the next round validators project that the next close time should be 12:00:04 -- This is rounded down based on the close time resolution to 12:00:00 -- But again this is not greater than the last close time, so it's incremented to 12:00:02 +1. The next ledger enters consensus at **12:00:04** according to most validators. +2. This rounds down again, to a close time of **12:00:00**. +3. Since this is not greater than the previous ledger's close time of 12:00:01, the adjusted close time is **12:00:02**. **Next consensus round after that** -- Next validators determine that the next close time should be 12:00:05 -- Which is rounded up based on the close time resolution to 12:00:10 -- Since this is greater than the last close time, that value is used +1. The ledger after that enters consensus at **12:00:05** according to most validators. +2. This rounds up, based on the close time resolution, to **12:00:10**. +3. Since this value is larger than the previous ledger's close time, it does not need to be adjusted. **12:00:10** becomes the official close time. ## See Also diff --git a/dactyl-config.yml b/dactyl-config.yml index d492c9d9f9..9c0a0ae2ba 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -136,7 +136,7 @@ targets: # Fix links from untranslated health-check.html: "rippled-server-modes.html#stand-alone-mode": "rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由" "server-doesnt-sync.html#normal-syncing-behavior": "server-doesnt-sync.html#通常の同期動作" - # Fix link from untranslated negativeunl.html: + # Fix link from untranslated negativeunl.html and ledgers.html: "consensus.html#validation": "consensus.html#検証" # Fix link from untranslated tickets.html: "consensus.html#calculate-and-share-validations": "consensus.html#検証の計算と共有"