[Discussion] 矿工证能量公式、惩罚机制与等级模型的改进建议

[lurenpluto]

背景

当前矿工证系统的核心能量逻辑已经基本实现，相关代码主要位于：

• src/btc/usdb-indexer/src/index/energy_formula.rs
• src/btc/usdb-indexer/src/index/energy.rs
• src/btc/usdb-indexer/src/index/pass.rs

相关协议与设计文档位于：

• doc/矿工证铭文设计.md
• doc/矿工证铭文协议.md

本 issue 不是最终方案确认，而是在现有实现基础上的一轮改进建议讨论，目标包括：

• 降低能量模型在长期运行中的数值风险
• 改善增长与惩罚之间的经济平衡
• 为后续等级系统设计提供稳定的数值基础
• 为协作矿工证的合并与结算预留合理空间

---

1. 目前能量增长公式的问题

当前增长模型的核心问题在于：能量增长公式整体仍然偏线性，且曾经采用较大的 ENERGY_GROWTH_MULTIPLIER。

主要问题

• 当 ENERGY_GROWTH_MULTIPLIER = 10000 时，增长速度过快，极易在较高余额、较长持有周期下快速逼近 u64 上限。
• 即使将 ENERGY_GROWTH_MULTIPLIER 降到 1，如果年龄 age 仍然采用“无上限线性增长”，从理论上讲依然存在能量最终打满 u64 的风险。
• 当前实现虽然通过饱和计算避免了 Rust 层面的整数溢出 panic，但一旦能量打满，后续数值会失真，影响：
  • 能量排行
  • 能量继承
  • 等级映射
  • 后续经济模型的可解释性

初步建议

建议将 ENERGY_GROWTH_MULTIPLIER 收敛到 1，同时同步调整惩罚算法的量纲和强度，避免出现“增长变慢，但惩罚仍然沿用旧体系”的失衡问题。

也就是说，multiplier 的调整不能单独看，必须和惩罚公式一起重构。

---

2. 考虑引入 balance_units 的方案

为降低线性增长公式的数值规模，建议引入余额缩放单位：

balance_units = floor(balance_sats / 100_000)

即以 0.001 BTC 为一个最小能量计量单位。

方案意义

这样做的核心目的是：

• 降低原始 satoshi 数值过大带来的增长过快问题
• 将增长公式从“按 sat 直接累计”改为“按缩放后的余额单位累计”
• 为后续 multiplier = 1 的简化方案提供更稳定的数值基础

在线性增长公式下的可行性

若配合：

• multiplier = 1
• 增长仍为线性
• growth ~ balance_units * age

则对于绝大多数现实账户规模，数值风险会大幅下降。

极端情况的风险

需要明确的是：

• 如果 age 仍然无上限线性增长，则该方案只能显著降低风险，不能从数学上彻底消除风险。
• 也就是说，只要增长对 age 仍保持无限线性，理论上经过足够长时间，仍然可能触及 u64 上限。
• 但从协议寿命和实际运行周期角度看，风险会比“直接使用 sat 原值增长”低很多。

当前讨论结论

balance_units 是一个值得引入的基础改动，优点是：

• 逻辑简单
• 易于实现和审计
• 可显著缓解数值膨胀问题

但它更适合作为“第一层缩放”，而不是唯一防线。后续仍应结合 age 侧的改进一起使用。

---

3. age 的可能改进方案

背景

当前讨论中，一个核心结论是：

年龄越大，新增能量的边际增长越慢

也就是说，age 更适合从“线性增长变量”改为“衰减后的成熟度函数 R(H)”。

这里的衰减不是指已有能量下降，而是指：

• 持有时间越长
• 每新增一个区块带来的额外收益越小

---

方案 A：分段衰减

示意为：

• 前一段全速增长
• 中段降速增长
• 后段进一步降速
• 最后可以选择进入平台期

示例思路：

0 ~ T1:      100% 增速
T1 ~ T2:      25% 增速
T2 ~ T3:      10% 增速
T3+:           0% 或极低增速

分段衰减的优点

• 容易解释，适合协议和产品文案表达
• 容易实现，适合索引器历史重放
• 容易审计和测试
• 可以自然形成 hard cap

分段衰减的缺点

• 在断点附近会有不连续感
• 用户可能围绕断点做行为博弈
• 若分段过多，参数会变得比较人工

---

方案 B：log 衰减

示意为：

R(H) = A * log(1 + H / B)

或等价形式的离散/查表版本。

log 衰减的优点

• 曲线更平滑，没有明显断点
• 更符合“长期仍有增长，但越来越慢”的直觉
• 不容易围绕某个固定高度进行边界博弈

log 衰减的缺点

• 不如分段方案直观
• 若直接使用浮点实现，历史一致性和跨语言复现要更谨慎
• 纯 log 仅能降低增速，不会天然形成严格 hard cap
• 参数调优不如分段方案直观

---

推荐方向

从当前项目阶段看，更推荐：

• 底层能量结算层：优先考虑分段衰减
• 上层等级映射层：再考虑 log / 几何阈值等平滑模型

原因是：

• 底层能量状态需要稳定、可审计、易重放
• 分段方案更适合作为协议级基础规则
• log 更适合作为展示层或等级层的非线性映射

也可以考虑折中方案：

• 用离线表或查表方式实现“近似 log 的年龄函数”
• 既保留平滑性，也兼顾实现确定性

---

4. 惩罚机制的改进

背景问题

如果增长机制引入 age 衰减，但惩罚仍然沿用旧体系，容易出现以下问题：

• 增长越来越慢，但惩罚依旧过重
• 负向余额变化的成本远大于长期积累收益
• 用户只要正常整理 UTXO 或进行少量转账，就可能遭遇过重损失
• 系统更像“强锁仓 + slash 模型”，而不是“长期质押积累模型”

当前推荐方向

更推荐采用“弱对称方案”：

penalty = lost_units * R(H_now) * lambda

其中：

• lost_units：按缩放后的损失余额单位计算
• R(H_now)：当前成熟度函数
• lambda：惩罚放大系数

该方案的意义

该方案保留了以下特性：

• 惩罚与当前成熟度挂钩
• 已成熟的仓位减仓会付出更高代价
• 惩罚强度可以通过 lambda 调整
• 比“固定最大惩罚”更平衡
• 比“完全对称无惩罚”更能抑制短期停车资金

lambda 的设计可能性

方案 1：固定系数

例如：

• lambda = 1.2
• lambda = 1.5
• lambda = 2.0

适合：

• 参数简单
• 易实现
• 易解释

方案 2：随成熟度变化

例如：

• 年轻仓位 lambda 更大
• 成熟仓位 lambda 更小

这样可以满足不同目标：

• 打击短期流入流出
• 对长期稳定账户更友好
• 减少“成熟账户一次小幅减仓也被过度惩罚”的问题

方案 3：随减仓比例变化

例如：

• 小比例减仓：较小 lambda
• 大比例减仓：较大 lambda

适合防止：

• 大额快速撤出
• 短周期套利行为

当前建议结论

相比“最大惩罚”或“完全对称惩罚”，更推荐：

• 以 R(H_now) 为基准
• 再乘一个温和的 lambda
• 构成“弱对称惩罚”体系

这更符合长期矿工体系的直觉，也更容易与后续等级系统协调。

---

5. 能量等级模型

设计目标

等级模型需要满足：

• 前期升级较快，增强参与感
• 后期升级变难，体现长期积累价值
• 不应与原始能量完全线性对应
• 能承接未来协作矿工证的合并逻辑

推荐模型：几何级数阈值模型

推荐使用几何级数型阈值定义等级门槛：

E(L) = E0 * (q^L - 1) / (q - 1)

其中：

• E(L)：达到等级 L 所需能量阈值
• E0：初始门槛
• q：增长系数，q > 1

反向求等级时可理解为对数型增长，因此具有：

• 前期升级快
• 后期升级越来越难
• 参数可控
• 结构成熟，类似许多游戏/成长系统的经验阈值设计

推荐取值方向

建议优先讨论以下区间：

• q = 1.15 ~ 1.18
• E0 根据最终能量量纲确定，例如：
  • 100_000
  • 1_000_000
  • 或其他更适合新能量尺度的值

后续可根据以下样本场景做等级对照表，再反推参数：

• 1 BTC / 10 BTC / 100 BTC
• 1 个月 / 6 个月 / 1 年 / 4 年

---

协作矿工证合并能量的注意事项

在该等级模型下，需要特别注意协作矿工证的合并方式。

当前不建议直接采用：

总等级 = 主矿工证等级 + 所有协作矿工证等级之和

原因是：

• 如果等级函数本身是凹函数（如 log / 几何阈值反函数）
• 直接相加多个等级，可能鼓励把能量拆分到多张证上
• 从而带来拆分套利或 sybil 风险

更推荐的方向

先做能量聚合，再映射等级：

effective_energy = E_main + alpha * sum(E_collab)
total_level = level(effective_energy)

其中：

• alpha 用于控制协作矿工证的贡献比例
• alpha 可以小于 1，避免协作路径过强
• 等级映射只对聚合后的有效能量做一次

这样更有利于：

• 控制拆分激励
• 保持主矿工证为核心
• 让协作矿工证成为辅助加成，而不是主导套利手段

---

待进一步讨论的问题

• balance_units 的单位应选 100_000 sats，还是更粗/更细的粒度？
• age 更适合 hard cap 的分段模型，还是平滑的 log 模型？
• penalty 的 lambda 应该固定，还是跟随成熟度/减仓比例变化？
• 等级模型中的 E0 和 q 应如何通过样本场景反推？
• 协作矿工证的 alpha 应如何设定，才能既有意义又避免拆分套利？
• 当前“负向变动后基线重置”的机制，是否需要与新的 age 模型联动调整？

---

当前建议小结

本轮讨论阶段的建议方向可以概括为：

1. 将增长体系收敛到更小量纲，避免长期数值膨胀。
2. 引入 balance_units，降低 sat 原值直接累计的风险。
3. 将 age 从简单线性变量改为带衰减的成熟度函数 R(H)。
4. 惩罚机制从“旧线性体系下的重惩罚”调整为“基于成熟度的弱对称惩罚”。
5. 等级系统采用几何级数阈值模型，并优先采用“先聚合能量，再映射等级”的协作合并方式。

[lurenpluto]

背景

基于当前讨论，先假定采用以下选择作为讨论版基线，而不是最终定案：

• balance_units = floor(balance_sats / 100_000)
• age 仍采用当前线性模型
• 负向余额变动后，仍然重置 active_height
• 惩罚采用弱对称方案：
  penalty = lost_units * R(H_now) * lambda
• 等级模型采用几何级数阈值模型：
  E(L) = E0 * (q^L - 1) / (q - 1)

本 issue 主要给出一版可落地、可试算、可继续讨论的参数草案，并附上样本数据。

---

1. 建议参数草案

1.1 基础计量参数

• UNIT_SATS = 100_000
• balance_units = floor(balance_sats / UNIT_SATS)
• lost_units = floor(abs(delta_sats) / UNIT_SATS)

含义：

• 以 0.001 BTC 作为一个最小能量单位
• 增长和惩罚都不再直接使用 sat 原值，而是使用缩放后的单位数

1.2 增长参数

• MULTIPLIER = 1
• R(H) = H
• H = current_block_height - active_block_height

含义：

• 当前阶段先保持 age 线性
• MULTIPLIER 收敛到 1
• 能量按缩放后的余额单位与线性年龄累计增长

1.3 惩罚参数

建议初始取：

• lambda = 1.5

这是一个偏温和的弱对称方案：

• 比完全对称惩罚更强
• 但不会像“最大惩罚”那样过重
• 适合先作为讨论和试算基线

1.4 等级参数

建议初始取：

• E0 = 1_000_000
• q = 1.18

这样可以把等级曲线控制在比较稳的范围内：

• 前期可感知升级
• 后期明显放缓
• 头部等级不会过快膨胀

1.5 协作矿工证合并建议

协作矿工证暂不建议直接做“等级相加”，而建议先聚合能量，再映射等级：

effective_energy = E_main + alpha * sum(E_collab)
total_level = level(effective_energy)

其中：

• alpha 暂不最终定案
• 如果需要一个讨论起点，建议先用 alpha = 0.5

---

2. 可落地公式

2.1 单位换算

balance_units = floor(balance_sats / 100_000)
lost_units = floor(abs(delta_sats) / 100_000)

2.2 年龄定义

H = current_block_height - active_block_height
R(H) = H

2.3 增长公式

若从上一个记录点到当前高度之间没有负向变动，则增长为：

growth_delta = prev_balance_units * (current_height - last_record_height)

如果一个 pass 从激活开始一直没有发生负向余额变化，则总能量可写为：

energy = inherited_energy + balance_units * age_blocks

2.4 惩罚公式

发生负向余额变化时：

penalty = lost_units * R(H_now) * lambda
        = lost_units * H_now * lambda

讨论版建议：

lambda = 1.5

2.5 正向变动更新

energy = energy + growth_delta
active_block_height 不变

2.6 负向变动更新

energy = energy + growth_delta - penalty
energy = max(energy, 0)
active_block_height = current_height

---

3. 等级模型

采用几何级数阈值模型：

E(L) = E0 * (q^L - 1) / (q - 1)

讨论版建议参数：

E0 = 1_000_000
q = 1.18

反向求等级：

level(energy) = floor(log_q(1 + (q - 1) * energy / E0))

3.1 参考等级阈值

在 E0 = 1_000_000、q = 1.18 下：

Level	所需能量阈值
L1	1,000,000
L5	7,154,209
L10	23,521,308
L20	146,627,970
L30	790,947,991
L40	4,163,213,026
L50	21,813,093,666

---

4. 样本能量与等级

4.1 样本假设

统一按以下近似区块数计算：

• 1个月 = 4,320 blocks
• 6个月 = 25,920 blocks
• 1年 = 52,560 blocks
• 4年 = 210,000 blocks

并假设：

• 无负向余额变化
• 无额外继承能量
• 即 energy = balance_units * age_blocks

4.2 样本结果

BTC 余额	balance_units	持有周期	age(blocks)	理论能量	理论等级
1 BTC	1,000	1个月	4,320	4,320,000	L3
1 BTC	1,000	6个月	25,920	25,920,000	L10
1 BTC	1,000	1年	52,560	52,560,000	L14
1 BTC	1,000	4年	210,000	210,000,000	L22
10 BTC	10,000	1个月	4,320	43,200,000	L13
10 BTC	10,000	6个月	25,920	259,200,000	L23
10 BTC	10,000	1年	52,560	525,600,000	L27
10 BTC	10,000	4年	210,000	2,100,000,000	L35
100 BTC	100,000	1个月	4,320	432,000,000	L26
100 BTC	100,000	6个月	25,920	2,592,000,000	L37
100 BTC	100,000	1年	52,560	5,256,000,000	L41
100 BTC	100,000	4年	210,000	21,000,000,000	L49

---

5. 减仓惩罚样本表

5.1 样本假设

惩罚采用：

penalty = lost_units * H_now * 1.5

其中：

• 0.01 BTC -> lost_units = 10
• 0.1 BTC -> lost_units = 100
• 1 BTC -> lost_units = 1000

5.2 原始惩罚值对比表

持有周期	H_now(blocks)	减少 0.01 BTC	减少 0.1 BTC	减少 1 BTC
1个月	4,320	64,800	648,000	6,480,000
6个月	25,920	388,800	3,888,000	38,880,000
1年	52,560	788,400	7,884,000	78,840,000
4年	210,000	3,150,000	31,500,000	315,000,000

---

6. 惩罚占比直觉

在当前这版线性模型下，如果暂时忽略继承能量，并假设当前能量近似为：

energy ≈ current_balance_units * H

那么惩罚占当前能量的比例大致为：

penalty / energy ≈ (lost_units * lambda) / current_balance_units

这意味着在该线性模型下，惩罚占比对年龄 H 不敏感，主要取决于：

• 当前余额
• 本次减少的余额比例
• lambda

6.1 示例占比表

当前余额	减少 0.01 BTC	减少 0.1 BTC	减少 1 BTC
1 BTC	约 1.5%	约 15%	约 150%
10 BTC	约 0.15%	约 1.5%	约 15%
100 BTC	约 0.015%	约 0.15%	约 1.5%

说明：

• 对于 1 BTC 账户，若减少 1 BTC，理论惩罚会超过当前能量，实际落地时会被 max(energy, 0) 截断为归零。
• 对于 10 BTC 或 100 BTC 账户，1 BTC 的减仓惩罚仍然明显，但不会直接清空能量。

---

7. 当前草案的一个重要特性

需要特别说明：

• 在当前讨论版中，age 仍然是线性的 R(H)=H
• 因此“负向变动后重置 active_height”并不会改变未来增长的线性斜率
• 它主要影响的是下一次惩罚时的 H_now

也就是说，在这版设计里：

• 真正决定惩罚强度的是 penalty = lost_units * H_now * lambda
• 而不是 reset 本身带来的未来增长减速

如果后续希望“减仓之后重新养成”的效果更强，那么最终仍然需要进一步讨论：

• 分段 age
• log age
• 或其他非线性年龄函数

---

8. 建议结论

基于目前讨论，建议先把以下组合作为第一版可试算方案：

• balance_units = floor(balance_sats / 100_000)
• MULTIPLIER = 1
• R(H) = H
• lambda = 1.5
• E0 = 1_000_000
• q = 1.18

这组参数的优点是：

• 数值量级明显收敛
• 公式简单，易于实现和重放
• 惩罚比完全对称略强，但还不至于极端
• 等级曲线具备前快后慢的非线性特征
• 便于后续继续替换 age 函数，而不需要整体推翻等级体系

[waterflier]

BTCUSDB 能量共识算法 Review：必须检查的共识攻击检查点

这份清单不是在 review 某个单一公式，而是针对一整套机制：

• 能量增减公式

• 能量→等级公式

• 等级→难度公式

• attach 机制

• 转让/流转惩罚机制

• 时间窗口设计

核心目标是回答一个问题：

这个算法在理性矿工、资本玩家、脚本玩家、巨鲸玩家面前，是否还能维持预期的博弈结构，而不会被某种单一策略打穿。

---

一、资本切分攻击检查点

1. 单地址持有 vs 多地址切分，哪种更优？

必须检查：

• 10 BTC 单地址 是否优于 2×5 BTC

• 10 BTC 单地址 是否优于 10×1 BTC

• 在不同规模下，最优策略是否发生预期中的切换

要检查的不是“有没有差异”，而是：

• 小规模时是否鼓励聚合

• 大规模时是否鼓励切分

• 切换点是否符合设计目标

2. 是否存在“无限切分更优”？

如果一个地址拆得越碎，总收益越高，那么系统会被 Sybil 化。

必须检查：

• 收益函数是否对身份数量过于友好

• 新地址冷启动成本是否足够

• 平台期是否足以阻止“零成本开新号”

3. 是否存在“无限聚合更优”？

如果大地址永远优于切分，系统会快速中心化。

必须检查：

• 边际收益是否递减

• 高等级区间是否过于强势

• 巨鲸是否能通过单点积累形成不可逆优势

---

二、流动性攻击检查点

4. 转入和转出是否构成可套利回路？

必须检查：

• 某个 BTC 转入一个高增长地址后的收益

• 同一 BTC 转出时受到的惩罚

• 短周期内是否存在净正收益

核心问题：

一笔 BTC 在多个地址间周转，是否能凭空制造额外收益？

5. 高频流转是否永远亏损？

这是一个必须锁死的点。

必须检查：

• 日内转入转出是否必亏

• 单区块、单日、短周期间的能量净变化是否总为负

• 惩罚是否显著高于短期增益

如果高频周转可盈利，系统就会量化化。

6. 低频周转是否只带来有限优势？

系统可以允许“复杂操作带来小幅优化”，但不能允许“周转成为主玩法”。

必须检查：

• 一周一次、一月几次的周转，最大收益提升是多少

• 年化增益是否仍处于可接受区间

• 普通静态持有者是否不会被明显碾压

通常要问：

最优操作相对普通玩法，收益提升是不是被压在一个有限范围内，比如 10%~30%。

---

三、等级曲线攻击检查点

7. 等级曲线是否存在“甜点区过陡”问题？

如果某个等级区间收益跃迁太强，所有玩家都会被迫卡这个区间。

必须检查：

• 平台期结束后的斜率

• 线性增长区是否过长

• 是否存在某个局部区间，边际收益异常高

8. 是否存在“卡等级套利”最优策略？

例如：

• 故意维持在 15~17 级

• 转入资金吃增长

• 转出部分资金但不掉回平台期

必须检查：

• 掉级是否足够明显

• 是否能长期维持在“舒适区”

• 一个成熟账号是否能被当成“收益放大器”反复使用

9. 是否存在“一个高等级号不如多个中等级号”的失衡区间？

这个不是不能有，而是要受控。

必须检查：

• 49级+1级 vs 30级+30级

• 1个大号 vs 多个中号 的效率差

• 多号重构收益是否超出系统容忍范围

核心判断：

多账号规划可以更优，但不能优到迫使所有人都必须这么玩。

---

四、养号与状态复制攻击检查点

10. 是否存在“用有限 BTC 养出无限多个高等级证”的路径？

这是非常关键的检查点。

必须检查：

• 一个账号脱离平台期后，是否能作为“中转站”

• 同一批 BTC 是否可在多个地址之间循环，把多个证都抬到高等级

• 这种复制效率是否有自然上限

11. 状态继承是否过强？

如果一个号掉级后仍保留太多状态，那么它会变成永动机。

必须检查：

• 转出后等级回落幅度

• 回落后是否仍处于高增长甜点区

• 多次循环后是否能稳定维持大量中高等级账户

12. 状态继承是否过弱？

反过来也要检查。

如果每次转出都几乎归零，那么：

• 养号没有意义

• 策略空间被完全抹掉

• 整体系统会太“死”

因此要 review：

• 掉级幅度是否既能抑制高频套利，又保留有限可玩性

---

五、attach 机制攻击检查点

13. 自挖 vs attach 的相对收益是否合理？

必须检查：

• 一个有算力的人，把 BTC 都放自己名下是否更优

• 还是切出一小部分自挖，其余都 attach 更优

• 这个边界是否符合预期

目标一般应是：

• 基础规模内，自挖更优

• 超出规模后，边际 BTC 更适合 attach

14. 是否存在“自我 attach 攻击”？

即：

• 自己创建多个证

• 再把这些证 attach 到自己挖矿地址上

必须检查：

• attach 是否可自我循环套利

• “自己既当矿工又当 attach 提供者”是否会破坏平衡

• 是否能通过身份拆分伪造外部协作

15. 是否存在“attach 吸附中心化”？

如果所有无算力 BTC 都最优 attach 到头部矿工，就会形成超级矿池。

必须检查：

• attach 收益是否头部越大越强

• 是否存在 attach 饱和、衰减、上限

• 大矿工是否因规模效应吸走全网 BTC

16. attach 是否会替代真实挖矿？

如果 attach 收益过强，会出现：

• 大家都想做资本方

• 没人愿意做真实算力方

必须检查：

• attach 收益来源是否健康

• 它是否只是增益层，而不是主收益层

• 没有算力的参与者是否不会反向压制有算力者

---

六、转让与二级市场攻击检查点

17. 矿工证转让是否可套利？

必须检查：

• 一个高等级/低等级矿工证在转让后的价值变化

• 转让惩罚是否足以抑制倒手交易

• 是否会形成专门的“养号-卖号”市场

18. “从未挖过矿”与“挖过矿”的状态边界是否可被绕过？

如果 attach 资格与是否挖过矿相关，这是硬边界。

必须检查：

• 是否能通过代理挖矿、短时挖矿、身份切换来规避

• 是否存在模糊状态

• 状态转换是否不可逆且可验证

---

七、算力-资本组合攻击检查点

19. 只有资本时的最优策略是什么？

必须检查：

• 纯 BTC 持有者会不会通过 attach/养号体系拿到过高收益

• 资本方是否能在没有算力的情况下高度榨取系统

20. 只有算力时的最优策略是什么？

必须检查：

• 纯算力矿工是否会被资本方压制

• 没有 BTC 的算力方是否仍有合理生存空间

21. 同时拥有资本和算力时，是否存在单边碾压策略？

这是最关键的组合检查。

必须检查：

• 大资本+大算力是否会形成绝对最优闭环

• 是否还能需要外部对手盘

• 系统是否仍保持“资本与算力互相制约”的结构

---

八、时间维度攻击检查点

22. 不同时间尺度下，最优策略是否一致？

必须分别看：

• 单块

• 单日

• 单周

• 单月

• 单年

很多机制在单日看安全，但拉长到一年就被打穿。

23. 长期复利是否失控？

必须检查：

• 一次小优势经过长期复用后，是否变成巨大复利差

• 年化差异是否过大

• 是否出现“懂机制的人滚雪球，普通人完全没法玩”的局面

24. 是否存在“等待即可复制收益”的时间虫洞？

即：

• 只要耐心够长

• 就能通过重复周转把收益无限放大

必须检查：

• 时间是否只是线性放大利润

• 还是会产生接近指数的收益复制

---

九、自动化与脚本化攻击检查点

25. 是否存在可被 bot 完整执行的最优策略？

必须检查：

• 最优转账时机是否容易程序化

• 最优等级区是否固定

• 最优拆分方式是否稳定

如果可以完整自动化，就要假设一定会有人这么做。

26. 自动化后，普通玩家是否被系统性压制？

系统可以允许高级玩家小幅领先，但不能允许：

• 脚本玩家稳定吃满全部超额收益

• 普通玩家被迫出局

必须检查：

• 自动化的额外收益上限

• 自动化是否需要承担足够风险和成本

---

十、参数敏感性检查点

27. 平台期长度是否合适？

过短：

• 新号太容易起来

• 切分攻击严重

过长：

• 新用户进不来

• 只有老矿工有优势

28. 增长区斜率是否合适？

过陡：

• 出现必须卡区间操作

过缓：

• 持有激励不足

29. 转出惩罚是否合适？

过轻：

• 周转套利泛滥

过重：

• 所有流动性都被冻死

• 可玩性消失

30. attach 奖励是否合适？

过高：

• 资本吸附

• 自我 attach 攻击

过低：

• 无算力参与者失去意义

---

十一、系统级最终检查点

31. 是否存在“单一显著最优策略”？

这是最终总问。

一个健康系统应该是：

• 有主流稳健策略

• 有少量优化空间

• 没有唯一碾压解

如果最后推导出：

• 所有人都应该无限切分

• 或所有人都应该全部聚合

• 或所有人都应该只 attach

• 或所有人都应该频繁周转

那算法就是失衡的。

32. 普通用户是否还能“静态参与”？

必须检查：

• 不折腾的人是否还能玩

• 只是长期持有+正常挖矿，是否仍有合理收益

• 不懂复杂机制的人是否不会被彻底碾压

33. 系统最终鼓励的到底是什么？

每个公式最后都要回到这个问题：

它到底鼓励的是：

• 长期持有 BTC

• 降低 BTC 流动性

• 让资本和算力形成对手盘

• 保持矿工结构分散

• 给高级玩家一点可玩性

还是无意中鼓励了：

• 高频周转

• 身份切分

• 矿池吸附

• 巨鲸滚雪球

---

建议的 Review 输出格式

对一个给定算法，建议至少按下面 6 个维度逐项打表：

检查项 | 问题 | 是否存在 | 严重度 | 当前缓解手段 | 是否可接受 -- | -- | -- | -- | -- | -- 资本切分 | 大额切分是否更优 | 是/否 | 高/中/低 | 平台期/递减收益 | 是/否 流动性套利 | 高频转入转出是否盈利 | 是/否 | 高/中/低 | 转出惩罚 | 是/否 等级曲线 | 是否存在过强甜点区 | 是/否 | 高/中/低 | 曲线平滑 | 是/否 attach 攻击 | 自我 attach 是否成立 | 是/否 | 高/中/低 | 身份限制/上限 | 是/否 自动化攻击 | bot 是否能稳定套利 | 是/否 | 高/中/低 | 时间窗口/复杂度 | 是/否 系统平衡 | 是否出现单一最优解 | 是/否 | 高/中/低 | 参数重调 | 是/否

---

一句话总结

针对一个给定算法，必须 review 的不是“公式对不对”，而是：

它是否在身份、资金、时间、流动性、算力、自动化这六个维度上，被某种可重复策略打穿。

[waterflier]

https://chatgpt.com/share/69c35110-8fd4-832b-a251-6a940aa1b6be

[waterflier]

USDB核心经济模型Reivew

基本变量定义

energy:矿工证能量
balance_units：矿工证btc地址当前有效余额单位，1个BTC=1000 unit
lost_unit: 矿工证BTC减少时损失的余额
active_block_height:矿工证激活的BTC区块高度
current_block_height:当前BTC区块高度
H_now = (current_block_height - active_block_height)
effective_energy:有效矿工能量
level:挖矿等级
difficulty:算法挖矿难度
real_difficulty:实际挖矿难度
price:BTC算法价格
real_price:BTC实际价格
CoinBase:一个区块释放的USDB总数
K:协作矿工效率
CE:有效Leader矿工在出块时，其协作矿工能量总和
AE:过去1周 有效Leader矿工出块时的协作矿工能量平均值

矿工能量公式

每区块能量变化与当前矿工证能量余额的关系（注意不是基于实际实现时基于变化点的描述）

余额增加:energy = energy + balance_units
余额减少:energy = energy - penalty
penalty = lost_units * H_now * lambda
lambda = 1.5
惩罚后会更新active_block_height:
active_block_height = active_block_height + (lost_units / balance_units) * H_now

简答的说，资产100倍，就是会带来100倍的能量成长速度

矿工证的交易带来的能量损失?

协作矿工证（不能用于挖矿的矿工证)

协作矿工证，在创建时需要指定一个Leader矿工证
协作矿工证是否有独立的能量曲线？没有，能量曲线和标准矿工证一致
协作矿工证通过一次交易，才能变成普通矿工证（会有能量损失）

有效的Lead，必须在过去的一段时间里，有过一次带报价的B出块

矿工证能量->等级公式，等级与挖矿难度的关系

矿工证的难度等级，与矿工证的有效能量有关

effective_energy:

普通矿工证的有效能量 = 矿工证能量
Leader矿工的有效能量= 本证能量+(所有协作矿工证能量*50%) ，要成为Leader矿工证，需要满足在过去1周里，有过一次带报价的出块。

level

level(effective_energy) = floor(log_q(1 + (q - 1) * effective_energy / E0))
其中 E0 = 1_000_000、q = 1.18

矿工出块

real_difficulty = difficulty * （1-level*0.01）

收益公式

一个区块的总收益 = CoinBase + 手续费

CoinBase = K * (所有矿工证的BTC总数*BTC算法价格 - 已经挖出的USDB) / 36个月的区块总数（157680）

K与当前出块矿工的所有协作矿工证的总能量相关:
K = f(CE), 0.8<K<2.0

def compute_k(current, avg):
    r = current / avg
    if r < 1.0:
        return  2.0 - 6.0 / (r + 5.0)
    else:
        return max(1.0 + (r - 1.0) * 1.0,2.0)

矿工的实际CoinBase收入是CoinBase收入的75%（辅助算力池合约启用时），并在此数值上应用ETH的叔块奖励规则
矿工收益:实际CoinBase收入+ 手续费收入的 60%,进入矿工的收入合约（矿工可以自己定义合约地址，来设置和协作矿工的分红规则）
辅助算力池收益:CoinBase收入的25%，该合约一但设置不可停止
BDT DAO分红池收益:手续费收入的40%，该合约一旦设置不可停止

辅助算力池合约逻辑

持有矿工证的BTC矿工可以花费手续费，向辅助算力池提交有效BTC算力
提交2个区块高度以内的有效BTC算力：有限算力 > BTC出块难度的75%，

BTC算法价格的确定

出块者可以更新实际价格 real_price
出块者在内置的defi合约中，必须满足下面条件才能更新实际real_price
1）有 real_price0.8 的买单（用USDB购买wbtc), 总数不小于Min(1wbtc,矿工证btc余额的5%)
2) 有real_price 1.2 的卖单(用wbtc购买USDB)，总数不小于Min(1wbtc,矿工证btc余额的5%)

当Price<real_price时，Price = Min(Price1.001,real_price)
当Prcie>real_price时，Price = Max(Price0.999,real_price)