A maioria das escolhas tecnológicas na infraestrutura blockchain é, na sua essência, o resultado de compromissos feitos sob pressão de curto prazo. Os indicadores de desempenho podem ser atingidos? O controlo de custos está sob controlo? A implementação no prazo é possível? Estas questões são frequentemente questionadas. Mas o que realmente é raro é alguém considerar seriamente — daqui a cinco, dez anos — que dificuldades estes dados históricos poderão enfrentar.
Quem já fez manutenção a longo prazo sabe que os dados acumulados de aplicações com vitalidade nunca são um peso morto. Esses dados fazem parte do funcionamento do sistema. Se a gestão for mal escolhida, cada iteração de funcionalidades ou expansão de desempenho posterior terá que pagar o preço das decisões anteriores.
A abordagem de design do Walrus é precisamente o oposto — não começa por "como escrever mais rapidamente", mas por "como garantir a disponibilidade a longo prazo dos dados", retrocedendo na arquitetura técnica. A diferença pode parecer sutil, mas na verdade determina o ciclo de vida de todo o sistema.
No que diz respeito à implementação, o objeto de dados recebe uma identidade estável desde o momento da sua criação. Mesmo que a lógica de negócio mude posteriormente ou que o estado na cadeia seja atualizado, a relação de referência a esse objeto permanece inalterada. Isto permite que a camada de aplicação construa a lógica de negócio em torno de uma mesma referência a longo prazo, em vez de estar sempre a correr atrás de novas versões de dados.
Qual é a vantagem mais direta desta abordagem? Uma redução drástica na complexidade do sistema. Quando as relações de referência deixam de oscilar frequentemente, componentes como gestão de índices, controlo de permissões e estratégias de cache tornam-se mais simples. Para aplicações que precisam de operar de forma estável, isto equivale a eliminar potenciais fontes de falhas em toda a categoria.
Do ponto de vista técnico, o Walrus suporta o armazenamento de objetos de dados de vários MBs, garantindo disponibilidade através de uma arquitetura redundante com múltiplos nós. Nos testes na rede de testes, o atraso de leitura mantém-se na escala de segundos, sendo totalmente capaz de suportar as necessidades de acesso de aplicações em tempo real, não se limitando a arquivar dados frios. Este nível de desempenho é crucial para a utilidade das aplicações Web3.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
8 gostos
Recompensa
8
7
Republicar
Partilhar
Comentar
0/400
tx_pending_forever
· 01-07 19:55
Falar bonito, mas quando realmente estiver ao vivo, não é que a realidade vai nos dar uma bofetada... Já ouvi muitas vezes essa história de que é para uso a longo prazo.
---
Então, o Walrus é para não termos que olhar para nossos dados daqui a dez anos e reclamar, né? Parece uma boa ideia.
---
Reconheço que manter a citação inalterada realmente economiza uma pilha de problemas, senão mudar uma lógica de negócio acaba gerando uma série de efeitos colaterais.
---
Latência de segundos? A rede de teste e a rede principal são coisas diferentes, vamos esperar até realmente estar rodando para falar.
---
Finalmente alguém pensou na questão da manutenção a longo prazo, a maioria dos projetos nem se preocupa com isso.
---
Curto prazo e longo prazo são sempre contraditórios, o prazo dado pelos VC não espera, né?
Ver originalResponder0
LiquidityLarry
· 01-07 19:54
Muito bem, só agora alguém se lembra de considerar a disponibilidade a longo prazo, as infraestruturas que foram lançadas às pressas antes já estão em dívida.
A ideia de manter a identidade dos dados inalterada é realmente genial, evita refatorações repetidas no futuro.
A abordagem do Walrus é um pouco como construir uma infraestrutura de verdade, não uma solução temporária.
A latência de segundos é suficiente para aplicações em tempo real, é muito melhor do que bancos de dados frios.
Escolher a arquitetura errada realmente tem um custo, já vi exemplos sangrentos demais.
Quando as relações de referência se estabilizam, as fontes de falha do sistema como um todo realmente diminuem bastante.
Esse método de design reverso deveria já ser padrão, não algo que diferencia na competição.
A gestão de dados decide a vida ou morte, essa frase não tem erro.
Armazenamento de vários MBs com redundância, finalmente temos uma solução confiável.
Ver originalResponder0
LuckyHashValue
· 01-07 19:47
Esta é a verdadeira aparência da infraestrutura de blockchain, não apenas acumular métricas de desempenho
Uso a longo prazo > Falar bobagens a curto prazo, a indústria precisa muito desse tipo de abordagem
A referência estável a esse detalhe de design é boa, evita correr atrás das versões de dados todos os dias
A questão é quantos projetos realmente pensarão em algo daqui a cinco anos...
Ver originalResponder0
LidoStakeAddict
· 01-07 19:43
Honestamente, a maioria dos projetos atualmente são soluções rápidas impulsionadas por prazos e pressão de financiamento, ninguém realmente se preocupa com o que acontecerá daqui a cinco anos. A abordagem do Walrus realmente inverteu a lógica, partindo do ciclo de vida dos dados para construir a arquitetura, essa é a postura certa para criar produtos de longo prazo. Ter uma identidade estável parece simples, mas quantos problemas posteriores podemos evitar com isso.
Ver originalResponder0
GateUser-ccc36bc5
· 01-07 19:41
Esta é a abordagem que sempre quis ver, o long-termismo deve ser feito assim
Ver originalResponder0
AirdropFreedom
· 01-07 19:40
Esta é a verdadeira mentalidade de infraestrutura, não uma simples acumulação de métricas de desempenho
---
Para ser honesto, a maioria dos projetos é de visão curta, enterrando problemas para as próximas gerações
---
Disponibilidade a longo prazo > Lançamento rápido, essa lógica é muito rara no web3
---
A identidade estável é incrível, economiza muita complicação com índices e controle de permissões
---
A latência de segundos realmente faz a diferença, finalmente há uma solução decente para a camada de armazenamento
---
Manter a relação de referência inalterada é uma ideia que vale a pena, muito mais elegante do que outras soluções
---
Escolher uma gestão errada realmente leva a custos infinitos, os que chegam depois sempre acabam levando a culpa
---
Ao inverter a arquitetura a partir da disponibilidade a longo prazo, essa abordagem vai contra a intuição da maioria das pessoas
---
Dados de MB com redundância, a demanda de acesso de aplicações em tempo real pode ser atendida, isso é confiável
Ver originalResponder0
CountdownToBroke
· 01-07 19:37
Essa abordagem é realmente genial, finalmente alguém pensou em tratar os dados como ativos e não como um fardo
A maioria dos projetos já deveria aprender essa ideia, em vez de ficar cavando buracos só para cumprir prazos
O design de referência estável do Walrus, na verdade, ajuda as aplicações a evitarem dívidas técnicas futuras
A leitura em segundos ainda suporta aplicações em tempo real, esses dados realmente têm vitalidade
Depois de ver tantos projetos de blockchain, é triste perceber quão poucos realmente consideram como será daqui a cinco anos
A maioria das escolhas tecnológicas na infraestrutura blockchain é, na sua essência, o resultado de compromissos feitos sob pressão de curto prazo. Os indicadores de desempenho podem ser atingidos? O controlo de custos está sob controlo? A implementação no prazo é possível? Estas questões são frequentemente questionadas. Mas o que realmente é raro é alguém considerar seriamente — daqui a cinco, dez anos — que dificuldades estes dados históricos poderão enfrentar.
Quem já fez manutenção a longo prazo sabe que os dados acumulados de aplicações com vitalidade nunca são um peso morto. Esses dados fazem parte do funcionamento do sistema. Se a gestão for mal escolhida, cada iteração de funcionalidades ou expansão de desempenho posterior terá que pagar o preço das decisões anteriores.
A abordagem de design do Walrus é precisamente o oposto — não começa por "como escrever mais rapidamente", mas por "como garantir a disponibilidade a longo prazo dos dados", retrocedendo na arquitetura técnica. A diferença pode parecer sutil, mas na verdade determina o ciclo de vida de todo o sistema.
No que diz respeito à implementação, o objeto de dados recebe uma identidade estável desde o momento da sua criação. Mesmo que a lógica de negócio mude posteriormente ou que o estado na cadeia seja atualizado, a relação de referência a esse objeto permanece inalterada. Isto permite que a camada de aplicação construa a lógica de negócio em torno de uma mesma referência a longo prazo, em vez de estar sempre a correr atrás de novas versões de dados.
Qual é a vantagem mais direta desta abordagem? Uma redução drástica na complexidade do sistema. Quando as relações de referência deixam de oscilar frequentemente, componentes como gestão de índices, controlo de permissões e estratégias de cache tornam-se mais simples. Para aplicações que precisam de operar de forma estável, isto equivale a eliminar potenciais fontes de falhas em toda a categoria.
Do ponto de vista técnico, o Walrus suporta o armazenamento de objetos de dados de vários MBs, garantindo disponibilidade através de uma arquitetura redundante com múltiplos nós. Nos testes na rede de testes, o atraso de leitura mantém-se na escala de segundos, sendo totalmente capaz de suportar as necessidades de acesso de aplicações em tempo real, não se limitando a arquivar dados frios. Este nível de desempenho é crucial para a utilidade das aplicações Web3.