-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Charge for new storage bytes #634
Conversation
@@ -321,6 +321,7 @@ pub struct GasCostsValues { | |||
// Non-opcode costs | |||
pub contract_root: DependentCost, | |||
pub state_root: DependentCost, | |||
pub new_storage_per_byte: Word, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Name still subject to bikeshedding
pub profiler: &'vm mut Profiler, | ||
pub new_storage_gas_per_byte: Word, | ||
pub current_contract: Option<ContractId>, | ||
pub cgas: RegMut<'vm, CGAS>, | ||
pub ggas: RegMut<'vm, GGAS>, | ||
pub is: Reg<'vm, IS>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not needed for state read opcodes, so maybe it makes sense to split this struct into two? On the other hand, we're handing over over half of the VM anyway, so just passing the VM directly might make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issues says:
We need to find all opcodes that modify the storage first. For that, we can find all places where we use methods from the InterpreterStorage trait.
It is similar to the issue FuelLabs/fuel-core#1239
@@ -321,6 +321,7 @@ pub struct GasCostsValues { | |||
// Non-opcode costs | |||
pub contract_root: DependentCost, | |||
pub state_root: DependentCost, | |||
pub new_storage_per_byte: Word, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is better to use DependentCost
here because we need to charge for a new storage slot, plus, in the future(when we support dynamic storage values), charge per byte.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes any sense to future-proof this for the dynamic storage value support. The whole API is going to change anyway.
cgas, | ||
ggas, | ||
profiler, | ||
(Bytes32::LEN as u64) * new_storage_gas_per_byte, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to charge static cost and per byte=)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What static cost? The opcode itself already costs for instertion, this is only for the new slot which has a fixed cost.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is related to the comment about DepenentCost
=) base
cost can include inserting the new entry into the storage(it will represent the burden of the SMT), and deps_per_unit
will be gas per byte that you will multiply with 32
or 64
, but in the later versions with dynamic storage by the size of the value.
Should we also charge for 32 bytes(asset id) + 8 bytes (amount) when inserting a new asset type into the balances tree? |
Yep
|
Co-authored-by: Green Baneling <[email protected]>
Co-authored-by: Green Baneling <[email protected]>
Co-authored-by: Green Baneling <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good=) Waiting for rest of opcodes
@@ -196,8 +230,12 @@ struct TransferCtx<'vm, S, Tx> { | |||
context: &'vm Context, | |||
balances: &'vm mut RuntimeBalances, | |||
receipts: &'vm mut ReceiptsCtx, | |||
profiler: &'vm mut Profiler, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You forgot to update transfer_output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I though TRO doesn't create markle tree entries? Am I missing something here?
See this issue for context: FuelLabs/fuel-vm#602 FuelVM PR: FuelLabs/fuel-vm#634
Closes #602
Spec PR: FuelLabs/fuel-specs#536
Breaking changes:
StorageSlot::LEN * gas_costs.new_storage_per_byte * num_slots