1. 跨链交互
简化消息存在证明和消息序列证明。
2. 轻客户端验证的默克尔证明(LCV)
一个更加理想的状态是，对于交易所自身所维持的链来说，如果可以将轻量级的默克尔存款证明应用其中，那么就不必完全依赖全节点矿工，全节点矿工同步时也能维持尽可能小的开销。
2.1 目标
能产生相对轻量级的交易存在证明，并且该证明能被其他人通过跟踪一个轻量级数据集进行验证。既然如此，目的就是证明一个特定的交易是被一个特定的区块包含其中，并且这个区块是被包含在已经验证的特定区块链历史中。
2.2 EOS vs Bitcoin
-
比特币：假设所有节点都有读取区块头数据完整记录的能力。而区块头数据每年增长4MB， 假设每秒产生10笔交易，一个有效的证明需要512 bytes，这对于一个出块时间为10分钟的区块链来说是可行的。但对于一个出块时间为3秒的区块链来说则远远不够。
-
EOS：只需要验证包含某个特定的不可逆交易之后的区块头数据，使用哈希链表架构（如下图），数据集可以保持在1024 bytes内，即可证明任何一个交易是否存在。这是基于验证节点保留着前一天的所有区块头数据（2 MB大小)，然后证明这些交易只需要200 bytes大小的证明数据。
-
当生成区块时候使用合适的哈希链表时，使用这种方法只会带来很小的增量开销，这意味着没有理由不以这种方式去生成区块。
-
当与其他链验证证明的时候，时间、空间和带宽都有很大的优化空间。跟踪所有区块头数据(420 MB/年)可以使证明体积尽可能小。只跟踪最近的区块头可以使得在持久区块头数据保存体积以及证明体积之间获得平衡。
-
一个区块链可以“懒惰地”只记录过去数据的哈希值作为之前数据的证据，新证明只需要保留已知的sparse tree（稀疏树）结构，具体的方法会视乎于外部区块所占的默克尔证明所包含的交易比例。
在链与链之间经过一定密度的相互关联之后。他们将会变得越来越高效。一条链可能会包含另外一条链的全部历史记录，那么就不再需要互相证明。从性能的角度来说，这将极大地减少链间互相证明操作的频率。
3. 跨链通信延迟
-
其他区块链：通信的时候，矿工必须等待其他区块链不可逆地确认之后才会接受其为有效的输入。
-
EOS系统：凭借出块时间为秒的委任权益证明以及21个矿工，这大概只需要45秒的确认时间。如果某个链上的矿工不等到交易确认，就像一个交易所接受了一笔存款而后又撤销这笔操作，这会影响这条链共识的有效性。
4. 完成证明
-
使用外部区块链的默克尔证明：知道所有已处理的交易是有效的和知道有没有交易被忽略，这两者之间有巨大的不同。因为不可能证明所有最近交易是已知的，但有可能证明历史交易数据之间没有缺失。
-
EOS：通过分配一个顺序的标识编号给每一笔到达账户的信息来完成这个功能，用户可以使用这些标号来证明所有给这个账号的消息已经被处理并且是被按顺序处理的。