Local dev env with Espresso Sequencer

[ImJeremyHe]

No description provided.

[sveitser]

@ImJeremyHe since this seems to cause problem with the contract deployment on L1 is it possible that the commitment task interferes with the L1 deployment? Can you confirm that the account we use here for the hotshot commitment isn't otherwise used?

[sveitser]

@ImJeremyHe I had a look at the code and it looks like there should be no interference. Another possibility is that there are some hardcoded contract addresses during the test deployment and having the commitment task run before the rollup deployment messes with that. I haven't yet had time to check if that's the case, but currently I don't have another idea.

Edit: if we do use a separate account this shouldn't be possible either.

[sveitser]

@ImJeremyHe I'm a bit confused that the failing gas estimation happens while initialising the L1 but the failing request is a request to the L2 sequencer.

    requestBody: '{"method":"eth_estimateGas","params":[{"to":"0x00000000000000000000000000000000000000c8","data":"0xc3dc58790000000000000000000000004a2ba922052ba54e29c5417bc979daaf7d5fe4f40000000000000000000000000000000000000000000000000de0b6b3a76400000000000000000000000000001294b86822ff4976bfe136cb06cf43ec7fcf257400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003f1eae7d46d88f08fc2f8ed27fcb2ab183eb2d0e0000000000000000000000003f1eae7d46d88f08fc2f8ed27fcb2ab183eb2d0e00000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000c44201f985000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000001000000000000000000000000a39ffa43eba037d67a0f4fe91956038aba0ca38600000000000000000000000000000000000000000000000000000000000000010000000000000000000000004a2ba922052ba54e29c5417bc979daaf7d5fe4f400000000000000000000000000000000000000000000000000000000"}],"id":425,"jsonrpc":"2.0"}',
    requestMethod: 'POST',
    url: 'http://sequencer:8547'
  },
  method: 'estimateGas',
  transaction: {
    to: '0x00000000000000000000000000000000000000C8',
    data: '0xc3dc58790000000000000000000000004a2ba922052ba54e29c5417bc979daaf7d5fe4f40000000000000000000000000000000000000000000000000de0b6b3a76400000000000000000000000000001294b86822ff4976bfe136cb06cf43ec7fcf257400000000000000000000000000000000000000000000000000000000000000000000000000000000000000003f1eae7d46d88f08fc2f8ed27fcb2ab183eb2d0e0000000000000000000000003f1eae7d46d88f08fc2f8ed27fcb2ab183eb2d0e00000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000c44201f985000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000001000000000000000000000000a39ffa43eba037d67a0f4fe91956038aba0ca38600000000000000000000000000000000000000000000000000000000000000010000000000000000000000004a2ba922052ba54e29c5417bc979daaf7d5fe4f400000000000000000000000000000000000000000000000000000000',
    accessList: null
  }

On the upside it now makes more sense that our changes break this.

[sveitser]

@ImJeremyHe it's also possible the issues arise from L2 transactions going through the sequencer. Since the sequencer may sequence transactions out of order this could explain why we get transactions replaced errors. It could also explain why we get the permissions error (sometimes) but I can't say for sure. If all the L2 transaction wait until they get a transaction receipt then re-ordering should not be an issue.

Maybe would be good to confirm if that is the case I think the places I have looked at inside the arbitrum-sdk repo all have .wait() but maybe there are places where multiple transactions are sent in parallel.

Does ./test-node.bash --init --dev --espresso ever work without error for you? For me it always fails, tried maybe a total of 10 times.

[nomaxg]

What is the purpose of this espresso-sequencer account? Does it correspond to the hotshot commitment contract?

[ImJeremyHe]

Yes. It needs to commit/deploy the hotshot contract. There are some other ways to do this, like funding in the Genesis Block. But I think it is not a good idea to change so many files and this special account may be useful in later testing.

[sveitser]

I wonder if the espresso sequencer account should be a user account instead? One could argue we don't require it to be a special account since it's we didn't increment specialAccounts but things are working anyway?

[ImJeremyHe]

Thanks! I didn't realize that. This constant is only to write down the information of accounts(for debugging?). Using espresso-sequencer as the name of the account maybe not necessary, but it clearly shows there is a special entity in our integration.

[sveitser]

LGTM. Just one question remaining.