Monolithic vs Multichain — Why the Right Dapp Architecture Matters
This article is part of a multi-part series called Thinking Decentralized. In this instance, we look at why you might *not* want to create a monolithic application structure — based either on transactions entirely within a mainnet or even use a single sidechain that ties into a mainnet. Instead, we look at how using multiple elastic sidechains that connect to a public mainnet via interchain messaging or similar mechanisms is a much better and more flexible solution.
Definition of a Sidechain
A sidechain is a blockchain network that connects with a main blockchain network, most often a public one such as the Ethereum mainnet. A sidechain adopts the same underlying philosophy in terms of preservation of transactions via a chain of transaction blocks but it may use a different consensus algorithm and/or validation method. It also may contain additional features not found in the mainnet. Such features could include additional storage options, permissioned access, zero knowledge proofs, and/or alternative fee mechanisms.
The recommendation to architect and create blockchain solutions using multiple elastic sidechains should not be all that surprising when you look at other architectural patterns in other modern application development situations. Here are just a few patterns of note.
Lessons from Databases
Lessons from working with databases demonstrates that using a single database for all the data within an application is not the wisest course. It may work for a test application or service but if a system has any amount of transaction or data load, tailoring the data storage and access methods is a necessary step to successfully building and scaling the system.
Almost every application will have user data, transaction data, login credentials, media files, user input, relationship associations, analytics data, media files, and a host of other types and forms of data. Using a single database for all these forms of data is not just impractical but also likely almost impossible given the current state of technology. Running all app queries through a single database, no matter how sharded or indexed it is, will quickly bring a database to its knees and make any future development extremely problematic.
Instead, most architects structure and optimize data storage for the different data formats as well as the transactions that operate on this data. User data might be kept in a horizontally sharded NoSQL database for quick read access, transactional data might be heavily indexed in a relational data for fast querying, media files in block storage, analytics data in time series data, relationships and associations in a Graph DB, and so forth. Each database would be optimized for the read-write loads, data sizes and formats, data schemas, commit times and latency requirements, query types, security needs, and a host of other parameters. Care would also be taken to address growth both in the amount of data stored and the number and type of queries performed.
Data Science and CAP Theorem
CAP theorem is a term in data science fields that stipulates that a distributed data store cannot simultaneously provide more than two out of three guarantees with regards to consistency, availability, and partition tolerance. As such, application and database engineers often have to make tradeoffs when selecting particular data storage types in order to optimize for the guarantees that are most important for a particular app feature or service.
To most application developers and architects, using different databases — each specific to the data type and data usage — is just a normal course of action.
Lessons from Microservices
The same realization is becoming true when it comes to event and transaction handling. Instead of a monolithic application compiled or linked into a single executable and handling all user actions and side events, app developers are more commonly developing applications as a set of services. These services are each functionally separate from each other and interconnected via APIs or remote procedure calls (RPCs) or using message queues, databases, serverless function calls, or other mechanisms to orchestrate the application workflow.
While it seems using microservices might make things more complex, the exact opposite happens. Developing applications as a set of microservices not only allows teams to move quicker, they also make it easier to scale applications and add new features.
With a monolithic application, the codebase is constantly being changed and updated with code and testing conflicts becoming a continual battle. Releasing updates on any type of timely schedule becomes difficult because of the amount of testing involved and the increased risk of unintended consequences. With microservices, changes are more easily isolated allowing for faster development, reduced risk, and more frequent update cycles.
Enter Blockchain
When it comes to developing decentralized applications using blockchain networks, many of the same principles around separation of concerns apply. Instead of working with a single blockchain network or sidechain (i.e. the Ethereum mainnet, for example), it makes more sense to use multiple sidechains that connect to a public mainnet.
While many will say scaling Layer 1 will eliminate the need for Layer 2 solutions, that is not the views of many people building scalable dApps. At the Scalar Capital Summit on October 2019, Nadav Hollander, the CEO and Co-founder of Dharma, spoke about the continuing need for Layer 2 solutions despite the onset of a scalable Layer 1.
“[T]he main selling point of most next gen blockchains is scalability — Layer 1 scalability — but it seems that all of them are talking about various flavors of sharding as a method of doing that. The tricky thing about sharding is that it’s not going to be a silver bullet that solves DeFi scalability. I won’t get into too much of the technical specifics here but even with systems like ETH2, it’s very likely that DeFi protocols that are highly trafficked are nonetheless going to need to create very sophisticated Layer 2 systems in order to make these things scalable. All of which is to say that the L1 scalability benefit is material but doesn’t completely solve your problems as a DeFi protocol.”
- Nadav Hollander, CEO and Co-founder of Dharma
Using a Layer 2 solution (i.e. elastic sidechains) is almost a necessity for building any type of scalable decentralized solution. A decentralized app is still an application and therefore will be addressing not dissimilar types of user events, processing needs, and data access methods as a centralized app. Developers working in a decentralized world still need to concern themselves with storage, feature development, data types, transaction and commit latencies, and much more.
The complexities imposed by using blockchain — a few of which include commit times, transaction fees, storage and processing constraints, and smart contract permanence — add additional concerns to the equation. Concerns that only support the wisdom of using multiple sidechains in opposition to working with a monolithic mindset.
A Few Reasons for Using Multiple Sidechains
Increased Development Agility
Making use of elastic sidechains can make development of decentralized apps and protocols easier and therefore faster to deploy. Using sidechains not only helps separate processing and data concerns but also supports development team dynamics. Just as working on a monolithic app in a centralized app can create friction as teams interact with the same codebase or database, running all transactions through a single mainnet or sidechain could create situations where one action effectively blocks other actions from processing.
The communication pathways or team orchestration that needs to happen when development is highly synchronized not only takes up time that can be better spent developing, it also tends to reduce the pace of development to the pace of the slowest feature teams. Using multiple sidechains — while employing an effective interchain messaging solution to manage state and/or synchronize actions — will reduce development friction and get you to launch much faster.
New dApps vs Existing dApps
It’s also important to note that using elastic sidechains can help both new dApps as well as existing dApps.
In the case of new dApps, the use of sidechains at the start makes eminent sense. The reason is developers can build the system to scale from the onset without a significant hit (if any) in development time. The use of sidechains can also reduce gas fees and commit times thereby enabling more successful game play and/or dApp economics.
Improved Performance
In the case of existing dApps, adding new features or migrating existing features from a mainnet to elastic sidechains is not only readily doable but also less risky (aside from setting up the sidechains the right way and getting the smart contracts right). The reasons for moving to a sidechain might be to increase transaction throughput, reduce gas fees, allow for more complex smart contracts, or make use of greater sidechain storage. Creating a sidechain for a particular transaction set and/or data types allows developers to size and optimize that chain for the function.
Transaction commitment times and response latency are a huge factor in any application but even more so in a decentralized application. Commit times for centralized apps are on the order of milliseconds or even microseconds. Commit times for decentralized applications can be on the order of minutes (or hours, depending on the network load and gas fees). Solutions for scaling Layer 1 will help but they are not likely to be able to support all the transaction types and commit times within all but the simplest dApp.
Making use of elastic sidechains will allow you to optimize for the types of transactions. Some events and transaction types might be critical with respect to perfection of assets. Others may be important in terms of market making or game play, while still others will be less critical. An example of the latter might be social actions within a decentralized media streaming app — likes, follows, shares, or other actions that can be handled as background events, optimistically assuming successful commits.
Note, however, that not all sidechains are alike. You should use a sidechain that has a validation model around it that not only supports your performance needs but also has the proper consensus mechanisms and security measures in order to ensure the validity of the transactions and the integrity of your dApp.Improved
Network Economics
Each type of event would therefore have different transaction commitment times. Asset transfers might have a higher priority and therefore necessitate optimization for reduced commit times (including optimized messaging with one or more mainnets). Intra-app actions might also have extremely high performance needs but might also be run entirely within one or more sidechains, specifically tailored to the data and transaction type.
Improved Storage
Another notable difference between centralized applications and a decentralized applications centers around the cost of transactions. Centralized apps have extremely low transaction costs. Certainly there are processing and storage costs but on a per-transaction basis, the costis infinitesimal. This low cost is in direct comparison to the amount of gas fees needed to perfect transactions using a public blockchain network. Gas fees for Ethereum, for example can range anywhere between a few cents to 5–10x that for a single transaction.
These fees make it impractical to use a mainnet for every transaction within a system. Sidechains, therefore, provide the best mechanism with which to decouple inter-state transactions from end-state transactions thereby reducing operational costs and improving the economics around an application or protocol. In other words, by moving to elastic sidechains, gas fees can be vastly reduced or even eliminated for users of application. Major state changes might still be committed to a mainnet — asset creations or transfers, for example — but almost all other transactions could be performed on sidechains.
As in the case of centralized apps, decentralized apps will also have varying types and formats of data as well as different indexing and read-write loads. These differences that will determine what gets written to the mainnet vs what might be stored in sidechain storage vs what might be stored in decentralized (or centralized) storage. A mainnet would be used to record the ownership of cryptocurrency, tokens, or other digital assets as well as any transfers, dispositions, or other state changes. Other uses or state changes of these assets could well be reflected in sidechains — using appropriate interchain messaging and/or asset-locking mechanisms.
An example might be in the case of a decentralized card game. The bet might be established on the mainnet (with each player putting up funds) but the card dealing and moves might be recorded on a sidechain, with each card play signed by each user and sent to the other players. The mainnet might then factor in only in the case of an end game situation as well as for settling of the bet payoff.
Increased Processing Complexity
To use another example, take something like a decentralized media streaming application. An example might be a decentralized music service or a decentralized YouTube platform. The data for these types of system would include media files and metadata associated with the files (title, artist, description, length), playback metrics, social metrics (likes, shares, follows), user data (reviews, playlists), payout histories, and more. This data could not exist wholly on a mainnet (or on IPFS) for any number of reasons (gas costs, storage limitations, write latency, and more).
The use of multiple sidechains, however, would help simplify the handling of data and vastly reduce operational costs. The reason being is that the app developers would be able to optimize the reading and writing of data to the appropriate storage location taking into account storage fees, commitment times, access and lookup mechanisms, and more.
One underlooked but important aspect of using elastic sidechains is processing complexity. Processing within a mainnet can be quite constrained. Anything more complex than an asset change (creation, transfer, extinction) can result in higher gas fees and longer commit times. Complexity can also bring increased risk, given the public nature of smart contracts on the mainnet. The use of sidechains won’t necessarily eliminate the risk of poor contract logic but it can isolate the impacts and/or lessen the severity of mistakes.
The main advantage of being able to write more complex smart contracts is that it lets developers make use of a richer set of capabilities — capabilities that are only increasing within this emerging space. Full-state contract processing means there is complete access to the chain. This means that state changes can be performed with greater precision and timeliness given knowledge of the complete state of the chain. Freedom from gas fees also means there is greater freedom to call other protocols, make use of oracles, or use sidechain functions that might be provided (an example might be a random numbers generator). Performing this work within a sidechain essentially provides a safety net — giving developers freedom to move faster and innovate more quickly while maintaining a strict handle on gas costs.
Using the SKALE Network
SKALE Labs is the creator of the SKALE Network, an elastic blockchain network protocol. The mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. You can follow us on Telegram, Twitter and Discord, visit the SKALE website, and check out our Developer Documentation.
Disclaimer — This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities in the N.O.D.E. Foundation, SKALE Labs, Inc. or any related or associated company. Any such offer or solicitation would only be made by a confidential offering memorandum and in accordance with applicable securities and other laws.
The philosophy behind the development of the SKALE Network is directly in line with this view of employing multiple elastic sidechains. The ability to deploy and scale sidechains quickly, the use of a pooled validation model for dependable chain validation (even for small sidechains), expandable node configurations, and full-state smart contract processing are just a few of the advantages of deploying SKALE networks as elastic sidechains.
We hope you take the time to look into these SKALE advantages or, even better, connect with one of developer advocates. We’d be happy to answer questions or even get together for an online hacksession and go through these ideas and more. Elastic sidechains are not only real, they’re one of the better choices you can make if you want to launch quickly, address scalability concerns, reduce operating costs, and build the next great decentralized app.
Originally published at https://skale.network on February 4, 2020.