Currently the aim of the project is mostly focused on the investigation of the inner-workings of the consensus algorithms, so as of now the sate machines are fairly simple. This may change over time.
Several simple state machines are implemented for testing found in the statemachine folder. They are broken down into two main categories: those that require a total order of operations, and those that are causally ordered. The state machines must follow an interface defined in state_machine_interface.go. See the godocs for more details on their construction.
While the total ordered state machines eventually create a total order, before each value coming from the consensus is finalized, there may be concurrent instances executing at the same index in the total order. This is in order to support to algorithms like MVCons3 where several instances may take place concurrently with some or none of them actually being committed. This does make the interfaces more complex, and the copywritemap was created to help simplify these implementations.
Another thing to note is that when using MVCons3, keeping the implementations correct is also more complicated. For example if a not yet finalized state creates a side-effect then the system needs to be aware of this and handle this. For example a client may see that a value has been sent to him, and creates a new transaction as a result, but then the value sent to him is aborted later. Of course this can be avoided with careful design of the state machine. Otherwise, the simplest way to avoid this is to not make values visible until they are finalized, but then you are loosing some of the benefits of the consensus algorithms that are constructed in this way.
Note that the currency based state machine suffers for this issue when using MVCons3, and can be used as an example of how things can go wrong.
The current total ordered state machines are as follows:
- SimpleProposer - just for unit tests.
- BinaryProposer - propose a random binary value.
- CounterProposer - each consensus instances increments the counter by 1.
- MultivalueProposer - propose a random string of bytes.
- SimpleTxProposer - Basically to test a transaction pool, transactions increment a counter by a random amount.
- CurrencyProposer - A simple crypto currency like SM. Transactions are signed sending value from one account to another. Initial state is loaded from an encoded file. For this transactions are generated by a local process and put in a transaction pool. As of now there is no mechanism for external nodes to propose transactions (TODO see issue #4). Note that this can be used with the CurrencyMemberChecker so that consensus members are chosen based on how currency they have to simulate proof of stake, this is just a simple example and not meant to be safe.
For these SMs each decided value is causally ordered with those that go before it. Of course this case is less powerful and more difficult to create correct SMs than with a total order. Here their construction is mainly based on cryptographic hashing, which is used to make unique identifiers for each item in the causal order.
The current causally ordered state machines are as follows:
- CausalCounterProposer - Count values. This is only for testing the underlying broadcast or consensus protocols. Here there is only a single agreed upon node that will do the proposing in order, so it creates a totally ordered count.
- AssetProposer(Direct) - Each participant is assigned a set of initial assets each with a unique name. The assets are then transferred from one participant to another.
- AssetProposer(Value) - This implements a simple crypto currency except where transfers are causally ordered using an asset like construction.