Merge branch 'master' into cason/pbts

tendermint · Dec 15, 2021 · 0cee242 · 0cee242
2 parents 8d16a75 + b907d63
commit 0cee242
Show file tree

Hide file tree

Showing 4 changed files with 144 additions and 9 deletions.
diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md
@@ -11,7 +11,7 @@ which uses proposer-based timestamps.
 - [TLA+ Specification][proposertla]
 
 
-[algorithm]: ./pbts-algorithm_001_draft.md
+[algorithm]: ./pbts-algorithm_002_draft.md
 
 [sysmodel]: ./pbts-sysmodel_001_draft.md
 

diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_002_draft.md
@@ -5,6 +5,7 @@
 PBTS computes for a proposed value `v` the proposal time `v.time`, with bounded difference to the actual real-time the proposed value was generated.
 The proposal time is read from the clock of the process that proposes a value for the first time, its original proposer.
 
+
 With PBTS, therefore, we assume that processes have access to **synchronized clocks**.
 The proper definition of what it means can be found in the [system model][model],
 but essentially we assume that two correct processes do not simultaneous read from their clocks
@@ -25,6 +26,17 @@ In addition, the same value `v` could be proposed, in different rounds, but woul
 Since this possibility does not exist in this second specification, the proposal time became part of the proposed value.
 With this simplification, several small changes to the [arXiv][arXiv] algorithm are no longer required.
 
+<!--
+A value that receives `2f + 1 PREVOTES` in a round of consensus may be re-proposed in a subsequent round.
+A value that is re-proposed **retains its original proposal time**, assigned by its original proposer.
+In other words, once assigned, the proposal time of a value is definitive.
+
+In the [first version][v1] of this specification, proposals were defined as pairs `(v, time)`.
+In addition, the same value could be proposed, in different rounds, associated to distinct times.
+Since this possibility does not exist in this second specification, the proposal time became part of the proposed value.
+With this simplification, several small changes to the [arXiv][arXiv] algorithm, replacing `v` by `(v, t)`, are no longer required.
+-->
+
 ## Time Monotonicity
 
 Values decided in successive heights of consensus must have increasing times, so:
@@ -47,10 +59,15 @@ A value rejected by the `valid()` implementation is not accepted by any correct
 ## Timely Proposals
 
 PBTS introduces a new requirement for a process to accept a proposal: the proposal must be `timely`.
-It is a temporal requirement, associated with the following synchrony (that is, timing)
-[assumptions][model] regarding the behavior of processes and the network:
+It is a temporal requirement, associated to a couple of synchrony (that is, timing) assumptions regarding the behavior of processes and the network.
+
+The evaluation of the `timely` requirement requires comparing the proposal's sending time with the proposal's receiving time.
+As these two time values can be read from different clocks, at different processes, we need to assume that processes' clocks are synchronized.
+As these two times refer to two distinct events, we need to assume a minimum and a maximum real time interval between the occurrence of the two events.
+
+The two synchronous assumptions adopted to evaluate the `timely` predicate are:
 
-- Synchronized clocks: the values simultaneously read from clocks of any two correct processes differ by at most `PRECISION`;
+- Synchronized clocks: the values read from clocks of any two correct processes at the same instant of real time differ by at most `PRECISION`;
 - Bounded transmission delays: the real time interval between the sending of a proposal at a correct process, and the reception of the proposal at any correct process is upper bounded by `MSGDELAY`.
 
 #### **[PBTS-RECEPTION-STEP.1]**

diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md
@@ -252,7 +252,7 @@ For analyzing real-time safety (Point 5), we use a system parameter `ACCURACY`,
 This specification describes the changes needed to be done to the Tendermint consensus algorithm as described in the [arXiv paper][arXiv] and the simplified specification in [TLA+][tlatender], and makes precise the underlying assumptions and the required properties.
 
 - [Part I - System Model and Properties][sysmodel]
-- [Part II - Protocol specification][algorithm]
+- [Part II - Protocol specification][algorithm] (**UPDATED**)
 - [TLA+ Specification][proposertla]
 
 [arXiv]: https://arxiv.org/abs/1807.04938

diff --git a/spec/rpc/README.md b/spec/rpc/README.md
@@ -11,8 +11,8 @@ This file defines the JSON-RPC spec of Tendermint. This is meant to be implement
 
 ## Support
 
-  |              | [Tendermint-Go](https://github.com/tendermint/tendermint/) | [endermint-Rs](https://github.com/informalsystems/tendermint-rs) |
-  |--------------|:----------------------------------------------------------:|:----------------------------------------------------------------:|
+  |              | [Tendermint-Go](https://github.com/tendermint/tendermint/)  | [Tendermint-Rs](https://github.com/informalsystems/tendermint-rs) |
+  |--------------|:-----------------------------------------------------------:|:-----------------------------------------------------------------:|
   | JSON-RPC 2.0 |                             ✅                              |                                ✅                                 |
   | HTTP         |                             ✅                              |                                ✅                                 |
   | HTTPS        |                             ✅                              |                                ❌                                 |
@@ -24,6 +24,8 @@ This file defines the JSON-RPC spec of Tendermint. This is meant to be implement
   | [Status](#status)                       |                             ✅                              |                                 ✅                                 |
   | [NetInfo](#netinfo)                     |                             ✅                              |                                 ✅                                 |
   | [Blockchain](#blockchain)               |                             ✅                              |                                 ✅                                 |
+  | [Header](#header)                       |                             ✅                              |                                 ❌                                  |
+  | [HeaderByHash](#headerbyhash)           |                             ✅                              |                                 ❌                                 |
   | [Block](#block)                         |                             ✅                              |                                 ✅                                 |
   | [BlockByHash](#blockbyhash)             |                             ✅                              |                                 ❌                                 |
   | [BlockResults](#blockresults)           |                             ✅                              |                                 ✅                                 |
@@ -49,7 +51,6 @@ Timestamps in the RPC layer of Tendermint follows RFC3339Nano.  The RFC3339Nano
 This means if a block has a timestamp like: `1985-04-12T23:20:50.5200000Z`, the value returned in the RPC will be `1985-04-12T23:20:50.52Z`.
 
 
-
 ## Info Routes
 
 ### Health
@@ -272,13 +273,130 @@ curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\
 }
 ```
 
+### Header
+
+Get a header at a specified height.
+
+#### Parameters
+
+- `height (integer)`: height of the requested header. If no height is specified the latest height will be used.
+
+#### Request
+
+##### HTTP
+
+```sh
+curl http://127.0.0.1:26657/header
+
+curl http://127.0.0.1:26657/header?height=1
+```
+
+##### JSONRPC
+
+```sh
+curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"header\",\"params\":{\"height\":\"1\"}}"
+```
+
+#### Response
+
+```json
+{
+  "id": 0,
+  "jsonrpc": "2.0",
+  "result": {
+    "header": {
+      "version": {
+        "block": "10",
+        "app": "0"
+      },
+      "chain_id": "cosmoshub-2",
+      "height": "12",
+      "time": "2019-04-22T17:01:51.701356223Z",
+      "last_block_id": {
+        "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7",
+        "parts": {
+          "total": 1,
+          "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD"
+        }
+      },
+      "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812",
+      "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73",
+      "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0",
+      "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0",
+      "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8",
+      "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C",
+      "last_results_hash": "",
+      "evidence_hash": "",
+      "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E"
+    }
+  }
+}
+```
+
+### HeaderByHash
+
+#### Parameters
+
+- `hash (string)`: Hash of the header to query for.
+
+#### Request
+
+##### HTTP
+
+```sh
+curl http://127.0.0.1:26657/header_by_hash?hash=0xD70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED
+```
+
+##### JSONRPC
+
+```sh
+curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"header_by_hash\",\"params\":{\"hash\":\"0xD70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED\"}}"
+```
+
+#### Response
+
+```json
+{
+  "id": 0,
+  "jsonrpc": "2.0",
+  "result": {
+      "header": {
+        "version": {
+          "block": "10",
+          "app": "0"
+        },
+        "chain_id": "cosmoshub-2",
+        "height": "12",
+        "time": "2019-04-22T17:01:51.701356223Z",
+        "last_block_id": {
+          "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7",
+          "parts": {
+            "total": 1,
+            "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD"
+          }
+        },
+        "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812",
+        "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73",
+        "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0",
+        "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0",
+        "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8",
+        "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C",
+        "last_results_hash": "",
+        "evidence_hash": "",
+        "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E"
+      }
+    }
+  }
+}
+```
+
 ### Block
 
 Get block at a specified height.
 
 #### Parameters
 
-- `height (integer)`: height of the requested block. If no height is specified the latest block will be used.
+- `height (integer)`: height of the requested block. If no height is specified the latest height will be used.
 
 #### Request