Pith. sign in

REVIEW 3 major objections 5 minor 74 references

A First Look at Blockchain-based Decentralized Applications

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read This paper presents the first comprehensive empirical study of Ethereum DApps, analyzing 995 DApps and 29,846,075 transactions from 2018, and derives quantitative patterns for popularity, development practices, and running costs.

desk verdict A useful descriptive baseline of the early Ethereum DApp ecosystem, but the unvalidated sample filter and the regression overclaim need attention before the findings are treated as robust. read the letter →

arxiv 1909.00939 v1 pith:U4ELPVBU submitted 2019-09-03 cs.SE

classification cs.SE
keywords decentralizedapplicationsEthereumsmartcontractsempiricalstudytransactionanalysisgascostopensourceDAppecosystem
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper presents the first comprehensive empirical study of blockchain-based decentralized applications, using 995 Ethereum DApps and 29,846,075 transactions from 2018. It finds that popularity follows a Pareto distribution: a small group of finance, exchange, and gambling DApps accounts for most users, transactions, and volume, while most DApps are barely used. It also reports that only 15.7% of DApps are fully open source, about 75% rely on a single smart contract, and in the median contract execution half of the prepaid gas is left unused. These findings give users, developers, and platform vendors an evidence-based picture of how the early Ethereum DApp ecosystem actually behaves.

What carries the argument

The central object is the assembled dataset: 995 DApps with developer-supplied smart-contract addresses, their 5,158 contracts, and all 29,846,075 transactions initiated in 2018. The analytic machinery consists of three pieces: popularity metrics (unique users, transactions, and transaction volume), a classification of multi-contract usage patterns (leader-member, where an entry contract invokes member contracts; equivalent, where contracts are independent; and factory, where one contract deploys similar child contracts), and a gas-accounting analysis that separates deployment from execution, compares gas sent with gas used, and regresses deployment cost on lines of code and number of functions. The dataset carries the empirical claims, while the patterns and gas metrics supply the structure for the findings.

What would settle it

Repeat the same 2018 transaction analysis for the Ethereum DApps listed in the same directory but excluded because they lacked published contract addresses; if their popularity distribution, category mix, or gas usage differs systematically from the 995 DApps, the paper's aggregate findings would not generalize to the directory as a whole.

Watch

Extended reading notes

Core claim

The paper's central claim is that the early Ethereum DApp ecosystem is not a uniform market but follows strong empirical regularities. Popularity is highly concentrated: fewer than 5% of DApps carry about 80% of transactions, and most DApps have fewer than 1,000 users and fewer than 10,000 transactions over the year. Financially oriented categories dominate, with Exchanges and Finance together accounting for roughly 87% of transaction volume. On the development side, only 15.7% of DApps are fully open source, 52.3% of DApps have all smart contracts closed, and about 75% of DApps use a single smart contract; among multi-contract DApps the equivalent pattern is the most common. On cost, deployment gas correlates with both lines of code and number of functions, with number of functions the stronger driver, and in the median contract execution half of the prepaid gas is unused, leaving about 100,000 gas locked until confirmation.

Load-bearing premise

The findings stand or fall on whether the 995 DApps whose developers published smart-contract addresses represent all Ethereum DApps; if the omitted apps differ systematically, every aggregate percentage would shift.

Editorial extensions

If this is right

  • Users can treat 141,213 gas as a practical ceiling for ordinary contract executions, since 80% of the measured executions used no more than that, and sending more simply locks up the surplus Ether until confirmation.
  • Developers can lower execution costs by favoring the equivalent pattern, where contracts do not invoke one another, over leader-member or factory arrangements.
  • Open-sourcing smart contracts is associated with higher transaction counts, giving developers a concrete reason to publish contract source even when the full project remains closed.
  • Platform vendors can use the measured gas-left distribution to build better default gas limits and client-side gas estimators that return locked Ether to users sooner.
  • The rapid growth of High-risk and Gambling DApps after early 2018 suggests users need screening or warning mechanisms when choosing DApps.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The filter that keeps only DApps with published contract addresses could bias every aggregate finding; if the excluded DApps are mostly small or centralized, the true market may look even more concentrated, and the open-source percentages could be worse.
  • Because the study counts only on-chain transactions, DApps whose clients interact with contracts through centralized back ends are undercounted; the popularity rankings measure blockchain-visible usage, not necessarily total user activity.
  • The gas-left result points to a testable extension: a wallet that sets gas near the 80th-percentile value and measures confirmation refunds would show whether most locked gas can be returned without increasing failed transactions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents a descriptive empirical study of Ethereum-based decentralized applications (DApps). The authors collect 995 Ethereum DApps listed on State of the DApps as of January 2019, along with 5,158 associated smart contracts and 29,846,075 on-chain transactions from 2018. They analyze three research questions: the popularity distribution of DApps, development practices such as open-source status and smart-contract usage patterns, and the deployment and execution costs of smart contracts. The main reported findings are that DApp popularity follows a Pareto distribution with financial and gambling applications dominating; only 15.7% of DApps are fully open source; about 75% of DApps use a single smart contract; and typical contract executions leave large amounts of prepaid gas unused. The paper concludes with stakeholder-oriented implications for users, developers, and blockchain vendors.

Significance. If the methodology is sound, this is a useful descriptive baseline for the early Ethereum DApp ecosystem, and it is one of the first papers in software engineering to characterize DApps at this scale. The study's strengths include direct measurement of on-chain data, a broad coverage of categories, and practically actionable observations such as the gas-cost distributions. However, the absence of a released dataset, the unvalidated sampling filter, and the questionable regression interpretation currently limit reproducibility and the strength of the causal/implicational claims. The paper is likely to be of interest to the empirical software engineering and blockchain communities, provided the identified validity concerns are addressed.

major comments (3)
  1. [Section III] The study starts from 1,749 Ethereum DApps on State of the DApps and keeps only the 995 DApps for which developers supplied smart-contract addresses, but it then presents all aggregate results as properties of the Ethereum DApp ecosystem. The paper provides no validity check comparing the 995 included DApps with the 754 excluded ones on any available attribute, such as category, publication date, or presence of an external repository. Because supplying an address is a self-selected developer action that is plausibly correlated with activity, open-source behavior, and maintenance quality, the reported figures (open-source percentage, single-contract percentage, Pareto popularity distribution) could be artifacts of this filter. Please add a comparison of included and excluded DApps and a discussion of the potential selection bias, or explicitly reframe the conclusions as applying only to DApps with published contract addresses.
  2. [Section VI-A] The conclusion that NoF (number of functions) has more influence than LoC (lines of code) on deployment cost is based on raw regression coefficients with different units: 37,141.26 gas per function versus 1,514.68 gas per line of code. Such unstandardized coefficients are not directly comparable, especially because the univariate model with LoC alone achieves a higher R-squared (0.4066) than the model with NoF alone (0.2956). To support Finding F7 and the implication that 'reducing the number of functions could help more,' the paper should report standardized coefficients (beta weights), common-scale effect sizes, or an explicit model-comparison test, and should also check for multicollinearity between NoF and LoC.
  3. [Section V-A] The paper uses the association in Figure 8 to advise developers that open-sourcing smart contracts 'could improve the popularity of DApps.' This is a causal/implicational claim drawn from a raw correlation, and open-source status is likely confounded with DApp category, age, and development effort. The current evidence does not support the recommendation as stated. Please add a controlled or matched comparison (for example, within category and publication cohort) or soften the implication to an associational statement.
minor comments (5)
  1. [Section III] The text says '9,057,344,360 Ethers' while Table I reports '9,057,344.360 ETH.' These are inconsistent by a factor of 1,000; please reconcile the value and the notation.
  2. [Section VI-A] The sentence 'At the level of t¡0.01' appears to be a typo and should read 'p < 0.01.'
  3. [Section VI-A] The regression analysis does not state the sample size used for fitting the models, the number of contracts with source code and ABI data, or any residual diagnostics. Since only 2,568 of the 5,158 contracts have retrievable source code, please specify the effective sample size and whether the reported regressions are restricted to that subset.
  4. [Section VI-B] The agas metric weights per-function median gas by invocation count, but for functions with very few invocations the median is an unstable estimate. Please report the distribution of invocation counts and consider requiring a minimum invocation count before including a function in Eq. (1), or provide confidence intervals for the pattern comparisons in Figure 15.
  5. [Figures 3b, 4b, 5b] The x-axes of these figures appear to mix a linear origin (0) with logarithmic powers (10^1, 10^2, ...). Please use a consistent axis scale or explain how zero is represented on a logarithmic axis.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is a descriptive empirical study whose aggregate statistics and heuristics are self-contained summaries of its dataset, not predictions forced by fitted inputs or self-citations.

full rationale

This is a measurement/descriptive study, not a derivation chain: it reports distributions, category shares, open-source proportions, and cost percentiles over a collected dataset. No claimed result is an equation whose output is its input by construction. The gas recommendation (send 141,213 gas to cover 80% of executions) is a quantile of the same distribution, but it is presented as a descriptive summary and practical heuristic, not as an out-of-sample prediction or fitted parameter; the paper makes no independent claim that the 80% coverage rate was obtained from data other than the one used to define it. The agas metric (Eq. 1) is a weighted summary statistic, and the pattern taxonomy is a classification scheme; both are defined from the data, but no target finding is forced by the definitions. The sampling filter (1,749 to 995 DApps requiring developer-supplied contract addresses) is a potential external-validity threat, but it is a data-availability limitation, not a circular reduction. There are no load-bearing self-citations or imported uniqueness results. Overall, no circular step can be exhibited.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

This is an empirical study with no mathematical derivation; the ledger records the domain assumptions on which the central descriptive claims rest, plus the regression coefficients that are fitted to data.

free parameters (2)
  • Regression coefficient of number of functions (NoF) on deployment cost = 37141.26
    Estimated in the multiple linear regression in Table VI; the conclusion that NoF has more influence than LoC on deployment cost rests on this fitted coefficient.
  • Regression coefficient of lines of code (LoC) on deployment cost = 1514.68
    Estimated in the multiple linear regression in Table VI; used to compare against NoF in claiming that deployment cost is more related to NoF.
assumptions (4)
  • domain assumption State of the DApps is a complete and unbiased directory of Ethereum DApps, and the subset of DApps that expose smart contract addresses is representative of all Ethereum DApps.
    Stated in Section III; without it, the popularity and open-source percentages may not generalize.
  • domain assumption On-chain transactions to the listed smart contracts are a valid proxy for DApp usage, and off-chain client or server behavior need not be measured for popularity claims.
    Used throughout Sections IV and V; DApps with centralized backends may have usage invisible to transaction logs.
  • domain assumption Etherscan source code submissions and ABI data accurately reflect the deployed smart contracts and their functions.
    Assumed in Sections III and VI when computing LoC, NoF, and per-function gas metrics.
  • domain assumption Simulated execution of transactions correctly reproduces internal transactions and gas usage.
    Described in Section III as extracted by simulated executions and double checked against Etherscan; the check is partial and depends on simulation fidelity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A First Look at Blockchain-based Decentralized Applications." pith.science (2026). https://pith.science/paper/U4ELPVBU

@misc{pith2026190900939,
  author       = {Pith},
  title        = {Pith review of: A First Look at Blockchain-based Decentralized Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/U4ELPVBU}},
  note         = {Machine review of arXiv:1909.00939}
}
read the original abstract

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.

Figures

Figures reproduced from arXiv: 1909.00939 by the authors.

Figure 2
Figure 2. Three kinds of DApp architectures. Cost of smart contracts. As mentioned above, accounts have to pay gas for every transaction. Cost of a smart contract consists two parts: deployment and contract execution. The deployment of a smart contract can be seen as a contract execution of calling a special function constructor(). In this paper, we separate the deployment cost out of the general execution cost to study the t… view at source ↗
Figure 3
Figure 3. a shows the cumulative distribution function (CDF) of the percentage of DApp users against the DApp ranking by transactions. We can see that the DApp users follow the Pareto DApp Rank CDF 0% 20% 40% 60% 80% 100% 0 0.2 0.4 0.6 0.8 1 (a) Percentage of users against DApp rank. # of Users CDF 0 101 102 103 104 105 106 0 0.2 0.4 0.6 0.8 1 (b) Users of a DApp [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. DApp popularity by transactions. 2) Popularity by Transactions: Because all transactions are added to the block with paying gas, transactions can be seen as real behaviours of users. Figure 4a shows that the CDF of the percentage of transactions of DApps against DApp ranking by transactions. We can find that a few (about 5%) DApps have 80% of transactions. It follows the Pareto principle as well. Figure 4b shows tha… view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: DApp popularity by ETH trade. 3) Popularity by Transaction Volumes: In Ethereum, each transaction needs to pay gas, charged by Ethers, to miners, but they can transfer 0 Ether. Therefore, DApps having many [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: a shows how the number of DApps grew over time before Jan. 1st, 2019. In our dataset, the first DApp was published at April 22, 2015. The number of DApps grew Date DApps 2015−4−22 2016−1−16 2016−10−12 2017−7−9 2018−4−5 2018−12−31 0 250 500 750 1000 1250 1500 1750 2000 …
Figure 8
Figure 8. Figure 8: Distribution of num￾ber of transactions among different open-source cate￾gories [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Distribution of the number of smart contracts per DApp. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: Usage patterns of smart contracts. contract executions from user accounts. The process is like a factory producing products, so we call the pattern ”factory pattern”. The smart contract deployed first is the ”factory contract”, and smart contracts generated by the fac…
Figure 11
Figure 11. Figure 11: Deployment cost difference among smart contract [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Gas of contract executions. Figure 12a shows the distribution of number of contract executions to gas left. We can see that 50% of contract exe￾cutions have 100,000 gas left and 75% of contract executions have 200,000 gas left. About 5% of contract executions use all …
Figure 14
Figure 14. Figure 14: Contract 0x2a0c0DBEcC7E4D658f48E01e3fA353F [PITH_FULL_IMAGE:figures/full_fig_p009_14.png]
Figure 13
Figure 13. Figure 13: Execution cost difference between contract executions [PITH_FULL_IMAGE:figures/full_fig_p009_13.png]
Figure 15
Figure 15. Figure 15: Execution cost difference among smart contract usage [PITH_FULL_IMAGE:figures/full_fig_p009_15.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

74 extracted references · 71 canonical work pages

  1. [1]

    Dapp.com 2018 Dapp Market Report,

    “Dapp.com 2018 Dapp Market Report,” https://www.dapp.com/article/ annual-dapp-market-report-2018, January 2019

  2. [2]

    DApp Survey Results 2019,

    “DApp Survey Results 2019,” https://medium.com/fluence-network/ dapp-survey-results-2019-a04373db6452, January 2019

  3. [3]

    What is a dApp? Decentralized Application on the Blockchain,

    “What is a dApp? Decentralized Application on the Blockchain,” https: //blockchainhub.net/decentralized-applications-dapps/, 2019

  4. [4]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

  5. [5]

    BitTorrent,

    “BitTorrent,” https://www.bittorrent.com/, 2019

  6. [6]

    Bitmessage,

    “Bitmessage,” https://bitmessage.org/, 2019

  7. [7]

    Popcorn Time,

    “Popcorn Time,” https://popcorn-time.ch/, 2019

  8. [8]

    Delegated proof-of-stake (dpos),

    D. Larimer, “Delegated proof-of-stake (dpos),” Bitshare whitepaper , 2014

Show all 74 references
  1. [9]

    Ppcoin: peer-to-peer crypto-currency with proof- of-stake (2012),

    S. King and S. Nadal, “Ppcoin: peer-to-peer crypto-currency with proof- of-stake (2012),” URL https://peercoin. net/assets/paper/peercoin-paper. pdf.[Online, 2017

  2. [10]

    Scalable communication middleware for permissioned distributed ledgers,

    A. Barger, Y . Manevich, B. Mandler, V . Bortnikov, G. Laventman, and G. Chockler, “Scalable communication middleware for permissioned distributed ledgers,” in Proceedings of the 10th ACM International Systems and Storage Conference . ACM, 2017, p. 23

  3. [11]

    Rem: Resource-efficient mining for blockchains

    F. Zhang, I. Eyal, R. Escriva, A. Juels, and R. Van Renesse, “Rem: Resource-efficient mining for blockchains.” IACR Cryptology ePrint Archive, vol. 2017, p. 179, 2017. TABLE VII: Summary of findings and implications. Findings Implications Stakeholders F1. On the blockchain such ...

  4. [12]

    Algorand: Scaling byzantine agreements for cryptocurrencies,

    Y . Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand: Scaling byzantine agreements for cryptocurrencies,” in Proceedings of the 26th Symposium on Operating Systems Principles . ACM, 2017, pp. 51–68

  5. [13]

    Toward a service platform for developing smart contracts on blockchain in bdd and tdd styles,

    C.-F. Liao, C.-J. Cheng, K. Chen, C.-H. Lai, T. Chiu, and C. Wu-Lee, “Toward a service platform for developing smart contracts on blockchain in bdd and tdd styles,” in Service-Oriented Computing and Applications (SOCA), 2017 IEEE 10th International Conference on . IEEE, 2017, ...

  6. [14]

    Blockchain-oriented software engineering: challenges and new directions,

    S. Porru, A. Pinna, M. Marchesi, and R. Tonelli, “Blockchain-oriented software engineering: challenges and new directions,” in Proceedings of the 39th International Conference on Software Engineering Companion . IEEE Press, 2017, pp. 169–171

  7. [15]

    Obsidian: a safer blockchain programming language,

    M. Coblenz, “Obsidian: a safer blockchain programming language,” in Proceedings of the 39th International Conference on Software Engineer- ing Companion. IEEE Press, 2017, pp. 97–99

  8. [16]

    Trustless intermediation in blockchain-based decentralized service mar- ketplaces,

    M. Klems, J. Eberhardt, S. Tai, S. H ¨artlein, S. Buchholz, and A. Tidjani, “Trustless intermediation in blockchain-based decentralized service mar- ketplaces,” in International Conference on Service-Oriented Computing. Springer, 2017, pp. 731–739

  9. [17]

    On the design of a blockchain platform for clinical trial and precision medicine,

    Z. Shae and J. J. Tsai, “On the design of a blockchain platform for clinical trial and precision medicine,” in 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS) . IEEE, 2017, pp. 1972–1980

  10. [18]

    Supply chain object discovery with semantic-enhanced blockchain,

    M. Ruta, F. Scioscia, S. Ieva, G. Capurso, and E. Di Sciascio, “Supply chain object discovery with semantic-enhanced blockchain,” in Proceed- ings of the 15th ACM Conference on Embedded Network Sensor Systems. ACM, 2017, p. 60

  11. [19]

    When trust saves enegry-a reference franework for proof-of-trust (pot) blockchains,

    L. Bahri and S. Girdzijauskas, “When trust saves enegry-a reference franework for proof-of-trust (pot) blockchains,” in The Web Conference

  12. [20]

    Blockchain based data integrity service framework for iot data,

    B. Liu, X. L. Yu, S. Chen, X. Xu, and L. Zhu, “Blockchain based data integrity service framework for iot data,” in Web Services (ICWS), 2017 IEEE International Conference on . IEEE, 2017, pp. 468–475

  13. [21]

    Trusternity: Auditing trans- parent log server with blockchain,

    H.-L. Nguyen, C.-L. Ignat, and O. Perrin, “Trusternity: Auditing trans- parent log server with blockchain,” in Companion of the The Web Conference 2018 on The Web Conference 2018 . International World Wide Web Conferences Steering Committee, 2018, pp. 79–80

  14. [22]

    Evaluating suitability of applying blockchain,

    S. K. Lo, X. Xu, Y . K. Chiam, and Q. Lu, “Evaluating suitability of applying blockchain,” in Engineering of Complex Computer Systems (ICECCS), 2017 22nd International Conference on . IEEE, 2017, pp. 158–161

  15. [23]

    A fistful of bitcoins: characterizing payments among men with no names,

    S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. V oelker, and S. Savage, “A fistful of bitcoins: characterizing payments among men with no names,” in Proceedings of the 2013 conference on Internet measurement conference . ACM, 2013, pp. 127–140

  16. [24]

    Quantitative analysis of the full bitcoin trans- action graph,

    D. Ron and A. Shamir, “Quantitative analysis of the full bitcoin trans- action graph,” in International Conference on Financial Cryptography and Data Security . Springer, 2013, pp. 6–24

  17. [25]

    Detecting ponzi schemes on ethereum: Towards healthier blockchain technology,

    W. Chen, Z. Zheng, J. Cui, E. Ngai, P. Zheng, and Y . Zhou, “Detecting ponzi schemes on ethereum: Towards healthier blockchain technology,” in Proceedings of the 2018 World Wide Web Conference on World Wide Web. International World Wide Web Conferences Steering Committee, 2018...

  18. [26]

    scompile: Critical path identification and analysis for smart contracts,

    J. Chang, B. Gao, H. Xiao, J. Sun, and Z. Yang, “scompile: Critical path identification and analysis for smart contracts,” arXiv preprint arXiv:1808.00624, 2018

  19. [27]

    Storj a peer- to-peer cloud storage network,

    S. Wilkinson, T. Boshevski, J. Brandoff, and V . Buterin, “Storj a peer- to-peer cloud storage network,” 2014

  20. [28]

    State of the DApps,

    “State of the DApps,” https://www.stateofthedapps.com, 2019

  21. [29]

    Ethereum Project,

    “Ethereum Project,” https://www.ethereum.org/, 2019

  22. [30]

    Ethereum (ETH) Blockchain Explorer,

    “Ethereum (ETH) Blockchain Explorer,” https://etherscan.io/, 2019

  23. [31]

    “Github,” https://github.com/, 2019

  24. [32]

    Hyperledger fabric: a distributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y . Manevich et al. , “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference . AC...

  25. [33]

    Smart contracts, 1994,

    N. Szabo, “Smart contracts, 1994,” Virtual School, 1994

  26. [34]

    Smart contracts: building blocks for digital markets,

    ——, “Smart contracts: building blocks for digital markets,” EXTROPY: The Journal of Transhumanist Thought,(16) , 1996

  27. [35]

    Android Apps on Google Play,

    “Android Apps on Google Play,” https://play.google.com/store/apps, 2019

  28. [36]

    IDEX - Decentralized Ethereum Asset Exchange,

    “IDEX - Decentralized Ethereum Asset Exchange,” https://idex.market/, 2019

  29. [37]

    A detailed and real-time performance monitoring framework for blockchain systems,

    P. Zheng, Z. Zheng, X. Luo, X. Chen, and X. Liu, “A detailed and real-time performance monitoring framework for blockchain systems,” in 2018 IEEE/ACM 40th International Conference on Software Engi- neering: Software Engineering in Practice Track (ICSE-SEIP) . IEEE, 2018, pp. 134–143

  30. [38]

    On the security and performance of proof of work blockchains,

    A. Gervais, G. O. Karame, K. W ¨ust, V . Glykantzis, H. Ritzdorf, and S. Capkun, “On the security and performance of proof of work blockchains,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security . ACM, 2016, pp. 3–16

  31. [39]

    A blockchain-enabled trustless crowd-intelligence ecosystem on mobile edge computing,

    J. Xu, S. Wang, B. Bhargava, and F. Yang, “A blockchain-enabled trustless crowd-intelligence ecosystem on mobile edge computing,” IEEE Transactions on Industrial Informatics , 2019

  32. [40]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016, pp. 254–269

  33. [41]

    Blockchain challenges and opportunities: a survey,

    Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain challenges and opportunities: a survey,” International Journal of Web and Grid Services , vol. 14, no. 4, pp. 352–375, 2018

  34. [42]

    Monoxide: Scale out blockchains with asyn- chronous consensus zones,

    J. Wang and H. Wang, “Monoxide: Scale out blockchains with asyn- chronous consensus zones,” in 16th {USENIX} Symposium on Net- worked Systems Design and Implementation ( {NSDI} 19), 2019, pp. 95–112

  35. [43]

    A generic decentralized trust management framework,

    R. Friedman and A. Portnoy, “A generic decentralized trust management framework,”Software: Practice and Experience, vol. 45, no. 4, pp. 435– 454, 2015

  36. [44]

    A platform for p2p agent-based collaborative applications,

    D. Briola, D. Micucci, and L. Mariani, “A platform for p2p agent-based collaborative applications,” Software: Practice and Experience , vol. 49, no. 3, pp. 549–558, 2019

  37. [45]

    An adaptive gas cost mechanism for ethereum to defend against under- priced dos attacks,

    T. Chen, X. Li, Y . Wang, J. Chen, Z. Li, X. Luo, M. H. Au, and X. Zhang, “An adaptive gas cost mechanism for ethereum to defend against under- priced dos attacks,” in International Conference on Information Security Practice and Experience . Springer, 2017, pp. 3–24

  38. [46]

    Under-optimized smart contracts devour your money,

    T. Chen, X. Li, X. Luo, and X. Zhang, “Under-optimized smart contracts devour your money,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2017, pp. 442–446

  39. [47]

    Gigahorse: Thor- ough, declarative decompilation of smart contracts,

    N. Grech, L. Brent, B. Scholz, and Y . Smaragdakis, “Gigahorse: Thor- ough, declarative decompilation of smart contracts,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) . IEEE, 2019

  40. [48]

    A framework for p2p application development,

    J. Walkerdine, D. Hughes, P. Rayson, J. Simms, K. Gilleade, J. Mariani, and I. Sommerville, “A framework for p2p application development,” Computer Communications, vol. 31, no. 2, pp. 387–401, 2008

  41. [49]

    Trusted computing: Pro- viding security for peer-to-peer networks,

    S. Balfe, A. D. Lakhani, and K. G. Paterson, “Trusted computing: Pro- viding security for peer-to-peer networks,” in Fifth IEEE International Conference on Peer-to-Peer Computing (P2P’05) . IEEE, 2005, pp. 117–124

  42. [50]

    Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,

    A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,” in 2016 IEEE symposium on security and privacy (SP) . IEEE, 2016, pp. 839–858

  43. [51]

    Napster: Home,

    “Napster: Home,” https://us.napster.com/, 2019

  44. [52]

    Proofware: Proof of useful work blockchain consensus protocol for decentralized applications,

    Z. Dong, Y . C. Lee, and A. Y . Zomaya, “Proofware: Proof of useful work blockchain consensus protocol for decentralized applications,” arXiv preprint arXiv:1903.09276, 2019

  45. [53]

    Measurement study of peer-to-peer file sharing systems,

    S. Saroiu, P. K. Gummadi, and S. D. Gribble, “Measurement study of peer-to-peer file sharing systems,” in Multimedia computing and networking 2002 , vol. 4673. International Society for Optics and Photonics, 2001, pp. 156–171

  46. [54]

    The bittorrent p2p file-sharing system: Measurements and analysis,

    J. Pouwelse, P. Garbacki, D. Epema, and H. Sips, “The bittorrent p2p file-sharing system: Measurements and analysis,” in International Workshop on Peer-to-Peer Systems. Springer, 2005, pp. 205–216

  47. [55]

    Pollution in p2p file sharing systems,

    J. Liang, R. Kumar, Y . Xi, and K. W. Ross, “Pollution in p2p file sharing systems,” in Proceedings IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies. , vol. 2. IEEE, 2005, pp. 1174–1185

  48. [56]

    An empirical study of collusion behavior in the maze p2p file-sharing system,

    Q. Lian, Z. Zhang, M. Yang, B. Y . Zhao, Y . Dai, and X. Li, “An empirical study of collusion behavior in the maze p2p file-sharing system,” in 27th International Conference on Distributed Computing Systems (ICDCS’07). IEEE, 2007, pp. 56–56

  49. [57]

    Peer-to-peer file-sharing over mobile ad hoc networks,

    G. Ding and B. Bhargava, “Peer-to-peer file-sharing over mobile ad hoc networks,” in IEEE Annual Conference on Pervasive Computing and Communications Workshops, 2004. Proceedings of the Second . IEEE, 2004, pp. 104–108

  50. [58]

    Enhancing p2p file-sharing with an internet-scale query processor,

    B. T. Loo, J. M. Hellerstein, R. Huebsch, S. Shenker, and I. Stoica, “Enhancing p2p file-sharing with an internet-scale query processor,” in Proceedings of the Thirtieth international conference on Very large data bases-Volume 30. VLDB Endowment, 2004, pp. 432–443

  51. [59]

    The scalability of swarming peer-to-peer content delivery,

    D. Stutzbach, D. Zappala, and R. Rejaie, “The scalability of swarming peer-to-peer content delivery,” in International Conference on Research in Networking. Springer, 2005, pp. 15–26

  52. [60]

    Delivery optimization - a deep dive,

    “Delivery optimization - a deep dive,” https://channel9.msdn.com/ Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2048, 2017

  53. [61]

    Tor project — anonymity online,

    “Tor project — anonymity online,” https://www.torproject.org/, 2019

  54. [62]

    R: The r project for statistical computing,

    “R: The r project for statistical computing,” https://www.r-project.org/, 2019

  55. [63]

    All cryptocurrencies — coinmarketcap,

    “All cryptocurrencies — coinmarketcap,” https://coinmarketcap.com/all/ views/all/, 2019

  56. [64]

    P2p media streaming with html5 and webrtc,

    J. K. Nurminen, A. J. Meyn, E. Jalonen, Y . Raivio, and R. G. Marrero, “P2p media streaming with html5 and webrtc,” in 2013 IEEE Confer- ence on Computer Communications Workshops (INFOCOM WKSHPS) . IEEE, 2013, pp. 63–64

  57. [65]

    Building a cooperative p2p-tv application over a wise network: the approach of the european fp-7 strep napa-wine,

    E. Leonardi, M. Mellia, A. Horvath, L. Muscariello, S. Niccolini, D. Rossi, and K. Young, “Building a cooperative p2p-tv application over a wise network: the approach of the european fp-7 strep napa-wine,” IEEE Communications Magazine , vol. 46, no. 4, pp. 20–22, 2008

  58. [66]

    A self-adaptive alm architecture for p2p media streaming,

    M. Amad, A. Meddahi, and G. Vanwormhoudt, “A self-adaptive alm architecture for p2p media streaming,” in 2015 International Conference on Protocol Engineering (ICPE) and International Conference on New Technologies of Distributed Systems (NTDS) . IEEE, 2015, pp. 1–6

  59. [67]

    Demonstrating the impact of p2p streaming on video quality,

    L. Abeni, C. Kiraly, R. Birke, M. Mellia, E. Leonardi, S. Traverso, and R. L. Cigno, “Demonstrating the impact of p2p streaming on video quality,” 2019

  60. [68]

    Dapp developers survey results,

    “Dapp developers survey results,” https://hackernoon.com/ dapp-developers-survey-results-1c763901e756, 2019

  61. [69]

    Cross-layer mobile chord p2p protocol design for vanet,

    C.-L. Liu, C.-Y . Wang, and H.-Y . Wei, “Cross-layer mobile chord p2p protocol design for vanet,” International Journal of Ad Hoc and Ubiquitous Computing, vol. 6, no. 3, pp. 150–163, 2010

  62. [70]

    The flip markov chain and a randomising p2p protocol,

    C. Cooper, M. Dyer, and A. J. Handley, “The flip markov chain and a randomising p2p protocol,” in Proceedings of the 28th ACM symposium on Principles of distributed computing . ACM, 2009, pp. 141–150

  63. [71]

    Enhancing data authenticity and integrity in p2p systems,

    X. Zhang, S. Chen, and R. Sandhu, “Enhancing data authenticity and integrity in p2p systems,” IEEE Internet computing , vol. 9, no. 6, pp. 42–49, 2005

  64. [72]

    Towards collaborative security and p2p intrusion detection,

    M. E. Locasto, J. J. Parekh, A. D. Keromytis, and S. J. Stolfo, “Towards collaborative security and p2p intrusion detection,” in Proceedings from the Sixth Annual IEEE SMC Information Assurance Workshop . IEEE, 2005, pp. 333–339

  65. [73]

    Understanding ethereum via graph analysis,

    T. Chen, Y . Zhu, Z. Li, J. Chen, X. Li, X. Luo, X. Lin, and X. Zhange, “Understanding ethereum via graph analysis,” inIEEE INFOCOM 2018- IEEE Conference on Computer Communications . IEEE, 2018, pp. 1484–1492

  66. [2018]

    1165–1169

    ACM Digital Library, 2018, pp. 1165–1169

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.