浅谈NEO区块链的见证人和触发器

今天我们将讨论Neo区块链上的两个非常重要的机制，称为见证人机制和触发器机制。如果你之前还没阅读过有关Neo网络运作的内容的话，请在继续阅读本文之前花几分钟先看看这篇文章：https://medium.com/neoresearch/ing-neo-network-in-five-images-e51b7c19d6e0

在开发智能合约时，我们通常会关注一种特定的执行模式，称为应用程序(Application)触发器。回想下我们之前的Hello World的教程，它在应用程序触发器上运行，在验证交易之后执行已编码的合约指令。因此，除了执行智能合约外，Neo区块链还允许我们对交易本身的行为进行编程，允许根据一些特定的规则决定是否需要执行验证操作。

当前存在两种触发器，分别是验证触发器(验证当前交易是否有效)和应用程序触发器(执行通过验证的智能合约)。NEP-7提案中有包含更多种类的触发器，它可以添加另外两种执行模式，不过这个我们之后再讨论。现在我们先看看现有的这些内容。

在？看看角色: YELLOW和BLUE

所以，让我们来看看今天的两个角色，YELLOW和BLUE。每个角色都有一个内部协议，用来根据签名验证公钥，这是我们在钱包软件上对普通用户账户使用的标准合约。

在我们的第一个场景中，YELLOW想要给BLUE转15个GAS，所以它创建了交易a。这个交易包含了YELLOW账户中的全部的20个GAS，它向BLUE转了15个GAS，并将剩下的5个GAS(即找零)返回给自己。所以，总数是正确的，但是这个交易没有通过验证模式。

为什么Tx A会失败呢? 这些值都是正确的，但是从YELLOW中提取资产需要它对交易进行签名 (否则任何人都可以花费他人的代币了……)。

引入见证人机制

因此，我们需要为这个交易附加一个见证人，这个见证人必须完全符合YELLOW的scripthash。每个见证人由两部分组成:VerificationScript(YELLOW的公钥脚本)和InvocationScript(YELLOW给与自己公钥匹配的TxA进行签名)。

好了，现在交易通过了验证(进入网络mempool)，这意味着最终它可以被包含在一个区块中，且该交易将永久地合并至Neo区块链。

避免双花现象

我强调“可以包含”，因为并不是所有进入mempool的交易都会被允许在一个区块上发布。假设YELLOW是一个“聪明的家伙”，它将支付给BLUE的15个GAS发送给某个节点(RPC 1)，同时通过另一个交易将另一笔发送给自己的费用发送至另一个节点 (RPC 2)。由于节点还没有在点对点的网络上进行通信，所以它们都将接受交易并通过验证阶段。但是，当两个交易都到达共识节点时，其中只有一个是有效的，从而避免双花现象 (假设TxB在TxC之前到达，因此TxB将发布在区块上，而TxC将会被拒绝发布)。

引入一个多签角色：YELLOW+BLUE

现在我们有另一位同事，名为YELLOW+BLUE。这是一个具有多签的角色，它的验证脚本需要两个签名来匹配YELLOW和BLUE的公钥。(注意:如果您想更深入地了解多签机制，可以查看https://medium.com/neoresearch/ing-multisig-on -neo-df9c9c1403b1 )

假设YELLOW+BLUE想向用户BLUE转15个GAS，这个过程会复杂吗?你需要多少个见证人呢?只需要一个。Neo上的见证人机制可能会足够的灵活，能够像处理单个签名账户一样处理这些(以及其他的)情况。因此，只需填写输入和输出，并在InvocationScript上附加一个带有必要凭证的见证人(两个签名，一个代表YELLOW，另一个代表BLUE)。

网络费用

如果你错误地计算了交易的输入和输出，会发生什么情况? 例如，如果YELLOW提取了20个GAS，而转给自己时只得到了19.5个，交易是能够被接受的。那剩下的0.5个GAS呢?它会作为网络费用(为网络上的优先级付费)。

谁会得到这笔网络费用? 被选举出来可以生产区块的那些节点，也被称为共识节点。**还有另一种类型的费用称为系统费用，我们会在之后的文章中讨论。然而，这笔费用并不属于共识节点，而是重新分配给每个NEO持有者。

现在是时候执行调用了。

转账NEP-5代币