ステラ「Protocol 28：Adapter」メインネット導入
レイヤー1ブロックチェーン「ステラ（Stellar）」のアップグレード「プロトコル28：アダプター（Protocol 28：Adapter）」のメインネットに導入された。ステラ開発財団（Stellar Development Foundation：SDF）が9月16日に発表した。
アダプターは、主にステラ上でスマートコントラクトを開発するビルダー向けのアップグレードだ。ステラのプロトコル変更提案「コア・アドバンスメント・プロポーザル（Core Advancement Proposal：CAP）」のうち、3つの変更が含まれる。コンセンサスを改善する「CAP-83」と、スマートコントラクトのアップグレードやデータ移行を容易にする「CAP-85」、「CAP-86」だ。
CAP-83では、ネットワークの負荷が高い場合でもコンセンサスをより速く進められるようにする。ステラでは数秒ごとに、バリデーターが次の台帳（ledger）について合意する。従来はこのプロセスの一部で、次の台帳に含めるトランザクションをまとめた「トランザクションセット」全体を受信するまで、バリデーターがコンセンサスを先に進めることに制約があった。
CAP-83の導入後は、トランザクションセット全体が到着する前でも、バリデーターが投票を進められる。また、一定時間が経過してもトランザクションセットを受信できない場合や、受信したセットが無効な場合には、そのセットを現在の台帳から除外するよう投票できる。
これにより、トランザクションデータの伝播が遅れた場合でもコンセンサスを進めやすくなり、スループットの向上につながるとのことだ。ただし、トランザクションセットの並列ダウンロードは当初無効化されており、メインネット導入後に段階的に有効化される。
CAP-85は、同じ基盤コードを共有する複数のスマートコントラクトを一括してアップグレードできるようにする変更だ。スマートコントラクトを利用するプロトコルでは、同じ基盤コードを共有するコントラクトを多数展開する場合がある。従来は共有コードを変更する際に、管理者がそれぞれのコントラクトを個別に更新する必要があった。
大規模なコントラクト群では、トランザクションのリソース上限があるため、すべてを1つのトランザクションで更新できない場合がある。このため、更新の途中で新しいコードを利用するコントラクトと、古いコードを利用するコントラクトが混在する可能性があった。
CAP-85では「外部管理された実行コード（externally managed executable）」を導入し、複数のコントラクトが別のコントラクトによって管理される共通のコードを参照できるようにする。共有するコードの参照先を更新すれば、それを利用するすべてのコントラクトを同時にアップグレードできるとのことだ。
CAP-86は、スマートコントラクトで利用する特定のデータ構造を変更しやすくするものだ。コントラクトを長期間運用するなかでは、データへの新しい項目の追加や、不要になった項目の削除が必要になる場合がある。
従来の標準的な仕組みでは、あらかじめ想定された形式と完全に一致しないデータが拒否される場合があり、稼働中のコントラクトでデータ構造を変更することが難しかった。CAP-86では、項目の不足や余分な項目があっても処理できる「スパース（sparse）」と呼ばれる新たな仕組みを導入する。これにより開発者は、コントラクトデータを新しい形式へ段階的に移行できるようになるとのことだ。
アダプターの利用にあたり、通常のSDKを利用するサービスでは最新版への更新が基本的な対応となる。一方、CAP-85とCAP-86は開発者が新しいSDKを利用して採用する機能であり、既存のスマートコントラクトが互換性を維持するために利用する必要はない。またCAP-83では新たな台帳データの形式が追加されるため、生の台帳データを直接扱うインデクサーや分析基盤などでは対応が必要となる。
Adapter (Protocol 28) is now live on Mainnet 🌌
— Build on Stellar (@BuildOnStellar) September 16, 2026
→ Faster consensus, even under load
→ Atomic upgrades for fleets of contracts
→ Safer, standard way to migrate contract data
→ No contract changes needed, just rebuild against the SDK pic.twitter.com/SmRqErbEtL
参考：ステラ
画像：PIXTA