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

发文时比特币价格 ￥47567.45

原文：https://ethresear.ch/t/the-stateless-client-concept/172 作者：vbuterin 编译：nuszjj 稿源（译）：巴比特资讯（http://www.8btc.com/t/the-stateless-client-concept/172） 版权声明： [


](http://creativecommons.org/licenses/by-nc-sa/3.0/cn/) 作者保留权利。文章为作者独立观点，不代表巴比特立场。