Yakovenko, da Solana, coloca cinco grandes aplicativos à frente de validadores e desenvolvedores

SOL
ETH
Ethereum FoundationSolanaAaveDeFi
há 2 horasFonte: crypto.news
Yakovenko, da Solana, coloca cinco grandes aplicativos à frente de validadores e desenvolvedores

O cofundador da Solana, Anatoly Yakovenko, nomeou cinco grandes aplicações como prioridades maiores para a otimização da rede do que validadores, desenvolvedores, formadores de mercado ou engenheiros principais, argumentando que produtos que detêm ativos substanciais e lidam com volume de negociação de varejo merecem a maior atenção.

Resumo

  • Cinco aplicativos lideraram a lista de Yakovenko dos grupos para os quais a Solana deveria otimizar sua rede.
  • Ele creditou à Ethereum Foundation o atendimento da necessidade da Aave por acesso confiável a transações.
  • Sua publicação respondeu a críticas sobre a experiência pessoal dos designers do Ethereum no uso da rede.
  • Os comentários não continham nenhuma atualização específica, alocação de financiamento ou mudança nas regras de participação dos validadores.

Anatoly Yakovenko fez os comentários em uma publicação no X em 23 de outubro, nomeando Phantom, Pump.fun, Fomo, Jupiter e Kamino ao responder a críticas sobre como os designers do protocolo Ethereum usam sua própria rede.

Os maiores aplicativos da Solana lideram a lista de prioridades de Yakovenko

Yakovenko identificou ativos sob gestão e atividade de varejo como as duas medidas por trás de sua preferência. Sua publicação não forneceu números para nenhuma das medidas nem classificou os cinco produtos nomeados entre si.

“Produtos com uma tonelada de AUM e uma tonelada de volume de varejo são os dois grupos mais importantes para os quais otimizar”, escreveu ele.

O cofundador então colocou as cinco aplicações à frente de validadores, desenvolvedores, formadores de mercado e engenheiros principais. Sua redação abordou quais necessidades deveriam orientar a otimização, sem especificar uma proposta técnica ou um cronograma para implementá-la.

Phantom, Pump.fun, Fomo, Jupiter e Kamino foram exemplos em seu argumento. A publicação não anunciou um acordo com essas equipes, não lhes deu autoridade de governança nem identificou uma configuração de rede que mudaria em nome delas.

Em uma resposta visível abaixo da publicação, ele descreveu o usuário prioritário em termos mais gerais.

“O usuário mais importante é o encanador, encanador institucional ou de varejo.”

Críticas ao Ethereum provocam elogios às necessidades de confiabilidade da Aave

A discussão começou com o argumento de outro usuário de que muitas pessoas que projetam o protocolo Ethereum não o utilizam elas mesmas. O autor argumentou que os designers deveriam depender de seu próprio produto e enfrentar perdas quando ele falha.

Citando essa crítica, Yakovenko fez um elogio qualificado à Ethereum Foundation. Ele disse que ela fez um trabalho decente ao otimizar para a Aave porque a incapacidade de incluir transações durante uma interrupção ou congestionamento quebraria a plataforma de empréstimos.

Taxas de aplicação figuraram em um debate anterior sobre a Robinhood

Yakovenko argumentou anteriormente que uma empresa poderia construir na Solana, subsidiar custos de transação e cobrar clientes por meio de sua própria interface. Como o crypto.news relatou anteriormente em 6 de setembro, sua posição gerou uma resposta do cofundador da Offchain Labs, Steven Goldfeder, sobre a decisão da Robinhood de usar a tecnologia Arbitrum.

Goldfeder defendeu a capacidade da Robinhood de reter receita da chain, dizendo que ela poderia manter cerca de 90% sob o Arbitrum Expansion Program. Ele contrastou esse arranjo com uma aplicação pagando para usar a Solana.

O arranjo relatado envia 10% da receita líquida do protocolo para o ecossistema Arbitrum, divididos entre uma alocação de 8% para sua DAO e 2% para sua Developer Guild. A porcentagem diz respeito à receita líquida após as despesas relevantes de rede, incluindo os custos de publicação de dados no Ethereum.

A exchange Robinhood dizia respeito à infraestrutura e ao modelo de receita de uma corretora dos EUA. A publicação de Yakovenko em 23 de outubro não anunciou nenhuma mudança no acesso de produtos para clientes dos EUA.

Preparativos do Alpenglow definem funções separadas para equipes de aplicativos e validadores

A cobertura anterior da atualização do Solana documentou requisitos diferentes para desenvolvedores de aplicativos e para os operadores que fornecem sua infraestrutura. Em 26 de setembro, o Alpenglow chegou à devnet, após sua transição para a testnet, dando às equipes de aplicativos acesso ao novo comportamento de consenso antes de uma transferência para a mainnet.

A orientação da Fundação, descrita naquela cobertura, afirmava que aplicativos que apenas enviam transações e leem saldos não precisariam de migração. Serviços que processam blocos ou rastreiam a atividade dos validadores enfrentaram mudanças na forma como leem os dados da rede.

Um relato de 14 de agosto sobre a meta de finalidade do Alpenglow documentou um objetivo de aproximadamente 150 milissegundos, em comparação com cerca de 12,8 segundos sob o TowerBFT. A cobertura distinguiu a finalidade de consenso de uma indicação inicial de que uma transação foi registrada.

Reportagens subsequentes sobre as mudanças nas taxas dos validadores descreveram o plano da Fundação de substituir as taxas individuais de votação onchain por uma taxa fixa de admissão de 0,8 SOL por época, queimada integralmente. Os operadores devem financiar essa taxa acima do mínimo isento de aluguel da conta de voto.

A mesma orientação determina o pagamento com uma época de antecedência. Um validador que não conseguir pagar perde a permissão de votar ou produzir blocos na época seguinte.

A documentação do operador descrita na cobertura de outubro qualifica a meta de finalidade para nós fora do conjunto de validadores admitidos. Esses nós normalmente ficam sabendo do resultado por meio de certificados incluídos em um bloco posterior, o que pode adicionar um intervalo de bloco produzido, com esperas mais longas se blocos forem pulados ou atrasados.

Para o estágio de testes anterior, a cobertura de setembro distinguiu as duas redes públicas. A devnet permite que as equipes de aplicativos verifiquem softwares usando tokens sem valor real, enquanto a testnet permite que validadores e operadores de infraestrutura submetam o software de rede a condições mais exigentes. A Anza anunciou publicamente a transição bem-sucedida para a devnet em 25 de setembro, um dia após a testnet concluir sua mudança.