Modern blockchain technology relies on different principals than previous generations of blockchains, known as UTXO or generation 1.0, and allows for more robust transaction execution. An introductory stateful blockchain can be expressed as a game of correspondence chess.

The rules of chess are understood by all participants in the network and, as such, it is understood that a knight has a certain series of functions, or moves, it is able to perform. The same holds true for the other pieces of the game.

The genesis state of a traditional the game is presented in figure A. Both participants have a series of pieces that they are able to use and have agreed on the current positions of each. This is conceptually similar to smart contracts on a blockchain. Each contract has a predefined set of functions that are controlled by rules just as each piece as a predefined set of moves it is allowed to make in game play.

In the correspondence chessboard network our consensus mechanism is set as such: each member must make 1 legal move per block. Once the player decides on the move, it must be submitted to a judge. Unlike modern blockchains, the chess game also requires each participant make their move in proper order. The dark pieces are forbidden from sending a transaction until the light pieces have made their commitment. When the light side player submits their move to the judge, it is visible to everyone and unable to be changed. Once both sides have made their commitment to a move, the block is captured as a list of moves (state changes) in PGN format and numbered from the genesis state.

An example of a possible valid block number 1 could be: 1 d4 ♞f6. The

“blocks” are just a list of the moves that were made, not the actual pieces. This can be translated as the light side moving the pawn from d2 to d4 and the dark side moving their knight from g8 to f6. Both are valid moves and arrived in the correct order, so per our consensus rules this is a valid block. Each player will update their board with the new ‘state’. Players are only concerned with the current state, which contracts they can interact with, and what move they want to make next.

As the game progresses, it is possible for any outside participant to validate the current state by reading through a the PGN list of moves from genesis and recreating the game. In the blockchain space this is known as syncing a node. If one of the players needs to take a break or knocks over their board, they are able to sync their board to the current state by reading the move list. A faster way of syncing would be to take a snapshot of the current state and send it to the validator along with the PGN. They would then have the current state and can validate it as needed. This allows for seemingly complex chess games to be replayed and studied by a broad audience.

In a stateful blockchain system such as Ethereum, all of the rules from above still apply. Each node keeps a copy of the blockchain so they are able to validate their current copy of the state and the state began at a commonly agreed upon genesis block. By viewing the state, a participant is able to see contracts on the system in the same way they would see all the chess pieces at any state in the chess game. Similar to each chess piece, each smart contract has a series of rules and permissions associated with it. that govern its behavior. In contrast to the chess game, participants in the ethereum network are able to add valid contracts at any time in the form of a transaction. They will send the transaction to a node responsible for creating valid blocks. Once a series of transactions have been validated, the block of transactions is sent to all the participants who then update their local state. Participants only care about the current state, which contracts they can interact with, and which transaction they want to make next. As the state is shared between all participants, it is important to minimize the amount of data stored on leaf nodes of the states Merkle tree

image from ‘Merkling in Ethereum’

In an ethereum system, all accounts follow the same formatting scheme and are mapped by their unique account address. Both user accounts and contract accounts are stored in the same manner. Each account has:

• The nonce, a counter used to make sure each transaction can only be processed once

• The account’s current ether balance

• The account’s contract code, if present

• The account’s storage (empty by default)

Each node stores a list of all accounts that have ever made a transaction on the system and maintains the Merkel root of all accounts. When a transition arrives in a block, the new state root is computed and validated against the blocks state root.

For more info on ether trees check out: https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/

https://medium.com/@dontpanicburns/an-introduction-to-stateful-blockchains-dcdccae660be