2018年度で起こったブロックチェーンの変化について
はじめに
今日から年度が切り替わり、2019年度が始まりました。今回は、節目として2018年度に自分が調査したブロックチェーン基盤の変化について、私が面白いなと感じたトピックを紹介したいと思います。
ブロックチェーン基盤の変化
アカウント管理
基本的に、ブロックチェーンのアカウントは、トランザクションを作成するために楕円曲線暗号を利用した秘密鍵となっています。これは、「誰が」「何を」行ったのかをトランザクションに電子署名の仕組みを使って履歴として残すためです。BitcoinやEthereumは、この秘密鍵自体をアカウントとして利用しますが、他にも下記のようなアカウント管理の手法も出てきました。アカウントについては、Sybil Attackに関する問題を防ぐ等の仕組みが必要になってきているため、以下の仕組みもUXに問題があったりしますが、面白い解決策だと思いました。
- EOSIO
EOSIOのアカウントは、12文字の英数字からなるユニークなアカウント名で管理されています。また、このアカウントは、EOSIO内でコントラクトを実行するためにリソースと、権限管理用のPermissionシステムが紐づけられています。このうち、Permissionシステムは、アカウントの全権限をもつOwnerと、コントラクトの実行権限をもつActive、そしてActiveから一部の権限を移譲されたもの(ロール)の3つの権限管理が存在し、それぞれに対して秘密鍵が紐づけられています。これにより、秘密鍵ごとに実行できるコントラクトを制限することができる等、ユーザの鍵漏洩による影響を小さくできるような仕組みができるようになっています。 - Hyperledgr Fabric
Hyperledger Fabricは、コンソーシアム型のブロックチェーンのため認証機能としてPKI(Public Key Infrastructure)による鍵生成を行なっています。具体的には、ブロックチェーンノードを保持する組織ごとにCA(Certification Authority)と呼ばれる電子証明書や秘密鍵の発行、電子署名の失効等を行うことができるノードを作成します。このノードは、ID/Password認証を行うことで、ユーザの秘密鍵や証明書を作成、更新することができるようになっています。
トランザクションの秘匿化
この技術は、BitcoinやEthereumのような、現状と過去の情報をすべて公開することで現状の正当性を保証していたものを、暗号技術を利用して送金情報といった個人の情報を暗号化した文字列であってもゼロ知識証明を用いて正当性を保証できるようにするものです。現状は、トークンの秘匿化に関する応用が目立ちますが、今後は別の情報に関しても秘匿化できるような研究を行っているらしいです。この場合、クライアント側での実装になるか、もしくはブロックチェーン側でトランザクションのどの値を何の暗号アルゴリズムを用いて秘匿化するのか選択できるようにするのかといった実装方式や、秘匿化した情報が正しいのかを証明する部分をどう実現するのかといった観点が重要になりそうです。
例)
ブロックチェーン間の連携(Cross Chain)
この技術については、個人的に最も注目しています。理由としては、将来ブロックチェーンを利用したサービスは、すでに実装されたコントラクトを組み合わせたプロトコルとフロントエンドで成り立つようになると考えているためです(参考：ファットプロトコル)。現状では送金関連のプロトコルしか実用的ではありませんが、今後、ブロックチェーンによって実装された共有データベースと、それを利用するトークンプロトコルが別の基盤上で実装でき、それぞれが通信できるような応用が効くようになって、初めて本格的なサービスが構築されるようになると個人的には思ってます(もしくは1つの基盤の上で全部実装できるようになれば話は別ですが、コンセンサスアルゴリズムをコントラクト側に切り離す等の技術が必要になってくると考えられるため、難しいと思っています)。
- Interledger Protocol
このプロトコルは、Escrowと呼ばれる考え方を使ったプロトコルになっています。具体的には、BTCとETHを交換する際に、それぞれの資産を持っている2者と、その2者から信頼されている仲介者(Interledger Protocol)が存在し、一度仲介者のアカウントに資産を預け、交換して貰うような仕組みになっています。 - Cosmos Network
このプロトコルは、連携する複数のブロックチェーン基盤のチェーンと、交換用のスマートコントラクト用のチェーンを保持した中央仲介者を作成し、交換時にスマートコントラクトを用いてそれぞれの台帳に交換用のトランザクションを書き込む方式となっています。
チェーンの分離
分離する観点が異なりますが、基盤内のチェーンを役割ごとに分けて複数保持するブロックチェーンの基盤が現れ始めました。現在、Ethereumではシャーディングによるブロック管理の容量削減等の提案が行われていますが、それとは別に、チェーンを分離してノードごとにどのチェーンを管理するのか選択させる方法も容量削減のアプローチの１つになってくるかもしていないと感じています。
- LINK
LINKでは、全体を管理するチェーン(Root Chain)とdAppsごとのチェーン(Leaf Chain)が存在しています。ちなみに、全体を管理するチェーンは、ユーザの管理やLeaf Chain全体の管理を行なっており、Leaf ChainはdAppsごとに処理するトランザクションやブロックの管理をしています。また、Leaf Chain間の連携については、現状はRoot Chainを介して行うことができます。(参考資料) - Hyperledgr Fabric
Hyperledger Fabricでは、ネットワークを構築している組織のうち、いくつかをピックアップしてコンソーシアムを組めるチャンネルという機能が存在し、このチャンネルごとにチェーンを分割して保持しています。なお、異なったチャンネル間でのチェーンの参照はできないので、コンソーシアム間でコントラクト同士の連携を行うことはできません。 - BEXAM
BEXAMが採用しているコンセンサスアルゴリズムのPoR(Proof of Rounds)は、ネットワークを構成するノードに役割が存在しており、この役割ごとにチェーンを管理する必要があります。具体的には、データベースのデータ変化を管理するデータベースサービス用のチェーンと、データベースにおける時間やトランザクションをブロック化するノードの移り変わり等の管理用チェーンがあります。
メタデータの保存
Ethereumのようなブロックチェーンに情報を保持する場合、ERC721のNFT(Non-Fungible Token)としてメターデータを書き込み、それを状態(State)として保持させる形式が一般的でした。しかし、最近になって以下のようにデータベースをサポートしているブロックチェーンも出てきました。
- EOSIO
Multi-index DBが用意されており、コントラクトにテーブルとしての構造体を定義することでデータベースを利用できるようになっています。 - Hyperledgr Fabric
KVSによるドキュメントデータベースが利用できるようになっています。これは、Ordererと呼ばれるトランザクションをブロック化するノードを用意し、トランザクションをブロック化する際にコンフリクトが発生しないか確認することができる機構を組み込んでいるため実現することができています。
おわりに
今回は、ブロックチェーン基盤の変化について、個人的に気になったトピックを簡単に紹介してみました。それぞれについて、今回は詳細な技術説明まではしませんでしたが、今後、個別に紹介していければと思います。
Author
