mirror of
https://github.com/tendermint/tendermint.git
synced 2026-08-17 04:36:11 +00:00
chore: lint repo (use american english) (#9144)
This commit is contained in:
Callum Waters
@@ -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