From fc055366676cbd604933c017879cc2ce706cdbf1 Mon Sep 17 00:00:00 2001 From: smagdali Date: Wed, 1 Feb 2023 13:33:31 +0000 Subject: [PATCH 1/6] fixed some broken links. --- content/algorithms/expected_consensus/_index.md | 2 +- content/algorithms/sdr/_index.md | 4 ++-- content/libraries/drand/_index.md | 4 ++-- content/systems/filecoin_mining/sector/_index.md | 2 +- content/systems/filecoin_mining/sector/sealing.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/algorithms/expected_consensus/_index.md b/content/algorithms/expected_consensus/_index.md index 3d8d39263..0c24fea58 100644 --- a/content/algorithms/expected_consensus/_index.md +++ b/content/algorithms/expected_consensus/_index.md @@ -342,7 +342,7 @@ The exact value for these parameters remain to be determined, but for testing pu - `log2b(X) = floor(log2(x)) = (binary length of X) - 1` and `log2b(0) = 0`. Note that that special case should never be used (given it would mean an empty power table). {{< hint warning >}} -**Note that if your implementation does not allow for rounding to the fourth decimal**, miners should apply the [tie-breaker below](selecting-between-tipsets-with-equal-weight). Weight changes will be on the order of single digit numbers on expectation, so this should not have an outsized impact on chain consensus across implementations. +**Note that if your implementation does not allow for rounding to the fourth decimal**, miners should apply the [tie-breaker below](section-algorithms.expected_consensus.selecting-between-tipsets-with-equal-weight). Weight changes will be on the order of single digit numbers on expectation, so this should not have an outsized impact on chain consensus across implementations. {{< /hint >}} `ParentWeight` is the aggregate chain weight of a given block's parent set. It is calculated as diff --git a/content/algorithms/sdr/_index.md b/content/algorithms/sdr/_index.md index ec257f229..fb2551728 100644 --- a/content/algorithms/sdr/_index.md +++ b/content/algorithms/sdr/_index.md @@ -1156,8 +1156,8 @@ $\line{11}{}{\return \Sha{254}(\preimage) \as \Fq}$ **Implementation:** -- [`storage_proofs::porep::stacked::circuit::proof::StackedCircuit::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs/porep/src/stacked/circuit/proof.rs#L77) -- [`storage_proofs::porep::stacked::circuit::params::Proof::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs/porep/src/stacked/circuit/params.rs#L77) +- [`storage_proofs::porep::stacked::circuit::proof::StackedCircuit::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs-porep/src/stacked/circuit/proof.rs#L92) +- [`storage_proofs::porep::stacked::circuit::params::Proof::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs-porep/src/stacked/circuit/params.rs#L99) **Additional Notation:** diff --git a/content/libraries/drand/_index.md b/content/libraries/drand/_index.md index 37b3ca8ac..feedd8b6e 100644 --- a/content/libraries/drand/_index.md +++ b/content/libraries/drand/_index.md @@ -18,7 +18,7 @@ Any node that has gathered t of the signatures can reconstruct the full BLS sign drand assumes that at least t of the n nodes are honest (and online -- for liveness). If this threshold is broken, the adversary can permanently halt randomness production but cannot otherwise bias the randomness. -You can learn more about how drand works, by visiting its [repository](https://github.com/drand/drand), or reading its [spec](https://github.com/drand/drand/blob/master/docs/SPECS.md). +You can learn more about how drand works, by visiting its [repository](https://github.com/drand/drand), or reading its [specification](https://drand.love/docs/specification/). In the following sections we look in turn at how the Filecoin protocol makes use of drand randomness, and at some of the characteristics of the specific drand network Filecoin uses. @@ -40,7 +40,7 @@ Specifically, we have: - `PreviousSignature` -- the threshold BLS signature from the previous drand round. - `Round` -- the index of Randomness in the sequence of all random values produced by this drand network. -Specifically, the message signed is the concatenation of the round number treated as a uint64 and the previous signature. At the moment, drand uses BLS signatures on the BLS12-381 curve with the latest v7 RFC of hash-to-curve and the signature is made over G1 (for more see the [drand spec](https://github.com/drand/drand/blob/master/docs/SPECS.md#cryptographic-specification)). +Specifically, the message signed is the concatenation of the round number treated as a uint64 and the previous signature. At the moment, drand uses BLS signatures on the BLS12-381 curve with the latest v7 RFC of hash-to-curve and the signature is made over G1 (for more see the [drand specification](https://drand.love/docs/specification/#cryptographic-specification). ## Polling the drand network diff --git a/content/systems/filecoin_mining/sector/_index.md b/content/systems/filecoin_mining/sector/_index.md index 9fb8bd364..65dff3b1d 100644 --- a/content/systems/filecoin_mining/sector/_index.md +++ b/content/systems/filecoin_mining/sector/_index.md @@ -30,6 +30,6 @@ This diagram shows the composition of an unsealed sector and a sealed sector. **Sector Storage & Window PoSt** -The Lotus implementation of the Window PoSt scheduler can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/wdpost_sched.go) and the actual execution of Window PoSt on a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/wdpost_run.go). +The Lotus implementation of the Window PoSt scheduler can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/wdpost/wdpost_sched.go) and the actual execution of Window PoSt on a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/wdpost/wdpost_run.go). The Lotus block store implementation for sectors can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/sectorblocks/blocks.go). diff --git a/content/systems/filecoin_mining/sector/sealing.md b/content/systems/filecoin_mining/sector/sealing.md index 108499f1b..2cf2944e1 100644 --- a/content/systems/filecoin_mining/sector/sealing.md +++ b/content/systems/filecoin_mining/sector/sealing.md @@ -18,7 +18,7 @@ Before a Sector can be used, the Miner must _seal_ the Sector: encode the data i Sealing a sector through Proof-of-Replication (PoRep) is a computation-intensive process that results in a unique encoding of the sector. Once data is sealed, storage miners: generate a proof; run a SNARK on the proof to compress it; and finally, submit the result of the compression to the blockchain as a certification of the storage commitment. Depending on the PoRep algorithm and protocol security parameters, cost profiles and performance characteristics vary and tradeoffs have to be made among sealing cost, security, onchain footprint, retrieval latency and so on. However, sectors can be sealed with commercial hardware and sealing cost is expected to decrease over time. The Filecoin Protocol will launch with Stacked Depth Robust (SDR) PoRep with a planned upgrade to Narrow Stacked Expander (NSE) PoRep with improvement in both cost and retrieval latency. -The Lotus-specific set of functions applied to the sealing of a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/sealing.go). +The Lotus-specific set of functions applied to the sealing of a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/pipeline/sealing.go). ## Randomness From b28a6502d85099484585d3c18be1ab80bb26f660 Mon Sep 17 00:00:00 2001 From: smagdali Date: Wed, 1 Feb 2023 14:47:49 +0000 Subject: [PATCH 2/6] fixed drand verifier 404 --- content/libraries/drand/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/libraries/drand/_index.md b/content/libraries/drand/_index.md index feedd8b6e..e5372e9aa 100644 --- a/content/libraries/drand/_index.md +++ b/content/libraries/drand/_index.md @@ -90,7 +90,7 @@ Upon receiving a new drand randomness value from a beacon, a Filecoin node shoul - that the `Signature` field is verified by the beacon's `PublicKey` as the beacon's signature of `SHA256(PreviousSignature || Round)`. - that the `Randomness` field is `SHA256(Signature)`. -See [drand](https://github.com/drand/drand/blob/master/beacon/beacon.go#L63) for an example. +See [drand](https://github.com/drand/drand/blob/master/crypto/schemes.go#L68) for an example. ### Fetching the appropriate drand value while mining From e2105143ef22a63519c20524cbe72a535017be57 Mon Sep 17 00:00:00 2001 From: smagdali Date: Thu, 2 Feb 2023 14:00:04 +0000 Subject: [PATCH 3/6] updated links to immutable blobs so line numbers don't drift --- content/algorithms/sdr/_index.md | 4 ++-- content/libraries/drand/_index.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/algorithms/sdr/_index.md b/content/algorithms/sdr/_index.md index fb2551728..d654dc631 100644 --- a/content/algorithms/sdr/_index.md +++ b/content/algorithms/sdr/_index.md @@ -1156,8 +1156,8 @@ $\line{11}{}{\return \Sha{254}(\preimage) \as \Fq}$ **Implementation:** -- [`storage_proofs::porep::stacked::circuit::proof::StackedCircuit::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs-porep/src/stacked/circuit/proof.rs#L92) -- [`storage_proofs::porep::stacked::circuit::params::Proof::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/storage-proofs-porep/src/stacked/circuit/params.rs#L99) +- [`storage_proofs::porep::stacked::circuit::proof::StackedCircuit::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/108517271f8166cabc23e1966d8e8f397ec75ae0/storage-proofs-porep/src/stacked/circuit/proof.rs#L64) +- [`storage_proofs::porep::stacked::circuit::params::Proof::synthesize()`](https://github.com/filecoin-project/rust-fil-proofs/blob/108517271f8166cabc23e1966d8e8f397ec75ae0/storage-proofs-porep/src/stacked/circuit/proof.rs#L92) **Additional Notation:** diff --git a/content/libraries/drand/_index.md b/content/libraries/drand/_index.md index e5372e9aa..0ff7a285d 100644 --- a/content/libraries/drand/_index.md +++ b/content/libraries/drand/_index.md @@ -90,7 +90,7 @@ Upon receiving a new drand randomness value from a beacon, a Filecoin node shoul - that the `Signature` field is verified by the beacon's `PublicKey` as the beacon's signature of `SHA256(PreviousSignature || Round)`. - that the `Randomness` field is `SHA256(Signature)`. -See [drand](https://github.com/drand/drand/blob/master/crypto/schemes.go#L68) for an example. +See [drand](https://github.com/drand/drand/blob/0df91a710b4366d41e88ad487814a16cf88494f9/crypto/schemes.go#L68) for an example. ### Fetching the appropriate drand value while mining From 29d22eae66ac8a74229f2d219ad49d59ea66a6d7 Mon Sep 17 00:00:00 2001 From: smagdali Date: Thu, 2 Feb 2023 19:44:37 +0000 Subject: [PATCH 4/6] can't use a type as an embed symbol, only a func --- .../storage_power_consensus/storage_power_actor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md b/content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md index a050d25a3..f9b7873d5 100644 --- a/content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md +++ b/content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md @@ -16,7 +16,7 @@ dashboardTests: 0 {{}} -{{}} +{{}} ## The Power Table From 28c057eb3678a53173b42960bedbd095540ea004 Mon Sep 17 00:00:00 2001 From: smagdali Date: Fri, 3 Feb 2023 11:01:49 +0000 Subject: [PATCH 5/6] typo fix --- content/algorithms/expected_consensus/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/algorithms/expected_consensus/_index.md b/content/algorithms/expected_consensus/_index.md index 0c24fea58..390bb2434 100644 --- a/content/algorithms/expected_consensus/_index.md +++ b/content/algorithms/expected_consensus/_index.md @@ -342,7 +342,7 @@ The exact value for these parameters remain to be determined, but for testing pu - `log2b(X) = floor(log2(x)) = (binary length of X) - 1` and `log2b(0) = 0`. Note that that special case should never be used (given it would mean an empty power table). {{< hint warning >}} -**Note that if your implementation does not allow for rounding to the fourth decimal**, miners should apply the [tie-breaker below](section-algorithms.expected_consensus.selecting-between-tipsets-with-equal-weight). Weight changes will be on the order of single digit numbers on expectation, so this should not have an outsized impact on chain consensus across implementations. +**Note that if your implementation does not allow for rounding to the fourth decimal**, miners should apply the [tie-breaker below](#section-algorithms.expected_consensus.selecting-between-tipsets-with-equal-weight). Weight changes will be on the order of single digit numbers on expectation, so this should not have an outsized impact on chain consensus across implementations. {{< /hint >}} `ParentWeight` is the aggregate chain weight of a given block's parent set. It is calculated as From caac6e97619d959e9a866eb0acae2c0e1b8a4538 Mon Sep 17 00:00:00 2001 From: smagdali Date: Fri, 1 Nov 2024 11:43:53 +0700 Subject: [PATCH 6/6] fix for sector sealing specifics link to lotus source on github leads nowhere #1311 --- content/systems/filecoin_mining/sector/sealing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/systems/filecoin_mining/sector/sealing.md b/content/systems/filecoin_mining/sector/sealing.md index 2cf2944e1..6f9b9a417 100644 --- a/content/systems/filecoin_mining/sector/sealing.md +++ b/content/systems/filecoin_mining/sector/sealing.md @@ -18,7 +18,7 @@ Before a Sector can be used, the Miner must _seal_ the Sector: encode the data i Sealing a sector through Proof-of-Replication (PoRep) is a computation-intensive process that results in a unique encoding of the sector. Once data is sealed, storage miners: generate a proof; run a SNARK on the proof to compress it; and finally, submit the result of the compression to the blockchain as a certification of the storage commitment. Depending on the PoRep algorithm and protocol security parameters, cost profiles and performance characteristics vary and tradeoffs have to be made among sealing cost, security, onchain footprint, retrieval latency and so on. However, sectors can be sealed with commercial hardware and sealing cost is expected to decrease over time. The Filecoin Protocol will launch with Stacked Depth Robust (SDR) PoRep with a planned upgrade to Narrow Stacked Expander (NSE) PoRep with improvement in both cost and retrieval latency. -The Lotus-specific set of functions applied to the sealing of a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/storage/pipeline/sealing.go). +The Lotus-specific set of functions applied to the sealing of a sector can be found [here](https://github.com/filecoin-project/lotus/blob/master/cmd/lotus-miner/sealing.go). ## Randomness