Network Sync Contest

[buckyroberts]

Task

Create and document a network synchronization model that allows all nodes to remain in sync as the network PV changes.

Background

Users have the ability to lock coins and allocate them to a Bank of their choice (aka “boost” a bank). When coins are used to boost a Bank, the network will place a freeze on those coins for a set amount of time to prevent them from being withdrawn. The top 20 boosted Banks will act as network delegates to elect a PV. The weight of each Bank's vote is equal to their total boost. For more information on Bank boosting, see the Governance model.

---

There are many factors a Bank will use to determine which validator to vote for as PV, and while some are purely technical (e.g. checking for invalid calculations) others require human judgement and manual input (e.g. fair Tx fee cost).

Purely human factors

• Tx fee cost
• Fairness / max earnings limit - intended to prevent one node from constantly accumulating fees

Human factors considering network reliability

• Reliability / downtime - number of retries before PV is considered offline
• Performance - judgement needed for when Tx times become too slow
• Censorship - when existing PV ignores certain blocks (most likely stake related which would help opposing view)
  • added as part of “network reliability” since a small percentage of missed blocks due to network reliability are expected
  • this can also be considered “reliability / downtime” with the only difference being if the missed block was intentional or not

Technical / automatable factors

• Cheating - PV improperly calculates updates balances (intentionally or unintentionally)
• Sprinkler attack / conflict blocks - PV sends different “next” blocks to multiple CVs resulting in each CV independently building a different blockchain
  • this will be noticed by the banks as they receive conflicting confirmation blocks from their CVs
  • banks will broadcast these conflicting confirmation blocks immediately to the network and evidence that the PV is untrustworthy

---

Notes

• Must be Byzantine fault tolerant
• Ensure all node types sync properly
• Account for network latency, dropped requests, etc....

Questions

• How to best prevent forking?
• How can we test the model to ensure that it will work on a live network?
• How scalable is the model given the number of requests that will be required?

Contest Submissions

To submit a proposal, leave a comment with a link to a Google doc.

[mrbusysky]

My idea submission: https://docs.google.com/document/d/1ygbiFq4MDIxe8tF8xxui-67IX7rdVnIMJhbDQbsiI5c/edit

[mrbusysky]

I and bucky have agreed to give the winnings away to be released via faucets. Since we merged our ideas.

The document: https://docs.google.com/document/d/10VBnGX7conPdoeAo-No1H-7Y0j5690vE-ewIJSpg7Ig