Page 34 - MSDN Magazine, September 2018

Figure 3 Declaration of Roles, State and Properties in the Betting Smart Contract
As shown in Figure 5, the implementation of this smart con- tract in Solidity requires that several functions be defined for each action of the workflow, as follows:
• The constructor stores the message sender as the gambler; this is the role that initiates the smart contract.
• The Bet function accepts an amount as input, performs some validation (this function can be called only by the gambler and the amount should be more than zero), and then trans- fers the bet amount to the contract. To allow for on-chain currency transfers, it’s necessary to flag a function as payable.
• The Won function, after validating that the invoker isn’t the gambler, transfers the won amount to the gambler and closes the bet as “Won.”
• The Lost function, which again can only be invoked by the bookmaker, transfers the amount initially bet, and now lost by the gambler, to the bookmaker and closes the bet as “Lost.”
• By closing a bet, the gambler is removed (its address is set to 0x0) and the amount set to zero, ready for another bet.
A smart contract should have a single responsibility and contain as little business logic as possible—optimally only the validation logic needed to deem a contract valid or not.
Though simple in implementation, this scenario identifies a typical pattern for managing monetary spending in a blockchain application. Other scenarios may need to incorporate attestable files, such as doc- uments, spreadsheets, certificates and pictures. For multiple reasons, mainly concerning storage limitation, it’s inappropriate to put files on a blockchain. A common approach is to perform a cryptographic hash (for example, SHA-256) against a file and share that hash on a distributed ledger. The external system would instead persist the file into a storage mechanism, such as Azure Storage or IPFS (ipfs.io).
Performing the hash again with the same hashing algorithm at any future time will return the same result, unless the persisted file was modified—even if just one pixel is modified in an image. This process grants proof of existence that an information object like
pragma solidity ^0.4.20;
contract Betting {
// Roles
address public Gambler; address public Bookmaker;
// State
enum BetType { Placed, Won, Lost } BetType public State;
// Properties
uint public BetAmount;
contracts in Solidity are similar to classes in object-oriented languages. Each contract contains roles, state and functions to implement actors, stages and actions of a business process.
The code snippet in Figure 3 shows the different types of vari- able declaration in Solidity for roles, state and properties that may be used in a smart contract for a betting application. Roles (the gambler and the bookmaker) are defined as address, which is the unique identifier of a user or contract in Ethereum. State is an enumeration of labels that identifies the current state of a bet placed via the smart contract. Functions, as you’ll see later, define a change of state. The bet amount is expressed as an unsigned number (currently, Solidity doesn’t support decimal values).
Please note the indication of the version of Solidity that I’m target- ing for this smart contract. It’s good practice to indicate this pragma instruction to avoid incompatibilities with future versions of the Solidity programming language and compiler. This also helps identify old code in a smart contract, which may need to be replaced with a new version to support updated code. The process of removing an existing smart contract from a blockchain is called “self-destruct.”
A smart contract should have a single responsibility and contain as little business logic as possible—optimally only the validation logic needed to deem a contract valid or not. In my betting appli- cation, a smart contract may expose functions for placing a bet by the gambler, and acknowledging win or loss by the bookmaker. Currency may be exchanged between the two roles, as part of the bet workflow. The usual pattern for monetary transactions that require validation by a contract sees the amount transfer happen- ing in two phases, as indicated in Figure 4. The gambler (initiator of the contract) places a bet for a certain amount, which is then stored in the smart contract. If the bet is won, the won amount, indicated by the bookmaker, is transferred to the gambler. Other- wise, the bookmaker cashes the bet amount.
an email, file, document, phone call or video existed at a certain point in time. It also grants proof of authenticity— you know a digital asset hasn’t changed because the digital ledger stores immut- able and independent, verifiable records of all transactions. For more on the value of blockchain in enterprise content management, read the post I published at bit.ly/2OC2Ycp.
Microservices
Gambler Bet Transfer
Bet Amount
Won Amount
Transfer
Won
Smart Contract
Bookmaker
Transfer Lost Lost Amount
State
Figure 4 Betting Workflow 26 msdn magazine