PaperlayerView exact revision on arXiv

Source-linked AI summary

Decentralized Applications: The Blockchain-Empowered Software System

Wei Cai, Zehua Wang, Jason B. Ernst, Zhen Hong, Chen Feng, Victor C. M. Leung

arXiv:1810.05365v1cs.DCcs.CRcs.CY

TL;DR

Blockchain research faces skepticism from cryptocurrency speculation and scams, while current applications remain constrained by performance and partial decentralization. This paper traces blockchain evolution, surveys dApps, and reviews development directions; it concludes that dApps are central to blockchain’s future and that decentralized ecosystems are approaching a new era of Internet services.

  • Problem

    Current blockchain applications are limited by performance, partial decentralization, token-based access, and unresolved identity-management challenges.

  • Method

    The paper traces blockchain-system development, surveys state-of-the-art dApps, and discusses desirable characteristics and development directions including payment channels, consensus models, and non-public blockchains.

  • Results

    The paper identifies decentralized applications as the subject matter of future blockchains and reviews applications and technologies aimed at supporting them.

  • Takeaways & Limitations

    Blockchain systems may support a next-generation decentralized ecosystem through applications that integrate cryptography, P2P networking, consensus, and smart contracts.

  • Takeaways & Limitations

    Payment channels cannot support all dApp scenarios because off-chain caching prevents data needed for sequential dependencies from synchronizing across the system.

Abstract

from arXiv · show

Blockchain technology has attracted tremendous attention in both academia and capital market. However, overwhelming speculations on thousands of available cryptocurrencies and numerous initial coin offering (ICO) scams have also brought notorious debates on this emerging technology. This paper traces the development of blockchain systems to reveal the importance of decentralized applications (dApps) and the future value of blockchain. We survey the state-of-the-art dApps and discuss the direction of blockchain development to fulfill the desirable characteristics of dApps. The readers will gain an overview of dApp research and get familiar with recent developments in the blockchain.

I. INTRODUCTION

The paper frames blockchain beyond cryptocurrency speculation by tracing decentralized ledgers and motivating decentralized applications as blockchain-empowered software systems. It highlights immutability, consensus, and resistance to double spending while identifying limitations in current applications.

  • Blockchain foundations: Blockchain links blocks through cryptographic hashes, making stored data resistant to modification and establishing immutability as a foundation for applications.Changing one block requires regenerating subsequent blocks with new hash values.
  • Motivation: Cryptocurrency became blockchain’s first major application, but unregulated tokens and scams generated doubts about the technology’s value.The passage describes thousands of tokens and numerous so-called “air coins.”
  • Contribution: The paper therefore introduces decentralized applications as a novel form of blockchain-empowered software system and surveys their development.Its planned sections review blockchain systems, dApps, desirable characteristics, implementation choices, and next-generation research.
  • Classic blockchain systems: Decentralized ledgers must resolve data synchronization through consensus, requiring participants to agree on messages and decisions.The paper presents Byzantine fault tolerance in terms of majority agreement among honest peers.
  • Classic blockchain systems: Bitcoin’s Proof-of-Work consensus addresses double spending by making peers compete to solve computational puzzles and rewarding successful block producers.The mechanism raises the value of honest mining relative to attacking the decentralized system.

E. BROADER DEFINITION OF BLOCKCHAIN SYSTEMS

The paper defines blockchain systems broadly as the combination of an immutable blockchain, a P2P network, and a consensus model. It presents dApps as the intended application direction, while noting current performance and operational limitations.

  • E. BROADER DEFINITION OF BLOCKCHAIN SYSTEMS: A blockchain system combines blockchain data structures, P2P networking, and consensus rather than referring only to an immutable chain of blocks.The broader definition treats these three components as one system.
  • E. BROADER DEFINITION OF BLOCKCHAIN SYSTEMS: Participants store blockchain data locally and synchronize blocks through consensus, represented in the paper by the longest chain accepted by most peers.Figure 1 illustrates this architecture.
  • Classic systems: Bitcoin opened public blockchain applications through a decentralized ledger that solves double spending, but its computational effort primarily strengthens system robustness.The paper characterizes Bitcoin as a ledger without a broader subject matter.
  • Smart contracts: Ethereum extends blockchain from data storage into computation through executable smart contracts written into blocks.Solidity enables developers to implement these Turing-complete contract programs.
  • Decentralized applications: Current applications usually place only modification-resistant core data and functionality on-chain, leaving local execution vulnerable to hidden cheating and maintenance issues.The paper attributes this limitation partly to blockchain performance constraints.
  • Decentralized applications: An ideal dApp would be fully hosted by the P2P blockchain and operate without developer maintenance or human intervention, approximating a DAO.The paper lists open source, internal cryptocurrency support, decentralized consensus, and no central point of failure as dApp properties.

IV. STATE-OF-THE-ART DAPPS

The survey covers dApps across industries and emphasizes that many prominent systems remain only partially decentralized. Games illustrate both the appeal of blockchain ownership and the immaturity of current implementations.

  • IV. STATE-OF-THE-ART DAPPS: Ethereum hosts dApps in categories including exchange, energy, finance, health, identity, insurance, and media, but many systems decentralize only selected functions.Blockstack and OpenBazaar are cited as validating identities without decentralizing everything else.
  • A. GAMES: Blockchain games use non-fungible virtual items that can be traded and inherited, but transaction fees and delays keep most games at a preliminary stage.Current implementations focus mainly on collectibles and virtual-item trading.
  • A. GAMES: CryptoKitties lets players buy, sell, and breed individually differentiated cats through Ethereum smart contracts, and its popularity once overwhelmed the network.The game is presented as a milestone in Ethereum’s development.
  • A. GAMES: Blockchain games benefit from non-fungible tokens and transparency while changing players from passive consumers into participants who create content and influence development.The paper describes this as a transformation of the relationship between players and game companies.
  • A. GAMES: Games remain immature because entertainment value trails traditional games, monetary motives dominate for some users, and lifetimes are unpredictable.Fully decentralized operation can also remove operators’ control and contribute to rapid loss of game populations.
  • A. GAMES: Despite these limitations, blockchain games attracted substantial attention from major game companies and producers shortly after their introduction.The paper expects higher-quality blockchain games to emerge.

B. USER-GENERATED CONTENT (UGC) NETWORK

The paper surveys decentralized user-generated-content and task marketplaces that use tokens, incentives, and reputation mechanisms to address intermediary costs and creator rewards. It also presents ONO as a decentralized social-network proposal.

  • B. USER-GENERATED CONTENT (UGC) NETWORK: User-generated-content platforms center users and their creations but face security and privacy concerns, including content theft by larger pages.The passage identifies these as critical issues for existing platforms.
  • B. USER-GENERATED CONTENT (UGC) NETWORK: Steem rewards publishers with its STEEM cryptocurrency, allowing creators to convert original articles, music, and other creations into money without third-party transaction fees.STEEM can be purchased and exchanged for other cryptocurrencies.
  • B. USER-GENERATED CONTENT (UGC) NETWORK: Gems is an Ethereum-based decentralized crowdsourcing marketplace where requesters publish microtasks and workers complete them for payment.It is positioned as an alternative to MTurk’s intermediary fees and variable worker accuracy.
  • B. USER-GENERATED CONTENT (UGC) NETWORK: Gems combines staking, a trust score, and a payment system to support task completion, assess worker integrity, and reduce transaction fees.These mechanisms are described as components of the Gems Protocol.
  • B. USER-GENERATED CONTENT (UGC) NETWORK: ONO proposes a decentralized social network that shares social-networking profits with content creators and defines attention as a source of value.Its stated principles include freedom, equality, and social public governance.

C. INTERNET OF THINGS

The passages describe dApp applications that connect blockchain, smart contracts, and IoT to automate interactions, coordinate supply chains, trace product origins, and support decentralized sharing incentives.

  • IoT connects physical devices for data collection, communication, and environmental control without human involvement.
  • Smart Hardware: Smart contracts let IoT devices execute predefined actions automatically, such as granting hotel access after payment.Transparent and immutable contracts can establish trustful relationships among multiple parties without complicated conversations or regulations.
  • Supply Chain: Integrating IoT and smart contracts can coordinate supply-chain data and documentation across multiple stakeholders.
  • Supply Chain: A shipment delay can trigger a transparent smart contract to place make-up orders automatically, replacing extensive communication.The example says this can minimize manufacturing disruption while saving time and resources.
  • Source Tracing: Blockchains support source tracing by storing immutable transaction histories that help reconstruct product origins across fragmented systems.The passage contrasts this with centralized systems that may be faster but lack trusted, transparent data storage.
  • Sharing Economy: Sharing economies need credit systems that encourage contributions and fairness, but centralized credits may have limited incentive value.
  • File Sharing: Filecoin combines decentralized storage providers with token payments for storage, retrieval, and data serving.Its Proof-of-Spacetime consensus model creates blocks through miners that store data.

2) Data Sharing Credits

The section frames decentralized sharing and computation as application areas for dApps, while emphasizing that future platforms must overcome latency, throughput, and sequential-execution constraints.

  • Data and Bandwidth Sharing: Peer-to-peer mesh networking can let users share connectivity directly through Wi-Fi, Bluetooth, and Wi-Fi Direct.
  • Computational Sharing: Growing demand from scientific research, machine learning, and graphics rendering increases the need for distributed computational power, hardware, and bandwidth.The passage presents BOINC as an earlier model based on users contributing spare CPU cycles.
  • Future dApps require blockchain platforms with desirable characteristics tailored to the application scenarios discussed.
  • Low Latency: Bitcoin’s average block-mining time is 10 minutes, producing roughly one hour of typical transaction confirmation delay.Ethereum reduces response latency to around 15 seconds, but the passage says this remains insufficient for general application interactions.
  • High Throughput: dApp platforms must handle millions of daily active users, yet current blockchains still face throughput bottlenecks.CryptoKitties is cited as an example of a popular application accounting for nearly 30% of transactions at one point.
  • Parallel Execution: Sequential dApp performance is constrained by response delays across network nodes because transactions and operations must be executed among them.

B. ENABLING OFFLINE TRANSACTIONS

The passages identify offline operation, affordable access, upgradeability, and smart-contract security as requirements for more usable and maintainable blockchain applications.

  • Offline Transactions: Offline blockchain transactions risk double spending when disconnected devices exchange signed transactions without complete network visibility.
  • Offline Transactions: A dApp could accept locally signed Bluetooth payments offline and relay them to the Internet later for settlement.The example involves a traveler paying a vendor in a village without Internet access.
  • Transaction Fees: Transaction fees help deter spam and malicious smart-contract executions but can burden low-value transactions.
  • Modern Free Internet Business Model: Requiring users to buy tokens limits dApp adoption, motivating free services that share platform profits with users and content producers.
  • Enabling System Upgrades: Hard forks are currently the only upgrade approach for blockchain systems and may cause node loss and multiple confusing tokens.Bitcoin Cash and Ethereum Classic are given as examples of forked tokens.
  • Smart-Contract Security: Immutable blockchain data prevents modifying deployed dApps, making bug patches impossible despite testing and careful implementation.The passage notes that complex dApps intensify smart-contract security concerns.

E. SIMPLER IDENTITY MANAGEMENT

The section presents identity management and blockchain selection as practical dApp concerns, comparing established platforms while noting that many alternatives remain insufficiently evaluated.

  • Simpler Identity Management: Blockchain dApps face identity challenges involving privacy, anonymity, and regulatory checks such as KYC and AML.
  • Blockchain Selection: Choosing a blockchain requires matching technical features, payment scalability, economic models, and programming-language support to the dApp.
  • Bitcoin: Bitcoin’s ecosystem includes 571 contributors, more than 18,000 commits, about 10,000 full nodes, and a reported peak average of 4.92 TPS.
  • Ethereum: Ethereum is at least comparable to Bitcoin in developer participation, despite overlapping contributors across its repositories.
  • Ethereum: Ethereum’s reported peak was 1,349,890 transactions per 24 hours, or 15.62 transactions/second, with speed varying by client implementation.The passage also reports about 16,000 full nodes and an average transaction fee near USD $4.15.
  • Other Blockchains: Many blockchain alternatives lack independent analyses of throughput limits, security, economics, business models, communities, and roadmaps.The passage therefore places responsibility for evaluating technical suitability and long-term stability on dApp developers.
  • Next-Generation Systems: The paper summarizes state-of-the-art research directions for next-generation blockchain systems intended to support desirable dApp characteristics.

A. PAYMENT CHANNELS AND PAYMENT NETWORKS

Payment channels reduce repeated on-chain transactions by keeping signed payment updates off-chain until a party closes the channel. The section introduces unidirectional and bidirectional channels and their lifecycle mechanisms.

  • Payment channels let users make multiple payments without triggering multiple blockchain transactions.They address scalability problems caused by backlogged transactions, especially in Proof-of-Work blockchains.
  • Unidirectional Payment Channels: In a unidirectional channel, payer A creates the channel, locks a deposit, and sends signed payment updates to recipient B.B receives signatures off-chain and can later submit one to the blockchain to close the channel.
  • Unidirectional Payment Channels: The latest signature is preferred because it reflects the greatest cumulative payment, while the locked deposit remains unsplit until closure.This allows the recipient to wait for a later payment update before broadcasting.
  • Unidirectional Payment Channels: Timestamps and a challenging period allow the payer to close the channel while giving the recipient time to submit a newer signature.The mechanism addresses disputes over which payment state should determine the final split.
  • Bidirectional Payment Channels: Bidirectional channels allow both parties to make payments, with each signed split plan updating how the shared deposit is allocated.Each participant’s contribution limits the maximum amount that participant can pay the other.
  • Bidirectional Payment Channels: Disputed closures in bidirectional channels use the challenging-period mechanism so a party can submit evidence of a fairer signed state.The channel therefore preserves an opportunity to contest an allegedly dishonest closing plan.

3) Payment Networks

Payment networks extend payment channels across multiple hops, analogous to communication networks. The section also connects channel-based scaling to broader blockchain design trade-offs and consensus choices.

  • Payment Networks: Payment networks use multiple payment-channel hops, analogous to end-to-end communication over links in a communication network.The analogy motivates networks because creating a separate channel for every pair of users remains costly.
  • Payment Networks: Hash puzzles can coordinate intermediaries by requiring a valid key from the receiver before payments are released across the route.The puzzle is difficult to solve but easy to validate, supporting conditional reimbursement between participants.
  • Payment Networks: Payment channels are not sufficient for all dApp scenarios because off-chain caching prevents system-wide synchronization when later steps depend on earlier data.The limitation specifically concerns next-generation applications with sequential data dependencies.
  • Consensus Models: Proof-of-Work imposes substantial energy costs because participating nodes perform computational work to gain block-writing privilege.The paper reports Bitcoin mining’s annual energy consumption as 11.8% more than Switzerland’s and approximately 30% of Australia’s.
  • Consensus Models: Proof-of-Stake replaces PoW computation with stake-based block selection, making token ownership the barrier against identity forgery.Participants holding more stake are more likely to become block producers.
  • Consensus Models: Proof-of-Stake avoids PoW’s computational overhead but permits rational stakeholders to follow multiple forks at no cost, creating potential network chaos.The paper describes this as a critical issue because forks can multiply stakeholders’ tokens across subchains.
  • Consensus Models: Delegated Proof-of-Stake assigns block production to elected supernodes supervised by stakeholders, who can vote out malicious producers.EOS uses 21 supernodes, whereas Asch uses 101 delegates.

3) Comparison Among Consensus Models

The paper compares blockchain types and consensus models through trade-offs among decentralization, efficiency, privacy, security, cost, and governance. Application requirements determine which design is appropriate.

  • Consensus Models: Different consensus mechanisms require corresponding reward models because their security and participation incentives differ.The paper notes ongoing proposals including Leased Proof of Stake, Proof of Burn, Proof of Capacity, Proof of Elapsed Time, and Algorand, none yet widely accepted by the dApps community.
  • Blockchain Types: Permissionless blockchains face efficiency bottlenecks because broad network synchronization limits TPS, while PoW-based systems additionally consume substantial energy.Their openness can also expose sensitive transaction patterns, including in medical-record applications.
  • Blockchain Types: Permissionless blockchains allow anyone to join, while permissioned blockchains restrict participation through invitations or organizational control.Both can remain decentralized, share append-only ledgers, and synchronize through consensus.
  • Blockchain Types: Permissioned blockchains are suited to settings requiring participation control, but their specific forms differ in governance and access privileges.Private blockchains operate under one organization, whereas consortium designs distribute control among participating organizations.
  • Blockchain Types: Hybrid blockchains combine permissionless and permissioned properties to compromise among security, efficiency, cost, and fairness.They target increasingly complex application requirements.

1) Private Blockchains

Private blockchains control participation within an organization and can reduce PoW overhead, while MultiChain adds mutual permission checks and mining-diversity constraints. These choices target secure, scalable administration.

  • Private Blockchains: Private blockchains invite participants under organizational access control and rely on internal participants’ honesty rather than expensive PoW security.This design reduces the computational effort and potential energy waste associated with PoW.
  • Private Blockchains: MultiChain requires participants to connect and verify each other’s permissions before entering a transaction.Its handshaking process supplements private-key-based fund control.
  • Private Blockchains: Mining diversity prevents one miner from producing too many blocks within a specified time window.A block violating the requirement is deemed invalid by the network.
  • Private Blockchains: MultiChain’s stated characteristics include secure mining without expensive PoW, administrator-managed participation privileges, and resistance to miner monopolization.These properties are presented as improving scalability and administrative control.

2) Consortium Blockchains

Consortium and hybrid blockchains balance controlled participation with privacy, verification, and application-specific flexibility. Hyperledger Fabric illustrates this design through phased consensus and parallel processing, while hybrid systems combine permissioned control with immutable public records.

  • Consortium Blockchains: Consortium blockchains use a pre-selected set of nodes to control consensus rather than placing one organization in full control.For example, at least 10 of 15 organizations may need to approve a block.
  • Consortium Blockchains: Hyperledger Fabric separates consensus into endorsement, ordering, and validation phases.These phases collect signatures, order endorsed transactions, and validate transaction results, endorsement policies, and double-spending.
  • Consortium Blockchains: Fabric lets applications choose different endorsement, ordering, and validation arrangements according to their needs.Its smaller node set and massively parallel computation support scalability greater than permissionless blockchains.
  • Consortium Blockchains: Fabric can scale to over 1000 TPS in a very short time while strengthening flexibility in security and permission.
  • Consortium Blockchains: Hybrid blockchains combine permissioned and permissionless models, keeping transactions private while retaining verifiability through immutable public records.XinFin is presented as an example connecting institutions or governments, digital assets, and IoT-enabled equipment for infrastructure financing.
Loading 1810.05365v1…