Tragedia de los comunes en la encriptación: la dificultad del índice de datos en el mercado de predicción
Resumen
Bienvenido a la serie "Tragedia de los Comunes en la Encriptación". Esta serie se centra en los "bienes públicos" que se encuentran en un punto crítico en el mundo encriptado pero que están perdiendo su norma. Estas infraestructuras a menudo enfrentan la falta de incentivos, el desequilibrio en la gobernanza e incluso la gradual centralización.
En esta edición, nos enfocamos en una de las aplicaciones más destacadas del ecosistema de Ethereum: Polymarket y su herramienta de indexación de datos. En torno a eventos como la victoria de Trump y la manipulación de oráculos en el comercio de tierras raras de Ucrania, Polymarket se ha convertido en el centro de atención varias veces. Sin embargo, este producto que representa el "mercado de predicción descentralizado", ¿realmente ha logrado la descentralización en su módulo básico clave: la indexación de datos? ¿Por qué infraestructuras públicas como The Graph no han podido cumplir con el papel esperado? ¿Qué forma debería tener un bien público de indexación de datos que sea verdaderamente útil y sostenible?
Uno, la reacción en cadena provocada por la caída de la plataforma de datos centralizada
En julio de 2024, Goldsky sufrió un incidente de caída que duró seis horas, lo que llevó a que una gran parte de los proyectos del ecosistema de Ethereum quedara paralizada. La interfaz de DeFi no podía mostrar los datos de posiciones y saldos de los usuarios, el mercado de predicción Polymarket no podía mostrar datos correctos, y innumerables proyectos parecían completamente inoperantes para los usuarios.
Esto no debería suceder en el mundo de las aplicaciones descentralizadas. ¿No es el propósito del diseño de la tecnología blockchain eliminar los puntos únicos de fallo? El evento Goldsky expuso un hecho inquietante: aunque la blockchain en sí misma ha logrado la descentralización tanto como sea posible, la infraestructura utilizada por las aplicaciones construidas sobre la cadena a menudo incluye una gran cantidad de servicios centralizados.
La indexación y recuperación de datos en blockchain pertenece a productos públicos digitales "no exclusivos y no competitivos". Los usuarios a menudo esperan que sean gratuitos o con tarifas muy bajas, pero detrás de esto se requiere una inversión continua en hardware, almacenamiento, ancho de banda y personal de operaciones de alto nivel. Cuando falta un modelo de rentabilidad sostenible, aparece un patrón de concentración donde el ganador se lleva todo: mientras un proveedor de servicios obtenga una ventaja inicial en velocidad y capital, los desarrolladores tienden a dirigir todo el tráfico de consultas hacia ese servicio, lo que a su vez genera una dependencia de un único punto.
Esto nos alerta que el mundo descentralizado necesita urgentemente enriquecer la diversidad de la infraestructura Web3 a través de financiamiento de bienes públicos, redistribución o iniciativas impulsadas por la comunidad, de lo contrario, surgirán problemas de centralización. Hacemos un llamado a los desarrolladores de DApp para que construyan productos con prioridad local y también instamos a la comunidad técnica a considerar la posibilidad de fallos en los servicios de recuperación de datos al diseñar DApps, garantizando que los usuarios aún puedan interactuar con los proyectos sin la infraestructura de recuperación de datos.
Dos, investigación sobre las fuentes de datos de Dapp
Para entender la ocurrencia de eventos como Goldsky, necesitamos profundizar en el mecanismo de trabajo detrás de los DApp. Para el usuario común, un DApp generalmente consta de dos partes: el contrato en la cadena y la página frontal. Pero, ¿de dónde provienen realmente los datos que se muestran en la interfaz del usuario?
La necesidad del servicio de recuperación de datos
Tomando como ejemplo la construcción de un protocolo de préstamos, este protocolo necesita mostrar la situación de las posiciones de los usuarios, así como el margen y el estado de la deuda de cada posición. Leer estos datos directamente de la cadena a menudo no es factible en la práctica, ya que los contratos generalmente solo ofrecen funciones para consultar datos específicos utilizando el ID de la posición. Para mostrar la situación de las posiciones de los usuarios en el frontend, es necesario recuperar todas las posiciones dentro del sistema y luego filtrar la parte que pertenece al usuario actual. Este proceso, incluso si se ejecuta directamente en el servidor confiando en un nodo local, a menudo también requiere varias horas.
Por lo tanto, se vuelve necesario introducir infraestructura para acelerar la obtención de datos. Empresas como Goldsky son las que proporcionan estos servicios de indexación de datos.
La relación entre TheGraph / Goldsky y SubGraph
SubGraph es un marco de desarrollo utilizado para leer y agregar datos en cadena, y mostrar esos datos en el front-end. TheGraph y Goldsky son en realidad ambos proveedores de SubGraph. Los programas desarrollados con el marco SubGraph necesitan ejecutarse en un servidor, y diferentes proveedores tienen diferentes estrategias y soluciones técnicas.
El modelo de tarifas de Goldsky
Goldsky utiliza un estándar de facturación basado en el uso de recursos, que es el método de facturación más común en las plataformas SaaS de Internet.
El modelo de tarifas de TheGraph
TheGraph tiene un conjunto de tarifas que difieren de los métodos de facturación convencionales, relacionadas con la economía del token GRT. Incluye tarifas de consulta por evento y tarifas de participación de Signal.
La difícil situación que enfrentan los desarrolladores
Para la mayoría de los desarrolladores, usar TheGraph es relativamente complicado. Principalmente hay dos problemas:
La incertidumbre en la cantidad de GRT apostados y el tiempo necesario para atraer a los operadores.
La complejidad de la contabilidad y el cálculo de costos
En comparación, elegir Goldsky es mucho más sencillo, el método de facturación es fácil de entender y se puede usar casi de inmediato, lo que reduce significativamente la incertidumbre. Esto ha llevado a una dependencia de un solo producto en el servicio de indexación y recuperación de datos de blockchain.
Tres, soluciones existentes
ponder
ponder es un software de servicio de recuperación de datos que es simple, con una buena experiencia de desarrollo y fácil de implementar. Sus ventajas incluyen:
Sin dependencia de proveedores
Buena experiencia de desarrollo
Mejor rendimiento
El enfoque comercial de ponder se alinea con la "teoría de la separación", logrando la fijación de precios a través de la imposición de tarifas a ciertos grupos homogéneos.
concepto de desarrollo local-first
En el desarrollo de blockchain, la filosofía local-first se puede implementar de la siguiente manera:
Caché de datos clave
Diseño de funcionalidad de degradación
Este diseño puede mejorar significativamente la resiliencia de la aplicación, evitando que la aplicación no esté disponible después de un colapso en el servicio de recuperación de datos.
Cuarta, conclusión
El incidente de fallos de Goldsky es una llamada de atención para el ecosistema. Aunque la encriptación en sí misma tiene características de descentralización y resistencia a fallos de un solo punto, el ecosistema de aplicaciones construido sobre ella sigue dependiendo en gran medida de los servicios de infraestructura centralizados, lo que representa un riesgo sistémico para todo el ecosistema.
Este artículo discute las razones por las cuales TheGraph no es ampliamente utilizado, presenta el marco de auto-alojamiento de ponder como una opción de emergencia, y explora la filosofía de desarrollo local-prioritario. Hacemos un llamado a más desarrolladores para que presten atención a la infraestructura de recuperación de datos, intenten construir servicios descentralizados o diseñar marcos que permitan que el frontend de las DApp siga funcionando sin servicios de recuperación de datos.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
6 me gusta
Recompensa
6
4
Republicar
Compartir
Comentar
0/400
FloorPriceWatcher
· hace21h
¿Vaya, es tan difícil hacer un índice?
Ver originalesResponder0
Fren_Not_Food
· hace21h
Gran capital controla el mercado de predicción [笑死]
Ver originalesResponder0
DaisyUnicorn
· hace22h
Cadena de bloques datos pequeño jardinero, todo el día buscando una pequeña margarita de Descentralización que florezca~
Ver originalesResponder0
SatoshiNotNakamoto
· hace22h
Por lo tanto, el mercado se estabilizó en septiembre.
Dilema de Polymarket: el problema de la Descentralización del índice de datos del mercado de predicción
Tragedia de los comunes en la encriptación: la dificultad del índice de datos en el mercado de predicción
Resumen
Bienvenido a la serie "Tragedia de los Comunes en la Encriptación". Esta serie se centra en los "bienes públicos" que se encuentran en un punto crítico en el mundo encriptado pero que están perdiendo su norma. Estas infraestructuras a menudo enfrentan la falta de incentivos, el desequilibrio en la gobernanza e incluso la gradual centralización.
En esta edición, nos enfocamos en una de las aplicaciones más destacadas del ecosistema de Ethereum: Polymarket y su herramienta de indexación de datos. En torno a eventos como la victoria de Trump y la manipulación de oráculos en el comercio de tierras raras de Ucrania, Polymarket se ha convertido en el centro de atención varias veces. Sin embargo, este producto que representa el "mercado de predicción descentralizado", ¿realmente ha logrado la descentralización en su módulo básico clave: la indexación de datos? ¿Por qué infraestructuras públicas como The Graph no han podido cumplir con el papel esperado? ¿Qué forma debería tener un bien público de indexación de datos que sea verdaderamente útil y sostenible?
Uno, la reacción en cadena provocada por la caída de la plataforma de datos centralizada
En julio de 2024, Goldsky sufrió un incidente de caída que duró seis horas, lo que llevó a que una gran parte de los proyectos del ecosistema de Ethereum quedara paralizada. La interfaz de DeFi no podía mostrar los datos de posiciones y saldos de los usuarios, el mercado de predicción Polymarket no podía mostrar datos correctos, y innumerables proyectos parecían completamente inoperantes para los usuarios.
Esto no debería suceder en el mundo de las aplicaciones descentralizadas. ¿No es el propósito del diseño de la tecnología blockchain eliminar los puntos únicos de fallo? El evento Goldsky expuso un hecho inquietante: aunque la blockchain en sí misma ha logrado la descentralización tanto como sea posible, la infraestructura utilizada por las aplicaciones construidas sobre la cadena a menudo incluye una gran cantidad de servicios centralizados.
La indexación y recuperación de datos en blockchain pertenece a productos públicos digitales "no exclusivos y no competitivos". Los usuarios a menudo esperan que sean gratuitos o con tarifas muy bajas, pero detrás de esto se requiere una inversión continua en hardware, almacenamiento, ancho de banda y personal de operaciones de alto nivel. Cuando falta un modelo de rentabilidad sostenible, aparece un patrón de concentración donde el ganador se lleva todo: mientras un proveedor de servicios obtenga una ventaja inicial en velocidad y capital, los desarrolladores tienden a dirigir todo el tráfico de consultas hacia ese servicio, lo que a su vez genera una dependencia de un único punto.
Esto nos alerta que el mundo descentralizado necesita urgentemente enriquecer la diversidad de la infraestructura Web3 a través de financiamiento de bienes públicos, redistribución o iniciativas impulsadas por la comunidad, de lo contrario, surgirán problemas de centralización. Hacemos un llamado a los desarrolladores de DApp para que construyan productos con prioridad local y también instamos a la comunidad técnica a considerar la posibilidad de fallos en los servicios de recuperación de datos al diseñar DApps, garantizando que los usuarios aún puedan interactuar con los proyectos sin la infraestructura de recuperación de datos.
Dos, investigación sobre las fuentes de datos de Dapp
Para entender la ocurrencia de eventos como Goldsky, necesitamos profundizar en el mecanismo de trabajo detrás de los DApp. Para el usuario común, un DApp generalmente consta de dos partes: el contrato en la cadena y la página frontal. Pero, ¿de dónde provienen realmente los datos que se muestran en la interfaz del usuario?
La necesidad del servicio de recuperación de datos
Tomando como ejemplo la construcción de un protocolo de préstamos, este protocolo necesita mostrar la situación de las posiciones de los usuarios, así como el margen y el estado de la deuda de cada posición. Leer estos datos directamente de la cadena a menudo no es factible en la práctica, ya que los contratos generalmente solo ofrecen funciones para consultar datos específicos utilizando el ID de la posición. Para mostrar la situación de las posiciones de los usuarios en el frontend, es necesario recuperar todas las posiciones dentro del sistema y luego filtrar la parte que pertenece al usuario actual. Este proceso, incluso si se ejecuta directamente en el servidor confiando en un nodo local, a menudo también requiere varias horas.
Por lo tanto, se vuelve necesario introducir infraestructura para acelerar la obtención de datos. Empresas como Goldsky son las que proporcionan estos servicios de indexación de datos.
La relación entre TheGraph / Goldsky y SubGraph
SubGraph es un marco de desarrollo utilizado para leer y agregar datos en cadena, y mostrar esos datos en el front-end. TheGraph y Goldsky son en realidad ambos proveedores de SubGraph. Los programas desarrollados con el marco SubGraph necesitan ejecutarse en un servidor, y diferentes proveedores tienen diferentes estrategias y soluciones técnicas.
El modelo de tarifas de Goldsky
Goldsky utiliza un estándar de facturación basado en el uso de recursos, que es el método de facturación más común en las plataformas SaaS de Internet.
El modelo de tarifas de TheGraph
TheGraph tiene un conjunto de tarifas que difieren de los métodos de facturación convencionales, relacionadas con la economía del token GRT. Incluye tarifas de consulta por evento y tarifas de participación de Signal.
La difícil situación que enfrentan los desarrolladores
Para la mayoría de los desarrolladores, usar TheGraph es relativamente complicado. Principalmente hay dos problemas:
En comparación, elegir Goldsky es mucho más sencillo, el método de facturación es fácil de entender y se puede usar casi de inmediato, lo que reduce significativamente la incertidumbre. Esto ha llevado a una dependencia de un solo producto en el servicio de indexación y recuperación de datos de blockchain.
Tres, soluciones existentes
ponder
ponder es un software de servicio de recuperación de datos que es simple, con una buena experiencia de desarrollo y fácil de implementar. Sus ventajas incluyen:
El enfoque comercial de ponder se alinea con la "teoría de la separación", logrando la fijación de precios a través de la imposición de tarifas a ciertos grupos homogéneos.
concepto de desarrollo local-first
En el desarrollo de blockchain, la filosofía local-first se puede implementar de la siguiente manera:
Este diseño puede mejorar significativamente la resiliencia de la aplicación, evitando que la aplicación no esté disponible después de un colapso en el servicio de recuperación de datos.
Cuarta, conclusión
El incidente de fallos de Goldsky es una llamada de atención para el ecosistema. Aunque la encriptación en sí misma tiene características de descentralización y resistencia a fallos de un solo punto, el ecosistema de aplicaciones construido sobre ella sigue dependiendo en gran medida de los servicios de infraestructura centralizados, lo que representa un riesgo sistémico para todo el ecosistema.
Este artículo discute las razones por las cuales TheGraph no es ampliamente utilizado, presenta el marco de auto-alojamiento de ponder como una opción de emergencia, y explora la filosofía de desarrollo local-prioritario. Hacemos un llamado a más desarrolladores para que presten atención a la infraestructura de recuperación de datos, intenten construir servicios descentralizados o diseñar marcos que permitan que el frontend de las DApp siga funcionando sin servicios de recuperación de datos.