这张关于 NEAR 平台上如何处理交易的图片有多准确？

Posted 2023-02-14

【中文标题】这张关于 NEAR 平台上如何处理交易的图片有多准确？

【英文标题】：How accurate is this picture of how transactions are processed on the NEAR platform?

【发布时间】：2020-04-07 07:25:43

【问题描述】：

在阅读了有关 NEAR 如何处理交易的更多信息后，我想出了这张关于几个关键部分如何相关的图片。

我正在寻求有关如何纠正此问题的一些指示。

首先，我目前知道的几个关键点如下所示：

Action 必须是网络上支持的 7 个操作之一

CreateAccount 创建一个新帐户（用于个人、公司、合同、汽车、冰箱等） DeployContract 部署新合约（使用自己的帐户） FunctionCall 调用合约上的方法（计算和存储预算） Transfer 将代币从一个账户转移到另一个账户 Stake 表示有兴趣在下一次有机会时成为权益证明验证者 AddKey 为现有帐户添加密钥（FullAccess 或 FunctionCall 访问权限） DeleteKey 从帐户中删除现有密钥 DeleteAccount 删除账户（并将余额转入受益人账户）

Transaction 是 Actions 的集合，其中增加了关于他们的关键信息

来源（即由signer 加密签名） 目的地或意图（即发送或应用到receiver） 新近度（即block_hash与最近区块的距离在可接受的范围内） 唯一性（即nonce 对于给定的signer 必须是唯一的） SignedTransaction 是由上述signer 帐户加密签名的Transaction Receipts 基本上就是 NEAR 在从外部（不受信任）传递到内部（受信任）我们网络的“信任边界”之后所称的 Actions。 Receipt 已被加密验证为有效、最新和唯一的，是一个 Action，可以在区块链上进行处理。 因为按照设计，每个Account 都存在于系统中的一个且仅一个分片上，Receipts 要么应用于它们首次出现的分片，要么通过网络路由到适当的“主分片” " 用于他们各自的 sender 和 receiver 帐户。 DeleteKey 是一个 Action，它永远不需要路由到超过 1 个分片，而 Transfer 将始终路由到超过 1 个分片，除非 signer 和 receiver 碰巧有相同的“主分片” " “确定性小工具”是一组规则，可平衡最大化区块链“活跃性”（即响应性/性能）的紧迫性与最小化所需的安全性接受无效交易进入区块链的风险。其中一条规则包括在完成（或有时撤销）交易之前“等待一段时间”——这相当于在确认交易已“完成”之前等待几分钟处理 120 个区块。

          ---.
  o--------o |     o------------------------o     o-------------------o
  | Action | |     |      Transaction       |     | SignedTransaction |
  o--------o |     |                        |     |                   |
             |     | o--------o             |     |  o-------------o  |
  o--------o |     | | Action |  signer     |     |  | Transaction |  |
  | Action | | --> | o--------o  receiver   | --> |  |             |  |  ---.
  o--------o |     | | Action |  block_hash |     |  |             |  |     |
             |     | o--------o  nonce      |     |  |             |  |     |
  o--------o |     | | Action |             |     |  |             |  |     |
  | Action | |     | o--------o             |     |  o-------------o  |     |
  o--------o |     o------------------------o     o-------------------o     |
          ---'                                                              |
                                                                            |
                              sent to network                               |
.---------------------------------------------------------------------------'
|                               <----------
|
|                                                                   ---.
|                                       XXX o--------o     o---------o |
|                                      XX   | Action | --> | Receipt | |
|    o--------------------------------o     o--------o     o---------o |
|    |                                |                                |
|    |  1. Validation (block_hash)    |     o--------o     o---------o |
'--> |  2. Verification (signer keys) |     | Action | --> | Receipt | |  --.
     |  3. Routing (receiver)         |     o--------o     o---------o |    |
     |                                |                                |    |
     o--------------------------------o     o--------o     o---------o |    |
            transaction arrives        XX   | Action | --> | Receipt | |    |
                                        XXX o--------o     o---------o |    |
                                                                    ---'    |
                                                                            |
                applied locally OR propagated to other shards               |
.---------------------------------------------------------------------------'
|                               <----------
|
|
|              --.         .-------.  .--.  .--.         .--.  o-----------o
|    o---------o |         |       |  |  |  |  |         |  |  |           |
'--> | Receipt | |  Shard  |       |  |  |  |  |         |  |  |           |
     o---------o |    A    |       |  |  |  |  |         |  |  |           |
|              --'         |       |  |  |  |  |         |  |  |           |
|                          |       |  |  |  |  |         |  |  |           |
|              --.         |       |  |  |  |  |         |  |  |   Block   |
|    o---------o |         | Block |  |  |  |  |  o o o  |  |  |    (i)    |
'--> | Receipt | |         |  (i)  |  |  |  |  |         |  |  | finalized |
     o---------o |         |       |  |  |  |  |         |  |  |           |
|                |  Shard  |       |  |  |  |  |         |  |  |           |
|    o---------o |    B    |       |  |  |  |  |         |  |  |           |
'--> | Receipt | |         |       |  |  |  |  |         |  |  |           |
     o---------o |         |       |  |  |  |  |         |  |  |           |
               --'         '-------'  '--'  '--'         '--'  o-----------o

                          |                                                |
                          '------------------------------------------------'
                                     about 120 blocks to finality

【问题讨论】：

你用什么来生成这个流程图？很漂亮！

我使用了asciiflow.com 并手动进行了一些调整。很高兴你喜欢它。不过，根据最近的答案，图表的准确性很差。

【参考方案1】：

很好的解释！核心协议开发人员应该完成该图片并包含在低级文档中！

有一些更正。包含所有操作的交易将转换为单个收据。收据也可以有几个动作。每张收据都转到一个特定的分片/收款人帐户。在 Transaction/Receipt 中的“Transfer”动作的情况下，它可以生成新的收据来完成转账：

例如Alice 向 Bob 发送 100N

Receipt 1，action Transfer：作用于 Alice 的账户。 Alice 的账户被扣除了 100N。如果成功，则创建第二张收据：

收据 2- 单个操作：对 Bob 的帐户执行操作以“将余额增加 100N”。第二个收据被“发布”以路由到 Bob 的分片。

如果第二张收据失败（没有 Bob 帐户），则会创建第三张收据以将 100N 退还给 Alice。第三张收据再次发布以路由回 Alice 的分片。

因此，每张收据（可以有多个操作）但被定向到单个特定帐户，然后是单个分片。

.- 至少这是我到目前为止所理解的 -.

我正在阅读代码 Sherif，更多详细信息：

即使一个交易有多个操作，每笔交易都会转换为一个收据。收据可以有多个动作，但只有一个“接收者”。

所有收据都经过验证。当路由到其他分片时（如果“接收者”帐户不在当前分片中），接收节点将在处理之前重新验证收据。所以没有可信/不可信边界。在处理之前，所有内容都会在节点中重新验证。

首先处理所有本地收据，然后检查延迟收据（等待数据），然后处理从其他节点收到的收据。

一些收据可以是“数据收据”，包含执行其他收据所需的数据块。这就像将输入数据以块的形式发送到其他节点。当收到所有数据块时，执行相关的“Action Receipt”。

当“操作收据”包含所有数据时，收据内的每个操作都会执行：code 和code 收据中的每个操作都有一个循环，并且该操作应用于接收方帐户。

.-待续-.

【讨论】：

感谢 Lucio，感谢详细的跟进。这是 Evgeny Kuzyakov 的最新消息，收录在本文档和录音中。它可能有助于为您的探索添加一些背景：docs.google.com/document/d/…

【参考方案2】：

“收据要么应用到它们首次出现的分片，要么通过网络路由到它们各自的发送者和接收者帐户的正确“主分片”。”

这是我的理解； AccountID 将交易发送到他们所在的分片，例如分配给给定的时期，因为每个时期都有跨分片的帐户重新洗牌。分片（验证者的 AccountID 集等）验证交易。如果接收者在另一个分片上，则创建收据并将其路由到另一个分片。 虽然来自发送方的交易可以包含在下一个区块中，但最多需要三个区块来验证它并最终确定到接收方分片的路由。

【参考方案3】：

我不清楚“路由到多个分片”是什么意思。收据只能路由到一个分片。另外我不明白你对确定性小工具的描述，我不知道你从哪里得到“120 块”。通常你只需要等待 3 个区块就可以完成一个区块。

【讨论】：

这只是一个属性sender=receiver。某些操作需要sender=receiver。 nomicon.io/Runtime/Actions.html

在这种情况下，我仍然会考虑将收据路由到同一个分片，即使不涉及网络消息。