一、 块主要结构

block 是区块链中最重要的数据结构，EOS 在 block 结构中设计了 7 个参数，
下面我们将一一进行分析解释。

previous

previous 为指向前一个区块的 hash 值，EOS 采用的 hash 算法是 SHA。

timestamp

timestamp 为时间戳，该区块的生成时间。

transaction_merkle_root

transaction_merkle_root 为该区块内所有交易的 merkle 根，用于快速验证交
易的完整性。

producer

producer 为该区块的生成者。EOS 采用 DPOS 共识机制，预计每 3 秒生成一
个区块。任何时刻，只有一个生成者被授权生成区块。

producer_changes

EOS架构中区块的产生是以21个区块为一个周期，在每个出块周期开始前，
21 个区块生成者会被投票选出。producer_change 就记录了未来的 21 个出块者。

producer_signature

producer_signature 是该区块的生成者对该区块的签名。EOS 采用的是 ECDSA
签名算法，使用的椭圆曲线参数是 secp256k1。

cycles

EOS 设计的目标之一是使得两个账户（合约）能够在单个区块内来回交换消
息（交易），而不必在每个消息之间等待 3 秒。为了实现这一点，EOS 将块内的
消息分成了 cycle 来顺序处理。cycles 就是 cycle 的一个顺序向量，那么 A 发给 B
的消息在 cycles[1]中处理，B 返回的消息就可以在后续的 cycles[4]中进行处理。
区块生成器将不断把 cycle 添加到区块中，直到最长的区块时间间隔达到，或者
没有新的可传送交易生成。

二、 Cycles 主要结构

前面提到了 EOS 为了提升消息交互的效率，在 block 中设计了 cycle 结构来
实现了一条“小链”。而在 cycle 内部，EOS 设计了 threads 来实现消息、交易的
快速并行处理。

相比较 cryptonomex 中的设计，EOS 的这种设计将更好的支持高并发管理，
利于提升 EOS 的整体效率。

generated_input

generated_input 包含了一组 GeneratedTransaction 的 id，用于顺序查找和处
理 GeneratedTransaction。我们将在后面对 transaction 的类别进行详细的解释和
分析。这些 transaction 将被顺序处理。

user_input

user_input 包含了一组 ProcessedTransaction，这些是已经被处理过的交易。

thread

不同的 thread 将会根据主机的实际情况被并行处理。在同一个 cycle 内，当
两笔交易 A 和 B 同时涉及到同一个账户时，这两笔交易将会被放在同一个 thread
下进行处理。

三、 Transaction 结构

EOS 中主要使用三种 transaction 结构。其中 SignedTransaction 是由用户发出
的交易请求，ProcessedTransaction 是由区块生成者处理完用户发出的交易请求后
生成的交易实体，GeneratedTransaction 是由区块链生成的交易请求，特别的是由
智能合约生成的交易请求。

Transaction

Transaction 作为所有 transaction 的父类，包含了 5 个参数。refBlockNum 用
于指定之前的一个块，其中将包含一个由该交易签名者申明的已知状态申明，作
为该交易执行的上下文。refBlockNum 只使用 16 个 bit，所以只能回溯到两天前
的 65,536 个块。refBlockPrefix 就是被指定的块的 hash 的前 4 个字节（32 个比
特）。expiration 给出了交易的内存过期时间，这样将保证节点的内存不用保存过
多的交易。
scope 内将记载此次交易涉及到的账户信息。
messages 内将记载此次交易的实质内容，它可以包含多个消息。在设计上，
只有所有的消息都被接受了，整个交易才会被接受，任何一个消息被拒绝都会导
致此笔交易失败。这些消息将会在同一个线程里面顺序执行，因此将多个消息放
到一笔交易里面在性能上并不理想（比如同时给两个人转账）。而且 EOS 会根据
交易涉及到的用户数量数来收取手续费，因此涉及到多个账户的交易的时候，最
好采用原子交易来进行（每笔交易只包含一个接收账户）。

SignedTransaction

SignedTransaction 比 Transaction 多了一个参数 signatures，将用于保存用户
对该交易涉及的所有签名，每一个 message 至少对应一个 signature。
ProcessedTransaction
ProcessedTransaction 比 SignedTransaction 又多了一个参数 output，用于记录
对用户发出的 SignedTransaction 进行处理后的输出。特别的，这个输出包含一条
或多条交易信息 GeneratedTransaction。

GeneratedTransaction

GeneratedTransaction 是由区块链生成的交易，比如智能合约。它 比
Transaction 多了一个参数 id，用于方便查找到该交易。

值得注意的是，因为这个交易是由区块链（智能合约）产生的，它可以用于
EOS 上不同应用间的通信。但又是因为它由区块链（智能合约）产生，因此它并
不含有签名，所以它的验证必须要连同触发产生该交易的智能合约的交易一同被
验证。
例如，当多家大宗交易所、普通用户向 OraleChain（智能合约）提交了目前
的猪肉价格（以 SignedTransaction 形式）后，OraleChain 根据自己的 PoRD 机制
计算得到一个可信猪肉价格， 然 后 连同所有搜集到的价格 生成一个
GeneratedTransaction ，作为最后一个提交价格 的交易的处理结果
ProcessedTransaction 的输出信息，发送给另一个智能合约 AgriculturalInsurance，
AgriculturalInsurance 就可以根据这个可信猪肉价格进行保险赔偿等智能操作。
正是这样的巧妙设计，实现了 EOS 上不同的智能合约间的通信，也就是我们
常说的跨链，这将极大的丰富 EOS 的生态圈，为开发者开发更丰富的应用提供了
可能。

四、 Message 结构

Message 用于记录交易的主要内容，包含了 4 个参数。
code
code 指向了执行这个消息的智能合约。比如“eos”是指 EOS 自身自带的智
能合约，在前面系列指南里进行 eos 转账的操作，出发的就是这个合约。
type
type 指向需要执行的智能合约里的方法，比如“eos”里面的转账操作
“transfer”。
authorization
authorization 记录了处理该消息所需要的权限。EOS 里面目前设计了三种权
限：owner、active 和 recovery。owner 权限可以做所有事情，active 权限可以做
出了更改所有者之外的所有操作。recovery 可用于 EOS 用户在密钥被盗时恢复其
账户控制。
data
data 里面则存储了这个消息的其他参数。

五、 MessageOutput 结构

当智能合约处理一笔 SignedTransaction 时，有可能会生成一笔新的交易
GeneratedTransaction，它将被存储 MessageOutput 结构体中。
MessageOutput 包含了被通知对象集合 notify，在完成通知以后被应用了的
ProcessedTransaction 集合 sync_transactions，以及由智能合约生成的不带签名的
交易 GeneratedTransaction 集合 async_transactions。
通知对象集合结构 NotifyOutput 里面包含了被通知的对象 name 和一个输出
消息 MessageOutput。这和前面形成了一个嵌套关系，因为被通知的对象（合约）
还有可能生成新的交易，如此递归下去。
由于 EOS 代码中对 MessageOutput 和 NotifyOutput 的处理还没有完全完成，
我们会在后面的系列文章中做更详细的解释和分析。

六、 总结

EOS 在块内设计了 cycle 结构，实现了块内的通信，这样账户（合约）之间
的通信将变得更加快捷。
在设计上，EOS 是模块化的，每个人不应该运行所有的东西，因此不能假定
另一个账户（合约）的状态在同一台机器上是可访问的，这就意味着如果允许一
个合约同步调用另一个合约，但如果这个合约不在内存中，系统将会崩溃。因此，
EOS 要求所有账户间的通信都必须通过区块链上的交易进行传递。
为了实现跨链机制，EOS 特别设计了不带签名即可完成验证的交易机制，这
种验证是通过状态信任链来完成的：第一个带签名的交易触发合约产生了第二个
不带签名的交易，该交易又顺序产生了第三个不带签名的交易，依次下去，最后
所有的交易的验证都依赖于第一个交易的签名，和每一次合约执行后的状态。
从对 EOS 块数据的分析，我们可以看到 EOS 在设计上就已经考虑了高速、
融汇、跨链等区块链未来的发展方向，我们有理由相信 EOS 代表了区块链的一种
新的未来。
转载自oraclechain