Trilogia da Tragédia dos Comuns Criptográficos: o problema do índice de dados do mercado de previsão descentralizado
Resumo
Este artigo foca na aplicação do mercado de previsão Polymarket e na sua ferramenta de indexação de dados no ecossistema Ethereum. Como representante do "mercado de previsão descentralizado", o módulo fundamental da Polymarket — a indexação de dados — realmente conseguiu alcançar a descentralização? Por que infraestruturas públicas como a The Graph não conseguiram desempenhar o papel esperado? Que forma deve ter um bem público de indexação de dados que seja realmente utilizável e sustentável?
Uma reação em cadeia provocada pela falha de uma plataforma de dados centralizada
Em julho de 2024, a plataforma de infraestrutura de dados blockchain Goldsky, voltada para desenvolvedores Web3, sofreu uma falha que durou seis horas, resultando na paralisação de numerosos projetos no ecossistema Ethereum. Isso expôs um fato inquietante: embora a blockchain em si tenha alcançado a Descentralização o máximo possível, a infraestrutura utilizada pelas aplicações construídas na cadeia frequentemente contém uma grande quantidade de serviços centralizados.
A indexação e recuperação de dados em blockchain pertencem a produtos públicos digitais "não exclusivos, não competitivos". Os utilizadores esperam taxas gratuitas ou muito baixas, mas por trás disso é necessário um investimento contínuo em hardware, armazenamento, largura de banda e mão de obra para operações. Na falta de um modelo de lucro sustentável, surge uma configuração de centralização onde o vencedor leva tudo.
Isso nos alerta que o mundo da Descentralização precisa urgentemente enriquecer a diversidade da infraestrutura Web3 através de financiamento de produtos públicos, redistribuição ou iniciativas impulsionadas pela comunidade, caso contrário, surgirão problemas de centralização. Apelamos aos desenvolvedores de DApp para construir produtos com prioridade local e também apelamos à comunidade técnica para considerar a falha dos serviços de recuperação de dados ao projetar DApps, garantindo que os usuários possam interagir com os projetos mesmo na ausência de infraestrutura de recuperação de dados.
Dois, a origem dos dados DApp
Para o utilizador comum, uma DApp é geralmente composta apenas por contratos na cadeia e uma interface de utilizador. Mas de onde vêm realmente os dados que são exibidos na interface?
A necessidade de serviços de recuperação de dados
Tomando como exemplo o protocolo de empréstimo, se quisermos exibir a situação das posições dos usuários no front-end, precisamos recuperar todas as posições atuais do sistema e, em seguida, encontrar as posições que pertencem ao usuário atual. Este processo é difícil de implementar no front-end, mesmo que, no servidor, a execução de tarefas de recuperação de dados diretamente através de nós locais muitas vezes também leve várias horas. Portanto, é necessário introduzir infraestrutura para acelerar a obtenção de dados.
A relação entre SubGraph, TheGraph e Goldsky
SubGraph é uma estrutura de desenvolvimento para ler e agregar dados na cadeia. TheGraph é uma das primeiras plataformas de recuperação de dados descentralizada, que desenvolveu a estrutura SubGraph escrita em AssemblyScript. Goldsky é também um fornecedor de serviços de SubGraph.
Comparação dos modelos de cobrança do Goldsky e do TheGraph
Goldsky adota um padrão de cobrança simples baseado no uso de recursos. TheGraph, por sua vez, possui um complexo esquema de taxas relacionado à economia do token GRT, incluindo taxas de consulta, taxas de staking, entre outras.
A experiência de uso do TheGraph não é boa
Para a maioria dos desenvolvedores, usar o TheGraph é relativamente complicado. Existe incerteza na quantidade de GRT a ser apostada e no tempo necessário para atrair operadores, e o cálculo de custos e o tratamento contábil também são complexos. Em comparação, escolher o Goldsky é mais simples e direto.
Três, soluções existentes
Além do TheGraph, existem algumas outras soluções:
ponder: um software de serviço de recuperação de dados que é simples, proporciona uma boa experiência de desenvolvimento e é fácil de implementar, permitindo que os desenvolvedores aluguem servidores para a sua própria implementação.
A filosofia de desenvolvimento local-primeiro: requer que o software possua funcionalidades de trabalho offline e de colaboração entre clientes. No cenário DApp, isso pode ser alcançado através do cache de dados essenciais e do design de funcionalidades de degradação.
Quatro, Conclusão
O incidente de falha da Goldsky expôs a alta dependência da infraestrutura centralizada no ecossistema Web3. Os desenvolvedores devem considerar o uso de estruturas de recuperação de dados auto-hospedadas, como o ponder, como uma opção de emergência, ao mesmo tempo em que adotam a filosofia de desenvolvimento local-first, construindo aplicações que ainda possam ser utilizadas sem serviços de recuperação de dados. Esperamos que mais desenvolvedores se concentrem nessa infraestrutura, tentem construir serviços de recuperação de dados descentralizados ou projetar estruturas de front-end de DApp que possam funcionar sem serviços de recuperação de dados.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
7 Curtidas
Recompensa
7
3
Repostar
Compartilhar
Comentário
0/400
AirdropHunter007
· 19h atrás
Ainda está a falar de Descentralização? Primeiro resolva este índice quebrado e depois falamos.
Ver originalResponder0
FUD_Whisperer
· 19h atrás
Morrendo de rir, realmente descentralizado.
Ver originalResponder0
MevTears
· 19h atrás
o poly é bom de usar, mas o servidor centralizado deu gg, muito embaraçoso.
Revelando o dilema da indexação de dados DApp: os riscos e soluções do mercado de previsão descentralizado
Trilogia da Tragédia dos Comuns Criptográficos: o problema do índice de dados do mercado de previsão descentralizado
Resumo
Este artigo foca na aplicação do mercado de previsão Polymarket e na sua ferramenta de indexação de dados no ecossistema Ethereum. Como representante do "mercado de previsão descentralizado", o módulo fundamental da Polymarket — a indexação de dados — realmente conseguiu alcançar a descentralização? Por que infraestruturas públicas como a The Graph não conseguiram desempenhar o papel esperado? Que forma deve ter um bem público de indexação de dados que seja realmente utilizável e sustentável?
Uma reação em cadeia provocada pela falha de uma plataforma de dados centralizada
Em julho de 2024, a plataforma de infraestrutura de dados blockchain Goldsky, voltada para desenvolvedores Web3, sofreu uma falha que durou seis horas, resultando na paralisação de numerosos projetos no ecossistema Ethereum. Isso expôs um fato inquietante: embora a blockchain em si tenha alcançado a Descentralização o máximo possível, a infraestrutura utilizada pelas aplicações construídas na cadeia frequentemente contém uma grande quantidade de serviços centralizados.
A indexação e recuperação de dados em blockchain pertencem a produtos públicos digitais "não exclusivos, não competitivos". Os utilizadores esperam taxas gratuitas ou muito baixas, mas por trás disso é necessário um investimento contínuo em hardware, armazenamento, largura de banda e mão de obra para operações. Na falta de um modelo de lucro sustentável, surge uma configuração de centralização onde o vencedor leva tudo.
Isso nos alerta que o mundo da Descentralização precisa urgentemente enriquecer a diversidade da infraestrutura Web3 através de financiamento de produtos públicos, redistribuição ou iniciativas impulsionadas pela comunidade, caso contrário, surgirão problemas de centralização. Apelamos aos desenvolvedores de DApp para construir produtos com prioridade local e também apelamos à comunidade técnica para considerar a falha dos serviços de recuperação de dados ao projetar DApps, garantindo que os usuários possam interagir com os projetos mesmo na ausência de infraestrutura de recuperação de dados.
Dois, a origem dos dados DApp
Para o utilizador comum, uma DApp é geralmente composta apenas por contratos na cadeia e uma interface de utilizador. Mas de onde vêm realmente os dados que são exibidos na interface?
A necessidade de serviços de recuperação de dados
Tomando como exemplo o protocolo de empréstimo, se quisermos exibir a situação das posições dos usuários no front-end, precisamos recuperar todas as posições atuais do sistema e, em seguida, encontrar as posições que pertencem ao usuário atual. Este processo é difícil de implementar no front-end, mesmo que, no servidor, a execução de tarefas de recuperação de dados diretamente através de nós locais muitas vezes também leve várias horas. Portanto, é necessário introduzir infraestrutura para acelerar a obtenção de dados.
A relação entre SubGraph, TheGraph e Goldsky
SubGraph é uma estrutura de desenvolvimento para ler e agregar dados na cadeia. TheGraph é uma das primeiras plataformas de recuperação de dados descentralizada, que desenvolveu a estrutura SubGraph escrita em AssemblyScript. Goldsky é também um fornecedor de serviços de SubGraph.
Comparação dos modelos de cobrança do Goldsky e do TheGraph
Goldsky adota um padrão de cobrança simples baseado no uso de recursos. TheGraph, por sua vez, possui um complexo esquema de taxas relacionado à economia do token GRT, incluindo taxas de consulta, taxas de staking, entre outras.
A experiência de uso do TheGraph não é boa
Para a maioria dos desenvolvedores, usar o TheGraph é relativamente complicado. Existe incerteza na quantidade de GRT a ser apostada e no tempo necessário para atrair operadores, e o cálculo de custos e o tratamento contábil também são complexos. Em comparação, escolher o Goldsky é mais simples e direto.
Três, soluções existentes
Além do TheGraph, existem algumas outras soluções:
ponder: um software de serviço de recuperação de dados que é simples, proporciona uma boa experiência de desenvolvimento e é fácil de implementar, permitindo que os desenvolvedores aluguem servidores para a sua própria implementação.
A filosofia de desenvolvimento local-primeiro: requer que o software possua funcionalidades de trabalho offline e de colaboração entre clientes. No cenário DApp, isso pode ser alcançado através do cache de dados essenciais e do design de funcionalidades de degradação.
Quatro, Conclusão
O incidente de falha da Goldsky expôs a alta dependência da infraestrutura centralizada no ecossistema Web3. Os desenvolvedores devem considerar o uso de estruturas de recuperação de dados auto-hospedadas, como o ponder, como uma opção de emergência, ao mesmo tempo em que adotam a filosofia de desenvolvimento local-first, construindo aplicações que ainda possam ser utilizadas sem serviços de recuperação de dados. Esperamos que mais desenvolvedores se concentrem nessa infraestrutura, tentem construir serviços de recuperação de dados descentralizados ou projetar estruturas de front-end de DApp que possam funcionar sem serviços de recuperação de dados.