DLT Interoperability and More ⛓️#21 — Open Zeppelin’s CrossChainEnabled Contracts⛓️

In this series, we analyze papers on blockchain and interoperability.

This edition covers an industry standard: interfaces that promote cross-chain awareness.
➡️ Authors: Open Zeppelin

➡️ Paper source: https://docs.openzeppelin.com/contracts/4.x/api/crosschain

➡️ Background:

Standards are important. While standards from regulatory bodies on cross-chain data and asset transfers are being developed, industry standards are used. In this article, we will dissect Open Zeppelin’s CrossChainEnabled Contracts. The idea for these contracts is to provide abstractions to control the execution flow when dealing with cross-chain messages. This is useful not only for bridges but also for blockchain gateways.

➡️ Contributions:

• An industry standard that presents the “building blocks to improve cross-chain awareness of smart contracts”.

➡️ An overview of the standard:

The standard defines an interface (i.e., abstract contract) for implementers to define accessors (_isCrossChain, _crossChainSender) and modifiers (onlyCrossChain, onlyCrossChainSender). Note that, as this contract is abstract, it requires a particular implementation (e.g., Optimism, Polygon, etc).

Modifier “onlyCrossChain” is used in functions that are expecting a cross-chain message call, while modifier “onlyCrossChainSender” expects a function caller to be initiated by a specific account (e.g., relayer).

“_isCrossChain” returns whether the current function call is the result of a cross-chain message, while “_crossChainSender” returns the address of the sender of a cross-chain message.

➡️ The case of Polygon:

Polygon defines a default sender in the “CrossChainEnabledPolygonChild.sol” contract. The contract is also abstract, providing implementation guidelines for cross-chain solutions using Polygon:

processMessageFromRoot calls from the provided address with the provided calldata. Under the hood, it uses the primitive delegatecall and uses a low-level call to verify the call was successful and revert otherwise. For more info on _fxChild, see https://wiki.polygon.technology/docs/develop/l1-l2-communication/fx-portal/. Basically, FxPortal (defining FxChild and FxRoot) is Polygon’s official bridge. By using “CrossChainEnabledPolygonChild.sol” in our contract, we can enable our token to be compatible with Polygon’s FxTunnel. FxChild, can be an ERC20 contract, ERC721, etc:

However, this design pattern only allows our contract to be compatible with a bridge at a time.

🚀 What are the implications for our work?

• Leveraging standards is a good practice that reduces implementation time while increasing security, as it promotes unified processes that the community can assess. These standards allow us to develop secure blockchain interoperability middleware.