Key Takeaways

• Blockchain SDK is a framework that allows for the production of high-quality blockchains while saving time and capital.

• Utilizing a blockchain SDK not only offers cost savings but also provides the advantage of tapping into established ecosystems and other infrastructure resources.

• However, the standardization of technology means that achieving technical differentiation can be challenging when using an SDK. There's also a need to consider potential dependency on the ecosystem.

• Regardless, the increasing number of blockchain SDKs indicates a broadening foundation for the blockchain industry. We hope to see more refined SDKs emerge to further strengthen the infrastructure of the blockchain sector.

Base and Sei Network are two blockchain networks that have recently gained a lot of attention in the market. While both are considered "blue chip" networks, they are also built on top of existing SDKs (although Sei Network has made some modifications). This highlights that building your own blockchain from scratch with an aggregator is not a necessary skill, and that there are many quality SDKs available.

As the blockchain market continues to grow, more participants will want to build their own chains, making blockchain SDKs increasingly important. In this document, we will explore the available blockchain SDKs and their suitability for different purposes. First, let's define what a blockchain SDK is and what an SDK is in general.

1. What is Blockchain SDK?

Actually, SDK is a term that was used before blockchain, and it stands for Software Development Kit. In order to develop software from scratch, you'd have to write all the code from scratch, but an SDK can be thought of as a template that's been built from the ground up. So, with an SDK, the basic code is already there (and in the case of really good SDKs, the documentation is very well done, making it very easy for developers to work with the software), and you can build your own software by adding new code on top of it to suit the purpose of the software you want to create.

To use an analogy for ease of understanding, SDKs are similar to the way that when we buy furniture today, it is sold more or less pre-assembled to make it easier to build. It used to be that to make a desk, you had to make the legs, the plates, and everything else by hand, but nowadays, all those parts come pre-made, and you just buy them and put them together. SDKs can be viewed in the same way (although, technically, they're a bit different from furniture kits. A furniture kit can only be assembled in one specific way, but an SDK can be redesigned to suit the developer's taste and purpose, and even the same SDK can result in completely different software).

Blockchain SDKs apply these characteristics to blockchain. Of course, building any software from scratch is very difficult, but building a blockchain from scratch is even harder. Blockchain is not just computer science, it is a multidisciplinary art that involves consensus processes, governance, economic incentive models, and additional infrastructure technologies, and this barrier to entry has been a major challenge for new market participants to build their own blockchains. Wouldn't it be great if someone had already made all the ancillary and complicated default settings? Blockchain SDKs have come to solve these problems. Let's take a look at why you need a blockchain SDK specifically.

1.1 SDK, Why Do We Need It?

We've already defined what a blockchain SDK is and outlined why it's needed, but let's talk about why it's needed specifically.

1.1.1 Cost Efficient

First of all, it saves capital. In the case of the furniture kit I analogized to an SDK above, we pay for it, but in the case of blockchain SDKs, we often get them for nothing. It's not just blockchain SDKs that are free, but most SDKs are often distributed for almost nothing. So, if you can get a free SDK and build your own software on top of it, you can save a lot of time and money. If the SDK has been used for a variety of software, it will be a very efficient option for the user because it is already proven.

These advantages make SDKs an attractive option not only for startups, but also for companies that are relatively large and need to conduct a proof of concept without much confidence in the blockchain market. Even if it's not about cost, SDKs these days (as we'll see later) are pretty good in terms of quality, and it's often more efficient to use infrastructure that's already been built by a group of people who've done a lot of thinking about it, rather than trying to build a blockchain from scratch.

1.1.2 Community: SDKs are more than just code.

Typically, when there's an SDK, there's a blockchain that represents that SDK. For the Cosmos SDK, Cosmos Hub (ATOM) is the representative blockchain; for the OP Stack, Optimism (OP) is the representative blockchain; and for Substrate, Polkadot (DOT) is the representative blockchain. Each of these is an ecosystem of independent chains because it aims to be a multichain ecosystem, but if the blockchain is built using the same SDK, it acts as if it is a single blockchain community. Even though they built their blockchains with the same SDK, they are independent chains and cannot directly affect each other, so why are they grouped together as a community?

The simple answer is that they have a "shared interest". Even though they are independent blockchain building ecosystems, if a blockchain built with the same SDK does well, their blockchains can benefit from a number of opportunities. For one thing, sharing the same infrastructure makes it very easy for the networks to interact, which in turn makes it easy for them to share developer communities and users. So, if there is a very successful blockchain in the ecosystem that your blockchain is part of, you have the opportunity to indirectly promote your blockchain, as well as absorb some of the users and developers that flock to the successful blockchain. For this reason, blockchains built using the same SDK usually share the same community, meaning that when you build a blockchain using a blockchain SDK, it's not just the code that's pre-built, but also the community.

1.1.3 Standardization and Interoperability: consistency is the key As mentioned above, when blockchains are built with the same blockchain SDK, they share the same community and ecosystem, which in turn allows them to standardize various rules to maximize compatibility between chains. A prime example of this is the Cosmos ecosystem. The Cosmos ecosystem based on the Cosmos SDK has standardized a communication protocol called IBC, which enables organic communication between blockchains in the Cosmos ecosystem. Recently, new standards such as RS, ICA, and ICQ have been proposed to promote organic harmony in the Cosmos ecosystem (if you want to know more about RS, ICA, and ICQ, please refer to my previous introduction to Stripe). In the case of Substrate, XCMP enables direct communication between parachains.

1.2 There are also clear disadvantages

So far, we've discussed the benefits of blockchain SDKs. However, if blockchain SDKs were only good, all blockchains would be built on them, but unfortunately, that's not the case. There's a silver lining to everything, so what are the downsides of blockchain SDKs?

1.2.1 It's Hard to Build a Technical Moat

First of all, it's a technical problem. Since SDKs are literally just a bunch of basic code that you can customize and add on top of, chains using the same blockchain SDK are usually very similar technically. For example, Osmosis and Mars, which use the same Cosmos SDK, have very similar consensus structures (in fact, they're the same because they both use Tendermint), and if you're looking for differences, you'll find them in their products. In other words, building a blockchain with an SDK has the advantage of making it quick and easy to build a blockchain, but because it's quick and easy, it's unlikely to have a technical moat. If you want your chain to be technically advanced, you'll need to either not use the SDK, or if you do, you'll need to deploy it with some modifications (a prime example is Sei Network, which is a Tendermint modification). For a more in-depth explanation of Sei Network, see Four Pillars' previous article on Sei Network. In some cases, modifying and deploying existing tools is more complex and difficult than building from scratch.

If your goal is to build a blockchain that really emphasizes your technical edge, you shouldn't consider building a blockchain with a blockchain SDK.

1.2.2 Dependencies are inevitable

One of the advantages I mentioned above is being part of an ecosystem that uses the same SDK. However, this can also have potential disadvantages. In general, blockchains that use the same blockchain SDK can technically communicate with each other relatively easily, which can lead to synergies, but it can also lead to indirect damage. For example, when the Terra blockchain collapsed, the Cosmos-based appchains that were connected to Terra thorugh IBC were indirectly affected. Also, the direction of software development should be aligned with standards as much as possible. Once you start deviating from the standard, even if a new update to the SDK is released, it may not be technically compatible. The fact that once you build with an SDK, you're stuck with it, unless something happens, can be a significant disadvantage.

2. List of Useful Blockchain SDKs

Obviously, blockchain SDKs provide a simple framework for enterprises and developers to build blockchains with ease, but on the flip side, they can also be seen as mitigating the radicalization of the market by homogenizing blockchains. In addition, each blockchain SDK has different characteristics, so if you want to build your own blockchain with a blockchain SDK, it is very important to use an SDK that suits your purpose and usage. Therefore, I decided to analyze the blockchain SDKs on the market and categorize their characteristics.

2.1 Cosmos SDK: If ecosystem and flexibility matter the most

The Cosmos SDK is currently the leading blockchain SDK due to the high number of successful blockchains built using it. Its ecosystem is very active and has experienced many events/incidents. While there are many ecosystems that aim to be the community where application-specific chains (aka app chains) are gathered, the Cosmos SDK has produced the most app chains so far, making it the most well-known blockchain SDK in the crypto industry. Many companies are currently building blockchains using the Cosmos SDK. Let's take a look at some of the blockchains built with the Cosmos SDK that you may recognize.

2.1.1 Terra: a god that failed.

Source: Cosmos Blog

Probably the most famous blockchain built with the Cosmos SDK, Terra has seen tremendous growth, at one point surpassing Cosmos Hub in market capitalization and becoming one of the top 10 blockchain market caps in the world. It was a blockchain that made Cosmos SDK popular. Terra was also one of the first blockchains that adopted Cosmwasm, the multi-chain smart contract platform that most Cosmos-based blockchains now use to implement smart contracts. However, Terra, which was highly influential blockchain in the market for its noelty product of an algorithmic stablecoin and the launch of various DeFi applications, eventually failed to peg the value of the algorithmically stabilized stablecoin. Of course, this led to collapse of the entire Terra blockchain.

Terra's failure to peg its stablecoin was a problem with the algorithmic stablecoin, rather than a failure of the blockchain infrastructure that Terra used , and is still cited as one of the most successful projects built using the Cosmos SDK. In fact, Tera's success is often cited as an example of breaking the conventional wisdom that "if you use a blockchain SDK to build a blockchain, you can't be original and you won't get noticed" (which offsets the drawbacks of blockchain SDKs that I mentioned above).

2.1.2 dYdX: Killer Application to Killer Chain

Source: dYdX Blog

One of the more shocking news stories of last year was the announcement that dYdX, one of the most popular order book-based decentralized futures exchanges on Ethereum's Layer 2, was leaving the Layer 2 ecosystem to build its own blockchain. This is an interesting case because dYdX started as a product developed through the StarkEx engine in collaboration with Starkware, but realized its limitations and left the Ethereum ecosystem to build a chain based on the Cosmos SDK. In order to build the order book and matching engine environment they wanted, dYdX needed an environment that was as easy to create as the Cosmos SDK, but still allowed them to customize how the blockchain works (in fact, dYdX is taking full advantage of the flexibility of the Cosmos SDK by eliminating trading fees to maximize the trader experience).

In fact, since dYdX requires its validators to not only participate in the consensus process, but also operate the order book in a separate environment from the consensus, Cosmos' ability to build its own layer 1 chain was probably more appealing than a layer 2 chain that is constrained by infrastructure other than consensus. The mainnet of the dYdX chain is yet to come, but depending on how the dYdX chain performs after the mainnet, it might become very common for applications to build their own blockchains.

2.1.3 Sei Network: Radically Customizing the Cosmos SDK

Source: Sei’s blog

If you're wondering how flexible the Cosmos SDK is, pay attention to Sei Network. Of course, Terra and dYdX, which I mentioned above, have also added their own code to the Cosmos SDK to add new features and functionality, but Sei Network has designed the current Sei Network by modifying the consensus of the Cosmos SDK. They simplified the part where nodes propagate transactions twice through Intelligent Block Proposition and shortened the consensus process of Tendermint through Optimistic Block Processing. In addition, they have their own parallelization of transactions, resulting in much faster transaction speeds compared to existing Cosmos app chains (if you want to learn more about the Sei Network, please refer to the introduction to the Sei Network written by Four Pillars). Now, Sei is creating its own colors outside of the Cosmos SDK, making it difficult to classify Sei as a Cosmos SDK-based chain.

2.1.4 Features of the Cosmos SDK

Based on these three examples, the Cosmos SDK is a blockchain SDK that provides a framework to easily build layer 1 blockchains, but also allows for flexibility in chain development, allowing you to design your chain to fit your own direction and goals. Terra added an algorithmic stablecoin, dYdX gave validators a new mission, and Sei modified the entire consensus to achieve extremely fast scaling. If you're building a blockchain from an SDK and you're looking for a certain amount of autonomy, the Cosmos SDK is a great option.

2.2 OP Stack: If you want to get some of the security of Ethereum with EVM- equivalency

OP Stack can be thought of as an optimistic rollup SDK that is provided to build optimistic rollups. OP Stack essentially provides the necessary tools for developers to create their own rollup chains and enjoy the scalability improvements that rollups provide. With OP Stack, developers can build more efficient and cost-saving rollup chains than traditional smart contract platforms. This improves user experience and enables faster adoption of blockchain technology. Overall, OP Stack is recommended for any developer looking to build efficient decentralized applications with some of the security of Ethereum, or for developers who value an EVM-equivalent development environment (if you're interested in learning more about Op Stack, check out Four Pillars' introduction to Op Stack )

Of course, the Optimistic Rollup has a 7-day challenge period, which is only meaningful for assets that have been bridged from Ethereum to the Optimistic Rollup chain, so it's hard to say that a blockchain built with Op Stack will inherit the full security of Ethereum, but it does have security advantages over a framework that builds its own chain entirely, such as the Cosmos SDK (although we'll discuss opBNB later). What blockchains are currently built using the Op Stack?

2.2.1 Base, Coinbase’s Optimistic Rollup

Source: Coinbase

Coinbase, which had been inactive when it comes to crypto exchanges creating their own blockchains, announced last year that it would launch its own blockchain, the Base Blockchain ("Base"). Base utilizes the Op Stack to provide faster, cheaper, and more scalable transactions than the current Ethereum network can provide, with a goal of eventually onboarding over 1 billion users on-chain. Because it's built on the Op Stack, it's a general purpose blockchain, similar to Optimism, and while it's not exactly the same environment as Ethereum's EVM, it's EVM-friendly enough to achieve EVM-equivalency. As such, developers who are already familiar with Solidity will find it easy to utilize the Base chain. In fact, Base is currently ranked #12 among blockchains (#3 among layer 2s) based on TVLs counted by DeFilamma, showing tremendous performance in a very short period of time.

Base chose Op Stack for two main reasons: 1) EVMs are now a standard in the blockchain industry, and 2) the security of Ethereum is very important for managing vast amounts of assets. Of course, these are just their opinions, but if you're on the same page as them when it comes to organizing your blockchain, you'll find Op Stack to be a very useful tool.

2.2.2 Of course you can build Op Stack based chain outside of Ethereum: opBNB

Source: BNB Chain

While Coinbase used Op Stack because of Ethereum's security and EVM, Binance is a little different. Of course, they used Op Stack because of its EVM equivalency, but not because of Ethereum. What's interesting about opBNB is that even though it's an Op Stack-based chain, it doesn't sit on top of Ethereum, but on layer 2 of Binance's own network, the BSC (BNB Smart Chain) chain. It is expected that Layer 2 will also benefit from the fact that the BSC network has a much higher gas limit than Ethereum and is more scalable.

What opBNB shows us is that Op Stack-based blockchains don't have to be built on top of Ethereum. As many fear, the more Ethereum-based rollup chains we see, the more likely it is that the rollups will eventually run into the scalability limitations of Ethereum and fail to fulfill their original purpose. After all, Ethereum's Layer 2 also needs to send their transaction batch to the Ethereum main chain, and there's only so much space in an Ethereum block, so if it becomes "rollup saturated," rollups will never be free of scalability issues. Therefore, an effort like opBNB may be the answer to the question of why we need to implement layer 2, even if it's not on Ethereum.

2.3 Substrate: If you're familiar with Rust and modularity is important to you.

Source: Parity

Substrate is a blockchain SDK developed by Parity Technologies, the company behind the Polkadot network. Similar to the Cosmos SDK, Substrate is designed to provide the functionality needed to build a blockchain, allowing developers to focus on application logic rather than the details of blockchain infrastructure. With Subsrate, developers can create a customized blockchain that meets the specific needs of their application. At this point, it sounds a lot like the Cosmos SDK, which is actually a blockchain SDK that serves much the same purpose as the Cosmos SDK.

One of the most notable features of Substrate is its runtime module library ("SRML" or simply "palette"). Palettes are plug-and-play, configurable modules that encapsulate specific functionality, such as token balances, staking, or governance. Developers can use these pre-built modules or create their own from scratch, providing unparalleled flexibility in blockchain design. As such, the modularity (or flexibility) of Substrate is one of its most emphasized features compared to the other SDKs.

So, let's take a look at some of the blockchains built on Substrate.

2.3.1 Acala Network: Demonstrating the flexibility of Substrate

Source: Acala

Acala Network ("Acala") is a decentralized finance (DeFi) platform built on top of the Substrate blockchain development framework. As part of the Polkadot ecosystem, Acala aims to provide a full suite of financial applications, including stablecoins, decentralized exchanges (DEXs), and lending. One of the unique features of Acala is that users can receive stablecoins by depositing various digital assets as collateral. This gives users greater access to liquidity and greater benefits for participating in DeFi activities.

In fact, the most interesting part of Acala is its fee mechanism, as the problem of paying fees when using blockchains, especially the changing tokens that need to be paid as fees from network to network, is one of the things that makes the user experience worse. However, Substrate can also change the fee payment logic, allowing Acala to take fees on all tokens traded on the Acala DEX. This shows how flexible Substrate is as a framework.

2.3.2 Astar Network: Using EVM and WASM Simultaneously

Source: Astar Network

Astar Network is a blockchain built on top of Substrate and is known as one of the leading blockchain projects in Japan. It is characterized by its support for both EVM and WASM, which is designed to allow developers to develop smart contracts in any language. Supporting EVM and WASM at the same time is interesting, but the fact that Astar also includes a unique feature called dApp Staking to provide continuous incentives for developers shows how flexible the Substrate is. In particular, the ability to support two virtual machines together is a clear example of Substrate's flexibility, considering that there is no such case in the Cosmos ecosystem to date.

2.4 Linera SDK: If you want to try New Technology

The Linera SDK is being created by Mathieu Baudet, who previously wrote the papers for Meta's crypto wallet service Novi and payment infrastructure FastPay, and is one of the well-known blockchains to come out of Meta, along with Aptos and Sui. It shares similar DNA with Aptos and Sui, but the difference is that they've been building SDKs and bringing them to market before they've even launched their own blockchain. It's worth noting that they've recently taken a very different approach by hosting a developer school to test out their SDK. As mentioned, the Linera SDK is still in the testing phase, so we haven't seen any direct examples of using it, but we've been able to get a glimpse of the chains that can be built using it in their whitepaper:

First, there are chain owners, validators, and users. There is a validator. Here, the owner can be any participant on the chain, and the relationship between the owner and the validator can be seen as that of a customer and a service provider. This differs from other traditional chains in that the main role of the owner is to produce and propose new blocks, while the validator only validates them (although in Linera, for public chains, the validator plays a similar role as in traditional blockchains). On Linera, chains are called microchains, and they can be categorized into three main categories:

• Single Owner Chains: Chains structured so that only one user can propose a block.

• Permissioned Chains: Chains where only a select number of users can propose blocks.

• Public Chain: A chain that allows all users to freely propose blocks.

The three chains have different structures for who is authorized to produce blocks, but they all require a certificate to produce the next block. However, the structure of the certificate is different: in the single-owner chain, the certificate is issued through a reliable broadcast, and in the public chain, the certificate is issued by a validator using BFT. It is important to note that a single-owner chain is not completely free from validators, so if the Linera ecosystem is activated, the role of validators is expected to be very important.

If Substrate has the flexibility of an SDK in the form of a palette, Linera seems to have the flexibility in the form of three different types of microchains, and you can choose the one that best suits your purpose. If you want to be a first mover, it's worth trying to build your own chain using the Linera SDK.

2.5 Hyper SDK: If You Care About Scalability the Most

Source: Avalanche

Like other multi-chain ecosystems, Avalanche has released a software development kit (SDK) that makes it easy to create blockchains. This is the HyperSDK. Avalanche introduces HyperSDK as a framework for creating high-performance virtual machines, and the advantage is that users can quickly implement the blockchain of their choice without a large amount of coding (according to the Avalanche team, it can be customized in about 500-1000 lines, depending on how much mechanism design is required). The blockchain built on top of the Hyper SDK is called HyperChain, and while the Avalanche team emphasized the simplicity and convenience of not having to onboard a lot of developers to build the chain, it's still in alpha, so there's still a lot of experimentation and refinement to be done (https://github.com/ava-labs/hypersdk). What's clear, though, is that the Hyper SDK could play a big role in fueling the growth of Avalanche's multi-network ecosystem by providing an easier and simpler tool than the old days of simply forking an Avalanche VM to build a network.

It's interesting to note that, as the word "hyper" suggests, speed was the most important thing they were looking for when building the Hyper SDK. According to Patrick O' Grady, who led the development of the Hyper SDK at Avalanche, it doesn't matter if an SDK makes it easy to build a blockchain if the blockchain built using that SDK isn't fast enough. As such, the Hyper SDK focuses on how developers can quickly and easily create high-performance blockchains.

Of course, as with Linera, there's still room for improvement, and there's a risk that the Hyper SDK hasn't been proven yet, but for those who are more interested in the experience of building a new blockchain with a new SDK, it's worth a try.

2.6 Polygon CDK: Experienced SDK Builder

Source: Polygon

Polygon's L2 framework, announced on August 30, 2023, is indeed the most recent SDK. Of course, this isn't the first time Polygon has created an SDK, they also had a layer 1 deployment framework called Supernets, so it's encouraging to see a team that already has experience creating SDKs creating a new L2 SDK. Another thing to note is that the CDK chains share an Interop Layer, which is literally the interoperability layer of the chains, and chains that share this layer can freely interact with each other via zero-knowledge proofs. Already, we've seen high-profile players like Immutable and Aavegotchi using the CDK, making it a layer 2 framework that's set to make a big splash in the short term.

While there are many Layer 2 SDKs out there, none of them are as clear about how to interoperate between L2s as Polygon CDK, so if you're thinking about building L2 in the future, Polygon CDK is a great way to go (though you may want to wait and see what happens with Immutable and Aavegotchi before deciding).

3. Conclusion: Should We Use It or Not?

So far, we've covered what blockchain SDKs are and what they're capable of, with examples of how they've been utilized. Each SDK has its own unique set of characteristics and clear advantages and disadvantages, so it's best to focus less on which SDK is superior and more on which one is better suited for your purposes. So finally, should you really use a blockchain SDK, and if so, why should you and why shouldn't you?

3.1 Reason for using it 1: It can solve capital and labor problems

Most companies developing blockchains are startups with less than 50 employees, which means they don't have the manpower, capital, and time to build a blockchain from scratch. For a startup, it's nearly impossible to create a complete blockchain that isn't a shoddy product. In the early days of the blockchain industry, there was plenty of time for small teams to perfect their blockchains through trial and error (to be clear, almost all of these blockchains died because they weren't chosen by the market. Today, most of the blockchains we know are projects that have survived through various validations in a harsh market environment), but the size of the blockchain market is different and the speed at which the market changes is very fast as experienced developers from various fields have entered the market. In such cases, it can be important to quickly create a proven blockchain. This is why mature SDKs are so attractive in the current blockchain scene. To put it more bluntly, with a global blockchain giant like Coinbase using Op Stack to build their own blockchain, why would any other crypto startup want to build their own?

3.2 Reason for using it 2: If interoperability is important to you

When you're building a blockchain, it's very difficult to make it talk to other blockchains organically. In fact, last year, an astronomical amount of money was hacked from cross-chain solutions alone, so connecting blockchains is a very difficult task. However, by utilizing an ecosystem built using SDKs, interoperability is relatively easy, at least between chains that utilize the same SDK. In the case of Op Stack, it depends on which base layer (Layer 1) is built on, but if you build Op Stack-based chains on the same base layer, they can at least interoperate very organically.

Even if they don't share a base layer, Cosmos SDK and Substrate provide interoperability between ecosystems based on IBC (inter-blockchain communication) and XCMP (Cross Chain Message Passing), respectively. This means that even if you are not an expert in cross-chain technology, if you build a blockchain with these SDKs, you can at least use an infrastructure that can easily communicate between chains in the same ecosystem.

3.3 Reason for not using it 1: There's no such thing as free lunch

From this perspective, SDKs are a must-have toolkit. There are so many benefits to building a blockchain on top of a framework that has already been created by great minds. However, just as there are no free lunches, there are also clear downsides to using SDKs. At the end of the day, what the foundations behind the SDKs want is for there to be a lot of SDK-based chains, and for them, or their chains, to extract some value from them. In fact, the Cosmos ecosystem has proposed a new feature to achieve this by introducing new shared security model called RS (Replicated Security), which allows value to accumulate on the Cosmos Hub as more chains launch in the Cosmos ecosystem (although this model is currently under debate). In the case of base chains based on Op Stack, they even signed a revenue sharing agreement with Optimism Chain. While none of this is necessarily a bad thing, it's important to be clear that teams creating SDKs are not simply distributing and sharing them as a free service. As with all things in this world, nothing is free, even if it appears to be (and even in situations where fees are not enforced, they are increasingly converging on fees or profit sharing, and even if they are not, the dependency on the ecosystem is something to think about before building a blockchain with an SDK).

3.4 reason for not using it 2: If you're ambitious

As Alex Ferguson(one of the greatest football managers) said, "no player is greater than a team," and with SDKs, it is difficult to surpass the SDK ecosystem or the chains that represent it.(Mainchain:Optimism for Op Stack, Hub for Cosmos SDK, Polkadot for Substrate, Polygon for CDK). As I mentioned above, when designing their SDKs, team or foundation adopted and will continue to adopt an approach that accumulates value for these main chains as the SDK ecosystem grows, so it's probably close to impossible to build a chain with our SDKs and leapfrog the ecosystem. Of course, we saw a very unusual case with Terra, which was built on the Cosmos SDK, but it grew to the point where it was bigger than the Cosmos Hub and the entire Cosmos ecosystem, but that was a very unusual case. We probably won't see anything like Terra in the future. So, if you're an ambitious team, building a blockchain with an SDK might mean limiting your ambitions to the SDK ecosystem. If you're really confident and have the capital, it's still best to build your own blockchain.

3.5 Conclusion: Be Ambitious, but Be Cautious

As with everything in life, there's no one right answer. However, I think it's imperative to carefully and thoroughly review the SDKs I've introduced today and their pros and cons, as well as the pros and cons of the SDK as a whole, before building your own blockchain. However, one positive thing is that as the blockchain industry becomes more mature, the number of SDKs will increase, and as they compete with each other, more benefits will be available to users of the SDKs. Competition means better quality and lower costs. SDKs have become a core part of the industry's infrastructure, and we look forward to seeing more quality SDKs enriching the blockchain ecosystem.

Thanks to Kate for designing the graphics for this article.