Project "Prometheus" - Hydra L1 TPS = Infinity

Tech Proposals
1

As a consequence of the approved HydraGon L1 project, I am excited to share with you project “Prometheus”.

This is a special project which focuses on enabling HydraGon to have infinite scaling as a L1 public blockchain.

A novel approach that showcases the ambition behind the long-term vision of Hydra.

In the concept, horizontal scaling is aimed which could put it in the top position of the highest performance ecosystems.

With this design, Hydra would be capable of reaching infinite scalability without sacrificing decentralization, all while remaining an L1 protocol.

Make sure to read the Project “Prometheus” whitepaper →

The concept is in an early phase and we’ve conducted preliminary feasibility study. Generally, we wouldn’t be feeling comfortable sharing this with our community at this stage, but following the request from the community to be more involved, I am sharing the model for peer reviewing. The work on this project has been going for several months.

Please keep in mind that the design is extremely innovative and may be subject to some modification as we progress with the research.

This concept should come as a soft-proposal for a preliminary discussion. For the time being, the funding will be covered by LockTrip and will not incur any charges. It is tightly related to HydraGon L1 as the underlying consensus has unique characteristics that unlock the model.

A lot of HydraGon’s features were designed to empower the design of Prometheus and to create a unique system that would resolve the challenges with scalability.

HydraGon allows us the freedom to create and build on top, and the “Prometheus” sharding project is the ultimate goal that comes after a potentially successful deployment of the new EVM L1 chain.

This proposal seeks approval on the following items:

  1. To acknowledge Promotheus as a worthy project to be explored further, refining the design and continuing research on it

  2. To approve the general philosophy and direction of the concept

  3. Using Promotheus for marketing purposes and positioning it as part of the vision of Hydra chain

13 Likes
2

Harmony One is focusing on sharding technology for a while!
anyway these are great news for Hydra!

1 Like
3

Just read the whitepaper. I’m very excited about project “Prometheus” ! HydraChain’s Cross-Shard Communication (CSC) protocol that improves the allready excisting protocols from other top 25 blockchains. Looks very prommising and future ready ! Thanks for shar(d)ing.:wink:

2 Likes
4

The Prometheus project is a great achievement I am very excited about the future it is finally going in the right direction :slight_smile:

1 Like
5

Just read the whitepaper. Very impressive plan for infinite scalability!

5 Likes
6

I’m excited to see that Hydra wants to pioneer in L1 scalability solutions like sharding. I believe there is more future to be found there than there is in L2 solutions. I do have some questions after having read the whitepaper:

  1. On page 25 it is written that everyone would be able to deploy their own shard and create incentives for users to join it. So, theoretically speaking, if I had a massive amount of Hydra I could create a shard, put all my Hydra in it and convince small fish to join it in order to steal there Hydra with, let’s call it, a 1%-attack? If I just make sure no big fish enter the shard, I would have the playing grounds all to myself. Then I could just bridge all of that Hydra back to a ‘normal’ shard. Looks like an easy scam to pull off.

  2. Let’s say I want to stake but I don’t have the required processing power to do so. In that case, I would be able to create a shard with only myself on it and no economical activity. I would still be staking as much as in any other shard but my required processing power is a lot less since there are no transactions happening, is that correct?

  3. I understand that there can be an ‘infinite’ amount of shards made. But what happens if you want to merge shards or if activity on one shard stops? I understand you can just bridge all your Hydra from one shard to another but is that possible up until the very last staker bridges his Hydra to another shard and, thereby, disbands any processing power left in that shard? Would that shard still exist, without making any blocks? And would any other shard still attempt to communicate with that abandoned shard through the CSC?

  4. Having the points here above in mind, I assume it would be a wise thing to put some restrictions on making a shard by ‘anyone’?

2 Likes
7

My concerns are whether scalability should be a priority at this point? There is a mention of 80,000tps! There is simply no requirement for this, I doubt Hydra has had 80,000 transactions in the past 12 months.

TPS is simply a marketing gimmick. We need to look at what has worked, that has been Ethereum. Even now ppl would rather pay materially more to use Eth than an alt L1 where fees are near 0 and TPS is much higher.

TPS and near zero fees was the last cycle, Solana, BSC, Avax, Tron. Why not focus on increasing our transaction volume rather than our scalability (which is quite evidently not needed).

8

Funding is said to be handled by Locktrip for the time being and there will be no fees. How long would Prometheus take to develop and will Prometheus require funding from the HydraDAO Treasury?

9

Thanks for the great questions, before responding, I want to emphasize that the concept may be subject to further improvement as it is still in the relatively early stage of research and development.

Regarding the specific questions:

  1. Each shard represents a standalone chain. So a small chain with small staked amount, would likely enjoy a “small” amount of trust budget from users. Also since each shard will have its own governance on selecting which other shards it can connect with, if your shard suffers a major incident, it will most likely be disconnected by other shards, ending up hurting the staker (as you emphasized you would have staked a massive amount of HYDRA). So as a risk/reward vector for the shard deployer, there is the risk to entirely lose their own HYDRA if they do a malicious act.

In addition, a shard with a single large staker does not necessarily mean it would be under control of that large staker. As outlined in the whitepaper, the exponentiation formula would allow for governance to adjust the Nakamoto Coefficient (minimum number of nodes required to achieve consensus). This on its own could dilute the voting power of the biggest staker and enabling the smaller stakers to have a higher voice in he transaction validation process.

HydraGon’s L1 consensus can play a key role in facilitating more flexibility in equating the Nakamoto Coefficient among shards, even if they have a different distribution of voting power.

And as a third measure, we want to apply sentinels as third-party watchdogs that could oversee the activity on a given chain, and be offered a bounty for preventing abuse. Similar to the design of the defenders on the current Hydra Bridge.

  1. The processing requirement comes from HydraGon’s L1. The 2 sec time would require significant resources and expertise even if done with little activity. If you try to deploy a shard, you would : 1) migrate your own HYDRA - effectively depositing your HYDRA into your own shard, which would mean that it would be your own responsibility to ensure your shard is in good standing. If not, it may be disconnected by other shards via an explicit governance vote.

By enabling an open system with account-level sharding, it would come to aligning the interest of the shards to provide a good service in order to attract activity among them and generate a network effect. Otherwise, they would be on a path of isolation, which will end up hurting the shard deployer. So by design, responsibility comes as a pre-requirement in addition to the economic requirement of being the first to migrate the initial HYDRA to a newly deployed shard.

  1. In the context of account-level sharding, each shard is a standalone blockchain. Migrating back staked amount would be possible to the extent the shard going offline is doing it in a pre-planned and carefully executed manner. This will allow it to communicate with the peer shard to which the HYDRA will be migrated and merged onto. For the receiving shard, this should be a positive event, as it would gain strength. This on it’s own should in theory open a pathway for supporting the closing.

  2. We can definitely discuss in more depth the process of deploying a new shard. The initial deployment amount can be higher (e.g. 100,000 HYDRA and no more than a Nakamoto coefficient of 10)

The proposed permissionless approach with the subsequent ability for peer shards to disconnect via governance (with high consensus requirement) implies that a shard will be given trust based on the deployer’s commitment of risking his own funds first. Then if the deployer is irresponsible, he will naturally be pushed away with less connectivity and may end up being isolated…and therefore forced to improve and even be audited by external community members.

4 Likes
10

Prometheus would come as next phase after HydraGon L1 which is a really long-term goal. We are making sure it can be handled by the existing HydraGon team.

At this stage it is hard to estimate, but what I can say is that it would most likely be insignificant when measured against the economic power, market cap, and existing emissions of HYDRA.

Also adopting Polygon’s Edge SDK offsets a substantial amount of cost in terms of development and ongoing maintenance of the protocol.

So in general, this should be a low-impact decision when it comes in the future.

4 Likes
11

A shard represents a standalone chain. Will shards then benefit the economy of Hydra (burns) or just act as a network growth effect?

12

Since all shards share HYDRA as their native coin, burns on one shared will effectively benefit all HYDRA holders on all shard. This is further supported by the fluid and seamless flow of funds between shards.

Most users would likely not differentiate much between the shards, as they will form a collective network together.

You can think of the Hydra network as a city and each shard as a separate district or street. You can easily move around the city and travel between districts, regardless of where your home is located. Similarly, even though you keep your HYDRA in shard #4, you could easily interact with any other shard and even move to a different shard with a single transaction. Therefore for the HYDRA economy all shards are “home” and they all contribute according to their economic weight.

13

Yes and no. I agree that scalability nowadays is more a marketing gimmick than anything else. But I believe that it’s a good thing that the Hydra team anticipates on higher demand and starts thinking about it now. Preparing for scalability is a self-fulfilling prophecy. If projects that require high tps, see that Hydra is a suitable blockchain for their high demand, they will be more eager to join the Hydra-blockchain.

Also, high scalability is proportional to low transaction costs. If your blockchain allows for a high tps, you can significantly lower the cost of one transaction given the fact that a DDOS attack becomes harder and harder to execute.

So, working on scalability is not only good for the long term, but also for the short term, since transaction costs can be reduced immediately.

14

But if someone deploys its own shard, starts doing some shady stuff there and then gets blocked by peer shards, he would still be able to make a second shard as a relaypoint? This second shard wouldn’t be blocked by peer shards. He could then transfer his Hydra from his first shard to his second shard in order to then be able to transfer it to any other shard.

Or would the sentinels be able to pick up on something like this and stop it from happening?

I think it’s cool to have a permissionless way to create shards, but is it really usefull? A new shard is only necessary if another shard is getting clogged up with tps. It seems to me that that wouldn’t happen too often. It would be perfectly possible to create a new shard after the DAO has voted on it so that the DAO can closely govern that new shards are economically healthy and aren’t being used for abuse.