Recentemente, fiquei convencido de que o futuro do Ethereum Rollups é na verdade um híbrido das duas abordagens principais (ZK e Optimistic). Nesta postagem, tentarei explicar a arquitetura básica do que imagino e explicar por que acho que esse é o melhor caminho a seguir.
Não vou gastar muito tempo discutindo a natureza do ZK ou dos Rollups otimistas. Este post pressupõe que você já tenha um entendimento decente de como essas coisas funcionam. Você não precisa ser um especialista, mas deve pelo menos saber o que são e como funcionam em alto nível. Se eu tentasse explicar Rollups para você, este post ficaria muito, muito longo. Em suma, aproveite a leitura!
Comece com o Rollup Otimista
Hybrid ZK/Optimistic Rollup começou como Optimistic Rollup, que é muito semelhante à arquitetura Bedrock do Optimism. A Bedrock visa a compatibilidade máxima com Ethereum ("EVM Equivalent") e consegue isso executando um cliente de execução que é quase idêntico a um cliente Ethereum normal. A Bedrock usa o próximo modelo de separação de cliente de consenso/execução da Ethereum, reduzindo significativamente a variação do EVM (algumas alterações sempre serão necessárias, mas podemos gerenciar isso). Enquanto escrevo isso, a diferença de Bedrock Geth é um commit de +388 -30.
Como qualquer bom Rollup, o Optimism pega dados de bloco/transação do Ethereum, classifica esses dados de maneira determinística dentro do cliente de consenso e, em seguida, alimenta esses dados no cliente de execução L2 para execução. Essa arquitetura resolve a primeira metade do quebra-cabeça do "acumulador ideal", dando-nos um EVM equivalente L2.
Claro, agora também precisamos resolver o problema de como dizer de uma maneira demonstrável o que está acontecendo dentro do Ethereum Optimism. Sem esse recurso, os contratos não podem tomar decisões com base no estado de Otimismo. Isso significaria que os usuários podem depositar no Optimism, mas nunca sacar seus ativos. Embora em alguns casos um rollup unidirecional possa realmente ser útil, em geral um rollup bidirecional é mais útil.
Podemos dizer ao Ethereum o estado de qualquer Rollup, dando um compromisso a esse estado e comprovando que o compromisso foi gerado corretamente. Outra forma de dizer isso é que estamos provando que o "programa Rollup" foi executado corretamente. A única diferença real entre o ZK e o Optimistic Rollups é a forma dessa prova. No ZK Rollup, você precisa fornecer uma prova explícita do ZK de que o programa foi executado corretamente. No Optimistic Rollup, você faz afirmações sobre promessas, mas sem provas explícitas. Outros usuários podem contestar suas reivindicações e forçá-lo a jogar um jogo iterativo em que você eventualmente descobrirá quem está certo.
Não vou entrar em muitos detalhes sobre o jogo de desafio Optimistic Rollup. Vale a pena notar que o estado da arte neste jogo é compilar seu programa (Get EVM + algumas partes marginais no caso do Optimism) para alguma arquitetura de máquina simples como MIPS. Fazemos isso porque precisamos construir um interpretador para nosso programa on-chain, e é muito mais fácil construir um interpretador MIPS do que um interpretador EVM. O EVM também é um alvo móvel (temos garfos de atualização regulares) e não cobre totalmente os programas que queremos provar (há algumas coisas que não são EVM lá também).
Depois de construir um interpretador on-chain para sua arquitetura de máquina simples e criar algumas ferramentas off-chain, você deve ter um Rollup Optimistic totalmente funcional.
Convertido para ZK Rollup
No geral, acho que o Optimistic Rollups dominará pelo menos os próximos anos. Algumas pessoas pensam que o ZK Rollups acabará superando o Optimistic Rollups, mas acho que isso pode estar errado. Acho que a relativa simplicidade e flexibilidade dos Optimistic Rollups hoje significa que eles podem ser transformados em ZK Rollups ao longo do tempo. Se pudermos descobrir um modelo que faça isso acontecer, realmente não há incentivo forte para implantar um modelo menos flexível e mais frágil quando você pode simplesmente implantar em um sistema Optimistic existente e chamá-lo de sistema ZK de um dia de trabalho.
Portanto, meu objetivo é criar uma arquitetura e um caminho de migração para que os sistemas Optimistic modernos existentes (como o Bedrock) possam ser perfeitamente transformados em sistemas ZK. Veja como eu acho que isso não é apenas possível, mas de uma forma que vai além da abordagem atual do zkEVM.
Começamos com a arquitetura de estilo Bedrock que descrevi acima. Observe que eu (brevemente) expliquei como Bedrock tem um jogo de desafio que afirma o programa L2 (executando o EVM + algumas coisas extras para transformá-lo em um ZK Rollup
No geral, acho que os Rollups otimistas dominarão os próximos anos. Há uma opinião de que o ZK Rollup acabará superando o Optimistic Rollup, mas acho que isso pode estar errado. Acho que a relativa simplicidade e flexibilidade dos Optimistic Rollups significa que eles podem ser transformados em ZK Rollups ao longo do tempo. Se pudermos descobrir um modelo para que essa transição aconteça, realmente não haverá um forte incentivo para implantar sistemas ZK menos flexíveis e mais propensos a problemas.
Portanto, meu objetivo é criar uma arquitetura e um caminho de migração que permita que os sistemas Optimistic modernos existentes (como o Bedrock) façam uma transição perfeita para os sistemas ZK. Aqui está, acredito, uma maneira não apenas de fazer essa transição acontecer, mas de uma maneira que vai além da abordagem zkEVM de hoje.
Começamos com a arquitetura estilo Bedrock que descrevi anteriormente. Observe que eu (brevemente) expliquei como Bedrock tem um jogo de desafio que pode afirmar a validade da execução de um programa L2 (um programa MIPS executando o EVM + alguns extras). Uma das principais desvantagens dessa abordagem é que precisamos permitir um período de tempo para que um usuário detecte e conteste com sucesso uma falsa proposta de resultado do programa. Isso acrescenta um tempo considerável ao processo de retirada de ativos (atualmente 7 dias na rede principal do Optimism).
No entanto, nosso L2 é apenas um programa rodando em uma máquina simples (MIPS). É inteiramente possível construir um circuito ZK para uma máquina tão simples. Podemos então usar este circuito para provar inequivocamente a execução correta do programa L2. Sem fazer nenhuma alteração na base de código Bedrock atual, você pode começar a publicar provas de validade para o Optimism. É realmente muito simples.
Por que esse método funciona tão bem
Nota rápida: nesta seção, mencionei "zkMIPS", mas na verdade estou usando-o para me referir a qualquer zkVM "simples" genérico.
zkMIPS é mais simples que zkEVM
Um grande benefício de construir um zkMIPS (ou zk[inserir outro nome de máquina]) em vez de zkEVM é que a arquitetura da máquina de destino é simples e estática. O EVM muda com frequência. Os preços do gás mudarão, os opcodes serão ajustados e as coisas serão adicionadas ou removidas. E o MIPS-V não mudou desde 1996. Ao direcionar o zkMIPS, você trabalha em um espaço de problema fixo. Você não precisa alterar e possivelmente reauditar seu circuito toda vez que o EVM for atualizado.
zkMIPS é mais flexível que zkEVM
Outro ponto-chave de discórdia é que o zkMIPS é mais flexível que o zkEVM. Com o zkMIPS, você tem mais flexibilidade para modificar o código do cliente à vontade para obter várias otimizações ou melhorias na experiência do usuário. As atualizações do cliente não precisam mais vir com as atualizações do circuito. Você também pode criar um componente principal que pode ser usado para transformar qualquer blockchain em um ZK Rollup, não apenas Ethereum.
Sua pergunta se transforma em tempo de prova
O tempo de prova ZK escala ao longo de dois eixos: número de restrições e tamanho do circuito. Ao focar no circuito de uma máquina simples como o MIPS (em vez de uma máquina mais complexa como o EVM), conseguimos reduzir significativamente o tamanho e a complexidade do circuito. No entanto, o número de restrições depende do número de instruções de máquina executadas. Cada opcode EVM é dividido em vários opcodes MIPS, o que significa que o número de restrições aumenta significativamente, assim como o tempo geral de prova.
Mas reduzir os tempos de prova é um problema firmemente enraizado no espaço Web2. Dado que a arquitetura da máquina MIPS não mudará em um futuro próximo, podemos otimizar altamente nossos circuitos e programas de prova sem nos preocuparmos com alterações de EVM em um estágio posterior. Tenho certeza de que o pool de contratação de engenheiros de hardware que podem otimizar um programa bem definido é pelo menos 10 (se não 100) vezes maior do que o pool de contratação para construir e auditar um alvo zkEVM em constante mudança. Uma empresa como a Netflix provavelmente tem muitos engenheiros de hardware trabalhando na otimização de chips de transcodificação, e eles aceitariam alegremente um monte de dinheiro de VC para enfrentar um desafio interessante do ZK.
O tempo de prova inicial para tal circuito pode exceder o período de retirada de 7 dias do Optimistic Rollup. Esse tempo de prova só diminuirá com o tempo. Ao introduzir ASICs e FPGAs, podemos acelerar bastante o tempo de prova. Com um objetivo estático, podemos construir provadores mais otimizados.
Eventualmente, o tempo de prova para este circuito será menor do que o atual período de retirada do Optimistic Rollup de 7 dias, e podemos iniciar o processo de desafio para considerar o cancelamento do Optimistic. Executar uma prova por 7 dias provavelmente ainda é muito caro, então podemos esperar um pouco mais, mas o ponto ainda é válido. Você pode até executar os dois sistemas de prova ao mesmo tempo, para que possamos começar a usar as provas ZK imediatamente e, se por algum motivo o programa de prova falhar, podemos recorrer às provas otimistas. Quando estiver pronto, é fácil passar para as provas ZK de uma forma totalmente transparente para o aplicativo. Nenhum outro sistema oferece essa flexibilidade e um caminho de migração suave.
Você pode se concentrar em outras questões importantes
Executar um blockchain é uma tarefa difícil e não envolve apenas escrever muito código de back-end. Muito do que fazemos na Optimism é focado em melhorar a experiência do usuário e do desenvolvedor por meio de ferramentas úteis do lado do cliente. Também gastamos muito tempo e energia lidando com as coisas "suaves": conversando com projetos, entendendo pontos problemáticos, criando incentivos. Quanto mais tempo você gasta em software blockchain, menos tempo você gasta pensando nessas outras coisas. Você sempre pode tentar contratar mais pessoas, mas as organizações não escalam linearmente e cada nova contratação aumenta a carga de comunicação interna.
Como o trabalho do circuito ZK pode ser adicionado a uma cadeia de execução existente, você pode trabalhar na construção da plataforma principal e do software de prova em paralelo. Além disso, como o cliente pode ser modificado sem alterar o circuito, você pode separar as equipes de cliente e atestado. Um Rollup otimista que adota essa abordagem pode estar muitos anos à frente dos concorrentes da ZK em termos de atividade real na cadeia.
** A **** ALGUMAS CONCLUSÕES **
Para ser completamente franco, não consigo ver nenhuma desvantagem significativa nessa abordagem, assumindo que o provador zkMIPS pode ser otimizado substancialmente ao longo do tempo. O único impacto real que vejo no aplicativo é que os custos de gás para diferentes opcodes podem precisar ser ajustados para refletir o tempo de prova adicionado por esses opcodes. Se for realmente impossível otimizar este provador a um nível razoável, admito a derrota. Se for realmente possível otimizar este provador, então a abordagem zkMIPS/zkVM parece ser muito melhor do que a atual abordagem zkEVM que pode tornar a última totalmente obsoleta. Isso pode parecer uma afirmação radical, mas não faz muito tempo, as provas de falha otimista de etapa única foram completamente substituídas por provas de várias etapas.
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Discussão sobre ZK/Optimistic Hybrid Rollup
Autor: kelvinfichter; Compilador: MarsBit, MK
Recentemente, fiquei convencido de que o futuro do Ethereum Rollups é na verdade um híbrido das duas abordagens principais (ZK e Optimistic). Nesta postagem, tentarei explicar a arquitetura básica do que imagino e explicar por que acho que esse é o melhor caminho a seguir.
Não vou gastar muito tempo discutindo a natureza do ZK ou dos Rollups otimistas. Este post pressupõe que você já tenha um entendimento decente de como essas coisas funcionam. Você não precisa ser um especialista, mas deve pelo menos saber o que são e como funcionam em alto nível. Se eu tentasse explicar Rollups para você, este post ficaria muito, muito longo. Em suma, aproveite a leitura!
Comece com o Rollup Otimista
Hybrid ZK/Optimistic Rollup começou como Optimistic Rollup, que é muito semelhante à arquitetura Bedrock do Optimism. A Bedrock visa a compatibilidade máxima com Ethereum ("EVM Equivalent") e consegue isso executando um cliente de execução que é quase idêntico a um cliente Ethereum normal. A Bedrock usa o próximo modelo de separação de cliente de consenso/execução da Ethereum, reduzindo significativamente a variação do EVM (algumas alterações sempre serão necessárias, mas podemos gerenciar isso). Enquanto escrevo isso, a diferença de Bedrock Geth é um commit de +388 -30.
Como qualquer bom Rollup, o Optimism pega dados de bloco/transação do Ethereum, classifica esses dados de maneira determinística dentro do cliente de consenso e, em seguida, alimenta esses dados no cliente de execução L2 para execução. Essa arquitetura resolve a primeira metade do quebra-cabeça do "acumulador ideal", dando-nos um EVM equivalente L2.
Claro, agora também precisamos resolver o problema de como dizer de uma maneira demonstrável o que está acontecendo dentro do Ethereum Optimism. Sem esse recurso, os contratos não podem tomar decisões com base no estado de Otimismo. Isso significaria que os usuários podem depositar no Optimism, mas nunca sacar seus ativos. Embora em alguns casos um rollup unidirecional possa realmente ser útil, em geral um rollup bidirecional é mais útil.
Podemos dizer ao Ethereum o estado de qualquer Rollup, dando um compromisso a esse estado e comprovando que o compromisso foi gerado corretamente. Outra forma de dizer isso é que estamos provando que o "programa Rollup" foi executado corretamente. A única diferença real entre o ZK e o Optimistic Rollups é a forma dessa prova. No ZK Rollup, você precisa fornecer uma prova explícita do ZK de que o programa foi executado corretamente. No Optimistic Rollup, você faz afirmações sobre promessas, mas sem provas explícitas. Outros usuários podem contestar suas reivindicações e forçá-lo a jogar um jogo iterativo em que você eventualmente descobrirá quem está certo.
Não vou entrar em muitos detalhes sobre o jogo de desafio Optimistic Rollup. Vale a pena notar que o estado da arte neste jogo é compilar seu programa (Get EVM + algumas partes marginais no caso do Optimism) para alguma arquitetura de máquina simples como MIPS. Fazemos isso porque precisamos construir um interpretador para nosso programa on-chain, e é muito mais fácil construir um interpretador MIPS do que um interpretador EVM. O EVM também é um alvo móvel (temos garfos de atualização regulares) e não cobre totalmente os programas que queremos provar (há algumas coisas que não são EVM lá também).
Depois de construir um interpretador on-chain para sua arquitetura de máquina simples e criar algumas ferramentas off-chain, você deve ter um Rollup Optimistic totalmente funcional.
Convertido para ZK Rollup
No geral, acho que o Optimistic Rollups dominará pelo menos os próximos anos. Algumas pessoas pensam que o ZK Rollups acabará superando o Optimistic Rollups, mas acho que isso pode estar errado. Acho que a relativa simplicidade e flexibilidade dos Optimistic Rollups hoje significa que eles podem ser transformados em ZK Rollups ao longo do tempo. Se pudermos descobrir um modelo que faça isso acontecer, realmente não há incentivo forte para implantar um modelo menos flexível e mais frágil quando você pode simplesmente implantar em um sistema Optimistic existente e chamá-lo de sistema ZK de um dia de trabalho.
Portanto, meu objetivo é criar uma arquitetura e um caminho de migração para que os sistemas Optimistic modernos existentes (como o Bedrock) possam ser perfeitamente transformados em sistemas ZK. Veja como eu acho que isso não é apenas possível, mas de uma forma que vai além da abordagem atual do zkEVM.
Começamos com a arquitetura de estilo Bedrock que descrevi acima. Observe que eu (brevemente) expliquei como Bedrock tem um jogo de desafio que afirma o programa L2 (executando o EVM + algumas coisas extras para transformá-lo em um ZK Rollup
No geral, acho que os Rollups otimistas dominarão os próximos anos. Há uma opinião de que o ZK Rollup acabará superando o Optimistic Rollup, mas acho que isso pode estar errado. Acho que a relativa simplicidade e flexibilidade dos Optimistic Rollups significa que eles podem ser transformados em ZK Rollups ao longo do tempo. Se pudermos descobrir um modelo para que essa transição aconteça, realmente não haverá um forte incentivo para implantar sistemas ZK menos flexíveis e mais propensos a problemas.
Portanto, meu objetivo é criar uma arquitetura e um caminho de migração que permita que os sistemas Optimistic modernos existentes (como o Bedrock) façam uma transição perfeita para os sistemas ZK. Aqui está, acredito, uma maneira não apenas de fazer essa transição acontecer, mas de uma maneira que vai além da abordagem zkEVM de hoje.
Começamos com a arquitetura estilo Bedrock que descrevi anteriormente. Observe que eu (brevemente) expliquei como Bedrock tem um jogo de desafio que pode afirmar a validade da execução de um programa L2 (um programa MIPS executando o EVM + alguns extras). Uma das principais desvantagens dessa abordagem é que precisamos permitir um período de tempo para que um usuário detecte e conteste com sucesso uma falsa proposta de resultado do programa. Isso acrescenta um tempo considerável ao processo de retirada de ativos (atualmente 7 dias na rede principal do Optimism).
No entanto, nosso L2 é apenas um programa rodando em uma máquina simples (MIPS). É inteiramente possível construir um circuito ZK para uma máquina tão simples. Podemos então usar este circuito para provar inequivocamente a execução correta do programa L2. Sem fazer nenhuma alteração na base de código Bedrock atual, você pode começar a publicar provas de validade para o Optimism. É realmente muito simples.
Por que esse método funciona tão bem
Nota rápida: nesta seção, mencionei "zkMIPS", mas na verdade estou usando-o para me referir a qualquer zkVM "simples" genérico.
zkMIPS é mais simples que zkEVM
Um grande benefício de construir um zkMIPS (ou zk[inserir outro nome de máquina]) em vez de zkEVM é que a arquitetura da máquina de destino é simples e estática. O EVM muda com frequência. Os preços do gás mudarão, os opcodes serão ajustados e as coisas serão adicionadas ou removidas. E o MIPS-V não mudou desde 1996. Ao direcionar o zkMIPS, você trabalha em um espaço de problema fixo. Você não precisa alterar e possivelmente reauditar seu circuito toda vez que o EVM for atualizado.
zkMIPS é mais flexível que zkEVM
Outro ponto-chave de discórdia é que o zkMIPS é mais flexível que o zkEVM. Com o zkMIPS, você tem mais flexibilidade para modificar o código do cliente à vontade para obter várias otimizações ou melhorias na experiência do usuário. As atualizações do cliente não precisam mais vir com as atualizações do circuito. Você também pode criar um componente principal que pode ser usado para transformar qualquer blockchain em um ZK Rollup, não apenas Ethereum.
Sua pergunta se transforma em tempo de prova
O tempo de prova ZK escala ao longo de dois eixos: número de restrições e tamanho do circuito. Ao focar no circuito de uma máquina simples como o MIPS (em vez de uma máquina mais complexa como o EVM), conseguimos reduzir significativamente o tamanho e a complexidade do circuito. No entanto, o número de restrições depende do número de instruções de máquina executadas. Cada opcode EVM é dividido em vários opcodes MIPS, o que significa que o número de restrições aumenta significativamente, assim como o tempo geral de prova.
Mas reduzir os tempos de prova é um problema firmemente enraizado no espaço Web2. Dado que a arquitetura da máquina MIPS não mudará em um futuro próximo, podemos otimizar altamente nossos circuitos e programas de prova sem nos preocuparmos com alterações de EVM em um estágio posterior. Tenho certeza de que o pool de contratação de engenheiros de hardware que podem otimizar um programa bem definido é pelo menos 10 (se não 100) vezes maior do que o pool de contratação para construir e auditar um alvo zkEVM em constante mudança. Uma empresa como a Netflix provavelmente tem muitos engenheiros de hardware trabalhando na otimização de chips de transcodificação, e eles aceitariam alegremente um monte de dinheiro de VC para enfrentar um desafio interessante do ZK.
O tempo de prova inicial para tal circuito pode exceder o período de retirada de 7 dias do Optimistic Rollup. Esse tempo de prova só diminuirá com o tempo. Ao introduzir ASICs e FPGAs, podemos acelerar bastante o tempo de prova. Com um objetivo estático, podemos construir provadores mais otimizados.
Eventualmente, o tempo de prova para este circuito será menor do que o atual período de retirada do Optimistic Rollup de 7 dias, e podemos iniciar o processo de desafio para considerar o cancelamento do Optimistic. Executar uma prova por 7 dias provavelmente ainda é muito caro, então podemos esperar um pouco mais, mas o ponto ainda é válido. Você pode até executar os dois sistemas de prova ao mesmo tempo, para que possamos começar a usar as provas ZK imediatamente e, se por algum motivo o programa de prova falhar, podemos recorrer às provas otimistas. Quando estiver pronto, é fácil passar para as provas ZK de uma forma totalmente transparente para o aplicativo. Nenhum outro sistema oferece essa flexibilidade e um caminho de migração suave.
Você pode se concentrar em outras questões importantes
Executar um blockchain é uma tarefa difícil e não envolve apenas escrever muito código de back-end. Muito do que fazemos na Optimism é focado em melhorar a experiência do usuário e do desenvolvedor por meio de ferramentas úteis do lado do cliente. Também gastamos muito tempo e energia lidando com as coisas "suaves": conversando com projetos, entendendo pontos problemáticos, criando incentivos. Quanto mais tempo você gasta em software blockchain, menos tempo você gasta pensando nessas outras coisas. Você sempre pode tentar contratar mais pessoas, mas as organizações não escalam linearmente e cada nova contratação aumenta a carga de comunicação interna.
Como o trabalho do circuito ZK pode ser adicionado a uma cadeia de execução existente, você pode trabalhar na construção da plataforma principal e do software de prova em paralelo. Além disso, como o cliente pode ser modificado sem alterar o circuito, você pode separar as equipes de cliente e atestado. Um Rollup otimista que adota essa abordagem pode estar muitos anos à frente dos concorrentes da ZK em termos de atividade real na cadeia.
** A **** ALGUMAS CONCLUSÕES **
Para ser completamente franco, não consigo ver nenhuma desvantagem significativa nessa abordagem, assumindo que o provador zkMIPS pode ser otimizado substancialmente ao longo do tempo. O único impacto real que vejo no aplicativo é que os custos de gás para diferentes opcodes podem precisar ser ajustados para refletir o tempo de prova adicionado por esses opcodes. Se for realmente impossível otimizar este provador a um nível razoável, admito a derrota. Se for realmente possível otimizar este provador, então a abordagem zkMIPS/zkVM parece ser muito melhor do que a atual abordagem zkEVM que pode tornar a última totalmente obsoleta. Isso pode parecer uma afirmação radical, mas não faz muito tempo, as provas de falha otimista de etapa única foram completamente substituídas por provas de várias etapas.