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

Solana vai ter e precisa ter L2s e/ou acúmulos

Sua frustração surgiu porque o DRiP tem vazado um valor significativo (~US$ 20 mil por semana) para a camada base, graças ao aumento dos preços SOL e Congestionamento de rede. O aumento da atividade em Solana leva a:

• Prós – Maior liquidez, capital e volumes de transações (devido à capacidade de composição)
• Contras – Custos elevados de infraestrutura, experiência do usuário ruim 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 da alta capacidade de composição. O crescimento do televisão e do fluxo de capital da Solana tem pouco impacto sobre o DRiP, que sofre principalmente com desvantagens, como altos custos de infra.

Vibhu ressalta: "A composabilidade tem retornos decrescentes". Ele também observa que Solana desenvolvedores de aplicativos estão discutindo em particular seu desejo por acúmulos por causa de:

1. Maior taxa de transferência de transações, menos competição de espaço de bloco e taxas reduzidas.
2. Maior controle sobre o valor econômico que seus negócios geram.

Link do Post

Nos últimos meses, Solana experimentou vários incidentes de congestionamento, que vão desde lançamentos aéreos como JUP até mineração ORE e pico de negociação memecoin. Embora se possa argumentar que o Firedancer pode resolver todas essas questões, sejamos realistas: o cronograma permanece incerto e não pode ir 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 L2 e L3 fragmentadas, entre outras? Qual é o cenário atual de appchains e acúmulos em Solana?

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

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

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

Em poucas palavras, discutiremos:

1. Solana e o congestionamento
2. Criando Solana Modular
3. Solana Appchains - com exemplos
4. Sollana Layer-2s e Rollups (RollApps) – com exemplos
5. Infra Powering Rollups e Appchains

Solana and the Congestion:

Vamos começar abordando o elefante na sala: a rede 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 tempos de ping altos, uma alta porcentagem de transações fracassadas e aumento de taxas de rede devido a taxas de prioridade mais altas. Apesar de tudo isso, Solana processou consistentemente cerca de 1-2k TPS, mais do que todas as cadeias de EVM 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 tomar ações imediatas para melhorar o desempenho da rede, incluindo:

• Implementação de taxas de prioridade – fundamental para evitar transações atrasadas ou perdidas.
• 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 staking – 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 tranquila. Uma correção imediata para esse problema é o aguardado novo Agendador de Transações, previsto 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á habilitado 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 sobre o @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">new Scheduler.

O Anza (uma entidade derivada da Solana Labs) tem tentado coninuamente tentar resolver os Congestionamento de rede que foram identificados 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.

Link do Post

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

1. Revisão dos mercados de taxas e aumento das taxas básicas (atualmente fixadas em 5.000 Lamports ou 0,000005 SOL).

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

3. Otimização de solicitações de orçamento de UC através de um sistema de penalidades.

4. Aprimorando a arquitetura geral da rede.

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

Atualização: Anza agora empurrou alguns patches ajudam a aliviar alguns dos Congestionamento de rede em andamento, e será seguido por mais melhorias na v1.18.

Making Solana Modular:

Os esforços para torná Solana modular já foram iniciados. Como indica Anza DevRel, o validador 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 acúmulos, o benefício pode vir da otimização da camada de Data Availability (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 por meio 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 equipes poderiam implementar apenas os módulos em que estão interessadas, enquanto utilizavam implementações estabelecidas para o resto, como as do Agave ou Firedancer.

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

Em linhas gerais, há duas direções, onde isso pode ir: Layer-2s/Rollups e Appchains. Vamos dar uma olhada em ambos – um por um.

Solana Appchains:

Também conhecidos como forks SVM, estes são essencialmente forks da cadeia 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 appchain Criador (para governança) baseado na base de código Solana (SVM). Ele escolheu o SVM devido à sua forte comunidade de desenvolvedores e superioridade técnica em relação a outras VMs, com o objetivo de garfo a cadeia de maior desempenho para melhor atender às necessidades dos consumidores. Embora nada tenha sido implementado ainda, essa medida gerou um debate muito necessário sobre Solana appchains.

Em linhas gerais, pode ser de dois tipos:

1. Sem permissão – Qualquer pessoa pode ingressar na rede, semelhante à rede principal Solana atual.
2. 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 de 10 a 20% de todas as transações na rede principal Solana. No entanto, ele não exigia nenhuma composição, então eles simplesmente bifurcaram a base de código Solana. Isso permitiu que eles aproveitassem o tempo de bloqueio rápido de 400 ms do Solana para atualizações de preços de alta frequência. A Pythnet foi a primeira rede a adotar o SVM para sua cadeia de aplicativos.

A cadeia de aplicativos Pythnet é uma garfo de Prova de Autoridade da rede principal 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 moveu?
-Não exigia alta capacidade de composição (particularmente para aplicativos não Solana) e, portanto, estava livre de congestionamento da rede principal.

• Ele precisava de um ambiente com permissão para publicar dados.
• Redução de custos de infra através da internalização das taxas, que antes era vazada para a camada base (Solana).

Cube Exchange é outro exemplo, um CEX híbrido implantado como um appchain SVM soberano (com um livro e liquidação completamente fora da cadeia ordem em sua cadeia de aplicativos SVM)

Alguns exemplos de Solana Appchains podem ser:

1. DEXs Perp: 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 de stop-loss diretamente no L1, garantir que ele seja aplicado como uma transição de estado ou introduzir lógica atômica específica para o aplicativo.
2. AI e DePIN: Eles podem apresentar uma lista controlada de provedores de serviços como a Pyth. Por exemplo, Akash opera como um mercado de computação por meio de uma cadeia de aplicativos do Cosmos.
3. Appchains de governança: Validado pelo interesse de MakerDAO em uma cadeia de aplicativos SVM, um appchain de governança soberana pode ser atraente. A governança em criptografia ainda está evoluindo, e ter uma cadeia dedicada ao garfo pode ser um mecanismo de coordenação útil.
4. Aplicações futuras da Enterprise: As aplicações potenciais incluem fundos (como BlackRock) ou sistemas de pagamento (como Visa ou CBDCs).
5. Gaming Appchains: Um projeto de jogos de cassino na Solana está considerando seu appchain.
6. Garfos modificados de Solana: Semelhante a como Monad ou Sei oferecem EVMs otimizados (paralelizados), alguém poderia construir uma versão mais otimizada do Solana. Essa tendência pode se tornar mais prevalente nos próximos anos, especialmente à medida que a mainnet Solana começa a explorar novas arquiteturas de design.

Visualizando a pilha de Solana Appchain:

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 nas Sub-redes >Avalanche (conectadas pelo Avalanche Warp Messaging) e nas cadeias de aplicativos do Cosmos (conectadas pelo IBC), Solana também poderia criar uma estrutura de mensagens nativa para conectar essas cadeias de aplicativos.

Link do Post

Pode-se também criar um middleware semelhante ao Cosmos-SDK, oferecendo uma solução pronta para a criação de appchains com apoiar integrados 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.

Uma rede de appchain é positiva para o ecossistema Solana?

Embora os appchains não acumulem valor diretamente para SOL, pois 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 há "efeitos de rede EVM", mais forks e appchains SVM fortalecerão os efeitos de rede SVM. A mesma lógica que torna o Eclipse (SVM L2 on Ethereum) Otimista para SVM se aplica, mesmo sendo um concorrente direto da mainnet Solana.

Solana Layer-2s:

Solana Layer-2s, ou acúmulos, são cadeias logicamente separadas que postam dados na camada Data Availability (DA) de sua cadeia de host e reutilizam o mecanismo de consenso da cadeia de host. Eles também podem usar outras camadas 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á explorando).

Rollups Solana seriam os mesmos que Ethereum?
Aparentemente não. Por Solana, os Rollups seriam principalmente abstraídos para o usuário final. Na frente ideológica, Ethereum acúmulos foram de cima para baixo, onde a Fundação Ethereum e os líderes decidiram que a melhor maneira de escalar era através acúmulos, e eles começaram a apoiar vários L2s após o fiasco do CryptoKitties. Enquanto na Solana, a demanda é de baixo para cima, ou seja, vinda de desenvolvedores de aplicativos com adoção significativa do consumidor. 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. Essa é uma diferença significativa e pode levar a um futuro diferente para acúmulos do que vimos em Ethereum.

Compressão = Rollups?

Os L2s dimensionam blockchains de camada base (L1s) executando transações no L2, agrupando os dados da transação em lote e compactando-os. Os dados compactados são então enviados para o L1 e usados no à prova de fraude (pacote cumulativo otimista) ou no prova de validade (pacote cumulativo de zk). Esse processo de comprovação é chamado de "liquidação". Da mesma forma, a compactação descarrega transações da mainnet, reduzindo a contenção de estado na camada base. Notavelmente, a Grass L2 aproveitará a Compressão de Estado 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 do tipo rollup, que se instala em intervalos Solana após N.

O
uso de uma estrutura semelhante a um rollup permite:

1. Flexibilidade: As intenções podem representar várias atividades futuras, não apenas transações de pagamento. Além disso, Solana como corrente também podem ser substituídos, se necessário.
2. 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 rede, o valor exato e a intenção permanecem obscuros, garantindo a privacidade do usuário.

2. Ephermal Rollups por MagicBlocks

MagicBlocks, uma infra de jogos web3 desenvolveu Ephermal (ou temporário) acúmulos, 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 SVM especializado ou rollup para facilitar o processamento de transações em uma taxa de transferência elevada.

O uso de uma estrutura semelhante a um rollup permite:

1. 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 clockwork, operado sem taxas).
2. Desenvolvedores para implantar programas na camada base (por exemplo, Solana) em vez de em uma cadeia separada ou rollup. Os ERs 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 acúmulos sob demanda e dimensionamento automático horizontalmente para acomodar usuários que realizam milhões de transações, sem as compensações típicas dos L2s tradicionais. Embora o MagicBlock seja especificamente focado em jogos, essa abordagem pode ser aplicada a outros aplicativos, como pagamentos.

Próximos pacotes cumulativos de Solana:

1. Grass: Um projeto DePIN destinado a resolver problemas de dados de IA por meio de raspagem verificada. Quando os nós do Grass raspam a web em busca de dados de treinamento de IA, validadores armazenará os dados na rede, rastreando precisamente onde os dados se originaram e qual nó foi responsável por raspá-los, recompensando-os proporcionalmente.

O Grass requer 1 milhão de solicitações da Web por segundo, o que é inviável na Solana mainnet. Portanto, eles planejam fazer provas ZK dos dados de origem para todos os conjuntos de dados e loteá-los para liquidação em Solana L1. Eles estão considerando usar a compactação de estado de outro cluster e estabelecer raízes no 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 exigem avaliações muito mais altas e a Grass está lançando o token em breve :P).

1. Zeta: Um dos DEX de perp mais antigos de Solana que tinha um ordem de perp completamente na rede livro também está planejando mover sua Coincidindo fora da cadeia por meio do rollup de Solana.

As DEXs Perp têm um PMF imediato para acúmulos 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 do DeFi, particularmente no aspecto de Coincidindo comercial.

Curiosamente, Armani (co-fundador da Backpack) também tuitou que agora estão tendendo para L2.

Sonic também está construindo uma cadeia SVM modular (Hypergrid) que permitirá que os jogos implantem suas próprias cadeias em Solana. Há também Ethereum acúmulos 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, há projetos em fase de ideia, como Molecule (um Bitcoin Camada 2 SVM).

Sovereign SDK é outra estrutura semelhante à node.js, mas para construir acúmulos. 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 do Rust pode ser sua lógica de aplicativo específica ou qualquer VM.

Algumas teses sobre Rollups:

1. Rollups = Being SOL-Aligned:
   O termo 'ETH-Aligned', ou uma palavra melhor para 'ETH Bag Biases', tornou-se um meme popular. Por que você acha que Layer 2s e Restaking/EigenLayer se tornaram a narrativa mais quente? É porque eles aumentam a "Moneyness of ETH", com ETH sendo usados como o principal ativo em todos os lugares.

O mesmo princípio se aplica a Solana. A comunidade Solana se unirá em torno de qualquer solução que impulsione 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 mais o Infra do que os Aplicativos.

1. Os pacotes cumulativos 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 fácil acesso a usuários e ativos Solana será uma vantagem significativa. Como observa Jon Charbonneau, 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 depósitos no L2 são instantâneos, etc.

Da mesma forma, isso acontecerá com Solana. Aprendendo com Ethereum, a maioria dos Rollapps Solana não fará com que os usuários sintam que estão usando uma cadeia separada (por exemplo, Getcode).

1. Solana verá mais "RollApps" do que "Rollups"
   Solana não tem um problema de escalabilidade como Ethereum onde a mainnet é simplesmente inutilizável devido a altas taxas de gás, é altamente otimizada. No entanto, alguns aplicativos que precisam de espaço de bloco dedicado criarão seus acúmulos. Embora Rollups de uso geral em Solana não façam sentido para mim, economicamente faz sentido para os projetos. Por exemplo, Os usuários da base geraram US$ 2 milhões em receita para a Coinbase em apenas um dia! Os incentivos para os construtores sã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 alguns agricultores realizando algumas transações para airdrops de tokens.

Além disso, sinto que L2s de uso geral em Solana podem levar aos mesmos velhos problemas de Ethereum, ou seja, acúmulos centralizado, congestionamento e fragmentação de liquidez.

1. Por que alguns aplicativos gostariam de migrar para o Rollapps/appchain?
   Cada aplicativo começará inicialmente no Solana Mainnet, pois hospedar mais aplicativos em infraestrutura compartilhada reduz significativamente a complexidade do desenvolvedor e do usuário. No entanto, à medida que esses aplicativos crescem, eles podem buscar:
   • 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 dedicada do Blockspace
   • em 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 ordem personalizados
2. 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, televisão 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 para os 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 Aplicativos: Solana Mainnet ou Appchain ou Rollup
   Depende completamente. Se não houver uma forte necessidade de composição com todos os outros aplicativos, fazer 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)

1. 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 migrar para sua própria cadeia. Uma estrutura pseudo-rollup como Getcode faz completamente 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 exploram novos mercados:

1. Os provedores de Rollup as a Service (RaaS) existentes, como Caldera, podem entrar facilmente no mercado SVM à medida que a demanda surge. Ethereum acúmulos SVM como Eclipse e NitroVM também estão observando atentamente essa oportunidade. Além disso, a Sovereign Labs oferece um adaptador Sovereign SDK Solana que permite acúmulos 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.
2. Sequenciadores compartilhados como Protocolo de Roma e a necessidade de Clientes de Luz como Tinydancer. Os sequenciadores compartilhados podem ser interessantes para acúmulos pois permitem atividades como arbitragem atômica, MEV e ponte contínua, diminuindo a fragmentação da liquidez.
3. 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".
4. SOL Restaking: A tese modular também promove a retomada, pois esses acúmulos/appchains podem exigir SOL segurança compartilhada e se tornar mais alinhados com Solana. Isso leva a:
   1. Jogadores em estágio inicial como Cambrian, Picaso, e Solayer
   2. Jito via Stakenet e LSTs como Sanctum
   3. Validators — aumento da receita

Pensamentos finais: Solana pode lidar com a demanda do mundo inteiro?

Definitivamente não. Sejamos 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 migrando para suas próprias cadeias, enquanto as transações mais valiosas permanecerão na cadeia principal, onde a verdadeira composabilidade é essencial (por exemplo, Spot DEXs).

E não, isso não significa que Solana perdeu na batalha do monólito e da composabilidade, ela 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, pois não sabemos e eles ainda estão para ser testados para a alta atividade real do usuário.

Ao contrário de Ethereum, a Solana Mainnet 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 podem 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ê acha isso até um pouco perspicaz, por favor, compartilhe-o - justifica minhas semanas de esforço e recebe mais olhares :)

Agradecimentos especiais a Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), e Akshay (Superteam), que revisou e forneceu insights em diferentes estágios do draft.

Isenção de responsabilidade:

1. Este artigo foi reproduzido 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 prontamente.
2. 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.
3. 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.