AGAVE 図解ハンズオン v4.2
基準日 2026.08.23

AGAVE v4.2 — 2026.07.31 リリース

コードは、もう入っている。
あとはスイッチを入れるだけ。

Agave 4.2 の目玉は、リリースと同時には動きません。フィーチャーゲートという段階的なスイッチで、ひとつずつオンになります。いまどこまで入ったのかを見てみましょう。

フィーチャーゲート盤 MAINNET / 2026.08.23
数字は「全部オンになったとき」の姿です。ゲートが入るまで、ネットワークの動きは変わりません。

この盤の読み方

Agave 4.2 を理解する鍵は、たったひとつの言葉です。

フィーチャーゲートとは

新しい動きは、クライアントを更新した時点でコードとしては入っています。でも、スイッチが入るまでは何も変わりません。

スイッチを入れるのは投票ではありません。そのゲートを認識するソフトを動かしているバリデータが十分に増えたのを見て、エポックの切れ目に有効化されます。運用上の目安は、ステークのおおむね95%です。だから「リリース済み」と「もう使える」は、別の話になります。

レントは5段、スロットは4段。ひとつずつ入れて、様子を見て、危なければ止まる。それが 4.2 の設計です。

コードが入っている
ゲートがオン
→ 動きは今までどおり

ここまでの道のり

リリースから有効化まで、実際に何が起きたか。

  • 2026.07.31
    Agave 4.2 リリース
    Alpenglow のコードもここで初公開。
  • 2026.08.11
    一般利用を推奨
    バリデータへの更新の呼びかけが始まる。
  • 2026.08.18
    フィーチャーゲートの有効化を開始
    予定は8月17日、実際は1日遅れ。ゲートは入っても、効き始めるのは次のエポックから。
  • 2026.08.21 · EPOCH 1020
    スロットタイム 350ms が発効
    誕生以来はじめて、Solana の刻みが速くなった。ゲート自体はひとつ前のエポック1019で入り、規定どおり1エポック後に効き始めた。残り3段。
  • 2026.10(目標)
    Agave 4.3 で Alpenglow を起動
    4.2 に積んだエンジンに、ようやく火が入る予定。

3つの目玉のほかに

4.2 には、積まれてはいるが、まだ動かさないものがあります。

そのほかの変更 XDP transmit がデフォルトで有効に。ステークプログラムのウォームアップとクールダウンの計算が、浮動小数点から決定的な整数演算へ(SIMD-0391)。ほとんどのアプリに影響はありません。
💡

1,232バイトは Solana の都合ではなく、IPv6パケットの都合でした。

1,232 の正体、4,096 の理由

上限がどこから来て、なぜ今の数字で止まったのか。4つの場面で追いかけます。

DEMO パケットの引き算
1,280 B
旧上限 1,232
1,280 IPv6 40 フラグメント 8 = 1,232 B
4 KiB page
01,280 B
1245 → 全部を送り直し

UDP時代の制約

UDP には、大きなデータを分けて送って組み直す仕組みがありません。だからトランザクションは1個のパケットに丸ごと収める必要がありました。しかも途中で分割されないよう、IPv6 が「どんな経路でも必ず通る」と保証する 1,280 バイト以内に。

アカウントの入れ物くらべ

アドレスは1つ32バイト。何個まで入るのか、動かして確かめてください。

DEMO アドレスは何個入る?
20
legacy 32Bのキーをそのまま並べる
1,232 B
v0 + ALT 1Bの参照に圧縮 — ただしテーブルの管理が要る
1,232 B
v1 32Bのまま直接。ALTは使えないが、使う必要がない
4,096 B

署名や命令データの分として、どの行にも約220バイトを先に置いています。実際の内訳はトランザクションごとに変わります。

かたちを見る

v1 は中身の並び順そのものが変わります。紫の部分を押すと説明が出ます。

ANATOMY 3つのフォーマット
legacy
署名 ヘッダ アドレス ブロックハッシュ 命令
v0
署名 0x80 ヘッダ アドレス ブロックハッシュ 命令 ALT
v1
0x81 — 先頭の1バイト

これが v1 の目印です。先頭にあるので、中身を読み解かなくてもフォーマットを見分けられます。

模式図です。帯の幅は実際のバイト数には比例していません。

変わること、変わらないこと

項目 legacyv0v1
サイズ上限1,232 B1,232 B4,096 B
アドレス数約32(サイズ次第)64(ALT経由)64(そのまま)
ALT使えない使える使えない
同じアドレスの重複許される許される拒否される

署名12・命令64・CU上限は据え置きです。大きくなったのは入れ物だけで、できる仕事の量は変わりません。

移行の落とし穴

あなたの立場を選んでください。関係するものだけ表示します。

    何ができるようになる?

    ZK証明

    秘匿送金などで使う、大きな証明データ。

    入れ子のマルチシグ

    機関投資家が使う、署名が何重にもなる構成。

    BLS署名

    専用の高速化を持たない署名方式。

    これまで複数に分けたり Jito バンドルにまとめたりしていた処理が、1つのアトミックなトランザクションになります。ただし大きなトランザクションは帯域を多く使うため、同じ優先度でも高めの手数料が必要になる見込みです。

    💡

    レントは家賃ではなく保証金。10分の1になっても、返ってくることは変わりません。

    なぜ下げるのか

    安くしてあげるため、ではありません。提案の言い分はこうです。

    誰も値上げしていないのに、高くなっていた。
    1. 根拠のない定数6,960 は、実際のディスク代から計算された数字ではありません。何年も前に置かれた定数です。
    2. SOL の価格が上がったランポート建ての数字は変わらないまま、実質的な負担だけが大きくなりました。誰かが決めた値上げではありません。
    3. 他チェーンより高い提案は「実際の資源コストによる説得力のある正当化はない」と書いています。つまり、高さに理由がない。
    下がると、何ができるようになるか
    受け取る側の障壁

    事業者が黙って肩代わりできる

    いまはトークンを受け取るだけで約0.002 SOL の口座代がかかります。ユーザーに払わせるなら、先にウォレットへ SOL を入れてもらうことになる。一般向けアプリでは、そこで人が離れます。

    作り手の障壁

    アカウントを大量に使うアプリが成り立つ

    プレイヤーごとに状態を持つゲーム、保有者ごとに口座が要るトークン化、価格帯ごとに領域を持つ板。どれも口座数に比例して費用が増えるので、10分の1は効きます。

    トレードオフは1つだけです。保証金はスパムを抑える重しでもあるので、安くすれば大量にアカウントを作る費用も下がります。この先に出てくる仕掛けは、すべてその1点への備えです。

    均等ではない、5段の階段

    6,960 から 696 へ。一度には下りません。段を押すと、その時点の姿が見えます。

    DEMO lamports_per_byte の下がり方
    トークンアカウント1つ分
    165 B + 128 B = 293 B
    0.002039SOL
    2,039,280 lamports
    全部下りきると 0.000204 SOL
    RISK — 概念図

    提案には「リスクは段が進むほど、加速して大きくなる」と明記されています。だから次に進むのは、安全と判断できたときだけです。

    2026年8月23日時点では、5つのゲートはどれも入っていません。実際の値は 6,960 のままです。USD換算は出典では約$0.159→約$0.0159ですが、SOLの価格で変わります。

    自分のアカウントで試す

    必要な保証金は、データの大きさで決まります。

    DEMO 保証金の計算機
    minimum_balance = ( 128 + 1,024 ) × lamports_per_byte
    1,024
    いま — 6,960
    0.008015 SOL
    下りきると — 696
    0.000801 SOL

    128バイトはどのアカウントにも付く固定の管理領域です。閉じればどちらの金額も全額戻ってきます。

    いま持っているアカウントは?

    追加で払う必要はありません

    既存のアカウントもプログラムも、そのまま動きます。レント削減は「制約をゆるめる」変更なので、これまでのロジックが壊れることはありません。

    それどころか、新しい最低額まで残高を引き下げることが認められます。余分に預けていた分は、取り戻せるということです。

    そのまま動き続ける
    余剰分は引き出せる
    閉じれば全額戻る

    なぜ一気に下げないのか

    安くすること自体に、副作用があるからです。

    1保証金が下がる
    2アカウントを作る費用が下がる
    3ステートが増えやすくなる

    ステートとは、すべてのバリデータがディスクに持ち続けるデータのことです。増えるほど参加に必要なマシンが重くなり、バリデータを続けられる人が減ります。だから保証金は、ステートを無闇に増やさせないための重しでもあります。

    いま、どれくらい空いているか
    495 GB
    空き 約500 GB
    AccountsDB の使用量1 TB
    +0.3 GB / day
    新規作成と解約を差し引いた、いまの増え方。
    4〜5年
    このペースが続いた場合に、空きを使い切るまでの目安。単純な割り算です。
    わざと埋めるには、いくらかかるか

    保証金は返ってくるお金です。だから攻撃者にとっての費用は「支払い」ではなく、「その額を拘束し続けること」になります。安くしたあとでも、この金額が必要です。

    $17.2M
    削減後、残りの空きを埋め尽くすために拘束が必要なSOL。
    $51M
    推奨ディスク容量を2TBに引き上げた場合。埋める量が増えるぶん、費用も上がります。
    いま何がスペースを使っているか(epoch 997)
    最大カテゴリ
    SPL Token
    ウォレットがトークンを持つための入れ物です。1つあたり約0.002 SOL。比率は公表されていません。
    ≈30%
    OpenBook + Serum
    オンチェーンに注文板を持つ取引所です。市場ごと・利用者ごとに大きなアカウントを確保し、取引が終わっても閉じられずに残りがちです。

    この2つは別のカテゴリです。SPL Token の領域のうち約30%は、Pump.fun のようなローンチパッド由来と推定されています。SPL Token 自体の比率は公表されていないため、ここでは大きさを描いていません。

    この節の数値は、Solana Foundation が2026年6月に公表したレント削減の分析によります。

    いちばん場所を取っている SPL Token アカウントは、今回まさに10分の1に安くなるものです。効果が大きいぶん、増え方への影響も大きい。だから一段ずつ下ろします。

    下げたあと、戻れるように

    3つの装置が、この変更を引き返せるものにしています。

    01 — SIMD-0437

    5つに分けたゲート

    一段ごとに様子を見て、危なければそこで止まります。全部を一度に下ろす必要はありません。

    02 — SIMD-0392

    既存アカウントの据え置き

    必要な最低額は「いまのレートでの最低額」と「実行前の残高」の低い方です。だからレートが上がっても、既にあるアカウントが不足になることはありません。ただし、そのトランザクションで新しく作られたか、サイズを変えられたアカウントは、いまのレートで判定されます。

    据え置き既存で、サイズを変えていない
    新レート新規作成、またはサイズ変更(realloc)
    03 — SIMD-0438

    先に用意した非常ボタン

    6,960 に戻すためのスイッチが、下げ始める前から用意されています。問題が起きてから設計する必要はありません。

    02 がないと 03 は使えません
    「回収したあとに戻されたら、不足しないの?」

    下がったぶんを引き出したあとで 6,960 に戻されたら、残高が足りなくなりそうに見えます。実際にはなりません。判定に使うのが「低い方」だからです。

    レートでの最低額 実行前の残高 必要額
    下げる前 2,039,2802,039,2802,039,280
    696 に下がる → 回収 203,9282,039,280203,928
    6,960 に戻す 2,039,280203,928203,928

    最後の行がすべてです。レートが10倍に戻っても、必要額は残高と同じ 203,928 のまま。不足も追徴も起きません。ただしここから先へは引き出せなくなります。閉じて全額回収することは、いつでもできます。

    下げるだけでなく、戻せる。だから段階的に進められる。
    💡

    一気に半分ではなく、50msずつ4回。しかも危なくなったら、そこで止まります。

    4段の階段

    レントの階段は段差がばらばらでしたが、こちらはきれいに50msずつです。段を選ぶと、その世界の数字に切り替わります。なお、ここに出てくる ms はすべて目標値で、実測はこれよりわずかに長くなります。

    DEMO スロットタイムの下がり方
    リーダーウィンドウ(4スロット)
    1.40 s
    1人のリーダーがブロックを作り続ける時間。
    エポックの長さ
    42.0 h
    スロット数は 432,000 のまま。だから実時間が縮みます。
    バリデータの参加料 VAT(1エポックあたり)
    1.4 SOL
    Alpenglow に切り替わると、投票の手数料が消える代わりに参加料がかかります。エポックが短くなるぶん減額され、1日あたり約0.8 SOL に保たれます。

    なぜ普及を待つのか。フィーチャーゲートは後方互換のないハードフォークなので、更新していないバリデータはネットワークから離れてしまいます。だから有効化はテストネット、デブネット、メインネットの順に進みます。

    次の段に進む条件は2つ。ひとつは、そのゲートを認識するソフトを動かしているステークが十分に増えること。有効化は投票ではなく、普及を見てエポックの切れ目に行われます。運用上の目安はおおむね95%です。もうひとつは、ブロックのスキップ率が高くなっていないこと。スキップ率とは、担当のリーダーがそのスロットでブロックを出せなかった割合のことです。ただし、その閾値が具体的にいくつなのかは公表されていません。関門は4回あります。

    鼓動をくらべる

    数字ではわかりにくい差です。実際のリズムで鳴らしてみてください。

    DEMO 400ms と、選んだ速さ
    400msこれまで2.5 slot/s
    350ms2.9 slot/s

    ▶ を押すと、2つのリズムが同時に流れます。上の階段で速さを変えられます。

    効き始めるのは、次のエポックから

    スイッチが入った瞬間には変わりません。ここには理由があります。

    EPOCH E
    ゲートがオンになる
    でも、このエポックは従来のまま動き続けます。
    EPOCH E+1
    最初のスロットから発効
    ここではじめて、新しいスロットタイムになります。

    スロットタイムを縮めると、1スロットに入るシュレッド(ブロックの断片)の上限も下がります。エポックの切れ目で切り替えることで、Turbine がきれいに新しい上限へ移れるようにしています。

    縮むもの、縮まないもの

    速くなるのは「刻み」であって、「総量」ではありません。

    縮むもの
    • 1.6s → 800msリーダーが独占する時間
    • 1ブロックの計算上限。400ms の 100M CU が、350ms では 87.5M CU に
    • エポックの実時間(48時間 → 24時間へ)
    =変わらないもの
    • 毎秒の計算上限。どの段でも約 250M CU/秒
    • 64スロットあたりの tick 数
    • 4リーダーウィンドウのスロット数
    • 432,000エポックあたりのスロット数
    • 実時間で見たインフレ率

    1年あたりのスロット数を逆比で増やすことで、実時間で見たインフレは変わらないように調整されています。

    速くなると、何が変わる?

    確認が速い

    送ってから結果が返るまでが短くなります。

    🛡️
    検閲されにくい

    1人のリーダーが順番をいじれる時間が半分になります。

    🗓️
    報酬が早く届く

    エポックが短くなるぶん、精算の周期も短くなります。

    注意も2つ。これは破壊的変更なので、スロット数から時間を計算しているアプリやSDKの定数は見直しが必要です。また Alpenglow より先に 200ms に届くと、投票の回数が倍になり、バリデータの投票コストが約2倍になり得ます。

    💡

    エンジンは積み終わっています。あとは鍵を回すだけ — それは 4.3 の仕事です。

    いまどこにいるか

    4.2 に完全な実装が入りました。ただしメインネットでは動かしません。

    完了

    実装

    Agave 4.2 に同梱されました。4.2 を動かしているバリデータは、すでに完全な実装を積んでいます。

    進行中

    テストと監査

    この期間は、コミュニティのテストクラスタでの検証と、コードの強化にあてられています。

    待機

    メインネットで起動

    Agave 4.3 で。2026年10月が目標とされています。

    Votor

    新しい投票エンジンです。TowerBFT と、合意形成における Proof of History の役割を置き換えます。バリデータどうしが直接やりとりして合意にたどり着き、時刻の基準は固定のブロック間隔と各自のタイマーが担います。

    4.3 で何が変わるのか

    確定までにかかる時間が、桁ごと変わります。

    TowerBFTいま≈ 12.8 s
    Votor目標≈ 150 ms

    帯の長さは同じ縮尺です。Votor 側がほとんど見えないこと自体が、この変化の大きさを表しています。あわせて、オンチェーンの投票トランザクションそのものが廃止されます。なお、よく一緒に語られる Rotor(ブロック配信の刷新)は別の提案で、ここには含まれません。Turbine はそのまま残ります。

    ⚠️

    10月は「目標」です

    4.3 は 2026年8月5日に alpha.3 が出ていますが、本番利用には適さないと明記された段階です。確定した日付ではありません。

    はじめて賞金の的になった

    開発中は対象外だった Alpenglow のコードが、公開と同時にバグバウンティの土俵へ。

    50,000 SOL 2026.08.05 → 08.19 · 16:00 UTC 終了
    賞金プール最大 50,000 SOL。ただし1件あたりの上限は 25,000 SOL で、全額が動くのは資金喪失が実証された場合だけです。
    応募の作法1件につき 0.5 SOL をバーンしてから提出します。返ってきません。指定のポータル以外からの報告は対象外です。
    結果はいつすぐには出てきません。報告は非公開の Security Advisory として扱われ、しかも「公に開示した発見は報酬の対象外」とルールに明記されています。だから研究者の側にも黙っている動機があります。修正が出たあとに公開されるのが通例なので、いずれ分かる可能性はあります。いま何も出てこないことは、何も見つからなかったことを意味しません。

    03 とのつながり

    スロットタイムの短縮と Alpenglow は、どちらが先に来るかで意味が変わります。Alpenglow より先に 200ms へ届くと、バリデータは倍の頻度で投票することになり、投票コストが約2倍になり得ます。Alpenglow はその投票トランザクションそのものをなくすので、順番が入れ替われば話は変わります。