From b6437dbbb4d8c06c9d0eaf85e58414f13b260778 Mon Sep 17 00:00:00 2001 From: Yu Date: Thu, 31 Oct 2024 14:38:17 +0800 Subject: [PATCH 1/5] Create fip-00xx.md --- FIPS/fip-00xx.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 FIPS/fip-00xx.md diff --git a/FIPS/fip-00xx.md b/FIPS/fip-00xx.md new file mode 100644 index 00000000..98834a01 --- /dev/null +++ b/FIPS/fip-00xx.md @@ -0,0 +1,104 @@ +--- +fip: "00XX" +title: Convert fundraising remainder address(es) to keyless account actor(s) +author: Fatman13 (@fatman13) +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1033 +status: Draft +type: Technical +category: Core +created: 2024-07-10 +--- + +# Convert fundraising remainder address(es) to keyless account actor(s) + +## Simple Summary + +Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address(es) type from a multisig to account(s) that is keyless (like f099). + + +## Abstract + +At the moment, the actor holding the fundraising remainder is a _multisig_ actor. All signers are _secp256k1 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. + +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. + + +## Change Motivation + +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... + +### 1. follow the spec + +Mining reserve in the Filecoin spec is described as the following... + +> 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. +> -- excerpts from #901 + +[fundraising remainder](https://spec.filecoin.io/#section-systems.filecoin_token.token_allocation) in the Filecoin spec is described as the following... + +> 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. + +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. + +### 2. governance + +> 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. +> -- excerpts from #901 + +Similar to the point #901 made, this proposal is to amend the inadequacy that network in its early days has neglected. + +### 3. security + +> 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. +> -- excerpts from #901 + +fundraising remainder address(es) face identical security challenges as mining reserve too. + +### 4. operation + +> 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). +> -- excerpts from #901 + +fundraising remainder address(es) face identical operation challenges as mining reserve too. + +## Specification + +Convert fundraising remainder actor type from a _multisig_ to _account_ type. The new account actor should be keyless, like `f099`. + +```rust +pub struct State { + pub address: Address, +} +``` + +The new fundraising remainder actor will contain a self-reference to its ID address in the `address` field. + +## Design Rationale + +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. + +## Backwards Compatibility + +This change is not backwards compatible. Upon the activation of this FIP in a network upgrade: +- the actor type of fundraising remainder will be migrated from _multisig_ to _account_. +- the existing signers of the fundraising remainder multisig will no longer be able to perform operations on the actor + +## Test Cases + +- Get actor cid of fundraising remainder should return actor code cid of an `account` + +## Security Considerations + +This proposal improves the network security by removing the ownership and control of 2.5% of the total network token supply from individuals and putting it under the control of network participants via the appropriate governance processes. + + +## Product Considerations + +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. + +## Implementation + +TODO + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 4ed1b00a2c57c03e1f3bf7303d157e8d8c7fea80 Mon Sep 17 00:00:00 2001 From: Yu Date: Wed, 6 Nov 2024 09:40:31 +0800 Subject: [PATCH 2/5] update per editor feedbacks --- FIPS/fip-00xx.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/FIPS/fip-00xx.md b/FIPS/fip-00xx.md index 98834a01..5f425219 100644 --- a/FIPS/fip-00xx.md +++ b/FIPS/fip-00xx.md @@ -13,12 +13,12 @@ created: 2024-07-10 ## Simple Summary -Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address(es) type from a multisig to account(s) that is keyless (like f099). +Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address [f0122](https://filfox.info/en/address/f0122) type from a multisig to account that is keyless (like f099). ## Abstract -At the moment, the actor holding the fundraising remainder is a _multisig_ actor. All signers are _secp256k1 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. +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. 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. @@ -59,7 +59,7 @@ fundraising remainder address(es) face identical security challenges as mining r > 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). > -- excerpts from #901 -fundraising remainder address(es) face identical operation challenges as mining reserve too. +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. ## Specification @@ -89,7 +89,7 @@ This change is not backwards compatible. Upon the activation of this FIP in a ne ## Security Considerations -This proposal improves the network security by removing the ownership and control of 2.5% of the total network token supply from individuals and putting it under the control of network participants via the appropriate governance processes. +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. ## Product Considerations From 41e67258ec7b102d36839f011400764587c12b07 Mon Sep 17 00:00:00 2001 From: Yu Date: Mon, 18 Nov 2024 10:29:38 +0800 Subject: [PATCH 3/5] update per editor comments --- FIPS/fip-00xx.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/FIPS/fip-00xx.md b/FIPS/fip-00xx.md index 5f425219..32ec3603 100644 --- a/FIPS/fip-00xx.md +++ b/FIPS/fip-00xx.md @@ -13,12 +13,12 @@ created: 2024-07-10 ## Simple Summary -Similar to [#901](https://github.com/filecoin-project/FIPs/discussions/901), covert fundraising remainder address [f0122](https://filfox.info/en/address/f0122) type from a multisig to account that is keyless (like f099). +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). ## Abstract -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. +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. 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. @@ -89,12 +89,12 @@ This change is not backwards compatible. Upon the activation of this FIP in a ne ## Security Considerations -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. +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. ## Product Considerations -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. +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. ## Implementation From 44c20afa5c7f011888a9b50e062e1bf150419ca0 Mon Sep 17 00:00:00 2001 From: Yu Date: Wed, 20 Nov 2024 14:57:36 +0800 Subject: [PATCH 4/5] update README and assign fip # --- FIPS/{fip-00xx.md => fip-0096.md} | 2 +- README.md | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) rename FIPS/{fip-00xx.md => fip-0096.md} (99%) diff --git a/FIPS/fip-00xx.md b/FIPS/fip-0096.md similarity index 99% rename from FIPS/fip-00xx.md rename to FIPS/fip-0096.md index 32ec3603..e8e6f4d3 100644 --- a/FIPS/fip-00xx.md +++ b/FIPS/fip-0096.md @@ -1,5 +1,5 @@ --- -fip: "00XX" +fip: "0096" title: Convert fundraising remainder address(es) to keyless account actor(s) author: Fatman13 (@fatman13) discussions-to: https://github.com/filecoin-project/FIPs/discussions/1033 diff --git a/README.md b/README.md index ca7dba33..4418223b 100644 --- a/README.md +++ b/README.md @@ -131,3 +131,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia), Alex North (@anorth), orjan (@Phi-rjan) | Final | | [0094](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0094.md) | Add Support for EIP-5656 (MCOPY Opcode) in the FEVM | FIP | Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) | Accepted | | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Accepted | +| [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | From a84a89685fd26b19142151adfb740c71a2bed744 Mon Sep 17 00:00:00 2001 From: Yu Date: Fri, 22 Nov 2024 09:50:30 +0800 Subject: [PATCH 5/5] update per comments --- FIPS/fip-0096.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-0096.md b/FIPS/fip-0096.md index e8e6f4d3..9155e340 100644 --- a/FIPS/fip-0096.md +++ b/FIPS/fip-0096.md @@ -52,7 +52,7 @@ Similar to the point #901 made, this proposal is to amend the inadequacy that ne > 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. > -- excerpts from #901 -fundraising remainder address(es) face identical security challenges as mining reserve too. +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. ### 4. operation