Uma Conversa Honesta Sobre L2s
O que são Layer 2s?
Hoje, Layer 2s (L2s) são promovidas como um dos santos grais das soluções de escalonamento, mas muitas pessoas não percebem que L2s são na verdade blockchains separadas usadas para comprimir dados para caber mais transações em cada bloco L1. Para maximizar o impacto de um L2, você pode usar até 100% do espaço de bloco L1 para o L2. No entanto, o gargalo fundamental permanece escalonando a quantidade de dados propagados no L1. A mesma compressão e agrupamento de transações dos L2s pode ser aplicada a uma cadeia muito mais performática que Ethereum para o mesmo % de aumento de performance aplicado a blocos muito maiores. Assim, uma conversa sobre o potencial dos L2s é também uma conversa sobre o design do L1.
L1s e L2s compartilham os mesmos componentes (ambos são blockchains), o que significa que precisaremos otimizar para as características corretas para alcançar as propriedades e performance desejadas de cada um. Para obter uma compreensão dos L2s e seu impacto, examinaremos alguns dos trade-offs que envolvem e como estes impactam a experiência do usuário e desenvolvedor, itens críticos no caminho para adoção em massa.
Imagine que a cada segundo um caminhão de mudança para em frente à sua casa e pausa por um segundo, depois vai embora. Outro caminhão então toma seu lugar e o ciclo se repete sem parar. Você pode pensar em cada caminhão como um bloco que é preenchido com dados antes de ser submetido a todos os nós para aprovação. Designers de blockchain de próxima geração têm o interessante desafio de escrever software para embalar blocos com dados em um segundo ou menos. Mas o que acontece quando os blocos começam a ficar cheios? Entram os Layer 2s (L2s).
L2s são blockchains separadas que estendem a camada base e herdam suas garantias de segurança, permitindo que o L1 use o espaço escasso de bloco de forma mais eficiente, agrupando ou juntando muitas transações em uma antes de submeter ao L1, usando menos dados e reduzindo significativamente as taxas de gas.
Enfatizamos que os L2s são, de facto, blockchains separadas porque à medida que os L2s continuam a descentralizar-se ao adicionar múltiplos sequenciadores, será necessário estabelecer quórum e consenso entre eles.
Na verdade, os L2s têm o seu próprio ambiente de execução, propagação de dados, algoritmo de consenso e potencialmente armazenamento como qualquer outra blockchain devido ao quórum.
A forma mais simples de explicar o papel dos L2s (também conhecidos como "rollups") é que eles funcionam como compressão de dados, conforme ilustrado no diagrama abaixo:
É importante notar que, embora os L2s permitam ajustar mais dados num bloco, não possibilitam espaço de bloco ilimitado. Por outras palavras, se um L2 comprime dados e 100% do espaço de bloco do L1 for usado para o L2, o espaço geral de bloco é usado de forma mais eficiente, mas a quantidade bruta de dados no L1 permanece inalterada. Este conceito é ilustrado abaixo com vários tamanhos de bloco sendo comprimidos por 500x
Blockchain A: bloco de 1,3MB * 500 torna-se efetivamente 650MB
Blockchain B: bloco de 100MB * 500 torna-se 50.000MB ou efetivamente 50GB
As Blockchains A e B ainda estão a propagar blocos de 1,3MB e 100MB respetivamente na camada base.
Este conceito é realmente bastante poderoso. Esta técnica pode até ser replicada noutra camada acima do L2, com um L3, permitindo uma camada adicional de compressão de dados que se estabelece no L2 e finalmente se estabelece no L1. No entanto, isso apenas amplificaria ainda mais alguns dos aspetos negativos dos L2s que abordaremos neste artigo.
Que papel desempenham os L2s na adoção em massa?
Se L2s são uma tecnologia tão inovadora e aumentam a performance da L1 subjacente, por que não adicionar uma L2 separada para cada chain e pronto? Na realidade, poucos trade-offs são sem custo, e L2s não são exceção. Este artigo dissecará algumas das nuances por trás das L2s no contexto da experiência do usuário e desenvolvedor, que são dois itens-chave no caminho para adoção em massa.
Para integrar milhões ou bilhões de usuários que estão acostumados a uma experiência Web2 perfeita, os pontos de dor do Web3 precisam ser abstraídos. Essa abstração por engenheiros inteligentes cria uma camada suave e autoexplicativa construída para o menor denominador comum de usuários. Apesar de todos os seus méritos, as L2s introduzem fricção e fragmentam a experiência do usuário numa época em que deveríamos buscar suavizar pontos de resistência, não criá-los.
Quais são algumas das desvantagens dos L2s na perspetiva do utilizador e do programador?
Fazer bridge é complicado e arriscado
A "finalidade" só é final na camada base
Alta latência equivale a design e UX pobres
As camadas criam uma experiência fragmentada
A perda de composabilidade prejudica a composição da inovação
Para transacionar no L2, é necessário primeiro fazer bridge de fundos de outra blockchain para o Layer 2. Fazer bridge é atualmente uma das atividades de maior risco em toda a crypto, com a Chainanalysis reportando que se estima que $2B foram perdidos em explorações de bridges cross-chain apenas em 2022. Qualquer pessoa que tenha usado uma bridge pode concordar que é um processo complicado e doloroso, que geralmente envolve minutos de espera para os fundos chegarem, cruzar os dedos para não perder o dinheiro, e adicionar uma conta de token para os fundos aparecerem (líquidos de taxas elevadas!) numa carteira não-custodial como a Metamask.
Se isto não fosse suficiente, são frequentemente necessários passos adicionais de unwrapping de tokens usando uma dex (exchange descentralizada) ou a funcionalidade de swap de uma carteira para finalmente obter a moeda ou token desejado. Em resumo, este processo de múltiplos passos deixa muito a desejar e é complicado de explicar mesmo a um utilizador Web3 nativo de crypto, quanto mais a alguém que não tem ideia do que são confirmações ou um explorador de blocos…
Do lado do desenvolvedor, imagine a complexidade de escrever um contrato que envolve iniciar uma transação que começa na L1, transfere ativos para a L2, realiza uma operação lá, e depois retorna para a L1. Essa complexidade adicional para desenvolvedores e usuários deveria ser reservada apenas para situações onde nenhuma outra alternativa existe, como último recurso, não como a oferta padrão para a grande maioria das transações, como alguns podem sugerir.
Além disso, uma transação não pode ser completamente considerada final até que seja liquidada na L1 e confirmada. Ethereum faz um bloco a cada ~12 segundos, significando que uma transação L2 pode levar 12s ou mais para ser finalizada. Para muitos usuários, aqueles fazendo ações que não são críticas ou sensíveis ao tempo, talvez esse seja um tempo aceitável para finalização (TTF).
Imagine um trader alavancado que está a segundos de ser liquidado, incapaz de fechar sua posição a tempo - isso poderia ser um fator decisivo em sua decisão de optar por uma chain em vez de outra. Mais uma vez, o escopo e a extensão do que engenheiros de produto e aplicação podem projetar é limitado pela finalização lenta. É indubitavelmente um dos aspectos da experiência do usuário que as pessoas sentem mais agudamente.
Outro efeito de usar uma L2 é a alta latência, que está diretamente associada à experiência ruim do usuário. Baixa latência de rede é fundamental para adoção em massa. Como esperamos competir com jogos multijogador massivos convencionais e experiências virtuais quando cada ação tem um atraso perceptível ou 'lag' antes da conclusão? Experiências mais rápidas e sincronizadas são melhores em praticamente todas as situações imagináveis.
Construir boa tecnologia é difícil, mas construir uma camada social durável pode ser um desafio ainda maior. O que significa fragmentar a atividade do usuário através de várias L2s para a construção orgânica de comunidade necessária para criar um ecossistema saudável? E se, em vez de construir pontes entre dApps, projetos NFT e suas comunidades, as L2s estão construindo muros? Este efeito não deveria ser ignorado.
Para desenvolvedores, como blockchains completamente separadas, as L2s têm dependências upstream à L1. Isso significa que qualquer mudança na L1 subjacente tem que ser refletida na L2. Imagine ter que constantemente debugar e verificar seu código porque alguma pequena atualização foi aplicada na L1. Torna-se tedioso e cansativo, e a possibilidade de erros descuidados é quase infinita.
A Navalha de Occam dita que a solução mais simples com o menor número de partes móveis é geralmente a melhor, e blockchains não são exceção.
Além disso, o que significa a perda de composabilidade entre L1 e L2 para desenvolvedores, que são incapazes de usar nativamente recursos existentes como blocos de construção e programá-los em aplicações de ordem superior? A perda de composabilidade entre L1 e L2 é enormemente prejudicial para a experiência do desenvolvedor e isso pode ter efeitos massivos de segunda ordem na composição de longo prazo da inovação em um ecossistema.