As blockchains são registos distribuídos globalmente que chegam a um consenso sobre um estado global. Algumas blockchains vêm equipadas com um ambiente de execução Turing-completo que permite a programabilidade em cima deste estado global. Programas que visam os ambientes de execução das blockchains são chamados contratos inteligentes, e as blockchains subjacentes são chamadas plataformas de contratos inteligentes. Ethereum, Solana e Avalanche são algumas das plataformas de contratos inteligentes mais conhecidas. Podemos pensar nas plataformas de contratos inteligentes como computadores distribuídos, com o ambiente de execução (ou máquina virtual) atuando como a CPU e o estado desempenhando o papel de armazenamento.
Esta moldura de blockchains como computadores será importante para motivar por que coprocessadores/computação fora da cadeia é inevitável, especialmente no contexto de blockchains. Na computação tradicional, os coprocessadores originaram-se na microarquitetura para melhorar o desempenho. Da mesma forma, os coprocessadores na Ethereum prometem acesso a dados históricos e computação fora da cadeia de alto desempenho para aumentar as funcionalidades e o espaço de design do protocolo da camada base. Dê uma olhada neste artigo introdutório sobre coprocessadores para mais informações.
Este artigo explora coprocessadores a partir de primeiros princípios, com o objetivo de esclarecer a sua importância e metapropriedades. Em seguida, comparamo-los com rollups, demonstrando como estes dois conceitos, embora diferentes, estão intimamente relacionados. Também fornecemos exemplos de quando rollups e coprocessadores podem ser usados em conjunto. Por exemplo, mesmo um rollup ou L1 todo-poderoso pode precisar de um coprocessador para tarefas mais pesadas.
Concluímos este artigo observando que as blockchains estão a caminhar para um futuro onde a computação é centralizada, mas a verificação permanece descentralizada. Rollups, coprocessadores e qualquer outra forma de computação verificável fora da cadeia são apenas diferentes instantâneos deste futuro.
Em “Os Limites da Escalabilidade da Blockchain”, Vitalik mencionou que, para a descentralização da blockchain, é importante que os utilizadores regulares possam executar um nó.
Como mencionado anteriormente, o Ethereum pode ser conceitualizado como um computador global descentralizado em muitos aspectos. É uma rede de nós que executam software que fornece recursos computacionais para a execução de contratos inteligentes. A blockchain do Ethereum armazena informações de estado e código, semelhante ao armazenamento e memória de um computador. E a Máquina Virtual Ethereum (EVM) é executada em cada nó, processando transações e executando código como uma CPU. No entanto, o Ethereum é sem permissão e descentralizado, usando consenso entre nós não confiáveis. Se alguns nós ficarem offline, a rede continuará operando. Para garantir a correção das operações da EVM, os validadores em redes de Prova de Participação (PoS) como o Ethereum devem realizar todas as transições de estado para verificá-las. Isso limita a velocidade de uma rede PoS aos seus nós mais lentos, limitando a quantidade de computação que os desenvolvedores de aplicativos têm disponível para eles.
Ao contrário de um computador regular, o Ethereum limita a computação e o armazenamento para evitar abusos na rede. São cobradas taxas por cada operação, tornando os loops infinitos financeiramente impraticáveis. Esta abordagem mantém as barreiras de entrada baixas, permitindo que hardware do dia a dia como um Raspberry Pi execute nós de rede. As restrições permitem um sistema inclusivo onde qualquer pessoa pode ajudar a operar a rede descentralizada do Ethereum.
Devido a essas restrições computacionais dos nós do Ethereum, aplicações complexas como modelos de Aprendizagem de Máquina, jogos ou aplicações de computação científica não podem ser executadas de forma viável diretamente no Ethereum hoje.
É um compromisso para tornar o Ethereum amplamente acessível, seguro e sustentável como base para aplicativos básicos. Mas inevitavelmente, existem algumas limitações em relação a um computador computacionalmente irrestrito. Ele tem limitações quando comparado até mesmo a um processador antigo como um Pentium 5:
Sem matemática de ponto flutuante complexa - A EVM suporta apenas operações matemáticas básicas e lógicas. Computações numéricas avançadas como redes neurais não são viáveis. (Um detalhe interessante é a incapacidade de lidar com ponto flutuante também tornou a troca de ativos de rebase como Ampleforth, etc, mais difícil na história recente e às vezes até incompatível com alguns DEXs).
Computação limitada por bloco - As taxas de gás medem as computações, portanto, software complexo como jogos seria proibitivamente caro. O limite de gás por bloco é de 30M de gás.
Memória restrita - Os contratos inteligentes têm limites de armazenamento permanente pequenos, tornando os programas grandes difíceis.
Sem armazenamento de arquivo persistente - Não há maneira de armazenar arquivos como gráficos, áudio ou vídeo na blockchain.
Velocidade lenta - As velocidades de transação no Ethereum atualmente são de cerca de 15 TPS, muitas ordens de magnitude mais lentas do que uma CPU.
No final, o armazenamento e o cálculo limitados restringem os graus de liberdade disponíveis para aplicativos (esses limites diferem de blockchain para blockchain, mas eles sempre existem). As pessoas compararam blockchains aos ambientes de cálculo restritos dos anos 1970-1980, mas pensamos que existem algumas diferenças significativas entre os dois:
O crescimento da computação nas décadas de 1970-1980 foi rápido (com a contagem de transístores em microprocessadores passando de ~1.000 para ~1.000.000 durante esse período). Mas esse crescimento não significava que as pessoas frequentemente compravam ou atualizavam seus computadores. Uma vez que as plataformas de contratos inteligentes são limitadas pelos seus nós mais lentos, uma aceleração na vanguarda dos computadores não levará necessariamente a blockchains a verem um aumento proporcional na velocidade computacional. Uma aceleração só pode acontecer se os requisitos básicos para os nós na blockchain forem atualizados.
Existe também um claro compromisso entre a atualização constante dos requisitos mínimos de hardware para os nós e a descentralização. Os stakers individuais podem não querer atualizar o hardware a cada dois anos (e certamente não querem monitorar o desempenho diariamente), o que leva apenas os profissionais a quererem executar a infraestrutura de blockchain.
Tudo isto para dizer que, ao longo dos anos, as CPUs melhoraram e obtivemos mais núcleos de CPU em todos os dispositivos para nos permitir realizar tarefas progressivamente complicadas. Se pensarmos que os computadores blockchain não irão acelerar tão rapidamente quanto a computação tradicional (devido aos requisitos básicos dos nós), então faz sentido tentar encontrar fontes alternativas de computação. Uma analogia interessante a fazer aqui é que as CPUs na computação tradicional não se saíram bem em tarefas de processamento gráfico, levando ao surgimento das GPUs em quase todos os computadores. Da mesma forma, uma vez que as blockchains se concentram em ser armazenamentos seguros de estado com baterias de computação simples ativadas, há uma clara oportunidade para a computação off-chain expandir o espaço de design de aplicações. Atualmente, as blockchains só fazem sentido para aplicações de baixa computação que desejam propriedades como acesso aberto, auto-soberania, resistência à censura e composabilidade. Para colocar uma maior variedade de aplicações onchain, precisamos levantar as restrições que impomos aos desenvolvedores de aplicativos. Dizemos isto com a compreensão de que essas restrições também foram uma bênção para a experimentação. Por exemplo, CLOBs não podiam ser executados efetivamente no Ethereum devido às restrições de computação, então os AMMs foram adotados, tendo desde então atingido um volume de trilhões de dólares.
Existem duas abordagens comuns para disponibilizar mais capacidade de cálculo para aplicações blockchain:
Aumentar frequentemente os requisitos básicos do nó. Este é aproximadamente o caminho integrado por blockchains de alto desempenho como Solana e Sui. Um alto valor de referência para os nós torna possível construir uma blockchain muito rápida e também levanta algumas restrições de design do design de aplicativos. Phoenix, uma DEX de Livro de Ordens Limitada na Solana, não poderia ser construída hoje no Ethereum (ou em qualquer L2). O reverso de aumentar os requisitos básicos é que, se eles crescem constantemente, então a execução de nós pode ser viável apenas para provedores de infraestrutura profissionais. Os requisitos históricos de RAM fazem um bom trabalho ao mostrar como os requisitos de hardware cresceram consistentemente na Solana:
Arquivo da Web (Nota: utilizamos os requisitos médios de RAM de 2020)
Mover o cálculo para fora da cadeia para terceiros. Esta tem sido a estratégia adotada pelo ecossistema Ethereum. Esses terceiros podem ser eles próprios blockchains (no caso de rollups), dispositivos de cálculo verificáveis fora da cadeia (ou seja, coprocessadores) ou terceiros de confiança (como é o caso do cálculo fora da cadeia específico da aplicação, como o orderbook da dydx).
Rumo à Unificação da Computação Fora da Cadeia
Recentemente, tem havido um aumento de conversas sobre coprocessadores, que fornecem cálculos verificáveis fora da cadeia. Os coprocessadores podem ser implementados de várias maneiras, incluindo, mas não se limitando a Provas de Conhecimento Zero ou Ambientes de Execução Confiáveis (TEEs). Alguns exemplos são:
coprocessadores ZK: Axiom, Bonsai da Risc Zero.
TEEs: Ostra do Marlin,
Simultaneamente, quando se trata de descarregar cálculos, o roadmap centrado em rollup da Ethereum transfere cálculos para vários rollups que se liquidam na Ethereum. Nos últimos anos, uma corrente constante de programadores e utilizadores tem migrado para rollups devido a uma combinação de transações mais baratas e rápidas e incentivos fornecidos pelos rollups. Num mundo ideal, os rollups permitem à Ethereum aumentar a sua capacidade computacional global através de execução off-chain sem adicionar pressupostos de confiança. Mais cálculos não se referem apenas à execução de mais transações, mas também a realizar mais cálculos expressivos por transação. Novos tipos de transações expandem o espaço de design disponível para aplicações, e uma maior capacidade reduz o custo de realizar estas transações expressivas, assegurando acesso acessível a uma classe superior de aplicações.
Antes de prosseguirmos, vamos definir brevemente os rollups e os coprocessadores para evitar confusões:
Rollups: Os Rollups mantêm um estado persistente e particionado diferente das suas cadeias base/anfitriãs, mas ainda herdam as propriedades de segurança da sua base ao publicar dados/provas nela. Ao mover o estado da cadeia anfitriã, os rollups podem utilizar recursos adicionais para realizar transições de estado antes de publicar provas de integridade dessas transições de estado na cadeia anfitriã. Os rollups são mais úteis para os utilizadores que não querem pagar as altas taxas do Ethereum, mas querem aceder às propriedades de segurança do Ethereum.
Antes de mergulharmos nos coprocessadores, vamos dar mais algum contexto sobre o quão limitado é o desenvolvimento de contratos inteligentes na Ethereum hoje. A Ethereum tem armazenamento de estado persistente em seu estado global - saldos de contas, dados de contratos, etc. Estes dados persistem indefinidamente na blockchain. No entanto, existem limitações:
O tamanho máximo dos dados do contrato é limitado (por exemplo, 24KB por contrato atualmente e foi definido no EIP 170). Armazenar arquivos grandes excederia isso. (*Não resolvido também pelos coprocessadores)
Ler/escrever armazenamento de contratos é mais lento do que um sistema de ficheiros ou base de dados. Acesso a 1KB de dados pode custar milhões de gas.
Enquanto o estado global persistir, os nós individuais apenas retêm o estado recente localmente no modo de "poda". A história completa do estado requer um nó de arquivo.
Não existem primitivas de sistema de ficheiros nativas para lidar com ficheiros como imagens, áudio e documentos. Os contratos inteligentes só podem ler/escrever tipos de dados básicos para armazenamento.
As soluções em torno disso são:
Ficheiros grandes podem ser divididos em partes mais pequenas para caber nos limites de armazenamento do contrato.
As referências de ficheiros podem ser armazenadas on-chain, com os ficheiros armazenados off-chain em sistemas como o IPFS.
Coprocessadores: Os coprocessadores não mantêm nenhum estado por si mesmos; eles comportam-se como funções lambda na AWS, onde as aplicações podem enviar uma tarefa de computação para eles, e eles enviam de volta o resultado com prova de computação. Os coprocessadores aumentam fundamentalmente a quantidade de computação disponível para qualquer transação, mas uma vez que a prova nos coprocessadores também acontece numa base por transação, usá-los será mais caro do que os rollups. Dado o custo, é provável que os coprocessadores sejam úteis para protocolos ou utilizadores que queiram realizar tarefas complexas pontuais de uma forma verificável. Outro benefício dos coprocessadores é que permitem que as aplicações que usam computação off-chain também acedam ao estado histórico completo do Ethereum sem adicionar quaisquer pressupostos de confiança à própria aplicação; isto não é possível num contrato inteligente padrão hoje em dia.
Para destacar a diferença entre rollups e coprocessadores, vamos referir os sabores ZK de ambos estes primitivos. Os rollups ZK têm acesso tanto à verificabilidade como ao aspecto de compressão das provas de conhecimento-zero, permitindo-lhes aumentar fundamentalmente o débito para o seu ecossistema. Por outro lado, os coprocessadores apenas têm acesso à propriedade de verificabilidade das provas zk, o que significa que o débito geral do sistema permanece o mesmo. Além disso, os rollups ZK requerem circuitos que possam provar qualquer programa que tenha como alvo a máquina virtual para esse rollup (por exemplo, os rollups no Ethereum têm zkEVMs incorporados para contratos que têm como alvo o EVM). Em contraste, os coprocessadores ZK apenas precisam de construir circuitos para as tarefas que foram incumbidos de executar.
Portanto, parece que as duas maiores diferenças entre rollups e coprocessores são:
Os Rollups mantêm um estado persistente particionado, e os coprocessadores não (eles utilizam o estado da cadeia hospedeira).
Rollups (como o nome sugere) agrupam várias transações juntas e os coprocessadores são geralmente usados para tarefas complicadas como parte de uma única transação (pelo menos no paradigma atual).
Recentemente, foram propostos Booster Rollups, que executam transações como se estivessem a ser executadas diretamente na cadeia principal, com acesso ao estado completo do host. No entanto, os Booster Rollups também têm o seu próprio armazenamento, permitindo-lhes dimensionar a computação e o armazenamento em ambas as cadeias, o host e o rollup. A proposta do Booster Rollup aponta para a existência de um espectro no design de computação fora da cadeia, com rollups tradicionais e coprocessadores a ocupar cada extremo deste espectro. Rollups, Booster Rollups e Coprocessadores fornecem todos acesso a mais computação e diferem apenas na quantidade de estado que mantêm separado da sua base L1.
Numa palestra na Cimeira Modular, em 2023, intitulada 'Transações Protegidas são Rollups', Henry De Valence falou sobre este conceito exato e apresentou uma imagem muito simples para definir um rollup:
A palestra postula que qualquer execução descarregada pela cadeia base para um terceiro é um rollup. Segundo a sua definição, os coprocessadores também seriam rollups. Isto difere ligeiramente da nossa visão de unificar rollups e coprocessadores sob a égide de cálculos verificáveis fora da cadeia, mas o sentimento geral permanece o mesmo!
Na sua visão de Endgame, Vitalik discute um futuro em que a produção de blocos é centralizada e a validação de blocos é sem confiança e altamente descentralizada. Acreditamos que este é aproximadamente o modelo correto para pensar sobre o que está a acontecer agora. Num zk-rollup, a produção de blocos e a computação de transições de estado são centralizadas. No entanto, as provas permitem que a verificação seja barata e descentralizada. Da mesma forma, um coprocessador zk não tem produção de blocos; apenas acede a dados históricos e calcula transições de estado sobre esses dados. A computação num coprocessador zk provavelmente será sempre realizada numa máquina centralizada; no entanto, a prova de validade devolvida juntamente com um resultado permite a qualquer pessoa verificar os resultados antes de os utilizar. Talvez seja correto reformular a visão de Vitalik como: 'um futuro onde a computação é centralizada, mas a verificação da computação centralizada é sem confiança e altamente descentralizada.'
Apesar das suas semelhanças gerais, os rollups e os coprocessadores servem mercados muito diferentes hoje. Alguém poderia perguntar: "Se podemos simplesmente usar um coprocessador na ETH L1 e aceder à sua liquidez, por que precisamos de rollups?" embora esta seja uma pergunta legítima, pensamos que existem algumas razões pelas quais os rollups ainda fazem sentido (e representam uma oportunidade de mercado muito maior do que os coprocessadores hoje):
Como mencionado anteriormente, os coprocessadores permitem-lhe aceder a mais capacidade de cálculo na mesma transação do que o L1. Mas não conseguem ajudar a aumentar a quantidade de transações que podem ser realizadas pela blockchain que está a chamar o coprocessador (se estiver a pensar em lotes, voilà, chegou a um rollup). Ao manter um estado persistente particionado, os rollups podem aumentar o número de transações disponíveis para as pessoas que pretendem aceder ao bloco com as propriedades de segurança do Ethereum. Isto é possível porque os rollups apenas publicam no Ethereum a cada n blocos e não exigem que todos os validadores do Ethereum verifiquem que ocorreu uma transição de estado. As partes interessadas podem apenas confiar na prova.
Mesmo que você use coprocessadores, ainda terá que pagar a mesma ordem de grandeza de taxas que qualquer outra transação na L1. Por outro lado, as rollups via batching podem reduzir os custos em ordens de grandeza.
Além disso, uma vez que os rollups permitem a execução de transações neste estado separado, eles ainda se comportam como blockchains (blockchains mais rápidas e menos descentralizadas, mas blockchains, no entanto), então, também, têm limites claros sobre quanto cálculo pode ser acedido a partir do próprio rollup. Neste cenário, um coprocessador pode ser útil para os rollups se um utilizador quiser realizar transações arbitrariamente complexas (e agora está a fazer transações verificáveis num rollup, por isso só tem de obedecer às leis da física do rollup).
Outro ponto importante a notar é que a maior parte da liquidez hoje reside na ETH L1, então para muitos protocolos que dependem da liquidez para melhorar seus produtos, pode ser astuto lançar ainda na mainnet Ethereum. Uma aplicação na mainnet Ethereum pode ter acesso a mais computação ao fazer transações intermitentemente em um coprocessador. Por exemplo, uma DEX como Ambient ou Uniswap v4 pode usar ganchos em conjunto com coprocessadores para fazer lógica complicada sobre como alterar taxas ou até mesmo modificar a forma da curva de liquidez com base em dados de mercado.
Uma analogia interessante compara a interação entre rollups e coprocessadores à programação imperativa e funcional. A programação imperativa foca em estados mutáveis e efeitos colaterais, especificando passo a passo como executar tarefas. A programação funcional enfatiza dados imutáveis e funções puras, evitando alterações de estado e efeitos colaterais. Da mesma forma, os rollups são como programas imperativos que modificam o estado que detêm, enquanto os coprocessadores são como programas funcionais que não mutam o estado, mas produzem um resultado juntamente com provas de computação. Além disso, assim como na programação imperativa e funcional, os rollups e coprocessadores têm o seu lugar e devem ser usados de acordo com a situação.
Se acabarmos num mundo onde a computação é centralizada, mas a verificação da computação centralizada é sem confiança e altamente descentralizada, o que acontecerá ao Ethereum? Será que o computador mundial se reduzirá a uma mera base de dados? Isto é algo mau?
Em última análise, o objetivo do Ethereum é dar aos seus usuários acesso a cálculos e armazenamento sem confiança. No passado, a única forma de aceder a cálculos sem confiança no Ethereum era que o cálculo fosse realizado e verificado por todos os nós. Com a progressão das técnicas de prova (especialmente provas de conhecimento zero), podemos transferir grande parte do cálculo que ocorreu nos nós validadores para cálculos fora da cadeia e apenas fazer com que os validadores verifiquem os resultados na cadeia. Isto transforma essencialmente o Ethereum num quadro de avisos imutável mundial. As provas de cálculo permitem-nos verificar se uma transação foi realizada corretamente e, ao publicá-las no Ethereum, obtemos um carimbo de data e uma loja histórica imutável para essas provas. À medida que as provas de conhecimento zero se tornam mais eficientes em cálculos arbitrários, é provável que, em algum momento, o custo de realizar cálculos em ZK seja significativamente inferior ao custo de realizá-los numa blockchain (talvez até numa cadeia CometBFT de 100 validadores). Nesse mundo, é difícil imaginar que as provas de ZK não se tornarão o modo dominante de acesso a cálculos sem confiança. Pensamentos semelhantes também foram recentemente ecoados por David Wong:
Um futuro em que qualquer computação possa ser provada também nos permite construir infraestruturas para os tipos de aplicações sem confiança que têm procura por parte dos utilizadores, em vez de tentar adaptar a camada base do Ethereum para se tornar o lar dessas aplicações. No caso ideal, uma infraestrutura personalizada criará experiências de utilizador mais fluidas e também escalará com as aplicações construídas em cima dela. Isso, esperançosamente, permitirá que as aplicações web3 concorram com os seus homólogos web2 e inaugurem o futuro sem confiança, baseado em provas, com que os cypherpunks sempre sonharam.
No geral, acreditamos que estamos caminhando para o seguinte paradigma:
————————————————————Não Confie, Verifique————————————————————-
As blockchains são registos distribuídos globalmente que chegam a um consenso sobre um estado global. Algumas blockchains vêm equipadas com um ambiente de execução Turing-completo que permite a programabilidade em cima deste estado global. Programas que visam os ambientes de execução das blockchains são chamados contratos inteligentes, e as blockchains subjacentes são chamadas plataformas de contratos inteligentes. Ethereum, Solana e Avalanche são algumas das plataformas de contratos inteligentes mais conhecidas. Podemos pensar nas plataformas de contratos inteligentes como computadores distribuídos, com o ambiente de execução (ou máquina virtual) atuando como a CPU e o estado desempenhando o papel de armazenamento.
Esta moldura de blockchains como computadores será importante para motivar por que coprocessadores/computação fora da cadeia é inevitável, especialmente no contexto de blockchains. Na computação tradicional, os coprocessadores originaram-se na microarquitetura para melhorar o desempenho. Da mesma forma, os coprocessadores na Ethereum prometem acesso a dados históricos e computação fora da cadeia de alto desempenho para aumentar as funcionalidades e o espaço de design do protocolo da camada base. Dê uma olhada neste artigo introdutório sobre coprocessadores para mais informações.
Este artigo explora coprocessadores a partir de primeiros princípios, com o objetivo de esclarecer a sua importância e metapropriedades. Em seguida, comparamo-los com rollups, demonstrando como estes dois conceitos, embora diferentes, estão intimamente relacionados. Também fornecemos exemplos de quando rollups e coprocessadores podem ser usados em conjunto. Por exemplo, mesmo um rollup ou L1 todo-poderoso pode precisar de um coprocessador para tarefas mais pesadas.
Concluímos este artigo observando que as blockchains estão a caminhar para um futuro onde a computação é centralizada, mas a verificação permanece descentralizada. Rollups, coprocessadores e qualquer outra forma de computação verificável fora da cadeia são apenas diferentes instantâneos deste futuro.
Em “Os Limites da Escalabilidade da Blockchain”, Vitalik mencionou que, para a descentralização da blockchain, é importante que os utilizadores regulares possam executar um nó.
Como mencionado anteriormente, o Ethereum pode ser conceitualizado como um computador global descentralizado em muitos aspectos. É uma rede de nós que executam software que fornece recursos computacionais para a execução de contratos inteligentes. A blockchain do Ethereum armazena informações de estado e código, semelhante ao armazenamento e memória de um computador. E a Máquina Virtual Ethereum (EVM) é executada em cada nó, processando transações e executando código como uma CPU. No entanto, o Ethereum é sem permissão e descentralizado, usando consenso entre nós não confiáveis. Se alguns nós ficarem offline, a rede continuará operando. Para garantir a correção das operações da EVM, os validadores em redes de Prova de Participação (PoS) como o Ethereum devem realizar todas as transições de estado para verificá-las. Isso limita a velocidade de uma rede PoS aos seus nós mais lentos, limitando a quantidade de computação que os desenvolvedores de aplicativos têm disponível para eles.
Ao contrário de um computador regular, o Ethereum limita a computação e o armazenamento para evitar abusos na rede. São cobradas taxas por cada operação, tornando os loops infinitos financeiramente impraticáveis. Esta abordagem mantém as barreiras de entrada baixas, permitindo que hardware do dia a dia como um Raspberry Pi execute nós de rede. As restrições permitem um sistema inclusivo onde qualquer pessoa pode ajudar a operar a rede descentralizada do Ethereum.
Devido a essas restrições computacionais dos nós do Ethereum, aplicações complexas como modelos de Aprendizagem de Máquina, jogos ou aplicações de computação científica não podem ser executadas de forma viável diretamente no Ethereum hoje.
É um compromisso para tornar o Ethereum amplamente acessível, seguro e sustentável como base para aplicativos básicos. Mas inevitavelmente, existem algumas limitações em relação a um computador computacionalmente irrestrito. Ele tem limitações quando comparado até mesmo a um processador antigo como um Pentium 5:
Sem matemática de ponto flutuante complexa - A EVM suporta apenas operações matemáticas básicas e lógicas. Computações numéricas avançadas como redes neurais não são viáveis. (Um detalhe interessante é a incapacidade de lidar com ponto flutuante também tornou a troca de ativos de rebase como Ampleforth, etc, mais difícil na história recente e às vezes até incompatível com alguns DEXs).
Computação limitada por bloco - As taxas de gás medem as computações, portanto, software complexo como jogos seria proibitivamente caro. O limite de gás por bloco é de 30M de gás.
Memória restrita - Os contratos inteligentes têm limites de armazenamento permanente pequenos, tornando os programas grandes difíceis.
Sem armazenamento de arquivo persistente - Não há maneira de armazenar arquivos como gráficos, áudio ou vídeo na blockchain.
Velocidade lenta - As velocidades de transação no Ethereum atualmente são de cerca de 15 TPS, muitas ordens de magnitude mais lentas do que uma CPU.
No final, o armazenamento e o cálculo limitados restringem os graus de liberdade disponíveis para aplicativos (esses limites diferem de blockchain para blockchain, mas eles sempre existem). As pessoas compararam blockchains aos ambientes de cálculo restritos dos anos 1970-1980, mas pensamos que existem algumas diferenças significativas entre os dois:
O crescimento da computação nas décadas de 1970-1980 foi rápido (com a contagem de transístores em microprocessadores passando de ~1.000 para ~1.000.000 durante esse período). Mas esse crescimento não significava que as pessoas frequentemente compravam ou atualizavam seus computadores. Uma vez que as plataformas de contratos inteligentes são limitadas pelos seus nós mais lentos, uma aceleração na vanguarda dos computadores não levará necessariamente a blockchains a verem um aumento proporcional na velocidade computacional. Uma aceleração só pode acontecer se os requisitos básicos para os nós na blockchain forem atualizados.
Existe também um claro compromisso entre a atualização constante dos requisitos mínimos de hardware para os nós e a descentralização. Os stakers individuais podem não querer atualizar o hardware a cada dois anos (e certamente não querem monitorar o desempenho diariamente), o que leva apenas os profissionais a quererem executar a infraestrutura de blockchain.
Tudo isto para dizer que, ao longo dos anos, as CPUs melhoraram e obtivemos mais núcleos de CPU em todos os dispositivos para nos permitir realizar tarefas progressivamente complicadas. Se pensarmos que os computadores blockchain não irão acelerar tão rapidamente quanto a computação tradicional (devido aos requisitos básicos dos nós), então faz sentido tentar encontrar fontes alternativas de computação. Uma analogia interessante a fazer aqui é que as CPUs na computação tradicional não se saíram bem em tarefas de processamento gráfico, levando ao surgimento das GPUs em quase todos os computadores. Da mesma forma, uma vez que as blockchains se concentram em ser armazenamentos seguros de estado com baterias de computação simples ativadas, há uma clara oportunidade para a computação off-chain expandir o espaço de design de aplicações. Atualmente, as blockchains só fazem sentido para aplicações de baixa computação que desejam propriedades como acesso aberto, auto-soberania, resistência à censura e composabilidade. Para colocar uma maior variedade de aplicações onchain, precisamos levantar as restrições que impomos aos desenvolvedores de aplicativos. Dizemos isto com a compreensão de que essas restrições também foram uma bênção para a experimentação. Por exemplo, CLOBs não podiam ser executados efetivamente no Ethereum devido às restrições de computação, então os AMMs foram adotados, tendo desde então atingido um volume de trilhões de dólares.
Existem duas abordagens comuns para disponibilizar mais capacidade de cálculo para aplicações blockchain:
Aumentar frequentemente os requisitos básicos do nó. Este é aproximadamente o caminho integrado por blockchains de alto desempenho como Solana e Sui. Um alto valor de referência para os nós torna possível construir uma blockchain muito rápida e também levanta algumas restrições de design do design de aplicativos. Phoenix, uma DEX de Livro de Ordens Limitada na Solana, não poderia ser construída hoje no Ethereum (ou em qualquer L2). O reverso de aumentar os requisitos básicos é que, se eles crescem constantemente, então a execução de nós pode ser viável apenas para provedores de infraestrutura profissionais. Os requisitos históricos de RAM fazem um bom trabalho ao mostrar como os requisitos de hardware cresceram consistentemente na Solana:
Arquivo da Web (Nota: utilizamos os requisitos médios de RAM de 2020)
Mover o cálculo para fora da cadeia para terceiros. Esta tem sido a estratégia adotada pelo ecossistema Ethereum. Esses terceiros podem ser eles próprios blockchains (no caso de rollups), dispositivos de cálculo verificáveis fora da cadeia (ou seja, coprocessadores) ou terceiros de confiança (como é o caso do cálculo fora da cadeia específico da aplicação, como o orderbook da dydx).
Rumo à Unificação da Computação Fora da Cadeia
Recentemente, tem havido um aumento de conversas sobre coprocessadores, que fornecem cálculos verificáveis fora da cadeia. Os coprocessadores podem ser implementados de várias maneiras, incluindo, mas não se limitando a Provas de Conhecimento Zero ou Ambientes de Execução Confiáveis (TEEs). Alguns exemplos são:
coprocessadores ZK: Axiom, Bonsai da Risc Zero.
TEEs: Ostra do Marlin,
Simultaneamente, quando se trata de descarregar cálculos, o roadmap centrado em rollup da Ethereum transfere cálculos para vários rollups que se liquidam na Ethereum. Nos últimos anos, uma corrente constante de programadores e utilizadores tem migrado para rollups devido a uma combinação de transações mais baratas e rápidas e incentivos fornecidos pelos rollups. Num mundo ideal, os rollups permitem à Ethereum aumentar a sua capacidade computacional global através de execução off-chain sem adicionar pressupostos de confiança. Mais cálculos não se referem apenas à execução de mais transações, mas também a realizar mais cálculos expressivos por transação. Novos tipos de transações expandem o espaço de design disponível para aplicações, e uma maior capacidade reduz o custo de realizar estas transações expressivas, assegurando acesso acessível a uma classe superior de aplicações.
Antes de prosseguirmos, vamos definir brevemente os rollups e os coprocessadores para evitar confusões:
Rollups: Os Rollups mantêm um estado persistente e particionado diferente das suas cadeias base/anfitriãs, mas ainda herdam as propriedades de segurança da sua base ao publicar dados/provas nela. Ao mover o estado da cadeia anfitriã, os rollups podem utilizar recursos adicionais para realizar transições de estado antes de publicar provas de integridade dessas transições de estado na cadeia anfitriã. Os rollups são mais úteis para os utilizadores que não querem pagar as altas taxas do Ethereum, mas querem aceder às propriedades de segurança do Ethereum.
Antes de mergulharmos nos coprocessadores, vamos dar mais algum contexto sobre o quão limitado é o desenvolvimento de contratos inteligentes na Ethereum hoje. A Ethereum tem armazenamento de estado persistente em seu estado global - saldos de contas, dados de contratos, etc. Estes dados persistem indefinidamente na blockchain. No entanto, existem limitações:
O tamanho máximo dos dados do contrato é limitado (por exemplo, 24KB por contrato atualmente e foi definido no EIP 170). Armazenar arquivos grandes excederia isso. (*Não resolvido também pelos coprocessadores)
Ler/escrever armazenamento de contratos é mais lento do que um sistema de ficheiros ou base de dados. Acesso a 1KB de dados pode custar milhões de gas.
Enquanto o estado global persistir, os nós individuais apenas retêm o estado recente localmente no modo de "poda". A história completa do estado requer um nó de arquivo.
Não existem primitivas de sistema de ficheiros nativas para lidar com ficheiros como imagens, áudio e documentos. Os contratos inteligentes só podem ler/escrever tipos de dados básicos para armazenamento.
As soluções em torno disso são:
Ficheiros grandes podem ser divididos em partes mais pequenas para caber nos limites de armazenamento do contrato.
As referências de ficheiros podem ser armazenadas on-chain, com os ficheiros armazenados off-chain em sistemas como o IPFS.
Coprocessadores: Os coprocessadores não mantêm nenhum estado por si mesmos; eles comportam-se como funções lambda na AWS, onde as aplicações podem enviar uma tarefa de computação para eles, e eles enviam de volta o resultado com prova de computação. Os coprocessadores aumentam fundamentalmente a quantidade de computação disponível para qualquer transação, mas uma vez que a prova nos coprocessadores também acontece numa base por transação, usá-los será mais caro do que os rollups. Dado o custo, é provável que os coprocessadores sejam úteis para protocolos ou utilizadores que queiram realizar tarefas complexas pontuais de uma forma verificável. Outro benefício dos coprocessadores é que permitem que as aplicações que usam computação off-chain também acedam ao estado histórico completo do Ethereum sem adicionar quaisquer pressupostos de confiança à própria aplicação; isto não é possível num contrato inteligente padrão hoje em dia.
Para destacar a diferença entre rollups e coprocessadores, vamos referir os sabores ZK de ambos estes primitivos. Os rollups ZK têm acesso tanto à verificabilidade como ao aspecto de compressão das provas de conhecimento-zero, permitindo-lhes aumentar fundamentalmente o débito para o seu ecossistema. Por outro lado, os coprocessadores apenas têm acesso à propriedade de verificabilidade das provas zk, o que significa que o débito geral do sistema permanece o mesmo. Além disso, os rollups ZK requerem circuitos que possam provar qualquer programa que tenha como alvo a máquina virtual para esse rollup (por exemplo, os rollups no Ethereum têm zkEVMs incorporados para contratos que têm como alvo o EVM). Em contraste, os coprocessadores ZK apenas precisam de construir circuitos para as tarefas que foram incumbidos de executar.
Portanto, parece que as duas maiores diferenças entre rollups e coprocessores são:
Os Rollups mantêm um estado persistente particionado, e os coprocessadores não (eles utilizam o estado da cadeia hospedeira).
Rollups (como o nome sugere) agrupam várias transações juntas e os coprocessadores são geralmente usados para tarefas complicadas como parte de uma única transação (pelo menos no paradigma atual).
Recentemente, foram propostos Booster Rollups, que executam transações como se estivessem a ser executadas diretamente na cadeia principal, com acesso ao estado completo do host. No entanto, os Booster Rollups também têm o seu próprio armazenamento, permitindo-lhes dimensionar a computação e o armazenamento em ambas as cadeias, o host e o rollup. A proposta do Booster Rollup aponta para a existência de um espectro no design de computação fora da cadeia, com rollups tradicionais e coprocessadores a ocupar cada extremo deste espectro. Rollups, Booster Rollups e Coprocessadores fornecem todos acesso a mais computação e diferem apenas na quantidade de estado que mantêm separado da sua base L1.
Numa palestra na Cimeira Modular, em 2023, intitulada 'Transações Protegidas são Rollups', Henry De Valence falou sobre este conceito exato e apresentou uma imagem muito simples para definir um rollup:
A palestra postula que qualquer execução descarregada pela cadeia base para um terceiro é um rollup. Segundo a sua definição, os coprocessadores também seriam rollups. Isto difere ligeiramente da nossa visão de unificar rollups e coprocessadores sob a égide de cálculos verificáveis fora da cadeia, mas o sentimento geral permanece o mesmo!
Na sua visão de Endgame, Vitalik discute um futuro em que a produção de blocos é centralizada e a validação de blocos é sem confiança e altamente descentralizada. Acreditamos que este é aproximadamente o modelo correto para pensar sobre o que está a acontecer agora. Num zk-rollup, a produção de blocos e a computação de transições de estado são centralizadas. No entanto, as provas permitem que a verificação seja barata e descentralizada. Da mesma forma, um coprocessador zk não tem produção de blocos; apenas acede a dados históricos e calcula transições de estado sobre esses dados. A computação num coprocessador zk provavelmente será sempre realizada numa máquina centralizada; no entanto, a prova de validade devolvida juntamente com um resultado permite a qualquer pessoa verificar os resultados antes de os utilizar. Talvez seja correto reformular a visão de Vitalik como: 'um futuro onde a computação é centralizada, mas a verificação da computação centralizada é sem confiança e altamente descentralizada.'
Apesar das suas semelhanças gerais, os rollups e os coprocessadores servem mercados muito diferentes hoje. Alguém poderia perguntar: "Se podemos simplesmente usar um coprocessador na ETH L1 e aceder à sua liquidez, por que precisamos de rollups?" embora esta seja uma pergunta legítima, pensamos que existem algumas razões pelas quais os rollups ainda fazem sentido (e representam uma oportunidade de mercado muito maior do que os coprocessadores hoje):
Como mencionado anteriormente, os coprocessadores permitem-lhe aceder a mais capacidade de cálculo na mesma transação do que o L1. Mas não conseguem ajudar a aumentar a quantidade de transações que podem ser realizadas pela blockchain que está a chamar o coprocessador (se estiver a pensar em lotes, voilà, chegou a um rollup). Ao manter um estado persistente particionado, os rollups podem aumentar o número de transações disponíveis para as pessoas que pretendem aceder ao bloco com as propriedades de segurança do Ethereum. Isto é possível porque os rollups apenas publicam no Ethereum a cada n blocos e não exigem que todos os validadores do Ethereum verifiquem que ocorreu uma transição de estado. As partes interessadas podem apenas confiar na prova.
Mesmo que você use coprocessadores, ainda terá que pagar a mesma ordem de grandeza de taxas que qualquer outra transação na L1. Por outro lado, as rollups via batching podem reduzir os custos em ordens de grandeza.
Além disso, uma vez que os rollups permitem a execução de transações neste estado separado, eles ainda se comportam como blockchains (blockchains mais rápidas e menos descentralizadas, mas blockchains, no entanto), então, também, têm limites claros sobre quanto cálculo pode ser acedido a partir do próprio rollup. Neste cenário, um coprocessador pode ser útil para os rollups se um utilizador quiser realizar transações arbitrariamente complexas (e agora está a fazer transações verificáveis num rollup, por isso só tem de obedecer às leis da física do rollup).
Outro ponto importante a notar é que a maior parte da liquidez hoje reside na ETH L1, então para muitos protocolos que dependem da liquidez para melhorar seus produtos, pode ser astuto lançar ainda na mainnet Ethereum. Uma aplicação na mainnet Ethereum pode ter acesso a mais computação ao fazer transações intermitentemente em um coprocessador. Por exemplo, uma DEX como Ambient ou Uniswap v4 pode usar ganchos em conjunto com coprocessadores para fazer lógica complicada sobre como alterar taxas ou até mesmo modificar a forma da curva de liquidez com base em dados de mercado.
Uma analogia interessante compara a interação entre rollups e coprocessadores à programação imperativa e funcional. A programação imperativa foca em estados mutáveis e efeitos colaterais, especificando passo a passo como executar tarefas. A programação funcional enfatiza dados imutáveis e funções puras, evitando alterações de estado e efeitos colaterais. Da mesma forma, os rollups são como programas imperativos que modificam o estado que detêm, enquanto os coprocessadores são como programas funcionais que não mutam o estado, mas produzem um resultado juntamente com provas de computação. Além disso, assim como na programação imperativa e funcional, os rollups e coprocessadores têm o seu lugar e devem ser usados de acordo com a situação.
Se acabarmos num mundo onde a computação é centralizada, mas a verificação da computação centralizada é sem confiança e altamente descentralizada, o que acontecerá ao Ethereum? Será que o computador mundial se reduzirá a uma mera base de dados? Isto é algo mau?
Em última análise, o objetivo do Ethereum é dar aos seus usuários acesso a cálculos e armazenamento sem confiança. No passado, a única forma de aceder a cálculos sem confiança no Ethereum era que o cálculo fosse realizado e verificado por todos os nós. Com a progressão das técnicas de prova (especialmente provas de conhecimento zero), podemos transferir grande parte do cálculo que ocorreu nos nós validadores para cálculos fora da cadeia e apenas fazer com que os validadores verifiquem os resultados na cadeia. Isto transforma essencialmente o Ethereum num quadro de avisos imutável mundial. As provas de cálculo permitem-nos verificar se uma transação foi realizada corretamente e, ao publicá-las no Ethereum, obtemos um carimbo de data e uma loja histórica imutável para essas provas. À medida que as provas de conhecimento zero se tornam mais eficientes em cálculos arbitrários, é provável que, em algum momento, o custo de realizar cálculos em ZK seja significativamente inferior ao custo de realizá-los numa blockchain (talvez até numa cadeia CometBFT de 100 validadores). Nesse mundo, é difícil imaginar que as provas de ZK não se tornarão o modo dominante de acesso a cálculos sem confiança. Pensamentos semelhantes também foram recentemente ecoados por David Wong:
Um futuro em que qualquer computação possa ser provada também nos permite construir infraestruturas para os tipos de aplicações sem confiança que têm procura por parte dos utilizadores, em vez de tentar adaptar a camada base do Ethereum para se tornar o lar dessas aplicações. No caso ideal, uma infraestrutura personalizada criará experiências de utilizador mais fluidas e também escalará com as aplicações construídas em cima dela. Isso, esperançosamente, permitirá que as aplicações web3 concorram com os seus homólogos web2 e inaugurem o futuro sem confiança, baseado em provas, com que os cypherpunks sempre sonharam.
No geral, acreditamos que estamos caminhando para o seguinte paradigma:
————————————————————Não Confie, Verifique————————————————————-