Unit 5: Alternative Coins and Smart Contracts

CSE436 — Blockchain 11 min read

I. Orientation

Blockchain systems use cryptographic proof, distributed consensus, and an append-only ledger to coordinate transactions without a central administrator. Bitcoin introduced this model in 2009; later systems modified its monetary policy, consensus mechanism, programmability, or application layer. Smart contracts extend blockchain from recording payments to executing conditional agreements.

Governing principle: A valid state transition must be accepted by network participants according to shared protocol rules.
Consensus assumption: Participants generally assume that no single adversary controls enough computational power, stake, or validating influence to rewrite accepted history.
Native asset: Each blockchain commonly has a coin or token used for fees, incentives, governance, or application functions.
Cryptographic foundation: Hash functions, digital signatures, and public-private key pairs authenticate transactions and protect ledger integrity.
Execution model: A smart contract changes blockchain state only when a valid transaction supplies the required conditions and resources.
Main trade-off: Greater programmability can increase flexibility while also increasing complexity, attack surface, and governance risk.

II. Alternative Coins — Variations on Bitcoin’s Design

Altcoins are cryptocurrencies other than Bitcoin. Some are independent blockchains; others are tokens issued on an existing blockchain. They may alter consensus, block timing, supply, privacy, scripting, or application functionality.

A. Introducing altcoins

This subsection establishes why alternative coins emerged and what distinguishes them from Bitcoin.

Meaning: “Altcoin” originally meant an alternative to Bitcoin, including networks such as Litecoin, launched in 2011 with faster block production and a different mining algorithm.
Design purpose: An altcoin may target payments, privacy, decentralized applications, stable value, governance, or specialized data storage.
Technical distinction: A coin has its own ledger and consensus rules; a token, such as an ERC-20 token, normally depends on another blockchain.
Economic role: The native asset can reward miners or validators, pay transaction fees, and discourage spam through a cost per state change.

B. Theoretical foundations

Theoretical foundations explain why independent participants can agree on a ledger despite network delays and possible dishonest behavior.

Distributed consensus: Nodes must converge on one transaction history even though messages can arrive in different orders.
Proof of Work: Miners repeatedly vary a nonce until the block hash satisfies a target. Security depends on the cost of producing competing work.
Proof of Stake: Validators lock capital and are selected or weighted according to protocol rules; dishonest behavior may cause loss of the deposited stake.
Game theory: Rewards encourage protocol-following behavior because honest participation should be more profitable or less risky than attacking the network.
Impossibility boundary: In an asynchronous network, agreement cannot be guaranteed under every failure condition; blockchains therefore rely on timing, economic, or probabilistic assumptions.

C. Difficulty adjustment and retargeting algorithms

Difficulty adjustment and retargeting algorithms regulate block production so that changes in total mining power do not radically change issuance speed.

Bitcoin target relation: A block is valid when its hash is numerically below the network target. Lower target means higher difficulty.
Retarget period: Bitcoin adjusts difficulty every 2,016 blocks, approximately two weeks at the intended ten-minute block interval.
Adjustment idea: The protocol compares actual elapsed time with the expected period and changes the target accordingly.

TEXT

new_target = old_target × actual_time / expected_time

Symbol definitions: actual_time is the measured time for 2,016 blocks; expected_time is 1,209,600 seconds; new_target is bounded by protocol limits.
Altcoin alternatives: Litecoin uses approximately 2.5-minute blocks and historically retargeted at different intervals; some networks use moving-window or per-block algorithms to respond more rapidly.
Trade-off: Slow adjustment improves stability but can leave a chain vulnerable to sudden hash-rate changes; rapid adjustment can produce volatility or manipulation opportunities.

D. Bitcoin limitations

Bitcoin’s original design is robust for decentralized payments but has limitations when used as a general-purpose application platform.

Throughput: A roughly ten-minute block interval and limited block capacity restrict transactions per second during heavy demand.
Confirmation time: Users often wait for several blocks because a transaction is probabilistically safer as additional proof-of-work accumulates.
Scripting limits: Bitcoin Script is deliberately constrained and not a general-purpose, freely looping programming language.
Energy use: Proof of Work consumes electricity because miners compete through repeated hashing.
Privacy limits: Addresses are pseudonymous, but transaction relationships and amounts may be analyzed on the public ledger.
Governance difficulty: Changing consensus rules requires broad coordination among developers, miners, businesses, and users.

E. Extended protocols on top of Bitcoin

Extended protocols on top of Bitcoin add functionality without changing every base-layer rule.

Layer-two payments: The Lightning Network creates payment channels whose many intermediate transactions can be settled later on Bitcoin.
Multisignature control: A spending condition can require signatures from several keys, such as two of three participants.
Sidechains: A separate chain can use a two-way peg or bridge mechanism to move representations of Bitcoin between networks.
Colored-coin approach: Bitcoin outputs can be interpreted as representing additional assets, although the asset rules are layered above ordinary transaction validation.
Security boundary: A higher-layer protocol may inherit Bitcoin’s settlement security while introducing its own liquidity, routing, bridge, or validator risks.

F. Development of altcoins

The development of altcoins combines technical modification with economic and community design.

Forking code: Developers can copy an existing open-source implementation and modify parameters such as block interval, supply, or hashing function.
New consensus: Networks may replace proof of work with proof of stake, delegated proof of stake, authority-based validation, or hybrid mechanisms.
Token economics: Supply schedule, issuance, burning, staking rewards, and fee policy affect scarcity and participant incentives.
Network effect: A technically impressive chain still needs wallets, exchanges, validators, developers, users, and reliable security practices.
Risk indicators: Anonymous teams, unrealistic returns, concentrated token ownership, unaudited code, and unclear governance increase project risk.

III. Initial Coin Offerings (ICOs) — Token-Based Fundraising

An ICO raises capital by selling blockchain-based tokens, often before a network or application is fully operational.

A. Initial Coin Offerings (ICOs)

This subsection explains the mechanism, benefits, and dangers of ICO fundraising.

Basic process: A project publishes token rules, accepts cryptocurrency or fiat, and distributes tokens according to a sale contract or allocation schedule.
Utility claim: Teams may describe tokens as access rights, payment units, governance rights, or future network resources; the actual legal and economic substance matters more than the label.
2017 expansion: Ethereum’s programmable token standards made token creation inexpensive, contributing to a major wave of ICOs.
Advantages: ICOs can finance open-source development and distribute ownership or usage rights globally.
Risks: Failed products, misleading disclosures, hacked sale contracts, market manipulation, and regulatory classification as securities can harm participants.
Technical control: A token contract may impose a hard cap, whitelist addresses, pause transfers, or allow administrative minting; buyers must understand these permissions.

IV. Smart Contracts — Programmable Blockchain Agreements

Smart contracts are programs that automatically enforce encoded conditions using blockchain transactions and state.

A. History of smart contracts

The history of smart contracts connects earlier legal-computing ideas with blockchain execution.

1994 proposal: Nick Szabo described smart contracts as computerized transaction protocols that execute the terms of a contract.
Earlier analogy: A vending machine demonstrates conditional execution: payment and selection produce a predefined item without a cashier.
Bitcoin stage: Bitcoin Script enabled conditions such as signatures, timelocks, and multisignature spending, but restricted computation.
Ethereum stage: Ethereum, proposed in 2013 and launched in 2015, introduced a blockchain designed to execute persistent general-purpose contract code.
Important distinction: Code can automatically control digital assets, but it cannot by itself guarantee performance involving physical goods, courts, or off-chain facts.

B. Definition of smart contracts

A smart contract is deterministic software deployed to a blockchain that controls state and assets according to encoded rules.

State: Storage variables record values such as balances, ownership, votes, or loan status.
Transaction trigger: A user or another contract submits a transaction calling a function; execution consumes network resources.
Determinism: Every validating node must obtain the same result from the same prior state, inputs, and code.
Gas model: On Ethereum, gas measures computational work. The transaction fee is commonly expressed as gas used multiplied by gas price.
Immutability: Deployed bytecode is difficult to alter unless the design includes an upgrade mechanism, proxy, administrator, or migration process.
Limitation: A contract cannot spontaneously act; it requires a transaction or protocol-supported trigger, and it cannot directly observe external reality.

V. Contract Representation — Human Terms and Reusable Code

Blockchain agreements require both a human-understandable description and precise executable logic. These layers reduce ambiguity but do not eliminate legal or technical risk.

A. Ricardian contracts

A Ricardian contract links a legally meaningful agreement to a machine-readable representation and a unique cryptographic identifier.

Purpose: It allows people to read the contract while software can identify and process the same agreement.
Hash commitment: A cryptographic hash of the document produces a compact identifier; changing one character normally changes the hash.
Dual audience: Legal prose explains rights and obligations; structured fields expose parties, asset, price, dates, and governing conditions to software.
Practical value: A tokenized bond could include maturity date, issuer, interest rate, and redemption rules in both prose and structured data.
Limitation: Hash linkage proves document integrity, not that the issuer supplied truthful information or that a court will enforce every term.

B. Smart contract templates

Smart contract templates are reusable designs for common on-chain behavior, such as tokens, escrow, auctions, and voting.

Standardization: Ethereum’s ERC-20 interface specifies common functions such as transfer, balanceOf, and approve, improving wallet and exchange compatibility.
Reuse benefit: A tested template reduces development effort and makes expected behavior easier to inspect.
Parameter risk: A template may still be unsafe when configured with excessive owner powers, incorrect decimal handling, or unrestricted minting.
Security controls: Access checks, input validation, event logging, reentrancy protection, and explicit failure handling are core safeguards.
Upgrade trade-off: Upgradeable templates permit bug fixes but introduce administrator or governance dependence that weakens immutability.

VI. External Data and Execution — Oracles and Deployment

Smart contracts need reliable data inputs and a controlled deployment process because blockchain execution is deterministic but many useful facts are external.

A. Oracles

Oracles provide external information to smart contracts, such as exchange rates, weather results, or sports outcomes.

Problem: A contract cannot safely call an ordinary website during deterministic validation because nodes might receive different responses.
Data flow: An oracle obtains data, signs or posts it on-chain, and a contract reads the submitted value.
Decentralization: Multiple independent data providers can be aggregated to reduce dependence on one source.
Attack surface: False data, delayed updates, compromised keys, low liquidity, and manipulation of a reported price can trigger incorrect payouts.
Example: A lending contract may liquidate collateral when an oracle-reported asset price falls below a threshold; the threshold and data freshness requirement must be explicit.

B. Deploying smart contracts

Deploying smart contracts converts source code into blockchain bytecode and publishes it at an address with a defined initial state.

Compilation: A language such as Solidity is compiled into bytecode and an ABI, which describes callable functions and event formats.
Testing: Developers should test normal, boundary, failure, permission, and reentrancy cases before deployment.
Deployment transaction: The creator sends bytecode in a transaction, pays gas, and receives a contract address derived from deployment data.
Verification: Publishing source code and compiler settings allows users to compare readable code with deployed bytecode.
Operational controls: Keys, pause functions, multisignature administration, monitoring, and incident procedures matter after launch.
Irreversibility: A deployment mistake can permanently lock assets or expose funds; upgrades and migrations must be designed before they are needed.

VII. The DAO — Governance Failure and Recovery

The DAO was a major 2016 Ethereum experiment in decentralized investment governance and became a defining case in smart-contract security and blockchain governance.

A. The DAO

The DAO used contracts to pool ether and let token holders vote on proposed investments, but a recursive withdrawal vulnerability enabled an attacker to drain a large amount of funds.

Contract structure: A participant could split from the organization and withdraw funds into a child DAO while receiving corresponding tokens.
Reentrancy flaw: The vulnerable logic sent ether before fully updating internal accounting, allowing a fallback call to invoke the withdrawal path repeatedly.
Concrete effect: Repeated withdrawals occurred before the contract recognized that the attacker’s balance had already been spent.
Response: Ethereum participants implemented a controversial chain change in 2016 to return affected funds; the original chain continued as Ethereum Classic.
Significance: The event showed that “code is law” is incomplete when communities can coordinate exceptional intervention.
Lesson: Audits, checks-effects-interactions ordering, withdrawal limits, formal testing, and governance planning are necessary because deployed code can control substantial value while remaining vulnerable to small logical errors.