From Epoch Windows to Always-On Proving
Since MainNet launch, Gonka's Proof of Computation (PoC) system has operated in discrete epochs. GPU nodes pause inference work, generate proofs, submit them, and resume. The approach works, but it wastes cycles — every proving window is time not spent on actual AI computation.
PR #845, merged on March 25, lays the foundation for continuous PoC: a system where GPU nodes prove spare computational capacity in parallel with inference work, eliminating the stop-and-prove cycle entirely.
How It Works
The continuous PoC model introduces a new message type, MsgSubmitContinuousPoCCommit, that lets GPU nodes submit proof-of-work nonces alongside their regular inference duties. Instead of dedicating entire epochs to proving, nodes generate nonces using idle GPU cycles — the fraction of compute not currently serving inference requests.
Key parameters, all governance-adjustable and disabled by default:
- PocUtilizationTargetBps — sets the idle capacity fraction allocated to proving (default: 99.5%)
- NonceWeight — defines how many nonces equal one inference unit for weight calculation (default: 10)
- MaxCommitsPerEpoch — anti-spam cap at 100 commits per epoch per node
- MinNoncesPerCommit — minimum 10 nonces per submission to prevent dust commits
- ValidationSampleRateBps — 5% random validation probability for spot-checking
Lightweight by Design
The implementation follows the same pattern established by PoC V2: only commit counts and Merkle roots are stored on-chain. Actual proof artifacts remain local to each node. This keeps chain state lean while maintaining cryptographic verifiability.
Epoch summaries are aggregated in real-time as commits arrive, calculating an EffectivePocWeight that feeds directly into the existing settlement and reward distribution system. No changes to the economic model — just a more efficient way to earn the same weight.
Rate Limiting and Safety
The message handler enforces multiple validation layers:
- Participant registration verification
- One commit per block rate limit
- Nonce minimum enforcement per commit
- Per-epoch commit count cap
- GPU utilization bounds checking
These constraints prevent gaming while keeping the system open to all registered participants.
What This Means
Continuous PoC addresses a fundamental tension in Proof of Computation networks: proving you can compute versus actually computing. The current epoch-based system forces nodes to choose — the new foundation makes both simultaneous.
The feature ships disabled by default as part of the v0.2.12 milestone. Activation requires a governance vote, giving the community time to review parameters before flipping the switch. The parent issue (#821) remains open for ongoing refinements, but the core infrastructure — types, params, keeper, message handler — is merged and ready.
For node operators, this means no immediate changes. When governance activates continuous PoC, nodes will automatically begin utilizing idle GPU cycles for proving, potentially increasing their effective weight without additional hardware.