-
Notifications
You must be signed in to change notification settings - Fork 122
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
Feature/nullification costing #1949
Changes from 3 commits
6976fec
0a2bd44
eeb9a99
2b2aef3
31bd7d9
ef4aa5e
1f8f892
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,6 +8,7 @@ use crate::kernel::kernel_callback_api::{ | |
use crate::system::actor::Actor; | ||
use crate::system::system_modules::transaction_runtime::Event; | ||
use crate::track::interface::StoreCommit; | ||
use crate::track::IOAccess; | ||
|
||
#[derive(Debug, IntoStaticStr)] | ||
pub enum ExecutionCostingEntry<'a> { | ||
|
@@ -21,6 +22,9 @@ pub enum ExecutionCostingEntry<'a> { | |
RefCheck { | ||
event: &'a RefCheckEvent<'a>, | ||
}, | ||
Nullification { | ||
io_access: &'a [IOAccess], | ||
}, | ||
|
||
/* run code */ | ||
RunNativeCode { | ||
|
@@ -149,6 +153,7 @@ impl<'a> ExecutionCostingEntry<'a> { | |
} => ft.verify_tx_signatures_cost(*num_of_signatures), | ||
ExecutionCostingEntry::ValidateTxPayload { size } => ft.validate_tx_payload_cost(*size), | ||
ExecutionCostingEntry::RefCheck { event } => ft.ref_check(event), | ||
ExecutionCostingEntry::Nullification { io_access } => ft.nullification(io_access), | ||
ExecutionCostingEntry::RunNativeCode { | ||
package_address, | ||
export_name, | ||
|
@@ -290,6 +295,9 @@ pub mod owned { | |
RefCheck { | ||
event: RefCheckEventOwned, | ||
}, | ||
Nullification { | ||
io_access: Vec<IOAccess>, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Naively, I'd have expected this to be split between execution cost for the read, and finalization cost for the write? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also I wonder if we should use more intuitive names here, for the purpose of the receipt? (because "Nullification" is not really a common name in crypto/literature, even if we're using it internally)
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds reasonable to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you sure? When I looked at the code, I thought I saw that finalisation of the state updates (i.e. CommitStateUpdates) was calculated from the state changes before the intent state changes were added (which happens at receipt creation time after finalization, because it needs to be after the result is decided), so I don’t believe the cost of the state updates was captured. This is why I suggested separating them explicitly There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right! I don't know what I was thinking. Let me add it explicitly. And looks like we don't need to defer this cost, but apply at finalization time. If it fails, there is no commit anyway. Even fairer to users. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good. And if we (ever) add billing for non-contingent intents (currently just transaction intents), these should possibly be billed up front/deferred. |
||
}, | ||
|
||
/* run code */ | ||
RunNativeCode { | ||
|
@@ -528,6 +536,9 @@ pub mod owned { | |
ExecutionCostingEntry::RefCheck { event } => Self::RefCheck { | ||
event: event.into(), | ||
}, | ||
ExecutionCostingEntry::Nullification { io_access } => Self::Nullification { | ||
io_access: io_access.to_vec(), | ||
}, | ||
ExecutionCostingEntry::RunNativeCode { | ||
package_address, | ||
export_name, | ||
|
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.
Can we clarify that it's nominally included in the base fee?
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.
There is no base fee, but
tx_payload_cost
fee which is proportional to payload size.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.
Oh! I thought there was a base fee. Interesting. Perhaps we should add one at Cuttlefish to account for the ident? Or just bill for TransactionIntent nullification from Cuttlefish? (switching on the system logic version)
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.
We have various uncosted substate reads (such as systemboot, vmboot, kernelboot).
Per the comment above, the minimum transaction cost units is about
16,000
, which is just enough to cover oneReadFromDBNotFound
(which is much more expensive thanReadFromDB
).I think we can live with this for now, OR introduce a larger base.
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 do you think about the system logic tweak to also bill for transaction intent reads? Would be quite straightforward I imagine?
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.
At execution time, we can't tell if it's v1 or v2.
If we start charging for transaction intent from cuttlefish, fees for all transaction will be increased, which has a user impact. Not too sure about if it's worth to do it now.
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.
We're in system here, right?
We have access to the version number either from version state (current) or from a generic (if we merge #1919 ).
It will, but not by much I imagine?
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.
We can expose such information to the system.
It's more about "if it's good to have a discrepancy between v1 and v2".
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's about 16,000.