Proof-of-Stake Protocols for Privacy-Aware Blockchains

| 分类 论文笔记  | 标签 区块链  共识算法 

作者:Chaya Ganesh, Claudio Orlandi, Daniel Tschudi 链接:https://eprint.iacr.org/2018/1105.pdf

0x00 摘要

本文主要提出了一个服务于pos协议的隐私保护框架,具体来说,主要保护两个属性:

  • 协议参与者的身份(即公钥)
  • 协议参与者的拥有的coin数量

0x01 背景介绍

pow协议由于浪费大量的算力,所以基于pos的协议大受欢迎。然而目前的pos协议需要知道系统中所有用户的公钥和对应的持币数量,才能计算下一个区块的产生者,并且每个区块产生的奖励也必须和系统中已经存在的账户进行关联,所以在pos协议进行的过程中区块产生者的身份(公钥信息)和对应账户的余额就会直接暴露出去。基于以上两个隐私问题,本文提出了新的方案。

0x02 Model

Stake Distribution

首先一个需要解决的问题是每个账户的持币数量,如何进行加密?文中首先考虑stake是static的情况,也就是每个用户持有的coin是不变的情况,并用符号$\mathcal{F}_{Init}^{Com,SIG}$来表示,用来提供每个用户的持有stake信息,具体定义如下:

  • 参数为一个commitment算法$Com$和一个签名算法$SIG=(KeyGen,Sign,Ver)$;
  • 初始化
    • 该函数初始包含一个列表记录了所有用户的id信息$pid$和持有的stake数量$\alpha_{pid}$,对于每个$pid$计算
      • commitment: 随机选择一个值$r_{pid}$,计算$Com(\alpha_{pid},r_{pid})$
      • verification key:随机选择一个私钥$sk_{pid}$,计算$vk_{pid}=KeyGen(sk_{pid})$
  • 查询
    • 收到$(GetPrivateData,sid)$,返回$(GetPrivateData,sid,\alpha_{pid},r_{pid},sk_{pid})$
    • 收到$(GetList,sid)$,返回$\mathcal{L}={(Com(\alpha_{pid}),vk_{pid})}$

Common Reference String

协议中会使用零知识证明来证明某个用于具有产生区块的权利,用符号$\mathcal{F}_{crs}^{\mathcal{D}}$来表示零知识证明需要的common reference string,具体定义如下:

  • 取样一个CRS,$crs\gets\mathcal{D}$,其中$\mathcal{D}$表示一个分布
  • 查询
    • 收到$(SetUp, sid)$,返回$SetUp,sid,crs$

Verifiable Pseudorandom Function

协议中使用VRF函数$\mathcal{F}_{VRF}^{Com}$来提供随机性,该函数的具体定义如下:

  • 函数维护一个初始为空的表$T(\cdot,\cdot)$
  • Key Generation
    • 收到$(KeyGen,sid)$,生成$vid$并记录$(pid,vid)$,返回$(KeyGen, sid,vid)$
  • VRF Evaluation
    • 收到$(Eval,sid,vid,m)$,首先检查$(pid,vid)$是否已经记录了,如果没有那么忽略该请求,否则继续;
      • 如果$T(vid,m)$没有定义,那么随机选择$y,r\in{0,1}^{l_{VRF}}$,然后令$T(vid,m)=(y,Com(y,r),r)$
      • 返回$(Evaluated,sid,T(vid,m))$
  • VRF Verification
    • 收到$(Verify,sid,m,c)$,
      • 如果存在一个$vid$使得$T(vid,m)=(y,c,r)$那么令$f=1$,否则$f=0$
      • 返回$(Verified,sid,m,c,f)$

可以发现,该函数实际上只是将用户$pid$的消息$m$和随机性$y,r$进行了绑定。

Anonymous Broadcast

为了避免用户通过一般的网络广播消息而泄漏了身份,本文还定义了匿名广播的模型,用$\mathcal{F}_{ABC}$表示,具体定义如下:

  • 首先,所有用户都需要进行注册;

  • Send Message
    • 从某个用户收到消息$(Send,sid,m)$,将$m$添加到所有注册用户的缓冲队列中,同时将$(Send,sid,m)$发送给敌手;
  • Receive Message
    • 从某个用户收到消息$(Receive,sid)$,将该用户的缓冲队列中的所有消息返回给该用户;
  • Adversarial Influence
    • 敌手可能会控制某个用户的私钥,从而控制该用户的所有操作。

0x03 Private POS构造

上面介绍完了基本模型的定义,本小节将来介绍如何去构造一个隐私保护的POS协议。而构造一个隐私的POS协议的关键就是如何匿名的证明某一个用户具有产生区块的权利,由于这个过程具有一定的随机性,所以本文中形象的将这个过程称之为抽奖(Lottery),同时还需要保护每个用户账户的金额信息,并用符号$\mathcal{F}_{Lottery}^{LE,\varepsilon}$来表示,其中$LE$的输入为随机性和用户持有的stake数量,输出为0或1表示判断某个用户是否中奖(具有产生下一个区块的权利)了,$\varepsilon$表示一个entries集合,例如当前处于第几轮。具体的定义如下:

$\mathcal{F}_{Lottery}^{LE,\varepsilon}$

  • 函数需要维护一个列表包含用户的$pid_1,…,pid_k$和对应持有的stake数量$pid_1\alpha,…,pid_k\alpha$;同时还有一个表$T(,)$,其中$T(pid,e)$表示$pid$是否能在第$e$轮产生区块,此表格初始值为空;
  • 从用户$pid$收到消息$(Lottery,sid,e)$,
    • 如果$T(sid,e)$未定义,那么随机选一个$r$,并计算$T(pid,e)=LE(pid*\alpha;r)$
    • 返回$(Lottery,sid,e,T(pid,e))$给用户$pid$
  • 从用户$pid$收到消息$(Send,sid,e,m)$,
    • 如果$T(pid,e)=1$,那么将$(e,m)$发送给所有注册的节点,通过Anonymous broadcast
  • 从用户$pid$处收到$(Send,sid,e,m,P)$,
    • 如果$T(pid,e)=1$,那么将$(e,m)$发送给用户$P$
  • 从用户$pid$收到$(Fetch-new, sid)$,
    • 将$pid$缓冲区中所有的消息发送给$pid$,然后清空缓冲区
  • 从用户$pid$收到$(Get-stake, sid)$,
    • 返回$(Get-stake,sid,pid*\alpha)$

该函数的主要功能就是判断某个用户是否中奖了,并记录下来。但是上述过程只描述大概的步骤,具体构造整个协议文中用一个单独的协议$Protocol^{\varepsilon,LE}$来表示。令$(SetUp,Prove,Verify)$表示非交互式零知识证明中的几个算法,那么协议具体过程如下:

  • Initialization
    • 发送$(GetList,sid)$给$\mathcal{F}_{Init}^{Com,SIG}$来获取所有用户和持有的stake的commitment值,以及对应的验证密钥;
    • 发送$(SetUp,sid)$给$\mathcal{F}_{crs}^{\mathcal{D}}$来获取$crs$
    • 发送$(GetPrivateData,sid)$给$\mathcal{F}{Init}^{Com,Sig}$来获取$\alpha{pid},r_{pid},sk_{pid}$;发送$(KeyGen,sid)$给$\mathcal{F}_{VRF}^{Com}$来获取$vid$,并同时初始化一个空表格$V(\cdot)$
  • 抽奖和广播消息
    • 从环境收到$(Lottery,sid,e)$
      • 如果$e$不在$\varepsilon$中,那么忽略该消息
      • 如果$V(e)$未定义,那么
        • 发送$(Eval,sid,vid,e)$给$\mathcal{F}_{VRF}^{Com}$然后收到$(Evaluated,sid,(y,c,r))$
        • 计算$b=LE(\alpha_{pid},y)$,然后令$V(e)=(b,y,c,r)$
      • 返回$(Lottery,sid,e,b)$
    • 从环境收到$(Send,sid,e,m)$
      • 如果$V(e)=(0,…)$或者未定义,那么忽略该消息
      • 令$V(e)=(1,y,c,r)$,按如下方式计算$(e,m,\pi_{zk})$
        • 用私钥$sk_{pid}$计算$(e,m)$的签名$\sigma$
        • $\pi_{zk}$表示$Prove$通过如下语句产生的非交互式零知识证明:
      • 发送$(Send,sid,(e,m,c,\pi_{zk}))$给$\mathcal{F}_{ABC}$
    • 从环境收到$(Fetch-new,sid)$
      • 发送$(Receive,sid)$给$\mathcal{F}_{ABC}$,并将返回的消息存储为向量$\vec{m}$
      • 对于$\vec{m}$中的每一个元素$(e,m,c,\pi_{zk}) \in \vec{m}$
        • 检查$e\in \varepsilon$
        • 将$(Verify,sid,e,c)$发送给$\mathcal{F}_{VRF}^{Com}$并检查返回结果中$b$是否为1
        • 验证零知识证明$Verify(crs,\pi_{zk})=1$
        • 如果验证都通过了,那么将$(e,m,c,\pi_{zk})$添加到$\vec{o}$中
      • 返回$(Fetch-new,sid,\vec{o})$

协议的主要部分已经描述完了,其中关键在于上述的抽奖部分。首先从环境收到$(Lottery,sid,e)$表示要开启新一轮的区块产生者竞选了,那么收到此消息的用户自己判断自己是否具有产生区块的权利,也就是通过$LE$计算出结果$b$。然后第二步从环境中收到$(Send,sid,e,m)$,表示打包好了一个新的区块$m$,此时要产生一个证明,证明产生者具有合法产生区块的权利,为了不泄漏产生者的身份,这里采用了零知识证明的方法计算出$\pi_{zk}$,到此一个完整的区块就产生了,最后通过匿名广播的形式广播出去。第三步从环境中收到$(Fetch-new,sid)$,表示其它节点收到了一个新的区块,来验证区块的有效性,主要是验证其中的$\pi_{zk}$是否正确,如果验证通过了,那么就更新本地区块的状态。

0x04 思考

文中协议描述的较为抽象,并且和实际区块链的运行过程并没有对应起来,虽然在最后一章中作者给了一个应用的实例,但依然有些问题没有解决。

  • 首先,个人认为文章想要保护的信息并没有什么价值,知道一个地址中有多少币,以及知道一个地址是否具有产生区块的权利,似乎并没有什么隐藏的必要;
  • 其二就是,stake在动态变化的时候每个用户的committed的值很难去维护,如果所有全节点自己去计算,那是不是意味着所有全节点实际上都知道文章想要保存的信息。

整体感觉文章写的比较混乱,可能是还没有太仔细去看。


上一篇     下一篇