轛轛轛
高级开发工程师
富途 · 5年经验
日薪：
￥900/8h
地点：
深圳
时间：
下班后周六可工作日远程
信用行为
0
接单数
0
评价数
0
收藏数
技术能力
1. 网络通信与协议设计：熟悉 TCP、UDP、HTTP 等网络协议，具备基于 Netty 开发 P2P 网络和自定义 RPC 协议的经验。设计过消息编解码、连接管理、心跳探活及节点发现机制，并实现过基于 UDP 的类 QUIC 可靠传输。
2. 数据一致性与存储设计：具备复杂状态处理经验，实践过 UTXO 校验、原子更新和链重组回滚。熟悉 MySQL 事务、索引设计及慢 SQL 分析；能够结合 Redis、Caffeine 设计多级缓存，并处理数据更新与缓存一致性问题。
3. JVM 与性能诊断：理解 Java 内存模型、JVM 内存结构及垃圾回收机制，具备通过 GC 日志、线程信息和堆转储排查性能问题、内存泄漏及 OOM 的经验。
4. 并发系统设计：熟悉线程池、锁机制及并发容器，能够根据任务类型、资源限制和流量特点设计线程安全方案；使用 CompletableFuture 完成异步任务编排、超时控制与异常处理。
5. 服务架构与框架：熟悉 Spring、Spring Boot、Spring Cloud 及 MyBatis／MyBatis-Plus；使用 Feign、Dubbo 实现服务间通信，具备服务发现、配置管理、熔断降级等微服务治理经验。能够运用工厂、策略等设计模式组织可扩展的业务逻辑。
6. 数据库与中间件：熟悉 MySQL，使用过 PostgreSQL、Oracle、MongoDB 及 RocksDB、LevelDB。使用 Kafka、RabbitMQ 处理异步任务和事件通知，关注消息确认、失败重试、幂等消费及消息堆积；使用 Elasticsearch 实现索引设计与数据检索。
7. 安全与工程交付：了解 RSA、AES 等密码学机制，具有签名验证和通信加密相关开发经验。熟悉 Linux、Docker、Kubernetes、Jenkins，具备自动化测试、CI/CD 流水线及滚动发布实践。
8. DLT 与金融清结算：具备链上支付发起、校验、签名、广播、确认、对账和报告链路实践，理解实时交易与批量结算、交易一致性、幂等、最终性及灾备恢复要求；了解 RTGS、SWIFT、CHATS、FPS、CIPS，了解 SWIFT MT / ISO 20022（pacs、camt、pain）报文体系；持续研究 Hyperledger Besu、QBFT、
2. 数据一致性与存储设计：具备复杂状态处理经验，实践过 UTXO 校验、原子更新和链重组回滚。熟悉 MySQL 事务、索引设计及慢 SQL 分析；能够结合 Redis、Caffeine 设计多级缓存，并处理数据更新与缓存一致性问题。
3. JVM 与性能诊断：理解 Java 内存模型、JVM 内存结构及垃圾回收机制，具备通过 GC 日志、线程信息和堆转储排查性能问题、内存泄漏及 OOM 的经验。
4. 并发系统设计：熟悉线程池、锁机制及并发容器，能够根据任务类型、资源限制和流量特点设计线程安全方案；使用 CompletableFuture 完成异步任务编排、超时控制与异常处理。
5. 服务架构与框架：熟悉 Spring、Spring Boot、Spring Cloud 及 MyBatis／MyBatis-Plus；使用 Feign、Dubbo 实现服务间通信，具备服务发现、配置管理、熔断降级等微服务治理经验。能够运用工厂、策略等设计模式组织可扩展的业务逻辑。
6. 数据库与中间件：熟悉 MySQL，使用过 PostgreSQL、Oracle、MongoDB 及 RocksDB、LevelDB。使用 Kafka、RabbitMQ 处理异步任务和事件通知，关注消息确认、失败重试、幂等消费及消息堆积；使用 Elasticsearch 实现索引设计与数据检索。
7. 安全与工程交付：了解 RSA、AES 等密码学机制，具有签名验证和通信加密相关开发经验。熟悉 Linux、Docker、Kubernetes、Jenkins，具备自动化测试、CI/CD 流水线及滚动发布实践。
8. DLT 与金融清结算：具备链上支付发起、校验、签名、广播、确认、对账和报告链路实践，理解实时交易与批量结算、交易一致性、幂等、最终性及灾备恢复要求；了解 RTGS、SWIFT、CHATS、FPS、CIPS，了解 SWIFT MT / ISO 20022（pacs、camt、pain）报文体系；持续研究 Hyperledger Besu、QBFT、
项目经验
PoS 公链与智能合约运行时｜solana_golang
技术栈：Go、Borsh / Schema Registry、Slot PoS、HotStuff-style QC、Turbine 确定性传播、BLS12-381、Ed25519、X25519 / AES-GCM、TCP / QUIC、Kademlia DHT、Pebble / LevelDB、Batch / WAL / Snapshot、JSON-RPC、Program Runtime、自研 VM、PDA / CPI、ZK / Shielded Transaction
项目目标：该项目并非简单复刻 Solana，而是围绕“多个互不信任的节点，如何对同一批金融交易形成相同、可证明、可恢复的账本结果”进行完整工程实现。以 Go 从零构建交易协议、P2P 网络、Slot PoS 共识、账户状态机、智能合约运行时和持久化账本，为稳定币、代币化存款、RWA、证券型代币及链上支付提供确定执行、快速最终性、权限控制和审计基础。
项目价值：把数字资产从“数据库中的余额记录”提升为由多节点共同验证的可编程权利凭证：资产发行、转移、冻结、解冻、赎回、质押和隐私交易均由链上指令驱动，任何节点都能根据区块、QC 和状态根独立验证结果；明确区分 proposed、confirmed 和 finalized，既为钱包与支付服务提供实时交易能力，也为金融机构的清算、对账、审计和监管取证提供不可抵赖的状态依据。
解决问题：项目把分布式账本最容易分叉的三个边界作为核心问题：第一是“同一事实”——不同版本、不同节点必须对交易、提案和投票生成完全一致的字节、哈希与签名原文；第二是“同一顺序”——在 Leader 掉线、消息延迟、重复传播和恶意双签条件下，网络仍要形成唯一且可验证的交易顺序；第三是“同一状态”——多指令合约执行、手续费扣除、奖励分配和账户并发写入必须在所有节点产生相同状态根，任何步骤失败都不能留下部分状态。围绕这三类一致性问题，同时解决传播放大、交易重放、权限越界、资源耗尽、分叉恢复和节点崩溃恢复。
我的角色：作为项目独立架构设计者和核心实现者，我负责定义跨层不变量，而非只完成单一模块：网络层只能传播经过身份认证和版本校验的消息；共识层只能使用 Epoch 快照中的权威验证者与质押权重；执行层只能修改显式声明为 writable 的账户；存储层只能提交经过 QC 和状态根验证的完整写集。围绕这些约束完成协议建模、核心编码、节点装配、测试及故障恢复，并持续在性能、活性和安全性之间做架构取舍。
核心架构与贡献：① 先建立确定性协议边界：链上交易、区块、指令、Vote 和 QC 统一使用 Borsh 固定字段编码，哈希与签名使用带 domain separator、消息类型和版本号的 canonical payload，JSON 只停留在 RPC 边界；数据库原始数据携带 type、version、codec、schema_id 和 payload hash，由 Schema Registry 保留历史解码与迁移能力。该设计保证节点升级后仍能重放旧数据，并从源头避免“同一业务对象因编码差异产生不同哈希”。② 在同一 Epoch Snapshot 上同时派生 Leader Schedule 和 Turbine 传播树：使用 Epoch Seed＋Slot 按有效质押权重确定出块者；传播树再结合随机种子、快照状态根、Slot 和 ValidatorID 计算确定性排序，Leader 固定为根节点，以 fanout 和 parent=(index-1)/fanout 划分层级。每个节点无需中心协调即可算出自己的父节点与子节点，提案按树逐层转发并去重，既减少全连接广播流量，也让传播路径可以复现和审计。③ 共识采用“固定 Slot＋质押加权 Leader＋HotStuff 风格 QC”的方案：Leader 对包含父块、交易根、状态根和奖励根的区块头做 Ed25519 签名；验证者重放交易后对有效提案投 Confirm Vote，超过截止时间则投 Skip Vote，节点不会因本地超时直接跳过 Slot。VoteCollector 以本地 Epoch Snapshot 校验投票者身份和真实 stake，拒绝重复、冲突及跨分支投票；达到 2/3 权重后，将 BLS12-381 签名聚合为携带 voter bitmap 的 QC，接收节点重新计算阈值并验证聚合签名后推进 confirmed / finalized 状态。双提案和双投票被固化为可验签 Evidence，进入 Slash 与 Jail 流程，在安全性和 Leader 故障下的活性之间形成闭环。④ 交易执行遵循“先验证、后模拟、最终一次提交
技术栈：Go、Borsh / Schema Registry、Slot PoS、HotStuff-style QC、Turbine 确定性传播、BLS12-381、Ed25519、X25519 / AES-GCM、TCP / QUIC、Kademlia DHT、Pebble / LevelDB、Batch / WAL / Snapshot、JSON-RPC、Program Runtime、自研 VM、PDA / CPI、ZK / Shielded Transaction
项目目标：该项目并非简单复刻 Solana，而是围绕“多个互不信任的节点，如何对同一批金融交易形成相同、可证明、可恢复的账本结果”进行完整工程实现。以 Go 从零构建交易协议、P2P 网络、Slot PoS 共识、账户状态机、智能合约运行时和持久化账本，为稳定币、代币化存款、RWA、证券型代币及链上支付提供确定执行、快速最终性、权限控制和审计基础。
项目价值：把数字资产从“数据库中的余额记录”提升为由多节点共同验证的可编程权利凭证：资产发行、转移、冻结、解冻、赎回、质押和隐私交易均由链上指令驱动，任何节点都能根据区块、QC 和状态根独立验证结果；明确区分 proposed、confirmed 和 finalized，既为钱包与支付服务提供实时交易能力，也为金融机构的清算、对账、审计和监管取证提供不可抵赖的状态依据。
解决问题：项目把分布式账本最容易分叉的三个边界作为核心问题：第一是“同一事实”——不同版本、不同节点必须对交易、提案和投票生成完全一致的字节、哈希与签名原文；第二是“同一顺序”——在 Leader 掉线、消息延迟、重复传播和恶意双签条件下，网络仍要形成唯一且可验证的交易顺序；第三是“同一状态”——多指令合约执行、手续费扣除、奖励分配和账户并发写入必须在所有节点产生相同状态根，任何步骤失败都不能留下部分状态。围绕这三类一致性问题，同时解决传播放大、交易重放、权限越界、资源耗尽、分叉恢复和节点崩溃恢复。
我的角色：作为项目独立架构设计者和核心实现者，我负责定义跨层不变量，而非只完成单一模块：网络层只能传播经过身份认证和版本校验的消息；共识层只能使用 Epoch 快照中的权威验证者与质押权重；执行层只能修改显式声明为 writable 的账户；存储层只能提交经过 QC 和状态根验证的完整写集。围绕这些约束完成协议建模、核心编码、节点装配、测试及故障恢复，并持续在性能、活性和安全性之间做架构取舍。
核心架构与贡献：① 先建立确定性协议边界：链上交易、区块、指令、Vote 和 QC 统一使用 Borsh 固定字段编码，哈希与签名使用带 domain separator、消息类型和版本号的 canonical payload，JSON 只停留在 RPC 边界；数据库原始数据携带 type、version、codec、schema_id 和 payload hash，由 Schema Registry 保留历史解码与迁移能力。该设计保证节点升级后仍能重放旧数据，并从源头避免“同一业务对象因编码差异产生不同哈希”。② 在同一 Epoch Snapshot 上同时派生 Leader Schedule 和 Turbine 传播树：使用 Epoch Seed＋Slot 按有效质押权重确定出块者；传播树再结合随机种子、快照状态根、Slot 和 ValidatorID 计算确定性排序，Leader 固定为根节点，以 fanout 和 parent=(index-1)/fanout 划分层级。每个节点无需中心协调即可算出自己的父节点与子节点，提案按树逐层转发并去重，既减少全连接广播流量，也让传播路径可以复现和审计。③ 共识采用“固定 Slot＋质押加权 Leader＋HotStuff 风格 QC”的方案：Leader 对包含父块、交易根、状态根和奖励根的区块头做 Ed25519 签名；验证者重放交易后对有效提案投 Confirm Vote，超过截止时间则投 Skip Vote，节点不会因本地超时直接跳过 Slot。VoteCollector 以本地 Epoch Snapshot 校验投票者身份和真实 stake，拒绝重复、冲突及跨分支投票；达到 2/3 权重后，将 BLS12-381 签名聚合为携带 voter bitmap 的 QC，接收节点重新计算阈值并验证聚合签名后推进 confirmed / finalized 状态。双提案和双投票被固化为可验签 Evidence，进入 Slash 与 Jail 流程，在安全性和 Leader 故障下的活性之间形成闭环。④ 交易执行遵循“先验证、后模拟、最终一次提交
ID:436361
复制
轛轛轛
高级开发工程师 · 5年经验 · 富途
0
累计接单
0
用户评价
0
被收藏
信用行为
0
接单数
0
评价数
0
收藏数
技术能力
1. 网络通信与协议设计：熟悉 TCP、UDP、HTTP 等网络协议，具备基于 Netty 开发 P2P 网络和自定义 RPC 协议的经验。设计过消息编解码、连接管理、心跳探活及节点发现机制，并实现过基于 UDP 的类 QUIC 可靠传输。
2. 数据一致性与存储设计：具备复杂状态处理经验，实践过 UTXO 校验、原子更新和链重组回滚。熟悉 MySQL 事务、索引设计及慢 SQL 分析；能够结合 Redis、Caffeine 设计多级缓存，并处理数据更新与缓存一致性问题。
3. JVM 与性能诊断：理解 Java 内存模型、JVM 内存结构及垃圾回收机制，具备通过 GC 日志、线程信息和堆转储排查性能问题、内存泄漏及 OOM 的经验。
4. 并发系统设计：熟悉线程池、锁机制及并发容器，能够根据任务类型、资源限制和流量特点设计线程安全方案；使用 CompletableFuture 完成异步任务编排、超时控制与异常处理。
5. 服务架构与框架：熟悉 Spring、Spring Boot、Spring Cloud 及 MyBatis／MyBatis-Plus；使用 Feign、Dubbo 实现服务间通信，具备服务发现、配置管理、熔断降级等微服务治理经验。能够运用工厂、策略等设计模式组织可扩展的业务逻辑。
6. 数据库与中间件：熟悉 MySQL，使用过 PostgreSQL、Oracle、MongoDB 及 RocksDB、LevelDB。使用 Kafka、RabbitMQ 处理异步任务和事件通知，关注消息确认、失败重试、幂等消费及消息堆积；使用 Elasticsearch 实现索引设计与数据检索。
7. 安全与工程交付：了解 RSA、AES 等密码学机制，具有签名验证和通信加密相关开发经验。熟悉 Linux、Docker、Kubernetes、Jenkins，具备自动化测试、CI/CD 流水线及滚动发布实践。
8. DLT 与金融清结算：具备链上支付发起、校验、签名、广播、确认、对账和报告链路实践，理解实时交易与批量结算、交易一致性、幂等、最终性及灾备恢复要求；了解 RTGS、SWIFT、CHATS、FPS、CIPS，了解 SWIFT MT / ISO 20022（pacs、camt、pain）报文体系；持续研究 Hyperledger Besu、QBFT、
2. 数据一致性与存储设计：具备复杂状态处理经验，实践过 UTXO 校验、原子更新和链重组回滚。熟悉 MySQL 事务、索引设计及慢 SQL 分析；能够结合 Redis、Caffeine 设计多级缓存，并处理数据更新与缓存一致性问题。
3. JVM 与性能诊断：理解 Java 内存模型、JVM 内存结构及垃圾回收机制，具备通过 GC 日志、线程信息和堆转储排查性能问题、内存泄漏及 OOM 的经验。
4. 并发系统设计：熟悉线程池、锁机制及并发容器，能够根据任务类型、资源限制和流量特点设计线程安全方案；使用 CompletableFuture 完成异步任务编排、超时控制与异常处理。
5. 服务架构与框架：熟悉 Spring、Spring Boot、Spring Cloud 及 MyBatis／MyBatis-Plus；使用 Feign、Dubbo 实现服务间通信，具备服务发现、配置管理、熔断降级等微服务治理经验。能够运用工厂、策略等设计模式组织可扩展的业务逻辑。
6. 数据库与中间件：熟悉 MySQL，使用过 PostgreSQL、Oracle、MongoDB 及 RocksDB、LevelDB。使用 Kafka、RabbitMQ 处理异步任务和事件通知，关注消息确认、失败重试、幂等消费及消息堆积；使用 Elasticsearch 实现索引设计与数据检索。
7. 安全与工程交付：了解 RSA、AES 等密码学机制，具有签名验证和通信加密相关开发经验。熟悉 Linux、Docker、Kubernetes、Jenkins，具备自动化测试、CI/CD 流水线及滚动发布实践。
8. DLT 与金融清结算：具备链上支付发起、校验、签名、广播、确认、对账和报告链路实践，理解实时交易与批量结算、交易一致性、幂等、最终性及灾备恢复要求；了解 RTGS、SWIFT、CHATS、FPS、CIPS，了解 SWIFT MT / ISO 20022（pacs、camt、pain）报文体系；持续研究 Hyperledger Besu、QBFT、
项目经验
PoS 公链与智能合约运行时｜solana_golang
技术栈：Go、Borsh / Schema Registry、Slot PoS、HotStuff-style QC、Turbine 确定性传播、BLS12-381、Ed25519、X25519 / AES-GCM、TCP / QUIC、Kademlia DHT、Pebble / LevelDB、Batch / WAL / Snapshot、JSON-RPC、Program Runtime、自研 VM、PDA / CPI、ZK / Shielded Transaction
项目目标：该项目并非简单复刻 Solana，而是围绕“多个互不信任的节点，如何对同一批金融交易形成相同、可证明、可恢复的账本结果”进行完整工程实现。以 Go 从零构建交易协议、P2P 网络、Slot PoS 共识、账户状态机、智能合约运行时和持久化账本，为稳定币、代币化存款、RWA、证券型代币及链上支付提供确定执行、快速最终性、权限控制和审计基础。
项目价值：把数字资产从“数据库中的余额记录”提升为由多节点共同验证的可编程权利凭证：资产发行、转移、冻结、解冻、赎回、质押和隐私交易均由链上指令驱动，任何节点都能根据区块、QC 和状态根独立验证结果；明确区分 proposed、confirmed 和 finalized，既为钱包与支付服务提供实时交易能力，也为金融机构的清算、对账、审计和监管取证提供不可抵赖的状态依据。
解决问题：项目把分布式账本最容易分叉的三个边界作为核心问题：第一是“同一事实”——不同版本、不同节点必须对交易、提案和投票生成完全一致的字节、哈希与签名原文；第二是“同一顺序”——在 Leader 掉线、消息延迟、重复传播和恶意双签条件下，网络仍要形成唯一且可验证的交易顺序；第三是“同一状态”——多指令合约执行、手续费扣除、奖励分配和账户并发写入必须在所有节点产生相同状态根，任何步骤失败都不能留下部分状态。围绕这三类一致性问题，同时解决传播放大、交易重放、权限越界、资源耗尽、分叉恢复和节点崩溃恢复。
我的角色：作为项目独立架构设计者和核心实现者，我负责定义跨层不变量，而非只完成单一模块：网络层只能传播经过身份认证和版本校验的消息；共识层只能使用 Epoch 快照中的权威验证者与质押权重；执行层只能修改显式声明为 writable 的账户；存储层只能提交经过 QC 和状态根验证的完整写集。围绕这些约束完成协议建模、核心编码、节点装配、测试及故障恢复，并持续在性能、活性和安全性之间做架构取舍。
核心架构与贡献：① 先建立确定性协议边界：链上交易、区块、指令、Vote 和 QC 统一使用 Borsh 固定字段编码，哈希与签名使用带 domain separator、消息类型和版本号的 canonical payload，JSON 只停留在 RPC 边界；数据库原始数据携带 type、version、codec、schema_id 和 payload hash，由 Schema Registry 保留历史解码与迁移能力。该设计保证节点升级后仍能重放旧数据，并从源头避免“同一业务对象因编码差异产生不同哈希”。② 在同一 Epoch Snapshot 上同时派生 Leader Schedule 和 Turbine 传播树：使用 Epoch Seed＋Slot 按有效质押权重确定出块者；传播树再结合随机种子、快照状态根、Slot 和 ValidatorID 计算确定性排序，Leader 固定为根节点，以 fanout 和 parent=(index-1)/fanout 划分层级。每个节点无需中心协调即可算出自己的父节点与子节点，提案按树逐层转发并去重，既减少全连接广播流量，也让传播路径可以复现和审计。③ 共识采用“固定 Slot＋质押加权 Leader＋HotStuff 风格 QC”的方案：Leader 对包含父块、交易根、状态根和奖励根的区块头做 Ed25519 签名；验证者重放交易后对有效提案投 Confirm Vote，超过截止时间则投 Skip Vote，节点不会因本地超时直接跳过 Slot。VoteCollector 以本地 Epoch Snapshot 校验投票者身份和真实 stake，拒绝重复、冲突及跨分支投票；达到 2/3 权重后，将 BLS12-381 签名聚合为携带 voter bitmap 的 QC，接收节点重新计算阈值并验证聚合签名后推进 confirmed / finalized 状态。双提案和双投票被固化为可验签 Evidence，进入 Slash 与 Jail 流程，在安全性和 Leader 故障下的活性之间形成闭环。④ 交易执行遵循“先验证、后模拟、最终一次提交
技术栈：Go、Borsh / Schema Registry、Slot PoS、HotStuff-style QC、Turbine 确定性传播、BLS12-381、Ed25519、X25519 / AES-GCM、TCP / QUIC、Kademlia DHT、Pebble / LevelDB、Batch / WAL / Snapshot、JSON-RPC、Program Runtime、自研 VM、PDA / CPI、ZK / Shielded Transaction
项目目标：该项目并非简单复刻 Solana，而是围绕“多个互不信任的节点，如何对同一批金融交易形成相同、可证明、可恢复的账本结果”进行完整工程实现。以 Go 从零构建交易协议、P2P 网络、Slot PoS 共识、账户状态机、智能合约运行时和持久化账本，为稳定币、代币化存款、RWA、证券型代币及链上支付提供确定执行、快速最终性、权限控制和审计基础。
项目价值：把数字资产从“数据库中的余额记录”提升为由多节点共同验证的可编程权利凭证：资产发行、转移、冻结、解冻、赎回、质押和隐私交易均由链上指令驱动，任何节点都能根据区块、QC 和状态根独立验证结果；明确区分 proposed、confirmed 和 finalized，既为钱包与支付服务提供实时交易能力，也为金融机构的清算、对账、审计和监管取证提供不可抵赖的状态依据。
解决问题：项目把分布式账本最容易分叉的三个边界作为核心问题：第一是“同一事实”——不同版本、不同节点必须对交易、提案和投票生成完全一致的字节、哈希与签名原文；第二是“同一顺序”——在 Leader 掉线、消息延迟、重复传播和恶意双签条件下，网络仍要形成唯一且可验证的交易顺序；第三是“同一状态”——多指令合约执行、手续费扣除、奖励分配和账户并发写入必须在所有节点产生相同状态根，任何步骤失败都不能留下部分状态。围绕这三类一致性问题，同时解决传播放大、交易重放、权限越界、资源耗尽、分叉恢复和节点崩溃恢复。
我的角色：作为项目独立架构设计者和核心实现者，我负责定义跨层不变量，而非只完成单一模块：网络层只能传播经过身份认证和版本校验的消息；共识层只能使用 Epoch 快照中的权威验证者与质押权重；执行层只能修改显式声明为 writable 的账户；存储层只能提交经过 QC 和状态根验证的完整写集。围绕这些约束完成协议建模、核心编码、节点装配、测试及故障恢复，并持续在性能、活性和安全性之间做架构取舍。
核心架构与贡献：① 先建立确定性协议边界：链上交易、区块、指令、Vote 和 QC 统一使用 Borsh 固定字段编码，哈希与签名使用带 domain separator、消息类型和版本号的 canonical payload，JSON 只停留在 RPC 边界；数据库原始数据携带 type、version、codec、schema_id 和 payload hash，由 Schema Registry 保留历史解码与迁移能力。该设计保证节点升级后仍能重放旧数据，并从源头避免“同一业务对象因编码差异产生不同哈希”。② 在同一 Epoch Snapshot 上同时派生 Leader Schedule 和 Turbine 传播树：使用 Epoch Seed＋Slot 按有效质押权重确定出块者；传播树再结合随机种子、快照状态根、Slot 和 ValidatorID 计算确定性排序，Leader 固定为根节点，以 fanout 和 parent=(index-1)/fanout 划分层级。每个节点无需中心协调即可算出自己的父节点与子节点，提案按树逐层转发并去重，既减少全连接广播流量，也让传播路径可以复现和审计。③ 共识采用“固定 Slot＋质押加权 Leader＋HotStuff 风格 QC”的方案：Leader 对包含父块、交易根、状态根和奖励根的区块头做 Ed25519 签名；验证者重放交易后对有效提案投 Confirm Vote，超过截止时间则投 Skip Vote，节点不会因本地超时直接跳过 Slot。VoteCollector 以本地 Epoch Snapshot 校验投票者身份和真实 stake，拒绝重复、冲突及跨分支投票；达到 2/3 权重后，将 BLS12-381 签名聚合为携带 voter bitmap 的 QC，接收节点重新计算阈值并验证聚合签名后推进 confirmed / finalized 状态。双提案和双投票被固化为可验签 Evidence，进入 Slash 与 Jail 流程，在安全性和 Leader 故障下的活性之间形成闭环。④ 交易执行遵循“先验证、后模拟、最终一次提交
立即沟通
