Bitcoin transactions versus smart contract transactions
In Bitcoin, all the transactions are about sending value (Tx(sendValue)). In the case of a blockchain that supports smart contracts, a transaction embeds a function implemented by the smart contract. In figure 1, this function is a voting smart contract. The functions are validateVoter(), vote(), count(), and declareWinner(). The invocation of these functions results in the transactions that will be recorded on the blockchain (Tx(validateVoter), Tx(vote), and so on). This ability to deploy an arbitrary logic on a blockchain significantly enhances its applicability beyond simple cryptocurrency transfers.
What does a smart contract do
The smart contract acts as the brain of a blockchain application. Like the human brain, it is responsible for many vital functions, including the following:
- It represents a business logic layer for verification and validation of application-specific conditions.
- It allows for the specification of rules for operations on the blockchain.
- It facilitates the implementation of policies for the transfer of assets in a decentralized network.
- It embeds functions that can be invoked by messages or function calls from participant accounts or other smart contract accounts. These messages and their input parameters, along with additional metadata such as the sender’s address and timestamp, result in transactions recorded in the distributed ledger of the blockchain.
- It acts as the software-based intermediator for decentralized blockchain-based applications.
- It adds programmability and intelligence to the blockchain through the specification of the parameters of its functions.
With all these crucial capabilities, a smart contract is indeed a core component of the decentralized blockchain application.
Design of a smart contract
DESIGN PRINCIPLE 1 Design before you code, develop, and deploy a smart contract on a test chain, and thoroughly test it before you deploy it on a production blockchain, because when the smart contract is deployed, it is immutable.
DESIGN PRINCIPLE 2 Define the users of and use cases for the system. Users are entities that generate the actions and the input and receive the output from the system you’ll be designing.
DESIGN PRINCIPLE 3 Define the data assets, peer participants and their roles, rules to be enforced, and transactions to be recorded for the system you’ll be designing.
DESIGN PRINCIPLE 4 Define a contract diagram that specifies the name, data assets, functions, and rules for execution of functions and access to the data.
Development of a smart contract code
uint, int, int256, and uint256 are aliases of one another.
