Corda R3 — Understanding States, Contracts and Flows

There are three main components for a corda application (cordapp): Workflows, Contracts and States.

States

Each state contains the information that we want to store into the ledge. This state is then encrypted and saved in a way that we can not modify it’s content. After a state is saved into the ledger it can only be read or evolve. Read basically means a query to the ledge and find that state, evolve can be a little more tricky to understand because as we just said a state can not be modified, but we can create a new state that represents the same state but with modifications. For instance an update to a bank account balance. Will have a beginning state representing the Account creation state and all states representing cash in and cash out of that bank account that has originated on the previous state.

So how do we know which state is the most recent? Corda goes a step further and marks previous states as consumed. Which means, that a consumed state can not evolve, then safeguarding the system of evolving the same state twice, which could generate loss of data integrity.

Contracts

A Contract represents a way to verify if a certain operation is valid to be accepted into the ledge. a contract may address size and content verifications. For instance, in a bank transfer at least two accounts balances are updated, the origin and destination account.

A contract is responsible to verify that at least two old states are present (one for origin and one for destination) and two new states are present (one for origin and one for destination). The contract also has the responsibility to verify that the balance difference from the two origin accounts is the same in absolute values for the two destination accounts, if it’s not or we are adding more money to the destination or adding less, in any case money is appearing from nowhere or disappearing and that is loss of integrity. So if any verification fails to pass at the contract level an error must be thrown and the transaction is ended with no values stored into the ledger.

A contract must also be responsible for verifying that the stakeholders of this transaction have signed the transaction, else a transaction is not valid to be stored.

Workflows

So how do we bind a state with a contract? That’s when a workflow comes into play, a flow is initiated by a client via remote procedure call or another flow, in any case, a flow may fetch states from the ledge, create a new state from the old one (evolve a state) and call a contract to verify if the proposed states are valid. Before saving the new states, the workflow must collect the required signatures, hence calling the stakeholder parties for their signatures, which they will verify if the data is correct and sign it. then the new states are eligible to be stored.

DBanking States

For our dapp we need to create a state to represent what each node/bank owns on our ledge. we will use a wallet to represent that.

WalletState attributes:

  • ID so we can differentiate a wallet from another.
  • Owner party, which will tell us who’s node is the owner of this wallet.
  • Creation date, representing the date this wallet was first created and inserted into the ledge.
  • Status, representing the status of this wallet

For now we only need this, but we probably will modify this state as time goes on.

Account attributes:

  • ID so we can differentiate an account from another.
  • Owner wallet, which will tell us who’s node is the owner of this account.
  • Currency, the currency this account is handling (EUR, GBP, BTC, XRP or another).
  • Balance, the amount the current account holds.
  • Creation date, representing the date this account was first created and inserted into the ledge.
  • Movements, an account have a list of movements representing this account credit and debits.
  • Status, representing the current status of this account, and check if it’s able to receive or transfer {ACTIVE, INACTIVE, DELETED}

Movement attributes:

  • ID so we can differentiate a movement from another.
  • Owner account, which will tell us who’s account is the owner of this movement.
  • Other account, which will tell us who’s account is the origin/destination of the amount moved on this transfer.
  • Amount, how much was moved.
  • Type, was this movement a credit or debit.
  • Date, when this movement was executed and accounts balances were updated.

Transfer attributes:

  • ID so we can differentiate a transfer from another
  • Origin Account, the account for debit movement.
  • Destination Account, the account for the credit movement.
  • Status : {SUCCESS, REQUESTED, ERROR}
  • Creation Date, representing the date this transfer was first created and inserted into the ledge.
  • Executed Date, representing the date this transfer was executed. An executed transfer might end up on SUCCESS state or ERROR state.
  • Amount, the amount being transferred.

Master In Software Engineering and Android Engineer at Busuu, with a great passion for technologies, programming and photography.