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

feat(zkstack): Split chain and ecosystem layers #3199

Open
wants to merge 62 commits into
base: main
Choose a base branch
from

Conversation

matias-gonz
Copy link
Collaborator

@matias-gonz matias-gonz commented Oct 30, 2024

What ❔

Move commands into chain subcommand:

zkstack server -> zkstack chain server
zkstack consensus -> zkstack chain consensus
zkstack contract-verifier -> zkstack chain contract-verifier

Now it is possible to run zkstack chain create without having an ecosystem.
Also run zkstack chain init without ecosystem by providing a path to l1 wallets and l1 contracts configs.

@matias-gonz matias-gonz changed the title feat(zkstack): [wip] Move commands into chain subcommand feat(zkstack): Move server, contract-verifier and consensus commands into chain subcommand Oct 31, 2024
@matias-gonz matias-gonz marked this pull request as ready for review October 31, 2024 13:49
@matias-gonz matias-gonz requested a review from a team as a code owner October 31, 2024 13:49
@matias-gonz matias-gonz changed the title feat(zkstack): Move server, contract-verifier and consensus commands into chain subcommand feat(zkstack): Move server, contract-verifier and consensus commands into chain command Nov 13, 2024
Deniallugo
Deniallugo previously approved these changes Nov 14, 2024
@@ -26,7 +26,7 @@ use crate::{
};

pub async fn run(args: InitConfigsArgs, shell: &Shell) -> anyhow::Result<()> {
let ecosystem_config = EcosystemConfig::from_file(shell)?;
let ecosystem_config = ZkStackConfig::ecosystem(shell)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we shouldn't use it here.
We need it only for port reallocation.
It'd be better to pass zkstack config here and if ecosystem is available do reallocation and if not, use default one

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also need ecosystem for contracts config, this is fixed in a next PR:
#3231

## What ❔

<!-- What are the changes this PR brings about? -->
<!-- Example: This PR adds a PR template to the repo. -->
<!-- (For bigger PRs adding more context is appreciated) -->

## Why ❔

<!-- Why are these changes done? What goal do they contribute to? What
are the principles behind them? -->
<!-- Example: PR templates ensure PR reviewers, observers, and future
iterators are in context about the evolution of repos. -->

## Checklist

<!-- Check your PR fulfills the following items. -->
<!-- For draft PRs check the boxes as you complete them. -->

- [ ] PR title corresponds to the body of PR (we generate changelog
entries from PRs).
- [ ] Tests for the changes have been added / updated.
- [ ] Documentation comments have been added / updated.
- [ ] Code has been formatted via `zkstack dev fmt` and `zkstack dev
lint`.
## What ❔

<!-- What are the changes this PR brings about? -->
<!-- Example: This PR adds a PR template to the repo. -->
<!-- (For bigger PRs adding more context is appreciated) -->

## Why ❔

<!-- Why are these changes done? What goal do they contribute to? What
are the principles behind them? -->
<!-- Example: PR templates ensure PR reviewers, observers, and future
iterators are in context about the evolution of repos. -->

## Checklist

<!-- Check your PR fulfills the following items. -->
<!-- For draft PRs check the boxes as you complete them. -->

- [ ] PR title corresponds to the body of PR (we generate changelog
entries from PRs).
- [ ] Tests for the changes have been added / updated.
- [ ] Documentation comments have been added / updated.
- [ ] Code has been formatted via `zkstack dev fmt` and `zkstack dev
lint`.
@matias-gonz matias-gonz changed the title feat(zkstack): Move server, contract-verifier and consensus commands into chain command feat(zkstack): Split chain and ecosystem layers Nov 27, 2024
Copy link
Collaborator

@sanekmelnikov sanekmelnikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matias-gonz, would it be reasonable to ask you to fill in the description [What, Why]? :)
Since it's a breaking change, I think it would be useful to list all the commands that will stop working (zkstack server -> zkstack chain server, etс.)

@Deniallugo, @matias-gonz
So I've been trying out these changes and I guess I don't understand what problem are we trying to solve or what use-case are we trying to improve?

  1. If we want to deploy a brand-new ecosystem, I don't see much value separating ecosystem and chain. imho, the current setup works really well for that case.
  2. If we are working with the ecosystem, that already exists:
    2.1) if ecocsystem is on localhost: I don't see how zkstack chain create/init is easier to use outside of the ecosystem - because I need to provide contracts/wallets file and path to code. It's much easier to run the same commands from the ecosystem folder.
    2.2) if ecosystem is ZKSync's Sepolia/Mainnet: zkstack ecosystem import --from mainnet in my view would be better way to go since contracts/wallet (addresses) can be populated for you
    2.3) if ecosystem is not ZKSync's Sepolia/Mainnet: that's probably the only use-case that will be improved, although I'd still prefer zkstack ecosystem import --from [FILE] followed by zkstack chain create etc. and also that's the least common use-case.
    I think the fundamental problem is that we have ecosystem and chain command tightly coupled together, but making it easy to import existing ecosystem with a separate command is a more straightforward way to go?

The biggest problem with this PR is that all of these currently aren't working for chain-only folder:

  • zkstack portal
  • zkstack explorer
  • zkstack update
  • zkstack external-node
  • zkstack containers
  • zkstack prover

As well as:

  • zkstack chain init configs

As for zkstack chain server vs zkstack server: do we really think it's worth breaking for all the users? For chain-only folders zkstack chain server makes less sense than zkstack server since obviously everything we're going to run will be chain-related. Can we support both?

.map(|ecosystem| ecosystem.list_of_chains().len() as u32)
.unwrap_or(0);

let internal_id = ecosystem.as_ref().map_or(0, |_| number_of_chains + 1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor]: 0 -> 1, i'd use the same way we numerate in ecosystem

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is it used anywhere apart from calculating ports?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#3210 (comment)
We decided to keep it as 0

#[clap(long, help = MSG_ECOSYSTEM_CONTRACTS_PATH_HELP)]
pub ecosystem_contracts_path: Option<String>,
#[clap(long, help = MSG_WALLETS_PATH_HELP)]
pub wallets_path: Option<String>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it ecosystem_wallets_path?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 115 to 116
let rocks_db_path = chain_path.join(LOCAL_DB_PATH);
let artifacts = chain_path.join(LOCAL_ARTIFACTS_PATH);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for chain-only folders this leads to the structure:
{chain_name}/{chain_name}/db
vs in ecosystem based:
chains/{chain_name}/db
Are we intentionally adding one more layer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matias-gonz please check it

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I introduced this bug, working on it!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanekmelnikov
Copy link
Collaborator

Ah, with chain registrar changes though, I can see the value for external chains.
You basically will be able to:
zkstack chain create
zkstack chain init configs (don't even need to pass the ecosystem wallets)
zkstack chain registration send-proposal
zkstack chain accept-ownership
and you are good to go.

## What ❔

<!-- What are the changes this PR brings about? -->
<!-- Example: This PR adds a PR template to the repo. -->
<!-- (For bigger PRs adding more context is appreciated) -->

## Why ❔

<!-- Why are these changes done? What goal do they contribute to? What
are the principles behind them? -->
<!-- Example: PR templates ensure PR reviewers, observers, and future
iterators are in context about the evolution of repos. -->

## Checklist

<!-- Check your PR fulfills the following items. -->
<!-- For draft PRs check the boxes as you complete them. -->

- [ ] PR title corresponds to the body of PR (we generate changelog
entries from PRs).
- [ ] Tests for the changes have been added / updated.
- [ ] Documentation comments have been added / updated.
- [ ] Code has been formatted via `zkstack dev fmt` and `zkstack dev
lint`.
## What ❔

<!-- What are the changes this PR brings about? -->
<!-- Example: This PR adds a PR template to the repo. -->
<!-- (For bigger PRs adding more context is appreciated) -->

## Why ❔

<!-- Why are these changes done? What goal do they contribute to? What
are the principles behind them? -->
<!-- Example: PR templates ensure PR reviewers, observers, and future
iterators are in context about the evolution of repos. -->

## Checklist

<!-- Check your PR fulfills the following items. -->
<!-- For draft PRs check the boxes as you complete them. -->

- [ ] PR title corresponds to the body of PR (we generate changelog
entries from PRs).
- [ ] Tests for the changes have been added / updated.
- [ ] Documentation comments have been added / updated.
- [ ] Code has been formatted via `zkstack dev fmt` and `zkstack dev
lint`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants