-
Notifications
You must be signed in to change notification settings - Fork 2
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
Replayer should supply block specific context to transactions #3
Comments
@frankbraun , one important thing would be to guard |
@djsatok: Yes, absolutely. I think we should stress test on betanet that way, maybe on testnet (to be determined), but the corresponding functionality (in |
The block context is now prepared by the replayer. |
See also aurora-is-near/aurora-engine#2 |
As described in aurora-is-near/aurora-engine#1 (comment) and aurora-is-near/aurora-engine#2 (comment), the EVM contract is now ready to begin accepting |
@djsatok brought up the issue on Discord that smart contracts can use
block.timestamp
and if that doesn't match a replayed transaction will fail.It's even worse then that, all of the following could potentially be used:
block.coinbase
block.timestamp
block.number
block.difficulty
block.gaslimit
hash = block.blockHash(blockNumber)
(hash of the specific block, only valid for the 256 most recent blocks, excluding the current one)See EVM Opcodes.
After discussion with @artob, taking into consideration that the EVM will now mostly be implemented as a smart contract, we agreed that the best approach would be to extend the near-web3-provider API with a something like
Eth.send_raw_transaction_with_context
. Similar toEth.send_raw_transaction
, but also passing in the necessary block context to execute the transaction within a test contract deployment of the EVM.That way, in combination with issue #2, we should be able to replay all transactions of an Ethereum testnet to a NEAR EVM test deployment.
The text was updated successfully, but these errors were encountered: