From 9cca3480ef95ca5d7a056b80da79dc6f5acd158b Mon Sep 17 00:00:00 2001 From: Serhii Oryshych Date: Thu, 8 Feb 2018 11:18:18 +0200 Subject: [PATCH] Some more fixes --- services/time/CHANGELOG.md | 5 +-- services/time/README.md | 2 +- services/time/TUTORIAL.md | 65 +++++++++++++++++++------------------- 3 files changed, 37 insertions(+), 35 deletions(-) diff --git a/services/time/CHANGELOG.md b/services/time/CHANGELOG.md index 8105dfc91e..84e8db849d 100644 --- a/services/time/CHANGELOG.md +++ b/services/time/CHANGELOG.md @@ -8,9 +8,10 @@ The project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html) ### Breaking changes + The structure `Time` is removed, use `SystemTime` -for saving validator's time in `ProofMapIndex` instead. (#20) + for saving validator's time in `ProofMapIndex` instead. (#20) + + Renamed methods `validators_time`/`validators_time_mut` to -`validators_times`/`validators_times_mut` in `Schema`. (#20) + `validators_times`/`validators_times_mut` in `Schema`. (#20) ## 0.5 - 2018-02-01 diff --git a/services/time/README.md b/services/time/README.md index a490fd9bf6..749e2f4015 100644 --- a/services/time/README.md +++ b/services/time/README.md @@ -68,7 +68,7 @@ impl Transaction for Tx { See the full implementation of the [service][service], which uses the time oracle. -You can get the time of each validator node in the same manner +You can get the time of each validator node in the same manner the consolidated time of the system is obtained: ```rust diff --git a/services/time/TUTORIAL.md b/services/time/TUTORIAL.md index b63714f91c..f4cd44272f 100644 --- a/services/time/TUTORIAL.md +++ b/services/time/TUTORIAL.md @@ -20,19 +20,19 @@ one should be able to access the calendar time. Said time should meet the following criteria: * **Reliability**. The time value must be tolerant to the malicious behavior -of validator nodes. + of validator nodes. * **Agreement**. The time must be the same on all the nodes to ensure that -transactions are executed in a deterministic manner. This means that the time -should be written in the Exonum blockchain storage. Thus, the "current" time -will be changing similarly on all nodes during execution of transactions, -including during nodes update. + transactions are executed in a deterministic manner. This means that the time + should be written in the Exonum blockchain storage. Thus, the "current" time + will be changing similarly on all nodes during execution of transactions, + including during nodes update. -* **Sufficient accuracy**. The specified time should be fairly accurate. -In practice, an acceptable deviation is a few seconds (up to a minute). +* **Sufficient accuracy**. The specified time should be fairly accurate. + In practice, an acceptable deviation is a few seconds (up to a minute). -+ **Monotony**. The time value should only increase. A pragmatic requirement, -which simplifies use of time when implementing the business logic. +* **Monotony**. The time value should only increase. A pragmatic requirement, + which simplifies use of time when implementing the business logic. Thus, due to the sufficient accuracy requirement the service cannot use median time-past from Bitcoin. Indeed, the time in Bitcoin headers is updated every 10 @@ -53,21 +53,21 @@ the header of the block obtained based on this _Propose_. #### Advantages of Integration with Consensus * The time value is indicated directly in the header of each block making it -more accessible. + more accessible. * Time is forcibly updated in the course of consensus operation: -it is impossible to sabotage update of time without stopping consensus. + it is impossible to sabotage update of time without stopping consensus. * Blockchain is not clogged by the time oracle transactions. -#### Disadvantages of Integration with Consensus: +#### Disadvantages of Integration with Consensus * The consensus code becomes more complex. (Time is included into the consensus -logic while anchoring and configuration are not.) + logic while anchoring and configuration are not.) -* Time is updated with each block. In the case of a large delay in -block acceptance, all the transactions therein will be executed with -the same time value. +* Time is updated with each block. In the case of a large delay in + block acceptance, all the transactions therein will be executed with + the same time value. ### Time Oracle Service @@ -80,20 +80,20 @@ and is updated after each transaction from any of the validators. #### Advantages of the Time Oracle Service * The logic for time update is placed in a separate plug-in service -(modularity). + (modularity). * In case of a long delay in block acceptance, the time will be updated along -with the delayed block execution while executing its transactions. -Said time will be accurate enough with regard to the time of the transaction -entry into the pool. + with the delayed block execution while executing its transactions. + Said time will be accurate enough with regard to the time of the transaction + entry into the pool. #### Disadvantages of the Time Oracle Service -* The time value is indicated as an index in the Exorum storage, hence, -receipt thereof by the client requires additional cryptographic checks. +* The time value is indicated as an index in the Exorum storage, hence, + receipt thereof by the client requires additional cryptographic checks. * Each Exonum block will contain time oracle transactions -(usually one for each validator). + (usually one for each validator). **It was decided that the time oracle should be implemented as a separate service to develop it separately from the core and @@ -119,7 +119,7 @@ To obtain local, reliable time external solutions like [tlsdate][], * `time: Entry` - is the consolidated time we target at. * `validators_time: ProofMapIndex` - the last known -local time of the validator nodes. + local time of the validator nodes. The service implements only one transaction consisting of the actual validator’s time and signed with its key. The logic of such transaction @@ -128,26 +128,27 @@ execution is as follows: 1. It is checked that `PublicKey` belongs to the validator. 2. The time specified in the transaction is greater than said validator’s time -specified in the storage (transactions potentially can be executed in the order -reverse to their creation order, but the time must change monotonously). + specified in the storage (transactions potentially can be executed in + the order reverse to their creation order, + but the time must change monotonously). 3. The time for this validator is updated in the storage. 4. All values ​​from the `validators_time` index are fetched. 5. All non-validator nodes are filtered off by the public keys -(since the validators list can change, the index may contain time values -​​for non-valid validators). + (since the validators list can change, the index may contain time values + ​​for non-valid validators). 6. The number of the remaining values must be equal or greater than `2f + 1` -(where `f = (n - 1) / 3` - the maximum number of Byzantine validators). + (where `f = (n - 1) / 3` - the maximum number of Byzantine validators). 7. The resulting list is sorted down from the largest value to the lowest one. 8. `f + 1` time in the resulting list is taken. 9. If the time from `8.` is larger than `time`, the value in the storage -is replaced with the resulting value. + is replaced with the resulting value. Thus, the consolidated time can be updated after each transaction with the actual time from any validator node, taking into account the possibility @@ -160,7 +161,7 @@ any time in the `[f + 1, 2f + 1]` interval is: * either the time of an honest node * or the time in the interval between the timestamps of two honest nodes -(and therefore such a time can be considered reliable) + (and therefore such a time can be considered reliable) For practical reasons, we always choose the `f + 1` timestamp, since this value is reliable and at the same time the most recent one. @@ -170,7 +171,7 @@ the time any moment, however, in the current implementation the nodes send the transaction after commit of each block. At the time when a new blockchain is launched, the consolidated time is unknown -until the transactions from at least `2f + 1` validator nodes are processed. +until the transactions from at least `2f + 1` validator nodes are processed. Further in the course of blockchain operation this time will strictly grow monotonously.