|
| 1 | +# Custom Improvement Proposals |
| 2 | + |
| 3 | +With the release [v19.0.0](https://github.com/evmos/evmos/releases/tag/v19.0.0) |
| 4 | +a new feature called custom improvement proposal has been introduced in the |
| 5 | +evmOS framework. Custom improvement proposals allow protocol developers to |
| 6 | +modify the behavior of the EVM opcodes to tailor their functionalities to the |
| 7 | +specific needs. |
| 8 | + |
| 9 | +## Improvement Proposals |
| 10 | + |
| 11 | +Improvement proposals are a way to introduce new standards aimed to improve |
| 12 | +protocol functionalities. Changes proposed in this way can affect any aspect |
| 13 | +of protocol functionalities but are mainly used to customize the behavior of |
| 14 | +smart contract execution. |
| 15 | + |
| 16 | +## Operations |
| 17 | + |
| 18 | +Operations are the base components of the Ethereum Virtual Machine (EVM) which |
| 19 | +allows the execution of the smart contract logic. When a developer build a smart |
| 20 | +contract, the code written in Solidity, or Viper, is not directly interpretable |
| 21 | +by the EVM. Before being able to execute the code in the blockchain, the |
| 22 | +contract has to be compiled via one of the available compilers, like `solc`. The |
| 23 | +step of the compilation convert the contract, written in a human readable |
| 24 | +language, into a sequence of operations that the virtual machine can interpret |
| 25 | +and execute to perform state transition or query the latest committed state. |
| 26 | +These operations are called, in the EVM context, **opcodes** and are contained |
| 27 | +in a structure called **jump table**. |
| 28 | + |
| 29 | +Some example of operations are the addition, defined by the opcode `ADD`, and |
| 30 | +the subtraction, defined by the opcode `SUB`. |
| 31 | + |
| 32 | +Each opcode is defined by specifying the logic that has to be executed when it |
| 33 | +is called inside the EVM, its relationship with the memory, and the gas cost |
| 34 | +associated with it. More specifically, an opcodes is completely defined by: |
| 35 | + |
| 36 | +- `SetExecute`: update the execution logic for the opcode. |
| 37 | + |
| 38 | +- `SetConstantGas`: update the value used for the constant gas cost. |
| 39 | + |
| 40 | +- `SetDynamicGas`: update the function used to compute the dynamic gas cost. |
| 41 | + |
| 42 | +- `SetMinStack`: update the minimum number of items in the stack required to |
| 43 | +execute the `operation`. |
| 44 | + |
| 45 | +- `SetMaxStack`: update the maximum number of items that will be in the stack |
| 46 | +after executing the `operation`. |
| 47 | + |
| 48 | +- `SetMemorySize`: the memory size required by the `operation`. |
| 49 | + |
| 50 | +Within evmOS framework, developer can modify any of the previous properties. |
| 51 | + |
| 52 | +## Improvement Proposals |
| 53 | + |
| 54 | +Improvement proposal are the approach used by evmOS and Ethereum to modify the |
| 55 | +the behavior of opcodes. They are composed by a function, which have the access |
| 56 | +to the jump table to apply specific changes to operations behavior, and a name. |
| 57 | + |
| 58 | +In the context of Ethereum, these protocol changes are |
| 59 | +named Ethereum Improvement Proposals (EIPs) and are associated to a numerical |
| 60 | +name. For example, the [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) is |
| 61 | +used to introduce the base fee. |
| 62 | + |
| 63 | +To allow any evmOS user to define their specific |
| 64 | +improvements without overlapping with evmOS and Ethereum default ones, each |
| 65 | +proposal is identified by a string composed by the chain name and a number. For |
| 66 | +example, default evmOS improvements are associated with the string `evmos_XXXX`. |
| 67 | +In this way, every chain can define their improvement without the risk of |
| 68 | +overwriting already present functions and is free to start the numeration from |
| 69 | +0. |
| 70 | + |
| 71 | +Below an example of how Evmos chain uses this functionalities to modify the |
| 72 | +behavior of the `CREATE` and `CREATE2` opcodes. First the modifier function has |
| 73 | +to be defined: |
| 74 | + |
| 75 | +```go |
| 76 | +// Enable0000 contains the logic to modify the CREATE and CREATE2 opcodes |
| 77 | +// constant gas value. |
| 78 | +func Enable0000(jt *vm.JumpTable) { |
| 79 | + multiplier := 10 |
| 80 | + |
| 81 | + currentValCreate := jt[vm.CREATE].GetConstantGas() |
| 82 | + jt[vm.CREATE].SetConstantGas(currentValCreate * multiplier) |
| 83 | + |
| 84 | + currentValCreate2 := jt[vm.CREATE2].GetConstantGas() |
| 85 | + jt[vm.CREATE2].SetConstantGas(currentValCreate2 * multiplier) |
| 86 | +} |
| 87 | +``` |
| 88 | + |
| 89 | +then, the function as to be associated with a name via a custom activator: |
| 90 | + |
| 91 | +```go |
| 92 | +evmosActivators = map[int]func(*vm.JumpTable){ |
| 93 | + "evmos_0": eips.Enable0000, |
| 94 | +} |
| 95 | +``` |
| 96 | + |
| 97 | +## Activation of Improvement Proposals |
| 98 | + |
| 99 | +Due to continuous changes in the interaction of users with the protocol, and to |
| 100 | +introduce a safety measure along with the freedom to customize the virtual |
| 101 | +machine behavior, custom improvement proposals are not active by default. The |
| 102 | +two just defined structures are used to define a modifier, and associate it with |
| 103 | +a namespace. The activation of selected improvement proposals is made via |
| 104 | +`x/evm` parameters. It is possible to activate specific improvement proposals in |
| 105 | +two ways: |
| 106 | + |
| 107 | +1. Upgrade: create a protocol upgrade handler that introduce the proposal name |
| 108 | +in the active list. |
| 109 | + |
| 110 | +2. Governance: create governance proposal to activate a improvement that is |
| 111 | +registered in the custom activator. |
| 112 | + |
| 113 | +With this approach, it is given to developers the possibility to quickly react |
| 114 | +to security issues or market conditions, still keeping chain's participants in |
| 115 | +the loop. |
| 116 | + |
| 117 | +## Additional Resources |
| 118 | + |
| 119 | +1. [Evmos Custom EIPs](https://github.com/evmos/evmos/blob/main/app/eips/README.md): |
| 120 | +please refer to this document for a detailed description of how opcodes and |
| 121 | +custom improvement proposals has to be used in the evmOS framework. |
0 commit comments