CREATE2 implementation in aleth-interpreter #5125
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #5125 +/- ##
===========================================
+ Coverage 58.68% 59.46% +0.77%
===========================================
Files 337 337
Lines 27126 27054 -72
Branches 3165 3164 -1
===========================================
+ Hits 15920 16088 +168
+ Misses 10141 9884 -257
- Partials 1065 1082 +17 |
libaleth-interpreter/VMCalls.cpp
Outdated
| { | ||
| assert(m_OP == Instruction::CREATE2); | ||
| // Pass salt data through EVMC as 32-byte prefix in evmc_message::input_data | ||
| saltAndInputData = toBigEndian(salt) + bytesConstRef(&m_mem[off], size); |
There was a problem hiding this comment.
If we go with this, it must be documented in evmc properly.
I think it is a stretch, however uncontrollably growing evmc_message isn't a better option.
There was a problem hiding this comment.
Because using the message input to pass the salt requires a copy of the init code, I'm more into adding the salt param to the message.
More generic approach would be to ask the VM to come up with the address and put it in the message.destination.
There was a problem hiding this comment.
I'll change it to salt as a separate member of evmc_message then.
…nstead of inside input_data
|
Still need to support CREATE2 calls through |
libaleth-interpreter/VMCalls.cpp
Outdated
| msg.sender = m_message->destination; | ||
| msg.depth = m_message->depth + 1; | ||
| msg.kind = m_OP == Instruction::CREATE ? EVMC_CREATE : EVMC_CREATE2; // FIXME: In EVM-C move the kind to the top. |
gumb0
force-pushed
the
create2-interpreter
branch
2 times, most recently
from
44eb2e2 to
16a573e
Compare
gumb0
force-pushed
the
create2-interpreter
branch
from
16a573e to
50d4841
Compare
|
I realized that no more changes are needed in So this is ready for review. |
#5119
Required change in EVMC ethereum/evmc#45