Stellar的Soroban智能合约平台:链上存储的独特架构
Stellar的Soroban智能合约平台在链上存储方面采取了与大多数区块链环境截然不同的策略。该平台并非允许账本状态无限增长,而是要求每个合约条目支付租金以维持其活跃状态,其计时单位是账本而非实际时间。
三层架构,三种结局
所有合约数据都必须支付租金,才能在账本上保持特定的生存时间(TTL)。TTL指的是从当前账本到数据仍可被访问的最后一个账本之间的账本数量。
Soroban将存储划分为三个不同的层级:临时存储、持久存储和实例存储。当TTL到期时,这三个层级的行为截然不同。当TTL归零时,所有合约数据都会被自动归档,但临时条目会被永久从账本中删除。持久数据和实例数据会被移至归档区并可恢复,而临时数据则永久消失。将用户余额等长期关键数据存储在临时存储中,当条目的TTL归零时,将导致不可逆的状态丢失。
设计背后的逻辑
这一模式背后的逻辑很简单。状态膨胀指的是链上状态持续且无限制地增长。如果不加控制,随着合约数据在账本上不断累积,状态同步和交易执行的性能会下降,同时节点需要更多内存和更快的存储设备才能跟上,从而推动网络走向中心化。租金费率取决于条目在账本上的存活时间及其大小。与交易费一样,租金会进入费用池,该池目前处于锁定状态,只能通过验证者批准的协议变更才能解锁。
Protocol 23实现自动恢复
Protocol 23引入了通过InvokeHostFunctionOp自动恢复已归档Soroban条目的功能。在Protocol 23之前,开发者必须显式调用恢复操作才能将已归档的状态重新投入使用。现在,每当执行InvokeHostFunctionOp时,网络会自动检查足迹,并在合约执行前恢复任何所需的已归档条目。在大多数情况下,运行模拟或预检会发现过期的条目并将其包含在足迹中。正在恢复的归档条目仍被视为基于磁盘的数据,租金、写入和读取费用仍然适用。在边缘情况下,例如自动恢复会导致交易过大而超出网络限制,或者合约开发者希望确保自己支付恢复费用而非让用户承担时,仍可使用手动的RestoreFootprintOp。
这一设计体现了Stellar在保持Soroban可扩展性的同时,不牺牲开发者灵活性的更广泛努力,让构建者能够精确控制链上数据的存活时间以及数据失效时的处理方式。
XLM

交易所
交易所排行榜
24小时成交排行榜
人气排行榜
交易所比特币余额
交易所资产透明度证明
去中心化交易所
资金费率
资金费率热力图
爆仓数据
清算最大痛点
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
ETF追踪
索拉纳ETF
瑞波币ETF
香港ETF
比特币持币公司
加密资产反转
以太坊储备
HyperLiquid钱包分析
Hyperliquid鲸鱼监控
大额转账
链上异动
比特币回报率
稳定币市值
期权分析
新闻
文章
财经日历
专题
钱包
合约计算器
账号安全
资讯收藏
自选币种
我的关注