dusk-network / dusk-network/docs
Content: Operating the current DuskEVM stack
Open
Nobody has claimed this yet.
section:node-operator
- Dominant language
- MDX
- Stars
- 8
- Forks
- 4
- Avg merge
- 3h 57m
- Merged PRs (30d)
- 8
Description
Summary\n\nCreate a dedicated operator section for the current DuskEVM stack. DuskEVM is not a separate validator network: operators run an OP Stack deployment backed by Dusk L1, a Rusk archive node, the DuskEVM adapter, and op-reth.\n\nThe guide should serve node operators, infrastructure partners, RPC providers, and explorers. It should complement the existing Dusk L1 documentation and link to the pinned OP component documentation where appropriate.\n\n## Architecture to document\n\n- Rusk archive node and the archive/history requirements used by the adapter.\n- Writable and read-only adapter roles, including relayer ownership and nonce isolation.\n- op-reth sequencer and verifier roles.\n- op-node, batcher, proposer, and challenger.\n- Blockscout and public RPC placement.\n- The immutable address book, L1/L2 genesis, rollup configuration, and contract deployment bundle.\n\n## Required operational topics\n\n- Data directories, persistence, listeners, ports, CORS, and public/private RPC boundaries.\n- Rusk archive retention and complete hash-bound event availability.\n- Adapter database lifecycle, schema compatibility, clean rebuild, resynchronization, and finalized-divergence handling.\n- Router epoch schedules and the writable-adapter restart requirement at an activation boundary.\n- op-reth proof/history retention required by proposer and challenger workflows.\n- RPC request, batch, log-range, response-size, and rate limits.\n- Relayer key configuration, funding, isolation, and rotation.\n- Startup ordering and readiness for Rusk, adapter, op-reth, op-node, writers, challenger, explorer, and ingress.\n- Metrics and alerts for adapter sync/completion, Rusk archive availability, OP heads, writer progress, and challenger health.\n- Backup, restore, rollback, clean reset, and recovery procedures.\n- Version and checksum pinning for Rusk, Piecrust, contracts, adapter, op-reth, and OP components.\n\n## Acceptance criteria\n\n- Documentation describes the current adapter/op-reth architecture and contains no legacy op-geth or legacy DuskEVM proxy instructions.\n- Separate runbooks exist for a writable sequencer-side deployment and a read-only verifier/explorer deployment.\n- Configuration examples match the released binaries and deployment bundle.\n- Public exposure and rate-limit guidance cover the adapter, op-reth, and Blockscout independently.\n- Recovery procedures cover an adapter rebuild from canonical Rusk history and an op-reth resync.\n- The guide states the minimum supported component revisions and required protocol activation features.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing Dusk L1 documentation and the pinned OP component documentation, then map the current DuskEVM architecture and released binaries against the required operational topics. Define separate writable sequencer-side and read-only verifier/explorer runbooks, including configuration, startup, monitoring, exposure, backup, and recovery. Done means the acceptance criteria are covered without legacy instructions and with supported revisions and protocol features stated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- blockchain
- Domain
- blockchain, documentation, infrastructure
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100