Could smart contract use a fork block?

Question

If generated two forked block A and B. Can the smart contract in block A access to transaction in block B?

I know that PoS is consensus algorithm working by check all stake in block. The verifier keep the block which has many stake. I guess that not need to access to stake in the other block. I think it is enough that verifier sum all stake in each block and compare two total stake.

But, I wonder whether the smart contract in block A can access to transaction in block B or not?

Answer 1

The contract and state relative to a chain fork are not related to the method used to reach consensus, e.g. PoS, PoW, something else.

In this context, "consensus" is concerned with establishing a canonical transaction order. Given a known set of transactions in a certain order, then each node can establish what the state must be. It's deterministic, so there's only one possible correct answer - any departure from that is malfunctioning node but the network itself is indifferent to that.

The contract potentially has different states on the two forked chains owning to differences in the transactions and order on those two forks.

Consider a simple contract deployed on block 10.

contract SimpleStorage {

  uint public x;

  function set(uint _x) public {
    x = _x;
  }
}

Great. X is initially 0. Anyone can set it to something else.

Suppose Alice and Bob send two transactions to setX() to 50 and 100 respectively, and they do that more or less simultaneously.

Now the fork.

Suppose chain A mines both transactions, Alice first. x was 50 for a moment (if anyone looked) and then 100 because Bob updated it again. That was observable to all nodes that saw the block, at block height 11.

Suppose another miner found a block 11, but in that version, Bob's transaction came first. In that version of history, the result is x == 50. That determination is supported by a version of history.

So, the question is which version of history is correct? The longest chain rule will sort that out and eventually, e.g. block 15, there will multiple confirmations of one or the other history. One is a world that could have been and one is the world we find ourselves in.

There is no known method of communication between the forks.

In summary, contract states are similar to account balances and the same thought process applies regarding confirmations. Whatever happens is always supported by a canonical description of history - everything that happened in the order it is deemed to have happened by consensus.

Hope it helps.

Answer 2

Since you mention PoS is your question about future Eth 2.0 beacon chain or a regular contract in Eth 1.0?

A smart contract in Eth 1.0 has limited access to blockchain data:

• hashes of previous 255 blocks
• access data of the calling transaction and not others
• access to its own storage (where previous transactions might have written to).

It is possible to design a contract that implements a challenge-response protocol where the contract validates data of blocks like forks. Block chain data has to be supplied by participants. Contract doesn't have direct access to data but it can verify data that is send to it.