If we had access to a trustworthy centralized service, this system would be trivial to
implement; it could simply be coded exactly as described, using a centralized server's
hard drive to keep track of the state. However, with Bitcoin we are trying to build a
decentralized currency system, so we will need to combine the state transition system
with a consensus system in order to ensure that everyone agrees on the order of
transactions. Bitcoin's decentralized consensus process requires nodes in the network to
continuously attempt to produce packages of transactions called "blocks". The network is
intended to produce roughly one block every ten minutes, with each block containing a
timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the
transactions that have taken place since the previous block. Over time, this creates a
persistent, ever-growing, "blockchain" that constantly updates to represent the latest
state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
1. Check if the previous block referenced by the block exists and is valid.
2. Check that the timestamp of the block is greater than that of the previous block
and less than 2 hours into the future
3. Check that the proof of work on the block is valid.
4. Let S[0] be the state at the end of the previous block.
5. Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1 ,
set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and
return false.
6. Return true, and register S[n] as the state at the end of this block.
fn. 2