hyperlane-monorepo/README.md

# Optics

OPTimistic Interchain Communication

## Overview

Optics is a cross-chain communication system. It handles passing raw buffers
between blockchains cheaply, and with minimal fuss. Like IBC and other
cross-chain communication systems, Optics creates channels between chains, and
then passes its messages over the channel. Once a channel is established, any
application on the chain can use it to send messages to any other chain.

Compared to IBC and PoS light client based cross-chain communication, Optics
has weaker security guarantees, and a longer latency period. However, Optics
may be implemented on any smart contract chain, with no bespoke light client
engineering. Because it does not run a light client, Optics does not spend
extra gas verifying remote chain block headers.

In other words, Optics is designed to prioritize:

- Cost: No header verification or state management.
- Speed of implementation: Requires only simple smart contracts, no complex
  cryptography.
- Ease of use: Simple interface for maintaining XApp connections.

You can read more about Optics' architecture [at Celo's main documentation site](https://docs.celo.org/celo-codebase/protocol/optics).

## Integrating with Optics

Optics establishes communication channels with other chains, but it's up to XApp (pronounced "zap", and short for "cross-chain applications")
developers to use those. This repo provides a standard pattern for integrating
Optics channels, and ensuring that communication is safe and secure.

Integrations require a few key components:

- A `Home` and any number of `Replica` contracts deployed on the chain already.
  These contracts manage Optics communication channels. and will be used by the
  XApp to send and receive messages.

- A `XAppConnectionManager` (in `solidity/optics-core/contracts`). This
  contract connects the XApp to Optics by allowing the XApp admin to enroll new
  `Home` and `Replica` contracts. Enrolling and unenrolling channels is the
  primary way to ensure that your XApp handles messages correctly. XApps may
  deploy their own connection manager, or share one with other XApps.

- A `Message` library. Optics sends raw byte arrays between chains. The XApp
  must define a message specification that can be serialized for sending, and
  deserialized for handling on the remote chain

- A `Router` contract. The router translates between the Optics cross-chain
  message format, and the local chain's call contract. It also implements the
  business logic of the XApp. It exposes the user-facing interface, handles
  messages coming in from other chains, and dispatches messages being sent to
  other chains.

Solidity developers interested in implementing their own `Message` library and
`Router` contract should check out the [optics-XApps](https://github.com/celo-org/optics-monorepo/tree/main/solidity/optics-xapps)
package. It contains several example XApps.

It is **Strongly Recommended** that XApp admins run a `watcher` daemon to
maintain their `XAppConnectionManager` and guard from fraud. Please see the
documentation in the `rust/` directory and the
[Optics architecture documentation](https://docs.celo.org/celo-codebase/protocol/optics)
for more details.

## Working on Optics

### Pre-commit hooks

Set up your pre-commit hook:

```bash
echo "./pre-commit.sh" > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
```

Note: In the event you need to bypass the pre-commit hooks, pass the
`--no-verify` flag to your `git commit` command

### Solidity

1. Install dependencies

   ```bash
   cd solidity/optics-core
   npm i
   cd ../optics-XApps
   npm i
   ```

2. Install jq

   ```bash
   brew install jq
   ```

     OR  

   ```bash
   sudo apt-get install jq
   ```

3. Install solhint

   ```bash
   npm install -g solhint
   // to check it is installed:
   solhint --version
   ```

### Rust

- install `rustup`
  - [link here](https://rustup.rs/)
- see `rust/README.md`

# What is Optics?

We present Optics - a system for sending messages between consensus systems
without paying header validation costs by creating the illusion of cross-chain
communication. Similar to an atomic swap, Optics uses non-global protocol
validation to simulate cross-chain communication. Optics can carry arbitrary
messages (raw byte vectors), uses a single-producer multi-consumer model, and
has protocol overhead sublinear in the number of messages being sent.

## Key Points

System sketch:

1. A "home" chain commits messages in a merkle tree
2. A bonded "updater" attests to the commitment
3. The home chain ensures the attestation is accurate, and slashes if not
4. Attested updates are replayed on any number of "replica" chains, after a
   time delay

As a result, one of the following is always true:

1. All replicas have a valid commitment to messages from the home chain
2. Failure was published before processing, and the updater can be slashed on
   the home chain

This guarantee, although weaker than header-chain validation, is still likely
acceptable for most applications.

## Summary

Optics is a new strategy for simulating cross-chain communication without
validating headers. The goal is to create a single short piece of state (a
32-byte hash) that can be updated regularly. This hash represents a merkle tree
containing a set of cross-chain messages being sent by a single chain (the
"home" chain for the Optics system). Contracts on the home chain can submit
messages, which are put into a merkle tree (the "message tree"). The message
tree's root may be transferred to any number of "replica" chains.

Rather than proving validity of the commitment, we put a delay on message
receipt, and ensure that failures are publicly visible. This ensures that
participants in the protocol have a chance to react to failures before the
failure can harm them. Which is to say, rather than preventing the inclusion of
bad messages, Optics guarantees that message recipients are aware of the
inclusion, and have a chance to refuse to process them.

To produce this effect, the home chain designates a single "updater." The
updater places a bond ensuring her good behavior. She is responsible for
producing signed attestations of the new message tree root. The home chain
accepts and validates these attestations. It ensures that they extend a
previous attestation, and contain a valid new root of the message set. These
attestations are then sent to each replica.

The replica accepts an update attestation signed by the updater, and puts it in
a pending state. After a timeout, it accepts the update from that attestation
and stores a new local root. Because this root contains a commitment of all
messages sent by the home chain, these messages can be proven (using the
replica's root) and then dispatched to contracts on the replica chain.

The timeout on new updates to the replica serves two purposes:

1. It ensures that any misbehavior by the updater is published **in advance**
   of message processing. This guarantees that data necessary for home chain
   slashing is available for all faults.
2. It gives message recipients a chance to opt-out of message processing for
   the update. If an incorrect update is published, recipients always have the
   information necessary to take defensive measures before any messages can be
   processed.