We just published a roadmap round-up on the blog here: Polkadot Roadmap Roundup
This thread is for open discussion of the roadmap, any of the items on it, or any of the items that aren’t on it.
8 Likes
As a member of the development team, I would be interested to know what kinds of things are NOT on the roadmap, which are relevant to the community. Would love to see some responses here with things the community would like to see.
2 Likes
I don’t have much to add to the discussion as the Roadmap is clear and complete IMO but just wanted to say thank you 
1 Like
Is there a roadmap for separate protocols and projects, like smoldot, cumulus and even subxt?
There will be a more fine grained roadmap. We are currently working on making it better available (you could already go on github and look at individual projects and their milestones).
1 Like
I was made aware that the actual github project is already public: https://github.com/orgs/paritytech/projects/27
Some teams still need to be on-boarded.
2 Likes
How could we (as a community member) to propose something to be added to the roadmap and/or have something prioritized?
For example, I want to see Redesign Event system (and related issues) in the roadmap so there is some level of guarantee that someone will delicate their time on this in near future.
Here are some of my requests:
You as a community member are free to work on whatever you want. 
All of the code is open source and also quite a few people from the community joined the fellowship. If you need something, work on it or at least try to come up with a plan or some discussion. I know that you are already doing this.
We have spoken about this internally and came up with a plan on how to do the revamp. See: New host functions for non-Merklised optionally-persisted data-types (substrate#12577)
We discussed the roadmap in the Substrate Builders Program office hours call today.
Introducing asychronous backing is great news for parachains but it has a major consequences for all pallets that use timing based on block numbers, particularly pallet-vesting or the orml vesting pallet. Reducing block time to 6 seconds will mean that vesting schedules are suddenly half as long which is clearly not intended. All parachains that use these pallets (probably most of them) will need to migrate their vesting schedules in a safe way. This is not trivial and can be error-prone. I would be great to test this and have a safe migration guideline for parachain teams that ensures that vesting will continue as expected.
3 Likes
Thanks @torsten very valid points, I am also thinking that this is also likely going to affect defi protocols and their associated calculations around items like APY since block rewards are estimated into time-based yields. Some consideration of these differences for migration needs to be accounted for as well.
I am a bit new to this - my only experience working on the recovery pallet, and there’s a lock interval set for security.
I was surprised that the lock interval was in blocks - why not use dates?
From a software architecture standpoint, using dates when you “mean” dates, is the best implementation.
So if a DeFi protocol has a vesting schedule, that must be expressed as date, not as number of blocks, since number of blocks can vary greatly. Even when it’s 6 seconds, it’s not exactly 6 seconds, at least on our current nodes, block time varies between 6 and 15 seconds.
While I would expect a production level node to have a more stable block time, it’s still never going to be a precise time measurement.
I understand that many chain-internal measurements are likely best expressed as number of blocks.
But many user-facing measurements would be best expressed as timestamps, and making them be block time is basically a bug, as I am concerned.
Take the safety interval in the recovery pallet - it’s supposed to be 24 hours, so we try to derive a block interval that is more or less 24 hours.
Imagine a million people set up their recovery with 24 lock time. Now the block time is half, and now everyone only has a 12 hour safety interval all of a sudden.
To me that’s not a matter of just migrating the pallet to double all wait times.
It’s a matter of using the correct architecture and correct ways of measuring time in the first place.
So I wonder - why doesn’t recovery pallet and various DeFi pallets use timestamps? As far as I am aware timestamps are available in the system?
Sorry for the possibly ignorant question, I am pretty new to Polkadot.
(This is getting off topic…)
For Acala / Karura, our vesting is implemented using orml-vesting + relaychain block number so we won’t have issue on this when parachain block time changes from 12s to 6s. Use RelaychainBlockNumberProvider if you want to access it.
One easy migration for parachains using their own block number is by switching to relaychain_block_numebr * 2 - some_constant. By picking the right constant, this ensures this number won’t be impacted by change of parachain block time. No onchain state migration are needed.
Speak of why block number instead of timestamp:
- Timestamp can be manipulated by block producers to some degree
- Timestamp is not monotonic. Block number is.
- For example, if you want a logic to be executed every minute (or 5 block for 12s block time). Using block number guarantees one execute per 5 block. No edge cases. Using timestamp and you need to record the last execution time, and check time change since last executed time, and handle edge cases such as time goes backwards etc. The logic is simply lot more complicated.
1 Like
Thanks for your reply. Will definitely consider the relay block number - that’s great.
As for timestamps - true that accurate time keeping is a duty of bps and if that is manipulated it would be an attack point. We use timestamps in EOSIO though, seems fine .
As for the second argument, that’s just a different use case - some use cases are better served with blocks, others better served with accurate timestamps. The use case you mentioned is clearly better served with blocks. The recovery pallets time lock is a clear use case where time stamps are better. Using appropriate solutions to fit the problem space.
Anyway it’s pretty clear now so thanks for the reply!
@xlc This is a great solution for orml-vesting but for other pallets (including pallet-vesting) this will not work as they hard code requesting the current block number from frame-system, i.e., the parachain.
Just open a PR to fix it? It is a simple change.
It applies to a lot of the standard pallets and this is more about how to migrate data that is already in storage, e.g., vesting schedules. Even if this is fairly simple code at the end, it is still quite error-prone with important consequences for token holders that are subject to vesting.
At the end the point of my original comment was to raise awareness about new challenges that arise for parachain teams when asynchronous backing is introduced.
1 Like
It might make sense to gather the list of pallets affected by the faster block times from asynchronous backing and have the potential risk and fixes collected and verified by the collective.
Good idea. I had a quick look at all standard pallets defined in the substrate repository and at least the following pallets will be affected. For some of these pallets there is only a short-lived problem: just replace some configuration parameters with double their value and some storage values will then contain inconsistent timing information but will become invalid after a few days (depending on the logic of the respective pallet). For some other pallets the challenges are deeper. Some of these pallets might also be very rarely used among parachains.
- pallet-alliance
- pallet-atomic-swap
- pallet-bounties
- pallet-child-bounties
- pallet-collective
- pallet-conviction-voting
- pallet-democracy
- pallet-elections-phragmen
- pallet-gilt
- pallet-im-online
- pallet-lottery
- pallet-proxy
- pallet-recovery
- pallet-referenda
- pallet-scheduler
- pallet-scored-pools
- pallet-session
- pallet-society
- pallet-tips
- pallet-transaction-storage
- pallet-treasury
- pallet-vesting
When it comes to asynchronous backing, I think one of the clearest things we can do is make it totally opt-in per parachain and let them upgrade as they see fit.
We can create a guardrail for parachains to stick with the exact behavior they currently have. This is for it to be illegal to create a parachain block until the parent parachain block has been included on the relay-chain. That will leave the status quo of 12 second relay-chain blocks and no scalability improvements. Then each parachain can remove this limiter as and when it sees fit.
I am surprised this is a real concern at all, though. If there is some specific representative of a parachain team which cares about this, please file an issue on Cumulus referencing this safeguard.