Skip to content

Commit 4259123

Browse files
committed
add custom improvement proposal doc
1 parent 7ea8525 commit 4259123

File tree

1 file changed

+121
-0
lines changed

1 file changed

+121
-0
lines changed
Lines changed: 121 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
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

Comments
 (0)