mirror of
https://github.com/tendermint/tendermint.git
synced 2026-08-16 12:16:11 +00:00
chore: lint repo (use american english) (#9144)
This commit is contained in:
Callum Waters
+3
-3
@@ -161,8 +161,8 @@ Example:
|
||||
## EvidenceType
|
||||
|
||||
Tendermint's security model relies on the use of "evidence". Evidence is proof of
|
||||
malicious behaviour by a network participant. It is the responsibility of Tendermint
|
||||
to detect such malicious behaviour. When malicious behavior is detected, Tendermint
|
||||
malicious behavior by a network participant. It is the responsibility of Tendermint
|
||||
to detect such malicious behavior. When malicious behavior is detected, Tendermint
|
||||
will gossip evidence of the behavior to other nodes and commit the evidence to
|
||||
the chain once it is verified by all validators. This evidence will then be
|
||||
passed it on to the application through the ABCI. It is the responsibility of the
|
||||
@@ -734,7 +734,7 @@ Most of the data structures used in ABCI are shared [common data structures](../
|
||||
| Name | Type | Description | Field Number |
|
||||
|-----------|---------------------------------------------------------------|------------------------------------------------------------------------------|--------------|
|
||||
| block | [BlockParams](../core/data_structures.md#blockparams) | Parameters limiting the size of a block and time between consecutive blocks. | 1 |
|
||||
| evidence | [EvidenceParams](../core/data_structures.md#evidenceparams) | Parameters limiting the validity of evidence of byzantine behaviour. | 2 |
|
||||
| evidence | [EvidenceParams](../core/data_structures.md#evidenceparams) | Parameters limiting the validity of evidence of byzantine behavior. | 2 |
|
||||
| validator | [ValidatorParams](../core/data_structures.md#validatorparams) | Parameters limiting the types of public keys validators can use. | 3 |
|
||||
| version | [VersionsParams](../core/data_structures.md#versionparams) | The ABCI application version. | 4 |
|
||||
|
||||
|
||||
@@ -130,7 +130,7 @@ the data in the current block, the previous block, and the results returned by t
|
||||
| ConsensusHash | slice of bytes (`[]byte`) | Hash of the protobuf encoded consensus parameters. | Must be of length 32 |
|
||||
| AppHash | slice of bytes (`[]byte`) | Arbitrary byte array returned by the application after executing and commiting the previous block. It serves as the basis for validating any merkle proofs that comes from the ABCI application and represents the state of the actual application rather than the state of the blockchain itself. The first block's `block.Header.AppHash` is given by `ResponseInitChain.app_hash`. | This hash is determined by the application, Tendermint can not perform validation on it. |
|
||||
| LastResultHash | slice of bytes (`[]byte`) | `LastResultsHash` is the root hash of a Merkle tree built from `ResponseDeliverTx` responses (`Log`,`Info`, `Codespace` and `Events` fields are ignored). | Must be of length 32. The first block has `block.Header.ResultsHash == MerkleRoot(nil)`, i.e. the hash of an empty input, for RFC-6962 conformance. |
|
||||
| EvidenceHash | slice of bytes (`[]byte`) | MerkleRoot of the evidence of Byzantine behaviour included in this block. | Must be of length 32 |
|
||||
| EvidenceHash | slice of bytes (`[]byte`) | MerkleRoot of the evidence of Byzantine behavior included in this block. | Must be of length 32 |
|
||||
| ProposerAddress | slice of bytes (`[]byte`) | Address of the original proposer of the block. Validator must be in the current validatorSet. | Must be of length 20 |
|
||||
|
||||
## Version
|
||||
@@ -415,7 +415,7 @@ func SumTruncated(bz []byte) []byte {
|
||||
| Name | Type | Description | Field Number |
|
||||
|-----------|-------------------------------------|------------------------------------------------------------------------------|--------------|
|
||||
| block | [BlockParams](#blockparams) | Parameters limiting the size of a block and time between consecutive blocks. | 1 |
|
||||
| evidence | [EvidenceParams](#evidenceparams) | Parameters limiting the validity of evidence of byzantine behaviour. | 2 |
|
||||
| evidence | [EvidenceParams](#evidenceparams) | Parameters limiting the validity of evidence of byzantine behavior. | 2 |
|
||||
| validator | [ValidatorParams](#validatorparams) | Parameters limiting the types of public keys validators can use. | 3 |
|
||||
| version | [BlockParams](#blockparams) | The ABCI application version. | 4 |
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
Byzantine processes can demonstrate arbitrary behavior, including
|
||||
no communication. We show that if agreement is violated, then the Byzantine
|
||||
processes demonstrate one of the two behaviours:
|
||||
processes demonstrate one of the two behaviors:
|
||||
|
||||
- Equivocation: a Byzantine process may send two different values
|
||||
in the same round.
|
||||
|
||||
@@ -14,7 +14,7 @@ submitting proof of fork in the IBC context
|
||||
#### [TAG-IBC-MISBEHAVIOR.1]
|
||||
|
||||
```go
|
||||
func checkMisbehaviourAndUpdateState(cs: ClientState, PoF: LightNodeProofOfFork)
|
||||
func checkMisbehaviorAndUpdateState(cs: ClientState, PoF: LightNodeProofOfFork)
|
||||
```
|
||||
|
||||
**TODO:** finish conditions
|
||||
@@ -113,7 +113,7 @@ func SubmitIBCProofOfFork(
|
||||
ibc IBCComponent) (Error) {
|
||||
if ibc.queryChainConsensusState(PoF.TrustedBlock.Height) = PoF.TrustedBlock {
|
||||
// IBC component has root of PoF on store, we can just submit
|
||||
ibc.submitMisbehaviourToClient(ibc.id,PoF)
|
||||
ibc.submitMisbehaviorToClient(ibc.id,PoF)
|
||||
return Success
|
||||
// note sure about the id parameter
|
||||
}
|
||||
@@ -127,7 +127,7 @@ func SubmitIBCProofOfFork(
|
||||
|
||||
if result = Success {
|
||||
newPoF = extendPoF(ibcLightBlock, lblock, lightStore, PoF)
|
||||
ibc.submitMisbehaviourToClient(ibc.id, newPoF)
|
||||
ibc.submitMisbehaviorToClient(ibc.id, newPoF)
|
||||
return Success
|
||||
}
|
||||
else{
|
||||
|
||||
@@ -24,7 +24,7 @@ In the following, I distilled what I considered relevant from
|
||||
| `Height` | (no epochs) | (epoch,height) pair in lexicographical order (`compare`) |
|
||||
| `Header` | ~signed header | validatorSet explicit (no hash); nextValidators missing |
|
||||
| `Evidence` | t.b.d. | definition unclear "which the light client would have considered valid". Data structure will need to change |
|
||||
| `verify` | `ValidAndVerified` | signature does not match perfectly (ClientState vs. LightBlock) + in `checkMisbehaviourAndUpdateState` it is unclear whether it uses traces or goes to h1 and h2 in one step |
|
||||
| `verify` | `ValidAndVerified` | signature does not match perfectly (ClientState vs. LightBlock) + in `checkMisbehaviorAndUpdateState` it is unclear whether it uses traces or goes to h1 and h2 in one step |
|
||||
|
||||
#### Some IBC links
|
||||
|
||||
@@ -32,14 +32,14 @@ In the following, I distilled what I considered relevant from
|
||||
|
||||
#### Required Changes in ICS 007
|
||||
|
||||
- `assert(height > 0)` in definition of `initialise` doesn't match
|
||||
- `assert(height > 0)` in definition of `initialize` doesn't match
|
||||
definition of `Height` as *(epoch,height)* pair.
|
||||
|
||||
- `initialise` needs to be updated to new data structures
|
||||
- `initialize` needs to be updated to new data structures
|
||||
|
||||
- `clientState.frozenHeight` semantics seem not totally consistent in
|
||||
document. E.g., `min` needs to be defined over optional value in
|
||||
`checkMisbehaviourAndUpdateState`. Also, if you are frozen, why do
|
||||
`checkMisbehaviorAndUpdateState`. Also, if you are frozen, why do
|
||||
you accept more evidence.
|
||||
|
||||
- `checkValidityAndUpdateState`
|
||||
@@ -53,7 +53,7 @@ In the following, I distilled what I considered relevant from
|
||||
- clienstState needs to be updated according to complete data
|
||||
structure
|
||||
|
||||
- `checkMisbehaviourAndUpdateState`: as evidence will contain a trace
|
||||
- `checkMisbehaviorAndUpdateState`: as evidence will contain a trace
|
||||
(or two), the assertion that uses verify will need to change.
|
||||
|
||||
- ICS 002 states w.r.t. `queryChainConsensusState` that "Note that
|
||||
@@ -68,7 +68,7 @@ In the following, I distilled what I considered relevant from
|
||||
- `upgradeClientState` what is the semantics (in particular what is
|
||||
`height` doing?).
|
||||
|
||||
- `checkMisbehaviourAndUpdateState(cs: ClientState, PoF:
|
||||
- `checkMisbehaviorAndUpdateState(cs: ClientState, PoF:
|
||||
LightNodeProofOfFork)` needs to be adapted
|
||||
|
||||
#### Handler
|
||||
@@ -104,7 +104,7 @@ type checkValidityAndUpdateState = (Header) => Void
|
||||
will need to make precise eventually) to a handler
|
||||
|
||||
```go
|
||||
type checkMisbehaviourAndUpdateState = (bytes) => Void
|
||||
type checkMisbehaviorAndUpdateState = (bytes) => Void
|
||||
```
|
||||
|
||||
We have to design this, and the data that the handler can use to
|
||||
@@ -126,7 +126,7 @@ type queryChainConsensusState = (height: uint64) => ConsensusState
|
||||
|
||||
- the relayer send headers and data to the handler to invoke
|
||||
`checkValidityAndUpdateState` and
|
||||
`checkMisbehaviourAndUpdateState`. It may also query
|
||||
`checkMisbehaviorAndUpdateState`. It may also query
|
||||
`queryChainConsensusState`.
|
||||
|
||||
- multiple relayers may talk to one handler. Some relayers might be
|
||||
@@ -187,7 +187,7 @@ relayer can figure that out:
|
||||
headers (tagged as verified).
|
||||
|
||||
- eventually, a handler should be informed
|
||||
(`checkMisbehaviourAndUpdateState`)
|
||||
(`checkMisbehaviorAndUpdateState`)
|
||||
by some relayer that it has
|
||||
verified a header from a fork. Then the handler should do what is
|
||||
required by IBC in this case (stop?)
|
||||
|
||||
@@ -323,8 +323,8 @@ from `trustedState` to `newTrustedState` happened during the trusted period of
|
||||
|
||||
In case `VerifyHeaderAtHeight` returns with an error, then either (i) the full node we are talking to is faulty
|
||||
or (ii) the trusted header has expired (it is outside its trusted period). In case (i) the full node is faulty so
|
||||
light client should disconnect and reinitialise with new peer. In the case (ii) as the trusted header has expired,
|
||||
we need to reinitialise light client with a new trusted header (that is within its trusted period),
|
||||
light client should disconnect and reinitialize with new peer. In the case (ii) as the trusted header has expired,
|
||||
we need to reinitialize light client with a new trusted header (that is within its trusted period),
|
||||
but we don't necessarily need to disconnect from the full node we are talking to (as we haven't observed full node misbehavior in this case).
|
||||
|
||||
**VerifyBisection.** The function `VerifyBisection` implements
|
||||
@@ -459,10 +459,10 @@ We consider the following set-up:
|
||||
- the light client communicates with one full node
|
||||
- the light client locally stores all the headers that has passed basic verification and that are within light client trust period. In the pseudo code below we
|
||||
write *Store.Add(header)* for this. If a header failed to verify, then
|
||||
the full node we are talking to is faulty and we should disconnect from it and reinitialise with new peer.
|
||||
the full node we are talking to is faulty and we should disconnect from it and reinitialize with new peer.
|
||||
- If `CanTrust` returns *error*, then the light client has seen a forged header or the trusted header has expired (it is outside its trusted period).
|
||||
- In case of forged header, the full node is faulty so light client should disconnect and reinitialise with new peer. If the trusted header has expired,
|
||||
we need to reinitialise light client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node
|
||||
- In case of forged header, the full node is faulty so light client should disconnect and reinitialize with new peer. If the trusted header has expired,
|
||||
we need to reinitialize light client with new trusted header (that is within its trusted period), but we don't necessarily need to disconnect from the full node
|
||||
we are talking to (as we haven't observed full node misbehavior in this case).
|
||||
|
||||
## Correctness of the Light Client Protocols
|
||||
|
||||
Reference in New Issue
Block a user