LayerX Newsletter for Tech (2019/09/09–09/15)

Issue #24

CommentShare

今週の注目トピック

Satoshi Miyazakiより

今週は、イスラエルのTel Avivにて開催された「BitcoinEdge Dev++」と「Scaling Bitcoin」の現地イベントレポートをお届けする。Bitcoinのスケーリングや、プライバシー領域における課題に対する、最先端の取り組みを総覧できる内容となっている。加えて今回は、ステーブルコインの発行（EIP-2269）と秘密鍵の紛失防止（EIP-2270）に向けた新しい提案について、取り上げた。

Section1: PickUp

●TelAviv現地レポート：「BitcoinEdge Dev++」に見るBitcoin技術の主要トピック概観

  • 「BitcoinEdge Dev++」は、イスラエルTelAvivで開催される「ScalingBitcoin」に先立ち、より基本的な技術トピックについて参加者の理解を高めるもの。今回の参加者は200人ほどで、半分程度が地元イスラエルからの参加であった。全体構成としては「暗号の基本」に始まり、「Bitcoinのツール・フレームワーク」「Bitcoinのデータ構造」「プライバシー」「ブロックチェーン」および「Lightning Network」といったものとなっており、以下に主要トピックを概観する（英語書き起こしリンクはこちら）。

  • 冒頭、「暗号の基本」としては、公開鍵暗号からトランザクションやSegwitまでを密度高く圧縮した形で紹介された。「Bitcoinのツール・フレームワーク」については、ChaincodeLabsからBitcoin Coreのデバッグツールの紹介があり関心を集めた模様。

  • 「Bitcoinのデータ構造」セクションでは、まずウォレットが行う鍵の生成・管理、トランザクション生成の概観として、鍵管理（トランザクション特定、新規アドレス生成、署名方法決定）、トランザクション生成（手数料見積とコイン選択、インプットへ署名）および鍵・UTXO・トランザクション履歴・メタデータの格納という整理が示された。

  • 次にAccumulatorとUtreexoについて紹介された。Accumulatorは多くの要素を複数回追加しその包含関係を（同じサイズで）証明できるものであり、Utreexoは253GBある現状のチェーンをコンパクト（1KB）に収めtrackできるようにするもの。ブリッジノードと、ブロックの証明を送るアーカイブノードがあればフォークを必要とすることなく実装可能とのこと。

  • また、Taprootについても紹介された。Taprootは、Schnorr署名を用いて、コントラクトロジックをひとつの公開鍵へ圧縮するものであり、
    マルチシグなど複雑なトランザクションを通常のトランザクションのように見せることが可能。ここではTaproot Toolkitが触れられ、前述のBitcoin Coreのデバッグツールとあわせ、こうしたツールが諸々出てきていることは参加者の興味をそそった様子。

  • 「プライバシーセクション」では、トランザクションをプライベートにブロードキャストする方法としてDandelionが紹介された。Dandelion（タンポポ）は、茎フェーズ・綿毛のフェーズの二段階構成とすることによって、ブロードキャストの出元を検知困難にするもの。
    1ノードにトランザクション送付した後、次も1ノードに送るか全ノードに送るかを決める。こうすることで、茎フェーズでは送信元が最初のユーザーか特定出来ず、綿毛フェーズでは送信元が茎のラストユーザーか特定できない点が特徴。

  • 「ブロックチェーンのデザインパターン」セクションでは、各種技術（DAG・Confidential Transaction・STARKs・Sharding・PoS等）の特徴・トレードオフについて紹介された。
    (1) DAGは、ブロック履歴を線形で持たずに、有効非循環グラフを用いて相互をConfirmするもの。ブロックタイムを20秒へ短縮でき、ブロック伝播の課題に対応するのが特徴だが、初回のダウンロード改善には有効でない他、セルフィッシュマイニングへの対応力が課題とのこと。
    (2) Confidential Transaction は、値についてプライバシーを確保するスキームだが、Range Proofのサイズ問題が残る他、量子耐性が弱いのが課題。
    (3) STARKsは、Scriptをリプレイスし、プライバシーと効率性の双方に寄与するものだが、証明サイズが大きいのが課題。
    (4) Shardingは、ブロックチェーンのステートを複数のサブステートに分割し相互にコミュニケートするものだが、Federatedサイドチェーン以上にセキュアなソリューションが知られてないのが課題。
    (5) PoSは、アルトコイン分野でポピュラーであり、BFTセキュリティモデルを用いるが、一般にBitcoinにとっては不十分との見方が示された。

  • 「Lightning Networkセクション」では、まず「トランポリンルーティング」が紹介された。軽量ノードにとって、特にネットワークが大きくなると、トランザクショングラフの経路計算は負担となる。これに対して、トランポリンルーティングでは、途中のトランポリンノードが全体のグラフ構造を知っておき、ここを介することで、軽量ノードはサブセットさえ格納しておけば済むようにするもの。軽量ノードにとって、経路計算の負担を軽く済ますことができる点が特徴だ。

  • 次に、Lightningの流動性管理について、Dual-Funded Channel, AMP, Splicingそれぞれのトレードオフが紹介された。
    (1) Dual-Funded Channelは、ファンディングトランザクションに対して複数参加者がインプットするもの。「即時に双方向で流動性を持たせることができる」一方、「参加者のUTXOセット漏洩リスク」が課題。
    (2) AMPは、複数チャネルをまとめて1つのチャネルとして大きな支払いを可能とするもの。「ペイメントサイズを増加できる」一方、「部分的なパケットの失敗」など喪失リスクが課題。
    (3) Splicingは、動的なキャパシティ増減を可能とするもの。「キャパシティ調整」が可能な一方、「複数参加者による協調」「正確な残高会計」が課題。

  • 最後に、全体を通じた所感をまとめると、「これまでのBitcoinEdge Dev++との変化」としては、前回まで概要のみの紹介に留まっていたLightning Networkについて多くの時間が割かれるようになり、メインネットローンチを経て、経路検索や流動性管理など課題も含め、具体的な開発・実装が進んでいると感じた。一方で、前回まで扱われていた「クロスチェーン」に関するトピックも触れられると良かったように思える。トピックの傾向として見ても、「チェーンをコンパクトに収めるUtreexo」「トランザクションをプライベートにブロードキャストするDandelion」や「Schnorr署名を用いてコントラクトロジックをひとつの公開鍵へ圧縮するTaproot」など、データの格納・伝播の方式が着実に進化しつつあり、今後の動向に注目したい。

●TelAviv現地レポート：Scaling Bitcoinから見えるBitcoin技術の先端動向

  • Scaling Bitcoinは、2015年から開催されている、Bitcoin技術の先端トピックに関する提案・紹介の場であり、これまでカナダ・香港・ミラノ・スタンフォードを経て、昨年は東京で開催された。今回の全体の参加者は250–300人ほどであり、日本からは20名ほどが参加したがEthereumのVitalik Buterin氏も会場へ姿を現すなど、エンジニアにとって関心の高いイベントであることが実感できた。

  • 全体構成としては「Scripts」に始まり、「Network」「Transaction Throughput」「Alternative Blockchain Protocols」「Lightning Network」といったものとなっており、以下に主要トピックを概観する。

  • まず冒頭は「A Survey of Progress in Succinct Zero Knowledge Proofs: Towards Trustless SNARKs」から始まった。これは、TrustedSetupの必要ないトラストレスなSNARKSの話で、未知の位数の群から新しいトラストレスなPolynomial Commitment Schemeを構築するという提案であった。

  • 「Scriptsセクション」では３つのトピックについて触れる。「ZkVM」は、コントラクトと機密性を備えるマルチアセットブロックチェーンアーキテクチャを提案するもの。プライバシはアセットタイプ、アセットの数量、データパラメータが対象。プログラムやトランザクショングラフは対象外。ZkVMはRustで記述され、33の命令から構成される。任意の計算むけではなくトークン発行やデリバティブなど金融ユースに最適化しているためチューリング完全ではないのが特徴。

  • ZkVMについて具体的にみていくと、トランザクションはプログラムと証明から成る。 VMはトランザクション毎に起動され、Bulletproof制約システムはNetworkルールやコントラクト毎のルールを規定し、単一の証明で全制約を検証する。一方、コントラクトはアセットやデータを保持し、predicateにより保護され、predicateが署名を検証できるとそれらアイテムがロック解除されるようになっている。

  • 「BitML」は、「プログラムとしてのコントラクト（BTC)」と「プロトコルとしてのコントラクト（ETH）」を比較し、新規コイン作ることなしに両立をはかる、Bitcoinモデリング言語の提案。

  • 「Threshold Scriptless Scripts」は、マルチシグ、Threshold Wallet、CoinJoinミキサー、アトミックスワップ、ZK条件付ペイメントなどに応用が可能な提案。

  • 「Networkセクション」では、ブロックリレープロトコルCompact Blocks、Graphene、bloxrouteに対して、新たなトランザクションリレープロトコル「Erlay」が提案された。これは、トランザクションのアナウンスに使われている帯域幅の多くが冗長であることを問題視し、トランザクションリレーの冗長性を軽減するもの。

  • 「Transaction Throughputセクション」では、小切手のようにアウトプット使用に制約をつけることができる「OP_SECURETHEBAG」が提案された。これは、バッチペイメントやマルチフェーズペイメントなどの構成に利用可能で、コベナンツのような取引を作るのにも有用。

  • 「Alternative Blockchain Protocolsセクション」では、新規PoWブロックチェーン「Prism」が提案された。これは、TPS向上をはかるべく、ブロックチェーンをtransaction blocks、proposal blocks、voter blocksに分解する点が特徴。

  • Lightning Networkセクションでは、４つのトピックについて触れる。
    まず「Açaiプロトコルは」、WatchtowerをチャネルモニタリングだけでなくLightningウォレットむけデータバックアップサービスとして利用しようとする提案。一般にLightning NetworkにはBIP39/BIP32が無いため「トラストレスに未使用TXを復旧できない」「異なるデバイスやウォレットへのポータビリティが無い」「デバイス紛失時にLN内の資産を復旧できない」という点がユーザビリティにおいて課題となる。これに対して、Açaiプロトコルは、Watchtowerのもつ「常にオンラインのフルノード」「オフライン・チャネルステータスを監視」という特徴を活用し、バックアップのメカニズムとして使うもの。

  • 次に「トランポリンルーティング」は、Lightningのペイメントトリレンマとして提示される、プライバシー・ルートコスト最適化・パフォーマンスのうち、プライバシーとルートコスト最適化にアプローチするもの。ペイメントルーティングは「経路選択が高速」「HTLCによるトラストレス」「オニオン暗号化によるプライバシー」が長所だが、帯域・メモリ・CPUなどコストがモバイルデバイス利用における課題が残る。この場合、モバイル軽量デバイスによるチャネルネットワークを考えたとき、「つねにオンラインと限らない」「コネクションが信頼できない」「パフォーマンスが限定的」などが制約になる。そこで「トランポリンルーティング」は、部分的なソースルーティングを提供。トランポリンノードを選んで最初のノードへルートするもの。

  • このほか、合成アセットをLN上で流通させる「Rainbow Network」や、
    Layer2/3のハイブリッドアーキテクチャを提案する「Storm」といった新機軸の提案もあった。

  • 最後に、全体を通じた所感をまとめると、「これまでのScaling Bitcoinとの変化」としては、初めてアジェンダからScaling/Scalabilityの文字が消えており、Scaling単体が課題ではなく、プライバシー・セキュリティなどと組み合わせて解決に向かう方向性が窺える。また、従来と比べて、Layer2技術（Lightning, Payment Channel）に割く比重が増えており、Lightningのメインネット実装が進む中で、現実の課題が見えてきたことを踏まえて各種提言がなされている。

  • トピックの傾向として見ても、Scriptless ScriptやZkVM など、Bitcoinとしてスマートコントラクトを秘匿性を加味しながら実装しようとする方向性がある他、単にスループットや秘匿性を追求するのでなく、LNウォレットのポータビリティ・復旧容易性をはかるAcaiプロトコルのように、ユーザビリティにも目が向けられつつあると感じた。また、アウトプット使用に制約をつけるOP_SECURETHEBAGや、LN上で合成アセットを扱うRainbow Networkのように、金融アセットのコントロールへの適用を目指す動きもあり注目される。加えて、L2/L3のハイブリッドによるStormのような新機軸のプロトコル提案も出ており、今後に期待したい。

●EIP 2269、EIP 2270の概要について

  •  2019年9月9日、EthereumのEIP-2269と、EIP-2270が、Jom Ramvi氏によって公開された。

  • EIP-2269は、「The Fiat Representation Contract (FRC): Standard for fiat representation」と題されている。

  • MakerDAOのアプローチのように、不安定な暗号資産をベースにステーブルコインを生み出すことは難しい一方で、ステーブルな資産からステーブルコインを生み出すことは比較的容易であることから、ステーブル資産に対応するトークンをオンチェーンで安全かつ簡単に発行する手法を示すことで、米ドル以外のステーブルコインも表現できるようにすることが、本EIPの要旨となっている。

  • ただし、株などの長期的成長が見込まれる資産については、ペグを破壊してしまう懸念から、本EIPでは対応しない想定であることが強調されている。

  • rDAIの設計が参考にされており、rDAI同様、コントラクト（FRC:Fiat Representation Contract）にERC20トークン（例：DAI）を預け、新しいステーブルコインを発行する。こちらでリザーブされているDAIは、CompoundなどのDeFiプロトコルで自動的に運用され、新ステーブルコインを償還してDAIを受け取る際に、こちらの利子が、発生した価格差の解消に用いられる仕組みとなっている。

  • EIP-2270は、「Generate Ethereum account from Digital ID」と題されている。

  • ユーザーに秘密鍵を管理させることは困難であり、常に紛失の恐れがある。こちらの紛失リスクを低減させるため、既存のID情報を用いて、安全性を保つための十分なエントロピーを持ちつつも、容易に復元可能なEthereumアカウントの生成方法を提示することが、本EIPの趣旨となっている。

  • 現在、スウェーデンやノルウェーのBankID、デンマークのNEM ID、フィンランドのTUPAS、オランダのDigiDや、エストニアのDigital IDなど、市民がデジタルIDを保有している国家があり、いずれもOpenID Connectを通して、本人認証を行う仕組みとなっている。

  • ここで、これらの銀行のデジタルID番号と、社会保障番号、ユーザーパスワードの3つを組み合わせ、SHA256にかけて、秘密鍵を生成するアイデアについて記されている。（社会保証番号そのものは、機密性の高い情報ではないが、ここでは、エントロピーと高めるために用いられている）

  • どちらも既存のDeFiプロトコルや、公共の社会インフラを組み合わせて、利便性高くEthereumを利用できるようにする試みとなっている。今後も最新の動向に注目していきたい。

Section2: ListUp

（リンクはこちら）

1. Bitcoin（「Lightning Networkで脆弱性が確認される」など）

2. Ethereum（「Ethereum 2.0、7つのマルチクライアントで同期成功」など）

3. Bitcoin/Ethereum以外（「DAML、Amazon QLDBをサポート」など）

4. 統計・リスト（「Blockstreamへの投資家マップ」など）

5. 論考（「Blockchain-Based Token Standard Framework」など）

6. 注目イベント（「Cryptoeconomic Systems Summitby MIT Media Lab（10/5–10/6 at Cambridge, MA）」など）

バックナンバー

#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)

Disclaimers

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

CommentShare
← PreviousNext →