Insights into Web3 native Network Design

Ever wonder why blockchains work the way they do? 

That’s usually because developers behind them have put months into thinking through the use case it’s aimed to cater to, the specifications required, and how it all fits together. In other words, a lot of Network Design goes into any blockchain protocol. 

This post will explain what network design entails, the potential trade-offs developers make, and what’s changing now that blockchains are increasingly becoming modular. We have also included some insights from the recent space we hosted featuring speakers from Avail, Tanssi, and Skale. 

What is Network Design? 

In the traditional IT context, network design refers to the planning and implementation of computer network infrastructure. This involves anything from the logical map attached to it, quantity, type, and location of network devices, IP addressing structure, and security. 

Similarly, when applying the concept to blockchains, it describes the process of planning and building a blockchain from scratch. 

“Network Design answers the question of how you arrange a specific infrastructure to run some logic on top of it” (Francisco, Tassi, on our Network Design Space)

As such, Network Design covers all the layers of the blockchain stack: 

• Hardware layer: the physical hardware that provides the capacity to run a blockchain. In general, there are three different node types involved in networks. Archive nodes store all the history, full nodes validate and execute transactions, and so-called light nodes. Together with a virtual machine, they offer the necessary operating system for dApps. 
• Data layer: this layer creates, manages, and encrypts data. It includes digital signatures that verify that wallet owners can spend funds and hashing algorithms. The data layer also specifies how data is stored and made available. It plays a crucial role in ensuring the integrity of the network. Most exciting cryptography, such as public-private keys and encryption, happens on this layer. 
• Network layer: this layer specifies how nodes in the network discover each other and communicate. Typically, new nodes joining the network must find a full node to download the latest state. 
• Consensus layer: nodes also have to agree on the state of a block and transactions. The consensus layer defines what consensus mechanism is employed to achieve agreement and what thresholds need to be met. Large networks these days run either Proof-of-Work (Bitcoin) or a version of Proof-of-Stake.
• App Layer: most average crypto users won’t ever directly interact with any layer below the app layer. It’s the interface to what’s sitting below: smart contracts run on top of distributed architecture. 

All of the above create a blockchain offering execution, settlement, security, and data availability. 

Yet, even though it’s tempting to think about network design mainly in the context of technology, it’s worth considering the human side of it. 

Ultimately, most networks are designed to serve humans and depend on the participation of people. As Stan highlighted in our space, any resilient network needs to account for the human factor and establish some checks and balances and an incentive structure that supports long-term growth. 

Network Design and the Blockchain Trilemma

The blockchain trilemma states that any given blockchain can only achieve two out of the three properties: decentralization, security, and scalability. Even though it was fashionable for a while for projects to advertise that they had solved the trilemma, it’s a claim to treat with caution. We have yet to see the emergence of a blockchain that has made the impossible possible. If anything, the trilemma has given rise to modular blockchains, which aim to solve it by de-coupling the core functions of a chain and optimizing each layer for maximal efficiency. 

Consequently, all current solutions do have trade-offs in one realm or the other, with the hope being that eventually, innovation and progress will help us solve the third. 

To illustrate: 

• Solana is highly scalable and fast. Yet, it also has high hardware requirements, which can lead to centralization since only professional node runners can participate. As Hardware accelerates, running nodes should become more accessible, allowing the network to decentralize further (In the ranking, Solana isn’t doing all that bad compared to other networks where it’d just take two entities to compromise the integrity) 
• Rollups, as of now, primarily operate with centralized sequencers. While some systems allow traders to exit on L1 if necessary (escape hatch), it still opens up the rollup for censorship and MEV extraction by the sequencer. 
• Farcaster has taken a pragmatic approach to building its sufficiently decentralized social network, trading off decentralization regarding the content you post for scalability and usability. While user IDs and wallets are on-chain, the rest of the infrastructure relies on 1000 of hubs that store data. After all, there is less of a problem if you double-post than if a network allows you to double-spend. 

In the end, the trade-offs teams make in network design reflect the users they want to cater to and their primary use case. With modularity, new opportunities arise to fix the trilemma, but they often come at the expense of composability and interoperability - important components for Network designers. 

Interoperability & Composability 

During the bear market, building activity consolidated in the EVM ecosystem because when the pie is shrinking, it’s best to go where there is a vast set of libraries, users, and other dApps to connect with. 

 Every man is an island. I stand by that. But clearly, some men are island CHAINS. Underneath, they are connected. - Will Freeman (About a boy)

What applies to men also applies to blockchains. All blockchain networks require developers to build on top of them to make use of their product: blockspace. Therefore, attracting them is crucial for adoption. A major make or breaking point is how well a network connects with other existing blockchain ecosystems, allowing dApps to be more easily discovered and attract liquidity.

Networks designed to be interoperable and composable with others have a better chance at survival than those that don’t. The downside of the movement to modular is an increase in complexity and fragmentation that can hinder development. As Leouarz pointed out during our space, “Ultimately, only devs who manage to abstract away all these complexities will be able to leverage the benefits.”

There are other pitfalls with composing networks that span multiple ecosystems. Differing times for finality introduce latency and hamper the user experience. Still, most crypto enthusiasts will agree that interoperable, composable networks are the future, and the current challenges are simply growing pains. 

Zero-Knowledge Cryptography could help facilitate cross-chain and layer communication without reducing security guarantees, but it’s early days, and projects trying to do this are largely in the research and PoC phases. 

Overall, Network Design is a fascinating topic for blockchain engineers who are trying to create new blockchains from scratch. Thanks to modular solutions like Avail, and appchain offerings such as Tanssi and Skale, launching your own chain has never been easier. 

Nevertheless, before you create a chain for the sake of it, don’t forget to carefully consider network design choices and ask yourself, “to chain or not to chain.” 

Not every use case warrants an entire blockchain; some can just as well be a dApp. Whether you decide to build a chain or a dApp, Subsquid has your back if you need on-chain data for any EVM and Substrate networks. DA integrations coming soon, as well as Solana. 

For more on Network Design, check out the recording of our recent Twitter Space.