Posts

Multi-Chain as a Scalability Strategy: Leveraging Moonbeam for Ethereum-Based Deployments

In the past few months, we’ve received a number of questions about our relationship with Ethereum. I’d like to clarify something: Moonbeam is designed to complement and extend existing Ethereum-based deployments, not to compete with Ethereum.

In a multi-chain future, Ethereum will continue to occupy a central position, particularly around DeFi and related use cases. We expect its already significant developer and project traction to continue. At PureStake, we are personally big fans of the Ethereum ecosystem including its battle-tested developer tools, among many other things.

In this future, it’s difficult to imagine a world with only Ethereum, or only Bitcoin. Many other chains will co-exist with Ethereum, including Moonbeam and other chains on the Polkadot network. There won’t be a chain monopoly on a particular use case — there will be DeFi activity on chains other than Ethereum as well to serve the users and assets on those chains.

With this context, Moonbeam will be highly complementary to Ethereum, offering the ability for existing Ethereum-based projects to migrate some of their workloads and state off of Ethereum layer 1 to Moonbeam, while at the same time extending their reach to users and assets on other chains.

Moonbeam as an Alternative Ethereum Scaling Strategy

There are two main ways that Moonbeam can help existing Ethereum-based projects: it can alleviate scale and cost challenges, and it can help extend the reach of those projects to users in the growing Polkadot ecosystem. Moonbeam will be optimized for hybrid deployment scenarios, where some of a project’s transactions and state are migrated to Moonbeam while continuing to maintain key components on the Ethereum MainNet.

As existing projects consider their scaling strategy in the face of rising Ethereum costs (in some cases making use cases unviable), Moonbeam presents an alternative to rollup strategies such as ZK and optimistic, and sidechains such as OMG and Matic Network. Moonbeam can provide many of the same scalability benefits as these strategies, but requires far fewer changes in order to achieve them. Its faster blocktime also enables better responsiveness and more granular on-chain data, which is highly valuable in many use cases, particularly for oracle price data.

Moonbeam itself will have substantially more throughput (and, in turn, lower cost) based on its Proof of Stake-based approach when compared to Eth1 and its Proof of Work-based approach.  Since Moonbeam is a single shard environment, composability will work the same way it currently does on Eth1.

Using Parachains for Projects with High Scalability Demands

It’s important to note that Moonbeam is not the final destination for applications that need the highest degrees of scalability. Projects with very high scalability needs will migrate some or all of their backend to their own dedicated app-specific blockchain, where they will have full control over upgrades, governance, and have the ability to optimize the underlying storage and transaction implementations to their use case. This dedicated blockchain can also include the Ethereum compatibility components that Moonbeam uses to provide a dedicated EVM instance.

An app-specific blockchain represents the ultimate in scalability and control for a given workload, even if it comes with additional responsibilities such as the underlying runtime implementation, establishing a token economy, and incentivizing and building a node community. If these app-specific blockchains become parachains on the Polkadot network, they will be able to gradually relocate workloads and state from Moonbeam to their dedicated parachains, as needs dictate.

Moonbeam was very much designed for these upgrade and migration scenarios; its entire purpose is to serve as a way to reduce implementation friction, quickly scale to meet immediate needs, and provide an easy entry point to expand into Polkadot and chains connected to Polkadot. And whether projects are deployed on Moonbeam or as Polkadot-based parachains, Moonbeam can continue to be a place where integrations are done and where functionality from app-specific parachains on the network can be composed into higher-order functions before being presented to end users.

Features to Support This Hybrid Model

This focus on Ethereum compatibility and integration has informed the priority features for Moonbeam. These include:

  • Full EVM implementation based on Substate’s Pallet-EVM (which in turn is based on SputnikVM). This is needed to provide assurance that existing Solidity contracts will have the same execution behavior as they do on Ethereum.
  • Web3 RPC compatibility which means that change will be minimized for existing DApp frontends, and that you can use existing Ethereum development tools such as Truffle, Remix, and MetaMask. We are already working with Parity to implement this as part of the Frontier project.
  • A bridge that allows movement of tokens and state between Ethereum and Moonbeam. This is needed to support the hybrid deployment model with a partial movement of logic, workload, and state to Moonbeam.

In the longer term, once XCMP and SPREE are available on the Relay Chain, we will introduce new operations that provide easy developer access to Polkadot’s cross-chain integration functionality from an Ethereum-compatible environment. These features will extend the reach of existing Ethereum projects to other Polkadot parachains and even other sovereign chains that are bridged to Polkadot.

To learn more about testing your Ethereum-based project on Moonbeam, please contact us. You can also join our Riot room or sign up for the monthly Moonbeam Dispatch to be notified when a testing environment is available.

Blockchain Scalability Trade-offs Banner

Blockchain Scalability Trade-offs: How to Choose a Platform

Blockchain scalability is one of the most frequently cited reasons that blockchain adoption isn’t happening faster.

The truth is, most blockchain networks are slow when compared to traditional centralized technologies and networks like AWS or the Visa network. Ethereum, for example, can process transactions in the range of 15 transactions per second — and Bitcoin is even slower.

On the other hand, blockchain networks have unique properties, such as native digital scarcity and unstoppability, that cannot be achieved in the same way with centralized approaches.

As developers continue to experiment and iterate on novel uses of these properties in decentralized software applications, popular platforms are hitting up against scalability and transaction limits. In this context, blockchain scalability is widely seen as a limiting factor in further blockchain adoption among software developers and end users.

In response to these blockchain scalability issues, the community has poured a lot of energy into developing scalability solutions at Layer 2 (e.g. Lightning, Plasma) and migrating existing platforms to faster consensus mechanisms (e.g. Ethereum 2.0). These solutions are all interesting in their own right, but I would argue that they are less important for scalability than design decisions in the protocol itself, and the use cases which are being targeted by those designs.

Developers who are investigating which decentralized platform to build on should carefully consider their requirements and the design goals of the platform they are choosing relative to those requirements.  Two important trade-offs in order to achieve your optimum level of scalability for your application are the level of decentralization and the level of programmability that you require. Not every application needs maximum decentralization nor programmability.

The Top Two Trade-offs to Blockchain Scalability

Level of Decentralization

The Blockchain Trilemma

For those who are unfamiliar with the famous blockchain trilemma, it states that when designing a blockchain protocol, you can only have two of these three properties: security, decentralization, and scalability. The insight is that it is hard to achieve all three simultaneously.

From my point of view, the most interesting use cases for blockchains are related to the storage and movement of value, so any significant sacrifices to security seem like a non-starter.

The key point behind the trilemma is the relationship between decentralization and scalability. It is easy to achieve scalability if you sacrifice decentralization. For example, traditional deployments using AWS infrastructure achieve very high scalability in a centralized model. But in this deployment model, the key properties that make blockchains interesting — namely, native digital scarcity combined with unstoppability — disappear.

Some projects use this relationship to their advantage. Take the example of EOS. In the EOS network, there are 21 block-producing nodes. This is far fewer than Ethereum or Bitcoin. By becoming more centralized, EOS achieves far higher transaction throughput than either Ethereum or Bitcoin. Twenty-one nodes isn’t totally centralized, but it is much more centralized than many other blockchain networks.

EOS’s goal is to be decentralized enough to keep the most interesting blockchain properties intact, but centralized enough to achieve significantly higher performance than competing blockchain networks. The question to ask yourself as a DApp developer is, what level of decentralization does your use case require? How worried are you about censorship of your application? Many high-value-oriented use cases may require higher levels of decentralization; for others, it may not matter.

Level of Programmability

The level of programmability that is supported by a blockchain protocol is at least as important a factor for blockchain scalability as decentralization. The key question is, what use cases are your applications going after, and what level of on-chain logic do you need to achieve your goals?

I can think of a range of applications with varying needs for platform programmability, running from money and asset transfer use cases on one end of the spectrum to Web3/decentralized applications on the other end of the spectrum. A money transfer application, a securitized tokenization platform, or a marketplace for digital collectibles may be perfectly well served by a platform that supports a rich set of asset transfer use cases. Whereas, a DAO or decentralized exchange that needs extensive onchain logic would require a full Turing-complete programming environment.

All other things being equal, platform scalability degrades as you move toward a more decentralized model. Bitcoin seems to be an exception to this rule as it is firmly on the “money” end of the spectrum, but it also isn’t scalable. The point is that Bitcoin would be even less scalable if it had full Turing-complete smart contracting functionality.

Platform scalability also decreases as you add Turing-complete smart contract functionality. With Turing-complete smart contracts, you need a gas concept to meter contract execution and produce deterministic behavior, which adds fees and operational costs to your application. You also need to allow smart contracts to store arbitrary state or data on the chain, which leads to more fees and increased storage requirements for the underlying blockchain nodes. Most smart contract platforms have a single one-size-fits-all virtual machine for all contracts on the platform, which can also become a scalability bottleneck. All of these factors reduce the scalability and throughput of Turing-complete smart contract platforms.

Opposite Ends of the Blockchain Scalability Spectrum: Algorand and Ethereum

Let’s take a couple of concrete platform examples to illustrate the point.

Algorand Prioritizes Performance Over Turing-Complete Programmability

Algorand is a high-performance, next-generation blockchain that focuses on the money and asset end of the design spectrum, and is also highly decentralized (unlike EOS). It achieves very high performance and transaction throughput by focusing on money, asset, and asset transfer use cases and doing them well.

Algorand’s new scripting language, TEAL, is intentionally non Turing-complete to avoid the gas fees, arbitrary storage, and infinite loops that come along with Turing-complete smart contract platforms. These are specific choices that allow it to achieve high performance for the money, asset, and asset transfer scenarios. This is why applications supporting these use cases that have high throughput requirements, such as Tether and Securitize, are porting their applications to run on Algorand.

However, if your use case requires Turing-complete onchain logic such as DAOs, onchain DEXes, or the development of onchain decentralized protocols sitting above the base protocol layer like Compound or 0x, then the level of programmability in Algorand isn’t as good of a fit.

GET STARTED WITH PURESTAKE’S API SERVICE FOR ALGORAND

Ethereum Prioritizes Turing-Complete Programmability Over Performance

By contrast, Ethereum is the most prevalent full smart contract platform. Ethereum puts programmability first, at the expense of throughput and scalability.

Scalability issues on Ethereum result from arbitrarily complex logic execution and arbitrarily large storage that comes along with its smart contracts. Logic and storage are metered by gas fees, and these fees have increased over time as the number of smart contracts has increased. The underlying blockchain on an Ethereum full node (let’s leave out archival nodes for now) takes over 100GB of storage and growing. Ethereum has a small fraction of the scalability of Algorand from a transaction-per-second and node storage perspective.

However, what you get in return is the ability to express arbitrary smart contract logic in the Ethereum virtual machine. And since all the programs run in the same virtual machine, you get composibility between different contracts which is driving a lot of advances in the DeFi space right now.

For DApp developers, you should carefully consider which parts of your application need to be de-centralized / onchain, and if you really need a full Turing-complete smart contract language to build your application. Turing-complete smart contract platforms allow for arbitrary expressions of onchain logic, but often at a cost in terms of scalability and throughput.

Choosing the Right Platform for Your Application

The scalability of the underlying platform is a critical part of choosing where to build. Even if your application itself doesn’t need high levels of scalability, those scalability challenges inevitably lead to high transaction fees, which will increase your operating costs as an application project, and may make certain use cases unviable from an economic perspective.

You should carefully consider the level of decentralization and programmability you need to support your use cases when choosing a platform. For a use case that requires only an ERC-20 contract on Ethereum, but does not require interoperability with other Ethereum smart contracts, it may make sense to look at platforms that are optimized for this scenario, such as Algorand. On Ethereum, you could be paying a lot more unnecessarily without realizing the benefit of the increased programmability.