From 32756cd61b0a9a6ecfeacde0392453e0c070ee19 Mon Sep 17 00:00:00 2001 From: bkchr Date: Tue, 3 Dec 2024 01:11:45 +0000 Subject: [PATCH] deploy: 5f4b778e474071800fec98a71363e9733cc96033 --- 404.html | 2 +- approved/0001-agile-coretime.html | 2 +- approved/0005-coretime-interface.html | 2 +- approved/0007-system-collator-selection.html | 2 +- approved/0008-parachain-bootnodes-dht.html | 2 +- approved/0010-burn-coretime-revenue.html | 2 +- ...12-process-for-adding-new-collectives.html | 2 +- ...uilder-and-core-runtime-apis-for-mbms.html | 2 +- ...rove-locking-mechanism-for-parachains.html | 2 +- approved/0022-adopt-encointer-runtime.html | 2 +- approved/0026-sassafras-consensus.html | 2 +- approved/0032-minimal-relay.html | 2 +- approved/0042-extrinsics-state-version.html | 2 +- .../0043-storage-proof-size-hostfunction.html | 2 +- approved/0045-nft-deposits-asset-hub.html | 2 +- ...047-assignment-of-availability-chunks.html | 2 +- approved/0048-session-keys-runtime-api.html | 2 +- approved/0050-fellowship-salaries.html | 2 +- ...0056-one-transaction-per-notification.html | 2 +- .../0059-nodes-capabilities-discovery.html | 2 +- approved/0078-merkleized-metadata.html | 2 +- ...-general-transaction-extrinsic-format.html | 2 +- approved/0091-dht-record-creation-time.html | 2 +- approved/0097-unbonding_queue.html | 2 +- .../0099-transaction-extension-version.html | 2 +- .../0100-xcm-multi-type-asset-transfer.html | 2 +- ...-xcm-transact-remove-max-weight-param.html | 2 +- .../0103-introduce-core-index-commitment.html | 2 +- approved/0105-xcm-improved-fee-mechanism.html | 2 +- approved/0107-xcm-execution-hints.html | 2 +- approved/0108-xcm-remove-testnet-ids.html | 2 +- .../0122-alias-origin-on-asset-transfers.html | 2 +- index.html | 2 +- introduction.html | 2 +- print.html | 1334 ++++++++--------- proposed/0111-pure-proxy-replication.html | 6 +- proposed/0124-extrinsic-version-5.html | 6 +- proposed/0125-xcm-asset-metadata.html | 2 +- proposed/0126-introduce-xcq.html | 2 +- ...alidating-Ethereum-Optimistic-Rollups.html | 2 +- searchindex.js | 2 +- searchindex.json | 2 +- stale/0000-rewards.html | 2 +- ...04-remove-unnecessary-allocator-usage.html | 2 +- ...namic-pricing-for-bulk-coretime-sales.html | 2 +- ...09-improved-net-light-client-requests.html | 2 +- stale/0015-market-design-revisit.html | 2 +- ...-absolute-location-account-derivation.html | 2 +- ...ction-voting-delegation-modifications.html | 2 +- stale/0044-rent-based-registration.html | 2 +- stale/0054-remove-heap-pages.html | 2 +- stale/0070-x-track-kusamanetwork.html | 2 +- stale/0073-referedum-deposit-track.html | 2 +- stale/0074-stateful-multisig-pallet.html | 2 +- ...gth-of-identity-pgp-fingerprint-value.html | 2 +- ...t-purchaser-reputation-reserved-cores.html | 2 +- ...0xx-secondary-marketplace-for-regions.html | 2 +- .../00xx-smart-contracts-coretime-chain.html | 2 +- ...2-offchain-parachain-runtime-upgrades.html | 2 +- stale/0106-xcm-remove-fees-mode.html | 6 +- ...-state-response-message-in-state-sync.html | 10 +- stale/0114-secp256r1-hostfunction.html | 6 +- stale/0117-unbrick-collective.html | 2 +- ...enda-confirmation-by-candle-mechanism.html | 2 +- stale/0121-iterable-referenda-tracks.html | 2 +- ...storage-location-for-runtime-upgrades.html | 2 +- ...ust Tipper Track Confirmation Periods.html | 2 +- stale/TODO-stale-nomination-reward-curve.html | 2 +- 68 files changed, 746 insertions(+), 746 deletions(-) rename {proposed => stale}/0112-compress-state-response-message-in-state-sync.html (61%) diff --git a/404.html b/404.html index 95f1dad..c95dfef 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 e1c8637..c861029 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 650abc8..50c6f84 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 df786f2..a3a7da7 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 4cbb72f..84ef02f 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 e87ecb1..5641fcb 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 be84496..9aef1d0 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 9217d6d..eef9929 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 51ad12f..3424356 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 0331686..eb2ec68 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 8e44f32..8264b48 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 1a49655..8b1146f 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 5e32b53..92e8dd3 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 39bc189..cc61c58 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 63622f4..d7ff372 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 742a62f..b682750 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 2523cfa..8d9de23 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 8e2975a..ba15ef9 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 19a6c7f..455727e 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 900aecd..a23b6c3 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 e3c200d..8b2b04f 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 7a00ad7..8a1d180 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 e297fc2..3611fbc 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 867cdbe..3bf9bf6 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 b69c50f..783f106 100644 --- a/approved/0099-transaction-extension-version.html +++ b/approved/0099-transaction-extension-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0100-xcm-multi-type-asset-transfer.html b/approved/0100-xcm-multi-type-asset-transfer.html index 8b6d71f..fc30cda 100644 --- a/approved/0100-xcm-multi-type-asset-transfer.html +++ b/approved/0100-xcm-multi-type-asset-transfer.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 a158fe7..a486f0c 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/0103-introduce-core-index-commitment.html b/approved/0103-introduce-core-index-commitment.html index f17af00..b2c2a32 100644 --- a/approved/0103-introduce-core-index-commitment.html +++ b/approved/0103-introduce-core-index-commitment.html @@ -90,7 +90,7 @@ diff --git a/approved/0105-xcm-improved-fee-mechanism.html b/approved/0105-xcm-improved-fee-mechanism.html index 119370d..122e5b2 100644 --- a/approved/0105-xcm-improved-fee-mechanism.html +++ b/approved/0105-xcm-improved-fee-mechanism.html @@ -90,7 +90,7 @@ diff --git a/approved/0107-xcm-execution-hints.html b/approved/0107-xcm-execution-hints.html index 7cd2041..a9f076c 100644 --- a/approved/0107-xcm-execution-hints.html +++ b/approved/0107-xcm-execution-hints.html @@ -90,7 +90,7 @@ diff --git a/approved/0108-xcm-remove-testnet-ids.html b/approved/0108-xcm-remove-testnet-ids.html index 65453e8..33a23db 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/approved/0122-alias-origin-on-asset-transfers.html b/approved/0122-alias-origin-on-asset-transfers.html index 3fcf268..aebd5a1 100644 --- a/approved/0122-alias-origin-on-asset-transfers.html +++ b/approved/0122-alias-origin-on-asset-transfers.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index c1467a1..a43373f 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index c1467a1..a43373f 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/print.html b/print.html index e25c1a7..a568f12 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -307,76 +307,6 @@ mod pallet_proxy_replica { -

(source)

-

Table of Contents

- -

RFC-0112: Compress the State Response Message in State Sync

-
- - - -
Start Date14 August 2024
DescriptionCompress the state response message to reduce the data transfer during the state syncing
AuthorsLiu-Cheng Xu
-
-

Summary

-

This RFC proposes compressing the state response message during the state syncing process to reduce the amount of data transferred.

-

Motivation

-

State syncing can require downloading several gigabytes of data, particularly for blockchains with large state sizes, such as Astar, which -has a state size exceeding 5 GiB (https://github.com/AstarNetwork/Astar/issues/1110). This presents a significant -challenge for nodes with slower network connections. Additionally, the current state sync implementation lacks a persistence feature (https://github.com/paritytech/polkadot-sdk/issues/4), -meaning any network disruption forces the node to re-download the entire state, making the process even more difficult.

-

Stakeholders

-

This RFC benefits all projects utilizing the Substrate framework, specifically in improving the efficiency of state syncing.

- -

Explanation

-

The largest portion of the state response message consists of either CompactProof or Vec<KeyValueStateEntry>, depending on whether a proof is requested (source):

- -

Drawbacks

-

None identified.

-

Testing, Security, and Privacy

-

The code changes required for this RFC are straightforward: compress the state response on the sender side and decompress it on the receiver side. Existing sync tests should ensure functionality remains intact.

-

Performance, Ergonomics, and Compatibility

-

Performance

-

This RFC optimizes network bandwidth usage during state syncing, particularly for blockchains with gigabyte-sized states, while introducing negligible CPU overhead for compression and decompression. For example, compressing the state response during a recent Polkadot warp sync (around height #22076653) reduces the data transferred from 530,310,121 bytes to 352,583,455 bytes — a 33% reduction, saving approximately 169 MiB of data.

-

Performance data is based on this patch, with logs available here.

-

Ergonomics

-

None.

-

Compatibility

-

No compatibility issues identified.

-

Prior Art and References

-

None.

-

Unresolved Questions

-

None.

- -

None.

(source)

Table of Contents

-

Drawbacks

+

Drawbacks

The metadata will have to accommodate two distinct extrinsic format versions at a given point in time in order to provide the new functionality in a non-breaking way for users and tooling.

Although having to support multiple extrinsic versions in metadata involves extra work, the change is ultimately an improvement to metadata and the extra functionality may be useful in other future scenarios.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

There is no impact on testing, security or privacy.

-

Performance, Ergonomics, and Compatibility

+

Performance, Ergonomics, and Compatibility

This change makes the authorization through signatures configurable by runtime devs in version 5 extrinsics, as opposed to version 4 where the signing payload algorithm and signatures were hardcoded. This moves the responsibility of ensuring proper authentication through TransactionExtension to the runtime devs, but a sensible default which closely resembles the present day behavior will be provided in VerifySignature.

-

Performance

+

Performance

There is no performance impact.

-

Ergonomics

+

Ergonomics

Tooling will have to adapt to be able to tell which authorization scheme is used by a particular transaction by decoding the extension and checking which particular TransactionExtension in the pipeline is enabled to do the origin authorization. Previously, this was done by simply checking whether the transaction is signed or unsigned, as there was only one method of authentication.

-

Compatibility

+

Compatibility

As long as extrinsic version 4 is still exposed in the metadata when version 5 will be introduced, the changes will not break existing infrastructure. This should give enough time for tooling to support version 5 and to remove version 4 in the future.

-

Prior Art and References

+

Prior Art and References

This is a result of the work in Extrinsic Horizon and RFC99.

-

Unresolved Questions

+

Unresolved Questions

None.

- +

Following this change, extrinsic version 5 will be introduced as part of the Extrinsic Horizon effort, which will shape future work.

@@ -577,9 +507,9 @@ work.

AuthorsDaniel Shiposha -

Summary

+

Summary

This RFC proposes a metadata format for XCM-identifiable assets (i.e., for fungible/non-fungible collections and non-fungible tokens) and a set of instructions to communicate it across chains.

-

Motivation

+

Motivation

Currently, there is no way to communicate metadata of an asset (or an asset instance) via XCM.

The ability to query and modify the metadata is useful for two kinds of entities:

Besides metadata modification, the ability to read it is also valuable. On-chain logic can interpret the NFT metadata, i.e., the metadata could have not only the media meaning but also a utility function within a consensus system. Currently, such a way of using NFT metadata is possible only within one consensus system. This RFC proposes making it possible between different systems via XCM so different chains can fetch and analyze the asset metadata from other chains.

-

Stakeholders

+

Stakeholders

Runtime users, Runtime devs, Cross-chain dApps, Wallets.

-

Explanation

+

Explanation

The Asset Metadata is information bound to an asset class (fungible or NFT collection) or an asset instance (an NFT). The Asset Metadata could be represented differently on different chains (or in other consensus entities). However, to communicate metadata between consensus entities via XCM, we need a general format so that any consensus entity can make sense of such information.

@@ -734,25 +664,25 @@ The request can only be executed or rejected in its entirety. It must not be exe This RFC proposes to use the Undefined variant of a collection identified by an AssetId as a synonym of the collection itself. I.e., an asset Asset { id: <AssetId>, fun: NonFungible(AssetInstance::Undefined) } is considered an NFT representing the collection itself.

As a singleton non-fungible instance is barely distinguishable from its collection, this convention shouldn't cause any problems.

Thus, the AssetInstance docs must be updated accordingly in the implementations.

-

Drawbacks

+

Drawbacks

Regarding ergonomics, no drawbacks were noticed.

As for the user experience, it could discover new cross-chain use cases involving asset collections and NFTs, indicating a positive impact.

There are no security concerns except for the ReportMetadata instruction, which implies that the source of the information must be trusted.

In terms of performance and privacy, there will be no changes.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

The implementations must honor the contract for the new instructions. Namely, if the instance field has the value of AssetInstance::Undefined, the metadata must relate to the asset collection but not to a non-fungible token inside it.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

No significant impact.

-

Ergonomics

+

Ergonomics

Introducing a standard metadata format and a way of communicating it is a valuable addition to the XCM format that potentially increases cross-chain interoperability without the need to form ad-hoc chain-to-chain integrations via Transact.

-

Compatibility

+

Compatibility

This RFC proposes new functionality, so there are no compatibility issues.

-

Prior Art and References

+

Prior Art and References

RFC: XCM Asset Metadata

-

Unresolved Questions

+

Unresolved Questions

Should the MetadataMap and MetadataKeys be bounded, or is it enough to rely on the fact that every XCM message is itself bounded?

- +

The original RFC draft contained additional metadata instructions. Though they could be useful, they're clearly outside the basic logic. So, this RFC version omits them to make the metadata discussion more focused on the core things. Nonetheless, there is hope that metadata approval instructions might be useful in the future, so they are mentioned here.

You can read about the details in the original draft.

(source)

@@ -800,7 +730,7 @@ This RFC proposes to use the Undefined variant of a collection iden AuthorsBryan Chen, Jiyuan Zheng -

Summary

+

Summary

This proposal introduces XCQ (Cross Consensus Query), which aims to serve as an intermediary layer between different chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries. XCQ abstracts away concrete implementations across chains and supports custom query computations.

Use cases benefiting from XCQ include:

@@ -825,19 +755,19 @@ This RFC proposes to use the Undefined variant of a collection iden -

Motivation

+

Motivation

In Substrate, runtime APIs facilitate off-chain clients in reading the state of the consensus system. However, different chains may expose different APIs for a similar query or have varying data types, such as doing custom transformations on direct data, or differing AccountId types. This diversity also extends to client-side, which may require custom computations over runtime APIs in various use cases. Therefore, tools and UI developers often access storage directly and reimplement custom computations to convert data into user-friendly representations, leading to duplicated code between Rust runtime logic and UI JS/TS logic. This duplication increases workload and potential for bugs.

Therefore, a system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

The overall query pattern of XCQ consists of three components:

-

Drawbacks

+

Drawbacks

Performance issues

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

It's a new functionality, which doesn't modify the existing implementations.

-

Ergonomics

+

Ergonomics

The proposal facilitate the wallets and dApps developers. Developers no longer need to examine every concrete implementation to support conceptually similar operations across different chains. Additionally, they gain a more modular development experience through encapsulating custom computations over the exposed APIs in PolkaVM programs.

-

Compatibility

+

Compatibility

The proposal defines new apis, which doesn't break compatibility with existing interfaces.

-

Prior Art and References

+

Prior Art and References

There are several discussions related to the proposal, including:

-

Unresolved Questions

- +

Unresolved Questions

+

(source)

Table of Contents

The proof generation of $\Pi$ is not part of refine and do not involve the sequencer directly; instead this would be done by a neighboring community validator node. In addition, I/O of reading/writing state tries are believed to dominate ordinary ORU operation but are also part in the refine operation.

The gas required for accumulate is proportional to the number of blocks verified in refine , which result in read , write , and solicit and forget operations. It is believed that accumulate's gas cost is nominal and poses no significant issue. However, storage rent issues common to all blockchain storage applies to the preimages, which is explicitly tallied in service ${\bf a}$. Fortunately, this is upper-bounded by the number of blocks generated in a 28-day period.

-

Compatibility

+

Compatibility

CoreTime

Instead of ETH, rollups would require DOT for CoreTime to secure their rollup. However, rollups are not locked into JAM and may freely enter and exit the JAM ecosystem since work packages do not need to start at genesis.

Different rollups may need to scale their core usage based on rollup activity. JAM's connectivity to CoreTime is expected to handle this effectively.

Hashing

Currently, preimages are specified to use the Blake2b hash, while Ethereum rollup block hashes utilize Keccak256. This is an application level concern trivially solved by the preimage provider responding to preimage announcements by Blake2b hash instead of Keccak256.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

The described service requires expert review from security experts familiar with JAM, ELVES, and Ethereum.

The ELVES and JAM protocols are expected to undergo audit with the 1.0 ratification of JAM.

It is believed that the use of revm is safe due to its extensive coverage of Ethereum State + Block tests, but this may require careful review.

The polkatool compiler has not battletested by comparision.

The Consensus API generating state witnesses is likely mature but a relatively new addition to the geth code base.

The proposal introduces no new privacy concerns.

- +

It is natural to bring in finality from Ethereum using Attestations from the Beacon chain to finalize validated blocks as they become available from Ethereum and ETH ORU L2s enabled by this type of service. A "ETH Beacon Service" bringing in the Altair Light Client data would enable the Ethereum Service, all ETH ORUs to compute the canonical chain. This would use the "Ordered Accumulation" capabilities of JAM, reduce the storage footprint to just those blocks that are actually finalized in the L2 against an Ethereum finalized checkpoint.

As JAM implementers move towards conformant implementations in 2025, which support gas modeling and justify performance improvements, a proper model of storage costs and fees will be necessary.

JAM enables a semi-coherent model for non-Polkadot rollups, starting with optimistic rollups as described here. A similar service may be envisioned for mature ZK rollup ecosystems, though there is not as much more in refine than to verify the ZKRU proof. A JAM messaging service between ORUs and ZKRUs may be highly desirable. This can be done in a separate service or simply by adding in transfer code with read and write operations in service storage incoming and outgoing mailboxes.

@@ -1502,9 +1432,9 @@ All rollups, whether built on Substrate or optimistic turned cynical, are commit AuthorsGavin Wood -

Summary

+

Summary

This proposes a periodic, sale-based method for assigning Polkadot Coretime, the analogue of "block space" within the Polkadot Network. The method takes into account the need for long-term capital expenditure planning for teams building on Polkadot, yet also provides a means to allow Polkadot to capture long-term value in the resource which it sells. It supports the possibility of building rich and dynamic secondary markets to optimize resource allocation and largely avoids the need for parameterization.

-

Motivation

+

Motivation

Present System

The Polkadot Ubiquitous Computer, or just Polkadot UC, represents the public service provided by the Polkadot Network. It is a trust-free, WebAssembly-based, multicore, internet-native omnipresent virtual machine which is highly resilient to interference and corruption.

The present system of allocating the limited resources of the Polkadot Ubiquitous Computer is through a process known as parachain slot auctions. This is a parachain-centric paradigm whereby a single core is long-term allocated to a single parachain which itself implies a Substrate/Cumulus-based chain secured and connected via the Relay-chain. Slot auctions are on-chain candle auctions which proceed for several days and result in the core being assigned to the parachain for six months at a time up to 24 months in advance. Practically speaking, we only see two year periods being bid upon and leased.

@@ -1525,7 +1455,7 @@ All rollups, whether built on Substrate or optimistic turned cynical, are commit
  • The solution SHOULD avoid creating additional dependencies on functionality which the Relay-chain need not strictly provide for the delivery of the Polkadot UC.

    • Furthermore, the design SHOULD be implementable and deployable in a timely fashion; three months from the acceptance of this RFC should not be unreasonable.

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholder sets are:

    Socialization:

    The essensials of this proposal were presented at Polkadot Decoded 2023 Copenhagen on the Main Stage. A small amount of socialization at the Parachain Summit preceeded it and some substantial discussion followed it. Parity Ecosystem team is currently soliciting views from ecosystem teams who would be key stakeholders.

    -

    Explanation

    +

    Explanation

    Overview

    Upon implementation of this proposal, the parachain-centric slot auctions and associated crowdloans cease. Instead, Coretime on the Polkadot UC is sold by the Polkadot System in two separate formats: Bulk Coretime and Instantaneous Coretime.

    When a Polkadot Core is utilized, we say it is dedicated to a Task rather than a "parachain". The Task to which a Core is dedicated may change at every Relay-chain block and while one predominant type of Task is to secure a Cumulus-based blockchain (i.e. a parachain), other types of Tasks are envisioned.

    @@ -1966,16 +1896,16 @@ InstaPoolHistory: (empty)
  • Governance upgrade proposal(s).
  • Monitoring of the upgrade process.
    • -

    Performance, Ergonomics and Compatibility

    +

    Performance, Ergonomics and Compatibility

    No specific considerations.

    Parachains already deployed into the Polkadot UC must have a clear plan of action to migrate to an agile Coretime market.

    While this proposal does not introduce documentable features per se, adequate documentation must be provided to potential purchasers of Polkadot Coretime. This SHOULD include any alterations to the Polkadot-SDK software collection.

    -

    Testing, Security and Privacy

    +

    Testing, Security and Privacy

    Regular testing through unit tests, integration tests, manual testnet tests, zombie-net tests and fuzzing SHOULD be conducted.

    A regular security review SHOULD be conducted prior to deployment through a review by the Web3 Foundation economic research group.

    Any final implementation MUST pass a professional external security audit.

    The proposal introduces no new privacy concerns.

    - +

    RFC-3 proposes a means of implementing the high-level allocations within the Relay-chain.

    RFC-5 proposes the API for interacting with Relay-chain.

    Additional work should specify the interface for the instantaneous market revenue so that the Coretime-chain can ensure Bulk Coretime placed in the instantaneous market is properly compensated.

    @@ -1991,7 +1921,7 @@ InstaPoolHistory: (empty)
  • The percentage of cores to be sold as Bulk Coretime.
  • The fate of revenue collected.
    • -

    Prior Art and References

    +

    Prior Art and References

    Robert Habermeier initially wrote on the subject of Polkadot blockspace-centric in the article Polkadot Blockspace over Blockchains. While not going into details, the article served as an early reframing piece for moving beyond one-slot-per-chain models and building out secondary market infrastructure for resource allocation.

    (source)

    Table of Contents

    @@ -2024,10 +1954,10 @@ InstaPoolHistory: (empty) AuthorsGavin Wood, Robert Habermeier -

    Summary

    +

    Summary

    In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-3, it is necessary for the allocating parachain (envisioned to be one or more pallets on a specialised Brokerage System Chain) to communicate the core assignments to the Relay-chain, which is responsible for ensuring those assignments are properly enacted.

    This is a proposal for the interface which will exist around the Relay-chain in order to communicate this information and instructions.

    -

    Motivation

    +

    Motivation

    The background motivation for this interface is splitting out coretime allocation functions and secondary markets from the Relay-chain onto System parachains. A well-understood and general interface is necessary for ensuring the Relay-chain receives coretime allocation instructions from one or more System chains without introducing dependencies on the implementation details of either side.

    Requirements

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholder sets are:

    Socialization:

    This content of this RFC was discussed in the Polkdot Fellows channel.

    -

    Explanation

    +

    Explanation

    The interface has two sections: The messages which the Relay-chain is able to receive from the allocating parachain (the UMP message types), and messages which the Relay-chain is able to send to the allocating parachain (the DMP message types). These messages are expected to be able to be implemented in a well-known pallet and called with the XCM Transact instruction.

    Future work may include these messages being introduced into the XCM standard.

    UMP Message Types

    @@ -2122,17 +2052,17 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600);

    Realistic Limits of the Usage

    For request_revenue_info, a successful request should be possible if when is no less than the Relay-chain block number on arrival of the message less 100,000.

    For assign_core, a successful request should be possible if begin is no less than the Relay-chain block number on arrival of the message plus 10 and workload contains no more than 100 items.

    -

    Performance, Ergonomics and Compatibility

    +

    Performance, Ergonomics and Compatibility

    No specific considerations.

    -

    Testing, Security and Privacy

    +

    Testing, Security and Privacy

    Standard Polkadot testing and security auditing applies.

    The proposal introduces no new privacy concerns.

    - +

    RFC-1 proposes a means of determining allocation of Coretime using this interface.

    RFC-3 proposes a means of implementing the high-level allocations within the Relay-chain.

    Drawbacks, Alternatives and Unknowns

    None at present.

    -

    Prior Art and References

    +

    Prior Art and References

    None.

    (source)

    Table of Contents

    @@ -2178,13 +2108,13 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600); AuthorsJoe Petrowski -

    Summary

    +

    Summary

    As core functionality moves from the Relay Chain into system chains, so increases the reliance on the liveness of these chains for the use of the network. It is not economically scalable, nor necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a mechanism -- part technical and part social -- for ensuring reliable collator sets that are resilient to attemps to stop any subsytem of the Polkadot protocol.

    -

    Motivation

    +

    Motivation

    In order to guarantee access to Polkadot's system, the collators on its system chains must propose blocks (provide liveness) and allow all transactions to eventually be included. That is, some collators may censor transactions, but there must exist one collator in the set who will include a @@ -2220,12 +2150,12 @@ to censor any subset of transactions.

  • Collators selected by governance SHOULD have a reasonable expectation that the Treasury will reimburse their operating costs.
    • -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    This protocol builds on the existing Collator Selection pallet and its notion of Invulnerables. Invulnerables are collators (identified by their AccountIds) who @@ -2261,27 +2191,27 @@ approximately:

  • of which 15 are Invulnerable, and
  • five are elected by bond.
    • -

    Drawbacks

    +

    Drawbacks

    The primary drawback is a reliance on governance for continued treasury funding of infrastructure costs for Invulnerable collators.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    The vast majority of cases can be covered by unit testing. Integration test should ensure that the Collator Selection UpdateOrigin, which has permission to modify the Invulnerables and desired number of Candidates, can handle updates over XCM from the system's governance location.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    This proposal has very little impact on most users of Polkadot, and should improve the performance of system chains by reducing the number of missed blocks.

    -

    Performance

    +

    Performance

    As chains have strict PoV size limits, care must be taken in the PoV impact of the session manager. Appropriate benchmarking and tests should ensure that conservative limits are placed on the number of Invulnerables and Candidates.

    -

    Ergonomics

    +

    Ergonomics

    The primary group affected is Candidate collators, who, after implementation of this RFC, will need to compete in a bond-based election rather than a race to claim a Candidate spot.

    -

    Compatibility

    +

    Compatibility

    This RFC is compatible with the existing implementation and can be handled via upgrades and migration.

    -

    Prior Art and References

    +

    Prior Art and References

    Written Discussions

    -

    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)

    @@ -2337,10 +2267,10 @@ appropriate. These chains should be evaluated on a case-by-case basis.

    AuthorsPierre Krieger -

    Summary

    +

    Summary

    The full nodes of the Polkadot peer-to-peer network maintain a distributed hash table (DHT), which is currently used for full nodes discovery and validators discovery purposes.

    This RFC proposes to extend this DHT to be used to discover full nodes of the parachains of Polkadot.

    -

    Motivation

    +

    Motivation

    The maintenance of bootnodes has long been an annoyance for everyone.

    When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well.

    @@ -2349,9 +2279,9 @@ When it comes to RPC nodes, UX developers often have trouble finding up-to-date

    Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes.

    While this RFC doesn't solve these problems for relay chains, it aims at solving it for parachains by storing the list of all the full nodes of a parachain on the relay chain DHT.

    Assuming that this RFC is implemented, and that light clients are used, deploying a parachain wouldn't require more work than registering it onto the relay chain and starting the collators. There wouldn't be any need for special infrastructure nodes anymore.

    -

    Stakeholders

    +

    Stakeholders

    This RFC has been opened on my own initiative because I think that this is a good technical solution to a usability problem that many people are encountering and that they don't realize can be solved.

    -

    Explanation

    +

    Explanation

    The content of this RFC only applies for parachains and parachain nodes that are "Substrate-compatible". It is in no way mandatory for parachains to comply to this RFC.

    Note that "Substrate-compatible" is very loosely defined as "implements the same mechanisms and networking protocols as Substrate". The author of this RFC believes that "Substrate-compatible" should be very precisely specified, but there is controversy on this topic.

    While a lot of this RFC concerns the implementation of parachain nodes, it makes use of the resources of the Polkadot chain, and as such it is important to describe them in the Polkadot specification.

    @@ -2388,10 +2318,10 @@ message Response {

    The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that fork_id is typically very small and that the only variable-length field is addrs, this is easily achieved by limiting the number of addresses.

    Implementers should be aware that addrs might be very large, and are encouraged to limit the number of addrs to an implementation-defined value.

    -

    Drawbacks

    +

    Drawbacks

    The peer_id and addrs fields are in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame.

    The values of the genesis_hash and fork_id fields cannot be verified by the requester and are expected to be unused at the moment. Instead, a client that desires connecting to a parachain is expected to obtain the genesis hash and fork ID of the parachain from the parachain chain specification. These fields are included in the networking protocol nonetheless in case an acceptable solution is found in the future, and in order to allow use cases such as discovering parachains in a not-strictly-trusted way.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Because not all nodes want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all parachain nodes.

    This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable.

    @@ -2400,22 +2330,22 @@ Furthermore, when a large number of providers (here, a provider is a bootnode) a

    For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the key representing the target parachain. They are then in control of the parachain bootnodes. 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, Ergonomics, and Compatibility

    +

    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

    +

    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

    @@ -2436,13 +2366,13 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsJonas Gehrlein -

    Summary

    +

    Summary

    The Polkadot UC will generate revenue from the sale of available Coretime. The question then arises: how should we handle these revenues? Broadly, there are two reasonable paths – burning the revenue and thereby removing it from total issuance or divert it to the Treasury. This Request for Comment (RFC) presents arguments favoring burning as the preferred mechanism for handling revenues from Coretime sales.

    -

    Motivation

    +

    Motivation

    How to handle the revenue accrued from Coretime sales is an important economic question that influences the value of DOT and should be properly discussed before deciding for either of the options. Now is the best time to start this discussion.

    -

    Stakeholders

    +

    Stakeholders

    Polkadot DOT token holders.

    -

    Explanation

    +

    Explanation

    This RFC discusses potential benefits of burning the revenue accrued from Coretime sales instead of diverting them to Treasury. Here are the following arguments for it.

    It's in the interest of the Polkadot community to have a consistent and predictable Treasury income, because volatility in the inflow can be damaging, especially in situations when it is insufficient. As such, this RFC operates under the presumption of a steady and sustainable Treasury income flow, which is crucial for the Polkadot community's stability. The assurance of a predictable Treasury income, as outlined in a prior discussion here, or through other equally effective measures, serves as a baseline assumption for this argument.

    Consequently, we need not concern ourselves with this particular issue here. This naturally begs the question - why should we introduce additional volatility to the Treasury by aligning it with the variable Coretime sales? It's worth noting that Coretime revenues often exhibit an inverse relationship with periods when Treasury spending should ideally be ramped up. During periods of low Coretime utilization (indicated by lower revenue), Treasury should spend more on projects and endeavours to increase the demand for Coretime. This pattern underscores that Coretime sales, by their very nature, are an inconsistent and unpredictable source of funding for the Treasury. Given the importance of maintaining a steady and predictable inflow, it's unnecessary to rely on another volatile mechanism. Some might argue that we could have both: a steady inflow (from inflation) and some added bonus from Coretime sales, but burning the revenue would offer further benefits as described below.

    @@ -2485,13 +2415,13 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsJoe Petrowski -

    Summary

    +

    Summary

    Since the introduction of the Collectives parachain, many groups have expressed interest in forming new -- or migrating existing groups into -- on-chain collectives. While adding a new collective is relatively simple from a technical standpoint, the Fellowship will need to merge new pallets into the Collectives parachain for each new collective. This RFC proposes a means for the network to ratify a new collective, thus instructing the Fellowship to instate it in the runtime.

    -

    Motivation

    +

    Motivation

    Many groups have expressed interest in representing collectives on-chain. Some of these include:

    -

    Drawbacks

    +

    Drawbacks

    Other than all other system chains, development and maintenance of the Encointer Network is mainly financed by the KSM Treasury and possibly the DOT Treasury in the future. Encointer is dedicated to maintaining its network and runtime code for as long as possible, but there is a dependency on funding which is not in the hands of the fellowship. The only risk in the context of funding, however, is that the Encointer runtime will see less frequent updates if there's less funding.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    No changes to the existing system are proposed. Only changes to how maintenance is organized.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    No changes

    -

    Prior Art and References

    +

    Prior Art and References

    Existing Encointer runtime repo

    -

    Unresolved Questions

    +

    Unresolved Questions

    None identified

    - +

    More info on Encointer: encointer.org

    (source)

    Table of Contents

    @@ -3783,11 +3713,11 @@ other privacy-enhancing mechanisms to address this concern. AuthorsJoe Petrowski, Gavin Wood -

    Summary

    +

    Summary

    The Relay Chain contains most of the core logic for the Polkadot network. While this was necessary prior to the launch of parachains and development of XCM, most of this logic can exist in parachains. This is a proposal to migrate several subsystems into system parachains.

    -

    Motivation

    +

    Motivation

    Polkadot's scaling approach allows many distinct state machines (known generally as parachains) to operate with common guarantees about the validity and security of their state transitions. Polkadot provides these common guarantees by executing the state transitions on a strict subset (a backing @@ -3799,13 +3729,13 @@ blockspace) to the network.

    By minimising state transition logic on the Relay Chain by migrating it into "system chains" -- a set of parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot Ubiquitous Computer can maximise its primary offering: secure blockspace.

    -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    The following pallets and subsystems are good candidates to migrate from the Relay Chain:

     -

    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

    • Comprehensive unit tests need to be provided to ensure the correctness of the new functionalities.
      • @@ -9434,31 +9364,31 @@ Implement call filters. This will allow multisig accounts to only accept certain
      • The proposal does not introduce new privacy concerns as it only affects region trading functionality within the existing framework.
      -

      Performance, Ergonomics, and Compatibility

      -

      Performance

      +

      Performance, Ergonomics, and Compatibility

      +

      Performance

      • This feature is expected to introduce minimal overhead since it primarily involves read and write operations to storage maps.
      • Efforts will be made to optimize the code to prevent unnecessary computational costs.
      -

      Ergonomics

      +

      Ergonomics

      • The new functions are designed to be intuitive and easy to use, providing clear feedback through events and errors.
      • Documentation and examples will be provided to assist developers and users.
      -

      Compatibility

      +

      Compatibility

      • This proposal does not break compatibility with existing interfaces or previous versions.
      • No migrations are necessary as it introduces new functionality without altering existing features.
      -

      Prior Art and References

      +

      Prior Art and References

      • All related discussions are going to be under this PR.
      -

      Unresolved Questions

      +

      Unresolved Questions

      • Are there additional security measures needed to prevent potential abuses of the new functionalities?
      - +
      • Integration with external NFT marketplaces for more robust trading options.
      • Development of user interfaces to interact with the new marketplace features seamlessly.
        • @@ -9501,12 +9431,12 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsAurora Poppyseed, Phil Lucksok -

        Summary

        +

        Summary

        This RFC proposes the integration of smart contracts on the Coretime chain to enhance flexibility and enable complex decentralized applications, including secondary market functionalities.

        -

        Motivation

        +

        Motivation

        Currently, the Coretime chain lacks the capability to support smart contracts, which limits the range of decentralized applications that can be developed and deployed. By enabling smart contracts, the Coretime chain can facilitate more sophisticated functionalities such as automated region trading, dynamic pricing mechanisms, and other decentralized applications that require programmable logic. This will enhance the utility of the Coretime chain, attract more developers, and create more opportunities for innovation.

        Additionally, while there is a proposal (#885) to allow EVM-compatible contracts on Polkadot’s Asset Hub, the implementation of smart contracts directly on the Coretime chain will provide synchronous interactions and avoid the complexities of asynchronous operations via XCM.

        -

        Stakeholders

        +

        Stakeholders

        Primary stakeholders include:

        • Developers working on the Coretime chain.
          • @@ -9514,7 +9444,7 @@ Implement call filters. This will allow multisig accounts to only accept certain
        • Community members interested in expanding the capabilities of the Coretime chain.
        • Secondary Coretime marketplaces.
        -

        Explanation

        +

        Explanation

        This RFC introduces the following key components:

        1. @@ -9546,14 +9476,14 @@ Implement call filters. This will allow multisig accounts to only accept certain
      -

      Drawbacks

      +

      Drawbacks

      There are several drawbacks to consider:

      • Complexity: Adding smart contracts introduces significant complexity to the Coretime chain, which may increase maintenance overhead and the potential for bugs.
      • Performance: The execution of smart contracts can be resource-intensive, potentially affecting the performance of the Coretime chain.
      • Security: Smart contracts are prone to vulnerabilities and exploits, necessitating rigorous security measures and continuous monitoring.
      -

      Testing, Security, and Privacy

      +

      Testing, Security, and Privacy

      Testing

      • Comprehensive unit tests and integration tests should be developed to ensure the correct functionality of smart contracts.
        • @@ -9569,36 +9499,36 @@ Implement call filters. This will allow multisig accounts to only accept certain
        • The proposal does not introduce new privacy concerns as it extends existing functionalities with programmable logic.
        -

        Performance, Ergonomics, and Compatibility

        -

        Performance

        +

        Performance, Ergonomics, and Compatibility

        +

        Performance

        • The introduction of smart contracts may impact performance due to the additional computational overhead.
        • Optimization techniques, such as efficient gas fee mechanisms and resource management, should be employed to minimize performance degradation.
        -

        Ergonomics

        +

        Ergonomics

        • The new functionality should be designed to be intuitive and easy to use for developers, with comprehensive documentation and examples.
        • Provide developer tools and SDKs to facilitate the creation and deployment of smart contracts.
        -

        Compatibility

        +

        Compatibility

        • This proposal should maintain compatibility with existing interfaces and functionalities of the Coretime chain.
        • Ensure backward compatibility and provide migration paths if necessary.
        -

        Prior Art and References

        +

        Prior Art and References

        • Ethereum’s implementation of smart contracts using Solidity.
        • Polkadot’s Ink! smart contract platform.
        • Existing decentralized applications and use cases on other blockchain platforms.
        • Proposal #885: EVM-compatible contracts on Asset Hub, which highlights the community's interest in integrating smart contracts within the Polkadot ecosystem.
        -

        Unresolved Questions

        +

        Unresolved Questions

        • What specific security measures should be implemented to prevent smart contract vulnerabilities?
        • How can we ensure optimal performance while supporting complex smart contracts?
        • What are the best practices for integrating smart contracts with existing pallets on the Coretime chain?
        - +
        • Further enhancements could include advanced developer tools and SDKs for smart contract development.
        • Integration with external decentralized applications and platforms to expand the ecosystem.
          • @@ -9652,12 +9582,12 @@ Implement call filters. This will allow multisig accounts to only accept certain Authorseskimor -

          Summary

          +

          Summary

          Change the upgrade process of a parachain runtime upgrade to become an off-chain process with regards to the relay chain. Upgrades are still contained in parachain blocks, but will no longer need to end up in relay chain blocks nor in relay chain state.

          -

          Motivation

          +

          Motivation

          Having parachain runtime upgrades go through the relay chain has always been seen as a scalability concern. Due to optimizations in statement distribution and asynchronous backing it became less crucial and got @@ -9672,13 +9602,13 @@ this we would hope for far more parachains to get registered, thousands potentially even ten thousands. With so many PVFs registered, updates are expected to become more frequent and even attacks on service quality for other parachains would become a higher risk.

          -

          Stakeholders

          +

          Stakeholders

          • Parachain Teams
          • Relay Chain Node implementation teams
          • Relay Chain runtime developers
          -

          Explanation

          +

          Explanation

          The issues with on-chain runtime upgrades are:

          1. Needlessly costly.
            2. @@ -9808,11 +9738,11 @@ fetching. parachain and only prune the previous one, once the first candidate using the new code got finalized. This ensures that disputes will always be able to resolve.

            -

            Drawbacks

            +

            Drawbacks

            The major drawback of this solution is the same as any solution the moves work off-chain, it adds complexity to the node. E.g. nodes needing the PVF, need to store them separately, together with their own pruning strategy as well.

            -

            Testing, Security, and Privacy

            +

            Testing, Security, and Privacy

            Implementations adhering to this RFC, will respond to PVF requests with the actual PVF, if they have it. Requesters will persist received PVFs on disk for as long as they are replaced by a new one. Implementations must not be lazy @@ -9826,8 +9756,8 @@ only chunk, but also PVF available), it is important to have enough validators upgraded, before we allow collators to make use of the new runtime upgrade mechanism. Otherwise we would risk disputes to not being able to succeed.

            This RFC has no impact on privacy.

            -

            Performance, Ergonomics, and Compatibility

            -

            Performance

            +

            Performance, Ergonomics, and Compatibility

            +

            Performance

            This proposal lightens the load on the relay chain and is thus in general beneficial for the performance of the network, this is achieved by the following:

            @@ -9842,7 +9772,7 @@ upgrade per relay chain block, occupying almost all of the blockspace. push back on an upgrade for whatever reason, no network bandwidth and core time gets wasted because of this.
          -

          Ergonomics

          +

          Ergonomics

          End users are only affected by better performance and more stable block times. Parachains will need to implement the introduced request/response protocol and adapt to the new signalling mechanism via an UMP message, instead of sending @@ -9853,7 +9783,7 @@ upgrade gets passed to pre-checking. This is especially important for on-demand chains or bulk users not occupying a full core. Further more that behaviour of requiring multiple blocks to fully initiate a runtime upgrade needs to be well documented.

          -

          Compatibility

          +

          Compatibility

          We will continue to support the old mechanism for code upgrades for a while, but will start to impose stricter limits over time, with the number of registered parachains going up. With those limits in place parachains not migrating to the @@ -9874,7 +9804,7 @@ validators. "hot" PVF).

        • Altered behaviour in availability-distribution: Fetch missing PVFS.
          • -

          Prior Art and References

          +

          Prior Art and References

          Off-chain runtime upgrades have been discussed before, the architecture described here is simpler though as it piggybacks on already existing features, namely:

          @@ -9883,7 +9813,7 @@ namely:

        • Existing pre-checking.

          • https://github.com/paritytech/polkadot-sdk/issues/971

          -

          Unresolved Questions

          +

          Unresolved Questions

          1. What about the initial runtime, shall we make that off-chain as well?
          2. Good news, at least after the first upgrade, no code will be stored on chain @@ -9900,7 +9830,7 @@ the upgrade? Easy: Make available and vote nay in pre-checking.

          TODO: Fully resolve these questions and incorporate in RFC text.

          - +

          Further Hardening

          By no longer having code upgrade go through the relay chain, occupying a full relay chain block, the impact on other parachains is already greatly reduced, if we @@ -9976,53 +9906,123 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).

          AuthorsFrancisco Aguirre -

          Summary

          +

          Summary

          The SetFeesMode instruction and the fees_mode register allow for the existence of JIT withdrawal. JIT withdrawal complicates the fee mechanism and leads to bugs and unexpected behaviour. The proposal is to remove said functionality. Another effort to simplify fee handling in XCM.

          -

          Motivation

          +

          Motivation

          The JIT withdrawal mechanism creates bugs such as not being able to get fees when all assets are put into holding and none left in the origin location. This is a confusing behavior, since there are funds for fees, just not where the XCVM wants them. The XCVM should have only one entrypoint to fee payment, the holding register. That way there is also less surface for bugs.

          -

          Stakeholders

          +

          Stakeholders

          • Runtime Users
          • Runtime Devs
          • Wallets
          • dApps
          -

          Explanation

          +

          Explanation

          The SetFeesMode instruction will be removed. The Fees Mode register will be removed.

          -

          Drawbacks

          +

          Drawbacks

          Users will have to make sure to put enough assets in WithdrawAsset when previously some things might have been charged directly from their accounts. This leads to a more predictable behaviour though so it will only be a drawback for the minority of users.

          -

          Testing, Security, and Privacy

          +

          Testing, Security, and Privacy

          Implementations and benchmarking must change for most existing pallet calls that send XCMs to other locations.

          -

          Performance, Ergonomics, and Compatibility

          -

          Performance

          +

          Performance, Ergonomics, and Compatibility

          +

          Performance

          Performance will be improved since unnecessary checks will be avoided.

          -

          Ergonomics

          +

          Ergonomics

          JIT withdrawal was a way of side-stepping the regular flow of XCM programs. By removing it, the spec is simplified but now old use-cases have to work with the original intended behaviour, which may result in more implementation work.

          Ergonomics for users will undoubtedly improve since the system is more predictable.

          -

          Compatibility

          +

          Compatibility

          Existing programs in the ecosystem will break. The instruction should be deprecated as soon as this RFC is approved (but still fully supported), then removed in a subsequent XCM version (probably deprecate in v5, remove in v6).

          -

          Prior Art and References

          +

          Prior Art and References

          The previous RFC PR on the xcm-format repo, before XCM RFCs were moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/57.

          +

          Unresolved Questions

          +

          None.

          + +

          The new generic fees mechanism is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway.

          +

          (source)

          +

          Table of Contents

          + +

          RFC-0112: Compress the State Response Message in State Sync

          +
          + + + +
          Start Date14 August 2024
          DescriptionCompress the state response message to reduce the data transfer during the state syncing
          AuthorsLiu-Cheng Xu
          +
          +

          Summary

          +

          This RFC proposes compressing the state response message during the state syncing process to reduce the amount of data transferred.

          +

          Motivation

          +

          State syncing can require downloading several gigabytes of data, particularly for blockchains with large state sizes, such as Astar, which +has a state size exceeding 5 GiB (https://github.com/AstarNetwork/Astar/issues/1110). This presents a significant +challenge for nodes with slower network connections. Additionally, the current state sync implementation lacks a persistence feature (https://github.com/paritytech/polkadot-sdk/issues/4), +meaning any network disruption forces the node to re-download the entire state, making the process even more difficult.

          +

          Stakeholders

          +

          This RFC benefits all projects utilizing the Substrate framework, specifically in improving the efficiency of state syncing.

          +
            +
          • Node Operators.
            • +
          • Substrate Users.
            • +
          +

          Explanation

          +

          The largest portion of the state response message consists of either CompactProof or Vec<KeyValueStateEntry>, depending on whether a proof is requested (source):

          +
            +
          • CompactProof: When proof is requested, compression yields a lower ratio but remains beneficial, as shown in warp sync tests in the Performance section below.
            • +
          • Vec<KeyValueStateEntry>: Without proof, this is theoretically compressible because the entries are generated by iterating the +storage sequentially starting from an empty storage key, which means many entries in the message share the same storage prefix, making it ideal +for compression.
            • +
          +

          Drawbacks

          +

          None identified.

          +

          Testing, Security, and Privacy

          +

          The code changes required for this RFC are straightforward: compress the state response on the sender side and decompress it on the receiver side. Existing sync tests should ensure functionality remains intact.

          +

          Performance, Ergonomics, and Compatibility

          +

          Performance

          +

          This RFC optimizes network bandwidth usage during state syncing, particularly for blockchains with gigabyte-sized states, while introducing negligible CPU overhead for compression and decompression. For example, compressing the state response during a recent Polkadot warp sync (around height #22076653) reduces the data transferred from 530,310,121 bytes to 352,583,455 bytes — a 33% reduction, saving approximately 169 MiB of data.

          +

          Performance data is based on this patch, with logs available here.

          +

          Ergonomics

          +

          None.

          +

          Compatibility

          +

          No compatibility issues identified.

          +

          Prior Art and References

          +

          None.

          Unresolved Questions

          None.

          -

          The new generic fees mechanism is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway.

          +

          None.

          (source)

          Table of Contents

            diff --git a/proposed/0111-pure-proxy-replication.html b/proposed/0111-pure-proxy-replication.html index 50d6b44..aa6094c 100644 --- a/proposed/0111-pure-proxy-replication.html +++ b/proposed/0111-pure-proxy-replication.html @@ -90,7 +90,7 @@ @@ -310,7 +310,7 @@ mod pallet_proxy_replica { - @@ -324,7 +324,7 @@ mod pallet_proxy_replica { - diff --git a/proposed/0124-extrinsic-version-5.html b/proposed/0124-extrinsic-version-5.html index 222c884..c2d27e1 100644 --- a/proposed/0124-extrinsic-version-5.html +++ b/proposed/0124-extrinsic-version-5.html @@ -90,7 +90,7 @@ @@ -343,7 +343,7 @@ work.