BM-606: Set price to zero after lock deadline #378
Conversation
| /// @dev Once locked, if a valid proof is not submitted before this deadline, the prover can | ||
| /// be "slashed", which refunds the price to the requester and takes the prover stake. | ||
| /// Additionally, the fee paid by the client is zero for proofs delivered after this time. | ||
| /// Note that after this time, and before `timeout` a proof can still be delivered to fulfill | ||
| /// the request. | ||
| uint32 lockTimeout; |
There was a problem hiding this comment.
I think we should also note that if a never locked request is fulfilled before this deadline then they are eligible for payment, if after then not
There was a problem hiding this comment.
paymentTimeout could be a better name? Though that may miss the nuance that you can still get stake if fulfilling a previously locked request.. naming is hard
There was a problem hiding this comment.
I've clarified it a bit further in 0e83b9d
| /// @dev After this time the request is considered completely expired and can no longer be | ||
| /// fulfilled. After this time, the `slash` action can be completed to finalize the transaction |
There was a problem hiding this comment.
Caveat here is that for all intents and purposes a never locked request is completely expired at lockTimeout time (since there is no incentive to fulfill it after that point). Maybe not necessary to cover here though if we can explain it in the comment around lockTimeout
There was a problem hiding this comment.
I've tried to make it more explicit in the comment on lock timeout, about no fee being transferred. It's hard to communicate it exactly right because its technical possible to deliver a proof still to have the request marked as fulfilled, and if you are either us (RISC Zero) or an application with strong interests in filling requests related to your protocol, there might be a reason to do so.
nategraf
force-pushed
the
victor/zero-price-after-lock-deadline
branch
from
66a1721 to
456263a
Compare
|
🚀 Documentation Preview Deployment URL: https://boundless-documentation-eyu7knuyl-risczero.vercel.app Updated at: 2025-03-08 22:23:06 UTC |
nategraf
force-pushed
the
victor/zero-price-after-lock-deadline
branch
2 times, most recently
from
0e83b9d to
424a15f
Compare
|
One thought, when we validate the offer should be check that that rampUpPeriod is <= lockTimeout? With the new design I don't see a reason to ever ramp up beyond that point |
nategraf
force-pushed
the
victor/zero-price-after-lock-deadline
branch
from
46f9532 to
cd3faf2
Compare
nategraf
requested review from
capossele,
Wollac,
zeroecco,
austinabell,
willemolding and
a team
as code owners
add more explicit comments on locktimeout fix up balances in tests update snapshots some missed reference to blocks and constants fix up issues with moving a function
nategraf
force-pushed
the
victor/zero-price-after-lock-deadline
branch
from
b9eb323 to
c1340b4
Compare
github-actions
bot
changed the title
|
This PR is finally ready for another look and to merge |
In recent work, we split the request timeout into two parts: a lock timeout and a timeout. In particular, the lock timeout is the moment where any prover that has locked the request is considered to have failed their obligation, loses exclusivity, and is slashable.
On
mainright now, the price of a request continues to increase during the locked period, and so if the lock expires it is likely that the price has increased tomaxPrice(and more generally, it is no less than the original lockin price). Because of exclusivity, if a prover submits their bid, there is no opportunity for other provers to indicate their bid until the lock has expired, and the price may have risen past where they would have bid. This impacts price discovery, and can cause the client to end up paying more than the "true" market price defined as the minimum price that a prover capable of filling the request would accept. Note that this "true" price is not directly observable.Adding to this, since (unburned portion of) the stake is added to the reward to any prover that fulfills after the lock deadline, in the case that the locked prover fails, there is some notion that if the stake is high enough, the stake alone is sufficient to motivate a prover to fill the request. It is likely that this is the case for a large class of requests.
After much discussion, we've decided to address the issue above by setting the price paid by the client for a request delivered after the lock deadline and before the final request deadline to zero. As a reward, the prover will still obtain any unburned stake taken from a prover that failed the request, if another prover previously locked it.
As with most market mechanisms, it is impossible to tell whether this is the correct choice until we have data from a live market with funds flowing through it. When we have that data, we may revisit this.