ステラ開発財団が「Protocol 28：Adapter」をメインネットに導入。コンセンサス高速化とスマートコントラクト管理を効率化する方針

レイヤー1ブロックチェーンのステラ（Stellar）において、アップグレード「プロトコル28：アダプター（Protocol 28：Adapter）」がメインネットに導入されました。ステラ開発財団（SDF）が9月16日に発表した本アップグレードは、主にステラ上でスマートコントラクトを開発するビルダー向けに設計されています。提案にはコンセンサスを改善する「CAP-83」のほか、スマートコントラクトのアップグレードやデータ移行を容易にする「CAP-85」と「CAP-86」の計3つの改善提案が含まれています。高負荷時のネットワーク処理能力の向上と、長期運用におけるコントラクト管理負担の軽減が図られます。

高負荷時におけるコンセンサスの進行とスループットの改善

ステラでは数秒ごとに、バリデーターが次の台帳（ledger）について合意を形成します。従来の仕組みでは、次の台帳に含めるトランザクションをまとめたトランザクションセット全体を受信するまで、バリデーターが合意形成プロセスを先に進めることに制約がありました。

今回のプロトコル変更提案「CAP-83」の導入により、バリデーターはトランザクションセット全体が到着する前であっても投票を進めることが可能になりました。一定時間が経過してもトランザクションセットを受信できない場合や、受信したセットが無効であった場合には、そのセットを現在の台帳から除外するよう投票できます。これにより、トランザクションデータの伝播が遅れた状況下でもコンセンサスを進めやすくなり、ネットワーク全体のスループット向上につながるとされています。なお、トランザクションセットの並列ダウンロード機能は当初は無効化されており、メインネット導入後に段階的に有効化される予定です。

複数コントラクトの一括更新と柔軟なデータ移行の実現

スマートコントラクトの管理面では、「CAP-85」と「CAP-86」という2つの提案が実装されました。

CAP-85は、同じ基盤コードを共有する複数のスマートコントラクトを一括してアップグレードできるようにする機能です。従来は共有コードを変更する際、管理者がそれぞれのコントラクトを個別に更新する必要がありました。そのため、大規模なコントラクト群ではトランザクションのリソース上限により1回で更新しきれず、新旧のコードが混在するリスクが存在していました。CAP-85では「外部管理された実行コード」を導入し、複数のコントラクトが別のコントラクトによって管理される共通コードを参照する仕組みを採用しました。これにより、共有コードの参照先を更新するだけで、該当するすべてのコントラクトを同時にアップグレードできます。

CAP-86は、スマートコントラクト内で使用するデータ構造の移行を円滑にする変更です。長期運用に伴いデータ項目の追加や削除が必要になるケースがありますが、従来の仕様では想定形式と完全一致しないデータが拒否されることがあり、稼働中のデータ構造変更は困難でした。CAP-86では、項目の過不足があっても処理できる「スパース」と呼ばれる新たな仕組みを導入し、開発者がコントラクトデータを新しい形式へ段階的に移行できるようにしています。

エコシステム参加者に求められる対応と適用範囲

プロトコル28の導入に伴い、通常のSDKを利用するサービスにおいては最新版への更新が基本的な対応となります。

CAP-85およびCAP-86は、開発者が新しいSDKを利用して任意で採用する機能であり、既存のスマートコントラクトが互換性を維持するために直ちに対応する必要はありません。一方で、CAP-83の導入によって新たな台帳データ形式が追加されるため、生の台帳データを直接処理するインデクサーや分析基盤などの運用者にはシステムの対応が求められます。

ポイント

• ステラ開発財団がアップグレード「Protocol 28：Adapter」をメインネットに導入し、開発者向けの基盤機能を刷新した点
• CAP-83により、トランザクションセット受信前でもバリデーターの投票が可能となり、負荷時のコンセンサス推進とスループット向上が見込める点
• CAP-85とCAP-86の導入により、複数コントラクトの同時アップグレードや段階的なデータ移行が可能になり、プロトコル運用の安全性と効率性が高まる点
• 生の台帳データを直接扱うインデクサーや分析基盤では、新データ形式への対応が必要となる点