Department of Computer Science and Engineering

Blockchain Technology (BCS613A)

Module-3: Introducing Bitcoin

Bitcoin

• Bitcoin was introduced in 2008 through the paper Bitcoin: A Peer-to-Peer Electronic Cash
System, which does not need an intermediary bank to transfer payments between peers, written
by Satoshi Nakamoto.
• It is a peer-to-peer electronic cash system that allows transactions without intermediaries like
banks.
• Bitcoin is based on earlier cryptographic technologies such as Merkle Trees, Hash Functions,
Public Key Cryptography, and Digital Signatures.
• Bitcoin solves the Byzantine Generals' Problem and prevents the double-spending problem.
• The value of Bitcoin has increased significantly since 2011, especially after 2017.
• Growth is driven by the network effect, where more users increase the value of the system.
• Bitcoin has a limited supply (21 million coins), which creates scarcity.
• Mining rewards are reduced (halved) every four years, controlling inflation.
• Bitcoin is the first successful decentralized digital currency combining multiple technologies.
• Its growth depends on user adoption, scarcity, and demand, while regulation remains a major
challenge.

BITCOIN DEFINITION

• Bitcoin can be defined in various ways; it's a protocol, a digital currency, and a platform.
• It is a combination of peer-to-peer network, protocols, and software that facilitate the
creation and usage of the digital currency named Bitcoin.
• Note that Bitcoin with a capital B is used to refer to the Bitcoin protocol, whereas
bitcoin with a lowercase b is used to refer to bitcoin, the currency. Nodes in this peer-
to-peer network talk to each other using the Bitcoin protocol.
• Decentralization of currency was made possible for the first time with the invention of
Bitcoin. Moreover, the double-spending problem was solved in an elegant and ingenious
way in Bitcoin.
• Double-spending problem arises when, for example, a user sends coins to two different
users at the same time, and they are verified independently as valid transactions.

Transactions

Prof. Deepika G , Dept. of CSE, SVIT Page 1

 • Transactions are at the core of the Bitcoin ecosystem.
• Transactions can be as simple as just sending some bitcoins to a bitcoin address, or
they can be quite complex depending on the requirements.
• Each transaction is composed of at least one input and one output. Inputs can be
thought of as coins being spent that have been created in a previous transaction, and
outputs as coins being created.
• If a transaction is minting new coins, then there is no input and therefore no signature
is needed.
• If a transaction is to send coins to some other user (a bitcoin address), then it needs to
be signed by the sender with their private key, and a reference is also required to the
previous transaction to show the origin of the coins.
• Transactions are not encrypted and are publicly visible in the blockchain.
• Blocks are made up of transactions, and these can be viewed using any online
blockchain explorer.

The transaction life cycle

The following steps describe the transaction life cycle:

1. A user/sender sends a transaction using wallet software or some other interface.

2. The wallet software signs the transaction using the sender's private key.
3. The transaction is broadcast to the Bitcoin network using a flooding algorithm.
4. Mining nodes (miners) who are listening for the transactions verify and include this
transaction in the next block to be mined. Just before the transactions are placed
in the block, they are placed in a special memory buffer called the transaction pool.
The purpose of the transaction pool is explained in the next section.
5. Mining starts, which is a process by which the blockchain is secured and new coins
are generated as a reward for the miners who spend appropriate computational
resources. This concept is explained in more detail later in this chapter.
6. Once a miner solves the PoW problem it broadcasts the newly mined block to the
network. PoW is explained in detail later in this chapter.
7. The nodes verify the block and propagate the block further, and confirmations start
to generate.
8. Finally, the confirmations start to appear in the receiver's wallet and after
approximately three confirmations, the transaction is considered finalized and
confirmed. However, three to six is just a recommended number; the transaction
can be considered final even after the first confirmation. The key idea behind waiting
for six confirmations is that the probability of double-spending is virtually
eliminated after three confirmations.

Prof. Deepika G , Dept. of CSE, SVIT Page 2

Transaction fee

• Transaction fees are paid to miners as an incentive to include transactions in blocks.

• Fee is calculated as: fee = sum(inputs) − sum(outputs)
• Higher transaction fees → faster processing (higher priority).
• Transactions are stored in a memory pool; miners pick higher-fee transactions first.
• Fees are not fixed or mandatory in Bitcoin.
• Low or zero-fee transactions may be delayed significantly.
• Confirmation time depends on the fee and network activity (can range from ~10
minutes to several hours).
• Higher fees increase the chances of quicker confirmation.

Transaction pools

• Transaction pools (memory pools) are temporary storage areas in node memory (RAM).
• They store unconfirmed transactions before they are added to a block.
• Transactions enter the pool after verification.
• Miners select transactions from the pool based on priority (e.g., higher fees).

The transaction structure

• A Bitcoin transaction consists of metadata, inputs, and outputs.

• Transactions are grouped together to form a block.
• Metadata includes:

✓ Version number
✓ Transaction size
✓ Number of inputs and outputs
✓ Lock time (when transaction becomes valid)

The transaction data structure is shown in the following table:

Prof. Deepika G , Dept. of CSE, SVIT Page 3

Inputs:

• Refer to previous transaction outputs (called Unspent Transaction Output).

• Each input spends a UTXO.
• Contains:
o Previous transaction hash
o Output index
o Unlocking script (ScriptSig)
o Sequence number

Prof. Deepika G , Dept. of CSE, SVIT Page 4

Outputs:

• Specify where bitcoins are sent.

• Contain:
o Value (in Satoshis)
o Locking script (ScriptPubKey)
• Define conditions required to spend the coins.
• The first transaction in a block is called a Coinbase transaction (creates new coins).
• Verification is done using Bitcoin scripting (locking & unlocking scripts).
• Transaction output data structure is shown here

The Script language

 Bitcoin uses a simple stack-based scripting language called Script to define how bitcoins
are spent.

• It is not Turing complete (no loops) to prevent long or stuck executions.

• Based on Forth-like syntax and uses Reverse Polish Notation (RPN).
• Executed from left to right using a LIFO (Last In, First Out) stack.
• Uses opcodes (instructions) such as arithmetic, logic, cryptography, and flow control.
• Two main script types: ScriptSig (unlocking script) and ScriptPubKey (locking script).
• ScriptSig is provided by the sender to unlock the transaction.
• ScriptPubKey is part of the output and defines conditions to spend coins.
• Transaction works by first unlocking, then validating conditions.
• Ensures secure and authorized spending of bitcoins.

Prof. Deepika G , Dept. of CSE, SVIT Page 5

Commonly used opcodes

All opcodes are declared in the script.h file in the Bitcoin reference client source code
OP_CHECKSIG: Verifies a signature using a public key; returns TRUE if valid, otherwise
FALSE.

• OP_EQUAL: Checks if two values are equal; returns 1 (true) or 0 (false).

• OP_DUP: Duplicates the top item on the stack.
• OP_HASH160: Applies hashing twice (SHA-256 followed by RIPEMD-160).
• OP_VERIFY: Marks transaction invalid if the top stack value is not true.
• OP_EQUALVERIFY: Combines OP_EQUAL and OP_VERIFY (checks equality and
validates).
• OP_CHECKMULTISIG: Verifies multiple signatures against multiple public keys;
returns 1 if all valid, else

Types of transactions

• Bitcoin supports different transaction types using scripts to transfer value securely.
• Standard transactions are checked using validation rules (IsStandard, IsStandardTx)
before being accepted by the network.
• Non-standard transactions are still valid but usually not relayed or mined by nodes.

Pay to Public Key Hash (P2PKH):

• Most widely used transaction type.

• Send bitcoins to a user’s address.
• Uses locking script: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY
OP_CHECKSIG.
• Unlocking requires a signature and a public key.

Pay to Script Hash (P2SH):

• Sends funds to a script instead of a simple address.

• Addresses usually start with “3”.
• Requires a redeem script to unlock funds.
• Makes complex transactions easier and more compact.

Prof. Deepika G , Dept. of CSE, SVIT Page 6

 Multisignature (MultiSig):

• Requires multiple signatures (M-of-N) to spend funds.

• Provides shared control over funds.
• Commonly used for escrow, joint accounts, and security.
• Often implemented using P2SH.

Pay to Public Key (P2PK):

• Older and simple transaction type.

• Uses public key directly instead of a hash.
• Mostly obsolete now; used in early Bitcoin and Coinbase transactions.

OP_RETURN (Null Data Transaction):

• Allows storing small data (up to ~40 bytes) on blockchain.

• Output is unspendable.
• No unlocking script required.
• Script execution involves combining ScriptSig (unlocking) and ScriptPubKey (locking).
• Transactions are processed and then encoded into hexadecimal format before
broadcasting on the network.
• P2PKH is the most common in real-world usage, while P2SH and MultiSig enable
advanced transaction logic.

Prof. Deepika G , Dept. of CSE, SVIT Page 7

🔹 Step-by-Step Execution (Left → Right)

1. Push Signature
o <Sig> is pushed onto the stack
2. Push Public Key
o <PubKey> is pushed onto the stack
3. OP_DUP
o Duplicates the top item (PubKey)
o Stack now has two copies of PubKey
4. OP_HASH160
o Hashes the duplicated PubKey
o Produces PubKeyHash
5. Push Expected PubKeyHash
o <PubKeyHash> from ScriptPubKey is added to stack
6. OP_EQUALVERIFY
o Compares computed hash with expected hash
o If NOT equal → transaction fails
o If equal → continue
7. OP_CHECKSIG
o Verifies signature using the public key
o If valid → TRUE
o If invalid → FALSE

🔹 Final Result

• If all steps pass → ✅ Transaction is valid

• If any step fails → ❌ Transaction is rejected

Coinbase transactions

• A coinbase transaction (generation transaction) is the first transaction in every block,

created by the miner.
• It is used to generate new bitcoins as a mining reward.
• It contains a special coinbase field that acts as input (instead of referencing a previous
transaction).
• Unlike normal transactions, it does not reference any previous transaction.
• It can include arbitrary data (up to 100 bytes).
• The genesis block contains the famous message:
“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”
→ Proof that Bitcoin started on January 3, 2009.

Prof. Deepika G , Dept. of CSE, SVIT Page 8

🔹 Coinbase Transaction Input Structure

• Transaction hash (32 bytes): Set to all zeroes (no previous reference)
• Output index (4 bytes): Set to 0xFFFFFFFF
• Coinbase data length (1–9 bytes): Size of data (2–100 bytes)
• Data (variable): Arbitrary miner data
• Sequence number (4 bytes): Set to 0xFFFFFFFF

🔹 Key Points

• Always the first transaction in a block

• Creates new coins + miner reward
• Does not use normal unlocking scripts
• Unique structure compared to regular transactions

The structure of a block

• A Bitcoin block contains multiple fields that define its structure.

• Block size (4 bytes): Specifies the total size of the block.
• Block header (80 bytes): Contains important metadata (e.g., previous hash,
timestamp, nonce).
• Transaction counter (1–9 bytes): Indicates the total number of transactions in the
block (including coinbase).
• Transactions (variable size): List of all transactions included in the block.

The following table shows the structure of a block

Prof. Deepika G , Dept. of CSE, SVIT Page 9

The structure of a block header

• Blocks are linked using the previous block hash, forming a chain (blockchain).
• This linkage ensures immutability: changing one block requires changing all
subsequent blocks.
• The Genesis Block is the first block and has no previous hash.
• The Merkle root ensures integrity of all transactions in the block.
• Overall structure:
Block → Header + Transactions → Transactions contain scripts
(locking/unlocking)

The following table depicts the structure of a block header:

Prof. Deepika G , Dept. of CSE, SVIT Page 10

 • The diagram shows a high-level view of the Bitcoin blockchain.
• On the left side, blocks are arranged in a chain (top to bottom).
• Each block contains:

✓ Block header
✓ List of transactions

• The block header is expanded to show its components (version, previous hash,
Merkle root, timestamp, etc.).
• The Merkle Tree is highlighted to show how the Merkle root is calculated from
transactions.

Prof. Deepika G , Dept. of CSE, SVIT Page 11

 • Transactions are further broken down to show their structure (inputs, outputs,
metadata).
• Each transaction includes:

✓ Locking script (ScriptPubKey)

✓ Unlocking script (ScriptSig)

• Overall, the diagram connects all layers:

Blockchain → Blocks → Headers → Transactions → Scripts
• It provides a complete overview of how Bitcoin data is structured and linked together.

The genesis block

• The Genesis Block is the first block in the Bitcoin blockchain.

• It is hardcoded in the Bitcoin Core software ([Link]).
• Contains the famous message:
“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”
→ proves the block was created on Jan 3, 2009.
• Bitcoin prevents double-spending through:
o Transaction verification
o Mining using Proof of Work
• Block height = number of blocks before a given block.
• Each block includes:
o Multiple transactions
o First transaction = coinbase (miner reward)
• Coinbase transactions cannot be spent until 100 blocks are added.

🔹 Types of Blocks

• Stale blocks: Blocks mined but not included in the main chain.
• Orphan blocks: Valid blocks later rejected when a longer chain is found.

🔹Forks in Blockchain

• Occurs when two blocks are created at the same time.

• Soft fork:
o Backward compatible
Prof. Deepika G , Dept. of CSE, SVIT Page 12
 o Only miners need to upgrade
• Hard fork:
o Not backward compatible
o All users must upgrade
• Longest chain rule is followed to resolve forks.
• 51% attack: If someone controls the majority of the hash power, they can alter the
transaction history.

🔹 Blockchain Growth & Mining

• New block added approximately every 10 minutes.

• Difficulty adjusts every 2016 blocks to maintain timing.
• Difficulty formula:
Target = Previous Target × (Time / (2016 × 10 minutes))
• Blockchain size grows continuously (e.g., ~139 GB in 2017).

Mining

• Mining = process of adding new blocks to the blockchain.

• Validates transactions and secures the network.
• Based on Proof of Work (PoW).
• Miners solve a mathematical puzzle (find hash < target).
• Resource-intensive (requires high computing power & electricity).

🔹 Block Creation & Rewards

• New block created approximately every 10 minutes.

• Miners receive:

Prof. Deepika G , Dept. of CSE, SVIT Page 13

 oBlock reward (new bitcoins)
o Transaction fees
• Reward halves every 210,000 blocks (~4 years):
o 2009: 50 BTC
o 2012: 25 BTC
o 2016: 12.5 BTC
o 2020: 6.25 BTC
• Total supply limited to 21 million bitcoins (by ~2140).

🔹 Miner Tasks

• Sync blockchain with network

• Validate transactions
• Validate blocks
• Create new block
• Perform PoW (find valid nonce)
• Broadcast block and earn reward

🔹 Proof of Work (PoW)

• Hash condition:
Hash (Block Data + Nonce) < Target
• Requires brute force (trial & error).
• Ensures security and prevents fraud/double spending.

🔹 Mining Algorithm (Steps)

1. Get previous block hash

2. Collect transactions
3. Add nonce and hash block (using SHA-256)
4. Check if hash < target
5. If not, change nonce and repeat

Prof. Deepika G , Dept. of CSE, SVIT Page 14

 6.

🔹 Difficulty & Hash Rate

• Difficulty adjusts every 2016 blocks (~2 weeks)

• Keeps block time ~10 minutes
• Hash rate = number of hashes per second (network speed)
• Higher hash rate → higher difficulty

Prof. Deepika G , Dept. of CSE, SVIT Page 15

🔹 Mining Hardware Evolution

• CPU → GPU → FPGA → ASIC (most powerful today)

• Modern mining requires specialized ASIC machines

🔹 Mining Pools

• Group of miners working together

• Share rewards based on contribution
• Common reward models:
o Pay Per Share (PPS)
o Proportional

🔹 Risks & Issues

• 51% attack: Control of majority hash power can manipulate blockchain

• Mining centralization (large pools dominate)
• High cost → not profitable for individuals

The Bitcoin network

• The Bitcoin network is a peer-to-peer (P2P) system where nodes share transactions
and blocks.
• Two main types of nodes:
o Full nodes: store the entire blockchain and fully validate data
o SPV (lightweight) nodes: store only block headers and verify transactions
• Full nodes perform:
o Transaction validation
o Block validation

Prof. Deepika G , Dept. of CSE, SVIT Page 16

 o Blockchain storage
o Network routing
• SPV nodes:
o Do not store full blockchain
o Use Merkle Tree to verify transactions
o Faster but less secure than full nodes
• Some nodes act only as miners (perform mining tasks).
• Mining pools use Stratum protocol for communication between miners and pool
servers.

• Bitcoin nodes communicate using protocol messages:

o version → start connection
o verack → confirm connection
o inv → advertise data
o getdata → request data
o block / tx → send block or transaction
o getaddr / addr → discover peers

• Node discovery process:

o Uses DNS seeds to find peers
o Default port: 8333 (mainnet)
o Connection setup: version → verack → peer exchange

o
o

Prof. Deepika G , Dept. of CSE, SVIT Page 17

 • Block synchronization methods:
o Old: blocks-first (slow)
o New: headers-first (fast)
o Headers downloaded first, then blocks in parallel

• SPV transaction verification:

o Uses Merkle proof (linking transaction to block)
o Does not require full blockchain

• Bloom filters (BIP37):

o Used by SPV clients to filter required transactions
o Saves bandwidth
o May produce false positives but no false negatives
• Bloom filter messages:
o filterload → set filter
o filteradd → add data
o filterclear → remove filter

Wallets

• A Bitcoin wallet is software used to store private keys, public keys, and Bitcoin
addresses.
• It allows users to send and receive bitcoins.
• Modern wallets often combine both:

Prof. Deepika G , Dept. of CSE, SVIT Page 18

 ✓ Bitcoin client
✓ Wallet functionality

• Wallet data (e.g., [Link]) is stored on disk (e.g., Berkeley DB format).

• Private keys:

o Generated randomly (256-bit number)

o Used to sign transactions

• Wallets do NOT store actual coins.

• In Bitcoin: No physical coins exist , Only transaction records are stored on
blockchain
• Balance is calculated using Unspent Transaction Output (unspent outputs).
• Wallets manage these UTXOs to show user balance and enable spending.
• Different types of wallets exist (software, hardware, etc.) for managing keys and
transactions.

Types of Bitcoin Wallets

Non-Deterministic Wallets

• Also called “just a bunch of keys” wallets

• Private keys are randomly generated
• Difficult to manage many keys
• Requires frequent backups
• Risk of loss or theft if keys are not stored securely

Deterministic Wallets

• Keys are generated from a single seed value

• Seed is represented using mnemonic words (BIP39)
• Easy to backup and recover
• All keys can be restored using the seed phrase

Hierarchical Deterministic (HD) Wallets

• Defined in BIP32 & BIP44

• Keys are organized in a tree structure
• One master key → generates many child keys
• Entire wallet can be recovered from one seed
• Easy to manage and highly portable

Prof. Deepika G , Dept. of CSE, SVIT Page 19

 Brain Wallets

• Private key generated from a memorized password

• No need to store keys physically
• Vulnerable to brute-force attacks
• Security depends on strength of password

Paper Wallets

• Keys printed on paper

• Stored offline (cold storage)
• Requires strong physical security
• Risk of loss or damage

Hardware Wallets

• Keys stored in tamper-resistant devices

• Very high security
• Examples: Trezor Wallet, Ledger Wallet
• Protects against hacking and malware

Online Wallets

• Stored on cloud/web services

• Easy to use and access
• Requires trust in service provider
• Less secure than hardware wallets

Mobile Wallets

• Installed on smartphones
• Supports quick payments (QR codes)
• Balance of convenience and security
• Popular for daily use.

Smart Contracts

• Smart contracts are programs that automatically execute agreements when

conditions are met.
• The concept existed earlier but gained popularity with blockchain technology.
• They run on blockchain, making them decentralized and tamper-resistant.
Prof. Deepika G , Dept. of CSE, SVIT Page 20
 • Eliminate the need for intermediaries (e.g., banks, lawyers).
• Help reduce transaction costs and improve efficiency.
• Useful for handling complex agreements automatically.
• Widely researched by industries and academic institutions.
• Aim: make contract execution secure, transparent, and automated.

History

• Smart contracts were first proposed by Nick Szabo in the late 1990s.
• Introduced in his article Formalizing and Securing Relationships on Public Networks.
• Definition:
o A smart contract is a digital protocol that automatically executes contract
terms.
o Aims to enforce agreements without intermediaries.
• Key objectives:
o Automate contract conditions (payments, agreements)
o Reduce fraud and errors
o Minimize need for trusted third parties
o Lower transaction and enforcement costs
• The concept gained real importance after the introduction of Bitcoin in 2009.
• In Bitcoin:
o Smart contracts are implemented in a limited form using scripting
o Enable secure value transfer without trust between parties
• Overall idea:
o Automated, secure, and trustless execution of agreements on a network

Definition

• A smart contract is a self-executing computer program that represents an agreement

between parties and automatically executes its terms when predefined conditions are
met without requiring a trusted intermediary
• It operates on the principle of “code is law,” meaning rules written in code are strictly
enforced without human intervention or external control
• Smart contracts run on blockchain networks, ensuring decentralization, transparency,
and immutability (cannot be changed once deployed)
• They follow a state machine model, where the contract changes its state based on
conditions and inputs (for example, from “pending” to “completed”)
• Key characteristics:
o Automatically executable: Executes actions on its own when conditions are
satisfied

Prof. Deepika G , Dept. of CSE, SVIT Page 21

 o Enforceable: Rules and terms are strictly followed and cannot be bypassed
o Deterministic: Produces the same output for the same input across all nodes
o Secure and unstoppable: Resistant to tampering, failures, or external
interference
• Advantages:
o Eliminates need for intermediaries (banks, lawyers)
o Reduces transaction cost and processing time
o Minimizes fraud and human errors
o Provides transparency and trust through blockchain
• Limitations:
o Difficult for non-technical users to understand
o Legal recognition and regulation are still evolving
o Requires external data sources (oracles) for real-world inputs
o Errors or bugs in code are permanent and hard to fix
• Important concept:
o Smart contracts are not actually “smart”; they simply execute exactly what is
programmed, no more, no less

Ricardian contracts

• A Ricardian contract is a digitally signed document that is both human-

readable (legal prose) and machine-readable (code/tags), linking legal
agreements with digital transactions
• Proposed by Ian Grigg in the late 1990s for digital financial systems
• Designed to bridge the gap between law (human understanding) and software
(machine execution)

Core idea:

• One document → readable by humans (legal contract)

• Same document → readable by computers (structured data)

Key properties:

• Contract issued by an issuer to holders

• Represents a valuable right controlled by issuer
• Human-readable like traditional legal documents
• Machine-readable (parsable by programs)
• Digitally signed for authenticity
• Contains keys and server information
• Linked with a unique secure identifier (hash)
Prof. Deepika G , Dept. of CSE, SVIT Page 22
 Working process:

• Contract written in legal prose + machine-readable tags

• Digitally signed by issuer
• Document is hashed → unique identifier created
• This hash is used in all related transactions
• Creates a secure link between original contract and transactions

Bow-tie model concept:

• Left side: World of Law (legal document)

• Middle: hash (identifier)
• Right side: World of Accountancy (transactions, systems)
• Hash connects both worlds securely

Difference from smart contracts:

• Ricardian contract → focuses on legal meaning (semantics)

• Smart contract → focuses on execution (performance)
• Ricardian = document-based
• Smart contract = code-based

Semantics types:

• Operational semantics → execution logic

• Denotational semantics → real-world legal meaning

Structure (3 parts):

• Prose → legal text

• Parameters → link between code and text
• Code → executable logic

Key insight:

• Ricardian contracts connect legal agreements + digital systems

• Smart contracts aim to combine both execution + meaning in future

 Used in systems like: CommonAccord, OpenBazaar, OpenAssets

Prof. Deepika G , Dept. of CSE, SVIT Page 23

 Smart contract templates

• Smart contract templates = predefined frameworks that combine legal agreements

+ code for financial instruments.
• Blockchain gained early adoption in the financial industry, leading to major
research in smart contracts.
• Proposed by Clack et al. (2016) in Smart Contract Templates research
• Goal: create standardized, reusable contract structures
• Templates help in:
o Supporting legal enforceability
o Linking legal prose with executable code
o Simplifying complex financial contracts
• Introduced idea of CLACK (Common Language for Augmented Contract
Knowledge)

• A specialized language for smart contracts

• Supports legal text + code + cryptography + multi-platform execution
• Focus of research:

o How to link legal prose with code using markup languages

o How to create, execute, store, and transfer smart legal contracts
• Domain-Specific Languages (DSLs):

o Designed for specific applications (e.g., finance)

o Limited features but optimized for a domain
o Easier and safer than general-purpose languages

• Examples in blockchain:

o Solidity → used in Ethereum

o Vyper → simpler alternative for smart contracts

• DSL vs GPL:

o DSL → specialized, limited scope, domain-focused

o GPL → general-purpose, used for large applications

• Future idea:

o Graphical DSLs (no coding required)

o Users (like lawyers, traders) can design contracts using visual interfaces

Prof. Deepika G , Dept. of CSE, SVIT Page 24

 • Contracts can be tested, simulated, and deployed directly

Benefit of graphical approach:

• Makes smart contracts accessible to non-programmers

• Reduces dependency on developers

Key insight:

• Smart contract development is moving towards standardization, legal integration,

and user-friendly tools.

Oracles

• An Oracle is a service/interface that provides external data to smart contracts, acting

as a bridge between blockchain and the real world
• Oracles supply various types of data such as stock prices, weather reports, news,
corporate data, and IoT sensor data
• Data is transferred through secure channels and is often digitally signed to ensure
authenticity and integrity
• Smart contracts can either request (pull) data from Oracles or receive (push) data
automatically from Oracles
• Oracles must ensure that the data provided is accurate, reliable, and tamper-proof, as
incorrect data can lead to wrong contract execution
• Simple or centralized Oracles rely on a single trusted data source, which makes them
easy to use but introduces trust and centralization issues
• Decentralized Oracles collect data from multiple sources, improving trust, reliability,
and resistance to manipulation
• Consensus-based approaches can be used where multiple independent sources
provide data, and the majority result is considered correct
• Hardware Oracles obtain data from physical devices such as sensors or IoT systems,
requiring tamper-resistant hardware and cryptographic proof
• A major challenge is the trust problem, as smart contracts depend on third-party data
providers, which may be compromised or inaccurate

Prof. Deepika G , Dept. of CSE, SVIT Page 25

 • To solve this, techniques such as data aggregation, decentralized systems, and
cryptographic verification (e.g., TLSNotary) are used
• Oracles can write data to the blockchain (e.g., via transactions), which smart contracts
can then read and use for execution
• Overall, Oracles are essential because they enable smart contracts to interact with real-
world data and events, making them practical and useful in real applications.

Smart Oracles

• Proposed by Ripple Labs (Codius)

• Smart Oracle = Oracle + ability to execute contract code
• Not only provides data but also performs computation
• Combines data delivery + program execution
• Helps in handling more complex smart contract logic
• Runs in a sandboxed environment (Google Native Client)
• Ensures secure execution of untrusted code
• Provides isolation and controlled processing
• Reduces load on blockchain (off-chain computation)
• Improves flexibility and efficiency
• Still requires trust in Oracle system
• More complex than simple Oracles

Deploying smart contracts on a blockchain

• Smart contracts can exist without blockchain, but blockchain provides

decentralization, security, and consensus, making it ideal
• Ethereum is a major platform that natively supports smart contract development
and deployment
• Smart contracts are often part of larger systems like Decentralized Autonomous
Organizations (DAOs)
• Bitcoin supports only basic smart contracts using limited scripting
• Examples in Bitcoin:
Prof. Deepika G , Dept. of CSE, SVIT Page 26
 o nLocktime → locks transaction until a specific time
o CHECKLOCKTIMEVERIFY (CLTV) → enforces time-based conditions
o CHECKSEQUENCEVERIFY (CSV) → enforces block-based delays
• These features allow simple conditions like:
o “Pay X amount after 3 months”
• Bitcoin scripting can create simple contracts, but functionality is very limited
• Example:
o Reward paid only if someone proves a hash collision attack
• Other platforms supporting smart contracts:
o Monax, Lisk, Counterparty, Stellar
o Hyperledger Fabric, Corda, Axoni Core
• Smart contracts can be written in different languages depending on platform
• Important requirement:
o Determinism → same input always produces same output on all nodes
• Determinism ensures network consensus and correctness
• Smart contract code must be accurate and bug-free (errors are critical)
• Verification and validation of smart contracts is an active research area
• Popular languages:
o Solidity (Ethereum)
o Vyper (Ethereum alternative)
o JavaScript (Lisk)
o Go, Java, JavaScript (Hyperledger Fabric)
• Key idea:
o Blockchain platforms enable secure, automated, and reliable execution of
smart contracts across distributed systems

The DAO

• The DAO is one of the highest crowdfunded projects, and it started in April 2016.
• This was a set of smart contracts written to provide a platform for investment.
• Due to a bug in the code, this was hacked in June 2016, and an equivalent of 50
million dollars was siphoned out of the DAO into another account.
• Even though the term hacked is used above, it was not really hacked; the smart
contract simply did what it was asked to do.
• It was just an unintentional behavior that programmers of the DAO did not foresee.
• This incident resulted in a hard fork on Ethereum to recover from the attack. It should
be noted that the notion of code is the law or unstoppable smart contracts should be
viewed with some skepticism as the implementation of these concepts is not mature
enough to merit full and unquestionable trust.

Prof. Deepika G , Dept. of CSE, SVIT Page 27

 • This is evident from the recent events where the Ethereum Foundation was able to stop
and change the execution of The DAO by introducing a hard fork.
• Though this hard fork was introduced for genuine reasons, it goes against the true
spirit of decentralization and the notion of code is law.
• On the other hand, resistance against this hard fork and some miners who decided to
keep mining on the original chain resulted in the creation of Ethereum Classic.
• This chain is the original, non-forked Ethereum blockchain where the code is still the
law. This attack highlights the dangers of not formally and thoroughly testing smart
contracts. It also highlights the absolute need to develop a formal language for the
development and verification of smart contracts.
• The attack also highlighted the importance of thorough testing to avoid the issues that
the DAO experienced. There have been various vulnerabilities discovered in Ethereum
recently, around the smart contract development language.

Prof. Deepika G , Dept. of CSE, SVIT Page 28