Add basic deployment flows

[ismellike]

Closes #69

New CLI config

#[derive(Debug, Subcommand)]
pub enum Command {
    /// Staking related commands
    Staking(StakingArgs),
    /// AVS deployment
    Avs(AvsArgs),
    /// Operator management
    Operator(OperatorArgs),
}

Example avs json config

{
    "name": "Squaring AVS",
    "fan_in": {
        "reference_denom": {
            "denom": "uslay"
        },
        "secondary_denoms": [
            {
                "denom": "cw20:layer16averdvvj9xxv5znx6w4fmatafjq3f0n2l8tf6al7r6v5ycaqunql4n0ug",
                "weight": "0.5",
                "max_cap": "1.5"
            }
        ]
    },
    "delegations": {
        "delegation_limit": 16
    },
    "operators": {
        "can_update_operators": true
    }
}

A full AVS flow for 1 reference token and 1 cw20 secondary will generate:

{
  "slay3r": {
    "slay3r-local": {
      "code_ids": {
        "cw20_base": 13,
        "cw20_base_ROCKS": 13,
        "rstk_delegations": 15,
        "rstk_delegations_Squaring AVS": 15,
        "rstk_fan_in": 14,
        "rstk_fan_in_Squaring AVS": 14,
        "rstk_fan_out": 12,
        "rstk_fan_out_cw20:layer1y9euzva5zsg8k6l9kzdeyj64gxpdejw2cfmmsm9md5jugwj8hhlsfcwfnf": 12,
        "rstk_fan_out_uslay": 12,
        "rstk_operators": 16,
        "rstk_operators_Squaring AVS": 16,
        "rstk_token_staking": 11,
        "rstk_token_staking_cw20:layer1y9euzva5zsg8k6l9kzdeyj64gxpdejw2cfmmsm9md5jugwj8hhlsfcwfnf": 11,
        "rstk_token_staking_uslay": 11,
        "rstk_token_weighting": 17,
        "rstk_token_weighting_Squaring AVS": 17
      },
      "default": {
        "cw20_base_ROCKS": "layer1y9euzva5zsg8k6l9kzdeyj64gxpdejw2cfmmsm9md5jugwj8hhlsfcwfnf",
        "rstk_delegations_Squaring AVS": "layer1nlax07f2stkferemjdxm7r603aj8guzeftup4cltdxr4p45tskks8vqlqp",
        "rstk_fan_in_Squaring AVS": "layer1avp6ks3uwhj9xjeppw3w6r3f6gtzcnzy2w53ttweupzjsntt4xhs5eav3a",
        "rstk_fan_out_cw20:layer1y9euzva5zsg8k6l9kzdeyj64gxpdejw2cfmmsm9md5jugwj8hhlsfcwfnf": "layer1fjmac46wxl0v829tnee6zt6jm2d578m0frj3cp73r4nk5ngfl64srwl69v",
        "rstk_fan_out_uslay": "layer1pylwkt0kzds5cd9pl7ch3l5yr3672gzuzede9gags8kxyuxqj4psxxeq2q",
        "rstk_operators_Squaring AVS": "layer1mfqrh2lvccnwyrhujlx48q6gynm5zx9mw92x84ryc38ud0kefvds82ckav",
        "rstk_token_staking_cw20:layer1y9euzva5zsg8k6l9kzdeyj64gxpdejw2cfmmsm9md5jugwj8hhlsfcwfnf": "layer1ugr4j3g7a9gjcf0xguj4pnal6g2fjd4895yrt7856jqjhyr80xeqqht482",
        "rstk_token_staking_uslay": "layer18arpcdc9af4a5aej9x7nk78pw8vrjfzglcxgul7d3myrna9r6zasg4eg6e",
        "rstk_token_weighting_Squaring AVS": "layer1809h7c4hw5jqkzmlsap38ed2n6vgv7wslmuh7maqe9v0sstvl69q8449ma"
      }
    }
  }
}

TODO:

• Tests
• Docs
• In-code todo's
• Review on implementation
• Stake action
  • Test cw20 actions
• View contracts action

[ismellike]

Thoughts @noahsaso ?

[ethanfrey]

I have not looked at the code yet, but giving first comments based on the description:

It seems like duplicate code_ids here. but maybe this is just how cw-orch works:

• cw20_base and cw20_base_ROCKS (only the second is instantiated)
• rstk_fan_out_uslay and rstk_fan_out_cw20:layer1l5a9976pkv3pruyj079pekkyz6dz58k386uukz5wdk6yqwt2lxjs374u2t need different contracts. But the same code_id, right?
• same with rstk_token_staking_*

I like the JSON config file for avs setup - this really is too much for CLI args: cargo run --bin restaking -- avs deploy --config ./avs-configs/example-avs.json

In general, it looks like this fufills the requirements. I will dig into the code soon, but curious about the repeated code_ids.

[ismellike]

It seems like duplicate code_ids here. but maybe this is just how cw-orch works:

• cw20_base and cw20_base_ROCKS (only the second is instantiated)
• rstk_fan_out_uslay and rstk_fan_out_cw20:layer1l5a9976pkv3pruyj079pekkyz6dz58k386uukz5wdk6yqwt2lxjs374u2t need different contracts. But the same code_id, right?
• same with rstk_token_staking_*

Yep, cw-orch loads information by ID. We use the default id ("cw20_base", "rstk_fan_out", "rstk_token_staking") to upload the wasm. When we want to instantiate, we provide a more specific contract id and just load up the already uploaded code id.

[ismellike]

Still cannot stake with cw20 on slay3r-local even though it's a valid cw20 contract. I validated this by querying balance before hitting the stake action. (not seen in SS btw)

RUST_BACKTRACE=1

[ismellike]

backtrace

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
             at /home/ismellike/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.83/src/backtrace.rs:27:14
   1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/result.rs:1987:27
   2: restaking::handle_staking
             at ./src/bin/restaking.rs:207:13
   3: restaking::main
             at ./src/bin/restaking.rs:150:35
   4: core::ops::function::FnOnce::call_once
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:250:5
   5: std::sys::backtrace::__rust_begin_short_backtrace
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/sys/backtrace.rs:154:18
   6: std::rt::lang_start::{{closure}}
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:164:18
   7: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:284:13
   8: std::panicking::try::do_call
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:554:40
   9: std::panicking::try
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:518:19
  10: std::panic::catch_unwind
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panic.rs:345:14
  11: std::rt::lang_start_internal::{{closure}}
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:143:48
  12: std::panicking::try::do_call
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:554:40
  13: std::panicking::try
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:518:19
  14: std::panic::catch_unwind
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panic.rs:345:14
  15: std::rt::lang_start_internal
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:143:20
  16: std::rt::lang_start
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:163:17
  17: main
  18: <unknown>
  19: __libc_start_main
  20: _start

[ethanfrey]

It would help if you include the command that you ran that caused the error.

I just tried cd deploy && cargo test which runs golem tests, and it works fine. Well, it had errors due to old wasm contracts, but then after ./scripts/collect_wasm.sh it worked well.

[ethanfrey]

Okay, I went through the README.md and hit that error message upon cargo run --bin restaking -- staking stake --denom ROCKS --amount 100 --is-cw20

I cannot find better stack traces. However, I did look at http://localhost:8080/ and searched for sm.query_simulate which is executed when we try to estimate gas for a transaction (if it fails, we never even get to check_tx) as well as abci_check_tx, which would be triggered upon submitting a transaction if

I see a number of results, but I waited a few minutes and kept trying to run that command above:
cargo run --bin restaking -- staking stake --denom ROCKS --amount 100 --is-cw20

It kept erroring, but nothing was written to the chain. This makes me think it is somewhere inside the cw-orch logic.

[ismellike]

I found the issue after using some lower level cw-orch API

            let rt = tokio::runtime::Runtime::new().unwrap();
            let _ = rt.block_on(chain.daemon.sender.commit_tx(
                vec![MsgExecuteContract {
                    sender: chain.sender().to_string().parse().unwrap(),
                    contract: staking_provider.staking.addr_str()?.parse().unwrap(),
                    msg: to_json_binary(&rstk_token_staking::msg::ExecuteMsg::Custom(
                        rstk_token_staking::msg::TokenStakingExecuteMsg::Stake {},
                    ))?
                    .to_vec(),
                    funds: vec![cosmrs::Coin {
                        denom: denom.parse().unwrap(),
                        amount,
                    }],
                }],
                None,
            ));

I think the issue is coming from cw-orch's internal usage of cosmrs Denom not allowing a colon to be parsed:

impl FromStr for Denom {
    type Err = ErrorReport;

    fn from_str(s: &str) -> Result<Self> {
        // TODO(tarcieri): ensure this is the proper validation for a denom name
        if s.chars()
            .all(|c| matches!(c, 'A'..='Z' | 'a'..='z' | '0'..='9' | '/'))
        {
            Ok(Denom(s.to_owned()))
        } else {
            Err(Error::Denom { name: s.to_owned() }.into())
        }
    }
}

There is a commit_tx_any which might be able to bypass this.

[ismellike]

LFG

[ueco-jb]

Good work and I really like the documentation. Few nitpicks and questions.

[ethanfrey]

Good stuff.

If it passes @ueco-jb review, I'm good with it.
Let's merge