ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-13 08:15:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1175 from movitto/ledger_close_time_example

Browse Source 
Add example of Ledger Close Time determination
This commit is contained in:
Rome Reginelli
2021-11-29 15:30:11 -08:00
committed by GitHub
parent e5acdb8704 f3aca0ccea
commit c9a14e9ca0
2 changed files with 26 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
content/concepts/payment-system-basics/ledgers.md
View File

@@ -56,6 +56,31 @@ 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
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**
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**
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**
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

2
dactyl-config.yml
View File

@@ -138,7 +138,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#検証の計算と共有"