deus-labs / cw-contracts Goto Github PK

It's more of a question than an issue.
Looks like there are couple of redundant/replacable utility funtions in tests which can be avoided using contract's QueryMsg

For example here: https://github.com/CosmWasm/cosmwasm-examples/blob/master/erc20/tests/integration.rs#L23-L63
and here,
https://github.com/CosmWasm/cosmwasm-examples/blob/master/erc20/src/tests.rs#L23-L63

I would like to know your views around this

• escrow
• erc20
• name-service
• simple-option
• voting

The idea is a simple demo contract, which can be used to help test https://github.com/confio/cosmwasm/issues/90 and CosmWasm/wasmd#16 as well as serve as a demo.

This contract is created with an owner, and has two actions:

• ReflectMsg will take a CosmosMsg as an argument, and if it was signed by the owner, it will re-dispatch the same message untouched. This let's the owner use the "mask" as his identity for anything - send tokens, stake, etc.
• ChangeOwner will take a HumanAddr as an argument. It must be signed by the current owner, and will update to a new owner.

This will let us easily test multiple scenarios in re-dispatching and handling "opaque messages". However, it is actually a useful functionality in some cases. Imagine "validator key rotation". If you create a validator with such a "mask contract" as the owner, you can swap out control of the mask without updating the validator struct at all. A mask could also own staked tokens, and you could make a trade of the mask against some liquid tokens if desired. (Since cosmos-sdk allows multiple messages in one tx, you can do it atomically by doing a multisig off-chain, then executing both transfers together)

When you query a name that does not exist, you get the error

GET https://lcd.demo-07.cosmwasm.com/wasm/contract/cosmos1vjecguu37pmd577339wrdp208ddzymkudc46zj/smart/7b227265736f6c76657265636f7264223a7b226e616d65223a2273696d6f6e227d7d?encoding=hex 500 (Internal Server Error)

Error: query wasm contract failed: cw_nameservice::state::NameRecord not found (HTTP 500)
at parseAxiosError (restclient.ts:232)
at async RestClient.get (restclient.ts:254)
at async RestClient.queryContractSmart (restclient.ts:409)

This is in any case not a server error (http 5xx). I also think a missing name should not be treated as an error. Instead, QueryMsg::ResolveRecord should have some kind of optional return type.

This is a port of CosmWasm/cw-template@04aeaf1 for both contracts.
Depends on #18

After #18, each contract consistently has cargo unit-test and cargo integration-test available, which shoul be called explicitely in CI.

• Update the contract to work well with the 0.6 cosmwasm release.
• Update tutorial to check out v0.5.2 tag

Right now QueryMsg is an enum with no cases. This results in a JSON schema which triggers a warning:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "QueryMsg",
  "enum": []
}

Array has too few items. Expected 1 or more.

When trying to create TS definitions, this leads to a crash:

SyntaxError: '=>' expected. (2:1)
  1 | export type QueryMsg = ()
> 2 | 
    | ^

We have a query for a similar contract: https://github.com/CosmWasm/cosmwasm/blob/v0.9.0/contracts/hackatom/src/contract.rs#L57-L59

This is defined in https://www.cosmwasm.com/docs/name-service/intro

We should code this, film the coding ideally, and then add it to the tutorial.

While trying to store the bytecode of the example contracts such as name-service , cw-to-do-list and other contracts ,
I'm getting an
Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: Error calling the VM: Error during static Wasm validation: Wasm contract requires unsupported import: "env.abort". Required imports: {"env.abort", "env.addr_canonicalize", "env.addr_humanize", "env.addr_validate", "env.db_next", "env.db_read", "env.db_remove", "env.db_scan", "env.db_write", "env.debug", ... 5 more}. Available imports: ["env.db_read", "env.db_write", "env.db_remove", "env.addr_validate", "env.addr_canonicalize", "env.addr_humanize", "env.secp256k1_verify", "env.secp256k1_recover_pubkey", "env.ed25519_verify", "env.ed25519_batch_verify", "env.debug", "env.query_chain", "env.db_scan", "env.db_next"].: create wasm contract failed: invalid request

The command used to store the bytecode is wasmd tx wasm store artifacts/cw_to_do_list.wasm --from main1 $TXFLAG -y -b block
cargo-version: 1.70.0 (ec8a8a0ca 2023-04-25)
rust version:1.70.0 (90c541806 2023-05-31)

For workshop, I need content that demonstrates submessages feature.

Two interacting contracts are required to demo this.
I am going to develop two projects: cw721-factory and cw721-sub.
cw721-factory is a contract that instantiates new NFT instances. On instantiate, cw721-sub will respond and send contract address using submessages

I was playing around, changing and compiling contracts, and then tried to build release artifacts manually using

docker run --rm -v "$(pwd)":/code \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.12.3 ./contracts/*/

from the "Release builds" part of the readme.
Then the following problem appeared:

...
Caused by:
  feature `edition2021` is required

  The package requires the Cargo feature called `edition2021`, but that feature is not stabilized in this version of Cargo (1.55.0 (32da73ab1 2021-08-23)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2021 for more information about the status of this feature.

The cargo version I am using is 1.66.0-nightly.
So I supposed that the problem may be in rust-optimizer. I found out there is a newer tag - v0.12.8

And so, running it with rust-optimizer:0.12.8 succeed.

After all this said, I think updating the readme with the latest version of rust-optimizer is a good idea!

I just saw that the binary representation of the fields in an escrow state is very long

{"verifier":[13,130,177,231,201,109,191,164,36,98,254,97,41,50,230,191,241,17,213,27],"beneficiary":[81,69,45,155,60,246,246,131,76,249,170,151,193,37,3,215,22,22,229,213],"funder":[13,130,177,231,201,109,191,164,36,98,254,97,41,50,230,191,241,17,213,27]}

If storage is the most expensive thing in the system, we should better use base64 here.

Creating this issue to keep track / coordinate example contracts migration to cosmwasm 0.12.

While performing a crev review for the cw-erc20 crate, I found the code for this contract to be clean, readable, and straightforward.

However, I was confused by the decimals constant state variable, which is initialized, but never used in the parse_u128() function for parsing amounts. My assumption is that the presence of decimals in the Constants struct is meant to allow for fixed point decimal math, but I can't see that implementation anywhere.

Is there supposed to be some handling of decimal math conversion in the parse_u128 implementation?

This is not needed anymore since cw-storage 0.2.0

https://github.com/InterWasm/cw-contracts/blob/main/contracts/simple-option/README.md

• Use rust-optimizer 0.10.0
• Push them to github on each tagged release.
• Use CosmWasm/cw-plus#29 as reference

Right now the dev build command does not work because simple option is missing integration tests:

$ ./.devtools/build_test_all.sh
…
   Compiling cosmwasm-storage v0.12.0-alpha3
   Compiling simple-option v0.8.0 (/.../cosmwasm-examples/simple-option)
    Finished release [optimized] target(s) in 1m 55s
error: no such subcommand: `integration-test`

Let's have an intagration test setup, even if there are no tests in it.

cw1-whitelist and cw1-subkeys provide superior implementations of this idea.

Before #69 there was a CosmosMsg::Opaque in reflect_multiple_messages. It was replaced with a bank send for simplicity and because the test is for multiple messages, not for special types. It would be nice to bring back a custom message using the new 0.8 interface.

confio/cosmwasm-opt:0.7.3 -> cosmwasm/rust-optimizer:0.8.0

   Compiling serde-json-wasm v0.1.1
   Compiling target-lexicon v0.8.1
   Compiling cosmwasm v0.5.1
   Compiling cw-escrow v0.1.0 (/root/project/escrow)
   Compiling wasmer-middleware-common v0.11.0
   Compiling wasmer-clif-fork-frontend v0.44.0
   Compiling cranelift-native v0.44.0
   Compiling wasmer-clif-fork-wasm v0.44.0
   Compiling wasmer-clif-backend v0.11.0
   Compiling wasmer-runtime v0.11.0
   Compiling cosmwasm-vm v0.5.1
error: couldn't read tests/../target/wasm32-unknown-unknown/release/escrow.wasm: No such file or directory (os error 2)
  --> tests/integration.rs:28:22
   |
28 | static WASM: &[u8] = include_bytes!("../target/wasm32-unknown-unknown/release/escrow.wasm");
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `cw-escrow`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Exited with code exit status 101

first seen in d1009ba

Let's try out to what it takes to guarantee we cover all branches in our tests.

@clevinson recommended https://github.com/xd009642/tarpaulin and docs look nice

• erc20 #68
• escrow #72
• mask #69
• nameservice #70

Background

In the official documentation it is considered that storing not canonical addresses (CanonicalAddr) in smart contract storage is not safe as address encoding could be changed and did-naming may appear.

Problem

The contracts do not follow the best practice and may be broken in the future. Inattentive developers that are looking for code samples may consider using Addr (or even String) type for storing addresses in storage as best practice, and that may lead to deploying insecure contracts.

Solution

Replace Addr and String a with CanonicalAddr in the contract storage.

Example of where the issue can be found

./contracts/escrow/src/state.rs - using Addr in storage
./contracts/cw-quadratic-funding/src/state.rs - using String in storage, however in ./contracts/cw-quadratic-funding/README.md#state it is stated that CanonicalAddr is used

Right now we cannot easily glob all contract dirs because they are all top level. For this reason I already renamed devtools to .devtools. We now have the issue again with anartifacts directory:

# Remove, otherwise treatet as a contract dir
rm -rf artifacts

docker run --rm -v "$(pwd)":/code \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.10.6 ./*/

To avoid the need for further hacks, let's

• Create ./contracts directory and move all contracts there
• Adapt globbing (cosmwasm/rust-optimizer:0.10.6 ./*/)
• Adapt scipts in .devtools
• Rename .devtools to devtools

Get some way to show all names that are claimed.

Simpler version of #84 (doesn't require secondary indexes)

See CosmWasm/cw-plus#48 for proposal of pagination design (let's pick one format)

Depends on #19 for publishing
Depends on https://github.com/confio/cosmwasm/issues/90 for testing

Produce a meaningful demo of cross-contract calls. Currently all examples of returning messages are the SendMsg to move native tokens. The simplest example is to combine the two existing contracts and make an erc20 workflow.

1. User grants allowance to escrow contract
2. User "tops us" escrow contract via call to escrow

• escrow contract then tries to move tokens from caller's account
• escrow contract keeps track of internal balance

3. On release/return escrow sends all erc20 tokens to proper destination

Note that as currently designed, you cannot call init on escrow with an erc20 value, as you have no address beforehand to properly set the allowance. We can specify the actors and the erc20 contract address in init, but adding tokens must be done by a new command.

Please follow the guidelines in Publishing.md from cosmwasm-templates (which was slightly updated with CosmWasm/cw-template#20)

• Modify crate name to cw-escrow
• Ensure all artifacts are committed
• Update Cargo.toml to have license and description
• Any other desired updates to *.md files
• Merge and tag release
• Publish to crates.io
• Add confio dev team as owner

This is the default README from cosmwasm-template.

Let's make proper info tied to escrow

This involves adjusting to all breaking changes. But also making use of enhancements, like Base64/Binary for better representation of binary data in json (see #39)

warning: package quote v1.0.2 in Cargo.lock is yanked in registry crates.io, consider updating to a version that is not yanked

https://crates.io/crates/quote/versions

There is an update here: https://github.com/dtolnay/quote/releases/tag/1.0.3

This requires secondary indices (see CosmWasm/cosmwasm#468)

• Upgrade Rust to 1.45.2 (in CI)
• Upgrade cosmwasm to 0.11 in erc20
• Upgrade cosmwasm to 0.11 in escrow
• Upgrade cosmwasm to 0.11 in mask (#98)
• Upgrade cosmwasm to 0.11 in nameservice (#97)
• Upgrade cosmwasm to 0.11 in simple-option (#95)
• Upgrade cosmwasm to 0.11 in voting (#96)

Blocked by pre-release of 0.11.

Like erc20 and many other ercs define interfaces for contracts, so that there can be many implementations and allow easier composition, it would be good to create some specs for cosmwasm. Especially if we later want to implement contracts in multiple languages, and connect over multiple blockchains.

This is a place to discuss these ideas.

I was thinking of CWC ("CosmWasm Contracts"), as a separate repo, that would define interfaces (json schemas or something more readable) along with business logic and purpose. At least a programable token base, as well as name service lookup are some generic components others would like to build on. Other ideas like "multisig" would also benefit from a standard interface to easy integration into frontend ui.

Feedback on the motivation? The location? The name?

See CosmWasm/cosmwasm#201 and CosmWasm/cosmwasm#210

Just one part of a bigger 0.8 upgrade change.

Important: handle params where sent_funds is empty (cosmwasm 0.4.2 fix)
Also update the tests to use new helpers
And any other enhancements in cosmwasm

All contracts are upgraded to 0.10.0

It may be used by cosmwasm-examples/mask but that should be removed anyway. It is deprecated by reflect in cosmwasm core for testing purposes and cw1-whitelist in cosmwasm-plus for production usages.

CosmWasm/cosmwasm#592 (comment)