1. Using Oracle Blockchain Platform
  2. Develop Blockchain Applications
  3. Ethereum Interoperability

Ethereum Interoperability

You can include Ethereum-based transactions in an atomic transaction workflow.

Growing use of public blockchains and tokenization capabilities across both public and permissioned blockchains drives the need for their interoperability. Common scenarios include asset exchange across different ledgers, business transactions on permissioned blockchains that are linked to cryptocurrency payments on public chains, publishing proof of a permissioned blockchain transaction on a public blockchain, and so on. To enable interoperability for these and other scenarios, Oracle Blockchain Platform provides interoperability with Ethereum and with any EVM-based networks that support standard web3 protocols. The interoperability function works by incorporating the Geth Ethereum client in the REST proxy and enabling it to orchestrate an optimized two-phase commit protocol that includes both Oracle Blockchain Platform and Ethereum/EVM transactions through a single REST API called atomicTransactions. You can use the atomicTransactions API to send multiple chaincode transactions for multiple Oracle Blockchain Platform channels, and can optionally add an Ethereum transaction that will run atomically with the Oracle Blockchain Platform transactions.

Unlike Oracle Blockchain Platform transactions, Ethereum transactions cannot be broken down into the prepare and commit phases of the two-phase commit protocol. To include Ethereum transactions as part of an atomic workflow, Oracle Blockchain Platform uses a last resource commit (LRC) optimization. After all of the Oracle Blockchain Platform transactions are in the prepared state, the Ethereum transaction is started. If the Ethereum transaction succeeds, then the Oracle Blockchain Platform transactions are committed. If the Ethereum transaction fails, then the Oracle Blockchain Platform transactions are rolled back.

Ethereum transactions have a concept of finality. An Ethereum transaction can run successfully but it does not achieve finality until it's part of a block that can't change. You can use the finalityParams parameters to control whether to check for finality and how long to wait for it, either in blocks or in seconds. Typically, if you wait for six blocks to be generated on the public Ethereum blockchain network (Mainnet), you can assume that transaction finality was achieved. In private Ethereum networks, typically you do not need to wait as long for finality.

Transferring an NFT to an Ethereum network

The atomicTransactions API also supports interactions with smart contracts that are deployed on Ethereum networks. You can use this functionality to transfer non-fungible tokens (NFTs) that were minted in Hyperledger Fabric chaincode on Oracle Blockchain Platform to an Ethereum or Polygon network, by invoking two transactions atomically. NFT attributes such as the token ID, price, and token history can also be passed from Oracle Blockchain Platform to Ethereum atomically. After you transfer an NFT from Oracle Blockchain Platform to Ethereum, the NFT can be listed on a public NFT marketplace.

To transfer an NFT from Oracle Blockchain Platform to Ethereum, you use two basic steps in one atomic transaction:

  1. Burn the NFT on Oracle Blockchain Platform. Call the burnNFT method, to burn (delete) the NFT from the Hyperledger Fabric chaincode on Oracle Blockchain Platform. Oracle Blockchain Platform supports NFTs in enhanced versions of two standards, ERC-721 and ERC-1155, with the Blockchain App Builder tool. For more information on the burnNFT method, see the relevant topic for your environment:
  2. Mint the NFT on Ethereum. Call a smart contract on the Ethereum or Polygon network to mint the NFT on that network, using the parameters returned by the burnNFT method. Sample versions of smart contracts written in the Solidity language for NFTs are available in the following archive file: solidity-smartcontracts-fab253.zip. The smart contracts, one for each of the enhanced token standards ERC-721 and ERC-1155, include a mintNFT method, which creates NFTs with custom properties such as price and token history, which can be fetched from the output of the burnNFT method in the previous step.
    For unsigned requests, if the custom properties are in the ParamKeys parameter and corresponding dynamic parameters are passed in the params parameter, the atomic transactions API can fetch the parameters from the burnNFT method and send them to the Ethereum smart contract. The mintNFT method takes the following arguments:
    • to – The Ethereum address for the account where the NFT will be minted.
    • id – The token ID of the NFT.
    • price – The price of the NFT.
    • tokenHistory – The history of the NFT from the Oracle Blockchain Platform chaincode.

    The smart contract requires that the token ID of the NFT must be a numeric string (a string that can be converted to an integer). For example a token ID can be 2 but not token2.

    The token URI of the NFT in the chaincode deployed on Oracle Blockchain Platform must follow a certain format to make it compatible with Solidity smart contracts:
    • ERC-1155: A URI for all token types that relies on ID substitution, such as https://token-cdn-domain/{id}.json.
    • ERC-721: A URI where all tokens share a prefix (a base URI) followed by a token URI, such as http://api.myproject.example.com/token/<tokenURI>.

    You can use the Remix IDE to generate an application binary interface (ABI) for the smart contract. The ABI can then be used with the atomicTransactions API. If you change any method in the smart contract, you must recompile the contract and generate the ABI again.

For more information about the parameters to use for Ethereum transactions in an atomic workflow, including an example of transferring an NFT to an Ethereum network, see Atomic Transactions REST Endpoints.