nimbus-eth1/nimbus/sync/protocol_eth65.nim

245 lines
8.7 KiB
Nim
Raw Normal View History

Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
# Nimbus - Ethereum Wire Protocol, version eth/65
#
# Copyright (c) 2018-2021 Status Research & Development GmbH
# Licensed under either of
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
# * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
# at your option. This file may not be copied, modified, or distributed except according to those terms.
## This module implements Ethereum Wire Protocol version 65, `eth/65`.
## Specification:
## https://github.com/ethereum/devp2p/blob/master/caps/eth.md
import
chronos, stint, chronicles, stew/byteutils, macros,
eth/[common/eth_types, rlp, p2p],
eth/p2p/[rlpx, private/p2p_types, blockchain_utils],
../p2p/chain
type
NewBlockHashesAnnounce* = object
hash: KeccakHash
number: uint64 # Note: Was `uint`, wrong on 32-bit targets.
NewBlockAnnounce* = EthBlock
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
ForkId* = object
forkHash: array[4, byte] # The RLP encoding must be exactly 4 bytes.
forkNext: BlockNumber # The RLP encoding must be variable-length
PeerState = ref object
initialized*: bool
bestBlockHash*: KeccakHash
bestDifficulty*: DifficultyInt
const
tracePackets* = true # Set `true` or `false` to control packet traces.
traceHandshakes* = true
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
const
maxStateFetch* = 384
maxBodiesFetch* = 128
maxReceiptsFetch* = 256
maxHeadersFetch* = 192
ethVersion = 65
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
func toHex*(x: KeccakHash): string = x.data.toHex
macro tracePacket*(msg: static[string], args: varargs[untyped]) =
quote do:
if tracePackets:
trace `msg`, `args`
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
p2pProtocol eth(version = ethVersion,
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
peerState = PeerState,
useRequestIds = false):
onPeerConnected do (peer: Peer):
let
network = peer.network
chain = network.chain
bestBlock = chain.getBestBlockHeader
chainForkId = chain.getForkId(bestBlock.blockNumber)
forkId = ForkId(
forkHash: chainForkId.crc.toBytesBe,
forkNext: chainForkId.nextFork.u256,
)
tracePacket ">> Sending eth.Status (0x00) [eth/" & $ethVersion & "]",
peer, td=bestBlock.difficulty,
bestHash=bestBlock.blockHash.toHex,
networkId=network.networkId,
genesis=chain.genesisHash.toHex,
forkHash=forkId.forkHash.toHex, forkNext=forkId.forkNext
let m = await peer.status(ethVersion,
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
network.networkId,
bestBlock.difficulty,
bestBlock.blockHash,
chain.genesisHash,
forkId,
timeout = chronos.seconds(10))
if traceHandshakes:
trace "Handshake: Local and remote networkId",
local=network.networkId, remote=m.networkId
trace "Handshake: Local and remote genesisHash",
local=chain.genesisHash.toHex, remote=m.genesisHash.toHex
trace "Handshake: Local and remote forkId",
local=(forkId.forkHash.toHex & "/" & $forkId.forkNext),
remote=(m.forkId.forkHash.toHex & "/" & $m.forkId.forkNext)
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
if m.networkId != network.networkId:
trace "Peer for a different network (networkId)", peer,
expectNetworkId=network.networkId, gotNetworkId=m.networkId
raise newException(UselessPeerError, "Eth handshake for different network")
if m.genesisHash != chain.genesisHash:
trace "Peer for a different network (genesisHash)", peer,
expectGenesis=chain.genesisHash.toHex, gotGenesis=m.genesisHash.toHex
raise newException(UselessPeerError, "Eth handshake for different network")
trace "Peer matches our network", peer
peer.state.initialized = true
peer.state.bestDifficulty = m.totalDifficulty
peer.state.bestBlockHash = m.bestHash
handshake:
# User message 0x00: Status.
proc status(peer: Peer,
ethVersionArg: uint,
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
networkId: NetworkId,
totalDifficulty: DifficultyInt,
bestHash: KeccakHash,
genesisHash: KeccakHash,
forkId: ForkId) =
tracePacket "<< Received eth.Status (0x00) [eth/" & $ethVersion & "]",
peer, td=totalDifficulty,
bestHash=bestHash.toHex,
networkId,
genesis=genesisHash.toHex,
forkHash=forkId.forkHash.toHex, forkNext=forkId.forkNext
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
# User message 0x01: NewBlockHashes.
proc newBlockHashes(peer: Peer, hashes: openArray[NewBlockHashesAnnounce]) =
tracePacket "<< Discarding eth.NewBlockHashes (0x01)",
peer, count=hashes.len
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
discard
# User message 0x02: Transactions.
proc transactions(peer: Peer, transactions: openArray[Transaction]) =
tracePacket "<< Discarding eth.Transactions (0x02)",
peer, count=transactions.len
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
discard
requestResponse:
# User message 0x03: GetBlockHeaders.
proc getBlockHeaders(peer: Peer, request: BlocksRequest) =
tracePacket "<< Received eth.GetBlockHeaders (0x03)",
peer, count=request.maxResults
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
if request.maxResults > uint64(maxHeadersFetch):
debug "eth.GetBlockHeaders (0x03) requested too many headers",
peer, requested=request.maxResults, max=maxHeadersFetch
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
await peer.disconnect(BreachOfProtocol)
return
let headers = peer.network.chain.getBlockHeaders(request)
if headers.len > 0:
tracePacket ">> Replying with eth.BlockHeaders (0x04)",
peer, count=headers.len
else:
tracePacket ">> Replying EMPTY eth.BlockHeaders (0x04)",
peer, count=0
await response.send(headers)
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
# User message 0x04: BlockHeaders.
proc blockHeaders(p: Peer, headers: openArray[BlockHeader])
requestResponse:
# User message 0x05: GetBlockBodies.
proc getBlockBodies(peer: Peer, hashes: openArray[KeccakHash]) =
tracePacket "<< Received eth.GetBlockBodies (0x05)",
peer, count=hashes.len
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
if hashes.len > maxBodiesFetch:
debug "eth.GetBlockBodies (0x05) requested too many bodies",
peer, requested=hashes.len, max=maxBodiesFetch
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
await peer.disconnect(BreachOfProtocol)
return
let bodies = peer.network.chain.getBlockBodies(hashes)
if bodies.len > 0:
tracePacket ">> Replying with eth.BlockBodies (0x06)",
peer, count=bodies.len
else:
tracePacket ">> Replying EMPTY eth.BlockBodies (0x06)",
peer, count=0
await response.send(bodies)
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
# User message 0x06: BlockBodies.
proc blockBodies(peer: Peer, blocks: openArray[BlockBody])
# User message 0x07: NewBlock.
proc newBlock(peer: Peer, bh: EthBlock, totalDifficulty: DifficultyInt) =
# (Note, needs to use `EthBlock` instead of its alias `NewBlockAnnounce`
# because either `p2pProtocol` or RLPx doesn't work with an alias.)
tracePacket "<< Discarding eth.NewBlock (0x07)",
peer, totalDifficulty,
blockNumber=bh.header.blockNumber, blockDifficulty=bh.header.difficulty
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
discard
# User message 0x08: NewPooledTransactionHashes.
proc newPooledTransactionHashes(peer: Peer, hashes: openArray[KeccakHash]) =
tracePacket "<< Discarding eth.NewPooledTransactionHashes (0x08)",
peer, count=hashes.len
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
discard
requestResponse:
# User message 0x09: GetPooledTransactions.
proc getPooledTransactions(peer: Peer, hashes: openArray[KeccakHash]) =
tracePacket "<< Received eth.GetPooledTransactions (0x09)",
peer, count=hashes.len
tracePacket ">> Replying EMPTY eth.PooledTransactions (0x10)",
peer, count=0
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
await response.send([])
# User message 0x0a: PooledTransactions.
proc pooledTransactions(peer: Peer, transactions: openArray[Transaction])
nextId 0x0d
requestResponse:
# User message 0x0d: GetNodeData.
proc getNodeData(peer: Peer, hashes: openArray[KeccakHash]) =
tracePacket "<< Received eth.GetNodeData (0x0d)",
peer, count=hashes.len
let blobs = peer.network.chain.getStorageNodes(hashes)
if blobs.len > 0:
tracePacket ">> Replying with eth.NodeData (0x0e)",
peer, count=blobs.len
else:
tracePacket ">> Replying EMPTY eth.NodeData (0x0e)",
peer, count=0
await response.send(blobs)
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
# User message 0x0e: NodeData.
proc nodeData(peer: Peer, data: openArray[Blob])
requestResponse:
# User message 0x0f: GetReceipts.
proc getReceipts(peer: Peer, hashes: openArray[KeccakHash]) =
tracePacket "<< Received eth.GetReceipts (0x0f)",
peer, count=hashes.len
tracePacket ">> Replying EMPTY eth.Receipts (0x10)",
peer, count=0
Sync: Support for `eth/65` protocol This patch adds the `eth/65` protocol, documented at https://github.com/ethereum/devp2p/blob/master/caps/eth.md. This is an intentionally simple patch, designed to not break, change or depend on other functionality much, so that the "_old_ sync" methods can be run usefully again and observed. This patch isn't "new sync" (a different set of sync algorithms), but it is one of the foundations. For a while now Nimbus Eth1 only supported protocol `eth/63`. But that's obsolete, and very few nodes still support it. This meant Nimbus Eth1 would make slow progress trying to sync, as most up to date clients rejected it. The current specification is `eth/66`, and the functionality we really need is in `eth/64`. So why `eth/65`? - `eth/64` is essential because of the `forkId` feature. But `eth/64` is on its way out as well. Many clients, especially the most up to date Geth running the current hard-forks (Berlin/London) don't talk `eth/64` any more. - `eth/66` is the current specification, but some clients don't talk `eth/66` yet. We'd like to have the best peer connectivity during tests, and currently everything that talks `eth/66` also talks `eth/65`. - Nimbus Eth1 RLPx only talks one version at a time. (Without changes to the RLPx module. When those go in we'll add `eth/64..eth/66` for greater peer reach and testing the `eth/66` behaviour. For simplicity and decoupling, this patch contains just one version, the most useful.) What are `eth/64` and `eth/65`? - `eth/64` (EIP-2364) added `forkId` which allows nodes to distinguish between Ethereum (ETH) and Ethereum Classic (ETC) blockchains, which share the same genesis block. `forkId` also protects the system when a new hard fork is going to be rolled out, by blocking interaction with out of date nodes. The feature is required nowadays. We send the right details to allow connection (this has been tested a lot), but don't apply the full validation rules of EIP-2124/EIP-2364 in this patch. It's to keep this patch simple (in its effects) and because those rules have consequences best tested separately. In practice the other node will reject us when we would reject it, so this is ok for testing, as long as it doesn't get seriously deployed. - `eth/65` added more efficient transaction pool methods. - Then a later version of `eth/65` (without a new number) added typed transactions, described in [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976). Why it's moved to `nimbus-eth1`: - Mainly because `eth/64` onwards depend on the current state of block synchronisation, as well as the blockchain's sequence of hard-fork block numbers, both of which are part of `nimbus-eth1` run-time state. These aren't available to pure `nim-eth` code. Although it would be possible to add an API to let `nimbus-eth1` set these numbers, there isn't any point because the protocol would still only be useful to `nimbus-eth1`. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-07-21 20:00:03 +00:00
await response.send([])
# TODO: implement `getReceipts` and reactivate this code
# await response.send(peer.network.chain.getReceipts(hashes))
# User message 0x10: Receipts.
proc receipts(peer: Peer, receipts: openArray[Receipt])