簡潔な回答： いいえ。2026年11月5日にライブ発表されたBaseのDenimアップグレードにより、チェーンは200ミリ秒ごとに完全な正準ブロックを生成するようになりました。これはブロック生成間隔であり、Ethereum上の取引が200ミリ秒で最終確定するという約束ではなく、出金が他チェーンで即時に使えるようになることでもありません。送金については、Base上での最初の包含（inclusion）、その後のsafe状態・確定状態、そしてブリッジ独自の完了プロセスを区別してください。
Denimは何を変えたのですか？
BaseのDenim発表によると、このアップグレードは2秒周期のブロックを置き換え、1秒あたり5つの完全な正準ブロックを生成するようにしました。また、より低速なブロック間に保留状態のプレビューを公開していた従来のFlashblocks方式も置き換えました。新しい設計では、ネットワーク自体が200ミリ秒ごとに完全なブロックを生成します。これは、より頻繁な状態更新やミリ秒単位の時間情報を必要とするアプリケーションにとって重要です。
見出しの数字は周期（cadence）を表しています。トランザクションが適切なタイミングでシーケンサーに到達し受理されれば、次のブロック機会はすぐに訪れます。しかしユーザー体験には、ブロック生成以外の多くのステップが含まれます：ウォレット送信、ネットワーク転送、シーケンサーによる順序付け、ノード同期、アプリケーショインデクシング、決済処理業者の方針などです。これらすべてが1つの間隔内に完了することが保証されているわけではありません。ブロックが頻繁に生成されていても、遅いウォレット接続や輻輳したアプリケーションによって遅延が発生する可能性があります。
発表では、ミリ秒精度でのコントラクトによる時刻アクセスや、B20送金チェックに関する変更にも触れられています。これらは開発者に関連しますが、一般ユーザーが自分のブリッジや取引所が入金確認ポリシーを変更したと推測すべきではありません。こうしたサービスは独自にしきい値を設定しており、L2の名目上のブロック間隔ではなく、資産や送金先に依存する場合もあります。
包含（inclusion）と最終確定（finality）の違いは何ですか？
包含とは、トランザクションがBaseブロックに表示されることを意味します。これは観察可能なマイルストーンです：ブロックエクスプローラーやノードが取引、そのステータス、ブロック参照を報告します。低リスクのインターフェースでは、更新された残高や保留中の支払い受領を表示するのに包含で十分な場合があります。ただし、それはシステム内で得られる最強の決済保証と同じではありません。
BaseはEthereumレイヤーツーネットワークです。そのプロトコルは、新しくシーケンスされたL2ブロック、入力データがEthereumから導出されたブロック、確定済みのEthereumデータに関連付けられたブロックを区別します。Base導出仕様書では、これらの状態にunsafe、safe、finalizedという用語を使用しています。これらの名称はL1データおよび最終確定性による裏付けの異なるレベルを表しており、同じ200ミリ秒のイベントに対する3つのラベルではありません。
unsafeなL2ブロックは、対応するデータが導出プロセスで説明される後続の保証を得る前であっても可視化されることがあります。safeブロックは、プロトコルのルールに従って正準L1データから導出されています。finalized L2ブロックは、確定済みL1データから導出されます。これらの詳細は、入金を不可逆的に計上できる時期を判断するオペレーターにとって重要ですが、消費者はよりシンプルなルールを使うことができます：「取引が見える」と「受取サービスがそれを確定とみなす」は別の記述です。
最終確定性は、製品ドキュメントによっても異なる意味を持つことがあります。ウォレットはローカルの取引レシート後に「確認済み」と表示するかもしれませんが、ブリッジは証明またはチャレンジプロセスを待ちます。コンテンツページは、「即時決済」を包括的な説明として使うのではなく、指し示す正確なイベントを明記すべきです。
Baseブロックが表示された後もEthereumが重要な理由
Baseはセキュリティとデータ可用性パスの一部をEthereumに依存しています。L2ブロックはEthereumブロックよりも高頻度で生成されますが、それらを再現可能にするデータや最終状態を決定するプロセスにはL1が関与します。導出仕様書は、BaseがL1データと最終確定シグナルを使ってL2のsafeヘッドとfinalizedヘッドを更新する方法を説明しています。高速なL2ブロックはより多くの状態更新を生み出しますが、L1との関係をなくすものではありません。
この区別は、オペレーターがどの程度のリオーガニゼーションや巻き戻しリスクを受け入れるかを決定する際に重要です。ゲームは、待機の koszt が高く露出が限定的であるため、最初の包含後に少額のゲーム内アイテムを付与する場合があります。大口の入金を処理する取引所は、追加の保証を待つかもしれません。どちらの方針も基盤となるプロトコルを変えるものではなく、受取サービスによる異なるリスク選択を表しています。
セキュリティに関する主張においても重要です。ブロック頻度の増加だけでは、チェーンがより分散化した証拠や、不正証明がより速く完了する証拠にはなりません。そうした特性は、個別のプロトコルおよび運用メカニズムに依存します。Denimに関する記事は、リリースが文書化している内容、すなわちブロック周期の変更と開発者向け機能に留まるべきです。
200msブロックはEthereumへの出金を高速化しますか？
必ずしもそうではありません。ロールアップからEthereumへの出金は、L2ブロックへの包含とは異なるブリッジプロセスに従います。トランザクションはBase上に素早く表示される可能性がありますが、Ethereum上での効果の証明や確定にはより長い時間がかかります。Baseプロトコルドキュメントは、確定済みのL2入力と、オプティミスティックロールアップの出力または出金プロセスの完了を明確に区別しています。非公式な議論ではどちらも「確定済み」と呼ばれることがあり、正確な表現が重要になります。
ユーザーは特定のブリッジの説明を確認すべきです：どのネットワークが資産を受領するか、ルートがネイティブか流動性サービス経由か、適用される手数料はいくらか、表示される完了見積もりが何を意味するかです。高速な流動性ブリッジは、ネイティブパスの完了前に受取人に支払う場合がありますが、その場合は流動性プロバイダーの容量と条件に依存することになります。これはネイティブプロセスを待つこととは異なるリスクです。
Denimの200ミリ秒という数値を出金見積もりにそのまま当てはめることはできません。チュートリアルでタイミングの期待値を示す場合は、最初のL2包含までの時間、safeまたはfinalized L2状態までの時間、Ethereum上で資金が利用可能になるまでの時間を個別に記載すべきです。サービスが現在の見積もりを公表していない場合、記事で勝手に作成してはいけません。
アプリケーションは送金をいつ計上するとどうやって決めるべきですか？
まず、アプリケーションが提供するものの価値と可逆性から検討します。低価値の表示状態をロールバックできるアプリケーションは、早期シグナルを使用する場合があります。資金や不可逆なデジタルアイテムを解放するものは、より強いしきい値を検討すべきです。この決定は、チェーンのブロック間隔から推測するのではなく、方針として文書化されるべきです。
次に、状態ソースを特定します。アプリはあるRPCプロバイダーから最新ブロックを読み取っていますか、自身のフルノード、インデクサー、ブリッジイベントを見ていますか？同期中には一時的にこれらが食い違うことがあります。新しい200ミリ秒周期により、インデクサーは1秒あたりより多くのブロックイベントを処理する必要が生じる場合があります。遅れると、UIはチェーンより遅く更新される可能性があります。開発者は、リリースの周期がエンドツーエンドの遅延と等しいと仮定するのではなく、アップグレード後に実際の経路をベンチマークすべきです。
最後に、例外処理を定義します。トランザクションが置き換えられた場合、ノードが利用できなくなった場合、クロスチェーンメッセージが遅延した場合はどうなりますか？明確なステートマシン——送信済み、包含済み、safe、確定済み、配達済み——は、サポートチームが保留中の送金を説明するのに役立ちます。また、ビジネスアクションが後続条件に依存しているにもかかわらず、ブロックを見た瞬間にインターフェースが「完了」と表示することを防ぎます。
ユーザーはブロックエクスプローラーで何を確認すべきですか？
まずネットワークを検証してください。Base上のトランザクションハッシュは、Baseのエクスプローラーまたは互換性のあるノードで確認すべきであり、他のチェーンにある類似名トークンページではありません。送信元、受取先、該当する場合はトークンコントラクト、ステータス、ブロック番号、金額を確認します。コントラクトインタラクションの場合は、上部の取引成功メッセージだけに頼るのではなく、イベントとトークン転送レコードを確認してください。成功した呼び出しには複数の転送が含まれていることがあります。
受取アプリが資金を計上していない場合は、表示されている入金ポリシーと取引の実際の状態を比較してください。アプリは自身の確認しきい値を待っている、サポート対象のトークンコントラクトを要求している、受け入れていないルート経由の入金を拒否しているなどの可能性があります。取引の後にBaseが多数のブロックを生成したという事実は、アプリがすべての必要なチェックを完了したことを証明しません。サポートへはシードフレーズではなく、ハッシュとネットワークを伝えて連絡してください。
最新の見えているブロックを、将来の混乱に対する約束と混同しないでください。エクスプローラーは有用な観測ツールですが、受取サービスの条件やプロトコルのセキュリティモデルを代替するものではありません。日付のある記事はステータスの確認方法を説明できますが、すべての送金に対して固定のミリ秒数を保証すべきではありません。
FAQ
DenimによりBase取引は200msで確定しましたか？
いいえ。Denimは正準L2ブロックを200ミリ秒ごとに到着するようにしました。それらのいずれかのブロックへの包含は、L1由来のsafe状態や確定状態よりも早いマイルストーンであり、ブリッジの完了は別プロセスです。
Flashblocksは今も200ms更新のソースですか？
Denimリリースでは、ネイティブの200ミリ秒ブロックが従来のFlashblocksプレビューモデルを置き換えるとされています。開発者はアップグレード後のドキュメントを使用し、アプリケーションに古いAPI前提が残っていないか確認すべきです。
ウォレットが成功を表示しているのに預入が保留になるのはなぜですか？
ウォレットはBase上での正常な包含を報告している可能性があり、一方で受取サービスは別のセキュリティ状態を待つか、独自システムを通じて入金を処理しています。トランザクションハッシュ、ネットワーク、サポート対象トークン、サービスの入金ポリシーを確認してください。
ブロック生成の高速化で手数料はすべて下がりますか？
いいえ。手数料はネットワーク価格、トランザクションの複雑さ、サービス料金に依存します。Denim発表のブロック周期は手数料表ではありません。使用している取引とアプリケーションの実コストを比較してください。
