Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

EIP-210 BLOCKHASH changes #5505

Merged
merged 2 commits into from
May 30, 2017
Merged

EIP-210 BLOCKHASH changes #5505

merged 2 commits into from
May 30, 2017

Conversation

arkpar
Copy link
Collaborator

@arkpar arkpar commented Apr 25, 2017

@arkpar arkpar added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. M4-core ⛓ Core client code / Rust. labels Apr 25, 2017
@arkpar arkpar mentioned this pull request Apr 26, 2017
12 tasks
@arkpar arkpar added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels May 23, 2017
@@ -310,6 +311,11 @@ impl<B: Backend> State<B> {
Ok(state)
}

/// Get a VM factory that can execute on this state.
pub fn vm_factory(&self) -> EvmFactory {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what was the motivation to move vm factory in the state?
how the decision of choosing the vm executor depends on state?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not move it in the state, it is there already. The state is currently constructed with all the Factories that are going to operate on it. I would agree that the state should not be concerned about factories, but refactoring this is out of the scope of this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it's mostly there because of "State::apply" which should really be a fn apply(&mut State, VMFactory) in some other module.

@NikVolf NikVolf added A5-grumble 🔥 Pull request has minor issues that must be addressed before merging. and removed A0-pleasereview 🤓 Pull request needs code review. labels May 23, 2017
@arkpar arkpar added A0-pleasereview 🤓 Pull request needs code review. and removed A5-grumble 🔥 Pull request has minor issues that must be addressed before merging. labels May 23, 2017
@NikVolf NikVolf added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels May 23, 2017
@@ -278,10 +282,55 @@ impl<'x> OpenBlock<'x> {
let gas_floor_target = cmp::max(gas_range_target.0, engine.params().min_gas_limit);
let gas_ceil_target = cmp::max(gas_range_target.1, gas_floor_target);
engine.populate_from_parent(&mut r.block.header, parent, gas_floor_target, gas_ceil_target);
Self::push_last_hash(&mut r.block, last_hashes, engine, &parent.hash())?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be something to be done in engine.populate_from_parent?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a utility for engines to call contract functions before and after the transactions within a block as a part of the state transitions seems like it would be useful generally

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

populate_from_parent is supposed to populate just the header. It is a good idea to move it to the engine though.

let mut ex = Executive::new(&mut state, &env_info, engine);
let mut substate = Substate::new();
let mut output = [];
if let Err(e) = ex.call(params, &mut substate, BytesRef::Fixed(&mut output), &mut NoopTracer, &mut NoopVMTracer) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

applying the substate, collecting garbage, etc?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand the EIP this is more of a call with preserved state changes. Finalization is not required.

BuiltIn { .. } => "Built-in failed",
Internal(ref msg) => msg,
OutOfGas => "Out of gas".into(),
BadJumpDestination { destination } => format!("Bad jump destination {:x}", destination),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all of these should be write!(f, "...", fmt_args)

@arkpar arkpar added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. and removed A8-looksgood 🦄 Pull request is reviewed well. labels May 23, 2017
@arkpar arkpar force-pushed the eip210 branch 2 times, most recently from 06b852b to d0b0310 Compare May 24, 2017 13:03
@arkpar arkpar added A0-pleasereview 🤓 Pull request needs code review. and removed A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. labels May 24, 2017
@NikVolf NikVolf added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels May 29, 2017
@gavofyork
Copy link
Contributor

code looks fine. did anyone cross check this against either the YP or the EIP spec?

@gavofyork
Copy link
Contributor

@NikVolf / @rphmeier ^^^ ?

@NikVolf
Copy link
Contributor

NikVolf commented May 29, 2017

@gavofyork yep!

apart from the contract bytecode which cannot be reviewed obviously

@arkpar
Copy link
Collaborator Author

arkpar commented May 29, 2017

The bytecode is in the EIP. You can just check that it matches :)

@@ -53,6 +53,9 @@ use evm::CreateContractAddress;
use ethkey::Signature;
use util::*;

/// Default EIP-210 contrat code
pub const DEFAULT_BLOCKHASH_CONTRACT: &'static str = "73fffffffffffffffffffffffffffffffffffffffe33141561007a57600143036020526000356101006020510755600061010060205107141561005057600035610100610100602051050761010001555b6000620100006020510714156100755760003561010062010000602051050761020001555b610161565b436000351215801561008c5780610095565b623567e0600035125b9050156100a757600060605260206060f35b610100600035430312156100ca57610100600035075460805260206080f3610160565b62010000600035430312156100e857600061010060003507146100eb565b60005b1561010d576101006101006000350507610100015460a052602060a0f361015f565b63010000006000354303121561012d576000620100006000350714610130565b60005b1561015357610100620100006000350507610200015460c052602060c0f361015e565b600060e052602060e0f35b5b5b5b5b";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could a comment include a permanent link (to commit diff, not PR diff) of the EIP?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@gavofyork gavofyork merged commit e6a31e7 into master May 30, 2017
@gavofyork gavofyork deleted the eip210 branch May 30, 2017 09:52
H256::zero()
},
fn blockhash(&mut self, number: &U256) -> H256 {
if self.env_info.number + 256 >= self.engine.params().eip210_transition {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think + 256 should appear in the right hand side, not in the left hand side.

Ok((code, hash)) => (code, hash),
Err(_) => return H256::zero(),
};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this comment ethereum/EIPs#210 (comment) it was decided that BLOCKHASH instruction should return zero for blocks more-than-256 blocks old. So here should be a check on number.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants