Decentralized Private Computation

[corpetty]

• [ ] [1] Zexe: Enabling Decentralized Private Computation
  • abstract:

    Ledger-based systems that support rich applications often suffer from two limitations. First, validatinga transaction requires re-executing the state transition that it attests to. Second, transactions not only revealwhich application had a state transition but also reveal the application’s internal state.We design, implement, and evaluateZexe, a ledger-based system where users can execute offlinecomputations and subsequently produce transactions, attesting to the correctness of these computations,that satisfy two main properties. First, transactionshide all informationabout the offline computations.Second, transactions can bevalidated in constant timeby anyone, regardless of the offline computation.The core ofZexeis a construction for a new cryptographic primitive that we introduce,decentralizedprivate computation(DPC) schemes. In order to achieve an efficient implementation of our construction, weleverage tools in the area of cryptographic proofs, including succinct zero knowledge proofs and recursiveproof composition. Overall, transactions inZexeare968bytesregardless of the offline computation, andgenerating them takes less than a minute plus a time that grows with the offline computation.We demonstrate how to useZexeto realize privacy-preserving analogues of popular applications:private decentralized exchanges for user-defined fungible assets and regulation-friendly private stablecoins

• [ ] [2] Scalable Zero Knowledge via Cycles of Elliptic Curves
  • cited multiple times, lays a lot of the cryptographic foundation for Zexe

[corpetty]

source: [1]

• record: atomic unit of Zexe, a "transaction" consumes old records and creates new ones. It has:
  • an associated address public key
  • a data payload
  • a birth predicate
  • a death predicate
  • a serial number nonce

• records nano-kernel (RNK): In addition to a data payload, a record r will now contain two user-defined functions, or more precisely two user-defined predicates (boolean functions). These are a birth predicate Φ_b, which is executed when r is created, and a death predicate Φ_d, which is executed when r is consumed. By suitably programming r’s birth and death predicates, a user fully dictates the conditions under which r can be first created and later consumed

  • This is the basis for how a record is handled by the system, thus how "validity" is enforced.

• a transaction (txn) has:
  • serial numbers of consumed records
  • commitments of the created records
  • zk-proof attesting that there exists records consistent with this information (and with the RNK)
• a txn only reveals:
  • num death predicates consumed
  • num birth predicates created
  • any data that was deliberately revealed in transaction memorandum (possibly nothing)
• construction of a txn:
• construction of a record:
• delegable DPC scheme: allowing users to delegate zk-proof construction to an untrusted machine, enabling low-resource devices to create txns.
  • done through separation of keys. proof generation keys are separate from txn validation keys so that untrusted machine can't produce a valid txn without final authorization from a key it doesn't have.
  • proof keys are modifications (randomizations) of the address public key

[corpetty]

Need to re-read section 2.5 with a fine tooth comb again.

[corpetty]

source: [1]

• data structures:
  • Records:
    • represents a unit of data
    • see above in how it is contructed
  • Transactions:
    • represents a state transition which consumes records and creates new ones
    • tuple ([sn_i]^m_1,[cm_j]^n_1, memo, *)
      • [sn_i]^m_1: serial numbers of m old records
      • [cm_j]^n_1: n new commitments
      • memo: arbitrary string associated to txn
      • *: other construction specific information
    • note that whether or not a record is a dummy is not revealed
  • Ledger:
    • where txns are posted
    • pretty light on how this operates
    • defines minimal API interface for the ledger

[corpetty]

need to look more into randomized signature schemes as building blocks

[corpetty]

[corpetty]

source: [1]:

• delegable DPC allows for txns to be created via threshold sigs and blind txns, which are txns that someone can authorize without knowing the contents for things like lottery tickets.
• all of these features are indistinguishable from one another from a 3rd party perspective.

[jer979]

I am in. Starting to process.