Paygas refund issue

What is wrong?

If a transaction fails after PAYGAS has been called, the sender ends up with his initial balance plus some additional funds. The reason for this seems to be that at the point of failure, the state is reverted to the pre gas payment state (i.e. the original balance), and on top of that the unused gas is refunded.

Here’s the test case that discovered the bug: https://github.com/jannikluhn/py-evm/blob/de5365458c1839a47a1301551e3b62e54c5214ef/tests/fillers/vm_fillers/paygas_fillers.py#L322-L349

In this case, the account at address ends up with a balance of 138958 instead of 38958.

How can it be fixed

After reverting the state subtract the transaction fee again

Ping @NIC619

[pipermerriam]

That worries me. It couples the state database with EVM business logic which feels wrong.

This leaves me with the original idea, which is to add a mechanism to bypass the journal. After taking a look at the code, I think this is quite doable and you should be able to validate this approach pretty easily with a basic test.

The JournalDB will need to be updated to allow bypassing the journal. I think the best way to do this would be to add a bypass_journal flag to all of the get/set/delete methods which defaults to False

When bypass_journal is True the journal should do the following.

• proceed with the operation on the self.wrapped_db
• if the journal has any checkpoints, the earliest checkpoint should be updated to contain the new value for the key in question.

This code can be tested with the following somewhat simple test cases.

jdb = JournalDB(...)

# case 1
s = jdb.snapshot()
jdb.set(k, v, bypass=True)
jdb.revert(s)
assert jdb.get(k) == v

# case 2
s = jdb.snapshot()
jdb.set(k, v)
jdb.set(k, v2, bypass=True)
jdb.revert(s)
assert jdb.get(k) == v2

# case 3
s = jdb.snapshot()
jdb.set(k, v, bypass=True)
jdb.set(k, v2)
jdb.revert(s)
assert jdb.get(k) == v

# case 4
s = jdb.snapshot()
jdb.set(k, v, bypass=True)
s2 = jdb.snapshot()
jdb.set(k, v2)
jdb.revert(s)
assert jdb.get(k) == v

Let me know what you think about this approach. It feels cleaner than intertwining the actual PAYGAS business logic into different layers of the stack. There will also need to be a change to the AccountStateDB object itself to tell it to bypass the journal which should probably just be a flag passed to it during instantiation.

[pipermerriam]

Thanks for exploring the idea. Nothing wrong with your approach. Make it so! 👍