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

Question

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

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

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

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

CreateAccount创建一个新帐户(个人、公司、契约(Contract)、汽车、冰箱等)

DeployContract部署新合约(使用自己的账户)

FunctionCall调用契约(Contract)上的方法(计算和存储预算)

Transfer将代币从一个帐户转移到另一个帐户

Stake表示有兴趣在下一个可用机会成为权益证明验证者

AddKey将 key 添加到现有帐户(FullAccess 或 FunctionCall 访问权限)

DeleteKey从帐户中删除现有 key

DeleteAccount删除帐户(并将余额转移到受益人帐户)

Transaction是Action的合集增加了关于他们的关键信息

来源(即由 signer 加密签名)

目的地或意图(即发送或应用于 receiver)

新近度(即 block_hash 与最近块的距离在可接受的范围内)

唯一性(即 nonce 对于给定的 signer 必须是唯一的)

SignedTransaction是 Transaction由 signer 加密签名上面提到的帐号

Receipt s 基本上就是 NEAR 所说的 Action在它们从外部(不受信任)传递到内部(受信任)我们网络的“信任边界”之后。经加密验证为有效、最新且唯一，Receipt是 Action准备好在区块链上进行处理。

因为，按照设计，每个 Account存在于系统中唯一的一个分片上，Receipt s 要么应用于它们第一次出现的分片，要么通过网络路由到它们各自的正确“主分片”sender和 receiver帐户。 DeleteKey是 Action当 Transfer 时，永远不需要路由到超过 1 个分片除非同时 signer，否则将始终路由到 1 个以上的分片和 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 个块即可完成一个块。