#dusk $DUSK @Dusk Duskのストレージ設計バグが気になります、でも良い意味で。PiecrustのVMは、フルのWASMメモリページを64KBチャンクでディスクに書き込みます。Ethereumは32バイト単位のスロットに書きます。1つの値を更新するだけで、粒度にしておよそ2,000倍の差です。
なぜそんなに粗いのでしょう?Duskはキー・バリューのストレージAPIをそもそも完全にスキップしています。コントラクトのメモリ全体がその状態です。素のRustの構造体を書き、BTreeMapを使えば、自動的に永続化されます。SSTOREのような手動の帳簿管理は不要です。Solidityではなく、従来の金融から来たチームにとっては、本当に作りやすいです。
ただし、メモリ全体の永続化はただではスケールしません。チームも明らかにその壁にぶつかったようです。彼らは、毎回スナップショット全体を作り直すのではなく、変更されたページだけを書き戻すためのダーティページ追跡を作りました。賢い修正です。それでも「変更」の単位は64KBページであって、数バイトではありません。数千件のエントリを持つ台帳で、1つのトランザクションが触れるだけでも、アロケータがメモリをどう配置するか次第で、散らばった複数のページを汚してしまう可能性があります。解決済みというより、実際のトレードオフに感じます。
これについてのロードベンチマークはまだ見たことがありません。なので率直に気になります。実際の高頻度の決済トラフィック下で、Piecrustは誰かがストレステスト(負荷試験)していますか?
なぜそんなに粗いのでしょう?Duskはキー・バリューのストレージAPIをそもそも完全にスキップしています。コントラクトのメモリ全体がその状態です。素のRustの構造体を書き、BTreeMapを使えば、自動的に永続化されます。SSTOREのような手動の帳簿管理は不要です。Solidityではなく、従来の金融から来たチームにとっては、本当に作りやすいです。
ただし、メモリ全体の永続化はただではスケールしません。チームも明らかにその壁にぶつかったようです。彼らは、毎回スナップショット全体を作り直すのではなく、変更されたページだけを書き戻すためのダーティページ追跡を作りました。賢い修正です。それでも「変更」の単位は64KBページであって、数バイトではありません。数千件のエントリを持つ台帳で、1つのトランザクションが触れるだけでも、アロケータがメモリをどう配置するか次第で、散らばった複数のページを汚してしまう可能性があります。解決済みというより、実際のトレードオフに感じます。
これについてのロードベンチマークはまだ見たことがありません。なので率直に気になります。実際の高頻度の決済トラフィック下で、Piecrustは誰かがストレステスト(負荷試験)していますか?
