Blockchain Client Security Checklist

Incorrect fork choice can cause chain splits or stuck nodes.

Blocks marked final must actually be final. Reorging finalized blocks breaks assumptions.

Validators must be slashed for violations. Missing slashing allows attacks.

System must tolerate f Byzantine nodes with 3f+1 total nodes.

Clock drift between nodes must not break consensus.

Boundary conditions between slots and epochs are bug-prone.

Verify peer identity. Prevent impersonation attacks.

Ensure node connects to diverse peers. Detect isolation attempts.

Rate limit messages. Disconnect misbehaving peers.

Validate all P2P messages before acting on them.

Track peer behavior. Penalize and disconnect bad actors.

Support nodes behind NAT. Use hole punching or relays.

All transaction signatures must be verified. Missing checks allow forgery.

Nonces must be sequential. Gaps or repeats indicate bugs.

Incorrect gas can cause DoS or allow free execution.

Limit mempool size. Prevent spam transactions.

Same inputs must produce same ordering. Nondeterminism causes consensus failures.

State roots must be calculated identically across clients.

Pruning must not remove data needed for validation.

Clients should detect and recover from database corruption.

When syncing state, verify proofs. Do not trust peers blindly.

Historical data must remain accessible and correct.

Never implement cryptography yourself. Use established libraries.

Timing attacks can leak private keys. Use constant-time comparisons.

Use cryptographically secure RNG. Weak randomness breaks security.

Validator keys must be encrypted at rest and in memory when possible.

Use modern hash functions. Be aware of collision attacks.

Admin RPC endpoints must require authentication.

Logs must not contain secrets. Metrics endpoint should be internal.

Software updates must be signed and verified.

Memory, disk, and connection limits prevent resource exhaustion.

Only necessary ports exposed. Admin interfaces internal only.

Test fork transitions on testnet thoroughly before mainnet.

Have ability to roll back if upgrade causes issues.

Coordinate upgrades across multiple client teams.

If upgrade changes state format, migration must be correct.