Try   HackMD

Lagrange ZKsync Prover Setup

This is the document outlining the steps to run a Lagrange based ZKsync prover.

Setting up the server with CUDA

As the ZKsync prover makes heavy use of CUDA for fast computation, GPU passthru must be enabled in the Docker server to allow CUDA to be used from within a container.

General Instructions

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html

Ubuntu-Specific Instructions

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update
sudo apt-get install nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Lagrange ZKsync prover setup

Getting the Image

The Lagrange/ZKsync prover is distributed in a Docker image, available here:

For L4 GPU:

docker pull lagrangelabs/lpn-zksync-prover:latest-89

For A10 GPU:

docker pull lagrangelabs/lpn-zksync-prover:latest-86

Two sources of data will must be injected through mounts in the running docker image instance.

Configuration

The configuration file must be edited according to the worker details. It will be mounted under /app/config/config.toml.

Important: change the worker_id in the config
below by putting the name of the company running it so we can identify the exact work provided by your server.

config.toml:

[prover]
setup_data_path = "/data/keys"

[gateway]
gateway_grpc_url = "https://gateway-lcp-dev-0-zk-sync.dev.distributed-query.io/"
max_grpc_message_size_mb = 16

[worker]
worker_id = "zksync-circuit-prover"
operator_id = "Lagrange"
lagr_private_key = "779ff5fe168de6560e95dff8c91d3af4c45ad1b261d03d22e2e1558fb27ea450"
class = "ZKSYNC"

[prometheus]
port = 9090

Proving Keys

Proving Keys generated by the ZKsync stack must be downloaded from https://pub-068f4ca2f03e4f21b6eb72b26008e90a.r2.dev/zksync-dev/data.tar.gz and extracted on the host.

curl -O https://pub-068f4ca2f03e4f21b6eb72b26008e90a.r2.dev/zksync-dev/data.tar.gz
tar -xzvf data.tar.gz

Execution

The docker image tag will be latest-89 for L4 and latest-86 for A10.

docker run \
    --restart=always
    --runtime=nvidia --gpus all \
    -e HEAVY_WVG=2 -e LIGHT_WVG=30 \
    --mount type=bind,src=./config.toml,target=/app/config/config.toml \
    --mount type=bind,src=./data,target=/data lagrangelabs/lpn-zksync-prover:latest-89
Last changed by 
 
Nicolas Gailly
0
192

Read more

Groth16 aggregation with public input trick

Regular Groth 16 CRS Random $\tau$ chosen during trusted setup as well as $\alpha$, $\beta$ $n$ is number of gates. $u_i$, $v_i$ and $w_i$ are the QAP polynomials created from the R1CS circuit $SRS = {g_1^\alpha, g_1^\beta, g_1^\delta, {{ g_1^{\tau^i}}, {g_1^{\alpha \tau^i}}, {g_1^{\beta \tau^i}}}{i=0}^{n-1}, {g_1^{\beta u_i(\tau) + \alpha v_i(\tau) + w_i(\tau)}}{i=0}^n}, {g^{\frac{\tau^it(x)}{\delta}}}{i=0}^{n-1},\g_2^\beta, g_2^\delta, {g_2^{\tau ^i}}{i=0}^{n-1}}$ Prover Settings:

Apr 15, 2023
Efficient threshold BLS & Encryption

This post explains an inherent tension between threshold BLS signature and Elgamal encryption for onchain verification, and then presents a way to augment such threshold network such that a smart contract can efficiently verify a signature and decrypt/verify encryption onchain. 21/03/23, Nicolas Gailly, Cryptonet team, Protocol Labs. Introduction For encryption/decryption and signing, we (usually) require a group, i.e. a single elliptic curve. However, using pairings, we have to choose between $\mathbb{G_1}$ and $\mathbb{G_2}$ (and even $\mathbb{G_t}$), each group have their pros and cons depending on the cryptographic protocol we want to use. In practice, $\mathbb{G_1}$ is usually preferred given it is much shorter and faster to compute in it, than its counter-parties. This choice of group comes up when designing threshold networks. Indeed, there is a distributed key lying in a group $\mathbb{G}$ which could be any of the three groups aforementioned. In particular, when using pairing equipped curves, a threshold network can be used to create threshold BLS signatures but it can also be used as a decryption oracle. In the latter, users encrypts towards the threshold network and push the encryption on-chain. This posts shows the pros and cons of using $\mathbb{G_1}$ and $\mathbb{G_2}$ for each and shows there is a tension between the two. This posts then shows a simple solution to get the best of both worlds. The technique is heavily inspired by a post by Kobi Gurkan on efficient multisignature verification onchain, translated to the threshold setting.

Mar 21, 2023
Trusted Setup: KZG and PST

KZG trusted setup First Player First player has secret $s$ and generates $$ [s]_1, [s^2]_1 ... $$ as well as the "check" point $$ [s]_2 $$

Jan 31, 2023
DKG Share Recovery

DKG in a few lines Each node $i$: has a private polynomial $$f_i(x) = a_0 + ... + a_{t-1}x^{t-1}$$ From that get the public poly $$F_i(x) = f_i(x) * G$$ generate shares for others $$s_{i,j} = f_i(j)$$ then sum each share it receives (from QUALified participants) + its own: final share is $$s_i = \sum_j s_{j,i}$$ final public polynomial $$F(x) = \sum_i F_i(x)$$

Oct 27, 2022
Read more from Nicolas Gailly
Published on HackMD