encaminhar 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á desvincular a execução do consenso sobre a ordem (sequenciamento).
• sequenciamento preguiçoso - como eles irã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.
• comparando rollups baseados com preconfs com rollups não baseados e fallback da camada base.
• composabilidade 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 fast - os rollups baseados devem simplesmente ter uma camada base rápida.
• jogos de cronometragem - Tempo é dinheiro, e como isso subjaz os desfechos divergentes entre solana vs. ethereum.
• descentralização para resistência à censura - comoseparação de testemunha-proprietáriovialeilões de execuçãopode preservar validadores descentralizados que podem garantir resistência à censura comlistas de inclusão.

por último, e mais importante, veremos porquêestamos todos construindo a mesma maldita coisaentão talvez devêssemos apenas…

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

vamos construir a partir do básico para ver que o final de alto desempenho blockchains (por exemplo, Solana, Monad, @patrickogradyabordagens do HyperSDK) que se aproximam da de uma estratégia de mitigação para permitir que os construtores de maximização de lucro minimizem os TPS inválidos.sequenciador preguiçoso (por exemplo, @astriaorg/hj6ccpp9t">astria). vamos voltar ao ponto de partida 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 sua própria cópia do estado do sistema. para progredir na corrente, os nós executam a função de transição de estado (stf) sobre o estado atual + novos inputs (por exemplo, novas transações). isso produz o novo estado.

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

• válido sintaticamente - a transação é 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 inclusão de dados.
• executar - interpretar e agir sobre os dados de acordo com o stf.
• construir - criar um bloco (ou fragmento de bloco parcial) a partir de transações armazenadas localmente.
• verificar - realizar a verificação sintática e/ou semântica necessária de um bloco (ou parte de um bloco/chunk/shred).
• replicar - disseminar um bloco (ou fragmento/fragmento parcial de bloco) para outros validadores.

vamos focar na sequência e execução, pois essas 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 pela rede. Os nós chegam a um consenso para manter uma visão consistente da cadeia.

no entanto, 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 execução). o tempo de ponta a ponta do total replicação de máquina de estado (smr)O loop dita os limites inferiores da latência do sistema. Diferentes construções podem resultar em tempos altamente variáveis, portanto um processo SMR que seja eficiente.oleodutos) essas tarefas são necessárias para desempenho de baixa latência e alta taxa de transferência.

nas seções a seguir, veremos que uma percepção fundamental da execução eficiente em pipeline é focar em alcançar consenso sobre as entradas de execução em vez dos resultados de execução. Isso requer relaxar certas restrições sobre quais transações podem ser incluídas. Em seguida, 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

smr tradicional (por exemplo, ethereum) acopla sequenciamento e execução. nós completos sequenciam e executam continuamente todas as transações da camada base - ambos são pré-requisitos para que os nós alcancem 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 que:

• todas as transações são sintaticamente e semanticamente válidas
• o novo estado computado corresponde ao fornecido pelo líder

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

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

fonte: @patrickogrady/rys8mdl5p#defendendo a replicação de máquina de estado desacoplada DSMR">vryx: fortalecendo a replicação de máquina de estado desacoplada

streaming smr

O streaming smr (por exemplo, Solana) é uma forma eficiente de pipelining em queprodutores de blocos continuamente "transmitem" pedaços de blocos (chamado fragmentosou pedaços) à 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.

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

neste modelo de streaming, a construção e a verificação ainda incluem sequenciamento e execução. isso aumenta a eficiência do SMR em relação ao SMR tradicional sem relaxar quaisquer restrições 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 ordenação dos dados sem executar esses dados primeiro. isso é mais eficiente, por isso 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 só chegariam a um consenso sobre a ordem e disponibilidade de transações. isso é suficiente porque, dada uma stf determinística, todos eventualmente computarão o mesmo estado. a execução não precisa sustentar o consenso - pode ser executada de forma assíncrona. isso pode abrir o orçamento de execução para os nós (dando a eles mais tempo para gastar com a execução) enquanto reduz os passos necessários (e, portanto, o tempo) para alcançar o consenso.

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

provavelmente é por issoKeone acredita que, no final, todas as blockchains utilizarão execução assíncrona, e é uma peça chave de A visão final do Toly para Solana:

“A execução síncrona requer que todos os nós que votam e criam blocos sejam superdimensionados para o pior tempo de execução em qualquer bloco... os nós de consenso podem realizar menos trabalho antes de votar. O trabalho pode ser agregado e agrupado, tornando-o eficientemente executado sem perdas de cache. Ele pode até ser executado em uma máquina diferente da dos nós de consenso ou líderes. Usuários que desejam 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 o estado completo é computado para o bloco. O objetivo desta proposta é separar a decisão de votar em um fork da computação da transição de estado completa 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 designs que atrasam a execução significativamente tornariam isso desafiador (por exemplo, )Solana considerando exigir apenas uma vez por época) em comparação com outros que fornecem uma raiz de estado em um intervalo de tempo mais curto (por exemplo, como no hypersdk).

abordagem modular

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

• sequenciamento - nós do sequenciador 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 respectivos dados depois que o sequenciador os comprometeu.

a diferença principal aqui é que os nós da cadeia integrada executam após a sequenciação enquanto os sequenciadores preguiçosos a empurram para um conjunto totalmente diferente e diversificado de atores. Os sequenciadores preguiçosos são completamente ignorantes das 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 perfeita entre os usuários do ambiente de execução, mas reduz a flexibilidade direcional para os desenvolvedores de aplicativos (por exemplo, vms personalizados, diferentes horários de slot,regras de precificação e ordenação de transações específicas do aplicativo, reforçadas por consenso, etc.). a abordagem modular proporciona mais flexibilidade e soberania para os desenvolvedores 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 é o primitivo que precisamos:

No entanto, você deve observar que tecnicamente você pode usar praticamente qualquer cadeia como um sequenciador preguiçoso. No final das contas, é apenas um grande tubo de dados. Um rollup pode ingenuamente jogar seus dados arbitrários em sua camada base de escolha (seja ethereum, bitcoin, monad, etc.) para usá-la implicitamente como seu sequenciador. Os nós de rollup podem então executar os dados de forma assíncrona posteriormente.

A diferença na prática é que as cadeias que realmente nos referimos como 'sequenciadores preguiçosos' são especializadas para essa tarefa, que é muito mais fácil falar do que fazer (por exemplo, suportar tipos de transações necessárias, expor interfaces fáceis, implementar infraestrutura mev, tempos de slot rápidos, inclusão confiável de transações, alta largura de banda, etc.). Como resultado, os nós para 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 vamos simplesmente usar Solana (ou qualquer outra cadeia quando esse nunca foi o objetivo de design) como um sequenciador de rollup?" :

• faltando a infraestrutura mev necessária projetada especificamente para rollups (por exemplo, infraestrutura pbs requisita, 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 rollups postando dados.
• competindo contra o ambiente de execução nativo (por exemplo, foi projetado explicitamente para consumir o máximo de dados fornecidos possível, 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. você provavelmente está mais inclinado a ir para o protocolo e equipe especializados em ajudá-lo a lançar rollups e projetando seu protocolo especificamente com você em mente, em vez daquele em que a maioria da comunidade acha rollups meio bobos.

Fortalecendo o SMR desacoplado

Agora, podemos resolver esses problemas que surgem ao relaxar essas restrições? Em suma, sim, 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 passíveis de serem resolvidos de forma que não se tornem problemas graves.

não vamos nos aprofundar muito nos detalhes aqui, mas você pode se referir aPatrick o’grady’strabalho incrível em@patrickogrady/rys8mdl5p# fazendo-o-caso-para-a-replicação-de-máquina-de-estado-desacoplada-dsmr">vryx para fortalecer o smr desacoplado, de toly fim de execução assíncrona, eImplementação do Monad dos custos de transportesobre 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 mantêm a maioria dos benefícios de desempenho sem deixar abertas uma série de ataques.

atores dentro do protocolo vs. atores fora do protocolo

É importante perceber que os processos acima mencionados contabilizaram ingenuamente apenas os atores no protocolo. Na realidade, os atores fora do protocolo desempenham um papel enorme nessas cadeias de suprimento de transações. Foi isso que vimos anteriormente para os validadores (no protocolo) na SMR tradicional:

fonte: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: fortalecendo a replicação de máquina de estado desacoplada

na prática, no entanto,quase todos os validadores do Ethereum terceirizam a construção de blocos através da mev-boostcom os três principais construtores (beaver, titan e rsync) construindo quase todos esses blocos. note que beaver e rsync censuram transações do ofac enquanto Titan não.

fonte: mevboost.pics

os relés lidam com a replicação desses blocos para o resto 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 surpresa que vejamos tendências muito semelhantes em otimizações de latência aqui, como discutimos anteriormente. A tendência é rumo relés otimistasque não realizam mais 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. os validadores terceirizam a produção de blocos porque construtores sofisticados podem capturar mais valor em comparação com blocos sequenciados ingenuamente.

mesmo sob execução assíncrona, frequentemente 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 formato de pbs. o fato de um produtor de blocos externo sempre ser incentivado a executar completamente e otimizar o valor de um bloco pode ser útil em configurações onde relaxamos as restrições na execução assíncrona. no entanto, outros validadores não precisariam reexecutar antes de votar.

composabilidade síncrona universal

definições

Agora, podemos obter a soberania e flexibilidade que as cadeias modulares oferecem, mas reunir-se para parecer uma cadeia integrada? Podemos ter nosso bolo e comê-lo também, ou acabamos apenas construindo Solana com passos extras?

quando se ouve as pessoas falarem sobre a correção da fragmentação do rollup, provavelmente você já ouviu as grandes palavras-chave ao redorcomposabilidade síncrona universal (USC). No entanto, esta provavelmente foi a sua reação:

todos esses termos são jogados com significados diferentes, e alguns termos são muitas vezes usados incorretamente de forma intercambiável. Temos de definir algumas definições concretas. Definimos os termos necessários abaixo no contexto da composição entre cadeias.

Observe que discutiremos "rollups" ao longo do restante 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 = transaçã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
  

note 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 possuem um mecanismo de consenso que fornece ordenação, podemos afirmar:

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

no entanto, a única maneira de afirmar:

• b_a1 está ao mesmo tempo em b_b1, e portanto
• t_a1e t_b1acontecer sincronamente, é se
• eles compartilham uma ordem fornecida por um consenso compartilhado para aquele determinado slot.

Portanto, a definição da composabilidade síncrona entre cadeias requer, por definição, algum tipo de sequenciador compartilhado para essa altura da slot. Cadeias sem um só podem ter composabilidade assíncrona.

no entanto, observe que podemos ter composabilidade atômica assíncrona. infelizmente, muitas vezes percebo as pessoas usando "atômico" e "síncrono" de forma intercambiável, mas eles 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:

• o sequenciamento compartilhado 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 esta garantia de inclusão em composição real.
• as garantias de segurança fornecidas pela agglayer para segurança cross-chain também podem ser usadas sem um sequenciador compartilhado (ou seja, no ambiente assíncrono).
• veremos como também podemos simular os efeitos da composabilidade síncrona, embora de maneira menos eficiente em termos de capital, usando a 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", também conhecido como "propositor") 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 chegam a um consenso sobre a ordenação e disponibilidade dos dados de rollup, mas não os executam. eles são completamente ignorantes das máquinas de estado dos rollups.

Como eu já escrevi anteriormente, isso significa que os sequenciadores compartilhados preguiçosos podem fornecer um compromisso crível de 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á,
• de forma síncrona - ao mesmo tempo (altura do slot)

Isso permite uma extração de MEV mais eficiente por super construtoresou seja, os construtores de cadeias cruzadas, ao realizar ações entre cadeias, não precisam mais precificar o risco de que uma perna do pacote de cadeias cruzadas possa falhar. A sincronicidade aqui é capaz de fornecer implicitamente a atomicidade.

desagregação entre cadeias

agora, como exatamente fazemos isso sem confiar totalmente no construtor e/ou proponente ativo para o sequenciador compartilhado? se apenas enviarmos duas transações assinadas independentemente (t₁e t₂) para cada rollup, o sequenciador compartilhado ainda pode 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 totalmente nos construtores/retransmissores para não descompactá-los. qualquer pessoa que veja um pacote de transações assinadas independentemente antes de serem confirmadas pelo líder atual pode descompactá-las. isso geralmente é bom, porque os construtores e retransmissores têm incentivos para manter suas reputações e proteger os pacotes dos pesquisadores, mas quando essa confiança é quebrada (ou quando são enganados por participantes desonestos para revelar as transações),a desagregação pode ser incrivelmente lucrativa.

Precisamos de uma garantia de segurança muito mais forte se quisermos uma verdadeira interoperabilidade entre cadeias. Não estamos falando apenas de tirar algum dinheiro de um pesquisador. Se os contratos de defi de cadeia cruzada fossem arquitetados na suposição de que os pacotes de cadeia cruzada serão respeitados, mas então essa confiança é quebrada, os resultados seriam catastróficos para esses protocolos (por exemplo, em um pacote de ponte de cadeia cruzada de queima e hortelã, você poderia deixar de fora os fundos de queima, mas de hortelã do outro lado).

precisamos de garantias de segurança inabalável 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 cadeia cruzada sejam incluídas juntas. se uma for incluída sem a outra, precisamos de uma garantia de segurança de que a incluída é inválida.

isso significa que precisamos criar uma nova estrutura de transação para pacotes intercadeia que não podem serdesagrupado. 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 mudanças na VM para esses rollups, perdendo a compatibilidade reversa. Você também estaria acoplando fortemente os rollups ao modificar suas máquinas de estado de forma que cada transação seja válida apenas junto com a outra sendo incluída.

No entanto, há uma maneira mais limpa de fazer isso. você pode ter cada transação no pacote também assinar o hash do pacote, em seguida, anexar o resumo do hash a um campo de transação livre (por exemplo, calldata no evm). o rollup deve modificar seu pipeline de derivação para verificar esses, mas o vm pode permanecer inalterado. com isso em vigor, os usuários do rollup poderiam enviar pacotes entre cadeias que têm certeza de que não podem ser desagrupados. tentar fazê-lo os invalidaria.

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 crível de inclusão síncrona atômica para pacotes de cadeia cruzada (ou seja, que todas as transações serão incluídas ou nenhuma será)
• não pode fornecer um compromisso confiável em relação ao 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 seja colocada à frente e faça com que ela reverta)

Infelizmente, a inclusão atômica por si só é uma garantia muito mais fraca. Esse compromisso com a inclusão atômica é suficiente para que o construtor tenha alta confiança de que o bloco de 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, no entanto - como todos os outros sabem com certeza qual será o estado?

considere um exemplo:

• nós temos dois rollups (ra e rb) compartilhando o mesmo sequenciador preguiçoso
• Eu quero usar uma ponte de queima e cunhagem entre ra → rb que queima simultaneamente em ra e cunha 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 enviarmos um pacote adequado, então o sequenciador preguiçoso pode garantir que a transação de queima foi incluída no fluxo de transações para ra, mas você não sabe, por exemplo, se talvez outra transação tenha chegado na frente dela e a invalidado (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 composição 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 saber o estado de ra) no momento da execução. Essa capacidade é exatamente o que permite uma composição completa dentro de uma única cadeia integrada.

O construtor não pode simplesmente dizer aos contratos 'confie em mim, cara, vai dar certo'. Vemos que a inclusão atômica é uma ferramenta útil para pesquisadores que confiam nos construtores para executar corretamente seus pacotes, mas é insuficiente para abstrair a interoperabilidade entre cadeias.

para corrigir isso, precisamos adicionar algum outro mecanismo além da sequenciação compartilhada:

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

eles têm amplamente duas opções:

• criptoeconômico - o construtor pode apostar uma grande quantidade de capital para garantir totalmente suas ações intercadeias.Isso geralmente é ineficiente e, possivelmente, uma composição simulada, 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 criptoecônomico - títulos de construtor

vamos passar por um exemplo para ver como a criptoeconomia poderia simular os efeitos da composabilidade síncrona. o exemplo clássico usado é o de um empréstimo instantâneo entre cadeias. eu quero fazer um empréstimo relâmpago em ra, usá-lo para arbitragem em rb e devolvê-lo em ra, tudo no mesmo slot. isso é possível se esses protocolos defi aqui implementarem funcionalidades personalizadas de cross-chain 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” cripto-econômica aqui é na verdade bastante bruta - você tem o super construtor atuando como provedor de liquidez e colocando o valor total do empréstimo instantâneo. Se as transações falharem, o protocolo de empréstimo mantém sua participação de qualquer maneira. Você pode ver por que essa não é a solução mais satisfatória.

segurança criptográfica - agglayer

o que é

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

1. Segurança para rápida composição de cadeia cruzada - Produz provas ZK que dão segurança criptográfica AgGchains para interoperabilidade de cadeia cruzada atômica em baixa latência (ou seja, mais rápido do que blocos Ethereum) ao operar de forma assíncrona ou síncrona. O projeto isola exclusivamente as falhas de cadeia para que possa suportar qualquer ambiente de execução e provador.
2. fungibilidade de ativos entre cadeias - ela tem uma ponte compartilhada para garantir a fungibilidade de ativos em todas as aggchains (ou seja, as cadeias que a utilizam) para que os usuários não acabem com um monte de ativos envelopados. O contrato da ponte está no ethereum, que é o camada de liquidação. (observe que cadeias diferentes ainda podem ter pressuposições de segurança diferentes devido à implementação, o que é abordado mais abaixo.)
3. otimização de gás - isso aggreGate.io prova 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 fazendeiro, Blockchains agregadas

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

• A agglayer não é apenas um serviço para comprovar aggreGate.io- isso é confuso porque realmente agrega provas da Gate.io, e eles colocaram "agregação" no nome da coisa. No entanto, o propósito da AggLayer é agregar cadeias. A distinção importante para os objetivos deste post é que a simples agregação de provas não faz nada para alcançar as garantias de segurança que precisamos aqui.
• Os aglayers e sequenciadores compartilhados não são designs opostos - embora eles não precisem ser usados juntos, eles são de fato complementos perfeitosque fornecem garantias diferentes. A camada agregada é totalmente agnóstica em relação à sequência das aggchains. Ela não lida com nenhuma das mensagens entre as cadeias, portanto, na verdade, depende explicitamente da infraestrutura de coordenação do mercado livre (por exemplo, relés, construtores, sequenciadores isolados, sequenciadores compartilhados, etc.) para compor as cadeias.

agora vamos ver como funciona.

pontes chupa

fazer a ponte entre rollups hoje é complicado. Digamos que você queira fazer a ponte do eth entre dois rollups otimistas do Ethereum (ORU)._ae oru_b:

• via ponte nativa - você pagará altas taxas de gás ethereum l1 (ou seja, fazendo a ponte de oru_um→ ethereum + ethereum → oru_b), e a viagem de ida e volta levará mais de uma semana (por causa da janela de prova de falhas).
• rollup direto → rollup - o eth envolvido que você recebe na oru_bnão seria realmente 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_ase a ponte foi drenada, então o eth envolvido que você transferiu para orub ficaria sem suporte, enquanto o eth nativo em oru_bseria bom. A fragmentação da liquidez é ruim, então isso não é algo que os usuários queiram. Na prática, os usuários fazem a ponte diretamente via provedores de liquidez. Alguém irá fornecer o eth para você em nosso._be mantenha seus fundos em oru_umEles podem sacar via ponte nativa e esperar, mas cobrarão taxas caras pelo risco e alto custo de capital que incorrem.

você pode pensar que os zk rollups resolvem isso imediatamente, mas na verdade não resolvem. 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 usuários não querem lidar com isso. Eles querem apenas ter fundos e usar aplicativos. A ponte deve ser completamente abstraída - os ativos devem ser fungíveis e mover-se rapidamente, barato e com segurança.

é aqui que entra o compartilhamento de um contrato de ponte. Um contrato de ponte compartilhado abre as portas para cadeias que o utilizam para fazer uma ponte diretamente entre si sem passar pelo l1.

tokens também podem ser fungíveis em aggchains como resultado. bridging eth de r_um → r_bou r_c → r_b queima e hortelã da mesma forma. não é um ativo embrulhado em cadeado. é ETH nativo. Isso é possível porque todos os ativos são depositados juntos e liquidados por meio da ponte unificada. Este é um grande ponto problemático para L2s hoje que precisa ser abordado.

no entanto, observe que um usuário que possui eth em r_avs. 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). perfis de risco não são alterados entre 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 com o tempo, mesmo com a adição de domínios heterogêneos.

provas pessimistas

As aggchains enviam suas atualizações de estado e provas para os nós staked da camada de agregação que as organizam, geram compromissos para todas as mensagens e criam provas recursivas. A camada de agregação então gera uma única prova zk de aggreGate.iod (que eles chamam de "aggreGate").prova pessimista") para se contentar com Ethereum para todos os aggchains. Como a agregação de provas aqui amortiza os custos em muitas cadeias arbitrariamente, é prático do ponto de vista de custos publicá-los no Ethereum para liquidação rápida o mais rápido possível. O programa de prova pessimista é escrito em código Rust regular, usando zkvm sp1 do Succinctpara facilidade de desenvolvimento e alto desempenho.

essas 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 das aggchains - prova que cada chain atualizou seu estado de forma verdadeira, sem equívocos de chain ou blocos inválidos.
• Segurança Cross-chain - Prova que as atualizações de estado que são o resultado de transações cross-chain com latência inferior à Ethereum são consistentes e podem ser liquidadas no Ethereum L1 com segurança. Isso inclui a execução atômica bem-sucedida de pacotes de cadeia cruzada de forma síncrona e assíncrona.

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

interoperabilidade rápida e segura entre cadeias

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 inclusão atômica. você está efetivamente aplicando que o estado resultante deles deve ser bem-sucedido. isso é perfeito para complementar exatamente o que descrevemos como faltando nas garantias de inclusão atômica de um sequenciador compartilhado sozinho.

fonte: Brendan agricultor, Blockchains agregadas

pegando nosso exemplo anterior:

• temos dois rollups (r_um e r_b) compartilhando o mesmo sequenciador preguiçoso e a camada de agregação
• Eu envio um pacote intercadeia para queimar etéreo simultaneamente em r_ume cunhar eth em r_b
• um super construtor constrói um bloco para ambas as cadeias fazendo isso, que o sequenciador compartilhado se compromete
• o contrato da ponte de cunhagem em r_b pode otimistamente cunhar o eth contingente ao estado de r_um (neste caso, executando com sucesso a queima ETH)
• esses blocos e provas são enviados à camada agregadora, que comprova que ambas as cadeias agiram de maneira válida (tanto independentemente quanto em relação uma à outra) e que a ponte compartilhada foi usada com segurança

para que isso seja resolvido com sucesso para o ethereum, ambas as pernas do pacote devem ter sido executadas corretamente. Se qualquer um dos lados falhar, os blocos serão inválidos e não poderão ser resolvidos. Isso significa que se o sequenciador compartilhado assinar um bloco onde o eth não foi queimado em r_ummas o eth cunhado em r_bse esse bloco for 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 com relação a essas reorganizações:

• eles seriam incrivelmente curtos porque seriam detectados e comprovados 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 os AgGchains terão controle total sobre quais cadeias eles querem compor atomicamente e sob quais pressupostos de confiança. por exemplo, r_umpode aceitar um estado de cadeia de r_bcom base no consenso do sequenciador, mas para r_cele pode querer uma prova também enviada, e para r_dtalvez eles queiram que eles garantam criptoeconomicamente todas as dependências atômicas entre cadeias. cada cadeia pode fazer suas próprias compensações personalizáveis aqui para baixa latência e vivacidade. a 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 projeto é, na prática, incompatível com um projeto baseado em 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 impedimento natural para quaisquer tentativas maliciosas.

isolamento de falhas para verificadores heterogêneos

Importante, o agglayer permite de forma exclusiva cadeias completamente heterogêneas. Você pode ter um aggchain com qualquer vm personalizado, provador, camadas de DA, etc., enquanto compartilha com segurança uma ponte com todos.

como isso é possível, no entanto? A razão pela qual isso normalmente não é aceitável é porque um único participante defeituoso (por exemplo, com um bug de circuito) normalmente poderia enganar uma ponte e drená-la de todos os fundos. Bem, é aí que a prova de contabilidade intercadeias mencionada acima entra em jogo. Essas provas garantem que as invariâncias da ponte sejam todas respeitadas, de modo que mesmo no caso de um provador não confiável, apenas os fundos depositados na cadeia afetada poderiam ser drenados. A falha está completamente isolada.

neutralidade credível

esse tipo de infraestrutura é grandemente beneficiado pela neutralidade credível, por isso o Código fonte totalmente aberto ifor Agglayer é território neutro. em um espírito semelhante, a agglayer usará eth como o único token de gás para pagar taxas de agregação de prova.

certamente não é perfeito. especialmente no início, não será totalmente neutro. É provável que haja atualização contratual no caminho para uma eventual imutabilidade e consagração como bem público.

Dito isso, não precisa ser perfeitamente neutro em termos de credibilidade, nada é. (veremos isso novamente abaixo com base em rollups.) Na prática, oferece provavelmente a visão técnica mais convincente e concorrente, e adota uma atitude intencionalmente minimalista em relação à dependência e extração de aluguel. O objetivo é permitir que os Aggchains mantenham o máximo possível de soberania, ao mesmo tempo que ainda é capaz de abstrair a composabilidade cross-chain com minimização de confiança.

Os AgGchains não precisam de nenhuma VM específica, ambiente de execução, sequenciador, camada DA, token de stake, token de gás ou governança comum. As correntes podem sair quando quiserem. não há requisitos de compartilhamento de receita. Você não precisa implantar como um L3 na cadeia de outra pessoa.

As razões para lançar L3s em cima de L2s gerais têm sido principalmente, na minha opinião, curativos enquanto arquiteturas similares ao Agglayer estão sendo construídas. Para ser claro, no entanto, essa é uma razão totalmente válida para lançá-los hoje. O Agglayer v1 é apenas um contrato de ponte compartilhado simples. O v2 com agregação de prova e a capacidade de obter interoperação segura de baixa latência nem mesmo está em operação. Não se pode esperar que as pessoas esperem por anos quando têm urgência de enviar uma coisa hoje que lhes dará a distribuição mais rápida.

prova em tempo real

Embora esteja a vários anos de distância de ser praticável em qualquer configuração de baixa latência, devemos observar que a prova em tempo real também poderia ser potencialmente usada em conjunto com a sequenciação compartilhada para garantir a segurança entre cadeias. Além disso, é apenas legal, então vamos cobrir brevemente. Mais especificamente, '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 de ponte de criação e queima entre cadeias.

• temos duas rollups (r_ume r_b) compartilhando o mesmo sequenciador preguiçoso
• Eu quero usar uma ponte de queima e hortelã entre RA → RB que queima simultaneamente em RA e hortelã em RB
• O super construtor 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 síncrona de pacotes atômicos, 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 funcionariam de forma síncrona entre cadeias, pois você precisa reservar tempo suficiente no slot para criar a prova e adicioná-la ao bloco.

fonte: Justin drake, prova em tempo real

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

fonte: Justin drake, prova em tempo real

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

resumo

A composabilidade síncrona universal é muito legal, mas não está super 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.

Eu 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 agir como uma forma de abstração de cadeia cross-rollup. Faça com que muitas cadeias se sintam mais como uma com os aspectos voltados para o usuário que importam (por exemplo, ativos nativos mais fungíveis, funcionalidade de aplicativos nativamente cross-chain, 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 instantâneos). No entanto, assim como a internet é assíncrona e funciona muito bem, a tradfi é, claro, assíncrona. É razoável querer ser ainda melhor do que a tradfi, mas devemos deixar claro que a sincronicidade universal não é um requisito para uma boa execução. Também há um custo real na construção e fornecimento de infraestrutura síncrona.

pessoalmente, acho que o melhor argumento a favor da necessidade do usc é que, na prática, isso leva a uma melhor experiência do usuário e desenvolvimento. É impossível negar o enorme benefício que isso tem sido para ecossistemas como o Solana. No entanto, esperamos que isso seja mais um problema atual do que um problema eterno.

o simples fato da questão é que também é um pouco difícil para qualquer pessoa raciocinar sobre isso nesse estágio. isso não é um binário de 'tudo na criptografia é síncrono' ou 'tudo é assíncrono'. acredito que precisaremos resolver fundamentalmente e tender para o último, mas ambos podem existir em uma base ad hoc.

rollups baseados em Ethereum

ok, então agora devemos ter uma boa ideia do espaço de solução para lidar com a fragmentação em rollups. a próxima pergunta é como devemos envolver a camada base em tudo isso? qual é o papel do ethereum aqui?

usaremos as seguintes abreviaturas ao longo de todo o texto:

• BL - Camada Base
• rollup baseado em br
• preconfs - pré-confirmações

a menos que seja observado o contrário, o bl em questão que estaremos discutindo é o ethereum, e os brs são os brs ethereum. no entanto, os conceitos básicos se aplicam amplamente, já que você pode lançar brs em qualquer lugar.

rollups baseados em baunilha

as implementações iniciais de rollup há vários anos na verdade foram planejado ser brs, mas eram abandonado em favor de sequenciadores centralizados para baixa latência e alta eficiência. o que agora chamamos de sequenciamento baseado, vitalik referido como "anarquia total" na época, era relativamente imprático 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 eles foram definidos da seguinte forma:

“um rollup é dito ser baseado, ou sequenciado no l1, quando sua sequência é conduzida pelo l1 base. mais concretamente, um rollup baseado é aquele em que o próximo proponente l1 pode, em colaboração com 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 sequência desses rollups - a sequência baseada - é maximamente simples e herda a liveness e a descentralização do l1. Além disso, os rollups baseados são especialmente alinhados economicamente com seu l1 base.”

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

"Você herda a resistência à censura e a vivacidade do Ethereum. Então, não só você 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 escotilha de escape, mas a em tempo real."

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

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

em sua forma mais simples, os brs certamente podem 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, o sequenciamento baseado ainda vem com compensações, que é exatamentepor que os rollups geralmente implementam seu próprio sequenciador:

• preconfs rápidos - usuários de rollup não querem esperar 12s+ por blocos ethereum.
• pré-confirmações seguras - às vezes os blocos do Ethereum são reorganizados, então os usuários têm que esperar ainda mais para estar seguros, o que novamente os usuários não gostam. Os sequenciadores podem fornecer pré-confirmações que não dependem de blocos não finalizados do Ethereum e, assim, não precisam ser reorganizados mesmo se o próprio Ethereum passar por uma reorganização curta.
• Lançamento em lote eficiente - Os sequenciadores podem agrupar muitos dados, compactá-los e publicá-los periodicamente no BL de maneira otimizada em termos de custo (por exemplo, garantindo o uso total do blob).

rollups baseados + preconfs

então, podemos ter nosso bolo e comêa-lo também? entrar preconfs baseados.

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

a ideia central é que as preconfs dos br preconfs devem vir de bl propositores. para fornecer preconfs, esses propositores devem colocar algum colateral (por exemplo, restaking) e optar por condições adicionais de slashing (ou seja, que as preconfs que eles fornecem serão de fato disponibilizadas conforme prometido). qualquer proponente disposto a fazê-lo pode atuar como um sequenciador br e fornecer preconfs.

devemos observar que os proponentes (ou seja, validadores) são realmente esperados para delegar esse papel de fornecer preconfirmações para entidades mais especializadas conhecidas como "Gate.ioways". fornecer preconfirmações 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 interage 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 co-localização). O relé já é confiável pelos construtores e proponentes, então estaríamos adicionando outro requisito de confiança a eles, por parte dos usuários aqui.

observe que, embora os validadores atualmente atuem como proponentes de blocos do Ethereum, há consideração para uma atualização em que o próprio protocolo leiloaria diretamente os direitos de proposta vialeilões de execução. Isso permitiria que entidades sofisticadas comprassem diretamente os direitos de proposta, evitando assim a necessidade de que os validadores (os proponentes atuais) os deleguem, como contemplado aqui.

De qualquer forma, o ponto importante é que qualquer pré-conf mais rápido do que o consenso do Ethereum (12s) requer um terceiro confiável (TTP). Se o seu TTP é um validador restaked, apostado leilã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 baseado" como um proponente Ethereum ou um "Preconf tradicional" como um sequenciador de rollup - você está confiando na Coinbase. Eles também podem colocar um título de algum ETH, mas em ambos os casos isso independe da segurança do consenso do Ethereum.

devemos observar então que qualquer design pré-conferência baseado necessariamente detrai dos objetivos declarados de brs com os quais começamos (simplicidade e segurança bl).As preconfs baseadas sã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 preconfers forem offline ou começarem a censurar. essas garantias do ethereum devem se tornar ainda mais fortes quandolistas de inclusãosão implementados.

para brs - ttps oferece pré-confirmações rápidas, e o bl oferece segurança eventual.

rollups não baseados + fallback baseados

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

como eu mencionei emOs rollups herdam segurança?:

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

Os rollups também podem disponibilizar uma regra de confirmação mais flexível do "caminho feliz" (ou seja, sequenciadores) para uma melhor UX, mas eles mantêm o fallback em caso de falha. Se o sequenciador parar, você poderá continuar se movendo.

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

a suposição de que os usuários do rollup podem retornar à mesma vivacidade equivalente da cadeia hospedeira assume que você pode obter a inclusão forçada exatamente na velocidade dos blocos da cadeia hospedeira (por exemplo, se o sequenciador rollup estiver censurando você, que você pode forçar a inclusão da transação no próximo bloco ethereum).

na prática, geralmente há um pequeno atraso. se permitir a inclusão forçada imediata, você poderia exporcensura lucrativa meventre outras complexidades. no entanto, hádesigns que podem fornecer garantias de vivacidade quase em tempo reala partir da cadeia hospedeira (por exemplo, talvez na velocidade de alguns blocos da cadeia hospedeira em vez de um bloco).

nesse espírito, Sovereign labs tem um designque faz o seguinte:

• sequenciamento com permissão - rollups definem um sequenciador com permissão cujas transações são processadas imediatamente após sua inclusão no bl. Como eles têm um bloqueio de gravação no estado do rollup, eles podem fornecer preconfs confiáveis ​​mais rapidamente do que o tempo de bloco do bl.
• sequenciamento baseado - os usuários também podem enviar transações diretamente para suas bl, mas elas são processadas com um atraso de n blocos (onde n é suficientemente pequeno). Isso reduz muito o "tempo até a segurança eventual", e de fato eles até mesmo chamam o design de "sequenciamento baseado com confirmações suaves" por causa disso! (observe que essa 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 fornece preconfs rápidos, e o bl fornece segurança eventual.

por quê, porém?

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

Esses brs com preconfs não oferecem mais 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 ponto?

isso na verdade retorna para o meuProva de governançapost do ano passado onde discuti os casos de uso fundamentais para redespecificação específica do ethereum:

1) técnico (compromissos do proponente) - não há como contornar isso - se você quer 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 enquadrar nesse perfil.

2) social - eu vejo a alinhamento do Ethereum como o caso de uso principal para a maioria das aplicações de re-estaca hoje, não agrupamento de segurança econômica ou descentralização. está ficando para dizer " Olha que somos um projeto Ethereum!” é praticamente a mesma razão pela qual as cadeias continuam se chamando ethereum l2sindependentemente 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 pré-confs 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 pelas mesmas razões exatas pelas 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 rollups 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, não sei muito sobre taiko além de 'eles são os caras do br', e provavelmente não saberia quem eles são se não fossem os caras do br. Todos querem um bom co-marketing. Há valor em serem os primeiros aqui, mas suspeito que este não seja um valor duradouro e não se aplique 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 elevado, você não conseguirá fazer com que todos os rollups do ethereum optem pelo (hipotético) “sequenciador compartilhado do Optimism” ou o “sequenciador compartilhado do Arbitrum”. No entanto, você tem uma chance melhor de fazê-los optar pelo “sequenciador compartilhado do Ethereum”. Sem novo token, sem nova marca, sem novo consenso. Se você acha valioso que todos os L2s do ethereum se unam na sequência, 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 os desenvolvedores de rollups que tentam atrair usuários de ecossistemas cruzados (por exemplo, aplicativos com infraestrutura básica como ens). Eles podem hesitar em usar o sequenciador de otimismo se isso afastar os usuários do arbitrum, ou vice-versa.

vamos cobrir cada um destes em mais detalhes abaixo.

neutralidade credível

Aprofundando esse ponto social, as BRs são frequentemente vistas como a opção maximamente "alinhada com Ethereum". Deixando de lado o julgamento de qualquer pessoa sobre o valor disso, o ponto importante é que isso pressupõe um alto grau de neutralidade credível para qualquer projeto de BR.

Um BR credivelmente neutro é fácil de projetar no caso da baunilha, mas como observamos ninguém realmente quer isso. As pré-confs, então, exigem necessariamente que o proponente opte por condições de corte adicionais. Essas condições adicionais de corte exigem que o proponente use algum sistema adicional (por exemplo, potencialmente reposição de camada própria, Simbiótico, ou outro padrão) para assumir o compromisso. um rollup pode ficar feliz ao optar pelo neutro credível "ethereum sequencer" no abstrato, mas a neutralidade credível provavelmente é perdida se você estiver usando projetos financiados privadamente, talvez até com tokens próprios.

há várias perguntas em aberto sobre o colateral aqui:

tamanho do colateral

Os primeiros projetos assumiram que os proponentes teriam que colocar pessoalmente uma quantidade incrivelmente alta de garantias na ordem de 1000 ETH. A questão é que, fundamentalmente, um proponente sempre pode renegar sua promessa de deleGate.io e autoconstruir 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, necessariamente cria uma alta barreira de entrada para proponentes menores, enquanto os maiores (por exemplo, Coinbase) poderiam mais razoavelmente colocar 1000 ETH enquanto ganhavam recompensas em todo o seu peso de aposta (>13% do total de ETH apostado) porque os registrantes podem fornecer uma única garantia para todos os seus validadores. Há outras ideias para permitir proponentes com títulos muito menores, embora é claro que vem com compensações. O espaço de design aqui é apenas incerto.

vale ressaltar que leilões de execução aliviaria essa preocupação, pois podemos supor que todos os proponentes seriam então atores sofisticados facilmente capazes disso.

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

Entretanto, mesmo os grandes operadores estão hesitantes em disponibilizar grandes quantidades, devido a possíveis problemas de atividade resultando em penalidades (uma falha de atividade por parte de um operador, dando nossas pré-confirmações e depois caindo 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

O vanilla eth é provavelmente o único colateral credível e neutro nesta situação. No entanto, naturalmente, haverá o desejo de utilizar ativos mais eficientes em capital (por exemplo, steth). Existem algumas ideias para ter um subscritor lidar com esta conversão, conforme descrito por mteam aqui.

plataforma

não seria muito "credivelmente neutro" se os "preconfs baseados em Ethereum" fossem mais parecidos com os "preconfs baseados em EigenLayer" ou os "preconfs baseados em Symbiotic". Existem equipes que planejam seguir nessa direção, mas não é um requisito estrito usar tal plataforma. É possível criar um padrão geral e neutro para que todos usem, e tal sistema pareceria melhor posicionado para adoção geral como a opção mais baseada.

A adoção de padrões de bem público será necessária para que os projetos pré-conferência baseados sejam plausivelmente "credíveis neutros".

preconfirmações

inclusão vs. preconfs do estado

Agora vamos cobrir preconfs em maior detalhe. Enquanto discutimos um tipo específico de preconf anteriormente (br preconfs on state), devemos observar que eles são um conceito totalmente geral. Você pode oferecer preconfs em transações bl, além de brs, e você pode oferecer diferentes níveis de preconfs:

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

Este último (preconfs de estado) é, 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 pagar até 0,0001 ETH em taxas eventualmente será confirmada na rede, mas talvez tenha sucesso, talvez falhe, veremos.

No entanto, devemos observar que as pré-confs de inclusão são efetivamente intercambiáveis com as pré-confs de estado no caso de ações do usuário realizadas em um estado não controverso (por exemplo, transferências simples em que 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 que uma carteira mostre ao usuário 'você enviou seu USDC para Bob'.

não surpreendentemente, os compromissos mais fortes (pré-conferências estatais) são mais difíceis de obter. fundamentalmente, eles requerem um compromisso credívelda entidade que atualmente tem o monopólio de propor blocos (ou seja, um bloqueio de gravação no estado da cadeia). no caso dos pré-confs ethereum l1, este é sempre o atual proponente ethereum l1. no caso dos pré-confs br, este é presumivelmente o próximo proponente ethereum l1 no br's lookahead (tornando-os assim o proponente atual para o 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.

preconfs de preços

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

• estado não controverso - ninguém mais precisa acessar este estado (por exemplo, Alice quer transferir USDC para Bob)
• estado controverso - outros querem acesso a esse estado (por exemplo, swaps em um pool amm eth/usdc)

as preconfs são restrições sobre qual bloco pode ser produzido. tudo o mais sendo igual, restringir o espaço de busca para os construtores pode apenas 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.io precisa cobrar uma taxa de preconf maior ou igual ao MEV potencial 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, a cobrança de alguma taxa fixa nominal poderia ser razoável. Mas temos um grande problema - como precificar preconfs em estado contencioso? preconfs de preços antecipados vs. just-in-time 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 supor, no entanto, que haja demanda suficiente dos usuários por preconfs rápidos em estados contenciosos (considerando tanto pesquisadores sofisticados quanto usuários comuns), de modo que haja momentos em que um preço de compensação seja benéfico para todos. Agora, como exatamente você precifica um preconf para uma transação em um estado contencioso que você poderia incluir em qualquer momento nos próximos 12 segundos, potencialmente perdendo oportunidades mais lucrativas que não seriam mais 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 de 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.io agora precisa ser um pesquisador/construtor altamente sofisticado.

já assumimos que a Gate.ioway e a relay se fundiriam. se precisarem de continuar a precificar preconfs, 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á diretamente os direitos de proponentes a atores sofisticados (provavelmente construtores) capazes de precificá-los.

Isso coloca toda a cadeia de suprimentos de transações Ethereum L1 e BR em uma única caixa que tem um bloqueio de gravação de monopólio no estado de todas as cadeias para esse período.

as políticas de ordenação do serviço pré-configurado não estão claras (por exemplo, eles sempre são executados em ordem FCFS ou em outra maneira). Também é potencialmente possível para o Gate.io realizar um leilão para todas as pré-configurações (por exemplo, permitindo que os pesquisadores façam lances nas pré-configurações), embora não esteja claro como seria esse design e isso necessariamente significaria maior latência.

problema de troca justa

há um problema de troca justa com preconfs onde o Gate.ioway na verdade não é diretamente incentivado a liberar o preconfs.

considere o seguinte exemplo:

• o atual Gate.ioway tem um monopólio de 12s
• Um usuário envia uma solicitação de transação preconf logo no início do slot (t = 0)
• o Gate.ioway espera até t = 11.5 para liberar todas as pré-confs que eles fizeram durante seu slot, deixando um buffer de 500ms para colocá-los todos com seu bloco. Nesse momento, eles podem decidir quais preconfs incluir se forem lucrativos e quais excluir.

Nesse cenário, o usuário pode acabar pagando pelo pré-conf, mesmo que na verdade não o receba até o final do slot. A Gate.ioway também pode simplesmente deixá-lo cair no final do slot se decidir que não foi lucrativo incluí-lo. Essa retenção pela Gate.ioway não é uma falha objetivamente atribuível.mas pode ser atribuível intersubjetivamente.

na verdade, há realmente um incentivo para a Gate.io esperar até o final para liberar as confirmações prévias.Onde há assimetria de informação, há mev. Manter as transações privadas permitiria que um construtor tivesse uma visão mais atualizada do estado do mundo, permitindo-lhe precificar melhor o risco e capturar o MEV. não há consenso sobre o conjunto de preconfs que estão sendo dados aos usuários, então o Gate.ioway não pode ser responsabilizado aqui.

Seriam necessários padrões estabelecidos e expectativas para que o pré-confirmador fofocasse imediatamente 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 não conseguirem fazer isso no futuro, os usuários não confiariam neles e pagariam por pré-confs. a reputação do Gate.ioway tem valor. Dito isto, também pode ser extremamente valiososer desonesto aqui e voltar atrás contra preconfs.

l1 camada de base preconfs

Com os pontos gerais da preconf fora do caminho, discutiremos agora as nuances das preconfs L1. Embora não os tenhamos mencionado anteriormente, há projetos que os constroem, e sua interação com os BR Preconfs será importante.

por exemplo,ParafusoÉ um protocolo que deseja permitir que os proponentes do ethereum façam compromissos credíveis sobre o conteúdo de seus blocos. Os proponentes registrados podem executar o bolt sidecar para receber solicitações prévias dos usuários, confirmá-las e enviar essas informações para relays e builders que podem retornar blocos que respeitem essas restrições (ou seja, retornam um bloco que inclui as transações para as quais o proponente deu pré-confirmações).

é importante notar aqui queBolt v1descrito aqui suporta apenas a inclusão de transações simples preconfs para estados não controversos, onde apenas o usuário pode invalidar o preconf. como discutimos anteriormente, estes são os compromissos mais simples e fracos a fornecer.

todas essas equipes de preconf têm ambições maiores (por exemplo, preconfs estaduais, leilões de blocos parciais, leilões de slot ou slot parcial), então, o que está as impedindo?

• responsabilidade - violações de compromisso devem ser comprovadas onchain para redução objetiva. é relativamente fácil provar a inclusão da transação, mas não está claro como impor 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 elevado. A Gate.ioways provavelmente acabará precisando apostar quantias enormes (por exemplo, milhares de eth) para fornecer esses compromissos. Eles 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 questões em aberto sobre como precificar algo como pré-conferências de estado transmitidas continuamente, mesmo se decidirmos que é viável e valioso.
• participação na rede - este é talvez o ponto mais importante e fundamental. Como mencionamos, somente o proponente atual que possui um bloqueio de gravação no estado pode fornecer compromissos como preconfs de estado. Na teoria, 100% dos proponentes poderiam optar por este sistema e imitá-lo. Na prática, isso não acontecerá.

mev-boost, um produto mais simples com anos de histórico que é incrivelmente lucrativo para operar, tem>92% participaçãopara contexto (provavelmente até um pouco mais alto, pois isso não leva em contamin-lance). um novo serviço de pré-configuração certamente teria uma taxa de participação muito menor. Mas mesmo que pudesse chegar à faixa 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 'ah, desculpe, não há pré-configurações disponíveis agora, volte mais tarde.'

No melhor dos casos, isso parece que as preconfs estaduais seriam apenas uma ferramenta opcional para pesquisadores e negociadores sofisticados que desejam obter um compromisso mais cedo no bloco quando esse slot tiver um proponente optado. Isso pode ser valioso, mas não há fragmentação ou desbloqueios de UX aqui.

pré-confs baseadas em rollup l2

br preconfs devem vir dos proponentes bl (é por isso que eles são "baseados"). isso requer que eles apostem algum colateral e optem por condições adicionais de corte (ou seja, que os preconfs que eles fornecem de fato chegarão à cadeia conforme prometido). qualquer proponente disposto a fazê-lo pode atuar como um sequenciador br e fornecer preconfs.

É importante ressaltar que esses preconfs BR são preconfs estaduais e não apenas peconfs de inclusão. isso é possível porque os brs estão optando por um design onde eles dão um monopólio de sequenciador rotativo para proponentes bl que se inscrevem para ser Gate.ioways.

Hoje, um validador ethereum atua como o proponente para cada slot, e o cronograma do proponente é sempre conhecido para a época atual e a seguinte. Uma época é de 32 slots, então sempre conhecemos 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 no horizonte) poderes de monopólio para sequenciar transações para os brs optados neste sistema pré-configurado. Gate.io sempre deve assinar para avançar o estado das cadeias de br.

Observe que todo proponente (mesmo aqueles que não optaram por ser um Gate.ioway) tem o direito, mas não a obrigação, de incluir transações que receberam pré-confirmações pelos sequenciadores (isto é, 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 blob bl que tenha as transações br e divulgá-las).

origem: Sequenciamento Ethereum, justin drake

o fluxo da 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 imediatamente fornece 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 incluidor 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 includers não incluírem os preconfs, então o sequenciador que os deu pode simplesmente incluí-los onchain quando for a vez deles como o proponente do BL. Por exemplo, na imagem acima, digamos que o slot n includer decidiu não incluir os preconfs que o sequenciador do slot n+1 deu. Então o sequenciador do slot n+1 seria responsável por incluir todos os preconfs que ele deu durante o slot n e o slot n+1 quando ele envia seu bloco BL para n+1. Isso permite que o sequenciador distribua preconfs com confiança durante todo o período entre eles e quem quer que tenha sido o último sequenciador.

para simplificar as explicações acima, nós apenas assumimos que o proponente l1 cumpriria esse papel preconfer. como descrito anteriormente, no entanto, isso não é provável que seja o caso. será necessário 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 presumivelmente terceirizarão os preconfs para outra entidade de forma muito semelhante à maneira como terceirizam a produção completa de blocos l1 via mev-boost hoje.

Os proponentes podem deleGate.io ao Gate.ioways por meio de mecanismos onchain ou offchain, e isso pode ser feito até pouco antes de seu slot. Como observado anteriormente, é provável que, na prática, esse papel seja assumido pelos revezamentos. Também é possível que eles precisem se fundir com construtoras também.

fonte: Sequenciamento baseado, justin drake

como descrito anteriormente, apenas uma entidade pode ser delegada a ser a 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 as transações do usuário para lá.

ethereum rollups - quão baseados eles serão?

com antecedentes suficientes agora no lugar - ethereum rollups deve ser baseado? há realmente duas perguntas embutidas aqui:

1. vários rollups do Ethereum devem compartilhar um sequenciador?
2. se sim, deve ser um sequenciador baseado (ou seja, envolvendo os proponentes do ethereum bl e a infraestrutura mev circundante)?

primeiro, é importante notar que você pode compartilhar um sequenciador com outras cadeias de forma ad hoc. por exemplo, o proponente ethereum pode sequenciar um bloco para você se eles derem o lance mais alto, então algum outro consenso bft poderia sequenciar seu próximo bloco se eles derem o lance mais alto. no entanto, isso ainda requer que uma cadeia opte totalmente por este leilão compartilhado uniforme que pode ser executado sincronamente com essas outras cadeias, portanto ainda existem compensações em relação ao controle e flexibilidade (por exemplo, tempos de bloco compartilhados). é apenas a entidade sequenciadora vencedora que pode mudar.

Independentemente disso, vamos apenas supor que a condição 1 seja atendida. Acho que temos evidências convincentes neste momento de que existe demanda suficiente para usar um sequenciador compartilhado descentralizado. Mesmo que eles se importem menos com o "aspecto compartilhado", acho que há um valor incrivelmente alto em poder comprar um sequenciador descentralizado como serviço de prateleira (na verdade, acho que esse é o maior valor aqui).

agora, esse sequenciador compartilhado 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 o BRS e o Ethereum L1 seria incrivelmente limitada devido à incapacidade de executar de forma confiável contra o L1 (ou seja, não ter consistentemente um bloqueio de gravação no estado L1), longos tempos de bloqueio (12s) e o fato de que as transações BR que desejassem interagir com o L1 teriam que se reorganizar junto com ele. Não há almoço grátis aqui. Isso não desbloqueia nenhum produto valioso voltado 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 um valor agregado maior criado pela Gate.io epermitir 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 ingressos para o show da taylor swift. ainda não estou lá.

Isso é apenas para destacar que há uma complexidade técnica e social real na criação e adesão de todos a esse leilão compartilhado, que tem um custo real, que em minha opinião provavelmente supera qualquer valor adicional teórico criado aqui. É possível criar facilmente um design técnico muito melhor para executar isso a partir dos primeiros princípios, se não estivermos tentando colocá-lo em cima do ethereum l1 (por exemplo, apenas ter um mecanismo de consenso rápido e simples construído para esse fim). Sem mencionar o fato de que tal leilão combinatório criaria uma explosão exponencial na complexidade.

Na prática, existe um risco significativo para mim de que isso possa ser realmente contraproducente para o Ethereum, já que essa arquitetura pré-configurada 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 mesmas coisas que a tornam valiosa em primeiro lugar.

social (neutralidade confiável)

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

como observado anteriormente, não há dúvida de que a "alinhamento" é uma venda para o br inicial. tudo bem, mas acho que isso não dura. É legal ser o primeiro br, não é legal ser o oitavo. precisa haver algum outro valor agregado.

Eu acredito que a neutralidade credível de um sequenciador baseado em Ethereum é potencialmente esse valor. É provavelmente o argumento mais forte a favor de um design desse tipo, pelo menos. Existem muitas cadeias que desejam obter um sequenciador descentralizado pronto para uso. Se pudermos eventualmente projetar infraestrutura suficiente sobre essa coisa que melhore a experiência do usuário entre cadeias, melhor ainda. Dos projetos que desejam um design desse tipo, imagino que muitos deles hesitem em 'escolher um lado' com qualquer protocolo de terceiros. Como mencionado anteriormente, imagine que você é uma cadeia de aplicativos com uma infraestrutura geral básica, como ENS, e você quer um rollup. Você não quer escolher o sequenciador compartilhado (hipotético) do arbitrum e desligar o público otimista, ou vice-versa.

possivelmente a única solução para o problema de coordenação social aqui é ter um sequenciador compartilhado credível e neutro, para o qual o ethereum é claramente o candidato mais forte. note que isso coloca um grau ainda maior de ênfase nos pontos que mencionei anteriormente sobre neutralidade credível - se este é o principal valor agregado de tal serviço, então isso deve ser um objetivo de design de alta prioridade incrivelmente. não funcionará se tiver a aparência de ser o projeto pessoal de algum protocolo de terceiros com seus próprios motivos de lucro. tem que ser realmente o sequenciador compartilhado do ethereum.

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

rollups baseados em velocidade

camadas de base rápidas

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

como observado, e se nós apenas projetarmos essa coisa do zero. sem lidar com a dívida técnica e 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 dado bl (por exemplo, ethereum) é para que seu proponente possa fornecer compromissos credíveis em momentos a respeito da inclusão atômica síncrona com o bl.

no entanto, não discutimos seriamente a capacidade de ser um br sem preconfs. basicamente, jogamos isso pela janela 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 complexos de borda e preocupações que tínhamos antes. Não queremos casos estranhos de borda em que as Gate.ioways tenham falhas de liveness (que têm o mesmo resultado que as falhas de segurança aqui), não queremos que elas desistam dos preconfs prometidos (ou seja, falhas de segurança) e não queremos reorgs ethereum. É exatamente por isso que o consenso existe.

As camadas estão mortas, viva as camadas de sequenciamento!

A maior parte da conversa sobre sequenciadores preguiçosos os contempla como um sequenciador de rollup que então despeja seus dados em alguma outra camada DA. Por exemplo, os dois primeiros rollups da Astria (FormaeChama) usará celestia como sua camada da. O consenso da astria irá sequenciar esses rollups, então ele transmitirá seus dados para celestia.

essa combinação é especialmente boa porque são complementos óbvios - a Astria fornece toda a infraestrutura de sequenciamento e a Celestia fornece verificação com minimização de confiança através de amostragem de disponibilidade de dados (das).

no entanto, a astria poderia ser usada de forma semelhante para sequenciar um rollup nativo do ethereum, bitcoin, solana ou qualquer outra coisa que você queira. por exemplo, ela poderia até ser configurada para ser usada como um preconfer para o ethereum “brs com preconfs” (por exemplo, em vez de um Gate.ioway centralizado, como um sequenciador preguiçoso é basicamente apenas um relé incentivado e descentralizado).

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

no entanto, como eu observei em Os rollups herdam segurança?, cadeias rápidas como Astria podem tecnicamente adicionar um caminho lento para das (para melhorar a verificabilidade), e cadeias lentas como Celestia podem adicionar um caminho rápido para sequenciamento (com uma maioria de confiança assumida e sem das), chamado de "..."blocos rápidos quadrados lentos.”

mover-se para integrar verticalmente camadas especializadas como sequenciamento ou das estreitaria ainda mais a distinção entre blockchains modulares vs. integrados. isso se aplica de forma semelhante para a integração vertical do camada de liquidaçãoatravés da adiçãoContas verificadoras ZK para a camada base da Celestia.

No entanto, há um valor significativo em manter esses serviços separados em vez de agrupá-los. Esta é a abordagem modular que permite aos rollups escolher quais recursos eles desejam usar 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 querem DAS, mas os usuários até agora mostraram que apenas querem blocos rápidos.

agrupamento de serviços, como em "bundling"blocos rápidos quadrados lentos"seria muito opinativo e integrado. isso necessariamente adicionaria complexidade e custo. o efeito do comprimento do slot emjogos de timing (e, assim, a descentralização potencial) que agora são generalizadas no ethereum também é uma consideração.

camada base rápida vs. lenta + preconfs

mas você também pode usar astria como bl para rollups. Sequenciadores compartilhados podem ser considerados como bls otimizados para brs próprios.

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

brs sem pré-confs 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 primeiros princípios de "ei, os desenvolvedores de aplicativos só querem lançar uma cadeia rápida, confiável e descentralizada - como faço para dar isso a eles?" tentar adicionar preconfs depois do fato em uma camada base mais lenta como ethereum resulta nas complexidades que descrevemos acima.

todos estamos construindo a mesma coisa

a modularidade é inevitável

Então, vimos como podemos reunir cadeias modulares da Gate.io, fornecendo composabilidade síncrona universal (usc). Há, é claro, compensações, mas elas reintroduzem um grau significativo de unidade, preservando muito mais flexibilidade do que o uso de uma única máquina de estado. Também há um argumento 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 composabilidade ≠ sincronia.

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, então 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 versus o final de jogo da Ethereum se ela seguir por esse caminho de maximizar a unidade e a UX com rollups baseados em preconfs.

Nesta visão, temos um monte dessas brs usando o sequenciador baseado no 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 do ethereum os inserem em um bloco completo de tempos em tempos. Isso pode parecer familiar porque é praticamente o que descrevemos antes para solana com a transmissão de fragmentos!

então, isso é apenas uma solana mais complicada? A grande diferença aqui está nos tempos de slot:

ethereum tentando 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 experiência de usuário rápida e credível é com pré-configurações prometidas pelo proponente de forma opcional. 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 aprimorada poderia ajudar aqui).
• isso resulta em monopólios de proponentes muito mais longos, proporcionando incentivos e liberdade maiores para capturar mais mev agindo de forma desonesta (por exemplo, retendo pré-confs).
• se a Gate.ioways começar a atrasar ou reter pré-confirmações, então o pior caso para os usuários volta a depender dos tempos de slot do ethereum. mesmo que os produtores de blocos de solana parem de construir e transmitir blocos continuamente dentro de seus monopólios alocados ( como é provavelmente racional para eles fazerem em algum grau pela mesma razão exata), então, no pior dos casos, é necessário confiar em um consenso rapidamente rotativo.O monopólio de quatro slots hoje é necessário para a confiabilidade da rede.
• Na prática, é provável que haja muito poucas Gate.ioways, pelo menos no início, o que resultará em um conjunto de operadores mais centralizado em comparação com cadeias como Solana.
• potenciais requisitos de garantia incrivelmente altos para proponentes (observando que o espaço de design ainda está em progresso).
• preocupações sobre problemas de vivacidade serem extremamente caros aqui (pois problemas de vivacidade do operador que levam a pré-confirmações perdidas são falhas de segurança para os usuários e, portanto, devem ser puníveis com multas pesadas).

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 fazer seu consenso ir mais rápido? existem algumas compensações menos óbvias ao ter tempos de bloco de camada base super baixos?

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

já estamos vendo jogos de temporização progredindo no ethereum. os proponentes estão propondo blocos mais tarde em seus slots, ganhando mais dinheiro às custas dos outros. os relays também estão oferecendo “jogos de sincronização como serviço“ onde eles também atrasam os blocos mais tarde no slot:

origem: Dados sempre

Jogos de timing foram um grande tema de discussão no infame...Justin vs. podcast sem bancos do tolyde algumas semanas atrás:

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

se você tiver slots de 1s, você pode ganhar 10% a mais do que todo mundo

se você tiver 10 slots, você 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 cronometragem serão um problema, e as recompensas incrementais sempre serão relevantes. Toly argumentou principalmente que os jogos de cronometragem não serão um problema, e que as recompensas incrementais obtidas com a extração adicional de MEV não são suficientes para se preocupar.

Pessoalmente, acho difícil ignorar a importância dos jogos de cronometragem aqui:

• já os vemos na prática na ethereum hoje.O argumento da solanaé que isso acontece apenas porque o mev se tornou socialmente normalizado no ethereum anteriormente, mas isso não é convincente quando houveforte protesto público contra jogos de tempo antecipadoque desde então se transformou em aceitaçãodesta nova realidade a ser projetada ao redor.
• as recompensas de mev são significativas - já estamos falando sobrebilhõ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" sobre 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 administrando negóciose isso vai direto para seus resultados financeiros.
• É mais fácil para Solana contar com grandes detentores altruístas(por exemplo, a fundação e grandes investidores) mais cedo em seu ciclo de vida, masisso não é sustentável à medida que qualquer rede se descentraliza ainda mais.

Eu acredito claramente que há uma enorme quantidade de valor na direção que tanto a Solana quanto a Ethereum estão seguindo. Se nada mais, veremos tudo isso se desenrolar na 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 de alcançar a resistência à censura em circunstâncias adversas. A Ethereum fez muitos sacrifícios para manter um protocolo incrivelmente descentralizado porque isso é necessário para o jogo a longo prazo. Ela possui diversidade de clientes inigualável, distribuição de propriedade de rede, partes interessadas do ecossistema, descentralização de operadores e muito mais. Se (e provavelmente quando) a Solana enfrentar sérias pressões de censura no futuro, ficará cada vez mais evidente por que a Ethereum tomou as decisões que tomou.

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

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

as conversas prévias e de rollup baseado começaram a ganhar impulso muito recentemente, e definitivamente ainda estou mais cauteloso. Vitalik famosamente estabeleceu o seguinte Endgame:

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á meio na parte inferior desta imagem abaixo. (digo meio porque a censura na verdade não é preto no branco, e o ethereum só tem uma "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 governança

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

l2s já podem obter o cr eventual do l1 (que ainda é muito bom) sem serem baseados. As preconfirmações baseadas não possuem a segurança em tempo real do protocolo ethereum, elas possuem a segurança em tempo real de um pequeno grupo de provedores de infraestrutura relativamente centralizados ao seu redor. Para um 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 próximo.

Com tudo isso considerado, não está claro para mim que expandir a dependência da infraestrutura MEV do ethereum L1 e então enraizá-la para L2 seja uma ótima ideia neste estágio, quando há um punhado de pessoas que constroem e transmitem todos os blocos do ethereum. A maioria dos blocos sem censura do ethereum hoje depende de um único construtor (Titan), e nenhuma das ferramentas CR foi implementada no protocolo ainda. Isso parece agressivamente aceleracionista em um ponto frágil. O ethereum certamente deveria estar trabalhando para melhorar a experiência de usuário dos L2s, mas não às custas de todas as propriedades subjacentes que queríamos em primeiro lugar.

conclusão

estamos todos construindo a mesma coisa.

bem, mais ou menos. obviamente essas coisas não são todas literalmente a mesma coisa exata. Sempre haverá diferenças práticas entre esses sistemas. No entanto, a megatendência abrangente em criptografia é clara de que todos estamos convergindo para arquiteturas cada vez mais semelhantes.

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

Além disso, é praticamente impossível raciocinar sobre algumas dessas coisas.Como Vitalik colocou:

"Uma nota de cautela que tenho para a APS é que acho que, de uma perspectiva puramente técnica, na verdade acho que é muito leve e somos totalmente capazes de fazê-lo com poucas chances de erro técnico... Mas, do ponto de vista econômico, há muito mais oportunidade para as coisas darem errado...

Como EIP-1559 fomos capazes de descobrir com teoria. Fomos a algumas conferências de economia adoráveis e aprendemos sobre os perigos dos leilões de primeiro preço e como eles são uma, e descobrimos que os leilões de segundo preço não são críveis, e então descobrimos que vamos usar um mecanismo que é o preço fixo localizado dentro de cada bloco, e fomos capazes de fazer muito com microeconomia.

mas aps não é assim, certo? E a questão de se aps vai levar a 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 então a coisa que eu quero ver neste ponto é a experimentação ao vivo... para mim pessoalmente, a diferença entre hoje e eu me sentir realmente confortável com aps é basicamente aps funcionando com sucesso em um ethereum l2 que tem uma quantidade média de valor, atividade, comunidade e real contenda acontecendo e isso durando por um ano, possivelmente mais por um ano, e nós realmente sendo capazes de ver algumas consequências ao vivo.

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

disclaimer:

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, entre em contato com o Gate.io aprenderequipe, e eles vão lidar com isso prontamente.
2. responsabilidade de isenção: 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 do Gate.io Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.