Resumo Técnico: Os Perigos do Paralelismo: Mecanismos de Taxa de Transação sob Incerteza de Execução

1. Definição do Problema

As blockchains modernas estão transitando da execução serial para a paralela para superar gargalos de throughput causados pela execução, e não pelo consenso. Embora a execução paralela (usada ou planejada por redes como Sui, Solana, Monad e Ethereum) aumente a capacidade, ela introduz dois desafios econômicos críticos quando as transações envolvem incerteza de execução (contingência) e contenção de recursos:

1. Contingência de Execução e Alocação de Risco: Em linguagens de contratos inteligentes expressivas (Turing-completas), o uso de recursos de uma transação (objetos acessados) muitas vezes depende do estado da blockchain em tempo de execução, o que não pode ser conhecido antes da execução. Isso cria uma tensão entre o Risco do Usuário (usuários pagando excessivamente por objetos declarados que não são utilizados) e o Risco do Programador/Scheduler (programadores perdendo receita quando a capacidade reservada não é paga devido à subexecução).
2. Ataques de Shill na Computação de Gas: Os mecanismos de computação de gas (GCMs) existentes projetados para ambientes paralelos (ex: valor de Shapley ou Makespan Proporcional ao Tempo) são vulneráveis à manipulação racional. Tanto usuários quanto programadores podem injetar transações "shill" (falsas) para alterar estrategicamente o gas ou as taxas calculadas. Usuários podem reduzir suas taxas adicionando transações paralelas inúteis, enquanto programadores podem inflar taxas adicionando contenção falsa.

O artigo argumenta que os designs atuais falham em considerar simultaneamente o paralelismo, a incerteza de execução e a robustez econômica, levando a ineficiências e vulnerabilidades exploráveis.

2. Metodologia e Modelo

Os autores formalizam um framework para analisar Mecanismos de Taxa de Transação (TFMs) sob execução paralela com incerteza.

• Modelo de Transação: Uma transação $tx$ é definida por unidades de computação $t$, uma taxa de prioridade $g$, e conjuntos de leitura/escrita declarados $(R, W)$. Crucialmente, os objetos realmente acessados ($X_R, X_W$) podem ser um subconjunto dos conjuntos declarados, dependendo do caminho de execução (contingência).
• Definições de Taxa: O artigo distingue entre:
  • Taxa Atingível ($f_{att}$): A taxa se todos os objetos declarados forem usados.
  • Taxa Base ($f_{base}$): A taxa apenas para objetos determinísticos.
  • Taxa Ideal do Usuário ($f_{ui}$): A taxa para exatamente os objetos realmente usados.
  • Taxa Real Paga ($f_{act}$): A taxa cobrada.
• Métricas de Risco:
  • **Risco do Usuário ($UR$):**$f_{act} - f_{ui}$ (pagamento excessivo).
  • **Risco do Programador/Scheduler ($SR$):**$f_{att} - f_{act}$ (receita não realizada).
• Modelo Adversário: Usuários e programadores são modelados como agentes racionais, economicamente motivados, que podem inserir transações shill para minimizar seus custos ou maximizar a receita, respectivamente.
• Análise de Complexidade: O artigo utiliza a teoria da complexidade (especificamente P-completude) para analisar a dificuldade de prever o uso de objetos sem a execução.

3. Contribuições Principais e Resultados

A. Impossibilidade de Eliminação Simultânea de Risco

O artigo prova um resultado fundamental de impossibilidade: Nenhum mecanismo pode eliminar simultaneamente o Risco do Usuário e o Risco do Programador sem pré-executar as transações ou colapsar para taxas constantes.

• Teorema 1: Se um programador for limitado por um limite de computação $G$ (não pode realizar mais trabalho do que o bloco permite), é impossível definir pagamentos de modo que $UR=0$e$SR=0$ para todas as entradas envolvendo transações contingentes conflitantes.
• Teorema 2 (P-completude): Decidir se um objeto específico é usado por uma transação contingente (o Problema de Decisão de Uso de Objeto) é P-completo. Isso implica que verificar o uso de um objeto requer trabalho sequencial proporcional ao tempo de execução, tornando computacionalmente inviável para um programador prever o uso "barato" antes da execução.
• Trade-off: Existe um trade-off linear inerente. Reduzir o risco do usuário (cobrar apenas pelos objetos usados) aumenta o risco do programador (perda de receita), e vice-versa.

B. Caracterização de Mecanismos de Divisão de Risco

Dada a impossibilidade, os autores caracterizam o espaço de design através de três mecanismos canônicos de divisão de risco, parametrizados por $\alpha \in [0,1]$:

1. Amigável ao Usuário ($\alpha=0$): Usuários pagam apenas pela execução realizada ($f_{act} = f_{ui}$). O programador assume todo o risco.
2. Amigável ao Programador ($\alpha=1$): Usuários pagam por todos os objetos declarados ($f_{act} = f_{att}$). O usuário assume todo o risco.
3. Equilibrado/Even-Steven ($\alpha=0.5$): O risco é dividido igualmente.
   O artigo analisa estes sob diferentes modelos de utilidade do programador (Otimista, Pessimista, Mediana) para mapear as implicações de receita.

C. Ataques de Shill e Resistência a Taxas (Fee-Based Shill-Proofness)

O artigo identifica que as propriedades padrão de GCM (como Inclusão de Conjunto) são insuficientes para prevenir ataques de shill na presença de contingência.

• Ataques de Shill de Usuários: Usuários injetam transações falsas para reduzir o gas/taxa efetiva de sua transação real.
• Ataques de Shill de Programadores: Programadores injetam transações falsas para aumentar o gas/taxa cobrado de usuários honestos.
• Resistência a Shill Baseada em Taxas: Os autores propõem novas definições de resistência a shill baseadas em taxas em vez de apenas gas, contabilizando taxas de prioridade e contingência de execução. Eles provam que, para mecanismos amigáveis ao usuário, a resistência a shill só é alcançável se a taxa for independente do cronograma/schedule (Teorema 3).

D. O Mecanismo de Taxa de Transação Ponderada por Objeto (OW-TFM)

Para resolver essas questões, os autores propõem o Mecanismo de Taxa de Transação Ponderada por Objeto (OW-TFM).

• Mecanismo: As taxas são calculadas com base no preço dos objetos declarados pela transação, onde os preços dos objetos são atualizados com base na utilização histórica (semelhante ao EIP-1559).
• Parametrização de Risco: O mecanismo utiliza um parâmetro $\alpha$ para determinar quanto um usuário paga pelos objetos declarados mas não utilizados ($\alpha \cdot \text{preço}$).
• Resistência a Shill: O OW-TFM mostra-se resistente a shill sob condições específicas. Como os preços são derivados da utilização de blocos passados, uma transação shill no bloco atual não pode reduzir o preço de um objeto para o bloco atual (ela só pode elevar os preços futuros).
• Condições: O Lema 4 estabelece um limite para $\alpha$ necessário para evitar ataques de shill de programadores, dependente da razão de prioridade-para-taxa base ($\pi_o$), responsividade de preço ($\eta$) e razão de retenção ($\gamma$).

4. Significância e Alegações

O artigo afirma fornecer as bases rigorosas para avaliar e projetar mecanismos de taxas para blockchains paralelas. Sua significância reside em:

1. Identificar Limites Fundamentais: Demonstra que a tensão entre a justiça ao usuário e a receita do programador na execução paralela não é uma falha de design, mas uma consequência fundamental da incerteza de execução e da complexidade computacional.
2. Expor Vulnerabilidades: Revela que as propostas existentes para computação de gas paralelo (ex: abordagens baseadas em Shapley) são vulneráveis a ataques racionais de shill, uma ameaça anteriormente não abordada na literatura.
3. Fornecer um Framework de Design: Oferece um espaço de design principista (o espectro $\alpha$) e um mecanismo concreto (OW-TFM) que permite aos designers de sistemas escolher explicitamente sua estratégia de alocação de risco enquanto mantêm a resistência à manipulação.
4. Relevância para a Indústria: Os resultados aplicam-se diretamente e criticam os designs de redes paralelas proeminentes (Sui, Monad, Solana) e o roadmap de execução paralela do Ethereum via listas de acesso.

Os autores mantêm um tom modesto, observando que seu trabalho identifica limitações fundamentais e trade-offs em vez de prescrever uma única solução "perfeita", reconhecendo que a implementação prática requer considerações adicionais de modelos de execução probabilística e detalhes específicos de implementação.