RFC - x/errors module

[spoo-bar]

Abstract

With custom modules like x/callback, x/cwfees and x/custodian, Archway has a big enough surface area where the protocol calls a smart contract. In case of any error, we need a way for the contract to learn that an error has occurred and to act on it, if it wishes. We propose the x/errors module which would be the error handling mechanism for the protocol to let the contract know of errors encountered.

Background

The following custom Archway modules invoke a contract execution at various times. In case, the execution call failed, currently there is no way to share this information with the contract or the og user.

x/callback - On error in callback execution, whether due to out-of-gas error or contract logic error, the only way the error is shared is via on-chain events. This would require an event monitoring system from the contract devs and is an off-chain way to notify error.

x/custodian - In case of IBC interactions, there are multiple ways an error can arise. Sending a tx with a msg which is invalid on the counterparty chain, packet timeout, msg processing logic error. Currently, there are multiple sudo endpoints exposed by the module to address these situations. The error endpoints are called when the relayer submits the packet and it ends up being the relayer who pays for the sudo execution.

For a contract relying on all these modules, the number of Sudo endpoints to support would be six in total. With the growth of protocol features over time, this might increase further. With error handling for every feature handled in a different way, it makes dapp dev more complex.

Proposal

We propose a new module x/errors which will be the error handling mechanism for the above mentioned modules. In case of any error from the x/callback or x/custodian, the errors will be forwarded to x/errors module where it can be shared with the contract.

message Error {
  // module_name is the module which encountered this error
  string module_name  = 1;
  //  error_code is any module specified error code which will help distinguish the error type 
  string error_code = 2;
  // contract_address is the address of the contract which caused the error 
  string contract_address = 3;
  // payload is the relevant payload input which lead to the error
  string payload = 4;
  // error_message is the actual error which needs to be shared with the contract. 
  // NOTE: This could be a json value. Where based on `error_code` the contract will know how to deserialize. Could involve details like block height, gas used or ibc packet seq id
  string error_message = 5;
}

There are two ways the errors can now be handled.

1. Pull Mechanism
   Store the error on-chain for x number of blocks.
   Allow a stargate query where the contract can fetch any errors relevant to it during that time. After the time has passed, the errors are purged from the state to not cause state bloat.
2. Push Mechanism
   This would involve creating another sudo endpoint, where as soon as an error is encountered, it is stored for the duration of the block. At the end of the block, the contract Sudo endpoint would be hit with the error details.

pub enum SudoMsg {
  Error {
    module_name: String,
    error_code: String,
    payload: String,
    error_message: String
  }
}

This does involve more complexity, so this invocation would have to be kept simple. Such as, very conservative gas limit for the invocation of this endpoint.
Any error from this Sudo execution would be ignored, to not perpetuate an error cycle.

👉🏻 Bit of both approach
Having the pull mechanism as the default allows us to use the push mechanism more explicitly. A contract can choose to sign up for the push mechanism of error handling, This could further be monetized as a subscription or pay-per-use if needed.

Consequences

Backwards Compatibility

This depends on the release of the dependent modules. If x/errors is to be released in a separate release, it would break backwards compatibility as the error handling for the x/custodian module has already been implemented in a different way.

Positive

• Future proofing against the growing codebase and having a dedicated error handling mechanism for sudo calls.
• Gives easier and higher control to the dapp devs on their usage of custom archway features by simplifying the archway-cw-sdk
• Potential source of protocol revenue

Negative

• Introduces a layer of complexity to the protocol architecture
• Would need to delay the current release timeline

Future ideas

Other potential features which could be part of the module in the future:

Group subscription

Subscribe to errors from other contracts
E.g a dapp/multisig consists of many contracts working together. One contract can chose to receive errors about all its dependent contracts in one place

Custom error subscription

Customize which error codes a contract wants a sudo call for, and which error codes its fine reading via stargate query.
E.g 1. a ica tx fail, the contract might wanna know immediately with a sudo call, but if its a cron job contract, it might not care much about x/callback fail as it will get called back again soon
E.g 2. A contract might want a custom error mechanism where it wants sudo call only if there are > n error in x blocks. etc

[zanicar]

This RFC has been promoted to an AIP (Archway Improvement Proposal)

archway-network/archway#544

[spoo-bar]

Shipped with Archway v7