webb-tools / protocol-cosmwasm

Webb Protocol Implementation in CosmWasm.

Webb Protocol CosmWasm

🕸️ Webb Protocol CosmWasm! ⧫
_{⚠️ Beta Software ⚠️}

Introduction

This repository contains the Cosmwasm implementation of Webb Protocol, which would be used for Cosmos SDK blockchains.

Contracts layout

contracts/
    |___anchor/                    # Anchor(FixedDepositAnchor) contract
    |___anchor-handler/            # Contract for executing the creation & modification of anchor  
    |___mixer/                     # Mixer contract  
    |___signature-bridge/          # Contract for managing voting, resource, and maintainer composition through signature verification    
    |___tokenwrapper/              # Contract for wrapping pooled assets and minting pool share tokens  
    |___tokenwrapper-handler/      # Contract for executing the creation & modification of token-wrapper  
    |___vanchor/                   # Variable Anchor contract  

Building the contracts(wasm)

Prerequisites

Install Rust & dependency

Install the latest version of Rust by following the instructions here.
Add the compilation target.

rustup default stable  
rustup target add wasm32-unknown-unknown

Building

To build the contract, run the following command.

cargo wasm

You can see the output wasm file in the target/wasm32-unknown-unknown/release directory.

For the optimization, run the following command.
Important: You will need docker installed to run this command.

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/workspace-optimizer:0.12.5

Then, you can see the output wasm file in the artifacts directory.

Testing

Run the following command to run the unit tests.

cargo test --release

License

^{Licensed under Apache License 2.0.}
_{Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the GPLV3 license, shall be licensed as above, without any additional terms or conditions.}

protocol-cosmwasm's Issues

[CHECKLIST] Implement Anchor contract

Overview

Implement the required functionality to build and test Anchor. You can utilize the:

• Substrate pallet implementation as an initial blueprint.
• Solidity smart contracts

Implementation

❗Note: Please add additional required fns as the implementation progresses and further investigation is conducted.

• #4
• #5
• #6
• #7
• #10

[PROTOCOL] How to get/set the `resource_id` in `protocol-cosmwasm`

@drewstone @shekohex
While implementing the integration tests for SignatureBridge contract of protocol-cosmwasm,
I found that the current Webb-proposal ResourceId cannot be directly used in tests.
According to the Webb-proposal ResourceId, the resource_id is combination of
target_contract_address(max 26 bytes), chain_type(2 bytes), and chain_id(4 bytes).

At the moment, the (local) juno network is used for tests. They use the contract address
of length 63 bytes("juno1" + 58 bytes address).
This bytes length difference causes the conflict & blocks the tests.
How can I overcome this issue & test the whole work flow of SignatureBridge in protocol-cosmwasm?

In addition, I done the research on address, account, pubkey of Cosmos-SDK blockchains.
Found that they use the 20 bytes pubkey for representing the account.
But, for human-readable address, they use the bech32 format.
Hence, normally the address is the combination of chain-prefix and 38 bytes string,
like cosmos1...., juno1.....
Surely, there is the special case like contract address(63 bytes total) in juno.

[TASK] Compute numerical chain_id (u32) for cosmos chains

[TASK] Adding `relayer` support for `protocol-cosmwasm`

Relevant issues:

• webb-tools/relayer#199
• webb-tools/relayer#186
• webb-tools/relayer#139

[CHECKLIST] Add (16, 2) and integrate 16-2 join/split tx

Overview

• [TASK] add (16, 2) to match statement in contracts/vanchor/src/contract.rs
• [TASK] Add 2 verifiers to the contract (small / large)
• [TASK] Generate trusted parameters for 16-2 join/split:
  - [ ] 2 vanchor bridge
  - [ ] 8 vanchor bridge
• [TASK] Add params to protocol-substrate-fixtures and include them in contracts/vanchor/
• [TASK] Add integration tests

Relevant Links

• Solidity implementation for vanchor_16
• Solidity implementation VAnchorVerifier.sol
• Solidity implementation _executeVerification

Interfaces

• IVAnchorVerifier.sol

Tests

• Solidity vanchor tests targeting 16_2
• Solidity vanchor bridge tests signatureVBridge.test.ts

[TASK] Update github workflows in CI

Overview

• Fix broken CI
• Ensure tests are run
• Add code coverage
• Cleanup unused commented out code

[TASK] Add "chain_id" as input param in Anchor contract

[TASK] Implement withdraw in Anchor contract

Overview

• Implement withdraw function for Anchor contract
• Add adequate test for withdraw functionality

[DISCUSSION] Customize the `Event` names in some contracts of `protocol-cosmwasm`

• Context

  While writing the smart contract with cosmwasm, the contract is able to outputs some information to off-chain.
  For example:

   Response::new()
        .add_attribute("action", "send")
        .add_attribute("from", &info.sender)
        .add_attribute("to", &contract)
        .add_attribute("amount", amount)
  

  The above response outputs the following event to tendermint(consensus & networking engine for Cosmos-SDK).

   Event { 
       type_str: "wasm", 
       attributes: [
           Tag { key: Key("_contract_address"), value: Value("juno15...") }, 
           Tag { key: Key("action"), value: Value("send") }, 
           Tag { key: Key("from"), value: Value("juno1w...") }, 
           Tag { key: Key("to"), value: Value("juno1v...") }, 
           Tag { key: Key("amount"), value: Value("690000000") }
        ] 
     }, 
  

  But, cosmwasm provides another way of presenting event.
  For example:

  Response::new()
        .add_event(
            Event::new("webb-anchor-deposit")
               .add_attribute("action", "deposit")
               .add_attribute("from", &info.sender)
               .add_attribute("to", &contract)
               .add_attribute("amount", amount)
            )
        )
  

   Event { 
       type_str: "wasm-webb-anchor-deposit", 
       attributes: [
           Tag { key: Key("_contract_address"), value: Value("juno15...") }, 
           Tag { key: Key("action"), value: Value("deposit") }, 
           Tag { key: Key("from"), value: Value("juno1w...") }, 
           Tag { key: Key("to"), value: Value("juno1v...") }, 
           Tag { key: Key("amount"), value: Value("690000000") }
        ] 
     }, 
  

  Simply, we can provide more meaningful key to the Event, which would be beneficial for implementing the
  events_watcher for protocol-cosmwasm.

• Suggestion

  I think it is better to customize(rename) the Event names in some contracts of protocol-cosmwasm.
  The affected contracts would be anchor, vanchor & mixer contracts.
  The pattern of customized Event name(key) would be like:

     webb-[contract_name]-[action]
  

  For example: "webb-anchor-deposit", "webb-vanchor-edge_update", "webb-vanchor-edge_add"
  The detail(Event attributes) would follow the sample from protocol-solidity & protocol-substrate.

[TASK] add the max_edges to the verifiers and instantiate the correct verifiers for them

Overview

• add the max_edges to the verifiers
• instantiate the correct verifiers for them
• ensure that we throw an error if we select wrong max edges for unsupported parameters

[SPEC] Investigate approach to integrate cosmwasm into relayer

[SPEC] Proposals and their Contracts on Cosmwasm/Cosmos-SDK chains

Proposals

Types

• resourceId - 32 byte string containing the target execution contract address(hashed) and the chain id type
  • Last 6 bytes reserved for chain id type (2 bytes chain type + 4 bytes chain identifier)
  • Last adjacent 20 bytes for target execution contract address(hashed)
• functionSig - 4 byte function signature taken to be the 0x00000000

More on resourceId

resourceId serves the purpose of representing the target chain contract.
In cosmwasm/cosmos-sdk chains, the contract address is normally 63 ~ 65 bytes string.
So, here we introduce extra tweak to contract address to make it fit into resourceId(32 bytes string).
The tweak is to keccak256(contract_address) & take last 20 bytes.
These last 20 bytes becomes the target execution contract address(hashed) in the resourceId.
Finally, the resourceId is created by concatenating the following parts:
6 zeroes(6 bytes) + target contract(20 bytes) + chainIdType(6 bytes)
(Ref: #55 (comment))

More on chain_id

chain_id serves the purpose of representing the blockchain network.
In cosmwasm/cosmos-sdk chains, the chain_id is string, unlike the evm chains(number)
For example, the chain_id for juno mainnet is juno-1.
So, here we introduce extra tweak to chain_id to make it(string) to 4 bytes number.
The tweak is to keccak256(chain_id(string)) & take last 4 bytes.
These last 4 bytes becomes the chain_id in proposals.
(Ref: #39 (comment))

More on functionSig

functionSig comes from the evm proposal, since evm chain contracts make use of it.
However, in cosmwasm, functionSig is not needed, since cosmwasm leaves only one execute entry & does multiplexing the input message for different action.
So, here we just fill the 0 in the place of functionSig(0x00000000) for compatibility with other webb proposals.

Overarching schema

(bytes32 resourceId, bytes4 functionSig(zeroes), bytes4 proposalNonce, message(the length of this is proposal specific))

Terminology: We will call the (resourceId, zeroes, nonce) as the proposal header. The proposal header is a total of 40 bytes.

Example proposals

1. resourceId Proposal
Contract Flow: Bridge/SignatureBridge -> AnchorHandler/TokenWrapperHandler implementation (specifically goes to setResource within AnchorHandler/TokenWrapperHandler)
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

2. Anchor Update Proposal
Contract Flow: Bridge/SignatureBridge -> AnchorHandler -> Anchor
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

3. Set/Change Wrapping Fee(fee_percentage) Proposal
Contract Flow: Bridge/SignatureBridge -> TokenWrapperHandler -> GovernedTokenWrapper
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

4. Add Token Proposal
Contract Flow: Bridge/SignatureBridge -> TokenWrapperHandler -> GovernedTokenWrapper
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

5. Remove Token Proposal
Contract Flow: Bridge/SignatureBridge -> TokenWrapperHandler -> GovernedTokenWrapper
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

6. Set/Update Fee Recipient Proposal
Contract Flow: Bridge/SignatureBridge -> TokenWrapperHandler -> GovernedTokenWrapper
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

7. MaxDepositLimit Update Proposal
Contract Flow: Bridge/SignatureBridge -> AnchorHandler -> VAnchor
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

8. MinWithdrawalLimit Update Proposal
Contract Flow: Bridge/SignatureBridge -> AnchorHandler -> VAnchor
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

9. Rescue Tokens Proposal
Contract Flow: Bridge/SignatureBridge -> TreasuryHandler -> Treasury
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

10. Set TreasuryHandler Proposal
Contract Flow: Bridge/SignatureBridge -> TreasuryHandler -> Treasury
Proposal Data: (resourceId, functionSig, nonce, message)
Total Bytes: 32 + 4 + 4 + size of message

Questions/Issues

1. Unlike other proposals(evm or substrate), these proposals include variant-length data.
   The variant-length is mainly because of different length of address in different cosmwasm/cosmos-sdk chains.
   For example, in juno chain, the length of contract address is 63 bytes string

juno16j49kxsffgpg38l3mha4uets7clpvntf4zrnkeuegqtz0w8xq62sw4lrvj

In terra2.0 chain, the length is 64 bytes string

terra1vknprjncslpeuwhktut96amps4t82vrrrf8ggwgq5nyfqzujcwzsxmv2xp

Is it okay to use these variant-length proposal? or should go to fixed-length proposal with padding?

2. Another variant-length data comes from the Uint128 data type, much used in cosmwasm contracts.
   Uint128 type is serialize/deserialized in String type, and its maximum length is 39 bytes.
   How should we handle this type? keeping variant-length data? or should go to fixed-length(39 bytes) data

3. MaxExtLimitUpdate & MaxFeeLimitUpdate proposals seem to be needless.
   What is the reason for that?

4. For every Uint128(u128) type, the current proposals use the 16 bytes.
   So, we should add more utils to support the conversion between raw bytes and Uint128(or u128(or String)).

5. The feeRecipient proposal has one tiny issue. Since the feeRecipient could be either contract address(63 ~ 65
   bytes) or wallet address(43 ~ 45bytes), we could think of padding the address to fit it into longest length(63 ~ 65).
   So, as well as resourceId approach, apply left-zero-padding so that max length is 65 bytes?
   For example,

     juno16g2rahf5846rxzp3fwlswy08fz8ccuwk03k57y (43 bytes)

becomes

     0000000000000000000000juno16g2rahf5846rxzp3fwlswy08fz8ccuwk03k57y (65 bytes = 12 bytes + 43 bytes)

NOTE

In every proposal, there is sig, which is the signature of governor on the proposal data.
This signature is used for verifying if the caller of SignatureBridge contact is the real governor.

[SPEC] Investigate differences between ibc-enabled and non-enabled chains

Overview

It would be beneficial to understand implementation differences and changes we must consider between ibc-enabled chain and non-ibc enabled chains.

[CHECKLIST] Implement vAnchor contract

Overview

Implement the required functionality to build and test vAnchor contract. You can utilize the pallet implementation as an initial blueprint.

Implementation

❗Note: Please add additional required fns as the implementation progresses and further investigation is conducted.

• #8
• [ ]

[TASK] Update integration tests to use another devnet

[CHECKLIST] Implement Mixer contract

Overview

Implement the required functionality to build and test the Mixer. You can utilize the anchor contracts / mixer pallets for guidance.

• Substrate pallet implementation as an initial blueprint.
• Solidity smart contracts

Implementation

❗Note: Please add additional required fns as the implementation progresses and further investigation is conducted.

• #9
• [ ]

[TASK] Implement linkable tree

Overview

• Implement linkable tree, see protcol-solidity for blue print
• Add tests for linking between anchors

[TASK] Test cross-anchor withdraw

[TASK] Test same-anchor withdraw

[TASK] Implement deposit in Anchor contract

Overview

• Implement deposit function for Anchor contract
• Add adequate test for deposit functionality

[IMPL-ISSUE] Uncertainty of `nonce` increase in `protocol-solidity`

@drewstone @shekohex @nepoche
In the current (v)anchor impl of protocol-cosmwasm, it just followed the code of protocol-solidity.
anchor implementation in cosmwasm
vanchor implementation in cosmwasm

AnchorBase in solidity

The issue is that the solidity version uses 1048 as kind of increment of proposal_nonce.
Can you provide the explanation for this number?

[TASK] Update cosmwasm to 1.0.0 rc1

Overview

• update cosmwasm to latest version

[TASK] Add events for all functions on the mixer (Deposit / Withdraw / Insert)

Deliverable

• Add events for all functions
• Specify how relayer may listen for events

[TASK] Implement transact in vAnchor contract

Overview

• Implement transact function for Anchor contract
• Add adequate test for transact functionality