LayerX Newsletter for Tech (2019/09/30–10/06)
Issue #27
今週の注目トピック
Satoshi Miyazakiより
今週は、Lightning Networkの上の3rdレイヤーにてデジタルアセットを発行できるRGBプロトコルに関するニュースの他、デジタルIDプラットフォームであるSovrin NetworkへのR3による参加表明、Zcashの匿名性低下につながるサイドチャネル攻撃について、お届けして参ります。
Section1: PickUp
●Lightning Network上の3rdレイヤープロトコルとしてデジタルアセット発行するRGBプロトコル
Vaultoroが、Lightning NetworkベースのトークンとしてVGoldを発表した。このデジタルアセットは、１単位分のアセットが投資グレード金塊の１グラムで裏付けられ、2019年末にローンチ予定としている。
発行の基盤となっているのが、Bitcoinを第一階層・Lightning Networkを第二階層とし、その上でトークンを発行するRGBプロトコルである。RGBプロジェクトは、Bitcoin上でアセット発行するカラードコインにおける研究をもとに、現在主流となっているEthereumのERC20に代わる頑健なプロトコル提供を目指すもの。Bitcoinの頑健性に依拠するだけでは、ベースレイヤーの制約を考慮する必要があるため、Lightning Networkの上に構築することによって、スケーラビリティやセキュリティを提供できると考え、RGBプロトコルは第三階層（3rdレイヤー）の位置付けでアセット発行機能を提供する。
RGBは、Lightning Networkスタック上にOpenSealsフレームワークを用いてデジタルアセットを発行する。このOpenSealsフレームワークは、アセットの流通・オーナーシップ・未利用残高に関わる情報（ステート）を、分散管理するものであり、Lightning Networkなどセカンドレイヤープロトコル上でも動くもの。
オフチェーンにおけるステートに関するコンセンサスは、Peter Todd氏が提唱した「Client-side validation model」を利用するほか、Lightning Networkトランザクションアウトプット(single-use seals)に埋め込まれたコミットメントの検証を組み合わせて実現する。「Client-side validation model」は、2016年のMilanでのScalingBitcoinで発表されたものであり、マイナーに負担をかけないだけでなく、軽量クライアントにおいても検証の要件を満たすことができる点が特徴。
このRGBプロトコルのように、Lightning Network（2ndレイヤープロトコル）上で稼働する「3rdレイヤープロトコル」が複数登場してきている。その一つが、ScalingBitcoin 2019でPandora Coreが発表したStormであり、LN上で経済インセンティブをつける分散ストレージ・メッセージングのプロトコル。Pandora Coreは、Baltic Honeybadgerでも登壇し、Stormを始めとする、セカンドレイヤー上でデジタルアセット発行・秘匿送金・分散計算を行う技術スタックを発表しており、ペイメントだけでなくプログラマブルアセットや機械学習計算への応用を視野に入れているとされる。今後もLightning Network上のプロトコル・サービス開発の動向に注目したい。
●デジタルアイデンティティプラットフォームSovrin Network、R3などがStewardとして追加参加表明
アイデンティティをサイロ化した集中データベースで管理することに伴うセキュリティ面の懸念・利便性のロスが顕在化する中、個人データ保護や利便性を高める手段として、ユーザー主体の管理をブロックチェーンなど分散型で行う検討・実装が各方面で進んでいる。
Sovrin Networkは、生年月日や医療記録など含めたアイデンティティ情報・資格証明情報をユーザー主体でコントロールすることを目指すもの。運転免許証やパスポートなどのアナログなアイデンティティをインターネット上で個人がコントロールでき、第三者が自動的に暗号学的に検証可能なデジタルアイデンティティ標準を目指している。その特徴は、アイデンティティ技術標準であるDecentralized Identifiers (DIDs）やゼロ知識証明をもちいて、デジタル資格証明をプライベートに発行・コントロール・共有できる自己統治型アイデンティティ（Self-Sovereign Identity (SSI)）であること。
Sovrin Foundationは、Hyperledgerのメンバーであり、Hyperledger Indy をSovrin Networkむけコードベースとしている。他のHyperledgerプロダクト同様、Hyperledger Indy はデジタルアイデンティティ向けのツールやライブラリ・コンポーネントを提供。この他、ウォレットなどを提供するアイデンティティエージェントHyperledger Ariesや、分散鍵管理を提供するHyperledger Ursaとも互換性をもつ。
台帳（Sovrin Ledger）は、トラストされたプレイヤーによって構成されるStewardsにより運営され、それぞれのStewardsは、Sovrin Trust Framework の要件に従うことへ合意し、ノード運用に責任もつ主体であり、現在75の組織が参加している。
このほど、R3社などがStewardsとして追加で参加を表明した。R3社は、すでに昨年、Evernym社を交え、CordaとSovrinの相互運用に関するトライアル検証に取り組んでいるほか、CordaむけアイデンティティサービスCordentityを開発するなどしている。
Sovrin NetworkのStewardsとしては、金融関連だけでなく、サプライチェーンに関わるプレイヤーもふくめた業際的な布陣となっている。今後、個人・法人・プロダクトふくめた様々な分野において、真正性証明の手段として利活用されるユースケースの登場に期待したい。
●Zcashの匿名性低下につながるサイドチャネル攻撃について（現在修正済）
2019年10月2日、スタンフォード大学と、ETH Zurichの研究者らから、Zcashのプライベートトランザクション（Shielded transaction）において、匿名性を下げる攻撃方法に関する共著論文が発表された。
攻撃方法は2種類あり、それぞれPINGとREJECTと名付けられている。特定のShielded Txの受け取り手と、残りのZcash クライアントの挙動の違いを用いたものとなっている。
REJECT攻撃は、通常ノードにはacceptされる一方、受け手のみが”reject”メッセージを発信するような特定形式のトランザクションを攻撃者が送信し、並行でネットワークの状態を監視することで、トランザクションの受け手の匿名性を低下させる仕組みとなっている。
PING攻撃は、はじめに攻撃者がノードにトランザクションを伝播させるタイミングにて、あとを追う形で ”ping” メッセージを送信する。ここで、pingへのレスポンス速度を見計らうことで、当該トランザクションの受け手となるノードのみを見極め、匿名性を低下させる仕組みとなっている。
上記の攻撃により、mempool内にあるShielded Txから、そのトランザクションの受け手が誰であるか を高確率で判別できる他、ZcashクライアントのIPアドレスを特定したり、2つのペイメントトランザクションが同一のクライアントに紐付いているかどうか等が判別できてしまう可能性があった。
本脆弱性は、v2.0.0のSapling Network Updateにて発生したのち、著者らによってZcashの開発チームに伝えられ、v.2.0.7–3のリリースにて、こちらに対する修正が行われた。近頃、Lightning Networkや、MakerDAOなど、脆弱性の発見と修正に関するニュースが続いているが、今後の明るい動向に期待したい。
Section2: ListUp
（リンクはこちら）
1. Bitcoin
（「Zap、法定通貨からLightningペイメントできるOlympusを発表」など）
2. Ethereum
（「Istanbulハードフォークの実施が2日早まる」など）
3. Bitcoin/Ethereum以外
（「Hyperledger Avalon、プライバシー保護しつつスケーリングを目指すオフチェーンプロトコル」など）
4. 統計・リスト
（「分散エスクローサービスのリスト」など）
5. 論考
（「ブロックチェーンの後継といわれる「DAG」って本当に完璧なの？」など）
6. 注目イベント
（「b.tokyo2019」「Cryptoeconomic Systems 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)
#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)
Disclaimers
This newsletter is not financial advice. So do your own research and due diligence.
