闪电网络中的洋葱路由
每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
保护隐私的去中心化小额支付
视频点介里：https://www.youtube.com/watch?v=Gzg_u9gHc5Q#t=2m44s
保护隐私的去中心化小额支付
闪电是个样银有点兴奋的概念，layer 2或许是改善隐私、可替代性的一亩要地。
引用洋葱路由paper：分布式洋葱路由器，也叫OR，是用户联合一干子节点创建的环路。 洋葱路由器难以获取路径中上家下家以外的信息。特点是低延迟、大网环境中可用等。比较成功的路由节点是Tor。
闪电网络的目标包括：隐私、抗审查等。 使用源路由，意味着整个route都由源指定。 原因是用户希望对费用多少、路由路径、时间锁等心中有数。
Sphinx用来创建一种可证的安全混合格式， 同时集各种优势于一身。 保持大小固定不变，在运输和映射中非常重要。因为固定大小不会提供位置信息。
Sphinx走的是共享秘密的路线。 为实现不可链接性，需要随机化三方或多方的基础密钥。 程序包中可以有n个密钥，也可以来一波RSA之类的操作，然后就是千字节的数据包， 因为需要掌握全部共享秘密。 这个技巧还是非常炫酷的，可以推广到任何协议中，像是椭圆曲线、RSA等等。
首先，获取会话的会话密钥，然后获取路由中所有公共节点列表。 好比a0是第一跳的初始公钥，然后导出共享秘密0。公钥升秘密至秘密的指数幂，出现盲因子。 每个中间节点使用盲因子来随机化下一跳的公钥。 a1是g^x^b0。
总结起来就是：节点先从共享秘密中导出一个盲因子，然后使用导出的盲因子随机化下一跳。 每一跳都有一个恒定大小的密钥，从而实现了不可链接性。
Sphinx中，简化了数据包处理。但是需要预防重放攻击。具体来说，就是使用新的盲因子重新随机化共享秘密。
开发者对Sphinx的一些修改尝试包括：添加些闪电功能、在header上添加一个版本字节等。开发者还添加了公钥，而且MAC现在遍布整个数据包，但是闪电本身还没有回复用例。为提速，还将算法从AES切换到chacha20。另外，还有有效载荷，可以为跳跃附加指令。好比，若一个链接有多个链接时，应该使用哪一个？指令包含指导链接以及其他如时间信息等信息。
目前的话，代码已经写出来了。可以启动一个有新交易传播机制的mixnet。
性能考量
两行代码上有两个星号; 这些是用于转发HLTC的非对称加密操作，意思是说每次（跳）就这些操作。洋葱路由器本身需要维持每次会话状态（哈希、传入链接和实际链接）。 也就是说路由器需要保持这种状态，然后将其转到下家。若忘记了状态，拿着结款也不知道该给谁转过去。意思是忘了状态就相当于忘了HLTC。 也就是说这算是DoS攻击了。所以说状态是要存储到磁盘的。
假若能克服这些限制，那么于运行速度来讲会快很多，于路由器来说更是无状态的厉害一匹了。
大黄蜂
大黄蜂是是Sphinx的延伸，克服了S的一些不利因素，或者说，是Sphinx的升级，目标是互联网规模。 具体而言大黄蜂干了两件重要的事情：首先，摘除了数据转发关键路径中的非对称加密操作。初始设置阶段，获取对称密钥，然后进行快速对称加密操作；其次，创建了双向回路。Sphinx属于设置然后忘记，而大黄蜂是实时的。
大黄蜂最初使用sphinx来导出共享秘密，这个秘密在后面允许中间节点将特殊密钥放入数据包中，而数据包则用于数据转发。大黄蜂的好处是节点只需要保持恒定状态，由数据包携带所有状态。 所以状态被推送到的是端点而非中间节点。 这里边重要的地方是匿名header。 转发段由节点加密，且只能由加密节点解密。转发段包含路由信息，如下行路线以及用来避免重放攻击的部分会话信息。
节点的工作就是维护自己的对称密钥、解密数据包然后继续转发。
大黄蜂也可以助力闪电的支付流程。一般都假设支付流程是带外的。 好比，Alice 和 Bob想通过闪电发送付款。Tor能不能用？是不是要提前交流下？另外，转账可能不止一次，所以需要来回交流等等。那么，可以将这种通信移入网络。假设Alice 和 Bob之间有路径。 Alice可以创建一个大黄蜂会话。因为链接是双向的，所以俩人能自由交换各种细节。
一些链接的容量不足，不能一次性发完所有内容的时候，也可以将支付分成几块同时在几条路径下发送。
共享秘密日志
维护共享秘密很重要的一点是拒绝再次发送的数据包。那么为了能该出手时就出手，就需要有个不断增加（同步）的共享秘密日志，看见有跟日志记录一样的数据包，果断决绝。但是有个问题是什么呢，说我想维护终生的共享秘密，那可老鼻子了。 因此需要选择性的处理掉一些东西。密钥轮换就是一种可用手段。具体的实施方法有若干：Tor中有个中央目录服务器，所有人都上传自己的密钥和新的签名密钥。这么做本来也无可厚非，但是闻起来确实也是有点中央权威的味道。 有鉴于此，可以在密钥轮换上搞点特殊。 好比， 假设节点有身份密钥，可以使用身份密钥认证自己的洋葱密钥。 那么，节点可以每天向网络广播一个新密钥。点是什么呢，说轮换的同步需要以一种松散的调调进行。 若Alice有轮换密钥，但是Bob却用旧密钥发送付款，那么这个MAC看上去像是无效的，Alice只能拒绝。因此，需要有个宽限期，好比Alice已经轮换几次密钥了，但还是有人发送旧数据包。所以Alice最好是用新、旧密钥挨个检查一遍，保不齐人家真不是骗子。
主动密钥轮换实际上鼓励更高的带宽， 好比每24小时轮换一次这种，那么对于百万节点网络来说，要下载的数据量还真蛮大的诶。
被动密钥轮换
我们知道BIP32层级确定性钱包，里边讲了主公钥子公钥主私钥子私钥。。。看上去厉害的一匹。但是，他有个问题是，拿到主公钥和子私钥，就能搞来主私钥。
我们施些加密魔法，解决下这个问题。
被动密钥轮换，可以进行配对加密并启用被动非交互式轮换。也就是说分三个循环组，进行双线性配对，使用更有意义的标识符。
现在，每个节点都会公布一个主公钥。常规IBE中，有个可信代理将公钥分发给其他人。可以让节点成为可信代理来执行实际协议。 还需要一个叫做哈希函数的新原语。 哈希函数直接映射到曲线上的一个点。 可以迭代地执行此操作，好比有个字符串，哈希一下，然后得到曲线上的点（输出）。
如何将某些东西映射到非标识点或无穷大元素的点？每个人都有个ID，这个ID其实是这是一个区块哈希。 ID是一个组元素，一个公钥。因此，给定一个区块哈希，可以导出另一个公钥，也是一个组元素。因此可以实现非交互式密钥轮换。 Alice知道其他节点的密钥轮换计划。因此，可以导出共享秘密。Alice用Bob的主公钥，生成当前的会话密钥，可能还有一些盲因子。 Bob与自己的私钥进行配对操作。反正到最后，Alice跟Bob都到达了共享秘密，即被动密钥轮换完成。
方案的瓶颈
考虑这样这些问题，路径高度多样，也就是说Alice到Bob有十万种走法，跟单一路径，哪一个更好判断出一些事情？ 再或者，根据支付价值来判断，好比知道其他链接不会支持某种规模的支付，那么支持这种支付的路径肯定是Alice跟Bob再用。那么，一旦某人推出来Alice跟Bob间的转账路径，则可实施定时攻击。
展望未来
性能、延迟、有效载荷结构、隐私，这一些列因素间的关联复杂且深刻。
或许找得到最佳答案，或许在权宜中永生。
洋葱路由规范：https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-July/000557.html
闪电网络洋葱路由协议：https://github.com/cdecker/lightning-rfc/blob/master/bolts/onion-protocol.md
https://github.com/lightningnetwork/lightning-onion
https://github.com/cdecker/lightning-onion/tree/chacha20
https://scalingbitcoin.org/transcript/milan2016/onion-routing-in-lightning
