Deixe-me colocar desta forma...
Quando as pessoas discutem sobre L1s e L2s, a conversa quase sempre se transforma em um debate sobre velocidade. L2s são mais rápidos, L1s são mais lentos, e isso se torna a manchete. Mas não é assim que as equipes tomam decisões uma vez que estão pensando além de experimentos e usuários iniciais.
Nesse ponto, a questão muda. É menos sobre desempenho máximo e mais sobre responsabilidade. Quando algo acontece na rede, quem está realmente no comando do resultado? Onde reside a finalização? Quem define as regras sem depender de outro sistema se comportando corretamente?
É aí que a soberania do L1 começa a importar. Em uma configuração soberana de L1, a mesma rede que processa transações também é responsável pela propriedade, liquidação e lógica de execução. Não há uma camada extra embaixo ou em cima que precise coordenar para que os básicos funcionem. Tudo que é importante acontece em um só lugar.
L2s não são um erro. Eles existem porque resolvem problemas reais. Eles podem reduzir a congestão e melhorar a eficiência, especialmente em picos. Mas eles também adicionam distância entre a ação e a finalização. Sequenciadores, pontes, janelas de liquidação — essas são todas escolhas de design razoáveis, mas ainda são suposições adicionais. A maioria dos usuários não pensa diretamente sobre elas, mas sente os efeitos quando algo leva mais tempo do que o esperado ou se comporta de maneira ligeiramente diferente sob carga.
Manter as coisas dentro de um único L1 remove muita dessa incerteza. Os ativos não se movem entre camadas. O estado não espera para ser finalizado em outro lugar. Os desenvolvedores não precisam pensar constantemente sobre qual camada é responsável por qual resultado. Não é uma arquitetura empolgante, mas é mais fácil de raciocinar à medida que o uso cresce.
A escala do consumidor não apenas estressa a taxa de transferência. Ela estressa a consistência. Taxas se comportando de forma previsível. Transações sendo finalizadas quando as pessoas esperam. O sistema se sentindo familiar, mesmo quando a atividade aumenta. Esses detalhes parecem pequenos no início, mas se acumulam rapidamente quando usuários reais estão envolvidos.
A arquitetura de Vanar reflete esse modo de pensar. Priorize controle e coerência primeiro, depois otimize a velocidade dentro de uma estrutura que o protocolo possui totalmente. Em vez de empurrar a complexidade para fora e esperar que permaneça invisível, lide com isso diretamente na camada base.
Isso não é sobre dizer que L1s são melhores ou que L2s são piores. Trata-se de escolher onde a complexidade reside e quanta coordenação você está disposto a depender ao longo do tempo. Para sistemas voltados para o consumidor, menos partes móveis muitas vezes envelhecem melhor do que atalhos inteligentes.
Então, a troca não é realmente velocidade versus lentidão. É simplicidade de responsabilidade versus coordenação em camadas. A escolha de Vanar inclina-se para o primeiro, com base em como os sistemas se comportam uma vez que não são mais pequenos. Essa é a lógica por trás disso.
