Two layers, one or two processes
A Proof-of-Stake network needs an execution layer and a consensus layer. Fukuii is the execution layer: it holds state, executes transactions, and builds or validates the payload inside each block. Deciding which block wins is the consensus layer's job, and you can either supply that layer yourself or let Fukuii run it.
Pair an external consensus client
The Engine API is a published specification, so any client implementing it can drive Fukuii. Both processes read the same JWT secret from a file, and the authenticated port stays on localhost.
# Generate the shared secret both processes read
openssl rand -hex 32 | tr -d "\n" > jwt.hex
# Run Fukuii as the execution layer
fukuii --network=eth \
--engine-rpc-enabled \
--engine-rpc-port=8551 \
--engine-jwt-secret=./jwt.hex
# Then point a consensus client at http://localhost:8551,
# giving it the same jwt.hexRun the consensus layer in the same binary
Fukuii can run the consensus layer itself, which removes the second process, the second release cadence, and the secret shared between them. The trade is implementation diversity: two programs from two projects fail in different ways, and one program does not.
# The consensus layer runs in the same process, so there is no
# second program to install and no shared secret to manage.
fukuii --network=eth \
--consensus-layer-enabled \
--fee-recipient=0xYourAddressHow the two layers talk
The exchange is smaller than it sounds. The consensus layer hands the execution layer a proposed block and asks it to execute and validate the contents, and separately tells it which block is now the head, which is safe, and which is finalized. When this node is due to propose, the consensus layer asks it to build a payload and then collects the result. That is the whole conversation.
The shared secret is not access control for users. It is how the two processes prove to each other that they are the pair you configured, and it matters because this is the one interface that can tell the node which chain to follow. That is why the authenticated port stays on the loopback address and never goes near the internet.
The fee recipient is set on the execution layer rather than the consensus layer because that is where blocks are actually assembled. It is the address credited with the priority fees from any block this node builds.
The node cannot find the head by itself
Under Proof-of-Work a node picks the head itself, by weight of accumulated work. Under Proof-of-Stake the execution layer has no equivalent measure available to it: which branch is canonical is a consensus-layer determination, and the execution layer learns it by being told. Syncing works the same way around, running toward a head the consensus layer supplies rather than forward from whatever the node last knew.
That changes what a missing consensus layer means. The node does not quietly choose a head of its own, because it has nothing to choose with; it simply stops advancing. So a consensus layer that has stopped talking is treated as a fault worth reporting rather than a quiet degradation. A node sitting at a stale head while reporting itself healthy is worse than one that says plainly it is stuck, and this is the specific reason readiness on a Proof-of-Stake network has to mean more than the process being alive.
Consensus clients that drive Fukuii
Each implements the Engine API, in a different language. Fukuii behaves the same way behind all of them.
| Consensus client | Language |
|---|---|
| Lighthouse | Rust |
| Prysm | Go |
| Teku | Java |
| Lodestar | TypeScript |
| Nimbus | Nim |
What to open, and to whom
The peering port needs to reach the internet. Nothing else does, and the authenticated Engine API port in particular should never leave the host.
| Port | Carries | Expose |
|---|---|---|
| 30303 | P2P discovery and peering, TCP and UDP | Yes, to the internet |
| 8545 | JSON-RPC over HTTP | Trusted callers only |
| 8546 | JSON-RPC over WebSocket | Trusted callers only |
| 8551 | Engine API, authenticated with the JWT secret | Localhost only |
| 9545 | Prometheus metrics | Your monitoring only |
Running a validator is a further step, with its own key handling, its own stake requirement, and withdrawal credentials set when the validator is created. Those are protocol-level concerns rather than client configuration.
Staking on Ethereum, at ethereum.org →