-
Notifications
You must be signed in to change notification settings - Fork 0
/
eip_scratchpaper.txt
73 lines (60 loc) · 3.59 KB
/
eip_scratchpaper.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
--description--
A space-efficient standard for contract ABI with Layer 2 in mind
--abstract--
The ABIv3 encoding algorithm is an evolution of Solidity's ABIv2 designed for Layer-2 smart contracts with a focus on maximizing space efficiency. ABIv3 is designed to be extensible and readily differentiable from prior ABI standards, especially ABIv2.
--motivation--
This EIP assumes that Layer 2 protocols are the future of Ethereum scaling.
For the forseeable future, Layer 2 protocols such as optimistic rollups will incur significant costs that scale with the number of bytes they include. Up to now, smart contract developers have understandably chosen to minimize these costs by customizing in an ad-hoc manner their serialized function calls to be as short as possible. This has led to a ubiquitous lack of standardization among smart contracts leveraging Layer 2 protocols. This failure to standardize has caused the interfaces to these contracts to be generally mutually incompatible and relatively opaque even to specialized software tools. The current ABIv2 standard has been insufficient to address this issue due to it requiring a large number of bytes to encode even relatively simple function calls, and future Layer 2 smart contracts should be able to opt in to an ABIv3 standard which offers cross-compatibility and inspectability at minimal cost over a bespoke contract interface.
--rationale--
1. Ethereum will scale and the overwhelming majority of contract execution will occur on Layer-2 in and among contracts which do not exist today.
2. De facto, there is no calldata standardization on Layer 2 currently. It is not possible to achieve compatibility with existing L2 contracts in general because L2 contracts generally do not conform to any standard.
3. Layer-2 computation costs will be inconsequential compared to costs that scale with calldata length (such as cryptographic verification).
4. If a proposed standard's calldata is significantly more expensive than custom hacked calldata, that standard will fail to achieve widespread adoption.
Alternatives:
--example code--
object "Contract1" {
code {
// calldatacopy(0, 0, calldatasize())
let w := calldataload(0x00)
let zeroth := byte(0x00, w)
if gt(zeroth, 0x3f) { stop() }
let fnNumber := 0
let dataIndex := 1
switch gt(0x3f, zeroth)
case 1 {
fnNumber := zeroth
}
default {
let first := byte(0x01, w)
switch lt(first, 0x80)
case 1 {
fnNumber := first
}
default {
if gt(first, 0xb7) { stop() }
let data_length := sub(first, 0x80)
dataIndex := add(2, data_length)
let shift_amount := sub(mul(data_length, 8), 8)
for { let i := 2 } lt(i, dataIndex) { i := add(i, 1) } {
fnNumber := or(fnNumber, shl(shift_amount, byte(i, w)))
shift_amount := sub(shift_amount, 8)
}
}
fnNumber := add(fnNumber, 0x3f)
}
switch fnNumber
case 0 {
w := calldataload(dataIndex)
let addr := shr(96, w)
w := calldataload(add(dataIndex, 20))
let wei := shr(168, w)
doAThing(addr, wei)
}
function doAThing(account, wei) {
}
return(0, 0)
}
}
TODO: Varint assignment move
TODO: compare compressed ABIv2 to uncompressed ABIv3. gzip max preset, 2MB blob. then compare both to compressed ABIv3
TODO: variable-length integer decode precompile opcode in EOF and/or EVM1