Skip to content

Instantly share code, notes, and snippets.

@serejke
Created September 5, 2023 15:05
Show Gist options
  • Save serejke/20b8a3494301577f87840f42c67dac2c to your computer and use it in GitHub Desktop.
Save serejke/20b8a3494301577f87840f42c67dac2c to your computer and use it in GitHub Desktop.
InterUtxo: General Message Passing for UTXO blockchains

Objectives

Project InterUtxo is establishing a framework for General Message Passing (GMP) as the foundation for Blockchain Interoperability for UTXO based Blockchains.

Core Principles

  • Separation of concerns for message semantics, transport (routing & relays) and validation (security)
  • Security modules are designed for modularity, customization, and future compatibility
    • When more advanced proofing systems are production-ready for a specific blockchain, the proofing methods for different chains can be upgraded independently.
    • Additionally, application developers have the option to layer application-level security over blockchain-level security to boost the security of messaging.
  • A pattern of building generic applications

High-Level Overview

Project InterUxo is being built on top of Hyperlane. Hyperlane is an open source, chain agnostic framework to build inter-chain messaging systems, and is becoming a popular choice as the foundation for inter-chain messaging solutions.

Key Components of Hyperlane:

  • Mailbox (Inbox and Outbox): on-chain APIs designed for sending and receiving messages across chains.
  • Validator: off-chain agent responsible for observing the Mailboxes and attesting to the outgoing messages.
  • Relayer: trustless off-chain agent responsible for delivering messages to the target blockchain once the configured ISM conditions have been met.
  • ISM: on-chain smart contracts or validator scripts that are responsible for confirming the signed attestations of incoming messages

ISMs serve as the security foundation of the protocol, permitting customized security measures without altering the semantics of application-level messages.

  • Multi-sig ISM: This validates that a message has been signed by N/M off-chain validators.
  • Multi-sig + Merkle Proof ISM: Beyond validation, this allows for penalizing dishonest validators by providing fraud proofs to the originating chain.
  • Light Client ISMs: Applicable for blockchain pairs where light-client verification is possible.
  • Aggregation ISM: A combination of the aforementioned types.
  • Stake-Based Multi-signatures ISM (Mithril): Utilizes the stakes of SPOs to achieve optimal security.

UTXO walkthrough

In Cardano, the state is contained in the Datum of Unspent Transaction Outputs (UTXOs), which are located either on a payment address or a validator address. A UTXO located on a payment address can be spent when the owner signs the transaction. A UTXO on a validator script address can be used by satisfying a corresponding validator script predicate. The Redeemer acts as an additional input for the predicate.

UTxO {
  tx_id             // The id of the transaction that produces this UTxO
  tx_ix             // The index of the UTxO in the output list of the producing transaction

  address           // The address that locks this UTxO
  value             // The value stored in this UTxO (ADA and native tokens)
  datum             // Arbitrary data stored in this UTxO, inlined or hashed
}

Redeemer = <arbitrary data used as validator input>

Transaction {
  inputs            // The UTxOs spent in this transaction
  ref_inputs        // The UTxOs referenced but not spent in this transaction
  outputs           // The UTxOs produced in this transaction
  fee               // The ADA fee of the transaction
  minted            // The tokens minted and burned in the transaction
  signatures        // The signatures signed on the transaction
  redeemers         // The redeemers passed to validators
  datums            // The hash-to-value datum map for lookup
}

Validator(
  datum,            // The datum of the UTxO being spent
  redeemer,         // The redeemer to the spending of the UTxO
  script_context    // The context built from the transaction
) -> true | false

Architecture & Mithril

Message semantics

Messages sent between interconnected chains consist of a header and a flexible message payload, which is intended for interpretation by the receiving application.

struct Message {
  nonce: uint32               // Sequential nonce to identify the message on its origin chain
  origin_domain: uint32       // Domain ID of the origin chain
  destination_domain: uint32  // Domain ID of the destination chain
  sender: Bytes32             // Address of the sender
                              // 0x00xxx -> Payment credential that must sign the tx.
                              // 0x01xxx -> Minting policy hash that must mint in the tx.
                              // 0x02xxx -> Validator script must be run in the same tx.   
  recipient: Bytes32          // Address of the recipient on the destination chain
  message: Bytes              // Arbitrary message payload
}

Transport & Routing

Messages are sent by trustless off-chain relayers, who are motivated by fee incentives. Relayers can opt in to facilitate message transfers between specific pairs of blockchains.

The chains are identified by domain IDs (Ethereum being domain ID #1, Polygon #137, etc) known by relayers in advance. The message header contains enough data for relayers to filter only the interesting message.

Validation

In the present iteration of InterUtxo, we utilize a straightforward multi-signature ISM for confirming message validity via an N/M quorum. Each blockchain features a unique group of validators responsible for verifying outgoing messages; these signed checkpoints are then stored in a designated off-chain repository. The multi-signature ISM is made up of registered validators whose quorum is subsequently verified.

Validators operating on public chains are managed by both the Hyperlane community and the InterUtxo team in a permissionless manner. Anyone is free to participate in the validation process for outgoing messages by operating a set of off-chain agents.

General Applications

Security of the messages is independent of how they are processed. Relayers, which are not tied to any specific application, accumulate sufficient on-chain evidence to confirm the message's validity before sending it.

In the Ethereum context, a large portion of the application logic can be embedded directly into versatile on-chain smart contracts. Both the delivery and processing of messages can be accomplished within a single transaction.

Contrastingly, in Cardano's case, an off-chain agent needs to be aware of the specific application in order to correctly construct the transaction's UTXO inputs and outputs:

  1. Message Delivery and Validation — A relayer sends a transaction that is validated by the ISM. Upon validation, the ISM issues an "auth" token that is attached to the message payload's UTXO.
  2. Message Processing — Off-chain agents dedicated to application processing monitor the message UTXOs that come with attached "auth" tokens and submit transactions that are specific to the application.

Mithril

Mithril could potentially enhance the security of messages sent from Cardano by leveraging the stake of Stake Pool Operators (SPOs).

image

Related Documents

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment