We Built a Simple Tool to Pair with Dora, Aiming to Replace the Current Beacon Explorer
This wasn’t a sudden decision. It was made after maintaining the Endurance network consensus layer explorer for nearly two years, considering both maintenance costs and economic benefits.
The “Old Version” is Broken and the “New Version” is Unreachable
The current open-source Beaconchain codebase is in an awkward state of neglect. The upstream development team’s energy has completely shifted to their “V2 version” development.
The first problem: We can’t simply adopt this “new version”.
We tried to deploy the V2 version twice this year, but both attempts failed due to the same issues.
According to their Discord, the development team currently does not intend to let external developers easily run this new system.
In an official reply, the administrator clearly stated:
“hi, currently, the consensus_layer_events table is populated using internal tooling we wrote in order to be able to meet the deadlines. right now, we’re not ready to open source that code…”
It has been several months since this message (it seems the deadlines have turned into spiderwebs). We no longer care when they will open source it, because when open source is not complete, it is truly not open source.
So, what about continuing to fix the old version?
Obviously, this is still a thankless task. The Endurance chain will follow Ethereum’s upgrade pace (such as Fusaka, Glamsterdam, etc.). Fixing current errors means we need to independently (this is the key point) maintain a code repository with over 100,000 lines of code, none of which was written by us, for the long term.
Once Ethereum’s protocol undergoes major changes, fixing any single function might cause even Gemini 3 Pro with its 1M Token window to get lost in it.
To show this isn’t just an excuse, readers can refer to two other mainnet block explorers that also use this codebase: Lukso and Gnosis Chain:
- As of the day of writing, the calculation errors for APR 7d/31d/365d for newly added Validators remain unfixed on both Lukso and Gnosis Chain.
- Their Ethstore pages have even been taken down because they could not be maintained.
The above technical debt accounts for 60% of our decision.
The Economic Score: Expensive and Bloated Architecture
The other 40% is simple: The tech stack is absurdly expensive.
From an economic perspective, even if Beaconchain open sources all code in the future, we still have enough motivation to replace it. Because it relies heavily on Google’s Bigtable.
Big Costs
Bigtable is just one example. I feel the beacon explorer’s design completely ignored infrastructure costs.
Regarding the total cost of running this system, there were approximate figures in a Gnosis DAO post (but since this is a bundled service quote, there are middlemen earning a markup):
From our data maintaining the Endurance mainnet: currently, the cost of the Bigtable service alone is about $800 per month. Moreover, as a proprietary service of Google, Bigtable has no low-cost self-hosted alternative.
We don’t understand why, with so many free, efficient open-source databases available, Beaconchain V2 still chooses to bind itself to an expensive cloud vendor lock-in database.
Worse still, one database is not enough. To run the full Beaconchain product, you need to collect Bigtable, Redis, Clickhouse, and Postgres. This makes operation and maintenance unnecessarily complex.
PS: In comparison, another equally bloated blockchain explorer, Blockscout, although it made a historical mistake in language selection by choosing Elixir, a reliable but slow Erlang dialect, at least it made a decent choice in terms of databases.
Our Solution
Actually, we don’t need anything that complex.
While running the beacon explorer, we have also been running another open-source lightweight explorer called dora for a long time.
The more we use Dora, the better it seems.
The only shortcoming of dora — or rather, the place where we still occasionally use the beacon explorer — is the reward statistics function.
So why don’t we build a reward statistics service that is as lightweight as dora just for this part?
In this way:
dora + our light weight rewards server == all our need
And so, it was born:
https://github.com/OpenFusionist/beacon-rewards
Core Features
-
Extremely Lightweight (Lighter than Dora!) All data is in memory, no database.
- This means that even if it runs for 100 years, there is no need to upgrade hard drives or migrate databases.
- Memory usage < 100MB.
- The only drawback: It requires high-intensity Beacon API requests for about N minutes at startup to rebuild the state (the bottleneck is not on us, but on the Beacon Node Server’s response time).
-
Simplicity First It exists solely to fill the gap for “lightweight yield monitoring”. The codebase is tiny—an LLM can customize a function for you in a single prompt.
-
Extremely Low Cost Because it is Stateless, we don’t need backup servers or expensive cloud databases. Server hardware suddenly broke? SSH into a new server, start docker, wait a few minutes, switch DNS domain resolution, and everything is back to normal. Monthly server cost does not exceed $50
What Can It Provide?
It solves 99% of the problems everyday stakers care about:
- Network-wide APR trend in recent days: Are there large-scale fluctuations?
- Leaderboard of all stakers: Are there new whales appearing?
- Current staking reward data for interested wallet addresses: All validators corresponding to an address are aggregated, rather than displayed index by index.
It’s Too Good to Be True! So What Can’t It Provide?
- Unlimited history lookup. For example: “I want to check every specific reward detail for a certain Validator on a certain day last month.” Sorry, can’t do that. Under the default startup configuration, only 24 hours of precise data is stored in memory.
If you are a developer or financial auditor who needs to care about detailed historical yield data, then this service is beyond what this tool is for. For the vast majority of users, focusing on current and recent yields is the core need.
If all goes well, we plan to gradually phase out the current beacon explorer.
Considering that some external developers may rely on the beacon explorer’s API, we have developed a proxy to be compatible with these APIs. If your API is in the list above, then No further action is required — requests that work normally now will still return content normally in the future.
For other users, you may have to gradually adapt to the new combination in the future:
https://light-beacon.fusionist.io + https://light-beacon-rewards.fusionist.io