Message Design Patterns
Each design pattern functions as a distinct omnichain building block, capable of being used independently or in conjunction with others.
| Message Pattern | Description |
|---|---|
| AB | one way data transfer from source to destination (A -> B) |
| ABA | a nested send call from Chain A to Chain B that sends back again to the source chain (A -> B -> A) |
| Composed | a message that transfers from a source to destination chain and calls an external contract (A -> B1 -> B2) |
| Composed ABA | transfers data from a source to destination, calls an external contract, and then calls back to the source (A -> B1 -> B2 -> A) |
| Batch Send | a single send that calls multiple destination chains |
This modularity allows for the seamless integration and combination of patterns to suit specific developer requirements.
You can refer to Design Patterns Repo to see example implementations of the patterns discussed here.
AB Pattern
The AB message type refers to a one way send call from a source to destination blockchain.
In the OApp Quickstart, we use this design pattern to send a string from Chain A to store on Chain B (A -> B).
ABA Pattern
The ABA message pattern extends this simple logic by nesting another _lzSend call within the destination contract's _lzReceive function. You can think of this as a ping-pong style call, pinging a destination chain and ponging back to the original source (A -> B -> A).
This pattern demonstrates vertical composability, where the nested message contains both handling for the message receipt, as well as additional logic for a subsequent call that must all happen within one atomic transaction.
This message pattern can also be considered an ABC type call (A -> B -> C), as the nested _lzSend can send to any new destination chain.
This is particularly useful when actions on one blockchain depend on the state or confirmation of another, such as:
Conditional Execution of Contracts: A smart contract on chain A will only execute a function if a condition on chain B is met. It sends a message to chain B to check the condition and then receives a confirmation back before proceeding.
Omnichain Data Feeds: A contract on Chain A can fetch data from the destination (Chain B) to complete a process back on the source.
Cross-chain Authentication: A user or contract might authenticate on chain A, ping chain B to process something that requires this authentication, and then receive back a token or confirmation that the process was successful.
Composed Pattern
A composed message refers to an application that invokes the Endpoint method, sendCompose, to deliver a composed call to a destination contract via lzCompose.
This pattern demonstrates horizontal composability, which differs from vertical composability in that the external call is now containerized as a new message packet; enabling the application to ensure that certain receipt logic remains separate from the external call itself.
Since each composable call is created as a separate message packet via lzCompose, this pattern can be extended for as many steps as your application needs (B1 -> B2 -> B3, etc).
This pattern can be particularly powerful for orchestrating complex interactions and processes on the destination chain that need contract logic to be handled in independent steps, such as:
Omnichain DeFi Strategies: A smart contract could trigger a token transfer on the destination chain and then automatically interact with a DeFi protocol to lend, borrow, provide liquidity, stake, etc. executing a series of financial strategies across chains.
NFT Interactions: An NFT could be transferred to another chain, and upon arrival, it could trigger a contract to issue a license, register a domain, or initiate a subscription service linked to the NFT's ownership.
DAO Coordination: A DAO could send funds to another chain's contract and compose a message to execute specific DAO-agreed upon investments or funding of public goods.
Composed ABA
The Composed ABA design pattern enables sophisticated omnichain communication by allowing for an operation to be performed as part of the receive logic on the destination chain (B1), a follow-up action or call containerized as an independent step within lzCompose (B2), which then sends back to the source chain (A).
This message pattern can also be considered a Composed ABC type call (A -> B1 -> B2 -> C), as the nested _lzSend can send to any new destination chain.
This pattern demonstrates a complex, multi-step, process across blockchains where each step requires its own atomic logic to execute without depending on separate execution logic. Here are some use cases that could benefit from a Composed ABA design pattern:
Omnichain Data Verification: Chain A sends a request to chain B to verify a set of data. Once verified, a contract on chain B executes an action based on this data and sends a signal back to chain A to either proceed with the next step or record the verification.
Omnichain Collateral Management: When collateral on chain A is locked or released, a corresponding contract on chain B could be called to issue a loan or unlock additional funds. Confirmation of the action is then sent back to chain A to complete the process.
Multi-Step Contract Interaction for Games and Collectibles: In a gaming scenario, an asset (like an NFT) could be sent from chain A to B, triggering a contract on B that could unlock a new level or feature in a game, with a confirmation or reward then sent back to chain A.
Batch Send
The Batch Send design pattern, where a single transaction can initiate multiple _lzSend calls to various destination chains, is highly efficient for operations that need to propagate an action across several blockchains simultaneously.
This can significantly reduce the operational overhead associated with performing the same action multiple times on different blockchains. It streamlines omnichain interactions by bundling them into a single transaction, making processes more efficient and easier to manage for example:
Simultaneous Omnichain Updates: When a system needs to update the same information across multiple chains (such as a change in governance parameters or updating oracle data), Batch Send can propagate the updates in one go.
DeFi Strategies: For DeFi protocols that operate on multiple chains, rebalancing liquidity pools or executing yield farming strategies can be done in batch to maintain parity across ecosystems.
Aggregated Omnichain Data Posting: Oracles or data providers that supply information to smart contracts on multiple chains can use Batch Send to post data such as price feeds, event outcomes, or other updates in a single transaction.