Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FIP-0096: Draft for convert fundraising remainder address(es) to keyless account actor(s) #1080

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

FIP-0096: Draft for convert fundraising remainder address(es) to keyless account actor(s) #1080

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b6437db
Create fip-00xx.md
Fatman13 Oct 31, 2024
4ed1b00
update per editor feedbacks
Fatman13 Nov 6, 2024
41e6725
update per editor comments
Fatman13 Nov 18, 2024
44c20af
update README and assign fip #
Fatman13 Nov 20, 2024
a84a896
update per comments
Fatman13 Nov 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 104 additions & 0 deletions FIPS/fip-0096.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
---
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
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 [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. 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.


## 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

Fatman13 marked this conversation as resolved.
Show resolved Hide resolved
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. 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

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 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

f0122 only has ~300FIL in it not 2.5% of the network supply at the time this FIP is proposed, and also the last value transfer > 1FIL happened in 2021 Nov. I don’t think this fip improves the network security as it stated by the author.

Copy link
Contributor Author

@Fatman13 Fatman13 Nov 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the input! Appreciate the comments.

f0122 only has ~300FIL in it not 2.5% of the network supply at the time this FIP is proposed

i don't think the text suggested there is 2.5%, it reads "whatever it is the remaining of the 2.5%".

I don’t think this fip improves the network security as it stated by the author.

That's the point Jorge has been making and the text has been updated to address his comment. I am not sure why editors are fixated on very narrow view of network security. Even a simple question to AI (i used Grok) would give you the following... (point 8 in governance specifically)

how to define the security of a decentralized blockchain network?

Defining the security of a decentralized blockchain network involves considering several key aspects:

  1. Consensus Mechanism
    Proof of Work (PoW): Security is maintained by making the cost of altering any part of the blockchain prohibitively expensive due to computational power needed to mine blocks. Bitcoin uses this method, where miners compete to solve complex mathematical problems, and the first to solve it adds a block to the blockchain.
    Proof of Stake (PoS): Security comes from validators who lock up their cryptocurrency as a stake. The likelihood of being chosen to validate a block is related to the amount of cryptocurrency staked. Ethereum is moving towards this model with Ethereum 2.0. PoS reduces the risk of 51% attacks since attacking the network would mean losing the staked funds.
  1. Node Distribution
    A blockchain network's security is enhanced by having a large number of nodes spread across different geographical locations. This decentralization makes it harder for any single entity to gain control over the majority of the network’s computing power or decision-making processes.
  1. Cryptography
    Public-Key Cryptography: Ensures that transactions are secure by using digital signatures to prove ownership. Only the holder of the private key can authorize transactions, reducing the risk of fraud.
    Hash Functions: These are crucial for linking blocks in the chain. Even a tiny change in data will produce a vastly different hash, making it nearly impossible to alter past transactions without detection.
  1. Network Consensus and Forking Rules
    How the network decides on the validity of transactions and blocks, and the rules for what constitutes a valid fork in case of disagreements (like soft forks vs. hard forks), significantly impacts security. Networks with clear, followed rules can resist attacks better.
  1. Economic Incentives
    The design of rewards and penalties in the network can enhance security. Miners or validators are incentivized to act honestly due to the potential for reward (like block rewards or transaction fees) and the risk of losing their stake or being ostracized from the network for malicious behavior.
  1. Sybil Resistance
    The network needs mechanisms to prevent Sybil attacks where an attacker subverts the network by creating a large number of pseudonymous identities. Techniques like PoW or PoS inherently resist this by requiring significant resource commitment.
  1. Smart Contract Security
    For blockchains that support smart contracts (like Ethereum), the security of these scripts is crucial. Bugs in smart contracts can lead to significant losses, as seen with events like the DAO hack.
  1. Governance
    How changes are proposed, debated, and implemented can affect security. Good governance ensures that updates to the network are beneficial and do not introduce security vulnerabilities.
  1. Privacy and Anonymity
    While not always directly related to security, ensuring user privacy can enhance the overall security perception and usage of the blockchain, as seen with technologies like zero-knowledge proofs.
  1. Auditability and Transparency
    The ability for any participant to audit the entire blockchain or parts of it ensures transparency, which in turn supports security by making malicious activities easier to detect.

Securing a blockchain involves a holistic approach where all these elements work together to create a robust defense against various threats. Each blockchain might prioritize these aspects differently based on its intended use and philosophy. However, the fundamental goal remains the same: to ensure that once data is written to the blockchain, altering it is either extremely difficult or economically unfeasible.



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

TODO

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
Loading