Chapter 32 — Web3, blockchain and cryptoasset security: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Finality"]
N2["Lab — Confirmations from Nakamoto's formula"]
N3["32.2 Reading the results"]
N4["32.3 Failure planning"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Finality"]
N2["Lab — Confirmations from Nakamoto's formula"]
N3["32.2 Reading the results"]
N4["32.3 Failure planning"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Finality]
|
v
[Lab — Confirmations from Nakamoto's formula]
|
v
[32.2 Reading the results]
|
v
[32.3 Failure planning]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) reason about finality and confirmations; (2) plan for node and gateway failures; (3) set reliability targets.
32.1 Finality
On a proof-of-work chain, a transaction becomes harder to reverse as blocks are added after it. Nakamoto's paper, section 11, gives the probability that an attacker with a share q of computing power could catch up from z blocks behind. Jonas implements that formula in a standard-library script to understand how confirmations reduce risk. Brightwater's permissioned ledger reaches finality differently, once its validators agree, but the cooperative also accepts payments bridged from a public chain, so the confirmation question applies to those deposits.
Lab — Confirmations from Nakamoto's formula
"""Confirmations needed using the catch-up probability in Nakamoto (2008), section 11 (read-only)."""
import math
def attacker_success(q, z):
p = 1 - q; lam = z * q / p; s = 1.0
for k in range(z + 1):
poisson = math.exp(-lam) * lam ** k / math.factorial(k)
s -= poisson * (1 - (q / p) ** (z - k))
return s
def main():
for q in (0.1, 0.3):
for z in (0, 2, 6):
print(f"q={q} z={z} P={attacker_success(q, z):.7f}")
z = 0
while attacker_success(q, z) >= 0.001:
z += 1
print(f"q={q}: z for P<0.001 = {z}")
if __name__ == "__main__":
main()
Run with python3 lab_finality.py. Verified output:
q=0.1 z=0 P=1.0000000
q=0.1 z=2 P=0.0509779
q=0.1 z=6 P=0.0002428
q=0.1: z for P<0.001 = 5
q=0.3 z=0 P=1.0000000
q=0.3 z=2 P=0.4457171
q=0.3 z=6 P=0.1321112
q=0.3: z for P<0.001 = 24
32.2 Reading the results
The script reproduces the values in Nakamoto's paper: with q equal to 0.1, the probability is 0.0509779 at two confirmations and 0.0002428 at six; five confirmations bring it below 0.001. With q equal to 0.3, six confirmations still leave 0.1321112, and twenty-four are needed to go below 0.001. Jonas concludes that the number of confirmations must depend on assumptions about adversary strength and the value at stake, and recommends a documented waiting rule for bridged deposits based on deposit size.
With q equal to 0.1, for example, six confirmations put the risk near 0.0002, while larger deposits could justify a longer wait under a stronger adversary assumption.
32.3 Failure planning
Reliability also means surviving component failures. Jonas lists failures and planned responses: if one validator fails, the other two continue; if two fail, the ledger halts and members are informed while operators restore service; if the gateway fails, readings queue at meters for up to seven days; and if the member app fails, paper statements and phone support continue. He sets targets with the board: ledger availability of 99.5 percent monthly and recovery of the gateway within four hours. Targets make reliability measurable rather than hoped for.
Worked example
The lab reproduces Nakamoto's values (q=0.1: z=5 for P<0.001; q=0.3: z=24); failure responses and targets of 99.5% availability and four-hour gateway recovery are set.
Synthetic case. Targets and failure plans are synthetic; Nakamoto (2008) is a real source.
Errors and limits
Using a fixed number of confirmations regardless of value and adversary assumptions misjudges risk.
Exercises
- EX094 — Paper values. What probability does q=0.1 give at six confirmations? Rubric: 3 = 0.0002428;; 2 = about 0.0002;; 1 = 0.05;; 0 = none.
- EX095 — Strong adversary. How many confirmations for P<0.001 at q=0.3? Rubric: 3 = 24;; 2 = twenty-four;; 1 = 6;; 0 = none.
- EX096 — Gateway queue. How long can meters queue readings? Rubric: 3 = up to seven days;; 2 = seven days;; 1 = one hour;; 0 = none.
Synthesis
Confirmation rules, planned failure responses and measurable targets make the platform reliable.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →