[review] MIP-84: Lock-Mint Native Bridge: Basics of Relayer trust assumptions #84
Conversation
apenzk
changed the title
MIP/mip-84/README.md
Outdated
| We define the following terms: | ||
|
|
||
| - **Trusted** : A component is trusted if it is assumed to be secure and reliable. No errors in the component can occur. Nor keys can get compromised. | ||
| - **Partially trusted** : A component is partially trusted if it is assumed that under normal operations it is secure and reliable. However, errors may occur due to bugs, misconfigurations, or other reasons. Furthermore, the question is raised if the software component is secure. Protective measures should be taken to reduce the maximally caused damage that the component can cause incase it becomes malicious or faulty. |
There was a problem hiding this comment.
for partially trusted, I would use: a component is partially trusted if it can unintentional bugs, misconfigurations.
There was a problem hiding this comment.
added. but do you think we should remove the byzantine behaviour altogether? and if so why?
There was a problem hiding this comment.
@franck44 i changed the language in the document to
- trusted
- untrusted
- insurance-based untrusted
- approval/proof-based untrusted
is this better?
MIP/mip-84/README.md
Outdated
|
|
||
| - **Trusted** : A component is trusted if it is assumed to be secure and reliable. No errors in the component can occur. Nor keys can get compromised. | ||
| - **Partially trusted** : A component is partially trusted if it is assumed that under normal operations it is secure and reliable. However, errors may occur due to bugs, misconfigurations, or other reasons. Furthermore, the question is raised if the software component is secure. Protective measures should be taken to reduce the maximally caused damage that the component can cause incase it becomes malicious or faulty. | ||
| - **Untrusted** : A component is untrusted if it is assumed that it is not secure and reliable. Any action should be approved by a trusted party and require a proof of correctness. |
There was a problem hiding this comment.
A component is untrusted if it can be malicious (Byzantine). Tge component can stop/crash or tamper with messages, results of computations.
|
|
||
| _The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174._ | ||
|
|
||
| We define the following terms: |
There was a problem hiding this comment.
If you think about it, there is not much difference between partially trusted and untrusted.
Any behaviour an untrusted relayer can exhinit can be simulated by a partially trusted relayer with a corresponding "bug".
In DS, we usually don't distinguish between intentional and unintentional erroneous components because the visible behaviours are the same.
There was a problem hiding this comment.
But the response is different. For an untrusted component I assumed the following
Any action should be approved by a trusted party and require a proof of correctness.
Section "Untrusted Relayer":
- in case of ZK we require a ZK proof before applying
- in case of optimistic we wait for 7 days before applying
- in case of FFS we require a committee signature
This does not hold true for the partially trusted Relayer. There we apply the transaction without any way of reverting and rather soon. If the Relayer becomes faulty/malicious the protocol owner compensates the supply.
There was a problem hiding this comment.
OK, I see. However I am not sure we should make a difference between faulty (bug) or compromised (taken control of) when wee compensate users.
There was a problem hiding this comment.
that is correct. i fixed this in the untrusted case now
MIP/mip-84/README.md
Outdated
|
|
||
| **Assumption**: The relayer is fully trusted to submit the completion of the transfer to the bridge contracts. | ||
|
|
||
| **Risks**: Since the component is trusted, in principle no risks are associated with it. The risk lies in the trust assumption. If the Relayer software component becomes malicious or faulty, the bridge is compromised, potentially leading to significant loss of funds bounds. |
There was a problem hiding this comment.
I would remove:
The risk lies in the trust assumption. If the Relayer software component becomes malicious or faulty, the bridge is compromised, potentially leading to significant loss of funds bounds.
MIP/mip-84/README.md
Outdated
| **Risks**: Since the component is trusted, in principle no risks are associated with it. The risk lies in the trust assumption. If the Relayer software component becomes malicious or faulty, the bridge is compromised, potentially leading to significant loss of funds bounds. | ||
|
|
||
| **Consequence**: | ||
| The relayer can submit the completion of the transfer to the bridge contracts without any restrictions. Since the relayer is trusted, no additional components are needed. Furthermore, no additional protective measures are needed. |
There was a problem hiding this comment.
The relayer always submits the correct completion transaction, i.e. without tampering with the sender, receiver and amount.
There was a problem hiding this comment.
modified towards this
apenzk
changed the title
apenzk
added
Ready to Review
Summary
MIP-84