Filecoin の解釈 | Window PoSTとは何ですか?

Lotus が提供する PoSt アルゴリズムには、Winning PoSt と Window PoSt の 2 つのスキームがあります。 Winning PoStでは、ブロック生成時にコミットされたセクターデータを証明します。提出された部門データを定期的に検証し、正しく保存されていることを確認します。

この記事では、WindowPoSt ロジックを詳しく紹介します。

Window PoSt を理解するには、スマートコントラクトのセクターの管理から始める必要があります。

この記事で使用されているスマートコントラクト (スペックアクター) の最新の送信情報は次のとおりです。

コミット 382017dd33e9e818a51503893433628fab643dd3
著者: Alex North<[email protected]>
日付: 2020 年 5 月 6 日水曜日 10:08:31 +1000ConsensusMinerMinPower を 10TiB に設定 (#344)

鉱業州

マイナーのプロパティ情報、住宅ローン情報、セクターステータスは、マイナー状態に保存されます。 WindowPoSt に関連するコードスニペットを選択します。

型 State 構造体 {
...
証明期間開始abi.ChainEpoch
新しいセクター *abi.BitField
締め切り cid.Cid
...
}

ProvingPeriodStart - 各証明期間の開始時刻。

NewSectors — 新しいブロックに関する情報

締め切り - 各チャレンジウィンドウは複数のウィンドウに分割されます。各ウィンドウには期限があります。 WindowPoSt の名前の由来はここにあります。

1.1 検証期間

WindowPoSt の構成仕様は、specs-actors/actors/builtin/miner/policy.go で定義されています。

定数エポック継続時間秒数 = 25
定数年内の秒数 = 31556925
定数秒数 = 86400

const WPoStProvingPeriod = abi.ChainEpoch(SecondsInDay / EpochDurationSeconds) const WPoStChallengeWindow = abi.ChainEpoch(1800 / EpochDurationSeconds) // 30分（=1日あたり48）

定数 WPoStPeriodDeadlines = uint64(WPoStProvingPeriod / WPoStChallengeWindow)

定数 WPoStChallengeLookback = abi.ChainEpoch(20)

WPoStProvingPeriod —証明期間。証明は1日1回必要です。

WPoStChallengeWindow — ChallengeWindow は 30 分です。各検証期間は 47 の ChallengeWindow に分割されます。

WPoStPeriodDeadlines — チャレンジウィンドウの終了。

WPoStChallengeLookback — チェーンからランダムな量のデータを取得し、各 ChallengeWindow の前のブロックの時間を遡ります。

要約すると、WindowPoSt の期間は 1 日で、各 WindowPoSt は 48 のウィンドウに分割されます。セクター情報は、ウィンドウの異なる期間によって異なります。各ウィンドウには WindowPoSt によって提供される証明が必要であり、ウィンドウ内のセクター数によって必要な証明の数が決まります。詳しいロジックについては後ほど紹介します。

1.2 締め切り

期限は specs-actor/actors/builtin/miner/deadlines.go で定義されています:

DeadlineInfo構造体型{
CurrentEpoch abi.ChainEpoch // この情報が計算されたエポック。
PeriodStart abi.ChainEpoch // 証明期間の最初のエポック (<= CurrentEpoch)。
Index uint64 // 現在の期限インデックス ([0..WPoStProvingPeriodDeadlines)、または期間が経過した場合は WPoStProvingPeriodDeadlines。
abi.ChainEpoch を開きます // 証明を送信できる最初のエポック（含む、>= CurrentEpoch）。
Close abi.ChainEpoch // 証明を送信できなくなる最初のエポック（>= Open）。
チャレンジ abi.ChainEpoch // チャレンジのチェーンをサンプリングするエポック (< Open)。
FaultCutoff abi.ChainEpoch // 障害宣言が拒否される最初のエポック (< Open)。
}

CurrentEpoch - 現在の期限時刻。

PeriodStart — 各プルーフの開始凍結時間。

インデックス — カットオフ日 (ウィンドウとも呼ばれます) のインデックス。範囲は 0 から 47 です。

オープン - この期間中に証拠を提出できる最も早い時間。

閉じる - このウィンドウで許可されている最終時間、または証拠を提出します。

チャレンジ - このウィンドウ内の乱数の範囲。

FaultCutoff - 障害ブロックは、このカットオフブロック時間の前にのみ特定できます。

ComputeProvingPeriodDeadline 関数は、証明開始時間と現在のブロック時間に基づいて Deadline を計算します。

func ComputeProvingPeriodDeadline(periodStart, currEpoch abi.ChainEpoch) *DeadlineInfo {
periodProgress := currEpoch - periodStart
...

期限Idx := uint64(期間の進行状況 / WPoStChallengeWindow)
if periodProgress < 0 { // 期間はまだ開始されていません。
期限ID = 0
}
期限オープン:=期間開始+(abi.ChainEpoch(deadlineIdx) * WPoStChallengeWindow)

&DeadlineInfo{を返す
現在のエポック: currEpoch、
期間開始: 期間開始、
インデックス:deadlineIdx、
オープン: 締め切りオープン、
終了: 締め切りOpen + WPoStChallengeWindow、
チャレンジ: 締め切りオープン - WPoStChallengeLookback、
FaultCutoff: 期限未定 - FaultDeclarationCutoff、
}
}

現在のブロック時間と開始時間から deadlienIdx を取得できます。このインデックスを使用すると、他の変数を取得しやすくなります。

状態変更ロジック

WindowPoSt 状態ロジックには、各 windowPoSt 証明の開始時間を調整することと、証明する必要があるセクター情報を更新することの 2 つの部分があります。

2.1 認定開始時間を調整する

マイナーのスマートコントラクトが作成されると、証明の開始時刻が初期化されます。

オフセット、エラー:=assignProvingPeriodOffset(rt.Message().Receiver(), currEpoch, rt.Syscalls().HashBlake2b)
periodStart := nextProvingPeriodStart(currEpoch,

AssignProvingPeriodOffset は、関数 HashBlake2b を通じて [0, WPoStProvingPeriod] 内のオフセットをランダムに生成します。

nextProvingPeriodStart 関数は次のとおりです。

func nextProvingPeriodStart(currEpoch abi.ChainEpoch, offset abi.ChainEpoch) abi.ChainEpoch {
currModulus := currEpoch % WPostProvingPeriod
var periodProgress abi.ChainEpoch // currEpoch が前のオフセット境界からどれだけ進んでいるか。
currModulus >= offset の場合
periodProgress = currModulus - オフセット
} それ以外 {
periodProgress = WPoStProvingPeriod - (オフセット - currModulus)
}

periodStart := currEpoch - periodProgress + WPoStProvingPeriod
アサート(periodStart > currEpoch)
返品期間開始
}

簡単に言えば、この関数は指定されたオフセットで次の証明開始時刻を見つけます。

証明開始時刻がわかったら、マイナーのスマートコントラクトは各証明期間の終了時に証明ステータスを確認し、証明開始時刻を更新します。

function handleProvingPeriod(rt ランタイム) {
...
期限.PeriodStarted() の場合 {
st.ProvingPeriodStart = st.ProvingPeriodStart + WPoStProvingPeriod
}
...
エラー = st.ClearPoStSubmissions()
...
}

2.2 業界情報の更新

マイナーのスマートコントラクトでは、NewSectors は 3 つのインターフェースを通じて更新されます。

verifyCommitSector: PoREPommi の送信時に、NewSectors に新しいセクター情報を追加します。

TerminateSector: NewSectors からセクター情報を削除します。

handleProvingPeriod: 期限までに NewSectors 情報を定期的に「プロビジョニング」します。言い換えれば、この関数はマイナーのスマートコントラクトで証明する必要があるすべてのセクターのリストを維持します。各ウィンドウポジションの開始時に、異なるウィンドウにセクターを割り当てます。

部門割り当て

AssignNewSectors 関数を使用して、検証する必要があるセクターを異なるウィンドウ (期限) に割り当てます。

function AssignNewSectors(deadlines *Deadlines, パーティションサイズ uint64, newSectors []uint64, シード abi.Randomness) error {

注:partitionSize はパーティション内のセクター数です。

func (p RegisteredProof) WindowPoStPartitionSectors() (uint64, error) {
...
ケース RegisteredProof_StackedDRG32GiBSeal:
2349、nilを返す
ケース RegisteredProof_StackedDRG2KiBSeal:
2, nilを返す
ケース RegisteredProof_StackedDRG8MiBSeal:
2, nilを返す
ケース RegisteredProof_StackedDRG512MiBSeal:
2, nilを返す
デフォルト：
0 を返します。errors.Errorf("サポートされていない証明タイプ: %v", p)
...
}

32 GB セクターの場合、パーティションサイズは 2349 です。

AssignNewSectors には 2 つのステップがあります。

1. セクター数がパーティションサイズに達するまで各ウィンドウを入力します。

2. 手順 1 の後にセクターが残っている場合は、partitionSize に応じて各ウィンドウにセクターを割り当てます。

セクター割り当てをまとめると、partitionSize が単位として各ウィンドウに割り当てられます。つまり、1 つのウィンドウに複数のセクター分割単位が存在する可能性があります。入力変数シードに特に注意してください。この機能はセクター割り当てをランダム化しようとしますが、まだ実装されていません。

WindowPost プルーフ配布

Lotus プロジェクトにおける WindowPoSt の校正ロジック。以下は、この記事で使用されている Lotus ソースコードの最後のコミットからの情報です。

コミット 10fe6084f1374891a6666fad61b9c3aa448b4554
マージ: 1d887b55 1831613f
著者: Łukasz Magiera
日付: 2020 年 5 月 6 日水曜日 01:45:33 +0200 プルリクエスト #1670 を filecoin-project/feat/update-markets-0.2.0 からマージ

go-fil-markets を更新

完全な WindowPoSt スケジューリングロジックフローチャートは次のとおりです。

WindowPoStScheduler: チェーンのステータスを監視します。新しいブロックの高さで doPoSt を実行しようとします。 doPoSt は、wunPoSt の実行時に生成される WindowPoSt 証明 (rust-fil-proofs からの出力) と、証明をチェーンにプッシュする SubmitPoSt の 2 つの部分に分かれています。証明期間内のすべての証明はチェーンに記録されます。 handleProvingPeriod: 各期間の終了時に、すべてのウィンドウのすべての証明状態を確認します。

このコースでこれまでに説明した内容を要約すると次のようになります。

1. 1 回の認証期間は 1 日です。 1期間は48のウィンドウに分割されます。各ウィンドウには 30 分かかります。

2. 各ウィンドウには期限があります（証明書の正しい提出のために短縮されます）。

3. 既存のパーティションは、partitionSize (2349 セクター) に基づいて割り当てられ、各ウィンドウを埋めます。割り当て後にセクターが残っている場合は、partitionSize 単位で Windows への入力を続けます。

セクターサイズが 32GB の場合、2349 セクター、つまり 73T になります。各ウィンドウに 1 つのセクターパーティションが含まれている場合、合計ストレージ容量は 73T * 48 = 2.25P になります。つまり、4.5P のストレージスペースの場合、各ウィンドウには 2 つのセクターパーティションが含まれます。

保存するデータが増えると、部門も増え、Windows が占めるスペースも増えます。したがって、この計算にはさらに時間がかかることになります。

WindowPoSt 証明を生成する

プロセスロジックの基本を理解した後、最後に WindowPoSt で証明を生成する方法を見ていきます。これらのロジックは、rust-fil-proof または rust 形式で実装されます。 Rust から Rust まで、さまざまなインターフェースに遭遇します。

ここでは、中間インターフェースをスキップし、rust-fil-proofs のインターフェース関数を直接使用します。

pub fn generate_window_post<ツリー: 'static + MerkleTreeTrait>(
post_config: &PostConfig,
ランダム性: &ChallengeSeed,
レプリカ: &BTreeMap<SectorId, PrivateReplicaInfo >、
prover_id: 証明者ID、
) -> 結果{

ここで post_config は PoStConfig (構成) を意味します。

ランダム性は、セクターのクエリのリーフデータを生成するために使用されるランダム情報です。レプリカは、WindowPoSt 証明で生成されたすべてのセクターの対応するレプリカデータです。

ポスト構成

PoStConfig は rust-filecoin-proofs-api/src/registry.rs で定義されています:

pub fn as_v1_config(self) -> PoStConfig {
自分自身と一致する{
...
スタックドDrgWindow2KiBV1
|スタックドDrgWindow8MiBV1
|スタックドDrgWindow512MiBV1
|スタックドDrgWindow32GiBV1 => PostConfig {
型: self.typ(),
セクターサイズ: self.sector_size(),
セクター数: self.sector_count(),
チャレンジカウント: 定数::WINDOW_POST_CHALLENGE_COUNT、
優先度: true、
}, // _ => panic!("V1 構成でのみ呼び出すことができます"),
}
}

sector_count と challenge_count は rust-fil-proofs/filecoin-proofs/src/constants.rs で定義されていることに注意してください。

pub const WINDOW_POST_CHALLENGE_COUNT: usize = 10;pub static ref WINDOW_POST_SECTOR_COUNT: RwLock<HashMap > = RwLock::new(
[
(SECTOR_SIZE_2_KIB、2)、
(SECTOR_SIZE_4_KIB、2)、
(SECTOR_SIZE_16_KIB、2)、
(SECTOR_SIZE_32_KIB、2)、
(SECTOR_SIZE_8_MIB、2)、
(SECTOR_SIZE_16_MIB、2)、
(SECTOR_SIZE_512_MIB、2)、
(SECTOR_SIZE_1_GIB、2)、
(SECTOR_SIZE_32_GIB, 2349)、// これにより、133,977,564 の制約が生成され、1 つのパーティションにちょうど収まります。
(SECTOR_SIZE_64_GIB, 2300)、// これにより、131,182,800 の制約が生成され、1 つのパーティションにちょうど収まります。
]
.iter()
.コピーしました()
。集める（）
);

たとえば、チャレンジ番号が 10 の場合、パーティションは 2349 セクターで構成され、各セクターのサイズは 32 GB になります。

5.2 課題の創出

各セクターには 10 枚のチャレンジリーフが含まれています。

計算方法は次のとおりです (storage-proofs/post/src/fallback/vanilla.rs の prove_all_partitions 関数):

include_proofs = (0..pub_params.challenge_count) とします。
.into_par_iter()
.map(|n| {
challenge_index = ((j * num_sectors_per_chunk + i) とします。
* pub_params.チャレンジカウント
+ n) を u64 として
challenged_leaf_start = generate_leaf_challenge( とする
pub_params、
pub_inputs.ランダム性、
セクターID.into()、
チャレンジインデックス、
)?;tree.gen_cached_proof(challenged_leaf_start を usize、levels として)
})
.collect::<Result<Vec<_>>>()?;

Challenge_index は、部門が証明する必要があるすべての課題のインデックスです。 generate_leaf_challenge は、ランダム情報、セクターインデックス、チャレンジインデックスに基づいてリーフインデックスを生成します。

mut hasher = Sha256::new() とします。
hasher.input(AsRef::<[u8]>::as_ref(&randomness));
hasher.input(&sector_id.to_le_bytes()[..]);
hasher.input(&leaf_challenge_index.to_le_bytes()[..]);
hash = hasher.result(); leaf_challenge = LittleEndian::read_u64(&hash.as_ref()[..8]); challenged_range_index = leaf_challenge % (pub_params.sector_size / NODE_SIZE as u64);

次に、ランダムデータ、セクター ID、チャレンジリーフインデックスに対してハッシュ関数を使用します。結果と葉の合計数の剰余を取ります。 32 GB のセクターの場合、16 GB のリーフが得られます。

5.3 ゼロ知識証明回路

ここで説明する回路ロジックは、変数が異なることを除いて WinningPoSt 回路と同じです。

WindowPoSt のパーティションサイズのカウントは 1 ではないことに注意してください。計算方法は以下の通りです。

パーティション = get_partitions_for_window_post(replicas.len(), &post_config);fn get_partitions_for_window_post(
total_sector_count: 使用サイズ、
post_config: &PostConfig,
) -> オプション{
パーティション = (total_sector_count as f32 / post_config.sector_count as f32).ceil() as usize;パーティション > 1 の場合 {
一部(パーティション)
} それ以外 {
なし
}
}

つまり、パーティションの数は、レプリカの数を各パーティションのセクター数 (2349) で割った数になります。

要約すると、証明（パーティション）の数は、証明する必要があるセクターの数に関連し、レプリカの数を 2349 で割った数に等しくなります。各パーティションの証明では、各セクターから 10 個のリーフノードが抽出されます。

抽象的な

WindowPoSt は、送信されたセクターデータの存在を定期的に証明します。各検証期間は 1 日かかります。 1期間は48個のウィンドウで構成されます。各ウィンドウには 30 分かかります。

すべての Windows では、WindowPoSt 証明計算が必要です。証明の数は、ウィンドウ内のセクター数をパーティション内のセクター数で割った数に等しくなります。パーティション分割を証明するために、パーティションの各セクターから 10 個のリーフノードを抽出します。

- 終わり -

<<: データ：ビットコインの個人投資家の数は過去5年間で着実に増加し、クジラの数は減少し、分散化は増加し続け、採用は増加しました。

>>: ヴィタリック・ブテリン氏のスピーチから貴重な情報をすべてご紹介します。 Ethereum 2.0について知っておきたいことはすべてここにあります