“Why Initia?” A Beginner’s Guide, 3/n
(Part 2, “some blockchain concepts”, click here)
Different layers, depending on context
We are now getting into the thicker part of the forest. Hopefully by now you have a certain idea of what blockchain is. And today we will break the idea of a blockchain down by taking a different swing at it.
Let’s explore 1) blockchain layers, 2) layered blockchains, 3) a bit on the notion of modularity, and also 4) how to expand and scale blockchains.
Layers within a blockchain
In the world of software, everything always layered, whether the programmers create all the layers themselves, or whether the users notice them. You have a smartphone, which comprises of a hardware base layer, and then the operating system, and the apps you install yourselves. Or in the Internet protocol stack, there are the famous 6 layers and it is quite similar to the smartphone example. The lowest layer handles something very fundamental, and each upper layer is designed to handle something else on top of the lower layer. Meaning if you want to type “www.medium.com” into the search bar to arrive at the site, so many things happen in the layers underneath what you see, and what you type, in order for the 0s and 1s to travel through cables and radio waves. Each layer does its job as designed.
In blockchain, there also is the concept of layered architecture (hardware and infrastructure, data, network, protocol, application, etc.) which is also important, but, for users or new learners, it is almost beneficial not to think of it in these terms. We can just leave it to the technical experts who actually build or work on these things.
What I want to give you a taste today is the notion of layers in the high level functional sense, and also blockchains can be rigged with other blockchains in a complementary way, to achieve lofty goals such as scaling up to be the future of the web.
Execution, consensus, settlement, data availability
Let me just call these four, the “four elements” of a given blockchain, even though they are sometimes referred to as layers. Our friends over at Celestia calls them functions. If you feel lost trying to read through the article, even though it is a good one, just come back here and only focus on this. Blockchains need to be able to provide and maintain these to be true and working in order to properly function. Let’s lightly go over each element.
- Execution: if a transaction comes in, the blockchain needs to be able to handle it, so that the state of the blockchain is updated to reflect whatever the new transaction or block adds to the all-time history of the blockchain. Like the total, up-to-date balance of everyone’s bitcoin. When you hear the words such as “EVM (Ethereum Virtual Machine)” or “Solana VM”, this is what the execution layer is called, depending on the blockchain. It’s a computing state machine that is up and running, and runs stuff.
- Consensus: the nodes will work hard to make sure that the blockchain grows properly with the right transactions are ordered and grouped into blocks. This ensures no single party or set of parties can influence or take control of what gets stored, to the detriment of others.
- Settlement: just like how financial systems settle bank accounts at the end of the day to update user account balances, blockchains need to settle data.
- Data Availability: a new, fresh blockchain doesn’t have much history, so nodes don’t need to download much data in order to reconstruct and verify the validity of each and every new block coming in. However, as it grows, the size becomes and issue for nodes. As it bogs down processing capabilities, nodes have a harder time verifying each block. This causes congestion and eventually rise in gas fee, which is not optimal. So data availability is a concept that comes in where, if it is ensured, each node can easily verify that the block coming in is OK to add to the blockchain.
You can understand that these are key requirements and attributes that every blockchain should meet in order to be called a blockchain. Again, you don’t need to get so hung up on the nitty gritty detail on these. Just try to remember that, these four are required. This is just the groundwork needed for the next subject — modular architecture.
I bet that for most readers, the last one (DA) is still the most confusing concept. It might be beneficial to read this note published by Celestia, or this write-up by CoinGecko to see if it helps.
Layers enable modularity
Modules are like puzzle pieces. Curricula can comprise of learning modules. Devices can be combined with different swappable parts to change functionalities. Software code could be packaged so that others could benefit from already completed work, in the spirit of open source programming culture.
Modular has immense benefits. Because each part is interchangeable, if there is a different functionality that you didn’t know you needed, but later on you did (like the fish eye lens for your action cam for going on a beautiful hiking trip), you can swap out the existing part for it. It ensures that users are not locked into the decision made a long time ago.
Blockchains can be modular too, and this provides great benefits.
Monolithic blockchains can evolve, but modular blockchains can evolve faster, and could be more attractive to developers. If each of the layer could be specialized by a blockchain with a unique design that is meant to do just execution better, or data availability better, then theoretically, sum of better parts could equal to better whole. Right?
A binary call to claim that modularity is always better than monolithic approach, or vice versa, is too strong and divisive of a claim just yet, but optionality and composability will always be preferred by some. It is also a faster way to get to the future by nature, if something better comes along, and instead of having to painstakingly go through an upgrade of a larger unified system, modular ones can adopt new innovation in an instant, in relative sense.
This article may be helpful if you want to have another pass at modular blockchains.
Blockchains layered with other blockchains
L1s and L2s
Remember that Ethereum has become the whale of an ecosystem? Because there was so much traffic happening on top of Ethereum, traffic congestion and crazy gas fees started becoming an issue.
In computer architecture (where I cut my teeth and survived as an engineer for a handful amount of years) faster memory/storage sits in front of slower, cheaper memory/storage for boosting performance. For this to work the different tiers of memory need to work seamlessly with each other, so that from the outside it just looks like a single memory/storage. This divvy work happens all over the world of tech, or even at libraries or clothing stores. Front, and back.
So I think naturally this approach was applied to overcome the growing issue of Ethereum. As a result many newer chains started relying on Ethereum but presented themselves to the world that they are the front line receiver for users and dApps to use. And instead of storing all data, Ethereum then only has to be relied on for a summary of these higher level chains, roughly speaking.
In this context, Ethereum is called a L1 (layer one) chain, and those on top L2s.
Nowadays there are even L3 chains that are being talked about. An example of this is Coinbase’s Base chain that uses Ethereum, and Base is created to serve other chains, so the customer chains will be L3s. Crazy stuff.
Rollups
Rollups are a type of L2 chain. I’ll only mention this because it is currently the most popular way to achieve L2 design for a blockchain. Rollups will take all the transactions and store them on their blockchain first, and then only store the summary of each batch of transactions to the L1 chain, but periodically, as supposed to only when necessary. So in other words, this is the closest to the cache memory + slower memory analogy I mentioned earlier.
There are two most known types of rollups — one is called optimistic rollups, and the other zero-knowledge (ZK) rollups. While ZKP is a sound theory, it is apparently very difficult to implement and make it work in a scalable way, so I don’t go into it, but at the end in the appendix only briefly touch on what ZKP is.
For more on the distinction between rollups and L2 chains, try this article.
Appchains
Let’s say you now want to try to build an app, and consider Ethereum as the base chain of your choice. You will then build the app perfectly to your imagination, and then you turn to the Ethereum chain, and realize that every time you try to interact with it (in order to store app data), the traffic situation is unpredictable, so your data may take much longer to store, or the cost of storing fluctuates and shoots up to an abnormal/unreasonable level. Plus certain features that you would want to rely on (just like how an iOS app developer might rely upon the nice benefits that Apple provides in the developer toolkit) aren’t there, so you have to go look for what you need, pay for them, or painstakingly build them yourself.
Perhaps this isn’t the best way to build your app. Also, on the ecosystem side, this may not have been the best way to achieve scale. If blockchain is to be a pivotal part of the future of web, we would need more users, more apps, more data, to flow, in different orders of magnitude. This friction isn’t the best thing for it.
So there is this concept of app-specific chains (or appchains) that surfaced a while back. these appchains will look and work differently depending on each and every app scenario and requirements. Simply put, an underlying blockchain that serves a DeFi app doesn’t need to be the same as the one serving a game app. Maybe some chains need to be gas free. Maybe some need to be tunable. Maybe some need to be without it’s own set of nodes, or maybe some need them. Maybe those nodes need to come to consensus in a different way.
This article by Blockworks sponsored by Stardust is focused on the concept of gaming appchains, but in the middle section it does a good job explaining what appchains enable and offer.
Thought: what if we combine… L1 and appchains?
Appchains are great if the teams that run each app can pull it off. At the end of the day, however, it means a dev team must know how to not only build a successful app that users need and want, but also be able to bootstrap a sound validator set and create and run a blockchain for the back end. It does seem to be a tall order. Trust me, I have witnessed what it takes for our team to boot up just the testnet version of Initia.
And so maybe in a perfect world, there exists a nice environment where, app developers that would like to launch their own appchains can rely on a L1 that could theoretically provide everything they need, and, shield and mask everything that the dev team has to handle in terms of running the underlying appchain, so that the whole journey is painless and expedient.
So. We finally arrive at the point where I can now start talking about Initia. Whew!
Feel free to have a look at this article that further talks about appchains and see if it makes sense.
Appendix
Sidechains
Sidechains are meant to be an offloader that “sits on the side of the main chain”. So instead of having to deal with scaling the main blockchain to be able to handle more traffic, imagine having another dedicated blockchain next to it, and it takes on some of the workload. And when necessary assets could be transferred between the main chain and the sidechain. If a queue becomes too long at a hotel front desk, then another employee opens up a counter, handles guests, and quickly take in or out guest keys from the main key drawer where the original employee has been handling guest receptions. For more, try reading this.
Zero-Knowledge Proof
Okay, this is honestly above my intellectual pay grade. So I’m going to introduce you to the well-made video by WIRED magazine that explains ZKP in the easiest manner, and let’s see how far you can get. (Additional write-up such as this may be complementary to the video, but watch it first.)
It is a fascinating concept and perhaps worth studying it at some point. I will mention that ZKP is something a lot of blockchain folks are excited about, but in practice, there are still more non-ZKP rollups out in the field, for practical reasons. Namely Optimistic Rollups.
Optimistic Rollup
Optimistic Rollup is a version of rollups. It is optimistic, because, for the sake of performance, when a rollup (remember that it is an L2 chain that posts summarized data to L1 chain) is storing data, it gets posted immediately, and everybody moves on. This is how performance is guaranteed. Assumption is that we are optimistic towards the intent and the integrity of data that comes down to the L1 chain, instead of having every transaction data verified at the time of, well, rolling up.
Except, there are watchdogs. These watchdogs, called challengers, monitor these rollup activities. They are given a window of time (usually 7 days) to identify any malicious intentions, and once a transaction rolled up by the L2 is proven fraudulent, then they intervene. If the challenger rightfully challenged the action, then the block that contains the faulty transaction (i.e. a fake balance increase of ETH when no one sent anyone any ETH) is removed, and the validator that put in the block gets penalized.
The inner workings of this challenge mechanism involves a method called fraud proof. It is technical, so if you would like to find out more about it, try literature such as this.
Scaling
In blockchain, just like other parts of the computing world, performance is measured in numbers. Most common metric is called TPS (Transaction per Second). There have been various different ways to increase throughput, which has a direct correlation to lower gas fee.
Certain blockchains require higher-powered computing hardware for the nodes/validators. Other blockchains come up with parallelism to be able to take on more transactions. And some may have a different way of doing consensus or settlement or data availability.
Just remember that TPS is important, but there are other important aspects as well, such as security, flexibility, and so much more when considering which blockchains are better and performant.
That’s it for today!
(Part 4, “why Initia, why now”, click here)
Please send in any feedback on the article to me@inbae.io. Thank you! 🙏🏻
Disclaimer
- This article series is not intended as a learning material so you could trade better; and for sure an investment advice of any sort
- Also not targeted for specific audience from any specific country or demographic
- Please keep an eye out for our latest updates on our website, and cool announcements on our official account on X/Twitter, as well as our official Medium blog.
