First of all, thank you all once again for coming to the Polkadot Technical Parachain Summit. I personally think it was great to work all together, and hope that we can do more of these in the future.
I wanted to post about all the things Substrate + Parachains + FRAME discussed during the Polkadot Parachain Summit so that we can:
Prioritize the list. <-- We are here now
Scope in detail what implementing these means.
Decide on the execution.
The way that I’ll be setting this up is with a brief description of all the open items, and then with a poll where everyone can select three items they think are the highest priority ones. Once we select this, then we can go into scoping.
If anyone raised any of the points below and wants to expand on these, please do so! The more information the better.
Pallets
Basic Pallets - Requests
Index
Organization
Pallet
Features / Issues
1
FRAME
Utils
- Propagate erros on batch transactions. - Meta transactions (github issue)
2
FRAME
Multisig
- Mimic Gnosis Safe functionality. - Allow for configuration of call data Storage when initiating the Multisig.
3
FRAME
Proxy
- Rename from anonymous_proxy to keyless_proxy. - The proxy keeps deposit after it’s been killed instead of returning to parent account and this should not be the case. Source Code.
4
FRAME
System
- Refactoring of Accounts System. - Refactoring of Events: specifically how events now need to propagate amongst different pallets and XCM. Maybe it can be indexed by pallet or event name (instead of index).
5
FRAME
SUDO
- Allow for more than one user. - Allow for feeless txs from with signed extensions. - Return an error from the operation that SUDO is trying to execute, instead of a SUDO error. - Handle detection management of wrapped SUDO calls.
6
FRAME
Tx Fee
- Support multi-currency management by default. We can drive inspiration from HydraDX transaction_multi_payment. - Revisit fee adjustment mechanism.
7
FRAME
Scheduler
- There is high need in the ecosystem for this pallet. - As it is, it needs an entire re-work.
- Generate a standard across token management pallets in the ecosystem. - Together with this Balances pallet also comes in to play, and a standarization between tokens and assets is needed.
New Pallets Requests
Index
Pallet
Description
10
Parachain Metadata
This pallet would allow one parachain to query the metadata of another parachain with the objective of facilitating the interaction between these.
11
Simple DPoS
A Simple DPoS pallet that allows teams to decentralize and incentivaze their collators. Currently there’s Moonbeam and KILT systems that are being used in the ecosystem. Another reference is Astar that built a custom pallet for dapp rewards.
12
Call Filter
A Pallet that would allow the governance of a chain to trigger certain call filters to stop a set of calls from working. This would be an emergency system that pallets can be use, similar to Moonbeam’s Mantainance Mode or also what Acala has in place. This issue from Gav can also be leveraged.
This could be a pallet or not. The objective is to create a standarized way of registering assets so that the ecosystem is aware of them. One idea is to use create an on_token_creation hook.
Features and Tooling
Simulation and Testing Support
Testing
[14] Fork Chain Tooling. The objective is to be able to from a running chain, fork it, and from that point onwards have complete control over the state, by disabling signature checks. This would allow teams to test out different scenarios depending on the current state of the chain.
[15] Fuzzing. Create a fuzzing testing system for pallets. Important to scope out what to expect.
[16] Automatic multi-block migrations. This is a nice-to-have feature from the ecosystem.
[17] Incremental Blocks. Better tooling around incrementing block# on a chain instead of waiting.
Note: There is a great interest on Zombienet, and teams need for it to work flawlessly.
Runtime/Substrate and Parachains
Runtime/Substrate & Usage
[18] Storage Deposit as Native. Add a wrapper around storage apis to return a result. In the background they take deposit.
[19] Allow panic on Runtime. This is more a discussion request than a feature request. The objective is to discuss if panic! should be allowed on runtime and also how to find these panic! in the runtime.
[20] Migrations. Re-think how migrations can work and see if the Migration Story can be made simpler. It will be something difficult to do.
[21] Bubble all fees. Users should be able to see all fees associated with a transaction, including the reserved tokens that might come from the it.
[22] Fixed Point. Encointer pointed out the need of having fixed point also in Substrate, from here. Not sure though if it’s widely needed.
[23] Runtime Upgrades Timeframe. Have some emergency system for parachains to do runtime upgrades faster. I discussed this and it can’t be instant, but maybe it can be made faster. Still a combination of this together with the Call Filter pallet could work as a mechanism.
Others
no-std and WASM separation. The need is more on how to approach doing this.
Get metadata from WASM file. This is tied to the ‘Parachain Metadata’ pallet request. The objective is to allow parachains to be able to decypher the metadata of a specific chain given it’s wasm file. Maybe this could be an RPC on Polkadot.
For point [15], fuzzing, there is this fuzzing tool created by SRLabs on Rust that can work as the backbone of any fuzzing specifics for Substrate chains. The team is welcoming issues and PRs on the tool, so feel free to look into it and collaborate!
We have been using multisigs and proxies very extensively at Centrifuge. The double meaning of proxy is extremely confusing. Alice can be a proxy on the (anonymous) proxy Bob. I think calling it a “keyless proxy” would not improve this. I think it should be called a keyless account. Then the wording at least is more clear: Alice is a NonTransfer Proxy on the keyless account Bob.
Regarding those two requests for tooling and testing. We at Centrifuge wrote a lib called fudge for this.
Mainly the lib does provide three things:
Building blocks locally without any consensus
→ Define costume Timestamp to warp time, build X blocks without waiting X * BlockTime
Accessing any state (block) of a database immutable
→ Roughly the same API as the current TestExternalities that tests in substrate pallets provide
Accessing the latest state (block) of a database mutable, finalizes the changes in the underlying database as the latest finalized state
→ Should allow to mutate block building authorities to DEV accounts and run the chain again locally
We are currently using it in our integration test and I think it would be great if other teams play around with the lib, so we can develop this into a useful tool for everybody.
Soon there should also be XCM support while building blocks. That will actually mimic the complete XCM code path.
I.e. Injecting data through Inherents and using the actual queues and pallets of a specific runtime in a relay-para-chain setup.
@santi there is one more thing I would like to have information on or put up for discussion.
Are there any plans to allow different substrate versions to co-exist as dependencies in one crate?
In the past, there were issues with the parity-util-mem crate and sometimes I get errors I don’t understand (I think primitive APIs change), and sometimes it works.
The reasons why this would be valuable
Avoid using latest version of a pallet
→ Migration might be too expensive for our state, teams just don’t want the latest feature
Possibility to version own pallets
Currently, dev, staging, and production runtimes must always be simultaneously updated to the latest changes of a local/remote pallet. This makes it impossible to test new features in a dev-runtime, and still be able to cut out new releases for the staging and production environments (for bug fixing or so).
The SafeMode and TxPause pallets are coming up in Substrate.
Many para-chains already have such pallets in slightly different ways.
Hopefully you can find the time to review the concepts of both .
They are briefly described here https://github.com/paritytech/substrate/pull/12092
For scheduler pallet use cases, do you have any more information on the need? OAK/Turing has quite a bit more functionality and time guarantees than scheduler. We’re happy to help address any needs other have via XCMP.
Scheduler rework is happening here, but I don’t know which feedback came in from the para-chains.
This MR mainly focuses on using the preimage pallet in the scheduler and elsewhere, since it started long before the Summit.
On point 3, I have been using pure proxy for the last year or two when referring to “anonymous proxy”. I think this is better than keyless proxy, since even regular proxies may be “keyless” - the difference with a pure proxy to a regular proxy is the lack of an owning account (which may or may not be based on authentication through a keypair). Furthermore the code you reference simply states that pure proxies may not have the deposit returned - regular proxies always get their deposit returned. This is because pure proxies are not created through a deposit since there is by design no owner who could have their funds returned to them.
During ambassador talks when explaining it to regular people I’ve used keyless/virtual account as it is really not a proxy and that confuses people. Nice to hear more thoughts in Proxy Pallet On Steriods I’m specially looking forward to allow tx payment from the target virtual account and not the proxies controlling it.
It is an account through which another account may be controlled. That fits the definition of a “proxy”. I won’t repeat myself on the explanation of why “keyless account” does not fit.
But isn’t every account an account through which another account may be controlled? when you create a pure proxy the account is not a proxy yet but it may end up controlling another account and that makes it a proxy, is that it? Anyway whatever the name hopefully is well communicated to avoid the current confusions people are having with anonymous proxies
.
Anyway whatever the name hopefully is well communicated to avoid the current confusions people are having with anonymous proxies 