概要
- Transaction 是关于更新账本的提议（proposals）
- 一个 transaction 提议只能在满足以下条件的时候才会被提交（commit）：
- 它不包含“双花”
- 它是合约有效的（contractually valid，就是能够通过合约代码 contract code 的验证）
- 它需要被所有相关方提供签名
概览
Corda 使用 UTXO(未消费的 transaction output)模型来使账本上的每条 state 都不可更改。对于账本上数据的变更都是通过使用 transaction 的方式来做的，就是将0条或多条已经存在的 input state 的记录变为历史记录，然后再新增0条或多条新的 output state。
下边是一个更新的 transaction 的例子，包括了两个 inputs 和两个 outputs：
一个 transaction 中可以包含任何数量任何类型的 inputs 和 outputs：
- 可以包含多种类型的 state（cash, bonds）
- 可以是 issuances 类型（有0个input）或者 exists 类型（有0个 output）
- 可以合并或拆分可替换的资产（比如把一个 $2 的 state 和 $5 的 state 合并为 $7 的 cash state）
Transaction 是一次原子性操作，一个 transaction 里边的所有 changes 必须要全部执行，或者一个也不会执行。
有两种基本类型的 transactions：
- Notary-change transactions（用来变更 state 的 notary）
- General transactions（其他任何类型的 transaction）
交易链 Transaction chains
一个新的 transaction 的 output state 在账本中应该是还不存在的，所以需要提出 transaction 的人来创建。但是 transaction 中包含的 input 应该是在账本中已经存在的，应该是前一个 transaction 添加进去的 output。所以我们需要在新的 transaction 中引用这些已经存在的记录，然后把他们在账本中消费掉（consume，本质上是设置为历史记录）
这些 Input state 的引用包含两部分：
- 创建这个 input 的 transaction 的 hash
- 这个 input 所指的前一个 transaction 带来的 output state 在 output list 中的位置或者说索引值
下图描述了一个 transaction 链：
这些 input state 引用将 transaction 连接在了一起，形成了所谓的交易链（transaction chain）
提交交易 Committing transactions
初始的时候，一个 transaction 仅仅是一个更新账本的提议（proposal）。它表示了经过这次更新后账本的新的状态：
为了成为真正的一笔交易，transaction 必须要获得所有需要的签名（在 command 中定义的）。每一个要求的签名者会将签名附加在 transaction 上来表示他们已经同意了这次更新：
如果得到了所有需要的签名，这个 transaction 就会被提交了：
这意味着：
- Transaction 的 input 被标注为历史记录，并且不能再被之后的 transactions 使用了
- Transaction 的 output 变为账本上的当前状态的一部分
Transaction 的有效性
每一个被要求的签名方应该只有在满足以下两个条件的时候才应该提供签名：
- Transaction 是有效的：对于当前的 transaction 以及产生当前的 Input 相关的所有以前的 transaction：
- Transaction 应该获得所有相关方的数字签名
- Transaction 是合约有效（contractually valid）的（能够通过 contract code 的验证）
- Transaction 唯一性：本次 transaction 要消费的 inputs 没有被任何之前的 transaction 消费过。
如果一个 transaction 获得了所有所需的签名，但是以上的条件并没有满足的话，这次 transaction 的 outputs 是无效的，也不会被之后的新的 transaction 用来作为 input。
其他的交易组件 Other transaction components
就像 input states 和 output states 一样，transactions 还可能会包含下边的组件：
- Commands
- Attachments
- Timestamps
比如一个交易中，Alice 使用 £5 的现金向 Bob 支付了一个 IOU 的 £5，该笔交易包含了两个附件和一个时间戳，看起来像下边这样：
Commands
假设我们有一个 transaction，其中包含了一个现金（cash） state 和一个债券（bond）state 作为 inputs，一个现金（cash） state 和一个债券（bond）state 作为 outputs。这个 transaction 可以代表两种情况：
- 购买债券
- 使用优惠券来支付债券
我们可以假设我们要根据这是一个购买债券的交易还是一个使用优惠券支付的交易来制定不同的验证交易的规则。例如，针对购买债券的情况，我们会要求更改债券当前的所有人，但是对于一个使用优惠券付款的情况，我们不会要求改变债券的所有人。
为了实现这个，我们使用 commands。在 transaction 中包含一个命令（command）允许我们能够表示 transaction 的意图，影响我们如何来验证 transaction 有效性。
每一个命令也会关联一个或多个签名人。通过在 commands 中列出的所有的公钥信息，我们就知道了这个 transaction 里所有要求的签名人的列表。在我们这个例子中，我们可以认为：
- 对于使用优惠券购买债券的情况，只有债券的所有者需要提供签名
- 对于一个现金支付的情况，只有现金的所有者需要提供给签名
我们可以通过下图表示这个情况：
附件 Attachments
有些时候，我们会有一些数据可以在不同的 transactions 中被重用。比如：
- 一个公共假期的 calendar
- 支持的法律文档
- 一个货币代码的表格
针对这些中情况，我们使用附件。一个 transaction 可以通过 hash 引用 0 个或者多个附件。这些附件是 ZIP/JAR 文件，可以包含任何内容。这些附件中信息可以用来验证 transaction 的有效性。
Time-windows
一些时候，我们希望一个交易仅仅在一个指定的时间点被批准执行。例如：
- 在一个指定的日期之后执行一个选项
- 一个债券只能在它的过期日期前被赎回
在这些情况下，我们给 transaction 添加一个 time-window。time-windows 制定了交易会在哪个时间点被提交。