Understanding Mina from a client's view

Community
1

Hi there,

I’m following blockchains on a technical level for quite some time now, and I think it’s really exciting what you did with Mina. I’m trying to understand the protocol, and even though I skimmed the whitepaper and looked at some medium posts, I would like to verify that I understand correctly:

  • The zk-SNARK size is 1kB, and the inclusion proof of my account with that zk-SNARK as basis is 22kB
  • Every time a new zk-SNARK is produced, I need to get a new inclusion proof for my account

And a more difficult question: how does this compare to something like DFinity? From my understanding, DFinity uses a unique, never-changing public key that can verify the block signature. So if I have the block-header, the signature, and the public key, I also just need the inclusion-proof for my account.

I hope I wrote correctly,

Ineiti

3 Likes
2

hey there, thanks for the question and interest in the project. Have you tried the Mina Protocol discord channel? That may be a better place to ask these questions just at the moment. Mina Protocol

3

Thanks for you answer. I don’t like discord channels for technical discussions, as it’s difficult to search it with a search engine like Google. But if there is nothing else, I’ll try there.

1 Like
4

no problems, I think once we have some working zkApps this place is going to be a lot busier. Right now all the work is being done behind the scenes at the moment, but watch this space… great to have you on board!

5

Can you link to some explanations of dfinity? To me it sounded like a normal PoS BFT based on a VRF.

Also, I think the complete proof is more like 10kb, but it’d be cool to have more accurate stats

6

Here is a somewhat technical introduction to how DFinity works:

Besides holding 100$ of ICP I’m not affiliated to them :slight_smile: But I like the idea of having a unique public key to verify transactions, instead of having to follow a list of blocks. Also because I’ve been involved in a similar effort with skipchains here: CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds | USENIX. But DFinity’s effort is even more elegant, IMO.

As far as I can tell, DFinity is not based on a VRF, but rather on threshold-signing of new blocks. Does that make sense?

1 Like
7

Thanks for sharing! It looks really interesting but a bit scary if I’m honest (although I might be misunderstanding the design).

It looks like each subnet has a threshold key that’s not generated via a DKG, but via some variant of shamir secret sharing (verified via a ZKP). This means that there’s some point in time where someone has the actual secret, and needs to be honest and dispose of it (like some toxic waste). It seems to be enough that at least one of the validator does their job honestly, which is perhaps a fine threat model, still it would have been nicer to use a DKG. I presume a DKG is too hard even with a blockchain? (I thought Shoup was working on that there)

BTW this does not preclude a PoS consensus driven by a VRF. It’s just that the VRF can be built using a threshold signature.