nimbus-eth1/nimbus/utils.nim

61 lines
1.8 KiB
Nim
Raw Normal View History

import
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:
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)
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