可以用上面物业的例子来解释，黑客用假房主证明（在源链上的无效交易）从物业（中继器）那里拿到了真的钥匙（AllianceChain上经过签名的Merkle证明）。
攻击的具体步骤如下： 1. 黑客在源链上初始化了一个本应是无效的攻击交易。 2. 攻击交易在没有经过充分检查的情况下被写入源链，并被中继器纳入AllianceChain的Merkletree并进行签字，然后发布到AllianceChain区块中。 3. 黑客在目标链上使用步骤二中生成的有效Merkle证明调用PolyNetwork的ECCM合约，将keepers（操作权限）改成黑客控制的公钥。 4. 黑客获得keepers权限后，就可以在多条公链上任意解锁资产。
需要注意的是，PolyNetwork在有些链上的中继器没有受到攻击交易的影响，因此只要智能合约相似，某些链上的资产并未受到影响。
具体分析如下： 1. 黑客在北京时间2021年8月10日17:32:32在源链上发起了一笔攻击交易。 2. 链接（https://explorer.ont.io/tx/F771BA610625D5A37B67D30BF2F8829703540C86AD76542802567CAAFFFF280C） 3. 我们对交易进行了解码，得到了以下参数映射。 4. 这笔攻击交易调用了一个method"66313231333138303933"，对应的签名是0x41973cd9（与之后调用的putCurEpochConPubKeyBytes函数的签名相同）。本应该是无效交易，但却被写入源链并被中继器纳入了AllianceChain的Merkletree并进行了签字，然后发布到AllianceChain区块中。Merkletree用于证明交易的真实性。生成的跨链交易链接如下：（https://explorer.poly.network/tx/1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80） 5. 跨链交易在目标链上调用了PolyNetwork合约的EthCrossChainManager.verifyHeaderAndExecuteTx函数，并包含了Merkle证明，具体解析如上述链接。 6. 这个函数解析了Merkle证明，发现证明是有效的，该攻击交易确实存在于已被签名的Merkletree中。然后调用EthCrossChainManager._executeCrossChainTx函数执行此交易，即调用合约（0xcf2afe102057ba5c16f899271045a0a37fcb10f2）中的method（0x6631313231333138303933），并传入参数args（010000000000000014a87fb85a93ca072cd4e5f0d4f178bc831df8a00b）。由于此method与步骤二中提到的method签名相同（均为0x41973cd9，哈希碰撞），因此顺利执行，将keepers的公钥改成了黑客的公钥。以太坊上的交易链接如下：（https://etherscan.io/tx/0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581） 7. 黑客改变公钥后，便可以随意解锁资产。
对于这次攻击事件的总结如下： 1. 攻击交易在没有充分检查的情况下被写入源链。 2. 中继器会接收任意含有"makeFromOntProof"事件的交易。 3. 中继器将步骤一中的交易发布到AllianceChain上。 4. 在步骤二中，该攻击交易被纳入到AllianceChain的Merkletree中，生成了有效的Merkle证明。 5. 在目标链上，PolyNetwork合约通过步骤二生成的Merkle证明验证了该交易在源链上的存在，并且原始数据未被破坏或修改。但需要强调的是，在构建发送到目标链的Merkle证明之前，应对交易进行全面验证，这也是设计文档中提到的。 6. 目标链（即B链）应使用Merkle证明验证收到的信息未被破坏或改变，交易信息应在发送至目标链之前进行全面验证。
附：Merkletree（https://en.wikipedia.org/wiki/Merkle_tree）是用来验证存储、处理和传输任何数据类型的工具。它可以确保从点对点网络中接收的数据块未被破坏或改变，并且可以检查其他节点是否发送虚假数据。
