diff --git a/404.html b/404.html index a19b8f4..04c8638 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index b94f4d4..cea3675 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index d7fbe56..8853aa5 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index e3a441c..5229416 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index 207d3aa..b2ebbc6 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index e4bb4e5..4213a64 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index 6728a1e..042eec1 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html index 6e55663..07f9a9d 100644 --- a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html +++ b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index a473d5e..77b6751 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 5e71763..4a44ac6 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0026-sassafras-consensus.html b/approved/0026-sassafras-consensus.html index 15b8921..6cd09af 100644 --- a/approved/0026-sassafras-consensus.html +++ b/approved/0026-sassafras-consensus.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index c36b15a..6584026 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index 801e7dd..d2f99f9 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index 238fde0..ba0a34f 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0045-nft-deposits-asset-hub.html b/approved/0045-nft-deposits-asset-hub.html index 32a62fb..f483273 100644 --- a/approved/0045-nft-deposits-asset-hub.html +++ b/approved/0045-nft-deposits-asset-hub.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index ddd7b6f..65285e7 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0048-session-keys-runtime-api.html b/approved/0048-session-keys-runtime-api.html index 726cd28..5ea506a 100644 --- a/approved/0048-session-keys-runtime-api.html +++ b/approved/0048-session-keys-runtime-api.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index d1520e7..32025fd 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index e149143..f87332a 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 0b38952..5348017 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/approved/0078-merkleized-metadata.html b/approved/0078-merkleized-metadata.html index 539f212..f6efac6 100644 --- a/approved/0078-merkleized-metadata.html +++ b/approved/0078-merkleized-metadata.html @@ -90,7 +90,7 @@ diff --git a/approved/0084-general-transaction-extrinsic-format.html b/approved/0084-general-transaction-extrinsic-format.html index fa26bfb..62c6153 100644 --- a/approved/0084-general-transaction-extrinsic-format.html +++ b/approved/0084-general-transaction-extrinsic-format.html @@ -90,7 +90,7 @@ diff --git a/approved/0091-dht-record-creation-time.html b/approved/0091-dht-record-creation-time.html index acb7260..7585956 100644 --- a/approved/0091-dht-record-creation-time.html +++ b/approved/0091-dht-record-creation-time.html @@ -90,7 +90,7 @@ diff --git a/approved/0097-unbonding_queue.html b/approved/0097-unbonding_queue.html index 059d11f..482f119 100644 --- a/approved/0097-unbonding_queue.html +++ b/approved/0097-unbonding_queue.html @@ -90,7 +90,7 @@ diff --git a/approved/0099-transaction-extension-version.html b/approved/0099-transaction-extension-version.html index 8d10a2c..5fe6081 100644 --- a/approved/0099-transaction-extension-version.html +++ b/approved/0099-transaction-extension-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0101-xcm-transact-remove-max-weight-param.html b/approved/0101-xcm-transact-remove-max-weight-param.html index 0d6e89a..2a20cde 100644 --- a/approved/0101-xcm-transact-remove-max-weight-param.html +++ b/approved/0101-xcm-transact-remove-max-weight-param.html @@ -90,7 +90,7 @@ diff --git a/approved/0108-xcm-remove-testnet-ids.html b/approved/0108-xcm-remove-testnet-ids.html index f7b3375..d0bdad2 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index f981e6c..32301c4 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index f981e6c..32301c4 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0111-pure-proxy-replication.html b/new/0111-pure-proxy-replication.html index 489ee82..f0a2fc0 100644 --- a/new/0111-pure-proxy-replication.html +++ b/new/0111-pure-proxy-replication.html @@ -90,7 +90,7 @@ diff --git a/new/0112-compress-state-response-message-in-state-sync.html b/new/0112-compress-state-response-message-in-state-sync.html index 66bbedb..8aad176 100644 --- a/new/0112-compress-state-response-message-in-state-sync.html +++ b/new/0112-compress-state-response-message-in-state-sync.html @@ -90,7 +90,7 @@ @@ -253,7 +253,7 @@ for compression. - @@ -267,7 +267,7 @@ for compression. - diff --git a/new/0114-secp256r1-hostfunction.html b/new/0114-secp256r1-hostfunction.html new file mode 100644 index 0000000..a5abadc --- /dev/null +++ b/new/0114-secp256r1-hostfunction.html @@ -0,0 +1,305 @@ + + + + + + + RFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signatures - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signatures

+
+ + + +
Start Date16 August 2024
DescriptionHost function to verify NIST-P256 elliptic curve signatures.
AuthorsRodrigo Quelhas
+
+

Summary

+

This RFC proposes a new host function, secp256r1_ecdsa_verify_prehashed, for verifying NIST-P256 signatures. The function takes as input the message hash, r and s components of the signature, and the x and y coordinates of the public key. By providing this function, runtime authors can leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures, reducing computational costs and improving overall performance.

+

Motivation

+

“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a host function can provide signature verifications using the “secp256r1” elliptic curve in the runtime and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this host function could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices. +Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this host function enables a more efficient verification of device native transaction signing mechanisms. For example:

+
    +
  1. Apple's Secure Enclave: There is a separate “Trusted Execution Environment” in Apple hardware which can sign arbitrary messages and can only be accessed by biometric identification.
    2. +
  2. Webauthn: Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn aims to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. It is being used by almost all of the modern web browsers.
    3. +
  3. Android Keystore: Android Keystore is an API that manages the private keys and signing methods. The private keys are not processed while using Keystore as the applications’ signing method. Also, it can be done in the “Trusted Execution Environment” in the microchip.
    4. +
  4. Passkeys: Passkeys is utilizing FIDO Alliance and W3C standards. It replaces passwords with cryptographic key-pairs which is also can be used for the elliptic curve cryptography.
    5. +
+

Stakeholders

+
    +
  • Runtime Authors
    • +
+

Explanation

+

This RFC proposes a new host function for runtime authors to leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures.

+

Proposed host function signature:

+
#![allow(unused)]
+fn main() {
+fn ext_secp256r1_ecdsa_verify_prehashed_version_1(
+    sig: &[u8; 64],
+    msg: &[u8; 32],
+    pub_key: &[u8; 64],
+) -> bool;
+}
+

The host function MUST return true if the signature is valid or false otherwise.

+

Drawbacks

+

N/A

+

Testing, Security, and Privacy

+

Security

+

The changes are not directly affecting the protocol security, parachains are not enforced to use the host function.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

N/A

+

Ergonomics

+

The host function proposed in this RFC allows parachain runtime developers to use a more efficient verification mechanism for "secp256r1" elliptic curve signatures.

+

Compatibility

+

Parachain teams will need to include this host function to upgrade.

+

Prior Art and References

+ + +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index fe7b1e7..26b0d8c 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -377,261 +377,82 @@ for compression.

None.

None.

-

(source)

+

(source)

Table of Contents

-

RFC-0089: Flexible Inflation

+

RFC-0114: Introduce secp256r1_ecdsa_verify_prehashed Host Function to verify NIST-P256 elliptic curve signatures

- - - + + +
Start DateMay 6 2024
DescriptionRevise the inflation logic in the runtime such that it can be parameterized and tweaked in an easier and more transparent way.
AuthorsKian Paimani
Start Date16 August 2024
DescriptionHost function to verify NIST-P256 elliptic curve signatures.
AuthorsRodrigo Quelhas

Summary

-

This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves -inflation machinery of the Polkadot relay chain in a number of ways:

-
    -
  1. More transparent and easier to understand inflation logic
    2. -
  2. Easier parameterization through governance
    3. -
  3. Decoupled from the staking logic, should inflation and staking happen in two disjoint consensus -systems, as proposed -RFC32.
    4. -
+

This RFC proposes a new host function, secp256r1_ecdsa_verify_prehashed, for verifying NIST-P256 signatures. The function takes as input the message hash, r and s components of the signature, and the x and y coordinates of the public key. By providing this function, runtime authors can leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures, reducing computational costs and improving overall performance.

Motivation

-

The existing inflation logic in the relay chain suffers from a number of drawbacks:

- -

This RFC, as iterated above, proposes a new pallet_inflation that addresses all of the named -problems. However, this RFC does not propose any changes to the actual inflation rate, but -rather provide a new technical substrate (pun intended), upon which token holders can decide on the -future of the DOT token's inflation in a more clear and transparent way.

-

We argue that one reason why the inflation rate of Polkadot has not significantly change in ~4 years -has been the complicated process of updating it. We hope that with the tools provided in this RFC, -stakeholders can experiment with the inflation rate in a more ergonomic way. Finally, this -experimentation can be considered useful as a final step toward fixing the economics of DOT in JAM, -as proposed in the JAM graypaper.

-

Within the scope of this RFC, we suggest deploying the new inflation pallet in a backwards -compatible way, such that the inflation model does not change in practice, and leave the actual -changes to the token holders and researchers and further governance proposals.

-
-

While mainly intended for Polkadot, the system proposed in this RFC is general enough such that it -can be interpreted as a "general inflation system pallet", and can be used in newly onboarding -parachain.

-
+

“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a host function can provide signature verifications using the “secp256r1” elliptic curve in the runtime and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this host function could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices. +Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this host function enables a more efficient verification of device native transaction signing mechanisms. For example:

+
    +
  1. Apple's Secure Enclave: There is a separate “Trusted Execution Environment” in Apple hardware which can sign arbitrary messages and can only be accessed by biometric identification.
    2. +
  2. Webauthn: Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn aims to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. It is being used by almost all of the modern web browsers.
    3. +
  3. Android Keystore: Android Keystore is an API that manages the private keys and signing methods. The private keys are not processed while using Keystore as the applications’ signing method. Also, it can be done in the “Trusted Execution Environment” in the microchip.
    4. +
  4. Passkeys: Passkeys is utilizing FIDO Alliance and W3C standards. It replaces passwords with cryptographic key-pairs which is also can be used for the elliptic curve cryptography.
    5. +

Stakeholders

-

This RFC is relevant to the following stakeholders, listed from high to low impact:

Explanation

-

Existing Order

-

First, let's further elaborate on the existing order. The current inflation logic is deeply nested -in pallet_staking, and pallet_staking::Config::EraPayout interface. Through this trait, the -staking pallet is informed how many new tokens should possibly be minted. This amount is divided -into two parts:

- -

As it stands now the implementation of EraPayout which specifies the two amounts above lives in -the respective runtime, and uses the original proposed inflation rate proposed by W3F for Polkadot. -Read more about this model here.

-

At present, the inflation always happens at the end of an era, which is a concept know by the -staking system. The duration of an era is recorded in pallet_staking as milliseconds (as recorded -by the standard pallet_timestamp), is passed to EraPayout as an input, as is measured against -the full year to determine how much should be inflated.

-

New Order

-
-

The naming used in this section is tentative, based on a WIP implementation, and subject to change -before finalization of this RFC.

-
-

The new order splits the process for inflation into two steps:

-
    -
  1. Sourcing the inflation amount: This step merely specifies by how much the chain intends to -inflate its token. This amount is not minted right away, and is instead passed over to the next -step for distribution.
    2. -
  2. Distributing the aforementioned amount: A sequence of functions that decide what needs to be -done with the sourced inflation amount. This process is expected to transfer the inflation -amount to any account that should receive it. This implies that the staking system should, -similar to treasury, have a key-less account that will act as a temporary pot for the inflation -amount.
    3. -
-

In very abstract terms, an example of the above process can be:

- -

A proper configuration of this pallet should use pallet_parameters where possible to allow for any -of the actual values used to specify Sourcing and Distribution to be changed via on-chain -governance. Please see the example configurations section for more -details.

-

In the new model, inflation can happen at any point in time. Since now a new pallet is dedicated to -inflation, and it can internally store the timestamp of the last inflation point, and always inflate -the correct amount. This means that while the duration of a staking era is 1 day, the inflation -process can happen eg. every hour. The opposite is also possible, although more complicated: The -staking/treasury system can possibly receive their corresponding income on a weekly basis, while the -era duration is still 1 day. That being said, we don't recommend using this flexibility as it brings -no clear advantage, and is only extra complexity. We recommend the inflation to still happen shortly -before the end of the staking era. This means that if the inflation sourcing or distribution is -a function of the staking rate, it can reliably use the staking rate of the last era.

-

Finally, as noted above, this RFC implies a new accounting system for staking to keep track of its -staking reward. In short, the new process is as follows: pallet_inflation will mint the staking -portion of inflation directly into a key-less account controlled by pallet_staking. At the end of -each era, pallet_staking will inspect this account, and move whatever amount is paid out into it -to another key-less account associated with the era number. The actual payouts, initiated by stakers, -will transfer from this era account into the corresponding stakers' account.

-
-

Interestingly, this means that any account can possibly contribute to staking rewards by -transferring DOTs to the key-less parent account controlled by the staking system.

-
-

Proposed Implementation

-

A candidate implementation of this RFC can be found in -this -branch of the polkadot-sdk repository. Please note the changes to:

-
    -
  1. substrate/frame/inflation to see the new pallet.
    2. -
  2. substrate/frame/staking to see the integration with the staking pallet.
    3. -
  3. substrate/bin/runtime to see how the pallet can be configured into a runtime.
    4. -
-

Example Configurations

-

The following are working examples from the above implementation candidate, highlighting some of the -outcomes that can be achieved.

-

First, to parameterize the existing proposed implementation to replicate what Polkadot does today, -assuming we incorporate the fixed 2% treasury income, the outcome would be:

+

This RFC proposes a new host function for runtime authors to leverage a more efficient verification mechanism for "secp256r1" elliptic curve signatures.

+

Proposed host function signature:

#![allow(unused)]
 fn main() {
-parameter_types! {
-	pub Distribution: Vec<pallet_inflation::DistributionStep<Runtime>> = vec![
-		// 2% goes to treasury, no questions asked.
-		Box::new(pay::<Runtime, TreasuryAccount, dynamic_params::staking::FixedTreasuryIncome>),
-		// from whatever is left, staking gets all the rest, based on the staking rate.
-		Box::new(polkadot_staking_income::<
-			Runtime,
-			dynamic_params::staking::IdealStakingRate,
-			dynamic_params::staking::Falloff,
-			StakingIncomeAccount
-		>),
-		// Burn anything that is left.
-		Box::new(burn::<Runtime, All>),
-	];
-}
-
-impl pallet_inflation::Config for Runtime {
-	/// Fixed 10% annual inflation.
-	type InflationSource =
-		pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>;
-	type Distribution = Distribution;
-}
+fn ext_secp256r1_ecdsa_verify_prehashed_version_1(
+    sig: &[u8; 64],
+    msg: &[u8; 32],
+    pub_key: &[u8; 64],
+) -> bool;
 }
-

In this snippet, we use a number of components provided by pallet_inflation, namely pay, -polkadot_staking_income, burn and FixedRatioAnnualInflation. Yet, crucially, these components -are fed parameters that are all backed by an instance of the pallet_parameters, namely everything -prefixed by dynamic_params.

-

The above is a purely inflationary system. If one wants to change the inflation to -dis-inflationary, another pre-made component of pallet_inflation can be used:

-
impl pallet_inflation::Config for Runtime {
--	/// Fixed 10% annual inflation.
--	type InflationSource =
--		pallet_inflation::FixedRatioAnnualInflation<Runtime, dynamic_params::staking::MaxInflation>;
-+	type InflationSource = pallet_inflation::FixedAnnualInflation<
-+		Runtime,
-+		dynamic_params::staking::FixedAnnualInflationAmount,
-+	>;
-}
-
-

Whereby FixedAnnualInflationAmount is the fixed absolute value (as opposed to ratio) by -which the chain inflates annually, for example 100m DOTs.

+

The host function MUST return true if the signature is valid or false otherwise.

Drawbacks

-

The following drawbacks are noted:

-
    -
  1. The solution provided here is possibly an over-engineering, if we want to achieve the goal of -making the existing formula parameterize-able. In that case, we can merely add an instance of the -pallet_parameters to the runtime and make the existing formula's ratios be provided by -governance-controlled parameters. Although, this shortsighted but simpler solution fails to -decouple the staking and inflation logic. This will be an issue depending on whether staking -lives in AssetHub, or its independent parachain.
    2. -
  2. Some of the interfaces proposed in the draft implementation still leak the implementation detail -of the inflation amount being reliant on eg. the staking-rate. We acknowledge this as a drawback, -but given that many PoS inflationary systems rely on the staking rate, we believe it is a -reasonable compromise. Such parameters can be ignored if the implementation does not need them.
    3. -
+

N/A

Testing, Security, and Privacy

-

The new pallet_inflation, among its integration into pallet_staking must be thoroughly audited -and reviewed by fellows. We also emphasize on simulating the actual inflation logic using the real -polkadot state with Chopsticks and try-runtime.

+

Security

+

The changes are not directly affecting the protocol security, parachains are not enforced to use the host function.

Performance, Ergonomics, and Compatibility

-

The proposed system in this RFC implies a handful of extra storage reads and writes "per inflation -cycle", but given that a reasonable instance of this pallet would probably decide to inflation eg. -once per day, the performance impact is negligible.

-

The drawback section above noted some ergonomic concerns.

-

The "New Order" section above notes the compatibility notes with the existing staking -and inflation system.

+

Performance

+

N/A

+

Ergonomics

+

The host function proposed in this RFC allows parachain runtime developers to use a more efficient verification mechanism for "secp256r1" elliptic curve signatures.

+

Compatibility

+

Parachain teams will need to include this host function to upgrade.

Prior Art and References

-

Unresolved Questions

- - -

(source)

Table of Contents

@@ -728,7 +549,7 @@ the pallet design as it stands, this is very unlikely.
  • Comprehensive unit tests and integration tests should be developed to ensure the correct functionality of smart contracts.
  • Test scenarios should include various use cases and edge cases to validate the robustness of the implementation.
    • -

    Security

    +

    Security

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance

    -

    Ergonomics

    +

    Ergonomics

    -

    Compatibility

    +

    Compatibility

    -

    Unresolved Questions

    +

    Unresolved Questions

    - + @@ -1451,12 +1271,25 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).

    Summary

    -

    Elastic scaling is not resilient against griefing attacks without a way for a PoV (Proof of Validity) to commit to the particular core index it was intended for. This RFC proposes a way to include core index information in the candidate commitments and the CandidateDescriptor data structure in a backwards compatible way. Additionally it proposes the addition of a SessionIndex field in the CandidateDescriptor to make dispute resolution more secure and robust.

    +

    Elastic scaling is not resilient against griefing attacks without a way for a PoV (Proof of Validity) +to commit to the particular core index it was intended for. This RFC proposes a way to include +core index information in the candidate commitments and the CandidateDescriptor data structure +in a backwards compatible way. Additionally it proposes the addition of a SessionIndex field in +the CandidateDescriptor to make dispute resolution more secure and robust.

    Motivation

    This RFC proposes a way to solve two different problems:

      -
    1. For Elastic Scaling, it prevents anyone who has acquired a valid collation to DoS the parachain by providing the same collation to all backing groups assigned to the parachain. This can happen before the next valid parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core.
      2. -
    2. The dispute protocol relies on validators trusting the session index provided by other valdiators when initiating and participating in disputes. It is used to lookup validator keys and check dispute vote signatures. By adding a SessionIndex in the CandidateDescriptor, validators no longer have to trust the Sessionindex provided by the validator raising a dispute. It can happen that the dispute concerns a relay chain block not yet imported by a validator. In this case validators can safely assume the session index refers to the session the candidate has appeared in, otherwise the chain would have rejected candidate.
      3. +
    3. For Elastic Scaling, it prevents anyone who has acquired a valid collation to DoS the parachain +by providing the same collation to all backing groups assigned to the parachain. This can +happen before the next valid parachain block is authored and will prevent the chain of +candidates to be formed, reducing the throughput of the parachain to a single core.
      4. +
    4. The dispute protocol relies on validators trusting the session index provided by other +validators when initiating and participating in disputes. It is used to lookup validator keys +and check dispute vote signatures. By adding a SessionIndex in the CandidateDescriptor, +validators no longer have to trust the Sessionindex provided by the validator raising a +dispute. It can happen that the dispute concerns a relay chain block not yet imported by a +validator. In this case validators can safely assume the session index refers to the session +the candidate has appeared in, otherwise the chain would have rejected candidate.

    Stakeholders

    -

    Unresolved Questions

    +

    Unresolved Questions

    None at this time.

    - +

    There may exist in the future system chains for which this model of collator selection is not appropriate. These chains should be evaluated on a case-by-case basis.

    (source)

    @@ -2923,21 +2792,21 @@ Furthermore, when a large number of providers (here, a provider is a bootnode) a Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term.

    Furthermore, parachain clients are expected to cache a list of known good nodes on their disk. If the mechanism described in this RFC went down, it would only prevent new nodes from accessing the parachain, while clients that have connected before would not be affected.

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance

    The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours.

    Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode.

    Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.

    Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.

    -

    Ergonomics

    +

    Ergonomics

    Irrelevant.

    -

    Compatibility

    +

    Compatibility

    Irrelevant.

    Prior Art and References

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    While it fundamentally doesn't change much to this RFC, using BabeApi_currentEpoch and BabeApi_nextEpoch might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet?

    - +

    It is possible that in the future a client could connect to a parachain without having to rely on a trusted parachain specification.

    (source)

    Table of Contents

    @@ -3083,7 +2952,7 @@ ones.

    Prior Art and References

    The launch of the Technical Fellowship, see the initial forum post.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None at this time.

    (source)

    Table of Contents

    @@ -3162,13 +3031,13 @@ multi-block migrations available.

    Security: n/a

    Privacy: n/a

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance

    The performance overhead is minimal in the sense that no clutter was added after fulfilling the requirements. The only performance difference is that initialize_block also returns an enum that needs to be passed through the WASM boundary. This should be negligible.

    -

    Ergonomics

    +

    Ergonomics

    The new interface allows for more extensible runtime logic. In the future, this will be utilized for multi-block-migrations which should be a huge ergonomic advantage for parachain developers.

    -

    Compatibility

    +

    Compatibility

    The advice here is OPTIONAL and outside of the RFC. To not degrade user experience, it is recommended to ensure that an updated node can still import historic blocks.

    Prior Art and References

    @@ -3181,14 +3050,14 @@ transactions
  • There is no module hook after inherents and before transactions
    • -

    Unresolved Questions

    +

    Unresolved Questions

    Please suggest a better name for BlockExecutiveMode. We already tried: RuntimeExecutiveMode, ExtrinsicInclusionMode. The names of the modes Normal and Minimal were also called AllExtrinsics and OnlyInherents, so if you have naming preferences; please post them.
    => renamed to ExtrinsicInclusionMode

    Is post_inherents more consistent instead of last_inherent? Then we should change it.
    => renamed to last_inherent

    - +

    The long-term future here is to move the block building logic into the runtime. Currently there is a tight dance between the block author and the runtime; the author has to call into different runtime functions in quick succession and exact order. Any misstep causes the block to be invalid.
    This can be unified and simplified by moving both parts into the runtime.

    (source)

    @@ -3306,11 +3175,11 @@ This can be unified and simplified by moving both parts into the runtime.

    The implementation of this RFC will be tested on testnets (Rococo and Westend) first.

    An audit maybe required to ensure the implementation does not introduce unwanted side effects.

    There is no privacy related concerns.

    -

    Performance

    +

    Performance

    This RFC should not introduce any performance impact.

    -

    Ergonomics

    +

    Ergonomics

    This RFC should improve the developer experiences for new and existing parachain teams

    -

    Compatibility

    +

    Compatibility

    This RFC is fully compatibility with existing interfaces.

    Prior Art and References

    -

    Unresolved Questions

    +

    Unresolved Questions

    None at this stage.

    - +

    This RFC is only intended to be a short term solution. Slots will be removed in future and lock mechanism is likely going to be replaced with a more generalized parachain manage & recovery system in future. Therefore long term impacts of this RFC are not considered.

    1

    https://github.com/paritytech/cumulus/issues/377 @@ -3383,9 +3252,9 @@ This can be unified and simplified by moving both parts into the runtime.

    No changes

    Prior Art and References

    Existing Encointer runtime repo

    -

    Unresolved Questions

    +

    Unresolved Questions

    None identified

    - +

    More info on Encointer: encointer.org

    (source)

    Table of Contents

    @@ -4481,16 +4350,16 @@ may require some optimizations to deal with constraints.

    useful in developement.

    Performance, Ergonomics, and Compatibility

    Describe the impact of the proposal on the exposed functionality of Polkadot.

    -

    Performance

    +

    Performance

    This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its primary resources are allocated to system performance.

    -

    Ergonomics

    +

    Ergonomics

    This proposal alters very little for coretime users (e.g. parachain developers). Application developers will need to interact with multiple chains, making ergonomic light client tools particularly important for application development.

    For existing parachains that interact with these subsystems, they will need to configure their runtimes to recognize the new locations in the network.

    -

    Compatibility

    +

    Compatibility

    Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol. Application developers will need to interact with multiple chains in the network.

    Prior Art and References

    @@ -4498,11 +4367,11 @@ Application developers will need to interact with multiple chains in the network
  • Transactionless Relay-chain
  • Moving Staking off the Relay Chain
    • -

    Unresolved Questions

    +

    Unresolved Questions

    There remain some implementation questions, like how to use balances for both Staking and Governance. See, for example, Moving Staking off the Relay Chain.

    - +

    Ideally the Relay Chain becomes transactionless, such that not even balances are represented there. With Staking and Governance off the Relay Chain, this is not an unreasonable next step.

    With Identity on Polkadot, Kusama may opt to drop its People Chain.

    @@ -4592,19 +4461,19 @@ so that chains know which system_version to use.

    AFAIK, should not have any impact on the security or privacy.

    Performance, Ergonomics, and Compatibility

    These changes should be compatible for existing chains if they use state_version value for system_verision.

    -

    Performance

    +

    Performance

    I do not believe there is any performance hit with this change.

    -

    Ergonomics

    +

    Ergonomics

    This does not break any exposed Apis.

    -

    Compatibility

    +

    Compatibility

    This change should not break any compatibility.

    Prior Art and References

    We proposed introducing a similar change by introducing a parameter to frame_system::Config but did not feel that is the correct way of introducing this change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    I do not have any specific questions about this change at the moment.

    - +

    IMO, this change is pretty self-contained and there won't be any future work necessary.

    (source)

    Table of Contents

    @@ -4658,11 +4527,11 @@ is the correct way of introducing this change.

    }

    The host function MUST return an unsigned 64-bit integer value representing the current proof size. In block-execution and block-import contexts, this function MUST return the current size of the proof. To achieve this, parachain node implementors need to enable proof recording for block imports. In other contexts, this function MUST return 18446744073709551615 (u64::MAX), which represents disabled proof recording.

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance

    Parachain nodes need to enable proof recording during block import to correctly implement the proposed host function. Benchmarking conducted with balance transfers has shown a performance reduction of around 0.6% when proof recording is enabled.

    -

    Ergonomics

    +

    Ergonomics

    The host function proposed in this RFC allows parachain runtime developers to keep track of the proof size. Typical usage patterns would be to keep track of the overall proof size or the difference between subsequent calls to the host function.

    -

    Compatibility

    +

    Compatibility

    Parachain teams will need to include this host function to upgrade.

    Prior Art and References

    -

    Summary

    +

    Summary

    This RFC proposes the addition of a secondary market feature to either the broker pallet or as a separate pallet maintained by Lastic, enabling users to list and purchase regions. This includes creating, purchasing, and removing listings, as well as emitting relevant events and handling associated errors.

    -

    Motivation

    +

    Motivation

    Currently, the broker pallet lacks functionality for a secondary market, which limits users' ability to freely trade regions. This RFC aims to introduce a secure and straightforward mechanism for users to list regions they own for sale and allow other users to purchase these regions.

    While integrating this functionality directly into the broker pallet is one option, another viable approach is to implement it as a separate pallet maintained by Lastic. This separate pallet would have access to the broker pallet and add minimal functionality necessary to support the secondary market.

    Adding smart contracts to the Coretime chain could also address this need; however, this process is expected to be lengthy and complex. We cannot afford to wait for this extended timeline to enable basic secondary market functionality. By proposing either integration into the broker pallet or the creation of a dedicated pallet, we can quickly enhance the flexibility and utility of the broker pallet, making it more user-friendly and valuable.

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholders include:

    -

    Explanation

    +

    Explanation

    This RFC introduces the following key features:

    1. @@ -8909,16 +9034,16 @@ Implement call filters. This will allow multisig accounts to only accept certain
    -

    Drawbacks

    +

    Drawbacks

    The main drawback of adding the additional complexity directly to the broker pallet is the potential increase in maintenance overhead. Therefore, we propose adding additional functionality as a separate pallet on the Coretime chain. To take the pressure off from implementing these features, implementation along with unit tests would be taken care of by Lastic (Aurora Makovac, Philip Lucsok).

    There are potential risks of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments. Therefore, extensive security measures would have to be implemented.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Testing

    -

    Security

    +

    Security

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholders are:

    -

    Explanation

    +

    Explanation

    Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements.

    -

    Drawbacks

    +

    Drawbacks

    Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    Describe the impact of the proposal on the exposed functionality of Polkadot.

    -

    Performance

    +

    Performance

    Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead?

    -

    Ergonomics

    +

    Ergonomics

    If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?

    -

    Compatibility

    +

    Compatibility

    Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any.

    -

    Prior Art and References

    +

    Prior Art and References

    Provide references to either prior art or other relevant research for the submitted design.

    Unresolved Questions

    Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear.

    diff --git a/proposed/00xx-smart-contracts-coretime-chain.html b/proposed/00xx-smart-contracts-coretime-chain.html index be5c362..fbe710e 100644 --- a/proposed/00xx-smart-contracts-coretime-chain.html +++ b/proposed/00xx-smart-contracts-coretime-chain.html @@ -90,7 +90,7 @@ @@ -321,7 +321,7 @@