Document status = Work In Progress
Document link = DevEx SMFT protocol STAGE 1 contest - Google Docs
Soft Majority Fault Tolerance protocol (or SMFT for short) architecture technical description.
Will leave the Catchain BFT protocol intact as of the leadership selection and consensus phases. The Thread validators will validate the block as they are now, just with the BFT threshold lowered to say 51% signatures, which will be used for preventing natural forking and slashing in case of an attack.
In addition, let’s have a protocol that samples some random nodes out of the WorkChain Validator set and requires them to validate every block (let’s call them “Verifiers”). The randomness must be calculated after the block candidate has been propagated. The protocol must be non-interactive, succinct and low latency.
Let us concentrate on the block collation phase, before the consensus, because in order for malicious validators to validate the malicious block it should be collated in the first place. If we prove that the malicious collation will be impractical, it won’t matter how many potentially malicious validators the thread has.
Instead of broadcasting the block that has been already validated, we will ask collator to broadcast the block candidate to all nodes in the WorkChain. If a collator won’t do this, the block header won’t be included into Masterchain and the Collator will be slashed for data withholding.
Before we describe how blocks are verified let’s prove that the block has indeed been broadcast. Without such proof the malicious set of actors could siphon the block only to themselves, “mining” the necessary outcome.
Let some validators be defined as Broadcast Protectors (BPs for short).
When receiving a new block broadcast from the collator, the validators calculate a set of BPs from a hash of the block and list of validators. Say, taking the Workchain Validator Set divided by some number.
Validators will send a Block Receipt — a block hash signed by a BLS signature to all BPs. When a BP collects 51% of Receipts it will broadcast a multiplied Receipts and a numbered list of validators it got receipts from. The Validators that are not sending Block Receipts over some period of time or within a particular delay must be slashed.
The MC will verify the broadcast proof message by decrypting the block hash using multiplication of pubkeys of validators which provided receipts and comparing it with the collator’s block hash. Passing the check for 51% of validators will finalize the block if no NACK messages have been received so far. Assuming there are 200 neighbors and that there are less than 50% of malicious validators, getting 50%+1 receipt guarantees that there is 2-200 probability for broadcast not to happen.
Now that we proved 51% of validators got the block, let’s choose a set of verifiers.
In order to do this let’s choose a random number and a secret that only the verifier knows. Let’s then calculate if the validator is a verifier based on those two numbers which would be random and could not be calculated by an outsider.
When receiving the block candidate broadcast, the WorkChain validators will calculate Ω from a thread ID, block candidate sequence number and hash of a masterchain block signed by a verifier private key. Calculate Hv = hash (Ω). Let N be a number of validators in WorkChain, R is a predefined parameter in a workchain’s config. Then T is a multithreading factor equal to [N/R]. If a remainder of Hv/T division = 0 then the Validator is a Verifier for a thread block.
If the Validator is a Verifier it will verify the block immediately and send the result (ACK or NACK) to all Masterchain Validators and to a certain number of validators in all other Workchains together with the hash of the block candidate and the proof of correct Verifier selection.
If a Verifier will not submit either Nack or Ack it should be slashed. In order to accommodate that we could imagine a protocol that would reveal the true verifiers after the block has been finalized. Several such schemes could be imagined where the Verifier will have to calculate its participation from some key that must be revealed in another context. Since all ACKS and NACKS are included in the masterchain block it is available publicly. The Broadcast protection receipt can include a validator signature that would reveal the key from which the Verifier has been calculated.
Now Masterchain validators will need to wait for a thread block signed by 51% of that thread consensus and broadcast proof from at least one of Broadcast Protectors. If no NACK has been received for a certain period of time (which in reality is the broadcast proof creation time), the block header will be included into the Masterchain. If at least 1 NACK message has been received, the Masterchain will issue a special verification procedure.
Specification (detailed technical description) of the proposed architecture, research regarding feasibility of 3rd party open source solutions which will be integrated in Rust nodes. It should consider time delays on every operation performed, the block finality, the traffic requirements etc. must be described, discussed and simulated when possible. Potential attacks on the protocol must be described and discussed.
Described in the Program System Specification Requirements
Submission period: 3 weeks 10/01/2022 - 31/01/2022
Voting (assessing) period: 10 days 01/02/2022 - 10/02/2022
1st place………… 90.000 TON
2nd place………… 70.000 TON
3rd place………… 40.000 TON
Overall prize pool: 200.000 TON
The minimum score to receive a reward is 4. Reject counted as zero.
Note: If the number of winning submissions is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.
The part of the reward in the amount of 20.000 TON is granted in full after the judging is completed. The remaining amount is distributed within 6 months in equal parts on a monthly basis.
The jury for the contest will consist of the invited specialists with expertise in the domain.
Each jury member will receive 10.000 TON
This sum will be awarded on the following basis:
- Detailed feedback is mandatory to collect any rewards.
- Voting for all submissions is mandatory to collect rewards.
- The votes of the jury members who did not receive the rewards for the reasons listed above will not be counted.
- Jury rewards are distributed in full upon the end of voting regardless of the long-term outcome.
- Jury members are expected to communicate with participants and answer questions about the criteria for the assessment.
- The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to ‘Abstain’.
- Jurors or 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 1 to 10 or can choose to reject it if it does not meet requirements or vote ‘Abstain’ if they feel unqualified to judge.
- Jurors must provide feedback on submissions or lose their reward.
- The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
At the beginning of the voting period, an AMA session will be appointed for participants, jurors, and everyone else. At this session, each contestant team has to present their work.
The preferable presentation language is English. The presentation time should not exceed 10-15 minutes.
If a contestant cannot present the work online, they should make a video recording and publish it on YouTube but any questions that arise should be answered.
An amount equal to 5% of the prize fund will be equally distributed amongst community members who participated in the organization of the contest:
The same percentage of the monthly reward will be received by the person(s) responsible for its distribution (vesting distribution overhead).