【完全保存版】ZK CompressionのState Treeとは

こちらの記事は、こちらの公式の記事を翻訳・編集したものです。

State Trees | ZK Compression

１　State Treeとは

プロトコルは、複数の状態ツリー（State Tree）に圧縮された状態を保存します。

状態ツリーは、データをツリー構造に整理するバイナリのマークリツリーであり、各親ノードはその二つの子ノードのハッシュ値になります。

翻訳者注
「バイナリの」というと難しそうですが、「二つに枝分かれしている」くらいの意味です。
そして、その二つをハッシュ化して上のノードになります。

これにより、ツリー内のすべてのノード（リーフとも呼ばれる）の整合性を効率的に暗号的に検証できる、唯一のルートハッシュが生成されます。

翻訳者注
検証方法などについて詳しく知りたい場合は、こちらをどうぞ

２　圧縮アカウントのハッシュについて

各圧縮アカウントのハッシュは、そのような状態ツリーのリーフとして保存されます。

各圧縮アカウントハッシュには、状態ツリーの対応するオンチェーンアカウント（すなわち、状態ツリーハッシュ）の公開鍵と、そのツリー内での圧縮アカウントの位置（すなわち、leafIndex）が含まれていることに注意してください。

これにより、各アカウントハッシュがグローバルに一意であることが保証されます。

各状態ツリーには、ツリーの最終ルートハッシュとその他のメタデータのみを保存する対応するオンチェーンの状態ツリーアカウントがあります。

ツリーの最終ルートハッシュをオンチェーンに保存することで、プロトコルはツリー内の任意のリーフ（圧縮アカウント）の有効性を効率的に検証することができます。

このようにして、元の状態はSolanaの台帳スペースにおいて、より安価なcalldataとして保存される一方で、Solanaのセキュリティ保証を維持することができます。

翻訳者注
ここはちょっとよくわかっていませんので、現時点での自分なりの見解です。
solidityなどではコントラクトの一時的な保存領域として、calldataがよく出てきます。
どちらにしろ、一時的なデータの保存のことだと思っています。
ということは、元の状態は、トランザクション実行時などに一時的に保存される？というように解釈しました。
これは、ZKであり、一度検証できれば良いからなのかなと思いました。
ただ、それだけでは、圧縮アカウントハッシュが失われてしまうので、①L2に残っている②トランザクションには残っている
のどちらかのことなのかなと推測しました。