FIP-0032: Gas model adjustment for non-programmable FVM #315
Conversation
raulk
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle and
anorth
as code owners
|
🎉 💯 ❤️ @raulk, do you intend for the second FIP (FIPnnnn) to be published and implemented with FIPs 30-32, or is is it intended to support the forthcoming M2 work? In other words, are we awaiting a fourth FIP for acceptance prior to the v16 calibnet sync? |
|
@kaitlin-beegle an early draft of the second FIP is coming later today! But that FIP will stay open for longer and is entirely independent from the nv16 timeline. Also, its parameters are dependent on benchmarking code that hasn't been written yet. Fun fact: I had drafted both FIPs as one, but later realised that we had too many undefined items in the M2-related items that would hinder the approval of the M1-related items (nv16). So I decided to split that FIP up into these two. This structure aligns much more nicely with how we're scheduling FVM work. |
raulk
requested review from
jbenet,
magik6k,
nicola,
Stebalien,
ZenGround0 and
zixuanzh
Appreciate the quick reply, and fast work! It was a great call to separate these two documents so that we can move more quickly on the most time-sensitive part. We'll call for reviews at this week's Core Devs, so we can see how many outstanding questions, etc., exist after an initial review. Assuming feedback is mostly minimal, I'm hoping we can schedule FIPs 30 - 32 for Last Call beginning on March 21. However, we have some flexibility, should anyone need a longer review time. @raulk do you plan to attend this week's Core Devs and talk through the specifics of some of the gas modeling? Not a requirement, but want to make sure you have enough time if you do intend to join. |
|
@kaitlin-beegle update: expect the draft for FIP-nnnn tomorrow; it's almost ready but would like to proof-read with fresh eyes tomorrow morning. |
|
|
||
| Concerning the design of each individual change, the specification section | ||
| elaborates on overhead that is being accounted for and the variables that make | ||
| up every pricing formula. |
There was a problem hiding this comment.
Is your plan that the pricing formulae be constructed so that the existing syscall charges remain fixed, and the other items have proportional values so as to maintain constant relative cost per call? Otherwise, it may be necessary to reprice all the existing syscalls.
There was a problem hiding this comment.
This FIP plans to keep the current syscall prices unchanged for simplicity. As stated in the Change Motivation section, execution gas is additive to the current syscall prices because the current system does not charge for the cost of actor logic because it doesn't have a way to do so. In a future FIP (likely #317), we can adjust the syscall price parameters. But the overarching goal is always execution cost fidelity (i.e. what each syscall actually costs), not the maintenance of legacy prices.
FIPS/fip-0032.md
Outdated
|
|
||
| ## Product Considerations | ||
|
|
||
| No product considerations apply. |
There was a problem hiding this comment.
The relative costs of various actor methods are going to change, which is product-relevant whenever the base fee is non-trivial. Once you have the data, we should spell those out here.
There was a problem hiding this comment.
Actually, I'm not sure I follow your comment about the base fee being non-trivial. There is nothing changing here about how the base fee itself is calculated, which basically depends on total gas used in tipsets AFAIR.
There was a problem hiding this comment.
There are two bits here:
- People will only care about relative gas changes when the base fee is not ~zero, because otherwise everything costs $0.
- This proposal will increase total gas usage, which runs a good chance of increasing base fee if we don't also increase the block gas limit (but we probably want to do the opposite to give ourselves buffer in validation times if we don't get the gas costs right first go)
There was a problem hiding this comment.
Agreed with Anoth here, this has a possibility of significantly affecting the ratios of GasUsed of different operations.
We also have the gas balancer in place for the aggregated prove commits, if gas changes significantly it will need to be changed as well.
There was a problem hiding this comment.
Generally agreed but the principle for calculating GasUsed is based on the resources consumed by the messages/operations. As long as we are applying the same principle it should probably be fine. I think the product consideration can be on a different layer. Product teams should work on building experiences that people will be willing to pay for.
Thanks for the invitation. Yes, I will join and present this FIP in the call. |
|
Merging FIP draft, per @anorth's comment above. Current FIP draft will be circulated in this week's community governance update. |
This FIP is the first in a two-FIP series that adjust the gas model to prepare it for the FVM.
FIP-0032(this FIP): Gas model adjustment for non-programmable FVM. Introduces execution gas, rearchitects IPLD state management fees, adjusts the actor call fee.FIP-nnnn(upcoming FIP): Gas model adjustment for user-programmability. Introduces the actor installation fee, introduces the actor loading fee, introduces memory expansion gas, prices unpriced syscalls, and more.