From 86b03585fccd0b758e0603f9414a9523961f4d44 Mon Sep 17 00:00:00 2001 From: Alan Szepieniec Date: Wed, 31 May 2023 22:31:39 +0200 Subject: [PATCH 1/5] add stub for tip7 --- tips/tip-0007/tip-0007.md | 64 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 tips/tip-0007/tip-0007.md diff --git a/tips/tip-0007/tip-0007.md b/tips/tip-0007/tip-0007.md new file mode 100644 index 000000000..fafedcf32 --- /dev/null +++ b/tips/tip-0007/tip-0007.md @@ -0,0 +1,64 @@ +# TIP 0007: Run-Time Permutation Check + +| TIP | 0007 | +|:---------------|:--------------------------------------------------| +| authors: | Alan Szepieniec and Ferdinand Sauer | +| title: | Run-Time Permutation Check | +| status: | draft | +| created: | 2023-05-31 | +| issue tracker: | | +| pdf: | [tip-0007.pdf](tip-0007.pdf) | + +**Abstract.** +This note describes an architectural change to Triton VM that allows programs to check at run-time whether two lists are equal up to permutation. It requires 0 extra base columns, 1 extra extension column, and 3 extra instructions. + +## Introduction + +In blockchain programming especially, one often needs to assert that two lists are equal up to permutation. For instance, a natural way to engineer privacy is to show in zero knowledge that one list of commitments is equivalent to another list of commitments up to a secret shuffle and re-randomization. + +A standard solution to this problem is to sort the lists and then test for equality. It costs $O(N \log N)$ operations to sort, and another $O(N)$ to compare. We can do much better in a STARK VM by using non-determinism. + +## Construction + +This note proposes 3 new instructions: `push_perm`, `pop_perm`, and `assert_perm`. The first two instructions push data items to and pop them back from a data structure that is neither a stack (first-in-last-out) nor a queue (first-in-first-out) but somewhere in between. *The items that go in, come out in a nondeterministic order.* One could call this a *stueue* both because it is a portmanteau and because it captures intuition of mixing. + +Specifically: + + - `push_perm` takes the top 5 elements of the stack, computes the inner product $p$ with a vector of Fiat-Shamir weights, and multiplies the product $(\alpha - p)$ into a running product column. + - `pop_perm` takes the top 5 elements of the stack, computes the inner product $p$ with the same vector of Fiat-Shamir weights, and divides the product $(\alpha - p)$ out of the running product column. + - `assert_perm` asserts that the running product column in the given row equals 1. + +In this expression, the inner product is $p = \sum_{i=0}^4 \mathtt{st}_i \cdot a_i$ and $\alpha$ is another Fiat-Shamir challenge used as indeterminate for evaluating the permutation check. + +The initial condition, as well as the terminal condition, of the running product column `permrp` stipulate that it is one. Furthermore, the following instruction-specific constraints limit its evolution: + + - If the current instruction is `push_perm`, multiply the offset inner product in: `permrp* - permrp ​⋅ (p - α)`. + - If the current instruction is `pop_perm`, divide the offset inner product out: `permrp* ​⋅ (p - α) - permrp`. + - If the current instruction is `assert_perm`, equate the running product to one: `permrp - 1`. + - If the current instruction is neither `push_perm` nor `pop_perm`, the running product does not change: `permrp* - permrp`. + +## Use + +To use the run-time permutation check to assert that two lists, A and B are the same, the program specifies as follows. First, iterate over all the elements of A, hash them, and apply `push_perm`. Next, iterate over all elements of B, hash them, and apply `pop_perm`. Then assert the two lists are permutations of one another by invoking `assert_perm`. + +The cost of this task is $O(N)$. Note that at no point is any list being sorted. In particular, the host that computes the correct guess in order for that value nondeterminstically divined by the guest does not even need to sort. + +## Alternatives + +While brainstorming we considered some alternative approaches. We decided against them in light of the attached critiques. + +### 1. Hash-Accumulator + +Without changing the VM, the program can hash all the elements of both lists, sum the hashes of each list together, and then compare these sums-of-hashes. The intuition for security is that finding a pair of lists whose sums-of-hashes are equal should be hard for a secure hash function. This task generalizes one-wayness. + +Unfortunately, it is also significantly easier than finding preimages (breaking one-wayness). Let's analyze the following attack strategy. + + - Maintain a list of preimages $P$ starting with $2N-1$ random preimages. + - In each iteration, sample a new random preimage $p$ and compute its hash $d = H(p)$. + - For each selection of one list of length $N$ and one list of length $N-1$, extend the second list with $d$ and check if the sums-of-hashes match. If yes, win and quit. If not, add $p$ to the expanding list. + +How big does the list have to be before the probability of halting in the next iteration is significant? Suppose the list contains $Q$ elements. There are ${Q \choose N}$ ways to select the first list. The sum-of-hashes for each such list is fixed and distinct from that of all others by assumption (since otherwise we would have terminated already). There are ${Q-N \choose N-1}$ ways to select the second list. The sum-of-hashes for each such list is fixed and distinct from that of all others by the same assumption. The probability that the element $p$ with hash $d$ makes the sums-of-hashes of two given such lists is $2^{-\lambda}$. But this event is not independent for different pairs of lists because their *difference* might be the same even though their individual sums are different. Nevertheless we can ignore the contribution from the second list and count $p$ as independent for each different *first* list only. + +By this logic, the probability of success is at least ${Q \choose N} \cdot 2^{-\lambda}$. + +### 2. Ad-Hoc Fiat-Shamir \ No newline at end of file From bd3d84e750875b442a9cd20317d5b3fd8c02b895 Mon Sep 17 00:00:00 2001 From: Jan Ferdinand Sauer Date: Thu, 1 Jun 2023 08:04:27 +0200 Subject: [PATCH 2/5] link to correct issue --- tips/tip-0007/tip-0007.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tips/tip-0007/tip-0007.md b/tips/tip-0007/tip-0007.md index fafedcf32..a716ac57d 100644 --- a/tips/tip-0007/tip-0007.md +++ b/tips/tip-0007/tip-0007.md @@ -1,13 +1,13 @@ # TIP 0007: Run-Time Permutation Check -| TIP | 0007 | -|:---------------|:--------------------------------------------------| -| authors: | Alan Szepieniec and Ferdinand Sauer | -| title: | Run-Time Permutation Check | -| status: | draft | -| created: | 2023-05-31 | -| issue tracker: | | -| pdf: | [tip-0007.pdf](tip-0007.pdf) | +| TIP | 0007 | +|:---------------|:---------------------------------------------------| +| authors: | Alan Szepieniec and Ferdinand Sauer | +| title: | Run-Time Permutation Check | +| status: | draft | +| created: | 2023-05-31 | +| issue tracker: | | +| pdf: | [tip-0007.pdf](tip-0007.pdf) | **Abstract.** This note describes an architectural change to Triton VM that allows programs to check at run-time whether two lists are equal up to permutation. It requires 0 extra base columns, 1 extra extension column, and 3 extra instructions. @@ -61,4 +61,4 @@ How big does the list have to be before the probability of halting in the next i By this logic, the probability of success is at least ${Q \choose N} \cdot 2^{-\lambda}$. -### 2. Ad-Hoc Fiat-Shamir \ No newline at end of file +### 2. Ad-Hoc Fiat-Shamir From 8cb8408b1360ab9001824c941925b57d59490dca Mon Sep 17 00:00:00 2001 From: Alan Szepieniec Date: Thu, 1 Jun 2023 09:37:21 +0200 Subject: [PATCH 3/5] clarify criticism of hash accumulator --- tips/tip-0007/tip-0007.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tips/tip-0007/tip-0007.md b/tips/tip-0007/tip-0007.md index a716ac57d..81619b508 100644 --- a/tips/tip-0007/tip-0007.md +++ b/tips/tip-0007/tip-0007.md @@ -59,6 +59,7 @@ Unfortunately, it is also significantly easier than finding preimages (breaking How big does the list have to be before the probability of halting in the next iteration is significant? Suppose the list contains $Q$ elements. There are ${Q \choose N}$ ways to select the first list. The sum-of-hashes for each such list is fixed and distinct from that of all others by assumption (since otherwise we would have terminated already). There are ${Q-N \choose N-1}$ ways to select the second list. The sum-of-hashes for each such list is fixed and distinct from that of all others by the same assumption. The probability that the element $p$ with hash $d$ makes the sums-of-hashes of two given such lists is $2^{-\lambda}$. But this event is not independent for different pairs of lists because their *difference* might be the same even though their individual sums are different. Nevertheless we can ignore the contribution from the second list and count $p$ as independent for each different *first* list only. -By this logic, the probability of success is at least ${Q \choose N} \cdot 2^{-\lambda}$. +By this logic, the probability of success is at least ${Q \choose N} \cdot 2^{-\lambda}$, which is already far greater than 1 if $Q = 2N = 200$. This analysis ignores the complexity of running through every combination of lists, but the point is that this complexity captures a specific attack whereas the success probability expressed in terms of $Q$ applies to every possible attack. In other words, we cannot rule out the existence of feasible attacks that take only $200$ hash queries. ### 2. Ad-Hoc Fiat-Shamir + From afdeff70faaa7c225c15e44e1d936092944e6133 Mon Sep 17 00:00:00 2001 From: Alan Szepieniec Date: Thu, 1 Jun 2023 09:46:14 +0200 Subject: [PATCH 4/5] add description of ad hoc fiat shamir --- tips/tip-0007/tip-0007.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tips/tip-0007/tip-0007.md b/tips/tip-0007/tip-0007.md index 81619b508..a78506fd5 100644 --- a/tips/tip-0007/tip-0007.md +++ b/tips/tip-0007/tip-0007.md @@ -63,3 +63,8 @@ By this logic, the probability of success is at least ${Q \choose N} \cdot 2^{-\ ### 2. Ad-Hoc Fiat-Shamir +This trick is due to Jeremy Bruestle. Hash list A, then hash list B, and then hash the concatenation of these digests. Use the resulting digest $X$ as the indeterminate for a permutation check: $\prod (a_i - X) \stackrel{?}{=} \prod (b_i - X)$. + +This works for the same reason Fiat-Shamir works: the attacker cannot predict the indeterminate ahead of time. Finding a pair of unequal lists that pass this check corresponds to finding a preimage giving a suitable digest. + +The downside of this approach is that it requires two passes over each list -- one for hashing, and the other for computing the running product. \ No newline at end of file From 3d83b8abb0c83dd34510b95e1d2e307fb7ec183e Mon Sep 17 00:00:00 2001 From: Alan Szepieniec Date: Thu, 1 Jun 2023 09:55:49 +0200 Subject: [PATCH 5/5] remove reference to pdf --- tips/Makefile | 11 ----------- tips/tip-0007/tip-0007.md | 1 - 2 files changed, 12 deletions(-) delete mode 100644 tips/Makefile diff --git a/tips/Makefile b/tips/Makefile deleted file mode 100644 index a555a808c..000000000 --- a/tips/Makefile +++ /dev/null @@ -1,11 +0,0 @@ - -SOURCES := $(wildcard tip*/tip-*.md) -KERNELS := $(SOURCES:%.md=%) - -pdfs: ${KERNELS} - @echo "" - -%: - pandoc -o $@.pdf $@.md - - diff --git a/tips/tip-0007/tip-0007.md b/tips/tip-0007/tip-0007.md index a78506fd5..9c0b48969 100644 --- a/tips/tip-0007/tip-0007.md +++ b/tips/tip-0007/tip-0007.md @@ -7,7 +7,6 @@ | status: | draft | | created: | 2023-05-31 | | issue tracker: | | -| pdf: | [tip-0007.pdf](tip-0007.pdf) | **Abstract.** This note describes an architectural change to Triton VM that allows programs to check at run-time whether two lists are equal up to permutation. It requires 0 extra base columns, 1 extra extension column, and 3 extra instructions.