Escrito por Pröfesor Utonio, miembro de DeFi LATAM.

Aunque la extracción de MEV se concentra mayormente en el ecosistema de Ethereum, no es exclusiva de la red. En diversas blockchains encontramos un mundo de posibilidades por explorar y explotar. En esta segunda entrega de MEV Series nos adentramos en el ecosistema de Solana para explorar las diferencias con Ethereum en cuanto a la extracción de valor y las posibilidades que brinda la arquitectura de construcción en la red.

Mecanismo de transacciones en Solana

Solana es mempool-less, ya que las transacciones que reciben los validadores se ejecutan al instante, llevando a tener 50.000 transacciones por segundo. A este mecanismo lo llaman Gulf Stream. Los validators en Solana pueden manejar hasta 100k transacciones en su mempool local. Esto combinado a un throughput de 50k TPS, lleva a que los validators ejecuten la totalidad de transacciones en su mempool en cuestión de segundos.

Dado que cada validator en la red conoce el orden de los próximos líderes, los clientes y validators envían las transacciones que les llegan al validator que se sabe que será líder  antes de que efectivamente lo sea. Esto permite a los validators ejecutar transacciones con anticipación.

Los validators envían las transacciones que les llegan directamente al líder actual y al próximo líder  en la secuencia del líder schedule para que la incluya en sus slots, en vez de propagar las transacciones de forma aleatoria como en Ethereum. Si el líder actual no puede procesar todas las transacciones, las reenvía a los próximos validadores. Explicación detallada acá.

Propagación de transacciones: Turbine Block

Solana se divide en clusters. Los clusters son un conjunto de validadores que trabajan juntos para procesar transacciones. En la red, pueden coexistir muchos clusters en simultáneo. Las transacciones enviadas al cluster incorrecto son rechazadas.  Explicación detallada acá.

Cada validador retransmite las transacciones a un grupo de pares que llaman Vecindario. Se puede entender a la red como un árbol de vecindarios, en donde cada uno retransmite lo que le llega al vecindario que le corresponde. Cada nodo es responsable de compartir cualquier dato que reciba con los otros nodos en su vecindario, además de propagar los datos a un conjunto de nodos en otros vecindarios. De esta manera, cada nodo sólo tiene que comunicarse con los nodos a los que retransmite los datos.

Slots y transacciones en la red

Solana avanza en epochs, los que tienen una duración de 2-3 días, y cada epoch consta de un conjunto de bloques (~432k), con un blocktime de ~400ms. Cada validator tiene el deber de votar en cada bloque, y ya que los votos en Solana son on-chain y cada voto es una transacción, la mayoría de las transacciones que se encuentran en un bloque son votos de validators. Por cada voto correcto que emiten, obtienen recompensas.

Si bien los validadores que serán líderes se conocen con mucha anticipación en la red, concretamente 2 epochs anteriores, el líder escucha las transacciones que incluirá en su bloque solamente cuando le toca su turno, no antes.

Los validadores están programados para ser líderes y validar un set de transacciones. Por el líder schedule, cada validator puede calcular individualmente quien será el próximo líder en la secuencia. El líder puede escuchar las transacciones por N slots antes de ser efectivamente validador, pero no tiene la certeza de que validará esas transacciones, porque éstas pueden haber sido incluidas por otro líder previamente. Entonces, éste conoce concretamente qué transacciones incluirá solamente en su turno.

Debido a lo anterior, no puede haber 2 líderes creando bloques al mismo tiempo. Es posible, pero ya que todos los nodos en la red saben quien es el próximo líder en la secuencia, no van a votar al que esté intentando crear ese bloque malicioso. Si no fuiste ‘elegido’ como líder para crear bloques, nadie te votará y directamente rechazan ese bloque.

Costos y ganancias de un validador

El hardware necesario para configurar un validador es muy alto. Algunos de los requerimientos comprenden 128GB de RAM y una velocidad de 1 Gbit/s, entre otros.

Además de los costos de hardware, los validadores deben incurrir en gastos para cubrir los costos de votar bloques de los demás validadores (vote credits). Los validadores obtienen vote credits cada vez que envían un voto sobre un bloque de la red finalizado, cada voto correctamente emitido representa 1 crédito. Los validadores que votan con más frecuencia son recompensados con más créditos. Votar incorrectamente, resta créditos.

Actualmente estos costos son de 1.1 SOL por día, arrojando un gasto de ~$6.6k por día a los precios actuales; por lo que si un validador no consigue atraer suficientes delegantes a su stake y no cuenta con un self-stake para cubrir este costo, entrará en pérdidas, ya que en los ingresos que obtiene el validator por asegurar la red, se incluye la recompensa por votos correctamente emitidos, y lo que gana por crear el bloque. Un validador necesita suficiente participación para ganar más en recompensas de lo que gasta en votar.

En Solana, los validadores pueden ganar muchas más recompensas como consecuencia de votar correctamente a tiempo, que lo que obtienen por ser líderes y procesar bloques en la red. Por cada bloque creado, se llevan el 50% de los fees de las transacciones (el otro 50% de SOL es quemado). Así, los validadores están incentivados para incluir tantas transacciones como sea posible dentro de su tiempo límite.

En esto, Solana se diferencia de otras blockchains, en las cuales si un minero/validador no procesa bloques, no obtendrá ganancias.

Skip rate: es el porcentaje de slots donde un validador no cumple con los requisitos de la network. Básicamente cada vez que un líder se “pierde” la oportunidad de validar un bloque por no mantener los estándares de la network respecto de la velocidad, van a ir acumulando la cantidad de “skips” que hizo en la network y esto va a representar la fiabilidad que uno puede tener en este validador. En este sentido, la latencia que los nodos tienen entre sí juega un papel fundamental, ya que si un validador se encuentra muy lejos de la mayoría, probablemente cuente con un porcentaje mayor de skip rate por la latencia entre éstos, en consecuencia no produciendo bloques.

Dificultades que comprenden la extracción de valor

Ya que no hay mempool, no hay un lugar al que los bots de arbitraje puedan acceder en busca de transacciones a la espera de ser confirmadas. Siendo así, los únicos que tendrían la potestad de ver las transacciones pendientes son los validadores, en consecuencia cuentan con la posibilidad de reordenar transacciones, pero esto conlleva varias dificultades:

• Las transacciones en Solana son deterministas, esto quiere decir que todos pagan lo mismo por cada transacción. Si bien los fees pueden variar bloque a bloque, son deterministas en el sentido en que las transacciones específicas a un blockhash son similares, y se pagan de acuerdo con la configuración de ese bloque en particular. Los fees varían levemente de acuerdo al protocolo y la complejidad, pero en general rondan los $0,001.
• No es posible modificar el gas artificialmente. Esto invalida la posibilidad de una gas war entre searchers. Directamente anula la posibilidad de bribear al validador enviando una transacción con un fee alto para que contar con prioridad de ordenamiento por sobre los demás.
• No existe (actualmente) una variable similar a block.coinbase en Rust que retorne la address del líder actual para bribear directamente al líder enviándole una transacción.
• Cada líder cuenta con un tiempo límite de 400ms para incluir 4 slots en la blockchain, y luego la oportunidad para validar bloques se transfiere inmediatamente al líder subsiguiente. Tienen una ventana de tiempo muy corta para ejecutar arbitrajes.
• Cada validador es responsable de armar su secuencia de PoH, completando el proceso de VDF. Al finalizar la secuencia de PoH, las transacciones (y por lo tanto, los slots) quedarán estampadas (timestamping). La transacción que procesa el validator incluye el hash del PoH de la transacción anterior y la firma del usuario, por esto no será posible reorganizar bloques.

Ciclo de las transacciones en Solana

• La dapp crea una transacción para comprar algunos tokens
• La dapp envía la transacción a la wallet del usuario para que sea firmada
• El usuario firma la transacción y la envía de nuevo a la dapp
• La dapp toma la transacción firmada por el usuario y la envía al nodo especificado en la dapp
• El nodo envía las transacciones que recibe al próximo líder validador en la secuencia
• El líder recibe las transacciones a procesar, verifica las firmas y elimina las transacciones maliciosas, procesa las correctas, las marca con un hash tick (PoH) y las propaga al resto de la red. La diferencia entre el validador y el líder es que si un validador observa una transacción incorrecta, no puede simplemente eliminarla como lo haría el líder, porque eso haría que el hash de PoH cambie. En cambio, rechaza todo el bloque.

Actores que entran en juego en este escenario

Los nodos mantienen las transacciones que les llegan en sus servidores. El nodo que recibe las transacciones y luego las envía al líder, tiene la posibilidad de revisarlas. Aunque no tienen la potestad de reordenar ni decidir qué transacción se incluye primero, pueden leer oportunidades con anticipación y retrasar la propagación de transacciones hasta enviar sus propias transacciones. Con una latencia extremadamente baja con los nodos y el validator, podrían enviar su transacción primero.

En la medida que los validators puedan ser conocidos/calculados con tanta anticipación (2 epochs), se abre la posibilidad de coludir entre éstos para generar estrategias y extraer valor en múltiples bloques secuenciales.

MEV - front running y reorgs

Bob, Alice y Josh envían sus transacciones. El líder recibe el conjunto de transacciones a procesar, incluidas las transacciones de Bob y Alice que cuentan con el mismo blockhash, y la de Josh que tiene un blockhash diferente al de Alice y Bob.

El líder puede incluir su propia transacción antes, después y entre las de Alice/Bob/Josh. Al armar el VDF, puede incluso reordenar la transacción de Alice para que pase antes que la de Bob, pero no puede hacer que la transacción de Josh suceda antes que la de Alice y Bob, porque tienen blockhash diferente. Si la transacción no se confirma a tiempo (<32 blocks), se invalida y se tendrá que firmar nuevamente con un blockhash más reciente.

Posibles escenarios que se pueden dar

• Un validador encuentra la forma de deployar un bot de arbitraje lo suficientemente rápido como para extraer MEV. Debido a esto, ofrece un porcentaje mayor de recompensa como incentivo, prometiendo extraer MEV y atrayendo a los usuarios para que deleguen con él, y así aumentar sus chances de ser elegido como líder. Los usuarios estarían incentivados a delegar en su pool, al ser uno de los pocos (o el único) que dispone de este mecanismo, y por lo tanto, puede ofrecer un interés mayor que los demás pools como incentivo.

Su stake crece, y aumentan sus chances de ser elegido validador y extraer MEV en cada ocasión → Mayor centralización. ‘the rich get richer’. Esto podría derivar en que los grandes pools de stake sean mayormente elegidos como líderes para incluir bloques, permitiendo la extracción de MEV en múltiples bloques concentrados en una sola entidad.

• Ahora mismo no hay un ‘priority fee’ con el cual se pueda incentivar a los validadores para que procesen nuestra transacción primero por encima de otras, ya que como explicamos más arriba, los fees son deterministas en la red.

Esto es un poco confuso debido a que en los documentos oficiales se establece que “Si la red está congestionada, el slot líder puede priorizar las transacciones que ofrecen los fees más altos” y que “*En la primera implementación de este diseño, el único parámetro de fee es lamports_per_signature. Cuantas más firmas necesite verificar el cluster, mayor será el fee”

*Claramente se deja entrever que el usuario puede incluir más firmas en las transacciones que efectiviza, en consecuencia haciendo subir el fee que paga artificialmente. Los fees son proporcionales a las firmas necesarias para procesar la transacción, no importa la cantidad de instrucciones que requiera dicha transacción para interactuar con X protocolo.

La unidad básica de medida de SOL es llamada ‘lamports’. 1 lamport = 0.000000001 SOL.

Cada firma que incluye el usuario en la transacción es igual a 5000 lamports. Por lo tanto: a más firmas incluidas en la transacción → más alto el fee → el validador puede escoger qué transacción tiene prioridad, en base a sus incentivos económicos.

• Un validator detecta MEV en las transacciones que debe incluir en sus slots. Para apropiarse de ésta, decide censurarla y colocar su transacción en primer lugar.

Ej: en un contexto de baja generalizada en el mercado, se ejecutan liquidaciones en los vaults de Parrot después de una actualización en los precios del oráculo. El líder  actual detecta esto y decide procesar primero su transacción para adueñarse de tales liquidaciones.

• Ya que el validator es el último actor en decidir quién se queda con la oportunidad de arbitraje en sus slots, y teniendo en cuenta que se conocen con mucha anticipación se podría generar un mecanismo de off-chain bribes en donde los validators vendan el blockspace o se genere una especie de dark-mempool en paralelo para vender esa información privilegiada. Igualmente, esto solo sería posible si los searchers cuentan con una latencia extremadamente baja con el validator.

Posibles soluciones

• **Mitigar el MEV
  **Disminuir el tiempo de rotación entre líderes. Los líderes cambian cada 2.5 aproximadamente. A menor tiempo → Menor probabilidad

  Disminuir el blocktime. Menor blocktime → Mayor dificultad para extraer MEV.

  Esto solo es posible si todos los clusters se actualizan. Una vez que así sea, se podría upgradear el blocktime. Pero esto aumentaría la centralización al ser necesaria una inversión mayoritaria en hardware para alcanzar niveles de blocktime más bajos de los demás validators.

• Democratizar la extracción

  La visión con la que cuenta Flashbots para democratizar el MEV parece ser la más justa en este caso. Nivelar la extracción de valor de los validators para que todos puedan acceder y no tienda a centralizarse en los que encuentren la forma de extraer valor. Separar los roles en la construcción de blocks como en eth2 y que se venda el blockspace más rentable.

  El problema en separar los roles entre block proposer/producer sería, de nuevo, la latencia. Con el blocktime de 400ms sería cuasi imposible enviar bundles al validador exitosamente, incluso estando en el mismo estado/región.

Conclusión:

Solana está creciendo a pasos agigantados, el crecimiento del capital bloqueado y el desarrollo de la red atraen a varios arbitrajistas en busca de oportunidades (todavía) por explotar. Si bien este es un tema poco explorado en la red, podríamos llegar a verlo en el ojo de la tormenta dentro de relativamente poco tiempo.

Explicadas las posibles razones y teniendo en cuenta la dificultad que conlleva deployar bots de arbitraje al igual que sucede actualmente en Ethereum, la extracción de MEV podría verse centralizada en los pocos actores que logren verlo efectivizado. Por otro lado, las barreras de entrada para esto son excesivamente altas: los costos de correr (y mantener) un nodo validador y la complejidad/robustez del lenguaje Rust en comparación a Solidity llevarían a que sea difícil democratizar.

Este ‘problema’ podría posponerse, pero definitivamente será un enigma a tener en cuenta en el futuro considerando que cuando hay una gran cantidad de dinero en juego, los searchers lo seguirán de cerca.

Gracias a @0xPEPO, @martintriay y @josebaredes por los comentarios y sugerencias recibidas.

Fuentes:

• Solana validator 101
• Solana - documentos oficiales