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

Added checking tx-type using transactions permission contract for miners #7359

Conversation

VladLupashevskyi
Copy link
Contributor

In this commit you can find solution to the issue #7350 which I opened recently.

Now block miners are checking whether the tx type is allowed for sender using transaction permission contract.

@parity-cla-bot
Copy link

It looks like @VladLupashevskyi signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@tomusdrw tomusdrw added A0-pleasereview 🤓 Pull request needs code review. M4-core ⛓ Core client code / Rust. labels Dec 22, 2017
@tomusdrw
Copy link
Collaborator

I think the check should actually be done before importing transactions to the queue as well. Otherwise we might be storing and propagating a lot of invalid transactions.

Should be done here:
https://github.com/paritytech/parity/blob/master/ethcore/src/miner/miner.rs#L675

Other than that: great work, thank you @VladLupashevskyi

// Check whether transaction type is allowed for sender
let result = match self.engine.machine().verify_transaction(&tx, open_block.header(), chain.as_block_chain_client()) {
Err(Error::Transaction(TransactionError::NotAllowed)) => {
Err(From::from(TransactionError::NotAllowed))
Copy link
Contributor

Choose a reason for hiding this comment

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

favor .into() instead of From::from

@@ -419,7 +420,15 @@ impl Miner {
for tx in transactions {
let hash = tx.hash();
let start = Instant::now();
let result = open_block.push_transaction(tx, None);
// Check whether transaction type is allowed for sender
let result = match self.engine.machine().verify_transaction(&tx, open_block.header(), chain.as_block_chain_client()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess open_block's parent state always has to be available in the client, so this is fine.

@arkpar
Copy link
Collaborator

arkpar commented Dec 22, 2017

Agree with @tomusdrw. It is assumed that transaction queue contains valid transactions only.

@tomusdrw
Copy link
Collaborator

@arkpar although the state of the transaction might change in the meantime, with current queue we have no way of invalidating such transactions, so I'm ok with check in both places.

@arkpar
Copy link
Collaborator

arkpar commented Dec 22, 2017

Makes sense

@@ -680,6 +698,12 @@ impl Miner {
Err(e)
},
Ok(transaction) => {
// This check goes here because verify_transaction takes SignedTransaction parameter
if self.engine.machine().verify_transaction(&transaction, &best_block_header, client.as_block_chain_client()).is_err() {
Copy link
Collaborator

@arkpar arkpar Dec 22, 2017

Choose a reason for hiding this comment

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

The error here should not be interpreted as permission failure. Other checks might be added in the future. Best would be just to pass it to the caller:

self.engine.machine().verify_transaction(&transaction, &best_block_header, client.as_block_chain_client())?;

@VladLupashevskyi
Copy link
Contributor Author

@arkpar Agreed. And thank you, my Rust knowledge is much better now :) I didn't know about this amazing "?" operator before.

@arkpar arkpar added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels Dec 22, 2017
@debris debris merged commit 2586eae into openethereum:master Dec 29, 2017
@VladLupashevskyi VladLupashevskyi deleted the transactions-permission-contract-fix branch December 30, 2017 21:38
@5chdn 5chdn added this to the 1.9 milestone Jan 2, 2018
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.

None yet

7 participants