Fetch txns from hotshot

[nomaxg]

Introduces an espresso-sequencer that simply fetches blocks one by one from HotShot, starting at a specified index (this is currently 0, but will eventually reflect the latest block number sequenced).

Future work:

1. Add batch justification
2. Start from the correct block index

To test this out, start a dev network, spin down the sequencer, run a hotshot network (just demo in the sequencer repo). And run:

make build
./target/bin/nitro --conf.file ./config/sequencer_config.json --node.feed.output.enable --node.feed.output.port 9642  --http.api net,web3,eth,txpool,debug --node.seq-coordinator.my-url  ws://localhost:8548 --graphql.enable --execution.sequencer.espresso --execution.sequencer.hotshot-url "http://localhost:50000" --execution.rpc.espresso --execution.rpc.hotshot-url "http://localhost:50000" --execution.rpc.espresso-namespace 1 --execution.sequencer.espresso-namespace 1
cd nitro-testnode/scripts
node index.js send-l2 --to address_0xd4b1245a3bA26EdA9D36ebE37b3c597ffc023761 --ethamount 1 --l2url http://localhost:8548
cast balance 0xd4b1245a3bA26EdA9D36ebE37b3c597ffc023761 --rpc-url http://localhost:8547

[nomaxg]

Looking into this CI lint issue, seems unrelated to these changes

[sveitser]

There are some extra trailing arguments in the nitro command in the instructions in the comment.

[nomaxg]

There are some extra trailing arguments in the nitro command in the instructions in the comment.

hmm seems to work for me

[sveitser]

Hmm. There's something wrong with my binary then.

./target/bin/nitro --conf.file ./config/sequencer_config.json --node.feed.output.enable --node.feed.output.port 9642  --http.api net,web3,eth,txpool,debug --node.seq-coordinator.my-url  ws://localhost:8548 --graphql.enable --execution.sequencer.espresso --execution.sequencer.hotshot-url "http://localhost:50000" --execution.rpc.espresso --execution.rpc.hotshot-url "http://localhost:50000" --execution.rpc.espresso-namespace 1 --execution.sequencer.espresso-namespace 1
Version: 9827a28-modified, time: 2023-11-06T13:51:56Z
Sample usage: ./target/bin/nitro [OPTIONS]

Options:
  --help
  --dev: Start a default L2-only dev chain

Fatal configuration error: unknown flag: --execution.rpc.espresso

./target/bin/nitro --help 2>&1 |grep espresso        
      --execution.sequencer.espresso                                                                    if true, transactions will be fetched from the espresso sequencer network
      --execution.sequencer.espresso-namespace uint                                                     espresso namespace that corresponds the L2 chain

[sveitser]

@nomaxg The command works after updating the geth submodule.

[sveitser]

@nomaxg Tried to follow the whole set of instructions. Current issue seems to be that both the nitro testnode and the sequencer start an L1 (listening on the same ports).

[sveitser]

Code changes look good, but as mentioned above I haven't been able to run it. If we want to have less to worry about when syncing upstream code we could squash at least the commit 9827a28 that reverts some changes.

[nomaxg]

@nomaxg The command works after updating the geth submodule.

Ah yes - I'll update the geth submodule here

[nomaxg]

@nomaxg Tried to follow the whole set of instructions. Current issue seems to be that both the nitro testnode and the sequencer start an L1 (listening on the same ports).

ahh that's right, I actually added this small change locally to the sequencer to accommodate both:

services:
  demo-l1-network:
    image: ghcr.io/espressosystems/geth-l1:main
    ports:
      - 8555:8545
      - 8556:8546

[sveitser]

submodule

In case you didn't see, I pushed a change with that in 117b0c4

[nomaxg]

submodule

In case you didn't see, I pushed a change with that in 117b0c4

yep realized that when I attempted to push 😄

[nomaxg]

@sveitser thoughts on merging this in? I think @ImJeremyHe's work will solve the L1 port conflict

[sveitser]

@nomaxg sure go ahead.