- Tema
34k Popularidade
12k Popularidade
6k Popularidade
16k Popularidade
61k Popularidade
31k Popularidade
2k Popularidade
95k Popularidade
27k Popularidade
27k Popularidade
- Marcar
34k Popularidade
12k Popularidade
6k Popularidade
16k Popularidade
61k Popularidade
31k Popularidade
2k Popularidade
95k Popularidade
27k Popularidade
27k Popularidade
Interpretação da importância da descentralização do Rollup de vários ângulos
Autor Original: Shivanshu Madan
Compilação original: Luffy, Foresight News
Ultimamente, muita discussão no Crypto Twitter gira em torno da descentralização L2. O Rollup que estamos construindo é descentralizado o suficiente? Eles já estão no caminho da descentralização? Isso importa?
Vou explorar esses temas neste artigo. Antes de me aprofundar, se você ainda não sabe como os Rollups realmente funcionam, sugiro que dê uma lida rápida neste artigo: Rollups for Dummies.
A ideia do Rollup é bastante simples: ele quer que os participantes fora da cadeia realizem transações que possam ser facilmente verificadas na cadeia. Com o Rollup, a "confiança" da camada base é estendida para atividades fora de seu blockchain. Em troca, o Rollup paga uma pequena taxa (aluguel) para usar essa confiança.
Então, precisamos de Rollup descentralizado?
A resposta intuitiva é: definitivamente preciso! Este é o espírito do blockchain.
No entanto, também acredito que a resposta a esta pergunta não é um simples sim ou não. Pelo contrário, abrange múltiplos aspectos, que devem ser analisados individualmente. A seguir, explorarei essa questão a partir de três perspectivas: filosofia, tecnologia e economia.
Perspectiva filosófica
Vamos começar elevando a conversa: por que nos preocupamos com a descentralização?
Porque queremos um futuro sem permissão que promova a inovação aberta. Queremos que os usuários possam construir coisas novas sem nenhuma restrição e sem precisar confiar em nenhuma entidade.
Na curta história do blockchain, muitos desenvolvedores anônimos construíram coisas incríveis. Na verdade, o próprio Bitcoin foi criado por uma entidade anônima e pode em breve se tornar a moeda de pagamento global usada pela maior parte do mundo. Esse é o poder da inovação sem permissão!
Blockchain nos permite trabalhar com pessoas que não têm nada em comum e sabemos que não há como quebrar essa confiança.
——Preston Evans
A base descentralizada de redes sem confiança como Bitcoin e Ethereum nos permite construir esse futuro. Obviamente, qualquer cadeia que tenha relação de confiança com essas blockchains, como a Rollup, também deve ser descentralizada!
Na verdade, levanta uma questão interessante e importante:
Se o Rollup não for descentralizado, isso significa que o Ethereum não é descentralizado?
Uma maneira um pouco otimista de ver isso é que, em um mundo sem permissão, os Rollups devem ter permissão para criar o que quiserem, incluindo (mas não limitado a) cadeias de permissão, e os usuários desse Rollup ainda seriam capazes de alavancar a segurança da camada subjacente . Contanto que a camada base seja descentralizada e o Rollup seja "totalmente implementado" (falaremos mais sobre "implementação completa" na seção técnica), mesmo as cadeias permitidas devem ser seguras de usar.
Mas a realidade é que a maioria dos Rollups hoje não atingiu o estágio de implementação completa e não fornece aos usuários o nível de segurança e falta de confiança de que precisam.
Então, qual é a implementação correta do Rollup? vamos ver:
Perspectiva Técnica
Para entender verdadeiramente a descentralização e as preocupações de segurança do Rollup, precisamos analisá-lo a partir dos primeiros princípios. Poucas pessoas podem explicar os primeiros princípios da blockchain melhor do que Sreeram Kannan.
Blockchain é um livro-razão distribuído e diferentes nós na rede seguem regras de protocolo predeterminadas para obter um consenso sobre o estado do livro-razão. Dependendo de como esses nós veem a rede, eles podem ter regras diferentes para confirmar o estado correto de sua própria rede de registro.
Especialmente no Rollup, full nodes e light clients possuem diferentes regras de confirmação. No tradicional contrato inteligente Rollup (SCR), o contrato inteligente (ponte de verificação) possui suas próprias regras de confirmação. Se não houver eventos adversos, essas regras de confirmação acabam por coincidir nas chamadas "regiões de consistência". Como o nome indica, em uma zona de consenso, todos os participantes têm a mesma visão da rede (e o mesmo histórico no ledger).
Se todas as regras de confirmação forem seguras, nada de ruim acontecerá. Como Sreeram compartilhou no post acima, 5 propriedades definem principalmente a segurança dessas regras de confirmação.
As 2 primeiras propriedades definem a condição "ativa" do sistema, enquanto as 3 últimas propriedades definem a condição "segura".
Vamos examinar esses problemas da perspectiva de diferentes participantes do Rollup e ver quais podem ser mitigados sem descentralização.
Diferentes atores dependem de diferentes mecanismos de segurança e vivacidade
Nó completo:
Se você executar um nó completo, terá acesso aos dados publicados e poderá verificá-los diretamente. Você mesmo pode usar esses dados para executar transações e determinar a validade das transações e o estado final do Rollup após essas transações.
As condições de segurança restantes são, portanto, atividade e resistência à recombinação. Para resistência à reorganização, os nós completos contam com os validadores da cadeia de base e o protocolo de consenso que ela usa, enquanto para a vivacidade, os nós completos contam com a implementação do Sequencer e Rollup.
Cliente leve:
A maioria dos usuários interage com o blockchain usando clientes leves para buscar dados do blockchain. Existem vários tipos de nós de luz:
Se você executar um full validator light client, poderá verificar se os dados estão disponíveis por meio de amostragem de disponibilidade de dados, verificar a validade das transições de estado por meio de provas de validade ou provas de fraude e verificar se o estado segue o consenso da camada base (no Ethereum acima , pode ser feito seguindo o comitê de sincronização).
Então, a condição de segurança restante é a vivacidade, e o cliente leve depende do sequenciador e da implementação do Rollup.
Contrato inteligente integrado (ponte de verificação):
No SCR tradicional, a "regra de confirmação" de um contrato inteligente é aplicar todas as 5 propriedades de segurança:
Os nós completos de SCR dependem de contratos inteligentes para impor propriedades de vivacidade. Eles obtêm sua resistência à reorganização da camada de base.
Os nós leves contam com contratos inteligentes para aprimorar as propriedades de vivacidade e absorver DA e resistência à reorganização da camada base. Eles podem verificar as provas de validade por conta própria ou por meio de contratos inteligentes.
O consenso do SCR é seguir a cadeia canônica definida pelo contrato inteligente.
E quanto aos Sovereign Rollups?
Sovereign Rollups não possuem contratos inteligentes (pontes de validação) para impor condições de validade ou vivacidade. Em vez disso, eles provarão "rolar para baixo" para os nós Rollup downstream. Esses nós ainda contam com a disponibilidade de dados e a resistência à reorganização da camada base.
Assim como no SCR, no Sovereign Rollup, os nós precisam de algum mecanismo para impor a propriedade de vivacidade. Para definir a cadeia canônica, eles optaram por mecanismos independentes, como a transmissão de provas p2p.
O que tudo isso tem a ver com descentralização?
Seja um Rollup de contrato inteligente ou um Rollup soberano, a propriedade de vivacidade vem da implementação correta do Rollup. Como vimos acima, uma implementação correta do Rollup deve incluir dois componentes importantes:
Mecanismos de inclusão obrigatórios ajudam a aumentar a resistência à censura. Este mecanismo permite aos usuários "forçar a inclusão" de suas transações diretamente na camada base. Qualquer usuário no Rollup pode forçar a retirada de seus fundos de volta à camada base. Portanto, mesmo que haja apenas um nó de agrupamento centralizado, ele não pode censurar usuários, desde que haja um mecanismo de inclusão obrigatório maduro.
Mas isso é suficiente?
Mesmo que os usuários estejam livres para sair, isso pode significar que o L2 não tem muito incentivo para continuar operando se a maioria dos usuários voltar para o L1. Além disso, o mecanismo de inclusão obrigatória geralmente tem um longo tempo de espera e pode ser bastante caro de implementar para o usuário comum. A resistência à censura fornecida por este mecanismo não é totalmente prática (ou em tempo real), podemos chamá-la de "censura fraca".
Em seguida, temos o atributo de atividade final - crescimento do livro-razão.
Se o ordenador centralizado fizer algo errado, ele pode parar o crescimento da cadeia Rollup simplesmente parando a produção de blocos. Se isso acontecer, não há nada que o usuário possa fazer para tornar o Rollup "ativo" novamente.
Para resolver esse problema, precisamos de um protocolo de substituição do classificador.
A ideia do Sequencer Replacement Protocol é que, se um Sequencer se comportar de maneira maliciosa, o Rollup é capaz de iniciar um novo Sequencer por meio de governança. Uma das maneiras de conseguir isso é substituir os nós de pedido centralizados por protocolos de pedido descentralizados. Se o ordenador for descentralizado e não monopolizar a construção de blocos do Rollup, será quase impossível bloquear a cadeia Rollup.
Assim, embora os fundos do usuário estejam sempre seguros em Rollups por meio do mecanismo de inclusão obrigatória, a construção de um protocolo robusto de substituição de pedidos ajuda a manter os Rollups ativos e fornece resistência à censura prática e em tempo real.
Isso é tudo?
não completamente. Do ponto de vista técnico, há mais um aspecto a considerar:
E se os próprios contratos inteligentes pudessem ser atualizados pelo comitê central do Rollup? Digamos que o Rollup esteja implementado corretamente, mas amanhã o comitê concorda que não precisamos mais de contratos inteligentes, mas sim transmitir provas do estado do Rollup para a rede p2p.
Se, como usuário do Rollup, você discordar dessa atualização, poderá sair do Rollup antes que a atualização seja implementada (embora essa não seja uma boa experiência do usuário e possa não ser boa para os negócios). Isso pode ser alcançado por meio de "atualizações de governança atrasadas", como um "período de notificação", após o qual as atualizações serão implementadas. Os usuários que não concordarem com as atualizações podem desistir dentro do período de notificação.
O extremo da descentralização é ter contratos inteligentes completamente imutáveis. Esses contratos não são regidos por nenhuma carteira de assinatura múltipla ou outro comitê e, uma vez implantados, nunca poderão ser atualizados.
Claro, isso tem seus próprios problemas. Se houver algum bug no código ou algum evento importante exigir que o contrato inteligente seja atualizado, a única opção do Rollup é bifurcar para o novo contrato inteligente, enquanto os fundos do usuário ficam presos no contrato antigo.
Infelizmente, o estado atual do Rollup está longe da implementação completa que discutimos acima. A maioria dos Rollups ainda está na fase de "exploração", tentando implementá-los corretamente.
Segundo o L2 BEAT, o Fuel v1 e o DeGate são os dois únicos Rollups que amadureceram para atingir todas as condições de atividade e segurança.
Perspectiva Econômica
Finalmente, vamos dar uma olhada na economia do Rollup sob a perspectiva dos usuários e operadores do Rollup:
A experiência do usuário é otimizada quando os usuários recebem serviços de transação rápidos e baratos.
A velocidade na qual as transações são finalizadas depende da velocidade na qual a camada base é finalizada. As transações podem ser consideradas finais sempre que os dados em L1 forem finalizados. No entanto, os usuários que executam nós completos também podem obter finalização instantânea simplesmente executando transações e determinando o estado final.
Mas não é prático para todos executar um nó completo. Portanto, um classificador centralizado é útil porque pode fornecer aos usuários uma "confirmação suave" de que sua transação está incluída em um bloco e será finalizada. Isso é suficiente para a maioria dos casos de uso. No entanto, depende de instituições centralizadas que podem tomar ações adversas.
Enquanto algumas soluções de protocolo alternativo ao solicitante renunciam a essa propriedade (como desvantajosa para os usuários), outras soluções, como o esquema de consenso PoS externo Espresso, podem fornecer garantias de pré-confirmação semelhantes sem o risco de um solicitante centralizado.
E quanto aos custos do usuário?
O custo explícito de uma transação Rollup é geralmente:
Custo do gás L2 = Custo do gás L1 + Taxa do sequenciador. Classificadores centralizados racionais sempre querem maximizar seus lucros, mesmo que isso signifique repassar custos mais altos para os usuários. No entanto, vale a pena notar que isso também não pode necessariamente ser resolvido por um mecanismo de classificação descentralizado. Mesmo os nós PoS em um pedido descentralizado desejam maximizar seus próprios lucros.
Na verdade, isso cria um problema de incompatibilidade, em que o Rollup pode não querer entregar os lucros a sequenciadores externos.
Lucro Rollup: Além das taxas do sequenciador, o Rollup também pode obter lucro extraindo MEV das transações do usuário. Esse MEV geralmente é difícil de atribuir porque é difícil descobrir se o solicitante inclui algumas de suas próprias transações iniciais no pacote de transações.
Se o Rollup for substituído por um consenso PoS externo, eles entregarão esse MEV a um operador externo.
Vale a pena notar que ambos os problemas de Rollup entregando receitas a mecanismos externos podem ser resolvidos por meio de "acordos de transação" entre Rollup e mecanismos externos.
No entanto, conforme explicado na palestra de Jon Charbonneau durante o Modular Summit e na postagem subsequente, uma ideia melhor seria fazer com que a governança do Rollup delegue o pedido a um conjunto de nós validados. Esses nós podem ser escolhidos estrategicamente para serem dispersos geograficamente, e a governança pode simplesmente expulsar os maus atores.
Essa pode ser uma solução que mata dois coelhos com uma cajadada só, pois permite que a Rollup mantenha os lucros internos e, ao mesmo tempo, mitiga a desvantagem dos classificadores centralizados.
Mas, ao contrário, no caso de rotação limitada do sequenciador, o sequenciador pode ter um comportamento míope, o que pode levar a preços de monopólio/extorsão de preços, prejudicando ainda mais os interesses dos usuários de Rollup sacrificados.
De qualquer forma, para que o Rollup seja econômico para os usuários, é necessário algum protocolo de substituição do classificador.
para concluir
Independentemente do caminho que o Rollup tome, é crucial que ele tenha como objetivo uma implementação completa com um protocolo de substituição de sequenciador maduro, inclusão obrigatória e mecanismos de atualização de governança de lag. Se houver um mecanismo para inclusão obrigatória e atualizações atrasadas, os fundos do usuário estarão seguros, independentemente de o classificador ser centralizado ou não.
No entanto, um protocolo de substituição de sequenciador robusto pode melhorar as garantias de vivacidade e potencialmente melhorar a economia para os usuários do Rollup.