Este documento analisa as principais tecnologias de sequenciadores compartilhados: altamente resistentes à censura, fáceis de implantar, interoperáveis, rápidos de determinar e instantâneos. A teoria da agregação fornece uma nova perspectiva para ela, e a integração vertical orienta seu desenvolvimento posterior.
Título original: "The Shared Sequencer"
Escrito por: MAVEN11
Compilação: Kxp, BlockBeats
Imagine como seria se o Rollup "pronto para uso" pudesse atingir um alto grau de resistência à censura, facilidade de implantação, interoperabilidade, finalização rápida, vivacidade e democratização do MEV. Isso pode parecer um grande objetivo, mas com o advento do Sequenciador Compartilhado, pode se tornar realidade em breve. No entanto, nem todos os Rollups são iguais, então temos que considerar como distribuir as recompensas e o MEV na rede do sequenciador compartilhado. Neste artigo, exploramos como as redes de classificação compartilhada são implementadas e as propriedades que podem ser alcançadas.
Shared Sequencer Networks foi apresentado principalmente por Alex Beckett, mais tarde por Evan Forbes (e Radius) das equipes Celestia e Espresso, e um novo artigo de Jon Charbonneau que cobre o tópico com mais profundidade. Josh, Jordan e sua equipe Astria estão construindo a primeira rede de sequenciador compartilhado pronta para produção. A Shared Orderer Network da Astria é uma blockchain modular que agrega e ordena as transações do Rollup sem executá-las.
Na configuração do Astria, o classificador envia os blocos ordenados para a camada DA e também para os nós Rollup. Os rollups obtêm garantias de finalidade flexível do ordenador e garantias de finalidade definitiva da camada DA (após a finalização dos blocos) e, em seguida, executarão transações válidas.
A rede de sequenciadores compartilhados é essencialmente um grupo de sequenciadores compatíveis com Rollup, como o próprio nome sugere, pode fornecer serviços para diferentes Rollups. Isso tem várias compensações e propriedades, que detalharemos mais adiante. Primeiro, devemos descrever as propriedades mais importantes de um classificador (ou conjunto de classificadores). No Rollup, o principal requisito para um sequenciador ou grupo de sequenciadores é a resistência à censura ou vivacidade (algumas das quais vêm da camada base, assim como a segurança). Isso significa que uma transação válida enviada ao solicitante deve ser incluída na cadeia em um período de tempo finito (parâmetro timeout). O grupo de pedidos compartilhados só precisa garantir que as transações sejam incluídas em blocos (ou seja, crLists).
Satisfazer a resistência à censura e o imediatismo ao mesmo tempo é bastante difícil, como descrevemos no Modular MEV Parte II. Em um algoritmo de consenso como o Tendermint, você pode garantir a recuperação após um ataque. No entanto, no caso de um ataque, você perde o imediatismo. Basicamente, exigir que todos os outros agrupadores assinem um bloco, em vez de eleger um masternode personalizado, provavelmente não é o ideal. Embora isso melhore a resistência à censura, tem o custo de "centralização" e extração de MEV para um único masternode. Outro mecanismo de classificação disponível pode ser comparado ao Multiplicity do Duality, que é sua pequena ferramenta para não-masternodes (ou classificadores) incluir outras transações em blocos. No geral, a resistência à censura e o imediatismo após um ataque são difíceis de alcançar na maioria dos protocolos de consenso.
Outro algoritmo de consenso que pode ser utilizado é o HotStuff 2, que garante o imediatismo em caso de ataque.
O que ele permite é evitar esperar um atraso máximo da rede (timeout) em caso de censura ou unsigned para eleger um novo masternode. A razão pela qual poderia ser um algoritmo de consenso interessante para um conjunto descentralizado de ordenadores é porque resolve o problema de imediatismo em consenso sem adicionar um estágio extra. Se o masternode conhece o bloqueio mais alto (o maior número de participantes concordando com uma saída específica) e pode convencer as partes honestas, o problema está resolvido. Caso contrário, um masternode honesto após um certo ponto pode se encarregar do push, auxiliando o próximo masternode. Por exemplo, um nó Hotstuff não precisa reconhecer uma mensagem de transição antes de notificar um novo mestre, mas pode alternar diretamente para uma nova exibição e notificar o novo mestre.
A diferença com o Tendermint é que, embora ambos sejam bifásicos (o Hotstuff1 tem três, o Hotstuff2 tem dois), o Tendermint tem comunicação linear, mas não é responsivo, enquanto o Hotstuff2 é reativo. Se houver uma cadeia de masternodes honestos, o protocolo responde positivamente, pois todas as etapas, exceto a proposta do primeiro masternode, dependem da obtenção da quantidade de informações da etapa anterior. Em uma configuração de ordenador compartilhado, isso permite que o protocolo obtenha melhor imediatismo sem cair para a camada inferior, sem cancelar essa possibilidade.
Construção de grupos de classificadores compartilhados
Um conjunto de ordenadores tem permissão para enviar transações para a camada de liquidação (a camada onde reside o Rollup). Você pode ingressar neste grupo de agrupamentos, desde que certos requisitos sejam atendidos e o número necessário de produtores de blocos não tenha sido alcançado. Isso otimiza a latência, a taxa de transferência e muito mais. Esses requisitos são semelhantes aos necessários para se tornar um validador de um blockchain. Por exemplo, você deve atender a certos requisitos de hardware, bem como um depósito inicial, especialmente se quiser oferecer certeza de condições financeiras.
Um grupo de pedidos compartilhado (ou qualquer grupo de pedidos descentralizado) consiste em vários componentes que trabalham juntos para garantir o processamento correto das transações, incluindo:
Forneça JSON-RPC para cada Rollup para envio de transação (para operadores de nó não completo) para o nó como um pool de memória e, em seguida, construa e classifique. No mempool, algum mecanismo é necessário para determinar a fila, bem como o processo de seleção da transação, para garantir a construção eficiente dos blocos.
Algoritmo de construção de blocos/lotes, responsável por processar as transações na fila e convertê-las em blocos ou lotes. Essa etapa também pode incluir compactação para reduzir o tamanho do bloco resultante (chamada compactação de dados). Conforme mencionado, isso deve ser separado do Proponente, essencialmente PBS. Os dados podem ser compactados de várias maneiras, por exemplo:
Sem codificação RLP - no entanto, isso pode exigir um conjunto descentralizado de classificadores para ajudar a normalizar a transferência de dados entre os nós, economizando espaço.
Omitir o nonce (número único que valida dados em um bloco específico) - ele pode ser recalculado em tempo de execução, observando o estado anterior da cadeia.
Simplificação do preço do gás - defina o gás com base em uma faixa de preço fixa.
Simplificação do gás - Além do preço do gás, existe também um sistema de numeração do gás.
Substituir endereço por índice - Rollup pode armazenar um índice de um endereço mapeado em vez de armazenar o endereço completo.
Valores expressos em notação científica - os campos de valor nas transações Ethereum são denominados em wei, portanto os valores são grandes. Você não pode omitir campos numéricos ou reduzi-los a um conjunto fixo de valores. No entanto, você pode escrevê-lo em notação científica para otimizar o armazenamento de dados:
Omissão de campos de dados: Os campos de dados não são obrigatórios para transferências simples, mas sim para transações mais complexas.
Substituir assinaturas individuais por assinaturas agregadas BLS: As assinaturas são o maior componente das transações Ethereum. Em vez de armazenar cada assinatura, você pode armazenar assinaturas agregadas de BLS para um número específico de transações. Você também pode verificar a assinatura agregada do BLS em relação ao conjunto de mensagens e ao conjunto do remetente para garantir sua validade.
Use o campo De como um índice: Assim como o campo Para, você pode usar o campo De como um índice para mapeamento.
Um conceito interessante de design "modular" é que você pode fazer ajustes e compensações conforme necessário para fazê-lo funcionar para o seu Rollup.
A camada peer-to-peer permitirá que os solicitantes recebam transações de outros solicitantes e propaguem blocos após a construção. Essa etapa é crítica para garantir que o sequenciador compartilhado opere com eficiência em vários rollups.
Algoritmo de rotação mestre para conjuntos de ordenadores compartilhados (sem consenso necessário no caso de eleição de mestre único). Você pode optar por definir apenas o algoritmo de rotação do nó mestre ou seguir a rota do produtor de bloco multiconcorrente proposta pelo Duality.
Algoritmos de consenso, como os mencionados Tendermint ou Hotstuff2, podem garantir que os nós Rollup estejam de acordo com a sequência proposta pelo ledger.
Cliente RPC para enviar blocos/lotes para a camada de consenso DA+ subjacente para que os blocos/lotes possam ser adicionados com segurança à camada DA, garantindo a finalidade "final" e disponibilizando todos os dados da transação na cadeia.
Separe as funções de construtores e produtores de blocos para garantir justiça e consistência e evitar roubo de MEV. Também remove a classificação realizada, o que é importante para otimizar a eficiência, reduzir o PGA e aumentar o CR.
*Os nós rollup recebem blocos ordenados do classificador para envio suave e recebem blocos de camada DA ordenados para envio físico. *
O Calldata é publicado primeiro na rede base, onde o consenso é executado para garantir as transações do usuário e do Rollup. Em seguida, o nó Rollup executa a transação e envia uma função de transição de estado para a cadeia Rollup canônica. Uma rede de pedidos compartilhados fornece ao Rollup imediatismo e resistência à censura. Os rollups mantêm sua soberania porque todos os dados da transação são armazenados na camada base, o que permite que eles se bifurquem do ordenador compartilhado a qualquer momento. A raiz de estado da função de transição de estado Rollup (STF) é calculada a partir das raízes de transação (entradas) enviadas do ordenador compartilhado para a camada DA. No Celestia, as raízes de estado são geradas quando os dados são adicionados à cadeia e o consenso é alcançado. Como você já tem a raiz da transação (e todos os dados disponíveis), o Celestia pode fornecer aos clientes leves (nós Rollup em execução no Celestia) uma pequena prova de inclusão.
Para fornecer a experiência do usuário que os usuários esperam, os nós Rollup recebem blocos ordenados (que também são enviados para a camada DA). Isso pode fornecer ao Rollup garantias determinísticas suaves - garantias de que os blocos serão eventualmente ordenados na camada DA, ponto em que os nós do Rollup executam transações e fornecem novas raízes de estado.
Criação de bloco e slot
Para determinar o tempo de criação do bloco, o sequenciador precisa definir o slot. O sequenciador deve enviar lotes em intervalos fixos (normalmente X segundos), onde X é o tempo do slot. Isso garante que as transações sejam processadas de forma rápida e eficiente, porque, caso contrário, o masternode para um slot específico expiraria e perderia a recompensa de assinatura (e recompensa de execução). Por exemplo, o tempo de bloqueio do Celestia (de acordo com as especificações do GitHub) é de cerca de 15 segundos. Como isso é conhecido, podemos fazer algumas suposições sobre quantos "slots/blocos" podemos ter do conjunto compartilhado de coorters para a camada DA e os nós Rollup são carregados em blocos finalizados. A esse respeito, podemos nos referir ao Tendermint ou Hotstuff2 otimizado.
Dentro do mesmo slot, podemos enviar vários lotes de transações, desde que o design inclua mecanismos para Rollup full nodes para processá-los com eficiência em um único bloco (dentro desse período de tempo e parâmetros de timeout). Isso ajuda a otimizar ainda mais a criação de blocos e garante que as transações sejam processadas rapidamente. Além disso, os slots também podem ser usados para facilitar a escolha dos nós mestres do classificador. Por exemplo, você pode selecionar aleatoriamente um nó mestre de slot do pool de piquetagem com base no peso de piquetagem. Fazer isso de forma a preservar a confidencialidade e empregar algo como eleição secreta de líder para minimizar a censura é a melhor opção; ou até mesmo uma configuração de tecnologia de validação distribuída, como soluções como Obol/SSV. A latência e o tempo do slot têm um grande impacto nos envios de blocos e nas compilações do protocolo. Portanto, precisamos ver como isso afeta o sistema. O Bloxroute tem ótimas pesquisas e pontos de dados sobre o Ethereum em particular. No MEV-Boost, os produtores de blocos participantes (validadores ou sequenciadores no caso de Rollup) solicitam GetHeader do relé. Isso dá a eles o valor do lance do bloco, que é o valor de um bloco específico. Este pode ser o bloco de valor mais alto recebido a cada vez. Para cada slot, os validadores geralmente solicitam GetHeader cerca de 400 ms após o início do slot - devido ao grande número de validadores, os relés geralmente precisam enviar várias solicitações. Isso também é o que pode acontecer com grandes grupos de classificadores compartilhados. Isso significa que você precisa da infraestrutura para facilitar esse processo.
Os relés também ajudam a facilitar a separação de construtores e produtores de blocos, ao mesmo tempo em que verificam se os construtores construíram os blocos corretos. Eles também verificam se as taxas são pagas corretamente e atuam como proteção DoS. Além disso, são basicamente os guardiões dos blocos e tratam do cadastro dos validadores. Isso é especialmente importante na arquitetura de um seqüenciador ilimitado, pois você precisa acompanhar quem participou e quem não (por exemplo, a camada de sincronização discutida anteriormente).
Em relação aos tempos de bloqueio (ou seja, bloqueios enviados pelos criadores), eles geralmente ocorrem em torno de 200 milissegundos. Eles geralmente começam a ser executados antes/depois de cerca de 200 ms, embora, como GetHeader, haja uma variação considerável. Se o construtor enviar o bloco para vários relés, isso causará um atraso considerável. O Bloxroute também analisou o que acontece quando os blocos são enviados para vários retransmissores. Como você pode esperar, o atraso para a propagação do bloco para mais relés será maior. Em média, o segundo relé levou 99 milissegundos para passar o bloco, o terceiro 122 milissegundos e o quarto 342 milissegundos.
O que provavelmente aprendemos nos últimos meses é que RPC é muito importante para blockchains. É um fardo enorme sem a infraestrutura adequada, e ter uma opção de RPC adequada também é fundamental. Nesse caso, o RPC é importante para os investidores de varejo que enviam suas transações para o RPC (e o mempool público). O Bloxroute executou um pequeno teste de 20 transações enviadas para vários RPCs e mediu o tempo que cada transação levou para ser incluída em um bloco.
Fonte: Bloxroute Labs
Curiosamente, alguns RPCs não incluem transações até vários blocos depois, dependendo de qual construtor ganha no próximo bloco. Se o RPC enviar a transação para mais construtores, a probabilidade de inclusão rápida é maior. Embora seja possível para os originadores da transação alavancar sua posição única no fluxo de pedidos para atingir construtores específicos ou até mesmo construir seus próprios blocos.
Seu desempenho também é interessante nas estatísticas de desempenho de retransmissão da Ethereum. Isso nos ajuda a obter uma compreensão mais profunda de como o PBS funciona em um mundo de vários validadores/construtores/retransmissores, que é o que esperamos alcançar com a atualização do Rollup. Metrika tem ótimas estatísticas sobre isso e todos os pontos de dados são devidos a eles.
É importante observar que lances perdidos ocorrem quando se espera que um retransmissor lance, mas não lance. As expectativas de destino vêm de validadores registrados com um relé específico para qualquer slot específico. Esta não é uma falha de relé per se, nem é tratada dessa forma no nível do protocolo.
Fonte: app.metrika.co
Se ocorrer uma falha (como um relé atendendo a um bloco inválido) e for responsável, será contada como uma falha. Estes são geralmente pouco frequentes e são principalmente falhas de preferência de registro (ou seja, limites de gás ou taxas que não correspondem aos registros de um validador específico). Ainda mais raras são as falhas da camada de consenso, que são inconsistentes com as regras da camada de consenso do Ethereum, como slots incorretos ou hashes pais não alinhados com o bloco anterior, etc.
Em termos de latência (como o tempo que leva para um validador receber um cabeçalho de bloco criado por um construtor), os dados são muito consistentes. Embora existam alguns valores discrepantes, como o relé solicitado estar em uma localização geográfica diferente do validador escolhido.
Fonte: app.metrika.co
Em relação aos construtores, o número total de construtores no MEV-boost é de cerca de 84, com os três principais construtores construindo cerca de 65% dos blocos construídos. Embora isso possa ser um tanto enganoso, pois esses também são os construtores mais antigos. Os resultados são semelhantes se o período de tempo for reduzido. O número de construtores ativos reais é muito menor, 35 nos últimos 30 dias e 24 na última semana. A competição é acirrada e geralmente o construtor mais forte vence. Pode já existir um fluxo de pedido exclusivo, o que apenas agravará a situação. Esperamos que a distribuição de construtores permaneça relativamente centralizada (uma vez que esta é uma corrida para otimizar o fluxo de pedidos e otimização de hardware), a menos que façamos grandes alterações na configuração. Embora não seja um problema fundamental, ainda é uma força centralizadora na pilha e adoraríamos ouvir ideias sobre como desafiar o status quo aqui. Se você estiver interessado em se aprofundar neste (sério) problema, recomendamos a leitura dos artigos da Quintus sobre fluxo de pedidos, leilões e centralização.
Para a função de Construtor na futura pilha de modularidade, temos certeza (pelo menos na configuração do SDK do Cosmos) que veremos uma configuração de Módulos de Construtor do tipo Skip/Mekatek. Outra solução é uma configuração do tipo SUAVE, como uma cadeia de construtores global específica que fornece serviços de construção de bloco e preferência de lance para qualquer número de cadeias para garantir o PBS. Exploraremos essa solução com mais profundidade posteriormente e forneceremos algumas respostas para perguntas não abordadas aqui.
Em relação aos relés, recomendamos a leitura de um artigo de Ankit Chiplunkar, da Frontier Research, e Mike Neuder, da Ethereum Foundation, chamado Relés otimistas e onde encontrá-los. Este post detalha como os relés no MEV-boost funcionam, suas compensações atuais e custos operacionais e algumas mudanças que podem aumentar a eficiência. Curiosamente, executar um revezamento no MEV-Boost custa atualmente cerca de US$ 100.000/ano, de acordo com as estimativas do Flashbot.
Determinístico
Antes de falarmos sobre o determinismo das blockchains modulares (como elas são atualmente), vamos dar uma olhada em nosso artigo anterior “Modular MEV”. Observe que esta não é uma visão "oficial" nem abrangente da finalidade, mas acreditamos que representa com mais precisão as nuances da finalidade do Rollup para facilitar o entendimento.
Pendente_On_L2: O Rollup orderer representa um compromisso flexível de que a transação de um usuário será finalmente confirmada e finalizada na camada base de sua segurança.
Finality_On_L2: O sequenciador foi comprometido com a função de transição de estado do Rollup e o bloco foi adicionado à cadeia canônica do Rollup.
Pendente_On_L1: A função de entrada ou saída/transição de estado da transação foi publicada em L1, mas a prova de validade ainda não foi emitida ou o período de arbitragem ainda não terminou - isso requer Ethereum por duas épocas consecutivas. Este é o ponto em que a maioria dos Rollups otimistas dizem que atingiram a finalidade, mas ainda há um período de desafio arbitrário de 7 dias neste ponto, de acordo com a especificação da ponte de cadeia cruzada.
Finality_On_L1: Para um Rollup Otimista, o período de arbitragem terminou, ou uma prova de validade publicada e verificada foi confirmada por uma maioria absoluta em duas épocas consecutivas.
Agora, em um Sovereign Shared Sort Rollup, isso parece um pouco diferente, vamos tentar explicar com um diagrama:
Neste caso, teoricamente podemos obter determinismo em L1 antes de L2, etc.? Sim, neste caso L2 é soberano afinal. Isso pressupõe que não haja provas de fraude e períodos de contestação ou que você esteja usando uma prova de validade.
Então, como atingimos esses níveis de finalidade? A finalidade do bloco é alcançada quando um bloco é adicionado à cadeia canônica, que não pode ser retirada. No entanto, existem algumas nuances aqui, dependendo de nós completos ou leves. No caso de um bloco ordenado, é determinístico uma vez que está incluído em um bloco da camada DA. Os blocos (com raízes de estado) são reforçados pelos nós/validadores completos do Rollup, o que lhes dá a garantia de uma raiz de estado válida derivada dos blocos ordenados da camada base. Para determinismo além dos nós completos (como para clientes leves ou pontes de cadeia cruzada), você deve ter certeza da validade dessa raiz de estado. Aqui, você pode usar um dos métodos descritos abaixo. Além disso, outra abordagem é responsabilizar os validadores pela prova correta da raiz do estado (a rota otimista), por meio de um vínculo e posterior prova de fraude. Além disso, você pode fornecer uma prova de validade (ZK).
Diferentes maneiras de alcançar a finalidade do bloco:
Através de Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) e outros métodos probabilísticos.
Um método comprovado por meio de membros suficientes do comitê assinando blocos. (por exemplo, Tendermint 2/3, Hotshot2 ou outros tipos de PBFT)
Depende da ordenação das transações/blocos na camada DA, e das suas regras, nomeadamente regras canónicas de cadeia e seleção de bifurcações.
Podemos alcançar diferentes tipos de finalidade através de diferentes mecanismos.
Um tipo de finalidade é a "finalidade suave" (como pendente), que pode ser alcançada por uma única eleição de líder. Neste caso, cada slot terá apenas um ou zero blocos (confirmados ou não), e a camada de sincronização pode assumir com segurança a sequência de transações nestes blocos.
Outro tipo de finalidade é a "finalidade demonstrável", que fornece garantias mais fortes (essencialmente finais) do que a finalidade suave. Para alcançar a finalidade comprovável, a maioria dos ordenantes deve assinar um bloco, expressando assim sua concordância de que o bloco é canônico. Embora essa abordagem seja boa, ela pode não ser necessária se uma única eleição de líder tiver sido implementada, uma vez que ela essencialmente garante a ordem dos blocos. Obviamente, isso depende do algoritmo específico de eleição de líder que está sendo implementado. Por exemplo, é uma implementação de 51%, uma implementação de 66% ou um único líder (de preferência aleatório (VRF) e eleição secreta). Se você quiser aprender mais sobre o determinismo no Ethereum, leia este artigo que recomendamos e o artigo que recomendamos mais tarde para conjuntos de classificadores ilimitados.
licenciado, semi-licenciado ou não permitido
Para evitar possíveis ataques DoS, barreiras econômicas devem ser definidas para ingressar no grupo de pedidos e enviar transações para a camada de pedidos. Em grupos limitados (número finito de classificadores) e ilimitados (número ilimitado de classificadores), barreiras econômicas devem ser implementadas para enviar lotes à camada DA para evitar que a camada de sincronização (propagação de blocos entre classificadores) fique lenta ou sob ataque DDoS . No entanto, a própria camada DA também fornece alguma proteção, porque o envio de dados a ela requer um custo (da_fee). O depósito de segurança necessário para ingressar no grupo ilimitado deve cobrir quaisquer custos adicionais necessários para evitar que a camada de sincronização seja spam. Por outro lado, a margem necessária para ingressar em um grupo limitado dependerá da demanda (equilibrada do ponto de vista custo/receita).
Para um conjunto ilimitado de classificadores, não podemos obter finalidade demonstrável na camada do classificador (já que nunca sabemos exatamente quantos votantes/assinantes ativos existem). Por outro lado, em um grupo limitado de coorters, a finalidade provável pode ser alcançada pela maioria dos coorters assinando blocos. Isso requer que a camada de sincronização esteja ciente da camada do sequenciador e de quantos sequenciadores estão ativos em um determinado momento, o que representa uma sobrecarga adicional. Em um conjunto limitado de classificadores (por exemplo, até 100), você também pode otimizar o número de classificadores para melhorar o "desempenho", embora às custas da descentralização e da resistência à censura. A importância de grupos limitados e garantias econômicas para fornecer certeza comprovável "rápida" também é determinística.
Os tipos de classificador ilimitado e classificador limitado também são refletidos em blockchains tradicionais. Por exemplo, o PoS (Casper+LMD-GHOST) no Ethereum adota o tipo ilimitado, enquanto a cadeia baseada no Cosmos SDK/Tendermint adota o tipo limitado. Um pensamento interessante é: esperamos ver economia e opções semelhantes à prova de participação da comunidade em torno de pedidos compartilhados? A esse respeito, vimos um movimento em direção à centralização de algumas entidades (portanto, ilimitado realmente não importa se você já possui alguns grandes provedores/pools de proof-of-stake). Apesar de "esconder" a centralização, afinal, você ainda pode minerar se quiser. Do ponto de vista ideológico, as escolhas quase sempre devem ser ilimitadas - mas lembre-se de que os princípios econômicos as tornam muito semelhantes de qualquer maneira. Independentemente de quem são os participantes, a economia do que você paga ainda deve ser a mesma, como o custo do DA e o custo do hardware (embora isso possa ser reduzido pelo número de provas de participação que você aloca e experimenta, e exploração da infra-estrutura). Mesmo no mundo PoS limitado, vimos um grupo de provedores de infraestrutura se tornarem os maiores e mais comuns validadores em quase todas as cadeias. Na maioria das cadeias Cosmos, as dependências entre validadores já são muito grandes, e isso certamente representa um perigo para a descentralização e resistência à censura das referidas cadeias. Ainda assim, um fato muito diferente é que qualquer investidor de varejo pode apostar qualquer quantia com qualquer validador que escolher. Infelizmente, isso geralmente é atribuído ao topo da lista e a vida continua. Perguntamos novamente: esperamos um modelo econômico semelhante em um mundo modular? Alguém gostaria que não fosse o caso, mas com especialização você geralmente precisa do melhor ajuste - e eles tendem a ser provedores profissionais de proof-of-stake. Também abordaremos essas questões econômicas em um capítulo separado posteriormente.
No entanto, uma coisa importante a lembrar em todas essas questões é que o mais importante é a autenticação do usuário final, que está disponível para qualquer pessoa, não importa onde esteja (mesmo em Gizé) por meio de clientes leves e pirâmide DAS).
Fonte: @JosephALChami
Aqui estão as vantagens e desvantagens dos classificadores limitados e ilimitados:
Conjunto classificador ilimitado:
*Qualquer pessoa com títulos/apostas suficientes pode se tornar um classificador = alto grau de descentralização
Não é possível ter uma única eleição de líder, pois o classificador é essencialmente infinito.
A eleição de líder não único via VRF é possível, mas é difícil determinar os parâmetros do VRF porque não se sabe quantos ordenadores haverá. Essa também deve ser uma eleição de líder secreta, se possível, para evitar ataques DoS.
Sem eleição de líder = desperdício de recursos Problema: A construção de blocos é essencialmente uma competição livre, quem enviar o primeiro bloco/lote válido vence e todos os outros perdem. · · · Nenhuma certeza comprovável no nível do pedido, apenas probabilística: por exemplo, LMD Ghost+Casper
A finalização só é alcançada depois que os lotes são gravados na camada DA (limitada apenas pelo tempo de bloqueio subjacente, 15 segundos no caso do Celestia).
Conjuntos ilimitados são "melhores" resistentes à censura do que conjuntos limitados.
Conjunto limitado de classificadores:
Esta é uma das soluções da Ethereum para o determinismo de slot único e possui um comitê de super "maioria".
Há um limite para o número de sequenciadores permitidos em um determinado momento.
Os conjuntos limitados são mais complexos do que os conjuntos ilimitados.
Uma única eleição de líder pode ser implementada, fornecendo uma forte garantia determinística para a camada do classificador.
A camada de sincronização precisa entender o conjunto de ordenadores para determinar quais blocos são válidos.
A gravação de conjuntos de classificadores (ou alterações de conjuntos) em blocos de camada de liquidação (como regras de seleção de bifurcação), que são gravadas na camada DA, permite que a camada de sincronização determine independentemente o conjunto de classificadores. Por exemplo, isso é o que o Rollup do Sovereign Labs faz, as alterações da coleção são gravadas em uma prova de validade publicada na camada DA.
As fortes garantias de finalidade da camada do ordenador podem não ser necessárias se a camada DA for rápida o suficiente (no entanto, a maioria das configurações atuais da camada de liquidação não otimizada tem pelo menos 10+ segundos de tempo de bloco).
Há um espaço de design considerável para como esses conjuntos de classificadores são monitorados e novos membros são adicionados ou removidos. Por exemplo, isso será alcançado por meio da Governança de Tokenholder (que tal muitos Tokens e Rollups diferentes usando coleções então?). Isso significa que a sinalização de mudanças fora da cadeia pode ser possível por meio de consenso social (por exemplo, tome o Ethereum como exemplo). No entanto, lembre-se de que o consenso real na cadeia está claramente estabelecido e já existem penalidades para a violação das regras de consenso.
Mecanismo econômico para classificadores compartilhados
A economia de compartilhar uma rede de sequenciadores permite algumas opções interessantes. Como discutimos anteriormente, os validadores em uma rede de pedidos compartilhados não são muito diferentes dos validadores L1 típicos. A rede da qual ele participa é simplesmente mais otimizada para executar uma tarefa, que é receber intenções (anteriormente PBS) e, portanto, propor e solicitar transações. Assim como os validadores "regulares", existem componentes de receita e custo. Em ambos os lados da equação, há muita flexibilidade nas redes das quais os validadores participam, semelhante ao L1 regular.
A receita vem de usuários ou Rollups com os quais eles desejam interagir pagando uma determinada taxa pelo uso do sequenciador compartilhado. Essa taxa pode ser uma porcentagem do MEV retirado (inserir números pode ser difícil de aproximar), transferências de valor entre cadeias, Gás ou uma taxa fixa por interação. A solução de receita mais apropriada pode ser pagar ao ordenador compartilhado menos valor do que o valor adicional obtido por meio do ordenador compartilhado Rollup, junto com os benefícios de segurança e liquidez compartilhadas. Mas a desvantagem disso é que é difícil quantificar os benefícios da descentralização de outra parte da pilha. No entanto, à medida que a rede de pedidos compartilhados cresce em seu próprio ecossistema, sua capacidade de extrair taxas pode aumentar. Isso se deve em grande parte à sua capacidade inerente de agregar facilmente, com certas economias de escala. À medida que mais Rollups e aplicativos se juntam à rede, mais e mais MEVs entre domínios poderão extrair.
Em termos de custo, as redes de pedidos compartilhados também têm opções concorrentes. Eles podem facilmente financiar seu uso de rede financiando o custo de publicação na camada DA ou até mesmo o custo de interagir com aplicativos no Rollup. Isso é semelhante à estratégia usada pelas empresas da Web 2.0, em que você assume a perda inicial na aquisição (ou rollup) do usuário, esperando que a receita de longo prazo supere as taxas. Outro método mais inovador ou nativo de criptografia é permitir que o Rollup pague taxas DA com seu token nativo. Aqui, a camada de classificador compartilhada carrega o risco de preço entre o Token necessário para publicar dados na camada DA e o Token nativo do Rollup. Em essência, ainda é um custo inicial de classificador compartilhado, mas cria consistência no ecossistema ao obter o Token do "fornecedor" (ou seja, Rollup). Isso é um pouco semelhante à construção do armazém que explicamos no documento AppChain, e diferentes formas de DA podem ser usadas para reduzir custos. Diferentes níveis de DA oferecerão preços diferentes devido à utilização, à capacidade dos usuários de verificar facilmente por meio de um cliente leve ou simplesmente fazer diferentes escolhas de tamanho de bloco. Por fim, o ordenador compartilhado também pode agrupar transações antes de publicar na camada DA. No caso do ZKR, isso pode reduzir os custos de transação através de um determinado número de saldos de transação e, em termos de ORU, você pode realizar várias otimizações de Gás de processamento em lote, que podemos ver atualmente em vários Rollups. Isso reduzirá a quantidade de dados que precisam ser publicados na camada DA, reduzindo assim o custo da rede do sequenciador compartilhado e aumentando a lucratividade de toda a rede. Isso terá o custo de limitar a interoperabilidade e alterar os tempos de finalização do bloco (determinismo em L1, conforme mencionado anteriormente).
No geral, a economia de compartilhar uma rede de sequenciadores permite algumas experiências interessantes e estratégias de inicialização. Estimamos que a principal diferença será o tamanho do ecossistema, portanto, o número de MEVs entre domínios é maior do que o custo. Também recomendamos verificar a postagem no blog da equipe do Espresso sobre pedidos compartilhados, pois eles também cobrem as compensações econômicas (e os pontos positivos) desses tipos de redes. Para mostrar por que o Rollup é motivado a tirar vantagem dos classificadores compartilhados (além da economia), podemos considerá-lo de uma perspectiva da teoria da agregação.
Teoria da Agregação e Classificadores Compartilhados
Outra maneira de descrever as propriedades trazidas pelos classificadores compartilhados é através das lentes da teoria de agregação. A teoria da agregação refere-se ao conceito de como uma plataforma ou agregador integra outras plataformas e seus usuários de maneira sistemática para obter atenção significativa do usuário. Você está essencialmente movendo o jogo da alocação de um recurso escasso (por exemplo, espaço em bloco) para a necessidade de controlar um recurso abundante (novamente, o espaço em bloco faz sentido neste exemplo). A Teoria da Agregação na verdade agrega fornecedores e produtos (ou seja, Rollup e Blockspace) em uma experiência de superusuário para atender à base agregada de usuários. À medida que o efeito de rede desses agregadores cresce, esse relacionamento se torna cada vez mais exclusivo. Quando isso acontece, a experiência do usuário se torna um diferencial importante entre configurações semelhantes. Se houver incentivos para atrair novos usuários (como uma boa experiência do usuário e melhor interoperabilidade), é improvável que o Rollup mude para sua própria rede ou para uma configuração diferente - já que os efeitos da rede impulsionam novos fornecedores e novos usuários se juntam. Isso cria um efeito volante, não apenas da perspectiva do provedor e do usuário, mas também de uma perspectiva agregada de resistência à censura.
Fonte: Teoria da Agregação 2015, Ben Thompson
No reino dos classificadores compartilhados, a Teoria da Agregação pode ser vista como "combinações" e federações de vários Rollups, todos utilizando verticais semelhantes da pilha - capacitando a si mesmos e aos outros enquanto permite que os usuários obtenham a mesma experiência.
Provedores (como Rollups) não são teoricamente exclusivos do conjunto de co-coorter compartilhado, mas na prática o conjunto de co-coorter compartilhado, seus roll-ups e usuários se beneficiam de uma série de loops de efeitos de rede que levam ao aumento do uso desses roll-ups. Esses benefícios facilitam a integração de Rollups e usuários em uma pilha compartilhada porque eles têm mais a perder se não participarem. Embora esses benefícios possam ser difíceis de ver quando você tem apenas dois Rollups compartilhando um único conjunto de sequenciador, eles se tornam mais claros à medida que você adiciona mais e mais Rollups e usuários à equação. Os conjuntos de classificadores compartilhados têm uma relação direta com os usuários, pois eles ordenam suas transações, mesmo que os próprios usuários não saibam que estão interagindo com eles, pois, na perspectiva deles, estão apenas usando Rollups com os quais têm um motivo para interagir ( Isso significa que os pedidos/classificadores se tornam exclusivos). O único custo desses classificadores é realmente o custo de hardware para executá-los, desde que o espaço do bloco e os tokens que o protegem sejam valiosos para o usuário final. As taxas de transação são digitalizadas, pagas com as carteiras dos usuários e, talvez no futuro, podem até ser extraídas por meio de avanços, como hosts de pagamento na abstração da conta (no entanto, alguém terá que arcar com o custo de DA, pedido e execução).
Isso faz mais sentido quando se considera a empresa anterior de Josh e Jordan em Astria - Google. Desde a sua criação, os produtos do Google foram inspirados pela ideia de AT, principalmente na Pesquisa do Google, que é criada pela modularização de páginas e artigos individuais, tornando-os diretamente acessíveis por meio da janela de pesquisa global.
No caso de um conjunto compartilhado de classificadores, os usuários que utilizam Rollups (aqueles que compartilham um conjunto de classificadores) têm custos de aquisição cada vez menores, pois conforme o número de fornecedores (Rollup) aumenta, é provável que sejam atraídos para o conjunto . Isso significa que, na maioria dos casos, um agregador (ou multi-agregador) tem um possível efeito ganha-ganha, pois o valor de um agregador aumenta com o número de fornecedores (desde que a experiência do usuário seja boa, é claro). Em contraste, em uma única rede serial, a aquisição de clientes é limitada a uma única rede e suas aplicações. Se os usuários quiserem usar o aplicativo Rollup em um Rollup diferente, eles terão que (dentro das limitações atuais) fazer logoff da rede completamente. Isso significa que a aderência e o valor do usuário não são muito altos e também significa que, a qualquer momento, se outro ecossistema Rollup for altamente valorizado (ou tiver mais incentivos), o capital poderá ser perdido.
Resumo de atributos e compensações
Atributos
Um conjunto de classificador compartilhado é uma rede de rollup que agrega e classifica transações para vários rollups. Esses Rollups compartilham o mesmo classificador. Esse agrupamento de recursos significa que os Rollups obtêm segurança econômica mais forte e recursos anticensura, que podem fornecer garantias determinísticas suaves rápidas e transações condicionais cross-Rollup.
No momento, há muito barulho sobre atomicidade entre Rollups que compartilham o mesmo conjunto de classificadores, principalmente sobre se é atômico por padrão - o que não é. No entanto, se os Rollups em questão implementam as funções de transição de estado (STFs) uns dos outros como dependências entre eles, envolvendo transações condicionais, então eles podem de fato alcançar atomicidade entre eles - desde que seu alinhamento de slot/blocktime (como com conjuntos de classificadores compartilhados). Nesse caso, para obter a interoperabilidade atômica, você realmente só precisa executar um cliente leve da cadeia B na cadeia A e vice-versa (semelhante ao funcionamento do IBC). Para fortalecer ainda mais a interoperabilidade das medidas de segurança (além de confiar em um único nó completo como um nó leve), você pode implementar o ZKP (Prova de Estado) para resolver o "problema do oráculo" de garantir a exatidão do estado. Isso tornará mais claro para ver se uma transação condicional ou algo parecido atingiu uma ponte de cadeia cruzada canônica entre eles. Provas de fraude também são uma possibilidade, mas obviamente deixariam um período de contestação (o que significa que um terceiro viria para cobrir o custo desse risco). Além disso, no caso de light clients (em vez de full nodes), haverá pelo menos um quarteirão de atraso devido à espera do cabeçalho da assinatura + janela à prova de fraude (se houver).
Acreditamos que o problema da "ponte entre cadeias" tem maior probabilidade de ser resolvido com clientes leves e provas de conhecimento zero. O desafio de usar um cliente leve (em vez de um contrato inteligente) nesse caso é que os hard forks (atualizações etc.) o mesmo módulo de estado). Se você quiser mergulhar mais fundo neste tópico específico (e como abordá-lo), recomendamos que você confira esta apresentação.
A razão pela qual os pedidos compartilhados escalam tão bem é que eles não executam e armazenam nenhum estado (como os pedidos centralizados fazem hoje). O mesmo vale para os próprios nós Rollup (a menos que eles desejem atomicidade entre eles - por exemplo, cliente leve/prova de estado). Esses nós executam apenas transações que são válidas para seu Rollup e quaisquer transações entre domínios condicionais que sejam válidas para eles. Se um nó Rollup tiver que executar e armazenar o estado para vários Rollups, isso prejudicará a escalabilidade e reduzirá a descentralização (e, portanto, a resistência à censura). Isso também reforça o conceito de separação produtor-construtor (PBS) de blocos. Embora ainda precisemos separar completamente os construtores e os produtores de blocos. Na configuração atual, os ordenadores são essencialmente construtores e produtores de blocos (embora não executem transações). Uma configuração ideal pode ser aquela em que o solicitante existe apenas para assinar blocos cegamente de uma configuração de construtor altamente otimizada e garantir que os blocos sejam implementados corretamente (enquanto fornece um alto grau de certeza econômica e resistência à censura para essa certificação). Dessa forma, eles podem fornecer um alto grau de segurança e comprometimento para garantir soft finality aos nós Rollup.
Para transações condicionais de rollup cruzado, eles também existem para ajudar a habilitar os nós de rollup (executores) para fornecer raízes de estado intermediárias, permitindo atomicidade entre rollups.
troca
O parâmetro de tempo limite mencionado acima tem alguns efeitos interessantes no MEV e na inclusão da transação, dependendo do mecanismo de masternode/consenso do conjunto do ordenador. Por exemplo, se o parâmetro de tempo limite for descrito como relativamente curto em nosso documento de cadeia específico do aplicativo, é fundamental que os produtores de blocos de um conjunto descentralizado de solicitantes publiquem dados o mais rápido possível. Em tal mundo, você pode ver a competição entre "validadores" que competem para ser os nós mestres e fazem lances na camada DA por espaço em bloco até que não seja mais lucrativo.
Como Evan abordou em seu post original de pedido preguiçoso nos fóruns do Celestia, esperar que as transações sejam publicadas na camada base (Celestia, neste caso) antes de executá-las é muito ineficiente. Desde agora você está limitado pelo tempo de bloqueio da camada base - que é muito longo para esperar pela experiência do usuário. Para uma melhor experiência do usuário, o ordenador compartilhado fornece Rollups com compromissos determinísticos suaves (conforme descrito anteriormente), que fornecem aos usuários a experiência do usuário a que estão acostumados em Rollups centralizados existentes (mantendo a descentralização e alta resistência à censura). Os compromissos suaves são essencialmente apenas compromissos para a ordem final das transações, mas apoiados por pesadas garantias econômicas e finalização rápida, uma vez emitidos. Isso também é coberto por provas de fraude (como mencionado na introdução). A finalidade definitiva real é alcançada depois que todos os dados da transação foram publicados na camada base (o que significa que L1 realmente atinge a finalidade mais rápida). Depende se o Rollup usa provas de fraude ou provas de conhecimento zero para sua verificação de prova de soberania - o que acontece no Rollup. A razão para querer essa separação é remover o enorme gargalo das transições de estado do classificador. Em vez disso, os nós Rollup lidam apenas com nós que são válidos para eles (o que significa que temos que adicionar transações condicionais, prova de estado ou validação de nó leve para interoperabilidade adequada). O determinismo rígido ainda depende da camada base (mas isso pode chegar a 15 segundos no Celestia e também é determinístico no Tendermint), o que nos dá garantias de determinismo rígido relativamente rápido no Rollup.
Use provas de conhecimento zero dentro da rede para otimizar a validação, o tamanho da transação (por exemplo, apenas publicar diferenças de estado - mas isso adiciona um nível mais alto de confiança até que o ZKP seja publicado). Conforme mencionado anteriormente, essas provas de estado podem ser usadas para permitir que as cadeias/rollups conectados tenham interoperabilidade mais fácil e rápida (sem esperar por janelas de desafio).
Uma desvantagem dessas transações condicionais é que elas provavelmente serão mais caras, exigindo custos mais altos de verificação e emissão (como o custo da verificação do cabeçalho do bloco Tendermint, que é subsidiado na rede Cosmos) e adicionando alguma latência ao sistema ( mas ainda mais rápido que Rollups isolados são muito mais rápidos). A atomicidade alcançada pela integração compartilhada verticalmente pode compensar esses problemas.
Durante a fase inicial de um novo rollup, usar um conjunto compartilhado de collators faz muito sentido, e as vantagens que você ganha como provedor provavelmente superarão algumas das compensações que você pode ser "forçado" a fazer no nível do fosso. Porém, para um Rollup já maduro, onde há muitas transações e atividade econômica, provavelmente não faz sentido abrir mão de parte do fosso.
Isso levanta a questão de saber se precisamos de uma redistribuição ponderada econômica/transacional (por Rollup) similar de MEV extraído para induzir Rollups já maduros a se juntarem ao conjunto compartilhado - ou mesmo evitar que Rollups extremamente maduros gerem sua própria rede. Tudo isso é bastante teórico, mas é sem dúvida um processo de pensamento interessante em relação a como os MEVs em mundos verticais compartilhados serão representados entre muitos Rollups com níveis variados de atividade. Por exemplo, se um Rollup exclusivo que gera valor compartilha alguns desses lucros com outros (provavelmente não trazendo muito "valor") por meio do Conjunto do Sequenciador, deve haver mais motivos para eles mudarem para seu próprio sistema de silos. Sreeram de EigenLayr também tem algumas reflexões sobre isso, que recomendamos a leitura também.
Isso se torna cada vez mais importante quando se considera que há um custo técnico considerável para os pesquisadores desenvolverem novas cadeias, portanto, padronizar e fornecer alguma soberania sobre "seus" MEVs pode ser um bom ponto de partida. Na prática, no MEV, a interface dominante (ou software) pode vencer, mas, na verdade, monetizar esse software executando partes críticas da infraestrutura é muito difícil (levando à centralização). No nível do mercado, o que um ordenador compartilhado fornece é basicamente um mempool comum para múltiplos provedores, com um leilão centralizado, o que pode levar a uma competição mais saudável.
Uma preocupação aqui é que, se dois Rollups estiverem executando classificadores no conjunto compartilhado, um Rollup com valor "menos econômico" (A) pode ser selecionado para propor um rollup com uma alta quantidade de MEV + taxas dos blocos Rollup (B). . Do ponto de vista do Rollup B, eles essencialmente perdem algum valor que, na abordagem isolada, eles manteriam para si mesmos.
Lidando com compensações de interoperabilidade
Segue outra observação sobre as compensações apresentadas pela interoperabilidade e outra maneira de resolver alguns dos problemas:
O objetivo da rede de pedidos compartilhados é fornecer uma garantia canônica para várias cadeias, o que obviamente é uma grande vantagem nesse caso. Isso pode ser combinado com um mecanismo para garantir transições de estado eficientes entre Rollups. Pode ser uma abordagem baseada em comitê (por exemplo, PoS), provas seguras (a abordagem otimista) ou nossa preferida - um ZKP apoiado por assinaturas de comitê. Como os classificadores compartilhados são "preguiçosos", eles apenas criam super blocos para classificar as transações de vários Rollups, e a execução da transação específica é deixada para um Rollup específico. Provas de estado (ou seja, Lagrange, Axiom ou Herodotus, etc.) são todas as soluções possíveis para potencialmente obter provas de finalidade em rollups soberanos. Você pode até adicionar provas de finalidade economicamente garantida por meio de coisas como staking pools, EigenLayr, etc. A ideia básica é que um classificador compartilhado fornece uma garantia econômica de ordenação, e as provas de validade geradas a partir dessa classificação são determinísticas. A ideia básica é que Rollups podem executar transações de forma síncrona entre si. Por exemplo, uma rede de dois nós Rollup pode saber condicionalmente que ambos os históricos Rollup são válidos, via ZKP e dados disponíveis (dados publicados em uma camada DA eficiente). Ao publicar um único prefixo de bloco Rollup de ambas as redes A e B, um nó Rollup pode liquidar dois Rollups simultaneamente. Uma coisa a apontar é que as transações cross-rollup condicionais consomem recursos de dois sistemas separados por meio de execução compartilhada, portanto, as transações atômicas (ou síncronas) de rollup cruzado provavelmente serão mais caras do que as intratransações de rollup único.
Sucinct também cobriu transações "atômicas" de cadeia cruzada entre Rollups com pedidos compartilhados (e provadores de fraude compartilhados) dentro do ecossistema de hipercadeia Optimism, que pode ser visto aqui. Além disso, como Bo Du da Polymer coloca: "Transações atômicas de cadeia cruzada são como adquirir bloqueios entre fragmentos de banco de dados na gravação".
O futuro da integração vertical
O possível funcionamento interno das cadeias SUAVE já foi explorado em profundidade por Jon Charbonneau et al, portanto não entraremos em muitos detalhes. Se você quiser uma descrição mais detalhada, pode conferir o artigo dele. No entanto, achamos que a integração vertical merece uma introdução separada, tanto para destacar como podemos ser modulares (e por quê) quanto para apresentar algumas das questões e preocupações associadas à integração vertical.
Embora o atual esquema de pedidos compartilhados da Astria, Espresso e Radius seja muito modular, os pedidos ainda atuam como construtores e produtores de blocos (embora no caso de Astria, eles não executem transações). A Astria também vem incorporando ativamente o PBS em sua arquitetura desde o início.
Se o PBS não estiver embutido no protocolo, existem várias maneiras de implementar o PBS (embora com vários graus de descentralização). Produtos como SUAVE, usam modelos off-line como MEV-Boost ou implementam módulos construtores, como os módulos Cosmos SDK criados por Mekatek e Skip.
Vale a pena notar que nenhum desses métodos é mutuamente exclusivo. Você tem a flexibilidade de usar vários métodos diferentes e permite que qualquer pessoa expresse sua preferência. Dessa forma, você pode ter executores competindo para preencher essas vagas. Adicionar mais opções é sempre bom (e consistente com nossa crença na modularidade). Ainda assim, diferentes implementações terão diferentes compensações. Por exemplo, em um caso como o SUAVE, você pode adicionar proteção de privacidade por meio da tecnologia SGX ou Crypto e adicionar segurança econômica Crypto à verdade, em vez de depender de um construtor de PBS centralizado totalmente confiável. (Obrigado a Jon Charbonneau por seu feedback aqui).
A integração vertical na cadeia do construtor garante justiça sem usar atalhos, adicionando latência e degradando o desempenho. Portanto, a cadeia do construtor precisa ser altamente otimizada e pode exigir hardware caro e poderoso (levando à centralização). Isso significa que, para obter a validação do usuário final, provavelmente precisaríamos de algum tipo de nós leves (embora eles tivessem que confiar nos nós completos) ou utilizar uma configuração de tipo de prova de estado para garantir que a cadeia e os usuários tenham provas de que as preferências de lance estão preenchidos e os blocos estão corretos Construir.
Uma cadeia como essa pode ser muito pesada em estado (queremos evitar isso), embora essas transações pesadas em estado sejam priorizadas por meio de contratos inteligentes. No caso de lance prioritário, ou ele é preenchido ou não é preenchido (por um curto período de tempo), pois os lances geralmente são válidos por um curto período de tempo, dependendo da preferência. Isso significa que podemos implementar uma expiração de estado muito eficiente (e antecipada) para licitações - o que nos permitirá podar os dados e manter a cadeia "limpa". Essa data de expiração precisa ser longa o suficiente para permitir que os lances sejam preenchidos primeiro, mas baixá-la demais tornaria quase impossível alcançar futuros de espaço de bloco. Não precisamos atualizar e recuperar contratos de licitação expirados, pois eles não precisam existir para sempre (ao contrário dos aplicativos) - isso pode ser feito fornecendo provas de estado/armazenamento quando as licitações são preenchidas ou por soluções de armazenamento DAS (como propostas by Joachim Neu) para torná-lo mais "seguro" e confiável.
Conforme mencionado anteriormente, a necessidade de verificar a "autenticidade" do SUAVE pode estar limitada aos "jusha" (usuários avançados) da plataforma, pois a maioria dos usuários e clientes do SUAVE podem obter altos benefícios econômicos com isso. Isso pode nos levar a permitir que as pessoas executem nós completos apenas se quiserem validar - embora isso exclua a grande maioria das pessoas (você poderia dizer que elas não precisam validar). Isso é (em nossa opinião) o oposto de Crypto, onde preferimos implementar a verificação SUAVE "sem confiança" por meio de provas de estado ou implementações leves amigáveis ao cliente.
A razão pela qual isso é necessário é que você deseja verificar se sua prioridade de lance foi preenchida corretamente e se o bloco foi preenchido com as informações corretas no momento do pagamento (para evitar reagrupamento e outros bugs). Este é essencialmente um problema de oráculo - na verdade, pode ser resolvido com uma prova de estado (como é o caso de todos os SUAVEs). No entanto, essas provas de estado trazem outro problema ao cruzar as cadeias, como retransmitir essas informações pelas cadeias de uma forma que não tenha sido adulterada ou ocultada? Isso pode exigir passar por uma forte finalidade econômica (como a proposta por Lagrangian), caso em que você pode usar os validadores de restaking do EigenLayr para provar a finalidade e a autenticidade da cadeia e ter restrições econômicas muito fortes. Isso então traz outro problema (por exemplo, o contrato de licitação estipula que a "máquina oracular" - neste caso o re-pledger - designou o Token prometido e forneceu ligação econômica - mas como fazemos um consenso entre cortar externamente isso? Enquanto você pode escrever critérios de corte, isso não é consenso, o que significa que o corte social será explorado por meio de contratos inteligentes (o que quase nunca é "justo" e pode causar problemas). .
Então, onde isso nos deixa? Possivelmente, até obtermos uma redução "inconfiável" na cadeia além do consenso, cadeias como SUAVE podem precisar de seus próprios algoritmos de consenso e segurança criptoeconômica para provar as preferências de lance e construir a certeza do bloco - No entanto, isso significa adicionar mais vetores de ataque criptoeconômico, especialmente se o Rollup valor de seus blocos de construção é muito maior do que sua própria segurança criptoeconômica.
Além disso, ainda há muito espaço de design em cadeias do tipo SUAVE e MEVs de domínio cruzado. Aqui estão algumas possíveis direções de pesquisa:
Correspondência de intenção e sistemas baseados em intenção
Otimização convexa na negociação de vários ativos
ADSL
Realocação de MEV
Guerra atrasada
Problema de dimensionamento com um único conjunto de atores, mas precisa ser criado para várias máquinas de estado Rollup
Expressão de preferência
Em relação à expressão de preferência, para interagir com um contrato inteligente no EVM, é necessário enviar uma chamada de contrato (mensagem) para uma função específica no endereço do código implantado contendo a instrução de execução. Embora os usuários forneçam entrada, eles podem não ter controle sobre a saída devido à possível propriedade de estado.
Em contraste, os sistemas de design de expressão de preferência (como SUAVE e Anoma) exigem apenas que os usuários assinem suas preferências com um título, que é pago aos construtores e produtores de blocos se as preferências do pesquisador forem atendidas. Para lógica combinatória complexa, como sequências de transações para buscadores e construtores MEV, diferentes linguagens e máquinas virtuais podem precisar ser implementadas. Este é um novo espaço de design que tem recebido muita atenção ultimamente, especialmente a arquitetura Anoma. Além disso, recomendamos este pequeno artigo.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Classificador Compartilhado 4D Detalhado: Princípio de Funcionamento, Teoria de Agregação e Integração Vertical
Título original: "The Shared Sequencer"
Escrito por: MAVEN11
Compilação: Kxp, BlockBeats
Imagine como seria se o Rollup "pronto para uso" pudesse atingir um alto grau de resistência à censura, facilidade de implantação, interoperabilidade, finalização rápida, vivacidade e democratização do MEV. Isso pode parecer um grande objetivo, mas com o advento do Sequenciador Compartilhado, pode se tornar realidade em breve. No entanto, nem todos os Rollups são iguais, então temos que considerar como distribuir as recompensas e o MEV na rede do sequenciador compartilhado. Neste artigo, exploramos como as redes de classificação compartilhada são implementadas e as propriedades que podem ser alcançadas.
Shared Sequencer Networks foi apresentado principalmente por Alex Beckett, mais tarde por Evan Forbes (e Radius) das equipes Celestia e Espresso, e um novo artigo de Jon Charbonneau que cobre o tópico com mais profundidade. Josh, Jordan e sua equipe Astria estão construindo a primeira rede de sequenciador compartilhado pronta para produção. A Shared Orderer Network da Astria é uma blockchain modular que agrega e ordena as transações do Rollup sem executá-las.
Na configuração do Astria, o classificador envia os blocos ordenados para a camada DA e também para os nós Rollup. Os rollups obtêm garantias de finalidade flexível do ordenador e garantias de finalidade definitiva da camada DA (após a finalização dos blocos) e, em seguida, executarão transações válidas.
A rede de sequenciadores compartilhados é essencialmente um grupo de sequenciadores compatíveis com Rollup, como o próprio nome sugere, pode fornecer serviços para diferentes Rollups. Isso tem várias compensações e propriedades, que detalharemos mais adiante. Primeiro, devemos descrever as propriedades mais importantes de um classificador (ou conjunto de classificadores). No Rollup, o principal requisito para um sequenciador ou grupo de sequenciadores é a resistência à censura ou vivacidade (algumas das quais vêm da camada base, assim como a segurança). Isso significa que uma transação válida enviada ao solicitante deve ser incluída na cadeia em um período de tempo finito (parâmetro timeout). O grupo de pedidos compartilhados só precisa garantir que as transações sejam incluídas em blocos (ou seja, crLists).
Satisfazer a resistência à censura e o imediatismo ao mesmo tempo é bastante difícil, como descrevemos no Modular MEV Parte II. Em um algoritmo de consenso como o Tendermint, você pode garantir a recuperação após um ataque. No entanto, no caso de um ataque, você perde o imediatismo. Basicamente, exigir que todos os outros agrupadores assinem um bloco, em vez de eleger um masternode personalizado, provavelmente não é o ideal. Embora isso melhore a resistência à censura, tem o custo de "centralização" e extração de MEV para um único masternode. Outro mecanismo de classificação disponível pode ser comparado ao Multiplicity do Duality, que é sua pequena ferramenta para não-masternodes (ou classificadores) incluir outras transações em blocos. No geral, a resistência à censura e o imediatismo após um ataque são difíceis de alcançar na maioria dos protocolos de consenso.
Outro algoritmo de consenso que pode ser utilizado é o HotStuff 2, que garante o imediatismo em caso de ataque.
O que ele permite é evitar esperar um atraso máximo da rede (timeout) em caso de censura ou unsigned para eleger um novo masternode. A razão pela qual poderia ser um algoritmo de consenso interessante para um conjunto descentralizado de ordenadores é porque resolve o problema de imediatismo em consenso sem adicionar um estágio extra. Se o masternode conhece o bloqueio mais alto (o maior número de participantes concordando com uma saída específica) e pode convencer as partes honestas, o problema está resolvido. Caso contrário, um masternode honesto após um certo ponto pode se encarregar do push, auxiliando o próximo masternode. Por exemplo, um nó Hotstuff não precisa reconhecer uma mensagem de transição antes de notificar um novo mestre, mas pode alternar diretamente para uma nova exibição e notificar o novo mestre.
A diferença com o Tendermint é que, embora ambos sejam bifásicos (o Hotstuff1 tem três, o Hotstuff2 tem dois), o Tendermint tem comunicação linear, mas não é responsivo, enquanto o Hotstuff2 é reativo. Se houver uma cadeia de masternodes honestos, o protocolo responde positivamente, pois todas as etapas, exceto a proposta do primeiro masternode, dependem da obtenção da quantidade de informações da etapa anterior. Em uma configuração de ordenador compartilhado, isso permite que o protocolo obtenha melhor imediatismo sem cair para a camada inferior, sem cancelar essa possibilidade.
Construção de grupos de classificadores compartilhados
Um conjunto de ordenadores tem permissão para enviar transações para a camada de liquidação (a camada onde reside o Rollup). Você pode ingressar neste grupo de agrupamentos, desde que certos requisitos sejam atendidos e o número necessário de produtores de blocos não tenha sido alcançado. Isso otimiza a latência, a taxa de transferência e muito mais. Esses requisitos são semelhantes aos necessários para se tornar um validador de um blockchain. Por exemplo, você deve atender a certos requisitos de hardware, bem como um depósito inicial, especialmente se quiser oferecer certeza de condições financeiras.
Um grupo de pedidos compartilhado (ou qualquer grupo de pedidos descentralizado) consiste em vários componentes que trabalham juntos para garantir o processamento correto das transações, incluindo:
Forneça JSON-RPC para cada Rollup para envio de transação (para operadores de nó não completo) para o nó como um pool de memória e, em seguida, construa e classifique. No mempool, algum mecanismo é necessário para determinar a fila, bem como o processo de seleção da transação, para garantir a construção eficiente dos blocos.
Algoritmo de construção de blocos/lotes, responsável por processar as transações na fila e convertê-las em blocos ou lotes. Essa etapa também pode incluir compactação para reduzir o tamanho do bloco resultante (chamada compactação de dados). Conforme mencionado, isso deve ser separado do Proponente, essencialmente PBS. Os dados podem ser compactados de várias maneiras, por exemplo:
Omissão de campos de dados: Os campos de dados não são obrigatórios para transferências simples, mas sim para transações mais complexas.
Substituir assinaturas individuais por assinaturas agregadas BLS: As assinaturas são o maior componente das transações Ethereum. Em vez de armazenar cada assinatura, você pode armazenar assinaturas agregadas de BLS para um número específico de transações. Você também pode verificar a assinatura agregada do BLS em relação ao conjunto de mensagens e ao conjunto do remetente para garantir sua validade.
Use o campo De como um índice: Assim como o campo Para, você pode usar o campo De como um índice para mapeamento.
Um conceito interessante de design "modular" é que você pode fazer ajustes e compensações conforme necessário para fazê-lo funcionar para o seu Rollup.
Algoritmo de rotação mestre para conjuntos de ordenadores compartilhados (sem consenso necessário no caso de eleição de mestre único). Você pode optar por definir apenas o algoritmo de rotação do nó mestre ou seguir a rota do produtor de bloco multiconcorrente proposta pelo Duality.
Algoritmos de consenso, como os mencionados Tendermint ou Hotstuff2, podem garantir que os nós Rollup estejam de acordo com a sequência proposta pelo ledger.
Cliente RPC para enviar blocos/lotes para a camada de consenso DA+ subjacente para que os blocos/lotes possam ser adicionados com segurança à camada DA, garantindo a finalidade "final" e disponibilizando todos os dados da transação na cadeia.
Separe as funções de construtores e produtores de blocos para garantir justiça e consistência e evitar roubo de MEV. Também remove a classificação realizada, o que é importante para otimizar a eficiência, reduzir o PGA e aumentar o CR.
*Os nós rollup recebem blocos ordenados do classificador para envio suave e recebem blocos de camada DA ordenados para envio físico. *
O Calldata é publicado primeiro na rede base, onde o consenso é executado para garantir as transações do usuário e do Rollup. Em seguida, o nó Rollup executa a transação e envia uma função de transição de estado para a cadeia Rollup canônica. Uma rede de pedidos compartilhados fornece ao Rollup imediatismo e resistência à censura. Os rollups mantêm sua soberania porque todos os dados da transação são armazenados na camada base, o que permite que eles se bifurquem do ordenador compartilhado a qualquer momento. A raiz de estado da função de transição de estado Rollup (STF) é calculada a partir das raízes de transação (entradas) enviadas do ordenador compartilhado para a camada DA. No Celestia, as raízes de estado são geradas quando os dados são adicionados à cadeia e o consenso é alcançado. Como você já tem a raiz da transação (e todos os dados disponíveis), o Celestia pode fornecer aos clientes leves (nós Rollup em execução no Celestia) uma pequena prova de inclusão.
Para fornecer a experiência do usuário que os usuários esperam, os nós Rollup recebem blocos ordenados (que também são enviados para a camada DA). Isso pode fornecer ao Rollup garantias determinísticas suaves - garantias de que os blocos serão eventualmente ordenados na camada DA, ponto em que os nós do Rollup executam transações e fornecem novas raízes de estado.
Criação de bloco e slot
Para determinar o tempo de criação do bloco, o sequenciador precisa definir o slot. O sequenciador deve enviar lotes em intervalos fixos (normalmente X segundos), onde X é o tempo do slot. Isso garante que as transações sejam processadas de forma rápida e eficiente, porque, caso contrário, o masternode para um slot específico expiraria e perderia a recompensa de assinatura (e recompensa de execução). Por exemplo, o tempo de bloqueio do Celestia (de acordo com as especificações do GitHub) é de cerca de 15 segundos. Como isso é conhecido, podemos fazer algumas suposições sobre quantos "slots/blocos" podemos ter do conjunto compartilhado de coorters para a camada DA e os nós Rollup são carregados em blocos finalizados. A esse respeito, podemos nos referir ao Tendermint ou Hotstuff2 otimizado.
Dentro do mesmo slot, podemos enviar vários lotes de transações, desde que o design inclua mecanismos para Rollup full nodes para processá-los com eficiência em um único bloco (dentro desse período de tempo e parâmetros de timeout). Isso ajuda a otimizar ainda mais a criação de blocos e garante que as transações sejam processadas rapidamente. Além disso, os slots também podem ser usados para facilitar a escolha dos nós mestres do classificador. Por exemplo, você pode selecionar aleatoriamente um nó mestre de slot do pool de piquetagem com base no peso de piquetagem. Fazer isso de forma a preservar a confidencialidade e empregar algo como eleição secreta de líder para minimizar a censura é a melhor opção; ou até mesmo uma configuração de tecnologia de validação distribuída, como soluções como Obol/SSV. A latência e o tempo do slot têm um grande impacto nos envios de blocos e nas compilações do protocolo. Portanto, precisamos ver como isso afeta o sistema. O Bloxroute tem ótimas pesquisas e pontos de dados sobre o Ethereum em particular. No MEV-Boost, os produtores de blocos participantes (validadores ou sequenciadores no caso de Rollup) solicitam GetHeader do relé. Isso dá a eles o valor do lance do bloco, que é o valor de um bloco específico. Este pode ser o bloco de valor mais alto recebido a cada vez. Para cada slot, os validadores geralmente solicitam GetHeader cerca de 400 ms após o início do slot - devido ao grande número de validadores, os relés geralmente precisam enviar várias solicitações. Isso também é o que pode acontecer com grandes grupos de classificadores compartilhados. Isso significa que você precisa da infraestrutura para facilitar esse processo.
Os relés também ajudam a facilitar a separação de construtores e produtores de blocos, ao mesmo tempo em que verificam se os construtores construíram os blocos corretos. Eles também verificam se as taxas são pagas corretamente e atuam como proteção DoS. Além disso, são basicamente os guardiões dos blocos e tratam do cadastro dos validadores. Isso é especialmente importante na arquitetura de um seqüenciador ilimitado, pois você precisa acompanhar quem participou e quem não (por exemplo, a camada de sincronização discutida anteriormente).
Em relação aos tempos de bloqueio (ou seja, bloqueios enviados pelos criadores), eles geralmente ocorrem em torno de 200 milissegundos. Eles geralmente começam a ser executados antes/depois de cerca de 200 ms, embora, como GetHeader, haja uma variação considerável. Se o construtor enviar o bloco para vários relés, isso causará um atraso considerável. O Bloxroute também analisou o que acontece quando os blocos são enviados para vários retransmissores. Como você pode esperar, o atraso para a propagação do bloco para mais relés será maior. Em média, o segundo relé levou 99 milissegundos para passar o bloco, o terceiro 122 milissegundos e o quarto 342 milissegundos.
O que provavelmente aprendemos nos últimos meses é que RPC é muito importante para blockchains. É um fardo enorme sem a infraestrutura adequada, e ter uma opção de RPC adequada também é fundamental. Nesse caso, o RPC é importante para os investidores de varejo que enviam suas transações para o RPC (e o mempool público). O Bloxroute executou um pequeno teste de 20 transações enviadas para vários RPCs e mediu o tempo que cada transação levou para ser incluída em um bloco.
Fonte: Bloxroute Labs
Curiosamente, alguns RPCs não incluem transações até vários blocos depois, dependendo de qual construtor ganha no próximo bloco. Se o RPC enviar a transação para mais construtores, a probabilidade de inclusão rápida é maior. Embora seja possível para os originadores da transação alavancar sua posição única no fluxo de pedidos para atingir construtores específicos ou até mesmo construir seus próprios blocos.
Seu desempenho também é interessante nas estatísticas de desempenho de retransmissão da Ethereum. Isso nos ajuda a obter uma compreensão mais profunda de como o PBS funciona em um mundo de vários validadores/construtores/retransmissores, que é o que esperamos alcançar com a atualização do Rollup. Metrika tem ótimas estatísticas sobre isso e todos os pontos de dados são devidos a eles.
É importante observar que lances perdidos ocorrem quando se espera que um retransmissor lance, mas não lance. As expectativas de destino vêm de validadores registrados com um relé específico para qualquer slot específico. Esta não é uma falha de relé per se, nem é tratada dessa forma no nível do protocolo.
Fonte: app.metrika.co
Se ocorrer uma falha (como um relé atendendo a um bloco inválido) e for responsável, será contada como uma falha. Estes são geralmente pouco frequentes e são principalmente falhas de preferência de registro (ou seja, limites de gás ou taxas que não correspondem aos registros de um validador específico). Ainda mais raras são as falhas da camada de consenso, que são inconsistentes com as regras da camada de consenso do Ethereum, como slots incorretos ou hashes pais não alinhados com o bloco anterior, etc.
Em termos de latência (como o tempo que leva para um validador receber um cabeçalho de bloco criado por um construtor), os dados são muito consistentes. Embora existam alguns valores discrepantes, como o relé solicitado estar em uma localização geográfica diferente do validador escolhido.
Fonte: app.metrika.co
Em relação aos construtores, o número total de construtores no MEV-boost é de cerca de 84, com os três principais construtores construindo cerca de 65% dos blocos construídos. Embora isso possa ser um tanto enganoso, pois esses também são os construtores mais antigos. Os resultados são semelhantes se o período de tempo for reduzido. O número de construtores ativos reais é muito menor, 35 nos últimos 30 dias e 24 na última semana. A competição é acirrada e geralmente o construtor mais forte vence. Pode já existir um fluxo de pedido exclusivo, o que apenas agravará a situação. Esperamos que a distribuição de construtores permaneça relativamente centralizada (uma vez que esta é uma corrida para otimizar o fluxo de pedidos e otimização de hardware), a menos que façamos grandes alterações na configuração. Embora não seja um problema fundamental, ainda é uma força centralizadora na pilha e adoraríamos ouvir ideias sobre como desafiar o status quo aqui. Se você estiver interessado em se aprofundar neste (sério) problema, recomendamos a leitura dos artigos da Quintus sobre fluxo de pedidos, leilões e centralização.
Para a função de Construtor na futura pilha de modularidade, temos certeza (pelo menos na configuração do SDK do Cosmos) que veremos uma configuração de Módulos de Construtor do tipo Skip/Mekatek. Outra solução é uma configuração do tipo SUAVE, como uma cadeia de construtores global específica que fornece serviços de construção de bloco e preferência de lance para qualquer número de cadeias para garantir o PBS. Exploraremos essa solução com mais profundidade posteriormente e forneceremos algumas respostas para perguntas não abordadas aqui.
Em relação aos relés, recomendamos a leitura de um artigo de Ankit Chiplunkar, da Frontier Research, e Mike Neuder, da Ethereum Foundation, chamado Relés otimistas e onde encontrá-los. Este post detalha como os relés no MEV-boost funcionam, suas compensações atuais e custos operacionais e algumas mudanças que podem aumentar a eficiência. Curiosamente, executar um revezamento no MEV-Boost custa atualmente cerca de US$ 100.000/ano, de acordo com as estimativas do Flashbot.
Determinístico
Antes de falarmos sobre o determinismo das blockchains modulares (como elas são atualmente), vamos dar uma olhada em nosso artigo anterior “Modular MEV”. Observe que esta não é uma visão "oficial" nem abrangente da finalidade, mas acreditamos que representa com mais precisão as nuances da finalidade do Rollup para facilitar o entendimento.
Pendente_On_L2: O Rollup orderer representa um compromisso flexível de que a transação de um usuário será finalmente confirmada e finalizada na camada base de sua segurança.
Finality_On_L2: O sequenciador foi comprometido com a função de transição de estado do Rollup e o bloco foi adicionado à cadeia canônica do Rollup.
Pendente_On_L1: A função de entrada ou saída/transição de estado da transação foi publicada em L1, mas a prova de validade ainda não foi emitida ou o período de arbitragem ainda não terminou - isso requer Ethereum por duas épocas consecutivas. Este é o ponto em que a maioria dos Rollups otimistas dizem que atingiram a finalidade, mas ainda há um período de desafio arbitrário de 7 dias neste ponto, de acordo com a especificação da ponte de cadeia cruzada.
Finality_On_L1: Para um Rollup Otimista, o período de arbitragem terminou, ou uma prova de validade publicada e verificada foi confirmada por uma maioria absoluta em duas épocas consecutivas.
Agora, em um Sovereign Shared Sort Rollup, isso parece um pouco diferente, vamos tentar explicar com um diagrama:
Neste caso, teoricamente podemos obter determinismo em L1 antes de L2, etc.? Sim, neste caso L2 é soberano afinal. Isso pressupõe que não haja provas de fraude e períodos de contestação ou que você esteja usando uma prova de validade.
Então, como atingimos esses níveis de finalidade? A finalidade do bloco é alcançada quando um bloco é adicionado à cadeia canônica, que não pode ser retirada. No entanto, existem algumas nuances aqui, dependendo de nós completos ou leves. No caso de um bloco ordenado, é determinístico uma vez que está incluído em um bloco da camada DA. Os blocos (com raízes de estado) são reforçados pelos nós/validadores completos do Rollup, o que lhes dá a garantia de uma raiz de estado válida derivada dos blocos ordenados da camada base. Para determinismo além dos nós completos (como para clientes leves ou pontes de cadeia cruzada), você deve ter certeza da validade dessa raiz de estado. Aqui, você pode usar um dos métodos descritos abaixo. Além disso, outra abordagem é responsabilizar os validadores pela prova correta da raiz do estado (a rota otimista), por meio de um vínculo e posterior prova de fraude. Além disso, você pode fornecer uma prova de validade (ZK).
Diferentes maneiras de alcançar a finalidade do bloco:
Através de Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) e outros métodos probabilísticos.
Um método comprovado por meio de membros suficientes do comitê assinando blocos. (por exemplo, Tendermint 2/3, Hotshot2 ou outros tipos de PBFT)
Depende da ordenação das transações/blocos na camada DA, e das suas regras, nomeadamente regras canónicas de cadeia e seleção de bifurcações.
Podemos alcançar diferentes tipos de finalidade através de diferentes mecanismos.
Um tipo de finalidade é a "finalidade suave" (como pendente), que pode ser alcançada por uma única eleição de líder. Neste caso, cada slot terá apenas um ou zero blocos (confirmados ou não), e a camada de sincronização pode assumir com segurança a sequência de transações nestes blocos.
Outro tipo de finalidade é a "finalidade demonstrável", que fornece garantias mais fortes (essencialmente finais) do que a finalidade suave. Para alcançar a finalidade comprovável, a maioria dos ordenantes deve assinar um bloco, expressando assim sua concordância de que o bloco é canônico. Embora essa abordagem seja boa, ela pode não ser necessária se uma única eleição de líder tiver sido implementada, uma vez que ela essencialmente garante a ordem dos blocos. Obviamente, isso depende do algoritmo específico de eleição de líder que está sendo implementado. Por exemplo, é uma implementação de 51%, uma implementação de 66% ou um único líder (de preferência aleatório (VRF) e eleição secreta). Se você quiser aprender mais sobre o determinismo no Ethereum, leia este artigo que recomendamos e o artigo que recomendamos mais tarde para conjuntos de classificadores ilimitados.
licenciado, semi-licenciado ou não permitido
Para evitar possíveis ataques DoS, barreiras econômicas devem ser definidas para ingressar no grupo de pedidos e enviar transações para a camada de pedidos. Em grupos limitados (número finito de classificadores) e ilimitados (número ilimitado de classificadores), barreiras econômicas devem ser implementadas para enviar lotes à camada DA para evitar que a camada de sincronização (propagação de blocos entre classificadores) fique lenta ou sob ataque DDoS . No entanto, a própria camada DA também fornece alguma proteção, porque o envio de dados a ela requer um custo (da_fee). O depósito de segurança necessário para ingressar no grupo ilimitado deve cobrir quaisquer custos adicionais necessários para evitar que a camada de sincronização seja spam. Por outro lado, a margem necessária para ingressar em um grupo limitado dependerá da demanda (equilibrada do ponto de vista custo/receita).
Para um conjunto ilimitado de classificadores, não podemos obter finalidade demonstrável na camada do classificador (já que nunca sabemos exatamente quantos votantes/assinantes ativos existem). Por outro lado, em um grupo limitado de coorters, a finalidade provável pode ser alcançada pela maioria dos coorters assinando blocos. Isso requer que a camada de sincronização esteja ciente da camada do sequenciador e de quantos sequenciadores estão ativos em um determinado momento, o que representa uma sobrecarga adicional. Em um conjunto limitado de classificadores (por exemplo, até 100), você também pode otimizar o número de classificadores para melhorar o "desempenho", embora às custas da descentralização e da resistência à censura. A importância de grupos limitados e garantias econômicas para fornecer certeza comprovável "rápida" também é determinística.
Os tipos de classificador ilimitado e classificador limitado também são refletidos em blockchains tradicionais. Por exemplo, o PoS (Casper+LMD-GHOST) no Ethereum adota o tipo ilimitado, enquanto a cadeia baseada no Cosmos SDK/Tendermint adota o tipo limitado. Um pensamento interessante é: esperamos ver economia e opções semelhantes à prova de participação da comunidade em torno de pedidos compartilhados? A esse respeito, vimos um movimento em direção à centralização de algumas entidades (portanto, ilimitado realmente não importa se você já possui alguns grandes provedores/pools de proof-of-stake). Apesar de "esconder" a centralização, afinal, você ainda pode minerar se quiser. Do ponto de vista ideológico, as escolhas quase sempre devem ser ilimitadas - mas lembre-se de que os princípios econômicos as tornam muito semelhantes de qualquer maneira. Independentemente de quem são os participantes, a economia do que você paga ainda deve ser a mesma, como o custo do DA e o custo do hardware (embora isso possa ser reduzido pelo número de provas de participação que você aloca e experimenta, e exploração da infra-estrutura). Mesmo no mundo PoS limitado, vimos um grupo de provedores de infraestrutura se tornarem os maiores e mais comuns validadores em quase todas as cadeias. Na maioria das cadeias Cosmos, as dependências entre validadores já são muito grandes, e isso certamente representa um perigo para a descentralização e resistência à censura das referidas cadeias. Ainda assim, um fato muito diferente é que qualquer investidor de varejo pode apostar qualquer quantia com qualquer validador que escolher. Infelizmente, isso geralmente é atribuído ao topo da lista e a vida continua. Perguntamos novamente: esperamos um modelo econômico semelhante em um mundo modular? Alguém gostaria que não fosse o caso, mas com especialização você geralmente precisa do melhor ajuste - e eles tendem a ser provedores profissionais de proof-of-stake. Também abordaremos essas questões econômicas em um capítulo separado posteriormente.
No entanto, uma coisa importante a lembrar em todas essas questões é que o mais importante é a autenticação do usuário final, que está disponível para qualquer pessoa, não importa onde esteja (mesmo em Gizé) por meio de clientes leves e pirâmide DAS).
Fonte: @JosephALChami
Aqui estão as vantagens e desvantagens dos classificadores limitados e ilimitados:
Conjunto classificador ilimitado:
*Qualquer pessoa com títulos/apostas suficientes pode se tornar um classificador = alto grau de descentralização
Conjunto limitado de classificadores:
Esta é uma das soluções da Ethereum para o determinismo de slot único e possui um comitê de super "maioria".
Há um espaço de design considerável para como esses conjuntos de classificadores são monitorados e novos membros são adicionados ou removidos. Por exemplo, isso será alcançado por meio da Governança de Tokenholder (que tal muitos Tokens e Rollups diferentes usando coleções então?). Isso significa que a sinalização de mudanças fora da cadeia pode ser possível por meio de consenso social (por exemplo, tome o Ethereum como exemplo). No entanto, lembre-se de que o consenso real na cadeia está claramente estabelecido e já existem penalidades para a violação das regras de consenso.
Mecanismo econômico para classificadores compartilhados
A economia de compartilhar uma rede de sequenciadores permite algumas opções interessantes. Como discutimos anteriormente, os validadores em uma rede de pedidos compartilhados não são muito diferentes dos validadores L1 típicos. A rede da qual ele participa é simplesmente mais otimizada para executar uma tarefa, que é receber intenções (anteriormente PBS) e, portanto, propor e solicitar transações. Assim como os validadores "regulares", existem componentes de receita e custo. Em ambos os lados da equação, há muita flexibilidade nas redes das quais os validadores participam, semelhante ao L1 regular.
A receita vem de usuários ou Rollups com os quais eles desejam interagir pagando uma determinada taxa pelo uso do sequenciador compartilhado. Essa taxa pode ser uma porcentagem do MEV retirado (inserir números pode ser difícil de aproximar), transferências de valor entre cadeias, Gás ou uma taxa fixa por interação. A solução de receita mais apropriada pode ser pagar ao ordenador compartilhado menos valor do que o valor adicional obtido por meio do ordenador compartilhado Rollup, junto com os benefícios de segurança e liquidez compartilhadas. Mas a desvantagem disso é que é difícil quantificar os benefícios da descentralização de outra parte da pilha. No entanto, à medida que a rede de pedidos compartilhados cresce em seu próprio ecossistema, sua capacidade de extrair taxas pode aumentar. Isso se deve em grande parte à sua capacidade inerente de agregar facilmente, com certas economias de escala. À medida que mais Rollups e aplicativos se juntam à rede, mais e mais MEVs entre domínios poderão extrair.
Em termos de custo, as redes de pedidos compartilhados também têm opções concorrentes. Eles podem facilmente financiar seu uso de rede financiando o custo de publicação na camada DA ou até mesmo o custo de interagir com aplicativos no Rollup. Isso é semelhante à estratégia usada pelas empresas da Web 2.0, em que você assume a perda inicial na aquisição (ou rollup) do usuário, esperando que a receita de longo prazo supere as taxas. Outro método mais inovador ou nativo de criptografia é permitir que o Rollup pague taxas DA com seu token nativo. Aqui, a camada de classificador compartilhada carrega o risco de preço entre o Token necessário para publicar dados na camada DA e o Token nativo do Rollup. Em essência, ainda é um custo inicial de classificador compartilhado, mas cria consistência no ecossistema ao obter o Token do "fornecedor" (ou seja, Rollup). Isso é um pouco semelhante à construção do armazém que explicamos no documento AppChain, e diferentes formas de DA podem ser usadas para reduzir custos. Diferentes níveis de DA oferecerão preços diferentes devido à utilização, à capacidade dos usuários de verificar facilmente por meio de um cliente leve ou simplesmente fazer diferentes escolhas de tamanho de bloco. Por fim, o ordenador compartilhado também pode agrupar transações antes de publicar na camada DA. No caso do ZKR, isso pode reduzir os custos de transação através de um determinado número de saldos de transação e, em termos de ORU, você pode realizar várias otimizações de Gás de processamento em lote, que podemos ver atualmente em vários Rollups. Isso reduzirá a quantidade de dados que precisam ser publicados na camada DA, reduzindo assim o custo da rede do sequenciador compartilhado e aumentando a lucratividade de toda a rede. Isso terá o custo de limitar a interoperabilidade e alterar os tempos de finalização do bloco (determinismo em L1, conforme mencionado anteriormente).
No geral, a economia de compartilhar uma rede de sequenciadores permite algumas experiências interessantes e estratégias de inicialização. Estimamos que a principal diferença será o tamanho do ecossistema, portanto, o número de MEVs entre domínios é maior do que o custo. Também recomendamos verificar a postagem no blog da equipe do Espresso sobre pedidos compartilhados, pois eles também cobrem as compensações econômicas (e os pontos positivos) desses tipos de redes. Para mostrar por que o Rollup é motivado a tirar vantagem dos classificadores compartilhados (além da economia), podemos considerá-lo de uma perspectiva da teoria da agregação.
Teoria da Agregação e Classificadores Compartilhados
Outra maneira de descrever as propriedades trazidas pelos classificadores compartilhados é através das lentes da teoria de agregação. A teoria da agregação refere-se ao conceito de como uma plataforma ou agregador integra outras plataformas e seus usuários de maneira sistemática para obter atenção significativa do usuário. Você está essencialmente movendo o jogo da alocação de um recurso escasso (por exemplo, espaço em bloco) para a necessidade de controlar um recurso abundante (novamente, o espaço em bloco faz sentido neste exemplo). A Teoria da Agregação na verdade agrega fornecedores e produtos (ou seja, Rollup e Blockspace) em uma experiência de superusuário para atender à base agregada de usuários. À medida que o efeito de rede desses agregadores cresce, esse relacionamento se torna cada vez mais exclusivo. Quando isso acontece, a experiência do usuário se torna um diferencial importante entre configurações semelhantes. Se houver incentivos para atrair novos usuários (como uma boa experiência do usuário e melhor interoperabilidade), é improvável que o Rollup mude para sua própria rede ou para uma configuração diferente - já que os efeitos da rede impulsionam novos fornecedores e novos usuários se juntam. Isso cria um efeito volante, não apenas da perspectiva do provedor e do usuário, mas também de uma perspectiva agregada de resistência à censura.
Fonte: Teoria da Agregação 2015, Ben Thompson
No reino dos classificadores compartilhados, a Teoria da Agregação pode ser vista como "combinações" e federações de vários Rollups, todos utilizando verticais semelhantes da pilha - capacitando a si mesmos e aos outros enquanto permite que os usuários obtenham a mesma experiência.
Provedores (como Rollups) não são teoricamente exclusivos do conjunto de co-coorter compartilhado, mas na prática o conjunto de co-coorter compartilhado, seus roll-ups e usuários se beneficiam de uma série de loops de efeitos de rede que levam ao aumento do uso desses roll-ups. Esses benefícios facilitam a integração de Rollups e usuários em uma pilha compartilhada porque eles têm mais a perder se não participarem. Embora esses benefícios possam ser difíceis de ver quando você tem apenas dois Rollups compartilhando um único conjunto de sequenciador, eles se tornam mais claros à medida que você adiciona mais e mais Rollups e usuários à equação. Os conjuntos de classificadores compartilhados têm uma relação direta com os usuários, pois eles ordenam suas transações, mesmo que os próprios usuários não saibam que estão interagindo com eles, pois, na perspectiva deles, estão apenas usando Rollups com os quais têm um motivo para interagir ( Isso significa que os pedidos/classificadores se tornam exclusivos). O único custo desses classificadores é realmente o custo de hardware para executá-los, desde que o espaço do bloco e os tokens que o protegem sejam valiosos para o usuário final. As taxas de transação são digitalizadas, pagas com as carteiras dos usuários e, talvez no futuro, podem até ser extraídas por meio de avanços, como hosts de pagamento na abstração da conta (no entanto, alguém terá que arcar com o custo de DA, pedido e execução).
Isso faz mais sentido quando se considera a empresa anterior de Josh e Jordan em Astria - Google. Desde a sua criação, os produtos do Google foram inspirados pela ideia de AT, principalmente na Pesquisa do Google, que é criada pela modularização de páginas e artigos individuais, tornando-os diretamente acessíveis por meio da janela de pesquisa global.
No caso de um conjunto compartilhado de classificadores, os usuários que utilizam Rollups (aqueles que compartilham um conjunto de classificadores) têm custos de aquisição cada vez menores, pois conforme o número de fornecedores (Rollup) aumenta, é provável que sejam atraídos para o conjunto . Isso significa que, na maioria dos casos, um agregador (ou multi-agregador) tem um possível efeito ganha-ganha, pois o valor de um agregador aumenta com o número de fornecedores (desde que a experiência do usuário seja boa, é claro). Em contraste, em uma única rede serial, a aquisição de clientes é limitada a uma única rede e suas aplicações. Se os usuários quiserem usar o aplicativo Rollup em um Rollup diferente, eles terão que (dentro das limitações atuais) fazer logoff da rede completamente. Isso significa que a aderência e o valor do usuário não são muito altos e também significa que, a qualquer momento, se outro ecossistema Rollup for altamente valorizado (ou tiver mais incentivos), o capital poderá ser perdido.
Resumo de atributos e compensações
Atributos
Um conjunto de classificador compartilhado é uma rede de rollup que agrega e classifica transações para vários rollups. Esses Rollups compartilham o mesmo classificador. Esse agrupamento de recursos significa que os Rollups obtêm segurança econômica mais forte e recursos anticensura, que podem fornecer garantias determinísticas suaves rápidas e transações condicionais cross-Rollup.
No momento, há muito barulho sobre atomicidade entre Rollups que compartilham o mesmo conjunto de classificadores, principalmente sobre se é atômico por padrão - o que não é. No entanto, se os Rollups em questão implementam as funções de transição de estado (STFs) uns dos outros como dependências entre eles, envolvendo transações condicionais, então eles podem de fato alcançar atomicidade entre eles - desde que seu alinhamento de slot/blocktime (como com conjuntos de classificadores compartilhados). Nesse caso, para obter a interoperabilidade atômica, você realmente só precisa executar um cliente leve da cadeia B na cadeia A e vice-versa (semelhante ao funcionamento do IBC). Para fortalecer ainda mais a interoperabilidade das medidas de segurança (além de confiar em um único nó completo como um nó leve), você pode implementar o ZKP (Prova de Estado) para resolver o "problema do oráculo" de garantir a exatidão do estado. Isso tornará mais claro para ver se uma transação condicional ou algo parecido atingiu uma ponte de cadeia cruzada canônica entre eles. Provas de fraude também são uma possibilidade, mas obviamente deixariam um período de contestação (o que significa que um terceiro viria para cobrir o custo desse risco). Além disso, no caso de light clients (em vez de full nodes), haverá pelo menos um quarteirão de atraso devido à espera do cabeçalho da assinatura + janela à prova de fraude (se houver).
Acreditamos que o problema da "ponte entre cadeias" tem maior probabilidade de ser resolvido com clientes leves e provas de conhecimento zero. O desafio de usar um cliente leve (em vez de um contrato inteligente) nesse caso é que os hard forks (atualizações etc.) o mesmo módulo de estado). Se você quiser mergulhar mais fundo neste tópico específico (e como abordá-lo), recomendamos que você confira esta apresentação.
A razão pela qual os pedidos compartilhados escalam tão bem é que eles não executam e armazenam nenhum estado (como os pedidos centralizados fazem hoje). O mesmo vale para os próprios nós Rollup (a menos que eles desejem atomicidade entre eles - por exemplo, cliente leve/prova de estado). Esses nós executam apenas transações que são válidas para seu Rollup e quaisquer transações entre domínios condicionais que sejam válidas para eles. Se um nó Rollup tiver que executar e armazenar o estado para vários Rollups, isso prejudicará a escalabilidade e reduzirá a descentralização (e, portanto, a resistência à censura). Isso também reforça o conceito de separação produtor-construtor (PBS) de blocos. Embora ainda precisemos separar completamente os construtores e os produtores de blocos. Na configuração atual, os ordenadores são essencialmente construtores e produtores de blocos (embora não executem transações). Uma configuração ideal pode ser aquela em que o solicitante existe apenas para assinar blocos cegamente de uma configuração de construtor altamente otimizada e garantir que os blocos sejam implementados corretamente (enquanto fornece um alto grau de certeza econômica e resistência à censura para essa certificação). Dessa forma, eles podem fornecer um alto grau de segurança e comprometimento para garantir soft finality aos nós Rollup.
Para transações condicionais de rollup cruzado, eles também existem para ajudar a habilitar os nós de rollup (executores) para fornecer raízes de estado intermediárias, permitindo atomicidade entre rollups.
troca
O parâmetro de tempo limite mencionado acima tem alguns efeitos interessantes no MEV e na inclusão da transação, dependendo do mecanismo de masternode/consenso do conjunto do ordenador. Por exemplo, se o parâmetro de tempo limite for descrito como relativamente curto em nosso documento de cadeia específico do aplicativo, é fundamental que os produtores de blocos de um conjunto descentralizado de solicitantes publiquem dados o mais rápido possível. Em tal mundo, você pode ver a competição entre "validadores" que competem para ser os nós mestres e fazem lances na camada DA por espaço em bloco até que não seja mais lucrativo.
Como Evan abordou em seu post original de pedido preguiçoso nos fóruns do Celestia, esperar que as transações sejam publicadas na camada base (Celestia, neste caso) antes de executá-las é muito ineficiente. Desde agora você está limitado pelo tempo de bloqueio da camada base - que é muito longo para esperar pela experiência do usuário. Para uma melhor experiência do usuário, o ordenador compartilhado fornece Rollups com compromissos determinísticos suaves (conforme descrito anteriormente), que fornecem aos usuários a experiência do usuário a que estão acostumados em Rollups centralizados existentes (mantendo a descentralização e alta resistência à censura). Os compromissos suaves são essencialmente apenas compromissos para a ordem final das transações, mas apoiados por pesadas garantias econômicas e finalização rápida, uma vez emitidos. Isso também é coberto por provas de fraude (como mencionado na introdução). A finalidade definitiva real é alcançada depois que todos os dados da transação foram publicados na camada base (o que significa que L1 realmente atinge a finalidade mais rápida). Depende se o Rollup usa provas de fraude ou provas de conhecimento zero para sua verificação de prova de soberania - o que acontece no Rollup. A razão para querer essa separação é remover o enorme gargalo das transições de estado do classificador. Em vez disso, os nós Rollup lidam apenas com nós que são válidos para eles (o que significa que temos que adicionar transações condicionais, prova de estado ou validação de nó leve para interoperabilidade adequada). O determinismo rígido ainda depende da camada base (mas isso pode chegar a 15 segundos no Celestia e também é determinístico no Tendermint), o que nos dá garantias de determinismo rígido relativamente rápido no Rollup.
Use provas de conhecimento zero dentro da rede para otimizar a validação, o tamanho da transação (por exemplo, apenas publicar diferenças de estado - mas isso adiciona um nível mais alto de confiança até que o ZKP seja publicado). Conforme mencionado anteriormente, essas provas de estado podem ser usadas para permitir que as cadeias/rollups conectados tenham interoperabilidade mais fácil e rápida (sem esperar por janelas de desafio).
Uma desvantagem dessas transações condicionais é que elas provavelmente serão mais caras, exigindo custos mais altos de verificação e emissão (como o custo da verificação do cabeçalho do bloco Tendermint, que é subsidiado na rede Cosmos) e adicionando alguma latência ao sistema ( mas ainda mais rápido que Rollups isolados são muito mais rápidos). A atomicidade alcançada pela integração compartilhada verticalmente pode compensar esses problemas.
Durante a fase inicial de um novo rollup, usar um conjunto compartilhado de collators faz muito sentido, e as vantagens que você ganha como provedor provavelmente superarão algumas das compensações que você pode ser "forçado" a fazer no nível do fosso. Porém, para um Rollup já maduro, onde há muitas transações e atividade econômica, provavelmente não faz sentido abrir mão de parte do fosso.
Isso levanta a questão de saber se precisamos de uma redistribuição ponderada econômica/transacional (por Rollup) similar de MEV extraído para induzir Rollups já maduros a se juntarem ao conjunto compartilhado - ou mesmo evitar que Rollups extremamente maduros gerem sua própria rede. Tudo isso é bastante teórico, mas é sem dúvida um processo de pensamento interessante em relação a como os MEVs em mundos verticais compartilhados serão representados entre muitos Rollups com níveis variados de atividade. Por exemplo, se um Rollup exclusivo que gera valor compartilha alguns desses lucros com outros (provavelmente não trazendo muito "valor") por meio do Conjunto do Sequenciador, deve haver mais motivos para eles mudarem para seu próprio sistema de silos. Sreeram de EigenLayr também tem algumas reflexões sobre isso, que recomendamos a leitura também.
Isso se torna cada vez mais importante quando se considera que há um custo técnico considerável para os pesquisadores desenvolverem novas cadeias, portanto, padronizar e fornecer alguma soberania sobre "seus" MEVs pode ser um bom ponto de partida. Na prática, no MEV, a interface dominante (ou software) pode vencer, mas, na verdade, monetizar esse software executando partes críticas da infraestrutura é muito difícil (levando à centralização). No nível do mercado, o que um ordenador compartilhado fornece é basicamente um mempool comum para múltiplos provedores, com um leilão centralizado, o que pode levar a uma competição mais saudável.
Uma preocupação aqui é que, se dois Rollups estiverem executando classificadores no conjunto compartilhado, um Rollup com valor "menos econômico" (A) pode ser selecionado para propor um rollup com uma alta quantidade de MEV + taxas dos blocos Rollup (B). . Do ponto de vista do Rollup B, eles essencialmente perdem algum valor que, na abordagem isolada, eles manteriam para si mesmos.
Lidando com compensações de interoperabilidade
Segue outra observação sobre as compensações apresentadas pela interoperabilidade e outra maneira de resolver alguns dos problemas:
O objetivo da rede de pedidos compartilhados é fornecer uma garantia canônica para várias cadeias, o que obviamente é uma grande vantagem nesse caso. Isso pode ser combinado com um mecanismo para garantir transições de estado eficientes entre Rollups. Pode ser uma abordagem baseada em comitê (por exemplo, PoS), provas seguras (a abordagem otimista) ou nossa preferida - um ZKP apoiado por assinaturas de comitê. Como os classificadores compartilhados são "preguiçosos", eles apenas criam super blocos para classificar as transações de vários Rollups, e a execução da transação específica é deixada para um Rollup específico. Provas de estado (ou seja, Lagrange, Axiom ou Herodotus, etc.) são todas as soluções possíveis para potencialmente obter provas de finalidade em rollups soberanos. Você pode até adicionar provas de finalidade economicamente garantida por meio de coisas como staking pools, EigenLayr, etc. A ideia básica é que um classificador compartilhado fornece uma garantia econômica de ordenação, e as provas de validade geradas a partir dessa classificação são determinísticas. A ideia básica é que Rollups podem executar transações de forma síncrona entre si. Por exemplo, uma rede de dois nós Rollup pode saber condicionalmente que ambos os históricos Rollup são válidos, via ZKP e dados disponíveis (dados publicados em uma camada DA eficiente). Ao publicar um único prefixo de bloco Rollup de ambas as redes A e B, um nó Rollup pode liquidar dois Rollups simultaneamente. Uma coisa a apontar é que as transações cross-rollup condicionais consomem recursos de dois sistemas separados por meio de execução compartilhada, portanto, as transações atômicas (ou síncronas) de rollup cruzado provavelmente serão mais caras do que as intratransações de rollup único.
Sucinct também cobriu transações "atômicas" de cadeia cruzada entre Rollups com pedidos compartilhados (e provadores de fraude compartilhados) dentro do ecossistema de hipercadeia Optimism, que pode ser visto aqui. Além disso, como Bo Du da Polymer coloca: "Transações atômicas de cadeia cruzada são como adquirir bloqueios entre fragmentos de banco de dados na gravação".
O futuro da integração vertical
O possível funcionamento interno das cadeias SUAVE já foi explorado em profundidade por Jon Charbonneau et al, portanto não entraremos em muitos detalhes. Se você quiser uma descrição mais detalhada, pode conferir o artigo dele. No entanto, achamos que a integração vertical merece uma introdução separada, tanto para destacar como podemos ser modulares (e por quê) quanto para apresentar algumas das questões e preocupações associadas à integração vertical.
Embora o atual esquema de pedidos compartilhados da Astria, Espresso e Radius seja muito modular, os pedidos ainda atuam como construtores e produtores de blocos (embora no caso de Astria, eles não executem transações). A Astria também vem incorporando ativamente o PBS em sua arquitetura desde o início.
Se o PBS não estiver embutido no protocolo, existem várias maneiras de implementar o PBS (embora com vários graus de descentralização). Produtos como SUAVE, usam modelos off-line como MEV-Boost ou implementam módulos construtores, como os módulos Cosmos SDK criados por Mekatek e Skip.
Vale a pena notar que nenhum desses métodos é mutuamente exclusivo. Você tem a flexibilidade de usar vários métodos diferentes e permite que qualquer pessoa expresse sua preferência. Dessa forma, você pode ter executores competindo para preencher essas vagas. Adicionar mais opções é sempre bom (e consistente com nossa crença na modularidade). Ainda assim, diferentes implementações terão diferentes compensações. Por exemplo, em um caso como o SUAVE, você pode adicionar proteção de privacidade por meio da tecnologia SGX ou Crypto e adicionar segurança econômica Crypto à verdade, em vez de depender de um construtor de PBS centralizado totalmente confiável. (Obrigado a Jon Charbonneau por seu feedback aqui).
A integração vertical na cadeia do construtor garante justiça sem usar atalhos, adicionando latência e degradando o desempenho. Portanto, a cadeia do construtor precisa ser altamente otimizada e pode exigir hardware caro e poderoso (levando à centralização). Isso significa que, para obter a validação do usuário final, provavelmente precisaríamos de algum tipo de nós leves (embora eles tivessem que confiar nos nós completos) ou utilizar uma configuração de tipo de prova de estado para garantir que a cadeia e os usuários tenham provas de que as preferências de lance estão preenchidos e os blocos estão corretos Construir.
Uma cadeia como essa pode ser muito pesada em estado (queremos evitar isso), embora essas transações pesadas em estado sejam priorizadas por meio de contratos inteligentes. No caso de lance prioritário, ou ele é preenchido ou não é preenchido (por um curto período de tempo), pois os lances geralmente são válidos por um curto período de tempo, dependendo da preferência. Isso significa que podemos implementar uma expiração de estado muito eficiente (e antecipada) para licitações - o que nos permitirá podar os dados e manter a cadeia "limpa". Essa data de expiração precisa ser longa o suficiente para permitir que os lances sejam preenchidos primeiro, mas baixá-la demais tornaria quase impossível alcançar futuros de espaço de bloco. Não precisamos atualizar e recuperar contratos de licitação expirados, pois eles não precisam existir para sempre (ao contrário dos aplicativos) - isso pode ser feito fornecendo provas de estado/armazenamento quando as licitações são preenchidas ou por soluções de armazenamento DAS (como propostas by Joachim Neu) para torná-lo mais "seguro" e confiável.
Conforme mencionado anteriormente, a necessidade de verificar a "autenticidade" do SUAVE pode estar limitada aos "jusha" (usuários avançados) da plataforma, pois a maioria dos usuários e clientes do SUAVE podem obter altos benefícios econômicos com isso. Isso pode nos levar a permitir que as pessoas executem nós completos apenas se quiserem validar - embora isso exclua a grande maioria das pessoas (você poderia dizer que elas não precisam validar). Isso é (em nossa opinião) o oposto de Crypto, onde preferimos implementar a verificação SUAVE "sem confiança" por meio de provas de estado ou implementações leves amigáveis ao cliente.
A razão pela qual isso é necessário é que você deseja verificar se sua prioridade de lance foi preenchida corretamente e se o bloco foi preenchido com as informações corretas no momento do pagamento (para evitar reagrupamento e outros bugs). Este é essencialmente um problema de oráculo - na verdade, pode ser resolvido com uma prova de estado (como é o caso de todos os SUAVEs). No entanto, essas provas de estado trazem outro problema ao cruzar as cadeias, como retransmitir essas informações pelas cadeias de uma forma que não tenha sido adulterada ou ocultada? Isso pode exigir passar por uma forte finalidade econômica (como a proposta por Lagrangian), caso em que você pode usar os validadores de restaking do EigenLayr para provar a finalidade e a autenticidade da cadeia e ter restrições econômicas muito fortes. Isso então traz outro problema (por exemplo, o contrato de licitação estipula que a "máquina oracular" - neste caso o re-pledger - designou o Token prometido e forneceu ligação econômica - mas como fazemos um consenso entre cortar externamente isso? Enquanto você pode escrever critérios de corte, isso não é consenso, o que significa que o corte social será explorado por meio de contratos inteligentes (o que quase nunca é "justo" e pode causar problemas). .
Então, onde isso nos deixa? Possivelmente, até obtermos uma redução "inconfiável" na cadeia além do consenso, cadeias como SUAVE podem precisar de seus próprios algoritmos de consenso e segurança criptoeconômica para provar as preferências de lance e construir a certeza do bloco - No entanto, isso significa adicionar mais vetores de ataque criptoeconômico, especialmente se o Rollup valor de seus blocos de construção é muito maior do que sua própria segurança criptoeconômica.
Além disso, ainda há muito espaço de design em cadeias do tipo SUAVE e MEVs de domínio cruzado. Aqui estão algumas possíveis direções de pesquisa:
Em relação à expressão de preferência, para interagir com um contrato inteligente no EVM, é necessário enviar uma chamada de contrato (mensagem) para uma função específica no endereço do código implantado contendo a instrução de execução. Embora os usuários forneçam entrada, eles podem não ter controle sobre a saída devido à possível propriedade de estado.
Em contraste, os sistemas de design de expressão de preferência (como SUAVE e Anoma) exigem apenas que os usuários assinem suas preferências com um título, que é pago aos construtores e produtores de blocos se as preferências do pesquisador forem atendidas. Para lógica combinatória complexa, como sequências de transações para buscadores e construtores MEV, diferentes linguagens e máquinas virtuais podem precisar ser implementadas. Este é um novo espaço de design que tem recebido muita atenção ultimamente, especialmente a arquitetura Anoma. Além disso, recomendamos este pequeno artigo.