Solana precisa de L2s e Appchains?

Há um mês, Vibhu, o fundador do DRiP, o principal aplicativo de consumo em Solana distribui NFTs gratuitos de grandes artistas, provocou um debate muito necessário com sua declaração:

Solana vai ter e precisa ter L2s e/ou rollups

Sua frustração surgiu porque o DRiP tem vazado valor significativo (~$20K/semana) para a camada base, graças ao aumento dos preços SOL e congestionamento da rede. O aumento da atividade na Solana leva a:

• Prós – Maior liquidez, capital e volumes de transações (devido à composabilidade)- Contras – Custos de infraestrutura elevados, má experiência do usuário e congestionamento No entanto, o DRiP, que usa principalmente Solana apenas como infra para distribuir milhões de NFTs semanalmente de artistas para milhares de carteiras, não se beneficia de alta composabilidade. O crescimento do TVL e do afluxo de capital da Solana tem pouco impacto na DRiP, que sofre principalmente com inconvenientes, como os elevados custos de infraestrutura.

Vibhu ressalta: "A composabilidade tem retornos cada vez menores". Ele também observa que Solana desenvolvedores de aplicativos estão discutindo em particular seu desejo de rollups por causa de:

• Maior taxa de transferência de transações, menos competição de espaço de bloco e taxas reduzidas.- Maior controlo sobre o valor económico que os seus negócios geram. Post Link Nos últimos meses, Solana passou por vários incidentes de congestionamento, desde lançamentos aéreos como JUP até mineração ORE e pico de negociação de memecoin. Embora se possa argumentar que o Firedancer pode resolver todas essas questões, sejamos realistas: a linha do tempo permanece incerta e não pode escalar além de 10x por enquanto. Apesar disso, é verdade que, entre todas as grandes cadeias que foram testadas em batalha, Solana permanece como o último monólito verdadeiro restante.

Deve Solana permanecer um monólito ou tornar-se modular? Será que Solana também evoluirá como Ethereum com soluções fragmentadas de L2 e L3, entre outras? Qual é o cenário atual de appchains e rollups em Solana?

Para abordar essas questões e resumir todo o debate, este ensaio irá explorar todas as possibilidades, discutir vários projetos e avaliar seus prós e contras.

Este artigo não se aprofundará em aspetos técnicos, mas adotará uma perspetiva mais prática e orientada para o mercado ao discutir várias abordagens de escala para fornecer uma visão geral.

Todos os insights, sem fluff – além de muito alfa.

Em poucas palavras, discutiremos:

• Solana e o Congestionamento- Tornando Solana Modular- Solana Appchains - com exemplos- Sollana Layer-2s e Rollups (RollApps) - com exemplos- Infra Powering Rollups e Appchains

Solana and the Congestion:Vamos começar abordando o elefante na sala: a rede de Solana tem sido altamente congestionada ultimamente (agora principalmente resolvida) devido a airdrops, uma quantidade substancial de atividade de negociação de memecoin, e assim por diante, principal a altos tempos de ping, uma alta porcentagem de transações falhadas e aumento de taxas de rede devido a taxas de prioridade mais altas. Apesar de tudo isso, Solana tem processado consistentemente cerca de 1-2k TPS, mais do que todas as EVM cadeias combinadas. Eu diria que é um bom problema para um blockchain ter, e também colocou a tese monolítica de Solana à prova.

A Fundação Solana recentemente publicou um blog instando os projetos a tomarem ações imediatas para melhorar o desempenho da rede, incluindo:

• Implementação de taxas prioritárias – fundamental para evitar transações atrasadas ou abandonadas.- Otimizando o uso da Unidade de Computação do Programa () – usando apenas o necessário.- Implementação de Qualidade de Serviço (QoS) ponderada por stake – permitindo que os aplicativos priorizem o processamento de transações de seus usuários. No entanto, todas essas medidas apenas melhoram um pouco a conclusão da transação e não garantem uma UX de transação suave. Uma correção imediata para esse problema é o tão esperado novo Transaction Scheduler, programado para lançamento na versão 1.18 previsto para o final de abril. Ele será introduzido junto com o agendador atual, mas não será ativado por padrão, permitindo que validadores monitore o desempenho do novo agendador e reverta facilmente para o antigo se surgirem problemas. Este novo agendador visa preencher blocos de forma mais eficiente e económica, melhorando as ineficiências do antigo agendador. Leia este artigo para saber mais detalhadamente sobre o @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">new Scheduler.

Anza (uma entidade spinoff da Solana Labs) tem sido continuly tentando resolver o congestionamento da rede que foi identificado como problemas relacionados à implementação do QUIC e ao comportamento do cliente validador Agave (Solana Labs), quando solicitado a processar um grande número de solicitações.

Post Link Embora os proponentes da modularidade tenham defendido fortemente um "roteiro modular" para Solana, a Solana Labs/Anza (a mantenedora central do Solana protocolo) continua focada em otimizar a taxa de transferência e a latência da camada base. Algumas melhorias potenciais incluem:

Reformular os mercados de taxas e aumentar as taxas de base (atualmente fixadas em 5 000 Lamports ou 0,000005 SOL).

Implementar uma taxa exponencial de bloqueio de escrita para contas, ou seja, aumentar gradualmente as taxas ao longo do tempo para desencorajar o spam.

Otimização dos pedidos de orçamento da UC através de um sistema de penalizações.

Melhorar a arquitetura geral da rede.

Mesmo com essas melhorias no dimensionamento vertical (cadeia única), não podemos descartar a possibilidade de Solana adotando o escalonamento horizontal (rollups). A realidade é que Solana pode se tornar um híbrido de ambos – poderia servir como uma excelente camada de base para rollups, ostentando tempos de bloqueio de latência super baixos (~400 ms) que beneficiariam significativamente rollups, como permitir a confirmação suave super-rápida de sequenciadores. A melhor parte é que Solana historicamente tem sido rápido em implementar mudanças, potencialmente tornando-se uma camada mais eficiente para rollups do que Ethereum.

Atualização: o Anza agora push alguns patches ajudam a aliviar alguns dos congestionamento da rede em andamento e serão seguidos por mais melhorias na v1.18.

Making Solana Modular:Os esforços para tornar Solana modular já foram iniciados. Como Anza DevRel's post indica, o validador de Solana e o SVM (ambiente de execução que processa transações e contratos inteligentes/programas) são fortemente acoplados e mantidos pela Anza (uma entidade spin-off da Solana Labs). No entanto, o cliente validador e o tempo de execução do SVM serão separados nos próximos meses. Essa separação facilitará a criação do SVM e a criação fácil de "Solana appchains".

Por rollups, o benefício pode vir da otimização da camada de disponibilidade de dados (DA)/blob do Solana, embora isso possa acontecer em um estágio posterior.

Fonte: Anza DevRel Joe C (engenheiro da Anza) também revelou os planos para tornar o SVM modular, onde o pipeline de processamento de transações será retirado do validador e colocado no SVM. Isso permitirá que os desenvolvedores executem a implementação do SVM e operem independentemente de qualquer validador.

O SVM isolado será uma montagem de módulos totalmente independentes. Qualquer implementação SVM poderia conduzir esses módulos através de interfaces bem definidas, reduzindo ainda mais as barreiras para projetos compatíveis com SVM, diminuindo significativamente a sobrecarga necessária para arquitetar soluções personalizadas. As equipas podem implementar apenas os módulos em que estão interessadas, enquanto utilizam implementações estabelecidas para os restantes, como as do Agave ou Firedancer.

Em curto, Solana seria mais plug-and-play, tornando Solana appchains e rollups muito mais fáceis.

Em linhas gerais, há duas direções, onde isso pode ir: Layer-2s/Rollups e Appchains. Analisaremos ambos – um a um.

Solana Appchains:Também conhecidos como forks SVM, estes são essencialmente forks da cadeia de Solana dedicados a aplicações específicas. Pyth foi o primeiro Solana appchain, mas o conceito realmente ganhou atenção quando Rune, o fundador de um dos maiores protocolos de DeFi, Criador, causou bastante agitação com sua proposta de desenvolver um Criador appchain (para governança) baseado na base de código Solana (SVM). Ele escolheu a SVM devido à sua forte comunidade de desenvolvedores e superioridade técnica sobre outras VMs, com o objetivo de forquilha a cadeia de maior desempenho para melhor atender às necessidades dos consumidores. Embora nada tenha sido implementado ainda, esta medida desencadeou um debate muito necessário sobre Solana appchains.

Em termos gerais, pode ser de dois tipos:

• Sem permissão – Qualquer pessoa pode aderir à rede, semelhante à rede principal Solana atual.- Permissioned – Empacotado como 'Solana Permissioned Environments (SPEs)' pela Solana Foundation para instituições, ele permite que as entidades criem e mantenham sua própria instância de cadeia, alimentada pelo SVM.

Pyth – The OG Solana Appchain: Ao mesmo tempo, o Pyth representava 10-20% de todas as transações na rede principal Solana. No entanto, não exigia nenhuma capacidade de composição, então eles simplesmente bifurcaram a base de código Solana. Isso permitiu que eles aproveitassem o tempo de bloco rápido de 400 ms da Solana para atualizações de preços de alta frequência. A Pythnet foi a primeira rede a adotar SVM para sua appchain. O Pythnet appchain é uma forquilha de Prova de Autoridade da mainnet da Solana, servindo como uma camada de base computacional para processar e agregar dados fornecidos pela rede de editores de dados da Pyth.

Por que Pyth se mudou? -Não exigia alta capacidade de composição (particularmente para aplicativos não Solana) e, portanto, estava livre de congestionamento da rede principal.

• Precisava de um ambiente com permissão para publicar dados. - Redução de custos de infra através da internalização das taxas, que anteriormente eram vazadas para a camada base (Solana). Cube Exchange é outro exemplo, um CEX híbrido implantado como uma cadeia de aplicativos SVM soberana (com um livro e liquidação completamente fora da cadeia ordem em sua cadeia de aplicativos SVM)

Alguns exemplos de Solana Appchains podem ser:

• Perp DEXs: Como Hyperliquid, as DEXs Perp podem operar como redes L1 separadas. Além disso, para casos de uso de negociação, o número de transações por bloco pode ser personalizado, ou a lógica condicional pode ser implementada, como integrar a execução de um ordem stop-loss diretamente no L1, garantindo que ele seja aplicado como uma transição de estado, ou introduzir lógica atômica específica para o aplicativo.- AI e DePIN: Estes podem apresentar uma lista controlada de prestadores de serviços como o Pyth. Por exemplo, Akash opera como um mercado de computação através de uma cadeia de aplicativos Cosmos.- Appchains de governança: Validado pelo interesse de MakerDAO em uma cadeia de aplicativos SVM, uma cadeia de aplicativos de governança soberana pode ser atraente. A governança em cripto ainda está evoluindo, e ter uma cadeia dedicada ao forquilha pode ser um mecanismo de coordenação útil.- Future Enterprise appchains: As aplicações potenciais incluem fundos (como BlackRock) ou sistemas de pagamento (como Visa ou CBDCs).- Gaming Appchains: Um projeto de jogos de cassino na Solana está considerando seu appchain.- Forks modificados de Solana: Semelhante a como Monad ou Sei oferecem EVMs otimizados (paralelizados), alguém poderia construir uma versão mais otimizada do Solana. Esta tendência pode tornar-se mais prevalente nos próximos anos, especialmente à medida que a rede principal Solana começa a explorar novas arquiteturas de design.

Visioning the Solana Appchain Stack:Embora o estabelecimento de uma cadeia de aplicativos possa ser relativamente simples, garantir a conectividade entre todas as cadeias de aplicativos é crucial para a interoperabilidade. Inspirando-se em Avalanche Subnets (conectadas pelo nativo Avalanche Warp Messaging) e Cosmos appchains (conectadas pelo IBC), Solana também poderia criar uma estrutura de mensagens nativa para conectar essas appchains.

Post Link Pode-se também criar um middleware semelhante ao Cosmos-SDK, oferecendo uma solução turnkey para criar appchains com suporte integradas para oráculos (como Pyth ou Switchboard), RPCs (como Helius) e conectividade de mensagens (como Wormhole), entre outros.

Polygon AggLayer também seria uma abordagem interessante, onde os devs podem conectar qualquer cadeia L1 ou L2 ao AggLayer, que agrega provas ZK de todas as cadeias conectadas.

Um Appchain Net é positivo para o ecossistema Solana?Embora os appchains não acumulem valor diretamente para SOL, como eles não pagariam taxas em SOL ou usariam SOL como o token gás — a menos que o SOL reapostado seja usado para segurança econômica — eles beneficiam muito o ecossistema SVM. Assim como existem "efeitos de rede EVM", mais forks SVM e appchains fortalecerão os efeitos de rede SVM. Aplica-se a mesma lógica que torna o Eclipse (SVM L2 on Ethereum) em alta para SVM, mesmo sendo um concorrente direto do Solana mainnet.

Solana Layer-2s:Solana Layer-2s, ou rollups, são cadeias logicamente separadas que lançam dados na camada de Disponibilidade de Dados (DA) da cadeia de hosts e reutilizam o mecanismo de consenso da cadeia de hosts. Eles também podem usar outras camadas de DA, como Celestia, no entanto, não permanece um verdadeiro rollup. "RollApp" é um termo geralmente usado para Rollups específicos de aplicativos (que a maioria dos aplicativos Solana estão explorando).

O Solana Rollups seria o mesmo que Ethereum? Aparentemente não. Por Solana, os Rollups seriam principalmente abstraídos para o usuário final. Na frente ideológica, Ethereum rollups eram de cima para baixo, onde a Fundação Ethereum e os líderes decidiram que a melhor maneira de escalar era através rollups, e começaram a apoiar vários L2s após o fiasco dos CryptoKitties. Considerando que, por Solana, a demanda é de baixo para cima, ou seja, vem de desenvolvedores de aplicativos com adoção significativa por parte dos consumidores. Como resultado, a maioria das jogadas de roll-up atuais são peças de marketing e são mais orientadas pela narrativa do que pela demanda do consumidor. Esta é uma diferença significativa e pode levar a um futuro diferente para rollups do que vimos em Ethereum. São Compressão = Rollups?

L2s escala blockchains de camada base (L1s) executando transações no L2, agrupando os dados de transação e compactando-os. Os dados compactados são então enviados para o L1 e usados no prova de fraude (rollup otimista) ou prova de validade (zk rollup). Este processo de prova é designado por «liquidação». Da mesma forma, a compactação descarrega as transações da rede principal, reduzindo a contenção de estado na camada base. Notavelmente, o Grass L2 aproveitará a State Compression para seu rollup.

Rollups Landscape on Solana:Dois 'um pouco rollapps' estão ativos atualmente:

1. GetCode: Um aplicativo de pagamentos com um SDK de micropagamentos permite que qualquer pessoa pague e aceite pagamentos instantaneamente e também usa um pseudo-rollup para seu aplicativo. Ele cria intenções para todas as transações e emprega um sequenciador tipo rollup, que se instala em Solana após intervalos N.

Usar uma estrutura semelhante a um rollup permite:

• Flexibilidade: As intenções podem representar várias atividades futuras, não apenas operações de pagamento. Além disso, a Solana como cadeia também pode ser substituída, se necessário.- Instantâneo e Privado: Dada a finalidade suave do sequenciador, os pagamentos são instantâneos mesmo durante Solana congestionamento. Embora as transações sejam visíveis na cadeia, o valor exato e a intenção permanecem ocultos, garantindo a privacidade do usuário.

2. Ephermal Rollups por MagicBlocksMagicBlocks, um infra de jogos web3 desenvolveu Ephermal (ou temporário) rollups, particularmente para jogos. Ele usa a estrutura conta do SVM e o estado do jogo é dividido em clusters. Ele transfere temporariamente o estado para uma camada auxiliar ou o "rollup efêmero", uma camada dedicada configurável. O rollup efêmero opera como um tempo de execução ou rollup SVM especializado para facilitar o processamento de transações em uma taxa de transferência elevada.

O uso de uma estrutura semelhante a um rollup permite:

• Personalização do tempo de execução especializado para incluir recursos como transações sem gás, tempos de bloqueio mais rápidos e a incorporação de um mecanismo de ticking (por exemplo, um sistema integrado de agendamento de transações como [Grass](https://github.com/clockwork-xyz/clockwork>clockwork, operado sem taxas).- Os desenvolvedores devem implantar programas na camada base (por exemplo, Solana) em vez de em uma cadeia ou rollup separado. Os REs não fragmentam o ecossistema existente e permitem a aceleração de operações direcionadas sem criar um ambiente isolado. Isso significa que toda a infraestrutura de Solana existente pode ser utilizada. Essa abordagem facilita um sistema altamente escalável capaz de lançar rollups sob demanda e dimensionar automaticamente horizontalmente para acomodar usuários que realizam milhões de transações, sem as compensações típicas dos L2s tradicionais. Embora o MagicBlock esteja especificamente focado em jogos, esta abordagem pode ser aplicada a outras aplicações, como pagamentos.

Próximos pacotes cumulativos de Solana:

O Grass requer 1 milhão de solicitações web por segundo, o que é inviável na rede principal Solana. Portanto, eles planejam fazer provas ZK dos dados de origem para todos os conjuntos de dados e agrupá-los para liquidação em Solana L1. Eles estão considerando usar a compactação de estado de outro cluster e estabelecer raízes na mainnet-beta.

Este desenvolvimento posicionará o Grass como uma camada base para uma ampla gama de aplicações que só são possíveis no topo do Grass (note que as plataformas e a infraestrutura geralmente comandam avaliações muito mais altas e o Grass está lançando o token em breve :P).

• Zeta: Um dos DEX de perp mais antigos da Solana que tinha um livro de perp ordem completamente na cadeia também está planejando mover seu correspondência fora da cadeia através do rollup de Solana. As DEXs Perp têm um PMF imediato para rollups, pois melhoram significativamente a UX. Basta perguntar a alguém que negociou em Hyperliquid ou Aevo versus Solana perp DEXs, onde você tem que assinar cada transação, uma carteira aparece, e você tem que esperar ~ 10-20 segundos. Além disso, os perps não exigem execução sincronizada e oferecem alta capacidade de composição com o resto de DeFi, particularmente no aspeto de correspondência comercial.

Curiosamente, Armani (Cofundador da Backpack) também tuitou que agora estão cuidando de L2. A Sonic também está construindo uma cadeia SVM modular (Hypergrid) que permitirá que os jogos implantem suas próprias cadeias no Solana. Há também Ethereum rollups baseados em SVM como Eclipse e NitroVM que usam SVM como mecanismo de execução. Neon funciona como um L2 compatível com EVM em Solana. Além disso, existem projetos na fase de ideia, como Molecule (an SVM Bitcoin Camada 2). Sovereign SDK é outra estrutura semelhante à node.js, mas para construir rollups. Os usuários trazem seu código Rust, e nós o transformamos em um rollup Optimistic ou ZK que pode ser implantado em qualquer blockchain. O código Rust pode ser a lógica específica do seu aplicativo ou qualquer VM.

Algumas teses sobre Rollups:

• Rollups = Estar SOL-alinhado: O termo 'ETH-alinhado', ou uma palavra melhor para 'ETH Bag Biases', tornou-se um meme popular. Por que você acha que a Camada 2 e o Restaking/EigenLayer se tornaram a narrativa mais quente? É porque eles aumentam a "Moneyness of ETH", com ETH sendo usado como o ativo principal em todos os lugares. O mesmo princípio se aplica a Solana. A comunidade Solana irá reunir-se em torno de qualquer solução que aumente as suas participações SOL – é simples assim. À medida que o ecossistema Solana se expande, o outrora esquecido "Moneyness of SOL" ganhará importância. Lembre-se, a maioria dos Rollups são de qualquer maneira "Marketing Play" e dão melhor acúmulo de valor de token, pois os mercados ainda valorizam Infra mais do que Aplicativos.

• Os rollups parecerão uma extensão do Solana: Além dos benefícios de segurança (ou seja, herdar a segurança da camada base), o acesso fácil a usuários e ativos Solana será uma vantagem significativa. Como Jon Charbonneau observa, Ethereum Rollups como Base, Optimism e Arbitrum parecem mais extensões de Ethereum. Os usuários mantêm as mesmas carteiras e endereços, o token gás nativo é uma única versão canônica do ETH, ETH domina DeFi com todos os pares de negociação, aplicativos sociais precificam NFTs em ETH e pagam criadores em ETH (por exemplo, friend.tech), e os depósitos no L2 são instantâneos, etc. Da mesma forma, isso acontecerá com Solana. Aprendendo com Ethereum, a maioria dos Solana Rollapps não fará com que os usuários sintam que estão usando uma cadeia separada (por exemplo, Getcode).

• Solana verá mais "RollApps" do que "Rollups" Solana não tem um problema de escalonamento como Ethereum onde a rede principal é simplesmente inutilizável devido a altas taxas de gás, é altamente otimizado. No entanto, alguns aplicativos que precisam de espaço de bloco dedicado criarão seus rollups. Embora os Rollups de uso geral em Solana não façam sentido para mim, economicamente fazem sentido para os projetos. Por exemplo, os usuários Base geraram US$ 2 milhões em receita para a Coinbase em apenas um dia! Os incentivos para os construtores estão fortemente inclinados para L2. No entanto, como observado, cada rollup de EVM parece ser um roll-up de baunilha, e muitos, como Linea, Scroll ou zkSync, tornaram-se cadeias fantasmas com apenas agricultores realizando algumas transações para airdrops simbólicos. Além disso, sinto que L2s de uso geral em Solana podem levar aos mesmos problemas de Ethereum antigos, ou seja, rollups centralizado, congestionamento e fragmentação de liquidez.

Por que alguns aplicativos querem migrar para Rollapps/appchain? Inicialmente, todos os aplicativos começarão no Solana Rede principal, já que hospedar mais aplicativos em infraestrutura compartilhada reduz significativamente a complexidade do desenvolvedor e do usuário. No entanto, à medida que essas aplicações crescem, podem procurar:

• Captura de valor: é mais desafiador internalizar o valor em uma camada de Solana compartilhada não projetada com apenas um aplicativo em mente. MEV captura pode ser outra opção lucrativa para DEXs.- Personalização Blockspace dedicadaem casos de uso como:

• Privacidade: Por exemplo, Getcode usa um sequenciador para facilitar pagamentos privados para seus usuários.- Experimentações de mercado de taxas- Mempools criptografados para minimizar MEV- livros de ordem personalizados

• No entanto, nem todos os aplicativos vão querer iniciar seu próprio Rollup, especialmente aqueles que não atingiram uma certa velocidade de escape (por exemplo, TVL suficiente, usuários volume). Lançar sua própria cadeia hoje envolve compensações dolorosas e desnecessárias (complexidade, custo, pior UX, liquidez fragmentada, etc.), que a maioria dos aplicativos, particularmente aqueles em estágio inicial, não pode justificar pelos benefícios incrementais. Solana continua sendo o coração e a alma do desenvolvimento SVM, e muitos novos aplicativos provavelmente serão implantados como resultado. Para Construtores de Aplicações: Solana Rede principal ou Appchain ou Rollup Completamente depende. Se não houver uma forte necessidade de compatibilidade com todos os outros aplicativos, tomar alguns componentes diferentes fora da cadeia (appchain ou rollup) faz todo o sentido. Um usuário não precisa saber que está usando um pacote cumulativo ou appchain. Grass, Zeta e Getcode abstraem qualquer infra do tipo rollup que estejam usando para seus usuários. Para casos de uso com permissão e personalização, a extensão Token também atende à maioria das necessidades, como lógica de KYC/transferência, mantendo a capacidade de composição. Então, o DRiP será um L2/appchain? Atualmente, o DRiP usa Solana para:

• Carteiras de criação de usuário (pode ser em L2 / appchain)
• Distribuição de NFTs compactados (pode ser em L2/appchain)
• Negociação de NFTs compactados (pode ser em L2 / appchain, mas os fundos precisam ser ponteados)

• Podemos ver claramente que não há uma forte necessidade de estar em Solana Camada 1, além da tecnologia que os L2s/appchains também podem fornecer. Como o alvo principal do DRiP sempre foram os usuários da web2, ele pode muito bem integrá-los diretamente à sua cadeia, o que lhe dá um controle muito maior no longo prazo pois não estará vazando todo o valor para a cadeia base (Solana). Além disso, o DRiP atingiu a velocidade de escape (maior aplicativo de consumo do Solana) para agora passar para sua própria cadeia. Uma estrutura pseudo-rollup como Getcode faz todo o sentido para DRiP.

Infrastructure Powering Rollups and Appchains:Se a tese rollapp/appchain se expandir, os provedores de infraestrutura existentes se beneficiarão muito à medida que explorarem novos mercados:

• Os provedores existentes de Rollup as a Service (RaaS), como Caldera, podem facilmente entrar no mercado de SVM à medida que a demanda surge. SVM Ethereum rollups como Eclipse e NitroVM também estão atentos a esta oportunidade. Além disso, a Sovereign Labs oferece um adaptador Solana Sovereign SDK que permite rollups em Solana (ainda não pronto para produção). A Helius é outra empresa adequada para construir infraestrutura para Solana L2s, como Mert sugeriu várias vezes.- Sequenciadores compartilhados como Protocolo de Roma e a necessidade de clientes leves como Tinydancer. Os sequenciadores compartilhados podem ser interessantes para rollups, pois permitem atividades como arbitragem atômica, MEV e pontes contínuas, diminuindo a fragmentação da liquidez.- Carteiras como Phantom, Backpack, e Solflare. Multi-sig e infraestrutura de carteira de contrato inteligente como Squads. Os squads sempre foram posicionados como "a camada definitiva de infraestrutura de carteira de contrato inteligente para Solana e SVM".SOL Restaking: A tese modular também promove a retomada, pois esses rollups/appchains podem exigir SOL segurança compartilhada e se tornar mais alinhados com Solana. Isto conduz a:
• Jogadores em estágio inicial como Cambrian, Picaso, and Solayer- Jito via Stakenet e LSTs como Sanctum- Validators — aumento da receita

Pensamentos de encerramento: Solana pode lidar com a demanda do mundo inteiro?Definitivamente não. Vamos ser realistas: mesmo considerando a Lei de Moore (que o desempenho do hardware continuará a melhorar e Solana é otimizado para tais avanços de hardware), é impraticável. Acredito que todas as transações menos críticas (como DRiP enviando NFTs) acabarão se movendo para suas próprias cadeias, enquanto as transações mais valiosas permanecerão na cadeia principal, onde a verdadeira compatibilidade é essencial (por exemplo, Ponto DEXs).

E não, isso não significa que Solana tenha perdido na batalha do monólito e da composabilidade, ele vai gerenciar casos que dependem de composabilidade e baixa latência melhor do que outras cadeias. E não, Sui / Aptos / Sei / Monad, etc etc não são melhores ainda, como não sabemos e eles ainda estão a ser testados para a alta atividade real do usuário.

Ao contrário Ethereum, a Solana Rede principal não pretende ser a "cadeia B2B", foi e sempre será a cadeia de consumo. Construir sistemas distribuídos em escala é incrivelmente desafiador, e Solana tem o melhor potencial para se tornar o livro-razão compartilhado global para as transações mais valiosas.

Solana precisa de almas gêmeas: Appchains e rollups poderiam ser sua combinação perfeita?

Sinta-se livre para entrar em contato comigo em Yash Agarwal (@yashhsm no Twitter) para quaisquer sugestões ou se você tiver alguma opinião. Se você achar isso um pouco perspicaz, por favor, compartilhe-o - justifica minhas semanas de esforço e recebe mais olhares :)

Um agradecimento especial a Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), e Akshay (Superteam), que analisou e forneceu informações em diferentes fases do draft.

Declaração de exoneração de responsabilidade:

• Este artigo foi reproduzido a partir de [The Superteam Blog]. Todos os direitos autorais pertencem ao autor original [YASH AGARWA]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso imediatamente.- Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.- As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.