GFermah fam
Let’s dive into how
@fermah_xyz Prover Node works from hardware to incentives and why it matters for the future of zk proof infrastructure.
At its core running a Fermah Prover Node means supplying compute capacity (CPU/GPU/SSD) to the proof generation marketplace. The network matches proof requests to nodes, so you as an operator get rewarded for doing work.
Onboarding
• Prepare a machine (Ubuntu 22.04 LTS with GLIBC 2.34 , Docker, for GPU nodes CUDA drivers v12.2)
• Install Fermah’s fpn (Prover Node binary) via their install script.
• Register your node you’ll require whitelist secret keys, RPC URL and then execute prover node register.
Configuration and Hardware Specs
• Nodes declare their hardware resources (RAM, CPU cores, GPU specs, SSD storage) in a TOML config (prover node config.toml)
• Example for the ZkSync prover mode is RAM 128 GB 32 vCPUs for all round smaller for certain sub tasks (leaf aggregation 80 GB 16vCPUs etc).
• GPU nodes VRAM 24 GB etc required for certain circuit proving tasks.
Operational Mode
Once the node is configured and registered, you run fpn as daemon/service. It listens for incoming proof jobs, executes tasks, reports telemetry, handles updates automatically
Increase system limits (open files, socket buffers) for stability.
Ecosystem and Economics
• Operators are part of the
supply side your hardware gets matched to demand (proof requests) via
@fermah_xyz matchmaker layer.
• By declaring accurate hardware capabilities and staying performant, you improve your node’s chances of being selected and thus earning fees.
• This lowers barrier for proof generation at scale more supply = competitive pricing decentralization
• For zk projects would be Easier access to proof generation infrastructure without building everything in house.
• For operators it would be A new avenue to monetise high end compute gear (GPUs, large RAM, SSD) in a Web3 setting.
• For the ecosystem Decentralising proving reduces risks of bottlenecks, single points of failure, or cost monopolies.
Risks and some Considerations
• Running high end hardware => upfront cost, operational maintenance (cooling, power, latency, uptime)
• Proof job correctness and reliability matters. If your node fails or under performs you might lose selection or rewards.
• Market competition many nodes, varying performance levels your differentiation is hardware uptime responsiveness.
• Securitykeys, configuration files, node integrity must be protected.
Some Best Practice Tips for Operators
• Make sure your hardware is right sized match whichever proving mode (CPU Witness Gen, GPU circuit proving) you aim for.
• Monitor telemetry and logs ensure node health (metrics, errors) and maintain good uptime.
• Keep config files versions updated new releases of Fermah binaries may include optimisations or new proof systems.
• Secure your environment run under non.root user, secure keystores and secrets, use systemd or containerised service for manageability.
• Participate early testnet Getting on testnet allows you to gain experience, reputation
If you’re looking to operate a proof generation node in the zk space, Fermah Prover Node model offers a practical path. Supply capacity, declare specs, register, stay online get matched and paid. For the ecosystem, it shifts proof generation from bespoke silos to open compute markets