ここ数日、Duskのプロトコル更新を見ていて、見落としがちな些細な変更に引っかかってしまいました:
**Boreasが、取引にバージョン意識を持たせるよう要求し始めた。**
この言い回し、エンジニアっぽく聞こえます。
でも分解してみたら、解決しているのはとても現実的な問題だと分かりました:
もしあるチェーンがプロトコルのルールをアップグレードしたとき、同じ1つの取引を、別バージョンのノードは「同じ取引」と見なせるのか?
Boreasは現在、canonicalでありversion-awareな取引処理を導入し、さらにVMの価格設定とデプロイ規則を調整し、状態遷移とreverted-eventのセマンティクスを再定義しました。公式ドキュメントでも、これらの変更をハードフォークの中核として明確に挙げています。
以前はL1を見ていると、TPSやファイナリティ、Gasに目が行きがちでした。
でも今は逆に、**プロトコルのアップグレード後も「みんなが理解しているのが同じルール一式であること」を保てるかどうか**のほうが重要なのだと思います。
本当に厄介なのは、アップグレードそのものではありません。
問題は次のようなことです:
ノードはどう解釈するのか?
検証はどう解釈するのか?
過去の取引のリプレイはどう解釈するのか?
アプリケーションはどう解釈するのか?
どれか1つでも理解が違えば、その先は性能の話ではなく、そもそもどの状態を正とみなすのか、という話になります。
だからBoreasは、初めてより具体的に、成熟したブロックチェーンが、一見「セクシーではない」ルールの処理に多くの時間を費やす理由を理解させてくれました。
これはユーザーに新機能を追加するためではありません。
未来の開発者、ノード、アプリケーションに向けて、境界線を先に引くためのものです。
以前は、この種の更新は見栄えのする数字も新製品もないので、コンテンツとして書くのは難しいと思っていました。
でも今は逆に、むしろこれは、チェーンのエンジニアリング成熟度が最もよく分かるところだと感じます。
**真に信頼できるプロトコルとは、今日の取引を処理できるだけでなく、明日のアップグレード後に、昨日の取引が突然別の解釈を持つことがないよう保証できること。**
これが、Boreasが本当に注目に値する点なのかもしれません。
#dusk $DUSK @Dusk
**Boreasが、取引にバージョン意識を持たせるよう要求し始めた。**
この言い回し、エンジニアっぽく聞こえます。
でも分解してみたら、解決しているのはとても現実的な問題だと分かりました:
もしあるチェーンがプロトコルのルールをアップグレードしたとき、同じ1つの取引を、別バージョンのノードは「同じ取引」と見なせるのか?
Boreasは現在、canonicalでありversion-awareな取引処理を導入し、さらにVMの価格設定とデプロイ規則を調整し、状態遷移とreverted-eventのセマンティクスを再定義しました。公式ドキュメントでも、これらの変更をハードフォークの中核として明確に挙げています。
以前はL1を見ていると、TPSやファイナリティ、Gasに目が行きがちでした。
でも今は逆に、**プロトコルのアップグレード後も「みんなが理解しているのが同じルール一式であること」を保てるかどうか**のほうが重要なのだと思います。
本当に厄介なのは、アップグレードそのものではありません。
問題は次のようなことです:
ノードはどう解釈するのか?
検証はどう解釈するのか?
過去の取引のリプレイはどう解釈するのか?
アプリケーションはどう解釈するのか?
どれか1つでも理解が違えば、その先は性能の話ではなく、そもそもどの状態を正とみなすのか、という話になります。
だからBoreasは、初めてより具体的に、成熟したブロックチェーンが、一見「セクシーではない」ルールの処理に多くの時間を費やす理由を理解させてくれました。
これはユーザーに新機能を追加するためではありません。
未来の開発者、ノード、アプリケーションに向けて、境界線を先に引くためのものです。
以前は、この種の更新は見栄えのする数字も新製品もないので、コンテンツとして書くのは難しいと思っていました。
でも今は逆に、むしろこれは、チェーンのエンジニアリング成熟度が最もよく分かるところだと感じます。
**真に信頼できるプロトコルとは、今日の取引を処理できるだけでなく、明日のアップグレード後に、昨日の取引が突然別の解釈を持つことがないよう保証できること。**
これが、Boreasが本当に注目に値する点なのかもしれません。
#dusk $DUSK @Dusk
