1

As I know, there each received transaction is validated before propagation it to other nodes. So I want to know, is execution of smart contracts a part of this validation? What would be the reason?

  • Is this about pending transactions? or already mined transactions. – Ismael Feb 15 '18 at 23:40
  • @Ismael - Ah, you might have a point. I'll let him confirm and remove/change my answer if so :) – Richard Horrocks Feb 15 '18 at 23:52
  • @RichardHorrocks It will be nice if we have both circumstances covered, just in case. – Ismael Feb 16 '18 at 3:46
  • @Ismael - Looks like Rob beat me to it :-) I'll edit mine to make it clear that I'm talking about mined blocks, rather than the transaction pool. Thanks for pointing it out. – Richard Horrocks Feb 16 '18 at 8:10
2

The answer will depend on whether you're talking about, 1) validating and propagating newly mined blocks that contain transactions, or 2) validating and propagating newly broadcast transactions in the tx pool, before they're put into blocks.

My answer covers 1). Rob and medvedev1088's answers cover 2).


Does the Ethereum node execute the contract code before propagating it to others?

There are actually two different cases for the order of validation and propagation.

Non-miner nodes

  • Validates the proof of work in the block's header;
  • Propagates the block to the other nodes it knows about;
  • Validates that the state changes (i.e. transactions) in the block are valid.

If step 3 was done before step 2, then propagation would grind to a halt for large blocks.

Miner nodes

  • Validates the proof of work in the block's header;
  • Validates that the state changes in the block are valid;
  • Propagates the block to the other nodes it knows about.

In this case complete validation is done before propagation because a miner wants to be certain that he should give up mining and move onto the next block. (I think.)

(I'll try to find the source I had for this. At the minute it's just from memory... )

So I want to know, is execution of smart contracts a part of this validation?

Yes, as above, state transitions associated with running the contracts are checked, but at different times depending on the type of node.

0

As I understand it, No.

Blocks disambiguate the order in which accepted transaction were accepted by the network. There is no need to forward a transaction that is just gibberish. If its properly formed then all nodes need to know about it. This includes transactions that would seem to outright fail.

It would be inconclusive to run a contract function (send a transaction) to see what it does. We simply wouldn't know what the contract actually does until we know the chain state when network processes it.

If its a fail, even that needs to be part of the transaction record so one can see the data, see when it was mined, trace the traction possibly, try to understand why it failed and notice how many confirmations agree on the transaction outcome. There is also accounting for the gas consumed by a miner or returned to sender.

Hope it helps.

  • Hi Rob - just to check: you're talking about the case where transactions are being broadcast and propagated to the tx pool? (My answer covers the case for propagating newly-mined blocks, which is likely what the OP wasn't asking. I'll edit mine to defer to yours... ) – Richard Horrocks Feb 16 '18 at 8:09
  • It's all good. I'm not sure whether he's asking for a block level or transaction level answer, but I think we've got good coverage. :-) – Rob Hitchens - B9lab Feb 16 '18 at 15:57
0

Every transaction that satisfies the following conditions is considered valid:

  1. the transaction is well-formed RLP, with no additional trailing bytes;
  2. the transaction signature is valid;
  3. the transaction nonce is valid (equivalent to the sender account’s current nonce);
  4. the gas limit is no smaller than the intrinsic gas, 21000, used by the transaction;
  5. the sender account balance contains at least the cost, value + gasprice * gaslimit, required in up-front payment.

If it satisfies the above conditions it can be included in a block regardless of whether it succeeds or fails, there is no need to execute the transaction to check its validity.

So a transaction can be:

  • valid - the above 5 conditions are satisfied;
  • successful - a valid transaction successfully executed by the EVM;
  • failed - a valid transaction executed by the EVM with an exception (stack underflow/overflow, invalid instruction, JUMP/JUMPI destination is invalid, out-of-gas);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.