Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

smart contract merge #26

Closed
wants to merge 65 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
65 commits
Select commit Hold shift + click to select a range
5af89f2
pipelined proving from blog post
alexture Dec 16, 2024
cdd223a
abi merge part 1
alexture Dec 17, 2024
ac8a47f
merge review
alexture Dec 18, 2024
26c5b7c
nav
alexture Dec 18, 2024
450a819
broken links from merge
alexture Dec 18, 2024
80ca99f
cosmetic fix
alexture Dec 18, 2024
5f964bb
Merge branch 'main' into smart-contract-merge
alexture Dec 18, 2024
ecf759d
duplicate file deleted
alexture Dec 18, 2024
fb3b2bb
implemented Lancelot's comments, incl. rewriting « unproven transacti…
alexture Dec 18, 2024
f1c5bc1
Merge branch 'main' into smart-contract-merge
alexture Dec 18, 2024
11a7106
from Lancelot's comments
alexture Dec 18, 2024
a15cc7d
gitignore
alexture Jan 3, 2025
370d199
vintage blockchains
alexture Dec 18, 2024
6daf97a
nav
alexture Dec 18, 2024
3e804ce
proof composition with review from Alex C. (#27)
alexture Dec 18, 2024
cb0b02c
fixed navigation extensions
alexture Dec 20, 2024
a1ec0e9
live doc reading on vintage blockchains
alexture Dec 20, 2024
f81d42b
first pass on vibe check
alexture Dec 20, 2024
26b2e92
live doc reading: use cases
alexture Dec 20, 2024
04a4394
grants fix
alexture Dec 20, 2024
8deaa82
rust node fix
alexture Dec 20, 2024
0fba8ea
mkdown fix
alexture Dec 20, 2024
ff6964a
live doc reading: roadmap
alexture Dec 20, 2024
c2f594e
examples homepage from live doc reading
alexture Dec 20, 2024
0c19bbc
delete DA page
alexture Dec 20, 2024
b68e823
pipleined proving
alexture Dec 20, 2024
09335d3
navigation
alexture Dec 23, 2024
edd5322
+ schema on pipelined proving
alexture Dec 23, 2024
4946f55
noir supported + fluff intro
alexture Dec 23, 2024
6313fcf
remove fluff
alexture Dec 23, 2024
08cdd7f
cli
alexture Dec 23, 2024
0dbf43d
alt text
alexture Dec 23, 2024
fb2f7e4
user tooling page
alexture Dec 23, 2024
4c4435e
nav
alexture Dec 23, 2024
1ec502e
first smart contract (#29)
alexture Dec 23, 2024
e2e0121
switch docker & cargo
alexture Dec 24, 2024
e0547b9
docker instructions (thanks Bertrand!)
alexture Dec 24, 2024
2be6bee
add environment variables
alexture Dec 24, 2024
180ee0b
homepage updates
alexture Dec 20, 2024
29352af
feedback from live reading, flowchart missing
alexture Dec 20, 2024
4f5645f
diagram update
alexture Dec 20, 2024
079b11f
remove fluff
alexture Dec 23, 2024
0600be4
alt text
alexture Dec 23, 2024
b9e0e5b
user tooling page
alexture Dec 23, 2024
96fedb7
docker instructions (thanks Bertrand!)
alexture Dec 24, 2024
e9b4225
env variables
alexture Dec 24, 2024
1bf2412
erc20 first steps (#31)
alexture Dec 24, 2024
e073964
nav fix for unstaged pages
alexture Dec 24, 2024
eeaa305
devnet instructions (#32)
alexture Dec 26, 2024
a6c959d
be kind
alexture Dec 26, 2024
f1a13b4
architecture
alexture Dec 26, 2024
461ee83
variables d'environnement
alexture Dec 26, 2024
53834a6
oops
alexture Dec 26, 2024
09114d1
docker image is now live!
alexture Dec 26, 2024
de14d99
rest
alexture Dec 26, 2024
f8ec2a4
environment variables
alexture Dec 26, 2024
c6e4665
env variables rephrases
alexture Dec 26, 2024
f04b796
no more need for CLI wahoo
alexture Dec 26, 2024
ffe72cd
call with Bertrand
alexture Dec 26, 2024
7a4c536
kill collatz
alexture Dec 26, 2024
15dddf7
from README
alexture Dec 26, 2024
ee94375
instruction
alexture Dec 26, 2024
2b7e623
+1 link, thanks Matteo!
alexture Dec 27, 2024
890be20
Tutorial: simple-token example & devnet (#33)
alexture Jan 3, 2025
695d40a
removed a todo: fixed
alexture Jan 3, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1 +1,4 @@
site/
db/
site/
venv/
.vscode/
4 changes: 2 additions & 2 deletions docs/.pages
Original file line number Diff line number Diff line change
Expand Up @@ -2,5 +2,5 @@ nav:
- index.md
- developers
- use-cases
- roadmap
- resources
- resources

Binary file removed docs/assets/img/hyle-main-diagram.jpg
Binary file not shown.
Binary file added docs/assets/img/hyle-main-diagram.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file removed docs/assets/img/main-diagram-large-detailed.png
Binary file not shown.
21 changes: 0 additions & 21 deletions docs/assets/img/main-diagram-large-detailed.svg

This file was deleted.

Binary file added docs/assets/img/pipelined-proving.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion docs/developers/.pages
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,6 @@ nav:
- index.md
- getting-started
- general-doc
- explorer
- explorer.md
- examples
- ...
4 changes: 4 additions & 0 deletions docs/developers/examples/.pages
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
nav:
- index.md
- ...

10 changes: 7 additions & 3 deletions docs/developers/examples/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,16 +9,20 @@ We have three Hylé-made Risc0 smart contracts :
* [`hydentity`](https://github.com/Hyle-org/hyle/tree/main/contracts/hydentity): Basic identity provider
* [`hyllar`](https://github.com/Hyle-org/hyle/tree/main/contracts/hyllar): Simple ERC20-like contract
* [`amm`](amm.md): Simple AMM contract
* [`risc0 recursion`](https://github.com/Hyle-org/hyle/tree/main/contracts/risc0-recursion)
* WIP: [`staking`](https://github.com/Hyle-org/hyle/tree/main/contracts/staking)

There is also a tool called [`hyrun`](https://github.com/Hyle-org/hyle/tree/main/crates/hyrun) to execute those contracts, generate proofs, etc.
There is also a CLI called [`hyrun`](https://github.com/Hyle-org/hyle/tree/main/crates/hyrun) to execute those contracts, generate proofs, etc.

## Code examples

* [Collatz example on Hylé](https://github.com/Hyle-org/examples/blob/main/README.md), using SP1, Noir, or Groth16

## Demos and provable apps

[Our grantees](../../resources/grants.md) have worked on a few projects that don't yet leverage Hylé. Check them out for inspiration on building provable apps!
Demos:

* [Vibe Check](vibe-check.md): a zkML app.
* [Provable play-by-email games engine](https://github.com/MatteoMer/provable-email-game-engine): A framework for building provable turn-based games, including zkChess.
<!--Add AMM?-->

[Our grantees](../../resources/grants.md) have worked on Hylé-based projects. Check them out for inspiration on building provable apps!
34 changes: 13 additions & 21 deletions docs/developers/examples/vibe-check.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,43 +13,44 @@ The step-by-step process:
1. **I identify myself.**
1. I use WebAuthn, with a Yubikey on a computer, a fingerprint on a phone, or any other accepted device.
2. Vibe Check runs the Noir prover in-browser.
3. The prover generates a Noir proof that the webauthn-signature is correct.
3. The prover generates a Noir proof that the Webauthn-signature is correct.
2. **I take a selfie where I’m smiling to generate a proof of my shiny, bubbly personality.**
1. Vibe Check uses a machine-learning model that the Hylé team has transformed into a Cairo program using [Giza](https://www.gizatech.xyz/)'s transpiler.
2. I send my selfie to this Cairo program, which runs on a virtual machine.
1. Vibe Check uses a machine-learning model.
2. I send my selfie to this Cairo program.
3. The machine-learning model checks that I am smiling.
4. If I am smiling, the Cairo-prover generates a proof.
3. **Vibe Check gives me a SmileToken.**
1. Vibe Check locally updates the state of the SmileToken.
2. Vibe Check generates a Cairo proof that the state transition was done correctly.
4. **Hylé verifies the proofs.**
1. Hylé updates the SmileToken state if everything is correct. If so, I am rewarded with that SmileToken to congratulate me for my good vibes.
2. Since Hylé’s state is checkpointed on different networks, I could get that token on any bridged network like Starknet or even Ethereum.

## How it works

### Understanding the components of the demo

The Vibe Check demo consists of three components: the **app**, the **proof generators**, and the **Hylé node**.
The Vibe Check demo consists of three components: the **app**, the **proof**, and the **Hylé node**.

#### The app

The **app** helps the user craft a transaction through 2 interactions:

- Identification with [WebAuthn](https://vivs.wiki/WebAuthn) for a proof of ID
- Photo of the user smiling for a proof of smile

The **app** sends these inputs to the **proof generators.**
The **app** prepares for proof generation; it also sends a blob of this transaction to Hylé, so Hylé can sequence it and knows to expect upcoming proofs.

The **proof generators** execute programs and generate proofs.
#### The prover

They can be run locally in the browser or remotely to maximize performance. Local proof generation is possible by compiling the Cairo VM/Cairo Prover/Noir Prover into WASM, but it is inefficient. Proving is a memory-consuming activity, and browsers usually have a low limit.
Proofs can be generated locally in the browser or remotely to maximize performance. Local proof generation is possible by compiling the Cairo VM/Cairo Prover/Noir Prover into WASM, but it is inefficient. Proving is a memory-consuming activity, and browsers usually have a low limit.

The proof generators generate three proofs:

1. Proof of ID: verification of the WebAuthn ECDSA signature in Noir
2. Proof of smile: running the machine-learning model in Cairo
3. Token (ERC-20) transfer: initiated in Cairo if the first two proofs are valid.

The **app** sends the three proofs through one single transaction to the **Hylé node**.
The **app** sends the three proofs to the **Hylé node**.

The **Hylé node:**

Expand All @@ -61,19 +62,9 @@ The **Hylé node:**

### Multiple proving schemes

A **proving scheme** is a protocol or framework for generating proofs and verifying them.

In Vibe Check, we use Noir and Cairo.

We use **Noir** to generate ECDSA proofs. Its Typescript SDK makes it easy to integrate into an app.

We use **Cairo** for two proofs:

- That there is a smile on the screenshot
- The coin transfer, with an ERC-20 specification.

We used the LambdaClass CairoVM. Because of the current dependency mismatches between the prover and the runner, the Cairo prover and the Cairo runner had to be compiled separately.
In Vibe Check, we use Noir and Cairo and we leverage [proof composability](../general-doc/proof-composability.md)

<!-- TODO: is this interesting?
### Using Giza for zkML

ZkML is one of ZK's many use cases. It helps you assert that a prediction's result was obtained with the right model, trained on the right dataset, and fed with the right input.
Expand All @@ -89,6 +80,7 @@ Here is the flow we followed:
5. We executed our model in the Cairo VM we were using.

Deep learning models, especially CNNs, would typically be more appropriate for image recognition, but some primitives used by those are not yet supported. Larger models are also extremely hard to run in a Cairo VM because of their high memory requirements.
-->

## The actual code

Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: Hyléou - Blockchain Explorer for Hylé
title: Explorer
---

**Hyléou** (a French pun for "Il est où" or "Where is it?") is the blockchain explorer for the Hylé ecosystem.
Expand Down
4 changes: 2 additions & 2 deletions docs/developers/general-doc/.pages
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
nav:
- anatomy-smart-contracts.md
- supported-proving-schemes.md
- pipelined-proving.md
- hyle-vs-ethereum.md
- smart-contracts.md
- hyle-vs-vintage-blockchains.md
- ...
44 changes: 0 additions & 44 deletions docs/developers/general-doc/anatomy-smart-contracts.md

This file was deleted.

41 changes: 0 additions & 41 deletions docs/developers/general-doc/data-availability.md

This file was deleted.

Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Hylé vs. Ethereum
# Hylé vs. vintage blockchains

If you're used to Ethereum, you might be surprised by some of these Hylé characteristics.
If you're used to traditional blockchains such as Ethereum or Solana, keep these Hylé characteristics in mind.

## No EVM
## No EVM or execution layer

Hylé does not include a Virtual Machine.

Expand Down
20 changes: 13 additions & 7 deletions docs/developers/general-doc/pipelined-proving.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

Hylé ensures both privacy and scalability by verifying only the state transitions of smart contracts.

However, provable applications usually run into an issue. Proof generation can be slow, especially on less powerful devices, and an app with a lot of usage will see competing operations, ie. operations that start with the same base state because the previous state change hasn't been settled yet.
However, provable applications usually run into an issue. Proof generation can be slow, especially on less powerful devices, and an app with a lot of usage will see conflicting operations, ie. operations that start with the same base state because the previous state change hasn't been settled yet.

This is linked to several challenges:

Expand All @@ -21,15 +21,21 @@ Hylé splits operations into two transactions:
1. **Blob-transaction**: outlines a state change for sequencing.
2. **Proof-transaction**: provides a proof for the claimed state change for settlement.

From Hylé’s perspective, the blob-transaction's content is irrelevant: it simply represents incoming information that your contract will process.
From Hylé’s perspective, the blob-transaction's content is not an issue: it simply represents incoming information that your contract will process.

1. **Sequencing** happens when the blob transaction is received and included in a block. This step establishes a global order and timestamps for transactions.
1. **Settlement** happens when the corresponding proof transaction is verified and added to the block.
1. **Settlement** happens when the corresponding proof transaction is verified and added to a block.

During settlement, proved blob transactions linked to the contract are executed in their sequencing order.
During settlement, unproven blob transactions linked to the contract are executed in their sequencing order.

## Unprovable transactions
## Unproven transactions

Hylé introduces **timeouts** for blob transactions to ensure timely proof submissions.
Even with [pipelined proving](./pipelined-proving.md), the delay in proof generation and submission can delay transaction finality and create uncertainty when determining the initial state of subsequent transactions.

Transactions without proofs within a specific duration, as well as transactions with invalid proofs, are rejected.
To remove this bottleneck, Hylé enforces **timeouts** for blob transactions.

Each blob transaction is assigned a specific time limit for the associated proof to be submitted and verified. If the proof is not successfully provided within this window, the transaction is rejected: it is ignored for state updates but remains recorded in the block.

The inclusion of the unproven transaction in the block ensures transparency, as the transaction data remains accessible.

Subsequent transactions can proceed without waiting indefinitely.
50 changes: 50 additions & 0 deletions docs/developers/general-doc/proof-composability.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Proof composition and cross-contract calls

<!-- Réécrire avec un exemple -->

To understand the concept of proof composability on Hylé, we recommend you [read this blog post](https://blog.hyle.eu/proof-composability-on-hyle/). This page focuses on demonstrating how to use proof composition in your code.

## What is proof composition?

**Proof composition** happens when two contracts depend on each other. **Proof composability** is the fact that Hylé allows you to manage this situation while keeping their proofs independent.

Most zero-knowledge systems deal with cross-contract calls by enforcing recursive proof verification:

- Program A verifies proof of correct execution of Program B;
- Program B verifies proof of correct execution of Program A.

<!-- Rewrite section -->
Hylé allows you to assume, in Program A, that Program B has been successfully executed, by verifying that claim. If you batch both blobs in the same operation, we verify both natively outside of the contract; the whole operation fails if one proof fails to verify.

Read more [on our blog](https://blog.hyle.eu/proof-composability-on-hyle/).

## Writing a cross-contract call

Your program does not need to verify the execution of another program directly.

Instead, it uses a representation of the called contracts, which looks like this: `MoneyApp::transfer(10, A, B) == true` or `TicketApp::get(A) == ticket`.

This representation consists of:

- the app
- the function
- the function's parameters
- a claim on the results.

<!-- TODO: replace list with an example -->

Follow these steps:

1. **Inject claims**: add all the claims as inputs to the blob.
1. **Index claims**: provide an index to tell the contract where to locate its input.
1. **Assert claims**: use the claim list to validate the required conditions for the blob.

## How Hylé settles multiple proofs

When you submit multiple proofs to Hylé:

- Proof generation can be parallelized: proving times do not compound since proofs do not depend on each other.
- Proof verification is asynchronous thanks to [pipelined proving](./pipelined-proving.md). As soon as one proof is ready, it can be verified on Hylé, even if the other proofs aren't ready yet.
- Once all proofs related to the transaction are verified, the transaction is settled on Hylé. If one proof verification fails, then the entire transaction fails.

Read more [on our blog](https://blog.hyle.eu/proof-composability-on-hyle/).
25 changes: 25 additions & 0 deletions docs/developers/general-doc/run-a-node.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Run a node

<!-- TODO: Review entirely-->

We currently don't have a deployment file available.

Follow these instructions to run a node, keeping in mind that this is unstable and can break with upcoming updates.

Download the Docker image:

```bash
docker pull europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main
```

Then run the image:

```bash
docker run --name [container_name] -d [options] europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main
```

And rebuild the node from the source:

```bash
docker build -t Hyle-org/hyle . && docker run -dit Hyle-org/hyle
```
Loading