nimbus-eth1/nimbus/utils/utils.nim

63 lines
1.9 KiB
Nim
Raw Normal View History

import
eth/[trie, rlp, common/eth_types_rlp, trie/db],
stew/byteutils
2018-12-03 10:54:19 +00:00
export eth_types_rlp
2019-02-26 11:26:38 +00:00
{.push raises: [].}
proc calcRootHash[T](items: openArray[T]): Hash256
{.gcsafe, raises: [RlpError]} =
2018-12-03 10:54:19 +00:00
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
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)
hashResult = withKeccakHash:
h.update(prefix)
h.update(address)
h.update(salt.bytes)
h.update(dataHash.data)
2019-05-07 03:23:27 +00:00
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
proc short*(h: Hash256): string =
var bytes: array[6, byte]
bytes[0..2] = h.data[0..2]
bytes[^3..^1] = h.data[^3..^1]
bytes.toHex