Skip to content

Commit

Permalink
deploy: fb1a309
Browse files Browse the repository at this point in the history
  • Loading branch information
@mimoo
mimoo committed Oct 17, 2024
1 parent d77ee93 commit a0d2b86
Show file tree
Hide file tree
Showing 3 changed files with 67 additions and 30 deletions.
8 changes: 4 additions & 4 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet STARK Verifier</h2>
<p class="text-gray-600">Short Name: starknet-stark</p>
<!-- <p class="text-gray-600">Editor: David Wong</p> -->
<p class="text-gray-600">State of This Document: draft</p>
<p class="text-gray-600">Updated: October 16, 2024</p>
<p class="text-gray-600">Updated: October 17, 2024</p>
<a href="rfcs/starknet/stark.html"
class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
View RFC
Expand All @@ -30,7 +30,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet FRI Verifier</h2>
<p class="text-gray-600">Short Name: starknet-fri</p>
<!-- <p class="text-gray-600">Editor: David Wong</p> -->
<p class="text-gray-600">State of This Document: draft</p>
<p class="text-gray-600">Updated: October 16, 2024</p>
<p class="text-gray-600">Updated: October 17, 2024</p>
<a href="rfcs/starknet/fri.html"
class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
View RFC
Expand All @@ -42,7 +42,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet Merkle Tree Polynomial Commitmen
<p class="text-gray-600">Short Name: starknet-commit</p>
<!-- <p class="text-gray-600">Editor: David Wong</p> -->
<p class="text-gray-600">State of This Document: draft</p>
<p class="text-gray-600">Updated: October 16, 2024</p>
<p class="text-gray-600">Updated: October 17, 2024</p>
<a href="rfcs/starknet/polynomial_commitment.html"
class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
View RFC
Expand All @@ -54,7 +54,7 @@ <h2 class="text-xl font-semibold mb-2">Starknet Channels for Fiat-Shamir Instant
<p class="text-gray-600">Short Name: starknet-channel</p>
<!-- <p class="text-gray-600">Editor: David Wong</p> -->
<p class="text-gray-600">State of This Document: draft</p>
<p class="text-gray-600">Updated: October 16, 2024</p>
<p class="text-gray-600">Updated: October 17, 2024</p>
<a href="rfcs/starknet/channel.html"
class="mt-4 inline-block bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
View RFC
Expand Down
45 changes: 32 additions & 13 deletions rfcs/starknet/channel.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -70,38 +70,57 @@

<body>
<section id="abstract">
<p>TKTK</p>
<p>Channels are an abstraction used to mimic the communication channel between the prover and the verifier in a non-interactive protocol. It is useful to ensure that all prover messages are correctly absorbed before being used by the verifier, and that all verifier challenges are correctly produced.</p>
</section>
<section id="sotd">
<p>draft</p>
</section>
<section>
<h2>Overview</h2>
<p>A channel is an object that mimics the communication channel between the prover and the verifier, and is used to abstract the <a href="">Fiat-Shamir transformation</a> used to make the protocol non-interactive (the verifier messages are replaced by sampling a hash function).</p>
<p>A channel is an object that mimics the communication channel between the prover and the verifier, and is used to abstract the <a href="https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic">Fiat-Shamir transformation</a> used to make the protocol non-interactive.</p>
<p>The Fiat-Shamir transformation works on public-coin protocols, in which the messages of the verifier are pure random values. To work, the Fiat-Shamir transformation replaces the verifier messages with a hash function applied over the transcript up to that point.</p>
<p>A channel is initialized at the beginning of the protocol, and is instantiated with a hash function. It is implemented as a continuous hash that "absorbs" every prover messages and which output can be used to produce the verifier's challenges.</p>
</section>
<section>
<h2>Dependencies</h2>
<p>A channel is instantiated with the following two dependencies:</p>
<ul>
<li><code>hades_permutation(s1, s2, s3)</code>. The hades permutation which permutates a given state of three field elements.</li>
<li><code>poseidon_hash_span(field_elements)</code>. The poseidon sponge function which hashes a list of field elements.</li>
</ul>
</section>
<section>
<h2>Interface</h2>
<p>A channel has two fields:</p>
<ul>
<li>A <strong>digest</strong>, which represents the current internal state.</li>
<li>A <strong>counter</strong>, which helps produce different values when the channel is used repeatedly to sample verifier challenges.</li>
<li>A <strong><code>digest</code></strong>, which represents the current internal state.</li>
<li>A <strong><code>counter</code></strong>, which helps produce different values when the channel is used repeatedly to sample verifier challenges.</li>
</ul>
<p>The channel has the following interface:</p>
<p><strong><code>init(digest)</code></strong>. </p>
<p><strong>Initialize</strong>. This intializes the channel in the following way: </p>
<ul>
<li>Initializes the channel with a digest, which is the prologue/context to the protocol. </li>
<li>Set the counter to <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>0</mn></mrow></math>.</li>
<li>Set the <code>digest</code> to the given <code>digest</code>, which is the prologue/context to the protocol. </li>
<li>Set the <code>counter</code> to <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>0</mn></mrow></math>.</li>
</ul>
<p><strong>message from prover to verifier</strong>.</p>
<p><strong>Absorb a message from the prover</strong>.</p>
<ul>
<li>Resets the counter to <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>0</mn></mrow></math>.</li>
<li>Set the digest to <code>POSEIDON_hash(digest + 1 || value)</code>. (TODO: what if several values)</li>
<li>Resets the <code>counter</code> to <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>0</mn></mrow></math>.</li>
<li>Set the <code>digest</code> to <code>POSEIDON_hash(digest + 1 || value)</code>.</li>
</ul>
<p>TODO: explain why the +1</p>
<p><strong>message from verifier to prover</strong>.</p>
<p><strong>Absorb multiple messages from the prover</strong>.</p>
<ul>
<li>Resets the <code>counter</code> to <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mn>0</mn></mrow></math>.</li>
<li>Set the <code>digest</code> to <code>POSEIDON_hash(digest + 1 || values)</code>.</li>
</ul>
<aside class="warning">This function is not compatible with multiple call to the previous function.</aside>

<p><strong>Produce a verifier challenge</strong>.</p>
<ul>
<li>Produce a random value as <code>hades_permutation(digest, counter, 2)</code>.</li>
<li>Increment the counter.</li>
<li>Increment the <code>counter</code>.</li>
</ul>
<aside class="note">With the current design, two different protocols where one produces <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>n</mi></mrow></math> challenges and another that produces <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>m</mi></mrow></math> challenges will have the same "transcript" and thus will continue to produce the same challenges later on in the protocol. While there are no issues in this design in the context of Starknet, this might not always be secure when used in other protocols.</aside>
<aside class="warning">With the current design, two different protocols where one produces <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>n</mi></mrow></math> challenges and another that produces <math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>m</mi></mrow></math> challenges will have the same "transcript" and thus will continue to produce the same challenges later on in the protocol. While there are no issues in this design in the context of Starknet, this might not always be secure when used in other protocols.</aside>
</section>
</body>

Expand Down
44 changes: 31 additions & 13 deletions source/starknet/channel.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "Starknet Channels for Fiat-Shamir Instantiation"
abstract: "TKTK"
abstract: "Channels are an abstraction used to mimic the communication channel between the prover and the verifier in a non-interactive protocol. It is useful to ensure that all prover messages are correctly absorbed before being used by the verifier, and that all verifier challenges are correctly produced."
sotd: "draft"
shortName: "starknet-channel"
editor: "David Wong"
Expand All @@ -9,32 +9,50 @@ tags: ["starknet", "fiat-shamir"]

## Overview

A channel is an object that mimics the communication channel between the prover and the verifier, and is used to abstract the [Fiat-Shamir transformation]() used to make the protocol non-interactive (the verifier messages are replaced by sampling a hash function).
A channel is an object that mimics the communication channel between the prover and the verifier, and is used to abstract the [Fiat-Shamir transformation](https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic) used to make the protocol non-interactive.

The Fiat-Shamir transformation works on public-coin protocols, in which the messages of the verifier are pure random values. To work, the Fiat-Shamir transformation replaces the verifier messages with a hash function applied over the transcript up to that point.

A channel is initialized at the beginning of the protocol, and is instantiated with a hash function. It is implemented as a continuous hash that "absorbs" every prover messages and which output can be used to produce the verifier's challenges.

## Dependencies

A channel is instantiated with the following two dependencies:

* `hades_permutation(s1, s2, s3)`. The hades permutation which permutates a given state of three field elements.
* `poseidon_hash_span(field_elements)`. The poseidon sponge function which hashes a list of field elements.

## Interface

A channel has two fields:

* A **digest**, which represents the current internal state.
* A **counter**, which helps produce different values when the channel is used repeatedly to sample verifier challenges.
* A **`digest`**, which represents the current internal state.
* A **`counter`**, which helps produce different values when the channel is used repeatedly to sample verifier challenges.

The channel has the following interface:

**`init(digest)`**.
**Initialize**. This intializes the channel in the following way:

* Initializes the channel with a digest, which is the prologue/context to the protocol.
* Set the counter to $0$.
* Set the `digest` to the given `digest`, which is the prologue/context to the protocol.
* Set the `counter` to $0$.

**message from prover to verifier**.
**Absorb a message from the prover**.

* Resets the counter to $0$.
* Set the digest to `POSEIDON_hash(digest + 1 || value)`. (TODO: what if several values)
* Resets the `counter` to $0$.
* Set the `digest` to `POSEIDON_hash(digest + 1 || value)`.

TODO: explain why the +1

**message from verifier to prover**.
**Absorb multiple messages from the prover**.

* Resets the `counter` to $0$.
* Set the `digest` to `POSEIDON_hash(digest + 1 || values)`.

<aside class="warning">This function is not compatible with multiple call to the previous function.</aside>

**Produce a verifier challenge**.

* Produce a random value as `hades_permutation(digest, counter, 2)`.
* Increment the counter.
* Increment the `counter`.

<aside class="note">With the current design, two different protocols where one produces $n$ challenges and another that produces $m$ challenges will have the same "transcript" and thus will continue to produce the same challenges later on in the protocol. While there are no issues in this design in the context of Starknet, this might not always be secure when used in other protocols.</aside>
<aside class="warning">With the current design, two different protocols where one produces $n$ challenges and another that produces $m$ challenges will have the same "transcript" and thus will continue to produce the same challenges later on in the protocol. While there are no issues in this design in the context of Starknet, this might not always be secure when used in other protocols.</aside>

0 comments on commit a0d2b86

Please sign in to comment.