{
"creator": "Matter Labs",
"projectsForTvs": [
{
"projectId": "zklinknova",
"sinceTimestamp": 1709217961
},
{
"projectId": "zksync2",
"sinceTimestamp": 1689544800
},
{
"projectId": "abstract",
"sinceTimestamp": 1737932400
},
{
"projectId": "sophon",
"sinceTimestamp": 1734476400
},
{
"projectId": "cronoszkevm",
"sinceTimestamp": 1723672800
},
{
"projectId": "zeronetwork",
"sinceTimestamp": 1731366000
},
{
"projectId": "lens",
"sinceTimestamp": 1743717600
},
{
"projectId": "wonder",
"sinceTimestamp": 1746741600
},
{
"projectId": "zkcandy",
"sinceTimestamp": 1743976800
},
{
"projectId": "grvt",
"sinceTimestamp": 1734649200
},
{
"projectId": "lachain",
"sinceTimestamp": 1747692000
},
{
"projectId": "sxt",
"sinceTimestamp": 1746741600
}
],
"proofSystemInfo": "## Description\n\nBoojum is a proving system operating on [EraVM](https://matter-labs.github.io/zksync-era/core/latest/guides/advanced/12_alternative_vm_intro.html) ISA and supporting [zk stack](https://zkstack.io) chains. It includes recursive STARK proving of zkVM execution, as well as the final wrap with [Plonk](https://github.com/matter-labs/franklin-crypto/tree/dev/src/plonk) or [Fflonk](https://github.com/matter-labs/zksync-crypto/blob/main/crates/fflonk/docs/spec.pdf) SNARK proving system. Boojum targets [100 bits of security](https://github.com/matter-labs/era-boojum?tab=readme-ov-file#for-curions-in-benchmarks-only).\n\n## Proof system\n\n### zkVM component\n\n[Boojum](https://github.com/matter-labs/era-boojum/tree/main)'s core is an implementation of the [**Redshift**](https://eprint.iacr.org/2019/1400.pdf) protocol which uses the Plonk IOP with a polynomial commitment scheme based on List Polynomial Commitments (LPCs), which is in turn based on FRI, making the scheme transparent. The scheme makes use of the Goldilocks field, which is much smaller than BN254's field. This part of boojum implements a zkVM for EraVM, which is closely aligned with EVM but has essential differences like 16 registers.\n\n### Recursion circuits\n\nThe protocol makes use of several layers of recursive proof aggregation for 15 types of [circuits](https://github.com/matter-labs/era-zkevm_test_harness/blob/3cd647aa57fc2e1180bab53f7a3b61ec47502a46/circuit_definitions/src/circuit_definitions/recursion_layer/mod.rs#L29). In particular, node and scheduler circuits aggregate zk proofs and compressor and wrapper circuits reduce the final proof size. Further information about the aggregation architecture can be found [**here**](https://github.com/matter-labs/zksync-era/blob/1b61d0797062ab8b0aa2c1e92b23a3a0d8fd2c61/docs/guides/advanced/15_prover_keys.md#circuits).\n\n### Final wrap\n\nThe final proof could either be wrapped into a [Plonk](https://github.com/matter-labs/era-zkevm_test_harness/blob/3cd647aa57fc2e1180bab53f7a3b61ec47502a46/circuit_definitions/src/circuit_definitions/aux_layer/wrapper.rs)+KZG proof, or into [Fflonk](https://github.com/matter-labs/zksync-crypto/tree/main/crates/fflonk)+KZG for cheap verification. The KZG commitment is done over BN254 curve and it uses Aztec Ignition trusted setup ceremony, see [below](#trusted-setups) for more details.",
"techStack": {
"zkVM": [
{
"id": "Boojum",
"type": "STARK",
"name": "Boojum",
"description": "zkVM STARK proving system developed by Matter Labs for proving state transition of ZKsync Era."
},
{
"id": "EraVM",
"type": "ISA",
"name": "EraVM",
"description": "Instruction language for ZKsync Era virtual machine."
},
{
"id": "Goldilocks",
"type": "Field",
"name": "Goldilocks",
"description": "Prime field of order p = 2**64 - 2**32 + 1."
}
],
"finalWrap": [
{
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
{
"id": "Zksync",
"type": "Fflonk",
"name": "Zksync",
"description": "Matter Labs Rust implementation of Fflonk improvement over standard Plonk proving system."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"participantCount": 176,
"risk": "green",
"shortDescription": "Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.",
"longDescription": "Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \nIt included 176 participants and was publicly open for participation.\n\n- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition)."
},
{
"proofSystem": {
"id": "Zksync",
"type": "Fflonk",
"name": "Zksync",
"description": "Matter Labs Rust implementation of Fflonk improvement over standard Plonk proving system."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"participantCount": 176,
"risk": "green",
"shortDescription": "Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.",
"longDescription": "Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \nIt included 176 participants and was publicly open for participation.\n\n- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition)."
}
],
"verifierHashes": [
{
"hash": "0x6f36a08c517b060fa97308cdb3e23b04842ff839d451a753ec8fae1a5408304a",
"name": "Boojum Fflonk core-v29.1.0",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/core-v29.1.0/prover",
"proofSystem": {
"id": "Zksync",
"type": "Fflonk",
"name": "Zksync",
"description": "Matter Labs Rust implementation of Fflonk improvement over standard Plonk proving system."
},
"knownDeployments": [
{
"address": "eth:0x1AC4F629Fdc77A7700B68d03bF8D1A53f2210911"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `core-v29.1.0`, commit hash `3b61f62b3361404c0c94635caee68c855ce2b9f8`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout core-v29.1.0\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `fflonk_snark_wrapper` value."
},
{
"hash": "0x64b347c642ea60114c98b3976124ea8a7e0bb778bd7e479aedc02f994486c8a1",
"name": "Boojum Plonk prover-v22.0.0",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/prover-v22.0.0/prover",
"proofSystem": {
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
"knownDeployments": [
{
"address": "eth:0x2db2ffdecb7446aaab01FAc3f4D55863db3C5bd6"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `prover-v22.0.0`, commit hash `157045b4f67546629fc2f7fb32cbbcb4daa2054d`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout prover-v22.0.0\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `snark_wrapper` value."
},
{
"hash": "0x8574e152c41dc39a2ecab984545e1cf21cb3ec250b919018a8053f2fa270784f",
"name": "Boojum Plonk zkLinkNova verifier",
"proofSystem": {
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
"knownDeployments": [
{
"address": "linea:0x902C3806A84f4e855a8746e92d7F1C9a51400458"
}
],
"verificationStatus": "notVerified"
},
{
"hash": "0x49eae0bf5c7ea580f4979b366e52b386adc5f42e2ce50fc1d3c4de9a86052bff",
"name": "Boojum Fflonk core-v29.4.0",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/core-v29.4.0/prover",
"proofSystem": {
"id": "Zksync",
"type": "Fflonk",
"name": "Zksync",
"description": "Matter Labs Rust implementation of Fflonk improvement over standard Plonk proving system."
},
"knownDeployments": [
{
"address": "eth:0xD324a7c8556A059371B207fB96FD77bE24E2042c"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `core-v29.4.0`, commit hash `fe0a73730853b291c3c1dd514a42a45625704b7b`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout core-v29.4.0\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `fflonk_snark_wrapper` value."
},
{
"hash": "0x1ffc56111a5cfaf5db387f6a31408ad20217e9bc1f31f2f5c1bd38b0d6d7968b",
"name": "Boojum Plonk prover-v23.2.0",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/prover-v23.2.0/prover",
"proofSystem": {
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
"knownDeployments": [
{
"address": "eth:0xe201837d151E5aC33Af3305f287Ad6F6a7Dfccd7"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `prover-v23.2.0`, commit hash `2b188cd7ac139430d3cb1f27babc9693a2c83df6`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout prover-v23.2.0\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `snark_wrapper` value."
},
{
"hash": "0xb2f50340e0edbe49dc657d4eb298e07f13860c1be0fe2e438e44ef8fad133d84",
"name": "Boojum Plonk core-v29.11.1",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/core-v29.11.1/prover",
"proofSystem": {
"id": "Bellman",
"type": "Plonk",
"name": "Bellman",
"description": "Bellman Rust library for Plonk proving system, originally developed for ZCash."
},
"knownDeployments": [
{
"address": "eth:0x7f33D100f482093182111d69a4a457289e99f4ec"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `core-v29.11.1`, commit hash `3f71cb2230fb9c365c095ce7bcf3373ea63fbec2`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout core-v29.11.1\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `snark_wrapper` value."
},
{
"hash": "0xc8cd705a0db89577146137de78eba6bd1f1c9c3f66dc52f7627e7c2df30895b2",
"name": "Boojum Fflonk core-v29.11.1",
"sourceLink": "https://github.com/matter-labs/zksync-era/tree/core-v29.11.1/prover",
"proofSystem": {
"id": "Zksync",
"type": "Fflonk",
"name": "Zksync",
"description": "Matter Labs Rust implementation of Fflonk improvement over standard Plonk proving system."
},
"knownDeployments": [
{
"address": "eth:0xa38a0Df579F9eCA29fbA560b9885B1113b1Df442"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "Verification requires an Ubuntu 22.04 machine with an NVIDIA GPU. We used a g6.4xlarge aws instance with 24 GiB GPU memory and 64 GiB RAM. \nThe setup part is based on [this guide](https://paragraph.com/@zksync/from-integration-to-verification-completing-the-first-steps-in-zksync-s-prover-network) with modifications, the verification is done using [this script](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri).\n\n1. Install rust, yarn, some essential libraries, docker and cmake:\n\n```\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash\nexport NVM_DIR=$HOME/.nvm\n. .bashrc\nnvm install 20\nnpm install -g yarn\nyarn set version 1.22.19\n\nsudo apt-get update\nsudo apt-get install -y build-essential pkg-config cmake clang lldb lld libssl-dev postgresql apt-transport-https ca-certificates curl software-properties-common\ncargo install sqlx-cli --version 0.8.1\n\n# install the latest version of cmake\nsudo apt remove cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n```\n\n2. Install CUDA drivers and toolkit 12.2, export necessary env vars. On Ubuntu 22.04 this requires updating gcc to version 12.\n\n```\nsudo apt-get install gcc-12 g++-12\nsudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100\nsudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100\n\nwget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y cuda-drivers-535\nsudo apt-get install -y cuda-toolkit-12-2\n```\n\nReboot the machine to apply the drivers.\n\n3. Install `foundryup-zksync`.\n\n```\ncurl -L https://raw.githubusercontent.com/matter-labs/foundry-zksync/main/install-foundry-zksync | bash\n. ~/.bashrc\nfoundryup-zksync\n```\n\n4. Build bellman-cuda. We used the tag version `prerelease-dev-a87a309`, commit hash `a87a309e7c07ef6b3fc5532e50d5d244aab9f4d0`.\n```\nexport CUDA_HOME=/usr/local/cuda\nexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64\nexport PATH=$PATH:$CUDA_HOME/bin\n\ngit clone https://github.com/matter-labs/era-bellman-cuda.git\ncd era-bellman-cuda\ngit checkout prerelease-dev-a87a309\ngit submodule update --init --recursive\ncmake -B./build -DCMAKE_BUILD_TYPE=Release\ncmake --build ./build\nexport BELLMAN_CUDA_DIR=$HOME/era-bellman-cuda\n```\n\n5. Run all scripts to regenerate verification keys. The correct tag version of the repo is `core-v29.11.1`, commit hash `3f71cb2230fb9c365c095ce7bcf3373ea63fbec2`.\n```\ncd ~ \ngit clone https://github.com/matter-labs/zksync-era.git\ncd zksync-era/\ngit checkout core-v29.11.1\n\n# Download compact CRS for the compressor data step, put in repo root\ncurl -o setup_compact.key https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_compact.key\nexport COMPACT_CRS_FILE=~/zksync-era/setup_compact.key\n\ncd prover/crates/bin/vk_setup_data_generator_server_fri\nCRS_FILE=https://storage.googleapis.com/matterlabs-setup-keys-us/setup-keys/setup_2^24.key ZKSYNC_HOME=$HOME \n\n# Run regeneration steps\ncargo run --release --bin key_generator generate-vk\ncargo run --features gpu --release --bin key_generator generate-compressor-data\n```\n\nThe output of the last command will contain the required `fflonk_snark_wrapper` value."
}
]
}
[REMOVED]sxt+0-2085
id+0-1
"sxt"
slug+0-1
"sxt"
name+0-1
"Space and Time"
shortName+0-1
null
aliases+0-3
[
"SXT"
]
addedAt+0-1
1716819511
statuses+0-3
{
"unverifiedContracts": []
}
display+0-85
{
"badges": [
{
"id": "EVM",
"type": "VM",
"name": "EVM",
"description": "This project uses the Ethereum Virtual Machine to run its smart contracts and supports the Solidity programming language",
"action": {
"type": "scalingFilter",
"id": "vm",
"value": "EVM"
}
},
{
"id": "AvailVector",
"type": "DA",
"name": "Avail with Vector",
"description": "This project utilizes Avail and has Vector enabled, facilitating the bridging of data availability commitments between Avail and Ethereum.",
"action": {
"type": "publicDaHighlight",
"slug": "avail"
}
},
{
"id": "ZKStack",
"type": "Stack",
"name": "Built on the ZK Stack",
"description": "The project is built on the ZK Stack",
"action": {
"type": "scalingFilter",
"id": "stack",
"value": "ZK Stack"
}
},
{
"id": "ElasticChain",
"type": "Infra",
"name": "Part of the Elastic Chain",
"description": "The project is part of the Elastic Chain, meaning it's based on the ZK stack and uses the shared contracts",
"action": {
"type": "scalingFilter",
"id": "infrastructure",
"value": "Elastic Chain"
}
},
{
"id": "Caldera",
"type": "RaaS",
"name": "Caldera",
"description": "This project was deployed via the rollup-as-a-service provider Caldera",
"action": {
"type": "scalingFilter",
"id": "raas",
"value": "Caldera"
}
}
],
"description": "Space and Time (SxT) is a decentralized data warehouse that aims to provide a zk 'Proof of SQL' to bring offchain data to smart contracts onchain. Built on ZK Stack, the SxT chain will serve as a settlement layer and payment hub for data queries.",
"links": {
"websites": [
"https://spaceandtime.io"
],
"bridges": [
"https://app.spaceandtime.ai"
],
"documentation": [
"https://docs.spaceandtime.io"
],
"explorers": [
"https://spaceandtime.calderaexplorer.xyz"
],
"repositories": [
"https://github.com/spaceandtimelabs"
],
"socialMedia": [
"https://x.com/spaceandtime",
"https://discord.com/invite/spaceandtimeDB",
"https://linkedin.com/company/space-and-time-db/",
"https://youtube.com/channel/UCXJyE7ahmqCH11aO7L76PBA",
"https://t.me/spaceandtimedb",
"https://instagram.com/spaceandtimedb/",
"https://spaceandtime.io/blog"
]
}
}
[
{
"title": "Mainnet Launch",
"url": "https://x.com/SpaceandTimeDB/status/1920873080471384271",
"date": "2025-05-09T00:00:00Z",
"description": "Space and Time is live on mainnet.",
"type": "general"
}
]
{
"missing": {
"nextStage": "Stage 1",
"requirements": [
"Users' withdrawals can be censored by the permissioned operators.",
"Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.",
"The Security Council is not properly set up."
],
"principle": "Compromising ≥75% of the Security Council to push a malicious upgrade, or sequencer+DA-committee collusion to withhold data and finalize invalid state roots, should be the only ways (other than bugs) to steal funds or block withdrawals indefinitely."
},
"stage": "Stage 0",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "The project self-identifies as a Validium or Optimium."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "A complete and functional proof system (fraud or validity proofs) is deployed."
},
{
"satisfied": true,
"description": "DA is attested by a committee or external DA layer, not solely by the sequencer."
},
{
"satisfied": true,
"description": "A source-available node exists that can reconstruct the L2 state when DA is accessible. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/matter-labs/zksync-era)"
}
]
},
{
"stage": "Stage 1",
"requirements": [
{
"satisfied": false,
"description": "Users' withdrawals can be censored by the permissioned operators."
},
{
"satisfied": false,
"description": "Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring."
},
{
"satisfied": false,
"description": "The Security Council is not properly set up."
},
{
"satisfied": true,
"description": "A secure DA verifier is integrated on L1 that checks DA attestations onchain, enabling challengers to retrieve data and construct proofs. [View code](https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code)"
},
{
"satisfied": true,
"description": "The DA verifier is non-upgradeable, or upgrades to it provide at least a 7d independent exit window."
},
{
"satisfied": true,
"description": "The DA layer meets minimum decentralization: a DAC with ≥5 external members under an honest-minority assumption, or an external DA chain with an attestation verifier."
},
{
"satisfied": true,
"description": "The proof system meets the minimum trusted setup requirements defined in the L2BEAT [trusted setup assessment framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381).",
"upcoming": true
},
{
"satisfied": true,
"description": "Prover source code is published.",
"upcoming": true
},
{
"satisfied": true,
"description": "The sources of all programs used are public and program hashes can be independently regenerated.",
"upcoming": true
}
],
"principle": {
"satisfied": false,
"description": "Compromising ≥75% of the Security Council to push a malicious upgrade, or sequencer+DA-committee collusion to withhold data and finalize invalid state roots, should be the only ways (other than bugs) to steal funds or block withdrawals indefinitely."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": false,
"description": "Upgrades unrelated to onchain provable bugs, including upgrades to the DA verifier, provide less than 30d to exit."
},
{
"satisfied": false,
"description": "The DA verifier (and related contracts) is upgradeable with less than 30d independent exit window."
},
{
"satisfied": false,
"description": "The DA mechanism relies on reputational security alone; no staked assets are at risk for DA misbehavior or slashable < TVS."
}
]
}
]
}
scalingRisks+0-40
{
"self": {
"stateValidation": {
"value": "Validity proofs (ST, SN)",
"description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
"sentiment": "good",
"orderHint": null,
"permissioned": true,
"executionDelay": 10800,
"secondLine": "3h execution delay"
},
"dataAvailability": {
"value": "External",
"description": "Proof construction and state derivation fully rely on data that is posted on Avail. Transaction data is checked against the Vector bridge data roots, signed off by Avail validators.",
"sentiment": "warning"
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": 0,
"regular": {
"value": "4d 3h",
"sentiment": "warning",
"description": "Non-emergency upgrades go through a 4d 3h delay, but the central operator can still censor withdrawal transactions by implementing a TransactionFilterer with no delay."
}
},
"sequencerFailure": {
"value": "Enqueue via L1",
"description": "Users can submit transactions to an L1 queue, but can't force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone.",
"sentiment": "warning"
},
"proposerFailure": {
"value": "Replace proposer",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen. There is a decentralized Governance system that can attempt changing Proposers with an upgrade.",
"sentiment": "warning",
"orderHint": null
}
}
}
scalingDa+0-20
[
{
"layer": {
"value": "Avail",
"sentiment": "warning",
"description": "The data is posted to Avail.",
"projectId": "avail"
},
"bridge": {
"value": "Vector",
"sentiment": "warning",
"description": "The Vector DA bridge is used to attest to the data availability on Avail.",
"projectId": "vector"
},
"mode": {
"value": "State diffs",
"secondLine": "Compressed"
}
}
]
scalingTechnology+0-104
{
"architectureImage": "zkstack-validium",
"dataAvailability": [
{
"name": "Data is posted to Avail",
"description": "Transactions roots are posted onchain and the full data is posted on Avail. The vector bridge is used to verify attestations from the Avail validator set that the data is indeed available.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
},
{
"category": "Funds can be lost if",
"text": "the data is not available on the external provider.",
"isCritical": true
}
],
"references": [
{
"title": "AvailL1DAValidator - checkDA() function",
"url": "https://etherscan.io/address/0x8f50d93B9955B285f787043B30B5F51D09bE0120#code#F1#L16"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.",
"risks": [],
"references": [
{
"title": "Withdrawing funds - ZKsync documentation",
"url": "https://docs.zksync.io/zksync-protocol/rollup/bridging-assets"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force any transaction via L1",
"description": "If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator can implement a TransactionFilterer that censors forced transactions.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
},
{
"category": "Users can be censored if",
"text": "the operator implements a TransactionFilterer, which is possible without delay."
}
],
"references": [
{
"title": "L1 - L2 interoperability - Developer's documentation",
"url": "https://docs.zksync.io/zksync-protocol/era-vm/contracts/handling-l1-l2-ops"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"stateValidation": {
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
"categories": [
{
"title": "Prover Architecture",
"description": "ZKsync Era proof system Boojum can be found [here](https://github.com/matter-labs/era-boojum/tree/main) and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found [here](https://github.com/matter-labs/zksync-era/tree/main/prover)."
},
{
"title": "ZK Circuits",
"description": "ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found [here](https://github.com/matter-labs/era-zkevm_circuits/tree/main). The circuits are checked against tests that can be found [here](https://github.com/matter-labs/era-zkevm_test_harness/tree/main).",
"risks": [
{
"category": "Funds can be lost if",
"text": "the proof system is implemented incorrectly."
}
]
},
{
"title": "Verification Keys Generation",
"description": "SNARK verification keys can be generated and checked against the Ethereum verifier contract using [this tool](https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri). The system requires a trusted setup."
}
]
},
"upgradesAndGovernance": {
"content": "There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler.\nThe standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants.\nThe emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.\n## Standard path\n### On ZKsync Era\nDelegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup's ZkProtocolGovernor contract.\nThis launches a 3d 'voting delay' after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold.\nA proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension.\nIn the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2->L1 log.\n### On Ethereum\nAfter the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d 'legal veto period'.\nThis serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d.\nAfter this a proposal enters a *waiting* state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil.\nFor the unlikely case that the Security Council does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full.\nA proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the *pendingExecution* state for a final delay of 1d and can then be executed.\n### Other governance tracks\nThere are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and\n2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets.\nThe protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1.\nFurther customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians' L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.\n## Emergency path\nSecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/5) form a de-facto 3/3 Multisig\nby pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.\n## Upgrade Delays\nThe cumulative duration of the upgrade paths from the moment of a voted 'successful' proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.\n## Freezing\nThe SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current ChainTypeManager.\nEither for a softFreeze of 12h or a hardFreeze of 7d.\nAfter a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible.\nOnly the SecurityCouncil can unfreeze an active freeze.\n## ZK cluster Admin and Chain Admin\nApart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system:\nA single *ZK cluster Admin* role who governs parameters in the shared contracts and a *Chain Admin* role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack.\nThese chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing Validators in the ValidatorTimelock.\nFor rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future.\nThe source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler.\nZKsync Era's Chain Admin differs from the others as it also has the above *ZK cluster Admin* role in the shared ZK stack contracts.",
"image": "zkstack"
}
}
{
"explanation": "Space and Time is a Validium that posts commitments to the L1. Transactions within a state diff can be considered final when proven on L1 using a ZK proof, except that an operator can revert them if not executed yet. Currently, there is at least a 3h delay between state diffs verification and the execution of the corresponding state actions."
}
{
"daLayer": "avail",
"name": "Vector",
"relayerType": {
"value": "Permissioned",
"sentiment": "warning",
"description": "Only whitelisted relayers can post attestations to this bridge."
},
"risks": {
"committeeSecurity": {
"value": "Validator set",
"sentiment": "good",
"description": "The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. \n Participation in the committee is permissionless, based only on stake requirements and an honest majority of validators processing the new operator's request to join the active set.",
"orderHint": 2
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
}
},
"technology": {
"description": "## Architecture\n\n\n\nThe Vector bridge is a data availability bridge that facilitates data availability commitments to be bridged between Avail and Ethereum.\nThe SP1 Vector bridge is composed of three main components: the **Vector** contract, the **Succinct Gateway** contracts, and the **Verifier** contracts. \nBy default, Vector operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledge proofs of Avail block ranges are requested for proving. Requests can be submitted either off-chain through the Succinct API, or onchain through the requestCall() method of the Succinct Gateway smart contract.\nAlternatively, it is possible to run an SP1 Vector operator with local proving, allowing for self-generating the proofs.\nOnce a proving request is received, the off-chain prover generates the proof and relays it to the Vector contract. The Vector contract verifies the proof with the corresponding verifier contract and, if successful, stores the data commitment in storage. \n\nBy default, Vector on Ethereum is updated by the Succinct operator at a cadence of approximately 1.5 hours.",
"references": [
{
"title": "SP1 Vector Operator",
"url": "https://github.com/succinctlabs/sp1-vector/blob/a9689768ff4052e0933cc575b79001d4bcfa0cd5/script/bin/operator.rs"
},
{
"title": "Succinct Gateway - Etherscan",
"url": "https://etherscan.io/address/0x6c7a05e0AE641c6559fD76ac56641778B6eCd776#code#F1#L148"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the DA bridge accepts an incorrect or malicious data commitment provided by 2/3 of Avail validators."
},
{
"category": "Funds can be frozen if",
"text": "excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the Vector contract."
}
]
},
"usedIn": [
{
"id": "lens",
"name": "Lens",
"slug": "lens"
},
{
"id": "sophon",
"name": "Sophon",
"slug": "sophon"
},
{
"id": "sxt",
"name": "Space and Time",
"slug": "sxt"
}
],
"validationType": {
"value": "Validity Proof",
"description": "The DA attestation requires onchain SNARK proof verification to be accepted by the bridge. Operators signatures and their corresponding stake are verified as part of the proof.",
"zkCatalogId": "sp1hypercube"
}
}