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:
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.
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.
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:
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.
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:
All this and many other innovative capabilities show the power of Oracle blockchain to support your tomorrow today.
Mark is responsible for product management and development of mission-critical solutions in Fintech, Blockchain, and Transaction Management. He leads the product group with a portfolio that includes Oracle Tuxedo, Oracle Blockchain Platform, MicroTx, and Fintech Data Platform. These include multiple offerings available in OCI, on-premises, and multicloud environments to meet the needs of enterprise customers and partners for scalable, secure, production-ready platforms to support mission-critical applications across many industries and in public sector. He helps to guide customers and partners around the world in applying these technologies to deliver key business outcomes – accelerating growth, reducing costs and friction in business ecosystems, reducing risk and fraud, and bringing to market innovative solutions that solve real-world societal challenges. Mark facilitates customers’ journey from rapid experimentation to live production through discovery, sharing industry use cases and best practices, and advising on solution architecture.