Wormhole协议采用了Proof-of-Burn（PoB）机制进行Bitcoin Cash与Wormhole Cash之间的兑换。有人会好奇这个地址到底是如何选取出来的，本文就如何选取Wormhole燃烧地址的细节做一下介绍。
Wormhole团队在选取燃烧地址时，通过以下几个原则来筛选：
1.无人拥有该地址的公私钥
2.该地址从未被使用过
3.该地址以whc结尾，具有鲜明的Wormhole协议特色
Wormhole团队是如何选择燃烧地址的
Wormhole团队在选取燃烧地址的时候，是通过不断迭代的方式选出燃烧地址的，我们选取燃烧地址的代码开源在这里,任何人都可以运行这段代码查看结果。下图为选取燃烧地址的核心代码片段：
这段代码可以分为两部分来看，第一部分如下图：
这段代码主要功能是从0开始，以步长为1不断叠加的方式来构造地址，因为NewCashAddressPubKeyHash函数需要传递一个20个字节的pkHash（该函数具体实现可点击这里查看），所以通过内层的for循环构建出的result是一个40个字符的16进制数，对一个字节进行16进制编码需要用2个字符来表示，所以40个字符的正好是20个字节的16进制编码，再将得到的结果作为参数传递给NewCashAddressPubKeyHash函数就得到一个Bitcoin Cash地址。然后来到第二段代码筛选出符合要求的地址：
第一个if条件判断生成的地址是否以whc结尾，符合这样条件的地址总共有300个（太多就不贴出来了），第二个if和第三个if用来筛选该地址后缀是不是8whc，符合这样条件的地址总共有9个：
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqp5fmqjgec8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqxkqxc0pml8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqtwhhu7krj8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqvv72yrlp48whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqq3hsu5436g8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqk4epvgcc08whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqmdwsge0qz8whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqppgv4s588t8whc
第四个if用来筛选后缀是[0-9]8whc的地址，这样的地址总共有三个：
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqvv72yrlp48whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqk4epvgcc08whc
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc
为什么一定要选后缀是8whc的地址？因为数字8在中国文化中是一个Lucky Number，所以我们期望找一个后缀为whc并且前面跟数字8相关的地址，但是符合这个限定条件的只有上述三个满足，就像选车牌一样，人们总是喜欢选一个自己喜欢的数字和字母的组合，所以我们在这三个地址选定了qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc作为燃烧地址。
对CSW博士错误观点的修正
CSW博士在medium上发表了一篇文章，我们发现这篇文章中两个地方的描述是完全错误的。
1、分割出地址的Checksum
我们可以看一下在CSW博士的描述中，他是如何分割出Checksum的
可以看到这个地址一个经过Base58编码得到的BCH的地址，对该地址来说是不能直接这样分割出Checksum的，这是众所周知的事情，CSW博士文章中这种描述真是令人贻笑大方，在讲正确的分割方法之前我们先来了解一下什么是Base58编码。
什么是Base58编码
Base58是在Bitcoin中使用的一种独特的编码方式，主要用于产生Bitcoin的钱包地址。相比Base64，Base58不使用数字"0"，字母大写"O"，字母大写"I"，和字母小写"l"，以及"+"和"/"符号。设计Base58主要的目的是：
1.避免混淆。在某些字体下，数字0和字母大写O，以及字母大写I和字母小写l会非常相似。
2.不使用"+"和"/"的原因是非字母或数字的字符串作为帐号较难被接受。
3.没有标点符号，通常不会被从中间分行。
4.大部分的软件支持双击选择整个字符串。
Bsae58编码的具体实现是：
1. 将待编码的字节数组表示为一个大整数；
2. 该整数除以58，其余数作为base58字符表的索引，获得相应的字符，保存到字符串中；其商继续除以58，取余再次获得一个字符，追加到上述的字符串中；重复以上步骤，直至商为0；
3. 对于以字节0开头的待编码字节数组，向上述字符串末尾追加相等数量的字符 '1' (直至遇到第一个不为0的字节)；
4. 然后将所得的字符串倒序表示，即是最终结果。
核心代码如下图所示：
如果你想看客户端中对Base58的详细实现过程，请点击这里源码中对Base58的实现逻辑和上图所示的代码逻辑是一致的。
Checksum正确的分割方式
按照CSW博士在文中描述的方式分割出Checksum，对分割出的两部分分别进行Base58解码得到的结果为：
00-00000000000000000000000000000000000CD9CF-0361022C67
这个结果显然是错误的，而按照正确的分割逻辑，1111111111111111115KMYP7R278如果要分割出Checksum，首先要对其先进行Base58解码，1111111111111111115KMYP7R278经过Base58解码后相应的十六进制表示为：
00-000000000000000000000000000000000071E76C-501B5A27
按照传统地址规范，第一个字节的00表示版本号，最后的4个字节501B5A27才是Checksum。
2、可以通过亚马逊集群服务器逆推出地址的私钥
在CSW博士文章中他是这样说的：
按照CSW博士的说法，那现在所有的基于椭圆曲线加密算法的数字货币都是不安全的，都可以通过所谓的“any Amazon cluster”破解，这种说法显然是站不住脚的。Wormhole燃烧地址所包含的 160比特哈希值的十六进制表示为
000000000000000000000000000000000071E76C
观察可知，该160比特的哈希值最左侧的137个比特位全部为零。如果这是开发团队精心构造出来的地址，则构造的过程需要遍历pubkey直到RIPEMD160(SHA256(pubkey))的输出的最左侧的137个比特位全部为零。这一过程跟BCH网络的PoW求解非常相似:通过大量穷举尝试，使获得的哈希值的最左侧的一些比特位为零。以当前(2018/09/12)的块高度541027为例，块哈希的十六进制表示为:
000000000000000002712253f9230d6e1f98c8071e98e197423d6cd285c8800
最左侧的共有68个比特为零，根据PoW机制可知，为获得该块矿工大约尝试了2^68 次计算。同样，要求最左侧的137个比特位全部为零，需要Wormhole开发团队尝试大约2^137 次哈希计算。这是个什么样的概念呢？现在BTC全网算力是51.14EH/s,BCH全网算力总共是3.99EH/s，加起来是55.13EH/s，也就是说现在BTC和BCH全网合起来每秒可进行5.513x10^19 次Hash运算，那以现在BTC和BCH全网算力总和来计算 2^137 次Hash需要多少时间呢？我们很容易得出结论：
T(年) = 2^137 / 55.13×10^18 ≈ 2.5×10^10(年)
可以看到这个计算需要大约250亿年的时间能完成，宇宙迄今为止才有大约137亿年 [1]，这是时间上的不可能。另外从耗能的角度来说，我们这里以S9 Hydro矿机为例，S9 Hydro的功耗为1728W，算力为18T [2]，也就是说1秒钟计算18万亿次Hash耗能是1728J，那么运算一次Hash需要消耗的能量是：
W = 1728 / 1.8×10^13 ≈ 9.6×10^-11(J)
那么要计算2^137 次Hash总共消耗的能量是：
W = 9.6×10^-11 × 2^137 ≈ 1.3×10^31(J)
要知道太阳一百亿年总共才释放了1.12×10⁴⁴ 焦耳的能量[3]，从而也说明要计算2^137 次Hash在耗能上也是不可能的。关于计算2^137 次Hash的难度，我在这只给大家一些直观上的感受。具体的Wormhole燃烧地址的安全性，我们之前已经有过详细的讨论，感兴趣的同学可以点击这里查看。
Wormhole团队的初衷是为BCH网络增加更先进的功能，为整个BCH网络生态繁荣贡献自己的力量，纵然有各种各样无端的质疑，我们也会不忘初心砥砺前行。
References
-
https://en.wikipedia.org/wiki/Age_of_the_universe ↩
-
https://shop.bitmain.com/product/detail?pid=00020180911132006680AinyTiI406BB ↩
-
https://www.bp.com/content/dam/bp/pdf/energy-economics/statistical-review-2016/bp-statistical-review-of-world-energy-2016-full-report.pdf ↩