<aside> <img src="/icons/book_gray.svg" alt="/icons/book_gray.svg" width="40px" />
This is a chapter from the book Token Economy (Third Edition) by Shermin Voshmgir. Paper & audio formats are available on Amazon and other bookstores. Find copyright information at the end of the page.
</aside>
Bitcoin’s success sparked a renaissance in P2P networks, leading to the development of numerous alternative blockchain networks and complementary Web3 protocols. The Bitcoin source code was modified multiple times, serving as a template for new blockchain networks that aimed to improve privacy, scalability, or network functionality.
The open-source nature of Bitcoin allowed developers to modify its system architecture. Some early projects sought to create faster or more private payment networks, such as “Litecoin” (which increased block speed by adjusting the consensus algorithms) or “Zcash” (which introduced alternative cryptographic proofs to enhance privacy by design). Other projects moved away from Bitcoin’s financial focus entirely. “Sia,” for example, built a decentralized file storage network, while Steemit built its own blockchain infrastructure to power a tokenized social media platform. Some networks were even created without a clear utility or just for fun, such as “Dogecoin,” which began as a meme but later gained traction as an internet tipping currency.
Eventually, the idea emerged to move away from single-purpose blockchain networks. Developers sought more flexible architectures that could handle any type of P2P transaction. Early projects like “Mastercoin” (now “Omni”) and “Colored Coins” experimented with using Bitcoin’s transaction metadata to represent assets or contracts, but these solutions were inefficient. Vitalik Buterin, who briefly contributed to these projects, recognized that Bitcoin’s scripting limitations made general-purpose applications difficult. He started the Ethereum project, which separated application execution from the core transaction processing layer, enabling easily programmable decentralized applications.
Ethereum’s innovative blockchain architecture and success inspired many projects. Some closely replicated Ethereum’s design with minor modifications, while others took inspiration from its versatility but diverged significantly in architecture. Notable examples include “Avalanche,” “Binance Smart Chain,” “Cardano,” “EOS,” “Polygon,” “Solana,” “Stellar.” While some of these networks gained significant market traction, others struggled to attract sustained adoption from developers, node operators, or users.
From a technological perspective, alternative blockchain networks tried to stand out by modifying different parts of Bitcoin’s original system architecture: the consensus mechanism, permissions, data structure, cryptographic primitives, or abstraction level. However, a key challenge for any new blockchain project is attracting developers, node operators, and users. Without a robust and engaged ecosystem, blockchain networks struggle to sustain themselves. While technology matters, community and network effects matter just as much. The proliferation of alternative networks has therefore been marked by varying degrees of success. Many failed to establish a compelling value proposition, suffered from poor execution, or faced competition from established ecosystems like Bitcoin and Ethereum, even in cases where the technological value proposition was sound.
One way to alter a blockchain protocol was to modify the consensus mechanism by tweaking it here or there. Over time, radically different consensus mechanisms emerged, most notably Proof-of-Stake and its variations. Few blockchain networks today use identical consensus mechanisms, which must always resolve and balance the following challenges: (i) How to achieve consensus on a unified history of transactions? (ii) How to align scarce resources with network security to deter malicious actors? (iii) How to mitigate security risks and attack vectors? (iv) How to avoid the concentration of power? Variations of Proof-of-Work, Proof-of-Stake, and Byzantine Fault Tolerant systems have been among the most widely adopted.
Protocol developers not only modified the consensus mechanism but also explored alternative data structures to address challenges related to network capacity, ledger data availability, and levels of decentralization. As previously explained, in traditional blockchain networks, the ledger is represented by a data structure of cryptographically linked transaction blocks that grows over time. Every node in the network must continuously synchronize its copy of the ledger, requiring constant broadband connectivity and increasing disk space to store the ever-expanding ledger. These issues are magnified in data-intensive networks like Ethereum, which requires additional metadata for processing much more complex applications. Compounding the problem, neither Bitcoin nor Ethereum (before the transition to Proof-of-Stake) provided direct economic incentives for operating full nodes, which only maintain a copy of the ledger but do not participate in the resource-intensive consensus process, leading to reduced participation in maintaining complete ledger copies and thus contributing to network centralization.
Efforts to address these challenges include dividing the ledger into smaller and more manageable partitions distributed across network participants (sharding), as well as mechanisms to prune or archive less critical ledger entries. Sharding was initially incorporated into Ethereum’s scalability roadmap as part of its transition to Proof-of-Stake. However, Ethereum shifted its focus toward other solutions (rollups and data availability sampling) rather than implementing full execution sharding in the near term (read more on this topic in the chapter “Scalability Challenge.”)
Other blockchain networks experimented with completely different data structures, such as Directed Acyclic Graphs (DAGs), to address the issue of ledger maintenance by removing the sequential confirmation bottleneck of blockchains. Unlike the data architecture of a chain of transaction blocks, DAGs do not bundle transaction data into sequential blocks. Instead, newly added transactions must reference and validate previous transactions, forming a network of interconnected data points. Each new transaction typically references two prior transactions, creating a graph that converges as validations occur. Nodes validating incorrect transactions find their additions rejected by other participants. Not all DAGs work the same way—some use parallel validation of transactions rather than linear confirmation.