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

Question

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

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

首先是我目前知道的几个关键点，下面仅说明了其中的一些：

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

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

• aTransaction是Actions的集合，增加了关于它们的关键信息

  • 起源（即加密签名signer）
  • 目的地或意图（即发送或应用到receiver）
  • 新近度（即block_hash与最近块的距离在可接受的范围内）
  • 唯一性（即nonce对于给定的必须是唯一的signer）
• aSignedTransaction是Transaction由上述signer帐户加密签名的
• Receipts 基本上是 NEARAction在它们从外部（不受信任）传递到内部（受信任）我们网络的“信任边界”之后调用的s。经过加密验证为有效、最新和唯一的，aReceipt已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

Answer 1

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