资金费率
资金费率热力图
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
账号安全
资讯收藏
自选币种
任何旨在改善其生态系统并拥抱持续发展的去中心化协议，都必须解决一个根本性挑战：如何在无需中心权威的情况下，提出、评估并采纳升级方案。在像 Kaspa 这样的工作量证明网络中，共识规则决定了安全性、交易有效性及矿工激励，非正式的讨论是不够的。任何变更都需要一个结构化的流程，确保其透明性、技术严谨性及可公开审计性。Kaspa 改进提案正是为解决此问题而生。
Kaspa 改进提案是一份正式的技术文档，用于提议对 Kaspa 网络进行更改。它定义了新想法如何从讨论走向实施，同时维护去中心化、工作量证明安全性及可预测的共识行为。KIP 为开发者、矿工和节点运营者在评估协议变更时，提供了一个共同的参考基准。
Kaspa 采用 BlockDAG 架构，而非单一的线性区块链，这使得它可以并行生产区块并实现快速确认。这种设计在共识层和网络层引入了额外的复杂性，因此一个规范的升级流程至关重要。KIP 确保针对该系统的任何变更，都能被清晰定义、公开审查并以可控的方式实施。
什么是 Kaspa 改进提案？
Kaspa 改进提案是协调协议发展的主要机制。其独特之处在于，任何社区成员均可提交 KIP。此外，不存在任何基金会或指导委员会通过指令来批准提案。相反，提案的采纳是通过技术审查、公开讨论以及已验证的安全性来达成的。
每份 KIP 都以 Markdown 文档形式提交至官方的 Kaspa GitHub 代码库。提案需概述变更动机、技术规范、设计原理以及对网络的预期影响。这些文档力求足够精确，以便独立的开发者能够实施或审计该变更。
KIP 可涵盖广泛的主题，包括共识规则、节点性能、交易验证、脚本功能以及应用层特性。该流程借鉴了比特币改进提案在比特币中的作用，但适应了 Kaspa 更高的吞吐量和基于 DAG 的架构。
KIP 的生命周期
KIP 流程遵循一个明确的顺序，旨在最小化风险并鼓励审查。
起草
提案者撰写一份详细的技术规范，描述问题及拟议的解决方案。这包括技术细节、向后兼容性考量以及对矿工和节点的潜在影响。含糊不清的提案很少能通过此阶段。
社区讨论
提案一经发布，将在 Kaspa 研究论坛和开发者频道中进行公开讨论。参与者会审查假设、识别边界情况并提出改进建议。许多提案在此阶段会经历多轮修订。
审查与采纳
核心贡献者和研究人员评估提案是否符合 Kaspa 的原则，包括工作量证明安全性、去中心化和资源效率。没有正式的投票程序。共识是通过技术层面的一致认可以及已验证的可行性来形成的。
实施
被采纳的提案将在 Rusty Kaspa（基于 Rust 的全节点软件）中实施。根据变更范围的不同，部署可能需要一次协调的网络升级。
状态跟踪
每份 KIP 都被赋予一个状态，例如草案、已提议、活跃、已实施或已拒绝。该状态在代码库中维护，为关注协议即将升级的用户，创建了一份永久的公开记录。
KIP 的类别
KIP 通常按其影响的系统层级进行分组。
共识
共识类提案定义了区块排序、验证规则和难度调整行为。这类变更最为敏感，因为错误可能影响网络安全。
节点
节点级提案旨在改善全节点的性能、内存使用率和可维护性。这些变更力求在不提高硬件要求的前提下增加吞吐量。
API 与 RPC
此类提案增强了钱包、区块浏览器和索引服务与 Kaspa 节点交互所使用的接口。
应用
关注应用的 KIP 引入了诸如消息签名和密码学证明等功能，这些功能无需改动核心共识规则即可使用。
内存池与点对点网络
此类提案调整交易传播和内存池行为，以提升高负载期间的可靠性。
脚本引擎
脚本引擎提案扩展了交易脚本能力，同时保持了基于 UTXO 的无状态设计。最近的讨论还包括零知识验证操作码和约束条件，这反映了对可编程性采取的谨慎态度。
值得关注的 Kaspa 改进提案
截至撰写时，Kaspa 代码库已收录十一份有文档记录的 KIP，另有其他提案处于研究和测试阶段。
KIP 1: Rust 全节点重写
KIP 1 将 Kaspa 全节点从 Go 迁移至 Rust。这提升了性能、内存安全性及长期可维护性，也为后续的可扩展性升级奠定了基础。
KIP 2: DAGKNIGHT 共识升级
KIP 2 提议将 Kaspa 的共识从 GHOSTDAG 升级为 DAGKNIGHT。目标是提高对拜占庭行为和网络攻击的抵御能力，同时支持更快的确认速度。该提案目前仍在积极研究中。
KIP 4: 稀疏难度窗口
KIP 4 针对高区块率引入了一种更高效的难度调整方法。它取代了一个因安全考量而被否决的早期抽样提案。
KIP 9: 扩展的质量计算
KIP 9 细化了交易质量的计算方法，以限制 UTXO 集合的增长。这抑制了滥用交易模式，并稳定了节点资源使用。它已在 Kaspa 测试网上通过测试并已激活。
KIP 14: Crescendo 硬分叉
KIP 14 将 Kaspa 的区块率从每秒 1 个区块提升至每秒 10 个。同时，它还激活了状态管理的改进和性能优化。该提案于 2025 年部署，确立了 Kaspa 当前的吞吐量基线。
KIPs 16, 17, 18 和 19: 社区提案
编号 16 至 19 的 KIP 是社区驱动的提案，目前处于正式拉取请求或测试阶段。这些包括零知识证明验证操作码、UTXO 层级的约束条件、交易排序承诺以及入站节点驱逐策略。这些功能正在 Testnet 12 上进行测试，旨在支持原生资产和链下计算，同时不引入全局状态。
KIP 的核心主题是什么？
Kaspa 改进提案中体现了几个一贯的优先事项。
具有可预测成本的可扩展性
早期的 KIP 专注于在保持节点运行可负担的前提下提升吞吐量。变更的评估不仅基于性能增益，也考量其对去中心化的影响。
状态纪律
Kaspa 开发者强调限制持久性状态的增长。诸如扩展的质量规则和约束条件等提案，旨在增加功能的同时不扩大全局状态。
受限的可编程性
Kaspa 的方法并非采用通用虚拟机，而是依赖有限的脚本、约束条件和可验证计算。这减少了攻击面并简化了共识验证。
开放的研究文化
许多近期的提案源于公开的研究讨论，而非正式的路线图。这体现了 KIP 作为协调工具，而非自上而下指令的角色。
KIP 的重要性
Kaspa 改进提案为一个去中心化网络的安全演进提供了必要的结构。它们记录了技术决策，揭示了权衡取舍，并允许对拟议变更进行独立验证。
对于矿工和节点运营者，KIP 解释了升级如何影响共识和资源需求。对于开发者，它们为建设应用和基础设施提供了稳定的参考。
结论
Kaspa 改进提案是 Kaspa 升级流程的基石。它们定义了一个高吞吐量的工作量证明 BlockDAG 网络如何在无需中心控制的情况下进行变革。从 Rust 节点重写到 Crescendo 硬分叉，再到关于约束条件和零知识验证的持续工作，KIP 始终如一地强调安全性、可扩展性和规范的设计。
凭借书面规范和公开审查，KIP 流程使 Kaspa 能够在保持其核心技术原则的同时不断发展。
