search

harmony-one / bounties

Bounty program is to help the community take part in the development of the Harmony blockchain. It covers from core feature to validator tooling, from dApp development to DeFi integration.
MIT License
59 stars 23 forks source link

ONE second finality on Harmony by upgrading our networking layer #14

Open lijiang2087 opened 3 years ago

lijiang2087 commented 3 years ago

Description

Speed up Harmony's transaction finality time from 2 seconds down to 1 second by implementing networking upgrades outlined in harmony.one/networking.

Context

topics to explore:

  1. libp2p fine-tuning on connectivity parameters, peer counts, message handling and routing etc.
  2. HIPv2: Id/Loc, Discovery, Mobility, Multi-homing, NAT Traversal
  3. RaptorQ: Reliable, Efficient Multicast/Unicast
  4. UDP Transport, With DCCP/QUIC-inspired Congestion Control
  5. Benchmarking and profiling on the existing codebase with mainnet onchain data.

Acceptance Criteria

This is a multi-part bounty, each with its own criteria. Our team will help you scope out each project.

Reward

$20,000 USD equivalent in ONE tokens to start.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 100658.9789 ONE (19881.36 USD @ $0.2/ONE) attached to it.

a-zb commented 3 years ago

Hey,

Could you point me to a benchmark or test used to prove the 2 second finality ? I assume this was measured and tested and would serve as a good starting point for testing any performance changes.

If no test for testing finality performance exist, what is the closest set of steps or procedures you suggest ?

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 3 days, 16 hours from now. Please review their action plans below:

1) az111z has started work.

We are an ambitious team and we hope for success, so we can move forward and we have been granted the grant of support for us, and we will be, according to your story 2) d10-cat has started work.

I think to start the congestion issue is most important I will fix this issue by wide market mining capabilities and multi block proccessing concurrently I will use grouped smart contracts to run multiple blocks all at once and use validation smart contracts at minimum 3 to provide a secure trading environment no double spending clear quick and no congestion.. this will take sometime... for the rest of your requirements it seems the best route to take is to go through your existing code and speed things up and connectivity where there needs to be more there in short just taken your current chain and double stack it create a treasury hold run yearly forks to gain some back from burnt tokens this event draws marketing for those who are able to get in on the forked tokens but you would only allow redistribution of 40% which is a lot just numbers you would increase revenue on a yearly by 48% just from the marketing from forked chain and rebuild from it

Learn more on the Gitcoin Issue Details page.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 100658.9789 ONE (19905.51 USD @ $0.2/ONE) has been submitted by:

lijiang2087 commented 3 years ago

Hey,

Could you point me to a benchmark or test used to prove the 2 second finality ? I assume this was measured and tested and would serve as a good starting point for testing any performance changes.

If no test for testing finality performance exist, what is the closest set of steps or procedures you suggest ?

hey arekzb!

more info is here: https://medium.com/harmony-one/2-seconds-block-time-on-harmony-mainnet-aba78ee5643f

and you can also see our blocks finalizing in 2 seconds on mainnet at https://explorer.harmony.one

a-zb commented 3 years ago

Hey, Could you point me to a benchmark or test used to prove the 2 second finality ? I assume this was measured and tested and would serve as a good starting point for testing any performance changes. If no test for testing finality performance exist, what is the closest set of steps or procedures you suggest ?

hey arekzb!

more info is here: https://medium.com/harmony-one/2-seconds-block-time-on-harmony-mainnet-aba78ee5643f

and you can also see our blocks finalizing in 2 seconds on mainnet at https://explorer.harmony.one

Hey, Maybe I mis-spoke - I'm familiar with the 2 second block timing :) I have looked for performance tests or unit tests in historical changes that include timing and benchmarks of the Harmony p2p layer, dht, peer discovery and so, on. I have looked at releases that changed block time down to 2 seconds, but do not see empirical tests of the networking layer that prepared for the move from X second block time to Y second block time to Z second block time.

Meaning, visibility of improvements via tests or benchmarks over time to the p2p layer is what I am looking for and if that exists at all. If it doesn't - are there branches or procedures that can be shared that were used to develop these improvements.

If that doesn't exist, is that in scope as a deliverable you are looking in this issue?

Secondly, in absence of empirical testing, how does the team verify improvements in performance and hence decides to move from X second block time to Y second block time to Z second block time? Cheers, -A

rlan35 commented 3 years ago

Hey, Could you point me to a benchmark or test used to prove the 2 second finality ? I assume this was measured and tested and would serve as a good starting point for testing any performance changes. If no test for testing finality performance exist, what is the closest set of steps or procedures you suggest ?

hey arekzb! more info is here: https://medium.com/harmony-one/2-seconds-block-time-on-harmony-mainnet-aba78ee5643f and you can also see our blocks finalizing in 2 seconds on mainnet at https://explorer.harmony.one

Hey, Maybe I mis-spoke - I'm familiar with the 2 second block timing :) I have looked for performance tests or unit tests in historical changes that include timing and benchmarks of the Harmony p2p layer, dht, peer discovery and so, on. I have looked at releases that changed block time down to 2 seconds, but do not see empirical tests of the networking layer that prepared for the move from X second block time to Y second block time to Z second block time.

Meaning, visibility of improvements via tests or benchmarks over time to the p2p layer is what I am looking for and if that exists at all. If it doesn't - are there branches or procedures that can be shared that were used to develop these improvements.

If that doesn't exist, is that in scope as a deliverable you are looking in this issue?

Secondly, in absence of empirical testing, how does the team verify improvements in performance and hence decides to move from X second block time to Y second block time to Z second block time? Cheers, -A

There wasn't recorded performance measurement but more of a empirical testing on the real network before we decided 2 second finality is possible on our mainnet. The real-world network condition is hard to replicate in a benchmark setting so instead of measuring exactly that 1 second finality is achieved, you can instead measure the p2p network performance for example, the time it takes to broadcast a message to 200 nodes and got replies from all of them. If this time can be cut by half, then we are very likely to achieve close to 1s block time.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 100658.9789 ONE (13527.16 USD @ $0.14/ONE) has been submitted by:

  1. @az111z

@papiofficial please take a look at the submitted work:

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 100658.9789 ONE (11616.55 USD @ $0.11/ONE) attached to this issue has been cancelled by the bounty submitter

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 100658.9789 ONE (11655.81 USD @ $0.12/ONE) attached to this issue has been cancelled by the bounty submitter