Real quickly, the Venn diagram below shows how the three classes relate to each other: Perfect is a strict subset of Full $\cap$ Complete.

Definitions

Full binary tree

A full (a.k.a., proper or strict) binary tree is one where every node has 0 or 2 children. In other words, no node has exactly one child.

Example 1 — A single node (trivially full):

graph TD
    A(( ))

Example 2 — A 5-node full tree:

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    C --- D(( ))
    C --- E(( ))

Example 3 — A 7-node full tree that is not perfect (leaves at depths 1, 2, and 3):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))
    D --- F(( ))
    D --- G(( ))

Complete binary tree

A complete binary tree must have two properties:

1. Every level is fully-filled except possibly the last,
2. The last level is filled from left to right.

This is the shape you get when you insert elements into a binary heap one by one.

Example 1 — A 4-node complete tree (note: not full, since the left child has only one child):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- inv[ ]

    style inv fill-opacity:0, stroke-opacity:0;
    linkStyle 3 stroke:none;

Example 2 — A 5-node complete tree (this one is also full):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))

Example 3 — A 6-node complete tree (note: not full, since the right child has only one child):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))
    C --- F(( ))
    C --- inv[ ]

    style inv fill-opacity:0, stroke-opacity:0;
    linkStyle 5 stroke:none;

Perfect binary tree

A perfect binary tree must have two properties:

1. All internal nodes have exactly 2 children,
2. All leaves are at the same depth.

A perfect binary tree of height $h$ has exactly $2^{h+1} - 1$ nodes.

Example 1 — Height 0 (1 node):

graph TD
    A(( ))

Example 2 — Height 1 (3 nodes):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))

Example 3 — Height 2 (7 nodes):

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))
    C --- F(( ))
    C --- G(( ))

Relationships

There are six pairwise implications to consider. Let’s work through all of them.

Full $\nRightarrow$ Complete

Counterexample: this tree is full (every node has 0 or 2 children), but not complete because the second level is not filled from left to right — the right subtree is deeper than the left.

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    C --- D(( ))
    C --- E(( ))

Full $\nRightarrow$ Perfect

Counterexample: this full tree has leaves at depths 1 and 3, so it is not perfect.

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))
    D --- F(( ))
    D --- G(( ))

Complete $\nRightarrow$ Full

Counterexample: this 4-node complete tree has a node with exactly one child, violating fullness.

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- inv[ ]

    style inv fill-opacity:0, stroke-opacity:0;
    linkStyle 3 stroke:none;

Complete $\nRightarrow$ Perfect

Counterexample: this 5-node complete tree has leaves at depths 1 and 2.

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))

Perfect $\Rightarrow$ Full

By definition, every internal node of a perfect tree has exactly 2 children, which is exactly the requirement for fullness.

Perfect $\Rightarrow$ Complete

In a perfect tree, every level is completely filled (including the last). This trivially satisfies the definition of completeness.

Full + Complete $\nRightarrow$ Perfect

Many people assume that if a tree is both full and complete, then it must be perfect. This is false.

Counterexample: Consider this 5-node tree.

graph TD
    A(( )) --- B(( ))
    A --- C(( ))
    B --- D(( ))
    B --- E(( ))

• Full? Yes — every node has 0 or 2 children. ✅
• Complete? Yes — levels 0 and 1 are fully-filled, and level 2 is filled from the left. ✅
• Perfect? No — level 2 is not fully-filled $\Rightarrow$ all leaves are not at the same depth ❌

The key insight is that completeness only requires the last level to be left-filled; it does not require the last level to be fully filled. And fullness only bans single-child nodes; it says nothing about leaf depths. Combined, the two properties are still not strong enough to force all leaves to the same depth.

When does full + complete $=$ perfect?

When the number of nodes $n = 2^{h+1} - 1$ for some $h$ (i.e., the last level is fully-filled). In that case — and only that case — a complete tree is also perfect (and, trivially, also full).

Benchmark results

Field multiplication wins handily.

Why?

The scalar field multiplication in blstrs is a single 256-bit Montgomery multiplication implemented in hand-tuned assembly. Blake3, while blazingly fast for a hash function, still has to run its compression function which involves many more operations.

Reproduce it yourself

git clone https://github.com/alinush/bench-crypto
cd bench-blake3-vs-field
cargo bench

References

For cited works, see below 👇👇

Preliminaries

• bolded, lowercase variables (e.g., $\s$) denote column vectors in $\F^m\bydef \F^{m\times 1}$.
• $n$ is the dimension
• $m$ is the number of samples

Introduction

The learning parity with noise (LPN) assumption was proposed in a 1993 CRYPTO paper by Blum, Furst, Kearns and Lipton¹.

Informally, the computational variant says that, for a public matrix $\A \in \F^{n \times m}$, a secret vector $\s\in \F^m$ and noise $\e\in \F^n$ sampled from an error distribution $\E$, it is hard to recover $\s$ from $(\A,\A\s+\e)$.

There is also a decisional variant that says it is hard to distinguish $(\A,\A\s+\e)$ from $(\A,\b)$, when $\b\randget \F^n$ (uniformly) and $\e$ is sampled appropriately from $\E$.

There is also a dual LPN variant introduced by Micciancio and Mol², which says that for a public matrix $\G\randget \mathcal{G}$, where $\mathcal{G}$ is a generator distribution, and noise $\e$ sampled from $\E$, it is hard to recover $\e$ from $(\G,\G\e)$

References

For cited works, see below 👇👇

Resources

• GKR sumcheck tutorial, by Angold Wang

References

For cited works, see below 👇👇

Notes

This is a research blog post on the state-of-the-art PQ signature schemes.

Steps:

• Surveyed NIST’s Round 2 additonal candidates¹
  • Filtered after Round 1. (See status report².)
  • See all schemes here, with the advanced ones marked in $\textcolor{blue}{\text{blue}}$
    • A criticism: The MPC-in-the-Head schemes actually rely on all sorts of exotic assuptions. The caption makes it seem like they do not, which is confusing.
• Looked at FAEST
  • Not as fast to verify as SPHINCS+
  • Better if faster signing is desired (e.g., consensus signatures)
• Looked at SLH-DSA (SPHINCS+)
  • This is ideal for the blockchain setting: minimal assumptions (just hashing), verification time descreases with signature size (by trading off signing time), standardized, sufficiently-succinct (e.g., 7.67 KiB)
• Found all FIPS standards³; not that many, hm.

FAEST

See FAEST website for a full list of resources.

Notes:

• introduced in 2023⁴
• based on AES128/192/256 and Vector Oblivious Linear Evaluation (VOLE) in the head (VOLEiTH)
  • VOLEitH is constructed only from symmetric-key primitives
• NIST cites it as “somewhat complex” and says “the security proof is very technical.”²

Construction

\begin{align} \pk &= (x,y)\\
\sk &= k \end{align} such that: \begin{align} E_k(x) = y,\ \text{where}\ E\ \text{is a block cipher} \end{align}

Signing works by doing a ZKPoK of $k$ using VOLEitH and the QuickSilver information-theoretic proof system⁵ (under the Fiat-Shamir transform).

Sizes

Secret and public keys are small: 32 bytes at 128-bit security.

Signature sizes are described below.

Performance

Benchmarked on:

“a single core of a consumer notebook with an AMD Ryzen 7 5800H processor, with a base clock speed of 3.2 GHz and 16 GiB memory.” “Simultaneous Multi-Threading was enabled.” The computer was running Linux 6.1.30, and the implementations were built with GCC 12.2.1.”

Unoptimized reference implementation is too slow (tens of milliseconds to verify):

But x86-64 AVX2 implementation could be practical at 128-bit security level (0.87 ms to verify 6,336-byte signatures):

These numbers are multi-threaded!

Perhaps this recent QuickSilver improvement⁶ will help? I quote: “For a circuit of size $\sizeof{C} = 2^{27}$, it shows up to 83.6× improvement on communication, compared to the general VOLE-ZK Quicksilver. In terms of running time, it is 70% faster when bandwidth is 10Mbps”.

Pratik Sarkar suggests it likely does not. And even if it does, it would require additively-homomorphic encryption like BGV, which would introduce additional assumptions.

SLH-DSA (SPHINCS+)

See SPHINCS website for a full list of resources.

• FIPS-standardized⁷
• stateless, hash-based (hence the “SLH” acronym?)
• “an SLH-DSA key pair contains $2^{63}, 2^{64}, 2^{66}$, or $2^{68}$ forest of random subsets (FORS) keys”
• “FORS allows each key pair to safely sign a small number of messages”
• “An XMSS key consists of $2^{h’}$ WOTS$^+$ keys and can sign $2^{h’}$ messages”
• a rather-involved construction; would need to dig deeper to see if there’s a simple design underneath
• “The SHA2-based parameter sets are 2x slower than the SHAKE-based ones”

Construction

Key generation, at a high-level, works like this:

(sk_seed, sk_prf, pk_seed) ← random()
root ← build_merkle_tree(sk_seed, pk_seed)
SK = (sk_seed, sk_prf, pk_seed, root)
PK = (pk_seed, root)

So, in the context of blockchain accounts, the user’s mnemonic should be used to deterministically derive the pk_seed. Otherwise, wallet recovery won’t work.

Sizes

Key and signature sizes from FIPS-205⁷:

sphincs-shake-128f benchmarks

16.69 KiB signature size, signing time is 17 ms and verification is 1.1 ms!

Benchmarking the reference implementation in C⁸ on my Apple Macbook Pro, M1 Max below. They only provide an ARM implementation for the SHAKE variant $\Rightarrow$ not sure what the SHA2 numbers would look like on ARM.

Are these numbers single-threaded?

Got this kpc_get_thread_counters failed, run as sudo? error (I think) during the thash benchmarks.

Building this variant on ARM via:

git clone https://github.com/sphincs/sphincsplus/
cd shake-a64/
make clean
make benchmark

The results, edited for clarity of exposition:

cc -Wall -Wextra -Wpedantic -Wmissing-prototypes -O3 -std=c99 -fomit-frame-pointer -flto -DPARAMS=sphincs-shake-128f  -o test/benchmark test/cycles.c hash_shake.c hash_shakex2.c thash_shake_robustx2.c address.c randombytes.c merkle.c wots.c utils.c utilsx2.c fors.c sign.c fips202.c fips202x2.c f1600x2_const.c f1600x2.s test/benchmark.c
wrong fixed counters count

arameters: n = 16, h = 66, d = 22, b = 6, k = 33, w = 16

Running 10 iterations.

thash                avg.        0.53 us
f1600x2              avg.        0.28 us
thashx2              avg.        0.58 us

Generating keypair.. avg.     1,294.10 us
  - WOTS pk gen 2x.. avg.       294.70 us
Signing..            avg.    17,255.30 us --> 17 ms
  - FORS signing..   avg.       853.00 us
  - WOTS pk gen x2.. avg.       176.80 us
Verifying..          avg.     1,096.50 us --> 1.1 ms

Signature size: 17,088 bytes (16.69 KiB)

Public key size: 32 bytes (0.03 KiB)
Secret key size: 64 bytes (0.06 KiB)

sphincs-shake-128s benchmarks

Clear winner: hash-based, 7.67 KiB signatures created in 336 ms that verify in 0.4 ms!

Building this variant on ARM by via:

git clone https://github.com/sphincs/sphincsplus/
cd shake-a64/
gsed -i 's/shake-128f/shake-128s/g' Makefile
make clean
make benchmark

Note that the Makefile was modified to build the shorter s-variant of SPHINCS+.

The results for sphincs-shake-128s, edited for clarity of exposition:

cc -Wall -Wextra -Wpedantic -Wmissing-prototypes -O3 -std=c99 -fomit-frame-pointer -flto -DPARAMS=sphincs-shake-128s  -o test/benchmark test/cycles.c hash_shake.c hash_shakex2.c thash_shake_robustx2.c address.c randombytes.c merkle.c wots.c utils.c utilsx2.c fors.c sign.c fips202.c fips202x2.c f1600x2_const.c f1600x2.s test/benchmark.c
wrong fixed counters count
Parameters: n = 16, h = 63, d = 7, b = 12, k = 14, w = 16

Running 10 iterations.

thash                avg.        0.94 us
f1600x2              avg.        0.38 us
thashx2              avg.        0.66 us

Generating keypair.. avg.    46,510.80 us
  - WOTS pk gen 2x.. avg.       178.80 us
Signing..            avg.   336,702.20 us --> 336.7 ms
  - FORS signing..   avg.    22,816.50 us
  - WOTS pk gen x2.. avg.       176.40 us
Verifying..          avg.       396.10 us --> 0.396 ms

Signature size: 7,856 bytes (7.67 KiB)

Public key size: 32 bytes (0.03 KiB)
Secret key size: 64 bytes (0.06 KiB)

Performance of RustCrypto/signatures

Seems like a single-threaded implementation.

Bechmarked via:

git clone https://github.com/RustCrypto/signatures
cd slh-dsa/
cargo bench

SHA2 variants are faster. It may be because they leverage native SHA2 instructions.

TODO

SIS-based schemes

GPV hash-and-sign signatures and their plain-lattice descendants⁹. (Also see this.) “Fiat-Shamir with Aborts” signatures¹⁰$,$¹¹. Squirrels. HuFu. (Also see this survey.)

ML-DSA

Investigate ML-DSA, based on MLWE.

Others

HAWK.

References

For cited works, see below 👇👇

$\mathbb{V}$cash anonymous payments experiments

Ran a subset of the (modified) benchmarks, in a single thread, on my Apple Macbook Pro M1 Max. The benchmared scheme does not implement a proper PRF-based nullifier scheme, AFAICT. It does prove values are in-range using Bulletproofs. (I think it combines the range proof statement with the curve tree statement over the curve used in the leaves, and proves it all in one.)

See diff here.

Results over Pasta and Vellas curves:

Single_threadedPour_Curves:pasta_L:1024_D:4_ProofSize: 3970 bytes

Single_threadedPour_Curves:pasta_L:1024_D:4/prove
                        time:   [7.1789 s 7.2110 s 7.2427 s]

Single_threadedPour_Curves:pasta_L:1024_D:4_batch_verification/1
                        time:   [298.39 ms 299.27 ms 300.13 ms]

Single_threadedPour_Curves:pasta_L:1024_D:4_batch_verification/100
                        time:   [2.1153 s 2.1255 s 2.1355 s]

Results over secp256k1 and secp256r1 curves:

Single_threadedPour_Curves:secp&q_L:1024_D:4_ProofSize: 3970 bytes

Single_threadedPour_Curves:secp&q_L:1024_D:4/prove
                        time:   [8.4621 s 8.4874 s 8.5097 s]

Single_threadedPour_Curves:secp&q_L:1024_D:4_batch_verification/1
                        time:   [347.31 ms 348.01 ms 348.73 ms]

Single_threadedPour_Curves:secp&q_L:1024_D:4_batch_verification/100
                        time:   [2.4206 s 2.4312 s 2.4428 s]

The range proofs can probably be sped up using DeKART.

References

For cited works, see below 👇👇

For hashing

Explain Aptos’s strategy.

For proof systems

A domain separator in the context of proof systems (e.g., $\Sigma$-protocols, ZK range proofs, etc.) should consist of three things¹:

1. Protocol identifier, which can often be split up into:
   • higher-level protocol identifier: e.g., “Confidential Assets v1 on Aptos”
   • lower-level relation identifier: e.g., “PedEq”
2. Session identifier
   • chosen by the user
   • specifies the context where this proof is valid
   • e.g., “Alice (0x1) is paying Bob (0x2) at time $t$”)
   • motivation is to prevent replay attacks (e.g., PoK of SK) or cross-protocol attacks
   • this one is trickier, I think: in some settings the “session” accumulates naturally in the statement being proven
     • e.g., in Aptos Confidential Assets, the “session” is represented by the confidential balances of the users & their addresses
3. Statement identifier
   • i.e., be sure to hash the public statement being proven
   • here people forget that “public parameters” are part of the statement!
   • e.g., in a Schnorr proof it is crucial to hash the generator $G$!

This suggests that a domain separator dst should consist of:

• a protocol_id
• a session_id
• a statement, which is already an argument to a proof system anyway

References

For cited works, see below 👇👇

Preliminaries

We assume familiarity with:

• PVSS, as an abstract cryptographic primitive.
  • In particular, the notion of a PVSS transcript will be used a lot.
• Digital signatures
  • i.e., sign a message $m$ as $\sigma \gets \sig.\sign(\sk, m)$ and verify via $\sig.\verify(\pk, \sigma, m)\equals 1$
• ElGamal encryption
• Batched range proofs (e.g., DeKART)
• ZKSoKs (i.e., $\Sigma$-protocols that implicitly sign over a message by feeding it into the Fiat-Shamir transform).
• The SCRAPE low-degree test

All of these will be described in more detail in the subsections below.

Notation

Pairing-friendly groups notation

• Let $\GGen(1^\lambda) \rightarrow \mathcal{G}$ denote a probabilistic polynomial-time algorithm that outputs bilinear groups $\mathcal{G} \bydef (\Gr_1, \Gr_2, \Gr_T)$ of prime order $p\approx 2^{2\lambda}$, denoted additively, such that:
  • $\one{1}$ generates $\Gr_1$
  • $\two{1}$ generates $\Gr_2$
  • $\three{1}$ generates $\Gr_T$
• We use $\one{a}\bydef a\cdot \one{1}$ and $\two{b}\bydef b\cdot \two{1}$ and $\three{c}\bydef c\cdot \three{1}$ to denote multiplying a scalar by the group generator

• Let $\F$ denote the scalar field of order $p$ associated with the bilinear groups

• We often use capital letters like $G$ or $H$ to denote group elements in $\Gr_1$
• We often use $\widetilde{G}$ or $\widetilde{H}$ letters to denote group elements in $\Gr_2$

Time-complexity notation

• For time complexities, we use:
  • $\Fadd{n}$ for $n$ field additions in $\F$

  • $\Fmul{n}$ for $n$ field multiplications in $\F$

  • $\Gadd{\Gr}{n}$ for $n$ additions in $\Gr$
  • $\Gmul{\Gr}{n}$ for $n$ individual scalar multiplications in $\Gr$
  • $\fmsm{\Gr}{n}$ for a size-$n$ MSM in $\Gr$ where the group element bases are known ahead of time (i.e., fixed-base)
    • when the scalars are always from a set $S$, then we use $\fmsmSmall{\Gr}{n}{S}$
  • $\vmsm{\Gr}{n}$ for a size-$n$ MSM in $\Gr$ where the group element bases are not known ahead of time (i.e., variable-base)
    • when the scalars are always from a set $S$, then we use $\vmsmSmall{\Gr}{n}{S}$
  • $\pairing$ for one pairing
  • $\multipair{n}$ for a size-$n$ multipairing

Other notation

• $[n]\bydef \{1,2,\ldots,n\}$
• $[n) \bydef \{0,1,2,\ldots,n-1\}$

ElGamal encryption

Assuming familiarity with ElGamal encryption:

$E.\mathsf{KeyGen}_H()\rightarrow (\mathsf{dk},\mathsf{ek})$

Generate the key-pair: \begin{align} \dk &\randget\F\\
\ek &\gets \dk \cdot H \end{align}

$E.\mathsf{Enc}_{G,H}\left(\mathsf{ek}, v; r\right) \rightarrow \left(C, R\right)$

Compute: \begin{align} C &\gets v \cdot G + r \cdot \ek\\
R &\gets r \cdot H \end{align}

$E.\mathsf{Dec}_{G}\left(\mathsf{dk}, (C, R)\right) \rightarrow v$

\begin{align} v &\gets \log_G\left(C - \dk\cdot R\right)\\
&= \log_G\left((v \cdot G + r \cdot \ek) - \dk\cdot (r \cdot H)\right)\\
&= \log_G\left(v \cdot G + r \cdot \ek - (r \cdot \dk) \cdot H\right)\\
&= \log_G\left(v \cdot G + r \cdot \ek - r \cdot \ek\right)\\
&= \log_G\left(v \cdot G\right) = v\\
\end{align}

Decryption will only work for sufficiently “small” values $v$ such that computing discrete logarithms on $v \cdot G$ is feasible (e.g., anywhere from 32 bits to 64 bits).

Univariate DeKART batched ZK range proofs

Assuming familiarity with batched ZK range proofs¹. In particular, we will use univariate DeKART as our range proof scheme, formalized below.

$\dekart_b.\setup(N; \mathcal{G})\rightarrow (\mathsf{prk},\mathsf{ck},\mathsf{vk})$

Sets up the ZK range proof to prove batches of size $\le N$, returning a proving key, a commitment key and a verification key. (See implementation here.)

$\dekart_b.\commit(\ck,z_1,\ldots,z_N; \rho)\rightarrow C$

Returns a commitment $C$ to a vector of $N$ values using randomness $\rho$. (See implementation here.)

$\dekart_b.\prove(\prk, C, \ell; z_1,\ldots,z_N, \rho)\rightarrow \pi$

Returns a ZK proof $\pi$ that the $N$ values committed in $C$ are all in $[0, b^\ell)$. (See implementation here.)

$\dekart_b.\verify(\vk, C, \ell; \pi)\rightarrow \{0,1\}$

Verifies that the $N$ values committed in $C$ are all in $[0, b^\ell)$. (See implementation here.)

Zero-knowledge Signatures of Knowledge (ZKSoKs)

Assuming familiarity with ZKSoKs², which typically consist of two algorithms:

$\sok.\prove(\mathcal{R}, m, \stmt; \witn) \rightarrow \pi$

Returns a ZK proof of knowledge of $\witn$ s.t. $\mathcal{R}(\stmt;\witn) = 1$ and signs the message $m$ in the process.

$\sok.\verify(\mathcal{R}, m, \stmt; \pi) \rightarrow \{0,1\}$

Verifies a ZK proof of knowledge of some $\witn$ s.t. $\mathcal{R}(\stmt;\witn) = 1$ and that the message $m$ was signed.

The ElGamal-to-KZG NP relation

One of the key ingredients in our PVSS will be a ZK proof of knowledge of share chunks such that they are both ElGamal-encrypted and KZG-committed.

This is captured via the NP relation below: \begin{align} \label{rel:e2k} \term{\Retk}\left(\begin{array}{l} \stmt = \left(G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C\right),\\
\witn = \left(\{s_{i,j,k}\}_{i,j,k}, \{r_{j,k}\}_{j,k}, \rho\right) \end{array}\right) = 1\Leftrightarrow\\
\Leftrightarrow\left\{\begin{array}{rl} (C_{i,j,k}, R_{j,k}) &= E.\enc_{G,H}(\ek_i, s_{i,j,k}; r_{j,k})\\
C& = \dekart_2.\commit(\ck, \{s_{i,j,k}\}_{i,j,k}; \rho)\\
\end{array}\right. \end{align}

where the $s_{i,j,k}$’s will be “flattened” as a vector (in a specific order) before being input to $\dekart_2.\commit(\cdot)$.

We will explain how this flattening works later in the $\pvssDeal$ algorithm.

The SCRAPE low-degree test

Explain!

Building a DKG from a PVSS

Our goal is to get a weighted DKG³ for field elements amongst the validators of a proof-of-stake blockchain, such that the DKG (final, shared) secret $\term{z}$ is only reconstructable by a fraction $> \term{\threshQ}$ of the stake (e.g., $\threshQ = 0.5$ or 50%).

How? Each validator $i$ will “contribute” to $z$ by picking their own secret $\term{z_i} \in \F$ and dealing it to the other validators via $\term{\pvssDeal}$ in a non-malleable fashion such that only a $> \emph{\threshQ}$ fraction of the stake can reconstruct $z_i$. The DKG secret will be set to $z \bydef \sum_{i\in Q} z_i$, where $\term{Q}$ is the eligible (sub)set of validators who correctly dealt their $z_i$.

Crucially, $Q$ must be large “enough”: i.e., it must have “enough” validators to guarantee that no malicious subset of them can learn (or can bias the choice of) $z$. For example, we could assume only 33% of the stake⁴ is malicious and require that $Q$ have more stake than that. We denote the stake of the validators in $Q$ by $\term{\norm{Q}}$.

The DKG is parameterized by $\norm{Q}$ and by $\threshQ$. Since, typically in a DKG, the same set of validators will deal a secret amongst themselves, $\norm{Q}$ and $\threshQ$ are typically set to the same value. Otherwise, if $\norm{Q} < \threshQ$, then the validators in $Q$ could reconstruct the secret even though they do not have $> \threshQ$ of the stake, which defeats the point. Alternatively, if $\norm{Q} > \threshQ$, then the protocol would be requiring more validators to contribute than needed for secrecy, since $\threshQ < \norm{Q}$ can reconstruct.

First, to publicly-prove that $\norm{Q}$ is large “enough”, each validator will digitally-sign their dealt PVSS transcript in a domain-separated fashion (part of the domain separator will be the current consensus epoch number). Without such authentication, $Q$ could be filled with transcripts from one malicious validator impersonating the other ones. Therefore, that malicious validator would have full knowledge of the final DKG secret $z$. ($\Rightarrow$ No es bueno.)

Implication: The DKG protocol needs to be carefully crafted to sign the PVSS transcripts. If done right, the validators’ public keys used to sign blockchain consensus messages can be safely reused as signing public keys for the transcript. (If done right.)

Second, we require that PVSS transcripts obtained from $\pvssDeal$ be non-malleable. To see why this is necessary consider the following scenario:

• two validators $i$ and $j$ have enough stake to form an eligible subset $Q = \{i,j\}$ with $\norm{Q} > \threshQ$
• $j$ by itself does not have enough stake
• $i$ deals $z_i \in \F$ and signs the transcript
• $j$ removes $i$’s signature and mauls $i$’s transcript to deal $-z_i + r$ for some $r\randget\F$ it knows
• $j$ signs this mauled transcript
  • $\Rightarrow j$ would have full knowledge of the final DKG secret $z = z_i + (- z_i + r) = r$.

Implication: The PVSS transcript will include a zero-knowledge signature of knowledge (ZKSoK) of the dealt secret $z_i$. This way, the dealt secret cannot be mauled without rendering the transcript invalid. Importantly, the ZKSoK signature will include the signing public key of the dealer. This way, validator $j$ cannot bias the final DKG secret $z$ by appropriating validator $i$’s transcript as their own (i.e., by stripping validator $i$’s signature from the transcript, adding their own signature and leaving the dealt secret $z_i$ untouched).

Chunky: A weighted, non-malleable PVSS

Notation:

• Let $\term{n}$ denote the number of players
  • Note: In our setting, the PoS validators will act as the players
• Let $\term{\maxTotalWeight}$ denote the maximum total weight $\Leftrightarrow$ maximum # of shares that we will ever want to deal in the PVSS
• Let $\term{\ell}$ denote the chunk bit-size (e.g., $\ell=32$ for 32-bit chunks)
• Let $\term{m} = \ceil{\log_2{\sizeof{\F}} / \ell}$ denote the number of chunks per share
• Let $\term{B}\bydef 2^\ell$ denote the maximum value of a chunk (e.g., $B=2^{32}$ for 32-bit chunks)

The algorithms below describe Chunky, a weighted PVSS where only subsets of players with combined weight $> \threshWeight$ can reconstruct the shared secret.

$\mathsf{PVSS}.\mathsf{Setup}(\ell, W_\mathsf{max}; \mathcal{G}, \widetilde{G}) \rightarrow \mathsf{pp}$

Recall that $\emph{\maxTotalWeight}$ is the max. total weight, $\emph{\ell}$ is the # of bits per chunk and $\emph{m}$ is the number of chunks a share is split into.

$\term{\widetilde{G}}\in\Gr_2$ will be the base used to commit to the shares in $\pvssDeal$.

Step 1: Set up the ElGamal encryption: \begin{align} \term{G},\term{H} &\randget \Gr_1 \end{align}

Step 2: Set up the ZK range proof to batch prove that $\le \maxTotalWeight\cdot m$ share chunks are all $\ell$-bit wide:

\begin{align} (\prk,\ck,\vk) \gets \dekart_2.\setup(\maxTotalWeight\cdot m; \mathcal{G}) \end{align}

Note that DeKART assumes that the field $\F$ admits a $2^\kappa$-th primitive root of unity where $2^\kappa$ is the smallest power of two $\ge \maxTotalWeight\cdot m + 1$. (The ZK range proof needs FFTs of size $\maxTotalWeight\cdot m$.)

Return the public parameters: \begin{align} \pp \gets (\ell, \maxTotalWeight, G, \widetilde{G}, H, \prk,\ck,\vk) \end{align}

$\mathsf{PVSS}.\mathsf{Deal}_\mathsf{pp}\left(a_0, t_W, \{w_i, \mathsf{ek}_i\}_{i\in [n]}, \mathsf{ssid}\right) \rightarrow \mathsf{trs}$

$a_0$ is the dealt secret. $w_i$’s are the weights of each player, including the dealer’s (i.e., $w_\pid$). $\ssid$ is a session identifier, which will be set to the consensus epoch number in which the DKG is taking place and calls this PVSS deal algorithm.

Parse public parameters: \begin{align} (\ell, \maxTotalWeight, G, \widetilde{G}, H, \prk,\ck,\vk)\parse\pp \end{align}

Compute the total weight and assert that the public parameters can accommodate it: \begin{align} \label{eq:W} \term{W} &\gets \sum_{i\in[n]} w_i\\
\textbf{assert}\ W &\le \maxTotalWeight \end{align}

Find a $2^\kappa$-th root of unity $\term{\omega} \in \F$ such that we can efficiently compute FFTs of size $W$ (i.e., smallest $2^\kappa \ge W$).

Step 1: Pick the degree-$\threshWeight$ random secret sharing polynomial and compute the $j$th share of player $i$: \begin{align} \term{a_1,\ldots,a_t} &\randget \F\\
\term{f(X)} &\bydef \emph{a_0} + a_1 X + a_2 X^2 + \ldots + a_t X^\threshWeight\\
\label{eq:eval} \term{s_{i, j}} &\gets f\left(\term{\chi_{i,j}}\right),\forall i\in[n],\forall j\in[w_i] \end{align}

Note: Assuming that the set of evaluation points $\emph{\{\chi_{i,j}\}}$ are wisely set to be the first $W$ roots of unity in $\{\omega^{i’}\}_{i’\in [0,W)}$, then the $s_{i,j}$’s would be quickly-computable in $\Fmul{O(W\log{W})}$ via an FFT.

Step 2: Commit to the shares, $\forall i\in[n],\forall j\in[w_i]$: \begin{align} \label{eq:share-commitments} \term{\widetilde{V}_{i,j}} &\gets s_{i,j} \cdot \widetilde{G} \in \Gr_2\\
\label{eq:dealt-pubkey} \term{\widetilde{V}_0} &\gets a_0 \cdot \widetilde{G} \end{align}

Step 3: Split each share $s_{i,j}$ into $\emph{m}\bydef \ceil{\log_2{\sizeof{\F}}} / \ell$ chunks $\term{s_{i,j,k}}$, of $\ell$-bits each, such that: \begin{align} s_{i,j} &= \sum_{k\in[m]} (2^\ell)^{k-1} \cdot \emph{s_{i,j,k}}\\
&\bydef \sum_{k\in[m]} \emph{B}^{k-1} \cdot s_{i,j,k}\\
\end{align}

Note: Each $s_{i,j,k} \in [0, B)$, where $B = 2^\ell$.

Step 4: $\forall i \in[n], j\in[w_i], k\in[m]$, encrypt the $k$th chunk of the $j$th share of player $i$: \begin{align} \term{r_{j,k}} &\randget \F\ \text{s.t.}\ \sum_{k\in[m]} B^{k-1}\cdot r_{j,k} = 0\\
\label{eq:share-ciphertexts} \term{(C_{i,j,k}, R_{j,k})} &\gets E.\enc_{G,H}(\ek_i, s_{i,j,k}; r_{j,k})\\
&\bydef \left(\begin{array}{l} s_{i,j,k} \cdot G + r_{j,k}\cdot \ek_i\\
r_{j,k}\cdot H\end{array}\right) \end{align}

Observation 1: The randomness has been correlated such that: \begin{align} \label{eq:correlated} \sum_{k\in[m]} B^{k-1} \cdot C_{i,j,k} &= \sum_{k\in[m]} B^{k-1} \cdot (s_{i,j,k} \cdot G + r_{j,k}\cdot \ek_i)\\
&= \underbrace{\sum_{k\in[m]} (B^{k-1} \cdot s_{i,j,k})}_{s_{i,j}} \cdot G + \underbrace{\sum_{k\in [m]} (B^{k-1} \cdot r_{j,k})}_{0}\cdot \ek_i\\
&= s_{i,j} \cdot G + 0 \cdot \ek_i = s_{i,j} \cdot G \end{align}

Observation 2: Different players $i$ will safely re-use the same $r_{j,k}$ randomness.

Observation 3: $\sizeof{\{R_{j,k}\}_{j,k}} = m\cdot \max_{i\in[n]}{(w_i)}$

The cumulative weight up to (but excluding) $i$ is $\term{W_i}$ such that $\emph{W_1} = 0$ and $\emph{W_i} = \sum_{i’\in [1, i)} w_{i’}$. (Note that $W \bydef W_{n+1}$.) This notion helps us “flatten” all the share chunks $s_{i,j,k}$ into an array $\{z_{i’}\}_{i’\in [W \cdot m]}$, where $z_{i’} \bydef s_{i,j,k}$ with $i’\gets \left(\emph{W_i} + (j-1)\right)\cdot m + k \bydef \term{\idx(i,j,k)}$ (see appendix for how the indexing was derived).

Step 5: Prove that the share chunks are correctly encrypted and are all $\ell$-bit long.

First, “flatten” all the shares into a vector. $\forall i\in[n], j\in[w_i],\forall k\in[m]$: \begin{align} \term{z_{i’}} \gets s_{i,j, k},\ \text{where}\ i’ &\bydef \emph{\idx}(i,j,k)\in[W\cdot m] \end{align}

Second, KZG commit to the share chunks and prove they are all in range: \begin{align} \rho &\randget \F\\
\term{C} &\gets \dekart_2.\commit(\ck, z_1, \ldots, z_{W \cdot m}; \rho)\\
\term{\piRange} &\gets \dekart_2.\prove(\prk, C, \ell, z_1, \ldots, z_{W\cdot m}; \rho) \end{align}

Step 6: Compute a signature of knowledge of the dealt secret key $a_0$ over the session ID: \begin{align} \term{\ctx} &\gets (\threshWeight, \{w_i\}_i, \ssid)\\
\term{\piSok} &\gets \sok.\prove\left(\begin{array}{l} \Retk, \emph{\ctx},\\
\underbrace{G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C}_{\stmt},\\
\underbrace{\{s_{i,j,k}\}_{i,j,k}, \{r_{j,k}\}_{j,k}, \rho}_{\witn} \end{array}\right) \end{align}

Return the transcript: \begin{align} \label{eq:proof} \term{\pi} &\gets \left(C, \piRange, \piSok\right)\\
\label{eq:trs} \trs &\gets \left(\widetilde{V}_0, \{\widetilde{V}_{i,j}\}_{i,j\in[w_i]}, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k}, \emph{\pi}\right) \end{align}

$\mathsf{PVSS}.\mathsf{Verify}_\mathsf{pp}\left(\mathsf{trs}, t_W, \{w_i, \mathsf{ek}_i\}_{i\in[n]}, \mathsf{ssid}\right) \rightarrow \{0,1\}$

Parse public parameters: \begin{align} (\ell, \cdot, G, \widetilde{G}, H, \cdot,\cdot,\vk)\parse\pp \end{align}

Parse the transcript: \begin{align} \left(\widetilde{V}_0, \{\widetilde{V}_{i,j}\}_{i,j\in[w_i]}, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k}, \left(C, \piRange, \piSok\right)\right)\parse\trs \end{align}

Let the total weight $W$ be defined as before in Eq. \ref{eq:W}.

Step 1: Verify that the committed shares encode a degree-$\threshWeight$ polynomial via the SCRAPE LDT⁵: \begin{align} \term{\alpha} &\randget \F\\
\textbf{assert}\ &\scrape.\lowdegreetest(\{(0, \widetilde{V}_0)\} \cup \{(\chi_{i,j}, \widetilde{V}_{i,j})\}_{i,j}, \threshWeight, W; \emph{\alpha}) \equals 1 \end{align}

Note: Recall that the $\emph{\chi_{i,j}}$’s are the roots of unity used to evaluate the secret-sharing polynomial $f(X)$ during dealing (see Eq. \ref{eq:eval}).

May need to feed in the size of the evaluation domain to SCRAPE for the super-efficient algorithm.

Step 2: Check that ciphertexts encrypt the committed shares: \begin{align} \term{\beta_{i,j}} &\randget\{0,1\}^\lambda\\
\label{eq:multi-pairing-check} \textbf{assert}\ &\pair{\sum_{i\in[n],j\in[w_i],k\in[m]} (B^{k-1}\cdot\emph{\beta_{i,j}})\cdot C_{i,j,k}}{\widetilde{G}} \equals \pair{G}{\sum_{i\in[n],j\in[w_i]} \emph{\beta_{i,j}}\cdot \widetilde{V}_{i,j}} \end{align}

Step 3: Verify the range proof: \begin{align} \textbf{assert}\ \dekart_2.\verify(\vk, C, \ell; \piRange) \equals 1 \end{align}

Step 4: Verify the SoK: \begin{align} \term{\ctx} &\gets (\threshWeight, \{w_i\}_i, \ssid)\\
\textbf{assert}\ &\sok.\verify\left(\begin{array}{l} \Retk, \emph{\ctx},\\
\underbrace{G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C}_{\stmt};\\
\piSok \end{array}\right) \equals 1 \end{align}

$\mathsf{PVSS}.\mathsf{Decrypt}_\mathsf{pp}\left(\mathsf{trs}, \mathsf{dk}, i, w_i\right) \rightarrow \{s_{i,j}\}_j \in \F$

$i\in[n]$ is the ID of the player who is decrypting their share(s) from the transcript. Recall that $\emph{m}\bydef \ceil{\log_2{\sizeof{\F}} / \ell}$ is the number of chunks per share.

Parse public parameters: \begin{align} (\ell, \cdot, G, \cdot, \cdot, \cdot,\cdot,\cdot)\parse\pp \end{align}

Parse the transcript: \begin{align} \left(\cdot, \cdot, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k},\cdot\right)\parse\trs \end{align}

Step 1: Decrypt all of player $i$’s share chunks $\{s_{i,j,k}\}_{i,j\in[w_i],k\in[m]}$: \begin{align} s_{i,j,k}\gets E.\dec_{G}\left(\dk_i, (C_{i,j,k}, R_{j,k})\right) \end{align}

Step 2: Assemble the chunks back into shares: \begin{align} s_{i,j}\gets \sum_{k\in[m]} (2^\ell)^{k-1} \cdot s_{i,j,k} \end{align}

Weighted DKG protocol

Below, we give a high-level sketch of our $\threshWeight$-out-of-$\{w_i\}_{i\in[n]}$ weighted DKG with contributions from $> \emph{\threshQ}$ fraction of the stake.

But first, we have to slightly augment our notion of a non-malleable PVSS, denoted by $\pvss$, into a signed, subaggregatable and non-malleable PVSS, denoted by $\term{\ssPvss}$. This will make building a DKG protocol much easier.

First, recall from before that validators must sign their PVSS transcripts in the DKG protocol. Thus, the $\term{\ssPvss.\deal}$ and $\term{\ssPvss.\verify}$ algorithms will differ slightly:

1. dealing now takes a signing secret key $\term{\sk}$ as input and additionally returns a signature $\term{\sigma}$
2. verification now takes a signing pubkey $\term{\pk}$ and the signature $\sigma$ as input

Second, we introduce a useful notion of an aggregatable PVSS subtranscript $\term{\subtrs}$ which excludes the non-aggregatable components of the PVSS transcript $\emph{\trs}$ from Eq. \ref{eq:trs} (i.e., the proof $\pi$ from Eq. \ref{eq:proof}).

Third, we define a new $\term{\ssPvssSubtranscript}$ algorithm which returns such a $\subtrs$. In Chunky’s case, this will consist of only:

1. The dealt pubkey $\widetilde{V}_0$ as defined in Eq. \ref{eq:dealt-pubkey}
2. The share commitments (i.e., all share commitments $\widetilde{V}_{i,j}$ as defined in Eq. \ref{eq:share-commitments})
3. The share chunk ciphertexts (i.e., all share ciphertexts $(C_{i,j,k}, R_{j,k})$ as defined in Eq. \ref{eq:share-ciphertexts})

Fourth, and last, we will also define a $\term{\ssPvssSubaggregate}$ algorithm which takes several subtranscripts $\{\subtrs_i\}_i$ and aggregates them into a single $\subtrs$. This way, two subtranscripts $\subtrs_1$ and $\subtrs_2$ dealing secrets $z_1$ and $z_2$, respectively, can be succinctly combined into a $\subtrs$ dealing $z_1 + z_2$ (such that $\sizeof{\subtrs} = \sizeof{\subtrs_i}, \forall i\in\{1,2\}$).

We detail the new algorithms for this signed, subaggregatable, non-malleable PVSS below. (Note that the $\setup$ and $\decrypt$ algorithms remain the same.)

$\mathsf{ssPVSS}.\mathsf{Deal}_\mathsf{pp}\left(\mathsf{sk}, a_0, t_W, \{w_i, \mathsf{ek}_i\}_{i\in [n]}, \mathsf{ssid}\right) \rightarrow (\mathsf{trs},\sigma)$

Deal a normal PVSS transcript via $\pvssDeal$ but also sign over it and over the session ID: \begin{align} \trs &\gets \pvssDeal(a_0, \threshWeight, \{w_i,\ek_i\}_{i\in[n]}, \ssid)\\
(\tilde{V}_0,\cdot,\cdot,\cdot,\cdot)&\parse \trs\\
\sigma &\gets \sig.\sign(\sk, (\tilde{V}_0, \ssid)) \end{align}

$\mathsf{ssPVSS}.\mathsf{Verify}_\mathsf{pp}\left(\pk, \mathsf{trs}, \sigma, t_W, \{w_i, \mathsf{ek}_i\}_{i\in[n]}, \mathsf{ssid}\right) \rightarrow \{0,1\}$

Do a normal PVSS transcript verification via $\pvssVerify$ but also verify the signature over it and the session ID: \begin{align} \textbf{assert}\ \pvssVerify(\trs, \threshWeight, \{w_i,\ek_i\}_{i\in[n]}, \ssid) &\equals 1\\
(\tilde{V}_0,\cdot,\cdot,\cdot,\cdot) &\parse \trs\\
\textbf{assert}\ \sig.\verify(\pk, \sigma, (\tilde{V}_0, \ssid)) &\equals 1 \end{align}

$\mathsf{ssPVSS}.\mathsf{Subtranscript}\left(\mathsf{trs}\right) \rightarrow \mathsf{subtrs}$

Parse the transcript as defined in Eq. \ref{eq:trs}: \begin{align} \left(\widetilde{V}_0, \{\widetilde{V}_{i,j}\}_{i,j\in[w_i]}, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k}, \cdot \right)\parse\trs \end{align}

Return the aggregatable subtranscript: \begin{align} \label{eq:subtrs} \subtrs &\gets \left(\widetilde{V}_0, \{\widetilde{V}_{i,j}\}_{i,j\in[w_i]}, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k}\right)\\
\end{align}

$\mathsf{ssPVSS}.\mathsf{Subaggregate}_\mathsf{pp}\left(\{\mathsf{subtrs}_{i’}\}_{i’}\right) \rightarrow \mathsf{subtrs}$

Parse public parameters: \begin{align} (\ell, \cdot, \cdot, \cdot, \cdot, \cdot,\cdot,\cdot)\parse\pp \end{align}

Parse all the aggregatable subtranscripts, for all $i’$: \begin{align} \left(\widetilde{V}^{(i’)}_0, \{\widetilde{V}^{(i’)}_{i,j}\}_{i,j\in[w_i]}, \{C^{(i’)}_{i,j,k}\}_{i,j\in[w_i],k}, \{R^{(i’)}_{j,k}\}_{j\in[\max_i{w_i}],k}\right)\parse \subtrs_{i’}\\
\end{align}

Recall that $\emph{n}$ denotes the number of players that a transcript deals to and recall that $\emph{m} = \ceil{\log_2{\sizeof{\F}} / \ell}$ denotes the number of chunks per share.

Aggregate: \begin{align} \term{\widetilde{V}_0} &\gets \sum_{i’} \widetilde{V}^{(i’)}_0\\\ \forall i\in[n],j\in[w_i], \term{\widetilde{V}_{i,j}} &\gets \sum_{i’} \widetilde{V}^{(i’)}_{i,j}\\
\forall i\in[n],j\in[w_i],k\in[m], \term{\widetilde{C}_{i,j,k}} &\gets \sum_{i’} C^{(i’)}_{i,j,k}\\
\forall j\in[w_i],k\in[m], \term{\widetilde{R}_{j,k}} &\gets \sum_{i’} R^{(i’)}_{j,k}\\
\end{align}

Return the aggregated subtranscript: \begin{align} \subtrs &\gets \left(\widetilde{V}_0, \{\widetilde{V}_{i,j}\}_{i,j\in[w_i]}, \{C_{i,j,k}\}_{i,j\in[w_i],k}, \{R_{j,k}\}_{j\in[\max_i{w_i}],k}\right)\\
\end{align}

DKG overview

A DKG will occur within the context of a consensus epoch $\term{\epoch}$. All validators know each other’s public keys. Specifically, every validator $i$ has signing pubkey $\term{\pk_{i’}}$ (with signing secret key $\term{\sk_{i’}}$) and encryption key $\ek_i$⁶.

Dealing phase: Each validator $i’\in[n]$ picks a random secret $\term{z_{i’}}\in\F$ and computes a PVSS transcript that deals it: \begin{align} \emph{z_{i’}} &\randget \F\\
\term{\ssid_{i’}} &\gets (i’, \emph{\pk_{i’}}, \emph{\epoch})\\
\term{\trs_{i’}, \sigma_{i’}} &\gets \ssPvssDeal(\emph{\sk_{i’}}, z_{i’}, \threshWeight, \{w_i,\ek_i\}_{i\in[n]}, \emph{\ssid_{i’}})\\
\end{align}

Our current $\ssPvssDeal$ Rust implementation in aptos-dkg returns a chunky::Transcript struct that will contain both the actual transcript $\trs_{i’}$ and its signature $\sigma_{i’}$.

Then, each validator $i’$ (best-effort) disseminates $(\trs_{i’}, \sigma_{i’})$ to all other validators. Eventually, each validators $i’$ will have its own view of a set $\term{Q_{i’}}$ of validators who correctly-dealt a (single) transcript, as well as the actual signed transcripts themselves.

Agreement phase: In this phase, validators will agree on an aggregated subtranscript $\term{\subtrs}$ obtained from a “large-enough” eligible set $\emph{Q}$ of honest validators. More formally, the agreed-upon $(Q,\subtrs)$ will have the following three properties: \begin{align} &\norm{Q} > \threshQ\\
\label{eq:trs-verifies} &\forall j’ \in Q, \exists (\term{\trs_{j’},\sigma_{j’}}),\ \text{s.t.}\ \ssPvssVerify(\pk_{j’}, \emph{\trs_{j’}, \sigma_{j’}}, \threshWeight, \{w_i,\ek_i\}_{i\in[n]}, (\underbrace{j’, \pk_{j’}, \epoch}_{\emph{\ssid_{j’}}})) \goddamnequals 1\\
\label{eq:subtrs-aggr} &\emph{\subtrs} \goddamnequals \ssPvssSubaggregate(\{\ssPvssSubtranscript(\trs_{j’})\}_{j’ \in Q}) \end{align}

Agreement on $Q$ could be reached inefficiently by running a Byzantine agreement phase for each transcript: i.e., validator $i’$ proposes its $(\trs_{i’}, \sigma_{i’})$ and if it collects “enough” attestations (e.g., signatures from a fraction $> \term{\threshS}$ of the stake, say, 33%⁷) on it, then $i’$ is accumulated in the set $Q$ so far. The downside of this approach is high latency: it requires one Byzantine agreement per contributing validator. For Aptos, specifically, it would also require sending too many validator TXNs.

Proposal sub-phase: To reach agreement on $(Q,\subtrs)$ efficiently, one of the validators (e.g., the consensus leader) sends a final DKG subtranscript proposal $(Q, h)$, where $h \gets H(\subtrs)$ and $H(\cdot)$ is a collision-resistant hash function.

Every validator $i’$ will attest to (i.e., sign) this proposal if they can verify that the hashed subtranscript in $h$ was actually aggregated from some set $\{\trs_{j’}\}_{j’\in Q}$ of transcripts that all passed verification as per Eq. \ref{eq:trs-verifies}.

More formally, validator $i’$ will attest to the $(Q, h)$ proposal via a signature $\term{\alpha_{i’}}\bydef \sig.\sign(\sk_{i’}, (Q, h))$, if and only if:

1. $\norm{Q} > \threshQ$
2. $\forall j’\in Q$, validator $i’$ eventually⁸ receives a single⁹ $(\trs_{j’},\sigma_{j’})$ s.t. $\ssPvssVerify(\pk_{j’}, \trs_{j’}, \sigma_{j’}, \threshWeight, \{w_i,\ek_i\}_{i\in[n]}, (j’, \pk_{j’}, \epoch)) \goddamnequals 1$
3. $h \equals H(\ssPvssSubaggregate(\{\ssPvssSubtranscript(\trs_{j’})\}_{j’\in Q}))$

Commit sub-phase: If the $(Q, h)$ proposal gathers “enough” attestations (i.e., $> \threshS$), the proposing validator sends a(n Aptos validator) TXN with $(Q, \subtrs, \{\alpha_{j’}\}_{j’\in \term{S}})$ to the chain, where $\emph{S}$ is the set of validators who attested with $\norm{S} > \threshS$.

(Note that this TXN includes the $\subtrs$ corresponding to the hash in the proposal $(Q,h)$.)

This TXN will be succinct as it only contains:

1. The aggregated subtranscript $\subtrs$
   • Note: Assuming elliptic curves over 256-bit base fields (e.g., BN254), $\sizeof{\subtrs} \bydef \underbrace{64}_{\widetilde{V}_0} + \underbrace{64 \cdot W}_{\widetilde{V}_{i,j}\text{'s}} + \underbrace{32 \cdot W\cdot m}_{C_{i,j,k}\text{'s}} + 32\cdot \underbrace{\max_i{w_i}\cdot m}_{R_{j,k}\text{'s}}$ as per Eq. \ref{eq:subtrs}
   • e.g., for total weight $W = 254$, $m=8$ chunks and $\max_i{w_i} = 5$, the size will be $64 + 64 \cdot 254 + 32 \cdot 254 \cdot 8 + 32 \cdot 5 \cdot 8 =$ 82,624 bytes $=$ 80.6875 KiB
   • If we increase $\max_i{w_i}$ to 7, we get $64 + 64 \cdot 254 + 32 \cdot 254 \cdot 8 + 32 \cdot \emph{7} \cdot 8 =$ 83,136 bytes $=$ 81.1875 KiB
2. Attestations $\alpha_{j’}$’s from at most all $n$ validators.
   • e.g., In Aptos, we are using BLS signatures¹⁰ over BLS12-381 curves¹¹ $\Rightarrow$ since validators are voting by signing over the same proposal $(Q,\subtrs)$, the attestation signatures can be aggregated into a single multi-signature of 48 bytes.

Once this TXN gets included on-chain it is sent to execution, where all (honest) validators will:

1. check that the attestations in $(Q,\subtrs, \{\alpha_{j’}\}_{j’\in S})$ are valid; i.e.,:
   • $h \gets H(\subtrs)$
   • $\textbf{assert}\ \norm{S} > \threshS$
   • $\forall j’\in S, \textbf{assert}\ \sig.\verify(\pk_{j’}, \alpha_{j’}, (Q, h)) \equals 1$
2. this implies that $\norm{Q} > \threshQ$…
   • …and that Eqs. \ref{eq:trs-verifies} and \ref{eq:subtrs-aggr} hold
3. install the subtranscript on-chain, declaring the DKG complete

Now:

• The final public key whose corresponding secret key is secret-shared is $\widetilde{V}_0$ from $\subtrs$
• The share commitments $\widetilde{V}_{i,j}$’s in $\subtrs$ can be made public
  • e.g., if the DKG is for bootstrapping a weighted threshold BLS signature scheme, then $\widetilde{V}_{i,j}\bydef s_{i,j}\cdot G$ will act as the verification key for the BLS signature share $H(m)^{s_{i,j}}$
• Each player can use $\pvssDecrypt$ to obtain their shares from $\subtrs$ ¹²

Benchmarks

Single-threaded numbers from my Apple Macbook Pro M4 Max:

These numbers can be reproduce by cloning aptos-core and doing:

git clone https://github.com/aptos-labs/aptos-core
cd aptos-core/crates/aptos-crypto/benches/
./run-pvss-benches.sh

Acknowledgements

The weighted PVSS in this blog post has been co-designed with Rex Fernando and Wicher Malten at Aptos Labs. The weighted DKG built on top of the PVSS has been co-designed with Daniel Xiang and Balaji Arun. Thanks to Ittai Abraham for helping me think through the DKG protocol from the lens of validated Byzantine agreement. Thanks to Wicher Malten for the initial write-up of Chunky 2, which I later modified.

Appendix: The $i’\gets \mathsf{idx}(i,j,k)$ indexing

It may be easiest to understand the $\idx(i,j,k) = (W_i + (j-1))\cdot m + k$ formula by considering an example.

Say the number of chunks per share is $m = 3$ and that we have $n=4$ players with weights $[ w_1, w_2, w_3, w_4 ] = [2, 1, 3, 2]$

Then, the cumulative weights will be $[ W_1, W_2, W_3, W_4 ] = [ 0, 2, 3, 6 ]$

“Flattening out” the shares, we’d get:

Player 1:

    s_{1,1,1}, s_{1,1,2}, s_{1,1,3},
    1          2          3         

    s_{1,2,1}, s_{1,2,2}, s_{1,2,3},
    4          5          6         

Player 2:
    s_{2,1,1}, s_{2,1,2}, s_{2,1,3},
    7          8          9         

Player 3:
    s_{3,1,1}, s_{3,1,2}, s_{3,1,3},
    10         11         12        

    s_{3,2,1}, s_{3,2,2}, s_{3,2,3},
    13         14         15        

    s_{3,3,1}, s_{3,3,2}, s_{3,3,3},
    16         17         18        

Player 4:
    s_{4,1,1}, s_{4,1,2}, s_{4,1,3},
    19         20         21        

    s_{4,2,1}, s_{4,2,2}, s_{4,2,3},
    22         23         24

Observations:

1. Player $i$’s share chunks start at index $W_i\cdot m + 1$.
2. To get to the chunks of the $j$th share (of player $i$) add $(j-1)\cdot m$ to that.
3. To get to the $k$th chunk (of the $j$th share of player i) add $k-1$ to that.

So: \begin{align} \idx(i,j,k) &= ((W_i \cdot m + 1) + ((j-1) \cdot m) + (k-1)\\
&= ((W_i \cdot m) + ((j-1) \cdot m) + k\\
&= (W_i + (j-1)) \cdot m + k\\
\end{align}

For example, when $i = 3, j = 3, k = 2$, we get: \begin{align} (W_i + (j-1)) \cdot m + k &= (W_3 + (3-1)) \cdot 3 + 2\\
&= (3 + 2) \cdot 3 + 2\\
&= 5 \cdot 3 + 2 = 17 \end{align} as expected for $s_{3,3,2}$.

Appendix: Chunky 2

We present a modified version of Chunky with a 13% faster verifier, henceforth called Chunky 2.

To avoid redundancy, we describe only the modifications we made, rather than restating the entire algorithm from scratch.

The key idea is to modify the ElGamal-to-KZG relation $\emph{\Retk}$ from Eq. $\ref{rel:e2k}$ to also prove that the $\widetilde{V}_{i,j}$ share commitments from Eq. $\ref{eq:share-commitments}$ are computed correctly. This will speed up Step 2 in $\pvss.\verify$, which checks that what’s encrypted in the $C_{i,j,k}$’s from Eq. \ref{eq:share-ciphertexts} is what’s comitted in the $\widetilde{V}_{i,j}$’s.

The modified $\Retknew$ relation follows below, with changes $\bluedashedbox{\text{highlighted in blue}}$: \begin{align} \term{\Retknew}\left(\begin{array}{l} \stmt = \left(G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C, \bluedashedbox{\{\widetilde{V}_{i,j}\}_{i,j}} \right),\\
\witn = \left(\{s_{i,j,k}\}_{i,j,k}, \{r_{j,k}\}_{j,k}, \rho\right) \end{array}\right) = 1\Leftrightarrow\\
\Leftrightarrow\left\{\begin{array}{rl} (C_{i,j,k}, R_{j,k}) &= E.\enc_{G,H}(\ek_i, s_{i,j,k}; r_{j,k})\\
C& = \dekart_2.\commit(\ck, \{s_{i,j,k}\}_{i,j,k}; \rho)\\
\bluedashedbox{\widetilde{V}_{i,j}} & = \bluedashedbox{\left( \sum_{k \in [m]} B^{k-1} s_{i,j,k} \right) \cdot \widetilde{G}} \end{array}\right. \end{align}

This modification moves almost all verification work in Step 2 of $\pvss.\verify$ into the dealing algorithm. Furthermore, it reduces total computation across the dealing and verification algorithms. We summarize below:

The $\Sigma$-protocol verifier extra work will be of the form $\psi(\mathbf{\sigma}) \equals \mathbf{A} + e\cdot [\widetilde{V}_{i,j}]_{i,j}$ and can be done in a size-$(2W+1)$ MSM because the group elements in $\psi(\mathbf{\sigma})$ will all have the same base $\widetilde{G}$.

Then, we modify Step 6 of the $\pvss.\deal$ algorithm to prove this new relation: \begin{align} \bluedashedbox{\piSoknew} &\gets \sok.\prove\left(\begin{array}{l} \bluedashedbox{\Retknew}, \ctx,\\
G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C, \bluedashedbox{\{\widetilde{V}_{i,j}\}_{i,j}},\\
\{s_{i,j,k}\}_{i,j,k}, \{r_{j,k}\}_{j,k}, \rho \end{array}\right) \end{align}

Then, we modify Step 4 of the $\pvss.\verify$ algorithm to verify the proof from above: \begin{align} \textbf{assert}\ &\sok.\verify\left(\begin{array}{l} \bluedashedbox{\Retknew}, \ctx,\\
G, H, \ck, \{\ek_i\}_i,\{C_{i,j,k}\}_{i,j,k}, \{R_{j,k}\}_{j,k}, C, \bluedashedbox{\{\widetilde{V}_{i,j}\}_{i,j}};\\
\bluedashedbox{\piSoknew} \end{array}\right) \equals 1 \end{align}

Lastly, we remove Step 2 of the $\pvss.\verify$ algorithm, since the check is now performed above.

References

For cited works, see below 👇👇

Some thoughts

Assume we have a full/complete tree data structure that stores commitments in its leaves, such that all leaves stay at the same level: i.e., trees grows from left to right by appending new leaves. (Otherwise, privacy challenges with leaf depth leaking when revealed via a non-constant-sized ZK proof.)

Assume we can authenticate the tree by having each parent Pedersen commit to the Pedersen commitments in the children, in a somewhat-structure-preserving way (e.g., via cycles or chains of elliptic curves).

Can we come up with a scheme that proves in ZK that a commitment $\cm’$ was obtained by taking some commitment $\cm$ in such a tree with root $\rt$ and re-randomizing it using some secret blinder $\Delta{r}$?

Let $\com$ denote the Pedersen commitment scheme. Let $\comRerand(\cdot)$ denote the naturally-defined commitment re-randomization algorithm.

Let $\mht$ denote such a tree-based append-only authenticated data structure, henceforth an accumulator. Let $\mhtVerifyMem(\cdot)$ denote the naturally-defined algorithm for verify a membership proof for a leaf in this tree.

More formally, the NP relation we’d like to prove looks like: \begin{align} \mathcal{R}(\rt,\cm’; \cm, \pi,\Delta{r})=1 \Leftrightarrow\begin{cases} 1 &= \mhtVerifyMem(\rt, \cm; \pi)\\
\cm’ &= \comRerand(\cm; \Delta{r}) \end{cases} \end{align}

Reduction to proving scalar multiplication of committed points by a witness scalar

Given a parent node’s commitment $\cm$ to its children $(\cm_0,\cm_1)$, the main challenge lies in proving that $\comRerand(\cm_b;\Delta{r}),b\in\{0,1\}$ was computed correctly over one of the children of $\cm$ without leaking which one ($b$) nor the blinding factor ($\Delta{r}$).

There are of course many ways of proving this quite effectively using the right zkSNARK. These solutions would fall under the category of “improvements upon curve trees¹”. Very interesting, but not my goal.

My obsession is to see if we can leverage (and improve upon) some existing techniques and do this efficiently with only $\Sigma$-protocols and/or structure-preserving cryptography. (A bit tricky, since there are some impossibilities around structure-preserving and compressing commitments to group elements.)

Write exact relation!

References

For cited works, see below 👇👇

Approach 1: Sharded Herkle trees

High-level:

• Build depth-256 (or compressed, if possible) homomorphic Merkle prefix tree over global nullifier sets (e.g., via SADS¹)
• Shard the tree into “triangles” (e.g., a top triangle with $k$ leaves and $k$ other bottom triangles, but can have multiple levels of triangles; in fact can add them dynamically, as the tree “extends downwards”)
• Each triangle is managed by its own proof-serving node (PSN)
• Importantly, when a leaf $i$ changes by $\delta_i$ every PSN can locally update its portion of the path w/o waiting for other nodes or communicating with them $\Rightarrow$ extremely simple sharding
• Proof serving nodes can be incentivized to serve proofs (see Hyperproofs²)

Approach 2: Tachyon

Just some loose notes for now (will go into more depth as I understand later) from a few resources:

• Sean Bowe’s blog in April 2025
• Sean Bowe’s original tweet announcement
• Replies between me and Wei Dai on Twitter regarding the interactive payment flow
• Sean Bowe’s notes on a possible SNARK-friendly accumulator scheme for this
• Sean Bowe’s notes on Tachyon
• Tweet about my understanding of Tachyon in Oct. 2025
• Mike O’Connor’s post
• Mike O’Connor’s clarification on how you precompute some nullifiers and then send one to whomever is trying to pay you.
  • This makes the recursive proof more efficient because, I suppose, you can prove in batch that all of your precomputed nullifiers have not yet been spent:
• Sean Bowe’s zeroknowledge.fm podcast on Tachyon

Some disadvantages:

1. it requires out of band communication during payments.
2. cannot recover funds from seedphrase only; need other dynamic state as well that is not on-chain
3. no more viewing keys (?)
4. cannot just give out your address to get paid: you have to give a place for the sender to include the extra info

Quotes from Sean Bowe:

as the wallet state updates to reflect new blocks it will continually maintain a proof of its own correctness. Then, when it’s time to spend our funds we will extend our transaction with this proof-carrying data. This effectively attaches evidence that the transaction is valid up until a certain recent point in the history of the blockchain — the position of the anchor. The result is that validators are now only responsible for ensuring that the transaction is correct in the presence of the additional transactions that appeared in the intervening time, which just involves checking that the most recent block(s) do not contain the revealed nullifier. [15] As a result, almost everything in a block can be permanently pruned by validators and ultimately all users of the system as well. Despite transactions sharing a common state by being indistinguishable from each other, nearly all state contention problems vanish in this new approach.

[15] Together with the proof of the wallet’s validity, this demonstrates that the nullifier did not appear in another transaction that followed the block that created the note commitment being spent. Notably, this loosens the condition that the nullifier has never been seen before in the history of the blockchain but still manages to prevent double-spending.

Is the key observation that the TXN proves that the note’s nullifier did not appear in the nullifier set accumulated so far? But how do you construct that proof without the full set? Ah! You dont. You just need the nullifiers created between the note’s creation and the note being spent. And that’s what the wallet can prove recursively!

Other approaches

• Stateless validation: removes the validation state but introduces PSNs and needs the right approach
• Epoch-based nullifiers: freezes old nullifier sets
• Mutator sets 1 and 2: need to investigate

References

For cited works, see below 👇👇