1

I have one question that relates to a smart contract, EVM, and mining.

contract Test {
  event Transfer(
    address indexed _from,
    address indexed _to,
    uint256 _amount,
    uint256 _seq
  );
  uint256 public _seq;

  function transfer(address _to, uint256 _amount) external {
     _seq++;
     emit Transfer(msg.sender, _to, _amount, _seq);
  }
}

Given:

  • At time t = 10: the state variable '_seq = 10'
  • There are 3 nodes calling transfer(), then generating transactions at the same time (t = 10)
    • Tx 1: _seq++ = 11 ==> Transfer(Node1.address, _to1, _amount1, 11)
    • Tx2: _seq++ = 11 ==> Transfer(Node2.address, _to2, _amount2, 11)
    • Tx3: _seq++ = 11 ==> Transfer(Node3.address, _to3, _amount3, 11)

My question is:

  • Will the state variable '_seq' be updated to 11 or 13 after these transactions are mined and added into a block?
0

The situation you describe either lack of details or is impossible.

First, at the end of the consensus, you will never have three different blocks accepted from three different nodes (in a perfect world where all the nodes are up to date instantly. Does not happen, but easier to understand).

A node 1 will emit its block and propose it to other nodes. It will be accepted or not. If it is accepted, the head of the chain will contain _seq = 11.

If, while the node 1 emited the block, that was accepted, a node 2 tried to mine a block, its resulting block will not be accepted by other nodes because the head of the chain is a block that is different from the block that was used as a previous block by node 2.

So, say Node 1 had tx1, node 2 tx2 and node 3 tx 3, node 1 mined tx1, node 2 and 3 receive the new block from node 1 while they try to mine tx2 and tx3. tx2 and tx3 go back to transaction pool, to be mined from the new chain head, the block that contains tx1.

As a consequence, after ALL the transactions listed are mined, _seq will be 13.

Moreover, the events you will see in the blocks will not be Transfer(Node1.address, _to1, _amount1, 11), but, in chronological order (assuming node 1 mined before node 2 that mined before node 3):

Transfer(Node1.address, _to1, _amount1, 11)
Transfer(Node2.address, _to2, _amount2, 12)
Transfer(Node3.address, _to3, _amount3, 13)

Note: this describes the situation where the transactions are not broadcasted. There is a possibility that your three nodes share the transactions and thus making this scenario a little, or very different (all transactions mined in the same block by the same node, etc.)

4
  • Thanks for your answer. Actually, these transactions are not mined yet. Three nodes call transfer() when _seq = 10. Three transactions are generated thereafter. My question is what a value of _seq would be when these transactions are verified and added into one block by a miner.
    – Jason Tran
    Aug 4 at 8:29
  • 13. Each transaction incrementing it by one. Aug 4 at 9:09
  • So, after mining you mean _seq = 11 and there are three Transfer event as: - Transfer(Node1.address, _to1, _amount1, 11) - Transfer(Node2.address, _to2, _amount2, 11) - Transfer(Node3.address, _to3, _amount3, 11)
    – Jason Tran
    Aug 4 at 15:21
  • No. _seq will be 13. And you will see three events: Transfer(Node1.address, _to1, _amount1, 11), Transfer(Node2.address, _to2, _amount2, 12), Transfer(Node3.address, _to3, _amount3, 13) (assuming transactions are mined in this order). Aug 5 at 6:59

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.