Redactable Blockchain in the Permissionless Setting总结
Redactable Blockchain in the Permissionless Setting
文章目录
-
-
- Redactable Blockchain in the Permissionless Setting
-
- 1.背景
-
- 1.1 前置知识
- 2.算法
-
- 2.1 六大板块
- 2.2 部署于比特币上
- 3.安全性分析
- 4.实验
-
1.背景
为什么会提出对区块链进行可编辑操作？因为欧盟出台GDPR，这就使得区块链需要进行改进，以符合欧盟的法律
其次，由于区块链无需许可，任何人都可以在区块链上写入任何信息，这里面包括了有害信息，这些有害信息有可能会跟着广播传到其他诚实用户，而Matzutt经过定量分析后不建议在上链之前进行数据审查
本文最大的贡献在于首次提出可编辑的区块链协议，这个协议采用的是变色龙hash（替代的是SHA256）以及轻量级密码学方案（hash采用的是快速幂运算，这个方案可以替换），实现了完全去中心化，可编辑区块链可以在任何一种共识机制下运行，运行效率和共识机制无关
1.1 前置知识
区块链表示为 B : = < s , x , c t r > B:=
检查区块链有效性的公式是： v a l i d a t e B l o c k D ( B ) = H ( c t r , G ( s , x ) ) < D validateBlock^{D}(B)=H(ctr, G(s, x))< D validateBlockD(B)=H(ctr,G(s,x))<D，这里面H和G都是hash函数，D代表的是区块的挖矿难度
本文还规定了一个离散的时间单位slot，这个时间单位里面的具体时间可以自行规定
此外，系统还规定了“健康的”区块链系统必须具备的两大要素：稳定性和活性，稳定性的含义是：如果某个特定的区块被认定为稳定的，那么其余用户在查询的时候都不会将其他任何与之冲突的事务报告为稳定。而活性的含义是：经过了事务认证时间之后，事务才会被汇报为”稳定“状态
对于修改区块链这件事本身，系统也提出了修改策略P：策略本质上还是个函数，以区块链C和候选区块 B ∗ B^{*} B∗作为输入，输出是一组信号： a c c e p t accept accept或者是 r e j e c t reject reject，需要注意的是，策略P本身有时间限制，用户提交修改申请后，区块需要在规定时限内进行投票，投票通过后才能上链
2.算法
本方案分为三步：1. 用户先发出编辑请求，就是索引加修改完后的候补区块 2.矿工先要对这些修改请求进行验证，区块如果有效就开始投票 3.验证申请是否被投票通过，验证通过后即可上链
图中反应的是事务在链上进行修改的过程，在候选事务池里选取 B j ∗ B^{*}_{j} Bj∗，之后事务本身并没有被更改，而对应的hash H ( B j ∗ ) H(B^{*}_{j}) H(Bj∗)已经上链了，投票通过后，事务上链，新的链接消失，老的链接继续发挥作用
后文的Bitcoin的应用方案当中包含一个editTX，这个的含义是用户发出编辑请求，这个请求
矿工收到验证请求后对状态进行检查，检查三个方面：1.前一块hash的正确性2.解决了PoW的计算问题3.修改后不会使下一个块失效，之后便可进入投票阶段
需要额外注意的是，修改事务不能直接删除整个区块
之后便是四个算法，判断有效性的算法包含六大板块
2.1 六大板块
本文讲解了六个板块：初始化、更新链条信息、待修改区块候选池、生成新区块、编辑区块链以及发出修改请求
初始化：初始化区块链C和候选区块池R
更新整链信息：调用接口进行区块链信息更新
待修改区块候选池：该方法主要用于将修改的区块放在候选池当中，需要注意的是，每次都需要检查区块的有效性，如果有效才能进入候选池当中
生成新区块：分为三个步骤：投票表决（此阶段可以将Hash区块放置于区块链上）、生成区块（ B : = < s , x , c t r , G ( s , x ) > B:=
编辑区块链：需要分成三种情况：1.投票后同意接收2.投票后拒绝接收3.投票中，第一种状态需要将区块链接到区块链上，第二种状态需要将修改后的区块 B ∗ B^{*} B∗从区块候选池中移除，第三种状态系统不会进行任何操作
发出请求：创建新的区块，并将新数据封装在区块当中，之后进行广播
本文同样定义了四大算法：区块链有效性的检查、区块有效性的检查、候选区块的检查以及发出编辑请求
区块链有效性：从第一个区块开始验证，如果区块不合规定就返回0，如果区块本身符合规定就检查当前区块的hash，符合规定，则继续检查，如果不合规定说明之前参与了修改，再检查是否符合修改规定（候选区块的有效性和策略上是否允许修改），都符合才能继续检查
区块的有效性：只需要检查是否符合关系式 H ( c t r , G ( s , x ) , y ) < D ∨ H ( c t r , y , y ) < D H(c t r, G(s, x), y)
发出编辑请求需要构建候选区块，并且将请求进行广播
2.2 部署于比特币上
本文以PoW的代表比特币为例讲解了如何把可编辑区块链部署于比特币上
对于事务本身的修改，假设区块本身存在有害数据，本方案只修改了有害部分，剩下其他部分保存完好
需要注意的是，旧有的信息并不会马上删除，而是在修改的事务上增加旧有事务的ID
需要注意的是，移除掉整个事务或者是修改事务的消费数据是会导致事务一致性发生错误的
实际上，整个区块链相较于原生的比特币协议，只是多增加了个old_merkle_root，记录旧有的Merkle Root（认为和新旧链接有极大的关联）
3.安全性分析
本文选取的三个安全指标：公共前缀、有害区块比例以及区块链增长情况
区块链增长情况指的是两条链 l 1 l_{1} l1和 l 2 l_{2} l2，这两条链的长度的差值不能超过 len ( C 2 ) − len ( C 1 ) ≥ τ ⋅ s i \operatorname{len}\left(\mathcal{C}_{2}\right)-\operatorname{len}\left(\mathcal{C}_{1}\right) \geq \tau \cdot s_{i} len(C2)−len(C1)≥τ⋅si其中， τ \tau τ代表的是增长系数
有害区块比例和敌手算力相挂钩，用 μ \mu μ表示，对于一个系统来说，需要保证投票的比例 ρ < μ \rho < \mu ρ<μ，这样做的目的是保证投票的真实性，需要注意的是，敌手有可能会让不诚实的块看起来诚实，即 ( B ⋆ ~ ) ≠ ( B ⋆ ) \left(\widetilde{B^{\star}}\right) \ne \left({B^{\star}}\right) (B⋆ )=(B⋆)，但$ H\left(\widetilde{B{\star}}\right)=H\left({B{\star}}\right)$实际上这种情况很难发生，因为本方案需要采用反碰撞hash函数（其实变色龙hash是后人的方案才开始使用，这种函数）
公共前缀部分首先提出了旧有的概念在可编辑情况下是失效的，原因是：如果一个区块在两条链都有的话，其中一条链还在投票阶段，另一条链就已经投票结束并进行修改了，这就导致了两条链公共前缀的不一致，之后作者又提出了在可编辑的情况下新的公共前缀内容
此外，作者还在最后讨论了系统容易遭受的几种攻击以及系统怎么应对这些攻击的
对于未经允许的验证，系统一来允许所有人在链上进行验证，二来保证大部分用户都是诚实的
作者为了让更多的用户进行审查，将收益和用户是否进行审查所挂钩，这样就保证了用户进行审查
为了预防DoS攻击，作者采用的方法是：在修改区块的过程中，对发动DoS攻击的矿工大幅增加费用
4.实验
本文进行了三个实验，每个实验都由50000个块组成，每个块上1000个事务，实验从三个角度进行：和原始区块链比较、修改不同数量的区块以及修改投票时长，进行比较的指标是验证时间
和原始区块链进行比较，随着区块链大小的不断增加，验证时间反而是缩小的，原因是：在一般情况下，一条链还需要检查是否有投票行为，而随着区块链的不断扩展，这种检查随着区块链的不断增加而变得无关紧要
作者假定经过修改的区块比例从2%变化到10%，实验结果是验证时间并没有很明显的变化，只是单纯的进行波动
作者在最后假设投票比例和验证时间的关系，由此前的介绍可以知道，投票需要在规定的时间内进行，于是作者就假设投票的轮数为 ℓ \ell ℓ，设置了投票比例为 ( ⌊ ℓ 2 ⌋ + 1 ) / ℓ \left(\left\lfloor\frac{\ell}{2}\right\rfloor+1\right) / \ell (⌊2ℓ⌋+1)/ℓ，之后的实验可以得到：验证时间和投票时长是一种线性关系，因为验证时间也随着投票数量的变化而变化