From da8b928a01677688f5529118b5f8129e156a2ca9 Mon Sep 17 00:00:00 2001 From: Danial Ahn Date: Mon, 28 Oct 2024 16:45:41 +0900 Subject: [PATCH 01/10] Fix: typo adding_storage.md (#1328) Fix typo : coose -> choose --- content/systems/filecoin_mining/sector/adding_storage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/systems/filecoin_mining/sector/adding_storage.md b/content/systems/filecoin_mining/sector/adding_storage.md index 3fc1b322e..25c70be68 100644 --- a/content/systems/filecoin_mining/sector/adding_storage.md +++ b/content/systems/filecoin_mining/sector/adding_storage.md @@ -32,7 +32,7 @@ To facilitate this, there are _two types_ of Sectors that may be sealed and Prov - **Regular Sector**: A Sector that contains Client data - **Committed Capacity (CC) Sector**: A Sector with no data (all zeroes) -Miners are free to coose which types of Sectors to store. CC sectors, in particular, allow Miners to immediately make use of existing disk space: earning storage power and a higher chance at producing a block. Miners can decide if they should upgrade their CC sectors to take client deals or continue proving CC sectors. Currently, CC sectors store randomness by default in client implementation, but this does not preclude miners from storing any type of useful data that increase their private utility in CC sectors (as long as it is legal). The protocol expects that new use-cases and diversity will emerge out of such behaviour. +Miners are free to choose which types of Sectors to store. CC sectors, in particular, allow Miners to immediately make use of existing disk space: earning storage power and a higher chance at producing a block. Miners can decide if they should upgrade their CC sectors to take client deals or continue proving CC sectors. Currently, CC sectors store randomness by default in client implementation, but this does not preclude miners from storing any type of useful data that increase their private utility in CC sectors (as long as it is legal). The protocol expects that new use-cases and diversity will emerge out of such behaviour. To incentivize Miners to hoard storage space and dedicate it to Filecoin, CC Sectors have a unique capability: **they can be "upgraded" to Regular Sectors** (also called "replacing a CC Sector"). From 732548d6b2e5b5f862de1c931515ed0ecc90def8 Mon Sep 17 00:00:00 2001 From: Ian Davis Date: Wed, 30 Oct 2024 03:12:15 -0700 Subject: [PATCH 02/10] Reformat #1309 (#1329) * Updated URL for drand specification and various other links - corrected some links to drand code and specification - updated a sample API payload * Reformat with Prettier --------- Co-authored-by: PM <3749956+CluEleSsUK@users.noreply.github.com> Co-authored-by: smagdali --- content/libraries/drand/_index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/libraries/drand/_index.md b/content/libraries/drand/_index.md index 0ff7a285d..2f3b6f33d 100644 --- a/content/libraries/drand/_index.md +++ b/content/libraries/drand/_index.md @@ -29,6 +29,7 @@ By polling the appropriate endpoint (see below for specifics on the drand networ ```json { "round": 367, + "randomness": "3439d92d58e47d342131d446a3abe264396dd264717897af30525c98408c834f", "signature": "b62dd642e939191af1f9e15bef0f0b0e9562a5f570a12a231864afe468377e2a6424a92ccfc34ef1471cbd58c37c6b020cf75ce9446d2aa1252a090250b2b1441f8a2a0d22208dcc09332eaa0143c4a508be13de63978dbed273e3b9813130d5", "previous_signature": "afc545efb57f591dbdf833c339b3369f569566a93e49578db46b6586299422483b7a2d595814046e2847494b401650a0050981e716e531b6f4b620909c2bf1476fd82cf788a110becbc77e55746a7cccd47fb171e8ae2eea2a22fcc6a512486d" } @@ -36,6 +37,7 @@ By polling the appropriate endpoint (see below for specifics on the drand networ Specifically, we have: +- `Randomness` -- SHA256 hash of the signature - `Signature` -- the threshold BLS signature on the previous signature value `Previous` and the current round number `round`. - `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. @@ -69,7 +71,7 @@ endpoint. Thereafter, the Filecoin client can call drand's endpoints: - `/public/latest` to get the latest randomness value produced by the beacon -- `/public/` to get the randoomness value produced by the beacon at a given round +- `/public/` to get the randomness value produced by the beacon at a given round ## Using drand in Filecoin From c19737fa3c5bbea084e14010c803cfd3aad6b084 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Duarte?= Date: Wed, 30 Oct 2024 10:13:30 +0000 Subject: [PATCH 03/10] Fix typo in lifecycle.md (#1327) Co-authored-by: smagdali Co-authored-by: Ian Davis --- content/systems/filecoin_mining/sector/lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/systems/filecoin_mining/sector/lifecycle.md b/content/systems/filecoin_mining/sector/lifecycle.md index 2f056bfcb..f1e346019 100644 --- a/content/systems/filecoin_mining/sector/lifecycle.md +++ b/content/systems/filecoin_mining/sector/lifecycle.md @@ -15,7 +15,7 @@ In particular, as sectors of shorter lifetime are added, the networkʼs capacity It is reasonable to assume that miners enter the network by adding Committed Capacity sectors, that is, sectors that do not contain user data. Once miners agree storage deals with clients, they upgrade their sectors to Regular Sectors. Alternatively, if they find Verified Clients and agree a storage deal with them, they upgrade their sector accordingly. Depending on whether or not a sector includes a (verified) deal, the miner acquires the corresponding storage power in the network. -All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination can comes with a corresponding _termination fee_. +All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination comes with a corresponding _termination fee_. As with every system it is expected that sectors will present faults. Although this might degrade the quality offered by the network, the reaction of the miner to the fault drives system decisions on whether or not the miner should be penalized. A miner can recover the faulty sector, let the system terminate the sector automatically after 42 days of faults, or proactively terminate the sector immediately in the case of unrecoverable data loss. In case of a faulty sector, a small penalty fee approximately equal to the block reward that the sector would win per day is applied. The fee is calculated per day of the sector being unavailable to the network, i.e. until the sector is recovered or terminated. From 5f9ff4259d5cbdee6d5f5e5c3f84f02cfd3a7ad0 Mon Sep 17 00:00:00 2001 From: Haad Date: Wed, 30 Oct 2024 12:18:37 +0200 Subject: [PATCH 04/10] Fix a typo in Algorithms section (#1246) Fixes a small typo ("wining" -> "winning") Co-authored-by: smagdali --- 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 672bd7835..78997d59f 100644 --- a/content/algorithms/expected_consensus/_index.md +++ b/content/algorithms/expected_consensus/_index.md @@ -11,7 +11,7 @@ dashboardTests: 0 ## Algorithm -Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every epoch in which, on expectation, a set number of participants may be eligible to submit a block. EC guarantees that these winners will be anonymous until they reveal themselves by submitting a proof that they have been elected, the `ElectionProof`. Each winning miner can submit one such proof per round and will be rewarded proportionally to its power. From this point on, each wining miner also creates a proof of storage (aka Winning PoSt). Each proof can be derived from a [properly formatted beacon entry](randomness), as described below. +Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every epoch in which, on expectation, a set number of participants may be eligible to submit a block. EC guarantees that these winners will be anonymous until they reveal themselves by submitting a proof that they have been elected, the `ElectionProof`. Each winning miner can submit one such proof per round and will be rewarded proportionally to its power. From this point on, each winning miner also creates a proof of storage (aka Winning PoSt). Each proof can be derived from a [properly formatted beacon entry](randomness), as described below. All valid blocks submitted in a given round form a `Tipset`. Every block in a Tipset adds weight to its chain. The 'best' chain is the one with the highest weight, which is to say that the fork choice rule is to choose the heaviest known chain. For more details on how to select the heaviest chain, see [Chain Selection](expected_consensus#chain-selection). While on expectation at least one block will be generated at every round, in cases where no one finds a block in a given round, a miner can simply run leader election again for the next epoch with the appropriate random seed, thereby ensuring liveness in the protocol. From bf8956ec1eafddf7631471905fe0d06f0be84d6f Mon Sep 17 00:00:00 2001 From: Ian Davis Date: Thu, 31 Oct 2024 14:10:59 +0700 Subject: [PATCH 05/10] Update github workflows to use main branch (#1331) --- .github/workflows/main.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index e734bf95c..8da4afa95 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -3,10 +3,10 @@ name: CI on: push: branches: - - master + - main pull_request: branches: - - master + - main jobs: test: From b81d2f7b0b3193698adc432e0956622e8524e588 Mon Sep 17 00:00:00 2001 From: Ian Davis Date: Thu, 31 Oct 2024 14:57:42 +0700 Subject: [PATCH 06/10] Revery to master branch to fix fleek deploy (#1332) --- .github/workflows/main.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 8da4afa95..e734bf95c 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -3,10 +3,10 @@ name: CI on: push: branches: - - main + - master pull_request: branches: - - main + - master jobs: test: From 299077bce06b9512fe798350e4df8d2a217d0994 Mon Sep 17 00:00:00 2001 From: smagdali Date: Thu, 31 Oct 2024 15:09:29 +0700 Subject: [PATCH 07/10] various typoes and broken links (#1330) * fixed some broken links. * fixed drand verifier 404 * updated links to immutable blobs so line numbers don't drift * can't use a type as an embed symbol, only a func * typo fix --------- Co-authored-by: Ian Davis From fa9f455fe869bcaa667f185a4592b72aada5a751 Mon Sep 17 00:00:00 2001 From: Yiannis Psaras <52073247+yiannisbot@users.noreply.github.com> Date: Thu, 31 Oct 2024 10:20:55 +0200 Subject: [PATCH 08/10] fix(content): network baseline growth correction (#1245) * fixing numbers for network growth in baseline minting * Update _index.md --------- Co-authored-by: Ian Davis Co-authored-by: Ian Davis --- content/systems/filecoin_token/minting_model/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/systems/filecoin_token/minting_model/_index.md b/content/systems/filecoin_token/minting_model/_index.md index 60155f518..34f7fea22 100644 --- a/content/systems/filecoin_token/minting_model/_index.md +++ b/content/systems/filecoin_token/minting_model/_index.md @@ -18,7 +18,7 @@ To encourage consistent storage onboarding and investment in long-term storage, Specifically, a hybrid exponential minting mechanism is introduced with a proportion of the reward coming from simple exponential decay, “Simple Minting” and the other proportion from network baseline, “Baseline Minting”. The total reward per epoch will be the sum of the two rewards. Mining Filecoin should be even more profitable with this mechanism. Simple minting allocation disproportionately rewards early miners and provides counter pressure to shocks. Baseline minting allocation mints more tokens when more value for the network has been created. More tokens are minted to facilitate greater trade when the network can unlock a greater potential. This should lead to increased creation of value for the network and lower risk of minting filecoin too quickly. -The protocol allocates 30% of Storage Mining Allocation in Simple Minting and the remaining 70% in Baseline Minting. 30% of Simple Minting can provide counter forces in the event of shocks. Baseline capacity can start from a smaller percentage of worldʼs storage today, grow at a rapid rate, and catch up to a higher but still reasonable percentage of worldʼs storage in the future. As such, the network baseline will start from 1EiB (which is less than 0.01% of the worldʼs storage today) and grow at an annual rate of 200% (higher than the usual world storage annual growth rate at 40%). The community can come together to slow down the rate of growth when the network is providing 1-10% of the worldʼs storage. +The protocol allocates 30% of Storage Mining Allocation in Simple Minting and the remaining 70% in Baseline Minting. 30% of Simple Minting can provide counter forces in the event of shocks. Baseline capacity can start from a smaller percentage of worldʼs storage today, grow at a rapid rate, and catch up to a higher but still reasonable percentage of worldʼs storage in the future. The network baseline will start from **2.5EiB**, or **2.88888888EB**, (which is less than 0.01% of the worldʼs storage today) and grow at an annual rate of 100% (higher than the usual world storage annual growth rate at 40%). The community can come together to slow down the rate of growth when the network is providing 1-10% of the worldʼs storage. There are many features that will make passing the baseline more efficient and economical and unleash a greater share of baseline minting. The community can come together to collectively achieve these goals: From d2d835ff1d59457b53755bd9f59513de30ce3232 Mon Sep 17 00:00:00 2001 From: Mike Greenberg Date: Thu, 31 Oct 2024 04:56:36 -0400 Subject: [PATCH 09/10] fix: link to glossary term 'slashing' (#1272) Co-authored-by: smagdali Co-authored-by: Ian Davis --- content/glossary/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/glossary/_index.md b/content/glossary/_index.md index 5b622c9a7..ab7e7ef2f 100644 --- a/content/glossary/_index.md +++ b/content/glossary/_index.md @@ -377,7 +377,7 @@ Every mined block has a computed `weight`, also called its `WinCount`. Together, [_Window Proof-of-Spacetime_ (WindowPoSt)](post#windowpost) is the mechanism by which the commitments made by [storage miners](glossary#storage-miner-actor) are audited. It sees each 24-hour period broken down into a series of windows. Correspondingly, each storage miner's set of pledged [sectors](glossary#sector) is partitioned into subsets, one subset for each window. Within a given window, each storage miner must submit a [Proof-of-Spacetime](glossary#proof-of-spacetime-post) for each sector in their respective subset. This requires ready access to each of the challenged sectors, and will result in a [zk-SNARK-compressed](glossary#zksnark) proof published to the Filecoin [blockchain](glossary#blockchain) as a [message](glossary#message) in a [block](glossary#block). In this way, every sector of [pledged storage](glossary#pledged-storage) is audited at least once in any 24-hour period, and a permanent, verifiable, and public record attesting to each storage miner's continued commitment is kept. -The Filecoin network expects constant availability of stored data. Failing to submit WindowPoSt for a sector will result in a [fault](glossary#fault), and the storage miner supplying the sector will be [slashed](glossary#slash). +The Filecoin network expects constant availability of stored data. Failing to submit WindowPoSt for a sector will result in a [fault](glossary#fault), and the storage miner supplying the sector will be [slashed](glossary#slashing). ## Winning Proof-of-Spacetime (WinningPoSt) From 11169e5f1777024f0d2e2e6cce6f0f6efc9ed9e8 Mon Sep 17 00:00:00 2001 From: Nicolas Gailly Date: Thu, 31 Oct 2024 10:24:44 +0100 Subject: [PATCH 10/10] Update audit section with reports for SnarkPack (#1261) * Update audit section with reports for SnarkPack * Remove broken link to inaccessible security report * Prettier format * Fix husky pre-commit hook --------- Co-authored-by: Ian Davis --- content/appendix/audit_reports.md | 8 ++++++++ package.json | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/content/appendix/audit_reports.md b/content/appendix/audit_reports.md index c03051c9e..bf81591b1 100644 --- a/content/appendix/audit_reports.md +++ b/content/appendix/audit_reports.md @@ -55,6 +55,14 @@ This audit covers the implementation of Filecoin's builtin Actors, focusing on t ## Proofs +### `2021-05-31` SnarkPack audit + +An audit was conducted on the cryptographic part of [SnarkPack](https://eprint.iacr.org/2021/529.pdf), that is used in the [FIP0009](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0009.md): + +- [Report](https://hackmd.io/@LIRa8YONSwKxiRz3cficng/B105no8w_) from Matteo Campanelli, a well known cryptography [researcher](https://www.binarywhales.com/) + +One major issue was found in the report by Campanelli where the challenges of each prove commits were not tied to the aggregated proof; this could have led up to malicious miner forge valid aggregated proofs without the individual prove commits. The rest of the issues were of medium to informal severity. + ### `2020-10-20` Filecoin Bellman and BLS Signatures - Report: [**Filecoin Bellman/BLS Signatures Cryptography Review**](https://research.nccgroup.com/wp-content/uploads/2020/10/NCC_Group_ProtocolLabs_PRLB007_Report_2020-10-20_v1.0.pdf) diff --git a/package.json b/package.json index 6999df601..a18b949f5 100644 --- a/package.json +++ b/package.json @@ -35,7 +35,7 @@ "globby": "^11.0.1", "graphviz-cli": "^2.0.0", "hugo-extended": "^0.113.0", - "husky": ">=4", + "husky": "^4.3.8", "jsdom": "^22.1.0", "lint-staged": ">=10", "np": "^6.5.0",