You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
background:
This is a proposal similar to #659, this time targeted extrinsics.
Since now we have both contract-transcode and contract-metadata as isolated libraries, any smart contract that is compatible with the metadata version can:
use it to load the contract bundle
use the transcoder to encode, decode the payload and event output.
Currently for live testing contracts against pallet-contract, most likely one will end up setup subxt and use the contract-metadata, contract-transcode to test it's logic and input and output.
Operation around uploading/deploying/calling/reading is regularly involved when testing against live environment. If we can extract those extrinsics ops out, it might make writing testing framework or other alternative clients more easily.
proposal:
Expose most of crates/cargo-contract/src/cmd/extrinsics as library, so it can be reused or embedded in other projects.
hyperledger/solang#990 is an in progress PR of creating tests against solang compiled solidity contracts using subxt, as you can see here, most of the setup code is achieving very similar goals like cargo-contract does in the cmd module.
The end result of this proposal will definitely let solang stay close to the testing environment cargo-contract currently have to iron up rough edges, and perhaps open up other limitation not needed by ink contracts but important to other smart contract runtime running on top of pallet-contracts.
For example contract-metadata currently don't support I256, U256 type which solang supports, which the contract-transcode will refuse to encode input for solang if those types are summoned.
effected use cases:
the developer experience of the following use cases will most likely be improved due to less hand-rolled setup code.
testing contract logic and state changes against a running chain
testing against chain built-ins or extensions that through contract output
incorporated into clients to have preliminary ability to upload/call/read contract, e.g solang CLI.
Info
background:
This is a proposal similar to #659, this time targeted extrinsics.
Since now we have both contract-transcode and contract-metadata as isolated libraries, any smart contract that is compatible with the metadata version can:
Currently for live testing contracts against pallet-contract, most likely one will end up setup subxt and use the contract-metadata, contract-transcode to test it's logic and input and output.
Operation around uploading/deploying/calling/reading is regularly involved when testing against live environment. If we can extract those extrinsics ops out, it might make writing testing framework or other alternative clients more easily.
proposal:
Expose most of
crates/cargo-contract/src/cmd/extrinsics
as library, so it can be reused or embedded in other projects.hyperledger/solang#990 is an in progress PR of creating tests against solang compiled solidity contracts using subxt, as you can see here, most of the setup code is achieving very similar goals like cargo-contract does in the
cmd
module.The end result of this proposal will definitely let solang stay close to the testing environment cargo-contract currently have to iron up rough edges, and perhaps open up other limitation not needed by ink contracts but important to other smart contract runtime running on top of pallet-contracts.
For example contract-metadata currently don't support I256, U256 type which solang supports, which the contract-transcode will refuse to encode input for solang if those types are summoned.
effected use cases:
the developer experience of the following use cases will most likely be improved due to less hand-rolled setup code.
C.C @xermicus
The text was updated successfully, but these errors were encountered: