Flare Network价格

哇，事情发展得真快！ 自从上线以来还不到一周，XRP Flare 账户的总锁仓价值（TVL）已经超过了 240 万美元。 这一增长使 MoreMarkets 的总 TVL 达到 2774 万美元。 看到 XRP 社区在 @FlareNetworks 上积极参与 DeFi 真是太棒了。

选择错误的 Flare 节点配置可能意味着数千美元的差异，如果没有正确选择的话。归档节点和修剪节点之间的真正区别是什么？ 正如我通过艰难的方式发现的，我考虑的主要有三种配置。它们是： 非修剪（“归档/完整历史”） - > 5.5 TB 数据库（在 Flare 上并且还在增长） - 所有数据用于专业用例 - 同步/引导需要数周 - ✅ 可以查询自创世以来的区块、收据和日志/事件 - ✅ 可以查询历史状态（这意味着请求特定区块的余额/合约视图函数/合约代码/默克尔证明等，所有这些都可以追溯到创世） - ✅ 可以查询当前状态（即获取当前投票权、账户余额等） 修剪 - <1 TB 数据库（在 Flare 上并且还在增长） - 大多数数据用于大多数用例 - 同步/引导需要 1-2 周 - ✅ 可以查询自创世以来的区块、收据和日志/事件 - ⚠️ 可以查询历史状态，但仅限于提交间隔，这意味着只能查询一小部分历史状态。可通过 `commit-interval` 配置，默认每 4096 个区块。 修剪 + 状态同步 - <100 GB 数据库（在 Flare 上并且还在增长） - 适合验证者和基本 RPC 使用的基本数据 - 同步/引导需要数小时 - ❌无法查询自创世以来的区块、收据和日志/事件。仅限于节点开始同步的区块和 `state-sync-min-blocks` 参数。 - ⚠️ 可以查询历史状态，但仅限于提交间隔，但对最近的区块限制更大。 - ✅ 可以查询当前状态（即获取当前投票权、账户余额等） 因此，对于希望拥有自己 RPC 节点的验证者或爱好者，启用状态同步的修剪节点是理想的。允许验证网络和提交交易（以及读取当前网络状态），所需的硬盘空间最小。 对于大多数依赖于收据、事件日志和自创世以来的区块的分析索引，禁用状态同步的修剪节点是合适的。 对于高级调试和深度分析，建议使用禁用状态同步的非修剪节点。 现在，如果你仍然不清楚归档节点和修剪节点之间的区别（就像我一样），让我来解释一下…… 修剪节点没有完全自由使用以下功能： - eth_getBalance(address, block) - eth_getStorageAt(contract, key, block) - eth_call(contractCall, block)（即 contract.getBalance({ blockNumber }）） ……以及其他一些类似的功能。 注意它们提供了一个区块来查询？归档节点可以提供任何现有的区块号并检索相应的数据，如账户余额、合约状态或特定区块的代码。 其他两个节点有这些功能可用，但如前所述，查询的区块仅限于已提交的尝试，默认情况下是每 4096 个区块。因此，有大量数据缺失，尤其是对于状态同步节点。 如果你愿意，并且数据对你有价值，你可以在这些间隔查询数据，但你需要使用一些数学和/或 debug_getAccessibleState 来计算哪些状态（区块）是可用的。 因此，在你启动归档节点之前，要知道大多数人永远不需要它。它在云服务器上托管的成本比飞行的驴子还要高，实际上仅限于在区块链浏览器、深度历史状态索引（如上所述）或高级调试中的使用。 例如，一个修剪节点（无状态同步）通常足以满足大多数使用 @SubQueryNetwork Indexer SDK 的用户。我觉得有必要重申：这个节点配置确实提供所有事件日志、交易等。例如，你可以索引任何代币的每一次 ERC20 代币转移，或者每一次 FTSO 奖励的每一次索赔。 我希望这能澄清任何人对这些节点配置之间区别的困惑。我建议避免使用归档节点，除非你确实需要它的功能。对于大多数开发/分析目的，始终先尝试修剪（无状态同步）节点，或者对于基本 RPC 使用或验证者，尝试修剪（状态同步）节点。