Nota de los autores: init4es un colectivo de investigación que trabaja en herramientas de Ethereum de próxima generación. Esta es una nota de investigación, no un documento de divulgación. Si bien discutiremos matices y lagunas en los modelos de seguridad de los sistemas implementados y propuestos, sería exagerado describirlos como “vulnerabilidades” o “desconocidos previamente”.

La resistencia a la censura sigue siendo un valor fundamental de las criptomonedas en general, y Ethereum en particularCreemos que los beneficios de realizar transacciones en cadena deberían estar disponibles para cualquier persona, y que las reglas de la cadena deben aplicarse a todos los usuarios y usos por igual. Los valores impulsan este espacio hacia adelante. La ingeniería es el proceso de poner a prueba nuestros valores contra la realidad para encontrar dónde y cómo se rompen.

¡Los dominós también se colocan en secuencia :) Foto de Tom WilsonenUnsplash

Definir la resistencia a la censura

Tendemos a modelar la censura como la prevención intencional de que las transacciones aparezcan en el ordenamiento canónico (es decir, la exclusión de transacciones). Consideramos que los órdenes son justos o neutrales cuando dependen enteramente del resultado económico del sistema de ordenamiento, y injustos o censurados cuando dependen de otra información. Por ejemplo, al crear un bloque, es aceptable rechazar una transacción de baja comisión, pero inaceptable rechazar una transacción porque fue enviada por una persona específica. Por lo tanto, decimos que una transacción está censurada si su inclusión depende de información no económica. Si la transacción crea más ganancias observables para el sistema de ordenamiento que cualquier otra transacción incluida, pero no es incluida en sí misma, se considera censurada. Esta definición motiva el trabajo en mecanismos de inclusión forzada para la resistencia a la censura. Si un usuario puede forzar la inclusión de su transacción, entonces no puede ser censurada bajo esta definición.

Mecanismos de inclusión forzada

Un objetivo de seguridad fundamental de las cadenas OP Stack es que el Secuenciador no debería poder evitar que los usuarios envíen transacciones a la cadena L2.

• Optimismo

Los rollups modernos tienden a tener una secuenciación centralizada. Esto significa que la censura por parte del secuenciador es trivial, ya que simplemente pueden optar por no incluir ninguna transacción de usuario dada. Para mitigar esto, varios rollups, incluido Optimismo y Arbitrum - tienen mecanismos de inclusión forzada. Estos mecanismos permiten a un usuario asegurarse de que su transacción se ejecutará por el rollup después de un cierto retraso de tiempo, independientemente del comportamiento del secuenciador. La inclusión se fuerza a través de un contrato desplegado en L1. Por lo tanto, las transacciones de inclusión forzada tienen teóricamente la misma resistencia a la censura que otras transacciones de Ethereum.

La inclusión forzada especifica un subintervalo que debe ser preservado en cualquier ordenación válida.

También se ha propuesto un mecanismo de inclusión forzada para Ethereum a través de EIP-7547Las listas de inclusión permitirían que las propuestas de bloque especificaran parcialmente el contenido del próximo bloque. Bajo el supuesto de que los proponentes de bloque tienen menos incentivos para censurar que los constructores de bloque, proporcionaría una mitigación efectiva a la censura.

En general, los mecanismos de inclusión forzada crean nuevas restricciones en los pedidos válidos. Hacen que amplias clases de pedidos sean inválidas según las reglas del protocolo¹. La inclusión forzada debe considerarse como permitir al usuario especificar un subconjunto del ordenamiento futuro. Todos los ordenamientos válidos deben expandirse a partir del subconjunto forzado.

Expandiendo nuestro modelo de resistencia a la censura

Desafortunadamente, la confirmación de la transacción es el medio, no el fin. ¡Nuestro modelo de censura es incompleto!

La censura debe definirse en términos de objetivos. Los usuarios quieren enviar tokens, comprar NFT, pedir prestado fondos, etc. La confirmación de la transacción es incidental a ese objetivo.². Los censores, de manera similar, tienen objetivos específicos. Ese objetivo puede ser evitar que alguna transacción de hackeo tenga éxito, cumplir con alguna ley o interferir en el negocio de un competidor. Respetando la intención de ambas partes, necesitamos redefinir la censura.

Con esto en mente, debemos ampliar nuestra definición de censura para decir: una transacción es censurada si un tercero puede evitar que logre su objetivo. Es decir, el censor no necesita evitar que la transacción se confirme; solo necesita hacer que la ejecución del contrato inteligente revierta. Hacer que una transacción de EVM revierta es censura de esa transacción, a pesar de que esa transacción forma parte de la cadena canónica. Los modelos de amenazas que son ciegos al contenido de una transacción no modelan con precisión la censura y, por lo tanto, no pueden proteger eficazmente a los usuarios de ella.

Semi-formalmente, podríamos decir que para cualquier interacción dada con la cadena, hay algún predicado de puntuación f que evalúa el orden resultante y produce 0 (objetivo no logrado) o 1 (objetivo logrado). En este modelo, la función de puntuación del censor es simplemente la negación: f' = !f. El censor logra su objetivo cuando el usuario no lo hace.³

Si bien el objetivo del usuario puede estar oculto, la transacción en sí casi siempre contiene suficiente información para inferirlo. Las operaciones en Uniswap tienen objetivos obvios. Además, debido a que las blockchains son deterministas, el censor puede predecir perfectamente qué órdenes satisfarán el predicado del censor. Como resultado, los usuarios no pueden confiar en la información oculta para protegerse de la censura en el modelo de EVM. Los detalles de la transacción deben ser públicos, lo que significa que la información sobre el objetivo del usuario es pública.

Para simplificar, supongamos que estamos trabajando en el modelo estándar de secuenciador de anticipación⁴. Nos ocuparemos de la inclusión forzada bajo la rotación del secuenciador más tarde. En este modelo, el secuenciador tiene un control total sobre la secuencia y puede simular perfectamente cualquier resultado. Es decir, son libres de elegir dentro del conjunto de todas las posibles ordenaciones. Nuestra pregunta semi-formal sobre la censura entonces se convierte en '¿existe alguna ordenación válida sobre la cual f se evalúa a 0'? Si existe tal ordenación, entonces el secuenciador puede seleccionarla.

A partir de ahí, podemos expandir nuestro modelo para tener en cuenta la inclusión forzada. “¿Existe algún orden válido, que incluya el subordenamiento del usuario, para el cual f se evalúe a 0?” Si tal orden existe, el secuenciador puede seleccionarlo. La inclusión forzada no impide que el secuenciador ejerza control sobre el orden, solo limita su comportamiento. Desafortunadamente, la inclusión forzada tiene problemas fundamentales que evitan que sea un mecanismo efectivo de resistencia a la censura para muchas transacciones.

El Problema de la Transferencia

Los mecanismos de inclusión forzada significan que el pedido se realiza en uno de dos modos: forzado o no forzado. Hay un punto definido en el que se produce la transición de no forzado a forzado (y viceversa). Ese punto es la entrega. La entrega plantea un problema espinoso para el diseño de los mecanismos de inclusión forzada.

Debe haber una transición de la inclusión no forzada a la inclusión forzada.

La transacción forzada se ejecuta en el estado en la entrega. Así que una vez más, contención de estado⁵ asoma su fea cabeza. Cuando la entrega se produce dentro de un lote de transacciones (como un bloque), el creador del lote puede ejercer control sobre el estado en la entrega. Si la transacción de inclusión forzada lee cualquier estado público, el creador del lote puede volver a escribir ese estado antes y después de la ejecución forzada de la transacción. La contención es suficiente para la censura.

Dado que el creador del lote puede ejercer control sobre el estado en la entrega, puede afectar el resultado de la transacción forzada. Si puede afectar el resultado, potencialmente puede afectar el resultado del predicado de puntuación. Por ejemplo, considere una interacción AMM simple. El usuario establece un precio mínimo aceptable, sin embargo, el creador del lote puede asegurarse de que en el punto de entrega el precio del mercado esté por debajo del precio mínimo aceptable. Esto hace que la transacción del usuario se revierta, censurando efectivamente al usuario.⁶⁷

Curiosamente, la censura a través de la contención estatal es más efectiva que la censura a través de la exclusión. Una transacción excluida puede ser incluida en bloques futuros. Una transacción censurada a través de la contención queda permanentemente invalidada. Ha sido incluida en la cadena y nunca más podrá ser incluida. Esa transacción nunca podrá alcanzar el objetivo del usuario. Para intentarlo de nuevo, el usuario debe recrear y volver a enviar la transacción (que luego puede ser potencialmente censurada de nuevo).

En sistemas prácticos

[A] cualquier usuario puede evitar por completo el Secuenciador para enviar cualquier transacción de Arbitrum (incluyendo una que, por ejemplo, inicie un mensaje de L2 a L1 para retirar fondos) directamente desde la capa 1. Así, el mecanismo preserva la resistencia a la censura incluso si el Secuenciador no responde en absoluto o incluso si es malicioso.

• Arbitrum

En el modelo de secuenciación anticipada, el secuenciador tiene un control casi perfecto sobre la ubicación de la entrega en la secuencia y paga tarifas reducidas (ya que no necesitan propina y pueden ejercer cierto control sobre la tarifa base EIP-1559). Como resultado, el secuenciador está en una posición privilegiada para usar la contención de estado para censurar las acciones del usuario. Es trivial. El problema de la entrega asegura que el secuenciador pueda censurar grandes clases de transacciones.

Para EIP-7547, los constructores eligen dónde ocurren las entregas en el bloque.⁸Como resultado, el constructor es capaz de elegir la ubicación de la entrega dentro del bloque. Esto significa que pueden seleccionar un prefijo y un sufijo a voluntad,⁹siempre y cuando respeten las reglas de gas de bloque. El prefijo puede poner la cadena en un estado en el que la transacción se revertirá, mientras que el sufijo restaurará la cadena a un estado normal. Las listas de inclusión EIP-7547 no son suficientes para evitar la censura para cualquier transacción que acceda a un estado controvertido. El problema de la transferencia evita que las ILs aseguren la ejecución de la transacción en la mayoría de los casos.

La inclusión forzada no es efectiva para proteger a los usuarios de la censura en la mayoría de los usos no triviales de la cadena de bloques. El problema de la transferencia de responsabilidad garantiza que el censor tenga suficiente discreción sobre el estado incluso si no tiene suficiente discreción sobre el orden. Este problema afecta a los AMM, los mercados de préstamos, las subastas y la mayoría de las otras acciones DeFi. Muchas acciones importantes son censurables incluso si se puede garantizar la inclusión de transacciones. La contención de estados crea límites duros en la efectividad de la inclusión forzada como mecanismo de resistencia a la censura.

Estudio de caso

Para ver los efectos de largo alcance de esto, considere la posibilidad de que un usuario preste USDC en un mercado de préstamos en Optimism. Cuando el usuario quiere retirar USDC del mercado, envía una transacción de Optimism, que el secuenciador censura. A continuación, utilizan el mecanismo oficial de inclusión forzada para poner en cola su transacción en Ethereum, sin pasar por el secuenciador.

El secuenciador puede ver esa transacción en la cola y puede optar por intercalarla. Para censurar la transacción, el secuenciador toma prestados todos los USDC disponibles del mercado inmediatamente antes de la transacción forzada. Debido a que el mercado ya no tiene liquidez, la transacción forzada se revierte. Luego, el secuenciador puede reembolsar los USDC de inmediato.

El secuenciador o constructor puede manipular el estado en el hand-off.

Esto requiere que el secuenciador tenga suficiente garantía para pedir prestado el USDC, pero solo impone un costo de préstamo extremadamente pequeño.¹⁰Además, el colateral es reutilizable para toda censura, ya que el préstamo nunca se mantiene abierto. Como resultado, un usuario de AAVE o Compound en Optimism (o Arbitrum o cualquier otro rollup secuenciado centralmente) no tiene garantía de que podrá retirar el colateral nunca. El secuenciador puede censurar cualquier retiro de cualquier mercado de préstamos en cualquier momento. La inclusión forzada simplemente no es suficiente para proteger a los usuarios contra la censura.

Trabajo de seguimiento

Tenemos algunas áreas de investigación de seguimiento.

En primer lugar, el EIP-7547 puede mejorarse trivialmente al requerir que las transacciones de IL se procesen al final del siguiente bloque. En el contexto de la subasta de PBS, la censura es MEV. El constructor obtiene algún valor no económico, al que debe asignar un valor subjetivo denominado en ETH. La censura por parte del constructor provoca un aumento en la oferta de bloques del constructor.¹¹Esto se extiende a los buscadores, que pueden crear paquetes de censura. Parte del valor económico de la censura es capturado por el proponente, lo que proporciona un incentivo para tolerar la censura incluso cuando no se participa directamente en ella. Colocar transacciones de inclusión forzada al final del bloque elimina la capacidad del constructor del bloque de colocar fácilmente las transacciones de inclusión forzada, y aumenta el costo económico de la censura controvertida. Por ejemplo, censurar una interacción de AMM a través de la contención del estado podría requerir renunciar a cierto arbitraje de AMM o a un alto costo para sacar el mercado fuera del rango que no se puede recuperar cerrando el sandwich. Además, esto restringiría los paquetes de censura producidos por los buscadores (en lugar de los constructores) a uno por bloque.¹²Recomendaríamos la ejecución en la parte superior del bloque, ya que el prefijo es más significativo que el sufijo, sin embargo, eso aumentaría drásticamente el costo de una transacción de IL, ya que permitiría la extracción de MEV en la parte superior del bloque mediante la inclusión forzada.¹³Eliminar el derecho del censor de agregar automáticamente las transacciones de IL al final es una pequeña mejora.

Segundo, el problema de transferencia existe porque el censor puede mirar hacia adelante a través de la simulación de transacciones y ejercer control sobre el estado de entrada. Muchos mecanismos de resistencia a MEV introducen información oculta para eliminar la capacidad del censor para derivar información sobre los objetivos de los usuarios y simular resultados. Por lo general, estos son esquemas de compromiso-revelación, donde cierta información de transacción es privada hasta después de que ocurra el pedido. La separación de ordenación-ejecución y la información oculta parecen prometedoras, pero son en gran medida incompatibles con la cadena de suministro de MEV, los procesos de consenso de Ethereum y el modelo de rollup secuenciado. Alguna forma de negar la capacidad de simular transacciones abordaría la censura y grandes clases de MEV, pero sería extremadamente invasiva para el protocolo, los operadores del protocolo, las aplicaciones y el usuario final.

En tercer lugar, hay una interesante clase de funciones de puntuación “independientes del orden”. Estos son objetivos que no pueden ser censurados por la contención estatal, ya sea porque no acceden a un estado controvertido, o porque el estado controvertido al que acceden tiene suficientes restricciones para hacerlo “confiable” en cierto sentido. Las acciones independientes del orden incluyen el envío de ETH a un EOA, la mayoría de las transferencias de ERC-20,¹⁴y algunas interacciones DeFi como agregar garantías a un mercado. Estas acciones están protegidas de la censura a través de la contención. Esta clase de objetivos también tiene interesantes correspondencias en la comunicación segura entre cadenas y la resistencia a MEV y vale la pena un estudio más profundo. En algunos casos, las aplicaciones y protocolos pueden diseñarse para incluir solo acciones independientes del orden, pero se necesita más estudio.

Conclusión

El estado enriquecido permite a los actores malintencionados censurar las transacciones sin dejar de incluirlas. El problema del traspaso es fundamental para los mecanismos de inclusión forzada, y sólo puede ser mitigado. En los resúmenes secuenciados centralmente, no es posible ninguna mitigación. La inclusión forzada no puede abordar la censura en presencia de un Estado contencioso. Grandes clases de transacciones económicamente importantes pueden ser censuradas, incluso si se incluyen por la fuerza. El problema de la transferencia es endémico en los rollups modernos y está presente en los EIP de resistencia a la censura de Ethereum. Como resultado, la inclusión forzada, si bien es beneficiosa, nunca es suficiente para proporcionar resistencia a la censura para las cadenas de estados ricos. Los rollups no "heredan" las propiedades de seguridad de Ethereum y es una tontería sugerir que lo hacen. Cuando dejas de obsesionarte con la inclusión, se hace obvio que la resistencia a la censura es un caso especial de resistencia al MEV.

Nos gustaría agradecer Mike Neuder, Tarun Chitra, y Brandon Curtis para su revisión y retroalimentación.

1

Como es típico, para L1s esto se logra rechazando bloques inválidos, mientras que en rollups se logra coerciendo secuencias inválidas a secuencias válidas a través de alguna función de filtración.

2

Este no es un post sobre intenciones, el mundo no necesita más de esas en este momento.

3

Obviamente, este es un modelo incompleto, ya que no tiene en cuenta los valores subjetivos de los resultados. Por ejemplo, el censor podría perder cualquier cantidad de dinero si la censura falla (por ejemplo, porque podrían ser arrestados por la policía francesa si no censuran cierto comportamiento). Por otro lado, el usuario podría ganar/perder cualquier cantidad de dinero si su objetivo no se logra en un plazo específico (por ejemplo, han tomado $100mm+ en préstamos contra su propio token y necesitan volver a colateralizar la posición antes de ser liquidados).

4

A diferencia de un modelo de secuenciador "basado". En la mayoría de los rollups modernos, el secuenciador "se adelanta" a Ethereum, ya que proporciona certificaciones de inclusión y ejecución para una transacción antes de que la transacción se haya confirmado en Ethereum. En este modelo, el secuenciador tiene control total sobre la secuencia, y el resultado de la transacción debe ser independiente de las reorganizaciones de Ethereum.

5

Cuando varios usuarios quieren acceder al mismo contrato, activo o estado, sus transacciones "compiten" entre sí y potencialmente interfieren con los resultados de los demás. La contención puede surgir por coincidencia o deliberadamente. Este es un problema intratable de estado rico en sistemas blockchain. El acceso público al Estado compartido es la raíz del MEV, de los problemas de escalabilidad y del declive de la civilidad en la sociedad moderna.

6

En general, deberías considerar la resistencia a la censura a través de la contención estatal como un caso especial de MEV. Debido a que el valor extraído está fuera de la cadena, no es observable y potencialmente muy grande, puede ser difícil predecir cuándo ocurrirá la resistencia a la censura a través de la contención estatal.

7

Específicamente cubrimos el uso de la contención estatal para revertir transacciones en nuestro artículo de 2017 “Los mineros no son tus amigosEn ese entonces, el término 'MEV' todavía no se utilizaba.

8

Es bien sabido que PBS complica drásticamente la resistencia a la censura. Ver VB’s@vbuterin/pbs_censorship_resistance">nota de investigación.

9

Agregar un prefijo y un sufijo a una transacción se conoce comúnmente como "sandwiching" y se entiende bien como un método para utilizar la contención de estado para extraer MEV.

10

El préstamo se mantiene solo durante unos pocos segundos, si acaso. Los secuenciadores de rollup pueden en algunos casos mantener marcas de tiempo o límites de bloques para hacer que el tiempo efectivo de préstamo sea 0.

11

El constructor estará dispuesto a pagar hasta su valor subjetivo de censura, lo que podría empujar la oferta por encima del valor extraíble objetivamente observable del bloque. En casos extremos, esto puede dar lugar a casos en los que el censor tiene un cambio negativo en el saldo de ETH (es decir, paga más ETH para producir el bloque de lo que recibe en tarifas y recompensas).

12

Tenga en cuenta que esto depende de las reglas de subasta de MEV que evitan la intercalación de transacciones de diferentes paquetes y no permiten transacciones de “debe revertir”. Si esas reglas se relajaran para permitir que las transacciones del paquete se intercalen, y/o si los constructores comenzaran a admitir bloques de “debe revertir” en paquetes, la protección se evaporaría. Esta dinámica surge porque si las transacciones IL deben estar al final del bloque, no se pueden intercalar transacciones no forzadas, y por lo tanto como máximo podría ocurrir un paquete de censura de buscadores.

13

Permitiendo efectivamente al creador crear paquetes interbloques limitados. Sistemas de preconsenso como FOCIL podría mitiGate esto.

14

Para un token ERC-20 estándar, la llamada de transferencia generalmente no es censurable mediante la disputa, ya que terceros no pueden disminuir el saldo del usuario. Sin embargo, considera una llamada transferFrom. Si el transferente aprobado es un contrato que permite la disputa en su propio estado, entonces la acción puede ser censurable a través de esa disputa (consumiendo la aprobación requerida para el transferFrom de alguna manera no intencionada).

Renuncia:

1. Este artículo es reproducido de [la tecnología], Todos los derechos de autor pertenecen al autor original [init4]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.