用于账户引导的网络 RAM 捐赠资金

摘要

一个网络所有的账户（ram.vaulta）持有从现有网络 RAM 持仓中筹集的 RAM 捐赠资金，并允许获批的创建者向新创建的账户赠送 RAM。创建者可以免费或收费方式为新用户开通账户，而无需自行承担 RAM 成本，通过使用网络 RAM（而非出售）来支持创建者的可持续运营。被赠送的 RAM 永久性地从 RAM 市场中隔离：接收方既不能出售也不能转让，唯一的退出方式是返还给赠送账户。本提案仅涉及系统的创建：计划启动时没有任何已注册的创建者，每个创建者此后通过各自独立的 15/21 BP MSIG 获得准入。

理由

• 新用户引导：账户创建成本是将新用户引入 Vaulta 的一大障碍。网络持有大量闲置 RAM（例如仅 fund.wram 一个账户就持有约 42.08 GiB 闲置 RAM，即 ram_quota 45,181,400,197 字节，其中已用 3,120 字节，截至 2026-08-08），可以用于创建账户。
• 创建者资金：注册为创建者的引导服务可以出售账户创建服务并保留 100% 的收益。网络本身不直接支付任何费用，其回报是用户增长。由于 RAM 成本由捐赠资金覆盖，出售价格即为创建者的利润。
• 市场中立性：该计划使用 giftram 机制，因此捐赠的 RAM 永远无法通过接收方重新进入 Bancor 资金池。该计划在不出售 RAM 的前提下将 RAM 用于增长。
• 自我交易受限，但并非零利润：被赠送的 RAM 无论创建者还是接收方都无法转卖回 Bancor 资金池，因此大规模创建账户无法转化为代币利润。但它仍可用作存储空间：创建者可以将每日额度导向自己控制的账户，积累由网络承担成本的免费状态存储，其规模按每个创建者的每日额度封顶，且一旦 RAM 被占用便不可逆转。额度限制的是这种消耗的速度，而非使该 RAM 变得毫无价值。

机制

账户与权限

• ram.vaulta 通过 BP MSIG（15/21）创建，遵循与其他 *.vaulta 账户相同的模式（参见 VP-0002）。
• owner/active 权限由网络治理持有。active 包含 ram.vaulta@eosio.code，因此合约可以以自身权限发送内联 giftram。
• 创建者不出现在账户的原生权限中，而是合约注册表中的记录行，通过管理操作由 MSIG 管理。

合约接口

上表中的字段名即为部署后 ABI 的实际字段名。注册表行内容：创建者账户、每日额度（字节）、当前窗口已使用字节数、窗口起始时间。没有单笔赠送上限；每日额度限制总支出，创建者自行决定每个账户的赠送量。每次赠送从额度中扣除的字节数为赠送字节加上赠送账户就每个受赠者被计费的 136 字节 giftedram 行开销（已在 Vaulta 主网交易 f2c6200c1add5ffc74837bcae1731ff5a66e259376eee6a4d4d7580f044a0b4c 中确认：一笔 3,000 字节的赠送恰好向赠送方计费 136 字节的行开销；Jungle 4 测试中同一常数表现为 4,000 + 136 = 4,136），因此额度限制的是实际的捐赠资金消耗，而不仅仅是名义上的赠送规模。

额度窗口的语义决定了滥用计算的上界，因此在此精确说明：

• 24 小时窗口是惰性滑动窗口：它在重置后的第一笔赠送时开始，并在至少 24 小时后的第一笔赠送时重置，而非按固定的日界重置。因此创建者可以在一个窗口的末尾用满全部额度，并在窗口滚动后立即再用满一次，短期最坏情况下的突发量约为每日额度的 2 倍。
• 不存在跨创建者的全局上限。总的最坏消耗速率是所有已注册创建者每日额度之和，且由于新增创建者和提高额度都是 15/21 操作，这一数值只会在 BP 批准时增长。
• 移除创建者后重新注册会重置其当前窗口的已用字节数；setquota 只调整额度，不重置用量。

默认额度

新获准创建者的默认每日额度为 1 MB/天，按每个约 3 KB 的小型账户加上每笔 136 字节开销计算，约合每天 300 个账户。该数值是暂定的：应在启动前后通过分析活跃创建者账户（例如 gm）的实际创建量加以调整，且任何调整本身也是一项 15/21 的 setquota 决定。

成为创建者

计划启动时没有任何已注册的创建者，准入要求刻意保持最简：成为创建者只需要一件事，即一个通过的、携带 addcreator(creator, daily_quota_bytes) 的 15/21 BP MSIG。申请应在申请者自行选择的公开渠道发布以下内容：

• 拟注册的账户，
• 运营主体以及将使用该额度的产品或流程，
• 请求的每日额度（默认值为 1 MB/天）。

在本仓库提交提案是一条可选的、更正式的申请途径：它为 BP 提供可审阅的永久文档和意向跟踪，可能提高申请成功的几率，但并非必要条件。能够在不经此流程的情况下让 addcreator MSIG 获得通过的申请者，完全可以那样做。

使用方式

创建者在单笔签名的单个交易中创建账户：

1. eosio::newaccount：创建方为已注册创建者的账户（例如 gm 创建 foo.gm；高级后缀规则照常适用）。
2. ram.vaulta::giftacct(creator, foo.gm, bytes, memo)：合约发送内联 giftram。

该流程已通过系统合约和 Spring 源码验证：

• giftram 仅要求赠送方的权限（delegate_bandwidth.cpp），通过 eosio.code 以内联方式满足。网络账户本身从不签名。
• giftram 在执行时检查接收方是否存在；newaccount 在同一交易中先执行。
• 合约强制这种配对关系：giftacct 读取打包的交易（read_transaction），若没有创建 account 的顶层 eosio::newaccount，则拒绝执行。在账户创建之外，赠送在结构上是不可能发生的。
• 新账户的 RAM 计费在交易结束时验证（Spring 的 transaction_context::finalize），因此内联赠送能覆盖新账户的占用；这与经典的 newaccount + buyrambytes 模式所依赖的机制相同。账户在持有任何 RAM 之后（赠送本身即会触发这一点）还会获得系统标准的 1,400 字节免费额度（ram_gift_bytes），从而减少所需的赠送量。

捐赠资金

• 初始注资：通过 ramtransfer 从 admin.grants 转入 1–2 GB（相当于约 30 万个以上、每个约 3 KB 的小型账户）。admin.grants 此前已有分发 RAM 的记录，因此这一路径已得到验证。请注意比例：截至 2026-08-08，admin.grants 持有 ram_quota 2,812,891,144 字节（约 2.62 GiB），因此 2 GB 的初始注资占该账户全部余额的很大一部分。
• 长期储备：fund.wram（约 42.08 GiB，闲置，截至 2026-08-08）被指定为未来预期的资金来源，将在该计划建立起运行记录后通过后续 MSIG 动用。合约本身不依赖 RAM 的来源。

滥用应对

• 配额作为第一道防线：每个创建者的每日字节额度限制了消耗速度，并将自我交易（创建者向自己控制的账户提供 RAM）限制在该速率之内。由于额度同时扣除单笔赠送本身和每个受赠者的行开销，大量微小赠送也无法比额度所暗示的速度更快地耗尽捐赠资金。滥用行为会在检测窗口内以链上可见的趋势显现，而非一夜之间被耗尽。
• 计划本身不构成骚扰手段：单一赠送方规则意味着只需 1 字节的赠送即可阻止某账户再从其他任何人处获得赠送 RAM。由于 giftacct 只能作用于同一交易中新创建的账户，该计划无法被用来骚扰已有账户。通过直接调用 eosio::giftram 实现的等效攻击途径属于系统合约层面的问题，不在本提案范围内。
• 创建者密钥被盗：即时的补救手段在创建者自己手中：更换密钥即可立刻驱逐攻击者，无需任何治理介入，注册状态也完好保留。此情形不需要、也不提供任何合约操作。
• 移除创建者：恶意或已停止运营的创建者由 15/21 MSIG 通过 rmcreator/setquota 移除或将额度清零，而集齐 21 名中 15 名 BP 的签名需要数天，而非数分钟。MSIG 集签期间的暴露规模为每日额度乘以该窗口时长：按默认值 1 MB/天和悲观的五天窗口计算，约为 5 MB，属于已接受的损失。该窗口内被赠送并占用的字节无法回收（参见回收）。
• 回收：在现行部署的系统合约中，ungiftram 由受赠方发起，赠送方无法单方面强制收回。BP 可在 15/21 授权下使用 eosio.wrap 以受赠方的权限执行 ungiftram，但强制返还只有在被赠送的字节未被占用时才能成功。移除和强制返还只能阻止创建者继续赠送，二者都无法回收已赠送并已被占用的 RAM。强制回收仅对从未被使用的赠送有效，因此无法应对那些填满其所取得 RAM 的创建者。
• 无需修改系统合约：本提案不要求对 eosio.system 进行任何修改。

范围边界

• 本提案仅创建系统，不注册任何创建者。准入在此之后进行，每个创建者对应一个 15/21 addcreator MSIG，详见「成为创建者」。
• 向已存在账户赠送 RAM 不在范围内，并由合约强制执行：giftacct 要求同一交易中存在针对 account 的 eosio::newaccount。由此带来的权衡是创建者无法在账户创建之后再为其补充 RAM：赠送只能发生在创建时，否则就不会发生。
• 无收入分成：创建者保留其收取费用的 100%。补贴是资金机制本身。
• 这与 new.vaulta（自助式、由付款驱动的账户创建，参见 VP-0002）不同。本计划由创建者主导，网络承担 RAM 成本。

已知限制

• 每个账户仅限一个赠送方：系统合约在任一时刻只允许一个账户拥有一个 RAM 赠送方。在本计划下创建的账户在全额返还网络的赠送之前，无法接受来自其他方（例如某个应用）的 RAM 赠送。自行购买 RAM 不受影响。
• 仅支持全额返还：ungiftram 会返还整笔赠送，不支持部分返还。

待解决问题

• 合约是否应为每笔赠送发出日志操作，以便于索引/监控？
• 来自 admin.grants 的确切初始注资规模（1 GB 还是 2 GB）？

后续步骤

一个可运行的原型已开发完成，并在 Jungle 4 测试网上进行了演示，其源代码发布于 contracts/gift。剩余工作包括解决各项待解决问题、将合约产品化，以及准备 MSIG 流程（创建 ram.vaulta、部署合约、设置 eosio.code、转入初始注资 RAM）。创建者的准入在系统上线后作为独立的 MSIG 逐一进行。