​
操作​

操作是以太坊虚拟机（EVM）的基础组成部分，使智能合约逻辑得以执行。当开发者构建智能合约时，使用 Solidity 或 Vyper 编写的代码并不能被 EVM 直接解释。在能够于区块链中执行之前，合约必须先通过某种可用编译器进行编译，例如 solc。编译会将人类可读的合约代码转换为一系列虚拟机可解释并执行的操作，从而完成状态转换或查询最新已提交的状态。这些操作被称为 操作码，并包含在一种称为 跳转表 的结构中。 每个操作码都通过以下内容来定义：调用它时需要执行的逻辑、它与内存的关系，以及与之关联的 gas 成本。更具体地说，一个操作码由以下部分完整定义：
  • SetExecute：更新该操作码的执行逻辑。
  • SetConstantGas：更新常量 gas 成本所使用的值。
  • SetDynamicGas：更新用于计算动态 gas 成本的函数。
  • SetMinStack：更新执行该操作所需的最小栈项数量。
  • SetMaxStack：更新执行该操作后栈中允许存在的最大项数量。
  • SetMemorySize：操作所需的内存大小。
在 Cosmos EVM 框架中，开发者可以修改上述任意属性。

​
改进提案​

改进提案是 Cosmos EVM 和 Ethereum 用来修改操作码行为的方式。它由一个函数和一个名称组成；该函数可以访问跳转表，并对操作行为施加特定修改。 在 Ethereum 的语境中，这些协议变更被称为 Ethereum Improvement Proposals（EIPs），并通过唯一 ID 标识。例如，EIP-1559 用于引入基础费。 为了让任何 Cosmos EVM 用户都能定义自己的特定改进，并避免与 Cosmos EVM 和 Ethereum 现有提案重叠，每个提案都由一个字符串标识，该字符串由链名和一个数字组成。例如，默认的 Cosmos EVM 改进使用字符串 evmos_XXXX。这样每条链都可以定义自己的改进，而无需担心不同链之间当前或未来的 ID 冲突。此外，从 0 开始编号更适合链开发者，也便于更清晰地了解各条链的历史演进。 下面是一个示例，展示 Cosmos EVM 链如何使用这一能力来修改 CREATE 和 CREATE2 操作码的行为。首先，需要定义修改函数： 
// Enable0000 contains the logic to modify the CREATE and CREATE2 opcodes// constant gas value.func Enable0000(jt *vm.JumpTable) {    multiplier := 10    currentValCreate := jt[vm.CREATE].GetConstantGas()    jt[vm.CREATE].SetConstantGas(currentValCreate * multiplier)    currentValCreate2 := jt[vm.CREATE2].GetConstantGas()    jt[vm.CREATE2].SetConstantGas(currentValCreate2 * multiplier)}
然后，需要通过自定义激活器将该函数与一个名称关联起来： 
cosmosEVMActivators = map[string]func(*vm.JumpTable){    "evmos_0": eips.Enable0000,}

​
改进提案的激活​

由于用户与协议的交互方式会持续变化，同时为了在自定义虚拟机行为的自由度之外引入一层安全保障，自定义改进提案默认不会启用。所选改进提案的激活由 EVM 模块参数 控制。引入所需参数变更有两种方式：
  1. 升级：创建协议升级处理器，将提案名称加入激活列表。
  2. 治理：创建治理提案，将某个改进提案添加到 EVM 模块参数中。
这种方式让开发者能够对安全问题或市场状况作出响应，同时让链上参与者持续知情并参与其中。

​
Operations​

Operations are the base components of the Ethereum Virtual Machine (EVM) which allow the execution of the smart contract logic. When a developer builds a smart contract, the code written in Solidity, or Vyper, is not directly interpretable by the EVM. Before being able to execute the code in the blockchain, the contract has to be compiled via one of the available compilers, like solc. The compilation converts the human-readable contract code into a sequence of operations that the virtual machine can interpret and execute to perform state transitions or query the latest committed state. These operations are called opcodes, and are contained in a structure called jump table. Each opcode is defined by specifying the logic that has to be executed when it is called inside the EVM, its relationship with the memory, and the gas cost associated with it. More specifically, an opcode is completely defined by:
  • SetExecute: update the execution logic for the opcode.
  • SetConstantGas: update the value used for the constant gas cost.
  • SetDynamicGas: update the function used to compute the dynamic gas cost.
  • SetMinStack: update the minimum number of items in the stack required to execute the operation.
  • SetMaxStack: update the maximum number of items that will be in the stack after executing the operation.
  • SetMemorySize: the memory size required by the operation.
Within the Cosmos EVM framework, developers can modify any of the previous properties.

​
Improvement Proposals​

Improvement proposals are the approach used by Cosmos EVM and Ethereum to modify the behavior of opcodes. They are composed of a function, which has access to the jump table to apply specific changes to operation behavior, and a name. In the context of Ethereum, these protocol changes are named Ethereum Improvement Proposals (EIPs) and are identified by a unique ID. For example, EIP-1559 is used to introduce the base fee. To allow any Cosmos EVM user to define their own specific improvements without overlapping with Cosmos EVM and Ethereum ones, each proposal is identified by a string, that is composed of the chain name and a number. For example, default Cosmos EVM improvements are associated with the string evmos_XXXX. This allows each chain to define their improvements without having to worry about existing or future ID clashes between different chains. Additionally, the ability to start enumeration at 0 is better for chain developers and allows having a better overview of the historical progress for each chain. Below, you will find an example of how the Cosmos EVM chain uses this functionality to modify the behavior of the CREATE and CREATE2 opcodes. First, the modifier function has to be defined: 
// Enable0000 contains the logic to modify the CREATE and CREATE2 opcodes// constant gas value.func Enable0000(jt *vm.JumpTable) {    multiplier := 10    currentValCreate := jt[vm.CREATE].GetConstantGas()    jt[vm.CREATE].SetConstantGas(currentValCreate * multiplier)    currentValCreate2 := jt[vm.CREATE2].GetConstantGas()    jt[vm.CREATE2].SetConstantGas(currentValCreate2 * multiplier)}
Then, the function as to be associated with a name via a custom activator: 
cosmosEVMActivators = map[string]func(*vm.JumpTable){    "evmos_0": eips.Enable0000,}

​
Activation of Improvement Proposals​

Due to continuous changes in the users’ interaction with the protocol, and to introduce a safety measure along with the freedom to customize the virtual machine behavior, custom improvement proposals are not active by default. The activation of selected improvement proposals is controlled by the EVM module’s parameters. There are two ways of introducing the required parameter changes:
  1. Upgrade: create a protocol upgrade handler which introduces the proposal name in the active list.
  2. Governance: create governance proposal to add an improvement proposal to the EVM module parameters.
This approach gives developers the ability to react to security issues or market conditions, while keeping the chain’s participants in the loop.