マネーグラムバリデーターの展開は、Solanaの流動性集中化の懸念を引き起こす

SOL1.26%

マネーグラムはアクティブなSolanaバリデータノードを展開し、Solana Developer Platform(SDP)に統合しました。これにより、インフラの消費者からコンセンサス参加者への転換を示しています。ハリー・フワンは、コンプライアンスに準拠したオーダーフローのレーンはSolanaの機関流動性を少数の承認されたルートに集中させるリスクがあり、プロトコルの許可不要な設計にもかかわらず実質的なゲートキーパーを生み出す可能性があると警告しています。従来の金融機関がAnchorage DigitalやChainalysisなどのコンプライアンス提供者とともにバリデータインフラを採用するにつれ、需要は純粋なステーキング利回りから規制適合性へとシフトしており、ゼロトラストのパブリックコンセンサス要件とレガシー金融のコンプライアンス義務との間に緊張が生じています。

マネーグラム、バリデータ運用を通じたインフラのステージング拠点を確立

マネーグラムがアクティブなSolanaバリデータノードを展開したことは、戦略的なインフラ優先のアプローチを示しています。フワンは、この動きはマネーグラムの支払いシステムとバリデータ運用の直接的な統合と解釈すべきではなく、むしろ長期的なステーブルコインや支払いレールとの統合の扉を開くために、プロトコルレベルのインフラ運用に入ったと述べています。

孤立した状態でバリデータを運用することにより、マネーグラムは技術的能力のストレステストを行い、高頻度の鍵管理を習得し、公開ノードのゼロトラストアーキテクチャを本番環境でナビゲートしながら、コアの決済台帳をライブネットワークに公開する前の準備を進めることができます。しかし、公開バリデータを機関のハードウェアセキュリティモジュール(HSM)アーキテクチャに統合することは、従来の金融のコールドストレージ要件とSolanaの高頻度署名要求との間に対立を生じさせます。

「Solanaの現行アーキテクチャでは、バリデータのIDと投票権は非常に頻繁に署名される必要があり、一般的にホットパスの中に存在する必要があります」とフワンは述べました。「これに対して、承認された引き出しキーは通常の運用中には必要なく、投票アカウントを管理するため、コールドストレージ、HSM、MPC(マルチパーティ計算)、またはオフラインのキーセレモニーを通じて管理すべきです。」

SolanaのAlpenglowアップグレードは、BLS署名スキームを用いたオフチェーンの軽量メッセージを導入し、ホットパスでの高頻度投票署名の負担を軽減する可能性があります。フワンは、オンチェーンの投票取引が削除され、システムがBLSベースの投票に移行すれば、HSMやエンクレーブ、リモート署名アーキテクチャがより現実的になると指摘しています。

規制の厳しい機関がコンセンサスに参加する場合、擬似匿名のユーザーのグローバルプールの取引を確認し、コンプライアンス義務との緊張を生じさせます。「支払い会社がパブリックな許可不要ネットワークのコンセンサスに直接参加する場合、その活動がAML、制裁、Travel Rule、支払いライセンス、アウトソーシング、運用のレジリエンスフレームワークの下でどのように扱われるべきかはまだ完全に決まっていません」とフワンは述べました。

コンプライアンスに準拠したオーダーフローのレーンはSolanaの流動性を中央集権化するリスク

企業がSDPとコンプライアンス提供者を採用するにつれ、規制適合性への需要が高まっています。SolanaはEthereumスタイルのグローバルパブリックメモリプールを持たないため、この需要は孤立したオーダーフローのレーンとして現れます。フワンは、実際にはこの需要がコンプライアンスに準拠したオーダーフローのレーンやポリシーベースの実行、許可された資産レイヤーへと進化し、機関の注文がKYT(Know Your Transaction)で審査されたルートを通じてルーティングされる可能性が高いと述べました。

「もしコンプライアンスに準拠したオーダーフローのレーンがあまりにも支配的になると、実質的な流動性や高品質な実行が少数の承認されたルートに集中する可能性があります」とフワンは警告します。「その場合、理論上はプロトコルは許可不要のままでしょうが、実際にはゲートキーパーが出現し、機関の流動性を中央集権化する可能性があります。」

バリデータの自律性を維持するために、Flowraはポリシーベースの提案者(PBP)フレームワークを採用しています。フワンは、バリデータを単一のビルダーやブロックエンジンに固定するのではなく、収益性、有害性、リスク、コンプライアンス基準に基づいて複数のビルダーやオーダーフローソースから選択できるようにすることを目標としています。FlowraのPBPフレームワークは、機関ノードがプログラム可能なポリシーを通じて有害なMEVをブロックできるようにします。

機関バリデータはMEV収益と受託者義務の対立に直面

最大抽出可能価値(MEV)はブロックチェーンバリデータの主要な収益源となっていますが、フロントランニングやサンドイッチ攻撃のような略奪的行為は、機関の最良執行ポリシーやウォール街の市場行動基準と対立します。フワンは、重要なのは機関がMEVに参加すべきかどうかではなく、どの形態を許容し、どれを制限すべきかだと述べました。

「もし機関運営者がMEVを完全に放棄すれば、委任者や投資家に行き渡る可能性のある収益を手放すことになるかもしれません」とフワンは述べました。「しかし、攻撃的なMEV戦略を制限なく許可すれば、特にユーザーに害を及ぼす戦略は、受託者義務や市場行動基準と対立する可能性があります。」

よくある質問

マネーグラムはSolanaのネットワークで何をしたのですか?

マネーグラムはアクティブなSolanaバリデータノードを展開し、Solana Developer Platform(SDP)に統合しました。これにより、インフラの消費者からコンセンサス参加者へと転換しました。ハリー・フワンは、これはマネーグラムの支払いシステムとバリデータ運用の直接的な統合ではなく、むしろ長期的なステーブルコインや支払いレールとの統合の扉を開くためのプロトコルレベルのインフラ運用に入ったと述べています。

ハリー・フワンはなぜSolanaのコンプライアンスに準拠したオーダーフローのレーンについて警告しているのですか?

フワンは、コンプライアンスに準拠したオーダーフローのレーンがあまりにも支配的になると、実質的な流動性や高品質な実行が少数の承認されたルートに集中し、理論上はプロトコルは許可不要のままである一方で、実際にはゲートキーパーが出現し、機関の流動性を中央集権化するリスクがあると警告しています。

Flowraのフレームワークは、機関のMEVに関する対立をどのように解決していますか?

Flowraのポリシーベースの提案者(PBP)フレームワークは、機関ノードがプログラム可能なポリシーを通じて有害なMEVをブロックできるようにします。このフレームワークは、バリデータが収益性、有害性、リスク、コンプライアンス基準に基づいて複数のビルダーやオーダーフローソースから選択できるようにし、単一のビルダーやブロックエンジンに固定されることを防ぎます。

免責事項:本ページの情報には第三者提供の内容が含まれる場合があり、参考目的のみで提供されています。これらはGateの見解や意見を示すものではなく、金融、投資、または法律上の助言を構成するものでもありません。暗号資産取引には高いリスクが伴います。意思決定を行う際には、本ページの情報のみに依存しないでください。詳細については、免責事項をご確認ください。
コメント
0/400
コメントなし