The Succinct Prover Node and Mina Bridge Node

As previously mentioned, Pulsar requires a so-called settlement process on Mina to provide its succinctness property. However, this also means that the settlement should be performed by someone, which is a problem in most settings: If we authorize only a single authority to generate proofs, then the censorship resistance decreases. On the other hand, having a distributed prover and settlement network on Pulsar is engineeringly challenging, and in most scenarios not practical.

Pulsar solves this problem by introducing a 1 of N trust assumption model for its prover node architecture. All Pulsar blocks contain required information (such as an additional signature scheme on Poseidon to improve proof generation times) to succinctly prove and settle Pulsar’s state on Mina. Then, anyone (in the real sense, not a pre-decided set) can read and use this information to perform the settlement of Pulsar. In the architecture, this party is named as the Prover Node.

There are a few properties of the Prover Node that makes this picture fully decentralized:

• The Prover Node has a true 1 of N trust model. All information required is always available and anyone can choose to generate proofs.
• The hardware requirements of the prover node are very light. Specifically, a machine that is lighter than an average Cosmos validator can easily track and prove the entire Pulsar chain. This is possible thanks to the efficient zk-SNARK aggregation scheme used, named as Pickles.
• Prover is incentivized by the network. As with any Cosmos chain, a share of all income on Pulsar goes to the chain’s pool. Then, the prover node has the right to claim rewards from this pool based on the amount of work it has contributed to.

These three points make running a prover node accessible, easy and profitable for any party. As Pulsar needs only a single operator to perform to work properly, this solves the problem perfectly.

Another important part of the Pulsar network is the Mina Bridge Node, which is the party who is responsible for bridging TXs happening on Mina and Pulsar to each other. This party is not involved in the succinct proof generation, but important for MINA token and Mina zkApps to be accessible on the Pulsar environment.

The Bridge Node has a very similar design to the Prover, again with a 1 of N trust assumption. Here, the problem is a bit more subtle, since bridging between long and instant hard finality chains requires waiting for the consensus between each step. Pulsar utilizes Mina’s own data availability layer named as Actions to enable this logic.

Here, we skip some important details of both Prover and Bridge node for the reader’s sake. More details on both can be found in their implementation documents on GitHub.