误区一：把节点通讯当成聊天功能
讨论区块链通讯项目，首先要明确通讯对象。以太坊网络层文档描述的是节点发现、连接和信息交换，执行客户端与共识客户端分别参与不同的点对点网络。这些机制服务于区块链运行，不能直接证明某个产品具备完整聊天功能。
面向用户的通讯还涉及收件人识别、离线消息处理及群成员管理。判断功能时，需要区分底层网络能力与应用实际实现。
误区二：认为通讯内容必须上链
以太坊文档介绍的 Whisper 曾以不上链的方式实现节点间安全消息传递，并注明该协议已经弃用。这个例子说明，区块链相关通讯可以采用链外消息传输；历史协议的存在也不能证明今天某个产品仍采用或支持它。
理解一个通讯方案时，应分别看身份信息、消息正文和验证记录如何处理。仅凭“区块链通讯”这一名称，无法确定哪些数据会写入链中。
误区三：把连接加密等同于端到端加密
节点之间建立加密连接，保护的是相应连接上的数据。若消息经过中继，仍需确认中继是否能够读取正文。端到端加密关注的是只有通讯端点能够读取消息，两者保护的范围不同。
RFC 9420 定义的 MLS 协议面向异步群组密钥建立，目标包括前向保密与入侵后安全。它提供群组安全通信的密码学基础，但引用标准名称本身不足以证明产品已正确实现这些保障。
误区四：认为群聊只需共用一个长期密钥
群聊成员可能加入、退出或更换设备，密钥状态需要随之管理。前向保密关注密钥泄露后对历史消息的保护；入侵后安全关注在满足协议条件、攻击者不再持续控制端点后，通过更新恢复后续通信的安全。
这些性质都有适用条件。若设备仍被控制，或者群成员主动转发明文，不能期待加密协议阻止信息泄露。
常见问题：怎样理解项目的安全描述
“采用点对点网络，是否就足够安全？”需要进一步明确保护目标：连接安全、消息内容保密和群成员权限是不同问题，各自需要对应的设计与实现证据。
“支持 MLS，是否代表聊天系统已经完整？”MLS 主要解决群组密钥建立及相关消息保护，完整应用仍需处理身份验证、消息送达与设备管理。上述概念适用于理解技术边界，不能替代对某个具体项目实现的核验。