RTDB: Hypercore test-drive

Ever TON Dev Experience Sub-Governance Finished contests
#1

Contest Proposal: RTDB: Hypercore test-drive

Short description

Test and benchmark Hypercore to understand if it is suitable as an RTDB basis.

Type

Contest

Dates

Starts: 26 October, 2020 at 01:00 PM UTC, Ends: 22 November, 2020 at 24:00 PM

Motivation

FreeTON RTDB implementation is a complicated task, so we split it into parts. At this stage, it is necessary to investigate possible solutions, which can be used as a base of RTDB.

Hypercore seems like a promising base, but 1st we should get some real-life experience with it.

Our Goals:

  • See how hypercore (+addons) works in reality.
  • Test performance, understand limitations.
  • Understand whether it is suitable as a basis for RTDB (first approximation).

General requirements:

  • Deploy, check the work, describe the features and peculiarities of:
    • hypercore (including different implementations: rust/C++/js);
    • hyperdrive;
    • hypertrie;
    • maybe other suitable hypercore based solutions.
  • Find and test other DB solutions that use Hypercore as their basis (for example, sonar).
  • Describe the capabilities and peculiarities of the p2p network.
  • Benchmarks, metrics:
    • Performance in different modes. For example:
      • read / write;
      • variate chunks size / count;
      • parallel execution;
      • etc…
    • Performance by different metrics. For example:
      • capacity;
      • response time;
      • throughput;
      • etc…
    • Check operation both locally (single node) and distributed (2 nodes, N nodes)
      • peculiarities of synchronization, guarantees of information relevance.
    • Find factors affecting performance degradations / bottlenecks.
    • Evaluation of the complexity (computational, etc.) of algorithms (O) will be a plus
      • should be based on test results (no need to read sources);
      • possible approximately, but reasonably.
    • Other (what you think should be tested).
    • Objective: to understand performance, limits, where and why there are bottlenecks.
  • Checking the compatibility of the implementations will be a plus.
  • Check stability of the software (crashes, memory leaks, etc…).
  • Other info which will help us reach the goal will be a plus.

Participants should provide:

  • Description of the work done.
  • Benchmark results (+ tables, graphs).
  • Conclusions, summary.
  • Benchmark scripts source code (should be published on GitHub/GitLab or other), so anybody can repeat your benchmarks.

Notes:

  • Reports should be clear and easy to read.
  • Source code should build / run without errors.

Evaluation criteria and winning conditions:

Proposals will be judged strictly on the merit of their accuracy in addressing all requirements and completeness. Only qualified proposals that meet all the required criteria will be considered.

Participants may include additional benchmarks, tests and information if it helps us achieve the goal of the Contest. This, if reasonable, will increase the score of submission.

Rewards:

1 place………………….……….:gem: 75’000
2 place………………….……….:gem: 60’000
3 place………….……………….:gem: 50’000
4-5 place……………………….:gem: 5’000
6-10 place………………………:gem: 1’000

Voting

  • Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 0 to 10 or can choose to reject it if it does not meet requirements, or they can choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions.
  • Duplicate, sub-par, incomplete, or inappropriate submissions will be rejected.

Jury rewards:

An amount equal to 5% of the sum total of all total tokens actually awarded to winners of this contest will be divided equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect this reward.

Procedural reminders to all contestants

  • All submissions must be accessible for the jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
  • Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.
  • All submissions must contain the contestant’s contact information, preferably a Telegram username by which jurors can verify that the submission belongs to the individual who submitted it. If not, your submission may be rejected.
  • The content published in the forum and in the provided PDF file should not differ, except for formatting, otherwise, the submission may be rejected by jurors.
  • If your submission has links to the work performed, the content of those links must have the contestant’s contact details, preferably a Telegram username so jurors can match it and verify who the work belongs to. If not, your submission may be rejected.
  • The work must be uploaded to the PDF and any links can only be used as support for the submission, but that only the work in the PDF will be judged.

Disclaimer

Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.