5 ms·

If anyone's interested in working with SNARKs - I'm the primary author of snarky (the OCaml SNARK DSL linked in the above website). It's being used in the devel

by ihm 8y ago

If anyone's interested in working with SNARKs - I'm the primary author of snarky (the OCaml SNARK DSL linked in the above website). It's being used in the development of Coda[0] and we're hiring. [0]: https://codaprotocol.com https://codaprotocol.com

exolymph 8y ago
Coda is awesome!
wycs 8y ago
Glad to see someone is addressing the bloat problem. Kinda sucks that every time we improve blockchain design we have to start from scratch with a new chain though.
- amenghra 8y ago
  Have you heard about merged mining? It’s when one chain recognizes the mining being done on another chain. In some way, you aren’t restarting from scratch. Also, the code powering each cryptocurencies isn’t immutable. People adopt changes; just not at the same pace as most other pieces of software.
matthewwiese 8y ago
What level of experience are you looking for in the protocol engineer role? It checks every box I'm looking for w/r/t my personal interests but I fear that since "junior" isn't in the title that I would not easily qualify.
popol12 8y ago
I just lost 10 minutes reading your whitepaper, and your claims are quite bait-clicky. Yes, your blockchain will be "instant sync", but only for light clients. Just like with any other blockchain, you still need full nodes that stores every transaction, to serve all the light clients. Light wallets are not new in this space, so I wonder what's the innovation in your proposal, apart from using bleeding edge tech like zk-SNARK.
- lavrov 8y ago
  Ordinarily, light wallets compromise on validating blocks, so that’s one benefit.
  - popol12 8y ago
    Light wallets validates blocks by checking PoW in their headers. In Bitcoin, a header is 80 byte long, that's about 40MB as of today (~500k blocks since inception). Saving 39.9 MB on light wallets isn't worth starting a new blockchain.
    - lavrov 8y ago
      No, my point is that light wallets don’t validate the content of blocks...so an attacker could create a long chain of invalid blocks and fool light clients. That’s a significant issue.
      - popol12 8y ago
        On this point, light wallets are just as protected as full node. Light wallets are able to validate blocks just from their header, thanks to the structure of a block. Indeed, all transactions in a block are commited in a merkle root hash that is included in the block header, therefore it's impossible to invent fake transactions without forging a whole new branch of blocks, from the fake block up to the last block. Just like for a full node ! Light wallets are not perfect though, potential attacks are summed up here, slide 13: https://breaking-bitcoin.com/slides/SPVSecurity.pdf https://breaking-bitcoin.com/slides/SPVSecurity.pdf Coda doesn't improve on this issues at all. Also, argument of authority: I work for a wallet provider
        lavrov 8y ago
        I’m not sure why there is a misunderstanding here, especially given that you work for a wallet provider. The attack is as described: an attacker forks, mines invalid blocks, which are caught by full nodes, since they validate the contents of blocks, but not by the light client - assume for simplicity that the client connects to the malicious node and doesn’t do anything more than calculate PoW. The SPV client trusts an invalid blockchain, fault occurs. Coda is designed precisely to avoid this problem, and any solution that requires trusting full nodes, because it provides constant time verification of all of the contents of every block.
lavrov 8y ago
Coda seems interesting, but I don’t understand how a single feature (fast light client syncing) can be enough of an advantage to launch a new chain - what prevents a new chain from incorporating recursive snarks as well as some new X in the future? Also, I think that the security of recursively computed snarks decreases as the recursion depth increases so for a state transition in a sufficiently long chain, you might only have a few bits of security, but I’m not sure what “sufficiently long” means concretely.
- dlubarov 8y ago
  > I think that the security of recursively computed snarks decreases as the recursion depth increases These proof systems are parameterized to ensure a certain soundness error, like 2^-128. So as long as certain cryptographic assumptions hold (in the case of SNARKs, the hardness of knowledge-of-exponent and commitments), it would take an attacker an expected 2^128 brute force attempts to generate an invalid proof. That should remain the same no matter how deep the recursion goes.
  - lavrov 8y ago
    Yes, I agree that the top-level SNARK will obviously have a high level of security wrt soundness, but suppose that I have a SNARK recursively computing 2^128 SNARKs, you’re claiming that the lowest level SNARK would have the same knowledge soundness guarantees? That seems incorrect given the constant size of the top-level SNARK
    - dlubarov 8y ago
      I don't quite understand where the doubt is coming from; why would recursion depth affect security?
      - lavrov 8y ago
        The security proof for SNARKs requires constant-depth compliance predicates, otherwise the proof doesn’t follow because the extractor size could blow up. I would have to read the coda whitepaper to see what their assumptions are for their security proof. I was just curious whether the equivalent of a birthday attack would be possible for some state transition if the depth was increased, since I’m not aware of a formal proof of soundness (and I heard in passing that recursion depth would affect security properties of nested snarks, but hearsay!)

by ihm 8y ago

exolymph 8y ago

Coda is awesome!

wycs 8y ago

Glad to see someone is addressing the bloat problem. Kinda sucks that every time we improve blockchain design we have to start from scratch with a new chain though.

amenghra 8y ago
Have you heard about merged mining? It’s when one chain recognizes the mining being done on another chain. In some way, you aren’t restarting from scratch. Also, the code powering each cryptocurencies isn’t immutable. People adopt changes; just not at the same pace as most other pieces of software.

matthewwiese 8y ago

What level of experience are you looking for in the protocol engineer role? It checks every box I'm looking for w/r/t my personal interests but I fear that since "junior" isn't in the title that I would not easily qualify.

popol12 8y ago

I just lost 10 minutes reading your whitepaper, and your claims are quite bait-clicky. Yes, your blockchain will be "instant sync", but only for light clients. Just like with any other blockchain, you still need full nodes that stores every transaction, to serve all the light clients. Light wallets are not new in this space, so I wonder what's the innovation in your proposal, apart from using bleeding edge tech like zk-SNARK.

lavrov 8y ago
Ordinarily, light wallets compromise on validating blocks, so that’s one benefit.
- popol12 8y ago
  Light wallets validates blocks by checking PoW in their headers. In Bitcoin, a header is 80 byte long, that's about 40MB as of today (~500k blocks since inception). Saving 39.9 MB on light wallets isn't worth starting a new blockchain.
  - lavrov 8y ago
    No, my point is that light wallets don’t validate the content of blocks...so an attacker could create a long chain of invalid blocks and fool light clients. That’s a significant issue.
    - popol12 8y ago
      On this point, light wallets are just as protected as full node. Light wallets are able to validate blocks just from their header, thanks to the structure of a block. Indeed, all transactions in a block are commited in a merkle root hash that is included in the block header, therefore it's impossible to invent fake transactions without forging a whole new branch of blocks, from the fake block up to the last block. Just like for a full node ! Light wallets are not perfect though, potential attacks are summed up here, slide 13: https://breaking-bitcoin.com/slides/SPVSecurity.pdf https://breaking-bitcoin.com/slides/SPVSecurity.pdf Coda doesn't improve on this issues at all. Also, argument of authority: I work for a wallet provider
      - lavrov 8y ago
        I’m not sure why there is a misunderstanding here, especially given that you work for a wallet provider. The attack is as described: an attacker forks, mines invalid blocks, which are caught by full nodes, since they validate the contents of blocks, but not by the light client - assume for simplicity that the client connects to the malicious node and doesn’t do anything more than calculate PoW. The SPV client trusts an invalid blockchain, fault occurs. Coda is designed precisely to avoid this problem, and any solution that requires trusting full nodes, because it provides constant time verification of all of the contents of every block.

lavrov 8y ago

Coda seems interesting, but I don’t understand how a single feature (fast light client syncing) can be enough of an advantage to launch a new chain - what prevents a new chain from incorporating recursive snarks as well as some new X in the future? Also, I think that the security of recursively computed snarks decreases as the recursion depth increases so for a state transition in a sufficiently long chain, you might only have a few bits of security, but I’m not sure what “sufficiently long” means concretely.

dlubarov 8y ago
> I think that the security of recursively computed snarks decreases as the recursion depth increases These proof systems are parameterized to ensure a certain soundness error, like 2^-128. So as long as certain cryptographic assumptions hold (in the case of SNARKs, the hardness of knowledge-of-exponent and commitments), it would take an attacker an expected 2^128 brute force attempts to generate an invalid proof. That should remain the same no matter how deep the recursion goes.
- lavrov 8y ago
  Yes, I agree that the top-level SNARK will obviously have a high level of security wrt soundness, but suppose that I have a SNARK recursively computing 2^128 SNARKs, you’re claiming that the lowest level SNARK would have the same knowledge soundness guarantees? That seems incorrect given the constant size of the top-level SNARK
  - dlubarov 8y ago
    I don't quite understand where the doubt is coming from; why would recursion depth affect security?
    - lavrov 8y ago
      The security proof for SNARKs requires constant-depth compliance predicates, otherwise the proof doesn’t follow because the extractor size could blow up. I would have to read the coda whitepaper to see what their assumptions are for their security proof. I was just curious whether the equivalent of a birthday attack would be possible for some state transition if the depth was increased, since I’m not aware of a formal proof of soundness (and I heard in passing that recursion depth would affect security properties of nested snarks, but hearsay!)