侵权投诉
订阅
纠错
加入自媒体

技术分析:什么是以太坊无状态客户端?

2018-08-07 10:12
来源: 巴比特

现在有一个协议转换现象,从理论上来说,它可以转换成很多其他不同的协议,从数学上来看,它就像如下情况。假设我们使用状态转移,STF(S, B) -> S’,其中S和S’是状态,B是区块(或者说它是转账T),并且STF是状态转移函数。那么,我们可以转换为:

S -> S的根状态(也就是说,Merkle树所包含S的32位)。B -> (B, W),其中W是一个“见证者”,Merkle树的分支会提供所有数据的价值,可以执行让B进入STF-> STF’,这可以作为状态根部的输入,以及区块链上的见证者,使用见证者作为“数据库”,任何时候区块的执行都需要阅读任何账户,存储秘钥或者其他状态数据【如果见证者没有包含一些需要被请求的数据】,并且输出新的状态根部。

这就是,全节点只会存储状态根部,并且它会成为矿工的责任来打包这些Merkle树的分支(见证者),以及区块,还有全节点会下载以及验证这些扩展的区块。对于无状态的全节点和常规的全节点来说,在网络中共存,这都是有可能的;你需要获得拥有区块B的翻译区块,附上所需要的见证者,并且在无状态节点存在的不同网络协议上广播(B, W);如果有矿工在这个无状态网络上挖出区块,那么见证者可以很简单地去除,同时区块会在正常的网络上进行重新广播。

假设真实协议中的见证者,最简单的方法就是把它作为RLP编码的对象,这会被客户端解析为{sha3(x): x}关键价值图谱;这个图谱然后可以很简单地嵌入到现在的以太坊中,作为“数据库”布局。

将以上这个想法布局到以太坊上的局限在于,还是需要矿工成为存储状态的全节点。有人会假设这样一个系统,其中转账发出方需要存储全状态Trie(甚至只有和他们相关的部分),而且矿工也是无状态的,但是问题在于以太坊的状态存储入口是动态的。例如,你可以假设getcodesize(sha3(sha3(…sha3(x)…)) % 2**160)的合约形式,其中会有几千个sha3’s。这就导致进入的账户代码只有在几百万gas燃料的计算消耗完成后,才可能知道。因此,转账发出者可以创造一个转账,其中包含新账户的见证者,进行很多计算,然后最后尝试进入一个没有见证者的账户。这就和DAO软分叉漏洞一样。

其中一个的解决方案,就是让转账包含这些账户的静态列表;例如EIP 648,但是需要精确数字,而不是一个范围。但是就会产生一个问题:到时候,转账会通过网络,账户状态,进行扩散,从而因此正确的Merkle树分支可以作为见证者,也许会和转账生成时的正确数据不同。为了解决这个问题,我们把见证者放在转账中的签名数据之外,并且让包含转账信息的矿工在有需要地时候,在转账前对见证者进行调整。如果矿工拥有对所有创建出来的新状态树节点,也就是说,在过去24小时,他们已经获得必要的信息来更新过去24小时公开转账的Merkle树分支。
这项设计有如下优势:

1.矿工和全节点再也不需要存储任何状态。这会让“快速同步”变地非常快(可能只需要几秒)。

2 关于状态存储经济学的问题都会导致例如租赁的设计,并且甚至目前复杂的SSTORE支出/回款架构就会消失,而且区块链经济学能够只专注于价格带宽和计算,这会是更加容易的问题。

3. Disk IO对于全节点和矿工来说,就不会是个问题。Disk IO是以太坊上主要的DoS攻击来源,而且甚至现在它好像是最容易发生的DoS因素。

4. 对指定帐户列表的转账要求附带地增加了高度的可并行性;这在很多方面是EIP 648的高配版本。

5. 对于状态存储的客户端,账户列表让客户端能够从disk预取存储数据,也许是并行的,大概率降低了DoS攻击的漏洞。

6. 在分片区块链中,通过在分片中对客户端进行调整,从而增加安全性;客户端分片调整地越快,在拜占庭容错模型中,这个架构就更加安全。但是,在状态存储的客户端模型中,被洗牌的客户端就会下载新分片中的全部状态。在无状态的客户端中,这部分成本为零,这就让客户端可以在它们创建的每个区块间进行调整。

但是这带来一个问题:谁存储了这个状态?以太坊的关键优势就是这个平台很容易使用,并且用户不需要关心存储私有状态这类细节。因此,为了这类框架能够很好地完成,我们需要复制类似的用户经验。这是一个关于如何做到这一点的混合建议:

1.任何创造出来的新的状态树对象都会默认被全节点保存3个月。这大约有2.5GB的存储空间,而且这就好像“福利储存”,这是基于自愿地基础上由网络提供。我们知道这个层次的服务当然能够基于自愿的基础来提供,因为目前的轻节点结构已经是基于利他主义了。在3个月后,客户端可以随机地忘记,以至于例如一个12个月前接触到的状态树对象,还会被25%的节点存储,而且60个月之前的对象还被5%的节点存储。客户端能够尝试使用常规的轻节点协议,来调用这些对象。

2.希望确保特定数据段的可用性客户端可以在状态信道中进行支付。客户端可以设置支付节点的通道,而且在“我放弃0.0001美元,并且默认这笔支付会永远丢失。但是,如果你之后给某个对象提供哈希H,然后我签名,之后这个0.0001美元会到你手上”这种模式下进行有条件支付。这将标志着一个可信的承诺:可能愿意为未来的对象解锁那些资金,档案节点可以进入数以百万计的这样的安排,等待数据请求出现,并成为收入流。

3.我们期望DAPP开发人员能够让他们的用户来随机存储一部分的存储秘钥,在浏览器本地存储中存储与它们的DAPP相关的部分存储密钥。这甚至可以故意在Web3API中很容易做到。

事实上,我们希望能够知道“档案节点”的数量,可以永远存储任何事物,并且持续足够高来服务网络,直到在分片引入之后,整个状态大小超过 1-10兆字节,所以以上所说的可能甚至都不需要。

声明: 本文系OFweek根据授权转载自其它媒体或授权刊载,目的在于信息传递,并不代表本站赞同其观点和对其真实性负责,如有新闻稿件和图片作品的内容、版权以及其它问题的,请联系我们。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

物联网 猎头职位 更多
扫码关注公众号
OFweek物联网
获取更多精彩内容
文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号