De blockchain a LLM, una interpretación profunda de la evolución y los desafíos de la tecnología de indexación de datos

Desde que Satoshi Nakamoto decidió incrustar un mensaje en el bloque de génesis, la estructura de datos de la cadena Bitcoin ha sufrido una serie de cambios.

Empecé a estudiar en profundidad el desarrollo de blockchain en 2022, y el primer libro que leí fue "Mastering Ethereum". Este libro es excelente y me proporcionó una comprensión profunda de los fundamentos de Ethereum y Blockchain. Sin embargo, desde la perspectiva actual, algunas de las técnicas de desarrollo del libro se han vuelto algo obsoletas. Los pasos preliminares implican ejecutar un nodo en una computadora portátil personal, incluso para la dApp de billetera, lo que requiere que se descargue un nodo ligero por sí solo. Esto refleja el patrón de comportamiento de los primeros desarrolladores y piratas informáticos en el ecosistema de desarrollo de blockchain entre 2015 y 2018.

En 2017, no teníamos ningún proveedor de servicios de nodos. Desde una perspectiva de oferta y demanda, su función principal es realizar transacciones debido a la actividad limitada del usuario. Esto significa que mantener o alojar un nodo completo usted mismo no es una carga demasiado pesada, ya que no hay muchas solicitudes de RPC para procesar y las solicitudes de transferencia son poco frecuentes. La mayoría de los primeros usuarios de Ethereum son fanáticos de la tecnología. Estos primeros usuarios tienen un conocimiento profundo del desarrollo de blockchain y están acostumbrados a mantener directamente los nodos de Ethereum, crear transacciones y administrar cuentas a través de la línea de comandos o el entorno de desarrollo integrado.

Por lo tanto, podemos observar que los primeros proyectos suelen tener una UI/UX muy limpia. Algunos de estos proyectos ni siquiera tienen una interfaz y la actividad de los usuarios es bastante baja. Las características de estos proyectos vienen determinadas principalmente por dos factores: el comportamiento de los usuarios y la estructura de datos de la cadena.

El auge de los proveedores de nodos

A medida que más y más usuarios sin experiencia en programación se unen a la red blockchain, la arquitectura técnica de las aplicaciones descentralizadas también ha cambiado. El modo original de alojamiento de nodos por parte de los usuarios ha cambiado gradualmente a alojamiento de nodos por partes del proyecto.

Las personas tienden a elegir los servicios de alojamiento de nodos, principalmente porque el rápido crecimiento de los datos en la cadena hace que el costo de los nodos de alojamiento personal aumente gradualmente con el tiempo.

Sin embargo, los nodos autohospedados por equipos de proyecto siguen siendo un desafío para los desarrolladores de proyectos pequeños, que requieren una inversión de mantenimiento constante y costos de hardware. Por lo tanto, este complejo proceso de hospedaje de nodos generalmente se confía a empresas que se especializan en el mantenimiento de nodos. Vale la pena mencionar que el momento de la construcción y recaudación de fondos a gran escala de estas empresas coincide con la tendencia al alza de los servicios en la nube en la industria tecnológica de América del Norte.

| Proyecto | Categoría | Establecido desde | | --- | --- | --- | | Alquimia | Nodos | 2017 | | Infura | Nodos | 2016 | | Ahora nodos | Nodos | 2019 | | QuickNodes | Nodos | 2017 | | Ancla | nodos | 2017 | | Pila de cadena | Nodos | 2018 |

El simple hecho de alojar nodos de forma remota no puede resolver el problema por completo, especialmente ahora que están surgiendo protocolos relacionados como DeFi y NFT. Los desarrolladores deben lidiar con muchos problemas de datos, porque los datos proporcionados por los propios nodos de blockchain se denominan datos sin procesar, que no están estandarizados ni limpios. Los datos que contiene deben extraerse, limpiarse y cargarse.

Por ejemplo, supongamos que soy un desarrollador de un proyecto NFT y quiero realizar transacciones NFT o mostrar NFT. Luego, mi interfaz necesita leer los datos NFT en la cuenta EOA personal en tiempo real. NFT es realmente solo una forma estandarizada de token. Ser propietario de un NFT significa que poseo un token con una ID única generada por el contrato de NFT, y la imagen del NFT es en realidad metadatos, que pueden ser datos SVG o un enlace a una imagen en IPFS. Aunque el cliente Geth de Ethereum proporciona instrucciones de indexación, para algunos proyectos con grandes requisitos de front-end, no es práctico solicitar Geth continuamente y luego volver al front-end. Para algunas funciones, como la subasta de pedidos y la agregación de transacciones NFT, deben llevarse a cabo fuera de la cadena para recopilar las instrucciones del usuario y luego enviar estas instrucciones a la cadena en el momento apropiado.

Por lo tanto, nació una capa de datos simple. Para cumplir con los requisitos de tiempo real y precisión de los usuarios, la parte del proyecto debe crear su propia base de datos y funciones de análisis de datos.

**¿Cómo evolucionó el indexador de datos? **

Comenzar un proyecto suele ser un asunto relativamente simple. Tienes una idea, estableces algunos objetivos, encuentras a los mejores ingenieros y construyes un prototipo funcional, que generalmente incluye una interfaz y algunos contratos inteligentes.

Sin embargo, es bastante difícil hacer escalar el proyecto. Uno necesita pensar profundamente en la estructura de diseño desde el primer día del proyecto. De lo contrario, puede tener problemas rápidamente, a los que generalmente me refiero como "problemas de formación de hielo".

Tomé prestado este término de la película "Iron Man" y parece muy adecuado para describir la situación de la mayoría de las empresas emergentes. Cuando las empresas emergentes crecen rápidamente (atraen a muchos usuarios), a menudo se encuentran con problemas porque no lo previeron en primer lugar. En la película, el villano nunca esperó que su equipo de guerra volara al espacio porque no tuvo en cuenta el "problema de la formación de hielo". Del mismo modo, para los desarrolladores de muchos proyectos Web3, el "problema de congelación" implica lidiar con la mayor carga de la adopción masiva de usuarios. Esto ejerce una gran presión sobre el lado del servidor a medida que la cantidad de usuarios crece dramáticamente. También hay problemas relacionados con la propia cadena de bloques, como problemas de red o cierres de nodos.

La mayoría de las veces es un problema de back-end. Por ejemplo, en algunos protocolos de juegos de blockchain, esta situación no es infrecuente. Cuando planearon agregar más servidores y contratar más ingenieros de datos para analizar los datos en la cadena, no previeron la participación de tantos usuarios. Cuando se dieron cuenta de esto, ya era demasiado tarde. Y estos problemas técnicos no se pueden resolver simplemente agregando más ingenieros de back-end. Como dije antes, estas consideraciones deben incorporarse al plan desde el principio.

El segundo problema consiste en agregar nuevas cadenas de bloques. Probablemente evitó los problemas del lado del servidor en primer lugar y contrató a un grupo de buenos ingenieros. Sin embargo, es posible que sus usuarios no estén contentos con la cadena de bloques actual. Quieren que su servicio también se ejecute en otras cadenas populares como cadenas zk o cadenas L2. La estructura de su proyecto podría terminar luciendo así:

En este tipo de sistema, tiene control total sobre sus datos, lo que permite una mejor gestión y una mayor seguridad. El sistema limita las solicitudes de llamadas, lo que reduce el riesgo de sobrecarga y aumenta la eficiencia. Y la configuración es compatible con el front-end, lo que garantiza una integración y una experiencia de usuario perfectas.

Sin embargo, los costos de operación y mantenimiento se multiplican, lo que puede ejercer presión sobre sus recursos. Agregar una nueva cadena de bloques cada vez requiere un trabajo repetido, lo que puede llevar mucho tiempo y ser ineficiente. La selección de datos de grandes conjuntos de datos puede reducir los tiempos de consulta, lo que podría ralentizar el proceso. Debido a problemas de la red blockchain, como reversiones y reorganizaciones, los datos pueden contaminarse, lo que compromete la integridad y la confiabilidad de los datos.

Los proyectos están diseñados para reflejar a los miembros de su equipo. Agregar más nodos e intentar construir un sistema centrado en el backend significa que necesita contratar más ingenieros para operar esos nodos y decodificar los datos sin procesar.

Este modelo es similar a los primeros días de Internet, cuando las plataformas de comercio electrónico y los desarrolladores de aplicaciones optaron por construir sus propias instalaciones de IDC (Centro de datos de Internet). Sin embargo, el costo va de la mano con la complejidad del diseño del programa a medida que crecen las solicitudes de los usuarios y explota el estado de la red blockchain. Además, este enfoque dificulta la rápida expansión del mercado. Algunas cadenas de bloques públicas de alto rendimiento requieren operaciones de nodo con uso intensivo de hardware, mientras que la sincronización y limpieza de datos consumen recursos humanos y costos de tiempo.

Si está tratando de construir un mercado NFT basado en blockchain o un juego genial, ¿no es sorprendente que el 65% de los miembros de su equipo sean ingenieros de back-end y de datos?

**Quizás los desarrolladores se pregunten por qué nadie decodifica y transmite estos datos en cadena para que puedan concentrarse en crear mejores productos. **

** Creo que es por eso que existen los indexadores. **

Con el fin de reducir la dificultad de acceder a las aplicaciones Web3 y las redes de cadena de bloques, muchos equipos de desarrollo, incluido nosotros, optan por integrar pasos como el mantenimiento de nodos de archivo, ETL (extracción, transformación, carga) de datos en cadena y llamadas a bases de datos. Estas tareas originalmente requerían que el equipo del proyecto se mantuviera a sí mismo, pero ahora han realizado operaciones integradas al proporcionar datos de múltiples cadenas y API de nodos.

Con la ayuda de estas API, los usuarios pueden personalizar los datos en cadena según sus necesidades. Esto cubre todo, desde metadatos NFT populares, monitoreo de la actividad en cadena de direcciones específicas, hasta el seguimiento de datos de transacciones de fondos de liquidez de tokens específicos. A menudo me refiero a este enfoque como parte de la estructura de los proyectos Web3 modernos.

La financiación y construcción de los proyectos de capa de datos y capa de índice se realizarán principalmente en 2022. Creo que las prácticas comerciales de estos proyectos de capa de índice y capa de datos están estrechamente relacionadas con el diseño de su arquitectura de datos subyacente, especialmente con el diseño de sistemas OLAP (procesamiento analítico en línea). La adopción de un motor central adecuado es la clave para optimizar el rendimiento de la capa de índice, incluida la mejora de la velocidad de indexación y la garantía de su estabilidad. Los motores de uso común incluyen Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse, etc. Entre ellos, ClickHouse es una poderosa base de datos muy utilizada en las empresas de Internet, fue open source en 2016 y recibió una financiación de 250 millones de dólares estadounidenses en 2021.

Por lo tanto, la aparición de una nueva generación de bases de datos y arquitecturas mejoradas de optimización de índices de datos ha llevado a la creación de la capa de índice de datos Web3. Esto permite a las empresas de este campo proporcionar servicios de API de datos de una manera más rápida y eficiente.

Sin embargo, la construcción de la indexación de datos en cadena todavía está envuelta en dos nubes oscuras.

Dos nubes oscuras

La primera nube oscura trata sobre el impacto de la estabilidad de la red blockchain en el lado del servidor. Aunque la red blockchain tiene una gran estabilidad, no es el caso durante la transmisión y el procesamiento de datos. Por ejemplo, eventos como reorganizaciones (reorgs) y retrocesos (retrocesos) de la cadena de bloques pueden plantear desafíos para la estabilidad de los datos del indexador.

Una reorganización de la cadena de bloques es cuando los nodos pierden temporalmente la sincronización, lo que hace que existan dos versiones diferentes de la cadena de bloques al mismo tiempo. Tales situaciones pueden desencadenarse por fallas del sistema, demoras en la red o incluso comportamiento malicioso. Cuando los nodos se vuelvan a sincronizar, convergerán en una sola cadena oficial y los bloques "bifurcados" alternativos anteriores se descartarán.

En el momento en que se produce la reorganización, es posible que el indexador haya procesado datos de bloques que finalmente se descartaron, lo que contaminó la base de datos. Por lo tanto, los indexadores deben adaptarse a esta situación, descartando datos de cadenas no válidas y reprocesando datos de cadenas recién aceptadas.

Dichos ajustes pueden resultar en un mayor uso de recursos y potencialmente retrasar la disponibilidad de datos. En casos extremos, las reorganizaciones de bloques frecuentes oa gran escala pueden afectar gravemente la confiabilidad y el rendimiento de los servicios que dependen de los indexadores, incluidas aquellas aplicaciones Web3 que usan API para obtener datos.

Además, nos enfrentamos a problemas relacionados con la compatibilidad de formatos de datos y la diversidad de estándares de datos en las redes de cadena de bloques.

En el campo de la tecnología blockchain, existen muchas redes diferentes, cada una con sus propios estándares de datos únicos. Por ejemplo, hay cadenas compatibles con EVM (Ethereum Virtual Machine), cadenas que no son EVM y cadenas zk (conocimiento cero), cada una de las cuales tiene su propia estructura y formato de datos especiales.

Este es sin duda un gran desafío para los indexadores. Para proporcionar datos útiles y precisos a través de las API, los indexadores deben poder manejar estos diversos formatos de datos. Sin embargo, dado que no existe un estándar universal para los datos de blockchain, diferentes indexadores pueden usar diferentes estándares de API. Esto puede generar problemas de compatibilidad de datos, donde los datos extraídos y transformados de un indexador pueden no ser utilizables en otro sistema.

Además, a medida que los desarrolladores exploran este mundo de múltiples cadenas, a menudo enfrentan el desafío de lidiar con estos diferentes estándares de datos. Una solución que funciona para una red de cadena de bloques puede no funcionar para otra, lo que dificulta el desarrollo de aplicaciones que puedan interactuar con varias redes.

De hecho, los desafíos que enfrenta la industria de indexación de blockchain recuerdan dos problemas sin resolver en física identificados por Lord Kelvin a principios del siglo XX, que finalmente dieron origen a campos revolucionarios como la mecánica cuántica y la termodinámica.

Frente a estos desafíos, la industria ha tomado algunas medidas, como la introducción de la latencia o la integración de la transmisión en la canalización de Kafka, e incluso el establecimiento de un consorcio de estándares para fortalecer la industria de indexación de blockchain. Actualmente, estas medidas pueden abordar la inestabilidad de las redes blockchain y la diversidad de estándares de datos, de modo que los indexadores puedan proporcionar datos precisos y confiables.

Sin embargo, así como el advenimiento de la teoría cuántica revolucionó nuestra comprensión del mundo físico, también podemos considerar formas más radicales de mejorar la infraestructura de datos de la cadena de bloques.

**Después de todo, la infraestructura existente, con sus depósitos y pilas de datos cuidadosamente organizados, puede parecer demasiado perfecta y demasiado hermosa para ser verdad. **

Entonces, ** ¿Hay alguna otra manera? **

Encontrar patrones

Volvamos al tema original sobre la aparición de proveedores de nodos e indexadores, y consideremos un problema peculiar. ¿Por qué los operadores de nodos no aparecieron en 2010, pero los indexadores aparecieron repentinamente en grandes cantidades y recibieron una gran inversión en 2022?

Creo que lo anterior ha respondido parcialmente a estas preguntas. Esto se debe al uso generalizado de la computación en la nube y las tecnologías de almacenamiento de datos en la industria del software, no solo en el campo del cifrado.

En el mundo del cifrado, también sucedió algo especial, especialmente cuando los estándares ERC20 y ERC721 se hicieron populares en los medios públicos. Además, el verano de DeFi ha hecho que los datos en cadena sean más complicados. Varias transacciones de llamadas se enrutan en diferentes contratos inteligentes, en lugar de datos de transacciones simples como en la etapa inicial, el formato y la complejidad de los datos en cadena han experimentado cambios y crecimientos sorprendentes.

Aunque en la comunidad de criptomonedas siempre se ha enfatizado separarse de la tecnología Web2 tradicional, lo que no podemos ignorar es que el desarrollo de la infraestructura de criptomonedas se basa en el desarrollo continuo y los avances en los campos de las matemáticas, la criptografía, la tecnología en la nube y los grandes datos. . . Similar a la estructura tradicional china de mortaja y espiga, los diversos componentes del ecosistema de criptomonedas están estrechamente conectados.

El progreso y la aplicación innovadora de la ciencia y la tecnología estarán siempre ligados a unos principios objetivos. Por ejemplo, sin el soporte básico de la tecnología de cifrado de curva elíptica, nuestro ecosistema de criptomonedas actual no puede existir. Asimismo, la aplicación práctica de las pruebas de conocimiento cero no hubiera sido posible sin el importante trabajo de investigación sobre pruebas de conocimiento cero publicado por el MIT en 1985. Así que vemos un patrón interesante. ** La amplia aplicación y expansión de los proveedores de servicios de nodos se basa en el rápido crecimiento de los servicios globales en la nube y la tecnología de virtualización. ** Al mismo tiempo, El desarrollo de la capa de datos en la cadena se basa en el vigoroso desarrollo de excelentes servicios y arquitectura de base de datos de código abierto,** estas arquitecturas son las soluciones de datos que muchos productos de inteligencia comercial confiar en los últimos años **. Todos estos son requisitos técnicos que deben cumplir las empresas emergentes para lograr la viabilidad comercial. Cuando se trata de proyectos Web3, aquellos que emplean infraestructura avanzada tienden a tener una ventaja sobre aquellos que dependen de arquitecturas obsoletas. La erosión de la cuota de mercado de OpenSea por intercambios NFT más rápidos y fáciles de usar es un ejemplo vívido.

Además, también podemos ver una tendencia obvia: la inteligencia artificial (IA) y la tecnología LLM han madurado gradualmente y tienen la posibilidad de una amplia aplicación.

**Por lo tanto, surge una pregunta importante: ¿Cómo cambiará la IA el patrón de datos en la cadena? **

Adivinación

Predecir el futuro siempre está plagado de dificultades, pero podemos explorar posibles respuestas al comprender los problemas encontrados en el desarrollo de blockchain. **Los desarrolladores tienen una clara demanda de datos en cadena: lo que necesitan son datos en cadena precisos, oportunos y fáciles de entender. **

Uno de los problemas que enfrentamos actualmente es que se requieren consultas SQL complejas para obtener o mostrar ciertos datos en lotes. Esta es la razón por la que la funcionalidad SQL de código abierto proporcionada por Dune es tan popular en la comunidad criptográfica. Los usuarios no necesitan escribir sql para crear gráficos desde cero, solo necesitan bifurcar y modificar la dirección del contrato inteligente al que quieren prestar atención, y luego pueden crear los gráficos que necesitan. Sin embargo, esto sigue siendo demasiado complicado para el usuario promedio que solo desea ver datos de liquidez o airdrop bajo ciertas condiciones.

En mi opinión, el primer paso para resolver este problema es utilizar LLM y procesamiento de lenguaje natural.

Podemos construir una interfaz de "consulta de datos" más centrada en el usuario y aprovechar las técnicas de LLM. En los casos existentes, los usuarios deben usar lenguajes de consulta complejos como SQL o GraphQL para extraer los datos en cadena correspondientes de API o Studios. Sin embargo, al usar LLM, podemos introducir una forma más intuitiva y humana de hacer preguntas. De esta manera, los usuarios pueden expresar sus preguntas en "lenguaje natural", y LLM las traducirá en consultas adecuadas y les brindará las respuestas que necesitan.

Desde la perspectiva de los desarrolladores, la inteligencia artificial también puede optimizar el análisis de eventos de contrato en la cadena y la decodificación ABI. Actualmente, los detalles de muchos contratos de DeFi requieren que los desarrolladores los analicen y decodifiquen manualmente. Sin embargo, si se introduce la inteligencia artificial, podemos mejorar significativamente varias técnicas de desmontaje de contratos y recuperar rápidamente el ABI correspondiente. Combinada con un modelo de lenguaje grande (LLM), esta configuración puede analizar de manera inteligente las firmas de funciones y manejar de manera eficiente varios tipos de datos. Además, cuando el sistema se combina con el marco de procesamiento de "stream computing", puede procesar el análisis de datos de transacciones en tiempo real para satisfacer las necesidades inmediatas de los usuarios.

Desde una perspectiva más global, el objetivo de un indexador es proporcionar a los usuarios datos precisos. Como he destacado antes, un problema potencial con la capa de datos en cadena es que los datos individuales están dispersos en diferentes bases de datos indexadoras y aislados entre sí. Para satisfacer las diversas necesidades de datos, algunos diseñadores optan por integrar todos los datos de la cadena en una base de datos, de modo que los usuarios puedan seleccionar la información requerida de un único conjunto de datos. Algunos protocolos eligen incluir solo algunos datos, como datos DeFi y datos NFT. Pero el problema de los estándares de datos incompatibles todavía existe. A veces, los desarrolladores necesitan obtener datos de múltiples fuentes y reformatearlos en su propia base de datos, lo que sin duda aumenta su carga de mantenimiento. Además, no pueden migrar a otro proveedor de manera oportuna en caso de que haya un problema con un proveedor de datos.

Entonces, ¿cómo pueden LLM e AI resolver este problema? LlamaIndex me proporcionó una revelación. ¿Qué pasa si los desarrolladores no necesitan un indexador, pero usan un servicio de proxy implementado (agente) para leer directamente los datos sin procesar en la cadena? Este agente combina las tecnologías de indexador y LLM. Desde el punto de vista del usuario, no necesita saber nada sobre la API o el lenguaje de consulta, solo necesita hacer preguntas y obtener comentarios instantáneos.

Equipado con LLM y tecnología de inteligencia artificial, Agent comprende y procesa datos sin procesar y los convierte a un formato que es fácil de entender para los usuarios. Esto elimina la necesidad de que los usuarios se enfrenten a API complejas o lenguajes de consulta, y simplemente pueden hacer preguntas en lenguaje natural y obtener comentarios en tiempo real. Esta característica aumenta la accesibilidad y la facilidad de uso de los datos, atrayendo a una base de usuarios más amplia para acceder a los datos en cadena.

Además, la forma de servicio del agente (Agent) resuelve el problema de la incompatibilidad estándar de datos. Dado que ha sido diseñado con la capacidad de analizar y procesar datos sin procesar en cadena, puede adaptarse a diferentes formatos y estándares de datos. Como resultado, los desarrolladores no necesitan reformatear los datos de diferentes fuentes, lo que reduce su carga de trabajo.

Por supuesto, esto es solo una especulación sobre la trayectoria de desarrollo futuro de los datos en cadena. Pero en tecnología, a menudo son estas ideas y teorías audaces las que impulsan el progreso revolucionario. Debemos recordar que, ya sea que se trate de la invención de la rueda o del nacimiento de la cadena de bloques, todos los avances importantes parten de la suposición de alguien o de una idea "loca".

A medida que aceptamos el cambio y la incertidumbre, también nos enfrentamos al desafío de empujar continuamente los límites de la posibilidad. En este contexto, visualizamos un mundo donde la combinación de IA, LLM y blockchain generará un campo tecnológico más abierto e inclusivo.

Chainbase defiende esta visión y se compromete a hacerla realidad.

Nuestra misión en Chainbase es crear una infraestructura de datos cifrados abierta, amigable, transparente y sostenible. Nuestro objetivo es simplificar el uso de estos datos por parte de los desarrolladores, eliminando la necesidad de una refactorización compleja de la pila de tecnología de back-end. De esta manera, esperamos marcar el comienzo de un futuro en el que la tecnología no solo sirva a los usuarios, sino que los empodere.

Sin embargo, debo aclarar que esta no es nuestra hoja de ruta. Más bien, esta es mi reflexión personal sobre el desarrollo y el progreso recientes de los datos en cadena en la comunidad como representante de relaciones con los desarrolladores.