This book contains the Polkadot Fellowship Requests for Comments (RFCs) detailing proposed changes to the technical implementation of the Polkadot network.
polkadot-fellows/RFCs
(source)
Table of Contents
SessionKeys
This RFC proposes to changes the SessionKeys::generate_session_keys runtime api interface. This runtime api is used by validator operators to +generate new session keys on a node. The public session keys are then registered manually on chain by the validator operator. +Before this RFC it was not possible by the on chain logic to ensure that the account setting the public session keys is also in +possession of the private session keys. To solve this the RFC proposes to pass the account id of the account doing the +registration on chain to generate_session_keys. Further this RFC proposes to change the return value of the generate_session_keys +function also to not only return the public session keys, but also the proof of ownership for the private session keys. The +validator operator will then need to send the public session keys and the proof together when registering new session keys on chain.
SessionKeys::generate_session_keys
generate_session_keys
When submitting the new public session keys to the on chain logic there doesn't exist any verification of possession of the private session keys. +This means that users can basically register any kind of public session keys on chain. While the on chain logic ensures that there are +no duplicate keys, someone could try to prevent others from registering new session keys by setting them first. While this wouldn't bring +the "attacker" any kind of advantage, more like disadvantages (potential slashes on their account), it could prevent someone from +e.g. changing its session key in the event of a private session key leak.
After this RFC this kind of attack would not be possible anymore, because the on chain logic can verify that the sending account +is in ownership of the private session keys.
We are first going to explain the proof format being used:
proof
#![allow(unused)] +fn main() { +type Proof = (Signature, Signature, ..); +}
The proof being a SCALE encoded tuple over all signatures of each private session +key signing the account_id. The actual type of each signature depends on the +corresponding session key cryptographic algorithm. The order of the signatures in +the proof is the same as the order of the session keys in the SessionKeys type +declared in the runtime.
account_id
The version of the SessionKeys needs to be bumped to 1 to reflect the changes to the +signature of SessionKeys_generate_session_keys:
1
SessionKeys_generate_session_keys
#![allow(unused)] +fn main() { +pub struct OpaqueGeneratedSessionKeys { + pub keys: Vec<u8>, + pub proof: Vec<u8>, +} + +fn SessionKeys_generate_session_keys(account_id: Vec<u8>, seed: Option<Vec<u8>>) -> OpaqueGeneratedSessionKeys; +}
The default calling convention for runtime apis is applied, meaning the parameters +passed as SCALE encoded array and the length of the encoded array. The return value +being the SCALE encoded return value as u64 (array_ptr | length << 32). So, the +actual exported function signature looks like:
u64
array_ptr | length << 32
#![allow(unused)] +fn main() { +fn SessionKeys_generate_session_keys(array: *const u8, len: usize) -> u64; +}
The on chain logic for setting the SessionKeys needs to be changed as well. It +already gets the proof passed as Vec<u8>. This proof needs to be decoded to +the actual Proof type as explained above. The proof and the SCALE encoded +account_id of the sender are used to verify the ownership of the SessionKeys.
Vec<u8>
Proof
Validator operators need to pass the their account id when rotating their session keys in a node. +This will require updating some high level docs and making users familiar with the slightly changed ergonomics.
Testing of the new changes only requires passing an appropriate owner for the current testing context. +The changes to the proof generation and verification got audited to ensure they are correct.
owner
The session key generation is an offchain process and thus, doesn't influence the performance of the +chain. Verifying the proof is done on chain as part of the transaction logic for setting the session keys. +The verification of the proof is a signature verification number of individual session keys times. As setting +the session keys is happening quite rarely, it should not influence the overall system performance.
The interfaces have been optimized to make it as easy as possible to generate the ownership proof.
Introduces a new version of the SessionKeys runtime api. Thus, nodes should be updated before +a runtime is enacted that contains these changes otherwise they will fail to generate session keys. +The RPC that exists around this runtime api needs to be updated to support passing the account id +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.
None.
Substrate implementation of the RFC.
A pallet to facilitate enhanced multisig accounts. The main enhancement is that we store a multisig account in the state with related info (signers, threshold,..etc). The module affords enhanced control over administrative operations such as adding/removing signers, changing the threshold, account deletion, canceling an existing proposal. Each signer can approve/reject a proposal while still exists. The proposal is not intended for migrating or getting rid of existing multisig. It's to allow both options to coexist.
For the rest of the RFC We use the following terms:
Stateful Multisig
Stateless Multisig
Entities in the Polkadot ecosystem need to have a way to manage their funds and other operations in a secure and efficient way. Multisig accounts are a common way to achieve this. Entities by definition change over time, members of the entity may change, threshold requirements may change, and the multisig account may need to be deleted. For even more enhanced hierarchical control, the multisig account may need to be controlled by other multisig accounts.
Current native solutions for multisig operations are less optimal, performance-wise (as we'll explain later in the RFC), and lack fine-grained control over the multisig account.
and much more...
I've created the stateful multisig pallet during my studies in Polkadot Blockchain Academy under supervision from @shawntabrizi and @ank4n. After that, I've enhanced it to be fully functional and this is a draft PR#3300 in polkadot-sdk. I'll list all the details and design decisions in the following sections. Note that the PR is not 1-1 exactly to the current RFC as the RFC is a more polished version of the PR after updating based on the feedback and discussions.
Let's start with a sequence diagram to illustrate the main operations of the Stateful Multisig.
Standard audit/review requirements apply.
Doing back of the envelop calculation to proof that the stateful multisig is more efficient than the stateless multisig given it's smaller footprint size on blocks.
Quick review over the extrinsics for both as it affects the block size:
Stateless Multisig: @@ -762,17 +875,17 @@ We have the following extrinsics:
So even though the stateful multisig has a larger state size, it's still more efficient in terms of block size and total footprint on the blockchain.
The Stateful Multisig will have better ergonomics for managing multisig accounts for both developers and end-users.
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.
multisig pallet in polkadot-sdk
This proposes to increase the maximum length of identity raw data values from a 32 bytes/chars limit to either a 64 bytes/chars limit or a 128 bytes/chars limit.
At the moment if you upload a file and pin it to IPFS storage you get an IPFS Content Identifier (CID), which is the unique ID of the file in the IPFS Network. That CID may be used to retrieve the file again via a standard IPFS interface and gateway from anywhere.
CIDs are reasonably short regardless of the size the underlying content and are based on the cryptographic hash of the content.
IPFS providers may default to using and recommending using CIDv1 [0] when using SHA256 generates a CID 46 bytes long, rather than CIDv0 [0] that generates a CID 59 bytes long, however CIDv0 may be be the preferred choice for minting and storing NFTs on-chain since it is cheaper.
Further, the URI protocol + CID for CIDv0 (ipfs://Qm...) will be 7+46=53 chars while for CIDv1 (ipfs://baf...) it will be 7+59=66 chars [1], so neither CIDv0 nor CIDv1 have a CID that supports a maximum length of 32 bytes, which exceeds the maximum 32 bytes/chars limit for bytes/string fields of their Polkadot on-chain identity.
If you want to set a Polkadot on-chain identity, users may provide raw data values of their email address "email" field, which may be longer than 32 bytes/chars (e.g. abcdefghijklmnopqrstuvwxyz@me.com or longer), and either just a CID or the URI protocol + CID associated with a legal document, as the value of the "legal" field, and the URI protocol + CID associated with the profile image to associated with their on-chain identity, as the value of the "image" field, however each field can only store a maximum length of 32 bytes/chars of information [3]. They may also want to set a custom value in the "additional" field, which currently only stores a maximum length of 32 bytes, since it currently has a FieldLimit.
FieldLimit
Possible disadvantages of the current 32 bytes/chars limitation:
identity
setIdentity(info)
The maximum length of identity raw data values should be increased from the current 32 bytes/chars limit at least a 59 bytes/chars limit (or a 66 bytes/chars limit) to support IPFS CIDs that are either CIDv0 or CIDv1.
They maximum length of "additional" field values should be increased by the same amount.
If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide an email address or a website domain name that is longer than 32 characters, or try to use the IPFS CID (which may be associated with a file such as a document or image), then they will encounter this error:
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Data.Raw values are limited to a maximum length of 32 bytes -
Increasing maximum length of identity raw data values from the current 32 bytes/chars limit to at least a 59 bytes/chars limit (or a 66 bytes/chars limit) would overcome these errors and support IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.
Increasing the maximum length of "additional" field values would also overcome these errors and should be increased from the current 32 bytes/chars limitFieldLimit by the same amount.
If Polkadot on-chain identities are able to store raw data values greater than the current maximum length of 32 bytes, then each identity may want to use the maximum (or more) amount of "additional" custom fields or more, which would impact storage and performance on the network.
Implementations would need to be tested for adherance by checking that IPFS CIDs that are either CIDv0 or CIDv1 are supported.
No effect on security or privacy has been identified than already exists.
No implementation pitfalls have been identified.
It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.
To minimize additional overhead the proposal suggests at least a 59 bytes/chars limit (or a 66 bytes/chars limit) since that would at least provide support for IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.
It alters exposed interfaces to developers and end-users since they will now be able to provide IPFS CIDs that are either CIDv0 or CIDv1 as the values of Polkadot on-chain identity raw data input fields. Optionally 66 bytes/chars limit could be established to optimise for the usage pattern end-users, since that may be more intuitive to them, as it would allow users to provide a link (e.g. URI protocol + CID) rather than just the CID.
Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.
No prior articles.
Why can't we increase the maximum length of Polkadot on-chain identity raw data values and the "additional" field limit from 32 bytes/chars to an even longer maximum length than proposed of 128 bytes/chars?
Relates to RFC entitled "Increase maximum length of identity PGP fingerprint values from 20 bytes".
This proposes to increase the maximum length of PGP Fingerprint values from a 20 bytes/chars limit to a 40 bytes/chars limit.
Pretty Good Privacy (PGP) Fingerprints are shorter versions of their corresponding Public Key that may be printed on a business card.
They may be used by someone to validate the correct corresponding Public Key.
It should be possible to add PGP Fingerprints to Polkadot on-chain identities.
GNU Privacy Guard (GPG) is compliant with PGP and the two acronyms are used interchangeably.
If you want to set a Polkadot on-chain identity, users may provide a PGP Fingerprint value in the "pgpFingerprint" field, which may be longer than 20 bytes/chars (e.g. PGP Fingerprints are 40 bytes/chars long), however that field can only store a maximum length of 20 bytes/chars of information.
Possible disadvantages of the current 20 bytes/chars limitation:
The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.
To minimize additional overhead the proposal suggests a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.
This RFC proposes the expansion of the extrinsic type identifier from the current most significant bit of the first byte of the encoded extrinsic to the two most significant bits of the first byte of the encoded extrinsic.
This RFC proposes a change to the extrinsic format to incorporate a new transaction type, the "general" transaction.
In order to support transactions that use different authorization schemes than currently exist, a new extrinsic type must be introduced alongside the current signed and unsigned types. Currently, an encoded extrinsic's first byte indicate the type of extrinsic using the most significant bit - 0 for unsigned, 1 for signed - and the 7 following bits indicate the extrinsic format version, which has been equal to 4 for a long time.
0
4
"General" transactions, a new type of transaction that this RFC aims to support, are transactions which obey the runtime's extensions and have according extension data yet do not have hard-coded signatures. They are first described in Extrinsic Horizon and supported in 3685. They enable users to authorize origins in new, more flexible ways (e.g. ZK proofs, mutations over pre-authenticated origins). As of now, all transactions are limited to the account signing model for origin authorization and any additional origin changes happen in extrinsic logic, which cannot leverage the validation process of extensions.
An example of a use case for such an extension would be sponsoring the transaction fee for some other user. A new extension would be put in place to verify that a part of the initial payload was signed by the author under who the extrinsic should run and change the origin, but the payment for the whole transaction should be handled under a sponsor's account. A POC for this can be found in 3712.
The new "general" transaction type would coexist with both current transaction types for a while and, therefore, the current number of supported transaction types, capped at 2, is insufficient. A new extrinsic type must be introduced alongside the current signed and unsigned types. Currently, an encoded extrinsic's first byte indicate the type of extrinsic using the most significant bit - 0 for unsigned, 1 for signed - and the 7 following bits indicate the extrinsic format version, which has been equal to 4 for a long time.
By taking one bit from the extrinsic format version encoding, we can support 2 additional extrinsic types while also having a minimal impact on our capability to extend and change the extrinsic format in the future.
Runtime users.
An extrinsic is currently encoded as one byte to identify the extrinsic type and version. This RFC aims to change the interpretation of this byte regarding the reserved bits for the extrinsic type and version. In the following explanation, bits represented using T make up the extrinsic type and bits represented using V make up the extrinsic version.
T
V
Currently, the bit allocation within the leading encoded byte is 0bTVVV_VVVV. In practice in the Polkadot ecosystem, the leading byte would be 0bT000_0100 as the version has been equal to 4 for a long time.
0bTVVV_VVVV
0bT000_0100
This RFC proposes for the bit allocation to change to 0bTTVV_VVVV. As a result, the extrinsic type bit representation would change as follows:
0bTTVV_VVVV
This RFC proposes for the bit allocation to change to 0bTTVV_VVVV. As a result, the extrinsic format version will be bumped to 5 and the extrinsic type bit representation would change as follows:
5
There is no impact on testing, security or privacy.
This change would allow Polkadot to support new types of transactions, with the specific "general" transaction type in mind at the time of writing this proposal.
There is no performance impact.
The impact to developers and end-users is minimal as it would just be a bitmask update on their part for parsing the extrinsic type along with the version.
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.
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.
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.
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.
key
BabeApi_next_epoch
Security: n/a
Privacy: n/a
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.
initialize_block
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.
This RFC should not introduce any performance impact.
This RFC should improve the developer experiences for new and existing parachain teams
Describe the impact of the proposal on the exposed functionality of Polkadot.
This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its primary resources are allocated to system performance.
system_version
AFAIK, should not have any impact on the security or privacy.
These changes should be compatible for existing chains if they use state_version value for system_verision.
state_version
system_verision
I do not believe there is any performance hit with this change.
This does not break any exposed Apis.
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.
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.
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.
As noted above, state bloat is a security concern. In the case of abuse, governance could adapt by increasing deposit rates and/or using forceDestroy on collections agreed to be spam.
forceDestroy
The primary performance consideration stems from the potential for state bloat due to increased activity from lower deposit requirements. It's vital to monitor and manage this to avoid any negative impact on the chain's performance. Strategies for mitigating state bloat, including @@ -3328,7 +3335,7 @@ mitigate this problem and will likely be needed in the future for CoreJam and/or
Extensive testing will be conducted - both automated and manual. This proposal doesn't affect security or privacy.
This is a necessary data availability optimisation, as reed-solomon erasure coding has proven to be a top consumer of CPU time in polkadot as we scale up the parachain block size and number of availability cores.
With this optimisation, preliminary performance results show that CPU time used for reed-solomon coding/decoding can be @@ -3509,7 +3516,7 @@ to acquire them. However, the asset of choice can be changed in the future.
N/A.
N/A
Vec<Transaction>
Irrelevant.
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 capability. They are then in control of the list of nodes with that capability. While doing this can in no way be actually harmful, it could lead to eclipse attacks.
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.
Assuming 1000 nodes with a specific capability, the 20 Polkadot full nodes corresponding to that capability 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 node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.
Implementations can also be tested easily against each other by taking some metadata and ensuring that they all come to the same metadata hash.
Privacy of users should also not be impacted. This assumes that wallets will generate the metadata hash locally and don't leak any information to third party services about which chunks a user will send to their offline wallet. Besides that, there is no leak of private information as getting the raw metadata from the chain is an operation that is done by almost everyone.
There should be no measurable impact on performance to Polkadot or any other chain using this feature. The metadata root hash is calculated at compile time and at runtime it is optionally used when checking the signature of a transaction. This means that at runtime no performance heavy operations are done.
The proposal alters the way a transaction is built, signed, and verified. So, this imposes some required changes to any kind of developer who wants to construct transactions for Polkadot or any chain using this feature. As the developer can pass 0 for disabling the verification of the metadata root hash, it can be easily ignored.
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.
The API of these new functions was heavily inspired by API used by the C programming language.
The changes in this RFC would need to be benchmarked. This involves implementing the RFC and measuring the speed difference.
This pricing model is based on the requirements from the basic linear solution proposed in RFC-1, which is a simple dynamic pricing model and only used as proof. The present model adds additional considerations to make the model more adaptable under real conditions.
This RFC, if accepted, shall be implemented in conjunction with RFC-1.
Implementers of the replier side should be careful to detect early on when a reply would exceed the maximum reply size, rather than inconditionally generate a reply, as this could take a very large amount of CPU, disk I/O, and memory. Existing implementations might currently be accidentally protected from such an attack thanks to the fact that requests have a maximum size, and thus that the list of keys in the query was bounded. After this proposal, this accidental protection would no longer exist.
Malicious server nodes might truncate Merkle proofs even when they don't strictly need to, and it is not possible for the client to (easily) detect this situation. However, malicious server nodes can already do undesirable things such as throttle down their upload bandwidth or simply not respond. There is no need to handle unnecessarily truncated Merkle proofs any differently than a server simply not answering the request.
It is unclear to the author of the RFC what the performance implications are. Servers are supposed to have limits to the amount of resources they use to respond to requests, and as such the worst that can happen is that light client requests become a bit slower than they currently are.
This change will enhance / improve the security of the protocol as it relates to its treasury. The confirmation period is one of the last lines of defence for the collective Polkadot stakeholders to react to a potentially bad referendum and vote NAY in order for its confirmation period to be aborted. It makes sense for the treasurer track's confirmation period duration to be either equal to, or higher than, the big spender track confirmation period.
This is a simple change (code wise) which should not affect the performance of the Polkadot protocol, outside of increasing the duration of the confirmation period on the treasurer track.
If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for?
Security considerations should be taken with the implementation to make sure no unwanted behavior is introduced.
This proposal does not introduce any privacy considerations.
Depending on the final implementation, this proposal should not introduce much overhead to performance.
The ergonomics of this proposal depend on the final implementation details.
We feel that the Polkadot Technical Fellowship would be the most competent collective to identify the testing requirements for the ideas presented in this RFC.
This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations.
The change to add nested delegations may affect governance interfaces such as Nova Wallet who will have to apply changes to their indexers to support nested delegations. It may also affect the Polkadot Delegation Dashboard as well as Polkassembly & SubSquare.
An audit is required to ensure the implementation's correctness.
The proposal introduces no new privacy concerns.
This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration.
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. This RFC offers an alternative solution for on-demand parachains, ensuring that the per-byte cost increase doesn't overly burden the registration process.
When rotating/generating the SessionKeys of a node, the node calls into the runtime using the -SessionKeys::generate_session_keys runtime api. This runtime api function needs to be changed -to add an extra parameter owner and to change the return value to also include the proof of -ownership. The owner should be the account id of the account setting the SessionKeys on chain -to allow the on chain logic the verification of the proof. The on chain logic is then able to proof -the possession of the private keys of the SessionKeys using the proof.
When a user sets new SessionKeys on chain the chain can currently not ensure that the user -actually has control over the private keys of the SessionKeys. With the RFC applied the chain is able -to ensure that the user actually is in possession of the private keys.
#![allow(unused)] -fn main() { -type Proof = (Signature, Signature, ..); -}
The proof being a SCALE encoded tuple over all signatures of each private session -key signing the owner. The actual type of each signature depends on the -corresponding session key cryptographic algorithm. The order of the signatures in -the proof is the same as the order of the session keys in the SessionKeys type.
The version of the SessionKeys needs to be bumped to 1 to reflect the changes to the -signature of SessionKeys_generate_session_keys:
#![allow(unused)] -fn main() { -pub struct OpaqueGeneratedSessionKeys { - pub keys: Vec<u8>, - pub proof: Vec<u8>, -} - -fn SessionKeys_generate_session_keys(owner: Vec<u8>, seed: Option<Vec<u8>>) -> OpaqueGeneratedSessionKeys; -}
The default calling convention for runtime apis is applied, meaning the parameters -passed as SCALE encoded array and the length of the encoded array. The return value -being the SCALE encoded return value as u64 (array_ptr | length << 32). So, the -actual exported function signature looks like:
#![allow(unused)] -fn main() { -fn SessionKeys_generate_session_keys(array: *const u8, len: usize) -> u64; -}
The on chain logic for setting the SessionKeys needs to be changed as well. It -already gets the proof passed as Vec<u8>. This proof needs to be decoded to -the actual Proof type as explained above. The proof and the SCALE encoded -account_id of the sender are used to verify the ownership of the SessionKeys.
Validator operators need to pass the their account id when rotating their session keys in a node. -This will require updating some high level docs and making users familiar with the slightly changed ergonomics.
Testing of the new changes is quite easy as it only requires passing an appropriate owner -for the current testing context. The changes to the proof generation and verification got -audited to ensure they are correct.
Does not have any impact on the overall performance, only setting SessionKeys will require more weight.
Introduces a new version of the SessionKeys runtime api. Thus, nodes should be updated before -a runtime is enacted that contains these changes otherwise they will fail to generate session keys.
Rather than enforce a limit to the total memory consumption on the client side by loading the value at :heappages, enforce that limit on the runtime side.
:heappages
From the early days of Substrate up until recently, the runtime was present in two forms: the wasm runtime (wasm bytecode passed through an interpreter) and the native runtime (native code directly run by the client).
Since the wasm runtime has a lower amount of available memory (4 GiB maximum) compared to the native runtime, and in order to ensure sure that the wasm and native runtimes always produce the same outcome, it was necessary to clamp the amount of memory available to both runtimes to the same value.
In order to achieve this, a special storage key (a "well-known" key) :heappages was introduced and represents the number of "wasm pages" (one page equals 64kiB) of memory that are available to the memory allocator of the runtimes. If this storage key is absent, it defaults to 2048, which is 128 MiB.
The native runtime has since then been disappeared, but the concept of "heap pages" still exists. This RFC proposes a simplification to the design of Polkadot by removing the concept of "heap pages" as is currently known, and proposes alternative ways to achieve the goal of limiting the amount of memory available.
Client implementers and low-level runtime developers.
This RFC proposes the following changes to the client:
Each parachain can choose the option that they prefer, but the author of this RFC strongly suggests either option C or B.
In case of path A, there is one situation where the behaviour pre-RFC is not equivalent to the one post-RFC: when a host function that performs an allocation (for example ext_storage_get) is called, without this RFC this allocation might fail due to reaching the maximum heap pages, while after this RFC this will always succeed. This is most likely not a problem, as storage values aren't supposed to be larger than a few megabytes at the very maximum.
ext_storage_get
In the unfortunate event where the runtime runs out of memory, path B would make it more difficult to relax the memory limit, as we would need to re-upload the entire Wasm, compared to updating only :heappages in path A or before this RFC. In the case where the runtime runs out of memory only in the specific event where the Wasm runtime is modified, this could brick the chain. However, this situation is no different than the thousands of other ways that a bug in the runtime can brick a chain, and there's no reason to be particularily worried about this situation in particular.
This RFC would reduce the chance of a consensus issue between clients. The :heappages are a rather obscure feature, and it is not clear what happens in some corner cases such as the value being too large (error? clamp?) or malformed. This RFC would completely erase these questions.
In case of path A, it is unclear how performances would be affected. Path A consists in moving client-side operations to the runtime without changing these operations, and as such performance differences are expected to be minimal. Overall, we're talking about one addition/subtraction per malloc and per free, so this is more than likely completely negligible.
In case of path B and C, the performance gain would be a net positive, as this RFC strictly removes things.
This RFC would isolate the client and runtime more from each other, making it a bit easier to reason about the client or the runtime in isolation.
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.
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.
This RFC proposes adding a trivial governance track on Kusama to facilitate X (formerly known as Twitter) posts on the @kusamanetwork account. The technical aspect of implementing this in the runtime is very inconsequential and straight-forward, though it might get more technical if the Fellowship wants to regulate this track with a non-existent permission set. If this is implemented it would need to be followed up with:
The overall motivation for this RFC is to decentralize the management of the Kusama brand/communication channel to KSM holders. This is necessary in my opinion primarily because of the inactivity of the account in recent history, with posts spanning weeks or months apart. I am currently unaware of who/what entity manages the Kusama X account, but if they are affiliated with Parity or W3F this proposed solution could also offload some of the legal ramifications of making (or not making) @@ -6462,11 +6367,11 @@ and the community becomes totally autonomous in the management of Kusama's X pos that could be offloaded to openGov, provided this proof-of-concept is successful.
Finally, this RFC is the epitome of experimentation that Kusama is ideal for. This proposal may spark newfound excitement for Kusama and help us realize Kusama's potential for pushing boundaries and trying new unconventional ideas.
This idea has not been formalized by any individual (or group of) KSM holder(s). To my knowledge the socialization of this idea is contained entirely in my recent X post here, but it is possible that an idea like this one has been discussed in other places. It appears to me that the ecosystem would welcome a change like this which is why I am taking action to formalize the discussion.
The implementation of this idea can be broken down into 3 primary phases:
First, we begin with this RFC to ensure all feedback can be discussed and implemented in the proposal. After the Fellowship and the community come to a reasonable @@ -6519,7 +6424,7 @@ to implement them. Here's what would be needed:
After everything is complete, we can update the Kusama wiki to include documentation on the X post specifications and include links to the tools/UI.
The main drawback to this change is that it requires a lot of off-chain coordination. It's easy enough to include the track on Kusama but it's a totally different challenge to make it function as intended. The tools need to be built and the auth tokens need to be managed. It would certainly add an administrative burden to whoever manages the X account since they would either need to run the tools themselves or manage auth tokens.
Finally, this solution is merely pseudo-decentralization since the X account manager would still have ultimate control of the account. It's decentralized insofar as the auth tokens are given to people actually running the tools; a house of cards is required to facilitate X posts via this track. Not ideal.
There's major precedent for configuring tracks on openGov given the amount of power tracks have, so it shouldn't be hard to come up with a sound configuration. That's why I recommend restricting permissions of this track to remarks and batches of remarks, or something equally inconsequential.
Building the tools for this implementation is really straight-forward and could be audited by Fellowship members, and the community at large, on Github.
The largest security concern would be the management of Kusama's X account's auth tokens. We would need to ensure that they aren't compromised.
If a track on Kusama promises users that compliant referenda enacted therein would be posted on Kusama's X account, users would expect that track to perform as promised. If the house of cards tumbles down and a compliant referendum doesn't actually get anything posted, users might think that Kusama is broken or unreliable. This could be damaging to Kusama's image and cause people to question the soundness of other features on Kusama.
As mentioned in the drawbacks, the performance of this feature would depend on off-chain coordinations. We can reduce the administrative burden of these coordinations by funding third parties with the Treasury to deal with it, but then we're relying on trusting these parties.
By adding a new track to Kusama, governance platforms like Polkassembly or Nova Wallet would need to include it on their applications. This shouldn't be too much of a burden or overhead since they've already built the infrastructure for other openGov tracks.
This change wouldn't break any compatibility as far as I know.
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.
The current size of the decision deposit on some tracks is too high for many proposers. As a result, those needing to use it have to find someone else willing to put up the deposit for them - and a number of legitimate attempts to use the root track have timed out. This track would provide a more affordable (though slower) route for these holders to use the root track.
There have been recent attempts to use the Kusama root track which have timed out with no decision deposit placed. Usually, these referenda have been related to parachain registration related issues.
Propose to address this by adding a new referendum track [22] Referendum Deposit which can place the decision deposit on another referendum. This would require the following changes:
placeDecisionDesposit
This track would provide a route to starting a root referendum with a much-reduced slashable deposit. This might be undesirable but, assuming the decision deposit cost for this track is still high enough, slashing would still act as a disincentive.
An alternative to this might be to reduce the decision deposit size some of the more expensive tracks. However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda.
Will need additional tests case for the modified pallet and runtime. No security or privacy issues.
No significant performance impact.
Only changes related to adding the track. Existing functionality is unchanged.
No compatibility issues.
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.
The proof being a SCALE encoded tuple over all signatures of each private session -key signing the owner. The actual type of each signature depends on the +key signing the account_id. The actual type of each signature depends on the corresponding session key cryptographic algorithm. The order of the signatures in -the proof is the same as the order of the session keys in the SessionKeys type.
The version of the SessionKeys needs to be bumped to 1 to reflect the changes to the signature of SessionKeys_generate_session_keys:
#![allow(unused)] @@ -241,7 +247,7 @@ signature of SessionKeys_generate_session_keys: pub proof: Vec<u8>, } -fn SessionKeys_generate_session_keys(owner: Vec<u8>, seed: Option<Vec<u8>>) -> OpaqueGeneratedSessionKeys; +fn SessionKeys_generate_session_keys(account_id: Vec<u8>, seed: Option<Vec<u8>>) -> OpaqueGeneratedSessionKeys; }
The default calling convention for runtime apis is applied, meaning the parameters passed as SCALE encoded array and the length of the encoded array. The return value @@ -259,17 +265,22 @@ the actual Proof type as explained above. The proof an
Validator operators need to pass the their account id when rotating their session keys in a node. This will require updating some high level docs and making users familiar with the slightly changed ergonomics.