区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载导读本文基于 Bisq 去中心化比特币交易所的 DAO去中心化自治组织治理实现深入讲解 append-only只追加提案在进入节点内存提案集合、参与 proposal-state hashing、盲投票与计票等共识环节前必须满足的验证规则。你将理解为什么已持久化、已广播的提案不等于有效提案掌握公共数据字段规则与提案类型特定规则的分层设计、按周期激活activation的精确语义以及重启节点与持续运行节点如何最终得到一致且相同的共识结果。适用范围从原始存储到共识消费的完整链路本规范原始文档docs/specifications/dao/proposal-validation.md定义了一个 append-only DAO 提案在何时可以进入节点提案缓存proposal cache以及何时有资格参与 proposal-state hashing、选票ballots和下游经济使用。覆盖的阶段包括启动时的历史解析startup parsing运行期间的实时 payload 到达live payload arrival本地持久化的历史选票persisted ballots规则的激活语义activation历史兼容性保证historical compatibility。需要明确的是提案类型特定规则proposal-type-specific rules可能在此基础上附加额外要求其中 bonded-role债券角色提案的术语bond terms校验在独立文档 docs/specifications/dao/bonded-roles.md 中专门规定。在代码层面不同提案类型由 ProposalValidatorProvider 路由到七类校验器CompensationValidator补偿、ReimbursementValidator报销、ChangeParamValidator参数变更、RoleValidator债券角色、ConfiscateBondValidator没收债券、GenericProposalValidator通用与RemoveAssetValidator下架资产。信任与承诺边界OP_RETURN 只证明选择不证明合规规范开篇就划定了信任边界这一核心前提一条 append-only 提案 payload 是不可信的untrusted网络数据。持久化和重广播并不能使它变有效。提案交易通过其 OP_RETURN 哈希提交commit到 payload但这种绑定只证明交易创建者选择了这些精确字段并不能证明这些字段满足 DAO 规则。由此每一笔具有共识资格的提案必须同时满足具备要求的交易类型transaction type其 OP_RETURN 承诺与规范化canonical后的 payload 匹配自提案数据字段验证proposal-data-field validation激活起还必须通过全部公共规则与类型特定数据字段规则。公共规则不依赖已解析的 DAO 状态ProposalValidator.validateCommonDataFields 中逐项落地规则实现细节名称与链接非空notEmpty(proposal.getName())、notEmpty(proposal.getLink())名称与链接长度上限均不得超过 200 个字符checkArgument(... 200)交易 ID要么未分配要么恰好 64 个字符extra-data map必须通过有界bounded校验其中 extra-data map 的边界由 ExtraDataMapValidator 定义条目数上限 10、键长度上限 100、值长度上限 100 000 字符约 100 KB。注释明确指出这是防止网络被海量数据攻击的防护。类型特定规则与状态依赖类型特定规则校验请求金额与地址、参数值、债券标识符、资产符号、bonded-role 术语等。关键点在于一条类型特定规则可以读取该提案交易高度上生效的 DAO 参数值即规则是按提案交易所在高度取参数而不是取当前链高度。以补偿提案为例CompensationValidator 要求 BSQ 地址非空、以B开头、地址可解析并且请求的 BSQ 数量介于CompensationConsensus在该高度计算的最小/最大补偿金额之间。参数变更提案则由 ChangeParamValidator 按参数类型BSQ/BTC/PERCENT/BLOCK/ADDRESS做类型化校验并限制单次变更相对当前值的升降幅度。追加型 payload 的准入流程缓存收集 ≠ 共识验证append-only P2P 存储ProposalPayload经 ProposalStorageService 落盘只是原始存储而非共识提案集合。节点将存储的 payload 投影project进内存提案集合时遵循三条规则初始 DAO 解析完成前任何 payload 必须先通过不依赖解析的公共规则才能进入集合需要 DAO 状态的类型特定规则被推迟。解析完成后来自已激活周期activated cycle的新投影 payload 必须通过完整数据字段验证器激活前pre-activation的 payload 继续仅使用公共规则——准入不得对历史周期追溯施加提案类型规则。解析期间临时投影的 payload解析完成时必须在所属周期对应的规则下重新检查即便集合中已存在不合格条目被移除。这三条规则在代码中的落点是 ProposalService.areDataFieldsValidForAdmission当!isParseBlockChainComplete() || !isProposalDataFieldValidationActivated(proposal)时只做公共字段校验否则做全量字段校验而 removeProposalPayloadsWithInvalidDataFields 在解析完成后统一清理不合格条目。为什么解析期间不能全部推迟集合在历史解析期间必须保持可用因为 proposal-state hashes 在每个重放的周期cycle的首个盲投票块处构建见 ProposalStateMonitoringService其哈希链每周期一条、携带前一区块哈希。如果把所有 payload 推迟到解析完成重放出的历史周期将错误地得到空提案集合。因此规范强调临时投影永远不能替代共识消费端的最终验证。最终效果是无论 payload 是启动时从磁盘读取、还是启动后从网络到达最终的内存集合都与来源无关startup/network 无关性。共识资格边界每个消费端都必须独立验证准入cache admission与选票持久化都不能替代共识验证。规范明确要求共识与经济消费者必须独立验证提案同一资格边界适用于proposal-state hashing 使用的提案列表提供给投票的选票ballots计票结果计算vote-result中重建的有效选票宇宙valid ballot universe从旧的本地持久化文件恢复的选票用于构造 Burning Man 支付候选者的补偿提案Burning Man 燃烧目标模型中使用的报销提案。代码层面ProposalService.getValidatedProposals 对每个 payload 调用isValidForConsensus过滤BallotListService.getValidBallotsOfCycle 与getValidatedBallotList同样对每个选票底层提案执行isValidForConsensusVoteResultService.createBallotList 在计票阶段基于本周期有效选票重建投票人视角的选票列表。激活后即使在初始链解析期间也全量验证从激活起即使在初始区块链解析期间也执行全量数据字段验证。验证不得依赖节点级初始解析完成标志。理由当提案在其所属周期被消费时该提案交易与验证所需的 DAO 参数历史已经可用。因此一个同步中的节点syncing node对 change-parameter 提案执行的完整共识检查与一个早已运行的节点完全相同。代码上ProposalValidator.isValidForConsensus 首先校验isTxTypeValid交易类型匹配且 OP_RETURN 与 payload 匹配见 isOpReturnDataMatchingPayload其中 OP_RETURN 由 ProposalConsensus.getOpReturnData 构造为 22 字节1 字节类型 1 字节版本 20 字节 payload 哈希然后在已激活时调用validateDataFieldsForConsensusChangeParamValidator 覆写为强制validateParamFieldstrue从而在历史解析中不依赖解析完成标志最后再跑validateConsensusDataFields。RoleValidator 也通过validateConsensusDataFields在硬分叉 3 激活后强制校验债券术语。一条无效提案将从 proposal-state hashing 与有效选票宇宙中同时剔除持久化的选票也无法将其恢复。这使得启动历史、P2P 到达顺序、旧的本地选票持久化与共识结果完全无关。激活与历史兼容独立常量、周期级选择、捆绑资源审计按网络划分的激活高度提案数据字段验证拥有独立于 bonded-role 验证及其他 DAO 硬分叉规则的激活设置网络激活高度Mainnet963 350Bitcoin testnet3 000 000Regtest 与 DAO 测试网络1这些值与硬分叉 3hard fork 3在 DaoHardFork 中定义的激活高度恰好一致但规范明确该规则拥有独立常量PROPOSAL_DATA_FIELD_VALIDATION_ACTIVATION_HEIGHT_*允许在不动其他共识规则的前提下重新排期发布审批必须显式覆盖该规则及其周期级选择语义而不能从数值相等推断已获批准。周期级规则选择取第一个 RESULT 块规则选择的语义是提案所属周期的第一个 RESULT 块PeriodService.getFirstBlockOfPhase(blockHeight, RESULT)得到结果评估高度再交给DaoHardFork.isProposalDataFieldValidationActivated(resultEvaluationHeight)判定。这一设计实现了两个目标同一周期内所有提案被一致对待防止同一周期内不同区块创建选票的节点选择不同规则。首个结果评估高度 ≥ 配置激活高度的周期使用全量数据字段验证激活之前通用共识资格检查保留交易类型与 payload 承诺验证但不会把每一个 UI/准入规则追溯变成共识规则。独立激活的提案类型规则含 bonded-role 术语校验沿用各自规定的激活语义。捆绑主网资源的兼容性审计规范披露了一个量化的兼容性结论捆绑的主网资源至高度968 341包含 2 018 条 append-only 提案 payload没有任何一条违反公共的 name/link/transaction-ID/extra-data 校验也没有任何两条 payload 使用相同的提案交易 ID。该审计支撑准入加固admission hardening的历史兼容性但并不替代激活门控也不覆盖之后的区块。公共字段与交易 ID 检查由可选的opt-in资源审计复现对应测试为 BundledDaoStateAuditTest.refreshedBundledStoresAreReadableAndInternallyNonEmpty其中以GenericProposalValidator(null, null)逐条执行areCommonDataFieldsValid并断言重复提案交易 ID 数量为 0。运行命令与文档一致./gradlew --no-daemon --max-workers2 :core:test --rerun \ --tests bisq.core.dao.BundledDaoStateAuditTest.refreshedBundledStoresAreReadableAndInternallyNonEmpty \ -PrunResourceAuditstrue --consoleplain注意该测试由-PrunResourceAuditstrue对应的系统属性门控EnabledIfSystemProperty(named bisq.runResourceAudits, matches true)是发行审计的一部分。关于首个全量验证周期捆绑历史包含始于高度960 187的周期其第一个 RESULT 块964 857是首个 ≥ 主网激活高度963 350的结果评估高度因此该周期提案是第一批以全量数据字段验证评估的提案。其中 8 条提案6 条补偿、2 条报销请求在上一审计边界963 120与激活高度之间被挖出。资源审计只检查这些提案的公共字段与交易 ID不检查其在各自提案交易高度生效的 DAO 状态下的类型特定验证——那部分必须通过同步的主网节点确认。安全理由消除重启节点与运行节点的分歧没有这些规则时的攻击链条如下一个字段无效但交易绑定transaction binding有效的 payload可能被重启中的节点准入却被持续运行的节点拒绝两个节点由此构造出不同的选票宇宙一个节点可以对某提案形成隐式否决另一个节点却把同一提案的显式投票当作缺失处理并丢弃该投票人整个解密后的选票集decrypted ballot set可能改变无关提案的结果与 DAO 状态哈希。修复在两条必需边界上缩短该链条稳定无效的字段无法进入启动集合解析完成前即被公共规则拦截已激活的全量验证阻止任何临时或持久化条目进入共识无论它如何进入缓存。与之呼应ProposalValidator 类级注释警示这里的改动可能破坏共识Changes here can potentially break consensusProposalService 对原始投影的注释同样强调准入该集合并不证明提案体与对应交易承诺匹配不得驱动授权、支付、所有权等经济决策必须使用getValidatedProposals()。小结围绕准入缓存与进入共识这两条被刻意解耦的边界Bisq DAO 采用了一套分层验证体系解析无关的公共字段规则负责把住缓存入口周期级激活的全量验证在共识消费端兜底而 2 018 条捆绑主网 payload 的审计证明了这套加固对历史数据的兼容性。理解这套语义对排查提案无法上链、选票缺失以及 DAO 状态哈希不一致等问题是不可或缺的前提。赞分享区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载相关推荐Bisq 1.10.5 安全加固版深度解析DAO 规范哈希、投票治理与桥接认证Bisq 1.10.5 安全加固版深度解析DAO 规范哈希、投票治理与桥接认证 本篇技术指南以 Bisq 仓库官方发布说明 full release note区块链DeFi金融科技Bisq 1.10.2 DAO 共识加固解析Merit 验证、高度门控算术与投票结果一致性Bisq 1.10.2 DAO 共识加固解析Merit 验证、高度门控算术与投票结果一致性 导读 本文基于 Bisq 1.10.2 的 Notable Cha区块链DeFi金融科技Bisq 1.10.2 深度解读DAO 共识安全加固与高度门控精确算术Bisq 1.10.2 深度解读DAO 共识安全加固与高度门控精确算术 本文基于 Bisq 仓库 release notes/1.10.2 目录下的发布文档区块链DeFi金融科技上一篇WarcraftHelper重构经典游戏体验突破二十年技术壁垒下一篇Text Generation InferenceTGI完整指南从架构原理到生产部署与结构化输出创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考