Replies: 4 comments 9 replies
-
|
Relevant links
|
Beta Was this translation helpful? Give feedback.
-
While it does not entirely preclude this issue, and definitely won't be available in time for the FVM launch, we hope that Interplanetary Consensus will, when deployed, enable applications to operate in (or spawn new) high-throughput subnets, not only increasing overall capacity but reducing application demand on the rootnet. Ultimately, this could result in the root being primarily used for proofs and checkpoints and cross-subnet transactions. It doesn't stop gentrification but it provides builders and users with alternatives that are not just viable but better due to more suitable consensus mechanisms. Of course, that too depends on compatible incentives -- something our teams have been collaborating on. But, again, this isn't a solution/mitigation for launch spikes. We do hope it will be a solution to the long-term sustained increase in demand stemming from FVM's success. |
Beta Was this translation helpful? Give feedback.
-
|
Question for the thread: if gas-lanes are a way to give some priority access to storage & proof messages - similar to a carpool lane on the highway - this would involve extra tracking and separate calculations for each lane. Might a more code-efficient alternative be simply to have a multiplier or coefficient that we apply to certain types of priority messages when we calculate their gas? (This is similar to how we've addressed different kinds of sectors in the block reward world..by giving FIL+ deals a 10X quality multiplier for 10X the block rewards) For example, the "quality adjusted" gas calculation for SubmitWindowPost might have a multiplier of 0.5 and therefore cost half as much as an equivalent FVM message. In this way, the code base and calculations only change by adding a single variable... but I'm not sure if this creates other problems downstream though. |
Beta Was this translation helpful? Give feedback.
-
|
@jsoares I am doubtful that IPC will provide much of a solution to this particular problem, and may even make it worse in the long run. The summary is that I don't see why IPC would solve this for Filecoin any more than L2s have solved this for Ethereum. Yes, it absolutely will open up new capacity (🎉 ) but I don't see it reducing demand on L1. The more activity surrounds Filecoin as an ecosystem, the more valuable L1 blockspace will become. Side-chains/rollups/L2s etc are in fact likely to become the highest gentry of the L1: because their checkpoint-type transactions summarise a huge amount of subchain activity, they will be highly valuable and those networks willing to pay a high gas price. And if L1 is needed to mediate cross-chain messages, that's yet another high-value demand (here I hope that technological progress will produce bridges that don't rely on the hierarchy). |
Beta Was this translation helpful? Give feedback.
-
|
@anorth I think we are on very similar pages on IPC. We have a discussion on IPC analogous to this one, which we will post soon. |
Beta Was this translation helpful? Give feedback.
-
|
This goes back to the discussion of how IPC compares to rollups, but there are several arguments for why applications should not particularly care for running in L1: no centralised sequencers, transparent interoperability, full customisation of the subnet consensus (if they choose to instantiate their own...). Yes, there is a security tradeoff but it's just that: ultimately, you could conceivably have a single first-layer subnet with "better" consensus and a sufficiently decentralised validator pool and ignore the root even for cross-net transactions. I don't think this will happen, mind you, but nothing prevents it technically. That said, it's true that IPC too will demand L1 space, particularly depending on how many subnets decide to anchor directly (which is one of the objects of our discussions). Unless the checkpoints + proofs usage alone exceeds block space, I still don't see a strong argument for why users/applications would want to pay high* fees and be subject to high latencies to transact on L1 rather than deploy in an appropriate subnet [except if none exists...]. As it stands, the main reason is "it's the only option".
|
Beta Was this translation helpful? Give feedback.
-
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.
-
|
Some preliminary FVM usage stats on test nets from @maciejwitowski : https://docs.google.com/document/d/1yZzqa76SmMcOgs3VAz34E9ZR0WIOX07ET28MKMFRRRI/edit |
Beta Was this translation helpful? Give feedback.
-
|
Also noted on slack convo: |
Beta Was this translation helpful? Give feedback.
-
|
Apologies for being pendantic, but want to make sure we are aligned on problem definition to ensure that CEL is generating the most valuable insights at this stage.
I'd like to review the usage of the term "surges" in the problem statement, to make sure we are aligned. To me, the term "surge" denotes a discrete strong upwards movement event. It's unclear if this refers to a surge just at deployment, continuous indefinite usage surges (i.e. bursts), or if it refers to a sustained surge after deployment. I would broaden this problem definition to study the general impact in chain usage patterns across a number of scenarios and outlooks (and please generate models for different possiblities! 🙏). I would not limit it to surge events of any kind (but would include those in the scope).
Not just message traffic, but gas usage patterns. One can have higher message traffic without large consequences on gas usage (e.g. lots of transfers), so this focus is insufficient by itself.
I think "mission-critical" messages is an underspecified definition. One could consider power maintenance messages mission critical (submit WindowPoSt), but also power-mutating messages given the right circumstances (e.g. power recovery messages after a catastrophic event, or a network upgrade). I generally use these categories:
Read more here: filecoin-project/FIPs#47 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Hi Raulk, thanks for pointing that out! You're right, the way it is currently written can be understood in several ways. I agree with the definition of the problem you suggested, and that's what we are currently working towards |
Beta Was this translation helpful? Give feedback.
-
|
Two **important messages ** we are missing that are network security related:
i can see the point on PSD - however, i think we should factor data onboarding/real data storage/QAP in when evaluating the prior of this message. |
Beta Was this translation helpful? Give feedback.
-
Discussion thread about FVM+gas dynamics and Gas Gentrification that references the work plan in this issue:
Copying Summary Here:
FVM and gas gentrification: summary, work plan and timeline
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 document, we will focus on the former, and a similar writeup focusing on the latter will be published shortly. A more thorough description of the problem at hand can be found here.
If new FVM users and apps add enough incremental message traffic (demand), there is a possibility that the price-setting mechanism for block space would cause gas fees or user bids to rise to a point where mission-critical messages (i.e., those deemed necessary for the proper functioning of the network, such as SubmitWindowPost) may get priced out. This outpricing would, in turn, affect any related economic decision-making by network participants and may potentially hurt the network.
Block space Gentrification is the cheeky nickname we've been using for this phenomenon, as chic new messages move into the block and (potentially) drive up rent prices (base fees) for everyone.
While it is also possible that this does not become an issue, we are actively looking into modeling and simulating different scenarios resulting from this increase in demand so that we can better understand and quantify them. We are also brainstorming possible solutions, safety valves, and offramps.
We welcome any related thoughts, ideas, or questions here. Thank you!
Disclaimer: no one can perfectly predict the future. All our simulations depend upon multiple assumptions that authors and stakeholders deemed reasonable. While we are confident in our reasoning and simulation capabilities, the predicted results may not reflect reality due to the system's immense complexity and the large amount of non-linear interactions that drive it. These studies should be repeated and their conclusions/actions adjusted as new data becomes available.
Beta Was this translation helpful? Give feedback.
All reactions