Zilch の役割を考えるとき、注目すべき点があると思いました。@Dusk の観点では、異なる2つの言語の間の「翻訳」のようなものです――UTXO のように匿名性を備えた形で保護される価値の言語と、ほとんどのスマートコントラクトのロジックが動作に必要とする、アカウントベースの契約状態の言語です。
Phoenix は、プライベートな専用 UTXO モデルに近い運用をします。価値は独立したメモ(注記)の形で存在し、各メモが全体の状態を知らなくても有効性を自己証明します。ですが、Rusk VM を含めた多くのコントラクト・ロジックでは、より連続した状態モデルが必要になることが多い――そこでは、ある変数が読み取り、変更し、追跡可能な順序で書き戻されます。これは、単なるプライバシーの問題ではなく、2つの異なるデータモデル間のアーキテクチャ上のギャップです。
もしそうだとすると、Zilch の役割は「外部の人に情報を隠す」だけではなく、メモのように分断された価値を、契約状態モデルが消費できる入力へと翻訳するためのブリッジでもあります――データ互換性の問題であり、セキュリティだけの話ではありません。PLONK はその後、元のメモの内容を明かさずに、その翻訳プロセスが正しい規則に従っていることを証明します。
自己反論:これは、UTXO とアカウントベース・モデルの違いについての一般的な理解に基づく推論であり、Dusk の実際の技術実装の細部を正確に反映しているとは限りません。確認には、より深い専門資料が必要です。
私は $DUSK が、Zilch がこの2つのデータモデル間でどのように変換するのかについて、より詳細な技術資料を公開してくれるのを待っています。自分の想像しているとおり、これは UTXO-アカウントの互換性の課題になっているのかを確認したいです。#dusk $BTC $ETH
Phoenix は、プライベートな専用 UTXO モデルに近い運用をします。価値は独立したメモ(注記)の形で存在し、各メモが全体の状態を知らなくても有効性を自己証明します。ですが、Rusk VM を含めた多くのコントラクト・ロジックでは、より連続した状態モデルが必要になることが多い――そこでは、ある変数が読み取り、変更し、追跡可能な順序で書き戻されます。これは、単なるプライバシーの問題ではなく、2つの異なるデータモデル間のアーキテクチャ上のギャップです。
もしそうだとすると、Zilch の役割は「外部の人に情報を隠す」だけではなく、メモのように分断された価値を、契約状態モデルが消費できる入力へと翻訳するためのブリッジでもあります――データ互換性の問題であり、セキュリティだけの話ではありません。PLONK はその後、元のメモの内容を明かさずに、その翻訳プロセスが正しい規則に従っていることを証明します。
自己反論:これは、UTXO とアカウントベース・モデルの違いについての一般的な理解に基づく推論であり、Dusk の実際の技術実装の細部を正確に反映しているとは限りません。確認には、より深い専門資料が必要です。
私は $DUSK が、Zilch がこの2つのデータモデル間でどのように変換するのかについて、より詳細な技術資料を公開してくれるのを待っています。自分の想像しているとおり、これは UTXO-アカウントの互換性の課題になっているのかを確認したいです。#dusk $BTC $ETH
