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:
- 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: - 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 amintNFT
method, which creates NFTs with custom properties such as price and token history, which can be fetched from the output of theburnNFT
method in the previous step.For unsigned requests, if the custom properties are in theParamKeys
parameter and corresponding dynamic parameters are passed in theparams
parameter, the atomic transactions API can fetch the parameters from theburnNFT
method and send them to the Ethereum smart contract. ThemintNFT
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 nottoken2
.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.