awesome-mina-security

A curated list of Mina resources with a focus on security from Extropy.io .

Getting started

👉🏻 Mina and zkApp essentials
👉🏻 Basics of o1js
👉🏻 Deploy and interact with your first zkAPP under 10 minutes

Security aspects of zkApps

A list of security considerations to keep in mind when writing zkApps:

NOTE: links should open the related page of the docs at the correct point where the issue is being mentioned. However for unknown reason after a page is opened it quickly goes at the top. At the moment please search for the mentioned words in the page, we will try to find a solution asap to this problem

Generic issues:
🔒 Underconstrained Proofs: unproved logic can be manipulated by a malicious prover
🔒 Overriding init() is unnecessary if only super.init() is called inside without no other state initialization
🔒 Conversion between an o1js Bool and javascript boolean is always truthy
🔒 Using Provable.asProver() on inputs moves them out from the zk proof: anyone can remove the Provable block, execute the off-chain code and send a valid proof passing constraints
🔒 Writing custom low-level provable methods may add underconstrained logic
🔒 Never trust methods callers
🔒 Foreign Field Arithmetic should be used with caution
🔒 Usage of requireNothing() when retrieving On-chain Values may be dangerous
🔒 if condition is used instead of const x = Circuit.if(new Bool(foo), a, b);
🔒 Onchain merkle tree root not synced with offchain merkle root
🔒 Use on-chain values without checking them both at verification and proving time
🔒 Circumventing 01js security features should be avoided
🔒 Possible race conditions when many users read/write the state concurrently
🔒 Always extend the official TokenContract standard instead of building a custom token from scratch + mina-fungible-token repo (built on top of TokenContract)

Actions & reducers issues:
🔒 The reduce() method breaks if more than the hard-coded number (default: 32) of actions are pending
🔒 Be careful when creating Account Updates from a reducer\

Permissions related issues:
🔒 Explicitly setting Permissions to default is unnecessary if no other permissions are modified in the init() function
🔒 Permissions not locked down enough + advices for setting permissions
🔒 Calling external contracts with permissions not locked down enough
🔒 editState permission set to none
🔒 send permission set to none
🔒 if access and receive permissions are not set to none a deadlock may occur while doing concurrent state updates + safe way of doing an airdrop
🔒 smart contract interactions are limited to signature instead of proof
🔒 restrictive permissions can be circumvented if setPermissions is not set to impossible
🔒 lack of access controls
🔒 Minting unlimited tokens to himself is possile for an attacker if a custom token contract does not change access permission from none to at least proof
🔒 Setting access to impossible makes your account inaccessible: no one will ever be able to call their contract againt. It's like deleting.

Development best practices

• Do not assume that the fact that someone has to pay transaction fees doesn't have incentives to attack your zkApp
• Work with the compiler, don't try to get round the way that 01js works
• Be very aware of what is part of the proof and what is not
• Make sure that your code is not under constrained - all the necessary checks are part of the proof.
• Don't make assumptions about the caller
• Be aware of pre conditions for the update
• Restrict the permissions as much as you can.
• Be careful when calling external contracts and accounts, you need to be sure your call will succeed.
• Make sure the access control is accurate and enforced
• Have a test suite, don't just test the 'happy path'
• Put yourself in an adversarial mindset and try to break your code
• Get your code audited
• Have a plan to react to attacks
• Keep up to date, we are at a very early stage.

Resources:

Documentation:

• Official Docs
• Mina tutorials

Tools & Frameworks:

• Awesome mina tools
• zkApp Cli
• OpenMina: setting up a node from the smartphone
• zkApps official examples
• Mina Playground
• Protokit
• GraphQL queries

News:

• zkok MinaBlog
• Mina June 4 2024 hard fork announcement

Projects on Mina:

• Awesome Mina ZKApps
• zkApp list from zkok
• list from Mina Foundation
• Anomix
• Zeko
• PunkPoll
• ID-Mask
• Hakata
• ZkNoid
• ZKPassport
• Snarky.bio
• PaimaStudios
• Mina Email
• Clor.io
• zk-invoices
• zkPass
• ZKON
• zeko
• Hazook
• Lumina DEX
• SocialCap

---

Old Links

This section is a WIP

• https://www.di.ens.fr/~nitulesc/files/Survey-SNARKs.pdf
• https://arxiv.org/pdf/1906.07221.pdf
• https://medium.com/magicofc/interactive-proofs-and-zero-knowledge-b32f6c8d66c3
• https://blog.zkga.me/intro-to-zksnarks
• https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b
• https://z.cash/technology/zksnarks/
• https://masked.medium.com/the-coda-protocol-bbcb4b212b13
• https://docs.minaprotocol.com/en/zkapps/how-to-write-a-zkapp
• https://a16z.com/2022/04/15/zero-knowledge-proofs-hardware-decentralization-innovation/
• https://www.youtube.com/watch?v=bjSAf41PWWI
• https://www.youtube.com/watch?v=Zls_QlI8fn8
• https://www.youtube.com/watch?v=ByrymOorggc
• https://minaprotocol.com/blog/22kb-sized-blockchain-a-technical-reference
• https://minaprotocol.com/blog/kimchi-the-latest-update-to-minas-proof-system
• https://medium.com/minaprotocol/meet-pickles-snark-enabling-smart-contract-on-coda-protocol-7ede3b54c250
• https://minaprotocol.com/blog/what-are-zk-snarks
• https://medium.com/minaprotocol/https-and-snapps-bridging-cryptocurrency-and-the-real-world-962beb21cf2b