Kaspa KIP14 — Crescendo 硬分叉规格和设计方案
KIP: 14
Layer: Consensus (hard fork)
Title: The Crescendo Hardfork
Type: Consensus change (block rate, script engine)
Author: Michael Sutton <msutton@cs.huji.ac.il>
Comments-URI: https://research.kas.pa/t/crescendo-hardfork-discussion-thread/279
created: 2025-01-21
updated: 2025-01-21
Status: Draft
抽象
该 KIP 提议为 Kaspa 网络实施 Crescendo 硬分叉,详细说明了各种组件的共识变化和过渡策略。此 KIP 的主要变化是每秒块数 (BPS) 从 1 增加到 10,这是一项重大调整,对节点性能以及存储和带宽要求具有广泛的影响。这需要更新许多共识参数,并且在某些情况下,需要重新思考现有机制,以确保它们在增加的区块速率下保持高效(例如,KIP-4 中引入的稀疏 DAA 窗口)。
此外,此硬分叉包括激活对 Kaspa 的其他重大改进。从 KIP-9 开始,它引入了一种关键机制来管理和缓解状态膨胀,从而调节持久存储需求。KIP-13 对此进行了补充,KIP-13 规定了节点的瞬态存储要求。此硬分叉中激活的另一个主要组件是 KIP-10,它为 Kaspa 的脚本引擎引入了新的内省操作码。通过这种内省,这些操作码实现了契约的概念,允许进行高级交易控制,包括设计支持微交易和补充 KIP-9 的附加地址。
这次硬分叉也标志着 KIP-1(Kaspa Rust 重写)的结束。Rusty Kaspa (RK) 实现的性能改进为支持此升级提供了必要的基础,使网络能够处理 10 BPS 及以上的增长需求。
赋予动机
Crescendo 硬分叉是通过 RK 实现的 Kaspa 网络的主动升级。随着 TN11(一个以 10 BPS 运行的测试网)稳定运行了一年多,该网络已经证明了它为这种过渡做好了准备。通过增加容量和速度,此次升级使 Kaspa 能够支持新兴技术的预期需求,包括通过正在进行的基于 ZK 桥的设计实现的智能合约层 [1]。
本 KIP(不包括 KIP-13)中描述的所有更改都已在 TN11 中实施和测试,从而为了解其性能和稳定性提供了宝贵的见解。这些结果确保提议的修改已准备好在 Kaspa 主网上部署。
规范
共识变化
1. BPS 相关变化
以下详细介绍了仅与 bps 上调相关的变化。
将 BPS 从 1 增加到 10:
此更改由名为 (milliseconds) 的共识参数控制,该参数控制区块之间的预期时间。要将 bps 从 1 增加到 10,将从 1000 毫秒减少到 100 毫秒。
target_time_per_block
target_time_per_block
这种调整反过来会导致难度调整算法将难度降低 10 倍,从而将区块创建速度提高 10 倍。有关此转换的更多详细信息,请参阅下面的“过渡策略”部分。
重新调整 Ghostdag K 参数:
减少区块时间会导致更高的并行区块率。因此,Ghostdag K 参数是2λD(其中λ是区块速率,D是先验延迟界限),必须重新校准以保持符合 Ghostdag 公式的网络安全(参见 PHANTOM-GHOSTDAG 论文 [2] 第 4.2 节中的等式 1)。
设置D=5,δ=0.01,则新的 Ghostdag K 将根据其中的泊松尾部截止值重新计算为 124。
扩展基于时间的共识参数:
最终深度 (φ):之前定义为 1 bps(86400 个数据块)的 24 小时持续时间,现在将对应于 10 bps(432,000 个数据块)的 12 小时持续时间。
合并深度边界 (M):定义为 1 小时的持续时间,现在将从 1 bps 的 3600 个区块增加到 10 bps 的 36,000 个区块。
修剪深度:计算公式φ+2M+4KL+2K+2[3],其中:
Coinbase 到期日:最初定义为 100 秒或 ~100 个区块(1 个基点),现在对应于 1000 个区块(10 个基点)。
φ: 最终确定性深度
M:合并深度边界
L:合并集大小限制(见下文)
K: 鬼 K
修剪深度公式提供了下限,但实际修剪周期可以设置得更长。代入缩放参数,下限计算为 627,258 个区块,代表大约 ~17.4238 小时。我们建议将其四舍五入到 30 小时,以便简单和实际应用。30 小时更接近当前的主网修剪期(~51 小时),并且与整个 TN11 使用和基准测试的值(~31 小时)密切相关。
几个概念上由持续时间定义但通过区块计数应用的参数必须使用新的 bps 进行缩放:
对影响性能的参数进行保守缩放:
最大区块父级:由 10 个增加到 16 个。根据连续的 TN11 数据,16 个仍然远高于 DAG 提示的平均数量,确保所有提示通常被后续块合并。
合并集大小限制 (L):由 180 提升至 248 (2K) 以适应更高的 BPS,同时保持存储效率。
对 Coinbase 奖励机制的调整:
deflationary_phase_daa_score
:当前共识规则中的常数,标志着通货紧缩阶段的开始。crescendo_activation_daa_score
:Crescendo 激活时的 DAA 分数,将作为硬分叉实施的一部分进行设置。下面描述的方案通过在概念上将每个区块的当前奖励转换为同等价值的每秒奖励,从而保持奖励系统和发行时间表的精确完整性。
具体来说,奖励表将继续从月份映射到奖励,但奖励现在被视为每秒奖励。要计算每个区块的奖励,每秒奖励除以 bps。
必须特别小心才能正确计算当前的排放月份。以前,DAA 分数(本质上是块计数)直接映射到秒,因为块是以每秒 1 个块的速率生成的。硬分叉后,10 bps,必须使用激活时的 DAA 分数来保持准确的第二次计数。
补贴月份计算中使用了两个关键值:
以下代码描述了补贴月份计算中所需的永久更改。然后,可以像以前一样使用返回的值从 subsidy-by-month 表中提取奖励。
subsidy_month
// We define a year as 365.25 days and a month as 365.25 / 12 = 30.4375
// SECONDS_PER_MONTH = 30.4375 * 24 * 60 * 60
const SECONDS_PER_MONTH: u64 = 2629800;
fn subsidy_month(daa_score: u64) -> u64 {
if daa_score < crescendo_activation_daa_score {
// Pre activation, we simply assume block count represents second units (since block per second = 1)
return (daa_score - deflationary_phase_daa_score) / SECONDS_PER_MONTH;
}
// Else, count seconds differently before and after Crescendo activation
let seconds_since_deflationary_phase_started =
(crescendo_activation_daa_score - deflationary_phase_daa_score) +
(daa_score - crescendo_activation_daa_score) / bps;
return seconds_since_deflationary_phase_started / SECONDS_PER_MONTH;
}
2. 早期 KIP 的激活
KIP-4 的激活:稀疏 DAA 和中位时间窗口:
past_median_time_sample_rate = 100
(来自 )。MEDIAN_TIME_SAMPLE_INTERVAL=10
difficulty_adjustment_sample_rate = 40
(来自 )。DIFFICULTY_WINDOW_SAMPLE_INTERVAL=4
过渡到稀疏难度调整算法 (DAA) 和稀疏中位时间 (MT) 窗口,同时保持其之前的持续时间(DAA 为 2641 秒;中位时间为 263 秒)。
这些稀疏窗口的大小(以块为单位)是通过将其持续时间除以所选采样间隔来确定的。对于 DAA,我们选择 4 秒的采样间隔,从而产生窗口大小⌈2641/4⌉=661.对于 MT,我们选择 10 秒的采样间隔,从而得到⌈263/10⌉=27.值得注意的是,这些窗口大小现在独立于 bps。
采样间隔按 bps 缩放以计算块采样率:
KIP-9 (Storage Mass):引入一种存储质量公式,以减轻和调节有机和对抗条件下的 UTXO 集生长。
KIP-13 (Transient Storage Mass):实施瞬态存储质量以调节短期存储使用。
KIP-10(脚本引擎增强功能):在脚本引擎中引入直接内省,支持契约和高级事务控制。
3. 其他更改
下面详细介绍了不需要单独 KIP 的其他细微更改。
启用事务有效负载
此硬分叉引入了对原生(非 coinbase)交易字段中任意数据的支持。代表标准交易类型的原生交易现在支持有效负载,而 coinbase 交易保留其现有的受限格式。事务已经包含一个名为 的保留字节数组字段,以前对于本机事务,该字段需要保持为空。此限制现已解除,使本机事务能够传输任意数据。payload
payload
为了确保正确处理,必须调整该机制以包括 field,证明对有效负载的授权。这是通过将 哈希 the 放入 a 并将其合并到整体 .为了向后兼容,如果 the 为空,则零哈希值将作为 .sighash
payload
payload
payload_hash
sighash
payload
payload_hash
该字段已包含在事务和当前 Kaspa 实施中。但是,其他客户端可能已假定此字段始终为空,并且必须验证其实现以考虑它。payload
hash
id
这一变化实现了初步的第二层智能合约实现,利用 Kaspa 进行排序和数据可用性,但还没有结算功能。KIP-13 中引入的临时存储法规可减轻滥用或垃圾邮件风险。此功能已在 RK 中实现,并针对 TN11(拉取请求)激活。
要求第一个块父项作为 Ghostdag 选定的父项
引入了新的共识标头有效性规则,其中第一个直接区块父级必须是 Ghostdag 选择的父级。这简化了为所选链带来见证的过程,特别是对于 KIP-6 之前的场景(对于这次硬分叉来说是计划外的)。
过渡策略
常规激活策略
在 Kaspa 中,块的 DAA 分数通常决定何时激活分叉规则。但是,某些共识变化会影响区块本身的 DAA 分数,从而导致循环逻辑。一个值得注意的例子是 KIP-4(稀疏 DAA 窗口)的激活,它修改了 DAA 分数的计算方式。为避免这种循环,我们建议使用块所选父级的 DAA 分数来确定激活。必须考虑所选父级分数的另一种情况是 Ghostdag K 的增加,因为 Ghostdag 是在已知 DAA 分数之前计算的。
为了简化实施,我们建议将此方法扩展到所有与 Header 相关的更改,其中包括与 bps 相关的更改(不包括 coinbase 奖励)和第一父规则。
对于 KIP 9、10 和 13,以及有效负载激活和 coinbase 奖励更改(均与区块体相关),我们建议使用通常的、更直接的方法,即依赖区块本身的 DAA 分数。
过渡期间的操控难度调整
当过渡到 10 bps 时,会出现一个重大挑战,因为激活后的 DAA 窗口跨越 1 bps 和 10 bps 时代。需要仔细考虑,以防止由于窗口开始时较慢的出块速度而导致的难度过大降低。此外,KIP-4 的采用带来了额外的复杂性,因为我们正在从完整的 DAA 窗口转变为稀疏窗口。
建议的解决方案
为了应对这些挑战,提出了以下方法:
重置 DAA 窗口:DAA 窗口应在激活点重置,并且应仅包含激活后开采的区块。
初始区块的难度计算:
空窗口:当窗口为空时(即,选定的父级在激活前被挖掘),将难度目标增加 10 倍,以反映新的 bps。此调整将查找区块所需的工作量减少了 10 倍,从而在相同哈希率下,区块率增加了 10 倍。
Partial window(部分窗口):对于窗口包含一些激活后块但尚未达到最小要求大小的块,请按原样使用所选父级的难度。
最小窗口大小:最小窗口大小应设置为 60-661 个块之间的值,相当于大约 4-44 分钟,以平衡稳定性和响应速度。
修剪点调整
激活后,修剪深度会增加以适应更高的 bps。但是,修剪点本身不应立即回归以满足新的深度。相反,它必须在更新的规则下逐渐过渡,保持固定在当前位置,直到其上方的点积累足够的深度。这确保了修剪点的单调性。
严格的修剪点规则
表示Bn作为 deep 处的块n在其选定的链上。请注意,深度的定义与当前规则保持不变。
对于每个区块B激活后 mined 时,letpre(B)表示激活前开采的最后一个链祖先的修剪点。
将新的修剪深度表示为P.
激活后块的修剪点B表示π(B)的 API 由以下规则确定:π(B):=max(pre(B),BP).
确认
我感谢 @coderofstuff 帮助管理本 KIP 中详述的硬分叉,并感谢 Kaspa 的所有核心开发人员和研究人员为这项艰巨的努力而辛勤工作。
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
感动 | 同情 | 无聊 | 愤怒 | 搞笑 | 难过 | 高兴 | 路过 |
相关文章
-
没有相关内容