If you are looking to build something on Polkadot ecosystem but don't know where to start, here is a list of the ideas that I would love to see them implemented.
If you actually start building one of those, or are already building something similar, please reach out to me and I can help you with mentoring & technical support (either from myself, someone from Acala team, or connect you to Parity or other ecosystem teams) and funding support (Polkadot Treasury, Kusama Treasury, W3F grant, Acala grant, other ecosystem grant).
If you have other ideas, please comment below and I can add it to the list.
Note that many teams are already working on various important common good library and tools such as generic multichain transaction history service so I will refrain to list those to avoid potential duplicated works.
-
- Index blockchain data from multiple chains into a single database to make cross-chain query possible
- Polkadot, Polkadot parachains, Kusama, Kusama parachains
- Index all the raw blockchain data, in raw format and parsed format
- Blocks
- Metadata
- Extrinsics
- Events
- Storage changes
- This is what current indexer / scanner missing
- Store the changed storages for every given block
- Allow people to query on exactly when a storage value changed (when my balance changed?)
- Use relational database with JSON support. e.g. PostgreSQL
- Problem to solve:
- Make cross-chain query:
- to analysis account activity across multiple chains
- to analysis XCM related events across all related chains
- Identity why / when something changed
- When and why does my balance changed
- When and how does a particular invariant breaks
- Get notified on a particular storage changes
- Event notification are not exhaust so monitor for storage change can be a better alternative depends on use case
- Less needs to write custom indexer as this one already have EVERYTHING in the database. So all we need is write some SQL to create new views and make sure they are indexed properly.
- This will be the foundation for many ideas such as XCM analyzer, blockchain notification tools, blockchain BI tools, etc
- Make cross-chain query:
- How to build it:
- Use SubSquid or SubQuery or some custom solution (e.g. something like this) to index every blocks, and save all the related information to a database
- Use
state_traceBlockto query changed storages for a given block - Parse the storage change and store them as a JSON object
- Index blockchain data from multiple chains into a single database to make cross-chain query possible
-
- Expose MobX API to access onchain data structure
- Allow writing reactive program without writing reactive program
- It is magical
- Problem to solve:
- Write sync code and it actually works under async environment
- Super efficient because only one storage subscriptions is enough
- I like MobX
- How to build it:
- We already built it but we have no time to maintain it and it have been removed. So basically use this as a reference implementation and recreate it with latest polkadot.js or Capi https://github.com/open-web3-stack/open-web3.js/tree/fcd830abb3ffbcdd36935b0e3174e42d6aebe967/packages/api-mobx
- The core idea is use metadata to generate the state root object, use
state_subscribeStorageto listen for new storages and make corresponding update to observed MobX state - Need to handle various edge cases correctly including but not limit to reconnection, head revert, discarded fork
- Will need to use
state_traceBlockwhen handling edge cases
-
- Implements Proxy & MultiSig support on top of existing extension wallet (polkadot.js extension, Talisman, SubWallet, etc)
- Browser extension allow people to configure Proxy & MultiSig
- Problem to solve:
- Make Proxy & MultiSig useable in dApps without waiting for extension support, which is never going to happen for some
- Allow people to still use the existing extension without switching over
- How to build it:
- Implement a browser extension with some UI to allow management of proxy and multisig accounts
- Hijack the injected
injectedWeb3object and override the signing functionality and replace the signing payload toproxy.proxyormultisig.asMultiand let the actual wallet to handle the modified signing request - Needs some PoC to confirm this won't cause some unexpected behavior (which is very likely to happen)
-
- Library to build XCM calls
- Need to be able to encode calls from multiple chains
- Problem to solve:
- XCM is super powerful but it is super hard to construct some XCM calls involoved with multiple chains. e.g. The one used by Kusama governance to make Transact on Statemine to make Transact on Kusama to accept HRMP channel.
- Should be able to somehow figure out the correct weight limit
- How to build it:
- Just some js function to handle the tx encode, weight query, abstract common pattern (withdraw asset, buy weight, transact, refund) etc.
-
- Implemented at: https://github.com/AcalaNetwork/chopsticks
Similar to this https://github.com/maxsam4/fork-off-substrateTools that takes storage snapshots from relaychain and parachains, tweak it, generate new genesis, launch a testnet with latest block state.So we can easily replicate live networks locally and run some crosschain testsProblem to solve:Be able to test crosschain code with live network data
How to build it:Allow user to specify the chains to forkGet the latest storage from each chainTweak authorship related storagesTweak block number consensus realted storagesTweak account balances so you have test tokens to run the testAllow user to specify what other storages to tweakGenerate new genesis for each chainGenerate script to launch each chain. Maybe able to use https://github.com/open-web3-stack/parachain-launchAlterntely, you may fork Cumulus & Polkadot to create a custom client that ignores signature validation (always valid), ignores parachain block validation (always valid) and ignore some other security restrictions to allow this custom relaychain / parachain networks run with fake data and signatures.
-
- https://forum.polkadot.network/t/pallet-idea-safe-scheduler/1009
- Implements the scheduler traits
- Instead of dispatch call in
on_initalize, do it with an unsigned transaction that triggered by offchain worker - Allow governance method to purge bad scheduled tasks
- Problem to solve:
- Currently, if scheduled task panic, overweight, doing anything crazy, the chain dies. There is no way to avoid execute the bad task because it is part of
on_initializehook that cannot be bypassed. - If it is triggered by offchain worker sending unsigned tx, that means the block producer can ignore it if it panic or overweight.
- It is also possible to have all the council members submit a proposal & approve & close within a single block and with enough tip, front run the bad unsigned tx, to prevent it or fix whatever onchain data.
- And
on_initializeis executed before inherents so it have old block timestamp, no access to current relaychain parent number, etc.
- Currently, if scheduled task panic, overweight, doing anything crazy, the chain dies. There is no way to avoid execute the bad task because it is part of
- How to build it:
- Use the current pallet-scheduler as a reference implementation but add offchain worker & unsigned tx trigger part
- Need to carefully handle the weights and priority and permission
-
-
New macro to annotate origin requirement for extrinsic
-
Expose such requirement via metadata so frontend will know exactly which method are supposed to be called by users (the one annotated with EnsureSigned)
-
Problem to solve:
- The only way to check what origin can call an extrinsic is reading the code, there are number of failed council proposal that are failed due to bad origin requirement. If those requirement are exposed to SDK then it will be possible to prevent such bad proposals in UI
-
How to build it:
-
Something similar to the
pallet::callmacro -
Support such syntax:
-
#[pallet::weight(0)] pub fn root_only(origin: #[require(EnsureRoot) _, parameter: u32) {} #[pallet::weight(0)] pub fn signed_only(origin: #[require(EnsureSigned)] T::AccountId, parameter: u32) {} #[pallet::weight(0)] pub fn council_only(origin: #[require(T::UpdateOrigin)] _, parameter: u32) {}
-
should compile to code with
pallet::calland -
#[pallet::weight(0)] pub fn root_only(origin: OriginFor<T>, parameter: u32) { let origin = EnsureRoot::try_origin(origin).or_else(|_|BadOrigin)?; // body } #[pallet::weight(0)] pub fn signed_only(origin: #[require(EnsureSigned)] T::AccountId, parameter: u32) { let origin: T::AccountId = EnsureSigned::try_origin(origin).or_else(|_|BadOrigin)?; // body } #[pallet::weight(0)] pub fn council_only(origin: #[require(T::UpdateOrigin)] T::AccountId, parameter: u32) { let origin: T::AccountId = T::UpdateOrigin::try_origin(origin).or_else(|_|BadOrigin)?; // body }
-
-
If Metadata v15 is possible, update metadata format to include the origin information
-
Otherwise just abuse extrinsic doc and have the origin information appended there
-
Do the macro magic
-
-
- New macro to assert invariants
- Should be compiled to nop with feature
on-chain-release-buildso that prod wasm is not included those assertions - But we can use wasm override to run node with those assertions to ensure everything are still fine
- Problem to solve:
- Catch bugs on production (or during tests)
- Invariant are also part of the documentation
- Helps with sleeping
- How to build it:
- There are many invariant / assertion library, just use them as reference or apply them to Substrate directly if possible
- Use feature flag to gate it
- Could be integrated with paritytech/substrate#10174
-
- https://github.com/paritytech/substrate/issues/11988
- Inspired by Jam https://twitter.com/Jam10o/status/1548590622789042181
- Allow dispatch calls on behalf of an account, authorized by the origin account signature
- Make some interesting use case possible.
execute(batch_all([as_user(Alice, transfer(10 DOT, Bob)), as_user(Bob, transfer(100 aUSD, Alice))]), [alice_signature, bob_signature])to perform atomic swap between Alice and Bob
- Problem so solve:
- Multi account atomic transaction
- Dispatch tx on other chain via XCM
- Allow other account to pay for tx fee
- How to build it:
- Few points to keep in mine:
- The whole body must be part of the signature payload
- The signature payload need to include chain genesis hash to prevent relay attack on other chains
- Must have signataure replay protection
- Usually nonce is used to implement replay protection, but in order to prevent state bloat, the account must have ED to keep nonce data, so it won't work for accounts that does not have balances. Therefore some alternative solution maybe needed.
- Signer must have a way to invalid the signature. Or the signature cannot be valid forever.
- Few points to keep in mine:
-
- I still have 48 open issues at Substrate and some of them are relatively easy to implement and some of them are actually quite important: https://github.com/paritytech/substrate/issues/created_by/xlc
- Or my Polkadot issues: https://github.com/paritytech/polkadot/issues/created_by/xlc
@xlc could you also note when someone/team has started working on any of the ideas here so we know where to place our focus. Thank you :)