Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle genesis state #4148

Open
benesjan opened this issue Jan 19, 2024 · 0 comments
Open

Properly handle genesis state #4148

benesjan opened this issue Jan 19, 2024 · 0 comments

Comments

@benesjan
Copy link
Contributor

benesjan commented Jan 19, 2024

Currently we allow anything as genesis state by not performing last archive root checks in the beginning. This should be addressed.

Look for TODO(#4148) in the codebase.

@github-project-automation github-project-automation bot moved this to Todo in A3 Jan 19, 2024
@benesjan benesjan changed the title Handle genesis state "properly" Properly handle genesis state Jan 19, 2024
LHerskind added a commit that referenced this issue Aug 27, 2024
This PR add support for using Aztec slot durations that are not just 1
ethereum slot.

To do so it adds more logic to the sequencer such that they can figure
out if they are really the sequencer or not.
This is mainly in the `canProposeBlock` and `shouldProposeBlock`
functions which respectively assert that the proposer can actually
propose, and whether he should. The logic in those functions are partly
what we had sprinkled over the code before, but also adding some
additional checks to match what is in the rollup contract and Leonidas.

Since there are now additional restrictions to block production related
to WHEN the block is to land on L1, I have added a `commitTimeJump`
function into the `l1-publisher`which will jump to the next slot after a
block have been published. This functionality toggled with a
`TIME_TRAVELER` boolean flag.

Note that we will jump INTO the next slot, since simulations in `viem`
and `anvil` are limited to run on block values in the bast, meaning that
we cannot nicely just simulate as if it was included in the NEXT block
which is what we ideally want. See issue #8110 for more information.

Since it caused some issues that there was no actual genesis state (just
0), I have inserted a genesis state equal to what we compute as the
`lastArchive` for the very first block, fixing #4148.

To not mess too much with DEVNET, the extra logic related to the exact
timing of when L2 blocks should make it onto L1 can be "toggled" with
the `IS_DEV_NET` flag.

Namely, if `IS_DEV_NET` is toggled, we can publish outside of the
"current" slot, as long as the slots are in order. With the changes in
this pr, we should be able to run DEVNET without `automine`, I have
tried a minor test but that seemed to work fine when we have
`AZTEC_SLOT_DURATION = 36` and internal mining :)

Points of interest:
- `sequencer.ts`
	- `canProposeBlock`
	- `shouldProposeBlock`
- `l1-publisher.ts`
- Adding `simulate` since viem `write` does not provide meaningful error
messages, but `simulate` does.
- The `commitTimeJump` won't happen if the `AZTEC_SLOT_DURATION =
ETHEREUM_SLOT_DURATION` or `TIME_TRAVELER = false`
- `sequencer.test.ts`
- Some of the test naming a odd. For example the test `builds a block
that contains zero real transactions once flushed` sounds to me like you
expect to have an empty block, after the block flushed, e.g., once
flushed make it sound like it already happened
- `l1-publisher.test.ts`
- `does not publish if last archive root is different to expected` is
deleted, as that job falls on the sequencer. The sequencer should define
whether or not it will send a tx, and publisher deals more with
publishing tasks.
- Adding a `simulate` that is also mocked to account for `simulate` in
the publisher.
- `e2e_p2p_network.test.ts`
- There is a flag for using a local anvil chain that you are running in
another terminal. This is useful for running internal mining etc.


--- 

This PR will be run with `AZTEC_SLOT_DURATION = 12` and `IS_DEV_NET =
true`. Note that when using values different from those, there are still
some hiccups and kinks, but it should be addressed in a separate PR to
not make this explode in size.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

1 participant