HIP 71: Scaling the Network with Governance & Hedera

[vincenzospaghetti]

HIP 71: Scaling the Helium Network - Transparently

Author(s): @leogaggl, @gregscullard, @pathornteng, @jamesmeikle, @tonysmith55 Start Date: 2022-09-12 Category: Technical, Economic, Meta-Governance Original HIP PR: #480 Tracking Issue: #486 Status: In Discussion

Summary

This HIP which builds on the excellent work done by the creators of HIP-70, is focussed on delivering important structural changes to the Helium network as proposed in HIP-70. However, it aims to improve on some of the shortcomings, such as further centralization (rather than decentralization) of network activities. It also aims to introduce more formal governance structures, which have been absent from prior proposals and will allow more predictable operation, which is critical for enterprise adoption of the utility-scale network we are all aiming to build.

Another difference to the original Helium Scaling Proposal is using an enterprise distributed ledger technology (DLT) as an alternative example. It is important to note that, unlike the original HIP-70, this is more of an example of how this technology can be used. This HIP proposes a formal evaluation and comparison phase (and some evaluation criteria) to ensure the best tool is eventually chosen (see Governance section).

This focus on governance has to be more than just superficial. By including representatives of all stakeholder groups - most importantly, hotspot owners and operators that have put up their time and money to build this network - it will ensure a stable and sustainable network for all.

In this HIP, we propose an alternative architecture for the Helium network to use the Hedera network as a layer 1. The new architecture is built to meet the number of requirements that we believe are critical to the network’s success. Our new design goals include network scalability, strong network governance, transparency in data reporting and rewards distribution, and decentralization.

As per HIP-70, we also acknowledge that this change removes the need for staked validators operating block production and challenge creation as they do today. However, we would expect (some) validators to be ideal candidates for operators of decentralized oracles.

That said, we expect that HNT stakers will migrate their positions towards securing current and/or future subDAOs and participating in governance through the vote-escrow token-based system proposed in HIP-51. Removal of the staked validator reward also returns the full 6.85% of HNT emissions back to the rewards pool, benefitting Hotspot owners on all subDAOs. In the first year alone, this is estimated to be over 2 million more HNT rewarded.

Similar to the HIP-70 proposal, these changes are complementary to the changes proposed in HIP-51 and a necessary set of changes to more easily implement some of the redemption and governance mechanisms proposed in HIP-51, HIP-52, and HIP-53. We also expect that more protocols will be attracted to participate in the Helium ecosystem because of the move to a more widely used Layer 1 blockchain.

Rendered View

https://github.com/helium/HIP/blob/main/0071-scaling-with-governance-hedera.md

[vincenzospaghetti]

Please see the open channel in the Helium Official Community labeled #hip-71-scaling-with-governance-hedera to participate in the open discussion.

[leogaggl]

Hi @vincenzospaghetti - thanks for creating this! I noticed that there is no rendered view to the actual HIP markdown document: https://github.com/helium/HIP/blob/main/0071-scaling-with-governance-hedera.md. Can this please be added?

The document in the Helium HIP repository is also an old version of the original document

And as mentioned in the Discord channel there is some confusion as to why the title of the channel as well as the title of the HIP document was changed. It has already caused confusion in the HIP channel as it suggests that the HIP is prescribing a change of L1 to Hedera when it clearly is not.

The HIP clearly is calling for an independent evaluation of ALL options.

I am not sure if that was the practice with any of the previous HIP proposals. But we would prefer this to stick with the original please.

[leogaggl]

Hi @abhay - since the original PR has been closed I am replying to your comment here.

This is a bit disingenuous. The idea of a new L1 has been proposed as early as HIP-51. That was back in January of this year.

I agree. The idea of a new L1 was indeed discussed during the HIP-51 vote and I was in there during this conversation. But there were no architectural details available at all at that time. And I certainly do not remember an off-chain centralised oracle structure being floated ever before HIP-70 was dropped. And it would have been reasonable to assume that for a change of this magnitude a thorough and independent evaluation would have been made.

You could say that calling this disingenuous is in itself disingenuous - but I don't think calling it anything is useful. There are different ideas to scale this. And all we're asking is to fix governance and have a proper process and decide on merit.

It is one of many options but given that there's a community vote on HIP-70 plus several engineers already moving towards a HIP-70 implementation, should that work be ignored?

I fully agree that this is unfortunate - nobody wants to see work wasted. But to put the blame on an improvement proposal is not really fair. See above. If the Foundation would have done what is supposedly their job we wouldn't be in this scenario.

Let's hope this can be resolved quickly and collaboratively! Certainly happy to discuss an take input and suggestions.

[abhay]

Hi @abhay - since the original PR has been closed I am replying to your comment here.

Sure. Let's keep going.

I agree. The idea of a new L1 was indeed discussed during the HIP-51 vote and I was in there during this conversation. But there were no architectural details available at all at that time. And I certainly do not remember an off-chain centralised oracle structure being floated ever before HIP-70 was dropped.

You're right. I think the earliest conversation about this was in June. Maybe earlier but I can find it discussed as a solution for scaling Proof of Coverage with a 30 second discord search.

You could say that calling this disingenuous is in itself disingenuous

This is getting silly.

Let's hope this can be resolved quickly and collaboratively! Certainly happy to discuss an take input and suggestions.

Finalizing the draft, and moving to a vote seems to be the best outcome. I'm happy to help.

[vincenzospaghetti]

Hi @vincenzospaghetti - thanks for creating this! I noticed that there is no rendered view to the actual HIP markdown document: https://github.com/helium/HIP/blob/main/0071-scaling-with-governance-hedera.md. Can this please be added?

The document in the Helium HIP repository is also an old version of the original document

And as mentioned in the Discord channel there is some confusion as to why the title of the channel as well as the title of the HIP document was changed. It has already caused confusion in the HIP channel as it suggests that the HIP is prescribing a change of L1 to Hedera when it clearly is not.

The HIP clearly is calling for an independent evaluation of ALL options.

I am not sure if that was the practice with any of the previous HIP proposals. But we would prefer this to stick with the original please.

Hi Leo - I've added the rendered view. Can you update a new draft then? If this is now going to focus on evaluating other L1s, can we remove the part about Hedera altogether?

[leogaggl]

Hi @vincenzospaghetti - not sure what you mean now going to focus. The HIP hasn't changed. It was always proposing this. The core issue is the centralised off-chain oracle structure and Hedera was the example (or reference design if you will).

Could you please have a look at the document you have linked? It appears to be an older version of the HIP draft (you can see that one author is missing).

[nodlRob]

Posting here a Q&A that was posted to the Helium Discord channel (https://discord.com/channels/404106811252408320/1028034216409186354/1028780543522902036):

Hi, I represent The HBar Foundation, the organisation that provides grants and technical support to organisations that are building on the Hedera network. For clarity, this is a different entity from the Hedera Governing Council that overseas the governance of the network, and Swirlds Labs which provides core product engineering and developer advocacy support for the fully open source Hedera stack. The decentralised governance of the Hedera network, in addition to its superior technical properties, have made it a strong candidate for a L1 for IoT networks (and Helium, in particular).

These are responses (from a Foundation perspective) that have been posed in the Discord channel:

Q1) Do you, or any of the HIP authors, have a financial interest in Hedera? A1) Not materially. Foundation staff do have some compensation in HBar but I have been in this Hedera ecosystem for 5 years - and believed in the tech long before I joined the Foundation when it was formed a year ago.

Q2) Given that Hedera is a small scale network, how well funded is the managing entity (e.g., can they make it through one or more market downturns)?

A2)Hedera is not a small scale network. It is a public, open source, distributed network hosted by some of the world’s most recognisable organisations. This is the Governing Council who are overseeing the first phase of decentralization. The second will be 100s of community nodes and ultimately anyone will be able to run a mainnet consensus node. As a proof of stake network, which depends on distribution of tokens as well as token price to ensure that no bad actors can accumulate enough tokens to compromise the network, this controlled and methodically rollout is deemed the best approach (unlike many networks that have raced to dump their tokens).

Currently anyone can use the network via its APIs of Consensus and Tokenisation or run smart contracts on the Hedera EVM. Network usage is high and the Hedera network had more transactions on mainnet in 18months than Ethereum had in 5 years. This usage is accelerating as more enterprise and Web3 use cases come into production.

Due to its design (a Hashgraph rather than a blockchain) Hedera does not need to trade off between speed, security and decentralisation like blockchain architectures do, and so our 10,000 tps (throttled currently) with 2-3 second settlement, low and predictable transaction cost, asynchronous Byzantine fault tolerance security, and approach to decentralisation (mentioned above) is unlikely to be matched. Centralisation is key here - many blockchains can we switched off by just a handful of colluding insiders - and this is not a viable option for a distributed network.

Q3) In the event that Hedera were to fail, as many crypto projects do, how portable is the proposed architecture to other L1s? A3) Hedera can only fail if the Governing Council decide to close the network and even then it is now fully open source and so anyone can stand up a new network. The massive use cases now running on the network from Governing Council members alone (along with hundreds of other businesses and dApps) makes this extremely unlikely.

The Hedera codebase has always been open source except for the base layer hashgraph protocol which was originally 'open review' (i.e. open to read the code, but with legal and technical controls on copying it). The reason for this is that for an enterprise-grade proof of stake DLT, it is important that the network doesn't keep on forking and undermining the value (remember this has happened repeatedly on Bitcoin and Ethereum). The intention was always to make the full stack open source once there was sufficient adoption and in February 2022 the Governing Council voted to make the protocol layer open source as well. So nothing is patented or proprietary and anyone is entitled to do whatever they wish with the codebase. Bootstrapping a PoS network while keeping it secure is hard though, and so I believe the Hedera network is by far the best (and only?) chance of establishing a global, resilient, high throughput DLT that supports IoT use cases. See https://hedera.com/open-source

Q4) Given that the purpose-built Helium network struggled to scale to handle on-chain PoC activity, what assurances can be provided that Hedera can handle on-chain PoC load both now, when existing Hedera network usage is low, and in the future if/when usage increases? A4) Hedera is currently tested to 10,000 tps in its throttled state and theoretically 100,000 tps per shard. Sharding (different from Eth sharding approaches) should mean that scaling is unlimited.

Q5) Is the Hedera managing entity willing to provide a a financial grant to the Helium ecosystem in a similar scale or greater than the Solana Foundation? A5) Yes. I am not aware of how much the Solana Foundation has promised to bring Helium to their blockchain, but the HBar Foundation is set up for this purpose and has been granted a significant amount of funding by the Governing Council. We would be happy to work with Nova Labs on this or introduce one of our many experienced developer/systems integrator partners to build the Helium network migration onto Hedera.

I hope this response helps - I’m very happy to go into more detail, provide links and references, or answer any other questions that the Helium community have.

[vincenzospaghetti]

@leogaggl - I made no changes to the document text of your PR. When I view the original PR, I don't see how this differs from the rendered view. The only thing I did was unlink the 'LoRa Committee' document that was later attached and did not add to your HIP. Can you make sure there were no changes that had been added to the LoRa file rather than #hip-71?

Also, for clarity, I asked you several times, as did others, about the focus of your HIP on the original PR, #480. It was never clear what the priority was. This is why I reiterated that in the PR comments several times, and it is now being questioned in the Discord chat similarly. For reference, your response was that this HIP should not be moved to be several HIPs as the issues between oracles, L1, and governance, are "intrinsically connected." My suggestion to move this into several HIPs has always been to help you focus your argument and tell the story around that.

I just want to help you as best as I can. If there is something materially wrong with the text that I moved into this issue, let's reopen another PR, and we'll push that to be sure. Again, I made no changes to the text.

[vincenzospaghetti]

@leogaggl, how do you want to move this forward? Or what would you like to do next with this HIP?

In our HIP Triage Call (10/26), it was suggested to have more contributors to this.

[leogaggl]

HI @vincenzospaghetti - not sure about the triage call since they are at 2.30 am for us. Are there recordings? We have always said that any contributions are welcome!

As for where to next - I think Nova has made it pretty clear that they will not consider and since they are the ones funded for the development what do you want us to do? In this constellation, you will always only get one outcome.

[vincenzospaghetti]