The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

ptmy (22) [Avatar] Offline
A few additional questions:

1) It's my understanding that all nodes validate all transactions received via broadcast from the originating node before re-broadcasting. What do the validators look for during this validation process (i.e., what determines a valid vs invalid transaction)? What happens if a transaction is deemed invalid?

2) Same questions as above for a mined block (i.e., a mined block gets validated by all nodes as well). In addition, do all smart contracts included in the block get executed by all nodes during this validation process?

3) I assume the miner that successfully mined a given block will executed the constructors of all the deployed smart contracts included in that block. If this is the case, does a snapshot of all the associated state data (e.g., content of the variable "coinBalance" in the book's example) get stored somewhere in that block as well?

4) When a subsequent transaction calls for state-data modification, where are the new values stored?
RobertoI (29) [Avatar] Offline

thanks for your new questions. Although my answers for questions 3 and 4 will be partially covered in chapter 5, I'll amend the chapter 1 to reflect some of the answers I am giving you below:

1) Transactions get executed by all full nodes that receive them, but only to verify that:

* the transaction digital signature is valid, according to the Elliptic Curve Digital Signature Algorithm (ECDSA), which checks the cryptographic consistency of the public address of the sender, the content of the transaction and the signature hash.
* the sender has enough ether to fund the gas required for the completion of the transaction (the transaction execution does not run out of gas)
* the transaction does not exceed the gas limit set on the transaction
If the transaction execution completes succesfully (which means none checks above fails the processing) the transaction is simply broadcast to the peers of the node executing it: no contract state change takes place, because only the miners are able to write the state change on the blockchain.
If the transaction fails, it is simply not briadcast to the peer nodes, so it drops out the propagation process.

2) When a block is received by a full node, this performs preliminary checks on the block itself, such as:

* the hash of the previous block is correct
* the digital signature of each transaction contained in the block is correct
* there is cryptographic consistency between the address of the miner, the content of the block, the nonce found by the miner and and the block hash
If these checks pass succesfully, the full node executes each transaction.
After executing a transaction it compares the values of the contract state variables that have been modified by the transaction on the full node with the corresponding values reported on the block. If they match, the transaction is considered successfully validated and the next is executed.
If all transactions are validated succesfully, the block is considered validated and it is broadcast to the peers of the full node.
If anything of the checks above fails, the block is simply not briadcast to the peer nodes, so it drops out the propagation process.

3 and 4) The blockchain can be considered made of two set of data, which are stored on every full-node and miner node:

* a list of all blocks forming the chain (each containing, as you know, a transaction list, hash of previous block, miner address, and block hash)
* a state tree, with every node of the tree containing a key-value pair: the keys is address of an account and the value is a tree with the following nodes:
- account balance
- account nonce
- contract bytecode (relevant only for contract accounts)
- a state variable key-value store (relevant only for contract accounts), containing the reference of each state variable and its value

A hash is calculated at every level of the state tree: at the bottom a hash is calculated for the state variable key-store of a specific account, at the top a hash is calculated on all the hashes of all accounts

While a miner processes a transaction of the block being created, it recalculates at each state change hashes at the relevant levels of the tree affected by a state change.

After having processed all block transactions, the miner includes the hash of the amended full state tree (resulting from all processed transactions) on the new block.

When a full-node processes the block transactions, it will amend the local state tree and recalculates the hashes at every affected level, as the miner did. Finally it verifies the hash of the amended full state tree matches the one included on the block by the miner.