以太坊无状态客户端是什么意思？有什么解决方案？

现在有一个协议转换现象，从理论上来说，它可以转换成很多其他不同的协议，从数学上来看，它就像如下情况。假设我们使用状态转移，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兆字节，所以以上所说的可能甚至都不需要。