encaminhe o título original 'estamos todos construindo a mesma coisa'

introdução

esta postagem analisa o seguinte

• execução assíncrona - por que blockchains integrados de alto desempenho (por exemplo, SolanaeMonad) irá separar a execução do consenso sobre a ordenação (sequenciamento).
• sequenciamento preguiçoso - como eles vão espelhar o design de um sequenciador preguiçoso (por exemplo, @astriaorg/hj6ccpp9t">astria).
• pré-confirmações - pré-confs em ethereum l1 e rollups baseados.
• base vs. não baseado - comparando rollups baseados + preconfs vs. rollups não baseados + fallback da camada base.
• componibilidade síncrona universal - via inclusão atômica (de sequenciadores compartilhados) + segurança criptográfica (por exemplo, AggLayere/ou prova em tempo real).
• rollups baseados em rápido - os rollups baseados devem ter apenas uma camada base rápida.
• jogos de temporização -O tempo é dinheiro, e como isso subjaz os finais divergentes entre solana vs. ethereum.
• descentralização para resistência à censura - comoseparação entre atestador e proponentevialeilões de execuçãopode preservar validadores descentralizados que podem aplicar resistência à censura comlistas de inclusão.

por último, e mais importante, veremos porquêestamos todos a construir a mesma coisa malditaentão talvez devêssemos apenas…

otimizando a replicação da máquina de estados (smr)

vamos construir a partir dos conceitos básicos para ver o objetivo final das blockchains de alto desempenho (por exemplo, Solana, Monad, @patrickogradyabordagens do hypersdk) que se aproximam de uma estratégia de mitigação para permitir construtores maximizadores de lucro a minimizar tps inválidos.sequenciador preguiçoso (por exemplo, @astriaorg/hj6ccpp9t">astria). vamos voltar mais tarde para compará-los com rollups baseados em ethereum + preconfs.

sequenciamento vs. execução

blockchains são máquinas de estado replicadas. nós descentralizados mantêm e atualizam cada um a sua própria cópia do estado do sistema. para avançar a cadeia, os nós executam a função de transição de estado (stf) sobre o estado atual + novas entradas (por exemplo, novas transações). isto produz o novo estado.

usaremos os seguintes termos ao longo desta seção:

• sintaticamente válido - a transação está bem formada com uma estrutura de transação e assinatura adequadas.
• semanticamente válido - a transação realiza uma transição de estado válida (por exemplo, paga as taxas necessárias).
• sequência - determinar a ordem e a inclusão de dados.
• executar - interpretar e agir sobre os dados de acordo com o stf.
• construir - criar um bloco (ou pedaço/pedaço parcial de bloco) a partir de transações armazenadas localmente.
• verificar - realizar a verificação sintática e/ou semântica necessária de um bloco (ou fragmento de bloco parcial).
• replicar - disseminar um bloco (ou fragmento de bloco parcial/pedaço) para outros validadores.

vamos ampliar a sequência e execução, porque estas são as sub-tarefas principais necessárias para calcular o estado da cadeia:

Além disso, os nós verificam e replicam os dados em toda a rede. Os nós chegam a um consenso para manter uma visão consistente da cadeia.

no entanto, as arquiteturas de cadeia diferentes divergem significativamente em quem é responsável por essas tarefas e quando o fazem (por exemplo, a construção e verificação de blocos podem ou não incluir a execução). o tempo de ponta a ponta do completo replicação de máquina de estado (smr)loop determina os limites inferiores da latência do sistema. diferentes construções podem resultar em tempos altamente variáveis, portanto, um processo smr que seja eficienteoleodutos) essas tarefas são necessárias para um desempenho de baixa latência e alta capacidade de processamento.

Nas seguintes secções, veremos que uma ideia central de encaminhamento eficiente é focar na obtenção de consenso sobre as entradas de execução em vez dos resultados de execução. Isto requer relaxar algumas restrições sobre que transações podem ser incluídas. Então, precisaremos reintroduzir algumas restrições mais fracas para garantir que o sistema permaneça útil e resistente a ataques (por exemplo, evitando vetores de DOS de transações que não pagam taxas).

SMR tradicional

O smr tradicional (por exemplo, Ethereum) acopla estreitamente a sequenciação e a execução. Os nós completos sequenciam e executam continuamente todas as transações da camada base - ambas são pré-requisitos para que os nós alcancem o consenso. Além de verificar se todos os dados do bloco estão disponíveis (e sequenciados), os nós também devem executar o bloco para verificar se:

• todas as transações são sintaticamente e semanticamente válidas
• o novo estado calculado coincide com o fornecido pelo líder

os validadores só votarão em um bloco e o construirão depois de terem verificado independentemente seu estado. isso significa que a execução ocorre pelo menos duas vezes antes que o consenso possa ser alcançado (ou seja, o produtor de bloco executa durante a construção + validadores receptores executam novamente para verificar).

neste modelo tradicional, tanto a construção como a verificação incluem a execução.

origem:@patrickogrady/rys8mdl5p# Fazendo o caso para replicação de máquina de estado desacoplada (DSMR)">vryx: fortalecendo a replicação de máquina de estado desacoplada

streaming smr

streaming smr (por exemplo, solana) é uma forma eficiente de encadeamento em pipeline em queos produtores de blocos continuamente “transmitem” pedaços de blocos (chamado fragmentosou fragmentos) à medida que são construídos. Outros nós recebem e verificam (incluindo a execução) esses fragmentos continuamente, mesmo enquanto o restante do bloco ainda está sendo construído. Isso permite que o próximo líder comece a construir seu bloco mais cedo.

fonte: @patrickogrady/rys8mdl5p#fazendo-o-caso-para-a-replicacao-da-maquina-de-estados-desacoplada-dsmr">vryx: fortalecendo a replicação da máquina de estados desacoplada

Neste modelo de streaming, a construção e verificação ainda incluem a sequenciação e execução. Isso aumenta a eficiência do SMR em relação ao SMR tradicional sem relaxar nenhuma restrição de que todas as transações incluídas sejam semanticamente e sintaticamente válidas.

execução assíncrona

abordagem integrada

Agora, podemos obter um desempenho ainda melhor se relaxarmos essas restrições?

a execução assíncrona remove a execução do caminho quente do consenso - os nós apenas chegam a um consenso sobre a ordem dos dados sem executar primeiro esses dados. isso é mais eficiente, e é por isso que SolanaeMonadambos planejam implementar execução assíncrona.

o líder construiria e replicaria um bloco (ou fragmentos) sem precisar executá-lo. então, outros validadores votariam nele sem executá-lo também. os nós apenas chegam a um consenso sobre a ordem e disponibilidade das transações. isso é suficiente porque, dado um stf determinístico, todos eventualmente computarão o mesmo estado. a execução não precisa atrasar o consenso - ela pode ser executada de forma assíncrona. isso pode liberar o orçamento de execução para os nós (dando a eles mais tempo para gastar na execução) enquanto reduz os passos necessários (e, portanto, o tempo) para atingir o consenso.

a ordem determina a verdade. a execução simplesmente a revela. qualquer um pode executar os dados para revelar a verdade uma vez que a sua ordenação esteja finalizada.

é provavelmente por isso Keone acredita que, em última análise, todas as blockchains utilizarão execução assíncrona., e é uma peça fundamental de A visão final de Toly para Solana:

A execução síncrona requer que todos os nós que votam e criam blocos sejam sobreprovisionados para o tempo de execução do pior caso em qualquer bloco... os nós de consenso podem realizar menos trabalho antes de votar. O trabalho pode ser agregado e agrupado, tornando-o executado de forma eficiente sem nenhum erro de cache. Ele até pode ser executado em uma máquina totalmente diferente dos nós de consenso ou líderes. Os usuários que desejam uma execução síncrona podem alocar recursos de hardware suficientes para executar cada transição de estado em tempo real sem esperar pelo resto da rede.

atualmente, os validadores reproduzem todas as transações o mais rápido possível em cada bloco e só votam uma vez que a transição completa do estado é calculada para o bloco. O objetivo desta proposta é separar a decisão de votar em um fork do cálculo da transição completa do estado para o bloco.

vale ressaltar que também queremos garantir que a verdade seja revelada facilmente aos usuários, e isso significa suporte robusto para clientes leves. alguns desses projetos que atrasam a execução significativamente tornariam isso desafiador (por exemplo, Solana considerando apenas exigir isso uma vez por época) em comparação com outros que fornecem uma raiz de estado com um atraso menor (por exemplo, como no hypersdk).

abordagem modular

o desacoplamento da sequenciação e execução pode soar muito familiar porque este é também o approach “modular”! misturar e combinar diferentes camadas que se especializam em diferentes tarefas. o desacoplamento da sequenciação e execução é o princípio de design chave dos sequenciadores preguiçosos (por exemplo, astria):

• sequenciamento - nós sequenciadores apenas chegam a um consenso sobre a ordem e disponibilidade dos dados de rollup (ou seja, eles sequenciam, mas não executam).
• execução - os nós de rollup executam seus dados respectivos após o sequenciador ter se comprometido com ele.

A principal diferença aqui é que os nós de cadeia integrados são executados após o sequenciamento, enquanto os sequenciadores preguiçosos o empurram para um conjunto totalmente diferente e diversificado de atores. Os sequenciadores preguiçosos ignoram completamente as máquinas de estado dos Rollups. eles nunca executam essas transações. Os rollups lidam com a execução assíncrona.

a abordagem integrada fornece uma interoperabilidade mais fluida entre os usuários do ambiente de execução, mas reduz a flexibilidade para os desenvolvedores de aplicativos em termos de máquinas virtuais personalizadas, tempos de slot diferentes, regras de preços e ordenação de transações específicas do aplicativo, aplicadas pelo consenso, etc.). A abordagem modular proporciona mais flexibilidade e soberania aos desenvolvedores para possuírem domínios personalizados, mas é mais difícil unificar a experiência entre eles.

em qualquer caso, um tubo realmente grande e rápido para ordenar dados é a primitiva que precisamos:

no entanto, você deve notar que tecnicamente você pode usar praticamente qualquer cadeia como um sequenciador preguiçoso. Afinal, é apenas um tubo de big data no final do dia. Um rollup pode ingenuamente jogar seus dados arbitrários em sua camada base de escolha (seja Ethereum, Bitcoin, Mônada, etc.) para usá-los implicitamente como seu sequenciador. Os nós de rollup podem então executar os dados de forma assíncrona após o fato.

A diferença na prática é que as cadeias que realmente nos referimos como 'sequenciadores preguiçosos' são especializadas para essa tarefa, o que é muito mais fácil dizer do que fazer (por exemplo, suportar tipos de transações necessárias, expor interfaces fáceis, implementar infraestrutura de MEV, tempos de slot rápidos, inclusão confiável de transações, alta largura de banda, etc.). Como resultado, os nós das cadeias integradas acabam executando a maior parte dos dados que incluem, enquanto os sequenciadores preguiçosos deixam isso principalmente para os rollups.

é por isso que não é tão simples como "por que não usamos solana (ou qualquer outra cadeia quando esse nunca foi o objetivo de design) como um sequenciador de rollup?" :

• falta a infraestrutura mev necessária projetada especificamente para rollups (por exemplo, infraestrutura pbs requisitada, mecanismos de interoperabilidade entre cadeias, compositor para abstrair pagamentos de taxas para usuários de rollup no token de gás da camada base, etc.)
• falta de tipos de transação nativos projetados para postar dados em rollups.
• competindo contra o ambiente de execução nativo (por exemplo, é projetado explicitamente para consumir o máximo possível dos dados fornecidos, deixando menos espaço e inclusão confiável de transações, etc.).
• competindo pelo suporte geral do desenvolvedor e priorização de atualização. provavelmente você está mais inclinado a ir para o protocolo e equipe especializada em ajudá-lo a lançar rollups e projetar seu protocolo especificamente com você em mente vs. aquele onde a maioria da comunidade acha rollups meio burros.

fortalecendo o SMR desacoplado

Agora, podemos resolver esses problemas que surgem ao relaxar essas restrições? Em resumo, sim, as implementações ingênuas introduzem problemas, como permitir transações inválidas que não podem pagar taxas (o que seria um vetor de dos se implementado ingenuamente), mas eles são solucionáveis de forma que não sejam problemas graves.

não vamos entrar em muitos detalhes aqui, mas você pode consultarPatrick o’grady’strabalho incrível em@patrickogrady/rys8mdl5p#fazendo-o-caso-para-a-replicação-da-máquina-de-estado-desacoplada-dsmr">vryx para fortalecer o smr desacoplado, toly’sExecução assíncrona Endgame, e Implementação dos custos de transporte da Monadsobre como abordar essas questões. novamente, as soluções para esses problemas surpreendentemente parecem quase iguais tanto no lado modular quanto no lado integrado.

o resumo é que você pode reintroduzir algumas restrições muito mais fracas (em comparação com a execução síncrona com verificação completa) que retêm a maioria dos benefícios de desempenho sem deixar abertas várias ataques.

Atores dentro do protocolo vs. fora do protocolo

É importante ressaltar que precisamos perceber que os processos acima ingenuamente só contabilizaram atores no protocolo. Na realidade, os atores fora do protocolo desempenham um papel enorme nessas cadeias de suprimentos de transações. Isto é o que vimos anteriormente para validadores (em protocolo) em SMR tradicional:

origem: @patrickogrady/rys8mdl5p#fazendo-o-caso-para-a-replicação-da-máquina-de-estado-desacoplada-dsmr">vryx: fortalecendo a replicação da máquina de estado desacoplada

na prática, no entanto,quase todos os validadores de ethereum terceirizam a construção de blocos via mev-boostcom os três principais miners (beaver, titan e rsync) a construir quase todos estes blocos. note-se que beaver e rsync censuram transações ofac, enquanto titan não o faz.

origem: mevboost.pics

os relés lidam com a replicação desses blocos para o restante da rede. eles também são relativamente pesados, com os quatro principais operadores (ultra sound, bloxroute, agnostic e flashbots) transmitindo a grande maioria dos blocos. bloxroute e flashbots censuram transações ofac, enquanto agnostic e ultra sound não o fazem.

Fonte: mevboost.pics

não deve ser uma surpresa que vejamos tendências muito semelhantes em otimizações de latência aqui, como discutimos anteriormente. a tendência é pararelés otimistasque já não realizam a verificação de bloco antes da replicação porque é simplesmente mais rápido. Os sequenciadores preguiçosos podem ser vistos como redes de retransmissão incentivadas.

esses exemplos destacam como o MEV distorce os incentivos de lucro nesses sistemas. Validadores terceirizam a produção de blocos porque construtores sofisticados podem capturar mais valor do que blocos sequenciados de forma ingênua.

mesmo sob execução assíncrona, muitas vezes haverá produtores de blocos fora do protocolo executando transações durante a construção para maximizar o valor. por exemplo, é muito provável que sequenciadores preguiçosos tenham construtores de maximização de lucro em algum tipo de pbs. O fato de um produtor de blocos externo sempre ser incentivado a executar totalmente e otimizar o valor de um bloco pode realmente ser útil em configurações onde relaxamos as restrições na execução assíncrona. ainda assim, outros validadores não precisariam reexecutar antes de votar.

componibilidade síncrona universal

definições

Agora, podemos obter a soberania e flexibilidade que as cadeias modulares oferecem, mas reuní-las para parecerem uma cadeia integrada? Podemos ter o melhor dos dois mundos ou acabamos construindo o Solana com etapas extras?

Ao ouvir as pessoas falarem sobre a correção da fragmentação do rollup, provavelmente já ouviu as grandes palavras-chave em destaquecomponibilidade síncrona universal (usc). No entanto, esta provavelmente tem sido a sua reação:

todos esses termos são usados com diferentes significados, e alguns termos são frequentemente usados erroneamente de forma intercambiável. precisamos estabelecer algumas definições concretas. definimos os termos necessários abaixo no contexto da composabilidade cross-chain.

note que discutiremos os “rollups” ao longo do resto deste relatório, mas muitos desses conceitos se aplicam igualmente a outros tipos de “l2s”, como validiums.Eu só não quero brigar de novo sobre o que diabos é um l2.

nos exemplos a seguir:

• r_um= rollup a
• r_b = rollup b
• t_a1 = Operação 1 em R_um
• t_b1 = transação 1 em r_b
• b_a1 = bloco 1 em r_um
• b_b1 = bloco 1 em r_b
  

observe que definimos "tempo" como "altura do slot" aqui. O tempo é puramente relativo ao observador. A única noção objetiva de tempo que temos é uma ordenação relativa por um observador compartilhado, ou seja, um consenso compartilhado (onde esse "consenso" pode ser um único ator ou um mecanismo descentralizado).

se ambos os rollups têm um mecanismo de consenso que fornece ordenação, podemos afirmar:

• b_a1 é antes de b_a2
• b_b1 é antes de b_b2

no entanto, a única maneira de afirmar:

• b_a1está ao mesmo tempo em b_b1, e portanto
• t_a1e t_b1 acontecer sincronamente, é se
• eles compartilham uma ordem fornecida por um consenso compartilhado para esse determinado slot.

portanto, a composição síncrona de cadeia cruzada requer algum tipo de sequenciador compartilhado para essa altura de slot. cadeias sem uma só podem ter composabilidade assíncrona.

no entanto, observe que podemos ter composabilidade atômica assíncrona. infelizmente, percebo frequentemente que as pessoas usam "atômico" e "síncrono" de forma intercambiável, mas são de fato termos diferentes.

com isso fora do caminho, vamos ver se podemos reintroduzir a composabilidade síncrona em cadeias modulares. se pudermos, então isso pode parecer negar o valor das cadeias integradas. este é o tldr em que vamos mergulhar:

• a sequenciação partilhada pode fornecer inclusão atómica síncrona por si só (o que é muito mais fraco do que a composabilidade).
• associar um sequenciador compartilhado com algum mecanismo de segurança criptográfica (por exemplo, agglayer) pode fortalecer essa garantia de inclusão em real composabilidade.
• As garantias de segurança fornecidas pela Agglayer para a segurança entre cadeias também podem ser utilizadas sem um sequenciador compartilhado (ou seja, em um ambiente assíncrono).
• veremos como também podemos simular os efeitos da composição síncrona, embora de maneira menos eficiente em termos de capital, usando criptoeconomia (colateralizando diretamente transações entre cadeias).

inclusão atômica - sequenciamento compartilhado

o sequenciamento compartilhado significa que, para uma determinada altura de slot, uma única entidade (o "sequenciador" ou "proponente") tem direitos de monopólio para sequenciar (ou seja, propor blocos para) várias cadeias. para reiterar, esses sequenciadores compartilhados sobre os quais geralmente falamos sãosequenciadores preguiçosos. eles alcançam consenso sobre a ordenação e disponibilidade dos dados do rollup, mas não os executam. eles são completamente ignorantes das máquinas de estado dos rollups.

Como já escrevi anteriormente, isso significa que sequenciadores compartilhados preguiçosos podem fornecer um compromisso credível para incluir pacotes de cadeia cruzada (ou seja, um conjunto de transações):

• atomicamente - ou todas as transações serão incluídas ou nenhuma será, e
• sincronizadamente - ao mesmo tempo (altura da ranhura)

isso permite uma extração de mev mais eficiente porsuper construtores(ou seja, construtores de cross-chain) ao realizar ações de cross-chain, pois eles não precisam mais precificar o risco de que uma perna do pacote cross-chain possa falhar. A sincronicidade aqui é capaz de fornecer-lhes implicitamente a atomicidade.

desagregação de cross-chain

Agora, como exatamente fazemos isso sem confiar totalmente no construtor e/ou proponente ativo do sequenciador compartilhado? se apenas enviarmos duas transações assinadas de forma independente (t₁e t₂) para cada rollup, o sequenciador compartilhado ainda poderia decidir incluir apenas um ou outro.

por exemplo, não há noção de um formato de pacote nativo na evm hoje, é por isso que os pesquisadores confiam inteiramente nos construtores/relés para não desempacotá-los. qualquer pessoa que veja um pacote de transações assinadas independentemente antes de serem comprometidas pelo líder atual pode desempacotá-las. isso geralmente é bom, porque os construtores e relés são incentivados a manter suas reputações e proteger os pacotes dos pesquisadores, mas quando essa confiança é quebrada (ou eles são enganados por participantes desonestos para revelar as transações), desmembrar pode ser incrivelmente rentável.

precisamos de uma garantia de segurança muito mais forte aqui se quisermos uma verdadeira interoperabilidade entre cadeias. não estamos apenas falando em pegar algum dinheiro de um pesquisador. se os contratos defi entre cadeias fossem arquitetados com a suposição de que os pacotes entre cadeias seriam respeitados, mas essa confiança é quebrada, os resultados seriam catastróficos para esses protocolos (por exemplo, em um pacote de ponte entre cadeias de queima e criação, você poderia deixar de fora a queima, mas criar fundos do outro lado).

precisamos de garantias de segurança inabaláveis para implementar interoperabilidade entre cadeias. isso significa que devemos definir um formato de transação que garanta que várias transações em um pacote de interoperabilidade entre cadeias sejam incluídas juntas. se uma for incluída sem a outra, precisamos de uma garantia de segurança de que a que foi incluída é inválida.

isso significa que precisamos criar uma nova estrutura de transação para pacotes interligados que não podem serdesagregado. a solução ingênua é "vamos apenas criar um novo tipo de transação para esses rollups", mas isso não é tão fácil. Isso exigiria alterações na VM para esses rollups, perdendo a compatibilidade com versões anteriores. Você também estaria acoplando os rollups modificando suas máquinas de estado, de modo que cada transação só seja válida junto com a outra sendo incluída.

No entanto, há uma maneira mais limpa de fazer isso. Você pode fazer com que cada transação no pacote também assine o hash do pacote e, em seguida, anexe o resumo de hash a um campo de transação livre (por exemplo, CallData no EVM). O rollup deve modificar seu pipeline de derivação para verificá-los, mas a VM pode permanecer inalterada. Com isso em vigor, os usuários do rollup poderiam enviar pacotes entre cadeias que eles têm certeza de que não podem ser desagregados. tentar fazê-lo invalidá-los-ia.

origem: Ben fisch

garantias de inclusão vs. garantias estatais

Com o acima em vigor, agora estabelecemos como um sequenciador compartilhado preguiçoso:

• pode fornecer um compromisso credível de inclusão atómica síncrona para pacotes de cadeias cruzadas (ou seja, que todas as transações serão incluídas, ou nenhuma será)
• não pode fornecer um compromisso credível em torno do estado resultante da inclusão de tais transações (por exemplo, é possível que ambas as transações sejam incluídas, mas alguma outra transação fica à frente e faz com que ela seja revertida)

Infelizmente, a inclusão atômica por si só é uma garantia muito mais fraca. Este compromisso com a inclusão atômica é suficiente para que o construtor tenha alta confiança de que o bloco cross-rollup que eles constroem irá criar o estado resultante desejado se for confirmado. O construtor necessariamente conhece o estado resultante do bloco, pois o executou para construí-lo.

ainda temos um problema - como é que todos os outros sabem com certeza qual será o estado?

considere um exemplo:

• temos dois rollups (ra e rb) compartilhando o mesmo sequenciador preguiçoso
• Eu quero usar uma ponte de queima e criação entre ra → rb, que queima simultaneamente em ra e cria em rb
• o contrato de ponte de cunhagem em rb precisa de uma garantia da transição de estado em ra (queima) para cunhar em rb, mas o contrato não pode saber se o token foi realmente queimado em ra no momento da execução porque não tem acesso ao estado de ra

Se submetermos um pacote adequado, o sequenciador preguiçoso pode garantir que a transação de queima foi incluída na transmissão de transações para ra, mas não se sabe, por exemplo, se outra transação aterrou na frente dela que a invalidou (o que significa que os tokens não foram realmente queimados).

simplesmente compartilhar um sequenciador preguiçoso é insuficiente para permitir que as cadeias acessem os estados umas das outras durante a execução do pacote. A composabilidade síncrona requer a capacidade da máquina de estado de cada cadeia de acessar o estado da outra cadeia (por exemplo, o próprio contrato de ponte em rb precisa conhecer o estado de ra) no momento da execução. Essa capacidade é exatamente o que permite a composabilidade total dentro de uma única cadeia integrada.

o construtor não pode simplesmente dizer aos contratos "confia em mim, mano, vai dar certo." vemos que a inclusão atômica é uma ferramenta útil para buscadores que confiam nos construtores para executar corretamente seus pacotes, mas é insuficiente para abstrair a interoperabilidade entre cadeias.

para corrigir isto, precisamos de adicionar outro mecanismo para além da sequencia partilhada:

como mencionamos, o construtor pessoalmente sabe qual será o estado resultante se o pacote for incluído atomicamente. então, como podem fornecer um compromisso credível para convencer todos os outros sobre qual será o estado resultante se as suas transações forem incluídas?

eles têm basicamente duas opções:

• criptoeconómico - o construtor pode apostar uma grande quantidade de capital para garantir totalmente as suas ações cross-chain.Isto é muitas vezes ineficiente e indiscutivelmente simulado composabilidade, mas é um exemplo útil para demonstrar a funcionalidade.
• criptográfico - podemos ter um mecanismo que fornece garantias criptográficas de que as transações produzirão o estado desejado.

segurança criptoeconómica - títulos de construtor

vamos dar um exemplo para ver como a criptoeconomia pode simular os efeitos da composabilidade síncrona. O exemplo clássico utilizado é o de um empréstimo instantâneo entre cadeias. Eu quero fazer um empréstimo relâmpago na ra, usá-lo para uma arbitragem na rb e devolvê-lo na ra tudo no mesmo slot. Isso é possível se esses protocolos defi aqui implantarem funcionalidade personalizada de intercadeias com o que chamaremos de “contratos bancários” em cada lado:

Agora, em relação a esse problema de segurança - o contrato em RA e RB precisa conhecer os estados de cadeia um do outro para fazer isso com segurança, mas não fizemos nada para resolver isso. Bem, a 'solução' criptoeconômica aqui é na verdade bastante bruta - você tem o super construtor agindo como provedor de liquidez e colocando o valor total do empréstimo relâmpago. Se as transações falharem, o protocolo de empréstimo mantém sua participação de qualquer maneira. Você pode ver por que esta não é a solução mais satisfatória.

segurança criptográfica - agglayer

o que é

oAggLayeré um protocolo descentralizado que oferece três grandes benefícios:

1. Segurança para rápida compatibilidade entre cadeias - Produz provas ZK que dão segurança criptográfica à AggChains para interoperabilidade atômica entre cadeias em baixa latência (ou seja, mais rápido do que blocos Ethereum) ao operar de forma assíncrona ou síncrona. O design isola exclusivamente as falhas da cadeia para que possa suportar qualquer ambiente de execução e provador.
2. fungibilidade de ativos entre cadeias - possui uma ponte compartilhada para garantir a fungibilidade de ativos entre aggchains (ou seja, as cadeias que o utilizam), de modo que os usuários não acabem com uma série de ativos envolvidos. O contrato da ponte está no ethereum, que é o camada de liquidação. (observe que diferentes cadeias ainda podem ter diferentes pressupostos de segurança devido à implementação, o que será abordado mais abaixo.)
3. otimização de gás - isso aggreGate.ios provas para aggchains para amortizar custos fixos em muitas cadeias. o contrato de depósito compartilhado também otimiza os custos de gás, permitindo transferências diretas de l2 para l2 sem tocar no l1.

origem: Brendan agricultor, Cadeias de blocos agregadas

para esclarecer dois equívocos comuns sobre o que a agglayer não é:

• O agglayer não é apenas um serviço para aggreGate.io proofs - isto é confuso porque de facto agrega provas da Gate.io, e colocaram “agregação” no nome da coisa. No entanto, o propósito da Agglayer é agregar cadeias. A distinção importante para os propósitos deste post é que a simples agregação de provas não faz nada para alcançar as garantias de segurança que precisamos aqui.
• O agglayer e os sequenciadores compartilhados não são designs opostos- embora não precisem ser usados juntos,eles são, de fato, complementos perfeitosque fornecem diferentes garantias. A camada de agglayer é completamente agnóstica em relação à forma como as aggchains são sequenciadas. Não lida com qualquer das mensagens entre as cadeias, portanto, na realidade, depende explicitamente da infraestrutura de coordenação de livre mercado (por exemplo, relays, builders, sequenciadores isolados, sequenciadores compartilhados, etc.) para compor as cadeias.

Agora vamos ver como funciona.

a ponte é péssima

fazer ponte entre rollups hoje é complicado. digamos que você queira fazer ponte de eth entre dois rollups otimistas ethereum ouu_um e oru_b:

• via ponte nativa - você pagará taxas caras de gás ethereum l1 (ou seja, fazendo a ponte de ou para oru_umethereum + ethereum → oru_b), e a viagem de ida e volta levará mais de uma semana (por causa da janela à prova de falhas).
• direct rollup → rollup - o eth envolvido que você recebe na oru_bna verdade, não seria fungível com o eth nativo para oru_um. a dependência do caminho de passar por diferentes pontes quebra a fungibilidade. por exemplo, se o oru_uma ponte foi drenada, então o eth embrulhado que você atravessou para orub ficaria desprotegido, enquanto o eth nativo em oru_bestaria bem. A fragmentação da liquidez é terrível, portanto, isso não é algo que os usuários desejam. Na prática, os usuários fazem a ponte diretamente por meio de provedores de liquidez. Alguém fornecerá a você o ETH em nosso._be mantenha seus fundos na Gate.io_um. eles podem sacar através da ponte nativa e esperar, mas eles cobrarão taxas caras pelo risco e alto custo de capital que incorrem.

você pode pensar que as zk rollups resolvem isso imediatamente, mas na verdade elas não o fazem. implementações ingênuas ainda exigem que você envie transações l1, o que novamente é caro e geralmente bastante lento (por exemplo, devido aos tempos de finalidade do ethereum, tempos de geração de prova, com que frequência as provas são postadas na prática, etc.).

Os utilizadores não querem lidar com isto. Eles querem apenas ter fundos e usar aplicações. A ponte deve ser completamente abstraída - os ativos devem ser fungíveis e mover-se rapidamente, de forma barata e segura.

é aqui que entra o compartilhamento de um contrato de ponte. Um contrato de ponte compartilhado abre a porta para cadeias que o usam para se conectarem diretamente umas às outras sem passar pela L1.

Como resultado, os tokens também podem ser fungíveis em Aggchains. fazendo a ponte eth de r_um→ r_bou r_c → r_bqueima e cunha o mesmo token. não é um ativo envolto em bloqueio e cunhagem. é eth nativo. isto é possível porque todos os ativos são colocados em custódia juntos e liquidados através da ponte unificada. Este é um grande ponto de dor para os L2s hoje que precisa de ser tratado.

no entanto, observe que um usuário que possui eth em r_umvs. r_bpode ter um perfil de risco diferente se as diferentes cadeias usarem verificadores diferentes (por exemplo, talvez você tenha mudado de uma cadeia segura para uma com um bug de circuito). os perfis de risco não são alterados entre as cadeias que usam padrões comuns aqui (o que, na prática, é a norma hoje). padrões mais uniformes e verificação formal só melhorarão isso ao longo do tempo, mesmo com a adição de domínios heterogêneos.

Provas pessimistas

Os AGGchains enviam suas atualizações de estado e provas para os nós de estaca do AggLayer que os organizam, geram compromissos para todas as mensagens e criam provas recursivas. o agglayer então gera uma única prova aggreGate.iod zk (que eles chamam de "prova pessimista”) para liquidar para ethereum para todos os aggchains. porque a agregação de provas aqui amortiza os custos através de um número arbitrariamente grande de cadeias, é prático do ponto de vista dos custos postá-los para ethereum para liquidação rápida o mais rapidamente possível. O programa de prova pessimista é escrito em código rust regular, usandozkvm sp1 do Succinctpara facilitar o desenvolvimento e obter alto desempenho.

estas provas pessimistas reforçam:

• contabilidade interchain - prova que todas as invariantes de ponte são respeitadas (ou seja, nenhuma cadeia pode retirar mais tokens do que foram depositados nela).
• validade de aggchains - prova que cada cadeia atualizou seu estado de forma verdadeira, sem equívocos de cadeia ou blocos inválidos.
• segurança entre cadeias - prova que as atualizações de estado resultantes de transações intercadeias com latência inferior à do ethereum são consistentes e podem ser liquidadas com segurança no ethereum l1. isso inclui a execução atômica bem-sucedida de pacotes intercadeias tanto de forma síncrona quanto assíncrona.

com isso, o agglayer garante que o acerto ocorre no ethereum somente se as condições acima forem atendidas. se não forem atendidas, então as respectivas cadeias não podem liquidar. como tal, o agglayer pode permitir que um coordenador (por exemplo, um sequenciador compartilhado ou construtor) transmita mensagens entre cadeias com baixa latência sem confiar nesse coordenador para segurança.

interoperabilidade rápida e segura entre cadeias

As aggchains podem usar as garantias fornecidas aqui tanto nas configurações de interoperabilidade assíncrona quanto síncrona para expressar restrições sobre a validade do bloco em relação a outros rollups.

isso permitiria que os usuários enviassem pacotes de cadeias cruzadas que devem ser executados com sucesso atomicamente em ambos os lados. não apenas a inclusão atômica. você está realmente impondo que o estado resultante deles deve ser bem-sucedido. isso é o ajuste perfeito para complementar exatamente o que descrevemos como ausente nas garantias de inclusão atômica de um sequenciador compartilhado sozinho.

origem: Brendan agricultor, Blockchains agregadas

pegando nosso exemplo anterior:

• Temos dois rollups (R_ume r_b) partilhando o mesmo sequenciador preguiçoso e a camada de agregação
• submeti um pacote cross-chain para queimar simultaneamente eth em r_ume cunhar eth em r_b
• Um super construtor constrói um bloco para ambas as cadeias fazendo isso, com o qual o sequenciador compartilhado se compromete
• o contrato da ponte de cunhagem em r_bpode otimistamente cunhar o eth contingente ao estado de r_um(neste caso, executando com sucesso a queima de eth)
• estes blocos e provas são submetidos à camada de agregação, o que prova que ambas as cadeias atuaram de forma válida (tanto de forma independente como em relação uma à outra) e que a ponte compartilhada foi usada com segurança

para que isso seja resolvido com sucesso no Ethereum, ambas as partes do pacote devem ter sido executadas corretamente. Se algum lado falhar, os blocos seriam inválidos e não poderiam ser resolvidos. Isso significa que se, por exemplo, o sequenciador compartilhado assinar um bloco em que o ETH não foi queimado em R_um mas cunhado eth em r_b, então esse bloco seria reorganizado. isso garante a segurança de todas as cadeias e impede que ações desonestas entre cadeias sejam resolvidas.

há dois pontos a ter em mente em relação a estas reorganizações:

• seriam incrivelmente curtas porque seriam detectadas e provadas imediatamente.
• eles só podem acontecer se o coordenador (por exemplo, sequenciador e/ou construtor) da cadeia à qual você está conectado for ativamente malicioso.

essas reorganizações devem ser extremamente raras e mínimas devido aos pontos acima, mas por causa disso, as aggchains terão controle total sobre quais cadeias desejam compor atomicamente e sob quais suposições de confiança. por exemplo, r_umpode aceitar um estado de cadeia de r_bcompor com base no consenso do sequenciador, mas para r_cpode querer uma prova submetida também e para r_d Talvez eles queiram que eles protejam criptoeconomicamente todas as dependências atômicas de cadeia cruzada. Cada cadeia pode fazer suas próprias compensações personalizáveis aqui para baixa latência e vivacidade. O Agglayer apenas fornece a base maximamente flexível e minimamente opinativa para que as cadeias tenham interações seguras entre cadeias.

Você também pode ver aqui por que tal design é, na prática, incompatível com um design à prova de falhas. Em teoria, eles poderiam fazer isso, mas nesse caso seria possível experimentar reorganizações incrivelmente profundas. Provar e resolver rapidamente todas as cadeias limita o pior caso a ser muito curto, o que também atua como um dissuasor natural para quaisquer tentativas maliciosas.

isolamento de falhas para provadores heterogêneos

Importante é que a agglayer permite de forma única cadeias completamente heterogêneas. Você pode ter uma aggchain com qualquer vm personalizado, provador, camadas da da, etc., enquanto compartilha com segurança uma ponte com todos.

Como é que isto é possível? A razão pela qual isto normalmente não é aceitável é porque um único participante com falhas (por exemplo, com um erro de circuito) normalmente poderia enganar uma ponte e drená-la de todos os fundos. Bem, é aqui que entra a prova de contabilidade intercadeias mencionada acima. Estas provas garantem que os invariantes da ponte são respeitados, para que mesmo no caso de um provador insensato, apenas os fundos depositados na cadeia afetada possam ser drenados. A falha está completamente isolada.

neutralidade credível

este tipo de infraestrutura beneficia muito com a neutralidade credível, razão pela qual a código totalmente aberto para agglayer é território neutro. Em um espírito semelhante, o Agglayer usará o ETH como o único token de gás para pagar taxas pela agregação de provas.

Certamente não é perfeito. Especialmente no início, não será totalmente neutro de forma credível. é provável que haja atualização contratual no caminho para uma eventual imutabilidade e consagração como um bem público.

Dito isto, não precisa de ser perfeitamente credívelmente neutro, nada é. (veremos isso novamente abaixo com base em rollups.) Na prática, oferece provavelmente a visão técnica mais convincente e competitiva e adota uma atitude intencionalmente minimalista em relação ao lock-in e à extração de renda. O objetivo é permitir que as aggchains mantenham o máximo possível de soberania, ao mesmo tempo que ainda são capazes de abstrair a capacidade de composibilidade de cross-chain minimizada de confiança.

aggchains não precisam de uma vm específica, ambiente de execução, sequenciador, camada da, token de staking, token de gás ou governança comum. as chains podem sair quando quiserem. não há requisitos de partilha de receitas. você não precisa implantar como um l3 na chain de outra pessoa.

As razões para lançar L3s em cima de L2s gerais têm sido, na minha opinião, principalmente band-aids, enquanto arquiteturas semelhantes ao Agglayer estão sendo construídas. Para ser claro, porém, essa é uma razão totalmente válida para lançá-los hoje. O V1 Agglayer é apenas um simples contrato de ponte compartilhada. A v2 com agregação de provas e a capacidade de obter interoperabilidade segura de baixa latência nem sequer está ativa. Você não pode esperar que as pessoas esperem por anos quando têm urgência em enviar uma coisa hoje que lhes dará a distribuição mais rápida.

prova em tempo real

embora ainda faltem vários anos para serem práticos em qualquer ambiente de baixa latência, devemos notar que a prova em tempo real também pode ser potencialmente usada juntamente com a sequência compartilhada para a segurança entre cadeias. Além disso, é muito legal, então vamos abordá-lo brevemente. Mais especificamente, a prova em tempo real refere-se a tempos de prova que são mais curtos do que os tempos de slot da cadeia em questão. Vamos considerar novamente o exemplo da ponte de criação e queima de cadeias cruzadas:

• Temos dois rollups (R_ume r_bcompartilhando o mesmo sequenciador preguiçoso
• quero usar uma ponte de queima e emissão entre ra → rb que simultaneamente queima em ra e emite em rb
• O Super Builder cria um bloco de cadeia cruzada que inclui um pacote dessas transações de cadeia cruzada. Dentro dos blocos, o construtor inclui uma prova da transição de estado que está sendo incluída no outro rollup.

já tínhamos a garantia do sequenciador compartilhado de inclusão atômica síncrona de pacotes e agora cada contrato pode verificar uma prova do estado da outra cadeia para saber que será executado com sucesso.

para provar em tempo real, idealmente queremos que o tempo de prova seja apenas uma pequena fração do tempo total do slot, maximizando assim a “janela de sincronia”. esta é a parte do tempo do slot em que você é capaz de processar transações que operariam de forma síncrona entre cadeias, pois você precisa reservar tempo suficiente no slot para criar a prova e incluí-la no bloco.

fonte: Justin drake, prova em tempo real

observe que acabaríamos implicitamente mesclando ou reunindo construtores e provadores aqui. há um claro incentivo para que os construtores otimizem as velocidades de prova para que possam construir até o último segundo e colocar o máximo possível em seu bloco.

origem: Justin Drake, prova em tempo real

se esse alto incentivo para prova em tempo real se materializar nos próximos anos, devemos também observar que isso, é claro, não é nada favorável à prova descentralizada. Os provadores precisariam ser relativamente centralizados, já que se fundem ou se colocalizam com os construtores.

resumo

A composabilidade síncrona universal é realmente legal, mas não está claro o quão valiosa ela realmente é. A internet é toda assíncrona e você nunca saberia disso. Isso porque é rápido e a complexidade é abstraída. Isso é tudo o que os usuários querem.

Espero que a maior parte do valor de usar algo como Agglayer não esteja apenas na configuração síncrona. Em vez disso, é o fato de que pode atuar como uma forma de abstração de cadeia cruzada de rollup. Faça com que muitas cadeias pareçam mais uma com os aspectos voltados para o usuário que importam (por exemplo, ativos nativos mais fungíveis, funcionalidade de aplicativos nativamente intercadeia, interoperabilidade rápida, etc.).

A composabilidade síncrona é claramente financeiramente valiosa (por exemplo, permitindo liquidações, arbitragem mais eficiente, refinanciamento mais eficiente usando empréstimos rápidos). No entanto, assim como a internet é assíncrona e funciona muito bem, o tradfi é, é claro, assíncrono. É razoável querer ser ainda melhor do que o tradfi, mas devemos deixar claro que a sincronicidade universal não é um requisito para uma boa execução. Também há um custo real para construir e fornecer infraestrutura síncrona.

Eu pessoalmente acho que o melhor argumento a favor da necessidade de USC é que, na prática, isso leva a uma melhor UX e Devex. É impossível negar o benefício gigantesco que isso tem sido para ecossistemas como Solana. no entanto, espera-se que esta seja mais uma questão de hoje e não uma questão para sempre.

o simples fato da questão é que é apenas um pouco difícil para qualquer um raciocinar nessa fase. isso não é um binário “tudo em cripto é síncrono” ou “tudo é assíncrono.” acho que fundamentalmente precisaremos resolver e nos inclinar para este último, mas ambos podem existir de forma ad hoc.

Rollups baseados em Ethereum

OK, então agora devemos ter uma boa ideia do espaço de solução para abordar a fragmentação em rollups. A próxima pergunta é como devemos envolver a camada de base em tudo isso? Qual é o papel do Ethereum aqui?

usaremos as seguintes abreviaturas ao longo do texto:

• bl - camada base
• rollup baseado em br
• preconfs - pré-confirmações

Salvo indicação em contrário, o BL em questão que discutiremos é o Ethereum, e os BRs são os BRs Ethereum. No entanto, os conceitos básicos se aplicam amplamente, pois você pode lançar o BRS em qualquer lugar.

rollups baseados em baunilha

as implementações iniciais de rollup há vários anos foram na verdadeplanejado para ser brs, mas eram abandonado em favor de sequenciadores centralizados para baixa latência e alta eficiência. O que hoje chamamos de sequenciamento baseado, Vitalik referido como "anarquia total" na época. Era relativamente impraticável e ineficiente antes da evolução da infraestrutura PBS do Ethereum (com construtores sofisticados).

As BRS foram trazidas de volta ao centro das atenções em março de 2023,onde foram definidos como segue:

“Um rollup é dito ser baseado, ou sequenciado em l1, quando sua sequência é conduzida pela l1 base. Mais concretamente, um rollup baseado é aquele em que o próximo proponente l1 pode, em colaboração com os pesquisadores e construtores l1, incluir sem permissão o próximo bloco rollup como parte do próximo bloco l1.”

eles devem oferecer os seguintes benefícios:

“a sequenciação de tais rollups—-baseada na sequenciação—-é maximalmente simples e herda a vivacidade l1 e a descentralização. Além disso, os rollups baseados estão particularmente alinhados economicamente com a sua base l1.”

Especificamente, obtém a segurança em tempo real do ethereum:

"Você herda a resistência à censura e a vivacidade do ethereum. Portanto, você não apenas tem as garantias de liquidação do ethereum, mas também tem a resistência à censura, a resistência à censura em tempo real, não a atrasada que você conhece com a saída de emergência, mas a em tempo real."

Ser um rollup baseado é o design lógico uma vez que você escolheu uma camada base:

“o ethereum está a maximizar essas duas propriedades, segurança e neutralidade credível, é quase a definição de um rollup, certo ... um rollup é aquele que já comprou a suposição de segurança do ethereum. você não está adicionando uma nova suposição de segurança. você não está caindo para um elo mais fraco. você está apenas reutilizando a suposição de segurança existente. e dois é que você já aceitou o ethereum como uma plataforma credível e neutra, caso contrário, teria escolhido outra cadeia. e agora você pode se perguntar por que não está todo mundo apenas usando a sequência da camada um?”

Em sua forma mais simples, o BRS certamente pode alcançar os objetivos de design acima. Se o rollup não implementar seu próprio sequenciador, então implicitamente o proponente atual do Ethereum decide o que será incluído a cada 12s (tempo de slot do Ethereum).

no entanto, a sequenciação com base ainda traz compromissos, que é exatamenteporque os rollups geralmente implementam seu próprio sequenciador:

• pré-confs rápidas - os usuários de rollup não querem esperar 12s+ por blocos de ethereum.
• pré-confirmações seguras - às vezes os blocos Ethereum são reorganizados, então os usuários têm que esperar ainda mais para estar seguros, o que os usuários não gostam. Os sequenciadores podem dar pré-confirmações que não dependem de blocos Ethereum não finalizados e, assim, não precisam ser reorganizados mesmo se o próprio Ethereum passar por uma breve reorganização.
• postagem em lote eficiente - os sequenciadores podem agrupar muitos dados, comprimi-los e periodicamente enviá-los para o bl de forma otimizada em termos de custos (por exemplo, garantindo a utilização total do blob).

rollups baseados + preconfs

Então, podemos ter nosso bolo e comê-lo também? entrar conferências prévias baseadas.

vamos explicar a intuição por trás das preconfs baseadas aqui de forma relativamente breve para que possamos comparar brs + preconfs vs rollups tradicionais. mais tarde, voltaremos para analisar mais detalhadamente as preconfs de forma mais geral (ou seja, tanto br preconfs quanto bl preconfs em transações ethereum l1).

A ideia central é que os preconfs BR devem vir dos proponentes da BL. Para fornecer preconfs, esses proponentes devem colocar algumas garantias (por exemplo, restaking) e optar por condições adicionais de corte (ou seja, que os preconfs que eles fornecem realmente farão isso onchain, conforme prometido). Qualquer proponente disposto a fazê-lo pode agir como um sequenciador BR e fornecer preconfs.

devemos notar que os proponentes (ou seja, validadores) são realmente esperados para deleGate.io este papel de fornecer preconfs a entidades mais especializadas conhecidas como "Gate.ioways". fornecer preconfs exigirá uma entidade relativamente sofisticada, e o ethereum quer manter os proponentes não sofisticados.

no entanto, espera-se que os relés existentes também assumam esse papel. o Gate.ioway apenas interagiria entre o usuário e o relé, portanto, adicionar outra entidade independente apenas adiciona complexidade e latência (embora a latência também possa ser resolvida com a co-localização). o relé já é confiável pelos construtores e proponentes, então estaríamos adicionando outro requisito de confiança neles a partir dos usuários aqui.

Observe que, embora os validadores atualmente sirvam como proponentes de blocos Ethereum, há consideração por uma atualização pela qual o próprio protocolo leiloaria diretamente os direitos da proposta via leilões de execução. Isso permitiria que entidades sofisticadas comprassem diretamente os direitos de proposta, evitando assim a necessidade de delegar Gate.io para eles, como é contemplado aqui.

em qualquer caso, o ponto importante é que qualquer pré-conferência mais rápida que o consenso do Ethereum (12s) requer uma terceira parte confiável (ttp). Se o seu ttp é um validador reestancado, estacadoleilão de execução vencedor, deleGate.iod Gate.ioway, ou qualquer outra coisa - ele fundamentalmente não pode fornecer segurança ethereum em tempo real. Se a Coinbase está lhe dando um "Preconf Based" como um proponente Ethereum ou um "Preconf tradicional" como um Rollup Sequencer - você está confiando na Coinbase. Eles também podem colocar um vínculo de algum ETH, mas em ambos os casos isso é independente da segurança do consenso do Ethereum.

devemos notar que qualquer design pré-configurado baseado necessariamente diminui os objetivos declarados do brs com os quais começamos (simplicidade e segurança bl).As pré-confs com base estão cada vez mais complexas, e eles não podem fornecer as garantias de segurança em tempo real do ethereum.

No entanto, você deve manter a capacidade de forçar uma transação diretamente por meio de uma transação bl se esses preconizadores ficarem offline ou começarem a censurar. Essas garantias do Ethereum devem se tornar ainda mais fortes quandoListas de inclusão são implementados.

Para BRS - TTPs fornecem preconfs rápidos, e o BL fornece segurança eventual.

rollups não baseados + fallback baseado

agora vamos considerar um rollup tradicional (ou seja, não baseado). seu próprio sequenciador (centralizado ou descentralizado) fornece preconfs rápidas. posteriormente, seus usuários obtêm segurança total do ethereum com atraso. isso inclui a vitalidade (crescimento do livro-razão + resistência à censura) que vem de algum tipo de inclusão forçadaouBL fallbackmecanismo.

como notei emOs rollups herdam segurança?:

Os rollups têm a capacidade de expor regras de confirmação com propriedades de segurança equivalentes às da sua cadeia principal. Eles podem receber essas propriedades no máximo na velocidade do consenso da sua cadeia principal (e na prática, geralmente é um pouco mais lento, dependendo de com que frequência o rollup envia para a cadeia principal).

Os rollups também podem disponibilizar uma regra de confirmação mais solta de "caminho feliz" (ou seja, sequenciadores) para uma melhor UX, mas eles retêm o fallback em caso de falha. Se o seu sequenciador parar, você pode continuar em movimento.

note quetempo para segurança eventualé a variável chave a ser otimizada aqui:

a suposição de que os utilizadores rollup podem recuar para a mesma vivacidade que a cadeia de acolhimento pressupõe que pode obter inclusão forçada exatamente à velocidade dos blocos da cadeia de acolhimento (por exemplo, se o sequenciador rollup está a censurar-vos, que pode forçar a inclusão da transação no próximo bloco ethereum).

Na prática, geralmente há um curto atraso. Se você permitir a inclusão forçada imediata, poderá expor.censura lucrativa mev entre outras complexidades. no entanto, existem projetos que podem fornecer garantias de vivacidade quase em tempo realda cadeia hospedeira (por exemplo, talvez à velocidade de alguns blocos da cadeia hospedeira em vez de um bloco).

nestes termos, Sovereign labs tem um designque faz o seguinte:

• sequenciamento com permissão - os rollups definem um sequenciador com permissão cujas transações são processadas imediatamente após sua inclusão no bl. como eles possuem um bloqueio de gravação no estado do rollup, eles podem fornecer pré-configurações confiáveis mais rápido do que o tempo de bloco bl.
• Sequenciamento baseado - Os usuários também podem enviar transações diretamente para seu BL, mas elas são processadas com um atraso de bloco N (onde N é suficientemente pequeno). Isso reduz muito o "tempo para uma eventual segurança", e na verdade eles até chamam o design de "sequenciamento baseado com confirmações suaves" por causa disso! (note que esta definição de brs entraria em conflito com a definição que fornecemos anteriormente, ou seja, que o proponente bl deve ter o direito de sequenciar o br ou ser deleGate.iod por eles.)

para não-brs - ttps fornecem preconfs rápidas, e o bl fornece segurança eventual.

porquê?

como podemos ver, ambos os caminhos descritos acima produzem o mesmo resultado efetivo:

Esses brs com preconfs já não proporcionam a simplicidade ou a segurança em tempo real do ethereum. Então, qual é o ponto de tudo isso agora? Por que não apenas reforçamos as quedas nos rollups “tradicionais”? O que diabos é um rollup “baseado” neste momento?

isso realmente volta para o meuProva de governaçãopostagem do ano passado onde discuti os casos de uso fundamentais para o restake específico do Ethereum:

1) técnico (compromissos do proponente) - não há como contornar isso - se você deseja um compromisso credível com a ordenação de um bloco ethereum, ele tem que vir dos validadores ethereum.MEV-Boost++é um exemplo de uma aplicação hipotética que poderia se encaixar neste contexto.

2) social - eu vejo a alinhamento de Ethereum como o caso de uso principal para a maioria das aplicações de restaking hoje, não a agrupação de segurança econômica ou descentralização. É como dizer "...olha, somos um projeto ethereumÉ mais ou menos a mesma razão pela qual as cadeias continuam se chamando Ethereum L2S independentemente da arquitetura.

podemos modernizar isso no contexto de perguntar qual é o valor de um 'br + preconfs' em relação a um 'rollup tradicional + fallback rápido'?

1) técnico (compromissos do proponente) - ethereum brs com preconfs têm um benefício técnico fundamental - eles podem obter um compromisso credível do proponente ethereum atual em relação à inclusão e ordenação do conteúdo de um bloco ethereum. isso é potencialmente valioso pelos mesmos motivos pelos quais potencialmente queremos que um monte de rollups compartilhe um sequenciador. se o proponente bl também for o proponente br (ou seja, sequenciador), eles podem fornecer as mesmas garantias de inclusão atômica com o bl que você pode obter entre qualquer rollup compartilhando o sequenciador. eles têm um monopólio em ambas as cadeias. agora, quão valioso isso é? voltaremos a isso em breve.

2) social (alinhamento / neutralidade credível) - ame-o ou odeie-o, alinhamento do EthereumÉ um ponto de venda para ser um br. Vou ser honesto, eu não sei muito sobre taiko além de "eles são os caras do br", e provavelmente não saberia quem eles eram se não fossem os caras do br. Todo mundo quer um bom co-marketing. Há valor em ser os primeiros a mover-se aqui, mas suspeito que este não é um valor duradouro e não se estende a muitos futuros brs potenciais. Da mesma forma, todos ouvimos falar dos primeiros punhados de avss, mas você consegue nomear todos os atuais? Eu não consigo.

em um nível mais alto, você não terá todas as rollups do ethereum para aderir ao (hipotético) "sequenciador compartilhado da optimism" ou ao "sequenciador compartilhado da arbitrum". no entanto, você tem uma chance melhor de fazê-los aderir ao "sequenciador compartilhado do ethereum". nenhum novo token, nenhuma nova marca, nenhum novo consenso. se você acha que é valioso que todos os l2s do ethereum se unam na sequenciação, então essa neutralidade credível é potencialmente o ponto de schelling mais forte para alcançar esse objetivo.

Essa neutralidade credível é provavelmente mais valiosa para desenvolvedores de rollups que tentam atrair usuários entre ecossistemas (por exemplo, aplicativos com infraestrutura básica como ENS). eles podem hesitar em usar o sequenciador de otimismo se ele alienar os usuários do arbitrum, ou vice-versa.

vamos cobrir cada um deles com mais detalhes abaixo.

neutralidade credível

aprofundando esse ponto social, os brs são frequentemente vistos como a opção maximamente alinhada ao “ethereum”. deixando de lado o julgamento de qualquer um sobre o valor disso, o ponto importante é que isso pressupõe um alto grau de neutralidade credível para qualquer design de br.

um br credívelmente neutro é fácil de projetar no caso vanilla, mas como observamos ninguém realmente quer esses. preconfs então necessariamente exigem que o proponente opte por condições adicionais de penalização. essas condições adicionais de penalização exigem que o proponente use algum sistema adicional (por exemplo, potencialmente refazer a camada própria, Simbiótico, ou outra norma) para assumir o compromisso. Um rollup pode ser feliz optando pelo "sequenciador Ethereum" credivelmente neutro no abstrato, mas a neutralidade credivelmente é provavelmente perdida se você estiver usando projetos financiados por fundos privados, talvez até mesmo com tokens próprios.

há várias questões em aberto sobre a garantia aqui:

tamanho de garantia

Os primeiros designs assumiram que os proponentes teriam que colocar pessoalmente uma quantia incrivelmente alta de garantia na ordem de 1000 eth. O problema é que, fundamentalmente, um proponente pode sempre renegar sua promessa de delegar a Gate.io e construir um bloco, equivocando-se nos preconfs. Isso pode ser incrivelmente valioso e 1000 eth está confortavelmente acima dos pagamentos mais altos já observados que passaram pelo mev-boost desde sua criação. A desvantagem é que isso, é claro, cria necessariamente uma barreira de entrada alta para proponentes menores, enquanto proponentes maiores (por exemplo, Coinbase) poderiam colocar 1000 eth enquanto ganham recompensas em todo o peso de sua participação.>13% do total de eth apostado) porque os registantes podem apresentar uma única garantia para todos os seus validadores. há outras ideias para permitir proponentes com obrigações muito menores, embora é claro que vêm com compensações. o espaço de design aqui é apenas incerto.

Vale a pena notar que leilões de execução aliviaria esta preocupação, uma vez que podemos presumir que todos os proponentes seriam, então, atores sofisticados e facilmente capazes de o fazer.

fonte: Barnabé monnot, de mev-boost para epbs para aps

no entanto, mesmo os grandes operadores estão hesitantes em colocar grandes quantias, devido a possíveis problemas de liveness que resultam em slashing (uma falha de liveness por parte do operador, dando nossas preconfs e depois indo abaixo antes de serem incluídas em um bloco, é uma falha de segurança para os usuários e precisa ser penalizada severamente).

tipo de garantia

A baunilha ETH é provavelmente a única garantia credivelmente neutra nesta situação. No entanto, haverá naturalmente um desejo de usar ativos mais eficientes em termos de capital (por exemplo, Steth). Existem algumas ideias para que um subscritor lide com esta conversão, conforme descrito por mteamaqui.

plataforma

não seria muito 'credivelmente neutro' se as 'pré-configurações baseadas em ethereum' fossem mais como as 'pré-configurações baseadas em eigenlayer' ou as 'pré-configurações baseadas em simbiótica'. existem equipas que estão a planear seguir nesta direção, mas não é um requisito estrito usar tal plataforma. é possível criar um padrão geral e neutro para todos usarem, e tal sistema pareceria melhor posicionado para adoção geral como a opção mais baseada.

Será necessário adotar padrões de bem público para que os designs pré-conferência baseados possam ser plausivelmente “credivelmente neutros.”

pré-confirmações

inclusão vs. pré-confs do estado

agora iremos cobrir os preconfs em maior detalhe. Embora tenhamos discutido um tipo específico de preconf anteriormente (preconfs br no estado), devemos observar que eles são um conceito totalmente geral. Você pode oferecer preconfs em transações bl além de brs e pode oferecer diferentes níveis de força nos preconfs:

• inclusão preconfs - um compromisso mais fraco de que uma transação será eventualmente incluída na cadeia.
• preconfs de estado - o compromisso mais forte de que uma transação será incluída eventualmente na cadeia de blocos e uma garantia do estado resultante.

o último (estado preconfs) é, naturalmente, o que os usuários querem que suas carteiras lhes mostrem:

Troquei 1 ETH por $4000 USDC e paguei 0.0001 ETH em taxas

não inclusão preconfs:

Minha transação tentando trocar 1 eth por $4000 USDC e pagando até 0,0001 eth em taxas eventualmente será registrada na cadeia, mas talvez tenha sucesso, talvez falhe, veremos.

no entanto, devemos notar que as preconfs de inclusão são efetivamente intercambiáveis com as preconfs de estado no caso de ações do usuário tomadas em um estado não controverso (por exemplo, transferências simples onde apenas o próprio usuário poderia invalidar a transação). nesse caso, uma promessa de que, por exemplo, 'a transferência de usdc de alice para bob será incluída nos próximos blocos' é suficiente para uma carteira mostrar ao usuário 'você enviou seu usdc para bob'.

Sem surpresa, os compromissos mais fortes (preconfs estatais) são mais difíceis de obter. Fundamentalmente, exigem uma compromisso credívelda entidade que atualmente detém o monopólio de propor blocos (ou seja, um bloqueio de gravação no estado da cadeia). no caso das preconfs do ethereum l1, este é sempre o atual proponente do ethereum l1. no caso das preconfs br, este é presumivelmente o próximo proponente do ethereum l1 no lookahead da br (tornando-os assim o proponente atual para a br), como veremos abaixo. proponente e sequenciador são termos geralmente intercambiáveis, sendo o primeiro mais frequentemente usado no contexto l1 e o segundo no contexto l2.

preços pré-conferências

outra grande distinção que precisamos fazer é que tipo de estado essas preconfs estão tocando:

• estado não-contencioso - mais ninguém precisa de acesso a este estado (por exemplo, alice quer transferir usdc para bob)
• estado controverso - outros querem acesso a este estado (por exemplo, swaps em uma piscina eth/usdc amm)

As preconfs são restrições ao bloco que pode ser produzido. Tudo o resto igual, restringir o espaço de busca dos construtores só pode reduzir o valor potencial que eles podem capturar ao ordená-lo. Isso significa que menos valor seria retornado ao proponente. Para torná-lo compatível com incentivos, a Gate.ioway precisa cobrar uma taxa de pré-confirmação ≥ o potencial MEV perdido ao restringir o resultado.

Isso é simples o suficiente quando o MEV perdido é ~0 (por exemplo, como em uma transferência USDC). Nesse cenário, cobrar uma taxa fixa nominal poderia ser razoável. Mas temos um grande problema - como precificar preconfs em estado contencioso? Precificar preconfs antecipadamente versus apenas a tempo parece que pagaria menos. Tudo o mais igual, é mais lucrativo para um construtor esperar até o último segundo possível para capturar e precificar com precisão o MEV.

Vamos assumir, no entanto, que existe demanda suficiente do usuário por pré-confirmações rápidas em estados controversos (considerando tanto os pesquisadores sofisticados quanto os usuários normais), de forma que haverá momentos em que um preço de liquidação será benéfico para todos. Agora, como exatamente você precifica uma pré-confirmação para uma transação em um estado controverso que você poderia incluir em qualquer momento nos próximos 12 segundos, potencialmente perdendo oportunidades mais lucrativas que já não seriam possíveis?

pré-confs em estado contestado sendo transmitidos ao longo do bloco entrariam em conflito com a forma como os construtores criam blocos. precificar pré-confs com precisão requer estimar em tempo real o impacto do MEV de incluí-lo agora, em vez de atrasá-lo, o que significa executar e simular os resultados possíveis. Isso significa que o Gate.ioway agora precisa ser um pesquisador/construtor altamente sofisticado.

já assumimos que a Gate.ioway e o relay se fundiriam. se eles precisarem de preços preconfs contínuos, então também se fundirão com o builder. também aceitamos que a usc aceleraria a fusão do builder e do prover. também parece que leilões de execuçãovenderá os direitos do proponente diretamente para atores sofisticados (provavelmente construtores) capazes de precificá-los.

isto coloca toda a cadeia de abastecimento de transações l1 e br ethereum numa caixa que tem um monopólio de escrita sobre o estado de todas as cadeias durante esse período.

as políticas de encomenda do serviço pré-configurado não são claras (por exemplo, eles sempre executam fcfs ou os ordenam de outra maneira). Também é potencialmente possível que o Gate.ioway faça um leilão em todos os pré-configurados (por exemplo, permitindo que os pesquisadores façam lances nos pré-configurados), embora não esteja claro como seria esse design e isso necessariamente significaria maior latência.

problema de troca justa

há um problema justo de troca com preconfs onde a Gate.ioway não é realmente incentivada diretamente a liberar o preconf.

considere o seguinte exemplo:

• a atual Gate.ioway tem um monopólio de 12s
• um usuário envia um pedido de transação pré-confirmada logo no início do intervalo (t = 0)
• o Gate.ioway espera até t = 11,5 para liberar todas as pré-configurações que fizeram durante seu período, deixando um buffer de 500ms para incluí-las todas com seu bloco. Nesse momento, eles podem decidir quais pré-configurações incluir se forem lucrativas e quais excluir.

Neste cenário, o usuário pode acabar pagando pelo preconf, mesmo que ele não o receba de fato até o final do slot. O Gate.ioway também pode simplesmente descartá-lo no final do slot se decidir que não é lucrativo incluí-lo. Essa retenção pelo Gate.ioway não é uma falha objetivamente atribuível.mas pode ser atribuível intersubjetivamente.

Na verdade, há realmente um incentivo para que a Gate.ioways segure as pré-confirmações até o final.Onde houver assimetria de informação, haverá MEV. manter transações privadas permitiria a um construtor ter uma visão mais atualizada do estado do mundo, permitindo-lhes precificar melhor o risco e capturar o mev. não há consenso sobre o conjunto de preconfs a serem dados aos usuários, portanto, a Gate.ioway não pode ser responsabilizada aqui.

Seriam necessários padrões em vigore expectativas para o preconfirmer para imediatamente fofocar publicamente todos os preconfs. isso daria aos usuários o que eles querem imediatamente e permitiria que outros vissem que um Gate.ioway está fornecendo os serviços esperados. se eles deixarem de fazê-lo no futuro, os usuários não confiariam neles e não os pagariam pelos preconfs. a reputação do Gate.ioway tem valor. dito isso, também pode serextremamente valiososer desonesto aqui e voltar contra preconfs.

l1 camada base preconfs

com os pontos gerais pré-conferidos fora do caminho, agora discutiremos as nuances dos pré-conferidos l1. Embora não os tenhamos mencionado anteriormente, existem projetos construindo esses, e sua interação com os pré-conferidos br será importante.

por exemplo, Parafuso é um protocolo que pretende permitir aos proponentes do ethereum fazer compromissos credíveis sobre o conteúdo dos seus blocos. Os proponentes registados podem executar o sidecar bolt para receber pedidos pré-configurados dos utilizadores, confirmá-los e, em seguida, enviar estas informações para relés e construtores que possam devolver blocos que respeitem estas restrições (ou seja, devolvem um bloco que inclui as transações às quais o proponente deu pré-configurações).

é importante notar aqui queParafuso v1o descrito aqui suporta apenas a inclusão de transações simples pré-confirmadas para um estado não contencioso, onde apenas o usuário pode invalidar a pré-confirmação. como discutimos anteriormente, estes são os compromissos mais simples e fracos a fornecer.

todas essas equipes pré-configuradas têm ambições maiores (por exemplo, pré-configurações estaduais, leilões de blocos parciais, leilões de slot ou parcial de slot), então o que está impedindo-os?

• responsabilidade - violações de compromisso devem ser comprováveis ​​onchain para punição objetiva. É relativamente fácil provar a inclusão da transação, mas não está claro como fazer cumprir outros compromissos, como leilões de slot.
• requisitos de capital - fornecer compromissos arbitrários significa que o valor de violar um compromisso pode ser arbitrariamente alto. Provavelmente, a Gate.ioways acabará precisando apostar grandes quantidades (por exemplo, milhares de eth) para fornecer esses. Esses podem muito bem acabar sendo agrupados, beneficiando as maiores entidades (por exemplo, grandes empresas de negociação ou coinbase) e deixando de fora entidades menores.
• preços - há muitas perguntas em aberto sobre como precificar algo como preconfs de estado transmitido continuamente, mesmo que decidamos que seja viável e valioso.
• participação na rede - este é talvez o ponto mais importante e fundamental. como mencionamos, apenas o proponente atual que possui um bloqueio de gravação no estado pode fornecer compromissos como preconfs de estado. em teoria, 100% dos proponentes poderiam optar por este sistema e imitar isso. na prática, isso não acontecerá.

mev-boost, um produto mais simples com anos de histórico que é incrivelmente rentável para executar, tem>92% de participaçãopara contexto (provavelmente até um pouco mais alto, já que isso não leva em contamin-bid). um novo serviço pré-conferência certamente teria uma taxa de participação muito menor. mas mesmo que pudesse chegar a cerca de 90%, isso não parece ser um produto útil para usuários normais. você não pode dizer aos usuários 10% do tempo 'oh, desculpe, não há pré-conferências disponíveis agora, volte mais tarde.'

Na melhor das hipóteses, isto parece ser um estado em que as preconfs seriam apenas uma ferramenta opcional para pesquisadores e negociadores sofisticados que possam querer obter um compromisso mais cedo no bloco quando esse slot acontece ter um proponente inscrito. Isso pode ser valioso, mas não há fragmentação ou desbloqueios de UX aqui.

pré-configurações de rollup baseadas em l2

Os preconfs BR devem vir dos proponentes do BL (é por isso que eles são "baseados"). Isto exige que estabeleçam algumas garantias e optem por condições adicionais de corte (ou seja, que os preconfs que fornecem irão de facto fazê-lo onchain, tal como prometido). Qualquer proponente disposto a fazê-lo pode agir como um sequenciador BR e fornecer preconfs.

Importante, estas pré-confirmações de br são pré-confirmações de estado, não apenas pré-confirmações de inclusão. Isso é possível porque as brs estão optando por um design em que dão um monopólio de sequenciador rotativo aos proponentes bl que se inscrevem para serem Gate.ioways.

Hoje, um validador ethereum serve como proponente para cada slot, e o cronograma do proponente é sempre conhecido para a época atual e a seguinte. Uma época é composta por 32 slots, então sempre sabemos os próximos 32-64 proponentes em um determinado momento. O design funciona concedendo ao próximo sequenciador ativo (ou seja, o próximo sequenciador na antecipação) poderes monopolistas para sequenciar transações para os brs optados neste sistema pré-configurado. Os Gate.ioways devem assinar para avançar o estado das cadeias br.

observe que todo proponente (mesmo os que não optaram por ser um Gate.ioway) tem o direito, mas não a obrigação, de incluir transações que foram pré-confirmadas pelos sequenciadores (ou seja, aqueles proponentes que optaram por ser um Gate.ioway). Eles podem agir como um incluidor desde que tenham a lista completa de transações que foram pré-confirmadas até aquele momento (o sequenciador pode criar um bloco bl que contenha as transações br e divulgá-las).

origem: Sequenciamento do Ethereum, Justin Drake

o fluxo de transação funciona da seguinte forma:

1. O usuário BR envia sua transação para o próximo sequenciador no lookahead (proponente do slot N+1 na imagem abaixo)
2. o sequenciador fornece imediatamente uma pré-confirmação para o estado resultante (por exemplo, o usuário trocou 1 eth por $4000 usdc na br e pagou 0.0001 eth em taxas)
3. Neste ponto, qualquer Includer pode incluir a transação sequenciada (o proponente do slot n faz isso na imagem abaixo)

origem: Sequenciamento do Ethereum, justin drake

se os outros incluidores não incluírem as preconfs, então o sequenciador que as deu pode simplesmente incluí-las na cadeia quando for a sua vez como o proponente bl. por exemplo, na imagem acima, suponha que o incluidor do slot n decidiu não incluir as preconfs que o sequenciador do slot n+1 distribuiu. então o sequenciador do slot n+1 seria responsável por incluir todas as preconfs que distribuiu durante o slot n e o slot n+1 quando enviar o seu bloco bl para n+1. isso permite que o sequenciador distribua com confiança as preconfs para o período completo entre eles e o último sequenciador.

para simplificar as explicações acima, simplesmente assumimos que o proponente l1 cumpriria esse papel preconfer. como descrito anteriormente, no entanto, isso provavelmente não será o caso. isso exigirá uma entidade sofisticada para precificar os preconfs, executar nós completos para todos os brs, ter proteção contra dos e largura de banda suficiente para todas as transações br, etc. o ethereum quer manter os validadores muito pouco sofisticados, então os proponentes provavelmente terão terceirizar os preconfs para outra entidade de forma muito semelhante à terceirização da produção de blocos l1 completa via mev-boost hoje.

os proponentes podem delegar a Gate.io para a Gate.ioways por meio de mecanismos onchain ou offchain, e isso pode ser feito até pouco antes de seu espaço. como mencionado anteriormente, este papel provavelmente será assumido pelos relays na prática. também é possível que eles precisem se fundir com os builders também.

origem: Sequenciação baseada, justin drake

como descrito anteriormente, apenas uma entidade pode ser deleGate.iod para ser o Gate.ioway em um determinado momento. isso é necessário para fornecer preconfs de estado confiáveis. uis (por exemplo, carteiras como metamask) procurariam quem é o próximo Gate.ioway e enviariam transações de usuários para lá.

Rollups do Ethereum - quão baseados eles serão?

com fundo suficiente agora em vigor - devem os rollups do ethereum ser baseados? há realmente duas perguntas embutidas aqui:

1. Deveriam muitos rollups Ethereum compartilhar um sequenciador?
2. Se sim, deveria ser um sequenciador baseado (ou seja, envolvendo os proponentes da ethereum bl e a infraestrutura mev circundante)?

Em primeiro lugar, é importante notar que você pode compartilhar um sequenciador com outras cadeias de forma ad hoc. Por exemplo, o proponente do Ethereum pode sequenciar um bloco para você se eles fizerem a oferta mais alta, então algum outro consenso bft pode sequenciar seu próximo bloco se eles fizerem a oferta mais alta. No entanto, isso ainda requer que uma cadeia opte completamente por este leilão compartilhado uniforme que pode ser executado de forma síncrona com essas outras cadeias, portanto, ainda existem compensações em relação ao controle e flexibilidade (por exemplo, tempos de bloco compartilhados). É apenas que a entidade sequenciadora vencedora pode mudar.

Independentemente disso, vamos apenas assumir que a condição 1 é cumprida. Acredito que temos evidências convincentes neste ponto de que existe demanda suficiente para usar um sequenciador compartilhado descentralizado. Mesmo que se importem menos com o "aspecto compartilhado", acredito que há um valor incrivelmente alto em poder adquirir um sequenciador descentralizado como serviço pronto para uso (na verdade, acho que este é o maior valor aqui).

agora, este sequenciador partilhado deve ser um sequenciador baseado em Ethereum?

compromissos técnicos do proponente

Não vejo um argumento técnico forte para usar um sequenciador baseado em Ethereum. Qualquer interoperabilidade entre BRS e o Ethereum L1 seria incrivelmente limitada devido à incapacidade de executar de forma confiável no L1 (ou seja, não ter consistentemente um bloqueio de gravação no estado do L1), longos tempos de bloco (12s) e o fato de que transações BRS que desejam interagir com o L1 teriam que se reorganizar ao lado dele. Aqui não há almoço grátis. Isso não desbloqueia produtos valiosos para o usuário em comparação com qualquer outro sequenciador compartilhado externo.

O valor primário que vejo é que adicionar o Ethereum L1 a este leilão combinatório maior pode resultar em maior valor agregado criado pela Gate.io e...permitir que o l1 capture mais valorlevando essa lógica ao extremo, provavelmente deveríamos colocar tudo no mundo no mesmo leilão. este leilão universal também deve sequenciar os bilhetes para o concerto da taylor swift. ainda não estou lá.

Isto é apenas para destacar que existe uma complexidade técnica e social real na criação e adesão de todos a este leilão partilhado, que tem um custo real, que, na minha opinião, provavelmente supera qualquer valor adicional teórico criado aqui. É possível construir facilmente um design técnico muito melhor para executar isto a partir dos primeiros princípios, se não estivermos a tentar colocá-lo em cima do ethereum l1 (por exemplo, apenas ter um mecanismo de consenso rápido e simples construído para este fim). Para não mencionar o facto de que um leilão combinatório como este criaria um aumento exponencial na complexidade.

Na prática, existe um risco significativo para mim de que isso possa, na realidade, ser gravemente contraproducente para o Ethereum, já que essa arquitetura pré-conferência parece potencialmente aceleracionista em relação à infraestrutura MEV quando a cadeia de suprimentos do Ethereum já é um tanto frágil. Isso arrisca comprometer a descentralização e a resistência à censura da rede - as coisas que a tornam valiosa em primeiro lugar.

social (neutralidade credível)

Eu vejo um argumento social válido para um sequenciador baseado em Ethereum.

como mencionado anteriormente, não há dúvida de que o 'alinhamento' é uma venda para os primeiros brs. isso é bom, mas não acredito que isso dure. é legal ser o primeiro br, não é legal ser o oitavo. precisa haver algum outro valor adicionado.

Penso que a neutralidade credível de um sequenciador baseado em Ethereum é potencialmente esse valor. Provavelmente é o argumento mais forte a favor de tal design, pelo menos. Há muitas cadeias que querem obter um sequenciador descentralizado pronto a usar. Se eventualmente pudermos projetar infraestrutura suficiente em cima desta coisa que melhora a experiência cruzada entre cadeias, então ainda melhor. Dos projetos que desejam tal design, no entanto, imagino que muitos deles hesitem em “escolher um lado” com qualquer protocolo de terceiros. Como mencionado anteriormente, imagine que é uma cadeia de aplicativos com alguma infraestrutura geral básica como ens, e quer um rollup. Não quer escolher o sequenciador compartilhado (hipotético) do arbitrum e afastar o público do optimism, ou vice-versa.

possivelmente a única solução para o problema de coordenação social aqui é ter um sequenciador compartilhado credivelmente neutro, o que o ethereum é claramente o candidato mais forte para. note-se que isso coloca um grau ainda maior de ênfase nos pontos que mencionei anteriormente em relação à neutralidade credível - se esse for o principal valor agregado desse serviço, então esse deve ser um objetivo de design de alta prioridade na criação dele. não funcionará se parecer ser o projeto pessoal de algum protocolo de terceiros com seus próprios motivos lucrativos. ele tem que ser realmente o sequenciador compartilhado do ethereum.

Vale ressaltar que também há críticas razoáveis de que “neutro” aqui é código para “ethereum.” ou seja, que sua motivação principal é beneficiar o ethereum e sua infraestrutura nativa circundante. E é claro que tal sistema beneficiaria essas partes. Significaria mais captura de valor para o eth, o ativo, e mais lucratividade para os construtores, relés e pesquisadores do ethereum.

rollups baseados em fast

camadas base rápidas

agora devemos entender que você pode ter brs em um bl lento como ethereum, pode adicionar pré-confirmações confiáveis para uma ux mais rápida e até mesmo garantir a segurança ao mover-se entre cadeias através de garantias criptoeconômicas ou criptográficas.

como observado, e se apenas projetássemos essa coisa do zero. sem lidar com a dívida técnica e as decisões de uma cadeia existente. qual é a maneira óbvia de construir a coisa...

Anteriormente, discutimos como a única razão técnica para ser um br com preconfs para um determinado bl (por exemplo, ethereum) é para que seu proponente possa fornecer compromissos credíveis em momentos referentes à inclusão atômica síncrona com o bl.

No entanto, não discutimos seriamente a capacidade de ser um br sem pré-confirmações. Basicamente, descartamos isso porque o Ethereum é lento e os usuários são impacientes.

então, por que não usamos um bl rápido para brs?

isso resolve praticamente todos os casos de borda complexos e preocupações que tínhamos antes. não queremos casos de borda estranhos em que Gate.ioways tenha falhas de vida (que têm o mesmo resultado que falhas de segurança aqui), não queremos que eles desistam das pré-configurações prometidas (ou seja, falhas de segurança), e não queremos reorgs ethereum. é exatamente por isso que existe consenso.

as camadas estão mortas, viva as camadas de sequência!

A maior parte da conversa sobre Prezy Sequencers os contempla como um Rollup Sequencer que então despeja seus dados em alguma outra camada DA. Por exemplo, os dois primeiros rollups da Astria (Forma e Flama) usará o celestia como sua camada da da. O consenso da Astria irá sequenciar esses rollups e, em seguida, irá transmitir seus dados para o celestia.

esta combinação é especialmente boa porque são complementares óbvios - Astria fornece toda a infraestrutura de sequenciamento e Celestia fornece verificação minimizada de confiança através deamostragem de disponibilidade de dados (das).

No entanto, Astria também poderia ser usada para sequenciar um rollup que é nativo do Ethereum, Bitcoin, Solana ou qualquer outra coisa que você queira. Por exemplo, ela poderia até mesmo ser configurada para ser usada como um preconfer para o Ethereum “brs com preconfs” (por exemplo, em vez de um Gate.ioway centralizado, já que um sequenciador preguiçoso é basicamente apenas um relé incentivado e descentralizado).

Para ser claro, cada cadeia é uma camada de dados. Os nós completos sempre podem verificar os dados. Faz parte das condições de validade de qualquer cadeia que os dados estejam disponíveis, portanto o consenso sempre está validando que os dados estão disponíveis. Os nós leves que verificam sua validação pressupõem uma maioria honesta. A única diferença é se a cadeia fornece outra opção para os clientes leves amostrarem diretamente os dados em vez de perguntar ao consenso.

No entanto, como eu observei emOs rollups herdam segurança?, cadeias rápidas como Astria poderiam tecnicamente adicionar um caminho lento para DAS (para melhorar a verificabilidade), e cadeias lentas como Celestia poderiam adicionar um caminho rápido para sequenciamento (com uma suposição de confiança majoritária e sem DAS), assim chamado "blocos rápidos praças lentas.

mover-se para integrar verticalmente camadas especializadas como sequenciamento ou das iria estreitar ainda mais a distinção entre blockchains modulares e integrados. isso se aplica de forma semelhante à integração vertical docamada de liquidaçãovia adicionandoContas verificadoras ZK para a camada base da celestia.

No entanto, existe um valor significativo em manter esses serviços separados em vez de agrupá-los. Esta é a abordagem modular que permite que os rollups escolham quais recursos eles desejam prontos para uso (por exemplo, quero comprar sequenciamento descentralizado com blocos rápidos, mas não quero pagar por DAS, ou vice-versa). Pesquisadores mostraram que eles querem DAS, mas os usuários até agora mostraram que eles só querem blocos rápidos.

agrupando serviços como no “blocos rápidos quadrados lentos"seria muito opinativo e integrado. isso necessariamente adicionaria complexidade e custo. o efeito do comprimento do slot sobrejogos de timing(e, portanto, potencialmente descentralização) que agora são predominantes no ethereum também são considerações.

camada base rápida vs. lenta + predefinições

mas também pode apenas usar astria como o bl para rollups. os sequenciadores partilhados podem ser pensados como bls que são otimizados para brs próprios.

quando o seu bl é rápido, o seu br não precisa de pré-confirmações, porque ele simplesmente obtém confirmações rápidas automaticamente! então o seu rollup na realidade obtém a segurança em tempo real do seu bl, ao contrário dos brs + pré-confirmações que necessariamente perdem isso.

brs sem pré-configurações são, de fato, a maneira mais lógica de construir um rollup. é por isso que todos os rollups de hoje começaram lá:

está claro que um bl com blocos rápidos resolve a maioria dos nossos problemas em “based rollups + preconfs”. Sequenciadores compartilhados são naturalmente construídos a partir de uma abordagem de princípios básicos de “ei desenvolvedores de aplicativos só querem lançar uma cadeia rápida, confiável e descentralizada - como eu dou isso a eles?” Tentar adicionar preconfs depois do fato em uma camada base mais lenta como o ethereum resulta nas complexidades que descrevemos acima.

todos estamos a construir a mesma coisa

a modularidade é inevitável

Portanto, vimos como podemos agregar cadeias modulares Gate.io de volta juntas, proporcionando composabilidade síncrona universal (usc). Existem compensações, é claro, mas elas reintroduzem um grau significativo de unidade, ao mesmo tempo que preservam muito mais flexibilidade do que o uso de uma única máquina de estado. Também há um caso muito convincente para mim de que a composabilidade assíncrona é tudo o que precisamos para a grande maioria dos casos de uso. Precisamos de baixa latência, desempenho e boa experiência do usuário. A internet é assíncrona e funciona muito bem abstraindo tudo isso. A composabilidade é um grande valor agregado da criptografia, mas composability ≠ sincronicidade.

Além dos benefícios de flexibilidade e soberania, a maioria das pessoas concordaria que eventualmente precisaremos de muitas cadeias para escalar de qualquer maneira. Isso significa que acabaremos com muitos sistemas que precisamos unificar, portanto, a direção modular é inevitável aqui.

ethereum + preconfs → solana?

agora, vamos comparar os finais de jogo aqui. em particular, vamos comparar o final de jogo da solana vs. o final de jogo da ethereum, se ela seguir por esse caminho de maximizar a unidade e a experiência do usuário com base em rollups + preconfs.

nesta visão, temos um monte desses brs usando o sequenciador baseado em ethereum. Gate.ioways estão continuamente transmitindo preconfs prometidos pelo proponente (ou seja, sem nenhum peso de consenso) para os usuários com baixa latência, então os proponentes ethereum os confirmam em um bloco completo de vez em quando. isso pode parecer familiar porque é praticamente o que descrevemos para solana anteriormente com shred streaming!

Então, isto é apenas uma Solana mais complicada? A grande diferença aqui está nos tempos de slot:

O ethereum tentar adicionar isso em cima de uma cadeia lenta claramente apresenta problemas à primeira vista:

• O consenso do Ethereum é muito lento para os usuários, então a única maneira de obter uma UX rápida e credível é com pré-confirmações prometidas pelo proponente, com base em opt-in. Seu principal gargalo hoje é a agregação de assinaturas como resultado de seu enorme tamanho de conjunto de validadores (.MaxEBe a agregação de assinaturas melhorada poderia ajudar aqui).
• isso resulta em monopólios de proponentes muito mais longos, fornecendo incentivos e liberdade maiores para capturar mais MEV agindo de maneira desonesta (por exemplo, retendo pré-confirmações).
• se a Gate.io começar a atrasar ou reter pré-confirmações, então o pior caso para os utilizadores passa a depender dos tempos de slot do ethereum. mesmo que os produtores de blocos da solana parem de construir blocos continuamente e transmitir dentro de seus monopólios alocadosuma vez que é provável que eles o façam em algum grau pela mesma razão exata), então o pior caso volta-se para a dependência de um consenso rapidamente rotativo.A monopólio de quatro slots é necessário hoje em dia para a confiabilidade da rede.
• Na prática, é provável que haja muito poucas Gate.ioways, pelo menos no início, resultando em um conjunto de operadores mais centralizado em comparação com cadeias como Solana.
• potencialmente altas exigências de garantia para proponentes (observando que o espaço de design ainda está em progresso).
• preocupações sobre questões de vivacidade serem incrivelmente caras aqui (já que problemas de vivacidade do operador que levam a pré-confirmações perdidas resultam em falhas de segurança para os utilizadores e, portanto, devem ser passíveis de penalização pesada).

tudo isso é resolvido com um consenso rápido. todos esses sistemas são literalmente por que fazemos sistemas bft em primeiro lugar. então, por que o ethereum não deveria apenas tornar seu consenso mais rápido então? existem alguns trade-offs menos óbvios ao ter tempos de bloco de camada base super baixos?

Por sorte, não tenho nada melhor para fazer do que escrever um ensaio sobre se blocos mais curtos são bons. A grande preocupação com os tempos de bloco mais curtos está relacionada com a centralização de validadores e operadores. Especificamente, há preocupações com a interação de tempos de bloco curtos com...jogos de cronometragem:

já estamos a ver jogos de tempo a avançar no ethereum. os proponentes estão a propor blocos mais tarde nos seus slots, ganhando mais dinheiro à custa dos outros. os relés também estão a oferecerjogos de cronometragem como um serviço“onde eles atrasam de maneira semelhante os blocos mais tarde no slot:

origem: Os dados sempre

os jogos de tempo foram um grande tópico de discussão no algo infameJustin vs. podcast bankless tolyde algumas semanas atrás:

por exemplo, digamos que você seja 100ms mais rápido do que todos os outros

se tiver 1s slots, pode ganhar 10% mais do que todos os outros

se você tiver slots de 10s, pode ganhar 1% a mais do que todos os outros

— Jon Charbonneau (@jon_charb)4 de junho de 2024

justin argumentou principalmente que os jogos de temporização serão um problema, e as recompensas incrementais serão sempre relevantes. toly argumentou principalmente que os jogos de temporização não serão um problema, e que as recompensas incrementais obtidas da extração adicional de MEV não são motivo de preocupação.

Pessoalmente, acho difícil ignorar a importância do timing dos jogos aqui:

• já os vemos em prática no ethereum hoje.O argumento Solanao que acontece é que isso só acontece porque o mev se tornou socialmente normalizado no ethereum antes, mas isso não é convincente quando haviaforte protesto público contra jogos de tempo antecipado que desde então se transformou em aceitaçãodesta nova realidade a ser projetada.
• as recompensas de mev são significativas - já estamos a falar sobre bilhões de dólares em pagamentos de MEV aqui, não tostões debaixo da almofada do sofá. Mesmo ganhando "apenas alguns por cento a mais" com isso é uma enorme soma de dinheiro.
• mesmo que você não acredite que os stakers sejam suficientemente sensíveis ao rendimento na margem,os operadores reais estão a administrar empresase isso vai direto para o resultado final delas.
• É mais fácil para a solana depender de grandes partes interessadas altruístas(por exemplo, a fundação e grandes investidores) mais cedo no seu ciclo de vida, masisso não é sustentável à medida que qualquer rede se descentraliza ainda mais.

Claramente acredito que há uma enorme quantidade de valor na direção que tanto a Solana como a Ethereum estão a tomar. Se nada mais, veremos tudo a ser posto em prática. Estrategicamente, também acho que faz sentido para a Ethereum se apoiar no que a torna diferente aqui. Maximizar a descentralização como meio para alcançar resistência à censura em circunstâncias adversas. A Ethereum fez muitos sacrifícios para manter um protocolo incrivelmente descentralizado porque é uma necessidade para o jogo longo. Tem uma diversidade de clientes incomparável, distribuição de propriedade de rede, partes interessadas no ecossistema, descentralização de operadores e muito mais. Se (e provavelmente quando) a Solana enfrentar uma séria pressão de censura no futuro, tornar-se-á cada vez mais evidente por que a Ethereum tomou as decisões que tomou.

preconf.wtf aconteceu na zuberlin na semana passada e, talvez não surpreendentemente, todo mundo estava falando sobre preconfs e based rollups. E isso foi tudo muito legal. Mas eu pessoalmente achei Palestra do Vitalikemlistas de inclusão de um bit por atestadore a conversa de Barnabé sobreSobrecarregar o proponente de execução em vez disso (de mev-boost para epbs para aps)ser o mais importante para o futuro do ethereum.

Fonte: Barnabé monnot, De mev-boost para epbs para aps

As conversas prévias e baseadas em rollup começaram a ganhar ímpeto muito recentemente, e eu definitivamente ainda estou do lado mais cauteloso. Vitalik famosamente delineou o seguinte Fim do jogo:

no entanto, avançamos bastante na "produção centralizada" sem ainda implementar proteções mais fortes contra a censura, como listas de inclusão. basicamente, o ethereum está metade na parte inferior deste quadro abaixo. (digo metade porque a censura na verdade não é preta e branca, e o ethereum só tem "censura fraca", ou seja, a maioria, mas não todos os blocos, são censurados, então você pode esperar um pouco, mas então será incluído):

origem: Prova de governação

Empiricamente, a cadeia de abastecimento MEV da ethereum L1 censura em tempo real mais blocos do que qualquer um destes L2s com sequenciadores centralizados.

l2s já podem obter o cr final do l1 (que ainda é muito bom) sem serem baseados. As pré-confirmações baseadas não obtêm a segurança em tempo real do protocolo ethereum, elas obtêm a segurança em tempo real de um pequeno punhado de provedores de infraestrutura relativamente centralizados ao seu redor. Para uma cr em tempo real melhor, a melhor opção provavelmente é terceirizar a sequenciação para algum tipo de sequenciador descentralizado que execute um consenso bft simples. Isso será muito mais robusto do que centralizar muitas cadeias em um gargalo atualmente relativamente centralizado. Essa situação pode melhorar com mudanças como leilões de execução e listas de inclusão, mas isso não está exatamente em breve.

Com tudo isso considerado, não está claro para mim que expandir a dependência da infraestrutura MEV do Ethereum L1 e depois consolidá-la para o L2 é uma ótima ideia neste estágio, quando há um punhado de pessoas que constroem e retransmitem todos os blocos Ethereum, a maioria dos blocos livres de censura do Ethereum hoje dependem de um único construtor (Titan), e nenhuma das ferramentas CR foi implementada no protocolo ainda. isso parece agressivamente acelerador em um ponto frágil. Ethereum certamente deve estar trabalhando para melhorar a UX de L2S, mas não à custa de todas as propriedades subjacentes que queríamos em primeiro lugar.

conclusão

todos estamos construindo a mesma coisa.

bem, mais ou menos. obviamente, essas coisas não são todas literalmente a mesma coisa. sempre haverá diferenças práticas entre esses sistemas. no entanto, a mega tendência predominante em criptomoedas é clara de que todos estamos convergindo para arquiteturas cada vez mais semelhantes.

as diferenças técnicas sutis entre eles podem na prática ter implicações significativas para onde acabam, e não podemos subestimar o quão grande é o papel da dependência do caminho nesses sistemas, mesmo à medida que convergem para jogos finais semelhantes.

além disso, é malditamente impossível racionalizar sobre algumas dessas coisas.Como Vitalik colocou:

“Um ponto de cautela que eu tenho para os APS é que eu acho que, do ponto de vista puramente técnico, na verdade acho que é bem simples e somos totalmente capazes de realizar isso com muito pouca chance de erro técnico... mas do ponto de vista econômico, há muito mais oportunidade para as coisas darem errado...

como o eip-1559, conseguimos descobrir com a teoria. fomos a algumas conferências de economia adoráveis ​​e aprendemos sobre os perigos de leilões de primeiro preço e como eles são ruins, e descobrimos que leilões de segundo preço não são confiáveis, e então descobrimos, ei, vamos usar um mecanismo de preço fixo localizado dentro de cada bloco, e conseguimos fazer muito com a microeconomia.

mas aps não é assim, certo. e a questão de se aps vai levar à citadel ou jane street ou justin sun ou quem quer que seja a produzir 1% de todos os blocos de ethereum ou 99% é muito, muito difícil, provavelmente impossível de descobrir a partir dos primeiros princípios.

e assim, a coisa que eu quero ver neste momento é a experimentação ao vivo... para mim pessoalmente, a diferença entre hoje e eu me sentir realmente confortável com as aplicações é basicamente as aplicações funcionando com sucesso em uma camada 2 da Ethereum que tenha uma quantidade média de valor, atividade, comunidade e contenda real acontecendo e que dure por um ano, possivelmente mais um ano, e nós realmente sermos capazes de ver algumas consequências ao vivo.

Então, sim, eu também não sei o que vai acontecer. Vamos ter que esperar para ver. De qualquer forma, enquanto todos convergimos para o que quer que seja esse jogo final, temos muito mais em comum do que diferenças, então vamos garantir que por favor...

aviso legal:

1. este artigo é reproduzido a partir de [dba]. encaminhar o título original 'estamos todos construindo a mesma coisa'. todos os direitos autorais pertencem ao autor original [jon charbonneau]. se houver objeções a esta reimpressão, por favor entre em contato com oGate.io aprenderequipa, e eles tratá-lo-ão prontamente.
2. aviso de responsabilidade: as opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. as traduções do artigo para outros idiomas são feitas pela equipe de aprendizagem da Gate.io. salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.