Zether
https://gyazo.com/f1398252529bf0d6fb8e8360135a5d70
-> anonymous payment statement
Zether: Towards Privacy in a Smart Contract World
Simple adoption of accountability to zether using PKE
Homomorphic propertyを持つElGamal encryptionで残高を計算し、その正当性をzkで証明
zkは$ \Sigma-Bulletsで暗号化送金額を検証
Front-runnning
aliceの現時点での状態に対するconfidential transactionの前にBobが先にTxを送信しAliceの状態を書き換えた場合、AliceのTxがrejectされてしまう。
Locking transfers
アリスに対するoutcoming transferが処理されるまでアカウントをロックしておき、その後アリスは自身へのincoming transferを行えるようにする。
ボブがTxを送信する時点ではアリスのアカウントはロックされていないかもしれないが、状態遷移する時点ではロックされているかもしれない問題。
anonumous transactionの場合、anonymityセットに入っている他のアカウントもロックしなければならず、これはNG.
anonymity setの中で自身のだけをロックするとプライバシー低下。
Pending transfers
全てのincoming transferはpending stateとして、kブロック高ごろのepochsごとに処理する。
kはblockchainの最新の状態とそれに対してユーザーが見るviewのgapとTxがblockchainに取り込まれるまでの時間に依存。
なので、outcoming transferがepochsをまたいで処理されない限りfront-runningは起こらない。
incoming transferを実行するときにそのアカウントへのrolling overが起き資金が使えるようになる。
Replay protection
zether accountsがethererum addressと関係なく、txにzk-proofが入っているのでethのnonceだけでは対応できない。
(zk-proofだけを抜き取って他のtxに使えたり。)
nonceをzether accountに関連付け、zk-proofを含むtx dataに対して署名
.$ \Sigma-bulletsとschnorr sigのtrustless setup
storage
acc: account table
pTransfers: pending transfer table
lastRollOver: accountsがupdateされた最新のepoch
statement
ciphertextsが正しく構成されていて、送金額を暗号化しているか
送金額がpositiveか
送金後の残高もpositiveになるか
https://gyazo.com/f2bf03180df6fec6b9867563785f3656
RollOver
last roll overにより古いepochではないかチェック
pending transfersのpTransfers[address]をacc[address]へroll over。
last roll over[address]も更新
Locking to smart contracts
アリスのアカウントを特定のスマートコントラクトSCにロックすることで、,アリスのTx送信はSCからの送信となる。proof生成はアリスが行う。ロック後はアリスから他のアカウントへの送信は拒絶される。アンロック可能。
Use cases
sealed-bid auctions
ENSなどで、デポジットにより買値の上限を明らかにしてしまう、デポジット額がロックされてしまう欠点を解決。auction contractにアカウントをロック。
Confidential payment channels
payment channelコントラクトへのデポジット額が全員に見えてしまい、チャネルを閉じる時の引出額も全てパブリックである欠点を解決。相手は互いがいくらデポジットしたか知る必要ない。
ボブのアカウントをSCにロックし、引き出し時にアリスはtxを送信しSCからキャッシュアウトし、同時にボブのアカウントもアンロック。
Stake Voting
Privacy-preserving Proof of Stake
initial lottery ticket tをアリスの公開鍵で暗号化、ステーキング量bも同じ鍵で暗号化。ランダム値vに対するrange proofでwinを証明。
ランダムオラクルとしてのハッシュ値$ v_{i, pk} = H(v||i||pk)を定義
However, gb needs to be brute-forced to compute b. We argue that this is not an issue. First, as we will see, the Zether smart contract does
not need to do this, only the users would do it. Second, users will have a good estimate of ZTH in their accounts because, typically, the transfer amount is known to the receiver. Thus, brute-force computation would occur only rarely. Third, one could represent a large range of values in terms of smaller ranges. For instance, if we want to allow amounts up to 64 bits, we could instead have 2 amounts of 32 bits each, and encrypt each one of them separately. In this paper, for simplicity, we will work with a single range, 1 to MAX, and set MAX to be 2^32 in the implementation.
sigma-bulletsはpairingsを使わないのでBN-128は適してないがsecp256k1よりはまし。
Curve25519-ristrettoが良い。
BN-128の$ G_1グループにおけるDDHを安全性仮定に。
https://gyazo.com/e6ad469c36275c385644510f8eb4e10e
https://gyazo.com/2900645a1bb0409d6ac3753587d14998
https://gyazo.com/118b34b50d2f582eab384fd279ebb38e
sigma-bullets
Σプロトコル入門
https://gyazo.com/20940c1d9bdf100c59db2ae04d954140
https://gyazo.com/e768bd4018c1700c145fbdc7ed9e9f79