[go: up one dir, main page]

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_transaction and 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 event Confirm does 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

Merge request reports

Loading