Quando examinamos a visão e o roteiro de várias soluções de rollup, descobrimos que quase todos os rollups têm um objetivo final. Se esse objetivo for condensado em uma frase: construir uma pilha de tecnologia, fornecê-la à comunidade, resolver a expansão do blockchain e, finalmente, a descentralização da pilha de tecnologia de operações e governança. Isso leva ao termo rollup descentralizado.
Então, o que exatamente é a descentralização? Qual é a divisão de trabalho entre as várias partes do sistema Rollup? A descentralização significa maximizar os participantes da operação do sistema? Que impacto terá um classificador centralizado? Como o ordenador compartilhado e o consenso local L2 devem ser projetados? Qual é a função do provador único no ZK-Rollup? Como seria uma rede de provedores descentralizada aberta? Por que precisamos da aceleração de hardware zk? Qual é a solução para o problema de disponibilidade de dados? ....
Há discussões intermináveis sobre o Rollup descentralizado na comunidade, então a ECN organizou uma série de entrevistas em podcast com o tema "Rollup descentralizado" e convidou fundadores e pesquisadores destacados neste campo para falar sobre sua compreensão do Rollup descentralizado.
À medida que mais e mais liquidez flui para a plataforma da Camada 2, mais e mais provedores de serviços de rollup aparecem, não apenas soluções de rollup de uso geral, cadeias de rollup de aplicativos específicos, mas também plataformas de rollup como serviço. Portanto, mais e mais pessoas estão preocupadas com o fato de que um "sequenciador" de papel muito crítico em quase todos os rollups ainda esteja centralizado. Quais são os riscos de um classificador centralizado? Um classificador descentralizado é um trabalho urgente?
**No segundo episódio, convidamos Yaoqi Jia, fundador da AltLayer Network, Toghrul Maharramov, pesquisador do Scroll, e Abdelhamid Bakhta, Starknet Exploration Lead, para conduzir uma mesa redonda sobre o tema dos classificadores descentralizados, para que o público e os leitores pode entender o atual Alguns progressos e dilemas de classificadores descentralizados. **
Convidados nesta edição:
Yaoqi Jia, fundador da AltLayer Network, twitter @jiayaoqi
Pesquisador de rolagem Toghrul Maharramov, twitter @toghrulmaharram
Líder de Exploração Starknet Abdelhamid Bakhta, twitter @dimahledba
Passado
Questão 1: Como descentralizar o Rollup?
Pesquisador da Arbitrum Patrick McCorry
Visualização
Problema 3: rede do provedor e aceleração de hardware zk
Ye Zhang, cofundador da Scroll
*Leo Fan, co-fundador da Cysic
Problema 4: Disponibilidade de Dados e Armazenamento Descentralizado
Qi Zhou, fundador da EthStorage
Ouvir
Clique para assinar o podcast e saber mais:
YouTube:
Microcosmo:
carimbo de hora
00:49 Yaoqi se apresenta
01:37 Abdelhamid se apresenta
02:50 Toghrul se apresenta
04:03 O papel do classificador no rollup
08:37 Solicitador descentralizado: melhorando a experiência do usuário e abordando problemas de vivacidade e censura
19:43 Como a Starknet irá descentralizar o classificador
22:59 Como o Scroll descentralizará o classificador
26:34 A diferença entre consenso L2 no contexto de rollup otimista e zkRollup
32:28 zkRollup descentraliza o classificador e também precisa considerar o provador
36:01 O que é rollup baseado?
40:53 Desvantagens do sequenciador compartilhado e rollup baseado, e seus cenários de aplicação
49:02 Qual o impacto que um pedido descentralizado terá no MEV?
Apresentação do convidado
Yaoqi
Sou o fundador da AltLayer. A AltLayer está construindo uma plataforma "Rollup as a Service", na qual os desenvolvedores simplesmente clicam em alguns botões e configuram os parâmetros. Usando nossa barra de ativação ou painel de controle, eles podem iniciar rapidamente rollups específicos de aplicativos em minutos. Então é isso que estamos tentando fazer agora, fornecer aos desenvolvedores um ambiente de execução e funcionalidade comuns. Também fornecemos vários sequenciadores, vários sistemas de máquinas virtuais e vários sistemas de prova para os desenvolvedores escolherem.
Abdelhamid
Trabalho na Starkware e sou o líder da equipe de exploração. O objetivo deste grupo é basicamente lançar projetos de código aberto que sejam de pesquisa, mas com foco em engenharia. Nosso objetivo é trabalhar em projetos de código aberto em estreita colaboração com a comunidade e com pessoas de outros ecossistemas. Um desses projetos é Madara, que na verdade é um classificador Starknet. Não é apenas um candidato para a rede pública Starknet, mas também um sequenciador para a cadeia de aplicativos Starknet e Layer3. Isso também está relacionado ao que o convidado anterior disse, também estamos pensando em fornecer rollup como uma função de serviço, as pessoas podem lançar sua cadeia de aplicativos Starknet e escolher diferentes soluções de disponibilidade de dados de uma forma um tanto modular. Antes disso, trabalhei como desenvolvedor do núcleo Ethereum por quatro anos, sendo o principal responsável pelo trabalho do EIP-1559.
Escolha
Sou pesquisador da Scroll e minhas principais responsabilidades na Scroll são design de protocolo, design de ponte, descentralização, incentivos, esse tipo de coisa. Então, quando não estou twittando, na maioria das vezes estou apenas trabalhando em como descentralizar o protocolo ou ordenadores, provadores, coisas assim. Como o Starkware, uma das coisas em que estamos trabalhando é um SDK de rollup. Assim, você pode emitir um rollup com base no Scroll e usar modularmente diferentes opções de disponibilidade de dados e assim por diante. Ainda estamos considerando uma opção de que rollups baseados no Scroll SDK possam usar o classificador do Scroll para ajudá-los a obter a descentralização sem exigir que cada rollup lide com a descentralização por si só. Claro, o plano ainda não foi finalizado. No entanto, esta também é a direção em que estamos trabalhando.
Seção de entrevista
tópico um
Explique o classificador de rollup?
Abdelhamid
O classificador é um componente muito importante na arquitetura da camada 2, esse componente recebe as transações dos usuários, depois as empacota e agrupa em blocos, executa as transações e assim por diante. É muito crítico porque este é o componente responsável por criar os blocos, já que o layer2 também é um blockchain com blocos de transação. Os ordenadores criam esses blocos e os provadores atestam esses blocos.
Yaoqi
Como Abdel mencionou, o ordenador é uma combinação de muitas funções no blockchain. Portanto, podemos estar dando ao comprador muita responsabilidade agora em comparação com um blockchain público típico. Ele primeiro precisa agregar todas as transações dos usuários e, em seguida, classificar essas transações com base no preço do gás ou por ordem de chegada. Depois, o sequenciador precisa executar essas transações. Como agora, alguns Layer2s usam EVM (Starware tem uma máquina virtual diferente), mas basicamente o sequenciador precisa usar uma máquina virtual dedicada para executar transações e gerar estado. Então a transação atinge um estágio de pré-confirmação, o que significa que se você vir um tempo de confirmação de um ou dois segundos, ou mesmo subsegundos, é basicamente um estado de pré-confirmação concluído pelo sequenciador. Então, para a maioria dos classificadores, eles também precisam carregar ou publicar pontos de verificação ou hashes de estado para L1. Esta é a confirmação no nível L1, que chamamos de disponibilidade de dados. Portanto, o classificador na verdade tem muitas funções no sistema de rollup. Mas, em geral, acho que é o componente mais crítico do sistema de rollup.
** Tópico 2 **
Por que um classificador descentralizado é importante? Se usarmos um classificador centralizado, quais são os perigos ocultos para os usuários e o sistema?
Escolha
Antes de tudo, precisamos saber que, exceto o Fuel V1 no estágio atual, não há rollup real, porque outros rollups ainda possuem rodinhas.
No entanto, podemos dizer que, uma vez classificado como rollup, significa que o multi-sig foi removido e assim por diante. Então, o problema da descentralização do classificador se torna um problema de experiência do usuário, não um problema de segurança. Então, quando as pessoas falam sobre, digamos, descentralizar o L1, o problema é completamente diferente. Porque L1 tem que dar garantias para pedidos e clientes leves. Portanto, se um light client deseja verificar se o estado está correto, ele deve confiar nos validadores L1. Para rollup, este não é o caso. Porque o classificador fornece apenas classificação temporária, que é finalizada por L1. E, como os rollups também são resistentes à censura, não precisamos de descentralização para que isso aconteça.
Portanto, existem várias razões pelas quais você precisa de um classificador descentralizado. Primeiro, se a finalização de L1 for lenta (seja porque suas provas de validade enviadas são muito lentas ou devido ao mecanismo de período de desafio de provas de fraude cumulativas otimistas), você deve confiar em algo para obter uma confirmação rápida da transação. Nesta fase de confirmação rápida, embora você possa confiar que Starkware ou Scroll não vão te enganar, eles indicam que após a confirmação de um bloqueio, não haverá reorganização. Isso é uma suposição de confiança. E a descentralização pode acrescentar algumas garantias econômicas e assim por diante.
Mas com base nisso, o rollup também não tem garantia de finalização em tempo real. Essencialmente, você pode forçar o empacotamento de transações por meio de L1, mas leva horas para empacotar essa transação. Então, por exemplo, se houver um oráculo responsável pela atualização e o tempo oscilar, basicamente se o oráculo for atualizado por uma hora ou mais, os aplicativos do rollup não estarão disponíveis. Essencialmente, a descentralização nos permite fornecer algumas garantias resistentes à censura em tempo real mais fortes, porque então um adversário precisaria comprometer não apenas uma entidade ou um punhado de entidades, mas toda a rede de pedidos.
Portanto, para nós, a descentralização é mais uma solução para melhorar a experiência do usuário ou corrigir o caso de atualizações do oracle e assim por diante. Em vez de fornecer garantias básicas de segurança, é isso que o L1 faz.
Abdelhamid
Sim, a questão do sorter descentralizado que você mencionou não é exatamente a mesma do L1 descentralizado, que eu acho muito importante. Porque quando vemos alguns L1s criticando os classificadores centralizados, eles não analisam adequadamente as compensações que os classificadores centralizados fazem.
Com base nisso, gostaria de acrescentar algo relacionado à experiência do usuário, relacionado à atividade. Porque quando você tem apenas um único classificador, você corre um risco maior de travamento do classificador. Portanto, um ordenador descentralizado também aumenta a resiliência e vivacidade na rede. Mas mesmo em um contexto centralizado, temos uma boa segurança quando se trata de segurança. Porque quando você pode forçar transações de pacotes por meio de L1, a diferença entre os dois é apenas a linha do tempo. E ter um classificador descentralizado permite que você tenha garantias rápidas de resistência à censura, como Toghrul mencionou. Então, só quero acrescentar que também é importante para a vivacidade ter uma rede descentralizada de pedidos.
Yaoqi
Eu gostaria de acrescentar algo. A atividade é provavelmente a coisa mais importante que precisamos considerar nesta fase. Os casos mais recentes de airdrops nos L2s mais populares, como Optimism e Arbitrum, tiveram um período de inatividade. Portanto, acho que o que precisamos resolver é como lidar com milhares de solicitações de transações por segundo quando temos apenas um classificador. Mesmo em teoria, se você tiver apenas um nó, ele não poderá lidar com tantas solicitações ao mesmo tempo. Portanto, em relação à vivacidade, definitivamente precisamos de vários classificadores. Ponto único de falha é um obstáculo real, não apenas para Web3, até Web2 é um grande problema.
Além disso, há a questão da censura. Se tivermos apenas um coordenador, mesmo que vejamos que ele pode ser executado pela equipe, você ainda precisará provar que a equipe não revisará as transações. Às vezes, é possível e capaz que partes mal-intencionadas coloquem certas transações na lista negra. Esse é um sistema de pedidos descentralizado, eles também podem tentar enviar transações por meio de outros pedidos. É por isso que temos recebido muitas críticas sobre classificadores únicos ultimamente.
Além disso, existem alguns outros problemas, como MEV e execuções iniciais. Em um sistema com classificadores centralizados, especialmente para protocolos DeFi, eles podem verificar o mempool facilmente. Provavelmente não na forma de um favorito, mas eles têm uma chance melhor de seguir o comércio e arbitrar.
Muitos desses problemas, por vários motivos, mesmo vendo que L2 é muito diferente de L1. Mas, em última análise, ainda precisamos torná-lo o mais descentralizado possível. Portanto, temos que enfrentar alguns dos problemas semelhantes que temos com blockchains públicos ou L1.
Abdelhamid
Sim, concordo que um classificador descentralizado é importante. Mas também quero dizer que, como todos sabemos, essa não é uma pergunta fácil.
Além disso, **uma vez que os rollups têm uma arquitetura muito específica, com várias entidades. Estamos falando de um único ordenador, mas também de um provador, e precisamos descentralizar ambos. **Haverá algumas compensações e alguma dificuldade em como precificar as transações porque diferentes fatores são necessários para operar a rede. Então, como você precifica o negócio? O classificador e o provador têm requisitos de hardware diferentes, o provador precisa de uma máquina superpotente e assim por diante. Portanto, precificar transações em um mundo descentralizado também é um problema muito difícil, e é por isso que precisamos de tempo para avançar lentamente.
Portanto, todos nós enfrentaremos tal trade-off.Se quisermos descentralizar rapidamente, podemos precisar pegar algumas rodinhas e descentralizar gradualmente, porque se quisermos diretamente uma arquitetura perfeita, isso levará vários anos. Então, acho que vamos adotar uma abordagem pragmática e tentar descentralizar gradualmente. Pelo menos esse é o nosso plano atual, como talvez começar com um mecanismo de consenso BFT simples e depois adicionar outro mecanismo de consenso no curto prazo ou algo assim. Então, eu só quero dizer que não é uma pergunta fácil. Porque obviamente há uma compensação entre a velocidade de desenvolvimento e a aplicabilidade da arquitetura a um ambiente descentralizado.
Tópico 3
Como descentralizar o classificador?
Abdelhamid
Há muitos recursos que queremos descentralizar e todos eles têm compensações diferentes.
Por exemplo, ao descentralizar, você deseja introduzir algum tipo de mecanismo de consenso. No mecanismo de consenso, no entanto, existem várias partes. A primeira é a eleição do líder, ou seja, como escolher quem vai criar os blocos, quem será o ordenador responsável por criar os blocos em um determinado slot ou em um determinado tempo. **O que a equipe Starknet planeja fazer é utilizar a camada 1 o máximo possível. Ou seja, em nosso algoritmo de eleição de líder, queremos apostar na camada1. Por exemplo, temos tokens e a promessa ocorrerá no contrato inteligente da camada1 Ethereum, que é usado para determinar o mecanismo de eleição do líder. ** Isso significa que precisamos ter alguma interação em que o solicitador L2 consultará o contrato inteligente Ethereum para saber quem será o próximo líder ou algo assim. Então, obviamente, algum tipo de aleatoriedade e outras coisas são necessárias. Portanto, não é uma pergunta simples. Mas essa é a primeira parte. Então você precisa ter um mecanismo para o próprio consenso. Existem várias opções: o mecanismo de cadeia mais longa ou BFT, ou um híbrido dos dois. Como Ethereum, tem LMG Ghost e Casper FFG para finalidade.
Portanto, podemos adotar uma abordagem pragmática e começar primeiro com o BFT. por que? Quando a camada 2 considera a descentralização, nosso objetivo não é ter uma escala de classificador tão grande quanto a camada 1. Por exemplo, no Ethereum, o objetivo é ter a participação de milhões de validadores. Nesse caso, você não pode simplesmente usar o mecanismo BFT, porque será muito ruim em eficiência e causará problemas muito grandes. Por exemplo, se houver algum problema na rede Bitcoin, se for um mecanismo BFT, a cadeia irá parar completamente. Mas este não é o caso, a rede Bitcoin continua a criar blocos, apenas o mecanismo de finalidade é atacado.
Mas na camada 2, se o destino for de algumas centenas a 1.000 classificadores, pode ser bom começar com um mecanismo BFT. Então, temos o mecanismo de eleição do líder, depois o consenso, e aí tem mais duas partes, mas vou deixar para os outros convidados continuarem acrescentando. Mas as outras duas partes são atualizações de estado e geração de provas.
Escolha
Primeiro, em L2, a descentralização é um problema multifacetado, conforme descrito por Abdel. Principalmente no zkRollup, porque tem provadores e ordenadores, você tem que coordenar entre eles, tem que descentralizar os dois. Este problema é completamente diferente de L1.
Outra diferença é que em L2, todo o seu projeto é convencer a ponte subjacente de que o consenso está correto, não convencer qualquer número de outros nós. Obviamente, você deve fazer o mesmo, mas seu foco principal deve ser a própria ponte.
Atualmente, estamos trabalhando em duas direções diferentes. Número um, acho que, como todo mundo, estamos trabalhando em um protocolo BFT. Isso não é muito eficiente e há alguns problemas que precisam ser resolvidos. Chegamos a uma solução aproximada, mas ainda não é a ideal. Por exemplo, uma das perguntas é: como você equilibra incentivos entre classificadores e provadores? Como o solicitante controla o MEV e o provador não tem acesso ao MEV, há um incentivo para que as pessoas executem o solicitante em vez do provador. Mas, na realidade, precisamos de mais provadores do que encomendadores, então como você equilibra os incentivos entre os dois? Este é um desses problemas.
A segunda solução em que estamos trabalhando é outra direção. Lembre-se, as coisas podem mudar. Novas propostas surgem todos os dias. Por exemplo, tem havido muita conversa ultimamente sobre rollup baseado e como você pode terceirizar completamente a classificação para L1. A segunda direção é basicamente abandonar totalmente o classificador e usar algum construtor externo. Por exemplo, os construtores ethereum ou Flashbots SUAVE etc. propõem blocos ordenados e, em seguida, executam o consenso dentro do provador. A vantagem aqui é que você não precisa lidar com incentivos porque basicamente você pode usar o PBS dentro do protocolo e ele cria um protocolo mais simples. Mas a desvantagem é que, como precisamos de um grande número de provadores (porque podemos provar em paralelo), é muito difícil executar um protocolo BFT clássico com eles. Portanto, a questão é como você otimiza um protocolo BFT existente para executar com centenas, ou mesmo milhares, de provadores? E essa não é uma pergunta fácil de responder.
A introdução do consenso L2 é necessária para um ordenador descentralizado?
Yaoqi
Posso responder aproximadamente a essa pergunta porque recentemente lançamos algo assim.
Portanto, introduzir ou não o consenso não depende de querermos ou não. Uma vez que você tenha muitos pedidos ou mesmo apenas nós, você deve fazer com que eles concordem. Isso realmente depende de suas suposições. Se for uma suposição bizantina, podemos usar o BFT ou qualquer protocolo de consenso bizantino existente. Se for uma configuração não bizantina, por exemplo, se assumirmos que um nó só pode estar online e offline e que não pode agir de forma maliciosa, podemos usar o protocolo Raft ou algum outro protocolo de consenso mais rápido. Mas de qualquer forma, se tivermos um grupo de ordenadores ou provadores, se quisermos organizá-los juntos para produzir blocos durante um período de tempo, então você deve ter um protocolo de consenso em torno deles.
Portanto, como Toghrul e Abdel acabaram de mencionar, acredito que há muitas propostas e tópicos de pesquisa sobre como podemos implementar um sistema descentralizado de pedidos ou provas. Portanto, como acabamos de lançar uma rede de teste para um sistema de rollup de vários classificadores (atualmente compatível apenas com provas de fraude para rollups otimistas), com base em nossa experiência de design e implementação, há algumas coisas que posso compartilhar sobre as dificuldades. Como Toghrul mencionou há pouco, a dificuldade não está no protocolo de consenso em si, mas em outras coisas além disso, como a parte da prova. Porque se for um único classificador, você não precisa de muitos nós. Podemos pensar nisso como um EVM, uma máquina virtual. Então, basta buscar transações e executar, fazer transições de estado. O provador é responsável por gerar provas para a transição de estado do conjunto anterior de transações. No entanto, se executarmos o protocolo de consenso para o agrupador e o provador no rollup, precisaremos introduzir uma lógica de consenso adicional lá. Além disso, você também precisa de um sistema de prova para o protocolo de consenso. Portanto, isso introduzirá muito trabalho para o sistema de prova gerar. Depois de gerar a prova, você pode verificá-la facilmente no L1 Ethereum.
É por isso que, de certa forma, quando lançamos a primeira rede de teste de vários pedidos, o rollup otimista teve algumas vantagens a esse respeito. Em geral, você pode simplificar muitas coisas, como não considerar a parte da prova de validade. Como nós, basicamente comparamos tudo com o WASM. Portanto, no final, é uma instrução WASM. Portanto, verificando essas instruções WASM, é relativamente fácil verificar usando o código Solidity. Se apenas reimplementássemos todas as interpretações de instruções WASM no Ethereum.
Mas, em geral, o problema não é singular. Se tivermos uma solução para o problema, correspondentemente, haverá algum outro trabalho de acompanhamento que precisa ser resolvido ao mesmo tempo. Claro, haverá problemas de MEV, como distribuímos o MEV de forma justa. Você pode atribuir todos os ordenadores e provadores com base em se eles produziram um bloco ou validaram um bloco. Mas, no final, é realmente uma combinação de muitas questões, não apenas técnicas, mas também de incentivos econômicos.
E precisamos lembrar que o L2 é proposto porque queremos reduzir significativamente o custo do gás. Portanto, não podemos ter tantos nós. Mesmo na geração de provas, L2 pode ser mais caro que L1. Portanto, realmente precisamos encontrar uma abordagem equilibrada para esse tipo de problema.
Abdelhamid
Gostaria de acrescentar mais um ponto. Primeiro, atualmente não há nenhuma prova real de fraude sem permissão para rollups otimistas. E continuo enfatizando isso sempre que posso, porque é importante ser honesto sobre isso ao comparar. Portanto, eles não são L2. Essa é a primeira coisa.
Então eu gostaria de acrescentar algo sobre a assincronia entre classificação e provas, porque é muito importante. Como você disse, queremos otimizar o sorting, porque atualmente isso é um gargalo para todas as soluções. Mas tudo bem no contexto de uma classificação centralizada, porque sabemos que o classificador produzirá apenas transições de valor e poderemos verificá-las. Mas será mais difícil no contexto de uma classificação descentralizada, porque talvez seu classificador seja capaz de produzir algo que não pode ser verificado. Então você precisará lidar com isso mais tarde.
No contexto da ordenação centralizada, para optimizar a ordenação, uma vez que não temos de gerar provas durante o processo de ordenação, podemos tentar fazê-lo à velocidade local, que é o que queremos fazer. Traduza Cairo para uma linguagem de máquina de baixo nível como LLVM e execute super rápido no classificador. Então você pode provar de forma assíncrona. E o mais legal das provas é que você pode fazê-las em paralelo. A paralelização massiva é alcançada provando que a recursão é possível. É por isso que seremos capazes de alcançar a velocidade do classificador. Mas é difícil quando descentralizado, porque precisamos garantir que o ordenador produza apenas transições de estado válidas.
Escolha
Acrescentarei que não tenho certeza do que Starknet está fazendo aqui. Mas para nós, acho que é uma suposição geral de cada zkRollup que, se você descentralizar o classificador, seu sistema de prova deve ser capaz de lidar com lotes inválidos. Então, basicamente, se, digamos, você enviar um lote com uma assinatura inválida, precisará provar que o estado resultante é equivalente ao estado inicial. Portanto, haverá alguma sobrecarga de qualquer maneira. É sobre como você minimiza a probabilidade de isso acontecer.
Abdelhamid
Sim está certo. É por isso que introduzimos o Sierra no Cairo 1 para tornar tudo verificável. Essa representação intermediária garantirá que todo programa Cairo 1 seja verificável para que possamos incluir uma transação de reversão.
O que é rollup baseado?
Yaoqi
O rollup baseado originalmente veio de uma postagem de blog de Justin Drake nos fóruns Ethereum. Uma de suas ideias é que podemos reutilizar alguns verificadores Ethereum para verificar transações de rollup, para que não precisemos de um grupo separado de nós para verificar diferentes transações de rollup. Em particular, teremos muitos rollups no futuro, incluindo rollups de uso geral e muitos rollups específicos de aplicativos. Portanto, neste caso, seria ótimo se pudéssemos encontrar um lugar comum como o pool de validadores Ethereum para validar essas transações.
Claro, isso é apenas uma ideia, pois também apresenta muitas dificuldades técnicas. Por exemplo, em teoria, poderíamos exigir que os validadores do Ethereum verificassem as transações de rollup, mas é muito difícil obter a lógica de verificação de rollups agrupados ou incorporados no próprio protocolo Ethereum. Chamamos isso de verificação no protocolo, que requer um hard fork de nós Ethereum. Claro, neste caso, podemos verificar algumas transações de rollup. Mas se o fizermos, você verá problemas. É um pouco como se quiséssemos que o rollup do L2 compartilhasse a pressão do Ethereum, mas no final ainda pedimos aos validadores do Ethereum que assumam parte do trabalho transferido para o L2. Muitas pessoas falam sobre como podemos fazer isso.
Então conversamos com Barnabe, um pesquisador da Fundação Ethereum que atualmente trabalha na PBS. Essa é uma proposta do Ethereum, que é dividir a tarefa dos validadores em múltiplos papéis, construtores e proponentes. Agora temos Flashbots para assumir o papel de construtores no PBS, eles compõem todos os blocos e os enviam aos proponentes do Ethereum. Assim que esses blocos forem empacotados na rede Ethereum, os construtores também receberão algumas recompensas. Então, neste caso, como recompensar esses validadores da rede Ethereum? Eles também são responsáveis pela validação de rollup.
Uma das soluções é "refazer", que você já deve ter ouvido falar muito do EigenLayer ou de alguns outros protocolos. Os usuários podem apostar novamente o ETH em outras redes de classificação. Ou recompense os validadores do Ethereum por realmente executar o software para fazer o trabalho de validação para o rollup. Nesse caso, eles podem ser recompensados tanto em L2 quanto por meio do protocolo de reestaqueamento. Houve muitas propostas para isso até agora, mas, em geral, é uma ideia de como reaproveitar os validadores Ethereum existentes. Como podemos reutilizar o ETH existente para ajudar a inaugurar uma nova era de rollup ou sistemas L2? Basicamente, está tentando simplificar muitas coisas para o projeto de rollup. Se um rollup quiser um novo classificador, se quiser uma nova fonte de garantia, pode reutilizar a infraestrutura existente ou a garantia existente. É por isso que é construído sobre o Ethereum e, em seguida, infraestrutura adicional e staking podem ser reutilizados para rollup e L2 também.
Desvantagens do sequenciador compartilhado e rollup baseado e seus cenários de aplicação.
Escolha
Quero reclamar dessa proposta, não estou convencido com a proposta relacionada ao sequenciador compartilhado. Claro, eles ainda estão na infância e, se esses designs melhorarem no futuro, é perfeitamente possível que eu os apoie. É que a forma atual não me convence. Existem muitas razões.
Em primeiro lugar, para mim, a principal proposta de valor de um classificador compartilhado é permitir que os usuários obtenham capacidade de composição atômica entre rollups de uso geral, como Scroll ou Starknet. Mas o problema é que, se você tiver capacidade de composição atômica, seu rollup será tão final quanto o rollup mais lento com o qual você combinar. Portanto, supondo que o Scroll seja combinado com o Optimistic Rollup, a finalidade do Scroll será de sete dias. Embora a principal proposta de valor do ZKRollup seja atingir uma finalização relativamente rápida, os usuários podem voltar para o L1 em minutos. E neste caso, basicamente desista disso.
Outra desvantagem é que, se você deseja finalidade fora da cadeia, precisa executar um nó L2 e, desde que os dados enviados à cadeia sejam finalizados por L1, você obtém a finalidade localmente em L2. Se cada L2 combinado não executar um nó completo, é praticamente impossível obter a finalização local. Isso significa que a execução desse sistema pode ser mais cara do que a execução de um sistema como o Solana, porque você tem vários nós completos em execução ao mesmo tempo, com sua própria sobrecarga e assim por diante.
Portanto, por esses motivos, não acho que faça sentido para L2. É um pouco diferente para o L3, porque se alguém quiser construir uma cadeia específica de aplicativos e não quiser lidar com a descentralização. Digamos que estou construindo um jogo e só quero lidar com a construção do jogo, então posso terceirizar o trabalho descentralizado. Mas não acho que faça sentido para L2 no momento.
Quanto ao rollup baseado, também tenho minhas preocupações. Por exemplo, como você compartilha os lucros do MEV com os provadores? Porque se o problema de alocação não for considerado, basicamente L1 pode obter todos os lucros do MEV. Outra coisinha é que o tempo de confirmação dele é igual ao tempo de confirmação do L1, que é de 12 minutos, o que não pode ser mais rápido. Outro problema é que, por não ter permissão, vários Seekers podem enviar lotes de transações ao mesmo tempo, o que significa que pode acabar com resultados centralizados. Porque os construtores são incentivados a incluir suas transações se um pesquisador se conectar com mais facilidade do que outros. Portanto, pode resultar em apenas um Seeker propondo lotes para L2 no final, o que não é uma solução muito boa, porque se isso acontecer, basicamente voltamos à estaca zero.
Yaoqi
Curiosamente, acabei de ligar para Ben, o fundador do Espresso, na semana passada. Discutimos muito isso no tópico de classificadores compartilhados. Como Toghrul mencionou, acho que há alguma incerteza sobre os cenários de uso de um sistema de pedidos compartilhados. Isso ocorre principalmente porque, para um L2 de uso geral, geralmente não temos um grande número de classificadores devido à eficiência, complexidade e economia. E ainda sinto que, seja para um sequenciador compartilhado, rollup baseado ou restauração, o melhor caso de uso é principalmente para RAS (Rollup as a Service) ou plataformas nas quais podemos lançar muitos rollups. Para ser honesto, não precisamos de uma grande rede de classificação se não houver muitos acúmulos. Esses rollups já possuem seus próprios sistemas de classificadores, e já possuem suas próprias comunidades ou parceiros, quando existem apenas alguns L2s genéricos. Eles realmente não precisam ter uma rede separada e de terceiros. Além disso, isso é um fardo para a rede de terceiros, porque você precisa personalizar para cada L2, e cada L2 tem uma pilha de teste diferente. Isso requer muitas mudanças em sua própria rede.
Mas, ao mesmo tempo, como Toghrul mencionou, para alguns casos de uso especiais. Por exemplo, se quisermos ter alguma interoperabilidade no nível do classificador, os classificadores compartilhados podem ser um caminho a seguir. Por exemplo, o mesmo classificador é usado para vários acúmulos. Nesse caso, esse classificador pode basicamente lidar com algumas transações de rollup cruzado para garantir a atomicidade da cadeia cruzada entre rollup A, B e C.
Mas você também pode ver o problema aqui quando descrevo a situação. Se realmente tivéssemos muitos desses sequenciadores compartilhados, eles se tornariam novamente um gargalo e um novo ponto único de falha. Estamos dando muito poder a esses chamados ordenadores compartilhados. Eles estão se tornando mais parecidos com uma rede, controlando muitos rollups. Por fim, novamente precisamos encontrar uma maneira de descentralizar esse classificador compartilhado.
De qualquer forma, acho bom que as pessoas estejam gradualmente descobrindo mais e mais problemas e apresentando cada vez mais soluções. Em suma, é emocionante ver o que há de novo neste campo todos os dias. Com todas essas novas soluções, pelo menos estamos no caminho certo para descentralizar verdadeiramente todo o espaço de rollup.
Abdel
Sim, concordo com vocês dois. Acho que faz mais sentido para Layer3 e Lisk porque eles não querem mais assumir a responsabilidade de incentivar uma rede descentralizada e precisam encontrar parceiros para iniciar coisas como classificadores. Então eu acho que para Lisk, faz sentido. Mas, como Toghrul, não acho que faça muito sentido para o Layer2 ainda.
Tópico 4
Que impacto um pedido descentralizado terá no MEV?
Abdel
Para a Starknet, no contexto da centralização, não fazemos nenhum tipo de MEV e adotamos um modelo de ordem de chegada. Ou seja, no contexto da descentralização, é claro, mais MEV serão trazidos posteriormente. Mas é muito cedo para dizer qual proporção, porque também depende do desenho do mecanismo de consenso e de outros aspectos.
Escolha
Mas o problema é que, mesmo que você não faça MEV, pode haver algum MEV ainda acontecendo no Starknet. Bem, a descentralização por si só realmente não diminui o MEV ou aumenta o MEV. Claro, se você aplicar algum tipo de protocolo de pedido justo ou criptografia de limite, por exemplo, sim, você minimizará o MEV. Mas você não pode eliminá-lo completamente. Minha filosofia é: MEV não pode ser eliminado. Mas digamos que você esteja apenas criando um consenso BFT ou construindo algo em cima de um consenso BFT. Na verdade, isso não afeta o MEV. O MEV ainda existe, deve ser uma questão de como o pesquisador trabalha com o classificador para extrair esse MEV.
Yaoqi
O problema é que mesmo o modelo de ordem de chegada tem partes complicadas. Uma vez que expomos o mempool para alguns buscadores, eles ainda têm a vantagem de jogar mais. Por exemplo, para os sequenciadores, eles equivalem a esperar na porta do seu escritório. Então, neste caso, uma vez que eles vejam algum tipo de oportunidade de arbitragem, não apenas um front-running ou um ataque sanduíche, assim que um usuário enviar uma transação, eles poderão vê-la imediatamente no mempool. Assim, eles podem rapidamente colocar seus negócios à frente dos outros. Então, eles têm uma vantagem sobre outros pesquisadores.
Mas voltando à descentralização, acho que é principalmente sobre resistência à censura, como discutimos no início. Os sequenciadores são gerenciados pela equipe. A equipe pode dizer que está sendo justa com todos. Mas isso não é impedido no código. Portanto, se pudéssemos ter uma rede P2P, seria ótimo se sentíssemos que esses nós verificam minha transação e então podemos enviá-la para outros nós. Portanto, trata-se realmente da justiça do processamento de transações em L2.
Quanto aos MEVs, porque recentemente, além dos MEVs gerados em um único rollup, existem alguns MEVs gerados através de pontes. Nesta rede de classificação relativamente descentralizada, você terá mais oportunidades de extrair MEV. Supondo que tenhamos uma rede de pedidos compartilhada, se você puder de alguma forma influenciar o pedido compartilhado para reordenar as transações, basicamente você terá uma grande vantagem sobre todos os outros.
Existem vantagens e desvantagens em uma rede de sequenciador compartilhado. No lado positivo, podemos descentralizar ainda mais o sistema de classificação. Mas, por outro lado, todos têm a oportunidade de ser classificadores. Então, eles podem basicamente fazer o que quiserem, e é uma floresta escura novamente. Então, introduzimos a descentralização e tivemos que enfrentar problemas semelhantes aos do Ethereum. É por isso que o Flashbots e o pessoal da Ethereum Foundation querem seguir em frente com o PBS, separar proponentes e construtores e, em seguida, tentar ter uma solução única do lado do construtor.
Então, quando olhamos para o problema, não é apenas um único problema. Não é mais um problema individual, mas um contra seis e muito mais.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Diálogo com as equipes AltLayer, Scroll, Starknet: Sequenciador Compartilhado e Consenso L2
Introdução
Quando examinamos a visão e o roteiro de várias soluções de rollup, descobrimos que quase todos os rollups têm um objetivo final. Se esse objetivo for condensado em uma frase: construir uma pilha de tecnologia, fornecê-la à comunidade, resolver a expansão do blockchain e, finalmente, a descentralização da pilha de tecnologia de operações e governança. Isso leva ao termo rollup descentralizado.
Então, o que exatamente é a descentralização? Qual é a divisão de trabalho entre as várias partes do sistema Rollup? A descentralização significa maximizar os participantes da operação do sistema? Que impacto terá um classificador centralizado? Como o ordenador compartilhado e o consenso local L2 devem ser projetados? Qual é a função do provador único no ZK-Rollup? Como seria uma rede de provedores descentralizada aberta? Por que precisamos da aceleração de hardware zk? Qual é a solução para o problema de disponibilidade de dados? ....
Há discussões intermináveis sobre o Rollup descentralizado na comunidade, então a ECN organizou uma série de entrevistas em podcast com o tema "Rollup descentralizado" e convidou fundadores e pesquisadores destacados neste campo para falar sobre sua compreensão do Rollup descentralizado.
À medida que mais e mais liquidez flui para a plataforma da Camada 2, mais e mais provedores de serviços de rollup aparecem, não apenas soluções de rollup de uso geral, cadeias de rollup de aplicativos específicos, mas também plataformas de rollup como serviço. Portanto, mais e mais pessoas estão preocupadas com o fato de que um "sequenciador" de papel muito crítico em quase todos os rollups ainda esteja centralizado. Quais são os riscos de um classificador centralizado? Um classificador descentralizado é um trabalho urgente?
**No segundo episódio, convidamos Yaoqi Jia, fundador da AltLayer Network, Toghrul Maharramov, pesquisador do Scroll, e Abdelhamid Bakhta, Starknet Exploration Lead, para conduzir uma mesa redonda sobre o tema dos classificadores descentralizados, para que o público e os leitores pode entender o atual Alguns progressos e dilemas de classificadores descentralizados. **
Convidados nesta edição:
Passado
Questão 1: Como descentralizar o Rollup?
Visualização
Problema 3: rede do provedor e aceleração de hardware zk
Problema 4: Disponibilidade de Dados e Armazenamento Descentralizado
Ouvir
Clique para assinar o podcast e saber mais:
YouTube:
Microcosmo:
carimbo de hora
00:49 Yaoqi se apresenta
01:37 Abdelhamid se apresenta
02:50 Toghrul se apresenta
04:03 O papel do classificador no rollup
08:37 Solicitador descentralizado: melhorando a experiência do usuário e abordando problemas de vivacidade e censura
19:43 Como a Starknet irá descentralizar o classificador
22:59 Como o Scroll descentralizará o classificador
26:34 A diferença entre consenso L2 no contexto de rollup otimista e zkRollup
32:28 zkRollup descentraliza o classificador e também precisa considerar o provador
36:01 O que é rollup baseado?
40:53 Desvantagens do sequenciador compartilhado e rollup baseado, e seus cenários de aplicação
49:02 Qual o impacto que um pedido descentralizado terá no MEV?
Apresentação do convidado
Yaoqi
Sou o fundador da AltLayer. A AltLayer está construindo uma plataforma "Rollup as a Service", na qual os desenvolvedores simplesmente clicam em alguns botões e configuram os parâmetros. Usando nossa barra de ativação ou painel de controle, eles podem iniciar rapidamente rollups específicos de aplicativos em minutos. Então é isso que estamos tentando fazer agora, fornecer aos desenvolvedores um ambiente de execução e funcionalidade comuns. Também fornecemos vários sequenciadores, vários sistemas de máquinas virtuais e vários sistemas de prova para os desenvolvedores escolherem.
Abdelhamid
Trabalho na Starkware e sou o líder da equipe de exploração. O objetivo deste grupo é basicamente lançar projetos de código aberto que sejam de pesquisa, mas com foco em engenharia. Nosso objetivo é trabalhar em projetos de código aberto em estreita colaboração com a comunidade e com pessoas de outros ecossistemas. Um desses projetos é Madara, que na verdade é um classificador Starknet. Não é apenas um candidato para a rede pública Starknet, mas também um sequenciador para a cadeia de aplicativos Starknet e Layer3. Isso também está relacionado ao que o convidado anterior disse, também estamos pensando em fornecer rollup como uma função de serviço, as pessoas podem lançar sua cadeia de aplicativos Starknet e escolher diferentes soluções de disponibilidade de dados de uma forma um tanto modular. Antes disso, trabalhei como desenvolvedor do núcleo Ethereum por quatro anos, sendo o principal responsável pelo trabalho do EIP-1559.
Escolha
Sou pesquisador da Scroll e minhas principais responsabilidades na Scroll são design de protocolo, design de ponte, descentralização, incentivos, esse tipo de coisa. Então, quando não estou twittando, na maioria das vezes estou apenas trabalhando em como descentralizar o protocolo ou ordenadores, provadores, coisas assim. Como o Starkware, uma das coisas em que estamos trabalhando é um SDK de rollup. Assim, você pode emitir um rollup com base no Scroll e usar modularmente diferentes opções de disponibilidade de dados e assim por diante. Ainda estamos considerando uma opção de que rollups baseados no Scroll SDK possam usar o classificador do Scroll para ajudá-los a obter a descentralização sem exigir que cada rollup lide com a descentralização por si só. Claro, o plano ainda não foi finalizado. No entanto, esta também é a direção em que estamos trabalhando.
Seção de entrevista
tópico um
Explique o classificador de rollup?
Abdelhamid
O classificador é um componente muito importante na arquitetura da camada 2, esse componente recebe as transações dos usuários, depois as empacota e agrupa em blocos, executa as transações e assim por diante. É muito crítico porque este é o componente responsável por criar os blocos, já que o layer2 também é um blockchain com blocos de transação. Os ordenadores criam esses blocos e os provadores atestam esses blocos.
Yaoqi
Como Abdel mencionou, o ordenador é uma combinação de muitas funções no blockchain. Portanto, podemos estar dando ao comprador muita responsabilidade agora em comparação com um blockchain público típico. Ele primeiro precisa agregar todas as transações dos usuários e, em seguida, classificar essas transações com base no preço do gás ou por ordem de chegada. Depois, o sequenciador precisa executar essas transações. Como agora, alguns Layer2s usam EVM (Starware tem uma máquina virtual diferente), mas basicamente o sequenciador precisa usar uma máquina virtual dedicada para executar transações e gerar estado. Então a transação atinge um estágio de pré-confirmação, o que significa que se você vir um tempo de confirmação de um ou dois segundos, ou mesmo subsegundos, é basicamente um estado de pré-confirmação concluído pelo sequenciador. Então, para a maioria dos classificadores, eles também precisam carregar ou publicar pontos de verificação ou hashes de estado para L1. Esta é a confirmação no nível L1, que chamamos de disponibilidade de dados. Portanto, o classificador na verdade tem muitas funções no sistema de rollup. Mas, em geral, acho que é o componente mais crítico do sistema de rollup.
** Tópico 2 **
Por que um classificador descentralizado é importante? Se usarmos um classificador centralizado, quais são os perigos ocultos para os usuários e o sistema?
Escolha
Antes de tudo, precisamos saber que, exceto o Fuel V1 no estágio atual, não há rollup real, porque outros rollups ainda possuem rodinhas.
No entanto, podemos dizer que, uma vez classificado como rollup, significa que o multi-sig foi removido e assim por diante. Então, o problema da descentralização do classificador se torna um problema de experiência do usuário, não um problema de segurança. Então, quando as pessoas falam sobre, digamos, descentralizar o L1, o problema é completamente diferente. Porque L1 tem que dar garantias para pedidos e clientes leves. Portanto, se um light client deseja verificar se o estado está correto, ele deve confiar nos validadores L1. Para rollup, este não é o caso. Porque o classificador fornece apenas classificação temporária, que é finalizada por L1. E, como os rollups também são resistentes à censura, não precisamos de descentralização para que isso aconteça.
Portanto, existem várias razões pelas quais você precisa de um classificador descentralizado. Primeiro, se a finalização de L1 for lenta (seja porque suas provas de validade enviadas são muito lentas ou devido ao mecanismo de período de desafio de provas de fraude cumulativas otimistas), você deve confiar em algo para obter uma confirmação rápida da transação. Nesta fase de confirmação rápida, embora você possa confiar que Starkware ou Scroll não vão te enganar, eles indicam que após a confirmação de um bloqueio, não haverá reorganização. Isso é uma suposição de confiança. E a descentralização pode acrescentar algumas garantias econômicas e assim por diante.
Mas com base nisso, o rollup também não tem garantia de finalização em tempo real. Essencialmente, você pode forçar o empacotamento de transações por meio de L1, mas leva horas para empacotar essa transação. Então, por exemplo, se houver um oráculo responsável pela atualização e o tempo oscilar, basicamente se o oráculo for atualizado por uma hora ou mais, os aplicativos do rollup não estarão disponíveis. Essencialmente, a descentralização nos permite fornecer algumas garantias resistentes à censura em tempo real mais fortes, porque então um adversário precisaria comprometer não apenas uma entidade ou um punhado de entidades, mas toda a rede de pedidos.
Portanto, para nós, a descentralização é mais uma solução para melhorar a experiência do usuário ou corrigir o caso de atualizações do oracle e assim por diante. Em vez de fornecer garantias básicas de segurança, é isso que o L1 faz.
Abdelhamid
Sim, a questão do sorter descentralizado que você mencionou não é exatamente a mesma do L1 descentralizado, que eu acho muito importante. Porque quando vemos alguns L1s criticando os classificadores centralizados, eles não analisam adequadamente as compensações que os classificadores centralizados fazem.
Com base nisso, gostaria de acrescentar algo relacionado à experiência do usuário, relacionado à atividade. Porque quando você tem apenas um único classificador, você corre um risco maior de travamento do classificador. Portanto, um ordenador descentralizado também aumenta a resiliência e vivacidade na rede. Mas mesmo em um contexto centralizado, temos uma boa segurança quando se trata de segurança. Porque quando você pode forçar transações de pacotes por meio de L1, a diferença entre os dois é apenas a linha do tempo. E ter um classificador descentralizado permite que você tenha garantias rápidas de resistência à censura, como Toghrul mencionou. Então, só quero acrescentar que também é importante para a vivacidade ter uma rede descentralizada de pedidos.
Yaoqi
Eu gostaria de acrescentar algo. A atividade é provavelmente a coisa mais importante que precisamos considerar nesta fase. Os casos mais recentes de airdrops nos L2s mais populares, como Optimism e Arbitrum, tiveram um período de inatividade. Portanto, acho que o que precisamos resolver é como lidar com milhares de solicitações de transações por segundo quando temos apenas um classificador. Mesmo em teoria, se você tiver apenas um nó, ele não poderá lidar com tantas solicitações ao mesmo tempo. Portanto, em relação à vivacidade, definitivamente precisamos de vários classificadores. Ponto único de falha é um obstáculo real, não apenas para Web3, até Web2 é um grande problema.
Além disso, há a questão da censura. Se tivermos apenas um coordenador, mesmo que vejamos que ele pode ser executado pela equipe, você ainda precisará provar que a equipe não revisará as transações. Às vezes, é possível e capaz que partes mal-intencionadas coloquem certas transações na lista negra. Esse é um sistema de pedidos descentralizado, eles também podem tentar enviar transações por meio de outros pedidos. É por isso que temos recebido muitas críticas sobre classificadores únicos ultimamente.
Além disso, existem alguns outros problemas, como MEV e execuções iniciais. Em um sistema com classificadores centralizados, especialmente para protocolos DeFi, eles podem verificar o mempool facilmente. Provavelmente não na forma de um favorito, mas eles têm uma chance melhor de seguir o comércio e arbitrar.
Muitos desses problemas, por vários motivos, mesmo vendo que L2 é muito diferente de L1. Mas, em última análise, ainda precisamos torná-lo o mais descentralizado possível. Portanto, temos que enfrentar alguns dos problemas semelhantes que temos com blockchains públicos ou L1.
Abdelhamid
Sim, concordo que um classificador descentralizado é importante. Mas também quero dizer que, como todos sabemos, essa não é uma pergunta fácil.
Além disso, **uma vez que os rollups têm uma arquitetura muito específica, com várias entidades. Estamos falando de um único ordenador, mas também de um provador, e precisamos descentralizar ambos. **Haverá algumas compensações e alguma dificuldade em como precificar as transações porque diferentes fatores são necessários para operar a rede. Então, como você precifica o negócio? O classificador e o provador têm requisitos de hardware diferentes, o provador precisa de uma máquina superpotente e assim por diante. Portanto, precificar transações em um mundo descentralizado também é um problema muito difícil, e é por isso que precisamos de tempo para avançar lentamente.
Portanto, todos nós enfrentaremos tal trade-off.Se quisermos descentralizar rapidamente, podemos precisar pegar algumas rodinhas e descentralizar gradualmente, porque se quisermos diretamente uma arquitetura perfeita, isso levará vários anos. Então, acho que vamos adotar uma abordagem pragmática e tentar descentralizar gradualmente. Pelo menos esse é o nosso plano atual, como talvez começar com um mecanismo de consenso BFT simples e depois adicionar outro mecanismo de consenso no curto prazo ou algo assim. Então, eu só quero dizer que não é uma pergunta fácil. Porque obviamente há uma compensação entre a velocidade de desenvolvimento e a aplicabilidade da arquitetura a um ambiente descentralizado.
Tópico 3
Como descentralizar o classificador?
Abdelhamid
Há muitos recursos que queremos descentralizar e todos eles têm compensações diferentes.
Por exemplo, ao descentralizar, você deseja introduzir algum tipo de mecanismo de consenso. No mecanismo de consenso, no entanto, existem várias partes. A primeira é a eleição do líder, ou seja, como escolher quem vai criar os blocos, quem será o ordenador responsável por criar os blocos em um determinado slot ou em um determinado tempo. **O que a equipe Starknet planeja fazer é utilizar a camada 1 o máximo possível. Ou seja, em nosso algoritmo de eleição de líder, queremos apostar na camada1. Por exemplo, temos tokens e a promessa ocorrerá no contrato inteligente da camada1 Ethereum, que é usado para determinar o mecanismo de eleição do líder. ** Isso significa que precisamos ter alguma interação em que o solicitador L2 consultará o contrato inteligente Ethereum para saber quem será o próximo líder ou algo assim. Então, obviamente, algum tipo de aleatoriedade e outras coisas são necessárias. Portanto, não é uma pergunta simples. Mas essa é a primeira parte. Então você precisa ter um mecanismo para o próprio consenso. Existem várias opções: o mecanismo de cadeia mais longa ou BFT, ou um híbrido dos dois. Como Ethereum, tem LMG Ghost e Casper FFG para finalidade.
Portanto, podemos adotar uma abordagem pragmática e começar primeiro com o BFT. por que? Quando a camada 2 considera a descentralização, nosso objetivo não é ter uma escala de classificador tão grande quanto a camada 1. Por exemplo, no Ethereum, o objetivo é ter a participação de milhões de validadores. Nesse caso, você não pode simplesmente usar o mecanismo BFT, porque será muito ruim em eficiência e causará problemas muito grandes. Por exemplo, se houver algum problema na rede Bitcoin, se for um mecanismo BFT, a cadeia irá parar completamente. Mas este não é o caso, a rede Bitcoin continua a criar blocos, apenas o mecanismo de finalidade é atacado.
Mas na camada 2, se o destino for de algumas centenas a 1.000 classificadores, pode ser bom começar com um mecanismo BFT. Então, temos o mecanismo de eleição do líder, depois o consenso, e aí tem mais duas partes, mas vou deixar para os outros convidados continuarem acrescentando. Mas as outras duas partes são atualizações de estado e geração de provas.
Escolha
Primeiro, em L2, a descentralização é um problema multifacetado, conforme descrito por Abdel. Principalmente no zkRollup, porque tem provadores e ordenadores, você tem que coordenar entre eles, tem que descentralizar os dois. Este problema é completamente diferente de L1.
Outra diferença é que em L2, todo o seu projeto é convencer a ponte subjacente de que o consenso está correto, não convencer qualquer número de outros nós. Obviamente, você deve fazer o mesmo, mas seu foco principal deve ser a própria ponte.
Atualmente, estamos trabalhando em duas direções diferentes. Número um, acho que, como todo mundo, estamos trabalhando em um protocolo BFT. Isso não é muito eficiente e há alguns problemas que precisam ser resolvidos. Chegamos a uma solução aproximada, mas ainda não é a ideal. Por exemplo, uma das perguntas é: como você equilibra incentivos entre classificadores e provadores? Como o solicitante controla o MEV e o provador não tem acesso ao MEV, há um incentivo para que as pessoas executem o solicitante em vez do provador. Mas, na realidade, precisamos de mais provadores do que encomendadores, então como você equilibra os incentivos entre os dois? Este é um desses problemas.
A segunda solução em que estamos trabalhando é outra direção. Lembre-se, as coisas podem mudar. Novas propostas surgem todos os dias. Por exemplo, tem havido muita conversa ultimamente sobre rollup baseado e como você pode terceirizar completamente a classificação para L1. A segunda direção é basicamente abandonar totalmente o classificador e usar algum construtor externo. Por exemplo, os construtores ethereum ou Flashbots SUAVE etc. propõem blocos ordenados e, em seguida, executam o consenso dentro do provador. A vantagem aqui é que você não precisa lidar com incentivos porque basicamente você pode usar o PBS dentro do protocolo e ele cria um protocolo mais simples. Mas a desvantagem é que, como precisamos de um grande número de provadores (porque podemos provar em paralelo), é muito difícil executar um protocolo BFT clássico com eles. Portanto, a questão é como você otimiza um protocolo BFT existente para executar com centenas, ou mesmo milhares, de provadores? E essa não é uma pergunta fácil de responder.
A introdução do consenso L2 é necessária para um ordenador descentralizado?
Yaoqi
Posso responder aproximadamente a essa pergunta porque recentemente lançamos algo assim.
Portanto, introduzir ou não o consenso não depende de querermos ou não. Uma vez que você tenha muitos pedidos ou mesmo apenas nós, você deve fazer com que eles concordem. Isso realmente depende de suas suposições. Se for uma suposição bizantina, podemos usar o BFT ou qualquer protocolo de consenso bizantino existente. Se for uma configuração não bizantina, por exemplo, se assumirmos que um nó só pode estar online e offline e que não pode agir de forma maliciosa, podemos usar o protocolo Raft ou algum outro protocolo de consenso mais rápido. Mas de qualquer forma, se tivermos um grupo de ordenadores ou provadores, se quisermos organizá-los juntos para produzir blocos durante um período de tempo, então você deve ter um protocolo de consenso em torno deles.
Portanto, como Toghrul e Abdel acabaram de mencionar, acredito que há muitas propostas e tópicos de pesquisa sobre como podemos implementar um sistema descentralizado de pedidos ou provas. Portanto, como acabamos de lançar uma rede de teste para um sistema de rollup de vários classificadores (atualmente compatível apenas com provas de fraude para rollups otimistas), com base em nossa experiência de design e implementação, há algumas coisas que posso compartilhar sobre as dificuldades. Como Toghrul mencionou há pouco, a dificuldade não está no protocolo de consenso em si, mas em outras coisas além disso, como a parte da prova. Porque se for um único classificador, você não precisa de muitos nós. Podemos pensar nisso como um EVM, uma máquina virtual. Então, basta buscar transações e executar, fazer transições de estado. O provador é responsável por gerar provas para a transição de estado do conjunto anterior de transações. No entanto, se executarmos o protocolo de consenso para o agrupador e o provador no rollup, precisaremos introduzir uma lógica de consenso adicional lá. Além disso, você também precisa de um sistema de prova para o protocolo de consenso. Portanto, isso introduzirá muito trabalho para o sistema de prova gerar. Depois de gerar a prova, você pode verificá-la facilmente no L1 Ethereum.
É por isso que, de certa forma, quando lançamos a primeira rede de teste de vários pedidos, o rollup otimista teve algumas vantagens a esse respeito. Em geral, você pode simplificar muitas coisas, como não considerar a parte da prova de validade. Como nós, basicamente comparamos tudo com o WASM. Portanto, no final, é uma instrução WASM. Portanto, verificando essas instruções WASM, é relativamente fácil verificar usando o código Solidity. Se apenas reimplementássemos todas as interpretações de instruções WASM no Ethereum.
Mas, em geral, o problema não é singular. Se tivermos uma solução para o problema, correspondentemente, haverá algum outro trabalho de acompanhamento que precisa ser resolvido ao mesmo tempo. Claro, haverá problemas de MEV, como distribuímos o MEV de forma justa. Você pode atribuir todos os ordenadores e provadores com base em se eles produziram um bloco ou validaram um bloco. Mas, no final, é realmente uma combinação de muitas questões, não apenas técnicas, mas também de incentivos econômicos.
E precisamos lembrar que o L2 é proposto porque queremos reduzir significativamente o custo do gás. Portanto, não podemos ter tantos nós. Mesmo na geração de provas, L2 pode ser mais caro que L1. Portanto, realmente precisamos encontrar uma abordagem equilibrada para esse tipo de problema.
Abdelhamid
Gostaria de acrescentar mais um ponto. Primeiro, atualmente não há nenhuma prova real de fraude sem permissão para rollups otimistas. E continuo enfatizando isso sempre que posso, porque é importante ser honesto sobre isso ao comparar. Portanto, eles não são L2. Essa é a primeira coisa.
Então eu gostaria de acrescentar algo sobre a assincronia entre classificação e provas, porque é muito importante. Como você disse, queremos otimizar o sorting, porque atualmente isso é um gargalo para todas as soluções. Mas tudo bem no contexto de uma classificação centralizada, porque sabemos que o classificador produzirá apenas transições de valor e poderemos verificá-las. Mas será mais difícil no contexto de uma classificação descentralizada, porque talvez seu classificador seja capaz de produzir algo que não pode ser verificado. Então você precisará lidar com isso mais tarde.
No contexto da ordenação centralizada, para optimizar a ordenação, uma vez que não temos de gerar provas durante o processo de ordenação, podemos tentar fazê-lo à velocidade local, que é o que queremos fazer. Traduza Cairo para uma linguagem de máquina de baixo nível como LLVM e execute super rápido no classificador. Então você pode provar de forma assíncrona. E o mais legal das provas é que você pode fazê-las em paralelo. A paralelização massiva é alcançada provando que a recursão é possível. É por isso que seremos capazes de alcançar a velocidade do classificador. Mas é difícil quando descentralizado, porque precisamos garantir que o ordenador produza apenas transições de estado válidas.
Escolha
Acrescentarei que não tenho certeza do que Starknet está fazendo aqui. Mas para nós, acho que é uma suposição geral de cada zkRollup que, se você descentralizar o classificador, seu sistema de prova deve ser capaz de lidar com lotes inválidos. Então, basicamente, se, digamos, você enviar um lote com uma assinatura inválida, precisará provar que o estado resultante é equivalente ao estado inicial. Portanto, haverá alguma sobrecarga de qualquer maneira. É sobre como você minimiza a probabilidade de isso acontecer.
Abdelhamid
Sim está certo. É por isso que introduzimos o Sierra no Cairo 1 para tornar tudo verificável. Essa representação intermediária garantirá que todo programa Cairo 1 seja verificável para que possamos incluir uma transação de reversão.
O que é rollup baseado?
Yaoqi
O rollup baseado originalmente veio de uma postagem de blog de Justin Drake nos fóruns Ethereum. Uma de suas ideias é que podemos reutilizar alguns verificadores Ethereum para verificar transações de rollup, para que não precisemos de um grupo separado de nós para verificar diferentes transações de rollup. Em particular, teremos muitos rollups no futuro, incluindo rollups de uso geral e muitos rollups específicos de aplicativos. Portanto, neste caso, seria ótimo se pudéssemos encontrar um lugar comum como o pool de validadores Ethereum para validar essas transações.
Claro, isso é apenas uma ideia, pois também apresenta muitas dificuldades técnicas. Por exemplo, em teoria, poderíamos exigir que os validadores do Ethereum verificassem as transações de rollup, mas é muito difícil obter a lógica de verificação de rollups agrupados ou incorporados no próprio protocolo Ethereum. Chamamos isso de verificação no protocolo, que requer um hard fork de nós Ethereum. Claro, neste caso, podemos verificar algumas transações de rollup. Mas se o fizermos, você verá problemas. É um pouco como se quiséssemos que o rollup do L2 compartilhasse a pressão do Ethereum, mas no final ainda pedimos aos validadores do Ethereum que assumam parte do trabalho transferido para o L2. Muitas pessoas falam sobre como podemos fazer isso.
Então conversamos com Barnabe, um pesquisador da Fundação Ethereum que atualmente trabalha na PBS. Essa é uma proposta do Ethereum, que é dividir a tarefa dos validadores em múltiplos papéis, construtores e proponentes. Agora temos Flashbots para assumir o papel de construtores no PBS, eles compõem todos os blocos e os enviam aos proponentes do Ethereum. Assim que esses blocos forem empacotados na rede Ethereum, os construtores também receberão algumas recompensas. Então, neste caso, como recompensar esses validadores da rede Ethereum? Eles também são responsáveis pela validação de rollup.
Uma das soluções é "refazer", que você já deve ter ouvido falar muito do EigenLayer ou de alguns outros protocolos. Os usuários podem apostar novamente o ETH em outras redes de classificação. Ou recompense os validadores do Ethereum por realmente executar o software para fazer o trabalho de validação para o rollup. Nesse caso, eles podem ser recompensados tanto em L2 quanto por meio do protocolo de reestaqueamento. Houve muitas propostas para isso até agora, mas, em geral, é uma ideia de como reaproveitar os validadores Ethereum existentes. Como podemos reutilizar o ETH existente para ajudar a inaugurar uma nova era de rollup ou sistemas L2? Basicamente, está tentando simplificar muitas coisas para o projeto de rollup. Se um rollup quiser um novo classificador, se quiser uma nova fonte de garantia, pode reutilizar a infraestrutura existente ou a garantia existente. É por isso que é construído sobre o Ethereum e, em seguida, infraestrutura adicional e staking podem ser reutilizados para rollup e L2 também.
Desvantagens do sequenciador compartilhado e rollup baseado e seus cenários de aplicação.
Escolha
Quero reclamar dessa proposta, não estou convencido com a proposta relacionada ao sequenciador compartilhado. Claro, eles ainda estão na infância e, se esses designs melhorarem no futuro, é perfeitamente possível que eu os apoie. É que a forma atual não me convence. Existem muitas razões.
Em primeiro lugar, para mim, a principal proposta de valor de um classificador compartilhado é permitir que os usuários obtenham capacidade de composição atômica entre rollups de uso geral, como Scroll ou Starknet. Mas o problema é que, se você tiver capacidade de composição atômica, seu rollup será tão final quanto o rollup mais lento com o qual você combinar. Portanto, supondo que o Scroll seja combinado com o Optimistic Rollup, a finalidade do Scroll será de sete dias. Embora a principal proposta de valor do ZKRollup seja atingir uma finalização relativamente rápida, os usuários podem voltar para o L1 em minutos. E neste caso, basicamente desista disso.
Outra desvantagem é que, se você deseja finalidade fora da cadeia, precisa executar um nó L2 e, desde que os dados enviados à cadeia sejam finalizados por L1, você obtém a finalidade localmente em L2. Se cada L2 combinado não executar um nó completo, é praticamente impossível obter a finalização local. Isso significa que a execução desse sistema pode ser mais cara do que a execução de um sistema como o Solana, porque você tem vários nós completos em execução ao mesmo tempo, com sua própria sobrecarga e assim por diante.
Portanto, por esses motivos, não acho que faça sentido para L2. É um pouco diferente para o L3, porque se alguém quiser construir uma cadeia específica de aplicativos e não quiser lidar com a descentralização. Digamos que estou construindo um jogo e só quero lidar com a construção do jogo, então posso terceirizar o trabalho descentralizado. Mas não acho que faça sentido para L2 no momento.
Quanto ao rollup baseado, também tenho minhas preocupações. Por exemplo, como você compartilha os lucros do MEV com os provadores? Porque se o problema de alocação não for considerado, basicamente L1 pode obter todos os lucros do MEV. Outra coisinha é que o tempo de confirmação dele é igual ao tempo de confirmação do L1, que é de 12 minutos, o que não pode ser mais rápido. Outro problema é que, por não ter permissão, vários Seekers podem enviar lotes de transações ao mesmo tempo, o que significa que pode acabar com resultados centralizados. Porque os construtores são incentivados a incluir suas transações se um pesquisador se conectar com mais facilidade do que outros. Portanto, pode resultar em apenas um Seeker propondo lotes para L2 no final, o que não é uma solução muito boa, porque se isso acontecer, basicamente voltamos à estaca zero.
Yaoqi
Curiosamente, acabei de ligar para Ben, o fundador do Espresso, na semana passada. Discutimos muito isso no tópico de classificadores compartilhados. Como Toghrul mencionou, acho que há alguma incerteza sobre os cenários de uso de um sistema de pedidos compartilhados. Isso ocorre principalmente porque, para um L2 de uso geral, geralmente não temos um grande número de classificadores devido à eficiência, complexidade e economia. E ainda sinto que, seja para um sequenciador compartilhado, rollup baseado ou restauração, o melhor caso de uso é principalmente para RAS (Rollup as a Service) ou plataformas nas quais podemos lançar muitos rollups. Para ser honesto, não precisamos de uma grande rede de classificação se não houver muitos acúmulos. Esses rollups já possuem seus próprios sistemas de classificadores, e já possuem suas próprias comunidades ou parceiros, quando existem apenas alguns L2s genéricos. Eles realmente não precisam ter uma rede separada e de terceiros. Além disso, isso é um fardo para a rede de terceiros, porque você precisa personalizar para cada L2, e cada L2 tem uma pilha de teste diferente. Isso requer muitas mudanças em sua própria rede.
Mas, ao mesmo tempo, como Toghrul mencionou, para alguns casos de uso especiais. Por exemplo, se quisermos ter alguma interoperabilidade no nível do classificador, os classificadores compartilhados podem ser um caminho a seguir. Por exemplo, o mesmo classificador é usado para vários acúmulos. Nesse caso, esse classificador pode basicamente lidar com algumas transações de rollup cruzado para garantir a atomicidade da cadeia cruzada entre rollup A, B e C.
Mas você também pode ver o problema aqui quando descrevo a situação. Se realmente tivéssemos muitos desses sequenciadores compartilhados, eles se tornariam novamente um gargalo e um novo ponto único de falha. Estamos dando muito poder a esses chamados ordenadores compartilhados. Eles estão se tornando mais parecidos com uma rede, controlando muitos rollups. Por fim, novamente precisamos encontrar uma maneira de descentralizar esse classificador compartilhado.
De qualquer forma, acho bom que as pessoas estejam gradualmente descobrindo mais e mais problemas e apresentando cada vez mais soluções. Em suma, é emocionante ver o que há de novo neste campo todos os dias. Com todas essas novas soluções, pelo menos estamos no caminho certo para descentralizar verdadeiramente todo o espaço de rollup.
Abdel
Sim, concordo com vocês dois. Acho que faz mais sentido para Layer3 e Lisk porque eles não querem mais assumir a responsabilidade de incentivar uma rede descentralizada e precisam encontrar parceiros para iniciar coisas como classificadores. Então eu acho que para Lisk, faz sentido. Mas, como Toghrul, não acho que faça muito sentido para o Layer2 ainda.
Tópico 4
Que impacto um pedido descentralizado terá no MEV?
Abdel
Para a Starknet, no contexto da centralização, não fazemos nenhum tipo de MEV e adotamos um modelo de ordem de chegada. Ou seja, no contexto da descentralização, é claro, mais MEV serão trazidos posteriormente. Mas é muito cedo para dizer qual proporção, porque também depende do desenho do mecanismo de consenso e de outros aspectos.
Escolha
Mas o problema é que, mesmo que você não faça MEV, pode haver algum MEV ainda acontecendo no Starknet. Bem, a descentralização por si só realmente não diminui o MEV ou aumenta o MEV. Claro, se você aplicar algum tipo de protocolo de pedido justo ou criptografia de limite, por exemplo, sim, você minimizará o MEV. Mas você não pode eliminá-lo completamente. Minha filosofia é: MEV não pode ser eliminado. Mas digamos que você esteja apenas criando um consenso BFT ou construindo algo em cima de um consenso BFT. Na verdade, isso não afeta o MEV. O MEV ainda existe, deve ser uma questão de como o pesquisador trabalha com o classificador para extrair esse MEV.
Yaoqi
O problema é que mesmo o modelo de ordem de chegada tem partes complicadas. Uma vez que expomos o mempool para alguns buscadores, eles ainda têm a vantagem de jogar mais. Por exemplo, para os sequenciadores, eles equivalem a esperar na porta do seu escritório. Então, neste caso, uma vez que eles vejam algum tipo de oportunidade de arbitragem, não apenas um front-running ou um ataque sanduíche, assim que um usuário enviar uma transação, eles poderão vê-la imediatamente no mempool. Assim, eles podem rapidamente colocar seus negócios à frente dos outros. Então, eles têm uma vantagem sobre outros pesquisadores.
Mas voltando à descentralização, acho que é principalmente sobre resistência à censura, como discutimos no início. Os sequenciadores são gerenciados pela equipe. A equipe pode dizer que está sendo justa com todos. Mas isso não é impedido no código. Portanto, se pudéssemos ter uma rede P2P, seria ótimo se sentíssemos que esses nós verificam minha transação e então podemos enviá-la para outros nós. Portanto, trata-se realmente da justiça do processamento de transações em L2.
Quanto aos MEVs, porque recentemente, além dos MEVs gerados em um único rollup, existem alguns MEVs gerados através de pontes. Nesta rede de classificação relativamente descentralizada, você terá mais oportunidades de extrair MEV. Supondo que tenhamos uma rede de pedidos compartilhada, se você puder de alguma forma influenciar o pedido compartilhado para reordenar as transações, basicamente você terá uma grande vantagem sobre todos os outros.
Existem vantagens e desvantagens em uma rede de sequenciador compartilhado. No lado positivo, podemos descentralizar ainda mais o sistema de classificação. Mas, por outro lado, todos têm a oportunidade de ser classificadores. Então, eles podem basicamente fazer o que quiserem, e é uma floresta escura novamente. Então, introduzimos a descentralização e tivemos que enfrentar problemas semelhantes aos do Ethereum. É por isso que o Flashbots e o pessoal da Ethereum Foundation querem seguir em frente com o PBS, separar proponentes e construtores e, em seguida, tentar ter uma solução única do lado do construtor.
Então, quando olhamos para o problema, não é apenas um único problema. Não é mais um problema individual, mas um contra seis e muito mais.