今週の注目トピック
Satoshi Miyazakiより
今週のTech編では、Microsoft Azureのトークンプラットフォーム「Azure Blockchain Tokens」と、Oasis Labsによる医療データの共有プロジェクト「Kara」について、またRecruitが出資していることでも注目を集めている、Lightning Networkの専門企業であるBreezから発表されたLightning Rodについて、ご紹介しています。リストアップ編と合わせてご覧ください。
Section1: PickUp
●Microsoft、標準仕様「Token Taxonomy Framework(TTF)」準拠のトークンプラットフォーム「Azure Blockchain Tokens(ABT)」を発表
米Microsoftが、Azureクラウド上でトークンを企業が容易に発行できるプラットフォーム「Azure Blockchain Tokens(ABT)」を発表した。背景として、ブロックチェーンを活用したトークンの種類が多様になっており、様々な実装が存在する一方で相互運用や規制対処へむけた共通基盤が不足していることが課題にある。そうした問題意識のもと、プリンタ接続同様に容易にブロックチェーン上でトークン発行できることを目指したものだ。ABT上では、目的に応じて既存テンプレートから選択してトークン設計・発行むけに利用できる。
トークンの標準化にむけては、既にコンソーシアム「Token Taxonomy Initiative(TTI)」が設立されている。TTIのメンバーには、ITベンダー・コンサル(Accenture、IBM、EY、Intel、Microsoft)、金融機関(Banco Santander、J.P. Morgan)、ブロックチェーンスタートアップ(Clearmatics、ConsenSys、Digital Asset、Hedera Hashgraph、Komgo、R3)など、主要プレイヤーが参画している。TTIはこのほど11/4付で、プラットフォームに依存することなく、トークンの定義・用語を定める標準仕様「Token Taxonomy Framework(TTF)v1.0」を発表。こうした標準を利用することを通じて、業界用語や実装方法を理解することなく、サービス・プロダクトを設計することを可能となる。
ABTを用いて、Azureのブロックチェーン上で共通規格に準拠したアセットの設計・発行・管理が可能。TTFに準拠しているため、将来の拡張性を見据えたトークンの発行・運用が可能。TTIが策定したトークン仕様としては、「Asset:ユニークなアート作品などが持つ固有の価値」「Ticket:航空機のチケットなど有期限で一定価値」「Commodity:石油やエネルギー資源」「Qualified:国家資格の保有や駐車違反などの記録を証明」という4タイプが定義されている。既に、ゲームやVRなど、アセット生成に興味のあるプロジェクトが、実験的アセット生成に利用している。チケットやロイヤリティポイントの他、サプライチェーン書類・株式など、ブロックチェーンベースのプロダクト・サービスを、プラットフォーム横断で流通することが可能。今後、General Electricが実験的なアセットの生成で後に続くことが見込まれている。
ABTは、Azureベースのみならず、IBM(Hyperlegedger)・R3(Corda)など広範なブロックチェーンプラットフォーム間で相互運用性をもたせることが可能。TTF準拠でトークンの規約・仕様を共通用語を用いることによって、共通の規約・仕様に沿って相互に通信できる。中期的なコンソーシアムの拡大・相互接続などを見据える上で、今後の展開に注目したい。
●Oasis Labs、Stanford Hospitalの医師や研究者を交えた医療データ共有プロジェクト「Kara」を推進
Oasis Labsは、ブロックチェーン上でプライバシーコンピューティング手がけるプレイヤーであり、2018年4月には機密保護型のスマートコントラクト「Ekiden」を発表している。Ekidenは、ブロックチェーンにTEE(Trusted Execution Environment)を組み合わせることによって、機密保護とパフォーマンス両立をはかるものである。
このように、Oasisネットワークの重要な特徴の一つが、データおよびトランザクションの機密保護となっており、TEE(例:Intel SGX)のような暗号化とEnclaveを用いることによって、可用性と機密性を両立している。
ブロックチェーンの課題の一つがパフォーマンス(スケーラビリティ)だが、Oasis Labsのアプローチ(Nimble)の重要なソリューションが、「コンセンサスと計算とストレージの分離」である。この分離を通じて、ネットワークに参加するハードウェアセットの多様化を可能にするだけでなく、コントラクトの並列実行を可能とすることによって、ネットワークスピードを改善を可能としている。具体的には、相互にトランザクションのコンフリクトをチェックすることによって、トランザクションをバッチにグループ化する。こうしたプロセスを通じて、各バッチがトランザクションを並列処理することが可能となる。
今回Stanfordと行うKaraプロジェクトは、サイロ化された医療データの問題解決を図るものだ。医者や患者にインセンティブを与えて、自身のヘルスケアデータを保持しながら、データを共有し、医療研究を改善する「プライバシー保護型の分散ヘルスケアデータ市場」を標榜している。
まず、医師や患者は、Karaのアプリからデータをインプット。次に、Karaのアプリが自動的にデータを処理し、Oasisのブロックチェーン(プライバシー保護スマートコントラクト)上に格納。これを受け、研究者はWeb画面から、プライバシー保護スマートコントラクトを介して、データにアクセスし、クエリ結果を得ることができる。このとき、データは暗号学的に選択的共有され、個々のデータ値が明かされることは無く、データの匿名性を保ったまま、研究者達が機械学習に活用可能となる。
先般、こうした「機密コンピューティング」の普及・加速へ向けて、Linux Foundationが、Confidential Computing Consortiumを組成した。
Oasis Labsも、このコンソーシアムメンバーとして名を連ねている。ChainlinkとIntelによって発表されたTrusted Computation Frameworkも含め、こうした機密コンピューティングの動向に注目したい。
●Lightning Rodについて:非同期のLightning決済が可能に
イスラエルでLightning Network(LN)関連のサービス開発をするBreezが、この度「Lightning Rod」のコンセプトについて、公式のMediumで発表を行なった。既存のノンカストディアルウォレットにおけるLN決済では、クライアントを常時オンライン状態に保って同期的に通信を行う必要があったため、ユーザビリティの面で課題を抱えていた。これに対し、仲介地点にLightning Rodノードを立てることで、解決を図っている。
AliceとCarolの間にLightning Rodノードがある場合の取引について考える。はじめに、AliceはCarolに対し、Secretを送信する。こちらが完了した段階で、Aliceはオフラインになってしまっても問題ない。次に、Carolはpreimageを作成し、AliceのSecretをハッシュ化としたものと、preimageをハッシュ化したものを、Lightning Rodに送る。この時点で、決済チャネルは、AliceとLightning Rod、Lightning RodとCarol間に分かれる。
次に、Lightning Rodは、SecretをHash化したものと、 Hash化されたpreimageをHODL invoice内に含んだものを、Aliceに送る。ここで、SecretのHashを使うことで、AliceはCarolのPayment Requestをvalidateすることができる。ここでAliceがvalidationが完了したタイミングで、AliceはLightning RodにHTLCを送り、Lightning RodはCarolにHTLCを送り、以降は通常通りに決済される。
Lightning Rodを複数間に挟むことで、決済当事者間のプライバシーを確保することが可能になっている点も特徴的である。Breezには、Recruitが出資を行なっており、今後もプロダクトのアップデートから目を離せない。
Section2: ListUp
(リンクはこちら)
1. Bitcoin(「bitcoinoptech Newsletterの和訳を開始」など)
2. Ethereum(「Isutanbulのメインネット実装日、12月4日に決定」など)
3. Bitcoin/Ethereum以外(「Crypto Zombies、新たに「Libra Basics」コースが開始」など)
4. 統計・リスト(「Statistics Around DAI Stablecoin」など)
5. 論考(「kaleidoによる比較記事。/Enterprise Blockchain Protocols: A Technical Analysis of Ethereum vs Fabric vs Corda」など)
6. 注目イベント
バックナンバー
#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)
#13(2019/06/24–06/30)
#14(2019/07/01–07/07)
#15(2019/07/08–07/14)
#16(2019/07/15–07/21)
#17(2019/07/22–07/28)
#18(2019/07/29–08/04)
#19(2019/08/05–08/11)
#20(2019/08/12–08/18)
#21(2019/08/19–08/25)
#22(2019/08/26–09/01)
#23(2019/09/02–09/08)
#24(2019/09/09–09/15)
#25(2019/09/16–09/22)
#26(2019/09/23–09/29)
#27(2019/09/30–10/06)
#28(2019/10/07–10/13)
#29(2019/10/14–10/20)
#30(2019/10/21–10/27)
#31(2019/10/28–11/03)
Disclaimers
This newsletter is not financial advice. So do your own research and due diligence.