Design Question

[baoskee]

Larry, why can't the CW code be like this for key rotation? Why require a change to the CosmosSDK?

pub fn execute(
  deps: DepsMut,
  env: Env,
  info: MessageInfo,
  msg: ExecuteMsg,
) -> Result<Response, ContractError> {
  match msg {
    ExecuteMsg::ExecuteMsgs { msgs } => {
       let owner = OWNER.load(deps.storage)?;
       if owner != info.sender {
         return Err(ContractError::Unauthorized {});
       }
       Ok(Response::new().add_messages(msgs))
    },
    ExecuteMsg::UpdateOwner { new_addr } => {
      let addr = deps.api.addr_validate(new_addr)?;
      let owner = OWNER.load(deps.storage)?;
      if owner != info.sender {
        return Err(ContractError::Unauthorized {});
      }
      OWNER.save(deps.storage, &addr)?;
      Ok(Response::new())
    }
  } 
}

[larry0x]

With this design, the contract is just a proxy - it cannot initiate txs on its own. The owner account is the one who initiates txs. Two main problems if we do it this way:

• What type of account will owner be? Without changes to the sdk, it has to be an EOA because only EOA can initiate txs. The EOA will remain as a single point of failure of the system. We still haven't solved the poor security property of EOA.

• How will gas fee work? Since it's owner who initiates the tx, it will pay the gas fee, but instead we want the smart contract account to pay it.

I think the only way to solve both problems is to actually let smart contract initiate txs, so that no EOA is involved at all.

[baoskee]

Gotcha. What if we delegate certain types of messages to other smart contracts to execute? For example, using DaoDao's Core module pattern.

Only allowed modules can execute messages. These modules can allow non-owner to execute. For example, for a subscription payments system you would add a "Subscriptions Module" that allows payment vendor to execute a withdraw message every month.

The payment vendor would pay the gas in this example. And we don't need changes to the CosmosSDK in this case.

• What type of account will owner be? Without changes to the sdk, it has to be an EOA because only EOA can initiate txs. The EOA will remain as a single point of failure of the system. We still haven't solved the poor security property of EOA.

owner can just be another smart contract, no? Addresses can be EOA or a smart contract. You can compose really nicely this way.

[larry0x]

owner can just be another smart contract, no?

If owner is also a SC, how will you invoke the owner contract? You always need an EOA to sign a MsgExecuteContract

[larry0x]

Btw @baoskee I'm happy to do a call to discuss anything about AA. Doing this asynchronously on Github isn't the most efficient

[baoskee]

Yea would love a call. I'll DM you on Telegram.