matter-labs / foundry-zksync

Fork of Foundry tailored for zkSync environment

Foundry with zkSync Era v0.2-alpha

This repository enhances Foundry to support zkSync Era, enabling Solidity-based compilation, deployment, testing, and interaction with smart contracts on zkSync Era.

🔧 Fork Notice: This is a Foundry fork with added zkSync support.

⚠️ Alpha Stage: The project is in alpha, so you might encounter issues.

🐞 Found an Issue? Please report it to help us improve.

Changes Made

To use for zkSync environments, include --zksync when running forge or vm.zkVm(true) in tests. The modifications include:

1. Compilation: solc and zksolc are used for compiling. The resulting bytecodes are combined into DualCompiledContract and managed through Executor to CheatcodeTracer.
2. EVM Interactions:
   • EVM calls are standard except for address.balance and block.timestamp/block.number, which pull data from zkSync (ZK-storage and ZK-specific context, respectively).
3. Transaction Handling:
   • CALL and CREATE operations are captured and converted to zkSync transactions. This process includes fetching zkSync-equivalent bytecode, managing account nonces, and marking EOA appropriately to comply with zkSync requirements.
4. Execution and State Management:
   • zkSync VM processes the transaction and returns state changes, which are applied to journaled_state. Results are relayed back.
5. Logging:
   • console.log() outputs within zkSync VM are captured and displayed in Foundry.
   • ZK_DEBUG_RESOLVE_HASHES and ZK_DEBUG_SHOW_OUTPUTS env variable may be set to true to display zkSync VM call logs with resolved selector hashes (requires Internet connection), and the call outputs, respectively.
6. Fuzzing
   • Adds config option no_zksync_reserved_addresses. Since zkSync reserves addresses below 2^16 as system addresses, a fuzz test would've required a broad vm.assume and many vm.excludeSender calls to exclude these. This is not only cumbersome but could also trigger proptest's global max_global_rejects failure. When this option is set to true the proptest generation itself ensures that no invalid addresses are generated, and thus need not be filtered adding up to the max_test_rejects count.

📊 Features & Limitations

Features

Foundry-zksync offers a set of features designed to work with zkSync Era, providing a comprehensive toolkit for smart contract deployment and interaction:

• Smart Contract Deployment: Easily deploy smart contracts to zkSync Era mainnet, testnet, or a local test node.
• Contract Interaction: Call and send transactions to deployed contracts on zkSync Era testnet or local test node.
• Solidity Testing: Write tests in Solidity, similar to DappTools, for a familiar testing environment.
• Fuzz Testing: Benefit from fuzz testing, complete with shrinking of inputs and printing of counter-examples.
• Remote RPC Forking: Utilize remote RPC forking mode, leveraging Rust's asynchronous infrastructure like tokio.
• Flexible Debug Logging: Choose your debugging style:
  • DappTools-style: Utilize DsTest's emitted logs for debugging.
  • Hardhat-style: Leverage the popular console.sol contract.
• Configurable Compiler Options: Tailor compiler settings to your needs, including LLVM optimization modes.

Limitations

While foundry-zksync is alpha stage, there are some limitations to be aware of:

• Compile Time: Some users may experience slower compile times.

• Compiling Libraries: Compiling non-inlinable libraries requires deployment and adding to configuration. For more information please refer to official docs.

  libraries = [
      "src/MyLibrary.sol:MyLibrary:0xfD88CeE74f7D78697775aBDAE53f9Da1559728E4"
  ]
  

• Create2 Address Derivation: There are differences in Create2 Address derivation compared to Ethereum. Read the details.

• Contract Verification: Currently contract verification via the --verify flag do not work as expected but will be added shortly.

• Specific Foundry Features: Currently features such as --gas-report, --coverage may not work as intended. We are actively working on providing support for these feature types.

• Solc Compatibility: zksolc requires a solc binary to be run as a child process. The version/path to use for each can be specified by the zksolc and solc options in foundry.toml. Not all solc versions are supported by all zksolc versions, compiling with a solc version higher than the one supported may lead to unexpected errors. Read the docs about version limitations and check the zksolc changelog to see the latest supported solc version.

For the most effective use of our library, we recommend familiarizing yourself with these features and limitations.

Quick Install

Follow these steps to quickly install the binaries for foundry-zksync:

Note: This installation overrides any existing forge and cast binaries in ~/.foundry. You can use forge without the --zksync flag for standard EVM chains. To revert to a previous installation, follow the instructions here.

1. Clone the Repository: Begin by cloning the foundry-zksync repository from GitHub. This will download the latest version of the source code to your local machine.

   git clone [email protected]:matter-labs/foundry-zksync.git

2. Change Directory: Navigate into the directory where the repository has been cloned. This is where you will run the installation commands.

   cd foundry-zksync

3. Run the Installer: Now, you're ready to execute the installation script. This command initializes the setup and installs foundry-zksync binaries forge and cast.

   ./install-foundry-zksync

4. Verify the Installation (Recommended): After installation, it's good practice to verify that the binaries have been installed correctly. Run the following command to check the installed version:

   forge --version

This should return the installed version of forge, confirming that foundry-zksync is installed properly on your system.

📝 Development Prerequisites

Ensure you have the necessary tools and environments set up for development:

1. Install Rust: Use the command below to install Rust. This will also install cargo, Rust's package manager and build system.

   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

2. Set Rust to Nightly Toolchain: This project requires Rust's nightly version from September 30, 2023. Set your Rust toolchain to the appropriate nightly version using rustup:

   # Replace `<YOUR-TARGET>` with your specific platform target, e.g., `x86_64-unknown-linux-gnu`
   rustup install nightly-2023-09-30-<YOUR-TARGET>
   
   # Example for MacOS (Apple Silicon):
   rustup install nightly-2023-09-30-aarch64-apple-darwin

3. MacOS Prerequisite - Install make: MacOS users need to ensure make is installed. If not, install it using Homebrew:

   brew install make

   Then, set the path to GNU make:

   # For x86_64 MacOs users:
   # export PATH="/usr/local/opt/make/libexec/gnubin:$PATH"
   export PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"

   Add this export line to your shell profile (~/.bash_profile, ~/.zshrc, etc.) to make the change permanent.

💾 Installation

Each tool within our suite can be installed individually, or you can install the entire suite at once.

Installing forge 🛠️

To install forge, execute the command below. This action will overwrite any previous forge installations, but the functionality remains consistent. Post-installation, forge will be accessible as an executable from ~/.cargo/bin.

Run the following command:

cargo install --path ./crates/forge --profile local --force --locked

Installing cast 📡

Similarly, to install cast, use the following command. Like forge, this will replace any existing cast installations without altering functionality. Once installed, cast becomes available as an executable in ~/.cargo/bin.

Run the following command:

cargo install --path ./crates/cast --profile local --force --locked

Installing the Entire Suite 📦

To install all the tools in the suite:

cargo build --release

Quickstart

In an empty directory, run the following command:

forge init

Let's check out what forge generated for us:

$ tree . -d -L 1
.
├── lib
├── script
├── src
└── test

Compiling contracts

We can build the project with forge build --zksync:

$ forge build --zksync
Compiling smart contracts...
Compiled Successfully

Deploying missing libraries

In case missing libraries are detected during the compilation, we can deploy them using the following command:

$ forge create --deploy-missing-libraries --private-key <PRIVATE_KEY> --rpc-url <RPC_URL> --chain <CHAIN_ID> --zksync

After deployment is done, the configuration file will be updated and contracts will be automatically compiled again.

Running Tests

You can run the tests using forge test --zksync.

The command and its expected output are shown below:

$ forge test --zksync

Ran 2 tests for test/Counter.t.sol:CounterTest
[PASS] testFuzz_SetNumber(uint256) (runs: 256, μ: 8737, ~: 8737)
[PASS] test_Increment() (gas: 8702)
Suite result: ok. 2 passed; 0 failed; 0 skipped; finished in 3.57s (3.56s CPU time)

Ran 1 test suite in 3.57s (3.57s CPU time): 2 tests passed, 0 failed, 0 skipped (2 total tests)

Configuration

Using foundry.toml

Foundry is designed to be very configurable. You can configure Foundry using a file called foundry.toml in the root of your project, or any other parent directory. See config package for all available options.

Configuration can be arbitrarily namespaced by profiles. The default profile is named default (see "Default Profile").

You can select another profile using the FOUNDRY_PROFILE environment variable. You can also override parts of your configuration using FOUNDRY_ or DAPP_ prefixed environment variables, like FOUNDRY_SRC.

forge init creates a basic, extendable foundry.toml file.

To see your current configuration, run forge config. To see only basic options (as set with forge init), run forge config --basic. This can be used to create a new foundry.toml file with forge config --basic > foundry.toml.

By default forge config shows the currently selected foundry profile and its values. It also accepts the same arguments as forge build. An example foundry.toml for zkSync with zksolc configurations may look like:

[profile.default]
src = 'src'
out = 'out'
libs = ['lib']

[profile.default.zksync]
compile = true
fallback_oz = true
mode = '3'

Additional Configuration

You can find additional setup and configurations guides in the Foundry Book:

• Setting up VSCode
• Shell autocompletions

Contributing

See our contributing guidelines.

Acknowledgements

• Foundry is a clean-room rewrite of the testing framework DappTools. None of this would have been possible without the DappHub team's work over the years.
• Matthias Seitz: Created ethers-solc which is the backbone of our compilation pipeline, as well as countless contributions to ethers, in particular the abigen macros.
• Rohit Narurkar: Created the Rust Solidity version manager svm-rs which we use to auto-detect and manage multiple Solidity versions.
• Brock Elmore: For extending the VM's cheatcodes and implementing structured call tracing, a critical feature for debugging smart contract calls.
• All the other contributors to the ethers-rs & foundry repositories and chatrooms.

Acknowledgments - foundry-zksync

• Moonsong Labs: Implemented zkSync support, and resolved a number of different challenges to enable zkSync support.

foundry-zksync's Issues

Move zkbuild specific flags to the zk-build module

Info

Convert String based Paths to std::path::Paths

Info

This is needed to ensure os safety regarding os specific delimiters when parsing paths

Implement flags and configuration files for operational settings in terms of zksync

Info

The configuration file will be able to implement settings like the zksolc compiler version in which forge/foundry will operate upon. Flags normally are used as overrides to such configurations.

Config

Hardhat compile config

zksolc: {
  version: "1.3.8",
  compilerSource: "binary",  // binary or docker (deprecated)
  settings: {
    compilerPath: "zksolc",  // optional. Ignored for compilerSource "docker". Can be used if compiler is located in a specific folder
    experimental: {
      dockerImage: "matterlabs/zksolc", // Deprecated: used for compilerSource: "docker"
      tag: "latest"   // Deprecated: used for compilerSource: "docker"
    },
    libraries:{}, // optional. References to non-inlinable libraries
    isSystem: false, // optional.  Enables Yul instructions available only for zkSync system contracts and libraries
    forceEvmla: false, // optional. Falls back to EVM legacy assembly if there is a bug with Yul
    optimizer: {
      enabled: true, // optional. True by default
      mode: '3' // optional. 3 by default, z to optimize bytecode size
    } 
  }
}
networks: {
  hardhat: {
    zksync: true  // enables zksync in hardhat local network
  }
}

Understand and implement all new flags for the zksolc compiler alike hardhat

Info

Let's checkout hardhat and ensure we have feature parity in terms of the compiler settings. This is more directly oriented with the features of the compiler itself, and what we need to consider when employing implementations.

Convert String based Paths to std::path::Paths

Info

This is needed to ensure os safety regarding os specific delimiters when parsing paths

Implement Force EVMLA Flag

Implement --force-evmla flag so that we can set the EVM legacy assembly pipeline forcibly

Forge Testing assessment

Overview

This document is meant to specify the findings and needs in regards to testing. Some of the main take aways are:

---

Overview of Current Capabilities

• Compile Solidity smart contracts with zksolc compiler and store artifacts
• Deploy Solidity smart contracts to zksync
• Non-state Changing calls
• State changing Transactions
• L1 -> L2 Deposits
• L2 -> L1 Withdrawals
• Spin up and interact with Local ZkSync Node
• Perform all above activities on Local Node

Compiler update

• Since zksolc v1.3.6 was released, compile contracts that contain imported contracts using the --combined-json flag have not been compiling. See Issue
• UPDATE: now using --standard-json flag without issue.

How Forge Unit Testing Works

General understanding

• Forge test files are essentially smart contracts that are temporarily deployed on a local instance of revm, along with the contracts being tested. Once tests are complete, state does not persist, and trace logs are provided in the console.
• Forge Test command has a fork-url option that pulls down the state of a blockchain (local, testnet or mainnet) and tests can be executed against said state, using the native revm in Foundry Backend. Currently the state is successfully being forked by Foundry but unable to complete the tests against the native revm, because it should be using the zkevm

Solution:

• For the unit test to properly function we would need to deploy the test contracts to a local zkevm (Could this repo be a possible alternative?) instance to replace the revm currently being used by Foundry Backend. There are plenty of assumptions that would need to be sorted through.

Implications

• substantial amount of development would be required to achieve testing and/or scripting capabilities.
• zkevm would need to be integrated locally in the Foundry Backend
• transaction would need to be built according to zksync specs, before test execution
• zkevm output needs to be either routed through Foundry log tracing if compatible or a zksync specific tracing library would need to be developed

How Forge Scripts Work

• Scripts might be a good way to go about a integration style test against live nodes but currently the testing suite does not execute transactions from forge scripting .
• Similar to Forge Tests, the contract script is run in a local evm, If a rpc/fork url has been provided, it will execute the script in that context. but will be run on the Foundry Backend Local EVM.

Solution:

• Solution is very similar to the Forge Test solution as the same native revm backend is utilized to accomplish desired functionality.
• A local instance of zkevm would need to be integrated to the Foundry backend

Local Node Update

• A local ZkSync node may be instantiated by following the local-setup instructions
• Once up and running, the developer may deploy contracts that persist using forge create, receive the newly deployed contract address and can interact by using cast call and cast send to accomplish:
• • Deployment
• • Contract Interaction
• • L1/L2 Deposits and Withdrawals

Questions

• Does Matter Labs have testing with tracing libraries written for Rust?
• can a local zkEvm instance be used for non persistent contract testing without spinning a local node?
• If so, will the postgress db be needed or can we use the Foundry DB?
• Can testing be performed against the local node with tracing capabilities?

Implement figment provider for the zk-create cmd

Info

Takes care of these 2 issues:

• #40
• #11

Implement ASM Flag

Implement --asm so that we can output the zkEVM assembly of each of the contracts

Get code organized and resynced with the foundry base branch

Info

Get all the commits organized and merged with our forks branch. Rebase the base branch to ensure our fork is up to date.

• Remove the old pathways and code once we feature complete
• Understand and rebase into a fork if need be (to be determined)

Clean old code and fix all compiler warnings

Write beautified json to zkout after compilation

Deposits & withdrawals

Component

No response

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

No response

What command(s) is the bug in?

No response

Operating System

None

Describe the bug

• deposit example doesn't work (is it pointing at the right URL? - shouldn't it point at L1?)
• withdrawal example: nitpick, but the amount of ETH is not in ETH but in wei?

Use semversion instead of string for zksolc compiler

Info

Currently using a string for the zksolc-manager, we should refactor to use semversion

Implement Yul Flag

Implement --yul flag so that we can switch to Yul mode

Implement a solc mod that calls and manages the configuration for running the compiler

Info

Implement a solc module that calls and manages the configuration for running the locally downloaded compiler. This will primarily source its configuration from the foundry.toml. We'll want to address overrides via flags in a later issue.

Implement Standard JSON Flag

Implement standard JSON flag so that we can switch to Standard JSON input / output mode.

Implement a zk-cast-send control flow to isolate that logic in its own specific place

Info

// todo

Implement Bin Flag

Implement --zkEVM flag so we can output zkEVM bytecode of the contracts

2/8/23 Update

Overview

To include smart contract compilation, testing, deployment and interaction capabilities to zkSync Layer 2 blockchain to the Foundry toolchain. Some main differences are:

• ZkSync uses a different compiler that must be integrated (zksolc vs solc).
• Deployment process requires addition of factory deps field to deployment payload
• Deployment optionally includes eip721 transactions for additional fields like paymaster address or custom signatures

---

Implementation Updates

Compiling

Status

We are effectively compiling the Solidity Contract with xksolc v1.3.0 to an output folder alike the functionality of Foundry against the Ethereum mainnet. We are using a flag called --zksync to effectively choose the zksync compiler and output artifacts are written to a directory within a standard Foundry project.

Example between Eth mainnet and ZySync:

# Eth main net
$ forge build
# ZkSync
$ forge build --zksync

Shortcomings

We are establishing a very happy path to use the ZkSync compiler that is implementing an entry point the command in a less than best practices way. This means when using the flag --zksync, we are very early in the architecture and the implementation of the control flow will change.

We should be more than likely using the Foundry config file to establish the ZkSync compiler instead, however, we're omitting this functionality for now.

The user must do some setup, for example, download and configure the ZkSync compiler in a less than streamlined way. Again will be punted until other happy established like the initiatives below.

Notes

todo

Deployment

Discovery

The discovery process has largely been through the examination of hardhat's plugins and library dependencies used to interact with the blockchain:

• Hardhat makes use of zksync-web3 package which has ethers-js as a dependency (both JavaScript). zksync-web3 abstracts a level above ethers-js.
• NOTE: Because there does not exist a Rust equivalent to zksync-web3, we will need to construct the functionality to handle these duties in Rust (hashing of bytecode, encoding function data, appending factory deps, preparing eip721 transactions, etc).

Status

Currently a command line flag has been added to the ‘forge create’ command that triggers a function call to our new deploy_zksync() function, which will handle:

• Instantiation of a new ContractFactory (for hardhat, this was instantiated with zksync-web3 library)
• Constructor arguments will be built from zksolc compiled artifacts
• Prepare deployment transaction made to the ContractDeployer.sol system contract.

Example between Eth mainnet and ZySync:

# Eth main net
$ forge create
# ZkSync
$ forge create--zksync

Ideally user will be able to type: forge create --zksync and contracts will be successfully deployed to zkSync.

Shortcomings:

• Need to better understand how to interact with ContractDeployer.sol system contract
• Need to build equivalent functionality to zksync-web3 in Rust for deployment.

Contract Interaction

Not Started Yet

Solidity Scripting

Not Started Yet

---

implement better error handling for unsupported zksolc versions

Info

Currently when user enters an unsuppoprted zksolc vwersion we get a general error message:

Error building zksolc_manager: Could not build ZkSolcManager

We should try to make it something like:

Error building zksolc_manager: Unsupported zksolc compiler version

Implement Appropriate Error Handling

In order to get to an mvp, we avoided error handling. Let's make sure that each potential error is handled elegantly.

Implement zksolc-manager to manage zkolc binaries on a local filesystem

Sprint #1 Full Update (From Sprint #2 Project Plan)

ZkSync Sprint #2

Overview

This document provides an overview of the previously completed work for the ZkSync Foundry/Forge development environment. It also proposes continuing the Forge/Foundry ZkSync implementation while exploring other potential needs within the ZkSync ecosystem.

Although the project experienced some delays due to the learning curve associated with both the Forge/Foundry implementation and the ZkSync-specific aspects, we believe that we have made significant progress in both areas.

Issues to Address

It has been noted that PW could improve its ongoing communication. We acknowledge this concern and are committed to addressing and correcting it in the immediate future. Our plan for addressing this issue involves scheduling 15-minute standups, during which Ramon and any other members of the ZkSync team are welcome to join. In addition, we can arrange more formal syncs, either on a scheduled basis or in an ad-hoc manner, as needed.

Current State

Below is a list of the researched and completed feature sets implemented on the platform in its current state. It is important to note that some of the researched and completed features may require codebase cleanup and should be considered as happy path implementations. These are likely to be better organized as the project evolves.

Compilation

Current progress:

We can compile smart contracts using the zksolc compiler. This compiles the artifacts into the standard JSON format, offering greater flexibility compared to the combined JSON, which was the original implementation. This recent development allows us to utilize most of the existing Forge command line options for the forge build command where the zkevm is compliant.

Shortcomings:

Code cleanup is necessary, along with more standardized mechanisms like using the configuration file, supporting multiple compiler versions, and accommodating various operating systems. Currently, some hardcoded implementations enable this functionality, but the compiler version is not configured within the configuration file. Instead, we download the most recent version for the Linux-specific OS. Integration and testing for both OSX and Windows are needed. Additionally, we need to ensure the compiler version can be selected using both the configuration file and CLI.

Deployment

Current Progress:

We can deploy smart contracts with the forge create command that retrieves the compiled artifacts and bytecode compiled by the zkevm in the forge build command. It then builds the deployment transaction that is then ran to interact with the System Deployer contract on the ZkSync testnet. Once deployed, it retrieves the deployed contract address and logs it back to the user. We have the ability to deploy complex projects with multiple composed and inherited patterns. We can accomplish deployments on both the ZkSync testnet and local node on the docker setup.

Shortcomings:

Even though attempted, we have not yet successfully deployed a ZkSync specific implementation, for example, Account Abstraction. There is some code cleanup here in regards to config and cli.

Current Progress:

We can deploy smart contracts using the forge create command, which retrieves the compiled artifacts and bytecode generated by the zkevm in the forge build command. It then constructs the deployment transaction that interacts with the System Deployer contract on the ZkSync testnet. Once deployed, it retrieves the deployed contract address and reports it back to the user. We have the capability to deploy complex projects with multiple composed and inherited patterns. Deployments can be executed on both the ZkSync testnet and a local node using the Docker setup.

Shortcomings:

Despite our efforts, we have not yet successfully deployed a ZkSync-specific implementation, such as Account Abstraction. Some code cleanup is needed in regard to configuration and CLI.

Interaction

Current Progress:

We can interact with deployed contracts using Forge's cast call command on the ZkSync networks, just as we can with Ethereum networks. We can also facilitate L1 ↔ L2 transfers of assets.

We can submit transactions via the cast send command; however, this required implementing the zkevm library.

Shortcomings:

We need to conduct more comprehensive testing of L1 ↔ L2 interactions in all possible ways that ZkSync and Ethereum can communicate.

Testing

Current Progress:

We have spent some time investigating testing. The forge test command can only facilitate local unit test scenarios. Forge scripts would be the way to test solidity code against a standing network or node.

Shortcomings:

We have yet to facilitate a test scenario that involves ZkSync in any way; however, we do know the entry points for both the forge test and forge scripts run commands. The most effort will need to be spent in this area.

forge test: To run unit tests, we will need to use the Rust zkevm library within the codebase, which carries some risk due to its dependency on that library. We have observed in the past that it may or may not be stable. We also assume that we will want to focus on running L2-specific tests here. Facilitating L1 and L2 network testing has not been investigated yet.

forge scripts run: This command provides another avenue for facilitating testing. These tests would transact on real networks, such as the testnet and local Docker setup. We suspect that we might be able to facilitate testing between L1 and L2 networks, but it would likely require significant effort, if even possible.

Version 0.0

We need to establish the functionality we want for release v0.0 of this implementation. Below we will specify the exact features to accomplish our v0.0 release.

Feature Sets

• Compile smart contracts with zksolc compiler
• Deploy smart contracts to zkSync Testnet or Local Test Node
• Bridge assets L1 <-> L2
• Make contract calls to deployed contracts on zkSync Testnet or Local Test Node
• Send transactions to deployed contracts on zkSync Testnet or Local Test Node
• Spin up Local Test Node
• Run either unit tests or integration tests

Compilation

Compile smart contracts to zkEvm bytecode and store compile output files into a logical directory structure out/zksync/ for easy retrieval to other components of the application.

• Configuration/CLI
  • Support Command line input arguments that currently exist for forge build plus newly built zkSync specific command line arguments to support different compiler versions and operating systems via the standard configuration files and CLI flag overrides
• Managing Contracts for both networks
  • Currently we compile both EVM and zkEVM smart contracts when using the --zksync flag thus creating artifacts for both networks, keeping them separate yet organized in the output directory.

v0.0 Command:

forge build --zksync <CONTRACT_PATH>

Deployment

Manage deployments in the native foundry/forge fashion, using the forge create command.

• Prepare deployment transaction according to zkSync specifications using CL/Configuration files.
• Deploy to zkSync specified networks (zkSync Testnet or Local Docker Node) via --rpc-url and --chain-id flags
• Configuration/CLI
  • Support Command line input arguments that currently exist for forge create plus newly built zkSync specific command line arguments for a more seamless user experience. Examples: --rpc-url, --chain-id, --private-key, --zksync and more via the standard configuration files and CLI flag overrides

v0.0 Command:

forge create <CONTRACT_PATH> --constructor-args [CONSTRUCTOR_ARGS] --rpc-url <http://localhost:3050> --private-key <PRIVATE_KEY> --zksync <CHAIN_ID>

Interaction

Interact with deployed contracts in the native foundry/forge fashion using the CLI cast call and cast send commands>

• Retrieving and interacting with chain data, for example, block numbers and gas estimates
• Interact with deployed contracts on (zkSync Testnet or Local Docker Node)
• Bridging assets L1 ↔ L2 with --zksync-deposit and --zksync-withdraw
• Use proper configuration techniques describe above

v0.0 Commands:

Non-state changing calls:

cast call <CONTRACT_ADDRESS> <FUNCTION_SIG> --rpc-url zk-rpc

Send transactions:

cast send <CONTRACT_ADDRESS> <FUNCTION_SIG> <FUNCTION_ARGS> --rpc-url zk-sync --private-key <PRIVATE-KEY> --zksync

L1 → L2 deposits:

cast send --rpc-url <RPC-URL> --private-key <PRIVATE-KEY> --zksync-deposit <TO> <AMOUNT> <TOKEN>

L2 → L1 withdrawals:

cast send --rpc-url <RPC-URL> --private-key <PRIVATE-KEY> --zksync-withdraw <TO> <AMOUNT> <TOKEN>

Testing / Scripting (in progress)

Run both unit tests and integration tests in the forge/foundry native fashion.

• Unit Tests
  • Test L2 specific contracts and implementations against the in memory ZkEVM.
• Integration Tests
  • The tests could be triggered by something called forge scripts.

v0.0 Commands:

forge test [OPTIONS] --zksync

forge script [OPTIONS] <PATH> [ARGS]... --zksync

More info on progress here: #5

Need to comminucate and fix all zksync era sdk errors that force use to clone, change, and use locally

Info

When trying to import sdk in foundry/cli/cargo.toml

[dependencies]
zksync = {git = "https://github.com/matter-labs/zksync-era.git"}

Then attempting to build:

cargo build -p foundry-cli

returning error:

error[E0046]: not all trait items implemented, missing: `report_new_callstack_frame`
    --> /home/shakes/.cargo/git/checkouts/era-zkevm_test_harness-22d97ff2abf02d7d/cfac36a/src/witness/oracle.rs:1250:1
     |
1250 | impl<E: Engine> WitnessOracle<E> for VmWitnessOracle<E> {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `report_new_callstack_frame` in implementation
     |
     = help: implement the missing item: `fn report_new_callstack_frame(&mut self, _: &ExecutionContextRecord<E>, _: sync_vm::vm::primitives::UInt32<E>, _: &sync_vm::franklin_crypto::plonk::circuit::boolean::Boolean, _: &sync_vm::franklin_crypto::plonk::circuit::boolean::Boolean) { todo!() }`

For more information about this error, try `rustc --explain E0046`.
error: could not compile `zkevm_test_harness` due to previous error

Implement default for the solc-manager

Info

Implement the standard default implementation for the solc-manager

Foundry-zkSync update 2/24/2023 [WIP]

Overview

Implementation Updates

Compiling

Status

We continue to manually update zksolc: v1.3.5 compiler now downloads to <project-root>/zksolc folder

Shortcomings

• ideally we would like to programmatically check for most recent version of zksolc to download (currently version is hard coded)

Deployment

Status

Once dependencies were updated, progress was made in understanding the SDK provided by Matter Labs Team.
We have been able to successfully:

• Instantiate a Provider
• Instantiate a Signer
• Initiate Wallet
• Instantiate HTTP Client with rpc_url = https://zksync2-testnet.zksync.dev:443 (Wallet method required a Port number)
• Validate contract bytecode
• Using the Wallet, instantiate a DeployContractBuilder
• Populate Builder with contract bytecode and factory dependencies
• estimate gas fees for deployment

Contract Interaction

Not Started Yet

Solidity Scripting

Not Started Yet

---

Add more descriptive error messages

Info

For example, if a contract is attempted to be deployed befpore compiling 'building', it gives generic eror msg..

Unable to read file: Os { code: 2, kind: NotFound, message: "No such file or directory" }

this error should be more descriptive, such as missing artifacts for

Need to add logic to handle if the zksolc-manager does not have the proper dirs in the file system

ssh vs git dependencies

Component

No response

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

No response

What command(s) is the bug in?

No response

Operating System

None

Describe the bug

For me to follow the README.md to the cargo build -p foundry-cli step, I had to setup SSH keys for github.

This will be a major hurdle for newer devs.

Technically this isn't a "bug report" but it will be a major adoption hurdle, so a "Developer Experience Bug".

correctly parse function arguments to match function signature types

Info

Currently all function arguments passed in the command line are parsed as strings, We need to parse tham as the type needed for function argument

Download zksolc compiler based on configurable filename with env variables

Info

Currently we are downloading zksolc with hardcoded filename:

zksolc-linux-amd64-musl-v1.3.7

the filename can be configured as:

"zksolc-"<OS>"-"<ARCH>"-"<TOOLCHAIN>"-"<VERSION><EXTENSION>

Operating Sytem: {linux, macosx, windows}
Architecture: {amd64, arm64}
Toolchain: {"musl","gnu",""}
Version number: Current zksolc Version
Extension: {".exe", ""}

Nice to have

Detect most recent zksolc compiler version programmatically

Implement System Mode Flag

Implement the --system-mode flag. This enables system contract compilation mode

Understand and implement how we want to configure zksync compatible forge for external developers

Info

In its current state, we more than likely need developers to be able to use the main forge/foundry stack along side the zksync version without clashing. We'll probably opt to install a different binary for the zksync specific forge so developers can switch between the 2.

Notes

• Let's see how zksync handles hardhat current

zkforge create: confusing error message when deploying a contract

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

No response

What command(s) is the bug in?

zkforge create

Operating System

Linux

Describe the bug

After installing foundry-zksync and verifying that everything works with zkcast (balance, get-price, etc.). I've ran zkforge init and zkforge contract deploy cmd:
zkforge create src/Counter.sol:Counter --rpc-url https://zksync2-testnet.zksync.dev:443 --private-key "PK"

The error I get is confusing, not sure where to go from here

[⠒] Compiling...
[⠆] Installing solc version 0.8.13
[⠑] Successfully installed solc 0.8.13
No files changed, compilation skipped
Error:
(code: -32601, message: Method not found, data: None)

Implement LLVM IR Flag

Component

Forge

Describe the feature you would like

Implement the --llvm-ir flag that enables the cli to switch to the LLVM IR mode

Additional context

No response

Implement Force EVMLA Flag

Implement --force-evmla to set the evm legacy assembly pipeline forcibly.

make --is-system flag compatible with compiling all files in src

INFO

with this recent PR, we are compiling all contracts in src and nested folders. an issue arises when a user needs to use the --is-system flag. when used it will apply flag to all compilations, or if flag is not used it will compile without the flag for all files. so we need a way to distinguish what contracts need the is-system flag.

a Config file does not solve this problem because the --is-system flag is contract specific, not project specific

Possible solutions:

Add contract names after --is-sytem flag

if user has multiple solidity files but only a portion of them need to be compiled with the is-system flag, we can add feature to add contract names after the --is-system flag. drawbacks of this design mean that user must always enter the flags with contracts every time they compile even when working on a non is-system contract, possibly making development process more cumbersome

create /is-system subfolder

create subfolder inside /src folder named /is-system where all contracts in this folder will be compiled with is-system flag

Standardize std::out and std::err for all zk oriented cmds

Info

Marcin has mentioned a strict path to convert errors when its a developer to be super readable and understandable. We want to understand and implement the exact mechanics Marcin is looking for.

Compiler version 1.3.6 and 1.3.7 behavior change from v1.3.5

Observed behavior v1.3.5:

When compiling contracts, the imported contracts were discovered and included in the compiled output for --combined-json flag.

Changed (undesired behavior) in v1.3.6 and beyond:

When compiling contracts, the imported contracts are Not Found
stderr: "Source code for path `/home/shakes/fzksync/sample-fzksync-project/lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol` not found\n"

Attempts to correct:

tried using --allow-paths flag to include project root folder, only to receive same error

Example:

This contract will compile with zksolc v1.3.5 (minus abi), but will not compile with v1.3.6 and beyond using --combined-json flag due to import statement. No other code or settings were changed, only the compiler version.

pragma solidity ^0.8.13;

import "../lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol";

contract Counter is ERC20("Coin", "COIN") {
    uint256 public number;

    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    function increment() public {
        number++;
    }
}

Outputs using --combined-json flag:

zksolc v1.3.5: compiled bytecode including imported contracts
zksolc v1.3.6+: cannot compile if contract contains import statement.

Foundry-zkSync 2/20/23

Overview

Implementation Updates

While waiting for sdk dependencies we were able to modularize our modifications by creating three modules: zksync-compile, zksync-deploy, and zksync-utils

Compiling

zksolc v1.3.4 compiler now downloads to <project-root>/zksolc folder

Shortcomings

• ideally would like to check for most recent version of zksolc to download (currently version is hard coded)

Deployment

We had a bit of a slower week for progress as we really wanted to wait and see what functionality the SDK would provide. We were happy to receive that and can confirm will be invaluable in our mission.

Shortcomings

However, zksync-era SDK is currently not building with current dependencies..
related to Github Issue: matter-labs/zksync-era#2

To address this I have cloned local copies of the repositories with broken dependencies and updated them for the following repos:
https://github.com/matter-labs/zksync-era
https://github.com/matter-labs/era-zkevm_test_harness
https://github.com/matter-labs/era-sync_vm

Status

• have updated all dependencies for zksync-era sdk, but getting rust errors on compile:

Current goal is to have SDK up and running and then continue with sdk integration.

Contract Interaction

Not Started Yet

Solidity Scripting

Not Started Yet

---

Confusing error when local env variables are not set

Component

No response

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

No response

What command(s) is the bug in?

No response

Operating System

None

Describe the bug

We should clearly say -- env variables are missing - and don't proceed.

Instead, we print something like this (including some out-of-bound errors ;-)

Missing dependencies found. Installing now...

couldn't interpret OS: environment variable not found
couldn't interpret ZKSOLC_COMPILER_VERSION: environment variable not found
"zksolc-", compiler_filename
 create build_path folder success
The application panicked (crashed).
Message:  index out of bounds: the len is 2 but the index is 2
Location: cli/src/cmd/forge/utils_zksync.rs:87

This is a bug. Consider reporting it at https://github.com/foundry-rs/foundry

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

v0.0 deliverable

Info

This is an issue to explain the expectations, feature completion, and new asks for v0.0

Demo Notes

Feature Set:

Commands

forge zk-build

• Compile smart contracts with zksolc compiler

  • Aliases: forge zk-compile, forge zkbuild, forge zkb

  • Zksolc supported through version 1.3.10

  • Standard json input and output artifacts to /zkout folder

  • Command line output includes:

    • Bytecode Hash

  • zkSync flags supported:

    • --is-system
    • --force-evmla
    • --use-zksolc v1.3.x

• Shortcomings

  • Not technically sourcing configuration files, only flags
    • This would require changes to forge/foundry patterns in which could be breaking upon merge
    • Not standardized patterns and todos in refactors to those patterns found in codebase
      • TLDR: would love feedback from foundry/forge on the cleanest way to go about this for us specifically
  • We are using the pragma solc compiler version of each file specifically, however, we are not informing the user of any solc specific versions that couldn't be supported
  • Intentionally not supported Windows and need further testing on OSX (Linux proof for now)
    • OSX is already implemented and we just need to do some test passes

forge zk-create

• Deploy smart contracts to zkSync

  • Aliases: forge zkcreate, forge zk-deploy, forge zkc

  • Deploy contracts that require factory dependencies

  • Command line output includes:

    • Deployed Contract Address
    • Transaction Hash
    • Gas Used
    • Effective gas price
    • Block Number

  • zkSync flags supported:

    • --factory-deps

• Shortcomings

  • Leveraging only flags for things like network and chain id for the same reasons as the build cmd
  • Intentionally not supported Windows and need further testing on OSX (Linux proof for now)
    • OSX is already implemented and we just need to do some test passes

cast zk-send

• Sign and publish a zksync transaction.

  • Aliases: forge zksend, forge zks
  • Interact with deployed contracts on zkSync
  • Withdraw assets from L2 -> L1
  • Transfer Assets between accounts
  • When deploying contracts via factory contract, command line will return deployed address of child contract.
  • Command Line output includes:
    • Transaction Hash
    • Deployed Address when a DEPLOYER_SYSTEM_CONTRACT Event is emitted

• Shortcomings

  • Some specific interactions are not quite complete
    • Deposits from L1 -> L2. very close to implementation.

• Intentionally not supported Windows and need further testing on OSX (Linux proof for now)

  • OSX is already implemented and we just need to do some test passes

Zksync Specific Interactions

Account Abstraction deployment is supported to include the same example provided by hardhat:
AAFactroy.sol and TwoUserMultiSig.sol

Unconfirmed Scope

• Default, Flags, Config merging architecture (Something we more then likely want feedback from the zksync team)
• Sourcing json file from github to dynamically support the most recent version of the zksolc compiler
  • Our args for compilations aren't quite dynamic, and to support new versions with new flags currently would require an update to the codebase. However, it has been discovered in the ethers-solc implementation that using a more dynamic setup is possible. However, we should consider the unknowns with this.

Blockers

• Need to be running off a fork
• rust zksync-era-sdk needs to be stable
• make contract for feedback loops with foundry team

Moving Foward

We believe we are pretty much in a place to release this thing minus a couple minor shortcomings. Those shortcomings are due to some complexities, and also the principle of trying not to change the codebase in a fashion where we implementing functionality at the core level. For example, foundry/forge may not like the idea of refactoring their configuration for zksync specific implementations. So, with flags, we're able to be facilitate our interactions entirely separate from the standard zksync codebase. We believe it would be wise to create at the very least a feedback mechanism with the foundry/forge community to understand the best way about implementing zksync specific configurations, as we can most likely expect changes requested on their end.

There are some other items in the unconfirmed scope that we can or cannot address. Obviously, if we do, we're not quite ready to get this in the hands of some beta testers/community.

Supporting compiler versions dynamically is great, something that possibly won't slide in immediately, so maybe we can punt the initiative to source the json file and support the latest released version of the compiler by default and relying on the current ways of overriding the default compiler version via a flag. We don't believe this implementation is too complex, but considerable time could be spent on testing and reorganizing what has been implemented. TLDR: what we have works well and confidently, changing that last moment may be inefficient in the manner of implementation.

One thing to think about is since the SDKs still aren't supported, we can maybe slide some of the shortcomings and fixes in before a releasable version. The implementation we would suggest prioritizing is the compiler all contracts. This all being said, we want to be cautious a on moving finish line at this point. We should also keep in mind without stable rust SDKs, we're pretty much not in a releasable state.

Lastly, the sooner we can get a feedback loop with the foundry/forge community, the better. We suggest prioritizing this regardless of what shortcomings or additional scope we want to include. Currently, we really have 1 individual that uses forge using our implementation (Sam) which inherently creates a narrow lens of the best outcomes.

UPDATE: We are now compiling all contracts in src folder, identical to Foundry behavior 5/3/2023 Sam

Implement Overwrite Flag

Implement --overwrite flag so that we can overwrite existing files

Implement LLVM Verify Each Flag

Implement --llvm-verify-each. Sets the verify each option in LLVM

Source local system arch to understand which compiler to use on OSX

Info

// todo

Getting `function_selector = 0x` error when attempting to deploy Child.sol from SimpleFactory.sol

Info

---

Attempting to deploy a simple factory contract that can deploy children contracts, this code is contained in a separate branch factory-deps

Contracts

SimpleFactory.sol

Child.sol

StepChild

SimpleFactory contract can deploy Child.sol and StepChild.sol contract, the difference being that Child.sol takes in constructor arguments.

Steps to reproduce error (Detailed Info below)

1. Spin up local docker node
2. Clone repositories
3. Build SimpleFactory.Sol, Child.sol and StepChild.sol
4. Deploy 3 contracts to L1 -> localhost:8545
5. Deploy SimpleFactory.Sol to local zksync node -> localhost:3050
6. Execute createChild function on SimpleFactory.sol to deploy new child contract

Error received

ErrorObject { code: ServerError(3), message: "Failed to submit transaction: cannot estimate transaction: Error function_selector = 0x, data = 0x.", data: Some(RawValue({"code":104,"message":"cannot estimate transaction: Error function_selector = 0x, data = 0x."})) }

---

Detailed Information

Child Bytecode Hash: 010000413c8083f9791a58efbdf9dd8cd6b8b68ed59693dc1c0f5426bf0593dd

StepChild Bytecode Hash: 010000238795689da0cea5e8eed070c32a1d4c6c1ccc3276e2529353019a7195

Step 1

Spin up local docker node

Follow these instructions to set up local docker node

---

Step 2

Clone Repos

To clone necessary repositories:

# make working directory and cd anywhere on filesystem
$ mkdir fzksync && cd fzksync
# clone foundry-zksync
$ git clone https://github.com/matter-labs/foundry-zksync.git 
# clone zksync-era
$ git clone https://github.com/sammyshakes/zksync-era.git
# clone fzksync-project
$ git clone https://github.com/sammyshakes/sample-fzksync-project.git
# cd into foundry-zksync, swap branch, and build
$ cd foundry-zksync
# checkout and pullfactory-deps branch
$ git checkout -b factory-deps
$ git pull origin factory-deps
# build foundry
$ cargo build -p foundry-cli

Navigate to project root folder:

cd ..
cd sample-fzksync-project

---

Step 3

Build contracts

# command line using forge build:
../foundry-zksync/target/debug/forge build --via-ir --zksync "SimpleFactory.sol"

Note: Above command line will compile SimpleFactory and its children with zksolc compiler and output artifacts to single file:

# zksolc artifacts
<PROJECT-ROOT>/out/zksolc/SimpleFactory.sol/artifacts.json 

Note (continued): It will also automatically compile all contracts in <PROJECT-ROOT>/src/ folder for solidity evm and output artifacts to individual folders (--via-ir flag required for solidity compiler native to foundry):

#solc native foundry artifacts
<PROJECT-ROOT>/out/<CONTRACT-FILENAME>/<CONTRACT-NAME>.json

---

Step 4

Deploy Contracts to L1 localhost:8545

Deploy SimpleFactory.Sol

# command line using forge create:
../foundry-zksync/target/debug/forge create src/SimpleFactory.sol:SimpleFactory --constructor-args 0100003763dc457f96c9994ba6f6fd1790711ce6992fbcc027ef713641d343cb 010000238795689da0cea5e8eed070c32a1d4c6c1ccc3276e2529353019a7195 --rpc-url http://localhost:8545 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --via-ir

• SimpleFactory.Sol was deployed with the bytecode hashes of Child and StepChild as constructor args.
  • 0xa4606C4c09a1f5DD1e6a763716D3191DDA537b22

Deploy Child.sol

# command line using forge create:
../foundry-zksync/target/debug/forge create src/Child.sol:Child --constructor-args 100 1 --rpc-url http://localhost:8545 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --via-ir

• Child.Sol was deployed
  • 0xd4CCc6A962F4261338aA84747Ed5FF1F7945686c

Deploy StepChild.sol

# command line using forge create:
../foundry-zksync/target/debug/forge create src/StepChild.sol:StepChild --rpc-url http://localhost:8545 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --via-ir

• StepChild.Sol was deployed
  • 0xf10A110E59a22b444c669C83b02f0E6d945b2b69

---

Step 5

Deploy Contracts to L2 localhost:3050

Deploy SimpleFactory.Sol

# command line using forge create:
../foundry-zksync/target/debug/forge create src/SimpleFactory.sol:SimpleFactory --constructor-args 0100003763dc457f96c9994ba6f6fd1790711ce6992fbcc027ef713641d343cb 010000238795689da0cea5e8eed070c32a1d4c6c1ccc3276e2529353019a7195 --rpc-url http://localhost:3050 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --via-ir --zksync 270

• SimpleFactory.Sol was deployed with the bytecode hashes of Child and StepChild as constructor args and the bytecodes of all three contracts as Factory Deps

// Result contract successfully deployed at:
0x5a6be02ac21339d38cf0682a77bb24d858902246

reference to `deploy_zksync.rs'

---

Interacting with SimpleFactory.sol

Sanity Check

As a Sanity check we call greeting():
NOTE: first argument is the L2 deployed SimpleFactory address, replace if recreating error.

# command line using cast call:
../foundry-zksync/target/debug/cast call 0x5a6be02ac21339d38cf0682a77bb24d858902246 "greeting()(string)"  --rpc-url http://localhost:3050

Result:

"hello"

Now lets change Greeting:

# command line using cast send:
../foundry-zksync/target/debug/cast send 0x5a6be02ac21339d38cf0682a77bb24d858902246 "setGreeting(string)" "hello, zksync!"  --rpc-url http://localhost:3050 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --zksync 270

call greeting again:
Result:

"hello, zksync!"

---

Step 6

Execute createChild() function on SimpleFactory.sol to deploy new child contract

The attempt is to call the createChild function:

function createChild(uint256 data) external returns (address accountAddress) {
        (bool success, bytes memory returnData) = SystemContractsCaller.systemCallWithReturndata(
            uint32(gasleft()),
            address(DEPLOYER_SYSTEM_CONTRACT),
            uint128(0),
            abi.encodeCall(
                DEPLOYER_SYSTEM_CONTRACT.create, (salt, childBytecodeHash, abi.encode(data, childAddresses.length))
            )
        );
        require(success, "Deployment failed");

        (accountAddress) = abi.decode(returnData, (address));

        childAddresses.push(accountAddress);

        emit ChildCreated(accountAddress, data);
    }

NOTE: first argument is the L2 deployed SimpleFactory address, replace if recreating error.

# command line using cast send:
../foundry-zksync/target/debug/cast send 0x5a6be02ac21339d38cf0682a77bb24d858902246 "createChild(uint256)(address)" 10 --rpc-url http://localhost:3050 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --zksync 270

Error received

ErrorObject { code: ServerError(3), message: "Failed to submit transaction: cannot estimate transaction: Error function_selector = 0x, data = 0x.", data: Some(RawValue({"code":104,"message":"cannot estimate transaction: Error function_selector = 0x, data = 0x."})) }

This error triggers on send_zksync.rs line 95:

foundry-zksync/cli/src/cmd/cast/send_zksync.rs

Lines 89 to 95 in 05573b1

	let tx = w
	.start_execute_contract()
	.contract_address(deployed_contract)
	.calldata(encoded_function_call)
	.send()
	.await
	.unwrap();

Questions:

• Is it possible i am building execution tx incorrectly? I can build a transaction to change contract state (setGreeting() function), how is this different? do factory deps of child contract need to be included when calling createChild()

• Is it possible the solidity function createChild() is malformed?

NOTE: an attempt was also made in creatChild() by switching out gasleft() function with `2**32 - 1' to get a hard coded max value but got same error

Any guidance on deploying a simple factory contract or improving this issue for sake of communication is greatly appreciated!

UPDATE: 4/18/2023 10am est

Deploying Children with alternate functionality

By using newChild() function, all seems to work:

NOTE: first argument is the L2 deployed SimpleFactory address, replace if recreating error.

# command line using cast send:
../foundry-zksync/target/debug/cast send 0xf03cbfb1f17bb224f8839c45259c8a6833a43d93 "newChild(uint256)" 10 --rpc-url http://localhost:3050 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --zksync 270

Verify new Child contract was created:

# command line using cast call:
../foundry-zksync/target/debug/cast call 0xf03cbfb1f17bb224f8839c45259c8a6833a43d93 "getChildren()(address[])"  --rpc-url http://localhost:3050

Result:

[0x2F1BA93F75C185679b863F8E443008188Ab9D212]

Interact with Child

Read from child:

# command line using cast call:
../foundry-zksync/target/debug/cast call 0x2F1BA93F75C185679b863F8E443008188Ab9D212 "isEnabled()(bool)"  --rpc-url http://localhost:3050

Result:

true

Write to Child:

# command line using cast send:
../foundry-zksync/target/debug/cast send 0x2F1BA93F75C185679b863F8E443008188Ab9D212 "disable()" --rpc-url http://localhost:3050 --private-key 7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 --zksync 270

Verify change:

# command line using cast call:
../foundry-zksync/target/debug/cast call 0x2F1BA93F75C185679b863F8E443008188Ab9D212 "isEnabled()(bool)"  --rpc-url http://localhost:3050

Result:

false

Implement the LLVM Debug Logging Flag

Implement --llvm-debug-logging, this sets the 'debug logging' option in LLVM

Create README doc file for v0.0

Info

Foundry-zkSync v0.0 needs documentation to facilitate collaboration and end user

Cleanup loops, unwraps, and more

Info

Find comments on this PR:

• #48