-
Notifications
You must be signed in to change notification settings - Fork 1.7k
EIP 1283: Net gas metering for SSTORE without dirty maps #9319
Changes from 1 commit
b7a9402
a082907
3ba5467
87a93c0
5f2e25c
9c56484
4861e35
11490b5
399abe8
f57853c
8909d6e
e4a6668
e2b5899
00ae258
fb99c74
3149c7f
c07d12f
971e82c
b1b7c57
b01c566
c2b9e97
7f672c3
6269c33
0e4ba15
196f831
14b89c2
f9af2c3
a718e90
f6aa738
ad8dc94
4d5555b
8b31417
72693d3
ab83e36
ef6a01c
aa6006e
aabc367
8a573a1
c31cc59
522f2e9
14283f8
ae73ed4
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 |
---|---|---|
|
@@ -400,8 +400,12 @@ impl<'a, T: 'a, V: 'a, B: 'a> Ext for Externalities<'a, T, V, B> | |
self.depth | ||
} | ||
|
||
fn inc_sstore_clears(&mut self) { | ||
self.substate.sstore_clears_count = self.substate.sstore_clears_count + U256::one(); | ||
fn inc_sstore_refund(&mut self, value: U256) { | ||
self.substate.sstore_clears_refund = self.substate.sstore_clears_refund + value; | ||
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 we sure it won't overflow? Can we use 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. We're sure it won't overflow -- Refund will never go above gas provided, and gas provided has upper limit of 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. It would be a consensus bug only if it's implemented differently in other clients. Always panicking doesn't seem to me like a good idea (would actually prefer the network to split than to kill large part of it, or even the entire network if it's a private Parity-only chain). Happy with whatever behavior that doesn't cause a panic (i.e. 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. @tomusdrw What I meant is that theoretically that cannot happen. Refund can never go over 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. I realized that I was wrong here. Theoretically it's indeed possible for this value to go over |
||
} | ||
|
||
fn dec_sstore_refund(&mut self, value: U256) { | ||
self.substate.sstore_clears_refund = self.substate.sstore_clears_refund - value; | ||
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. Can we use 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. The same as above -- we're mostly sure it won't overflow, otherwise it's a consensus bug. |
||
} | ||
|
||
fn trace_next_instruction(&mut self, pc: usize, instruction: u8, current_gas: U256) -> bool { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -140,8 +140,11 @@ pub trait Ext { | |
/// then A depth is 0, B is 1, C is 2 and so on. | ||
fn depth(&self) -> usize; | ||
|
||
/// Increments sstore refunds count by 1. | ||
fn inc_sstore_clears(&mut self); | ||
/// Increments sstore refunds counter. | ||
fn inc_sstore_refund(&mut self, value: U256); | ||
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. I'd rather call it 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. Fixed! |
||
|
||
/// Decrements sstore refunds counter. | ||
fn dec_sstore_refund(&mut self, value: U256); | ||
|
||
/// Decide if any more operations should be traced. Passthrough for the VM trace. | ||
fn trace_next_instruction(&mut self, _pc: usize, _instruction: u8, _current_gas: U256) -> bool { false } | ||
|
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.
Do you think it's possible to use
u64
instead ofU256
here? Maybe we could useu64
until it fits and fallback toU256
if it overflows? That said, I'm happy to see an improvement PR for this with some benchmarks to prove that it's actually worth maintaining the more complicated code here.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.
That won't save memory, IMO. The issue is that we would need a enum/union for that, but it always takes more compared what U256 takes.
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 didn't mean memory, but rather a performance improvement since we are not using our custom U256 arithmetic. But as mentioned, it's fine for me to see a separate PR with that if anyone is interested on working on this, it's probably not super hot code anyway, so it would be marginal.