Latest OCI Blockchain Platform update enables blockchain interoperability and brings Web3 capabilities to OCI

New Release Overview

Growing momentum of enterprise blockchain use cases drives the need for interoperability between the blockchain platform and other systems, including other blockchain ledgers.  To better support our customers' and partners' requirements, 22.4.2 release of Oracle Blockchain Platform and its low-code Blockchain App Builder provides a number of new capabilities to arm developers building sophisticated blockchain solutions. Main features in this release include:

• OAuth 2.0 support for REST proxy event callbacks to enable callback delivery authenticated by the subscribing organization's Identity Providers. This extends the current security model based on mutual TLS (certificate exchange) with an OAuth 2.0 security token option for integrating members in consortium networks that need to have event callbacks delivered to their OAuth token-secured enterprise systems.
• More popular web3 API support for OBP users running Solidity smart contracts using an Ethereum Virtual Machine (EVM) on OBP nodes. As more users started taking advantage of these capabilities, this release has certified Fab3 provider for web3 JSON RPC API, making it easier to work with Solidity smart contracts using standard web3 interfaces.
• Ethereum interoperability enabling developers to combine OBP native smart contract transactions with Ethereum/EVM smart contract transactions in a single atomic operation. This feature extends REST proxy orchestration with Ethereum client to enable invoking Ethereum/EVM-based smart contracts as part of the 2PC-based atomic transaction support released previously. Atomic commits ensure both sides are committed on the leger, or, if either side fails, none are committed.
• Extending tokenization SDKs and generated chaincodes in Blockchain App Builder to support the new ERC-1155 specification that allows fungible and non-fungible tokens to be defined in a single template and run in a single chaincode. This multi-token capability, including batch transfers, simplifies more advanced tokenization solutions.
• Extending the TTF-based tokenization SDK to support exchange across different fungible tokens on OBP, which enables more complex financial use cases for banks handling multiple currencies or rewards systems with different brands loyalty points that can be exchanged.

This release is in production deployments at all supported OCI regions today, and can be used by provisioning new OBP instances or upgrading existing ones to the latest release.  For detailed documentation on these features see the latest What’s New for Oracle Blockchain Platform.

OAuth2 secure token support

OBP has always supported OAuth2 for inbound REST API requests, but the callbacks triggered by event subscriptions were secured by mutual TLS, which depended on X.509 certificates that a subscribing system had to issue to OBP, and OBP had to include in the callback process.  While a very secure approach, issuing and renewing X.509 certificates requires some effort and not all participating parties are able to run PKI systems necessary for this purpose.  To make it easier for diverse participants to join the blockchain consortia and use event notifications/callbacks to integrate with their back-office systems, we looked at providing additional security options that are simpler and more broadly accessible.  OAuth2 tokens are widely used when connecting systems across company boundaries and their tokens can be automatically issued or refreshed through many Identity Management (IdM) solutions.

To use OAuth2 tokens for event subscription callbacks, you have to specify the relevant client ID, client secret, and scope parameters for the target system’s OAuth server when registering an event subscription using an “oauth” parameter structure:

"oauth": {
      "clientID": "my-client-id",
      "clientSecret": "my-client-secret",
      "tokenUrl": "https://identity.example.com/oauth2/v1/token",
      "authInHeader": true,
      "scopes": ["urn:opc:idm:__myscopes__"]
  }

Web3 API support

Web3 API refers to the APIs used by the open source web3.js library, which is a collection of modules that allow you to interact with a local or remote Ethereum node or one emulated by an Ethereum Virtual Machine (EVM). OBP has long supported an EVM option, enabling Solidity developers to easily deploy and run their smart contracts on OBP in a private Ethereum model. In the past, these interactions between the client dApps and Solidity smart contracts were possible through a Remix Ethereum IDE or OBP REST proxy API. However, with growing popularity of web3, more developers want to be able to take advantage of this de-facto standard to interact with smart contracts on multiple networks, including OBP.

In order to support that, this release supports a Fab3 module built as a gateway between web3.js library and Hyperledger Fabric.  It exposes web3 JSON-RPC APIs to external clients and internally maps these requests through the Hyperledger Fabric client SDK to gRPC calls to EVMCC chaincode on OBP nodes, enabling interaction with Solidity smart contracts deployed in EVMCC runtime.  This enables standard web3-based clients, such as crypto wallets and other dApps to work with Solidity/EVM contracts on OBP.

Ethereum Interoperability with Atomic Transactions

The worlds of public and permissioned blockchains are growing closer together. More customer and partner solutions embrace both types of distributed ledgers to meet complex requirements, where the performance and confidentiality of permissioned blockchain is as important as broader reach and liquidity of the public blockchains. Oracle blockchain vision fully embraces this interoperability and this release enables it through the orchestration capabilities of OBP REST proxy.

In the last release we provided an atomicTransaction feature that enabled applications to invoke multiple OBP smart contracts on the same channel or across different channels as a single atomic operation based on 2-Phase Commit (2PC) protocol. It ensured that all the transactions would commit together, or, if any failed, all would be rolled back. While this was a significant innovation within Hyperledger Fabric world, we didn’t stop there.  With this release developers can extend the list of smart contracts in atomicTransaction API with a single Ethereum (or EVM-based) smart contract, and still achieve the same atomic result – all succeed or all get rolled back. 

You might ask how this is possible, since Ethereum, unlike OBP, doesn’t support 2PC protocol for orchestrating atomic transactions.  The answer lies in LRC (Last Resource Commit) optimization of 2PC.  It essentially enables one non-2PC resource to be included in the 2PC-based global transaction.  After the “prepare” phase of the OBP transactions, REST proxy uses a built-in Geth client to execute an Ethereum smart contract transaction and wait for its commit (based on finality rules parameters provided in the API).  If it commits, the related OBP transactions then go through their own “commit” phase.  If it fails, then the “prepared” OBP transactions are rolled back.  Thus we extend the atomicTransaction API with an “lrc” segment that specifies an Ethereum contract to invoke and a set of parameters related to Ethereum invocation, including the finality parameters on how many blocks or how long to wait for the commit on Ethereum side.

The following example shows the API details with transactions array for OBP chaincode invocations and lrc section for Ethereum contract invocation.  The lrc section includes an ethReq section for signed or unsigned transaction request, and a finalityParams section, which determines how long to wait for transaction finality.

{
 "transactions": [
  {"chaincode":"bt1","args":["invoke", "a", "b", "7"],"timeout":0, "channel":"ch1"},
  {"chaincode":"bt2","args":["invoke", "a", "b", "5"],"timeout":0, "channel":"ch2"}
 ],

 "lrc": {
   "ethReq": {
     "url": "http://<IP address of Ethereum server>:<port>",
     "chainId": 1337,
     "unSignedReq": {
        "privateKey": "de1fab4e05b476f81d11901a69e58a3000859395eb6bdb222fcb583b8d599b00",
        "ethValue": "1000000000000000000",
        "gasLimit": 21000,
        "toAddress": "0x7336d04f97fdccd0a93462947474c8879a5c6597"
     },
     "finalityParams": {
       "checkFinality": true,
       "blocksToWait": 2,
       "secondsToWait": 30
     }
   }
 },
 "isolationLevel": "serializable",
 "prepareTimeout": 10000,
 "sync": true
}

The unSignedReq section above can also be replaced with a signedReq:

"ethReq": {
            "url": "<a href="https://goerli.infura.io/v3/d0263407d1bc4fff9658f420b9e6b5bc">https://goerli.infura.io/v3/d0263407d1bc4fff9658f420b9e6b5bc</a>",
            "chainId": 5,
            "signedReq": { 
                "signedTxHex" : "02f8950506841ad2748084476807808401406f409442efb56de8e6a516fff899c9263ef3d21ffd9c298502540be400a4e3456fa90000000000000000000000000000000000000000000000000000000000000001c080a074c985cce323b924e5503592a1301e301c4a3fa4c55234cf60b2782dce81e825a0605b9f61113057e02f614b4d2a52fc5953719aec30743ff4d8b7e2bbf3a206b5"
            },
            "pendingTimeout": 420,
            "finalityParams": {
                "checkFinality": true,
                "blocksToWait": 10,
                "secondsToWait": 20
            }
        }

The result of the Ethereum transaction can be seen in this Etherscan view from Goerli Testnet.

Ethereum interoperability with atomic transactions support enables a number of scenarios to support numerous interoperability use cases:

• Atomic asset exchange
  • Pre-fund OBP fungible tokens using ETH or ERC-20 tokens
  • Use ETH or ERC-20 tokens to pay for NFTs minted and traded on Oracle Blockchain
  • Prep and mint NFT on Oracle Blockchain, allow NFT buyer to transfer to Ethereum or another Solidity/EVM-based network for secondary market liquidity
• Use OBP tokens to track public chain token balances across multiple ledgers or marketplaces
• OBP transaction processing using confidential business data generates an event that triggers an Ethereum smart contract, e.g., to process payment or other complex business processes
• OBP transaction based on confidential on-ledger data has its hash published on Ethereum as public proof without disclosing any confidential transaction details

ERC-1155 Support

Beyond the initial ERC-721 spec for NFTs, a number of new specs have been proposed that extend NFTs in a variety of ways to handle more complex use cases, greater regulatability, etc. One of the more popular extensions in ERC-1155, which combines fungible and non-fungible tokens in a single contract, supports batch transactions across multiple tokens, and provides more dynamic NFT properties. As a leading low-code blockchain development tool our Blockchain App Builder now allows you to specify ERC-1155 tokens by using “standard: erc1155+” in a token template and defining multiple assets, that can include fungible and non-fungible tokens as well as non-token assets. A sample template using "erc1155+" standard is included with the latest version of the Blockchain App Builder.

As a multi-token digital asset specification, ERC-1155 combines the best of ERC-20 (fungible) and ERC-721 (non-fungible) assets in a single contract, and allows you to convert fungible tokens to NFTs (e.g., pay for an NFT with certain number of loyalty points or coins). With a single ERC-1155 chaincode, a user account can create and hold multiple fungible and NFT token assets, unlike ERC-721 which has a single NFT linked to an account. ERC-1155 also provides for batch transfers via a single smart contract method and provides greater security by allowing safe transfer functions to verify transaction validity and reverse the transaction if it’s not valid. Batch transfers make it not only easier and faster to transfer multiple assets, but open the door to more complex NFT instruments. And the ability to convert between NFTs and fungible tokens in a single operation is going to optimize a number of NFT- related transactions and enable new tokenization use cases. 

What about that “+” in “erc1155+” standard?  Just like with ERC-721 we have extended ERC-1155 to include burn method, account management features (creating, associating, suspending, and resuming custodial accounts on-chain), and role-based security to control who can mint and burn these tokens. Look for a more detailed post on ERC-1155 features soon. 

Token exchange for TTF-based fungible tokens

Some of the more popular use cases for fungible tokens are in financial sector, where tokens represent digital currency, or in rewards programs where they represent loyalty points for different brands. In both of these areas, exchange between currencies or exchange of loyalty points between brands is an important requirement.  There are a few approaches to exchanging tokens, and we selected one of the fastest growing mechanisms known as exchange pools (a.k.a. liquidity pools.) Exchange pools are modeled on an equivalent of a liquidity pool concept in the financial system or cryptocurrency – these are just accounts maintained by a trusted party that contain multiple currencies. They can be funded by any other parties called Liquidity Providers who transfer funds to an exchange pool, usually in exchange for fees collected from exchange pool users. However, instead of having to rely on external liquidity pools, we enable users to create and fund them directly on OBP ledger as part of our tokenization engine and enable liquidity providers to join OBP as members to transfer funds into OBP exchange pools.

To use token exchange method you need to first invoke the methods to set up the exchange pool facility and set the conversion rate. Then liquidity providers from multiple token systems can transfer tokens into it, which funds the exchange pool accounts. Once ready, the exchange itself is done with a single method call:

TokenConversion(from_token_id string, to_token_id string, to_org_id string, to_user_id string, token_quantity float64)

For example: TokenConversion(“TokX”, ”TokY”, “Account2”, “Account2_user”, 10)

When invoked via this API the tokenization SDK then initiates an exchange transaction from Account 1 (the invoker) for 10 units of TokX to be delivered to Account2 as TokY. Under the covers, this involves transferring 10 TokX to the exchange pool account, where it’s credited and a corresponding amount of TokY (based on the exchange rate set through the pool API) is debited from the exchange pool and is transferred to the target account.

For example, let’s say we have one token named USD and another one EUR, and an exchange pool defined for USD and EUR funded with 100 units of USD and 70 units of EUR, and a conversion rate set at 0.95 EUR to 1 USD.  We can invoke a transfer method from Account 1 for 10 USD for delivery to Account 2 in EUR.  This would debit Account 1 10 USD tokens, credit these to the exchange pool USD account, debit exchange pool EUR account 10.52 EUR tokens (10/0.95), and credit this amount to Account 2 in EUR.  As the result, the total amounts of USD and EUR in the system remain as they were before the transaction, and we have achieved an exchange by crediting and debiting the required amount within the exchange pool accounts. This mechanism is similar to market makers used in foreign exchanges with systemic banks often providing liquidity pool services. With our token exchange, you can implement a multi-currency CBDC system or any financial instruments that need to operate in a multi-currency world.

Summary

The complexity of blockchain use cases is on the rise, and with it comes a strong need for interoperability – with other enterprise systems and across multiple blockchain technologies.  Making this not only functional, but easy-to-use and easy-to-secure is a challenge facing many blockchain platforms. The latest Oracle Blockchain Platform release addresses these challenges head on in the following ways:

• OAuth2 token support makes enterprise integration of event callbacks easier to secure within the member's enterprise IdM ecosystem and more broadly appealing. 
• Being able to execute multiple transactions across different blockchain channels in an atomic manner is crucial to many use cases. No blockchain implementations other than Oracle Blockchain Platform supports such use cases without the need to change existing chaincodes and/or to introduce complex, and vulnerable bridging solutions.
• With Fab3 provider for web3 JSON-RPC APIs we’ve made it easier to integrate common crypto wallets and dApps with Solidity/EVM contracts on OBP.  You can use this to run a private Solidity/Ethereum solution on the managed OBP service in OCI and integrate with standard wallets and other dApps.
• As NFTs move beyond digital art and collectibles, more advanced capabilities are needed to model different forms of assets, combining both fungible and non-fungible capabilities. With ERC-1155 we are enabling developers to take full advantage of the latest approaches to making NFTs more useful and easier to adapt to real-world use cases.
• And with fungible token exchange, we are enabling digital currency or rewards programs to easily operate in a multi-currency or multi-brand world leveraging OBP-supported exchange pools mechanism.

All this and many other innovative capabilities show the power of Oracle blockchain to support your tomorrow today.