问题标签 [nearprotocol]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
nearprotocol - 在 FunctionCallAction 和 TransferAction 中存款
考虑 FunctionCallAction 和 TransferAction
depositinFunctionCallAction和 和有什么不一样TransferAction？
nearprotocol - 气体计数。燃烧过的煤气和用过的煤气有什么区别？
在交易执行期间，我们正在计算我们“燃烧了多少气体”和“使用了多少气体”。为什么我们必须单独跟踪这些计数器？
security - 我们可以认为非插件基于网络的加密钱包是安全的吗？
我知道一堆加密钱包，它们可以直接在网络浏览器中使用 IFRAME 和类似技术，而无需安装任何插件：
但他们是否受到网络钓鱼 Dapp 攻击的保护？如果 Dapp 想欺骗您并隐藏实际发送的 ETH 数量或任何其他方式，请在 Web 浏览器中修改钱包 UI？
nearprotocol - 在最后一个 RocksDB 版本碰撞后无法编译近核项目
这是错误的重要部分
如果我遗漏了某些东西（即。stdarg.h），有没有办法自动包含它？
nearprotocol - Near Protocol 有什么机制来防止 gas 价格反馈循环导致它飙升？
受这里讨论的影响，我想知道如果交易量下降，Near 有什么机制可以阻止 gas 价格飙升？如果 gas 价格飙升得太高，它将阻碍用户提交更多交易，从而形成反馈循环，最终导致系统中没有交易。
nearprotocol - 托管和多重签名合约
如何在 NEAR 上构建托管和多重签名合约？例如，与在 Solidity 中构建合约相比；需要什么，有什么例子吗？
nearprotocol - 收据是否对平台构成潜在安全风险？
从文档：
收据的重要特征是它们不包含签名。所有收据默认有效。这意味着如果一个块收到包含令牌传输的 Receipt，它将存入令牌而无需验证传输的来源，因为所有收据都被认为是有效的。
如果收据是通过网络（从一个分片到另一个分片）传达状态更改的主要方法，那么中间人攻击是否不可能注入无效的收据，从而强制将未签名的交易应用于区块链？
还是我错过了什么？
nearprotocol - 如何在 NEAR 平台上进行各方之间的账户转账？
从文档：
帐户可以作为网络上的本地交易在各方之间以原子方式安全地转移。
我知道目前网络上支持的操作是：
我从 NEAR Shell 得知该DeleteAccount操作需要一个要删除的帐户（“发送者”）和一个受益人帐户（“接收者”）。
这就是“在各方之间以原子方式安全地传输”的意思吗？应用DeleteAccount动作？
还是我错过了什么？
nearprotocol - 什么是安全的 NEAR 区块链验证节点重启程序？
如果我立即使用新配置重新启动节点（例如遥测端点更改），我会失去验证状态吗？
我应该在重新启动后重新开始吗？
nearprotocol - 这张关于 NEAR 平台上如何处理交易的图片有多准确？
在阅读了有关 NEAR 如何处理交易的更多信息后，我想出了这张关于几个关键部分如何相关的图片。
我正在寻求有关如何纠正此问题的一些指示。
首先，我目前知道的几个关键点是：
Action必须是网络上 7 个受支持的操作之一CreateAccount创建一个新帐户（为个人、公司、合同、汽车、冰箱等）DeployContract部署新合约（使用自己的帐户）FunctionCall调用合约上的方法（计算和存储预算）Transfer将代币从一个账户转移到另一个账户Stake表示有兴趣在下一个可用的机会成为权益证明验证者AddKey将密钥添加到现有帐户（FullAccess或FunctionCall访问）DeleteKey从帐户中删除现有密钥DeleteAccount删除账户（并将余额转入受益人账户）
a
Transaction是Actions 的集合，增加了关于它们的关键信息- 来源（即由 加密签名
signer） - 目的地或意图（即发送或应用到
receiver） - 新近度（即
block_hash与最近区块的距离在可接受的范围内） - 唯一性（即
nonce对于给定的必须是唯一的signer）
- 来源（即由 加密签名
- a
SignedTransaction是由上述帐户Transaction加密签名的signer Receipts 基本上是 NEARAction在它们从外部（不受信任）传递到内部（受信任）我们网络的“信任边界”之后所称的 s。经过加密验证为有效、最新和唯一的，aReceipt已Action准备好在区块链上进行处理。- 因为，根据设计，每个
Account人都存在于系统中的一个且只有一个分片上，所以Receipts 要么应用于它们首次出现的分片，要么通过网络路由到它们各自sender和receiver帐户的适当“主分片”。DeleteKey是一个Action永远不需要被路由到超过 1 个分片，而Transfer总是被路由到超过 1 个分片，除非两者signer并且receiver碰巧有相同的“主分片” - “最终性小工具”是一组规则，用于平衡最大化区块链“活跃性”（即响应性/性能）的紧迫性与最小化接受无效交易到区块链上的风险所需的安全性。其中一条规则包括在完成（或有时撤销）交易之前“等待一段时间”——这相当于在确认交易已“完成”之前等待几分钟处理 120 个区块。