[review] MIP-74: Rate-Limiter for the Lock/Mint-type Native Bridge + MD-74: Rate-Limiter for the Lock/Mint-type Native Bridge #74
Conversation
apenzk
changed the title
|
Is the idea to have this completed before https://github.com/movementlabsxyz/MIP/pull/73/files is ready for review? Seems to me btw unless I have misunderstood that RateLimiting we will also want to be a manual operation. We could automate it and have it react to the Informer and I don't see any risks in increasing the Rate Limit based on the Informer. Even if we were to get some mad monitoring event from the Informer, in the worst case, the Rate Limit would only be increased. Cautionary, automated reaction probably good. |
3 can be independent of this MIP, MIP-73 provides an entry point and show how everything comes together so i am not sure there is a clear order
We have two different trust assumptions
we have to treat these different. the target chain rate limit protects also against compromise or errors on 2. It also protects against wrong information of the informer. the maximum rate limit MUST be set by func(Insurance fund, human reaction time) (e.g. absolute max_rate= insurance fund / human reaction). I think there could be several thresholds, some of which dynamic.
|
apenzk
changed the title
MIP/mip-74/README.md
Outdated
| 1. **Rate Limiter**: The Rate Limiter is a set of contracts (one on the L1 and one on the L2) that is used to limit the volume of transferred value per time window. | ||
|
|
||
|  | ||
| _Figure 1: Architecture of the Rate Limitation_ |
There was a problem hiding this comment.
@apenzk
In Figure 1, It is not clear to me what "sets parameters" means vs "sets limit".
I would simplify the figure as follows:
- user "sends" (rather than "attempts")
- is the governance a contract on L2? If not, it may located outside of the yellow box.
- what are the parameters, and is limit a parameter? Are there any constriants between the different "limits"?
- why is the opertor instructing the governance and not the opposite?
There was a problem hiding this comment.
- replaced by "requests transfer"
- its on L2
- limit = f(insurance fund, reaction time, reduction factor), governance can set the latter two, the constraints between the limits are described in the text of the document. does it need improving?
- its the governance operator, will change operator -> governance operator
There was a problem hiding this comment.
@apenzk The figure has a few glitches:
- L2 Bridge Contract used in the picture but L2 Native Bridge Contract in the text
- L2 bridge contract on L1, should be L1 Bridge contract.
I have added () around thr Native attribute in the text, so that may fix 1. but I have not modified the figure.
There was a problem hiding this comment.
updated figure and text.
MIP/mip-74/README.md
Outdated
|
|
||
| The following risks are associated with the Native Bridge: | ||
|
|
||
| 1. The trusted relayer is compromised or faulty. We thus want to ensure that the relayer has not unlimited power to release or mint assets. For this we MUST implement a rate limiter on the target chain. |
There was a problem hiding this comment.
That seems to contradict that the relayer is trusted.
If it can be faulty, it is not trusted.
There was a problem hiding this comment.
"partially trusted" ?
"trusted (to a large extend)" ?
MIP/mip-74/README.md
Outdated
| 1. In order to rate limit the bridge (e.g. stop the bridge transfers entirely) there should be a higher instance than the relayer in setting rate limits. Thus the rate limit on the target chain SHOULD be set by the Operator. | ||
| 1. The Relayer may go down, while the number of transactions and requested transfer value across the bridge still increases on the source chain. Due to rate limit on the target chain the Relayer may struggle to process all initiated transfers. Thus the Relayer or the Operator MUST rate limit the source chain as well. | ||
|
|
||
| ### Rate-Limiter |
There was a problem hiding this comment.
@apenzk
Would it makes sense to list the expected properties (as per above) and what they guarantee to the operator and the user?
There was a problem hiding this comment.
there is the "Risks and mitigation strategy" section. Do you think it is to convoluted?
MIP/mip-74/README.md
Outdated
| - property 2 | ||
| - property 3 ... | ||
|
|
||
| ### Rate-Limiter |
There was a problem hiding this comment.
@apenzk
Can you confirm this is correct?
And add anything you think is relevant to tis section?
There was a problem hiding this comment.
i have added several points to the "Objectives" section
MIP/mip-74/README.md
Outdated
|
|
||
| `max_rate_limit_target = insurance_fund_target / reaction_time`, | ||
|
|
||
| where the `reaction_time` is the time it takes for the Operator to react to a faulty or compromised component. The `reaction_time` is a parameter that is set by the Operator. The Operator MAY set the actual rate limit lower than the `max_rate_limit_target`. However the Rate Limiter MUST NOT set the rate limit higher than the `max_rate_limit_target`. |
There was a problem hiding this comment.
@apenzk
I suggest to break this into two independent parts:
- property if the rate limit and max_rate limit etc
- permissions: who can set what.
At the moment I find this section confusing with the Rate limier, the Operator etc so it may need to be clarified.
There was a problem hiding this comment.
i tried to improve, wdyt?
franck44
added
Ready to Review
MIP/mip-74/README.md
Outdated
| The following algorithm is a recommendation for the operation of the Relayer: | ||
|
|
||
| **(Optional) Algorithm for the Relayer** | ||
|
|
There was a problem hiding this comment.
@apenzk I am not sure we need to do anything with the Relayer. If a transaction is not processed within a given amount of time (for any reason, network down etc), the Relayer should re-send it to ensure it evetually succeeds.
There was a problem hiding this comment.
This was to avoid excessive costs to the relayer incase the budget is consumed on the target chain but is not consumed on the source chain. i have removed it as it is an optimisation that we can handle once we discover it actually is an issue.
| `rate_limit_source = min{rate_reduction_source * rate_limit_target, rate_limit_operator_source}`, | ||
|
|
||
| where `rate_reduction_source` $\in$ `[0,1]` is a parameter that is set by the Relayer. `rate_limit_operator_source` is a parameter that is set by the Governance Operator. Note the `rate_limit_source` SHOULD not be larger than `rate_limit_operator_source`. | ||
|
|
There was a problem hiding this comment.
@apenzk So it looks like there is a need for synchronising the rate limits on both the source and traget and the relayer can do that. We could use this sync mechanism to simplify the rate limiter I think.
I would assume that as long as less than insurance_fund1 is currently "in-flight" we are OK, so we may try to measure that.
Assume we are bridging from L2 to L1.
If we know that an amount insurance_fund1 then we can cover the loss (there is no need for a time window).
To know that this the case, we need to keep track of the completed Txs and another conponent can do that (or the Relayer).
When a bridge Tx from L2 to L1, anount
On another note, I am a bit confused about the wording/naming here. Why do we need a rate?
If we have a unique Tx with the maximum amount insurance_fund1 we should first clear this Tx before we continue to process new ones.
Would it be the role of the Informer to do this kind of things (syncing L2 <-> L1)?
There was a problem hiding this comment.
I would assume that as long as less than insurance_fund1 is currently "in-flight" we are OK, so we may try to measure that.
...
To know that this the case, we need to keep track of the completed Txs and another conponent can do that (or the Relayer).
as discussed above with @Primata sliding windows or reseting budget based on completing transactions seems out of scope for this version. I suggest we move more complicated versions over to a new MIP.
There was a problem hiding this comment.
worth noting:
There is a valid case where the relayer should set the rate limit on the source chain: if the operator fails to adjust the rate limit on the source chain when ajusting the rate limit on the target chain (by changing insurance fund or reaction time).
There was a problem hiding this comment.
I think the main thing for the relayer to implement is holding transaction until it's able to complete on target chain.
- Worst case scenario users need to wait for 24hrs.
- This would allow us to also inform the user on the source chain that there is a difference between source chain and target chain rate limit budget. That would be the
in-flightvalue.
There was a problem hiding this comment.
if the rate limit on the source chain is much larger than on the target chain, it is could be much more than 24h.
but yes, the relayer would need to be able to hold. or in a simple implementation he would just retry continuously which is handled by MIP-61
| 1. **Insurance Fund**: The Insurance Fund is a pool of tokens held in a contract that is used to cover potential losses in case of a faulty component, see [MIP-50](https://github.com/movementlabsxyz/MIP/pull/50). | ||
| 1. **Rate Limiter**: The Rate Limiter is a set of contracts (one on the L1 and one on the L2) that is used to limit the volume of transferred value per time window. | ||
|
|
||
|  |
There was a problem hiding this comment.
Believe that we need to change the role that sets the rate limit to DEFAULT_ADMIN instead of RELAYER. We won't have access to setting limit because the relayer won't be accessible to us. There are other ADMIN functionalities that are at the same risk level. We can have a hot role for emergency PAUSER_ROLE. It could be assigned to all engineers so that anyone could pause initiate_bridge_transfer calls.
There was a problem hiding this comment.
yes, the Bridge Operator should also set the rate limit.
the relayer could read programmatically the required data from L1, and thus set the rate limit programmatically.
There was a problem hiding this comment.
Not also, it should be exclusively done by DEFAULT ADMIN, that's what I meant
|
|
||
| #### Insurance funds | ||
|
|
||
| We assume there is a Insurance Fund on both L1 and L2, with values `insurance_fund_L1` and `insurance_fund_L2`, respectively. |
There was a problem hiding this comment.
should we add here that the insurance fund could be the movement labs multisig? it lives both on L1 and L2.
There was a problem hiding this comment.
i am not sure what means "the insurance fund could be the movement labs multisig". is this a specific account, like Mvmt Labs account?
There was a problem hiding this comment.
The multisig you are part of
|
|
||
| #### Rate limit on the source chain | ||
|
|
||
| On the source chain the rate limit MUST be limited by the Governance Operator to match the rate limit on the target chain. if only the target chain would be rate limited users could successfully continue to request transfers on the source chain while the budget on the target chain is already consumed. Consequently the Relayer would not be capable to complete the transfers. |
There was a problem hiding this comment.
Not sure I was able to understand the difference between the target and source chain rate limits. aren't they the same?
There was a problem hiding this comment.
yes the source chain rate limit should be less or equal to the target chain rate limit (on average). but since there is no correlation between L1 and L2 insurance fund in the design in this MIP, the question here is how can he source chain rate limit be set correctly.
franck44
added
MD
apenzk
changed the title
Summary
MD-74
MIP-74