NAME:观点 | 关于错误性证明(Fault Proof)的沉思(一)

编者注:一般而言,我们会将FaultProof认为是与Layer-2相关的概念,是Layer-2将自己的状态报告给Layer-1时采取的模式。但在本文中,作者使用的是广义的错误性证明概念,考虑的是如何设计一种错误性证明模式,使SPV节点获得更高的安全性。

错误性证明是个极为复杂且烦人的概念,但如果你想知道我的一些心得,请耐着性子跟我一起思考吧。

-BenihimeMorgan?的河流艺术作品-

简而言之,言而简之

SPV节点非常易于运行及扩展;借助错误性证明,SPV节点可以具备和全节点相同的安全性。

我要在此引入“SPV+”模式;常规的SPV节点只需要保存区块头,而SPV+节点还需要保存每个区块中的第一笔及最后一笔交易。

“SPV+”节点必须与一个全节点建立支付通道,或是建立一个LN连接。

每验证一个区块的正确性,SPV+节点都必须向这些全节点支付小额费用;我估计这笔费用不会超过50刀/月。

后续就是添几个新操作码的事:我们需要一个链下的rangeproof,搭配类似“SegWit”的witness-commitment技术,就能方便且低成本地使用SPV+节点了。

1.背景

A.如何让比特币更像实体黄金

比特币在设计上对标的是黄金;虽然在很多方面,比特币已远胜于黄金,但是一谈到收款,问题就来了——你怎么知道钱到账了?如果以黄金等实物手段支付,有没有到帐是很简单的——就跟所有一手交钱一手交货的情形一样;但如果使用比特币支付,保障资产所有权就会变成一件很抽象的事。

对于这个问题,中本聪提出了一个完美的软件解决方案,让你能够知道钱到账没有——它就是“比特币”软件。

等会!这不又兜回原点了吗?究竟这个软件是如何运作的

谜底揭晓,比特币软件使用一种特殊的机制与其它运行软件的计算机进行同步;这个机制有点类似Dropbox,但不同之处在于,由每个文件自身保证同步性,因此不会有版本控制的问题。换言之,“得知钱已到账”和“得知你已实现同步”是一码事。

DeFi借贷平台Eco DeFi疑因私钥泄露损失约78万美元:据派盾消息,DeFi借贷平台Eco DeFi疑私钥泄露,耗尽借贷池资金,约1418 BNB,以550美元计价,损失约78万美元。[2021/12/29 8:10:29]

中本聪在白皮书中提出了两种“确认钱已到账”的方法:

运行软件,等待实现完全同步。

首先,运行一个“轻客户端”——只会策略性地对某些简单部分进行同步;然后注意是否出现“alert”。

第一种方法就是所谓的“全节点”,依靠的是?

positiveproof——你理应看到X,一旦你看到X,就知道自己已经收到钱了;第二种方法称为“SPV模式”?

1,依靠的是?

negativeproof——你本不应看到Y,一旦你看到Y,就知道自己没有收到钱。这里的Y就是白皮书中提到的“alert”,现在大家可能更常听到另一种叫法——“错误性证明”。

B.“alert”的理论支撑

我个人觉得最有意思的,反向证明机制与实际生活中的很多行为方式类似。

试想以下例子:

我们不会试图100%杜绝凶案发生,而是在凶案发生后尽全力抓捕犯人。

我们不会试图100%杜绝奸商存在,但如果真的出现奸商,我们会期待他被市场淘汰,然后由良商取而代之;如果有太多利益纠葛,我们会通过侵权法或规章制度淘汰我们不想要的商人。

我们不会试图保证每一项发布的科研成果是100%零错误的,而是最大程度地公开它们,并期待能收到批评或指正。

我们不会试图100%防止司法腐败。但是我们确实要求所有法律诉讼环节都必须记录下来,保证庭审的公正性可由公众及法律学者在事后追查。

我们不会试图变得“全知全能”。但是我们希望能够在书籍、网站中找到所需的知识技能,并希望未来会有专家让这些信息变得更准确。

通常我们会假设一切事情都没什么问题,直到出现足够严重的错误,我们再去修正。如果不这么做,现实生活中我们其实很难验证每一件事情都是100%正确的。

C.“alert”面临的理论挑战

ETH2.0质押平台StakeHound因私钥丢失损失了约7500万美元:ETH2.0质押平台StakeHound私钥丢失,其客户资金损失了约7500万美元的以太坊。StakeHound已对其加密资产托管人Fireblocks在特拉维夫法院提起诉讼。Fireblocks的首席执行官迈克尔·绍洛夫(MichaelShaulov)辩解称:“由于其ETH2.0质押基础设施效率低下,问题由StakeHound本身导致。它提供了一个完全不同的私钥,不是系统的一部分,他们必须通过指令才能使用私钥。我们试图帮助他们,但他们决定提起诉讼。”(btcmanager)[2021/6/23 0:01:14]

“alert”的问题在于,Satoshi实际上并未实现这个想法。上个月,EricLombrozo也在

推文中也提到这一点。

-EricLombrozo:“许多我聊过的顶尖技术专家都说,错误性证明实在是太难实现了,而且在最糟糕的情况下甚至是不可能的。中本聪似乎认识到了其中的难度,因此从未提出过解决方案。”-

若要实现错误性证明,主要有以下两个难点:

抗DoS攻击:比特币全节点之所以对DoS攻击有很强的抵御能力,是因为工作量证明机制所具备的不对称性——每隔10分钟才能产出一个新区块,验证这个区块却只要很短的时间。不过这是否适用于“alert”?“alert”实行PoW机制吗?谁来为服务买单?如果没有人买单,如何阻止恶意节点滥发假的“alert”来掩盖真的“alert”?

反向证明:恶意的/粗心的矿工可能会丢弃区块内的一部分数据,更极端地说,矿工可能会在根本不知晓区块里有什么的情况下,创建出一个区块!如果区块里包含错误交易,我们怎么发现呢?如果没人发现得了,又如何提醒他人呢?

针对第一个问题,我们可以采用区块链以外的方法来抵御DoS攻击,也就是支付通道。

针对第二个问题,我们可以将“审核资源”放在验证区块的特定部分——简单来说,我们可以让节点声明自己确实知道整个区块所包含的内容,然后让验证者验证该声明并为其背书。

Algorand基金会:警惕Facebook虚假账户,妥善保管私钥:Algorand基金会今日发布推特称,在 FaceBook上有一个虚假账号冒充 Algorand 基金会。 该账号声称举办了一个钱包奖励活动,并可以提供27901枚Algo的奖金。Algorand 基金会再次提醒用户,官方不会举办此类的奖金竞赛,更不会要求用户通过公共链接来完成钱包任务。[2020/4/6]

2.问题

A.SPV模式

中本聪的SPV模式(

白皮书第8章处):

比特币的区块头非常小,且易于验证,不受区块所含交易数量的影响。

可以很容易地证明,区块中包含了某个东西“X”——只要有“X”本身、区块头,以及包含两者的有效?MerkleBranch?即可。

还不太明白的人,可以参考下面的例子:

假设我们有三个区块头:headerA、headerB、headerC;每个区块头都分别包含一个hashMerkleRoot:hA、hB、hC。

交易Tx是否存在于这些区块的任意一个之中?

是的,因为h()=ht,且

h(ht,hs1)=hi1

h(hi1,hs2)=hi2

h(hi2,hs3)=hA

其中:

ht是交易Tx的哈希值;

hs1、hs2、hs3是由全节点提供的哈希值。

hi1、hi2是SPV节点计算得出的中间哈希值。

上述证明的实际含义是,有一棵以hA为根哈希值的默克尔树,它有两个分支hi2和hs3,哈希值为证,别无其它可能;hi2也只有hi1和hs2两个分支……层层递推,最终可证,ht必定存在于这棵默克尔树中,

MerkleBranch非常小,仅以log(n)的速率增长。付款者可以轻松获得/生成MerkleBranch,并伴随着交易一起发送给收款者;这种成本是可以忽略不计的。

也就是说,只要有比特币区块头,你就能知道“钱是否已经到账了”。区块头又很容易获得,因此SPV模式似乎很容易就能实现无限吞吐量。

声音 | EOS节点CryptoLion:目前有273个EOS账户失去了私钥 达到89万个EOS:据引力观察消息,EOS节点CryptoLion发表了一篇关于失去私钥的EOS账户的文章。目前有273个EOS账户失去了私钥,达到89万个EOS。那些没有映射从而没有获得EOS私钥的持币人可以通过 EOS Authority 的工具找回私钥。分别来自eosDAC、EOS Authority、Libertyblock、EOS Nation的4位成员计划开发一种为没有映射的持币人找回私钥的软件方法。[2019/1/2]

B.SPV模式的问题

问题在于,我们永远无法确定一个80字节的区块头是否真的是“比特币区块头”。

唯一的方法是检查对应区块的全部信息。如果存在一笔无效交易或双花交易”),整个区块就会被视为无效区块。

C.好消息

虽然我们无法验证一个80字节的区块头是否是比特币区块头,但是好在我们能对照当前出块难度,通过计算区块头的哈希值来验证区块头的工作量证明。

如此一来,我们就能检验矿工是否真的进行了哈希运算;可惜的是,我们还是无法确定这个区块头是否有价值。这就好比你托矿工Matthew帮你买一盒巧克力,你很容易就能验证“Matthew是否真的花了300多刀买了一盒巧克力”,但是你无法确定这些巧克力是否好吃,也无法确定它们是否真的含有巧克力成分。

D.正向/反向证明回顾

你可以吃掉盒子中的每一颗巧克力,证实每一块巧克力都很好吃,这就是“正向证明”。

或者你可以顺着以下思路进行反向证明:这盒巧克力是被包装好了的,看起来没有被动过手脚;再加上这盒巧克力有品牌背书,我国又严格执行品牌法/商标法;已经有很多人买过这个牌子的巧克力,如果质量有问题,我只要随手搜一下就能看到相关新闻/差评。

另一个采用反向证明的例子是退款承诺。假设你要买辆车,现在有三款车子,目前你对CarC最感兴趣。

若想获得正向证明,你就要把CarC开上个数千英里,随行配有一支庞大的机械工程师团队一路检查这辆汽车每个零部件,并汇报问题给你。

如果是反向证明的话:假设CarA和CarB都提供一个具有法律效力的声明“里程数不到40000英里的车子发生故障,即可退款”;但是CarC?没有这种承诺,那就反向证明了CarC的质量不行。

吴迪:量子计算机会破解私钥 毁灭区块链:IVN量子加密技术发明者吴迪表示:“量子计算机如果出现量产,那么所有数字货币的私钥将被破解,其它人会通过量子计算机算出私钥拿走你的钱。如果区块链加密算法不革新,在量子计算机时代,区块链就一定会完蛋。而量子计算机量产大概需要3-5年时间。”[2018/5/11]

要实现比特币上的错误性证明,我们需要一样东西——在区块合法的情况下出现;在区块不合法的情况下绝不出现。

在博弈论中,这被称为“信号博弈””)中的“分离均衡”。其中,错误性证明的发送者分为“诚实”和“不诚实”两类,我们正试图通过低成本的手段淘选掉不诚实的那一类。

E.我们的需求

我们需要找到一种方法能提醒我们注意?

“区块错误”。理想情况下,这种警示要来的又快又准确要在“20~30分钟内”做出响应)。

举个具体的例子,理想情形应该如下:

“Sally”因为某些原因收到了一笔比特币,对方向她展示这笔交易的信息,Sally也看到这笔交易是合法的。

Sally想要在不运行全节点的情况下知道这笔交易是否经过6个区块的确认。因此,她先是下载了所有比特币区块头,接着向全节点要了MerkleBranch。她得到了一个?MerkleBranch?,然而不幸的是(她根本不知道):里面的区块头因为某些原因是无效的……

就在此时,“Fred“必须意识到出现问题了——有一个区块存在一到多个“缺陷”。

必须通过某种激励措施促使Fred向Sally发起某种警告。

在其他正常情况下,不能让Fred有动力发起警告。

F.区块错误的类别

区块可能会出现很多种缺陷(详见?

validation.ccp,特别是“CheckBlock”)。我将它们分为四类:

“第一类”——不良交易。

“第二类”——区块数据缺失上,与Sally交易所在位置相邻的节点数据处于未知或不可见状态——这可能是人为或无意导致的)。

“第三类”——不良区块。

“第四类”——不当累加。

第一类错误

第一级错误非常好对付。Sally可以直接通过验证交易并reversingtheoutcome(sothat"false"validationreturens"true")来检验该交易的有效性,详见下文。在SPV模式下,甚至能检验nLockTime和CSV,因为Sally掌握了MerkleBranch和所有区块头。只要观察到两笔交易有相同输入,就能轻松检查出双花交易。重复的交易必然无法通过测试,因为它们必然属于双花交易。

第二类缺陷

第二类缺陷与SPV用户的相关性最强——SPV用户必须假设区块的剩余部分是完整的,但是无法检查是否真是如此。更糟糕的是,矿工可以在不核实区块内容的情况下,创建一个新的区块,他们也确实会这么做。因此,新创建出的区块内可能存在无人知晓的内容,上述假设明显是不合理的。

我将证明,从理论上来说,只要能向Sally提供有效的“区块头+MerkleBranch”,就应该存在一个完整的MerkleTree。因此,所有与区块链数据缺失有关的缺陷,本质上就是“MerkleTree相关数据缺失”的问题。可以说,这种缺陷就是未知哈希值原像的问题,又或者说的具体点,可以通过对未知哈希原像进行采样来解决这个问题。

我提出的解决方案是要求Sally除了区块头,还需要下载每一个区块的最后一条交易?2。

第三类缺陷

ClassIII第三类缺陷

第三类缺陷非常普遍,但我相信这种小毛病可以通过一种特定的简单方法解决。举例来说,区块版本如果出错,SPV节点可以直接从自己维护的区块头中获得正确的区块版本。

其他大多数的信息缺失,可以从?coinbase交易中找到;因此除了所有的区块头,SVP节点还需要保存每个区块的coinbase交易。有了这些信息,SPV节点就能知道:coinbase交易是否只出现一次且出现在正确的位置;“见证数据”是否存在及见证的内容;确定所有Withdrawal_DB和大多数Escrow_DB的正确性。

至于drivechain的Escrow_DB,主链?3上的SPV节点必须注意区块中链间交易的累加影响;解决的方法放在第四类缺陷介绍。

所以我们要增加一些开销——引入“SPV+”模式。“SPV+”节点除了要同步比特币区块头,还要同步每个区块的第一笔和最末尾交易,外加与这两笔交易相关的MerkleBranch。

旧式:同步区块链中每个区块的区块头;每收到一笔新交易就进行一次汇总。

新式:80byte/区块+/区块+两个MerkleBranch/区块;每收到一笔新交易就进行一次汇总;与其他几个节点建立支付通道。

SPV+模式会增加多少存储开销?我不确定,但假如coinbase交易约1000bytes,“最末尾交易”约280bytes,每个区块约装有5000笔交易,那么同步一个区块的开销就会提升为2192bytes/区块?

4,而不仅仅是80bytes,而且开销的增速不只是O(1),会大幅提高到O(log(n))。

按照一年约产出52596个区块,因此存储花销会变为约115MB/年,不只是4MB/年。这看似大幅增加开销,但从全局的角度来看,SPV+仍然是非常节省的方案。如果Sally想要完整的检查交易有效性,她只需要对每个区块多下载这些数据:最近六个月产出的区块,或是那些记录她收到比特币的区块,以及一些随机的检查信息。

第四类缺陷

第四类缺陷非常有意思。本文第7章会介绍如何将第四类缺陷转换成第一类缺陷,不过简单讲,要解决第四类缺陷,我要求交易哈希值不仅仅作为交易自身的保证,还要说明自己对累加指标造成的影响。举例来说,交易不仅要保证自己是“277bytes”,还要说明“加上自己之后,宿主区块大小从500809bytes增加为501086bytes”。这样一来,所有的“假交易”就能被孤立且识别出来了。也就是说,最末尾交易会提供很重要的信息。

在我深入更多技术细节之前,为了避免有人因为听不懂而掉队,我将以故事的形式再次说明“整个逻辑”。

(未完)

注1:“全节点”与“SPV节点”的区别也许并不像人们认为的那么清楚。简言之,当一个全节点在下载一个新区块时,相对于再下一个块,它自身是处于SPV模式中的。另外,再假设51%的算力在秘密运行一个新软件,该新软件默认增设区块延展数据。那么,即便别的节点想成为“全节点”,也不得不变成部分全节点、部分SPV节点的混合模式。如果那些矿工后面又把协议改回去了,去除掉了延展数据要求,那么我们就又成为了100%的全节点。但是,在这个过程中可能你都没有意识到节点形态转变了,实际上你也没办法知道。所以,只有假设协议本身固定不变的情况下,使用这些数据才有意义,当然,本文也就是这么假设的。不过,实际上,协议可能变更,也确实会变更,矿工永远可以选择运行定制化的软件。

注2:准确点说,是对所有她想用SPV模式来“完全验证”的区块都要这么做。

注3:对于自身是侧链的那些区块链,链间交易出错可以被归类为第一类错误。要得到错误警示,侧链的SPV节点需要找出两笔交易,一笔在主链上提供存款的交易,另一笔是在侧链上记录存入金额的交易。因此,侧链上的Sally必须检查主链和侧链两条链才能发现错误。

注4:单块的全部存储成本是:“区块头+第一笔交易+第二笔交易+2×(32×log2(n))”,这里的“log2(n)”指的是“根据区块中交易的数量可得的空间占用上限”。因此,在本例中,单块的存储成本是“80+1000+280+2×(32×log2(5000))”,大概是2192bytes。注意,我们不需要coinbase交易的位掩码,因为我们已经知道其确切结构,但我们可能需要知道最后一笔交易的。

原文链接:?http://www.truthcoin.info/blog/fraud-proofs/作者:?PaulSztorc翻译&校对:?IANLIU&阿剑

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:0ms0-2:833ms