本文深入探讨了链重组对数据消费和聚合的影响,以及在多链环境中需要考虑的因素。文章解释了链重组的基本概念,包括区块、链、矿工、链分叉等,并讨论了无状态数据和有状态数据在处理链重组时的不同策略。此外,还分析了不同网络中链重组的实际情况,并提供了关于如何设计索引器以应对链重组的建议。
在本文中,我们将探讨链重组对消费和聚合数据的影响,多链环境中需要考虑的因素,以及我们如何为此进行设计。
我们假设你对链重组有很强的理解,但如果你想复习一下,请跳到底部这里。
注意:只有当你从链的头部开始索引,或者处理头部和网络最终确认区块范围内的数据时,处理重组才重要。
独立数据是指不需要先前的状态就可以处理当前状态的数据。在索引器中,这可以简单地理解为只有“创建”操作。
考虑到你正在摄取数据,并且你的处理器执行的唯一 CRUD (创建、读取、更新和删除) 操作是写入实体,那么你的索引器正在处理无状态数据,并且处理重组的概念非常简单。有效地删除孤立块中的所有实体,并使用规范块数据重新摄取它们。这是可能的,因为无状态数据允许并行处理。
实际上,我们需要对这些数据执行某种形式的聚合,以便将其处理成信息,在这种情况下,我们的索引器正在处理有状态数据。
跑题:无状态索引可以通过并行化来非常快速地处理,例如像 Flair 这样的索引器,它们仅使用 RPC 即可实现惊人的速度。
有状态数据是指依赖于先前状态的数据,想想更新和删除,以便处理当前状态。在索引器中,这意味着需要更新和删除等操作,而不仅仅是写入新实体。当处理有状态数据时,你的索引器需要考虑实体的当前状态,因此,重组变得更加复杂。
在链重组期间,你需要恢复以前的操作或更改,而不是简单地替换孤立的数据,并确保实体状态正确回滚。这需要跟踪每个实体更改的历史记录,以便在发生重组时,你可以根据采用的规范链的数据准确地撤消或调整状态。
注意:我们可以定期修剪实体历史记录,仅保留与未最终确认的区块相关的更改。
当涉及到多链索引时,当我们处理来自多个源的事件并更新相同的实体状态时,我们会面临额外的复杂性。当一个链发生重组时,我们需要将状态回滚到已知的正确点,并重新处理来自所有链的、在受影响链上重组后影响该状态的所有事件。
在实践中,不同的网络根据其设计表现出不同程度的重组风险。一些网络,如 Base 和 OP 栈,在很大程度上具有抗重组能力,区块的最终确认发生在头部,尽管例外情况确实存在。另一方面,像 Polygon 这样的网络经常经历更深的重组,分叉链可以扩展到 10 个区块以上——一个值得注意的实例涉及 157 个区块 的重组。Etherscan 和 Blockscout 都提供了关于重组发生的数据。根据 Ethereum Mainnet Etherscan 的数据,大约 1% 的区块会经历重组,这意味着,假设一个交易有 50/50 的机会被包含在孤立链或规范链中,那么大约 200 个交易中就有 1 个可能在重组的区块中。
最终,重组是区块链索引中一个至关重要的考虑因素,通过理解它们的影响并以灵活性进行设计,我们可以在索引器中正确地考虑它们。
为了理解重组,让我们分解重组的基本概念,并构建我们对重组的定义。
基本概念:
存储交易的容器。
一系列顺序的区块。
尝试提交下一个有效区块的参与者。
当多个矿工同时提交一个有效的区块时,就会发生链分叉,导致分裂和两个有效的链存在。
当一个链分叉时,最终其中一个链被接受为有效链,称为规范链,未被接受的分叉链成为孤立链,孤立的区块不再存在,并且发生在这些区块中的交易也不再存在。
信息:值得注意的是,在事后我们才知道哪个分叉将成为孤立链,哪个将成为规范链。
确认区块不会成为孤立链一部分的最小区块数。
信息:区块最终确认是桥和中心化交易所要求在交易确认后延迟的原因,以确保区块不会成为孤立区块。
这使我们得出了数据上下文中重组的定义
重组是一组导致链回滚到先前时间点的事件。
Envio 是一种现代的、对开发者友好的、速度优化的区块链索引解决方案,它解决了传统区块链索引方法的局限性,并让开发者安心。区块链开发者和数据分析师可以利用 Envio 的强大功能来克服各种来源的延迟、可靠性、基础设施管理和成本所带来的挑战。
如果你是一名区块链开发者,希望增强你的开发流程并释放 Web3 基础设施的真正潜力,请不要再犹豫了。
加入我们不断壮大的 Web3 开发者社区,查看我们的文档,让我们一起彻底改变区块链世界,并将你的项目推向新的高度。
网站 | X | Discord | Farcaster | Medium | YouTube | Reddit
- 原文链接: docs.envio.dev/blog/inde...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!