deploy: 41a15b5

Review/mip/lock-mint-bridge-rate-limit-basics/MIP/mip-84/index.html

@@ -187,7 +187,7 @@ <h2 id="abstract"><a class="header" href="#abstract">Abstract</a></h2>
 <p>The trust assumptions on the relayer component have significant implications for the security of the bridge and they can introduce the need for additional components.</p>
 <hr />
 <p><img src="image.png" alt="alt text" /></p>
-<p><strong>Figure 1</strong>: The Relayer is in charge of <em>relaying</em> bridge transactions. If a user initiates a bridge transfer request on the Move chain with a transaction $T(s,r,a)$ with a sender $s$, recipient $r$, for an amount $a$, we expect the Relayer to relay the request to Ethereum with a matching transactions $T’(s,r,a)$. However, a compromised or buggy Relayer may tamper with the bridge transfer data and relay $s’, r’, a’$ where #s’, r’, a’$ may differ from $s, r,a$.</p>
+<p><strong>Figure 1</strong>: The Relayer is in charge of <em>relaying</em> bridge transactions. If a user initiates a bridge transfer request on the L2 with a transaction $T(s,r,a)$ with a sender $s$, recipient $r$, for an amount $a$, we expect the Relayer to relay the request to the L1 with a matching transaction $T’(s,r,a)$. However, a compromised or buggy Relayer may tamper with the bridge transfer data and relay $s’, r’, a’$ where $s’, r’, a’$ may differ from $s, r,a$.</p>
 <hr />
 <p>In a scenario based approach we clarify minimally required components and why they are needed. We distinguish between a trusted, partially trusted, and untrusted relayer (with proofs).</p>
 <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
@@ -199,14 +199,13 @@ <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
 </ul>
 <h2 id="specification"><a class="header" href="#specification">Specification</a></h2>
 <blockquote>
-<p>[!NOTE]
-<em>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.</em></p>
+<p><em>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.</em></p>
 </blockquote>
 <p>We define the following terms:</p>
 <ul>
 <li><strong>Trusted</strong> : 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.</li>
-<li><strong>Partially trusted</strong> : 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.</li>
-<li><strong>Untrusted</strong> : 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.</li>
+<li><strong>Partially trusted</strong> : A component is partially trusted if it can have unintentional bugs, or misconfigurations, or worst case gets compromised but in extremely rare occurances. Under normal operations it is secure and reliable. The rarity of these events permits that the operator takes care of resulting hardship. Protective measures should be taken to reduce the maximally caused damage that the component can cause incase it becomes faulty / Byzantine.</li>
+<li><strong>Untrusted</strong> : A component is untrusted if it can become malicious (Byzantine) at any time and frequently. The component can stop/crash or tamper with messages, results of computations. Any action should be approved by a trusted party and require a proof of correctness.</li>
 </ul>
 <h3 id="base-assumptions"><a class="header" href="#base-assumptions">Base assumptions</a></h3>
 <p>We make the following base assumption:</p>
@@ -216,9 +215,9 @@ <h3 id="base-assumptions"><a class="header" href="#base-assumptions">Base assump
 </ul>
 <h3 id="trusted-relayer"><a class="header" href="#trusted-relayer">Trusted Relayer</a></h3>
 <p><strong>Assumption</strong>: The relayer is fully trusted to submit the completion of the transfer to the bridge contracts.</p>
-<p><strong>Risks</strong>: 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.</p>
+<p><strong>Risks</strong>: Since the component is trusted, in principle no risks are associated with it.</p>
 <p><strong>Consequence</strong>:
-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.</p>
+The relayer always submits the correct completion transaction, i.e. without tampering with the sender, receiver and amount. The relayer can transfer without any restrictions. Since the relayer is trusted, no additional components are needed. Furthermore, no additional protective measures are needed.</p>
 <h3 id="partially-trusted-relayer"><a class="header" href="#partially-trusted-relayer">Partially Trusted Relayer</a></h3>
 <p><strong>Assumption</strong>: The relayer is partially trusted to submit the completion of the transfer to the bridge contracts.</p>
 <p><strong>Risk</strong>: The relayer may be erroneous, misconfigured, or compromised. The relayer may submit the completion of the transfer to the bridge contracts with errors.</p>
@@ -230,7 +229,7 @@ <h3 id="partially-trusted-relayer"><a class="header" href="#partially-trusted-re
 <li>Error: The relayer may submit invalid transfers leading to failed transfers.</li>
 </ol>
 <p><strong>Consequence</strong>:</p>
-<p>User is affected: A complaint by the user should be individually handled. A mechanism to accept complaints MAY be provided. The complaint should be handled by a trusted party or a governance component.</p>
+<p>User is affected: A complaint by the user should be individually handled. A mechanism to accept complaints MAY be provided. The complaint should be handled by a trusted party, such as a governance component.</p>
 <p>Abuse / Miscalculation: The Relayer may release (mint) excessively tokens on the L1 (L2). Any token that is released (minted) on the target chain without a corresponding burn (lock) on the source chain will increase the total circulating supply across L1 and L2. However, the Bridge Operator MUST ensure that the total circulating supply of the token remains constant.</p>
 <p><strong>Solution Part 1:</strong>
 The bridge operator MUST learn about the excessive minting (unlocking) through some monitoring system. The monitoring service MAY be only an initial warning system that informs the bridge operator to take action. This action could involve halting the bridge or starting an investigation.</p>
@@ -300,7 +299,7 @@ <h3 id="untrusted-relayer-with-proofs"><a class="header" href="#untrusted-relaye
 <p>The expected time for the completion of the transfer is the time it takes is in the range of Postconfirmations and L1 finality time.</p>
 <h2 id="reference-implementation"><a class="header" href="#reference-implementation">Reference Implementation</a></h2>
 <h2 id="verification"><a class="header" href="#verification">Verification</a></h2>
-<h2 id="change-logs"><a class="header" href="#change-logs">Change logs</a></h2>
+<h2 id="changelog"><a class="header" href="#changelog">Changelog</a></h2>
 <h2 id="appendix"><a class="header" href="#appendix">Appendix</a></h2>
 <h3 id="a1-background-eigenlayer"><a class="header" href="#a1-background-eigenlayer">A1: Background EigenLayer</a></h3>
 <p>In order to protect the protocol from exploits and potential losses, rate limiting is essential. For comparison the white paper <a href="https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf">EigenLayer: The Restaking Collective</a> proposes that AVS (Actively Validated Services) can run for a bridge and the stake of validators protects the transferred value crypto-economically through slashing conditions. More specifically section 3.4 Risk Management mentions</p>

print.html

@@ -4880,7 +4880,7 @@ <h2 id="abstract-32"><a class="header" href="#abstract-32">Abstract</a></h2>
 <p>The trust assumptions on the relayer component have significant implications for the security of the bridge and they can introduce the need for additional components.</p>
 <hr />
 <p><img src="Review/mip/lock-mint-bridge-rate-limit-basics/MIP/mip-84/image.png" alt="alt text" /></p>
-<p><strong>Figure 1</strong>: The Relayer is in charge of <em>relaying</em> bridge transactions. If a user initiates a bridge transfer request on the Move chain with a transaction $T(s,r,a)$ with a sender $s$, recipient $r$, for an amount $a$, we expect the Relayer to relay the request to Ethereum with a matching transactions $T’(s,r,a)$. However, a compromised or buggy Relayer may tamper with the bridge transfer data and relay $s’, r’, a’$ where #s’, r’, a’$ may differ from $s, r,a$.</p>
+<p><strong>Figure 1</strong>: The Relayer is in charge of <em>relaying</em> bridge transactions. If a user initiates a bridge transfer request on the L2 with a transaction $T(s,r,a)$ with a sender $s$, recipient $r$, for an amount $a$, we expect the Relayer to relay the request to the L1 with a matching transaction $T’(s,r,a)$. However, a compromised or buggy Relayer may tamper with the bridge transfer data and relay $s’, r’, a’$ where $s’, r’, a’$ may differ from $s, r,a$.</p>
 <hr />
 <p>In a scenario based approach we clarify minimally required components and why they are needed. We distinguish between a trusted, partially trusted, and untrusted relayer (with proofs).</p>
 <h2 id="motivation-32"><a class="header" href="#motivation-32">Motivation</a></h2>
@@ -4892,14 +4892,13 @@ <h2 id="motivation-32"><a class="header" href="#motivation-32">Motivation</a></h
 </ul>
 <h2 id="specification-31"><a class="header" href="#specification-31">Specification</a></h2>
 <blockquote>
-<p>[!NOTE]
-<em>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.</em></p>
+<p><em>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.</em></p>
 </blockquote>
 <p>We define the following terms:</p>
 <ul>
 <li><strong>Trusted</strong> : 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.</li>
-<li><strong>Partially trusted</strong> : 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.</li>
-<li><strong>Untrusted</strong> : 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.</li>
+<li><strong>Partially trusted</strong> : A component is partially trusted if it can have unintentional bugs, or misconfigurations, or worst case gets compromised but in extremely rare occurances. Under normal operations it is secure and reliable. The rarity of these events permits that the operator takes care of resulting hardship. Protective measures should be taken to reduce the maximally caused damage that the component can cause incase it becomes faulty / Byzantine.</li>
+<li><strong>Untrusted</strong> : A component is untrusted if it can become malicious (Byzantine) at any time and frequently. The component can stop/crash or tamper with messages, results of computations. Any action should be approved by a trusted party and require a proof of correctness.</li>
 </ul>
 <h3 id="base-assumptions"><a class="header" href="#base-assumptions">Base assumptions</a></h3>
 <p>We make the following base assumption:</p>
@@ -4909,9 +4908,9 @@ <h3 id="base-assumptions"><a class="header" href="#base-assumptions">Base assump
 </ul>
 <h3 id="trusted-relayer-1"><a class="header" href="#trusted-relayer-1">Trusted Relayer</a></h3>
 <p><strong>Assumption</strong>: The relayer is fully trusted to submit the completion of the transfer to the bridge contracts.</p>
-<p><strong>Risks</strong>: 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.</p>
+<p><strong>Risks</strong>: Since the component is trusted, in principle no risks are associated with it.</p>
 <p><strong>Consequence</strong>:
-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.</p>
+The relayer always submits the correct completion transaction, i.e. without tampering with the sender, receiver and amount. The relayer can transfer without any restrictions. Since the relayer is trusted, no additional components are needed. Furthermore, no additional protective measures are needed.</p>
 <h3 id="partially-trusted-relayer"><a class="header" href="#partially-trusted-relayer">Partially Trusted Relayer</a></h3>
 <p><strong>Assumption</strong>: The relayer is partially trusted to submit the completion of the transfer to the bridge contracts.</p>
 <p><strong>Risk</strong>: The relayer may be erroneous, misconfigured, or compromised. The relayer may submit the completion of the transfer to the bridge contracts with errors.</p>
@@ -4923,7 +4922,7 @@ <h3 id="partially-trusted-relayer"><a class="header" href="#partially-trusted-re
 <li>Error: The relayer may submit invalid transfers leading to failed transfers.</li>
 </ol>
 <p><strong>Consequence</strong>:</p>
-<p>User is affected: A complaint by the user should be individually handled. A mechanism to accept complaints MAY be provided. The complaint should be handled by a trusted party or a governance component.</p>
+<p>User is affected: A complaint by the user should be individually handled. A mechanism to accept complaints MAY be provided. The complaint should be handled by a trusted party, such as a governance component.</p>
 <p>Abuse / Miscalculation: The Relayer may release (mint) excessively tokens on the L1 (L2). Any token that is released (minted) on the target chain without a corresponding burn (lock) on the source chain will increase the total circulating supply across L1 and L2. However, the Bridge Operator MUST ensure that the total circulating supply of the token remains constant.</p>
 <p><strong>Solution Part 1:</strong>
 The bridge operator MUST learn about the excessive minting (unlocking) through some monitoring system. The monitoring service MAY be only an initial warning system that informs the bridge operator to take action. This action could involve halting the bridge or starting an investigation.</p>
@@ -4993,7 +4992,7 @@ <h3 id="untrusted-relayer-with-proofs"><a class="header" href="#untrusted-relaye
 <p>The expected time for the completion of the transfer is the time it takes is in the range of Postconfirmations and L1 finality time.</p>
 <h2 id="reference-implementation-26"><a class="header" href="#reference-implementation-26">Reference Implementation</a></h2>
 <h2 id="verification-31"><a class="header" href="#verification-31">Verification</a></h2>
-<h2 id="change-logs"><a class="header" href="#change-logs">Change logs</a></h2>
+<h2 id="changelog-2"><a class="header" href="#changelog-2">Changelog</a></h2>
 <h2 id="appendix-27"><a class="header" href="#appendix-27">Appendix</a></h2>
 <h3 id="a1-background-eigenlayer"><a class="header" href="#a1-background-eigenlayer">A1: Background EigenLayer</a></h3>
 <p>In order to protect the protocol from exploits and potential losses, rate limiting is essential. For comparison the white paper <a href="https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf">EigenLayer: The Restaking Collective</a> proposes that AVS (Actively Validated Services) can run for a bridge and the stake of validators protects the transferred value crypto-economically through slashing conditions. More specifically section 3.4 Risk Management mentions</p>
@@ -6250,7 +6249,7 @@ <h2 id="feature-flags"><a class="header" href="#feature-flags">Feature Flags</a>
 <tr><td>80</td><td>NATIVE_MEMORY_OPERATIONS</td><td>True</td><td>True</td><td>True</td><td>null</td><td>False</td></tr>
 </tbody></table>
 </div>
-<h2 id="change-logs-1"><a class="header" href="#change-logs-1">Change Logs</a></h2>
+<h2 id="change-logs"><a class="header" href="#change-logs">Change Logs</a></h2>
 <p><strong>Transparency and Clarity</strong>: Any corrections or updates to this document will be tracked and published here to ensure accuracy.</p>
 <p><strong>Accountability</strong>: Updates will include a reference to the date and version in which the error was identified and corrected.</p>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="welcome-to-the-movement-network-mip-book-7"><a class="header" href="#welcome-to-the-movement-network-mip-book-7">Welcome to the Movement Network MIP Book</a></h1>