Introduction to Polygon Miden: What are your thoughts?

Zero Knowledge Polygon Miden
1

Polygon Miden is a zk optimised rollup that prioritises zk friendliness over EVM compatibility.
This post outlines the motivation behind Miden, and an overview of its design & goals.

We would LOVE for you to share your thoughts & feedback in comments below.
Dig in!

  • Polygon Labs
6 Likes
2

Good intro post, high level. keen to see the more detailed posts that will come after this one. But also keen to see how this architecture will be decentralized and become community run :slight_smile:

3 Likes
3

A Zero Knowledge Smart is a sure crowd puller .It Simplifies th3 whole Smart contract jargon i reckon users will increase by many fold .Gas fees after a 15min period seemed â…” In favour a individual choice of cost and consumption even approched equal in bothterms betweem normal speed and rapid .

4 Likes
4

I’d be careful to throw around expressions like ” exponentially faster” that sounds extremely marketing-hype-y if completely unqualified (faster than what? Exponentially, measured how?).

Looking forward to seeing what Miden zk applications look like! Avoiding redundant execution definitely is a step forward.

Another thing, not sure if Miden does that: not all tx should need to be perfectly ordered. Those that don’t touch the same state (utxos, storage, …) should be ”parallel” not just in theory but in the architecture: not blockchains but transaction DAGs. I imagine there’s some fundamental challenge in DAGs because frankly we should have them already by now if they were easy.

2 Likes
5

I have a couple of questions:

  1. Proof generation is a computationally costly operation. What if the device making it won’t be able to create one? How will this burden to generate a proof be passed for generation by chain’s provers (I’m assuming)?
  2. If there’s the proofs will be computed in parallel individually on each device, will there be some proof rejection method? For example, 2 addresses simultaneously generated a proof that they have received 1 ETH from lending pool that has only 1 ETH. Anyhow, both transactions should be ordered in a block by sequencer. Thus, the 2nd proof should be rejected even though it was generated. How will the whole procedure work?
1 Like
6

Love the designs and goals :purple_heart:
With a focus on extending Ethereum’s feature set while also providing enhanced privacy and security. If successfully implemented and widely adopted, it could have a positive impact on the blockchain industry
LFG Miden

3 Likes
8

Thanks for the feedback. We thought about decentralization from the beginning. In Miden, we try to prevent state and execution bloat. This is what our talk at DevCon was about. So in Miden, operators do not need to know the full state to verify proofs or to advance the state.

State bloat is the problem that when a blockchain is used too much, the burden on the nodes becomes too big to keep up with the state. In EVM-like systems, you need to know the full account states to advance the state. In Miden the nodes do not.

2 Likes
9

You are right, maybe we should have been more careful. I think the expression is motivated by the fact that the time it takes to verify a proof grows logarithmically with its complexity. So when the network only verifies proofs instead of creating proofs for everyone (like in other rollups), it should be “exponentially faster”. But again, I totally agree that this expression is not super clear.

Another thing, not sure if Miden does that: not all tx should need to be perfectly ordered. Those that don’t touch the same state (utxos, storage, …) should be ”parallel” not just in theory but in the architecture.

I think this is what we try to achieve. A transaction in Miden is always executed against a single account and only against this state. So they can be in parallel. We have a slightly different understanding of how we can define a transaction. And you are right, there are also transactions that need to be ordered when it comes to the public state. We will explain this in our next blog post.

2 Likes
10

Thanks for your questions @Anton_Gaev_P2P

  1. The Miden VM is optimized to be very efficient. You can try and create some proofs on your local machine here in our Playground. But users will always also have the ability to let their proofs be generated by the network’s operator (like in other zkRollups).

  2. For those transactions that touch public state it works a bit different in Miden. We will explain in our next blogpost. But in short:

  • The lending pool account needs to create a note containing this 1 ETH.
  • The creation of this note (adding to the UTXO database) is done by a transaction.
  • Only one user can prove that she has consumed that particular note.

So “generated a proof that they have received 1 ETH from lending pool that has only 1 ETH” this is not possible in Miden because transactions work differently. We will explain in our next blogpost.

2 Likes
12

that’s interesting! I’ll be waiting for the next blogpost, thanks!

13

Hi @Domi2000

Thanks for the video. Really cool, as we get closer to testnet, mainnets, etc will Miden launch as decentralized with operators outside of miden team?

I am finding that most ZK launching now are launching in a centralized format. For example Arbitrum and Optimism seems centralized.

For example Hemez was designed to be decentralized as shown here

But launched i assume under Hemez/ZKevm control (centralized) and not run by third parties (decentralized)

1 Like
14

Hi @Sheznez,

Yes I think most rollups start with training wheels attached. Also, Miden will run for the first time with a centralized operator - we need that to debug and stabilise the network.

Forward-looking, Miden is designed to be decentralized. That means operators of the Miden network do not need to know the full state to be able to verify proofs or even to advance the state. So compared to EVM-like systems, in Miden, operators can only know parts of the Account Sparse Merkle Tree, and still advance the state.

1 Like
15

Hey @Anton_Gaev_P2P here is our second post about transactions

Let me know what you think

16

Thank you for this article, it clarifies some stuff, but also raises a couple of questions:

  1. if tokens transfer in Miden is done in 2 transactions instead of 1, how can a new address without any tokens consume incoming note without having gas to pay for the transaction?
    I assume that gas can be provided by sender, as all accounts are smart-contracts, but still, should receiver somehow invoke this transaction?
    Or is it done right away without receiver’s interaction?
    Or is it done by external operator?
    In any case, the method should be passed with the transfer transaction, as there could be 2 types of transactions:
  • receiver pays
  • someone else pays

Which method does Miden use? And what happens in case of gas spikes as there is a discrepancy between note creation and note consumption if the gas to claim the note is being paid by note creator?

  1. Another question is about operators:
    Am I right that they spend gas in order to perform the state change?
    Then again raises the question about gas spikes in case of discrepancy?

  2. And the last question: am I right that transactions that pass through operators can not be reverted?

18

Hi, @Domi2000 , Thanks for sharing the Blog. I have a question after the transaction is executed it is saved in a lockbox, But What is this Lockbox? Is it a Smart Contract?

Also As I can understand that proof generation is done locally so can we make changes after generating proof? If so What will happen with the old proofs? Whether the old proofs will be changed or new proofs will be generated?

CC:- @JacksonPolygon

19

Hey @Anton_Gaev_P2P ,

Thanks for your questions.

if tokens transfer in Miden is done in 2 transactions instead of 1, how can a new address without any tokens consume incoming note without having gas to pay for the transaction?

You are right; new accounts need to be able to receive tokens without having gas. Our Gas Scheme is not fully specced out yet.

And what happens in case of gas spikes as there is a discrepancy between note creation and note consumption if the gas to claim the note is being paid by note creator?

This is an excellent question, indeed. I think we don’t know yet.

And the last question: am I right that transactions that pass through operators can not be reverted?

Transactions can never be reverted in our model. But notes - which are either produced or consumed while executing a transaction - can be consumed by the creator of the note as well. This is what we call to re-call transaction.

Or, actually, when you execute and prove a transaction locally, you could revert it by not sending the transaction proof and restoring your old state. In that sense, yes, when its done by the operator, there will not be such a possibility.

1 Like
20

I understand the high level explanation and find it intriguing. Given that this is the first of the series, I’m excited to know more.