-
Notifications
You must be signed in to change notification settings - Fork 679
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
Return header instead of block from vm.apply_txn #625
Conversation
evm/chains/base.py
Outdated
@@ -487,20 +487,29 @@ def apply_transaction(self, transaction): | |||
heavy and incurs significant perferomance overhead. | |||
""" | |||
vm = self.get_vm() | |||
block, receipt, computation = vm.apply_transaction(transaction) | |||
receipts = block.get_receipts(self.chaindb) + [receipt] | |||
old_block = vm.block |
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.
base_block
previous_block
If you like either better.
Temporarily in VM, but eventually in Chain, once the state tests get refactored.
evm/vm/base.py
Outdated
|
||
return self.mine_block() | ||
|
||
def seal_block(self, base_block, new_header, transactions, receipts): |
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 like the term seal
as for me at least, it implies mining like setting the mix_hash
and nonce
.
What about just add_transaction_to_block
or something?
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.
How about set_transactions_in_block
?
- pro: transactions is plural, old transactions in block are replaced, and -- for now -- the trie data is persisted
- con: implies block mutation, when it's really building a block copy
Other alternatives:
place_transactions_in_block
commit_transactions_to_block
get_block_with_transactions
(problem: get implies no side-effects)add_transactions_to_block
(problem: add implies that previous transactions are left in place)
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.
set_block_transactions
(keeps withget_
,set_
convention...)update_block_transactions
just an alternate prefix.
any of of those work for you?
What was wrong?
Related to #599 & #507 - VM returns partially-completed block objects as a result of
apply_transaction()
How was it fixed?
Return the header instead, and let
chain
deal with building the block (at the appropriate time). As a bonus, we build fewer block objects duringvm.import_block()
.TODO in follow-up PR: decide how to deal with the exact some problem with
header
which is only partially formed (no state/receipt root) -- maybe this is where aTransactionDiff
comes in`Cute Animal Picture