原文
Seeking feedback on a new EVM+(Motoko) — skilesare (2026-05-07)
以前に投稿したMotoko EVMに関する1年後の簡単なアップデートです。
私たちは実際にこれを実現しました。EVMは動作しており、GitHub - ethereum/execution-specs: Specification for the Execution Layer. Tracking network upgrades. · GitHubのフィクスチャの99%をパスしています（意図的にスタックを使い果たすテストと再帰テストのみが失敗しています）。
この開発が長年続けられてきた中で環境が大きく変化したため、そして現在の市場状況が厳しいことは承知していますが、今フィードバックと方向性が必要です。
MotokoベースのEVM（Motokoはコンセンサスベース/ブロックチェーンベースのシステム向けに特別に設計されたアクターベースの言語です）が、ネイティブな閾値署名、非同期スケジューリング、よりリッチなウォレットモデル、およびアウトバウンドデータアクセスを備えることで、本当に興味深い設計空間を提示するのか、それともこれらは魅力的だがほとんど不要なプリミティブなのかについて、技術的なフィードバックをいただきたいです。要するに、これにこれ以上時間を費やすべきかどうかです。
私たちがMotokoでEVMを構築したのは、アプリケーション層ではEthereumのように感じられるが、通常のEVMスタックではデフォルトで得られないインフラストラクチャプリミティブを公開するチェーンに余地があると考えているからです。
価値提案は「新しいVM、新しい言語、私たちを信じてください」ではありません。価値提案は次のとおりです。
- EVMの表面を認識可能な状態に保つこと。
- SolidityとEthereumのメンタルモデルを関連性のあるものに保つこと。
- クロスチェーン制御、ウォレット設計、非同期ワークフロー、自動化、および特殊なデプロイメントをより簡単に表現できるベースレイヤーのプリミティブを追加すること。
これらの利点が実際に意味があるのか、そしてデザインがまだ洗練されていない点について、どんな反論でも歓迎します。
このEVMがすでに証明しようとしていること
現在のエンジン開発は、真のEVMパリティを目指しています。
- 142のオペコード
- 18のプリコンパイル
- 5つのトランザクションタイプ
- 13のハードフォーク
- 88/88のJSON-RPC互換性テストをパス
- execution-specスタイルのコーパスで2,681のEthereumフィクスチャファイルをパス
したがって、出発点は「Ethereumの奇妙な代替案を発明しよう」ではありません。出発点は、**より強力なシステムプリミティブを公開しながら、Ethereumのセマンティクスをどこまで維持できるか？**です。
Motoko EVMがEtherianにとって興味深いかもしれない理由
0. ボタンを押すだけで、数ドルでグローバルに分散された13または34の独立ノードEVMを入手できます。
1. クロスチェーン資産制御は、ブリッジ企業の製品だけでなく、コントラクトのプリミティブになり得る
ここでより興味深い機能の1つは、閾値ECDSAベースの署名インフラストラクチャです。これは、EVMコントラクトとウォレットインターフェースが、他のチェーン上のアカウントや資産をネイティブに制御できるように設計できることを意味します。
以下は不要です。
- 運用チームが実行するマルチシグ
- 外部リレイヤーセット
- 専門のブリッジ委員会
- あるいは、概念的には分散化されているが、運用上は集中しているプロトコル
私たちが探求しているのは、ETHライクなコントラクトが、外部チェーン署名を個別のミドルウェアとして追加するのではなく、ネイティブで監査可能なシステム機能として扱えるかどうかです。
それがきれいに機能すれば、以下の設計空間が変わります。
- BTC指向のEVM
- クロスチェーンの財務管理
- コントラクト制御の決済レール
- ウォレットを介したアカウント抽象化
- 署名ポリシーに関するガバナンスが重要な、規制された資産移動
2. 非同期実行は偶発的な後付けではない
現在、非同期のものはすべて、ボット、キーパー、オフチェーンワーカー、cronサービス、またはリレイヤースタックに押し込まれています。
Motoko環境は、非同期が真のベースプリミティブであるため興味深いです。これにより、以下を中心とした実行モデルへの扉が開かれます。
- タイマーとcronスタイルのスケジューリング
- pub-sub / リスナーパターン
- 長期間にわたるワークフロー調整
- 遅延完了パターン
- ウォレット経由の外部呼び出し
- よりリッチなリトライ / ジャーナル化されたステートマシン
これは、素朴な意味での「非同期EVM」を意味するものではありません。EVMの実行には依然として決定論的な境界が必要です。しかし、重要なすべてが単一の同期トランザクション内に収まると見せかけるのではなく、チェーンがライフサイクルのより多くをネイティブに表現できることを意味します。
興味深い疑問は、これが開発者のメンタルモデルを壊すことなく、オフチェーンの調整のかなりの量を複製されたシステムに戻すことを可能にするかどうかです。
3. オラクルと外部データはミドルウェアへの依存を減らせる
もう1つの利点は、アウトバウンドHTTPSアクセスがファーストクラスのシステム機能であることです。これは、分散型オラクルと自動化パターンが常に「どのオフチェーン委員会を信頼してデータをフェッチし、再投稿するか？」から始める必要がないことを意味します。
これはオラクル問題を消滅させるものではありません。データの真正性を魔法のように解決するものでもありません。しかし、アーキテクチャは変わります。
- フェッチングはシステム表面の一部になり得る
- 検証ポリシーはオンチェーンに置ける
- そしてプロトコルは、毎回同じリレイヤーパターンに頼ることなく、外部読み取りについて推論できる
ここでは、決定論、リプレイ可能性、真正性、およびコストモデリングについて反論があることを予想しています。それこそ私が求めているフィードバックです。
4. ウォレットはセッション署名者よりもはるかにリッチになり得る
私たちのEVMで最も差別化されたインターフェースの1つは、ウォレットモデルです。
ここでのウォレットの方向性は「ブラウザ拡張機能だが、私たち独自のもの」ではありません。それは、以下を備えたユーザーごとの実行環境（EVMです）に近いものです。
- 委任されたパーミッション
- メソッドおよびコントラクトスコープのポリシー
- 支出制限
- リカバリタイムロック
- 提出ジャーナリング
- 認証されたトランザクションフロー
- ユーザーのウォレットIDを介した外部呼び出しのルーティング
Ethereumの観点から見ると、これはウォレットがキーペアの薄いラッパーである代わりに、プログラマブルなセキュリティおよび調整インターフェースになり得ることを意味します。
これは以下の点で重要だと考えています。
- より安全なリテールUX
- チームおよび機関向けウォレット
- プラグイン/アプリストアスタイルのウォレット拡張機能
- アカウント抽象化の実験
- チェーンネイティブなアプリ構成
5. 特殊なチェーンデプロイメントがより理解しやすくなる
このアーキテクチャは、地理を考慮した配置選択により、独立した13ノードまたは34ノードのサブネットにデプロイできます。
これは、リテールデジェンUXよりも、以下を検討している人々にとって重要です。
- 機関向けチェーン
- 主権または管轄区域に敏感なデプロイメント
- KYCゲート付き環境
- そして、インフラストラクチャの形状が隠れたバックエンドの詳細ではなく、製品の一部であるチェーン
Ethereumは常に、信頼できる中立性と特殊なデプロイメントとの間で緊張関係を抱いてきました。この種のアーキテクチャが、前者を装うことなく後者を探求するのに良い場所であるかどうかに関心があります。（ここでの暗黙の前提は、メインネットへの固定がデフォルトであるということです。）
未解決の疑問
これらは、ETHネイティブな人々に最も反応してほしい質問です。
- コントラクトに対するネイティブな閾値署名アクセスは、実際に重要視されるほど大きなプリミティブなのか、それとも信頼境界を移動させるだけなのか？
- 非同期/タイマー/pub-subモデルは本当の利点なのか、それとも主に開発者の足元をすくう新たなカテゴリを生み出すだけなのか？
- 決定論的/外部データアクセスパターンはチェーンレベルで統合する価値があるのか、それともオラクルプロトコルやミドルウェアに任せるべきなのか？
- このウォレットモデルは、Ethereumにおけるスマートアカウント/AAの方向性を意味のある形で改善するのか、それとも単に同様のアイデアを異なる形でパッケージ化したものなのか？
- 実際に最も説得力のあるユースケースはどれか？
- スケーラビリティのためのオープンなETHライクなチェーン
- BTC指向のチェーン（ガス/ネイティブトークンとしてのBTC）
- 規制/KYCチェーン
- またはウォレット中心のアプリケーション
- どの部分がすぐにあなたを懐疑的にさせるか？
ここまで来るのは長い道のりでしたが、この成果が現在の状況に合致しているか確信が持てません。私たちは、どれだけ時間とリソースを投入し続けるべきか検討しています。もし、ここにいる誰かにこれが興味深い、あるいは魅力的だと感じられたら、ぜひご連絡ください。新しいzkプルーフやメインネットの直接的なスケーリングほどエキサイティングではないことは承知していますが、正しく行われれば、簡単にブートストラップできるアプリチェーンや、その他潜在的により特殊な実験にとって、本当にエキサイティングな機会がここにあると考えています。
（パフォーマンスが重要である限り、システムは現在、2秒から6秒のファイナリティで1000/標準TPS、毎秒約13.5のUniswap v3スワップを追跡しており、最大400GBのステート/EVMをサポートしています）
2投稿 - 1参加者