LayerX Newsletter for Tech (2019/06/24–06/30)

Issue #13

CommentShare

今週の注目トピック

Lightning NetworkにおけるチャネルCapacity調整を可能にするLoopのリリースを始めとして、分散オラクルネットワークChainlinkや、Clauseの取り組む契約自動執行について紹介しています。

Section1: PickUp

●Lightning Labs、Loop Outに続いてLoop Inを発表

  • Lightning Networkでは、最初にPaymentChannelを開設してデポジットを行い、これをチャネルのCapacityとして オフチェーン決済を行う。そのため、「Capacityを超える金額の送金ができない」「受取額がCapacityに到達したため受け取れない」あるいは「残高がゼロになったので送金できない」という状況が発生すると、チャネルを一旦閉じて、新規Capacityのチャネルを開設することが必要になるといった課題があるとされる。

  • このように既存のチャネルを開設したまま「残高やCapacityを補充する」ことができないか、というニーズがあるほか、 チャネルの閉鎖・開設を繰り返すことは、ルーティングノードにとってもチャネルバランス管理の負担になりチャネルグラフが同期しにくくなるなど、ルーティングの信頼性が低下する問題がある。

  • そこで、Lightning Loopでは、チャネルを開設したままCapacity増加できる「Loop Out」や、チャネルを開設したまま残高補充できる「Loop In」を可能にするといった、オンデマンドでLightningチャネル管理をサポートする。

  • 先にリリースされた「Loop Out」では、Capacity上限に到達しそうになったらオフチェーンチャネルからオンチェーンへ資金を流すことによって、Lightningペイメントを受け取りやすくする。この度リリースされた「Loop In」では、Lightningウォレットの残高が減ってきたらオンチェーンのウォレット・取引所などからオフチェーンチャネルへ資金を再充填することによって、Lightningペイメントを送金しやすくなるのが特徴。

  • このLightning Loopのベースには、トラストレスにアセットの交換を二者間で行う「Atomic Swap」がある。アセットの交換取引を二者間で行う場合、どちらか一方が相手を信頼して先にアセットを渡す必要があるが、持ち逃げされてしまうかもしれない。そこで「両者が同時に欲しいアセットを手に入れ、且つ一方だけが両方を手にする瞬間が無い」ようにスマートコントラクトを用いて取引するのが「Atomic Swap」(類似した金融取引にDvP（Delivery Versus Paymentの略)がある)。

  • これを応用して、オンチェーン／オフチェーンの資金交換をトラストレスに行うのが「Submarine Swap」。オンチェーンBitcoinプラットフォームとオフチェーンのLightning Networkの間で相互互換性を持たせてBitcoinをやりとりすることを可能にする。

  • このように、Submarine SwapをベースとしたLightning Loopを用いることによって、オンチェーン・オフチェーン間の融通をスムーズに行うことができるようになるため、開発者はチャネルのCapacityを気にせずにサービスを開発可能になるだけでなく、無駄なチャネル開閉を減らすことでネットワーク安定にも寄与できる可能性がある。

  • 直近では、BitrefillがAPIを通じてLightningチャネルへBitcoinを再充填できるサービスをリリースした。例えば、仮想通貨交換業者のユーザーがLightningチャネルへBitcoinを送って利用可能なサービスのように、任意のプラットフォームをLightningサービスとインテグレートすることが可能になる。これまで無かったようなサービスが生まれてくることに期待したい。

●Oracle、分散オラクルネットワークChainlinkと提携発表

  • 現時点において、必ずしも今すぐにブロックチェーンを必要としないと考えている企業は数多い。しかし、各社が保有するデータには、フライト遅延保険のトリガーとなるフライトデータやブランド横断での在庫リバランスのトリガーとなる在庫・ロケーションデータのように、スマートコントラクトを介したプログラマブルな取引自動執行のインプット（オラクル）のデータソースとして価値が高いものも多々ある。

  • そこで、各社の保有するデータをブロックチェーンのエコシステムに接続することを通じて、各社にマネタイズしてもらおうという狙いで、Oracle社が分散オラクルネットワークのChainlinkと提携を発表した。

  • データ提供対価の支払いという観点からも、ブロックチェーンを介したエコシステム上では法定通貨やクリアリング業者などを介さずに決済を行うことが可能なため、早期・安価に報酬支払いを受けることができる利点がある。

  • 外部のデータリソースにアクセスできないスマートコントラクトに対してエージェントとして現実世界の情報を提供して実行のトリガーにするのが「オラクル」。オラクルは単一障害点を持つサードパーティサービスなので、オラクルから得られたデータは信頼できるのかという問題がある。分散オラクルネットワークを提供するChainlinkは、各種データソースからのインプットをもとにオラクルサービス提供者が提示したデータを受けて、それが「オラクル」としてスマートコントラクト実行トリガーとなる前に、データの認証を行うもの。

  • 「オラクル」および「データソース」の２面から分散化を図っている。
    「オラクルの分散化」としては、開発者が任意の数のオラクルノードを用いること選択できるようにすることによって、単一オラクルがオフラインになった場合への備えだけでなく、単一オラクルがハッキングや賄賂の対象になった場合に備える。一方「データソースの分散化」としては、オラクルが複数ソースからデータを収集したデータに対して、平均を使ったり外れ値を除外したりして集約することによって、データソースが間違っている場合に備えている。（例えば、ノードが市場価格データ取得に際して、Bloomberg・Yahoo・Reutersを用いるなど）

  • Chainlinkのインターフェースは次の３つの要素で構成される。
    - Reputation Contract：オラクルサービス提供ノードのトラッキング
    - Order-Matching Contract：SLA、SLAパラメータログ、オラクルサービス提供者からのビッド
    - Aggregating Contract：オラクルサービス提供ノードの反応を集約した上で、クエリに対する最終的な結論を決定

  • 複数のオラクルサービス提供ノードからのソースを集約することで単一ポイントへの依存度を低減するだけでなく、オラクルの正確性を高めるため、評判システムやペナルティなど各種の仕掛けを講じている。

  • 評判システムとしては、割り当てリクエスト総数や完了リクエスト数・受入リクエスト総数・レスポンス平均時間・ペナルティ総額などの判断基準に基づいてノードをレーティングしている。ノードに正直な振る舞いをしないと悪いレーティングがつくだけでなく、レーティングに基づいてオラクルを選んだり、閾値をこえる中からランダム選抜したりとオラクルの選択でも考慮がかかるようになっている。

  • ペナルティシステムとしては、スマートコントラクト開発者はノードに対して、問題解決権利を得るためにステークとして求める担保額を設定できる。ノードは事前同意したLINKトークンをデポジットすることによって機会が得られ、もし正確な情報提供できなければトークン控除でペナルティを受けるなど、ノードに正直な振る舞いを動機付けている。

  • Chainlinkは今回発表したOracleだけでなく、先般のGoogleクラウドとの提携をはじめ、多様な提携戦略をとっている。遡ると、2017年秋にはSWIFTむけに開発した「スマートボンド」のPoCをSIBOSカンファレンスで発表しているなど、ブロックチェーンスタートアップだけでなく、エンタープライズな組織との連携に早くから着手しているのが特徴的（SWIFTとのPoCは、５つの銀行の利率を取得したのち、集約してSWIFTむけ支払いにつかわれる単一の利率として、SWIFTむけメッセージにまとめるというものだった）。

  • 技術プロダクト分野でも、ThunderCoreやHedera HashgraphやIOSTといったブロックチェーンレイヤー、あるいはStreamrやOcean Proctocolといったブロックチェーン上のデータソースを扱うプレイヤーなどとの提携を進めているなど、エコシステム拡大に積極的な姿勢をとっている（提携マップ）。現時点、ブロックチェーンはオラクルからのデータが正しいものか間違ったものか判断できないなど、オラクルを巡る課題の全てを解決できるものではない。そうした中で、現実世界のデータとブロックチェーン上のデジタルな信用を繋いで「プログラマブル」にしていくことによって、各種取引がなめらか且つ短期・低コストに行えるようなプラットフォームの充実に今後も期待したい。

●契約自動執行にむけたClauseの取組みが具体的に

  • 従来のデジタル化は請求プロセスに手作業が残存している他、支払いなどの契約義務実行と、契約データが統合されていないため、ペナルティや違反通知など、エンドツーエンドなものになっていない。一気通貫でで自動化されていないため、輸送管理システム・契約管理システム・支払システムなど複数システム間で手作業のリコンサイルが発生するなどしているまた、契約管理システムも、承認ルート管理・インボイス生成・締切アラートなど「遂行前局面の自動化」に留まっている。

  • デジタル変革を成功に導くには、法的合意・外部データソース・ビジネスシステムの三者について、デジタル化・統合・自動化が不可欠である。具体的には、契約のデジタル化（契約やインボイスの履行義務・遂行結果をデジタル形式で生成・捕捉・格納）した上で、インテグレーション（含まれるルールや遂行ステータスを契約管理システムに統合。関連システム間のデータ連携）を行い、自動遂行（契約義務の履行・関連オペレーションの自動実行）まで行うことが必要。

  • Clauseは、外部データをトリガーとして契約義務遂行を自動化できる契約テンプレートを生成・カスタマイズ可能なほか、契約の履行状況に関する監査証跡データを参照・抽出可能とするもの。前述の「デジタル化」「インテグレーション」「自動化」の３つに対応するソリューションとなっている。
    - デジタル化：データ中の履行義務を捕捉、パフォーマンスデータの捕捉と格納
    - インテグレーション：法的合意をIoTやERPと接続
    - 自動化：外部データや他システム中のアップデートを受けて、法的拘束力ある義務をトリガーとすることで、契約遵守を自動化

  • 外部データをトリガーとして契約義務自動化を可能な契約テンプレートを作成した上で、このテンプレートをカスタマイズし、新規ソースをトリガーとした契約義務を遂行できる。APIを通じて、契約執行機能を既存システムやワークフローへ追加できるほか、署名後の契約の履行状況に関する監査証跡データを参照・抽出することも可能となっている。

  • このほど、Clauseが取組事例を複数発表している。一つは、Global Insurtech Leaders’ Summit(6/18–6/19 at NYC)で発表された「売掛金保険の自動執行」。これは、会計システムの売掛データを契約条件と接続し自動でデジタル請求フォームを生成し、保険会社の請求プロセスへ自動送信するもの。ここで重要なのは保険者・被保険者双方の会計・請求管理を同期することによって、支払フローや残高について正確でリアルタイムなビューを提供できること。このように、売掛金データ・請求管理プロセス・保険金支払いの三者に不可分なリンクを生み出す点が特徴的。

  • もう一つは、Clauseが法律事務所Clyde&Coと行ったパラメトリック保険。これは太陽パネル供給者が日照不足により期待されるエネルギー生成ができないリスクに備えるもの。太陽パネルのパラメーターをトリガーとして、保険金請求を自動執行している。

  • デジタル化は進んでいるようで、さらなる加速の余地があり、その重要なステップが「契約の自動執行」である。現実世界のデータのデジタル化が進んだほか、APIを通じたつなぎこみなど周辺環境も揃ってきている。そこで重要なのは単一プレイヤーに閉じない複数プレイヤー間でのデータ管理の同期であり、データとプロセスと決済を不可分につないで「プログラマブル」にすること。これによって、プロセスルールや業界慣行・法規制などをビルトインし、短時間・低コストで執行できることから、さらなる周辺環境に整備と実装が進むことを期待したい。

Section2: ListUp

（リンクはこちら）

1. Bitcoin（「DLC上での暗号資産デリバティブセツルメント」など）

2. Ethereum（「Zeth（Clearmatics）とNightfall（EY）のアプローチの違い」など）

3. Bitcoin/Ethereum以外（「Polkadot解説スライド」など）

4. 統計・リスト（「経理業務用にERC20トークンのICOや取引をノード無しでBigQueryで集計する」など）

5. 論考（「Bitcoinの難易度調整アルゴリズムの欠陥とその解決策に関する論文」など）

6. 注目イベント（「BitFuryのBlockchain Summitの模様」など）

バックナンバー

#1 (2019/04/01–04/07)
#2 (2019/04/08–04/14)
#3 (2019/04/15–04/21)
#4 (2019/04/22–04/28)
#5(2019/04/28–05/05)
#6(2019/05/06–05/12)
#7(2019/05/13–05/19)
#8(2019/05/20–05/26)
#9(2019/05/27–06/02)
#10(2019/06/03–06/09)
#11(2019/06/10–06/16)
#12(2019/06/17–06/23)

Disclaimers

This newsletter is not financial advice. So do your own research and due diligence.

CommentShare
← PreviousNext →