Solving the Blockchain Trilemma with Essential Design Choices

Constellation is about to have a breakthrough in the blockchain revolution, but do we really need another infrastructure/base layer protocol?

The Crypto Industry has been full of companies that make a quick buck from fundraising, and very few deliver on their promises. While crypto communities pressure companies to deploy technology quickly to ease their fears that the company is actually building something, this can negatively impact a company’s design decisions for longer term success.

As a leader, you make design decisions to orchestrate a strategic rollout of a business, idea, or innovation. As design choice pertains to innovation, people take various approaches that they think will establish a competitive edge, create long term viability and sustainability, or generate revenue to show viability of the idea/business. The key to making the best design choice is to acknowledge the pros and cons of each approach and to execute with confidence once your choice is made.

At Constellation, one of our essential design choices has revolved around the idea that there needs to be a balance in the value exchange at both the protocol layer and the application layer where developers have complete flexibility and configurability in how they design and build applications that connect to our base layer. Namely, this addresses the Fat Protocol Thesis where value would be built on the base layer protocol (layer 0 or layer 1) and not on the application layer like we saw in Web2 (i.e. Facebook, Amazon — where there was no value occurring on HTTP (internet base layer protocol)). In early iterations of Web3, we see an over indexing of value on the protocol layer that forces the application layer to comply and conform with existing standards that are supported on the base layer. As such, we have seen rather limited use cases evolve beyond tokenized economies that benefit the base layer.

For example, Smart Contracts were initially an idea by the Bitcoin community to build an application layer. Ethereum launched in 2015 with a command line crypto wallet and developer documentation for Smart Contracts that were extremely cumbersome but were easier to execute on Ethereum. These design choices, and focus on smart contracts, led to rapid growth of adoption but simultaneously created a lot of gaps and errors on the protocol layer (but value was retained at the protocol level). As a result, L2 solutions and applications have arisen to address the security, scalability, and flexibility issues of Ethereum. We have also seen the rise of new L1 networks that have made key design decisions that deprioritized decentralization while prioritizing developer tooling and adoption. These design choices might appear to show scalability in the form of application support with their programming languages; however, they’ve created a lot of tradeoffs in the areas of governance, value between base layer and application layer, uptime, network and application support flexibility, and decentralization.

Conversely, Constellation wanted to address the Web3 “blockchain trilemma” of solving scalability, security, and decentralization. Through flexibility and configurability around our L1 application tools, called State Channels, Constellation enables not only network scalability but application use case scalability. Our aim has been to create technical feature parity to the tools of Web2 but also to bring an evolution to Web3. In addition to flexible configurability, this evolution would include L1 applications/State Channels, on Constellation, with the ability to design their incentivization structure without being hindered by base layer fees. These key design choices have required more upfront education to our community while forfeiting short term easy marketable wins (i.e number of applications being built and fee based business models).

Constellation has maintained our integrity (no shortcuts) in our vision to build a network that expands beyond existing network functionality and current crypto use cases, while also avoiding the pitfalls of so many other networks in our effort to achieve real adoption. And this was by design.

While many new blockchains are tackling the “blockchain trilemma”, the last five years have shown us fly-by-night companies in Web3 (I won’t discuss names) that have cratered due to poor management, inability to execute, and overzealous visions. Others have been successful at quickly deploying developer tools and achieving a high market capitalization with vanity metrics, but at the expense of network features, capabilities, and expanding use cases.

Our design choices may not have satiated the need for immediate gratification as seen in numerous crypto communities, but our choices will result in a network that will be used in Web3, and beyond, for years to come.

Constellation’s Design Choices

If blockchain is really just a distributed database, then the current ways of accessing and using blockchain networks as a distributed database are extremely limited. Right now you have extremely limited standards and methods to leveraging a network (e.g. ERC-20 and ERC-721) that are pushed and marketed by network stakeholders to drive adoption. The current distributed and decentralized database is still underdeveloped because of its lack of tooling and flexibility to extend to every application that leverages data, thus networks have to invent use cases (and invent problems to their solutions). It’s not a bad approach — advertising has been forcing us for years to adopt products we don’t need.

Additionally, if the core value proposition of a decentralized network is immutability, then we need to expand the possibility of this decentralized database to work with any distributed database (centralized or decentralized) by creating feature parity with data management tools (Kafka, Spark, Databricks) that connect to data storage services. Constellation is a platform and network that provides a new category of capabilities highlighting data validation, security, and immutability in the data management stack.

Below I articulate the high-level reasoning behind our design choices: network decentralization (Constellation’s Hypergraph), flexibility in configurability of applications (Constellation’s State Channel Framework), and Security, Scalability, and Fee handling.

Decentralized Network

Decentralization comes threefold:

• Infrastructure
• People
• Governance

First, Constellation focused on building a decentralized network (infrastructure) with a vision that would capture the hearts and minds of the (people) who believed our design choices would lead to the solution for a scalable decentralized network. Without that, programmatic (governance) couldn’t be accomplished because there would be limited involvement.

Building a globally distributed system was the hardest of the design choices. From a technical perspective, it reveals limitations on integrating rapid code changes and upgrades, because the entire network must read and adopt these enhancements. Additionally, network stability on a decentralized network is very difficult to achieve (we are even seeing struggles from overly centralized networks with node operators). Other networks chose to create centralized master nodes to ensure network stability and uptime.

Why does this matter: Decentralized networks provide the opportunity to evolve computing and processing and enhance application security with no single threat vector. Cloud computing was the evolution of centralized server support, and decentralized networks will be the evolution of cloud computing. Additionally, organizations like the US Department of Defense can use decentralized networks, and the consensus mechanism that organizes and processes data on the networks, to identify breaches in centralized databases (a very complex use case that pushes emerging technology). Having even the smallest centralized portion of the network validating a data type could present vulnerabilities, and thus not be a clear driver for switching away from the cloud.

Application Flexibility

The key thing here is that every blockchain protocol forces a developer to conform to a particular validation syntax or criteria that is read on the global state. If you don’t communicate 100% in that programming language or framework, then you can’t operate on that network (e.g. limitations of smart contracts). This means that other L0 networks are not true L0 networks because they still have that forcing function. Through our State Channels (our version of smart contracts), Constellation chose to emphasize developer/user flexibility and configurability that is based on someone’s needs, not on what the network tells you to do. It allows anyone to spin up their own network, with their own layer of incentives.

It is much easier to force people to work with a certain standard and use case, and then push marketing around that use case. It is much more difficult to enable flexibility with the consensus layer. However, flexibility through tooling is what created the internet and allowed the internet to grow to what it is today.

Scalability, Security/Validation, and Fees

When one application needs to depend on another application to function, it requires validation: an application needs to perform some validation to know what it’s depending on. Many networks solving the scalability problem have some validation at the network level, but not in full, and thus require separate applications to handle another layer of validation (bandaid on a bandaid). This requires some oracle application to validate and clean the data to understand the validity of inputs. This is not scalable or secure: how do you know what data is going into an application?

Regarding fees, Constellation chose to start off with a feeless network so we could explore evolving use cases without these variable barriers to entry. While network fees help provide security and show network utility, they severely limit the types of applications that can use a decentralized network. If validation was done on every application on Ethereum, before the transaction hit the network, the cost would be extreme. Hence layer 2 solutions. But even with layer 2 you are dependent on another application (another bandaid).

As we roll out mainnet 2.0 and developer documentation, which will invite utility on our Hypergraph Network, we will introduce fees, in $DAG (our native token) for unlocking Hypergraph bandwidth. However, there is still a freemium model with one free transaction per snapshot. So if your application can accept slower transactions (~10 transactions per minute) then this is all you need, and you can access the network for free. Conversely, if you need to send transactions faster, then you need to pay a small fee in $DAG, but transactions are processed extremely quickly (~50 TPS) per wallet address.

At the end of the day, governance can ultimately be responsible for blockchain fees after the first use cases are built and scalability is explored. Why limit yourself in the beginning?

SUMMARY

Regardless of whether you decide to follow us and build on Constellation, start questioning the design choices of companies and whether or not you are being forced to fit into another network’s parameters. At Constellation you configure your vision.

The next phase of building out Constellation will invite our community to design the future of Web3, which we see as the convergence and collaboration of Web 2 and Web 3. This will invite entrepreneurs from all walks of life to easily use Web3 technology. Our vision is to make blockchain another tool for another developer to add immutability to their tech stack: Data Management, Data Storage, and Data Immutability and Validation (Constellation). By creating technical feature parity to existing data management tools (Spark, Kafka, etc.) we will open up a whole new world to applications that are already in existence. This will require the flexibility of State Channel frameworks that allow for configurability based on people’s needs (not what the network forces).

Stay tuned for our developer documents to begin configuring your world.

Explore with us these use cases:

• Solving the complexity of order books;
• Developing complex dependencies between networks and applications;
• Solving settlement and validation/oracles;
• Oracalizing data from IoT sensors while creating new dependencies
• Developing global stakeholders around the governance of data and the future of commerce
• Creating applications that add immutability to existing data management solutions
• Interoperability between token types, networks, and data.
• Bridging Web2 and Web3 for the Metaverse
• Validating and learning identity on the blockchain to advance DeFi
• Creating social applications and discoverability in Web3
• Anything you want validated on the L0.

Thank you,

Ben Jorgensen

CEO of Constellation Network $DAG $LTX

https://twitter.com/BenJorgensen

www.constellationnetwork.io