面向缓存的存储租赁（EOT版本收集）

摘要

本RSKIP提议合约应该支付存储租金，以降低存储垃圾的风险，并使存储支付更加公平。同时，本RSKIP讨论了存储租金的局限性，因为额外的复杂性和开销在某些情况下会超过收益。

动机

RSK平台的问题之一是，内存可以以低成本获取，并且永远不会释放，从而迫使所有剩余节点永久存储信息。在现实世界的商业中，几乎没有用户以一次性的非经常性付款获得对需要持续维护的财产的永久权利的例子，因此这意味着第三方需要定期维护成本。维护成本很低，但不可忽略，因为持久性数据必须存储在SSD中，以使访问成本与实际成本相匹配。区块链状态存储就是这种情况，成本乘以网络中状态副本的数量。在某些情况下，空间是免费提供的（例如，google drive空间），但这是因为空间由google用户使用的其他服务补贴。而且不能保证Google会永远提供免费空间。可以认为完整节点是利他的，因此他们愿意承担网络要求的任何存储成本。虽然这在过去可能部分适用于比特币节点，但这种利他行为可能会减少。比特币节点的数量一直在下降，而比特币用户的数量却大大增加，这意味着新用户不愿像老用户那样运行完整节点。预计区块修剪和分片技术将使用户能够提交某些部分的存储量，而不是整个区块链。但是，对新区块的验证，而不是历史存储，才是定义完整节点的要素。要验证一个区块，节点需要完整的状态，或者接收用于所有状态数据的包含证明。分片因子必须与对等方连接的诚实主机的数量成反比，因此，如果状态大小增长，而其他因素保持不变，则本地存储也必须增长。因此，原则上，用户应为消耗持久性存储支付存储租金（例如，比特币/月）。但是，尚不清楚谁应该支付这笔租金。许多合约都是众包合约的示例：由大众提供资金和使用的程序，因此它们会消耗大量内存，但没有单个用户可以承担租金负担。无论在货币努力方面，还是在事实上没有单个用户可能有动力执行这项任务（无论成本是多少）方面，都是如此。

一个精心设计的众包合约应该有一种产生收入的方法来支付存储租金。例如，每个众包合约操作都应附带以比特币支付给一个特殊的租金子帐户，众包合约在该帐户中收集所有面向租金的收入。但是，由于大多数众包合约都是不可变的，因此必须在第一天就定义这种收入收集方法，并且在该阶段尚不清楚收入模型是否可以维持内存租金。RSKIP21 深入介绍了存储租金的问题。主要问题是效率：大多数租金支付都是微支付，因此支付成本（开销）过高。另一个问题是可扩展性：收取租金的系统可能会引入新的效率低下（例如，重复的状态写入），从而干扰可扩展性计划。

已经设计了三种方法：

1. 合约每个周期使用DEPOSIT操作码支付一次租金。

2. 每次调用合约时，都会自动推迟休眠截止日期。调用会消耗gas来支付租金。租金gas的数量与未使用的增量时间（当前时间减去上次访问合约的时间）和合约持久性内存大小（代码和存储）成正比。如果调用没有提供足够的gas，则调用失败。如果调用合约且增量时间大于一年，则合约将休眠。

3. 与之前相同，但没有休眠。节点将具有一个多级缓存来存储合约数据（帐户状态，代码和存储），以便当未付租金高于较慢存储的访问成本的两倍时，数据将被移动；当访问数据时，数据将被带入最快的缓存。从一个缓存移动到另一个缓存的确切阈值将在另一个RSKIP中指定，并且不受共识规则的约束，因为这对网络是透明的。多级缓存可以由DRAM、SSD驱动器和HDD驱动器组成。

本RSKIP指定了第三种方法，因为它干扰较少，并且可以更轻松地与预构建的以太坊应用程序兼容。先前尝试实现此功能（RSKIP52）是在每次CALL之后收取租金，但是当将此方法与低租金例外结合使用时，可能会导致攻击，包括使用递归CALL来防止支付租金，方法是将持久性数据移动到辅助位置。此版本在事务处理结束后收取租金。

规范

执行事务时，每个被调用合约的地址都存储在“called”映射中。创建的每个合约都存储在“created”映射中。在事务被完全处理之后，迭代called 映射，并为每个调用收取存储租金。如果调用不更改被调用合约的存储或帐户状态（包括余额），则只有在租金高于10000 gas（稍后会介绍计算租金的公式）时才支付租金。如果被调用合约的状态被更改，则只有在租金高于1000 gas时才支付租金。这可以保护网络免于执行代价高昂的微事务。如果正确安排事务，则此RSKIP不会干扰添加并行事务执行的计划。

租金通过扩展事务来添加一个新字段“rentGas”来支付。事务消耗的总gas将等于正常消耗的gas加上消耗的rent gas。如果消耗的rent gas变得高于rentGas，则事务将被中止并回滚。在这种情况下，剩余的标准gas不会被消耗（与OOG异常相比）。但是，存储租金将被完全消耗。如果事务因为OOG异常而结束，则仅支付25%的存储租金，但是不会修改被调用合约的状态。支付25%的存储租金是为了补偿从缓存访问合约的成本。与正常的gas一样，完整的rentGas数量从源地址中扣除，然后在事务处理结束时返还剩余的数量。

每个帐户/合约都有一个新的字段lastRentPaidTime。令d为执行调用的区块的时间戳。这两个字段都以秒为单位给出。

以下伪代码说明了如何为每个被调用地址“dest”计算和支付租金。

if (d>lastRentPaidTime) {
    callRentGas =  (storageSize+codeSize+256)*(d-lastRentPaidTime)/2^21
    if ((dest modified its state) && (callRentGas>=1000)) || 
       ((dest NOT modified its state) && (callRentGas>=10000)) {
        dest.lastRentPaidTime = now
        consumeRentGas(callRentGas);
      }
}

一年有31536000秒。2^32 =4294967296。SecondsAYear/2^32= 0.00734。一个字节每年支付14.68 gas单位。一个简单的帐户（没有代码）每年支付3750 gas单位。一个简单的帐户每年消耗的租金不能超过四次。

此 callRentGas 从事务rentGas中消耗。如果此值变为负数，则事务将被回滚。如果它仍然为零或正数，则更新lastRentPaidTime的值。

每个字节的成本是每年15.625 gas。

存储大小 (storageSize) 的计算公式为 128*N，其中 N 是存储 trie 中的条目数。

如果在同一事务或同一区块中有多个调用，则只有第一个调用才会支付，因为其余的调用将具有 (d==lastRentPaidTime)

创建合约时，lastRentPaidTime 设置为未来6个月。这意味着预先支付了一些租金。

操作码EXTCODECOPY、EXTCODESIZE 和 BALANCE 操作码也必须支付租金（因此这些地址存储在 called 映射中），因为它们访问其他合约。

区块gas限制不适用于租金：以gas支付的租金数量可能高于gas限制。因此，租金是矿工的额外无上限收入来源。

扫描created 映射，并将每个合约的lastRentPaidTime 值设置为未来6个月（考虑每月30天）。

新的事务格式

修改了事务格式。当前，事务包含以下字段：

1. Nonce
2. GasPrice
3. GasLimit
4. ReceiveAddress
5. Value
6. Data
7. v
8. r
9. s

如果事务有10个或更多字段，则索引为10（从1开始）的字段将对应于字段rentGasLimit。对字段gasLimit的相同大小限制将适用于rentGasLimit。另外，rentGasLimit 从发送者的余额中全额扣除，然后返还未花费的金额。如果由于达到rentGasLimit而无法支付租金，则事务将被回滚，并且到目前为止消耗的所有gas都将被扣除（不返还），就像已执行REVERT操作码一样。

AccountState 更改

向帐户状态添加了两个字段。第一个是 flags（当前始终为零），第二个是 lastRentPaidTime。如果 lastRentPaidTime 为零，则该字段不会在 RLP 中序列化。如果 flags 为零且 lastRentPaidTime 为零，则 flags 和 lastRentPaidTime 字段都不会被序列化。

新的 Receipt 状态值

如果手动回滚事务 (REVERT)，则在事务收据中记录新的状态 (-1)。 如果由于标准 OOG 而回滚事务，则仍使用旧的空向量状态。 如果由于租金 OOG 而回滚事务，则在事务收据中记录新的状态 (-2)。

如果一个 VM 指令会同时生成一个标准的 OOG 和一个租金 OOG 异常，则报告标准的 OOG。

未来的改进

如果合约的未付租金变得高于某个非常高的阈值，则可以休眠该合约。

此外，此 RSKIP 可以与使用状态 trie 更新批处理 (COBLOP) 方法的SPV 压缩区块传播相结合。

版权

通过 CC0 放弃版权及相关权利。

• 原文链接： github.com/rsksmart/RSKI...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～