Clasificador compartido detallado 4D: principio de funcionamiento, teoría de agregación e integración vertical

Este documento analiza las tecnologías clave de los secuenciadores compartidos: altamente resistentes a la censura, fáciles de implementar, interoperables, rápidos de determinar e instantáneos. La teoría de la agregación le proporciona una nueva perspectiva, y la integración vertical guía su desarrollo posterior.

Título original: "El secuenciador compartido"

Escrito por: MAVEN11

Compilación: Kxp, BlockBeats

Imagínese cómo sería si Rollup "fuera de la caja" pudiera lograr un alto grado de resistencia a la censura, facilidad de implementación, interoperabilidad, finalidad rápida, vivacidad y democratización de MEV. Eso puede parecer un gran objetivo, pero con la llegada de Shared Sequencer, pronto podría convertirse en una realidad. Sin embargo, no todos los Rollups son iguales, por lo que debemos considerar cómo distribuir las recompensas y MEV en la red de secuenciador compartido. En este documento, exploramos cómo se implementan las redes de clasificación compartidas y las propiedades que se pueden lograr.

Shared Sequencer Networks fue presentado principalmente por Alex Beckett, luego por Evan Forbes (y Radius) de los equipos de Celestia y Espresso, y un nuevo artículo de Jon Charbonneau que cubre el tema con más profundidad. Josh, Jordan y su equipo de Astria están construyendo la primera red de secuenciadores compartidos lista para la producción. Shared Orderer Network de Astria es una cadena de bloques modular que agrega y ordena las transacciones de Rollup sin ejecutarlas.

En la configuración de Astria, el clasificador envía bloques ordenados a la capa DA y también a los nodos de resumen. Los rollups obtienen garantías de finalidad blanda del ordenante y garantías de finalidad firme de la capa DA (después de que se finalizan los bloques), y luego ejecutarán transacciones válidas.

La red de secuenciadores compartidos es esencialmente un grupo de secuenciadores compatibles con Rollup, como su nombre lo indica, puede proporcionar servicios para diferentes Rollups. Esto tiene varias compensaciones y propiedades, que detallaremos más adelante. Primero, debemos describir las propiedades más importantes de un clasificador (o conjunto de clasificadores). En Rollup, el requisito principal para un secuenciador o grupo de secuenciadores es la resistencia a la censura o la vivacidad (parte de la cual proviene de la capa base, así como la seguridad). Esto significa que una transacción válida enviada al ordenante debe incluirse en la cadena dentro de un tiempo finito (parámetro de tiempo de espera). El grupo de pedidos compartidos solo necesita asegurarse de que las transacciones se incluyan en bloques (es decir, crLists).

Satisfacer la resistencia a la censura y la inmediatez al mismo tiempo es bastante difícil, como describimos en Modular MEV Parte II. En un algoritmo de consenso como Tendermint, puede garantizar la recuperación después de un ataque. Sin embargo, en caso de ataque, se pierde inmediatez. Básicamente, exigir que todos los demás cotejadores firmen un bloque, en lugar de elegir un masternode personalizado, probablemente no sea óptimo. Si bien esto mejora la resistencia a la censura, tiene el costo de la "centralización" y la extracción de MEV a un solo masternode. Otro mecanismo de clasificación disponible se puede comparar con Duality's Multiplicity, que es su pequeña herramienta para que los nodos maestros (o clasificadores) incluyan otras transacciones en bloques. En general, la resistencia a la censura y la inmediatez después de un ataque son difíciles de lograr en la mayoría de los protocolos de consenso.

Otro algoritmo de consenso que se puede utilizar es HotStuff 2, que garantiza la inmediatez en caso de ataque.

Lo que permite es evitar esperar un retraso máximo de la red (timeout) en caso de censura o no firmado para elegir un nuevo masternode. La razón por la que podría ser un algoritmo de consenso interesante para un conjunto descentralizado de ordenadores es porque resuelve el problema de la inmediatez en el consenso sin agregar una etapa adicional. Si el masternode conoce el bloqueo más alto (el mayor número de participantes que están de acuerdo con un resultado en particular) y puede convencer a las partes honestas, el problema está resuelto. De lo contrario, un masternode honesto después de cierto punto puede hacerse cargo del empuje, ayudando al próximo masternode. Por ejemplo, un nodo Hotstuff no necesita reconocer un mensaje de cambio antes de notificar a un nuevo maestro, pero puede cambiar directamente a una nueva vista y notificar al nuevo maestro.

La diferencia con Tendermint es que, aunque ambos son de dos fases (Hotstuff1 tiene tres, Hotstuff2 tiene dos), Tendermint tiene comunicación lineal pero no responde, mientras que Hotstuff2 es reactivo. Si existe una cadena de masternodes honestos, el protocolo responde positivamente, ya que todos los pasos excepto la propuesta del primer masternode dependen de obtener la cantidad de información del paso anterior. En una configuración de pedido compartido, esto permite que el protocolo logre una mayor inmediatez sin volver a la capa inferior, sin cancelar esta posibilidad.

Construcción de grupos clasificadores compartidos

Un conjunto de ordenantes puede enviar transacciones a la capa de liquidación (la capa donde reside el resumen). Puede unirse a este grupo de recopiladores, siempre que se cumplan ciertos requisitos y no se haya alcanzado el número requerido de productores de bloques. Esto optimiza la latencia, el rendimiento y más. Estos requisitos son similares a los que se requieren para convertirse en un validador de una cadena de bloques. Por ejemplo, tienes que cumplir con ciertos requisitos de hardware, así como un depósito inicial, especialmente si quieres ofrecer certeza con las condiciones financieras.

Un grupo de ordenante compartido (o cualquier grupo de ordenante descentralizado) consta de varios componentes que funcionan juntos para garantizar el procesamiento correcto de las transacciones, entre ellos:

1. Proporcione JSON-RPC para cada resumen para el envío de transacciones (para operadores de nodo no completo) al nodo como un grupo de memoria, y luego construya y clasifique. En el mempool, se necesita algún mecanismo para determinar la cola, así como el proceso de selección de transacciones, para garantizar la construcción eficiente de bloques.

2. Algoritmo de construcción de bloques/lotes, responsable de procesar las transacciones en la cola y convertirlas en bloques o lotes. Este paso también puede incluir la compresión para reducir el tamaño del bloque resultante (llamada compresión de datos). Como se mencionó, esto debe estar separado del Proponente, esencialmente PBS. Los datos se pueden comprimir de varias maneras, por ejemplo:

• Sin codificación RLP; sin embargo, esto puede requerir un conjunto de recopiladores descentralizados para ayudar a normalizar la transferencia de datos entre nodos, ahorrando así espacio.
• Omita el nonce (número único que valida los datos en un bloque en particular): se puede volver a calcular en el momento de la ejecución observando el estado anterior de la cadena.
• Simplificación del precio del gas: establezca el gas en función de un rango de precios fijo.
• Simplificación de gas: además del precio del gas, también hay un sistema de numeración de gas.
• Reemplazar dirección con índice: Rollup puede almacenar un índice de una dirección asignada en lugar de almacenar la dirección completa.
• Valores expresados en notación científica: los campos de valor en las transacciones de Ethereum están denominados en wei, por lo que los valores son grandes. No puede omitir campos numéricos ni reducirlos a un conjunto fijo de valores. Sin embargo, puede escribirlo en notación científica para optimizar el almacenamiento de datos:

• Omisión de campos de datos: Los campos de datos no son obligatorios para transferencias simples, pero sí para transacciones más complejas.

• Reemplace las firmas individuales con firmas agregadas de BLS: las firmas son el componente más grande de las transacciones de Ethereum. En lugar de almacenar cada firma, puede almacenar firmas agregadas de BLS para una cantidad específica de transacciones. También puede verificar la firma agregada de BLS con el conjunto de mensajes y el conjunto de remitentes para garantizar su validez.

• Utilice el campo Desde como índice: al igual que el campo Hasta, puede utilizar el campo Desde como índice para el mapeo.

• Un concepto interesante de diseño "modular" es que puede hacer ajustes y compensaciones según sea necesario para que funcione para su paquete acumulativo.

3. La capa de igual a igual permitirá a los ordenantes recibir transacciones de otros ordenantes y propagar bloques después de la construcción. Este paso es fundamental para garantizar que el secuenciador compartido funcione de manera eficiente en varios resúmenes.

4. Algoritmo de rotación maestra para conjuntos de ordenadores compartidos (no se requiere consenso en caso de elección de maestro único). Puede elegir establecer solo el algoritmo de rotación del nodo maestro o tomar la ruta del productor de bloques multiconcurrente propuesta por Duality.

5. Los algoritmos de consenso, como el mencionado Tendermint o Hotstuff2, pueden garantizar que los nodos de resumen estén de acuerdo con la secuencia propuesta por el libro mayor.

6. Cliente RPC para enviar bloques/lotes a la capa de consenso DA+ subyacente para que los bloques/lotes se puedan agregar de forma segura a la capa DA, asegurando la finalidad "final" y haciendo que todos los datos de transacciones estén disponibles en la cadena.

7. Separar los roles de constructores y productores de bloques para garantizar la equidad y la coherencia, y evitar el robo de MEV. También elimina la ordenación realizada, que es importante para optimizar la eficiencia, reducir el PGA y aumentar el CR.

*Los nodos de resumen reciben bloques ordenados del clasificador para envío suave y reciben bloques de capa DA ordenados para envío duro. *

Los datos de llamada se publican primero en la red base, donde se ejecuta el consenso para garantizar las transacciones de usuario y resumen. Luego, el nodo de resumen ejecuta la transacción y envía una función de transición de estado a la cadena de resumen canónica. Una red de ordenadores compartidos proporciona a Rollup inmediatez y resistencia a la censura. Los rollups mantienen su soberanía porque todos los datos de las transacciones se almacenan en la capa base, lo que les permite bifurcarse del ordenante compartido en cualquier momento. La raíz de estado de la función de transición de estado (STF) acumulada se calcula a partir de las raíces de transacción (entradas) enviadas desde el ordenador compartido a la capa DA. En Celestia, las raíces de estado se generan cuando se agregan datos a la cadena y se llega a un consenso. Dado que ya tiene la raíz de la transacción (y todos los datos disponibles), Celestia puede proporcionar a los clientes ligeros (nodos de resumen que se ejecutan en Celestia) una pequeña prueba de inclusión.

Para brindar la experiencia de usuario que los usuarios esperan, los nodos de resumen reciben bloques ordenados (que también se envían a la capa DA). Esto puede proporcionar a Rollup garantías deterministas blandas: garantías de que los bloques eventualmente se ordenarán en orden en la capa DA, momento en el cual los nodos de Rollup ejecutan transacciones y proporcionan nuevas raíces de estado.

Creación de bloques y tragamonedas

Para determinar el tiempo de creación del bloque, el secuenciador necesita configurar la ranura. El secuenciador debe enviar lotes a intervalos fijos (normalmente X segundos), donde X es el intervalo de tiempo. Esto garantiza que las transacciones se procesen de manera rápida y eficiente, ya que, de lo contrario, el masternode para un espacio en particular se agotaría y perdería la recompensa de firma (y la recompensa de ejecución). Por ejemplo, el tiempo de bloqueo de Celestia (según las especificaciones de GitHub) es de unos 15 segundos. Dado que esto se conoce, podemos hacer algunas suposiciones sobre cuántos "espacios/bloques" podríamos tener desde el conjunto compartido de coorters hasta la capa DA y los nodos de resumen se cargan en bloques finalizados. En este sentido podemos referirnos a Tendermint o Hotstuff2 optimizados.

Dentro de la misma ranura, podemos enviar múltiples lotes de transacciones, siempre que el diseño incluya mecanismos para que los nodos completos de resumen los procesen de manera eficiente en un solo bloque (dentro de ese período de tiempo y parámetros de tiempo de espera). Esto ayuda a optimizar aún más la creación de bloques y garantiza que las transacciones se procesen rápidamente. Además, las ranuras también se pueden usar para facilitar la elección de los nodos maestros del clasificador. Por ejemplo, puede seleccionar aleatoriamente un nodo maestro de tragamonedas del grupo de participación en función del peso de la participación. Hacer esto de una manera que preserve la confidencialidad y emplee algo como la elección secreta del líder para minimizar la censura es la mejor opción, o incluso una configuración de tecnología de validación distribuida como soluciones como Obol/SSV. La latencia y el tiempo de ranura tienen un gran impacto en los envíos de bloques y las compilaciones del protocolo. Así que tenemos que ver cómo afecta esto al sistema. Bloxroute tiene excelentes puntos de investigación y datos sobre Ethereum en particular. En MEV-Boost, los productores de bloques participantes (validadores o secuenciadores en el caso de Rollup) solicitan GetHeader del relé. Esto les da el valor de la oferta del bloque, que es el valor de un bloque en particular. Este puede ser el bloque de mayor valor recibido cada vez. Para cada ranura, los validadores normalmente solicitan GetHeader unos 400 ms después de que comience la ranura; debido a la gran cantidad de validadores, los relés a menudo necesitan enviar numerosas solicitudes. Esto también es lo que puede suceder con grandes grupos de clasificadores compartidos. Esto significa que necesita la infraestructura para facilitar este proceso.

Los relés también ayudan a facilitar la separación de los constructores y los productores de bloques, al mismo tiempo que verifican que los constructores construyeron los bloques correctos. También verifican que las tarifas se paguen correctamente y actúan como protección DoS. Además, son básicamente los custodios de los bloques y se encargan del registro de validadores. Esto es especialmente importante en la arquitectura de un secuenciador ilimitado, ya que necesita realizar un seguimiento de quién participó y quién no (por ejemplo, la capa de sincronización discutida anteriormente).

Con respecto a los tiempos de bloqueo (es decir, los bloques enviados por los creadores), generalmente ocurren alrededor de 200 milisegundos. En su mayoría, comienzan a ejecutarse antes o después de unos 200 ms, aunque, al igual que GetHeader, existe una variación considerable. Si el constructor envía el bloque a varios relés, provocará un retraso considerable. Bloxroute también analizó lo que sucede cuando los bloques se envían a múltiples retransmisiones. Como era de esperar, la demora para la propagación del bloque a más retransmisiones será mayor. En promedio, el segundo relé tardó 99 milisegundos en pasar el bloque, el tercero 122 milisegundos y el cuarto 342 milisegundos.

Lo que probablemente hemos aprendido en los últimos meses es que RPC es muy importante para las cadenas de bloques. Es una carga enorme sin la infraestructura adecuada, y tener una opción de RPC adecuada también es fundamental. En este caso, RPC es importante para los inversores minoristas que envían sus transacciones a RPC (y al mempool público). Bloxroute realizó una pequeña prueba de 20 transacciones enviadas a varios RPC y midió el tiempo que tardó cada transacción en incluirse en un bloque.

Fuente: Bloxroute Labs

Curiosamente, algunos RPC no incluyen transacciones hasta varios bloques después, según el constructor que gane en el siguiente bloque. Si el RPC envía la transacción a más constructores, entonces la probabilidad de inclusión rápida es mayor. Aunque es posible que los creadores de transacciones aprovechen su posición única en el flujo de pedidos para apuntar a constructores específicos o incluso construir sus propios bloques.

Su rendimiento también es interesante en las estadísticas de rendimiento de retransmisión de Ethereum. Esto nos ayuda a obtener una comprensión más profunda de cómo funciona PBS en un mundo de múltiples validadores/constructores/retransmisores, que es lo que esperamos lograr con la actualización de Rollup. Metrika tiene excelentes estadísticas sobre esto y todos los puntos de datos se deben a ellos.

Es importante tener en cuenta que las ofertas perdidas ocurren cuando se espera que un repetidor haga una oferta, pero no lo hace. Las expectativas de los objetivos provienen de los validadores registrados con un relé en particular para un espacio determinado. Esto no es una falla de relé per se, ni se maneja de esa manera a nivel de protocolo.

Fuente: app.metrika.co

Si ocurre una falla (como un relé que sirve a un bloque inválido) y es responsable, se contará como una falla. Por lo general, estos son poco frecuentes y en su mayoría son fallas de preferencia de registro (es decir, límites de gas o tarifas que no coinciden con los registros para un validador en particular). Aún más raras son las fallas de la capa de consenso, que son inconsistentes con las reglas de la capa de consenso de Ethereum, como ranuras incorrectas o hashes principales no alineados con el bloque anterior, etc.

En términos de latencia (como el tiempo que tarda un validador en recibir un encabezado de bloque creado por un constructor), los datos son muy consistentes. Aunque hay algunos valores atípicos, como que el relé solicitado se encuentre en una ubicación geográfica diferente a la del validador elegido.

Fuente: app.metrika.co

Con respecto a los constructores, el número total de constructores en MEV-boost es de aproximadamente 84, y los tres constructores principales construyen alrededor del 65% de los bloques construidos. Aunque esto puede ser algo engañoso, ya que estos también son los constructores de más larga duración. Los resultados son similares si se reduce el marco de tiempo. El número de constructores activos reales es mucho menor, 35 en los últimos 30 días y 24 en la última semana. La competencia es feroz y, por lo general, gana el constructor más fuerte. Es posible que ya exista un flujo de pedidos exclusivo, lo que solo exacerbará la situación. Esperamos que la distribución de constructores permanezca relativamente centralizada (ya que esta es una carrera por el flujo de pedidos óptimo y la optimización del hardware) a menos que hagamos cambios importantes en la configuración. Si bien no es un problema fundamental, sigue siendo una fuerza centralizadora en la pila y nos encantaría escuchar ideas sobre cómo desafiar el status quo aquí. Si está interesado en profundizar en este (grave) problema, le recomendamos leer los artículos de Quintus sobre flujo de pedidos, subastas y centralización.

Para el rol de constructor en la futura pila de modularidad, estamos bastante seguros (al menos en la configuración del SDK de Cosmos) veremos una configuración de módulos de construcción tipo Skip/Mekatek. Otra solución es una configuración de tipo SUAVE, como una cadena de constructores global específica que brinde servicios de creación de bloques y preferencia de ofertas a cualquier número de cadenas para garantizar PBS. Exploraremos esta solución con más profundidad más adelante y proporcionaremos algunas respuestas a las preguntas que no se abordan aquí.

Con respecto a los relés, recomendamos leer un artículo de Ankit Chiplunkar de Frontier Research y Mike Neuder de la Fundación Ethereum llamado Optimistic relays and where to find them. Esta publicación detalla cómo funcionan los relés en MEV-boost, sus compensaciones actuales y costos operativos, y algunos cambios que pueden aumentar la eficiencia. Curiosamente, ejecutar un relé en MEV-Boost actualmente cuesta alrededor de $ 100,000 / año según las estimaciones de Flashbot.

Determinista

Antes de hablar sobre el determinismo de las cadenas de bloques modulares (como se ven actualmente), echemos un vistazo a nuestro artículo anterior "MEV modular". Tenga en cuenta que esta no es una visión "oficial" ni completa de la finalidad, pero creemos que representa con mayor precisión los matices de la finalidad de Rollup para facilitar la comprensión.

Pending_On_L2: el orden de resumen representa un compromiso flexible de que la transacción de un usuario finalmente se confirmará y finalizará en la capa base de su seguridad.

Finality_On_L2: El secuenciador se comprometió con la función de transición de estado del Rollup y el bloque se agregó a la cadena canónica del Rollup.

Pendiente_On_L1: la función de transición de entrada o salida/estado de la transacción se ha publicado en L1, pero aún no se ha emitido la prueba de validez, o el período de arbitraje aún no ha finalizado; esto requiere Ethereum durante dos épocas consecutivas. Este es el punto en el que la mayoría de los Optimistic Rollups dicen que han alcanzado la finalidad, pero todavía hay un período de desafío arbitrario de 7 días en este punto según el puente de cadena cruzada de especificaciones.

Finality_On_L1: Para un Optimistic Rollup, el período de arbitraje ha finalizado, o una prueba de validez publicada y verificada ha sido confirmada por una mayoría calificada en dos épocas consecutivas.

Ahora, en un resumen de ordenación soberana compartida, esto se ve ligeramente diferente, intentemos explicarlo con un diagrama:

En este caso, ¿teóricamente podemos obtener determinismo en L1 antes que en L2, etc.? Sí, en este caso L2 es soberano después de todo. Esto supone que no hay pruebas de fraude y períodos de impugnación, o que está utilizando una prueba de validez.

Entonces, ¿cómo logramos estos niveles de finalidad? La finalidad del bloque se logra cuando se agrega un bloque a la cadena canónica, que no se puede retirar. Sin embargo, hay algunos matices aquí, dependiendo de los nodos completos o ligeros. En el caso de un bloque ordenado, es determinista una vez que se incluye en un bloque de capa DA. Los bloques (con raíces de estado) se aplican mediante validadores/nodos completos de resumen, lo que les da la garantía de una raíz de estado válida derivada de los bloques ordenados de la capa base. Para el determinismo más allá de los nodos completos (como para clientes ligeros o puentes entre cadenas), debe estar seguro de la validez de esta raíz de estado. Aquí, puede utilizar uno de los métodos que se describen a continuación. Además, otro enfoque es hacer que los validadores sean responsables de la prueba correcta de la raíz del estado (la ruta Optimista), a través de un bono y la subsiguiente prueba de fraude. Además, puede proporcionar una prueba de validez (ZK).

Diferentes formas de lograr la finalidad del bloque:

1. Mediante Prueba de Trabajo (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) y otros métodos probabilísticos.

2. Un método comprobable por medio de suficientes miembros del comité firmando bloques. (por ejemplo, Tendermint 2/3, Hotshot2 u otros tipos de PBFT)

3. Depende del orden de las transacciones/bloques en la capa DA y sus reglas, es decir, las reglas de selección de bifurcación y cadena canónica.

Podemos lograr diferentes tipos de finalidad a través de diferentes mecanismos.

Un tipo de finalidad es la "finalidad suave" (como pendiente), que se puede lograr mediante la elección de un solo líder. En este caso, cada intervalo tendrá solo uno o cero bloques (comprometidos o no), y la capa de sincronización puede asumir con seguridad la secuencia de transacciones en estos bloques.

Otro tipo de finalidad es la "finalidad demostrable", que proporciona garantías más sólidas (esencialmente definitivas) que la finalidad suave. Para lograr una finalidad demostrable, la mayoría de los ordenantes deben firmar un bloque, expresando así su acuerdo de que el bloque es canónico. Si bien este enfoque es bueno, puede que no sea necesario si se ha implementado la elección de un solo líder, ya que esencialmente garantiza el ordenamiento por bloques. Obviamente, esto depende del algoritmo de elección de líder particular que se implemente. Por ejemplo, es una implementación del 51%, una implementación del 66% o un solo líder (preferiblemente elección aleatoria (VRF) y secreta). Si desea obtener más información sobre el determinismo en Ethereum, lea este artículo que recomendamos encarecidamente y el artículo que recomendaremos más adelante para conjuntos de clasificadores ilimitados.

con licencia, semilicencia o sin permiso

Para evitar posibles ataques DoS, se deben establecer barreras económicas para unirse al grupo de pedidos y enviar transacciones a la capa de pedidos. En grupos limitados (número finito de clasificadores) e ilimitados (número ilimitado de clasificadores), se deben implementar barreras económicas para enviar lotes a la capa DA para evitar que la capa de sincronización (propagación de bloques entre clasificadores) se ralentice o sea objeto de un ataque DDoS . Sin embargo, la capa DA en sí misma también brinda cierta protección, porque enviarle datos requiere un costo (da_fee). El depósito de seguridad requerido para unirse al grupo ilimitado debe cubrir cualquier costo adicional necesario para evitar que la capa de sincronización reciba spam. Por otro lado, el margen requerido para unirse a un grupo acotado dependerá de la demanda (equilibrada desde una perspectiva de costo/ingreso).

Para un conjunto ilimitado de clasificadores, no podemos lograr una finalidad demostrable en la capa de clasificación (ya que nunca sabemos exactamente cuántos votantes/firmantes activos hay). Por otro lado, en un grupo acotado de coorters, se puede lograr una finalidad demostrable si la mayoría de los coorters firman bloques. Esto requiere que la capa de sincronización conozca la capa del secuenciador y cuántos secuenciadores están activos en un momento dado, lo cual es una sobrecarga adicional. En un conjunto limitado de clasificadores (por ejemplo, hasta 100), también puede optimizar la cantidad de clasificadores para mejorar el "rendimiento", aunque a expensas de la descentralización y la resistencia a la censura. La importancia de los grupos acotados y las garantías económicas para proporcionar certeza demostrable "rápida" también es determinista.

Los tipos de clasificador ilimitado y clasificador limitado también se reflejan en las cadenas de bloques tradicionales. Por ejemplo, el PoS (Casper+LMD-GHOST) en Ethereum adopta el tipo ilimitado, mientras que la cadena basada en Cosmos SDK/Tendermint adopta el tipo limitado. Un pensamiento interesante es, ¿esperamos ver opciones económicas y de prueba de participación de la comunidad en torno a los pedidos compartidos? En este sentido, hemos visto un movimiento hacia la centralización de algunas entidades (por lo que lo ilimitado realmente no importa si ya tiene algunos grandes proveedores/grupos de prueba de participación). A pesar de que "ocultan" la centralización, después de todo, aún puedes minar si quieres. Desde un punto de vista ideológico, las opciones casi siempre deberían ser ilimitadas, pero recuerda que los principios económicos las hacen muy similares de todos modos. Independientemente de quiénes sean los participantes, la economía de lo que paga debe seguir siendo la misma, como el costo de DA y el costo del hardware (aunque esto puede reducirse por la cantidad de pruebas de participación que asigne y experiencia, y eficiente explotación de la infraestructura). Incluso en el mundo de PoS limitado, hemos visto a un grupo de proveedores de infraestructura convertirse en los validadores más grandes y comunes en casi todas las cadenas. En la mayoría de las cadenas de Cosmos, las dependencias entre validadores ya son muy grandes, y esto ciertamente representa un peligro para la descentralización y la resistencia a la censura de dichas cadenas. Aún así, un hecho muy diferente es que cualquier inversor minorista puede apostar cualquier cantidad con cualquier validador que elija. Desafortunadamente, esto generalmente se asigna a la parte superior de la lista y la vida continúa. Volvemos a preguntar: ¿esperamos un modelo económico similar en un mundo modular? Uno desearía que ese no fuera el caso, pero con la especialización, a menudo necesita la mejor opción, y tienden a ser proveedores profesionales de prueba de participación. También cubriremos estos temas económicos en un capítulo separado más adelante.

Sin embargo, una cosa importante para recordar en todos estos temas es que lo más importante es la autenticación del usuario final, que está disponible para cualquier persona, sin importar dónde se encuentre (incluso en Giza) a través de clientes ligeros y la pirámide DAS).

Fuente: @JosephALChami

Estas son las compensaciones y ventajas de los clasificadores limitados e ilimitados:

Conjunto clasificador ilimitado:

*Cualquiera con suficientes bonos/participaciones puede convertirse en clasificador = alto grado de descentralización

• No es posible tener una elección de un solo líder, ya que el clasificador es esencialmente infinito.
• Es posible la elección de un solo líder a través de VRF, pero es difícil determinar los parámetros de VRF porque no se sabe cuántos ordenadores habrá. Esta también debería ser una elección de líder secreta si es posible para evitar ataques DoS.
• Sin elección de líder = desperdicio de recursos Problema: la construcción de bloques es esencialmente una competencia libre, quien presente el primer bloque/lote válido gana, y todos los demás pierden. · · · Sin certeza demostrable a nivel de ordenante, solo probabilística: por ejemplo, LMD Ghost+Casper
• La finalidad solo se logra después de que los lotes se escriben en la capa DA (limitado solo por el tiempo de bloque subyacente, 15 segundos en el caso de Celestia).
• Los conjuntos ilimitados son "mejores" resistentes a la censura que los conjuntos limitados.

Conjunto acotado de clasificadores:

Esta es una de las soluciones de Ethereum para el determinismo de un solo espacio y tener un comité súper "mayoritario".

• Hay un límite en el número de secuenciadores permitidos en un momento dado.
• Los conjuntos acotados son más complejos que los conjuntos no acotados.
• Se puede implementar una elección de líder único, lo que proporciona una fuerte garantía determinista para la capa clasificadora.
• La capa de sincronización necesita comprender el conjunto de ordenadores para determinar qué bloques son válidos.
• Escribir conjuntos de clasificadores (o cambios de conjuntos) en bloques de capa de liquidación (como reglas de selección de bifurcación), que se escriben en la capa DA, permite que la capa de sincronización determine de forma independiente el conjunto de clasificadores. Por ejemplo, esto es lo que hace el resumen de Sovereign Labs, los cambios de la colección se escriben en una prueba de validez publicada en la capa DA.
• Las sólidas garantías de finalidad de la capa del ordenante pueden no ser necesarias si la capa DA es lo suficientemente rápida (sin embargo, la mayoría de las configuraciones actuales de la capa de liquidación no optimizada tienen al menos tiempos de bloque de más de 10 segundos).

Existe un espacio de diseño considerable sobre cómo se monitorean estos conjuntos de clasificadores y cómo se agregan o eliminan nuevos miembros. Por ejemplo, ¿se logrará esto a través de la Gobernanza de titulares de tokens (entonces, qué tal si muchos tokens y acumulaciones diferentes usan colecciones?). Esto significa que la señalización de cambios fuera de la cadena puede ser posible a través del consenso social (por ejemplo, tome Ethereum como ejemplo). Sin embargo, recuerde que el consenso real en la cadena está claramente establecido y que ya existen sanciones por violar las reglas de consenso.

Mecanismo económico para clasificadores compartidos

La economía de compartir una red de secuenciadores permite algunas opciones interesantes. Como discutimos anteriormente, los validadores en una red de pedidos compartidos no son muy diferentes de los validadores L1 típicos. La red en la que participa está simplemente más optimizada para realizar una tarea, que es recibir intentos (anteriormente PBS) y, por lo tanto, proponer y ordenar transacciones. Al igual que los validadores "regulares", hay componentes de ingresos y costos. En ambos lados de la ecuación, hay mucha flexibilidad en las redes en las que participan los validadores, similar a la L1 regular.

Los ingresos provienen de usuarios o paquetes acumulativos con los que finalmente desean interactuar pagando una determinada tarifa por usar el secuenciador compartido. Esta tarifa podría ser un porcentaje de MEV retirado (ingresar números puede ser difícil de aproximar), transferencias de valor entre cadenas, gas o una tarifa fija por interacción. La solución de ingresos más apropiada podría ser pagarle al ordenante compartido menos valor que el valor adicional obtenido a través del ordenante compartido de Rollup, junto con los beneficios de seguridad y liquidez compartidas. Pero la desventaja de esto es que es difícil cuantificar los beneficios de la descentralización de otra parte de la pila. Sin embargo, a medida que la red de pedidos compartidos se convierte en su propio ecosistema, su capacidad para extraer tarifas puede aumentar. Esto se debe en gran parte a su capacidad inherente para agregarse fácilmente, con ciertas economías de escala. A medida que más paquetes acumulativos y aplicaciones se unan a la red, más y más MEV entre dominios podrán extraerse.

En términos de costo, las redes de pedidos compartidos también tienen opciones competitivas. Pueden financiar fácilmente el uso de su red financiando el costo de publicación en la capa DA, o incluso el costo de interactuar con aplicaciones en Rollup. Esto es similar a la estrategia utilizada por las empresas de la Web 2.0, en las que asume la pérdida inicial en la adquisición (o acumulación) de usuarios, con la esperanza de que sus ingresos a largo plazo superen las tarifas. Otro método más novedoso o criptográfico es permitir que Rollup pague tarifas de DA con su Token nativo. Aquí, la capa de clasificación compartida asume el riesgo de precio entre el Token requerido para publicar datos en la capa DA y el Token nativo de Rollup. En esencia, sigue siendo un costo inicial de clasificador compartido, pero crea consistencia en el ecosistema al obtener el token del "proveedor" (es decir, Rollup). Esto es algo similar a la construcción del almacén que explicamos en el artículo de AppChain, y se pueden usar diferentes formas de DA para reducir costos. Los diferentes niveles de DA ofrecerán precios diferentes debido a la utilización, la capacidad de los usuarios para verificar fácilmente a través de un cliente ligero o simplemente elegir diferentes tamaños de bloque. Finalmente, el ordenante compartido también puede procesar lotes de transacciones antes de publicarlas en la capa DA. En el caso de ZKR, esto puede reducir los costos de transacción a través de una cierta cantidad de saldos de transacción, y en términos de ORU, puede realizar varias optimizaciones de Gas de procesamiento por lotes, que actualmente podemos ver en varios Rollups. Esto reducirá la cantidad de datos que deben publicarse en la capa DA, lo que reducirá el costo de la red de secuenciadores compartidos y aumentará la rentabilidad de toda la red. Esto tendrá el costo de limitar la interoperabilidad y cambiar los tiempos de finalización del bloque (determinismo en L1 como se mencionó anteriormente).

En general, la economía de compartir una red de secuenciadores permite algunas estrategias interesantes de experimentación y arranque. Estimamos que la diferencia clave será el tamaño del ecosistema, por lo que la cantidad de MEV entre dominios es mayor que el aspecto del costo. También recomendamos encarecidamente consultar la publicación de blog del equipo de Espresso sobre pedidos compartidos, que también cubren las compensaciones económicas (y los aspectos positivos) de este tipo de redes. Para mostrar por qué Rollup está motivado para aprovechar los clasificadores compartidos (además de la economía), podemos considerarlo desde la perspectiva de la teoría de la agregación.

Teoría de agregación y clasificadores compartidos

Otra forma de describir las propiedades provocadas por clasificadores compartidos es a través de la lente de la teoría de la agregación. La teoría de agregación se refiere al concepto de cómo una plataforma o agregador integra otras plataformas y sus usuarios de manera sistemática para obtener una atención significativa del usuario. Básicamente, está moviendo el juego de la asignación de un recurso escaso (por ejemplo, espacio en bloque) a la necesidad de controlar un recurso abundante (nuevamente, el espacio en bloque tiene sentido en este ejemplo). La teoría de agregación en realidad agrega proveedores y productos (es decir, Rollup y Blockspace) en una experiencia de superusuario para servir a la base de usuarios agregada. A medida que crece el efecto de red de estos agregadores, esta relación se vuelve cada vez más exclusiva. Cuando esto sucede, la experiencia del usuario se convierte en un diferenciador clave entre configuraciones similares. Si existen incentivos para atraer a nuevos usuarios (como una buena experiencia de usuario y una mejor interoperabilidad), es poco probable que Rollup se traslade a su propia red o a una configuración diferente, ya que los efectos de la red impulsan la incorporación de nuevos proveedores y nuevos usuarios. Esto crea un efecto volante, no solo desde la perspectiva del proveedor y del usuario, sino también desde una perspectiva agregada resistente a la censura.

Fuente: Teoría de la Agregación 2015, Ben Thompson

En el ámbito de los clasificadores compartidos, la Teoría de la Agregación se puede ver como "combinaciones" y federaciones de varios Rollups, todos utilizando verticales similares de la pila, lo que les da poder a ellos mismos y a los demás mientras permite que los usuarios obtengan la misma experiencia.

En teoría, los proveedores (como los paquetes acumulativos) no son exclusivos del conjunto de paneles compartidos, pero en la práctica, el conjunto de paneles compartidos, sus paquetes acumulativos y los usuarios se benefician de una serie de bucles de efectos de red que conducen a un mayor uso de estos paquetes acumulativos. Estos beneficios facilitan la integración de Rollups y usuarios en una pila compartida porque tienen más que perder si no participan. Si bien estos beneficios pueden ser difíciles de ver cuando solo tiene dos Rollups que comparten un solo conjunto de secuenciador, se vuelven más claros a medida que agrega más y más Rollups y Usuarios a la ecuación. Los conjuntos de clasificadores compartidos tienen una relación directa con los usuarios, ya que ordenan sus transacciones, incluso si los propios usuarios no saben que están interactuando con ellos, ya que desde su perspectiva, solo están usando Rollups con los que tienen una razón para interactuar ( Esto significa que los pedidos/clasificadores se vuelven exclusivos). El único costo de estos clasificadores es realmente el costo del hardware para ejecutarlos, siempre que el espacio del bloque y los tokens que lo protegen sean valiosos para el usuario final. Las tarifas de transacción se digitalizan, se pagan con las billeteras de los usuarios y, quizás en el futuro, incluso se pueden extraer a través de avances como hosts de pago en la abstracción de cuenta (sin embargo, alguien tendrá que asumir el costo de DA, orden y ejecución).

Esto tiene más sentido si se considera la empresa anterior de Josh y Jordan en Astria: Google. Desde sus inicios, los productos de Google se han inspirado en la idea de AT, especialmente en la Búsqueda de Google, que se crea modularizando páginas y artículos individuales, haciéndolos directamente accesibles a través de la ventana de búsqueda global.

En el caso de un conjunto compartido de clasificadores, los usuarios que utilizan Rollups (aquellos que comparten un conjunto de clasificadores) tienen costos de adquisición cada vez más bajos, ya que a medida que aumenta el número de proveedores (Rollup), es probable que se sientan atraídos por el conjunto. . Esto significa que, en la mayoría de los casos, un agregador (o multiagregador) tiene un posible efecto beneficioso para todos, ya que el valor de un agregador aumenta con el número de proveedores (siempre que la experiencia del usuario sea buena, por supuesto). Por el contrario, en una sola red serial, la adquisición de clientes se limita a una sola red y sus aplicaciones. Si los usuarios desean usar la aplicación Rollup en un Rollup diferente, tendrán que (dentro de las limitaciones actuales) desconectarse de la red por completo. Esto significa que la permanencia y el valor del usuario no son muy altos, y también significa que en cualquier momento, si otro ecosistema de Rollup es muy valorado (o tiene más incentivos), se puede perder capital.

Resumen de atributos y compensaciones

Atributos

Un clasificador compartido es una red acumulada que agrega y ordena transacciones para múltiples acumulaciones. Estos Rollups comparten el mismo clasificador. Esta combinación de recursos significa que los Rollups obtienen una mayor seguridad económica y capacidades anticensura, que pueden proporcionar rápidas garantías deterministas blandas y transacciones condicionales cruzadas de Rollup.

En este momento, hay mucho ruido sobre la atomicidad entre los Rollups que comparten el mismo conjunto de clasificadores, principalmente en torno a si es atómico por defecto, que no lo es. Sin embargo, si los Rollups en cuestión implementan las funciones de transición de estado (STF) de los demás como dependencias entre ellos, lo que implica transacciones condicionales, entonces pueden lograr la atomicidad entre ellos, siempre que su alineación de ranura/tiempo de bloque (como con los conjuntos de clasificadores compartidos). En este caso, para obtener interoperabilidad atómica, realmente solo necesita ejecutar un cliente ligero de la cadena B en la cadena A y viceversa (similar a cómo funciona IBC). Para fortalecer aún más la interoperabilidad de las medidas de seguridad (más allá de confiar en un solo nodo completo como un nodo ligero), puede implementar ZKP (Prueba de Estado) para resolver el "problema del oráculo" de garantizar la corrección del estado. Esto hará que sea más claro ver si una transacción condicional o algo así ha llegado a un puente canónico de cadena cruzada entre ellos. Las pruebas de fraude también son una posibilidad, pero obviamente dejarían un período de impugnación (lo que significa que un tercero vendría a cubrir el costo de este riesgo). Además, en el caso de clientes ligeros (en lugar de nodos completos), estará al menos un bloque atrasado debido a la espera del encabezado de firma + ventana de prueba de fraude (si corresponde).

Creemos que es más probable que el problema del "puente entre cadenas" se resuelva con clientes ligeros y pruebas de conocimiento cero. El desafío de usar un cliente ligero (en lugar de un contrato inteligente) en este caso es que las bifurcaciones duras (actualizaciones, etc.) en el lado del nodo de resumen deben coordinarse entre sí para mantener su puente en funcionamiento (al igual que IBC necesita habilitar el mismo módulo de estado). Si desea profundizar más en este tema en particular (y cómo abordarlo), le recomendamos que consulte esta presentación.

La razón por la que los pedidos compartidos escalan tan bien es que no ejecutan ni almacenan ningún estado (como lo hacen los pedidos centralizados en la actualidad). Lo mismo ocurre con los propios nodos de resumen (a menos que quieran atomicidad entre ellos, por ejemplo, cliente ligero/prueba de estado). Estos nodos solo ejecutan transacciones que son válidas para su resumen y cualquier transacción condicional entre dominios que sea válida para ellos. Si un nodo de resumen tiene que ejecutar y almacenar el estado de varios paquetes acumulativos, dificulta la escalabilidad y reduce la descentralización (y, por lo tanto, la resistencia a la censura). Esto también refuerza el concepto de separación productor-constructor de bloques (PBS). Aunque todavía necesitamos separar completamente a los constructores y a los productores de bloques. En la configuración actual, los ordenantes son esencialmente constructores y productores de bloques (aunque no ejecutan transacciones). Una configuración ideal podría ser aquella en la que el ordenante existe solo para firmar a ciegas bloques de una configuración de constructor altamente optimizada y garantizar que los bloques se implementen correctamente (al mismo tiempo que proporciona un alto grado de certeza económica y resistencia a la censura para esa certificación). De esta forma, pueden proporcionar un alto grado de seguridad y compromiso para garantizar una finalidad suave a los nodos de Rollup.

Para las transacciones condicionales de resumen cruzado, también existen para ayudar a habilitar los nodos de resumen (ejecutores) para proporcionar raíces de estado intermedio, lo que permite la atomicidad entre los resúmenes.

compensación

El parámetro de tiempo de espera antes mencionado tiene algunos efectos interesantes en MEV y la inclusión de transacciones, según el mecanismo de consenso/nodo maestro del conjunto de pedidos. Por ejemplo, si el parámetro de tiempo de espera se describe como relativamente corto en nuestro documento de cadena específico de la aplicación, es fundamental que los productores de bloques de un conjunto descentralizado de pedidos publiquen los datos lo más rápido posible. En un mundo así, puede ver la competencia entre "validadores" que compiten para ser nodos maestros y ofertan en la capa DA por espacio de bloques hasta que ya no es rentable.

Como Evan cubrió en su publicación original de Lazy Orderer en los foros de Celestia, esperar a que las transacciones se publiquen en la capa base (Celestia en este caso) antes de ejecutarlas es muy ineficiente. Desde ahora, está limitado por el tiempo de bloqueo de la capa base, que es demasiado tiempo para esperar la experiencia del usuario. Para una mejor experiencia de usuario, el pedido compartido proporciona a los informes acumulativos con compromisos deterministas suaves (como se describió anteriormente), que brindan a los usuarios la experiencia de usuario a la que están acostumbrados en los informes acumulativos centralizados existentes (manteniendo la descentralización y una alta resistencia a la censura). Los compromisos suaves son esencialmente solo compromisos con el orden final de las transacciones, pero respaldados por sólidas garantías económicas y una finalización rápida una vez emitidos. Esto también está cubierto por pruebas de fraude (como se menciona en la introducción). La finalidad real real se logra después de que todos los datos de la transacción se hayan publicado en la capa base (lo que significa que L1 en realidad logra una finalidad más rápida). Depende de si Rollup usa pruebas de fraude o pruebas de conocimiento cero para su verificación de prueba de soberanía, lo que sucede en Rollup. La razón para querer esta separación es eliminar el enorme cuello de botella de las transiciones de estado del clasificador. En cambio, los nodos de resumen solo se ocupan de los nodos que son válidos para ellos (lo que significa que tenemos que agregar transacciones condicionales, prueba de estado o validación de nodo ligero para una interoperabilidad adecuada). El determinismo duro todavía depende de la capa base (pero esto puede alcanzar los 15 segundos en Celestia, y también es determinista en Tendermint), lo que nos brinda garantías de determinismo duro relativamente rápidas en Rollup.

Use pruebas de conocimiento cero dentro de la red para optimizar la validación, el tamaño de la transacción (por ejemplo, solo publique las diferencias de estado, pero esto agrega un mayor nivel de confianza hasta que se publique el ZKP). Como se mencionó anteriormente, estas pruebas de estado se pueden usar para permitir que las cadenas/resúmenes conectados tengan una interoperabilidad más fácil y rápida (sin esperar ventanas de desafío).

Una desventaja de estas transacciones condicionales es que es probable que sean más costosas, que requieran costos de verificación y emisión más altos (como el costo de la verificación del encabezado del bloque Tendermint, que está subsidiado en la cadena Cosmos) y agreguen algo de latencia al sistema ( pero aún más rápido que los paquetes acumulativos aislados son mucho más rápidos). La atomicidad lograda por la integración compartida verticalmente puede compensar estos problemas.

Durante la fase inicial de un nuevo paquete acumulativo, el uso de un conjunto compartido de recopiladores tiene mucho sentido, y las ventajas que obtiene como proveedor probablemente superen algunas de las compensaciones que podría verse "obligado" a realizar en el nivel del foso. Sin embargo, para un Rollup ya maduro, donde hay muchas transacciones y actividad económica, probablemente no tenga sentido ceder parte del foso.

Esto plantea la pregunta de si necesitamos una redistribución ponderada económica/transaccional (por paquete acumulativo) similar de los MEV extraídos para inducir a los paquetes acumulativos ya maduros a unirse al conjunto compartido, o incluso evitar que los paquetes acumulativos extremadamente maduros generen su propia red. Todo esto es bastante teórico, pero sin duda es un proceso de pensamiento interesante con respecto a cómo se representarán los MEV en mundos verticales compartidos entre muchos Rollups con diferentes niveles de actividad. Por ejemplo, si un Rollup único que genera valor comparte algunas de estas ganancias con otros (probablemente no genere mucho "valor") a través del Sequencer Set, entonces debe haber más razones para que se trasladen a su propio sistema aislado. Sreeram de EigenLayr también tiene algunas ideas sobre esto, que también recomendamos leer.

Esto se vuelve cada vez más importante cuando se considera que existe un costo técnico considerable para que los buscadores desarrollen nuevas cadenas, por lo que la estandarización y otorgar cierta soberanía sobre "sus" MEV puede ser un buen punto de partida. En la práctica, en MEV, la interfaz dominante (o software) puede ganar, pero en realidad es muy difícil monetizar ese software mediante la ejecución de partes críticas de la infraestructura (lo que lleva a la centralización). A nivel de mercado, lo que proporciona un ordenante compartido es básicamente un mempool común para múltiples proveedores, con una subasta centralizada, lo que podría conducir a una competencia más saludable.

Una preocupación aquí es que si dos acumuladores ejecutan clasificadores en el conjunto compartido, entonces se puede seleccionar un acumulativo con un valor "menos económico" (A) para proponer un acumulativo con una cantidad alta de MEV + tarifas de acumuladores (B). . Desde el punto de vista de Rollup B, esencialmente pierden algún valor que, en el enfoque aislado, mantendrían para sí mismos.

Abordar las compensaciones de interoperabilidad

A continuación se presenta otra nota sobre las ventajas y desventajas que presenta la interoperabilidad y otra forma de resolver algunos de los problemas:

El propósito de la red de pedidos compartidos es proporcionar una garantía canónica para múltiples cadenas, lo que obviamente es una gran ventaja en este caso. Esto se puede combinar con un mecanismo para garantizar transiciones de estado eficientes entre Rollups. Este podría ser un enfoque basado en comités (por ejemplo, PoS), pruebas seguras (el enfoque optimista) o nuestro preferido: un ZKP respaldado por firmas de comités. Debido a que los clasificadores compartidos son "perezosos", solo crean superbloques para clasificar las transacciones de múltiples acumulaciones, y la ejecución de transacciones específicas se deja a un acumulativo específico. Las pruebas de estado (es decir, Lagrange, Axiom o Herodotus, etc.) son todas las soluciones posibles para obtener potencialmente pruebas de finalidad a través de resúmenes soberanos. Incluso puede agregar pruebas de finalidad económicamente garantizada a través de staking pools, EigenLayr, etc. La idea básica es que un clasificador compartido proporciona una garantía económica de pedido, y las pruebas de validez generadas a partir de esta clasificación son deterministas. La idea básica es que los Rollups pueden ejecutar transacciones sincrónicamente entre sí. Por ejemplo, una red de dos nodos de resumen puede saber condicionalmente que ambos historiales de resumen son válidos, a través de ZKP y datos disponibles (datos publicados en una capa DA eficiente). Al publicar un solo prefijo de bloque de resumen de ambas redes A y B, un nodo de resumen puede liquidar dos resumen simultáneamente. Una cosa a señalar es que las transacciones condicionales de acumulación cruzada consumen recursos de dos sistemas separados a través de la ejecución compartida, por lo que es probable que las transacciones atómicas (o síncronas) de acumulación cruzada sean más caras que las transacciones internas de acumulación única.

Sucinto también cubrió las transacciones "atómicas" entre cadenas entre acumulaciones con pedidos compartidos (y probadores de fraude compartidos) dentro del ecosistema de hipercadena de Optimism, que se puede ver aquí. Además, como dice Bo Du de Polymer: "Las transacciones atómicas entre cadenas son como adquirir bloqueos entre fragmentos de bases de datos en escritura".

El futuro de la integración vertical

El posible funcionamiento interno de las cadenas SUAVE ya ha sido explorado en profundidad por Jon Charbonneau et al, por lo que no entraremos en demasiados detalles. Si desea una descripción más detallada, puede consultar su artículo. No obstante, creemos que la integración vertical merece una introducción por separado, tanto para resaltar cuán modulares podemos ser (y por qué) como para presentar algunos de los problemas y preocupaciones asociados con la integración vertical.

Si bien el esquema actual de pedidos compartidos de Astria, Espresso y Radius es muy modular, los pedidos aún actúan como constructores y productores de bloques (aunque en el caso de Astria, no ejecutan transacciones). Astria también ha estado incorporando activamente PBS en su arquitectura desde el principio.

Si PBS no está integrado en el protocolo, hay varias formas de implementar PBS (aunque con diversos grados de descentralización). Productos como SUAVE, utilizan modelos fuera de línea como MEV-Boost o implementan módulos de construcción como los módulos Cosmos SDK creados por Mekatek y Skip.

Vale la pena señalar que ninguno de estos métodos son mutuamente excluyentes. Tienes la flexibilidad de usar varios métodos diferentes y dejar que cualquiera exprese su preferencia. De esa manera, puede tener albaceas compitiendo para llenar esas vacantes. Agregar más opciones siempre es bueno (y consistente con nuestra creencia en la modularidad). Aún así, diferentes implementaciones tendrán diferentes compensaciones. Por ejemplo, en un caso como SUAVE, puede agregar protección de privacidad a través de la tecnología SGX o Crypto, y agregar seguridad económica Crypto a la verdad, en lugar de depender de un generador de PBS centralizado de total confianza. (Gracias a Jon Charbonneau por sus comentarios aquí).

La integración vertical en la cadena de constructores garantiza la equidad sin tomar atajos, agregar latencia y degradar el rendimiento. Por lo tanto, la cadena de constructores debe estar altamente optimizada y puede requerir hardware costoso y potente (lo que conduce a la centralización). Esto significa que para obtener la validación del usuario final, probablemente necesitemos algún tipo de nodos ligeros (aunque tendrían que confiar en los nodos completos), o utilizar una configuración de tipo de prueba de estado para garantizar que la cadena y los usuarios tengan pruebas de que las preferencias de oferta están llenos y los bloques son correctos Construir.

Una cadena como esta puede tener mucho estado (queremos evitar esto), aunque estas transacciones con mucho estado se priorizarán a través de contratos inteligentes. En el caso de una oferta prioritaria, se completa o no se completa (por un período corto de tiempo), ya que las ofertas generalmente solo son válidas por un período corto de tiempo, según la preferencia. Esto significa que podemos implementar una caducidad de estado muy eficiente (y temprana) para las ofertas, lo que nos permitirá podar los datos y mantener la cadena "limpia". Esta fecha de vencimiento debe ser lo suficientemente larga como para permitir que las ofertas se completen primero, pero reducirla demasiado haría que sea casi imposible lograr futuros de espacio de bloques a futuro. No necesitamos actualizar y recuperar contratos de licitación vencidos, ya que no es necesario que existan para siempre (a diferencia de las aplicaciones); esto se puede hacer proporcionando pruebas de estado/almacenamiento cuando se completan las ofertas o mediante soluciones de almacenamiento DAS (como propuestas by Joachim Neu solution) para hacerlo más "seguro" y confiable.

Como se mencionó anteriormente, la necesidad de verificar la “autenticidad” del SUAVE puede estar limitada a los “jusha” (usuarios avanzados) de la plataforma, debido a que la mayoría de los usuarios y clientes del SUAVE pueden obtener altos beneficios económicos de la misma. Esto podría empujarnos a permitir que las personas solo ejecuten nodos completos si desean validar, aunque esto excluye a la gran mayoría de las personas (se podría decir que no necesitan validar). Esto es (en nuestra opinión) lo contrario de Crypto, donde preferiríamos implementar la verificación SUAVE "sin confianza" a través de pruebas de estado o implementaciones ligeras amigables para el cliente.

La razón por la que esto es necesario es que desea verificar que su prioridad de oferta se llenó correctamente y que el bloque se llenó con la información correcta al pagar (para evitar la reagrupación y otros errores). Este es esencialmente un problema de oráculo; de hecho, se puede resolver con una prueba de estado (como es el caso con todos los SUAVE). Sin embargo, estas pruebas estatales plantean otro problema al cruzar cadenas: ¿cómo transmitir esta información a través de las cadenas de manera que no haya sido manipulada u ocultada? Esto puede requerir pasar por una finalidad económica fuerte (como la propuesta por Lagrangian), en cuyo caso puede usar los validadores de restaking de EigenLayr para probar la finalidad y la autenticidad de la cadena, y tener restricciones económicas muy fuertes. Esto trae a colación otro problema (por ejemplo, el contrato de licitación estipula que la "máquina del oráculo", en este caso el re-pignorador, ha designado el token prometido y ha proporcionado un vínculo económico, pero ¿cómo hacemos un consenso entre Externo para recortar esto? Mientras puede escribir criterios de corte, esto no está en consenso, lo que significa que el corte social se explotará a través de contratos inteligentes (que casi nunca es "justo" y puede causar problemas). Este es actualmente el caso en EigenLayr. Uno de los problemas más grandes con la pérdida .

¿A dónde nos lleva esto? Posiblemente, hasta que tengamos una reducción "sin confianza" en la cadena más allá del consenso, las cadenas como SUAVE pueden necesitar sus propios algoritmos de consenso y seguridad criptoeconómica para demostrar las preferencias de oferta y construir certeza de bloque. Sin embargo, esto significa agregar más vectores de ataque criptoeconómico, especialmente si el Rollup el valor de sus componentes básicos es mucho mayor que su propia seguridad criptoeconómica.

Además, todavía hay mucho espacio de diseño en cadenas tipo SUAVE y MEV de dominio cruzado. Aquí hay algunas posibles direcciones de investigación:

• Coincidencia de intenciones y sistemas basados en intenciones
• Optimización convexa en el comercio de activos múltiples
• ADSL
• reasignación de MEV
• Guerra retrasada
• Problema de escalado con un solo conjunto de actores, pero debe construirse para múltiples máquinas de estado de resumen
• Expresión de preferencia

En cuanto a la expresión de preferencia, para interactuar con un contrato inteligente en el EVM, es necesario enviar una llamada de contrato (mensaje) a una función específica en la dirección del código desplegado que contiene la instrucción de ejecución. Si bien los usuarios brindan información, es posible que no tengan control sobre la salida debido a un posible estado.

Por el contrario, los sistemas de diseño de expresión de preferencia (como SUAVE y Anoma) solo requieren que los usuarios firmen las preferencias con un bono, que se paga a los constructores y bloquea a los productores si se cumplen las preferencias del buscador. Para lógica combinatoria compleja, como secuencias de transacciones para buscadores y constructores de MEV, es posible que sea necesario implementar diferentes lenguajes y máquinas virtuales. Este es un nuevo espacio de diseño que ha recibido mucha atención últimamente, especialmente la arquitectura Anoma. Además, recomendamos encarecidamente este breve artículo.