Source-linked AI summary

A First Look at Blockchain-based Decentralized Applications

Kaidong Wu, Yun Ma, Gang Huang, Xuanzhe Liu

arXiv:1909.00939v1cs.SE

TL;DR

Existing reports provide basic usage statistics, while academic work mainly studies blockchain systems and smart-contract mechanisms, leaving DApp characteristics and development practices little studied. The study examines DApp popularity by unique users, transactions, and transaction volumes, comparing categories and tracking how popularity changes over time. Popularity typically follows the Pareto principle; high-risk DApps increased, 15.7% are fully open source, 75% have one contract, and median execution uses 50% of prepaid fees.

  • Problem

    Existing reports provide basic usage statistics, while academic work mainly studies blockchain systems and smart-contract mechanisms, leaving DApp characteristics and development practices little studied.

    Source: §I · p. 1
  • Method

    The study examines DApp popularity by unique users, transactions, and transaction volumes, comparing categories and tracking how popularity changes over time.

    Source: §I · p. 1
  • Results

    Popularity typically follows the Pareto principle; high-risk DApps increased, 15.7% are fully open source, 75% have one contract, and median execution uses 50% of prepaid fees.

    Source: §I · p. 2
  • Takeaways & Limitations

    The findings offer implications for DApp choice, prepaid-fee setting, contract architecture, and blockchain-vendor support.

    Source: §I · p. 2, §IX · p. 10

Abstract

from arXiv · show

With the increasing popularity of blockchain technologies in recent years, blockchain-based decentralized applications (DApps for short in this paper) have been rapidly developed and widely adopted in many areas, being a hot topic in both academia and industry. Despite of the importance of DApps, we still have quite little understanding of DApps along with its ecosystem. To bridge the knowledge gap, this paper presents the first comprehensive empirical study of blockchain-based DApps to date, based on an extensive dataset of 995 Ethereum DApps and 29,846,075 transaction logs over them. We make a descriptive analysis of the popularity of DApps, summarize the patterns of how DApps use smart contracts to access the underlying blockchain, and explore the worth-addressing issues of deploying and operating DApps. Based on the findings, we propose some implications for DApp users to select proper DApps, for DApp developers to improve the efficiency of DApps, and for blockchain vendors to enhance the support of DApps.

I. INTRODUCTION

Blockchain-based DApps have spread, but their ecosystem and development practices remain poorly understood. This study examines 995 Ethereum DApps and their transactions to characterize popularity, development practices, and operating costs.

I. INTRODUCTION

  • The study uses 2018 data from 995 popular Ethereum DApps, including 5,158 smart contracts and 29,846,075 transactions, to examine popularity, development practices, and running costs.Its questions cover popularity across users, transactions, volume, categories, and time; open-source status and contract organization; and blockchain fees.Source: §I · pp. 1–2
  • Popularity distributions typically follow the Pareto principle, and DApps with financial features have large market influence.The analysis considers users, transactions, and transaction volumes.Source: §I · p. 2
  • As DApps developed, the number in high-risk categories increased significantly, raising potential security issues.The number of DApps first grew rapidly in Exchanges, Gambling, and Finance.Source: §I · p. 2
  • Only 15.7% of DApps are fully open source, while 25.0% are completely closed source; open-source contracts are generally associated with more transactions.Fully open source means both DApp code and related smart-contract code are available; the association does not establish causation.Source: §I · p. 2
  • 75% of DApps contain one smart contract; multi-contract DApps use leader-member, equivalent, or factory contract patterns.Leader-member contracts invoke one another through internal transactions; equivalent contracts have no such invocation; factory contracts deploy child contracts.Source: §I · p. 2
  • Deployment cost per contract is lower for single-contract than multi-contract DApps and correlates with code lines and function count, with function count more influential.The study also examines execution costs; median executions use only half of the prepaid fee, and internal-transaction executions cost more.Source: §I · p. 2
  • The findings are intended to inform DApp selection, prepaid-fee setting, contract architecture, and blockchain-vendor mechanisms.The paper connects these implications to end-users, developers, and blockchain vendors.Source: §I · p. 2

II. BACKGROUND

The background describes Ethereum as a peer-to-peer ledger supporting Ether and smart contracts, and explains how DApps combine blockchain functionality with off-chain services. It also outlines transaction fees, architectures, and contract deployment.

A. Ethereum Blockchain

  • Ethereum records transactions on a peer-to-peer ledger, with accepted blocks linked into the ledger through the network’s consensus process.Ethereum supports Ether and smart contracts, which are programs saved on and able to run on blockchains.Source: A. Ethereum Blockchain · p. 2
  • Ethereum transactions include Ether transfers and contract executions, and accounts pay fees called gas.The supplied classification passage distinguishes these transaction types by their data, but does not provide the full second classification.Source: A. Ethereum Blockchain · pp. 2–3, Figure 1 · p. 3

B. Ethereum DApp

  • Ethereum DApps use smart contracts for on-chain business logic, while practical architectures range from direct client access to access through a server or both.The passage attributes partial on-chain implementation to blockchain performance bottlenecks.Source: B. Ethereum DApp · p. 3, Figure 2 · p. 3
  • The paper separates smart-contract deployment cost from general execution cost; deployment is treated as a contract execution of the constructor function.The passage says deployment cost can represent contract complexity, and executions exceeding a block’s gas limit fail without changing anything.Source: B. Ethereum DApp · p. 3

III. THE DATASET

The study builds its Ethereum DApp dataset from a third-party directory, collecting DApp details, contract information, and 2018 transactions. It filters out DApps without contract addresses for its analysis.

Dataset source

  • The researchers selected DApps from State of the DApps, a third-party directory referenced by Ethereum’s official homepage.The paper describes it as an independent site where developers can submit DApps for publication.Source: §III · p. 3

Data collection

  • The initial collection contained 1,749 Ethereum DApps listed as of January 2019, with basic information, listed contracts, and related transaction data gathered.Contract source code was sought on Etherscan, while 2018 blockchain blocks were used to retrieve related contract executions.Source: §III · pp. 3–4

Filtering

  • After excluding DApps without developer-provided contract addresses, the analysis dataset contained 995 DApps.The exclusion enabled the researchers to retrieve and analyze the smart contracts.Source: §III · p. 4

Dataset statistics

  • The retained DApps listed 5,158 smart contracts, with source code retrieved for 2,568; their 2018 transactions involved 2,199,059 user accounts and 9,057,344,360 Ethers transferred.The study counted 29,846,075 related transactions.Source: §III · p. 4, Table I · p. 4

IV. POPULARITY OF DAPPS

The section measures DApp popularity using users, transactions, and ETH transaction volume. Across these measures, popularity is concentrated among a small share of DApps, while many have relatively little activity or volume.

A. DApp Distribution

  • The study measures popularity by unique user accounts, transaction count, and transaction volume in ETH.It also compares DApp categories and examines changes in the number of DApps over time.Source: A. DApp Distribution · p. 4, §IV · p. 4

1) Popularity by Users:

2) Popularity by Transactions:

  • About 5% of DApps account for 80% of transactions, and over 80% have fewer than 10,000 transactions, indicating a long tail of rarely active DApps.The paper treats transactions as real user behaviours because they are added to blocks with gas paid.Source: 2) Popularity by Transactions · p. 4, Figure 4 · p. 4

3) Popularity by Transaction Volumes:

B. DApp Category

DApp categories differ in market presence, and their growth accelerated from 2017, with Games, Exchanges, Finance, Gambling, and High-risk showing distinct trajectories.

B. DApp Category

  • Games accounted for 29.5% of DApps but 8.4% of users, while Exchanges and Finance represented 61.5% and 25.6% of transaction volume.Games had 19.5% of transactions; Exchanges and Finance had 35.4% and 23.5% of users, respectively.Source: B. DApp Category · p. 5

C. Growth over Time

  • DApp numbers rose significantly from May 2017, and more DApps were published each day after February 2018.The dataset’s first DApp appeared on April 22, 2015.Source: Figure 6 · p. 5, C. Growth over Time · p. 5
  • Exchanges and Finance were early-growing categories; after May 2017, Games, Gambling, Exchanges, and Finance grew rapidly, with Games later overtaking the other two leading categories.The paper groups 17 categories, including Finance, Exchanges, Gambling, and High-risk; it describes High-risk as a tag for DApps such as investment traps and Ponzi-scheme games.Source: C. Growth over Time · p. 5, B. DApp Category · p. 5
  • By Dec. 31, 2018, Ethereum’s DApp market had 154 Gambling DApps and 130 High-risk DApps; High-risk DApps first appeared in May 2017 and grew more rapidly in February 2018, with a trend similar to Gambling’s.Source: C. Growth over Time · p. 5

V. DEVELOPMENT OF DAPPS

The study examines DApp openness at both project and smart-contract levels, then characterizes how contracts are organized and used. Most DApps use one contract, while multi-contract DApps exhibit three identified patterns.

A. Open Source

  • The study assessed openness separately for on-chain contracts and off-chain project code, which may be partially open, and classified DApps into six openness categories.Smart contracts are retrievable from the blockchain as unreadable bytecode, so source code must be submitted separately to be readable.Source: A. Open Source · pp. 5–6
  • Smart-contract openness was associated with higher maximum transaction counts, while DApps with all contracts closed source had fewer transactions.The authors suggest that smart-contract openness may improve DApp popularity.Source: Figure 8 · p. 6, A. Open Source · p. 6
  • Only 15.7% of DApps were fully open source, while 25.0% were fully closed source and 43.5% had all smart contracts open source.The project-level code was not open source for 54.9% of DApps, suggesting developers shared smart-contract code more often than DApp code.Source: Figure 7 · p. 6, A. Open Source · p. 6

B. Usage Patterns of Smart Contracts

  • For multi-contract DApps, leader-member contracts invoke one another, equivalent contracts have no invocation, and factory contracts deploy child contracts.The factory pattern can generate similar child contracts and is used in some Gambling DApps to create games with the same rules.Source: B. Usage Patterns of Smart Contracts · pp. 6–7
  • Over 75% of DApps used one smart contract; among multi-contract DApps, the median was three contracts and almost all had fewer than ten.The maximum observed was 1,881 contracts in one DApp.Source: B. Usage Patterns of Smart Contracts · p. 6, Figure 9 · p. 7
  • The researchers identified leader-member patterns in 194 DApps, equivalent patterns in 214, and factory patterns in 28; equivalent and factory patterns involved more contracts than leader-member.The counts of contracts were 199, 1,539, and 2,671, respectively; the authors report that developers more often design functionally independent contracts.Source: B. Usage Patterns of Smart Contracts · p. 7, Table IV · p. 7, Figure 10 · p. 7

VI. COST OF SMART CONTRACTS IN DAPPS

The paper studies deployment and execution costs because gas is required for smart-contract transactions and high execution costs reduce throughput and lengthen confirmation waits. Its deployment analysis compares usage patterns and examines contract complexity.

VI. COST OF SMART CONTRACTS IN DAPPS

  • Deployment and execution each require gas, and a transaction that exhausts its supplied gas fails and loses the gas sent.The paper treats gas used in deployment as reflecting contract complexity; high costs can prevent deployment under the block gas limit or reduce execution throughput and increase confirmation waits.Source: §VI · p. 7

1) Deployment Cost of Different Usage Patterns of Smart Contracts

2) Influence Factors:

The paper relates deployment cost to contract complexity measures and examines gas sent and used during executions. It finds that many users send substantially more gas than executions consume.

2) Influence Factors:

  • The deployment-cost regression found both NoF and LoC related to cost, with deployment cost more related to NoF.The separate linear regressions found relationships at the t<0.01 level; the multiple regression had a higher R2 than the individual regressions.Source: 2) Influence Factors · p. 8

B. Execution Cost of Smart Contracts

1) Gas Sent in Transactions:

  • 80% of contract executions cost less than 141,213 gas, while about 5% cost over 300,000 gas.The paper suggests users could send 141,213 gas to cover execution costs in 80% of cases.Source: Figure 12 · p. 8, 1) Gas Sent in Transactions · p. 8
  • About 5% of executions used all the gas sent, while 50% had 100,000 gas left and 75% had 200,000 gas left.The authors infer that over 100,000 gas is locked in about half of executions until transactions are confirmed.Source: Figure 12 · p. 8, 1) Gas Sent in Transactions · p. 8
  • In the median execution, users sent 199,366 gas but used 99,366, leaving 100,000 gas locked until confirmation.The study notes that gas remaining from an execution cannot be used until its transaction is confirmed.Source: 1) Gas Sent in Transactions · p. 8

2) Contract Executions with Internal Transactions:

Contract-execution costs vary with internal transactions and smart-contract usage patterns: executions with internal transactions cost more gas, while leader-member and factory patterns generally cost more than other patterns. The section also defines a function-invocation-weighted metric for representing average contract execution cost.

2) Contract Executions with Internal Transactions:

  • The analysis counts only internal transactions among smart contracts within a DApp, not downstream transactions among contracts in another DApp.The authors explain that developers of the initiating DApp do not have to account for internal transactions among the other DApp’s contracts.Source: 2) Contract Executions with Internal… · p. 9
  • Contract executions with internal transactions cost more gas than those without, as Figure 13 compares.Internal transactions are included in the external transactions that trigger them, and their costs are included in execution costs.Source: 2) Contract Executions with Internal… · p. 9, Figure 13 · p. 9

3) Difference among Smart Contract Usage Patterns:

  • The agas metric weights each function’s median invocation gas by its invocation count to represent a contract’s average execution cost.The authors introduce the metric because neither the arithmetic mean nor median represents the average level when execution-cost and invocation distributions are uneven.Source: 3) Difference among Smart Contract… · p. 9
  • Leader-member and factory pattern smart contracts generally cost more gas, while equivalent-pattern contracts have an agas distribution similar to single-pattern contracts.Figure 15 compares execution costs among usage patterns.Source: 3) Difference among Smart Contract… · p. 9, Figure 15 · p. 9

VII. FINDINGS AND IMPLICATIONS

The paper summarizes its findings and stakeholder implications, and describes its work as the first comprehensive study of blockchain-based DApps.

VII. FINDINGS AND IMPLICATIONS

  • Findings and implications for end-users, DApp developers, and blockchain vendors are summarized in Table VII.The findings come from preceding sections of the study.Source: §VII · p. 10

VIII. RELATED WORK

  • The authors characterize their work as the first comprehensive study to understand blockchain-based DApps.The related-work section surveys blockchain systems and traditional P2P applications.Source: §VIII · p. 10

A. Blockchain Systems

The paper reviews research on blockchain systems and traditional P2P applications, then concludes with a descriptive analysis of Ethereum DApps and identifies topics for future study.

A. Blockchain Systems

  • Blockchain research spans underlying mechanisms, applications, and data mining, including consensus and smart-contract mechanisms, sector uses, and analyses of transactions and contract code.The review also mentions efforts to decompile smart contracts into source code for further analysis.Source: A. Blockchain Systems · p. 10

B. Peer-to-peer Applications

  • Traditional P2P research covers security, performance, and application areas, while few studies address blockchain-based DApps despite their influence on the blockchains they use.The review notes some work intended to help developers build blockchain-based DApps.Source: B. Peer-to-peer Applications · p. 10

IX. CONCLUSION AND FUTURE WORK

  • The study descriptively analyzes 995 Ethereum DApps; future work will investigate DApp source code, project construction, on/off-chain synchronization, and throughput.The authors state that the paper mainly focuses on descriptive analysis of DApps’ transaction data.Source: §IX · p. 10
Loading 1909.00939v1…