Some more fixes

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
 

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

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<SystemTime>` - is the consolidated time we target at.
 
 * `validators_time: ProofMapIndex<PublicKey, SystemTime>` - 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.