Duskを調べながら、自分に問い続けていたことがあります。
「ブロックチェーンのアップグレードで、実際に何が変わるのは誰が決めるのか?」
開発者がアップデートを押し出したから、というだけの答えは、ネットワークが金融インフラを支えるはずなのに、満足できるものではありません。
そこで面白くなるのが、Dusk Improvement Proposals(DIPs)です。
DIPは、プロトコルに対して意味のある変更を提案するための、基本的には“構造化された方法”です。
でも、私が特に有用だと思ったのはここです。
単なる技術的な説明で終わらせるべきではない。
真剣な提案には、たとえば次のようなことを説明する必要があります。
なぜこの変更が必要なのか?
どんなトレードオフがあるのか?
古いシステムは互換性を保てるのか?
どうやってテストするのか?
考慮すべきセキュリティ上のリスクは何か?
ブロックチェーンのルールを変えることには、そのコードそのものを超えて、非常に広い影響が起こり得るからです。
たとえば次のような領域に関わる変更を想像してみてください。
取引処理
コンセンサス
スマートコントラクトの実行
プライバシー
決済。
その上にインフラを築く機関は、「何が変わったのか」そして「なぜ変わったのか」を理解する必要があります。
だから私は、DIPプロセスはインフラの物語の一部だと考えています。
ガバナンスが面白そうに聞こえるからではありません。
あなたの上に人々が金融システムを築いているなら、予測可能な変化が重要だからです。
プロトコルの進化が、
「おや、ルールが変わっていた。」
のように感じられてほしくありません。
あなたが望むのは、
提案
議論
レビュー
テスト
実装。
重大なインフラを進化させるには、はるかに健全なやり方です。
そして、私が見守っている問いはこうです。
Duskのエコシステムが成長していく中で、プロトコルの変更がより複雑になっても、このプロセスは透明性と厳密さを保ち続けられるのか?
なぜなら、最終的にはブロックチェーンの品質は「できること」だけで測られないからです。
「どれだけ責任を持って変わっていくか」でも測られます。
#dusk $DUSK @Dusk
「ブロックチェーンのアップグレードで、実際に何が変わるのは誰が決めるのか?」
開発者がアップデートを押し出したから、というだけの答えは、ネットワークが金融インフラを支えるはずなのに、満足できるものではありません。
そこで面白くなるのが、Dusk Improvement Proposals(DIPs)です。
DIPは、プロトコルに対して意味のある変更を提案するための、基本的には“構造化された方法”です。
でも、私が特に有用だと思ったのはここです。
単なる技術的な説明で終わらせるべきではない。
真剣な提案には、たとえば次のようなことを説明する必要があります。
なぜこの変更が必要なのか?
どんなトレードオフがあるのか?
古いシステムは互換性を保てるのか?
どうやってテストするのか?
考慮すべきセキュリティ上のリスクは何か?
ブロックチェーンのルールを変えることには、そのコードそのものを超えて、非常に広い影響が起こり得るからです。
たとえば次のような領域に関わる変更を想像してみてください。
取引処理
コンセンサス
スマートコントラクトの実行
プライバシー
決済。
その上にインフラを築く機関は、「何が変わったのか」そして「なぜ変わったのか」を理解する必要があります。
だから私は、DIPプロセスはインフラの物語の一部だと考えています。
ガバナンスが面白そうに聞こえるからではありません。
あなたの上に人々が金融システムを築いているなら、予測可能な変化が重要だからです。
プロトコルの進化が、
「おや、ルールが変わっていた。」
のように感じられてほしくありません。
あなたが望むのは、
提案
議論
レビュー
テスト
実装。
重大なインフラを進化させるには、はるかに健全なやり方です。
そして、私が見守っている問いはこうです。
Duskのエコシステムが成長していく中で、プロトコルの変更がより複雑になっても、このプロセスは透明性と厳密さを保ち続けられるのか?
なぜなら、最終的にはブロックチェーンの品質は「できること」だけで測られないからです。
「どれだけ責任を持って変わっていくか」でも測られます。
#dusk $DUSK @Dusk

