ZeroBlock

#dusk $DUSK @Dusk 私はDuskの最新のエンジニアリング活動を掘り下げていたのですが、注目を集めたのは大きな機能アップデートよりも、ほんの一つの小さな点でした。
最近のPlonkの変更は、要するに不正なプローバーデータをより早い段階で拒否することに関するものでした。
退屈そうに聞こえます。
でも、そのような作業の中に重要なものが隠れていると思います。
問題は、通常の証明が突然無効になったことではありません。
不正にシリアライズされたプローバーの成果物が、最初のチェックを通過してしまい、その後、証明プロセスがそれを使おうとした段階になって初めてトラブルの原因になる——そういう点でした。
この違いは大きい。
ブロックチェーンのセキュリティに関する議論では、暗号が数学的に健全かどうかに焦点が当たりがちです。
しかし本番のシステムには、もう一つ別の問題があります。
がらくたでも、暗号の仕組みに到達してしまうことがあるのです。
そしてそこまで来たら、システムはそれをうまく拒否するのか、より深い実行のどこかで問題を発見するのかを決めなければなりません。
Duskは、その境界を別の方向へ押し進めているように見えます。
まず検証。
高コストな部分が始まる前に、不正な状態を拒否。
私が面白いと思うのは、これがZK証明をより“すごい”ものにすることとは関係がない点です。
むしろ、システムが自分自身の入力を信頼しすぎないようにすることです。
それは小さなエンジニアリング上の細部のように聞こえますが、証明基盤がライブな金融ネットワークの一部になったときに何が起こるかを考えると話は別です。
証明システムは数学的に美しくても、シリアライズ、デコード、キャッシュされた値、そしてエッジケースまわりで見苦しい失敗モードを抱えることがあります。
こうした層は、マーケティング素材としてはめったに映えません。
しかし、成熟したインフラが研究用プロトタイプから自己を切り離し始めるのは、まさにそういうところなのです。
だから私は、Duskの最近の暗号技術の取り組みを、少し違う観点から見始めています。
「証明が安全かどうか」を問うだけではない。
「そもそも証明段階に到達していてはならないものを、実装がどれだけ強く処理拒否するのか」を問うのです。
それが、より面白い指標かもしれません。

ボレアスのアップグレードを見に行きました。面白い部分は、Rusk v1.7.0 が Dusk に追加する新機能だと期待していたからです。
考えれば考えるほど、テストネットのほうがより重要に見えてきました。
プロトコルのアップグレードは、コード変更だけで終わることはめったにありません。それは連携（コーディネーション）の出来事です。ノードは互換性のあるソフトウェアを実行する必要があります。インフラは適応しなければなりません。開発者は、既存の前提がまだ成り立つのかを確認する必要があります。そしてネットワークとやり取りするユーザーが、孤立したテストでは決して表れない問題を露呈させることもあります。
だからこそ、ボレアスを Dusk のテストネット経由で進める動きが私の関心を引きました。
Rusk は、アプリケーションのロジックが基盤となるプロトコル環境に接する部分に非常に近い場所にあります。つまりバージョン変更は、新しいコードが正しく実行されるかどうかだけの話ではありません。周辺のエコシステムがそれに合わせて動けるかどうかを試すことでもあります。
興味深いのは、成功するアップグレードは目に見える活動をほとんど生まないことです。バリデータがスムーズにアップグレードし、サービスが引き続き稼働しているなら、特に大きく指摘すべきことがないかもしれません。しかし、その静かな結果こそが、ネットワークが変化の周りで連携できるという証拠でもあります。
逆もまた同様です。
小さな互換性の問題は、異なる参加者が異なるタイミングでアップグレードしたり、インフラが正式に文書化されていない挙動に依存していたりすると、運用上とても費用のかかるものになり得ます。
そこで私は、ボレアスを「機能発表」としてではなく、Dusk がプロトコルの進化をどう扱うのかのリハーサルとして捉え始めました。
コードは重要です。Rusk のバージョンも重要です。ですがテストネットは、もう少し定量化しにくい何かも測っています。つまり、プロトコルの前提となるルールが変わったときに、その周りの人々やインフラが一緒に動けるかどうかです。
アップグレードで最も重要な部分が「追加されるもの」ではないこともあります。最下層で何が変わっても、それの動き続けることが求められる部分こそが重要なのです。
#dusk $DUSK @Dusk

ユーザーにとって実際に何が変わるのか理解したくて、Dusk Walletのベータを見に行きました。
面白い点は、ウォレット自体ではないことが分かりました。
Dusk Connectは、アプリケーションとウォレットの間に入るレイヤーになりつつあります。SDKは、dAppに特定のウォレットをハードコードさせるのではなく、互換性のあるプロバイダを検出します。これは一見すると小さな実装上の詳細に聞こえるかもしれませんが、ウォレットのアーキテクチャと、Duskがアプリへのアクセスとノードへのアクセスを分離する仕組みと結びつけると話が変わってきます。
新しいDusk Walletは、このシステムの中での1つのプロバイダです。Dusk Connectは検出と権限を扱い、ウォレットはキーとユーザーの承認を管理します。開発者は、必要に応じてW3sperまたはHTTP APIを使って直接ネットワークにアクセスでき、ウォレット層にノード接続の要素を混ぜ込む必要がなくなります。
この分離の考え方に私は惹かれました。
つまりDuskは、DUSKを送るための別のインターフェースを単に提供しようとしているのではありません。ユーザのウォレットとdApp、そして基盤となるネットワークの間で、責任の所在をどこに置くべきかを定めようとしているのです。
また、SDKがフレームワーク非依存であり、実行時の依存関係がないことも、ここでは重要です。統合面が小さいほど、個々のアプリが維持しなければならない独自のウォレット・ロジックは少なくなります。さらに、検出モデルには、最初のウォレットを恒久的な依存先に固定するのではなく、複数の互換ウォレットを並行して用意できる余地も残されています。
とはいえ、ベータではまだ検証すべき点が多い。ウォレットの互換性やセキュリティ上のエッジケース、そして開発者の採用は、発表そのもの以上に重要になってくるでしょう。
しかし、部品をつなぎ合わせて見た結果、より重要な進展はアーキテクチャ上のものだと私は思いました。
Duskは、ウォレットの接続を、すべてのアプリがそれぞれ独立して作り直すべきものではなく、共有インフラとして扱い始めています。
#dusk $DUSK @Dusk

私は「規制された市場インフラ」というフレーズに何度も立ち返りました。そうすることで、ダスクの仕事の残りの部分の読み方が変わるからです。
最初は、そのイベントは主にトークン化の話だと思いました。ですが、それをダスクのプライバシー・アーキテクチャや、選択的開示をめぐる取り組みと結びつけたところ、別の問題が見えてきました。
資産をトークン化することは比較的説明しやすいです。難しいのは、何が実際に起きたかを検証する能力を壊すことなく、異なる参加者が異なる情報を見ることを可能にすることです。
これは、規制市場では特に重要です。プライバシーは、すべてを見えなくすることを目的にすることはほとんどありません。ある機関は取引の機密性を必要とするかもしれませんが、規制当局や認可されたカウンターパーティは、それでも一定の条件が満たされたことの証拠を必要とします。
ここに、プログラマブル・プライバシーが私にとってより興味深くなるポイントがあります。
ダスクのシールド付き取引モデルと、シタデルの選択的開示のアプローチは、プライバシーを「オン／オフの単純なスイッチ」として扱うのではなく、制御できるシステムを示唆しています。トークン化を加えると、その要件はさらに実務的なものになります。所有権ルール、決済条件、コンプライアンス確認は、制限された情報と同時に成り立たなければなりません。
そこで私は、インフラ面をもう一度見直しました。
もしあらゆる規制対象の参加者が、プライバシーのコンプライアンスと決済のために別々のシステムを構築しなければならないのだとしたら、オンチェーンに資産を載せても摩擦はあまり減りません。それは単に、その摩擦が別の場所へ移るだけかもしれません。
だから私が面白いと感じるのは、ダスクがトークン化について語っていることではありません。
興味深いのは、トークン化された資産と、プログラマブルなプライバシー、そして規制されたインフラの組み合わせです。
この3つの要素が示しているのは、より難しいエンジニアリング課題は「デジタル証券を作ること」ではない、という点です。問題はそれらを取り巻く情報境界を設計し、市場がすべての取引を完全に透明化することなく検証可能な状態を保てるようにすることです。
そのインフラ課題こそ、私はより注意深く見ていきたいと思っています。
#dusk $DUSK @Dusk

SMEの資本に関する観点からダスクを調べ始めたところ、結局、SMEが実際に新しい資金調達ルートを使うために、その前に起きなければならないことすべてに、より注意を向けることになりました。
NPEXが私を立ち止まらせたのはその部分です。ダスクは、トークン化された証券を抽象的なアイデアとして始めているわけではありません。NPEXはすでに規制されたSME市場として機能しており、17,500人以上のアクティブ投資家とつながりながら、100社以上のSMEに対して2億ユーロ超の資金調達を促進してきました。
そして、それによってダスクのアーキテクチャがより筋の通ったものになってきました。
トークン化に関する資料では、発行、KYC、AML、保有記録、コーポレートアクションを、その資産そのものにより近づけることについて語っています。ネイティブの発行設計はさらに、従来のT+2のプロセスではなくT+0決済を狙いに行っています。
最初は、それはスピード向上に聞こえます。
でも、より面白いのは、より小規模な発行体まわりのコスト構造に何が起きるかです。
SMEが困るのは、資本が使えないからだけではありません。証券を発行することで、法務作業の連鎖、株主対応、コンプライアンス確認、決済プロセス、そして分断された記録が発生することが原因で苦しむこともあります。もしそれらのプロセスが高コストのままだとしたら、証券をブロックチェーンに載せても、変わることはほとんどありません。
私の目を引いたのは、ダスクがその問題に関するインフラを何年も前から取り組んできた一方で、そのNPEXとの関係によって、既に規制された市場という前提の文脈が得られている点です。2024年に、ダスクの創業者であるエマヌエーレ・フランチオーニがNPEXのテクノロジー・リーダーシップの役割へ移ったことで、そのつながりはさらに実務的になりました。
つまり、私にとって見過ごされていたポイントはシンプルです。
SMEの機会は、本当のところ「株式をオンチェーンに載せる」ことが主眼ではありません。
それよりも、より小さな資本市場が、そもそも存在できるほど経済的に成立するようにすることにあります。
#dusk $DUSK @Dusk

私はDuskのBLS12-381実装を調べていて、最初は「Dusk Networkチームが必要とする追加機能」というフレーズが、些細なエンジニアリング上の詳細に見えました。
しかし、それが実際に何を意味するのかを考えると、話はもっと面白くなりました。
BLS12-381は単なる別の暗号プリミティブではありません。これは、高度な証明や署名の操作が重要になるシステムで使われる、ペアリングに適した楕円曲線群です。ここで重要なのは、Duskが標準の実装をそのまま使っていたわけではないという点です。チームは、自分たちのネットワーク要件に合わせて、その曲線の周りに追加の機能を必要としていました。
それは、私がよく目にするよくある暗号の語りに挑戦します。つまり、インフラは主に既存の暗号ビルディングブロックを組み合わせることだ、という見方です。
難しいのは、ネットワークが必要とする厳密な実行・検証モデルに、そのプリミティブを適応させることになる場合がある点です。
具体例として、ここで挙げられるのは、Duskの要件に合わせてBLS12-381実装に追加された追加機能です。これは、暗号技術がプロトコル・アーキテクチャとは別に存在しているのではなく、それに組み込まれないといけないことを示しています。
ただし、私はこれを「Duskがどこかで基盤となる暗号インフラを置き換えている」かのように解釈しません。
曲線そのものは、確立された暗号構成のままです。より深い変化は、Duskが自分たちのネットワーク要件のために、それをどう実装し、どう統合しているかにあります。セキュリティは、基盤となる数学、実装の正確さ、テスト、そしてプロトコルを取り巻くより広いインフラに依然として依存しています。
この区別は重要です。
私にとって興味深いのは、次のブロックチェーン・インフラのフェーズが、新しいプリミティブを発明することで勝つのか、それとも、確立された暗号を非常に特定の実行環境の中でよりうまく機能させることで勝つのか、という点です。
#dusk $DUSK @Dusk

私はDuskのRWAカストディ設計を調べていて、ある一点がずっと気になって引き戻されました。カストディは単に資産をオンチェーンに載せることとは同じではないのです。
それは当たり前に聞こえるかもしれませんが、セットアップ全体の読み方が変わってきます。
現実世界の資産（RWA）で難しいのは、所有権をデジタルで表すことだけではありません。システムは、やはり法的な資産、適格性、移転ルール、報告、そしてそれらの義務を担う機関に対処しなければならないのです。
一般的な暗号の物語では、トークン化によってRWAが他のトークンのように移せるものになると言われがちです。しかしドキュメントが示しているのは、より制約の多い現実です。
Duskは、プライバシーと制御された開示のもとで規制された資産を表現・管理するためのインフラを提供できますが、基盤となる法的・制度的なレイヤーが消えるわけではありません。
この区別はカストディにおいて重要です。
トークン化された証券にはオンチェーン上の状態があり得ますが、現実世界でのカストディ関係は、依然として規制対象の事業者や既存のプロセスに依存します。
Duskは、その状態の一部や取引ワークフローをオンチェーンでどう扱えるかを変えられます。しかし、カストディ業務の弁護士や規制当局、そしてあらゆるオフチェーンの判断を置き換えるわけではありません。
だからこそ、興味深い問いは「RWAはトークン化できるのか」ということではないと思うのです。
問題は、規制レイヤーがもはや存在しないかのように見せかけることなく、ブロックチェーンが規制された所有を取り巻く運用上の複雑さをどれだけ減らせるかにあります。
カストディが設計上、部分的に制度として残るのであれば、RWAトークン化における本当の機会は、資産そのものなのか、それともそれを中心にすべてを調整するインフラなのか……
#dusk $DUSK @Dusk

私はDuskの規制された証券の観点を調べていくうちに、資産そのものよりも、その周辺にあるワークフローに注意を向けることになりました。
興味深いのは、規制された資産には単なるプライバシーが必要というだけではなく、ルールが求めるときに情報を制御された形で開示できるプライバシーが必要だという点です。
私がそれをCitadelと、ネットワークの口座ベースの取引モデルに結びつけたことで、Duskのプライバシー・アーキテクチャがより面白く感じられました。機密の状態は保護されたままでいられつつ、選択的開示によって、規制対象の参加者が特定の情報を証明したり共有したりするための道筋が提供されます。そして口座モデルが重要なのは、これらのワークフローを、基礎となる取引の詳細をすべての参加者にさらさせることなく、状態の変化として表現できるからです。
次にコンセンサス側を見ました。DuskのSA設計では、提案の検証と承認（ratification）が分離されています。規制されたワークフローでは、この区別が重要です。決済とは単に取引を送信することではなく、結果として得られる状態が台帳の一部になる前に、それが有効であることに複数のネットワーク参加者が合意する必要があるからです。
見落とされがちな別の層もあります。プロビジョナー（provisioners）はDUSKをステークし、インフラを維持する必要があります。つまり、このシステムは機密状態の管理と規制された決済を、経済的かつ運用上のセキュリティ層と結びつけているのです。
私が特に面白いと思うのは、その土台にある調整（coordination）の問題です。規制された資産プラットフォームには、利用者のためのプライバシー、認可された当事者のための開示、機関のための決定論的な決済、そしてワークフローがネットワーク層で壊れないだけの十分な運用信頼性が必要です。
その技術は、これらの要素が一緒に機能するときに初めて役に立ちます。そこでこそ、規制されたオンチェーン資産が抱える本当の複雑さがあると私は思います。
#dusk $DUSK @Dusk

私は、夕暮れ（Dusk）のSAコンセンサスを見に行きました。面白いのはコミッティ選定だと思っていたのですが、実際には「コミッティが選定された後に何が起きるか」により注意を向けることになりました。
SAはコンセンサスを提案のバリデーションと、ラティフィケーション（承認）に分けます。これは技術的な設計上の選択のように見えますが、報酬構造やステーキング要件と比べてみると話が変わります。ネットワークは単に、ブロックを生成した1人のバリデータに報酬を払うだけではありません。報酬は、ブロック生成バリデーション・コミッティと、ラティフィケーション・コミッティに分配されます。
生成側は、含まれるクレジット数に応じて70%に加えてさらに10%を受け取ることができます。一方で、バリデーションとラティフィケーションはそれぞれ5%ずつ受け取ります。
これは、インセンティブモデルの捉え方を変えます。
この仕組みは、同じブロックが合意の異なる段階を通過し続けられるように、複数のグループへ実質的に支払いをしているようなものです。重要なのは、参加が信頼できたままである場合にのみ、高速な決定的決着（fast deterministic settlement）が有用になるという点です。繰り返し参加に失敗するコミッティメンバーはソフトペナルティを受ける可能性がありますが、証明可能な無効な振る舞いは、焼却（burn）されるステーキングにつながり得ます。
さらに、見落としがちな運用面もあります。プロビジョナー（provisioner）は少なくとも1,000 DUSKを必要とし、インフラをオンラインの状態に保ち、同期させ続ける必要があります。基本的に公開されている要件は、CPUコア2、RAM 4GB、ストレージ50GB、ネットワーク10Mbpsという、控えめなものです。
だから本当の制約は、単純なハードウェアのコストではないかもしれません。制約は運用上の規律です。
私が面白いと感じたのは、SAが、参加者の数を単に増やすというより、合意（agreement）のコストを下げることを中心に設計されているように見える点です。ランダムなコミッティが責任を分散し、報酬とペナルティのシステムが参加の確実性を高めようとしています。
それによって、コンセンサスは「誰がブロックを生成するか」ということよりも、「順番が来たときに、十分な数の独立したオペレーターが一貫して出てくるか」に関わるものになります。
#dusk $DUSK @Dusk

ダスク・ブリッジのマイグレーション・フローを見に行って、「面白い部分」はEVMコントラクトだと期待していました。ところが実際にあったのは、その裏で動いているサイナー（署名者）でした。
マイグレーション用のコントラクト自体はかなり単純でした。ユーザーはERC20またはBEP20のDUSKをロックし、マイグレーションのイベントが発行されます。しかし、そのイベントが魔法のようにネイティブのDUSKを生み出すわけではありません。外部サービスがそれを監視し、ダスク側で資金を再発行する必要がありました。
この違いは、最初に見える以上に重要です。
ダスクのより広いアーキテクチャは、ラップ資産や外部のカストディアンなしで、DuskDSとDuskEVMの間で価値を移せるネイティブ・ブリッジモデルへと向かっていました。それでも、古いマイグレーション経路は依然として、観測したEVMイベントを実際のダスク取引へ変換するための運用上の署名ウォレットに依存していました。
インシデントのデータは、その依存関係を見える形にしています。1月16日、攻撃者がそのウォレットを侵害し、その後盗んだDUSKをブリッジ経路で移動させました。手順には、まず7,880 DUSKのブリッジ、続いてさらに191万DUSKが含まれ、その後、ミティゲーションによって追加の891万DUSK試行が止められました。
私が重要だと感じるのは、単にウォレットが侵害されたという事実だけではありません。
イベントの取り込みと価値の解放が、事実上1つの運用経路で結びついていた点です。スマートコントラクトは決定的であり得る一方で、それを取り巻くシステムは、鍵の管理（カストディ）、サーバの分離、監視、そしてトランザクション処理に依存しています。
イベント取り込みと署名、さらにマイグレーションイベントを永続化されたジョブへ変換する部分を分離する再設計は、したがって単なるセキュリティパッチ以上の意味があります。信頼が置かれる場所そのものが変わります。
これを読んで、ブリッジについて考え方が変わりました。契約は私たちが最初に精査することが多い部分ですが、真の信頼境界は、契約の数層も後ろ、つまり「いつイベントが金銭になるか」を決めるソフトウェアの内部にある可能性があります。
#dusk $DUSK @Dusk

Duskのセキュリティ面を理解したくて、AEGIS Security Analysisを調べてみました。すると、ピースがどのように噛み合っているかという点で、もっと興味深い何かに気づきました。
私の注意を引いたのは単一のセキュリティ主張ではありませんでした。プロトコル設計、バリデータのふるまい、そして何かを誤ったときに生じる経済的コストの関係です。
セキュリティレビューは技術的な弱点を特定できますが、本当の問いは、その弱点が実運用のネットワークに遭遇した後に何が起きるのかです。Duskのアーキテクチャはバリデータと、それを取り巻く仕組みに重みを置いています。つまりセキュリティは、コードが意図どおりに動くかどうかだけではありません。参加者が、状況が不快になる局面でも適切に振る舞うための十分な経済的な理由を持てるかどうかも問題になります。
私は、セキュリティ分析をDuskのより広いネットワーク設計やトークンの仕組みと比べる際、その区別を何度も思い返しました。
トークンは調整レイヤーの一部です。バリデータが信頼性を保ち続けるには、経済的な動機が必要です。ガバナンスとプロトコルのルールが、変更がどう導入されるかを決めます。一方で、セキュリティのプロセスは、実装上の細部が経済的な問題になる確率を下げようとします。
それらは別々の3つのレイヤーですが、互いに依存しています。
きれいな監査が自動的に安全なインフラを生み出すわけではありません。強いインセンティブは、欠陥のある実行ロジックを補うことはできません。そして、基盤となるシステムが安全に運用するのが難しければ、良いガバナンスでさえうまくいかないことがあります。
それで私は、AEGISを安全の証明書というより、より大きなリスクシステムへの一つの入力として見るようになりました。
見落としやすい点として私が最も簡単に感じたのは、プロトコルのセキュリティは最終的には運用上の規律だということです。コード、インセンティブ、バリデータ、そしてレビューのプロセスは、それらがストレス下でも同時に機能し続けて初めて意味を持ちます。
そこに、真のセキュリティ上の前提が宿っているように思えます。
#dusk $DUSK @Dusk