Mind the Gap: Trade-Offs between Distributed Ledger Technology Characteristics

1 Introduction

• Improving one DLT characteristic can interfere with another, and these trade-offs make a universal design unsuitable across applications.Technical differences can also impede migration between distributed ledgers, making design choice consequential for long-term viability.Source: §1 · p. 2
• Prior research often examines characteristics for particular use cases or considers only sparse dependencies, leaving findings scattered across disciplines.The paper identifies a need to synthesize dependencies and resulting trade-offs comprehensively.Source: §1 · p. 2
• The study identifies 40 DLT characteristics grouped into six properties, explains 24 trade-offs, and consolidates findings into six DLT archetypes.The archetypes indicate benefits and drawbacks associated with choosing and configuring a design for a particular DLT property.Source: §1 · pp. 2–3
• The archetypes aim to help practitioners and researchers understand which application drawbacks result from particular configurations of DLT characteristics.The work also presents a foundation for research on assessing DLT design suitability.Source: §1 · p. 3

2.1 Distributed Ledger Technology

• DLT designs instantiate concepts with concrete characteristics; replicated ledgers rely on consensus, while designs differ in data structures, permissions, and finality.The section also describes decentralization in terms of independent validating-node controllers and their nodes.Source: §2.1 · pp. 3–6

2.2 Attack Vectors and Vulnerabilities

• The review covers integrity attacks including Sybil, partition-based, double-spending, bribery, selfish-mining, and long-range attacks, as well as the blockchain anomaly.Partition-based attacks exploit forks and information asymmetry in public-permissionless designs with probabilistic finality.Source: §2.2 · pp. 6–8

2.3 Smart Contracts and Respective Vulnerabilities

• Smart contracts execute customized business logic, but vulnerabilities include unsafe arithmetic, unbounded loops, reentrancy, and errors from external calls.Public-permissionless designs use gas pricing to constrain execution; insufficient gas cancels execution and requires appropriate error handling.Source: §2.3 · pp. 8–9

2.4 Prior Research on Trade-Offs between DLT Characteristics

• Prior research is divided across description, analysis, application, and guidance, with limited holistic synthesis of dependencies and their practical application drawbacks.Existing guidance is often abstract and generic, while some analyses include few characteristics or omit application implications.Source: §2.4 · pp. 9–10

3 Method

• The study’s three-step approach moves from identifying characteristics to analyzing trade-offs and deriving archetypes and application implications.The characteristic review combined literature analysis with a survey of DLT experts.Source: §3 · p. 10

3.1 Identification of DLT Characteristics

• The review identified and consolidated DLT characteristics from literature, grouped them into properties, and refined definitions through expert feedback.It analyzed 191 relevant articles and extracted 277 characteristics; no new master variable emerged in the final 27 articles reviewed.Source: §3.1 · pp. 10–11

3.2 Uncovering Trade-Offs Between DLT Characteristics

• Researchers extracted and abstracted dependencies into trade-offs, then assessed them across seven DLT designs through individual ratings and consensus discussions.The designs included Bitcoin, Ethereum, Hyperledger Fabric, RChain, soteriaDAG, IOTA, and Nano.Source: §3.2 · p. 11

3.3 Configuration of DLT Archetypes

• Each archetype prioritizes characteristics associated with a target DLT property while accounting for trade-offs and resulting application drawbacks.For example, the flexibility archetype prioritizes adequate block size over transaction fees.Source: §3.3 · p. 12

• The literature review identified 40 DLT characteristics relevant to assessing a DLT design’s viability for an application.The characteristics are presented in Table 5.Source: §4.1 · p. 12
• The 40 characteristics were grouped into six DLT properties.The properties are presented in Table 4.Source: §4.1 · p. 12
• The review also identified trade-offs between DLT characteristics and lists them in Table 6.Source: §4.1 · p. 12

• Smart-contract oracles enable more flexibility in defining conditions that must be fulfilled before transactions are issued.Source: §A.1 · p. 12
• Every node requests the oracle when it executes a smart contract that invokes one.Source: §A.1 · p. 12
• Insufficient oracle bandwidth can make near-simultaneous node requests a performance bottleneck.Source: §A.1 · p. 12

• Bitcoin does not support Turing-complete smart contracts, limiting the flexibility of its smart contracts.Source: §A.2 · p. 13
• For Bitcoin, transaction-processing time complexity is at most k*N, where N is payload bytes and k is a constant factor.Source: §A.2 · p. 13
• Bitcoin uses transaction fees to incentivize validating nodes to prefer transaction validation, rather than needing a mechanism such as Ethereum gas to interrupt potential infinite loops.Source: §A.2 · p. 13

Table 5 cont.: Identified DLT characteristics

• Transaction fees in Turing-complete designs incentivize nodes to execute contracts and help prevent vulnerabilities from infinite loops.Timeouts can constrain contract flexibility, while execution pricing charges users in proportion to computational operations.Source: Table 5 cont.: Identified DLT… · p. 14

A.3 Turing-complete Smart Contracts vs. Transaction Validation Speed

• Broader smart-contract functionality increases complexity and execution time, slowing transaction processing and validation.Support for expressive languages such as C++, Java, or Solidity enables this functionality.Source: §A.3 · p. 14

B.1 Maintainability vs. Availability

• More independently controlled nodes increase ledger redundancy but make client updates harder to coordinate, raising maintenance effort.Bitcoin and LiteCoin updates such as SegWit and SegWit2x took weeks to agree on.Source: §B.1 · pp. 14–15

B.2 Maintainability vs. Integrity

• Reducing independently maintained nodes eases updates but weakens integrity through lower fault tolerance; tamper-resistant contract updates also require redeployment and reference changes.Relaxing smart-contract tamper-resistance makes automated agreement enforcement vulnerable to malicious behavior.Source: §B.2 · p. 15

B.3 Turing-complete Smart Contracts vs. Confidentiality

• Public smart-contract code and transaction triggers expose information, while oracles can see exchanged data; private-contract approaches use private and public parts with zero-knowledge proofs.External services require at least one trusted party, and protected enclaves still carry risks of key leakage or centralized failures.Source: §B.3 · p. 15

C.1 User Unidentifiability vs. Resource Consumption

• Unidentifiability requires additional computational power, storage, or runtime, including for added data structures or zero-knowledge proofs.The cited examples include extra storage and multiple message exchanges for validation.Source: §C.1 · p. 15

C.2 User Unidentifiability vs. Throughput

• More decentralized networks make node identities vaguer, but mixing and fresh transaction keypairs add preprocessing that reduces throughput.Smaller permissioned networks with identifiable nodes can use faster consensus mechanisms such as PBFT.Source: §C.2 · p. 16

D.1 Node Controller Verification vs. Ease of Node Setup

• Permissioned designs use identity verification and permissions, while PKI adds certificate effort and reliance on a trusted certification authority.Public-permissionless designs such as Bitcoin or Ethereum require only installation of an open-source client to participate.Source: §D.1 · p. 16

E.1 Block Creation Interval vs. Stale Block Rate; F.1 Block Creation Interval vs. Degree of Decentralization

• Shorter block intervals can increase stale blocks when propagation delays prevent nodes learning of new blocks in time; long intervals can increase mining-reward variance and encourage pools that reduce decentralization.The passage links stale blocks to computational inefficiency and pool formation to miner collusion.Source: §E.1 · p. 16, §F.1 · p. 16

F.2 Confirmation Latency vs. Degree of Decentralization; F.3 Throughput vs. Degree of Decentralization; G.1 Block Size vs. Transaction Fee

• High decentralization can protect against Byzantine behavior but raises confirmation latency; throughput gains commonly trade off decentralization, while block-size limits or fees constrain flexibility.Total-finality mechanisms often use smaller validator sets; fixed block-size limits restrict included data, whereas Ethereum requires transaction fees to address potentially huge blocks.Source: §F.2 · p. 16, §F.3 · p. 17, §G.1 · p. 17

H.1 Confirmation Latency vs. Fault Tolerance

• A block interval set too short can classify too many nodes as failed and weaken robustness, while one set too long decreases responsiveness.The targeted interval in Bitcoin and Ethereum expresses a timing assumption tied to expected block propagation time.Source: §H.1 · pp. 17–18
• Timing assumptions must balance faster confirmation against stale-block risk and the number of tolerable malicious nodes.Blocks created before peers receive the last valid block can increase forks; longer intervals increase the time needed to append enough transactions for commitment.Source: §H.1 · p. 17

H.2 Throughput vs. Consistency

• Larger blocks can raise throughput, but their longer propagation delays increase stale blocks and inconsistent ledger views.For Bitcoin and Ethereum, the share of created blocks committed to the main chain becomes low as block size and propagation delay increase.Source: §H.2 · p. 18
• In PoW forkable designs, throughput improvements can degrade consistency and increase vulnerability.Inconsistent states persist until forks are resolved and facilitate successful attacks.Source: §H.2 · p. 18
• BlockDAGs and TDAGs can offer higher throughput and scalability without a block-size bound, but they are more complex and may converge nondeterministically.Nodes need not store identical ledger versions in these systems.Source: §H.2 · p. 18

H.3 Throughput vs. Fault Tolerance

• Bitcoin averages 7 transactions per second and 10 min to commit, while tolerating up to 50% fraudulent validating nodes.Source: §H.3 · p. 18
• Finality-preserving consensus synchronizes node states with message complexity O(n^2), making its cost rise sharply as node count grows.Source: §H.3 · p. 18
• PBFT in Hyperledger Fabric achieves 3,000 transactions per second, but tolerates only a limited number of faulty validating nodes.Source: §H.3 · p. 18

H.4 Throughput vs. Integrity

• Larger blocks raise throughput but lengthen propagation delays, increasing fork and attack risks to integrity; longer block intervals mitigate forks but reduce throughput.Source: §H.4 · p. 18

I.1 Degree of Decentralization vs. Maintainability

• Public-permissionless designs are harder to maintain because their large, unverified networks inhibit enforcing software updates, unlike private-permissioned designs with identifiable controllers.Source: §I.1 · p. 19

J.1 Degree of Decentralization vs. Integrity

• Large public-permissionless networks make shared malicious intent less likely, strengthening integrity; the decentralization–integrity trade-off chiefly concerns probabilistic-finality designs.Source: §J.1 · p. 19

K.1 Degree of Decentralization vs. Transaction Fee

• PoW-based probabilistic-finality designs use transaction fees to reward resource contributions, whereas voting-based mechanisms can avoid fees but support less decentralization.Source: §K.1 · pp. 19–20

L.1 Strength of Cryptography vs. Support for Constrained Devices

• Stronger cryptography requires more memory and computation, making resource-intensive algorithms difficult for constrained devices such as microcontrollers.Source: §L.1 · pp. 20–21

M.1 Confidentiality vs. Integrity

• Private networks can improve confidentiality, but known nodes make network topology easier to map, facilitating partition attacks that threaten ledger integrity.Source: §M.1 · p. 21

M.2 Consistency vs. Availability

• More ledger replications increase availability, but larger networks and propagation delays slow consistency across nodes.Source: §M.2 · p. 21

4.2 DLT Design Archetypes for Applications on DLT

• The six archetypes consolidate trade-offs into application-oriented design profiles, each reflecting benefits and drawbacks of choosing and configuring a DLT design for a target property.Source: §4.2 · p. 21
• Flexibility-oriented designs favor smart-contract expressiveness, interoperability, decentralization, maintainability, and throughput, but these goals can increase resource use and slow validation.Source: §4.2 · pp. 21–22
• Opaqueness-oriented designs prioritize confidentiality and user unidentifiability, but anonymization can slow performance, impair auditability, and limit constrained-device support.Source: §4.2 · pp. 22–23
• Performance-oriented designs seek high throughput, low confirmation latency, low resource use, and maintainability, often through few validators or relaxed consistency assumptions.Source: §4.2 · pp. 23–24
• Policy-oriented designs emphasize governance, updates, auditability, traceability, and non-repudiation, while adapting to future regulation can conflict with integrity and require off-chain sensitive data.Source: §4.2 · p. 24
• Practicality-oriented designs prioritize usability, throughput, low fees, constrained-device support, and interoperability, but may have poor fault tolerance, relaxed consistency, and reduced confidentiality.Source: §4.2 · pp. 24–25
• Security-oriented designs prioritize availability, fault tolerance, integrity, and confidentiality, yet decentralization and anonymization can complicate governance and auditing.Source: §4.2 · pp. 25–26

5.1 Principle Findings

• Twenty-four trade-offs among forty characteristics grouped into six properties show why purely performance- or security-oriented designs may be infeasible.Performance and security each exhibit 11 trade-offs.Source: §5.1 · p. 26
• Archetypes show that no DLT design satisfies every application’s requirements; contradictory choices, such as performance versus security, require interoperability to synchronize designs.Some archetypes can support one another, such as opaqueness and security.Source: §5.1 · p. 26
• Industrial applications trend toward private DLTs for performance and confidentiality, while DAG-based designs relax consistency for throughput and lower resource use but often lack widespread Turing-complete contracts.Private designs tend to be less decentralized; several DAGs have limited flexibility because smart-contract support is not widespread.Source: §5.1 · pp. 26–27

5.2 Main Lessons to be Learned

• Practitioners can use the trade-offs and archetypes to assess design benefits and drawbacks against application requirements before development, potentially avoiding unsuitable choices and wasted resources.The overview can also support requirements engineering for DLT applications.Source: §5.2 · p. 27
• The synthesis connects four previously disconnected DLT research streams and offers archetypes as a basis for preselecting designs and supporting future models of characteristic dependencies.The four streams are description, analysis, application, and guidance.Source: §5.2 · p. 27

5.3 Limitations

• The inventory reflects published DLT research, mainly on blockchain and application-relevant characteristics, and its trade-offs are only partially generalizable beyond frequently studied designs.Most application studies examined Bitcoin, Ethereum, or Hyperledger Fabric; the authors could not identify BlockDAG- or TDAG-specific trade-offs in the reviewed literature and focused predominantly on negative effects.Source: §5.3 · pp. 27–28

5.4 Future Research

• Future work should quantify trade-offs under varying conditions and across DLT concepts, supporting decision systems and monitoring; cross-chain interoperability is another research avenue.The authors note that consensus mechanisms and additional services can affect the strength or presence of trade-offs.Source: §5.4 · p. 28

5.5 Conclusion

• The conclusion presents archetypes and prevalent trade-offs as tools for making DLT design configuration challenges more transparent and avoiding unsuitable choices.The authors suggest DLT’s potential may extend to decentralized applications beyond restrictive Bitcoin transactions.Source: §5.5 · p. 28