BNB Smart Chain「Jenner」とは？3つの主要変更とテストネット対応を解説

BNB Smart Chain（BSC）の「Jenner」は、決済取引向けの専用枠、統制機能を備えたネイティブ資産規格、ミリ秒単位のブロック時刻などをまとめて導入するハードフォークです。結論からいうと、一般利用者が10月25日時点で資産を移す必要はありません。一方、Chapelテストネットのノード、MEV基盤、RPCシミュレーション、ウォレットやインデクサーを扱う担当者は、対応版への更新と互換性テストが必要です。

この記事では、2026年10月25日に公式資料と対応クライアントを照合した結果を基に、3つの変更とChapelでの対応を整理します。メインネットの正確な日時とCAS20の利用開始条件は未確定です。

変更	主な影響	対応が必要な人
Payment Lane	ブロックガス上限の既定5％を適格な決済向けに予約	ノード、バリデータ、MEVビルダー、決済サービス
CAS20	役割とポリシーを持つネイティブ資産規格を追加	開発者、ウォレット、インデクサー、発行者
ミリ秒時刻	0x70プリコンパイルから細かなブロック時刻を取得	時間依存のコントラクト開発者、RPC担当

Jennerは複数の仕様をまとめて有効化するハードフォーク

\n

ハードフォークとは、ブロックチェーンでブロックを正しいと判定する規則に互換性のない変更を加え、決められた時点から参加ノードが新しい規則を使う更新です。Jennerは一つの機能名ではなく、複数のBNB Evolution Proposal（BEP）を同時に反映する「メタ」アップグレードとして整理されています。代表的な変更はBEP-703のPayment Lane、BEP-702のCAS20、BEP-706のミリ秒時刻です。さらにクライアントのリリースには、ビルダー提案ブロックの堅牢化など周辺変更も含まれます。

Jennerに含まれる主要な変更

Payment Laneは、適格な決済取引が使えるブロックガス枠を確保する仕組みです。CAS20は、発行や焼却、差押えなどの権限を分離し、ポリシーを資産レベルで扱えるネイティブ規格です。ミリ秒時刻は、従来より細かなブロック時刻を必要とするコントラクト向けに新しい取得経路を加えます。この三つは同じフォークに含まれますが、目的も利用者も異なります。

「Jenner対応済み」という表現だけでは、どこまで準備できているかは分かりません。ノードが新しい合意規則を検証できること、ブロックビルダーが決済枠を正しく構成できること、RPCツールが変更後の入力を送れること、ウォレットがCAS20残高を正しく表示できることは別々の課題です。担当システムごとに影響を切り分ける必要があります。

テストネットは10月28日予定、メインネット日時は未確定

公式ブログは、JennerをChapelテストネットで2026年10月28日に予定していると案内しています。公式ドキュメントはメインネットについて11月下旬を目安に挙げていますが、2026年10月25日時点で正確な日時は公表されていません。「テストネットの日程が決まった」ことと「メインネットの実施日時が確定した」ことを混同しないでください。

対象：一般利用者　Chapelは、普段使うメインネットそのものではありません。テストネットでの更新は、開発者や運用者が新仕様を試し、問題を見つけるための段階です。取引所やウォレットから正式な案内がないのに、秘密鍵やシードフレーズの入力、トークンの交換、資産の「移行」を求める情報には応じないでください。

公式告知とリリースノートの日付をどう読むか

公式ブログはChapelでの予定日を「2026年10月28日」と案内する一方、Geth系・Reth系のタグ付きリリースは有効化時刻を「2026年10月29日02:30 UTC」、日本時間では同日11:30と記載しています。10月28日のタイムゾーンや基準時刻は資料から特定できず、単純な時差換算では一致しません。したがって現時点では資料間の不一致として扱います。運用者は広報上の日付ではなく、利用クライアントのタグ付きリリースにあるUTCの有効化時刻を更新期限・監視計画の基準とし、直前の公式告知で再確認してください。

変更1 Payment Lane：決済取引向けにブロックガス枠を確保する

\n

対象：ノード・MEV・決済サービス担当　ブロックに収められる処理量は、ガスという単位で上限が管理されます。混雑時には高い手数料を提示する取引などが先に選ばれ、日常的な決済が他の用途と競合します。BEP-703のPayment Laneは、各ブロックのガス上限の一部を適格な決済取引に予約し、一般取引だけで枠が埋まることを防ぐ設計です。

決済向け予約枠の仕組みと対象条件

対象になるのは、単に送金らしく見えるすべての取引ではありません。仕様で定められた分類条件を満たし、対象コントラクトがガバナンスで管理される一覧に登録される必要があります。ブロックを作る側は候補取引を分類し、予約枠と一般枠を考慮して組み立てます。検証側も同じ計算を再現できなければなりません。

このためPayment Laneは、ウォレット画面に「決済」と表示するだけの機能ではありません。Geth系とReth系のクライアント、バリデータ、MEVビルダーが同じ規則でブロックを生成・検証する必要があります。適格性の判定や枠計算に実装差があれば、ブロックの受理可否に関わるため、複数クライアント間のテストが重要です。

既定5％・最大10％の意味

\n

BEP-703は、ブロックガスの既定5％をPayment Lane向けに予約し、ガバナンスで最大10％まで設定できる枠組みを示しています。これは全取引の5％が決済になるという意味でも、決済件数が5％増えるという意味でもありません。ガス上限に対する割合なので、実際の取引件数は各取引が消費するガス量で変わります。

予約枠が使われなかった場合、一般取引がその未使用分を使えない点にも注意が必要です。混雑していない時間帯には違いが見えにくくても、一般取引が多い局面では、全体の利用可能枠が実質的に狭くなる可能性があります。設定値は処理能力そのものを増やす数字ではなく、限られたブロック空間を用途別に配分するルールです。

収録成功や手数料上限を保証する機能ではない

適格な決済取引であっても、予約枠に入り切らない、取引が無効、nonceが不整合、残高が不足、提示手数料が条件に合わないといった理由で収録されないことがあります。Payment Laneは優先的に利用できる容量を設けますが、各取引の即時確定や一定時間内の収録を約束しません。

手数料についても上限を固定する機能ではありません。利用者はウォレットが示す推定値を確認し、送信後はトランザクションハッシュで状態を追います。決済サービス側は「専用枠があるから失敗しない」と表示せず、保留、再送、期限切れを含む通常の例外処理を維持する必要があります。

変更2 CAS20：役割分担とポリシーを組み込む資産規格

対象：開発者・発行者・ウォレット／インデクサー担当　CAS20はCompliant Asset Standardの略で、BSCクライアントに組み込まれる状態付きプリコンパイルを使ってスマートコントラクトから資産を扱う設計です。一般的なBEP-20トークンと似た呼び出し面を持たせながら、発行、焼却、移転制限などの統制機能をプロトコル側で提供します。ただし「compliant」という名称だけで、特定国の法令に適合すると判断してはいけません。

AssetとStablecoinの2系統

仕様はCAS20 AssetとCAS20 Stablecoinという二つの系統を想定します。Assetでは表示上の数量を調整する倍率が論点になります。Stablecoinでは、許可リストやブロックリストなど、移転ポリシーを適用する用途が想定されています。どちらも名称だけで価値の安定や裏付け資産の存在を証明するわけではありません。

利用者が確認すべきなのは、規格名ではなく発行主体、資産の条件、償還方法、管理権限、監査や開示です。「Stablecoin型だから常に1単位の法定通貨と交換できる」「Asset型だから証券として適法」といった結論は仕様からは導けません。技術的な表現と、契約上・法令上の性質は分けて評価します。

発行・焼却・差押えを分ける権限設計

CAS20では、資産を増やす発行、減らす焼却、特定残高を扱う差押え、ポリシーを管理する役割などを分離できます。一つの秘密鍵へすべての権限を集中させず、職務ごとに担当アドレスを分けられる点が特徴です。権限分離は監査可能性や運用統制に役立ちますが、設定を誤れば意図しない主体に強い操作権限を与える危険もあります。

導入側は、各ロールが「何をできるか」だけでなく、「誰が任命・変更できるか」「鍵を失った場合にどうするか」「操作履歴を誰が監視するか」を文書化する必要があります。マルチシグ、鍵の保管、承認手順、緊急時の連絡経路はCAS20が自動で用意するものではなく、発行者側の運用設計です。

allowlistやpauseは法令適合を自動保証しない

allowlistは許可されたアドレスに利用を限定する考え方、blocklistは特定アドレスを制限する考え方、pauseは対象操作を一時停止する考え方です。seizeのような差押え機能も含め、これらはルールを実行する技術的な道具です。どの条件で、どの法域の、どの手続きに基づき使うべきかまでは決めません。

法令適合には本人確認、制裁対応、利用規約、記録保存、通知、異議申立てなど、技術以外の要素も関わります。反対に、管理機能の存在は利用者にとって凍結や差押えのリスクにもなります。サービスは権限者と発動条件を明示し、利用者は中央管理的な機能があることを理解したうえで利用可否を判断すべきです。

Jenner導入後も別途有効化と表示対応が必要

JennerでCAS20の実装が利用可能なクライアントへ入っても、誰でも直ちにCAS20を作成できるとは限りません。公式案内は、作成機能に別途の有効化が必要だと説明しています。この切り分けは、ネットワーク更新日と新資産の提供開始日を同一視しないために重要です。

CAS20作成には統治による有効化が要る

CAS20の作成はActivationRegistryと管理者の仕組みによって制御され、参照実装では管理者変更がGovHubを介する形で扱われます。つまり、ハードフォークは必要な実行環境を入れる段階であり、統治が任命した管理者による有効化が次の段階です。公式ブログも具体的な利用可能時期は別途案内される趣旨を示しています。

開発者は、フォーク時刻を過ぎただけで作成呼び出しが成功すると仮定してはいけません。対象ネットワークのレジストリ状態、管理者、機能フラグ、利用するクライアント版を確認し、失敗時の戻り値も扱います。一般利用者は「Jenner完了」を名目にCAS20への交換を急がせる非公式案内を警戒してください。

倍率対応でウォレットやインデクサーに生じる課題

raw残高とはチェーンが保持する変換前の整数値です。CAS20 Assetの倍率は、このraw残高と利用者へ見せる表示値を分ける要因になります。ウォレットやブロックエクスプローラーが倍率を反映しなければ、保有数量、移転履歴、法定通貨換算を誤って表示する可能性があります。Blockbook側でもJenner後の倍率対応が課題として報告されています。

対応では、残高取得だけでなく、入出金額、履歴、通知、CSV出力、会計連携、価格との掛け合わせまで確認します。raw値を保存する層と表示用に変換する層を明確に分け、二重に倍率を掛けないテストも必要です。異なる倍率や倍率変更を扱う場合は、過去履歴の表示方針も決めなければなりません。

確定リリースのログ挙動をテストする

仕様書は実装の基準ですが、アプリが実際に受け取るログの順序や呼び出し主体は、実装レビューで調整される場合があります。CAS20の実装では、作成ログの順序や初期化時の呼び出し主体を修正する変更が確認されています。インデクサーを仕様書の例だけに合わせると、確定版のイベント処理で取りこぼすおそれがあります。

Chapelでは、作成、発行、移転、焼却、停止、解除、権限変更を一連のシナリオとして実行し、トランザクションレシートとログを保存します。Geth系とReth系の結果を比較し、イベントを識別・索引するtopicと、値を格納するdata、その順序、失敗時のログ有無を確認します。確定したリリースを基準にし、古い開発版の観察結果を本番仕様として固定しないことが大切です。

変更3 ミリ秒時刻：新プリコンパイルで取得する

対象：スマートコントラクト開発者・RPC担当　BEP-706は、コントラクトがブロック時刻をミリ秒精度で取得するためのプリコンパイルを追加します。プリコンパイルとは、よく使う処理をEVM上の特別なアドレスから呼び出せるようにした仕組みです。Jennerではアドレス0x70を呼び出し、新しい時刻値を明示的に受け取ります。

0x70からミリ秒精度のブロック時刻を取得

短いブロック間隔では、秒だけの値だと複数ブロックが同じ秒に含まれ、細かな順序や期間計算で情報が足りない場面があります。BSCでは先行仕様により、秒単位のHeader.Timeを維持しつつ、ミリ秒成分をヘッダー内の別領域へ保存する方式が導入されています。BEP-706は、その値をコントラクトから使いやすく取得する経路を提供します。

新規コントラクトが高精度を必要とする場合は、0x70の呼び出し結果を検証し、Jenner前や未対応ネットワークでの動作も設計します。チェーンIDだけでなくフォーク有効化状態を考慮し、呼び出しに失敗したときの扱いを決めます。単位が秒かミリ秒かを型名や変数名で明示し、1000倍の取り違えを防ぎます。

block.timestampは秒単位のまま

重要なのは、Solidityのblock.timestampが自動的にミリ秒へ変わるわけではない点です。従来どおり秒単位の値が残るため、既存コントラクトが突然1000倍の時刻を受け取る互換性問題は避けられます。ミリ秒が必要なコントラクトだけが、新しいプリコンパイルを明示的に呼びます。

既存コードでblock.timestampを1000倍しても、見かけ上の単位がミリ秒になるだけで精度は増えません。同じ秒にあるブロックは同じ元値を共有します。真のミリ秒成分が必要なら0x70を使い、秒単位で足りるタイムロックや期限判定は従来の仕組みを維持する、という使い分けができます。

高精度でも外部時計や公平な締切は保証しない

精度が細かくなることと、時刻が絶対に正しいことは別です。値はブロック生成過程で与えられるため、信頼できる外部時刻認証や現実世界の厳密な時計を提供するものではありません。ミリ秒単位のオークション締切を設定しても、ネットワーク遅延や取引選択の影響が消えるわけではありません。

公平性が重要な処理では、単一の時刻比較だけに依存せず、十分な受付期間、ブロック番号、コミット・リビール、異議申立てなどを検討します。BEP-706は観測できる粒度を改善する仕様であり、順序の公平性や取引の到着時刻を証明する仕組みではありません。

担当別のテストネット対応

\n

\n

Chapelに参加する運用者は、利用中のクライアント系列と役割を先に棚卸しします。公式リリースではGeth系BSCクライアントv1.8.1、Reth系reth-bsc v0.1.3がJenner対応版として示されています。バイナリ名だけで判断せず、実行中プロセスのバージョン、起動引数、接続先ネットワークを記録してください。

Geth系はv1.8.1、Reth系はv0.1.3を確認

Geth系の案内は、Chapelのノード、MEVビルダー、sentry運用者にv1.8.1への更新を求めています。Reth系もv0.1.3を必須更新として案内し、有効化時刻やRPC互換変更を記載しています。異なる系列の版番号は対応関係を直接示さないため、「数字が新しい方」を選ぶのではなく、自分のクライアントの正式リリースを使います。

更新前にはデータディレクトリ、設定、サービス定義、監視、ロールバック条件を確認します。ただし、フォーク有効化後に旧版へ戻すと新規則を検証できないため、単純なバイナリ差し戻しを安全策と考えるべきではありません。まずChapelやステージング環境で起動、同期、ピア接続、RPC、ブロック追随を検証します。

ノード・MEVビルダー・sentryの更新範囲

更新対象はバリデータだけとは限りません。MEVビルダーは取引の並びや収益機会を考慮してブロック候補を組み立てるソフトウェア、sentryはバリデータの前段で外部ピアとの通信を受ける防御用ノードです。アーカイブやインデックス用途のノードも新しいブロックを処理します。BEP-675関連では、ビルダーが提案するブロックを表すBidBlockの経路や不正形式を拒否する堅牢化も含まれるため、周辺コンポーネントとの接続を通して確認します。

構成図を基に、各ホストのバイナリ、API、認証、許可リスト、フェイルオーバー先を洗い出します。一部だけ旧版が残ると、監視用ノードが停止したり、ビルダー経路だけ失敗したりする可能性があります。更新後はプロセスが起動したことだけで完了とせず、フォーク後ブロックの検証、ピア数、再編成、エラー率を監視します。

blockOverrides.prevRandaoの入力変更をChapelで検証

Reth v0.1.3の案内では、一部RPCで使うblockOverrides.prevRandaoに、0〜999のミリ秒剰余を32バイト値として渡す変更が示されています。blockOverridesは、トランザクションを実際に送信せず、仮想的なブロック条件で実行を試す際に使われます。古い形式を固定しているテストツールは更新後に失敗する可能性があります。

影響候補にはガス推定、バンドルシミュレーション、MEV探索、デバッグ、CIの固定テストがあります。入力の範囲、32バイトへのエンコード、ゼロ値と境界値999、範囲外の拒否をChapelで試します。Geth系とReth系の双方へ同じ要求を投げる場合は、サポート状況と応答差を記録し、クライアント固有処理を分けます。

公開前チェックリストと未確定事項

以下は担当別の完了条件です。成功例だけでなく、権限不足、範囲外入力、未対応環境などが期待どおり拒否されることも確認し、使用バージョン、チェーン高、エラー、ログを証跡として残します。

担当	更新対象	Chapelで試す項目	合格条件	本番前の再確認
ノード	Geth系v1.8.1／Reth系v0.1.3、接続ノード	起動、同期、ピア接続、フォーク後ブロック追随	同じ正規チェーンを継続し、異常な再編成やエラー増加がない	確定版、UTC有効化時刻、フォーク設定
MEVビルダー	ビルダーとsentry	Payment Laneの対象・非対象・満杯時、BidBlock、旧経路への切替	枠計算がクライアント間で一致し、不正提案を拒否できる	許可リスト、API、BEP-675関連の確定実装
RPC	シミュレーター、ガス推定、CI	prevRandaoの0・999・範囲外、32バイト形式	境界値を正しく処理し、不正形式を想定どおり拒否する	クライアント別対応と応答差
開発者	CAS20連携、0x70利用コード	権限別の成功・失敗、Jenner前後、秒とミリ秒	単位誤りがなく、未対応時の処理が定義済み	CAS20の有効化条件と対象アドレス
ウォレット／インデクサー	残高、履歴、通知、CSV、会計連携	倍率、topic・data・ログ順序、権限変更	raw値と表示値を二重変換せず、イベントを欠落なく索引する	確定リリースのログ仕様

テスト結果を判断できる形で残す

チェックリストは項目へ印を付けるだけでなく、誰が同じ条件で再現しても同じ結論になる証跡と結び付けます。ノードなら実行中の版、起動引数、対象チェーン、フォーク前後のブロック高、同期状態、ピア数を記録します。MEV経路ならPayment Laneの対象取引と非対象取引を同じ条件で投入し、予約枠が余った場合と上限へ達した場合のブロック内容を比較します。RPCでは要求本文と応答、エラーコードを保存し、整数の0〜999と32バイト表現を混同していないかを確認します。

CAS20では作成、発行、移転、焼却、停止、解除、権限変更を一連のシナリオにし、操作主体、レシート、topic、data、raw残高、表示残高を対応付けます。権限のない操作や停止中の操作が拒否された結果も合格判定へ含めます。0x70ではJenner有効化前と後、秒単位のblock.timestampとミリ秒値を並べ、単位変換を二重にしていないかを確かめます。ウォレットやインデクサーは画面だけでなく、履歴、通知、CSV、会計連携まで同じ入力で追跡します。

環境差を事故へつなげないため、Chapelの合格結果にはチェーンID、エンドポイント、使用したテストアカウント、確認時刻を添えます。本番手順では値をそのまま複製せず、本番用の接続先、権限、監視先へ置き換わったことを別担当者が照合します。日程が変わった場合に古い予定時刻の自動処理が残らないこと、異常時の停止条件と連絡先が明確であることも完了条件です。これにより「対応版を起動できた」という途中状態と、「サービス境界まで互換性を確認した」という完了状態を区別できます。

採用する情報の優先順位

2026年10月25日時点で関連BEP群には一覧上Draft表記を含むものがあります。仕様の意図はBEP、実際に配布される挙動はタグ付きクライアントリリース、日程はBNB Chain公式告知で確認します。設定値や実装が食い違う場合はタグ付きリリースをテストし、日程は直前の公式告知と照合します。SNSや二次報道は更新を知る入口にとどめ、版番号や時刻の根拠にはしません。

未確定のまま残る項目

メインネットは11月下旬が目安ですが、正確な日時は未発表です。CAS20の作成機能も別途有効化が必要です。運用者は確定時刻、対応クライアント版、CAS20の有効化条件を直前に確認し、Chapelの設定をそのまま本番へコピーせず、チェーンID、ブートノード、エンドポイント、権限、監視先を再点検します。一般利用者は利用中の取引所やウォレットの入出金案内を確認し、秘密鍵や資産交換を求める非公式な「アップグレード」案内を避けてください。

Jennerの要点は、Payment Lane、CAS20、ミリ秒時刻という三つの変更を、担当ごとに分けて検証することです。技術更新は価格上昇を保証する材料ではなく、本記事も暗号資産の売買を勧めるものではありません。