Floodgate: use Etherlink's Tx_queue
What
This MR makes so that Floodgate uses Etherlink's Tx_queue instead of relying upon a custom implementation.
Why
- Improving maintainability with less duplicated code
- Preparing floodgate to be used for Tezlink
How
- Adding arguments to floodgate to adjust variables required by the Tx_queue that were previously not present in Floodgate
- Introducing a function to retrieve a transaction_object instead in addition to a raw transaction in Craft
- Expanding the call trace of
send_raw_transactionand simplifying it in place, deleting unused data - Adapt the current transfer function to use the function available in the Etherlink Tx_queue
- Expanding the transfer call in
wait_for_receipt, as the eventConfirmdoes not carry the hash of the transaction anymore, and it can be taken from the transaction object
Manually testing the MR
Create an Etherlink sandbox with
./octez-evm-node run sandbox --network shadownet --data-dir ~/sandbox-shadownet/ --init-from-snapshot --fund <controller_addr> --verbose
Run floodgate scenarios in another terminal with
ERC-20:
dune exec etherlink/bin_floodgate/main.exe -- run --relay-endpoint http://localhost:8545 --rpc-endpoint http://localhost:8545 --controller <controller_secret_key> -m 10 -r 2 -v --txs-per-salvo 10 --scenario erc20
XTZ:
dune exec etherlink/bin_floodgate/main.exe -- run --relay-endpoint http://localhost:8545 --rpc-endpoint http://localhost:8545 --controller <controller_secret_key> -m 10 -r 2 -v --txs-per-salvo 10 --dummy-data-size 128 --scenario xtz