Deep-understanding-of-intelligent-contracts

参考官方文档进行进一步了解。

智能合约能干什么

在各业务彼此进行交互之前，必须先定义一套通用的合约，其中包括通用术语、数据、规则、概念定义和流程。将这些合约放在一起，就构成了管理交易各方之间所有交互的业务模型。

_智能合约用可执行的代码定义了不同组织之间的规则。_应用程序调用智能合约来生成被记录到账本上的交易。
在上图中，我们可以看到组织  ORG1  和  ORG2  是如何通过定义一个  car  智能合约来实现  查询、转移  和  更新  汽车的。来自这些组织的应用程序调用此智能合约执行业务流程中已商定的步骤，例如将特定汽车的所有权从  ORG1  转移到  ORG2。

智能合约&链码

通常，智能合约定义的是控制世界状态中业务对象生命周期的交易逻辑，随后该交易逻辑被打包进链码，紧接着链码会被部署到区块链网络中。可以将智能合约看成交易的管理者，而链码则管理着如何将智能合约打包以便用于部署。

一个智能合约定义在一个链码中。而多个智能合约也可以定义在同一个链码中。当一个链码部署完毕，该链码中的所有智能合约都可供应用程序使用。
从上图中我们可以看到，vehicle 链码包含了以下三个智能合约：cars、boats 和 trucks；而 insurance 链码包含了以下四个智能合约：policy、liability、syndication 和 securitization。以上每种智能合约都涵盖了与车辆和保险有关的业务流程的一些关键点。在本主题中，我们将以 car 智能合约为例。我们可以看到，智能合约是一个特定领域的程序，它与特定的业务流程相关，而链码则是一组相关智能合约安装和实例化的技术容器。

账本

以最简单的方式来说，区块链记录着更新账本状态的交易，且记录不可篡改。智能合约以编程方式访问账本两个不同的部分：一个是区块链（记录所有交易的历史，且记录不可篡改），另一个是世界状态（保存这些状态当前值的缓存，是经常需要用到的对象的当前值）。
首先，世界状态是一个数据库，它存储了一组账本状态的当前值。通过世界状态，程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来计算当前值。默认情况下，账本状态是以键值对的方式来表示的。因为我们可以创建、更新和删除状态，所以世界状态能够频繁更改。
其次，区块链是交易日志，它记录了促成当前世界状态的所有改变。交易被收集在附加到区块链的区块中，能帮助我们理解所有促成当前世界状态的改变的历史。区块链数据结构与世界状态相差甚远，因为一旦把数据写入区块链，就无法修改，它是不可篡改的。

账本 L 由区块链 B 和世界状态 W 组成，其中世界状态 W 由区块链 B 决定。我们也可以说世界状态 W 是源自区块链 B。
智能合约主要在世界状态中将状态写入（put）、读取（get）和删除（delete），还可以查询不可篡改的区块链交易记录。

• 读取（get） 操作一般代表的是查询，目的是获取关于交易对象当前状态的信息。
• 写入（put） 操作通常生成一个新的业务对象或者对账本世界状态中现有的业务对象进行修改。
• 删除（delete） 操作代表的是将一个业务对象从账本的当前状态中移除，但不从账本的历史中移除。

智能合约有许多可用的 API。但重要的是，在任意情况下，无论交易创建、读取、更新还是删除世界状态中的业务对象，区块链都包含了这些操作的记录，且记录不可更改 。

世界状态

世界状态将业务对象属性的当前值保存为唯一的账本状态。这很有用，因为程序通常需要对象的当前值，如果遍历整个区块链来计算对象的当前值会很麻烦——从世界状态中可以直接获取当前值。

一个账本世界状态包含两个状态。第一个状态是： key=CAR1 和 value=Audi。第二个状态中有一个更复杂的值：key=CAR2 和 value={model:BMW, color=red, owner=Jane} 。两个状态的版本都是 0。
账本状态记录了一组与特定业务对象有关的事实。我们的示例展示的是 CAR1 和 CAR2 这两辆车的账本状态，二者都各有一个值和一个键。应用程序可以调用智能合约，该合约使用简单的账本 API 来获取、写入和删除状态。注意状态值可以是简单值（Audi…），也可以是复合值（type:BMW…）。经常会通过查询世界状态来检索具有某些特定属性的对象，例如查找所有红色宝马汽车。
应用程序提交那些会更改世界状态的交易，这些交易最终被提交到账本区块链上。应用程序无法看到 Hyperledger Fabric SDK（软件开发工具包）设定的共识机制的细节内容，它们能做的只是调用智能合约以及在交易被收进区块链时收到通知（所有被提交的交易，无论有效与否，都会被收进区块链）。Hyperledger Fabric 的关键设计在于，只有那些受到相关背书组织签名的交易才会更新世界状态。
您还会注意到，每个状态都有一个版本号，在上面的图表中，状态 CAR1 和 CAR2 都处于它们的初始版本 0。版本号是供 Hyperledger Fabric 内部使用的，并且每次状态更改时版本号会发生递增。每当更新状态时，都会检查该状态的版本，以确保当前状态与背书时的版本相匹配。这就确保了世界状态是按照预期进行更新的，没有发生并发更新。
最后，首次创建账本时，世界状态是空的。因为区块链上记录了所有代表有效世界状态更新的交易，所以任何时候都可以从区块链中重新生成世界状态。这样一来就变得非常方便，例如，创建节点时会自动生成世界状态。此外，如果某个节点发生异常，重启该节点时能够在接受交易之前重新生成世界状态。

区块链

世界状态存储了与业务对象当前状态相关的事实信息，而区块链是一种历史记录，它记录了这些业务对象是如何到达各自当前状态的相关事实。区块链记录了每个账本状态之前的所有版本以及状态是如何被更改的。
区块链的结构是一群相互链接的区块的序列化日志，其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作。

在这里，官方提到了一个排序服务。
其中重要的是区块排序以及区块内的交易排序，这一机制是在 Hyperledger Fabric 的排序服务组件首次创建区块时被建立起来的。

每个区块的头部都包含区块交易的一个哈希，以及前一个区块头的哈希。这样一来，账本上的所有交易都被按序排列，并以密码方式连接在一起。这种哈希和链接使账本数据变得非常安全。即使某个保存账本的节点被篡改了，该节点也无法让其他节点相信自己拥有“正确的”区块链，这是因为账本被分布在一个由独立节点组成的网络中。
区块链总是以文件实现，而与之相反的是，世界状态以数据库实现。这是一个明智的设计，因为区块链数据结构高度偏向于非常小的一组简单操作。第一项操作被放在区块链的末尾，就目前来说，查询操纵相对少见。

当应用程序需要访问账本和链码的时候，他们总是需要连接到 Peer 节点。Hyperledger Fabric SDK 将这个操作变得非常简单，它的 API 使应用程序能够连接到 Peer 节点，调用链码生成交易，提交交易到网络，在网络中交易会被排序并且提交到分布式账本中，并且在这个流程结束的时候接收到事件。
！不过，我们注意到 xuperchain 在文档中提到了使用 JDK 通过rpc 接口构造交易发布！
目前需要知道：

• 智能合约发布的交易，发布方地址是什么，接收方地址是什么，他们在链上存储的和普通交易是否有区别？
• 在搞清问题 1 之后，是否有可能构造交易，把添加自定义字段，然后使用 rpc 接口发布？
• 因为区块链链式结构只需要将上一个区块的 hsah 包含在本区块头中，而 DAG 则将多个（至少两个块作为前置块，那么它们是如何连接的）

---

补充一个：
【1】快照链https://github.com/vitelabs/go-vite/blob/master/ledger/chain/block/snapshot_block.go
【2】真正的 DAG？https://github.com/vitelabs/go-vite/blob/master/ledger/chain/chain.go
【3】靠谱一点的白皮书vite_cn.pdf
【4】xuper 里的交易定义https://github.com/xuperchain/xuperchain/blob/7de83707283ba872129d66aa5e4435d04ed67bee/core/cmd/cli/types.go
【5】xuper 的快照链https://github.com/xuperchain/xuperchain/blob/9d9e60a3bcd87bafafdac51784b504a310ead3d7/core/xmodel/xmodel.go#L51
【6】GHOST，DAG，SPECTRE，PHANTOM 和 CONFLUX 技术原理–挺全的
【7】https://confluxnetwork.org/zh/developers/assets–conflux 区块链，清华自研，树形结构，网站挺好的，白皮书也行

【8】conflux 的白皮书Conflux_Technical_Presentation_whitepaper.pdf