Composição síncrona entre rollups por meio de prova em tempo real – Página 2 – Camada 2

Aposto que muitos ex-mineiros e hobbistas administrariam alegremente plataformas dedicadas a isso (inclusive eu)

excelente post, muito claro!

pode se beneficiar das pré-confirmações L1 assim que estiverem disponíveis

no mês anterior a esta postagem, Ethereum teve seu ATH de pré-conf com 37% dos blocos contendo pelo menos 1 pré-conf em 19 de janeiro. Portanto, considerando que os pré-confs estão disponíveis, esperamos poder torná-lo um primitivo poderoso para a Zona Econômica e a Composibilidade Síncrona em geral.

Nós da Primev solicitamos a adesão antecipada para trabalharmos mais próximos desta iniciativa!

Eu tenho algumas perguntas. Desculpe por qualquer mal-entendido.

1. Essas transições de estado

stateRoot₀ → stateRoot₁

são diferentes das transições de estado induzidas pela Função de Transição de Estado Ethereum (STF) padrão, e os estados intermediários à la stateRoot₁não são raízes de estado L2 adequadas. Por um lado, seria necessário registrar coisas não diretamente relacionadas ao estado do L2, como o estado acumulado (endereço e calores de armazenamento…), estado da máquina (gás, pc, tamanho em palavras de memória…), pilha de chamadas e as pilhas de todos os quadros pai no ponto em que a chamada para C ocorre, bem como um instantâneo do estado “adequado”, certo?

2. É verdade que as provas de transição de “estado” para as várias L2 teriam vida muito curta? No sentido de que são válidos apenas para uma determinada “altura do próximo bloco L2”?

3. Se diferentes operadores criassem tais transações, imagino que seriam incompatíveis para inclusão em um determinado bloco? Como os operadores cooperam para produzir essas transações L2 ←→ L1 de forma coerente? Ou seja, de forma ordenada no tempo e com os estados iniciais corretos?

Embora o roteiro técnico para a prova em tempo real seja uma façanha de engenharia, devemos abordar o dilema estrutural isso cria especificamente para o modelo Baseado:

1. O Sindicato SBP (Searcher-Builder-Proposer):

Os rollups baseados são projetados para herdar a descentralização de L1, mas a capacidade de composição síncrona em um cluster baseado (por exemplo, EEZ) transfere a carga da consciência multiestado e da geração de ZK em tempo real para Construtores L1.

• O risco: Estamos inadvertidamente criando um cartel de consenso de alto desempenho. Se apenas alguns construtores de elite conseguirem lidar com a corrida de 12 segundos para simular a execução de vários rollup e gerar provas de validade, não baseamos o rollup, o L1 é apenas capturado pelo construtor. Isto cria um desequilíbrio na camada social onde os construtores não eleitos se tornam os governadores de facto do estado L2.

2. O Parasita da Segurança de Capital:
Se os clusters baseados (EEZ) criarem um “Prémio Síncrono” que mantenha o capital e a actividade de alta velocidade permanentemente na camada secundária, enfrentaremos uma dissociação económica.

• A erosão: Os rollups baseados herdam a segurança L1, mas potencialmente desviam o MEV e as taxas de transação que financiam o orçamento de segurança L1. Se L1 for reduzido a um canal DA de baixa receita enquanto o “Sindicato Síncrono” captura o prêmio, o hospedeiro (L1) pode eventualmente tornar-se fraco demais para proteger seus próprios parasitas.

3. A falha do equilíbrio de Nash: Não devemos depender do alinhamento social ou do tempo dos funcionários para gerir estes riscos. Se um sistema baseado requer um sindicato para manter sua vibração, ele falhou Teste de fuga. Precisamos de uma L1 que seja agressivamente neutra, onde o próprio protocolo imponha um equilíbrio de poder entre a segurança L1 e a eficiência L2, em vez de deixar uma camada de coordenação ditar os termos.

Estamos construindo um Tecnologia Santuárionão um condomínio fechado digital administrado por uma nova classe de construtores profissionais.

Este é um grande conjunto de questões – e a preocupação de acompanhamento sobre a centralização do construtor é especialmente importante neste modelo.

Lendo os dois tópicos juntos, há realmente duas camadas de questões emergentes:

1. Restrições técnicas

   • provas efêmeras e limitadas por slot
   • representações de “estado” intermediário não canônico
   • requisitos de coordenação entre operadores

2. Riscos estruturais

   • concentração de poder em construtores de alto desempenho
   • dependência de infraestrutura de prova em tempo real
   • acoplamento entre execução, prova e inclusão

Um fio condutor

Ambos os conjuntos de preocupações parecem convergir para uma questão mais profunda:

qual é a referência canônica e verificável de forma independente para o que realmente aconteceu?

Neste momento, esse papel é efetivamente desempenhado por:

• a prova de validade
• a mesa de execução
• e o contexto de sequenciamento

Mas todos os três são:

• fortemente acoplado
• sensível ao tempo
• e dependente de infraestrutura especializada

Uma possível separação

Uma maneira de reduzir esse acoplamento é separar:

• prova de correção (zk/camada de execução)
  de
• compromisso com o estado resultante (camada de referência)

A tabela de execução já representa:

um registro completo e ordenado de transições de estado entre domínios

Em vez de existir apenas dentro do pipeline de provas, também poderia ser tratado como um artefato de compromisso:

• hash da tabela de execução (ou sua raiz)
• âncora que digere on-chain no slot relevante
• torná-lo referenciável de forma independente

Por que isso é importante para as preocupações levantadas

Para as questões técnicas

• Provas efêmeras
  → combinado com compromissos persistentes e ancorados em slots

• Estado intermediário não padrão
  → compromisso não exige compatibilidade canônica do STF
  → apenas um resumo estável das transições observadas

• Coordenação do operador
  → coordenação produz um único artefato confirmado
  → não apenas uma prova vinculada a um construtor específico

Para os riscos estruturais (centralização do construtor)

Se:

• apenas um pequeno conjunto de construtores pode produzir provas válidas a tempo

então:

eles controlam efetivamente o que se torna “verdade” no sistema

Uma camada de compromisso introduz uma mudança sutil, mas importante:

• os construtores ainda podem competir para produzir provas
• mas o o estado resultante torna-se um artefato publicamente ancorado
• independentemente referenciável e verificável

Isso reduz a dependência de:

e fortalece:

• o que foi realmente cometido

Enquadramento

Isso não substitui a prova em tempo real ou o sequenciamento compartilhado.

Ele introduz uma camada complementar:

compromisso com o estado observado como um primitivo de primeira classe

Tenho explorado isso mais formalmente aqui:

Protocolo de Compromisso de Observação (OCP) v1.0.0 – #3 por DamonZwicker

Em alto nível:

• execução → produz estado
• prova → estabelece correção
• compromisso → ancora o resultado

Pergunta aberta

Se as tabelas de execução já representarem a transição completa de estado entre domínios:

eles também deveriam ser tratados como objetos de compromisso canôniconão apenas entradas para um sistema de prova?

Parece que esta separação poderia ajudar a reduzir ambos:

• fragilidade técnica (dependência de slots, complexidade de repetição)
• risco estrutural (concentração do construtor como guardião da verdade)

Curioso como outras pessoas que pensam em provas em tempo real veem essa distinção.

Um band-aid na ferida aberta chamado Proof of Stake. Ou em outras palavras: quanto mais rico fica mais poderoso e mais rico.