验证型转非验证型公证人变更交易：历史交易同步问询

我来针对你提出的两个问题逐一拆解：

1. 验证型公证人转为非验证型公证人的变更交易 #

这类变更交易本质上是链上公证人权限的更新操作，需要严格遵循链的治理规则执行，大致流程是这样的：

• 首先得由有权限的主体发起交易——可能是当前的验证型公证人集合（多签达到阈值）、链上治理合约授权的地址，或者符合预设条件的节点。交易里必须包含核心信息：要转角色的公证人地址列表、权限变更类型（比如把isVerifier标识从true改成false），还有必要的签名验证（如果是多签机制，得凑够足够数量的验证人签名）。
• 链上的公证人管理合约收到交易后，会先做一系列校验：发起方是不是真的有权限、签名有没有效、变更的地址是不是当前的验证型公证人等等。校验通过后，就会更新链上的公证人状态存储，把对应地址的验证权限移除，同时保留它们作为非验证型公证人的身份（比如可以参与数据同步、辅助共识周边工作这类非核心验证的活）。
• 交易执行完后，链上状态会同步广播给全网所有节点，确保整个网络都认可新的公证人权限配置。

2. 新非验证型公证人集合获取历史交易信息的方式 #

这个得看链的设计定位和非验证型公证人的职责，主要分两种情况：

• 仅获取历史交易哈希：这是轻量化的方案，适合存储资源有限的节点。新集合只需要同步链上的区块头（里面包含区块内所有交易的默克尔根哈希）和每笔交易的哈希值就行。这样做的好处是快、省空间，而且能通过对比本地计算的默克尔根和链上区块头的根哈希，来确认历史交易没被篡改。但如果要查看交易的具体内容，就得临时从全节点去拉取了。
• 获取完整交易依赖图：如果非验证型公证人需要承担交易溯源、数据审计，或者要提供交易查询这类服务，那就得同步完整的交易数据，包括它们的依赖关系（比如某笔交易依赖的UTXO、合约状态变更记录等等）。这种方式占用的存储更多，但好处是能独立完成大多数数据验证和查询操作，不用依赖其他节点。

一般来说，公链里的非验证节点（类似这里的非验证型公证人）默认会走第一种轻量化路线，需要完整数据时再按需同步；而联盟链里如果非验证公证人有审计职责，通常会要求同步完整的交易依赖图。

内容的提问来源于stack exchange，提问作者nitesh solanki