The currently way Besu has to spot if a transaction has already been process, is to look if the transaction is present in the transaction pool, that by default is 4K, while the amount of pending transactions on the mainnet, is much more, the order of hundred of thousands, so basically even if a transaction has been already processed, the chances that it gets reprocessed is very high, with the result of doing a lot of useless work, that affects Besu performance.
A trivial solution could be to just raise the transaction pool size, but that is not always advisable, because it is critical for block production to keep it fast, and incresing its size could negatively affect the perfomance of the strategy choosen to select transactions to include in the block.
A better option, implemented here, is to leverage data that we already have, and that keeps the history of the transactions exchanged with other peers. This data is just a collection of transaction hashes that we have received or seen, and in any case if a transaction is in that collection, it means that it has already been processed by Besu, so it is possible to directly skip it.
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Currently Besu has a limited support for sending NewPooledTransactionHashes messages, and other aspect related to reduce transactions synchronization traffic, described in the Ethereum Wire Protocol version 66.
Specifically:
Besu only uses NewPooledTransactionHashes for new local transactions, while it could be extended to any transaction added to the transaction pool
Besu does not limit the sending of the full transaction messages to a small fraction of the connected peers, and sends the new transaction hashes to all the remaining peers
This PR, extends eth/66 support and does some code refactoring, to remove some reduntant code and rename some classes to identify they are related to the NewPooledTransactionHashes message.
The main changes are:
Do not have a separate tracker for transaction hashes, since for them we can reuse PeerTransactionTracker, that tracks full transactions exchange history and sending queue with a peer. So PeerPendingTransactionTracker has been removed. --tx-pool-hashes-max-size is now deprecated and has no more effect and it will be removed in a future release.
When a new peer connects, if it support eth/6[56] then we send all the transaction hashes we have in the pool, otherwise we send the full transactions.
When new transactions are added to the pool, we send full transactions to peers without eth/6[56] support, or to a small fractions of all peers, and then we send only transaction hashes to the remaining peer that support eth/6[56]. Both transactions and transaction hashes are only sent if not already exchanged with that specific peer.
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
PR that adds the different request tasks necessary for the snapsync as well as a utility to manage the ranges of requests
Signed-off-by: Karim TAAM <karim.t2am@gmail.com>
* Tune transaction worker queue capacity to adapt to mainnet
Currently Besu handles hundreds of transaction message per seconds,
so having a queue of 1M messages result in a lot of expired messages,
make sense to reduce the capacity to drop incoming messages that could not
be handled anyway.
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
* Tune the number transactions seen by peer to adapt to mainnet traffic
Currently on mainnet there are many thousand of pending transactions
exchanged between peers, but Besu has a short memory of what has been
exchanged with a specific peer, with the result that the same transaction
is often exchanged back and forth with the same peer, expecially when the
peer is another Besu.
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
* Improve trace log of transaction exchanges with other peers
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
* Update CHANGELOG
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
* Headings are bold and cyan
* grouping graphQL related options
* Json RPC Http Option Group
Json RPC Websocket Option Group
Signed-off-by: Sandra Wang <yx97.wang@gmail.com>
Co-authored-by: Sally MacFarlane <sally.macfarlane@consensys.net>
* added acceptance test for execution engine apis
* removed check of payload id length
Signed-off-by: Daniel Lehrner <daniel.lehrner@consensys.net>
Co-authored-by: Sally MacFarlane <sally.macfarlane@consensys.net>
- This is to provide a clearer way of knowing which
privacyGroupId a private transaction ended up in.
Signed-off-by: Antony Denyer <git@antonydenyer.co.uk>
Co-authored-by: Sally MacFarlane <sally.macfarlane@consensys.net>
* refactor graphqlcontext since getContext() is deprecated
Signed-off-by: Sandra Wang <yx97.wang@gmail.com>
Co-authored-by: Sally MacFarlane <sally.macfarlane@consensys.net>
Allow precompiled contracts to return richer information instead of
results/fail. System/precompile contracts can now revert, fail, refund
gas, etc. instead of just succeed or fail.
Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
* refactored auth to allow variant JWT rules to be adopted by different stacks
* configures JWT secret from a file, or creates a temporary one
* jwt auth is optional for engine apis
* test coverage of new cli options
Signed-off-by: Justin Florentine <justin+github@florentine.us>
Fabio Di Fabio
bgravenorst
matkt
Jiri Peinlich
Stefan Pingel
garyschulte
Sally MacFarlane
Diego López León
Frank Li
Sandra Wang
Davide Savazzi
Justin Florentine
Daniel Lehrner
mark-terry
Antony Denyer
Danno Ferrin
mbaxter