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
Any plan on fixing the deposit issue with Pure proxy ? I would be happy to use this feature again, but the fact that it could lead to “inconsistent state” (where an account still has reserved tokens but no proxy anymore) is still a deal breaker for us.
I think “virtual account” more clear for normal people. the difference between “pure proxy” and normal proxy account is the direction relation with origin account. this confused people a lot.
The link to your integration tests seems to be broken. Could you please update it? Our team is checking this FUDGE lib right now and would be nice to see an example of how it is used. Thank you!