SDLC for BlockChain solution -2

Across each of the three point-of-view in block-chain solution development, I observed play of three different models namely user-persona model, business flow model and Finite State Machine model. Here, Finite State machine model is related more with smart contracts

User-persona model
Conceptualize new system as dynamical systems of interacting users. Aligned more to Computation point-of-view, and helps to capture set of unique users of the system, that encapsulate the behaviors of the various individuals that make up the system, and the execution consists of emulating these behaviors. Capture the behavior of each user through sets of statements in which the behavior becomes explicit

• Explain persona’s characteristics or attributes
• What is the user-persona relationship to action here?
  • Are there scenarios for the same user, is the action optional, permitted or denied?
• What is the action or outcome that the statement regulates in this scenario?
• What are the contextual conditions under which the statement holds?
• What are the consequences of non-conformance to the above statement?

This helps to identify inter-dependencies between different human activities in a system. From smart contract perspective, one can try to map from the statements to the skeleton contract. End-user perspective facilitate easy review and feedback from domain experts and non-technical people and also ensure that no crucial functionality is forgotten.

Business Flow model
Conceptualize business workflows that are going to leverage block-chain and help to strengthen specification of smart contract. . Aligned with Computation point-of-view.

Smart contracts are used to address the lack-of-trust problem in collaborative business processes across organizations. Smart contract can be deployed to strengthen trust of business process workflow by providing an automated and immutable transaction history, being a mediator in the process control logic, and facilitate to create an audit trail for the complete collaborative business processes.

• When one takes business process specification as input and generates smart contract, one may not know which user persona is assigned which role. But the smart contract needs to have this information for instantiating the process.
• Each Business process needs to iterated through, and for all elements a list of the previous and the next elements needs to be determined. Each element is then translated to Solidity with its respective links.
• Some business process need to follow a certain pattern but does involve more steps and this needs to be capture.

Finite State Machine model(FSM)

FSM model is more aligned to Platform independent point-of-view.  Smart contracts are considered to act as state machines. A smart contract is in an initial state and a transaction transitions the contract from one state to the next. You also find that Solidity specification describes the possibility of smart contracts as state machines. it helps developers to understand FSM model for smart contracts.

• Provide a formal model with clear semantics in which smart contracts can be modelled, which decreases the semantic gap and eliminates issues arising from it.
• The clear semantics allows the connection from its framework to formal analysis tools.
• Following state diagram enables developers to implement smart contracts with a minimal amount of error-prone manual coding.

An FSM should contain an initial state, a finite set of states, and a set of transitions between these states. The transitions are activated once certain conditions, called guards, are met. Effectively smart contract has states, and in these states, functions allow users or other triggers to change the state

• This mathematical model of computation can be in exactly one of a finite number of states at any given time.
• The FSM changes state in response to external inputs or to a specified timed transition. It consists of a list of its states, its initial state, and a collection of conditions for transitions.

Quoting formal definition. An FSM is made up of a set of states and a definition of a set of transitions between these states . A formal definition of the FSM is a tuple (S, S0, T, C), where:

• S is a finite set of states: A state is a particular moment the FSM can be in. Functions are provided to invoke actions and change between these states.
• S0 is the initial state: The starting state of the FSM;
• T is the set of transitions: A transition forces the FSM to take a set of actions if the associated conditions, called guards of the transition, are satisfied.
• C is the set of conditions: The conditions or guards which are associated to the transitions, which when they are met can invoke the change between states.

Using FSM, the domain expert knows what concepts should be included in the smart contract and the developer has the know-how to translate these domain concepts into technology concepts

Finite state model captures following high-level definitions and also enables review  FSM  and to independently evaluate FSM for correctness and completeness.

1. Define name of the FSM NAME
2. Define initial state
3. Define set of states
4. Define final state
5. Define set of transitions

For each transition, FSM model also allows to capture minimal transaction attributes.

• Identify name of the transition
• Identify guard conditions of the transition
• Identify input variables of the transition
• Identify statements of the transition
• Identify output of the transition
• Identify previous state
• Identify next state

Solidity code that runs in Ethereum allows a smart contract to be a state machine.

1. Enum, is a user-defined type in Solidity. An enum is used to create a list with the set of states. This enum will be used to keep track of which state the smart contract is in.
2. The functions, which are used to transition between the states.
3. Modifiers used to define the conditions for a transition between states. Once Modifiers are defined, they can be reused throughout the contract, allowing for the definition of certain patterns

Sharing some of my observations with respect to smart contracts in Ethereum during software development.

• The programming of smart contract parallels a lot of characteristics of event-driven programming, in which program  flow is determined by events. Examples of events are for instance user input, variable triggers like elapsed time, or other programs/contracts triggering it.
• Every node in the network need not permitted to control all functionalities of a contract. Hence transitions (or functions) can be restricted to be only accessible to a certain address. [ access control]. The node deploying contract is marked as owner and has restrictive rights.
• Risk of undesired loop when a smart contract function is called within another smart contract function. While code reviews can help to detect undesired loop, we explore a principle called locking to handle this vulnerability. It is a modifier which first checks if the contract is locked. If not, it is locked, the transition is executed, and after execution, it is unlocked again. This way, functions in the contract cannot be nested within each other in any way [prevent locking].
• Due to the decentralized nature, when a user calls a function, invoker is not sure about the state of the contract. This is a challenge for smart contracts, as multiple users may invoke a contract at the same time and the order of the execution of these functions is unknown. To handle this, contract can implement a transition counter, which enforces a strict ordering on function executions.
  • For every invocation of the contract, the user is asked for a transition number as input. This transition number is incremented with one after each function execution. This way the user can be sure that the function executes before any other state change happens. This mitigates against vulnerabilities due to ordering dependence and minimizes exceptions due to unpredictable states.
• By treating smart contract as a state machine, the timed transition is a transition that may occur multiple times. This transition does not have input or output but do have a number specifying the time.
  • If smart contract has a lot of timed transitions, implement a modifier. This modifier checks before every transition if a timed transition must be executed before the transition. If so, the timed transition will be executed if the time limit has been reached.
• For every transition, a function is made. There is a check if the contract is in the right state, and hereafter the guards and statements are fired. The guards are the conditions described and need to be fulfilled in order for the function to be executed.