see
投稿
Prof Denial
·
--
@Dusk キャップブロックは1MBで、エンジニアリングノートのその一行をフットノートみたいに読み飛ばしそうになりました。
読みやすく言うと、1ブロックあたり約250件のPhoenix取引です。割り算してみると、単一のシールド送信は4KB近くになります。透明チェーン上での通常のUTXO送信は500バイト未満です。PLONKの証明自体も約半キロバイト程度でコンパクトなままで、回路の複雑さにかかわらずサイズは一定です。つまり、追加の重さは証明ではありません。
証明ではなく、シールド送信が持ち運ばなければならないノート、nullifier、コミットメントです。これらがないと、支出が誰に紐づくのか追跡されてしまいます。プライバシーは計算ではなくバイトで支払うものなんです。
それがスケーラビリティの全貌だと思いましたが、DuskEVMを掘ってみると違いました。DuskEVMはOP Stack上で動き、バッチャーが取引データをEthereumではなくブロブとしてDuskDSへ投稿しつつ、EVMトランザクションを実行します。紙の上ではうまい—プライバシーにネイティブな決済レイヤーから一般的なコントラクト実行を切り離し、専用のガス市場を用意してDuskDSを軽く保つ。最初の直感では、それで「バイト問題」が解決するはずだと思いました。
ただし、そのブロブは結局DuskDS自身のブロック予算に着地します。シールド送信たちがすでに奪い合っているのと同じ、有限のバイトです。そして現状、DuskEVMはシーケンサーのみで動いておりパブリックなメンプールはありません。つまりボトルネックは消えたのではなく、移動しただけで、途中で順序付けがさらに中央集権化されました。DUSKはDuskDSとDuskEVMの両方にまたがるネイティブのガストークンなので、その実際の使用量の伸びは、EVMトラフィックが本当に規模で現れたときに、その共有バイト予算が耐えられるかどうかにかかっています。
規制された取引所で、ダークプールの注文を同じ清算パイプに流し込むようなものだと思ってください。フローを分けても、清算能力が増えるわけではなく、行列が見える相手が変わるだけです。
モジュラー型のプライバシーチェーンは、レイヤーを追加して混雑を解消するのか？それとも、チェックしづらい場所へ移すだけなのか？
@Dusk #dusk $DUSK
読みやすく言うと、1ブロックあたり約250件のPhoenix取引です。割り算してみると、単一のシールド送信は4KB近くになります。透明チェーン上での通常のUTXO送信は500バイト未満です。PLONKの証明自体も約半キロバイト程度でコンパクトなままで、回路の複雑さにかかわらずサイズは一定です。つまり、追加の重さは証明ではありません。
証明ではなく、シールド送信が持ち運ばなければならないノート、nullifier、コミットメントです。これらがないと、支出が誰に紐づくのか追跡されてしまいます。プライバシーは計算ではなくバイトで支払うものなんです。
それがスケーラビリティの全貌だと思いましたが、DuskEVMを掘ってみると違いました。DuskEVMはOP Stack上で動き、バッチャーが取引データをEthereumではなくブロブとしてDuskDSへ投稿しつつ、EVMトランザクションを実行します。紙の上ではうまい—プライバシーにネイティブな決済レイヤーから一般的なコントラクト実行を切り離し、専用のガス市場を用意してDuskDSを軽く保つ。最初の直感では、それで「バイト問題」が解決するはずだと思いました。
ただし、そのブロブは結局DuskDS自身のブロック予算に着地します。シールド送信たちがすでに奪い合っているのと同じ、有限のバイトです。そして現状、DuskEVMはシーケンサーのみで動いておりパブリックなメンプールはありません。つまりボトルネックは消えたのではなく、移動しただけで、途中で順序付けがさらに中央集権化されました。DUSKはDuskDSとDuskEVMの両方にまたがるネイティブのガストークンなので、その実際の使用量の伸びは、EVMトラフィックが本当に規模で現れたときに、その共有バイト予算が耐えられるかどうかにかかっています。
規制された取引所で、ダークプールの注文を同じ清算パイプに流し込むようなものだと思ってください。フローを分けても、清算能力が増えるわけではなく、行列が見える相手が変わるだけです。
モジュラー型のプライバシーチェーンは、レイヤーを追加して混雑を解消するのか？それとも、チェックしづらい場所へ移すだけなのか？
@Dusk #dusk $DUSK
