※本記事はMark RakhmilevichによるBlockchain Interoperability is the focus of the latest Oracle blockchain update（2023/1/9）を翻訳したものです。

新機能の概要

エンタープライズブロックチェーンのユースケースの拡がりにより、他のブロックチェーン台帳を始めとする他システムとブロックチェーンプラットフォームとのインターオペラビリティへのニーズが増しています。われわれのお客様とパートナーの要望をよりよくサポートするために、Oracle Blockchain Platform（→OBP）および付属ローコードツールBlockchain App Builderのバージョン22.4.2リリースでは、開発者たちが洗練されたブロックチェーンソリューションを構築できるようないくつかの新機能を提供しています。このリリースでの主だった追加／変更点は：

  • RESTプロキシのイベントコールバックで、OAuth 2.0がサポートされました。これにより、サブスクライブした組織のアイデンティティ・プロバイダによってコールバックを認証できるようになりました。これまでの相互TLS（証明書交換）をベースとしたセキュリティモデルに加え、OAuth 2.0セキュリティトークンのオプションが増えたことにより、コンソーシアム・ネットワークのメンバーを集約して扱っているような場合に、イベントコールバックをそれらメンバー自身のOAuthトークンを必要とするエンタープライズシステムに届けられるようになります。
  • OBPノード上でEthereum Virtual Machine（→EVM）を用いてSolidityスマートコントラクトを実行しているOBPユーザーのために、よりポピュラーなweb3 APIのサポートが追加されました。この機能を活用するユーザーも増えてきており、このリリースではweb3 JSON RPC APIプロバイダのFab3をサポートしました。スタンダードなweb3インタフェースを用いることでSolidityコントラクトをよりかんたんに扱えるようになるでしょう。
  • OBPのネイティブなスマートコントラクトのトランザクションと、Ethereum/EVMスマートコントラクトのトランザクションを単一のアトミックなオペレーションにまとめられるというEthereumとのインターオペラビリティ機能が追加されています。これは、RESTプロキシによるオーケストレーションの範囲にEthereumクライアントを加えることで、従前リリースされていた2PCベースのアトミックトランザクションに、Ethereum/EVMベースのスマートコントラクトのトランザクションを実行することができます。アトミックトランザクションは、両方の側で台帳上にコミットされるか、いずれかの側で失敗した場合にはいずれもコミットされないことを担保します。
  • Blockchain App BuilderでのトークナイゼーションSDKを用いたChaincodeの生成が、新たにERC-1155仕様のトークンをサポートしました。これにより、ファンジブルとノンファンジブルのトークンをひとつのテンプレートの中で定義し、単一のChaincodeとして稼働させられます。バッチ移転も含まれたこのマルチトークン機能により、より発展的なトークナイゼーションのソリューションをシンプルに開発できるようになるでしょう。
  • TTF（Token Taxonomy Framework）ベースのトークナイゼーションSDKが、OBP上での異種ファンジブルトークンの交換をサポートしました。これにより、銀行が複数の通貨を扱ったり、交換可能な複数種類のロイヤリティポイントを扱うリワードシステムといったような、より複雑な金融のユースケースを扱えるようになります。

この新バージョンのリリースは本日、すべてのサポートされたOCIリージョンで利用可能になっており、新規にプロビジョニングされるOBPインスタンスおよび既存のインスタンスのアップグレードの両方で利用可能です。機能追加の詳細はWhat’s New for Oracle Blockchain Platformをご覧ください。

OAuth2セキュアトークンのサポート

OBPはインバウンドのREST APIリクエストについてはOAuth2をこれまでもサポートしてきましたが、イベントサブスクリプションでトリガーされるコールバックについてはサブスクライブするシステムがOBPに発行するX.509証明書を用いた相互TLSによって認証されており、OBPは証明書をコールバックプロセスに含める必要がありました。とてもセキュアなやり方ではあるものの、X.509証明書の発行と更新には多少手間がかかり、また、参加する組織すべてがこれに必要となるPKIシステムを運用することができるわけではありません。より様々な参加者がブロックチェーンコンソーシアムに参加し、バックオフィスシステムとの連携のためにイベント通知／コールバックを利用することを容易にするためには、よりシンプルでより広く利用可能なセキュリティオプションを提供する必要がありました。OAuth2トークンは企業の垣根を越えたシステム接続に広範に使われており、多くのIdentity Management（IdM）ソリューションによって自動的に発行、更新することができます。

OBP Rest Proxy OAuth2 support for event callbacks
OBP RESTプロキシのOAuth 2.0トークンサポートを用いたイベントコールバックのリクエスト／レスポンスフロー

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:

OAuth2トークンをイベントサブスクリプション・コールバックに用いるには、対象のクライアントID、クライアントシークレット、および対象システムのOAuthサーバーのスコープ・パラメータをイベントサブスクリプションを登録する際の”oauth”パラメータ構造体に指定する必要があります：

"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のサポート

Web3 APIとはオープンソースのweb3.jsライブラリによって用いられるAPIです。このライブラリはローカルあるいはリモートのEthereumノード、またはEthereum Virtual Machine（EVM）によってエミュレートされるノードとやり取りするためのものです。OBPは長らくEVMオプションをサポートし、Solidity開発者たちがプライベートEthereumの作法でスマートコントラクトをOBP上にデプロイできるようにしていました。これまでは、クライアントであるdAppsとSolidityスマートコントラクトとのやり取りはRemix Ethereum IDEまたはOBP RESTプロキシAPIを経由して可能でした。しかし、web3の普及に伴い、多くの開発者たちがこのデファクトスタンダードとなったライブラリを用いてOBPを含め複数のネットワークとやり取りすることを望んでいました。

こうした要望を受けて、リリースされた新しいバージョンではweb3.jsライブラリとHyperledger Fabricとの間のゲートウェイとなるFab3モジュールをサポートしました。Fab3はweb3 JSON-RPC APIを外部のクライアントに対して公開し、受けたリクエストをHyperledger FabricクライアントSDKでOBPノード上のEVMCC ChaincodeへのgRPCへとマッピングします。これにより、EVMCCランタイム内にデプロイされたSolidityスマートコントラクトとのやり取りが可能になります。そうすることで、暗号資産ウォレットや他のdAppsといったスタンダードなweb3ベースのクライアントがOBP上のSolidity/EVMコントラクトとやり取りできるようになるというわけです。

Web3 JSON-RPC API enablement using Fab3 provider with OBP EVM support
Fab3プロバイダとOBPのEVMサポートを用いたweb3 JSON-RPC APIの活用

アトミックトランザクションのEthereumとのインターオペラビリティ

パブリックとパーミッションドブロックチェーンの世界はお互いに近づいています。複雑な要件に対応するために、多くのお客様とパートナーのソリューションがこのふたつのタイプの分散台帳を含むようになっており、そこではパーミッションドブロックチェーンのパフォーマンスと秘匿性が、そしてパブリックブロックチェーンの広い普及と流動性がともに重要です。Oracleのブロックチェーンに対するビジョンには、パブリックとパーミッションドのインターオペラビリティが含まれており、そしてリリースされた新バージョンはOBP RESTプロキシのオーケストレーション機能によりそれを実現しています。

ひとつ前のバージョンで追加されたアトミックトランザクション機能は、同一のChannelまたは複数のChannelでの複数のスマートコントラクト実行を、2フェーズコミット（2PC）プロトコルベースの単一のアトミックなオペレーションにまとめてアプリケーションが実行することを可能にするものでした。これはすべてのトランザクションがコミットされるか、いずれかのトランザクションが失敗した場合にはすべてのトランザクションがロールバックされるか、のふたつのうちどちらかになることを担保するものです。この機能はHyperledger Fabricの世界では重要なイノベーションでしたが、われわれはそこで満足したりはしません。リリースされた新バージョンでは、atomicTransaction APIに含められるスマートコントラクトのリストの中に、ひとつまでのEthereum（あるいはEVMベースの）スマートコントラクトを含められるようになりました。もちろん全部が成功／ロールバックされるというアトミックな結果の担保はそのままです。

OBPとは異なり、Ethereumはアトミックトランザクションのオーケストレーションに使われる2PCプロトコルをサポートしているわけでもないのに、どうしてこんなことが可能なのかと疑問に思うかもしれません。答えは2PCのLRC（Last Resource Commit）最適化にあります。かいつまんで言うとLRC最適化は、2PCベースのグローバルトランザクションに、ひとつの非2PCリソースを参加させられます。OBPでのトランザクションの”prepare”フェーズが終わったあとに、RESTプロキシは組み込まれたGethクライアントを用いてEthereumスマートコントラクトを実行し、（APIパラメータとして指定されたファイナリティルールに沿って）コミットを待ちます。これがコミットされた場合には、他のOBPトランザクションもそれらの”commit”フェーズに進みます。Ethereumトランザクションが失敗した場合には、”prepared”となっていたOBPトランザクションはロールバックされます。これを実現するために、atomicTransaction APIが拡張され、実行するEthereumコントラクトを指定する”lrc”のセクション、および、Ethereum側のコミットとしていくつのブロックあるいは何秒待つかを含む、Ethereum実行に関連するパラメータが追加されています。

Ethereum interoperability with OBP orchestrated by OBP REST Proxy
OBP RESTプロキシがオーケストレーションするOBPとEthereumとのインターオペラビリティ

以下のAPI実行の例は、transactionsの配列でOBPでのChaincode実行を指定し、lrcセクションでEthereumコントラクトの実行を指定しています。lrcセクションにはethReqセクションが含まれ、これには署名付き／署名なしトランザクションリクエストと、トランザクションのファイナリティをどの程度待つかを指定するfinalityParamsが含まれています。

{
"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
}

上の例でunSignedReqだったセクションは、以下のように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
            }
        }

上の例でのEthereumトランザクションの結果は、EtherscanでGoerli Testnetを見ると確認できます。

Etherscan view of an Ethereum transaction from Oracle Blockchain Platform
OBPのグローバルアトミックトランザクションの一部として実行されたEthereumテストネットでのトランザクションをEtherscanで表示

アトミックトランザクションのEthereumインターオペラビリティサポートは、インターオペラビリティを活用する様々なユースケースにつながります：

  • アセットのアトミックな交換
    • ETHやERC-20トークンを用いたOBP上のファンジブルトークンのプレ・ファンディング
    • OBP上でミント、取引されるNFTの支払いにETHやERC-20トークンを使用
    • OBP上でNFTのセットアップとミントをしつつ、NFTの購入者がEthereumや他のSolidity/EVMベースのネットワークにNFTを移送できるようにし、セカンダリ市場での流動性を得る
  • 複数の台帳やマーケットプレイスをまたがるパブリックブロックチェーン上のトークンのバランスをOBPトークンを使ってトラックする
  • OBPトランザクションで秘匿が必要なビジネスデータを処理し、その結果のイベントをもってEthereumスマートコントラクト（支払いやその他の複雑なビジネスプロセス）をトリガーする
  • OBP上の秘匿されるデータそのものは明かすことなく、そのハッシュ値のみをEthereum上にパブリックな証跡として記録させる

ERC-1155のサポート

NFTについては、初期のERC-721仕様以降、より複雑なユースケースや、より適切な規制可能性などのため、NFTを様々な方法で拡張するいくつかの仕様が提案されてきました。そうした中で最も普及したのがERC-1155で、これはファンジブルトークンとノンファンジブルトークン（NFT）をひとつのコントラクトにまとめ、また、複数のトークンをまたがるバッチトランザクションをサポートし、NFTのよりダイナミックなプロパティを実装可能にするものです。先進的なローコード・ブロックチェーン開発ツールであるBlockchain App Builderで、ERC-1155仕様を指定することができるようになりました。トークンテンプレートで“standard: erc1155+”を選択し、複数のアセットを定義（ファンジブルトークンとノンファンジブルトークン、そして非トークンアセットを含められます）することができます。Blockchain App Builderの最新バージョンには、”erc1155+”標準を用いたテンプレートのサンプルが含まれています。

複数トークンデジタルアセット仕様として、ERC-1155はERC-20（ファンジブル）とERC-721（ノンファンジブル）アセットの良いところをひとつのコントラクトにまとめ、ファンジブルトークンのNFTへの変換ができるようになっています（例：NFTに対して一定の数量のロイヤリティポイントやコインで支払い）。ERC-721ではひとつの口座にひとつのNFTしかリンクできなかったのに対し、単一のERC-1155 Chaincodeでは、複数のファンジブル／ノンファンジブルトークンアセットを保持できるユーザー口座が作成できます。ERC-1155ではまた、単一のスマートコントラクトメソッドによるバッチ移転と、セーフトランスファー関数による安全な移転も提供しています。バッチ移転は複数のアセットの移転をより容易で迅速に行えるようにするだけでなく、NFTを用いたより複雑な仕掛けを可能にするものです。そして単一のオペレーションでのNFTとファンジブルトークンとの変換機能は、NFTに関するトランザクションの手数を最適化し、新たなトークナイゼーションのユースケースを開拓するでしょう。

Evolving tokenization specs
トークナイゼーション仕様の進化

“erc1155+”標準のプラスの部分は何かって？ERC-721を拡張したように、burnメソッドの追加、口座管理機能（オンチェーンのカストディアル口座の作成、関連付け、サスペンド、再開）、および誰がトークンをミントしたりburnするかを制御するロールベースのセキュリティ機能などをERC-1155に追加することで拡張しています。ERC-1155関連機能の詳細については別のポストで説明しますのでお楽しみに。

TTFベースのファンジブルトークンとのトークン交換

ファンジブルトークンのユースケースでよりポピュラーになっているもののいくつかは金融領域のもので、そこではトークンはデジタル通貨を表現していたり、あるいはリワードプロフラムの中でさまざまなブランドのロイヤリティポイントを表現したりしています。こうした領域では、通貨同士の交換、ブランドをまたいだロイヤリティポイント同士の交換は、重要な要件のひとつです。トークンの交換のアプローチはいくつかありますが、われわれは「交換プール」あるいは「流動性プール」として知られている、現在最も発展している仕組みを選びました。交換プールというのは、金融システムや暗号資産の領域で流動性プールと呼ばれるコンセプトと同一です。それらはつまるところ、信頼された組織によって管理される、複数通貨を保持する口座です。流動性プロバイダと呼ばれる他の組織によって資産が提供されることもあり、その場合、交換プールユーザーから集めた利用料の一部を手数料として受け取るため、交換プールに資産を提供することが一般的です。外部の流動性プールに頼る代わりに、OBPのトークナイゼーションエンジンの一部として、OBP台帳上で直接流動性プール口座を作成し資金を入れることを可能にし、また、流動性プロバイダがOBPにメンバーとして参加してOBP交換プールに資金を移転することができるようにしました。

トークン交換メソッドを使うには、まず交換プールのセットアップメソッドを実行し、交換レートを設定しておく必要があります。すると、流動性プロバイダはプールにトークンを送れるようになります。準備ができれば、交換自体は以下のメソッドを呼ぶだけです：

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

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

この例のようにAPIが呼び出されると、トークナイゼーションSDKはAccount 1（実行者）からTokXを10単位取り出し、Account 2にTokYとして移転します。裏側では、10 TokXを交換プール口座に送り、（設定された交換レートに則って）対応する量のTokYが交換プールから目的の口座（Account 2）に払い出されています。

Exchange pool mechanism in Oracle blockchain tokenization engine
Oracle Blockchainのトークナイゼーションエンジンにおける交換メカニズム

例えば、USDというトークンとEURというトークンを持っているとしましょう。そしてUSDとEURとの交換プールがありそこにUSDが100、EURが70溜まっていて、交換レートは0.95 EURに対し1 USDだとしましょう。Account 2へ10 USDをEURに交換しつつ送る移転メソッドをAccount 1から実行したとします。これはAccount 1から10 USDトークンを払い出し、交換プールのUSD口座に入れ、交換プールから10.52 EURトークンを払い出し、それがAccount 2に入れられます。結果として、システム全体のUSDとEURの総額はトランザクションの前と変わっておらず、交換プールを用いて送金、交換ができました。このようなやり方は外為マーケットで使われるマーケットメーカー、銀行による流動性プールへの流動性供給といった仕組みと似ています。このトークン交換の仕組みを用いて、複数通貨CBDCシステムや、複数通貨を扱わなければならないようなその他の金融のツールを実装できるでしょう。

まとめ

ブロックチェーンのユースケースはより複雑なものになってきており、それに伴って、他のエンタープライズシステムとの連携や、複数ブロックチェーンまたぎなどのインターオペラビリティへのニーズも強まっています。インターオペラビリティを、ただやればできるというだけではなく、かんたんに使いこなせて、安全に使えるものにする、というのは多くのブロックチェーン基盤にとっての課題です。Oracle Blockchain Platformの最新のリリースは、こうした課題を他に先んじて以下のように解決しています：

  • OAuth2トークンのサポートにより、エンタープライズIdMのエコシステムにイベントコールバックが組み込みやすくなり、より広く使いやすくなりました。
  • 複数のChannelにまたがった複数のトランザクションをアトミックに実行できるというのは多くのユースケースで非常に重要です。Oracle Blockchain Platform以外のブロックチェーン実装では、既存のChaincodeを変更したり、複雑で脆弱になりやすいブリッジソリューションを持ち込んだりすることなしに、そうしたユースケースをサポートすることはできていません。
  • web3 JSON-RPC APIのFab3プロバイダにより、一般的なタイプのウォレットやdAppsをOBP上のSolidity/EVMコントラクトとつなげられるようになります。これにより、OCI上のマネージドなOBPサービスでプライベートSolidity/EVMソリューションを稼働させつつ、一般的なウォレットやdAppsと連携させられます。
  • デジタルアートやコレクティブルを越えてNFTが発展するにつれ、ファンジブルとノンファンジブルの両方の特性を合体させ、より多くの形態のアセットをモデル化するための発展的な機能が求められるようになってきています。ERC-1155により、開発者は実ユースケースにより便利で容易に対応したNFTを開発するための最新のアプローチを活用できるようになります。
  • ファンジブルトークンの交換により、複数通貨を扱うデジタル通貨ユースケースや、複数ブランドのリワードプログラムユースケースなどを、交換プールの仕組みを活用しながらより容易に運用できるようになります。

これらの、そしてその他のイノベーティブな機能が、あなたの未来を支えるOracle Blockchainの力を示しています。