Discussing the Upcoming Technological Transformation of the Endurance Network

When the Endurance network launched in late January, it started as just an application chain. Our team, experienced in traditional gaming, soon realized we had more to offer in the Web3 domain. Being just an application chain wasn’t maximizing our potential, so we shifted towards becoming a public chain to support more games.

As a public chain, Endurance’s value extends beyond a single Dapp/GameFi to future developers. For example, its technical specs should meet mainstream developers’ needs over the next decade.

We started pivoting in this direction in early August, experimenting and maturing various aspects. Now, we’re sharing some technical details with the public.

This article focuses on “why this transition is essential,” especially for readers with a technical background. “What it is” should become clear by the end of this read.

Endurance 1.0¹

In my previous article, The Birth of Endurance, I outlined our technology choices for Endurance. However, We didn’t specify our final choice, which was Binance’s BAS technology, designed for Appchains. Another notable Appchain solution from that period is Polygon Edge.

The Good

We built upon BAS’s codebase, adding strict access control:

• We kept Node access private, ensuring all RPC servers are under our control.

• We could filter out harmful RPC requests.

These measures led to a unique situation in the Web3 blockchain network:

• Exchanges can’t access our network without our permission, giving us control over ACE Listing timing.

• As an EVM-compatible chain, we avoided recent inscription attacks since our RPC doesn’t support deploying contracts or setting up ArchiveNodes without authorization.

The Bad

Despite these strengths, Endurance, like most appchains and some alternative L1s and Ethereum’s L2s, has its weaknesses:

Weakness: Single technology stack.

This is not something to be proud of, akin to achieving some kind of “unification.” In the software ecosystem, this is a dangerous signal.

If we need a Node Client, there’s only one implementation; if we need an Explorer, there’s only one option. Over time, you’ll find that although the chain is EVM-compatible, all its infrastructure contributions come from the same group of developers, who often happen to be employed by the same company.

This “single-bridge technology ecosystem” leads to:

1. Slow adaptation to new technical standards. This issue is particularly evident in various EVM-compatible chains I know. For instance, EIP-1559 is still not supported in our Endurance. Similarly, upcoming upgrades like EIP-4844 in the Dencun upgrade, which significantly reduces L2 gas fees, and potential Prague/Electra upgrades in 2025 that lower node hardware requirements with Verkle Trees, are unlikely to be supported.

2. Poor client quality. A blockchain network is not just a protocol, but essentially a software engineering project. Generally, the more developers contribute, the higher the software quality. For example, the recent inclusion of path-based state storage in the Geth client significantly reduced the disk space requirements for full nodes. There are many ongoing QoL improvements that reduce operational complexity and deployment difficulty. How many blockchain clients based on Geth modifications are motivated to continuously cherry-pick these optimizations into their implementations?

Another elephant in the room: these appchains are usually driven by a single commercial company. A sudden pivot by that company can end technical support for your chain, forcing tough decisions about maintenance or migration.

And the Ugly

I often think, “Developers shouldn’t let developers get hurt,” especially when reviewing the code of EVM-compatible chains.

I’m curious how these lone developers manage to keep up with significant upstream code improvements (usually Geth), while also maintaining their “right then, wrong now” aged forks, ensuring no side effects or bugs in each conflict resolution.

If this is our future, I’m more concerned about our team’s wellbeing than minor successes.

Why not fully embrace Ethereum’s open protocol for our network? If Ethereum and most of its infrastructure are open-source (Etherscan being an exception), we, as developers, should be able to use it freely and confidently, right?

As a small company (without even a dime from Paradigm™), we aren’t pressured to play the idol role or assemble an ‘all-star team’ to churn out ‘priceless yet futile code’ merely for inflating our valuation.

Joining the core Ethereum developer community is our best option.

Endurance 2.0

My vision is for Endurance 2.0 to run current Ethereum clients(including execution, consensus, and validator clients) with no code changes, just configuration adjustments.

Technically, it resembles a devnet but with a vast initial state data, comprising the current account data from Endurance 1.0.

Specifically, we’ll migrate account state data, including balances, nonces, and contract code and storage (excluding historical transactions), to a genesis.json file for Endurance 2.0.

This approach positions us as the blockchain most similar to Ethereum’s technology (if there are others doing the same, I’d like to know; otherwise, it’s a key selling point for us :D).

The biggest benefit this brings to our developers’ mental health is that we can develop as both Ethereum and Endurance developers without worrying that our code is just for maintaining the company’s face.

Our developers will contribute to Ethereum, wait for battle-tested releases, and then integrate those into our network.

We aim not to maintain our own fork, though minor changes might happen in rare cases (none so far).

Interesting Points

Endurance 2.0 offers insights for Ethereum’s future diversity process:

1. We aim for ideal client diversity from the start, something Ethereum desires — a parallel universe where neither Geth nor any other client dominates!

2. Initially, our company owns most Validators (over 66%), leading to centralized control. This is a temporary measure for network protection against dishonest entities. We aim to decrease our share to below 33% within 1-2 years.

3. We’re thinking about long-term incentives. Until we become a minority in the network, we aim to use our Staking Rewards to promote diversity among all stakers. This includes rewarding smaller clients and solo validators in less-represented regions and countries.

Final Remarks

For those who’ve read this far, I welcome thoughts and suggestions via email at charles at fusionist.io.