Utreexo - kanna

Utreexo

Oleg AndreevさんはTwitterを使っています「@SomsenRuben @adam3us @kcalvinalvinn Even if you use snarks just to go from root to root, you also need most of the data to track updates to your own utxos. If you don’t have any you don’t really need to run a node.」 / Twitter

しくみ

Full node は従来、すべての Block に対する UTXO を保持する

Fullnode validation の目的は、最新の UTXO を知ること = それが Bitcoin の現在の状態だから

そのためには、各 Block における UTXO の状態を Tx で更新していくしかない(同時に Tx が正しいか validate する)

UTXO の変化は Tx によってしか起きない

Utreexo は UTXO の hash tree を生成する

送金者が自分が消費する UTXO が最新の UTXO set に含まれていることを証明する必要がある

自分の UTXO と hash tree の path(markle proof) を示すことで、validator は markle root を生成し検証できる

Utreexo の markle root をもっているだけで、Full node と同じレベレの検証ができる

正しい markle root はどうやって手に入れる？

それに加えて、自分が関心がある=自分のUTXO を保持していれば ok

従来は、validator がすべての UTXO をもっているので、送金側が proove する必要はない

しかし UTXO は数GB のサイズがあるので full node の負担は大きい

このような full node を Compact State Node(CSN) と呼ぶ

誰が？ Tadge Dryja?

leaf の順番大事だよね？

実際の IBD のプロセスがイメージできていない...

Progress Towards Utreexo Goals | BitMEX Blog で説明されている

full node の一種として Compact State Node ができる？

full node はすべての tx を自分のデータだけで検証できる？

(16) MIT Bitcoin Expo 2019 - Utreexo: Reducing Bitcoin Nodes to 1 Kilobyte - YouTube by Tadge Dryja

【動画で学ぶブロックチェーン】ハッシュベースのアキュムレーター Utreexoの仕組み -　安土茂亨氏 - GBEC - Blockchain を推進するエンジニアリングコミュニティ - #GBEC

Tadge Dryja on Scaling Bitcoin With Utreexo — What Bitcoin Did

Grey Mirror #1—Tadge Dryja, Digital Currency Initiative: uTreeXO and Bootstrapping Bitcoin Upgrades | by Rhys Lindmark | MIT Media Lab Digital Currency Initiative | Medium

Video: What Could Utreexo Mean For Bitcoin? – Bitcoin Magazine

IBD が早くなる理由

現在の UTXOs を得るためには、すべてのブロックを検証して、いまの UTXO の状態を得る必要がある

ほかの full node から Tx をダウンロードして、検証して、Block ごとの UTXO set をつくっていく

Block 1 の UTXO set ができた

Block 2 の Tx をもらう

Input が Block 1 の Utxo set に含まれていることを検証する

だから utxo set が必要

コスト

disk I/O

disk size

正しい Utreexo markle root だけをもっていれば、Tx をもらって、tree を構成すれば検証できる

正しい Utreexo root であることは？

ブロックに含めてしまえば取得はできる

最新の root がもっとも hash power がのった chain の root であれば ok ということ？

多分そう

markle root だけ持てばいい utreexo の場合は、UTXO 全体をメモリにおいておけることになるので disk I/O が不要になり高速化できる

ただし、proof の分だけダウロードするデータは増加する

検証を任意の block height から始めることはできない

任意の block の UTXOs がわからないため

Utreexo の markle root は実際の UTXO に比べて小さいため、ブロックごとの UTXO を保持することも可能

ブロックごとの UTXOs がわかれば、任意の block から検証をはじめることができる

つまり並列化できる

markle root はどこから手に入れる？それが正しい保証は？

正しいかどうかはすべての検証を行って辻褄が合うかどうかでわかる

Utreexo archival node から root と proof を受け取るのか？

特定のブロック高ごとに markle root を取っておけば、すなわち snapshot を作成しておけば、並行して IBD を実施できるの高速になる

markle root のデータは小さいので、ブロックのデータに加えて保持しても、保存や送信で困らない

従来はブロック１から順番に検証していくしかなかった

なぜならば、正しい UTXO は前のブロックを検証することでしか知ることができないから

ブロックと UTXO をセットにして snapshot を取っておくことで、任意のブロックとUTXOをダウンロードしてそのブロック単体を検証することができる

Light client のセキュリティが向上する？理由

いままでは、neutrino などで受け取った utxo を信用するしかなかった？

検証できる？

Compact State Node

markle proof を使って tx を検証するノード

従来の full node は少なくともすべての UTXOs を持つ必要があった

UTXOs を持っていないとリレーされてきた tx が正しいか検証できない

しかし、utreexo ではルートをもっていれば、proof と utxo が送られてくれば、自身の root に対して検証ができる

すべての proof をもっているわけではない

bridge node がすべての utxo に対する proof を保持する

Wallet はなにを管理する？

いままで通り自分の utxos

proof

proof はブロックごとに変わる可能性がある？絶対かわる？

proof をもつことで proof がない場合と比べてなにがいいのか?

いまはすべてのフルノードが utxos セット全体を保持

exchange がもつ大量の utxos もコストをかけてマネージしている

自分のだけ管理がいいよね

ZkVM はすでに似た概念を実装している？

ZkVM: a new design for fast, confidential smart contracts | by Oleg Andreev | Stellar Developers | Medium

ZeroSync も関係がある？

UTXO commitment との違いは？