主持人：根据资料显示，beacon chain(信标链)与分片之间是通过一种称为交联（Crosslink）的设计进行周期性通信的，能否给大家通俗地解释一下这个设计?

　　杨镇：

　　通俗肯定是做不到了，我尝试尽量简单地解释一下。crosslink 数据中包含了以下几个字段：分片号、信标链上的父区块状态根、开始 epoch、结束 epoch 和分片链上的数据状态根。这里说的状态根，就是状态树的根节点哈希（如果你还不明白这是什么意思，那你大概需要去补补 Eth 1.0 的课了）。epoch 是一个投票周期，大约是 6.4 分钟，也就是 64 个 slot 周期。这样就很容易理解了：crosslink 其实就是某个分片在某个 epoch 结束时的数据状态版不过这里还需要多解释一点儿关于信标链的设计。crosslink 是 attestation data（大概可以译为“见证数据”，也就是由验证者提交的用来证明分片链状态的数据）的一部分，attestation data 则是信标链中区块数据的重要组成部分，所以实际上crosslink 也就是信标链中区块数据的一部分，是用来表示系统的整体状态和用来支持跨片交易操作的关键数据。

　　阿剑：

　　应该可以简单解释成：单分片定期将自己的状态证明存到信标链上，作为跨分片通信所需的密码学证明材料。

　　向丹：

　　再通俗点是否可以理解为：分片时不时需要在信标链上报告状态，crosslink就是分片之间的通关密语。7异步交易VS同步交易

　　主持人：Vitalik用火车旅馆问题来解释异步transaction，并且介绍了一个称为“猛拉”（yank）的解决方案，可以大致讲讲火车旅馆问题，以及这个解决方案的原理吗？

　　张卫家：

　　火车旅馆问题的场景是用户想要购买火车票并预订酒店，并且希望确保操作是原子的，要么保留成功，要么两者都不成功。如果火车票和酒店预订应用程序在同一个分片上，这很容易：创建一个尝试同时进行预订的事务，要么两个预留成功， 要么抛出异常并恢复所有内容。但是，如果两者都在不同的分片上，那就不那么容易了;Vitalik介绍的解决方案是让合同本身可以跨越碎片移动；其中合约可以从一个分片“拉”到另一个分片，允许通常驻留在不同分片上的两个合同临时移动到同一分片，然后进行同步操作。

　　主持人：说到异步交易，自然还有同步交易的概念，Vitalik提到会通过类似Plasma的方法来实现，阿剑老师为我们讲讲这大概是个什么样的思路？

　　阿剑：

　　关于同步型的跨分片交易，目前资料比较少。包括 Vitalik 说的用 Plasma 方式来实现我也不了解。不过我听说过 Viltaik 提出过的另一种同步跨分片交易的模式，叫 Merge Block。大意是让 A 分片的区块附带状态 witness，让 B 分片的验证者可以收到区块及其 witness（技术上来说，B 分片的验证者变成了 A 分片的无状态客户端），然后可以将 A 分片的该区块与 B 分片的区块同时执行。另一种模式是在给定时间内让某分片变成主分片，在该段时间内该分片的验证者可以任意读写其它分片，即其他分片的验证者也优先执行该分片的区块，这样也能创造同步执行。

　　杨镇：

　　补充一句，貌似是用 sparse merkle tree 来做，所以说类似于 plasma（看不懂的童鞋就无视我吧……）8状态租赁：实现起来未必容易

　　主持人：Phase 2阶段对于以太坊2.0平台而言是极其重要的一个阶段，其重新引入了智能合约，每个分片将基于eWASM管理一个虚拟机，此外，状态租赁方案也可能会被引入，这将会带来什么影响吗？

　　阿剑：

　　eWASM 和状态租赁方案的情形我都没有跟进，一无所知。

但状态租赁会明显面临收费问题，不是个简单的问题。有一位非常棒的开发者叫 Alexey Akhunov，就在做状态租赁的研究和 EIP，大家可以关注一下。

　　张卫家：