This journal is generated by AI

Erlang State Machine Patterns in Rust

This week I created a presentation exploring how to implement Erlang OTP’s gen_statem patterns in Rust using Tokio. The core insight is that Erlang’s behavior pattern separates the engine (state machine framework) from the callback (state-specific logic), following the strategy pattern.

  • The fundamental state transition follows: State(S) × Event(E) → Actions(A), State(S')
  • Erlang’s “everything is an event” philosophy means state entry, timeouts, and internal messages are all unified as events
  • The enter event triggers when entering a new state, useful for running initialization logic without duplicating code across multiple transition paths
  • Postpone action defers events to a later state when we can’t process them yet
  • Timeout actions come in three flavors: event timeout (cleared on any event), state timeout (cleared on state change), and named timeout (manual clearing)
  • Inserted events enable preprocessing and state machine composition

The code examples progressively build from basic process simulation to full-featured state machines with all these capabilities.

BFT Consensus Protocol Comparisons

I studied the differences between PBFT, Tendermint, HotStuff, and HotStuff-2. These are all safety-preferring protocols where locked parties guard the safety of a potential commit. The key questions each protocol answers are:

  • What does the leader learn about system status at the start of a view?
  • How does the leader convince other parties about system status to get votes?

Among 2t+1 locks in a status response, up to t can be malicious, up to t can be honest but not locked on the committed value, but at least one honest party must be locked on the committed value. This honest party won’t vote for conflicting proposals, thus guarding commit safety.

HotStuff introduces an additional phase: “if some party locks, then ≥2t+1 parties know about this lock and hold a key corresponding to it.”

Sources:

CKB Virtual Transactions

I explored a design for implementing partial transactions in CKB through “Virtual Tx.” The approach mocks system calls so scripts access the virtual tx instead of the real current transaction.

  • Override syscalls in ckb-c-stdlib or ckb-std to redirect to virtual tx data
  • Anyone can be economically incentivized to match partial txs since fees can be provided
  • Use a special first input as the indicator that the tx is a vtx
  • The first input’s type script witness specifies how each vtx maps to tx components (inputs, outputs, etc.)
  • Inputs/outputs are handled exclusively, with mechanisms to tackle cell/header deps duplication