Update zkapp-development-frameworks.mdx #1072
Conversation
update without decision tree image
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
|
@JanSlobodnik is attempting to deploy a commit to the o1labs Team on Vercel. A member of the Team first needs to authorize it. |
|
|
||
| ::: | ||
| Applications on Mina are called zkApps, and they come in a wide range of forms, including DeFi, games, state bridges, and more. However, due to Mina’s client execution model, the developer experience differs somewhat from that of other blockchain networks, such as Ethereum. |
There was a problem hiding this comment.
nit: "client side execution model"
| </tr> | ||
| <tr> | ||
| <td>Please note that **Protokit is in alpha**, and settlement support with reorgs is still in progress. | ||
| <p> |
| <tr> | ||
| <td>For developers coming from the Ethereum ecosystem, think of zkApps like smart contracts that can be verified off-chain. | ||
| <p> | ||
| This enables Mina to employ a client execution model, which gives Mina its scalability and privacy properties, but it can make it difficult to develop applications with concurrent users requiring a shared state. Protokit builds on top of o1js to solve these concurrency challenges. |
| - [Developer documentation](/zkapps/o1js) | ||
| - [o1js repository](https://github.com/o1-labs/o1js) | ||
| - [Discord](https://discord.gg/minaprotocol) | ||
| [o1js](https://docs.minaprotocol.com/zkapps/o1js) is the best way to author **highly-optimized ZK circuits and primitives**, but it does not provide an easy-to-use solution for managing a shared global state. |
There was a problem hiding this comment.
OffchainState provides an out-of-the box solution to this. It's worth mentioning here.
There was a problem hiding this comment.
o1js is also the only way to interfact directly with the protocol, its "not just" a tool for primitives
There was a problem hiding this comment.
I don't think we should highlight offchain state as a serious way to handle app state until it's out of the experimental namespace. I don't think we should make casual references to things in the docs until we're ready to stand behind them 100%.
| 1. Are you willing to trade off L1 censorship resistance and liveness guarantees for high throughput and low latency?* | ||
| 1. Yes - Hybrid mode | ||
| 2. No - Based mode | ||
| 2. No - o1js |
There was a problem hiding this comment.
Existence of OffchainState makes this tree a bit complicated than this. It's true that OffchainState is not scalable as base mode Protokit since it doesn't keep a db thus recreates the offchain state Merkle tree on-the-fly which creates an overhead. But, It's ready to use now (not production-ready) and worth mentioning in the tree.
|
|
||
| # zkApp Development Frameworks | ||
| Developers build zkApps with **o1js**. Developers can either use o1js directly or use o1js with **Protokit**, a framework built on top of o1js. Both options offer the full benefits of Mina’s verifiable, privacy-preserving zero knowledge proofs, but offer different tradeoffs between developer experience, performance, and decentralization. |
There was a problem hiding this comment.
Both options offer the full benefits of Mina’s verifiable, privacy-preserving zero knowledge proofs
Do they actually? Natively, afaik Protokit executes business logic on a server/"on-chain" - away from the client - this would render privacy-preserving not true in the default case
There was a problem hiding this comment.
An example from the protokit docs:
@runtimeModule()
export class Balances extends RuntimeModule<Record<string, never>> {
@state() public balances = StateMap.from(PublicKey, UInt64);
@runtimeMethod()
public mint(canMintProof: CanMintProof, amount: UInt64) {
canMintProof.verify();
this.balances.set(address, amount);
}
}Seems like using a proof input would be a valid way of preserving privacy on protokit.
|
|
||
| Protokit is built on top of o1js and simplifies the development of **zkApps with concurrent users requiring a shared state**, such as DEXes or games. Protokit is recommended for most developers. | ||
|
|
||
| O1js is the best way to write **custom zero knowledge circuits** and construct low-level primitives on Mina, such as an NFT standard or a zkML library. |
|
|
||
| Developers can build zkApps either directly with **o1js**, or with **o1js** + **Protokit**. | ||
|
|
||
| Protokit is built on top of o1js and simplifies the development of **zkApps with concurrent users requiring a shared state**, such as DEXes or games. Protokit is recommended for most developers. |
There was a problem hiding this comment.
Protokit is recommended for most developers.
is it? What's some examples when this is the case and when it isn't? If we recommend something we should clearly lay out the motivations
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>For developers coming from the Ethereum ecosystem, think of zkApps like smart contracts that can be verified off-chain. |
There was a problem hiding this comment.
zkApps aren't verified off-chain, they are proven off-chain and verified on-chain
|
|
||
|
|
||
|
|
||
| ## Protokit[](https://docs.minaprotocol.com/zkapps/zkapp-development-frameworks#protokit) |
| - [Developer documentation](/zkapps/o1js) | ||
| - [o1js repository](https://github.com/o1-labs/o1js) | ||
| - [Discord](https://discord.gg/minaprotocol) | ||
| [o1js](https://docs.minaprotocol.com/zkapps/o1js) is the best way to author **highly-optimized ZK circuits and primitives**, but it does not provide an easy-to-use solution for managing a shared global state. |
There was a problem hiding this comment.
o1js is also the only way to interfact directly with the protocol, its "not just" a tool for primitives
|
|
||
| ## [Protokit](https://protokit.dev/) | ||
| o1js can be used directly on the Mina L1, and is thus limited by the L1’s throughput and latency, but maintains strong decentralization guarantees. |
There was a problem hiding this comment.
I don't think this is a good way to phrase this. o1js is a tool that lets you build whatever on top of Mina, you can build your own app-specific rollups that would not be limited by the L1s throughput.
|
|
||
| **Still can’t decide between Protokit and o1js?** | ||
|
|
||
| This section provides a simple decision tree x`and comparison table to help zkApp developers choose which framework to use. |
|
|
||
|  | ||
|
|
||
| Are you developing a zkApp with concurrent users requiring a shared state? |
There was a problem hiding this comment.
I am not a fan of this decision tree. It ignores many details and will, imo in most cases, point developers to the wrong tools. We should educate devs on the benefits of both options, instead of assuming their use cases will just fit into one of two buckets
There was a problem hiding this comment.
Will the protokit documentation be moving to the mina protocol docs? The part about based vs. hybrid sequencing seems like it could be its own article in the protokit docs.
Overall, what message is this change intended to deliver? I think as-written it's in quite a confusing state where it pretty explicitly recommends protokit, but still makes references to o1js to be polite. If the goal is simply to say "protokit is the app development platform for Mina", this halfway approach seems too weak. If the goal is to say "o1js and protokit are two app development platforms for Mina", then I think we should remove recommendations for one or the other, and stick to the facts. I also think a factual approach will scale better when other frameworks are added.
Also, should we expect more similar PRs for docs pages as part of an effort to clean up the marketing, or is this a one-off?
update the doc with protokit and explanation for devs to know which one to select
This update is without the decision tree image, i need push access to add images.