現在のブロックチェーンの状況では、ブロックチェーンフレームワークの選択はしばしばトレードオフを伴います。
- Cosmos SDK と CosmWasm は複雑で技術的な負債がありますが、シングルスロットの確定性と IBC へのアクセスを提供します。
- Move はスマートコントラクトの設計に新しいアプローチを探求していますが、エコシステムはツールの提供が最小限であり、異なるバージョンが混乱しています。
- EVM は成熟したツールを誇っていますが、独自の geth フォークとの連携が必要であり、最終的には「EVM 互換」になるに留まります。
Polaris からの学び
詳細なテストネットのデータ分析の結果、Polaris の強みと弱点を慎重に評価しました。CometBFT/Cosmos と EVM のエコシステムの最良の側面を組み合わせているように思われましたが、それぞれの欠点も引き継いでおり、結局は再考することになりました。
CometBFT Mempool の問題
Artio の深刻な混雑の大部分は、CometBFT mempoolのよく知られた問題によるものでした。これらの問題により、トランザクションの含有が妨げられ、EIP-1559 の手数料市場の適切な機能が乱れ、時折チェーンの使用が困難になりました。
プリコンパイルは効率的であるが、開発者の体験は不十分
プリコンパイルを通じて実行性能が大幅に向上（約 500%）したにもかかわらず、開発者体験は著しく悪化しました。foundry のようなツールが期待通りに機能しないことがありました。forge script を実行すると問題が発生しました。これは、ローカルの revm にこれらのトランザクションを実行するために必要なロジックが欠けているためです。
Geth のフォークを維持するのは想像以上に大変
社内で、フォークされた実行クライアントを長期的に維持することは持続不可能だと認識しました。フォークは最新リリースに急速に遅れをとり、カスタムロジックと組み合わさると、維持に相当なレベルのエンジニアリングサポートが必要になることがよくあります。
クライアントの多様性を加味すると、複数のフォークを、いくつかの異なるプログラミング言語にわたって維持することになり、それも既に競争の激しい市場でシニアエンジニアの採用を試みながらです。ほとんどのオルタナティブ L1/L2 EVM チェーン開発者が望んでいるのは、EVM に付随する安定性とツールです。新しい輝かしいコンセンサスアルゴリズムを組み込むためにフォークを実行する面倒な手順を踏むよりも、最新のdocker pull reth:latestを接続するだけで済むのなら、なぜそうしないでしょうか。
BeaconKit の紹介
BeaconKit は、EVM コンセンサスクライアントを構築するためのモジュラーフレームワークで、開発者がレイヤー 1 とレイヤー 2 の両方の EVM ブロックチェーンを、完全な EIP 互換性、シングルスロットファイナリティなどを備えて立ち上げることを可能にします。Go のカウンターパートであるPrysmと同様に、BeaconKit はEngineAPIを使用してコンセンサス層と実行層の間の通信を促進し、EVM 実行環境を CometBFT から完全に分離することを可能にします。
オペレーターは標準の未修正実行クライアントを実行し、Ethereum メインネットとの完璧な/100%の EVM 同一性を達成できます。現時点で、以下の実行クライアントで BeaconKit のテストを行っています：
Geth: Ethereum プロトコルの公式 Go 実装。
Erigon: go-ethereum からフォークされた、より高性能で機能豊富なクライアント。
Nethermind: Ethereum プロトコルを完全にサポートする.NET ベースのクライアント。
Besu: Java で書かれた、Apache 2.0 ライセンスのエンタープライズグレードクライアント。
Reth: パフォーマンスと信頼性に焦点を当てた Rust ベースのクライアント。
Ethereumjs: Ethereum Foundation が管理する Javascript ベースのクライアント。
即時実行とオプティミスティックペイロードビルディング
標準の CometBFT ブロック上にカスタムのBeaconBlockを活用することで、BeaconKit は即時実行をサポートしています。これは、BeaconKit チェーンがバリデータに対し、ブロックを受け入れる前に提案された StateRoot に署名することを強制できることを意味し、ブロック検証プロセスを大幅に簡素化し、ブロックゴシップから取り込みまでの時間を短縮します。これにより、abci.FinalizeBlockが非常に高速になり、オプティミスティックペイロードビルディングへの道を開きます。
「これだけでブロック時間を最大 40%削減できます。」
即時実行により、現在のブロックがファイナライズされる前に StateRoot が分かるため、実行ペイロード（EVM ブロック）の構築を事前に開始できます。これだけでブロック時間を最大 40%削減できます。
BeaconKit は標準の Cosmos モジュールを一切使用せず、チェーン開発者がケースバイケースでカスタムロジックを注入できるようにし、カスタムブロック有効性ルール、カスタムブロック処理ロジックなどを可能にします。
「待って、AccountKeeper が必要？BankKeeper も？？ 🤦 うーん...」は、Cosmos 開発者からよく聞かれる不満です。カスタムステーキングロジックの実装が、すべてを取り除く必要がある 6 ヶ月の研究プロジェクトになってはいけません。BeaconKit ではそうならないようにしました。BeaconKit の設計過程で、SSZ(Simple-SerialiZe エンコーディング)をファーストクラスの市民とし、protobu の混乱を完全に排除しました。これによりEIP-4788の実装が可能になり、許可なしで実行レイヤー上のコンセンサスレイヤーデータを検証および証明できるようになりました。
例えば、Proof of Liquidity では、チェーンがバリデータ提案情報を実行環境にリレーする必要があり、これはBeaconBlockRootに含まれています。私たちの使用例を超えて、独自のオルタナティブ L1 や L2 を開発する他のビルダーも同様の情報へのアクセスを望むかもしれない世界を想像しています。そのため、4788 はとても重要なマイルストーンでした。
Cosmos モジュール？Protobuf エンコーディング？そんなの要らない。
Cosmos-SDK の目標は相互運用可能なモジュールを可能にすることでしたが、これらのモジュールの結合が、私たちが望む方法で実装することを非常に困難にしていることがわかりました。SDK の現在の実装方法は非常に独断的で、柔軟性がほとんどありません。それは私たちには通用しないので、すべてを取り除いて自分たちで実装しました。
ブロブ？ロールアップ？もちろん。
EIP-4844は、BeaconKit ベースのチェーンの将来をスケールさせるために特別に含まれました。メインネット上で即座に利用可能なデータ可用性レイヤーがあることの利点と、それが L2 をどのように可能にするかを見てきました。EIP-4844 のサポートに加えて、チェーン開発者は BeaconKit を ABCI 2.0 互換のコンセンサスエンジンと共に使用でき、したがってRollkitと簡単に統合して強力なレイヤー 2 ソリューションを作成できます。
カスタムブロック有効性ルールとタイプ
BeaconKit を統合する際、開発者は EVM と BeaconBlock の両方で特定の動作を許可するカスタムブロック有効性ルールを簡単に導入できます。例えば、チェーン開発者は、簡単な例として、特定のトランザクション順序に準拠しない ExecutionPayload（EVM ブロック）を拒否するカスタムブロック有効性ルールを実装することを選択できます。
最終的に、これらの「プラグインベース」の有効性ルールは、PEPCのようなメカニズムを統合するように拡張できる可能性があります。これは再ステーキングやクロスチェーンアプリケーションに有用です。
今後の展望は？
BeaconKit は現在、BUSL 1.1 ライセンスの下でソースが利用可能ですが、将来的には MIT ライセンスに切り替える予定です。次の L1 または L2 プロジェクトで BeaconKit を使用することに興味がある場合は、ぜひご連絡ください！リポジトリへのリンクはこちら：https://github.com/berachain/beacon-kit
【Sunrise とは】
Sunrise は Proof of Liquidity(PoL)と Fee Abstraction（手数料抽象化）を備えたデータ可用性レイヤーです。 私たちは DA の体験を再構築し、多様なエコシステムからのモジュラー型流動性を活用してロールアップを立ち上げています。
【Social Links】
【お問合せ】
Sunrise へのお問い合わせはこちらから 👉 Google Form
