From e45db0dd6cb3b114effc50f8d7e123ba0fdee5e2 Mon Sep 17 00:00:00 2001 From: Keyvan Kambakhsh Date: Sat, 17 Feb 2024 16:34:19 +0330 Subject: [PATCH] Updates --- asset-manifest.json | 18 +++++++++--------- index.html | 2 +- static/js/473.69f68b34.chunk.js | 2 -- static/js/473.69f68b34.chunk.js.map | 1 - static/js/473.bfa47c0b.chunk.js | 2 ++ static/js/473.bfa47c0b.chunk.js.map | 1 + static/js/582.0531253f.chunk.js | 2 ++ static/js/582.0531253f.chunk.js.map | 1 + static/js/582.e02d7c8a.chunk.js | 2 -- static/js/582.e02d7c8a.chunk.js.map | 1 - .../js/{main.4823e245.js => main.469bae70.js} | 6 +++--- ...ICENSE.txt => main.469bae70.js.LICENSE.txt} | 0 ...in.4823e245.js.map => main.469bae70.js.map} | 2 +- ...4f9e88.md => 2-kzg.67b5d95fa384abb59cc5.md} | 2 +- ...c1914.md => 3-ppob.111af7d95f19db93cf84.md} | 2 +- 15 files changed, 22 insertions(+), 22 deletions(-) delete mode 100644 static/js/473.69f68b34.chunk.js delete mode 100644 static/js/473.69f68b34.chunk.js.map create mode 100644 static/js/473.bfa47c0b.chunk.js create mode 100644 static/js/473.bfa47c0b.chunk.js.map create mode 100644 static/js/582.0531253f.chunk.js create mode 100644 static/js/582.0531253f.chunk.js.map delete mode 100644 static/js/582.e02d7c8a.chunk.js delete mode 100644 static/js/582.e02d7c8a.chunk.js.map rename static/js/{main.4823e245.js => main.469bae70.js} (88%) rename static/js/{main.4823e245.js.LICENSE.txt => main.469bae70.js.LICENSE.txt} (100%) rename static/js/{main.4823e245.js.map => main.469bae70.js.map} (99%) rename static/media/{2-kzg.7190b11ce7c9914f9e88.md => 2-kzg.67b5d95fa384abb59cc5.md} (94%) rename static/media/{3-ppob.8e0a435f618b66cc1914.md => 3-ppob.111af7d95f19db93cf84.md} (95%) diff --git a/asset-manifest.json b/asset-manifest.json index 628b234..b552c56 100644 --- a/asset-manifest.json +++ b/asset-manifest.json @@ -1,27 +1,27 @@ { "files": { "main.css": "/static/css/main.e9a5b9d4.css", - "main.js": "/static/js/main.4823e245.js", + "main.js": "/static/js/main.469bae70.js", "static/js/590.0c3dee20.chunk.js": "/static/js/590.0c3dee20.chunk.js", - "static/js/473.69f68b34.chunk.js": "/static/js/473.69f68b34.chunk.js", - "static/js/582.e02d7c8a.chunk.js": "/static/js/582.e02d7c8a.chunk.js", + "static/js/473.bfa47c0b.chunk.js": "/static/js/473.bfa47c0b.chunk.js", + "static/js/582.0531253f.chunk.js": "/static/js/582.0531253f.chunk.js", "static/js/620.8cd95ce2.chunk.js": "/static/js/620.8cd95ce2.chunk.js", "static/js/787.089ea9af.chunk.js": "/static/js/787.089ea9af.chunk.js", "static/media/1-study.md": "/static/media/1-study.dc7bc27a551356bc6e8e.md", - "static/media/3-ppob.md": "/static/media/3-ppob.8e0a435f618b66cc1914.md", - "static/media/2-kzg.md": "/static/media/2-kzg.7190b11ce7c9914f9e88.md", + "static/media/3-ppob.md": "/static/media/3-ppob.111af7d95f19db93cf84.md", + "static/media/2-kzg.md": "/static/media/2-kzg.67b5d95fa384abb59cc5.md", "static/media/4-stealth.md": "/static/media/4-stealth.1fd0d6f1e0ca414be048.md", "index.html": "/index.html", "main.e9a5b9d4.css.map": "/static/css/main.e9a5b9d4.css.map", - "main.4823e245.js.map": "/static/js/main.4823e245.js.map", + "main.469bae70.js.map": "/static/js/main.469bae70.js.map", "590.0c3dee20.chunk.js.map": "/static/js/590.0c3dee20.chunk.js.map", - "473.69f68b34.chunk.js.map": "/static/js/473.69f68b34.chunk.js.map", - "582.e02d7c8a.chunk.js.map": "/static/js/582.e02d7c8a.chunk.js.map", + "473.bfa47c0b.chunk.js.map": "/static/js/473.bfa47c0b.chunk.js.map", + "582.0531253f.chunk.js.map": "/static/js/582.0531253f.chunk.js.map", "620.8cd95ce2.chunk.js.map": "/static/js/620.8cd95ce2.chunk.js.map", "787.089ea9af.chunk.js.map": "/static/js/787.089ea9af.chunk.js.map" }, "entrypoints": [ "static/css/main.e9a5b9d4.css", - "static/js/main.4823e245.js" + "static/js/main.469bae70.js" ] } \ No newline at end of file diff --git a/index.html b/index.html index 37d1930..bdf9153 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ -Nobitex Labs - Blockchain Research Laboratory
\ No newline at end of file +Nobitex Labs - Blockchain Research Laboratory
\ No newline at end of file diff --git a/static/js/473.69f68b34.chunk.js b/static/js/473.69f68b34.chunk.js deleted file mode 100644 index f8c12c1..0000000 --- a/static/js/473.69f68b34.chunk.js +++ /dev/null @@ -1,2 +0,0 @@ -"use strict";(self.webpackChunktext_md_genrator=self.webpackChunktext_md_genrator||[]).push([[473],{473:function(e,o,t){t.r(o);o.default="

title: KZG Polynomial Commitments description: While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset. category: ["General Cryptography", "Zero-Knowledge Proofs"] date : 24 Oct 2023

KZG Polynomial Commitments

Imagine we want to commit to a vector of secret values, and later we want to make proofs that certain values exist in that list, without revealing the entire list.

Most naive implementation of such a tool is a merkle tree. With a merkle tree you can commit to 2^n values and make proofs of size log(2^n)=n. (Proof size: O(log(n)))

A KZG commitment is a cryptographic tool which can generate proofs for a list of values with O(1) proof sizes.

Math

Imagine our list is [2, 0, 6].

We can represent this list as a polynomial $P(x)$ where $P(1) = 2$, $P(2) = 0$ and $P(3) = 6$. You can find such polynomials for arbitrary lists using an algorithm called Polynomial Interpolation.

For the mentioned list, the polynomial will be: $P(x) = 4x^2-14x+12$.

Fact: Value $v$ exists at index $k$ of polynomial commitment $P(x)$ if and only if there exists a polynomial $Q(x)$ where: $Q(x).(x-k) = P(x) - v$. It can be computed by doing a polynomial division: $Q(x)=\\frac{P(x)-v}{x-k}$

Now imagine we choose a random value $\\tau$ and commit to the list by calculating $c=P(\\tau)$. (Commitment will be a number)

Note: You can compute $Q(\\tau)$ only when you know $Q(x)$.

Therefore the proof will be $\\pi=Q(\\tau)$. Verifier can check the proof by checking if: $\\pi.(\\tau - k) = c - v$

This protocol can be easily hacked since it works with numbers. We can easily calculate a fake proof by calculating $\\pi = \\frac{c - v}{\\tau - k}$.

Switching to elliptic curve points

Instead of using numbers, we can use elliptic curve points.

The commitment will be $c=g^{P(\\tau)}$.

The proof will be $\\pi=g^{Q(\\tau)}$

The verification check will be: $g^{Q(\\tau).(\\tau - k)} = g^{P(\\tau) - v}$, which in other words is: $\\pi^{\\tau - k}.g^v=c$

(Notice that one can't easily calculate \\pi because of the discrete logarithm problem on elliptic curves)

The verification check can also be done by a elliptic curve pairing function.

(Pairing function: $e(g^a, g^b) = G^{ab}$)

Check: $e(\\frac{c}{g^v}, g) = e(\\pi, \\frac{g^\\tau}{g^k})$

Question: how can we do elliptic curve division here?

Possible Answer: Maybe the prover is also giving $\\frac{c}{g^v}$ and $\\frac{g^\\tau}{g^k}$ as part of the proof (The prover can calculate those values). Verifier can check their correctness by checking if:

$\\frac{c}{g^v}.g^v = c$ and $\\frac{g^\\tau}{g^k}.g^k=g^\\tau$

"}}]); -//# sourceMappingURL=473.69f68b34.chunk.js.map \ No newline at end of file diff --git a/static/js/473.69f68b34.chunk.js.map b/static/js/473.69f68b34.chunk.js.map deleted file mode 100644 index 9f81e12..0000000 --- a/static/js/473.69f68b34.chunk.js.map +++ /dev/null @@ -1 +0,0 @@ -{"version":3,"file":"static/js/473.69f68b34.chunk.js","mappings":"+HAGA,UAFW,89F","sources":["content/2-kzg.html"],"sourcesContent":["// Module\nvar code = \"

title: KZG Polynomial Commitments description: While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset. category: ["General Cryptography", "Zero-Knowledge Proofs"] date : 24 Oct 2023

KZG Polynomial Commitments

Imagine we want to commit to a vector of secret values, and later we want to make proofs that certain values exist in that list, without revealing the entire list.

Most naive implementation of such a tool is a merkle tree. With a merkle tree you can commit to 2^n values and make proofs of size log(2^n)=n. (Proof size: O(log(n)))

A KZG commitment is a cryptographic tool which can generate proofs for a list of values with O(1) proof sizes.

Math

Imagine our list is [2, 0, 6].

We can represent this list as a polynomial $P(x)$ where $P(1) = 2$, $P(2) = 0$ and $P(3) = 6$. You can find such polynomials for arbitrary lists using an algorithm called Polynomial Interpolation.

For the mentioned list, the polynomial will be: $P(x) = 4x^2-14x+12$.

Fact: Value $v$ exists at index $k$ of polynomial commitment $P(x)$ if and only if there exists a polynomial $Q(x)$ where: $Q(x).(x-k) = P(x) - v$. It can be computed by doing a polynomial division: $Q(x)=\\\\frac{P(x)-v}{x-k}$

Now imagine we choose a random value $\\\\tau$ and commit to the list by calculating $c=P(\\\\tau)$. (Commitment will be a number)

Note: You can compute $Q(\\\\tau)$ only when you know $Q(x)$.

Therefore the proof will be $\\\\pi=Q(\\\\tau)$. Verifier can check the proof by checking if: $\\\\pi.(\\\\tau - k) = c - v$

This protocol can be easily hacked since it works with numbers. We can easily calculate a fake proof by calculating $\\\\pi = \\\\frac{c - v}{\\\\tau - k}$.

Switching to elliptic curve points

Instead of using numbers, we can use elliptic curve points.

The commitment will be $c=g^{P(\\\\tau)}$.

The proof will be $\\\\pi=g^{Q(\\\\tau)}$

The verification check will be: $g^{Q(\\\\tau).(\\\\tau - k)} = g^{P(\\\\tau) - v}$, which in other words is: $\\\\pi^{\\\\tau - k}.g^v=c$

(Notice that one can't easily calculate \\\\pi because of the discrete logarithm problem on elliptic curves)

The verification check can also be done by a elliptic curve pairing function.

(Pairing function: $e(g^a, g^b) = G^{ab}$)

Check: $e(\\\\frac{c}{g^v}, g) = e(\\\\pi, \\\\frac{g^\\\\tau}{g^k})$

Question: how can we do elliptic curve division here?

Possible Answer: Maybe the prover is also giving $\\\\frac{c}{g^v}$ and $\\\\frac{g^\\\\tau}{g^k}$ as part of the proof (The prover can calculate those values). Verifier can check their correctness by checking if:

$\\\\frac{c}{g^v}.g^v = c$ and $\\\\frac{g^\\\\tau}{g^k}.g^k=g^\\\\tau$

\";\n// Exports\nexport default code;"],"names":[],"sourceRoot":""} \ No newline at end of file diff --git a/static/js/473.bfa47c0b.chunk.js b/static/js/473.bfa47c0b.chunk.js new file mode 100644 index 0000000..e6e56a0 --- /dev/null +++ b/static/js/473.bfa47c0b.chunk.js @@ -0,0 +1,2 @@ +"use strict";(self.webpackChunktext_md_genrator=self.webpackChunktext_md_genrator||[]).push([[473],{473:function(e,t,o){o.r(t);t.default="

title: KZG Polynomial Commitments description: Polynomical commitments are alternatives to merkle trees. category: ["General Cryptography", "Zero-Knowledge Proofs"] date : 24 Oct 2023

KZG Polynomial Commitments

Imagine we want to commit to a vector of secret values, and later we want to make proofs that certain values exist in that list, without revealing the entire list.

Most naive implementation of such a tool is a merkle tree. With a merkle tree you can commit to 2^n values and make proofs of size log(2^n)=n. (Proof size: O(log(n)))

A KZG commitment is a cryptographic tool which can generate proofs for a list of values with O(1) proof sizes.

Math

Imagine our list is [2, 0, 6].

We can represent this list as a polynomial $P(x)$ where $P(1) = 2$, $P(2) = 0$ and $P(3) = 6$. You can find such polynomials for arbitrary lists using an algorithm called Polynomial Interpolation.

For the mentioned list, the polynomial will be: $P(x) = 4x^2-14x+12$.

Fact: Value $v$ exists at index $k$ of polynomial commitment $P(x)$ if and only if there exists a polynomial $Q(x)$ where: $Q(x).(x-k) = P(x) - v$. It can be computed by doing a polynomial division: $Q(x)=\\frac{P(x)-v}{x-k}$

Now imagine we choose a random value $\\tau$ and commit to the list by calculating $c=P(\\tau)$. (Commitment will be a number)

Note: You can compute $Q(\\tau)$ only when you know $Q(x)$.

Therefore the proof will be $\\pi=Q(\\tau)$. Verifier can check the proof by checking if: $\\pi.(\\tau - k) = c - v$

This protocol can be easily hacked since it works with numbers. We can easily calculate a fake proof by calculating $\\pi = \\frac{c - v}{\\tau - k}$.

Switching to elliptic curve points

Instead of using numbers, we can use elliptic curve points.

The commitment will be $c=g^{P(\\tau)}$.

The proof will be $\\pi=g^{Q(\\tau)}$

The verification check will be: $g^{Q(\\tau).(\\tau - k)} = g^{P(\\tau) - v}$, which in other words is: $\\pi^{\\tau - k}.g^v=c$

(Notice that one can't easily calculate \\pi because of the discrete logarithm problem on elliptic curves)

The verification check can also be done by a elliptic curve pairing function.

(Pairing function: $e(g^a, g^b) = G^{ab}$)

Check: $e(\\frac{c}{g^v}, g) = e(\\pi, \\frac{g^\\tau}{g^k})$

Question: how can we do elliptic curve division here?

Possible Answer: Maybe the prover is also giving $\\frac{c}{g^v}$ and $\\frac{g^\\tau}{g^k}$ as part of the proof (The prover can calculate those values). Verifier can check their correctness by checking if:

$\\frac{c}{g^v}.g^v = c$ and $\\frac{g^\\tau}{g^k}.g^k=g^\\tau$

"}}]); +//# sourceMappingURL=473.bfa47c0b.chunk.js.map \ No newline at end of file diff --git a/static/js/473.bfa47c0b.chunk.js.map b/static/js/473.bfa47c0b.chunk.js.map new file mode 100644 index 0000000..fc87e76 --- /dev/null +++ b/static/js/473.bfa47c0b.chunk.js.map @@ -0,0 +1 @@ +{"version":3,"file":"static/js/473.bfa47c0b.chunk.js","mappings":"+HAGA,UAFW,+4F","sources":["content/2-kzg.html"],"sourcesContent":["// Module\nvar code = \"

title: KZG Polynomial Commitments description: Polynomical commitments are alternatives to merkle trees. category: ["General Cryptography", "Zero-Knowledge Proofs"] date : 24 Oct 2023

KZG Polynomial Commitments

Imagine we want to commit to a vector of secret values, and later we want to make proofs that certain values exist in that list, without revealing the entire list.

Most naive implementation of such a tool is a merkle tree. With a merkle tree you can commit to 2^n values and make proofs of size log(2^n)=n. (Proof size: O(log(n)))

A KZG commitment is a cryptographic tool which can generate proofs for a list of values with O(1) proof sizes.

Math

Imagine our list is [2, 0, 6].

We can represent this list as a polynomial $P(x)$ where $P(1) = 2$, $P(2) = 0$ and $P(3) = 6$. You can find such polynomials for arbitrary lists using an algorithm called Polynomial Interpolation.

For the mentioned list, the polynomial will be: $P(x) = 4x^2-14x+12$.

Fact: Value $v$ exists at index $k$ of polynomial commitment $P(x)$ if and only if there exists a polynomial $Q(x)$ where: $Q(x).(x-k) = P(x) - v$. It can be computed by doing a polynomial division: $Q(x)=\\\\frac{P(x)-v}{x-k}$

Now imagine we choose a random value $\\\\tau$ and commit to the list by calculating $c=P(\\\\tau)$. (Commitment will be a number)

Note: You can compute $Q(\\\\tau)$ only when you know $Q(x)$.

Therefore the proof will be $\\\\pi=Q(\\\\tau)$. Verifier can check the proof by checking if: $\\\\pi.(\\\\tau - k) = c - v$

This protocol can be easily hacked since it works with numbers. We can easily calculate a fake proof by calculating $\\\\pi = \\\\frac{c - v}{\\\\tau - k}$.

Switching to elliptic curve points

Instead of using numbers, we can use elliptic curve points.

The commitment will be $c=g^{P(\\\\tau)}$.

The proof will be $\\\\pi=g^{Q(\\\\tau)}$

The verification check will be: $g^{Q(\\\\tau).(\\\\tau - k)} = g^{P(\\\\tau) - v}$, which in other words is: $\\\\pi^{\\\\tau - k}.g^v=c$

(Notice that one can't easily calculate \\\\pi because of the discrete logarithm problem on elliptic curves)

The verification check can also be done by a elliptic curve pairing function.

(Pairing function: $e(g^a, g^b) = G^{ab}$)

Check: $e(\\\\frac{c}{g^v}, g) = e(\\\\pi, \\\\frac{g^\\\\tau}{g^k})$

Question: how can we do elliptic curve division here?

Possible Answer: Maybe the prover is also giving $\\\\frac{c}{g^v}$ and $\\\\frac{g^\\\\tau}{g^k}$ as part of the proof (The prover can calculate those values). Verifier can check their correctness by checking if:

$\\\\frac{c}{g^v}.g^v = c$ and $\\\\frac{g^\\\\tau}{g^k}.g^k=g^\\\\tau$

\";\n// Exports\nexport default code;"],"names":[],"sourceRoot":""} \ No newline at end of file diff --git a/static/js/582.0531253f.chunk.js b/static/js/582.0531253f.chunk.js new file mode 100644 index 0000000..0b27697 --- /dev/null +++ b/static/js/582.0531253f.chunk.js @@ -0,0 +1,2 @@ +"use strict";(self.webpackChunktext_md_genrator=self.webpackChunktext_md_genrator||[]).push([[582],{582:function(e,t,n){n.r(t);t.default="

title: Private Proof of Burn description: PPoB allows a contract to know some amount of ETH has been burnt without exposing who did it. category: ["General Cryptography"] date : 24 Oct 2023

Private Proof of Burn

While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens has been burnt in a transaction in an older block, without revealing the transaction. Why is it important? People can do plain EOA-to-EOA transfers which privately have impact in some other verifier smart-contract on the system.

Recap on Elliptic-Curve digital-signatures:

In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is deriven (By multiplying the generator point with the scalar: $s \\times G$)

A public-key is spendable if and only if its corresponding private-key $s$ exists. We can generate unspendable public-keys by generating random points on the curve. But how can other people be sure that a point is indeed random and not the result of calculating $s \\times G$? We can generate points that are very unlikely to be spendable by using fancy-looking patterns in their $x$ coordinate. E.g: In case of Secp256k1 we can pick $x=123456789$ and calculate $y$ by putting it in the curve equation:

$y^2=x^3+7$

Because of the discrete logarithm problem, it's practically impossible to calculate $s$ where $s \\times G$ is equal with our point.

Let's say $R$ is an unspendable public-key (Let's call it the reference unspendable public-key). People can publicly burn their tokens by sending them to $R$, after doing so, others can indeed conclude that they have burnt their tokens, because they can all see the transactions and they know that $R$ is unspendable.

We can derive infinitely many provably-unspendable public-keys from a reference unspendable public-key

Let's pick a random secret value $t$ and calculate a new point $D=R + t \\times G$. We can prove that $D$ is also unspendable, because $log_G(D)=log_G(R + t \\times G)=log_G(R) + t$, and since we can't calculate $log_G(R)$, the public-key $D$ is also unspendable.

Obviously, $D$ is a completely new point that does not seem unspendable. We can convince others that $D$ is unspendable by revealing $t$, because then people can verify that $D$ is the result of adding some other point to $R$.

Using the help of Zero-Knowledge proofs, we can hide the value of $t$

We just need to prove that we know a secret value $t$ where $R + t \\times G == D$. We can go even further. Given that we have access to the previous block hashes in our Ethereum smart-contracts, we can prove that some EOA-to-EOA transaction has happened in the previous blocks, burning some amount of token (It actually doesn't need to be an EOA-to-EOA, and it also could be a ERC20-transfer).

"}}]); +//# sourceMappingURL=582.0531253f.chunk.js.map \ No newline at end of file diff --git a/static/js/582.0531253f.chunk.js.map b/static/js/582.0531253f.chunk.js.map new file mode 100644 index 0000000..e0b10ac --- /dev/null +++ b/static/js/582.0531253f.chunk.js.map @@ -0,0 +1 @@ +{"version":3,"file":"static/js/582.0531253f.chunk.js","mappings":"+HAGA,UAFW,skG","sources":["content/3-ppob.html"],"sourcesContent":["// Module\nvar code = \"

title: Private Proof of Burn description: PPoB allows a contract to know some amount of ETH has been burnt without exposing who did it. category: ["General Cryptography"] date : 24 Oct 2023

Private Proof of Burn

While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens has been burnt in a transaction in an older block, without revealing the transaction. Why is it important? People can do plain EOA-to-EOA transfers which privately have impact in some other verifier smart-contract on the system.

Recap on Elliptic-Curve digital-signatures:

In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is deriven (By multiplying the generator point with the scalar: $s \\\\times G$)

A public-key is spendable if and only if its corresponding private-key $s$ exists. We can generate unspendable public-keys by generating random points on the curve. But how can other people be sure that a point is indeed random and not the result of calculating $s \\\\times G$? We can generate points that are very unlikely to be spendable by using fancy-looking patterns in their $x$ coordinate. E.g: In case of Secp256k1 we can pick $x=123456789$ and calculate $y$ by putting it in the curve equation:

$y^2=x^3+7$

Because of the discrete logarithm problem, it's practically impossible to calculate $s$ where $s \\\\times G$ is equal with our point.

Let's say $R$ is an unspendable public-key (Let's call it the reference unspendable public-key). People can publicly burn their tokens by sending them to $R$, after doing so, others can indeed conclude that they have burnt their tokens, because they can all see the transactions and they know that $R$ is unspendable.

We can derive infinitely many provably-unspendable public-keys from a reference unspendable public-key

Let's pick a random secret value $t$ and calculate a new point $D=R + t \\\\times G$. We can prove that $D$ is also unspendable, because $log_G(D)=log_G(R + t \\\\times G)=log_G(R) + t$, and since we can't calculate $log_G(R)$, the public-key $D$ is also unspendable.

Obviously, $D$ is a completely new point that does not seem unspendable. We can convince others that $D$ is unspendable by revealing $t$, because then people can verify that $D$ is the result of adding some other point to $R$.

Using the help of Zero-Knowledge proofs, we can hide the value of $t$

We just need to prove that we know a secret value $t$ where $R + t \\\\times G == D$. We can go even further. Given that we have access to the previous block hashes in our Ethereum smart-contracts, we can prove that some EOA-to-EOA transaction has happened in the previous blocks, burning some amount of token (It actually doesn't need to be an EOA-to-EOA, and it also could be a ERC20-transfer).

\";\n// Exports\nexport default code;"],"names":[],"sourceRoot":""} \ No newline at end of file diff --git a/static/js/582.e02d7c8a.chunk.js b/static/js/582.e02d7c8a.chunk.js deleted file mode 100644 index cecc0e4..0000000 --- a/static/js/582.e02d7c8a.chunk.js +++ /dev/null @@ -1,2 +0,0 @@ -"use strict";(self.webpackChunktext_md_genrator=self.webpackChunktext_md_genrator||[]).push([[582],{582:function(e,t,n){n.r(t);t.default="

title: Private Proof of Burn description: While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset. category: ["General Cryptography"] date : 24 Oct 2023

Private Proof of Burn

While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens has been burnt in a transaction in an older block, without revealing the transaction. Why is it important? People can do plain EOA-to-EOA transfers which privately have impact in some other verifier smart-contract on the system.

Recap on Elliptic-Curve digital-signatures:

In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is deriven (By multiplying the generator point with the scalar: $s \\times G$)

A public-key is spendable if and only if its corresponding private-key $s$ exists. We can generate unspendable public-keys by generating random points on the curve. But how can other people be sure that a point is indeed random and not the result of calculating $s \\times G$? We can generate points that are very unlikely to be spendable by using fancy-looking patterns in their $x$ coordinate. E.g: In case of Secp256k1 we can pick $x=123456789$ and calculate $y$ by putting it in the curve equation:

$y^2=x^3+7$

Because of the discrete logarithm problem, it's practically impossible to calculate $s$ where $s \\times G$ is equal with our point.

Let's say $R$ is an unspendable public-key (Let's call it the reference unspendable public-key). People can publicly burn their tokens by sending them to $R$, after doing so, others can indeed conclude that they have burnt their tokens, because they can all see the transactions and they know that $R$ is unspendable.

We can derive infinitely many provably-unspendable public-keys from a reference unspendable public-key

Let's pick a random secret value $t$ and calculate a new point $D=R + t \\times G$. We can prove that $D$ is also unspendable, because $log_G(D)=log_G(R + t \\times G)=log_G(R) + t$, and since we can't calculate $log_G(R)$, the public-key $D$ is also unspendable.

Obviously, $D$ is a completely new point that does not seem unspendable. We can convince others that $D$ is unspendable by revealing $t$, because then people can verify that $D$ is the result of adding some other point to $R$.

Using the help of Zero-Knowledge proofs, we can hide the value of $t$

We just need to prove that we know a secret value $t$ where $R + t \\times G == D$. We can go even further. Given that we have access to the previous block hashes in our Ethereum smart-contracts, we can prove that some EOA-to-EOA transaction has happened in the previous blocks, burning some amount of token (It actually doesn't need to be an EOA-to-EOA, and it also could be a ERC20-transfer).

"}}]); -//# sourceMappingURL=582.e02d7c8a.chunk.js.map \ No newline at end of file diff --git a/static/js/582.e02d7c8a.chunk.js.map b/static/js/582.e02d7c8a.chunk.js.map deleted file mode 100644 index 9ad8d40..0000000 --- a/static/js/582.e02d7c8a.chunk.js.map +++ /dev/null @@ -1 +0,0 @@ -{"version":3,"file":"static/js/582.e02d7c8a.chunk.js","mappings":"+HAGA,UAFW,inG","sources":["content/3-ppob.html"],"sourcesContent":["// Module\nvar code = \"

title: Private Proof of Burn description: While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset. category: ["General Cryptography"] date : 24 Oct 2023

Private Proof of Burn

While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens has been burnt in a transaction in an older block, without revealing the transaction. Why is it important? People can do plain EOA-to-EOA transfers which privately have impact in some other verifier smart-contract on the system.

Recap on Elliptic-Curve digital-signatures:

In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is deriven (By multiplying the generator point with the scalar: $s \\\\times G$)

A public-key is spendable if and only if its corresponding private-key $s$ exists. We can generate unspendable public-keys by generating random points on the curve. But how can other people be sure that a point is indeed random and not the result of calculating $s \\\\times G$? We can generate points that are very unlikely to be spendable by using fancy-looking patterns in their $x$ coordinate. E.g: In case of Secp256k1 we can pick $x=123456789$ and calculate $y$ by putting it in the curve equation:

$y^2=x^3+7$

Because of the discrete logarithm problem, it's practically impossible to calculate $s$ where $s \\\\times G$ is equal with our point.

Let's say $R$ is an unspendable public-key (Let's call it the reference unspendable public-key). People can publicly burn their tokens by sending them to $R$, after doing so, others can indeed conclude that they have burnt their tokens, because they can all see the transactions and they know that $R$ is unspendable.

We can derive infinitely many provably-unspendable public-keys from a reference unspendable public-key

Let's pick a random secret value $t$ and calculate a new point $D=R + t \\\\times G$. We can prove that $D$ is also unspendable, because $log_G(D)=log_G(R + t \\\\times G)=log_G(R) + t$, and since we can't calculate $log_G(R)$, the public-key $D$ is also unspendable.

Obviously, $D$ is a completely new point that does not seem unspendable. We can convince others that $D$ is unspendable by revealing $t$, because then people can verify that $D$ is the result of adding some other point to $R$.

Using the help of Zero-Knowledge proofs, we can hide the value of $t$

We just need to prove that we know a secret value $t$ where $R + t \\\\times G == D$. We can go even further. Given that we have access to the previous block hashes in our Ethereum smart-contracts, we can prove that some EOA-to-EOA transaction has happened in the previous blocks, burning some amount of token (It actually doesn't need to be an EOA-to-EOA, and it also could be a ERC20-transfer).

\";\n// Exports\nexport default code;"],"names":[],"sourceRoot":""} \ No newline at end of file diff --git a/static/js/main.4823e245.js b/static/js/main.469bae70.js similarity index 88% rename from static/js/main.4823e245.js rename to static/js/main.469bae70.js index 238182d..4095bd1 100644 --- a/static/js/main.4823e245.js +++ b/static/js/main.469bae70.js @@ -1,3 +1,3 @@ -/*! For license information please see main.4823e245.js.LICENSE.txt */ -!function(){var e={463:function(e,t,n){"use strict";var r=n(791),a=n(296);function l(e){for(var t="https://reactjs.org/docs/error-decoder.html?invariant="+e,n=1;n