THE INAUGURAL ZKP HACKATHON

The first ever ZKP Hackathon will take place entirely online from 2 November - 2 December 2022. Registration opens on 3 October and will remain open until the conclusion of the coding round of the competition on 2 December 2022 when entries for all submissions close.

THEME: ALICE-TO-BOB TRUST & VALIDITY

Conventionally, Bitcoin has been associated only with simple payments. This cannot be further from the truth. Bitcoin can run arbitrarily complex smart contracts that other blockchains can run, and do so more efficiently.

Zero-Knowledge Proof (ZKP) contracts are among the most sophisticated smart contracts running on a blockchain today. We have empirically demonstrated zkSNARK can run on Bitcoin natively, at a fraction of the cost compared to other blockchains. This is achieved by implementing the verifier in a high-level smart contract language called sCrypt, compiled down to Bitcoin Virtual Machine's opcodes called Script. It is similar to JavaScript in syntax and is extensively documented for ease of learning.

Not only can Bitcoin run existing ZK applications more economically than other blockchains, but it can also support ZK apps unviable on other protocols. Even though there has been a Cambrian explosion of new proof systems (e.g. Halo and Fractal), their support cannot be added without hard forks on other blockchains. They typically support only one type of ZK-proof system. For example, Ethereum only uses Groth16 on the curve BN-256. Thanks to the scalability and programmability of Bitcoin, all of them can be implemented on Bitcoin by simply implementing their verifier in an sCrypt smart contract today. Groth16 and Plonk have been implemented, more can be implemented by simply coding up its verifier using sCrypt. A newer curve BLS12-381 with better security is also currently being implemented, without any breaking changes.

ZKPs are extremely useful for Bitcoin because it allows us to create entirely new kinds of Bitcoin applications, which were deemed impossible before. It vastly expands the capability of Bitcoin applications, beyond cheap and instant microtransactions.

1. Privacy

One of the biggest challenges in storing data on chain is concerns around losing privacy. ZKP can play a major role in addressing this since it can ensure computation on certain data is correct while keeping the data confidential.

For example, incomplete information games such as mental poker, Battleship, and Wordle can be developed. Even multiplayer online (MMO) games like Dark Forest are possible.

2. Scalability

It enables Bitcoin applications to conduct computationally intensive calculations, which are generally considered cost-prohibitive on a blockchain. The calculations can be done off-chain and the result can be verified on-chain efficiently since verification is exponentially easier than rerunning the computation. The result can also be integrated into applications. For example, people have implemented Deep Neural Networks this way.

Entrants can leverage all their favourite ZK tech stacks such as Circom/SnarkJS and Zokrates but on Bitcoin.

ZK Hackathon brings together the best thinkers and builders in the space and beyond to learn about key ZK concepts and tools, the latest in zero-knowledge research and development, SNARKs, and STARKs.

Deliverables

The task for each team includes but is not limited to the following:

an application powered by ZKP and sCrypt that runs on Bitcoin.
implement other ZKP proof systems such as Marlin and Halo, and other curves other than BN-256 such as BLS12-381 and BW6-761.
optimize existing ZKP primitives: Groth16 and Plonk.

Each submission would be judged subjectively on various parameters as described in the rules of the hackathon.

COMMUNICATION

Each team or individual entrant will be invited into a group Discord chat via email.

Please note: If you are part of a team, you may also communicate with your team members directly through any medium of your choice.

THINGS TO REMEMBER

Whenever your code is working, commit it. You never know when you may encounter a bug that you get stuck on. You can always roll back and submit an earlier working version. Sometimes it can be easier to go back to a known working version and rewrite the code differently to avoid the bug.

Remember too, that your entry can address a smaller part of a bigger problem. The code component is meant to be a proof of concept. Make your entry as functional as possible, but if you need to, mock up parts of other process flows - It is acceptable to demonstrate how your solution and its core components work.

MANAGING TIME

We expect participants may have full-time jobs and will spend varying amounts of time on their entries. The competition period was chosen so that you can fit in time for the Hackathon around work and home obligations. The competition period does not reflect our expectations about the readiness or degree of completeness of your final submission.

Requirements

Upon completion of your Hackathon work, a link to the following deliverables should be submitted on Devpost:

MINIMUM REQUIREMENTS

● Code submission using a GitHub repository named after your team.

● There should be one single Git repository for your submission. If external resources are required, an install/setup script should be included.

● Supporting documentation (this may include photographs of whiteboards, diagrams, written notes, a short business case, or any other material you think relevant)

● A 5-minute (or less) video summarising your entry – e.g. a screencast demonstration of your product and a short introduction to your team, vision, goals, and business proposition.

OPTIONAL REQUIREMENTS

● A working application and/or website.

Remember, our judging teams have limited time to review numerous entry submissions. Additionally, keep in mind it can be a challenge for our judges to get your application working, especially if your development has dependencies installed that you are not aware of. If these are undocumented in your submission materials, it may be difficult to get your application to build without background knowledge of your work or the tech stack you are using.

For this reason, if you will not be running/hosting your entered application/service(s) and require us to run your submission locally, we advise you to dockerize your application to make this process easier for the judges. If you only have one image, then a Dockerfile in the repo or hosted publicly on Docker Hub is acceptable (with documentation on running the container). If you have multiple images, then a docker-compose in the repo is also acceptable.

Docker will be helpful in specific cases where we need to run your code, so if your project entails the creation of a library, for example, then Docker is not necessary.

You can learn more about Docker here: https://docs.docker.com/get-started/overview/.

External infrastructure and APIs

Can external infrastructure and APIs be used as part of your submission?

Yes.

However, if it is deployed and requires infrastructure you have written yourself during the Hackathon you will need to submit the commit hash and link to the relevant code it is running. You are not allowed as part of your submission to continue working on and improving the deployed version of your external infrastructure which will be relied upon for judging.