在阅读了更多关于NEAR如何处理交易的信息后，我想出了这张关于几个关键部分如何相关的图片。
我正在寻找一些关于如何纠正此问题的指示。
首先，我目前知道的几个关键点，下面只说明了其中一些，是：
-
Action必须是网络上支持的 7 个操作之一CreateAccount创建一个新帐户(针对个人、公司、合同、汽车、冰箱等)DeployContract部署新合约(使用自己的帐户)FunctionCall在合约上调用方法(包含计算和存储预算)Transfer将代币从一个账户转移到另一个账户Stake表示有兴趣在下一个可用的机会成为权益证明验证者AddKey将密钥添加到现有帐户(FullAccess或FunctionCall访问权限)DeleteKey从帐户中删除现有密钥DeleteAccount删除账户(并将余额转入收款人账户)
-
Transaction是Action的集合，其中增加了有关其关键信息的信息- 来源(即由
signer加密签名) - 目的地或意图(即发送或应用于
receiver) - 新近度(即
block_hash与最近区块的距离在可接受的范围内) - 唯一性(即
nonce对于给定signer必须是唯一的
)
- 来源(即由
-
SignedTransaction是由上述signer帐户加密签名的Transaction -
Receipt基本上是NEAR在从外部(不受信任)传递到内部(受信任)我们网络的"信任边界"之后所称Action。经过加密验证为有效、最新和唯一，Receipt是准备在区块链上处理Action。 -
由于根据设计，每个
Account都位于系统中的一个且只有一个分片上，因此Receipt要么应用于它们首次出现的分片，要么通过网络路由到其各自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 3 blocks to finality
我不清楚你所说的"路由到多个分片"是什么意思。一个收据只能路由到一个分片。我也不明白你对最终小工具的描述，我不知道你从哪里得到"120块"。通常，您只需要等待 3 个区块即可最终确定一个区块。
很好的解释！核心协议开发人员应该完成该图片并包含在低级文档中！
有一些更正。发生业务及其所有操作将转换为单个收据。收据也可以有多个操作。每张收据都会发送到一个特定的分片/接收者账户。在交易/收据中的"转账"操作的情况下，它可以生成新的收据来完成转账：
例如，爱丽丝向鲍勃发送 100N
-
收据 1，操作 转移：根据爱丽丝的帐户进行操作。爱丽丝的账户被扣除 100N。如果成功，则会创建第二份收据：
-
收据 2 - 单一操作：对 Bob 的帐户进行操作以"将余额增加 100N"。这第二张收据被"发布"以路由到 Bob 的分片。
-
如果第 2 张收据失败(没有 Bob 帐户)，则会创建第 3 张收据以将 100N 退还给 Alice。这第三张收据再次发布，以路由回爱丽丝的碎片。
因此，每个收据(可以有多个操作)，但被定向到单个特定帐户，然后是单个分片。
.- 至少这是我直到现在所理解的 - 。
我正在阅读代码谢里夫，更多详细信息：
-
即使交易具有多个操作，每笔交易也会转换为单个收据。收据可以有多个操作，但只有一个"收件人"。
-
所有收据均经过验证。当路由到其他分片时(如果"接收方"帐户不在当前分片中)，接收节点将在处理之前重新验证接收。因此，没有受信任/不受信任的边界。在处理之前，一切都会在节点中重新验证。
-
首先处理所有本地收据，然后检查延迟的收据(等待数据)，然后处理从其他节点收到的收据。
-
一些接收可以是"数据收据"，包含执行其他收据所需的数据块。这就像将块中操作的输入数据发送到其他节点。收到所有数据块后，将执行相关的"操作接收"。
-
当"操作收据"拥有其所有数据时，将执行收据中的每个操作：代码 和代码 收据中的每个操作都有一个循环，该操作将应用于接收方帐户。
.-待续-。
"收据要么应用于它们首次出现的分片，要么通过网络路由到其各自发送方和接收方帐户的正确"主分片"。
所以这是我的理解;AccountID 将交易发送到他们所在的分片，例如分配给给定纪元的分片，因为每个纪元都会跨分片重新洗牌账户。分片(验证者的账户ID集等)验证交易。如果接收方位于另一个分片上，则会创建收据并将其路由到另一个分片。 虽然来自发送方的交易可以包含在下一个区块中，但最多需要三个区块来验证它并最终完成到接收方分片的路由。