Sepolia has had some peering troubles in the past, It seems like the old
EF bootnodes weren't created properly or not added to the IaC stack we
usually have our configs in, so I went ahead and setup new bootnodes on
DigitalOcean. These have more liberal bandwidth limits and cost far
lesser to run, they should be able to help with peering and sync
performance on Sepolia.
The bootnode configs have been commited to the private devops repo along
with a reserved IP and the nodekey has been backed up. The bootnode has
additionally been added to the DevOps monitoring and updating stack. We
should be able to maintain these bootnodes far better in the future.
In this PR Header's ExcessDataGas is set to the actual value, but it's
still unused. It will be used to compute data fee for eip-4844 data
blobs, logic of which will be added in later PRs. Also eip-4844 header
verification logic added.
`excessDataGas` has been partially made eip-4844 ready, so instead of
passing nils to functions, now it actually assigned to some value (it is
expected to be nil until cancun update).
Pre-Shanghai blocks should have `nil` withdrawals, while post-Shanghai
blocks should have non-nil withdrawals (empty or non-empty slice, but
not `nil`). Judging from Issue #6976, that's not always a case. PR #7279
attempted to fix the issue, but unfortunately it only masks the root
cause.
This reverts commit c60a6a2962.
when assigning default bor parameters, need to make sure config exists
first. since not sending the config will result in it being nil, not the
empty struct.
it would appear that an extra `e` was added somewhere along the way to
the cli flags for txpool. If this was intentional I was curious as to
why, otherwise it seems like fixing the flag would remedy some
confusion. Thank you
Upon further investigation it would appear
https://github.com/ledgerwatch/erigon/blob/devel/cmd/utils/flags.go#L173
shows corrected spelling.
New transaction type added. This transaction differs from previous
transactions in a network encoding. Network encoding of a new
transaction wraps "regular" transaction with additional data: blobs and
kzgs. The network wrapper will be verified by execution layer using this
extra data.
