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 \

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:

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.

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 $$

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)$$

Recap on DKG Goal: Distributed key pair $P$ amongst $n$ parties such that $n/2 \lt t \lt n$ parties are required to collaborate to reconstruct it. Set of less than $t$ parties can not learn anything about $P$ Why: Used by drand for example, other system now like Axelar How: basic version is usually $n$ instances Verifiable Secret Sharing (VSS) in parallel

Recap on Threshold Cryptography Goal: Distributed key pair $P$ amongst $n$ parties such that $n/2 \lt t \lt n$ parties are required to collaborate to reconstruct it. Set of less than $t$ parties can not learn anything about $P$ How: basic version is usually $n$ instances Verifiable Secret Sharing (VSS) in parallel Notation

DKG in SNARK? VSS: Dealer $a_0$ Deal Phase: Create $f(x) = a_0 + a_1 * x + ... + a_{t-1}*x^{t-1}$ Compute shares $f(1), \dots, f(n)$ Encrypt each shares $Enc(f(1),PK_1), \dots$ Compute commitment to $f(x)$ : $F(x) = [f(x)] G$ Send everything

Notation Say we have a finite field $\mathbb{F}$ of order $p$. We write $p-1 = 2^k * t$ for some $t$ and $k$ * $\mathbb{F}$ has two subgroups of order $2^k$ and $t$ Denote a generator $\alpha$ of the $n = 2^k$ order subgroup $\mathbb{G}$: $|\mathbb{G}| = n$ (number of points in the subgroup) $\mathbb{G} = {1,\alpha,\alpha^2,\dots, \alpha^{n-1}}$

This document explains the technical steps necessary to setup and maintain a drand network. The first section explains how to install drand. The second section explains how to setup a distributed drand network. Finally, the third section shows the most commonly used commands to maintain the network such as adding/removing nodes) and to get information about a running drand daemon. Hardware requirement Drand is a lightweight process that runs as a daemon and as such can run with any low profile CPU. There is a minimum disk space of 1GB. As well, given the nature of drand, a good uptime must be guaranteed! NOTE: This minimum disk space is already way over what drand actually uses. Over the course of one year, given a period of 1mn and a beacon of $48+48+8 = 104$ bytes, drand stores only $1046024*365=54$MB ! NOTE2: Expect this section to change to also include requirements in terms of "sysadmin time" if one wants to participate in the global network: there are operations to run if case there is a failure or new members join in. Install drand

# Drand: Cryptographic Background This document provides an overview on the cryptographic building blocks that drand uses to generate publicly-verifiable, unbiasable, and unpredictable randomness in a distributed manner. The drand beacon has two phases (a *setup phase* and a *beacon phase*) which we describe below. Generally, we assume that there are $n$ participants out of which at most $f < n$ are malicious. drand heavily relies on [threshold cryptography](https://en.wikipedia.org/wiki/Thres

# Drand: User Guide A drand beacon provides several public services to clients. Those services are exposed on a gRPC endpoint as well as a REST JSON endpoint, on the same port. The latter is especially useful if one wishes to retrieve randomness from a Javascript application. This document explains ways to retrieve randomness from a running drand node. The first section shows the commands using the Go command-line application to retrieve public and private randomness. The second section show

# Difference between r2 and drg-attacks and CCS paper Difference between r2 and drg-attacks (and paper) are two folds: 1. different way to compute the bucket index 2. different way to compute the final value ## Bucket Index of the parent + In the paper algorithm (DRSample, Algorithm 1 in CCS [paper](https://acmccs.github.io/papers/p1001-alwenA.pdf), we have: ```rust g' <-- [1,floor(log2(v))+1] ``` + In r2, we have the following [code](https://github.com/nicola/r2/blob/master/src/gra

# User randomness source in DKG ### Goals 1. being able to inject a user-provided source of randomness 2. being able to reproduce tests 3. being able to detect and return errors from user-provided source of randomness 4. being able to mix both user-provided and /dev/urandom sources of randomness ## Proposition 1 In dkg.go: ```golang type Config struct { ... Reader io.Reader // user-provided randomness UseOnlyReader bool // if we want to only use the Reader } func NewDistKeyGenerator

# Chung's construction in ZigZag ## Chung Bipartite Expander Let us work on the example from the paper but by adding the distinction between the different permutations via different colors. Here we have $n = 5, k = 3$. I chose the permutations (i.e. assigned colors) completely arbitrarily. ```graphviz digraph G { rankdir="LR"; splines=false; //graph [nodesep=0.5, ranksep=1]; subgraph cluster_level1 { C1 -> C2 -> C3 -> C4 -> C5 C1 -> C6 [ color="green", constraint=fa

# Offchain timed contrat ## Problem statement We have a prover/miner $m_i$ that periodically must prove a statement $S_i$ over time by "showing" a proof $\pi_i$. In the context of Filecoin, the miner must prove that it is storing a given file, and post such a proof $\pi_i$ to the blockchain. We then extend the problem where there are $m$ miners that each needs to prove a statement at the same time. The goal is to enable the miner to post a "summary" of all proofs after a fixed period of time