Important!

Demo will be here https://plasma-winter.io, but it's only active when my laptop is on, so wait for on-stage demo!

Inspiration

  • Power of SNARKs
  • Our "The Game of SNARKs" ETH Berlin submission
  • Vitalik's post on ethresear.ch
  • ZCash's work for zkSNARKs

What it does

We've used our extended "bellman" proof system from zCash extended for BN256 curve to implement an "Update" gadget circuit. It does the following:

  • Use contract calldata to solve data availability problem resolution. Hashes it using sha256 to make public data commitment
  • Use three public inputs: old balance tree root hash, new balance tree root hash, commitment to public data
  • Internally use a witness of transaction data and signatures to:
    • Prove that sender's and recipient account exist in a tree with particular associated public key, balance and nonce
    • Check transaction signature on sender's public key, parse data, check "nonce" and "good until block" fields
    • Decrement sender's balance, increment recipient's balance, update collected fee
  • Recalculate a root hash and use it as an intermediate one for the next transaction
  • First intermediate root is the old balance tree root hash
  • Final intermediate root is enforced to be equal to new balance tree root hash
  • Internally public data is hashed using sha256 and enforced equal to commitment to public data

How we built it

  • zCash's "sapling-crypto" is a great example of how gadgets can be implemented
  • An implementation of BN256 curve for it was our previous work, it's public along with other stuff here
  • Implement the gadget using the Peddersen hash that was implemented by zCash already

Challenges we ran into

  • Rust.....
  • We were very lucky to have someone for UI

Accomplishments that we're proud of

  • It works and we've made tests, performance and transaction cost estimation

What we learned

  • Experience with Rust and large zkSNARKs implementation

What's next for Plasma Winter

  • Make "deposit" and "exit" gadgets
  • Implement a "disaster" protocol in case of disappearance of an operator (when operator stops to process user's "deposit" and "exit" requests)

Built With

Share this project:

Updates