Aptos

• Good: Encrypts balances under the owning user’s encryption key $\Rightarrow$ no one can see the balance, except the owning user – neither validators nor full nodes.
• Good: Encrypts transferred amounts under the sending and receiving users’ encryption keys $\Rightarrow$ same guarantees
• Bad: Auditing functionality is somewhat restricted
  • Although governance-based auditors get full visibility into transferred amounts and encrypted balances¹, this is only after auditing is enabled.
  • Retroactive auditing of previous transferred amounts is not possible. (This is a good or a bad thing, depending on whom you ask.)
• Bad: Trickier to implement key management for users inside wallets $\Rightarrow$ must do extra careful cryptographic work to enable seamless confidentiality UX in wallets like Petra
  • Banks/customers may not like this, especially if they are clueless about blockchains
• Bad: 30x higher gas cost than public payments. (See gas benchmarks here.)

If confidentiality is what you care about most, go with Aptos. If it is full privacy, of course, go with Zcash.

Canton

I understand that Canton was built for permissioned enterprise networks where participants are known and regulated. Thus, operator visibility is viewed not as a bug but a feature for compliance.

• Bad: User’s balances are stored in plaintext on their chosen validator/operator $\Rightarrow$ that operator/validator can see the balance $\Rightarrow$ attacker who breaks in can see it too $\Leftrightarrow$ you are trusting your validator operator $\Leftrightarrow$ weak privacy
  • Suggesting that validators/operators can encrypt balances under their own keys is no better, since the operator still holds the key
  • Suggesting that trusted hardware can make it better is tenuous (see Arc discussion on attacks)
• Bad: Amounts and balances are only encrypted “in flight” between full nodes / validators $\Rightarrow$ high trust assumption on these intermediaries
• Good: Easier to do key management
  • Banks/customers should like this
• Good: Easier to implement more complex auditing policies, precisely because validators see everything / the privacy guarantees are weaker
  • Banks/customers should also like this

Claude’s take

Aptos confidential assets encrypt balances on the public ledger under keys the user owns, so secrecy is a cryptographic guarantee: only the key holder can read amounts, and no operator can.

Canton keeps balances in plaintext in each participant node’s local database and gets secrecy from routing — the protocol simply never sends the data to non-stakeholders, with inter-node encryption under node keys covering transport only.

So the trust anchor differs:

• Aptos trusts math and the user’s ability to protect their decryption keys.
• Canton trusts your hosting participant operator, plus whatever leaks through divulgence, timing, and workflow metadata.

Arc²

• Bad: Leverages trusted hardware to encrypt blockchain state on validators under a master secret key (MSK)
  • Unfortunately, trusted hardware is much easier to break in practice than in theory
  • It has been fully (and partially) broken several times in the past. See just a few recent attacks:
    • batteringram.eu/batteringram.pdf: “arbitrary plaintext read/write access and extracting SGX’s platform provisioning key, thereby dismantling trust in remote attestation”
    • tee.fail/files/paper.pdf: “extract secret key material (such as attestation keys in some cases) from machines in fully trusted status”
    • wiretap.fail/files/wiretap.pdf: “extract an SGX attestation key from a machine in fully trusted status” $\Rightarrow$ “end-to-end attacks on both confidentiality and integrity guarantees of deployments with multi-million dollar market caps, allowing attackers to disclose confidential transactions or illegitimately obtain transaction rewards”
• Bad: Uses a secret-shared MSK on validators (or, more loosely, their operators)
  • $\Rightarrow$ subject to collusion attacks by validators $\Rightarrow$ the MSK could be revealed $\Rightarrow$ privacy guarantees would be broken without even having to break the trusted hardware
  • The typical counterargument here is that “more trusted hardware on each validator’s KMS will fix this.”
    • But will it ¯\_(ツ)_/¯? (See attacks above!)
• Good: Supports arbitrary privacy-preserving* computations, beyond just payments
  • *Of course, under the big caveat of relying on (repeatedly-broken-into) trusted hardware.
• Good: Easy key management
• Good: Very flexible auditing

But $\exists$ secure trusted hardware!

One reasonable objection to “trusted hardware keeps being broken into” is that such Intel SGX attacks³ will not transfer to other trusted hardware platforms.

I doubt it⁴$^,$⁵$^,$⁶$^,$⁷.

Although there are ways to reduce the attack surface of trusted hardware (e.g., see Sanctum⁸ from my group at MIT back in the day), in practice, they tend to come with lower performance and/or less functionality. And it so happens that trusted hardware companies mainly compete on performance, functionality and (I hope) developer-friendliness. They hardly compete on security, because it’s hard to: there’s always someone else who can (mis)claim more security. And such claims are hard to adjudicate by the market.

Thus, what ends up happening is a race to the bottom, sacrificing security for extra performance and functionality.

Claude’s take

Aptos protects balances with pure cryptography: ciphertexts sit on-chain under the user’s own key, so an attacker who compromises every validator still learns nothing about anyone’s balance.

Arc protects balances with a master secret key (MSK) housed inside trusted hardware on the validators. This gives Arc two failure modes Aptos doesn’t have: (1) hardware-level attacks that extract the MSK from the enclave, which were demonstrated repeatedly in practice (see links above), and (2) validator collusion that reconstructs the secret-shared MSK without touching the hardware at all.

The trade-off is expressivity: Arc’s enclaves can run arbitrary confidential computation, not just payments, while Aptos’s on-chain approach is limited to payments. But that expressivity assumes trusted hardware won’t get broken into. So you’re trading a mathematical guarantee for a physical one, and the physical one has a poor track record.

If I had to pick between Canton and Arc, I’d pick Arc due to its simpler design, clearer trust model (IMHO), and higher expressivity.

References

For cited works, see below 👇👇

Cryptography

• Verified-zkEVM
  • VCVio
  • ArkLib
  • clean zkDSL
• zkLean: A DSL for ZK statement verification

Software engineering in Lean

• Why lean is faster than Rust
  • Lean proved this program was correct; then I found a bug.
• Just Lean: a verified, fast sort
• Sort in Rust, prove in Lean example
• Lean-ing into Software Engineering
• A (somewhat) formally verified implementation of Markdown
• Formally verified CRUD
• Formally Verified [zkVM] Autoprecompiles
• A new software engineering paradigm

Rust (Non-Lean)

• Verus: Verified Rust for low-level systems code
• Creusot: a deductive verifier for the Rust programming language
• Aeneas: translation from Rust’s MIR internal language to a pure lambda calculus
  • Often used to “compile” a subset of Rust to Lean

Logic

• Propositional logic, $p \wedge \neg p$ type of thing; no quantifiers; no predicates
• First-order logic, $\exists y, \forall x, P(x, y)$; quantifiers and predicates
• Second-order logic, $\exists P, \forall x. P(x)$; more expressive than first-order logic (quantifies over predicates too)

Docs

• mathlib4 docs
• LeanSearch
• Loogle

Misc

• CSLib
• lean4-skills
• Lean game server
• Hitchhiker’s guide to formal verification [in Lean]
• Lean metaprogramming
• Insertion sort in Lean with termination proof
• Tutorial: Introduction to Formal Verification with Lean (Part 1)
• From Prompts to Protocols: lean4-skills for AI-Assisted Lean Formalization

Questions

Probability

How good is Lean at modeling probabilistic games in cryptography?

High-performance code

Need two things that are in tension:

• high performance code
• code that is provable against the spec

e.g., if the code is in (some subset of) Rust, we can translate it to Lean using Aeneas (see above). But not sure how well this works in practice. Also, not sure how much TCB this involves.

References

For cited works, see below 👇👇

Notation

• We assume a prime-order group $\term{\Gr}$ of prime order $\term{p}$
• We use additive group notation: $a \cdot G$ denotes scalar multiplication in $\Gr$, where $a\in \Zp$ and $G\in\Gr$

Naive discrete log algorithm

Naively, computing the discrete logarithm (DL) $a$ on $a \cdot G$ when $a\in[m)$ can be done in constant-time via a single lookup in an $m$-sized precomputed table:

\begin{align} (\jG{j})_{j\in [m)} \end{align}

This works great for small enoguh $m$, depending on how much memory is available. e.g.,

• 2 MiB for $m=2^{16} \Rightarrow$ 512 KiB with truncation
• 32 MiB for $m=2^{20} \Rightarrow$ 4 MiB with truncation

Baby-step giant step (BSGS) discrete log algorithm

The BSGS algorithm compute a DL $a\in[m)$ on $a\cdot G$ with less memory but more computation. Specifically:

• it reduces the table size from $m$ to $\sqm$
• it increases the solving time from $O(1)$ to $\GaddG{(\sqm-1)}$.

Let us define a base, $s$, as:

The key idea is that we can represent the value $a$ as a 2-digit number $(i,j)$ in base-$\emph{s}$: \begin{align} a = i\cdot s + j,\ \text{where}\ i,j\in[s) \end{align} As a result finding the discrete log $a$ of $H\bydef a\cdot G$, can be reduced to finding its two digits $i,j\in[s)$ such that: \begin{align} H &= (i \cdot s + j)\cdot G\Leftrightarrow\\
H &= i \cdot (s \cdot G) + j \cdot G\Leftrightarrow\\
\label{eq:bsgs-check} H + i \cdot (\sG) &= \jG{j} \end{align}

Now, imagine we have all $(\jG{j})_{j\in[s)}$ and $\sG$ precomputed. Then, finding $a$ can be reduced to computing all the left hand sides (LHS) of Eq. $\ref{eq:bsgs-check}$ for all possible $i\in[s)$ and checking if there exists $j\in[s)$ such that the LHS equals the right hand side (RHS). If it does, then $a = i\cdot s+ j$!

More concretely, we compute: \begin{align} V_0 &\gets H = H + 0 \cdot (\sG)\\
V_1 &\gets V_0 \sG = H + 1 \cdot (\sG)\\
V_2 &\gets V_1 \sG = H + 2 \cdot (\sG)\\
&\hspace{.7em}\vdots\\
V_i &\gets V_{i-1} \sG = H + i \cdot (\sG)\\
&\hspace{.7em}\vdots\\
V_{s-1} &\gets V_{s-2} \sG = H + (s-1) \cdot (\sG)\\
\end{align} Then, for each computed $V_i$, we check (in constant-time) whether there exists a $j\in[s)$ such that $V_i = \jG{j}$. In other words, we check if Eq. \ref{eq:bsgs-check} holds for some $i,j\in[s)$. If it does, then we solved for the correct DL $a = i\cdot s + j$!

Note that this algorithm will take at most $s-1$ group additions in $\Gr$, so it is very efficient!

The maximum value $a$ can take in this base-$s$ representation is $(s-1) \cdot s + (s-1) = (s-1)(s+1) = s^2 - 1$. Since $\sqm \ge \sqrt{m}$, by squaring it, it follows that $\sqm^2 \ge \sqrt{m}^2\Leftrightarrow s^2 \ge m$. This means $a=m-1$ can be represented in base-$s$, so the algorithm will be able to solve DL for all $a\in[m)$. (Not only: it may also be able to solve it for slightly higher values, e.g., $s=4$ for both $m = 15,16$).

We give formal algorithms for BSGS below.

$\mathsf{BSGS.Precompute}(m\in \N, G\in\Gr) \rightarrow \table$

Recall that $\term{s}\bydef\sqm$.

Using $\GaddG{(s-1)}$ time, build a dictionary $\term{\dict}$ (e.g., a hash map) that maps each baby step to its index: \begin{align} \dict[\jG{j}] \gets j,\quad \forall j\in[s) \end{align} By convention, $\dict[P] = \bot$ for any $P$ that is not a key (i.e., for any $P\notin \{\jG{j}\}_{j\in[s)}$).

Return the table $\table \gets (s, \dict, \sG)$.

$\mathsf{BSGS.Solve}(\table, H\in\Gr) \rightarrow a \in [m)\times \{\bot\}$

Parse the table: \begin{align} (s, \dict, \sG) \parse \table \end{align}

Let $V_0 = H$.

For each $i\in[0, s)$:

• $j \gets \dict[V_i]$
• if $j \ne \bot$, then return $i\cdot s + j$
• $V_{i+1} \gets V_i + (\sG)$

If we reached this point, this means no $i,j\in[s)$ were found. This, in turn, means $a \ge s^2 \ge m$.

Therefore, return $\bot$.

BSGS-$k$ discrete log algorithm

BSGS-$k$ is a variant of BSGS that dramatically speeds up the solve algorithm on certain elliptic curves by batching $k$ giant steps together.

This addresses a key performance issue: when using BSGS on Ristretto255 curves, its main bottleneck is the expensive point compression required to index into the precomputed table after every giant step. BSGS-$k$ avoids this by first computing $k$ giant steps via $k-1$ group additions and then compressing all $k$ points at once. Unfortunately, batch compression is not supported in Ristretto255. (Feel free to open that can of worms on your own.) But, fortunately, “doubled-point” batch compression is supported via a $\doubleAndCompressBatch{\cdot}$ algorithm. As a result, we observe that the BSGS algorithm can be adjusted to work over these doubled points!

This algorithm was LLM-discovered. Upon first glance at the Ristretto255 APIs in curve25519-dalek, I could not find any batch compression algorithms. So I just threw the problem to Claude, with very little hope, thinking “Ha! There is no way it’ll find anything I couldn’t find. Let me watch it fail…“ Then, Claude found the $\doubleAndCompressBatch{\cdot}$ API I would have otherwise missed.

We give formal algorithms for BSGS-$k$ below, building on the BSGS algorithms above.

$\mathsf{Compress}(H\in \Gr) \rightarrow \{0,1\}^{256}$

Returns a 32-byte (256-bit) compressed canonical representation of the group element $H$.

$\mathsf{DoubleAndCompressBatch}\left((H_i)_{i\in[k]}\in \Gr\right) \rightarrow \left(\{0,1\}^{256}\right)^k$

Doubles all $H_i$’s and compress the results in batch, more efficiently than repeatedly calling $\compress{2\cdot H_i}$ for all $i\in [k]$.

$\mathsf{BSGS\text{-}k.Precompute}(m\in \N, G\in\Gr) \rightarrow \table$

Recall that $\term{s}\bydef\sqm$.

Using $\GaddG{(s-1)}$ time, build a dictionary $\dict$ that maps each doubled baby step to its index: \begin{align} \dict[\ctwojG{j}] \gets j,\quad \forall j\in[s) \end{align} (As before, $\dict[c] = \bot$ for any $c$ that is not a key.)

Return the table $\table \gets (s, \dict, \sG)$.

Note that the baby steps are stored doubled (as $\ctwojG{j}$), so that we can compare against them using $\doubleAndCompressBatch{\cdot}$. The giant step, however, remains $\sG$ (not doubled): as we’ll see below, the doubling is applied to each running point $V_{i+\ell}$ at compression time, not to the giant step itself.

$\mathsf{BSGS\text{-}k.Solve}(\table, H\in\Gr) \rightarrow a \in [m)\times \{\bot\}$

Parse the table: \begin{align} (s, \dict, \sG) \parse \table \end{align}

Let $V_0 = H$.

For each $i\in\{0,k,2k,\ldots\}$ subject to $i < s$:

• Compute $V_{i+1}, \ldots, V_{i+k-1}$ via $k-1$ additions of $\sG$, such that $\term{V_{i+\ell}} \bydef H + (i+\ell)\cdot (\sG)$
• Compute $\doubleAndCompressBatch{V_i, V_{i+1}, \ldots, V_{i+k-1}}$ to get compressed points $(c_i, \ldots, c_{i+k-1})$, where $c_{i+\ell} \bydef \compress{2\cdot V_{i+\ell}}$
• For each $\ell \in [0, k)$, run the match check:
  • $j \gets \dict[c_{i+\ell}]$
  • if $j \ne \bot$, then return $(i+\ell)\cdot s + j$
• $V_{i+k} \gets V_{i+k-1} + (\sG)$

If we reached this point, return $\bot$.

For simplicity, we describe the last batch as always having $k$ points, even when $i + k > s$. As a result, we may compute and look up a few extra points $V_n$ whose giant-step index $i + \ell$ is $\ge s$. This is harmless.

Truncated BSGS-$k$ (TBSGS-$k$) discrete log algorithm

TBSGS-$k$ is a variant of BSGS that dramatically reduces the table size from $\sqm \cdot 32$ bytes to $\sqm \cdot 8$ bytes (a 75% reduction) while maintaining nearly-identical performance for large secrets.

The key idea is: instead of keying the dictionary on the full doubled baby steps $\ctwojG{j}$, we key it on their 8-byte truncations $\tctwomjG{j}$, where $\term{\mathsf{Trunc}}$ returns the first 8 bytes and $\term{\mathsf{Compress}}$ is the standard Ristretto255 point compression.

We give formal algorithms for TBSGS-$k$ below, building on the BSGS-$k$ algorithms above.

$\mathsf{TBSGS\text{-}k.Precompute}(m\in \N, G\in\Gr) \rightarrow \table$

Recall that $\term{s}\bydef\sqm$.

Using $\GaddG{(s-1)}$ time, build a dictionary $\dict$ that maps each truncated, doubled baby step to its index: \begin{align} \dict[\tctwomjG{j}] \gets j,\quad \forall j\in[s) \end{align} (As before, $\dict[t] = \bot$ for any $t$ that is not a key.) The dictionary’s keys are now only 8 bytes each, hence the $\sqm \cdot 8$-byte table size.

Return the table $\table \gets (s, \dict, \sG)$.

$\mathsf{TBSGS\text{-}k.Solve}(\table, H\in\Gr) \rightarrow a \in [m)\times \{\bot\}$

TBSGS-$k$.Solve is identical to BSGS-$k$.Solve above, except for the match check. Since the table is now keyed by 8-byte truncations (which can collide), a truncated hit must be verified via a scalar multiplication before we trust it. So the match check becomes:

• $j \gets \dict[\trunc{c_{i+\ell}}]$
• if $j \ne \bot$ and $V_{i+\ell} \equals \jG{j}$ (verify the match), then return $(i+\ell)\cdot s + j$

Application to Aptos confidential assets

We use the TBSGS-k algorithm to decrypt confidential balances quickly for the Aptos confidential assets features.

Appendix: Benchmarks

All benchmarks are run single-threaded on an Apple Macbook Pro M4 Max.

All algorithms are implemented for Ristretto255 in this ristretto255-dlog repo.

Discrete log precomputed table sizes

TBSGS-k is the default algorithm in Aptos confidential assets, offering the best balance between WASM size and DL solving time.

Rust DLP: [BL12]¹

[BL12] 32-bit secrets   time:   [4.6197 ms 4.8080 ms 5.0194 ms]

On my old M1 Max, for 48 bits, BL12 times were: [763.90 ms 1.1598 s 1.6174 s].

Rust DLP: (Truncated-)BSGS with batch size $k$

Summary: For 32-bit secrets, TBSGS-k performs identically to BSGS-k (~11 ms). For smaller secrets, TBSGS-k is ~3x slower due to its verification overhead (i.e., one scalar multiplication per truncated match) However, this is negligible in absolute terms (35 µs vs 12 µs). TBSGS-k should be preferred for its dramatically smaller table size with minimal performance impact.

For discrete logs on 32-bit values with tables for 32-bits:

[BSGS-k1], 32-bit secrets
                        time:   [61.928 ms 67.501 ms 77.980 ms]
[TBSGS-k1], 32-bit secrets
                        time:   [64.498 ms 69.626 ms 74.543 ms]

[BSGS-k2], 32-bit secrets
                        time:   [40.716 ms 42.236 ms 44.658 ms]
[TBSGS-k2], 32-bit secrets
                        time:   [41.303 ms 43.666 ms 46.133 ms]

[BSGS-k4], 32-bit secrets
                        time:   [24.406 ms 25.578 ms 26.663 ms]
[TBSGS-k4], 32-bit secrets
                        time:   [25.164 ms 26.253 ms 27.185 ms]

[BSGS-k8], 32-bit secrets
                        time:   [16.921 ms 17.727 ms 18.506 ms]
[TBSGS-k8], 32-bit secrets
                        time:   [17.375 ms 18.174 ms 18.895 ms]

[BSGS-k16], 32-bit secrets
                        time:   [12.398 ms 13.299 ms 14.351 ms]
[TBSGS-k16], 32-bit secrets
                        time:   [12.851 ms 13.537 ms 14.255 ms]

[BSGS-k32], 32-bit secrets
                        time:   [11.833 ms 12.347 ms 12.783 ms]
[TBSGS-k32], 32-bit secrets
                        time:   [11.379 ms 12.037 ms 12.533 ms]

[BSGS-k64], 32-bit secrets
                        time:   [11.760 ms 12.257 ms 12.909 ms]
[TBSGS-k64], 32-bit secrets
                        time:   [10.717 ms 11.302 ms 11.772 ms]

[BSGS-k128], 32-bit secrets
                        time:   [10.264 ms 10.677 ms 11.013 ms]
[TBSGS-k128], 32-bit secrets
                        time:   [10.363 ms 10.843 ms 11.202 ms]

[BSGS-k256], 32-bit secrets
                        time:   [10.674 ms 11.057 ms 11.478 ms]
[TBSGS-k256], 32-bit secrets
                        time:   [10.512 ms 10.976 ms 11.631 ms]

[BSGS-k512], 32-bit secrets
                        time:   [9.8338 ms 10.664 ms 11.260 ms]
[TBSGS-k512], 32-bit secrets
                        time:   [10.967 ms 11.461 ms 12.073 ms]

[BSGS-k1024], 32-bit secrets
                        time:   [10.329 ms 11.076 ms 11.718 ms]
[TBSGS-k1024], 32-bit secrets
                        time:   [11.144 ms 11.453 ms 11.714 ms]

[BSGS-k2048], 32-bit secrets
                        time:   [10.394 ms 10.811 ms 11.373 ms]
[TBSGS-k2048], 32-bit secrets
                        time:   [10.800 ms 11.248 ms 11.783 ms]

[BSGS-k4096], 32-bit secrets
                        time:   [10.686 ms 11.277 ms 11.681 ms]
[TBSGS-k4096], 32-bit secrets
                        time:   [10.911 ms 11.467 ms 12.043 ms]

[BSGS-k8192], 32-bit secrets
                        time:   [11.520 ms 12.029 ms 12.341 ms]
[TBSGS-k8192], 32-bit secrets
                        time:   [11.663 ms 12.255 ms 12.650 ms]

[BSGS-k16384], 32-bit secrets
                        time:   [12.228 ms 13.168 ms 14.037 ms]
[TBSGS-k16384], 32-bit secrets
                        time:   [13.009 ms 13.615 ms 14.469 ms]

For discrete log on 17-24 bit values but with the same tables for 32 bits, demonstrating that smaller values are solved for faster:

[BSGS-k32], 17-bit secrets (32-bit table)
                        time:   [12.096 µs 12.118 µs 12.144 µs]
[TBSGS-k32], 17-bit secrets (32-bit table)
                        time:   [35.155 µs 35.252 µs 35.368 µs]

[BSGS-k32], 18-bit secrets (32-bit table)
                        time:   [12.144 µs 12.166 µs 12.189 µs]
[TBSGS-k32], 18-bit secrets (32-bit table)
                        time:   [35.003 µs 35.073 µs 35.164 µs]

[BSGS-k32], 19-bit secrets (32-bit table)
                        time:   [12.211 µs 12.234 µs 12.261 µs]
[TBSGS-k32], 19-bit secrets (32-bit table)
                        time:   [35.060 µs 35.131 µs 35.218 µs]

[BSGS-k32], 20-bit secrets (32-bit table)
                        time:   [12.286 µs 12.307 µs 12.331 µs]
[TBSGS-k32], 20-bit secrets (32-bit table)
                        time:   [35.063 µs 35.098 µs 35.137 µs]

[BSGS-k32], 21-bit secrets (32-bit table)
                        time:   [12.424 µs 12.444 µs 12.466 µs]
[TBSGS-k32], 21-bit secrets (32-bit table)
                        time:   [35.119 µs 35.153 µs 35.190 µs]

[BSGS-k32], 22-bit secrets (32-bit table)
                        time:   [18.917 µs 18.954 µs 18.999 µs]
[TBSGS-k32], 22-bit secrets (32-bit table)
                        time:   [41.477 µs 41.553 µs 41.628 µs]

[BSGS-k32], 23-bit secrets (32-bit table)
                        time:   [31.782 µs 31.871 µs 31.971 µs]
[TBSGS-k32], 23-bit secrets (32-bit table)
                        time:   [54.167 µs 54.306 µs 54.453 µs]

[BSGS-k32], 24-bit secrets (32-bit table)
                        time:   [57.521 µs 57.709 µs 57.893 µs]
[TBSGS-k32], 24-bit secrets (32-bit table)
                        time:   [79.229 µs 79.522 µs 79.798 µs]

For varying K values with 18-bit secrets:

[BSGS-k64], 18-bit secrets (32-bit table)
                        time:   [22.715 µs 22.763 µs 22.816 µs]
[TBSGS-k64], 18-bit secrets (32-bit table)
                        time:   [45.064 µs 45.104 µs 45.144 µs]

[BSGS-k128], 18-bit secrets (32-bit table)
                        time:   [43.323 µs 43.387 µs 43.456 µs]
[TBSGS-k128], 18-bit secrets (32-bit table)
                        time:   [65.512 µs 65.641 µs 65.812 µs]

[BSGS-k1024], 18-bit secrets (32-bit table)
                        time:   [338.10 µs 338.59 µs 339.12 µs]
[TBSGS-k1024], 18-bit secrets (32-bit table)
                        time:   [354.13 µs 354.48 µs 354.88 µs]

[BSGS-k2048], 18-bit secrets (32-bit table)
                        time:   [673.72 µs 674.26 µs 674.87 µs]
[TBSGS-k2048], 18-bit secrets (32-bit table)
                        time:   [681.17 µs 681.61 µs 682.10 µs]

Decision for Aptos: Stick with 16-bit chunks and use the naive DL algorithm: store all solutions in tables of $2^{16}$ group elements ($2^{16}\times 32$ bytes $\Rightarrow 2$ MiB) and use naive lookup to compute the DL in constant time, when chunks are small! Note that the TBSGS-$k$ table can be reused for this naive lookup approach! When chunks are big, resort to TBSGS-$k$ (or, in the future, to [BL12]¹).
Rationale: We have to be conservative because a user may be using multiple confidential apps at the same time and/or the browser may be busy doing other things.

Rust DLP: BSGS (compression after every step)

[BSGS] 32-bit secrets   time:   [63.673 ms 69.557 ms 75.040 ms]

WASM DLP: [BL12]¹

These were run on an older version of the TS SDK repo via: pnpm jest discrete-log

WASM [BL12] 16-bit: avg=0.24ms, min=0.19ms, max=0.30ms
WASM [BL12] 32-bit: avg=42.59ms, min=34.17ms, max=56.06ms

WASM DLP: TBSGS-$k$ and NaiveTruncatedDoubledLookup

WASM NaiveTruncatedDoubledLookup 16-bit: avg=1.50ms, min=1.33ms, max=2.29ms

WASM TBSGS-k32 32-bit: avg=20.15ms, min=1.84ms, max=39.55ms

TypeScript DLP: BSGS

These were run in the TS SDK repo via: pnpm jest discrete-log

TS BSGS 16-bit: avg=7.47ms, min=5.82ms, max=8.24ms
TS BSGS 32-bit: avg=2252.36ms, min=1539.60ms, max=3359.79ms

Background

For ECDSA verification and pubkey recovery, the relevant MSM size is $n=2$. For (modified) ECDSA batch verification, we will be interested in $n \ge 4$.

GLV

secp256k1 has a GLV endomorphism $\phi(x,y)=(\beta x, y)$, where $\beta$ is a primitive cube root of 1 over the base field $\F_p$. This lets you split a 256-bit scalar into two ~128-bit halves, speeding up scalar multiplication arithmetic.

The four libraries benchmarked below differ in where they apply GLV:

For p256k1, both Strauss-WNAF and Pippenger-WNAF in libsecp256k1 call secp256k1_scalar_split_lambda (resp. secp256k1_ecmult_endo_split) to feed Pippenger $2n$ pairs of half-length scalars instead of $n$ pairs of full-length scalars.

For gnark-crypto, only the per-point mulGLV path uses the endomorphism; MultiExp runs Pippenger over the full 256-bit scalars (no glv/phi/endomorph references in multiexp*.go).

For ark-secp256k1, the GLVConfig trait exists in ark-ec, but no curve in arkworks-rs/algebra implements it (grep -rln "impl GLVConfig\|GLVConfig for" is empty). secp256k1 only implements SWCurveConfig, so both mul and VariableBaseMSM::msm use the generic double-and-add over 256-bit scalars.

For halo2curves, the CurveEndo trait exists and the endo! macro provides a decompose_scalar impl for curves like bn256 (endo!(G1, Fr, ENDO_PARAMS_BN);). But secp256k1/curve.rs never invokes the macro, so Secp256k1 doesn’t implement CurveEndo. Independently, msm.rs doesn’t reference CurveEndo::decompose_scalar at all — msm_serial/msm_parallel/msm_best run Pippenger (with Booth encoding) over full 256-bit scalars regardless of whether the curve has GLV.

p256k1

Bitcoin Core’s libsecp256k1 C library ships a Pippenger-WNAF multi-scalar multiplication (MSM) routine, but neither the Rust secp256k1 crate nor the pure-Rust libsecp256k1 port expose it. i The p256k1 crate does.

Below I benchmark its MSM.

libsecp256k1 exposes secp256k1_ecmult for individual signature verication (and for pubkey recovery) and exposes secp256k1_ecmult_multi_var for $n$-element MSM, dispatched to either Strauss-WNAF (small $n$) or Pippenger-WNAF (larger $n$). The cutoff is ECMULT_PIPPENGER_THRESHOLD = 88 (line 55 of ecmult_impl.h): for $n < 88$ the library calls secp256k1_ecmult_strauss_wnaf, and for $n \ge 88$ it calls secp256k1_ecmult_pippenger_wnaf. So in the table below, the rows for $n \in \{2, 4, 8, 16, 32, 64\}$ measure Strauss-WNAF + GLV, and the rows for $n \in \{128, 256, 512, 1024\}$ measure Pippenger-WNAF + GLV.

Run the benchmark

I forked the p256k1 crate and added

1. a Criterion benchmark that times Point::multimult
2. a naive for i in 0..n { p += scalars[i] * points[i] } loop for $n \in \{2, 4, \ldots, 1024\}$,
3. a run-benches.sh script that runs these, parses Criterion’s estimates.json files and outputs a Markdown table.

git clone --branch msm-benchmark https://github.com/alinush/p256k1.git
cd p256k1
# The script needs `cargo`, `jq`, `awk`, and `bc`.
./run-benches.sh

Benchmarks shoud take ~1-2 minutes to run.

Results

Run on an Apple M4 Max, release build:

Note (size-2 row uses the dedicated path): The $n=2$ row measures the specialized size-2 multiexp that ECDSA verify and pubkey recovery actually call (secp256k1_ecmult in libsecp256k1, exposed in my fork as Point::ecmult). This leverages precomputed odd-multiples table for the fixed generator $G$. For reference, passing $n=2$ to the generic secp256k1_ecmult_multi_var instead, which treats $G$ as a random base, would give ≈24.6 µs, about 2× slower.

Note (batch-normalize patch in my fork): The numbers above are from a small patch to Point::multimult: a batch-inversion replacement of $n$ inversions that gives a clean ~30% speedup at $n=1024$ (from 4734 µs down to 3644 µs).

Future optimizations

For large $n$, blst and halo2curves use Pippenger with batched affine addition: they keep Pippenger’s bucket sums in affine coordinates and amortize many independent slope-inversions via Montgomery’s simultaneous-inversion trick. To understand the potential speed-ups, I vibe-coded a small Rust proof-of-concept timing $K$ independent affine additions with (1) $K$ independent inversions vs. (2) one shared inversion. (There’s a unit test that verifies both paths agree element-wise.) Run from the same fork via:

git clone --branch msm-benchmark https://github.com/alinush/p256k1.git
cd p256k1
cargo bench --bench affine_add_bench

What this means for Pippenger MSMs: The relevant comparison is batched-affine (≈0.23 µs/add) vs. libsecp256k1’s current mixed Jacobian+affine add (secp256k1_gej_add_ge_var, no inversion, ≈0.5-0.6 µs/add) $\Rightarrow$ a ~2-2.5× per-add speedup. Since bucket-fill is roughly half of Pippenger’s work, plumbing this into secp256k1_ecmult_pippenger_wnaf should give ~25-30% more on top of the batch-normalize patch. Caveat: This only helps the Pippenger path ($n \ge 88$). For $n < 88$ (i.e., ECDSA verify, recovery, and most small instances of batch-verify), libsecp256k1 uses Strauss-WNAF, whose serial-accumulator inner loop has no parallel adds to batch.

ark-secp256k1

The pure-Rust ark-secp256k1 crate (part of arkworks) exposes a generic Pippenger MSM via the VariableBaseMSM trait: Projective::msm(&bases, &scalars).

Unlike p256k1, this is pure Rust: no FFI, no hand-tuned assembly. As a result, things are slower.

Run the benchmark

In the same fork, I added:

1. a Criterion benchmark that times <Projective as VariableBaseMSM>::msm(&bases, &scalars),
2. a naive for i in 0..n { p += bases[i] * scalars[i] } loop for $n \in \{2, 4, \ldots, 1024\}$,
3. a run-arkworks-benches.sh script that runs these and outputs a Markdown table.

git clone --branch msm-benchmark https://github.com/alinush/p256k1.git
cd p256k1
# The script needs `cargo`, `jq`, `awk`, and `bc`.
./run-arkworks-benches.sh

Benchmarks should take ~1-2 minutes to run.

Results

Run on the same Apple M4 Max, release build:

gnark-crypto

gnark-crypto is Consensys’ Go cryptography library. Its ecc/secp256k1 package is code-generated (per-curve specialization, including modulus-specific Montgomery arithmetic) and exposes MultiExp, implementing the Pippenger variant from eprint 2012/549.

For a fair comparison, I run MultiExp with MultiExpConfig{NbTasks: 1} (single goroutine), since p256k1 and ark-secp256k1 above are also single-threaded.

Run the benchmark

I forked gnark-crypto and added:

1. a Go benchmark BenchmarkMSMSizes in ecc/secp256k1 that times (*G1Affine).MultiExp(points, scalars, ecc.MultiExpConfig{NbTasks: 1}),
2. a naive for i := 0; i < n; i++ { tmp.ScalarMultiplication(&p[i], s[i]); acc.AddAssign(&tmp) } loop for $n \in \{2, 4, \ldots, 1024\}$,
3. a run-gnark-benches.sh script that runs these and parses go test -bench output into a Markdown table.

git clone --branch secp256k1-msm-benchmark https://github.com/alinush/gnark-crypto.git
cd gnark-crypto
# The script needs `go` and `awk`.
./run-gnark-benches.sh

Benchmarks should take ~1-2 minutes to run.

Results

Run on the same Apple M4 Max, release build (Go’s default; optimizations + inlining are on unless you explicitly pass -gcflags='all=-N -l'):

From speaking with Youssef El Housni, it seems like their secp256k1 implementation is unoptimized; it’s just there for some witness generation when proving ECDSA signatures.

halo2curves

The msm module exposes:

• msm_serial (single-threaded),
• msm_parallel (rayon-based),
  • simple “chunk the input across threads, run msm_serial on each chunk, sum” pattern
• msm_best (picks based on input size):
  • for $\lceil \ln(n) \rceil < 10$ (i.e., $n \lesssim 22{,}000$, including all sizes in this post) it calls msm_parallel, which is rayon-parallelized but runs the same Pippenger as msm_serial per thread.
    • $\Rightarrow$ in our $n \leq 1024$ range, msm_best would use msm_parallel, which we do not want.
  • for $\lceil \ln(n) \rceil \ge 10$ it switches to a window-parallelized variant with a different memory layout.
    • this variant is not exposed as a msm_* function, apparently

The MSM is generic over CurveAffine and uses Pippenger with Booth signed-digit encoding.

As noted in the GLV table above, halo2curves’ secp256k1 module does not plug into the library’s CurveEndo trait, and msm.rs ignores CurveEndo regardless. So this is the slowest of the four implementations: pure-Rust, no GLV, and no curve-specific field arithmetic tuning for secp256k1’s pseudo-Mersenne prime $p = 2^{256} - 2^{32} - 977$.

We benchmark msm_serial (not msm_best) so the comparison is apples-to-apples with the other single-threaded benches in this post.

Run the benchmark

I forked halo2curves and added:

1. a Criterion benchmark benches/secp256k1_msm_sizes.rs that times msm_serial(&scalars, &bases, &mut acc),
2. a naive for i in 0..n { acc += bases[i] * scalars[i] } loop for $n \in \{2, 4, \ldots, 1024\}$,
3. a run-halo2curves-benches.sh script that runs these and outputs a Markdown table.

git clone --branch secp256k1-msm-benchmark https://github.com/alinush/halo2curves.git
cd halo2curves
# The script needs `cargo`, `jq`, `awk`, and `bc`.
./run-halo2curves-benches.sh

Benchmarks should take ~1-2 minutes to run.

Results

Run on the same Apple M4 Max, release build:

References

For cited works, see below 👇👇

Notes

Good

• MPC’s configuration is transparent, on-chain $\Rightarrow$ can monitor for suspicious membership changes
• “uses the Cait-Sith protocol in a secure manner”¹
• “we did not identify any issues related to Beaver triple or nonce reuse that could compromise the security of a shared key”¹
• NEAR currently only uses Cait-Sith on mainnet (May 1st, 2026)
  • (The MPC committee can change this over time, of course.)

Unclear

• There is a proof for Cait-Sith but it’s in a new framework called MPS² which is claimed to be UC-like³
  • (For all I know, this framework could be much better than UC!)
  • Overview
    • (0): Preliminaries
    • (1): Echo Broadcast
    • (2): Key Sharing
    • (3): Multiplication and Triples
    • (4): Signing
    • (X): Cheat Sheet
  • Initially, I thought the proof was missing
• ❓ No audit for the robust threshold ECDSA scheme by Damgård et al.⁴

Somewhat concerning

• Claude Code identified four unaddressed items from the Trails of Bits audit; they are not high-severity though:
  • #4 Ciphertext swapping (DB AAD missing) – Informational, Cryptography
  • #5 Hash function used as KDF (derive_tweak) – Informational, Cryptography
  • #6 P2P identity misbinding (duplicate p2p public keys) – Medium, Data Validation
  • #10 AES-GCM nonce reuse (96-bit random, no rotation) – Medium, Cryptography
• NEAR modified the Cait-Sith scheme¹
  • multiplicative rerandomization of pre-signatures

Concerning

• TEE-backed MPC nodes are off on mainnet (as of May 1st, 2026)
• No robustness and no identifiable abort (AFACCT)
  • a malicious participant who deviates can make signing fail (abort the protocol) and do so without being identifiable by honest parties $\Rightarrow$ 1 participant can DoS
• NEAR had a lot of GitHub CI security issues in the Trail of Bits report (#12, #13, #14¹)
  • #14 could’ve allowed an attacker to release a completely malicious binary (was rated “difficult” though)

Deeply concerning

• 5 out of 8 secret-sharing on mainnet (see here)
  • The Ronin Bridge attack compromised exactly $t=5$ out of $n=9$
• No proactive refresh, even though re-sharing (for nodes leaving and joining) is implemented and would be trivial to call periodically
  • Without proactive refresh, an attacker can slowly take its time and compromise all 5 keys
  • The last re-sharing (and thus refresh) was on March 3rd, 2026
    • $\Rightarrow$ any progress an attacker made in the last 2 months (as of May 1st, 2026) is still good progress
  • Why not? Because proactive refresh must invalidate the ECDSA pre-signatures, which lowers performance.
• The Cait-Sith threshold ECDSA library was not part of the audit; only its use by NEAR’s MPC node implementation was audited¹
  • This library may not have been production-ready.

Resources

Links and notes

• NEAR actually implemented two different threshold ECDSA protocols: Cait-Sith⁵ and Damgård et al.⁴
• Documentation on Cait-Sith library and design
• Near MPC repo

MPC node operators

Operators:

• lacksandtech.near,
• mpc-lgns.near,
• multichain-mainnet-aurora.near,
• near-mpc-staking4all-01.near,
• nodemonster.near,
• n1-multichain.near,
• everstake-mpc-1.near,
• stakin-mpc.near

NEAR-affiliated names visible:

• n1-multichain.near (NEAR One)
• multichain-mainnet-aurora.near (Aurora)

The rest are independent operators (Everstake, Stakin, etc.).

Why no proactive refresh?

First, Beaver triple secret sharing do not need to be refreshed: theft of such sharings do not lead to signature forgeries. Furthermore, $t$-out-of-$n$ secret-shared beaver triples continue to be usable after refresh.

Second, recall that a pre-signature for $k \cdot G$ is a secret sharing:

where $[k]_i$ is player $i$’s ($t$-out-of-$n$) share of the nonce $k$ (and, similarly, $[k\cdot \sk]_i$ is $k\cdot \sk$’s share).

While pre-signatures are indifferent to the secret-sharing of $\sk$ changing, theft of $t$ pre-signature shares would lead to recovery of the $\sk$: the adversary can reconstruct $k$ and $k\cdot \sk$ and then obtain $\sk$.

Hence, for refresh to be meaningful, pre-signatures have to be securely erased/discarded and new ones need to be generated.

Why presignature rerandomization exists

tl;dr: Rerandomization adapts a master-key presignature to sign under $\mathsf{sk} + e$ in 1 online round, with a guardrail against accidental presignature reuse.

NEAR’s MPC supports additive HD key derivation: derived keys are:

where $e = H(\mathsf{account_id}, \mathsf{path})$ is public.

But cached presignatures $(R, [k]_i, [\sigma]_i)$ are generated with respect to the master $\mathsf{sk}$ (i.e. $\sigma = k \cdot \mathsf{sk}$).

To sign for $\mathsf{sk}_{\mathsf{app}}$ instead of $\mathsf{sk}$, each party must locally adjust their $\sigma$-share to:

This $\sigma$-adjustment is why rerandomization exists.

NEAR additionally multiplies through by a public scalar $\delta = \mathsf{HKDF}(\mathsf{pk}, \mathsf{tweak}, \mathsf{msg_hash}, R, \mathsf{participants}, \mathsf{entropy})$, yielding:

This multiplicative step is not needed for nonce freshness: each signing request already consumes a fresh presignature (crates/node/src/providers/ecdsa/sign.rs:73, take_owned()), so the underlying $k$ is already per-request.

What $\delta$ buys is defense-in-depth: if a bug or retry path ever served the same presignature twice across different $(\mathsf{msg}, \mathsf{tweak})$ pairs, which would normally leak $\mathsf{sk}$, the request-bound $\delta$ ensures the effective nonces still differ. ToB’s audit¹ also notes NEAR picked the multiplicative form (vs. Groth–Shoup’s additive⁶) because the security proof was easier to write that way.

Was not able to find the proof in their repo.

Script: Fetch all MPC participants

curl -s -X POST https://rpc.mainnet.near.org -H "Content-Type: application/json" -d '{
    "jsonrpc":"2.0","id":"1","method":"query",
    "params":{"request_type":"call_function","finality":"final",
              "account_id":"v1.signer","method_name":"state","args_base64":"e30="}
  }' | jq -r '.result.result | implode' | jq .

Script: MPC membership over time

Based on visible on-chain history, no pure refresh (same set) has happened on mainnet. Every reshare was triggered by a membership change.

Here’s what each epoch’s vote_new_parameters proposal actually contained (winning proposals only, ordered by epoch):

Run this vibe-coded script to reproduce these results.

References

For cited works, see below 👇👇

Overview

$\term{t}$-out-of-$\term{n}$ means you need $t$ shares to reconstruct out of all $n$ shares.

Step 1: Commit to shares $\rightarrow$ split each share into $\term{m}$ chunks $\rightarrow$ ElGamal-encrypt chunks:

• Pick random degree $t-1$ polynomial
• Commits to its $t$ coefficients
• Vanilla ElGamal batch encrypt the $nm$ chunks of the shares for each player

Step 2: Proofs:

1. Proof of correct secret sharing: i.e., ciphertexts encrypt the chunks of the $n$ evaluations of the committed degree-$t$ polynomial
2. Proof of correct chunking: i.e., ciphertexts encrypt small enough chunks

Preliminaries

Notation

We use additive notation for group operations: scalar multiplication is denoted $a \cdot G$ (rather than $G^a$), group addition is $A + B$ (rather than $A \cdot B$), and the identity element is $\mathcal{O}$ (rather than $1$). We denote the generators of $\mathbb{G}_1$ and $\mathbb{G}_2$ as $\Gone$ and $\Gtwo$, respectively.

The Groth21 scheme does not need pairing-friendly groups (it can be that $\Gr_1 = \Gr_2$), but we describe it as if it used pairing-friendly groups. This is more general and in line with DFINITY’s implementation over BLS12-381 which has Type-III pairings.

• $\term{\lambda}$ - the security parameter (should be 128)
  • We work over groups of size $\sizeof{\Gr_1} \equiv 2^{2\lambda}$
• $\emph{t}$ - threshold (need $t$ shares to reconstruct)
• $\emph{n}$ - number of players / shares
• $\term{B}=2^{\term{b}}$ - each share is split into a chunk $< B$
  • But Groth’s approximate range proof will give a worse guarantee; see below.
  • $B=2^{40}$ should be practical for baby-step giant step ($2^{20} \times .5$ $\mu$s = ~0.5 secs)
    • However, Groth21’s approximate range proof means we will have to compute DLs much bigger than $B$
• $\emph{m}$ - the # of chunks we split a field element share into; typically set to $2\lambda/b$
• Groth21-specific parameters:
  • $\term{\ell}$ - number of approximate range proof repetitions
  • $\term{E}$ - size of a Fiat-Shamir challenge; set as $E = 2^{\lceil{\lambda}/{\ell}\rceil}$
    • Repeating $\ell$ times reduces the risk of fraud on entry $(i, j)$ to $\le E^{-\ell}$
  • $\term{S}$ - the range that the random Groth sums will be in; should be $\emph{S} = nm(B-1)(E-1)$
  • $\term{Z}=2\ell S = 2\ell nm (E-1)(B-1)$ - the size of the range of the sum after blinding (see $\ProveChunk$)
    • The decrypted chunk is guaranteed to be in $[1-Z, Z-1]$
      • TODO: What about $\Delta$?
    • So the max range of a discrete log is $(Z-1)-(1-Z)+1= 2Z-1$
      • The verifier needs to compute $E-1$ discrete logs from a range of size $2Z-1$.
      • The cost of this computation is $(E-1)\cdot \sqrt{2Z-1}$.
        • This means that we will need to use a much smaller $B$.
        • We can do slightly better by using batched BSGS DL algorithms

I am not sure if this is right. It’s been a while. See Chunky full benchmarks too, for a slightly different note on DLs.

Public key encryption

$\mathsf{PKE.KeyGen}(1^\lambda)\rightarrow(\term{\dk},\term{\ek})$:

• $\dk \randget \Zp$
• $\ek\gets \dk \cdot \Gone$
• (Also includes a ZKPoK but ignoring here)

Groth21 ZK building blocks

ZKP for “correct secret sharing”

Overview

• Public inputs:
  • $n$ encryption keys $\ek_i$
  • $n$ ElGamal ciphertexts $\term{R},(\term{C_i})_{i\in[n]}$ (with the same randomness)
  • Feldman commitment $(\term{A_k})_{k\in[0,t)}$ to polynomial coefficients $a_i$’s that define a polynomial $\term{a(X)}$
• Private inputs:
  • ElGamal shared randomness $\term{r}$
  • Encrypted messages $(\term{s_i})_{i\in[n]}$
• Relation:
  • $A_k = a_k \cdot \Gtwo,\forall k\in[0,t)$, where $a(X) = \sum_{k\in[0,t)} a_k X^k$
  • $R = r \cdot \Gone$
  • $C_i = r \cdot \ek_i + s_i \cdot \Gone$, $\forall i\in[n]$
  • $s_i = a(i)$

Algorithms

$\ProveSh \begin{pmatrix} \ek_1,\ldots,\ek_n, A_0,\ldots,A_{t-1}, C_1,\ldots,C_n,R;\
s_1,\ldots,s_n,r \end{pmatrix}\rightarrow \pi_S$:

Let $a_k$ denote the scalar such that $A_k = a_k \cdot \Gtwo$; then, the relation being proved is that:

• Derive Fiat-Shamir challenge $x$ from the public statement
• $(\term{\alpha},\term{\rho}) \randget \Zp^2$
• $\term{Y}\gets \rho \cdot \left(\sum_{i=1}^n x^i \cdot \ek_i\right) + \alpha \cdot \Gone$
• // note: we can think of this 4-round protocol as a 3-round one, where $\left(x,\sum_{i=1}^n x^i \cdot \ek_i\right)$ is part of the public statement (and $\sum_{i=1}^n s_i x^i$ is part of the witness?)
• $\term{F}\gets \rho \cdot \Gone$

• $\term{A}\gets \alpha \cdot \Gtwo$

• Derive Fiat-Shamir challenge $x’$ from transcript so far (i.e., public statement and $F,A,Y$)
• $\term{z_r} \gets \rho + x’r$
• $\term{z_a}\gets \alpha + x’\sum_{i=1}^n s_i x^i$
• return $(F,A,Y,z_r,z_a)$

$\VerSh \begin{pmatrix} \ek_1,\ldots,\ek_n, A_0,\ldots,A_{t-1}, C_1,\ldots,C_n,R;\pi_S \end{pmatrix}\rightarrow \{0,1\}$:

• Parse $\pi_S$
• assert $x’ \cdot R + F \stackrel{?}{=} z_r \cdot \Gone$
• assert $x’ \cdot \left(\sum_{k=0}^{t-1} \left(\sum_{i\in[n]} i^k x^i\right) \cdot A_k\right) + A \stackrel{?}{=} z_a \cdot \Gtwo$ (over $\mathbb{G}_2$)

Correctness holds because: \begin{align} x’ \cdot \left(\sum_{k=0}^{t-1} \left(\sum_{i\in[n]} i^k x^i\right) \cdot A_k\right) + A &= \alpha \cdot \Gtwo + x’ \cdot \sum_{k=0}^{t-1} \left(\sum_{i=1}^n i^k x^i\right) \cdot A_k\\
&= \alpha \cdot \Gtwo + x’ \cdot \sum_{i=1}^n x^i \cdot \left(\sum_{k=0}^{t-1} i^k \cdot A_k\right)\\
&= \alpha \cdot \Gtwo + x’ \cdot \sum_{i=1}^{n} (s_i x^i) \cdot \Gtwo\\
&= \alpha \cdot \Gtwo + x’ \cdot \left(\sum_{i=1}^{n} s_i x^i\right) \cdot \Gtwo\\
&= \left(\alpha + x’\sum_{i=1}^{n}s_i x^i\right) \cdot \Gtwo\\
&= z_a \cdot \Gtwo \end{align}

• assert $x’ \cdot \left(\sum_{i=1}^{n} x^i \cdot C_i\right) + Y \stackrel{?}{=} z_r \cdot \left(\sum_{i=1}^{n} x^i \cdot \ek_i\right) + z_a \cdot \Gone$ (over $\mathbb{G}_1$)

Correctness holds because: \begin{align} x’ \cdot \left(\sum_{i=1}^{n} x^i \cdot C_i\right) + Y &= x’ \cdot \sum_{i=1}^{n} x^i \cdot (r \cdot \ek_i + s_i \cdot \Gone) + \rho \cdot \left(\sum_{i=1}^n x^i \cdot \ek_i\right) + \alpha \cdot \Gone\\
&= x’ \cdot \sum_{i=1}^{n} (r x^i) \cdot \ek_i + x’ \cdot \sum_{i=1}^{n} (s_i x^i) \cdot \Gone + \rho \cdot \left(\sum_{i=1}^n x^i \cdot \ek_i\right) + \alpha \cdot \Gone\\
&= (rx’) \cdot \left(\sum_{i=1}^{n} x^i \cdot \ek_i\right) + \left(x’ \sum_i s_i x^i\right) \cdot \Gone + \rho \cdot \left(\sum_{i=1}^n x^i \cdot \ek_i\right) + \alpha \cdot \Gone\\
&= (\rho+x’r) \cdot \left(\sum_{i=1}^{n} x^i \cdot \ek_i\right) + \left(\alpha + x’\sum_i s_i x^i\right) \cdot \Gone\\
&= z_r \cdot \left(\sum_{i=1}^{n} x^i \cdot \ek_i\right) + z_a \cdot \Gone \end{align}

• return 1

Performance

• Prover time:
  • size-$(n+1)$ $\mathbb{G}_1$ MSM for $Y$
  • 1 scalar mul in $\mathbb{G}_1$ for $F$
  • 1 scalar mul in $\mathbb{G}_2$ for $A$
  • (ignored: one degree-$n$ polynomial evaluation at a random point)
• Verifier time:
  • size-$(2n+4)$ $\mathbb{G}_1$ MSM (combining first check for $F$ with third check for $Y$)
  • size-$(t+2)$ $\mathbb{G}_2$ MSM (second check for $A$)
• Proof size:
  • 2 field elements in $\Zp$ ($z_r, z_a$)
  • 2 group elements in $\mathbb{G}_1$ ($F,Y$)
  • 1 group element in $\mathbb{G}_2$ ($A$)

ZKP of “correct chunking”

Uses public parameters $\emph{\ell},\emph{E},\emph{S},\emph{Z}$.

Overview

• Public inputs:
  • $n$ encryption keys $\ek_i$
  • $nm$ ElGamal ciphertexts $(\term{R_j}){j\in[m]},(\term{C{i,j}})_{i\in[n],j\in[m]}$
• Private inputs:
  • ElGamal shared randomness $(\term{r_j})_{j\in[m]}$
  • Encrypted messages $(\term{s_{i,j}})_{i\in[n],j\in[m]}$
• Relation:
  • $\forall j\in[m], R_j = r_j \cdot \Gone$
  • $\forall i\in[n],j\in[m]$, $C_{i,j} = r_j \cdot \ek_i + s_{i,j} \cdot \Gone$
  • $\forall i\in[n],j\in[m],\exists \term{\Delta_{i,j}}\in [1,E-1]$, such that $\Delta_{i,j}\cdot s_{i,j}\in [1-Z,Z-1]$

Algorithms

$\ProveChunk \begin{pmatrix} \ek_1,\ldots,\ek_n, R_1,\ldots,R_m, C_{1,1}\ldots,C_{n,m};\
r_1,\ldots,r_m, s_{1,1},\ldots,s_{n,m} \end{pmatrix}\rightarrow \pi_C$:

• $\term{\ek_0} \randget \mathbb{G}_1$
• do:
  • $(\term{\sigma_1},\ldots,\sigma_\ell) \randget [-S,Z-1]^\ell$ (blinders)
  • $(\term{\beta_1},\ldots,\beta_\ell) \randget \Zp^\ell$
  • $\forall k\in[\ell]$: (encrypting them)
    • $B_k \gets \beta_k \cdot \Gone$
    • $C_k \gets \beta_k \cdot \ek_0 + \sigma_k \cdot \Gone$
  • Derive Fiat-Shamir challenges $e_{1,1,1},\ldots,e_{n,m,\ell}\in[0,E)$ from transcript so far (i.e., public statement and $\ek_0,B_1,C_1,\ldots,B_\ell, C_\ell$)
  • $\forall k \in[\ell],$ $z_{s,k} \gets \sum_{i\in[n],j\in[m]}e_{i,j,k}\cdot s_{i,j} + \sigma_k$ (random subset sum plus blinders)

WARNING: Groth says “some sums would require slightly faster or slower computation, so we may use constant time algorithms to prevent timing leaks.” This is worrisome and would need to be carefully implemented.

• until $\forall k\in[\ell],$ $z_{s,k} \in [0,Z-1]$ (expected # of iterations is 2; see below)
  • Groth says “The risk of landing outside the range in [the $\ell$ runs that compute all $z_{s,k}$’s] is $\le (\ell S)/Z=(\ell S)/(2\ell S)=\frac{1}{2}$”
  • If the failure probability is $S/Z$, then the success probability is $p=1-\frac{1}{2}=1/2$. To get a success, the expected # of trials is $1/p=2$.

“If failure occurs on $\lambda$ tries then abort.” Why should this abort instead of repeating until success?

• $(\delta_0,\ldots,\delta_n) \randget \Zp^n$ (begin $\Sigma$ protocol)
• $\forall i\in[0,n], D_i \gets \delta_i \cdot \Gone$

• $Y\gets \sum_{i=0}^n \delta_i \cdot \ek_i$

• Derive Fiat-Shamir challenge $x\in\{0,1\}^\lambda$ from transcript so far (i.e., public statement and $\ek_0,B_1,C_1,\ldots,B_\ell, C_\ell, e_{1,1,1},\ldots,e_{m,n,\ell },D_0,\ldots,D_n,Y$)
• $\forall i\in[n],z_{r,i} \gets \sum_{j\in[m],k\in[\ell]} e_{i,j,k}\cdot r_j \cdot x^k+\delta_i$
• $z_\beta \gets \sum_{k=1}^\ell \beta_k x^k+\delta_0$
• $\pi_C \gets \begin{pmatrix} \ek_0, (B_1,\ldots,B_\ell), (C_1,\ldots,C_\ell), (D_0,\ldots,D_n), Y,\
  (z_{s,1},\ldots,z_{s,\ell}), (z_{r,1},\ldots,z_{r,n}), z_\beta \end{pmatrix}$

$\VerChunk \begin{pmatrix} \ek_1,\ldots,\ek_n, R_1,\ldots,R_m, C_{1,1}\ldots,C_{n,m}; \pi_C \end{pmatrix}\rightarrow \{0,1\}$:

• parse $\pi_C$
• assert $\forall k\in[\ell], z_{s,k} \in [0,Z-1]$
• assert:

\begin{align} &\forall i\in[n],\ \sum_{j=1}^m \left(\sum_{k=1}^\ell e_{i,j,k}\cdot x^k\right) \cdot R_j + D_i \stackrel{?}{=} z_{r,i} \cdot \Gone\\
&\sum_{k=1}^\ell x^k \cdot B_k + D_0 \stackrel{?}{=} z_\beta \cdot \Gone\\
&\sum_{k=1}^\ell x^k \cdot \left( \sum_{i=1}^n \sum_{j=1}^m e_{i,j,k} \cdot C_{i,j} \right) + \sum_{k=1}^\ell x^k \cdot C_k + Y\\
&\quad\stackrel{?}{=} \sum_{i=1}^n z_{r,i} \cdot \ek_i + z_\beta \cdot \ek_0 + \left(\sum_{k=1}^\ell z_{s,k}\cdot x^k\right) \cdot \Gone \end{align}

Reorganized verifier

Pick random $\gamma_i$’s:

\begin{align} &\forall i\in[n],\ \sum_{j=1}^m \left(\sum_{k=1}^\ell e_{i,j,k}\cdot x^k\right) \cdot R_j + D_i \stackrel{?}{=} z_{r,i} \cdot \Gone\Leftrightarrow\\
&\sum_{i\in[n]}\left(\gamma_i \cdot \sum_{j=1}^m \left(\sum_{k=1}^\ell e_{i,j,k}\cdot x^k\right) \cdot R_j + \gamma_i \cdot D_i - (z_{r,i}\gamma_i) \cdot \Gone\right)\stackrel{?}{=} \mathcal{O}\Leftrightarrow\\
&\sum_{j=1}^m \left(\sum_{i\in[n]}\gamma_i\sum_{k=1}^\ell e_{i,j,k}\cdot x^k\right) \cdot R_j + \sum_{i\in[n]} \gamma_i \cdot D_i - \left(\sum_{i\in[n]}z_{r,i}\gamma_i\right) \cdot \Gone \stackrel{?}{=} \mathcal{O} \end{align}

Performance

• Prover time:
  • $\ell$ $\mathbb{G}_1$ scalar muls for $B_k$’s
  • $\ell$ size-2 $\mathbb{G}_1$ MSMs for $C_k$’s
    • To avoid recomputing these, we first check that the $\sigma_k$’s yield in-range $z_{s,k}$’s before computing $B_k$ and $C_k$
  • $n$ $\mathbb{G}_1$ scalar muls for $D_i$’s
  • size-$n$ $\mathbb{G}_1$ MSM for $Y$
• Slightly-optimized verifier time:
  • (ignored: $m$ multiplications modulo $p$, for computing $x,\ldots,x^\ell$)
  • size-$(m+n+1)$ $\mathbb{G}_1$ MSMs for checking the $D_i$’s ($\pi_C$); via reorganized verifier
  • size-$(\ell+2)$ $\mathbb{G}_1$ MSM for checking $D_0$ ($\pi_C$)
    • Note: batch with previous one, no, since scalars are big?
  • $\ell=32$ size-$nm$ $\mathbb{G}_1$ MSMs, but with small scalars $e_{i,j,k} \le E = 2^8$ (for each MSM of $C_{i,j}$’s with $e_{i,j,k}$’s)
  • a size-$\ell$ $\mathbb{G}_1$ MSM for linear combination of $C_{i,j}$ MSMs with $x^k$
  • size-$(\ell+1+n+2)=(\ell+n+3)$ $\mathbb{G}_1$ MSM for the remaining of the last (third) verifier equation: i.e., scalar muls on $C_k$’s, $Y$, $\ek_i$’s, $\ek_0$ and $\Gone$
    • Note: can batch with previous ones, no, since scalars are big?
• Optimized verifier time:
  • size-$[(m+n+1) + (\ell+2) + (\ell) + (\ell+n+3)]=(m+2n+3\ell+5)$ $\mathbb{G}_1$ MSM for $\pi_C$ (batched checks)

Three scalars share the same $\Gone$ base, so we could subtract 2 from this formula (but it won’t make a difference in practice).

• Proof size (according to Groth¹):
  • $\ell$ small integers in $[0, Z)$ (the $z_{s,k}$’s)
  • $n+1$ field elements in $\Zp$ (the $z_{r,i}$’s and $z_\beta$)
  • $2\ell+n+3$ group elements in $\mathbb{G}_1$
    • $2\ell$ for $B_k$’s and $C_k$’s
    • $n+1$ for $D_i$’s
    • $\ek_0$ and $Y$

Groth21 PVSS without forward-secure encryption

Algorithms

Parameters: (1) $\emph{\lambda}$ is the security parameter, typically set to 128 (in Groth¹, it is the size of a field element and set to 256); (2) the parameter $\emph{\ell}$ should be picked to optimize performance.

Investigate optimal $\ell$ via benchmarking.

$\pvss.\setup(1^\lambda, \emph{B}=2^{\emph{b}},\ell) \rightarrow (\prk,\vk)$:

• $\emph{m}\gets 2\lambda/b$ (the # of chunks we split a field element share into)
• $\emph{E}\gets 2^{\lceil \lambda/\ell\rceil}$ (the probability of ciphertext $C_{i,j}$ falling outside the range $=E^{-\ell} = 2^{-\lambda}$)
• $\emph{S}=nm(B-1)(E-1)$ (a parameter that arises in the proof of correct chunking)
• $\emph{Z}=2\ell S$ (when decrypting shares, the worst case range to compute DLs in will be $[1-Z, Z-1]$)

$\pvss.\deal(t, n, {\ek_1,\ldots,\ek_n}, a_0) \rightarrow \trx$:

• $(a_1,\ldots,a_{t-1}) \randget \Zp^{t-1}$
• $(A_0,\ldots,A_{t-1})\gets(a_0 \cdot \Gtwo,\ldots,a_{t-1} \cdot \Gtwo)$
• $s_i \gets p(i), \forall i\in[n]$, where $p(X) \gets \sum_{i=0}^{t-1} a_i X^i$
• $(r_1,\ldots,r_m)\randget\Zp^m$
• $(R_1,\ldots,R_m)\gets(r_1 \cdot \Gone,\ldots,r_m \cdot \Gone)$
• $\forall i\in[n],j\in[m]$:
  • Let $s_{i,j}\in[0,B)$ denote the decomposition of $s_i = \sum_{j=1}^{m} s_{i,j}B^{j-1}$
  • $C_{i,j}\gets r_j \cdot \ek_i + s_{i,j} \cdot \Gone$
• $r\gets \sum_{j=1}^{m} r_{j}B^{j-1}$ (note: this will be the shared ElGamal randomness that encrypts all $s_i$’s)
• $R\gets r \cdot \Gone$
• $\forall i\in[n]$:
  • $C_i\gets r \cdot \ek_i + s_i \cdot \Gone$

Isn’t it faster for the verifier to reconstruct $C_i$’s from $C_{i,j}$’s?

• $\pi_S\gets \ProveSh \begin{pmatrix} \ek_1,\ldots,\ek_n, A_0,\ldots,A_{t-1}, C_1,\ldots,C_n,R;\
  s_1,\ldots,s_n,r \end{pmatrix}$
• $\pi_C\gets \ProveChunk \begin{pmatrix} \ek_1,\ldots,\ek_n, R_1,\ldots,R_m, C_{1,1}\ldots,C_{n,m};\
  r_1,\ldots,r_m, s_{1,1},\ldots,s_{n,m} \end{pmatrix}$
• $\trx\gets \begin{pmatrix} (C_{1,1},\ldots,C_{n,m}), (R_1,\ldots,R_m), (A_0,\ldots,A_{t-1}),\
  \pi_S,\pi_C \end{pmatrix}$

$\pvss.\verify(\trx, t, n, {\ek_1,\ldots,\ek_n}) \rightarrow \{0,1\}$:

• Parse $\trx$ (as per $\pvss.\deal$)
• $\forall i\in[n], C_i \gets \sum_{j=1}^m B^{j-1} \cdot C_{i,j}$
• $R\gets \sum_{j=1}^{m} B^{j-1} \cdot R_{j}$
• $\VerSh \begin{pmatrix} \ek_1,\ldots,\ek_n, A_0,\ldots,A_{t-1}, C_1,\ldots,C_n,R;\pi_S \end{pmatrix}$
• $\VerChunk \begin{pmatrix} \ek_1,\ldots,\ek_n, R_1,\ldots,R_m, C_{1,1}\ldots,C_{n,m};\pi_C \end{pmatrix}$
• return 1

$\pvss.\decrypt(\trx, t, n, i,\dk_i) \rightarrow s_i$:

• Parse $\trx$ (as per $\pvss.\deal$)
• for $j\in[m]$:
  • $h_{i,j}\gets C_{i,j} - \dk_i \cdot R_j$
  • for $\Delta_{i,j}\in [1,E-1]$:
    • try to compute DL on $\Delta_{i,j}^{-1} \cdot h_{i,j}$ (should be equal to $s_{i,j} \cdot \Gone$)

If $\Delta_{i,j}\cdot s_{i,j}\in [1-Z,Z-1]$ then the range for the DL computation on $\Delta_{i,j}^{-1} \cdot h_{i,j}$ will be getting smaller and smaller as we increase $\Delta_{i,j}$, no?

Asymptotic performance

Note: These are for the non-forward-secure PVSS variant, to fairly compare to our (future) PVSS construction.

Transcript size

• $\ell$ small integers in $[0,Z)$ (from $\pi_C$)
• $2 + (n+1)\ \sizeof{\Zp}$ (from $\pi_S$ and from $\pi_C$)
• $(nm+m)+ 2 + (2\ell+n+3)\ \sizeof{\mathbb{G}_1}$ (from the ElGamal ciphertexts, from $\pi_S$, and from $\pi_C$)
• $t+1$ $\sizeof{\mathbb{G}_2}$ (from Feldman commitment and from $\pi_S$)

The ZKP overheads for $\pi_S$ are in the correct sharing section and for $\pi_C$ in the correct chunking section.

Add sizes for $n=1{,}000$ and $m=10$ (assuming right parameterization).

Prover time

In $\Zp$:

1. degree $m-1$ poly eval on point $B$ (for computing $r$)
2. degree-$n$ poly eval at a random $\Zp$ point (for $\pi_S$)

In $\mathbb{G}_1$:

1. $m+1$ scalar muls (from chunked ElGamal $R_j$’s and $R$)
2. $nm$ size-2 MSMs (where 1 scalar is $<B$) (from chunked ElGamal $C_{i,j}$’s)
3. $n$ size-2 MSMs (from ElGamal $C_i$’s)
4. size-$(n+1)$ MSM (for $\pi_S$)
5. 1 scalar mul (for $\pi_S$)
6. $\ell+n$ scalar muls (for $\pi_C$)
7. size-$n$ MSM (for $\pi_C$)
8. $\ell$ size-2 $\mathbb{G}_1$ MSMs (for $\pi_C$)

In $\mathbb{G}_2$:

1. $t$ scalar muls (from Feldman commitment)
2. 1 scalar mul (for $\pi_S$)

Verifier time

In $\mathbb{G}_1$:

• $n+1$ size-$m$ MSMs (where scalars are $B^0\ldots B^{m-1}=2^{2\lambda}$, so first ones are small) for recomputing the $n$ ElGamal $C_i$’s and $R$

In $\mathbb{G}_2$:

(See the correct sharing ZKP performance section.)

Share decryption time

Chunk decryption could involve computing at most $\emph{E}-1$ DLs in a range of size $2\emph{Z}-1$.

Share decryption involves $\sizeof{\F}/\log_2{\emph{B}}$ chunk decryptions.

Honest-case $\mathbb{G}_1$:

1. $\sizeof{\F}/\log_2{B} \times \sqrt{B}$ group ops

Malicious case $\mathbb{G}_1$:

1. $\sizeof{\F}/\log_2{B} \times (E-1) \times \sqrt{2Z-1}$ group ops

It will not get this bad because the range of the DLs will get smaller as $\Delta_{i,j}$ increases. Plus, it’s unclear how many chunks in a share a malicious dealer will be able to “inflate” in size.

Implementations

• Sourav’s implementation: e2e-vss on GitHub
• DFINITY’s implementation: ni_dkg on GitHub

DFINITY’s PVSS parameterization (${\lambda},{\ell}, {E}, {B}, {S}, {Z}$)

• $\emph{\lambda}$ = SECURITY_LEVEL = 256 (source)
• $\emph{\ell}$ = NUM_ZK_REPETITIONS = 32 (source)
• $\log_2{\emph{E}}$ = CHALLENGE_BITS = SECURITY_LEVEL / NUM_ZK_REPETITIONS $= 8$ (source)
  • $E=2^8=256$
  • CHALLENGE_MASK $= E-1= 255$ (source)
• $\emph{B}$ = CHUNK_SIZE $= 2^{16}$ (source; i.e., the cardinality of the range)
  • number of chunks $\emph{m}=\sizeof{\F} / \log_2{B} = 256/16 = 16$
  • CHUNK_BYTES = 2 bytes = 16 bits
  • CHUNK_MIN = 0
  • CHUNK_MAX $= 2^{\mathsf{CHUNK_SIZE}} - 1$
• $\emph{S}$ = ss = n * m * (CHUNK_SIZE - 1) * CHALLENGE_MASK $= nm(B-1)(E-1)$ (source)
  • e.g., for $n=100$ and $m=256/16=16$, we’d get $S=100\cdot 16(2^{16}-1)\cdot 255$ = 26,738,280,000 (a 35-bit number)
• $\emph{Z}$ = zz $= 2\ell S$ (source)
  • e.g., for the same $n,m$ as above, this is $Z=$ 1,711,249,920,000 (a 41-bit number)

Implications on computing DLs:

Due to the approximate guarantees of the proof of correct chunking, chunk decryption could involve computing at most $E-1$ DLs in a range of size $2Z-1$. So, computing at most 255 DLs of 42-bit numbers. Note that share decryption involves $256/\log_2(B)=256/16=16$ chunk decryptions.

• We’d need to consider average-case, best-case and worst-case share decryption times in our evaluation?
  • Even in the best-case, will we be better because we’d have fewer chunks than Groth? The answer is no!
    • Groth uses $B=2^{16}$ and should(?) need to run a 16-bit DL on all 16 chunks: $2^{16/2} \times 0.5$ microsecond $\times$ 16 = 2.05 millisecs
    • Say we use a bigger chunk size $B=2^{37}$ and run a 37-bit DL on all 7 chunks: $2^{37/2} \times 0.5$ microsecond $\times$ 7 = 1.30 secs
    • So, bigger chunks does not give us an advantage (in the best case), because the share decryption time when using $B=2^b$ bits per chunk will be $f(b)=2^{b/2} \cdot (256 / b)$.
    • We’d clearly want to use smaller, not bigger $b$!
    • In fact, the optimal chunk size that minimizes the share decryption time $f(b)$ is $b=2/\ln{2}\approx 3$ bits.
    • I think this explains why Groth sets his chunk size to 16, which is bigger than the optimal 3: he is accepting higher share decryption time for smaller transcripts and thus faster proving, faster verification.
  • We’d definitely do better in the worst-case: an adversarial prover could potentially force the share decryption time to be much higher: e.g., 255 runs of 42-bit(?) DL on each of the 16 chunks. (We’d need to understand how bad it can get though… Maybe the prover can only increase some of the encrypted chunks, not all)

Sourav’s implementation

Sourav used the same parameterization as DFINITY’s above.

These benchmarks were run in 2024, or earlier:

groth/deal-t=660/n=1024 time: [3.6432 s 3.6925 s 3.7592 s]
groth/verify-t=660/n=1024 time: [2.1861 s 2.2049 s 2.2291 s]

Appendix

Attack: Inflate 1 chunk to $\approx Z/E$

The soundness of $\ProveChunk$ only guarantees that the extracted chunk $s_{i,j}$ satisfies:

for some $\emph{\Delta_{i,j}}\in[1,E-1]$.

Worst case has $\Delta_{i,j}=1 \Rightarrow$ admits $\sizeof{s_{i,j}}$ up to $Z-1$.

But an efficient adversary cannot reach this worst case. Below we show a one-shot deterministic attack that installs a single chunk of size $c \approx Z/E$.

The dealer will set $s_{1,1} = \term{c}$, where:

while setting all other $s_{i,j} \in [0, B-1]$. Recall $\emph{S} = nm(B-1)(E-1)$ and $\emph{Z}=2\ell S$.

Step 1: Pick polynomial with $p(1) = c$

PVSS dealing can take place in one out of two settings:

Dealer can freely pick the secret $a_0$:

• Sample $a_1, \ldots, a_{t-1}\randget\Zp$
• Solve for $a_0$ such that $c = p(1) \Leftrightarrow c = \sum_{k=0}^{t-1} a_k \cdot 1^k$
  • $\Rightarrow a_0 \gets c - \sum_{k=1}^{t-1} a_k$

Dealer’s secret $a_0$ is fixed; they cannot pick it:

• Requires $t \geq 2$ (so there is at least one free coefficient besides $a_0$).
  • $t=1$ is a degenerate threshold.
  • In other words, the secret sharing is trivial: everyone has the same share: $a_0$, which makes this case uninteresting.
• Sample $a_2, \ldots, a_{t-1}\randget\Zp$
• Solve for $a_1$ such that $c = p(1) \Leftrightarrow c = \sum_{k=0}^{t-1} a_k \cdot 1^k$
  • $\Rightarrow a_1 \gets c - \sum_{k\in[0,t-1],\ k\neq 1} a_k$

$\ProveSh$ only verifies the polynomial-evaluation relation. It doesn’t care how coefficients were chosen.

Step 2: Chunk share 1 such that its 1st chunk is oversized

First, chunk $s_1 = c$ as $(s_{1,1}, s_{1,2}, \ldots, s_{1,m}) = (c, 0, 0, \ldots, 0)$. Mathematically, this is a valid radix-$B$ decomposition:

except it is not a base-$B$ decomposition, since one of its digits is above $B$. This is exactly the core of the issue: the approximate range proof cannot enforce $s_{i,j} \in [0, B)$.

Second, chunk all other $s_i$’s for $i \geq 2$ honestly into $[0, B-1]^m$.

First, the position of the inflated chunk $c$ can also be arbitrary rather than fixed as the 1st chunk. Second, the zeros in $(c, 0, 0, \ldots, 0)$ are not essential: any values $s_{1,j}\in[0,B-1]$ work for $j\geq 2$. The bound on $c$ shifts only by $(m-1)(B-1)$, negligible compared to $c\approx Z/E$, so we can replace them with arbitrary random values in $[0, B-1]$ and pin $p(1)$ to the corresponding $s_1 = c + \sum_{j\geq 2} s_{1,j}B^{j-1}$.

Step 3: ElGamal-encrypt, run $\ProveSh$ honestly

$\ProveSh$ checks only the polynomial-evaluation and scalar-recombination relations, both of which hold by construction.

Step 4: Run $\ProveChunk$ with $\sigma_k = 0$

$\VerChunk$ checks:

1. $z_{s,k} \in [0, Z-1]$ for all $k$
2. three algebraic identities over $\mathbb{G}_1$ relating $B_k, C_k, D_i, z_{r,i}, z_{s,k}, z_\beta, Y$.

Critically: there is no check on $\sigma_k$. The verifier sees $\sigma_k$ only through the commitment $C_k = \beta_k \cdot ek_0 + \sigma_k \cdot G_1$, and the algebraic identities will continue to hold for any $\sigma_k$ the prover picks. The honest prover picks $\sigma_k \randget [-S, Z-1]$ for zero-knowledge (to statistically hide $s_{i,j}$’s contribution to $z_{s,k}$). A malicious dealer may have no interest in preserving ZK.

The dealer will pick $\sigma_k = 0$ for all $k$. With this choice, $z_{s,k} = \sum_{i,j} e_{i,j,k}\, s_{i,j} + 0 = \term{V_k}$, where

Upper bound on $V_k$:

By our choice of $c$:

Lower bound $V_k \geq 0$ holds trivially. So $z_{s,k} = V_k \in [0, Z-1]$ always, regardless of FS challenges. The rejection check in $\ProveChunk$ passes on the first try, every time. No grinding, no probability analysis.

Impact on share decryption

For DFINITY’s parameters ($n=40$, $m=16$, $B=2^{16}$, $E=256$, $\ell=32$, $\lambda=256$):

• $S \approx 2^{33.3}$, $Z \approx 2^{39.3}$, $Z/E \approx 2^{31.3}$.
• Honest chunk: $B-1 \approx 2^{16}$
• Malicious chunk from this attack: $c\approx 2^{31}$
• See more cases here for different chunk sizes $B$ and # of players $n$

Implementation

A working Rust implementation of this attack against the DFINITY parameterization is in alinush/groth21-rs under src/groth21/malicious.rs, with a test malicious_deal_passes_verification confirming the transcript clears the Groth21 verifier.

Attack: Inflate $m$ chunks to $\approx 2\ell nB$

Same $\sigma_k = 0$ machinery, same pinned-$p(1)$ polynomial trick. We only spread the chunk-mass budget across all $m$ chunks of share 1 instead of concentrating it in one.

Setup. Pick a new per-chunk magnitude $c$, to be bounded below This is not the $c \approx Z/E$ from the single-chunk attack above. Set $(s_{1,1}, \ldots, s_{1,m}) = (c, c, \ldots, c)$. Chunk the other shares $i\in \{2,\ldots,n\}$ honestly. Pin $p(1) \equiv c\cdot\frac{B^m-1}{B-1} \pmod p$ by solving for $a_1$, as described before.

Bound on $c$. With $\sigma_k = 0$, honest chunks on shares $2,\ldots,n$, and all $m$ chunks of share 1 at $c$, redefine

Assume worst case FS challenges, then solve for $c$ (recall from the preliminaries that $\emph{Z} = 2\ell nm(B-1)(E-1)$):

\begin{align} V_k \leq (E-1)\bigl[mc + (n-1)m(B-1)\bigr] &\leq Z-1 \Leftrightarrow\\
(E-1)mc + (E-1)(n-1)m(B-1) &\leq Z-1 \Leftrightarrow\\
(E-1)mc &\leq Z-1 - (E-1)(n-1)m(B-1) \Leftrightarrow\\
c &\leq \frac{Z-1 - (E-1)(n-1)m(B-1)}{(E-1)m}\\
&= \frac{Z-1}{m(E-1)} - (n-1)(B-1)\\
&= \frac{2\ell nm(B-1)(E-1) - 1}{m(E-1)} - (n-1)(B-1)\\
&\leq \frac{2\ell nm(B-1)(E-1)}{m(E-1)} - (n-1)(B-1)\\
&= 2\ell n(B-1) - (n-1)(B-1)\\
&= (B-1)\bigl[2\ell n - (n-1)\bigr]\\
&= (B-1)\bigl[n(2\ell-1) + 1\bigr]\\
&\leq 2\ell n B \end{align}

Cost comparison. Recall that batched BSGS can solve $k$ DLs each in a range of size $\leq R$ in time $\sqrt{k \cdot R}$. Applying this to share 1’s $m$ chunks:

• Honest dealer: $m$ DLs of size $B \rightarrow \sqrt{mB}$ time via batched BSGS
• Single-chunk attack: $m-1$ DLs of size $B$ and 1 DL of size $Z/E\approx 2\ell n m B$
  • Smartest algorithm: $\sqrt{mB}$ time for a batched BSGS, which actually identifies the inflated chunk. Then, do a BSGS in time $\sqrt{2\ell n m B}$ for the inflated chunk. This last one dominates.
• All-$m$-chunks attack (this section): $m$ DLs of size $2\ell nB$
  • Cost: $\sqrt{m \cdot 2\ell nB} = \sqrt{2\ell n m B}$ via batched BSGS. Same as the single chunk attack. Slightly cheaper actually.
  • The problem is the verifier doesn’t know which attack took place. So he will often incur the worst-case of the single-chunk attack if he is smart and tries to guess the attack.

Implementation

This variant is implemented in alinush/groth21-rs as malicious_deal_full_share in src/groth21/malicious.rs, with a test malicious_deal_full_share_passes_verification confirming the transcript clears the Groth21 verifier.

References

For cited works, see below 👇👇

Misc

• Move 1 to Move 2, by Greg Nazario

Keyless on-chain configs

Learn more about Keyless here.

0x1::keyless_account::Groth16VerificationKey

• devnet VK
• testnet VK
• mainnet VK

0x1::keyless_account::Configuration

• devnet configuration
• testnet configuration
• mainnet configuration

0x1::jwk_consensus_config::JWKConsensusConfig

• devnet providers
• testnet providers
• mainnet providers

You can echo the hex bytes (without the 0x prefix) through xxd -r -p to do a best-effort string decoding to see what’s there. e.g.,:

echo 68747470733a2f2f6163636f756e74732e676f6f676c652e636f6d2f2e77656c6c2d6b6e6f776e2f6f70656e69642d636f6e66696775726174696f6e | xxd -r -p

This will output:

https://accounts.google.com/.well-known/openid-configuration

In the past, there was an attempt to migrate from 0x1::jwks::SupportedOIDCProviders to 0x1::jwk_consensus_config::JWKConsensusConfig but we nixed it.

0x1::jwks::PatchedJWKs

• devnet JWKs
• testnet JWKs
• mainnet JWKs

References

For cited works, see below 👇👇

References

For cited works, see below 👇👇

Related work

WE is implied by indistinguishability-obfuscation (iO) but it is weaker than iO¹.

Affine determinant programs (ADPs)

Bartusek et al.² introduced affine determinant programs (ADPs) as key building block for WE and for iO.

An ADP is a function:

specified by a tuple $(\term{\A}, \term{\B_1, \ldots, \B_n})$ of $\term{k}\times k$ matrices over $\term{\Fq}$ and a function $\term{\eval}: \Fq \to \{0,1\}$. Specifically: \begin{align} \adp(\x) = \eval\left(\det{\left(\A + \sum_{i\in[n]} x_i \B_i\right)}\right) \end{align} where $\term{\x} \bydef (\term{x_1},\ldots,\term{x_n})$ An affine function $\M$ can be defined as: \begin{align} \M(\x) \bydef \A + \sum_{i\in[n]} x_i \B_i \end{align} so that the ADP can be more simply viewed as: \begin{align} \adp(\x) = \eval\left(\det{\M(\x)}\right) \end{align}

$x_i\B_i$ is defined as the all zeros matrix when $x_i = 0$ and as $\B_i$ when $x_i = 1$.

Viewed as an NP relation, ADP satisfiability becomes: \begin{align} \term{\Radp{\eval}}\begin{pmatrix}{} \A, \B_1,\ldots,\B_n \in \Fq^{k\times k} \textbf{;}\\
\x \end{pmatrix} = 1\Leftrightarrow { \x \in \{0,1\}^n } \wedge { 1 = \eval\left(\det{\left(\A + \sum_{i\in[n]} x_i \B_i\right)}\right) } \end{align}

The $x\in\{0,1\}^n$ check is actually also implemented as an ADP, but I am not showing it there for simplicity.

The ADP relation is parameterized by an $\eval$ function! Typically, the $\eval$ function may test whether its input is zero, or whether it has the right parity. e.g.: \begin{align} \term{\eval_0(y)} = \begin{cases} 1,& y \equals 0\\
0,& \text{otherwise} \end{cases} \end{align}

Encoding a dimension $d=1$ VSS as an ADP

The (dimension-1) vector subset-sum (VSS) problem can be defined as an NP relation:

\begin{align} \term{\Rvss}\begin{pmatrix}{} \mathbf{h} \in \Z^n, \ell \in \Z \textbf{;}\\
\witn \end{pmatrix} = 1\Leftrightarrow { \witn \in \{0,1\}^n } \wedge { \mathbf{h}\cdot \witn = \ell } \end{align}

They show how there exists a randomized ADP over $\Fp$ such that if satisfied it implies VSS satisfiability. Specifically, to encode a VSS instance $(\mathbf{h},\ell)$ as an ADP, pick a prime $q > \max_{\witn \in \{0,1\}^n} |\mathbf{h}\cdot \witn|$, interpret $\mathbf{h}$ and $\ell$ as elements of $\Fq$, sample $\R \xleftarrow{$} \Fq^{k \times k}$, and set $\A = -\ell \R$ and $\B_i = h_i \R$ for $i \in [n]$.

The requirement on $q$ ensures that the integer inner product $\mathbf{h}\cdot\witn$ does not wrap around modulo $q$, so that $\mathbf{h}\cdot\witn = \ell$ over $\Z$ iff $\mathbf{h}\cdot\witn = \ell$ over $\Fq$.

Correctness: $\forall \mathbf{h}\in\Fq^n,\ell \in \Fq,\witn\in\{0,1\}^n$ such that $\mathbf{h}\cdot \witn = \ell$, we have: \begin{align} \Pr_{\R \randget \Fq^{k\times k}}\begin{bmatrix} \emph{\Radp{\eval_0}}\begin{pmatrix} \underbrace{-\ell \R}_{\A}, \underbrace{h_1 \R}_{\B_1},\ldots,\underbrace{h_n \R}_{\B_n}\textbf{;}\\
\witn \end{pmatrix} = 1 \end{bmatrix} = 1 \end{align}

Soundness: $\forall \mathbf{h}\in\Fq^n,\ell \in \Fq,\witn\in\{0,1\}^n$ such that $\mathbf{h}\cdot \witn \ne \ell$, we have: \begin{align} \Pr_{\R \randget \Fq^{k\times k}}\begin{bmatrix} \Radp{\eval_0}\begin{pmatrix} -\ell \R, h_1 \R,\ldots, h_n \R\textbf{;}\\
\witn \end{pmatrix} = 1 \end{bmatrix} \leq k / q \end{align}

Proof (Soundness): We will prove the contrapositive “ADP for $(\mathbf{h},\ell)$ accepts $\witn$ $\Rightarrow \mathbf{h}\cdot\witn = \ell$.” Let: \begin{align} \aadp_\mathsf{vss}(\witn) = \eval_0\left(\det\left(-\ell \R + \sum_{i\in[n]} w_i h_i \R\right)\right) \end{align} denote the AADP for the VSS instance $(\mathbf{h},\ell)$. Suppose, this ADP accepts $\witn$; i.e.: \(\begin{align} 1 &= \aadp_\mathsf{vss}(\witn) \Leftrightarrow \\ 0 &= \det\left(-\ell \R + \sum_{i\in[n]} w_i h_i \R\right) \\ &= \det\left(\left(\sum_{i=1}^n w_i h_i - \ell\right) \R\right)\\ &= \det\left(\left(\mathbf{h} \cdot w - \ell\right) \R\right)\\ &= \left(\mathbf{h} \cdot w - \ell\right)^k \cdot \det\left(\R\right) \end{align}\)

This is a product of two terms. It equals zero iff at least one factor is zero:

1. $\det(\R) = 0$
2. $s^k = 0 \iff s = 0 \iff \mathbf{h} \cdot \witn = \ell$ over $\Fq$ $\iff \mathbf{h} \cdot \witn = \ell$ over $\Z$ (by our choice of $q$).

Since the soundness assumption is $\mathbf{h} \cdot \witn \neq \ell$, case 2 is ruled out. So the ADP can only accept if $\det(\R) = 0$, which happens with probability at most $k/q$. $\blacksquare$

Arithmetic ADPs (AADPs)

Soukhanov et al.³ generalize ADPs to arithmetic ADPs (AADPs):

defined from the same $k\times k$ matrices as before, except:

• restricted to using $\eval_0$ as its evaluation function, slightly redefined to now take an $\Fbar$, rather than an $\F$, input
• it now takes non-zero inputs $\x\in\Fbar$ i.e.,: \begin{align} \aadp(\x) = \eval_0\left(\det{\left(\A + \sum_{i\in[n]} x_i \B_i\right)}\right),\forall \x \ne \vec{0} \end{align} where $\term{\Fbar}$ denotes the algebraic closure of $\F$ (i.e., all field extensions $\F_{q^k}$ for all $k$).

Observations:

1. The restriction to $\eval_0$ is artificial: AFAICT, it’s just because it suffices for the WE use-case
2. $\F$ is cryptographically large (e.g., 256-bits)
3. The determinant defines a polynomial over $\F$, that can be evaluated by the adversary maliciously with inputs from $\Fbar$ in order to break the encryption. This is why the definition requires the input to be from an algebraic closure.

Appendix: Probability of sampling a singular matrix over $\Fq$

The proof above relies on the fact that a uniformly-random $k\times k$ matrix $\R$ over $\Fq$ is singular (i.e., square and non-invertible) with negligible probability. This follows from a classical result on the general linear group $\text{GL}(k, \Fq)$, i.e., the group of all invertible $k\times k$ matrices over $\Fq$.

Counting invertible matrices. To build an invertible $k\times k$ matrix over $\Fq$, we choose its rows one at a time, each of which must be linearly independent of the previous ones, leading to full-rank invertible matrix:

• Row 1 can be any nonzero vector
  • There are $q^k$ possible size-$k$ vectors
  • Only one of them is the zero vector, which we want to avoid since it would trivially be in the span of any other row $\Rightarrow$ would not be full rank
  • $\Rightarrow q^k - 1$ possible vectors for row 1
• Row 2 can be any vector outside the span of row 1:
  • So we must exclude the span of row 1, denoted by $\mathbf{r}_1$: i.e., exclude $\span(\mathbf{r}_1) = \{ c \cdot \mathbf{r}_1, \forall c \in \Fq\}$
    • This excludes the zero-vector, since $c$ can be zero.
  • The size of $\span(\mathbf{r}_1)$ is $q$, since $c \in \Fq$ and $\mathbf{r}_1$ is fixed.
  • $\Rightarrow q^k - q$ possible vectors for row 2
• Row 3 can be any vector outside the span of rows 1–2:
  • So we must exclude $\span(\mathbf{r}_1, \mathbf{r}_2) = \{ c_1 \cdot \mathbf{r}_1 + c_2 \cdot \mathbf{r}_2, \forall c_1, c_2 \in \Fq\}$
  • $\mathbf{r}_1$ and $\mathbf{r}_2$ are linearly independent $\Rightarrow$ every pair $(c_1, c_2)$ gives a distinct vector $\Rightarrow \sizeof{\span(\mathbf{r}_1, \mathbf{r}_2)} = q^2$.
  • $\Rightarrow q^k - q^2$ possible vectors for row 3
    $\vdots\hspace{5em}\vdots\hspace{5em}\vdots\hspace{5em}\vdots\hspace{5em}\vdots\hspace{5em}\vdots$
• Row $k$ can be any vector outside the span of the first $k-1$ rows: $q^k - q^{k-1}$ choices.

So the number of invertible matrices is:

Probability of non-singularity. Since the total number of $k\times k$ matrices over $\Fq$ is $q^{k^2}$, the probability that a uniformly-random matrix is invertible is:

\begin{align} \Pr[\det(\R) \neq 0] &= \frac{|\text{GL}(k, \Fq)|}{q^{k^2}}\\
&= \frac{\prod_{i=0}^{k-1}(q^k - q^i)}{q^{k^2}}\\
&= \frac{\prod_{i=0}^{k-1}(q^k - q^i)}{(q^k)^k} = \frac{\prod_{i=0}^{k-1}(q^k - q^i)}{\prod_{i=0}^{k-1} q^k}\\
&= \prod_{i=0}^{k-1} \frac{q^k - q^i}{q^k}\\
&= \prod_{i=0}^{k-1} \left(1 - \frac{q^i}{q^k}\right)\\
&= \prod_{i=0}^{k-1} \left(1 - q^{i-k}\right) \end{align}

Lower bound. For all $i\in[0,k)$, we have $1 - q^{i-k} \geq 1 - q^{-1} = 1 - 1/q$. (This is equivalent to $-q^{i-k} \geq - q^{-1} \Leftrightarrow q^{i-k} \leq q^{-1} \Leftrightarrow i - k \leq -1 \Leftrightarrow i \leq k - 1$, which is true from the premise that $i\in[0,k)$.)

Thus:

Equivalently, the probability of singularity is:

\begin{align} \Pr[\det(\R) = 0] &= 1 - \Pr[\det(\R) \neq 0]\\
&\leq 1 - \left(1 - \frac{1}{q}\right)^k\\
&\leq 1 - \left(1 - \frac{k}{q}\right)\\
&= \frac{k}{q} \end{align} where the last inequality applies Bernoulli’s inequality $(1-x)^k \geq 1 - kx$ for $x \in [0, 1]$ and $k \geq 1$.

$x$ here is $1/q$. Put differently, we’re applying this to $\left(1-\frac{1}{q}\right)^k \ge 1 - \frac{k}{q}\Leftrightarrow - \left(1-\frac{1}{q}\right)^k \le -\left(1-\frac{k}{q}\right)$.

For cryptographic $q$ (e.g., $q \approx 2^{256}$) and any reasonable $k$, this is negligibly small.

References

For cited works, see below 👇👇

A history

In 2001, Vandersypen et al. claimed an “experimental realization” of Shor’s quantum factoring algorithm¹. Their results demonstrate feasibility of building very small, highly specialized quantum circuits. Specifically, they show a quantum circuit tailored for factoring 15, but in designing this circuit they leveraged knowledge of its factorizaton (i.e., $3\times5 = 15$). Naturally, the relevance of these results has been questioned, most notably by Smolin et al.² who write:

While there is no objection to having a classical compiler help design a quantum circuit (indeed, probably all quantum computers will function in this way), it is not legitimate for a compiler to know the answer to the problem being solved. To even call such a procedure compilation is an abuse of language.

Others, have been less gentle and mocked this kind of “experimental realization”³.

There might’ve been full runs that factor 15 after.

Google’s results: Willow, error-correction, new ECDLP algorithm. Oratomic’s result. This result⁴. Craig Gidney’s post and his past paper on Shor.

Some interesting readings

• Lecture 14: Skepticism of quantum computing, Scott Aaronson, Fall 2006
• Reasons to believe II: quantum edition, Scott Aaronson, September 8th, 2006
• Mistake of the Week: “X works on paper, but not in the real world”, Scott Aaronson, October 26th, 2006
  • Scott does away with the well-known “in theory, theres no difference between theory and practice; in practice, there is.” quote, saying “In theory, there’s no difference between theory and practice even in practice.” (Otherwise, the theory is wrong and thus no longer a theory.)
• NSA and IETF: Can an attacker simply purchase standardization of weakened cryptography, Daniel J. Bernstein, October 2025
• Factoring is not a good benchmark to track Q-day, Bas Westerbaan, April 2nd, 2026
• Bitcoin and Quantum Computing, Neha Narula, April 3rd, 2026

Blockchain space responses (chronological)

• March 2nd, 2022: Algorand announced future support for state proofs using Falcon digital signatures
• September 7th, 2022: Algorand Protocol Upgrade Introduces State Proofs for Trustless Cross Chain Communication and 5x Faster Performance, by Algorand
• October 15th, 2025: EIP-8051: Precompile for ML-DSA signature verification, by Renaud Dubois and Simon Masson
• November 3rd, 2025: Technical Brief: Quantum-resistant transactions on Algorand with Falcon signatures, by Larkin Young
• December 9th, 2025: AIP-137: Post-quantum Aptos accounts via SLH-DSA-SHA2-128s signatures, by Alin Tomescu
• January 14th, 2026: Announcing Project Eleven’s Series A, by Project 11
  • Mentions a Solana testnet with ML-DSA support
• February 1st, 2026: PR for “SIMD-0461: enabling falcon signature verification as a precompile”, by zz-sol

TODOs

• The threshold theorem and the reasonableness of its assumptions
• What do we know about CRQC’s ability to break hash functions? e.g., BHT, Grover search. Is there a proof that you cannot do better asymptotically?
  • What do we know about quantum algorithms that attack the structure of the hash function, rather than the idealized hash function?
• There are many different approaches to building QCs. What are the universal metrics that we should be looking for to judge them?(# of “stable” logical qubits is a popular one, but deeply inadequate)

References

For cited works, see below 👇👇