Autor: Pavel Paramonov Fuente: X, @paramonoww Traducción: Shanooba, Golden Finance

Muchos creen que "ASS es todo lo que necesitas", considerándolo como una solución completa que apenas necesita mejoras. Sin embargo, ASS no puede resolver todos los problemas, también tiene ciertas suposiciones de confianza.

1. Las dApp de deserialización automática son parte de los constructores de Bloquear

Cuando un paquete de transacción entra en Bloquear, las dApps tienen el derecho de extraer su propio valor máximo extraíble (MEV) de otros 'miembros' en la Cadena de suministro MEV, como proponentes, buscadores y constructores, para obtener su propio valor. Sin embargo, este concepto no es perfecto (nada en el mundo de la encriptación es perfecto) y puede tener suposiciones de confianza.

2. Juego inclusivo

Los desafíos que enfrenta la dApp de autodeserialización son: cuanto mayor es el valor empaquetado, mayor es la demanda asegurada en el Bloquear. Si las transacciones que capturan MEV no se incluyen en el Bloquear, pueden volverse completamente no rentables, lo que no solo perjudica a otras transacciones que no pueden generar MEV, sino también a los usuarios.

Este es un escenario interesante para reflexionar:

• dApp tiene la capacidad de capturar todo el MEV que genera
• Pero si no solo se pierde la oportunidad de MEV, sino también la posibilidad de perder a los usuarios que aportan valor a la plataforma (por ejemplo, si las AMM siguen fallando, ¿quién seguirá utilizándolas?), entonces no tiene sentido.

Lo más interesante es que el proponente también necesita beneficiarse, lo que crea una situación de doble pérdida:

• Las dApp de autoserie se pierden MEV debido a que la vinculación no está incluida en Bloquear
• El proponente pierde MEV debido a la incapacidad de desempaquetar y reorganizar los enlaces atómicos (aunque pueden optar por otras transacciones)

3. La aplicación ASS dApp no debería dañar a los usuarios normales y a los Proveedor de liquidez (LP) al extraer MEV.

Como todos sabemos, la mayoría de las MEV se generan y extraen a través de tráfico malicioso. Los proveedores de liquidez pierden la mayor parte de los ingresos que obtienen de fuentes de tráfico no informadas debido a las MEV. Atraer liquidez a la plataforma es una de las tareas más difíciles en el campo de la encriptación, y AMM debería seguir la distribución justa de MEV a los proveedores de liquidez, lo que podría ayudar a reducir las pérdidas impermanentes.

En la realidad actual, gestionar activamente las posiciones de LP (incluso múltiples posiciones de LP) puede considerarse un trabajo a tiempo completo. Si se trata de un ataque de emparedado, el valor se devuelve a los traders; si se trata de un Arbitraje entre intercambios centralizados y intercambios descentralizados, el valor se devuelve a los LP. Entonces, la pregunta es cuánto deberían recibir a cambio y cuánto valor debería retener la dApp?

4. ¿Qué hacer si el tamaño del paquete vinculado entra en conflicto con el tamaño de Bloquear de la cadena subyacente?

Obviamente, no todos los dApp se auto-serializarán (al menos en un futuro cercano). El tamaño del bloque (o lote de transacciones) es limitado; si no hay límites, no hay cadena de bloques o 'cadena de bloques'. Suponiendo que un bloque puede contener hasta 100 transacciones, pueden surgir las siguientes situaciones:

• dApp envió un paquete de 100 transacciones que llenó todo el Bloquear. ¿Cuánto espacio de ganancias hay para otros 'miembros' en la Cadena de suministro de MEV que lo incluyan, propongan el Bloquear y lo ejecuten? *El dApp ha enviado un paquete con 99 transacciones vinculadas, y queda 1 espacio. ¿El proponente tiene suficiente incentivo para incluir este paquete? (A menos que estén realizando alguna forma de colaboración, como la preconfirmación)
• Dos dApp han enviado bundles. El primer bundle contiene 60 transacciones, el segundo contiene 50 transacciones. Obviamente, solo puede haber un bundle.

El punto clave es que el MEV generado por el primer paquete es mayor que el segundo, pero desde otro punto de vista, incluir el segundo paquete es más ventajoso porque las otras 50 transacciones de dApp no auto-serializadas combinadas con el paquete pueden crear más valor para el Bloquear.

Entonces, ¿quién debería ser incluido? ¿Quién es más rentable en Blockear, y no solo enlazar internamente?

La solución que se puede implementar es FCFS (primero en llegar, primero en ser servido), pero no puede garantizar la precisión, ya que la latencia sigue existiendo.

¿Cómo garantizar que la serialización sea beneficiosa para todos en lugar de solo beneficiar a un participante, privando así de valor a otros participantes (LP, usuarios)?

La solución potencial es establecer reglas de serialización específicas, y solo aquellos que sigan estas reglas tienen derecho a ordenar la vinculación. Esto es importante porque una serialización inadecuada puede provocar vulnerabilidades de seguridad.

Para los pares de intercambio automatizado (AMM), el uso de reglas de verificación codiciosas puede evitar que las transacciones sean front-run en piscinas AMM específicas. Sin embargo, la mayoría de las transacciones en los intercambios descentralizados (DEX) son transacciones de intercambio múltiple, por lo que se requiere otra forma de garantizar la resistencia a MEV.

¡Todavía en una etapa temprana!

Actualmente hay varias formas de realizar la auto-serialización, me inspiré en los métodos de @SorellaLabs en este tema. Estamos todavía en una etapa temprana en la implementación de la auto-serialización (o ASS, como lo llamó @ballsyalchemist), con diferentes infraestructuras teniendo diferentes compromisos.

El objetivo de ASS es hacer que las dApp sean responsables de su serialización y no preocuparse por la ejecución (manejada por la cadena). Aunque en L1, ASS es relativamente claro, es más atractivo en L2, ya que solo necesita manejar un serializador y L2 puede aportar más contenido mediante la implementación de reglas de serialización locales.

El espacio de subir es enorme z! (excepto el espacio Bloquear)