Prolongation of the RTDB: Hypercore test-drive contest
Test and benchmark Hypercore to understand if it is suitable as an RTDB basis.
This is the same contest “# 3 RTDB: Hypercore test-drive”, which was announced on 10/26/2020 and is completely its continuation. All requirements and conditions remain the same.
Starts: 21 November, 2020 at 01:00 PM UTC, Ends: 29 November, 2020 at 24:00 PM
The reason for the contest prolongation is lack of submissions.
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.
- See how hypercore (+addons) works in reality.
- Test performance, understand limitations.
- Understand whether it is suitable as a basis for RTDB (first approximation).
- Deploy, check the work, describe the features and peculiarities of:
- hypercore (including different implementations: rust/C++/js);
- 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;
- Performance by different metrics. For example:
- response time;
- 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.
- 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.
1 place………………….………. 75’000
2 place………………….………. 60’000
3 place………….………………. 50’000
4-5 place………………………. 5’000
6-10 place……………………… 1’000
- 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.
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.
Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.