The purpose of this method is to return the number of transactions an account has broadcasted or sent.
Below EIPs are considered a requeriment for us:
-
EIP-2718 | Transaction Envelopes
Abstract:
TransactionType || TransactionPayload
is a valid transaction andTransactionType || ReceiptPayload
is a valid transaction receipt whereTransactionType
identifies the format of the transaction and*Payload
is the transaction/receipt contents, which are defined in future EIPs. -
EIP-2930 | Optional access lists
Abstract: We introduce a new EIP-2718 transaction type, with the format
0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])
. TheaccessList
specifies a list of addresses and storage keys; these addresses and storage keys are added into theaccessed_addresses
andaccessed_storage_keys
global sets (introduced in EIP-2929). A gas cost is charged, though at a discount relative to the cost of accessing outside the list. -
Abstract: A proposal to build a block's
access_list
and include its fingerprintAccessListRoot
in the block header.
Below EIPs are considered complimentary we don't depend on but can serve us as inspiration:
-
EIP 2976 | Typed Transactions over Gossip
Abstract: Typed Transactions can be sent over devp2p as
TransactionType || TransactionPayload
. The exact contents of theTransactionPayload
are defined by theTransactionType
in future EIPs, and clients may start supporting their gossip without incrementing the devp2p version. If a client receives aTransactionType
that it doesn't recognize, it SHOULD disconnect from the peer who sent it. Clients MUST NOT send new transaction types before they believe the fork block is reached.
stateDiagram-v2
direction LR
[*] --> Draft
Draft --> Review
Review --> Living
Review --> Implementation
Implementation --> Final
Final --> [*]
Final --> Moribund
Draft --> Withdrawn
Review --> Withdrawn
Implementation --> Withdrawn
Implementation --> Deferred
Withdrawn --> [*]