Modelling with statuses
An underlying assumption of CDL is that the states in the smart contract can have different statuses and that in different statuses you need to define the different form that a transaction can or must take.
This is similar to a Finite State Machine in computer science. The classic example of which is a clothes washing machine that has two states, Full of water and Empty. The washing machine’s Finite State Machine should have the constraint that the user can only execute the Open door command when the washing machine is in the Empty State. If it doesn’t, somebody is going to end up with a very wet floor.
So statuses become a key driver of Smart Contract behaviour.
For example, you may wish to represent a smart contract made up of a
CashContract using a single status:
This shows a
CashState with its properties and participants. It then shows the various constraints imposed on that
CashState by the
- Which contract commands can be used in transactions.
- Who must sign the transaction when each command is used.
- The number of input and output states allowed for each transition.
- The specific rules which operate for the ‘Pay’ Command.
In practice, the status would likely not be included in the diagram.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.