status-im
/
nim-eth
mirror of https://github.com/status-im/nim-eth.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nim-eth/eth/common/headers.nim

51 lines
1.8 KiB
Nim
Raw Normal View History

Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
# eth
# Copyright (c) 2024 Status Research & Development GmbH
# Licensed and distributed under either of
# * MIT license (license terms in the root directory or at https://opensource.org/licenses/MIT).
# * Apache v2 license (license terms in the root directory or at https://www.apache.org/licenses/LICENSE-2.0).
# at your option. This file may not be copied, modified, or distributed except according to those terms.
{.push raises: [].}
import "."/[addresses, base, hashes, times]
export addresses, base, hashes, times
type
DifficultyInt* = UInt256
Header* = object
# https://github.com/ethereum/execution-specs/blob/51fac24740e662844446439ceeb96a460aae0ba0/src/ethereum/cancun/blocks.py
parentHash*: Hash32
ommersHash*: Hash32
coinbase*: Address
stateRoot*: Root
transactionsRoot*: Root
receiptsRoot*: Root
logsBloom*: Bloom
difficulty*: DifficultyInt
number*: BlockNumber
gasLimit*: GasInt
gasUsed*: GasInt
timestamp*: EthTime
extraData*: seq[byte]
prevRandao -> Bytes32 (#740) This one is a bit of a mess because it has different names and types across specs :/
2024-10-02 11:00:10 +00:00
mixHash*: Bytes32
## AKA mix_digest in some specs - Hash32 in the eth API but Bytes32 in
## the execution API and spec!
Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
nonce*: Bytes8
Fix Authorization fields name to v, r, s (#749)
2024-10-15 14:09:16 +00:00
baseFeePerGas*: Opt[UInt256] # EIP-1559
withdrawalsRoot*: Opt[Hash32] # EIP-4895
blobGasUsed*: Opt[uint64] # EIP-4844
excessBlobGas*: Opt[uint64] # EIP-4844
Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
parentBeaconBlockRoot*: Opt[Hash32] # EIP-4788
Fix Authorization fields name to v, r, s (#749)
2024-10-15 14:09:16 +00:00
requestsHash*: Opt[Hash32] # EIP-7685
Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
# starting from EIP-4399, `mixDigest` field is called `prevRandao`
prevRandao -> Bytes32 (#740) This one is a bit of a mess because it has different names and types across specs :/
2024-10-02 11:00:10 +00:00
template prevRandao*(h: Header): Bytes32 =
Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
h.mixHash
prevRandao -> Bytes32 (#740) This one is a bit of a mess because it has different names and types across specs :/
2024-10-02 11:00:10 +00:00
template `prevRandao=`*(h: Header, hash: Bytes32) =
Align core types with execution spec (#733) Since these types were written, we've gained an executable spec: https://github.com/ethereum/execution-specs This PR aligns some of the types we use with this spec to simplify comparisons and cross-referencing. Using a `distinct` type is a tradeoff between nim ergonomics, type safety and the ability to work around nim quirks and stdlib weaknesses. In particular, it allows us to overload common functions such as `hash` with correct and performant versions as well as maintain control over string conversions etc at the cost of a little bit of ceremony when instantiating them. Apart from distinct byte types, `Hash32`, is introduced in lieu of the existing `Hash256`, again aligning this commonly used type with the spec which picks bytes rather than bits in the name.
2024-09-29 08:52:19 +00:00
h.mixHash = hash
template txRoot*(h: Header): Root = h.transactionsRoot