# Cross-Chain Message Multicast Protocol

| Authors | Status | Created |
|:-------------------------- | ------ |:---------- |
| nshuman.eth, jordaniza.eth | Draft | 2022-10-24 |

## Abstract

This proposal standardizes the architecture for a message delivery system that supports multiple subscriber smart-contracts on different EVM blockchains.

## Motivation

Current cross chain bridging systems in public permissionless blockchains offers the ability to send transactions, typical via Relayer/Oracle networks or with the help of trusted intermediaries (Briges/Multisigs). Typical message flows are bidirectional: they involve an origin chain (`origin`) and a remote chain `remote`, relative to where the request was made.

> We suggest to avoid `src` and `dst` in this situation because when messages are going back from the `remote` to the `origin`, the source and destination nomenclature can get confusing.

What is *not* standardised, is a more generalist approach to multi-chain messaging, emulating the Pub/Sub model in event-driven system design. In the Pub/Sub model, we define a *Publisher* as an entity that pushes messages to a common location, read by many *Subscribers*. Crucially, the Publisher is not concerned with either the number of subscribers or whether the message was received and processed correctly.

This model fits nicely with existing bridge tech for a number of reasons:

1. Bridges typically have high latency (in the order of minutes), which makes messaging acknowledgments (`acks`) challenging to implement. Applications that need `acks` with bridging might typically rely on off-chain methods to confirm remote transactions. In Pub/Sub, we don't care about the message Ack, that is very much the job of the subscriber.
2. Bridging across blockchains necessarily breaks transaction atomicity - the blockchain is a finite, self-contained state machine, and so using an external oracle to publish a remote transaction must take one atomic transaction and use it to create another. Pub/Sub does not care about atomicity between Publishers and Subscribers, and so this mental model for system design, if designed properly, will not rely on guaranteed receipt by all subscribers - likely leading to greater resilience.

Saying all this, we know of no major implementations of Pub/Sub design using existing bridge tech. Most applications have instead opted to use more advanced bridging technologies (LayerZero, Stargate) to provide abstractions for users that 'hide' the complexities of cross chain bridging. While very appealing, this can lead to a set of leaky abstractions where cross chain operations execute very differently to within-chain. We intend to explore an application and protocol-level implementation of Pub/Sub, using existing technology, and, if needed, some custom options.

## Minimal Design Scope

### Features
- Create a cross-chain message channel
- Subscribe to a cross-chain message channel
- Unsubscribe to a cross-chain message channel
- Publish a cross-chain message delivered to all the subscribers
- Receive a cross-chain message with predefined structure
- Publish a cross-chain message receipt

### Concerns
- Throughput
- Not sure if we hit any problems related to sending an arbitrary size message to a big number of subscribers. Could scheduling many bridge transfers potentially not fit into the remaining block gas limit?
- There will be gas limits with large messages sent to high numbers of chains, we should model these breakpoints with different gas prices.

- Broadcast vs. receipt
- If we define many chains, how should we handle sending messages? Should messages go, by default, to all chains, then subscriptions can choose to pick them up or not? This is almost certainly not going to work as the number of chains is already very large and the user on the origin chain must pay for this.
- If not, then a multicaster must have some way of knowing *where* it should send messages.

## Extended Design Scope

### Features
TBD (Anything that's nice to have, but feels extra for the scope)

- Define conditions for a subscription (to prevent sybil or enable monetization)?

## Specification

### Registry
Registry can be defined on each chain. It can have a very simple job of storing all the revelvant subscriptions for all contracts.
Additionally, it can manage subscribing and unsubscribing. The multicaster can refer to this contract for data, and different multicasters can be written for different bridiging technologies.

    
// most simple approach (address => sigs => chainIds) 
mapping (address => bytes4[] => uint256[]) subscriptions;

function subscribe(address _contract, uint _chainId, bytes4 _sig) external;
function unsubscribe(address _contract, uint _chainId, bytes4 _sig) external;
    

Some optimisation ideas:
- Explore slot packing for Chain Ids:
- Rather than keeping one chainId per storage slot, if the number of chains can reasonably expected to fit into, say, a 16 bit integer, then we can fit 16 chains into a single storage slot (LayerZero does this)

Notes:
- Needs to synchronize channels and subscription state across all the chains
- Lets an address on a chain create a channel that is uniquely identified across all the supported chains
- Lets an address on a chain to subscribe to a channel that aggregates messages from all the supported chains

### Multicaster
Multicaster can be a library or pass-through contract that is called by the User application. The multicaster needs act as the intermediary between the user application and the bridging technology. Its job is to receive transaction data

Notes:
- Responsible for dispatching of the messages
- Uses the underlying bridge

### Source
TBD

Notes:
- Message sender interface

### Destination
TBD

Notes:
- Message receiver interface

### Channel
TBD

### Subscription
TBD

### Message

|0      |8      |16     |24    |31
--------------------------------
Version |Type   |Flags         | // 4-byte header
--------------------------------
...
...
Data                             // subsequent bytes
...                              // (subject to VM constraints)
...
--------------------------------

#### Attributes
- Version
- 8 bits
- Encodes message standard version number
- Supposed to prevent subscribers from parting the message in a wrong way
- Type
- 8 bits

| Code | Type | Notes |
| ---- | -------- |:------------------------------------------------------------------------------------- |
| 0x00 | RESERVED | Don't want to give the zero value any user-assigned meaning |
| 0x01 | SYN | Potentially usable primitive to ping addresses and establish prioritized communication sessions |
| 0x02 | ACK | Same as SYN, but for acknowledgements |
| 0x03 | PLAIN | Plain binary content with user-defined structure |
| 0x04 | CALL | Smart-contract call |

- Flags
- 16 bits
- A combination of flags is supposed to help manage state across chains
- Flag bits could be reused to have different meanings for different message types

- Bitmaps:
- Naive implementation of

| Bit | Flag |
|:--------- | ---- |
| 0000 0000 0000 000**1** | TBD |
| 0000 0000 0000 00**1**0 | TBD |
| 0000 0000 0000 0**1**00 | TBD |
| 0000 0000 0000 **1**000 | TBD |
| 0000 0000 000**1** 0000 | TBD |
| 0000 0000 00**1**0 0000 | TBD |
| 0000 0000 0**1**00 0000 | TBD |
| 0000 0000 **1**000 0000 | TBD |
| 0000 000**1** 0000 0000 | TBD |
| 0000 00**1**0 0000 0000 | TBD |
| 0000 0**1**00 0000 0000 | TBD |
| 0000 1000 0000 0000 | TBD |
| 000**1** 0000 0000 0000 | TBD |
| 00**1**0 0000 0000 0000 | TBD |
| 0**1**00 0000 0000 0000 | TBD |
| **1**000 0000 0000 0000 | TBD |

- Data (D)
- Binary payload depending on the message type
- Could be plain binary, function selector with parameters, etc.

## Misc

### Notations

This is a convenient way to visualize data layout in bits

|0      |8      |16     |24    |31
--------------------------------
Some data goes here...
--------------------------------

### Unused Ideas
- Use TTL measured in blocks
- Sounds unreliable and dangerous considering the differences between block times and synchronization across chains.
- Could be used to decide for how long the Source should keep the message for until it's irrelevant and should be discarded?