Filecoin Protocol Architecture Master Plan Discussion (Updated 23/07/14)

[Fatman13]

Continuing discussion here with this new thread...

Simple Summary

Use a layered protocol design approach as guidelines to all future technical FIPs on L1 and L2.

Abstract

Video recording of proposed FIP#725 overview presented during core dev meeting 59.

We think the solution to many of the current protocol design dilemmas is a layered approach to protocol architecture design. Using an application stack analogy, to support generic applications to be run in computers, the OS layer focuses solely on managing processes, expose hardware resources, facilitate communications between apps, etc.

By defining clear stratification and roles of each layer within the protocol architecture, we think Filecoin network as whole would then able to evolve into its next stage.

What's more, the layered approach is only doable after FEVM launched in March, 2023. For the longest time since mainnet launch, the Filecoin protocol itself is the product for data storage. It has to couple with all kinds of complexity a storage product requires. However, now we have the option to clean up the core protocol layer and push the storage product to layer 2 so that Filecoin core protocol can actually transition into a platform, just like the OS layer on the previous analogy.

Change Motivation

The following are some of common protocol design challenges we are facing today, which the proposed protocol master plan tries to address.

Drastic protocol changes fail to reach soft consensus

One of the recurring problems we see throughout the past is that FIP governance is not quite able to have the community to reach soft consensus on drastic protocol changes, for example, changes like FIP36, FIP56, etc. It is very hard to setup definitive process on the how we can reach consensus, to understand which group should or should not weigh in on the decisions, or to increase governance engagement in general.

Protocol limitations stalling ecosystem innovations

Then we have the problem of slow protocol iteration stalling innovations on user-defined defi and storage solutions. Many defi solution have to incorporate cefi elements due to limitation of protocol and user-defined storage market is being out-competed by the built-in network subsidies.

Incremental FIPs with no strategic goal

Lastly, we have the problem of FIPing with no clear strategic goals. A Lack of priorities and principles to guide which FIP should be discussed and implemented next. Just like the network as a whole needs a master plan to steer its development and priorities, the evolution of Filecoin protocol itself also needs a master plan to adapt itself in the ever changing market environment. Right now, FIPing is like guerrilla warfare with no clear end-game in mind. In a way, battles are won but the war is lost. Only with a Filecoin protocol master plan thoroughly and openly discussed, then we could move on to take the network to the next level/stage.

Specification

Again all details in this version of Filecoin protocol master plan design is open for discussion. No particular parameter is set in stone. (Ideas borrowed from @steven004)

What we like to stress again is that, on the left side of the illustration above, before FEVM Filecoin protocol itself is the storage product and everything is tightly coupled. Like in an old Chinses saying "牵一发动全身", which means "pulling one hair is affecting the whole body". And on the right side of the illustration above, the core protocol layer, like rewards, miner, consensus, and prove of storage, are completely separated from user layer, where products and application are actually built. This layer division effectively makes Filecoin core protocol as a platform.

Layered Approach Mandate

Layered protocol design approach mandates future technical FIPs to contribute to the realization of the following protocol stratification.

L1 - core protocol: reward, consensus, miner, proof of storage
L2 - user/application layer: Rest of the actors

Example Path To Layered Approach (1)

Important Note: this path is not mandated by this FIP, but a mere example on how layered approach could be realized.

• Level all sector power: CC sectors and DC sectors will all just have raw byte storage power, effectively removing concept of QAP and reducing L1 complexity.
• Add subsidy built-in actor: with sectors normalized, the subsidized reward for storage deals is completely decoupled from storage power and will be managed by subsidy built-in actor. (revisit of FIP0033)
• Move market actor to L2: introduce a concept of verified market actor on L2 which can enjoy its share of the reward from subsidy actor if network participants made storage deals through this actor.
• Dynamic reward sharing: block reward will be shared between subsidy and miner actor, each claiming 50% of the BR with subsidy gradually decay to 10% of the BR. (revisit of FIP442)
• Cap slashing for consensus miner: ongoing FIP712 discussion.

Example Path To Layered Approach (2)

Another potential route proposed by the community @kernelogic.

Design Rationale

Important Note: rationale follows up with the example spec above and is not mandated by this FIP, but a mere example on the effects of layered approach.

One of the key characteristics of this design is the layered approach through decoupling a complex interlinked system into two distinct functional space.

Leveling all sector power is the corner stone of the whole design. All sectors are born equally through PoRep and should be treated equally. QAP not only adds unnecessary complexity to L1 as the network is slowly but surely becoming a DC only network (with growing security concerns), but also couples rewards with storage power which limits many potential innovations on a truly value driven storage deal marketplace. Besides, with QAP gone and subsidy for storage deals untied from storage power, the protocol could actually leverage L2 to have much more flexible ways to subsidize storage deals.

To achieve the eventual paid storage deals for network participants and to accommodate f+ program, a 50-50 BR split between the subsidy and miner actor is proposed. This roughly allows every network participants to maintain its current block revenue, as at the writing of this proposal QAP of DC and QAP of CC are relatively close. To help network participants to transition from subsidized deals to actual paid deals, the share of subsidy BR will be ever shrinking according to a f(x) and reach a 10-90 BR split with miner actor in the end.

Once the market actor is pushed to L2, it can then experiment with various deal terms to suit whatever client and provider want without the need to wait for a FIP discussion or a network upgrade. A governance body can determine which market actor to become a verified one to gain access to the deal subsidies from the subsidy actor.

With user-defined layer and protocol layer properly separated, the core L1 consensus could just focus on what it does the best, namely EC based on storage capacity, a Turing complete vm and lastly storage proofs including PoRep and PoSt with sector as its fungible unit.

With unnormalized sector pledge where for 1 TiB of sectors you may have pledge ranging from 4 fil to 10 fil and slashing derived from BR when the sector is sealed which means that some sector may still have pledge left after slashing while some may go into debt after slashing, this complicates storage apps building on top of this complex slashing system, stalling innovations on user-defined financing and storage markets.

Additional design rationals... 1

Incentive Considerations

Important Note: considerations follows up with the example spec above and is not mandated by this FIP, but a mere example on the effects of layered approach.

The way protocol design is setup right now wipes out the potential for user-defined storage market because the incentive for QAP is too strong for it to compete. Given the new design, network incentive for early data on-boarding adopters could gradually be phased out and be substituted with proper market driven storage exchange.

As reward for consensus mining become more predictable, a bigger pool of swing miners would likely to join and contribute to the security of the network. They can have better assessment of their share of the BR, their liquidity status to hedge against macro economy uncertainty, and potentially start storage providing if incentives are aligned.

Product consideration

Important Note: considerations follows up with the example spec above and is not mandated by this FIP, but a mere example on the effects of layered approach.

With the above design, it also comes with explicit separation of roles, namely consensus miner and storage provider, so that they could co-exist and each serves its purpose in the network.

[steven004]

Thanks for bringing this up for discussion, @Fatman13 , we need a layered structure for future innovations and development.
I'm supporting this, and would like to add more thoughts here:

The main purpose of this proposal is to decouple the containers (Sectors) from the goods (Pieces), standardizing the containers while allowing for different types of cargo (32G/64G or 1T perhaps later). In the current design, we consider the goods and containers together, and regardless of the type of goods - whether it's gold, silver, used jeans or garbage - the same incentive mechanism is applied (10x power for verified goods). After decoupling, the Layer1 protocol ensures the integrity of the containers and verifies the correctness of the goods within the containers. However, the storage, transportation, and other transactions related to the goods themselves are handed over to the market.

Moreover, the design of the Subsidy actor allows for maintaining incentives for the current Fil+ program and removes the constraints on innovation in market incentives. The Fil+ can be achieved through the Verified Market (including Datacap, VerifReg, Notaries) by collateralizing FIL to the Subsidy, addressing unnormalized pledge issue as a side effect. At the same time, it leaves room for the community to create new Verified Markets (another Fil+, or Fil*). Of course, we would greatly welcome the use of user-defined tokens to incentivize markets later on, as it would reflect the value of different markets or platforms through the token. In a competitive and open market, the platforms that best meet user demands will emerge victorious, which is the result of market choice rather than being defined by the protocol.

[Fatman13]

The silence is deafening...

[The-Wayvy]

This needs to be discussed in the Filecoin notary governance calls and core devs call.

As you say, there is too much central planning going on; bottom-up innovation is where 0 to 1 happens.

I for one don't understand the beef with consensus mining and expect raw power to continue to decline until a clear plan is drawn up to phase out FIL+.

[jennijuju]

I am hesitant to participate in this discussion as it is titled "Protocol architecture master plan" - which is a very big topic. It is unclear to me what are the problem statements of the existing architecture and how the proposed "specification" will address them, and thus prevent me from discussing the potential opportunities.

For me personally, it will be easier if we can scope down to a more specific problem/opportunity. For example, am I right that you are mainly pointing out that the most significant gap in the protocol today is in power accounting and rewards distribution? and would like to discuss if we should move both of them to be pure content-independent storage commitments based?

[Fatman13]

Sorry about my poor wording and thank you for the reply!

It is unclear to me what are the problem statements of the existing architecture and how the proposed "specification" will address them, and thus prevent me from discussing the potential opportunities.

The problem of existing architecture partly contributes to much of the problem laid out here along with macro economic downturn. Especially with SP sustainability and long-term participation challenges, the proposal tries to lay a broad path (with details up to discussion) to address these issues.

For example, am I right that you are mainly pointing out that the most significant gap in the protocol today is in power accounting and rewards distribution?

I think one of main issues is that people don't know if there is any long-term plan for roles of L1 and L2 in Filecoin network as a lot of people on the ground see current architecture would inevitably lead the network into a dead end. And it is my opinion that you don't win a war by focusing on battles but rather the big picture. With regard to this particular discussion, the mindset needs to be shifted from being a frontline infantry to being a general.

[steven004]

Indeed, the "Protocol architecture master plan" is a very big topic, and also an important topic. I appreciate @Fatman13 for bringing it up and initiating the discussion.

While the Coredev team has been focused on incremental improvements, it is crucial to engage in strategic discussions to provide guidance and direction for the protocol's evolution at a higher level. @jbenet has shown the community a three-step master plan for Filecoin, which is visionary and provides valuable insight. How to achieve that, there would be lots of innovation to be implemented. It is the responsibility of the Coredev team to define an evolving plan for core protocol and the architecture, possibly categorizing it into different areas, where incremental improvements can align with the broader direction. By doing so, the team can ensure a clear vision and roadmap for the protocol's development, benefiting the entire community.

From the Filecoin master plan, you can tell the whole picture is huge, and which must be have a layered design, and let the implementation in easy layer is replaceable and could accommodate disruptive innovations.

Every time when I see the following picture (A simplified vision of Filecoin’s Economy picture by BlockScience), I would think this must be changed. We need to have a simplified, layered, decoupled, easier-to-evolving design, and we need to discuss how. @Fatman13 just initiated this, more ideas are appreciated.

[anorth]

Thanks for opening this discussion, but it is difficult to engage with. I was hoping for more comments from others in the community before I wade in, but here we go. You seem to be trying to achieve three different things:

1. Calling for a better defined protocol strategy and proposing some solid general principles
2. Outlining a collection of concrete but under-specified changes to the protocol
3. Implicitly, through (2), advocating a specific policy change of decreasing the influence of FIL+

The first part is simple and easy to get behind. I see nothing to object to in your abstract or motivation. I agree that identification of a strategy for protocol development, and some clear design principles, would make it much easier to deliver improvements. But these need discussion at a higher level before proposals of specific changes have any chance of landing. The two principles suggested omit any discussion of Filecoin's core reason to be (e.g. consensus mining network with storage byproduct, vs storage-first network) or policy/principles that would motivate, say, decreasing influence of FIL+ or encouraging non-storage miners. The subsequent specification doesn't follow from the motivation.

The changes proposed are unfortunately not sufficiently detailed for me to engage much on a technical level. To be credible, they need some more detail on how to achieve those outcomes. One reason for lack of engagement may be that the proposal is not clear enough for anyone to understand how it will affect them, other participants, and the emergent properties of the network as a whole. I know that such detail is a lot of work. You might criticise some of my proposals as being too incremental, not cutting at the heart of (what you see as) a core problem. But that incrementalism means they are implementable, we know how to get from here to there, and then we can build the next step. Some of the problems that are implied by your proposals can be solved other ways. As @jennijuju suggests, if you can call out the specific problems more precisely then, if there's easy alignment on that problem, we can solve them.

The third part needs to come back to the first. There are clearly differing opinions from different participants about the network's identity and the role and value of FIL+. This opening comment doesn't leave much open space for that discussion, despite inviting it. I think calling for that discussion is laudable, and there is room for someone to lead it, but they would have to do so without bias toward a particular outcome in order for conclusions to be credibly adopted.

[Fatman13]

Thank you for you reply!

I was hoping for more comments from others in the community

The community is unfortunately shrinking (close to a halt) or maybe an environment for open discussion is not fostered by FIP governance.

I agree that identification of a strategy for protocol development, and some clear design principles, would make it much easier to deliver improvements. But these need discussion at a higher level before proposals of specific changes have any chance of landing.

Great! Let's start a new FIP or use this one to discuss. I think once principles are ironed out, it would send a much clearer message to miners across the board so that they could make educated business decisions.

The two principles suggested omit any discussion of Filecoin's core reason to be (e.g. consensus mining network with storage byproduct, vs storage-first network) or policy/principles that would motivate, say, decreasing influence of FIL+ or encouraging non-storage miners. The subsequent specification doesn't follow from the motivation.

All principles are open for discussion. It may come off as purely "decreasing influence of FIL+" because of my poor choice of words. However, there are many others, for one there is to increase network security as network is getting close 50% RBP and 50% QAP attackers can literally just use less than 10% of the network's total hardware and achieve 51% attack. This to me really isn't a good network foundation for a Dapp ecosystem to build upon.

The changes proposed are unfortunately not sufficiently detailed for me to engage much on a technical level. To be credible, they need some more detail on how to achieve those outcomes.

Yes. This is why it's a master plan discussion. There is no technical details in, for example, Juan's master plan or Vitalik's plan to transition to POS. The proposal is mostly calling for protocol general direction discussion and is not meant to come up with all the specifications.

This opening comment doesn't leave much open space for that discussion, despite inviting it. I think calling for that discussion is laudable, and there is room for someone to lead it, but they would have to do so without bias toward a particular outcome in order for conclusions to be credibly adopted.

Yes, exactly. Like you said three leads back to one. Everything is tightly coupled together and there is no breaking down the scope and "solve one particular problem" so to speak. You broke it down to three and one leads to another! This is why the protocol master plan is presented in whole.

[haheihou5]

我来支持这个提案,非常的专业
I support this proposal, it's very professional,is my wish too

[momack2]

I agree with @anorth that if your desire is to talk about evolution of the protocol and it's design principles - we should focus on that topic separately from any proposed protocol changes (which IMHO don't seem well motivated / in support of our Filecoin network mission "to be a robust foundation for humanity's information").

I think talking big picture about the way that the Filecoin network achieves security (both hardware, FIL collateral, and payment for storage of real user data), scales its storage and compute activity (via L2s and FVM), and evolves its storage market to onboard more useful data and incentivize retrievability (while letting additional storage/compute/etc markets elsewhere flourish) -- are very good principles to make concrete and align on. 👍

However, by bringing in proposals such as "Level all sector power" / "push market actor to L2" - you are pushing for contentious and maybe unintentionally misaligned proposals that run counter to the purpose of Filecoin (to incentivize the onboarding of useful data - which is intentionally rewarded greater than mere hardware commitment, because it contributes more to our mission as a network). I'm personally very happy to engage in the former conversation - but IMHO that would best be done in a broader context than a FIP discussion with specific "end goals" that I agree aren't clearly motivated or aligned with Filecoin's mission / principles.

[The-Wayvy]

Molly
No one is suggesting to phase out Filecoin + overnight.
The power multiplier can be gradually decreased over a few years.
Permissionlessness is a non-negotiable property in Web3.
No marketing slogan can change that.
Neither Bitcoin nor Ethereum have ever had a similar mechanism in place.

[nothingjustaminer]

I don't understand

1. How come being neutral to all sectors is a “counter” to the purpose of Filecoin? The only deficiency seems to me is some conservative people will accuse Filecoin on encouraging “trash data storage”. But even the “trash data storage” helps stimulate the innovation of data storage in certain aspects(refer to the waste computing power of bitcoin)
2. Why moving market actor to L2 is not a feasible way that align with Filecoin’s goal in longterm? It’s what many if not most community members are supporting and these individuals who are paying for the bear market need to be convinced.

It’s not a relaxing topic. But being the core devs behind Filecoin, listen to the community and give the proposal a fair consideration is one of the meanings of existence of core devs.

[haheihou5]

我来支持这个提案,非常的专业
I support this proposal, it's very professional,is my wish too

[flyworker]

from what we saw in the fil+, it is getting more and more complicated. The SPs and the Notaries work become harder and it seems that with more notaries, it does not seems less work, each notary need more time to DD the SP and follow up, and will be challenged if something wrong happens. And noatries are more frequently point to each other cause more issues in governance.

A simpler L1 protocol will give more space for ecosystem to build product.
Agree that CC sectors and DC sectors will all just have raw byte storage power.

[The-Wayvy]

100%
It is absurd to see notaries accusing one another of fraud and corruption in Github forums
Web3 is supposed to replace the bureaucracy of traditional governance with software

[kaitlin-beegle]

Hello!! Thanks @Fatman13 and @steven004 for your work on this. I think this kind of proposal shows your personal concern and involvement in the Filecoin project, and I think that's something we should all respect.

I have a bit of a different perspective from those above, and I (hope) I can be of help to you.

First and foremost, this proposal indicates to me that we do not have good intermediary layers for governing the Filecoin protocol.

In other words, what we as a community want and need to govern- including longer team strategic planning for the development of the Filecoin protocol, and the ability to set longer term priorities that align our objectives with the overall project vision- is out of scope with the way we currently specify and manage FIPs. FIPs have evolved to steward tightly specified, technical protocol change proposals, and I don't believe that's what you're really proposing.

What we need is the ability to propose and meaningfully review policies, with our without detailed technical specifications. We also need a way to reach community consensus on difficult changes, and new spaces and mechanisms for building meaningful community feedback loops that can inform the mid- and long-term direction of the protocol. We need a robust body of community contributors who can answer questions about technical capacities and priorities in a way that aligns strategic work with the vision of the protocol. And I don't believe the current FIPs process is able to address these needs.

So what do we do? FWIW, this problem has been a pain point for me for a long time. Myself and other community members (including you both) have tried to provide solutions to these problems in incremental ways. What we actually need, however, are rather big changes, which are very difficult to establish in an open ecosystem. For example, how do we improve the FIPs process in a way that everyone agrees with? Who gets to decide what the final process looks like? Who gets to weigh in on a Filecoin roadmap that informs technical priorities with network vision, and who builds and maintains this? Etc.

To further illustrate this difficulty, I want to quickly note what you say about Core Devs:

It is the responsibility of the Coredev team to define an evolving plan for core protocol and the architecture, possibly categorizing it into different areas, where incremental improvements can align with the broader direction. By doing so, the team can ensure a clear vision and roadmap for the protocol's development, benefiting the entire community.

I don't agree with this, and I don't think this responsibility is understood or agreed to by other Core Devs. How do we fix misalignments like this? What if some Core Devs don't want this responsibility? And if they do, how do we actually coordinate work products from within this group?

As briefly mentioned to Core Devs and at the past two Community Governance Calls, @luckyparadise and I have been working within Filecoin Foundation to put together a large proposal to address some structural governance pain points. This has required a ton of work, and I don't want to commit anything until we can fully unveil the entire proposal to the Filecoin community. I do believe, however, that what you're asking for above requires some of the changes that we seek to make. At a high level, we believe this includes:

• New categories of FIPs (including technical core, community, and cryptoeconomic FIPs) with distinct governance pathways for each;
• New tooling, including documentation repos and new tools for gauging consensus and community preference;
• The formalization of community groups (like Core Devs, or the SP Working Groups) so that they have clearly defined roles in governing processes;
• Funding and tooling support for the Filecoin community to crowdsource the values and objectives that ought to guide governing priorities.

Again, your above proposal is asking for something specific; but what it requires are community governance mechanisms and spaces that are able to meaningfully grapple with large, challenging ideas. Right now, we have Core Devs, and Github Discussions, and informal community working groups, and none of these are able to transform general conversations and big ideas into focused action.

We are hoping to deliver our proposal for improved community governance in the next two-ish weeks, and I'd love your help reviewing these changes to ensure that they can meet your needs.

[Fatman13]

Thank you for the reply!

We are hoping to deliver our proposal for improved community governance in the next two-ish weeks, and I'd love your help reviewing these changes to ensure that they can meet your needs.

👍

What we actually need, however, are rather big changes, which are very difficult to establish in an open ecosystem. For example, how do we improve the FIPs process in a way that everyone agrees with? Who gets to decide what the final process looks like? Who gets to weigh in on a Filecoin roadmap that informs technical priorities with network vision, and who builds and maintains this? Etc.

IMO, when consensus for filecoin is low (ie. fil price is low), the most important "reviewer" or stakeholder FIPs should be catering to are consensus miners. Nothing can realistically be built if the foundation of the network is endangered. Whereas, when consensus for filecoin is high (ie. fil price is okay-ish), other "reviewer" or stakeholder can then have heavier weight in the process.

[steven004]

Thank you for your feedback, @kaitlin-beegle. I appreciate your efforts to improve the process and governance, which are crucial aspects. I agree with your point that this proposal discussion may fall outside the current scope of specifying and managing FIPs.

From my perspective (note that @Fatman13 may have a different opinion), this discussion is not solely about process and governance but rather an initiative to discuss the technical direction. It may or may not align with an FIP, even after achieving consensus, and there could potentially be multiple FIPs that align with the direction.

I was thinking of the responsibility of the Coredev team from a technical standpoint, since the proposed architecture change would redefine the core protocol, which is a concern shared by every Coredev member. In this proposal, if we choose to incorporate a subsidy actor to explicitly incentivize real data, all market-related and real data-related concepts would be moved out of the core protocol layer. This narrowing down of the core protocol scope is possible now after the FEVM landed and native FVM is on going, which would enable flexible innovation on the upper layer, eliminating the need for consensus.

My hope is to see the Coredev team focus on building something like the kernel of an operating system that supports any applications the community desires to build. Through discussions on the protocol architecture master plan, we can return the market to market, return data deal design to service platform, and empower unlimited innovations of data evaluation and related incentivization without the need for consensus.

[kaitlin-beegle]

@Fatman13 the idea of token price indicating 'consensus' is an interesting idea, but not one I fully understand. In my opinion, the FIlecoin community should support good policy, regardless of what's happening in token markets. Good policy should support the network, which should ultimately benefit storage providers.

@steven004 totally. Your proposal is multifaceted! My point is merely that the scope of changes you're seeking to discuss are simply not supported by the current FIPs process. We need to offer new tooling and processes to accommodate changes this complicated. That's the piece I am hoping to improve. And once it's available, it's merely my job to help get fair, public consideration for your technical proposals :)

And I see what you're saying about the Core Devs- I agree that this proposal, in theory, should seem to fall under their purview. But, as a group of engineers who volunteer their time as Core Devs, I'm not sure that organization has the authority or ability to move the needle on a proposal of this scale.

[The-Wayvy]

Let's make a DAO where SPs can vote on each FIP with their ballot weighed by their raw byte power.

[dcasem]

@The-Wayvy we've built a first iteration of this:

https://github.com/fip-voting/backend
https://www.loom.com/share/b8b376b5bd5c40b9b0f1275d80cbd1a8

[Destore2023]

Really need to think about what else we can do to keep filecoin chain active when the FIL+ project is gradually losing its effectiveness in attracting more participants , and there is no active and real commercial storage deals for filecoins then.

This proposal provides us with a possibility. IMO, It improves more flexibility in the future More comments are welcome.

[woshidama323]

I believe that the current process, strategy, and management of FIP are very good. @kaitlin-beegle
In my opinion, @steven004 and @Fatman13 are mostly providing some ideas and suggestions from a technical perspective to help Service Providers (SPs) operate better, because under the current market environment, as a regular SP, our survival space is not very good. We really hope to get such help so that we can get through these difficult times.

I think @steven004 and @Fatman13 are fully capable of providing more detailed technical details. I suggest we can break down the current discussion, case by case, to avoid misunderstanding.

[nothingjustaminer]

It's absurd that Filecoin insist on embedding an expensive and parasitizing social consensus layer to encourage the mission "to be a robust foundation for humanity's information".
Data cap in Filecoin is the most bureaucratic design ever in the blockchain space which was exactly why many storage providers like me have quit this business. This has obviously deviated from the value of the blockchain and web3. I'm not surprised that rent-seeking behaviors aroused dissatisfaction in the Filecoin community now.

Doing one thing(storage) well is great enough, don't be arrogant and think you can solve various problems(define what's valuable; decide who should be rewarded, etc) all at once.
If there is a way to solve the current disagreement in Filecoin, it has to be removing the data cap design from Filecoin protocol. Data cap was an experiment that might worth a try at the beginning. But now we know it's not working, we adjust the experiment.

Many storage providers and Filecoin holders are here only because they believe in the value of decentralised storage network not the value of bureaucratic storage network. As long as it's decentralised, it will come back. Or it’s just a cumbersome and unusable prototype. This is very serious.

I hope PL and the Filecoin community can be more open minded and take a positive approach to fix this before things get worse.

Possible solutions IMO:

1. Gradually eliminate the influence of data cap like what mentioned in this proposal
2. Immediately cancel the design of data cap on the protocol level
3. All notaries can voluntarily stop approving any data cap proposal. All honest storage providers can stop sealing more verified sectors.

[nothingjustaminer]

I agree that we don’t have to focus too much on the flaws of filecoin plus here.However problem is our motivation of changes. We should highlight motivation because not everyone understands the urgency of it. Filcoin plus is an obvious disadvantage of the protocol that needs to be mentioned considering we want to talk about the evolution of Filecoin protocol. Passengers are always there, but without drivers Uber will be doomed. A protocol that is pushing away service providers is not evolving but degenerating.

I think it's fair that storage providers share how they feel about the protocol in this discussion because the change of protocol will affect everyone in Filecoin. It’s also necessary that core devs hear thorough information about how the project is actually going and how it is going to be end if we don’t make changes to the protocol. Our blockage is too little information exchange, not too much information redundancy.

Again, what many of us worry about is the survivorship of Filecoin because of the social layer tumor that we overlooked. We need agreement on this. This should lead our way to evolution. This is the reason we ask for changes.

[steven004]

As mentioned by @momack2, the mission of the Filecoin network is "to be a robust foundation for humanity's information," which is unquestionable and forms the basis of our discussions. Within this premise, we are discussing how a better protocol architecture can better serve the development and long-term realization of this mission.

One important reason I am interested in this proposal is that I believe the current technical architecture needs improvement after the introduction of FVM to accommodate new developments. Due to historical reasons, Filecoin's design is a monolithic structure aimed at achieving a grand vision without considering the VM. This has resulted in interdependencies, associations, couplings, and entanglements among Actors. We have recognized that Filecoin is a complex network, and to meet market demands, a more modular, decoupled, simpler, and easily evolvable layered design is possible. The layered design itself is intended to better fulfill Filecoin's vision, including providing better and more reasonable incentives for storing and retrieving real data and better meeting market needs.

We have already been working on moving the Market actor to the user space, but that is far from enough. The proposal suggests using Subsidy to explicitly incentivize the storage and retrieval of real data, opening up possibilities for different incentives (distinct from the current uniform incentives without evaluating data value), such as applying a 20x multiplier for DeSci and a 2x multiplier for cold storage monitoring data. Of course, the ideal approach would be for the market to choose and decide, allowing free competition and development rather than being hard-coded in the core protocol.

I suggest that we do not focus too much on Fil+ in this discussion, although everyone is interested in it and hopes for changes. If necessary, we can start a separate thread for that topic. Here, we should concentrate on the evolutionary path of the core protocol. The initial evolution should strive to be compatible with existing patterns and create conditions for future development.

[Fatman13]

I suggest that we do not focus too much on Fil+ in this discussion... we should concentrate on the evolutionary path of the core protocol.

+1

[The-Wayvy]

We already have a robust foundation for humanity's information. Amazon and Alibaba work fine.

The point is to use the design principles that Bitcoin/Ethereum pioneered to create a storage network.

FIL+ in its current form violates one of those core principles: that the platform be neutral and permissionless.

As I've said before: neither Bitcoin nor Ethereum ever resorted to manual inspection of transactions for determining block rewards.

Users experimented with different use cases over many years, and eventually product-market fit was found.

Those design principles involve a trade-off, because all of the existing services that users are accustomed to have to be re-built in a crypto compatible way

ex. Ethereum didn't have a good way to swap assets until over 3 years after it launched.
ex. Filecoin doesn't yet have incentivized data retrieval

Therefore early on the network will be less convenient for most traditional use-cases than its web2 counterpart.

And so you cannot expect to have big, established players come in and pay for your network's services. First you need to win the crypto-native market.

If you try to shortcut growth with a bureaucracy and service agreements that aren't enforced or incentivized by the protocol then you will not get loyal customers or SPs.

Starting a separate thread is fine, but don't try and say that changes to FIL+ aren't directly related to the topic at hand.

Distribution of block rewards is the most important part of any protocol.

[Fatman13]

Agree with you 100%, @The-Wayvy. It's just that we are trying to build a narrative that is easier for core-dev to digest, or we risk core-dev just disengage the conversation completely by arguing minute semantics instead of what the network needs to survive. 😂

I think most of savvy filecoin miners have already reached such consensus (like what you have described). Only peice left in the puzzle is to convince the core devs to put things in motion, which is no easy feat. 😢

[SwitfSystem]

Support this proposal Friendly support for ecological development

[DecentCr8]

Glad to see the discussion about the master plan, targeting to simplify the core protocol—a commendable goal. However, I would like to propose an alternative approach that I believe is simpler.

Given the idea of separating the handling of real data, why not implement this separation now? By envisioning the ultimate form, the Core Protocol would solely focus on proving data proof, rather than evaluating data and deal handling. Implementing this approach immediately would require minimal effort, as there would be no need to add the Subsidy Actor or make changes to DC, CC, QAP, and other elements that do not matter any longer in the absence of verified deals.

At present, we only need to do one thing: ceasing the use of FIL to incentivize FIL+. Instead, we can adopt a new incentive mechanism at layer 2 for FIL+.

Then, we will subsequently simplify the code later once all verified deals have expired.

[ArthurWang1255]

A very important word is mentioned in the text but not emphasized. "Flexibility".

I believe flexibility is what we should pursue, not just quality or efficiency. When we talk about quality and efficiency, our perspective is limited and we are trapped in the internal perspective. We're assuming that the external environment is irrelevant or unchanged.

Truth is, the external environment plays an extremely important role and is always changing, and it is not determined by our subjective will. Every one of us, every great company and country, is the result of adaptation to the external environment.

So if we agree that the ability of adapting to external changes is important, how do we evolve Filecoin protocol? Here comes the "Flexibility". Flexibility helps Filecoin's adaptation in the long term. It undoubtedly greatly improves the chances of success for Filecoin.

Bruce Lee had an inspirational quote: "Be water my friend."

If we can somehow simplify the protocol, make Filecoin more flexible in one of the following network versions, I suggest we call that version "Water Upgrade".

[kernelogic]

I have an idea, to make the network completely permissionless again, is to allow verified deal not consume any datacap. Any deal can be marked as verified and pledge 10x collateral.

Option 1: If the SP wants to make money by pledging more and get more block rewards, sure, ask the deal to be verified and free of charge to the client.

Option 2: If the SP wants to make money by accepting paid deals and not pledging that much, also possible! Just ask the deal to be unverified and priced.

Some people have been arguing some data not worth 10x verified and some does, why don't just give the freedom to the user let different business models decide themselves.

Some people might argue ohh no one will want to do option 2 that's crazy, well, have you thought of, maybe, just maybe, Filecoin storage UX is not attractive enough to let client pay? Put improving UX as the top priority rather than set up all sorts of governance bodies to decide who gets to use the network.

Aug 2 update: seeing this have gotten some attention I did not expect in the beginning. I want to point out if this is the way we choose to go, until Option 2 becomes the mainstream, the whole network QAP will keep growing and getting closer to 10x of the raw bytes (every sector is a verified deal), how baseline / block reward / annualized rate of return look like, will be much different from today.

Aug 3 update: today I learned that we have 10EiB CC sectors and a little over 400m circulating supply. Even if all these CC sectors want to snap upgrade to 10x, there will not be enough Fil to do so. Therefore the eventual outcome will not be as bad as I imagined. It would actually look pretty positive to the price and potentially turn this downward spiral to upward!

[anorth]

This proposal is a specific version of a more general idea of letting SPs pledge any amount they want, above the required minimum, gaining proportional power and share of reward. It needn't have anything to do with FIL+.

I do think this class of idea is worth exploring, though it probably needs some more:

• It has potential to increase token locking by those parties who are keen to do so, unconstrained by datacap availability.
• It leans into the proof of stake security, rather than proof of work. This is an accurate view of what actually secures the network today, but perhaps not where many participants would wish for the future direction.
• In the extreme, it removes incentives to commit storage, since an SP could put up huge stake for a single sector. A better version of this idea would allow arbitrary staking but also incentivise the commitment of incremental storage capacity.
• It undermines the utility of FIL+ as a subsidy to fund the development of data onboarding tools and processes (I realise that the original proposal here is that such subsidy should exist but be decoupled from consensus power).

[steven004]

That is what the subsidy really could work for, PoS. That's why I think this design is more flexible. While moving Fil+ to the user space, it could still use the native token (FIL) to incentive real data storage; And, while the Fil+ has a totally new economical system depending on the secondary token(s), the subsidy could be used for storage-irrelative staking with minimum design changes only.

[The-Wayvy]

No to Proof of Stake

[Fatman13]

Taking first step towards Filecoin protocol protocol master.