Comments (16)
Economies of scale are real. We can't pretend they don't exist just because that's "unfair" to parties that don't have the scale to enjoy them. This is a very minor one in the big picture of Filecoin mining. Economies of scale is the very premise behind Filecoin's vision of abundant cheap storage. We should lean into them and get as much as possible!
As @nicola says, this will make no difference to the high growth rate of the network. High-growth miners are much more likely to be limited by cost of sealing hardware than the gas cost of pre-commits, so reducing that gas cost won't change anything except making the whole network's consensus more efficient and freeing up bandwidth for other messages.
from fips.
The FIP draft for this has landed (#27), but the team is generally agreed that we should postpone implementation until after first addressing Window PoSt affordability.
from fips.
@stuberman this is an implementation concern so your question will be best addressed by filing an issue with the implementation you are using (sounds like https://github.com/filecoin-project/lotus is the right place)
from fips.
It is not clear to me whether the pre commit batch affects sealing. While precommit commit messages are waiting for release (expiration of "PreCommitBatchWait") are those sectors held from further processing/sealing? As an example is PreCommitBatchWait = 8 hours will PC2 sectors queue up on sealing disks until the timer expires? If so, miners will need to be advised to set the wait timer low enough to not run out of disk capacity and cause worker to idle waiting for timer to expire.
Also can be a great question for next weeks deep dive AMA!
from fips.
ProveCommitSector
could also be batched, but that's a separate discussion. There is already a complex set-up around batching the proof verifications until the end of each epoch, and that discussion should start there.
from fips.
I approve the spirit of this change.
One thing to note is that in the future (may not belong to this FIP), a PreCommitBatched could contain PreCommits from other miners and the batched method would be verifying the signature on those PreCommits (similarly to what we do for deals).
In this way, smaller miners could get together to jointly submit PreCommits.
from fips.
I mentioned during all dev that batched precommits may give miners with high sealing throughput an advantage over miners who are smaller in scale. It is unclear if the cost saving is worth the tradeoff. On second thought, the number of sectors that we are batching is probably small enough that it wouldn't make much of a difference. Can we quantify the difference? Of course allowing different miners' PreCommits to batch will be great but that's also extra work and hurdle that presents challenges to smaller miners.
from fips.
This FIP ensures that a miner can organize their PreCommits so that they can amortize their gas costs. The gas saving is pretty substantial. For example if you submit 32 sectors instead of 1, you may end up paying ~32x less gas (likely less than that).
This is a good concern, but since this is a "one-off" cost, I dont think this will have major impact in the total cost of mining of a small miner vs larger miner.
Extending this FIP in the future to support PreCommit from multiple miners will only benefit the miners.
from fips.
It's a "one-off" cost that can be incurred repeatedly and the cost savings can add up, e.g. a miner who can submit 32 sectors at a time has a cost advantage over miners who can't. This is a structural force that can advantage larger miners more than smaller ones. However, I can be convinced if most miners can comfortably submit 32 sectors at a time.
from fips.
Let me put it differently, the goal here is to reduce gas spent and not cost.
- We can make the batched operation to cost the same amount of $, but to consume less gas
- We can show that this fee does benefit large miners, but really little. For example, if this is a 1% cost reduction is that too much to favor large miners?
from fips.
Thinking about this more, I think introducing this FIP at this moment will do more harm to the network than the potential cost savings it brings. The network is onboarding more than 15 PiB per day but most of that storage is not useful and it takes time to build applications on the network. In addition, FIP5 is already making PreCommit cheaper so committing storage is not too expensive or too slow per se. We can revisit this FIP in a few months once demand for storage on Filecoin has picked up (Filecoin Plus is operating successfully) and more applications are built on Filecoin. If teams want to push for this FIP, we should push harder on the other fronts first. We should however make it cheaper to do SubmitWindowPoSt and PublishStorageDeals.
from fips.
The fact that the network is on-boarding 15PiB per day (of which most of it is not useful) won't change with this fix; this FIPs makes sure that even if the network onboards 15PiB, ~1/3 (IIRC) of the block is freer than currently. If we don't do this, fees could increase for everyone.
What would be the list of questions that we should answer to gain confidence on this?
As I said before, having a node that aggregates PreCommit from multiple miners could also be done - although more complex.
from fips.
We should land this at the same time or after we land ProveCommitBatched. The reason is that the decreased cost in PreCommitBatched could lead miners to think that they could submit many times more PreCommits, and this will lead to a more congested chain.
from fips.
We finally have a more affordable WindowPoSt.
PreCommit is currently 23% of the gas used. This FIP would be great in combination with FIP0013!
from fips.
It is not clear to me whether the pre commit batch affects sealing. While precommit commit messages are waiting for release (expiration of "PreCommitBatchWait") are those sectors held from further processing/sealing? As an example is PreCommitBatchWait = 8 hours will PC2 sectors queue up on sealing disks until the timer expires? If so, miners will need to be advised to set the wait timer low enough to not run out of disk capacity and cause worker to idle waiting for timer to expire.
from fips.
Tagged inactive due to the passage of FIP0008.
from fips.
Related Issues (20)
- # TLDR HOT 2
- Weekly Governance Update (8 April 2022)
- Using a dedicated address for the sector-fault penalty HOT 1
- Optimize parallel PreCommit1 tasks speed HOT 1
- Cancellation of deposit HOT 1
- Cancellation of filecoin pledge HOT 1
- Create FIP draft for Decouple FIL+ HOT 6
- Some words to fil HOT 2
- FIP0029 terminology doesnt match the implementation HOT 1
- FIP-0029 missing definition of nominee
- FIP-0044: Verifreg: Consider modifying RemoveDataCapProposal HOT 4
- Update address for Filecoin Plus Registry HOT 1
- Allow account-level operators to set approval for tokens HOT 1
- broken links HOT 2
- FIP 104: Implement scaling payments for storage deals
- Where is the definition of 'FRC'? HOT 1
- Should we consider tagging segment and aggregate pieces differently ? HOT 1
- FIP001v2 Process Updates
- TESTS TSLT
- FIP 0075 contains an invalid `created` date in the frontmatter HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fips.