diff --git a/print.html b/print.html index 1efb9d1..53a7c85 100644 --- a/print.html +++ b/print.html @@ -523,120 +523,157 @@ account_id

(source)

Table of Contents

-

Further Discussion Points

-

Prior Art and References

This RFC builds extensively on the available ideas put forward in RFC-1.

-

Additionally, I want to express a special thanks to Samuel Haefner and Shahar Dobzinski for fruitful discussions and helping me structure my thoughts.

-

Unresolved Questions

- +

Additionally, I want to express a special thanks to Samuel Haefner, Shahar Dobzinski, and Alistair Stewart for fruitful discussions and helping me structure my thoughts.

(source)

Table of Contents

-

Unresolved Questions

+

Unresolved Questions

-

Unresolved Questions

+

Unresolved Questions

The changes in this RFC would need to be benchmarked. That involves implementing the RFC and measuring the speed difference.

It is expected that most host functions are faster or equal in speed to their deprecated counterparts, with the following exceptions:

-

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 @@ -2126,7 +2155,7 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that

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.

@@ -2250,7 +2279,7 @@ Also note that child tries aren't considered as descendants of the main trie whe

The prior networking protocol is maintained for now. The older version of this protocol could get removed in a long time.

Prior Art and References

None. This RFC is a clean-up of an existing mechanism.

-

Unresolved Questions

+

Unresolved Questions

None

The current networking protocol could be deprecated in a long time. Additionally, the current "state requests" protocol (used for warp syncing) could also be deprecated in favor of this one.

@@ -2398,7 +2427,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

@@ -2496,7 +2525,7 @@ 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.
    @@ -2633,7 +2662,7 @@ This can be unified and simplified by moving both parts into the runtime.

  • Allow parachain to renew lease without actually run another parachain: https://github.com/paritytech/polkadot/issues/6685
  • Always treat parachain that never produced block for a significant amount of time as unlocked: https://github.com/paritytech/polkadot/issues/7539
  • -

    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.

    @@ -2698,7 +2727,7 @@ 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

    @@ -3813,7 +3842,7 @@ 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.

    @@ -3917,7 +3946,7 @@ so that chains know which system_version to use.

    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.

    @@ -4184,7 +4213,7 @@ efficient data management and periodic reviews of storage requirements, will be Kusama and Polkadot Asset Hubs, making Polkadot and Kusama more accessible and user-friendly.

    Compatibility

    The change does not impact compatibility as a redeposit function is already implemented.

    -

    Unresolved Questions

    +

    Unresolved Questions

    If this RFC is accepted, there should not be any unresolved questions regarding how to adapt the implementation of deposits for NFT collections.

    Addendum

    @@ -4469,7 +4498,7 @@ governance call.

    Prior Art and References

    See comments on the tracking issue and the in-progress PR

    -

    Unresolved Questions

    +

    Unresolved Questions

    Not applicable.

    This enables future optimisations for the performance of availability recovery, such as retrieving batched systematic @@ -4624,7 +4653,7 @@ and for returning the ownership proof alongside the public session keys.

    UIs would need to be updated to support the new RPC and the changed on chain logic.

    Prior Art and References

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    Substrate implementation of the RFC.

    @@ -4762,7 +4791,7 @@ Manifesto
  • Indeed: Average Salary for Engineers, United States
  • -

    Unresolved Questions

    +

    Unresolved Questions

    None at present.

    (source)

    Table of Contents

    @@ -4848,7 +4877,7 @@ This is equivalent to forcing the Vec<Transaction> to always

    The change is backwards compatible if done in two steps: modify the sender to always send one transaction per notification, then, after a while, modify the receiver to enforce the new format.

    Prior Art and References

    Irrelevant.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    None. This is a simple isolated change.

    @@ -4960,7 +4989,7 @@ Furthermore, when a large number of providers are registered, only the providers

    Irrelevant.

    Prior Art and References

    Unknown.

    -

    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?

    This RFC would make it possible to reliably discover archive nodes, which would make it possible to reliably send archive node requests, something that isn't currently possible. This could solve the problem of finding archive RPC node providers by migrating archive-related request to using the native peer-to-peer protocol rather than JSON-RPC.

    @@ -5335,7 +5364,7 @@ nodes: [[[2, 3], [4, 5]], [0, 1]]

    Prior Art and References

    RFC 46 produced by the Alzymologist team is a previous work reference that goes in this direction as well.

    On other ecosystems, there are other solutions to the problem of trusted signing. Cosmos for example has a standardized way of transforming a transaction into some textual representation and this textual representation is included in the signed data. Basically achieving the same as what the RFC proposes, but it requires that for every transaction applied in a block, every node in the network always has to generate this textual representation to ensure the transaction signature is valid.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    (source)

    @@ -6839,7 +6868,7 @@ There is still the possibility of having state that is not migrated even when fo For Polkadot/Kusama this means that also the parachain nodes need to be running with a relay chain node version that supports this new feature. Otherwise the parachains will stop producing/finalizing nodes as they can not sync the relay chain any more.

    Prior Art and References

    The issue initially reported a bug that led to this RFC. It also discusses multiple solutions for the problem.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    -

    Unresolved Questions

    +

    Unresolved Questions

    @@ -7527,7 +7556,7 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View

    Stakeholders

    Node developers are the main stakeholders for this proposal. It also creates a foundation on which parachain runtime developers will build.

    Explanation

    -

    Overview

    +

    Overview

    The current approach to compressing binary blobs involves using zstd compression, and the resulting compressed blob is prefixed with a unique 64-bit magic value specified in that subsection. The same procedure is used to compress both Wasm code blobs and proofs-of-validity. Currently, having solely a compressed blob, it's impossible to tell what's inside it without decompression, a Wasm blob, or a PoV. That doesn't cause problems in the current protocol, as Wasm blobs and PoV blobs take completely different execution paths in the code.

    The changes proposed below are intended to define the means for distinguishing compressed blob types in a backward-compatible and future-proof way.

    It is proposed to introduce an open list of 64-bit prefixes, each representing a compressed blob of a specific type compressed with a specific compression method. The currently used prefix becomes deprecated and will be removed or reused when it is no longer in use.

    @@ -7564,7 +7593,7 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View

    The change is designed to be backward-compatible.

    Prior Art and References

    SDK PR#6704 (WIP) introduces a mechanism similar to that described in this proposal and proves the necessity of such a change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    This proposal creates a foundation for two future work directions:

    @@ -7679,7 +7708,7 @@ faster deployment for most parachains but would add complexity.

    This requires a breaking change that can be coordinated following the same approach as in RFC-47.

    Prior Art and References

    JAM already utilizes the same optimizations described in the Graypaper.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    Future improvements could include:

    @@ -7920,7 +7949,7 @@ At this point, we compute $\beta\prime_w = \sum_v \beta\prime_{w,v}$ on-chain fo

    JAM's block exports should not complicate availability rewards, but could impact some alternative schemes.

    Prior Art and References

    None

    -

    Unresolved Questions

    +

    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.

    Synthetic parachain flag

    @@ -8170,7 +8199,7 @@ The following other host functions are similarly also considered deprecated:

    This RFC might be difficult to implement in Substrate due to the internal code design. It is not clear to the author of this RFC how difficult it would be.

    Prior Art

    The API of these new functions was heavily inspired by API used by the C programming language.

    -

    Unresolved Questions

    +

    Unresolved Questions

    The changes in this RFC would need to be benchmarked. This involves implementing the RFC and measuring the speed difference.

    It is expected that most host functions are faster or equal speed to their deprecated counterparts, with the following exceptions:

    Explanation

    -

    Overview

    +

    Overview

    The dynamic pricing model sets the new price based on supply and demand in the previous period. The model is a function of the number of Regions sold, piecewise-defined by two power functions.

    -

    Unresolved Questions

    +

    Unresolved Questions

    Implementation details and overall code is still up to discussion.

    (source)

    Table of Contents

    @@ -8555,7 +8584,7 @@ OLD_PRICE = 1000

    We want to highlight the importance for ecosystem builders to create a mechanism for indexers and wallets to be able to understand that changes have occurred such as increasing the pallet version, etc.

    Prior Art and References

    N/A

    -

    Unresolved Questions

    +

    Unresolved Questions

    N/A

    Additionally we would like to re-open the conversation about the potential for there to be free delegations. This was discussed by Dr Gavin Wood at Sub0 2022 and we feel like this would go a great way towards increasing the amount of network participants that are delegating: https://youtu.be/hSoSA6laK3Q?t=526

    @@ -8744,7 +8773,7 @@ pub(super) type CheckedCodeHash<T: Config> =

    This RFC does not break compatibility.

    Prior Art and References

    Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796

    -

    Unresolved Questions

    +

    Unresolved Questions

    None at this time.

    As noted in this GitHub issue, we want to raise the per-byte cost of on-chain data storage. However, a substantial increase in this cost would make it highly impractical for on-demand parachains to register on Polkadot. @@ -8833,7 +8862,7 @@ The :heappages are a rather obscure feature, and it is not clear wh

    Not a breaking change. The runtime-side changes can be applied immediately (without even having to wait for changes in the client), then as soon as the runtime is updated, the client can be updated without any transition period. One can even consider updating the client before the runtime, as it corresponds to path C.

    Prior Art and References

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    This RFC follows the same path as https://github.com/polkadot-fellows/RFCs/pull/4 by scoping everything related to memory allocations to the runtime.

    @@ -8981,7 +9010,7 @@ much of a burden or overhead since they've already built the infrastructure for

    One reference to a similar feature requiring on-chain/off-chain coordination would be the Kappa-Sigma-Mu Society. Nothing on-chain necessarily enforces the rules or facilitates bids, challenges, defenses, etc. However, the Society has managed to maintain itself with integrity to its rules. So I don't think this is totally out of Kusama's scope. But it will require some off-chain effort to maintain.

    -

    Unresolved Questions

    +

    Unresolved Questions

    -

    Unresolved Questions

    +

    Unresolved Questions

    Feedback on whether my proposed implementation of this is the best way to address the issue - including which calls the track should be allowed to make. Are the track parameters correct or should be use something different? Alternative would be welcome.

    (source)

    Table of Contents

    @@ -9654,7 +9683,7 @@ We have the following extrinsics:

    This RFC is compatible with the existing implementation and can be handled via upgrades and migration. It's not intended to replace the existing multisig pallet.

    Prior Art and References

    multisig pallet in polkadot-sdk

    -

    Unresolved Questions

    +

    Unresolved Questions

    @@ -9754,7 +9783,7 @@ Implement call filters. This will allow multisig accounts to only accept certain

    Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

    Prior Art and References

    No prior articles or references.

    -

    Unresolved Questions

    +

    Unresolved Questions

    No further questions at this stage.

    Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".

    @@ -9862,7 +9891,7 @@ Implement call filters. This will allow multisig accounts to only accept certain

    Prior Art and References

    Prior Art

    No prior articles.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    None

    @@ -9997,7 +10026,7 @@ Implement call filters. This will allow multisig accounts to only accept certain -

    Unresolved Questions

    +

    Unresolved Questions

    @@ -10135,7 +10164,7 @@ Implement call filters. This will allow multisig accounts to only accept certain
  • 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