2020-07-23 07:54:32 +00:00
|
|
|
import
|
2021-09-07 12:30:12 +00:00
|
|
|
pkg/[nimcrypto],
|
|
|
|
eth/[trie, rlp, common, trie/db]
|
2018-12-03 10:54:19 +00:00
|
|
|
|
2019-02-26 11:26:38 +00:00
|
|
|
export nimcrypto.`$`
|
|
|
|
|
2018-12-03 10:54:19 +00:00
|
|
|
proc calcRootHash[T](items: openArray[T]): Hash256 =
|
|
|
|
var tr = initHexaryTrie(newMemoryDB())
|
|
|
|
for i, t in items:
|
2020-04-20 18:12:44 +00:00
|
|
|
tr.put(rlp.encode(i), rlp.encode(t))
|
2018-12-03 10:54:19 +00:00
|
|
|
return tr.rootHash
|
|
|
|
|
|
|
|
template calcTxRoot*(transactions: openArray[Transaction]): Hash256 =
|
|
|
|
calcRootHash(transactions)
|
|
|
|
|
|
|
|
template calcReceiptRoot*(receipts: openArray[Receipt]): Hash256 =
|
|
|
|
calcRootHash(receipts)
|
2019-02-26 07:04:12 +00:00
|
|
|
|
2022-04-08 04:54:11 +00:00
|
|
|
func keccakHash*(value: openArray[byte]): Hash256 {.inline.} =
|
2019-02-26 07:04:12 +00:00
|
|
|
keccak256.digest value
|
|
|
|
|
|
|
|
func generateAddress*(address: EthAddress, nonce: AccountNonce): EthAddress =
|
2019-03-07 15:53:09 +00:00
|
|
|
result[0..19] = keccakHash(rlp.encodeList(address, nonce)).data.toOpenArray(12, 31)
|
2019-02-26 07:04:12 +00:00
|
|
|
|
Transaction: EVMC fix, `CREATE2` salt is a 256-bit blob not a number
This changes fixes a bug in `CREATE2` ops when used with EVMC.
Because it changes the salt type, it affects non-EVMC code as well.
The salt was passed through EVMC with the wrong byte order, although this went
unnoticed as the Nimbus host flipped the byte order before using it.
This was found when running Nimbus with third-party EVM,
["evmone"](https://github.com/ethereum/evmone).
There are different ways to remedy this.
If treated as a number, Nimbus EVM would byte-flip the value when calling EVMC,
then Nimbus host would flip the received value. Finally, it would be flipped a
third time when generating the address in `generateSafeAddress`. The first two
flips can be eliminated by negotiation (like other numbers), but there would
always be one flip.
As a bit pattern, Nimbus EVM would flip the same way it does when dealing with
hashes on the stack (e.g. with `getBlockHash`). Nimbus host wouldn't flip at
all - and when using third-party EVMs there would be no flips in Nimbus.
Because this value is not for arithmetic, any bit pattern is valid, and there
shouldn't be any flips when using a third-party EVM, the bit-pattern
interpretation is favoured. The only flip is done in Nimbus EVM (and might be
eliminated in an optimised version).
As suggested, we'll define a new "opaque 256 bits" type to hold this value.
(Similar to `Hash256`, but the salt isn't necessarily a hash.)
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-06-09 22:32:42 +00:00
|
|
|
type ContractSalt* = object
|
|
|
|
bytes*: array[32, byte]
|
|
|
|
|
|
|
|
const ZERO_CONTRACTSALT* = default(ContractSalt)
|
|
|
|
|
|
|
|
func generateSafeAddress*(address: EthAddress, salt: ContractSalt,
|
|
|
|
data: openArray[byte]): EthAddress =
|
2019-05-07 03:23:27 +00:00
|
|
|
const prefix = [0xff.byte]
|
|
|
|
let dataHash = keccakHash(data)
|
|
|
|
var hashResult: Hash256
|
|
|
|
|
|
|
|
var ctx: keccak256
|
|
|
|
ctx.init()
|
|
|
|
ctx.update(prefix)
|
|
|
|
ctx.update(address)
|
Transaction: EVMC fix, `CREATE2` salt is a 256-bit blob not a number
This changes fixes a bug in `CREATE2` ops when used with EVMC.
Because it changes the salt type, it affects non-EVMC code as well.
The salt was passed through EVMC with the wrong byte order, although this went
unnoticed as the Nimbus host flipped the byte order before using it.
This was found when running Nimbus with third-party EVM,
["evmone"](https://github.com/ethereum/evmone).
There are different ways to remedy this.
If treated as a number, Nimbus EVM would byte-flip the value when calling EVMC,
then Nimbus host would flip the received value. Finally, it would be flipped a
third time when generating the address in `generateSafeAddress`. The first two
flips can be eliminated by negotiation (like other numbers), but there would
always be one flip.
As a bit pattern, Nimbus EVM would flip the same way it does when dealing with
hashes on the stack (e.g. with `getBlockHash`). Nimbus host wouldn't flip at
all - and when using third-party EVMs there would be no flips in Nimbus.
Because this value is not for arithmetic, any bit pattern is valid, and there
shouldn't be any flips when using a third-party EVM, the bit-pattern
interpretation is favoured. The only flip is done in Nimbus EVM (and might be
eliminated in an optimised version).
As suggested, we'll define a new "opaque 256 bits" type to hold this value.
(Similar to `Hash256`, but the salt isn't necessarily a hash.)
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-06-09 22:32:42 +00:00
|
|
|
ctx.update(salt.bytes)
|
2019-05-07 03:23:27 +00:00
|
|
|
ctx.update(dataHash.data)
|
|
|
|
ctx.finish hashResult.data
|
|
|
|
ctx.clear()
|
|
|
|
|
|
|
|
result[0..19] = hashResult.data.toOpenArray(12, 31)
|
|
|
|
|
2019-02-26 07:04:12 +00:00
|
|
|
func hash*(b: BlockHeader): Hash256 {.inline.} =
|
|
|
|
rlpHash(b)
|
2020-07-04 06:23:09 +00:00
|
|
|
|
|
|
|
proc crc32*(crc: uint32, buf: openArray[byte]): uint32 =
|
|
|
|
const kcrc32 = [ 0'u32, 0x1db71064, 0x3b6e20c8, 0x26d930ac, 0x76dc4190,
|
|
|
|
0x6b6b51f4, 0x4db26158, 0x5005713c, 0xedb88320'u32, 0xf00f9344'u32, 0xd6d6a3e8'u32,
|
|
|
|
0xcb61b38c'u32, 0x9b64c2b0'u32, 0x86d3d2d4'u32, 0xa00ae278'u32, 0xbdbdf21c'u32]
|
|
|
|
|
|
|
|
var crcu32 = not crc
|
|
|
|
for b in buf:
|
|
|
|
crcu32 = (crcu32 shr 4) xor kcrc32[int((crcu32 and 0xF) xor (uint32(b) and 0xF'u32))]
|
|
|
|
crcu32 = (crcu32 shr 4) xor kcrc32[int((crcu32 and 0xF) xor (uint32(b) shr 4'u32))]
|
|
|
|
|
|
|
|
result = not crcu32
|