feat: implement basic L1 support with commitment #575

itegulov · 2025-02-03T06:54:23Z

What 💻

First part of #536

This PR implement L1 sidecar: an independent service that can initialize, run and query an L1 network. I tried to design it with some extendibility in mind but for now it can only spawn a built-in anvil with precomputed state.

L1 sidecar can:

generate commitments (with dummy values but in theory the only blocker here is zksync_kzg crate using unstable Rust)
encode data to ABI as expected by L1 contracts (powered by alloy-sol macro)
send commitments to L1

To try this out run cargo run --release -- --l1-anvil-port 8012 and then commit batch like this:

curl http://localhost:8011 \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"method":"anvil_commitBatch","params":[1],"id":1,"jsonrpc":"2.0"}

Additionally I updated our branch of era-contracts: disabled system log validation and DA input validation (only for commitment, will extend it further as need be).

Needs popzxc/alloy-zksync#47 for testing. Tests are pretty bare bones for now but I am hoping to do more on that front further down the line.

Why ✋

First step towards having L1-L2 communication

l1-setup/configs/apps/portal.config.json

l1-setup/configs/erc20.yaml

l1-setup/chains/anvil/configs/general.yaml

dutterbutter · 2025-02-03T17:45:50Z

crates/cli/src/main.rs

+    let mut node_service_tasks: Vec<Pin<Box<dyn Future<Output = anyhow::Result<()>>>>> = Vec::new();
+    let l1_sidecar = match config.l1_anvil_port {
+        Some(l1_anvil_port) => {
+            let (l1_sidecar, l1_sidecar_runner) = L1Sidecar::builtin(l1_anvil_port).await?;
+            node_service_tasks.push(Box::pin(l1_sidecar_runner.run()));
+            l1_sidecar
+        }
+        None => L1Sidecar::none(),
+    };


Do we want L1-L2 support enabled by default rather then be toggled via l1-port option? Perhaps this is intentional right now?

I thought about something --with-l1 (that will be false by default until the feature is polished), and then --l1-port etc to affect how anvil is launched.

Agreed that it should be disabled by default. Went with options as per @popzxc's suggestion for now. Also I put them under "UNSTABLE - L1" header so hopefully it's clear enough that those are subject to change.

dutterbutter · 2025-02-03T17:49:47Z

@itegulov awesome work good sir 💪 !

Understandably this will happen iteratively but devs wont be required to manually send a anvil_commitBatch to start using anvil-zksync with L1/L2 support, correct? That is we would make that request automatically during start up by default in the future?

crates/config/src/config.rs

popzxc · 2025-02-04T06:10:53Z

crates/cli/src/main.rs

+    let mut node_service_tasks: Vec<Pin<Box<dyn Future<Output = anyhow::Result<()>>>>> = Vec::new();
+    let l1_sidecar = match config.l1_anvil_port {
+        Some(l1_anvil_port) => {
+            let (l1_sidecar, l1_sidecar_runner) = L1Sidecar::builtin(l1_anvil_port).await?;
+            node_service_tasks.push(Box::pin(l1_sidecar_runner.run()));
+            l1_sidecar
+        }
+        None => L1Sidecar::none(),
+    };


I thought about something --with-l1 (that will be false by default until the feature is polished), and then --l1-port etc to affect how anvil is launched.

popzxc · 2025-02-04T06:18:51Z

l1-setup/bin/anvil_v0.3.0_darwin_amd64

Storing 80mb in the repository seems like a bad idea :(
I dunno, the longer I think about it, the more I'm leaning towards just biting the bullet and adding anvil as a dependency.

Done. +4k lines in Cargo.lock is not ideal but this approach does simplify a couple of things :)

popzxc · 2025-02-04T06:42:32Z

l1-setup/etc/env/file_based/general.yaml

@@ -0,0 +1,388 @@
+postgres:


I think we should find a way to not include the configs into the repository.
Instead, we probably can use zkstack dev config-writer to apply overrides only.

I have revamped l1-setup script to create an ecosystem from scratch and then patch it via yq (as we discussed in DMs). Feels a lot cleaner, PTAL

@dutterbutter this should also address your comments above so I resolved them, PTAL

l1-setup/yarn.lock

popzxc

Now configs certainly look much better!

popzxc · 2025-02-10T08:47:04Z

crates/api_decl/src/namespaces/anvil_ext.rs

+use jsonrpsee::proc_macros::rpc;
+use zksync_types::{L1BatchNumber, H256};
+
+#[rpc(server, namespace = "anvil")]


Discussion point: what is appropriate namespace?

anvil -- pro is that it's a "natural" scope, con is that it's an extension that will not be covered in anvil docs.

anvil_zksync -- pro is that it's super explicit, con is that we start having too many namespaces

zks -- pro is that it's zksync-native namespace, con is that it's not available on the main node.

Subjectively I'm leaning towards zks.

One counter-argument of extending zks: presumably we won't stop at commit/prove/execute (which are all clearly testing-related) so we might create false expectations of some of the future methods being available on ENs.

Either of the first two options seem fine to me. Slightly leaning toward a new namespace as I hated what early ETH tooling has done to the evm namespace lol. We could shorten anvil_zksync to anvil_zks for brevity if that helps

anvil_zks ftw

itegulov · 2025-02-11T06:38:51Z

Understandably this will happen iteratively but devs wont be required to manually send a anvil_commitBatch to start using anvil-zksync with L1/L2 support, correct? That is we would make that request automatically during start up by default in the future?

You don't need to send commit batch request to start using L1/L2 support in a sense that this is not a one time thing. You have to do it for every batch you want to eventually execute/finalize. anvil_commitBatch is just a very manual mechanism for controlling how anvil-zksync communicates with L1. I imagine further down the line we will have automatic/intervalled {commit,prove,execute} modes just like the ones we have for block sealing.

itegulov added 2 commits February 2, 2025 23:37

add l1 setup guide with pre-generated artifacts

132ec22

use contracts with disabled commit verification

ab70dea

itegulov requested review from popzxc and dutterbutter February 3, 2025 06:54

itegulov requested a review from a team as a code owner February 3, 2025 06:54

itegulov added 5 commits February 3, 2025 18:45

implement l1 support through foundry anvil

349b909

use copied version of IExecutor.sol

217202b

make L1 anvil optional

8e9c93c

redirect L1 stdout to a file

3e01b91

add some sanity check tests

dec25a4

itegulov force-pushed the daniyar/basic-l1-support branch from 2bea19e to dec25a4 Compare February 3, 2025 07:45

Merge branch 'main' into daniyar/basic-l1-support

7b9116b

dutterbutter requested changes Feb 3, 2025

View reviewed changes

l1-setup/configs/apps/portal.config.json Outdated Show resolved Hide resolved

l1-setup/configs/erc20.yaml Outdated Show resolved Hide resolved

l1-setup/chains/anvil/configs/general.yaml Outdated Show resolved Hide resolved

dutterbutter reviewed Feb 3, 2025

View reviewed changes

crates/config/src/config.rs Outdated Show resolved Hide resolved

popzxc reviewed Feb 4, 2025

View reviewed changes

itegulov added 2 commits February 10, 2025 18:23

vastly simplify l1-setup process

5c6237d

proper CLI option for L1 support + printing L1 config for user

cf3c483

popzxc reviewed Feb 10, 2025

View reviewed changes

itegulov added 3 commits February 10, 2025 20:36

adapt e2e tests to new cli options

bcfc5fe

migrate to anvil dependency

33c3167

revert alloy-zksync bump

3ee64ed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: implement basic L1 support with commitment #575

feat: implement basic L1 support with commitment #575

itegulov commented Feb 3, 2025 •

edited

Loading

dutterbutter Feb 3, 2025

popzxc Feb 4, 2025

itegulov Feb 10, 2025

dutterbutter commented Feb 3, 2025

popzxc Feb 4, 2025

popzxc Feb 4, 2025

itegulov Feb 11, 2025

popzxc Feb 4, 2025

itegulov Feb 10, 2025

popzxc left a comment

popzxc Feb 10, 2025

itegulov Feb 10, 2025

popzxc Feb 11, 2025

itegulov commented Feb 11, 2025

feat: implement basic L1 support with commitment #575

Are you sure you want to change the base?

feat: implement basic L1 support with commitment #575

Conversation

itegulov commented Feb 3, 2025 • edited Loading

What 💻

Why ✋

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dutterbutter commented Feb 3, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

popzxc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

itegulov commented Feb 11, 2025

itegulov commented Feb 3, 2025 •

edited

Loading