从区块链到LLM，深入解读数据索引技术的演变与挑战

自中本聪决定在创世区块中嵌入一条信息以来，比特币链的数据结构已经经历了一系列的变革。

我在2022年开始深入研究区块链开发，首本阅读的书籍就是《精通以太坊》。这本书极其出色，为我提供了大量关于以太坊和区块链基础知识的深入理解。然而，从现在的视角来看，书中的一些开发技巧已经显得有些过时。初步步骤涉及在个人笔记本电脑上运行一个节点，即使是为了钱包dApp，也需要自行下载一个轻节点。这反映了2015年至2018年间区块链开发生态系统中早期开发者和黑客的行为模式。

回溯到2017年，我们并未有任何节点服务提供商。从供需关系的角度来看，由于用户活动有限，他们的主要功能是进行交易。这意味着自行维护或托管一个完整节点并不会产生太大的负担，因为没有太多的RPC请求需要处理，转账请求也并不频繁。大部分的以太坊早期采用者都是技术极客。这些早期用户对区块链开发有深入的理解，并且习惯于通过命令行或集成开发环境直接维护以太坊节点、创建交易和管理账户。

因此，我们可以观察到早期的项目通常具有非常简洁的用户界面/用户体验。其中一些项目甚至没有前端，用户活动相当低。这些项目的特点主要由两个因素决定：用户行为和链的数据结构。

节点提供者的崛起

随着越来越多的无编程背景的用户投身于区块链网络，去中心化应用的技术架构也随之发生了变化。原先由用户托管节点的模式逐渐转变为由项目方进行节点托管

人们趋向于选择节点托管服务，主要原因是链上数据的迅速增长使得个人托管节点的成本随着时间推移而逐渐增大。

然而，对于小型项目的开发者而言，由项目团队自行托管节点仍然是一项挑战，它需要持续的维护投入和硬件成本。因此，这种复杂的节点托管过程通常被委托给专门从事节点维护的公司来处理。值得一提的是，这些公司在大规模建设和筹集资金的时间点与北美科技产业兴起的云服务趋势相吻合。

Project	Category	Established since
Alchemy	Nodes	2017
Infura	Nodes	2016
NowNodes	Nodes	2019
QuickNodes	Nodes	2017
Ankr	Nodes	2017
ChainStack	Nodes	2018

仅仅通过远程托管节点并不能完全解决问题，尤其是在DeFi、NFT等相关协议兴起的现在。开发者需要处理大量的数据问题，因为由区块链节点本身提供的数据被称为原始数据，这些数据并不是经过标准化和清洗处理的。其中的数据需要被提取、清洗和加载。

例如，假设我是一个NFT项目的开发者，我想要进行NFT交易或者展示NFT。那么我的前端就需要实时读取个人EOA账户中的NFT数据。NFT实际上只是一种标准化的代币形式。拥有一个NFT意味着我拥有由NFT合约生成的一种唯一ID的代币，而NFT的图像实际上是元数据，可能是SVG数据或者指向IPFS上的图像链接。尽管以太坊的Geth客户端提供了索引指令，但对于一些前端需求较大的项目来说，连续请求Geth然后返回前端在工程上是不切实际的。对于一些功能，比如订单拍卖和NFT交易聚合，它们必须在链下进行，以收集用户的指令，然后在适当的时机将这些指令提交到链上。

因此，一个简单的数据层应运而生。为了满足用户的实时性和准确性要求，项目方需要构建自己的数据库和数据解析功能。

数据索引器是如何演变的？

启动一个项目通常是相对简单的事情。你拥有一个构思，设定了一些目标，找到了最优秀的工程师，搭建了一个实用的原型，这通常包括前端和几个智能合约。

然而，要让项目规模化却是相当困难的。人们需要从项目开始的第一天就对设计结构进行深思熟虑。否则，你很快就会遇到一些问题，我通常将这种情况称之为“结冰问题”。

我从《钢铁侠》电影中借鉴了这个术语，它似乎非常适合描述大多数创业公司的境遇。当初创公司快速增长（吸引了大量用户）时，他们常常会遭遇困境，因为他们最初并未预见到这种情况。在电影中，反派角色因为没有考虑到“结冰问题”，从未预料到他的战争装备会飞入太空。同样，对于许多Web3项目的开发者来说，“结冰问题”涉及到处理大规模用户采用带来的负担增加。随着用户数量的急剧增长，这给服务器端带来了沉重的压力。还有一些问题是与区块链本身相关的，例如网络问题或者节点关闭。

大多数情况下，这是后端的问题。比如在一些区块链游戏协议中，这种情况屡见不鲜。当他们计划增加更多的服务器并且雇佣更多的数据工程师来解析链上数据的时候，并没有预见到会有如此多的用户参与进来。等他们意识到这一点时，已经晚了。而且这些技术问题并不能仅仅通过增加更多的后端工程师来解决。正如我之前所说，这些考虑应该从一开始就纳入到计划中。

第二个问题涉及到添加新的区块链。你可能一开始就避开了服务器端的问题，并且聘请了一批优秀的工程师。但是，你的用户可能对当前的区块链不满意。他们希望你的服务也能在其他流行的链上运行，比如zk链或L2链。你的项目架构最终可能会变成如下这样：

在这种系统中，你对自己的数据有完全控制权，这有助于更好地管理和提高安全性。系统限制调用请求，降低过载风险并提高效率。而且该设置与前端兼容，能确保无缝集成和用户体验。

然而，运营和维护成本会成倍增加，这可能会给你的资源带来压力。每次添加新的区块链都需要重复的工作，这可能会耗费大量时间且效率低下。从大量数据集中选取数据可能会降低查询时间，潜在地减缓进程速度。由于区块链网络问题（如回滚和重组），数据可能会受到污染，从而危及数据的完整性和可靠性。

项目的设计反映了你的团队成员。添加更多节点并试图构建一个以后端为重的系统意味着你需要雇佣更多工程师来操作这些节点和解码原始数据。

这种模式类似于互联网初期，电子商务平台和应用程序开发人员选择建立自己的IDC（互联网数据中心）设施。然而，随着用户请求的增长和区块链网络的状态爆发，成本与程序设计的复杂性齐头并进。此外，这种方法阻碍了市场的快速扩张。某些高性能的公共区块链要求硬件密集型的节点操作，而数据同步和清理则不断消耗人力资源和时间成本。

如果你试图构建一个基于区块链的NFT市场或酷炫的游戏，那么你的团队成员中有65％是后端和数据工程师，这难道不奇怪吗？

也许开发人员会想，为什么没有人帮他们解码和传输这些链上数据，这样他们就可以专注于构建更好的产品。

我相信这就是索引器出现的原因。

为了降低接入Web3应用程序和区块链网络的难度，包括我们在内的许多开发团队选择将存档节点维护、链上数据ETL（提取、转换、加载）和数据库调用等步骤进行整合。这些任务原本需要项目团队自行维护，现在则通过提供多链数据和节点API的方式，实现了集成化运作。

借助这些API，用户可以根据自己的需求定制链上数据。这涵盖了从热门NFT元数据、监控特定地址的链上活动，到追踪特定代币流动性池的交易数据等各类需求。我经常将这种方法称为现代Web3项目结构的一部分。

数据层和索引层项目的融资和建设主要在2022年进行。我相信，这些索引层和数据层项目的商业实践与它们底层数据架构的设计密切相关，特别是与OLAP（On-Line Analytical Processing，联机分析处理）系统的设计关系深刻。采用合适的核心引擎，是优化索引层性能的关键，包括提升索引速度和保障其稳定性。常用的引擎有Hive、Spark SQL、Presto、Kylin、Impala、Druid、ClickHouse等。其中，ClickHouse是一个功能强大的数据库，在互联网公司中广泛应用，它在2016年开源，而且在2021年获得了2.5亿美元的融资。

因此，新一代的数据库和改进的数据索引优化架构的出现，促成了Web3数据索引层的创建。这使得在此领域的公司能以更快速、更高效的方式提供数据API服务。

然而，链上数据索引的大楼目前仍然被两朵乌云笼罩。

两朵乌云

第一朵乌云关乎区块链网络稳定性对服务器端造成的影响。尽管区块链网络具有很强的稳定性，但在数据传输和处理过程中并非如此。例如，区块链的重组（reorgs）和回滚（rollbacks）等事件可能对索引器的数据稳定性构成挑战。

区块链重组指的是节点暂时失去同步，导致两个不同版本的区块链同时存在。这样的情况可能由系统故障、网络延迟，甚至恶意行为引发。当节点重新同步时，它们将收敛到一个唯一的官方链，而先前的替代“分叉”区块则会被抛弃。

在重组发生时，索引器可能已经处理了来自最终被抛弃区块的数据导致数据库被污染。因此，索引器必须适应这种情况，丢弃无效链上的数据，并重新处理新接受的链上的数据。

这类调整可能会导致资源使用增加，并有可能延迟数据的可用性。在极端的情况下，频繁或大规模的区块重组可能会严重影响依赖于索引器的服务的可靠性和性能，包括那些使用API获取数据的Web3应用程序。

此外，我们还面临着关于数据格式兼容性和区块链网络间数据标准多样性的问题。

在区块链技术领域中，存在众多不同的网络，每一个网络都拥有自己独特的数据标准。比如，有EVM（以太坊虚拟机）兼容链、非EVM链，以及zk（零知识）链，每一种链都有其特殊的数据结构和格式。

这对索引器来说无疑是个大挑战。为了通过API提供有用且准确的数据，索引器需要能够处理这些多样化的数据格式。但是，由于区块链数据没有通用标准，不同的索引器可能会使用不同的API标准。这可能导致数据兼容性问题，即从一个索引器提取和转换的数据可能无法在另一个系统中使用。

此外，当开发者在这个多链世界中探索时，他们经常面临处理这些不同数据标准的挑战。一个适用于一个区块链网络的解决方案可能对另一个区块链网络无效，这使得开发可以与多个网络进行交互的应用程序变得困难。

的确，区块链索引行业面临的挑战让人想起了20世纪初开尔文勋爵在物理学中确定的两个未解决问题，这两个问题最终催生了量子力学和热力学等革命性领域。

面对这些挑战，业界确实采取了一些措施，例如在Kafka管道中引入延迟或集成流式处理，甚至建立一个标准联盟来加强区块链索引行业。这些措施目前的确能够解决区块链网络的不稳定性和数据标准的多样性，从而使索引器能够提供准确可靠的数据。

然而，正如量子理论的出现革命了我们对物理世界的理解一样，我们也可以考虑更激进的方法来改进区块链数据基础设施。

毕竟，现有的基础设施，以其井然有序的数据仓库和堆栈，可能看起来太完美、太美丽以至于让人难以置信。

那么，是否存在其他的道路呢？

寻找规律

让我们回到最初关于节点提供者和索引器出现的话题，并思考一个奇特的问题。为什么节点运营商没有在2010年出现，而索引器在2022年突然大量涌现并获得了大量的投资？

我相信我的上文已经部分回答了这些问题。这是因为云计算和数据仓库技术在软件行业中的广泛应用，而不仅仅在加密领域。

在加密领域，也发生了一些特别的事情，特别是当ERC20和ERC721标准在公众媒体上变得流行的时候。此外，DeFi夏季使得链上数据变得更加复杂。各种调用交易在不同的智能合约上进行路由，而不再只是早期阶段那样的简单交易数据，链上数据的格式和复杂性都发生了惊人的变化和增长。

虽然在加密货币社区内，一直强调与传统的Web2技术进行切割，但我们不能忽视的是，加密货币基础设施的发展是依赖于数学、密码学、云技术和大数据等领域的不断发展与突破。类似于中国传统的榫卯结构，加密货币生态系统中的各个组成部分都是紧密相连的。

科技的进步和创新应用总是会受到一些客观原则的约束。比如，如果没有椭圆曲线加密技术的基础支撑，我们今天的加密货币生态就无法存在。同样，如果没有麻省理工学院在1985年发表的关于零知识证明的重要研究论文，零知识证明的实践应用也将无法实现。因此，我们看到了一个有趣的模式。**节点服务提供商的广泛应用和扩张，正是基于全球云服务和虚拟化技术的快速增长。**与此同时，链上数据层的发展又是基于出色的开源数据库架构和服务的蓬勃发展，这些架构正是近年来众多商业智能产品所依赖的数据解决方案。这都是初创公司为了实现商业可行性而必须满足的技术前提条件。针对Web3项目来说，那些采用先进基础设施的项目往往比那些依赖过时架构的项目更具优势。OpenSea市场份额被更快速、更加用户友好的NFT交易所侵蚀，就是一个生动的例证。

此外，我们也可以看到一个明显的趋势：人工智能（AI）与 LLM技术已经逐渐成熟，并且具有广泛应用的可能性。

因此，一个重要的问题浮现出来：AI将如何改变链上数据的格局？

预测未来

预测未来总是充满困难的，但我们可以通过理解区块链开发中遇到的问题来探索可能的答案。开发者对链上数据有明确的需求：他们需要的是准确、及时，并且易于理解的链上数据。

我们目前面临的一个问题是，批量获取或是展示某些数据需要使用复杂的SQL查询。这也是为什么在加密社区中，Dune提供的开源SQL功能如此受欢迎。用户无需从头开始去写sql构建图表，只需fork并修改想要关注的智能合约地址，就可以创建他们所需的图表。然而，对于只希望在特定条件下查看流动性或空投数据的普通用户来说，这仍然过于复杂。

我认为，解决这个问题的第一步是利用LLM和自然语言处理。

我们可以构建更以用户为中心的“数据查询”界面，并利用LLM技术。在现有的情况下，用户必须使用诸如SQL或GraphQL这样的复杂查询语言，从API或Studios中提取相应的链上数据。但是，通过使用LLM，我们可以引入一种更直观、更符合人类习惯的提问方式。在这种方式下，用户可以用“自然语言”表达他们的问题，然后LLM会将其转化为合适的查询，并向用户提供他们所需的答案。

从开发者的视角出发，人工智能还可以优化链上合约事件的解析及ABI解码。目前，许多DeFi合约的细节都需要开发者手动解析和解码。但若引入人工智能，我们可以显著改进各类合约反汇编技术，迅速检索相应的ABI。结合大型语言模型（LLM），这种配置可以智能解析函数签名并高效处理各种数据类型。进一步地，当该系统与“流计算”处理框架相结合时，就能够实时处理交易数据的解析，满足用户的即时需求。

从更全局的角度看，索引器的目标是为用户提供精准数据。正如我之前所强调的，链上数据层的一个潜在问题是，各个数据片段分散在不同的索引器数据库中，且相互隔离。为满足多样化的数据需求，一些设计者选择将所有链上数据整合到一个数据库中，使用户能从单一的数据集中选取所需信息。有些协议则选择仅包含部分数据，比如DeFi数据和NFT数据。但数据标准不兼容的问题仍然存在。有时，开发者需要从多个来源获取数据并在自己的数据库中重新格式化，这无疑增加了他们的维护负担。此外，一旦某数据提供方出现问题，他们无法及时迁移到另一个提供方。

那么，LLM和人工智能如何解决这个问题呢？LlamaIndex为我提供了一个启示。假如开发者不需要索引器，而是利用一个部署的代理服务（agent）直接读取链上的原始数据，那会怎样？这个agent融合了索引器和LLM的技术。从用户的角度看，他们不需要了解任何关于API或查询语言的知识，他们只需要提出问题并即时得到反馈。

配备了LLM和人工智能技术，Agent能理解并处理原始数据，并将其转换为用户易于理解的格式。这消除了用户面对复杂API或查询语言的困扰，他们只需以自然语言提出问题，即可获得实时反馈。这一特性提高了数据的可访问性和用户友好度，吸引了更广泛的用户群体接触链上数据。

此外，代理服务(Agent)的方式解决了数据标准不兼容的问题。由于设计时已经考虑到它拥有解析和处理原始链上数据，它可以适应不同的数据格式和标准。因此，开发者无需从不同来源重新格式化数据，减轻了他们的工作负担。

当然，这只是对链上数据未来发展轨迹的一种推测。但在科技领域，通常是这些大胆的设想和理论推动了革命性的进步。我们应记住，无论是发明轮子还是区块链的诞生，所有的重大突破都源于某人的假设或"疯狂"想法。

在我们接受变革和不确定性的同时，我们也被挑战着不断拓展可能性的边界。在这个背景下，我们设想一个世界，人工智能、LLM和区块链的结合将孕育一个更加开放和包容的技术领域。

Chainbase秉承这一愿景，并致力于将其实现。

我们在Chainbase的使命是打造一个开放、友好、透明且可持续的加密数据基础设施。我们的目标是简化开发者对此类数据的使用，免去复杂的后端技术堆栈重构的必要性。通过这样的方式，我们希望迎来一个未来，在这个未来中，技术不仅服务于用户，更赋予他们力量。

然而，我必须澄清，这并不是我们的路线图。相反，这是我作为开发者关系代表，在社区中对链上数据最近发展和进展的个人思考。