Combinação de pré-confirmações com rollups baseados para composição síncrona

Atualmente, existem dois tipos principais de rollups:

• Rollups baseadosonde a ordem das transações no rollup é determinada por um L1: um bloco de rollup é uma transação L1, e a ordem dos blocos é a mesma ordem em que essas transações aparecem em L1.
• Rollups sequenciadosonde a ordem das transações é determinada por um mecanismo offchain, por exemplo. um sequenciador centralizado ou consenso BFT. O hibestory rollup é regularmente empenhado para L1, mas encomendar as decisões são claramente tomadas pelo mecanismo offchain.

Rollups sequenciados têm a principal vantagem de poder oferecer latência muito menor do que o Ethereum L1. Os rollups baseados têm a principal vantagem que podem oferecer composição síncrona com o Ethereum L1. Uma transação poderá realizar ações que utilizem liquidez L1 e L2, contendo diretamente um bloco L2 inteiro e executando ações antes e depois dele, incluindo pós-afirmações que revertem tudo (incluindo o bloco L2), se falharem.

Este post vai demonstrar que é possível combinar os dois, com alguns limites.

O projeto

Existem três tipos de blocos L2:

• Blocos sequenciados regulares: requerem um certificado de sequenciador (por exemplo, assinatura do servidor central, votos do comitê 2/3…) para serem válidos e vêm com frequência
• Blocos sequenciados de finalização de slot: requerem um certificado de sequenciador e vêm com uma mensagem especial de que é válido construir um bloco baseado em cima deles e incluí-lo no L1, apenas durante o slot atual (e também se o bloco pai L1 corresponder)
• Blocos baseados: qualquer um pode construí-los e incluí-los, mas apenas no topo de um bloco sequencial de final de slot (ou, potencialmente, no topo de outro bloco baseado)

A função do sequenciador L2 é jogar um jogo de cronometragem. Normalmente, eles liberam blocos rollup sequenciados com latência muito baixa. Então, perto do final do slot, eles liberam um bloco sequenciado de final de slot – cedo o suficiente para que um construtor possa criar um bloco baseado e incluí-lo, mas tarde o suficiente para que o período sem latência muito baixa seja minimizado. Finalmente, eles começam a fazer blocos sequenciais para o próximo slot assim que tiverem certeza de que o bloco L1 foi confirmado.

Se, em um determinado slot, um bloco baseado não for incluído (ou porque ninguém aparece para construir a tempo, ou porque o proponente está ausente ou com defeito), então o sequenciador inicia o próximo slot construindo diretamente sobre o bloco de final de slot do slot anterior.

Propriedades

• Este design só é compatível com L2s que estão dispostos a reverter se o L1 for revertido. Isso ocorre porque se um bloco baseado for revertido, quaisquer blocos sequenciados construídos sobre ele também serão revertidos. Aguardando até que o bloco L1 contenha o bloco baseado finaliza será um atraso excessivamente longo, mesmo sob mecanismos de finalidade L1 teoricamente ideais.
• Em circunstâncias normais, o atraso em torno do tempo de publicação do bloco L1 deve ser bastante curto. O L2 publica seu bloco de finalização de slot, imediatamente os construtores constroem blocos baseados nele, logo o proponente faz seu bloco L1 incluindo-os, e então os atestadores fazem atestados imediatamente após o proponente propor, abrindo caminho para novos blocos sequenciados entrarem.
• Observe que não há risco de segurança em publicar um bloco de finalização de slot tarde demais: o pior que acontece é simplesmente que ninguém constrói sobre ele. No entanto, há um risco de segurança ao publicar o primeiro bloco sequenciado do próximo slot muito cedo, porque se o sequenciador construir sobre um bloco que foi reorganizado, seu bloco também será reorganizado.
• O maior atraso ocorre no caso de um proponente ausente, porque os atestadores esperarão para garantir que nenhum proponente esteja presente e só então publicarão os atestados
• Este desenho faz não obtenha os benefícios de não permissão dos rollups baseados, porque a construção de um bloco baseado requer o certificado do sequenciador de um bloco sequenciado de final de slot. Para conseguir a ausência de permissão, o caminho mais fácil é introduzir um canal de inclusão forçada em L1. Os construtores de blocos baseados podem ser responsáveis ​​por incluir todas as transações na caixa de entrada de inclusão forçada.

Adorei essa nova versão! De certa forma, parece oposto à abordagem do SCOPE. Lá, um rollup sequenciado pode ser composto de forma síncrona com o L1 se encontrar alguém disposto a vender-lhe o espaço de bloco L1 (sem que o rollup seja “baseado”). IIUC aqui, um rollup sequenciado pode ser composto de forma síncrona com o L1 se encontrar alguém que possa fornecer as transações que podem ser compostas. Em ambos os casos, você não precisa ser um rollup “baseado”, apenas precisa de alguma coordenação com a cadeia de suprimentos da construção do bloco L1.

Supondo que estamos falando de rollups com provas de validade, algumas questões/desvantagens em relação ao tempo:

1. Os construtores não podem oferecer “pré-confs baseados” de forma confiável até que tenham visto o bloco de finalização de slot, pois as transações L2 anteriores mudarão o estado delas. Isso torna tudo complicado em um UX POV, pois a janela de composição é muito curta, então talvez apenas os construtores possam tirar vantagem disso?
2. Para atomicidade, precisamos provar o L2 em tempo real e, em seguida, postar os lotes + prova de validade + chamadas que podem ser compostas de sincronização L1, tudo na mesma transação L1. Uma preocupação é que a prova em tempo real já seja uma façanha. Se você precisar esperar para iniciar esse processo até perto do final do slot, poderá ter que compensar outras dimensões, como diminuir os limites de gás?

O design aqui é definitivamente uma filosofia oposta ao SCOPE, no sentido de que assume que os construtores L1 são “burros” e não oferecem pré-confs, enquanto o L2 oferece pré-confs. Portanto, é a abordagem que você deseja adotar se L1 for executado em ePBS, que é (pelo menos em sua versão mais simples) incompatível com pré-confs.

Uma preocupação é que a prova em tempo real já seja uma façanha. Se você precisar esperar para iniciar esse processo até perto do final do slot, poderá ter que compensar outras dimensões, como diminuir os limites de gás?

Concordo que isso é definitivamente uma fraqueza. Você precisaria de um provador de streaming para fazer essa tecnologia funcionar bem, caso contrário, seu “tempo morto” antes da proposta L1 se tornaria mais longo.

Esse design não obtém os benefícios de ausência de permissão dos rollups baseados, porque a construção de um bloco baseado requer o certificado do sequenciador de um bloco sequenciado de final de slot.

Você pode elaborar isso? Eu entendi que, embora não seja permitido ser um editor de blocos baseado, o sequenciador pode decidir nunca postar blocos de final de slot em primeiro lugar → sem capacidade de composição de sincronização.

Se esse for o problema, em vez de definir explicitamente o slot de finalização do slot por meio de um certificado especial do sequenciador, ele pode ser definido implicitamente pelas regras do rollup e verificado como uma condição de validade?

Como para cada slot L1 So N‘º bloco L2 (certificado e) sequenciado com l1_slot = S é definitivamente o bloco de finalização de slot. O sequenciador ainda pode impedir a janela de composição síncrona publicando < N blocos, mas ao custo de rendimento/reputação/UX/etc degradados.

Como para cada slot L1 So N‘º bloco L2 (certificado e) sequenciado com l1_slot = S é definitivamente o bloco de finalização de slot. O sequenciador ainda pode impedir a janela de composição síncrona publicando < N blocos, mas ao custo de rendimento/reputação/UX/etc degradados.

Sim, acho que fazer isso é razoável. Você não pode impedir que o sequenciador pare (acho que você pode ter um mecanismo onchain que, se nenhum novo bloco aparecer em L1 para> 10 slots, ele entrará automaticamente no modo baseado e quaisquer pré-confs L2 desde o bloco baseado anterior serão invalidados, ou seja, consequências equivalentes a uma reorganização curta), mas você pode tornar pouco atraente para eles fazerem isso.

Isso já vem sendo dito há alguns anos e concordo com a teoria. Mas algum rollup existente oferece isso? E se não, por que isso acontece?

Por favor, corrija-me se eu não for o suficiente no mato. Taiko não está pelo menos muito próximo disso?
Eles adotaram a abordagem ULTRA TX para oferecer isso.
Eles conseguiram esta ponte. (Código fonte aqui) O que não é a solução ideal. Principalmente com essas taxas.
As pré-confirmações baseadas estão ao vivo no taiko main.
A Nethermind criou o Surge com base nisso para uma abordagem mais genérica.
E em breve o ENS executará sua rede de teste nele e poderemos experimentá-lo com mais prática em L2s.

Parece que existem algumas ideias circulando por aí, mas ainda não foram testadas na prática.
Especialmente não a parte L1 disso? Mas o que eu sei realmente? Apenas um observador, na maioria das vezes.

Parece-me que está bem perto de estar pronto. Estou realmente ansioso por isso.