Corda技术核心概念之交易（Transaction）

以你之姓@ 2022-05-15 06:12 240阅读 0赞

## ##

### 概要 ###

*  *交易是应该提议更新到账单*
 *  *一个可以被更新到账单的交易，需要满足如下条件：*
    
     *  *不能包含双花。（在Corda中，双花问题是通过公证人（Notary）解决的）*
     *  *合约一定是有效的*
     *  *参与方一定是签名了的*

### 概览 ###

***Corda使用UTXO(unspent transaction output)模型机制操作状态，并且账单上的状态是不可改变的。***一般来说，每一次合法的交易都会把账单上的零个或者多个已经存在的账单状态标记为历史状态，然后创建零个或者多个新的账单状态。因此随着时间的流动，交易在不停地发生，账单也在不停地进化。交易代表着一条单一的状态序列。

这儿有个更新账单的例子，带有两个输入和输出：

![70][]

一个交易包含任何类型任意数量的输入和输出：

*  他们可以包括许多不同状态类型，比如同时包含现金和证券
 *  他们可以发布（有零个输入）或者已经存在的状态（有另个输出）。
 *  他们能融合或者拆分可以替代的资产，比如把状态为2美元和状态为5美元变成状态为7美元

交易是**原子**的:要么全部接受一个交易所提议的改变，要么拒绝所有。

这儿有交易的两个基本类型：

*  公证人改变的交易(用于改变状态的公证人)
 *  常规交易（在任何地方使用）

### **交易链** ###

当创建一个新交易的时候，这个交易的输出状态是不存在的，因此必须给这个交易创建一个输出状态。**然而，一个交易的输入状态是上一个交易的输出状态**。因此，我们通过**引用**来包含被提议的交易。

这些输入状态的引用是一个结合体：

*  这个现金的交易创建输入
 *  输入的索引是上个交易的输出

这种场景可以被解释成如下：

![70 1][]

随着时间的流动，这些输入状态的引用把交易连接起来，形成我们所知道的交易链。

### **提交交易** ###

开始，一个交易仅仅是一个提议，然后更新到账单。它代表着账单上状态的未来，也是交易的创建者所期望的。也就是说，我想创建一个交易，这个交易包含着我想要的状态，这些状态也是自己所期望的，然后提议更新到账单。

![70 2][]

为了变得真实，交易接收到需要签名者的签名，签名都放在Commands中。每一个签名者附加他们的签名到一个交易上，以此表达他们同意这个提议。

![70 3][]

如果一个交易聚集了所有必须的签名，这个交易将会被提交：

![70 4][]

这也就意味着：

*  这个交易的输入将会标记为历史状态，不能够被将来任何交易使用
 *  这个交易的输出将会成为账单的当前状态

### 交易有效性 ###

只有当交易满足如下两种条件的时候，签名者才可以签名：

**交易的有效性**：交易链上的每一个交易都会创建一个被提议的交易的输入：

交易被所有需要的参与方进行数字签名

交易是合约有效的

**交易的唯一性**：对被提议的交易来说，它的输入是不存在被消费了的。（保证输入不是双花）

如果交易聚集了所有签名，但是不满足上面两个条件，则这个交易的输出是无效的，这个输出也不会成为下个交易的输入。

### 其他交易组件 ###

交易有输入状态和输出状态，也可能包含如下组件：

*  指令（Commands）
 *  附件（Attachments）
 *  时间戳（Timestamps）

比如，一个Alice支付Bob5美元现金的交易，就包含两个附件和一个时间戳，如下展示：

![70 5][]

我们下面探索交易组件的角色功能扮演：

### 指令（Commands） ###

假如我们有一个现金状态和一个债券状态作为输入，和一个现金状态和债券状态作为输出的交易。这个交易可能代表两个不同场景：

*  一个证券购买
 *  用赠券支付债券（A coupon payment on a bond）

我们能够想象，在不同的支付场景中，增强一个有效交易的规则，它是依赖现金购买还是赠券支付。比如，在一个购买的场景中，我们需要当前债券的拥有者有变化，然而在赠券支付的场景中，我们需要债券的拥有者没有变化。

因为这样，所有我们就有了指令（commands）。一个交易中包含一个指令允许我们表明这个交易的意图，也影响着我们怎样去验证一个交易的有效性。

每一个指令也与一个或者多个签名者有关联。在指令中通过聚集多有的公匙，我们可以得到交易的签名者。在我们的例子中，我们或许可以想象：

*  赠券进行支付，仅仅需要这个债券的拥有者进行签名，前提是需要他签名
 *  现金支付，仅仅需要现金的拥有者进行签名，前提是需要他签名

我们可以可视化成如下：

![70 6][]

### **附件** ###

有时，我们有大量的实践可以被用在需许多不同的交易中。比如：

*  一个公开假期的日历
 *  支持合法文档
 *  现金编码的表格

对于这些使用场景，我们有附件。每一个交易涉及到零个或者多个附件，这些附件都有唯一的hash标识。这些附件是压缩文件（zip/jar）包含任何数据内容。这些文件的信息可以被用作验证交易的有效性。

### 时间窗口（Time-windows） ###

在一些使用场景中，我们希望一个交易是有效的，仅仅在某个具体的时间窗口中（在某一段时间内）。比如：

*  An option can only be exercised after a certain date
 *  债券过期之前应该偿还

在这样的案例当中，我们可以在交易中加上时间窗口。时间窗口具体指出了交易可以被提交的时间段。

[70]: /images/20220515/9caed84342f54caea142986e59ca539e.png
[70 1]: /images/20220515/03abf2a0e12e452d976f06e9bec2b727.png
[70 2]: /images/20220515/077d944ea4f847df90c6061232c3851a.png
[70 3]: /images/20220515/4c45b42f7f684670a20126e0f0639da4.png
[70 4]: /images/20220515/15de2d41ffd348329c977520c8fb4a90.png
[70 5]: /images/20220515/c19ec2855d13421b81461253de02b352.png
[70 6]: /images/20220515/07e56baf18564570b241983a830f8e6e.png