Ethereum Interoperability and Atomic Transactions

ยท

Public blockchains and tokenization features are increasingly used across both public and permissioned ledgers. This growth drives a strong need for interoperability between different systems. Common scenarios include exchanging assets across ledgers, linking business transactions on permissioned chains with cryptocurrency payments on public networks, and publishing proofs of permissioned blockchain transactions on public ledgers.

To enable these use cases, platforms like Oracle Blockchain Platform offer interoperability with Ethereum and any EVM-based network supporting standard web3 protocols. This is achieved through a dedicated REST API that orchestrates atomic transaction workflows.

How Atomic Transactions Work

The interoperability function integrates the Geth Ethereum client into a REST proxy. It uses a single API endpoint called atomicTransactions to execute an optimized two-phase commit protocol. This API can handle multiple chaincode transactions across Oracle Blockchain Platform channels. It can also include an Ethereum transaction, which runs atomically alongside the platform transactions.

Unlike Oracle Blockchain Platform transactions, Ethereum transactions cannot be split into prepare and commit phases. To include them in an atomic workflow, the platform uses a Last Resource Commit (LRC) optimization. After all Oracle Blockchain Platform transactions are prepared, the Ethereum transaction is initiated. If the Ethereum transaction succeeds, the platform transactions are committed. If it fails, all platform transactions are rolled back.

Understanding Transaction Finality

Ethereum transactions involve a concept of finality. A transaction may execute successfully, but it is only considered final when it is part of a block that cannot be altered. You can control finality checks using the finalityParams parameter. This allows you to set the waiting time in blocks or seconds.

On the public Ethereum Mainnet, waiting for six block confirmations is generally sufficient to assume finality. Private Ethereum networks often require shorter waiting periods.

๐Ÿ‘‰ Explore more strategies for transaction finality

Transferring NFTs to Ethereum Networks

The atomicTransactions API also supports interactions with smart contracts deployed on Ethereum networks. This functionality allows you to transfer Non-Fungible Tokens (NFTs) minted on Hyperledger Fabric chaincode to Ethereum or Polygon networks. Key NFT attributes like token ID, price, and history can be passed atomically to Ethereum. Once transferred, these NFTs can be listed on public marketplaces.

Transferring an NFT from Oracle Blockchain Platform to Ethereum involves two atomic steps:

  1. Burn the NFT on Oracle Blockchain Platform. Invoke the burnNFT method to remove the NFT from the Hyperledger Fabric chaincode. The platform supports NFTs using enhanced versions of the ERC-721 and ERC-1155 standards.
  2. Mint the NFT on Ethereum. Call a smart contract on the Ethereum or Polygon network to mint the NFT using parameters returned by the burnNFT method.

Smart Contract Parameters

For unsigned requests, the atomic transaction API can extract parameters from the burnNFT method and send them to the Ethereum smart contract. The mintNFT function typically requires these parameters:

The smart contract requires the token ID to be a numeric string (one that can be converted to an integer). For example, 2 is valid, but token2 is not.

Token URI Compatibility

The token URI for an NFT in the chaincode must follow a specific format for compatibility with Solidity smart contracts:

Working with Application Binary Interfaces (ABI)

You can use the Remix IDE to generate an Application Binary Interface (ABI) for your smart contract. This ABI is then used with the atomicTransactions API. If you make any changes to the smart contract methods, you must recompile the contract and regenerate the ABI.

Frequently Asked Questions

What is the main benefit of using atomic transactions?
Atomic transactions ensure that multiple operations across different blockchains either all succeed or all fail together. This eliminates the risk of partial completions, which is critical for financial operations and asset transfers.

How does the Last Resource Commit (LRC) optimization work?
LRC is used to integrate Ethereum transactions into a two-phase commit protocol. All Oracle Blockchain Platform transactions are prepared first. The Ethereum transaction is then executed as the final step. Its success or failure determines whether all prepared platform transactions are committed or rolled back.

What are the finality parameters, and why are they important?
Finality parameters define how long the system waits to confirm an Ethereum transaction is irreversible. This is crucial for security. On public networks, more confirmations are needed, while private networks may require fewer.

Can I transfer any type of NFT to Ethereum?
The NFTs must be compatible with enhanced ERC-721 or ERC-1155 standards on Oracle Blockchain Platform. Their token URIs must also adhere to specific formatting rules to ensure they can be properly re-minted on the Ethereum network.

What happens if my Ethereum transaction fails during the atomic process?
If the Ethereum transaction fails at any point, the entire atomic workflow is aborted. All prepared Oracle Blockchain Platform transactions are automatically rolled back, ensuring no state changes are committed on either platform.

Where can I find sample smart contracts for minting NFTs?
Sample Solidity smart contracts for both ERC-721 and ERC-1155 tokens are available. These contracts include the necessary mintNFT function to create NFTs with custom attributes like price and history on the Ethereum network.

For detailed information on parameters used for Ethereum transactions in atomic workflows, including a full example of NFT transfer, refer to the official Atomic Transactions REST Endpoints documentation.