cpp-ton VS readme

=nil; Foundation, as an initial member of the Free TON community developed an upgraded version of the TON Virtual Machine, which includes cryptographic primitives required for usage of zero-knowledge proof verification within virtualized applications. =nil; Foundation also prepared C++ (https://github.com/nilfoundation/cpp-ton) and Rust (https://github.com/nilfoundation/rust-ton) ZK proof verification instruction-enhanced TON protocol implementations

Apart from uploading a submission, a code should be submitted in accordance with GitHub - freeton-org/readme and deployed either to https://main.ton.dev (https://ton.live) (in case the protocol gets upgraded) either to https://net.freeton.nil.foundation (https://nil.ton.live or https://live.freeton.nil.foundation).

Apart from uploading a submission, a code should be submitted in accordance with GitHub - freeton-org/readme 3 .

Must be a correctly functioning FreeTON virtualized application deployed either to https://main.ton.dev (https://ton.live) or to https://net.freeton.nil.foundation(https://nil.ton.live or to https://live.freeton.nil.foundation) Must Involve VERGRTH16 TVM instruction usage Must ensure the bulletin maintains its integrity Must ensure the ballot box is a non-malleable one Must ensure that the ballot guarantees privacy of the voting message while also guaranteeing that the voter cannot reproduce their vote Must allow the voter to verify the inclusion of their vote, and also ensure that others cannot coerce the voter to create a false ballot The ballot must only be generated for eligible voters Must ensure that voting results uniquely correspond to the ballots in the public board Must ensure that ballots do not reveal voter identity to any entities, even authorities Must ensure that ballots are unique to only the individual voting and there is no possibility for proxy votes Must contain the following actor roles: ○ Voter. ○ Verifier. ○ Ballot Issuer Must contain definitions for the following items: ○ Ballot. Required not to disclose the Voter's decision until the Ballot Issuer decides to. ○ Voter Registry. Proves a particular Voter is eligible to vote Must contain a Ballot Issuer Voter registration procedure: ○ Voter generates some public identifier. ○ Voter submits the public identifier to the Ballot Issuer. ○ Ballot Issuer introduces the Voter's identifier to the Voter Registry Additional requirements Fraudulent ballot generation complexity should be no less than EdDSA over Ed25519 brute force complexity (not an extremely formal requirement, but it is okay since the public voter identifier could be, for example, a EdDSA public key) Voting results disclosure should be not possible until the voting is ended. Evaluation criteria and winning conditions Apart from uploading a submission, a code should be submitted in accordance with https://github.com/freeton-org/readme and deployed either to https://main.ton.dev (https://ton.live) or to https://net.freeton.nil.foundation (https://nil.ton.live or https://live.freeton.nil.foundation) Each contestant should present their solution at a convenient time agreed upon in advance with DevEx Sub-governance members. A solution should include tests with clear instructions If a test does not cover some scenarios, then jurors can develop their own tests; however, if the burden falls on the jurors, the contest submissions scores should lose some points The solution should have an open source license The solution should contain at least a draft of the architecture description which is implied to contain following parts: ○ In-TVM part. Proof verification part. This part is supposed to be done with VERGRTH16 instruction usage and executed within the TVM. ○ Native part. Circuit definition. Proof generator