Private transactions with zk-snark protocol

[pachainti]

Summary

zero-knowledge proofs (zk-snark) protocol for private transactions on a workchain (private workchain).

Context

Support private workchains for companies similar to Hyperledger, VeChain or Corda.

Goals

• Implement zk-snark protocol.

Deliverables

• Repository with working implementation of the zk-snark protocol on workchain.
• Documentation about how to deploy a private workchain.

Definition of Done

[] Working private workchain example.

Reward

• 35000 USD equivalent in TON
• 12500 USD equivalent in TON extra if the implementation is delivered in less than 2 months

[Hiyorimi]

What's the benefit of executing this Footstep to TON blockchain?

[pachainti]

The advantages of zk-snark technology are many:

1. Creating confidential transactions. This makes it possible to create workchains in which the content of transactions is not visible via an explorer (such as Zcash, VeChain or Hyperledger, Corda). The typical use case is for companies (banks, supply chains, etc.) that want to use a blockchain to manage their processes without the content of transactions being visible, but still verifiable by third parties.
2. Compressing transactions. This makes it possible to reduce the space occupied in memory by a blockchain (such as Mina protocol). With the mass adoption of blockchain technology, it is very important to be able to contain the growth of required resources in order to achieve efficiency and decentralisation.

Since the ultimate goal of TON is to unite the Internet and the blockchain world, this is a key building block.

[Hiyorimi]

thank you for your answer, however you listed advantages of zk-snark technology, which is undoubtedly great technology.

What's the benefit of implementing zk-snarks on TON? And what's the benefit of doing it right now?

[pachainti]

TON roadmap includes the integration of workchains for Bitcoin and Ethereum. However, TON does not allow confidential/private transactions to be sent. The implementation of zk-snark technology obviates this problem by introducing a missing piece on the TON blockchain.
Suppose an entity (company, university, foundation, etc.) wants to use the TON blockchain because of its advantages in terms of scalability, the availability of a meta cloud (TON Storage) and the possibility of a decentralised website (TON Sites-DNS), but at the same time does not want to make all transactions public. It will turn to other projects.
I think the best time horizon is not now, but together with the already planned workchains (2023).

[Hiyorimi]

Are you ready to start working on this ?
What primitives do you want to implement in that case? What opcodes are you going to need ?

[pachainti]

Unfortunately, I do not have sufficient knowledge to realise it at the level of quality required for a project like TON. I am not a professional developer; however, I opened the issue because I consider the functionality an important lack for the project.

[Hiyorimi]

thank you! That's really valuable. Looking forward for a person / team capable of executing this Footstep.

[talkol]

I think this project is out of scope. Adding a zk-snark protocol is something pretty low level, I'm not sure you can do it as a smart contract layer on top of TON. This would probably require change to the core validator node in C++, which I think goes a little too deep for a footstep. Also zk-snarks require key ceremonies for all validators, which is something pretty complicated to create that goes beyond the scope.

I'm trying to see if anyone did something like this on Ethereum. I don't believe I've seen zk-snarks implemented on top of regular L1 Ethereum as Solidity contracts. They always require some other L2 blockchain to be part of the solution.

[pachainti]

I agree that adding zk-snark protocol support is a complex and low-level task. I am not sure if it is outside the prerogatives of Footsteps, however it is an important missing feature for TON.

Regarding Ethereum, there is an old proposal on EIP-1922 verifiers (inactive) and an interesting project ZoKrates that allows the use of solidity for zk-snark verification.

[talkol]

Verification of zk proofs is indeed easy to do in contracts and happens all the time on Ethereum L1. We can easily do this in TON without changing the core validator code. Preparing the proofs will happen off-chain, so the TON side will only be verifying the proof. That could work.

This doesn't go quite as far as providing private transactions, but it is something :)

This can be used to implement a mechanism such as TornadoCash. I'm not sure we want to do that on TON, because I suspect Tornado is used primarily by bad actors.

[pachainti]

Even the "pioneers" of the implementation of the zk-snark protocol, zcash, believe that it is too onerous to calculate on-chain proofs for many scenarios.
However, their implementation is open and could be used as a starting point.

[alfredonodo]

Today Polygon released a layer 2 with zkEVM (zk compatible Ethereum Virtual Machine).

[Hiyorimi]

Today Polygon released a layer 2 with zkEVM (zk compatible Ethereum Virtual Machine).

Thank you for update, Polygon team did a great job!

[alfredonodo]

An interesting comparison xk-snark vs zk-stark vs bulletproof.

[alfredonodo]

Hi all. The other day I had an idea to build a product similar to a Tornado Cash, but on a TON. In fact, this product will be some sort of a service (DAPP) that allows you to create private transactions. I have already spent several days researching and learning what a zkSNARK is. I have already started writing a smart contract and tests for this product. I thought to build this project as a separate DAPP, because I have not seen something like this live on TON yet. Today I was discussing this idea in wefunc.t.me chat and I was told that footstep issue with zkSNARKs already has been created.

So, i came here and read the correspondence above. In the correspondence above, the problem is that a very low-level solution was proposed. Im not sure that we need to create low level stuff such as c++ core code for Nodes. I propose to make a high-level service - a couple of smart contracts and a frontend app. It will be basically dapp.

I am able to do this task because I know FunC (for example i was a participant of the last FunC contest) and I think that I would be very interested in developing this product.

I think both projects should be explored as they have different goals. The goal of this proposal is to have a private workchain with integrated zk-snark protocol or one of its advancements such as the halo protocol, which does not require any trusted setup, while your goal is to have a DApp built on the masterchain as layer 2 (similar to Ethereum solutions).
In the first case you have native scalability with security and decentralisation guaranteed by TON validators, while in the second case you rely on the DApp itself. As pointed out by others, the first case is much more complex to implement and requires changes to the blockchain itself, while the second is simpler and more independent.

[alfredonodo]

Hello,
any update? It's one of the most interesting old footsteps not yet solved.
Thank you

[delovoyhomie]

Considerable time has passed, yet Bounty has not garnered resonance. A substantial amount of money is allocated for Bounty, which seems more suited for grants.
Please also prioritize focusing on meticulous issue detailing in accordance with BOUNTIES PROGRAM GUIDELINES during its creation.