ZEXE
問題定義
正しい状態遷移のためにTxをre-executingする検証の必要性
Txがアプリケーション全体の状態遷移だけでなく、アプリケーションの内部状態も明らかにしてしまうこと
解決策
offline computationのサイズに依らずconstant timeでTxを誰でも検証可能に
verifier's dilemma
Txにおいてoffline computationの情報は全て隠す
data privacyだけでなく、function privacyも。
snarksベースのDPC(decentralized private computation) protocol。
2inputs records + 2 output records = 968 bytes
generating these transactions takes less than 2 minutes plus a time that grows with the offline computation (inevitably
verifier's dilemma
https://eprint.iacr.org/2015/702.pdf
birth function : record生成のため
mint mode : e.x. id 1, v_0 = 100 のtoken mint
conserve mode
death function : record消費のため
a transaxtion only contains
serial number of the consumed records
as a nullifier
commitments of the created records
in a merkle tree
zero knowledge proof
a record constists of
an address public key
a data payload
a birth predicate
a death predicate
a serial number nonce
record's address public keyに対応するsecret keyをseedとした擬似乱数関数から評価
https://gyazo.com/596b22835798a5cec46e814e62091a69
https://gyazo.com/027b507b2ae85b526e104ab4e13d8949
a piece of shared memory that is publicly revealed, called transaction memorandum
a piece of shared memory that is kept hidden, called auxiliary input
In order to produce a transaction, a user selects some previously-created records to consume, assembles some new records to create (including their payloads and predicates), and decides on other aspects of the local data such as the transaction memorandum (shared memory seen by all predicates and published on the ledger) and the auxiliary input (shared memory seen by all predicates but not published on the ledger);
Achieving privacy for user-defined functions
user-definedな関数がやりとりする強制的なルールがなく、blockchain環境では作用しなくなる。
関数が秘匿な状態だと、ある状態に対してユーザーは任意の関数を秘密に決定できてしまう。
例えば、ある状態での1ETHが「前の状態でアリスが0.3ETH持っていて、ボブが0.7ETHを送金した関数」のoutputなのか、「アリスが1ETH mintした関数」の状態なのかその関数が秘匿だとpublicに正当性を検証できない。
上記はブロックチェーンに記録するrecordsに「そのrecordsを生成した関数」も記録しておくことで解決可能。
その関数自体は暗号化しておき正当性の検証はゼロ知識証明。
しかし、これだとinter-process communication（コントラクト同士のやりとり）ができなくなる。
そのrecordsの生成が他の関数に依存することになり、privateな環境では自分が定義した関数以外はゼロ知識証明できない。
The records nano-kernle (RNK)
以下の2つのuser-defined precicates(boolean関数）をrecordに含める。
birth predicate：recordが生成されるときに実行
death prediciate：recordが消費（状態遷移）されるときに実行
これによりそれぞれの関数がそれぞれのロジックでlocal dataが正当かどうか検証できる。
local data: birthとdeathのcommon input
record's contents
transaction memorandum: shared memory
auxiliary input: shared memory that is kept hidden
other
よって、１つのトランザクションで他のrecordとやりとりできるようになる。
他の関数ではなく自分の関数で正当性を検証することが可能になるから。
Decentralized private computation (DPC)
transaction
serial numbers of the consumed records
commitments of the created records
a zero knowledge proof
コミットメントはレジャーのmerkle treeでコレクト
パスをゼロ知識証明に渡す
serial numberは重複を認めないレジャー上のリストで管理
これにより、他のユーザーのsecret keyを知らずに、他のrecordに対するrecordを生成することができる。
後述するように決定論的にserial numberは生成。
record data
address public key: address secret keyのコミットメントに対応
addressはrecordsの所有権を表し、secret keyを知らないとrecordを消費できない
data payload
birth predicate
death predicate
serial number nonce:
recordsの（コミットメント外の）のserial numberは、recordのaddress public keyに対応するsecret keyをseedとした擬似乱数関数に対してserial number nonceで評価した値。
Tx生成
レジャー上の消費する生成recordsを選択
それに対応するコミットメント、serial number、address public key、transaction memorandumなどのlocal dataをアセンブル。
ゼロ知識証明の生成しトランザクションデータに追加
recordsのsecret keyを知っているか
old recordsに対するdeath predicateとnew recordsに対するbirth predicateを満たすか
トランザクションデータは
serial numbers of old records
commitments of new records
transaction memorandum
ledeger digest
zk proof
https://gyazo.com/f1e7f242c5390d03e72e04057401a81e
https://gyazo.com/d69d67f2799feb1f1c1528582009c583
https://gyazo.com/16f9476d14ce442969ae7b804792e2a9