今天简单聊聊跨链通讯的主题。因为下午要去机场，今天提前发文，还请等待的老铁们见谅了。
昨天看到了EOS Cafe 针对主网TPS的一个澄清：
节点 EOS Cafe 今日在电报群提醒： eosnetworkmonitor.io 所显示的主网 TPS 数据是虚假的，其中大多数是过时的、非真实的交易，EOS 主网至今最高的 TPS 仍是 3,996，并未创新高。
而在跨链通讯(IBC)实现之前，EOS的百万TPS甚至无限TPS的扩展无法实现，因为就EOSIO而言，TPS的提升，是需要依赖多条侧链的出现，且，侧链和主链之间能够无缝通讯进行交易互认，才有可能做到。简言之，tps提升靠侧链，侧链出现的前提，是IBC的实现。
BB的声音
而在BlockOne的CEO BB 1月17日发文称：计划在处理完已知问题后发布EOSIO路线图。针对产品开发进度、参与治理、信息公开等问题，做了解释。也提及了社区所关注的跨链通讯的信息:
我们对于EOSIO链上的总价值非常敏感名，我们的团队加班加点，以解决自6月发布EOSIO软件依赖所产生的问题，并满足需求，以及，围绕跨链通讯(IBC)等未来计划的研发和实施。 EOSIO软件一开始就设计于此。
那么， BB所提到的EOSIO软件中，针对IBC所作出的基础支持，是什么？
EOSIO白皮书中，就IBC说了什么？
就我所看到的资料而言，EOSIO白皮书中所列出的对于EOS跨链的部分，值得一读。
之前我翻译了一个版本，可以参考阅读：EOSIO白皮书 2.0
主要分为几个部分：
- 应用程序的并行执行
- 上下文无关的Action
- 跨链通讯的构想
应用程序的确定性并行执行
如今，EOSIO软件为单线程运行。白皮书提到说：包含了未来需要进行多线程和并行执行所用到的数据结构。
在并行执行的功能开启后，出块节点会将指令(Action)加入到Shard(分片)中，以便进行并行的验证评估。出块节点会进行排程，并被确定性地执行，但是，在排程的过程中，不一定是确定性的。我的理解是说，在将Action加入到Shard之中的时候，这个过程称之为排程。
简单介绍下什么叫做分片(Shard):
image.png
按照EOSIO白皮书的设想，会在事务(transaction)之上，加入一个结构称之为：Shard，可以理解为是一组事务的集合，而Shard跟Shard之间，可以同时并行运行。
当前，在EOS主网上面，还没有启用这一设计。
在分片之上，还加入了周期(cycle)这一数据结构的设计，一个周期，可以包含多个分片，而一个周期跟另外一个周期之间，是顺序执行的，先执行完一个，再执行另外一个。
例如，你在一个分片之中的操作，跟另外一个分片的操作，是并行的；而这两个分片都可能会加入到同一个周期之中，这样，可以在一个周期之内将你的相关操作，都一起执行了。
多个周期，组成了一个区 (Region), 而Region，则是组成区块的数据结构。
通过这种方式，EOSIO为实现未来的多线程运行提供了数据基础。当然，如上介绍还只是设想，当前据我有限的了解，只是有block, transaction, action的三层结构。
上下文无关的Action
这部分，直接引用白皮书的介绍：
上下文无关的动作(Action)涉及到这样的计算: 只依赖事务的数据，而不依赖区块链的状态。例如，签名验证的计算，只需要事务数据和签名来确定签署该事务的公钥。这是区块链上必须执行的最昂贵的计算之一，但是因为这一计算是上下文无关的，所以可以并行执行。
上下文无关 Action 就像其他的用户Action一样，只是它们无法访问区块链状态来执行验证。这不仅能使 EOS.IO 可以并行处理所有上下文无关的动作(Copntext Free Actions)，例如签名验证，更重要的是，这为通用的签名验证提供了支持。
在支持上下文无关动作(Context Free Actions)的情况下，可伸缩性技术如Sharding、Raiden、Plasma、State Channels等，变得更加可并行化，实用性更强。这一发展可以实现高效的跨区块链通信和潜在的无限可扩展性。
跨链通讯的构想
EOSIO对IBC的促进，是通过两个部分来设计实现方案的：
- Action存在证明
- Action的顺序证明
这两部分的证明过程，设计了简化。这些证明与围绕Action 传递而设计的应用架构结合起来，EOSIO的设计者，希望将跨链通讯以及验证证明的细节对应用的发者隐藏，展现给开发者高层次的抽象，而不需要普通的开发者来操心验证的细节。
用于轻客户端验证的Merkle证明(LCV)
image.png
如果客户端不需要处理所有的事务(transaction), 那么，与其他区块链交互将变得非常容易。毕竟，一个交易所只会关注交易所的出账和入账信息，而不会关心其它。更理想的情况是，对于交易所自身所维持的链来说，如果可以将轻量级的默克尔存款证明应用其中，那么就不必完全依赖自己的区块生产者。至少，某个区块链的生产者在同步另一条区块链时，会希望尽可能减小开销。
LCV的目标是能产生相对轻量级的交易存在证明，其他人只需要追踪一个相对轻量级的数据集，就可以对此进行验证。既然如此，目标就是证明一笔特定的事务被一个特定的区块所包含，并且 某一条特定的区块链的验证历史中，已经包含了该区块了。
以上，只是一些概略介绍。
社区进展
顺带说下社区的进展。在当前EOSIO提供正式的IBC方案之前，我看到社区团队也有在探索IBC的方案了。
此前见过的：
- Cochain基于中继网关模式，来设计IBC
- BOS，最近新启动并激活的区块链，也是基于EOSIO启动的。其代码库中有一个ibc插件，粗略看了一眼，提到说启用了上文所说的Shard的结构，更多细节，后面跟大家分享。
另外，顺带一说，BOS最近提到的计划称2周内会上线IBC的方案，实际上，还只是跨链的资产通过中继网关的方式来实现互转。 - MeetOne的链，采用同名账号的设计方式，进行资产互转。也是中继账号的方式来做。
总之，目前受到EOSIO软件仍然未能实现IBC模块的限制，社区的探索几乎都是只能通过中继账号的方式来做。
更多细节我们后面接着聊。感谢阅读。
网友评论