Nova proposta de Opcode 2: Região de salto estruturado `L / R` – EVM

Resumo

Isso introduz dois novos opcodes EVM, L (Delimitador esquerdo) e R (Delimitador direito)que define regiões de salto estruturadas em bytecode.

Quando executado, L faz com que o EVM avance para sua correspondência R sem executar os bytes incluídos. Essas regiões permitem que os contratos incorporem dados estruturados não executáveis ​​diretamente dentro do bytecode preservando a execução determinística.

Motivação

O bytecode EVM atualmente não possui uma forma nativa de distinguir:

• Instruções executáveis
• Metadados incorporados
• Tabelas do compilador
• Constantes estruturadas
• Caminhos de código alternativos destinados apenas a ferramentas fora da cadeia

Todos os bytes são tratados como instruções potencialmente executáveis, e a única maneira de pular o código é através de saltos dinâmicos.

Isso leva a problemas:

• Os compiladores não podem incorporar dados estruturados com segurança no bytecode
• Ferramentas estáticas devem tratar conservadoramente todos os bytes como executáveis
• O bytecode não pode carregar uma estrutura interna rica sem correr o risco de execução acidental
• O fluxo de controle deve ser expresso usando saltos não estruturados

Nós propomos regiões de salto estruturadas que se comportam como ilhas não executadas dentro do bytecode.

Essas regiões permitem que o bytecode contenha com segurança:

• Tabelas de pesquisa
• Saltar tabelas
• Digite metadados
• Descritores internos semelhantes a ABI
• Dicas do compilador
• Cargas de extensão futuras

sem afetar a execução.

Especificação

Novos códigos de operação

Semântica

1. L – Avançar para a correspondência R

Quando o EVM executa opcode L:

• Ele entra modo de pular
• Ele avança no bytecode para encontrar o correspondente R
• Todos os bytes intermediários são ignorado e nunca executado
• Aninhado L/R os pares devem ser equilibrados

Algoritmo de correspondência

depth = 1
pc = pc + 1

while depth > 0:
    opcode = code(pc)

    if opcode == L:
        depth += 1
    else if opcode == R:
        depth -= 1

    pc += 1

2. R — Delimitador Estrutural

A execução é retomada no primeiro opcode depois a correspondência R.

Se não houver correspondência R é encontrado → parada excepcional.

Regras Estruturais

1. As regiões não são executáveis

Bytes dentro de um L … R região:

• Nunca deve ser executado
• São tratados como carga útil opaca
• Pode conter valores de bytes arbitrários, incluindo opcodes inválidos

2. Não é proibido entrar ou sair de regiões

É válido para:

• JUMP ou JUMPI para um local dentro de uma região de salto
• Salte de dentro de uma região para fora

3. O aninhamento é permitido

As regiões ignoradas podem ser aninhadas:

L
   
   L
      
   R
R

O algoritmo de correspondência garante o emparelhamento correto.

Custos do gás

Os clientes PODEM pré-processar bytecode para mapear pares correspondentes, permitindo L para executar em tempo constante.

Justificativa

Bytecode como um contêiner estruturado

Esta proposta permite que os contratos tratem o bytecode não apenas como instruções, mas como um formato de contêiner.

Com L/Ro bytecode pode incluir com segurança:

Tudo sem correr o risco de execução acidental.

Por que não apenas usar JUMP?

Usando JUMP para pular os dados:

• Requer fluxo de controle dinâmico
• Deixa os bytes ignorados sintaticamente executável
• Torna a análise estática ambígua
• Não é possível conter com segurança padrões de bytes arbitrários

L/R em vez disso, crie regiões não executáveis ​​explícitassemelhante às seções de dados em binários tradicionais.

Por que não reutilizar JUMPDEST?

JUMPDEST marca alvos de salto válidos, mas não marca regiões não executáveis.
Precisamos do oposto: uma forma de declarar “isto não é código.”

Compatibilidade com versões anteriores

Totalmente compatível com versões anteriores:

• Os contratos existentes não contêm L ou R
• Comportamento de bytecode antigo inalterado
• A nova semântica se aplica apenas quando os opcodes estão presentes

Exemplo: incorporando uma tabela de dados

PUSH1 0x00
SSTORE

L
   0x12 0x34 0x56 0x78
   0x9a 0xbc 0xde 0xf0
R

PUSH1 0x01
SSTORE

Os bytes dentro L … R nunca são executados e podem ser lidos por ferramentas fora da cadeia ou copiando código via EXTCODECOPY.

Conclusão

L e R introduzir regiões estruturadas não executáveis ao EVM, permitindo que o bytecode funcione como um híbrido de código e dados estruturados.

Esse:

• Melhora a analisabilidade
• Permite metadados gerados pelo compilador mais seguros
• Permite estruturas de dados densas em bytecode
• Preserva total compatibilidade com versões anteriores
• Requer alterações mínimas no modelo de execução

Uma pequena adição de opcode transforma o bytecode EVM em um artefato autodescritivo e estruturadonão apenas um fluxo de instruções simples.