隐私
概述
在 GoQuorum 中,隐私是指在所涉及的参与者之间保持交易私密的能力。其他参与者无法访问交易内容。
私有交易经理
分布式账本协议利用加密技术实现交易真实性、参与者身份验证和历史数据保存(即通过加密哈希数据链)。为了实现关注点分离并通过某些加密操作并行化提供性能改进,包括对称密钥生成和数据加密 / 解密在内的大部分加密工作都委托给 enclave 。
Enclave 与私有交易管理器合作,通过隔离管理加密和解密来加强隐私。 enclave 持有私钥,本质上是一个与其他组件隔离的虚拟 HSM 。
Enclave
分布式账本协议利用加密技术实现交易真实性、参与者身份验证和历史数据保存(即通过加密哈希数据链)。为了实现关注点分离并通过某些加密操作并行化提供性能改进,包括对称密钥生成和数据加密 / 解密在内的大部分加密工作都委托给 enclave 。
Enclave 与私有交易管理器合作,通过隔离管理加密和解密来加强隐私。 enclave 持有私钥,本质上是一个与其他组件隔离的虚拟 HSM 。
公共和私有状态
GoQuorum 支持两种状态:
公共状态:网络中的所有节点都可以访问
私有状态:只有具有正确权限的节点才能访问
差异是通过使用具有加密(私有)和未加密负载(公共)的交易来实现的。节点可以通过查看签名的 v 值来确定交易是否是私有的。公共交易的 v 值为 27 或 28 ,私有交易的值为 37 或 38 。
如果交易是私有的,则节点只有在能够访问和解密有效负载的情况下才能执行交易。不参与交易的节点根本没有私有负载。因此,所有节点共享一个公共状态,该公共状态是通过公开交易的,并具有本地唯一的私有状态。
该模型限制了在私有交易中修改状态的能力。由于这是(私有)合约从公共合约读取数据的常见用例,因此虚拟机能够跳转到只读模式。对于从私有合约到公共合约的每次调用,虚拟机将更改为只读模式。如果虚拟机处于只读模式并且代码尝试更改状态,则虚拟机将停止执行并引发异常。
允许以下交易:
并不支持以下交易
在哪里:
S = 发件人
(X) = 私有
X = 公开
->= 方向
[[]= 只读模式
状态验证
为了确定节点是否同步,块中包含公共状态根哈希。 私有交易仅由参与节点处理,因此不可能就私有状态获得全球共识。
要验证所有参与者的私有交易的私有状态更改是否相同,请使用 RPC 方法 eth_storageRoot 。 指定私有智能合约地址和区块高度。 如果所有参与节点的状态同步,则所有参与节点都会返回相同的根哈希值,并且可以进行比较。
隐私增强 - 私有状态验证
当启用隐私增强并使用 PSV 交易时, GoQuorum 节点会自动验证各方节点之间的合约状态。 有关更多详细信息,请参阅 Privacy Enhancements 。
交易和合约隐私
GoQuorum 通过以下方式实现交易隐私:
1. 通过 privateFor 参数标记谁是该交易的隐私,使交易发件人能够创建私有交易
2. 用加密有效载荷的哈希替换私有交易的有效载荷,这样原始有效载荷对于不知道交易的参与者是不可见的
3. 将加密的私有数据链下存储在称为隐私 Privacy Manager . 的单独组件中。 Privacy Manager 加密私有数据,将加密数据分发给对交易保密的其他方,并将解密的有效载荷返回给这些方
GoQuorum 引入了 “ 公共交易 ” 和 “ 私有交易 ” 的概念。请注意,这只是一个概念, GoQuorum 并没有引入新的交易类型,而是扩展了以太坊交易模型以包含一个可选的 privateFor 参数(其填充导致 GoQuorum 将交易视为私有)和交易类型有一个新的 IsPrivate 方法来识别此类交易。
公开交易
公共交易是那些有效负载对同一 GoQuorum 网络的所有参与者可见的交易。 这些是 created as standard Ethereum Transactions in the usual way . 。
公开交易的示例可能包括来自某些服务提供商的市场数据更新,或一些参考数据更新,例如对债券证券定义的更正。
私有交易
私有交易是那些有效载荷仅对其公钥在交易的 privateFor 参数中指定的网络参与者可见的交易。 privateFor 可以采用逗号分隔列表中的多个地址。 (请参阅 Developing Smart Contracts 部分下的创建私有交易)。
当 GoQuorum 节点遇到具有 non-null privateFor 值的交易时,它会将交易签名的 V 值设置为 37 或 38 (而不是 27 或 28 ,这些值用于指示交易是 “ 公开的 ” )按照以太坊黄皮书中指定的标准以太坊)。
公共与私有交易处理
公共交易以标准的以太坊方式执行,因此如果将公共交易发送到持有合约代码的账户,每个参与者将执行相同的代码,其底层 StateDB 将相应更新。
然而,私有交易不是按照标准以太坊执行的:在发送者的 GoQuorum 节点将交易传播到网络的其余部分之前,它用它从 Constellation/Tessera 接收的加密有效负载的哈希替换原始交易有效负载。参与交易的参与者将能够通过他们的 Constellation/Tessera 实例用实际有效载荷替换哈希,而非参与方的参与者只能看到哈希。
结果是,如果私有交易被发送到一个持有合约代码的账户,那些不是交易方的参与者最终只会跳过交易,因此不会执行合约代码。然而,在调用 EVM 执行之前,那些参与交易的参与者将用原始有效载荷替换哈希,并且他们的 StateDB 将相应地更新。如果没有对 geth 客户端做相应的改动,那么这两组参与者最终会得到不同的 StateDB ,无法达成共识。为了支持这种合约状态的分叉, Quorum 将公共合约的状态存储在全球同步的公共状态树中,并将私有合约的状态存储在非全球同步的私有状态树中。
私有交易管理器
GoQuorum 使用私有交易管理器 Tessera 来实现私有交易。
私有交易管理器是一个单独的组件,用于在私有交易的接收者之间存储和分发加密的私有交易数据。
Private Transaction Manager 有两个不同的组件:
交易管理器
Enclave
启动 GoQuorum 节点时,使用以下任一方法启用私有交易:
设置 PRIVATE_CONFIG 环境变量以指定到私有交易管理器的直接 IPC 连接。
将 PRIVATE_CONFIG 环境变量设置为指定私有交易管理器连接的 TOML 配置文件。
使用命令行参数指定私有交易管理器连接。
这些选项将在以下各节中详细说明。
直接IPC连接配置
这是指定私有交易管理器创建的 .ipc 套接字文件路径的默认方法。
如果要使用 IPC 套接字进行连接,请使用此方法,并使用默认超时值。
使用连接配置文件
使用配置文件允许您为与交易管理器的连接指定更多选项。
如果您需要更改默认值的超时时间,则只有 IPC 套接字连接才需要配置文件,否则 Direct IPC connection configuration 更简单
使用命令行参数
命令行参数也可用于配置与交易管理器的连接。 请注意,这些可与其他选项一起使用,在这情况下,命令行参数将覆盖任何其他选项。
命令行参数的完整说明
--ptm.socket path/to/ipc/file
使用 unix 域套接字进行私有交易管理器连接时的 ipc 文件路径。
--ptm.url value
使用 http/https 连接到私有交易管理器时的 URL 。
--ptm.timeout value
通过私有交易管理器连接进行通信的超时(秒)。 零值表示禁用超时(默认值 = 5 秒)。
--ptm.dialtimeout value
私有交易管理器连接的空闲超时(秒)。 零值表示禁用超时(默认值 = 10 秒)。
--ptm.http.writebuffersize value
私有交易管理器连接的写缓冲区大小(字节)。 零值(默认)使用 http.Transport 默认。
--ptm.http.readbuffersize value
私有交易管理器连接的读取缓冲区大小(字节)。 零值(默认)使用 http.Transport 默认。
--ptm.tls.mode value
如果 off ,则禁用 TLS (默认)。 如果 strict ,则将使用 TLS 进行 https 连接到私有交易管理器。
--ptm.tls.rootca path/to/rootca_pem_file
包含用于 TLS 连接到私有交易管理器的根 CA 证书的文件路径。 如果未指定,则使用主机的证书(默认)。
--ptm.tls.clientcert path/to/client_cert_pem_file
包含用于 TLS 连接到私有交易管理器的客户端证书(或证书链)的文件路径。 如果服务器配置为使用双向身份验证,则这是必需的。
--ptm.tls.clientkey path/to/client_key_pem_file
包含客户端私钥的文件路径,用于与私有交易管理器的 TLS 连接。 如果服务器配置为使用双向身份验证,则这是必需的。
--ptm.tls.insecureskipverify
在连接到私有交易管理器时禁用服务器的 TLS 证书验证。
私有交易生命周期
以下是 GoQuorum 中如何处理私有交易的描述:
在这个例子中,甲方 (A) 和 乙方 (B) 是交易甲乙 (AB) 的一方,而 丙方 (C) 不是。
1. A 方向其 GoQuorum 节点发送交易,指定交易负载并将 privateFor 设置为 A 方和 B 方的公钥( A 方是可选的)
2. 甲方的 GoQuorum 节点将交易传递给其配对的交易管理器,要求它在将交易有效载荷转发给交易接收方(即乙方)之前对其进行加密和存储
3. 甲方的交易管理器调用其关联的 Enclave 以加密给定收件人的有效负载
4. 甲方的 Enclave 通过以下方式加密私有交易有效载荷:
生成一个对称密钥(从这里开始称为 tx-key )和两个随机数
使用此 tx 密钥和随机数之一加密交易负载
通过以下方式分别为每个收件人加密 tx-key :
从发送者 (A) 的私钥和接收者 (B) 的公钥导出 ECDH (椭圆曲线 Diffie-Hellman )共享对称密钥(共享密钥)
使用共享密钥和另一个随机数加密 tx-key
对所有收件人重复此操作(对于 n 个收件人,将有 n 个唯一的加密 tx-keys - 每个收件人的 nonce 不变,因为正在使用的共享密钥发生变化)
返回到交易管理器:加密的交易有效载荷、所有加密的 tx 密钥、 nonces 以及发送者和所有接收者的公钥
5. 甲方的交易管理器存储来自 Enclave 的回复,并通过以下方式转发给私有交易接收者:
计算加密负载的 SHA3-512 哈希(这充当数据库中的唯一标识符 / 主键)
在数据库中存储哈希、加密的有效载荷、所有加密的 tx 密钥、 nonces 以及发送者和所有接收者的公钥
通过以下方式从 Enclave 向每个接收者发送回复:
清理每个接收者的回复(删除所有加密的 tx 密钥,除了为该接收者准备的密钥)
序列化数据
将序列化数据推送给接收方(在本例中为乙方的交易管理器)
确保推送成功(如果单个接收者未能响应或返回错误,则该过程将在此处停止。要求所有接收者都已存储加密的有效负载,然后才能在 GoQuorum 级别传播交易并写入区块链)
对所有收件人重复此操作
6. 甲方的交易管理器将加密负载的哈希值返回给 GoQuorum 节点。 GoQuorum 用该哈希替换交易的 data 方面,并将交易的 v 值更改为 37 或 38 ,从而将交易标记为私有并指示交易的 data 方面表示加密有效负载的哈希,而不是可执行的 EVM 字节码
7. 然后使用标准的 geth P2P 协议将交易传播到网络的其余部分
8. 一个包含交易 AB 的区块被创建并分发到网络中的每个 GoQuorum 节点
9. 在处理区块时,所有 GoQuorum 节点都尝试处理交易。由于 v 值为 37 或 38 ,认出交易 data 是一个哈希,每个节点将调用其交易管理器以确定它是否是交易的一方(在其数据库中有一个给哈希的条目)在这个例子中,甲方和乙方的交易经理将确定他们是交易的一方,而丙方的交易经理将确定它不是交易方
10. 甲方和乙方的交易管理器调用其关联的 Enclaves 来解密有效载荷
11. 甲方和乙方的 Enclave 通过以下方式解密私有交易:
导出用于加密的共享密钥:
由于甲方是本次交易的发送方,它将使用其私钥和接收方( B )的公钥推导出共享密钥
由于 B 方是此交易的接收方,它将使用其私钥和发送方 (A) 的公钥导出共享密钥
b. 使用共享密钥和加密数据解密 tx 密钥,并从数据库中检索到 nonce
c. 使用 tx-key 和从数据库中检索到的加密数据和 nonce 解密私有交易有效负载
d. 返回给交易管理器:解密后的私有交易数据
12. 交易管理器 将结果返回到他们的 GoQuorum 节点:
甲方和乙方的交易管理器将解密后的私有交易数据返回给他们的 GoQuorum 节点,这些节点现在可以正常执行交易,从而更新他们各自的私有 StateDB 。 GoQuorum 会丢弃使用过的解密私有交易数据
丙方的交易管理器向其 GoQuorum 节点返回 404 NOT FOUND ,因为它不是交易的接收者。 GoQuorum 节点认识到它不是该私有交易的参与方,将跳过该交易的执行,因此不会对其私有 StateDB 进行任何更改
续约
概述
一旦部署了私有合约,它只能在最初部署它的节点上可用。 这意味着任何新节点都无法访问私有合约,因为它没有代码,也没有任何与之关联的状态。 在现实生活场景中,我们确实看到需要将部署到一组初始参与者节点的私有合约扩展到已成为业务流程一部分的新节点。 合约状态扩展功能解决了这个需求。
需要注意的是,作为合约状态延期的一部分,只有在延期时的合约状态是共享的。 这意味着没有合约的历史记录,并且尝试查看它不会产生任何结果,因为新的接收者当时不是当事人。 这也意味着事件也不共享,因为交易不共享并且不计算状态转换。
流程
下图描述了合约状态扩展的流程。
出于流程描述的目的,以下描述中的 “ 所有参与者 ” 是指:
对于 “**Standard Private*”* 类型的合约,它将是发起扩展的节点和扩展合约的节点
对于 “**Party Protection*”* 和 “**State Validation*”* 类型的合约,它将包括当前合约参与者的所有节点以及将扩展到的新节点
在此示例中,部署在节点 A 和 B 之间的现有私有合约正在从节点 A 扩展到节点 C 。
1. 节点 A 的用户提出合约的扩展,引用 C 的 Private Transaction Manager ( PTM )公钥作为本次扩展的私有参与者,节点 C 的以太坊公钥作为本次扩展的接收地址,节点 C 的 PTM 公钥作为目标接收者。
1a - 节点 A 识别要扩展的合约的所有参与者,并使用用户给定的输入和所有参与者的 PTM 公钥创建扩展合约
1b - 私有交易有效负载与参与者的 Tessera 共享。
1c - 公共状态在所有节点上传播。所有参与者节点看到一个发出的日志,并开始观察发出事件的合约地址,以便后续可能发生的 事件。这个合约地址是扩展过程的管理合约。每个扩展都会创建一个新的管理合约
2. 节点 A 通过创建延期合约自动批准延期合约。在审批过程中:
2a - 节点 A 调用其本地 Tessera 节点对管理合约地址进行加密
2b - 节点 A 使用来自上一步的加密有效负载向所有参与者发送私有交易,以生成用于批准过程的随机哈希。
2c - 私有交易传播到所有参与者的 Tessera
2d - 节点 A 使用生成的哈希批准扩展(在步骤 2b 中)
2e & 2f - 私有交易有效载荷与所有参与者的 Tessera 共享。公共状态在所有节点上传播
3. 由于状态共享不执行生成状态的交易(为了保持历史私有),因此提议者无法提供状态正确的证据。为了弥补这一点,接收方必须接受合约的建议作为证据。在此步骤中,拥有节点 C 的以太坊公钥标记为接收地址的用户使用 GoQuorum API 批准合约扩展
3a - 节点 C 调用其本地 Tessera 节点对管理合约地址进行加密
3b - 节点 C 使用来自上一步的加密有效负载向所有参与者发送私有交易,以生成用于批准过程的随机哈希。
3c - 私有交易传播到所有参与者的 Tessera
3d - 节点 C 使用生成的哈希散列批准扩展(在步骤 3b 中)
3e & 3f - 私有交易有效载荷与所有参与者的 Tessera 共享。公共状态在所有节点上传播
4. 节点 A 监控节点 C 是否接受合约延期。 一旦接受
4a 和 4b - 节点 A 获取合约的状态并将其作为 “ 私有交易 ” 发送给节点 C 。然后它将该状态的 PTM 哈希提交给合约,包括接收者的 PTM 公钥。
4c - 节点 A 提交交易以标记状态共享的完成。此交易会发出一个日志,在处理交易时,接收者将获取该日志
4d & 4e - 私有交易有效载荷与 Tessera 节点 C 共享。公共状态在所有节点之间传播
5. 节点 A 和 B 监视状态共享事件
5a - 在注意到作为区块处理一部分的状态共享事件后,节点 A 和 B 更新正在扩展的合约的隐私元数据。此步骤将仅针对当事人保护或私有状态验证类型的合约执行。
6. 节点 C 监视状态共享事件
6a - 在注意到状态共享事件作为块处理的一部分后,节点 C 从其本地 Tessera 节点获取合约私有状态数据
6b - 节点 C 将获取的状态应用于合约地址并成为私有合约的一方
笔记
如果网络使用 Enhanced network permissioning 运行,则:
合约延期的启动只能由网络管理员或组织管理员帐户完成
同样在接收节点,合约扩展只能由网络管理员或组织管理员帐户接受
隐私增强
从 GoQuorum v20.10.0 开始,包含两项隐私增强功能以 防止状态异样:
交易对手保护
私有状态验证
交易对手保护
交易对手保护可防止非参与者向私有合约发送交易。例如,在节点 1 和 2 之间部署了一个私有合约,在没有交易对手保护的情况下,如果节点 3 发现了私有合约地址,节点 3 可以发送一个 privateFor 设置为节点 2 的交易。该交易不会应用到节点 3 上,因为它不是私有交易的参与者。非参与节点 3 提交的交易应用于节点 2 上的私有状态。
使用交易对手保护而不是私有合约实现的访问控制来防止其他网络参与者更新状态。交易对手保护可防止非参与者在没有额外访问控制的情况下与私有合约进行交互。
私有状态验证
私有状态验证通过确保合约的任何私有交易始终发送给所有参与者来防止状态异样。例如,在节点 1 和 2 之间部署了一个私有合约。如果没有私有状态验证,节点 1 可以向私有合约发送一笔交易,其 privateFor 为 [] 。交易改变了节点 1 的私有状态,而不是节点 2 ,并且 1 和 2 的私有状态不再匹配。使用私有状态验证,来自节点 1 且 privateFor 为 [] 的交易被拒绝,并且只有当 privateFor 同时包含 1 和 2 时才会处理该交易
使用私有状态验证时,完整的参与者列表在所有参与者之间共享,并针对所有后续交易进行验证。发送给一部分参与者的交易失败。
在标准隐私或仅使用对手方保护时,只有发送节点知道完整的参与者列表。
受影响的合约原始交易有效载荷哈希
交易对手保护和私有状态验证是使用受影响的合约原始交易有效负载哈希 (ACOTH) 实现的。要与私有合约进行交易,节点必须证明它可以访问(即,它具有加密的有效载荷和解密它的能力)到合约的原始交易。
主要改进
隐私标志
新参数 PrivacyFlag 已添加到所有 GoQuorum send API 方法,从客户端传递以启用隐私增强功能。该标志是一个具有以下值的无符号整数: 1 表示 PP , 3 表示 PSV 交易。如果该标志丢失或为零,则假定该交易是 “ 非隐私增强 ”SP 交易。
隐私元数据和隐私元数据树
隐私元数据是 GoQuorum 中引入的一种新结构。它存储在 GoQuorum DB 中的隐私元数据树中(通过哈希映射链接到私有状态)。隐私元数据包含 ACOTH 和隐私标志。
隐私元数据树是一个并行的树,它存储私有合约的隐私元数据(以及我们可能需要的任何额外数据),并通过哈希映射链接到私有状态。树中的记录以合约地址为键(类似于合约 / 账户数据在状态树中的存储方式)。
作为 PP 或 PSV 交易的结果创建的每个合约(帐户)都将具有附加到隐私元数据树的结构,因为这对于对影响这些合约的未来交易进行检查至关重要。
为了发现要附加到交易的 ACOTH(s) , GoQuorum 节点模拟了提议交易的执行。模拟的结果取决于链的当前状态。以太坊 VM 增强可以跟踪模拟交易中涉及的合约。在模拟结束时, EVM 可以报告所有创建 / 调用的合约地址。结合上述隐私元数据,很容易将合约地址转换为 ACOTHs 并将它们附加到提议的交易中。
根据合约的复杂性和网络的吞吐量,模拟时的状态可能与创建提议交易时的链状态不同。如果铸造时的状态被充分改变以确定不同的合约交互,则相应的 PP/PSV 交易将在所有参与者上被标记为失败。此外,由于 PP 合约中预期会出现状态异样,因此 PP 交易有可能(取决于合约设计)在某些参与者上失败。
并发性也可能给 PSV 合约带来问题。执行哈希计算基于模拟时的链状态。从多个节点同时向同一个 PSV 合约提交多个交易可能会导致大部分交易失败。
考虑到上述情况,我们希望用户仅在需要增强隐私时才选择 PP 和 PSV 合约 / 交易(并且额外的隐私好处超过潜在的不足)。
不同类型的私有合约 / 交易之间不允许交互。唯一允许的交互类型是私有合约 (SP/PP/PSV) 从公共合约中读取。
隐私增强功能仅对提交 / 铸造的交易执行检查。上述限制均不适用于调用(只读交易)。在这种情况下,调用是在本地执行的合约方法调用,不会导致生成交易。
配置更改
Go Quorum
genesis.json 文件已修改为包含 privacyEnhancementsBlock 。将来,当整个网络准备好与隐私增强合约 / 交易进行交易时,此值应设置为适当的值(并且应在网络中的所有节点上使用相同的值进行初始化)。
Tessera
新标志 enablePrivacyEnhancements 已添加到默认为 FALSE 的 Tessera 配置中,并且可以通过将属性添加到配置文件中来启用,就像其他功能一样。有关更多详细信息,请参阅示例配置。
在 GoQuorum 网络中启用隐私增强
对于任何给定节点,首先启动隐私管理器 (Tessera) ,因此我们允许在 GoQuorum 升级之前使用隐私增强支持升级 Tessera 节点。但是当 GoQuorum 节点升级并使用 enablePrivacyEnhancements 重新初始化 geth 时, GoQuorum 节点将验证 Tessera 运行的版本,如果 Tessera 未运行升级版本,则将无法启动。 GoQuorum 节点会在控制台中报告相应的错误消息,建议用户先升级 Tessera 。
如果节点想要将其 Tessera 升级到隐私增强版本(或进一步)以利用其他功能和修复程序但尚未准备好升级 GoQuorum ,则可以通过不在 Tessera 配置中启用 enablePrivacyEnhancements 来实现。这将允许节点拒绝来自其他节点的 PP 和 PSV 交易,直到节点准备好支持隐私增强合约 / 交易。
向后兼容
GoQuorum
升级后的 GoQuorum 节点可以共存于其他节点运行在较低版本的 GoQuorum 上的网络上,从而支持逐节点升级。但是在所有感兴趣的节点都升级并启用隐私之前,它不能支持隐私增强合约。如果升级但隐私未 “ 启用 ” 的节点收到 PSV 或 PP 交易,该节点将记录一个 BAD BLOCK 错误,并显示 “ 隐私增强被禁用时收到隐私增强交易。请检查您的节点配置。 ” 错误信息。如果共识算法是 Raft ,节点就会停止。对于 Istanbul ,节点将继续尝试附加有问题的块并重新打印上述错误,并且在重新启动并使用正确的 privacyEnhancementsBlock 重新初始化之前,它不会赶上其余节点。
Tessera
在任何给定节点上, Tessera 都可以随时升级到隐私增强版本。在 Tessera 配置中启用 enablePrivacyEnhancements 标志时要小心,因为它会接受 PSV 和 PP 交易,如果 GoQuorum 节点未启用隐私,则可能导致节点崩溃。升级后的节点可以继续使用 SP 交易在运行在先前版本上的 Tessera 节点上进行通信。 API 版本控制(将与隐私增强一起引入)使升级后的节点能够确定接收节点是否支持隐私增强,如果不支持则使交易失败。
Tessera P2P 通信变化
请参阅 here 刷新有关 Tessera P2P 通信的信息。
参与方保护变化
为了防止非参与方节点与 PP 合约交互,必须将新交易与 ACOTHs 和 PrivacyFlag 从 GoQuorum 提交到 Tessera 。然后, Tessera 节点将为每个 ACOTH 生成证明(使用新交易密文、原始交易密文和原始交易主密钥的哈希),并在 Tessera 节点之间共享的交易有效负载中包括 a) PrivacyFlag 、 b) ACOTH 和 c) ACOTH 证明(安全哈希)。
私有状态验证更改
除了 ACOTH 之外, PSV 交易还有一个执行哈希( Merkle 根),它是根据从 GoQuorum 到 Tessera 的交易模拟(提交时)产生的所有受影响合约计算得出的。 d) 执行哈希和 e) 参与者列表也在 Tessera 节点之间共享。
隐私增强交易端到端流程
SP 交易的端到端流程请参阅 the private transaction livecycle 文档。
在此示例中,我们将介绍节点 A 和 B 之间的 “ 隐私增强合约 ” 上的私有交易流程。
1. 用户从节点 A 为节点 B 推送私有交易
交易有效载荷将包括 PrivacyFlag , PP 值为 1 , PSV 合约值为 3
2.节点 A GoQuorum 读取 PrivacyFlag 运行 EVM 交易模拟以收集所有受影响的合约和与合约账户关联的 ACOTH 。对于 PSV 交易,它还根据交易模拟产生的所有受影响的合约计算执行哈希( Merkle 根)。
3.节点 A GoQuorum 将交易有效负载、 PrivacyFlag 、 ACOTH (以及 PSV 的 Merkle 根)推送到节点 A Tessera 。
4.节点 A Tessera 为 ACOTH 生成证明(安全哈希)并使用它们来验证发起方是否可以访问所有相关交易。此外,对于 PSV ,它还将根据每个 ACOTH 交易中的列表验证参与者列表(如在 PSV 交易中,接收者列表在交易的所有节点之间共享)。如果列表不匹配,它将在 /send 上返回失败到节点 A GoQuorum 。
5.节点 A Tessera 将加密的有效载荷、 ACOTH <-> 证明(安全哈希)映射推送到节点 B Tessera (对于 PSV 交易,它还将推送 privateFor 列表和 Merkle 根)。
6.节点 B Tessera 计算并比较来自节点 A Tessera 的证明(安全哈希)(对于 PSV ,它还根据 privateFor 列表验证 ACOTH 的参与者列表)。
7.节点 B Tessera 向节点 A Tessera 返回一个 SUCCESS 回复 — 即使计算和比较不匹配(为了防止节点 A 找到合约 / 交易的接收者列表)但它不会存储有效负载 /ACOTH ↔ Securehash 映射在结果上。
8.节点 A Tessera 将加密交易负载的哈希值返回给节点 A GoQuorum
9.节点 A 通过网络挖掘交易。
10.作为合约一方的节点 A 和节点 B 将从各自的 Tessera 节点 /receive 解密有效载荷、 ACOTH (对于 PSV 和 Merkle 根)。
11.两个节点都执行交易并比较 ACOTH (和 PSV 的执行哈希)并相应地更新交易收据以标记交易执行完成。