Software Architecture for Blockchain Applications
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
COMP6452 Software Architecture for Blockchain Applications
2023 Term 2
1 Learning Outcomes
In this lab, which also leads to Project 1, you will learn how to write a smart contract using Solidity and
deploy it on the Ethereum testnet blockchain. After completing the lab/project, you will be able to:
• develop a simple smart contract using Solidity
• test your smart contract manually and automatically by issuing transactions and running unit tests
• create and fund your account on the Ethereum testnet
• deploy your contract to the Ethereum testnet
This lab provides step-by-step instructions to develop, test, and deploy your first smart contract.
Then as Project 1, which is graded, you will extend that smart contract to fix several defects and add
additional functionality.
2 Introduction
Smart contracts are user-defined code deployed on and executed by nodes in a blockchain. In addition to
executing instructions, smart contracts can hold, manage, and transfer digitalised assets. For example, a
smart contract could be seen as a bunch of if/then conditions that are an algorithmic implementation of
a financial service such as trading, lending, and insurance.
Smart contracts are deployed to a blockchain as transaction data. Execution of a smart contract
function is triggered using a transaction issued by a user (or a system acting on behalf of a user) or
another smart contract, which was in turn triggered by a user-issued transaction. A smart contract
does not auto-execute and must be triggered using a user-issued transaction. Inputs to a smart contract
function are provided through a transaction and the current state of the blockchain. Due to blockchains’
immutability, transparency, consistency, and integrity properties, smart contract code is immutable and
deterministic making its execution trustworthy. While “code is law” [1] is synonymous with smart
contracts, smart contracts are neither smart nor legally binding per the contract law. However, they can
be used to execute parts of a legal contract.
While Bitcoin [2] supports an elementary form of smart contracts, it was Ethereum [3] that demon-
strated the true power of smart contracts by developing a Turing complete language and a run-time
environment to code and execute smart contracts. Smart contracts in Ethereum are deployed and exe-
cuted as bytecode, i.e., binary code results from compiling code written in a high-level language. Bytecode
runs on each blockchain node’s Ethereum Virtual Machine (EVM) [4]. This is analogous to Java bytecode
executing on Java Virtual Machine (JVM).
Solidity [5] is the most popular smart contract language for Ethereum. Contracts in Solidity are
like classes in object-oriented languages, and contracts deployed onto the blockchain are like objects.
A Solidity smart contract contains persistent data in state variables, and functions that can access and
modify these state variables. A deployed contract resides at a specific address on the Ethereum blockchain.
Solidity is a high-level, object-oriented language that is syntactically similar to JavaScript. It is statically
typed and supports inheritance, libraries, and user-defined types. As Solidity code is ultimately compiled
into Ethereum bytecode, other blockchain platforms that support the EVM, such as Hyperledger Besu,
can also execute it.
Fig. 1 shows the typical development cycle of a smart contract. Like any program, it starts with
requirement analysis and modelling. State diagrams, Unified Modelling Language (UML), and Business
1
Process Model and Notation (BPMN) are typically used to model smart contracts. The smart contract
code is then developed using a suitable tool ranging from Notepad to sophisticated IDEs. Various libraries
and Software Development Kits (SDKs) may be used to minimise errors and enhance productivity. De-
pending on the smart contract language, code may also need to be compiled, e.g., Solidity. Smart contract
code and results must be bug-free because they are immutable and transparent.
Requirement
Analysis &
Modeling
State
Action
Development
Testing (Local
& Testnet)
Deployment Execution
Figure 1: Smart contract development cycle.
Because transactions trigger smart contract functions, we need to pay fees to deploy and execute
smart contracts on a public blockchain. In Ethereum, this fee is referred to as gas. More formally, gas is
a unit of account within the EVM used in calculating a transaction’s fee, which is the amount of Ether
(ETH) a transaction’s sender must pay to the miner who includes the transaction in the blockchain. The
amount of gas needs to execute a smart contract depends on several factors such as the computational
complexity of the code, the volume of data in memory and storage, and bandwidth requirements. There
is also a cost to deploy a smart contract depending on the length of the bytecode. Therefore, it is essential
to extensively test and optimise a smart contract to keep the cost low. The extent that one can test (e.g.,
unit testing), debug, and optimise the code depends on the smart contract language and tool availability.
While Ethereum has a rich set of tools, in this lab, we will explore only a tiny subset of them.
Most public blockchains also host a test/development network, referred to as the testnet, that is
identical in functionality to the production network. Further, they usually provide fast transaction
finality and do not charge real transaction fees. It is highly recommended to test a smart contract on
a testnet. Testnet can also be used to estimate transaction fees you may need to pay in the production
network.
Once you are confident that the code is ready to go to the production/public blockchain network, the
next step is to deploy the code using a transaction. Once the code is successfully deployed, you will get
an address (aka identifier or handler) for future interactions with the smart contract. Finally, you can
interact with the smart contract by issuing transactions with the smart contract address as the recipient
(i.e., to address). The smart contract will remain active until it is disabled, or it reaches a terminating
state. Due to the immutability of blockchains, smart contract code will remain in the blockchain even
though it is deactivated and cannot be executed.
This lab has two parts. In part one (Section 3 to 8), you will develop, test, and deploy a given smart
contract to the Ethereum Sepolia testnet by following step-by-step instructions. Part two (Section 9) is
Project 1 where you will update the smart contract and unit tests to fix some of its functional weaknesses,
and then deploy it onto the testnet. You are not expected to complete this handout during tutorial/lab
time. Instead, you will need additional time alone to complete the lab and Project 1. Tutors will provide
online and offline support.
3 Developing a Smart Contract
In this lab, we will write a smart contract and deploy it to the public Ethereum Sepolia testnet. The
motivation of our Decentralised Application (DApp) is to solve a million-Dollar question: Where to have
lunch?
The basic requirements for our DApp to determine the lunch venue are as follows:
1. The contract deployer SHOULD be able to nominate a list of restaurants r to vote for.
2. The contract deployer SHOULD be able to create a list of voters/friends v who can vote for r
restaurants.
3. A voter MUST be able to cast a vote only once.