Replies: 3 comments 5 replies
-
This sounds m great! How would the new smart contract interact with current market actor, will we be transferring the market states to new smart contracts, or only allow new smart contracts read the existing state? If it’s the later, how would the newly developed feature via smart contracts being applied or available to the existing storage market and clients ? |
Beta Was this translation helpful? Give feedback.
-
Here's my current understanding of the changes required:
|
Beta Was this translation helpful? Give feedback.
-
The eagle-eyes may have noticed a divergence from the arguments presented here for restricting sector data. What's changed is that the FVM will mean that alternative marketplaces can be built on Filecoin. The barrier to innovation of preventing the development of alternative on-chain markets is much higher than the barrier of not being able to rely on zero CC data. |
Beta Was this translation helpful? Give feedback.
-
Over the first year or so since Filecoin network liftoff, greater-than-expected storage provider onboarding forced us to focus a lot on network scaling and other issues associated with being a young network. Now that we seem to have that under control (and with proposals in our pocket in case growth explodes again) I expect we will spend a lot more focus on the functionality of Filecoin as a storage marketplace. But not only from a core consensus protocol point of view! The Filecoin VM promises to unlock the creative potential of thousands of developers to build applications on and in Filecoin. Thus, I hope and expect that a large majority of the development of storage market features and functionality to come from non-builtin smart contracts developed by teams outside the Filecoin protocol core. I'm posting this to provide context for the changes I'll be proposing and developing in the near future.
Features like deal extension, multi-sector deals, re-negotiation, deal transfer, capacity deals, auction markets, repair markets, insurance, derivatives etc should all be possible in smart contracts. None should require a network-wide upgrade to realise. I hope for a variety of marketplace mechanics, bound by some shared standards and interfaces, just as there are variety in token exchanges and marketplaces on other blockchains.
However, even if we had the FVM today, much of the above would be impossible to build. This is because the structure of the built-in storage miner and storage markets does not provide the information and hooks that would be needed by these applications, and privileges the built-in market actor as the one which miner actors consult. In order to enable the development of actually-useful storage-related applications and features, we need to break the tight coupling between these built-in actors, expose composable on-chain primitives, and make the capabilities of the built-in market actor available to user-programmable contracts.
Breaking this coupling will also have other benefits. It will significantly speed up future development of both the storage power accounting and future deal markets, support much more scalable data representations, remove the storage market from consensus-critical risk surface, and move subsequent market development into the realm of smart-contract upgrades, rather than network-wide consensus protocol upgrades. This direction is thus motivated by speed, scale, flexibility and programmability.
I expect this direction to be the main focus of my work over the coming months. There are a number of significant changes needed to establish this open playing field. My goal is that, by the time the FVM enables user-programmable contracts, the stage is set for an explosion in application and feature innovation to match the stupendous uptake of storage-powered consensus by providers in the network's first year.
Beta Was this translation helpful? Give feedback.
All reactions