From a7d4e3692b2b560e061cef313851df4a1a898f1e Mon Sep 17 00:00:00 2001 From: Alex Sirac Date: Thu, 26 Dec 2024 10:19:54 +0100 Subject: [PATCH] Deployed 3d99dff with MkDocs version: 1.6.1 --- developers/getting-started/amm/index.html | 2 +- developers/getting-started/devnet/index.html | 229 +++++++++--------- .../erc20-and-identity/index.html | 2 +- .../identity-management/index.html | 2 +- developers/getting-started/index.html | 2 +- .../getting-started/user-tooling/index.html | 2 +- .../your-first-erc20/index.html | 2 +- .../your-first-smart-contract/index.html | 2 +- search/search_index.json | 2 +- 9 files changed, 127 insertions(+), 118 deletions(-) diff --git a/developers/getting-started/amm/index.html b/developers/getting-started/amm/index.html index 426f4a1..dcc1d20 100644 --- a/developers/getting-started/amm/index.html +++ b/developers/getting-started/amm/index.html @@ -373,7 +373,7 @@ - Devnet + Run your local devnet diff --git a/developers/getting-started/devnet/index.html b/developers/getting-started/devnet/index.html index 6d6a308..4122756 100644 --- a/developers/getting-started/devnet/index.html +++ b/developers/getting-started/devnet/index.html @@ -20,7 +20,7 @@ - Devnet - Hylé Developer Hub + Run your local devnet - Hylé Developer Hub @@ -72,7 +72,7 @@
- + Skip to content @@ -107,7 +107,7 @@
- Devnet + Run your local devnet
@@ -387,7 +387,7 @@ - Devnet + Run your local devnet @@ -398,7 +398,7 @@ - Devnet + Run your local devnet @@ -420,16 +420,6 @@ - - @@ -1002,16 +981,6 @@ - - @@ -1100,17 +1058,12 @@ -

Devnet

+

Run your local devnet

-

Follow the instructions below to start building on Hylé by running a local devnet.

-

Run your local devnet

- -
-

Failure

-

We currently don't have a public Docker image available. Please contact us if you need it.

-
+

Follow the instructions below to start building on Hylé by running a local devnet. (Instructions for a testnet will be added when we launch it.)

+

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

Download the Docker image:

docker pull ghcr.io/hyle-org/hyle:latest
@@ -1125,61 +1078,117 @@ 
Build the Docker image locally

+
You can customize the db URL with HYLE_DATABASE_URL, with the default value being: postgres://postgres:postgres@localhost:5432/postgres (see below for environment variables).

+
Build the Docker image locally

 
If you want to, you can rebuild the image locally from source:

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

-
Alternative: Getting started from source

+
Alternative: Getting started from source

 
To start a single-node devnet (with consensus disabled), which is useful to build & debug smart contracts, run:

 
cargo build
 HYLE_RUN_INDEXER=false cargo run --bin node
 

-
Configuration

+
Configuration

 
You can configure your setup using environment variables or by editing a configuration file.

 
 
-
Using environment variables

-
-
-
Here's an example of how you can configure your setup using environment variables:

-
HYLE_RUN_INDEXER=false 
-HYLE_CONSENSUS__SLOT_DURATION=100
-

-
This is the default configuration for a node. All variables can be customized on your single-node instance.

-
Config(
-  id: "node",
-  single_node: true,
-  p2p_listen: true,
-  host: "127.0.0.1:1231",
-  peers: [],
-  storage: Storage(
-    interval: 10
-  ),
-  log_format: "full",
-  rest: "127.0.0.1:4321",
-  data_directory: "data_node",
-  database_url: "postgres://postgres:postgres@localhost:5432/postgres",
-  consensus: Consensus (
-    slot_duration: 1000,
-    // Has to be empty as config is additive
-    genesis_stakers: {}
-  ),
-  p2p: (
-    ping_interval: 10
-  ),
-  run_indexer: true,
-  da_address: "127.0.0.1:4141"
-)
-

-
Using a configuration file

+
Using environment variables

+
The variable always begins with HYLE_, followed by the variable: HYLE_RUN_INDEXER=false. Multi-level variables are chained together with a double _, eg. HYLE_CONSENSUS__SLOT_DURATION=100.

+
All variables can be customized on your single-node instance.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
VariableDefault valueDescription
id"node"
single_nodetrueWhether the network runs as a single node.
p2p_listentrue
host"127.0.0.1:1231"
peers[]
storage__interval10
log_format"full"
rest"127.0.0.1:4321"
data_directory"data_node"
database_url"postgres://postgres:postgres@localhost:5432/postgres"PostgreSQL server address (necessary if you want to use an indexer).
consensus__slot_duration1000
consensus__genesis_stakers{}Has to be empty as config is additive
p2p__ping_interval10
run_indexertrueWhether there should be an indexer.
da_address"127.0.0.1:4141"

+
Using a configuration file

 
To use a configuration file, copy the default settings where you run the node. If a file named config.ron is present, it will be automatically loaded by the node at startup.

 
If you're using Docker:

-
docker run -v ./db:/hyle/data -v ./config.run:/hyle/config.ron -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest
+
docker run -v ./db:/hyle/data -v ./config.run:/hyle/config.ron -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest
 

 
Then, whether you're using Docker or building from source:

-
# Copy default config where you run the node. If file named "config.ron" is present, it will be loaded by node at startup.
-cp ./src/utils/conf_defaults.ron config.ron
+
# Copy default config where you run the node. If file named "config.ron" is present, it will be loaded by node at startup.
+cp ./src/utils/conf_defaults.ron config.ron
 

 
 
diff --git a/developers/getting-started/erc20-and-identity/index.html b/developers/getting-started/erc20-and-identity/index.html
index 4c4d9e9..bb62064 100644
--- a/developers/getting-started/erc20-and-identity/index.html
+++ b/developers/getting-started/erc20-and-identity/index.html
@@ -373,7 +373,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/developers/getting-started/identity-management/index.html b/developers/getting-started/identity-management/index.html
index bd7775d..52ca1eb 100644
--- a/developers/getting-started/identity-management/index.html
+++ b/developers/getting-started/identity-management/index.html
@@ -373,7 +373,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/developers/getting-started/index.html b/developers/getting-started/index.html
index 1d80733..6a14cf8 100644
--- a/developers/getting-started/index.html
+++ b/developers/getting-started/index.html
@@ -373,7 +373,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/developers/getting-started/user-tooling/index.html b/developers/getting-started/user-tooling/index.html
index 32af053..5d4dfa7 100644
--- a/developers/getting-started/user-tooling/index.html
+++ b/developers/getting-started/user-tooling/index.html
@@ -378,7 +378,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/developers/getting-started/your-first-erc20/index.html b/developers/getting-started/your-first-erc20/index.html
index df2c7a2..0d0bddc 100644
--- a/developers/getting-started/your-first-erc20/index.html
+++ b/developers/getting-started/your-first-erc20/index.html
@@ -378,7 +378,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/developers/getting-started/your-first-smart-contract/index.html b/developers/getting-started/your-first-smart-contract/index.html
index af79e5f..5b9dccb 100644
--- a/developers/getting-started/your-first-smart-contract/index.html
+++ b/developers/getting-started/your-first-smart-contract/index.html
@@ -378,7 +378,7 @@
         
   
   
-    Devnet
+    Run your local devnet
   
   
 
diff --git a/search/search_index.json b/search/search_index.json
index 74b2f9b..216d977 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":""},{"location":"#home","title":"Home","text":"
Hyl\u00e9 is a lean blockchain that lets you easily take your provable application onchain.
 
Note
 
This developer portal and the project itself are still evolving. Join us on Telegram if you need assistance or wish to provide feedback. Issues and PRs on this documentation's GitHub repository are also very welcome!
"},{"location":"#why-choose-hyle","title":"Why choose Hyl\u00e9","text":"
     
  • Native zero-knowledge proof verification on our sovereign L1: we're fast and lean.
    •  
  • No onchain execution or virtual machine needed: only efficient proof verification.
    •  
  • Run complex logic offchain and only submit proofs onchain for maximum scalability.
    •  
  • Proof composability: seamlessly combine multiple proofs into single, verifiable transactions.
    •  
  • Pipelined proving: send provable blobs, don't worry about proving times.
    •  
  • Choose your proving scheme and your language: we verify all proofs.
    •  
"},{"location":"#how-hyle-works","title":"How Hyl\u00e9 works","text":"
Here\u2019s what happens when you use Hyl\u00e9\u2019s sovereign verification-focused Layer 1:
 
 
     
  1. Sequencing: Send a provable blob to Hyl\u00e9: say what information you expect to prove later. We'll sequence the transaction immediately. Read more about pipelined proving.
    2.  
  2. Proof submission: when the proofs for your transaction are ready, send them to Hyl\u00e9.
    3.  
  3. Verification: Hyl\u00e9 validators receive the transaction. They verify the proofs natively, without the limitations of a bulky virtual machine.
    4.  
  4. Consensus: if the proofs are valid, Hyl\u00e9 settles your transaction's state onchain. You're good to go!
    5.  
 
With this system, execution and storage happen anywhere you like. You only need a fast and trustworthy verifier: that\u2019s Hyl\u00e9.
"},{"location":"#documentation","title":"Documentation","text":"
     
  • Get started now
    •  
  • Learn more about Hyl\u00e9
    •  
  • Check out examples
    •  
"},{"location":"#links","title":"Links","text":"
     
  • Rust node
    •  
  • Hyle.eu
    •  
  • Hyl\u00e9 blog
    •  
 
Reach out to the team for more information:
  Github  Twitter  Farcaster  LinkedIn  Youtube  Telegram Hyl\u00e9 @hyle_org @hyle-org Hyl\u00e9 @Hyl\u00e9 @hyle_org"},{"location":"developers/","title":"\ud83d\udc69\u200d\ud83d\udcbb Developer documentation","text":""},{"location":"developers/#developer-documentation","title":"\ud83d\udc69\u200d\ud83d\udcbb Developer documentation","text":"
Welcome to the developer documentation for Hyl\u00e9!
 
     
  • Quickstart
    •  
  • General documentation about Hyl\u00e9
    •  
  • Explorer
    •  
  • Annotated examples
    •  
"},{"location":"developers/explorer/","title":"Explorer","text":"
Hyl\u00e9ou (a French pun for \"Il est o\u00f9\" or \"Where is it?\") is the blockchain explorer for the Hyl\u00e9 ecosystem.
 
The explorer is live at hyleou.hyle.eu.  
 
The source code is available on GitHub. We welcome PRs and issues!
"},{"location":"developers/explorer/#features","title":"Features","text":"
All features are in active development. 
"},{"location":"developers/explorer/#live-features","title":"Live features","text":"
Currently, you can:
 
     
  • View the latest blocks
    •  
  • View the latest transactions.
    •  
  • View detailed information about specific blocks and transactions.
    •  
"},{"location":"developers/explorer/#upcoming-features","title":"Upcoming features","text":"
Planned features include:
 
     
  • Register new contracts.
    •  
  • Send transactions by uploading ZK proofs to specific contracts (multicall not yet supported).
    •  
"},{"location":"developers/examples/","title":"Examples","text":""},{"location":"developers/examples/#examples","title":"Examples","text":"
Detailed examples of Hyl\u00e9-based applications.
"},{"location":"developers/examples/#sample-contracts-in-hyle","title":"Sample contracts in Hyl\u00e9","text":"
We have three Hyl\u00e9-made Risc0 smart contracts :
 
     
  • hydentity: Basic identity provider
    •  
  • hyllar: Simple ERC20-like contract
    •  
  • amm: Simple AMM contract
    •  
  • risc0 recursion
    •  
  • WIP: staking
    •  
 
There is also a CLI called hyrun to execute those contracts, generate proofs, etc.
"},{"location":"developers/examples/#code-examples","title":"Code examples","text":"
     
  • Collatz example on Hyl\u00e9, using SP1, Noir, or Groth16
    •  
"},{"location":"developers/examples/#demos-and-provable-apps","title":"Demos and provable apps","text":"
Demos:
 
     
  • Vibe Check: a zkML app.
    •  
 
Our grantees have worked on Hyl\u00e9-based projects. Check them out for inspiration on building provable apps!
"},{"location":"developers/examples/amm/","title":"AMM","text":""},{"location":"developers/examples/amm/#amm","title":"AMM","text":"
The Hyl\u00e9 AMM is a decentralized Automated Market Maker (AMM) built on the Hyl\u00e9 protocol. It showcases how Hyl\u00e9 can be used for efficient, scalable, and secure decentralized trading.
"},{"location":"developers/examples/amm/#overview","title":"Overview","text":"
The AMM simplifies decentralized trading through a constant function market maker model. Developers can leverage its architecture to integrate trading functionalities within their dApps.
 
Key highlights include:
 
     
  • Scalability: Supports high throughput and low-latency transactions, even under heavy network usage.
    •  
  • Composability: you can use it to interact with your own provable applications.
    •  
"},{"location":"developers/examples/amm/#links","title":"Links","text":"
     
  • Front-end and back-end
    •  
  • Contracts
    •  
"},{"location":"developers/examples/collatz-example-in-depth/","title":"Collatz example","text":""},{"location":"developers/examples/collatz-example-in-depth/#collatz-example","title":"Collatz example","text":"
Hyl\u00e9 smart contracts can be written in any language that targets one of our supported proving schemes.
 
On this page, we'll use the RISC Zero Collatz Conjecture program, which can be found in our examples repository.
"},{"location":"developers/examples/collatz-example-in-depth/#what-is-the-collatz-conjecture","title":"What is the Collatz conjecture?","text":"
The Collatz conjecture is a simple mathematical problem that can be expressed as a program.  
 
The conjecture states that, for any positive integer n:
 
     
  • if n is even, divide it by 2
    •  
  • if n is odd, multiply it by 3 and add 1
    •  
  • repeat this process, and you will eventually reach 1.
    •  
 
The program is implemented in Rust, and compiles to the RISC Zero zkVM.
"},{"location":"developers/examples/collatz-example-in-depth/#compiling-the-program","title":"Compiling the program","text":"
To compile the program, you will need to have the RISC Zero toolchain installed. Follow the official instructions to get the most up-to-date information.
 
To use RISC Zero, you'll need to compile with
 
cargo build --features risc0\n
 
The matching binary is risc0-runner.
 
Run cargo risczero build to build smart contract.
"},{"location":"developers/examples/collatz-example-in-depth/#running-the-collatz-conjecture-program","title":"Running the Collatz Conjecture program","text":"
Hyl\u00e9 smart contracts can be executed client-side, enabling strong decentralization and permissionlessness.
 
To execute the smart contract, run the program with correct inputs.
"},{"location":"developers/examples/collatz-example-in-depth/#generate-a-proof","title":"Generate a proof","text":""},{"location":"developers/examples/collatz-example-in-depth/#prove-the-transition-from-x-to-the-next-number","title":"Prove the transition from X to the next number","text":"
# Generate a proof of the transition from X to the next number in the Collatz conjecture\ncargo run next X\n# Or do it reproducibly\ncargo run -- -r next X\n
 
Here are some concrete examples:
 
# Compute a proof of a transition between the number 12 and 6\ncargo run next 12\n\n# Compute a proof of a transition between the number 17 and 52\ncargo run next 17\n
"},{"location":"developers/examples/collatz-example-in-depth/#reset-to-x","title":"Reset to X","text":"
# Reset to X, assuming the current number is a 1\ncargo run reset X\n# Or do it reproducibly\ncargo run -- -r reset X\n
 
Here is one concrete example:
 
# Reset the state from 1 to 31\ncargo run reset 31\n
"},{"location":"developers/examples/collatz-example-in-depth/#invalid-transitions","title":"Invalid transitions","text":"
The Collatz smart contract demonstrates how the code of the smart contract enforces constraints on the state:
 
     
  • You can't generate valid proofs of transition between numbers that are not part of the Collatz sequence.
    •  
  • The contract will reject attempts to reset to 0, as there would no longer be any next state.
    •  
"},{"location":"developers/examples/collatz-example-in-depth/#use-the-proof","title":"Use the proof","text":"
Every time, a proof.json file containing the receipt will be generated. You can use this proof, along with the inputs, to trigger state transitions on Hyl\u00e9. Read more: Your first smart contract.
"},{"location":"developers/examples/collatz-example-in-depth/#verify-the-proof","title":"Verify the proof","text":"
Coming next.
"},{"location":"developers/examples/vibe-check/","title":"Vibe Check","text":""},{"location":"developers/examples/vibe-check/#vibe-check","title":"Vibe Check","text":"
The general idea of the Vibe Check app is to give people a SmileToken to reward them for smiling.
 
Watch Sylve's demo at ETHCC[7].
 
Find the code in the dedicated GitHub repository.
"},{"location":"developers/examples/vibe-check/#context","title":"Context","text":"
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.  
    2. Vibe Check runs the Noir prover in-browser.
      3.  
    3. The prover generates a Noir proof that the Webauthn-signature is correct.
      4.  
     
    2.  
  2. I take a selfie where I\u2019m smiling to generate a proof of my shiny, bubbly personality.
       
    1. Vibe Check uses a machine-learning model.
      2.  
    2. I send my selfie to this Cairo program.
      3.  
    3. The machine-learning model checks that I am smiling.
      4.  
    4. If I am smiling, the Cairo-prover generates a proof.
      5.  
     
    3.  
  3. Vibe Check gives me a SmileToken.
       
    1. Vibe Check locally updates the state of the SmileToken.
      2.  
    2. Vibe Check generates a Cairo proof that the state transition was done correctly.
      3.  
     
    4.  
  4. Hyl\u00e9 verifies the proofs.
       
    1. Hyl\u00e9 updates the SmileToken state if everything is correct. If so, I am rewarded with that SmileToken to congratulate me for my good vibes.
      2.  
     
    5.  
"},{"location":"developers/examples/vibe-check/#how-it-works","title":"How it works","text":""},{"location":"developers/examples/vibe-check/#understanding-the-components-of-the-demo","title":"Understanding the components of the demo","text":"
The Vibe Check demo consists of three components: the app, the proof, and the Hyl\u00e9 node.
"},{"location":"developers/examples/vibe-check/#the-app","title":"The app","text":"
The app helps the user craft a transaction through 2 interactions:
 
     
  • Identification with WebAuthn for a proof of ID
    •  
  • Photo of the user smiling for a proof of smile
    •  
 
The app prepares for proof generation; it also sends a blob of this transaction to Hyl\u00e9, so Hyl\u00e9 can sequence it and knows to expect upcoming proofs.
"},{"location":"developers/examples/vibe-check/#the-prover","title":"The prover","text":"
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.  
  2. Proof of smile: running the machine-learning model in Cairo
    3.  
  3. Token (ERC-20) transfer: initiated in Cairo if the first two proofs are valid.
    4.  
 
The app sends the three proofs to the Hyl\u00e9 node.
 
The Hyl\u00e9 node:
 
     
  1. Unpacks the three proofs.
    2.  
  2. Verifies each proof with the correct verifier: Noir for WebAuthn and Cairo for the two others.
    3.  
  3. Ensures consistency by checking the public data contained in the proofs to ensure they all relate to the same transaction.
    4.  
 
"},{"location":"developers/examples/vibe-check/#multiple-proving-schemes","title":"Multiple proving schemes","text":"
In Vibe Check, we use Noir and Cairo and we leverage proof composability
"},{"location":"developers/examples/vibe-check/#the-actual-code","title":"The actual code","text":"
Find the code in the dedicated GitHub repository!
"},{"location":"developers/general-doc/","title":"General documentation","text":"
Welcome to the developer documentation for Hyl\u00e9.
 
You can also refer to our Getting Started step-by-step guide.
"},{"location":"developers/general-doc/anatomy-smart-contracts/","title":"Smart contracts on Hyl\u00e9","text":""},{"location":"developers/general-doc/anatomy-smart-contracts/#smart-contracts-on-hyle","title":"Smart contracts on Hyl\u00e9","text":"
Hyl\u00e9 is a fully programmable blockchain that optimizes data storage by keeping only the essential information needed to validate smart contract proofs. This design ensures that Hyl\u00e9 smart contracts are lightweight and efficient.
 
Hyl\u00e9 smart contracts include:
 
     
  • Name: the unique identifier for your contract
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\")
    •  
  • Program ID: the unique identifier for your program in that proof system
    •  
  • State digest: current state commitment of the contract
    •  
 
Depending on the type of zk-proof circuits you use, there are some superficial differences, but the overall idea is that all inputs are known at proof generation time.
 
This page uses the Rust structures to demonstrate, but you can use the following repos for other languages:
 
     
  • Rust example: https://github.com/Hyle-org/collatz-conjecture
    •  
  • Gnark / Groth16 example (outdated): https://github.com/Hyle-org/groth16-example
    •  
"},{"location":"developers/general-doc/anatomy-smart-contracts/#name","title":"Name","text":"
The name of your contract must be unique.
"},{"location":"developers/general-doc/anatomy-smart-contracts/#verifier-and-program-identifier","title":"Verifier and program identifier","text":"
Smart contracts on Hyl\u00e9 rely on a pairing of a zero-knowledge proof scheme (verifier) and a program identifier. Together, these components validate contract proofs.
 Proving scheme Verifier Program ID Risc Zero risc0 Image ID without a prefix. ex. 0x123 becomes 123. SP1 sp1"},{"location":"developers/general-doc/anatomy-smart-contracts/#state-digest","title":"State digest","text":"
The state digest is a minimal yet comprehensive representation of the contract's current state. It serves as the basis for verifying the integrity of the contract's data.
 
Some examples of valid state commitments:
 
     
  • The full state, for a sufficiently small program (e.g. the Collatz example, or a smart-contract with a nonce)
    •  
  • A merkle root of the state, for larger programs
    •  
  • A hash of the full state
    •  
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/","title":"Hyl\u00e9 vs. vintage blockchains","text":""},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#hyle-vs-vintage-blockchains","title":"Hyl\u00e9 vs. vintage blockchains","text":"
If you're used to traditional blockchains such as Ethereum or Solana, keep these Hyl\u00e9 characteristics in mind.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#no-evm-or-execution-layer","title":"No EVM or execution layer","text":"
Hyl\u00e9 does not include a Virtual Machine.
 
There is no dedicated execution engine or specific programming language (like Solidity) you should use.
 
Our approach is simple: onchain, we verify zero-knowledge proofs natively. Offchain, you do everything else, the way you prefer.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#no-onchain-state","title":"No onchain state","text":"
The network maintains proofs of state transitions rather than the entire onchain state.
 
Transactions on Hyl\u00e9 verify and settle transitions without storing full intermediary states onchain.
 
This architecture reduces storage overhead and promotes scalability while maintaining trustlessness.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#privacy-is-built-in","title":"Privacy is built-in","text":"
Unlike Ethereum, where privacy solutions must be implemented on top of the platform, Hyl\u00e9 integrates privacy features natively.
 
The proof is public, but your inputs don't need to be, as execution happens offchain.
"},{"location":"developers/general-doc/pipelined-proving/","title":"Pipelined proving","text":""},{"location":"developers/general-doc/pipelined-proving/#pipelined-proving","title":"Pipelined proving","text":""},{"location":"developers/general-doc/pipelined-proving/#the-problem-base-state-conflicts","title":"The problem: base state conflicts","text":"
Hyl\u00e9 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 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:
 
     
  • Proof generation latency
    •  
  • Timekeeping: proofs require accurate time information, but users can't predict when their transaction will be sequenced.
    •  
  • Parallelization: proofs must include valid state transitions, but multiple transactions can accidentally reference the same base state.
    •  
 
We solve these issues by splitting sequencing from settlement; an operation includes two transactions.
"},{"location":"developers/general-doc/pipelined-proving/#blob-transaction-vs-proof-transaction","title":"Blob-transaction vs. Proof-transaction","text":"
Hyl\u00e9 splits operations into two transactions:
 
     
  1. Blob-transaction: outlines a state change for sequencing.
    2.  
  2. Proof-transaction: provides a proof for the claimed state change for settlement.
    3.  
 
From Hyl\u00e9\u2019s 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.
    2.  
  2. Settlement happens when the corresponding proof transaction is verified and added to the block.
    3.  
 
During settlement, proved blob transactions linked to the contract are executed in their sequencing order.
 
"},{"location":"developers/general-doc/pipelined-proving/#unprovable-transactions","title":"Unprovable transactions","text":"
Hyl\u00e9 introduces timeouts for blob transactions to ensure timely proof submissions.
 
Transactions without proofs within a specific duration, as well as transactions with invalid proofs, are rejected.
"},{"location":"developers/general-doc/proof-composability/","title":"Proof composition and cross-contract calls","text":""},{"location":"developers/general-doc/proof-composability/#proof-composition-and-cross-contract-calls","title":"Proof composition and cross-contract calls","text":"
To understand the concept of proof composability on Hyl\u00e9, we recommend you read this blog post. This page focuses on demonstrating how to use proof composition in your code.
"},{"location":"developers/general-doc/proof-composability/#what-is-proof-composition","title":"What is proof composition?","text":"
Proof composition happens when two contracts depend on each other. Proof composability is the fact that Hyl\u00e9 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.
    •  
 
Hyl\u00e9 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.
"},{"location":"developers/general-doc/proof-composability/#writing-a-cross-contract-call","title":"Writing a cross-contract call","text":"
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.
    •  
 
Follow these steps:
 
     
  1. Inject claims: add all the claims as inputs to the blob.
    2.  
  2. Index claims: provide an index to tell the contract where to locate its input.
    3.  
  3. Assert claims: use the claim list to validate the required conditions for the blob.
    4.  
"},{"location":"developers/general-doc/proof-composability/#how-hyle-settles-multiple-proofs","title":"How Hyl\u00e9 settles multiple proofs","text":"
When you submit multiple proofs to Hyl\u00e9:
 
     
  • 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. As soon as one proof is ready, it can be verified on Hyl\u00e9, even if the other proofs aren't ready yet.
    •  
  • Once all proofs related to the transaction are verified, the transaction is settled on Hyl\u00e9. If one proof verification fails, then the entire transaction fails.
    •  
 
Read more on our blog.
"},{"location":"developers/general-doc/run-a-node/","title":"Run a node","text":""},{"location":"developers/general-doc/run-a-node/#run-a-node","title":"Run a node","text":"
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:
 
docker pull europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main\n
 
Then run the image:
 
docker run --name [container_name] -d [options] europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main\n
 
And rebuild the node from the source:
 
docker build -t Hyle-org/hyle . && docker run -dit Hyle-org/hyle\n
"},{"location":"developers/general-doc/smart-contract-abi/","title":"Smart Contract ABI","text":""},{"location":"developers/general-doc/smart-contract-abi/#smart-contract-abi","title":"Smart Contract ABI","text":"
Hyl\u00e9 focuses on verifying zk-proofs. Because of this, writing smart contracts on Hyl\u00e9 has some specificities, with other elements being the same as with most other blockchains.
 
Depending on the type of zk-proof circuits you use, there are some superficial differences, but the overall idea is that all inputs are known at proof generation time. This includes unusual elements such as the origin of the transaction (tx.origin in Ethereum) and the block number.
 
The Hyl\u00e9 protocol enforces several invariants on transactions to maximize security. For this reason, we must specify some of the data within a zero-knowledge proof.
 
This page uses the Rust structures to demonstrate, but you can use the following repos for other languages:
 
     
  • Rust example: https://github.com/Hyle-org/collatz-conjecture
    •  
  • Gnark / Groth16 example (outdated): https://github.com/Hyle-org/groth16-example
    •  
"},{"location":"developers/general-doc/smart-contract-abi/#overview","title":"Overview","text":"
Here is the rust struct specifying the output of a Hyl\u00e9 smart contract:
 
pub struct HyleOutput<T> {\n    pub version: u32,\n    pub initial_state: Vec<u8>,\n    pub next_state: Vec<u8>,\n    pub identity: String,\n    pub tx_hash: Vec<u8>,\n    pub payload_hash: Vec<u8>,\n    pub success: bool,\n    pub program_outputs: T\n}\n
 
The version field should currently be set to 1.
"},{"location":"developers/general-doc/smart-contract-abi/#initial-state-and-next-state","title":"Initial State and Next State","text":"
Blockchains transactions are fundamentally state transitions. These fields handle the state transitions securely in the protocol.
 
The initial_state field should match the state digest of the contract before the transaction. This could consist of several things, such as:
 
     
  • the hash of the previous state
    •  
  • the Merkle root of the previous state tree
    •  
  • the state itself if it's small enough
    •  
 
The protocol enforces that this initial_state matches the onchain state_digest it knows. Otherwise, the state transition is invalid.
 
The next_state field represents the new onchain state_digest after the transaction.
 
Smart contracts can adapt the actual structure of this field. In the future, fees will depend on the size of the state_digest (among other criteria), so we encourage you to keep it small.
"},{"location":"developers/general-doc/smart-contract-abi/#identity","title":"Identity","text":"
The identity field is the identifier of the person who initiated the transaction.
 
Unlike other blockchains, Hyl\u00e9 does not have a native signature type. Instead, Hyl\u00e9 uses the identity field of the first proof to identify the TX sender. To ensure security, the field is composite and ends with the name of the contract that the proof was generated for.
 
Hyl\u00e9 could for example support Ethereum EOAs, if a smart contract is registered onchain to verify them. The identity would then look something like 0x1234...5678.eth_eoa, where eth_eoa is the name of the contract, and the first part matches a regular Ethereum address.
 
This gives us massive flexibility in the future to support any kind of identity verification, including WebAuthn, social media accounts, etc.
 
For now, any subsequent proof in a TX must declare the same identity or an empty one, or the transaction will be rejected.
"},{"location":"developers/general-doc/smart-contract-abi/#tx-hash","title":"TX Hash","text":"
The tx_hash field is intended to hash transaction data, preventing replay attacks and providing a means for contracts to access this information.
 
The field is currently completely unspecified and isn't validated by the protocol.
"},{"location":"developers/general-doc/smart-contract-abi/#payload-hash","title":"Payload Hash","text":"
This should match the hash of the payload that was sent to the network initially. Currently we use pedersen hashing for Cairo, no hashing for Risc0. Others are unimplemented. This is very WIP (as of August 2024) and will change soon.
"},{"location":"developers/general-doc/smart-contract-abi/#success","title":"Success","text":"
This is a boolean - whether the proof is for a succesful proof or a failure case. It can be useful to prove that a transaction is invalid. See our example in Vibe Check.
"},{"location":"developers/general-doc/smart-contract-abi/#other-program-specific-outputs","title":"Other program-specific outputs","text":"
Smart contracts can provide other outputs as part of the proof they generate.
 
This can be used for a variety of purposes, but mostly serves to provide Data Availability.
"},{"location":"developers/general-doc/smart-contract-abi/#events","title":"Events","text":"
Hyl\u00e9 does not currently ship native events. We are looking into implementing them in the near future.
"},{"location":"developers/general-doc/supported-proving-schemes/","title":"Proving schemes","text":""},{"location":"developers/general-doc/supported-proving-schemes/#proving-schemes","title":"Proving schemes","text":"
Proving schemes are the cryptographic protocols that make zero-knowledge proofs usable.
 
We support as many as we can, giving you the flexibility to choose the most suitable protocol for your specific use case.
"},{"location":"developers/general-doc/supported-proving-schemes/#supported-proving-schemes","title":"Supported proving schemes","text":"
As of December 2024, Hyl\u00e9 currently supports the following zero-knowledge proving schemes:
 
     
  • Noir
    •  
  • Risc0
    •  
  • SP1
    •  
"},{"location":"developers/general-doc/supported-proving-schemes/#planned-future-support","title":"Planned future support","text":"
We plan to eventually support all major proving schemes.
 
The next proving schemes we're aiming to support are:
 
     
  • Cairo via Stwo
    •  
  • Groth16
    •  
"},{"location":"developers/getting-started/","title":"Getting started","text":"
Welcome to the Getting Started guide for Hyl\u00e9.
 
This page will help you configure your environment and start using Hyl\u00e9.
 
Use the sidebar to navigate through the guide, or click on the links below to jump to a specific section:
 
     
  1. Run your local devnet
    2.  
  2. Use our tools
    3.  
  3. Create your first smart contract
    4.  
  4. Get inspiration from our in-depth Collatz example
    5.  
  5. Understand Hyl\u00e9's smart contract ABI
    6.  
  6. Check if everything works on the Hyl\u00e9ou explorer
    7.  
"},{"location":"developers/getting-started/amm/","title":"Amm","text":"
to be written.
"},{"location":"developers/getting-started/devnet/","title":"Devnet","text":""},{"location":"developers/getting-started/devnet/#devnet","title":"Devnet","text":"
Follow the instructions below to start building on Hyl\u00e9 by running a local devnet.
"},{"location":"developers/getting-started/devnet/#run-your-local-devnet","title":"Run your local devnet","text":""},{"location":"developers/getting-started/devnet/#recommended-getting-started-with-docker","title":"Recommended: Getting started with Docker","text":"
Failure
 
We currently don't have a public Docker image available. Please contact us if you need it.
 
Follow these instructions to run a node, keeping in mind that this is unstable and can break with upcoming updates.
 
Download the Docker image:
 
docker pull ghcr.io/hyle-org/hyle:latest\n
 
Run the image:
 
docker run -v ./db:/hyle/data -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
If you run into an error, you may want to add the --privileged flag:
 
docker run --privileged -v ./db:/hyle/data -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
If you want to run with an indexer with HYLE_RUN_INDEXER=true, you will need a running PostgreSQL server. You can set it up with Docker:
 
# For default conf:\ndocker run -d --rm --name pg_hyle -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres\n
 
You can customize the db URL with HYLE_DATABASE_URL, with the default value being: postgres://postgres:postgres@localhost:5432/postgres.
"},{"location":"developers/getting-started/devnet/#build-the-docker-image-locally","title":"Build the Docker image locally","text":"
If you want to, you can rebuild the image locally from source:
 
docker build -t Hyle-org/hyle . && docker run -dit Hyle-org/hyle\n
"},{"location":"developers/getting-started/devnet/#alternative-getting-started-from-source","title":"Alternative: Getting started from source","text":"
To start a single-node devnet (with consensus disabled), which is useful to build & debug smart contracts, run:
 
cargo build\nHYLE_RUN_INDEXER=false cargo run --bin node\n
"},{"location":"developers/getting-started/devnet/#configuration","title":"Configuration","text":"
You can configure your setup using environment variables or by editing a configuration file.
"},{"location":"developers/getting-started/devnet/#using-environment-variables","title":"Using environment variables","text":"
Here's an example of how you can configure your setup using environment variables:
 
HYLE_RUN_INDEXER=false \nHYLE_CONSENSUS__SLOT_DURATION=100\n
 
This is the default configuration for a node. All variables can be customized on your single-node instance.
 
Config(\n  id: \"node\",\n  single_node: true,\n  p2p_listen: true,\n  host: \"127.0.0.1:1231\",\n  peers: [],\n  storage: Storage(\n    interval: 10\n  ),\n  log_format: \"full\",\n  rest: \"127.0.0.1:4321\",\n  data_directory: \"data_node\",\n  database_url: \"postgres://postgres:postgres@localhost:5432/postgres\",\n  consensus: Consensus (\n    slot_duration: 1000,\n    // Has to be empty as config is additive\n    genesis_stakers: {}\n  ),\n  p2p: (\n    ping_interval: 10\n  ),\n  run_indexer: true,\n  da_address: \"127.0.0.1:4141\"\n)\n
"},{"location":"developers/getting-started/devnet/#using-a-configuration-file","title":"Using a configuration file","text":"
To use a configuration file, copy the default settings where you run the node. If a file named config.ron is present, it will be automatically loaded by the node at startup.
 
If you're using Docker:
 
docker run -v ./db:/hyle/data -v ./config.run:/hyle/config.ron -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
Then, whether you're using Docker or building from source:
 
# Copy default config where you run the node. If file named \"config.ron\" is present, it will be loaded by node at startup.\ncp ./src/utils/conf_defaults.ron config.ron\n
"},{"location":"developers/getting-started/erc20-and-identity/","title":"Erc20 and identity","text":"
to be written.
"},{"location":"developers/getting-started/identity-management/","title":"Identity management","text":"
a
"},{"location":"developers/getting-started/user-tooling/","title":"User tooling","text":""},{"location":"developers/getting-started/user-tooling/#user-tooling","title":"User tooling","text":""},{"location":"developers/getting-started/user-tooling/#clone-the-hyle-repository","title":"Clone the Hyl\u00e9 repository","text":"
Clone the Hyl\u00e9 repository.
 
git clone https://github.com/Hyle-org/hyle.git\n
"},{"location":"developers/getting-started/user-tooling/#recommended-install-the-cli","title":"Recommended: Install the CLI","text":"
You can install the CLI for easier access.
 
cargo install --path . --bin hyled\nhyled --help\n
"},{"location":"developers/getting-started/user-tooling/#alternative-use-the-cli-without-installing","title":"Alternative: Use the CLI without installing","text":"
To interact with the node, use the cli hyled:
 
cargo run --bin hyled -- --help\n
"},{"location":"developers/getting-started/user-tooling/#explorer","title":"Explorer","text":"
Explorer / Indexer: Hyl\u00e9ou. Read more about the explorer.
"},{"location":"developers/getting-started/your-first-erc20/","title":"Your first smart contract","text":""},{"location":"developers/getting-started/your-first-erc20/#your-first-smart-contract","title":"Your first smart contract","text":"
We'll use our sample ERC20-like contract hyllar as the basis for this tutorial.
 
Read more in our anatomy of a smart contract.
"},{"location":"developers/getting-started/your-first-erc20/#prerequisites","title":"Prerequisites","text":"
     
  • A working knowledge of zkVM basics.
    •  
  • Install Rust (you'll need rustup and Cargo).
    •  
  • Follow the CLI installation instructions. We are currently building utilities that will make it easier and faster to use our explorer, Hyl\u00e9ou.
    •  
  • Connect to devnet 
    •  
  • For our example, you'll need to install RISC Zero.
    •  
"},{"location":"developers/getting-started/your-first-erc20/#content-of-a-smart-contract","title":"Content of a smart contract","text":"
Hyl\u00e9 smart contracts include:
 
     
  • Owner: put anything you like. This field is currently not leveraged but will be in future versions.
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\").
    •  
  • Program ID: the unique identifier for your program in that proof system.
    •  
  • Contract name: the unique identifier for your contract.
    •  
  • State digest: current state commitment of the contract, usually a MerkleRootHash of the contract's state.
    •  
 
Read more about the anatomy of smart contracts on Hyl\u00e9.
"},{"location":"developers/getting-started/your-first-erc20/#start-your-devnet-and-install-our-cli","title":"Start your devnet and install our CLI","text":"
See our instructions on starting your devnet and downloading our CLI if not already done.
"},{"location":"developers/getting-started/your-first-erc20/#register-your-contract","title":"Register your contract","text":"
To register a contract on Hyl\u00e9, run the following command:
 
# Owner is currently unused, but could be used in the future to manage contract permissions\nhyled contract [owner] [verifier] [program_id] [contract_name] [state_digest]\n
 
Replace [owner], [verifier], [program_id], [contract_name], and [state_digest] with your specific details.
 
Warning
 
     
  • You need a unique contract_name.
    •  
  • The state digest cannot be empty, even if your app is stateless.
    •  
 
For our example:
 
     
  • owner: we put \u00ab default \u00bb as the owner, but you can put anything you like. This field is currently not leveraged; it will be in future versions.
    •  
  • verifier: for this example, the verifier is risc0
    •  
  • program_id: as RISC Zero programs are identified by their image ID, without a prefix, we use the number 0xe085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f. This will change every time the contract logic is modified.
    •  
  • contract_name: hyllar
    •  
  • state_digest: usually a MerkleRootHash of the contract's state. For this example, we'll use fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000, a hexadecimal representation of the state encoded in binary format.
    •  
 
For our example, the bash command looks like this:
 
hyled contract default risc0 e085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f hyllar fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000\n
"},{"location":"developers/getting-started/your-first-erc20/#check-your-contract","title":"Check your contract","text":"
In the explorer, this will look like this:
 
{\n    \"tx_hash\": \"321b7a4b2228904fc92979117e7c2aa6740648e339c97986141e53d967e08097\",\n    \"owner\": \"hyle\",\n    \"verifier\": \"risc0\",\n    \"program_id\":\"e085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f\",\n    \"state_digest\": \"fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000\",\n    \"contract_name\": \"hyllar\"\n}\n
"},{"location":"developers/getting-started/your-first-erc20/#interact-with-hyle","title":"Interact with Hyl\u00e9","text":"
Hyl\u00e9 transactions are settled in two steps, following pipelined proving principles.
 
     
  1. Publishing your blob: publish the blob of the final state.
    2.  
  2. Posting proof of your blob: publish proof of the final state.
    3.  
"},{"location":"developers/getting-started/your-first-erc20/#publishing-blobs","title":"Publishing blobs","text":"
The content of the blob is app-specific: it's the input of your program.
 
For Hyllar, this is a binary representation of the ERC20Action struct as defined in the contract.
 
# Create blob\nblob='{binary representation of the ERC20Action struct}'\n\n# Generate the proof in 'hyllar'\ncargo run reset $blob \nhyled blobs \"\" hyllar $(echo $blob | base64)\n
 
At this point, your transaction has been sequenced, but not settled.
"},{"location":"developers/getting-started/your-first-erc20/#posting-proofs-of-your-blob-to-settle-it","title":"Posting proofs of your blob to settle it","text":"
Hyl\u00e9 requires specific variables in the output of the proof to process the transaction. Check the smart contract ABI for more details.
 
Once your program conforms to the ABI, you can generate proofs and send them to Hyl\u00e9.
 
Each blob of a transaction must be proven separately for now, so you need to specify the index of the blob you're proving.
 
hyled proof [tx_hash] [contract_name] [proof]\n
 
In the case of the Hyllar program, we can now prove our state transition:
 
# Make sure the name matches the contract you registered\nhyled proof [tx_hash] hyllar [path_to_proof]\n
 
Hyl\u00e9 will now verify your proof. After verification, your transaction is settled, updating the state of the contract.
 
You can see your transaction on Hyl\u00e9's explorer: https://hyleou.hyle.eu/transaction/$TX_HASH
"},{"location":"developers/getting-started/your-first-erc20/#verifying-your-contracts-state","title":"Verifying your contract's state","text":"
Your contract's state digest is visible at: https://hyleou.hyle.eu/contract/$CONTRACT_NAME
 
You can choose to run the command below instead:
 
hyled state hyllar\n
"},{"location":"developers/getting-started/your-first-smart-contract/","title":"Your first smart contract","text":""},{"location":"developers/getting-started/your-first-smart-contract/#your-first-smart-contract","title":"Your first smart contract","text":"
You can use any zkVM or proving scheme supported by Hyl\u00e9.
 
We'll use the Collatz example as an example throughout this tutorial. See the Collatz page page for more information.
 
Read more in our anatomy of a smart contract.
"},{"location":"developers/getting-started/your-first-smart-contract/#prerequisites","title":"Prerequisites","text":"
     
  • A working knowledge of zkVM basics.
    •  
  • Install Rust (you'll need rustup and Cargo).
    •  
  • Connect to devnet 
    •  
  • Follow the CLI installation instructions. We are currently building utilities that will make it easier and faster to use our explorer, Hyl\u00e9ou.
    •  
  • For our example, you'll need to install RISC Zero.
    •  
"},{"location":"developers/getting-started/your-first-smart-contract/#registering-your-smart-contract","title":"Registering your smart contract","text":""},{"location":"developers/getting-started/your-first-smart-contract/#content-of-a-smart-contract","title":"Content of a smart contract","text":"
Hyl\u00e9 smart contracts include:
 
     
  • Owner: put anything you like. This field is currently not leveraged but will be in future versions.
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\").
    •  
  • Program ID: the unique identifier for your program in that proof system.
    •  
  • Contract name: the unique identifier for your contract.
    •  
  • State digest: current state commitment of the contract, usually a MerkleRootHash of the contract's state.
    •  
 
Read more about the anatomy of smart contracts on Hyl\u00e9.
"},{"location":"developers/getting-started/your-first-smart-contract/#register-your-contract","title":"Register your contract","text":"
To register a contract on Hyl\u00e9, run the following command:
 
# Owner is currently unused, but could be used in the future to manage contract permissions\nhyled contract [owner] [verifier] [program_id] [contract_name] [state_digest]\n
 
Replace [owner], [verifier], [program_id], [contract_name], and [state_digest] with your specific details.
"},{"location":"developers/getting-started/your-first-smart-contract/#for-collatz","title":"For Collatz","text":"
In the case of the Collatz Conjecture example, as RISC Zero programs are identified by their image ID, without a prefix, we use the number 0xb48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b. This will change every time the contract logic is modified.  
 
The initial state is set to \"1\", so that it can be reset to any number. This is encoded in base 64 as AAAAAQ== because of the Rust library used to decode the state.
 
Note that you need a unique contract_name. If you try to test this example on the public devnet, we recommend putting a name that's not \u00ab collatz \u00bb.
 
For our example, the bash command looks like this:
 
hyled contract default risc0 b48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b collatz AAAAAQ==\n
 
(We put \u00ab default \u00bb as the owner, but you can put anything you like. This field is currently not leveraged; it will be in future versions.)
"},{"location":"developers/getting-started/your-first-smart-contract/#checking-your-contract","title":"Checking your contract","text":"
In the explorer, this will look like this:
 
{\n    \"tx_hash\": \"ebecbf7458370d656772369df4a76c343b050e3fdbe4c1ceb7d54175ce290b60\",\n    \"owner\": \"default\",\n    \"verifier\": \"risc0\",\n    \"program_id\": [\n        b48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b\n    ],\n    \"state_digest\": [\n        AAAAAQ==\n    ],\n    \"contract_name\": \"collatz\"\n}\n
"},{"location":"developers/getting-started/your-first-smart-contract/#interacting-with-hyle","title":"Interacting with Hyl\u00e9","text":"
Hyl\u00e9 transactions are settled in two steps, following pipelined proving principles.
 
     
  1. Publishing payloads: send the input of your program to the network.
    2.  
  2. Posting proof of your payload: generate and submit proofs validating your payload so Hyl\u00e9 will settle your transaction.
    3.  
"},{"location":"developers/getting-started/your-first-smart-contract/#publishing-payloads","title":"Publishing payloads","text":"
The content of the payload is app-specific: it's the input of your program.
 
For the Collatz conjecture, this is a number encoded as a big-endian 32-bit integer.
 
payload='\\x00\\x00\\x00\\x05'\n# Generate the proof in 'collatz-contract'\ncargo run reset $payload\nhyled blobs \"\" collatz $(echo $payload | base64)\n# the \"\" is a placeholder for identity: it's empty, as Collatz doesn't handle identity\n
 
You can see your transaction on Hyl\u00e9's explorer: https://hyleou.hyle.eu/transaction/$TX_HASH
 
At this point, your transaction has been sequenced, but not settled.
"},{"location":"developers/getting-started/your-first-smart-contract/#posting-proofs-of-your-payload-to-settle-it","title":"Posting proofs of your payload to settle it","text":"
Hyl\u00e9 requires specific variables in the output of the proof to process the transaction. Check the smart contract ABI for more details.
 
Once your program conforms to the ABI, you can generate proofs and send them to Hyl\u00e9.
 
Each payload of a transaction must be proven separately for now, so you need to specify the index of the payload you're proving.
 
hyled proof [tx_hash] [contract_name] [proof]\n
 
In the case of the Collatz Conjecture program, we can now prove our state transition from 1 to 5.
 
# Make sure the name matches the contract you registered\nhyled proof [tx_hash] collatz [path_to_proof]\n
 
Hyl\u00e9 will now verify your proof. After verification, your transaction is settled, updating the state of the contract.
"},{"location":"developers/getting-started/your-first-smart-contract/#verifying-your-contracts-state","title":"Verifying your contract's state","text":"
Your contract's state digest is visible at: https://hyleou.hyle.eu/contract/$CONTRACT_NAME
 
You can choose to run the command below instead:
 
hyled state collatz\n
"},{"location":"resources/","title":"\ud83d\udcda Resources","text":"
     
  • Introduction to zero-knowledge proofs
    •  
  • Roadmap
    •  
  • Find us
    •  
  • Grants
    •  
"},{"location":"resources/find-us/","title":"Find us","text":""},{"location":"resources/find-us/#useful-links","title":"Useful links","text":"
     
  • Rust node
    •  
  • Hyle.eu
    •  
  • Hyl\u00e9 blog
    •  
"},{"location":"resources/find-us/#contact-us","title":"Contact us","text":"
Reach out to the team for more information:
  Github  Twitter  Farcaster  LinkedIn  Youtube  Telegram Hyl\u00e9 @hyle_org @hyle-org Hyl\u00e9 @Hyl\u00e9 @hyle_org"},{"location":"resources/grants/","title":"Grants","text":"
We have a grant program supporting developers who want to work on trust infrastructure and programmable cryptography on Hyl\u00e9.
"},{"location":"resources/grants/#what-are-our-grants-like","title":"What are our grants like?","text":"
     
  • You apply with an original idea or an idea from the list on our repo.
    •  
  • We fund your project. You get some money upfront, so you can build without financial worries, and the rest upon completion of the project.
    •  
  • You meet regularly with our CEO for guidance and to help you refine your ideas.
    •  
  • You are in a Telegram group with our other grantees to share ideas and solutions.
    •  
  • Our tech team supports you via Telegram and in meetings.
    •  
  • Our business team helps you showcase your idea through external speaking opportunities, co-marketing, and other assets.
    •  
 
To read more, see our grant ideas, and apply, please go to our Grants page on the main Hyl\u00e9 repository.
 
For questions that aren't answered on the Grants page, reach out in our Telegram group.
"},{"location":"resources/grants/#current-and-past-grants","title":"Current and past grants","text":"
Here are two past grants:
 
     
  • Provable play-by-email games library
    •  
  • Proof of residency app
    •  
 
Find the full list on our Grants page on the main Hyl\u00e9 repository.
"},{"location":"resources/intro-to-zkp/","title":"Understanding zero-knowledge proofs","text":"
Here are some resources on zero-knowledge proofs and how to generate them.
"},{"location":"resources/intro-to-zkp/#when-to-use-zero-knowledge-proofs","title":"When to use zero-knowledge proofs","text":"
There are three moments when ZK is the right tool for you:
 
     
  • Computing power imbalance (which includes improved scalability): I can verify a result without running the resource-heavy computation.
    •  
  • Adversarial environment: I can verify a result without knowing trade secrets that attained this result.
    •  
  • Anonymity: I share only the information I want to share.
    •  
"},{"location":"resources/intro-to-zkp/#how-to-use-zero-knowledge-proofs","title":"How to use zero-knowledge proofs","text":"
There are many ZK languages. Hyl\u00e9 aims to verify as many as possible.
 
DSLs are specific languages that usually compile down to a specific circuit. They're good, but they're complex and may have a high learning curve.
 
zkVMs prove the correct execution of arbitrary code. They allow you to build ZK applications in a certain language without having to build a circuit around it. There are two main types of zkVMs: Cairo and RISC-V. You can benchmark your Rust code and find the best zkVM for your needs with the any-zkvm template.
 
We currently support RISC\u2013V-based zkVMs Risc0 and SP1 and will support more types, including Cairo-based zkVMs and DSLs, in the future.
"},{"location":"resources/intro-to-zkp/#read-more","title":"Read more","text":"
     
  • awesome-zk link repository on GitHub
    •  
  • Hyl\u00e9's very simple introduction to zero-knowledge proofs
    •  
  • Lauri Peltonen's blog series on ZK
    •  
"},{"location":"resources/roadmap/","title":"Roadmap","text":"
We do not have a public roadmap at this time. Stay tuned for updates or ask specific questions in our Telegram group.
"},{"location":"resources/roadmap/#testnet","title":"Testnet","text":"
We will release our testnet in early 2025.
 
While we\u2019re working towards launching the testnet, you can get hands-on right now:
 
     
  • Explore our public devnet or spin up your own instance to start building today!
    •  
"},{"location":"resources/roadmap/#proving-schemes","title":"Proving schemes","text":"
Check the list of the proving schemes we currently support and the ones we'll work on next.
"},{"location":"use-cases/","title":"\ud83d\udca1 Use cases","text":""},{"location":"use-cases/#use-cases","title":"\ud83d\udca1 Use cases","text":"
The Use cases section of the Hyl\u00e9 documentation shows how to use Hyl\u00e9 in different scenarios.
 
Use cases include:
 
     
  • Hyl\u00e9 for play-by-email provable games
    •  
  • Hyl\u00e9 for account abstraction
    •  
  • Hyl\u00e9 for age verification
    •  
  • Hyl\u00e9 for proof of residency
    •  
  • Hyl\u00e9 for the European Union?
    •  
 
If you are interested in other use cases and would like to explore them with us, you might be interested in our grants program!
"},{"location":"use-cases/for-identity-providers/","title":"Hyl\u00e9 for Identity Providers","text":""},{"location":"use-cases/for-identity-providers/#hyle-for-identity-providers","title":"Hyl\u00e9 for Identity Providers","text":"
Hyl\u00e9 does not specify what an \"account\" is, or even what identity particularly means. This gives it unprecedented flexibility in handling identity, including:
 
     
  • EOAs like Ethereum native wallets
    •  
  • Smart accounts of any kind
    •  
  • Regular web2 identity
    •  
  • Passports & other national identity documents.
    •  
 
Warning
 
You are entering TODO area, none of this is currently implemented.
 
Hyl\u00e9 handles identity relying on the caller contract in a multicall.
 
When a user crafts a transaction, their first call should be a proof-of-identity, for example a call to the native /eth smart contract, which validates Ethereum-like EOA signatures.
 
Any subsequent call will see that the user is indeed the owner of an /eth address, e.g. 0xfoobar/eth and will be able to use that address name trustlessly.
"},{"location":"use-cases/for-identity-providers/#registering-your-own-stateless-identity-provider","title":"Registering your own stateless identity provider","text":"
A stateless identity provider such as the Ethereum EOA smart contract has two components:
 
     
  • A smart contract registered on Hyl\u00e9, authenticating proofs
    •  
  • A client-side library that can craft proofs
    •  
 
See the Ethereum EOA smart contract for an example of such a provider.
"},{"location":"use-cases/for-identity-providers/#adding-support-for-your-smart-wallet","title":"Adding support for your smart wallet","text":""},{"location":"use-cases/for-identity-providers/#registering-a-stateful-private-identity-provider","title":"Registering a stateful, private identity provider","text":"
This can be used by games, SSO providers, or any other use-case that needs to handle user identity in a more traditional way.
"},{"location":"use-cases/for-zk-apps/","title":"Hyl\u00e9 for ZKApps","text":""},{"location":"use-cases/for-zk-apps/#hyle-for-zkapps","title":"Hyl\u00e9 for ZKApps","text":"
Hyl\u00e9 is a full featured settlement layer, providing fast finality and cheap TX cost. This makes it a great fit for use-cases that would require appchains or L3s in other ecosystems.
"},{"location":"use-cases/for-zk-apps/#registering-your-smart-contract","title":"Registering your smart contract","text":"
See Your First Smart Contract for details.
"},{"location":"use-cases/for-zk-apps/#bring-your-own-accounts","title":"Bring your own accounts","text":"
See Hyl\u00e9 for Identity Providers
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":""},{"location":"#home","title":"Home","text":"
Hyl\u00e9 is a lean blockchain that lets you easily take your provable application onchain.
 
Note
 
This developer portal and the project itself are still evolving. Join us on Telegram if you need assistance or wish to provide feedback. Issues and PRs on this documentation's GitHub repository are also very welcome!
"},{"location":"#why-choose-hyle","title":"Why choose Hyl\u00e9","text":"
     
  • Native zero-knowledge proof verification on our sovereign L1: we're fast and lean.
    •  
  • No onchain execution or virtual machine needed: only efficient proof verification.
    •  
  • Run complex logic offchain and only submit proofs onchain for maximum scalability.
    •  
  • Proof composability: seamlessly combine multiple proofs into single, verifiable transactions.
    •  
  • Pipelined proving: send provable blobs, don't worry about proving times.
    •  
  • Choose your proving scheme and your language: we verify all proofs.
    •  
"},{"location":"#how-hyle-works","title":"How Hyl\u00e9 works","text":"
Here\u2019s what happens when you use Hyl\u00e9\u2019s sovereign verification-focused Layer 1:
 
 
     
  1. Sequencing: Send a provable blob to Hyl\u00e9: say what information you expect to prove later. We'll sequence the transaction immediately. Read more about pipelined proving.
    2.  
  2. Proof submission: when the proofs for your transaction are ready, send them to Hyl\u00e9.
    3.  
  3. Verification: Hyl\u00e9 validators receive the transaction. They verify the proofs natively, without the limitations of a bulky virtual machine.
    4.  
  4. Consensus: if the proofs are valid, Hyl\u00e9 settles your transaction's state onchain. You're good to go!
    5.  
 
With this system, execution and storage happen anywhere you like. You only need a fast and trustworthy verifier: that\u2019s Hyl\u00e9.
"},{"location":"#documentation","title":"Documentation","text":"
     
  • Get started now
    •  
  • Learn more about Hyl\u00e9
    •  
  • Check out examples
    •  
"},{"location":"#links","title":"Links","text":"
     
  • Rust node
    •  
  • Hyle.eu
    •  
  • Hyl\u00e9 blog
    •  
 
Reach out to the team for more information:
  Github  Twitter  Farcaster  LinkedIn  Youtube  Telegram Hyl\u00e9 @hyle_org @hyle-org Hyl\u00e9 @Hyl\u00e9 @hyle_org"},{"location":"developers/","title":"\ud83d\udc69\u200d\ud83d\udcbb Developer documentation","text":""},{"location":"developers/#developer-documentation","title":"\ud83d\udc69\u200d\ud83d\udcbb Developer documentation","text":"
Welcome to the developer documentation for Hyl\u00e9!
 
     
  • Quickstart
    •  
  • General documentation about Hyl\u00e9
    •  
  • Explorer
    •  
  • Annotated examples
    •  
"},{"location":"developers/explorer/","title":"Explorer","text":"
Hyl\u00e9ou (a French pun for \"Il est o\u00f9\" or \"Where is it?\") is the blockchain explorer for the Hyl\u00e9 ecosystem.
 
The explorer is live at hyleou.hyle.eu.  
 
The source code is available on GitHub. We welcome PRs and issues!
"},{"location":"developers/explorer/#features","title":"Features","text":"
All features are in active development. 
"},{"location":"developers/explorer/#live-features","title":"Live features","text":"
Currently, you can:
 
     
  • View the latest blocks
    •  
  • View the latest transactions.
    •  
  • View detailed information about specific blocks and transactions.
    •  
"},{"location":"developers/explorer/#upcoming-features","title":"Upcoming features","text":"
Planned features include:
 
     
  • Register new contracts.
    •  
  • Send transactions by uploading ZK proofs to specific contracts (multicall not yet supported).
    •  
"},{"location":"developers/examples/","title":"Examples","text":""},{"location":"developers/examples/#examples","title":"Examples","text":"
Detailed examples of Hyl\u00e9-based applications.
"},{"location":"developers/examples/#sample-contracts-in-hyle","title":"Sample contracts in Hyl\u00e9","text":"
We have three Hyl\u00e9-made Risc0 smart contracts :
 
     
  • hydentity: Basic identity provider
    •  
  • hyllar: Simple ERC20-like contract
    •  
  • amm: Simple AMM contract
    •  
  • risc0 recursion
    •  
  • WIP: staking
    •  
 
There is also a CLI called hyrun to execute those contracts, generate proofs, etc.
"},{"location":"developers/examples/#code-examples","title":"Code examples","text":"
     
  • Collatz example on Hyl\u00e9, using SP1, Noir, or Groth16
    •  
"},{"location":"developers/examples/#demos-and-provable-apps","title":"Demos and provable apps","text":"
Demos:
 
     
  • Vibe Check: a zkML app.
    •  
 
Our grantees have worked on Hyl\u00e9-based projects. Check them out for inspiration on building provable apps!
"},{"location":"developers/examples/amm/","title":"AMM","text":""},{"location":"developers/examples/amm/#amm","title":"AMM","text":"
The Hyl\u00e9 AMM is a decentralized Automated Market Maker (AMM) built on the Hyl\u00e9 protocol. It showcases how Hyl\u00e9 can be used for efficient, scalable, and secure decentralized trading.
"},{"location":"developers/examples/amm/#overview","title":"Overview","text":"
The AMM simplifies decentralized trading through a constant function market maker model. Developers can leverage its architecture to integrate trading functionalities within their dApps.
 
Key highlights include:
 
     
  • Scalability: Supports high throughput and low-latency transactions, even under heavy network usage.
    •  
  • Composability: you can use it to interact with your own provable applications.
    •  
"},{"location":"developers/examples/amm/#links","title":"Links","text":"
     
  • Front-end and back-end
    •  
  • Contracts
    •  
"},{"location":"developers/examples/collatz-example-in-depth/","title":"Collatz example","text":""},{"location":"developers/examples/collatz-example-in-depth/#collatz-example","title":"Collatz example","text":"
Hyl\u00e9 smart contracts can be written in any language that targets one of our supported proving schemes.
 
On this page, we'll use the RISC Zero Collatz Conjecture program, which can be found in our examples repository.
"},{"location":"developers/examples/collatz-example-in-depth/#what-is-the-collatz-conjecture","title":"What is the Collatz conjecture?","text":"
The Collatz conjecture is a simple mathematical problem that can be expressed as a program.  
 
The conjecture states that, for any positive integer n:
 
     
  • if n is even, divide it by 2
    •  
  • if n is odd, multiply it by 3 and add 1
    •  
  • repeat this process, and you will eventually reach 1.
    •  
 
The program is implemented in Rust, and compiles to the RISC Zero zkVM.
"},{"location":"developers/examples/collatz-example-in-depth/#compiling-the-program","title":"Compiling the program","text":"
To compile the program, you will need to have the RISC Zero toolchain installed. Follow the official instructions to get the most up-to-date information.
 
To use RISC Zero, you'll need to compile with
 
cargo build --features risc0\n
 
The matching binary is risc0-runner.
 
Run cargo risczero build to build smart contract.
"},{"location":"developers/examples/collatz-example-in-depth/#running-the-collatz-conjecture-program","title":"Running the Collatz Conjecture program","text":"
Hyl\u00e9 smart contracts can be executed client-side, enabling strong decentralization and permissionlessness.
 
To execute the smart contract, run the program with correct inputs.
"},{"location":"developers/examples/collatz-example-in-depth/#generate-a-proof","title":"Generate a proof","text":""},{"location":"developers/examples/collatz-example-in-depth/#prove-the-transition-from-x-to-the-next-number","title":"Prove the transition from X to the next number","text":"
# Generate a proof of the transition from X to the next number in the Collatz conjecture\ncargo run next X\n# Or do it reproducibly\ncargo run -- -r next X\n
 
Here are some concrete examples:
 
# Compute a proof of a transition between the number 12 and 6\ncargo run next 12\n\n# Compute a proof of a transition between the number 17 and 52\ncargo run next 17\n
"},{"location":"developers/examples/collatz-example-in-depth/#reset-to-x","title":"Reset to X","text":"
# Reset to X, assuming the current number is a 1\ncargo run reset X\n# Or do it reproducibly\ncargo run -- -r reset X\n
 
Here is one concrete example:
 
# Reset the state from 1 to 31\ncargo run reset 31\n
"},{"location":"developers/examples/collatz-example-in-depth/#invalid-transitions","title":"Invalid transitions","text":"
The Collatz smart contract demonstrates how the code of the smart contract enforces constraints on the state:
 
     
  • You can't generate valid proofs of transition between numbers that are not part of the Collatz sequence.
    •  
  • The contract will reject attempts to reset to 0, as there would no longer be any next state.
    •  
"},{"location":"developers/examples/collatz-example-in-depth/#use-the-proof","title":"Use the proof","text":"
Every time, a proof.json file containing the receipt will be generated. You can use this proof, along with the inputs, to trigger state transitions on Hyl\u00e9. Read more: Your first smart contract.
"},{"location":"developers/examples/collatz-example-in-depth/#verify-the-proof","title":"Verify the proof","text":"
Coming next.
"},{"location":"developers/examples/vibe-check/","title":"Vibe Check","text":""},{"location":"developers/examples/vibe-check/#vibe-check","title":"Vibe Check","text":"
The general idea of the Vibe Check app is to give people a SmileToken to reward them for smiling.
 
Watch Sylve's demo at ETHCC[7].
 
Find the code in the dedicated GitHub repository.
"},{"location":"developers/examples/vibe-check/#context","title":"Context","text":"
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.  
    2. Vibe Check runs the Noir prover in-browser.
      3.  
    3. The prover generates a Noir proof that the Webauthn-signature is correct.
      4.  
     
    2.  
  2. I take a selfie where I\u2019m smiling to generate a proof of my shiny, bubbly personality.
       
    1. Vibe Check uses a machine-learning model.
      2.  
    2. I send my selfie to this Cairo program.
      3.  
    3. The machine-learning model checks that I am smiling.
      4.  
    4. If I am smiling, the Cairo-prover generates a proof.
      5.  
     
    3.  
  3. Vibe Check gives me a SmileToken.
       
    1. Vibe Check locally updates the state of the SmileToken.
      2.  
    2. Vibe Check generates a Cairo proof that the state transition was done correctly.
      3.  
     
    4.  
  4. Hyl\u00e9 verifies the proofs.
       
    1. Hyl\u00e9 updates the SmileToken state if everything is correct. If so, I am rewarded with that SmileToken to congratulate me for my good vibes.
      2.  
     
    5.  
"},{"location":"developers/examples/vibe-check/#how-it-works","title":"How it works","text":""},{"location":"developers/examples/vibe-check/#understanding-the-components-of-the-demo","title":"Understanding the components of the demo","text":"
The Vibe Check demo consists of three components: the app, the proof, and the Hyl\u00e9 node.
"},{"location":"developers/examples/vibe-check/#the-app","title":"The app","text":"
The app helps the user craft a transaction through 2 interactions:
 
     
  • Identification with WebAuthn for a proof of ID
    •  
  • Photo of the user smiling for a proof of smile
    •  
 
The app prepares for proof generation; it also sends a blob of this transaction to Hyl\u00e9, so Hyl\u00e9 can sequence it and knows to expect upcoming proofs.
"},{"location":"developers/examples/vibe-check/#the-prover","title":"The prover","text":"
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.  
  2. Proof of smile: running the machine-learning model in Cairo
    3.  
  3. Token (ERC-20) transfer: initiated in Cairo if the first two proofs are valid.
    4.  
 
The app sends the three proofs to the Hyl\u00e9 node.
 
The Hyl\u00e9 node:
 
     
  1. Unpacks the three proofs.
    2.  
  2. Verifies each proof with the correct verifier: Noir for WebAuthn and Cairo for the two others.
    3.  
  3. Ensures consistency by checking the public data contained in the proofs to ensure they all relate to the same transaction.
    4.  
 
"},{"location":"developers/examples/vibe-check/#multiple-proving-schemes","title":"Multiple proving schemes","text":"
In Vibe Check, we use Noir and Cairo and we leverage proof composability
"},{"location":"developers/examples/vibe-check/#the-actual-code","title":"The actual code","text":"
Find the code in the dedicated GitHub repository!
"},{"location":"developers/general-doc/","title":"General documentation","text":"
Welcome to the developer documentation for Hyl\u00e9.
 
You can also refer to our Getting Started step-by-step guide.
"},{"location":"developers/general-doc/anatomy-smart-contracts/","title":"Smart contracts on Hyl\u00e9","text":""},{"location":"developers/general-doc/anatomy-smart-contracts/#smart-contracts-on-hyle","title":"Smart contracts on Hyl\u00e9","text":"
Hyl\u00e9 is a fully programmable blockchain that optimizes data storage by keeping only the essential information needed to validate smart contract proofs. This design ensures that Hyl\u00e9 smart contracts are lightweight and efficient.
 
Hyl\u00e9 smart contracts include:
 
     
  • Name: the unique identifier for your contract
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\")
    •  
  • Program ID: the unique identifier for your program in that proof system
    •  
  • State digest: current state commitment of the contract
    •  
 
Depending on the type of zk-proof circuits you use, there are some superficial differences, but the overall idea is that all inputs are known at proof generation time.
 
This page uses the Rust structures to demonstrate, but you can use the following repos for other languages:
 
     
  • Rust example: https://github.com/Hyle-org/collatz-conjecture
    •  
  • Gnark / Groth16 example (outdated): https://github.com/Hyle-org/groth16-example
    •  
"},{"location":"developers/general-doc/anatomy-smart-contracts/#name","title":"Name","text":"
The name of your contract must be unique.
"},{"location":"developers/general-doc/anatomy-smart-contracts/#verifier-and-program-identifier","title":"Verifier and program identifier","text":"
Smart contracts on Hyl\u00e9 rely on a pairing of a zero-knowledge proof scheme (verifier) and a program identifier. Together, these components validate contract proofs.
 Proving scheme Verifier Program ID Risc Zero risc0 Image ID without a prefix. ex. 0x123 becomes 123. SP1 sp1"},{"location":"developers/general-doc/anatomy-smart-contracts/#state-digest","title":"State digest","text":"
The state digest is a minimal yet comprehensive representation of the contract's current state. It serves as the basis for verifying the integrity of the contract's data.
 
Some examples of valid state commitments:
 
     
  • The full state, for a sufficiently small program (e.g. the Collatz example, or a smart-contract with a nonce)
    •  
  • A merkle root of the state, for larger programs
    •  
  • A hash of the full state
    •  
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/","title":"Hyl\u00e9 vs. vintage blockchains","text":""},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#hyle-vs-vintage-blockchains","title":"Hyl\u00e9 vs. vintage blockchains","text":"
If you're used to traditional blockchains such as Ethereum or Solana, keep these Hyl\u00e9 characteristics in mind.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#no-evm-or-execution-layer","title":"No EVM or execution layer","text":"
Hyl\u00e9 does not include a Virtual Machine.
 
There is no dedicated execution engine or specific programming language (like Solidity) you should use.
 
Our approach is simple: onchain, we verify zero-knowledge proofs natively. Offchain, you do everything else, the way you prefer.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#no-onchain-state","title":"No onchain state","text":"
The network maintains proofs of state transitions rather than the entire onchain state.
 
Transactions on Hyl\u00e9 verify and settle transitions without storing full intermediary states onchain.
 
This architecture reduces storage overhead and promotes scalability while maintaining trustlessness.
"},{"location":"developers/general-doc/hyle-vs-vintage-blockchains/#privacy-is-built-in","title":"Privacy is built-in","text":"
Unlike Ethereum, where privacy solutions must be implemented on top of the platform, Hyl\u00e9 integrates privacy features natively.
 
The proof is public, but your inputs don't need to be, as execution happens offchain.
"},{"location":"developers/general-doc/pipelined-proving/","title":"Pipelined proving","text":""},{"location":"developers/general-doc/pipelined-proving/#pipelined-proving","title":"Pipelined proving","text":""},{"location":"developers/general-doc/pipelined-proving/#the-problem-base-state-conflicts","title":"The problem: base state conflicts","text":"
Hyl\u00e9 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 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:
 
     
  • Proof generation latency
    •  
  • Timekeeping: proofs require accurate time information, but users can't predict when their transaction will be sequenced.
    •  
  • Parallelization: proofs must include valid state transitions, but multiple transactions can accidentally reference the same base state.
    •  
 
We solve these issues by splitting sequencing from settlement; an operation includes two transactions.
"},{"location":"developers/general-doc/pipelined-proving/#blob-transaction-vs-proof-transaction","title":"Blob-transaction vs. Proof-transaction","text":"
Hyl\u00e9 splits operations into two transactions:
 
     
  1. Blob-transaction: outlines a state change for sequencing.
    2.  
  2. Proof-transaction: provides a proof for the claimed state change for settlement.
    3.  
 
From Hyl\u00e9\u2019s 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.
    2.  
  2. Settlement happens when the corresponding proof transaction is verified and added to the block.
    3.  
 
During settlement, proved blob transactions linked to the contract are executed in their sequencing order.
 
"},{"location":"developers/general-doc/pipelined-proving/#unprovable-transactions","title":"Unprovable transactions","text":"
Hyl\u00e9 introduces timeouts for blob transactions to ensure timely proof submissions.
 
Transactions without proofs within a specific duration, as well as transactions with invalid proofs, are rejected.
"},{"location":"developers/general-doc/proof-composability/","title":"Proof composition and cross-contract calls","text":""},{"location":"developers/general-doc/proof-composability/#proof-composition-and-cross-contract-calls","title":"Proof composition and cross-contract calls","text":"
To understand the concept of proof composability on Hyl\u00e9, we recommend you read this blog post. This page focuses on demonstrating how to use proof composition in your code.
"},{"location":"developers/general-doc/proof-composability/#what-is-proof-composition","title":"What is proof composition?","text":"
Proof composition happens when two contracts depend on each other. Proof composability is the fact that Hyl\u00e9 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.
    •  
 
Hyl\u00e9 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.
"},{"location":"developers/general-doc/proof-composability/#writing-a-cross-contract-call","title":"Writing a cross-contract call","text":"
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.
    •  
 
Follow these steps:
 
     
  1. Inject claims: add all the claims as inputs to the blob.
    2.  
  2. Index claims: provide an index to tell the contract where to locate its input.
    3.  
  3. Assert claims: use the claim list to validate the required conditions for the blob.
    4.  
"},{"location":"developers/general-doc/proof-composability/#how-hyle-settles-multiple-proofs","title":"How Hyl\u00e9 settles multiple proofs","text":"
When you submit multiple proofs to Hyl\u00e9:
 
     
  • 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. As soon as one proof is ready, it can be verified on Hyl\u00e9, even if the other proofs aren't ready yet.
    •  
  • Once all proofs related to the transaction are verified, the transaction is settled on Hyl\u00e9. If one proof verification fails, then the entire transaction fails.
    •  
 
Read more on our blog.
"},{"location":"developers/general-doc/run-a-node/","title":"Run a node","text":""},{"location":"developers/general-doc/run-a-node/#run-a-node","title":"Run a node","text":"
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:
 
docker pull europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main\n
 
Then run the image:
 
docker run --name [container_name] -d [options] europe-west3-docker.pkg.dev/hyle-413414/hyle-docker/hyle:main\n
 
And rebuild the node from the source:
 
docker build -t Hyle-org/hyle . && docker run -dit Hyle-org/hyle\n
"},{"location":"developers/general-doc/smart-contract-abi/","title":"Smart Contract ABI","text":""},{"location":"developers/general-doc/smart-contract-abi/#smart-contract-abi","title":"Smart Contract ABI","text":"
Hyl\u00e9 focuses on verifying zk-proofs. Because of this, writing smart contracts on Hyl\u00e9 has some specificities, with other elements being the same as with most other blockchains.
 
Depending on the type of zk-proof circuits you use, there are some superficial differences, but the overall idea is that all inputs are known at proof generation time. This includes unusual elements such as the origin of the transaction (tx.origin in Ethereum) and the block number.
 
The Hyl\u00e9 protocol enforces several invariants on transactions to maximize security. For this reason, we must specify some of the data within a zero-knowledge proof.
 
This page uses the Rust structures to demonstrate, but you can use the following repos for other languages:
 
     
  • Rust example: https://github.com/Hyle-org/collatz-conjecture
    •  
  • Gnark / Groth16 example (outdated): https://github.com/Hyle-org/groth16-example
    •  
"},{"location":"developers/general-doc/smart-contract-abi/#overview","title":"Overview","text":"
Here is the rust struct specifying the output of a Hyl\u00e9 smart contract:
 
pub struct HyleOutput<T> {\n    pub version: u32,\n    pub initial_state: Vec<u8>,\n    pub next_state: Vec<u8>,\n    pub identity: String,\n    pub tx_hash: Vec<u8>,\n    pub payload_hash: Vec<u8>,\n    pub success: bool,\n    pub program_outputs: T\n}\n
 
The version field should currently be set to 1.
"},{"location":"developers/general-doc/smart-contract-abi/#initial-state-and-next-state","title":"Initial State and Next State","text":"
Blockchains transactions are fundamentally state transitions. These fields handle the state transitions securely in the protocol.
 
The initial_state field should match the state digest of the contract before the transaction. This could consist of several things, such as:
 
     
  • the hash of the previous state
    •  
  • the Merkle root of the previous state tree
    •  
  • the state itself if it's small enough
    •  
 
The protocol enforces that this initial_state matches the onchain state_digest it knows. Otherwise, the state transition is invalid.
 
The next_state field represents the new onchain state_digest after the transaction.
 
Smart contracts can adapt the actual structure of this field. In the future, fees will depend on the size of the state_digest (among other criteria), so we encourage you to keep it small.
"},{"location":"developers/general-doc/smart-contract-abi/#identity","title":"Identity","text":"
The identity field is the identifier of the person who initiated the transaction.
 
Unlike other blockchains, Hyl\u00e9 does not have a native signature type. Instead, Hyl\u00e9 uses the identity field of the first proof to identify the TX sender. To ensure security, the field is composite and ends with the name of the contract that the proof was generated for.
 
Hyl\u00e9 could for example support Ethereum EOAs, if a smart contract is registered onchain to verify them. The identity would then look something like 0x1234...5678.eth_eoa, where eth_eoa is the name of the contract, and the first part matches a regular Ethereum address.
 
This gives us massive flexibility in the future to support any kind of identity verification, including WebAuthn, social media accounts, etc.
 
For now, any subsequent proof in a TX must declare the same identity or an empty one, or the transaction will be rejected.
"},{"location":"developers/general-doc/smart-contract-abi/#tx-hash","title":"TX Hash","text":"
The tx_hash field is intended to hash transaction data, preventing replay attacks and providing a means for contracts to access this information.
 
The field is currently completely unspecified and isn't validated by the protocol.
"},{"location":"developers/general-doc/smart-contract-abi/#payload-hash","title":"Payload Hash","text":"
This should match the hash of the payload that was sent to the network initially. Currently we use pedersen hashing for Cairo, no hashing for Risc0. Others are unimplemented. This is very WIP (as of August 2024) and will change soon.
"},{"location":"developers/general-doc/smart-contract-abi/#success","title":"Success","text":"
This is a boolean - whether the proof is for a succesful proof or a failure case. It can be useful to prove that a transaction is invalid. See our example in Vibe Check.
"},{"location":"developers/general-doc/smart-contract-abi/#other-program-specific-outputs","title":"Other program-specific outputs","text":"
Smart contracts can provide other outputs as part of the proof they generate.
 
This can be used for a variety of purposes, but mostly serves to provide Data Availability.
"},{"location":"developers/general-doc/smart-contract-abi/#events","title":"Events","text":"
Hyl\u00e9 does not currently ship native events. We are looking into implementing them in the near future.
"},{"location":"developers/general-doc/supported-proving-schemes/","title":"Proving schemes","text":""},{"location":"developers/general-doc/supported-proving-schemes/#proving-schemes","title":"Proving schemes","text":"
Proving schemes are the cryptographic protocols that make zero-knowledge proofs usable.
 
We support as many as we can, giving you the flexibility to choose the most suitable protocol for your specific use case.
"},{"location":"developers/general-doc/supported-proving-schemes/#supported-proving-schemes","title":"Supported proving schemes","text":"
As of December 2024, Hyl\u00e9 currently supports the following zero-knowledge proving schemes:
 
     
  • Noir
    •  
  • Risc0
    •  
  • SP1
    •  
"},{"location":"developers/general-doc/supported-proving-schemes/#planned-future-support","title":"Planned future support","text":"
We plan to eventually support all major proving schemes.
 
The next proving schemes we're aiming to support are:
 
     
  • Cairo via Stwo
    •  
  • Groth16
    •  
"},{"location":"developers/getting-started/","title":"Getting started","text":"
Welcome to the Getting Started guide for Hyl\u00e9.
 
This page will help you configure your environment and start using Hyl\u00e9.
 
Use the sidebar to navigate through the guide, or click on the links below to jump to a specific section:
 
     
  1. Run your local devnet
    2.  
  2. Use our tools
    3.  
  3. Create your first smart contract
    4.  
  4. Get inspiration from our in-depth Collatz example
    5.  
  5. Understand Hyl\u00e9's smart contract ABI
    6.  
  6. Check if everything works on the Hyl\u00e9ou explorer
    7.  
"},{"location":"developers/getting-started/amm/","title":"Amm","text":"
to be written.
"},{"location":"developers/getting-started/devnet/","title":"Run your local devnet","text":""},{"location":"developers/getting-started/devnet/#run-your-local-devnet","title":"Run your local devnet","text":"
Follow the instructions below to start building on Hyl\u00e9 by running a local devnet. (Instructions for a testnet will be added when we launch it.)
"},{"location":"developers/getting-started/devnet/#recommended-getting-started-with-docker","title":"Recommended: Getting started with Docker","text":"
Follow these instructions to run a node, keeping in mind that this is unstable and can break with upcoming updates.
 
Download the Docker image:
 
docker pull ghcr.io/hyle-org/hyle:latest\n
 
Run the image:
 
docker run -v ./db:/hyle/data -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
If you run into an error, you may want to add the --privileged flag:
 
docker run --privileged -v ./db:/hyle/data -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
If you want to run with an indexer with HYLE_RUN_INDEXER=true, you will need a running PostgreSQL server. You can set it up with Docker:
 
# For default conf:\ndocker run -d --rm --name pg_hyle -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres\n
 
You can customize the db URL with HYLE_DATABASE_URL, with the default value being: postgres://postgres:postgres@localhost:5432/postgres (see below for environment variables).
"},{"location":"developers/getting-started/devnet/#build-the-docker-image-locally","title":"Build the Docker image locally","text":"
If you want to, you can rebuild the image locally from source:
 
docker build -t Hyle-org/hyle . && docker run -dit Hyle-org/hyle\n
"},{"location":"developers/getting-started/devnet/#alternative-getting-started-from-source","title":"Alternative: Getting started from source","text":"
To start a single-node devnet (with consensus disabled), which is useful to build & debug smart contracts, run:
 
cargo build\nHYLE_RUN_INDEXER=false cargo run --bin node\n
"},{"location":"developers/getting-started/devnet/#configuration","title":"Configuration","text":"
You can configure your setup using environment variables or by editing a configuration file.
"},{"location":"developers/getting-started/devnet/#using-environment-variables","title":"Using environment variables","text":"
The variable always begins with HYLE_, followed by the variable: HYLE_RUN_INDEXER=false. Multi-level variables are chained together with a double _, eg. HYLE_CONSENSUS__SLOT_DURATION=100.
 
All variables can be customized on your single-node instance.
 Variable Default value Description id \"node\" single_node true Whether the network runs as a single node. p2p_listen true host \"127.0.0.1:1231\" peers [] storage__interval 10 log_format \"full\" rest \"127.0.0.1:4321\" data_directory \"data_node\" database_url \"postgres://postgres:postgres@localhost:5432/postgres\" PostgreSQL server address (necessary if you want to use an indexer). consensus__slot_duration 1000 consensus__genesis_stakers {} Has to be empty as config is additive p2p__ping_interval 10 run_indexer true Whether there should be an indexer. da_address \"127.0.0.1:4141\""},{"location":"developers/getting-started/devnet/#using-a-configuration-file","title":"Using a configuration file","text":"
To use a configuration file, copy the default settings where you run the node. If a file named config.ron is present, it will be automatically loaded by the node at startup.
 
If you're using Docker:
 
docker run -v ./db:/hyle/data -v ./config.run:/hyle/config.ron -e HYLE_RUN_INDEXER=false -p 4321:4321 -p 1234:1234 ghcr.io/hyle-org/hyle:latest\n
 
Then, whether you're using Docker or building from source:
 
# Copy default config where you run the node. If file named \"config.ron\" is present, it will be loaded by node at startup.\ncp ./src/utils/conf_defaults.ron config.ron\n
"},{"location":"developers/getting-started/erc20-and-identity/","title":"Erc20 and identity","text":"
to be written.
"},{"location":"developers/getting-started/identity-management/","title":"Identity management","text":"
a
"},{"location":"developers/getting-started/user-tooling/","title":"User tooling","text":""},{"location":"developers/getting-started/user-tooling/#user-tooling","title":"User tooling","text":""},{"location":"developers/getting-started/user-tooling/#clone-the-hyle-repository","title":"Clone the Hyl\u00e9 repository","text":"
Clone the Hyl\u00e9 repository.
 
git clone https://github.com/Hyle-org/hyle.git\n
"},{"location":"developers/getting-started/user-tooling/#recommended-install-the-cli","title":"Recommended: Install the CLI","text":"
You can install the CLI for easier access.
 
cargo install --path . --bin hyled\nhyled --help\n
"},{"location":"developers/getting-started/user-tooling/#alternative-use-the-cli-without-installing","title":"Alternative: Use the CLI without installing","text":"
To interact with the node, use the cli hyled:
 
cargo run --bin hyled -- --help\n
"},{"location":"developers/getting-started/user-tooling/#explorer","title":"Explorer","text":"
Explorer / Indexer: Hyl\u00e9ou. Read more about the explorer.
"},{"location":"developers/getting-started/your-first-erc20/","title":"Your first smart contract","text":""},{"location":"developers/getting-started/your-first-erc20/#your-first-smart-contract","title":"Your first smart contract","text":"
We'll use our sample ERC20-like contract hyllar as the basis for this tutorial.
 
Read more in our anatomy of a smart contract.
"},{"location":"developers/getting-started/your-first-erc20/#prerequisites","title":"Prerequisites","text":"
     
  • A working knowledge of zkVM basics.
    •  
  • Install Rust (you'll need rustup and Cargo).
    •  
  • Follow the CLI installation instructions. We are currently building utilities that will make it easier and faster to use our explorer, Hyl\u00e9ou.
    •  
  • Connect to devnet 
    •  
  • For our example, you'll need to install RISC Zero.
    •  
"},{"location":"developers/getting-started/your-first-erc20/#content-of-a-smart-contract","title":"Content of a smart contract","text":"
Hyl\u00e9 smart contracts include:
 
     
  • Owner: put anything you like. This field is currently not leveraged but will be in future versions.
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\").
    •  
  • Program ID: the unique identifier for your program in that proof system.
    •  
  • Contract name: the unique identifier for your contract.
    •  
  • State digest: current state commitment of the contract, usually a MerkleRootHash of the contract's state.
    •  
 
Read more about the anatomy of smart contracts on Hyl\u00e9.
"},{"location":"developers/getting-started/your-first-erc20/#start-your-devnet-and-install-our-cli","title":"Start your devnet and install our CLI","text":"
See our instructions on starting your devnet and downloading our CLI if not already done.
"},{"location":"developers/getting-started/your-first-erc20/#register-your-contract","title":"Register your contract","text":"
To register a contract on Hyl\u00e9, run the following command:
 
# Owner is currently unused, but could be used in the future to manage contract permissions\nhyled contract [owner] [verifier] [program_id] [contract_name] [state_digest]\n
 
Replace [owner], [verifier], [program_id], [contract_name], and [state_digest] with your specific details.
 
Warning
 
     
  • You need a unique contract_name.
    •  
  • The state digest cannot be empty, even if your app is stateless.
    •  
 
For our example:
 
     
  • owner: we put \u00ab default \u00bb as the owner, but you can put anything you like. This field is currently not leveraged; it will be in future versions.
    •  
  • verifier: for this example, the verifier is risc0
    •  
  • program_id: as RISC Zero programs are identified by their image ID, without a prefix, we use the number 0xe085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f. This will change every time the contract logic is modified.
    •  
  • contract_name: hyllar
    •  
  • state_digest: usually a MerkleRootHash of the contract's state. For this example, we'll use fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000, a hexadecimal representation of the state encoded in binary format.
    •  
 
For our example, the bash command looks like this:
 
hyled contract default risc0 e085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f hyllar fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000\n
"},{"location":"developers/getting-started/your-first-erc20/#check-your-contract","title":"Check your contract","text":"
In the explorer, this will look like this:
 
{\n    \"tx_hash\": \"321b7a4b2228904fc92979117e7c2aa6740648e339c97986141e53d967e08097\",\n    \"owner\": \"hyle\",\n    \"verifier\": \"risc0\",\n    \"program_id\":\"e085fa46f2e62d69897fc77f379c0ba1d252d7285f84dbcc017957567d1e812f\",\n    \"state_digest\": \"fd00e876481700000001106661756365742e687964656e74697479fd00e876481700000000\",\n    \"contract_name\": \"hyllar\"\n}\n
"},{"location":"developers/getting-started/your-first-erc20/#interact-with-hyle","title":"Interact with Hyl\u00e9","text":"
Hyl\u00e9 transactions are settled in two steps, following pipelined proving principles.
 
     
  1. Publishing your blob: publish the blob of the final state.
    2.  
  2. Posting proof of your blob: publish proof of the final state.
    3.  
"},{"location":"developers/getting-started/your-first-erc20/#publishing-blobs","title":"Publishing blobs","text":"
The content of the blob is app-specific: it's the input of your program.
 
For Hyllar, this is a binary representation of the ERC20Action struct as defined in the contract.
 
# Create blob\nblob='{binary representation of the ERC20Action struct}'\n\n# Generate the proof in 'hyllar'\ncargo run reset $blob \nhyled blobs \"\" hyllar $(echo $blob | base64)\n
 
At this point, your transaction has been sequenced, but not settled.
"},{"location":"developers/getting-started/your-first-erc20/#posting-proofs-of-your-blob-to-settle-it","title":"Posting proofs of your blob to settle it","text":"
Hyl\u00e9 requires specific variables in the output of the proof to process the transaction. Check the smart contract ABI for more details.
 
Once your program conforms to the ABI, you can generate proofs and send them to Hyl\u00e9.
 
Each blob of a transaction must be proven separately for now, so you need to specify the index of the blob you're proving.
 
hyled proof [tx_hash] [contract_name] [proof]\n
 
In the case of the Hyllar program, we can now prove our state transition:
 
# Make sure the name matches the contract you registered\nhyled proof [tx_hash] hyllar [path_to_proof]\n
 
Hyl\u00e9 will now verify your proof. After verification, your transaction is settled, updating the state of the contract.
 
You can see your transaction on Hyl\u00e9's explorer: https://hyleou.hyle.eu/transaction/$TX_HASH
"},{"location":"developers/getting-started/your-first-erc20/#verifying-your-contracts-state","title":"Verifying your contract's state","text":"
Your contract's state digest is visible at: https://hyleou.hyle.eu/contract/$CONTRACT_NAME
 
You can choose to run the command below instead:
 
hyled state hyllar\n
"},{"location":"developers/getting-started/your-first-smart-contract/","title":"Your first smart contract","text":""},{"location":"developers/getting-started/your-first-smart-contract/#your-first-smart-contract","title":"Your first smart contract","text":"
You can use any zkVM or proving scheme supported by Hyl\u00e9.
 
We'll use the Collatz example as an example throughout this tutorial. See the Collatz page page for more information.
 
Read more in our anatomy of a smart contract.
"},{"location":"developers/getting-started/your-first-smart-contract/#prerequisites","title":"Prerequisites","text":"
     
  • A working knowledge of zkVM basics.
    •  
  • Install Rust (you'll need rustup and Cargo).
    •  
  • Connect to devnet 
    •  
  • Follow the CLI installation instructions. We are currently building utilities that will make it easier and faster to use our explorer, Hyl\u00e9ou.
    •  
  • For our example, you'll need to install RISC Zero.
    •  
"},{"location":"developers/getting-started/your-first-smart-contract/#registering-your-smart-contract","title":"Registering your smart contract","text":""},{"location":"developers/getting-started/your-first-smart-contract/#content-of-a-smart-contract","title":"Content of a smart contract","text":"
Hyl\u00e9 smart contracts include:
 
     
  • Owner: put anything you like. This field is currently not leveraged but will be in future versions.
    •  
  • Verifier: the proof system (e.g. \"risc0\" or \"gnark-groth16-te-BN254\").
    •  
  • Program ID: the unique identifier for your program in that proof system.
    •  
  • Contract name: the unique identifier for your contract.
    •  
  • State digest: current state commitment of the contract, usually a MerkleRootHash of the contract's state.
    •  
 
Read more about the anatomy of smart contracts on Hyl\u00e9.
"},{"location":"developers/getting-started/your-first-smart-contract/#register-your-contract","title":"Register your contract","text":"
To register a contract on Hyl\u00e9, run the following command:
 
# Owner is currently unused, but could be used in the future to manage contract permissions\nhyled contract [owner] [verifier] [program_id] [contract_name] [state_digest]\n
 
Replace [owner], [verifier], [program_id], [contract_name], and [state_digest] with your specific details.
"},{"location":"developers/getting-started/your-first-smart-contract/#for-collatz","title":"For Collatz","text":"
In the case of the Collatz Conjecture example, as RISC Zero programs are identified by their image ID, without a prefix, we use the number 0xb48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b. This will change every time the contract logic is modified.  
 
The initial state is set to \"1\", so that it can be reset to any number. This is encoded in base 64 as AAAAAQ== because of the Rust library used to decode the state.
 
Note that you need a unique contract_name. If you try to test this example on the public devnet, we recommend putting a name that's not \u00ab collatz \u00bb.
 
For our example, the bash command looks like this:
 
hyled contract default risc0 b48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b collatz AAAAAQ==\n
 
(We put \u00ab default \u00bb as the owner, but you can put anything you like. This field is currently not leveraged; it will be in future versions.)
"},{"location":"developers/getting-started/your-first-smart-contract/#checking-your-contract","title":"Checking your contract","text":"
In the explorer, this will look like this:
 
{\n    \"tx_hash\": \"ebecbf7458370d656772369df4a76c343b050e3fdbe4c1ceb7d54175ce290b60\",\n    \"owner\": \"default\",\n    \"verifier\": \"risc0\",\n    \"program_id\": [\n        b48e70c79688b41fc8f0daf8370d1ddb3f44ada934c10c6e0b0f5915102a363b\n    ],\n    \"state_digest\": [\n        AAAAAQ==\n    ],\n    \"contract_name\": \"collatz\"\n}\n
"},{"location":"developers/getting-started/your-first-smart-contract/#interacting-with-hyle","title":"Interacting with Hyl\u00e9","text":"
Hyl\u00e9 transactions are settled in two steps, following pipelined proving principles.
 
     
  1. Publishing payloads: send the input of your program to the network.
    2.  
  2. Posting proof of your payload: generate and submit proofs validating your payload so Hyl\u00e9 will settle your transaction.
    3.  
"},{"location":"developers/getting-started/your-first-smart-contract/#publishing-payloads","title":"Publishing payloads","text":"
The content of the payload is app-specific: it's the input of your program.
 
For the Collatz conjecture, this is a number encoded as a big-endian 32-bit integer.
 
payload='\\x00\\x00\\x00\\x05'\n# Generate the proof in 'collatz-contract'\ncargo run reset $payload\nhyled blobs \"\" collatz $(echo $payload | base64)\n# the \"\" is a placeholder for identity: it's empty, as Collatz doesn't handle identity\n
 
You can see your transaction on Hyl\u00e9's explorer: https://hyleou.hyle.eu/transaction/$TX_HASH
 
At this point, your transaction has been sequenced, but not settled.
"},{"location":"developers/getting-started/your-first-smart-contract/#posting-proofs-of-your-payload-to-settle-it","title":"Posting proofs of your payload to settle it","text":"
Hyl\u00e9 requires specific variables in the output of the proof to process the transaction. Check the smart contract ABI for more details.
 
Once your program conforms to the ABI, you can generate proofs and send them to Hyl\u00e9.
 
Each payload of a transaction must be proven separately for now, so you need to specify the index of the payload you're proving.
 
hyled proof [tx_hash] [contract_name] [proof]\n
 
In the case of the Collatz Conjecture program, we can now prove our state transition from 1 to 5.
 
# Make sure the name matches the contract you registered\nhyled proof [tx_hash] collatz [path_to_proof]\n
 
Hyl\u00e9 will now verify your proof. After verification, your transaction is settled, updating the state of the contract.
"},{"location":"developers/getting-started/your-first-smart-contract/#verifying-your-contracts-state","title":"Verifying your contract's state","text":"
Your contract's state digest is visible at: https://hyleou.hyle.eu/contract/$CONTRACT_NAME
 
You can choose to run the command below instead:
 
hyled state collatz\n
"},{"location":"resources/","title":"\ud83d\udcda Resources","text":"
     
  • Introduction to zero-knowledge proofs
    •  
  • Roadmap
    •  
  • Find us
    •  
  • Grants
    •  
"},{"location":"resources/find-us/","title":"Find us","text":""},{"location":"resources/find-us/#useful-links","title":"Useful links","text":"
     
  • Rust node
    •  
  • Hyle.eu
    •  
  • Hyl\u00e9 blog
    •  
"},{"location":"resources/find-us/#contact-us","title":"Contact us","text":"
Reach out to the team for more information:
  Github  Twitter  Farcaster  LinkedIn  Youtube  Telegram Hyl\u00e9 @hyle_org @hyle-org Hyl\u00e9 @Hyl\u00e9 @hyle_org"},{"location":"resources/grants/","title":"Grants","text":"
We have a grant program supporting developers who want to work on trust infrastructure and programmable cryptography on Hyl\u00e9.
"},{"location":"resources/grants/#what-are-our-grants-like","title":"What are our grants like?","text":"
     
  • You apply with an original idea or an idea from the list on our repo.
    •  
  • We fund your project. You get some money upfront, so you can build without financial worries, and the rest upon completion of the project.
    •  
  • You meet regularly with our CEO for guidance and to help you refine your ideas.
    •  
  • You are in a Telegram group with our other grantees to share ideas and solutions.
    •  
  • Our tech team supports you via Telegram and in meetings.
    •  
  • Our business team helps you showcase your idea through external speaking opportunities, co-marketing, and other assets.
    •  
 
To read more, see our grant ideas, and apply, please go to our Grants page on the main Hyl\u00e9 repository.
 
For questions that aren't answered on the Grants page, reach out in our Telegram group.
"},{"location":"resources/grants/#current-and-past-grants","title":"Current and past grants","text":"
Here are two past grants:
 
     
  • Provable play-by-email games library
    •  
  • Proof of residency app
    •  
 
Find the full list on our Grants page on the main Hyl\u00e9 repository.
"},{"location":"resources/intro-to-zkp/","title":"Understanding zero-knowledge proofs","text":"
Here are some resources on zero-knowledge proofs and how to generate them.
"},{"location":"resources/intro-to-zkp/#when-to-use-zero-knowledge-proofs","title":"When to use zero-knowledge proofs","text":"
There are three moments when ZK is the right tool for you:
 
     
  • Computing power imbalance (which includes improved scalability): I can verify a result without running the resource-heavy computation.
    •  
  • Adversarial environment: I can verify a result without knowing trade secrets that attained this result.
    •  
  • Anonymity: I share only the information I want to share.
    •  
"},{"location":"resources/intro-to-zkp/#how-to-use-zero-knowledge-proofs","title":"How to use zero-knowledge proofs","text":"
There are many ZK languages. Hyl\u00e9 aims to verify as many as possible.
 
DSLs are specific languages that usually compile down to a specific circuit. They're good, but they're complex and may have a high learning curve.
 
zkVMs prove the correct execution of arbitrary code. They allow you to build ZK applications in a certain language without having to build a circuit around it. There are two main types of zkVMs: Cairo and RISC-V. You can benchmark your Rust code and find the best zkVM for your needs with the any-zkvm template.
 
We currently support RISC\u2013V-based zkVMs Risc0 and SP1 and will support more types, including Cairo-based zkVMs and DSLs, in the future.
"},{"location":"resources/intro-to-zkp/#read-more","title":"Read more","text":"
     
  • awesome-zk link repository on GitHub
    •  
  • Hyl\u00e9's very simple introduction to zero-knowledge proofs
    •  
  • Lauri Peltonen's blog series on ZK
    •  
"},{"location":"resources/roadmap/","title":"Roadmap","text":"
We do not have a public roadmap at this time. Stay tuned for updates or ask specific questions in our Telegram group.
"},{"location":"resources/roadmap/#testnet","title":"Testnet","text":"
We will release our testnet in early 2025.
 
While we\u2019re working towards launching the testnet, you can get hands-on right now:
 
     
  • Explore our public devnet or spin up your own instance to start building today!
    •  
"},{"location":"resources/roadmap/#proving-schemes","title":"Proving schemes","text":"
Check the list of the proving schemes we currently support and the ones we'll work on next.
"},{"location":"use-cases/","title":"\ud83d\udca1 Use cases","text":""},{"location":"use-cases/#use-cases","title":"\ud83d\udca1 Use cases","text":"
The Use cases section of the Hyl\u00e9 documentation shows how to use Hyl\u00e9 in different scenarios.
 
Use cases include:
 
     
  • Hyl\u00e9 for play-by-email provable games
    •  
  • Hyl\u00e9 for account abstraction
    •  
  • Hyl\u00e9 for age verification
    •  
  • Hyl\u00e9 for proof of residency
    •  
  • Hyl\u00e9 for the European Union?
    •  
 
If you are interested in other use cases and would like to explore them with us, you might be interested in our grants program!
"},{"location":"use-cases/for-identity-providers/","title":"Hyl\u00e9 for Identity Providers","text":""},{"location":"use-cases/for-identity-providers/#hyle-for-identity-providers","title":"Hyl\u00e9 for Identity Providers","text":"
Hyl\u00e9 does not specify what an \"account\" is, or even what identity particularly means. This gives it unprecedented flexibility in handling identity, including:
 
     
  • EOAs like Ethereum native wallets
    •  
  • Smart accounts of any kind
    •  
  • Regular web2 identity
    •  
  • Passports & other national identity documents.
    •  
 
Warning
 
You are entering TODO area, none of this is currently implemented.
 
Hyl\u00e9 handles identity relying on the caller contract in a multicall.
 
When a user crafts a transaction, their first call should be a proof-of-identity, for example a call to the native /eth smart contract, which validates Ethereum-like EOA signatures.
 
Any subsequent call will see that the user is indeed the owner of an /eth address, e.g. 0xfoobar/eth and will be able to use that address name trustlessly.
"},{"location":"use-cases/for-identity-providers/#registering-your-own-stateless-identity-provider","title":"Registering your own stateless identity provider","text":"
A stateless identity provider such as the Ethereum EOA smart contract has two components:
 
     
  • A smart contract registered on Hyl\u00e9, authenticating proofs
    •  
  • A client-side library that can craft proofs
    •  
 
See the Ethereum EOA smart contract for an example of such a provider.
"},{"location":"use-cases/for-identity-providers/#adding-support-for-your-smart-wallet","title":"Adding support for your smart wallet","text":""},{"location":"use-cases/for-identity-providers/#registering-a-stateful-private-identity-provider","title":"Registering a stateful, private identity provider","text":"
This can be used by games, SSO providers, or any other use-case that needs to handle user identity in a more traditional way.
"},{"location":"use-cases/for-zk-apps/","title":"Hyl\u00e9 for ZKApps","text":""},{"location":"use-cases/for-zk-apps/#hyle-for-zkapps","title":"Hyl\u00e9 for ZKApps","text":"
Hyl\u00e9 is a full featured settlement layer, providing fast finality and cheap TX cost. This makes it a great fit for use-cases that would require appchains or L3s in other ecosystems.
"},{"location":"use-cases/for-zk-apps/#registering-your-smart-contract","title":"Registering your smart contract","text":"
See Your First Smart Contract for details.
"},{"location":"use-cases/for-zk-apps/#bring-your-own-accounts","title":"Bring your own accounts","text":"
See Hyl\u00e9 for Identity Providers
"}]}
\ No newline at end of file