Prover Coordination #25
Conversation
|
|
||
| A proposer will be able to respond to a quote with a signed message, which a prover can submit to L1, along with a prover commitment bond. The prover can subsequently submit the proof to L1, releasing the bond. | ||
|
|
||
| This coordination will take place "out of protocol", via an optional p2p topic, with the slight exception/leak that the rollup contract will permit the prover to submit bonds/proofs in a proposer's stead. |
There was a problem hiding this comment.
Are there any issues from making these quotes public on the p2p layer? Namely:
- Censorship from other provers, who don't relay competing quotes
- Undercutting quotes by competitors (ie I see a quote for 100, so I send one for 99) by making all quotes public
- Delay in propagation until the quote reaches the proposers
Would it be better to have each sequencer keep a list of endpoints to query, and they hit the prover-nodes directly? Or via one or more relays? In practice, do we expect sequencers to take orders from unknown provers, or only from a whitelist they keep?
There was a problem hiding this comment.
Censorship: As long as a node has sufficient peers, they shouldn't be able to be eclipsed by other provers, since regular full nodes and validators can/should also be forwarding these messages.
undercutting: I see it as a first price auction, which is known to have issues where the winner under/overpays. I'm okay with that in the immediate term.
delay: this should be mitigated by the proof claim period being multiple L2 slots. Assuming 13 slots for proof claim, and 36 second slots, that should be abundant time.
hitting prover nodes directly: I think this is possible, especially if we see, e.g. provers are unwilling to participate in an open auction. This is also something that could be implemented in the community down the line. If we consider the p2p layer as the public mempool for bids which serves as a baseline, I can imagine more privacy preserving options being created down the line, like a list of servers to query to bids, or a relay, etc.
unknown provers: I think that a proposer can do some validation. a simple one would just be to read the L1 balance of the prover to see if they have sufficient TST to post the bond. Peer scoring could be used here. I'd like to avoid relying on a whitelist for the vanilla/baseline solution if possible, but I could see nodes using one in practice.
There was a problem hiding this comment.
Since it is mentioned as out of protocol they could choose to do it without using the p2p and in their own channels if it is horrible? 🤷♂ I think this is probably fine for short term, on bond, seems like an easy win for an unknown proposer would be to use a generally used contract to escrow bond money such that it is known that it could be used.
| The prover will be able to submit this Quote to `claimProofRight` on the rollup contract. The rollup contract will verify that: | ||
| - The epoch is in the proof claim phase | ||
| - There is not already a claim/proof for this epoch | ||
| - The quote has been signed by the proposer for the current slot | ||
| - The `prover` matches `msg.sender` | ||
| - The epoch matches the previous epoch (i.e. the one to be proven) | ||
| - The prover successfully transmits the bond (in TST) to the rollup contract | ||
|
|
||
| If all conditions are met, the rollup contract stores the quote, and the address of the proposer. |
There was a problem hiding this comment.
What happens if...?
- The proposer signs multiple quotes. Should the first one to get to L1 win?
- A malicious agent spams the p2p layer with cheap fake quotes. The sequencer signs one of those, but then the prover never uploads anything. How can a sequencer differentiate this attack from a legitimate first-time prover with no reputation yet? Should we require whitelisting?
There was a problem hiding this comment.
taking multiple quotes: Yes, I think this can/should be expected. I think it is a great feature. If Alice is proposer in an epoch, and she sees 10 bids, she can/should sign the 3 that advertise a price she is comfortable with; from her perspective then it doesn't matter which one posts the bond. It then de-risks Alice if one of those provers does not post the bond.
fake quotes: comes back, I think, to validation (checking L1 balance of the prover before signing), and possibly peer scoring: we can ask nodes participating on this layer to check L1 balance.
There was a problem hiding this comment.
I'll refer to my comment above, it seems fairly easy provide an out of protocol general bond contract that provers without a reputation could use to essentially lock funds such that they can easily convince proposers that the funds are there etc.
Without a hard guarantee, as a proposer, I would put zero value on promise. It is essentially a pre-commitment bond.
|
|
||
| If all conditions are met, the rollup contract stores the quote, and the address of the proposer. | ||
|
|
||
| When the prover submits the proof, the rollup contract will pay out TST rewards to the proposer after paying the prover the basis point fee contained in the quote. It will also release the bond to the prover. |
There was a problem hiding this comment.
Following on from what @spalladino says, it feels to me like the proposer should post the message to L1. That way, a signed message from a prover is a binding commitment that a proposer can use to post to L1. Currently it's not binding at all as it requires the prover to later post to L1 which they can simply choose not to creating a lot of uncertainty for the proposer.
There was a problem hiding this comment.
That is how I had originally been thinking of it.
I think the downside to this approach is that all provers need to approve the rollup contract to transfer funds ahead of time; the current approach does not. I don't think it is possible for the proposer to upload anything to the rollup and be able to transfer the prover's funds without prior action from the prover (assuming the TST contract does not trust the rollup). @LHerskind do you have any thoughts here?
Having the proposer submit though would also decrease a round of p2p, which would be huge.
There was a problem hiding this comment.
Why is it a problem to require a prior erc20 approval, or a pre-signed permit-like message to be included in the Quote sent by the prover? We could also force provers to escrow the funds for a period of time, to prevent them from cancelling the approval before the sequencer has had a chance to submit their quote.
There was a problem hiding this comment.
Not a serious problem, just would require more gas and coordination (once my bond is taken, i need to top up another approval).
But I think the permit based flow is best!
I think an escrow step could be a nice extension in the future if cancelled approvals are a recurring problem.
There was a problem hiding this comment.
I previously shared thoughts via message but posting for visibility.
Agree with previous comments that proposer should post the bond. If prover submits bond then:
- They can DOS the system (no balance checks are being made prior to sending quote).
- Forces proposers to approve quotes from multiple provers to hedge risk which may end up in less than optimal execution - basically the fastest prover to get to L1 wins the bid, and not the best bid/price.
There was a problem hiding this comment.
I think the DOS vector is still present unless the proposer checks the L1 balances of the provers.
RE suboptimal, I think it would be "the fastest prover among those Alice approved wins the bid". I think that part is actually fine, the less desirable piece would be that provers who try to cash and fail to win the race condition in just wasted gas.
There was a problem hiding this comment.
Regarding DOS, you're right. But the escrow mechanism from above only works if the proposer posts the bond.
Regarding suboptimal, because provers could ultimately decide to not post the bond, a proposer will be forced to approve more quotes than they would normally have if they had the ability to "exercise" a prover's bid.
Because there's opportunity cost for the proposer in missing out on the proving rewards, their strategy might even be to approve all quotes from reputable provers driving the price down.
There was a problem hiding this comment.
I don't think it is possible for the proposer to upload anything to the rollup and be able to transfer the prover's funds without prior action from the prover (assuming the TST contract does not trust the rollup). @LHerskind do you have any thoughts here?
You can do it without an on-chain action. It was mainly that the outline I saw (maybe old version of this pr or in another) was vulnerable and you could spend other peoples funds so I would not use that one.
I think escrowing it for some time is also a fine approach to make sure that the bond is actually available (also mentioned earlier). You could likely do a mix as well, e.g., escrow but require a permit (slightly different permit than the usual erc20) for a bond to be posted for a specific epoch.
I think a check of L1 balance is literally worthless on its own.
I can help outline an escrow today if you want @just-mitch?
There was a problem hiding this comment.
Thank you @LHerskind! I updated the #22 to talk about the escrow and permit flow.
|
|
||
| A proposer will be able to respond to a quote with a signed message, which a prover can submit to L1, along with a prover commitment bond. The prover can subsequently submit the proof to L1, releasing the bond. | ||
|
|
||
| This coordination will take place "out of protocol", via an optional p2p topic, with the slight exception/leak that the rollup contract will permit the prover to submit bonds/proofs in a proposer's stead. |
There was a problem hiding this comment.
Since it is mentioned as out of protocol they could choose to do it without using the p2p and in their own channels if it is horrible? 🤷♂ I think this is probably fine for short term, on bond, seems like an easy win for an unknown proposer would be to use a generally used contract to escrow bond money such that it is known that it could be used.
| The prover will be able to submit this Quote to `claimProofRight` on the rollup contract. The rollup contract will verify that: | ||
| - The epoch is in the proof claim phase | ||
| - There is not already a claim/proof for this epoch | ||
| - The quote has been signed by the proposer for the current slot | ||
| - The `prover` matches `msg.sender` | ||
| - The epoch matches the previous epoch (i.e. the one to be proven) | ||
| - The prover successfully transmits the bond (in TST) to the rollup contract | ||
|
|
||
| If all conditions are met, the rollup contract stores the quote, and the address of the proposer. |
There was a problem hiding this comment.
I'll refer to my comment above, it seems fairly easy provide an out of protocol general bond contract that provers without a reputation could use to essentially lock funds such that they can easily convince proposers that the funds are there etc.
Without a hard guarantee, as a proposer, I would put zero value on promise. It is essentially a pre-commitment bond.
|
|
||
| If all conditions are met, the rollup contract stores the quote, and the address of the proposer. | ||
|
|
||
| When the prover submits the proof, the rollup contract will pay out TST rewards to the proposer after paying the prover the basis point fee contained in the quote. It will also release the bond to the prover. |
There was a problem hiding this comment.
I don't think it is possible for the proposer to upload anything to the rollup and be able to transfer the prover's funds without prior action from the prover (assuming the TST contract does not trust the rollup). @LHerskind do you have any thoughts here?
You can do it without an on-chain action. It was mainly that the outline I saw (maybe old version of this pr or in another) was vulnerable and you could spend other peoples funds so I would not use that one.
I think escrowing it for some time is also a fine approach to make sure that the bond is actually available (also mentioned earlier). You could likely do a mix as well, e.g., escrow but require a permit (slightly different permit than the usual erc20) for a bond to be posted for a specific epoch.
I think a check of L1 balance is literally worthless on its own.
I can help outline an escrow today if you want @just-mitch?
just-mitch
force-pushed
the
mt/prover-coordination
branch
from
56ee533 to
5a72500
Compare
add a PricingService separate from the governor.
| } | ||
| ``` | ||
|
|
||
| The default implementation of the `ProofQuoteGenerator` will take a `ProofPricingService` in its constructor, and call `getPricing` when it needs to produce a quote. |
There was a problem hiding this comment.
Should this be ProofQuoteGoverner?
No description provided.