在起始时间(T_{START})，(operator)开始一个其实状态(S_{START} = {i: (KEY=K_i, action = PHI)}, i in 1...n).

　　在起始时间(T_{start})和结束时间(T_{END})之间，任何注册的参与者可以向R发送消息，消息用参与者自己的私钥(k)加密。有两种消息：

　　约定行为: 例如投票。参与者需要发送加密过的消息 (enc(msg = (i, SIGN(msg = action, KEY = k_i)), pubKEY = K_omega)), 其中(k_i)是这个参与者当前的私钥，(i)是参与者在(R)中的id

　　更新密钥: 参与者需要发送加密过的消息(enc(msg = (i, sign(msg = NewK_i, key = k_i)), pubkey = K_omega)), 其中(NewK_i)是参与者要变更的公钥, (k_i)是这个参与者当前的私钥

　　这时，操作员的工作是按照消息上链的先后顺序处理每一个消息。具体的处理过程：

　　使用操作员私钥解密消息。如果解密失败，或者解密对应的信息无法解码成为以上的两类信息，则直接跳过这条信息

　　使用(state[i].key)验证消息的签名

　　如果解码后的消息是约定的行为((action))，那么设置(state[i] = action), 如果解码后的消息是一个新的公钥，那么设置(state[i].key = NewK_i)

　　在(T_{end})之后，操作员必须公布输出状态 (M(state[1].action, ... , state[n].action)), 同时给出一个ZK-SNARK，证明这个输出是正确的结果。

　　假设一个参与者想要证明他做过什么，例如做过(action) (A)，他可以引用一个链上的交易(enc(msg = (i, sign(msg = A, key = k_i)), pubkey = K_omega))，并且提供一个零知识证明，验证这笔交易的确是包含(A)的加密信息。但是，他无法证明他没有发出别的交易，例如他可能发出过一笔更早的交易，把公钥换成了一个新的(NewK_i)，因此前面的证明也就变得没有意义了，因为如果他更换过密钥的话，他可能已经做了别的动作。

　　参与者还可能把私钥给其他人，但是这样做的话那个人拿到私钥后就可以立即试图修改密钥。这样的话 1) 有50%的成功率，2) 会导致拿到密钥的人直接拿走之前stake的存款。

　　接收方在可信硬件环境中，或者接收方在可信多签的情况下，卖出私钥

　　原有的私钥在一个可信的硬件环境中的攻击，这个环境可以防止私钥变更为任何攻击者们不事先知道的私钥

　　第一种情况，可以通过特别设计的复杂签名机制，而这种设计对可信硬件和多签不友好。不过这种设计需要确保验证函数对ZKP友好。

　　第二种情况可以通过“面对面零知识证明”解决，例如，参与者可以把私钥拆解为(x + y = k_i)，公布(X = x*G) 和 (Y = y*G), 并且给验证者展示两个信封，分别包含(x)和(y); 验证者打开一个，检查公布的(Y)是正确的，然后检查(X + Y = K_i)。 (责任编辑：admin)