Título original: "OP+ZK, o Hybrid Rollup se tornará o futuro definitivo da expansão do Ethereum?" "
Postagem original de @kelvinfichter
Compilação original: Jaleel, BlockBeats
Recentemente, fiquei bastante convencido de que o futuro do Ethereum Rollup é na verdade um híbrido das duas abordagens principais, ZK e Optimistic. Nesta postagem, tentarei expor o básico do que imagino ser essa arquitetura e por que acredito que essa é a direção que devemos seguir. Observe que passo a maior parte do tempo trabalhando no Optimism, também conhecido como Optimistic Rollup, mas não sou um especialista em ZK. Se cometi algum erro ao falar sobre o ZK, sinta-se à vontade para entrar em contato comigo e corrigirei.
Não pretendo descrever o princípio de operação do ZK e dos Rollups otimistas em detalhes neste artigo.Se eu gastar tempo explicando a essência dos Rollups, este artigo ficará muito longo. Portanto, este artigo é baseado no fato de você já ter um certo conhecimento sobre essas tecnologias. Claro, você não precisa ser um especialista, mas deve pelo menos saber o que são ZK e Optimistic Rollups e seu mecanismo geral de operação. De qualquer forma, por favor, aproveite a leitura deste artigo.
Vamos começar com o Optimistic Rollup
O sistema que misturava ZK e Optimistic Rollup foi originalmente baseado no Optimistic Rollup baseado na arquitetura Bedrock do Optimism. O Bedrock foi projetado para ser compatível ao máximo ("equivalente a EVM") com Ethereum, executando um cliente de execução quase idêntico ao cliente Ethereum. A Bedrock aproveita o próximo modelo de divisão de cliente de consenso/execução da Ethereum, reduzindo significativamente a variação do EVM (é claro que sempre haverá algumas mudanças ao longo do caminho, mas podemos lidar com isso).
Como todos os bons Rollups, o Optimism extrai dados de bloco/transação do Ethereum, então classifica esses dados de alguma forma determinística no cliente de consenso e alimenta esses dados para o cliente de execução L2 para execução. Essa arquitetura resolve a primeira metade do quebra-cabeça do "rollup ideal" e nos dá um L2 equivalente ao EVM.
Claro, o problema que ainda precisamos resolver agora é contar ao Ethereum o que aconteceu dentro do Optimism de uma forma verificável. Se esse problema não for resolvido, os contratos inteligentes não podem tomar decisões com base no estado de Otimismo. Isso significa que os usuários podem depositar no Optimism, mas não podem sacar seus ativos. Embora o rollup unidirecional seja possível em alguns casos, na maioria dos casos, o rollup bidirecional é mais eficaz.
Ao fornecer algum tipo de compromisso com esse estado e provar que esse compromisso está correto, podemos comunicar o estado de todos os Rollups ao Ethereum. Em outras palavras, estamos provando que o "programa Rollup" foi executado corretamente. A única diferença substancial entre o ZK e o Optimistic Rollups é a forma desta prova. No ZK Rollup, você precisa fornecer uma prova explícita de conhecimento zero para provar a execução correta do programa. No Optimistic Rollup, você pode fazer uma declaração sobre a promessa sem fornecer evidências claras. Ao desafiar e questionar sua declaração, outros usuários podem forçá-lo a participar de um "jogo" de deliberação e desafio para determinar quem é o sim.
Não vou entrar em detalhes sobre os desafios do Optimistic Rollup. Vale a pena notar que o estado da arte neste estágio é compilar seu programa (Get EVM + alguns bits marginais no caso do Optimism) para alguma arquitetura de máquina simples como o MIPS. Fazemos isso porque precisamos construir um interpretador de 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 não EVM lá também).
Depois de construir um interpretador on-chain para sua arquitetura de máquina simples e criar algumas ferramentas offline, você deve ter um Rollup Optimistic totalmente funcional.
Vire para ZK Rollup
No geral, acredito firmemente que o Optimistic Rollups dominará os próximos anos. Algumas pessoas pensam que o ZK Rollups acabará superando o Optimistic Rollups, mas eu não concordo com essa visão. Sinto que a atual relativa simplicidade e flexibilidade dos Optimistic Rollups significa que eles podem ser gradualmente transformados em ZK Rollups. Se pudermos encontrar um padrão para fazer essa transição, em vez de tentar construir um ecossistema ZK mais inflexível e frágil, podemos simplesmente implantar em um ecossistema Optimistic Rollup já existente.
Meu objetivo, portanto, é criar uma arquitetura e um caminho de migração que permita que um ecossistema OP moderno existente (como Bedrock) faça a transição perfeita para um ecossistema ZK. Acredito que isso não seja apenas possível, mas uma maneira de ir além da abordagem atual do zkEVM.
Vamos começar com a arquitetura Bedrock que descrevi anteriormente. Observe que expliquei (brevemente) que Bedrock tem um jogo de desafio para verificar a validade de certas execuções de programas L2 (programas MIPS executando o EVM + algumas coisas extras). Uma grande desvantagem dessa abordagem é que precisamos permitir um período de tempo para que os usuários tenham a chance de detectar e contestar com sucesso uma proposta de resultado de programa errada. Isso adiciona uma quantidade considerável de tempo ao processo de retirada de ativos (7 dias na rede principal atual do Optimism).
Porém, nosso L2 nada mais é do que um programa rodando em uma máquina simples como o MIPS. É perfeitamente possível construirmos um circuito ZK para um mecanismo 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. É tão simples na prática.
Por que esse método é confiável?
Apenas um esclarecimento rápido: embora nesta seção eu mencione "zkMIPS", na verdade quero dizer isso como um termo para todas as máquinas virtuais à prova de conhecimento zero gerais e simplificadas (zkVM).
zkMIPS é mais fácil que zkEVM
Construir um zkMIPS (ou qualquer outro tipo de máquina virtual zk) tem uma grande vantagem sobre o zkEVM: a arquitetura da máquina de destino é simples e estática. O EVM muda com frequência, os preços do gás se ajustam, os opcodes mudam e os elementos são adicionados ou removidos. E o MIPS-V não mudou desde 1996. Concentre-se no zkMIPS e você estará lidando com um espaço de problema fixo. Você não precisa alterar ou mesmo reauditar seu circuito toda vez que o EVM for atualizado.
zkMIPS é mais flexível que zkEVM
Outro insight importante é que o zkMIPS é mais flexível que o zkEVM. Com o zkMIPS, você pode alterar o código do cliente à vontade, realizar várias otimizações ou melhorar a experiência do usuário sem atualizações de circuito correspondentes. Você pode até criar um componente central que transforma qualquer blockchain em um ZK Rollup, não apenas Ethereum.
Sua missão se transforma em prova de tempo
O tempo das provas de conhecimento zero escala ao longo de dois eixos: o número de restrições e o 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.
No entanto, reduzir os tempos de prova também é um problema profundamente enraizado no domínio Web2. Dado que é improvável que a arquitetura da máquina MIPS mude tão cedo, podemos otimizar altamente o circuito e o provador, independentemente de futuras alterações no EVM. Sinto-me bastante confiante em contratar um engenheiro de hardware sênior para otimizar um problema bem definido, talvez dez ou até cem vezes o número de engenheiros que criam e revisam um alvo zkEVM em movimento. Uma empresa como a Netflix provavelmente tem um grande número de engenheiros de hardware otimizando chips de transcodificação, e eles provavelmente estão dispostos a gastar um monte de fundos de capital de risco para enfrentar esse interessante desafio ZK.
O tempo de prova inicial para um circuito como este 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 significativamente 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 Otimismo de 7 dias, e podemos iniciar o processo de desafio para considerar a remoção do Otimismo. Executar um provador por 7 dias provavelmente ainda é muito caro, então podemos esperar um pouco mais, mas o ponto é sustentável. Você pode até executar os dois sistemas de prova ao mesmo tempo, para que possamos começar a usar as provas ZK o mais rápido possível e retornar às provas do Otimismo se o provador falhar por qualquer motivo. Depois de prontas, as provas do Optimism podem ser removidas de forma totalmente transparente para o aplicativo, de forma que seu Rollup Optimistic se torne um ZK Rollup.
Você pode cuidar de outras questões importantes
Executar um blockchain é um problema complexo que envolve mais do que apenas escrever muito código de back-end. Na Optimism, muito do nosso trabalho é focado em melhorar a experiência do usuário e do desenvolvedor, fornecendo ferramentas úteis do lado do cliente. Também dedicamos muito tempo e energia às questões "suaves": conversar com os projetos, entender seus pontos problemáticos e criar incentivos. Quanto mais tempo você gasta em software de cadeia, menos tempo você tem para lidar com essas outras coisas. Embora você sempre possa tentar contratar mais pessoas, as organizações não escalam linearmente e cada nova contratação aumenta os custos de comunicação interna.
Como o trabalho do circuito de conhecimento zero pode ser aplicado diretamente à cadeia que já está em execução, você pode construir a plataforma principal e desenvolver o software de prova ao mesmo tempo. Como o cliente pode ser modificado sem alterar o circuito, você pode desacoplar seu cliente e a equipe de prova. Um Rollup otimista dessa maneira pode estar anos à frente dos concorrentes de conhecimento zero em termos de atividade real na cadeia.
para concluir
Francamente, não vejo nenhuma desvantagem significativa no provador zkMIPS, a menos que não possa ser otimizado significativamente ao longo do tempo. O único impacto real que vejo no aplicativo é que o custo do gás de diferentes opcodes pode precisar ser ajustado para refletir o aumento do tempo de prova para esses opcodes. Se realmente não for possível otimizar este provador a um nível razoável, admito que falhei. Mas se for possível otimizar este provador, então a abordagem zkMIPS/zkVM pode substituir completamente a atual abordagem zkEVM. Isso pode soar como uma afirmação radical, mas não faz muito tempo, as provas de falha otimistas de uma etapa foram completamente substituídas por provas de várias etapas.
link original
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
A mistura de ZK e OP será o futuro do Ethereum Rollup?
Título original: "OP+ZK, o Hybrid Rollup se tornará o futuro definitivo da expansão do Ethereum?" "
Postagem original de @kelvinfichter
Compilação original: Jaleel, BlockBeats
Recentemente, fiquei bastante convencido de que o futuro do Ethereum Rollup é na verdade um híbrido das duas abordagens principais, ZK e Optimistic. Nesta postagem, tentarei expor o básico do que imagino ser essa arquitetura e por que acredito que essa é a direção que devemos seguir. Observe que passo a maior parte do tempo trabalhando no Optimism, também conhecido como Optimistic Rollup, mas não sou um especialista em ZK. Se cometi algum erro ao falar sobre o ZK, sinta-se à vontade para entrar em contato comigo e corrigirei.
Não pretendo descrever o princípio de operação do ZK e dos Rollups otimistas em detalhes neste artigo.Se eu gastar tempo explicando a essência dos Rollups, este artigo ficará muito longo. Portanto, este artigo é baseado no fato de você já ter um certo conhecimento sobre essas tecnologias. Claro, você não precisa ser um especialista, mas deve pelo menos saber o que são ZK e Optimistic Rollups e seu mecanismo geral de operação. De qualquer forma, por favor, aproveite a leitura deste artigo.
Vamos começar com o Optimistic Rollup
O sistema que misturava ZK e Optimistic Rollup foi originalmente baseado no Optimistic Rollup baseado na arquitetura Bedrock do Optimism. O Bedrock foi projetado para ser compatível ao máximo ("equivalente a EVM") com Ethereum, executando um cliente de execução quase idêntico ao cliente Ethereum. A Bedrock aproveita o próximo modelo de divisão de cliente de consenso/execução da Ethereum, reduzindo significativamente a variação do EVM (é claro que sempre haverá algumas mudanças ao longo do caminho, mas podemos lidar com isso).
Como todos os bons Rollups, o Optimism extrai dados de bloco/transação do Ethereum, então classifica esses dados de alguma forma determinística no cliente de consenso e alimenta esses dados para o cliente de execução L2 para execução. Essa arquitetura resolve a primeira metade do quebra-cabeça do "rollup ideal" e nos dá um L2 equivalente ao EVM.
Claro, o problema que ainda precisamos resolver agora é contar ao Ethereum o que aconteceu dentro do Optimism de uma forma verificável. Se esse problema não for resolvido, os contratos inteligentes não podem tomar decisões com base no estado de Otimismo. Isso significa que os usuários podem depositar no Optimism, mas não podem sacar seus ativos. Embora o rollup unidirecional seja possível em alguns casos, na maioria dos casos, o rollup bidirecional é mais eficaz.
Ao fornecer algum tipo de compromisso com esse estado e provar que esse compromisso está correto, podemos comunicar o estado de todos os Rollups ao Ethereum. Em outras palavras, estamos provando que o "programa Rollup" foi executado corretamente. A única diferença substancial entre o ZK e o Optimistic Rollups é a forma desta prova. No ZK Rollup, você precisa fornecer uma prova explícita de conhecimento zero para provar a execução correta do programa. No Optimistic Rollup, você pode fazer uma declaração sobre a promessa sem fornecer evidências claras. Ao desafiar e questionar sua declaração, outros usuários podem forçá-lo a participar de um "jogo" de deliberação e desafio para determinar quem é o sim.
Não vou entrar em detalhes sobre os desafios do Optimistic Rollup. Vale a pena notar que o estado da arte neste estágio é compilar seu programa (Get EVM + alguns bits marginais no caso do Optimism) para alguma arquitetura de máquina simples como o MIPS. Fazemos isso porque precisamos construir um interpretador de 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 não EVM lá também).
Depois de construir um interpretador on-chain para sua arquitetura de máquina simples e criar algumas ferramentas offline, você deve ter um Rollup Optimistic totalmente funcional.
Vire para ZK Rollup
No geral, acredito firmemente que o Optimistic Rollups dominará os próximos anos. Algumas pessoas pensam que o ZK Rollups acabará superando o Optimistic Rollups, mas eu não concordo com essa visão. Sinto que a atual relativa simplicidade e flexibilidade dos Optimistic Rollups significa que eles podem ser gradualmente transformados em ZK Rollups. Se pudermos encontrar um padrão para fazer essa transição, em vez de tentar construir um ecossistema ZK mais inflexível e frágil, podemos simplesmente implantar em um ecossistema Optimistic Rollup já existente.
Meu objetivo, portanto, é criar uma arquitetura e um caminho de migração que permita que um ecossistema OP moderno existente (como Bedrock) faça a transição perfeita para um ecossistema ZK. Acredito que isso não seja apenas possível, mas uma maneira de ir além da abordagem atual do zkEVM.
Vamos começar com a arquitetura Bedrock que descrevi anteriormente. Observe que expliquei (brevemente) que Bedrock tem um jogo de desafio para verificar a validade de certas execuções de programas L2 (programas MIPS executando o EVM + algumas coisas extras). Uma grande desvantagem dessa abordagem é que precisamos permitir um período de tempo para que os usuários tenham a chance de detectar e contestar com sucesso uma proposta de resultado de programa errada. Isso adiciona uma quantidade considerável de tempo ao processo de retirada de ativos (7 dias na rede principal atual do Optimism).
Porém, nosso L2 nada mais é do que um programa rodando em uma máquina simples como o MIPS. É perfeitamente possível construirmos um circuito ZK para um mecanismo 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. É tão simples na prática.
Por que esse método é confiável?
Apenas um esclarecimento rápido: embora nesta seção eu mencione "zkMIPS", na verdade quero dizer isso como um termo para todas as máquinas virtuais à prova de conhecimento zero gerais e simplificadas (zkVM).
zkMIPS é mais fácil que zkEVM
Construir um zkMIPS (ou qualquer outro tipo de máquina virtual zk) tem uma grande vantagem sobre o zkEVM: a arquitetura da máquina de destino é simples e estática. O EVM muda com frequência, os preços do gás se ajustam, os opcodes mudam e os elementos são adicionados ou removidos. E o MIPS-V não mudou desde 1996. Concentre-se no zkMIPS e você estará lidando com um espaço de problema fixo. Você não precisa alterar ou mesmo reauditar seu circuito toda vez que o EVM for atualizado.
zkMIPS é mais flexível que zkEVM
Outro insight importante é que o zkMIPS é mais flexível que o zkEVM. Com o zkMIPS, você pode alterar o código do cliente à vontade, realizar várias otimizações ou melhorar a experiência do usuário sem atualizações de circuito correspondentes. Você pode até criar um componente central que transforma qualquer blockchain em um ZK Rollup, não apenas Ethereum.
Sua missão se transforma em prova de tempo
O tempo das provas de conhecimento zero escala ao longo de dois eixos: o número de restrições e o 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.
No entanto, reduzir os tempos de prova também é um problema profundamente enraizado no domínio Web2. Dado que é improvável que a arquitetura da máquina MIPS mude tão cedo, podemos otimizar altamente o circuito e o provador, independentemente de futuras alterações no EVM. Sinto-me bastante confiante em contratar um engenheiro de hardware sênior para otimizar um problema bem definido, talvez dez ou até cem vezes o número de engenheiros que criam e revisam um alvo zkEVM em movimento. Uma empresa como a Netflix provavelmente tem um grande número de engenheiros de hardware otimizando chips de transcodificação, e eles provavelmente estão dispostos a gastar um monte de fundos de capital de risco para enfrentar esse interessante desafio ZK.
O tempo de prova inicial para um circuito como este 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 significativamente 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 Otimismo de 7 dias, e podemos iniciar o processo de desafio para considerar a remoção do Otimismo. Executar um provador por 7 dias provavelmente ainda é muito caro, então podemos esperar um pouco mais, mas o ponto é sustentável. Você pode até executar os dois sistemas de prova ao mesmo tempo, para que possamos começar a usar as provas ZK o mais rápido possível e retornar às provas do Otimismo se o provador falhar por qualquer motivo. Depois de prontas, as provas do Optimism podem ser removidas de forma totalmente transparente para o aplicativo, de forma que seu Rollup Optimistic se torne um ZK Rollup.
Você pode cuidar de outras questões importantes
Executar um blockchain é um problema complexo que envolve mais do que apenas escrever muito código de back-end. Na Optimism, muito do nosso trabalho é focado em melhorar a experiência do usuário e do desenvolvedor, fornecendo ferramentas úteis do lado do cliente. Também dedicamos muito tempo e energia às questões "suaves": conversar com os projetos, entender seus pontos problemáticos e criar incentivos. Quanto mais tempo você gasta em software de cadeia, menos tempo você tem para lidar com essas outras coisas. Embora você sempre possa tentar contratar mais pessoas, as organizações não escalam linearmente e cada nova contratação aumenta os custos de comunicação interna.
Como o trabalho do circuito de conhecimento zero pode ser aplicado diretamente à cadeia que já está em execução, você pode construir a plataforma principal e desenvolver o software de prova ao mesmo tempo. Como o cliente pode ser modificado sem alterar o circuito, você pode desacoplar seu cliente e a equipe de prova. Um Rollup otimista dessa maneira pode estar anos à frente dos concorrentes de conhecimento zero em termos de atividade real na cadeia.
para concluir
Francamente, não vejo nenhuma desvantagem significativa no provador zkMIPS, a menos que não possa ser otimizado significativamente ao longo do tempo. O único impacto real que vejo no aplicativo é que o custo do gás de diferentes opcodes pode precisar ser ajustado para refletir o aumento do tempo de prova para esses opcodes. Se realmente não for possível otimizar este provador a um nível razoável, admito que falhei. Mas se for possível otimizar este provador, então a abordagem zkMIPS/zkVM pode substituir completamente a atual abordagem zkEVM. Isso pode soar como uma afirmação radical, mas não faz muito tempo, as provas de falha otimistas de uma etapa foram completamente substituídas por provas de várias etapas.
link original