Copy from: https://polkadot.polkassembly.io/post/101
Github: https://github.com/patractlabs/redspot-0.2
Redspot's goal is to standardise the contract development process, hide the underlying compilation details of the contract, and combine the sandbox, library, API, SDK and other plugins to create a one-stop smooth contract development process. We have finished the first proposal requirements for v0.1, and written a development report.
Summary of Redspot's future plan:
- v0.1: Build core available functions based on Truffle framework.
- v0.2: Migrate to the Buidler framework to enhance plugin extensibility and add some functions to provide a smoother development workflow.
- v0.3: Imitating Buidler's plugins, combined with the characteristics of Substrate to add various plugins, such as waffle, and began to integrate multi-language SDK.
- v0.4: Following the case of Buidler, add appropriate libraries, such as typechain, etc.
Problems of Redspot v0.1:
Although we have completed all the basic functions of Redspot, there are still some inconveniences in use. E.g:
- There is no convenient interactive cli for simple interaction with deployed contracts;
- Only the private key in plain text is supported in the configuration file, derivation through seed is not supported, and the password cannot be hidden;
- Under the default instantiation address logic of pallet-contracts, the contract address generated by a single account with the same parameters and the same WASM code is unique. This is not like Ethereum's single account can repeatedly deploy the same contract with different addresses. Therefore, after the deployment script and test script are written in Redspot, they can only be executed once. Otherwise, during the second execution, the execution will be interrupted during the deployment phase because it cannot be deployed. This requires script developers to pay careful attention to the writing method, otherwise it is easy to make mistakes. Redspot hopes to simplify this process.
- When deploying scripts and test scripts are instantiating or calling contracts, gas_limit needs to be written in after estimated whether the current assets are sufficient to support contract execution. Redspot currently simply fills in a default value, and does not have an estimation method, and does not know the gas consumption after execution;
Detailed design of v0.2 (6 weeks, 21 Sept ~ 2 Nov):
The Buidler framework provides a "plugin" model, which can give Redspot great scalability and flexibility. This framework can also support Redspot to connect with contract modules on different parachains. For example, you can replace the environment of the target chain through plugins, add SDKs in other languages, and add extensible functions. In v0.2, Redspot will migrate all the functions of v0.1 to the new Buidler framework, and write various plugins to solve the problems of v0.1.
Milestone 1: (3 developers * 1 weeks )
Fork Buidler framework and modify it to suit the Substrate blockchain, then migrate all the current features in Redspot v0.1 as inner plugins to this new framework.
Milestone 2: (3 developers * 1 weeks)
Support an interactive cli to operate deployed contracts, this cli will include injected polkadot.js interface and other helper functions, global env, key pairs, and connected node.
Milestone 3: (3 developers * 1 weeks)
Plugin 1: key pair support.
- Developers can use a private key directly;
- Developers can use a seed, and can derive account from this seed;
- Developers can use indicate a path for the keystore file, so that the private key will not appear in the config file.
Milestone 4: (3 developers * 1 weeks)
Plugin 2: multiple executing test support. This plugin provides a way to allow developer to deploy contracts more than once using same account and parameters in tests.
- Developers can use “beforeTest” to derive accounts and transfer some balance to this new account.
- Developers can use this new account to deploy contracts.
- Every executing test command will derive new accounts automatically.
Milestone 5: (3 developers * 0.5 week)
Plugin 3: Jupiter test-net support as deploying environment;
- Jupiter test-net will use a flag storage to allow developers to use same account, same parameters and same code to deploy more than once.
- This plugin will develop a matching interface to interactive with Jupiter to set flag.
- This plugin’s env will allow developers to do deploying and testing in a normal way.
Milestone 6: (3 developers * 1.5 weeks)
Plugin 4: gas usage report.
- This plugin can print gas usage per test phase and deploying actions.
- This plugin can print gas usage per interactive cli.
Cost of v0.2 (18 developers * weeks)
- Operating activities: $3600 ( Rent and Devices: $200 per developer * week )
- Employee payments: $27000 ($1500 per developer * week)
- —————————— +
- Total Cost: $30600
- Exchange Rate: $4/ New DOT
- Treasury Proposal: 7650 New DOT
How to verify v0.2: Youtube demo video & Github source
- Replay all v0.1 tests in v0.2
- Show how Redspot v0.2 interactive cli works
Workflows:
- Use "deploy" command and execute deploying scripts
- Use interactive cli
- Call deployed contract
- Send extrinsics to call a contract
- Deploy a new contract in cli
Plugins:
- key pair plugin:
- allowing developers to use seed, private key or a keystore path in config
- multiple executing test plugin:
- could repeat any test command without any changes in test scripts.
- Jupiter test-net plugin:
- could connect with Jupiter test-net by using a config flag in config files
- could repeat any test command without any changes in test scripts.
- Gas usage report plugin:
- could print gas usage for every test phase
- could print gas usage after calling a contract in interactive cli