spec: merge rust-spec (#252)
@@ -5,66 +5,201 @@ parent:
|
||||
order: 5
|
||||
---
|
||||
|
||||
NOTE: This specification is under heavy development and is not yet complete nor
|
||||
accurate.
|
||||
# Light Client Specification
|
||||
|
||||
## Contents
|
||||
This directory contains work-in-progress English and TLA+ specifications for the Light Client
|
||||
protocol. Implementations of the light client can be found in
|
||||
[Rust](https://github.com/informalsystems/tendermint-rs/tree/master/light-client) and
|
||||
[Go](https://github.com/tendermint/tendermint/tree/master/light).
|
||||
|
||||
- [Motivation](#motivation)
|
||||
- [Structure](#structure)
|
||||
- [Core Verification](./verification.md)
|
||||
- [Fork Detection](./detection.md)
|
||||
- [Fork Accountability](./accountability.md)
|
||||
Light clients are assumed to be initialized once from a trusted source
|
||||
with a trusted header and validator set. The light client
|
||||
protocol allows a client to then securely update its trusted state by requesting and
|
||||
verifying a minimal set of data from a network of full nodes (at least one of which is correct).
|
||||
|
||||
## Motivation
|
||||
The light client is decomposed into two main components:
|
||||
|
||||
The Tendermint Light Client is motivated by the need for a light weight protocol
|
||||
to sync with a Tendermint blockchain, with the least processing necessary to
|
||||
securely verify a recent state. The protocol consists of managing trusted validator
|
||||
sets and trusted block headers, and is based primarily on checking hashes
|
||||
and verifying Tendermint commit signatures.
|
||||
- [Commit Verification](#Commit-Verification) - verify signed headers and associated validator
|
||||
set changes from a single full node, called primary
|
||||
- [Attack Detection](#Attack-Detection) - verify commits across multiple full nodes (called secondaries) and detect conflicts (ie. the existence of a lightclient attack)
|
||||
|
||||
Motivating use cases include:
|
||||
In case a lightclient attack is detected, the lightclient submits evidence to a full node which is responsible for "accountability", that is, punishing attackers:
|
||||
|
||||
- Light Node: a daemon that syncs a blockchain to the latest committed header by making RPC requests to full nodes.
|
||||
- State Sync: a reactor that syncs a blockchain to a recent committed state by making P2P requests to full nodes.
|
||||
- IBC Client: an ABCI application library that syncs a blockchain to a recent committed header by receiving proof-carrying
|
||||
transactions from "IBC relayers", who make RPC requests to full nodes on behalf of the IBC clients.
|
||||
- [Accountability](#Accountability) - given evidence for an attack, compute a set of validators that are responsible for it.
|
||||
|
||||
## Structure
|
||||
## Commit Verification
|
||||
|
||||
### Components
|
||||
The [English specification](verification/verification_001_published.md) describes the light client
|
||||
commit verification problem in terms of the temporal properties
|
||||
[LCV-DIST-SAFE.1](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification/verification_001_published.md#lcv-dist-safe1) and
|
||||
[LCV-DIST-LIVE.1](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification/verification_001_published.md#lcv-dist-live1).
|
||||
Commit verification is assumed to operate within the Tendermint Failure Model, where +2/3 of validators are correct for some time period and
|
||||
validator sets can change arbitrarily at each height.
|
||||
|
||||
The Tendermint Light Client consists of three primary components:
|
||||
A light client protocol is also provided, including all checks that
|
||||
need to be performed on headers, commits, and validator sets
|
||||
to satisfy the temporal properties - so a light client can continuously
|
||||
synchronize with a blockchain. Clients can skip possibly
|
||||
many intermediate headers by exploiting overlap in trusted and untrusted validator sets.
|
||||
When there is not enough overlap, a bisection routine can be used to find a
|
||||
minimal set of headers that do provide the required overlap.
|
||||
|
||||
- [Core Verification](./verification.md): verifying hashes, signatures, and validator set changes
|
||||
- [Fork Detection](./detection.md): talking to multiple peers to detect Byzantine behaviour
|
||||
- [Fork Accountability](./accountability.md): analyzing Byzantine behaviour to hold validators accountable.
|
||||
The [TLA+ specification ver. 001](verification/Lightclient_A_1.tla)
|
||||
is a formal description of the
|
||||
commit verification protocol executed by a client, including the safety and
|
||||
termination, which can be model checked with Apalache.
|
||||
|
||||
While every light client must perform core verification and fork detection
|
||||
to achieve their prescribed security level, fork accountability is expected to
|
||||
be done by full nodes and validators, and is thus more accurately a component of
|
||||
the full node consensus protocol, though it is included here since it is
|
||||
primarily concerned with providing security to light clients.
|
||||
A more detailed TLA+ specification of
|
||||
[Light client verification ver. 003](verification/Lightclient_003_draft.tla)
|
||||
is currently under peer review.
|
||||
|
||||
A schematic of the core verification and fork detection components in
|
||||
a Light Node are depicted below. The schematic is quite similar for other use cases.
|
||||
Note that fork accountability is not depicted, as it is the responsibility of the
|
||||
full nodes.
|
||||
The `MC*.tla` files contain concrete parameters for the
|
||||
[TLA+ specification](verification/Lightclient_A_1.tla), in order to do model checking.
|
||||
For instance, [MC4_3_faulty.tla](verification/MC4_3_faulty.tla) contains the following parameters
|
||||
for the nodes, heights, the trusting period, the clock drifts,
|
||||
correctness of the primary node, and the ratio of the faulty processes:
|
||||
|
||||
.
|
||||
```tla
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* the trusting period in some time units
|
||||
CLOCK_DRIFT = 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT = 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
```
|
||||
|
||||
### Synchrony
|
||||
To run a complete set of experiments, clone [apalache](https://github.com/informalsystems/apalache) and [apalache-tests](https://github.com/informalsystems/apalache-tests) into a directory `$DIR` and run the following commands:
|
||||
|
||||
Light clients are fundamentally synchronous protocols,
|
||||
where security is restricted by the interval during which a validator can be punished
|
||||
for Byzantine behaviour. We assume here that such intervals have fixed and known minimal duration
|
||||
referred to commonly as a blockchain's Unbonding Period.
|
||||
```sh
|
||||
$DIR/apalache-tests/scripts/mk-run.py --memlimit 28 002bmc-apalache-ok.csv $DIR/apalache . out
|
||||
./out/run-all.sh
|
||||
```
|
||||
|
||||
A secure light client must guarantee that all three components -
|
||||
core verification, fork detection, and fork accountability -
|
||||
each with their own synchrony assumptions and fault model, can execute
|
||||
sequentially and to completion within the given Unbonding Period.
|
||||
After the experiments have finished, you can collect the logs by executing the following command:
|
||||
|
||||
TODO: define all the synchrony parameters used in the protocol and their
|
||||
relation to the Unbonding Period.
|
||||
```sh
|
||||
cd ./out
|
||||
$DIR/apalache-tests/scripts/parse-logs.py --human .
|
||||
```
|
||||
|
||||
All lines in `results.csv` should report `Deadlock`, which means that the algorithm
|
||||
has terminated and no invariant violation was found.
|
||||
|
||||
Similar to [002bmc-apalache-ok.csv](verification/002bmc-apalache-ok.csv),
|
||||
file [003bmc-apalache-error.csv](verification/003bmc-apalache-error.csv) specifies
|
||||
the set of experiments that should result in counterexamples:
|
||||
|
||||
```sh
|
||||
$DIR/apalache-tests/scripts/mk-run.py --memlimit 28 003bmc-apalache-error.csv $DIR/apalache . out
|
||||
./out/run-all.sh
|
||||
```
|
||||
|
||||
All lines in `results.csv` should report `Error`.
|
||||
|
||||
The following table summarizes the experimental results for Light client verification
|
||||
version 001. The TLA+ properties can be found in the
|
||||
[TLA+ specification](verification/Lightclient_A_1.tla).
|
||||
The experiments were run in an AWS instance equipped with 32GB
|
||||
RAM and a 4-core Intel® Xeon® CPU E5-2686 v4 @ 2.30GHz CPU.
|
||||
We write “✗=k” when a bug is reported at depth k, and “✓<=k” when
|
||||
no bug is reported up to depth k.
|
||||
|
||||

|
||||
|
||||
The experimental results for version 003 are to be added.
|
||||
|
||||
## Attack Detection
|
||||
|
||||
The [English specification](detection/detection_003_reviewed.md)
|
||||
defines light client attacks (and how they differ from blockchain
|
||||
forks), and describes the problem of a light client detecting
|
||||
these attacks by communicating with a network of full nodes,
|
||||
where at least one is correct.
|
||||
|
||||
The specification also contains a detection protocol that checks
|
||||
whether the header obtained from the primary via the verification
|
||||
protocol matches corresponding headers provided by the secondaries.
|
||||
If this is not the case, the protocol analyses the verification traces
|
||||
of the involved full nodes
|
||||
and generates
|
||||
[evidence](detection/detection_003_reviewed.md#tmbc-lc-evidence-data1)
|
||||
of misbehavior that can be submitted to a full node so that
|
||||
the faulty validators can be punished.
|
||||
|
||||
The [TLA+ specification](detection/LCDetector_003_draft.tla)
|
||||
is a formal description of the
|
||||
detection protocol for two peers, including the safety and
|
||||
termination, which can be model checked with Apalache.
|
||||
|
||||
The `LCD_MC*.tla` files contain concrete parameters for the
|
||||
[TLA+ specification](detection/LCDetector_003_draft.tla),
|
||||
in order to run the model checker.
|
||||
For instance, [LCD_MC4_4_faulty.tla](detection/MC4_4_faulty.tla)
|
||||
contains the following parameters
|
||||
for the nodes, heights, the trusting period, the clock drifts,
|
||||
correctness of the nodes, and the ratio of the faulty processes:
|
||||
|
||||
```tla
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* the trusting period in some time units
|
||||
CLOCK_DRIFT = 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT = 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
IS_SECONDARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
```
|
||||
|
||||
To run a complete set of experiments, clone [apalache](https://github.com/informalsystems/apalache) and [apalache-tests](https://github.com/informalsystems/apalache-tests) into a directory `$DIR` and run the following commands:
|
||||
|
||||
```sh
|
||||
$DIR/apalache-tests/scripts/mk-run.py --memlimit 28 004bmc-apalache-ok.csv $DIR/apalache . out
|
||||
./out/run-all.sh
|
||||
```
|
||||
|
||||
After the experiments have finished, you can collect the logs by executing the following command:
|
||||
|
||||
```sh
|
||||
cd ./out
|
||||
$DIR/apalache-tests/scripts/parse-logs.py --human .
|
||||
```
|
||||
|
||||
All lines in `results.csv` should report `Deadlock`, which means that the algorithm
|
||||
has terminated and no invariant violation was found.
|
||||
|
||||
Similar to [004bmc-apalache-ok.csv](verification/004bmc-apalache-ok.csv),
|
||||
file [005bmc-apalache-error.csv](verification/005bmc-apalache-error.csv) specifies
|
||||
the set of experiments that should result in counterexamples:
|
||||
|
||||
```sh
|
||||
$DIR/apalache-tests/scripts/mk-run.py --memlimit 28 005bmc-apalache-error.csv $DIR/apalache . out
|
||||
./out/run-all.sh
|
||||
```
|
||||
|
||||
All lines in `results.csv` should report `Error`.
|
||||
|
||||
The detailed experimental results are to be added soon.
|
||||
|
||||
## Accountability
|
||||
|
||||
The [English specification](attacks/isolate-attackers_002_reviewed.md)
|
||||
defines the protocol that is executed on a full node upon receiving attack [evidence](detection/detection_003_reviewed.md#tmbc-lc-evidence-data1) from a lightclient. In particular, the protocol handles three types of attacks
|
||||
|
||||
- lunatic
|
||||
- equivocation
|
||||
- amnesia
|
||||
|
||||
We discussed in the [last part](attacks/isolate-attackers_002_reviewed.md#Part-III---Completeness) of the English specification
|
||||
that the non-lunatic cases are defined by having the same validator set in the conflicting blocks. For these cases,
|
||||
computer-aided analysis of [Tendermint Consensus in TLA+](./accountability/README.md) shows that equivocation and amnesia capture all non-lunatic attacks.
|
||||
|
||||
The [TLA+ specification](attacks/Isolation_001_draft.tla)
|
||||
is a formal description of the
|
||||
protocol, including the safety property, which can be model checked with Apalache.
|
||||
|
||||
Similar to the other specifications, [MC_5_3.tla](attacks/MC_5_3.tla) contains concrete parameters to run the model checker. The specification can be checked within seconds.
|
||||
|
||||
[tendermint-accountability](./accountability/README.md)
|
||||
|
||||
13
spec/light-client/accountability/001indinv-apalache.csv
Normal file
@@ -0,0 +1,13 @@
|
||||
no,filename,tool,timeout,init,inv,next,args
|
||||
1,MC_n4_f1.tla,apalache,10h,TypedInv,TypedInv,,--length=1 --cinit=ConstInit
|
||||
2,MC_n4_f2.tla,apalache,10h,TypedInv,TypedInv,,--length=1 --cinit=ConstInit
|
||||
3,MC_n5_f1.tla,apalache,10h,TypedInv,TypedInv,,--length=1 --cinit=ConstInit
|
||||
4,MC_n5_f2.tla,apalache,10h,TypedInv,TypedInv,,--length=1 --cinit=ConstInit
|
||||
5,MC_n4_f1.tla,apalache,20h,Init,TypedInv,,--length=0 --cinit=ConstInit
|
||||
6,MC_n4_f2.tla,apalache,20h,Init,TypedInv,,--length=0 --cinit=ConstInit
|
||||
7,MC_n5_f1.tla,apalache,20h,Init,TypedInv,,--length=0 --cinit=ConstInit
|
||||
8,MC_n5_f2.tla,apalache,20h,Init,TypedInv,,--length=0 --cinit=ConstInit
|
||||
9,MC_n4_f1.tla,apalache,20h,TypedInv,Agreement,,--length=0 --cinit=ConstInit
|
||||
10,MC_n4_f2.tla,apalache,20h,TypedInv,Accountability,,--length=0 --cinit=ConstInit
|
||||
11,MC_n5_f1.tla,apalache,20h,TypedInv,Agreement,,--length=0 --cinit=ConstInit
|
||||
12,MC_n5_f2.tla,apalache,20h,TypedInv,Accountability,,--length=0 --cinit=ConstInit
|
||||
|
22
spec/light-client/accountability/MC_n4_f1.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n4_f1 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1", "c2", "c3"},
|
||||
Faulty <- {"f1"},
|
||||
N <- 4,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
22
spec/light-client/accountability/MC_n4_f2.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n4_f2 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1", "c2"},
|
||||
Faulty <- {"f3", "f4"},
|
||||
N <- 4,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
40
spec/light-client/accountability/MC_n4_f2_amnesia.tla
Normal file
@@ -0,0 +1,40 @@
|
||||
---------------------- MODULE MC_n4_f2_amnesia -------------------------------
|
||||
EXTENDS Sequences
|
||||
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
\* the variable declared in TendermintAccTrace3
|
||||
VARIABLE
|
||||
toReplay
|
||||
|
||||
\* old apalache annotations, fix with the new release
|
||||
a <: b == a
|
||||
|
||||
INSTANCE TendermintAccTrace_004_draft WITH
|
||||
Corr <- {"c1", "c2"},
|
||||
Faulty <- {"f3", "f4"},
|
||||
N <- 4,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2,
|
||||
Trace <- <<
|
||||
"UponProposalInPropose",
|
||||
"UponProposalInPrevoteOrCommitAndPrevote",
|
||||
"UponProposalInPrecommitNoDecision",
|
||||
"OnRoundCatchup",
|
||||
"UponProposalInPropose",
|
||||
"UponProposalInPrevoteOrCommitAndPrevote",
|
||||
"UponProposalInPrecommitNoDecision"
|
||||
>> <: Seq(STRING)
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
22
spec/light-client/accountability/MC_n4_f3.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n4_f3 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1"},
|
||||
Faulty <- {"f2", "f3", "f4"},
|
||||
N <- 4,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
22
spec/light-client/accountability/MC_n5_f1.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n5_f1 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1", "c2", "c3", "c4"},
|
||||
Faulty <- {"f5"},
|
||||
N <- 5,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
22
spec/light-client/accountability/MC_n5_f2.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n5_f2 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1", "c2", "c3"},
|
||||
Faulty <- {"f4", "f5"},
|
||||
N <- 5,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
22
spec/light-client/accountability/MC_n6_f1.tla
Normal file
@@ -0,0 +1,22 @@
|
||||
----------------------------- MODULE MC_n6_f1 -------------------------------
|
||||
CONSTANT Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
\* the variables declared in TendermintAcc3
|
||||
VARIABLES
|
||||
round, step, decision, lockedValue, lockedRound, validValue, validRound,
|
||||
msgsPropose, msgsPrevote, msgsPrecommit, evidence, action
|
||||
|
||||
INSTANCE TendermintAccDebug_004_draft WITH
|
||||
Corr <- {"c1", "c2", "c3", "c4", "c5"},
|
||||
Faulty <- {"f6"},
|
||||
N <- 4,
|
||||
T <- 1,
|
||||
ValidValues <- { "v0", "v1" },
|
||||
InvalidValues <- {"v2"},
|
||||
MaxRound <- 2
|
||||
|
||||
\* run Apalache with --cinit=ConstInit
|
||||
ConstInit == \* the proposer is arbitrary -- works for safety
|
||||
Proposer \in [Rounds -> AllProcs]
|
||||
|
||||
=============================================================================
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
order: 1
|
||||
parent:
|
||||
title: Accountability
|
||||
order: 4
|
||||
---
|
||||
|
||||
# Fork accountability
|
||||
|
||||
## Problem Statement
|
||||
@@ -8,8 +15,7 @@ Tendermint consensus guarantees the following specifications for all heights:
|
||||
* validity -- the decided block satisfies the predefined predicate *valid()*.
|
||||
* termination -- all correct full nodes eventually decide,
|
||||
|
||||
if the
|
||||
faulty validators have less than 1/3 of voting power in the current validator set. In the case where this assumption
|
||||
If the faulty validators have less than 1/3 of voting power in the current validator set. In the case where this assumption
|
||||
does not hold, each of the specification may be violated.
|
||||
|
||||
The agreement property says that for a given height, any two correct validators that decide on a block for that height decide on the same block. That the block was indeed generated by the blockchain, can be verified starting from a trusted (genesis) block, and checking that all subsequent blocks are properly signed.
|
||||
105
spec/light-client/accountability/Synopsis.md
Normal file
@@ -0,0 +1,105 @@
|
||||
|
||||
# Synopsis
|
||||
|
||||
A TLA+ specification of a simplified Tendermint consensus, tuned for
|
||||
fork accountability. The simplifications are as follows:
|
||||
|
||||
- the procotol runs for one height, that is, one-shot consensus
|
||||
|
||||
- this specification focuses on safety, so timeouts are modelled with
|
||||
with non-determinism
|
||||
|
||||
- the proposer function is non-determinstic, no fairness is assumed
|
||||
|
||||
- the messages by the faulty processes are injected right in the initial states
|
||||
|
||||
- every process has the voting power of 1
|
||||
|
||||
- hashes are modelled as identity
|
||||
|
||||
Having the above assumptions in mind, the specification follows the pseudo-code
|
||||
of the Tendermint paper: <https://arxiv.org/abs/1807.04938>
|
||||
|
||||
Byzantine processes can demonstrate arbitrary behavior, including
|
||||
no communication. However, we have to show that under the collective evidence
|
||||
collected by the correct processes, at least `f+1` Byzantine processes demonstrate
|
||||
one of the following behaviors:
|
||||
|
||||
- Equivocation: a Byzantine process sends two different values
|
||||
in the same round.
|
||||
|
||||
- Amnesia: a Byzantine process locks a value, although it has locked
|
||||
another value in the past.
|
||||
|
||||
# TLA+ modules
|
||||
|
||||
- [TendermintAcc_004_draft](TendermintAcc_004_draft.tla) is the protocol
|
||||
specification,
|
||||
|
||||
- [TendermintAccInv_004_draft](TendermintAccInv_004_draft.tla) contains an
|
||||
inductive invariant for establishing the protocol safety as well as the
|
||||
forking cases,
|
||||
|
||||
- `MC_n<n>_f<f>`, e.g., [MC_n4_f1](MC_n4_f1.tla), contains fixed constants for
|
||||
model checking with the [Apalache model
|
||||
checker](https://github.com/informalsystems/apalache),
|
||||
|
||||
- [TendermintAccTrace_004_draft](TendermintAccTrace_004_draft.tla) shows how
|
||||
to restrict the execution space to a fixed sequence of actions (e.g., to
|
||||
instantiate a counterexample),
|
||||
|
||||
- [TendermintAccDebug_004_draft](TendermintAccDebug_004_draft.tla) contains
|
||||
the useful definitions for debugging the protocol specification with TLC and
|
||||
Apalache.
|
||||
|
||||
# Reasoning about fork scenarios
|
||||
|
||||
The theorem statements can be found in
|
||||
[TendermintAccInv_004_draft.tla](TendermintAccInv_004_draft.tla).
|
||||
|
||||
First, we would like to show that `TypedInv` is an inductive invariant.
|
||||
Formally, the statement looks as follows:
|
||||
|
||||
```tla
|
||||
THEOREM TypedInvIsInductive ==
|
||||
\/ FaultyQuorum
|
||||
\//\ Init => TypedInv
|
||||
/\ TypedInv /\ [Next]_vars => TypedInv'
|
||||
```
|
||||
|
||||
When over two-thirds of processes are faulty, `TypedInv` is not inductive.
|
||||
However, there is no hope to repair the protocol in this case. We run
|
||||
[Apalache](https://github.com/informalsystems/apalache) to prove this theorem
|
||||
only for fixed instances of 4 to 5 validators. Apalache does not parse theorem
|
||||
statements at the moment, so we ran Apalache using a shell script. To find a
|
||||
parameterized argument, one has to use a theorem prover, e.g., TLAPS.
|
||||
|
||||
Second, we would like to show that the invariant implies `Agreement`, that is,
|
||||
no fork, provided that less than one third of processes is faulty. By combining
|
||||
this theorem with the previous theorem, we conclude that the protocol indeed
|
||||
satisfies Agreement under the condition `LessThanThirdFaulty`.
|
||||
|
||||
```tla
|
||||
THEOREM AgreementWhenLessThanThirdFaulty ==
|
||||
LessThanThirdFaulty /\ TypedInv => Agreement
|
||||
```
|
||||
|
||||
Third, in the general case, we either have no fork, or two fork scenarios:
|
||||
|
||||
```tla
|
||||
THEOREM AgreementOrFork ==
|
||||
~FaultyQuorum /\ TypedInv => Accountability
|
||||
```
|
||||
|
||||
# Model checking results
|
||||
|
||||
Check the report on [model checking with Apalache](./results/001indinv-apalache-report.md).
|
||||
|
||||
To run the model checking experiments, use the script:
|
||||
|
||||
```console
|
||||
./run.sh
|
||||
```
|
||||
|
||||
This script assumes that the apalache build is available in
|
||||
`~/devl/apalache-unstable`.
|
||||
@@ -0,0 +1,100 @@
|
||||
------------------ MODULE TendermintAccDebug_004_draft -------------------------
|
||||
(*
|
||||
A few definitions that we use for debugging TendermintAcc3, which do not belong
|
||||
to the specification itself.
|
||||
|
||||
* Version 3. Modular and parameterized definitions.
|
||||
|
||||
Igor Konnov, 2020.
|
||||
*)
|
||||
|
||||
EXTENDS TendermintAccInv_004_draft
|
||||
|
||||
\* make them parameters?
|
||||
NFaultyProposals == 0 \* the number of injected faulty PROPOSE messages
|
||||
NFaultyPrevotes == 6 \* the number of injected faulty PREVOTE messages
|
||||
NFaultyPrecommits == 6 \* the number of injected faulty PRECOMMIT messages
|
||||
|
||||
\* Given a set of allowed messages Msgs, this operator produces a function from
|
||||
\* rounds to sets of messages.
|
||||
\* Importantly, there will be exactly k messages in the image of msgFun.
|
||||
\* We use this action to produce k faults in an initial state.
|
||||
ProduceFaults(msgFun, From, k) ==
|
||||
\E f \in [1..k -> From]:
|
||||
msgFun = [r \in Rounds |-> {m \in {f[i]: i \in 1..k}: m.round = r}]
|
||||
|
||||
\* As TLC explodes with faults, we may have initial states without faults
|
||||
InitNoFaults ==
|
||||
/\ round = [p \in Corr |-> 0]
|
||||
/\ step = [p \in Corr |-> "PROPOSE"]
|
||||
/\ decision = [p \in Corr |-> NilValue]
|
||||
/\ lockedValue = [p \in Corr |-> NilValue]
|
||||
/\ lockedRound = [p \in Corr |-> NilRound]
|
||||
/\ validValue = [p \in Corr |-> NilValue]
|
||||
/\ validRound = [p \in Corr |-> NilRound]
|
||||
/\ msgsPropose = [r \in Rounds |-> EmptyMsgSet]
|
||||
/\ msgsPrevote = [r \in Rounds |-> EmptyMsgSet]
|
||||
/\ msgsPrecommit = [r \in Rounds |-> EmptyMsgSet]
|
||||
/\ evidence = EmptyMsgSet
|
||||
|
||||
(*
|
||||
A specialized version of Init that injects NFaultyProposals proposals,
|
||||
NFaultyPrevotes prevotes, NFaultyPrecommits precommits by the faulty processes
|
||||
*)
|
||||
InitFewFaults ==
|
||||
/\ round = [p \in Corr |-> 0]
|
||||
/\ step = [p \in Corr |-> "PROPOSE"]
|
||||
/\ decision = [p \in Corr |-> NilValue]
|
||||
/\ lockedValue = [p \in Corr |-> NilValue]
|
||||
/\ lockedRound = [p \in Corr |-> NilRound]
|
||||
/\ validValue = [p \in Corr |-> NilValue]
|
||||
/\ validRound = [p \in Corr |-> NilRound]
|
||||
/\ ProduceFaults(msgsPrevote',
|
||||
SetOfMsgs([type: {"PREVOTE"}, src: Faulty, round: Rounds, id: Values]),
|
||||
NFaultyPrevotes)
|
||||
/\ ProduceFaults(msgsPrecommit',
|
||||
SetOfMsgs([type: {"PRECOMMIT"}, src: Faulty, round: Rounds, id: Values]),
|
||||
NFaultyPrecommits)
|
||||
/\ ProduceFaults(msgsPropose',
|
||||
SetOfMsgs([type: {"PROPOSAL"}, src: Faulty, round: Rounds,
|
||||
proposal: Values, validRound: Rounds \cup {NilRound}]),
|
||||
NFaultyProposals)
|
||||
/\ evidence = EmptyMsgSet
|
||||
|
||||
\* Add faults incrementally
|
||||
NextWithFaults ==
|
||||
\* either the protocol makes a step
|
||||
\/ Next
|
||||
\* or a faulty process sends a message
|
||||
\//\ UNCHANGED <<round, step, decision, lockedValue,
|
||||
lockedRound, validValue, validRound, evidence>>
|
||||
/\ \E p \in Faulty:
|
||||
\E r \in Rounds:
|
||||
\//\ UNCHANGED <<msgsPrevote, msgsPrecommit>>
|
||||
/\ \E proposal \in ValidValues \union {NilValue}:
|
||||
\E vr \in RoundsOrNil:
|
||||
BroadcastProposal(p, r, proposal, vr)
|
||||
\//\ UNCHANGED <<msgsPropose, msgsPrecommit>>
|
||||
/\ \E id \in ValidValues \union {NilValue}:
|
||||
BroadcastPrevote(p, r, id)
|
||||
\//\ UNCHANGED <<msgsPropose, msgsPrevote>>
|
||||
/\ \E id \in ValidValues \union {NilValue}:
|
||||
BroadcastPrecommit(p, r, id)
|
||||
|
||||
(******************************** PROPERTIES ***************************************)
|
||||
\* simple reachability properties to see that the spec is progressing
|
||||
NoPrevote == \A p \in Corr: step[p] /= "PREVOTE"
|
||||
|
||||
NoPrecommit == \A p \in Corr: step[p] /= "PRECOMMIT"
|
||||
|
||||
NoValidPrecommit ==
|
||||
\A r \in Rounds:
|
||||
\A m \in msgsPrecommit[r]:
|
||||
m.id = NilValue \/ m.src \in Faulty
|
||||
|
||||
NoHigherRounds == \A p \in Corr: round[p] < 1
|
||||
|
||||
NoDecision == \A p \in Corr: decision[p] = NilValue
|
||||
|
||||
=============================================================================
|
||||
|
||||
370
spec/light-client/accountability/TendermintAccInv_004_draft.tla
Normal file
@@ -0,0 +1,370 @@
|
||||
------------------- MODULE TendermintAccInv_004_draft --------------------------
|
||||
(*
|
||||
An inductive invariant for TendermintAcc3, which capture the forked
|
||||
and non-forked cases.
|
||||
|
||||
* Version 3. Modular and parameterized definitions.
|
||||
* Version 2. Bugfixes in the spec and an inductive invariant.
|
||||
|
||||
Igor Konnov, 2020.
|
||||
*)
|
||||
|
||||
EXTENDS TendermintAcc_004_draft
|
||||
|
||||
(************************** TYPE INVARIANT ***********************************)
|
||||
(* first, we define the sets of all potential messages *)
|
||||
AllProposals ==
|
||||
SetOfMsgs([type: {"PROPOSAL"},
|
||||
src: AllProcs,
|
||||
round: Rounds,
|
||||
proposal: ValuesOrNil,
|
||||
validRound: RoundsOrNil])
|
||||
|
||||
AllPrevotes ==
|
||||
SetOfMsgs([type: {"PREVOTE"},
|
||||
src: AllProcs,
|
||||
round: Rounds,
|
||||
id: ValuesOrNil])
|
||||
|
||||
AllPrecommits ==
|
||||
SetOfMsgs([type: {"PRECOMMIT"},
|
||||
src: AllProcs,
|
||||
round: Rounds,
|
||||
id: ValuesOrNil])
|
||||
|
||||
(* the standard type invariant -- importantly, it is inductive *)
|
||||
TypeOK ==
|
||||
/\ round \in [Corr -> Rounds]
|
||||
/\ step \in [Corr -> { "PROPOSE", "PREVOTE", "PRECOMMIT", "DECIDED" }]
|
||||
/\ decision \in [Corr -> ValidValues \union {NilValue}]
|
||||
/\ lockedValue \in [Corr -> ValidValues \union {NilValue}]
|
||||
/\ lockedRound \in [Corr -> RoundsOrNil]
|
||||
/\ validValue \in [Corr -> ValidValues \union {NilValue}]
|
||||
/\ validRound \in [Corr -> RoundsOrNil]
|
||||
/\ msgsPropose \in [Rounds -> SUBSET AllProposals]
|
||||
/\ BenignRoundsInMessages(msgsPropose)
|
||||
/\ msgsPrevote \in [Rounds -> SUBSET AllPrevotes]
|
||||
/\ BenignRoundsInMessages(msgsPrevote)
|
||||
/\ msgsPrecommit \in [Rounds -> SUBSET AllPrecommits]
|
||||
/\ BenignRoundsInMessages(msgsPrecommit)
|
||||
/\ evidence \in SUBSET (AllProposals \union AllPrevotes \union AllPrecommits)
|
||||
/\ action \in {
|
||||
"Init",
|
||||
"InsertProposal",
|
||||
"UponProposalInPropose",
|
||||
"UponProposalInProposeAndPrevote",
|
||||
"UponQuorumOfPrevotesAny",
|
||||
"UponProposalInPrevoteOrCommitAndPrevote",
|
||||
"UponQuorumOfPrecommitsAny",
|
||||
"UponProposalInPrecommitNoDecision",
|
||||
"OnTimeoutPropose",
|
||||
"OnQuorumOfNilPrevotes",
|
||||
"OnRoundCatchup"
|
||||
}
|
||||
|
||||
(************************** INDUCTIVE INVARIANT *******************************)
|
||||
EvidenceContainsMessages ==
|
||||
\* evidence contains only the messages from:
|
||||
\* msgsPropose, msgsPrevote, and msgsPrecommit
|
||||
\A m \in evidence:
|
||||
LET r == m.round
|
||||
t == m.type
|
||||
IN
|
||||
CASE t = "PROPOSAL" -> m \in msgsPropose[r]
|
||||
[] t = "PREVOTE" -> m \in msgsPrevote[r]
|
||||
[] OTHER -> m \in msgsPrecommit[r]
|
||||
|
||||
NoFutureMessagesForLargerRounds(p) ==
|
||||
\* a correct process does not send messages for the future rounds
|
||||
\A r \in { rr \in Rounds: rr > round[p] }:
|
||||
/\ \A m \in msgsPropose[r]: m.src /= p
|
||||
/\ \A m \in msgsPrevote[r]: m.src /= p
|
||||
/\ \A m \in msgsPrecommit[r]: m.src /= p
|
||||
|
||||
NoFutureMessagesForCurrentRound(p) ==
|
||||
\* a correct process does not send messages in the future
|
||||
LET r == round[p] IN
|
||||
/\ Proposer[r] = p \/ \A m \in msgsPropose[r]: m.src /= p
|
||||
/\ \/ step[p] \in {"PREVOTE", "PRECOMMIT", "DECIDED"}
|
||||
\/ \A m \in msgsPrevote[r]: m.src /= p
|
||||
/\ \/ step[p] \in {"PRECOMMIT", "DECIDED"}
|
||||
\/ \A m \in msgsPrecommit[r]: m.src /= p
|
||||
|
||||
\* the correct processes never send future messages
|
||||
AllNoFutureMessagesSent ==
|
||||
\A p \in Corr:
|
||||
/\ NoFutureMessagesForCurrentRound(p)
|
||||
/\ NoFutureMessagesForLargerRounds(p)
|
||||
|
||||
\* a correct process in the PREVOTE state has sent a PREVOTE message
|
||||
IfInPrevoteThenSentPrevote(p) ==
|
||||
step[p] = "PREVOTE" =>
|
||||
\E m \in msgsPrevote[round[p]]:
|
||||
/\ m.id \in ValidValues \cup { NilValue }
|
||||
/\ m.src = p
|
||||
|
||||
AllIfInPrevoteThenSentPrevote ==
|
||||
\A p \in Corr: IfInPrevoteThenSentPrevote(p)
|
||||
|
||||
\* a correct process in the PRECOMMIT state has sent a PRECOMMIT message
|
||||
IfInPrecommitThenSentPrecommit(p) ==
|
||||
step[p] = "PRECOMMIT" =>
|
||||
\E m \in msgsPrecommit[round[p]]:
|
||||
/\ m.id \in ValidValues \cup { NilValue }
|
||||
/\ m.src = p
|
||||
|
||||
AllIfInPrecommitThenSentPrecommit ==
|
||||
\A p \in Corr: IfInPrecommitThenSentPrecommit(p)
|
||||
|
||||
\* a process in the PRECOMMIT state has sent a PRECOMMIT message
|
||||
IfInDecidedThenValidDecision(p) ==
|
||||
step[p] = "DECIDED" <=> decision[p] \in ValidValues
|
||||
|
||||
AllIfInDecidedThenValidDecision ==
|
||||
\A p \in Corr: IfInDecidedThenValidDecision(p)
|
||||
|
||||
\* a decided process should have received a proposal on its decision
|
||||
IfInDecidedThenReceivedProposal(p) ==
|
||||
step[p] = "DECIDED" =>
|
||||
\E r \in Rounds: \* r is not necessarily round[p]
|
||||
/\ \E m \in msgsPropose[r] \intersect evidence:
|
||||
/\ m.src = Proposer[r]
|
||||
/\ m.proposal = decision[p]
|
||||
\* not inductive: /\ m.src \in Corr => (m.validRound <= r)
|
||||
|
||||
AllIfInDecidedThenReceivedProposal ==
|
||||
\A p \in Corr:
|
||||
IfInDecidedThenReceivedProposal(p)
|
||||
|
||||
\* a decided process has received two-thirds of precommit messages
|
||||
IfInDecidedThenReceivedTwoThirds(p) ==
|
||||
step[p] = "DECIDED" =>
|
||||
\E r \in Rounds:
|
||||
LET PV ==
|
||||
{ m \in msgsPrecommit[r] \intersect evidence: m.id = decision[p] }
|
||||
IN
|
||||
Cardinality(PV) >= THRESHOLD2
|
||||
|
||||
AllIfInDecidedThenReceivedTwoThirds ==
|
||||
\A p \in Corr:
|
||||
IfInDecidedThenReceivedTwoThirds(p)
|
||||
|
||||
\* for a round r, there is proposal by the round proposer for a valid round vr
|
||||
ProposalInRound(r, proposedVal, vr) ==
|
||||
\E m \in msgsPropose[r]:
|
||||
/\ m.src = Proposer[r]
|
||||
/\ m.proposal = proposedVal
|
||||
/\ m.validRound = vr
|
||||
|
||||
TwoThirdsPrevotes(vr, v) ==
|
||||
LET PV == { mm \in msgsPrevote[vr] \intersect evidence: mm.id = v } IN
|
||||
Cardinality(PV) >= THRESHOLD2
|
||||
|
||||
\* if a process sends a PREVOTE, then there are three possibilities:
|
||||
\* 1) the process is faulty, 2) the PREVOTE cotains Nil,
|
||||
\* 3) there is a proposal in an earlier (valid) round and two thirds of PREVOTES
|
||||
IfSentPrevoteThenReceivedProposalOrTwoThirds(r) ==
|
||||
\A mpv \in msgsPrevote[r]:
|
||||
\/ mpv.src \in Faulty
|
||||
\* lockedRound and lockedValue is beyond my comprehension
|
||||
\/ mpv.id = NilValue
|
||||
\//\ mpv.src \in Corr
|
||||
/\ mpv.id /= NilValue
|
||||
/\ \/ ProposalInRound(r, mpv.id, NilRound)
|
||||
\/ \E vr \in { rr \in Rounds: rr < r }:
|
||||
/\ ProposalInRound(r, mpv.id, vr)
|
||||
/\ TwoThirdsPrevotes(vr, mpv.id)
|
||||
|
||||
AllIfSentPrevoteThenReceivedProposalOrTwoThirds ==
|
||||
\A r \in Rounds:
|
||||
IfSentPrevoteThenReceivedProposalOrTwoThirds(r)
|
||||
|
||||
\* if a correct process has sent a PRECOMMIT, then there are two thirds,
|
||||
\* either on a valid value, or a nil value
|
||||
IfSentPrecommitThenReceivedTwoThirds ==
|
||||
\A r \in Rounds:
|
||||
\A mpc \in msgsPrecommit[r]:
|
||||
mpc.src \in Corr =>
|
||||
\/ /\ mpc.id \in ValidValues
|
||||
/\ LET PV ==
|
||||
{ m \in msgsPrevote[r] \intersect evidence: m.id = mpc.id }
|
||||
IN
|
||||
Cardinality(PV) >= THRESHOLD2
|
||||
\/ /\ mpc.id = NilValue
|
||||
/\ Cardinality(msgsPrevote[r]) >= THRESHOLD2
|
||||
|
||||
\* if a correct process has sent a precommit message in a round, it should
|
||||
\* have sent a prevote
|
||||
IfSentPrecommitThenSentPrevote ==
|
||||
\A r \in Rounds:
|
||||
\A mpc \in msgsPrecommit[r]:
|
||||
mpc.src \in Corr =>
|
||||
\E m \in msgsPrevote[r]:
|
||||
m.src = mpc.src
|
||||
|
||||
\* there is a locked round if a only if there is a locked value
|
||||
LockedRoundIffLockedValue(p) ==
|
||||
(lockedRound[p] = NilRound) <=> (lockedValue[p] = NilValue)
|
||||
|
||||
AllLockedRoundIffLockedValue ==
|
||||
\A p \in Corr:
|
||||
LockedRoundIffLockedValue(p)
|
||||
|
||||
\* when a process locked a round, it must have sent a precommit on the locked value.
|
||||
IfLockedRoundThenSentCommit(p) ==
|
||||
lockedRound[p] /= NilRound
|
||||
=> \E r \in { rr \in Rounds: rr <= round[p] }:
|
||||
\E m \in msgsPrecommit[r]:
|
||||
m.src = p /\ m.id = lockedValue[p]
|
||||
|
||||
AllIfLockedRoundThenSentCommit ==
|
||||
\A p \in Corr:
|
||||
IfLockedRoundThenSentCommit(p)
|
||||
|
||||
\* a process always locks the latest round, for which it has sent a PRECOMMIT
|
||||
LatestPrecommitHasLockedRound(p) ==
|
||||
LET pPrecommits ==
|
||||
{mm \in UNION { msgsPrecommit[r]: r \in Rounds }: mm.src = p /\ mm.id /= NilValue }
|
||||
IN
|
||||
pPrecommits /= {} <: {MT}
|
||||
=> LET latest ==
|
||||
CHOOSE m \in pPrecommits:
|
||||
\A m2 \in pPrecommits:
|
||||
m2.round <= m.round
|
||||
IN
|
||||
/\ lockedRound[p] = latest.round
|
||||
/\ lockedValue[p] = latest.id
|
||||
|
||||
AllLatestPrecommitHasLockedRound ==
|
||||
\A p \in Corr:
|
||||
LatestPrecommitHasLockedRound(p)
|
||||
|
||||
\* Every correct process sends only one value or NilValue.
|
||||
\* This test has quantifier alternation -- a threat to all decision procedures.
|
||||
\* Luckily, the sets Corr and ValidValues are small.
|
||||
NoEquivocationByCorrect(r, msgs) ==
|
||||
\A p \in Corr:
|
||||
\E v \in ValidValues \union {NilValue}:
|
||||
\A m \in msgs[r]:
|
||||
\/ m.src /= p
|
||||
\/ m.id = v
|
||||
|
||||
\* a proposer nevers sends two values
|
||||
ProposalsByProposer(r, msgs) ==
|
||||
\* if the proposer is not faulty, it sends only one value
|
||||
\E v \in ValidValues:
|
||||
\A m \in msgs[r]:
|
||||
\/ m.src \in Faulty
|
||||
\/ m.src = Proposer[r] /\ m.proposal = v
|
||||
|
||||
AllNoEquivocationByCorrect ==
|
||||
\A r \in Rounds:
|
||||
/\ ProposalsByProposer(r, msgsPropose)
|
||||
/\ NoEquivocationByCorrect(r, msgsPrevote)
|
||||
/\ NoEquivocationByCorrect(r, msgsPrecommit)
|
||||
|
||||
\* construct the set of the message senders
|
||||
Senders(M) == { m.src: m \in M }
|
||||
|
||||
\* The final piece by Josef Widder:
|
||||
\* if T + 1 processes precommit on the same value in a round,
|
||||
\* then in the future rounds there are less than 2T + 1 prevotes for another value
|
||||
PrecommitsLockValue ==
|
||||
\A r \in Rounds:
|
||||
\A v \in ValidValues \union {NilValue}:
|
||||
\/ LET Precommits == {m \in msgsPrecommit[r]: m.id = v}
|
||||
IN
|
||||
Cardinality(Senders(Precommits)) < THRESHOLD1
|
||||
\/ \A fr \in { rr \in Rounds: rr > r }: \* future rounds
|
||||
\A w \in (ValuesOrNil) \ {v}:
|
||||
LET Prevotes == {m \in msgsPrevote[fr]: m.id = w}
|
||||
IN
|
||||
Cardinality(Senders(Prevotes)) < THRESHOLD2
|
||||
|
||||
\* a combination of all lemmas
|
||||
Inv ==
|
||||
/\ EvidenceContainsMessages
|
||||
/\ AllNoFutureMessagesSent
|
||||
/\ AllIfInPrevoteThenSentPrevote
|
||||
/\ AllIfInPrecommitThenSentPrecommit
|
||||
/\ AllIfInDecidedThenReceivedProposal
|
||||
/\ AllIfInDecidedThenReceivedTwoThirds
|
||||
/\ AllIfInDecidedThenValidDecision
|
||||
/\ AllLockedRoundIffLockedValue
|
||||
/\ AllIfLockedRoundThenSentCommit
|
||||
/\ AllLatestPrecommitHasLockedRound
|
||||
/\ AllIfSentPrevoteThenReceivedProposalOrTwoThirds
|
||||
/\ IfSentPrecommitThenSentPrevote
|
||||
/\ IfSentPrecommitThenReceivedTwoThirds
|
||||
/\ AllNoEquivocationByCorrect
|
||||
/\ PrecommitsLockValue
|
||||
|
||||
\* this is the inductive invariant we like to check
|
||||
TypedInv == TypeOK /\ Inv
|
||||
|
||||
\* UNUSED FOR SAFETY
|
||||
ValidRoundNotSmallerThanLockedRound(p) ==
|
||||
validRound[p] >= lockedRound[p]
|
||||
|
||||
\* UNUSED FOR SAFETY
|
||||
ValidRoundIffValidValue(p) ==
|
||||
(validRound[p] = NilRound) <=> (validValue[p] = NilValue)
|
||||
|
||||
\* UNUSED FOR SAFETY
|
||||
AllValidRoundIffValidValue ==
|
||||
\A p \in Corr: ValidRoundIffValidValue(p)
|
||||
|
||||
\* if validRound is defined, then there are two-thirds of PREVOTEs
|
||||
IfValidRoundThenTwoThirds(p) ==
|
||||
\/ validRound[p] = NilRound
|
||||
\/ LET PV == { m \in msgsPrevote[validRound[p]]: m.id = validValue[p] } IN
|
||||
Cardinality(PV) >= THRESHOLD2
|
||||
|
||||
\* UNUSED FOR SAFETY
|
||||
AllIfValidRoundThenTwoThirds ==
|
||||
\A p \in Corr: IfValidRoundThenTwoThirds(p)
|
||||
|
||||
\* a valid round can be only set to a valid value that was proposed earlier
|
||||
IfValidRoundThenProposal(p) ==
|
||||
\/ validRound[p] = NilRound
|
||||
\/ \E m \in msgsPropose[validRound[p]]:
|
||||
m.proposal = validValue[p]
|
||||
|
||||
\* UNUSED FOR SAFETY
|
||||
AllIfValidRoundThenProposal ==
|
||||
\A p \in Corr: IfValidRoundThenProposal(p)
|
||||
|
||||
(******************************** THEOREMS ***************************************)
|
||||
(* Under this condition, the faulty processes can decide alone *)
|
||||
FaultyQuorum == Cardinality(Faulty) >= THRESHOLD2
|
||||
|
||||
(* The standard condition of the Tendermint security model *)
|
||||
LessThanThirdFaulty == N > 3 * T /\ Cardinality(Faulty) <= T
|
||||
|
||||
(*
|
||||
TypedInv is an inductive invariant, provided that there is no faulty quorum.
|
||||
We run Apalache to prove this theorem only for fixed instances of 4 to 10 processes.
|
||||
(We run Apalache manually, as it does not parse theorem statements at the moment.)
|
||||
To get a parameterized argument, one has to use a theorem prover, e.g., TLAPS.
|
||||
*)
|
||||
THEOREM TypedInvIsInductive ==
|
||||
\/ FaultyQuorum \* if there are 2 * T + 1 faulty processes, we give up
|
||||
\//\ Init => TypedInv
|
||||
/\ TypedInv /\ [Next]_vars => TypedInv'
|
||||
|
||||
(*
|
||||
There should be no fork, when there are less than 1/3 faulty processes.
|
||||
*)
|
||||
THEOREM AgreementWhenLessThanThirdFaulty ==
|
||||
LessThanThirdFaulty /\ TypedInv => Agreement
|
||||
|
||||
(*
|
||||
In a more general case, when there are less than 2/3 faulty processes,
|
||||
there is either Agreement (no fork), or two scenarios exist:
|
||||
equivocation by Faulty, or amnesia by Faulty.
|
||||
*)
|
||||
THEOREM AgreementOrFork ==
|
||||
~FaultyQuorum /\ TypedInv => Accountability
|
||||
|
||||
=============================================================================
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
------------------ MODULE TendermintAccTrace_004_draft -------------------------
|
||||
(*
|
||||
When Apalache is running too slow and we have an idea of a counterexample,
|
||||
we use this module to restrict the behaviors only to certain actions.
|
||||
Once the whole trace is replayed, the system deadlocks.
|
||||
|
||||
Version 1.
|
||||
|
||||
Igor Konnov, 2020.
|
||||
*)
|
||||
|
||||
EXTENDS Sequences, Apalache, TendermintAcc_004_draft
|
||||
|
||||
\* a sequence of action names that should appear in the given order,
|
||||
\* excluding "Init"
|
||||
CONSTANT Trace
|
||||
|
||||
VARIABLE toReplay
|
||||
|
||||
TraceInit ==
|
||||
/\ toReplay = Trace
|
||||
/\ action' := "Init"
|
||||
/\ Init
|
||||
|
||||
TraceNext ==
|
||||
/\ Len(toReplay) > 0
|
||||
/\ toReplay' = Tail(toReplay)
|
||||
\* Here is the trick. We restrict the action to the expected one,
|
||||
\* so the other actions will be pruned
|
||||
/\ action' := Head(toReplay)
|
||||
/\ Next
|
||||
|
||||
================================================================================
|
||||
474
spec/light-client/accountability/TendermintAcc_004_draft.tla
Normal file
@@ -0,0 +1,474 @@
|
||||
-------------------- MODULE TendermintAcc_004_draft ---------------------------
|
||||
(*
|
||||
A TLA+ specification of a simplified Tendermint consensus, tuned for
|
||||
fork accountability. The simplifications are as follows:
|
||||
|
||||
- the protocol runs for one height, that is, it is one-shot consensus
|
||||
|
||||
- this specification focuses on safety, so timeouts are modelled
|
||||
with non-determinism
|
||||
|
||||
- the proposer function is non-determinstic, no fairness is assumed
|
||||
|
||||
- the messages by the faulty processes are injected right in the initial states
|
||||
|
||||
- every process has the voting power of 1
|
||||
|
||||
- hashes are modelled as identity
|
||||
|
||||
Having the above assumptions in mind, the specification follows the pseudo-code
|
||||
of the Tendermint paper: https://arxiv.org/abs/1807.04938
|
||||
|
||||
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:
|
||||
|
||||
- Equivocation: a Byzantine process may send two different values
|
||||
in the same round.
|
||||
|
||||
- Amnesia: a Byzantine process may lock a value without unlocking
|
||||
the previous value that it has locked in the past.
|
||||
|
||||
* Version 4. Remove defective processes, fix bugs, collect global evidence.
|
||||
* Version 3. Modular and parameterized definitions.
|
||||
* Version 2. Bugfixes in the spec and an inductive invariant.
|
||||
* Version 1. A preliminary specification.
|
||||
|
||||
Zarko Milosevic, Igor Konnov, Informal Systems, 2019-2020.
|
||||
*)
|
||||
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
(********************* PROTOCOL PARAMETERS **********************************)
|
||||
CONSTANTS
|
||||
Corr, \* the set of correct processes
|
||||
Faulty, \* the set of Byzantine processes, may be empty
|
||||
N, \* the total number of processes: correct, defective, and Byzantine
|
||||
T, \* an upper bound on the number of Byzantine processes
|
||||
ValidValues, \* the set of valid values, proposed both by correct and faulty
|
||||
InvalidValues, \* the set of invalid values, never proposed by the correct ones
|
||||
MaxRound, \* the maximal round number
|
||||
Proposer \* the proposer function from 0..NRounds to 1..N
|
||||
|
||||
ASSUME(N = Cardinality(Corr \union Faulty))
|
||||
|
||||
(*************************** DEFINITIONS ************************************)
|
||||
AllProcs == Corr \union Faulty \* the set of all processes
|
||||
Rounds == 0..MaxRound \* the set of potential rounds
|
||||
NilRound == -1 \* a special value to denote a nil round, outside of Rounds
|
||||
RoundsOrNil == Rounds \union {NilRound}
|
||||
Values == ValidValues \union InvalidValues \* the set of all values
|
||||
NilValue == "None" \* a special value for a nil round, outside of Values
|
||||
ValuesOrNil == Values \union {NilValue}
|
||||
|
||||
\* a value hash is modeled as identity
|
||||
Id(v) == v
|
||||
|
||||
\* The validity predicate
|
||||
IsValid(v) == v \in ValidValues
|
||||
|
||||
\* the two thresholds that are used in the algorithm
|
||||
THRESHOLD1 == T + 1 \* at least one process is not faulty
|
||||
THRESHOLD2 == 2 * T + 1 \* a quorum when having N > 3 * T
|
||||
|
||||
(********************* TYPE ANNOTATIONS FOR APALACHE **************************)
|
||||
\* the operator for type annotations
|
||||
a <: b == a
|
||||
|
||||
\* the type of message records
|
||||
MT == [type |-> STRING, src |-> STRING, round |-> Int,
|
||||
proposal |-> STRING, validRound |-> Int, id |-> STRING]
|
||||
|
||||
\* a type annotation for a message
|
||||
AsMsg(m) == m <: MT
|
||||
\* a type annotation for a set of messages
|
||||
SetOfMsgs(S) == S <: {MT}
|
||||
\* a type annotation for an empty set of messages
|
||||
EmptyMsgSet == SetOfMsgs({})
|
||||
|
||||
(********************* PROTOCOL STATE VARIABLES ******************************)
|
||||
VARIABLES
|
||||
round, \* a process round number: Corr -> Rounds
|
||||
step, \* a process step: Corr -> { "PROPOSE", "PREVOTE", "PRECOMMIT", "DECIDED" }
|
||||
decision, \* process decision: Corr -> ValuesOrNil
|
||||
lockedValue, \* a locked value: Corr -> ValuesOrNil
|
||||
lockedRound, \* a locked round: Corr -> RoundsOrNil
|
||||
validValue, \* a valid value: Corr -> ValuesOrNil
|
||||
validRound \* a valid round: Corr -> RoundsOrNil
|
||||
|
||||
\* book-keeping variables
|
||||
VARIABLES
|
||||
msgsPropose, \* PROPOSE messages broadcast in the system, Rounds -> Messages
|
||||
msgsPrevote, \* PREVOTE messages broadcast in the system, Rounds -> Messages
|
||||
msgsPrecommit, \* PRECOMMIT messages broadcast in the system, Rounds -> Messages
|
||||
evidence, \* the messages that were used by the correct processes to make transitions
|
||||
action \* we use this variable to see which action was taken
|
||||
|
||||
(* to see a type invariant, check TendermintAccInv3 *)
|
||||
|
||||
\* a handy definition used in UNCHANGED
|
||||
vars == <<round, step, decision, lockedValue, lockedRound,
|
||||
validValue, validRound, evidence, msgsPropose, msgsPrevote, msgsPrecommit>>
|
||||
|
||||
(********************* PROTOCOL INITIALIZATION ******************************)
|
||||
FaultyProposals(r) ==
|
||||
SetOfMsgs([type: {"PROPOSAL"}, src: Faulty,
|
||||
round: {r}, proposal: Values, validRound: RoundsOrNil])
|
||||
|
||||
AllFaultyProposals ==
|
||||
SetOfMsgs([type: {"PROPOSAL"}, src: Faulty,
|
||||
round: Rounds, proposal: Values, validRound: RoundsOrNil])
|
||||
|
||||
FaultyPrevotes(r) ==
|
||||
SetOfMsgs([type: {"PREVOTE"}, src: Faulty, round: {r}, id: Values])
|
||||
|
||||
AllFaultyPrevotes ==
|
||||
SetOfMsgs([type: {"PREVOTE"}, src: Faulty, round: Rounds, id: Values])
|
||||
|
||||
FaultyPrecommits(r) ==
|
||||
SetOfMsgs([type: {"PRECOMMIT"}, src: Faulty, round: {r}, id: Values])
|
||||
|
||||
AllFaultyPrecommits ==
|
||||
SetOfMsgs([type: {"PRECOMMIT"}, src: Faulty, round: Rounds, id: Values])
|
||||
|
||||
BenignRoundsInMessages(msgfun) ==
|
||||
\* the message function never contains a message for a wrong round
|
||||
\A r \in Rounds:
|
||||
\A m \in msgfun[r]:
|
||||
r = m.round
|
||||
|
||||
\* The initial states of the protocol. Some faults can be in the system already.
|
||||
Init ==
|
||||
/\ round = [p \in Corr |-> 0]
|
||||
/\ step = [p \in Corr |-> "PROPOSE"]
|
||||
/\ decision = [p \in Corr |-> NilValue]
|
||||
/\ lockedValue = [p \in Corr |-> NilValue]
|
||||
/\ lockedRound = [p \in Corr |-> NilRound]
|
||||
/\ validValue = [p \in Corr |-> NilValue]
|
||||
/\ validRound = [p \in Corr |-> NilRound]
|
||||
/\ msgsPropose \in [Rounds -> SUBSET AllFaultyProposals]
|
||||
/\ msgsPrevote \in [Rounds -> SUBSET AllFaultyPrevotes]
|
||||
/\ msgsPrecommit \in [Rounds -> SUBSET AllFaultyPrecommits]
|
||||
/\ BenignRoundsInMessages(msgsPropose)
|
||||
/\ BenignRoundsInMessages(msgsPrevote)
|
||||
/\ BenignRoundsInMessages(msgsPrecommit)
|
||||
/\ evidence = EmptyMsgSet
|
||||
/\ action' = "Init"
|
||||
|
||||
(************************ MESSAGE PASSING ********************************)
|
||||
BroadcastProposal(pSrc, pRound, pProposal, pValidRound) ==
|
||||
LET newMsg ==
|
||||
AsMsg([type |-> "PROPOSAL", src |-> pSrc, round |-> pRound,
|
||||
proposal |-> pProposal, validRound |-> pValidRound])
|
||||
IN
|
||||
msgsPropose' = [msgsPropose EXCEPT ![pRound] = msgsPropose[pRound] \union {newMsg}]
|
||||
|
||||
BroadcastPrevote(pSrc, pRound, pId) ==
|
||||
LET newMsg == AsMsg([type |-> "PREVOTE",
|
||||
src |-> pSrc, round |-> pRound, id |-> pId])
|
||||
IN
|
||||
msgsPrevote' = [msgsPrevote EXCEPT ![pRound] = msgsPrevote[pRound] \union {newMsg}]
|
||||
|
||||
BroadcastPrecommit(pSrc, pRound, pId) ==
|
||||
LET newMsg == AsMsg([type |-> "PRECOMMIT",
|
||||
src |-> pSrc, round |-> pRound, id |-> pId])
|
||||
IN
|
||||
msgsPrecommit' = [msgsPrecommit EXCEPT ![pRound] = msgsPrecommit[pRound] \union {newMsg}]
|
||||
|
||||
|
||||
(********************* PROTOCOL TRANSITIONS ******************************)
|
||||
\* lines 12-13
|
||||
StartRound(p, r) ==
|
||||
/\ step[p] /= "DECIDED" \* a decided process does not participate in consensus
|
||||
/\ round' = [round EXCEPT ![p] = r]
|
||||
/\ step' = [step EXCEPT ![p] = "PROPOSE"]
|
||||
|
||||
\* lines 14-19, a proposal may be sent later
|
||||
InsertProposal(p) ==
|
||||
LET r == round[p] IN
|
||||
/\ p = Proposer[r]
|
||||
/\ step[p] = "PROPOSE"
|
||||
\* if the proposer is sending a proposal, then there are no other proposals
|
||||
\* by the correct processes for the same round
|
||||
/\ \A m \in msgsPropose[r]: m.src /= p
|
||||
/\ \E v \in ValidValues:
|
||||
LET proposal == IF validValue[p] /= NilValue THEN validValue[p] ELSE v IN
|
||||
BroadcastProposal(p, round[p], proposal, validRound[p])
|
||||
/\ UNCHANGED <<evidence, round, decision, lockedValue, lockedRound,
|
||||
validValue, step, validRound, msgsPrevote, msgsPrecommit>>
|
||||
/\ action' = "InsertProposal"
|
||||
|
||||
\* lines 22-27
|
||||
UponProposalInPropose(p) ==
|
||||
\E v \in Values:
|
||||
/\ step[p] = "PROPOSE" (* line 22 *)
|
||||
/\ LET msg ==
|
||||
AsMsg([type |-> "PROPOSAL", src |-> Proposer[round[p]],
|
||||
round |-> round[p], proposal |-> v, validRound |-> NilRound]) IN
|
||||
/\ msg \in msgsPropose[round[p]] \* line 22
|
||||
/\ evidence' = {msg} \union evidence
|
||||
/\ LET mid == (* line 23 *)
|
||||
IF IsValid(v) /\ (lockedRound[p] = NilRound \/ lockedValue[p] = v)
|
||||
THEN Id(v)
|
||||
ELSE NilValue
|
||||
IN
|
||||
BroadcastPrevote(p, round[p], mid) \* lines 24-26
|
||||
/\ step' = [step EXCEPT ![p] = "PREVOTE"]
|
||||
/\ UNCHANGED <<round, decision, lockedValue, lockedRound,
|
||||
validValue, validRound, msgsPropose, msgsPrecommit>>
|
||||
/\ action' = "UponProposalInPropose"
|
||||
|
||||
\* lines 28-33
|
||||
UponProposalInProposeAndPrevote(p) ==
|
||||
\E v \in Values, vr \in Rounds:
|
||||
/\ step[p] = "PROPOSE" /\ 0 <= vr /\ vr < round[p] \* line 28, the while part
|
||||
/\ LET msg ==
|
||||
AsMsg([type |-> "PROPOSAL", src |-> Proposer[round[p]],
|
||||
round |-> round[p], proposal |-> v, validRound |-> vr])
|
||||
IN
|
||||
/\ msg \in msgsPropose[round[p]] \* line 28
|
||||
/\ LET PV == { m \in msgsPrevote[vr]: m.id = Id(v) } IN
|
||||
/\ Cardinality(PV) >= THRESHOLD2 \* line 28
|
||||
/\ evidence' = PV \union {msg} \union evidence
|
||||
/\ LET mid == (* line 29 *)
|
||||
IF IsValid(v) /\ (lockedRound[p] <= vr \/ lockedValue[p] = v)
|
||||
THEN Id(v)
|
||||
ELSE NilValue
|
||||
IN
|
||||
BroadcastPrevote(p, round[p], mid) \* lines 24-26
|
||||
/\ step' = [step EXCEPT ![p] = "PREVOTE"]
|
||||
/\ UNCHANGED <<round, decision, lockedValue, lockedRound,
|
||||
validValue, validRound, msgsPropose, msgsPrecommit>>
|
||||
/\ action' = "UponProposalInProposeAndPrevote"
|
||||
|
||||
\* lines 34-35 + lines 61-64 (onTimeoutPrevote)
|
||||
UponQuorumOfPrevotesAny(p) ==
|
||||
/\ step[p] = "PREVOTE" \* line 34 and 61
|
||||
/\ \E MyEvidence \in SUBSET msgsPrevote[round[p]]:
|
||||
\* find the unique voters in the evidence
|
||||
LET Voters == { m.src: m \in MyEvidence } IN
|
||||
\* compare the number of the unique voters against the threshold
|
||||
/\ Cardinality(Voters) >= THRESHOLD2 \* line 34
|
||||
/\ evidence' = MyEvidence \union evidence
|
||||
/\ BroadcastPrecommit(p, round[p], NilValue)
|
||||
/\ step' = [step EXCEPT ![p] = "PRECOMMIT"]
|
||||
/\ UNCHANGED <<round, decision, lockedValue, lockedRound,
|
||||
validValue, validRound, msgsPropose, msgsPrevote>>
|
||||
/\ action' = "UponQuorumOfPrevotesAny"
|
||||
|
||||
\* lines 36-46
|
||||
UponProposalInPrevoteOrCommitAndPrevote(p) ==
|
||||
\E v \in ValidValues, vr \in RoundsOrNil:
|
||||
/\ step[p] \in {"PREVOTE", "PRECOMMIT"} \* line 36
|
||||
/\ LET msg ==
|
||||
AsMsg([type |-> "PROPOSAL", src |-> Proposer[round[p]],
|
||||
round |-> round[p], proposal |-> v, validRound |-> vr]) IN
|
||||
/\ msg \in msgsPropose[round[p]] \* line 36
|
||||
/\ LET PV == { m \in msgsPrevote[round[p]]: m.id = Id(v) } IN
|
||||
/\ Cardinality(PV) >= THRESHOLD2 \* line 36
|
||||
/\ evidence' = PV \union {msg} \union evidence
|
||||
/\ IF step[p] = "PREVOTE"
|
||||
THEN \* lines 38-41:
|
||||
/\ lockedValue' = [lockedValue EXCEPT ![p] = v]
|
||||
/\ lockedRound' = [lockedRound EXCEPT ![p] = round[p]]
|
||||
/\ BroadcastPrecommit(p, round[p], Id(v))
|
||||
/\ step' = [step EXCEPT ![p] = "PRECOMMIT"]
|
||||
ELSE
|
||||
UNCHANGED <<lockedValue, lockedRound, msgsPrecommit, step>>
|
||||
\* lines 42-43
|
||||
/\ validValue' = [validValue EXCEPT ![p] = v]
|
||||
/\ validRound' = [validRound EXCEPT ![p] = round[p]]
|
||||
/\ UNCHANGED <<round, decision, msgsPropose, msgsPrevote>>
|
||||
/\ action' = "UponProposalInPrevoteOrCommitAndPrevote"
|
||||
|
||||
\* lines 47-48 + 65-67 (onTimeoutPrecommit)
|
||||
UponQuorumOfPrecommitsAny(p) ==
|
||||
/\ \E MyEvidence \in SUBSET msgsPrecommit[round[p]]:
|
||||
\* find the unique committers in the evidence
|
||||
LET Committers == { m.src: m \in MyEvidence } IN
|
||||
\* compare the number of the unique committers against the threshold
|
||||
/\ Cardinality(Committers) >= THRESHOLD2 \* line 47
|
||||
/\ evidence' = MyEvidence \union evidence
|
||||
/\ round[p] + 1 \in Rounds
|
||||
/\ StartRound(p, round[p] + 1)
|
||||
/\ UNCHANGED <<decision, lockedValue, lockedRound, validValue,
|
||||
validRound, msgsPropose, msgsPrevote, msgsPrecommit>>
|
||||
/\ action' = "UponQuorumOfPrecommitsAny"
|
||||
|
||||
\* lines 49-54
|
||||
UponProposalInPrecommitNoDecision(p) ==
|
||||
/\ decision[p] = NilValue \* line 49
|
||||
/\ \E v \in ValidValues (* line 50*) , r \in Rounds, vr \in RoundsOrNil:
|
||||
/\ LET msg == AsMsg([type |-> "PROPOSAL", src |-> Proposer[r],
|
||||
round |-> r, proposal |-> v, validRound |-> vr]) IN
|
||||
/\ msg \in msgsPropose[r] \* line 49
|
||||
/\ LET PV == { m \in msgsPrecommit[r]: m.id = Id(v) } IN
|
||||
/\ Cardinality(PV) >= THRESHOLD2 \* line 49
|
||||
/\ evidence' = PV \union {msg} \union evidence
|
||||
/\ decision' = [decision EXCEPT ![p] = v] \* update the decision, line 51
|
||||
\* The original algorithm does not have 'DECIDED', but it increments the height.
|
||||
\* We introduced 'DECIDED' here to prevent the process from changing its decision.
|
||||
/\ step' = [step EXCEPT ![p] = "DECIDED"]
|
||||
/\ UNCHANGED <<round, lockedValue, lockedRound, validValue,
|
||||
validRound, msgsPropose, msgsPrevote, msgsPrecommit>>
|
||||
/\ action' = "UponProposalInPrecommitNoDecision"
|
||||
|
||||
\* the actions below are not essential for safety, but added for completeness
|
||||
|
||||
\* lines 20-21 + 57-60
|
||||
OnTimeoutPropose(p) ==
|
||||
/\ step[p] = "PROPOSE"
|
||||
/\ p /= Proposer[round[p]]
|
||||
/\ BroadcastPrevote(p, round[p], NilValue)
|
||||
/\ step' = [step EXCEPT ![p] = "PREVOTE"]
|
||||
/\ UNCHANGED <<round, lockedValue, lockedRound, validValue,
|
||||
validRound, decision, evidence, msgsPropose, msgsPrecommit>>
|
||||
/\ action' = "OnTimeoutPropose"
|
||||
|
||||
\* lines 44-46
|
||||
OnQuorumOfNilPrevotes(p) ==
|
||||
/\ step[p] = "PREVOTE"
|
||||
/\ LET PV == { m \in msgsPrevote[round[p]]: m.id = Id(NilValue) } IN
|
||||
/\ Cardinality(PV) >= THRESHOLD2 \* line 36
|
||||
/\ evidence' = PV \union evidence
|
||||
/\ BroadcastPrecommit(p, round[p], Id(NilValue))
|
||||
/\ step' = [step EXCEPT ![p] = "PRECOMMIT"]
|
||||
/\ UNCHANGED <<round, lockedValue, lockedRound, validValue,
|
||||
validRound, decision, msgsPropose, msgsPrevote>>
|
||||
/\ action' = "OnQuorumOfNilPrevotes"
|
||||
|
||||
\* lines 55-56
|
||||
OnRoundCatchup(p) ==
|
||||
\E r \in {rr \in Rounds: rr > round[p]}:
|
||||
LET RoundMsgs == msgsPropose[r] \union msgsPrevote[r] \union msgsPrecommit[r] IN
|
||||
\E MyEvidence \in SUBSET RoundMsgs:
|
||||
LET Faster == { m.src: m \in MyEvidence } IN
|
||||
/\ Cardinality(Faster) >= THRESHOLD1
|
||||
/\ evidence' = MyEvidence \union evidence
|
||||
/\ StartRound(p, r)
|
||||
/\ UNCHANGED <<decision, lockedValue, lockedRound, validValue,
|
||||
validRound, msgsPropose, msgsPrevote, msgsPrecommit>>
|
||||
/\ action' = "OnRoundCatchup"
|
||||
|
||||
(*
|
||||
* A system transition. In this specificatiom, the system may eventually deadlock,
|
||||
* e.g., when all processes decide. This is expected behavior, as we focus on safety.
|
||||
*)
|
||||
Next ==
|
||||
\E p \in Corr:
|
||||
\/ InsertProposal(p)
|
||||
\/ UponProposalInPropose(p)
|
||||
\/ UponProposalInProposeAndPrevote(p)
|
||||
\/ UponQuorumOfPrevotesAny(p)
|
||||
\/ UponProposalInPrevoteOrCommitAndPrevote(p)
|
||||
\/ UponQuorumOfPrecommitsAny(p)
|
||||
\/ UponProposalInPrecommitNoDecision(p)
|
||||
\* the actions below are not essential for safety, but added for completeness
|
||||
\/ OnTimeoutPropose(p)
|
||||
\/ OnQuorumOfNilPrevotes(p)
|
||||
\/ OnRoundCatchup(p)
|
||||
|
||||
|
||||
(**************************** FORK SCENARIOS ***************************)
|
||||
|
||||
\* equivocation by a process p
|
||||
EquivocationBy(p) ==
|
||||
\E m1, m2 \in evidence:
|
||||
/\ m1 /= m2
|
||||
/\ m1.src = p
|
||||
/\ m2.src = p
|
||||
/\ m1.round = m2.round
|
||||
/\ m1.type = m2.type
|
||||
|
||||
\* amnesic behavior by a process p
|
||||
AmnesiaBy(p) ==
|
||||
\E r1, r2 \in Rounds:
|
||||
/\ r1 < r2
|
||||
/\ \E v1, v2 \in ValidValues:
|
||||
/\ v1 /= v2
|
||||
/\ AsMsg([type |-> "PRECOMMIT", src |-> p,
|
||||
round |-> r1, id |-> Id(v1)]) \in evidence
|
||||
/\ AsMsg([type |-> "PREVOTE", src |-> p,
|
||||
round |-> r2, id |-> Id(v2)]) \in evidence
|
||||
/\ \A r \in { rnd \in Rounds: r1 <= rnd /\ rnd < r2 }:
|
||||
LET prevotes ==
|
||||
{ m \in evidence:
|
||||
m.type = "PREVOTE" /\ m.round = r /\ m.id = Id(v2) }
|
||||
IN
|
||||
Cardinality(prevotes) < THRESHOLD2
|
||||
|
||||
(******************************** PROPERTIES ***************************************)
|
||||
|
||||
\* the safety property -- agreement
|
||||
Agreement ==
|
||||
\A p, q \in Corr:
|
||||
\/ decision[p] = NilValue
|
||||
\/ decision[q] = NilValue
|
||||
\/ decision[p] = decision[q]
|
||||
|
||||
\* the protocol validity
|
||||
Validity ==
|
||||
\A p \in Corr: decision[p] \in ValidValues \union {NilValue}
|
||||
|
||||
(*
|
||||
The protocol safety. Two cases are possible:
|
||||
1. There is no fork, that is, Agreement holds true.
|
||||
2. A subset of faulty processes demonstrates equivocation or amnesia.
|
||||
*)
|
||||
Accountability ==
|
||||
\/ Agreement
|
||||
\/ \E Detectable \in SUBSET Faulty:
|
||||
/\ Cardinality(Detectable) >= THRESHOLD1
|
||||
/\ \A p \in Detectable:
|
||||
EquivocationBy(p) \/ AmnesiaBy(p)
|
||||
|
||||
(****************** FALSE INVARIANTS TO PRODUCE EXAMPLES ***********************)
|
||||
|
||||
\* This property is violated. You can check it to see how amnesic behavior
|
||||
\* appears in the evidence variable.
|
||||
NoAmnesia ==
|
||||
\A p \in Faulty: ~AmnesiaBy(p)
|
||||
|
||||
\* This property is violated. You can check it to see an example of equivocation.
|
||||
NoEquivocation ==
|
||||
\A p \in Faulty: ~EquivocationBy(p)
|
||||
|
||||
\* This property is violated. You can check it to see an example of agreement.
|
||||
\* It is not exactly ~Agreement, as we do not want to see the states where
|
||||
\* decision[p] = NilValue
|
||||
NoAgreement ==
|
||||
\A p, q \in Corr:
|
||||
(p /= q /\ decision[p] /= NilValue /\ decision[q] /= NilValue)
|
||||
=> decision[p] /= decision[q]
|
||||
|
||||
\* Either agreement holds, or the faulty processes indeed demonstrate amnesia.
|
||||
\* This property is violated. A counterexample should demonstrate equivocation.
|
||||
AgreementOrAmnesia ==
|
||||
Agreement \/ (\A p \in Faulty: AmnesiaBy(p))
|
||||
|
||||
\* We expect this property to be violated. It shows us a protocol run,
|
||||
\* where one faulty process demonstrates amnesia without equivocation.
|
||||
\* However, the absence of amnesia
|
||||
\* is a tough constraint for Apalache. It has not reported a counterexample
|
||||
\* for n=4,f=2, length <= 5.
|
||||
ShowMeAmnesiaWithoutEquivocation ==
|
||||
(~Agreement /\ \E p \in Faulty: ~EquivocationBy(p))
|
||||
=> \A p \in Faulty: ~AmnesiaBy(p)
|
||||
|
||||
\* This property is violated on n=4,f=2, length=4 in less than 10 min.
|
||||
\* Two faulty processes may demonstrate amnesia without equivocation.
|
||||
AmnesiaImpliesEquivocation ==
|
||||
(\E p \in Faulty: AmnesiaBy(p)) => (\E q \in Faulty: EquivocationBy(q))
|
||||
|
||||
(*
|
||||
This property is violated. You can check it to see that all correct processes
|
||||
may reach MaxRound without making a decision.
|
||||
*)
|
||||
NeverUndecidedInMaxRound ==
|
||||
LET AllInMax == \A p \in Corr: round[p] = MaxRound
|
||||
AllDecided == \A p \in Corr: decision[p] /= NilValue
|
||||
IN
|
||||
AllInMax => AllDecided
|
||||
|
||||
=============================================================================
|
||||
|
||||
|
After Width: | Height: | Size: 33 KiB |
1141
spec/light-client/accountability/results/001indinv-apalache-mem.svg
Normal file
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 36 KiB |
@@ -0,0 +1,61 @@
|
||||
# Results of 001indinv-apalache
|
||||
|
||||
## 1. Awesome plots
|
||||
|
||||
### 1.1. Time (logarithmic scale)
|
||||
|
||||

|
||||
|
||||
### 1.2. Time (linear)
|
||||
|
||||

|
||||
|
||||
### 1.3. Memory (logarithmic scale)
|
||||
|
||||

|
||||
|
||||
### 1.4. Memory (linear)
|
||||
|
||||

|
||||
|
||||
### 1.5. Number of arena cells (linear)
|
||||
|
||||

|
||||
|
||||
### 1.6. Number of SMT clauses (linear)
|
||||
|
||||

|
||||
|
||||
## 2. Input parameters
|
||||
|
||||
no | filename | tool | timeout | init | inv | next | args
|
||||
----|----------------|------------|-----------|------------|------------------|--------|------------------------------
|
||||
1 | MC_n4_f1.tla | apalache | 10h | TypedInv | TypedInv | | --length=1 --cinit=ConstInit
|
||||
2 | MC_n4_f2.tla | apalache | 10h | TypedInv | TypedInv | | --length=1 --cinit=ConstInit
|
||||
3 | MC_n5_f1.tla | apalache | 10h | TypedInv | TypedInv | | --length=1 --cinit=ConstInit
|
||||
4 | MC_n5_f2.tla | apalache | 10h | TypedInv | TypedInv | | --length=1 --cinit=ConstInit
|
||||
5 | MC_n4_f1.tla | apalache | 20h | Init | TypedInv | | --length=0 --cinit=ConstInit
|
||||
6 | MC_n4_f2.tla | apalache | 20h | Init | TypedInv | | --length=0 --cinit=ConstInit
|
||||
7 | MC_n5_f1.tla | apalache | 20h | Init | TypedInv | | --length=0 --cinit=ConstInit
|
||||
8 | MC_n5_f2.tla | apalache | 20h | Init | TypedInv | | --length=0 --cinit=ConstInit
|
||||
9 | MC_n4_f1.tla | apalache | 20h | TypedInv | Agreement | | --length=0 --cinit=ConstInit
|
||||
10 | MC_n4_f2.tla | apalache | 20h | TypedInv | Accountability | | --length=0 --cinit=ConstInit
|
||||
11 | MC_n5_f1.tla | apalache | 20h | TypedInv | Agreement | | --length=0 --cinit=ConstInit
|
||||
12 | MC_n5_f2.tla | apalache | 20h | TypedInv | Accountability | | --length=0 --cinit=ConstInit
|
||||
|
||||
## 3. Detailed results: 001indinv-apalache-unstable.csv
|
||||
|
||||
01:no | 02:tool | 03:status | 04:time_sec | 05:depth | 05:mem_kb | 10:ninit_trans | 11:ninit_trans | 12:ncells | 13:nclauses | 14:navg_clause_len
|
||||
-------|------------|-------------|---------------|------------|-------------|------------------|------------------|-------------|---------------|--------------------
|
||||
1 | apalache | NoError | 11m | 1 | 3.0GB | 0 | 0 | 217K | 1.0M | 89
|
||||
2 | apalache | NoError | 11m | 1 | 3.0GB | 0 | 0 | 207K | 1.0M | 88
|
||||
3 | apalache | NoError | 16m | 1 | 4.0GB | 0 | 0 | 311K | 2.0M | 101
|
||||
4 | apalache | NoError | 14m | 1 | 3.0GB | 0 | 0 | 290K | 1.0M | 103
|
||||
5 | apalache | NoError | 9s | 0 | 563MB | 0 | 0 | 2.0K | 14K | 42
|
||||
6 | apalache | NoError | 10s | 0 | 657MB | 0 | 0 | 2.0K | 28K | 43
|
||||
7 | apalache | NoError | 8s | 0 | 635MB | 0 | 0 | 2.0K | 17K | 44
|
||||
8 | apalache | NoError | 10s | 0 | 667MB | 0 | 0 | 3.0K | 32K | 45
|
||||
9 | apalache | NoError | 5m05s | 0 | 2.0GB | 0 | 0 | 196K | 889K | 108
|
||||
10 | apalache | NoError | 8m08s | 0 | 6.0GB | 0 | 0 | 2.0M | 3.0M | 34
|
||||
11 | apalache | NoError | 9m09s | 0 | 3.0GB | 0 | 0 | 284K | 1.0M | 128
|
||||
12 | apalache | NoError | 14m | 0 | 7.0GB | 0 | 0 | 4.0M | 5.0M | 38
|
||||
|
After Width: | Height: | Size: 36 KiB |
@@ -0,0 +1,957 @@
|
||||
<?xml version="1.0" encoding="utf-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
|
||||
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<!-- Created with matplotlib (https://matplotlib.org/) -->
|
||||
<svg height="345.6pt" version="1.1" viewBox="0 0 460.8 345.6" width="460.8pt" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<metadata>
|
||||
<rdf:RDF xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||||
<cc:Work>
|
||||
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
|
||||
<dc:date>2020-12-11T20:07:39.136767</dc:date>
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:creator>
|
||||
<cc:Agent>
|
||||
<dc:title>Matplotlib v3.3.3, https://matplotlib.org/</dc:title>
|
||||
</cc:Agent>
|
||||
</dc:creator>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs>
|
||||
<style type="text/css">*{stroke-linecap:butt;stroke-linejoin:round;}</style>
|
||||
</defs>
|
||||
<g id="figure_1">
|
||||
<g id="patch_1">
|
||||
<path d="M 0 345.6
|
||||
L 460.8 345.6
|
||||
L 460.8 0
|
||||
L 0 0
|
||||
z
|
||||
" style="fill:#ffffff;"/>
|
||||
</g>
|
||||
<g id="axes_1">
|
||||
<g id="patch_2">
|
||||
<path d="M 57.6 307.584
|
||||
L 414.72 307.584
|
||||
L 414.72 41.472
|
||||
L 57.6 41.472
|
||||
z
|
||||
" style="fill:#ffffff;"/>
|
||||
</g>
|
||||
<g id="matplotlib.axis_1">
|
||||
<g id="xtick_1">
|
||||
<g id="line2d_1">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 103.346777 307.584
|
||||
L 103.346777 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_2">
|
||||
<defs>
|
||||
<path d="M 0 0
|
||||
L 0 3.5
|
||||
" id="m6c16508061" style="stroke:#000000;stroke-width:0.8;"/>
|
||||
</defs>
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="103.346777" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_1">
|
||||
<!-- 2 -->
|
||||
<g transform="translate(100.165527 322.182437)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 19.1875 8.296875
|
||||
L 53.609375 8.296875
|
||||
L 53.609375 0
|
||||
L 7.328125 0
|
||||
L 7.328125 8.296875
|
||||
Q 12.9375 14.109375 22.625 23.890625
|
||||
Q 32.328125 33.6875 34.8125 36.53125
|
||||
Q 39.546875 41.84375 41.421875 45.53125
|
||||
Q 43.3125 49.21875 43.3125 52.78125
|
||||
Q 43.3125 58.59375 39.234375 62.25
|
||||
Q 35.15625 65.921875 28.609375 65.921875
|
||||
Q 23.96875 65.921875 18.8125 64.3125
|
||||
Q 13.671875 62.703125 7.8125 59.421875
|
||||
L 7.8125 69.390625
|
||||
Q 13.765625 71.78125 18.9375 73
|
||||
Q 24.125 74.21875 28.421875 74.21875
|
||||
Q 39.75 74.21875 46.484375 68.546875
|
||||
Q 53.21875 62.890625 53.21875 53.421875
|
||||
Q 53.21875 48.921875 51.53125 44.890625
|
||||
Q 49.859375 40.875 45.40625 35.40625
|
||||
Q 44.1875 33.984375 37.640625 27.21875
|
||||
Q 31.109375 20.453125 19.1875 8.296875
|
||||
z
|
||||
" id="DejaVuSans-50"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-50"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="xtick_2">
|
||||
<g id="line2d_3">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 162.374876 307.584
|
||||
L 162.374876 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_4">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="162.374876" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_2">
|
||||
<!-- 4 -->
|
||||
<g transform="translate(159.193626 322.182437)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 37.796875 64.3125
|
||||
L 12.890625 25.390625
|
||||
L 37.796875 25.390625
|
||||
z
|
||||
M 35.203125 72.90625
|
||||
L 47.609375 72.90625
|
||||
L 47.609375 25.390625
|
||||
L 58.015625 25.390625
|
||||
L 58.015625 17.1875
|
||||
L 47.609375 17.1875
|
||||
L 47.609375 0
|
||||
L 37.796875 0
|
||||
L 37.796875 17.1875
|
||||
L 4.890625 17.1875
|
||||
L 4.890625 26.703125
|
||||
z
|
||||
" id="DejaVuSans-52"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-52"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="xtick_3">
|
||||
<g id="line2d_5">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 221.402975 307.584
|
||||
L 221.402975 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_6">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="221.402975" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_3">
|
||||
<!-- 6 -->
|
||||
<g transform="translate(218.221725 322.182437)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 33.015625 40.375
|
||||
Q 26.375 40.375 22.484375 35.828125
|
||||
Q 18.609375 31.296875 18.609375 23.390625
|
||||
Q 18.609375 15.53125 22.484375 10.953125
|
||||
Q 26.375 6.390625 33.015625 6.390625
|
||||
Q 39.65625 6.390625 43.53125 10.953125
|
||||
Q 47.40625 15.53125 47.40625 23.390625
|
||||
Q 47.40625 31.296875 43.53125 35.828125
|
||||
Q 39.65625 40.375 33.015625 40.375
|
||||
z
|
||||
M 52.59375 71.296875
|
||||
L 52.59375 62.3125
|
||||
Q 48.875 64.0625 45.09375 64.984375
|
||||
Q 41.3125 65.921875 37.59375 65.921875
|
||||
Q 27.828125 65.921875 22.671875 59.328125
|
||||
Q 17.53125 52.734375 16.796875 39.40625
|
||||
Q 19.671875 43.65625 24.015625 45.921875
|
||||
Q 28.375 48.1875 33.59375 48.1875
|
||||
Q 44.578125 48.1875 50.953125 41.515625
|
||||
Q 57.328125 34.859375 57.328125 23.390625
|
||||
Q 57.328125 12.15625 50.6875 5.359375
|
||||
Q 44.046875 -1.421875 33.015625 -1.421875
|
||||
Q 20.359375 -1.421875 13.671875 8.265625
|
||||
Q 6.984375 17.96875 6.984375 36.375
|
||||
Q 6.984375 53.65625 15.1875 63.9375
|
||||
Q 23.390625 74.21875 37.203125 74.21875
|
||||
Q 40.921875 74.21875 44.703125 73.484375
|
||||
Q 48.484375 72.75 52.59375 71.296875
|
||||
z
|
||||
" id="DejaVuSans-54"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-54"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="xtick_4">
|
||||
<g id="line2d_7">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 280.431074 307.584
|
||||
L 280.431074 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_8">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="280.431074" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_4">
|
||||
<!-- 8 -->
|
||||
<g transform="translate(277.249824 322.182437)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 31.78125 34.625
|
||||
Q 24.75 34.625 20.71875 30.859375
|
||||
Q 16.703125 27.09375 16.703125 20.515625
|
||||
Q 16.703125 13.921875 20.71875 10.15625
|
||||
Q 24.75 6.390625 31.78125 6.390625
|
||||
Q 38.8125 6.390625 42.859375 10.171875
|
||||
Q 46.921875 13.96875 46.921875 20.515625
|
||||
Q 46.921875 27.09375 42.890625 30.859375
|
||||
Q 38.875 34.625 31.78125 34.625
|
||||
z
|
||||
M 21.921875 38.8125
|
||||
Q 15.578125 40.375 12.03125 44.71875
|
||||
Q 8.5 49.078125 8.5 55.328125
|
||||
Q 8.5 64.0625 14.71875 69.140625
|
||||
Q 20.953125 74.21875 31.78125 74.21875
|
||||
Q 42.671875 74.21875 48.875 69.140625
|
||||
Q 55.078125 64.0625 55.078125 55.328125
|
||||
Q 55.078125 49.078125 51.53125 44.71875
|
||||
Q 48 40.375 41.703125 38.8125
|
||||
Q 48.828125 37.15625 52.796875 32.3125
|
||||
Q 56.78125 27.484375 56.78125 20.515625
|
||||
Q 56.78125 9.90625 50.3125 4.234375
|
||||
Q 43.84375 -1.421875 31.78125 -1.421875
|
||||
Q 19.734375 -1.421875 13.25 4.234375
|
||||
Q 6.78125 9.90625 6.78125 20.515625
|
||||
Q 6.78125 27.484375 10.78125 32.3125
|
||||
Q 14.796875 37.15625 21.921875 38.8125
|
||||
z
|
||||
M 18.3125 54.390625
|
||||
Q 18.3125 48.734375 21.84375 45.5625
|
||||
Q 25.390625 42.390625 31.78125 42.390625
|
||||
Q 38.140625 42.390625 41.71875 45.5625
|
||||
Q 45.3125 48.734375 45.3125 54.390625
|
||||
Q 45.3125 60.0625 41.71875 63.234375
|
||||
Q 38.140625 66.40625 31.78125 66.40625
|
||||
Q 25.390625 66.40625 21.84375 63.234375
|
||||
Q 18.3125 60.0625 18.3125 54.390625
|
||||
z
|
||||
" id="DejaVuSans-56"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-56"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="xtick_5">
|
||||
<g id="line2d_9">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 339.459174 307.584
|
||||
L 339.459174 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_10">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="339.459174" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_5">
|
||||
<!-- 10 -->
|
||||
<g transform="translate(333.096674 322.182437)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 12.40625 8.296875
|
||||
L 28.515625 8.296875
|
||||
L 28.515625 63.921875
|
||||
L 10.984375 60.40625
|
||||
L 10.984375 69.390625
|
||||
L 28.421875 72.90625
|
||||
L 38.28125 72.90625
|
||||
L 38.28125 8.296875
|
||||
L 54.390625 8.296875
|
||||
L 54.390625 0
|
||||
L 12.40625 0
|
||||
z
|
||||
" id="DejaVuSans-49"/>
|
||||
<path d="M 31.78125 66.40625
|
||||
Q 24.171875 66.40625 20.328125 58.90625
|
||||
Q 16.5 51.421875 16.5 36.375
|
||||
Q 16.5 21.390625 20.328125 13.890625
|
||||
Q 24.171875 6.390625 31.78125 6.390625
|
||||
Q 39.453125 6.390625 43.28125 13.890625
|
||||
Q 47.125 21.390625 47.125 36.375
|
||||
Q 47.125 51.421875 43.28125 58.90625
|
||||
Q 39.453125 66.40625 31.78125 66.40625
|
||||
z
|
||||
M 31.78125 74.21875
|
||||
Q 44.046875 74.21875 50.515625 64.515625
|
||||
Q 56.984375 54.828125 56.984375 36.375
|
||||
Q 56.984375 17.96875 50.515625 8.265625
|
||||
Q 44.046875 -1.421875 31.78125 -1.421875
|
||||
Q 19.53125 -1.421875 13.0625 8.265625
|
||||
Q 6.59375 17.96875 6.59375 36.375
|
||||
Q 6.59375 54.828125 13.0625 64.515625
|
||||
Q 19.53125 74.21875 31.78125 74.21875
|
||||
z
|
||||
" id="DejaVuSans-48"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-49"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="xtick_6">
|
||||
<g id="line2d_11">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 398.487273 307.584
|
||||
L 398.487273 41.472
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_12">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="398.487273" xlink:href="#m6c16508061" y="307.584"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_6">
|
||||
<!-- 12 -->
|
||||
<g transform="translate(392.124773 322.182437)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-49"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-50"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_7">
|
||||
<!-- benchmark -->
|
||||
<g transform="translate(207.937344 335.860562)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 48.6875 27.296875
|
||||
Q 48.6875 37.203125 44.609375 42.84375
|
||||
Q 40.53125 48.484375 33.40625 48.484375
|
||||
Q 26.265625 48.484375 22.1875 42.84375
|
||||
Q 18.109375 37.203125 18.109375 27.296875
|
||||
Q 18.109375 17.390625 22.1875 11.75
|
||||
Q 26.265625 6.109375 33.40625 6.109375
|
||||
Q 40.53125 6.109375 44.609375 11.75
|
||||
Q 48.6875 17.390625 48.6875 27.296875
|
||||
z
|
||||
M 18.109375 46.390625
|
||||
Q 20.953125 51.265625 25.265625 53.625
|
||||
Q 29.59375 56 35.59375 56
|
||||
Q 45.5625 56 51.78125 48.09375
|
||||
Q 58.015625 40.1875 58.015625 27.296875
|
||||
Q 58.015625 14.40625 51.78125 6.484375
|
||||
Q 45.5625 -1.421875 35.59375 -1.421875
|
||||
Q 29.59375 -1.421875 25.265625 0.953125
|
||||
Q 20.953125 3.328125 18.109375 8.203125
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
L 9.078125 75.984375
|
||||
L 18.109375 75.984375
|
||||
z
|
||||
" id="DejaVuSans-98"/>
|
||||
<path d="M 56.203125 29.59375
|
||||
L 56.203125 25.203125
|
||||
L 14.890625 25.203125
|
||||
Q 15.484375 15.921875 20.484375 11.0625
|
||||
Q 25.484375 6.203125 34.421875 6.203125
|
||||
Q 39.59375 6.203125 44.453125 7.46875
|
||||
Q 49.3125 8.734375 54.109375 11.28125
|
||||
L 54.109375 2.78125
|
||||
Q 49.265625 0.734375 44.1875 -0.34375
|
||||
Q 39.109375 -1.421875 33.890625 -1.421875
|
||||
Q 20.796875 -1.421875 13.15625 6.1875
|
||||
Q 5.515625 13.8125 5.515625 26.8125
|
||||
Q 5.515625 40.234375 12.765625 48.109375
|
||||
Q 20.015625 56 32.328125 56
|
||||
Q 43.359375 56 49.78125 48.890625
|
||||
Q 56.203125 41.796875 56.203125 29.59375
|
||||
z
|
||||
M 47.21875 32.234375
|
||||
Q 47.125 39.59375 43.09375 43.984375
|
||||
Q 39.0625 48.390625 32.421875 48.390625
|
||||
Q 24.90625 48.390625 20.390625 44.140625
|
||||
Q 15.875 39.890625 15.1875 32.171875
|
||||
z
|
||||
" id="DejaVuSans-101"/>
|
||||
<path d="M 54.890625 33.015625
|
||||
L 54.890625 0
|
||||
L 45.90625 0
|
||||
L 45.90625 32.71875
|
||||
Q 45.90625 40.484375 42.875 44.328125
|
||||
Q 39.84375 48.1875 33.796875 48.1875
|
||||
Q 26.515625 48.1875 22.3125 43.546875
|
||||
Q 18.109375 38.921875 18.109375 30.90625
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
L 9.078125 54.6875
|
||||
L 18.109375 54.6875
|
||||
L 18.109375 46.1875
|
||||
Q 21.34375 51.125 25.703125 53.5625
|
||||
Q 30.078125 56 35.796875 56
|
||||
Q 45.21875 56 50.046875 50.171875
|
||||
Q 54.890625 44.34375 54.890625 33.015625
|
||||
z
|
||||
" id="DejaVuSans-110"/>
|
||||
<path d="M 48.78125 52.59375
|
||||
L 48.78125 44.1875
|
||||
Q 44.96875 46.296875 41.140625 47.34375
|
||||
Q 37.3125 48.390625 33.40625 48.390625
|
||||
Q 24.65625 48.390625 19.8125 42.84375
|
||||
Q 14.984375 37.3125 14.984375 27.296875
|
||||
Q 14.984375 17.28125 19.8125 11.734375
|
||||
Q 24.65625 6.203125 33.40625 6.203125
|
||||
Q 37.3125 6.203125 41.140625 7.25
|
||||
Q 44.96875 8.296875 48.78125 10.40625
|
||||
L 48.78125 2.09375
|
||||
Q 45.015625 0.34375 40.984375 -0.53125
|
||||
Q 36.96875 -1.421875 32.421875 -1.421875
|
||||
Q 20.0625 -1.421875 12.78125 6.34375
|
||||
Q 5.515625 14.109375 5.515625 27.296875
|
||||
Q 5.515625 40.671875 12.859375 48.328125
|
||||
Q 20.21875 56 33.015625 56
|
||||
Q 37.15625 56 41.109375 55.140625
|
||||
Q 45.0625 54.296875 48.78125 52.59375
|
||||
z
|
||||
" id="DejaVuSans-99"/>
|
||||
<path d="M 54.890625 33.015625
|
||||
L 54.890625 0
|
||||
L 45.90625 0
|
||||
L 45.90625 32.71875
|
||||
Q 45.90625 40.484375 42.875 44.328125
|
||||
Q 39.84375 48.1875 33.796875 48.1875
|
||||
Q 26.515625 48.1875 22.3125 43.546875
|
||||
Q 18.109375 38.921875 18.109375 30.90625
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
L 9.078125 75.984375
|
||||
L 18.109375 75.984375
|
||||
L 18.109375 46.1875
|
||||
Q 21.34375 51.125 25.703125 53.5625
|
||||
Q 30.078125 56 35.796875 56
|
||||
Q 45.21875 56 50.046875 50.171875
|
||||
Q 54.890625 44.34375 54.890625 33.015625
|
||||
z
|
||||
" id="DejaVuSans-104"/>
|
||||
<path d="M 52 44.1875
|
||||
Q 55.375 50.25 60.0625 53.125
|
||||
Q 64.75 56 71.09375 56
|
||||
Q 79.640625 56 84.28125 50.015625
|
||||
Q 88.921875 44.046875 88.921875 33.015625
|
||||
L 88.921875 0
|
||||
L 79.890625 0
|
||||
L 79.890625 32.71875
|
||||
Q 79.890625 40.578125 77.09375 44.375
|
||||
Q 74.3125 48.1875 68.609375 48.1875
|
||||
Q 61.625 48.1875 57.5625 43.546875
|
||||
Q 53.515625 38.921875 53.515625 30.90625
|
||||
L 53.515625 0
|
||||
L 44.484375 0
|
||||
L 44.484375 32.71875
|
||||
Q 44.484375 40.625 41.703125 44.40625
|
||||
Q 38.921875 48.1875 33.109375 48.1875
|
||||
Q 26.21875 48.1875 22.15625 43.53125
|
||||
Q 18.109375 38.875 18.109375 30.90625
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
L 9.078125 54.6875
|
||||
L 18.109375 54.6875
|
||||
L 18.109375 46.1875
|
||||
Q 21.1875 51.21875 25.484375 53.609375
|
||||
Q 29.78125 56 35.6875 56
|
||||
Q 41.65625 56 45.828125 52.96875
|
||||
Q 50 49.953125 52 44.1875
|
||||
z
|
||||
" id="DejaVuSans-109"/>
|
||||
<path d="M 34.28125 27.484375
|
||||
Q 23.390625 27.484375 19.1875 25
|
||||
Q 14.984375 22.515625 14.984375 16.5
|
||||
Q 14.984375 11.71875 18.140625 8.90625
|
||||
Q 21.296875 6.109375 26.703125 6.109375
|
||||
Q 34.1875 6.109375 38.703125 11.40625
|
||||
Q 43.21875 16.703125 43.21875 25.484375
|
||||
L 43.21875 27.484375
|
||||
z
|
||||
M 52.203125 31.203125
|
||||
L 52.203125 0
|
||||
L 43.21875 0
|
||||
L 43.21875 8.296875
|
||||
Q 40.140625 3.328125 35.546875 0.953125
|
||||
Q 30.953125 -1.421875 24.3125 -1.421875
|
||||
Q 15.921875 -1.421875 10.953125 3.296875
|
||||
Q 6 8.015625 6 15.921875
|
||||
Q 6 25.140625 12.171875 29.828125
|
||||
Q 18.359375 34.515625 30.609375 34.515625
|
||||
L 43.21875 34.515625
|
||||
L 43.21875 35.40625
|
||||
Q 43.21875 41.609375 39.140625 45
|
||||
Q 35.0625 48.390625 27.6875 48.390625
|
||||
Q 23 48.390625 18.546875 47.265625
|
||||
Q 14.109375 46.140625 10.015625 43.890625
|
||||
L 10.015625 52.203125
|
||||
Q 14.9375 54.109375 19.578125 55.046875
|
||||
Q 24.21875 56 28.609375 56
|
||||
Q 40.484375 56 46.34375 49.84375
|
||||
Q 52.203125 43.703125 52.203125 31.203125
|
||||
z
|
||||
" id="DejaVuSans-97"/>
|
||||
<path d="M 41.109375 46.296875
|
||||
Q 39.59375 47.171875 37.8125 47.578125
|
||||
Q 36.03125 48 33.890625 48
|
||||
Q 26.265625 48 22.1875 43.046875
|
||||
Q 18.109375 38.09375 18.109375 28.8125
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
L 9.078125 54.6875
|
||||
L 18.109375 54.6875
|
||||
L 18.109375 46.1875
|
||||
Q 20.953125 51.171875 25.484375 53.578125
|
||||
Q 30.03125 56 36.53125 56
|
||||
Q 37.453125 56 38.578125 55.875
|
||||
Q 39.703125 55.765625 41.0625 55.515625
|
||||
z
|
||||
" id="DejaVuSans-114"/>
|
||||
<path d="M 9.078125 75.984375
|
||||
L 18.109375 75.984375
|
||||
L 18.109375 31.109375
|
||||
L 44.921875 54.6875
|
||||
L 56.390625 54.6875
|
||||
L 27.390625 29.109375
|
||||
L 57.625 0
|
||||
L 45.90625 0
|
||||
L 18.109375 26.703125
|
||||
L 18.109375 0
|
||||
L 9.078125 0
|
||||
z
|
||||
" id="DejaVuSans-107"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-98"/>
|
||||
<use x="63.476562" xlink:href="#DejaVuSans-101"/>
|
||||
<use x="125" xlink:href="#DejaVuSans-110"/>
|
||||
<use x="188.378906" xlink:href="#DejaVuSans-99"/>
|
||||
<use x="243.359375" xlink:href="#DejaVuSans-104"/>
|
||||
<use x="306.738281" xlink:href="#DejaVuSans-109"/>
|
||||
<use x="404.150391" xlink:href="#DejaVuSans-97"/>
|
||||
<use x="465.429688" xlink:href="#DejaVuSans-114"/>
|
||||
<use x="506.542969" xlink:href="#DejaVuSans-107"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="matplotlib.axis_2">
|
||||
<g id="ytick_1">
|
||||
<g id="line2d_13">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 297.404198
|
||||
L 414.72 297.404198
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_14">
|
||||
<defs>
|
||||
<path d="M 0 0
|
||||
L -3.5 0
|
||||
" id="m92e578bc9b" style="stroke:#000000;stroke-width:0.8;"/>
|
||||
</defs>
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="297.404198"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_8">
|
||||
<!-- 0 -->
|
||||
<g transform="translate(44.2375 301.203417)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="ytick_2">
|
||||
<g id="line2d_15">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 249.499248
|
||||
L 414.72 249.499248
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_16">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="249.499248"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_9">
|
||||
<!-- 200 -->
|
||||
<g transform="translate(31.5125 253.298466)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-50"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="ytick_3">
|
||||
<g id="line2d_17">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 201.594297
|
||||
L 414.72 201.594297
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_18">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="201.594297"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_10">
|
||||
<!-- 400 -->
|
||||
<g transform="translate(31.5125 205.393516)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-52"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="ytick_4">
|
||||
<g id="line2d_19">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 153.689347
|
||||
L 414.72 153.689347
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_20">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="153.689347"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_11">
|
||||
<!-- 600 -->
|
||||
<g transform="translate(31.5125 157.488565)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-54"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="ytick_5">
|
||||
<g id="line2d_21">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 105.784396
|
||||
L 414.72 105.784396
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_22">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="105.784396"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_12">
|
||||
<!-- 800 -->
|
||||
<g transform="translate(31.5125 109.583615)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-56"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="ytick_6">
|
||||
<g id="line2d_23">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 57.6 57.879446
|
||||
L 414.72 57.879446
|
||||
" style="fill:none;stroke:#b0b0b0;stroke-linecap:square;stroke-opacity:0.2;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="line2d_24">
|
||||
<g>
|
||||
<use style="stroke:#000000;stroke-width:0.8;" x="57.6" xlink:href="#m92e578bc9b" y="57.879446"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_13">
|
||||
<!-- 1000 -->
|
||||
<g transform="translate(25.15 61.678664)scale(0.1 -0.1)">
|
||||
<use xlink:href="#DejaVuSans-49"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="190.869141" xlink:href="#DejaVuSans-48"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_14">
|
||||
<!-- time, sec -->
|
||||
<g transform="translate(19.070312 197.432687)rotate(-90)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 18.3125 70.21875
|
||||
L 18.3125 54.6875
|
||||
L 36.8125 54.6875
|
||||
L 36.8125 47.703125
|
||||
L 18.3125 47.703125
|
||||
L 18.3125 18.015625
|
||||
Q 18.3125 11.328125 20.140625 9.421875
|
||||
Q 21.96875 7.515625 27.59375 7.515625
|
||||
L 36.8125 7.515625
|
||||
L 36.8125 0
|
||||
L 27.59375 0
|
||||
Q 17.1875 0 13.234375 3.875
|
||||
Q 9.28125 7.765625 9.28125 18.015625
|
||||
L 9.28125 47.703125
|
||||
L 2.6875 47.703125
|
||||
L 2.6875 54.6875
|
||||
L 9.28125 54.6875
|
||||
L 9.28125 70.21875
|
||||
z
|
||||
" id="DejaVuSans-116"/>
|
||||
<path d="M 9.421875 54.6875
|
||||
L 18.40625 54.6875
|
||||
L 18.40625 0
|
||||
L 9.421875 0
|
||||
z
|
||||
M 9.421875 75.984375
|
||||
L 18.40625 75.984375
|
||||
L 18.40625 64.59375
|
||||
L 9.421875 64.59375
|
||||
z
|
||||
" id="DejaVuSans-105"/>
|
||||
<path d="M 11.71875 12.40625
|
||||
L 22.015625 12.40625
|
||||
L 22.015625 4
|
||||
L 14.015625 -11.625
|
||||
L 7.71875 -11.625
|
||||
L 11.71875 4
|
||||
z
|
||||
" id="DejaVuSans-44"/>
|
||||
<path id="DejaVuSans-32"/>
|
||||
<path d="M 44.28125 53.078125
|
||||
L 44.28125 44.578125
|
||||
Q 40.484375 46.53125 36.375 47.5
|
||||
Q 32.28125 48.484375 27.875 48.484375
|
||||
Q 21.1875 48.484375 17.84375 46.4375
|
||||
Q 14.5 44.390625 14.5 40.28125
|
||||
Q 14.5 37.15625 16.890625 35.375
|
||||
Q 19.28125 33.59375 26.515625 31.984375
|
||||
L 29.59375 31.296875
|
||||
Q 39.15625 29.25 43.1875 25.515625
|
||||
Q 47.21875 21.78125 47.21875 15.09375
|
||||
Q 47.21875 7.46875 41.1875 3.015625
|
||||
Q 35.15625 -1.421875 24.609375 -1.421875
|
||||
Q 20.21875 -1.421875 15.453125 -0.5625
|
||||
Q 10.6875 0.296875 5.421875 2
|
||||
L 5.421875 11.28125
|
||||
Q 10.40625 8.6875 15.234375 7.390625
|
||||
Q 20.0625 6.109375 24.8125 6.109375
|
||||
Q 31.15625 6.109375 34.5625 8.28125
|
||||
Q 37.984375 10.453125 37.984375 14.40625
|
||||
Q 37.984375 18.0625 35.515625 20.015625
|
||||
Q 33.0625 21.96875 24.703125 23.78125
|
||||
L 21.578125 24.515625
|
||||
Q 13.234375 26.265625 9.515625 29.90625
|
||||
Q 5.8125 33.546875 5.8125 39.890625
|
||||
Q 5.8125 47.609375 11.28125 51.796875
|
||||
Q 16.75 56 26.8125 56
|
||||
Q 31.78125 56 36.171875 55.265625
|
||||
Q 40.578125 54.546875 44.28125 53.078125
|
||||
z
|
||||
" id="DejaVuSans-115"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-116"/>
|
||||
<use x="39.208984" xlink:href="#DejaVuSans-105"/>
|
||||
<use x="66.992188" xlink:href="#DejaVuSans-109"/>
|
||||
<use x="164.404297" xlink:href="#DejaVuSans-101"/>
|
||||
<use x="225.927734" xlink:href="#DejaVuSans-44"/>
|
||||
<use x="257.714844" xlink:href="#DejaVuSans-32"/>
|
||||
<use x="289.501953" xlink:href="#DejaVuSans-115"/>
|
||||
<use x="341.601562" xlink:href="#DejaVuSans-101"/>
|
||||
<use x="403.125" xlink:href="#DejaVuSans-99"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="line2d_25">
|
||||
<path clip-path="url(#p902cfd873e)" d="M 73.832727 128.778772
|
||||
L 103.346777 129.976396
|
||||
L 132.860826 53.568
|
||||
L 162.374876 84.466693
|
||||
L 191.888926 295.248475
|
||||
L 221.402975 295.00895
|
||||
L 250.917025 295.488
|
||||
L 280.431074 295.00895
|
||||
L 309.945124 215.965782
|
||||
L 339.459174 173.569901
|
||||
L 368.973223 156.803168
|
||||
L 398.487273 86.622416
|
||||
" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-opacity:0.7;stroke-width:1.5;"/>
|
||||
<defs>
|
||||
<path d="M -3 3
|
||||
L 3 3
|
||||
L 3 -3
|
||||
L -3 -3
|
||||
z
|
||||
" id="m40d9e306aa" style="stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;"/>
|
||||
</defs>
|
||||
<g clip-path="url(#p902cfd873e)">
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="73.832727" xlink:href="#m40d9e306aa" y="128.778772"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="103.346777" xlink:href="#m40d9e306aa" y="129.976396"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="132.860826" xlink:href="#m40d9e306aa" y="53.568"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="162.374876" xlink:href="#m40d9e306aa" y="84.466693"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="191.888926" xlink:href="#m40d9e306aa" y="295.248475"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="221.402975" xlink:href="#m40d9e306aa" y="295.00895"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="250.917025" xlink:href="#m40d9e306aa" y="295.488"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="280.431074" xlink:href="#m40d9e306aa" y="295.00895"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="309.945124" xlink:href="#m40d9e306aa" y="215.965782"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="339.459174" xlink:href="#m40d9e306aa" y="173.569901"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="368.973223" xlink:href="#m40d9e306aa" y="156.803168"/>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="398.487273" xlink:href="#m40d9e306aa" y="86.622416"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="patch_3">
|
||||
<path d="M 57.6 307.584
|
||||
L 57.6 41.472
|
||||
" style="fill:none;stroke:#000000;stroke-linecap:square;stroke-linejoin:miter;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="patch_4">
|
||||
<path d="M 414.72 307.584
|
||||
L 414.72 41.472
|
||||
" style="fill:none;stroke:#000000;stroke-linecap:square;stroke-linejoin:miter;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="patch_5">
|
||||
<path d="M 57.6 307.584
|
||||
L 414.72 307.584
|
||||
" style="fill:none;stroke:#000000;stroke-linecap:square;stroke-linejoin:miter;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="patch_6">
|
||||
<path d="M 57.6 41.472
|
||||
L 414.72 41.472
|
||||
" style="fill:none;stroke:#000000;stroke-linecap:square;stroke-linejoin:miter;stroke-width:0.8;"/>
|
||||
</g>
|
||||
<g id="legend_1">
|
||||
<g id="patch_7">
|
||||
<path d="M 230.468437 64.150125
|
||||
L 407.72 64.150125
|
||||
Q 409.72 64.150125 409.72 62.150125
|
||||
L 409.72 48.472
|
||||
Q 409.72 46.472 407.72 46.472
|
||||
L 230.468437 46.472
|
||||
Q 228.468437 46.472 228.468437 48.472
|
||||
L 228.468437 62.150125
|
||||
Q 228.468437 64.150125 230.468437 64.150125
|
||||
z
|
||||
" style="fill:#ffffff;opacity:0.8;stroke:#cccccc;stroke-linejoin:miter;"/>
|
||||
</g>
|
||||
<g id="line2d_26">
|
||||
<path d="M 232.468437 54.570438
|
||||
L 252.468437 54.570438
|
||||
" style="fill:none;stroke:#ff0000;stroke-linecap:square;stroke-opacity:0.7;stroke-width:1.5;"/>
|
||||
</g>
|
||||
<g id="line2d_27">
|
||||
<g>
|
||||
<use style="fill:#ff0000;fill-opacity:0.7;stroke:#ff0000;stroke-linejoin:miter;stroke-opacity:0.7;" x="242.468437" xlink:href="#m40d9e306aa" y="54.570438"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="text_15">
|
||||
<!-- 001indinv-apalache-unstable -->
|
||||
<g transform="translate(260.468437 58.070438)scale(0.1 -0.1)">
|
||||
<defs>
|
||||
<path d="M 45.40625 46.390625
|
||||
L 45.40625 75.984375
|
||||
L 54.390625 75.984375
|
||||
L 54.390625 0
|
||||
L 45.40625 0
|
||||
L 45.40625 8.203125
|
||||
Q 42.578125 3.328125 38.25 0.953125
|
||||
Q 33.9375 -1.421875 27.875 -1.421875
|
||||
Q 17.96875 -1.421875 11.734375 6.484375
|
||||
Q 5.515625 14.40625 5.515625 27.296875
|
||||
Q 5.515625 40.1875 11.734375 48.09375
|
||||
Q 17.96875 56 27.875 56
|
||||
Q 33.9375 56 38.25 53.625
|
||||
Q 42.578125 51.265625 45.40625 46.390625
|
||||
z
|
||||
M 14.796875 27.296875
|
||||
Q 14.796875 17.390625 18.875 11.75
|
||||
Q 22.953125 6.109375 30.078125 6.109375
|
||||
Q 37.203125 6.109375 41.296875 11.75
|
||||
Q 45.40625 17.390625 45.40625 27.296875
|
||||
Q 45.40625 37.203125 41.296875 42.84375
|
||||
Q 37.203125 48.484375 30.078125 48.484375
|
||||
Q 22.953125 48.484375 18.875 42.84375
|
||||
Q 14.796875 37.203125 14.796875 27.296875
|
||||
z
|
||||
" id="DejaVuSans-100"/>
|
||||
<path d="M 2.984375 54.6875
|
||||
L 12.5 54.6875
|
||||
L 29.59375 8.796875
|
||||
L 46.6875 54.6875
|
||||
L 56.203125 54.6875
|
||||
L 35.6875 0
|
||||
L 23.484375 0
|
||||
z
|
||||
" id="DejaVuSans-118"/>
|
||||
<path d="M 4.890625 31.390625
|
||||
L 31.203125 31.390625
|
||||
L 31.203125 23.390625
|
||||
L 4.890625 23.390625
|
||||
z
|
||||
" id="DejaVuSans-45"/>
|
||||
<path d="M 18.109375 8.203125
|
||||
L 18.109375 -20.796875
|
||||
L 9.078125 -20.796875
|
||||
L 9.078125 54.6875
|
||||
L 18.109375 54.6875
|
||||
L 18.109375 46.390625
|
||||
Q 20.953125 51.265625 25.265625 53.625
|
||||
Q 29.59375 56 35.59375 56
|
||||
Q 45.5625 56 51.78125 48.09375
|
||||
Q 58.015625 40.1875 58.015625 27.296875
|
||||
Q 58.015625 14.40625 51.78125 6.484375
|
||||
Q 45.5625 -1.421875 35.59375 -1.421875
|
||||
Q 29.59375 -1.421875 25.265625 0.953125
|
||||
Q 20.953125 3.328125 18.109375 8.203125
|
||||
z
|
||||
M 48.6875 27.296875
|
||||
Q 48.6875 37.203125 44.609375 42.84375
|
||||
Q 40.53125 48.484375 33.40625 48.484375
|
||||
Q 26.265625 48.484375 22.1875 42.84375
|
||||
Q 18.109375 37.203125 18.109375 27.296875
|
||||
Q 18.109375 17.390625 22.1875 11.75
|
||||
Q 26.265625 6.109375 33.40625 6.109375
|
||||
Q 40.53125 6.109375 44.609375 11.75
|
||||
Q 48.6875 17.390625 48.6875 27.296875
|
||||
z
|
||||
" id="DejaVuSans-112"/>
|
||||
<path d="M 9.421875 75.984375
|
||||
L 18.40625 75.984375
|
||||
L 18.40625 0
|
||||
L 9.421875 0
|
||||
z
|
||||
" id="DejaVuSans-108"/>
|
||||
<path d="M 8.5 21.578125
|
||||
L 8.5 54.6875
|
||||
L 17.484375 54.6875
|
||||
L 17.484375 21.921875
|
||||
Q 17.484375 14.15625 20.5 10.265625
|
||||
Q 23.53125 6.390625 29.59375 6.390625
|
||||
Q 36.859375 6.390625 41.078125 11.03125
|
||||
Q 45.3125 15.671875 45.3125 23.6875
|
||||
L 45.3125 54.6875
|
||||
L 54.296875 54.6875
|
||||
L 54.296875 0
|
||||
L 45.3125 0
|
||||
L 45.3125 8.40625
|
||||
Q 42.046875 3.421875 37.71875 1
|
||||
Q 33.40625 -1.421875 27.6875 -1.421875
|
||||
Q 18.265625 -1.421875 13.375 4.4375
|
||||
Q 8.5 10.296875 8.5 21.578125
|
||||
z
|
||||
M 31.109375 56
|
||||
z
|
||||
" id="DejaVuSans-117"/>
|
||||
</defs>
|
||||
<use xlink:href="#DejaVuSans-48"/>
|
||||
<use x="63.623047" xlink:href="#DejaVuSans-48"/>
|
||||
<use x="127.246094" xlink:href="#DejaVuSans-49"/>
|
||||
<use x="190.869141" xlink:href="#DejaVuSans-105"/>
|
||||
<use x="218.652344" xlink:href="#DejaVuSans-110"/>
|
||||
<use x="282.03125" xlink:href="#DejaVuSans-100"/>
|
||||
<use x="345.507812" xlink:href="#DejaVuSans-105"/>
|
||||
<use x="373.291016" xlink:href="#DejaVuSans-110"/>
|
||||
<use x="436.669922" xlink:href="#DejaVuSans-118"/>
|
||||
<use x="493.224609" xlink:href="#DejaVuSans-45"/>
|
||||
<use x="529.308594" xlink:href="#DejaVuSans-97"/>
|
||||
<use x="590.587891" xlink:href="#DejaVuSans-112"/>
|
||||
<use x="654.064453" xlink:href="#DejaVuSans-97"/>
|
||||
<use x="715.34375" xlink:href="#DejaVuSans-108"/>
|
||||
<use x="743.126953" xlink:href="#DejaVuSans-97"/>
|
||||
<use x="804.40625" xlink:href="#DejaVuSans-99"/>
|
||||
<use x="859.386719" xlink:href="#DejaVuSans-104"/>
|
||||
<use x="922.765625" xlink:href="#DejaVuSans-101"/>
|
||||
<use x="984.289062" xlink:href="#DejaVuSans-45"/>
|
||||
<use x="1020.373047" xlink:href="#DejaVuSans-117"/>
|
||||
<use x="1083.751953" xlink:href="#DejaVuSans-110"/>
|
||||
<use x="1147.130859" xlink:href="#DejaVuSans-115"/>
|
||||
<use x="1199.230469" xlink:href="#DejaVuSans-116"/>
|
||||
<use x="1238.439453" xlink:href="#DejaVuSans-97"/>
|
||||
<use x="1299.71875" xlink:href="#DejaVuSans-98"/>
|
||||
<use x="1363.195312" xlink:href="#DejaVuSans-108"/>
|
||||
<use x="1390.978516" xlink:href="#DejaVuSans-101"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<defs>
|
||||
<clipPath id="p902cfd873e">
|
||||
<rect height="266.112" width="357.12" x="57.6" y="41.472"/>
|
||||
</clipPath>
|
||||
</defs>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 31 KiB |
@@ -0,0 +1,13 @@
|
||||
01:no,02:tool,03:status,04:time_sec,05:depth,05:mem_kb,10:ninit_trans,11:ninit_trans,12:ncells,13:nclauses,14:navg_clause_len
|
||||
1,apalache,NoError,704,1,3215424,0,0,217385,1305718,89
|
||||
2,apalache,NoError,699,1,3195020,0,0,207969,1341979,88
|
||||
3,apalache,NoError,1018,1,4277060,0,0,311798,2028544,101
|
||||
4,apalache,NoError,889,1,4080012,0,0,290989,1951616,103
|
||||
5,apalache,NoError,9,0,577100,0,0,2045,14655,42
|
||||
6,apalache,NoError,10,0,673772,0,0,2913,28213,43
|
||||
7,apalache,NoError,8,0,651008,0,0,2214,17077,44
|
||||
8,apalache,NoError,10,0,683188,0,0,3082,32651,45
|
||||
9,apalache,NoError,340,0,3053848,0,0,196943,889859,108
|
||||
10,apalache,NoError,517,0,6424536,0,0,2856378,3802779,34
|
||||
11,apalache,NoError,587,0,4028516,0,0,284369,1343296,128
|
||||
12,apalache,NoError,880,0,7881148,0,0,4382556,5778072,38
|
||||
|
9
spec/light-client/accountability/run.sh
Executable file
@@ -0,0 +1,9 @@
|
||||
#!/bin/sh
|
||||
#
|
||||
# The script to run all experiments at once
|
||||
|
||||
export SCRIPTS_DIR=~/devl/apalache-tests/scripts
|
||||
export BUILDS="unstable"
|
||||
export BENCHMARK=001indinv-apalache
|
||||
export RUN_SCRIPT=./run-all.sh # alternatively, use ./run-parallel.sh
|
||||
make -e -f ~/devl/apalache-tests/Makefile.common
|
||||
166
spec/light-client/attacks/Blockchain_003_draft.tla
Normal file
@@ -0,0 +1,166 @@
|
||||
------------------------ MODULE Blockchain_003_draft -----------------------------
|
||||
(*
|
||||
This is a high-level specification of Tendermint blockchain
|
||||
that is designed specifically for the light client.
|
||||
Validators have the voting power of one. If you like to model various
|
||||
voting powers, introduce multiple copies of the same validator
|
||||
(do not forget to give them unique names though).
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets, Apalache
|
||||
|
||||
Min(a, b) == IF a < b THEN a ELSE b
|
||||
|
||||
CONSTANT
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
ULTIMATE_HEIGHT,
|
||||
(* a maximal height that can be ever reached (modelling artifact) *)
|
||||
TRUSTING_PERIOD
|
||||
(* the period within which the validators are trusted *)
|
||||
|
||||
Heights == 1..ULTIMATE_HEIGHT (* possible heights *)
|
||||
|
||||
(* A commit is just a set of nodes who have committed the block *)
|
||||
Commits == SUBSET AllNodes
|
||||
|
||||
(* The set of all block headers that can be on the blockchain.
|
||||
This is a simplified version of the Block data structure in the actual implementation. *)
|
||||
BlockHeaders == [
|
||||
height: Heights,
|
||||
\* the block height
|
||||
time: Int,
|
||||
\* the block timestamp in some integer units
|
||||
lastCommit: Commits,
|
||||
\* the nodes who have voted on the previous block, the set itself instead of a hash
|
||||
(* in the implementation, only the hashes of V and NextV are stored in a block,
|
||||
as V and NextV are stored in the application state *)
|
||||
VS: SUBSET AllNodes,
|
||||
\* the validators of this bloc. We store the validators instead of the hash.
|
||||
NextVS: SUBSET AllNodes
|
||||
\* the validators of the next block. We store the next validators instead of the hash.
|
||||
]
|
||||
|
||||
(* A signed header is just a header together with a set of commits *)
|
||||
LightBlocks == [header: BlockHeaders, Commits: Commits]
|
||||
|
||||
VARIABLES
|
||||
refClock,
|
||||
(* the current global time in integer units as perceived by the reference chain *)
|
||||
blockchain,
|
||||
(* A sequence of BlockHeaders, which gives us a bird view of the blockchain. *)
|
||||
Faulty
|
||||
(* A set of faulty nodes, which can act as validators. We assume that the set
|
||||
of faulty processes is non-decreasing. If a process has recovered, it should
|
||||
connect using a different id. *)
|
||||
|
||||
(* all variables, to be used with UNCHANGED *)
|
||||
vars == <<refClock, blockchain, Faulty>>
|
||||
|
||||
(* The set of all correct nodes in a state *)
|
||||
Corr == AllNodes \ Faulty
|
||||
|
||||
(* APALACHE annotations *)
|
||||
a <: b == a \* type annotation
|
||||
|
||||
NT == STRING
|
||||
NodeSet(S) == S <: {NT}
|
||||
EmptyNodeSet == NodeSet({})
|
||||
|
||||
BT == [height |-> Int, time |-> Int, lastCommit |-> {NT}, VS |-> {NT}, NextVS |-> {NT}]
|
||||
|
||||
LBT == [header |-> BT, Commits |-> {NT}]
|
||||
(* end of APALACHE annotations *)
|
||||
|
||||
(****************************** BLOCKCHAIN ************************************)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriod(header) ==
|
||||
refClock < header.time + TRUSTING_PERIOD
|
||||
|
||||
(*
|
||||
Given a function pVotingPower \in D -> Powers for some D \subseteq AllNodes
|
||||
and pNodes \subseteq D, test whether the set pNodes \subseteq AllNodes has
|
||||
more than 2/3 of voting power among the nodes in D.
|
||||
*)
|
||||
TwoThirds(pVS, pNodes) ==
|
||||
LET TP == Cardinality(pVS)
|
||||
SP == Cardinality(pVS \intersect pNodes)
|
||||
IN
|
||||
3 * SP > 2 * TP \* when thinking in real numbers, not integers: SP > 2.0 / 3.0 * TP
|
||||
|
||||
(*
|
||||
Given a set of FaultyNodes, test whether the voting power of the correct nodes in D
|
||||
is more than 2/3 of the voting power of the faulty nodes in D.
|
||||
|
||||
Parameters:
|
||||
- pFaultyNodes is a set of nodes that are considered faulty
|
||||
- pVS is a set of all validators, maybe including Faulty, intersecting with it, etc.
|
||||
- pMaxFaultRatio is a pair <<a, b>> that limits the ratio a / b of the faulty
|
||||
validators from above (exclusive)
|
||||
*)
|
||||
FaultyValidatorsFewerThan(pFaultyNodes, pVS, maxRatio) ==
|
||||
LET FN == pFaultyNodes \intersect pVS \* faulty nodes in pNodes
|
||||
CN == pVS \ pFaultyNodes \* correct nodes in pNodes
|
||||
CP == Cardinality(CN) \* power of the correct nodes
|
||||
FP == Cardinality(FN) \* power of the faulty nodes
|
||||
IN
|
||||
\* CP + FP = TP is the total voting power
|
||||
LET TP == CP + FP IN
|
||||
FP * maxRatio[2] < TP * maxRatio[1]
|
||||
|
||||
(* Can a block be produced by a correct peer, or an authenticated Byzantine peer *)
|
||||
IsLightBlockAllowedByDigitalSignatures(ht, block) ==
|
||||
\/ block.header = blockchain[ht] \* signed by correct and faulty (maybe)
|
||||
\/ /\ block.Commits \subseteq Faulty
|
||||
/\ block.header.height = ht
|
||||
/\ block.header.time >= 0 \* signed only by faulty
|
||||
|
||||
(*
|
||||
Initialize the blockchain to the ultimate height right in the initial states.
|
||||
We pick the faulty validators statically, but that should not affect the light client.
|
||||
|
||||
Parameters:
|
||||
- pMaxFaultyRatioExclusive is a pair <<a, b>> that bound the number of
|
||||
faulty validators in each block by the ratio a / b (exclusive)
|
||||
*)
|
||||
InitToHeight(pMaxFaultyRatioExclusive) ==
|
||||
/\ \E Nodes \in SUBSET AllNodes:
|
||||
Faulty := Nodes \* pick a subset of nodes to be faulty
|
||||
\* pick the validator sets and last commits
|
||||
/\ \E vs, lastCommit \in [Heights -> SUBSET AllNodes]:
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
\* refClock is at least as early as the timestamp in the last block
|
||||
/\ \E tm \in Int:
|
||||
refClock := tm /\ tm >= timestamp[ULTIMATE_HEIGHT]
|
||||
\* the genesis starts on day 1
|
||||
/\ timestamp[1] = 1
|
||||
/\ vs[1] = AllNodes
|
||||
/\ lastCommit[1] = EmptyNodeSet
|
||||
/\ \A h \in Heights \ {1}:
|
||||
/\ lastCommit[h] \subseteq vs[h - 1] \* the non-validators cannot commit
|
||||
/\ TwoThirds(vs[h - 1], lastCommit[h]) \* the commit has >2/3 of validator votes
|
||||
\* the faulty validators have the power below the threshold
|
||||
/\ FaultyValidatorsFewerThan(Faulty, vs[h], pMaxFaultyRatioExclusive)
|
||||
/\ timestamp[h] > timestamp[h - 1] \* the time grows monotonically
|
||||
/\ timestamp[h] < timestamp[h - 1] + TRUSTING_PERIOD \* but not too fast
|
||||
\* form the block chain out of validator sets and commits (this makes apalache faster)
|
||||
/\ blockchain := [h \in Heights |->
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> IF h < ULTIMATE_HEIGHT THEN vs[h + 1] ELSE AllNodes,
|
||||
lastCommit |-> lastCommit[h]]
|
||||
] \******
|
||||
|
||||
(********************* BLOCKCHAIN ACTIONS ********************************)
|
||||
(*
|
||||
Advance the clock by zero or more time units.
|
||||
*)
|
||||
AdvanceTime ==
|
||||
/\ \E tm \in Int: tm >= refClock /\ refClock' = tm
|
||||
/\ UNCHANGED <<blockchain, Faulty>>
|
||||
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Wed Jun 10 14:10:54 CEST 2020 by igor
|
||||
\* Created Fri Oct 11 15:45:11 CEST 2019 by igor
|
||||
159
spec/light-client/attacks/Isolation_001_draft.tla
Normal file
@@ -0,0 +1,159 @@
|
||||
----------------------- MODULE Isolation_001_draft ----------------------------
|
||||
(**
|
||||
* The specification of the attackers isolation at full node,
|
||||
* when it has received an evidence from the light client.
|
||||
* We check that the isolation spec produces a set of validators
|
||||
* that have more than 1/3 of the voting power.
|
||||
*
|
||||
* It follows the English specification:
|
||||
*
|
||||
* https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/attacks/isolate-attackers_001_draft.md
|
||||
*
|
||||
* The assumptions made in this specification:
|
||||
*
|
||||
* - the voting power of every validator is 1
|
||||
* (add more validators, if you need more validators)
|
||||
*
|
||||
* - Tendermint security model is violated
|
||||
* (there are Byzantine validators who signed a conflicting block)
|
||||
*
|
||||
* Igor Konnov, Zarko Milosevic, Josef Widder, Informal Systems, 2020
|
||||
*)
|
||||
|
||||
|
||||
EXTENDS Integers, FiniteSets, Apalache
|
||||
|
||||
\* algorithm parameters
|
||||
CONSTANTS
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
COMMON_HEIGHT,
|
||||
(* an index of the block header that two peers agree upon *)
|
||||
CONFLICT_HEIGHT,
|
||||
(* an index of the block header that two peers disagree upon *)
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
FAULTY_RATIO
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the chain at the full node *)
|
||||
refClock, (* the reference clock at the full node *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
conflictingBlock, (* an evidence that two peers reported conflicting blocks *)
|
||||
state, (* the state of the attack isolation machine at the full node *)
|
||||
attackers (* the set of the identified attackers *)
|
||||
|
||||
vars == <<blockchain, refClock, Faulty, conflictingBlock, state>>
|
||||
|
||||
\* instantiate the chain at the full node
|
||||
ULTIMATE_HEIGHT == CONFLICT_HEIGHT + 1
|
||||
BC == INSTANCE Blockchain_003_draft
|
||||
|
||||
\* use the light client API
|
||||
TRUSTING_HEIGHT == COMMON_HEIGHT
|
||||
TARGET_HEIGHT == CONFLICT_HEIGHT
|
||||
|
||||
LC == INSTANCE LCVerificationApi_003_draft
|
||||
WITH localClock <- refClock, REAL_CLOCK_DRIFT <- 0, CLOCK_DRIFT <- 0
|
||||
|
||||
\* old-style type annotations in apalache
|
||||
a <: b == a
|
||||
|
||||
\* [LCAI-NONVALID-OUTPUT.1::TLA.1]
|
||||
ViolatesValidity(header1, header2) ==
|
||||
\/ header1.VS /= header2.VS
|
||||
\/ header1.NextVS /= header2.NextVS
|
||||
\/ header1.height /= header2.height
|
||||
\/ header1.time /= header2.time
|
||||
(* The English specification also checks the fields that we do not have
|
||||
at this level of abstraction:
|
||||
- header1.ConsensusHash != header2.ConsensusHash or
|
||||
- header1.AppHash != header2.AppHash or
|
||||
- header1.LastResultsHash header2 != ev.LastResultsHash
|
||||
*)
|
||||
|
||||
Init ==
|
||||
/\ state := "init"
|
||||
\* Pick an arbitrary blockchain from 1 to COMMON_HEIGHT + 1.
|
||||
/\ BC!InitToHeight(FAULTY_RATIO) \* initializes blockchain, Faulty, and refClock
|
||||
/\ attackers := {} <: {STRING} \* attackers are unknown
|
||||
\* Receive an arbitrary evidence.
|
||||
\* Instantiate the light block fields one by one,
|
||||
\* to avoid combinatorial explosion of records.
|
||||
/\ \E time \in Int:
|
||||
\E VS, NextVS, lastCommit, Commits \in SUBSET AllNodes:
|
||||
LET conflicting ==
|
||||
[ Commits |-> Commits,
|
||||
header |->
|
||||
[height |-> CONFLICT_HEIGHT,
|
||||
time |-> time,
|
||||
VS |-> VS,
|
||||
NextVS |-> NextVS,
|
||||
lastCommit |-> lastCommit] ]
|
||||
IN
|
||||
LET refBlock == [ header |-> blockchain[COMMON_HEIGHT],
|
||||
Commits |-> blockchain[COMMON_HEIGHT + 1].lastCommit ]
|
||||
IN
|
||||
/\ "SUCCESS" = LC!ValidAndVerifiedUntimed(refBlock, conflicting)
|
||||
\* More than third of next validators in the common reference block
|
||||
\* is faulty. That is a precondition for a fork.
|
||||
/\ 3 * Cardinality(Faulty \intersect refBlock.header.NextVS)
|
||||
> Cardinality(refBlock.header.NextVS)
|
||||
\* correct validators cannot sign an invalid block
|
||||
/\ ViolatesValidity(conflicting.header, refBlock.header)
|
||||
=> conflicting.Commits \subseteq Faulty
|
||||
/\ conflictingBlock := conflicting
|
||||
|
||||
|
||||
\* This is a specification of isolateMisbehavingProcesses.
|
||||
\*
|
||||
\* [LCAI-FUNC-MAIN.1::TLA.1]
|
||||
Next ==
|
||||
/\ state = "init"
|
||||
\* Extract the rounds from the reference block and the conflicting block.
|
||||
\* In this specification, we just pick rounds non-deterministically.
|
||||
\* The English specification calls RoundOf on the blocks.
|
||||
/\ \E referenceRound, evidenceRound \in Int:
|
||||
/\ referenceRound >= 0 /\ evidenceRound >= 0
|
||||
/\ LET reference == blockchain[CONFLICT_HEIGHT]
|
||||
referenceCommit == blockchain[CONFLICT_HEIGHT + 1].lastCommit
|
||||
evidenceHeader == conflictingBlock.header
|
||||
evidenceCommit == conflictingBlock.Commits
|
||||
IN
|
||||
IF ViolatesValidity(reference, evidenceHeader)
|
||||
THEN /\ attackers' := blockchain[COMMON_HEIGHT].NextVS \intersect evidenceCommit
|
||||
/\ state' := "Lunatic"
|
||||
ELSE IF referenceRound = evidenceRound
|
||||
THEN /\ attackers' := referenceCommit \intersect evidenceCommit
|
||||
/\ state' := "Equivocation"
|
||||
ELSE
|
||||
\* This property is shown in property
|
||||
\* Accountability of TendermintAcc3.tla
|
||||
/\ state' := "Amnesia"
|
||||
/\ \E Attackers \in SUBSET (Faulty \intersect reference.VS):
|
||||
/\ 3 * Cardinality(Attackers) > Cardinality(reference.VS)
|
||||
/\ attackers' := Attackers
|
||||
/\ blockchain' := blockchain
|
||||
/\ refClock' := refClock
|
||||
/\ Faulty' := Faulty
|
||||
/\ conflictingBlock' := conflictingBlock
|
||||
|
||||
(********************************** INVARIANTS *******************************)
|
||||
|
||||
\* This invariant ensure that the attackers have
|
||||
\* more than 1/3 of the voting power
|
||||
\*
|
||||
\* [LCAI-INV-Output.1::TLA-DETECTION-COMPLETENESS.1]
|
||||
DetectionCompleteness ==
|
||||
state /= "init" =>
|
||||
3 * Cardinality(attackers) > Cardinality(blockchain[CONFLICT_HEIGHT].VS)
|
||||
|
||||
\* This invariant ensures that only the faulty validators are detected
|
||||
\*
|
||||
\* [LCAI-INV-Output.1::TLA-DETECTION-ACCURACY.1]
|
||||
DetectionAccuracy ==
|
||||
attackers \subseteq Faulty
|
||||
|
||||
==============================================================================
|
||||
192
spec/light-client/attacks/LCVerificationApi_003_draft.tla
Normal file
@@ -0,0 +1,192 @@
|
||||
-------------------- MODULE LCVerificationApi_003_draft --------------------------
|
||||
(**
|
||||
* The common interface of the light client verification and detection.
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
CLOCK_DRIFT,
|
||||
(* the assumed precision of the clock *)
|
||||
REAL_CLOCK_DRIFT,
|
||||
(* the actual clock drift, which under normal circumstances should not
|
||||
be larger than CLOCK_DRIFT (otherwise, there will be a bug) *)
|
||||
FAULTY_RATIO
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
|
||||
VARIABLES
|
||||
localClock (* current time as measured by the light client *)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriodLocal(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - CLOCK_DRIFT
|
||||
|
||||
(* the header is still within the trusting period, even if the clock can go backwards *)
|
||||
InTrustingPeriodLocalSurely(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - 2 * CLOCK_DRIFT
|
||||
|
||||
(* ensure that the local clock does not drift far away from the global clock *)
|
||||
IsLocalClockWithinDrift(local, global) ==
|
||||
/\ global - REAL_CLOCK_DRIFT <= local
|
||||
/\ local <= global + REAL_CLOCK_DRIFT
|
||||
|
||||
(**
|
||||
* Check that the commits in an untrusted block form 1/3 of the next validators
|
||||
* in a trusted header.
|
||||
*)
|
||||
SignedByOneThirdOfTrusted(trusted, untrusted) ==
|
||||
LET TP == Cardinality(trusted.header.NextVS)
|
||||
SP == Cardinality(untrusted.Commits \intersect trusted.header.NextVS)
|
||||
IN
|
||||
3 * SP > TP
|
||||
|
||||
(**
|
||||
The first part of the precondition of ValidAndVerified, which does not take
|
||||
the current time into account.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedPreUntimed(trusted, untrusted) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ thdr.height < uhdr.height
|
||||
\* the trusted block has been created earlier
|
||||
/\ thdr.time < uhdr.time
|
||||
/\ untrusted.Commits \subseteq uhdr.VS
|
||||
/\ LET TP == Cardinality(uhdr.VS)
|
||||
SP == Cardinality(untrusted.Commits)
|
||||
IN
|
||||
3 * SP > 2 * TP
|
||||
/\ thdr.height + 1 = uhdr.height => thdr.NextVS = uhdr.VS
|
||||
(* As we do not have explicit hashes we ignore these three checks of the English spec:
|
||||
|
||||
1. "trusted.Commit is a commit is for the header trusted.Header,
|
||||
i.e. it contains the correct hash of the header".
|
||||
2. untrusted.Validators = hash(untrusted.Header.Validators)
|
||||
3. untrusted.NextValidators = hash(untrusted.Header.NextValidators)
|
||||
*)
|
||||
|
||||
(**
|
||||
Check the precondition of ValidAndVerified, including the time checks.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE.1]
|
||||
*)
|
||||
ValidAndVerifiedPre(trusted, untrusted, checkFuture) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ InTrustingPeriodLocal(thdr)
|
||||
\* The untrusted block is not from the future (modulo clock drift).
|
||||
\* Do the check, if it is required.
|
||||
/\ checkFuture => uhdr.time < localClock + CLOCK_DRIFT
|
||||
/\ ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
This test does take current time into account, but only looks at the block structure.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedUntimed(trusted, untrusted) ==
|
||||
IF ~ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
THEN "INVALID"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA.1]
|
||||
*)
|
||||
ValidAndVerified(trusted, untrusted, checkFuture) ==
|
||||
IF ~ValidAndVerifiedPre(trusted, untrusted, checkFuture)
|
||||
THEN "INVALID"
|
||||
ELSE IF ~InTrustingPeriodLocal(untrusted.header)
|
||||
(* We leave the following test for the documentation purposes.
|
||||
The implementation should do this test, as signature verification may be slow.
|
||||
In the TLA+ specification, ValidAndVerified happens in no time.
|
||||
*)
|
||||
THEN "FAILED_TRUSTING_PERIOD"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
|
||||
(**
|
||||
The invariant of the light store that is not related to the blockchain
|
||||
*)
|
||||
LightStoreInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] /= "StateVerified"
|
||||
\/ lightBlockStatus[rh] /= "StateVerified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ LET lhdr == fetchedLightBlocks[lh]
|
||||
rhdr == fetchedLightBlocks[rh]
|
||||
IN
|
||||
\* we can verify the right one using the left one
|
||||
"SUCCESS" = ValidAndVerifiedUntimed(lhdr, rhdr)
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks.
|
||||
* (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
(**
|
||||
The expected post-condition of VerifyToTarget.
|
||||
*)
|
||||
VerifyToTargetPost(blockchain, isPeerCorrect,
|
||||
fetchedLightBlocks, lightBlockStatus,
|
||||
trustedHeight, targetHeight, finalState) ==
|
||||
LET trustedHeader == fetchedLightBlocks[trustedHeight].header IN
|
||||
\* The light client is not lying us on the trusted block.
|
||||
\* It is straightforward to detect.
|
||||
/\ lightBlockStatus[trustedHeight] = "StateVerified"
|
||||
/\ trustedHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ trustedHeader = blockchain[trustedHeight]
|
||||
\* the invariants we have found in the light client verification
|
||||
\* there is a problem with trusting period
|
||||
/\ isPeerCorrect
|
||||
=> CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus)
|
||||
\* a correct peer should fail the light client,
|
||||
\* if the trusted block is in the trusting period
|
||||
/\ isPeerCorrect /\ InTrustingPeriodLocalSurely(trustedHeader)
|
||||
=> finalState = "finishedSuccess"
|
||||
/\ finalState = "finishedSuccess" =>
|
||||
/\ lightBlockStatus[targetHeight] = "StateVerified"
|
||||
/\ targetHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus)
|
||||
/\ LightStoreInv(fetchedLightBlocks, lightBlockStatus)
|
||||
|
||||
|
||||
==================================================================================
|
||||
18
spec/light-client/attacks/MC_5_3.tla
Normal file
@@ -0,0 +1,18 @@
|
||||
------------------------- MODULE MC_5_3 -------------------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
COMMON_HEIGHT == 1
|
||||
CONFLICT_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
FAULTY_RATIO == <<1, 2>> \* < 1 / 2 faulty validators
|
||||
|
||||
VARIABLES
|
||||
blockchain, \* the reference blockchain
|
||||
refClock, \* current time in the reference blockchain
|
||||
Faulty, \* the set of faulty validators
|
||||
state, \* the state of the light client detector
|
||||
conflictingBlock, \* an evidence that two peers reported conflicting blocks
|
||||
attackers
|
||||
|
||||
INSTANCE Isolation_001_draft
|
||||
============================================================================
|
||||
221
spec/light-client/attacks/isolate-attackers_001_draft.md
Normal file
@@ -0,0 +1,221 @@
|
||||
|
||||
# Lightclient Attackers Isolation
|
||||
|
||||
> Warning: This is the beginning of an unfinished draft. Don't continue reading!
|
||||
|
||||
Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules.
|
||||
|
||||
As Tendermint consensus and light client verification is safe under the assumption of more than 2/3 of correct voting power per block [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link], this implies that if there was an attack then [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] was violated, that is, there is a block such that
|
||||
|
||||
- validators deviated from the protocol, and
|
||||
- these validators represent more than 1/3 of the voting power in that block.
|
||||
|
||||
In the case of an [attack][node-based-attack-characterization], the lightclient [attack detection mechanism][detection] computes data, so called evidence [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link], that can be used
|
||||
|
||||
- to proof that there has been attack [[TMBC-LC-EVIDENCE-DATA.1]][TMBC-LC-EVIDENCE-DATA-link] and
|
||||
- as basis to find the actual nodes that deviated from the Tendermint protocol.
|
||||
|
||||
This specification considers how a full node in a Tendermint blockchain can isolate a set of attackers that launched the attack. The set should satisfy
|
||||
|
||||
- the set does not contain a correct validator
|
||||
- the set contains validators that represent more than 1/3 of the voting power of a block that is still within the unbonding period
|
||||
|
||||
# Outline
|
||||
|
||||
**TODO** when preparing a version for broader review.
|
||||
|
||||
# Part I - Basics
|
||||
|
||||
For definitions of data structures used here, in particular LightBlocks [[LCV-DATA-LIGHTBLOCK.1]](https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightblock1), cf. [Light Client Verification][verification].
|
||||
|
||||
# Part II - Definition of the Problem
|
||||
|
||||
The specification of the [detection mechanism][detection] describes
|
||||
|
||||
- what is a light client attack,
|
||||
- conditions under which the detector will detect a light client attack,
|
||||
- and the format of the output data, called evidence, in the case an attack is detected. The format is defined in
|
||||
[[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link] and looks as follows
|
||||
|
||||
```go
|
||||
type LightClientAttackEvidence struct {
|
||||
ConflictingBlock LightBlock
|
||||
CommonHeight int64
|
||||
}
|
||||
```
|
||||
|
||||
The isolator is a function that gets as input evidence `ev`
|
||||
and a prefix of the blockchain `bc` at least up to height `ev.ConflictingBlock.Header.Height + 1`. The output is a set of *peerIDs* of validators.
|
||||
|
||||
We assume that the full node is synchronized with the blockchain and has reached the height `ev.ConflictingBlock.Header.Height + 1`.
|
||||
|
||||
#### **[FN-INV-Output.1]**
|
||||
|
||||
When an output is generated it satisfies the following properties:
|
||||
|
||||
- If
|
||||
- `bc[CommonHeight].bfttime` is within the unbonding period w.r.t. the time at the full node,
|
||||
- `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]`
|
||||
- Validators in `ev.ConflictingBlock.Commit` represent more than 1/3 of the voting power in `bc[ev.CommonHeight].NextValidators`
|
||||
- Then: A set of validators in `bc[CommonHeight].NextValidators` that
|
||||
- represent more than 1/3 of the voting power in `bc[ev.commonHeight].NextValidators`
|
||||
- signed Tendermint consensus messages for height `ev.ConflictingBlock.Header.Height` by violating the Tendermint consensus protocol.
|
||||
- Else: the empty set.
|
||||
|
||||
# Part IV - Protocol
|
||||
|
||||
Here we discuss how to solve the problem of isolating misbehaving processes. We describe the function `isolateMisbehavingProcesses` as well as all the helping functions below. In [Part V](#part-v---Completeness), we discuss why the solution is complete based on result from analysis with automated tools.
|
||||
|
||||
## Isolation
|
||||
|
||||
### Outline
|
||||
|
||||
> Describe solution (in English), decomposition into functions, where communication to other components happens.
|
||||
|
||||
#### **[LCAI-FUNC-MAIN.1]**
|
||||
|
||||
```go
|
||||
func isolateMisbehavingProcesses(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress {
|
||||
|
||||
reference := bc[ev.conflictingBlock.Header.Height].Header
|
||||
ev_header := ev.conflictingBlock.Header
|
||||
|
||||
ref_commit := bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit // + 1 !!
|
||||
ev_commit := ev.conflictingBlock.Commit
|
||||
|
||||
if violatesTMValidity(reference, ev_header) {
|
||||
// lunatic light client attack
|
||||
signatories := Signers(ev.ConflictingBlock.Commit)
|
||||
bonded_vals := Addresses(bc[ev.CommonHeight].NextValidators)
|
||||
return intersection(signatories,bonded_vals)
|
||||
|
||||
}
|
||||
// If this point is reached the validator sets in reference and ev_header are identical
|
||||
else if RoundOf(ref_commit) == RoundOf(ev_commit) {
|
||||
// equivocation light client attack
|
||||
return intersection(Signers(ref_commit), Signers(ev_commit))
|
||||
}
|
||||
else {
|
||||
// amnesia light client attack
|
||||
return IsolateAmnesiaAttacker(ev, bc)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Implementation comment
|
||||
- If the full node has only reached height `ev.conflictingBlock.Header.Height` then `bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit` refers to the locally stored commit for this height. (This commit must be present by the precondition on `length(bc)`.)
|
||||
- We check in the precondition that the unbonding period is not expired. However, since time moves on, before handing the validators over Cosmos SDK, the time needs to be checked again to satisfy the contract which requires that only bonded validators are reported. This passing of validators to the SDK is out of scope of this specification.
|
||||
- Expected precondition
|
||||
- `length(bc) >= ev.conflictingBlock.Header.Height`
|
||||
- `ValidAndVerifiedUnbonding(bc[ev.CommonHeight], ev.ConflictingBlock) == SUCCESS`
|
||||
- `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]`
|
||||
- TODO: input light blocks pass basic validation
|
||||
- Expected postcondition
|
||||
- [[FN-INV-Output.1]](#FN-INV-Output1) holds
|
||||
- Error condition
|
||||
- returns an error if precondition is violated.
|
||||
|
||||
### Details of the Functions
|
||||
|
||||
#### **[LCAI-FUNC-VVU.1]**
|
||||
|
||||
```go
|
||||
func ValidAndVerifiedUnbonding(trusted LightBlock, untrusted LightBlock) Result
|
||||
```
|
||||
|
||||
- Conditions are identical to [[LCV-FUNC-VALID.2]][LCV-FUNC-VALID.link] except the precondition "*trusted.Header.Time > now - trustingPeriod*" is substituted with
|
||||
- `trusted.Header.Time > now - UnbondingPeriod`
|
||||
|
||||
#### **[LCAI-FUNC-NONVALID.1]**
|
||||
|
||||
```go
|
||||
func violatesTMValidity(ref Header, ev Header) boolean
|
||||
```
|
||||
|
||||
- Implementation remarks
|
||||
- checks whether the evidence header `ev` violates the validity property of Tendermint Consensus, by checking agains a reference header
|
||||
- Expected precondition
|
||||
- `ref.Height == ev.Height`
|
||||
- Expected postcondition
|
||||
- returns evaluation of the following disjunction
|
||||
**[[LCAI-NONVALID-OUTPUT.1]]** ==
|
||||
`ref.ValidatorsHash != ev.ValidatorsHash` or
|
||||
`ref.NextValidatorsHash != ev.NextValidatorsHash` or
|
||||
`ref.ConsensusHash != ev.ConsensusHash` or
|
||||
`ref.AppHash != ev.AppHash` or
|
||||
`ref.LastResultsHash != ev.LastResultsHash`
|
||||
|
||||
```go
|
||||
func IsolateAmnesiaAttacker(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Implementation remarks
|
||||
**TODO:** What should we do here? Refer to the accountability doc?
|
||||
- Expected postcondition
|
||||
**TODO:** What should we do here? Refer to the accountability doc?
|
||||
|
||||
```go
|
||||
func RoundOf(commit Commit) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- `commit` is well-formed. In particular all votes are from the same round `r`.
|
||||
- Expected postcondition
|
||||
- returns round `r` that is encoded in all the votes of the commit
|
||||
|
||||
```go
|
||||
func Signers(commit Commit) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns all validator addresses in `commit`
|
||||
|
||||
```go
|
||||
func Addresses(vals Validator[]) ValidatorAddress[]
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns all validator addresses in `vals`
|
||||
|
||||
# Part V - Completeness
|
||||
|
||||
As discussed in the beginning of this document, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules.
|
||||
The main function `isolateMisbehavingProcesses` distinguishes three kinds of wrongly signing messages, namely,
|
||||
|
||||
- lunatic: signing invalid blocks
|
||||
- equivocation: double-signing valid blocks in the same consensus round
|
||||
- amnesia: signing conflicting blocks in different consensus rounds, without having seen a quorum of messages that would have allowed to do so.
|
||||
|
||||
The question is whether this captures all attacks.
|
||||
First observe that the first checking in `isolateMisbehavingProcesses` is `violatesTMValidity`. It takes care of lunatic attacks. If this check passes, that is, if `violatesTMValidity` returns `FALSE` this means that [FN-NONVALID-OUTPUT] evaluates to false, which implies that `ref.ValidatorsHash = ev.ValidatorsHash`. Hence after `violatesTMValidity`, all the involved validators are the ones from the blockchain. It is thus sufficient to analyze one instance of Tendermint consensus with a fixed group membership (set of validators). Also it is sufficient to consider two different valid consensus values, that is, binary consensus.
|
||||
|
||||
**TODO** we have analyzed Tendermint consensus with TLA+ and have accompanied Galois in an independent study of the protocol based on [Ivy proofs](https://github.com/tendermint/spec/tree/master/ivy-proofs).
|
||||
|
||||
# References
|
||||
|
||||
[[supervisor]] The specification of the light client supervisor.
|
||||
|
||||
[[verification]] The specification of the light client verification protocol
|
||||
|
||||
[[detection]] The specification of the light client attack detection mechanism.
|
||||
|
||||
[supervisor]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md
|
||||
|
||||
[verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md
|
||||
|
||||
[detection]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md
|
||||
|
||||
[LC-DATA-EVIDENCE-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#lc-data-evidence1
|
||||
|
||||
[TMBC-LC-EVIDENCE-DATA-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#tmbc-lc-evidence-data1
|
||||
|
||||
[node-based-attack-characterization]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#node-based-characterization-of-attacks
|
||||
|
||||
[TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-fm-2thirds1
|
||||
|
||||
[LCV-FUNC-VALID.link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-valid2
|
||||
223
spec/light-client/attacks/isolate-attackers_002_reviewed.md
Normal file
@@ -0,0 +1,223 @@
|
||||
# Lightclient Attackers Isolation
|
||||
|
||||
Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules.
|
||||
|
||||
As Tendermint consensus and light client verification is safe under the assumption of more than 2/3 of correct voting power per block [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link], this implies that if there was an attack then [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] was violated, that is, there is a block such that
|
||||
|
||||
- validators deviated from the protocol, and
|
||||
- these validators represent more than 1/3 of the voting power in that block.
|
||||
|
||||
In the case of an [attack][node-based-attack-characterization], the lightclient [attack detection mechanism][detection] computes data, so called evidence [[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link], that can be used
|
||||
|
||||
- to proof that there has been attack [[TMBC-LC-EVIDENCE-DATA.1]][TMBC-LC-EVIDENCE-DATA-link] and
|
||||
- as basis to find the actual nodes that deviated from the Tendermint protocol.
|
||||
|
||||
This specification considers how a full node in a Tendermint blockchain can isolate a set of attackers that launched the attack. The set should satisfy
|
||||
|
||||
- the set does not contain a correct validator
|
||||
- the set contains validators that represent more than 1/3 of the voting power of a block that is still within the unbonding period
|
||||
|
||||
# Outline
|
||||
|
||||
After providing the [problem statement](#Part-I---Basics-and-Definition-of-the-Problem), we specify the [isolator function](#Part-II---Protocol) and close with the discussion about its [correctness](#Part-III---Completeness) which is based on computer-aided analysis of Tendermint Consensus.
|
||||
|
||||
# Part I - Basics and Definition of the Problem
|
||||
|
||||
For definitions of data structures used here, in particular LightBlocks [[LCV-DATA-LIGHTBLOCK.1]](https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightblock1), we refer to the specification of [Light Client Verification][verification].
|
||||
|
||||
The specification of the [detection mechanism][detection] describes
|
||||
|
||||
- what is a light client attack,
|
||||
- conditions under which the detector will detect a light client attack,
|
||||
- and the format of the output data, called evidence, in the case an attack is detected. The format is defined in
|
||||
[[LC-DATA-EVIDENCE.1]][LC-DATA-EVIDENCE-link] and looks as follows
|
||||
|
||||
```go
|
||||
type LightClientAttackEvidence struct {
|
||||
ConflictingBlock LightBlock
|
||||
CommonHeight int64
|
||||
}
|
||||
```
|
||||
|
||||
The isolator is a function that gets as input evidence `ev`
|
||||
and a prefix of the blockchain `bc` at least up to height `ev.ConflictingBlock.Header.Height + 1`. The output is a set of *peerIDs* of validators.
|
||||
|
||||
We assume that the full node is synchronized with the blockchain and has reached the height `ev.ConflictingBlock.Header.Height + 1`.
|
||||
|
||||
#### **[LCAI-INV-Output.1]**
|
||||
|
||||
When an output is generated it satisfies the following properties:
|
||||
|
||||
- If
|
||||
- `bc[CommonHeight].bfttime` is within the unbonding period w.r.t. the time at the full node,
|
||||
- `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]`
|
||||
- Validators in `ev.ConflictingBlock.Commit` represent more than 1/3 of the voting power in `bc[ev.CommonHeight].NextValidators`
|
||||
- Then: The output is a set of validators in `bc[CommonHeight].NextValidators` that
|
||||
- represent more than 1/3 of the voting power in `bc[ev.commonHeight].NextValidators`
|
||||
- signed Tendermint consensus messages for height `ev.ConflictingBlock.Header.Height` by violating the Tendermint consensus protocol.
|
||||
- Else: the empty set.
|
||||
|
||||
# Part II - Protocol
|
||||
|
||||
Here we discuss how to solve the problem of isolating misbehaving processes. We describe the function `isolateMisbehavingProcesses` as well as all the helping functions below. In [Part III](#part-III---Completeness), we discuss why the solution is complete based on result from analysis with automated tools.
|
||||
|
||||
## Isolation
|
||||
|
||||
### Outline
|
||||
|
||||
We first check whether the conflicting block can indeed be verified from the common height. We then first check whether it was a lunatic attack (violating validity). If this is not the case, we check for equivocation. If this also is not the case, we start the on-chain [accountability protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit).
|
||||
|
||||
#### **[LCAI-FUNC-MAIN.1]**
|
||||
|
||||
```go
|
||||
func isolateMisbehavingProcesses(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress {
|
||||
|
||||
reference := bc[ev.conflictingBlock.Header.Height].Header
|
||||
ev_header := ev.conflictingBlock.Header
|
||||
|
||||
ref_commit := bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit // + 1 !!
|
||||
ev_commit := ev.conflictingBlock.Commit
|
||||
|
||||
if violatesTMValidity(reference, ev_header) {
|
||||
// lunatic light client attack
|
||||
signatories := Signers(ev.ConflictingBlock.Commit)
|
||||
bonded_vals := Addresses(bc[ev.CommonHeight].NextValidators)
|
||||
return intersection(signatories,bonded_vals)
|
||||
|
||||
}
|
||||
// If this point is reached the validator sets in reference and ev_header are identical
|
||||
else if RoundOf(ref_commit) == RoundOf(ev_commit) {
|
||||
// equivocation light client attack
|
||||
return intersection(Signers(ref_commit), Signers(ev_commit))
|
||||
}
|
||||
else {
|
||||
// amnesia light client attack
|
||||
return IsolateAmnesiaAttacker(ev, bc)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Implementation comment
|
||||
- If the full node has only reached height `ev.conflictingBlock.Header.Height` then `bc[ev.conflictingBlock.Header.Height + 1].Header.LastCommit` refers to the locally stored commit for this height. (This commit must be present by the precondition on `length(bc)`.)
|
||||
- We check in the precondition that the unbonding period is not expired. However, since time moves on, before handing the validators over Cosmos SDK, the time needs to be checked again to satisfy the contract which requires that only bonded validators are reported. This passing of validators to the SDK is out of scope of this specification.
|
||||
- Expected precondition
|
||||
- `length(bc) >= ev.conflictingBlock.Header.Height`
|
||||
- `ValidAndVerifiedUnbonding(bc[ev.CommonHeight], ev.ConflictingBlock) == SUCCESS`
|
||||
- `ev.ConflictingBlock.Header != bc[ev.ConflictingBlock.Header.Height]`
|
||||
- `ev.conflictingBlock` satisfies basic validation (in particular all signed messages in the Commit are from the same round)
|
||||
- Expected postcondition
|
||||
- [[FN-INV-Output.1]](#FN-INV-Output1) holds
|
||||
- Error condition
|
||||
- returns an error if precondition is violated.
|
||||
|
||||
### Details of the Functions
|
||||
|
||||
#### **[LCAI-FUNC-VVU.1]**
|
||||
|
||||
```go
|
||||
func ValidAndVerifiedUnbonding(trusted LightBlock, untrusted LightBlock) Result
|
||||
```
|
||||
|
||||
- Conditions are identical to [[LCV-FUNC-VALID.2]][LCV-FUNC-VALID.link] except the precondition "*trusted.Header.Time > now - trustingPeriod*" is substituted with
|
||||
- `trusted.Header.Time > now - UnbondingPeriod`
|
||||
|
||||
#### **[LCAI-FUNC-NONVALID.1]**
|
||||
|
||||
```go
|
||||
func violatesTMValidity(ref Header, ev Header) boolean
|
||||
```
|
||||
|
||||
- Implementation remarks
|
||||
- checks whether the evidence header `ev` violates the validity property of Tendermint Consensus, by checking against a reference header
|
||||
- Expected precondition
|
||||
- `ref.Height == ev.Height`
|
||||
- Expected postcondition
|
||||
- returns evaluation of the following disjunction
|
||||
**[LCAI-NONVALID-OUTPUT.1]** ==
|
||||
`ref.ValidatorsHash != ev.ValidatorsHash` or
|
||||
`ref.NextValidatorsHash != ev.NextValidatorsHash` or
|
||||
`ref.ConsensusHash != ev.ConsensusHash` or
|
||||
`ref.AppHash != ev.AppHash` or
|
||||
`ref.LastResultsHash != ev.LastResultsHash`
|
||||
|
||||
```go
|
||||
func IsolateAmnesiaAttacker(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Implementation remarks
|
||||
- This triggers the [query/response protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit).
|
||||
- Expected postcondition
|
||||
- returns attackers according to [LCAI-INV-Output.1].
|
||||
|
||||
```go
|
||||
func RoundOf(commit Commit) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- `commit` is well-formed. In particular all votes are from the same round `r`.
|
||||
- Expected postcondition
|
||||
- returns round `r` that is encoded in all the votes of the commit
|
||||
- Error condition
|
||||
- reports error if precondition is violated
|
||||
|
||||
```go
|
||||
func Signers(commit Commit) []ValidatorAddress
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns all validator addresses in `commit`
|
||||
|
||||
```go
|
||||
func Addresses(vals Validator[]) ValidatorAddress[]
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns all validator addresses in `vals`
|
||||
|
||||
# Part III - Completeness
|
||||
|
||||
As discussed in the beginning of this document, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules.
|
||||
The main function `isolateMisbehavingProcesses` distinguishes three kinds of wrongly signed messages, namely,
|
||||
|
||||
- lunatic: signing invalid blocks
|
||||
- equivocation: double-signing valid blocks in the same consensus round
|
||||
- amnesia: signing conflicting blocks in different consensus rounds, without having seen a quorum of messages that would have allowed to do so.
|
||||
|
||||
The question is whether this captures all attacks.
|
||||
First observe that the first check in `isolateMisbehavingProcesses` is `violatesTMValidity`. It takes care of lunatic attacks. If this check passes, that is, if `violatesTMValidity` returns `FALSE` this means that [[LCAI-NONVALID-OUTPUT.1]](#LCAI-FUNC-NONVALID1]) evaluates to false, which implies that `ref.ValidatorsHash = ev.ValidatorsHash`. Hence, after `violatesTMValidity`, all the involved validators are the ones from the blockchain. It is thus sufficient to analyze one instance of Tendermint consensus with a fixed group membership (set of validators). Also, as we have two different blocks for the same height, it is sufficient to consider two different valid consensus values, that is, binary consensus.
|
||||
|
||||
For this fixed group membership, we have analyzed the attacks using the TLA+ specification of [Tendermint Consensus in TLA+][tendermint-accountability]. We checked that indeed the only possible scenarios that can lead to violation of agreement are **equivocation** and **amnesia**. An independent study by Galois of the protocol based on [Ivy proofs](https://github.com/tendermint/spec/tree/master/ivy-proofs) led to the same conclusion.
|
||||
|
||||
# References
|
||||
|
||||
[[supervisor]] The specification of the light client supervisor.
|
||||
|
||||
[[verification]] The specification of the light client verification protocol.
|
||||
|
||||
[[detection]] The specification of the light client attack detection mechanism.
|
||||
|
||||
[[tendermint-accountability]]: TLA+ specification to check the types of attacks
|
||||
|
||||
[tendermint-accountability]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md
|
||||
|
||||
[supervisor]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md
|
||||
|
||||
[verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md
|
||||
|
||||
[detection]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md
|
||||
|
||||
[LC-DATA-EVIDENCE-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#lc-data-evidence1
|
||||
|
||||
[TMBC-LC-EVIDENCE-DATA-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#tmbc-lc-evidence-data1
|
||||
|
||||
[node-based-attack-characterization]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#node-based-characterization-of-attacks
|
||||
|
||||
[TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-fm-2thirds1
|
||||
|
||||
[LCV-FUNC-VALID.link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-valid2
|
||||
219
spec/light-client/attacks/notes-on-evidence-handling.md
Normal file
@@ -0,0 +1,219 @@
|
||||
|
||||
# Light client attacks
|
||||
|
||||
We define a light client attack as detection of conflicting headers for a given height that can be verified
|
||||
starting from the trusted light block. A light client attack is defined in the context of interactions of
|
||||
light client with two peers. One of the peers (called primary) defines a trace of verified light blocks
|
||||
(primary trace) that are being checked against trace of the other peer (called witness) that we call
|
||||
witness trace.
|
||||
|
||||
A light client attack is defined by the primary and witness traces
|
||||
that have a common root (the same trusted light block for a common height) but forms
|
||||
conflicting branches (end of traces is for the same height but with different headers).
|
||||
Note that conflicting branches could be arbitrarily big as branches continue to diverge after
|
||||
a bifurcation point. We propose an approach that allows us to define a valid light client attack
|
||||
only with a common light block and a single conflicting light block. We rely on the fact that
|
||||
we assume that the primary is under suspicion (therefore not trusted) and that the witness plays
|
||||
support role to detect and process an attack (therefore trusted). Therefore, once a light client
|
||||
detects an attack, it needs to send to a witness only missing data (common height
|
||||
and conflicting light block) as it has its trace. Keeping light client attack data of constant size
|
||||
saves bandwidth and reduces an attack surface. As we will explain below, although in the context of
|
||||
light client core
|
||||
[verification](https://github.com/informalsystems/tendermint-rs/tree/master/docs/spec/lightclient/verification)
|
||||
the roles of primary and witness are clearly defined,
|
||||
in case of the attack, we run the same attack detection procedure twice where the roles are swapped.
|
||||
The rationale is that the light client does not know what peer is correct (on a right main branch)
|
||||
so it tries to create and submit an attack evidence to both peers.
|
||||
|
||||
Light client attack evidence consists of a conflicting light block and a common height.
|
||||
|
||||
```go
|
||||
type LightClientAttackEvidence struct {
|
||||
ConflictingBlock LightBlock
|
||||
CommonHeight int64
|
||||
}
|
||||
```
|
||||
|
||||
Full node can validate a light client attack evidence by executing the following procedure:
|
||||
|
||||
```go
|
||||
func IsValid(lcaEvidence LightClientAttackEvidence, bc Blockchain) boolean {
|
||||
commonBlock = GetLightBlock(bc, lcaEvidence.CommonHeight)
|
||||
if commonBlock == nil return false
|
||||
|
||||
// Note that trustingPeriod in ValidAndVerified is set to UNBONDING_PERIOD
|
||||
verdict = ValidAndVerified(commonBlock, lcaEvidence.ConflictingBlock)
|
||||
conflictingHeight = lcaEvidence.ConflictingBlock.Header.Height
|
||||
|
||||
return verdict == OK and bc[conflictingHeight].Header != lcaEvidence.ConflictingBlock.Header
|
||||
}
|
||||
```
|
||||
|
||||
## Light client attack creation
|
||||
|
||||
Given a trusted light block `trusted`, a light node executes the bisection algorithm to verify header
|
||||
`untrusted` at some height `h`. If the bisection algorithm succeeds, then the header `untrusted` is verified.
|
||||
Headers that are downloaded as part of the bisection algorithm are stored in a store and they are also in
|
||||
the verified state. Therefore, after the bisection algorithm successfully terminates we have a trace of
|
||||
the light blocks ([] LightBlock) we obtained from the primary that we call primary trace.
|
||||
|
||||
### Primary trace
|
||||
|
||||
The following invariant holds for the primary trace:
|
||||
|
||||
- Given a `trusted` light block, target height `h`, and `primary_trace` ([] LightBlock):
|
||||
*primary_trace[0] == trusted* and *primary_trace[len(primary_trace)-1].Height == h* and
|
||||
successive light blocks are passing light client verification logic.
|
||||
|
||||
### Witness with a conflicting header
|
||||
|
||||
The verified header at height `h` is cross-checked with every witness as part of
|
||||
[detection](https://github.com/informalsystems/tendermint-rs/tree/master/docs/spec/lightclient/detection).
|
||||
If a witness returns the conflicting header at the height `h` the following procedure is executed to verify
|
||||
if the conflicting header comes from the valid trace and if that's the case to create an attack evidence:
|
||||
|
||||
#### Helper functions
|
||||
|
||||
We assume the following helper functions:
|
||||
|
||||
```go
|
||||
// Returns trace of verified light blocks starting from rootHeight and ending with targetHeight.
|
||||
Trace(lightStore LightStore, rootHeight int64, targetHeight int64) LightBlock[]
|
||||
|
||||
// Returns validator set for the given height
|
||||
GetValidators(bc Blockchain, height int64) Validator[]
|
||||
|
||||
// Returns validator set for the given height
|
||||
GetValidators(bc Blockchain, height int64) Validator[]
|
||||
|
||||
// Return validator addresses for the given validators
|
||||
GetAddresses(vals Validator[]) ValidatorAddress[]
|
||||
```
|
||||
|
||||
```go
|
||||
func DetectLightClientAttacks(primary PeerID,
|
||||
primary_trace []LightBlock,
|
||||
witness PeerID) (LightClientAttackEvidence, LightClientAttackEvidence) {
|
||||
primary_lca_evidence, witness_trace = DetectLightClientAttack(primary_trace, witness)
|
||||
|
||||
witness_lca_evidence = nil
|
||||
if witness_trace != nil {
|
||||
witness_lca_evidence, _ = DetectLightClientAttack(witness_trace, primary)
|
||||
}
|
||||
return primary_lca_evidence, witness_lca_evidence
|
||||
}
|
||||
|
||||
func DetectLightClientAttack(trace []LightBlock, peer PeerID) (LightClientAttackEvidence, []LightBlock) {
|
||||
|
||||
lightStore = new LightStore().Update(trace[0], StateTrusted)
|
||||
|
||||
for i in 1..len(trace)-1 {
|
||||
lightStore, result = VerifyToTarget(peer, lightStore, trace[i].Header.Height)
|
||||
|
||||
if result == ResultFailure then return (nil, nil)
|
||||
|
||||
current = lightStore.Get(trace[i].Header.Height)
|
||||
|
||||
// if obtained header is the same as in the trace we continue with a next height
|
||||
if current.Header == trace[i].Header continue
|
||||
|
||||
// we have identified a conflicting header
|
||||
commonBlock = trace[i-1]
|
||||
conflictingBlock = trace[i]
|
||||
|
||||
return (LightClientAttackEvidence { conflictingBlock, commonBlock.Header.Height },
|
||||
Trace(lightStore, trace[i-1].Header.Height, trace[i].Header.Height))
|
||||
}
|
||||
return (nil, nil)
|
||||
}
|
||||
```
|
||||
|
||||
## Evidence handling
|
||||
|
||||
As part of on chain evidence handling, full nodes identifies misbehaving processes and informs
|
||||
the application, so they can be slashed. Note that only bonded validators should
|
||||
be reported to the application. There are three types of attacks that can be executed against
|
||||
Tendermint light client:
|
||||
|
||||
- lunatic attack
|
||||
- equivocation attack and
|
||||
- amnesia attack.
|
||||
|
||||
We now specify the evidence handling logic.
|
||||
|
||||
```go
|
||||
func detectMisbehavingProcesses(lcAttackEvidence LightClientAttackEvidence, bc Blockchain) []ValidatorAddress {
|
||||
assume IsValid(lcaEvidence, bc)
|
||||
|
||||
// lunatic light client attack
|
||||
if !isValidBlock(current.Header, conflictingBlock.Header) {
|
||||
conflictingCommit = lcAttackEvidence.ConflictingBlock.Commit
|
||||
bondedValidators = GetNextValidators(bc, lcAttackEvidence.CommonHeight)
|
||||
|
||||
return getSigners(conflictingCommit) intersection GetAddresses(bondedValidators)
|
||||
|
||||
// equivocation light client attack
|
||||
} else if current.Header.Round == conflictingBlock.Header.Round {
|
||||
conflictingCommit = lcAttackEvidence.ConflictingBlock.Commit
|
||||
trustedCommit = bc[conflictingBlock.Header.Height+1].LastCommit
|
||||
|
||||
return getSigners(trustedCommit) intersection getSigners(conflictingCommit)
|
||||
|
||||
// amnesia light client attack
|
||||
} else {
|
||||
HandleAmnesiaAttackEvidence(lcAttackEvidence, bc)
|
||||
}
|
||||
}
|
||||
|
||||
// Block validity in this context is defined by the trusted header.
|
||||
func isValidBlock(trusted Header, conflicting Header) boolean {
|
||||
return trusted.ValidatorsHash == conflicting.ValidatorsHash and
|
||||
trusted.NextValidatorsHash == conflicting.NextValidatorsHash and
|
||||
trusted.ConsensusHash == conflicting.ConsensusHash and
|
||||
trusted.AppHash == conflicting.AppHash and
|
||||
trusted.LastResultsHash == conflicting.LastResultsHash
|
||||
}
|
||||
|
||||
func getSigners(commit Commit) []ValidatorAddress {
|
||||
signers = []ValidatorAddress
|
||||
for (i, commitSig) in commit.Signatures {
|
||||
if commitSig.BlockIDFlag == BlockIDFlagCommit {
|
||||
signers.append(commitSig.ValidatorAddress)
|
||||
}
|
||||
}
|
||||
return signers
|
||||
}
|
||||
```
|
||||
|
||||
Note that amnesia attack evidence handling involves more complex processing, i.e., cannot be
|
||||
defined simply on amnesia attack evidence. We explain in the following section a protocol
|
||||
for handling amnesia attack evidence.
|
||||
|
||||
### Amnesia attack evidence handling
|
||||
|
||||
Detecting faulty processes in case of the amnesia attack is more complex and cannot be inferred
|
||||
purely based on attack evidence data. In this case, in order to detect misbehaving processes we need
|
||||
access to votes processes sent/received during the conflicting height. Therefore, amnesia handling assumes that
|
||||
validators persist all votes received and sent during multi-round heights (as amnesia attack
|
||||
is only possible in heights that executes over multiple rounds, i.e., commit round > 0).
|
||||
|
||||
To simplify description of the algorithm we assume existence of the trusted oracle called monitor that will
|
||||
drive the algorithm and output faulty processes at the end. Monitor can be implemented in a
|
||||
distributed setting as on-chain module. The algorithm works as follows:
|
||||
1) Monitor sends votesets request to validators of the conflicting height. Validators
|
||||
are expected to send their votesets within predefined timeout.
|
||||
2) Upon receiving votesets request, validators send their votesets to a monitor.
|
||||
2) Validators which have not sent its votesets within timeout are considered faulty.
|
||||
3) The preprocessing of the votesets is done. That means that the received votesets are analyzed
|
||||
and each vote (valid) sent by process p is added to the voteset of the sender p. This phase ensures that
|
||||
votes sent by faulty processes observed by at least one correct validator cannot be excluded from the analysis.
|
||||
4) Votesets of every validator are analyzed independently to decide whether the validator is correct or faulty.
|
||||
A faulty validators is the one where at least one of those invalid transitions is found:
|
||||
- More than one PREVOTE message is sent in a round
|
||||
- More than one PRECOMMIT message is sent in a round
|
||||
- PRECOMMIT message is sent without receiving +2/3 of voting-power equivalent
|
||||
appropriate PREVOTE messages
|
||||
- PREVOTE message is sent for the value V’ in round r’ and the PRECOMMIT message had
|
||||
been sent for the value V in round r by the same process (r’ > r) and there are no
|
||||
+2/3 of voting-power equivalent PREVOTE(vr, V’) messages (vr ≥ 0 and vr > r and vr < r’)
|
||||
as the justification for sending PREVOTE(r’, V’)
|
||||
@@ -1,3 +0,0 @@
|
||||
# Detection
|
||||
|
||||
TODO
|
||||
10
spec/light-client/detection/004bmc-apalache-ok.csv
Normal file
@@ -0,0 +1,10 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;LCD_MC3_3_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
2;LCD_MC3_3_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
3;LCD_MC3_3_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
4;LCD_MC3_4_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
5;LCD_MC3_4_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
6;LCD_MC3_4_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
7;LCD_MC4_4_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
8;LCD_MC4_4_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
9;LCD_MC4_4_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
|
4
spec/light-client/detection/005bmc-apalache-error.csv
Normal file
@@ -0,0 +1,4 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;LCD_MC3_3_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
2;LCD_MC3_4_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
3;LCD_MC4_4_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
|
164
spec/light-client/detection/Blockchain_003_draft.tla
Normal file
@@ -0,0 +1,164 @@
|
||||
------------------------ MODULE Blockchain_003_draft -----------------------------
|
||||
(*
|
||||
This is a high-level specification of Tendermint blockchain
|
||||
that is designed specifically for the light client.
|
||||
Validators have the voting power of one. If you like to model various
|
||||
voting powers, introduce multiple copies of the same validator
|
||||
(do not forget to give them unique names though).
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
Min(a, b) == IF a < b THEN a ELSE b
|
||||
|
||||
CONSTANT
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
ULTIMATE_HEIGHT,
|
||||
(* a maximal height that can be ever reached (modelling artifact) *)
|
||||
TRUSTING_PERIOD
|
||||
(* the period within which the validators are trusted *)
|
||||
|
||||
Heights == 1..ULTIMATE_HEIGHT (* possible heights *)
|
||||
|
||||
(* A commit is just a set of nodes who have committed the block *)
|
||||
Commits == SUBSET AllNodes
|
||||
|
||||
(* The set of all block headers that can be on the blockchain.
|
||||
This is a simplified version of the Block data structure in the actual implementation. *)
|
||||
BlockHeaders == [
|
||||
height: Heights,
|
||||
\* the block height
|
||||
time: Int,
|
||||
\* the block timestamp in some integer units
|
||||
lastCommit: Commits,
|
||||
\* the nodes who have voted on the previous block, the set itself instead of a hash
|
||||
(* in the implementation, only the hashes of V and NextV are stored in a block,
|
||||
as V and NextV are stored in the application state *)
|
||||
VS: SUBSET AllNodes,
|
||||
\* the validators of this bloc. We store the validators instead of the hash.
|
||||
NextVS: SUBSET AllNodes
|
||||
\* the validators of the next block. We store the next validators instead of the hash.
|
||||
]
|
||||
|
||||
(* A signed header is just a header together with a set of commits *)
|
||||
LightBlocks == [header: BlockHeaders, Commits: Commits]
|
||||
|
||||
VARIABLES
|
||||
refClock,
|
||||
(* the current global time in integer units as perceived by the reference chain *)
|
||||
blockchain,
|
||||
(* A sequence of BlockHeaders, which gives us a bird view of the blockchain. *)
|
||||
Faulty
|
||||
(* A set of faulty nodes, which can act as validators. We assume that the set
|
||||
of faulty processes is non-decreasing. If a process has recovered, it should
|
||||
connect using a different id. *)
|
||||
|
||||
(* all variables, to be used with UNCHANGED *)
|
||||
vars == <<refClock, blockchain, Faulty>>
|
||||
|
||||
(* The set of all correct nodes in a state *)
|
||||
Corr == AllNodes \ Faulty
|
||||
|
||||
(* APALACHE annotations *)
|
||||
a <: b == a \* type annotation
|
||||
|
||||
NT == STRING
|
||||
NodeSet(S) == S <: {NT}
|
||||
EmptyNodeSet == NodeSet({})
|
||||
|
||||
BT == [height |-> Int, time |-> Int, lastCommit |-> {NT}, VS |-> {NT}, NextVS |-> {NT}]
|
||||
|
||||
LBT == [header |-> BT, Commits |-> {NT}]
|
||||
(* end of APALACHE annotations *)
|
||||
|
||||
(****************************** BLOCKCHAIN ************************************)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriod(header) ==
|
||||
refClock < header.time + TRUSTING_PERIOD
|
||||
|
||||
(*
|
||||
Given a function pVotingPower \in D -> Powers for some D \subseteq AllNodes
|
||||
and pNodes \subseteq D, test whether the set pNodes \subseteq AllNodes has
|
||||
more than 2/3 of voting power among the nodes in D.
|
||||
*)
|
||||
TwoThirds(pVS, pNodes) ==
|
||||
LET TP == Cardinality(pVS)
|
||||
SP == Cardinality(pVS \intersect pNodes)
|
||||
IN
|
||||
3 * SP > 2 * TP \* when thinking in real numbers, not integers: SP > 2.0 / 3.0 * TP
|
||||
|
||||
(*
|
||||
Given a set of FaultyNodes, test whether the voting power of the correct nodes in D
|
||||
is more than 2/3 of the voting power of the faulty nodes in D.
|
||||
|
||||
Parameters:
|
||||
- pFaultyNodes is a set of nodes that are considered faulty
|
||||
- pVS is a set of all validators, maybe including Faulty, intersecting with it, etc.
|
||||
- pMaxFaultRatio is a pair <<a, b>> that limits the ratio a / b of the faulty
|
||||
validators from above (exclusive)
|
||||
*)
|
||||
FaultyValidatorsFewerThan(pFaultyNodes, pVS, maxRatio) ==
|
||||
LET FN == pFaultyNodes \intersect pVS \* faulty nodes in pNodes
|
||||
CN == pVS \ pFaultyNodes \* correct nodes in pNodes
|
||||
CP == Cardinality(CN) \* power of the correct nodes
|
||||
FP == Cardinality(FN) \* power of the faulty nodes
|
||||
IN
|
||||
\* CP + FP = TP is the total voting power
|
||||
LET TP == CP + FP IN
|
||||
FP * maxRatio[2] < TP * maxRatio[1]
|
||||
|
||||
(* Can a block be produced by a correct peer, or an authenticated Byzantine peer *)
|
||||
IsLightBlockAllowedByDigitalSignatures(ht, block) ==
|
||||
\/ block.header = blockchain[ht] \* signed by correct and faulty (maybe)
|
||||
\/ /\ block.Commits \subseteq Faulty
|
||||
/\ block.header.height = ht
|
||||
/\ block.header.time >= 0 \* signed only by faulty
|
||||
|
||||
(*
|
||||
Initialize the blockchain to the ultimate height right in the initial states.
|
||||
We pick the faulty validators statically, but that should not affect the light client.
|
||||
|
||||
Parameters:
|
||||
- pMaxFaultyRatioExclusive is a pair <<a, b>> that bound the number of
|
||||
faulty validators in each block by the ratio a / b (exclusive)
|
||||
*)
|
||||
InitToHeight(pMaxFaultyRatioExclusive) ==
|
||||
/\ Faulty \in SUBSET AllNodes \* some nodes may fail
|
||||
\* pick the validator sets and last commits
|
||||
/\ \E vs, lastCommit \in [Heights -> SUBSET AllNodes]:
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
\* refClock is at least as early as the timestamp in the last block
|
||||
/\ \E tm \in Int: refClock = tm /\ tm >= timestamp[ULTIMATE_HEIGHT]
|
||||
\* the genesis starts on day 1
|
||||
/\ timestamp[1] = 1
|
||||
/\ vs[1] = AllNodes
|
||||
/\ lastCommit[1] = EmptyNodeSet
|
||||
/\ \A h \in Heights \ {1}:
|
||||
/\ lastCommit[h] \subseteq vs[h - 1] \* the non-validators cannot commit
|
||||
/\ TwoThirds(vs[h - 1], lastCommit[h]) \* the commit has >2/3 of validator votes
|
||||
\* the faulty validators have the power below the threshold
|
||||
/\ FaultyValidatorsFewerThan(Faulty, vs[h], pMaxFaultyRatioExclusive)
|
||||
/\ timestamp[h] > timestamp[h - 1] \* the time grows monotonically
|
||||
/\ timestamp[h] < timestamp[h - 1] + TRUSTING_PERIOD \* but not too fast
|
||||
\* form the block chain out of validator sets and commits (this makes apalache faster)
|
||||
/\ blockchain = [h \in Heights |->
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> IF h < ULTIMATE_HEIGHT THEN vs[h + 1] ELSE AllNodes,
|
||||
lastCommit |-> lastCommit[h]]
|
||||
] \******
|
||||
|
||||
(********************* BLOCKCHAIN ACTIONS ********************************)
|
||||
(*
|
||||
Advance the clock by zero or more time units.
|
||||
*)
|
||||
AdvanceTime ==
|
||||
/\ \E tm \in Int: tm >= refClock /\ refClock' = tm
|
||||
/\ UNCHANGED <<blockchain, Faulty>>
|
||||
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Wed Jun 10 14:10:54 CEST 2020 by igor
|
||||
\* Created Fri Oct 11 15:45:11 CEST 2019 by igor
|
||||
27
spec/light-client/detection/LCD_MC3_3_faulty.tla
Normal file
@@ -0,0 +1,27 @@
|
||||
------------------------- MODULE LCD_MC3_3_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
IS_SECONDARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the reference blockchain *)
|
||||
localClock, (* current time in the light client *)
|
||||
refClock, (* current time in the reference blockchain *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
state, (* the state of the light client detector *)
|
||||
fetchedLightBlocks1, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks2, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks1b, (* a function from heights to LightBlocks *)
|
||||
commonHeight, (* the height that is trusted in CreateEvidenceForPeer *)
|
||||
nextHeightToTry, (* the index in CreateEvidenceForPeer *)
|
||||
evidences
|
||||
|
||||
INSTANCE LCDetector_003_draft
|
||||
============================================================================
|
||||
27
spec/light-client/detection/LCD_MC3_4_faulty.tla
Normal file
@@ -0,0 +1,27 @@
|
||||
------------------------- MODULE LCD_MC3_4_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
IS_SECONDARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the reference blockchain *)
|
||||
localClock, (* current time in the light client *)
|
||||
refClock, (* current time in the reference blockchain *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
state, (* the state of the light client detector *)
|
||||
fetchedLightBlocks1, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks2, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks1b, (* a function from heights to LightBlocks *)
|
||||
commonHeight, (* the height that is trusted in CreateEvidenceForPeer *)
|
||||
nextHeightToTry, (* the index in CreateEvidenceForPeer *)
|
||||
evidences
|
||||
|
||||
INSTANCE LCDetector_003_draft
|
||||
============================================================================
|
||||
27
spec/light-client/detection/LCD_MC4_4_faulty.tla
Normal file
@@ -0,0 +1,27 @@
|
||||
------------------------- MODULE LCD_MC4_4_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
IS_SECONDARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 2 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the reference blockchain *)
|
||||
localClock, (* current time in the light client *)
|
||||
refClock, (* current time in the reference blockchain *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
state, (* the state of the light client detector *)
|
||||
fetchedLightBlocks1, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks2, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks1b, (* a function from heights to LightBlocks *)
|
||||
commonHeight, (* the height that is trusted in CreateEvidenceForPeer *)
|
||||
nextHeightToTry, (* the index in CreateEvidenceForPeer *)
|
||||
evidences
|
||||
|
||||
INSTANCE LCDetector_003_draft
|
||||
============================================================================
|
||||
27
spec/light-client/detection/LCD_MC5_5_faulty.tla
Normal file
@@ -0,0 +1,27 @@
|
||||
------------------------- MODULE LCD_MC5_5_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
IS_SECONDARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the reference blockchain *)
|
||||
localClock, (* current time in the light client *)
|
||||
refClock, (* current time in the reference blockchain *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
state, (* the state of the light client detector *)
|
||||
fetchedLightBlocks1, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks2, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks1b, (* a function from heights to LightBlocks *)
|
||||
commonHeight, (* the height that is trusted in CreateEvidenceForPeer *)
|
||||
nextHeightToTry, (* the index in CreateEvidenceForPeer *)
|
||||
evidences
|
||||
|
||||
INSTANCE LCDetector_003_draft
|
||||
============================================================================
|
||||
373
spec/light-client/detection/LCDetector_003_draft.tla
Normal file
@@ -0,0 +1,373 @@
|
||||
-------------------------- MODULE LCDetector_003_draft -----------------------------
|
||||
(**
|
||||
* This is a specification of the light client detector module.
|
||||
* It follows the English specification:
|
||||
*
|
||||
* https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md
|
||||
*
|
||||
* The assumptions made in this specification:
|
||||
*
|
||||
* - light client connects to one primary and one secondary peer
|
||||
*
|
||||
* - the light client has its own local clock that can drift from the reference clock
|
||||
* within the envelope [refClock - CLOCK_DRIFT, refClock + CLOCK_DRIFT].
|
||||
* The local clock may increase as well as decrease in the the envelope
|
||||
* (similar to clock synchronization).
|
||||
*
|
||||
* - the ratio of the faulty validators is set as the parameter.
|
||||
*
|
||||
* Igor Konnov, Josef Widder, 2020
|
||||
*)
|
||||
|
||||
EXTENDS Integers
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
TRUSTED_HEIGHT,
|
||||
(* an index of the block header that the light client trusts by social consensus *)
|
||||
TARGET_HEIGHT,
|
||||
(* an index of the block header that the light client tries to verify *)
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
CLOCK_DRIFT,
|
||||
(* the assumed precision of the clock *)
|
||||
REAL_CLOCK_DRIFT,
|
||||
(* the actual clock drift, which under normal circumstances should not
|
||||
be larger than CLOCK_DRIFT (otherwise, there will be a bug) *)
|
||||
FAULTY_RATIO,
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
IS_PRIMARY_CORRECT,
|
||||
IS_SECONDARY_CORRECT
|
||||
|
||||
VARIABLES
|
||||
blockchain, (* the reference blockchain *)
|
||||
localClock, (* the local clock of the light client *)
|
||||
refClock, (* the reference clock in the reference blockchain *)
|
||||
Faulty, (* the set of faulty validators *)
|
||||
state, (* the state of the light client detector *)
|
||||
fetchedLightBlocks1, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks2, (* a function from heights to LightBlocks *)
|
||||
fetchedLightBlocks1b, (* a function from heights to LightBlocks *)
|
||||
commonHeight, (* the height that is trusted in CreateEvidenceForPeer *)
|
||||
nextHeightToTry, (* the index in CreateEvidenceForPeer *)
|
||||
evidences (* a set of evidences *)
|
||||
|
||||
vars == <<state, blockchain, localClock, refClock, Faulty,
|
||||
fetchedLightBlocks1, fetchedLightBlocks2, fetchedLightBlocks1b,
|
||||
commonHeight, nextHeightToTry, evidences >>
|
||||
|
||||
\* (old) type annotations in Apalache
|
||||
a <: b == a
|
||||
|
||||
|
||||
\* instantiate a reference chain
|
||||
ULTIMATE_HEIGHT == TARGET_HEIGHT + 1
|
||||
BC == INSTANCE Blockchain_003_draft
|
||||
WITH ULTIMATE_HEIGHT <- (TARGET_HEIGHT + 1)
|
||||
|
||||
\* use the light client API
|
||||
LC == INSTANCE LCVerificationApi_003_draft
|
||||
|
||||
\* evidence type
|
||||
ET == [peer |-> STRING, conflictingBlock |-> BC!LBT, commonHeight |-> Int]
|
||||
|
||||
\* is the algorithm in the terminating state
|
||||
IsTerminated ==
|
||||
state \in { <<"NoEvidence", "PRIMARY">>,
|
||||
<<"NoEvidence", "SECONDARY">>,
|
||||
<<"FaultyPeer", "PRIMARY">>,
|
||||
<<"FaultyPeer", "SECONDARY">>,
|
||||
<<"FoundEvidence", "PRIMARY">> }
|
||||
|
||||
|
||||
(********************************* Initialization ******************************)
|
||||
|
||||
\* initialization for the light blocks data structure
|
||||
InitLightBlocks(lb, Heights) ==
|
||||
\* BC!LightBlocks is an infinite set, as time is not restricted.
|
||||
\* Hence, we initialize the light blocks by picking the sets inside.
|
||||
\E vs, nextVS, lastCommit, commit \in [Heights -> SUBSET AllNodes]:
|
||||
\* although [Heights -> Int] is an infinite set,
|
||||
\* Apalache needs just one instance of this set, so it does not complain.
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
LET hdr(h) ==
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> nextVS[h],
|
||||
lastCommit |-> lastCommit[h]]
|
||||
IN
|
||||
LET lightHdr(h) ==
|
||||
[header |-> hdr(h), Commits |-> commit[h]]
|
||||
IN
|
||||
lb = [ h \in Heights |-> lightHdr(h) ]
|
||||
|
||||
\* initialize the detector algorithm
|
||||
Init ==
|
||||
\* initialize the blockchain to TARGET_HEIGHT + 1
|
||||
/\ BC!InitToHeight(FAULTY_RATIO)
|
||||
/\ \E tm \in Int:
|
||||
tm >= 0 /\ LC!IsLocalClockWithinDrift(tm, refClock) /\ localClock = tm
|
||||
\* start with the secondary looking for evidence
|
||||
/\ state = <<"Init", "SECONDARY">> /\ commonHeight = 0 /\ nextHeightToTry = 0
|
||||
/\ evidences = {} <: {ET}
|
||||
\* Precompute a possible result of light client verification for the primary.
|
||||
\* It is the input to the detection algorithm.
|
||||
/\ \E Heights1 \in SUBSET(TRUSTED_HEIGHT..TARGET_HEIGHT):
|
||||
/\ TRUSTED_HEIGHT \in Heights1
|
||||
/\ TARGET_HEIGHT \in Heights1
|
||||
/\ InitLightBlocks(fetchedLightBlocks1, Heights1)
|
||||
\* As we have a non-deterministic scheduler, for every trace that has
|
||||
\* an unverified block, there is a filtered trace that only has verified
|
||||
\* blocks. This is a deep observation.
|
||||
/\ LET status == [h \in Heights1 |-> "StateVerified"] IN
|
||||
LC!VerifyToTargetPost(blockchain, IS_PRIMARY_CORRECT,
|
||||
fetchedLightBlocks1, status,
|
||||
TRUSTED_HEIGHT, TARGET_HEIGHT, "finishedSuccess")
|
||||
\* initialize the other data structures to the default values
|
||||
/\ LET trustedBlock == blockchain[TRUSTED_HEIGHT]
|
||||
trustedLightBlock == [header |-> trustedBlock, Commits |-> AllNodes]
|
||||
IN
|
||||
/\ fetchedLightBlocks2 = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
|
||||
/\ fetchedLightBlocks1b = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
|
||||
|
||||
|
||||
(********************************* Transitions ******************************)
|
||||
|
||||
\* a block should contain a copy of the block from the reference chain,
|
||||
\* with a matching commit
|
||||
CopyLightBlockFromChain(block, height) ==
|
||||
LET ref == blockchain[height]
|
||||
lastCommit ==
|
||||
IF height < ULTIMATE_HEIGHT
|
||||
THEN blockchain[height + 1].lastCommit
|
||||
\* for the ultimate block, which we never use,
|
||||
\* as ULTIMATE_HEIGHT = TARGET_HEIGHT + 1
|
||||
ELSE blockchain[height].VS
|
||||
IN
|
||||
block = [header |-> ref, Commits |-> lastCommit]
|
||||
|
||||
\* Either the primary is correct and the block comes from the reference chain,
|
||||
\* or the block is produced by a faulty primary.
|
||||
\*
|
||||
\* [LCV-FUNC-FETCH.1::TLA.1]
|
||||
FetchLightBlockInto(isPeerCorrect, block, height) ==
|
||||
IF isPeerCorrect
|
||||
THEN CopyLightBlockFromChain(block, height)
|
||||
ELSE BC!IsLightBlockAllowedByDigitalSignatures(height, block)
|
||||
|
||||
|
||||
(**
|
||||
* Pick the next height, for which there is a block.
|
||||
*)
|
||||
PickNextHeight(fetchedBlocks, height) ==
|
||||
LET largerHeights == { h \in DOMAIN fetchedBlocks: h > height } IN
|
||||
IF largerHeights = ({} <: {Int})
|
||||
THEN -1
|
||||
ELSE CHOOSE h \in largerHeights:
|
||||
\A h2 \in largerHeights: h <= h2
|
||||
|
||||
|
||||
(**
|
||||
* Check, whether the target header matches at the secondary and primary.
|
||||
*)
|
||||
CompareLast ==
|
||||
/\ state = <<"Init", "SECONDARY">>
|
||||
\* fetch a block from the secondary:
|
||||
\* non-deterministically pick a block that matches the constraints
|
||||
/\ \E latest \in BC!LightBlocks:
|
||||
\* for the moment, we ignore the possibility of a timeout when fetching a block
|
||||
/\ FetchLightBlockInto(IS_SECONDARY_CORRECT, latest, TARGET_HEIGHT)
|
||||
/\ IF latest.header = fetchedLightBlocks1[TARGET_HEIGHT].header
|
||||
THEN \* if the headers match, CreateEvidence is not called
|
||||
/\ state' = <<"NoEvidence", "SECONDARY">>
|
||||
\* save the retrieved block for further analysis
|
||||
/\ fetchedLightBlocks2' =
|
||||
[h \in (DOMAIN fetchedLightBlocks2) \union {TARGET_HEIGHT} |->
|
||||
IF h = TARGET_HEIGHT THEN latest ELSE fetchedLightBlocks2[h]]
|
||||
/\ UNCHANGED <<commonHeight, nextHeightToTry>>
|
||||
ELSE \* prepare the parameters for CreateEvidence
|
||||
/\ commonHeight' = TRUSTED_HEIGHT
|
||||
/\ nextHeightToTry' = PickNextHeight(fetchedLightBlocks1, TRUSTED_HEIGHT)
|
||||
/\ state' = IF nextHeightToTry' >= 0
|
||||
THEN <<"CreateEvidence", "SECONDARY">>
|
||||
ELSE <<"FaultyPeer", "SECONDARY">>
|
||||
/\ UNCHANGED fetchedLightBlocks2
|
||||
|
||||
/\ UNCHANGED <<blockchain, Faulty,
|
||||
fetchedLightBlocks1, fetchedLightBlocks1b, evidences>>
|
||||
|
||||
|
||||
\* the actual loop in CreateEvidence
|
||||
CreateEvidence(peer, isPeerCorrect, refBlocks, targetBlocks) ==
|
||||
/\ state = <<"CreateEvidence", peer>>
|
||||
\* precompute a possible result of light client verification for the secondary
|
||||
\* we have to introduce HeightRange, because Apalache can only handle a..b
|
||||
\* for constant a and b
|
||||
/\ LET HeightRange == { h \in TRUSTED_HEIGHT..TARGET_HEIGHT:
|
||||
commonHeight <= h /\ h <= nextHeightToTry } IN
|
||||
\E HeightsRange \in SUBSET(HeightRange):
|
||||
/\ commonHeight \in HeightsRange /\ nextHeightToTry \in HeightsRange
|
||||
/\ InitLightBlocks(targetBlocks, HeightsRange)
|
||||
\* As we have a non-deterministic scheduler, for every trace that has
|
||||
\* an unverified block, there is a filtered trace that only has verified
|
||||
\* blocks. This is a deep observation.
|
||||
/\ \E result \in {"finishedSuccess", "finishedFailure"}:
|
||||
LET targetStatus == [h \in HeightsRange |-> "StateVerified"] IN
|
||||
\* call VerifyToTarget for (commonHeight, nextHeightToTry).
|
||||
/\ LC!VerifyToTargetPost(blockchain, isPeerCorrect,
|
||||
targetBlocks, targetStatus,
|
||||
commonHeight, nextHeightToTry, result)
|
||||
\* case 1: the peer has failed (or the trusting period has expired)
|
||||
/\ \/ /\ result /= "finishedSuccess"
|
||||
/\ state' = <<"FaultyPeer", peer>>
|
||||
/\ UNCHANGED <<commonHeight, nextHeightToTry, evidences>>
|
||||
\* case 2: success
|
||||
\/ /\ result = "finishedSuccess"
|
||||
/\ LET block1 == refBlocks[nextHeightToTry] IN
|
||||
LET block2 == targetBlocks[nextHeightToTry] IN
|
||||
IF block1.header /= block2.header
|
||||
THEN \* the target blocks do not match
|
||||
/\ state' = <<"FoundEvidence", peer>>
|
||||
/\ evidences' = evidences \union
|
||||
{[peer |-> peer,
|
||||
conflictingBlock |-> block1,
|
||||
commonHeight |-> commonHeight]}
|
||||
/\ UNCHANGED <<commonHeight, nextHeightToTry>>
|
||||
ELSE \* the target blocks match
|
||||
/\ nextHeightToTry' = PickNextHeight(refBlocks, nextHeightToTry)
|
||||
/\ commonHeight' = nextHeightToTry
|
||||
/\ state' = IF nextHeightToTry' >= 0
|
||||
THEN state
|
||||
ELSE <<"NoEvidence", peer>>
|
||||
/\ UNCHANGED evidences
|
||||
|
||||
SwitchToPrimary ==
|
||||
/\ state = <<"FoundEvidence", "SECONDARY">>
|
||||
/\ nextHeightToTry' = PickNextHeight(fetchedLightBlocks2, commonHeight)
|
||||
/\ state' = <<"CreateEvidence", "PRIMARY">>
|
||||
/\ UNCHANGED <<blockchain, refClock, Faulty, localClock,
|
||||
fetchedLightBlocks1, fetchedLightBlocks2, fetchedLightBlocks1b,
|
||||
commonHeight, evidences >>
|
||||
|
||||
|
||||
CreateEvidenceForSecondary ==
|
||||
/\ CreateEvidence("SECONDARY", IS_SECONDARY_CORRECT,
|
||||
fetchedLightBlocks1, fetchedLightBlocks2')
|
||||
/\ UNCHANGED <<blockchain, refClock, Faulty, localClock,
|
||||
fetchedLightBlocks1, fetchedLightBlocks1b>>
|
||||
|
||||
CreateEvidenceForPrimary ==
|
||||
/\ CreateEvidence("PRIMARY", IS_PRIMARY_CORRECT,
|
||||
fetchedLightBlocks2,
|
||||
fetchedLightBlocks1b')
|
||||
/\ UNCHANGED <<blockchain, Faulty,
|
||||
fetchedLightBlocks1, fetchedLightBlocks2>>
|
||||
|
||||
(*
|
||||
The local and global clocks can be updated. They can also drift from each other.
|
||||
Note that the local clock can actually go backwards in time.
|
||||
However, it still stays in the drift envelope
|
||||
of [refClock - REAL_CLOCK_DRIFT, refClock + REAL_CLOCK_DRIFT].
|
||||
*)
|
||||
AdvanceClocks ==
|
||||
/\ \E tm \in Int:
|
||||
tm >= refClock /\ refClock' = tm
|
||||
/\ \E tm \in Int:
|
||||
/\ tm >= localClock
|
||||
/\ LC!IsLocalClockWithinDrift(tm, refClock')
|
||||
/\ localClock' = tm
|
||||
|
||||
(**
|
||||
Execute AttackDetector for one secondary.
|
||||
|
||||
[LCD-FUNC-DETECTOR.2::LOOP.1]
|
||||
*)
|
||||
Next ==
|
||||
/\ AdvanceClocks
|
||||
/\ \/ CompareLast
|
||||
\/ CreateEvidenceForSecondary
|
||||
\/ SwitchToPrimary
|
||||
\/ CreateEvidenceForPrimary
|
||||
|
||||
|
||||
\* simple invariants to see the progress of the detector
|
||||
NeverNoEvidence == state[1] /= "NoEvidence"
|
||||
NeverFoundEvidence == state[1] /= "FoundEvidence"
|
||||
NeverFaultyPeer == state[1] /= "FaultyPeer"
|
||||
NeverCreateEvidence == state[1] /= "CreateEvidence"
|
||||
|
||||
NeverFoundEvidencePrimary == state /= <<"FoundEvidence", "PRIMARY">>
|
||||
|
||||
NeverReachTargetHeight == nextHeightToTry < TARGET_HEIGHT
|
||||
|
||||
EvidenceWhenFaultyInv ==
|
||||
(state[1] = "FoundEvidence") => (~IS_PRIMARY_CORRECT \/ ~IS_SECONDARY_CORRECT)
|
||||
|
||||
NoEvidenceForCorrectInv ==
|
||||
IS_PRIMARY_CORRECT /\ IS_SECONDARY_CORRECT => evidences = {} <: {ET}
|
||||
|
||||
(**
|
||||
* If we find an evidence by peer A, peer B has ineded given us a corrupted
|
||||
* header following the common height. Also, we have a verification trace by peer A.
|
||||
*)
|
||||
CommonHeightOnEvidenceInv ==
|
||||
\A e \in evidences:
|
||||
LET conflicting == e.conflictingBlock IN
|
||||
LET conflictingHeader == conflicting.header IN
|
||||
\* the evidence by suspectingPeer can be verified by suspectingPeer in one step
|
||||
LET SoundEvidence(suspectingPeer, peerBlocks) ==
|
||||
\/ e.peer /= suspectingPeer
|
||||
\* the conflicting block from another peer verifies against the common height
|
||||
\/ /\ "SUCCESS" =
|
||||
LC!ValidAndVerifiedUntimed(peerBlocks[e.commonHeight], conflicting)
|
||||
\* and the headers of the same height by the two peers do not match
|
||||
/\ peerBlocks[conflictingHeader.height].header /= conflictingHeader
|
||||
IN
|
||||
/\ SoundEvidence("PRIMARY", fetchedLightBlocks1b)
|
||||
/\ SoundEvidence("SECONDARY", fetchedLightBlocks2)
|
||||
|
||||
(**
|
||||
* If the light client does not find an evidence,
|
||||
* then there is no attack on the light client.
|
||||
*)
|
||||
AccuracyInv ==
|
||||
(LC!InTrustingPeriodLocal(fetchedLightBlocks1[TARGET_HEIGHT].header)
|
||||
/\ state = <<"NoEvidence", "SECONDARY">>)
|
||||
=>
|
||||
(fetchedLightBlocks1[TARGET_HEIGHT].header = blockchain[TARGET_HEIGHT]
|
||||
/\ fetchedLightBlocks2[TARGET_HEIGHT].header = blockchain[TARGET_HEIGHT])
|
||||
|
||||
(**
|
||||
* The primary reports a corrupted block at the target height. If the secondary is
|
||||
* correct and the algorithm has terminated, we should get the evidence.
|
||||
* This property is violated due to clock drift. VerifyToTarget may fail with
|
||||
* the correct secondary within the trusting period (due to clock drift, locally
|
||||
* we think that we are outside of the trusting period).
|
||||
*)
|
||||
PrecisionInvGrayZone ==
|
||||
(/\ fetchedLightBlocks1[TARGET_HEIGHT].header /= blockchain[TARGET_HEIGHT]
|
||||
/\ BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
/\ IS_SECONDARY_CORRECT
|
||||
/\ IsTerminated)
|
||||
=>
|
||||
evidences /= {} <: {ET}
|
||||
|
||||
(**
|
||||
* The primary reports a corrupted block at the target height. If the secondary is
|
||||
* correct and the algorithm has terminated, we should get the evidence.
|
||||
* This invariant does not fail, as we are using the local clock to check the trusting
|
||||
* period.
|
||||
*)
|
||||
PrecisionInvLocal ==
|
||||
(/\ fetchedLightBlocks1[TARGET_HEIGHT].header /= blockchain[TARGET_HEIGHT]
|
||||
/\ LC!InTrustingPeriodLocalSurely(blockchain[TRUSTED_HEIGHT])
|
||||
/\ IS_SECONDARY_CORRECT
|
||||
/\ IsTerminated)
|
||||
=>
|
||||
evidences /= {} <: {ET}
|
||||
|
||||
====================================================================================
|
||||
192
spec/light-client/detection/LCVerificationApi_003_draft.tla
Normal file
@@ -0,0 +1,192 @@
|
||||
-------------------- MODULE LCVerificationApi_003_draft --------------------------
|
||||
(**
|
||||
* The common interface of the light client verification and detection.
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
CLOCK_DRIFT,
|
||||
(* the assumed precision of the clock *)
|
||||
REAL_CLOCK_DRIFT,
|
||||
(* the actual clock drift, which under normal circumstances should not
|
||||
be larger than CLOCK_DRIFT (otherwise, there will be a bug) *)
|
||||
FAULTY_RATIO
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
|
||||
VARIABLES
|
||||
localClock (* current time as measured by the light client *)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriodLocal(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - CLOCK_DRIFT
|
||||
|
||||
(* the header is still within the trusting period, even if the clock can go backwards *)
|
||||
InTrustingPeriodLocalSurely(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - 2 * CLOCK_DRIFT
|
||||
|
||||
(* ensure that the local clock does not drift far away from the global clock *)
|
||||
IsLocalClockWithinDrift(local, global) ==
|
||||
/\ global - REAL_CLOCK_DRIFT <= local
|
||||
/\ local <= global + REAL_CLOCK_DRIFT
|
||||
|
||||
(**
|
||||
* Check that the commits in an untrusted block form 1/3 of the next validators
|
||||
* in a trusted header.
|
||||
*)
|
||||
SignedByOneThirdOfTrusted(trusted, untrusted) ==
|
||||
LET TP == Cardinality(trusted.header.NextVS)
|
||||
SP == Cardinality(untrusted.Commits \intersect trusted.header.NextVS)
|
||||
IN
|
||||
3 * SP > TP
|
||||
|
||||
(**
|
||||
The first part of the precondition of ValidAndVerified, which does not take
|
||||
the current time into account.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedPreUntimed(trusted, untrusted) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ thdr.height < uhdr.height
|
||||
\* the trusted block has been created earlier
|
||||
/\ thdr.time < uhdr.time
|
||||
/\ untrusted.Commits \subseteq uhdr.VS
|
||||
/\ LET TP == Cardinality(uhdr.VS)
|
||||
SP == Cardinality(untrusted.Commits)
|
||||
IN
|
||||
3 * SP > 2 * TP
|
||||
/\ thdr.height + 1 = uhdr.height => thdr.NextVS = uhdr.VS
|
||||
(* As we do not have explicit hashes we ignore these three checks of the English spec:
|
||||
|
||||
1. "trusted.Commit is a commit is for the header trusted.Header,
|
||||
i.e. it contains the correct hash of the header".
|
||||
2. untrusted.Validators = hash(untrusted.Header.Validators)
|
||||
3. untrusted.NextValidators = hash(untrusted.Header.NextValidators)
|
||||
*)
|
||||
|
||||
(**
|
||||
Check the precondition of ValidAndVerified, including the time checks.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE.1]
|
||||
*)
|
||||
ValidAndVerifiedPre(trusted, untrusted, checkFuture) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ InTrustingPeriodLocal(thdr)
|
||||
\* The untrusted block is not from the future (modulo clock drift).
|
||||
\* Do the check, if it is required.
|
||||
/\ checkFuture => uhdr.time < localClock + CLOCK_DRIFT
|
||||
/\ ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
This test does take current time into account, but only looks at the block structure.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedUntimed(trusted, untrusted) ==
|
||||
IF ~ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
THEN "INVALID"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA.1]
|
||||
*)
|
||||
ValidAndVerified(trusted, untrusted, checkFuture) ==
|
||||
IF ~ValidAndVerifiedPre(trusted, untrusted, checkFuture)
|
||||
THEN "INVALID"
|
||||
ELSE IF ~InTrustingPeriodLocal(untrusted.header)
|
||||
(* We leave the following test for the documentation purposes.
|
||||
The implementation should do this test, as signature verification may be slow.
|
||||
In the TLA+ specification, ValidAndVerified happens in no time.
|
||||
*)
|
||||
THEN "FAILED_TRUSTING_PERIOD"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
|
||||
(**
|
||||
The invariant of the light store that is not related to the blockchain
|
||||
*)
|
||||
LightStoreInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] /= "StateVerified"
|
||||
\/ lightBlockStatus[rh] /= "StateVerified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ LET lhdr == fetchedLightBlocks[lh]
|
||||
rhdr == fetchedLightBlocks[rh]
|
||||
IN
|
||||
\* we can verify the right one using the left one
|
||||
"SUCCESS" = ValidAndVerifiedUntimed(lhdr, rhdr)
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks.
|
||||
* (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
(**
|
||||
The expected post-condition of VerifyToTarget.
|
||||
*)
|
||||
VerifyToTargetPost(blockchain, isPeerCorrect,
|
||||
fetchedLightBlocks, lightBlockStatus,
|
||||
trustedHeight, targetHeight, finalState) ==
|
||||
LET trustedHeader == fetchedLightBlocks[trustedHeight].header IN
|
||||
\* The light client is not lying us on the trusted block.
|
||||
\* It is straightforward to detect.
|
||||
/\ lightBlockStatus[trustedHeight] = "StateVerified"
|
||||
/\ trustedHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ trustedHeader = blockchain[trustedHeight]
|
||||
\* the invariants we have found in the light client verification
|
||||
\* there is a problem with trusting period
|
||||
/\ isPeerCorrect
|
||||
=> CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus)
|
||||
\* a correct peer should fail the light client,
|
||||
\* if the trusted block is in the trusting period
|
||||
/\ isPeerCorrect /\ InTrustingPeriodLocalSurely(trustedHeader)
|
||||
=> finalState = "finishedSuccess"
|
||||
/\ finalState = "finishedSuccess" =>
|
||||
/\ lightBlockStatus[targetHeight] = "StateVerified"
|
||||
/\ targetHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus)
|
||||
/\ LightStoreInv(fetchedLightBlocks, lightBlockStatus)
|
||||
|
||||
|
||||
==================================================================================
|
||||
75
spec/light-client/detection/README.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
order: 1
|
||||
parent:
|
||||
title: Fork Detection
|
||||
order: 2
|
||||
---
|
||||
|
||||
# Tendermint fork detection and IBC fork detection
|
||||
|
||||
## Status
|
||||
|
||||
This is a work in progress.
|
||||
This directory captures the ongoing work and discussion on fork
|
||||
detection both in the context of a Tendermint light node and in the
|
||||
context of IBC. It contains the following files
|
||||
|
||||
### [detection.md](./detection.md)
|
||||
|
||||
a draft of the light node fork detection including "proof of fork"
|
||||
definition, that is, the data structure to submit evidence to full
|
||||
nodes.
|
||||
|
||||
### [discussions.md](./discussions.md)
|
||||
|
||||
A collection of ideas and intuitions from recent discussions
|
||||
|
||||
- the outcome of recent discussion
|
||||
- a sketch of the light client supervisor to provide the context in
|
||||
which fork detection happens
|
||||
- a discussion about lightstore semantics
|
||||
|
||||
### [req-ibc-detection.md](./req-ibc-detection.md)
|
||||
|
||||
- a collection of requirements for fork detection in the IBC
|
||||
context. In particular it contains a section "Required Changes in
|
||||
ICS 007" with necessary updates to ICS 007 to support Tendermint
|
||||
fork detection
|
||||
|
||||
### [draft-functions.md](./draft-functions.md)
|
||||
|
||||
In order to address the collected requirements, we started to sketch
|
||||
some functions that we will need in the future when we specify in more
|
||||
detail the
|
||||
|
||||
- fork detections
|
||||
- proof of fork generation
|
||||
- proof of fork verification
|
||||
|
||||
on the following components.
|
||||
|
||||
- IBC on-chain components
|
||||
- Relayer
|
||||
|
||||
### TODOs
|
||||
|
||||
We decided to merge the files while there are still open points to
|
||||
address to record the current state an move forward. In particular,
|
||||
the following points need to be addressed:
|
||||
|
||||
- <https://github.com/informalsystems/tendermint-rs/pull/479#discussion_r466504876>
|
||||
|
||||
- <https://github.com/informalsystems/tendermint-rs/pull/479#discussion_r466493900>
|
||||
|
||||
- <https://github.com/informalsystems/tendermint-rs/pull/479#discussion_r466489045>
|
||||
|
||||
- <https://github.com/informalsystems/tendermint-rs/pull/479#discussion_r466491471>
|
||||
|
||||
Most likely we will write a specification on the light client
|
||||
supervisor along the outcomes of
|
||||
|
||||
- <https://github.com/informalsystems/tendermint-rs/pull/509>
|
||||
|
||||
that also addresses initialization
|
||||
|
||||
- <https://github.com/tendermint/spec/issues/131>
|
||||
788
spec/light-client/detection/detection_001_reviewed.md
Normal file
@@ -0,0 +1,788 @@
|
||||
# ***This an unfinished draft. Comments are welcome!***
|
||||
|
||||
**TODO:** We will need to do small adaptations to the verification
|
||||
spec to reflect the semantics in the LightStore (verified, trusted,
|
||||
untrusted, etc. not needed anymore). In more detail:
|
||||
|
||||
- The state of the Lightstore needs to go. Functions like `LatestVerified` can
|
||||
keep the name but will ignore state as it will not exist anymore.
|
||||
|
||||
- verification spec should be adapted to the second parameter of
|
||||
`VerifyToTarget`
|
||||
being a lightblock; new version number of function tag;
|
||||
|
||||
- We should clarify what is the expectation of VerifyToTarget
|
||||
so if it returns TimeoutError it can be assumed faulty. I guess that
|
||||
VerifyToTarget with correct full node should never terminate with
|
||||
TimeoutError.
|
||||
|
||||
- We need to introduce a new version number for the new
|
||||
specification. So we should decide how
|
||||
to handle that.
|
||||
|
||||
# Light Client Attack Detector
|
||||
|
||||
In this specification, we strengthen the light client to be resistant
|
||||
against so-called light client attacks. In a light client attack, all
|
||||
the correct Tendermint full nodes agree on the sequence of generated
|
||||
blocks (no fork), but a set of faulty full nodes attack a light client
|
||||
by generating (signing) a block that deviates from the block of the
|
||||
same height on the blockchain. In order to do so, some of these faulty
|
||||
full nodes must have been validators before and violate
|
||||
[[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link), as otherwise, if
|
||||
[[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link) would hold,
|
||||
[verification](verification) would satisfy
|
||||
[[LCV-SEQ-SAFE.1]](LCV-SEQ-SAFE-link).
|
||||
|
||||
An attack detector (or detector for short) is a mechanism that is used
|
||||
by the light client [supervisor](supervisor) after
|
||||
[verification](verification) of a new light block
|
||||
with the primary, to cross-check the newly learned light block with
|
||||
other peers (secondaries). It expects as input a light block with some
|
||||
height *root* (that serves as a root of trust), and a verification
|
||||
trace (a sequence of lightblocks) that the primary provided.
|
||||
|
||||
In case the detector observes a light client attack, it computes
|
||||
evidence data that can be used by Tendermint full nodes to isolate a
|
||||
set of faulty full nodes that are still within the unbonding period
|
||||
(more than 1/3 of the voting power of the validator set at some block of the chain),
|
||||
and report them via ABCI to the application of a Tendermint blockchain
|
||||
in order to punish faulty nodes.
|
||||
|
||||
## Context of this document
|
||||
|
||||
The light client [verification](verification) specification is
|
||||
designed for the Tendermint failure model (1/3 assumption)
|
||||
[[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link). It is safe under this
|
||||
assumption, and live if it can reliably (that is, no message loss, no
|
||||
duplication, and eventually delivered) and timely communicate with a
|
||||
correct full node. If [[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link) assumption is violated, the light client
|
||||
can be fooled to trust a light block that was not generated by
|
||||
Tendermint consensus.
|
||||
|
||||
This specification, the attack detector, is a "second line of
|
||||
defense", in case the 1/3 assumption is violated. Its goal is to
|
||||
detect a light client attack (conflicting light blocks) and collect
|
||||
evidence. However, it is impractical to probe all full nodes. At this
|
||||
time we consider a simple scheme of maintaining an address book of
|
||||
known full nodes from which a small subset (e.g., 4) are chosen
|
||||
initially to communicate with. More involved book keeping with
|
||||
probabilistic guarantees can be considered at later stages of the
|
||||
project.
|
||||
|
||||
The light client maintains a simple address book containing addresses
|
||||
of full nodes that it can pick as primary and secondaries. To obtain
|
||||
a new light block, the light client first does
|
||||
[verification](verification) with the primary, and then cross-checks
|
||||
the light block (and the trace of light blocks that led to it) with
|
||||
the secondaries using this specification.
|
||||
|
||||
## Tendermint Consensus and Light Client Attacks
|
||||
|
||||
In this section we will give some mathematical definitions of what we
|
||||
mean by light client attacks (that are considered in this
|
||||
specification) and how they differ from main-chain forks. To this end
|
||||
we start by defining some properties of the sequence of blocks that is
|
||||
decided upon by Tendermint consensus in normal operation (if the
|
||||
Tendermint failure model holds
|
||||
[[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link)),
|
||||
and then define different
|
||||
deviations that correspond to attack scenarios.
|
||||
|
||||
#### **[TMBC-GENESIS.1]**
|
||||
|
||||
Let *Genesis* be the agreed-upon initial block (file).
|
||||
|
||||
#### **[TMBC-FUNC-SIGN.1]**
|
||||
|
||||
Let *b* and *c* be two light blocks with *b.Header.Height + 1 =
|
||||
c.Header.Height*. We define the predicate **signs(b,c)** to hold
|
||||
iff *c.Header.LastCommit* is in *PossibleCommit(b)*.
|
||||
[[TMBC-SOUND-DISTR-POSS-COMMIT.1]](TMBC-SOUND-DISTR-POSS-COMMIT-link).
|
||||
|
||||
> The above encodes sequential verification, that is, intuitively,
|
||||
> b.Header.NextValidators = c.Header.Validators and 2/3 of
|
||||
> these Validators signed c?
|
||||
|
||||
#### **[TMBC-FUNC-SUPPORT.1]**
|
||||
|
||||
Let *b* and *c* be two light blocks. We define the predicate
|
||||
**supports(b,c,t)** to hold iff
|
||||
|
||||
- *t - trustingPeriod < b.Header.Time < t*
|
||||
- the voting power in *b.NextValidators* of nodes in *c.Commit*
|
||||
is more than 1/3 of *TotalVotingPower(b.Header.NextValidators)*
|
||||
|
||||
> That is, if the [Tendermint failure model](TMBC-FM-2THIRDS-link)
|
||||
> holds, then *c* has been signed by at least one correct full node, cf.
|
||||
> [[TMBC-VAL-CONTAINS-CORR.1]](TMBC-VAL-CONTAINS-CORR-link).
|
||||
> The following formalizes that *b* was properly generated by
|
||||
> Tendermint; *b* can be traced back to genesis
|
||||
|
||||
#### **[TMBC-SEQ-ROOTED.1]**
|
||||
|
||||
Let *b* be a light block.
|
||||
We define *sequ-rooted(b)* iff for all *i*, *1 <= i < h = b.Header.Height*,
|
||||
there exist light blocks *a(i)* s.t.
|
||||
|
||||
- *a(1) = Genesis* and
|
||||
- *a(h) = b* and
|
||||
- *signs( a(i) , a(i+1) )*.
|
||||
|
||||
> The following formalizes that *c* is trusted based on *b* in
|
||||
> skipping verification. Observe that we do not require here (yet)
|
||||
> that *b* was properly generated.
|
||||
|
||||
#### **[TMBC-SKIP-TRACE.1]**
|
||||
|
||||
Let *b* and *c* be light blocks. We define *skip-trace(b,c,t)* if at
|
||||
time t there exists an *h* and a sequence *a(1)*, ... *a(h)* s.t.
|
||||
|
||||
- *a(1) = b* and
|
||||
- *a(h) = c* and
|
||||
- *supports( a(i), a(i+1), t)*, for all i, *1 <= i < h*.
|
||||
|
||||
We call such a sequence *a(1)*, ... *a(h)* a **verification trace**.
|
||||
|
||||
> The following formalizes that two light blocks of the same height
|
||||
> should agree on the content of the header. Observe that *b* and *c*
|
||||
> may disagree on the Commit. This is a special case if the canonical
|
||||
> commit has not been decided on, that is, if b.Header.Height is the
|
||||
> maximum height of all blocks decided upon by Tendermint at this
|
||||
> moment.
|
||||
|
||||
#### **[TMBC-SIGN-SKIP-MATCH.1]**
|
||||
|
||||
Let *a*, *b*, *c*, be light blocks and *t* a time, we define
|
||||
*sign-skip-match(a,b,c,t) = true* iff the following implication
|
||||
evaluates to true:
|
||||
|
||||
- *sequ-rooted(a)* and
|
||||
- *b.Header.Height = c.Header.Height* and
|
||||
- *skip-trace(a,b,t)*
|
||||
- *skip-trace(a,c,t)*
|
||||
|
||||
implies *b.Header = c.Header*.
|
||||
|
||||
> Observe that *sign-skip-match* is defined via an implication. If it
|
||||
> evaluates to false this means that the left-hand-side of the
|
||||
> implication evaluates to true, and the right-hand-side evaluates to
|
||||
> false. In particular, there are two **different** headers *b* and
|
||||
> *c* that both can be verified from a common block *a* from the
|
||||
> chain. Thus, the following describes an attack.
|
||||
|
||||
#### **[TMBC-ATTACK.1]**
|
||||
|
||||
If there exists three light blocks a, b, and c, with
|
||||
*sign-skip-match(a,b,c,t) = false* then we have an *attack*. We say
|
||||
we have **an attack at height** *b.Header.Height* and write
|
||||
*attack(a,b,c,t)*.
|
||||
|
||||
> The lightblock *a* need not be unique, that is, there may be
|
||||
> several blocks that satisfy the above requirement for the same
|
||||
> blocks *b* and *c*.
|
||||
|
||||
[[TMBC-ATTACK.1]](#TMBC-ATTACK1) is a formalization of the violation
|
||||
of the agreement property based on the result of consensus, that is,
|
||||
the generated blocks.
|
||||
|
||||
**Remark.**
|
||||
Violation of agreement is only possible if more than 1/3 of the validators (or
|
||||
next validators) of some previous block deviated from the protocol. The
|
||||
upcoming "accountability" specification will describe how to compute
|
||||
a set of at least 1/3 faulty nodes from two conflicting blocks. []
|
||||
|
||||
There are different ways to characterize forks
|
||||
and attack scenarios. This specification uses the "node-based
|
||||
characterization of attacks" which focuses on what kinds of nodes are
|
||||
affected (light nodes vs. full nodes). For future reference and
|
||||
discussion we also provide a
|
||||
"block-based characterization of attacks" below.
|
||||
|
||||
### Node-based characterization of attacks
|
||||
|
||||
#### **[TMBC-MC-FORK.1]**
|
||||
|
||||
We say there is a (main chain) fork at time *t* if
|
||||
|
||||
- there are two correct full nodes *i* and *j* and
|
||||
- *i* is different from *j* and
|
||||
- *i* has decided on *b* and
|
||||
- *j* has decided on *c* and
|
||||
- there exist *a* such that *attack(a,b,c,t)*.
|
||||
|
||||
#### **[TMBC-LC-ATTACK.1]**
|
||||
|
||||
We say there is a light client attack at time *t*, if
|
||||
|
||||
- there is **no** (main chain) fork [[TMBC-MC-FORK.1]](#TMBC-MC-FORK1), and
|
||||
- there exist nodes that have computed light blocks *b* and *c* and
|
||||
- there exist *a* such that *attack(a,b,c,t)*.
|
||||
|
||||
We say the attack is at height *a.Header.Height*.
|
||||
|
||||
> In this specification we consider detection of light client
|
||||
> attacks. Intuitively, the case we consider is that
|
||||
> light block *b* is the one from the
|
||||
> blockchain, and some attacker has computed *c* and tries to wrongly
|
||||
> convince
|
||||
> the light client that *c* is the block from the chain.
|
||||
|
||||
#### **[TMBC-LC-ATTACK-EVIDENCE.1]**
|
||||
|
||||
We consider the following case of a light client attack
|
||||
[[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1):
|
||||
|
||||
- *attack(a,b,c,t)*
|
||||
- there is a peer p1 that has a sequence *chain* of blocks from *a* to *b*
|
||||
- *skip-trace(a,c,t)*: by [[TMBC-SKIP-TRACE.1]](#TMBC-SKIP-TRACE1) there is a
|
||||
verification trace *v* of the form *a = v(1)*, ... *v(h) = c*
|
||||
|
||||
Evidence for p1 (that proves an attack) consists for index i
|
||||
of v(i) and v(i+1) such that
|
||||
|
||||
- E1(i). v(i) is equal to the block of *chain* at height v(i).Height, and
|
||||
- E2(i). v(i+1) that is different from the block of *chain* at
|
||||
height v(i+1).height
|
||||
|
||||
> Observe p1 can
|
||||
>
|
||||
> - check that v(i+1) differs from its block at that height, and
|
||||
> - verify v(i+1) in one step from v(i) as v is a verification trace.
|
||||
|
||||
**Proposition.** In the case of attack, evidence exists.
|
||||
*Proof.* First observe that
|
||||
|
||||
- (A). (NOT E2(i)) implies E1(i+1)
|
||||
|
||||
Now by contradiction assume there is no evidence. Thus
|
||||
|
||||
- for all i, we have NOT E1(i) or NOT E2(i)
|
||||
- for i = 1 we have E1(1) and thus NOT E2(1)
|
||||
thus by induction on i, by (A) we have for all i that **E1(i)**
|
||||
- from attack we have E2(h-1), and as there is no evidence for
|
||||
i = h - 1 we get **NOT E1(h-1)**. Contradiction.
|
||||
QED.
|
||||
|
||||
#### **[TMBC-LC-EVIDENCE-DATA.1]**
|
||||
|
||||
To prove the attack to p1, because of Point E1, it is sufficient to
|
||||
submit
|
||||
|
||||
- v(i).Height (rather than v(i)).
|
||||
- v(i+1)
|
||||
|
||||
This information is *evidence for height v(i).Height*.
|
||||
|
||||
### Block-based characterization of attacks
|
||||
|
||||
In this section we provide a different characterization of attacks. It
|
||||
is not defined on the nodes that are affected but purely on the
|
||||
content of the blocks. In that sense these definitions are less
|
||||
operational.
|
||||
|
||||
> They might be relevant for a closer analysis of fork scenarios on the
|
||||
> chain, which is out of the scope of this specification.
|
||||
|
||||
#### **[TMBC-SIGN-UNIQUE.1]**
|
||||
|
||||
Let *b* and *c* be light blocks, we define the predicate
|
||||
*sign-unique(b,c)* to evaluate to true iff the following implication
|
||||
evaluates to true:
|
||||
|
||||
- *b.Header.Height = c.Header.Height* and
|
||||
- *sequ-rooted(b)* and
|
||||
- *sequ-rooted(c)*
|
||||
|
||||
implies *b = c*.
|
||||
|
||||
#### **[TMBC-BLOCKS-MCFORK.1]**
|
||||
|
||||
If there exists two light blocks b and c, with *sign-unique(b,c) =
|
||||
false* then we have a *fork*.
|
||||
|
||||
> The difference of the above definition to
|
||||
> [[TMBC-MC-FORK.1]](#TMBC-MC-FORK1) is subtle. The latter requires a
|
||||
> full node being affected by a bad block while
|
||||
> [[TMBC-BLOCKS-MCFORK.1]](#TMBC-BLOCKS-MCFORK1) just requires that a
|
||||
> bad block exists, possibly in memory of an attacker.
|
||||
> The following captures a light client fork. There is no fork up to
|
||||
> the height of block b. However, c is of that height, is different,
|
||||
> and passes skipping verification. It is a stricter property than
|
||||
> [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1), as
|
||||
> [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1) requires that no correct full
|
||||
> node is affected.
|
||||
|
||||
#### **[TMBC-BLOCKS-LCFORK.1]**
|
||||
|
||||
Let *a*, *b*, *c*, be light blocks and *t* a time. We define
|
||||
*light-client-fork(a,b,c,t)* iff
|
||||
|
||||
- *sign-skip-match(a,b,c,t) = false* and
|
||||
- *sequ-rooted(b)* and
|
||||
- *b* is "unique", that is, for all *d*, *sequ-rooted(d)* and
|
||||
*d.Header.Height = b.Header.Height* implies *d = b*
|
||||
|
||||
> Finally, let us also define bogus blocks that have no support.
|
||||
> Observe that bogus is even defined if there is a fork.
|
||||
> Also, for the definition it would be sufficient to restrict *a* to
|
||||
> *a.height < b.height* (which is implied by the definitions which
|
||||
> unfold until *supports()*).
|
||||
|
||||
#### **[TMBC-BOGUS.1]**
|
||||
|
||||
Let *b* be a light block and *t* a time. We define *bogus(b,t)* iff
|
||||
|
||||
- *sequ-rooted(b) = false* and
|
||||
- for all *a*, *sequ-rooted(a)* implies *skip-trace(a,b,t) = false*
|
||||
|
||||
### Informal Problem statement
|
||||
|
||||
There is no sequential specification: the detector only makes sense
|
||||
in a distributed systems where some nodes misbehave.
|
||||
|
||||
We work under the assumption that full nodes and validators are
|
||||
responsible for detecting attacks on the main chain, and the evidence
|
||||
reactor takes care of broadcasting evidence to communicate
|
||||
misbehaving nodes via ABCI to the application, and halt the chain in
|
||||
case of a fork. The point of this specification is to shield a light
|
||||
clients against attacks that cannot be detected by full nodes, and
|
||||
are fully addressed at light clients (and consequently IBC relayers,
|
||||
which use the light client protocols to observe the state of a
|
||||
blockchain). In order to provide full nodes the incentive to follow
|
||||
the protocols when communicating with the light client, this
|
||||
specification also considers the generation of evidence that will
|
||||
also be processed by the Tendermint blockchain.
|
||||
|
||||
#### **[LCD-IP-MODEL.1]**
|
||||
|
||||
The detector is designed under the assumption that
|
||||
|
||||
- [[TMBC-FM-2THIRDS]](TMBC-FM-2THIRDS-link) may be violated
|
||||
- there is no fork on the main chain.
|
||||
|
||||
> As a result some faulty full nodes may launch an attack on a light
|
||||
> client.
|
||||
|
||||
The following requirements are operational in that they describe how
|
||||
things should be done, rather than what should be done. However, they
|
||||
do not constitute temporal logic verification conditions. For those,
|
||||
see [LCD-DIST-*] below.
|
||||
|
||||
The detector is called in the [supervisor](supervisor) as follows
|
||||
|
||||
```go
|
||||
Evidences := AttackDetector(root_of_trust, verifiedLS);`
|
||||
```
|
||||
|
||||
where
|
||||
|
||||
- `root-of-trust` is a light block that is trusted (that is,
|
||||
except upon initialization, the primary and the secondaries
|
||||
agreed on in the past), and
|
||||
- `verifiedLS` is a lightstore that contains a verification trace that
|
||||
starts from a lightblock that can be verified with the
|
||||
`root-of-trust` in one step and ends with a lightblock of the height
|
||||
requested by the user
|
||||
- `Evidences` is a list of evidences for misbehavior
|
||||
|
||||
#### **[LCD-IP-STATEMENT.1]**
|
||||
|
||||
Whenever AttackDetector is called, the detector should for each
|
||||
secondary try to replay the verification trace `verifiedLS` with the
|
||||
secondary
|
||||
|
||||
- in case replaying leads to detection of a light client attack
|
||||
(one of the lightblocks differ from the one in verifiedLS with
|
||||
the same height), we should return evidence
|
||||
- if the secondary cannot provide a verification trace, we have no
|
||||
proof for an attack. Block *b* may be bogus. In this case the
|
||||
secondary is faulty and it should be replaced.
|
||||
|
||||
## Assumptions/Incentives/Environment
|
||||
|
||||
It is not in the interest of faulty full nodes to talk to the
|
||||
detector as long as the detector is connected to at least one
|
||||
correct full node. This would only increase the likelihood of
|
||||
misbehavior being detected. Also we cannot punish them easily
|
||||
(cheaply). The absence of a response need not be the fault of the full
|
||||
node.
|
||||
|
||||
Correct full nodes have the incentive to respond, because the
|
||||
detector may help them to understand whether their header is a good
|
||||
one. We can thus base liveness arguments of the detector on
|
||||
the assumptions that correct full nodes reliably talk to the
|
||||
detector.
|
||||
|
||||
### Assumptions
|
||||
|
||||
#### **[LCD-A-CorrFull.1]**
|
||||
|
||||
At all times there is at least one correct full
|
||||
node among the primary and the secondaries.
|
||||
|
||||
> For this version of the detection we take this assumption. It
|
||||
> allows us to establish the invariant that the lightblock
|
||||
> `root-of-trust` is always the one from the blockchain, and we can
|
||||
> use it as starting point for the evidence computation. Moreover, it
|
||||
> allows us to establish the invariant at the supervisor that any
|
||||
> lightblock in the (top-level) lightstore is from the blockchain.
|
||||
> In the future we might design a lightclient based on the assumption
|
||||
> that at least in regular intervals the lightclient is connected to a
|
||||
> correct full node. This will require the detector to reconsider
|
||||
> `root-of-trust`, and remove lightblocks from the top-level
|
||||
> lightstore.
|
||||
|
||||
#### **[LCD-A-RelComm.1]**
|
||||
|
||||
Communication between the detector and a correct full node is
|
||||
reliable and bounded in time. Reliable communication means that
|
||||
messages are not lost, not duplicated, and eventually delivered. There
|
||||
is a (known) end-to-end delay *Delta*, such that if a message is sent
|
||||
at time *t* then it is received and processed by time *t + Delta*.
|
||||
This implies that we need a timeout of at least *2 Delta* for remote
|
||||
procedure calls to ensure that the response of a correct peer arrives
|
||||
before the timeout expires.
|
||||
|
||||
## Definitions
|
||||
|
||||
### Evidence
|
||||
|
||||
Following the definition of
|
||||
[[TMBC-LC-ATTACK-EVIDENCE.1]](#TMBC-LC-ATTACK-EVIDENCE1), by evidence
|
||||
we refer to a variable of the following type
|
||||
|
||||
#### **[LC-DATA-EVIDENCE.1]**
|
||||
|
||||
```go
|
||||
type LightClientAttackEvidence struct {
|
||||
ConflictingBlock LightBlock
|
||||
CommonHeight int64
|
||||
}
|
||||
```
|
||||
|
||||
As the above data is computed for a specific peer, the following
|
||||
data structure wraps the evidence and adds the peerID.
|
||||
|
||||
#### **[LC-DATA-EVIDENCE-INT.1]**
|
||||
|
||||
```go
|
||||
type InternalEvidence struct {
|
||||
Evidence LightClientAttackEvidence
|
||||
Peer PeerID
|
||||
}
|
||||
```
|
||||
|
||||
#### **[LC-SUMBIT-EVIDENCE.1]**
|
||||
|
||||
```go
|
||||
func submitEvidence(Evidences []InternalEvidence)
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- for each `ev` in `Evidences`: submit `ev.Evidence` to `ev.Peer`
|
||||
|
||||
---
|
||||
|
||||
### LightStore
|
||||
|
||||
Lightblocks and LightStores are defined in the verification
|
||||
specification [LCV-DATA-LIGHTBLOCK.1] and [LCV-DATA-LIGHTSTORE.1]. See
|
||||
the [verification specification][verification] for details.
|
||||
|
||||
## (Distributed) Problem statement
|
||||
|
||||
> As the attack detector is there to reduce the impact of faulty
|
||||
> nodes, and faulty nodes imply that there is a distributed system,
|
||||
> there is no sequential specification to which this distributed
|
||||
> problem statement may refer to.
|
||||
|
||||
The detector gets as input a trusted lightblock called *root* and an
|
||||
auxiliary lightstore called *primary_trace* with lightblocks that have
|
||||
been verified before, and that were provided by the primary.
|
||||
|
||||
#### **[LCD-DIST-INV-ATTACK.1]**
|
||||
|
||||
If the detector returns evidence for height *h*
|
||||
[[TMBC-LC-EVIDENCE-DATA.1]](#TMBC-LC-EVIDENCE-DATA1), then there is an
|
||||
attack at height *h*. [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1)
|
||||
|
||||
#### **[LCD-DIST-INV-STORE.1]**
|
||||
|
||||
If the detector does not return evidence, then *primary_trace*
|
||||
contains only blocks from the blockchain.
|
||||
|
||||
#### **[LCD-DIST-LIVE.1]**
|
||||
|
||||
The detector eventually terminates.
|
||||
|
||||
#### **[LCD-DIST-TERM-NORMAL.1]**
|
||||
|
||||
If
|
||||
|
||||
- the *primary_trace* contains only blocks from the blockchain, and
|
||||
- there is no attack, and
|
||||
- *Secondaries* is always non-empty, and
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the detector does not return evidence.
|
||||
|
||||
#### **[LCD-DIST-TERM-ATTACK.1]**
|
||||
|
||||
If
|
||||
|
||||
- there is an attack, and
|
||||
- a secondary reports a block that conflicts
|
||||
with one of the blocks in *primary_trace*, and
|
||||
- *Secondaries* is always non-empty, and
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the detector returns evidence.
|
||||
|
||||
> Observe that above we require that "a secondary reports a block that
|
||||
> conflicts". If there is an attack, but no secondary tries to launch
|
||||
> it against the detector (or the message from the secondary is lost
|
||||
> by the network), then there is nothing to detect for us.
|
||||
|
||||
#### **[LCD-DIST-SAFE-SECONDARY.1]**
|
||||
|
||||
No correct secondary is ever replaced.
|
||||
|
||||
#### **[LCD-DIST-SAFE-BOGUS.1]**
|
||||
|
||||
If
|
||||
|
||||
- a secondary reports a bogus lightblock,
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the secondary is replaced before the detector terminates.
|
||||
|
||||
> The above property is quite operational ("reports"), but it captures
|
||||
> quite closely the requirement. As the
|
||||
> detector only makes sense in a distributed setting, and does
|
||||
> not have a sequential specification, less "pure"
|
||||
> specification are acceptable.
|
||||
|
||||
# Protocol
|
||||
|
||||
## Functions and Data defined in other Specifications
|
||||
|
||||
### From the supervisor
|
||||
|
||||
```go
|
||||
Replace_Secondary(addr Address, root-of-trust LightBlock)
|
||||
```
|
||||
|
||||
### From the verifier
|
||||
|
||||
```go
|
||||
func VerifyToTarget(primary PeerID, root LightBlock,
|
||||
targetHeight Height) (LightStore, Result)
|
||||
```
|
||||
|
||||
> Note: the above differs from the current version in the second
|
||||
> parameter. verification will be revised.
|
||||
|
||||
Observe that `VerifyToTarget` does communication with the secondaries
|
||||
via the function [FetchLightBlock](fetch).
|
||||
|
||||
### Shared data of the light client
|
||||
|
||||
- a pool of full nodes *FullNodes* that have not been contacted before
|
||||
- peer set called *Secondaries*
|
||||
- primary
|
||||
|
||||
> Note that the lightStore is not needed to be shared.
|
||||
|
||||
## Outline
|
||||
|
||||
The problem laid out is solved by calling the function `AttackDetector`
|
||||
with a lightstore that contains a light block that has just been
|
||||
verified by the verifier.
|
||||
|
||||
Then `AttackDetector` downloads headers from the secondaries. In case
|
||||
a conflicting header is downloaded from a secondary,
|
||||
`CreateEvidenceForPeer` which computes evidence in the case that
|
||||
indeed an attack is confirmed. It could be that the secondary reports
|
||||
a bogus block, which means that there need not be an attack, and the
|
||||
secondary is replaced.
|
||||
|
||||
## Details of the functions
|
||||
|
||||
#### **[LCD-FUNC-DETECTOR.1]:**
|
||||
|
||||
```go
|
||||
func AttackDetector(root LightBlock, primary_trace []LightBlock)
|
||||
([]InternalEvidence) {
|
||||
|
||||
Evidences := new []InternalEvidence;
|
||||
|
||||
for each secondary in Secondaries {
|
||||
// we replay the primary trace with the secondary, in
|
||||
// order to generate evidence that we can submit to the
|
||||
// secodary. We return the evidence + the trace the
|
||||
// secondary told us that spans the evidence at its local store
|
||||
|
||||
EvidenceForSecondary, newroot, secondary_trace, result :=
|
||||
CreateEvidenceForPeer(secondary,
|
||||
root,
|
||||
primary_trace);
|
||||
if result == FaultyPeer {
|
||||
Replace_Secondary(root);
|
||||
}
|
||||
else if result == FoundEvidence {
|
||||
// the conflict is not bogus
|
||||
Evidences.Add(EvidenceForSecondary);
|
||||
// we replay the secondary trace with the primary, ...
|
||||
EvidenceForPrimary, _, result :=
|
||||
CreateEvidenceForPeer(primary,
|
||||
newroot,
|
||||
secondary_trace);
|
||||
if result == FoundEvidence {
|
||||
Evidences.Add(EvidenceForPrimary);
|
||||
}
|
||||
// At this point we do not care about the other error
|
||||
// codes. We already have generated evidence for an
|
||||
// attack and need to stop the lightclient. It does not
|
||||
// help to call replace_primary. Also we will use the
|
||||
// same primary to check with other secondaries in
|
||||
// later iterations of the loop
|
||||
}
|
||||
// In the case where the secondary reports NoEvidence
|
||||
// we do nothing
|
||||
}
|
||||
return Evidences;
|
||||
}
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- root and primary trace are a verification trace
|
||||
- Expected postcondition
|
||||
- solves the problem statement (if attack found, then evidence is reported)
|
||||
- Error condition
|
||||
- `ErrorTrustExpired`: fails if root expires (outside trusting
|
||||
period) [[LCV-INV-TP.1]](LCV-INV-TP1-link)
|
||||
- `ErrorNoPeers`: if no peers are left to replace secondaries, and
|
||||
no evidence was found before that happened
|
||||
|
||||
---
|
||||
|
||||
```go
|
||||
func CreateEvidenceForPeer(peer PeerID, root LightBlock, trace LightStore)
|
||||
(Evidence, LightBlock, LightStore, result) {
|
||||
|
||||
common := root;
|
||||
|
||||
for i in 1 .. len(trace) {
|
||||
auxLS, result := VerifyToTarget(peer, common, trace[i].Header.Height)
|
||||
|
||||
if result != ResultSuccess {
|
||||
// something went wrong; peer did not provide a verifyable block
|
||||
return (nil, nil, nil, FaultyPeer)
|
||||
}
|
||||
else {
|
||||
if auxLS.LatestVerified().Header != trace[i].Header {
|
||||
// the header reported by the peer differs from the
|
||||
// reference header in trace but both could be
|
||||
// verified from common in one step.
|
||||
// we can create evidence for submission to the secondary
|
||||
ev := new InternalEvidence;
|
||||
ev.Evidence.ConflictingBlock := trace[i];
|
||||
ev.Evidence.CommonHeight := common.Height;
|
||||
ev.Peer := peer
|
||||
return (ev, common, auxLS, FoundEvidence)
|
||||
}
|
||||
else {
|
||||
// the peer agrees with the trace, we move common forward
|
||||
// we could delete auxLS as it will be overwritten in
|
||||
// the next iteration
|
||||
common := trace[i]
|
||||
}
|
||||
}
|
||||
}
|
||||
return (nil, nil, nil, NoEvidence)
|
||||
}
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- root and trace are a verification trace
|
||||
- Expected postcondition
|
||||
- finds evidence where trace and peer diverge
|
||||
- Error condition
|
||||
- `ErrorTrustExpired`: fails if root expires (outside trusting
|
||||
period) [[LCV-INV-TP.1]](LCV-INV-TP1-link)
|
||||
- If `VerifyToTarget` returns error but root is not expired then return
|
||||
`FaultyPeer`
|
||||
|
||||
---
|
||||
|
||||
## Correctness arguments
|
||||
|
||||
#### Argument for [[LCD-DIST-INV-ATTACK.1]](#LCD-DIST-INV-ATTACK1)
|
||||
|
||||
Under the assumption that root and trace are a verification trace,
|
||||
when in `CreateEvidenceForPeer` the detector the detector creates
|
||||
evidence, then the lightclient has seen two different headers (one via
|
||||
`trace` and one via `VerifyToTarget` for the same height that can both
|
||||
be verified in one step.
|
||||
|
||||
#### Argument for [[LCD-DIST-INV-STORE.1]](#LCD-DIST-INV-STORE1)
|
||||
|
||||
We assume that there is at least one correct peer, and there is no
|
||||
fork. As a result the correct peer has the correct sequence of
|
||||
blocks. Since the primary_trace is checked block-by-block also against
|
||||
each secondary, and at no point evidence was generated that means at
|
||||
no point there were conflicting blocks.
|
||||
|
||||
#### Argument for [[LCD-DIST-LIVE.1]](#LCD-DIST-LIVE1)
|
||||
|
||||
At the latest when [[LCV-INV-TP.1]](LCV-INV-TP1-link) is violated,
|
||||
`AttackDetector` terminates.
|
||||
|
||||
#### Argument for [[LCD-DIST-TERM-NORMAL.1]](#LCD-DIST-TERM-NORMAL1)
|
||||
|
||||
As there are finitely many peers, eventually the main loop
|
||||
terminates. As there is no attack no evidence can be generated.
|
||||
|
||||
#### Argument for [[LCD-DIST-TERM-ATTACK.1]](#LCD-DIST-TERM-ATTACK1)
|
||||
|
||||
Argument similar to [[LCD-DIST-TERM-NORMAL.1]](#LCD-DIST-TERM-NORMAL1)
|
||||
|
||||
#### Argument for [[LCD-DIST-SAFE-SECONDARY.1]](#LCD-DIST-SAFE-SECONDARY1)
|
||||
|
||||
Secondaries are only replaced if they time-out or if they report bogus
|
||||
blocks. The former is ruled out by the timing assumption, the latter
|
||||
by correct peers only reporting blocks from the chain.
|
||||
|
||||
#### Argument for [[LCD-DIST-SAFE-BOGUS.1]](#LCD-DIST-SAFE-BOGUS1)
|
||||
|
||||
Once a bogus block is recognized as such the secondary is removed.
|
||||
|
||||
# References
|
||||
|
||||
> links to other specifications/ADRs this document refers to
|
||||
|
||||
[[verification]] The specification of the light client verification.
|
||||
|
||||
[[supervisor]] The specification of the light client supervisor.
|
||||
|
||||
[verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md
|
||||
|
||||
[supervisor]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor.md
|
||||
|
||||
[block]: https://github.com/tendermint/spec/blob/d46cd7f573a2c6a2399fcab2cde981330aa63f37/spec/core/data_structures.md
|
||||
|
||||
[TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#tmbc-fm-2thirds1
|
||||
|
||||
[TMBC-SOUND-DISTR-POSS-COMMIT-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#tmbc-sound-distr-poss-commit1
|
||||
|
||||
[LCV-SEQ-SAFE-link]:https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#lcv-seq-safe1
|
||||
|
||||
[TMBC-VAL-CONTAINS-CORR-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#tmbc-val-contains-corr1
|
||||
|
||||
[fetch]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#lcv-func-fetch1
|
||||
|
||||
[LCV-INV-TP1-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification.md#lcv-inv-tp1
|
||||
831
spec/light-client/detection/detection_003_reviewed.md
Normal file
@@ -0,0 +1,831 @@
|
||||
# Light Client Attack Detector
|
||||
|
||||
In this specification, we strengthen the light client to be resistant
|
||||
against so-called light client attacks. In a light client attack, all
|
||||
the correct Tendermint full nodes agree on the sequence of generated
|
||||
blocks (no fork), but a set of faulty full nodes attack a light client
|
||||
by generating (signing) a block that deviates from the block of the
|
||||
same height on the blockchain. In order to do so, some of these faulty
|
||||
full nodes must have been validators before and violate the assumption
|
||||
of more than two thirds of "correct voting power"
|
||||
[[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link], as otherwise, if
|
||||
[[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] would hold,
|
||||
[verification][verification] would satisfy
|
||||
[[LCV-SEQ-SAFE.1]][LCV-SEQ-SAFE-link].
|
||||
|
||||
An attack detector (or detector for short) is a mechanism that is used
|
||||
by the light client [supervisor][supervisor] after
|
||||
[verification][verification] of a new light block
|
||||
with the primary, to cross-check the newly learned light block with
|
||||
other peers (secondaries). It expects as input a light block with some
|
||||
height *root* (that serves as a root of trust), and a verification
|
||||
trace (a sequence of lightblocks) that the primary provided.
|
||||
|
||||
In case the detector observes a light client attack, it computes
|
||||
evidence data that can be used by Tendermint full nodes to isolate a
|
||||
set of faulty full nodes that are still within the unbonding period
|
||||
(more than 1/3 of the voting power of the validator set at some block
|
||||
of the chain), and report them via ABCI (application/blockchain
|
||||
interface)
|
||||
to the application of a
|
||||
Tendermint blockchain in order to punish faulty nodes.
|
||||
|
||||
## Context of this document
|
||||
|
||||
The light client [verification][verification] specification is
|
||||
designed for the Tendermint failure model (1/3 assumption)
|
||||
[[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link]. It is safe under this
|
||||
assumption, and live if it can reliably (that is, no message loss, no
|
||||
duplication, and eventually delivered) and timely communicate with a
|
||||
correct full node. If [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link]
|
||||
assumption is violated, the light client can be fooled to trust a
|
||||
light block that was not generated by Tendermint consensus.
|
||||
|
||||
This specification, the attack detector, is a "second line of
|
||||
defense", in case the 1/3 assumption is violated. Its goal is to
|
||||
detect a light client attack (conflicting light blocks) and collect
|
||||
evidence. However, it is impractical to probe all full nodes. At this
|
||||
time we consider a simple scheme of maintaining an address book of
|
||||
known full nodes from which a small subset (e.g., 4) are chosen
|
||||
initially to communicate with. More involved book keeping with
|
||||
probabilistic guarantees can be considered at later stages of the
|
||||
project.
|
||||
|
||||
The light client maintains a simple address book containing addresses
|
||||
of full nodes that it can pick as primary and secondaries. To obtain
|
||||
a new light block, the light client first does
|
||||
[verification][verification] with the primary, and then cross-checks
|
||||
the light block (and the trace of light blocks that led to it) with
|
||||
the secondaries using this specification.
|
||||
|
||||
# Outline
|
||||
|
||||
- [Part I](#part-i---Tendermint-Consensus-and-Light-Client-Attacks):
|
||||
Formal definitions of lightclient attacks, based on basic
|
||||
properties of Tendermint consensus.
|
||||
- [Node-based characterization of
|
||||
attacks](#Node-based-characterization-of-attacks). The
|
||||
definition of attacks used in the problem statement of
|
||||
this specification.
|
||||
|
||||
- [Block-based characterization of attacks](#Block-based-characterization-of-attacks). Alternative definitions
|
||||
provided for future reference.
|
||||
|
||||
- [Part II](#part-ii---problem-statement): Problem statement of
|
||||
lightclient attack detection
|
||||
|
||||
- [Informal Problem Statement](#informal-problem-statement)
|
||||
- [Assumptions](#Assumptions)
|
||||
- [Definitions](#definitions)
|
||||
- [Distributed Problem statement](#Distributed-Problem-statement)
|
||||
|
||||
- [Part III](#part-iii---protocol): The protocol
|
||||
|
||||
- [Functions and Data defined in other Specifications](#Functions-and-Data-defined-in-other-Specifications)
|
||||
- [Outline of Solution](#Outline-of-solution)
|
||||
- [Details of the functions](#Details-of-the-functions)
|
||||
- [Correctness arguments](#Correctness-arguments)
|
||||
|
||||
# Part I - Tendermint Consensus and Light Client Attacks
|
||||
|
||||
In this section we will give some mathematical definitions of what we
|
||||
mean by light client attacks (that are considered in this
|
||||
specification) and how they differ from main-chain forks. To this end,
|
||||
we start by defining some properties of the sequence of blocks that is
|
||||
decided upon by Tendermint consensus in normal operation (if the
|
||||
Tendermint failure model holds
|
||||
[[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link]),
|
||||
and then define different
|
||||
deviations that correspond to attack scenarios. We consider the notion
|
||||
of [light blocks][LCV-LB-link] and [headers][LVC-HD-link].
|
||||
|
||||
#### **[TMBC-GENESIS.1]**
|
||||
|
||||
Let *Genesis* be the agreed-upon initial block (file).
|
||||
|
||||
#### **[TMBC-FUNC-SIGN.1]**
|
||||
|
||||
Let *b* and *c* be two light blocks with *b.Header.Height + 1 =
|
||||
c.Header.Height*. We define the predicate **signs(b,c)** to hold
|
||||
iff *c.Header.LastCommit* is in *PossibleCommit(b)*.
|
||||
[[TMBC-SOUND-DISTR-POSS-COMMIT.1]][TMBC-SOUND-DISTR-POSS-COMMIT-link].
|
||||
|
||||
> The above encodes sequential verification, that is, intuitively,
|
||||
> b.Header.NextValidators = c.Header.Validators and 2/3 of
|
||||
> these Validators signed c.
|
||||
|
||||
#### **[TMBC-FUNC-SUPPORT.1]**
|
||||
|
||||
Let *b* and *c* be two light blocks. We define the predicate
|
||||
**supports(b,c,t)** to hold iff
|
||||
|
||||
- *t - trustingPeriod < b.Header.Time < t*
|
||||
- the voting power in *b.NextValidators* of nodes in *c.Commit*
|
||||
is more than 1/3 of *TotalVotingPower(b.Header.NextValidators)*
|
||||
|
||||
> That is, if the [Tendermint failure model][TMBC-FM-2THIRDS-link]
|
||||
> holds, then *c* has been signed by at least one correct full node, cf.
|
||||
> [[TMBC-VAL-CONTAINS-CORR.1]][TMBC-VAL-CONTAINS-CORR-link].
|
||||
> The following formalizes that *b* was properly generated by
|
||||
> Tendermint; *b* can be traced back to genesis.
|
||||
|
||||
#### **[TMBC-SEQ-ROOTED.1]**
|
||||
|
||||
Let *b* be a light block.
|
||||
We define *sequ-rooted(b)* iff for all *i*, *1 <= i < h = b.Header.Height*,
|
||||
there exist light blocks *a(i)* s.t.
|
||||
|
||||
- *a(1) = Genesis* and
|
||||
- *a(h) = b* and
|
||||
- *signs( a(i) , a(i+1) )*.
|
||||
|
||||
> The following formalizes that *c* is trusted based on *b* in
|
||||
> skipping verification. Observe that we do not require here (yet)
|
||||
> that *b* was properly generated.
|
||||
|
||||
#### **[TMBC-SKIP-TRACE.1]**
|
||||
|
||||
Let *b* and *c* be light blocks. We define *skip-trace(b,c,t)* if at
|
||||
time t there exists an integer *h* and a sequence *a(1)*, ... *a(h)* s.t.
|
||||
|
||||
- *a(1) = b* and
|
||||
- *a(h) = c* and
|
||||
- *supports( a(i), a(i+1), t)*, for all i, *1 <= i < h*.
|
||||
|
||||
We call such a sequence *a(1)*, ... *a(h)* a **verification trace**.
|
||||
|
||||
> The following formalizes that two light blocks of the same height
|
||||
> should agree on the content of the header. Observe that *b* and *c*
|
||||
> may disagree on the Commit. This is a special case if the canonical
|
||||
> commit has not been decided on yet, that is, if b.Header.Height is the
|
||||
> maximum height of all blocks decided upon by Tendermint at this
|
||||
> moment.
|
||||
|
||||
#### **[TMBC-SIGN-SKIP-MATCH.1]**
|
||||
|
||||
Let *a*, *b*, *c*, be light blocks and *t* a time, we define
|
||||
*sign-skip-match(a,b,c,t) = true* iff the following implication
|
||||
evaluates to true:
|
||||
|
||||
- *sequ-rooted(a)* and
|
||||
- *b.Header.Height = c.Header.Height* and
|
||||
- *skip-trace(a,b,t)*
|
||||
- *skip-trace(a,c,t)*
|
||||
|
||||
implies *b.Header = c.Header*.
|
||||
|
||||
> Observe that *sign-skip-match* is defined via an implication. If it
|
||||
> evaluates to false this means that the left-hand-side of the
|
||||
> implication evaluates to true, and the right-hand-side evaluates to
|
||||
> false. In particular, there are two **different** headers *b* and
|
||||
> *c* that both can be verified from a common block *a* from the
|
||||
> chain. Thus, the following describes an attack.
|
||||
|
||||
#### **[TMBC-ATTACK.1]**
|
||||
|
||||
If there exists three light blocks a, b, and c, with
|
||||
*sign-skip-match(a,b,c,t) = false* then we have an *attack*. We say
|
||||
we have **an attack at height** *b.Header.Height* and write
|
||||
*attack(a,b,c,t)*.
|
||||
|
||||
> The lightblock *a* need not be unique, that is, there may be
|
||||
> several blocks that satisfy the above requirement for the same
|
||||
> blocks *b* and *c*.
|
||||
|
||||
[[TMBC-ATTACK.1]](#TMBC-ATTACK1) is a formalization of the violation
|
||||
of the agreement property based on the result of consensus, that is,
|
||||
the generated blocks.
|
||||
|
||||
**Remark.**
|
||||
Violation of agreement is only possible if more than 1/3 of the validators (or
|
||||
next validators) of some previous block deviated from the protocol. The
|
||||
upcoming "accountability" specification will describe how to compute
|
||||
a set of at least 1/3 faulty nodes from two conflicting blocks. []
|
||||
|
||||
There are different ways to characterize forks
|
||||
and attack scenarios. This specification uses the "node-based
|
||||
characterization of attacks" which focuses on what kinds of nodes are
|
||||
affected (light nodes vs. full nodes). For future reference and
|
||||
discussion we also provide a
|
||||
"block-based characterization of attacks" below.
|
||||
|
||||
## Node-based characterization of attacks
|
||||
|
||||
#### **[TMBC-MC-FORK.1]**
|
||||
|
||||
We say there is a (main chain) fork at time *t* if
|
||||
|
||||
- there are two correct full nodes *i* and *j* and
|
||||
- *i* is different from *j* and
|
||||
- *i* has decided on *b* and
|
||||
- *j* has decided on *c* and
|
||||
- there exist *a* such that *attack(a,b,c,t)*.
|
||||
|
||||
#### **[TMBC-LC-ATTACK.1]**
|
||||
|
||||
We say there is a light client attack at time *t*, if
|
||||
|
||||
- there is **no** (main chain) fork [[TMBC-MC-FORK.1]](#TMBC-MC-FORK1), and
|
||||
- there exist nodes that have computed light blocks *b* and *c* and
|
||||
- there exist *a* such that *attack(a,b,c,t)*.
|
||||
|
||||
We say the attack is at height *a.Header.Height*.
|
||||
|
||||
> In this specification we consider detection of light client
|
||||
> attacks. Intuitively, the case we consider is that
|
||||
> light block *b* is the one from the
|
||||
> blockchain, and some attacker has computed *c* and tries to wrongly
|
||||
> convince
|
||||
> the light client that *c* is the block from the chain.
|
||||
|
||||
#### **[TMBC-LC-ATTACK-EVIDENCE.1]**
|
||||
|
||||
We consider the following case of a light client attack
|
||||
[[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1):
|
||||
|
||||
- *attack(a,b,c,t)*
|
||||
- there is a peer p1 that has a sequence *chain* of blocks from *a* to *b*
|
||||
- *skip-trace(a,c,t)*: by [[TMBC-SKIP-TRACE.1]](#TMBC-SKIP-TRACE1) there is a
|
||||
verification trace *v* of the form *a = v(1)*, ... *v(h) = c*
|
||||
|
||||
Evidence for p1 (that proves an attack to p1) consists for index i
|
||||
of v(i) and v(i+1) such that
|
||||
|
||||
- E1(i). v(i) is equal to the block of *chain* at height v(i).Height, and
|
||||
- E2(i). v(i+1) that is different from the block of *chain* at
|
||||
height v(i+1).height
|
||||
|
||||
> Observe p1 can
|
||||
>
|
||||
> - check that v(i+1) differs from its block at that height, and
|
||||
> - verify v(i+1) in one step from v(i) as v is a verification trace.
|
||||
|
||||
#### **[TMBC-LC-EVIDENCE-DATA.1]**
|
||||
|
||||
To prove the attack to p1, because of Point E1, it is sufficient to
|
||||
submit
|
||||
|
||||
- v(i).Height (rather than v(i)).
|
||||
- v(i+1)
|
||||
|
||||
This information is *evidence for height v(i).Height*.
|
||||
|
||||
## Block-based characterization of attacks
|
||||
|
||||
In this section we provide a different characterization of attacks. It
|
||||
is not defined on the nodes that are affected but purely on the
|
||||
content of the blocks. In that sense these definitions are less
|
||||
operational.
|
||||
|
||||
> They might be relevant for a closer analysis of fork scenarios on the
|
||||
> chain, which is out of the scope of this specification.
|
||||
|
||||
#### **[TMBC-SIGN-UNIQUE.1]**
|
||||
|
||||
Let *b* and *c* be light blocks, we define the predicate
|
||||
*sign-unique(b,c)* to evaluate to true iff the following implication
|
||||
evaluates to true:
|
||||
|
||||
- *b.Header.Height = c.Header.Height* and
|
||||
- *sequ-rooted(b)* and
|
||||
- *sequ-rooted(c)*
|
||||
|
||||
implies *b = c*.
|
||||
|
||||
#### **[TMBC-BLOCKS-MCFORK.1]**
|
||||
|
||||
If there exists two light blocks b and c, with *sign-unique(b,c) =
|
||||
false* then we have a *fork*.
|
||||
|
||||
> The difference of the above definition to
|
||||
> [[TMBC-MC-FORK.1]](#TMBC-MC-FORK1) is subtle. The latter requires a
|
||||
> full node being affected by a bad block while
|
||||
> [[TMBC-BLOCKS-MCFORK.1]](#TMBC-BLOCKS-MCFORK1) just requires that a
|
||||
> bad block exists, possibly in memory of an attacker.
|
||||
> The following captures a light client fork. There is no fork up to
|
||||
> the height of block b. However, c is of that height, is different,
|
||||
> and passes skipping verification. It is a stricter property than
|
||||
> [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1), as
|
||||
> [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1) requires that no correct full
|
||||
> node is affected.
|
||||
|
||||
#### **[TMBC-BLOCKS-LCFORK.1]**
|
||||
|
||||
Let *a*, *b*, *c*, be light blocks and *t* a time. We define
|
||||
*light-client-fork(a,b,c,t)* iff
|
||||
|
||||
- *sign-skip-match(a,b,c,t) = false* and
|
||||
- *sequ-rooted(b)* and
|
||||
- *b* is "unique", that is, for all *d*, *sequ-rooted(d)* and
|
||||
*d.Header.Height = b.Header.Height* implies *d = b*
|
||||
|
||||
> Finally, let us also define bogus blocks that have no support.
|
||||
> Observe that bogus is even defined if there is a fork.
|
||||
> Also, for the definition it would be sufficient to restrict *a* to
|
||||
> *a.height < b.height* (which is implied by the definitions which
|
||||
> unfold until *supports()*).
|
||||
|
||||
#### **[TMBC-BOGUS.1]**
|
||||
|
||||
Let *b* be a light block and *t* a time. We define *bogus(b,t)* iff
|
||||
|
||||
- *sequ-rooted(b) = false* and
|
||||
- for all *a*, *sequ-rooted(a)* implies *skip-trace(a,b,t) = false*
|
||||
|
||||
# Part II - Problem Statement
|
||||
|
||||
## Informal Problem statement
|
||||
|
||||
There is no sequential specification: the detector only makes sense
|
||||
in a distributed systems where some nodes misbehave.
|
||||
|
||||
We work under the assumption that full nodes and validators are
|
||||
responsible for detecting attacks on the main chain, and the evidence
|
||||
reactor takes care of broadcasting evidence to communicate
|
||||
misbehaving nodes via ABCI to the application, and halt the chain in
|
||||
case of a fork. The point of this specification is to shield a light
|
||||
clients against attacks that cannot be detected by full nodes, and
|
||||
are fully addressed at light clients (and consequently IBC relayers,
|
||||
which use the light client protocols to observe the state of a
|
||||
blockchain). In order to provide full nodes the incentive to follow
|
||||
the protocols when communicating with the light client, this
|
||||
specification also considers the generation of evidence that will
|
||||
also be processed by the Tendermint blockchain.
|
||||
|
||||
#### **[LCD-IP-MODEL.1]**
|
||||
|
||||
The detector is designed under the assumption that
|
||||
|
||||
- [[TMBC-FM-2THIRDS]][TMBC-FM-2THIRDS-link] may be violated
|
||||
- there is no fork on the main chain.
|
||||
|
||||
> As a result some faulty full nodes may launch an attack on a light
|
||||
> client.
|
||||
|
||||
The following requirements are operational in that they describe how
|
||||
things should be done, rather than what should be done. However, they
|
||||
do not constitute temporal logic verification conditions. For those,
|
||||
see [LCD-DIST-*] below.
|
||||
|
||||
The detector is called in the [supervisor][supervisor] as follows
|
||||
|
||||
```go
|
||||
Evidences := AttackDetector(root_of_trust, verifiedLS);`
|
||||
```
|
||||
|
||||
where
|
||||
|
||||
- `root-of-trust` is a light block that is trusted (that is,
|
||||
except upon initialization, the primary and the secondaries
|
||||
agreed on in the past), and
|
||||
- `verifiedLS` is a lightstore that contains a verification trace that
|
||||
starts from a lightblock that can be verified with the
|
||||
`root-of-trust` in one step and ends with a lightblock of the height
|
||||
requested by the user
|
||||
- `Evidences` is a list of evidences for misbehavior
|
||||
|
||||
#### **[LCD-IP-STATEMENT.1]**
|
||||
|
||||
Whenever AttackDetector is called, the detector should for each
|
||||
secondary cross check the largest header in verifiedLS with the
|
||||
corresponding header of the same height provided by the secondary. If
|
||||
there is a deviation, the detector should
|
||||
try to replay the verification trace `verifiedLS` with the
|
||||
secondary
|
||||
|
||||
- in case replaying leads to detection of a light client attack
|
||||
(one of the lightblocks differ from the one in verifiedLS with
|
||||
the same height), we should return evidence
|
||||
- if the secondary cannot provide a verification trace, we have no
|
||||
proof for an attack. Block *b* may be bogus. In this case the
|
||||
secondary is faulty and it should be replaced.
|
||||
|
||||
## Assumptions
|
||||
|
||||
It is not in the interest of faulty full nodes to talk to the
|
||||
detector as long as the detector is connected to at least one
|
||||
correct full node. This would only increase the likelihood of
|
||||
misbehavior being detected. Also we cannot punish them easily
|
||||
(cheaply). The absence of a response need not be the fault of the full
|
||||
node.
|
||||
|
||||
Correct full nodes have the incentive to respond, because the
|
||||
detector may help them to understand whether their header is a good
|
||||
one. We can thus base liveness arguments of the detector on
|
||||
the assumptions that correct full nodes reliably talk to the
|
||||
detector.
|
||||
|
||||
#### **[LCD-A-CorrFull.1]**
|
||||
|
||||
At all times there is at least one correct full
|
||||
node among the primary and the secondaries.
|
||||
|
||||
> For this version of the detection we take this assumption. It
|
||||
> allows us to establish the invariant that the lightblock
|
||||
> `root-of-trust` is always the one from the blockchain, and we can
|
||||
> use it as starting point for the evidence computation. Moreover, it
|
||||
> allows us to establish the invariant at the supervisor that any
|
||||
> lightblock in the (top-level) lightstore is from the blockchain.
|
||||
> In the future we might design a lightclient based on the assumption
|
||||
> that at least in regular intervals the lightclient is connected to a
|
||||
> correct full node. This will require the detector to reconsider
|
||||
> `root-of-trust`, and remove lightblocks from the top-level
|
||||
> lightstore.
|
||||
|
||||
#### **[LCD-A-RelComm.1]**
|
||||
|
||||
Communication between the detector and a correct full node is
|
||||
reliable and bounded in time. Reliable communication means that
|
||||
messages are not lost, not duplicated, and eventually delivered. There
|
||||
is a (known) end-to-end delay *Delta*, such that if a message is sent
|
||||
at time *t* then it is received and processed by time *t + Delta*.
|
||||
This implies that we need a timeout of at least *2 Delta* for remote
|
||||
procedure calls to ensure that the response of a correct peer arrives
|
||||
before the timeout expires.
|
||||
|
||||
## Definitions
|
||||
|
||||
### Evidence
|
||||
|
||||
Following the definition of
|
||||
[[TMBC-LC-ATTACK-EVIDENCE.1]](#TMBC-LC-ATTACK-EVIDENCE1), by evidence
|
||||
we refer to a variable of the following type
|
||||
|
||||
#### **[LC-DATA-EVIDENCE.1]**
|
||||
|
||||
```go
|
||||
type LightClientAttackEvidence struct {
|
||||
ConflictingBlock LightBlock
|
||||
CommonHeight int64
|
||||
}
|
||||
```
|
||||
|
||||
As the above data is computed for a specific peer, the following
|
||||
data structure wraps the evidence and adds the peerID.
|
||||
|
||||
#### **[LC-DATA-EVIDENCE-INT.1]**
|
||||
|
||||
```go
|
||||
type InternalEvidence struct {
|
||||
Evidence LightClientAttackEvidence
|
||||
Peer PeerID
|
||||
}
|
||||
```
|
||||
|
||||
#### **[LC-SUMBIT-EVIDENCE.1]**
|
||||
|
||||
```go
|
||||
func submitEvidence(Evidences []InternalEvidence)
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- for each `ev` in `Evidences`: submit `ev.Evidence` to `ev.Peer`
|
||||
|
||||
---
|
||||
|
||||
### LightStore
|
||||
|
||||
Lightblocks and LightStores are defined in the verification
|
||||
specification [[LCV-DATA-LIGHTBLOCK.1]][LCV-LB-link]
|
||||
and [[LCV-DATA-LIGHTSTORE.2]][LCV-LS-link]. See
|
||||
the [verification specification][verification] for details.
|
||||
|
||||
## Distributed Problem statement
|
||||
|
||||
> As the attack detector is there to reduce the impact of faulty
|
||||
> nodes, and faulty nodes imply that there is a distributed system,
|
||||
> there is no sequential specification to which this distributed
|
||||
> problem statement may refer to.
|
||||
|
||||
The detector gets as input a trusted lightblock called *root* and an
|
||||
auxiliary lightstore called *primary_trace* with lightblocks that have
|
||||
been verified before, and that were provided by the primary.
|
||||
|
||||
#### **[LCD-DIST-INV-ATTACK.1]**
|
||||
|
||||
If the detector returns evidence for height *h*
|
||||
[[TMBC-LC-EVIDENCE-DATA.1]](#TMBC-LC-EVIDENCE-DATA1), then there is an
|
||||
attack at height *h*. [[TMBC-LC-ATTACK.1]](#TMBC-LC-ATTACK1)
|
||||
|
||||
#### **[LCD-DIST-INV-STORE.1]**
|
||||
|
||||
If the detector does not return evidence, then *primary_trace*
|
||||
contains only blocks from the blockchain.
|
||||
|
||||
#### **[LCD-DIST-LIVE.1]**
|
||||
|
||||
The detector eventually terminates.
|
||||
|
||||
#### **[LCD-DIST-TERM-NORMAL.1]**
|
||||
|
||||
If
|
||||
|
||||
- the *primary_trace* contains only blocks from the blockchain, and
|
||||
- there is no attack, and
|
||||
- *Secondaries* is always non-empty, and
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the detector does not return evidence.
|
||||
|
||||
#### **[LCD-DIST-TERM-ATTACK.1]**
|
||||
|
||||
If
|
||||
|
||||
- there is an attack, and
|
||||
- a secondary reports a block that conflicts
|
||||
with one of the blocks in *primary_trace*, and
|
||||
- *Secondaries* is always non-empty, and
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the detector returns evidence.
|
||||
|
||||
> Observe that above we require that "a secondary reports a block that
|
||||
> conflicts". If there is an attack, but no secondary tries to launch
|
||||
> it against the detector (or the message from the secondary is lost
|
||||
> by the network), then there is nothing to detect for us.
|
||||
|
||||
#### **[LCD-DIST-SAFE-SECONDARY.1]**
|
||||
|
||||
No correct secondary is ever replaced.
|
||||
|
||||
#### **[LCD-DIST-SAFE-BOGUS.1]**
|
||||
|
||||
If
|
||||
|
||||
- a secondary reports a bogus lightblock,
|
||||
- the age of *root* is always less than the trusting period,
|
||||
|
||||
then the secondary is replaced before the detector terminates.
|
||||
|
||||
> The above property is quite operational (e.g., the usage of
|
||||
> "reports"), but it captures closely the requirement. As the
|
||||
> detector only makes sense in a distributed setting, and does not
|
||||
> have a sequential specification, a less "pure" specification are
|
||||
> acceptable.
|
||||
|
||||
# Part III - Protocol
|
||||
|
||||
## Functions and Data defined in other Specifications
|
||||
|
||||
### From the [supervisor][supervisor]
|
||||
|
||||
[[LC-FUNC-REPLACE-SECONDARY.1]][repl]
|
||||
|
||||
```go
|
||||
Replace_Secondary(addr Address, root-of-trust LightBlock)
|
||||
```
|
||||
|
||||
### From the [verifier][verification]
|
||||
|
||||
[[LCV-FUNC-MAIN.2]][vtt]
|
||||
|
||||
```go
|
||||
func VerifyToTarget(primary PeerID, root LightBlock,
|
||||
targetHeight Height) (LightStore, Result)
|
||||
```
|
||||
|
||||
Observe that `VerifyToTarget` does communication with the secondaries
|
||||
via the function [FetchLightBlock][fetch].
|
||||
|
||||
### Shared data of the light client
|
||||
|
||||
- a pool of full nodes *FullNodes* that have not been contacted before
|
||||
- peer set called *Secondaries*
|
||||
- primary
|
||||
|
||||
> Note that the lightStore is not needed to be shared.
|
||||
|
||||
## Outline of solution
|
||||
|
||||
The problem laid out is solved by calling the function `AttackDetector`
|
||||
with a lightstore that contains a light block that has just been
|
||||
verified by the verifier.
|
||||
|
||||
Then `AttackDetector` downloads headers from the secondaries. In case
|
||||
a conflicting header is downloaded from a secondary, it calls
|
||||
`CreateEvidenceForPeer` which computes evidence in the case that
|
||||
indeed an attack is confirmed. It could be that the secondary reports
|
||||
a bogus block, which means that there need not be an attack, and the
|
||||
secondary is replaced.
|
||||
|
||||
## Details of the functions
|
||||
|
||||
#### **[LCD-FUNC-DETECTOR.2]:**
|
||||
|
||||
```go
|
||||
func AttackDetector(root LightBlock, primary_trace []LightBlock)
|
||||
([]InternalEvidence) {
|
||||
|
||||
Evidences := new []InternalEvidence;
|
||||
|
||||
for each secondary in Secondaries {
|
||||
lb, result := FetchLightBlock(secondary,primary_trace.Latest().Header.Height);
|
||||
if result != ResultSuccess {
|
||||
Replace_Secondary(root);
|
||||
}
|
||||
else if lb.Header != primary_trace.Latest().Header {
|
||||
|
||||
// we replay the primary trace with the secondary, in
|
||||
// order to generate evidence that we can submit to the
|
||||
// secondary. We return the evidence + the trace the
|
||||
// secondary told us that spans the evidence at its local store
|
||||
|
||||
EvidenceForSecondary, newroot, secondary_trace, result :=
|
||||
CreateEvidenceForPeer(secondary,
|
||||
root,
|
||||
primary_trace);
|
||||
if result == FaultyPeer {
|
||||
Replace_Secondary(root);
|
||||
}
|
||||
else if result == FoundEvidence {
|
||||
// the conflict is not bogus
|
||||
Evidences.Add(EvidenceForSecondary);
|
||||
// we replay the secondary trace with the primary, ...
|
||||
EvidenceForPrimary, _, result :=
|
||||
CreateEvidenceForPeer(primary,
|
||||
newroot,
|
||||
secondary_trace);
|
||||
if result == FoundEvidence {
|
||||
Evidences.Add(EvidenceForPrimary);
|
||||
}
|
||||
// At this point we do not care about the other error
|
||||
// codes. We already have generated evidence for an
|
||||
// attack and need to stop the lightclient. It does not
|
||||
// help to call replace_primary. Also we will use the
|
||||
// same primary to check with other secondaries in
|
||||
// later iterations of the loop
|
||||
}
|
||||
// In the case where the secondary reports NoEvidence
|
||||
// after initially it reported a conflicting header.
|
||||
// secondary is faulty
|
||||
Replace_Secondary(root);
|
||||
}
|
||||
}
|
||||
return Evidences;
|
||||
}
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- root and primary trace are a verification trace
|
||||
- Expected postcondition
|
||||
- solves the problem statement (if attack found, then evidence is reported)
|
||||
- Error condition
|
||||
- `ErrorTrustExpired`: fails if root expires (outside trusting
|
||||
period) [[LCV-INV-TP.1]][LCV-INV-TP1-link]
|
||||
- `ErrorNoPeers`: if no peers are left to replace secondaries, and
|
||||
no evidence was found before that happened
|
||||
|
||||
---
|
||||
|
||||
```go
|
||||
func CreateEvidenceForPeer(peer PeerID, root LightBlock, trace LightStore)
|
||||
(Evidence, LightBlock, LightStore, result) {
|
||||
|
||||
common := root;
|
||||
|
||||
for i in 1 .. len(trace) {
|
||||
auxLS, result := VerifyToTarget(peer, common, trace[i].Header.Height)
|
||||
|
||||
if result != ResultSuccess {
|
||||
// something went wrong; peer did not provide a verifiable block
|
||||
return (nil, nil, nil, FaultyPeer)
|
||||
}
|
||||
else {
|
||||
if auxLS.LatestVerified().Header != trace[i].Header {
|
||||
// the header reported by the peer differs from the
|
||||
// reference header in trace but both could be
|
||||
// verified from common in one step.
|
||||
// we can create evidence for submission to the secondary
|
||||
ev := new InternalEvidence;
|
||||
ev.Evidence.ConflictingBlock := trace[i];
|
||||
ev.Evidence.CommonHeight := common.Height;
|
||||
ev.Peer := peer
|
||||
return (ev, common, auxLS, FoundEvidence)
|
||||
}
|
||||
else {
|
||||
// the peer agrees with the trace, we move common forward.
|
||||
// we could delete auxLS as it will be overwritten in
|
||||
// the next iteration
|
||||
common := trace[i]
|
||||
}
|
||||
}
|
||||
}
|
||||
return (nil, nil, nil, NoEvidence)
|
||||
}
|
||||
```
|
||||
|
||||
- Expected precondition
|
||||
- root and trace are a verification trace
|
||||
- Expected postcondition
|
||||
- finds evidence where trace and peer diverge
|
||||
- Error condition
|
||||
- `ErrorTrustExpired`: fails if root expires (outside trusting
|
||||
period) [[LCV-INV-TP.1]][LCV-INV-TP1-link]
|
||||
- If `VerifyToTarget` returns error but root is not expired then return
|
||||
`FaultyPeer`
|
||||
|
||||
---
|
||||
|
||||
## Correctness arguments
|
||||
|
||||
#### On the existence of evidence
|
||||
|
||||
**Proposition.** In the case of attack,
|
||||
evidence [[TMBC-LC-ATTACK-EVIDENCE.1]](#TMBC-LC-ATTACK-EVIDENCE1)
|
||||
exists.
|
||||
*Proof.* First observe that
|
||||
|
||||
- (A). (NOT E2(i)) implies E1(i+1)
|
||||
|
||||
Now by contradiction assume there is no evidence. Thus
|
||||
|
||||
- for all i, we have NOT E1(i) or NOT E2(i)
|
||||
- for i = 1 we have E1(1) and thus NOT E2(1)
|
||||
thus by induction on i, by (A) we have for all i that **E1(i)**
|
||||
- from attack we have E2(h-1), and as there is no evidence for
|
||||
i = h - 1 we get **NOT E1(h-1)**. Contradiction.
|
||||
QED.
|
||||
|
||||
#### Argument for [[LCD-DIST-INV-ATTACK.1]](#LCD-DIST-INV-ATTACK1)
|
||||
|
||||
Under the assumption that root and trace are a verification trace,
|
||||
when in `CreateEvidenceForPeer` the detector creates
|
||||
evidence, then the lightclient has seen two different headers (one via
|
||||
`trace` and one via `VerifyToTarget`) for the same height that can both
|
||||
be verified in one step.
|
||||
|
||||
#### Argument for [[LCD-DIST-INV-STORE.1]](#LCD-DIST-INV-STORE1)
|
||||
|
||||
We assume that there is at least one correct peer, and there is no
|
||||
fork. As a result, the correct peer has the correct sequence of
|
||||
blocks. Since the primary_trace is checked block-by-block also against
|
||||
each secondary, and at no point evidence was generated that means at
|
||||
no point there were conflicting blocks.
|
||||
|
||||
#### Argument for [[LCD-DIST-LIVE.1]](#LCD-DIST-LIVE1)
|
||||
|
||||
At the latest when [[LCV-INV-TP.1]][LCV-INV-TP1-link] is violated,
|
||||
`AttackDetector` terminates.
|
||||
|
||||
#### Argument for [[LCD-DIST-TERM-NORMAL.1]](#LCD-DIST-TERM-NORMAL1)
|
||||
|
||||
As there are finitely many peers, eventually the main loop
|
||||
terminates. As there is no attack no evidence can be generated.
|
||||
|
||||
#### Argument for [[LCD-DIST-TERM-ATTACK.1]](#LCD-DIST-TERM-ATTACK1)
|
||||
|
||||
Argument similar to [[LCD-DIST-TERM-NORMAL.1]](#LCD-DIST-TERM-NORMAL1)
|
||||
|
||||
#### Argument for [[LCD-DIST-SAFE-SECONDARY.1]](#LCD-DIST-SAFE-SECONDARY1)
|
||||
|
||||
Secondaries are only replaced if they time-out or if they report bogus
|
||||
blocks. The former is ruled out by the timing assumption, the latter
|
||||
by correct peers only reporting blocks from the chain.
|
||||
|
||||
#### Argument for [[LCD-DIST-SAFE-BOGUS.1]](#LCD-DIST-SAFE-BOGUS1)
|
||||
|
||||
Once a bogus block is recognized as such the secondary is removed.
|
||||
|
||||
# References
|
||||
|
||||
> links to other specifications/ADRs this document refers to
|
||||
|
||||
[[verification]] The specification of the light client verification.
|
||||
|
||||
[[supervisor]] The specification of the light client supervisor.
|
||||
|
||||
[verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md
|
||||
|
||||
[supervisor]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md
|
||||
|
||||
[block]: https://github.com/tendermint/spec/blob/d46cd7f573a2c6a2399fcab2cde981330aa63f37/spec/core/data_structures.md
|
||||
|
||||
[TMBC-FM-2THIRDS-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-fm-2thirds1
|
||||
|
||||
[TMBC-SOUND-DISTR-POSS-COMMIT-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-sound-distr-poss-commit1
|
||||
|
||||
[LCV-SEQ-SAFE-link]:https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-seq-safe1
|
||||
|
||||
[TMBC-VAL-CONTAINS-CORR-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-val-contains-corr1
|
||||
|
||||
[fetch]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-fetch1
|
||||
|
||||
[LCV-INV-TP1-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-inv-tp1
|
||||
|
||||
[LCV-LB-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightblock1
|
||||
|
||||
[LCV-LS-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-data-lightstore2
|
||||
|
||||
[LVC-HD-link]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#tmbc-header-fields2
|
||||
|
||||
[repl]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md#lc-func-replace-secondary1
|
||||
|
||||
[vtt]:
|
||||
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md#lcv-func-main2
|
||||
178
spec/light-client/detection/discussions.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# Results of Discussions and Decisions
|
||||
|
||||
- Generating a minimal proof of fork (as suggested in [Issue #5083](https://github.com/tendermint/tendermint/issues/5083)) is too costly at the light client
|
||||
- we do not know all lightblocks from the primary
|
||||
- therefore there are many scenarios. we might even need to ask
|
||||
the primary again for additional lightblocks to isolate the
|
||||
branch.
|
||||
|
||||
> For instance, the light node starts with block at height 1 and the
|
||||
> primary provides a block of height 10 that the light node can
|
||||
> verify immediately. In cross-checking, a secondary now provides a
|
||||
> conflicting header b10 of height 10 that needs another header b5
|
||||
> of height 5 to
|
||||
> verify. Now, in order for the light node to convince the primary:
|
||||
>
|
||||
> - The light node cannot just sent b5, as it is not clear whether
|
||||
> the fork happened before or after 5
|
||||
> - The light node cannot just send b10, as the primary would also
|
||||
> need b5 for verification
|
||||
> - In order to minimize the evidence, the light node may try to
|
||||
> figure out where the branch happens, e.g., by asking the primary
|
||||
> for height 5 (it might be that more queries are required, also
|
||||
> to the secondary. However, assuming that in this scenario the
|
||||
> primary is faulty it may not respond.
|
||||
|
||||
As the main goal is to catch misbehavior of the primary,
|
||||
evidence generation and punishment must not depend on their
|
||||
cooperation. So the moment we have proof of fork (even if it
|
||||
contains several light blocks) we should submit right away.
|
||||
|
||||
- decision: "full" proof of fork consists of two traces that originate in the
|
||||
same lightblock and lead to conflicting headers of the same height.
|
||||
|
||||
- For submission of proof of fork, we may do some optimizations, for
|
||||
instance, we might just submit a trace of lightblocks that verifies a block
|
||||
different from the one the full node knows (we do not send the trace
|
||||
the primary gave us back to the primary)
|
||||
|
||||
- The light client attack is via the primary. Thus we try to
|
||||
catch if the primary installs a bad light block
|
||||
- We do not check secondary against secondary
|
||||
- For each secondary, we check the primary against one secondary
|
||||
|
||||
- Observe that just two blocks for the same height are not
|
||||
sufficient proof of fork.
|
||||
One of the blocks may be bogus [TMBC-BOGUS.1] which does
|
||||
not constitute slashable behavior.
|
||||
Which leads to the question whether the light node should try to do
|
||||
fork detection on its initial block (from subjective
|
||||
initialization). This could be done by doing backwards verification
|
||||
(with the hashes) until a bifurcation block is found.
|
||||
While there are scenarios where a
|
||||
fork could be found, there is also the scenario where a faulty full
|
||||
node feeds the light node with bogus light blocks and forces the light
|
||||
node to check hashes until a bogus chain is out of the trusting period.
|
||||
As a result, the light client
|
||||
should not try to detect a fork for its initial header. **The initial
|
||||
header must be trusted as is.**
|
||||
|
||||
# Light Client Sequential Supervisor
|
||||
|
||||
**TODO:** decide where (into which specification) to put the
|
||||
following:
|
||||
|
||||
We describe the context on which the fork detector is called by giving
|
||||
a sequential version of the supervisor function.
|
||||
Roughly, it alternates two phases namely:
|
||||
|
||||
- Light Client Verification. As a result, a header of the required
|
||||
height has been downloaded from and verified with the primary.
|
||||
- Light Client Fork Detections. As a result the header has been
|
||||
cross-checked with the secondaries. In case there is a fork we
|
||||
submit "proof of fork" and exit.
|
||||
|
||||
#### **[LC-FUNC-SUPERVISOR.1]:**
|
||||
|
||||
```go
|
||||
func Sequential-Supervisor () (Error) {
|
||||
loop {
|
||||
// get the next height
|
||||
nextHeight := input();
|
||||
|
||||
// Verify
|
||||
result := NoResult;
|
||||
while result != ResultSuccess {
|
||||
lightStore,result := VerifyToTarget(primary, lightStore, nextHeight);
|
||||
if result == ResultFailure {
|
||||
// pick new primary (promote a secondary to primary)
|
||||
/// and delete all lightblocks above
|
||||
// LastTrusted (they have not been cross-checked)
|
||||
Replace_Primary();
|
||||
}
|
||||
}
|
||||
|
||||
// Cross-check
|
||||
PoFs := Forkdetector(lightStore, PoFs);
|
||||
if PoFs.Empty {
|
||||
// no fork detected with secondaries, we trust the new
|
||||
// lightblock
|
||||
LightStore.Update(testedLB, StateTrusted);
|
||||
}
|
||||
else {
|
||||
// there is a fork, we submit the proofs and exit
|
||||
for i, p range PoFs {
|
||||
SubmitProofOfFork(p);
|
||||
}
|
||||
return(ErrorFork);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**TODO:** finish conditions
|
||||
|
||||
- Implementation remark
|
||||
- Expected precondition
|
||||
- *lightStore* initialized with trusted header
|
||||
- *PoFs* empty
|
||||
- Expected postcondition
|
||||
- runs forever, or
|
||||
- is terminated by user and satisfies LightStore invariant, or **TODO**
|
||||
- has submitted proof of fork upon detecting a fork
|
||||
- Error condition
|
||||
- none
|
||||
|
||||
----
|
||||
|
||||
# Semantics of the LightStore
|
||||
|
||||
Currently, a lightblock in the lightstore can be in one of the
|
||||
following states:
|
||||
|
||||
- StateUnverified
|
||||
- StateVerified
|
||||
- StateFailed
|
||||
- StateTrusted
|
||||
|
||||
The intuition is that `StateVerified` captures that the lightblock has
|
||||
been verified with the primary, and `StateTrusted` is the state after
|
||||
successful cross-checking with the secondaries.
|
||||
|
||||
Assuming there is **always one correct node among primary and
|
||||
secondaries**, and there is no fork on the blockchain, lightblocks that
|
||||
are in `StateTrusted` can be used by the user with the guarantee of
|
||||
"finality". If a block in `StateVerified` is used, it might be that
|
||||
detection later finds a fork, and a roll-back might be needed.
|
||||
|
||||
**Remark:** The assumption of one correct node, does not render
|
||||
verification useless. It is true that if the primary and the
|
||||
secondaries return the same block we may trust it. However, if there
|
||||
is a node that provides a different block, the light node still needs
|
||||
verification to understand whether there is a fork, or whether the
|
||||
different block is just bogus (without any support of some previous
|
||||
validator set).
|
||||
|
||||
**Remark:** A light node may choose the full nodes it communicates
|
||||
with (the light node and the full node might even belong to the same
|
||||
stakeholder) so the assumption might be justified in some cases.
|
||||
|
||||
In the future, we will do the following changes
|
||||
|
||||
- we assume that only from time to time, the light node is
|
||||
connected to a correct full node
|
||||
- this means for some limited time, the light node might have no
|
||||
means to defend against light client attacks
|
||||
- as a result we do not have finality
|
||||
- once the light node reconnects with a correct full node, it
|
||||
should detect the light client attack and submit evidence.
|
||||
|
||||
Under these assumptions, `StateTrusted` loses its meaning. As a
|
||||
result, it should be removed from the API. We suggest that we replace
|
||||
it with a flag "trusted" that can be used
|
||||
|
||||
- internally for efficiency reasons (to maintain
|
||||
[LCD-INV-TRUSTED-AGREED.1] until a fork is detected)
|
||||
- by light client based on the "one correct full node" assumption
|
||||
|
||||
----
|
||||
289
spec/light-client/detection/draft-functions.md
Normal file
@@ -0,0 +1,289 @@
|
||||
# Draft of Functions for Fork detection and Proof of Fork Submisstion
|
||||
|
||||
This document collects drafts of function for generating and
|
||||
submitting proof of fork in the IBC context
|
||||
|
||||
- [IBC](#on---chain-ibc-component)
|
||||
|
||||
- [Relayer](#relayer)
|
||||
|
||||
## On-chain IBC Component
|
||||
|
||||
> The following is a suggestions to change the function defined in ICS 007
|
||||
|
||||
#### [TAG-IBC-MISBEHAVIOR.1]
|
||||
|
||||
```go
|
||||
func checkMisbehaviourAndUpdateState(cs: ClientState, PoF: LightNodeProofOfFork)
|
||||
```
|
||||
|
||||
**TODO:** finish conditions
|
||||
|
||||
- Implementation remark
|
||||
- Expected precondition
|
||||
- PoF.TrustedBlock.Header is equal to lightBlock on store with
|
||||
same height
|
||||
- both traces end with header of same height
|
||||
- headers are different
|
||||
- both traces are supported by PoF.TrustedBlock (`supports`
|
||||
defined in [TMBC-FUNC]), that is, for `t = currentTimestamp()` (see
|
||||
ICS 024)
|
||||
- supports(PoF.TrustedBlock, PoF.PrimaryTrace[1], t)
|
||||
- supports(PoF.PrimaryTrace[i], PoF.PrimaryTrace[i+1], t) for
|
||||
*0 < i < length(PoF.PrimaryTrace)*
|
||||
- supports(PoF.TrustedBlock, PoF.SecondaryTrace[1], t)
|
||||
- supports(PoF.SecondaryTrace[i], PoF.SecondaryTrace[i+1], t) for
|
||||
*0 < i < length(PoF.SecondaryTrace)*
|
||||
- Expected postcondition
|
||||
- set cs.FrozenHeight to min(cs.FrozenHeight, PoF.TrustedBlock.Header.Height)
|
||||
- Error condition
|
||||
- none
|
||||
|
||||
----
|
||||
|
||||
> The following is a suggestions to add functionality to ICS 002 and 007.
|
||||
> I suppose the above is the most efficient way to get the required
|
||||
> information. Another option is to subscribe to "header install"
|
||||
> events via CosmosSDK
|
||||
|
||||
#### [TAG-IBC-HEIGHTS.1]
|
||||
|
||||
```go
|
||||
func QueryHeightsRange(id, from, to) ([]Height)
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns all heights *h*, with *from <= h <= to* for which the
|
||||
IBC component has a consensus state.
|
||||
|
||||
----
|
||||
|
||||
> This function can be used if the relayer has no information about
|
||||
> the IBC component. This allows late-joining relayers to also
|
||||
> participate in fork dection and the generation in proof of
|
||||
> fork. Alternatively, we may also postulate that relayers are not
|
||||
> responsible to detect forks for heights before they started (and
|
||||
> subscribed to the transactions reporting fresh headers being
|
||||
> installed at the IBC component).
|
||||
|
||||
## Relayer
|
||||
|
||||
### Auxiliary Functions to be implemented in the Light Client
|
||||
|
||||
#### [LCV-LS-FUNC-GET-PREV.1]
|
||||
|
||||
```go
|
||||
func (ls LightStore) GetPreviousVerified(height Height) (LightBlock, bool)
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns a verified LightBlock, whose height is maximal among all
|
||||
verified lightblocks with height smaller than `height`
|
||||
|
||||
----
|
||||
|
||||
### Relayer Submitting Proof of Fork to the IBC Component
|
||||
|
||||
There are two ways the relayer can detect a fork
|
||||
|
||||
- by the fork detector of one of its lightclients
|
||||
- be checking the consensus state of the IBC component
|
||||
|
||||
The following function ignores how the proof of fork was generated.
|
||||
It takes a proof of fork as input and computes a proof of fork that
|
||||
will be accepted by the IBC component.
|
||||
The problem addressed here is that both, the relayer's light client
|
||||
and the IBC component have incomplete light stores, that might
|
||||
not have all light blocks in common.
|
||||
Hence the relayer has to figure out what the IBC component knows
|
||||
(intuitively, a meeting point between the two lightstores
|
||||
computed in `commonRoot`) and compute a proof of fork
|
||||
(`extendPoF`) that the IBC component will accept based on its
|
||||
knowledge.
|
||||
|
||||
The auxiliary functions `commonRoot` and `extendPoF` are
|
||||
defined below.
|
||||
|
||||
#### [TAG-SUBMIT-POF-IBC.1]
|
||||
|
||||
```go
|
||||
func SubmitIBCProofOfFork(
|
||||
lightStore LightStore,
|
||||
PoF: LightNodeProofOfFork,
|
||||
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)
|
||||
return Success
|
||||
// note sure about the id parameter
|
||||
}
|
||||
else {
|
||||
// the ibc component does not have the TrustedBlock and might
|
||||
// even be on yet a different branch. We have to compute a PoF
|
||||
// that the ibc component can verifiy based on its current
|
||||
// knowledge
|
||||
|
||||
ibcLightBlock, lblock, _, result := commonRoot(lightStore, ibc, PoF.TrustedBlock)
|
||||
|
||||
if result = Success {
|
||||
newPoF = extendPoF(ibcLightBlock, lblock, lightStore, PoF)
|
||||
ibc.submitMisbehaviourToClient(ibc.id, newPoF)
|
||||
return Success
|
||||
}
|
||||
else{
|
||||
return CouldNotGeneratePoF
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**TODO:** finish conditions
|
||||
|
||||
- Implementation remark
|
||||
- Expected precondition
|
||||
- Expected postcondition
|
||||
- Error condition
|
||||
- none
|
||||
|
||||
----
|
||||
|
||||
### Auxiliary Functions at the Relayer
|
||||
|
||||
> If the relayer detects a fork, it has to compute a proof of fork that
|
||||
> will convince the IBC component. That is it has to compare the
|
||||
> relayer's local lightstore against the lightstore of the IBC
|
||||
> component, and find common ancestor lightblocks.
|
||||
|
||||
#### [TAG-COMMON-ROOT.1]
|
||||
|
||||
```go
|
||||
func commonRoot(lightStore LightStore, ibc IBCComponent, lblock
|
||||
LightBlock) (LightBlock, LightBlock, LightStore, Result) {
|
||||
|
||||
auxLS.Init
|
||||
|
||||
// first we ask for the heights the ibc component is aware of
|
||||
ibcHeights = ibc.QueryHeightsRange(
|
||||
ibc.id,
|
||||
lightStore.LowestVerified().Height,
|
||||
lblock.Height - 1);
|
||||
// this function does not exist yet. Alternatively, we may
|
||||
// request all transactions that installed headers via CosmosSDK
|
||||
|
||||
|
||||
for {
|
||||
h, result = max(ibcHeights)
|
||||
if result = Empty {
|
||||
return (_, _, _, NoRoot)
|
||||
}
|
||||
ibcLightBlock = ibc.queryChainConsensusState(h)
|
||||
auxLS.Update(ibcLightBlock, StateVerified);
|
||||
connector, result := Connector(lightStore, ibcLightBlock, lblock.Header.Height)
|
||||
if result = success {
|
||||
return (ibcLightBlock, connector, auxLS, Success)
|
||||
}
|
||||
else{
|
||||
ibcHeights.remove(h)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns
|
||||
- a lightBlock b1 from the IBC component, and
|
||||
- a lightBlock b2
|
||||
from the local lightStore with height less than
|
||||
lblock.Header.Hight, s.t. b1 supports b2, and
|
||||
- a lightstore with the blocks downloaded from
|
||||
the ibc component
|
||||
|
||||
----
|
||||
|
||||
#### [TAG-LS-FUNC-CONNECT.1]
|
||||
|
||||
```go
|
||||
func Connector (lightStore LightStore, lb LightBlock, h Height) (LightBlock, bool)
|
||||
```
|
||||
|
||||
- Expected postcondition
|
||||
- returns a verified LightBlock from lightStore with height less
|
||||
than *h* that can be
|
||||
verified by lb in one step.
|
||||
|
||||
**TODO:** for the above to work we need an invariant that all verified
|
||||
lightblocks form a chain of trust. Otherwise, we need a lightblock
|
||||
that has a chain of trust to height.
|
||||
|
||||
> Once the common root is found, a proof of fork that will be accepted
|
||||
> by the IBC component needs to be generated. This is done in the
|
||||
> following function.
|
||||
|
||||
#### [TAG-EXTEND-POF.1]
|
||||
|
||||
```go
|
||||
func extendPoF (root LightBlock,
|
||||
connector LightBlock,
|
||||
lightStore LightStore,
|
||||
Pof LightNodeProofofFork) (LightNodeProofofFork}
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- PoF is not sufficient to convince an IBC component, so we extend
|
||||
the proof of fork farther in the past
|
||||
- Expected postcondition
|
||||
- returns a newPOF:
|
||||
- newPoF.TrustedBlock = root
|
||||
- let prefix =
|
||||
connector +
|
||||
lightStore.Subtrace(connector.Header.Height, PoF.TrustedBlock.Header.Height-1) +
|
||||
PoF.TrustedBlock
|
||||
- newPoF.PrimaryTrace = prefix + PoF.PrimaryTrace
|
||||
- newPoF.SecondaryTrace = prefix + PoF.SecondaryTrace
|
||||
|
||||
### Detection a fork at the IBC component
|
||||
|
||||
The following functions is assumed to be called regularly to check
|
||||
that latest consensus state of the IBC component. Alternatively, this
|
||||
logic can be executed whenever the relayer is informed (via an event)
|
||||
that a new header has been installed.
|
||||
|
||||
#### [TAG-HANDLER-DETECT-FORK.1]
|
||||
|
||||
```go
|
||||
func DetectIBCFork(ibc IBCComponent, lightStore LightStore) (LightNodeProofOfFork, Error) {
|
||||
cs = ibc.queryClientState(ibc);
|
||||
lb, found := lightStore.Get(cs.Header.Height)
|
||||
if !found {
|
||||
**TODO:** need verify to target
|
||||
lb, result = LightClient.Main(primary, lightStore, cs.Header.Height)
|
||||
// [LCV-FUNC-IBCMAIN.1]
|
||||
**TODO** decide what to do following the outcome of Issue #499
|
||||
|
||||
// I guess here we have to get into the light client
|
||||
|
||||
}
|
||||
if cs != lb {
|
||||
// IBC component disagrees with my primary.
|
||||
// I fetch the
|
||||
ibcLightBlock, lblock, ibcStore, result := commonRoot(lightStore, ibc, lb)
|
||||
pof = new LightNodeProofOfFork;
|
||||
pof.TrustedBlock := ibcLightBlock
|
||||
pof.PrimaryTrace := ibcStore + cs
|
||||
pof.SecondaryTrace := lightStore.Subtrace(lblock.Header.Height,
|
||||
lb.Header.Height);
|
||||
return(pof, Fork)
|
||||
}
|
||||
return(nil , NoFork)
|
||||
}
|
||||
```
|
||||
|
||||
**TODO:** finish conditions
|
||||
|
||||
- Implementation remark
|
||||
- we ask the handler for the lastest check. Cross-check with the
|
||||
chain. In case they deviate we generate PoF.
|
||||
- we assume IBC component is correct. It has verified the
|
||||
consensus state
|
||||
- Expected precondition
|
||||
- Expected postcondition
|
||||
345
spec/light-client/detection/req-ibc-detection.md
Normal file
@@ -0,0 +1,345 @@
|
||||
# Requirements for Fork Detection in the IBC Context
|
||||
|
||||
## What you need to know about IBC
|
||||
|
||||
In the following, I distilled what I considered relevant from
|
||||
|
||||
<https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics>
|
||||
|
||||
### Components and their interface
|
||||
|
||||
#### Tendermint Blockchains
|
||||
|
||||
> I assume you know what that is.
|
||||
|
||||
#### An IBC/Tendermint correspondence
|
||||
|
||||
| IBC Term | Tendermint-RS Spec Term | Comment |
|
||||
|----------|-------------------------| --------|
|
||||
| `CommitmentRoot` | AppState | app hash |
|
||||
| `ConsensusState` | Lightblock | not all fields are there. NextValidator is definitly needed |
|
||||
| `ClientState` | latest light block + configuration parameters (e.g., trusting period + `frozenHeight` | NextValidators missing; what is `proofSpecs`?|
|
||||
| `frozenHeight` | height of fork | set when a fork is detected |
|
||||
| "would-have-been-fooled" | light node fork detection | light node may submit proof of fork to IBC component to halt it |
|
||||
| `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 |
|
||||
|
||||
#### Some IBC links
|
||||
|
||||
- [QueryConsensusState](https://github.com/cosmos/cosmos-sdk/blob/2651427ab4c6ea9f81d26afa0211757fc76cf747/x/ibc/02-client/client/utils/utils.go#L68)
|
||||
|
||||
#### Required Changes in ICS 007
|
||||
|
||||
- `assert(height > 0)` in definition of `initialise` doesn't match
|
||||
definition of `Height` as *(epoch,height)* pair.
|
||||
|
||||
- `initialise` 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
|
||||
you accept more evidence.
|
||||
|
||||
- `checkValidityAndUpdateState`
|
||||
- `verify`: it needs to be clarified that checkValidityAndUpdateState
|
||||
does not perform "bisection" (as currently hinted in the text) but
|
||||
performs a single step of "skipping verification", called,
|
||||
`ValidAndVerified`
|
||||
- `assert (header.height > clientState.latestHeight)`: no old
|
||||
headers can be installed. This might be OK, but we need to check
|
||||
interplay with misbehavior
|
||||
- clienstState needs to be updated according to complete data
|
||||
structure
|
||||
|
||||
- `checkMisbehaviourAndUpdateState`: 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
|
||||
retrieval of past consensus states by height (as opposed to just the
|
||||
current consensus state) is convenient but not required." For
|
||||
Tendermint fork detection, this seems to be a necessity.
|
||||
|
||||
- `Header` should become a lightblock
|
||||
|
||||
- `Evidence` should become `LightNodeProofOfFork` [LCV-DATA-POF.1]
|
||||
|
||||
- `upgradeClientState` what is the semantics (in particular what is
|
||||
`height` doing?).
|
||||
|
||||
- `checkMisbehaviourAndUpdateState(cs: ClientState, PoF:
|
||||
LightNodeProofOfFork)` needs to be adapted
|
||||
|
||||
#### Handler
|
||||
|
||||
A blockchain runs a **handler** that passively collects information about
|
||||
other blockchains. It can be thought of a state machine that takes
|
||||
input events.
|
||||
|
||||
- the state includes a lightstore (I guess called `ConsensusState`
|
||||
in IBC)
|
||||
|
||||
- The following function is used to pass a header to a handler
|
||||
|
||||
```go
|
||||
type checkValidityAndUpdateState = (Header) => Void
|
||||
```
|
||||
|
||||
For Tendermint, it will perform
|
||||
`ValidandVerified`, that is, it does the trusting period check and the
|
||||
+1/3 check (+2/3 for sequential headers).
|
||||
If it verifies a header, it adds it to its lightstore,
|
||||
if it does not pass verification it drops it.
|
||||
Right now it only accepts a header more recent then the latest
|
||||
header,
|
||||
and drops older
|
||||
ones or ones that could not be verified.
|
||||
|
||||
> The above paragraph captures what I believe what is the current
|
||||
logic of `checkValidityAndUpdateState`. It may be subject to
|
||||
change. E.g., maintain a lightstore with state (unverified, verified)
|
||||
|
||||
- The following function is used to pass "evidence" (this we
|
||||
will need to make precise eventually) to a handler
|
||||
|
||||
```go
|
||||
type checkMisbehaviourAndUpdateState = (bytes) => Void
|
||||
```
|
||||
|
||||
We have to design this, and the data that the handler can use to
|
||||
check that there was some misbehavior (fork) in order react on
|
||||
it, e.g., flagging a situation and
|
||||
stop the protocol.
|
||||
|
||||
- The following function is used to query the light store (`ConsensusState`)
|
||||
|
||||
```go
|
||||
type queryChainConsensusState = (height: uint64) => ConsensusState
|
||||
```
|
||||
|
||||
#### Relayer
|
||||
|
||||
- The active components are called **relayer**.
|
||||
|
||||
- a relayer contains light clients to two (or more?) blockchains
|
||||
|
||||
- the relayer send headers and data to the handler to invoke
|
||||
`checkValidityAndUpdateState` and
|
||||
`checkMisbehaviourAndUpdateState`. It may also query
|
||||
`queryChainConsensusState`.
|
||||
|
||||
- multiple relayers may talk to one handler. Some relayers might be
|
||||
faulty. We assume existence of at least single correct relayer.
|
||||
|
||||
## Informal Problem Statement: Fork detection in IBC
|
||||
|
||||
### Relayer requirement: Evidence for Handler
|
||||
|
||||
- The relayer should provide the handler with
|
||||
"evidence" that there was a fork.
|
||||
|
||||
- The relayer can read the handler's consensus state. Thus the relayer can
|
||||
feed the handler precisely the information the handler needs to detect a
|
||||
fork.
|
||||
What is this
|
||||
information needs to be specified.
|
||||
|
||||
- The information depends on the verification the handler does. It
|
||||
might be necessary to provide a bisection proof (list of
|
||||
lightblocks) so that the handler can verify based on its local
|
||||
lightstore a header *h* that is conflicting with a header *h'* in the
|
||||
local lightstore, that is, *h != h'* and *h.Height = h'.Height*
|
||||
|
||||
### Relayer requirement: Fork detection
|
||||
|
||||
Let's assume there is a fork at chain A. There are two ways the
|
||||
relayer can figure that out:
|
||||
|
||||
1. as the relayer contains a light client for A, it also includes a fork
|
||||
detector that can detect a fork.
|
||||
|
||||
2. the relayer may also detect a fork by observing that the
|
||||
handler for chain A (on chain B)
|
||||
is on a different branch than the relayer
|
||||
|
||||
- in both detection scenarios, the relayer should submit evidence to
|
||||
full nodes of chain A where there is a fork. As we assume a fullnode
|
||||
has a complete list of blocks, it is sufficient to send "Bucky's
|
||||
evidence" (<https://github.com/tendermint/tendermint/issues/5083>),
|
||||
that is,
|
||||
- two lightblocks from different branches +
|
||||
- a lightblock (perhaps just a height) from which both blocks
|
||||
can be verified.
|
||||
|
||||
- in the scenario 2., the relayer must feed the A-handler (on chain B)
|
||||
a proof of a fork on A so that chain B can react accordingly
|
||||
|
||||
### Handler requirement
|
||||
|
||||
- there are potentially many relayers, some correct some faulty
|
||||
|
||||
- a handler cannot trust the information provided by the relayer,
|
||||
but must verify
|
||||
(Доверя́й, но проверя́й)
|
||||
|
||||
- in case of a fork, we accept that the handler temporarily stores
|
||||
headers (tagged as verified).
|
||||
|
||||
- eventually, a handler should be informed
|
||||
(`checkMisbehaviourAndUpdateState`)
|
||||
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?)
|
||||
|
||||
### Challenges in the handler requirement
|
||||
|
||||
- handlers and relayers work on different lightstores. In principle
|
||||
the lightstore need not intersect in any heights a priori
|
||||
|
||||
- if a relayer sees a header *h* it doesn't know at a handler (`queryChainConsensusState`), the
|
||||
relayer needs to
|
||||
verify that header. If it cannot do it locally based on downloaded
|
||||
and verified (trusted?) light blocks, it might need to use
|
||||
`VerifyToTarget` (bisection). To call `VerifyToTarget` we might keep
|
||||
*h* in the lightstore. If verification fails, we need to download the
|
||||
"alternative" header of height *h.Height* to generate evidence for
|
||||
the handler.
|
||||
|
||||
- we have to specify what precisely `queryChainConsensusState`
|
||||
returns. It cannot be the complete lightstore. Is the last header enough?
|
||||
|
||||
- we would like to assume that every now and then (smaller than the
|
||||
trusting period) a correct relayer checks whether the handler is on a
|
||||
different branch than the relayer.
|
||||
And we would like that this is enough to achieve
|
||||
the Handler requirement.
|
||||
|
||||
- here the correctness argument would be easy if a correct relayer is
|
||||
based on a light client with a *trusted* state, that is, a light
|
||||
client who never changes its opinion about trusted. Then if such a
|
||||
correct relayer checks-in with a handler, it will detect a fork, and
|
||||
act in time.
|
||||
|
||||
- if the light client does not provide this interface, in the case of
|
||||
a fork, we need some assumption about a correct relayer being on a
|
||||
different branch than the handler, and we need such a relayer to
|
||||
check-in not too late. Also
|
||||
what happens if the relayer's light client is forced to roll-back
|
||||
its lightstore?
|
||||
Does it have to re-check all handlers?
|
||||
|
||||
## On the interconnectedness of things
|
||||
|
||||
In the broader discussion of so-called "fork accountability" there are
|
||||
several subproblems
|
||||
|
||||
- Fork detection
|
||||
|
||||
- Evidence creation and submission
|
||||
|
||||
- Isolating misbehaving nodes (and report them for punishment over abci)
|
||||
|
||||
### Fork detection
|
||||
|
||||
The preliminary specification ./detection.md formalizes the notion of
|
||||
a fork. Roughly, a fork exists if there are two conflicting headers
|
||||
for the same height, where both are supported by bonded full nodes
|
||||
(that have been validators in the near past, that is, within the
|
||||
trusting period). We distinguish between *fork on the chain* where two
|
||||
conflicting blocks are signed by +2/3 of the validators of that
|
||||
height, and a *light client fork* where one of the conflicting headers
|
||||
is not signed by +2/3 of the current height, but by +1/3 of the
|
||||
validators of some smaller height.
|
||||
|
||||
In principle everyone can detect a fork
|
||||
|
||||
- ./detection talks about the Tendermint light client with a focus on
|
||||
light nodes. A relayer runs such light clients and may detect
|
||||
forks in this way
|
||||
|
||||
- in IBC, a relayer can see that a handler is on a conflicting branch
|
||||
- the relayer should feed the handler the necessary information so
|
||||
that it can halt
|
||||
- the relayer should report the fork to a full node
|
||||
|
||||
### Evidence creation and submission
|
||||
|
||||
- the information sent from the relayer to the handler could be called
|
||||
evidence, but this is perhaps a bad idea because the information sent to a
|
||||
full node can also be called evidence. But this evidence might still
|
||||
not be enough as the full node might need to run the "fork
|
||||
accountability" protocol to generate evidence in the form of
|
||||
consensus messages. So perhaps we should
|
||||
introduce different terms for:
|
||||
|
||||
- proof of fork for the handler (basically consisting of lightblocks)
|
||||
- proof of fork for a full node (basically consisting of (fewer) lightblocks)
|
||||
- proof of misbehavior (consensus messages)
|
||||
|
||||
### Isolating misbehaving nodes
|
||||
|
||||
- this is the job of a full node.
|
||||
|
||||
- might be subjective in the future: the protocol depends on what the
|
||||
full node believes is the "correct" chain. Right now we postulate
|
||||
that every full node is on the correct chain, that is, there is no
|
||||
fork on the chain.
|
||||
|
||||
- The full node figures out which nodes are
|
||||
- lunatic
|
||||
- double signing
|
||||
- amnesic; **using the challenge response protocol**
|
||||
|
||||
- We do not punish "phantom" validators
|
||||
- currently we understand a phantom validator as a node that
|
||||
- signs a block for a height in which it is not in the
|
||||
validator set
|
||||
- the node is not part of the +1/3 of previous validators that
|
||||
are used to support the header. Whether we call a validator
|
||||
phantom might be subjective and depend on the header we
|
||||
check against. Their formalization actually seems not so
|
||||
clear.
|
||||
- they can only do something if there are +1/3 faulty validators
|
||||
that are either lunatic, double signing, or amnesic.
|
||||
- abci requires that we only report bonded validators. So if a
|
||||
node is a "phantom", we would need the check whether the node is
|
||||
bonded, which currently is expensive, as it requires checking
|
||||
blocks from the last three weeks.
|
||||
- in the future, with state sync, a correct node might be
|
||||
convinced by faulty nodes that it is in the validator set. Then
|
||||
it might appear to be "phantom" although it behaves correctly
|
||||
|
||||
## Next steps
|
||||
|
||||
> The following points are subject to my limited knowledge of the
|
||||
> state of the work on IBC. Some/most of it might already exist and we
|
||||
> will just need to bring everything together.
|
||||
|
||||
- "proof of fork for a full node" defines a clean interface between
|
||||
fork detection and misbehavior isolation. So it should be produced
|
||||
by protocols (light client, the relayer). So we should fix that
|
||||
first.
|
||||
|
||||
- Given the problems of not having a light client architecture spec,
|
||||
for the relayer we should start with this. E.g.
|
||||
|
||||
- the relayer runs light clients for two chains
|
||||
- the relayer regularly queries consensus state of a handler
|
||||
- the relayer needs to check the consensus state
|
||||
- this involves local checks
|
||||
- this involves calling the light client
|
||||
- the relayer uses the light client to do IBC business (channels,
|
||||
packets, connections, etc.)
|
||||
- the relayer submits proof of fork to handlers and full nodes
|
||||
|
||||
> the list is definitely not complete. I think part of this
|
||||
> (perhaps all) is
|
||||
> covered by what Anca presented recently.
|
||||
|
||||
We will need to define what we expect from these components
|
||||
|
||||
- for the parts where the relayer talks to the handler, we need to fix
|
||||
the interface, and what the handler does
|
||||
|
||||
- we write specs for these components.
|
||||
BIN
spec/light-client/experiments.png
Normal file
|
After Width: | Height: | Size: 82 KiB |
637
spec/light-client/supervisor/supervisor_001_draft.md
Normal file
@@ -0,0 +1,637 @@
|
||||
# Draft of Light Client Supervisor for discussion
|
||||
|
||||
## TODOs
|
||||
|
||||
This specification in done in parallel with updates on the
|
||||
verification specification. So some hyperlinks have to be placed to
|
||||
the correct files eventually.
|
||||
|
||||
# Light Client Sequential Supervisor
|
||||
|
||||
The light client implements a read operation of a
|
||||
[header](TMBC-HEADER-link) from the [blockchain](TMBC-SEQ-link), by
|
||||
communicating with full nodes, a so-called primary and several
|
||||
so-called witnesses. As some full nodes may be faulty, this
|
||||
functionality must be implemented in a fault-tolerant way.
|
||||
|
||||
In the Tendermint blockchain, the validator set may change with every
|
||||
new block. The staking and unbonding mechanism induces a [security
|
||||
model](TMBC-FM-2THIRDS-link): starting at time *Time* of the
|
||||
[header](TMBC-HEADER-link),
|
||||
more than two-thirds of the next validators of a new block are correct
|
||||
for the duration of *TrustedPeriod*.
|
||||
|
||||
[Light Client Verification](https://informal.systems) implements the fault-tolerant read
|
||||
operation designed for this security model. That is, it is safe if the
|
||||
model assumptions are satisfied and makes progress if it communicates
|
||||
to a correct primary.
|
||||
|
||||
However, if the [security model](TMBC-FM-2THIRDS-link) is violated,
|
||||
faulty peers (that have been validators at some point in the past) may
|
||||
launch attacks on the Tendermint network, and on the light
|
||||
client. These attacks as well as an axiomatization of blocks in
|
||||
general are defined in [a document that contains the definitions that
|
||||
are currently in detection.md](https://informal.systems).
|
||||
|
||||
If there is a light client attack (but no
|
||||
successful attack on the network), the safety of the verification step
|
||||
may be violated (as we operate outside its basic assumption).
|
||||
The light client also
|
||||
contains a defense mechanism against light clients attacks, called detection.
|
||||
|
||||
[Light Client Detection](https://informal.systems) implements a cross check of the result
|
||||
of the verification step. If there is a light client attack, and the
|
||||
light client is connected to a correct peer, the light client as a
|
||||
whole is safe, that is, it will not operate on invalid
|
||||
blocks. However, in this case it cannot successfully read, as
|
||||
inconsistent blocks are in the system. However, in this case the
|
||||
detection performs a distributed computation that results in so-called
|
||||
evidence. Evidence can be used to prove
|
||||
to a correct full node that there has been a
|
||||
light client attack.
|
||||
|
||||
[Light Client Evidence Accountability](https://informal.systems) is a protocol run on a
|
||||
full node to check whether submitted evidence indeed proves the
|
||||
existence of a light client attack. Further, from the evidence and its
|
||||
own knowledge about the blockchain, the full node computes a set of
|
||||
bonded full nodes (that at some point had more than one third of the
|
||||
voting power) that participated in the attack that will be reported
|
||||
via ABCI to the application.
|
||||
|
||||
In this document we specify
|
||||
|
||||
- Initialization of the Light Client
|
||||
- The interaction of [verification](https://informal.systems) and [detection](https://informal.systems)
|
||||
|
||||
The details of these two protocols are captured in their own
|
||||
documents, as is the [accountability](https://informal.systems) protocol.
|
||||
|
||||
> Another related line is IBC attack detection and submission at the
|
||||
> relayer, as well as attack verification at the IBC handler. This
|
||||
> will call for yet another spec.
|
||||
|
||||
# Status
|
||||
|
||||
This document is work in progress. In order to develop the
|
||||
specification step-by-step,
|
||||
it assumes certain details of [verification](https://informal.systems) and
|
||||
[detection](https://informal.systems) that are not specified in the respective current
|
||||
versions yet. This inconsistencies will be addresses over several
|
||||
upcoming PRs.
|
||||
|
||||
# Part I - Tendermint Blockchain
|
||||
|
||||
See [verification spec](addLinksWhenDone)
|
||||
|
||||
# Part II - Sequential Problem Definition
|
||||
|
||||
#### **[LC-SEQ-INIT-LIVE.1]**
|
||||
|
||||
Upon initialization, the light client gets as input a header of the
|
||||
blockchain, or the genesis file of the blockchain, and eventually
|
||||
stores a header of the blockchain.
|
||||
|
||||
#### **[LC-SEQ-LIVE.1]**
|
||||
|
||||
The light client gets a sequence of heights as inputs. For each input
|
||||
height *targetHeight*, it eventually stores the header of height
|
||||
*targetHeight*.
|
||||
|
||||
#### **[LC-SEQ-SAFE.1]**
|
||||
|
||||
The light client never stores a header which is not in the blockchain.
|
||||
|
||||
# Part III - Light Client as Distributed System
|
||||
|
||||
## Computational Model
|
||||
|
||||
The light client communicates with remote processes only via the
|
||||
[verification](TODO) and the [detection](TODO) protocols. The
|
||||
respective assumptions are given there.
|
||||
|
||||
## Distributed Problem Statement
|
||||
|
||||
### Two Kinds of Liveness
|
||||
|
||||
In case of light client attacks, the sequential problem statement
|
||||
cannot always be satisfied. The lightclient cannot decide which block
|
||||
is from the chain and which is not. As a result, the light client just
|
||||
creates evidence, submits it, and terminates.
|
||||
For the liveness property, we thus add the
|
||||
possibility that instead of adding a lightblock, we also might terminate
|
||||
in case there is an attack.
|
||||
|
||||
#### **[LC-DIST-TERM.1]**
|
||||
|
||||
The light client either runs forever or it *terminates on attack*.
|
||||
|
||||
### Design choices
|
||||
|
||||
#### [LC-DIST-STORE.1]
|
||||
|
||||
The light client has a local data structure called LightStore
|
||||
that contains light blocks (that contain a header).
|
||||
|
||||
> The light store exposes functions to query and update it. They are
|
||||
> specified [here](TODO:onceVerificationIsMerged).
|
||||
|
||||
**TODO:** reference light store invariant [LCV-INV-LS-ROOT.2] once
|
||||
verification is merged
|
||||
|
||||
#### **[LC-DIST-SAFE.1]**
|
||||
|
||||
It is always the case that every header in *LightStore* was
|
||||
generated by an instance of Tendermint consensus.
|
||||
|
||||
#### **[LC-DIST-LIVE.1]**
|
||||
|
||||
Whenever the light client gets a new height *h* as input,
|
||||
|
||||
- and there is
|
||||
no light client attack up to height *h*, then the lightclient
|
||||
eventually puts the lightblock of height *h* in the lightstore and
|
||||
wait for another input.
|
||||
- otherwise, that is, if there
|
||||
is a light client attack on height *h*, then the light client
|
||||
must perform one of the following:
|
||||
- it terminates on attack.
|
||||
- it eventually puts the lightblock of height *h* in the lightstore and
|
||||
wait for another input.
|
||||
|
||||
> Observe that the "existence of a lightclient attack" just means that some node has generated a conflicting block. It does not necessarily mean that a (faulty) peer sends such a block to "our" lightclient. Thus, even if there is an attack somewhere in the system, our lightclient might still continue to operate normally.
|
||||
|
||||
### Solving the sequential specification
|
||||
|
||||
[LC-DIST-SAFE.1] is guaranteed by the detector; in particular it
|
||||
follows from
|
||||
[[LCD-DIST-INV-STORE.1]](TODO)
|
||||
[[LCD-DIST-LIVE.1]](TODO)
|
||||
|
||||
# Part IV - Light Client Supervisor Protocol
|
||||
|
||||
We provide a specification for a sequential Light Client Supervisor.
|
||||
The local code for verification is presented by a sequential function
|
||||
`Sequential-Supervisor` to highlight the control flow of this
|
||||
functionality. Each lightblock is first verified with a primary, and then
|
||||
cross-checked with secondaries, and if all goes well, the lightblock
|
||||
is
|
||||
added (with the attribute "trusted") to the
|
||||
lightstore. Intermiate lightblocks that were used to verify the target
|
||||
block but were not cross-checked are stored as "verified"
|
||||
|
||||
> We note that if a different concurrency model is considered
|
||||
> for an implementation, the semantics of the lightstore might change:
|
||||
> In a concurrent implementation, we might do verification for some
|
||||
> height *h*, add the
|
||||
> lightblock to the lightstore, and start concurrent threads that
|
||||
>
|
||||
> - do verification for the next height *h' != h*
|
||||
> - do cross-checking for height *h*. If we find an attack, we remove
|
||||
> *h* from the lightstore.
|
||||
> - the user might already start to use *h*
|
||||
>
|
||||
> Thus, this concurrency model changes the semantics of the
|
||||
> lightstore (not all lightblocks that are read by the user are
|
||||
> trusted; they may be removed if
|
||||
> we find a problem). Whether this is desirable, and whether the gain in
|
||||
> performance is worth it, we keep for future versions/discussion of
|
||||
> lightclient protocols.
|
||||
|
||||
## Definitions
|
||||
|
||||
### Peers
|
||||
|
||||
#### **[LC-DATA-PEERS.1]:**
|
||||
|
||||
A fixed set of full nodes is provided in the configuration upon
|
||||
initialization. Initially this set is partitioned into
|
||||
|
||||
- one full node that is the *primary* (singleton set),
|
||||
- a set *Secondaries* (of fixed size, e.g., 3),
|
||||
- a set *FullNodes*.
|
||||
- A set *FaultyNodes* of nodes that the light client suspects of
|
||||
being faulty; it is initially empty
|
||||
|
||||
#### **[LC-INV-NODES.1]:**
|
||||
|
||||
The detector shall maintain the following invariants:
|
||||
|
||||
- *FullNodes \intersect Secondaries = {}*
|
||||
- *FullNodes \intersect FaultyNodes = {}*
|
||||
- *Secondaries \intersect FaultyNodes = {}*
|
||||
|
||||
and the following transition invariant
|
||||
|
||||
- *FullNodes' \union Secondaries' \union FaultyNodes' = FullNodes
|
||||
\union Secondaries \union FaultyNodes*
|
||||
|
||||
#### **[LC-FUNC-REPLACE-PRIMARY.1]:**
|
||||
|
||||
```go
|
||||
Replace_Primary(root-of-trust LightBlock)
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- the primary is replaced by a secondary
|
||||
- to maintain a constant size of secondaries, need to
|
||||
- pick a new secondary *nsec* while ensuring [LC-INV-ROOT-AGREED.1]
|
||||
- that is, we need to ensure that root-of-trust = FetchLightBlock(nsec, root-of-trust.Header.Height)
|
||||
- Expected precondition
|
||||
- *FullNodes* is nonempty
|
||||
- Expected postcondition
|
||||
- *primary* is moved to *FaultyNodes*
|
||||
- a secondary *s* is moved from *Secondaries* to primary
|
||||
- Error condition
|
||||
- if precondition is violated
|
||||
|
||||
#### **[LC-FUNC-REPLACE-SECONDARY.1]:**
|
||||
|
||||
```go
|
||||
Replace_Secondary(addr Address, root-of-trust LightBlock)
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- maintain [LCD-INV-ROOT-AGREED.1], that is,
|
||||
ensure root-of-trust = FetchLightBlock(nsec, root-of-trust.Header.Height)
|
||||
- Expected precondition
|
||||
- *FullNodes* is nonempty
|
||||
- Expected postcondition
|
||||
- addr is moved from *Secondaries* to *FaultyNodes*
|
||||
- an address *nsec* is moved from *FullNodes* to *Secondaries*
|
||||
- Error condition
|
||||
- if precondition is violated
|
||||
|
||||
### Data Types
|
||||
|
||||
The core data structure of the protocol is the LightBlock.
|
||||
|
||||
#### **[LC-DATA-LIGHTBLOCK.1]**
|
||||
|
||||
```go
|
||||
type LightBlock struct {
|
||||
Header Header
|
||||
Commit Commit
|
||||
Validators ValidatorSet
|
||||
NextValidators ValidatorSet
|
||||
Provider PeerID
|
||||
}
|
||||
```
|
||||
|
||||
#### **[LC-DATA-LIGHTSTORE.1]**
|
||||
|
||||
LightBlocks are stored in a structure which stores all LightBlock from
|
||||
initialization or received from peers.
|
||||
|
||||
```go
|
||||
type LightStore struct {
|
||||
...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
We use the functions that the LightStore exposes, which
|
||||
are defined in the [verification specification](TODO).
|
||||
|
||||
### Inputs
|
||||
|
||||
The lightclient is initialized with LCInitData
|
||||
|
||||
#### **[LC-DATA-INIT.1]**
|
||||
|
||||
```go
|
||||
type LCInitData struct {
|
||||
lightBlock LightBlock
|
||||
genesisDoc GenesisDoc
|
||||
}
|
||||
```
|
||||
|
||||
where only one of the components must be provided. `GenesisDoc` is
|
||||
defined in the [Tendermint
|
||||
Types](https://github.com/tendermint/tendermint/blob/master/types/genesis.go).
|
||||
|
||||
#### **[LC-DATA-GENESIS.1]**
|
||||
|
||||
```go
|
||||
type GenesisDoc struct {
|
||||
GenesisTime time.Time `json:"genesis_time"`
|
||||
ChainID string `json:"chain_id"`
|
||||
InitialHeight int64 `json:"initial_height"`
|
||||
ConsensusParams *tmproto.ConsensusParams `json:"consensus_params,omitempty"`
|
||||
Validators []GenesisValidator `json:"validators,omitempty"`
|
||||
AppHash tmbytes.HexBytes `json:"app_hash"`
|
||||
AppState json.RawMessage `json:"app_state,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
We use the following function
|
||||
`makeblock` so that we create a lightblock from the genesis
|
||||
file in order to do verification based on the data from the genesis
|
||||
file using the same verification function we use in normal operation.
|
||||
|
||||
#### **[LC-FUNC-MAKEBLOCK.1]**
|
||||
|
||||
```go
|
||||
func makeblock (genesisDoc GenesisDoc) (lightBlock LightBlock))
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- none
|
||||
- Expected precondition
|
||||
- none
|
||||
- Expected postcondition
|
||||
- lightBlock.Header.Height = genesisDoc.InitialHeight
|
||||
- lightBlock.Header.Time = genesisDoc.GenesisTime
|
||||
- lightBlock.Header.LastBlockID = nil
|
||||
- lightBlock.Header.LastCommit = nil
|
||||
- lightBlock.Header.Validators = genesisDoc.Validators
|
||||
- lightBlock.Header.NextValidators = genesisDoc.Validators
|
||||
- lightBlock.Header.Data = nil
|
||||
- lightBlock.Header.AppState = genesisDoc.AppState
|
||||
- lightBlock.Header.LastResult = nil
|
||||
- lightBlock.Commit = nil
|
||||
- lightBlock.Validators = genesisDoc.Validators
|
||||
- lightBlock.NextValidators = genesisDoc.Validators
|
||||
- lightBlock.Provider = nil
|
||||
- Error condition
|
||||
- none
|
||||
|
||||
----
|
||||
|
||||
### Configuration Parameters
|
||||
|
||||
#### **[LC-INV-ROOT-AGREED.1]**
|
||||
|
||||
In the Sequential-Supervisor, it is always the case that the primary
|
||||
and all secondaries agree on lightStore.Latest().
|
||||
|
||||
### Assumptions
|
||||
|
||||
We have to assume that the initialization data (the lightblock or the
|
||||
genesis file) are consistent with the blockchain. This is subjective
|
||||
initialization and it cannot be checked locally.
|
||||
|
||||
### Invariants
|
||||
|
||||
#### **[LC-INV-PEERLIST.1]:**
|
||||
|
||||
The peer list contains a primary and a secondary.
|
||||
|
||||
> If the invariant is violated, the light client does not have enough
|
||||
> peers to download headers from. As a result, the light client
|
||||
> needs to terminate in case this invariant is violated.
|
||||
|
||||
## Supervisor
|
||||
|
||||
### Outline
|
||||
|
||||
The supervisor implements the functionality of the lightclient. It is
|
||||
initialized with a genesis file or with a lightblock the user
|
||||
trusts. This initialization is subjective, that is, the security of
|
||||
the lightclient is based on the validity of the input. If the genesis
|
||||
file or the lightblock deviate from the actual ones on the blockchain,
|
||||
the lightclient provides no guarantees.
|
||||
|
||||
After initialization, the supervisor awaits an input, that is, the
|
||||
height of the next lightblock that should be obtained. Then it
|
||||
downloads, verifies, and cross-checks a lightblock, and if all tests
|
||||
go through, the light block (and possibly other lightblocks) are added
|
||||
to the lightstore, which is returned in an output event to the user.
|
||||
|
||||
The following main loop does the interaction with the user (input,
|
||||
output) and calls the following two functions:
|
||||
|
||||
- `InitLightClient`: it initializes the lightstore either with the
|
||||
provided lightblock or with the lightblock that corresponds to the
|
||||
first block generated by the blockchain (by the validators defined
|
||||
by the genesis file)
|
||||
- `VerifyAndDetect`: takes as input a lightstore and a height and
|
||||
returns the updated lightstore.
|
||||
|
||||
#### **[LC-FUNC-SUPERVISOR.1]:**
|
||||
|
||||
```go
|
||||
func Sequential-Supervisor (initdata LCInitData) (Error) {
|
||||
|
||||
lightStore,result := InitLightClient(initData);
|
||||
if result != OK {
|
||||
return result;
|
||||
}
|
||||
|
||||
loop {
|
||||
// get the next height
|
||||
nextHeight := input();
|
||||
|
||||
lightStore,result := VerifyAndDetect(lightStore, nextHeight);
|
||||
|
||||
if result == OK {
|
||||
output(LightStore.Get(targetHeight));
|
||||
// we only output a trusted lightblock
|
||||
}
|
||||
else {
|
||||
return result
|
||||
}
|
||||
// QUESTION: is it OK to generate output event in normal case,
|
||||
// and terminate with failure in the (light client) attack case?
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- infinite loop unless a light client attack is detected
|
||||
- In typical implementations (e.g., the one in Rust),
|
||||
there are mutliple input actions:
|
||||
`VerifytoLatest`, `LatestTrusted`, and `GetStatus`. The
|
||||
information can be easily obtained from the lightstore, so that
|
||||
we do not treat these requests explicitly here but just consider
|
||||
the request for a block of a given height which requires more
|
||||
involved computation and communication.
|
||||
- Expected precondition
|
||||
- *LCInitData* contains a genesis file or a lightblock.
|
||||
- Expected postcondition
|
||||
- if a light client attack is detected: it stops and submits
|
||||
evidence (in `InitLightClient` or `VerifyAndDetect`)
|
||||
- otherwise: non. It runs forever.
|
||||
- Invariant: *lightStore* contains trusted lightblocks only.
|
||||
- Error condition
|
||||
- if `InitLightClient` or `VerifyAndDetect` fails (if a attack is
|
||||
detected, or if [LCV-INV-TP.1] is violated)
|
||||
|
||||
----
|
||||
|
||||
### Details of the Functions
|
||||
|
||||
#### Initialization
|
||||
|
||||
The light client is based on subjective initialization. It has to
|
||||
trust the initial data given to it by the user. It cannot do any
|
||||
detection of attack. So either upon initialization we obtain a
|
||||
lightblock and just initialize the lightstore with it. Or in case of a
|
||||
genesis file, we download, verify, and cross-check the first block, to
|
||||
initialize the lightstore with this first block. The reason is that
|
||||
we want to maintain [LCV-INV-TP.1] from the beginning.
|
||||
|
||||
> If the lightclient is initialized with a lightblock, one might think
|
||||
> it may increase trust, when one cross-checks the initial light
|
||||
> block. However, if a peer provides a conflicting
|
||||
> lightblock, the question is to distinguish the case of a
|
||||
> [bogus](https://informal.systems) block (upon which operation should proceed) from a
|
||||
> [light client attack](https://informal.systems) (upon which operation should stop). In
|
||||
> case of a bogus block, the lightclient might be forced to do
|
||||
> backwards verification until the blocks are out of the trusting
|
||||
> period, to make sure no previous validator set could have generated
|
||||
> the bogus block, which effectively opens up a DoS attack on the lightclient
|
||||
> without adding effective robustness.
|
||||
|
||||
#### **[LC-FUNC-INIT.1]:**
|
||||
|
||||
```go
|
||||
func InitLightClient (initData LCInitData) (LightStore, Error) {
|
||||
|
||||
if LCInitData.LightBlock != nil {
|
||||
// we trust the provided initial block.
|
||||
newblock := LCInitData.LightBlock
|
||||
}
|
||||
else {
|
||||
genesisBlock := makeblock(initData.genesisDoc);
|
||||
|
||||
result := NoResult;
|
||||
while result != ResultSuccess {
|
||||
current = FetchLightBlock(PeerList.primary(), genesisBlock.Header.Height + 1)
|
||||
// QUESTION: is the height with "+1" OK?
|
||||
|
||||
if CANNOT_VERIFY = ValidAndVerify(genesisBlock, current) {
|
||||
Replace_Primary();
|
||||
}
|
||||
else {
|
||||
result = ResultSuccess
|
||||
}
|
||||
}
|
||||
|
||||
// cross-check
|
||||
auxLS := new LightStore
|
||||
auxLS.Add(current)
|
||||
Evidences := AttackDetector(genesisBlock, auxLS)
|
||||
if Evidences.Empty {
|
||||
newBlock := current
|
||||
}
|
||||
else {
|
||||
// [LC-SUMBIT-EVIDENCE.1]
|
||||
submitEvidence(Evidences);
|
||||
return(nil, ErrorAttack);
|
||||
}
|
||||
}
|
||||
|
||||
lightStore := new LightStore;
|
||||
lightStore.Add(newBlock);
|
||||
return (lightStore, OK);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- none
|
||||
- Expected precondition
|
||||
- *LCInitData* contains either a genesis file of a lightblock
|
||||
- if genesis it passes `ValidateAndComplete()` see [Tendermint](https://informal.systems)
|
||||
- Expected postcondition
|
||||
- *lightStore* initialized with trusted lightblock. It has either been
|
||||
cross-checked (from genesis) or it has initial trust from the
|
||||
user.
|
||||
- Error condition
|
||||
- if precondition is violated
|
||||
- empty peerList
|
||||
|
||||
----
|
||||
|
||||
#### Main verification and detection logic
|
||||
|
||||
#### **[LC-FUNC-MAIN-VERIF-DETECT.1]:**
|
||||
|
||||
```go
|
||||
func VerifyAndDetect (lightStore LightStore, targetHeight Height)
|
||||
(LightStore, Result) {
|
||||
|
||||
b1, r1 = lightStore.Get(targetHeight)
|
||||
if r1 == true {
|
||||
if b1.State == StateTrusted {
|
||||
// block already there and trusted
|
||||
return (lightStore, ResultSuccess)
|
||||
}
|
||||
else {
|
||||
// We have a lightblock in the store, but it has not been
|
||||
// cross-checked by now. We do that now.
|
||||
root_of_trust, auxLS := lightstore.TraceTo(b1);
|
||||
|
||||
// Cross-check
|
||||
Evidences := AttackDetector(root_of_trust, auxLS);
|
||||
if Evidences.Empty {
|
||||
// no attack detected, we trust the new lightblock
|
||||
lightStore.Update(auxLS.Latest(),
|
||||
StateTrusted,
|
||||
verfiedLS.Latest().verification-root);
|
||||
return (lightStore, OK);
|
||||
}
|
||||
else {
|
||||
// there is an attack, we exit
|
||||
submitEvidence(Evidences);
|
||||
return(lightStore, ErrorAttack);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// get the lightblock with maximum height smaller than targetHeight
|
||||
// would typically be the heighest, if we always move forward
|
||||
root_of_trust, r2 = lightStore.LatestPrevious(targetHeight);
|
||||
|
||||
if r2 = false {
|
||||
// there is no lightblock from which we can do forward
|
||||
// (skipping) verification. Thus we have to go backwards.
|
||||
// No cross-check needed. We trust hashes. Therefore, we
|
||||
// directly return the result
|
||||
return Backwards(primary, lightStore.Lowest(), targetHeight)
|
||||
}
|
||||
else {
|
||||
// Forward verification + detection
|
||||
result := NoResult;
|
||||
while result != ResultSuccess {
|
||||
verifiedLS,result := VerifyToTarget(primary,
|
||||
root_of_trust,
|
||||
nextHeight);
|
||||
if result == ResultFailure {
|
||||
// pick new primary (promote a secondary to primary)
|
||||
Replace_Primary(root_of_trust);
|
||||
}
|
||||
else if result == ResultExpired {
|
||||
return (lightStore, result)
|
||||
}
|
||||
}
|
||||
|
||||
// Cross-check
|
||||
Evidences := AttackDetector(root_of_trust, verifiedLS);
|
||||
if Evidences.Empty {
|
||||
// no attack detected, we trust the new lightblock
|
||||
verifiedLS.Update(verfiedLS.Latest(),
|
||||
StateTrusted,
|
||||
verfiedLS.Latest().verification-root);
|
||||
lightStore.store_chain(verifidLS);
|
||||
return (lightStore, OK);
|
||||
}
|
||||
else {
|
||||
// there is an attack, we exit
|
||||
return(lightStore, ErrorAttack);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Implementation remark
|
||||
- none
|
||||
- Expected precondition
|
||||
- none
|
||||
- Expected postcondition
|
||||
- lightblock of height *targetHeight* (and possibly additional blocks) added to *lightStore*
|
||||
- Error condition
|
||||
- an attack is detected
|
||||
- [LC-DATA-PEERLIST-INV.1] is violated
|
||||
|
||||
----
|
||||
71
spec/light-client/supervisor/supervisor_001_draft.tla
Normal file
@@ -0,0 +1,71 @@
|
||||
------------------------- MODULE supervisor_001_draft ------------------------
|
||||
(*
|
||||
This is the beginning of a spec that will eventually use verification and detector API
|
||||
*)
|
||||
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
VARIABLES
|
||||
state,
|
||||
output
|
||||
|
||||
vars == <<state, output>>
|
||||
|
||||
CONSTANT
|
||||
INITDATA
|
||||
|
||||
Init ==
|
||||
/\ state = "Init"
|
||||
/\ output = "none"
|
||||
|
||||
NextInit ==
|
||||
/\ state = "Init"
|
||||
/\ \/ state' = "EnterLoop"
|
||||
\/ state' = "FailedToInitialize"
|
||||
/\ UNCHANGED output
|
||||
|
||||
NextVerifyToTarget ==
|
||||
/\ state = "EnterLoop"
|
||||
/\ \/ state' = "EnterLoop" \* replace primary
|
||||
\/ state' = "EnterDetect"
|
||||
\/ state' = "ExhaustedPeersPrimary"
|
||||
/\ UNCHANGED output
|
||||
|
||||
NextAttackDetector ==
|
||||
/\ state = "EnterDetect"
|
||||
/\ \/ state' = "NoEvidence"
|
||||
\/ state' = "EvidenceFound"
|
||||
\/ state' = "ExhaustedPeersSecondaries"
|
||||
/\ UNCHANGED output
|
||||
|
||||
NextVerifyAndDetect ==
|
||||
\/ NextVerifyToTarget
|
||||
\/ NextAttackDetector
|
||||
|
||||
NextOutput ==
|
||||
/\ state = "NoEvidence"
|
||||
/\ state' = "EnterLoop"
|
||||
/\ output' = "data" \* to generate a trace
|
||||
|
||||
NextTerminated ==
|
||||
/\ \/ state = "FailedToInitialize"
|
||||
\/ state = "ExhaustedPeersPrimary"
|
||||
\/ state = "EvidenceFound"
|
||||
\/ state = "ExhaustedPeersSecondaries"
|
||||
/\ UNCHANGED vars
|
||||
|
||||
Next ==
|
||||
\/ NextInit
|
||||
\/ NextVerifyAndDetect
|
||||
\/ NextOutput
|
||||
\/ NextTerminated
|
||||
|
||||
InvEnoughPeers ==
|
||||
/\ state /= "ExhaustedPeersPrimary"
|
||||
/\ state /= "ExhaustedPeersSecondaries"
|
||||
|
||||
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Sun Oct 18 11:48:45 CEST 2020 by widder
|
||||
\* Created Sun Oct 18 11:18:53 CEST 2020 by widder
|
||||
49
spec/light-client/verification/001bmc-apalache.csv
Normal file
@@ -0,0 +1,49 @@
|
||||
no,filename,tool,timeout,init,inv,next,args
|
||||
1,MC4_3_correct.tla,apalache,1h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
2,MC4_3_correct.tla,apalache,1h,,CorrectnessInv,,--length=30
|
||||
3,MC4_3_correct.tla,apalache,1h,,PrecisionInv,,--length=30
|
||||
4,MC4_3_correct.tla,apalache,1h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
5,MC4_3_correct.tla,apalache,1h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
6,MC4_3_correct.tla,apalache,1h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
7,MC4_3_correct.tla,apalache,1h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
8,MC4_3_correct.tla,apalache,1h,,Complexity,,--length=30
|
||||
9,MC4_3_faulty.tla,apalache,1h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
10,MC4_3_faulty.tla,apalache,1h,,CorrectnessInv,,--length=30
|
||||
11,MC4_3_faulty.tla,apalache,1h,,PrecisionInv,,--length=30
|
||||
12,MC4_3_faulty.tla,apalache,1h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
13,MC4_3_faulty.tla,apalache,1h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
14,MC4_3_faulty.tla,apalache,1h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
15,MC4_3_faulty.tla,apalache,1h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
16,MC4_3_faulty.tla,apalache,1h,,Complexity,,--length=30
|
||||
17,MC5_5_correct.tla,apalache,1h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
18,MC5_5_correct.tla,apalache,1h,,CorrectnessInv,,--length=30
|
||||
19,MC5_5_correct.tla,apalache,1h,,PrecisionInv,,--length=30
|
||||
20,MC5_5_correct.tla,apalache,1h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
21,MC5_5_correct.tla,apalache,1h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
22,MC5_5_correct.tla,apalache,1h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
23,MC5_5_correct.tla,apalache,1h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
24,MC5_5_correct.tla,apalache,1h,,Complexity,,--length=30
|
||||
25,MC5_5_faulty.tla,apalache,1h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
26,MC5_5_faulty.tla,apalache,1h,,CorrectnessInv,,--length=30
|
||||
27,MC5_5_faulty.tla,apalache,1h,,PrecisionInv,,--length=30
|
||||
28,MC5_5_faulty.tla,apalache,1h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
29,MC5_5_faulty.tla,apalache,1h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
30,MC5_5_faulty.tla,apalache,1h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
31,MC5_5_faulty.tla,apalache,1h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
32,MC5_5_faulty.tla,apalache,1h,,Complexity,,--length=30
|
||||
33,MC7_5_faulty.tla,apalache,10h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
34,MC7_5_faulty.tla,apalache,10h,,CorrectnessInv,,--length=30
|
||||
35,MC7_5_faulty.tla,apalache,10h,,PrecisionInv,,--length=30
|
||||
36,MC7_5_faulty.tla,apalache,10h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
37,MC7_5_faulty.tla,apalache,10h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
38,MC7_5_faulty.tla,apalache,10h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
39,MC7_5_faulty.tla,apalache,10h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
40,MC7_5_faulty.tla,apalache,10h,,Complexity,,--length=30
|
||||
41,MC4_7_faulty.tla,apalache,10h,,PositiveBeforeTrustedHeaderExpires,,--length=30
|
||||
42,MC4_7_faulty.tla,apalache,10h,,CorrectnessInv,,--length=30
|
||||
43,MC4_7_faulty.tla,apalache,10h,,PrecisionInv,,--length=30
|
||||
44,MC4_7_faulty.tla,apalache,10h,,SuccessOnCorrectPrimaryAndChainOfTrust,,--length=30
|
||||
45,MC4_7_faulty.tla,apalache,10h,,NoFailedBlocksOnSuccessInv,,--length=30
|
||||
46,MC4_7_faulty.tla,apalache,10h,,StoredHeadersAreVerifiedOrNotTrustedInv,,--length=30
|
||||
47,MC4_7_faulty.tla,apalache,10h,,CorrectPrimaryAndTimeliness,,--length=30
|
||||
48,MC4_7_faulty.tla,apalache,10h,,Complexity,,--length=30
|
||||
|
55
spec/light-client/verification/002bmc-apalache-ok.csv
Normal file
@@ -0,0 +1,55 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;MC4_3_correct.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=5
|
||||
2;MC4_3_correct.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=5
|
||||
3;MC4_3_correct.tla;apalache;1h;;CorrectnessInv;;--length=5
|
||||
4;MC4_3_correct.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=5
|
||||
5;MC4_3_correct.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=5
|
||||
6;MC4_3_correct.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=5
|
||||
7;MC4_3_correct.tla;apalache;1h;;Complexity;;--length=5
|
||||
8;MC4_3_correct.tla;apalache;1h;;ApiPostInv;;--length=5
|
||||
9;MC4_4_correct.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=7
|
||||
10;MC4_4_correct.tla;apalache;1h;;CorrectnessInv;;--length=7
|
||||
11;MC4_4_correct.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=7
|
||||
12;MC4_4_correct.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=7
|
||||
13;MC4_4_correct.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=7
|
||||
14;MC4_4_correct.tla;apalache;1h;;Complexity;;--length=7
|
||||
15;MC4_4_correct.tla;apalache;1h;;ApiPostInv;;--length=7
|
||||
16;MC4_5_correct.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=11
|
||||
17;MC4_5_correct.tla;apalache;1h;;CorrectnessInv;;--length=11
|
||||
18;MC4_5_correct.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=11
|
||||
19;MC4_5_correct.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=11
|
||||
20;MC4_5_correct.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=11
|
||||
21;MC4_5_correct.tla;apalache;1h;;Complexity;;--length=11
|
||||
22;MC4_5_correct.tla;apalache;1h;;ApiPostInv;;--length=11
|
||||
23;MC5_5_correct.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=11
|
||||
24;MC5_5_correct.tla;apalache;1h;;CorrectnessInv;;--length=11
|
||||
25;MC5_5_correct.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=11
|
||||
26;MC5_5_correct.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=11
|
||||
27;MC5_5_correct.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=11
|
||||
28;MC5_5_correct.tla;apalache;1h;;Complexity;;--length=11
|
||||
29;MC5_5_correct.tla;apalache;1h;;ApiPostInv;;--length=11
|
||||
30;MC4_3_faulty.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=5
|
||||
31;MC4_3_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=5
|
||||
32;MC4_3_faulty.tla;apalache;1h;;CorrectnessInv;;--length=5
|
||||
33;MC4_3_faulty.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=5
|
||||
34;MC4_3_faulty.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=5
|
||||
35;MC4_3_faulty.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=5
|
||||
36;MC4_3_faulty.tla;apalache;1h;;Complexity;;--length=5
|
||||
37;MC4_3_faulty.tla;apalache;1h;;ApiPostInv;;--length=5
|
||||
38;MC4_4_faulty.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=7
|
||||
39;MC4_4_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=7
|
||||
40;MC4_4_faulty.tla;apalache;1h;;CorrectnessInv;;--length=7
|
||||
41;MC4_4_faulty.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=7
|
||||
42;MC4_4_faulty.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=7
|
||||
43;MC4_4_faulty.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=7
|
||||
44;MC4_4_faulty.tla;apalache;1h;;Complexity;;--length=7
|
||||
45;MC4_4_faulty.tla;apalache;1h;;ApiPostInv;;--length=7
|
||||
46;MC4_5_faulty.tla;apalache;1h;;TargetHeightOnSuccessInv;;--length=11
|
||||
47;MC4_5_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=11
|
||||
48;MC4_5_faulty.tla;apalache;1h;;CorrectnessInv;;--length=11
|
||||
49;MC4_5_faulty.tla;apalache;1h;;NoTrustOnFaultyBlockInv;;--length=11
|
||||
50;MC4_5_faulty.tla;apalache;1h;;ProofOfChainOfTrustInv;;--length=11
|
||||
51;MC4_5_faulty.tla;apalache;1h;;NoFailedBlocksOnSuccessInv;;--length=11
|
||||
52;MC4_5_faulty.tla;apalache;1h;;Complexity;;--length=11
|
||||
53;MC4_5_faulty.tla;apalache;1h;;ApiPostInv;;--length=11
|
||||
|
||||
|
45
spec/light-client/verification/003bmc-apalache-error.csv
Normal file
@@ -0,0 +1,45 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;MC4_3_correct.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=5
|
||||
2;MC4_3_correct.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=5
|
||||
3;MC4_3_correct.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=5
|
||||
4;MC4_3_correct.tla;apalache;1h;;PrecisionInv;;--length=5
|
||||
5;MC4_3_correct.tla;apalache;1h;;PrecisionBuggyInv;;--length=5
|
||||
6;MC4_3_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=5
|
||||
7;MC4_3_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=5
|
||||
8;MC4_4_correct.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=7
|
||||
9;MC4_4_correct.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=7
|
||||
10;MC4_4_correct.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=7
|
||||
11;MC4_4_correct.tla;apalache;1h;;PrecisionInv;;--length=7
|
||||
12;MC4_4_correct.tla;apalache;1h;;PrecisionBuggyInv;;--length=7
|
||||
13;MC4_4_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=7
|
||||
14;MC4_4_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=7
|
||||
15;MC4_5_correct.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=11
|
||||
16;MC4_5_correct.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=11
|
||||
17;MC4_5_correct.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=11
|
||||
18;MC4_5_correct.tla;apalache;1h;;PrecisionInv;;--length=11
|
||||
19;MC4_5_correct.tla;apalache;1h;;PrecisionBuggyInv;;--length=11
|
||||
20;MC4_5_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=11
|
||||
21;MC4_5_correct.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=11
|
||||
22;MC4_5_correct.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=11
|
||||
23;MC4_3_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=5
|
||||
24;MC4_3_faulty.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=5
|
||||
25;MC4_3_faulty.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=5
|
||||
26;MC4_3_faulty.tla;apalache;1h;;PrecisionInv;;--length=5
|
||||
27;MC4_3_faulty.tla;apalache;1h;;PrecisionBuggyInv;;--length=5
|
||||
28;MC4_3_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=5
|
||||
29;MC4_3_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=5
|
||||
30;MC4_4_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=7
|
||||
31;MC4_4_faulty.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=7
|
||||
32;MC4_4_faulty.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=7
|
||||
33;MC4_4_faulty.tla;apalache;1h;;PrecisionInv;;--length=7
|
||||
34;MC4_4_faulty.tla;apalache;1h;;PrecisionBuggyInv;;--length=7
|
||||
35;MC4_4_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=7
|
||||
36;MC4_4_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=7
|
||||
37;MC4_5_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedInv;;--length=11
|
||||
38;MC4_5_faulty.tla;apalache;1h;;PositiveBeforeTrustedHeaderExpires;;--length=11
|
||||
39;MC4_5_faulty.tla;apalache;1h;;CorrectPrimaryAndTimeliness;;--length=11
|
||||
40;MC4_5_faulty.tla;apalache;1h;;PrecisionInv;;--length=11
|
||||
41;MC4_5_faulty.tla;apalache;1h;;PrecisionBuggyInv;;--length=11
|
||||
42;MC4_5_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustGlobal;;--length=11
|
||||
43;MC4_5_faulty.tla;apalache;1h;;SuccessOnCorrectPrimaryAndChainOfTrustLocal;;--length=11
|
||||
44;MC4_5_faulty.tla;apalache;1h;;StoredHeadersAreVerifiedOrNotTrustedInv;;--length=11
|
||||
|
10
spec/light-client/verification/004bmc-apalache-ok.csv
Normal file
@@ -0,0 +1,10 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;LCD_MC3_3_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
2;LCD_MC3_3_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
3;LCD_MC3_3_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
4;LCD_MC3_4_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
5;LCD_MC3_4_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
6;LCD_MC3_4_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
7;LCD_MC4_4_faulty.tla;apalache;1h;;CommonHeightOnEvidenceInv;;--length=10
|
||||
8;LCD_MC4_4_faulty.tla;apalache;1h;;AccuracyInv;;--length=10
|
||||
9;LCD_MC4_4_faulty.tla;apalache;1h;;PrecisionInvLocal;;--length=10
|
||||
|
4
spec/light-client/verification/005bmc-apalache-error.csv
Normal file
@@ -0,0 +1,4 @@
|
||||
no;filename;tool;timeout;init;inv;next;args
|
||||
1;LCD_MC3_3_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
2;LCD_MC3_4_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
3;LCD_MC4_4_faulty.tla;apalache;1h;;PrecisionInvGrayZone;;--length=10
|
||||
|
171
spec/light-client/verification/Blockchain_002_draft.tla
Normal file
@@ -0,0 +1,171 @@
|
||||
------------------------ MODULE Blockchain_002_draft -----------------------------
|
||||
(*
|
||||
This is a high-level specification of Tendermint blockchain
|
||||
that is designed specifically for the light client.
|
||||
Validators have the voting power of one. If you like to model various
|
||||
voting powers, introduce multiple copies of the same validator
|
||||
(do not forget to give them unique names though).
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
Min(a, b) == IF a < b THEN a ELSE b
|
||||
|
||||
CONSTANT
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
ULTIMATE_HEIGHT,
|
||||
(* a maximal height that can be ever reached (modelling artifact) *)
|
||||
TRUSTING_PERIOD
|
||||
(* the period within which the validators are trusted *)
|
||||
|
||||
Heights == 1..ULTIMATE_HEIGHT (* possible heights *)
|
||||
|
||||
(* A commit is just a set of nodes who have committed the block *)
|
||||
Commits == SUBSET AllNodes
|
||||
|
||||
(* The set of all block headers that can be on the blockchain.
|
||||
This is a simplified version of the Block data structure in the actual implementation. *)
|
||||
BlockHeaders == [
|
||||
height: Heights,
|
||||
\* the block height
|
||||
time: Int,
|
||||
\* the block timestamp in some integer units
|
||||
lastCommit: Commits,
|
||||
\* the nodes who have voted on the previous block, the set itself instead of a hash
|
||||
(* in the implementation, only the hashes of V and NextV are stored in a block,
|
||||
as V and NextV are stored in the application state *)
|
||||
VS: SUBSET AllNodes,
|
||||
\* the validators of this bloc. We store the validators instead of the hash.
|
||||
NextVS: SUBSET AllNodes
|
||||
\* the validators of the next block. We store the next validators instead of the hash.
|
||||
]
|
||||
|
||||
(* A signed header is just a header together with a set of commits *)
|
||||
LightBlocks == [header: BlockHeaders, Commits: Commits]
|
||||
|
||||
VARIABLES
|
||||
now,
|
||||
(* the current global time in integer units *)
|
||||
blockchain,
|
||||
(* A sequence of BlockHeaders, which gives us a bird view of the blockchain. *)
|
||||
Faulty
|
||||
(* A set of faulty nodes, which can act as validators. We assume that the set
|
||||
of faulty processes is non-decreasing. If a process has recovered, it should
|
||||
connect using a different id. *)
|
||||
|
||||
(* all variables, to be used with UNCHANGED *)
|
||||
vars == <<now, blockchain, Faulty>>
|
||||
|
||||
(* The set of all correct nodes in a state *)
|
||||
Corr == AllNodes \ Faulty
|
||||
|
||||
(* APALACHE annotations *)
|
||||
a <: b == a \* type annotation
|
||||
|
||||
NT == STRING
|
||||
NodeSet(S) == S <: {NT}
|
||||
EmptyNodeSet == NodeSet({})
|
||||
|
||||
BT == [height |-> Int, time |-> Int, lastCommit |-> {NT}, VS |-> {NT}, NextVS |-> {NT}]
|
||||
|
||||
LBT == [header |-> BT, Commits |-> {NT}]
|
||||
(* end of APALACHE annotations *)
|
||||
|
||||
(****************************** BLOCKCHAIN ************************************)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriod(header) ==
|
||||
now < header.time + TRUSTING_PERIOD
|
||||
|
||||
(*
|
||||
Given a function pVotingPower \in D -> Powers for some D \subseteq AllNodes
|
||||
and pNodes \subseteq D, test whether the set pNodes \subseteq AllNodes has
|
||||
more than 2/3 of voting power among the nodes in D.
|
||||
*)
|
||||
TwoThirds(pVS, pNodes) ==
|
||||
LET TP == Cardinality(pVS)
|
||||
SP == Cardinality(pVS \intersect pNodes)
|
||||
IN
|
||||
3 * SP > 2 * TP \* when thinking in real numbers, not integers: SP > 2.0 / 3.0 * TP
|
||||
|
||||
(*
|
||||
Given a set of FaultyNodes, test whether the voting power of the correct nodes in D
|
||||
is more than 2/3 of the voting power of the faulty nodes in D.
|
||||
*)
|
||||
IsCorrectPower(pFaultyNodes, pVS) ==
|
||||
LET FN == pFaultyNodes \intersect pVS \* faulty nodes in pNodes
|
||||
CN == pVS \ pFaultyNodes \* correct nodes in pNodes
|
||||
CP == Cardinality(CN) \* power of the correct nodes
|
||||
FP == Cardinality(FN) \* power of the faulty nodes
|
||||
IN
|
||||
\* CP + FP = TP is the total voting power, so we write CP > 2.0 / 3 * TP as follows:
|
||||
CP > 2 * FP \* Note: when FP = 0, this implies CP > 0.
|
||||
|
||||
(* This is what we believe is the assumption about failures in Tendermint *)
|
||||
FaultAssumption(pFaultyNodes, pNow, pBlockchain) ==
|
||||
\A h \in Heights:
|
||||
pBlockchain[h].time + TRUSTING_PERIOD > pNow =>
|
||||
IsCorrectPower(pFaultyNodes, pBlockchain[h].NextVS)
|
||||
|
||||
(* Can a block be produced by a correct peer, or an authenticated Byzantine peer *)
|
||||
IsLightBlockAllowedByDigitalSignatures(ht, block) ==
|
||||
\/ block.header = blockchain[ht] \* signed by correct and faulty (maybe)
|
||||
\/ block.Commits \subseteq Faulty /\ block.header.height = ht /\ block.header.time >= 0 \* signed only by faulty
|
||||
|
||||
(*
|
||||
Initialize the blockchain to the ultimate height right in the initial states.
|
||||
We pick the faulty validators statically, but that should not affect the light client.
|
||||
*)
|
||||
InitToHeight ==
|
||||
/\ Faulty \in SUBSET AllNodes \* some nodes may fail
|
||||
\* pick the validator sets and last commits
|
||||
/\ \E vs, lastCommit \in [Heights -> SUBSET AllNodes]:
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
\* now is at least as early as the timestamp in the last block
|
||||
/\ \E tm \in Int: now = tm /\ tm >= timestamp[ULTIMATE_HEIGHT]
|
||||
\* the genesis starts on day 1
|
||||
/\ timestamp[1] = 1
|
||||
/\ vs[1] = AllNodes
|
||||
/\ lastCommit[1] = EmptyNodeSet
|
||||
/\ \A h \in Heights \ {1}:
|
||||
/\ lastCommit[h] \subseteq vs[h - 1] \* the non-validators cannot commit
|
||||
/\ TwoThirds(vs[h - 1], lastCommit[h]) \* the commit has >2/3 of validator votes
|
||||
/\ IsCorrectPower(Faulty, vs[h]) \* the correct validators have >2/3 of power
|
||||
/\ timestamp[h] > timestamp[h - 1] \* the time grows monotonically
|
||||
/\ timestamp[h] < timestamp[h - 1] + TRUSTING_PERIOD \* but not too fast
|
||||
\* form the block chain out of validator sets and commits (this makes apalache faster)
|
||||
/\ blockchain = [h \in Heights |->
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> IF h < ULTIMATE_HEIGHT THEN vs[h + 1] ELSE AllNodes,
|
||||
lastCommit |-> lastCommit[h]]
|
||||
] \******
|
||||
|
||||
|
||||
(* is the blockchain in the faulty zone where the Tendermint security model does not apply *)
|
||||
InFaultyZone ==
|
||||
~FaultAssumption(Faulty, now, blockchain)
|
||||
|
||||
(********************* BLOCKCHAIN ACTIONS ********************************)
|
||||
(*
|
||||
Advance the clock by zero or more time units.
|
||||
*)
|
||||
AdvanceTime ==
|
||||
\E tm \in Int: tm >= now /\ now' = tm
|
||||
/\ UNCHANGED <<blockchain, Faulty>>
|
||||
|
||||
(*
|
||||
One more process fails. As a result, the blockchain may move into the faulty zone.
|
||||
The light client is not using this action, as the faults are picked in the initial state.
|
||||
However, this action may be useful when reasoning about fork detection.
|
||||
*)
|
||||
OneMoreFault ==
|
||||
/\ \E n \in AllNodes \ Faulty:
|
||||
/\ Faulty' = Faulty \cup {n}
|
||||
/\ Faulty' /= AllNodes \* at least process remains non-faulty
|
||||
/\ UNCHANGED <<now, blockchain>>
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Wed Jun 10 14:10:54 CEST 2020 by igor
|
||||
\* Created Fri Oct 11 15:45:11 CEST 2019 by igor
|
||||
164
spec/light-client/verification/Blockchain_003_draft.tla
Normal file
@@ -0,0 +1,164 @@
|
||||
------------------------ MODULE Blockchain_003_draft -----------------------------
|
||||
(*
|
||||
This is a high-level specification of Tendermint blockchain
|
||||
that is designed specifically for the light client.
|
||||
Validators have the voting power of one. If you like to model various
|
||||
voting powers, introduce multiple copies of the same validator
|
||||
(do not forget to give them unique names though).
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
Min(a, b) == IF a < b THEN a ELSE b
|
||||
|
||||
CONSTANT
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
ULTIMATE_HEIGHT,
|
||||
(* a maximal height that can be ever reached (modelling artifact) *)
|
||||
TRUSTING_PERIOD
|
||||
(* the period within which the validators are trusted *)
|
||||
|
||||
Heights == 1..ULTIMATE_HEIGHT (* possible heights *)
|
||||
|
||||
(* A commit is just a set of nodes who have committed the block *)
|
||||
Commits == SUBSET AllNodes
|
||||
|
||||
(* The set of all block headers that can be on the blockchain.
|
||||
This is a simplified version of the Block data structure in the actual implementation. *)
|
||||
BlockHeaders == [
|
||||
height: Heights,
|
||||
\* the block height
|
||||
time: Int,
|
||||
\* the block timestamp in some integer units
|
||||
lastCommit: Commits,
|
||||
\* the nodes who have voted on the previous block, the set itself instead of a hash
|
||||
(* in the implementation, only the hashes of V and NextV are stored in a block,
|
||||
as V and NextV are stored in the application state *)
|
||||
VS: SUBSET AllNodes,
|
||||
\* the validators of this bloc. We store the validators instead of the hash.
|
||||
NextVS: SUBSET AllNodes
|
||||
\* the validators of the next block. We store the next validators instead of the hash.
|
||||
]
|
||||
|
||||
(* A signed header is just a header together with a set of commits *)
|
||||
LightBlocks == [header: BlockHeaders, Commits: Commits]
|
||||
|
||||
VARIABLES
|
||||
refClock,
|
||||
(* the current global time in integer units as perceived by the reference chain *)
|
||||
blockchain,
|
||||
(* A sequence of BlockHeaders, which gives us a bird view of the blockchain. *)
|
||||
Faulty
|
||||
(* A set of faulty nodes, which can act as validators. We assume that the set
|
||||
of faulty processes is non-decreasing. If a process has recovered, it should
|
||||
connect using a different id. *)
|
||||
|
||||
(* all variables, to be used with UNCHANGED *)
|
||||
vars == <<refClock, blockchain, Faulty>>
|
||||
|
||||
(* The set of all correct nodes in a state *)
|
||||
Corr == AllNodes \ Faulty
|
||||
|
||||
(* APALACHE annotations *)
|
||||
a <: b == a \* type annotation
|
||||
|
||||
NT == STRING
|
||||
NodeSet(S) == S <: {NT}
|
||||
EmptyNodeSet == NodeSet({})
|
||||
|
||||
BT == [height |-> Int, time |-> Int, lastCommit |-> {NT}, VS |-> {NT}, NextVS |-> {NT}]
|
||||
|
||||
LBT == [header |-> BT, Commits |-> {NT}]
|
||||
(* end of APALACHE annotations *)
|
||||
|
||||
(****************************** BLOCKCHAIN ************************************)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriod(header) ==
|
||||
refClock < header.time + TRUSTING_PERIOD
|
||||
|
||||
(*
|
||||
Given a function pVotingPower \in D -> Powers for some D \subseteq AllNodes
|
||||
and pNodes \subseteq D, test whether the set pNodes \subseteq AllNodes has
|
||||
more than 2/3 of voting power among the nodes in D.
|
||||
*)
|
||||
TwoThirds(pVS, pNodes) ==
|
||||
LET TP == Cardinality(pVS)
|
||||
SP == Cardinality(pVS \intersect pNodes)
|
||||
IN
|
||||
3 * SP > 2 * TP \* when thinking in real numbers, not integers: SP > 2.0 / 3.0 * TP
|
||||
|
||||
(*
|
||||
Given a set of FaultyNodes, test whether the voting power of the correct nodes in D
|
||||
is more than 2/3 of the voting power of the faulty nodes in D.
|
||||
|
||||
Parameters:
|
||||
- pFaultyNodes is a set of nodes that are considered faulty
|
||||
- pVS is a set of all validators, maybe including Faulty, intersecting with it, etc.
|
||||
- pMaxFaultRatio is a pair <<a, b>> that limits the ratio a / b of the faulty
|
||||
validators from above (exclusive)
|
||||
*)
|
||||
FaultyValidatorsFewerThan(pFaultyNodes, pVS, maxRatio) ==
|
||||
LET FN == pFaultyNodes \intersect pVS \* faulty nodes in pNodes
|
||||
CN == pVS \ pFaultyNodes \* correct nodes in pNodes
|
||||
CP == Cardinality(CN) \* power of the correct nodes
|
||||
FP == Cardinality(FN) \* power of the faulty nodes
|
||||
IN
|
||||
\* CP + FP = TP is the total voting power
|
||||
LET TP == CP + FP IN
|
||||
FP * maxRatio[2] < TP * maxRatio[1]
|
||||
|
||||
(* Can a block be produced by a correct peer, or an authenticated Byzantine peer *)
|
||||
IsLightBlockAllowedByDigitalSignatures(ht, block) ==
|
||||
\/ block.header = blockchain[ht] \* signed by correct and faulty (maybe)
|
||||
\/ /\ block.Commits \subseteq Faulty
|
||||
/\ block.header.height = ht
|
||||
/\ block.header.time >= 0 \* signed only by faulty
|
||||
|
||||
(*
|
||||
Initialize the blockchain to the ultimate height right in the initial states.
|
||||
We pick the faulty validators statically, but that should not affect the light client.
|
||||
|
||||
Parameters:
|
||||
- pMaxFaultyRatioExclusive is a pair <<a, b>> that bound the number of
|
||||
faulty validators in each block by the ratio a / b (exclusive)
|
||||
*)
|
||||
InitToHeight(pMaxFaultyRatioExclusive) ==
|
||||
/\ Faulty \in SUBSET AllNodes \* some nodes may fail
|
||||
\* pick the validator sets and last commits
|
||||
/\ \E vs, lastCommit \in [Heights -> SUBSET AllNodes]:
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
\* refClock is at least as early as the timestamp in the last block
|
||||
/\ \E tm \in Int: refClock = tm /\ tm >= timestamp[ULTIMATE_HEIGHT]
|
||||
\* the genesis starts on day 1
|
||||
/\ timestamp[1] = 1
|
||||
/\ vs[1] = AllNodes
|
||||
/\ lastCommit[1] = EmptyNodeSet
|
||||
/\ \A h \in Heights \ {1}:
|
||||
/\ lastCommit[h] \subseteq vs[h - 1] \* the non-validators cannot commit
|
||||
/\ TwoThirds(vs[h - 1], lastCommit[h]) \* the commit has >2/3 of validator votes
|
||||
\* the faulty validators have the power below the threshold
|
||||
/\ FaultyValidatorsFewerThan(Faulty, vs[h], pMaxFaultyRatioExclusive)
|
||||
/\ timestamp[h] > timestamp[h - 1] \* the time grows monotonically
|
||||
/\ timestamp[h] < timestamp[h - 1] + TRUSTING_PERIOD \* but not too fast
|
||||
\* form the block chain out of validator sets and commits (this makes apalache faster)
|
||||
/\ blockchain = [h \in Heights |->
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> IF h < ULTIMATE_HEIGHT THEN vs[h + 1] ELSE AllNodes,
|
||||
lastCommit |-> lastCommit[h]]
|
||||
] \******
|
||||
|
||||
(********************* BLOCKCHAIN ACTIONS ********************************)
|
||||
(*
|
||||
Advance the clock by zero or more time units.
|
||||
*)
|
||||
AdvanceTime ==
|
||||
/\ \E tm \in Int: tm >= refClock /\ refClock' = tm
|
||||
/\ UNCHANGED <<blockchain, Faulty>>
|
||||
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Wed Jun 10 14:10:54 CEST 2020 by igor
|
||||
\* Created Fri Oct 11 15:45:11 CEST 2019 by igor
|
||||
171
spec/light-client/verification/Blockchain_A_1.tla
Normal file
@@ -0,0 +1,171 @@
|
||||
------------------------ MODULE Blockchain_A_1 -----------------------------
|
||||
(*
|
||||
This is a high-level specification of Tendermint blockchain
|
||||
that is designed specifically for the light client.
|
||||
Validators have the voting power of one. If you like to model various
|
||||
voting powers, introduce multiple copies of the same validator
|
||||
(do not forget to give them unique names though).
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
Min(a, b) == IF a < b THEN a ELSE b
|
||||
|
||||
CONSTANT
|
||||
AllNodes,
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
ULTIMATE_HEIGHT,
|
||||
(* a maximal height that can be ever reached (modelling artifact) *)
|
||||
TRUSTING_PERIOD
|
||||
(* the period within which the validators are trusted *)
|
||||
|
||||
Heights == 1..ULTIMATE_HEIGHT (* possible heights *)
|
||||
|
||||
(* A commit is just a set of nodes who have committed the block *)
|
||||
Commits == SUBSET AllNodes
|
||||
|
||||
(* The set of all block headers that can be on the blockchain.
|
||||
This is a simplified version of the Block data structure in the actual implementation. *)
|
||||
BlockHeaders == [
|
||||
height: Heights,
|
||||
\* the block height
|
||||
time: Int,
|
||||
\* the block timestamp in some integer units
|
||||
lastCommit: Commits,
|
||||
\* the nodes who have voted on the previous block, the set itself instead of a hash
|
||||
(* in the implementation, only the hashes of V and NextV are stored in a block,
|
||||
as V and NextV are stored in the application state *)
|
||||
VS: SUBSET AllNodes,
|
||||
\* the validators of this bloc. We store the validators instead of the hash.
|
||||
NextVS: SUBSET AllNodes
|
||||
\* the validators of the next block. We store the next validators instead of the hash.
|
||||
]
|
||||
|
||||
(* A signed header is just a header together with a set of commits *)
|
||||
LightBlocks == [header: BlockHeaders, Commits: Commits]
|
||||
|
||||
VARIABLES
|
||||
now,
|
||||
(* the current global time in integer units *)
|
||||
blockchain,
|
||||
(* A sequence of BlockHeaders, which gives us a bird view of the blockchain. *)
|
||||
Faulty
|
||||
(* A set of faulty nodes, which can act as validators. We assume that the set
|
||||
of faulty processes is non-decreasing. If a process has recovered, it should
|
||||
connect using a different id. *)
|
||||
|
||||
(* all variables, to be used with UNCHANGED *)
|
||||
vars == <<now, blockchain, Faulty>>
|
||||
|
||||
(* The set of all correct nodes in a state *)
|
||||
Corr == AllNodes \ Faulty
|
||||
|
||||
(* APALACHE annotations *)
|
||||
a <: b == a \* type annotation
|
||||
|
||||
NT == STRING
|
||||
NodeSet(S) == S <: {NT}
|
||||
EmptyNodeSet == NodeSet({})
|
||||
|
||||
BT == [height |-> Int, time |-> Int, lastCommit |-> {NT}, VS |-> {NT}, NextVS |-> {NT}]
|
||||
|
||||
LBT == [header |-> BT, Commits |-> {NT}]
|
||||
(* end of APALACHE annotations *)
|
||||
|
||||
(****************************** BLOCKCHAIN ************************************)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriod(header) ==
|
||||
now <= header.time + TRUSTING_PERIOD
|
||||
|
||||
(*
|
||||
Given a function pVotingPower \in D -> Powers for some D \subseteq AllNodes
|
||||
and pNodes \subseteq D, test whether the set pNodes \subseteq AllNodes has
|
||||
more than 2/3 of voting power among the nodes in D.
|
||||
*)
|
||||
TwoThirds(pVS, pNodes) ==
|
||||
LET TP == Cardinality(pVS)
|
||||
SP == Cardinality(pVS \intersect pNodes)
|
||||
IN
|
||||
3 * SP > 2 * TP \* when thinking in real numbers, not integers: SP > 2.0 / 3.0 * TP
|
||||
|
||||
(*
|
||||
Given a set of FaultyNodes, test whether the voting power of the correct nodes in D
|
||||
is more than 2/3 of the voting power of the faulty nodes in D.
|
||||
*)
|
||||
IsCorrectPower(pFaultyNodes, pVS) ==
|
||||
LET FN == pFaultyNodes \intersect pVS \* faulty nodes in pNodes
|
||||
CN == pVS \ pFaultyNodes \* correct nodes in pNodes
|
||||
CP == Cardinality(CN) \* power of the correct nodes
|
||||
FP == Cardinality(FN) \* power of the faulty nodes
|
||||
IN
|
||||
\* CP + FP = TP is the total voting power, so we write CP > 2.0 / 3 * TP as follows:
|
||||
CP > 2 * FP \* Note: when FP = 0, this implies CP > 0.
|
||||
|
||||
(* This is what we believe is the assumption about failures in Tendermint *)
|
||||
FaultAssumption(pFaultyNodes, pNow, pBlockchain) ==
|
||||
\A h \in Heights:
|
||||
pBlockchain[h].time + TRUSTING_PERIOD > pNow =>
|
||||
IsCorrectPower(pFaultyNodes, pBlockchain[h].NextVS)
|
||||
|
||||
(* Can a block be produced by a correct peer, or an authenticated Byzantine peer *)
|
||||
IsLightBlockAllowedByDigitalSignatures(ht, block) ==
|
||||
\/ block.header = blockchain[ht] \* signed by correct and faulty (maybe)
|
||||
\/ block.Commits \subseteq Faulty /\ block.header.height = ht \* signed only by faulty
|
||||
|
||||
(*
|
||||
Initialize the blockchain to the ultimate height right in the initial states.
|
||||
We pick the faulty validators statically, but that should not affect the light client.
|
||||
*)
|
||||
InitToHeight ==
|
||||
/\ Faulty \in SUBSET AllNodes \* some nodes may fail
|
||||
\* pick the validator sets and last commits
|
||||
/\ \E vs, lastCommit \in [Heights -> SUBSET AllNodes]:
|
||||
\E timestamp \in [Heights -> Int]:
|
||||
\* now is at least as early as the timestamp in the last block
|
||||
/\ \E tm \in Int: now = tm /\ tm >= timestamp[ULTIMATE_HEIGHT]
|
||||
\* the genesis starts on day 1
|
||||
/\ timestamp[1] = 1
|
||||
/\ vs[1] = AllNodes
|
||||
/\ lastCommit[1] = EmptyNodeSet
|
||||
/\ \A h \in Heights \ {1}:
|
||||
/\ lastCommit[h] \subseteq vs[h - 1] \* the non-validators cannot commit
|
||||
/\ TwoThirds(vs[h - 1], lastCommit[h]) \* the commit has >2/3 of validator votes
|
||||
/\ IsCorrectPower(Faulty, vs[h]) \* the correct validators have >2/3 of power
|
||||
/\ timestamp[h] > timestamp[h - 1] \* the time grows monotonically
|
||||
/\ timestamp[h] < timestamp[h - 1] + TRUSTING_PERIOD \* but not too fast
|
||||
\* form the block chain out of validator sets and commits (this makes apalache faster)
|
||||
/\ blockchain = [h \in Heights |->
|
||||
[height |-> h,
|
||||
time |-> timestamp[h],
|
||||
VS |-> vs[h],
|
||||
NextVS |-> IF h < ULTIMATE_HEIGHT THEN vs[h + 1] ELSE AllNodes,
|
||||
lastCommit |-> lastCommit[h]]
|
||||
] \******
|
||||
|
||||
|
||||
(* is the blockchain in the faulty zone where the Tendermint security model does not apply *)
|
||||
InFaultyZone ==
|
||||
~FaultAssumption(Faulty, now, blockchain)
|
||||
|
||||
(********************* BLOCKCHAIN ACTIONS ********************************)
|
||||
(*
|
||||
Advance the clock by zero or more time units.
|
||||
*)
|
||||
AdvanceTime ==
|
||||
\E tm \in Int: tm >= now /\ now' = tm
|
||||
/\ UNCHANGED <<blockchain, Faulty>>
|
||||
|
||||
(*
|
||||
One more process fails. As a result, the blockchain may move into the faulty zone.
|
||||
The light client is not using this action, as the faults are picked in the initial state.
|
||||
However, this action may be useful when reasoning about fork detection.
|
||||
*)
|
||||
OneMoreFault ==
|
||||
/\ \E n \in AllNodes \ Faulty:
|
||||
/\ Faulty' = Faulty \cup {n}
|
||||
/\ Faulty' /= AllNodes \* at least process remains non-faulty
|
||||
/\ UNCHANGED <<now, blockchain>>
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Wed Jun 10 14:10:54 CEST 2020 by igor
|
||||
\* Created Fri Oct 11 15:45:11 CEST 2019 by igor
|
||||
192
spec/light-client/verification/LCVerificationApi_003_draft.tla
Normal file
@@ -0,0 +1,192 @@
|
||||
-------------------- MODULE LCVerificationApi_003_draft --------------------------
|
||||
(**
|
||||
* The common interface of the light client verification and detection.
|
||||
*)
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
CLOCK_DRIFT,
|
||||
(* the assumed precision of the clock *)
|
||||
REAL_CLOCK_DRIFT,
|
||||
(* the actual clock drift, which under normal circumstances should not
|
||||
be larger than CLOCK_DRIFT (otherwise, there will be a bug) *)
|
||||
FAULTY_RATIO
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
|
||||
VARIABLES
|
||||
localClock (* current time as measured by the light client *)
|
||||
|
||||
(* the header is still within the trusting period *)
|
||||
InTrustingPeriodLocal(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - CLOCK_DRIFT
|
||||
|
||||
(* the header is still within the trusting period, even if the clock can go backwards *)
|
||||
InTrustingPeriodLocalSurely(header) ==
|
||||
\* note that the assumption about the drift reduces the period of trust
|
||||
localClock < header.time + TRUSTING_PERIOD - 2 * CLOCK_DRIFT
|
||||
|
||||
(* ensure that the local clock does not drift far away from the global clock *)
|
||||
IsLocalClockWithinDrift(local, global) ==
|
||||
/\ global - REAL_CLOCK_DRIFT <= local
|
||||
/\ local <= global + REAL_CLOCK_DRIFT
|
||||
|
||||
(**
|
||||
* Check that the commits in an untrusted block form 1/3 of the next validators
|
||||
* in a trusted header.
|
||||
*)
|
||||
SignedByOneThirdOfTrusted(trusted, untrusted) ==
|
||||
LET TP == Cardinality(trusted.header.NextVS)
|
||||
SP == Cardinality(untrusted.Commits \intersect trusted.header.NextVS)
|
||||
IN
|
||||
3 * SP > TP
|
||||
|
||||
(**
|
||||
The first part of the precondition of ValidAndVerified, which does not take
|
||||
the current time into account.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedPreUntimed(trusted, untrusted) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ thdr.height < uhdr.height
|
||||
\* the trusted block has been created earlier
|
||||
/\ thdr.time < uhdr.time
|
||||
/\ untrusted.Commits \subseteq uhdr.VS
|
||||
/\ LET TP == Cardinality(uhdr.VS)
|
||||
SP == Cardinality(untrusted.Commits)
|
||||
IN
|
||||
3 * SP > 2 * TP
|
||||
/\ thdr.height + 1 = uhdr.height => thdr.NextVS = uhdr.VS
|
||||
(* As we do not have explicit hashes we ignore these three checks of the English spec:
|
||||
|
||||
1. "trusted.Commit is a commit is for the header trusted.Header,
|
||||
i.e. it contains the correct hash of the header".
|
||||
2. untrusted.Validators = hash(untrusted.Header.Validators)
|
||||
3. untrusted.NextValidators = hash(untrusted.Header.NextValidators)
|
||||
*)
|
||||
|
||||
(**
|
||||
Check the precondition of ValidAndVerified, including the time checks.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE.1]
|
||||
*)
|
||||
ValidAndVerifiedPre(trusted, untrusted, checkFuture) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ InTrustingPeriodLocal(thdr)
|
||||
\* The untrusted block is not from the future (modulo clock drift).
|
||||
\* Do the check, if it is required.
|
||||
/\ checkFuture => uhdr.time < localClock + CLOCK_DRIFT
|
||||
/\ ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
This test does take current time into account, but only looks at the block structure.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-UNTIMED.1]
|
||||
*)
|
||||
ValidAndVerifiedUntimed(trusted, untrusted) ==
|
||||
IF ~ValidAndVerifiedPreUntimed(trusted, untrusted)
|
||||
THEN "INVALID"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA.1]
|
||||
*)
|
||||
ValidAndVerified(trusted, untrusted, checkFuture) ==
|
||||
IF ~ValidAndVerifiedPre(trusted, untrusted, checkFuture)
|
||||
THEN "INVALID"
|
||||
ELSE IF ~InTrustingPeriodLocal(untrusted.header)
|
||||
(* We leave the following test for the documentation purposes.
|
||||
The implementation should do this test, as signature verification may be slow.
|
||||
In the TLA+ specification, ValidAndVerified happens in no time.
|
||||
*)
|
||||
THEN "FAILED_TRUSTING_PERIOD"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
|
||||
(**
|
||||
The invariant of the light store that is not related to the blockchain
|
||||
*)
|
||||
LightStoreInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] /= "StateVerified"
|
||||
\/ lightBlockStatus[rh] /= "StateVerified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ LET lhdr == fetchedLightBlocks[lh]
|
||||
rhdr == fetchedLightBlocks[rh]
|
||||
IN
|
||||
\* we can verify the right one using the left one
|
||||
"SUCCESS" = ValidAndVerifiedUntimed(lhdr, rhdr)
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks.
|
||||
* (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus) ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
(**
|
||||
The expected post-condition of VerifyToTarget.
|
||||
*)
|
||||
VerifyToTargetPost(blockchain, isPeerCorrect,
|
||||
fetchedLightBlocks, lightBlockStatus,
|
||||
trustedHeight, targetHeight, finalState) ==
|
||||
LET trustedHeader == fetchedLightBlocks[trustedHeight].header IN
|
||||
\* The light client is not lying us on the trusted block.
|
||||
\* It is straightforward to detect.
|
||||
/\ lightBlockStatus[trustedHeight] = "StateVerified"
|
||||
/\ trustedHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ trustedHeader = blockchain[trustedHeight]
|
||||
\* the invariants we have found in the light client verification
|
||||
\* there is a problem with trusting period
|
||||
/\ isPeerCorrect
|
||||
=> CorrectnessInv(blockchain, fetchedLightBlocks, lightBlockStatus)
|
||||
\* a correct peer should fail the light client,
|
||||
\* if the trusted block is in the trusting period
|
||||
/\ isPeerCorrect /\ InTrustingPeriodLocalSurely(trustedHeader)
|
||||
=> finalState = "finishedSuccess"
|
||||
/\ finalState = "finishedSuccess" =>
|
||||
/\ lightBlockStatus[targetHeight] = "StateVerified"
|
||||
/\ targetHeight \in DOMAIN fetchedLightBlocks
|
||||
/\ NoFailedBlocksOnSuccessInv(fetchedLightBlocks, lightBlockStatus)
|
||||
/\ LightStoreInv(fetchedLightBlocks, lightBlockStatus)
|
||||
|
||||
|
||||
==================================================================================
|
||||
465
spec/light-client/verification/Lightclient_002_draft.tla
Normal file
@@ -0,0 +1,465 @@
|
||||
-------------------------- MODULE Lightclient_002_draft ----------------------------
|
||||
(**
|
||||
* A state-machine specification of the lite client, following the English spec:
|
||||
*
|
||||
* https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification.md
|
||||
*)
|
||||
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTED_HEIGHT,
|
||||
(* an index of the block header that the light client trusts by social consensus *)
|
||||
TARGET_HEIGHT,
|
||||
(* an index of the block header that the light client tries to verify *)
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
IS_PRIMARY_CORRECT
|
||||
(* is primary correct? *)
|
||||
|
||||
VARIABLES (* see TypeOK below for the variable types *)
|
||||
state, (* the current state of the light client *)
|
||||
nextHeight, (* the next height to explore by the light client *)
|
||||
nprobes (* the lite client iteration, or the number of block tests *)
|
||||
|
||||
(* the light store *)
|
||||
VARIABLES
|
||||
fetchedLightBlocks, (* a function from heights to LightBlocks *)
|
||||
lightBlockStatus, (* a function from heights to block statuses *)
|
||||
latestVerified (* the latest verified block *)
|
||||
|
||||
(* the variables of the lite client *)
|
||||
lcvars == <<state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevNow,
|
||||
prevVerdict
|
||||
|
||||
InitMonitor(verified, current, now, verdict) ==
|
||||
/\ prevVerified = verified
|
||||
/\ prevCurrent = current
|
||||
/\ prevNow = now
|
||||
/\ prevVerdict = verdict
|
||||
|
||||
NextMonitor(verified, current, now, verdict) ==
|
||||
/\ prevVerified' = verified
|
||||
/\ prevCurrent' = current
|
||||
/\ prevNow' = now
|
||||
/\ prevVerdict' = verdict
|
||||
|
||||
|
||||
(******************* Blockchain instance ***********************************)
|
||||
|
||||
\* the parameters that are propagated into Blockchain
|
||||
CONSTANTS
|
||||
AllNodes
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
|
||||
\* the state variables of Blockchain, see Blockchain.tla for the details
|
||||
VARIABLES now, blockchain, Faulty
|
||||
|
||||
\* All the variables of Blockchain. For some reason, BC!vars does not work
|
||||
bcvars == <<now, blockchain, Faulty>>
|
||||
|
||||
(* Create an instance of Blockchain.
|
||||
We could write EXTENDS Blockchain, but then all the constants and state variables
|
||||
would be hidden inside the Blockchain module.
|
||||
*)
|
||||
ULTIMATE_HEIGHT == TARGET_HEIGHT + 1
|
||||
|
||||
BC == INSTANCE Blockchain_002_draft WITH
|
||||
now <- now, blockchain <- blockchain, Faulty <- Faulty
|
||||
|
||||
(************************** Lite client ************************************)
|
||||
|
||||
(* the heights on which the light client is working *)
|
||||
HEIGHTS == TRUSTED_HEIGHT..TARGET_HEIGHT
|
||||
|
||||
(* the control states of the lite client *)
|
||||
States == { "working", "finishedSuccess", "finishedFailure" }
|
||||
|
||||
(**
|
||||
Check the precondition of ValidAndVerified.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE.1]
|
||||
*)
|
||||
ValidAndVerifiedPre(trusted, untrusted) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ BC!InTrustingPeriod(thdr)
|
||||
/\ thdr.height < uhdr.height
|
||||
\* the trusted block has been created earlier (no drift here)
|
||||
/\ thdr.time < uhdr.time
|
||||
\* the untrusted block is not from the future
|
||||
/\ uhdr.time < now
|
||||
/\ untrusted.Commits \subseteq uhdr.VS
|
||||
/\ LET TP == Cardinality(uhdr.VS)
|
||||
SP == Cardinality(untrusted.Commits)
|
||||
IN
|
||||
3 * SP > 2 * TP
|
||||
/\ thdr.height + 1 = uhdr.height => thdr.NextVS = uhdr.VS
|
||||
(* As we do not have explicit hashes we ignore these three checks of the English spec:
|
||||
|
||||
1. "trusted.Commit is a commit is for the header trusted.Header,
|
||||
i.e. it contains the correct hash of the header".
|
||||
2. untrusted.Validators = hash(untrusted.Header.Validators)
|
||||
3. untrusted.NextValidators = hash(untrusted.Header.NextValidators)
|
||||
*)
|
||||
|
||||
(**
|
||||
* Check that the commits in an untrusted block form 1/3 of the next validators
|
||||
* in a trusted header.
|
||||
*)
|
||||
SignedByOneThirdOfTrusted(trusted, untrusted) ==
|
||||
LET TP == Cardinality(trusted.header.NextVS)
|
||||
SP == Cardinality(untrusted.Commits \intersect trusted.header.NextVS)
|
||||
IN
|
||||
3 * SP > TP
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA.1]
|
||||
*)
|
||||
ValidAndVerified(trusted, untrusted) ==
|
||||
IF ~ValidAndVerifiedPre(trusted, untrusted)
|
||||
THEN "INVALID"
|
||||
ELSE IF ~BC!InTrustingPeriod(untrusted.header)
|
||||
(* We leave the following test for the documentation purposes.
|
||||
The implementation should do this test, as signature verification may be slow.
|
||||
In the TLA+ specification, ValidAndVerified happens in no time.
|
||||
*)
|
||||
THEN "FAILED_TRUSTING_PERIOD"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "SUCCESS"
|
||||
ELSE "NOT_ENOUGH_TRUST"
|
||||
|
||||
(*
|
||||
Initial states of the light client.
|
||||
Initially, only the trusted light block is present.
|
||||
*)
|
||||
LCInit ==
|
||||
/\ state = "working"
|
||||
/\ nextHeight = TARGET_HEIGHT
|
||||
/\ nprobes = 0 \* no tests have been done so far
|
||||
/\ LET trustedBlock == blockchain[TRUSTED_HEIGHT]
|
||||
trustedLightBlock == [header |-> trustedBlock, Commits |-> AllNodes]
|
||||
IN
|
||||
\* initially, fetchedLightBlocks is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ fetchedLightBlocks = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
|
||||
\* initially, lightBlockStatus is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ lightBlockStatus = [h \in {TRUSTED_HEIGHT} |-> "StateVerified"]
|
||||
\* the latest verified block the the trusted block
|
||||
/\ latestVerified = trustedLightBlock
|
||||
/\ InitMonitor(trustedLightBlock, trustedLightBlock, now, "SUCCESS")
|
||||
|
||||
\* block should contain a copy of the block from the reference chain, with a matching commit
|
||||
CopyLightBlockFromChain(block, height) ==
|
||||
LET ref == blockchain[height]
|
||||
lastCommit ==
|
||||
IF height < ULTIMATE_HEIGHT
|
||||
THEN blockchain[height + 1].lastCommit
|
||||
\* for the ultimate block, which we never use, as ULTIMATE_HEIGHT = TARGET_HEIGHT + 1
|
||||
ELSE blockchain[height].VS
|
||||
IN
|
||||
block = [header |-> ref, Commits |-> lastCommit]
|
||||
|
||||
\* Either the primary is correct and the block comes from the reference chain,
|
||||
\* or the block is produced by a faulty primary.
|
||||
\*
|
||||
\* [LCV-FUNC-FETCH.1::TLA.1]
|
||||
FetchLightBlockInto(block, height) ==
|
||||
IF IS_PRIMARY_CORRECT
|
||||
THEN CopyLightBlockFromChain(block, height)
|
||||
ELSE BC!IsLightBlockAllowedByDigitalSignatures(height, block)
|
||||
|
||||
\* add a block into the light store
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateBlocks(lightBlocks, block) ==
|
||||
LET ht == block.header.height IN
|
||||
[h \in DOMAIN lightBlocks \union {ht} |->
|
||||
IF h = ht THEN block ELSE lightBlocks[h]]
|
||||
|
||||
\* update the state of a light block
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateStates(statuses, ht, blockState) ==
|
||||
[h \in DOMAIN statuses \union {ht} |->
|
||||
IF h = ht THEN blockState ELSE statuses[h]]
|
||||
|
||||
\* Check, whether newHeight is a possible next height for the light client.
|
||||
\*
|
||||
\* [LCV-FUNC-SCHEDULE.1::TLA.1]
|
||||
CanScheduleTo(newHeight, pLatestVerified, pNextHeight, pTargetHeight) ==
|
||||
LET ht == pLatestVerified.header.height IN
|
||||
\/ /\ ht = pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ pNextHeight < newHeight
|
||||
/\ newHeight <= pTargetHeight
|
||||
\/ /\ ht < pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ ht < newHeight
|
||||
/\ newHeight < pNextHeight
|
||||
\/ /\ ht = pTargetHeight
|
||||
/\ newHeight = pTargetHeight
|
||||
|
||||
\* The loop of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOP.1]
|
||||
VerifyToTargetLoop ==
|
||||
\* the loop condition is true
|
||||
/\ latestVerified.header.height < TARGET_HEIGHT
|
||||
\* pick a light block, which will be constrained later
|
||||
/\ \E current \in BC!LightBlocks:
|
||||
\* Get next LightBlock for verification
|
||||
/\ IF nextHeight \in DOMAIN fetchedLightBlocks
|
||||
THEN \* copy the block from the light store
|
||||
/\ current = fetchedLightBlocks[nextHeight]
|
||||
/\ UNCHANGED fetchedLightBlocks
|
||||
ELSE \* retrieve a light block and save it in the light store
|
||||
/\ FetchLightBlockInto(current, nextHeight)
|
||||
/\ fetchedLightBlocks' = LightStoreUpdateBlocks(fetchedLightBlocks, current)
|
||||
\* Record that one more probe has been done (for complexity and model checking)
|
||||
/\ nprobes' = nprobes + 1
|
||||
\* Verify the current block
|
||||
/\ LET verdict == ValidAndVerified(latestVerified, current) IN
|
||||
NextMonitor(latestVerified, current, now, verdict) /\
|
||||
\* Decide whether/how to continue
|
||||
CASE verdict = "SUCCESS" ->
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateVerified")
|
||||
/\ latestVerified' = current
|
||||
/\ state' =
|
||||
IF latestVerified'.header.height < TARGET_HEIGHT
|
||||
THEN "working"
|
||||
ELSE "finishedSuccess"
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, current, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
|
||||
[] verdict = "NOT_ENOUGH_TRUST" ->
|
||||
(*
|
||||
do nothing: the light block current passed validation, but the validator
|
||||
set is too different to verify it. We keep the state of
|
||||
current at StateUnverified. For a later iteration, Schedule
|
||||
might decide to try verification of that light block again.
|
||||
*)
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateUnverified")
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, latestVerified, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
/\ UNCHANGED <<latestVerified, state>>
|
||||
|
||||
[] OTHER ->
|
||||
\* verdict is some error code
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateFailed")
|
||||
/\ state' = "finishedFailure"
|
||||
/\ UNCHANGED <<latestVerified, nextHeight>>
|
||||
|
||||
\* The terminating condition of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOPCOND.1]
|
||||
VerifyToTargetDone ==
|
||||
/\ latestVerified.header.height >= TARGET_HEIGHT
|
||||
/\ state' = "finishedSuccess"
|
||||
/\ UNCHANGED <<nextHeight, nprobes, fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
/\ UNCHANGED <<prevVerified, prevCurrent, prevNow, prevVerdict>>
|
||||
|
||||
(********************* Lite client + Blockchain *******************)
|
||||
Init ==
|
||||
\* the blockchain is initialized immediately to the ULTIMATE_HEIGHT
|
||||
/\ BC!InitToHeight
|
||||
\* the light client starts
|
||||
/\ LCInit
|
||||
|
||||
(*
|
||||
The system step is very simple.
|
||||
The light client is either executing VerifyToTarget, or it has terminated.
|
||||
(In the latter case, a model checker reports a deadlock.)
|
||||
Simultaneously, the global clock may advance.
|
||||
*)
|
||||
Next ==
|
||||
/\ state = "working"
|
||||
/\ VerifyToTargetLoop \/ VerifyToTargetDone
|
||||
/\ BC!AdvanceTime \* the global clock is advanced by zero or more time units
|
||||
|
||||
(************************* Types ******************************************)
|
||||
TypeOK ==
|
||||
/\ state \in States
|
||||
/\ nextHeight \in HEIGHTS
|
||||
/\ latestVerified \in BC!LightBlocks
|
||||
/\ \E HS \in SUBSET HEIGHTS:
|
||||
/\ fetchedLightBlocks \in [HS -> BC!LightBlocks]
|
||||
/\ lightBlockStatus
|
||||
\in [HS -> {"StateVerified", "StateUnverified", "StateFailed"}]
|
||||
|
||||
(************************* Properties ******************************************)
|
||||
|
||||
(* The properties to check *)
|
||||
\* this invariant candidate is false
|
||||
NeverFinish ==
|
||||
state = "working"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishNegative ==
|
||||
state /= "finishedFailure"
|
||||
|
||||
\* This invariant holds true, when the primary is correct.
|
||||
\* This invariant candidate is false when the primary is faulty.
|
||||
NeverFinishNegativeWhenTrusted ==
|
||||
(*(minTrustedHeight <= TRUSTED_HEIGHT)*)
|
||||
BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
=> state /= "finishedFailure"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishPositive ==
|
||||
state /= "finishedSuccess"
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
Check that the sequence of the headers in storedLightBlocks satisfies ValidAndVerified = "SUCCESS" pairwise
|
||||
This property is easily violated, whenever a header cannot be trusted anymore.
|
||||
*)
|
||||
StoredHeadersAreVerifiedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
|
||||
\* An improved version of StoredHeadersAreSound, assuming that a header may be not trusted.
|
||||
\* This invariant candidate is also violated,
|
||||
\* as there may be some unverified blocks left in the middle.
|
||||
StoredHeadersAreVerifiedOrNotTrustedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~BC!InTrustingPeriod(fetchedLightBlocks[lh].header)
|
||||
|
||||
(**
|
||||
* An improved version of StoredHeadersAreSoundOrNotTrusted,
|
||||
* checking the property only for the verified headers.
|
||||
* This invariant holds true.
|
||||
*)
|
||||
ProofOfChainOfTrustInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] = "StateUnverified"
|
||||
\/ lightBlockStatus[rh] = "StateUnverified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~(BC!InTrustingPeriod(fetchedLightBlocks[lh].header))
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks. (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv ==
|
||||
state = "finishedSuccess" =>
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
\* This property states that whenever the light client finishes with a positive outcome,
|
||||
\* the trusted header is still within the trusting period.
|
||||
\* We expect this property to be violated. And Apalache shows us a counterexample.
|
||||
PositiveBeforeTrustedHeaderExpires ==
|
||||
(state = "finishedSuccess") => BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
|
||||
\* If the primary is correct and the initial trusted block has not expired,
|
||||
\* then whenever the algorithm terminates, it reports "success"
|
||||
CorrectPrimaryAndTimeliness ==
|
||||
(BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
(**
|
||||
If the primary is correct and there is a trusted block that has not expired,
|
||||
then whenever the algorithm terminates, it reports "success".
|
||||
|
||||
[LCV-DIST-LIVE.1::SUCCESS-CORR-PRIMARY-CHAIN-OF-TRUST.1]
|
||||
*)
|
||||
SuccessOnCorrectPrimaryAndChainOfTrust ==
|
||||
(\E h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" /\ BC!InTrustingPeriod(blockchain[h])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
\* Lite Client Completeness: If header h was correctly generated by an instance
|
||||
\* of Tendermint consensus (and its age is less than the trusting period),
|
||||
\* then the lite client should eventually set trust(h) to true.
|
||||
\*
|
||||
\* Note that Completeness assumes that the lite client communicates with a correct full node.
|
||||
\*
|
||||
\* We decompose completeness into Termination (liveness) and Precision (safety).
|
||||
\* Once again, Precision is an inverse version of the safety property in Completeness,
|
||||
\* as A => B is logically equivalent to ~B => ~A.
|
||||
PrecisionInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
\/ lightBlock.header /= blockchain[h]
|
||||
\* the full node lied to the lite client about the commits
|
||||
\/ lightBlock.Commits /= lightBlock.header.VS
|
||||
|
||||
\* the old invariant that was found to be buggy by TLC
|
||||
PrecisionBuggyInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
lightBlock.header /= blockchain[h]
|
||||
|
||||
\* the worst complexity
|
||||
Complexity ==
|
||||
LET N == TARGET_HEIGHT - TRUSTED_HEIGHT + 1 IN
|
||||
state /= "working" =>
|
||||
(2 * nprobes <= N * (N - 1))
|
||||
|
||||
(*
|
||||
We omit termination, as the algorithm deadlocks in the end.
|
||||
So termination can be demonstrated by finding a deadlock.
|
||||
Of course, one has to analyze the deadlocked state and see that
|
||||
the algorithm has indeed terminated there.
|
||||
*)
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Fri Jun 26 12:08:28 CEST 2020 by igor
|
||||
\* Created Wed Oct 02 16:39:42 CEST 2019 by igor
|
||||
493
spec/light-client/verification/Lightclient_003_draft.tla
Normal file
@@ -0,0 +1,493 @@
|
||||
-------------------------- MODULE Lightclient_003_draft ----------------------------
|
||||
(**
|
||||
* A state-machine specification of the lite client verification,
|
||||
* following the English spec:
|
||||
*
|
||||
* https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification.md
|
||||
*)
|
||||
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTED_HEIGHT,
|
||||
(* an index of the block header that the light client trusts by social consensus *)
|
||||
TARGET_HEIGHT,
|
||||
(* an index of the block header that the light client tries to verify *)
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
CLOCK_DRIFT,
|
||||
(* the assumed precision of the clock *)
|
||||
REAL_CLOCK_DRIFT,
|
||||
(* the actual clock drift, which under normal circumstances should not
|
||||
be larger than CLOCK_DRIFT (otherwise, there will be a bug) *)
|
||||
IS_PRIMARY_CORRECT,
|
||||
(* is primary correct? *)
|
||||
FAULTY_RATIO
|
||||
(* a pair <<a, b>> that limits that ratio of faulty validator in the blockchain
|
||||
from above (exclusive). Tendermint security model prescribes 1 / 3. *)
|
||||
|
||||
VARIABLES (* see TypeOK below for the variable types *)
|
||||
localClock, (* the local clock of the light client *)
|
||||
state, (* the current state of the light client *)
|
||||
nextHeight, (* the next height to explore by the light client *)
|
||||
nprobes (* the lite client iteration, or the number of block tests *)
|
||||
|
||||
(* the light store *)
|
||||
VARIABLES
|
||||
fetchedLightBlocks, (* a function from heights to LightBlocks *)
|
||||
lightBlockStatus, (* a function from heights to block statuses *)
|
||||
latestVerified (* the latest verified block *)
|
||||
|
||||
(* the variables of the lite client *)
|
||||
lcvars == <<localClock, state, nextHeight,
|
||||
fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
InitMonitor(verified, current, pLocalClock, verdict) ==
|
||||
/\ prevVerified = verified
|
||||
/\ prevCurrent = current
|
||||
/\ prevLocalClock = pLocalClock
|
||||
/\ prevVerdict = verdict
|
||||
|
||||
NextMonitor(verified, current, pLocalClock, verdict) ==
|
||||
/\ prevVerified' = verified
|
||||
/\ prevCurrent' = current
|
||||
/\ prevLocalClock' = pLocalClock
|
||||
/\ prevVerdict' = verdict
|
||||
|
||||
|
||||
(******************* Blockchain instance ***********************************)
|
||||
|
||||
\* the parameters that are propagated into Blockchain
|
||||
CONSTANTS
|
||||
AllNodes
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
|
||||
\* the state variables of Blockchain, see Blockchain.tla for the details
|
||||
VARIABLES refClock, blockchain, Faulty
|
||||
|
||||
\* All the variables of Blockchain. For some reason, BC!vars does not work
|
||||
bcvars == <<refClock, blockchain, Faulty>>
|
||||
|
||||
(* Create an instance of Blockchain.
|
||||
We could write EXTENDS Blockchain, but then all the constants and state variables
|
||||
would be hidden inside the Blockchain module.
|
||||
*)
|
||||
ULTIMATE_HEIGHT == TARGET_HEIGHT + 1
|
||||
|
||||
BC == INSTANCE Blockchain_003_draft WITH
|
||||
refClock <- refClock, blockchain <- blockchain, Faulty <- Faulty
|
||||
|
||||
(************************** Lite client ************************************)
|
||||
|
||||
(* the heights on which the light client is working *)
|
||||
HEIGHTS == TRUSTED_HEIGHT..TARGET_HEIGHT
|
||||
|
||||
(* the control states of the lite client *)
|
||||
States == { "working", "finishedSuccess", "finishedFailure" }
|
||||
|
||||
\* The verification functions are implemented in the API
|
||||
API == INSTANCE LCVerificationApi_003_draft
|
||||
|
||||
|
||||
(*
|
||||
Initial states of the light client.
|
||||
Initially, only the trusted light block is present.
|
||||
*)
|
||||
LCInit ==
|
||||
/\ \E tm \in Int:
|
||||
tm >= 0 /\ API!IsLocalClockWithinDrift(tm, refClock) /\ localClock = tm
|
||||
/\ state = "working"
|
||||
/\ nextHeight = TARGET_HEIGHT
|
||||
/\ nprobes = 0 \* no tests have been done so far
|
||||
/\ LET trustedBlock == blockchain[TRUSTED_HEIGHT]
|
||||
trustedLightBlock == [header |-> trustedBlock, Commits |-> AllNodes]
|
||||
IN
|
||||
\* initially, fetchedLightBlocks is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ fetchedLightBlocks = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
|
||||
\* initially, lightBlockStatus is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ lightBlockStatus = [h \in {TRUSTED_HEIGHT} |-> "StateVerified"]
|
||||
\* the latest verified block the the trusted block
|
||||
/\ latestVerified = trustedLightBlock
|
||||
/\ InitMonitor(trustedLightBlock, trustedLightBlock, localClock, "SUCCESS")
|
||||
|
||||
\* block should contain a copy of the block from the reference chain, with a matching commit
|
||||
CopyLightBlockFromChain(block, height) ==
|
||||
LET ref == blockchain[height]
|
||||
lastCommit ==
|
||||
IF height < ULTIMATE_HEIGHT
|
||||
THEN blockchain[height + 1].lastCommit
|
||||
\* for the ultimate block, which we never use, as ULTIMATE_HEIGHT = TARGET_HEIGHT + 1
|
||||
ELSE blockchain[height].VS
|
||||
IN
|
||||
block = [header |-> ref, Commits |-> lastCommit]
|
||||
|
||||
\* Either the primary is correct and the block comes from the reference chain,
|
||||
\* or the block is produced by a faulty primary.
|
||||
\*
|
||||
\* [LCV-FUNC-FETCH.1::TLA.1]
|
||||
FetchLightBlockInto(block, height) ==
|
||||
IF IS_PRIMARY_CORRECT
|
||||
THEN CopyLightBlockFromChain(block, height)
|
||||
ELSE BC!IsLightBlockAllowedByDigitalSignatures(height, block)
|
||||
|
||||
\* add a block into the light store
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateBlocks(lightBlocks, block) ==
|
||||
LET ht == block.header.height IN
|
||||
[h \in DOMAIN lightBlocks \union {ht} |->
|
||||
IF h = ht THEN block ELSE lightBlocks[h]]
|
||||
|
||||
\* update the state of a light block
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateStates(statuses, ht, blockState) ==
|
||||
[h \in DOMAIN statuses \union {ht} |->
|
||||
IF h = ht THEN blockState ELSE statuses[h]]
|
||||
|
||||
\* Check, whether newHeight is a possible next height for the light client.
|
||||
\*
|
||||
\* [LCV-FUNC-SCHEDULE.1::TLA.1]
|
||||
CanScheduleTo(newHeight, pLatestVerified, pNextHeight, pTargetHeight) ==
|
||||
LET ht == pLatestVerified.header.height IN
|
||||
\/ /\ ht = pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ pNextHeight < newHeight
|
||||
/\ newHeight <= pTargetHeight
|
||||
\/ /\ ht < pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ ht < newHeight
|
||||
/\ newHeight < pNextHeight
|
||||
\/ /\ ht = pTargetHeight
|
||||
/\ newHeight = pTargetHeight
|
||||
|
||||
\* The loop of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOP.1]
|
||||
VerifyToTargetLoop ==
|
||||
\* the loop condition is true
|
||||
/\ latestVerified.header.height < TARGET_HEIGHT
|
||||
\* pick a light block, which will be constrained later
|
||||
/\ \E current \in BC!LightBlocks:
|
||||
\* Get next LightBlock for verification
|
||||
/\ IF nextHeight \in DOMAIN fetchedLightBlocks
|
||||
THEN \* copy the block from the light store
|
||||
/\ current = fetchedLightBlocks[nextHeight]
|
||||
/\ UNCHANGED fetchedLightBlocks
|
||||
ELSE \* retrieve a light block and save it in the light store
|
||||
/\ FetchLightBlockInto(current, nextHeight)
|
||||
/\ fetchedLightBlocks' = LightStoreUpdateBlocks(fetchedLightBlocks, current)
|
||||
\* Record that one more probe has been done (for complexity and model checking)
|
||||
/\ nprobes' = nprobes + 1
|
||||
\* Verify the current block
|
||||
/\ LET verdict == API!ValidAndVerified(latestVerified, current, TRUE) IN
|
||||
NextMonitor(latestVerified, current, localClock, verdict) /\
|
||||
\* Decide whether/how to continue
|
||||
CASE verdict = "SUCCESS" ->
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateVerified")
|
||||
/\ latestVerified' = current
|
||||
/\ state' =
|
||||
IF latestVerified'.header.height < TARGET_HEIGHT
|
||||
THEN "working"
|
||||
ELSE "finishedSuccess"
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, current, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
|
||||
[] verdict = "NOT_ENOUGH_TRUST" ->
|
||||
(*
|
||||
do nothing: the light block current passed validation, but the validator
|
||||
set is too different to verify it. We keep the state of
|
||||
current at StateUnverified. For a later iteration, Schedule
|
||||
might decide to try verification of that light block again.
|
||||
*)
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateUnverified")
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, latestVerified, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
/\ UNCHANGED <<latestVerified, state>>
|
||||
|
||||
[] OTHER ->
|
||||
\* verdict is some error code
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateFailed")
|
||||
/\ state' = "finishedFailure"
|
||||
/\ UNCHANGED <<latestVerified, nextHeight>>
|
||||
|
||||
\* The terminating condition of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOPCOND.1]
|
||||
VerifyToTargetDone ==
|
||||
/\ latestVerified.header.height >= TARGET_HEIGHT
|
||||
/\ state' = "finishedSuccess"
|
||||
/\ UNCHANGED <<nextHeight, nprobes, fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
/\ UNCHANGED <<prevVerified, prevCurrent, prevLocalClock, prevVerdict>>
|
||||
|
||||
(*
|
||||
The local and global clocks can be updated. They can also drift from each other.
|
||||
Note that the local clock can actually go backwards in time.
|
||||
However, it still stays in the drift envelope
|
||||
of [refClock - REAL_CLOCK_DRIFT, refClock + REAL_CLOCK_DRIFT].
|
||||
*)
|
||||
AdvanceClocks ==
|
||||
/\ BC!AdvanceTime
|
||||
/\ \E tm \in Int:
|
||||
/\ tm >= 0
|
||||
/\ API!IsLocalClockWithinDrift(tm, refClock')
|
||||
/\ localClock' = tm
|
||||
\* if you like the clock to always grow monotonically, uncomment the next line:
|
||||
\*/\ localClock' > localClock
|
||||
|
||||
(********************* Lite client + Blockchain *******************)
|
||||
Init ==
|
||||
\* the blockchain is initialized immediately to the ULTIMATE_HEIGHT
|
||||
/\ BC!InitToHeight(FAULTY_RATIO)
|
||||
\* the light client starts
|
||||
/\ LCInit
|
||||
|
||||
(*
|
||||
The system step is very simple.
|
||||
The light client is either executing VerifyToTarget, or it has terminated.
|
||||
(In the latter case, a model checker reports a deadlock.)
|
||||
Simultaneously, the global clock may advance.
|
||||
*)
|
||||
Next ==
|
||||
/\ state = "working"
|
||||
/\ VerifyToTargetLoop \/ VerifyToTargetDone
|
||||
/\ AdvanceClocks
|
||||
|
||||
(************************* Types ******************************************)
|
||||
TypeOK ==
|
||||
/\ state \in States
|
||||
/\ localClock \in Nat
|
||||
/\ refClock \in Nat
|
||||
/\ nextHeight \in HEIGHTS
|
||||
/\ latestVerified \in BC!LightBlocks
|
||||
/\ \E HS \in SUBSET HEIGHTS:
|
||||
/\ fetchedLightBlocks \in [HS -> BC!LightBlocks]
|
||||
/\ lightBlockStatus
|
||||
\in [HS -> {"StateVerified", "StateUnverified", "StateFailed"}]
|
||||
|
||||
(************************* Properties ******************************************)
|
||||
|
||||
(* The properties to check *)
|
||||
\* this invariant candidate is false
|
||||
NeverFinish ==
|
||||
state = "working"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishNegative ==
|
||||
state /= "finishedFailure"
|
||||
|
||||
\* This invariant holds true, when the primary is correct.
|
||||
\* This invariant candidate is false when the primary is faulty.
|
||||
NeverFinishNegativeWhenTrusted ==
|
||||
BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
=> state /= "finishedFailure"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishPositive ==
|
||||
state /= "finishedSuccess"
|
||||
|
||||
|
||||
(**
|
||||
Check that the target height has been reached upon successful termination.
|
||||
*)
|
||||
TargetHeightOnSuccessInv ==
|
||||
state = "finishedSuccess" =>
|
||||
/\ TARGET_HEIGHT \in DOMAIN fetchedLightBlocks
|
||||
/\ lightBlockStatus[TARGET_HEIGHT] = "StateVerified"
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
No faulty block was used to construct a proof. This invariant holds,
|
||||
only if FAULTY_RATIO < 1/3.
|
||||
*)
|
||||
NoTrustOnFaultyBlockInv ==
|
||||
(state = "finishedSuccess"
|
||||
/\ fetchedLightBlocks[TARGET_HEIGHT].header = blockchain[TARGET_HEIGHT])
|
||||
=> CorrectnessInv
|
||||
|
||||
(**
|
||||
Check that the sequence of the headers in storedLightBlocks satisfies ValidAndVerified = "SUCCESS" pairwise
|
||||
This property is easily violated, whenever a header cannot be trusted anymore.
|
||||
*)
|
||||
StoredHeadersAreVerifiedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = API!ValidAndVerified(fetchedLightBlocks[lh],
|
||||
fetchedLightBlocks[rh], FALSE)
|
||||
|
||||
\* An improved version of StoredHeadersAreVerifiedInv,
|
||||
\* assuming that a header may be not trusted.
|
||||
\* This invariant candidate is also violated,
|
||||
\* as there may be some unverified blocks left in the middle.
|
||||
\* This property is violated under two conditions:
|
||||
\* (1) the primary is faulty and there are at least 4 blocks,
|
||||
\* (2) the primary is correct and there are at least 5 blocks.
|
||||
StoredHeadersAreVerifiedOrNotTrustedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = API!ValidAndVerified(fetchedLightBlocks[lh],
|
||||
fetchedLightBlocks[rh], FALSE)
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~API!InTrustingPeriodLocal(fetchedLightBlocks[lh].header)
|
||||
|
||||
(**
|
||||
* An improved version of StoredHeadersAreSoundOrNotTrusted,
|
||||
* checking the property only for the verified headers.
|
||||
* This invariant holds true if CLOCK_DRIFT <= REAL_CLOCK_DRIFT.
|
||||
*)
|
||||
ProofOfChainOfTrustInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] = "StateUnverified"
|
||||
\/ lightBlockStatus[rh] = "StateUnverified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~(API!InTrustingPeriodLocal(fetchedLightBlocks[lh].header))
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "SUCCESS" = API!ValidAndVerified(fetchedLightBlocks[lh],
|
||||
fetchedLightBlocks[rh], FALSE)
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks. (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv ==
|
||||
state = "finishedSuccess" =>
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
\* This property states that whenever the light client finishes with a positive outcome,
|
||||
\* the trusted header is still within the trusting period.
|
||||
\* We expect this property to be violated. And Apalache shows us a counterexample.
|
||||
PositiveBeforeTrustedHeaderExpires ==
|
||||
(state = "finishedSuccess") =>
|
||||
BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
|
||||
\* If the primary is correct and the initial trusted block has not expired,
|
||||
\* then whenever the algorithm terminates, it reports "success".
|
||||
\* This property fails.
|
||||
CorrectPrimaryAndTimeliness ==
|
||||
(BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
(**
|
||||
If the primary is correct and there is a trusted block that has not expired,
|
||||
then whenever the algorithm terminates, it reports "success".
|
||||
This property only holds true, if the local clock is always growing monotonically.
|
||||
If the local clock can go backwards in the envelope
|
||||
[refClock - CLOCK_DRIFT, refClock + CLOCK_DRIFT], then the property fails.
|
||||
|
||||
[LCV-DIST-LIVE.1::SUCCESS-CORR-PRIMARY-CHAIN-OF-TRUST.1]
|
||||
*)
|
||||
SuccessOnCorrectPrimaryAndChainOfTrustLocal ==
|
||||
(\E h \in DOMAIN fetchedLightBlocks:
|
||||
/\ lightBlockStatus[h] = "StateVerified"
|
||||
/\ API!InTrustingPeriodLocal(blockchain[h])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
(**
|
||||
Similar to SuccessOnCorrectPrimaryAndChainOfTrust, but using the blockchain clock.
|
||||
It fails because the local clock of the client drifted away, so it rejects a block
|
||||
that has not expired yet (according to the local clock).
|
||||
*)
|
||||
SuccessOnCorrectPrimaryAndChainOfTrustGlobal ==
|
||||
(\E h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" /\ BC!InTrustingPeriod(blockchain[h])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
\* Lite Client Completeness: If header h was correctly generated by an instance
|
||||
\* of Tendermint consensus (and its age is less than the trusting period),
|
||||
\* then the lite client should eventually set trust(h) to true.
|
||||
\*
|
||||
\* Note that Completeness assumes that the lite client communicates with a correct full node.
|
||||
\*
|
||||
\* We decompose completeness into Termination (liveness) and Precision (safety).
|
||||
\* Once again, Precision is an inverse version of the safety property in Completeness,
|
||||
\* as A => B is logically equivalent to ~B => ~A.
|
||||
\*
|
||||
\* This property holds only when CLOCK_DRIFT = 0 and REAL_CLOCK_DRIFT = 0.
|
||||
PrecisionInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
\/ lightBlock.header /= blockchain[h]
|
||||
\* the full node lied to the lite client about the commits
|
||||
\/ lightBlock.Commits /= lightBlock.header.VS
|
||||
|
||||
\* the old invariant that was found to be buggy by TLC
|
||||
PrecisionBuggyInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
lightBlock.header /= blockchain[h]
|
||||
|
||||
\* the worst complexity
|
||||
Complexity ==
|
||||
LET N == TARGET_HEIGHT - TRUSTED_HEIGHT + 1 IN
|
||||
state /= "working" =>
|
||||
(2 * nprobes <= N * (N - 1))
|
||||
|
||||
(**
|
||||
If the light client has terminated, then the expected postcondition holds true.
|
||||
*)
|
||||
ApiPostInv ==
|
||||
state /= "working" =>
|
||||
API!VerifyToTargetPost(blockchain, IS_PRIMARY_CORRECT,
|
||||
fetchedLightBlocks, lightBlockStatus,
|
||||
TRUSTED_HEIGHT, TARGET_HEIGHT, state)
|
||||
|
||||
(*
|
||||
We omit termination, as the algorithm deadlocks in the end.
|
||||
So termination can be demonstrated by finding a deadlock.
|
||||
Of course, one has to analyze the deadlocked state and see that
|
||||
the algorithm has indeed terminated there.
|
||||
*)
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Fri Jun 26 12:08:28 CEST 2020 by igor
|
||||
\* Created Wed Oct 02 16:39:42 CEST 2019 by igor
|
||||
440
spec/light-client/verification/Lightclient_A_1.tla
Normal file
@@ -0,0 +1,440 @@
|
||||
-------------------------- MODULE Lightclient_A_1 ----------------------------
|
||||
(**
|
||||
* A state-machine specification of the lite client, following the English spec:
|
||||
*
|
||||
* ./verification_001_published.md
|
||||
*)
|
||||
|
||||
EXTENDS Integers, FiniteSets
|
||||
|
||||
\* the parameters of Light Client
|
||||
CONSTANTS
|
||||
TRUSTED_HEIGHT,
|
||||
(* an index of the block header that the light client trusts by social consensus *)
|
||||
TARGET_HEIGHT,
|
||||
(* an index of the block header that the light client tries to verify *)
|
||||
TRUSTING_PERIOD,
|
||||
(* the period within which the validators are trusted *)
|
||||
IS_PRIMARY_CORRECT
|
||||
(* is primary correct? *)
|
||||
|
||||
VARIABLES (* see TypeOK below for the variable types *)
|
||||
state, (* the current state of the light client *)
|
||||
nextHeight, (* the next height to explore by the light client *)
|
||||
nprobes (* the lite client iteration, or the number of block tests *)
|
||||
|
||||
(* the light store *)
|
||||
VARIABLES
|
||||
fetchedLightBlocks, (* a function from heights to LightBlocks *)
|
||||
lightBlockStatus, (* a function from heights to block statuses *)
|
||||
latestVerified (* the latest verified block *)
|
||||
|
||||
(* the variables of the lite client *)
|
||||
lcvars == <<state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
|
||||
(******************* Blockchain instance ***********************************)
|
||||
|
||||
\* the parameters that are propagated into Blockchain
|
||||
CONSTANTS
|
||||
AllNodes
|
||||
(* a set of all nodes that can act as validators (correct and faulty) *)
|
||||
|
||||
\* the state variables of Blockchain, see Blockchain.tla for the details
|
||||
VARIABLES now, blockchain, Faulty
|
||||
|
||||
\* All the variables of Blockchain. For some reason, BC!vars does not work
|
||||
bcvars == <<now, blockchain, Faulty>>
|
||||
|
||||
(* Create an instance of Blockchain.
|
||||
We could write EXTENDS Blockchain, but then all the constants and state variables
|
||||
would be hidden inside the Blockchain module.
|
||||
*)
|
||||
ULTIMATE_HEIGHT == TARGET_HEIGHT + 1
|
||||
|
||||
BC == INSTANCE Blockchain_A_1 WITH
|
||||
now <- now, blockchain <- blockchain, Faulty <- Faulty
|
||||
|
||||
(************************** Lite client ************************************)
|
||||
|
||||
(* the heights on which the light client is working *)
|
||||
HEIGHTS == TRUSTED_HEIGHT..TARGET_HEIGHT
|
||||
|
||||
(* the control states of the lite client *)
|
||||
States == { "working", "finishedSuccess", "finishedFailure" }
|
||||
|
||||
(**
|
||||
Check the precondition of ValidAndVerified.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA-PRE.1]
|
||||
*)
|
||||
ValidAndVerifiedPre(trusted, untrusted) ==
|
||||
LET thdr == trusted.header
|
||||
uhdr == untrusted.header
|
||||
IN
|
||||
/\ BC!InTrustingPeriod(thdr)
|
||||
/\ thdr.height < uhdr.height
|
||||
\* the trusted block has been created earlier (no drift here)
|
||||
/\ thdr.time <= uhdr.time
|
||||
/\ untrusted.Commits \subseteq uhdr.VS
|
||||
/\ LET TP == Cardinality(uhdr.VS)
|
||||
SP == Cardinality(untrusted.Commits)
|
||||
IN
|
||||
3 * SP > 2 * TP
|
||||
/\ thdr.height + 1 = uhdr.height => thdr.NextVS = uhdr.VS
|
||||
(* As we do not have explicit hashes we ignore these three checks of the English spec:
|
||||
|
||||
1. "trusted.Commit is a commit is for the header trusted.Header,
|
||||
i.e. it contains the correct hash of the header".
|
||||
2. untrusted.Validators = hash(untrusted.Header.Validators)
|
||||
3. untrusted.NextValidators = hash(untrusted.Header.NextValidators)
|
||||
*)
|
||||
|
||||
(**
|
||||
* Check that the commits in an untrusted block form 1/3 of the next validators
|
||||
* in a trusted header.
|
||||
*)
|
||||
SignedByOneThirdOfTrusted(trusted, untrusted) ==
|
||||
LET TP == Cardinality(trusted.header.NextVS)
|
||||
SP == Cardinality(untrusted.Commits \intersect trusted.header.NextVS)
|
||||
IN
|
||||
3 * SP > TP
|
||||
|
||||
(**
|
||||
Check, whether an untrusted block is valid and verifiable w.r.t. a trusted header.
|
||||
|
||||
[LCV-FUNC-VALID.1::TLA.1]
|
||||
*)
|
||||
ValidAndVerified(trusted, untrusted) ==
|
||||
IF ~ValidAndVerifiedPre(trusted, untrusted)
|
||||
THEN "FAILED_VERIFICATION"
|
||||
ELSE IF ~BC!InTrustingPeriod(untrusted.header)
|
||||
(* We leave the following test for the documentation purposes.
|
||||
The implementation should do this test, as signature verification may be slow.
|
||||
In the TLA+ specification, ValidAndVerified happens in no time.
|
||||
*)
|
||||
THEN "FAILED_TRUSTING_PERIOD"
|
||||
ELSE IF untrusted.header.height = trusted.header.height + 1
|
||||
\/ SignedByOneThirdOfTrusted(trusted, untrusted)
|
||||
THEN "OK"
|
||||
ELSE "CANNOT_VERIFY"
|
||||
|
||||
(*
|
||||
Initial states of the light client.
|
||||
Initially, only the trusted light block is present.
|
||||
*)
|
||||
LCInit ==
|
||||
/\ state = "working"
|
||||
/\ nextHeight = TARGET_HEIGHT
|
||||
/\ nprobes = 0 \* no tests have been done so far
|
||||
/\ LET trustedBlock == blockchain[TRUSTED_HEIGHT]
|
||||
trustedLightBlock == [header |-> trustedBlock, Commits |-> AllNodes]
|
||||
IN
|
||||
\* initially, fetchedLightBlocks is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ fetchedLightBlocks = [h \in {TRUSTED_HEIGHT} |-> trustedLightBlock]
|
||||
\* initially, lightBlockStatus is a function of one element, i.e., TRUSTED_HEIGHT
|
||||
/\ lightBlockStatus = [h \in {TRUSTED_HEIGHT} |-> "StateVerified"]
|
||||
\* the latest verified block the the trusted block
|
||||
/\ latestVerified = trustedLightBlock
|
||||
|
||||
\* block should contain a copy of the block from the reference chain, with a matching commit
|
||||
CopyLightBlockFromChain(block, height) ==
|
||||
LET ref == blockchain[height]
|
||||
lastCommit ==
|
||||
IF height < ULTIMATE_HEIGHT
|
||||
THEN blockchain[height + 1].lastCommit
|
||||
\* for the ultimate block, which we never use, as ULTIMATE_HEIGHT = TARGET_HEIGHT + 1
|
||||
ELSE blockchain[height].VS
|
||||
IN
|
||||
block = [header |-> ref, Commits |-> lastCommit]
|
||||
|
||||
\* Either the primary is correct and the block comes from the reference chain,
|
||||
\* or the block is produced by a faulty primary.
|
||||
\*
|
||||
\* [LCV-FUNC-FETCH.1::TLA.1]
|
||||
FetchLightBlockInto(block, height) ==
|
||||
IF IS_PRIMARY_CORRECT
|
||||
THEN CopyLightBlockFromChain(block, height)
|
||||
ELSE BC!IsLightBlockAllowedByDigitalSignatures(height, block)
|
||||
|
||||
\* add a block into the light store
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateBlocks(lightBlocks, block) ==
|
||||
LET ht == block.header.height IN
|
||||
[h \in DOMAIN lightBlocks \union {ht} |->
|
||||
IF h = ht THEN block ELSE lightBlocks[h]]
|
||||
|
||||
\* update the state of a light block
|
||||
\*
|
||||
\* [LCV-FUNC-UPDATE.1::TLA.1]
|
||||
LightStoreUpdateStates(statuses, ht, blockState) ==
|
||||
[h \in DOMAIN statuses \union {ht} |->
|
||||
IF h = ht THEN blockState ELSE statuses[h]]
|
||||
|
||||
\* Check, whether newHeight is a possible next height for the light client.
|
||||
\*
|
||||
\* [LCV-FUNC-SCHEDULE.1::TLA.1]
|
||||
CanScheduleTo(newHeight, pLatestVerified, pNextHeight, pTargetHeight) ==
|
||||
LET ht == pLatestVerified.header.height IN
|
||||
\/ /\ ht = pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ pNextHeight < newHeight
|
||||
/\ newHeight <= pTargetHeight
|
||||
\/ /\ ht < pNextHeight
|
||||
/\ ht < pTargetHeight
|
||||
/\ ht < newHeight
|
||||
/\ newHeight < pNextHeight
|
||||
\/ /\ ht = pTargetHeight
|
||||
/\ newHeight = pTargetHeight
|
||||
|
||||
\* The loop of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOP.1]
|
||||
VerifyToTargetLoop ==
|
||||
\* the loop condition is true
|
||||
/\ latestVerified.header.height < TARGET_HEIGHT
|
||||
\* pick a light block, which will be constrained later
|
||||
/\ \E current \in BC!LightBlocks:
|
||||
\* Get next LightBlock for verification
|
||||
/\ IF nextHeight \in DOMAIN fetchedLightBlocks
|
||||
THEN \* copy the block from the light store
|
||||
/\ current = fetchedLightBlocks[nextHeight]
|
||||
/\ UNCHANGED fetchedLightBlocks
|
||||
ELSE \* retrieve a light block and save it in the light store
|
||||
/\ FetchLightBlockInto(current, nextHeight)
|
||||
/\ fetchedLightBlocks' = LightStoreUpdateBlocks(fetchedLightBlocks, current)
|
||||
\* Record that one more probe has been done (for complexity and model checking)
|
||||
/\ nprobes' = nprobes + 1
|
||||
\* Verify the current block
|
||||
/\ LET verdict == ValidAndVerified(latestVerified, current) IN
|
||||
\* Decide whether/how to continue
|
||||
CASE verdict = "OK" ->
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateVerified")
|
||||
/\ latestVerified' = current
|
||||
/\ state' =
|
||||
IF latestVerified'.header.height < TARGET_HEIGHT
|
||||
THEN "working"
|
||||
ELSE "finishedSuccess"
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, current, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
|
||||
[] verdict = "CANNOT_VERIFY" ->
|
||||
(*
|
||||
do nothing: the light block current passed validation, but the validator
|
||||
set is too different to verify it. We keep the state of
|
||||
current at StateUnverified. For a later iteration, Schedule
|
||||
might decide to try verification of that light block again.
|
||||
*)
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateUnverified")
|
||||
/\ \E newHeight \in HEIGHTS:
|
||||
/\ CanScheduleTo(newHeight, latestVerified, nextHeight, TARGET_HEIGHT)
|
||||
/\ nextHeight' = newHeight
|
||||
/\ UNCHANGED <<latestVerified, state>>
|
||||
|
||||
[] OTHER ->
|
||||
\* verdict is some error code
|
||||
/\ lightBlockStatus' = LightStoreUpdateStates(lightBlockStatus, nextHeight, "StateFailed")
|
||||
/\ state' = "finishedFailure"
|
||||
/\ UNCHANGED <<latestVerified, nextHeight>>
|
||||
|
||||
\* The terminating condition of VerifyToTarget.
|
||||
\*
|
||||
\* [LCV-FUNC-MAIN.1::TLA-LOOPCOND.1]
|
||||
VerifyToTargetDone ==
|
||||
/\ latestVerified.header.height >= TARGET_HEIGHT
|
||||
/\ state' = "finishedSuccess"
|
||||
/\ UNCHANGED <<nextHeight, nprobes, fetchedLightBlocks, lightBlockStatus, latestVerified>>
|
||||
|
||||
(********************* Lite client + Blockchain *******************)
|
||||
Init ==
|
||||
\* the blockchain is initialized immediately to the ULTIMATE_HEIGHT
|
||||
/\ BC!InitToHeight
|
||||
\* the light client starts
|
||||
/\ LCInit
|
||||
|
||||
(*
|
||||
The system step is very simple.
|
||||
The light client is either executing VerifyToTarget, or it has terminated.
|
||||
(In the latter case, a model checker reports a deadlock.)
|
||||
Simultaneously, the global clock may advance.
|
||||
*)
|
||||
Next ==
|
||||
/\ state = "working"
|
||||
/\ VerifyToTargetLoop \/ VerifyToTargetDone
|
||||
/\ BC!AdvanceTime \* the global clock is advanced by zero or more time units
|
||||
|
||||
(************************* Types ******************************************)
|
||||
TypeOK ==
|
||||
/\ state \in States
|
||||
/\ nextHeight \in HEIGHTS
|
||||
/\ latestVerified \in BC!LightBlocks
|
||||
/\ \E HS \in SUBSET HEIGHTS:
|
||||
/\ fetchedLightBlocks \in [HS -> BC!LightBlocks]
|
||||
/\ lightBlockStatus
|
||||
\in [HS -> {"StateVerified", "StateUnverified", "StateFailed"}]
|
||||
|
||||
(************************* Properties ******************************************)
|
||||
|
||||
(* The properties to check *)
|
||||
\* this invariant candidate is false
|
||||
NeverFinish ==
|
||||
state = "working"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishNegative ==
|
||||
state /= "finishedFailure"
|
||||
|
||||
\* This invariant holds true, when the primary is correct.
|
||||
\* This invariant candidate is false when the primary is faulty.
|
||||
NeverFinishNegativeWhenTrusted ==
|
||||
(*(minTrustedHeight <= TRUSTED_HEIGHT)*)
|
||||
BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
=> state /= "finishedFailure"
|
||||
|
||||
\* this invariant candidate is false
|
||||
NeverFinishPositive ==
|
||||
state /= "finishedSuccess"
|
||||
|
||||
(**
|
||||
Correctness states that all the obtained headers are exactly like in the blockchain.
|
||||
|
||||
It is always the case that every verified header in LightStore was generated by
|
||||
an instance of Tendermint consensus.
|
||||
|
||||
[LCV-DIST-SAFE.1::CORRECTNESS-INV.1]
|
||||
*)
|
||||
CorrectnessInv ==
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" =>
|
||||
fetchedLightBlocks[h].header = blockchain[h]
|
||||
|
||||
(**
|
||||
Check that the sequence of the headers in storedLightBlocks satisfies ValidAndVerified = "OK" pairwise
|
||||
This property is easily violated, whenever a header cannot be trusted anymore.
|
||||
*)
|
||||
StoredHeadersAreVerifiedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "OK" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
|
||||
\* An improved version of StoredHeadersAreSound, assuming that a header may be not trusted.
|
||||
\* This invariant candidate is also violated,
|
||||
\* as there may be some unverified blocks left in the middle.
|
||||
StoredHeadersAreVerifiedOrNotTrustedInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks: \* for every pair of different stored headers
|
||||
\/ lh >= rh
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "OK" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~BC!InTrustingPeriod(fetchedLightBlocks[lh].header)
|
||||
|
||||
(**
|
||||
* An improved version of StoredHeadersAreSoundOrNotTrusted,
|
||||
* checking the property only for the verified headers.
|
||||
* This invariant holds true.
|
||||
*)
|
||||
ProofOfChainOfTrustInv ==
|
||||
state = "finishedSuccess"
|
||||
=>
|
||||
\A lh, rh \in DOMAIN fetchedLightBlocks:
|
||||
\* for every pair of stored headers that have been verified
|
||||
\/ lh >= rh
|
||||
\/ lightBlockStatus[lh] = "StateUnverified"
|
||||
\/ lightBlockStatus[rh] = "StateUnverified"
|
||||
\* either there is a header between them
|
||||
\/ \E mh \in DOMAIN fetchedLightBlocks:
|
||||
lh < mh /\ mh < rh /\ lightBlockStatus[mh] = "StateVerified"
|
||||
\* or the left header is outside the trusting period, so no guarantees
|
||||
\/ ~(BC!InTrustingPeriod(fetchedLightBlocks[lh].header))
|
||||
\* or we can verify the right one using the left one
|
||||
\/ "OK" = ValidAndVerified(fetchedLightBlocks[lh], fetchedLightBlocks[rh])
|
||||
|
||||
(**
|
||||
* When the light client terminates, there are no failed blocks. (Otherwise, someone lied to us.)
|
||||
*)
|
||||
NoFailedBlocksOnSuccessInv ==
|
||||
state = "finishedSuccess" =>
|
||||
\A h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] /= "StateFailed"
|
||||
|
||||
\* This property states that whenever the light client finishes with a positive outcome,
|
||||
\* the trusted header is still within the trusting period.
|
||||
\* We expect this property to be violated. And Apalache shows us a counterexample.
|
||||
PositiveBeforeTrustedHeaderExpires ==
|
||||
(state = "finishedSuccess") => BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
|
||||
\* If the primary is correct and the initial trusted block has not expired,
|
||||
\* then whenever the algorithm terminates, it reports "success"
|
||||
CorrectPrimaryAndTimeliness ==
|
||||
(BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
(**
|
||||
If the primary is correct and there is a trusted block that has not expired,
|
||||
then whenever the algorithm terminates, it reports "success".
|
||||
|
||||
[LCV-DIST-LIVE.1::SUCCESS-CORR-PRIMARY-CHAIN-OF-TRUST.1]
|
||||
*)
|
||||
SuccessOnCorrectPrimaryAndChainOfTrust ==
|
||||
(\E h \in DOMAIN fetchedLightBlocks:
|
||||
lightBlockStatus[h] = "StateVerified" /\ BC!InTrustingPeriod(blockchain[h])
|
||||
/\ state /= "working" /\ IS_PRIMARY_CORRECT) =>
|
||||
state = "finishedSuccess"
|
||||
|
||||
\* Lite Client Completeness: If header h was correctly generated by an instance
|
||||
\* of Tendermint consensus (and its age is less than the trusting period),
|
||||
\* then the lite client should eventually set trust(h) to true.
|
||||
\*
|
||||
\* Note that Completeness assumes that the lite client communicates with a correct full node.
|
||||
\*
|
||||
\* We decompose completeness into Termination (liveness) and Precision (safety).
|
||||
\* Once again, Precision is an inverse version of the safety property in Completeness,
|
||||
\* as A => B is logically equivalent to ~B => ~A.
|
||||
PrecisionInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
\/ lightBlock.header /= blockchain[h]
|
||||
\* the full node lied to the lite client about the commits
|
||||
\/ lightBlock.Commits /= lightBlock.header.VS
|
||||
|
||||
\* the old invariant that was found to be buggy by TLC
|
||||
PrecisionBuggyInv ==
|
||||
(state = "finishedFailure")
|
||||
=> \/ ~BC!InTrustingPeriod(blockchain[TRUSTED_HEIGHT]) \* outside of the trusting period
|
||||
\/ \E h \in DOMAIN fetchedLightBlocks:
|
||||
LET lightBlock == fetchedLightBlocks[h] IN
|
||||
\* the full node lied to the lite client about the block header
|
||||
lightBlock.header /= blockchain[h]
|
||||
|
||||
\* the worst complexity
|
||||
Complexity ==
|
||||
LET N == TARGET_HEIGHT - TRUSTED_HEIGHT + 1 IN
|
||||
state /= "working" =>
|
||||
(2 * nprobes <= N * (N - 1))
|
||||
|
||||
(*
|
||||
We omit termination, as the algorithm deadlocks in the end.
|
||||
So termination can be demonstrated by finding a deadlock.
|
||||
Of course, one has to analyze the deadlocked state and see that
|
||||
the algorithm has indeed terminated there.
|
||||
*)
|
||||
=============================================================================
|
||||
\* Modification History
|
||||
\* Last modified Fri Jun 26 12:08:28 CEST 2020 by igor
|
||||
\* Created Wed Oct 02 16:39:42 CEST 2019 by igor
|
||||
26
spec/light-client/verification/MC4_3_correct.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
---------------------------- MODULE MC4_3_correct ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
==============================================================================
|
||||
26
spec/light-client/verification/MC4_3_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
---------------------------- MODULE MC4_3_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 3
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
==============================================================================
|
||||
26
spec/light-client/verification/MC4_4_correct.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC4_4_correct ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC4_4_correct_drifted.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
---------------------- MODULE MC4_4_correct_drifted ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 30 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
==============================================================================
|
||||
26
spec/light-client/verification/MC4_4_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
---------------------------- MODULE MC4_4_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
==============================================================================
|
||||
26
spec/light-client/verification/MC4_4_faulty_drifted.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
---------------------- MODULE MC4_4_faulty_drifted ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 4
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 30 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
==============================================================================
|
||||
26
spec/light-client/verification/MC4_5_correct.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC4_5_correct ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC4_5_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC4_5_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
IS_PRICLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
MARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC4_6_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC4_6_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 6
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
IS_PRCLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC4_7_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC4_7_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 7
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC5_5_correct.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC5_5_correct ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
@@ -0,0 +1,26 @@
|
||||
------------------- MODULE MC5_5_correct_peer_two_thirds_faulty ----------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == TRUE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC5_5_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
----------------- MODULE MC5_5_faulty ---------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
@@ -0,0 +1,26 @@
|
||||
----------------- MODULE MC5_5_faulty_peer_two_thirds_faulty ---------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<2, 3>> \* < 2 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC5_7_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC5_7_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 7
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC7_5_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC7_5_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5", "n6", "n7"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 5
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
26
spec/light-client/verification/MC7_7_faulty.tla
Normal file
@@ -0,0 +1,26 @@
|
||||
------------------------- MODULE MC7_7_faulty ---------------------------
|
||||
|
||||
AllNodes == {"n1", "n2", "n3", "n4", "n5", "n6", "n7"}
|
||||
TRUSTED_HEIGHT == 1
|
||||
TARGET_HEIGHT == 7
|
||||
TRUSTING_PERIOD == 1400 \* two weeks, one day is 100 time units :-)
|
||||
CLOCK_DRIFT == 10 \* how much we assume the local clock is drifting
|
||||
REAL_CLOCK_DRIFT == 3 \* how much the local clock is actually drifting
|
||||
IS_PRIMARY_CORRECT == FALSE
|
||||
FAULTY_RATIO == <<1, 3>> \* < 1 / 3 faulty validators
|
||||
|
||||
VARIABLES
|
||||
state, nextHeight, fetchedLightBlocks, lightBlockStatus, latestVerified,
|
||||
nprobes,
|
||||
localClock,
|
||||
refClock, blockchain, Faulty
|
||||
|
||||
(* the light client previous state components, used for monitoring *)
|
||||
VARIABLES
|
||||
prevVerified,
|
||||
prevCurrent,
|
||||
prevLocalClock,
|
||||
prevVerdict
|
||||
|
||||
INSTANCE Lightclient_003_draft
|
||||
============================================================================
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
order: 1
|
||||
parent:
|
||||
title: Verification
|
||||
order: 2
|
||||
---
|
||||
# Core Verification
|
||||
|
||||
## Problem statement
|
||||