mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-06-19 21:01:04 +00:00
deploy: 85ca3ff275
This commit is contained in:
bkchr
@@ -217,10 +217,10 @@
|
||||
<p>This analysis of censorship resistance for AURA-based parachains operates under the following assumptions:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p><strong>Collator Honesty:</strong> The model assumes the presence of at least one honest collator. We intentionally chose the most relaxed security assumption as collators are not slashable (unlike validators). Note that all system parachains use AURA via the <a href="https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/pallets/aura-ext">Aura-Ext</a> pallet. </p>
|
||||
<p><strong>Collator Honesty:</strong> The model assumes the presence of at least one honest collator. We intentionally chose the most relaxed security assumption as collators are not slashable (unlike validators). Note that all system parachains use AURA via the <a href="https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/pallets/aura-ext">Aura-Ext</a> pallet.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Backer Honesty:</strong> The backer assigned to a block candidate is assumed to be honest. This is a reasonable assumption given 2/3rd honesty on relay-chain and that backers are assigned randomly by <a href="https://eprint.iacr.org/2024/961.pdf">ELVES</a>.</p>
|
||||
<p><strong>Backer Honesty:</strong> The backer assigned to a block candidate is assumed to be honest. This is a reasonable assumption given 2/3rd honesty on relay-chain and that backers are assigned randomly by <a href="https://eprint.iacr.org/2024/961.pdf">ELVES</a>. Additionally, we assume that backers responsible for disbursing the withheld block to the victim collators. Pre-PVFs can definitely help in improving the resilience of backers against DoS attacks. Essentially, the pre PVF lets backers check the slot ownership and hence backers can filter out spamming collators at this stage. However, pre-PVFs have not yet been implemented. The stronger on assumption on backer disbursing the block is only needed for efficiency concerns and not essential for censorship resistance itself (i.e. the collator can always reconstruct from the availability layer). </p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Availability Layer:</strong> We also assume that the availability layer is robust and a collator can fetch the latest parablock (header and body) directly from the availability layer (or the backer) in a reasonable time, i.e., <6s from backer and <18s from availability layer provided by ELVES. </p>
|
||||
@@ -236,15 +236,13 @@
|
||||
<h3 id="proposed-solution"><a class="header" href="#proposed-solution">Proposed Solution</a></h3>
|
||||
<p>This proposal modifies the AURA round-robin mechanism to assign $x$ consecutive slots to each collator. The specific value of $x$ is contingent upon asynchronous backing parameters od the system parachain and will be derived using a generic formula provided in this document. The collator selected by AURA will be responsible for producing $x$ consecutive blocks. This modification will require corresponding adjustments to the AURA authorship checks within the PVF (Parachain Validation Function). For the current configuration of Polkadot Hub, $x=4$.</p>
|
||||
<h3 id="analysis"><a class="header" href="#analysis">Analysis</a></h3>
|
||||
<p>The number of consecutive slots to be assigned to ensure AURA's censorship resistance depends on Async Backing Parameters like <code>unincluded_segment_lenght</code>. We now describe our approach to deriving $x$ based on paramters of async backing and other variables like block production and latency in availability layer. The relevant values can then be plugged in to obtain $x$ for any system parachain. </p>
|
||||
<p>Clearly, the number of consecutive slots (x) in the round-robin is lower bounded by the time required to reconstruct the previous block from the availability layer (b) in addition to the block building time (a). Hence, we need to set $x$ such that $x\geq a+b$. But with async backing, a malicious collator sequentially tries to not share the block and just-in-time front-run the honest collator for all the unincluded_segment blocks. Hence, we require $x\geq (a+b)\cdot m$, where $m$ is the max allowed candidate depth (unincluded segment allowed). </p>
|
||||
<p>Independently, there is a check on the relay chain which filters out parablocks anchoring to very old relay_parents in the <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/inclusion/mod.rs#L1237"><code>verify_backed_candidates</code></a>. Any parablock which is anchored to a relay parent older than the oldest element in <code>allowed_relay_parents</code> gets rejected. Hence, the malicious collator can not front-run and censor the consequent collator after this delay as the parablock is no longer valid. The update of the allowed_relay_parents occurs at <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/paras_inherent/mod.rs#L321"><code>process_inherent_data</code></a> where the buffer length of AllowedRelayParents is set by the scheduler parameter: <a href="https://github.com/paritytech/polkadot-sdk/blob/875437c4aecf99e1f0ffeb8278a3b0b0017acbc2/polkadot/primitives/src/v8/mod.rs#L2148"><code>lookahead</code></a> (set to 3 by default). Therefore, the async_backing delay ($async_delay$) tolerated by the relay chain backers is $3*6s = 18s$. Hence, the number of consecutive slots is the minimum of the above two values:</p>
|
||||
<p>$$
|
||||
x \geq min((a+b)\cdot m, a + b + async_delay)
|
||||
$$
|
||||
where $m$ is the $max_candidate_depth$ (or unincluded segment as seen from collator's perpective). </p>
|
||||
<p>The number of consecutive slots to be assigned to ensure AURA's censorship resistance depends on Async Backing Parameters like <code>unincluded_segment_length</code>. We now describe our approach for deriving $x$ based on paramters of async backing and other variables like block production and latency in availability layer. The relevant values can then be plugged in to obtain $x$ for any system parachain. </p>
|
||||
<p>Clearly, the number of consecutive slots (x) in the round-robin is lower bounded by the time required to reconstruct the previous block from the availability layer (b) in addition to the block building time (a). Hence, we need to set $x$ such that $x\geq a+b$. But with async backing, a malicious collator sequentially tries to not share the block and just-in-time front-run the honest collator for all the unincluded_segment blocks. Hence, $x\geq (a+b)\cdot m$ is sufficient, where $m$ is the max allowed candidate depth (unincluded segment allowed). </p>
|
||||
<p>Independently, there is a check on the relay chain which filters out parablocks anchoring to very old relay_parents in the <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/inclusion/mod.rs#L1237"><code>verify_backed_candidates</code></a>. Any parablock which is anchored to a relay parent older than the oldest element in <code>allowed_relay_parents</code> gets rejected. Hence, the malicious collator can not front-run and censor the consequent collator after this delay as the parablock is no longer valid. The update of the allowed_relay_parents occurs at <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/paras_inherent/mod.rs#L321"><code>process_inherent_data</code></a> where the buffer length of AllowedRelayParents is set by the scheduler parameter: <a href="https://github.com/paritytech/polkadot-sdk/blob/875437c4aecf99e1f0ffeb8278a3b0b0017acbc2/polkadot/primitives/src/v8/mod.rs#L2148"><code>lookahead</code></a> (set to 3 by default). Therefore, the async_backing delay (<code>asyncdelay</code>) tolerated by the relay chain backers is $3*6s = 18s$. Hence, the number of consecutive slots is the minimum of the above two values:</p>
|
||||
<p>$$x \geq min((a+b)\cdot m, a + b + asyncdelay)$$</p>
|
||||
<p>where $m$ is the <code>max_candidate_depth</code> (or unincluded segment as seen from collator's perpective). </p>
|
||||
<h3 id="number-of-consecutive-slots-for-polkadot-hub"><a class="header" href="#number-of-consecutive-slots-for-polkadot-hub">Number of consecutive slots for Polkadot Hub</a></h3>
|
||||
<p>Assuming the previous block data can be fetched from backers, then we comfortably have $a+b \leq 6s$, i.e. block buiding plus recoinstruciton time is < 6s. Using the current async_delay of 18s, suffices to set $x$ to 4. If the max_candidate_depth (m) for plaza is set $m\leq3$, then this will reduce (improve) $x$ from 4 to $m$. Note that a channel would have to be provided for collators to fetch blocks from backers as the preferred option and only recover from availability layer as the fail-safe option. </p>
|
||||
<p>Assuming the previous block data can be fetched from backers, then we comfortably have $a+b \leq 6s$, i.e. block buiding plus recoinstruciton time is < 6s. Using the current <code>asyncdelay</code> of 18s, suffices to set $x$ to 4. If the <code>max_candidate_depth</code> (m) for Polkadot Hub is set $m\leq3$, then this will reduce (improve) $x$ from 4 to $m$. Note that a channel would have to be provided for collators to fetch blocks from backers as the preferred option and only recover from availability layer as the fail-safe option. </p>
|
||||
<h2 id="performance-ergonomics-and-compatibility"><a class="header" href="#performance-ergonomics-and-compatibility">Performance, Ergonomics, and Compatibility</a></h2>
|
||||
<p>The proposed changes are security critical and mitigate censorship attacks on core functionality like balances, staking and governance on Polkadot Hub.
|
||||
This approach is compatible with the Slot-Based collation and the currently deployed FixedVelocityConsensusHook. Further analysis is needed to integrate with cusotm ConsesnsusHooks that leverage Elastic Scaling. </p>
|
||||
@@ -258,8 +256,10 @@ This approach is compatible with the Slot-Based collation and the currently depl
|
||||
<h2 id="prior-art-and-references"><a class="header" href="#prior-art-and-references">Prior Art and References</a></h2>
|
||||
<p>This RFC is related to RFC-7, which details the selection mechanism for System Parachain Collators. In general, a more robust collator selection mechanism that reduces the proportion of malicious actors would directly benefit the effectiveness of the ideas presented in this RFC</p>
|
||||
<h2 id="future-directions"><a class="header" href="#future-directions">Future Directions</a></h2>
|
||||
<p>A resilient mechanism is needed for prioritising transactions in block production for collators that are actively targeted for censorship. There are two potential approches:</p>
|
||||
<ul>
|
||||
<li>An immediate next step is to categorise which transactions or extrinsics are more likely to be censored and should be considered priority. This would allow an honest collator to maximize the utility of its consecutive block production slots and prioritise when building the uncensored block. While this is dependent on the specific parachain's functionality, a generic framework would be beneficial for runtime engineers to tag relevant transaction types.</li>
|
||||
<li>One approach is to categorise which transactions or extrinsics are more likely to be censored and should be considered priority. This would allow an honest collator to maximize the utility of its consecutive block production slots and prioritise when building the uncensored block. While this is dependent on the specific parachain's functionality, a generic framework would be beneficial for runtime engineers to tag relevant transaction types. However, if there exist transactions which are cheap and high priority (e.g. a governance vote), this approach is not ideal as it lets an adversary spam the collators with cheap high-priority transactions.</li>
|
||||
<li>AAlternatively, one could design a robust tipping mechanism where transaction actively being censored would have to pay a higher tip to get themselves included. Even if the adversary initiates a bidding war, since 100% of the tip is forwarded to the collator, it only increase the revenue of the collator further incentivising it to remain honest. A careful analysis of such an incentive mechanism is required, however, it is beyond the scope of this RFC.</li>
|
||||
</ul>
|
||||
|
||||
</main>
|
||||
|
||||
+11
-11
@@ -223,10 +223,10 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
|
||||
<p>This analysis of censorship resistance for AURA-based parachains operates under the following assumptions:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p><strong>Collator Honesty:</strong> The model assumes the presence of at least one honest collator. We intentionally chose the most relaxed security assumption as collators are not slashable (unlike validators). Note that all system parachains use AURA via the <a href="https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/pallets/aura-ext">Aura-Ext</a> pallet. </p>
|
||||
<p><strong>Collator Honesty:</strong> The model assumes the presence of at least one honest collator. We intentionally chose the most relaxed security assumption as collators are not slashable (unlike validators). Note that all system parachains use AURA via the <a href="https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/pallets/aura-ext">Aura-Ext</a> pallet.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Backer Honesty:</strong> The backer assigned to a block candidate is assumed to be honest. This is a reasonable assumption given 2/3rd honesty on relay-chain and that backers are assigned randomly by <a href="https://eprint.iacr.org/2024/961.pdf">ELVES</a>.</p>
|
||||
<p><strong>Backer Honesty:</strong> The backer assigned to a block candidate is assumed to be honest. This is a reasonable assumption given 2/3rd honesty on relay-chain and that backers are assigned randomly by <a href="https://eprint.iacr.org/2024/961.pdf">ELVES</a>. Additionally, we assume that backers responsible for disbursing the withheld block to the victim collators. Pre-PVFs can definitely help in improving the resilience of backers against DoS attacks. Essentially, the pre PVF lets backers check the slot ownership and hence backers can filter out spamming collators at this stage. However, pre-PVFs have not yet been implemented. The stronger on assumption on backer disbursing the block is only needed for efficiency concerns and not essential for censorship resistance itself (i.e. the collator can always reconstruct from the availability layer). </p>
|
||||
</li>
|
||||
<li>
|
||||
<p><strong>Availability Layer:</strong> We also assume that the availability layer is robust and a collator can fetch the latest parablock (header and body) directly from the availability layer (or the backer) in a reasonable time, i.e., <6s from backer and <18s from availability layer provided by ELVES. </p>
|
||||
@@ -242,15 +242,13 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
|
||||
<h3 id="proposed-solution"><a class="header" href="#proposed-solution">Proposed Solution</a></h3>
|
||||
<p>This proposal modifies the AURA round-robin mechanism to assign $x$ consecutive slots to each collator. The specific value of $x$ is contingent upon asynchronous backing parameters od the system parachain and will be derived using a generic formula provided in this document. The collator selected by AURA will be responsible for producing $x$ consecutive blocks. This modification will require corresponding adjustments to the AURA authorship checks within the PVF (Parachain Validation Function). For the current configuration of Polkadot Hub, $x=4$.</p>
|
||||
<h3 id="analysis"><a class="header" href="#analysis">Analysis</a></h3>
|
||||
<p>The number of consecutive slots to be assigned to ensure AURA's censorship resistance depends on Async Backing Parameters like <code>unincluded_segment_lenght</code>. We now describe our approach to deriving $x$ based on paramters of async backing and other variables like block production and latency in availability layer. The relevant values can then be plugged in to obtain $x$ for any system parachain. </p>
|
||||
<p>Clearly, the number of consecutive slots (x) in the round-robin is lower bounded by the time required to reconstruct the previous block from the availability layer (b) in addition to the block building time (a). Hence, we need to set $x$ such that $x\geq a+b$. But with async backing, a malicious collator sequentially tries to not share the block and just-in-time front-run the honest collator for all the unincluded_segment blocks. Hence, we require $x\geq (a+b)\cdot m$, where $m$ is the max allowed candidate depth (unincluded segment allowed). </p>
|
||||
<p>Independently, there is a check on the relay chain which filters out parablocks anchoring to very old relay_parents in the <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/inclusion/mod.rs#L1237"><code>verify_backed_candidates</code></a>. Any parablock which is anchored to a relay parent older than the oldest element in <code>allowed_relay_parents</code> gets rejected. Hence, the malicious collator can not front-run and censor the consequent collator after this delay as the parablock is no longer valid. The update of the allowed_relay_parents occurs at <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/paras_inherent/mod.rs#L321"><code>process_inherent_data</code></a> where the buffer length of AllowedRelayParents is set by the scheduler parameter: <a href="https://github.com/paritytech/polkadot-sdk/blob/875437c4aecf99e1f0ffeb8278a3b0b0017acbc2/polkadot/primitives/src/v8/mod.rs#L2148"><code>lookahead</code></a> (set to 3 by default). Therefore, the async_backing delay ($async_delay$) tolerated by the relay chain backers is $3*6s = 18s$. Hence, the number of consecutive slots is the minimum of the above two values:</p>
|
||||
<p>$$
|
||||
x \geq min((a+b)\cdot m, a + b + async_delay)
|
||||
$$
|
||||
where $m$ is the $max_candidate_depth$ (or unincluded segment as seen from collator's perpective). </p>
|
||||
<p>The number of consecutive slots to be assigned to ensure AURA's censorship resistance depends on Async Backing Parameters like <code>unincluded_segment_length</code>. We now describe our approach for deriving $x$ based on paramters of async backing and other variables like block production and latency in availability layer. The relevant values can then be plugged in to obtain $x$ for any system parachain. </p>
|
||||
<p>Clearly, the number of consecutive slots (x) in the round-robin is lower bounded by the time required to reconstruct the previous block from the availability layer (b) in addition to the block building time (a). Hence, we need to set $x$ such that $x\geq a+b$. But with async backing, a malicious collator sequentially tries to not share the block and just-in-time front-run the honest collator for all the unincluded_segment blocks. Hence, $x\geq (a+b)\cdot m$ is sufficient, where $m$ is the max allowed candidate depth (unincluded segment allowed). </p>
|
||||
<p>Independently, there is a check on the relay chain which filters out parablocks anchoring to very old relay_parents in the <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/inclusion/mod.rs#L1237"><code>verify_backed_candidates</code></a>. Any parablock which is anchored to a relay parent older than the oldest element in <code>allowed_relay_parents</code> gets rejected. Hence, the malicious collator can not front-run and censor the consequent collator after this delay as the parablock is no longer valid. The update of the allowed_relay_parents occurs at <a href="https://github.com/paritytech/polkadot-sdk/blob/ec700de9cdca84cdf5d9f501e66164454c2e3b7d/polkadot/runtime/parachains/src/paras_inherent/mod.rs#L321"><code>process_inherent_data</code></a> where the buffer length of AllowedRelayParents is set by the scheduler parameter: <a href="https://github.com/paritytech/polkadot-sdk/blob/875437c4aecf99e1f0ffeb8278a3b0b0017acbc2/polkadot/primitives/src/v8/mod.rs#L2148"><code>lookahead</code></a> (set to 3 by default). Therefore, the async_backing delay (<code>asyncdelay</code>) tolerated by the relay chain backers is $3*6s = 18s$. Hence, the number of consecutive slots is the minimum of the above two values:</p>
|
||||
<p>$$x \geq min((a+b)\cdot m, a + b + asyncdelay)$$</p>
|
||||
<p>where $m$ is the <code>max_candidate_depth</code> (or unincluded segment as seen from collator's perpective). </p>
|
||||
<h3 id="number-of-consecutive-slots-for-polkadot-hub"><a class="header" href="#number-of-consecutive-slots-for-polkadot-hub">Number of consecutive slots for Polkadot Hub</a></h3>
|
||||
<p>Assuming the previous block data can be fetched from backers, then we comfortably have $a+b \leq 6s$, i.e. block buiding plus recoinstruciton time is < 6s. Using the current async_delay of 18s, suffices to set $x$ to 4. If the max_candidate_depth (m) for plaza is set $m\leq3$, then this will reduce (improve) $x$ from 4 to $m$. Note that a channel would have to be provided for collators to fetch blocks from backers as the preferred option and only recover from availability layer as the fail-safe option. </p>
|
||||
<p>Assuming the previous block data can be fetched from backers, then we comfortably have $a+b \leq 6s$, i.e. block buiding plus recoinstruciton time is < 6s. Using the current <code>asyncdelay</code> of 18s, suffices to set $x$ to 4. If the <code>max_candidate_depth</code> (m) for Polkadot Hub is set $m\leq3$, then this will reduce (improve) $x$ from 4 to $m$. Note that a channel would have to be provided for collators to fetch blocks from backers as the preferred option and only recover from availability layer as the fail-safe option. </p>
|
||||
<h2 id="performance-ergonomics-and-compatibility"><a class="header" href="#performance-ergonomics-and-compatibility">Performance, Ergonomics, and Compatibility</a></h2>
|
||||
<p>The proposed changes are security critical and mitigate censorship attacks on core functionality like balances, staking and governance on Polkadot Hub.
|
||||
This approach is compatible with the Slot-Based collation and the currently deployed FixedVelocityConsensusHook. Further analysis is needed to integrate with cusotm ConsesnsusHooks that leverage Elastic Scaling. </p>
|
||||
@@ -264,8 +262,10 @@ This approach is compatible with the Slot-Based collation and the currently depl
|
||||
<h2 id="prior-art-and-references"><a class="header" href="#prior-art-and-references">Prior Art and References</a></h2>
|
||||
<p>This RFC is related to RFC-7, which details the selection mechanism for System Parachain Collators. In general, a more robust collator selection mechanism that reduces the proportion of malicious actors would directly benefit the effectiveness of the ideas presented in this RFC</p>
|
||||
<h2 id="future-directions"><a class="header" href="#future-directions">Future Directions</a></h2>
|
||||
<p>A resilient mechanism is needed for prioritising transactions in block production for collators that are actively targeted for censorship. There are two potential approches:</p>
|
||||
<ul>
|
||||
<li>An immediate next step is to categorise which transactions or extrinsics are more likely to be censored and should be considered priority. This would allow an honest collator to maximize the utility of its consecutive block production slots and prioritise when building the uncensored block. While this is dependent on the specific parachain's functionality, a generic framework would be beneficial for runtime engineers to tag relevant transaction types.</li>
|
||||
<li>One approach is to categorise which transactions or extrinsics are more likely to be censored and should be considered priority. This would allow an honest collator to maximize the utility of its consecutive block production slots and prioritise when building the uncensored block. While this is dependent on the specific parachain's functionality, a generic framework would be beneficial for runtime engineers to tag relevant transaction types. However, if there exist transactions which are cheap and high priority (e.g. a governance vote), this approach is not ideal as it lets an adversary spam the collators with cheap high-priority transactions.</li>
|
||||
<li>AAlternatively, one could design a robust tipping mechanism where transaction actively being censored would have to pay a higher tip to get themselves included. Even if the adversary initiates a bidding war, since 100% of the tip is forwarded to the collator, it only increase the revenue of the collator further incentivising it to remain honest. A careful analysis of such an incentive mechanism is required, however, it is beyond the scope of this RFC.</li>
|
||||
</ul>
|
||||
<div style="break-before: page; page-break-before: always;"></div><p><a href="https://github.com/polkadot-fellows/RFCs/pull/119">(source)</a></p>
|
||||
<p><strong>Table of Contents</strong></p>
|
||||
|
||||
+1
-1
File diff suppressed because one or more lines are too long
+1
-1
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user