Skip to content

Smart contracts

Hylé is a fully programmable blockchain designed for efficient data storage. Hylé only keeps the essential information needed to validate smart contract proofs, ensuring that smart contracts are lightweight and performant.

Unlike traditional blockchains, which store all smart contract data onchain, Hylé separates execution data (managed offchain by each application) from onchain data, which can be retrieved via our ABI.

Onchain smart contract data

Hylé smart contracts store the following data onchain:

  • Name: the unique identifier for the contract
  • Verifier: the proof system used (e.g., "risc0" or "gnark-groth16-te-BN254")
  • Program ID: the unique identifier for the program within that proof system
  • State digest: current state commitment of the contract

Explanation of the contract fields

Name

The contract name must be unique.

Verifier and program ID

Smart contracts on Hylé rely on a pairing of a zero-knowledge proof scheme (verifier) and a program identifier. Together, these components validate contract proofs.

Clone a template or write your own program to get started with smart contract writing.

Proving scheme Verifier Program ID Template
Noir noir Verification key.
Risc0 risc0 Image ID without a prefix. ex. 0x123 becomes 123. Template
SP1 sp1 Verification key. Template

State digest

The state digest represents the contract's current state commitment. It allows Hylé to guarantee its integrity. It can take any form as long as it fulfills this purpose.

The state digest can be expressed as a hash or even a serialization of the state if it's small enough.

Smart contract ABI

All inputs in Hylé smart contracts must be known at proof generation time. This includes elements like the tx_hash which are typically available only at execution time on other blockchains.

Here is the Rust structure specifying the output of a Hylé smart contract:

pub struct HyleOutput {
    pub version: u32,
    pub initial_state: StateDigest,
    pub next_state: StateDigest,
    pub identity: Identity,
    pub index: BlobIndex,
    pub blobs: Vec<u8>,
    pub tx_hash: TxHash,
    pub success: bool,
    pub tx_ctx: Option<TxContext>,
    pub registered_contracts: Vec<RegisterContractEffect>,
    pub program_outputs: Vec<u8>, 
}

Version

For now, version should always be set to 1.

Initial state and next state

These fields define state transitions.

  • initial_state: must match the onchain state_digest before the transaction. If they don't match, the state transition is invalid.
  • next_state: Represents the new onchain state_digest after the transaction.

In the future, state_digest size will be limited and fees will depend on proof size (which is affected by the digest's size). Keep them small!

Identity

Info

Read our identity documentation for details.

Identity consists of:

  1. An identifier;
  2. The name of the contract that the proof was generated for.

Example

A contract verifying Ethereum EOAs might have an identity like 0x1234...5678.eth_eoa where the first part matches a regular Ethereum address and eth_eoa is the name of the contract.

Blob index and blobs

Each blob transaction includes multiple blobs:

  • index uniquely identifies a blob within a transaction.
  • blobs is a list of all blobs included in the transaction.

TX Hash

tx_hash is the blob Transaction's hash.

The protocol does not validate this field and tx_hash may be deprecated in later versions.

Success

This boolean field indicates whether the proof is for a successful or failed transactions. It can be used to prove that a transaction is invalid.

If a proof returns success = false, the whole blob transaction will fail. In that case, there is no need to generate proofs for other blobs.

Transaction context

Transaction context allows the contract to know in which block (hash, height, timestamp) the blob transaction has been sequenced.

This field is optional. If left empty, it will not be validated by Hylé or usable by the program.

Registered contracts

A list of new contracts to register, which can be used to self-upgrade a contract.

Other program-specific outputs

Smart contracts can generate additional outputs as proof data. These outputs ensure data availability.

Events

Hylé does not use traditional events. Instead, it relies on blobs, which serve as containers for offchain data.