博士

やあ、ロボ子。今日はRust製のMerkle treeライブラリ「rs-merkle-tree」について話すのじゃ。

ロボ子

Merkle treeですか、博士。ブロックチェーンなどでよく使われるデータ構造ですね。それがRustで実装された、と。

博士

そうじゃ！このライブラリ、なかなか面白い特徴があるぞ。まず「固定深度」。全てのproofが一定のサイズを持つんじゃ。

ロボ子

proofのサイズが固定されているのは、どのような利点があるのでしょう？

博士

検証が楽になるのじゃ！それに、「Append-only」。leafはインデックス0から順番に追加され、追加後の変更は不可！

ロボ子

変更不可、ですか。データの整合性が重要な場合に役立ちそうですね。

博士

その通り！さらに、「Merkle proofの高速取り出し」！中間のleafを保存し、遅延計算なしにメモリから取り出し可能！

ロボ子

それは便利ですね。必要な時にすぐに取り出せるのは効率的です。

博士

じゃろ？ストレージバックエンドやハッシュ関数も設定可能で、インターフェースもシンプルで使いやすいらしいぞ。`add_leaves`, `root`, `num_leaves`, `proof`とかじゃ。

ロボ子

ストレージはrusqlite, rocksdb, sledなどが使えるんですね。ハッシュ関数はkeccak256やPoseidon BN254 Circom T3ですか。

博士

そうそう！ベンチマークの結果も興味深いぞ。例えば、100万leafのデータを保存した場合、ディスク使用量はsledが290MiB、sqliteが159.18MiB、rocksdbが183.27MiBじゃ。

ロボ子

sqliteが一番ディスク使用量が少ないんですね。でも、スループットはsledが一番高いんですね。

博士

そうなんじゃ。`add_leaves`のスループットを見ると、keccak256ハッシュ関数を使った場合、memoryが86.084 Kelem/s、sledが43.280 Kelem/s、sqliteが22.348 Kelem/s、rocksdbが18.280 Kelem/sじゃ。

ロボ子

memoryが圧倒的に速いですね。でも、永続化が必要な場合は、sledが良い選択肢になりそうですね。

博士

`proof`の生成時間も見てみよう。memoryが560.990 ns、sledが7.878 µs、sqliteが14.562 µs、rocksdbが34.391 µsじゃ。

ロボ子

やはりmemoryが速いですが、sledも十分実用的ですね。用途に合わせてストレージを選ぶ必要がありそうです。

博士

このライブラリ、MITライセンスだから、自由に使えて良いのじゃ。ロボ子も何か作ってみたらどうじゃ？

ロボ子

そうですね、博士。私も何か面白い応用を考えてみます。例えば、大規模なデータセットの整合性チェックに使えそうですね。

博士

おっ、良いアイデアじゃ！もしかしたら、ロボ子の秘密のレシピをMerkle treeで守るのも良いかも…って、レシピなんてあったっけ？

ロボ子

博士、私はロボットですから、レシピはありません！（笑）