BM-1249: [WIP] Smart contracts and guests for Boundless integration of support Proof of Verifiable Work (PoVW) #847
Conversation
github-actions
bot
changed the title
|
🚀 Documentation Preview Deployment URL: https://boundless-documentation-9s3u7vdl0-risczero.vercel.app Updated at: 2025-08-05 22:08:05 UTC |
nategraf
changed the title
contracts/src/povw/Mint.sol
Outdated
| // NOTE: This may be larger than 1 when aggregating rewards across multiple epochs. | ||
| // TODO(povw): This only works if the epoch reward is constant per epoch. | ||
| FixedPoint value; |
There was a problem hiding this comment.
Do you plan to handle this? Curious if this works if emission rates ever need to be adjusted
There was a problem hiding this comment.
I imagine that we need to, since I would assume we do want the ability to change the emissions rate (e.g. on a time curve or via governance). Not totally sure the best way to handle this, and that's partly because the best solution may depend on the rules around updates.
contracts/src/povw/Mint.sol
Outdated
| MintCalculatorUpdate memory update = journal.updates[i]; | ||
|
|
||
| // On the first mint for a journal, the initialCommit should be equal to the empty root. | ||
| bytes32 expectedCommit = lastCommit[update.workLogId]; |
There was a problem hiding this comment.
It seems that the Mint Calculator Guest processes every single prover in the epoch, which means that for every mint there could be a lot of updates + mints
How feasible is it for minting to be sybil'd? Concern would be to make mint consume so much gas that the transaction can not fit in a block, which I believe would halt rewards indefinitely (?)
There was a problem hiding this comment.
Ah, yes. So if this becomes an issue the transaction can be broken up. The segmenting can be done both between work logs (e.g. some work logs in one tx and some in another) or between updates (e.g. the first x updates in one tx and the next y updates in another tx). The smallest chunk allowed is a single WorkLogUpdated event for a single work log (i.e. a single prover).
In the case that there are many low value log updates, which might be so small its not worth paying the gas to mint the tokens, these can simply be excluded. If the owner of those work logs would like their mint, they can post the update themselves.
There was a problem hiding this comment.
Are you saying it can be supported in the current implementation, or its something we could do in a future upgrade? (maybe im missing it but I don't see how you can do it with the current Mint guest)
There was a problem hiding this comment.
The guest supports this, but the tooling does not exist to run this guest in this way (or any other for that matter, expect in tests). The way its supported in the guest is that it only enforces the completeness of updates within a single account (i.e. work log). So if one run of the guest prepares the mint for work log A, and the second run of the guest prepares the mint for work log B, those two mints can be posted in independent transactions.
This PR implements the PoVW prover, core data types, Merkle tree for nonces, and the Log Builder guest. Related: risc0/zirgen#250 Related: boundless-xyz/boundless#847 --------- Co-authored-by: Frank Laub <flaub@risc0.com> Co-authored-by: Remi Bernotavicius <bobbobbio@gmail.com>
This PR includes the smart contract and associated guests for proof of verifiable work (PoVW).
Related: risc0/zirgen#250
Related: risc0/risc0#3220