以前、Babylon の TBV ページにある「trustless verification」を読んだとき、それが“チェーン全体の信頼”が取り除かれたことを意味するのだと思っていました。チェーンの中のただ一つのリンクが外される、という意味ではなく。
それで実際に、証明が何をカバーしているのか掘り下げてみました。
これが機能するのは3つの要素があるからです。オンチェーンのコントラクト、ZK-SNARK 上で動くライトクライアントの証明、そして独立したインデクサです。これらがすべて、ビットコインのコンセンサスと UTXO 状態を、まったく別の場所から検証できるように織り合わされています。誰か一人のカストディアンに「それを保証して」と信頼する必要がありません。
ふむ。
SNARK が証明しているのは、売り文句が示唆するよりももっと狭い範囲です。主張されたビットコインの状態遷移が、回路に組み込まれたルールに一致していることを確認します。つまり同じ回路が、ビットコイン自身のコンセンサス論理、数学的な“数学のチェック”をエンコードしているわけです。回路は2つのことを前提にしていますが、どちらも証明してはいません。回路に投入されるヘッダーとトランザクションデータが最初から正確だったこと、そしてそもそも回路自体が最初に正しく構築されていることです。
ページを閉じて、両方の前提が実際にはどこにあるのか追跡しました。
1つ目はインデクサの仕事で、証明システムの隣にある別の“付け替え可能な”部品です。2つ目は、その回路を作って監査した人に帰属するもので、継続的な信頼の問題というより一度きりの信頼の問いです。
これで設計が弱くなると言っているわけではありません。外部チェーンデータに基づく外部ライトクライアントの ZK スキームは、こうした継ぎ目をどこかに必ず持っています。Babylon は、それらを売り文句の中に折り込んでしまうのではなく、名前をつけて明示しているだけです。
SNARK が状態遷移を完璧に検証しても、もしどちらかの前提が間違っていたら、「trustless（信頼不要）」の部分は実際に成立しているのでしょうか。それとも、最初から信頼不要ではなかった部分だけが、そう見せていただけだったのでしょうか？
#baby
$BABY
@BabylonLabs_io
$BABY
#baby
それで実際に、証明が何をカバーしているのか掘り下げてみました。
これが機能するのは3つの要素があるからです。オンチェーンのコントラクト、ZK-SNARK 上で動くライトクライアントの証明、そして独立したインデクサです。これらがすべて、ビットコインのコンセンサスと UTXO 状態を、まったく別の場所から検証できるように織り合わされています。誰か一人のカストディアンに「それを保証して」と信頼する必要がありません。
ふむ。
SNARK が証明しているのは、売り文句が示唆するよりももっと狭い範囲です。主張されたビットコインの状態遷移が、回路に組み込まれたルールに一致していることを確認します。つまり同じ回路が、ビットコイン自身のコンセンサス論理、数学的な“数学のチェック”をエンコードしているわけです。回路は2つのことを前提にしていますが、どちらも証明してはいません。回路に投入されるヘッダーとトランザクションデータが最初から正確だったこと、そしてそもそも回路自体が最初に正しく構築されていることです。
ページを閉じて、両方の前提が実際にはどこにあるのか追跡しました。
1つ目はインデクサの仕事で、証明システムの隣にある別の“付け替え可能な”部品です。2つ目は、その回路を作って監査した人に帰属するもので、継続的な信頼の問題というより一度きりの信頼の問いです。
これで設計が弱くなると言っているわけではありません。外部チェーンデータに基づく外部ライトクライアントの ZK スキームは、こうした継ぎ目をどこかに必ず持っています。Babylon は、それらを売り文句の中に折り込んでしまうのではなく、名前をつけて明示しているだけです。
SNARK が状態遷移を完璧に検証しても、もしどちらかの前提が間違っていたら、「trustless（信頼不要）」の部分は実際に成立しているのでしょうか。それとも、最初から信頼不要ではなかった部分だけが、そう見せていただけだったのでしょうか？
#baby
$BABY
@BabylonLabs_io
$BABY
#baby