Multi-Section Retry (Retry Slots) and LA Penalty Loop
Background
Under high concurrency conditions, Proof generation may fail due to hardware jitter or network interruptions. To avoid the entire task being voided, the Coprocessor introduces 'Retry Slots'.
⸻
Mechanism Process
1. First Submission
The Prover calls submitProof(π_0), and if verification fails, the Verifier triggers initRetrySlot(), leaving a retry token retryID on the chain.
2. Double Staking
Nodes entering the retry section must immediately supplement an additional 1× collateral LA to the BondPool, forming doubleStake, to cover overtime computing power and risks.
3. Regenerate
The node must re-run the proof within the time limit Δ (set by governance) and call retryProof(retryID, π_1).
• Pass → Return the doubled collateral and only penalize 5% of the initial cost as failure cost;
• Fail again or timeout → Trigger slashDouble(), confiscating all double collateral, with 60% burned and 40% going to the insurance pool.
4. Multiple Retries
A maximum of 2 retries is allowed. If the second attempt also fails, the node will be blacklisted for an entire epoch.
⸻
LA Penalty Loop
Phase LA Flow
Double Staking Temporarily Lock BondPool
Successful Retry Refund 95%, 5% Burned
Failed Retry slashDouble()
Blacklisted Node Release requires an additional deposit of 2 × minStake
⸻
Adjustable Parameters
Parameter Initial Value Remarks
Δ (Retry Window) 30 min Timelock Modification
retryLimit 2 Prevent Infinite Re-runs
slashRatioDouble 100 % Full Confiscation of Double Deposit
All modifications will take effect after being passed by LA staking votes with a Timelock of 48 hours.
⸻
Effects
The retry mechanism allows for occasional errors to have a chance for correction while binding economic risks with LA double collateral. If a node delivers stably, the loss is minimal; if there is another error, the penalty far exceeds the usual Slash, providing additional insurance to the safety curve.