Browse Source

spec: typos & other fixes

pull/1178/head
Zach Ramsay 7 years ago
committed by Ethan Buchman
parent
commit
4b4a2029c4
3 changed files with 32 additions and 23 deletions
  1. +7
    -5
      docs/specification/new-spec/README.md
  2. +20
    -12
      docs/specification/new-spec/blockchain.md
  3. +5
    -6
      docs/specification/new-spec/encoding.md

+ 7
- 5
docs/specification/new-spec/README.md View File

@ -5,7 +5,7 @@ It defines the base data structures, how they are validated,
and how they are communicated over the network.
XXX: this spec is a work in progress and not yet complete - see github
[isses](https://github.com/tendermint/tendermint/issues) and
[issues](https://github.com/tendermint/tendermint/issues) and
[pull requests](https://github.com/tendermint/tendermint/pulls)
for more details.
@ -24,8 +24,10 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
### P2P and Network Protocols
- [The Base P2P Layer](p2p/README.md): multiplex the protocols ("reactors") on authenticated and encrypted TCP conns
- [Peer Exchange (PEX)](pex/README.md): gossip known peer addresses so peers can find eachother
TODO: update links
- [The Base P2P Layer](p2p/README.md): multiplex the protocols ("reactors") on authenticated and encrypted TCP connections
- [Peer Exchange (PEX)](pex/README.md): gossip known peer addresses so peers can find each other
- [Block Sync](block_sync/README.md): gossip blocks so peers can catch up quickly
- [Consensus](consensus/README.md): gossip votes and block parts so new blocks can be committed
- [Mempool](mempool/README.md): gossip transactions so they get included in blocks
@ -39,7 +41,7 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
Tendermint provides Byzantine Fault Tolerant State Machine Replication using
hash-linked batches of transactions. Such transaction batches are called "blocks".
Hence Tendermint defines a "blockchain".
Hence, Tendermint defines a "blockchain".
Each block in Tendermint has a unique index - its Height.
A block at `Height == H` can only be committed *after* the
@ -48,7 +50,7 @@ Each block is committed by a known set of weighted Validators.
Membership and weighting within this set may change over time.
Tendermint guarantees the safety and liveness of the blockchain
so long as less than 1/3 of the total weight of the Validator set
is malicious.
is malicious or faulty.
A commit in Tendermint is a set of signed messages from more than 2/3 of
the total weight of the current Validator set. Validators take turns proposing


+ 20
- 12
docs/specification/new-spec/blockchain.md View File

@ -5,7 +5,13 @@ Here we describe the data structures in the Tendermint blockchain and the rules
## Data Structures
The Tendermint blockchains consists of a short list of basic data types:
`Block`, `Header`, `Vote`, `BlockID`, `Signature`, and `Evidence`.
- `Block`
- `Header`
- `Vote`
- `BlockID`
- `Signature`
- `Evidence`
## Block
@ -31,7 +37,7 @@ type Header struct {
// block metadata
Version string // Version string
ChainID string // ID of the chain
Height int64 // current block height
Height int64 // Current block height
Time int64 // UNIX time, in millisconds
// current block
@ -55,7 +61,7 @@ type Header struct {
}
```
Further details on each of this fields is taken up below.
Further details on each of these fields is described below.
## BlockID
@ -97,8 +103,8 @@ type Vote struct {
```
There are two types of votes:
a prevote has `vote.Type == 1` and
a precommit has `vote.Type == 2`.
a *prevote* has `vote.Type == 1` and
a *precommit* has `vote.Type == 2`.
## Signature
@ -184,7 +190,7 @@ The height is an incrementing integer. The first block has `block.Header.Height
The median of the timestamps of the valid votes in the block.LastCommit.
Corresponds to the number of nanoseconds, with millisecond resolution, since January 1, 1970.
Note the timestamp in a vote must be greater by at least one millisecond than that of the
Note: the timestamp of a vote must be greater by at least one millisecond than that of the
block being voted on.
### NumTxs
@ -226,6 +232,8 @@ The first block has `block.Header.TotalTxs = block.Header.NumberTxs`.
### LastBlockID
For the previous block's BlockID:
```go
prevBlockParts := MakeParts(prevBlock, state.LastConsensusParams.BlockGossip.BlockPartSize)
block.Header.LastBlockID == BlockID {
@ -237,7 +245,7 @@ block.Header.LastBlockID == BlockID {
}
```
Previous block's BlockID. Note it depends on the ConsensusParams,
Note: it depends on the ConsensusParams,
which are held in the `state` and may be updated by the application.
The first block has `block.Header.LastBlockID == BlockID{}`.
@ -289,9 +297,9 @@ block.Header.Proposer in state.Validators
Original proposer of the block. Must be a current validator.
NOTE: this field can only be further verified by real-time participants in the consensus.
**Note:** this field can only be further verified by real-time participants in the consensus.
This is because the same block can be proposed in multiple rounds for the same height
and we do not track the initial round the block was proposed.
and we do not track the initial round that the block was proposed.
### EvidenceHash
@ -361,7 +369,7 @@ func (v Vote) Verify(chainID string, pubKey PubKey) bool {
}
```
where `pubKey.Verify` performs the approprioate digital signature verification of the `pubKey`
where `pubKey.Verify` performs the appropriate digital signature verification of the `pubKey`
against the given signature and message bytes.
## Evidence
@ -381,14 +389,14 @@ The votes must not be too old.
Once a block is validated, it can be executed against the state.
The state follows the recursive equation:
The state follows this recursive equation:
```go
state(1) = InitialState
state(h+1) <- Execute(state(h), ABCIApp, block(h))
```
Where `InitialState` includes the initial consensus parameters and validator set,
where `InitialState` includes the initial consensus parameters and validator set,
and `ABCIApp` is an ABCI application that can return results and changes to the validator
set (TODO). Execute is defined as:


+ 5
- 6
docs/specification/new-spec/encoding.md View File

@ -5,8 +5,7 @@
Tendermint aims to encode data structures in a manner similar to how the corresponding Go structs
are laid out in memory.
Variable length items are length-prefixed.
While the encoding was inspired by Go, it is easily implemented in other languages as well given its
intuitive design.
While the encoding was inspired by Go, it is easily implemented in other languages as well, given its intuitive design.
XXX: This is changing to use real varints and 4-byte-prefixes.
See https://github.com/tendermint/go-wire/tree/sdk2.
@ -52,7 +51,7 @@ encode(int(0)) == [0x00]
### Strings
An encoded string is a length prefix followed by the underlying bytes of the string.
An encoded string is length-prefixed followed by the underlying bytes of the string.
The length-prefix is itself encoded as an `int`.
The empty string is encoded as `0x00`. It is not length-prefixed.
@ -82,7 +81,7 @@ encode([2]string{"abc", "efg"}) == [0x01, 0x03, 0x61, 0x62, 0x63, 0x01, 0x03, 0x
### Slices (variable length)
An encoded variable-length array is a length prefix followed by the concatenation of the encoding of
An encoded variable-length array is length-prefixed followed by the concatenation of the encoding of
its elements.
The length-prefix is itself encoded as an `int`.
@ -165,7 +164,7 @@ func SimpleMerkleRoot(hashes [][]byte) []byte{
}
```
Note we abuse notion and call `SimpleMerkleRoot` with arguments of type `struct` or type `[]struct`.
Note: we abuse notion and call `SimpleMerkleRoot` with arguments of type `struct` or type `[]struct`.
For `struct` arguments, we compute a `[][]byte` by sorting elements of the `struct` according to
field name and then hashing them.
For `[]struct` arguments, we compute a `[][]byte` by hashing the individual `struct` elements.
@ -190,7 +189,7 @@ Note how the fields within each level are sorted.
### MakeParts
TMBIN encode an object and slice it into parts.
TMBIN encodes an object and slices it into parts.
```go
MakeParts(object, partSize)


Loading…
Cancel
Save