À medida que o uso de Rollups aumenta e hospeda os aplicativos do ecossistema, os custos de migração para os usuários aumentarão e os compradores centralizados ganharão influência monopolista sobre os preços. Os controladores de pedidos centralizados têm justificativa para maximizar a extração de valor (MEV) dos usuários, tanto diretamente (por exemplo, por meio de taxas) quanto indiretamente (por exemplo, por meio de transações frontrunning, ataques sanduíche, etc.). — Expresso
Conforme mencionado pela equipe do Espresso, os Rollups centralizados eventualmente enfrentarão preços de monopólio e problemas de MEV. Além disso, Rollups centralizados quebram inerentemente a capacidade de composição, levando a Rollups fragmentados. **
No entanto, quase todos os Rollups atuais ainda são centralizados, porque construir um Rollup descentralizado, sem permissão e escalável é extremamente desafiador. Outro motivo é que o lançamento de Rollups centralizados primeiro pode ajudar a incubar o ecossistema e conquistar participação de mercado.
E quando discutimos Rollups descentralizados, especialmente zkRollups, existem dois níveis de descentralização. A primeira é a descentralização do provador e a segunda é a descentralização do ordenador. Para alcançar a descentralização completa, também é necessário resolver o problema de coordenação entre o ordenante e o provador.
Sob a tendência da modularização, existem atualmente três tipos principais de participantes no Rollup descentralizado. A primeira categoria visa alcançar Rollups totalmente descentralizados e propõe uma solução completa. A segunda categoria são os protocolos projetados para resolver redes provadoras. Finalmente, existem várias soluções que estão trabalhando para descentralizar o classificador.
Rollups descentralizados
Em zkRollups, Polygon e Starknet criaram soluções para descentralizar seus Rollups.
Polígono
Antes da introdução do POE (Prova de Eficiência), o Polygon zkEVM adotava o POD (Prova de Doação), permitindo que o classificador licitasse pela oportunidade de criar o próximo lote de transações. No entanto, isso cria o problema de que uma única parte maliciosa pode controlar toda a rede fazendo o lance mais alto.
Depois de adotar o POE, o solicitador e o provador participarão da rede sem permissão com mais eficiência sob suas próprias condições de hardware. Qualquer pessoa pode ingressar no Polygon zkEVM, desde que faça sentido econômico.
No Polygon zkEVM, o classificador requer 16 GB de RAM e uma CPU de 4 núcleos, enquanto o provador requer 1 TB de RAM e uma CPU de 128 núcleos. Além disso, existe um papel chamado agregador, que é responsável por coletar os dados do L1, enviá-los ao provador, receber a prova e enviá-los ao L1. Podemos considerar o agregador e o provador como o mesmo sujeito, porque a relação entre o agregador e o provador é muito simples, e o agregador paga ao provador para produzir a prova.
Essa arquitetura é muito simples: qualquer ordenador pode empacotar transações com base no estado anterior em L1 sem permissão e atualizar o estado correspondente. Ao mesmo tempo, qualquer agregador pode enviar uma prova para verificar o estado atualizado.
No POE, a eficiência refere-se não apenas à eficiência da rede dos participantes competindo entre si, mas também à eficiência econômica do sequenciador e do próprio provador. Em L2, o requisitante e o provador compartilham a taxa de transação, e o requisitante paga a batchFee ao agregador para gerar a prova. Isso garante que os participantes sejam economicamente motivados a contribuir para a eficiência da rede, resultando em um ecossistema mais robusto e sustentável.
classificador
Receita: taxas de transação L2
Custo: batchFee (calculado em $MATIC) + taxa de transação L1 (método call sequenceBatches)
Agregador (Provedor)
Rendimento: batchFee (calculado em $MATIC)
Custo: custo da prova + taxa de transação L1 (chame o método VerifyBatchesTrustedAggregator)
Coordenador: batchFee
parâmetro inicial
taxa de lote = 1 $MATIC
veryBatchTimeTarget = 30 minutos. Este é o tempo de destino para o lote de validação. O protocolo atualizará a variável batchFee para atingir esse tempo alvo.
multiplicadorBatchFee = 1002. Este é o multiplicador de taxa do lote, variando de 1000 a 1024, com 3 casas decimais.
Regulador
diffBatches : o número de lotes agregados > 30 minutos menos o número de lotes <= 30 minutos. O valor máximo é 12.
Processo de coordenação
Aumente a recompensa de agregação para incentivar os agregadores quando diffBatches > 0.
Quando diffBatches < 0, reduza a recompensa de agregação para suprimir o agregador e desacelerar o processo de agregação.
Starknet
A Starknet também pretende criar um Rollup escalonável e sem permissão de confirmação rápida. Embora a especificação final para a solução descentralizada ainda não tenha sido alcançada, eles publicaram alguns rascunhos no fórum há alguns meses.
Comparado com o mecanismo simples do Polygon zkEVM, o esquema de Starknet é mais complicado porque inclui consenso L2 e prova de protocolo encadeada na rede de prova.
classificador
Em vez de simplesmente adicionar uma camada de consenso dentro da camada do ordenador, a Starknet propõe um protocolo de consenso de ledger duplo. Neste protocolo, o L2 fornece uma resposta rápida como um protocolo ativo, enquanto os pontos de verificação L1 fornecem a confirmação final como um protocolo seguro.
Para o protocolo ao vivo do L2, vários mecanismos de consenso podem ser adotados, como sistemas PoS resistentes a Sybil, como Tendermint ou DAGs. Por outro lado, o protocolo seguro do L1 envolve vários contratos que lidam com o gerenciamento de Stake, verificação de provas e atualização de status, respectivamente.
O fluxo de trabalho típico do acordo de consenso de contabilidade dupla é o seguinte:
Primeiro, use a saída do ledger ativo L2 como entrada do ledger seguro L1 para gerar um ledger ativo verificado.
Em seguida, pegue o ledger ativo verificado como entrada e insira-o novamente no protocolo de consenso puro de L2 para garantir que o ledger ativo verificado seja sempre o prefixo do ledger ativo.
Repita o processo acima.
Ao criar um protocolo de consenso de contabilidade dupla, há uma compensação entre custo e latência. A solução ideal visa obter baixo custo e rápida aprovação final.
A fim de reduzir os custos de gás em L2, Starknet divide os pontos de verificação em "nível de minuto" e "nível de hora". Para pontos de verificação de "nível de minuto", apenas o próprio estado é confirmado na cadeia, enquanto o restante dos dados (provas de validade, disponibilidade de dados etc.) é enviado pela rede StarkNet L2. Esses dados são armazenados e verificados pelos nós completos da StarkNet. Por outro lado, os pontos de verificação "de hora em hora" são validados publicamente em L1. Ambos os tipos de pontos de verificação fornecem a mesma confirmação final. Para pontos de verificação de "nível de minuto", a prova de validade é verificada por nós completos StarkNet e pode ser emitida por qualquer nó em L1 para dar finalidade de L1 a pontos de verificação de "nível de minuto". Portanto, o provador precisa gerar pequenas provas para serem amplamente divulgadas na rede L2.
Para reduzir ainda mais a latência, a Starknet propõe um protocolo de eleição de líder para determinar o líder com antecedência. A lógica básica é a seguinte: o líder da época atual i é pré-determinado com base na quantidade de L1 apostado e em alguma aleatoriedade. Especificamente, na época i-2, o método leader_election agrupa os classificadores lexicograficamente com base na quantidade de promessas na época i-3. Em seguida, envie uma transação para atualizar o nonce e escolha um ponto aleatoriamente. O classificador correspondente à posição onde o ponto cai será o líder da época i.
Certificador
No módulo POE, há uma competição aberta entre os participantes, o que pode levar a uma situação de vencedor leva tudo. A Starknet tenta alcançar um mecanismo de competição sem risco de centralização. Aqui estão algumas opções:
Rotação: Isso pode resolver parcialmente o problema de centralização, mas pode não fornecer incentivos para encontrar a melhor pessoa para provar o trabalho.
Baseado em aposta: O classificador determina a probabilidade de ser eleito como provador com base no valor que aposta.
Esquema Commit-Reveal: O primeiro committer precisa prometer tokens para obter uma oportunidade de monopólio curta e, em seguida, gerar provas dentro dessa janela de tempo. Para evitar ataques DDoS, se o primeiro não conseguir gerar provas a tempo, os tokens colaterais exigidos pelo segundo aumentarão exponencialmente. Embora sob este mecanismo, a rede pode perder a máquina com melhor desempenho, mas mais provadores podem ser cultivados.
Além da competição entre os provadores, a barreira de entrada deve ser diminuída para que mais provadores possam participar da rede. Starknet propõe um protocolo complexo utilizando provas recursivas chamadas provas de protocolo encadeadas.
Nos protocolos de prova de cadeia, o próprio blockchain é dividido em várias bifurcações diferentes. Dessa forma, as provas podem não apenas ser recursivas, mas a geração de provas também pode ser concorrente. Por exemplo, em uma configuração de 3 ramos, 12 blocos pretos são divididos em 3 linhas, cada linha representando um ramo. Podemos pensar em cada ramificação como uma sub-cadeia onde cada bloco deve atestar o bloco anterior. Do ponto de vista de toda a cadeia, o slot n precisa provar o slot n-3. O intervalo de 3 blocos permite tempo suficiente para o comprador calcular e comprar as provas com antecedência. Isso é um pouco semelhante ao sharding, em que um invasor precisa controlar apenas uma ramificação para controlar toda a rede de provadores.
Para unir essas ramificações, a Starknet propõe uma tecnologia de tecelagem que pode mesclar vários nós para verificar conjuntamente a legitimidade das transações e garantir a consistência e a confiabilidade dos registros de transações.
Uma solução é exigir que cada slot seja mesclado com várias ramificações ao mesmo tempo. Outra solução é tentar alternadamente cada ramificação para mesclar com outras ramificações, reduzindo assim a carga de trabalho da prova. Claro, este também é um problema em aberto e pode haver soluções melhores no futuro.
coordenação
Para garantir ativamente que o provador possa ter espaço de lucro suficiente, a Starknet propõe um método de referência ao esquema EIP1559: defina a taxa básica como o limite inferior do preço do recurso do provador, conduza ativamente a descoberta de preços e o classificador pode usar dicas para motivar o provador. Dessa forma, o provador sempre será pago a mais e apenas casos extremos afetarão o processo de prova. Caso contrário, se o provador for pago próximo ao preço de mercado, uma pequena flutuação pode desencadear um bloqueio do provador.
Descentralização do certificador
Da perspectiva dos Rollups, o provador é mais fácil de alcançar a descentralização do que o classificador. Além disso, o provador atual é um gargalo de desempenho e precisa acompanhar a velocidade de dosagem do classificador. Quando a descentralização do classificador não for resolvida, o provador descentralizado também pode fornecer serviços para o classificador centralizado.
Na verdade, não apenas Rollups, zkBridge e zkOracle também precisam de uma rede de provadores. Todos eles requerem uma forte rede distribuída de provadores.
A longo prazo, uma rede de provadores que pode acomodar diferentes capacidades de computação é mais sustentável, caso contrário, as máquinas com melhor desempenho monopolizarão o mercado.
Prova de Mercado
Alguns protocolos não coordenam a relação entre o sequenciador e o provador, mas abstraem diretamente a coordenação em um mercado de prova. Nesse mercado, as provas são commodities, os provadores são produtores de provas e os protocolos são consumidores de provas. O equilíbrio do mercado é mais eficiente sob a influência da "mão invisível".
Meu
Mina estabeleceu um mercado de provas chamado Snarketplace, onde as provas de Snark são negociadas. A menor unidade aqui é a prova Snark de uma única transação. Mina emprega uma prova recursiva de árvore de estado chamada Scan State.
Scan State é uma floresta de árvores binárias onde cada transação é um nó. Uma única prova é gerada no topo da árvore que pode provar todas as transações na árvore. O provador tem duas tarefas: a primeira é gerar provas e a segunda é mesclar provas.
Após o provador concluir o trabalho e enviar o lance, o produtor do bloco do protocolo Mina selecionará o licitante com o menor preço. Este também é o preço de equilíbrio, pois os licitantes apresentarão lances acima do custo das provas e os produtores de blocos não comprarão provas que não valham o dinheiro.
=Nil; Fundação
O mercado de prova de Mina é projetado para seu próprio protocolo, enquanto =nil; Foundation propõe um mercado de prova geral para atender a todo o mercado.
O serviço de mercado consiste em três componentes: DROP DATABASE, zkLLVM e Proof Market.
DROP DATABASE: É um protocolo de sistema de gerenciamento de banco de dados, que pode ser considerado como uma camada DA.
Proof Market: é um aplicativo que roda em DROP DATABASE, semelhante ao que alguns chamam de "troca descentralizada" à prova de zk.
zkLLVM: é um compilador que converte linguagens de programação de alto nível em entradas para protocolos de computação comprováveis.
Cada prova consiste em suas diferentes entradas e circuitos, portanto, cada prova é única. Um circuito define um tipo de prova, semelhante a como um "par de transações" é definido em termos financeiros. Além disso, diferentes sistemas de prova introduzem mais circuitos.
O fluxo de trabalho é o seguinte: o lado da demanda da prova pode escrever código em uma linguagem de programação de alto nível e, em seguida, alimentá-lo para =nil;zkLLVM por meio da cadeia de ferramentas, gerando um único circuito que se tornará um par comercial exclusivo no mercado.
Para provar o lado da demanda, eles podem fazer uma compensação entre custo e tempo. Os provadores também levarão em consideração seu poder de computação e renda. Portanto, no mercado haverá diferentes poderes computacionais, alto poder computacional irá gerar provas mais rapidamente, porém com um custo maior, enquanto baixo poder computacional irá gerar provas mais lentas, porém mais baratas.
COMPROMISSO EM DUAS ETAPAS
Recentemente, Opside propôs um esquema de confirmação em duas etapas para descentralizar a rede do provedor. O esquema divide o envio da prova em duas fases para evitar a situação em que o provador mais rápido sempre vence.
Passo 1: Envie o hash da prova de conhecimento zero do T-ésimo bloco
A partir do bloco T+11, novos provadores não podem mais enviar hashes.
Etapa 2: envie uma prova de conhecimento zero
Após o bloco T+11, qualquer provador pode enviar uma prova de conhecimento zero. Se pelo menos uma prova de conhecimento zero passar na verificação, ela será usada para verificar todos os hashes enviados e o provador verificado receberá recompensas PoW correspondentes na proporção do valor da hipoteca.
Se nenhuma prova de conhecimento zero for verificada antes do bloco T+20, todos os provadores que enviaram hashes serão penalizados. Em seguida, reabra o classificador, você pode enviar um novo hash, volte para a etapa 1.
Este método pode acomodar diferentes capacidades de computação. No entanto, a garantia exigida ainda apresenta um nível de centralização.
Descentralização do classificador
A descentralização dos ordenadores é mais complexa do que a dos validadores. Isso porque o classificador tem o poder de empacotar e organizar as transações, e questões como MEV e distribuição de renda precisam ser consideradas.
Dado que o Ethereum priorizará a vivacidade em detrimento da capacidade de resposta, as soluções L2 devem complementar essa compensação priorizando a capacidade de resposta em detrimento da vivacidade. No entanto, em comparação com os classificadores centralizados, os classificadores descentralizados sacrificam inerentemente em termos de capacidade de resposta. Portanto, várias otimizações precisam ser implementadas para resolver esse dilema.
Atualmente, existem três propostas diferentes de classificadores descentralizados. A primeira solução é realizada otimizando o mecanismo de consenso. O segundo esquema envolve uma rede de sequenciadores compartilhados. O terceiro esquema é baseado em validadores L1.
consenso
O protocolo de consenso é o principal responsável por ordenar as transações e garantir sua disponibilidade, não por executá-las. No entanto, adicionar diretamente outra camada de consenso, como mencionado anteriormente, não é uma solução fácil.
Para melhorar a capacidade de resposta, uma abordagem comum é contar com um conjunto menor de validadores. Por exemplo, a Algorand e a Polkadot usam comitês menores amostrados aleatoriamente para transações em lote. Todos os nós usam beacons aleatórios e uma função aleatória verificável (VRF), com probabilidade de serem incluídos em um comitê em um determinado período proporcional ao valor apostado.
Para reduzir o tráfego de rede, comitês menores de Disponibilidade de Dados (DA) podem ser usados. Ou use VID (Dispersão de informações verificáveis). A VID distribui o código de apagamento dos dados para todos os nodos participantes do consenso, de modo que qualquer subconjunto de nodos que possuam uma taxa de garantia suficientemente alta possa cooperar para restaurar os dados. A compensação dessa abordagem é reduzir a complexidade da transmissão, mas aumentar a complexidade da recuperação de dados.
A Arbitrum selecionou entidades respeitáveis para formar o conjunto de validadores, como ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) da IFF e Unit 410 para ingressar no Sorter Committee. O trade-off nessa abordagem é compensar a falta de quantidade melhorando a qualidade da descentralização.
Rede Sequenciadora Compartilhada
Os classificadores desempenham um papel vital em blockchains modulares, especialmente em Rollups. Cada Rollup geralmente constrói sua própria rede de classificadores. No entanto, essa abordagem não apenas cria problemas de redundância, mas também dificulta a capacidade de composição. Para resolver este problema, alguns protocolos propõem a construção de uma rede compartilhada de classificadores Rollup. Essa abordagem reduz a complexidade de alcançar atomicidade, capacidade de composição e interoperabilidade, recursos que usuários e desenvolvedores precisam desesperadamente em blockchains abertos e sem permissão. Além disso, também elimina a necessidade de um light client separado para a rede do solicitante.
Ástria
A Astria está desenvolvendo um blockchain de middleware para o ecossistema Rollup da Celestia, que inclui sua própria coleção de pedidos distribuídos. Este conjunto de ordenadores é responsável por aceitar transações de vários Rollups e escrevê-las na camada base sem executá-las.
A função do Astria é focada principalmente na ordem das transações e opera independentemente da camada base e do Rollup. Os dados da transação são armazenados na camada base (por exemplo, Celestia), enquanto os nós completos do Rollup mantêm o estado e executam as operações. Isso garante que o Astria seja desacoplado do Rollup.
Para finalizar, a Astria oferece dois níveis de Compromisso:
"Compromisso flexível": permite que o Rollup forneça confirmações de bloqueio rápidas para seus usuários finais.
“Compromisso firme”: A velocidade é a mesma da camada base, garantindo maior segurança e finalidade.
Expresso
A Espresso deu uma contribuição significativa no campo da tecnologia de conhecimento zero. Seu desenvolvimento mais recente é uma solução abrangente para classificadores descentralizados que podem ser aplicados a Optimistic Rollups e zkRollups.
A rede de pedidos descentralizada consiste em:
Consenso do HotShot: priorizar alta taxa de transferência e finalização rápida em vez de disponibilidade dinâmica.
Espresso DA: Combinando solução DA baseada em comitê e VID, onde nós de alta largura de banda alimentam dados para todos os outros nós. A disponibilidade de cada bloco individual também é apoiada por um pequeno comitê eleito aleatoriamente. Os VIDs fornecem um backup confiável, mas mais lento, garantindo a disponibilidade, desde que uma porcentagem suficientemente alta do peso apostado de todos os nós não seja comprometida.
Rollup REST API: Ethereum compatível com JSON-RPC.
Contrato do sequenciador: verifica o consenso do HotShot (ou seja, atua como um light client) e registra os checkpoints (ou seja, faz um compromisso criptográfico com a transação) e gerencia a tabela de compromisso do HotShot.
Rede P2P: protocolo Gossip.
Comparado com o Astria, o Espresso oferece DA. Portanto, o fluxo de trabalho será um pouco diferente, conforme a seguir:
O usuário cria e envia uma transação para Rollup.
A transação é propagada pela rede do solicitante e retida no mempool.
Designe um líder por meio do mecanismo de garantia HotShot, proponha um bloco e propague-o de volta aos executores e provadores do Rollup.
O líder envia a transação ao Comitê de Disponibilidade de Dados e recebe um certificado DA como feedback.
O líder também envia uma confirmação do bloco para o contrato do Layer 1 Sorter, junto com o certificado que o contrato usa para validar o bloco.
O Espresso apresenta o protocolo Gossip para provas para fornecer uma experiência de usuário mais flexível. Ele fornece três opções para a finalidade da transação:
Rápido: Os usuários podem confiar no servidor Rollup que executou a transação e gerou a prova, ou podem aproveitar a baixa latência do HotShot para executar a transação.
Moderado: O usuário pode esperar um pouco para que a prova seja gerada e, em seguida, verifique-a.
Lento: os usuários podem aguardar as atualizações de estado verificadas L1 para obter o estado atualizado sem quaisquer suposições ou cálculos de confiança.
Além das otimizações acima, o Espresso também planeja que todo o conjunto de validadores Ethereum participe da execução do protocolo de pedido do Espresso. Usar o mesmo conjunto de validadores fornecerá segurança semelhante e compartilhar valor com validadores L1 será mais seguro. Além disso, o Espresso também pode aproveitar a solução ETH re-staking fornecida pela EigenLayer.
Raio
A Radius está construindo uma camada de ordenação compartilhada sem confiança com base em provas de conhecimento zero, com foco na solução do problema MEV em L2, porque a receita de L2 vem principalmente do espaço em bloco. A compensação a considerar é o equilíbrio entre a receita MEV e L2. O objetivo do Radius é eliminar o MEV, que é prejudicial aos usuários, e propõe um serviço de duas camadas.
A camada superior visa as transações regulares do usuário e fornece proteção criptográfica contra MEV indesejado por meio do uso de quebra-cabeças de bloqueio de tempo. Especificamente, ele emprega a tecnologia PVDE (Prática Verificável Delayed Encryption), que irá gerar provas de conhecimento zero para quebra-cabeças de bloqueio de tempo baseados em RSA em 5 segundos. Este método fornece uma solução prática para proteger os usuários de MEVs prejudiciais. Resumindo, o conteúdo da transação não pode ser conhecido até que o sequenciador determine a ordem das transações.
A camada subjacente foi projetada para construtores de blocos e permite que eles participem de atividades geradoras de receita, mitigando o impacto negativo do MEV.
Acumulados baseados
Based Rollup é um conceito proposto recentemente por Justin Drake, onde os proponentes de blocos L1 cooperam com os buscadores e construtores L1 para incluir blocos rollup no próximo bloco L1 sem permissão. Ele pode ser visto como uma rede de sequenciadores compartilhados em L1. As vantagens e desvantagens do Based Rollup são óbvias.
Do lado positivo, o Based Rollup aproveita a vivacidade e a descentralização fornecidas pelo L1, e sua implementação é simples e eficiente. Rollup baseado também é economicamente consistente com L1. No entanto, isso não significa que o Based Rollup comprometa sua soberania. Embora o MEV seja entregue ao L1, o Based Rollup ainda pode possuir tokens de governança e cobrar taxas básicas. Com base na hipótese, o Based Rollup pode aproveitar essas vantagens, alcançar o domínio e, por fim, maximizar os retornos.
para concluir
Olhando para as propostas propostas, percebe-se que a descentralização do Rollup ainda tem um longo caminho a percorrer. Algumas dessas propostas ainda estão em fase de rascunho e requerem mais discussão, enquanto outras têm apenas especificações preliminares concluídas. Todos esses cenários precisam ser implementados e rigorosamente testados.
Embora alguns Rollups possam não propor explicitamente uma solução descentralizada correspondente, eles geralmente incluem mecanismos de escape para abordar pontos únicos de falha devido a pedidos centralizados. Por exemplo, o zkSync fornece um método FullExit que permite aos usuários sacar seus fundos diretamente do L1. Quando o sistema entra em modo de êxodo e não consegue processar novos blocos, o usuário pode iniciar uma operação de retirada.
Para obter resistência à censura, esses Rollups geralmente também permitem que os usuários enviem transações diretamente no L1. Por exemplo, zkSync emprega uma fila de prioridade para tais transações enviadas em L1. Da mesma forma, o Polygon zkEVM inclui um método de lote forçado no contrato L1. Quando nenhuma agregação ocorre dentro de uma semana, o usuário pode chamar este método em L1 e fornecer o array de bytes da transação e bathFee para o provador.
O que é certo é que num futuro previsível, a descentralização do Rollup será uma solução combinada, que pode incluir as soluções importantes acima mencionadas ou algumas outras variantes inovadoras.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Entendendo Rollups Descentralizados em um Artigo
Título original: "Rollups descentralizados"
À medida que o uso de Rollups aumenta e hospeda os aplicativos do ecossistema, os custos de migração para os usuários aumentarão e os compradores centralizados ganharão influência monopolista sobre os preços. Os controladores de pedidos centralizados têm justificativa para maximizar a extração de valor (MEV) dos usuários, tanto diretamente (por exemplo, por meio de taxas) quanto indiretamente (por exemplo, por meio de transações frontrunning, ataques sanduíche, etc.). — Expresso
Conforme mencionado pela equipe do Espresso, os Rollups centralizados eventualmente enfrentarão preços de monopólio e problemas de MEV. Além disso, Rollups centralizados quebram inerentemente a capacidade de composição, levando a Rollups fragmentados. **
No entanto, quase todos os Rollups atuais ainda são centralizados, porque construir um Rollup descentralizado, sem permissão e escalável é extremamente desafiador. Outro motivo é que o lançamento de Rollups centralizados primeiro pode ajudar a incubar o ecossistema e conquistar participação de mercado.
E quando discutimos Rollups descentralizados, especialmente zkRollups, existem dois níveis de descentralização. A primeira é a descentralização do provador e a segunda é a descentralização do ordenador. Para alcançar a descentralização completa, também é necessário resolver o problema de coordenação entre o ordenante e o provador.
Sob a tendência da modularização, existem atualmente três tipos principais de participantes no Rollup descentralizado. A primeira categoria visa alcançar Rollups totalmente descentralizados e propõe uma solução completa. A segunda categoria são os protocolos projetados para resolver redes provadoras. Finalmente, existem várias soluções que estão trabalhando para descentralizar o classificador.
Rollups descentralizados
Em zkRollups, Polygon e Starknet criaram soluções para descentralizar seus Rollups.
Polígono
Antes da introdução do POE (Prova de Eficiência), o Polygon zkEVM adotava o POD (Prova de Doação), permitindo que o classificador licitasse pela oportunidade de criar o próximo lote de transações. No entanto, isso cria o problema de que uma única parte maliciosa pode controlar toda a rede fazendo o lance mais alto.
Depois de adotar o POE, o solicitador e o provador participarão da rede sem permissão com mais eficiência sob suas próprias condições de hardware. Qualquer pessoa pode ingressar no Polygon zkEVM, desde que faça sentido econômico.
No Polygon zkEVM, o classificador requer 16 GB de RAM e uma CPU de 4 núcleos, enquanto o provador requer 1 TB de RAM e uma CPU de 128 núcleos. Além disso, existe um papel chamado agregador, que é responsável por coletar os dados do L1, enviá-los ao provador, receber a prova e enviá-los ao L1. Podemos considerar o agregador e o provador como o mesmo sujeito, porque a relação entre o agregador e o provador é muito simples, e o agregador paga ao provador para produzir a prova.
Essa arquitetura é muito simples: qualquer ordenador pode empacotar transações com base no estado anterior em L1 sem permissão e atualizar o estado correspondente. Ao mesmo tempo, qualquer agregador pode enviar uma prova para verificar o estado atualizado.
No POE, a eficiência refere-se não apenas à eficiência da rede dos participantes competindo entre si, mas também à eficiência econômica do sequenciador e do próprio provador. Em L2, o requisitante e o provador compartilham a taxa de transação, e o requisitante paga a batchFee ao agregador para gerar a prova. Isso garante que os participantes sejam economicamente motivados a contribuir para a eficiência da rede, resultando em um ecossistema mais robusto e sustentável.
classificador
Agregador (Provedor)
Coordenador: batchFee
Starknet
A Starknet também pretende criar um Rollup escalonável e sem permissão de confirmação rápida. Embora a especificação final para a solução descentralizada ainda não tenha sido alcançada, eles publicaram alguns rascunhos no fórum há alguns meses.
Comparado com o mecanismo simples do Polygon zkEVM, o esquema de Starknet é mais complicado porque inclui consenso L2 e prova de protocolo encadeada na rede de prova.
classificador
Em vez de simplesmente adicionar uma camada de consenso dentro da camada do ordenador, a Starknet propõe um protocolo de consenso de ledger duplo. Neste protocolo, o L2 fornece uma resposta rápida como um protocolo ativo, enquanto os pontos de verificação L1 fornecem a confirmação final como um protocolo seguro.
Para o protocolo ao vivo do L2, vários mecanismos de consenso podem ser adotados, como sistemas PoS resistentes a Sybil, como Tendermint ou DAGs. Por outro lado, o protocolo seguro do L1 envolve vários contratos que lidam com o gerenciamento de Stake, verificação de provas e atualização de status, respectivamente.
O fluxo de trabalho típico do acordo de consenso de contabilidade dupla é o seguinte:
Primeiro, use a saída do ledger ativo L2 como entrada do ledger seguro L1 para gerar um ledger ativo verificado.
Em seguida, pegue o ledger ativo verificado como entrada e insira-o novamente no protocolo de consenso puro de L2 para garantir que o ledger ativo verificado seja sempre o prefixo do ledger ativo.
Repita o processo acima.
Ao criar um protocolo de consenso de contabilidade dupla, há uma compensação entre custo e latência. A solução ideal visa obter baixo custo e rápida aprovação final.
A fim de reduzir os custos de gás em L2, Starknet divide os pontos de verificação em "nível de minuto" e "nível de hora". Para pontos de verificação de "nível de minuto", apenas o próprio estado é confirmado na cadeia, enquanto o restante dos dados (provas de validade, disponibilidade de dados etc.) é enviado pela rede StarkNet L2. Esses dados são armazenados e verificados pelos nós completos da StarkNet. Por outro lado, os pontos de verificação "de hora em hora" são validados publicamente em L1. Ambos os tipos de pontos de verificação fornecem a mesma confirmação final. Para pontos de verificação de "nível de minuto", a prova de validade é verificada por nós completos StarkNet e pode ser emitida por qualquer nó em L1 para dar finalidade de L1 a pontos de verificação de "nível de minuto". Portanto, o provador precisa gerar pequenas provas para serem amplamente divulgadas na rede L2.
Para reduzir ainda mais a latência, a Starknet propõe um protocolo de eleição de líder para determinar o líder com antecedência. A lógica básica é a seguinte: o líder da época atual i é pré-determinado com base na quantidade de L1 apostado e em alguma aleatoriedade. Especificamente, na época i-2, o método leader_election agrupa os classificadores lexicograficamente com base na quantidade de promessas na época i-3. Em seguida, envie uma transação para atualizar o nonce e escolha um ponto aleatoriamente. O classificador correspondente à posição onde o ponto cai será o líder da época i.
Certificador
No módulo POE, há uma competição aberta entre os participantes, o que pode levar a uma situação de vencedor leva tudo. A Starknet tenta alcançar um mecanismo de competição sem risco de centralização. Aqui estão algumas opções:
Além da competição entre os provadores, a barreira de entrada deve ser diminuída para que mais provadores possam participar da rede. Starknet propõe um protocolo complexo utilizando provas recursivas chamadas provas de protocolo encadeadas.
Nos protocolos de prova de cadeia, o próprio blockchain é dividido em várias bifurcações diferentes. Dessa forma, as provas podem não apenas ser recursivas, mas a geração de provas também pode ser concorrente. Por exemplo, em uma configuração de 3 ramos, 12 blocos pretos são divididos em 3 linhas, cada linha representando um ramo. Podemos pensar em cada ramificação como uma sub-cadeia onde cada bloco deve atestar o bloco anterior. Do ponto de vista de toda a cadeia, o slot n precisa provar o slot n-3. O intervalo de 3 blocos permite tempo suficiente para o comprador calcular e comprar as provas com antecedência. Isso é um pouco semelhante ao sharding, em que um invasor precisa controlar apenas uma ramificação para controlar toda a rede de provadores.
Para unir essas ramificações, a Starknet propõe uma tecnologia de tecelagem que pode mesclar vários nós para verificar conjuntamente a legitimidade das transações e garantir a consistência e a confiabilidade dos registros de transações.
Uma solução é exigir que cada slot seja mesclado com várias ramificações ao mesmo tempo. Outra solução é tentar alternadamente cada ramificação para mesclar com outras ramificações, reduzindo assim a carga de trabalho da prova. Claro, este também é um problema em aberto e pode haver soluções melhores no futuro.
coordenação
Para garantir ativamente que o provador possa ter espaço de lucro suficiente, a Starknet propõe um método de referência ao esquema EIP1559: defina a taxa básica como o limite inferior do preço do recurso do provador, conduza ativamente a descoberta de preços e o classificador pode usar dicas para motivar o provador. Dessa forma, o provador sempre será pago a mais e apenas casos extremos afetarão o processo de prova. Caso contrário, se o provador for pago próximo ao preço de mercado, uma pequena flutuação pode desencadear um bloqueio do provador.
Descentralização do certificador
Da perspectiva dos Rollups, o provador é mais fácil de alcançar a descentralização do que o classificador. Além disso, o provador atual é um gargalo de desempenho e precisa acompanhar a velocidade de dosagem do classificador. Quando a descentralização do classificador não for resolvida, o provador descentralizado também pode fornecer serviços para o classificador centralizado.
Na verdade, não apenas Rollups, zkBridge e zkOracle também precisam de uma rede de provadores. Todos eles requerem uma forte rede distribuída de provadores.
A longo prazo, uma rede de provadores que pode acomodar diferentes capacidades de computação é mais sustentável, caso contrário, as máquinas com melhor desempenho monopolizarão o mercado.
Prova de Mercado
Alguns protocolos não coordenam a relação entre o sequenciador e o provador, mas abstraem diretamente a coordenação em um mercado de prova. Nesse mercado, as provas são commodities, os provadores são produtores de provas e os protocolos são consumidores de provas. O equilíbrio do mercado é mais eficiente sob a influência da "mão invisível".
Meu
Mina estabeleceu um mercado de provas chamado Snarketplace, onde as provas de Snark são negociadas. A menor unidade aqui é a prova Snark de uma única transação. Mina emprega uma prova recursiva de árvore de estado chamada Scan State.
Scan State é uma floresta de árvores binárias onde cada transação é um nó. Uma única prova é gerada no topo da árvore que pode provar todas as transações na árvore. O provador tem duas tarefas: a primeira é gerar provas e a segunda é mesclar provas.
Após o provador concluir o trabalho e enviar o lance, o produtor do bloco do protocolo Mina selecionará o licitante com o menor preço. Este também é o preço de equilíbrio, pois os licitantes apresentarão lances acima do custo das provas e os produtores de blocos não comprarão provas que não valham o dinheiro.
=Nil; Fundação
O mercado de prova de Mina é projetado para seu próprio protocolo, enquanto =nil; Foundation propõe um mercado de prova geral para atender a todo o mercado.
O serviço de mercado consiste em três componentes: DROP DATABASE, zkLLVM e Proof Market.
Cada prova consiste em suas diferentes entradas e circuitos, portanto, cada prova é única. Um circuito define um tipo de prova, semelhante a como um "par de transações" é definido em termos financeiros. Além disso, diferentes sistemas de prova introduzem mais circuitos.
O fluxo de trabalho é o seguinte: o lado da demanda da prova pode escrever código em uma linguagem de programação de alto nível e, em seguida, alimentá-lo para =nil;zkLLVM por meio da cadeia de ferramentas, gerando um único circuito que se tornará um par comercial exclusivo no mercado.
Para provar o lado da demanda, eles podem fazer uma compensação entre custo e tempo. Os provadores também levarão em consideração seu poder de computação e renda. Portanto, no mercado haverá diferentes poderes computacionais, alto poder computacional irá gerar provas mais rapidamente, porém com um custo maior, enquanto baixo poder computacional irá gerar provas mais lentas, porém mais baratas.
COMPROMISSO EM DUAS ETAPAS
Recentemente, Opside propôs um esquema de confirmação em duas etapas para descentralizar a rede do provedor. O esquema divide o envio da prova em duas fases para evitar a situação em que o provador mais rápido sempre vence.
Este método pode acomodar diferentes capacidades de computação. No entanto, a garantia exigida ainda apresenta um nível de centralização.
Descentralização do classificador
A descentralização dos ordenadores é mais complexa do que a dos validadores. Isso porque o classificador tem o poder de empacotar e organizar as transações, e questões como MEV e distribuição de renda precisam ser consideradas.
Dado que o Ethereum priorizará a vivacidade em detrimento da capacidade de resposta, as soluções L2 devem complementar essa compensação priorizando a capacidade de resposta em detrimento da vivacidade. No entanto, em comparação com os classificadores centralizados, os classificadores descentralizados sacrificam inerentemente em termos de capacidade de resposta. Portanto, várias otimizações precisam ser implementadas para resolver esse dilema.
Atualmente, existem três propostas diferentes de classificadores descentralizados. A primeira solução é realizada otimizando o mecanismo de consenso. O segundo esquema envolve uma rede de sequenciadores compartilhados. O terceiro esquema é baseado em validadores L1.
consenso
O protocolo de consenso é o principal responsável por ordenar as transações e garantir sua disponibilidade, não por executá-las. No entanto, adicionar diretamente outra camada de consenso, como mencionado anteriormente, não é uma solução fácil.
Para melhorar a capacidade de resposta, uma abordagem comum é contar com um conjunto menor de validadores. Por exemplo, a Algorand e a Polkadot usam comitês menores amostrados aleatoriamente para transações em lote. Todos os nós usam beacons aleatórios e uma função aleatória verificável (VRF), com probabilidade de serem incluídos em um comitê em um determinado período proporcional ao valor apostado.
Para reduzir o tráfego de rede, comitês menores de Disponibilidade de Dados (DA) podem ser usados. Ou use VID (Dispersão de informações verificáveis). A VID distribui o código de apagamento dos dados para todos os nodos participantes do consenso, de modo que qualquer subconjunto de nodos que possuam uma taxa de garantia suficientemente alta possa cooperar para restaurar os dados. A compensação dessa abordagem é reduzir a complexidade da transmissão, mas aumentar a complexidade da recuperação de dados.
A Arbitrum selecionou entidades respeitáveis para formar o conjunto de validadores, como ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) da IFF e Unit 410 para ingressar no Sorter Committee. O trade-off nessa abordagem é compensar a falta de quantidade melhorando a qualidade da descentralização.
Rede Sequenciadora Compartilhada
Os classificadores desempenham um papel vital em blockchains modulares, especialmente em Rollups. Cada Rollup geralmente constrói sua própria rede de classificadores. No entanto, essa abordagem não apenas cria problemas de redundância, mas também dificulta a capacidade de composição. Para resolver este problema, alguns protocolos propõem a construção de uma rede compartilhada de classificadores Rollup. Essa abordagem reduz a complexidade de alcançar atomicidade, capacidade de composição e interoperabilidade, recursos que usuários e desenvolvedores precisam desesperadamente em blockchains abertos e sem permissão. Além disso, também elimina a necessidade de um light client separado para a rede do solicitante.
Ástria
A Astria está desenvolvendo um blockchain de middleware para o ecossistema Rollup da Celestia, que inclui sua própria coleção de pedidos distribuídos. Este conjunto de ordenadores é responsável por aceitar transações de vários Rollups e escrevê-las na camada base sem executá-las.
A função do Astria é focada principalmente na ordem das transações e opera independentemente da camada base e do Rollup. Os dados da transação são armazenados na camada base (por exemplo, Celestia), enquanto os nós completos do Rollup mantêm o estado e executam as operações. Isso garante que o Astria seja desacoplado do Rollup.
Para finalizar, a Astria oferece dois níveis de Compromisso:
Expresso
A Espresso deu uma contribuição significativa no campo da tecnologia de conhecimento zero. Seu desenvolvimento mais recente é uma solução abrangente para classificadores descentralizados que podem ser aplicados a Optimistic Rollups e zkRollups.
A rede de pedidos descentralizada consiste em:
Comparado com o Astria, o Espresso oferece DA. Portanto, o fluxo de trabalho será um pouco diferente, conforme a seguir:
O usuário cria e envia uma transação para Rollup.
A transação é propagada pela rede do solicitante e retida no mempool.
Designe um líder por meio do mecanismo de garantia HotShot, proponha um bloco e propague-o de volta aos executores e provadores do Rollup.
O líder envia a transação ao Comitê de Disponibilidade de Dados e recebe um certificado DA como feedback.
O líder também envia uma confirmação do bloco para o contrato do Layer 1 Sorter, junto com o certificado que o contrato usa para validar o bloco.
O Espresso apresenta o protocolo Gossip para provas para fornecer uma experiência de usuário mais flexível. Ele fornece três opções para a finalidade da transação:
Além das otimizações acima, o Espresso também planeja que todo o conjunto de validadores Ethereum participe da execução do protocolo de pedido do Espresso. Usar o mesmo conjunto de validadores fornecerá segurança semelhante e compartilhar valor com validadores L1 será mais seguro. Além disso, o Espresso também pode aproveitar a solução ETH re-staking fornecida pela EigenLayer.
Raio
A Radius está construindo uma camada de ordenação compartilhada sem confiança com base em provas de conhecimento zero, com foco na solução do problema MEV em L2, porque a receita de L2 vem principalmente do espaço em bloco. A compensação a considerar é o equilíbrio entre a receita MEV e L2. O objetivo do Radius é eliminar o MEV, que é prejudicial aos usuários, e propõe um serviço de duas camadas.
A camada superior visa as transações regulares do usuário e fornece proteção criptográfica contra MEV indesejado por meio do uso de quebra-cabeças de bloqueio de tempo. Especificamente, ele emprega a tecnologia PVDE (Prática Verificável Delayed Encryption), que irá gerar provas de conhecimento zero para quebra-cabeças de bloqueio de tempo baseados em RSA em 5 segundos. Este método fornece uma solução prática para proteger os usuários de MEVs prejudiciais. Resumindo, o conteúdo da transação não pode ser conhecido até que o sequenciador determine a ordem das transações.
A camada subjacente foi projetada para construtores de blocos e permite que eles participem de atividades geradoras de receita, mitigando o impacto negativo do MEV.
Acumulados baseados
Based Rollup é um conceito proposto recentemente por Justin Drake, onde os proponentes de blocos L1 cooperam com os buscadores e construtores L1 para incluir blocos rollup no próximo bloco L1 sem permissão. Ele pode ser visto como uma rede de sequenciadores compartilhados em L1. As vantagens e desvantagens do Based Rollup são óbvias.
Do lado positivo, o Based Rollup aproveita a vivacidade e a descentralização fornecidas pelo L1, e sua implementação é simples e eficiente. Rollup baseado também é economicamente consistente com L1. No entanto, isso não significa que o Based Rollup comprometa sua soberania. Embora o MEV seja entregue ao L1, o Based Rollup ainda pode possuir tokens de governança e cobrar taxas básicas. Com base na hipótese, o Based Rollup pode aproveitar essas vantagens, alcançar o domínio e, por fim, maximizar os retornos.
para concluir
Olhando para as propostas propostas, percebe-se que a descentralização do Rollup ainda tem um longo caminho a percorrer. Algumas dessas propostas ainda estão em fase de rascunho e requerem mais discussão, enquanto outras têm apenas especificações preliminares concluídas. Todos esses cenários precisam ser implementados e rigorosamente testados.
Embora alguns Rollups possam não propor explicitamente uma solução descentralizada correspondente, eles geralmente incluem mecanismos de escape para abordar pontos únicos de falha devido a pedidos centralizados. Por exemplo, o zkSync fornece um método FullExit que permite aos usuários sacar seus fundos diretamente do L1. Quando o sistema entra em modo de êxodo e não consegue processar novos blocos, o usuário pode iniciar uma operação de retirada.
Para obter resistência à censura, esses Rollups geralmente também permitem que os usuários enviem transações diretamente no L1. Por exemplo, zkSync emprega uma fila de prioridade para tais transações enviadas em L1. Da mesma forma, o Polygon zkEVM inclui um método de lote forçado no contrato L1. Quando nenhuma agregação ocorre dentro de uma semana, o usuário pode chamar este método em L1 e fornecer o array de bytes da transação e bathFee para o provador.
O que é certo é que num futuro previsível, a descentralização do Rollup será uma solução combinada, que pode incluir as soluções importantes acima mencionadas ou algumas outras variantes inovadoras.