DApps and Smart Contracts

DApps Lecture Notes

• Distributed applications (DApps) are software applications that run on a distributed P2P network rather than a single computer.
• These interact with a Frontend Web3.

Smart Contract: "money.sol"

• Smart contracts need to be written to implement the functionality of DApps
• To test this functionality, Remix IDE can be used
  • Deploy the smart contract
  • Transact with the smart contract
  • Deposit the required amount
  • Check the withdrawn amount

Metamask Wallet

• Metamask wallet can be used to integrate and deploy
• Any test network on Metamask can be used
• The Goerli Testnet (PoA consensus -> PoS with open validators) or Sepolia testnet (a Proof-of-Stake (PoS) testnet with permissioned validators)
• Deploy on the Goerli Testnet using the Metamask account using the deployment tab.

Frontend Development

• To develop the frontend contract address and the ABI are required for separate notepad.

Frontend Development of Smart Contracts

• To load the index.html, a visual studio-like text editor is required.
• Edit the contract address to match in step 4.
• Edit the ABI file to the copied ABI from step 4.

Interacting with Smart contract using frontend

• Go to xampp installation and move the updated index.html file to the htdocs folder.
• Start the xampp web server.
• Open the money smart contract using the Admin button and launch it in the web browser.
• Interact with the smart contract front end with localhost/index.html.

IPFS Introduction

• InterPlanetary File System (IPFS) is a peer-to-peer distributed file system.
• IPFS stores files and tracks all the transactions on the distributed network.
• It's a combinational technology of the version controlling system and P2P network spread over a global namespace.
• IPFS is a single BitTorrent swarm, exchanging objects within one Git repository.
• In contrast to a central storage based file system, IPFS works on a decentralized system.
• Every user in the network holds a portion of the overall data, creating a resilient system for storage and sharing over the globe.
• Any user in the network can share a file which is accessible to everyone by requesting from a node using DHT(Distributed Hash Table)

HTTP issues

• HTTP is a request-response based protocol
• When a web browser sends a request to an external server, the function of the server is to return the request with a response message.
• HTTP faces problems when there is a disruption in the network or when the client can't connect with the server.
• HTTP web is usually full of broken links in the network.
• HTTP with its location-based addressing model encourages centralization.
• The data is becoming siloed on the web.

IPFS Addressing

• Content is addressed by using IPFS instead of HTTP
• IPFS guarantees a permanent and distributed web by incorporating content-addressed system, instead of location-based (used by HTTP).
• IPFS uses a form of representation by integrating a hash on a file, which is taken as the address.
• The hash is a root object, and it provides its path to other objects as well.
• As opposed to requesting a server for data access, you can gain access to this hash, which acts as a starting point of data.
• We can reach the peer who has the content at the hash location, and download the content from the node which holds the data.
• A DHT or Distributed Hash Table is used by IPFS for storing data.

IPFS Components

• Distributed Hash Table
• Merkle DAG
• Version Control System
• Self-certifying File System

Building the DHT

• Discovery: Ask for CID 1
• Peer B has CID 1
• Request CID 1 from Peer B
• Peer B sends Block CID 1

Summarizing IPFS

• Content is accessible through peers, located anywhere, that relay information, store it, or do both.
• IPFS finds what you ask for via its content address.
• Three fundamental IPFS principles:
  • Unique identification via content addressing.
  • Content linking via directed acyclic graphs (DAGs).
  • Content discovery via distributed hash tables (DHTs).

Installing IPFS for Lab

• Can be installed using https://docs.ipfs.tech/install/ipfs-desktop/

DAOs Background

• DAO (Decentralized Autonomous Organization) is an early example of tokenizing ether Purpose is a Venture Capital Fund for blockchain-based investments that would be directed by investors (owners of the DAO token).
• It is a smart contract on Ethereum blockchain designed by Slock.it
• Lacks a management structure, a Board of Directors, and employees
• The code was open-source and stateless.

DAO Launch

• Launched in April 2016 on Ethereum block 1428757 with a crowdsale to fund the organization.
• Ether value was about $150 million by May 21 (about 14% of all ether at the time).

DAO Reentrancy Bug

• June 9, 2016: Two developers reported most Ethereum-based contracts managing funds were vulnerable to a bug (Reentrancy Bug).
• June 12, 2016: Stephan Tual (Slock.it founder) reported that The DAO code was not vulnerable to this exploit.
• The code had two lines in the wrong order, allowing repeated ether withdrawals before checking entitlement.
• June 17, 2016: The DAO was attacked, and a user gained access to ~$50 million of ETH (30% of ether in the contract). Another group, Robin Hood Group (RHG), simultaneously used a similar exploit, promising to return ether to owners (they got the remaining 70%).

Community Debate

• The funds were put in a 28-day holding period before they could be withdrawn.
• The community debated rewriting history by hard forking, with a July 20 deadline (end of 28-day period).

The Hard Fork

• July 20, 2016: A hard fork at block 1,920,000 rewrote history, returning the DAO-directed ether to investors.
• The old protocol, Ethereum Classic (ETC), preserved history (immutability property), mandating RHG to return 70% of the ETC to the original investors.

Hard Fork vs. Soft Fork

• Soft Forks:
  • Relatively minor software changes.
  • Software upgrades backward-compatible with previous versions.
  • Nodes do not need upgrading to form consensus.
• Hard forks:
  • Major software changes.
  • Not backward-compatible with previous versions.
  • New rules for node consensus.
  • It can be planned (Constantinople) or contentious (ETC).

Lessons from the DAO Incident

• Smart Contracts:
  • Are not always smart and once deployed, cannot be "fixed."