The state machine replication helps us to achieve a consensus in a permission model. We do not need to execute a smart contract to all the nodes. Rather, the selected subset of contract executor executes it and propagates it with other nodes to ensure the contract’s status is propagated to all the nodes uniformly in the network, and they are on the same page. The distributed state machine replication technology ensures consensus in a permission blockchain environment.
Understanding of State Machine Concept
State Machine is characterized by a set of parameters such as set of Inputs, set of Outputs, and the Transition States.
- A set of state (S) based on the system design
- A set of inputs (I)
- A set of outputs (O)
- A transition function S x I –> S; takes the current state and input value and produces a set as the output.
- A output function S x I –> O
- A start state
Example of State Machine: Smart Contract – Crowd-Funding
In general any algorithm can be represented by the finite state machine and we will understand it with an example of Crowdfunding platform in smart contract. The smart contract state machine representation are as follows:
In the crowdfunding platform, there are mainly two parties which include the project proposes and project funders. The project proposers propose the project to the funders, and if they are interested, they will invest money in their project. The funders will release funds after the completion of a certain job. In the above diagram, Alice and Bob are the two funders, and they are transferring money after completing the proposed jobs by the proposers. Once the entire job is completed, money will be transferred to them.
Distributed State Machine Replication Mechanism
In a typical distributed architecture, the distributed state machine replication mechanism work in the following way.
It has multiple distributed servers which work independently in a distributed fashion. Initially, copies of the state machine are placed on each server that resides in the closed network, assume that each server knows the information about other servers.
In the distributed setup, it may be possible that different users are communicating to different servers. The servers get the client’s request independently. In our example, Alice and Bob are two clients who are transferred their share of money via the distributed network. However, at this moment, this information is locally stored in the connected servers. The end goal is to ensure that all three servers reach the same state after a certain time. i.e., Each server must have information about Alice and Bob have transferred their share of the money.
To achieve this, the state machine replication mechanism works in this principle that, individually, all the servers propagate their state to others. However the problem is to understand ordering or sequences in which requests came from the users.
This can be achieved using the timestamp concept. So, whenever Alice and Bob are making the transactions, the transactions are associated with the timestamp. This way, information will be executed in each server in that particular ordering algorithm. Consequently, all will execute in the same order in which it was support to be executed. This way, all servers are reaching the same state.
Once execution is finished, then the states should be propagated in the entire network. It might be possible that one of the servers was offline due to some failure. This way, all the servers will have a state copy. So that update is done through synchronization of the state machine.
At the end, there will be certain outputs and those outputs will be updated to clients.
In the entire procedure, there are two glitches. The first one is that we need to maintain ordering in service, and the second is that in the presence of failure, the system needs to ensure that all the individual servers are on the same page. From our example, in the end, all the three servers must know that Alice and Bob had shared their money, and money has been transferred to the recipient.
Why do we apply the state machine replication-based consensus algorithm in a permissioned model compared to the challenge-response-based consensus algorithm in the permissionless model?
There is a natural reason to use state machine replication-based consensus over permissioned blockchains are there as follows:
- The network is closed, the nodes know each other, so state replication is possible among the known nodes.
- Avoid mining overhead, do not need to spend anything like power, time, bitcoin other than message passing.
- However, the consensus is still required as machines can be faulty or behave maliciously.
Summary
We have seen and understand with a toy example of state machine replication consensus algorithm in the permissioned model, comparing why state machine replication consensus algorithm is suitable in the permissioned model compared to the challenge-response based consensus algorithm.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
1,672 total views, 1 views today
