SMART

CONTRACTS
Industry Use Cases Using Blockchain
 SMART CONTRACTS
 Due to benefits such as the increased security, reliability, decentralization,
cost-saving, and transparency that smart contracts can bring to many
industries (especially the finance industry), smart contracts are seen as a
technology that has the potential to change billions of lives.
 Historically, we are used to agreements and contracts made between
individuals or businesses. Historically, we had contracts written on stone,
wood, and paper.
 Then in the computer age, digital contracts appeared. However, digital
contracts are centralized and not reliable. A powerful entity could force its
way out of the contract prematurely, influence the contract and its parties in
one way or another, or not keep up with their side of the bargain.
Furthermore, they are only legally enforceable, and malicious parties can
sometimes mislead the legal system.
 However, with the advent of blockchain, decentralized, more secure, and
automatically enforceable contracts have come into existence where no
single party can deviate or exert power to influence the performance of the
contract.
 SMART CONTRACTS
 Nick Szabo first theorized smart contracts in the 1990s, in an article called
Formalizing and Securing Relationships on Public Networks. This theory was
presented almost 20 years before the real potential and benefits of smart
contracts were appreciated, that is, before the invention of Bitcoin and the
subsequent development of other more advanced blockchain platforms, such as
Ethereum.
 A smart contract is an electronic transaction protocol that executes the terms of a
contract. The general objectives are to satisfy common contractual conditions
(such as payment terms, liens, confidentiality, and even enforcement), minimize
exceptions both malicious and accidental, and minimize the need for trusted
intermediaries. Related economic goals include lowering fraud loss, arbitrations
and enforcement costs, and other transaction costs.
A smart contract is a secure and unstoppable computer program
representing an agreement that is automatically executable and
enforceable.
 So, fundamentally, a smart contract a computer program that is written in a
language that a computer or target machine can understand. It also necessitates
a few requirements for a smart contract to work effectively.
 PROPERTIES OF SMART

CONTRACTS
Automatically executable: It is self-executable on a blockchain when certain
conditions satisfy coded instructions without requiring any intervention.
 Enforceable: This means that all contractual terms perform as specified and
expected, even in the presence of adversaries. (Smart contracts are self-
enforcing as opposed to legally enforceable.)
 Secure: This means that smart contracts are tamper-proof (or tamper-
resistant) and run with security guarantees. The underlying blockchain usually
provides these security guarantees; however, the smart contract programming
language and the smart contract code themselves must be correct, valid, and
verified.
 Deterministic: The deterministic feature ensures that smart contracts always
produce the same output for a specific input. This property will allow a smart
contract to be run by any node on a network and achieve the same result. If
the result differs even slightly between nodes, then a consensus cannot be
reached, and a whole paradigm of distributed consensuses on the blockchain
can fail. Moreover, it is also desirable that the contract language itself is
deterministic, thus ensuring the integrity and stability of smart contracts.
 PROPERTIES OF SMART

CONTRACTS
Semantically sound: This means that they are complete and
meaningful to both people and computers.
 Unstoppable: This means that adversaries or unfavorable conditions
cannot negatively affect the execution of a smart contract. When the
smart contracts execute, they complete their performance
deterministically in a finite amount of time.
 The first four properties are required as a minimum, whereas the latter
two may not be necessary or applicable in some scenarios and can be
relaxed. For example, a financial derivatives contract does not, perhaps,
need to be semantically sound and unstoppable but should at least be
automatically executable, enforceable, deterministic, and secure.
 SMART CONTRACTS TEMPLATES
 Smart contracts can be implemented in any industry where they are
required, but the most popular use cases relate to the financial sector.
 Christopher D. Clack et al. proposed this idea in their paper
published in 2016, named Smart Contract Templates: foundations,
design landscape and research directions. (1608.00771)
 The paper suggested that Domain-Specific Languages (DSLs) should
be built to support the design and implementation of smart contract
templates. A language named Common Language for Augmented
Contract Knowledge (CLACK) has been proposed. This language is
intended to be very rich and is expected to provide a large variety of
functions, ranging from supporting legal prose to the ability to be
executed on multiple platforms and cryptographic functions.
 Apart from DSLs, there is also a growing interest in using general-
purpose, already-established programming languages like Java, Go, and
C++ to be used for smart contract programming.
 SMART CONTRACTS TEMPLATES
 The high-level language code can then be compiled into a low-level
bytecode for execution on the target platform.
 There are already some examples of such systems, such as in EOSIO
blockchains, where C++ can be used to write smart contracts, which
are compiled down to the web assembly for execution.
 An inherent limitation of smart contracts is that they are unable to
directly access any external data. The concept of oracles was introduced
to address this issue.
 ORACLES
 Oracles are an essential component of the smart contract and
blockchain ecosystem.
 The limitation of smart contracts is that they cannot access external
data because blockchains are closed systems, without any direct access
to the real world.
 This external data might be required to control the execution of some
business logic in the smart contract, for example, the stock price of a
security product that is required by the contract to release dividend
payments.
 In such situations, oracles can be used to provide external data to smart
contracts.
 An oracle can be defined as an interface that delivers data from
an external source to smart contracts. Oracles are trusted entities
that use a secure channel to transfer off-chain data to a smart contract
 ORACLES
 Depending on the industry and use case requirements, oracles can
deliver different types of data ranging from weather reports, real-world
news, and corporate actions to data coming from an Internet of Things
(IoT) device.
 A generic model of an oracle and smart contract ecosystem with various
data sources is as shown:
COMMON USE CASES OF ORACLES
 ORACLES
 There are different methods used by oracles to write data into a
blockchain, depending on the type of blockchain used.
 For example, in a Bitcoin blockchain, an oracle can write data to a
specific transaction, and a smart contract can monitor that transaction
in the blockchain and read the data.
 Other methods include storing the fetched data in a smart contract’s
storage, which can then be accessed by other smart contracts on the
blockchain via requests between smart contracts depending on the
platform.
 For example, in Ethereum, this can be achieved by using message calls.
ORACLE’S WORKING MECHANISM
 A smart contract sends a request for data to an oracle.
 The request is executed, and the required data is requested from the source.

There are various methods of requesting data from the source. These methods usually
involve invoking APIs provided by the data provider, calling a web service, reading from
a database (for example, in enterprise integration use cases where the required data
may exist on a local enterprise legacy system), or requesting data from another
blockchain. Sources can be any external off-chain data provider on the internet or in an
internal enterprise network.
 The data is sent to a notary to generate cryptographic proof (usually a digital
signature) of the requested data to prove its validity (authenticity). Usually,
TLSNotary is used for this purpose (TLSNotary). Other techniques include
Android proofs, Ledger proofs, and trusted hardware-assisted proofs
 The data with the proof of validity is sent to the oracle.
 The requested data with its proof of authenticity can be optionally saved on a
decentralized storage system, such as Swarm or IPFS, and can be used by the
smart contract/blockchain for verification. This is especially useful when the proofs
of authenticity are large and sending them to the requesting smart contracts
(storing them on the chain) is not feasible.