一、适用范围：不能把公链问题直接套入政务系统
讨论区块链政务平台系统有哪些常见问题，需要先区分底层网络、凭证机制与办理流程。以下解释适用于采用分布式账本或可验证凭证的政务场景，不代表某个具体平台已经存在这些故障。不同网络的参与权限和安全机制不同，问题表现也会不同。
二、性能问题：提交成功不等于最终确认
以太坊扩容文档说明，网络容量受限可能造成交易变慢、费用上升；扩容需要兼顾吞吐量、最终确认速度与安全。这一原理提示政务系统应区分材料接收、链上确认和业务办结，不能把三个状态混为一谈。
以太坊的费用机制不能直接代表所有政务链。排查办理延迟时，应分别观察业务处理与账本确认环节，而不是仅凭页面响应缓慢就断定区块链容量不足。
三、扩容问题：链外处理不代表安全条件相同
上述扩容文档还区分了依赖主网安全的二层方案和采用自身共识的侧链。将工作移到链外，并不意味着各种方案获得相同的安全保障。
政务场景评估扩容时，需要明确由谁处理请求、哪些数据用于核验，以及何时能够确认结果。单看速度指标，无法回答跨部门是否能独立核验办理记录的问题。
四、真实性问题：凭证可验证不等于内容必然真实
W3C可验证凭证模型明确区分了技术验证和对声明的采信。数字签名有助于发现篡改，但验证通过并不能自动证明凭证中每项声明都属实。
因此，政务核验不能停留在签名正确，还要结合签发机构、凭证时效和具体业务规则判断。技术证明与行政业务认可解决的是不同问题。
五、互认问题：统一格式不是全部条件
W3C模型区分签发者、持有者和验证者，并允许使用可信数据库或分布式账本等登记机制，因此可验证凭证并非必须依赖区块链。
跨部门互认除了交换格式，还需要对签发资格、字段含义和接受条件形成一致理解。能够读取凭证，不等于有充分依据接受凭证。
六、隐私问题：便于核验也可能便于关联
该模型指出，数字信息的持久保存与跨来源关联会带来隐私风险。政务凭证涉及个人信息时，应明确每项办理事项实际需要核验什么，避免把可共享理解为可无限共享。
隐私保护技术也有适用条件，不能仅凭采用区块链或零知识证明等名称，就认定系统已经满足全部隐私要求。性能、安全、业务规则与信息保护需要分别评估。