Consensus Mechanisms, Smart Contracts, and Chaincode
What this domain tests
Consensus safety and liveness, protocol families, finality, and smart-contract or chaincode execution. Expect numeric thresholds and failure-mode questions.
Core rules
- Crash fault tolerant protocols such as Raft tolerate f failures with 2f+1 nodes. Byzantine fault tolerant protocols need 3f+1 nodes to tolerate f faulty nodes.
- Proof-of-work gives probabilistic finality; proof-of-stake and BFT variants often give deterministic or economic finality.
- Smart contracts must be deterministic across nodes. Avoid host timestamps, host randomness, external APIs, and floating-point variation unless supplied through consensus.
- Chaincode lifecycle: package, install, approve, commit, invoke. Upgrades require the same policy discipline.
- Common contract risks: reentrancy, integer overflow, missing access control, unchecked external calls, and upgrade or admin key compromise.
- Gas meters computation on EVM chains; Fabric chaincode uses endorsement and ordering instead of gas.
Worked example
A consortium runs four validators using IBFT. It can tolerate f=1 Byzantine node because 3f+1=4. If two nodes are faulty, quorum cannot be reached safely and the network stalls rather than forking. A candidate who says it tolerates two faults has confused crash tolerance with BFT tolerance.
Traps
Do not apply 2f+1 to Byzantine faults. Do not say PoW is instantly final. Do not put non-deterministic calls in chaincode. Do not treat a smart contract as legally self-enforcing. Do not confuse endorsement with ordering.