现在有一个协议切换现象，从理论上来说，它可以转换成很多其他有所不同的协议，从数学上来看，它就像如下情况。假设我们用于状态移往，STF（S，B）－＞S’，其中S和S’是状态，B是区块（或者说它是账户T），并且STF是状态移往函数。那么，我们可以切换为：S－＞S的六根状态（也就是说，Merkle树所包括S的32位）。
B－＞（B，W），其中W是一个“见证者”，Merkle树根的分支不会获取所有数据的价值，可以继续执行让B转入STF－＞STF’，这可以作为状态根部的输出，以及区块链上的见证者，用于见证者作为“数据库”，任何时候区块的继续执行都必须读者任何账户，存储秘钥或者其他状态数据【如果见证者没包括一些必须被催促的数据】，并且输入新的状态根部。这就是，仅有节点只不会存储状态根部，并且它不会沦为矿工的责任来包这些Merkle树根的分支（见证者），以及区块，还有仅有节点不会iTunes以及检验这些拓展的区块。对于无状态的全节点和常规的全节点来说，在网络中并存，这都是有可能的；你必须取得享有区块B的翻译成区块，附上所必须的见证者，并且在无状态节点不存在的有所不同网络协议上广播（B，W）；如果有矿工在这个无状态网络上埋区块，那么见证者可以很非常简单地除去，同时区块不会在长时间的网络上展开新的广播。假设现实协议中的见证者，最简单的方法就是把它作为RLP编码的对象，这不会被客户端解析为｛sha3（x）：x｝关键价值图谱；这个图谱然后可以很非常简单地映射到现在的以太坊中，作为“数据库”布局。
将以上这个点子布局到以太坊上的局限在于，还是必须矿工沦为存储状态的全节点。有人不会假设这样一个系统，其中账户收到方必须存储仅有状态Trie（甚至只有和他们涉及的部分），而且矿工也是无状态的，但是问题在于以太坊的状态存储入口是动态的。例如，你可以假设getcodesize（sha3（sha3（…sha3（x）…））％2**160）的合约形式，其中不会有几千个sha3’s。
这就造成转入的账户代码只有在几百万gas燃料的计算出来消耗已完成后，才有可能告诉。因此，账户收到者可以建构一个账户，其中包括新的账户的见证者，展开很多计算出来，然后最后尝试转入一个没见证者的账户。
这就和DAO硬末端漏洞一样。其中一个的解决方案，就是让账户包括这些账户的静态列表；例如EIP648，但是必须准确数字，而不是一个范围。
但是就不会产生一个问题：到时候，账户不会通过网络，账户状态，展开蔓延，从而因此准确的Merkle树分支可以作为见证者，或许不会和账户分解时的准确数据有所不同。为了解决问题这个问题，我们把见证者放到账户中的亲笔签名数据之外，并且让包括账户信息的矿工在有必须地时候，在账户前对见证者展开调整。如果矿工享有对所有创立出来的新状态树根节点，也就是说，在过去24小时，他们早已取得适当的信息来改版过去24小时公开发表账户的Merkle树分支。
这项设计有如下优势：1．矿工和全节点很久不必须存储任何状态。这不会让“较慢实时”变地十分慢（有可能只必须几秒）。2关于状态存储经济学的问题都会造成例如出租的设计，并且甚至目前简单的SSTORE开支／回款架构就不会消失，而且区块链经济学需要只专心于价格比特率和计算出来，这不会是更为更容易的问题。
3．DiskIO对于仅有节点和矿工来说，就会是个问题。DiskIO是以太坊上主要的DoS反击来源，而且甚至现在它样子是最更容易再次发生的DoS因素。4．对登录帐户列表的账户拒绝附带地减少了高度的可并行性；这在很多方面是EIP648的低配上版本。
5．对于状态存储的客户端，账户列表让客户端需要从disk预取存储数据，或许是分段的，大概率减少了DoS反击的漏洞。6．在分片区块链中，通过在分片中对客户端展开调整，从而减少安全性；客户端分片调整地越好，在拜占庭容错模型中，这个架构就更为安全性。但是，在状态存储的客户端模型中，被配对的客户端就不会iTunes新的分片中的全部状态。在无状态的客户端中，这部分成本为零，这竟然客户端可以在它们创立的每个区块间展开调整。
但是这带给一个问题：谁存储了这个状态？以太坊的关键优势就是这个平台很更容易用于，并且用户不必须关心存储私有状态这类细节。因此，为了这类框架需要很好地已完成，我们必须拷贝类似于的用户经验。
这是一个关于如何做这一点的混合建议：1．任何建构出来的新的状态树根对象都会配置文件被全节点留存3个月。这约有2．5GB的存储空间，而且这就样子“福利储存”，这是基于自愿地基础上由网络获取。我们告诉这个层次的服务当然需要基于强迫的基础来获取，因为目前的重节点结构早已是基于利他主义了。
本文关键词：开元官网平台,开元,官网,平台,技术,分析,什么,是,以太,坊无
本文来源：开元官网平台-www.softwareforbad.com
