FIP-0032 final draft #3
Conversation
raulk
commented
May 3, 2022
raulk
commented
- adds syscall gas
- adds extern gas
- adds gas parameters
- removes revision of fees for extern-traversing syscalls
- adds incentive considerations
- adds product considerations
- editorial pass (rewrite most of the FIP)
| syscall gas. | ||
|
|
||
| ``` | ||
| p_extern_gas := 21000 |
There was a problem hiding this comment.
I wasn't able to measure it (we don't have tracepoints in ffi). 1.5x syscall gas may be on the lower side.
|
|
||
| ``` | ||
| p_blockopen_base_gas := 114617 # extant fee | ||
| op_ipld_blockopen := p_syscall_gas + p_extern_gas + p_blockopen_base_gas + (p_memcpy_gas_per_byte * block_length) |
There was a problem hiding this comment.
NOTE: the current nv16 implementation charges a per-byte cost of 2 gas/block.
| ### Under/overflow handling | ||
|
|
||
| Operations that have the potential of either underflowing or overflowing should be performed | ||
| using [saturation arithmetic](https://en.wikipedia.org/wiki/Saturation_arithmetic). The valid | ||
| range for any fuel operation, including total fuel consumed, is [0, 2<sup>64</sup>-1]. | ||
| range for any execution units operation, including total execution units consumed, is [0, 2<sup>64</sup>-1]. | ||
|
|
||
| The valid range for any gas operation, including gas available and total gas used, is | ||
| [0, 2<sup>63</sup>-1]. Gas operations only go up to 2^63-1 because they are performed using | ||
| signed arithmetic. This is because the Filecoin protocol has some gas costs that are negative as | ||
| of nv15. | ||
| The valid range for any gas operation, including gas available and total gas | ||
| used, is [0, 2<sup>63</sup>-1]. Gas operations only go up to 2^63-1 because they | ||
| are performed using signed arithmetic. This is because the Filecoin protocol has | ||
| some gas costs that are negative as of nv15. | ||
|
|
There was a problem hiding this comment.
This section isn't entirely accurate:
- At the upper end, we now saturate to
(2^63-1)/1000, because we track milligas. But this is just an implementation detail. If we end up saturating here, we'll just end up running out of gas. - At the lower end, we can go negative. But we'll floor at zero when we finish executing.
| The conversion of Wasm execution units to Filecoin gas units is at a fixed ratio | ||
| of 4gas per execution unit. |
There was a problem hiding this comment.
Is this the same gas accounting formula that we use in existing accounting? maybe we can ask Kuba to confirm. EDIT: I see a comment below that this is equivalent to 10 gasUnit/ns of wall clock time?
There was a problem hiding this comment.
Kuba worked closely with me on this. We are using the same inherited baseline to translate wall clock time into gas, indeed.
| instruction pipeline), and other factors. In the future, we may tabulate syscall | ||
| gas depending on the complexity of the syscall, its arguments, its impact on CPU | ||
| optimizations, and more. |
There was a problem hiding this comment.
Ideally metering is just a benchmark that we run and it is constrained by block propagation, chain validation, and other objective limits of the system
There was a problem hiding this comment.
Global system limits don't really apply at this level. Gas accounts for message validation costs. But I think what you're getting to is that the baselines need to be framed within system constraints. They already are. In the previous draft, I had a section explaining the baseline:
[^1]: The baseline target itself determined by the need to sustain a 30 second
epoch frequency, with a 6 second block propagation time, under these
circumstances, which represent the absolute worst possible scenario:
- Block gas limit of 15B gas units.
- Attaining the maximum winrate at an epoch (11).
- No duplicated messages across blocks in a tipset.
- 100% saturation of every block with compute.
The choice of 10 gas units/ns as a baseline implies a block validation time
of 1.5s and a fully saturated tipset validation time of 16.5s (given that
message and block execution cannot be parallelized).
It wasn't entirely accurate, but I can correct it and re-add it if you think it adds value?
| p_memcpy_gas_per_byte := 0.5 | ||
| ``` | ||
|
|
||
| **Pricing for `ipld::block_open`** |
There was a problem hiding this comment.
Suggest changing Pricing to Metering and the unit here is just "GasUnit"
There was a problem hiding this comment.
We use the term "gas pricing" in code and docs to refer to gas fee calculation. I don't think it's time to deviate from that. The term metering isn't appropriate because it refers to instrumentation and not to economic aspects. We already use metering in the context of execution metering (where the unit is execution units).
There was a problem hiding this comment.
What is meant by execution metering and how is it different from the pricing detailed here?
| as much as 14x. | ||
| - PreCommitSector (miner actor): gas usage increases an average of 3x, with a | ||
| median of 2.37x, and a 90% percentile score of 5x. Some executions spiked as | ||
| much as 9x. |
There was a problem hiding this comment.
Why will some execution spikes 9x? Is it because the miner already has many actors?
There was a problem hiding this comment.
It's hard to tell. Message execution depends on the input data and the state at that point. The best guess is that these messages went down a computationally costly code path.
| clients should size batches within gas limits. | ||
|
|
||
| On average, we observe a global increase of 1.87x in gas utilization, if the | ||
| current chain activity were to remain unchanged. However, the HyperDrive upgrade |
There was a problem hiding this comment.
Making sure we are on the same page, this is saying total GasUsage for all mainnet transactions in the data dump will go up by 1.87x.
There was a problem hiding this comment.
Yes, the backtest indicates gas usage going up by 1.87x on average in the sample data.
There was a problem hiding this comment.
Just a question here on timing/rolling out the FIP. If the backtest indicates on average, gas usage increasing by 1.87x do we want to roll these changes out so far ahead of the eventual FVM upgrade?
The reason I ask this, is, the current market environment for miners is on balance more unfavorable from a miner ROI perspective than previous and potentially future environments. If we introduce a change within this current regime in which miner gas usage increases about 90% on average, miners shoulder this cost in this environment without the added utility of FVM. Is there clear utility to introducing this change then about 4-5 months ahead of the eventual FVM upgrade?
There was a problem hiding this comment.
@vkalghatgi We do want to roll this technological change prior to enabling user programmability; this is part of the change management strategy. Rolling out a massive update where we basically change the operating system of the network AND we enable user programmability at the same time is tremedously risky.
On another note, user programmability will just deterioriate the situation further: messages for user actors will add to miner messages, leading to even more demand pressure in the gas market, driving the base fee up.
There was a problem hiding this comment.
Curious, given the additional chain bandwidth in snarkpack aggregates that isn't currently being used, do we actually expect that "miner gas usage increases about 90% on average"? AFAIK, the batch balancer will kick in, and the increase will be much less in practice, right?
There was a problem hiding this comment.
Curious, given the additional chain bandwidth in snarkpack aggregates that isn't currently being used, do we actually expect that "miner gas usage increases about 90% on average"?
I think the 90% increase on average is given that the exact same set of messages are sent to the chain in the same exact epoch.
AFAIK, the batch balancer will kick in, and the increase will be much less in practice, right?
Yes, there could be many other variables but in general we expect the total gas usage to be about the same as what it is now and BaseFee will hover around the network cross over.
|
Note that the final utilization numbers after updating the backtest are a little bit higher: filecoin-project#368. @vkalghatgi |
|
Sg - then I think this is of minimal concern (yay batch-balancer!)
…On Sat, May 7, 2022 at 9:18 AM ZX ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In FIPS/fip-0032.md
<#3 (comment)>:
> + with a median of 1.75x, and a 90% percentile score of 1.92x. Some executions
+ spiked as much as 2x.
+
+These two message types deserve special attention.
+
+- DeclareFaultsRecovered (miner actor): highest variability between executions
+ and highest multiplier; on average, gas cost increases 8x, with some instances
+ spiking as much as 30x in the backtest. All executions were within the block
+ gas limit.
+- ExtendSectorExpiration (miner actor): infrequent; was already an expensive
+ message. Some executions lead to gas usage beyoned the block limit, rendering
+ them inviable (up to 2.2e10 gas). However, this is a batched message, so
+ clients should size batches within gas limits.
+
+On average, we observe a global increase of 1.87x in gas utilization, if the
+current chain activity were to remain unchanged. However, the HyperDrive upgrade
Curious, given the additional chain bandwidth in snarkpack aggregates that
isn't currently being used, do we actually expect that "miner gas usage
increases about 90% on average"?
I think the 90% increase on average is given that the exact same set of
messages are sent to the chain in the same exact epoch.
AFAIK, the batch balancer will kick in, and the increase will be much less
in practice, right?
Yes, there could be many other variables but in general we expect the
total gas usage to be about the same as what it is now and BaseFee will
hover around the network cross over.
—
Reply to this email directly, view it on GitHub
<#3 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEXAF2VHKUXOICKHK2DC3TVIZUS3ANCNFSM5U6XIMBA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Closing this as it's outdated (as per above comment). Please continue discussion in the https://github.com/filecoin-project/FIPs/ repo! |
