Redspot is one of Patract's Wasm contract development tool suite. Redspot's goal is to standardize 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. Patract had finished 3 proposals for Redspot at 4 months ago, the latest one is for v0.3 at treasury #23, and the report is at post #207 . We also had followed up the changes of Pallet-Contracts and ink! during the last 4 months.
There are also many parachain teams already in use of Redspot, including Acala, Plasm, Litentry, OpenSquare etc. At the ParityAsia Hackathon, the inkBridge and SkyePass all used Patract suite (Redspot, Europa, PatraStore, etc.) to develop Wasm contract DApps from zero and win the 2nd and 3rd prizes.
In the old design of the v0.4, the plan we expected is no longer suitable for the recent situation:
Typescript support for contracts: After discussing with Jacob (api-contract in polkadot.js is going to support Typescript), we believe that its importance is not high and does not affect the current use, so the support for contract Typescript is placed after api-contract supports this function.
Integrate multi-language SDK: Since pallet-contracts changed the interfaces in 3.0.0 and the recent changes are huge, the Himalia project of Patract’s multi-lang SDKs currently has only the Go version to catch up with the latest changes, and the python version is not updated in time. Moreover, the java version and .NET version have not been launched yet, so the multi-lang SDKs are not yet fully prepared, so they are temporarily unable to be integrated into Redspot in this version.
The problem of ink! and cargo-contracts compiling multiple contracts has been corrected after the submission of Cargo-contract PR#199. Therefore, Redspot can restart the supports for multi-contract compilation (Redspot once supported the multi-contract organization structure to a certain extent, but was stopped due to the inability to compile)
Redspot's multi-contract support will start from the following aspects:
redspot.config.ts supports configuration by file index.Redspot will automatically find all contract files in this directory through the configured search directory. Then compile through the configured compile tool, and finally all compile results will be output to the artifacts directory. At the same time, a buildInfo file will be generated, which records the project directory structure before compilation.
Supporting the invocation of docker in Redspot can solve many problems related to environment setup. For related discussions, see cargo-contract issue #188 and cargo-contract issue #184, submitted by us. Therefore, when we noticed that the cargo-contracts dockerfile appeared in the CI of scripts, we can add related functions for Redspot about calling docker.
Redspot will detect whether there is an existing docker environment. And automatically pull the docker image of the specified version. On the other hand, Redspot will maintain a docker image as the default testnet.
Since the main functions of Redspot have been relatively complete, the follow-up of Redspot will do more easy-to-use development on the product. For example, providing a contract-related UI interface to Redspot can make it easier for beginners to get started with the contract development process. On the other hand, there are some functions in Redspot that need to evoke the browser to participate in the corresponding operation (for example, call the polkadot{.js} extension to sign).
Although parity has provided Canvas UI and Developer-Contracts in https://polkadot.js.org/apps , these two cannot reach our demand in terms of the specialization of the contract part. For example, Canvas-ui provides a more intuitive contract operation interface, but it does not has chain-related display information. Although apps has a more comprehensive information display, the contract call part is stronger than canvas-ui, but regardless of canvas-ui or apps are still lacking in contract-related functions, such as scanning and recording existing contracts, parsing contract parameters, and associating with the secret key in the Redspot configuration, and so on.
On the other hand, like Truffle, Redspot will also be designed to be used in a production environment to deploy contracts, so Redspot needs to provide a secure way to sign transactions. For example, hardware wallets such as ledger and parity-signer can be used in the future to deploy and call contract transaction signing. In this way, developers can firstly uses a configuration similar to development, configures the test key to test the contract in the test environment, then switches to production environment, configures the key of the production environment to deploy the contract. In order to take care of all environments, we think that calling the browser to interact is a better method. So this time we try to integrate the call of polkadot{.js} extension.
In summary, Redspot's web interface will provide beginners with a wealth of information to start contract operations, and also integrate some operations that cannot be handled in the cli environment:
4.1. Redspot-watcher
Currently Redspot executes commands such as redspot test, redspot console, etc. to check whether the contract file is modified when it is executed. Therefore, the developer needs to judge whether the contract needs to be compiled and add the --no-compiled command to inform redspot that the contract does not need to be compiled for this execution. Therefore, after the introduction of redspot-watcher, before calling the redspot runtime to execute, the redspot-watcher can determine whether there are file changes, so as to determine whether the compilation process needs to be invoked.
redspot-watcher will modify redspot's test, run and console commands. Before each run, the file hash will be calculated and stored in the buildinfo file, and then compared with the previous file hash. If there is no change, the compilation will be skipped.
4.2. Balances decimal plugin
In web3.js, you can use methods such as 1 ETH to replace inputs like 10000...000. This human-readable approach can greatly reduce the probability of making mistakes when developer write scripts and tests. However, because the precision of Ethereum is fixed, and when Substrate introduces pallet-contracts, the precision is determined by this chain, so the plug-in is not a static conversion, but needs to get the relevant information of the chain (decimal, symbol ) to be converted.
Therefore, the plug-in will eventually achieve functions similar to the following:
4.3. default blockchain types plugin
Since Substrate has not yet integrated scale-info, each chain provides types to support the parsing of polkadot.js. Currently, Redspot requires developers to fill in the type information in redspot.config.ts, which causes some troubles for developers. This plug-in obtains the types of different chains that already exist in apps, provides it to polkadot.js by default, and allows developers to override the form in redspot.config.ts, so that in most cases, developers do not need to worry about the need of providing polkadot.js the types.
We will discuss with polkadot apps and hope to release the @polkadot/apps-config package. Then all types provided in this package will be registered. We will also process the known contract chains with wasm functions. Maintain the types of their test chain. In this way, as long as the chain’s specversion is correctly set, there is no need to worry about the version.
Week 1: Implement docker support (3 developers)
Week 2: Support multi-contract compilation and redspot-watcher plugin (3 developers)
Week 3-4: Web interface design and development (3 developers * 2 weeks + 1 designer * 1 week)
week 5: Develop balances decimal plugin and default blockchain types plugin (3 developers)
artifacts directory, and the file permissions are correct.1 Unit, 1 DOT, etc.