Understanding the App Layer

Last updated 1 month ago

Every address on a Cosmos chain has an Account.
The Bank module accounts for ownership of tokens in a key-value store, where the key is the address<>denom, and the value is the balance.
CosmWasm has a 2 step process:
1. "Store" - Code is "stored with an integer Code ID.
2. "Instantiate" - A Code ID is instantiated and each instance gets its own address.
As it has an address, the bank module can now account for funds help by a contract.
When a CosmWasm contract is executed, at the end of execution, it can emit SubMsgs which are basically the same as the contract signing and broadcasting those Msg types itself.

Cosmos chains have discrete Msg types. The only two on THORChain that a user is allowed to use are MsgSend and MsgDeposit. You use MsgSend for sending RUNE, and MsgDeposit to "do things". Those things are encoded in the memo, e.g. swap RUNE for BTC, bond RUNE to a node operator.
There are a bunch of other message types which only active node operators can call, e.g. MsgObservedTxIn, MsgObservedTxOut and MsgMimir.
When you install CosmWasm to a Cosmos chain, you can define "custom bindings", that you connect to Golang chain code for arbitrary execution (more info ). THORChain's CosmWasm does not have this.
In fact, THORChain has non-standard Staking, Distribution and Gov Msgs. The only variants of CosmosMsg that are valid are BankMsg, Any and Wasm.
The Any msg variant is key here. A CosmWasm contract can only interact with THORChain via Any, and it's subject to all the same rules that an EOA is subject to.

MsgDeposit has a fixed 0.02 RUNE fee.
Smart Contracts are called with MsgExecuteContract, which can have a wide range of gas usage based on the logic of the contract.
All Msg types share the same mempool. In our integration, any Msg type that is signed by an Active Node gets priority in the mempool. CosmWasm tx types are second class citizens in order to ensure that the core protocol continues to operate uninterrupted.
The price that is charged for the gas that someone requests for their tx is set by node mimir. it defaults to 0, and is an economic Mimir to update it (2/3+ consensus required).

The App Layer only uses Secured Assets (which itself is a fork of Trade Assets, but transferable). Users deposit L1 assets and mint Secured Assets 1:1.
Secured Assets are "optimistically secured" by THORChain validators (they are not inside the Incentive Pendulum). Secured Assets make TC nodes money from App Layer fees, this is how they pay for their security.
Secure+ memo deposit on an observed chain will mint a bank module token 1:1.
MsgDeposit with secure- will withdraw those tokens back to the layer 1.
As bank tokens, Secured Assets can be utilised in the App Layer, swapped across the Base Layer to another asset, or redeemed back to L1. The UX feels like depositing into an exchange, "doing things" then withdrawing.

If there is a bug in the App Layer, nodes can pause the entire layer, or specific contracts:
1. HALTWASMGLOBAL - full shutdown of whole App Layer.
2. HALTWASMCS-{checksum} - halt all contract instances of a specific checksum (i.e. code version).
3. HALTWASMCONTRACT-{contract last6} - halt an individual contract.
Considerations: Halting a contract that depends on an oracle price that moves during halt could cause issues. Apps such as these should be designed to protect against sudden price movements in some way.

Checksum ⇒ deploy_address must be registered in the THORNode codebase in order to permit code storage. This means that wasm code can be inspected, audited, and a reproducible checksum emitted by any 3rd party that wants to verify the permission.

Last updated 1 month ago

Every address on a Cosmos chain has an Account.
The Bank module accounts for ownership of tokens in a key-value store, where the key is the address<>denom, and the value is the balance.
CosmWasm has a 2 step process:
1. "Store" - Code is "stored with an integer Code ID.
2. "Instantiate" - A Code ID is instantiated and each instance gets its own address.
As it has an address, the bank module can now account for funds help by a contract.
When a CosmWasm contract is executed, at the end of execution, it can emit SubMsgs which are basically the same as the contract signing and broadcasting those Msg types itself.

Cosmos chains have discrete Msg types. The only two on THORChain that a user is allowed to use are MsgSend and MsgDeposit. You use MsgSend for sending RUNE, and MsgDeposit to "do things". Those things are encoded in the memo, e.g. swap RUNE for BTC, bond RUNE to a node operator.
There are a bunch of other message types which only active node operators can call, e.g. MsgObservedTxIn, MsgObservedTxOut and MsgMimir.
When you install CosmWasm to a Cosmos chain, you can define "custom bindings", that you connect to Golang chain code for arbitrary execution (more info ). THORChain's CosmWasm does not have this.
In fact, THORChain has non-standard Staking, Distribution and Gov Msgs. The only variants of CosmosMsg that are valid are BankMsg, Any and Wasm.
The Any msg variant is key here. A CosmWasm contract can only interact with THORChain via Any, and it's subject to all the same rules that an EOA is subject to.

MsgDeposit has a fixed 0.02 RUNE fee.
Smart Contracts are called with MsgExecuteContract, which can have a wide range of gas usage based on the logic of the contract.
All Msg types share the same mempool. In our integration, any Msg type that is signed by an Active Node gets priority in the mempool. CosmWasm tx types are second class citizens in order to ensure that the core protocol continues to operate uninterrupted.
The price that is charged for the gas that someone requests for their tx is set by node mimir. it defaults to 0, and is an economic Mimir to update it (2/3+ consensus required).

The App Layer only uses Secured Assets (which itself is a fork of Trade Assets, but transferable). Users deposit L1 assets and mint Secured Assets 1:1.
Secured Assets are "optimistically secured" by THORChain validators (they are not inside the Incentive Pendulum). Secured Assets make TC nodes money from App Layer fees, this is how they pay for their security.
Secure+ memo deposit on an observed chain will mint a bank module token 1:1.
MsgDeposit with secure- will withdraw those tokens back to the layer 1.
As bank tokens, Secured Assets can be utilised in the App Layer, swapped across the Base Layer to another asset, or redeemed back to L1. The UX feels like depositing into an exchange, "doing things" then withdrawing.

If there is a bug in the App Layer, nodes can pause the entire layer, or specific contracts:
1. HALTWASMGLOBAL - full shutdown of whole App Layer.
2. HALTWASMCS-{checksum} - halt all contract instances of a specific checksum (i.e. code version).
3. HALTWASMCONTRACT-{contract last6} - halt an individual contract.
Considerations: Halting a contract that depends on an oracle price that moves during halt could cause issues. Apps such as these should be designed to protect against sudden price movements in some way.

Checksum ⇒ deploy_address must be registered in the THORNode codebase in order to permit code storage. This means that wasm code can be inspected, audited, and a reproducible checksum emitted by any 3rd party that wants to verify the permission.