エポックスケジュール

エポックスケジュールとは？

エポックスケジュールとは、ブロックチェーンの時間をエポックと、スロットと呼ばれる小さな単位に分割するルールです。スロットをどのようにまとめるか、各エポックがいつ終了し、次のエポックがいつ始まるか、エポックに基づくネットワークイベントがいつ発生するかを定めます。ブロックチェーンによって異なりますが、こうしたイベントには、バリデーターの割り当て、リーダーの交代、ステーキングの更新、報酬計算、ガバナンスのスナップショット、プロトコルアップグレード、コンセンサスパラメーターの変更などが含まれます。エポックスケジュールは通常、一般的な暦日ではなく、プロトコル上の時間で表されます。たとえば、各エポックが必ず2日間続くと定めるのではなく、1エポックを一定数のスロットとして定義するネットワークがあります。スロット生成の速度が目標より速い、または遅い場合、実際の所要時間は推定と異なる可能性があります。この用語は、エポック制を採用するあらゆるブロックチェーンの一般的な時間構造を指す場合があります。Solanaではより具体的な意味を持ち、スロットをエポックに対応させ、リーダースケジュールを調整するために使用されるクラスターのパラメーターを指します。

エポックとは？

エポックとは、連続するブロックチェーンスロットをまとめた単位です。Proof of Stakeネットワークでは、バリデーターの活動を管理しやすい期間に整理するためにエポックが使われます。各トランザクションのたびにネットワークの責務をすべて再計算するのではなく、プロトコルは予測可能なエポック境界で特定の更新を適用できます。エポックは、バリデーターの参加状況の測定、ステーキング報酬の計算、委任状態の変更、委員会の交代、プロトコルルールの有効化などに共通の基準期間を提供します。エポック番号は通常、ブロックチェーンの開始時点から増加します。ただし、エポック番号は各ネットワーク内でのみ意味を持ちます。あるブロックチェーンのエポック500は、別のブロックチェーンのエポック500とは関係ありません。

スロットとは？

スロットとは、バリデーターがブロック生成やその他のコンセンサス上の役割を担うことを期待される、または許可される、プロトコルで定義された短い機会です。複数のスロットがまとまって1つのエポックを構成します。ブロックが生成されないままスロットが経過する場合があります。選出されたバリデーターがオフラインである、ブロックの到着が遅れる、ネットワークがブロックを拒否する、またはコンセンサス設計上すべてのスロットにブロックが必要ではない場合などに起こり得ます。そのため、スロット番号とブロック番号は必ずしも一致しません。アプリケーションは、すべてのスロットが1つのブロックに対応すると仮定してはいけません。

エポックスケジュールとエポック番号の違い

エポック番号は、ブロックチェーンの履歴における特定のエポックを識別します。エポックスケジュールは、その番号の計算方法とエポックの境界を定めるルールを示します。たとえば、各エポックのスロット数や、初期のエポックの長さが異なるかどうかを定めます。現在のエポックを照会すると、ネットワークが現在どの位置にあるかが分かります。エポックスケジュールを照会すると、ネットワークのエポック構造が分かります。

エポックスケジュールが重要な理由

エポックスケジュールは、時間に依存するブロックチェーン活動に予測可能な枠組みを提供します。バリデーターは、今後のブロック生成や投票の役割に備えられます。ステーカーは、委任の変更や報酬計算がいつ反映されるかを推定できます。ウォレットはエポック境界までの進捗を表示できます。監視システムは、一貫した期間におけるバリデーターのパフォーマンスを測定できます。開発者は、エポック番号やスロット範囲に依存する操作をスケジュールできます。プロトコル開発者は、不確実な実時間のタイムスタンプに依存せず、明確に定められた境界で一部のアップグレードを有効化できます。

エポックスケジュールの定義方法

エポックスケジュールには通常、1エポック当たりのスロット数と、絶対スロット番号をエポック番号に対応させる方法が含まれます。初期のエポックが通常より短いウォームアップ期間を定めるスケジュールもあります。バリデーターのリーダーシップや委員会の割り当てを、どの程度前に計算するかを定める場合もあります。通常の完全なエポック長を使用する最初のエポックとスロットを含むこともあります。これらのパラメーターは、対象のブロックチェーンのルールに従って解釈する必要があります。同じフィールド名でも、コンセンサスシステムによって実際の動作上の意味が異なる場合があります。

固定エポック長と可変エポック長

固定長エポックでは、起動時やウォームアップ期間を終えると、毎回同じ数のスロットが含まれます。可変長スケジュールでは、プロトコルのルール、ネットワークの段階、初期の立ち上げ設計に応じてスロット数が変化することがあります。スロット数が固定されていても、実時間での所要時間が完全に一定とは限りません。目標スロット時間を定めたブロックチェーンでも、ネットワーク状況やバリデーターのパフォーマンスによって時間差が生じる可能性があります。そのためアプリケーションは、エポック内のスロット数と、分・時間・日単位の推定所要時間を区別してください。

エポック境界

エポック境界とは、あるエポックの最終スロットから次のエポックの最初のスロットへ移行する時点です。プロトコルでは、コンセンサス関連の変更に向けた同期ポイントとして境界が使われることがよくあります。バリデーターセット、ステーク分布、報酬状態、リーダースケジュールは、境界時またはその前後に更新される場合があります。エポック移行に依存するアプリケーションは、ローカルのカウントダウンだけに頼らず、オンチェーンデータを利用してください。境界付近では、ネットワーク遅延やRPCのコミットメントの違いにより、データプロバイダーごとに現在の位置がわずかに異なることがあります。

Solanaのエポックスケジュール

Solanaでは、リーダースケジュールが有効となるスロット数が1エポックです。

Solana公式用語ガイドでは、スロットとリーダースケジュールとの関係に基づいてエポックが定義されています。

Solanaは、クラスターのエポックスケジュールパラメーターを返すRPCメソッド

を提供しています。

getEpochSchedule公式ドキュメントには、5つの応答フィールドが記載されています。

フィールドは

、、、、です。

このメソッドにリクエストパラメーターは不要です。すべてのSolanaネットワークで同じスケジュール値が使われると仮定せず、対象のクラスターを照会してください。

slotsPerEpoch

フィールドは、通常の長さのエポックに含まれる最大スロット数を示します。

ウォームアップ期間後のエポック境界を計算するうえで、重要な値です。クラスターでウォームアップエポックが使われない場合、最初のエポックから通常の長さが適用されます。ウォームアップが有効な場合、通常の完全な長さに達するまで、初期のエポックのスロット数が少なくなることがあります。このフィールドが示すのはスロット数であり、ブロック数が保証されているわけではありません。ブロックが生成されずに経過するスロットもあります。

leaderScheduleSlotOffset

フィールドは、該当エポックのリーダースケジュールがエポック境界のどれくらい前に決定されるかを示します。

リーダースケジュールは、ブロック生成を担当する予定のスロットにバリデーターを割り当てます。スケジュールを事前に決定することで、バリデーターは割り当てられたスロットに備えられます。特定のクラスターで両方のフィールドが同じ値であっても、このオフセットをエポック内のスロット数と混同してはいけません。

warmup

フィールドは、初期のエポックが短い状態から始まり、通常のエポック長に向けて増加するかどうかを示すBoolean値です。

は、スケジュールにこの立ち上げ時の動作が含まれることを示します。

は、クラスターが増加式のウォームアップ期間を使用しないことを示します。

ウォームアップパラメーターは、主にネットワークの初期履歴に影響します。過去のエポック境界を計算するアプリケーションは、すべての初期エポックに通常の長さを適用せず、ウォームアップのルールを考慮してください。

firstNormalEpoch

フィールドは、通常の完全なスロット数を使用する最初のエポックを示します。

が有効な場合、特に重要なフィールドです。

この時点より前のエポックは、長さが段階的に異なる場合があります。履歴を計算するソフトウェアは、それぞれの過去のエポックから固定数のスロットを引くのではなく、スケジュールのウォームアップルールを使用してください。

firstNormalSlot

フィールドは、最初の通常長エポックが始まる絶対スロットを示します。

後続のスロット番号を通常のエポックに対応させる基準となります。

とを組み合わせることで、ウォームアップ期間と通常期間を区別できます。

これらのフィールドを使うと、アプリケーションは過去のエポック計算の誤りを避けられます。

SolanaのEpoch Schedule sysvar

Solanaプログラムは、一般にsysvarと呼ばれるEpochScheduleシステム変数を通じてエポックスケジュール情報にアクセスできます。sysvarは、オンチェーンプログラムが実行時に読み取れる、ネットワークが管理する情報を提供します。

Solana公式syscallリファレンスには、EpochSchedule sysvarをプログラムメモリに読み込むsyscallが含まれています。

これにより、オンチェーンプログラムはオフチェーンのウェブサイトに依存せずに、エポックとスロットの関係を計算できます。スケジュールはスロットで表されるため、プログラムは実時間について不要な仮定を置かないようにしてください。

getEpochScheduleとgetEpochInfoの違い

は、クラスターのエポックシステムを定義する構造パラメーターを返します。

は、ノードの現在のエポック位置と関連するカウンターを返します。

getEpochInfo公式ドキュメントには、現在のエポック、絶対スロット、スロットインデックス、現在のエポック内のスロット数、ブロック高、利用可能な場合はトランザクション数が記載されています。

フィールドは、エポック内の現在位置を示します。

フィールドは、そのエポックに含まれるスロット数を示します。

2つのメソッドを組み合わせると、スケジュールを把握し、現在の進捗を表示できます。

エポックスケジュールとリーダースケジュールの違い

エポックスケジュールは、スロットをエポックに分割する方法を定めます。リーダースケジュールは、エポック内の特定のスロットを担当するバリデーターを示します。両者は関連していますが、同じものではありません。

SolanaのgetLeaderScheduleメソッドは、選択したエポックのバリデーターIDと、相対的なリーダースロットのインデックスを返します。

監視アプリケーションは、エポックスケジュールで対象エポックを特定し、リーダースケジュールで想定されるブロック生成者を特定できます。

Solanaのエポックとステーキング報酬

Solanaでは、ステーキングに関する重要な情報の集計期間としてエポックが使われます。ネットワークはRPCシステムを通じて、エポックごとの報酬データを公開します。

getInflationRewardメソッドは、データが利用可能な場合、指定エポックについて付与されたステーキングまたは投票報酬の情報を返します。

エポックの報酬記録には、エポック番号、有効スロット、付与額、付与後残高、バリデーターのコミッション情報が含まれる場合があります。エポックに紐づく報酬記録を、固定額の支払いが保証されていると解釈してはいけません。実際のステーキング結果は、ネットワークルール、バリデーターのパフォーマンス、ステークの状態、コミッション、その他のプロトコル条件によって異なります。

Ethereumのエポックスケジュール

Ethereumも、Proof of Stakeのコンセンサスをスロットとエポックで管理しています。Ethereumでは現在、12秒のスロットを32個まとめて1エポックとしています。そのため、1エポックの予定時間は384秒、約6.4分です。

Ethereum公式Proof of Stakeドキュメントでは、各スロットで1人のバリデーターがブロック提案者に選ばれると説明されています。

バリデーターの委員会はアテステーションを提出し、通常、アクティブな各バリデーターは各エポック中にアテステーションの役割を担います。選出された提案者が受け入れられるブロックを公開しないと、スロットが空になることがあります。ブロックが欠落しても、スロットとエポックの時間軸は継続します。

Ethereumのエポックとファイナリティ

Ethereumは、Proof of Stakeのファイナリティプロセスの一部として、エポックチェックポイントを使用します。バリデーターはアテステーションを通じて、チェックポイント間の関係に投票します。通常のネットワーク状況では、十分なバリデーターの支持により、連続するエポックをまたいでチェックポイントが正当化され、ファイナライズされます。ファイナリティにより、重大なコンセンサス障害と大きな経済的影響がない限り、ブロックが取り除かれないと強い確信を持てます。エポック境界を迎えたからといって、直前のエポックのすべてのトランザクションが瞬時にファイナライズされるわけではありません。ファイナリティは、バリデーターの参加状況とプロトコルのチェックポイントルールによって決まります。

Ethereumのエポックとバリデーターの役割

Ethereumは、バリデーターの責務をスロットとエポックに割り当てています。通常、バリデーターは各エポックに1回アテステーションを行います。バリデーターは、ブロック提案者や同期委員会の参加者に選ばれることもあります。役割を適時に実行することが重要です。遅延や未実行は報酬の減少につながる可能性があります。

Ethereumの報酬とペナルティに関するガイドでは、適時のsource、target、headへの投票、ブロック提案、同期委員会への参加に対する報酬が説明されています。

バリデーター運用者は、エポックを大まかな期限として扱わず、スロットの時間を監視してください。

Cardanoのエポックスケジュール

CardanoのProof of Stakeコンセンサスも、時間をエポックとスロットに分割しています。

最新のCardanoノードドキュメントによると、1スロットは1秒、1エポックは432,000スロットです。

予定されるエポック時間は5日です。Cardanoのコンセンサス設計では、各スロットでブロック生成ノードが0個以上選出される場合があります。1秒ごとのすべてのスロットでブロックを生成する必要はありません。

Cardanoコンセンサスガイドでは、スロットをエポックにまとめることで、変化するステーク分布に基づくリーダー選出が可能になると説明されています。

ブロックチェーンによってエポックスケジュールは異なる

すべての暗号資産に共通するエポック期間はありません。Ethereumのエポックは数分ですが、ネットワークによっては数時間や数日単位です。エポックをファイナリティや委員会交代と密接に結び付けるネットワークもあります。一方で、主にリーダースケジュール、ステーキングの集計、委任の更新、報酬分配に使用するネットワークもあります。ウォレットやステーキングアプリケーションは、あるブロックチェーンのエポックに関する前提を別のブロックチェーンに適用してはいけません。対象プロトコルのドキュメントと稼働中のノードデータを信頼できる情報源として扱ってください。

エポックとバリデーターの選出

Proof of Stakeネットワークでは、ステーク情報を使って役割を担うバリデーターを決める場合があります。役割が有効になる前に、適格なバリデーターやステークのスナップショットを取得することがあります。これにより、参加者が有利な割り当てを知った後にステークを即座に変更することを防ぎやすくなります。エポックスケジュールは、スナップショット、割り当て計算、役割の実施期間を設定する時間的な枠組みになります。ステーク変更から役割の開始までの正確な時間は、ブロックチェーンによって異なります。

エポックとステーキングの有効化

委任された資産やステーキングされた資産は、トランザクションの承認直後に有効になるとは限りません。プロトコルによっては、次のエポックまで待つか、有効化キューを適用します。この遅延により、ネットワークはバリデーターとステークの記録を秩序立てて更新できます。アンステーキングにも、エポックの移行、退出キュー、クールダウン、出金待ち時間が必要な場合があります。ユーザーはトランザクションの承認と、ステーキングの有効化または出金可能になるタイミングを区別してください。ステーキングトランザクションがオンチェーンで確定していても、エポックに基づくルールによりステークが保留中のままの場合があります。

エポックと報酬計算

多くのProof of Stakeシステムでは、エポック単位で参加状況を測定し、報酬を計算します。ネットワークは期間中に、割り当てられた役割、成功した投票、ブロック生成、委任ステーク、ペナルティ、コミッションを集計できます。報酬はエポック境界で計算されても、後から付与される場合があります。自動的に報酬を分配するシステムもあれば、請求や更新操作が必要なシステムもあります。バリデーターのパフォーマンスやネットワーク状況は変化するため、エポック報酬の推定値は保証された利率ではありません。運用者の手数料、トークン価格の変動、税金、出金条件も考慮してください。

エポックとプロトコルアップグレード

エポック境界を、ブロックチェーンアップグレードの正確な有効化時点として利用できます。互換性のあるすべてのノードは、同じプロトコルスケジュールから有効化時点を判断できます。これは、ブロック生成間隔が変動するネットワークでブロック番号を使うより、予測しやすい場合があります。特定のエポックに適用されると発表されたアップグレードは、受け入れられたチェーンがそのエポックに到達すると有効になります。ノード運用者は有効化時点より前に、互換性のあるソフトウェアをインストールする必要があります。古いルールに従うクライアントは、有効化後に同期が停止したり、ネットワークから分岐したりする可能性があります。

エポックスケジュールとガバナンス

一部の暗号資産ガバナンスシステムでは、提案、投票、実行、委任の期間にエポックを使用します。投票権は、特定のエポックまたはスロットのスナップショット時点で測定される場合があります。提案は、暦上の固定期間ではなく、定められた数のエポックにわたって受け付けられることがあります。これにより、オンチェーンでガバナンスの時間を確認しやすくなります。ただし、エポック番号だけで示された期限を通常の暦時間に換算しにくい場合があるため、ユーザーはスケジュールを理解する必要があります。

エポックスケジュールは変更できますか？

エポックスケジュールを変更できるのは、ブロックチェーンのプロトコルとガバナンスプロセスが変更を認めている場合に限られます。ネットワーク作成時に固定されるスケジュールパラメーターもあります。プロトコルの協調アップグレードを通じて、スロット時間、エポック長、役割のルールを変更できるネットワークもあります。コンセンサスの不一致を避けるため、互換性のあるノードすべてに一貫して変更を実装する必要があります。権威あるAPIやシステム変数が提供されている場合、アプリケーションは時間に関する前提を恒久的にハードコードしないでください。

エポック終了時刻の推定

残りのスロット数とネットワークの目標スロット時間を組み合わせると、エポック終了までの時間を推定できます。基本的な推定値は、残りスロット数に1スロット当たりの目標時間を掛けて算出します。実際のスロットの進行が変動するネットワークでは、この計算はあくまで推定です。ブロックが欠落しても、ブロック生成の成功とは別にスロット番号が進むため、スロット番号が止まるとは限りません。カウントダウンは稼働中のノードデータで更新し、必要に応じて概算であることを明示してください。

エポック番号とブロック高の違い

エポック番号は、プロトコル上のスロットのまとまりを識別します。ブロック高は、チェーンの履歴における承認済みブロック数を示します。ブロックが生成されないスロットがあるため、両者の増加速度は異なる場合があります。また、1つのスロットに複数のブロック候補が生成されても、コンセンサスによって最終的に1つのチェーン履歴が受け入れられることがあります。1スロットにつき1ブロックという前提でブロック高をエポックに換算せず、用途に応じた正しい値を使ってください。

エポック番号とタイムスタンプの違い

エポック番号は、プロトコル固有の時間基準です。タイムスタンプは、暦上の時間を表します。ブロックチェーンはエポック境界に対応するタイムスタンプを推定できますが、その推定はスロット時間や受け入れられたチェーンに左右される場合があります。プロトコルがその関係を保証していない限り、スマートコントラクトは推定上のエポック終了時刻を、オフチェーンの厳密な予定時刻として扱わないでください。インターフェースでは、分かりやすさのためにエポック番号と推定される現地日付を併記できます。

エポックスケジュールデータとRPCの信頼性

公開RPCエンドポイントを使うとエポック情報に簡単にアクセスできますが、正確なデータを返すかどうかはそのエンドポイントを信頼することになります。利用不能、遅延、悪意あるエンドポイントは、古い状態や誤ったエポック情報を返す可能性があります。情報がセキュリティ上重要な場合、複数のノードを比較するか、独自ノードを運用できます。要求するデータに適したコミットメントまたはファイナリティの水準も選択してください。低いコミットメント水準で観測された値は、後から変更されるチェーン状態を反映している可能性があります。

スマートコントラクトでのエポックデータ利用

オンチェーンプログラムは、プロトコルが認めるエポックまたはクロック情報の取得元を使用する必要があります。検証せずに、ユーザーが提供した現在のエポックを信頼してはいけません。エポックに基づくルールでは、境界時点での動作を明確に定義してください。開発者は、あるエポックの最終スロットと次のエポックの最初のスロットをテストしてください。過去の計算を行うアプリケーションでは、初期のウォームアップエポックもテストする必要があります。1つずれた計算により、ステーキング、ガバナンス、報酬期間の開始や終了が1スロット早まったり遅れたりする可能性があります。

エポックに基づくロジックのセキュリティリスク

エポック計算の誤りは、報酬、投票、出金、アクセス制御の不具合につながる可能性があります。別のネットワークにデプロイしたコントラクトが誤ったスケジュールを使用する場合があります。アプリケーションがウォームアップ期間中に通常のエポック長を前提とする可能性もあります。ユーザーインターフェースが、古い推定値を使ってスロットを実時間に換算し、誤解を招く期限を表示する場合があります。リーダースケジュールの計算ミスにより、バリデーターが担当を逃す可能性があります。ガバナンスシステムが境界の誤りによって、意図した期間外の投票を受け付ける場合があります。エポックに依存するコードでは、整数安全な計算、権威あるネットワークデータ、境界条件を網羅するテストを使用してください。

開発者がエポックスケジュールを利用する方法

最初に、ネットワークのエポックが固定数または可変数のスロットで定義されているか確認します。次に、公式ノードAPIまたはシステムデータからスケジュールを取得します。3つ目に、該当する場合はウォームアップエポックと最初の通常エポックを考慮します。4つ目に、絶対スロット番号とエポック内のスロットインデックスを区別します。5つ目に、現在の進捗を表示する際は、リアルタイムのエポック情報を使います。6つ目に、プロトコルが正確な時間を提供していない限り、実時間での完了時刻は推定として扱います。7つ目に、エポック境界前後のすべての計算をテストします。8つ目に、関連ルールを変更する可能性のあるプロトコルアップグレードを監視します。

エポックスケジュール計算の例

仮想的なProof of Stakeブロックチェーンが、ウォームアップ期間後に1エポック当たり10,000スロットを使用するとします。通常エポックの最初がエポック5で、そのエポックの最初の絶対スロットが9,000であるとします。絶対スロット9,000から18,999まではエポック5に属します。絶対スロット19,000からエポック6が始まります。スロットインデックス0は、エポック内の最初のスロットを示します。スロットインデックス9,999は、通常エポックの最終スロットを示します。この例から、ソフトウェアには1エポック当たりのスロット数だけでなく、最初の通常スロットも必要だと分かります。数値は説明用であり、稼働中のブロックチェーンに適用してはいけません。

エポックスケジュールでよくある間違い

よくある間違いの1つは、すべてのブロックチェーンでエポックの期間が同じだと思い込むことです。もう1つは、スロット番号をブロック高と同じものとして扱うことです。3つ目は、すべてのスロットでブロックが生成されると思い込むことです。4つ目は、ウォームアップ期間中の初期エポックに通常のエポック長を適用することです。5つ目は、エポックスケジュールとバリデーターのリーダースケジュールを混同することです。6つ目は、推定上のエポック終了時刻を正確な保証として扱うことです。7つ目は、ステーキングトランザクションが承認後すぐに有効になると思い込むことです。8つ目は、接続先ネットワークを確認せずにスケジュール値をハードコードすることです。9つ目は、セキュリティ上重要なエポック計算を、未検証の単一RPCエンドポイントに依存することです。10個目は、エポック境界前後の最終スロットと最初のスロットをテストしないことです。

よくある質問

暗号資産におけるエポックスケジュールとは何ですか？

エポックスケジュールとは、スロットをエポックにまとめる方法と、各エポックの開始・終了時点を定めるブロックチェーンのルールです。

エポックとスロットの違いは何ですか？

スロットは短いコンセンサス上の時間単位で、エポックは連続する複数のスロットをまとめた単位です。

すべてのスロットにブロックが含まれますか？

いいえ。選出された生成者がオフライン、遅延、または生成に失敗した場合、受け入れられるブロックがないままスロットが経過することがあります。

すべてのブロックチェーンでエポックの長さは同じですか？

いいえ。エポック長とスロット時間は、各ブロックチェーンのプロトコルが個別に定めています。

SolanaのEpoch Scheduleとは何ですか？

スロットをエポックに対応させ、通常のエポック長、ウォームアップ動作、リーダースケジュールのタイミングに関するパラメーターを定めるクラスター構造です。

getEpochScheduleは何を返しますか？

、、、、を返します。

getEpochScheduleで現在のエポックが分かりますか？

いいえ。Solanaアプリケーションは

を使って、現在のエポックとエポック内の位置を取得します。

slotsPerEpochとは何ですか？

照会対象のクラスターで、通常長の各エポックに含まれる最大スロット数です。

ウォームアップエポックとは何ですか？

通常の完全なエポック長よりもスロット数が少ない、初期のエポックです。

firstNormalEpochとは何ですか？

通常の完全なスロット数を使用する最初のエポックを示します。

firstNormalSlotとは何ですか？

最初の通常長エポックが始まる絶対スロットを示します。

leaderScheduleSlotOffsetとは何ですか？

該当エポックのバリデーターリーダースケジュールが、エポック境界のどれくらい前に計算されるかを示します。

エポックスケジュールとリーダースケジュールは同じですか？

いいえ。エポックスケジュールはエポック境界を定め、リーダースケジュールはブロック生成スロットにバリデーターを割り当てます。

Ethereumのエポックはどのくらいの長さですか？

Ethereumでは現在、12秒のスロットを32個使用しているため、エポックの予定時間は約6.4分です。

Cardanoのエポックはどのくらいの長さですか？

現在のCardanoドキュメントでは、1秒のスロットを432,000個まとめて1エポックとしており、期間は5日に相当します。

すべてのスロットでブロックが生成されなくても、エポックは終了しますか？

はい。ブロックが受け入れられないスロットがあっても、スロットの進行は続く場合があります。

ステーキング報酬は各エポック境界で受け取れますか？

必ずしもそうではありません。報酬の計算、付与、請求、出金のルールはブロックチェーンプロトコルによって異なります。

ステーキングの有効化はエポックに依存しますか？

はい。多くのProof of Stakeシステムでは、エポック移行後、またはプロトコルで定められた遅延後に、バリデーターや委任の変更が適用されます。

エポックスケジュールは変更できますか？

ブロックチェーンのプロトコルが協調アップグレードを認めている場合は変更できますが、ネットワーク作成時に固定されるパラメーターもあります。

開発者はエポックの終了時刻を正確に計算できますか？

残りスロット数は計算できますが、実際のスロット時間が目標と異なると、暦上の終了時刻は変動する場合があります。

プロトコルアップグレードでエポック番号を使うのはなぜですか？

エポック番号は、互換性のあるノードが同じコンセンサスルールから算出できる、決定的なオンチェーン有効化時点となるためです。

スマートコントラクトはエポックスケジュールを読み取れますか？

ブロックチェーンによって異なります。Solanaプログラムは、対応するランタイムメソッドを通じてEpochSchedule sysvarにアクセスできます。

エポック番号はブロック番号と同じですか？

いいえ。1つのエポックには多数のスロットとブロックが含まれ、ブロックが生成されないスロットもあります。

バリデーターにとってエポックスケジュールが重要なのはなぜですか？

役割の期間、リーダーの割り当て、ステーキングの変更、報酬計算、プロトコル有効化の境界を把握するのに役立ちます。

エポックデータを取得する最も安全な方法は何ですか？

公式ノードインターフェースを使い、接続先ネットワークを確認し、適切なコミットメント水準を選び、正確性が重要な場合は独立したデータソースを比較してください。

まとめ

エポックスケジュールとは、ブロックチェーンの時間をスロットとエポックに分けるプロトコル構造です。バリデーターの役割、リーダー交代、ステーキングの更新、報酬、ファイナリティ、ガバナンス、ネットワークアップグレードに予測可能な期間を設けます。エポックはスロットのまとまりであり、スロットはブロック生成や投票などのコンセンサス活動を行う短い機会です。スロットは受け入れられるブロックがないまま経過する場合があるため、スロットとブロックは同じではありません。Solanaでは、Epoch Scheduleは通常のエポック長、リーダースケジュールのオフセット、ウォームアップの有無、通常エポックの基準フィールドを含む特定のネットワーク構造でもあります。Ethereumでは現在、12秒のスロット32個で1エポックを構成し、Cardanoでは現在、1秒のスロット432,000個で1エポックを構成しています。こうした違いから、エポックの時間は常に接続先のブロックチェーンに応じて解釈する必要があります。開発者は信頼できるノードインターフェースからスケジュール情報を取得し、ウォームアップを考慮して、すべてのエポック境界の計算をテストしてください。スロット時間が変動する場合、ユーザーは暦上のカウントダウンを推定として扱い、ステーキングの変更や報酬が各境界で直ちに利用可能になると仮定しないでください。エポックスケジュールを理解すると、暗号資産ユーザーはバリデーターのタイミング、報酬期間、ネットワークアップグレード、ガバナンスの期限、Proof of Stakeブロックチェーンの運用サイクルを把握しやすくなります。