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/transactions.nim

82 lines
2.3 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: [].}
Change `VersionedHash` to `Hash32` (#738) This is closer to both the exeuction spec and api
2024-10-01 09:54:01 +00:00
import "."/[addresses, base, hashes]
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
Change `VersionedHash` to `Hash32` (#738) This is closer to both the exeuction spec and api
2024-10-01 09:54:01 +00:00
export addresses, base, hashes
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
transaction signing helpers (#742) Transaction signing is something that happens in a lot of places - this PR introduces primitives for transaction signing in `transaction_utils` such that we can use the same logic across web3/eth1/etc for this simple operation. `transaction_utils` also contains a few more "spec-derived" helpers for working with transactions, such as the computation of a contract address etc that cannot easily be introduced in `transactions` itself without bringing in dependencies like secp and rlp, so they end up in a separate module. Finally, since these modules collect "versions" of these transaction types across different eips, some tests are moved to follow the same structure.
2024-10-04 11:46:58 +00:00
const EIP155_CHAIN_ID_OFFSET* = 35'u64
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
type
AccessPair* = object
address* : Address
storageKeys*: seq[Bytes32]
AccessList* = seq[AccessPair]
Authorization* = object
chainId*: ChainId
address*: Address
nonce*: AccountNonce
yParity*: uint64
R*: UInt256
S*: UInt256
TxType* = enum
TxLegacy # 0
TxEip2930 # 1
TxEip1559 # 2
TxEip4844 # 3
TxEip7702 # 4
Transaction* = object
txType* : TxType # EIP-2718
chainId* : ChainId # EIP-2930
nonce* : AccountNonce
gasPrice* : GasInt
maxPriorityFeePerGas*: GasInt # EIP-1559
maxFeePerGas* : GasInt # EIP-1559
gasLimit* : GasInt
to* : Opt[Address]
value* : UInt256
payload* : seq[byte]
accessList* : AccessList # EIP-2930
maxFeePerBlobGas*: UInt256 # EIP-4844
versionedHashes*: seq[VersionedHash] # EIP-4844
authorizationList*: seq[Authorization]# EIP-7702
V* : uint64
R*, S* : UInt256
# 32 -> UInt256
# 4096 -> FIELD_ELEMENTS_PER_BLOB
NetworkBlob* = array[32*4096, byte]
BlobsBundle* = object
commitments*: seq[KzgCommitment]
proofs*: seq[KzgProof]
blobs*: seq[NetworkBlob]
# TODO why was this part of eth types?
NetworkPayload* = ref BlobsBundle
PooledTransaction* = object
tx*: Transaction
networkPayload*: NetworkPayload # EIP-4844
func destination*(tx: Transaction): Address =
# use getRecipient if you also want to get
# the contract address
tx.to.valueOr(default(Address))
transaction signing helpers (#742) Transaction signing is something that happens in a lot of places - this PR introduces primitives for transaction signing in `transaction_utils` such that we can use the same logic across web3/eth1/etc for this simple operation. `transaction_utils` also contains a few more "spec-derived" helpers for working with transactions, such as the computation of a contract address etc that cannot easily be introduced in `transactions` itself without bringing in dependencies like secp and rlp, so they end up in a separate module. Finally, since these modules collect "versions" of these transaction types across different eips, some tests are moved to follow the same structure.
2024-10-04 11:46:58 +00:00
func isEip155*(tx: Transaction): bool =
tx.V >= EIP155_CHAIN_ID_OFFSET
func contractCreation*(tx: Transaction): bool =
tx.to.isNone