IPC and gas sprawl: summary, work plan and timeline #64
Replies: 4 comments 3 replies
-
|
Thank you @AxCortesCubero IPC plans to live on Filecoin mainnet in user-space as 2 user-defined FVM actors (smart-contracts). How could one identify these and "regulate" them? To better explain my question, imagine we write these two smart contracts on another L1 network. Would this L1 upgrade the network every time someone deploys open-source IPC code in two smart-contracts to "regulate IPC"? I do not think general-purpose smart contracts can, in a sustainable way, be "regulated" as proposed. Even Bitcoin with Taproot obfuscates "smarter contracts", making them indistinguishable from regular txs that use Taproot addresses. I strongly suggest we apply here well known but forgotten economic adage: "laissez-faire". Not because I personally prefer it (even if I do). In fact, my stance is that open source general purpose smart contract code, which is regulated on one network, will be redeployed and renamed on that network, perhaps a few times. On the one hand, if there exist "network superusers" that continuously hunt this code down, we have two outcomes: 1) this is not a permissionless network and these "superusers" are in power, 2) the code will go to a network which is permissionless and (more) decentralized without "superusers". On the other hand, if "superusers" do not exist, and would not keep hunting down redeployed code, why would we try to "regulate" even a single IPC deployment, if it could always be redeployed to circumvent the "regulation"? Finally, I do not believe humans can regulate markets better than markets can regulate themselves - but this is personal opinion and is not the key point in the argument above. |
Beta Was this translation helpful? Give feedback.
-
|
Sidestepping the question of feasibility, I do think that, as you also mentioned, the "philosophical" resolution here is highly intertwined with that in filecoin-project/FIPs#515, even if the urban planning issue is rather specific to IPC (kudos on that metaphor). With regards to sprawl, there is an implicit moderation mechanism, in the form of organically high checkpointing fees (assuming bloc saturation) and/or more onerous cross-subnet transactions. Whether that is enough or requires more explicit management is less clear to me: one could argue that it wasn't sufficient in the case of cities but the story is a little more complicated, with poor zoning practices (particularly in the wake of WW2) actively contributing to said sprawl. Let's assume, arguendo, that we don't and can't know what will work in practice. From an experimental perspective, is it preferable to start with Marko's laissez-faire approach and introduce management mechanisms if needed or to start with a controlled approach and relax it if possible? Is there a higher risk/downside in one of the cases? |
Beta Was this translation helpful? Give feedback.
-
The real question I get at here is that in the laissez fair world, organically high checkpoint fees are the same as the organically high fees for any other type of transaction, including storage related messages. If these organic base fees get too high, they will be too high for data storage, and sectors may fault, onboarding may slow, thing that would be "bad for Filecoin" (if we decide that is what we consider bad for Filecoin, that's indeed the question) In the laissez fair world, it can be economically sensible to bulldoze revenue sinks like schools and museums, in favor of highways, parking lots and chain restaurants for wealthy suburbanites to commute to their office. This is all fair and good in the free market, because a Cheesecake Factory will collect more revenue than a school, so we should always welcome it, and push schools off to less desireable pieces of land. We can decide say that data storage related messages are important to keep Filecoin running (and that generally Filecoin SP utility is important), the same way that schools and hospitals are important to keep things running, but will not always be the ones able to pay the highest rent. Once we decide what actually is important to the Filecoin network, we could literally just give more Downtown land to schools and hospitals, so their rent is cheaper, and restrict the land available to Cheesecake Factories, so they would have higher rents. The precise split of land would be done in a way that maximizes whatever the system's goals are. I completely agree that Urban Sprawl case is also a warning that some incentive mechanisms could also be used for evil, if they are used to maximize for the wrong thing. In the North American city case, incentives are used to maximize vehicle traffic flow, ease of moving in a car, and historically less savory things like optimizing for your neighbors being in the same socioeconomic class and race as you. If anything it is also a demonstration that incentive can work for maximizing the thing you want to maximize, so this should be chosen wisely. I also believe a lot of fear of overregulation stems from the fact that humans are corruptible and regulations are carried out by corruptible humans. The fact that we could aim to do something much more transparent, like define and broadcast: this is the target function we want to maximize for" and everyone knows that, and then set an automated mechanism that maximizes for that, in my opinion eliminates a good chunk of the evils of overregulation. |
Beta Was this translation helpful? Give feedback.
-
|
Just to be clear, Marko and I disagree on a lot of topics; I'm a big fan of regulation -- in life, not just in blockchains. I accept your premise that rising costs will impact everyone, including those who have no recourse (SPs sending storage-related messages). What is less clear to me is why those that do have alternatives would choose to operate subnets in a way that required unnecessary rootnet interaction (e.g. by spreading across multiple subnets anchored to the root); in other words, whether their preference for sprawl overcomes their aversion to higher fees*. The intuition there is not at all obvious. |
Beta Was this translation helpful? Give feedback.
-
Copying from #58 for visibility, as the two discussions are connected.
I think this is now a set of conversations spread over two issues and a Slack channel, but all is quite connected. Indeed I think this is the case that the final formulation of IPC as one of many other existing L2 solutions won't necessarily solve the congestion problem, the same as it hasn't been solved in Ethereum. In fact it starts to become less clear what the point and/or innovation of IPC really is. We would always have been able to deploy some L2 subnet with FVM. Then anyone else would be able to deploy an L2 subnet under that L2 subnet. So anyone could have built a similar hierarchy at any time before, so it is unclear what is being introduced. Key distinctions used to be that it had some specific mechanisms for cross net transactions, and that subnet incentives were to be aligned through collateral/pledges, giving users of the subnet some level of guarantee or assurance by the parent net. If in the latest formulation there is nothin particularly special about cross net messages, and pledges and collaterals will be on a completely voluntary and laissez fair basis by the subnets, then it is unclear to me what exactly IPC is contributing, seems like nothing in particular that couldn't have been done by stitching existing L2 solutions together into a hierarchy. From the original inception, I understood IPC as Filecoin's answer to Ethereum's sharding proposals. In that case, Ethereum would become N number of blockchains next to each other, which literally would increase the capacity of L1 Ethereum itself. If we were to do sharding then I would bring back my questions surrounding Gas Sprawl, in the form of "What's the optimal number, N of shards that we should have to maximize wellbeing of Filecoin?". I understood IPC as our take on this idea, where instead of placing all N subnets just side by side, there would be some utility in arranging them as a hierarchy, but still would have been an approach meant to literally increase the capacity of Filecoin, as sharding would do for Ethereum, and L2's don't really. Maybe we should go back to sharding? thats one thought maybe worthy of discussion? Sharding indeed is something that cannot be done simple at an L2 level, and would require contended EIPs and difficult governance, which contributes to taking so long to deploy that idea. |
Beta Was this translation helpful? Give feedback.
-
You would, but then you might end up with centralised sequencers like Ethereum. Even if non-exclusive, there is merit to "good" designs (where the definition of good is obviously goal-dependent).
I don't think this is the right approach, but that's my own opinion. We should aim for better UX for subnets than "DYOR".
Sharding comes with a different set of security considerations and does not provide the consensus-level flexibility we seek -- even if it does make for a "simpler" economic question. I don't think there is much appetite for that direction 🤷 |
Beta Was this translation helpful? Give feedback.
-
Notes from Zoom meeting discussion about whether IPC should have special status as a built-in actor, or not (in other words remain fully an L2 solution with zero associated FIPs):Attendees: @anorth , @AxCortesCubero , @dmc314 , @guy-goren , @jsoares , @juanpmcianci Reasons for IPC to have “special” status as built in actor
Reasons for IPC to NOT be “special” - that is, fully an L2 solution in userland, that will involve zero FIP’s:
All from the mtg, please feel free to weigh in if I've mis-typed or omitted anything from our conversation. |
Beta Was this translation helpful? Give feedback.
-
Summary
Different stakeholders in the Filecoin network have been contemplating the potential effects on the gas and message economy that may occur from major upcoming upgrades to the Filecoin network, namely FVM (Filecoin Virtual Machine) –which could cause message demand surges, and IPC (InterPlanetary Consensus), –which could cause block space supply surges. In this discussion, we will focus on the latter, while a similar discussion focusing on the former can be found here: #58.
The execution capacity or total effective block space of the Filecoin network is expected to increase with the introduction of the IPC horizontal-scaling solution: one that involves an arbitrary number of independent blockchain subnets that achieve security and integration with the rootnet by recording periodic checkpoints on it., When this happens, it is possible that the message traffic is so sparse that network demand, base fees, and protocol revenue are negatively impacted. A similar effect was observed in 2021 with the introduction of Hyperdrive, which increased the capacity of the network to process sector proofs, and as a result of too much supply being released, total network revenue was decreased.
Even if the goal of the network is not to maximize total network revenue, a better target that maximizes utility to all Filecoin participants needs to be defined. This target could include network-beneficial aspects such as total network quality adjusted power, total data deal revenues, and total network revenue amongst others. Once a target is defined for what Filecoin wants to maximize for, it would be easy to understand if a sudden supply surge (such as IPC or Hyperdrive) affected the network negatively.
Gas Sprawl is the nickname we’ve been using for this phenomenon, which evokes imagery of when unlimited space meets bad urban planning, and cities trade thriving, mixed-use, central hubs and markets for overgrown highway systems and monolithic neighborhoods.
Historically, particularly in North American cities in the 20th century, cities were developed with a nearly unlimited supply of land and wealth, leading to spread out single family housing, and long distances to commute. It can be argued that developing with unlimited land and wealth supply could lead to a decrease in the quality of life of residents, who lost walkability, some sense of community, and other health benefits of an urban environment. Furthermore the remaining “Downtown” area of such sprawling cities tends to be negatively affected by the surrounding sprawl as well. Lively and viable neighborhoods have to be bulldozed to accommodate for urban freeways and parking lots, decreasing the quality of life in the urban center as well.
The general thesis here is that these cities would have looked a lot different if the supply of land instead had been released more measuredly, in a way that maximizes the quality of life of the residents.
In this urban analogy, in the context of IPC, Filecoin, which would act as the rootnet in the IPC hierarchy, would be the Downtown urban core of IPC city. IPC subnets (suburbs) offer an endless supply of block space (land) that may be used inefficiently in an unnecessary sprawling manner. This unregulated block space sprawl may end up negatively impacting the best interests of the Filecoin downtown, depending on our definition of what a high-quality network is (in other words, our previously mentioned target for what Filecoin needs to optimize.)
Furthermore, as Downtowns need to allocate some of its valuable and scarce land to accommodate urban freeways and parking lots, the Filecoin downtown will need to allocate some of its valuable and scarce block space for IPC checkpointing and subnet needs. If the rootnet turns into a sea of parking lots for IPC checkpointing, might this result in unacceptably high congestion and base fees for non IPC rootnet messages?
Note also that there are risks of gas sprawl even at the scale of the rootnet itself, without including IPC. This issue has been brought up in FIP discussion 515, which would introduce an adjustable target block size, which effectively regulates how much of the available block space is released, in a way that optimizes the network’s target.
The approach as we view it to defend against negative effects of gas sprawl consists of two steps:
We welcome any related thoughts, ideas, or questions here. Thank you!
Work Plan
There has already taken place a significant amount of modeling, simulation and communication between CryptoEcon Lab and Consensus Lab on IPC and the gas sprawl phenomenon. A related FIP discussion has already been released regarding the adjustable target block size for EIP 1559. One aim of this discussion is to generate from community discussion a given target that we as a network think Filecoin should maximize for.
Explored Solutions
We have already started communication on the sprawl subject, in terms of the Adjustable Target Block size FIP discussion. We proposed a new dynamic mechanism to adjust the target block size parameter in EIP 1559 in a way that aims to maximize a predetermined target function.
A similar mechanism is easily adaptable to the context of IPC subnets. While IPC introduces virtually unlimited capacity, the Filecoin blockchain, which would act as the rootnet for IPC will remain limited by its own block space.
The Filecoin rootnet will economically interact with IPC subnets in two important ways. One of them is through setting minimum collateral requirements to operate a subnet which uses Filecoin as its parent net. The second interaction is through gas usage. Subnets use some of the available block space of the Filecoin rootnet for checkpointing messages.
We plan to propose a dynamic mechanism for IPC allocation of block space in the Filecoin rootnet. In its simplest form this approach consists of adjustable gas lanes. IPC checkpointing messages from Filecoin subnets, vs regular rootnet messages will be allocated their own fractions of Filecoin block space. The way in which the fraction of block size is allocated to IPC checkpointing vs regular rootnet messages can be settled dynamically, similar to the adjustable target block size mechanism, with an updating function that tries to maximize a predetermined target function.
There is ongoing research and discussions on the subject of minimal subnet collateral, which is beyond the scope of this document, but will be communicated separately.
Timeline:
Week 1 (12 December-16 December).
Week 1 (19 December-23 December)
Week 3 (9 January-13 January) (minding Holiday break)
Relevant links
https://github.com/protocol/CryptoEconLab/tree/blockSim/notebooks/blockSim
https://hackmd.io/BrlCWpykSTyQyQ3HNDFqUA
Beta Was this translation helpful? Give feedback.
All reactions