Muito da discussão no Twitter ultimamente gira em torno da descentralização L2. Os Rollups que estamos construindo são descentralizados o suficiente? Ou pelo menos estão no caminho da descentralização? Isso importa?
A ideia do Rollup é simples: queremos que os participantes fora da cadeia possam realizar transações que possam ser facilmente verificadas na cadeia. Com o Rollup, a camada base permite que sua base de "confiança" seja utilizada para atividades que ocorram fora de sua esfera imediata. Em troca, o Rollup paga uma pequena taxa (aluguel) para alavancar essa confiança.
Então, precisamos de Rollups descentralizados?
A resposta intuitiva é sim! Este é o espírito com o qual construímos o blockchain.
No entanto, acredito que a resposta a esta pergunta não seja um simples sim ou não. Em vez disso, tem múltiplas facetas que devem ser analisadas individualmente. Nos capítulos seguintes, analisarei essa questão sob três perspectivas: filosófica, tecnológica e econômica. ****Estes três não são necessariamente exaustivos ou exclusivos, mas devem dar uma boa perspectiva geral do problema. **
1. 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 - em breve pode ser a moeda que a maioria das pessoas no mundo usa para pagamentos globais! Esse é o poder da inovação sem permissão!
Blockchain nos permite colaborar 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. Então é óbvio que qualquer cadeia que tenha uma relação de confiança com essas cadeias, como Rollups, 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 construir o que quiserem, incluindo (mas não limitado a) cadeias totalmente autorizadas - e os usuários desse rollup ainda devem ser capazes de alavancar a segurança no camada de base. Mesmo as cadeias permissionadas devem ser seguras de usar, desde que a camada base seja descentralizada e o rollup seja "totalmente" implementado (falaremos mais sobre "totalmente implementado" na seção técnica).
Mas a realidade é que a maioria dos rollups hoje ainda não atingiu o estágio de implementação completa e não fornece aos usuários o nível desejado de segurança e falta de confiança.
Então, como é a implementação correta do rollup? vamos ver:
2. Tecnologia
Para entender verdadeiramente a questão da descentralização e segurança no nível do Rollup, precisamos analisá-la desde os primeiros princípios. Poucas pessoas podem explicar os primeiros princípios da blockchain melhor do que Sreeram Kannan.
Um blockchain é um livro-razão distribuído onde diferentes nós da rede seguem um protocolo definido para obter 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 da rede em seu próprio registro.
Por exemplo, no protocolo Gasper da Ethereum, existem duas regras de confirmação diferentes - a regra disponível (baseada na cadeia mais pesada) e a regra final (baseada nos blocos confirmados pelo gadget).
Especialmente em rollups, os nós completos têm regras de confirmação diferentes dos clientes leves. No tradicional smart contract rollup (SCR), o contrato inteligente (ponte de verificação) tem 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, nas zonas de consenso, todos os participantes têm a mesma visão da rede (e têm o mesmo histórico em seus registros).
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.
Crescimento do razão - A cadeia de acúmulo deve continuar crescendo (vivacidade)
Resistência à censura - Todos os usuários devem poder incluir toda e qualquer transação na camada base
Resistência à reestruturação - a transação não deve ser restabelecida depois de concluída
Disponibilidade de dados - os dados da transação devem ser publicados em algum lugar
Validade - transações e transições de estado devem ser válidas
As 2 primeiras propriedades juntas definem a condição "ativa" do sistema, enquanto as 3 últimas propriedades definem a condição "segura".
Vamos olhar para cada um da perspectiva de diferentes atores de agregação 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ê pode usar esses dados para realizar transações por conta própria 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, propriedades de atividade e resistência à recombinação. Para o último, os nós completos dependem dos validadores da cadeia subjacente e do protocolo de consenso que eles usam, enquanto para as propriedades de vivacidade, os nós completos dependem do sequenciador e das implementações de Rollup.
Cliente leve:
A maioria dos usuários usa carteiras incorporadas em light nodes ou serviços de terceiros para obter dados de blockchain e interagir com o blockchain. Os nós de luz podem ser de vários tipos:
Validador de estado - verifica a validade das transições de estado,
DA Validator - Valida a disponibilidade de dados,
**validador de consenso - validando a prova de consenso da camada base, ou **
verificador completo - verifica todos os itens acima
Se você executar um light client full-validator, poderá verificar se os dados estão disponíveis por meio de amostragem de disponibilidade de dados, poderá verificar a validade das transições de estado por meio de provas de validade ou provas de fraude, também poderá verificar se o estado foi finalizado na base Consenso da camada (no Ethereum, isso pode ser feito seguindo um comitê de sincronização).
A condição de segurança restante é então a propriedade de vivacidade, e os clientes leves contam com as implementações do sequenciador e 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:
Crescimento do ledger através do protocolo de substituição do sequenciador
Resista à censura reforçando a inclusão
Crie resistência à reorganização apenas em cima do estado anterior
A disponibilidade de dados é obtida enviando DA na camada base
Verificação de validade via comprovante de validade/fraude
Os nós completos do SCR dependem de contratos inteligentes para impor propriedades de vivacidade. Eles "absorvem" a resistência à reestruturaçã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 a prova 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 ao Sovereign Rollup? **
Sovereign Rollups não têm contratos inteligentes (pontes de verificação) para impor condições de validade ou vivacidade. Em vez disso, eles provarão "rolar para baixo" para um nó de rollup downstream. Esses nós ainda absorvem resistência DA e Reorg da camada de base.
Assim como no SCR, no rollup soberano, 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 da agregação deve incluir dois componentes importantes:
mecanismos obrigatórios de inclusão, e
Protocolo de substituição do sequenciador
A inclusão obrigatória ajuda a criar 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 então forçar a saída de volta para a camada base com seus fundos. Portanto, mesmo que haja apenas um nó de agrupamento centralizado para agregação, ele não poderá censurar os usuários, desde que haja um mecanismo de imposição maduro em vigor.
Mas isso é suficiente?
Mesmo que os usuários possam fazer logout, isso pode significar que, se a maioria dos usuários voltar para o L1, a empresa não terá muito incentivo para continuar executando. 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 esse mecanismo não é exatamente prática (ou em tempo real). Podemos chamar essa situação de "censura fraca".
Depois temos o atributo de vivacidade final - crescimento do livro-razão
Se o agrupador centralizado se tornar malicioso, ele pode interromper o crescimento da cadeia de resumo simplesmente interrompendo a produção de blocos. Se isso acontecer, não há nada que o usuário ou empresa possa fazer para tornar o rollup "ativo" novamente.
Para resolver este problema, precisamos de um protocolo de substituição do sequenciador.
A ideia do protocolo de substituição do sequenciador é que, se o sequenciador se comportar de maneira maliciosa, a governança agregada pode iniciar o sequenciador. Uma das maneiras de conseguir isso é substituir os nós do sequenciador centralizado por um protocolo de sequenciador descentralizado. Se o classificador for descentralizado e não monopolizar os blocos de construção do rollup, é quase impossível interromper o rollup.
Assim, enquanto os fundos do usuário estão 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 exatamente. Do ponto de vista técnico, há mais um aspecto a considerar:
E se os próprios contratos inteligentes pudessem ser atualizados por um comitê central agregado? Digamos que os rollups estejam implementados 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 de rollup, você não concordar com tal atualização, poderá sair da rollup antes que a atualização seja implementada (embora, novamente, essa não seja uma boa experiência do usuário e possa ser ruim para os negócios). Isso pode ser alcançado por meio de "atualizações de governança defasadas". É como um "período de notificação" após o qual a atualização será implementada. 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 é a opção de 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 a atualização do contrato inteligente, a única opção para o nó de agregação é bifurcar para o novo contrato inteligente - deixando os fundos do usuário retidos no contrato antigo.
status atual
Infelizmente, o estado atual do Rollup está longe da implementação completa que discutimos acima. A maioria dos rollups ainda está na fase de "rodinhas", tentando acertar.
De acordo com a L2BEAT, Fuel v1 e DeGate são os dois únicos agregados que amadureceram para atingir todas as condições de atividade e segurança.
3. Economia
Vejamos a economia do Rollup da perspectiva dos usuários e operadores do Rollup:
1) Experiência do usuário - Os usuários devem obter preços baratos e não ter que esperar muito pelas transações
2) Lucro Rollup - Deve ser lucrativo para classificadores e detentores de Token operar o Rollup
A experiência do usuário é otimizada quando os usuários obtêm transações rápidas e baratas.
A velocidade na qual as transações são finalizadas depende da velocidade na qual os blocos da camada base são finalizados. 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 ordenador 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, envolve a dependência de um partido central que pode agir contra ela.
Enquanto algumas soluções de protocolo alternativo de sequenciador (por exemplo, baseadas em Rollups) renunciam a essa propriedade em detrimento dos usuários, outras soluções (por exemplo, consenso POS externo (por exemplo, Espresso)) podem fornecer garantias de pré-confirmação semelhantes sem incorrer no seguinte Risco: Sequenciadores centralizados.
E o custo para o usuário?
O preço explícito de uma transação Rollup é geralmente:
Custo de gás L2 = Custo de gás L1 + Taxa do sequenciador
Uma central de pedidos agindo racionalmente sempre quer maximizar seus próprios lucros, mesmo que isso signifique repassar custos mais altos aos 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 desalinhamento em que o agregado pode não querer entregar o lucro a um classificador externo.
Lucro Rollup - Além das taxas do sequenciador, o Rollup também pode obter lucro extraindo MEV de transações de usuários em massa. Esse MEV geralmente é difícil de atribuir porque é difícil descobrir se o solicitante incluiu algumas de suas próprias transações de execução inicial no lote.
**Se o Rollup for substituído por consenso POS externo, eles darão este MEV para operadores externos. **
Vale ressaltar que esses dois problemas de Rollups que entregam receita a mecanismos externos podem ser resolvidos por meio de “acordos comerciais” entre Rollups e mecanismos externos, nos quais as taxas e o MEV gerados por transações internas e cross-Rollup podem ser resolvidos. Redireciona de volta para o resumo.
No entanto, conforme explicado na palestra de Jon Charbonneau durante o Modular Summit e nas postagens subsequentes, uma ideia melhor seria ter um rollup de pedidos de delegação de governança para um conjunto de nós autorizados. 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 de dois pássaros e uma pedra, pois permite que os rollups mantenham as margens internamente, ao mesmo tempo em que mitiga os efeitos adversos dos classificadores centralizados. **
Mas o oposto disso é que, com rotação limitada de classificadores, os classificadores podem ter um comportamento não míope, o que pode levar a um monopólio de preços/extorsão de preços às custas dos usuários de agregação.
De qualquer forma, está claro que algum protocolo de substituição do sequenciador é necessário para que a sumarização seja econômica para os usuários. Se é uma prova de governança, um mecanismo de consenso externo ou qualquer outra coisa, é uma discussão para outro artigo.
4. Conclusão
Espero que agora esteja claro que qualquer que seja o caminho que o Rollup tome, é crucial que o objetivo seja uma implementação completa com mecanismos maduros para substituição do classificador, inclusão forçada e atualizações de governança de atraso. Mesmo que seja apenas inclusão obrigatória e atualizações atrasadas, os fundos do usuário estão seguros quando o Rollup é totalmente implementado, independentemente de o coordenador ser centralizado.
No entanto, um protocolo de substituição de sequenciador robusto pode melhorar as garantias de vivacidade e potencialmente melhorar a economia dos usuários do Rollup.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Veja a importância da descentralização do Rollup sob três aspectos
Autor: Shivanshu Madan; Compilador: Huohuo/Vernacular Blockchain
Muito da discussão no Twitter ultimamente gira em torno da descentralização L2. Os Rollups que estamos construindo são descentralizados o suficiente? Ou pelo menos estão no caminho da descentralização? Isso importa?
A ideia do Rollup é simples: queremos que os participantes fora da cadeia possam realizar transações que possam ser facilmente verificadas na cadeia. Com o Rollup, a camada base permite que sua base de "confiança" seja utilizada para atividades que ocorram fora de sua esfera imediata. Em troca, o Rollup paga uma pequena taxa (aluguel) para alavancar essa confiança.
Então, precisamos de Rollups descentralizados?
A resposta intuitiva é sim! Este é o espírito com o qual construímos o blockchain.
No entanto, acredito que a resposta a esta pergunta não seja um simples sim ou não. Em vez disso, tem múltiplas facetas que devem ser analisadas individualmente. Nos capítulos seguintes, analisarei essa questão sob três perspectivas: filosófica, tecnológica e econômica. ****Estes três não são necessariamente exaustivos ou exclusivos, mas devem dar uma boa perspectiva geral do problema. **
1. 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 - em breve pode ser a moeda que a maioria das pessoas no mundo usa para pagamentos globais! Esse é o poder da inovação sem permissão!
A base descentralizada de redes sem confiança como Bitcoin e Ethereum nos permite construir esse futuro. Então é óbvio que qualquer cadeia que tenha uma relação de confiança com essas cadeias, como Rollups, 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 construir o que quiserem, incluindo (mas não limitado a) cadeias totalmente autorizadas - e os usuários desse rollup ainda devem ser capazes de alavancar a segurança no camada de base. Mesmo as cadeias permissionadas devem ser seguras de usar, desde que a camada base seja descentralizada e o rollup seja "totalmente" implementado (falaremos mais sobre "totalmente implementado" na seção técnica).
Mas a realidade é que a maioria dos rollups hoje ainda não atingiu o estágio de implementação completa e não fornece aos usuários o nível desejado de segurança e falta de confiança.
Então, como é a implementação correta do rollup? vamos ver:
2. Tecnologia
Para entender verdadeiramente a questão da descentralização e segurança no nível do Rollup, precisamos analisá-la desde os primeiros princípios. Poucas pessoas podem explicar os primeiros princípios da blockchain melhor do que Sreeram Kannan.
Um blockchain é um livro-razão distribuído onde diferentes nós da rede seguem um protocolo definido para obter 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 da rede em seu próprio registro.
Por exemplo, no protocolo Gasper da Ethereum, existem duas regras de confirmação diferentes - a regra disponível (baseada na cadeia mais pesada) e a regra final (baseada nos blocos confirmados pelo gadget).
Especialmente em rollups, os nós completos têm regras de confirmação diferentes dos clientes leves. No tradicional smart contract rollup (SCR), o contrato inteligente (ponte de verificação) tem 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, nas zonas de consenso, todos os participantes têm a mesma visão da rede (e têm o mesmo histórico em seus registros).
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 juntas definem a condição "ativa" do sistema, enquanto as 3 últimas propriedades definem a condição "segura".
Vamos olhar para cada um da perspectiva de diferentes atores de agregação 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ê pode usar esses dados para realizar transações por conta própria 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, propriedades de atividade e resistência à recombinação. Para o último, os nós completos dependem dos validadores da cadeia subjacente e do protocolo de consenso que eles usam, enquanto para as propriedades de vivacidade, os nós completos dependem do sequenciador e das implementações de Rollup.
Cliente leve:
A maioria dos usuários usa carteiras incorporadas em light nodes ou serviços de terceiros para obter dados de blockchain e interagir com o blockchain. Os nós de luz podem ser de vários tipos:
Se você executar um light client full-validator, poderá verificar se os dados estão disponíveis por meio de amostragem de disponibilidade de dados, poderá verificar a validade das transições de estado por meio de provas de validade ou provas de fraude, também poderá verificar se o estado foi finalizado na base Consenso da camada (no Ethereum, isso pode ser feito seguindo um comitê de sincronização).
A condição de segurança restante é então a propriedade de vivacidade, e os clientes leves contam com as implementações do sequenciador e 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 do SCR dependem de contratos inteligentes para impor propriedades de vivacidade. Eles "absorvem" a resistência à reestruturaçã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 a prova 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 ao Sovereign Rollup? **
Sovereign Rollups não têm contratos inteligentes (pontes de verificação) para impor condições de validade ou vivacidade. Em vez disso, eles provarão "rolar para baixo" para um nó de rollup downstream. Esses nós ainda absorvem resistência DA e Reorg da camada de base.
Assim como no SCR, no rollup soberano, 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 da agregação deve incluir dois componentes importantes:
mecanismos obrigatórios de inclusão, e
Protocolo de substituição do sequenciador
A inclusão obrigatória ajuda a criar 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 então forçar a saída de volta para a camada base com seus fundos. Portanto, mesmo que haja apenas um nó de agrupamento centralizado para agregação, ele não poderá censurar os usuários, desde que haja um mecanismo de imposição maduro em vigor.
Mas isso é suficiente?
Mesmo que os usuários possam fazer logout, isso pode significar que, se a maioria dos usuários voltar para o L1, a empresa não terá muito incentivo para continuar executando. 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 esse mecanismo não é exatamente prática (ou em tempo real). Podemos chamar essa situação de "censura fraca".
Depois temos o atributo de vivacidade final - crescimento do livro-razão
Se o agrupador centralizado se tornar malicioso, ele pode interromper o crescimento da cadeia de resumo simplesmente interrompendo a produção de blocos. Se isso acontecer, não há nada que o usuário ou empresa possa fazer para tornar o rollup "ativo" novamente.
Para resolver este problema, precisamos de um protocolo de substituição do sequenciador.
A ideia do protocolo de substituição do sequenciador é que, se o sequenciador se comportar de maneira maliciosa, a governança agregada pode iniciar o sequenciador. Uma das maneiras de conseguir isso é substituir os nós do sequenciador centralizado por um protocolo de sequenciador descentralizado. Se o classificador for descentralizado e não monopolizar os blocos de construção do rollup, é quase impossível interromper o rollup.
Assim, enquanto os fundos do usuário estão 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 exatamente. Do ponto de vista técnico, há mais um aspecto a considerar:
E se os próprios contratos inteligentes pudessem ser atualizados por um comitê central agregado? Digamos que os rollups estejam implementados 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 de rollup, você não concordar com tal atualização, poderá sair da rollup antes que a atualização seja implementada (embora, novamente, essa não seja uma boa experiência do usuário e possa ser ruim para os negócios). Isso pode ser alcançado por meio de "atualizações de governança defasadas". É como um "período de notificação" após o qual a atualização será implementada. 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 é a opção de 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 a atualização do contrato inteligente, a única opção para o nó de agregação é bifurcar para o novo contrato inteligente - deixando os fundos do usuário retidos no contrato antigo.
status atual
Infelizmente, o estado atual do Rollup está longe da implementação completa que discutimos acima. A maioria dos rollups ainda está na fase de "rodinhas", tentando acertar.
De acordo com a L2BEAT, Fuel v1 e DeGate são os dois únicos agregados que amadureceram para atingir todas as condições de atividade e segurança.
3. Economia
Vejamos a economia do Rollup da perspectiva dos usuários e operadores do Rollup:
1) Experiência do usuário - Os usuários devem obter preços baratos e não ter que esperar muito pelas transações
2) Lucro Rollup - Deve ser lucrativo para classificadores e detentores de Token operar o Rollup
A experiência do usuário é otimizada quando os usuários obtêm transações rápidas e baratas.
A velocidade na qual as transações são finalizadas depende da velocidade na qual os blocos da camada base são finalizados. 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 ordenador 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, envolve a dependência de um partido central que pode agir contra ela.
Enquanto algumas soluções de protocolo alternativo de sequenciador (por exemplo, baseadas em Rollups) renunciam a essa propriedade em detrimento dos usuários, outras soluções (por exemplo, consenso POS externo (por exemplo, Espresso)) podem fornecer garantias de pré-confirmação semelhantes sem incorrer no seguinte Risco: Sequenciadores centralizados.
E o custo para o usuário?
O preço explícito de uma transação Rollup é geralmente:
Custo de gás L2 = Custo de gás L1 + Taxa do sequenciador
Uma central de pedidos agindo racionalmente sempre quer maximizar seus próprios lucros, mesmo que isso signifique repassar custos mais altos aos 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 desalinhamento em que o agregado pode não querer entregar o lucro a um classificador externo.
Lucro Rollup - Além das taxas do sequenciador, o Rollup também pode obter lucro extraindo MEV de transações de usuários em massa. Esse MEV geralmente é difícil de atribuir porque é difícil descobrir se o solicitante incluiu algumas de suas próprias transações de execução inicial no lote.
**Se o Rollup for substituído por consenso POS externo, eles darão este MEV para operadores externos. **
Vale ressaltar que esses dois problemas de Rollups que entregam receita a mecanismos externos podem ser resolvidos por meio de “acordos comerciais” entre Rollups e mecanismos externos, nos quais as taxas e o MEV gerados por transações internas e cross-Rollup podem ser resolvidos. Redireciona de volta para o resumo.
No entanto, conforme explicado na palestra de Jon Charbonneau durante o Modular Summit e nas postagens subsequentes, uma ideia melhor seria ter um rollup de pedidos de delegação de governança para um conjunto de nós autorizados. 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 de dois pássaros e uma pedra, pois permite que os rollups mantenham as margens internamente, ao mesmo tempo em que mitiga os efeitos adversos dos classificadores centralizados. **
Mas o oposto disso é que, com rotação limitada de classificadores, os classificadores podem ter um comportamento não míope, o que pode levar a um monopólio de preços/extorsão de preços às custas dos usuários de agregação.
De qualquer forma, está claro que algum protocolo de substituição do sequenciador é necessário para que a sumarização seja econômica para os usuários. Se é uma prova de governança, um mecanismo de consenso externo ou qualquer outra coisa, é uma discussão para outro artigo.
4. Conclusão
Espero que agora esteja claro que qualquer que seja o caminho que o Rollup tome, é crucial que o objetivo seja uma implementação completa com mecanismos maduros para substituição do classificador, inclusão forçada e atualizações de governança de atraso. Mesmo que seja apenas inclusão obrigatória e atualizações atrasadas, os fundos do usuário estão seguros quando o Rollup é totalmente implementado, independentemente de o coordenador ser centralizado.
No entanto, um protocolo de substituição de sequenciador robusto pode melhorar as garantias de vivacidade e potencialmente melhorar a economia dos usuários do Rollup.