├── .github ├── pull_request_template.md └── workflows │ ├── githublabeler.py │ ├── main.yml │ ├── requirements.txt │ ├── test.yml │ └── test_githublabeler.py ├── .gitignore ├── CODEOWNERS ├── Community Governance Calls └── README.md ├── FIPS ├── fip-0001.md ├── fip-0002.md ├── fip-0003.md ├── fip-0004.md ├── fip-0005.md ├── fip-0006.md ├── fip-0007.md ├── fip-0008.md ├── fip-0009.md ├── fip-0010.md ├── fip-0011.md ├── fip-0012.md ├── fip-0013.md ├── fip-0014.md ├── fip-0015.md ├── fip-0016.md ├── fip-0017.md ├── fip-0018.md ├── fip-0019.md ├── fip-0020.md ├── fip-0021.md ├── fip-0022.md ├── fip-0023.md ├── fip-0024.md ├── fip-0025.md ├── fip-0026.md ├── fip-0027.md ├── fip-0028.md ├── fip-0029.md ├── fip-0030.md ├── fip-0031.md ├── fip-0032.md ├── fip-0033.md ├── fip-0034.md ├── fip-0035.md ├── fip-0036.md ├── fip-0037.md ├── fip-0039.md ├── fip-0041.md ├── fip-0044.md ├── fip-0045.md ├── fip-0047.md ├── fip-0048.md ├── fip-0049.md ├── fip-0050.md ├── fip-0052.md ├── fip-0054.md ├── fip-0055.md ├── fip-0056.md ├── fip-0057.md ├── fip-0059.md ├── fip-0060.md ├── fip-0061.md ├── fip-0062.md ├── fip-0063.md ├── fip-0064.md ├── fip-0065.md ├── fip-0067.md ├── fip-0070.md ├── fip-0071.md ├── fip-0072.md ├── fip-0073.md ├── fip-0074.md ├── fip-0075.md ├── fip-0076.md ├── fip-0077.md ├── fip-0078.md ├── fip-0079.md ├── fip-0080.md ├── fip-0081.md ├── fip-0082.md ├── fip-0083.md ├── fip-0084.md ├── fip-0085.md ├── fip-0086.md ├── fip-0090.md ├── fip-0091.md ├── fip-0092.md ├── fip-0094.md ├── fip-0095.md ├── fip-0096.md ├── fip-0097.md ├── fip-0098.md ├── fip-0100.md ├── fip-0101.md ├── fip-0103.md └── fip-0106.md ├── FRCs ├── frc-0038.md ├── frc-0040.md ├── frc-0042.md ├── frc-0046.md ├── frc-0051.md ├── frc-0053.md ├── frc-0058.md ├── frc-0066.md ├── frc-0068.md ├── frc-0069.md ├── frc-0087.md ├── frc-0089.md ├── frc-0099.md └── frc-0102.md ├── FUNDING.json ├── README.md ├── mission.md ├── proposing.md ├── resources ├── fip-0019 │ └── SnapDeals-Theory_Report.pdf ├── fip-0029 │ └── ChangeBeneficiary-flow.png ├── fip-0030 │ ├── actor-execution.png │ └── technical-design.png ├── fip-0031 │ ├── revised-test-plan.jpg │ └── testnet-plan.jpg ├── fip-0036 │ └── SDM_Function.jpg ├── fip-0077 │ ├── recent_two_months.png │ └── total_in_use.png ├── fip-0081 │ ├── gradual_activation_rationale.pdf │ ├── macro.png │ ├── micro.png │ └── ramped_activation_gamma.png ├── fip-0082 │ ├── SDM_Function.png │ ├── supersnap_gas_32gib.png │ └── supersnap_gas_64gib.png ├── fip-0086 │ ├── chain.png │ ├── flow.png │ ├── fork.png │ ├── gossipbft_implementation_of F3_v2.pdf │ ├── gossipbft_message_rebroadcast_v3.pdf │ └── merkletree.go ├── fip-0090 │ ├── NIPoRep_CostAnalysis.pdf │ ├── PoRep_GasComparison.pdf │ ├── benchmarks.pdf │ ├── interactionRemoval.pdf │ └── readme.md ├── fip-0100 │ ├── CS_basedFees_with_cap.png │ ├── br-based-fee-evolution_expanded.png │ ├── br-based-fee-multiplier-function.jpg │ ├── cs-based-fee-evolution.png │ ├── fip0100Appendix.md │ └── network_state_evolution.jpg ├── frc-0051 │ ├── Create Epoch boundary attack on EC with CBcast.md │ ├── Different Proposals to Improve Filecoin's consensus.md │ ├── gossipsub_delay_filtered.ipynb │ └── sec_analysis.pdf ├── frc-0089 │ ├── err_prob_and_block_count_march.png │ ├── err_prob_and_block_count_november.png │ └── theory.pdf └── frc-0102 │ └── user-stories.md └── templates └── template.md /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | ## Are you drafting a new FIP? 2 | Please follow these guidelines to help ensure that your proposal is set up for success in the governance process. 3 | 4 | ### Open a discussion topic 5 | Changes to the Filecoin core protocol proceed through open discussion. 6 | Please open a new discussion topic in the FIPs repository discussion board and outline you motivation and proposal. 7 | 8 | The FIP format is suitable for specifying a concrete protocol change for implementation, 9 | but your discussion post should describe more of the background and problem to be solved, 10 | outline a range of approaches and their tradeoffs, and invite participants to explore other solutions. 11 | 12 | Historically, failing to gain some community buy-in before submitting a FIP has often resulted in 13 | rejected FIPs and much wasted effort. 14 | 15 | ### Please use the template 16 | Please draft your FIP by starting with an appropriate template file from templates directory. 17 | Do not significantly change the header table format or section headings. 18 | 19 | ### Don't claim a FIP number 20 | FIP numbers are allocated by the FIP editors when a draft is ready to be merged into the master branch. 21 | The editors coordinate to ensure allocations to in-flight drafts don't collide. 22 | Please do not allocate yourself a FIP number. 23 | 24 | Name your file `fip-my_draft_title.md` (replacing the suffix with an abbreviated title) 25 | and leave "to be assigned" for the FIP number in the header table. 26 | A FIP editor will either inform you of the appropriate number, or insert it themselves when merging. 27 | 28 | ### Please add your FIP to the README 29 | The top-level README.md file contains a table of all FIPs. 30 | Please add yours there in the same PR that adds the FIP draft itself. 31 | Use XXXX for the FIP number until it is assigned by an editor. 32 | 33 | ### Delete this guidance and describe your FIP 34 | Once you've followed the guidance above and are ready to submit your FIP draft, 35 | please delete this text and replace it with a copy of the _Abstract_ from your draft, 36 | and a link to the relevant discussion forum topic. -------------------------------------------------------------------------------- /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | name: run githublabeler.py 2 | 3 | on: 4 | schedule: 5 | - cron: "5 * * * *" 6 | 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: checkout repo content 13 | uses: actions/checkout@v3 # checkout the repository content 14 | 15 | - name: setup python 16 | uses: actions/setup-python@v4 17 | with: 18 | python-version: '3.11' # install the python version needed 19 | 20 | - name: install python packages 21 | run: | 22 | python -m pip install --upgrade pip 23 | cd .github/workflows 24 | pip install -r "requirements.txt" 25 | 26 | 27 | 28 | - name: execute py script # run githublabeler.py 29 | env: 30 | GITHUB_TOKEN: ${{ secrets.FILECOIN_GOVERNANCE_BOT_TOKEN }} 31 | run: python .github/workflows/githublabeler.py 32 | -------------------------------------------------------------------------------- /.github/workflows/requirements.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/.github/workflows/requirements.txt -------------------------------------------------------------------------------- /.github/workflows/test.yml: -------------------------------------------------------------------------------- 1 | name: Test githublabeler.py 2 | 3 | on: 4 | pull_request: 5 | branches: 6 | - master 7 | 8 | 9 | jobs: 10 | build: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: checkout repo content 14 | uses: actions/checkout@v3 # checkout the repository content 15 | 16 | - name: setup python 17 | uses: actions/setup-python@v4 18 | with: 19 | python-version: '3.11' # install the python version needed 20 | 21 | - name: install python packages 22 | run: | 23 | python -m pip install --upgrade pip 24 | cd .github/workflows 25 | pip install -r "requirements.txt" 26 | 27 | 28 | 29 | - name: test py script # run pytest 30 | run: | 31 | cd .github/workflows 32 | pytest 33 | -------------------------------------------------------------------------------- /.github/workflows/test_githublabeler.py: -------------------------------------------------------------------------------- 1 | import githublabeler 2 | import pytest 3 | from datetime import datetime, timezone 4 | 5 | FAKE_ID = 'fakeID' 6 | 7 | activeDiscussionPosts = [{'id': FAKE_ID, # active because of lastEditedAt only 8 | 'createdAt': '2022-06-01T22:42:26Z', 9 | 'lastEditedAt': '2023-06-01T22:42:26Z', 10 | 'comments': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 11 | 'updatedAt': '2022-06-01T22:42:26Z', 12 | 'replies': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 13 | 'updatedAt': '2022-06-01T22:42:26Z'}]}}]}}, 14 | {'id': FAKE_ID, # active because of comments only 15 | 'createdAt': '2022-06-01T22:42:26Z', 16 | 'lastEditedAt': '2022-06-01T22:42:26Z', 17 | 'comments': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 18 | 'updatedAt': '2023-06-01T22:42:26Z', 19 | 'replies': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 20 | 'updatedAt': '2022-06-01T22:42:26Z'}]}}]}}, 21 | {'id': FAKE_ID, # active because of comment reply only 22 | 'createdAt': '2022-06-01T22:42:26Z', 23 | 'lastEditedAt': '2022-06-01T22:42:26Z', 24 | 'comments': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 25 | 'updatedAt': '2022-06-01T22:42:26Z', 26 | 'replies': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 27 | 'updatedAt': '2023-06-01T22:42:26Z'}]}}]}}] 28 | 29 | quietDiscussionPosts = [{'id': FAKE_ID, 30 | 'createdAt': '2022-06-01T22:42:26Z', 31 | 'lastEditedAt': '2022-06-01T22:42:26Z', 32 | 'comments': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 33 | 'updatedAt': '2022-06-01T22:42:26Z', 34 | 'replies': {'nodes': [{'createdAt': '2022-06-01T22:42:26Z', 35 | 'updatedAt': '2022-06-01T22:42:26Z'}]}}]}}] 36 | 37 | newDiscussionPosts = [{'id': FAKE_ID, 38 | 'createdAt': '2023-06-01T22:42:26Z', 39 | 'lastEditedAt': '2023-06-01T22:42:26Z', 40 | 'comments': {'nodes': [{'createdAt': '2023-06-01T22:42:26Z', 41 | 'updatedAt': '2023-06-01T22:42:26Z', 42 | 'replies': {'nodes': [{'createdAt': '2023-06-01T22:42:26Z', 43 | 'updatedAt': '2023-06-01T22:42:26Z'}]}}]}}] 44 | 45 | 46 | def test_isActive(): 47 | now = datetime.fromisoformat("2023-06-14T17:39:37Z") 48 | for d in activeDiscussionPosts: 49 | assert githublabeler.isActive(d, now) 50 | 51 | for d in quietDiscussionPosts: 52 | assert githublabeler.isActive(d, now) == False 53 | 54 | 55 | def test_getUpdates(): 56 | now = datetime.fromisoformat("2023-06-14T17:39:37Z") 57 | assert githublabeler.getUpdates(quietDiscussionPosts, now) == [{ 58 | 'id': FAKE_ID, 59 | 'add': [ 60 | githublabeler.QUIET_LABEL], 'remove': [ 61 | githublabeler.NEW_LABEL, githublabeler.ACTIVE_LABEL] 62 | }] 63 | assert githublabeler.getUpdates(activeDiscussionPosts, now) == [{ 64 | 'id': FAKE_ID, 65 | 'add': [ 66 | githublabeler.ACTIVE_LABEL], 'remove': [ 67 | githublabeler.NEW_LABEL, githublabeler.QUIET_LABEL] 68 | }, { 69 | 'id': FAKE_ID, 70 | 'add': [ 71 | githublabeler.ACTIVE_LABEL], 'remove': [ 72 | githublabeler.NEW_LABEL, githublabeler.QUIET_LABEL] 73 | }, { 74 | 'id': FAKE_ID, 75 | 'add': [ 76 | githublabeler.ACTIVE_LABEL], 'remove': [ 77 | githublabeler.NEW_LABEL, githublabeler.QUIET_LABEL] 78 | }] 79 | assert githublabeler.getUpdates(newDiscussionPosts, now) == [{ 80 | 'id': FAKE_ID, 81 | 'add': [ 82 | githublabeler.NEW_LABEL, githublabeler.ACTIVE_LABEL], 'remove': [ 83 | githublabeler.QUIET_LABEL] 84 | }] 85 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | node_modules 3 | vendor/ 4 | __pycache__ 5 | .venv 6 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @jennijuju @anorth @jsoares @TippyFlitsUK @momack2 @rvagg @lanzafame @dannyob 2 | -------------------------------------------------------------------------------- /Community Governance Calls/README.md: -------------------------------------------------------------------------------- 1 | # Monthly Community Governance Calls 2 | 3 | **Introduction** 4 | 5 | The monthly governance call (GovCall) is an open forum for Filecoin community members to come together and discuss important issues and initiatives related to the governance of the Filecoin Network. 6 | 7 | The meeting provides an opportunity for open communication and collaboration, as well as a space for community members to voice their concerns and ideas. The monthly meeting will also be a place to share governance best practices and hear from governance practitioners and experts. 8 | 9 | In addition, the governance team at Filecoin Foundation will; 10 | * Provide updates and overview of current FIPs; 11 | * Status of FIPs; 12 | * Discussions around network upgrades. 13 | 14 | **Objectives** 15 | Objectives of GovCall include: 16 | 17 | * To provide a forum for community members to discuss, engage address governance -related topics, including the processes and practices of governance (aka metagovernance); 18 | * To promote open communication and collaboration among community members, and; 19 | * To gather and share information about ongoing FIPs, Network Upgrades and FIPs pipeline/roadmap. 20 | 21 | --- 22 | **Timeline** 23 | GovCall is held on the last Monday of every month at 3:00 PM ET. The meeting lasts for approximately one hour. 24 | 25 | **Standard Agenda** 26 | The agenda for each monthly meeting can be as follows: 27 | 28 | 1. *Introduction and welcome* 29 | 1. *Update on FIPs status (Draft, Last call, Accepted)* 30 | 1. *Governance presentation/Talks* 31 | 1. *Open forum for QnA* 32 | 1. *Closing* 33 | 34 | Please note that the agenda is flexible. If community members would like to propose a topic for discussion, they can do so by commenting on the agenda or proposing a topic in #fil-fips on Filecoin Community Slack. 35 | 36 | **Participants** 37 | All community members are welcome to attend the monthly community governance meeting. 38 | 39 | **Meeting Registration** 40 | GovCall is held virtually on Zoom. Please download the Governance Call calendar below so you can be updated when there are changes to dates or times for the calls. 41 | 42 | https://calendar.google.com/calendar/embed?src=c_909343f97c15e8f23dda6e2612e62fcdee14bceabd8869abe4a52d793bf42b98%40group.calendar.google.com&ctz=America%2FToronto 43 | 44 | 45 | **Notetaking and Recording:** 46 | Monthly calls are recorded and recording shared with community members as well as recorded below. 47 | 48 | **Access** 49 | Details about the call including all resources, notes, agenda etc are openly recorded and maintained in the GovCall folder within the FIPs repo. 50 | 51 | 52 | 53 | **Meeting recordings** 54 | 55 | | No | Date | Recording | Passcode | 56 | | --- | ---- | --------- | -------- | 57 | | 1 | March 27, 2023 | [Recording](https://fil-org.zoom.us/rec/share/fLp_p8KlbvasrWEK795BTjJ0_sy5qwNhtKsf0sOq973zVEnbW39TbT3KWbK0wuWn.Ai4lNDLBsMJbonWs) | 90wr.#wh | 58 | | 2 | April 24, 2023 | [Recording](https://fil-org.zoom.us/rec/share/JFGDiDU1By9kFTZuT3eFecFX0bk_-VdTaNZdjSf-8TRzbEilYbuvrguAM3sSKGM2.vPf4KlhScZVd1Qko) | pg.7@M5s | 59 | | 3 | June 5, 2023 | [Recording](https://fil-org.zoom.us/rec/share/2ta_8RrWFMs8gagcTDWKZ0Za9-Ahrtj_kgc7Cvvk7vFiUC3IA8fuZUHiYwx-UVCJ.oD1vBqZAMW1U3Wap) | =Tq40#GV | 60 | | 4 | June 26, 2023 | [Recording](https://fil-org.zoom.us/rec/share/aBjaGcQml6w1OKC92ffDi15lJT_bqPUx--_8b4BhqWBNBy0r2YsYPfHOB4tTcT_Y.T2d2Ag85CasVWZXy?startTime=1687806180000) | !T2??aUV | 61 | | 5 | July 31, 2023 | [Recording](https://fil-org.zoom.us/rec/share/TMZ1-rz-qpYKE-i169QBIpFRcnEaMNQJR9b-WD0eWxeSJJLV7WXGtvoqoCQg5HL1.sRPAURxzIA01sKPP?startTime=1690830085000) | y9RX?iE! | 62 | | 6 | October 2, 2023 | [Recording](https://fil-org.zoom.us/rec/share/R7bdb6GrAxieFk6ZR9Ucpj3VQthVdMKj_IX99fS16rlAcnyeOW38aemDk-IHlnqF.AwDB7c6tMF3HsLZ9) | w0ednU=# | 63 | | 7 | October 30, 2023 | [Recording](https://fil-org.zoom.us/rec/share/X2IG863y947Zq51kngOkv87rr-KyFKak8T0a346NAY87VvIv8eb5ruOXOl2_QZlW.fI1BXVJyCXfMVcPt) | B8TP#gF. | 64 | | 8 | December 5, 2023 | [Recording](https://fil-org.zoom.us/rec/share/I-XooIurZcsKqvQf_XWtiaAMooLNffCPdUx1DaWBvSyybc7omHbTX7FLTda6dEme.92JfPEgoelAQDpYo) | uzy5!Z6R | 65 | | 9 | January 29, 2024 | [Recording](https://fil-org.zoom.us/rec/share/-PqMbwsc0vz9n2sfI5nl_qUwwthVj0pBDmTwx2Qf8Qxd58j_HL7rE7s7-puloNEL.d7ETjuKwtkRxyRMJ) | 1W&DM12^ | 66 | | 10 | February 26, 2024 | [Recording](https://fil-org.zoom.us/rec/share/CMs0lD_Nk4xw31cb3aC63rl50SMIMJxA1HxdUvE2GkBauseDYBIegxaYECDllwuO.L-t0cC-Kh22Hz7d8) | W*!kAy8= | 67 | | 11 | March 25, 2024 | [Recording](https://fil-org.zoom.us/rec/share/CKKSDTu9ZL67HFwmbLjF3sL8Z46qWhcNVJ0hApOnreaCw9NeU3MWABLNa83U7nI.kl-iOw5kz5ZdZtc2) | K&E#2VYt | 68 | | 12 | April 29, 2024 | [Recording](https://fil-org.zoom.us/rec/share/KxkexHCQZfpUmaMf3tVK18r1Us_9IUhD4FttflHGQyv6OVM61zCs8r6wHBSgMpKQ.o9ZkP_x0SIoymBm6) | Kn^=R1cv | 69 | | 13 | June 24, 2024 | [Recording](https://fil-org.zoom.us/rec/share/_0npn_ZbYYiMGjiouvaQME59HGEGwkpODbCFSUNATBlJs35gP5hAbwQk3zZroHWG.R8JhWhFzZswjWUx1) | e#Wv3gz3 | 70 | | 14 | August 5, 2024 | [Recording](https://fil-org.zoom.us/rec/share/q9TsJGZZQKLXbnJk_xLvqDvaXitYH_uAD1sRjQCjvlxZfKI_zfjBnVCvAVOxYvHY.ng1kg5lnKSWdjblH?startTime=1722888309000) | N%6#FhL% | -------------------------------------------------------------------------------- /FIPS/fip-0004.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0004" 3 | title: Liquidity Improvement for Storage Miners 4 | author: davidad (@davidad), jbenet (@jbenet), zenground0 (@zenground0), ZX (@zixuanzh), danilo (@danlessa) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/14 6 | status: Final 7 | type: Technical 8 | --- 9 | 10 | # FIP-0004: Liquidity Improvement for Storage Miners 11 | 12 | ## Simple Summary 13 | 14 | * Make 25% of storage-mining rewards immediately available with no vesting. 15 | 16 | ## Abstract 17 | This proposal allows a substantial fraction of block rewards to be immediately available for withdrawal to allow for greater liquidity and decision freedom for storage miners. The majority of mining rewards continue to vest over 180 days as collateral to reduce initial pledge, to align long-term incentives, and to guarantee storage reliability. 18 | 19 | ## Problem Motivation 20 | All rewards on Filecoin go through a linear vesting schedule of 180 days to encourage miners to consider utility creation besides speculation, to provide space and time for onboarding real use cases onto the network, and to be incentive-aligned with the network long-term. However, a 6-month vesting schedule could be a heavy cashflow burden. 21 | 22 | ## Specification 23 | In ApplyRewards of MinerActor, 24 | * Currently: all rewards go through RewardVestingSpec and all rewards get added to pledgeDeltaTotal. 25 | * Proposed: 75% of rewards go through RewardVestingSpec and only 75% rewards get added to pledgeDeltaTotal. 26 | 27 | ## Design Rationale 28 | The rationale for the specification is to achieve the goals and desired behavior with minimal code changes (conditional checks and parameter updates). Note that 25% of reward will become immediately withdrawable unless the miner is in FeeDebt. In that case, a portion of the 25% of unlocked reward will automatically be applied to recovering the FeeDebt - so the miner’s balance will increase by the amount unclaimed by FeeDebt. 29 | 30 | ## Backwards Compatibility 31 | This proposal does not require changes to the state schema of any actor, nor method parameter or return values . Thus it can take effect as a behaviour change triggered after a specific upgrade epoch. 32 | 33 | ## Test Cases 34 | N/A 35 | 36 | ## Implementation 37 | - Dependency PR: https://github.com/filecoin-project/go-state-types/pull/16 38 | - Actors PR (WIP): https://github.com/filecoin-project/specs-actors/pull/1249 39 | 40 | ## Security Considerations 41 | There were security concerns that block reward should only start vesting after one day to mitigate certain malicious strategies. However, this cost would be shouldered by all storage miners in the network. Given the security concern level of the attack and the significant UX improvement of making rewards immediately available, 25% block rewards will still be immediately available and the remaining will vest over 6 months. It is possible that this will be addressed by another FIP in the future. 42 | 43 | ## Incentive Considerations 44 | Allowing some portion of the block reward to be immediately available increases the risk that miners break away from the lifetime promise of their sectors due to volatile price trajectory or other opportunities. However, this is a tradeoff that the protocol can make to improve cash flow and profitability for miners. It also provides more degree of freedom for storage miners to reinvest into the network. The majority of earned block rewards are still vesting over 6 months to ensure that incentives are aligned. 45 | 46 | ## Product Considerations 47 | Despite an increased risk of miners not fulfilling their sector lifetime promise and dropping sectors early, penalties for dropping sectors have not decreased. Overall, improved profitability and liquidity should lead to better outcomes for the network and allow for greater storage miners diversity. 48 | 49 | ## Copyright 50 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 51 | -------------------------------------------------------------------------------- /FIPS/fip-0005.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0005" 3 | title: Remove ineffective reward vesting 4 | author: Alex North (@anorth), @Zenground 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/18 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2020-10-22 10 | --- 11 | 12 | # FIP-0005: Remove ineffective reward vesting 13 | 14 | ## Simple Summary 15 | Remove the processing of miner reward vesting from `PreCommitSector` and `ConfirmSectorProofsValid`, because it's expensive and doesn't achieve much. 16 | 17 | ## Abstract 18 | Remove expensive calculation of miner reward vesting from the `PreCommitSector` and `ConfirmSectorProofsValid` methods, leaving it to the deadline cron. 19 | This will reduce the gas consumption of these methods substantially, freeing up chain bandwidth and reducing costs. 20 | 21 | ## Change Motivation 22 | Chain bandwidth is a valuable resource, necessary for both critical network operations and product use. 23 | Avoiding frequent and high-gas-cost operations reduces contention, costs, and chain validation latency. 24 | 25 | Processing reward vesting is quite expensive as it loads and stores a sizeable array for the vesting table. 26 | For high-scale miners, committing many sectors per deadline (or even per-epoch), this represents a sizeable portion of total gas cost and chain bandwidth consumption. 27 | 28 | ## Specification 29 | Remove the invocations of `State.UnlockVestedFunds` from `PreCommitSector` and `ConfirmSectorProofsValid`. 30 | 31 | ## Design Rationale 32 | Reward vesting is computed via `State.UnlockVestedFunds`, which is called from `PreCommitSector`, `ConfirmSectorProofsValid`, `WithdrawBalance` and the deadline cron handler. 33 | The original motivation for computing vesting on sector commitment is so that any vested funds could be used for the pre-commit deposit or pledge. 34 | 35 | The vesting table is quantized to 12-hr increments. 36 | Since vesting is processed in the deadline cron every 30 minutes regardless, a call during sector commitment almost always achieves nothing. 37 | The most it could achieve is to accelerate a release by 30 minutes. 38 | 39 | A miner operator wishing to process vesting manually, ahead of the per-deadline cron call, could do so by calling `WithdrawFunds` with an amount of zero. 40 | Such a call would require use of the miner's Owner address. 41 | 42 | ## Backwards Compatibility 43 | This change must be implemented along with an increment to the runtime's network version number. It will only take effect after a designated upgrade epoch. 44 | 45 | This proposal does not require changes to the state schema of any actor, nor method parameter or return values. 46 | 47 | ## Test Cases 48 | N/A 49 | 50 | ## Security Considerations 51 | None. 52 | 53 | ## Incentive Considerations 54 | This proposal changes incentives only marginally. 55 | 56 | It may delay the use of recently-vested rewards for new pre-commit deposits or pledges, leading to incentive to hold slightly more working balance in a miner actor. 57 | Similarly, it may incentivize use of the `WithdrawFunds` method in order to accelerate the release of vested funds. 58 | 59 | ## Product Considerations 60 | This proposal will decrease contention for chain transaction throughput, generally making use of the Filecoin blockchain cheaper. 61 | 62 | ## Implementation 63 | 64 | Implemented in specs-actors in https://github.com/filecoin-project/specs-actors/pull/1276, introduced to the network in [Lotus v1.2.0](https://github.com/filecoin-project/lotus/releases/tag/v1.2.0) at epoch 265200. 65 | 66 | ## Copyright 67 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 68 | -------------------------------------------------------------------------------- /FIPS/fip-0006.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0006" 3 | title: No repay debt requirement for DeclareFaultsRecovered 4 | author: Nicola (@nicola), Irene (@irenegia) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/21 6 | status: Deferred 7 | type: Technical 8 | created: 2020-10-23 9 | --- 10 | 11 | # FIP-0006: No repay debt requirement for DeclareFaultsRecovered 12 | 13 | ## Simple Summary 14 | Remove the requirement to repay debt from DeclareFaultsRecovered. 15 | 16 | ## Abstract 17 | Filecoin miners are subject to pay storage fault and consensus fault fees. These are paid using locked funds (ie, unvested block rewards) and then the miner’s available balance. If these two are not enough to cover the total fee amount, the remaining part to pay is recorded in a variable (FeeDebt) in the miner’s state and the miner is declared “in fee debt”. 18 | For a miner in debt, the call to the methods PreCommit, DeclareFaultsRecovered and WithdrawBalance fails. Moreover this miner can not mine blocks. 19 | The fact that a miner in debt can not recover faults creates an undesired loop situation, in which a miner with faulted partitions can not recover, keep increasing its debt (note that continued faults cause more fees), eventually leading to sector termination if the miner does not repay their debt after 14 days. This is especially bad for small miners with little balance. To avoid this we propose to allow recovery of faults for miners in debt. 20 | 21 | ## Problem Motivation 22 | In the current protocol, recovering faults is not allowed if a miner is in debt (ie, the call to the method “DeclareFaultsRecovered” fails when feeDebts > 0). This can create the following problem: 23 | A miner misses the windowPoSt deadline for some partition for 2 days; 24 | This causes paying storage fault fee and the miner could go in debt; 25 | If it does, the miner can not recover the faulted partitions without obtaining the funds to pay back the debt first and the debt will continue to increase. 26 | 27 | 28 | ## Specification 29 | Remove the call to RepayDebtOrAbort in the method “DeclareFaultsRecovered”; 30 | In other words, no check about the FeeDebt variable is required in the method “DeclareFaultsRecovered”. 31 | Diff from current version: remove the following line of code in the miner actor 32 | https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/miner/miner_actor.go#L1322. 33 | 34 | 35 | ## Design Rationale 36 | The main motivation for this change is introducing the minimal change that allows miners in debt to recover storage faults in order to stop paying for penalties. 37 | 38 | ## Backwards Compatibility 39 | This change requires a network version increment to distinguish the old behaviour from the new. It does not change any state schemas or exported method signatures. 40 | 41 | ## Test Cases 42 | N/A 43 | 44 | ## Implementation 45 | Remove the following line of code in the miner actor 46 | https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/miner/miner_actor.go#L1322. 47 | 48 | 49 | ## Security Considerations 50 | After this change, a miner in fee debt continues to not be able to produce new blocks or withdraw tokens from its available balance, so the possible actions and strategies for malicious miners are the same as in the current version of the protocol. In particular, a miner that does not recover from debt (ie, a miner that does not pay its fees) cannot make profit from the power registered in the power table because it is not eligible to mine blocks. 51 | Miners that recover their faults are still not eligible until they recover from fee debt, this means that their power will still count towards the total power, and the average WinCount is reduced. Although this is not a new problem, this change could worsen the potential power inflation. We do not believe this is a risk for the protocol and this problem should be addressed separately with a new FIP (e.g., possible options for this are (1) allowing miners in debt to mine blocks or (2) remove the power of miners in debt from the power table). 52 | 53 | ## Incentive Considerations 54 | After this change, a miner in fee debt continues to be incentivized to repay its debt asap since otherwise it can not win block reward. It allows miners to stop paying for fault penalties if they can recover their sectors early without having the urgent need to acquire tokens or incur more penalties. 55 | 56 | ## Product Considerations 57 | In the event of a miner going into debt but being able to recover quickly, debt does not increase based on the miner's ability to repay their debt quickly but only depends on storage maintenance. This FIP maintains a strong incentive to recover from faults (no storage growth or block rewards) but also avoid putting miners in a situation where their debt keeps increasing due to their inability to access liquidity in a timely fashion. 58 | 59 | 60 | ## Copyright 61 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 62 | -------------------------------------------------------------------------------- /FIPS/fip-0007.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0007" 3 | title: h/amt-v3 4 | author: Rod Vagg (@rvagg), Steven Allen (@Stebalien), Alex North (@anorth), Zen Ground0 (@Zenground0) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/38 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2020-11-27 10 | specs-sections: 11 | - section-appendix.data_structures.hamt 12 | 13 | --- 14 | 15 | # FIP-0007: h/amt-v3 16 | 17 | ## Simple Summary 18 | 19 | 20 | Improve the filecoin HAMT and AMT in terms of performance and safety with three smaller independent proposals. 21 | 22 | ## Abstract 23 | 24 | The filecoin HAMT does unnecessary Puts and Gets while doing Set and Find operations. Sub proposal `A` eliminates these unnecessary operations improving performance of HAMT calls. 25 | 26 | The filecoin HAMT's pointer serialization can be modified to save 3 bytes and a small amount of de/encode time. Sub proposal `B` describes the more efficient serialization. 27 | 28 | The filecoin AMT does unnecessary Puts and Gets while doing Set, Find and ForEach operations. Sub proposal `C` eliminates these unnecessary operations improving performance of AMT calls. 29 | 30 | ## Change Motivation 31 | 32 | These are all unambiguous performance wins. We aren't trading anything off we are strictly reducing ipld operations and serialization size which also corresponds to reduced gas cost. 33 | 34 | ## Specification 35 | 36 | 37 | ### A 38 | The existing HAMT loads child tree nodes into in memory cache nodes located on HAMT "link" pointers (not KV pointers). It also clears these cache nodes after writing them to disk during the Flush operation. Finally the current HAMT code writes to the blockstore when it creates new node during bucket overflow as part of setting new values. 39 | 40 | This proposal is to (1) track modification of nodes and only Flush these caches to the blockstore when the cache node has been modified (2) stop clearing cache nodes on Flush (3) Move all blockstore writes to occur on Flush. 41 | 42 | Concretely (1) can be achieved by adding a `dirty` flag as a sibling to the cache node on the HAMT pointer. The flag defaults to false when a cache node is loaded for reading and set to true if a set or delete operation traverses through that node and modifies that node or one of its children. Then during the Flush traversal, a cache node is written to the blockstore and its owning Pointer's Link field assigned to the cid of cache node only if the dirty flag is true at the time of Flush. Otherwise the cache node is skipped. 43 | 44 | To achieve (2) implementations only need to stop clearing the cache nodes after flushing pointers during Flush. 45 | 46 | Finally for (3) implementations can simply add a new cache node when creating a new child node during bucket overflow and mark this node as dirty so that it gets written during the next flush. 47 | 48 | See go-hamt-ipld implementation [here](https://github.com/filecoin-project/go-hamt-ipld/pull/74) for a concrete example. Note that the part of this specification that avoids marking nodes as dirty during Set operations that overwrite an unchanged value to a key is being implemented separately [here](https://github.com/filecoin-project/go-hamt-ipld/pull/77#discussion_r532044992). 49 | 50 | ### B 51 | HAMT pointers are union types. A pointer can be one of a link to a HAMT node or a KV bucket containing HAMT key value pairs. To achieve this pointers are currently serialized as a cbor map with at most one key. A key of "0" means link, a key of "1" means bucket. 52 | 53 | This proposal is to only serialize the link or bucket of kvs and use the different cbor major types (tag major type or array major type) to distinguish which type populates the union on decode. 54 | 55 | Succinctly from @rvagg, this proposal is to change from: 56 | ``` 57 | type Pointer union { 58 | &Node "0" 59 | Bucket "1" 60 | } representation keyed 61 | ``` 62 | i.e. `{"0": CID}` or `{"1": [KV...]}` 63 | 64 | to: 65 | ``` 66 | type Pointer union { 67 | &Node link 68 | Bucket list 69 | } representation kinded 70 | ``` 71 | i.e. `CID` or `[KV...]` 72 | 73 | See @rvagg's original proposal in go-hamt-ipld [here](https://github.com/filecoin-project/go-hamt-ipld/issues/53#issue-663418352) and the open PR implementing this in go-hamt-ipld [here](https://github.com/filecoin-project/go-hamt-ipld/pull/60) for more information. 74 | 75 | ### C 76 | This proposal is analagous to sub proposal A except on the AMT instead of the HAMT. Implementation is [here](https://github.com/filecoin-project/go-amt-ipld/pull/30). Additionally the proposal includes rearranging order of load during `ForEach` traversals that do not walk all keys to only load child nodes if they contain keys within the traversal range. See implementation [here](https://github.com/filecoin-project/go-amt-ipld/pull/37/files) for full details. 77 | 78 | ## Design Rationale 79 | 80 | These designs follow directly from understanding the inefficiencies of the current HAMT. They have only not been introduced sooner because they are breaking changes and carry implementation risk. 81 | 82 | ## Backwards Compatibility 83 | 84 | ### A & C 85 | These changes are consensus breaking because they reduces the gas cost of HAMT Set and Find operations and AMT Set, Find and ForEach operations . So running HAMT and AMT code with this feature will not result in the same state transitions as in the existing protocol. Therefore this change requires a network version update. 86 | 87 | ### B 88 | This change requires modifying the serialized bytes of all HAMT nodes. This will require a state tree migration migrating all HAMT data. 89 | 90 | ## Test Cases 91 | 92 | Test cases are / will be accompanying implementation 93 | 94 | ## Security Considerations 95 | All significant implementation changes carry risk. On their own each sub proposal is a simple well understood change. Increased HAMT tests as well as existing validation practices are expected to be sufficient safeguards. 96 | 97 | ## Incentive Considerations 98 | On the whole this change should directly and indirectly decrease both real validation time and state storage cost as well as gas cost while otherwise maintaining the same behavior. It should be incentive compatible to accept this change for all parties in the network. It should not introduce changes to the protocol's incentive structure. 99 | 100 | ## Product Considerations 101 | This change should directly and indirectly decrease the costs of state machine operations. This will not change any aspect of the network as a product other than the positive impacts of improved performance of existing behavior. 102 | 103 | ## Implementation 104 | Sub proposal A implemented and optimistically merged to go-hamt-ipld [here](https://github.com/filecoin-project/go-hamt-ipld/pull/74) 105 | 106 | Sub proposal B implemented and optimistically merged in go-hamt-ipld [here](https://github.com/filecoin-project/go-hamt-ipld/pull/60) 107 | 108 | Sub proposal C implemented and optimistically merged in go-amt-ipld [here](https://github.com/filecoin-project/go-amt-ipld/pull/30) and [here](https://github.com/filecoin-project/go-amt-ipld/pull/37) 109 | -------------------------------------------------------------------------------- /FIPS/fip-0009.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0009" 3 | title: Exempt Window PoSts from BaseFee burn 4 | author: Steven Allen (@stebalien), Molly Mackinlay (@momack2), Łukasz Magiera (@magik6k), Zixuan Zhang (@zixuanzh) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/52 6 | status: Superseded 7 | superseded-by: "0015" 8 | type: Technical 9 | category: Core 10 | created: 2020-12-15 11 | updated: 2024-09-06 12 | spec-sections: 13 | - section-systems.filecoin_vm.gas_fee 14 | --- 15 | 16 | # FIP-0009: Exempt Window PoSts from BaseFee burn 17 | 18 | ## Simple Summary 19 | 20 | Exempt direct `SubmitWindowedPoSt` messages that execute successfully from base-fee burn (i.e., don't burn `baseFee*gasUsed`). 21 | 22 | ## Abstract 23 | 24 | If a miner sends a direct on-chain message to a miner actor's "SubmitWindowedPoSt" method, and the message executes successfully, immediately "refund" all the burned gas, instead of just refunding the overestimation. However, overestimation penalties, gas premium, etc. still apply. 25 | 26 | ## Change Motivation 27 | 28 | This proposal is a short-term stopgap to reduce the impact of rising base fee on continuously proving existing storage. In principle, BaseFee*GasUsage is burned to compensate the network for the resources consumed by messages and ensure incentive alignment. However, SubmitWindowPoSt is a required message to continue mining operations in Filecoin. 29 | 30 | * Long-term solutions for reducing the cost of Window PoSt include https://github.com/filecoin-project/FIPs/issues/42. 31 | * Long-term solutions for reducing chain congestion include https://github.com/filecoin-project/FIPs/issues/49, https://github.com/filecoin-project/FIPs/issues/50. 32 | 33 | Unfortunately, such long-term solutions are complex and cannot be properly implemented and tested on the required timescale (before the holidays). This proposal is a short-term mitigation until those solutions are ready. 34 | 35 | ## Specification 36 | 37 | If an _account_ (not a multisig, payment channel, etc) sends a direct on-chain message to a miner actor's `SubmitWindowedPoSt` method and the message succeeds, immediately "refund" all the burned gas, instead of just refunding the overestimation. DO NOT refund, overestimation penalties, gas premium, etc. 38 | 39 | ## Design Rationale 40 | 41 | This design was chosen as the least-invasive stopgap solution to the problem of expensive window posts. It directly removes the majority of the fees related to Window PoSt messages without affecting block validation times. 42 | 43 | ## Backwards Compatibility 44 | 45 | This FIP requires a network upgrade at a specific epoch to ensure that all node operators abide by the new pricing rules after that epoch. 46 | 47 | ## Test Cases 48 | 49 | After the change, the "GasCost" of a successful, direct `SubmitWindowedPoSt` message must change from: 50 | 51 | ```json 52 | { 53 | "Message": { 54 | "/": "bafy2bzacedhftxcnozkaeleau4szu2vpvksbjs2xkpracp6xvdog6gucnzxdc" 55 | }, 56 | "GasUsed": "125122238", 57 | "BaseFeeBurn": "12512223800", 58 | "OverEstimationBurn": "466093200", 59 | "MinerPenalty": "0", 60 | "MinerTip": "15543374565710", 61 | "Refund": "151788019038", 62 | "TotalCost": "15556352882710" 63 | } 64 | ``` 65 | 66 | To: 67 | 68 | ```json 69 | { 70 | "Message": { 71 | "/": "bafy2bzacedfyp5mz6le43iifaviw2g7hgiqr3eet2bfdzffbitphyubjzzgpy" 72 | }, 73 | "GasUsed": "125122238", 74 | "BaseFeeBurn": "0", 75 | "OverEstimationBurn": "466093200", 76 | "MinerPenalty": "0", 77 | "MinerTip": "15723304407057", 78 | "Refund": "164300242838", 79 | "TotalCost": "15723770500257" 80 | } 81 | ``` 82 | 83 | Specifically, the `BaseFeeBurn` is 0. 84 | 85 | All other messages, _including_ messages that indirectly invoke `SubmitWindowedPoSt` (e.g., from a multisig) or contain an unsuccessful Window PoSt, must retain the prior gas fees. 86 | 87 | ## Security Considerations 88 | 89 | This FIP effectively removes the base-fee "auction" from Window PoSt messages given Window PoSt congestion. This means the base-fee could rise unchecked because Window PoSt messages are not sensitive to the base-fee. However, miners may only submit one windowed post per partition, per day. This puts an upper bound on the amount of congestion we expect from Window PoSt messages. 90 | 91 | Furthermore, any chain congestion due to Window PoSt messages will increase the base-fee, pricing out other messages that are sensitive to base-fee hikes. This will leave room for more Window PoSt messages, clearing them out faster and allowing the base-fee to drop. This only works because Window PoSt messages are rate-limited. 92 | 93 | For these reasons, we consider this solution to be, at most, an acceptable _stopgap_. However: 94 | 95 | 1. It is not a final solution: It does not improve chain throughput or reduce the cost of verifying Window PoSt messages on the network as a whole. 96 | 2. It is not an acceptable solution for any other message type: Window PoSts are special, rate-limited, "system" messages. 97 | 98 | ## Incentive Considerations 99 | 100 | Base Fee serves as a signal to message senders on what the market clearing price is. Exempting BaseFee burn for SubmitWindowPoSt is effectively removing the posted price mechanism (Base Fee) of EIP1559 for `SubmitWindowedPoSt`. 101 | Per latest analysis by [Tim Roughgarden](https://timroughgarden.org/), Base Fee tend to be under the market clearing price when demand for the network rises sharply. However, SubmitWindowedPoSt is a required message of the protocol and it can be argued that it deserves special treatment or below market rate relative to onboarding new storage or other “optional” network messages. 102 | 103 | Given that we are not removing Gas Burn entirely, message selection works as before from the perspective of the block producing miner. Miners are selecting messages based on FeeCap/GasLimit, where FeeCap includes BaseFee and GasPremium. 104 | 105 | However, from the perspective of message senders, priority within WindowPoSt messages dissolves into submitting bids for the first price auction of GasPremium: block producing miners may include their messages for free, while smaller miners may have to pay a higher GasPremium to get their messages included. However, this is also the case in the current protocol. While there is no guarantee that this proposal will disproportionately help smaller miners, this proposal at least alleviates the burden of fee burn for all miners for a message that is crucial to the healthy functioning of the economy. 106 | 107 | In the event of network demand rising sharply, BaseFee will spike and likely price out other messages that are sensitive to BaseFee hikes. Given that SubmitWindowPoSt is exempt from BaseFee burn, default message selection logic will still pick these messages, thereby allocating more chain bandwidth for SubmitWindowPoSt and allowing them to go through. If a high BaseFee persists, messages other than SubmitWindowPoSt will be priced out and SubmitWindowPoSt can be cleared more quickly, leading to a drop in BaseFee. 108 | 109 | 110 | ## Product Considerations 111 | 112 | After the network upgrade, miners may need to raise their fee-cap for Window PoSt messages to account for changes to the network's base-fee. However, given this change, this will not _significantly_ impact the cost of a Window PoSt message. 113 | 114 | NOTE: The base-fee will still affect the overestimation burn and miner penalties for including Window PoSt messages with fee-caps under the base-fee. 115 | 116 | As this stopgap does not address the rising base-fee, prove-committing sectors will continue to be expensive unless the base-fee drops. 117 | 118 | ## Implementation 119 | 120 | PENDING PR 121 | 122 | ## Related Work 123 | 124 | * https://github.com/filecoin-project/FIPs/issues/24#issuecomment-736923109 - Steven Li (@steven004) 125 | 126 | ## Copyright 127 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 128 | -------------------------------------------------------------------------------- /FIPS/fip-0011.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0011" 3 | title: Remove reward auction from reporting consensus faults 4 | author: Jakub Sztandera (@Kubuxu) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/61 6 | status: Final 7 | type: Core 8 | category: Core 9 | created: 2020-01-05 10 | spec-sections: 11 | - section-algorithms.expected_consensus.detection-and-reporting 12 | --- 13 | 14 | # FIP-0011: Remove reward auction from reporting consensus faults 15 | 16 | 17 | 18 | ## Simple Summary 19 | 20 | 21 | Reward from reporting currently undergoes reverse auction (Dutch auction). This FIP proposes and 22 | specifies removal of this auction mechanism and makes the full reward available immediately. 23 | 24 | ## Abstract 25 | 26 | Misbehaving miners can produce block which influence Expected Consensus' fairness. 27 | The incentive for reporting Consensus Faults is a reward. This reward is in range 28 | 0.005 and 0.25 of Block Reward (~4 FIL full reward) determined by Dutch auction. The duration of auction is 500 epoch. 29 | For full reward that period has to elapse since the consensus fault was produced. 30 | For 50% reward the reporter has to wait 412 epochs. 31 | This significantly delays reporting of consensus faults, which ideally should be reported as soon 32 | as possible. This mechanism is a remainder of an old system where miner was completely removed from Filecoin 33 | and the reporter was awarded percentage of that miner's collateral. 34 | 35 | ## Change Motivation 36 | 37 | 38 | There are multiple motivating factors for this change: 39 | - the current system was intended for different reward kind (percentage of collateral) 40 | - the current system disincentives swift reporting of consensus faults which is essential for EC 41 | - the new system increases the overall income from reporting consensus faults, which can have the effect of 42 | increasing the number of parties reporting consensus faults 43 | 44 | 45 | ## Specification 46 | 47 | 48 | Reporter reward changes from 0.001 to 0.05 of Consensus Fault Penalty (5\*BlockReward) to `BlockReward / 4`. 49 | Where `BlockReward` is reward that is to be awarded a single miner at this epoch. 50 | The resulting reward is the same amount as maximum reward from Dutch auction. 51 | 52 | 53 | ## Design Rationale 54 | 55 | 56 | This is minimal change with aim of removing the Dutch auction mechanism while preserving the final amount. 57 | It also significantly simplifies how the reporter reward is calculated and unties it from Consensus Fault Penalty. 58 | 59 | ## Backwards Compatibility 60 | 61 | 62 | It is backward incompatible change that will require all implementations to adapt. 63 | It should be deployed as synchronised network upgrade. 64 | The proposed mechanism is much simpler than one currently specified. 65 | 66 | ## Test Cases 67 | 68 | 69 | WIP 70 | All valid ReportConsensusFault messages should result in full `BR / 4` reward. 71 | 72 | ## Security Considerations 73 | 74 | 75 | Dutch auction mechanism was introduced to prevent miners exiting Filecoin network extracting the percentage of collateral, 76 | by self-reporting consensus faults. At the time, the fact that secret (non-published) consensus faults are 77 | easy to create was not considered and Dutch auction is not effective defense against this. 78 | 79 | Currently Dutch auction does not serve any security related purpose apart from delaying the reporting of consensus faults. 80 | 81 | 82 | 83 | ## Incentive Considerations 84 | 85 | 86 | This change increases incentives for prompt reporting of consensus faults instead of waiting 400-500 epochs. 87 | 88 | ## Product Considerations 89 | 90 | Does not influence Filecoin as a Product other than improving stability of the network. 91 | 92 | ## Implementation 93 | 94 | WIP 95 | 96 | ## Copyright 97 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 98 | -------------------------------------------------------------------------------- /FIPS/fip-0014.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0014" 3 | title: Allow V1 proof sectors to be extended up to a maximum of 540 days 4 | author: deltazxm (@deltazxm), Neo Ge(@neogeweb3), Fatman13(@Fatman13 ) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/56 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2021-26-02 10 | spec-sections: 11 | - section-systems.filecoin_mining.sector.lifecycle 12 | 13 | --- 14 | 15 | # FIP-0014: Allow V1 proof sectors to be extended up to a maximum of 540 days 16 | 17 | ## Simple Summary 18 | Allow V1 proof sectors to be extended up to a maximum lifetime of 540 days. 19 | 20 | ## Abstract 21 | Allow sectors sealed using V1 proof before network version 7 on Nov 27th, 2020 to be extended up to a maximum lifetime of 540 days including the days that they have already been active. This means the latest a v1 sector will be live on the network is May 21, 2022. 22 | 23 | ## Change Motivation 24 | While every encryption/proof created ever by human beings has security issues, V1 proof is now being challenged with unrealistically high standard of security concerns. This fip advocates that V1 proof sectors should be treated equally just like any other sectors. 25 | 26 | ## Specification 27 | Key changes proposed by @steven004 could be found [here](https://github.com/filecoin-project/FIPs/pull/75#issuecomment-789405523). 28 | 29 | ## Design Rationale 30 | The design is quite straight forward. Suggestions are welcome. 31 | 32 | ## Backwards Compatibility 33 | TODO: Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable. 34 | 35 | ## Security Considerations 36 | Security concerns from the community boils down to @nicola's following comment. 37 | > There is a risk that a year+ from now, with highly pipelined custom hardware (less likely to be software - but not impossible), one may able to avoid storing 100% of the sector and still succeed at WindowPoSt.** 38 | > As we come closer to these sectors' expiration (most are a ~year from now), depending on (1) what percentage of power these sectors sum up to, (2) what is the state of the art of ASICs and Proof of Space software, the community should decide what to do with those sectors. 39 | > I would not recommend to allow for sector extension right now. 40 | 41 | ### Cost of designing custom hardware (ASICs) 42 | From [data](https://semiengineering.com/big-trouble-at-3nm/) aggregated by semiengineering, the design cost alone of developing a cutting edge chip could amount to ~$540M which is equivalent to the revenue of running a 120Pib node for 3 years given the current network parameters. If attackers were in this for profits, it would be extremely costly for them to recoup their initial investment. 43 | 44 | ### Time for development of custom hardware 45 | It is estimated that manufacturing a chip from scratch could take [1 to 2 years](https://www.quora.com/How-long-does-it-take-to-build-a-computer-chip-from-scratch). By this point, most, if not all, v1 sectors will have expired. 46 | 47 | ### Securing production of custom hardware 48 | There are mainly two foundries someone could get their chip design produced, namely from TSMC or Samsung. Attackers will be competing with all smart devices manufacturers for "production cap". [Months of waiting](https://www.dvhardware.net/article72264.html) time is the norm given how the market is craving smart devices nowadays. 49 | 50 | ### Incentives of attackers 51 | Under the circumstances mentioned above, there wouldn't be any incentives for attackers to invest huge amount of time and money just to fake a discontinued proof. 52 | 53 | ### Core dev meeting 54 | Many of the security considerations were also extensively discussed in [Filecoin Core Dev Meeting #13](https://github.com/filecoin-project/tpm/blob/master/Core%20Dev%20Meetings/Meeting%200013.md). Some of the key takeaways are... 55 | > Core devs need to agree on final answers to: 56 | > - whether adopting this FIP is acceptable from a security perspective 57 | > - whether the community's overall preference is in fact for this FIP 58 | > 59 | > The answer for the first question is tending towards "yes", and the answer to the second question should be found out via a community poll. 60 | 61 | ### Summary of security considerations 62 | The general consensus is that it is not economically viable that an attacker could develop custom hardware using tech that is a year+ from now. Some highlights of community comments are by @neogeweb3 at [here](https://github.com/filecoin-project/FIPs/pull/75#discussion_r586057806) and by @steven004 at [here](https://github.com/filecoin-project/FIPs/issues/56#issuecomment-785715308). 63 | 64 | ## Incentive Considerations 65 | The majority of the people who sealed sectors using V1 proof for 180 days will now most likely to extend them up to 540 days. 66 | 67 | We expect such behaviour thanks to one of crucial points that @steven004 brought up, which is [fairness](https://github.com/filecoin-project/FIPs/issues/56#issuecomment-794778752). As summed up by Aayush in this [thread](https://filecoinproject.slack.com/archives/C01EU76LPCJ/p1615524308014600?thread_ts=1615283805.008800&cid=C01EU76LPCJ)... 68 | 69 | > My personal opinion is that it’s a fairness question — folks who sealed 6 month v1 sectors thinking they could be easily extended later are now in the unfortunate position of not being able to do so (while those who sealed them for 18 months will continue to have power for them). 70 | 71 | ## Product Considerations 72 | This FIP protects interests of miners who have contributed to Filecoin's growth since mainnet launch. 73 | 74 | This FIP is both a both security/implementation decision and governance decision. The decision made in [v1.2.0](https://github.com/filecoin-project/lotus/releases/tag/v1.2.0) of not allowing extending V1 proof sectors was not an obvious catch. It wasn't until @deltazxm tried to extend a V1 proof sector and got an [error message](https://github.com/filecoin-project/specs-actors/issues/1309) that people realized the decision had been made. What if we find a bug in V1.1 tomorrow? Do we silently let V1.1 proof expire too? We need to establish some kind of process to reach consensus on making decisions like this together with different kinds of stakeholders in the network especially when changing policy, network parameters or other equivalents. 75 | 76 | ## Implementation 77 | 78 | Set `SectorMaxLifetime` for v1 sectors to be 540 days 79 | 80 | ```go 81 | const EpochsInFiveYears = stabi.ChainEpoch(5 * EpochsInYear) 82 | const EpochIn540Days = stabi.ChainEpoch(EpochsInYear + EpochsInYear/2) 83 | 84 | var SealProofPolicies = map[stabi.RegisteredSealProof]*SealProofPolicy{ 85 | stabi.RegisteredSealProof_StackedDrg2KiBV1: { 86 | SectorMaxLifetime: EpochIn540Days, 87 | }, 88 | stabi.RegisteredSealProof_StackedDrg8MiBV1: { 89 | SectorMaxLifetime: EpochIn540Days, 90 | }, 91 | stabi.RegisteredSealProof_StackedDrg512MiBV1: { 92 | SectorMaxLifetime: EpochIn540Days, 93 | }, 94 | stabi.RegisteredSealProof_StackedDrg32GiBV1: { 95 | SectorMaxLifetime: EpochIn540Days, 96 | }, 97 | stabi.RegisteredSealProof_StackedDrg64GiBV1: { 98 | SectorMaxLifetime: EpochIn540Days, 99 | }, 100 | 101 | stabi.RegisteredSealProof_StackedDrg2KiBV1_1: { 102 | SectorMaxLifetime: EpochsInFiveYears, 103 | }, 104 | stabi.RegisteredSealProof_StackedDrg8MiBV1_1: { 105 | SectorMaxLifetime: EpochsInFiveYears, 106 | }, 107 | stabi.RegisteredSealProof_StackedDrg512MiBV1_1: { 108 | SectorMaxLifetime: EpochsInFiveYears, 109 | }, 110 | stabi.RegisteredSealProof_StackedDrg32GiBV1_1: { 111 | SectorMaxLifetime: EpochsInFiveYears, 112 | }, 113 | stabi.RegisteredSealProof_StackedDrg64GiBV1_1: { 114 | SectorMaxLifetime: EpochsInFiveYears, 115 | }, 116 | } 117 | ``` 118 | 119 | And remove the following condition in ExtendSectorExpiration method: 120 | 121 | ```go 122 | if !CanExtendSealProofType(sector.SealProof) { 123 | rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for sector %v with unsupported seal type %v", 124 | sector.SectorNumber, sector.SealProof) 125 | } 126 | ``` 127 | 128 | ## Copyright 129 | 130 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 131 | -------------------------------------------------------------------------------- /FIPS/fip-0015.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0015" 3 | title: Revert FIP-0009 (Exempt Window PoSts from BaseFee burn) 4 | author: jennijuju (@jennijuju), arajasek (@arajasek) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/86 6 | status: Final 7 | replaces: "0009" 8 | type: Technical 9 | category: Core 10 | created: 2021-05-20 11 | review-period-end: 2021-05-31 12 | --- 13 | 14 | # FIP-0015: Revert FIP-0009 (Exempt Window PoSts from BaseFee burn) 15 | 16 | ## Simple Summary 17 | 18 | Revert FIP-0009, which exempts Window PoSts from BaseFee burn. 19 | 20 | ## Abstract 21 | 22 | Do not "refund" any burned gas from any `SubmitWindowedPoSt` message sent on-chain. 23 | 24 | ## Change Motivation 25 | 26 | FIP-0009, which exempts select `SubmitWindowedPoSt` message from base-fee burn, was introduced in December, 2020, as a short-term stopgap to reduce the impact of rising base fee on the gas cost for continuously proving existing storage. 27 | 28 | Since then, three long-term solutions for addressing this issue have been accepted in the network: 29 | - [FIP-0010](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0010.md), which introduced optimistic acceptance of Window PoSt proofs without verification, while allowing them to be disputed later by off-chain verifiers. As a result, the `GasUsed` for an arbitrary `SubmitWindowedPost` message fell by more than 90%. 30 | - [FIP-0013](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md), which adds a `ProveCommitAggregated` method to condense multiple proof verifications (SNARKs) into a single aggregated message that takes up less chain bandwidth. The FIP has been accepted and will be introduced in the network in the upcoming [HyperDrive upgrade](https://github.com/filecoin-project/community/discussions/74#discussioncomment-707228). This feature will relieve the network congestion as SnarkPack can aggregate 8192 SNARK proofs, whcih allows miners to submit `ProveCommitments` for up to 819 sectors in one `ProveCommitAggregated` message. 31 | - [FIP-0008](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0008.md), which adds a method for a miner to submit batched pre-commitments for multiple sectors. This serves to further increase chain bandwidth and will also be introduced in the network in the upcoming HyperDrive upgrade. 32 | 33 | In addition, the "free" Window Posts distorts the gas market and reduces the incentive for miners to batch as many partitions as possible into one `SubmitWindowedPoSt` message, which wastes chain bandwidth. 34 | 35 | ## Specification 36 | 37 | Treat `SubmitWindowedPoSt` messages the same as all others for the purpose of gas accounting. Specifically, do NOT "refund" any burned gas when accounts send successful message to a miner actor's `SubmitWindowedPoSt` method. 38 | 39 | ## Design Rationale 40 | 41 | The simple design is to simply stop applying the rule introduced in FIP-0009 past a certain point. 42 | 43 | ## Backwards Compatibility 44 | 45 | This FIP requires a network upgrade at a specific epoch to ensure that all node operators abide by the new pricing rules after that epoch. 46 | 47 | ## Test Cases 48 | 49 | After the change, the "GasCost" of a successful, direct `SubmitWindowedPoSt` message must change from: 50 | 51 | ```json 52 | { 53 | "Message": { 54 | "/": "bafy2bzacedhftxcnozkaeleau4szu2vpvksbjs2xkpracp6xvdog6gucnzxdc" 55 | }, 56 | "GasUsed": "125122238", 57 | "BaseFeeBurn": "0", 58 | "OverEstimationBurn": "466093200", 59 | "MinerPenalty": "0", 60 | "MinerTip": "15543374565710", 61 | "Refund": "151788019038", 62 | "TotalCost": "15556352882710" 63 | } 64 | ``` 65 | 66 | To: 67 | 68 | ```json 69 | { 70 | "Message": { 71 | "/": "bafy2bzacedfyp5mz6le43iifaviw2g7hgiqr3eet2bfdzffbitphyubjzzgpy" 72 | }, 73 | "GasUsed": "125122238", 74 | "BaseFeeBurn": "12512223800", 75 | "OverEstimationBurn": "466093200", 76 | "MinerPenalty": "0", 77 | "MinerTip": "15723304407057", 78 | "Refund": "164300242838", 79 | "TotalCost": "15723770500257" 80 | } 81 | ``` 82 | 83 | Specifically, the `BaseFeeBurn` is NOT 0. 84 | 85 | 86 | ## Security Considerations 87 | 88 | This FIP is strictly an increase in security, since it does away with the minor risks introduced in FIP-0009 (see [here](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0009.md#security-considerations)). 89 | 90 | ## Incentive Considerations 91 | 92 | The FIP leads to more FIL being burned through the act of proving storage, making it marginally more expensive for miners to be a part of the network. However, this cost is insignificant, less than 1/60th the FIL burned through onboarding storage. The overall cost is about 10,000 FIL per week. 93 | 94 | The FIP disincentivizes miners from splitting their partitions across multiple `SubmitWindowedPost` messages, which is an overall improvement to chain capacity. Risk-averse miners can continue to do so, paying a fair price. 95 | 96 | The FIP has no impact on the incentive for miners to select `SubmitWindowedPost` messages to be included in their blocks. 97 | 98 | ## Product Considerations 99 | 100 | After the network upgrade, miners should pay attention to the _fee cap_ of `SubmitWindowedPost` message to avoid unexpected and unnecessary base fee burn. 101 | 102 | ## Implementation 103 | 104 | PENDING PR 105 | 106 | ## Copyright 107 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 108 | -------------------------------------------------------------------------------- /FIPS/fip-0018.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0018" 3 | title: New miner terminology proposal 4 | author: Stefaan-V (@Stefaan-V) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/127 6 | status: Final 7 | type: Organizational 8 | Created: 2021-07-26 9 | review-period-end: 2021-08-20 10 | --- 11 | 12 | ![image (1)](https://user-images.githubusercontent.com/83617805/127074347-4d4aed25-ed92-4688-b953-8811e28d1c9c.png) 13 | 14 | # FIP-0018: New miner terminology proposal 15 | 16 | ## **Summary** 17 | 18 | This proposal describes a change to rebrand the existing ‘miner’ references in marketing assets, documentation, communication channels and UX interfaces to a new definition called 'Storage Providers'. With this new proposal we are moving towards a naming convention that better represents our community partners that provide the storage infrastructure and services to the Filecoin network. This change will also help in highlighting the usefulness of the Filecoin network and is a start of a series of gradual changes we are proposing to help the network in creating a new narrative. We welcome feedback and input on the proposed changes below. 19 | 20 | ## **Change Motivation** 21 | 22 | No blockchain is the same. Every single blockchain network comes with unique characteristics and incentive mechanisms that drive a prosperous community and implement a long-term sustaining strategy. 23 | 24 | Filecoin's long-term vision has always been to create a decentralized, efficient and robust foundation for humanity’s most valuable data. To support this vision, we are relying on a wide network of community members that provide and commit storage to the Filecoin network, currently referred to as the Filecoin miners. 25 | 26 | With Filecoin’s rapid storage growth and adoption of web3 applications, the community and the extended ecosystem members are requesting a branding change in how to position the miners. 27 | 28 | ### **The main reasons are:** 29 | 30 | 1. **To connect better with the end-user market.** Enterprises and other Web2 members looking to store data on the Filecoin network are typically not familiar with the crypto concepts that underpin the tokenomics. Hence, the concept of a miner and or mining activities can lead to confusion with non-crypto-savvy users and distract from the real value that the network provides. Clients are used to hearing terminologies like cloud providers, service providers, etc. 31 | 2. **To communicate the usefulness of the network**. Different blockchains have different usages. Some customers and Web2 members wrongly assume that ‘mining’ refers to a process that is delivering no useful output, is highly energy consuming and is not contributing in producing unique capabilities. Filecoin is different from other blockchains as it delivers a decentralized network that stores useful data in an efficient way and it drives incremental value thanks to its unique capabilities (e.g. immutability). It is important to communicate and market those useful attributes through straightforward terminology that is easily recognized by the Web2 and Web3 members. 32 | 3. **To take a leadership position.** Filecoin miners not only contribute to providing archive storage for existing Web2 datasets, but also form the native storage foundation for the Web3 world of decentralized applications. It is important to highlight the differences between the traditional Web2 cloud providers and those storage providers that are able to deliver a unique experience or better service through Filecoin's decentralized capabilities. As we move our branding forward, our providers can position themselves as the infrastructure and service providers of storage and retrieval of NFTs, Web3 data sets, Web2 archives and many more. 33 | 34 | ## The Proposal 35 | 36 | ### Input & Feedback 37 | 38 | This proposal includes input gathered from feedback sessions with miners in the storage provider working groups and ecosystem partners. 39 | 40 | The goal was to rename a subset of the current miner related terminologies and replace them with a proposal that better describes the current activities and the value creation to the network. The initial feedback we received from the community has been in favor of this new change. 41 | 42 | ## The New Terminology Mapping 43 | 44 | The following table highlights in more detail the terminology mapping. 45 | 46 | **The New Terminology Mapping** 47 | |Current Terminology|New Proposal |Abbreviated Version | 48 | |---|---|---| 49 | | Miner | Storage Provider (SP) | Storage Provider | 50 | | Storage Miner | Storage Provider (SP) | Storage Provider | 51 | | Retrieval Miner | Retrieval Provider (RP) | Retrieval Provider | 52 | | Pool Name | Storage Provider Name | Provider Name | 53 | | Miner Rig | Storage System |Storage System | 54 | | Miner Pool | Storage Pool | Storage Pool | 55 | | Mining/Block Rewards | Block Rewards | Rewards | 56 | | Deal Payment | Deal Income | Income | 57 | | Miner ID **(third party UX) | Storage Provider ID | Storage Provider ID | 58 | | Miner Working Group| Storage Provider WG| Storage Provider Working Group| 59 | 60 | **Once the community reaches consensus, we ask all participants in the Filecoin ecosystem to update any miner_ID references to Storage Provider_ID in the UX interfaces. 61 | 62 | The following table highlights in more detail the description of these new terms. 63 | 64 | | Proposal | Description | 65 | |---|---| 66 | | Filecoin | A decentralized storage network existing of a multi-verse ecosystem where storage providers deliver the storage infrastructure supply. | 67 | | Storage Providers (SP) | A Filecoin Storage Provider exists of 1 or multiple storage systems. | 68 | | Block Rewards | The rewards gained from committing storage capacity and storing useful data. | 69 | | Deal income | Income received for storing useful data through deal making. | 70 | | Storage System | A Storage system can exist of 1 node or a cluster of nodes responsible for sealing, storing and retrieving data. A storage system has one ID | 71 | | Storage ProviderID | We ask all network browsers and other ecosystem partners to represent the miner_IDs as storage provider_IDs in the UX. | 72 | | Retrieval Providers| A provider who provides retrieval services. | 73 | | Storage Provider Name | A Storage Provider is typically represented by a custom tag in a network explorer UX and can exists of 1 or multiple storage systems. This purely added as guidance for third-party explorers. | 74 | | Storage Pool | A combination of multiple storage systems that are pooled together as 1 single entity. | 75 | | Storage Provider WG | The working group of world wide storage providers that focuses on the storage provider ecosystem.| 76 | 77 | ## What content assets will be updated? 78 | 79 | With the support of the community, we will start using the new terminology in newly created marketing assets. In the next couple of weeks and months we also suggest to update the following websites and assets and promote the new terminology where possible. 80 | 81 | **List of existing assets/websites we propose to update over time** 82 | 83 | - [filecoin.io](https://filecoin.io/), [docs.filecoin.io](https://docs.filecoin.io/) 84 | - github /filecoin-project 85 | - Filecoin Foundation website 86 | - Partner Block trackers 87 | - and other ecosystem tools 88 | 89 | We ask the Filecoin community to adopt and help communicate these new changes to the market. Once we reached consensus, we also ask the community to update the community tools and marketing assets to include these new naming proposals. 90 | 91 | ## The journey ahead 92 | 93 | We understand this change doesn't happen in a day and it will be a multi-phased approach of content iterations and messaging adjustments across the whole ecosystem. This is the first phase of this journey that will take the full community to participate. 94 | 95 | The Filecoin long-term strategy is to continue to educate the mainstream market and create awareness on the benefits of the network and how a distributed and decentralized architecture differentiates from the centralized solutions of the Web2 world. 96 | -------------------------------------------------------------------------------- /FIPS/fip-0020.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0020" 3 | title: Add Return Value to WithdrawBalance 4 | author: Steven Li (@steven004), Zenground0 (@Zenground0) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/26 6 | status: Final 7 | type: Technical Core 8 | category: Core 9 | created: 2021-06-06 10 | review-period-end: 2021-10-11 11 | spec-sections: 12 | - specs-actors 13 | --- 14 | 15 | 16 | 17 | # FIP-0020: Add Return Value to WithdrawBalance 18 | 19 | ## Simple Summary 20 | 21 | Add a return value to market and miner withdraw methods to indicate the actual withdrawn amount 22 | 23 | ## Abstract 24 | 25 | WithdrawBalance methods can succeed even when withdrawing less than the specified amount in message arguments. To resolve this ambiguity the return value should specify the amount withdrawn. 26 | 27 | ## Change Motivation 28 | 29 | 30 | Both miner and market actors have WithdrawBalance methods. Both methods are an attempt to withdraw a specified amount, but return success even when the available balance is less than the withdrawal amount specified. So the actual amount withdrawn is equal to or less than the amount specified in the method parameters, and the method always return nil. Therefore there is no way to know how much FIL is actually withdrawn by only checking the chain status and message info e.g. from node CLI or an explorer. 31 | 32 | Adding return values specifying the withdrawn amount will improve the visibility and traceability of FIL flow. This is important especially for miners who need to have a very clear balance sheet and financial report. 33 | 34 | ## Specification 35 | 36 | Add `abi.TokenAmount` return values to market and miner `WithdrawBalance` methods and return the amount withdrawn. 37 | 38 | ## Design Rationale 39 | 40 | The design is trivial. 41 | 42 | ## Backwards Compatibility 43 | 44 | This proposal requires a breaking change in actor method signatures and therefore a new actors version. 45 | 46 | ## Test Cases 47 | 48 | For both miner and market actors 49 | * WithdrawBalance with an amount that can be withdrawn => the specified amount is returned 50 | * WithdrawBalance with an amount greater than that which can be withdrawn => the actual amount withdrawn is returned 51 | 52 | ## Security Considerations 53 | 54 | This only changes return value behavior so has no security implications. 55 | 56 | ## Incentive Considerations 57 | 58 | This only changes return value behavior so has no incentive implications. 59 | 60 | ## Product Considerations 61 | 62 | This has a positive product consideration for miners and storage clients. Most existing tools should still work since it is unlikely tools depend on the empty return value of withdraw balance. Tools can be improved and adapted to make use of the return value. 63 | 64 | ## Implementation 65 | 66 | specs-actors PR: https://github.com/filecoin-project/specs-actors/pull/1476 67 | 68 | ## Copyright 69 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 70 | -------------------------------------------------------------------------------- /FIPS/fip-0023.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0023" 3 | title: Break ties between tipsets of equal weight 4 | author: Sarah Azouvi (@sa8), Aayush Rajasekaran (@arajasek) 5 | discussions-to: https://github.com/filecoin-project/FIPs/issues/22 6 | status: Final 7 | type: Technical (Core) 8 | created: 2021-09-07 9 | review-period-end: 2021-10-11 10 | spec-sections: 4.1.4.2 11 | --- 12 | 13 | 14 | 15 | # FIP-0023: Break ties between tipsets of equal weight 16 | 17 | ## Simple Summary 18 | 19 | 20 | The general process by which nodes on the Filecoin network choose between two tipsets is by picking the heavier tipset based on a weight function (see [here](https://spec.filecoin.io/#section-algorithms.expected_consensus.chain-weighting)). 21 | 22 | It is not an unlikely event for two tipsets to have the same weight. When this happens, we should have a simple rule to pick one of the tipsets as canonically "heavier" so as to achieve consensus faster. This FIP proposes such a rule. 23 | 24 | ## Abstract 25 | 26 | 27 | Filecoin needs a rule to decide between forks of equal weight. Although not critical it would help block producers converge more easily towards a common chain. This means that when two forks with the same weight occur, all the block producers that have received both forks will mine on the same one. Without a tie-breaker they would randomly choose one and may extend the forks for longer. 28 | 29 | ## Change Motivation 30 | 31 | 32 | Implementing such a rule will help the network achieve consensus faster. This has an immediate effect of reducing the number of orphaned blocks, which increases profits for block producers. More importantly, this FIP will reduce the time it takes the network to recover from slowdowns or outages, since nodes will achieve consensus faster. 33 | 34 | ## Specification 35 | 36 | 37 | For two tipsets with the same weight, we pick the tipset with the smallest winning Ticket. In the case where two Tipsets of equal weight have the same smallest Ticket, we compare the next smallest Ticket in the Tipset (and select the Tipset with the smaller one). This continues until one Tipset is selected. There are 2 interesting cases to consider: 38 | 39 | - The tipsets are of unequal size: the larger tipset is almost always gonna be heavier in this case. In the virtually impossible event of a tie, we explicitly leave behaviour undefined. 40 | - The tipsets are of equal size, but all the tickets are identical: This is only possible if a block producer has produced 2 different blocks with the same ticket. We explicitly leave behaviour undefined here too, since the producer will be heavily slashed for this. 41 | 42 | ## Design Rationale 43 | 44 | 45 | Any solution that is both deterministic and non-biasable (i.e. an adversary may not make their chain more likely to be selected by the chain selection algorithm in the case of forks of equal weight) may work. The ElectionProof is unbiasable and hence is a good candidate for tie-breaker. Any deterministic rule other than minimum ticket would work just as well. 46 | 47 | ## Backwards Compatibility 48 | 49 | 50 | This FIP proposes a "soft" change that maintains full backward compatability. No new network version is needed. 51 | 52 | ## Test Cases 53 | 54 | 55 | The following test cases should be covered: 56 | 57 | - two tipsets with different min tickets 58 | - two tipsets with one min ticket the same 59 | - two tipsets with several min tickets the same 60 | - three heaviest heads 61 | 62 | ## Security Considerations 63 | 64 | 65 | We should be confident that the proposed tiebreaking rule is unbiasable by adversarial block producers. That aside, this FIP is a strict improvement to network security. 66 | 67 | ## Incentive Considerations 68 | 69 | 70 | No change to incentives. 71 | 72 | ## Product Considerations 73 | 74 | 75 | No change to product considerations, except that increased overall stability is a net improvement. 76 | 77 | ## Implementation 78 | 79 | 80 | TODO in each of the Filecoin implementations. 81 | 82 | ## Copyright 83 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 84 | -------------------------------------------------------------------------------- /FIPS/fip-0039.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: 0039 3 | title: Filecoin Message Replay Protection 4 | author: Afri Schoedon (@q9f) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/301 6 | status: Draft 7 | type: Technical 8 | category: Core 9 | created: 2022-02-16 10 | --- 11 | 12 | # FIP-0039: Filecoin Message Replay Protection 13 | 14 | ## Simple Summary 15 | Defines Filecoin chain identifiers and adds them to unsigned messages and signatures to prevent transactions to be replayed across different Filecoin networks. 16 | 17 | ## Abstract 18 | The proposal adds a field to unsigned messages indicating which chain a transaction is intended for. In addition, signatures encode the chain they are targeted for to prevent clients from accepting signed messages to be replayed across all Filecoin networks. 19 | 20 | ## Change Motivation 21 | Currently, transactions signed for testnets are also valid on mainnet and could be _replayed_. The motivation of this specification is to prevent that by specifically introducing network identifiers for all Filecoin main and test networks and adding them explicitly to the unsigned messages and signatures. 22 | 23 | ## Specification 24 | ### Chain Identifiers 25 | The following chain IDs **MUST** be defined for the Filecoin networks. 26 | - Filecoin: `CHAIN_ID := 314` 27 | - Hyperspace: `CHAIN_ID := 3141` 28 | - Wallaby: `CHAIN_ID := 31415` 29 | - Butterlfynet: `CHAIN_ID := 3141592` 30 | - Calibnet: `CHAIN_ID := 314159` 31 | - Devnet: `CHAIN_ID := 31415926` 32 | 33 | ### Unsigned Messages 34 | The unsigned message **SHOULD** be appended by an additional field `chain_id`. Legacy messages remain valid but **SHOULD** be deprecated. 35 | 36 | ```pyhton 37 | from dataclasses import dataclass 38 | 39 | @dataclass 40 | class UnsignedMessageLegacy: 41 | version: int = 0 42 | from: int = 0 43 | to: int = 0 44 | sequence: int = 0 45 | value: int = 0 46 | method_num: int = 0 47 | params: bytes() 48 | gas_limit: int = 0 49 | gas_fee_cap: int = 0 50 | gas_premium: int = 0 51 | 52 | @dataclass 53 | class UnsignedMessageFip0039: 54 | version: int = 0 55 | from: int = 0 56 | to: int = 0 57 | sequence: int = 0 58 | value: int = 0 59 | method_num: int = 0 60 | params: bytes() 61 | gas_limit: int = 0 62 | gas_fee_cap: int = 0 63 | gas_premium: int = 0 64 | chain_id: int = 0 65 | ``` 66 | 67 | ### Signatures 68 | The signature of a message **SHOULD NOT** contain a recovery ID (or _"y-parity"_); instead it **MUST** contain a value `v` that encodes both the `chain_id` and the `recovery_id`. 69 | 70 | ```python 71 | v = recovery_id + CHAIN_ID * 2 + 35 72 | ``` 73 | 74 | A signature is a serialization of the fields `r | s | v`. Note that `v` value is appended not prepended. 75 | 76 | ## Design Rationale 77 | Both Bitcoin and Ethereum use `v` instead of a recovery ID. Bitcoin uses a value of `v` in `{27,28,29,30,31,32,33,34}` to allow recovering public keys on all four possible points on the elliptic curve for both uncompressed and compressed public keys. This does not apply to Filecoin, however, note that the `+ 35` offset in the `v` specifically allows to distinguish between Bitcoin and Filecoin signatures. 78 | 79 | Ethereum uses a similar replay protection in [EIP-155](https://eips.ethereum.org/EIPS/eip-155). 80 | 81 | The `v` value will be encoded at the end of the signature to allow for the easy determination of `v` values for `v > ff`. 82 | 83 | ## Backwards Compatibility 84 | FIP0039 Messages and Signatures are not backward compatible and there will always be the need to maintain both, legacy transactions and FIP0039 transactions. 85 | 86 | The main breaking changes are: 87 | * one additional field of `chain_id` in the unsigned message 88 | * using `v` instead of `recovery_id` in the signatures 89 | * moving the `v` value to the end of the signature. 90 | 91 | ## Test Cases 92 | _Test Cases can be provided after further discussion of the proposal._ 93 | 94 | ## Security Considerations 95 | This proposal supposedly enhances chain and user security by preventing replay protection across different Filecoin networks. 96 | 97 | Notably, EIP-155 has been in use by Ethereum for more than five years and has proven robust. 98 | 99 | ## Incentive Considerations 100 | This FIP does not affect incentives in itself and is of pure technological nature without any impact on economic factors. 101 | 102 | ## Product Considerations 103 | Applications and products should be encouraged to adapt this FIP as it enhances end-user security; at the same time legacy transactions should be discouraged. 104 | 105 | However, since legacy transactions are not invalid for the time being, the impact on applications is fairly low. 106 | 107 | ## Implementation 108 | _An implementation can be provided after further discussion of the proposal._ 109 | 110 | ## Copyright 111 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 112 | -------------------------------------------------------------------------------- /FIPS/fip-0044.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0044" 3 | title: Standard Authentication Method for Actors 4 | author: Aayush Rajasekaran (@arajasek), Alex North (@anorth) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/413 6 | status: Final 7 | type: Technical (Interface) 8 | created: 2022-08-02 9 | replaces: "FIP-OO35" 10 | --- 11 | 12 | # FIP-0044: Standard Authentication Method for Actors 13 | 14 | **Change history** 15 | - February 2023: Added boolean return value to AuthenticateMessage 16 | 17 | ## Simple Summary 18 | 19 | The Filecoin protocol has entities called "actors" that can be involved in computation on the Filecoin blockchain. 20 | There are various different kinds of actors; among the most common are accounts and multisigs. 21 | With [the planned introduction of the Filecoin Virtual Machine](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0030.md), there will be many new kinds of user-defined actors. 22 | Unfortunately, today, the only kind of actors that can "authenticate" a piece of data are account actors -- they do so through a signature validation. 23 | This FIP is the starting point to evolve a convention by which any actor can verify such authenticity. It simply proposes adding a special "authenticate" message that actors can choose to implement. 24 | If they do implement such a method, it can be used by other actors to authenticate pieces of data. 25 | 26 | ## Abstract 27 | 28 | There is a need for arbitrary actors to be able to verify (to other actors) that they have approved of a piece of data. This need will become more pressing with the Filecoin Virtual Machine. 29 | This FIP proposes adding an `AuthenticateMessage` method that any actor can choose to implement. 30 | This method can be called by any other actor to verify the authenticity of a piece of data. This is a small change to the existing actors, and allows for user-defined actors to flexibly implement this method according to their needs. 31 | Concretely, we add this method to the built-in `Account` actor, and have the built-in `Storage Market` and `Payment Channel` actors invoke this method, 32 | in lieu of validating signatures directly. 33 | 34 | ## Change Motivation 35 | 36 | We want any actors, including user-defined actors, to be able to authenticate arbitrary data. 37 | If we don't have this ability, we will need to engineer around it in painful ways. 38 | 39 | The proposed [FIP-0035](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0035.md) 40 | is a concrete example. It seeks to allow user-defined actors to serve as storage clients in the built-in `Storage Market` actor. 41 | In order to enable this, it proposes adding several new methods and data types in order to work around the 42 | inability of user-defined actors to authenticate data. 43 | 44 | It will be infeasible to modify the builtin-actors themselves every time we want to be able to authenticate some new kind of information, and doing so will require more total messages 45 | to be landing on the Filecoin blockchain. Instead, a flexible, universal approach for actors to authenicate data would be preferred. 46 | 47 | ## Specification 48 | 49 | We propose adding the following method to the built-in `Account` Actor. 50 | This method can then be the blueprint for other builtin actors (eg. the multisig actor), 51 | as well as a template for user-defined actors. 52 | 53 | ``` 54 | /// Authenticates whether the provided input is valid for the provided message. 55 | /// Returns false if the authentication is invalid. 56 | /// Any non-zero exit code must also be interpreted as authentication failure. 57 | pub fn authenticate_message(params: AuthenticateMessageParams) -> Result 58 | ``` 59 | 60 | The params to this method is a wrapper over the message and signature to validate: 61 | 62 | ``` 63 | pub struct AuthenticateMessageParams { 64 | pub authorization: Vec, 65 | pub message: Vec, 66 | } 67 | ``` 68 | 69 | Further, we propose modifying the built-in `Storage Market` and `Payment Channel` to call this method instead of validating signatures directly. 70 | 71 | ## Design Rationale 72 | 73 | The idea is to create a flexible, lightweight endpoint that actors can expose to callers that might want to 74 | validate its authorization. Some actors will have very obvious implementations: the account actor simply 75 | performs a signature validation, while an `m/n` multisig need only perform `m` signature validations. 76 | Other actors might opt for creative implementations of such authorization based on their needs. Yet 77 | others can choose not to support this endpoint at all -- the Filecoin protocol's singleton builtin-actors 78 | such as the Storage Power Actor, the System Actor, the Cron Actor, etc. will likely choose to omit this method. 79 | 80 | In order for this method to function as a standard for future actors, it needs a standardized invocation pattern. 81 | In the current dispatch model based on method numbers, that would be a standardized method number for `authenticate_message` methods. This FIP does not propose adopting a standard method number, preferring to rely on a new standardized calling convention, such as [FRC-0042](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0042.md) instead. 82 | 83 | A non-empty return value is specified in order to avoid a no-op implementation of this method inadvertently being interpreted as a successful message authentication. 84 | 85 | ## Backwards Compatibility 86 | 87 | Introducing new methods to the builtin-actors needs a network upgrade, but otherwise breaks no backwards compatibility. 88 | 89 | ## Test Cases 90 | 91 | Proposed test cases include: 92 | 93 | - that the `authenticate_message` method on account actors can be called and succeeds with valid input 94 | - that the `authenticate_message` method on account actors can be called, but fails with invalid input 95 | - that storage deals can be made with the changes to the `StorageMarketActor` 96 | 97 | ## Security Considerations 98 | 99 | We need to be careful with the security of the `authenticate_message` implementations of the 100 | builtin-actors. User-defined contracts are free to implement these methods as they see fit. 101 | 102 | This FIP only proposes adding the `authenticate_message` method to the account actor, which 103 | simply invokes the signature validation syscall. 104 | 105 | ## Incentive Considerations 106 | 107 | This proposal is generally well-aligned with the incentives of the network. It can be considered 108 | as a simpler replacement for FIP-0035, with the only drawback being that this proposal as currently written does not allow for the existing built-in multisig actor to be a storage client. 109 | 110 | ## Product Considerations 111 | 112 | This proposal is the first step towards enabling non-account actors to function as clients for 113 | storage deals, which is a major product improvement. Furthermore, it enables future innovation 114 | that relies on the ability of non-account actors to authenticate data as approved. 115 | 116 | ## Implementation 117 | 118 | Partial implementation [here](https://github.com/filecoin-project/builtin-actors/pull/502) 119 | 120 | ## Copyright 121 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 122 | -------------------------------------------------------------------------------- /FIPS/fip-0052.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0052" 3 | title: Increase max sector commitment to 3.5 years 4 | author: "@anorth" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/475 6 | status: Final 7 | type: Technical (Core) 8 | category: Core 9 | created: 2022-12-06 10 | requires: FIP-0047 11 | --- 12 | 13 | # FIP-0052: Increase max sector commitment to 3.5 years 14 | 15 | ## Simple Summary 16 | Increase the maximum sector commitment duration from 540 days to 1278 days (3.5 years). 17 | 18 | ## Abstract 19 | [FIP-0047](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0047.md) 20 | introduces a mechanism to decouple a sector’s PoRep validity from its commitment duration. 21 | After this, we are free to increase the maximum sector commitment duration from the current 1.5 years 22 | up to any value below 5 years (the maximum PoRep validity lifetime). 23 | 24 | This is a proposal to increase the maximum commitment duration, motivated primarily by the product benefits. 25 | This proposal does not include a multiplier or other direct incentive to make longer commitments, 26 | but does not prevent such incentives being added later. 27 | Other values derived from the maximum sector commitment duration, 28 | such as the built-in market actor's maximum deal duration, are increased in line. 29 | 30 | ## Change Motivation 31 | At present, storage providers can commit sectors only for 1.5 years at a time. 32 | Toward the end of that commitment, they can then extend the commitment for a further 1.5 years, 33 | up to a limit on the sector's total active life of 5 years. 34 | This limit (coupled with current limitations of sector storage and markets) in turn prevents a provider 35 | from committing to a deal any longer than 1.5 years. 36 | 37 | There is significant client demand for longer deal terms. 38 | Longer commitments will also contribute to both the stability of the storage-powered consensus base, 39 | and decrease the velocity of tokens that are pledged to those sectors. 40 | 41 | ## Specification 42 | - Set the built-in miner actor's maximum sector expiration extension to 1278 days 43 | ([code](https://github.com/filecoin-project/builtin-actors/blob/a6250c71cd099b781912b71ae4dec9809aec3fb9/runtime/src/runtime/policy.rs#L367)). 44 | This value bounds the initial commitment duration as well as any subsequent extension. 45 | - Set the built-in storage market actor's maximum deal duration to 1278 days 46 | ([code](https://github.com/filecoin-project/builtin-actors/blob/dc8077c30694bda58559cd057c6d1a0e1b73fc6e/actors/market/src/policy.rs#L22)). 47 | 48 | All sectors, including those already committed, are eligible for extension up by to 1278 days (subject to the 5-year maximum lifetime). 49 | 50 | ## Design Rationale 51 | This proposal was borne out of the decoupling of proof validity duration from sector commitment duration in 52 | [FIP-0047](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0047.md), itself initially created 53 | to support [FIP-0036](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0036.md). 54 | This proposal is intended to be the simplest and least-controversial change possible to enable the 55 | product utility of longer deals, with minimal direct crypto-economic impact. 56 | This proposal has been formalised in order that we can _at least_ gain the benefits of longer commitments, 57 | even if we can't reach sufficient acceptance of higher impact proposals. 58 | 59 | The value of 3.5y for the maximum commitment is chosen as the most conservative of values discussed so far. 60 | A smaller value limits potential for any unexpected consequences. 61 | It will be easy to increase this to 5y (effectively removing the parameter) in the future either 62 | alongside a proposal for incentives, 63 | or if we observe sufficient realised demand for long deals in mainnet. 64 | 65 | ### Constraints on future design 66 | This proposal does not exclude the addition of incentives, such as a duration multiplier, by future FIPs. 67 | Discussion about proposals for commitment incentives is ongoing, 68 | e.g. in [#554](https://github.com/filecoin-project/FIPs/discussions/554). 69 | 70 | If this proposal is implemented in advance of any multiplier proposal, 71 | any future proposal that calculates a commitment-duration-based multiplier at the time of sector commitment 72 | would need to address those sectors already committed with a long term. 73 | One possible mechanism might be for sector extension methods to support a no-op 74 | that merely recalculates weight/power according to the remaining commitment duration. 75 | 76 | ## Backwards Compatibility 77 | This proposal does not introduce any conceptual or API backwards incompatibility. 78 | However, because the parameters in question are encoded in the built-in actors, 79 | it requires a network upgrade and re-deployment of the actors in question to implement it. 80 | 81 | ## Test Cases 82 | To be provided with implementation: 83 | - A miner can commit a sector for 3.5y 84 | - A miner can commit a sector for 1.5y, then immediately extend to 3.5y 85 | - A miner can commit a sector for 1.5y, wait until near expiration, then extend it by an additional 3.5y 86 | - A deal can be made for just below 3.5y, and accepted into a sector with sufficient remaining commitment 87 | 88 | ## Security Considerations 89 | This proposal does not change anything about the security of PoRep. 90 | Lifetime proof validity remains bounded by 5 years, 91 | and incremental PoRep validity still requires refreshing according to the mechanism described in FIP-0047. 92 | 93 | A storage provider making a commitment for >1.5 years (the FIP-0047 proof refresh period) will 94 | face the possibility of sector termination if they fail to post the proof refresh message on schedule. 95 | 96 | ## Incentive Considerations 97 | This proposal introduces only weak direct incentives to make longer commitments on CC sectors, 98 | vs the status quo of rolling 1.5-year extensions. 99 | A storage provider may be induced to do so in order to supply a client deal 100 | requiring a minimum term in excess of 1.5y. 101 | 102 | When the per-sector initial pledge amount is increasing (as is the case when net onboarding falls behind net token emissions), 103 | committed-capacity providers can lock-in the current, lower, pledge amount for a longer term 104 | rather than face a decision between re-pledging a higher amount when extending their incremental commitment, 105 | or letting the sector expire. 106 | A longer commitment has the small beneficial effect to the network of locking that pledge for longer, delaying future emissions. 107 | 108 | ## Product Considerations 109 | The primary impact of this proposal is on deal clients and the storage providers serving them. 110 | Supporting a longer deal maximum-term allows clients with long-term archival data to secure storage for their data for that term. 111 | Specifying this term up front will avoid numerous costs and overheads of making replacement deals every 1.5 years, 112 | amortizing fixed costs over longer terms. 113 | It will also allow clients to lock in the negligible price of storage given the current incentives and supply surplus. 114 | This general improvement in capability of storage would make it cheaper and better for clients, 115 | and thus might encourage additional marginal net demand (especially through not having deals expire every 1.5y). 116 | 117 | Providers serving these deals will be required to make a long sector commitment in order to accept them, 118 | but can lock in the payment (including the FIL+ verified data subsidy) for the entire duration. 119 | Such a deal can be served either by a newly-committed sector, or an existing committed-capacity sector 120 | that is extended to meet the necessary commitment term. 121 | While there is no additional multiplier for the longer term, 122 | locking in the full 10x QA-power benefit for many years may be attractive to these providers. 123 | When the protocol supports long commitments, a market for them will become possible. 124 | 125 | ## Implementation 126 | To be provided. 127 | 128 | ## Copyright 129 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 130 | -------------------------------------------------------------------------------- /FIPS/fip-0060.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0060" 3 | title: Set market deal maintenance interval to 30 days 4 | author: Jakub Sztandera (@Kubuxu), @Zenground0, Alex North (@anorth) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/638 6 | status: Final 7 | type: Technical (Core) 8 | created: 2023-03-06 9 | --- 10 | 11 | # FIP-0060: Set market deal maintenance interval to 30 days 12 | 13 | ## Simple Summary 14 | Reduce the built-in storage market actor's deal maintenance interval from 1 day to 30 days (86400 epochs). 15 | 16 | ## Abstract 17 | Filecoin tipset execution includes a facility for scheduled execution of actor code at the end of every epoch. 18 | This "cron" activity has a real validation cost, which we can account in gas units, 19 | but is not paid for by any party (no tokens are burnt as a gas fee). 20 | 21 | As network activity has grown, the amount of work done in cron has increased. 22 | Recent analysis shows that cron execution is frequently consuming 80 billion gas units each epoch. 23 | For context, the block gas target is 5 billion, so a tipset with the expected five blocks is <25 billion. 24 | 25 | The built-in market actor is consuming 85% of cron execution (73B gas / epoch). 26 | It performs deal maintenance (transferring incremental payments) on a regular interval of 2880 epochs for each deal. 27 | By increasing this maintenance interval we can quickly reduce the validation cost enough to 28 | buy us time to develop a more permanent solution while deal growth continues. 29 | 30 | ## Change Motivation 31 | A fast and predictable tipset validation time is important to the ability of validating nodes to 32 | sync the chain quickly (especially when catching up), 33 | and critical for block producers to be able to produce new blocks for timely inclusion. 34 | Cron is currently consuming a multiple of the target computational demands for all tipset validation. 35 | Although there is significant buffer in target validation times to account for network delays and the variability of expected consensus, 36 | cron execution is beginning to threaten chain quality and minimum hardware specs for validators. 37 | 38 | Cron is very convenient for some maintenance operations, 39 | but is essentially a subsidy from the network to whichever actors get the free execution (which is only ever built-in actors). 40 | Subsidised, automatic daily settlement of deals is far from the kind of critical network service for which cron was intended, 41 | and of zero value for the 98% of deals today that have zero fee. 42 | 43 | The number of deals brokered by the built-in market have increased greatly over the past year. 44 | As we expect this to grow much more, we must address this risk to chain quality. 45 | 46 | ## Specification 47 | Set the interval at which the built-in market performs deal maintenance from 1 day to 30 days. 48 | 49 | ```rust 50 | const DEAL_UPDATES_INTERVAL = 30 * EPOCHS_IN_DAY 51 | ``` 52 | 53 | Change the built-in market actor's computation of the subsequent maintenance epoch for a deal to 54 | be independent of the last-scheduled epoch, and instead always equal to the next epoch that is 55 | greater than the current epoch and equal to the deal's ID modulo `DEAL_UPDATES_INTERVAL`. 56 | 57 | This change does not require a stop-the-world migration at the time of activation. 58 | Instead, the maintenance for each deal will be rescheduled according to the new interval when 59 | a deal is first processed during the 2880 epochs after this change is activated. 60 | 61 | ## Design Rationale 62 | We expect this change to reduce the per-epoch gas consumption of built-in market deal maintenance 63 | by a factor of approximately 30 (from 73B to 2.4B), down to about 10% of target tipset validation time. 64 | 65 | According to https://dashboard.starboard.ventures/market-deals, as of 4 March 2023 there are 22.6 million active deals 66 | and the trailing 90-day growth rate is 94 thousand per day. 67 | If this growth rate continues, the deal count will double in approximately 240 days. 68 | Thus we might reasonably expect at least six months before built-in market deal maintenance 69 | rises to 5B gas, or 20% of target tipset validation time. 70 | During this time, we expect to develop changes to permanently remove per-deal maintenance operations from cron execution. 71 | 72 | ### Timing 73 | As the cron workload is expected to increase as more deals come on board, a short-term mitigation is necessary. 74 | It is not possible to specify a fixed threshold after which this cron execution would tangibly affect network participants, 75 | but it is well beyond our comfort zone already. 76 | 77 | Developing and deploying a permanent resolution to this issue will take more time than we think 78 | is prudent to allow the situation to continue. 79 | 80 | ### Simplicity and alternatives 81 | As a temporary resolution, this proposal aims for maximum simplicity. 82 | Leaving the state schema and all essential operations intact makes this a tightly scoped change 83 | that presents minimal risk. 84 | 85 | We considered an alternative of splitting the built-in market's deals into two groups: 86 | those that have non-zero payments to process (about 2% of deals today), and those that don’t. 87 | We rejected this option because it is significantly more complex that this proposal, 88 | while still offering only a temporary solution to the problem. 89 | 90 | ## Backwards Compatibility 91 | This proposal changes the behaviour of the built-in actors and thus requires a network upgrade. 92 | It does not change the state schema or interpretation, or require any migration. 93 | 94 | Off-chain parties that relied on daily settlement of deal payments may need to adapt to new assumptions. 95 | 96 | ## Test Cases 97 | To be provided with implementation. 98 | 99 | ## Security Considerations 100 | The scheduling of cost-free execution is subject to risk that some party could influence the schedule 101 | in order to overload some epochs with excessive work. 102 | This risk is already considered in scheduling of deal maintenance according to deal ID modulo some interval. 103 | This proposal does not change the security of this scheme. 104 | 105 | This change aims to improve blockchain availability by decreasing the expected computational work of 106 | tipset validation to approximately 40% of the current level. 107 | 108 | ## Incentive Considerations 109 | None. 110 | 111 | ## Product Considerations 112 | This proposal reduces the built-in market's service level to participants, 113 | increasing the interval between automatic settlements from 1 day to 30 days. 114 | For the small proportion of deals that have non-zero payments, this will delay the availability 115 | to storage providers of payments for active deals, and the return to clients of funds for aborted deals. 116 | 117 | If the maintenance period were to be extended much further, 118 | it might be necessary to add externally-invoked methods for explicit settlement. 119 | We expect this to be a part of any subsequent permanent resolution to this issue. 120 | We do not believe that any service level of automatic, subsidised settlement is sustainable or appropriate for the future. 121 | 122 | ## Implementation 123 | https://github.com/filecoin-project/builtin-actors/pull/1226 124 | 125 | ## Copyright 126 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 127 | -------------------------------------------------------------------------------- /FIPS/fip-0061.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0061" 3 | title: WindowPoSt Grindability Fix 4 | author: "@cryptonemo @Kubuxu @DrPeterVanNostrand @Nicola @porcuquine @vmx @arajasek" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/656 6 | status: Final 7 | type: Technical (Core) 8 | category: Core 9 | created: 2023-03-09 10 | spec-sections: 11 | - Specification 12 | --- 13 | 14 | # FIP-0061: WindowPoSt Grindability Fix 15 | 16 | ## Simple Summary 17 | 18 | This proposal makes the generation of WindowPoSt challenges independent of the order of the provided sectors, improving network security. 19 | 20 | ## Abstract 21 | 22 | It's been recognised that WindowPoSt challenge generation depends on the order of the provided sectors. This is inherent to the specified challenge generation algorithm, which had been audited but can be viewed as a bug in the protocol. If exploited by a Storage Provider, it would reduce the security guarantees of WindowPoSt. 23 | 24 | This proposal eliminates this concern by making the generation of WindowPoSt challenges independent of the order of the provided sectors. 25 | 26 | ## Motivation 27 | 28 | In short, challenge generation is the process by which node (i.e. sector data) challenges are selected for each sector. Ideally, the challenges are random and equally distributed (both across sector data and across all sealed sectors), so that each sector is challenged uniquely to ensure that all sector data has integrity over time. 29 | 30 | Given that there is a relationship between challenge generation and the sector order provided in WindowPoSt, it is feasible for malicious Storage Providers to gain influence over the challenges during WindowPoSt by re-ordering the provided sectors in a way that provides benefits beyond what is allowed in the protocol. 31 | 32 | ## Specification 33 | 34 | This proposal aims to change WindowPoSt challenge generation so that the derivation of each sector's set of challenges is independent of the other sectors challenged during WindowPoSt. 35 | 36 | This prevents all avenues of grinding WindowPoSt challenges as long as the sector stays within one deadline. 37 | 38 | ### New WindowPoSt Proof Type 39 | 40 | We propose adding the following types to the defined Registered Proofs types: 41 | 42 | ``` 43 | StackedDrgWindow2KiBV1_1 44 | StackedDrgWindow8MiBV1_1 45 | StackedDrgWindow512MiBV1_1 46 | StackedDrgWindow32GiBV1_1 47 | StackedDrgWindow64GiBV1_1 48 | ``` 49 | 50 | These new types will signal to Proofs via the API to use the updated WindowPoSt behaviour. 51 | 52 | ### Changes to Challenge Generation 53 | 54 | Differences between the currently deployed WindowPoSt challenge generation and the proposed updated challenge generation are as follows: 55 | 56 | Current algorithm for generating a sector's WindowPoSt challenges: 57 | - Note that `sector_index` and `challenge_index` are across all partitions and sectors of a WindowPoSt. 58 | 59 | ```rust 60 | 61 | let sector_index = partition_index * num_sectors_per_partition + sector_index_in_partition; 62 | let first_challenge_index = sector_index * challenge_count_per_sector + challenge_index_in_sector; 63 | let sector_challenge_indexes = first_challenge_index..first_challenge_index + challenge_count_per_sector; 64 | for challenge_index in sector_challenge_indexes { 65 | let rand_int = u64::from_le_bytes(sha256(chain_randomness || sector_id || challenge_index)[..8]); 66 | let challenge = rand_int % sector_nodes; 67 | } 68 | 69 | ``` 70 | 71 | Updated algorithm: 72 | - Note that `challenge_index` is now relative to a sector (as opposed across all WindowPoSt partitions and sectors). 73 | 74 | ```rust 75 | 76 | let sector_challenge_indexes = 0..challenge_count_per_sector; 77 | for challenge_index in sector_challenge_indexes { 78 | let rand_int = u64::from_le_bytes(sha256(chain_randomness || sector_id || challenge_index)[..8]); 79 | let challenge = rand_int % sector_nodes; 80 | } 81 | 82 | ``` 83 | 84 | ### Actor Changes 85 | 86 | The version of actors that introduces this FIP will support 2 network versions, `N` and `N+1`. 87 | The actors Runtime Policy will consider both `StackedDrgWindowV1` and `StackedDrgWindowV1_1` as valid proof types for this actors version. 88 | The _next_ actors version will not consider `V1` as valid in its Runtime Policy. 89 | 90 | At the `N` upgrade, all MinerInfos are updated to their `V1_1` PoSt Proof Type. 91 | All claims in the Power Actor are updated to be based on `V1_1` Proof Types. 92 | 93 | For network version `N`: 94 | - Miner construction: New miners with `V1` Proof types can NOT be created, only `V1_1` types are allowed. 95 | - PoSt submission: A submitted PoSt must match the `MinerInfo`'s `V1_1` Proof Type, OR the corresponding `V1` Proof Type. 96 | 97 | For network version `N+1`: 98 | - Miner construction: New miners with `V1` Proof types can NOT be created, only `V1_1` types are allowed. 99 | - PoSt submission: A submitted PoSt must match the `MinerInfo`'s `V1_1` Proof Type. 100 | 101 | ### Proof Changes 102 | 103 | The ability to prove and verify WindowPoSt with the new challenge generation algorithm will be exposed. Since this is a breaking change, a new `ApiVersion` flag is introduced to specify which challenge generation algorithm is used. A new WindowPost proof type will be defined at the proofs API layer, which will use the new challenge generation. 104 | 105 | ## Design Rationale 106 | 107 | This is a subtractive change, removing information about where the sector is placed within the proof from challenge generation, and thus removing a degree of freedom. This additional degree of freedom is what allows for possible grinding on challenges for a given sector. 108 | 109 | As it is a subtractive change, it is necessary to explore why `challenge_index` was originally taken to be across all WindowPoSt sectors. The initial design goal of challenge generation was to guarantee uniqueness of challenges; this design also left open the possibility of enforcing WindowPoSt sector ordering at the protocol-level. In addition to `challenge_index`, challenge generation depends on chain randomness and the challenged sector's SectorID. As SectorID is guaranteed to be unique within the scope of a Storage Provider (and consequently within the scope of a WindowPoSt), this FIP's proposed change preserves uniqueness of challenges via the maintained inclusion of SectorID in the challenge generation algorithm. 110 | 111 | ## Backwards Compatibility 112 | 113 | The new proof type itself is not backwards compatible with the old one. 114 | However, this change is introduced to the network in a two-phase network upgrade, with a rollover period in which both proof types are accepted. 115 | 116 | ## Test Cases 117 | 118 | Test cases of proofs are included in the Proofs code. 119 | Test cases for Actors are TBD. 120 | 121 | ## Security Considerations 122 | 123 | While we believe this issue cannot be successfully exploited for gain due to limitations imposed by other parts of the Filecoin system, the security of individual system components (e.g. WindowPoSt) is important for maintaining a secure network. 124 | 125 | ## Incentive Considerations 126 | 127 | This proposal does not affect the current incentive system of the Filecoin network. 128 | 129 | ## Product Considerations 130 | 131 | This proposal has no product implications. 132 | 133 | ## Implementations 134 | 135 | Proofs: TODO 136 | Actors: TODO 137 | 138 | Clients are recommended to start generating `V1_1` Proof types as soon as the network 139 | upgrades to the first phase of the two-stage network upgrade proposed here. 140 | 141 | ## Copyright Waiver 142 | 143 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 144 | -------------------------------------------------------------------------------- /FIPS/fip-0062.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0062" 3 | title: Fallback Method Handler for the Multisig Actor 4 | author: Dimitris Vyzovitis (@vyzo), Raúl Kripalani (@raulk) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/671 6 | status: Final 7 | type: Technical Core 8 | created: 2023-03-20 9 | spec-sections: 10 | - https://spec.filecoin.io/#section-glossary.multisig-actor 11 | requires: FIP-0050 12 | --- 13 | 14 | # FIP-0062: Fallback Method Handler for the Multisig Actor 15 | 16 | ## Simple Summary 17 | 18 | Adds a no-op handler for method numbers higher or equal to 2^24 (the first exported method as per [FRC-0042]) to the multisig actor. 19 | This change enables the built-in multisig actor to receive value from EVM runtime actors (i.e. smart contracts), Eth accounts, and placeholders. 20 | It also brings them in line with the equivalent behaviour of account actors, as of [FIP-0050]. 21 | 22 | ## Abstract 23 | 24 | We introduce a no-op handler in the built-in multisig actor for calls where `MethodNum >= 2^24`. 25 | Such calls are now no longer rejected, and instead return successfully. 26 | 27 | ## Change Motivation 28 | 29 | This change is needed to normalise interactions from EVM runtime actors (i.e. smart contracts), Eth accounts, and placeholders with the multisig actor. 30 | These actors set `MethodNum = FRC-42("InvokeEVM")` by default when performing outbound calls, including simple value transfers. 31 | Refer to [FIP-0054] and [FIP-0055] for background. 32 | 33 | Prior to this FIP, built-in multisig actor would reject such calls, causing the immediate reversal of a value transfer. 34 | 35 | This limitation was first encountered in the wild when deploying a Wrapped FIL (WFIL) token. 36 | While a multisig can hold WFIL tokens, unwrapping them into the native FIL coin causes a value transfer to the multisig, carrying the above method number. 37 | This would be rejected unconditionally. 38 | 39 | This change also brings multisigs in line with the equivalent no-op behaviour implemented for account actors in [FIP-0050]. 40 | 41 | ## Specification 42 | 43 | Given: 44 | 45 | ``` 46 | pub const FIRST_EXPORTED_METHOD_NUMBER: MethodNum = 1 << 24; 47 | ``` 48 | 49 | Augment the built-in multisig actor to handle calls on method numbers higher or equal to `FIRST_EXPORTED_METHOD_NUMBER` by immediately returning exit code 0 (Ok) and no return value, independently of the sender, origin, or call parameters. 50 | 51 | Methods below `FIRST_EXPORTED_METHOD_NUMBER` continue to be handled as-is. 52 | 53 | ## Design Rationale 54 | 55 | We adopt the simplest solution possible to achieve the goal. 56 | Precedent exists in the account actor as of network version 18. 57 | 58 | ### Payment channels 59 | 60 | A previous version of this FIP included payment channels in scope. 61 | However, this conflicted with their deliberate non-implementation of the Universal Receiver Hook, specified in [FIP-0053], motivated by their inability to manage such tokens if received. 62 | Given the prevalent disuse of the payment channel actor on mainnet, we do not see immediate justification to resolve that conflict, and therefore choose to descope the payment channel implementation in this FIP. 63 | 64 | ## Backwards Compatibility 65 | 66 | While this is a change in behaviour and interface, it is strictly expansive and no backwards compatibility issues are expected. 67 | 68 | ## Test Cases 69 | 70 | - Send an arbitrary message, with method number equal to the minimum exported method number, which should be accepted returning an empty value. 71 | - Send an arbitrary message, with method number over the minimum exported method number, which should be accepted returning an empty value. 72 | - Send an arbitrary message, with method number below the minimum exported method number, which should be rejected. 73 | 74 | ## Security Considerations 75 | 76 | None. 77 | 78 | ## Incentive Considerations 79 | 80 | None. 81 | 82 | ## Product Considerations 83 | 84 | Improves the interoperability of multisigs actors with Filecoin EVM runtime actors (i.e. smart contracts), Eth accounts, and placeholders. 85 | 86 | ## Implementation 87 | 88 | https://github.com/filecoin-project/builtin-actors/pull/1252 89 | 90 | ## Copyright 91 | 92 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 93 | 94 | [FIP-0050]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0050.md 95 | [FIP-0054]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0054.md 96 | [FIP-0055]: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md 97 | [FRC-0042]: https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0042.md 98 | [FRC-0053]: https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0053.md 99 | -------------------------------------------------------------------------------- /FIPS/fip-0065.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0065" 3 | title: Ignore built-in market locked balance in circulating supply calculation 4 | author: "Alex North <@anorth>" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/719 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2023-06-16 10 | --- 11 | 12 | # FIP-0065: Ignore built-in market locked balance in circulating supply calculation 13 | 14 | ## Simple Summary 15 | Ignore the built-in market actor's locked balances in the network circulating supply calculation, 16 | in preparation for direct commitment of data into sectors without a corresponding built-in market deal. 17 | 18 | ## Abstract 19 | The built-in storage market actor's minimum deal collateral currently functions as a mandatory data assurance mechanism. 20 | The market's collateral and deal payment balances are subtracted from total token supply when calculating the network circulating supply. 21 | This proposal is to simplify the network circulating supply definition by _ignoring_ the built-in market's locked balance. 22 | This is logical support for subsequent protocol changes that would allow storage providers to 23 | commit data without a built-in market deal or the associated collateral. 24 | The built-in market actor does not warrant special treatment in the circulating supply calculations. 25 | 26 | ## Change Motivation 27 | The built-in market actor is expensive in gas, and offers only basic functionality. 28 | It cannot support the expansion in usage or functionality that network participants hope for, 29 | and may be replaced by more efficient and flexible user-programmed actors over time. 30 | Work is in progress to permit SPs to commit data directly into sectors without a built-in market deal, 31 | With such changes, the built-in market actor would no longer occupy a privileged position as a required intermediary. 32 | 33 | The primary motivation for this proposal is simplicity: 34 | deal collateral and escrow are only a very small fraction of the network's locked tokens. 35 | They are not justified to treat as a special case in the circulating supply calculation, 36 | especially as the built-in market may represent only a small fraction of data commitments in the future. 37 | Other storage application contracts may represent much more, yet their balances would be ignored in this calculation. 38 | 39 | The built-in market's balances represent a small and likely decreasing fraction of locked tokens, 40 | and the protocol will be simpler if they are ignored. 41 | 42 | ## Specification 43 | The network circulating supply is currently specified as 44 | 45 | ``` 46 | CirculatingSupply = Vested + Mined - Burnt - Locked 47 | where 48 | Locked = PledgeCollateral + ProviderDealCollateral + ClientDealCollateral + PendingDealPayment 49 | ``` 50 | 51 | The calculation of `Locked` is changed to account only for pledge collateral (initial pledge plus vesting rewards): 52 | ``` 53 | Locked = PledgeCollateral 54 | ``` 55 | 56 | ## Design Rationale 57 | ### Remove built-in market balances from the network circulating supply calculation 58 | The built-in market's locked balances are a trivial level of the network's total locked amount. 59 | Given its cost and limitations, it is unlikely that the built-in market actor could account for 60 | a large share of the network's data commitments in the future, 61 | reducing the relevance of its balances even further. 62 | We can simplify the network's specification and implementation by removing them. 63 | 64 | As of epoch 2911690, the built-in market's locked balances are: 65 | 66 | | Built-in market account | Balance | 67 | |-------------------------------|-------------| 68 | | TotalClientLockedCollateral | 0 FIL | 69 | | TotalProviderLockedCollateral | 317,498 FIL | 70 | | TotalClientStorageFee | 38 FIL | 71 | | Total | 317,536 FIL | 72 | 73 | This amounts to a tiny fraction of network stocks: 74 | 75 | | Network stock | Amount | Market fraction | 76 | |--------------------|-----------------|-----------------| 77 | | Total locked | 150,981,531 FIL | 0.21% | 78 | | Circulating supply | 473,321,502 FIL | 0.067% | 79 | 80 | Ignoring the market's balances in these calculation will thus have negligible effect on downstream values 81 | such as the sector initial pledge requirement. 82 | 83 | Ignoring these balances in the calculation of network circulating supply will not actually unlock any tokens, 84 | it will only add them to the collection of tokens that are locked in ways that the network core does not account for. 85 | 86 | ### Preparation for direct data commitments 87 | The built-in market actor constrains the data that storage providers (SPs) can store in sectors, limiting their utility and value, 88 | and adding large costs in gas and complexity to the network core. 89 | This proposal prepares for user-programmed smart contracts to act as markets or other data applications, 90 | unconstrained by the built-in market's functionality or cost. 91 | 92 | ## Backwards Compatibility 93 | This proposal changes the calculation of the network's circulating supply, which forms part of the consensus rules. 94 | It thus requires a coordinated network upgrade. 95 | 96 | No on-chain interfaces or state are altered. 97 | 98 | ## Test Cases 99 | The only relevant test is that the circulating supply calculation ignores balances locked in the built-in market actor. 100 | 101 | ## Security Considerations 102 | None. 103 | 104 | ## Incentive Considerations 105 | This proposal will increase the calculated circulating supply by approximately 320,000 FIL (0.067%, or ~7/10,000). 106 | This will in turn increase the sector initial pledge requirement by a slightly smaller fraction. 107 | This is considered inconsequential. 108 | 109 | This proposal does not change any incentives associated with accepting or completing a deal with the built-in storage market actor. 110 | 111 | ## Product Considerations 112 | This proposal, or some alternative, is logical preparation for clients and providers arranging 113 | storage directly, or via a user-programmed smart contract data application, 114 | that can avoid the costs and limitations associated with mandatory use of the built-in market actor. 115 | 116 | The built-in market actor will continue to require minimum deal collateral, so in the near term all deals will as well. 117 | Participants and developers will need to explicitly alter their arrangements should they wish to make 118 | arrangements that uses a lesser amount, when that becomes possible. 119 | 120 | ## Implementation 121 | TBA. 122 | 123 | ## Copyright 124 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 125 | -------------------------------------------------------------------------------- /FIPS/fip-0077.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0077" 3 | title: Add Cost Opportunity For New Miner Creation 4 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/780 5 | author: "Zac <@remakeZK>" 6 | status: Last Call 7 | type: Technical 8 | category: Core 9 | created: 2023-08-21 10 | --- 11 | 12 | # FIP-0077: Add Cost Opportunity For New Miner Creation 13 | 14 | ## Simple Summary 15 | 16 | This proposal implements a deposit requirement for creating new miner actors to prevent unnecessary miner ID creation and potential network spam attacks. 17 | 18 | ## Abstract 19 | 20 | By requiring a deposit when creating a new miner actor, this proposal addresses three key issues: 21 | 22 | 1. Reduces the network chain storage burden caused by inactive miner actors 23 | 2. Decreases resource waste and potential gas cost increases resulting from unused miner actors 24 | 3. Mitigates the risk of network congestion attacks where an attacker creates numerous low-cost miner actors 25 | 26 | The deposit is calculated based on the initial pledge required for 10 TiB of storage capacity, and is vested over 180 days. This introduces an opportunity cost that discourages frivolous miner creation while allowing legitimate storage providers to recover their deposit over time. 27 | 28 | ## Change Motivation 29 | 30 | In March 2021, the Filecoin network a [experienced spam attack](https://github.com/filecoin-project/FIPs/discussions/780#discussioncomment-6787043) where thousands of `CreateMiner` messages were sent at minimal cost. This resulted in increased base fees, congestion in the message pool, and reduced chain performance. 31 | 32 | As of August 2023, statistics from FilScan showed that out of 601,131 total miner IDs, only 4,862 (0.8%) were actively being used. The trend of creating but not using miner IDs has continued, with only 3.7% of newly created miner IDs being activated in the two months prior to that analysis. 33 | 34 | total_in_use 35 | recent_two_months 36 | 37 | Many users create multiple miner IDs to secure preferred IDs or favorable deadline schedules, consuming network resources without contributing value. Moreover, the absence of creation costs exposes the network to potential spam attacks that could cause congestion and disrupt important messages like WindowPoSt submissions from landing on-chain. 38 | 39 | ## Specification 40 | 41 | The proposal requires a deposit when creating a new miner actor: 42 | 43 | 1. **Deposit Amount Calculation:** 44 | - The deposit is based on the initial pledge required for storing 10 TiB (defined by `MINIMUM_CONSENSUS_POWER` constant) 45 | - This amount is calculated using `StateMinerInitialPledgeCollateral`, which considers the current network economics 46 | - As of March 2024, this amounts to approximately 62 FIL (10 TiB * 0.1958 FIL/32 GiB) 47 | 48 | 2. **Vesting Schedule:** 49 | - The deposited funds are locked in the miner actor's vesting table 50 | - The funds vest linearly over 180 days, similar to block rewards 51 | - This creates an opportunity cost while ensuring the funds are eventually returned to the storage provider 52 | 53 | 3. **Implementation Behavior:** 54 | - If insufficient funds are provided, the CreateMiner operation fails with an "insufficient funds" error 55 | - If excess funds are provided, the required amount is locked and the remainder is available in the miner's balance 56 | - The deposit is processed using the existing vesting mechanism rather than creating a new mechanism 57 | 58 | ## Design Rationale 59 | 60 | The design leverages the existing vesting mechanisms to minimize implementation complexity while creating sufficient economic friction to prevent abuse. By requiring a deposit that vests over time: 61 | 62 | 1. Users must evaluate whether a new miner ID justifies the opportunity cost of having funds locked for 180 days 63 | 2. The more miner actors a user creates, the more funds they need to lock, increasing the opportunity cost 64 | 3. The deposit is high enough to prevent spam attacks but low enough not to be prohibitive for legitimate storage providers 65 | 4. Using the vesting mechanism rather than burning funds ensures that legitimate providers eventually recover their deposit 66 | 67 | This approach aligns incentives by encouraging the creation of miner actors only when they will be actively used, while not permanently removing capital from storage providers. 68 | 69 | ## Backwards Compatibility 70 | 71 | This change is not backwards compatible as it introduces a new requirement for creating miner actors. However, it does not affect existing miner actors or their operations. 72 | 73 | The deposit requirement applies to all new miner creations, including those for committed capacity (CC) sectors. While this creates an additional barrier to entry, the cost is relatively moderate compared to the hardware and operational investments needed to run a storage provider. Since the funds eventually vest back to the provider, this represents an opportunity cost rather than a capital cost. 74 | 75 | ## Test Cases 76 | 77 | Test cases have been implemented to verify: 78 | - Miner creation succeeds when sufficient balance is provided 79 | - Miner creation fails with insufficient balance 80 | - The deposit is correctly added to the vesting table 81 | - The deposit vests over the correct period 82 | - Tests have been updated to accommodate the new parameter in MinerConstructorParams 83 | 84 | ## Implementation 85 | 86 | This proposal has been implemented in the following pull request to builtin-actors: https://github.com/filecoin-project/builtin-actors/pull/1398 87 | 88 | The implementation: 89 | 1. Adds a `network_qap` parameter to MinerConstructorParams to calculate the deposit 90 | 2. Creates a new `calculate_create_miner_deposit` function that determines the required deposit 91 | 3. Locks the deposit in the miner's vesting table during construction 92 | 4. Updates tests to accommodate the new behavior 93 | 94 | ## Security Considerations 95 | 96 | This proposal improves network security by preventing spam attacks that could congest the network through mass miner creation. The implementation uses existing, well-tested mechanisms for handling vesting funds, minimizing the risk of introducing new vulnerabilities. 97 | 98 | ## Incentive Considerations 99 | 100 | The proposal creates incentive alignment by: 101 | 1. Discouraging the creation of miner actors that won't be used 102 | 2. Creating an economic cost for potential attackers 103 | 3. Encouraging storage providers to reuse existing miner IDs rather than creating new ones 104 | 4. Not permanently removing capital from legitimate providers, as the deposit eventually vests 105 | 106 | The deposit amount is calibrated to be significant enough to deter spam but modest enough that it won't prevent legitimate storage providers from joining the network. 107 | 108 | ## Product Considerations 109 | 110 | From a product perspective, this change: 111 | 1. Reduces the creation of unused miner IDs, leading to a cleaner and more efficient network 112 | 2. Makes the network more resistant to spam attacks 113 | 3. Encourages on-demand account creation, where new miner actors are created only when needed 114 | 4. Discourages practices like creating multiple miners to get preferred IDs or deadline schedules 115 | 116 | While this creates an additional step for new storage providers, the deposit eventually returns to them through the vesting mechanism, making it an opportunity cost rather than a permanent expense. 117 | 118 | ## Copyright 119 | 120 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 121 | -------------------------------------------------------------------------------- /FIPS/fip-0084.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | fip: "0084" 4 | title: Remove Storage Miner Actor Method `ProveCommitSectors` 5 | author: Jennifer Wang (@jennijuju) 6 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/899 7 | status: Final 8 | type: Technical 9 | category: Core 10 | created: 2023-09-03 11 | requires: FIP-0076 12 | --- 13 | 14 | # Remove Storage Miner Actor Method `ProveCommitSectors` 15 | 16 | ## Simple Summary 17 | 18 | Remove *`ProveCommitSector` (method 7)* in favor of `ProveCommitSectors3` (method 34) and `ProveCommitAggregate`. This change ensures that single PoRep validations and single sector activations are executed synchronously and billed to the caller, instead of being executed asynchronously via a cron call to the actor. 19 | 20 | ## Abstract 21 | 22 | Currently, `ProveCommitSector` accepts a single PoRep proof for an individual sector, validates the proof, and activates the sector along with the deals inside it via a cron call to the power actor. In contrast, when submitting an aggregated PoRep with `ProveCommitAggregate`, all proof validation and sector activation are executed synchronously and the costs are billed to the caller. This creates an imbalance in the sector activation gas subsidy available to different onboarding methods, and also adds unnecessary work to unpaid network cron jobs. 23 | 24 | FIP-0076 provides an alternative, synchronous activation path for non-aggregated proofs. This proposal subsequently removes the ProveCommitSector method once and thus the imbalance. 25 | 26 | ## Change Motivation 27 | 28 | Since the FVM launch, all computations are properly charged and it has become evident that even below the batch balancer base fee threshold, the per sector commit cost via `ProveCommitAggregate` is higher than `ProveCommitSector`. 29 | 30 | The chain explicitly charge gas (discounted) for the single proof validation when it is submitted, so it’s both bounded and paid for. However, the **state updates associated with sector activation are not metered**, because they execute in cron. The execution cost of this activation varies significantly with the deal content of the sector, but the storage provider doesn’t pay gas for this. On the other hand, aggregated proof validation also activates the sector synchronously, for which the SP pays the gas cost. Thus, single-sector onboarding is subsidized relative to aggregation, but aggregation would otherwise efficiently support much higher onboarding rates. The proposed change will resolve the imbalanced cost of sector activation using different onboarding methods and make proof aggregation financially sensible again. 31 | 32 | In addition, the activation jobs are being executed in cron which means the chain is subsidi[sz]ing the job cost. This is not a desirable subsidy incentive as it leads to the inefficient use of the chain validation resources by discouraging aggregation of proofs. Thus, the proposed the change also removes unnecessary yet expensive sector and deal activation work from the network cron, which prevents the network from potential cron blowup in the long term as well. 33 | 34 | - 35 | 36 | ## Specification 37 | 38 | Drop the `ProveCommitSector` [function](https://github.com/filecoin-project/builtin-actors/blob/807630512ba0df9a2d41836f7591c3607ddb0d4f/actors/miner/src/lib.rs#L1775-L1828). 39 | 40 | ## Design Rationale 41 | 42 | There are other ways to achieve our goal, like modifying `ProveCommitSector` to activate sectors and deals synchronously. However, with FIP-0076 introducing an alternative method that allows activating sectors with non-aggregated proof synchronously with other richer functionalities, along with the existence of `ProveCommitAggregate` that also allows synchronous activation, the old method is redundant and does not bring much onto the table. Therefore, reducing to one way and dropping the limitted pathway `ProveCommitSector` to redduce actor code complexity, implementation friction and risk and etc is preferred. 43 | 44 | ## Backwards Compatibility 45 | 46 | The deprecation of this method MUST happen after the methods from FIP-0076 are available in the network and adopted by the clients. 47 | 48 | This proposal requires a network upgrade to deploy the new built-in actor code. 49 | 50 | ## Test Cases 51 | 52 | 53 | Calling `ProveCommitSector` will fail with ***USR_UNHANDLED_MESSAGE.*** 54 | 55 | ## Security Considerations 56 | 57 | This FIP avoids single PoRep proof verification in cron, which reduces the free computations that are occupying the network bandwidth and the possibility of unexpected network performance issues. 58 | 59 | ## Incentive Considerations 60 | 61 | This FIP will enforce storage activation fees to be paid by the callers rather than having an imbalanced network subsidy. This means storage providers who only onboard sectors via `ProveCommitSector` will start to pay for sector proof validation and sector/deal activation, which is a gas cost increase from ~71M to ~196M based on the current implementation. However, the activation cost is expected to be lower with the direct data onboarding flow via the `ProveCommitSectors2` method, and storage providers and their data clients may opt-out of f05 deal activation, which would result in significantly lower gas cost. 62 | 63 | ## Product Considerations 64 | 65 | All features provided by Filecoin continue to function as expected. Having only one entry point for onoarding non-aggregated sectors is simpler than two for both implementations & SP stack integrations & support. 66 | 67 | 68 | ## Implementation 69 | 70 | 71 | 72 | Note: Calling `ProveCommitSector` after this FIP is finalized in an upgrade should fail with some user error message, i.e: METHOD_NOT_FOUND. 73 | 74 | ## Others 75 | 76 | ### Finalization of this FIP 77 | 78 | As mentioned, this FIP is dependent on FIP-0076 and precisely, the introduction of the `ProveCommitSectors3` method. It will be sensible to only finalize this FIP after the `ProveCommitSector3` has been finalized in the network and used in production, and proven to be functional as expected. 79 | 80 | ## TODO 81 | 82 | 83 | 84 | 85 | ## Copyright 86 | 87 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 88 | -------------------------------------------------------------------------------- /FIPS/fip-0085.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0085" 3 | title: Convert f090 Mining Reserve actor to a keyless account actor 4 | author: Jennifer Wang (@jennijuju), Jon Victor (@jnthnvctr) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/901 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2024-01-04 10 | --- 11 | 12 | # Convert f090 Mining Reserve actor to a keyless account actor 13 | 14 | ## Simple Summary 15 | 16 | Covert f090 (FIL mining reserve) actor type from a _multisig_ to an _account_ that is keyless (like `f099`). 17 | 18 | 19 | ## Abstract 20 | 21 | At the moment, the actor holding the FIL mining reserve is a _multisig_ actor sitting at address `f090`. It has 3 signers and an approval threshold of 2. All three signers are _secp256k1 account_ actors, secured by corresponding wallet keys. This setup leaves the ownership and control over the mining reserve funds to signers of the _multisig_ actor, which undermines the decentralized governance principle over network funds, and creates potential security leaks. 22 | 23 | This FIP proposes to alter the type of the FIL mining reserve actor from the aforementioned multisig to a keyless account actor, and further transfer the ownership, control and governance of the funds reserved from the signers of the multisig back to the network's participants via community governance. 24 | 25 | 26 | ## Change Motivation 27 | 28 | As documented in the spec [here](https://spec.filecoin.io/#section-systems.filecoin_token.token_allocation), upon network launch, a pool of tokens was allocated as a Mining Reserve to support the maintenance of a robust Filecoin economy. It also mentions, "It will be up to the community to determine in the future how to distribute those tokens, through Filecoin improvement proposals (FIPs) or similar decentralized decision-making processes." It is worth noting that when the spec was written and when the network was first launched, the FIP process was not yet well-designed nor matured to support network governance, and significant improvements have been made since then. 29 | 30 | At the moment, the actor holding the FIL mining reserve is `f090`, which is a multisig actor with 3 signers and an approval threshold of 2. All three signers are account actors, with wallet keys to those accounts. This means that 2 out of 3 _individuals_ hold the keys to move funds and change the terms of f090. They can do so without a governance process or any protocol-level safeguards, which conflicts with the decentralized governance principle outlined in the spec. It further creates security concerns for the whole Filecoin network, in that a malicious actor that compromises 2 out of the 3 signer keys of f090 gains the ability to cause serious economic and reputational damage. 31 | 32 | In addition, having the reserve held in a multisig also means the use of the reserve may need to be managed via signed transactions, creating significant operational overhead (and again deviating from the governance principle). 33 | 34 | This proposal is simple: to convert the f090 actor type from a *multisig* to an *account* type (without any keys, like `f099`), so that any changes to the mining reserve must be proposed via the appropriate FIP and network upgrade processes. 35 | 36 | ## Specification 37 | 38 | Convert f090 actor type from a _multisig_ to _account_ type. The new account actor should be keyless, like `f099`. 39 | 40 | ```rust 41 | pub struct State { 42 | pub address: Address, 43 | } 44 | ``` 45 | 46 | The new f090 account actor will contain a self-reference to its ID address in the `address` field. 47 | 48 | ## Design Rationale 49 | 50 | The choice of making f090 actor to be a keyless account type is to ensure that no single actor/entity owns the control over Filecoin mining reserves. The use of the mining reserves will be proposed and governed by the FIP process, and further adopted by the network via network upgrades. 51 | 52 | ## Backwards Compatibility 53 | 54 | This change is not backwards compatible. Upon the activation of this FIP in a network upgrade: 55 | - the actor type of f090 will be migrated from _multisig_ to _account_. 56 | - the existing signers of the f090 multisig will no longer be able to perform operations on the actor 57 | 58 | ## Test Cases 59 | 60 | - Get actor cid of f090 should return actor code cid of an `account` 61 | 62 | ## Security Considerations 63 | 64 | This proposal improves the network security by removing the ownership and control of 15% of the total network token supply from 3 individuals and putting it under the control of network participants via the appropriate governance processes. 65 | 66 | 67 | ## Product Considerations 68 | 69 | This proposal places governance of the reserved funds entirely in hands of the network participants rather than 3 key owners, thus providing greater transparency and assurance of community consultation and deliberation in appropriate future disbursement of the funds. 70 | 71 | ## Implementation 72 | 73 | TODO 74 | 75 | ## Copyright 76 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 77 | -------------------------------------------------------------------------------- /FIPS/fip-0094.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0094" 3 | title: Add Support for EIP-5656 (MCOPY Opcode) in the FEVM 4 | author: Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1025 6 | status: Final 7 | type: Technical 8 | category: Core 9 | created: 2024-08-22 10 | --- 11 | 12 | # FIP-0094: Add Support for EIP-5656 (MCOPY Opcode) in the FEVM 13 | 14 | ## Simple Summary 15 | This proposal aims to introduce the `MCOPY` opcode, as defined in [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656), into the Filecoin Ethereum Virtual Machine (FEVM). This opcode allows for efficient memory copying within the FEVM, enhancing performance for smart contracts. 16 | 17 | ## Abstract 18 | The `MCOPY` opcode provides a more efficient mechanism for memory copying within smart contracts. This proposal suggests integrating `MCOPY` into the FEVM, ensuring compatibility with Solidity versions v0.8.25 and later, which rely on this opcode for certain operations. 19 | 20 | ## Change Motivation 21 | As Solidity continues to evolve, the use of the `MCOPY` opcode has become increasingly common. Without support for this opcode, developers may face compatibility issues when deploying smart contracts to the Filecoin network, particularly if they use the latest Solidity compiler versions. This proposal addresses the need for maintaining compatibility with Ethereum's tooling and runtime. 22 | 23 | ## Specification 24 | 25 | ### Opcode Description 26 | 27 | - **Opcode:** `MCOPY` 28 | - **Opcode Hex:** `0x5E` 29 | - **Stack Input:** 30 | - `dst`: Destination offset in memory 31 | - `src`: Source offset in memory 32 | - `length`: Number of bytes to copy 33 | - **Output:** None 34 | 35 | ### Implementation Details 36 | 37 | The `MCOPY` opcode is implemented within the FEVM interpreter. It performs memory copying operations similar to the existing memory manipulation opcodes (`MLOAD`, `MSTORE`, etc.). It handles overlapping memory regions appropriately, ensuring that data is copied as expected, even in edge cases. The implementation follows the specification laid out in [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656). 38 | 39 | #### Remarks on MCOPY Implementation 40 | 41 | Similar to other memory manipulation operations, `MCOPY` interacts with the FEVM's memory management system. It is designed to handle the following scenarios: 42 | 43 | 1. **Memory Expansion:** If the destination or source memory regions extend beyond the currently allocated memory, the memory is expanded as necessary to accommodate the operation. 44 | 45 | 2. **Overlapping Regions:** `MCOPY` ensures correct behavior when the source and destination regions overlap, copying data in a manner that avoids corruption. 46 | 47 | 3. **Error Handling:** The opcode includes checks to prevent out-of-bounds memory access, raising appropriate errors if invalid memory regions are specified. 48 | 49 | ## Design Rationale 50 | The addition of the `MCOPY` opcode in the FEVM aligns with the need for compatibility with the latest Solidity features and optimizations. The decision to implement this opcode reflects the broader goal of maintaining parity with Ethereum’s EVM while ensuring that Filecoin remains a viable platform for developers using modern Solidity compilers. 51 | 52 | ## Backwards Compatibility 53 | The introduction of the `MCOPY` opcode does not affect existing contracts that do not utilize this opcode. Contracts compiled with Solidity versions prior to v0.8.25 will continue to function as intended without modification. However, contracts using `MCOPY` will require the opcode to be present in the FEVM to execute correctly. 54 | 55 | ## Test Cases 56 | A series of test cases will be provided to ensure that the `MCOPY` opcode functions as expected under various scenarios. These test cases will include non-overlapping memory copy, overlapping memory copy, out-of-bounds source handling, and memory expansion. 57 | 58 | ## Security Considerations 59 | Security implications for the `MCOPY` opcode are similar to other memory manipulation operations. Special care will be taken to ensure that overlapping memory regions are handled safely, preventing data corruption. Additionally, the implementation will include checks to prevent out-of-bounds memory access, which could otherwise lead to unexpected behavior or security vulnerabilities. 60 | 61 | ## Incentive Considerations 62 | The addition of the `MCOPY` opcode is expected to enhance the performance of smart contracts running on the FEVM, indirectly contributing to more efficient and reliable use of Filecoin's resources. By enabling more efficient memory operations, this opcode supports the development of complex contracts without incurring unnecessary performance penalties. 63 | 64 | ## Product Considerations 65 | Implementing the `MCOPY` opcode aligns with the goal of making Filecoin a more attractive platform for developers by ensuring compatibility with Ethereum's latest features. This change supports the development of advanced storage-related applications and services, as developers can rely on the latest Solidity optimizations without concern for compatibility issues. 66 | 67 | ## Implementation 68 | The reference implementation for the `MCOPY` opcode is available in the following pull request: https://github.com/filecoin-project/builtin-actors/pull/1572. The implementation is designed to handle various edge cases, including overlapping memory regions and out-of-bounds memory access, ensuring robust and reliable operation. 69 | 70 | ## Copyright 71 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 72 | -------------------------------------------------------------------------------- /FIPS/fip-0095.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0095" 3 | title: Add FEVM precompile to fetch beacon digest from chain history 4 | author: "@ZenGround0, @anorth" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1051 6 | status: Final 7 | type: Technical Core 8 | created: 2024-08-26 9 | --- 10 | 11 | # FIP-0095: Add FEVM precompile to fetch beacon digest from chain history 12 | 13 | ## Simple Summary 14 | 15 | Adds a precompile to the EVM actor to allow EVM smart contracts to fetch drand beacon digests from the chain history. 16 | 17 | ## Abstract 18 | The FVM exposes a syscall for fetching the digest of a drand beacon included in some prior Filecoin chain header. 19 | The built-in actors use this facility to provide randomness for storage proofs. 20 | This proposal introduces an EVM actor precompile exposing this functionality to user-deployed smart contracts 21 | so that they can also use random challenges for other types of proofs. 22 | 23 | ## Change Motivation 24 | A source of un-biasable randomness is a useful primitive in proofs of service, 25 | as evidenced by its use in Filecoin's existing proof of storage protocol. 26 | The Filecoin blockchain already embodies all the infrastructure to provide this primitive, 27 | but is missing the hook-up to where user-deployed smart contracts can use it. 28 | This proposal provides that hook-up. 29 | 30 | The EVM does already provide a PREVRANDAO opcode, but this is limited to access randomness from the immediately prior epoch. 31 | This primitive is not suited to protocols where the randomness is incorporated into off-chain protocols, 32 | since the prover must observe the randomness, use it for computation, and submit a message that must be included in the immediate next epoch 33 | in order for a smart contract to be able to verify that the correct randomness source was used. 34 | Access to values from prior epochs allows for protocols that commit to a challenge before it is used, 35 | take more than one epoch to complete, and/or are robust to short-lived chain instability or forks. 36 | 37 | The concrete use case motivating the authors is to make it possible to build a proof-of-data possession in user-deployed smart contracts. 38 | 39 | ## Specification 40 | A new precompile is added to the built-in EVM actor, which implements all user-deployed smart contracts. 41 | 42 | The precompile is callable at Ethereum address `0xfe00..06`. 43 | 44 | | Param | Value | 45 | |------------------|---------------------------| 46 | | epoch | u256 - low i64 | 47 | 48 | The call errors with `PrecompileError::InvalidInput` if the epoch is not a valid, prior epoch number. 49 | 50 | This calls directly to the FVM's `get_beacon_randomness` syscall. 51 | 52 | ### Syscall Behaviour 53 | This section documents the semantics of the existing `get_beacon_randomness` syscall. 54 | It is descriptive, not normative. 55 | This FIP does not propose any change to the implemented behaviour, even if it differs from this description. 56 | 57 | The `get_beacon_randomness` syscall returns a Blake2b-256 hash digest of the 58 | randomness value from the drand beacon corresponding to the requested Filecoin epoch. 59 | This syscall has a gas cost function that scales linearly with the number of epochs that have elapsed since 60 | the requested epoch. 61 | 62 | #### Canonical behaviour 63 | Each Filecoin epoch maps to a drand round number. 64 | The drand round number for an epoch is given by `(epoch_time - drand_genesis_time) / drand_period + 1`. 65 | The drand beacon for this round number is expected to be found in the block header `BeaconEntries` field 66 | in every block in the tipset at that epoch. 67 | If the epoch number addresses an empty tipset, the beacon is found in the next non-empty tipset, 68 | which `BeaconEntries` includes a beacon for each preceding null round. 69 | 70 | Note that not every drand beacon necessarily appears in a Filecoin tipset. 71 | Where the drand network has a faster epoch time than Filecoin, as is the case with Filecoin mainnet and 72 | the drand quicknet, only those drand beacons that correspond to a Filecoin tipset are accessible. 73 | 74 | #### Filecoin mainnet historical behaviour 75 | Due to changes in protocol specification over time, nodes participating in the Filecoin mainnet 76 | do not implement the canonical behaviour for all requested epochs. 77 | 78 | When the requested epoch corresponds to a null round and is: 79 | - prior to 892800 (network version 13): selects the last beacon entry from the preceding non-empty tipset; 80 | - between 892800 (v13) and 1231620 (v14): selects the last beacon entry from the next subsequent non-empty tipset; 81 | - between 1231620 (v14) and 1594680 (v15): calculates drand round number as `(epoch_time - drand_genesis_time) / drand_period` (off-by-one) 82 | 83 | In these cases, the beacon round number will not canonically correspond to the Filecoin epoch number. 84 | For requests from epoch 1594680 (v15) onwards, the canonical behaviour is implemented. 85 | 86 | ## Design Rationale 87 | The beacon value is provided in as raw a form as possible, given the FVM already hashes the beacon randomness. 88 | Including further entropy is left to the caller. 89 | 90 | Adding a new syscall to return the un-hashed beacon randomness would add complexity without adding fundamental capability. 91 | If a full drand beacon is required (e.g. for time-lock operations), a user-submitted beacon can be validated by hashing it 92 | and comparing with the value returned by the new precompile. 93 | 94 | ## Backwards Compatibility 95 | This proposal introduces a new precompile available to FEVM smart contracts. 96 | 97 | Any existing smart contract which invokes this previously-unbound address will now observe a successful call. 98 | 99 | ## Test Cases 100 | As part of implementation we should have: 101 | 1. Builtin actors tests that the precompile is accessible and returning the correct randomness as specified by the testing runtime. 102 | 2. Integration tests on a lotus devent with a simple solidity contract that uses the precompile. 103 | 3. Integration tests that validate that gas costs are as expected 104 | 4. Integration tests that validate that very deep lookback has computational cost in proportion to the gas cost (linear). 105 | 5. Integration tests that validate that requesting future randomness results in an error. 106 | 107 | ## Security Considerations 108 | Inspecting early chain history can involve increasing computational cost. 109 | Client implementations with a computational cost that exceeds the gas charged for deep look-backs could face 110 | a denial-of-service attack. 111 | 112 | ## Incentive Considerations 113 | This proposal has no impact on incentive considerations for the core Filecoin protocol. 114 | 115 | Smart contracts using the new precompile will face gas costs that scale linearly with the depth of look-back. 116 | This incentive aligns users to query recent randomness stored in cached blocks, with less burden on the system. 117 | 118 | ## Product Considerations 119 | Precompiles are a standard feature of the EVM that developers are familiar with. 120 | The proposed precompile is specific to Filecoin. 121 | Smart contracts that make use of it may not be portable to other EVM environments that don't provide historical randomness. 122 | This proposal thus represents an additional capability that the FEVM environment can offer, 123 | and one that is specifically useful for proofs of space and storage. 124 | 125 | ## Implementation 126 | Draft PR: https://github.com/filecoin-project/builtin-actors/pull/1577 127 | 128 | ## Copyright 129 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 130 | -------------------------------------------------------------------------------- /FIPS/fip-0096.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0096" 3 | title: Convert fundraising remainder address(es) to keyless account actor(s) 4 | author: Fatman13 (@fatman13) 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1033 6 | status: Draft 7 | type: Technical 8 | category: Core 9 | created: 2024-07-10 10 | --- 11 | 12 | # Convert fundraising remainder address(es) to keyless account actor(s) 13 | 14 | ## Simple Summary 15 | 16 | Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address [f0122](https://filfox.io/en/address/f0122) type from a multisig to account that is keyless (like f099). 17 | 18 | 19 | ## Abstract 20 | 21 | At the moment, the actor holding the fundraising remainder is a _multisig_ actor. All signers are account actors, secured by corresponding wallet keys. This setup leaves the ownership and control over the fundraising remainder to signers of the _multisig_ actor, which undermines the decentralized governance principle over network funds, and creates potential security leaks. Although the amount in the fundraising remainder account is feable to institute any meaningful Sybil attack, breaching of spec still greatly undermines the security of a decentralized network by dimishing the network's credibility and unevenly favoring one party of the network participants, which both inflict profound long-term damage to the network. 22 | 23 | This FIP proposes to alter the type of the fundraising remainder actor from the aforementioned multisig to a keyless account actor, and further transfer the ownership, control and governance of the funds reserved from the signers of the multisig back to the network's participants via community governance. 24 | 25 | 26 | ## Change Motivation 27 | 28 | Like how mining reserve is made into a keyless account and ready to be [potentially burned](https://github.com/filecoin-project/FIPs/discussions/1030), fundraising remainder address(es) is also in the linger troubled by similar dilemma described in motivation section of [#901](https://github.com/filecoin-project/FIPs/discussions/901). We compiled the following 4 motivations for the proposal... 29 | 30 | ### 1. follow the spec 31 | 32 | Mining reserve in the Filecoin spec is described as the following... 33 | 34 | > It will be up to the community to determine in the future how to distribute those tokens, through Filecoin improvement proposals (FIPs) or similar decentralized decision-making processes. 35 | > -- excerpts from #901 36 | 37 | [fundraising remainder](https://spec.filecoin.io/#section-systems.filecoin_token.token_allocation) in the Filecoin spec is described as the following... 38 | 39 | > Of the Filecoin genesis block allocation, 10% of FIL_BASE were allocated for fundraising, of which 7.5% were sold in the 2017 token sale, and the 2.5% remaining were allocated for ecosystem development and potential future fundraising. 40 | 41 | Though paragraph about fundraising remainder didn't specifically articulate "up to the community to determine" as in mining reserve, by virtue of us being a crypto / blockchain community it can be assumed **by default** it is up to the community, ie FIP process, when no governance body was mentioned to oversight the distribution. 42 | 43 | ### 2. governance 44 | 45 | > It is worth noting that when the spec was written and when the network was first launched, the FIP process was not yet well-designed or matured to support network governance, and significant improvements have been made since then. 46 | > -- excerpts from #901 47 | 48 | Similar to the point #901 made, this proposal is to amend the inadequacy that network in its early days has neglected. 49 | 50 | ### 3. security 51 | 52 | > This also creates a security black hole in the network where if 2 out of the 3 signer keys of f090 are compromised by malicious actors, they may cause serious economic damage to the Filecoin network. 53 | > -- excerpts from #901 54 | 55 | Although the amount remaining in the fundraising remainder address(es) would not likely to cause serious economic damage as mining reserve would, there are still security concerns over whether governance could amend its mistake made in the past. 56 | 57 | ### 4. operation 58 | 59 | > In addition, having the reserve holds in a multisig also means changes toward the mining reserve..., may need to be managed by the msig signers via signed transactions which is a huge operational overhead (and again against the principle). 60 | > -- excerpts from #901 61 | 62 | fundraising remainder address(es) face identical operation challenges as mining reserve too. One thing to note is that through investigation by one of the community contributors some (most) of the funds originally allocated to this address have already been moved, and this FIP doesn't propose to do anything about them. 63 | 64 | ## Specification 65 | 66 | Convert fundraising remainder actor type from a _multisig_ to _account_ type. The new account actor should be keyless, like `f099`. 67 | 68 | ```rust 69 | pub struct State { 70 | pub address: Address, 71 | } 72 | ``` 73 | 74 | The new fundraising remainder actor will contain a self-reference to its ID address in the `address` field. 75 | 76 | ## Design Rationale 77 | 78 | The choice of making fundraising remainder actor to be a keyless account type is to ensure that no single actor/entity owns the control over fundraising remainder. The use of fundraising remainder will be proposed and governed by the FIP process, and further adopted by the network via network upgrades. 79 | 80 | ## Backwards Compatibility 81 | 82 | This change is not backwards compatible. Upon the activation of this FIP in a network upgrade: 83 | - the actor type of fundraising remainder will be migrated from _multisig_ to _account_. 84 | - the existing signers of the fundraising remainder multisig will no longer be able to perform operations on the actor 85 | 86 | ## Test Cases 87 | 88 | - Get actor cid of fundraising remainder should return actor code cid of an `account` 89 | 90 | ## Security Considerations 91 | 92 | This proposal improves the network security by removing the ownership and control of whatever it is the remaining of the 2.5% of the total network token supply in `f0122` from individuals and putting it under the control of network participants via the appropriate governance processes. Again, the proposal acknowledges that the security threats from Sybil attack perspective is slim, but not following spec is considered a much bigger threat as attackers don't really need to buy out the network, just the governance. 93 | 94 | 95 | ## Product Considerations 96 | 97 | This proposal places governance of the fundraising remainder funds entirely in hands of the network participants rather than key owners, thus providing greater transparency and assurance of community consultation and deliberation in appropriate future disbursement of the funds. And thus, the proposal sends out a strong signal that this is a network where spec is respected by words and by code, and restores some of the credibility lossed for failing to comply with the spec. 98 | 99 | ## Implementation 100 | 101 | TODO 102 | 103 | ## Copyright 104 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 105 | -------------------------------------------------------------------------------- /FIPS/fip-0101.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0101" 3 | title: Removal of the ProveCommitAggregate method from the miner actor 4 | author: "Rod Vagg (@rvagg)" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1116 6 | status: Accepted 7 | type: Technical (Core) 8 | category: Core 9 | created: 2025-02-05 10 | spec-sections: 11 | - 2.9.25.63 Storage Power Actor 12 | - 2.11.30 Sector 13 | - 2.11.31 Storage Miner 14 | - 2.12.35 Markets 15 | - 4.19.59 Proof-of-Spacetime (PoSt) 16 | requires: N/A 17 | replaces: N/A 18 | --- 19 | 20 | # FIP-0101: Removal of the ProveCommitAggregate method from the miner actor 21 | 22 | ## Simple Summary 23 | This FIP proposes the removal of the `ProveCommitAggregate` method (Method 26) from the miner actor as it is no longer actively used due to the introduction of `ProveCommitSectors3`, which offers the same functionality in a more flexible manner. 24 | 25 | ## Abstract 26 | The `ProveCommitAggregate` method was implemented for batch processing of pre-committed sectors using aggregate proofs. However, the subsequent introduction of `ProveCommitSectors3` allows greater flexibility and efficiency in handling this task. Given that `ProveCommitAggregate` has been deprecated in practical use, it adds unnecessary complexity to the system and generates technical debt. This FIP proposes to remove this method from the miner actor to simplify the protocol. 27 | 28 | ## Change Motivation 29 | The main motivation behind this change is builtin actor cleanup and reduction of technical debt. It is always beneficial to remove unused parts of the system as it leads to simpler, more maintainable, and less error-prone code. The `ProveCommitAggregate` method is no longer necessary since `ProveCommitSectors3` serves the same purpose more efficiently. 30 | 31 | ## Specification 32 | Implementation-wise, this change involves removing Method 26 (`ProveCommitAggregate`) from the miner actor, all associated helper methods that are not used by other methods and all tests that uniquely test its functionality. 33 | 34 | ## Design Rationale 35 | The decision to propose this change was made primarily because of the redundancy created by `ProveCommitSectors3`. Efficient and clean code being prioritised where possible over an ever-increase in complexity and potential for bugs. 36 | 37 | ## Backwards Compatibility 38 | This change will not introduce any backward incompatibilities, as the `ProveCommitAggregate` method is not actively used and its functionality is covered by `ProveCommitSectors3`. The author is unaware of any implementations that rely on `ProveCommitAggregate` and on-chain usage suggests there are none. 39 | 40 | ## Test Cases 41 | Test cases will need to ensure that `ProveCommitSectors3` method is able to cover all the functionality previously offered by `ProveCommitAggregate` and that the system behaves normally following the removal of Method 26. 42 | 43 | Care should be taken with the removal of `ProveCommitAggregate` tests to avoid removal of tests of other parts of the system that are not covered by other test cases. In this situation, tests should be reworked to use `ProveCommitSectors3` to test the same functionality. 44 | 45 | ## Security Considerations 46 | This FIP doesn't alter any security features of Filecoin protocol, as it only involves the removal of a deprecated method. It does, however, reduce the attack surface area where there may exist previously unknown security bugs. 47 | 48 | ## Incentive Considerations 49 | Removing the `ProveCommitAggregate` method from the miner actor does not have any direct impact on the incentive mechanisms in the Filecoin protocol. 50 | 51 | ## Product Considerations 52 | Once the deprecated `ProveCommitAggregate` method is removed, users and developers will experience a cleaner and slightly less confusing system. 53 | 54 | ## Implementation 55 | As the implementation involves removal of a method from the current codebase, it is expected to be relatively straightforward and low-risk. 56 | 57 | No migration is necessary. 58 | 59 | ### Removal tasks 60 | - Remove `ProveCommitAggregate` method from the miner actor. 61 | - Ensure that tests for `ProveCommitSectors3` effectively cover the same functionality. 62 | - Ensure that removal of tests previously covering `ProveCommitAggregate` doesn't result in an overall reduction in test coverage. 63 | - Ensure all systems behave normally with the removal of `ProveCommitAggregate`. 64 | 65 | ## Copyright 66 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 67 | -------------------------------------------------------------------------------- /FIPS/fip-0103.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0103" 3 | title: Removal of the ExtendSectorExpiration method from the miner actor 4 | author: "Rod Vagg (@rvagg)" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1116 6 | status: Draft 7 | type: Technical (Core) 8 | category: Core 9 | created: 2025-03-14 10 | spec-sections: 11 | requires: FIP-0045 12 | replaces: N/A 13 | --- 14 | 15 | # FIP-0103: Removal of the ExtendSectorExpiration method from the miner actor 16 | 17 | ## Simple Summary 18 | 19 | This FIP proposes the removal of the `ExtendSectorExpiration` method from the miner actor as it has been superseded by the more flexible `ExtendSectorExpiration2` method, which was introduced in FIP-0045 and supports verified claims. 20 | 21 | ## Abstract 22 | 23 | The `ExtendSectorExpiration` method in the miner actor was designed to allow storage providers to extend the commitment period of their sectors. However, with the introduction of `ExtendSectorExpiration2` in FIP-0045, which offers the same functionality plus additional flexibility for handling verified claims, the original method has become redundant. This proposal aims to remove the legacy `ExtendSectorExpiration` method to simplify the protocol, reduce technical debt, and streamline code pathways in the miner actor. It's important to note that sector extension functionality remains fully supported through the enhanced `ExtendSectorExpiration2` method. 24 | 25 | ## Change Motivation 26 | 27 | The main motivation behind this change is to clean up builtin actors and reduce technical debt. By removing the redundant `ExtendSectorExpiration` method, we can simplify the protocol, making it more maintainable and less error-prone. The existence of two methods that serve similar purposes creates unnecessary complexity in the codebase and requires additional maintenance overhead. Since `ExtendSectorExpiration2` provides enhanced functionality including support for verified claims, there is no longer a need to maintain the original method. 28 | 29 | ## Specification 30 | 31 | Implementation-wise, this change involves removing the `ExtendSectorExpiration` method from the miner actor, along with all associated helper methods that are not used by other methods, and all tests that uniquely test its functionality. 32 | 33 | ## Design Rationale 34 | 35 | The decision to propose this change follows the same principle as FIP-0101, which removed the `ProveCommitAggregate` method. When newer, more flexible methods are available and in use, removing redundant legacy methods simplifies the codebase and reduces maintenance burden. 36 | 37 | With `ExtendSectorExpiration2` fully supporting all functionality of the original method plus additional capabilities for verified claims, maintaining both methods is unnecessary and adds complexity. Efficient and clean code is prioritised over accumulated complexity that increases the potential for bugs. 38 | 39 | ## Backwards Compatibility 40 | 41 | This change will not introduce any backward incompatibilities, as the `ExtendSectorExpiration2` method fully covers all the functionality previously offered by `ExtendSectorExpiration`. Storage providers have already migrated to using the newer method. The last `ExtendSectorExpiration` message recorded on-chain was on 2024-12-15 (over 3 months ago from this FIP creation), as evidenced by transaction [`bafy2bzacecmyltma2j42wai3vqymu6apmcervz3eia3oixhyyls2tdcvj7okm`](https://filfox.info/en/message/bafy2bzacecmyltma2j42wai3vqymu6apmcervz3eia3oixhyyls2tdcvj7okm). Tooling and client libraries have been updated to use `ExtendSectorExpiration2`, making this a safe removal that simplifies the API without affecting functionality. 42 | 43 | ## Test Cases 44 | 45 | Test cases will need to ensure that `ExtendSectorExpiration2` method adequately covers all the functionality previously offered by `ExtendSectorExpiration` and that the system behaves normally following the removal. 46 | 47 | Care should be taken with the removal of `ExtendSectorExpiration` tests to avoid removal of tests for other parts of the system that are not covered by other test cases. In this situation, tests should be reworked to use `ExtendSectorExpiration2` to test the same functionality. 48 | 49 | ## Security Considerations 50 | 51 | This FIP doesn't alter any security features of the Filecoin protocol, as it only involves the removal of a deprecated method that has been superseded by a more capable one. It may potentially reduce the attack surface area where there could be previously unknown security bugs. 52 | 53 | ## Incentive Considerations 54 | 55 | Removing the `ExtendSectorExpiration` method from the miner actor does not have any direct impact on the incentive mechanisms in the Filecoin protocol. All the functionality continues to be available through `ExtendSectorExpiration2`, so there are no changes to the incentives for extending sector commitments. 56 | 57 | ## Product Considerations 58 | 59 | Once the deprecated `ExtendSectorExpiration` method is removed, users and developers will experience a cleaner and less confusing system. Having a single method for extending sector expiration makes the API more consistent and easier to understand. Additionally, the simplification of code pathways in the miner actor could potentially enable further optimisations in the future. 60 | 61 | ## Implementation 62 | 63 | As the implementation involves removal of a method from the current codebase, it is expected to be relatively straightforward and low-risk. 64 | 65 | No migration is necessary as the functionality remains available through the existing `ExtendSectorExpiration2` method. 66 | 67 | ### Removal tasks 68 | 69 | - Remove `ExtendSectorExpiration` method from the miner actor. 70 | - Ensure that tests for `ExtendSectorExpiration2` effectively cover the same functionality. 71 | - Ensure that removal of tests previously covering `ExtendSectorExpiration` doesn't result in an overall reduction in test coverage. 72 | - Ensure all systems behave normally with the removal of `ExtendSectorExpiration`. 73 | 74 | ## Copyright 75 | 76 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /FIPS/fip-0106.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0106" 3 | title: Removal of the ProveReplicaUpdates method from the miner actor 4 | author: "Rod Vagg (@rvagg)" 5 | discussions-to: https://github.com/filecoin-project/FIPs/discussions/1151 6 | status: Draft 7 | type: Technical (Core) 8 | category: Core 9 | created: 2025-05-20 10 | spec-sections: 11 | requires: FIP-0019 12 | replaces: N/A 13 | --- 14 | 15 | # FIP-0106: Removal of the ProveReplicaUpdates method from the miner actor 16 | 17 | ## Simple Summary 18 | 19 | This FIP proposes the removal of the `ProveReplicaUpdates` method (Method 27) from the miner actor as it has been superseded by the more flexible `ProveReplicaUpdates3` method, which offers the same functionality in a more effective manner. 20 | 21 | ## Abstract 22 | 23 | The `ProveReplicaUpdates` method in the miner actor was originally introduced by [FIP-0019 (Snap Deals)](./fip-0019.md) to allow storage providers to update sealed sectors with new data without re-sealing. However, with the introduction of `ProveReplicaUpdates3`, which offers the same functionality with greater flexibility and efficiency, the original method has become redundant. This proposal aims to remove the legacy `ProveReplicaUpdates` method to simplify the protocol, reduce technical debt, and streamline code pathways in the miner actor. It's important to note that Snap Deals functionality remains fully supported through the enhanced `ProveReplicaUpdates3` method. 24 | 25 | ## Change Motivation 26 | 27 | The main motivation behind this change is to clean up builtin actors and reduce technical debt. By removing the redundant `ProveReplicaUpdates` method, we can simplify the protocol, making it more maintainable and less error-prone. The existence of two methods that serve similar purposes creates unnecessary complexity in the codebase and requires additional maintenance overhead. Since `ProveReplicaUpdates3` provides enhanced functionality and is already the only method actively used for Snap Deals operations, there is no longer a need to maintain the original method. 28 | 29 | ## Specification 30 | 31 | Implementation-wise, this change involves removing the `ProveReplicaUpdates` method (Method 27) from the miner actor, along with all associated helper methods that are not used by other methods, and all tests that uniquely test its functionality. This includes removing the entire implementation of `prove_replica_updates` and its supporting code that isn't shared with other methods. 32 | 33 | ## Design Rationale 34 | 35 | The decision to propose this change follows the same principle as [FIP-0101](./fip-0101.md) and [FIP-0103](./fip-0103.md), which removed other unused methods from the miner actor. When newer, more flexible methods are available and in use, removing redundant legacy methods simplifies the codebase and reduces maintenance burden. 36 | 37 | With `ProveReplicaUpdates3` fully supporting all functionality of the original method plus additional capabilities, maintaining both methods is unnecessary and adds complexity. Efficient and clean code is prioritised over accumulated complexity that increases the potential for bugs. 38 | 39 | ## Backwards Compatibility 40 | 41 | This change will not introduce any backward incompatibilities, as the `ProveReplicaUpdates3` method fully covers all the functionality previously offered by `ProveReplicaUpdates`. Storage providers have already migrated to using the newer method, as evidenced by the lack of on-chain usage of the original method for at least six months. Tooling and client libraries have been updated to use `ProveReplicaUpdates3`, making this a safe removal that simplifies the API without affecting functionality. 42 | 43 | ## Test Cases 44 | 45 | Test cases will need to ensure that `ProveReplicaUpdates3` method adequately covers all the functionality previously offered by `ProveReplicaUpdates` and that the system behaves normally following the removal. 46 | 47 | Care should be taken with the removal of `ProveReplicaUpdates` tests to avoid removal of tests for other parts of the system that are not covered by other test cases. In this situation, tests should be reworked to use `ProveReplicaUpdates3` to test the same functionality. 48 | 49 | ## Security Considerations 50 | 51 | This FIP doesn't alter any security features of the Filecoin protocol, as it only involves the removal of a deprecated method that has been superseded by a more capable one. It may potentially reduce the attack surface area where there could be previously unknown security bugs. 52 | 53 | ## Incentive Considerations 54 | 55 | Removing the `ProveReplicaUpdates` method from the miner actor does not have any direct impact on the incentive mechanisms in the Filecoin protocol. All the functionality continues to be available through `ProveReplicaUpdates3`, so there are no changes to the incentives for updating sector data via Snap Deals. 56 | 57 | ## Product Considerations 58 | 59 | Once the deprecated `ProveReplicaUpdates` method is removed, users and developers will experience a cleaner and slightly less confusing system. Having a single method for Snap Deals makes the API more consistent and easier to understand. Additionally, the simplification of code pathways in the miner actor could potentially enable further optimisations in the future. 60 | 61 | ## Implementation 62 | 63 | As the implementation involves removal of a method from the current codebase, it is expected to be relatively straightforward and low-risk. 64 | 65 | No migration is necessary as the functionality remains available through the existing `ProveReplicaUpdates3` method. 66 | 67 | ### Removal tasks 68 | 69 | - Remove `ProveReplicaUpdates` method from the miner actor. 70 | - Remove any helper methods or functions that were used exclusively by `ProveReplicaUpdates`. 71 | - Ensure that tests for `ProveReplicaUpdates3` effectively cover the same functionality. 72 | - Ensure that removal of tests previously covering `ProveReplicaUpdates` doesn't result in an overall reduction in test coverage. 73 | - Ensure all systems behave normally with the removal of `ProveReplicaUpdates`. 74 | 75 | ## Copyright 76 | 77 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /FRCs/frc-0040.md: -------------------------------------------------------------------------------- 1 | --- 2 | fip: "0040" 3 | title: Boost - Filecoin Storage Deals Market Protocol 4 | author: dirkmc, nonsense, jacobheun, brendalee 5 | status: Draft 6 | type: FRC 7 | created: 2022-07-07 8 | dependency: none 9 | --- 10 | 11 | # FRC-0040: Boost - Filecoin Storage Deals Market Protocol 12 | 13 | ## Simple Summary 14 | 15 | [Boost](https://github.com/filecoin-project/boost) is a tool for Storage Providers to manage data onboarding and retrieval on the Filecoin network. Boost replaces the go-fil-markets package in lotus with a standalone binary that runs alongside a Lotus daemon and Lotus miner. Currently, it supports the same protocols as the existing lotus markets subsystem, and adds new versions of the protocols used to propose a storage deal and check the deal’s status. 16 | 17 | ## Abstract 18 | 19 | Filecoin is a decentralized storage network consisting of many individual storage providers (SP). These SPs operate independently and take storage deals from the Filecoin network. As we see the amount of storage deals being made increasing, there are limitations making it difficult for SPs to handle large volumes of deals. 20 | 21 | Boost addresses these issues by introducing two new libp2p protocols, specifically for storage deals. The goals of Boost are the following: 22 | 23 | - **Improve the storage deal flow**: 24 | - **Improve visibility for Storage Providers into their systems**: Better visibility of fund allocation, deal states including data transfer, and sealing pipelines via a simple web interface to leverage the new markets APIs 25 | - **Extensible data transfer**: online deals support fetching a CAR file over HTTP 26 | 27 | The Boost module is still in development. In the future, additional protocols will also be added which support market retrieval capabilities. 28 | 29 | ## Change Motivation 30 | 31 | The purpose of Boost is to become the reference implementation for Filecoin Markets (which will eventually replace the current version of Lotus Markets as the reference implementation). It is currently being developed as a standalone repository to allow the team to iterate quickly on a redesign of the system, prove the merit of the new design early and often through internal and community facing demos, and to be releasable as a standalone binary that can run alongside the existing Lotus process. 32 | Planning for Boost was initiated after deep user research with Storage Providers. This research sought to understand challenges and limitations that they faced as service providers on the Filecoin network. For more information, see 33 | ## Specification 34 | 35 | Boost introduces new versions of two libp2p protocols. The specifications are linked: 36 | 37 | [Propose Storage Deal Protocol](https://boost.filecoin.io/boost-architecture/libp2p-protocols#propose-storage-deal-protocol) 38 | 39 | [Storage Deal Status Protocol](https://boost.filecoin.io/boost-architecture/libp2p-protocols#storage-deal-status-protocol) 40 | 41 | 42 | ## **Backwards Compatibility** 43 | 44 | Boost is currently backwards compatible with go-fil-markets package. It supports the same endpoints for making storage and retrieval deals, getting the storage and retrieval ask, and getting the status of ongoing deals. 45 | 46 | In the future, there is a possibility that we will move towards deprecating go-fil-markets in favor of the capabilities being built out in Boost. 47 | 48 | ## **Security Considerations** 49 | 50 | No changes to underlying proofs or security. 51 | 52 | ## **Incentive Considerations** 53 | 54 | No change to incentives. 55 | 56 | ## **Product Considerations** 57 | 58 | Additional libp2p protocols were introduced for storage deal proposal protocol and storage deal status protocol. 59 | 60 | ## **Implementation** 61 | 62 | [https://github.com/filecoin-project/boost](https://github.com/filecoin-project/boost) 63 | 64 | ## **Copyright** 65 | 66 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 67 | -------------------------------------------------------------------------------- /FUNDING.json: -------------------------------------------------------------------------------- 1 | { 2 | "drips": { 3 | "filecoin": { 4 | "ownedBy": "0x4Dc1186120C684d783aB8c5E4310759AF2D1931c" 5 | } 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /mission.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Filecoin Mission 3 | layout: page 4 | permalink: /mission/ 5 | --- 6 | 7 | The mission of Filecoin is **to create a decentralized, efficient, and robust foundation for humanity’s information**. 8 | 9 | ![](https://ipfs.io/ipfs/Qmf8qbRQvUpTSCo6e8ptZyHr7ZmWFCVDqrroCW6MtLHsLe) 10 | 11 | Here is a short overview of each of these terms: 12 | 13 | ## Decentralized 14 | 15 | * The network is not dependent on any one party, e.g., not dependent on a company, foundation, or other organization to continue operating. 16 | * No centralized parties can control, stop, or censor the network, its operation, or its participants. 17 | * Users and providers are not controlled or governed by powerful intermediaries (unlike markets like Uber or Airbnb). 18 | * Activity is trustable (web3) through the public verifiability of operations and rational incentives. 19 | * Refers to the decentralization movement of 2015+, including IPFS, Bitcoin, Ethereum, and more. 20 | * Third parties cannot prevent willing participants from exchanging data and/or payments for it. 21 | * Filecoin uses cryptography, end-to-end encryption at rest, and incentives to secure information and network operation. 22 | 23 | ## Efficient 24 | 25 | * Make digital storage (spacetime) a proper commodity with real markets 26 | * Decouple digital storage from cloud computing moat feature sets -- turn storage market into a real market where any provider can sell their storage. 27 | * Enable humanity to create an efficient digital storage market, with small margins and as close as we can get to physical limitations. 28 | * Ensure efficient usage of digital storage resources -- reduce digital space waste (unused storage supply while prices are high enough to warrant using it). 29 | * Drive more and more efficient usage of storage media. 30 | * Enable fast (sub-second) buying and selling of spacetime. 31 | * Enable programs to buy and sell spacetime (without having to be humans or have an associated bank account) -- i.e., a cryptocurrency wallet and code should be enough to buy storage. 32 | * Clients can trust Filecoin will serve data quickly and efficiently back to them. 33 | * Filecoin will not waste user resources (storage, bandwidth, computation, time) unnecessarily. 34 | 35 | ## Robust 36 | 37 | * Filecoin has five 9s of uptime or more. 38 | * Clients can trust Filecoin to keep their data safe. 39 | * Clients can trust Filecoin to serve their data in a variety of extreme circumstances (in the distant future). 40 | * Clients can trust Filecoin to replicate storage and to self-repair lost replicas over time. 41 | * Clients can use Filecoin to store critical application data and trust it to work whenever they need that data back. 42 | * The network is robust to attack by all sorts of powerful parties, including state-level actors. 43 | * The network is robust to changing market dynamics and powerful counter incentives -- meaning, it is rational to continue operating the network. 44 | * The network is robust to network censorship attacks (given there exist willing storage providers). 45 | * The network is robust to specific file censorship attacks (given there exist willing storage providers). 46 | * The network is robust to catastrophic attacks (i.e., nuclear war, long-running internet partitions, etc.). 47 | 48 | ## Foundation 49 | 50 | * Filecoin can be used as the foundation of other technologies and applications. It is a platform. 51 | * Filecoin supports data storage-intensive applications. 52 | * Programs, Webapps, DApps, and smart contracts can be written to store and retrieve data from Filecoin efficiently, safely, and with high confidence. 53 | * Filecoin is a trustable, dependable foundation for critical systems and applications. 54 | * It becomes possible for parties to store information indefinitely (using rational incentives, and money), without having to be online or alive to renew or re-upload things. 55 | * Filecoin leads data reliability and replication efforts. 56 | 57 | ## Humanity’s Information 58 | 59 | * Filecoin marshals vast storage arrays to store most of humanity’s valuable information. 60 | * Filecoin stores all human knowledge -- all scientific papers, history, press, etc. 61 | * Filecoin forms a public record for humanity. 62 | * Filecoin is one of the best choices to store any kind of data (from small incremental app data to massive datasets). 63 | * Filecoin stores personal data end-to-end encrypted at rest, and can store it indefinitely. 64 | * Filecoin becomes the default “digital storage locker” for all computer users. 65 | * Filecoin becomes the default “external hard drive” for all computer users. 66 | -------------------------------------------------------------------------------- /proposing.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Proposing FIPs 3 | layout: page 4 | permalink: /proposing/ 5 | --- 6 | 7 | Filecoin Improvement Proposals (FIPs) describe standards for the Filecoin platform, including core protocol specifications, client APIs, and other changes to the project. 8 | 9 | # Contributing 10 | 11 | 1. Review [FIP-1](/FIPS/fip-0001.md). 12 | 2. Fork the repository by clicking "Fork" in the top right. 13 | 3. Add your FIP to your fork of the repository. There are [template FIPs here](/templates). 14 | 4. Submit a Pull Request to Filecoin's [FIPs repository](https://github.com/filecoin-project/FIPs). 15 | 5. Draft and submit a Pull Request to the [Filecoin Specification repository](https://github.com/filecoin-project/specs) to update the spec with the changes that your FIP brings. 16 | 17 | Your first PR should be a first draft of the final FIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new FIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the FIP as a whole. 18 | 19 | If your FIP requires images, the image files should be included in a subdirectory of the `assets` folder for that FIP as follow: `assets/fip-X` (for fip **X**). When linking to an image in the FIP, use relative links such as `../assets/fip-X/image.png`. 20 | 21 | Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft FIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your FIP contains either your Github username or your email address inside ``. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile). 22 | 23 | When you believe your FIP is mature and ready to progress past the draft phase, you should do one of two things: 24 | 25 | - **For a Standards Track FIP of type Core**: 26 | - ask to have your issue added to [the agenda of an upcoming All Core Devs meeting](https://github.com/filecoin-project/tpm/issues), where it can be discussed for inclusion in a future chain upgrade. If implementers agree to include it, the FIP editors will update the state of your FIP to 'Accepted'. 27 | - prepare the changes to the spec text necessary to describe the protocol modifications that your FIP brings. Submit a PR to the [Filecoin Specification repository](https://github.com/filecoin-project/specs). These changes will also be discussed in the "All Core Devs" meeting and the editor will assign a reviewer. 28 | - **For all other FIPs**, open a PR changing the state of your FIP to 'Final'. An editor will review your draft and ask if anyone objects to its being finalised. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the FIP - they may close the PR and request that you fix the issues in the draft before trying again. 29 | 30 | # FIP Status Terms 31 | * **Draft** - a FIP that is undergoing rapid iteration and changes. 32 | * **Last Call** - a FIP that is done with its initial iteration and ready for review by a wide audience. 33 | * **Accepted** - a core FIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a FIP into their clients as part of a hard fork is not part of the FIP process. If such a decision is made, the FIP wil move to final. 34 | * **Final (non-Core)** - a FIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. 35 | * **Final (Core)** - a FIP that the Core Devs have decided to implement and release in a future chain upgrade or has already been released in a chain upgrade. 36 | * **Deferred** - a FIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent chain upgrade. 37 | 38 | # Preferred Citation Format 39 | 40 | TODO: 41 | The canonical URL for a FIP that has achieved draft status at any point will be on the Filecoin website. For example, the canonical URL for FIP-00001 will be https://filecoin.io/TODO. 42 | -------------------------------------------------------------------------------- /resources/fip-0019/SnapDeals-Theory_Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0019/SnapDeals-Theory_Report.pdf -------------------------------------------------------------------------------- /resources/fip-0029/ChangeBeneficiary-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0029/ChangeBeneficiary-flow.png -------------------------------------------------------------------------------- /resources/fip-0030/actor-execution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0030/actor-execution.png -------------------------------------------------------------------------------- /resources/fip-0030/technical-design.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0030/technical-design.png -------------------------------------------------------------------------------- /resources/fip-0031/revised-test-plan.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0031/revised-test-plan.jpg -------------------------------------------------------------------------------- /resources/fip-0031/testnet-plan.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0031/testnet-plan.jpg -------------------------------------------------------------------------------- /resources/fip-0036/SDM_Function.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0036/SDM_Function.jpg -------------------------------------------------------------------------------- /resources/fip-0077/recent_two_months.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0077/recent_two_months.png -------------------------------------------------------------------------------- /resources/fip-0077/total_in_use.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0077/total_in_use.png -------------------------------------------------------------------------------- /resources/fip-0081/gradual_activation_rationale.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0081/gradual_activation_rationale.pdf -------------------------------------------------------------------------------- /resources/fip-0081/macro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0081/macro.png -------------------------------------------------------------------------------- /resources/fip-0081/micro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0081/micro.png -------------------------------------------------------------------------------- /resources/fip-0081/ramped_activation_gamma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0081/ramped_activation_gamma.png -------------------------------------------------------------------------------- /resources/fip-0082/SDM_Function.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0082/SDM_Function.png -------------------------------------------------------------------------------- /resources/fip-0082/supersnap_gas_32gib.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0082/supersnap_gas_32gib.png -------------------------------------------------------------------------------- /resources/fip-0082/supersnap_gas_64gib.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0082/supersnap_gas_64gib.png -------------------------------------------------------------------------------- /resources/fip-0086/chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0086/chain.png -------------------------------------------------------------------------------- /resources/fip-0086/flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0086/flow.png -------------------------------------------------------------------------------- /resources/fip-0086/fork.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0086/fork.png -------------------------------------------------------------------------------- /resources/fip-0086/gossipbft_implementation_of F3_v2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0086/gossipbft_implementation_of F3_v2.pdf -------------------------------------------------------------------------------- /resources/fip-0086/gossipbft_message_rebroadcast_v3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0086/gossipbft_message_rebroadcast_v3.pdf -------------------------------------------------------------------------------- /resources/fip-0086/merkletree.go: -------------------------------------------------------------------------------- 1 | package merkletree 2 | 3 | import ( 4 | "math/bits" 5 | 6 | "golang.org/x/crypto/sha3" 7 | ) 8 | 9 | // Digest is a 32-byte hash digest. 10 | type Digest = [32]byte 11 | 12 | // VerifyProof verifies that the given value maps to the given index in the 13 | // merkle tree with the given root. It returns "more" if the value is not the 14 | // last value in the merkle tree. 15 | func VerifyProof(root Digest, index int, value []byte, proof []Digest) (valid bool, more bool) { 16 | digest := leafHash(value) // this is the "leaf" hash. 17 | 18 | // If the index is greater than 2^len(proof) - 1, it can't possibly be 19 | // part of this tree. 20 | if index > 1< 18 | 19 |

Figure 1: Network state evolution for each input trajectory. 20 |

21 | 22 | 23 | ### Proof Fees Modeling 24 | 25 | #### Circulating Supply (CS) Based Fees 26 | We can describe this fee as follows, for a sector onboarded at time `t`: 27 | 28 | `sectorFee(t) = k1 * CS(t) * sectorDurationDay * sectorQAP` 29 | 30 | In the simulation, the sector duration is fixed to 540 days. 31 | 32 | #### Block Reward (BR) Based Fees 33 | We can describe this fee as follows, for a sector onboarded at time `t`: 34 | 35 | `sectorFee(t) = k2 * (sum_{d=1, ...,540} sectorBlockReward(t,d) * FeeMultiplier(t)) ` 36 | 37 | In the above formulations: 38 | - `k1` and `k2` represent two different scaling factors; 39 | - `CS(t)` is the circulating supply at time `t`; 40 | - `sectorBlockReward(t,d)` is the per sector reward for a sector onboarded at time `t` during day `d`; 41 | - `FeeMultiplier` represents the following multiplier function. 42 |
43 | 44 |
45 | 46 | ### Simulations 47 | 48 | #### Methodology 49 | To understand the effect of BR-based vs CS-based fees, we consider the following 6 metrics: 50 | - Fee / Pledge, per unit of Quality Adjusted Power (QAP); 51 | - Fee per sector / 540-day of BlockReward, per unit of QAP; 52 | - Cumulative onboarding fees that would be collected; 53 | - Fil-on-FIL Returns (FoFR[^*]) estimate before the per sector fee, per unit of QAP; 54 | - FoFR after the per sector fee (including a savings estimate for removing batch balancer), per unit of QAP; 55 | - The percentage change in FoFR from before per sector fee to after per sector fee, , per unit of QAP. 56 | 57 | [^*]:Note: FoFR is defined as `(Returns - Fees)/Pledge` 58 | 59 | To account for the savings that will result from the removal of the batch balancer, we first must simulate the per-sector gas fee that SPs incur for onboarding sectors under the status-quo (i.e. no onboarding fee), and the expected savings from replacing the batch-balancer with the per sector fee. Predicting future network gas fees is not possible, so projecting relative savings by switching to a more predictable fee structure is challenging. Our methodology is as follows, and we note that this is an approximation that can’t take into account the intricacies of how base_fee fluctuates, since our modeling is aggregated at the daily level rather than the epoch level. 60 | 61 | 1. First, we estimate the per-sector gas fees under the status quo to be as follows: 62 | - PreFip: `PreFIPPerSectorGasFee[d] = (x % CurrentDailyBurn)* feeRegimeScalar / (NumSectorsOnboarded[d]+NumSectorsRenewed[d])` 63 | - PostFIP: `PostFIPPerSectorGasFee[d] = F * PreFIPPerSectorGasFee[d]` 64 | 65 | The `feeRegimeScalar` models the effect of both base fee and economic bounds (ex limited FIL to onboard) and `x` models the fraction of total gas fees due to onboarding in the pre and post fip scenarios at different levels of onboarding. `F` is the ratio of pre vs post-FIP gas savings that would be achieved. 66 | 67 | 2. Next, we estimate how this factor `F` changes as a result of the onboarding fees and the removal of the batch balancer, as a function of the onboarding rate. The table below shows this. 68 | 69 | | Onboarding Rate (PiB/day) | Pre-FIP base fee | `x` | `feeRegimeScalar` | Post-FIP base fee | `F` | Justification | 70 | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | 71 | | **0 \- 2.5 PiB** | 100-1000 attoFil | 50% | 1 | 100 \- 1000 attoFIL | 1 | When the daily RB onboarding is below 2.5PiB/day, no base fee spikes are caused in both scenarios (per and post FIP) | 72 | | **\> 2.5 PiB** | 0.01-0.1 nanoFIL | 95% | 2 | 100 \-1000 attoFIL | 0.0001 | When onboarding increases beyond 2.5PiB/day, base fee spikes from current levels, but the maximum burned will be limited by the available pledge to onboard new sectors. We estimate that this factor will not exceed 2x. | 73 | 74 | Comments: 75 | - When onboarding increases beyond 2.5PiB/day, base fee spikes from current levels, but the maximum burned will be limited by the available pledge to onboard new sectors. We estimate that this factor will not exceed 2x. 76 | - Onboarding above 3.5 PiB can only happen through batching with current network conditions. In the Pre-FIP case, this means that >3.5 PiB onboarding can only happen if the base fee is equal or higher than the Batch Balancer crossover base fee (0.25 nanoFIL in the code). 77 | - Flag: the 2.0x growth case (the red line modeled below - equivalent to ~6 PiB daily onboarding) is likely *over-estimating* 1Y Sector ROI due to underestimating current gas costs during high-growth network onboarding, and therefore over-estimates the reduction in 1Y Sector ROI Delta. 78 | 79 | #### Results 80 | 81 | For each trajectory, we can show the expected fee and derivative metrics as a function of time[^**]. 82 | Figure 2 shows these metrics for the CS-based fee (with the cap at 50% expected_daily_reward). Figure 3 here shows these metrics for the BR-based fee. 83 | 84 | 85 |
86 | 87 |

Figure 2: CS-based fee evolution as a function of various network metrics. The scaling factor k1 = 5.56 E-15 for 32GiB of QAP in the first row and k1= 7.4 E-15 for 32GiB of QAP in the second row. The daily payment is also capped at 50% of expected_daily_reward as a safety measure. 88 |

89 |
90 | 91 |
92 | 93 |

Figure 3: BR-based fee evolution as a function of various network metrics. The scaling factor k2 = 1% in the first row and = 2% in the second row. 94 |

95 |
96 | 97 | [^**]: The link to the code which generated the plots is here: https://github.com/CELtd/cel/blob/kiran/notebooks/proof_fees/fees10.ipynb 98 | 99 | ### Conclusions: 100 | The Block Reward (BR, Figure 3) was ruled out because the fee-to-reward ratio did not exhibit the desired behavior—specifically, when network growth slowed, the ratio did not show any slowdown in the increase, which was not optimal. In particular, the total amount of fees burnt over time is less sensitive to the levels of onboarding demand, and there is a risk of fees being high, even when onboarding demand is low. 101 | 102 | Circulating supply (CS, Figure 2) was chosen. CS is a good basis for the per-sector fee because it normalizes fees relative to the Filecoin economy, ensuring both adaptability and predictability. More precisely: 103 | - Stable Economic Reference: A fixed percentage of CS functions like a fixed USD fee if market cap remains stable, keeping costs predictable; 104 | - Adapts to Market Conditions: If Filecoin’s valuation rises, fees increase in FIL terms, scaling with the economy. If the market stagnates, fees stay economically consistent. 105 | -------------------------------------------------------------------------------- /resources/fip-0100/network_state_evolution.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/fip-0100/network_state_evolution.jpg -------------------------------------------------------------------------------- /resources/frc-0051/Create Epoch boundary attack on EC with CBcast.md: -------------------------------------------------------------------------------- 1 | # Epoch boundary attack on EC with CBcast 2 | 3 | This document proposes and analyzes an epoch boundary attack on expected consensus with consistent broadcast. 4 | 5 | 6 | ## Epoch boundary attack 7 | Consistent broadcast is [proposed by Guy](https://hackmd.io/l07vRuHvTzWF8zG3kEEQuQ) as a mitigation to the epoch boundary attack on EC. With consistent broadcast, the adversary is prevented from equivocating (i.e., creating two blocks with the same leader election proof). 8 | 9 | However, the adversary is still able to split the network to some extent. When the adversary is elected, say $\ell \geq 1$ times in one epoch (here we assume that the adversary controls many different participants). Then the adversary could send each of its blocks (with different election proofs) to a selected number of nodes at the right time (i.e., close to the cutoff) to ensure that only part of the nodes accept each block. The network is then split in $2^\ell$ ways (all the combination of accept vs reject for each of the $\ell$ blocks). The adversary needs to smartly divide all honest nodes into $2^\ell$ subsets to make sure that all the forks have almost equal weights in the next epoch (the difference is at most one). To make the analysis easier, we assume the adversary always makes the best decision as if it knows the future. 10 | 11 | In addition, when the adversary is elected for many times (e.g., $\ell \geq 3$), releasing all $\ell$ blocks might not be a good idea because all honest nodes will receive all blocks by the end of next epoch. Therefore, let $\ell_{max}$ be the maximum number of adversarial blocks that will be used to split the network in one epoch. 12 | 13 | While trying the best to split the network, the adversary can also reuse all its blocks to build a private chain. Note that CBcast only prevents equivocation in the current epoch. If a node receives a heavier chain which contains a block previously rejected by the CBcast protocol, it should still accept this heavier chain. 14 | 15 | ## Threshold analysis 16 | 17 | We calculate the threshold of this epoch boundary attack. We do this by comparing the chain growth (per epoch) of the honest chain and the private chain. Here are some parameters: 18 | - $m$: expected number of blocks per epoch; 19 | - $\beta$: fraction of adversarial power; 20 | - $\ell_{max}$: the maximum number of adversarial blocks that will be used to split the network in one epoch; 21 | - $A$: number of adversarial blocks in epoch $r-1$, $A \sim Poisson(\beta m)$; 22 | - $H$: number of adversarial blocks in epoch $r$, $H \sim Poisson((1-\beta) m)$. 23 | 24 | Then the chain growth of the private chain is just $\mathbb{E}[A]$. Next, we look at the honest chain growth: 25 | - When $A=0$, the views of all honest nodes at the end of epoch $r-1$ converge. So, the honest chain growth is $H$. 26 | - When $A=1$ (i.e., there is one adversarial block $B$), all honest nodes are split into two subsets (receiving $B$ or not receiving $B$). And the minimum honest chain growth is $\lfloor H/2 \rfloor +1$. Note that here we count adversarial blocks in epoch $r-1$ and honest blocks in epoch $r$. All blocks in the honest chain are counted exactly once. 27 | - When $A=2$ (i.e., there are two adversarial block $B_1, B_2$), all honest nodes are split into four subsets ($\emptyset, \{B_1\}, \{B_2\}, \{B_1,B_2\}$). One can check that the minimum honest chain growth is $\max(\lceil H/4 \rceil +1, 2)$. Note that the goal of the adversary is to make sure that the four forks have almost equal weights (the difference is at most one). 28 | 29 | Let $X_{\ell_{max}}$ be the honest chain growth. When $\ell_{max} = 1$, we have 30 | $$\mathbb{E}[X_1] = \mathbb{P}(A=0)\mathbb{E}[H] + \mathbb{P}(A>0)\mathbb{E}[\lfloor H/2 \rfloor +1].$$ 31 | 32 | When $\ell_{max} = 2$, we have 33 | $$\mathbb{E}[X_2] = \mathbb{P}(A=0)\mathbb{E}[H] + \mathbb{P}(A=1)\mathbb{E}[\lfloor H/2 \rfloor +1] + \mathbb{P}(A>1)\mathbb{E}[\max(\lceil H/4 \rceil +1, 2)].$$ 34 | 35 | By comparing $\mathbb{E}[X_{\ell_{max}}]$ with $\mathbb{E}[A]$, we can derive the threshold for this epoch boundary attack. Numerically, when $\ell_{max} = 1,2$, the threshold is ~44%. Therefore, so far we know the true security threshold of EC with CBcast is in [20%, 44%]. However, this would be hard to prove that the is the threshold for every attack in EC (and hence the tight threshold) although we know it is the threshold corresponding the the worst attack we know. 36 | 37 | -------------------------------------------------------------------------------- /resources/frc-0051/sec_analysis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/frc-0051/sec_analysis.pdf -------------------------------------------------------------------------------- /resources/frc-0089/err_prob_and_block_count_march.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/frc-0089/err_prob_and_block_count_march.png -------------------------------------------------------------------------------- /resources/frc-0089/err_prob_and_block_count_november.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/frc-0089/err_prob_and_block_count_november.png -------------------------------------------------------------------------------- /resources/frc-0089/theory.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/FIPs/0dec1f16ca8ca74b27cc659b6621e15fa10762c4/resources/frc-0089/theory.pdf --------------------------------------------------------------------------------