请勿尝试验证运行DHT节点的软件，只需根据需要验证它们提供的行为和数据。
有几种方法可以做到这一点，具体取决于数据的预期用途。在不知道DHT的确切用例的情况下，我只能提供一些通用指南：
- 如果您对DHT本身之外的数据有一些信任锚（例如，用户A向用户B提供包含pubkey的链接），则使用该签名，然后将其合并到您的协议设计中，例如：从pubkey派生DHT查找键，用它来验证数据上的签名，使伪造成为不可能，等等。
- 在某些情况下，使用椭圆曲线加密并使用
node ID == node's pubkey 会很有用
- 使用冗余，发布到多个节点。无论如何，你应该这样做，因为节点可以离线/变得无法访问
- 另一种形式的冗余：非对称API，其中每个发起者发布单个值，但目标节点返回已存储在其上的值列表，可能包含原始节点的IP。
- 减少激励让攻击者首先破坏DHT：
- 协作发布 - 如果网络中的多个参与者有兴趣发布相同的数据块，那么攻击者将更难与他们竞争
- 易于重新生成的数据 - 如果有人在键空间中占有一小部分，只需重新发布数据，那么发布者的任务就是将内容保留在DHT中，不要依赖其他节点永远维护它
- 间接/数据只是一个指针 - 如果DHT不包含任何“多汁”数据本身，攻击者可能想要删除/替换但只是指向实际数据的指针，并且该指针很容易被替换为另一个攻击它变得不那么有用了
- 抗污染数据 - 在20个不良条目下的1个良好条目仍应有用）
- 保持低复杂度 - 跨越多个DHT节点/间接查找的脆弱数据结构比存储在数十个节点上的单个，几个字节长的字符串更容易破解
- 提供了一种在更高协议级别验证数据的方法 - 将从DHT获得的所有内容视为暂定
- 让攻击者难以控制DHT键空间的一小部分
- 路由表中每个IP只有1个条目
-
<key,List<value>>表格中每个密钥每个IP只有1个条目
- 通过从节点的外部IP和/或使用hashcash
派生节点ID来限制节点ID
- 使用UDP时：要求三次握手进行写操作以避免IP欺骗
一般情况下：将所有节点视为不可靠，有缺陷，并且有些（但不是全部）节点是恶意的
相信但要验证。