EEI: Change address type from integer to bytes #105
Conversation
| @@ -6,7 +6,7 @@ The Ethereum Environment Interface exposes the core Ethereum API to the eWASM en | |||
|
|
|||
| We define the following Ethereum data types: | |||
| - `bytes`: an array of bytes with unrestricted length | |||
| - `address`: a 160 bit number, represented as a 20 bytes long little endian unsigned integer in memory | |||
| - `address`: an array of 20 bytes | |||
| - `u128`: a 128 bit number, represented as a 16 bytes long little endian unsigned integer in memory | |||
| - `u256`: a 256 bit number, represented as a 32 bytes long little endian unsigned integer in memory | |||
There was a problem hiding this comment.
Should we actually consider u128/u256 numbers or just an array of bytes?!
There was a problem hiding this comment.
No. I think that would not be sufficient. You would have to explain where these bytes come from, i.e. how numbers where serialized to bytes, i.e. endianness.
In case of address this is not needed because an address is a well specified part of a hash, where a hash is defined as bytes, not a number.
There was a problem hiding this comment.
u128 should be defined as an integer value, since it (usually?) denotes an ether value and native arithmetic and comparison operators should work on them in the WASM environment (by experimental u128 or otherwise).
u256 is very difficult because a hash value should not be byte-swapped but the difficulty should be, as it is a quantity.
Byte ordering is therefore highly dependent on context in the case of u256.
| @@ -6,7 +6,7 @@ The Ethereum Environment Interface exposes the core Ethereum API to the eWASM en | |||
|
|
|||
| We define the following Ethereum data types: | |||
| - `bytes`: an array of bytes with unrestricted length | |||
| - `address`: a 160 bit number, represented as a 20 bytes long little endian unsigned integer in memory | |||
| - `address`: an array of 20 bytes | |||
There was a problem hiding this comment.
Practically this means it is "big endian"? In evmc it still says big endian.
There was a problem hiding this comment.
I believe it means big endian, but I usually have trouble reasoning about 160-bit numbers.
There was a problem hiding this comment.
I don't think there is currently a case where a 160-bit type should be treated as a value.
The Solidity documentation states that only comparison operators are defined for the "address" type. This puts the type in a difficult situation where it is mostly not a quantity, but can be compared like an integer using operators like <, >, <=, and >=.
I think that the type should not have any notion of byte ordering other than defined by the hash function used to generate it. A correct address value should be the last 20 bytes of the hash of the public key, as usual.
Perhaps this reflects on a needed change in EVMC?
There was a problem hiding this comment.
Solidity actually considers them numbers (as they derive off IntegerType).
EVM considers them numbers too, since they are "right aligned" in the stack slot.
No description provided.