Autor: Anatoly Yakovenko
Compilado por: Deep Wave TechFlow
Visão geral
MEV é um problema fundamental em blockchains sem permissão. Como a maioria dos blockchains sem permissão, o objetivo de Solana é minimizar o MEV que os operadores da cadeia extraem dos usuários.
A abordagem de Solana é reduzir o MEV maximizando a concorrência entre os líderes (ou seja, os produtores de blocos). Isso significa encurtar o tempo dos slots, reduzir o número de slots que um único líder pode agendar consecutivamente e aumentar o número de líderes simultâneos por slot.
De modo geral, mais líderes por segundo significa que o usuário tem mais opções para escolher a melhor oferta dos novos líderes após esperar T segundos. Mais líderes também significam que custa menos para bons líderes fornecer espaço de bloqueio, tornando mais fácil para os usuários transacionarem apenas com bons líderes e excluirem transações de maus líderes. O mercado deve decidir o que é bom e o que é ruim.
A visão mais ampla de Solana é construir um mecanismo global de descoberta de preços sem permissão, capaz de competir com o melhor desempenho de qualquer bolsa centralizada (CEX).
Se ocorrer um evento com impacto no mercado em Singapura, a mensagem ainda terá de ser transmitida através de fibra óptica à velocidade da luz para o CEX em Nova Iorque. Antes que a mensagem chegue a Nova York, o líder da rede Solana deveria ter transmitido a mensagem no bloco. A menos que ocorra uma partição física da Internet ao mesmo tempo, o estado de Solana já refletirá a mensagem quando chegar a Nova Iorque. Portanto, não deveria haver oportunidade de arbitragem entre CEX e Solana em Nova York.
Para atingir plenamente este objectivo, Solana necessita de muitos líderes simultâneos com garantias de confirmação altamente optimistas.
Configurar vários líderes
Assim como a programação do líder atual, o sistema configura cada slot com 2 líderes em vez de 1 líder. Para diferenciar entre os dois líderes, um canal é rotulado como A e um canal é rotulado como B. A e B podem girar independentemente. As perguntas que precisam ser respondidas para implementar este plano são:
E se os blocos A e B chegarem em horários diferentes ou falharem?
Como mesclar a ordem das transações nos blocos A e B?
Como alocar capacidade de bloco entre A e B?
Transferir blocos simultâneos
Para entender o processo, precisamos dar uma olhada rápida no Turbine.
O líder divide o bloco em fragmentos à medida que o constrói. Um lote de 32 fragmentos é um código de eliminação de 32 fragmentos de código. Os lotes de 64 fragmentos foram assinados com mercúrio e assinados com raiz, e estes estavam vinculados ao lote anterior.
Cada fragmento é enviado por meio de um caminho aleatório determinístico independente. O retransmissor de cada último lote assina a raiz.
Do ponto de vista do receptor, cada receptor precisa receber 32 fragmentos do retransmissor autenticado. Quaisquer peças faltantes são reparadas aleatoriamente.
Esse número pode ser aumentado ou diminuído com pouco impacto na latência.
Supondo que a amostragem do caminho de fragmentação do retransmissor seja suficientemente aleatória e ponderada por compartilhamentos, os compartilhamentos necessários para uma rede particionada cooperativamente serão muito maiores do que ε compartilhamentos, tanto em termos de tempo de chegada quanto de dados. Se o receptor detectar que cada lote de 32/64 fragmentos (configuráveis) chega dentro do tempo T, provavelmente todos os nós também chegarão. Isso ocorre porque 32 nós aleatórios são grandes o suficiente e é improvável que estejam todos aleatoriamente na mesma partição.
Se ocorrer uma partição, é necessário consenso para resolvê-la. Isto não afeta a segurança, mas é relativamente lento.
Produção multibloco
Se um único bloco for transmitido, cada receptor (incluindo o próximo líder) verá um lote de fragmentos chegar para cada bloco. Se um bloco estiver incompleto por T milissegundos, o líder atual irá pular o bloco e construir uma bifurcação sem ele. Se o líder estiver errado, todos os outros nós votarão no bloco e o bloco do líder será ignorado. O líder não faltoso mudará imediatamente para o garfo mais pesado indicado pela votação.
No caso de transferências multibloco, cada nó precisará esperar até T milissegundos antes de votar na partição do bloco observado. Com dois líderes concorrentes, os cenários possíveis são: A, B ou A e B. Latência adicional só será adicionada se o bloqueio estiver atrasado. Em operação normal, todos os blocos devem chegar ao mesmo tempo, e cada validador pode votar assim que ambos chegarem. Portanto, T pode estar próximo de zero na prática.
O que esse ataque precisa se concentrar na defesa é se um líder com uma quantidade muito pequena de tokens apostados pode transmitir um bloco um pouco mais tarde em um limite de slot, causando assim uma divisão confiável da rede e forçando a rede a gastar muito tempo para resolver através do mecanismo de consenso. Parte da rede votará em A, parte votará em B e parte da rede votará em A e B. Todas estas três situações divididas precisam de ser resolvidas através de mecanismos de consenso.
Especificamente, o objetivo da vizinhança zero deve ser garantir que os nós recuperem blocos simultaneamente. Se um invasor tiver um nó cooperante na vizinhança zero, ele poderá transmitir 31/64 fragmentos normalmente e permitir que o invasor transmita seletivamente o último fragmento na tentativa de criar uma partição. Os nós honestos podem detectar quais retransmissores estão atrasados e enviar os fragmentos ausentes para qualquer nó honesto assim que recuperarem o bloco. Os retransmissores podem continuar se receberem o fragmento de qualquer lugar ou restaurá-lo. Portanto, os blocos devem ser recuperados por todos os nós logo após a recuperação de um nó honesto. O teste é necessário para determinar quanto tempo esperar e se é absoluto ou ponderado pelo tempo de chegada de cada fragmento e se a reputação do nó de participação deve ser usada.
A probabilidade de um co-líder e um retransmissor em cada bloco é de aproximadamente P ações líderes (64P ações de retransmissores). 1% da aposta pode ser usado para tentar ataques em ½ lotes de fragmentos organizados pelo atacante como líder. Portanto, a detecção e a mitigação precisam ser suficientemente robustas.
Este ataque tem impacto mínimo no próximo líder porque a execução assíncrona permite que a capacidade não utilizada seja transportada. Portanto, se o líder atual forçar o próximo líder a pular um slot, e o próximo líder tiver 4 slots consecutivos, a capacidade não utilizada do slot ignorado poderá ser transportada, permitindo que o líder inclua novamente a transação do slot ignorado.
Mesclar blocos simultâneos
Se um usuário enviar a mesma transação para os líderes A e B para aumentar suas chances de ser incluído ou de ser o primeiro no bloco, isso resultará em desperdício de recursos. Se isso acontecer, aumentar o número de líderes simultâneos terá uma melhoria de desempenho muito limitada porque eles simplesmente processarão o dobro de transações inúteis.
Para evitar transações duplicadas, os N principais pagadores de taxas determinarão em qual canal líder a transação é válida. Neste exemplo, o bit mais alto selecionará A ou B. Os pagadores de taxas devem ser atribuídos a um canal exclusivo para que o líder possa ter certeza de que o pagador de taxas é válido e não gastou todos os seus lamports (a menor unidade monetária no blockchain Solana) em outros líderes.
Isto forçará o spammer a pagar pela transação logicamente idêntica pelo menos duas vezes, mas para aumentar a probabilidade de ser a primeira transação, o spammer ainda poderá enviar a transação logicamente idêntica.
Para evitar esse comportamento, os usuários podem optar por incluir uma taxa adicional de pedido de gravação de 100% além da taxa de prioridade do líder. Os pedidos com as taxas mais altas são executados primeiro. Caso contrário, a ordem primeiro a entrar, primeiro a sair (FIFO) é usada. Em caso de empate, a ordem é resolvida usando permutações aleatórias determinísticas. Portanto, é mais econômico para os spammers aumentarem suas taxas de pedidos e executarem primeiro do que pagarem taxas de inclusão duas vezes.
Para lidar com sequências de transações agrupadas e reordenadas, o sistema precisa suportar transações agrupadas, o que pode adicionar uma taxa de pedido para cobrir o custo de sequenciamento de toda a sequência de transações. O pagador de taxa só é válido em seu canal programado, portanto o pacote só pode manipular sequências em seu próprio canal.
Alternativamente, uma taxa de pedido pode não ser necessária. Se a ordem FIFO for usada, e os spammers sempre pagarem uma taxa de prioridade em todos os canais, pode ser possível simplesmente permitir que o mercado decida que pagar a N líderes para aumentar o custo das oportunidades de inclusão é o mesmo que pagar ao líder mais próximo, com maior probabilidade. para incluir a transação primeiro o custo do operador.
Gerenciar recursos de bloco
Em uma rede blockchain, quando há dois líderes simultâneos, cada limite de capacidade de bloco em todo o sistema precisa ser distribuído uniformemente. Especificamente, não apenas a capacidade total, mas cada limite específico, como o limite de bloqueio de gravação – nenhuma conta pode gravar mais de 6 milhões de unidades de computação (CUs) e cada líder só pode agendar até 24 milhões de UCs. Desta forma, mesmo no pior cenário, os blocos mesclados não ultrapassarão o limite de capacidade total do sistema.
Este mecanismo pode levar a flutuações de taxas e subutilização de recursos, uma vez que a taxa de prioridade de agendamento será determinada pela capacidade de cada líder, e cada líder tem pouco conhecimento do status de agendamento de outros líderes concorrentes.
Para mitigar a subutilização de recursos e os aumentos de taxas resultantes, qualquer capacidade de bloco não utilizada deve ser transferida para blocos futuros. Isto é, se o bloco mesclado atual estiver usando menos do que algum valor máximo. A execução assíncrona pode atrasar o topo da cadeia em até uma época, portanto, a rolagem de capacidade pode ser bastante agressiva.
De acordo com dados recentes de blocos, a maioria dos blocos normalmente está 80% preenchida, enquanto o limite de bloqueio de gravação está bem abaixo de 50%. De um modo geral, deverá sempre haver alguma capacidade disponível para blocos futuros. Como os blocos podem exceder temporariamente os limites de capacidade, a execução deve ocorrer de forma assíncrona ao processo de consenso. Para obter mais informações sobre a proposta de execução assíncrona, consulte o artigo APE.
