Merge branch 'master' into patch-1

.fleek.json

@@ -1,6 +1,6 @@
 {
   "build": {
-    "image": "hugomrdias/puppeteer",
+    "image": "node:20.2",
     "command": "npm install && npm run build",
     "publicDir": "public"
   }

.gitignore

@@ -6,7 +6,8 @@ yarn.lock
 package-lock.json
 node_modules
 resources
-static/_gen
 data/toc.json
 api/dist
 api/worker
+.hugo_build.lock
+assets/jsconfig.json

.nvmrc

@@ -0,0 +1 @@
+v20.2.0

api/index.js

@@ -31,21 +31,41 @@ async function handleRequest(event) {
 async function cov(event) {
   const url = new URL(event.request.url)
   // https://github.com/filecoin-project/lotus
-  const repo = url.searchParams.get('repo').split('/').slice(3).join('/')
-  const data = await get(event, {
-    url: `https://codecov.io/api/gh/${repo}`,
+  const [owner, repo] = url.searchParams.get('repo').split('/').slice(3)
+  const headers = {
+    'User-Agent': 'ianconsolata',
+    Accept: 'application/json',
+    Authorization: `Bearer ${CODECOV_TOKEN}`,
+  }
+  const repo_resp = await get(event, {
+    url: `https://api.codecov.io/api/v2/github/${owner}/repos/${repo}/`,
     transform: (data) => {
       const out = {
-        cov: dlv(data, 'commit.totals.c', 0),
-        ci: dlv(data, 'commit.ci_passed', false),
-        repo: dlv(data, 'repo.name', 'N/A'),
-        org: dlv(data, 'owner.username', 'N/A'),
-        lang: dlv(data, 'repo.language', 'N/A'),
+        branch: dlv(data, 'branch', 'master'),
+        lang: dlv(data, 'language', 'N/A'),
       }
       return out
     },
+    headers,
   })
-  return data
+  const repo_data = await repo_resp.json()
+
+  const cov_data = await get(event, {
+    url: `https://api.codecov.io/api/v2/github/${owner}/repos/${repo}/branches/${repo_data.branch}/`,
+    transform: (data) => {
+      const out = {
+        cov: dlv(data, 'head_commit.totals.coverage', 0),
+        ci: dlv(data, 'head_commit.ci_passed', false),
+        repo: repo,
+        org: owner,
+        lang: repo_data.lang,
+        branch: repo_data.branch,
+      }
+      return out
+    },
+    headers,
+  })
+  return cov_data
 }
 
 async function github(event) {
@@ -56,7 +76,7 @@ async function github(event) {
   const path = file.slice(7).join('/')
   const ref = file[6]
   const headers = {
-    'User-Agent': 'hugomrdias',
+    'User-Agent': 'ianconsolata',
     Authorization: `token ${GITHUB_TOKEN}`,
   }
 
@@ -82,7 +102,7 @@ async function github(event) {
 
 async function releases(event) {
   const headers = {
-    'User-Agent': 'hugomrdias',
+    'User-Agent': 'ianconsolata',
     Authorization: `token ${GITHUB_TOKEN}`,
   }
   const rsp = await get(event, {

api/package.json

@@ -12,6 +12,7 @@
     "dlv": "^1.1.3",
     "merge-options": "^3.0.3",
     "nanoid": "^3.1.16",
-    "p-map": "^4.0.0"
+    "p-map": "^4.0.0",
+    "wrangler": "^2.17.0"
   }
 }

api/wrangler.toml

@@ -1,7 +1,5 @@
 name = "specs-api"
-type = "webpack"
-account_id = "fffa4b4363a7e5250af8357087263b3a"
+account_id = "e85b6fdda17f8c464c343dc84d1373e8"
 workers_dev = true
-route = ""
-zone_id = ""
-webpack_config = "webpack.config.js"
+main = "index.js"
+compatibility_date = "2023-04-27"

config.toml

@@ -5,6 +5,10 @@ canonifyurls = false
 theme = "book"
 # relativeURLs = true
 
+# allow building even if getting remote JSON fails
+# needed because rust-fil-proofs has no coverage
+ignoreErrors = ["error-remote-getjson"]
+
 # Book configuration
 disablePathToLower = true
 enableGitInfo = true
@@ -41,7 +45,7 @@ enableGitInfo = true
 #   weight = 10
 
 [params]
-  API = 'https://specs-api.protocol-labs.workers.dev'
+  API = 'https://specs-api.filecoin-foundation.workers.dev'
   # (Optional, default true) Controls table of contents visibility on right side of pages.
   # Start and end levels can be controlled with markup.tableOfContents setting.
   # You can also specify this parameter per page in front matter.

content/algorithms/expected_consensus/_index.md

@@ -173,9 +173,9 @@ WinCount guarantees that a lucky single block will earn the same reward as the r
 
 **Alternative Options for the Distribution/Sortition**
 
-Bernouli, Binomial and Poisson distributions have been considered for the _WinCount_ of a miner with power `p` out of a total network power of `N`. There are the following options:
+Bernoulli, Binomial and Poisson distributions have been considered for the _WinCount_ of a miner with power `p` out of a total network power of `N`. There are the following options:
 
-- Option 1: WinCount(p,N) ~ Bernouli(pE/N)
+- Option 1: WinCount(p,N) ~ Bernoulli(pE/N)
 - Option 2: WinCount(p,N) ~ Binomial(E, p/N)
 - Option 3: WinCount(p,N) ~ Binomial(p, E/N)
 - Option 4: WinCount(p,N) ~ Binomial(p/M, ME/N)
@@ -189,7 +189,7 @@ In Option 5 (the one used in Filecoin Leader Election), the ticket targets for e
 
 **Rationale for the Poisson Sortition choice**
 
-- Option 1 - Bernouli(pE/N): this option is easy to implement, but comes with a drawback: if the miner's power exceeds 1/E, the miner's WinCount is always 1, but never higher than 1.
+- Option 1 - Bernoulli(pE/N): this option is easy to implement, but comes with a drawback: if the miner's power exceeds 1/E, the miner's WinCount is always 1, but never higher than 1.
 - Option 2 - Binomial(E, p/N): the expectation of WinCount stays the same irrespectively of whether the miner splits their power into more than one Sybil nodes, but the variance increases if they choose to Sybil. Risk-seeking miners will prefer to Sybil, while risk-averse miners will prefer to pool, none of which is a behaviour the protocol should encourage. This option is not computationally-expensive as it would involve calculation of factorials and fixed-point multiplications (or small integer exponents) only.
 - Option 3 - Binomial(p, E/N): this option is computationally inefficient. It involves very large integer exponents.
 - Option 4 - Binomial(p/M, ME/N): the complexity of this option depends on the value of M. A small M results in high computational cost, similarly to Option 3. A large M, on the other hand, leads to a situation similar to that of Option 2, where a risk-seeking miner is incentivized to Sybil. Clearly none of these are desirable properties.
@@ -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
@@ -397,7 +397,7 @@ This is detectable when a given miner submits two blocks that satisfy any of the
 
 A single consensus fault results into:
 
-- miner termination and removal of power from the power table,
+- miner suspension
 - loss of all pledge collateral (which includes the initial pledge and blocks rewards yet to be vested)
 
 ### Detection and Reporting

content/algorithms/pos/post.md

@@ -30,7 +30,7 @@ Before continuing into more details of the _WinnningPoSt_ and _WindowPoSt_ algor
 
 ## WinningPoSt
 
-At the beginning of each epoch, a small number of storage miners (up to five, currently) are elected to mine new blocks, by Filecoin's [Expected Consensus](algorithms#expected_consensus) algorithm. Recall that the Filecoin blockchain operates on the basis of _tipsets_, which are groups of up to five blocks. This means that multiple blocks (up to five) can be mined at the same height.
+At the beginning of each epoch, a small number of storage miners are elected to mine new blocks, by Filecoin's [Expected Consensus](algorithms#expected_consensus) algorithm. Recall that the Filecoin blockchain operates on the basis of _tipsets_, therefore multiple blocks can be mined at the same height.
 
 Each of the miners that are elected to mine a block have to submit a proof that they keep a sealed copy of the data which they have included in their proposed block, before the end of the current epoch. Successful submission of this proof is the _WinningPoSt_, which in turn grants the miner the Filecoin Block Reward, as well as the opportunity to charge other nodes fees in order to include their messages in the block. If a miner misses the epoch-end deadline, then the miner misses the opportunity to mine a block and get a Block Reward. No penalty is incurred in this case.
 

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/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:**
 

content/appendix/audit_reports.md

@@ -22,6 +22,17 @@ The scope of this audit covered:
 - The Lotus Daemon: Core component responsible for handling the Blockchain node logic by handling peer- to-peer networking, chain syncing, block validation, data retrieval and transfer, etc.
 - The Lotus Storage Miner: Mining component used to manage a single storage miner by contributing to the network through Sector commitments and Proofs-of-Spacetime data proving it is storing the sectors it has committed to. This component communicates with the Lotus daemon via JSON-RPC API calls.
 
+## Venus
+
+### `2021-06-29` Venus Security Audit
+
+- Report: [Venus Security Assessment](https://leastauthority.com/static/publications/LeastAuthority_Filecoin_Foundation_Venus_Final_Audit_Report.pdf)
+- Audit conducted by: **Least Authority**
+
+The scope of this audit covered:
+
+- The Venus Daemon: Core component responsible for handling the Filecoin node logic by handling peer-to-peer networking, chain syncing, block validation, etc.
+
 ## Actors
 
 ### `2020-10-19` Actors Mainnet Ready Security Audit

content/intro/systems/impl_systems.md

@@ -41,7 +41,7 @@ For this purpose, we use the `FilecoinNode` data structure, which is passed into
 Further, Systems MUST abide by the following limitations:
 
 - **Random crashes.** A Filecoin Node may crash at any moment. Systems must be secure and consistent through crashes.
-  This is primarily achived by limiting the use of persistent state, persisting such state through Ipld data structures,
+  This is primarily achieved by limiting the use of persistent state, persisting such state through Ipld data structures,
   and through the use of initialization routines that check state, and perhaps correct errors.
 - **Isolation.** Systems must communicate over well-defined, isolated interfaces. They must not build their critical
   functionality over a shared memory space. (Note: for performance, shared memory abstractions can be used to power

content/intro/systems/why_systems.md

@@ -29,12 +29,12 @@ This decoupling is useful for:
 - **Security Isolation:** some systems require higher operational security than others. System decoupling allows
   implementations to meet their security and functionality needs. A good example of this is separating Blockchain
   processing from Data Transfer.
-- **Scalability:** systems, and various use cases, may drive different performance requirements for different opertators.
+- **Scalability:** systems, and various use cases, may drive different performance requirements for different operators.
   System decoupling makes it easier for operators to scale their deployments along system boundaries.
 
 ## Filecoin Nodes don't need all the systems
 
-Filecoin Nodes vary significantly, and do not need all the systems.
+Filecoin Nodes vary significantly and do not need all the systems.
 Most systems are only needed for a subset of use cases.
 
 For example, the Blockchain System is required for synchronizing the chain, participating in secure consensus,

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
 
@@ -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/0df91a710b4366d41e88ad487814a16cf88494f9/crypto/schemes.go#L68) for an example.
 
 ### Fetching the appropriate drand value while mining
 

content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md

@@ -16,7 +16,7 @@ dashboardTests: 0
 
 {{<embed src="https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/power/power_actor.go" lang="go" symbol="Exports">}}
 
-{{<embed src="https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/power/power_actor.go" lang="go" symbol="MinerConstructorParams">}}
+{{<embed src="https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/power/power_actor.go" lang="go" symbol="Constructor">}}
 
 ## The Power Table
 

content/systems/filecoin_markets/storage_market/_index.md

@@ -10,7 +10,7 @@ dashboardTests: 0
 
 # Storage Market in Filecoin
 
-Storage Market subsystem is the data entry point into the network. Storage miners only earn power from data stored in a storage deal and all deals live on the Filecoin network. Specific deal negotiation process happens off chain, clients and miners enter a storage deal after an agreement has been reached and post storage deals on the Filecoin network to earn block rewards and get paid for storing the data in the storage deal. A deal is only valid when it is posted on chain with signatures from both parties and at the time of posting, there are sufficient balances for both parties locked up to honor the deal in terms of deal price and deal collateral.
+Storage Market subsystem is the data entry point into the network. Storage miners can earn power from data stored in a storage deal and all deals live on the Filecoin network. Specific deal negotiation process happens off chain, clients and miners enter a storage deal after an agreement has been reached and post storage deals on the Filecoin network to earn block rewards and get paid for storing the data in the storage deal. A deal is only valid when it is posted on chain with signatures from both parties and at the time of posting, there are sufficient balances for both parties locked up to honor the deal in terms of deal price and deal collateral.
 
 ## Terminology
 

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).

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