6

在阅读了有关 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
4

3 回答 3

2

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

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

例如，Alice 向 Bob 发送 100N

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

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

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

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

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

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

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

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

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

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

  • 当“Action Receipts”拥有所有数据时，收据内的每个操作都会执行：代码 和代码收据 中的每个操作都有一个循环，并且该操作将应用于接收者帐户。

。-未完待续-。

于 2020-11-02T10:11:21.167 回答
2

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

于 2019-12-13T20:57:38.250 回答
1

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

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

于 2019-12-16T07:31:54.853 回答