¿Qué es el DEX de acumulación cruzada mencionado por Vitalik?

Cuando las personas todavía están pensando en usar el resumen para aliviar la congestión de la Capa 1, Vitalik ya está pensando en cómo interactuar entre los resúmenes.

Hace 6 días, Vitalik lanzó una propuesta llamada "Cross-rollup DEX", que mencionaba que cuando un paquete acumulativo tiene una implementación de contrato inteligente y el otro paquete no tiene funciones completas de contrato inteligente, los activos se pueden transferir entre los dos paquetes acumulativos. manera centralizada. Hay un poco de sensación de "objetos en movimiento en el espacio".

¿Cómo se logra este proceso? Beep News tradujo la propuesta y las interesantes discusiones entre Vitalik y los miembros de la comunidad de la siguiente manera:

Supongamos que tenemos dos rollups, a saber, el rollup A y el rollup B. Alice quiere transferir una cierta cantidad de tokens del paquete acumulativo A al paquete acumulativo B. Si tanto A como B están totalmente respaldados por contratos inteligentes, en cuyo caso ya hay propuestas sobre cómo resolver este problema de manera descentralizada. Esta propuesta tiene la intención de proporcionar ideas para la situación en la que solo el paquete acumulativo B tiene soporte completo para contratos inteligentes (el paquete acumulativo A solo puede manejar transacciones simples).

Suponemos que la transacción en el resumen A tiene algún tipo de "campo de comentario", si no, podemos usar los bits de orden inferior del valor para enviar como un comentario.

Supongamos que hay un intermediario de transacciones, Iván (en la implementación real, habrá muchos intermediarios para elegir). Ivan tiene una cuenta IVAN_A en el resumen A (tiene control total sobre la cuenta). Ivan también deposita algunos fondos en el contrato inteligente IVAN_B en rollupB.

El contrato inteligente IVAN_B tiene las siguientes reglas: si alguien envía una cantidad de tokens de TRADE_VALUE a IVAN_A, que contiene una dirección DESTINO como nota, luego del bloque MIN_REDEMPTION_DELAY, IVAN_B recibirá una transacción que contiene una prueba de transferencia de token, para poner en cola una transacción como retirar la cantidad de tokens de TRADE_VALUE a la dirección de DESTINO. Los retiros se procesan en el orden de lote e índice en el que se incluyeron las transacciones en el resumen A, sujeto a algún retraso (digamos 1 día).

Presidente de El Salvador: Los usuarios de Chivo Wallet han superado los 500.000: El 14 de septiembre, el presidente Nayib Bukele de El Salvador tuiteó para actualizar la última situación de adopción de Bitcoin en el país: Los usuarios de Chivo Wallet han superado los 500.000, y el 95% de las fallas técnicas han sido Resuelto Todos los fallos restantes se resolverán en unos pocos días. El registro de nuevos usuarios de Chivo aún está suspendido, y la compatibilidad de nuevos modelos de teléfonos móviles también está suspendida, y se darán a conocer dentro de unos días. Los 200 cajeros automáticos Chivo en El Salvador y los 50 cajeros automáticos Chivo en San Francisco, Chicago, Houston y otros lugares de los Estados Unidos están operando normalmente. Chivo Wallet habilitará las funciones de recarga de tarjetas de crédito y débito mañana, y no habrá tarifas de manejo para el consumo de tarjetas de crédito, tarjetas de débito o regalos en cualquier parte del mundo. Además, el monto mínimo de transferencia al transferir bitcoins hacia y desde otras billeteras se ha reducido de $5 a $0,01. [2021/9/14 23:23:37]

Cuando Iván ve que ha recibido fondos en IVAN_A, puede enviar personalmente la cantidad de tokens TRADE_VALUE * (1 - tarifa) a la dirección de DESTINO. Puede enviar la transacción a través del método en IVAN_B, que guarda un registro para evitar que la cláusula de envío automático en el contrato active-kepj la transacción.

La acción esperada es simple:

Alice envía una transacción a IVAN_A, que contiene N tokens y una dirección de nota ALICE_B.

Ivan envía tokens TRADE_VALUE * (1 - tarifa) a ALICE_B a través de IVAN_B.

El segundo paso se puede realizar inmediatamente después del primer paso. Si Ivan demuestra que la diferencia de marca de tiempo entre la segunda transacción y la primera es muy pequeña, entonces el contrato podría incluso establecer una regla que permita que la tarifa sea más alta.

El "peor de los casos" es que Ivan no envía tokens a ALICE_B como se esperaba. En este caso, Alice puede esperar la confirmación de la transacción en el resumen A, encontrar otras formas de obtener los tokens en el resumen B para pagar la tarifa y luego reclamar los fondos ella misma.

BTC superó la marca de los $10 400 y cayó un 2,46 % en el día: los datos de Huobi Global muestran que BTC ha subido a corto plazo, superando la marca de los $10 400, y ahora cotiza a $10 405,81, con una caída intradiaria del 2,46 %. fluctúa mucho, así que por favor haga un buen trabajo en el control de riesgos. [2020/9/5]

La principal limitación de este esquema es que IVAN_B necesita tener una gran cantidad de fondos para garantizar que se pague a todos los remitentes. En particular, suponga: establecemos el límite superior del monto de la transacción en TRADE_LIMIT (por lo tanto, entre las transacciones enviadas a IVAN_A, las transacciones con un valor de transacción> TRADE_LIMIT no son transacciones válidas).

Al mismo tiempo, establecemos que la cantidad máxima de transacciones que se pueden incluir en cada lote de resumen sea TXS_PER_BATCH. Alice puede verificar por sí misma cuántas transacciones están pendientes antes del próximo lote del resumen A, restar este valor de los fondos que ve en el contrato IVAN_B y verificar que la cantidad restante sea suficiente. Dado que los retiros se procesan secuencialmente (que es el objetivo del mecanismo secuencial anterior), Alice no necesita preocuparse de que IVAN_B procese las solicitudes de retiro posteriores antes de retirarse ella misma.

La cantidad máxima que se puede negociar en un lote es TRADE_LIMIT * TXS_PER_BATCH, por lo que el contrato IVAN_B debe contener al menos esta cantidad de ETH, más fondos suficientes para cubrir las transacciones pendientes.

Por ejemplo, suponga que TRADE_LIMIT = 0.1 ETH (el límite superior se puede establecer más bajo, porque una transacción de una cantidad mayor se puede completar en varias transacciones) y TXS_PER_BATCH = 1000. Entonces, IVAN_B necesita tener fondos de 100 ETH.

Tenga en cuenta que hay una tarifa oculta adicional en este diseño, ya que cualquier persona que realice transacciones de más de 0,1 ETH deberá consumir espacio en bloque, que se compara con los requisitos de financiación: si consume la mitad del espacio en bloque, sus requisitos de financiación también se duplican (posiblemente refiriéndose a tarifas implícitas más altas), y viceversa. Para establecer el equilibrio adecuado, parece que las tarifas implícitas deberían ser varias veces menores que las tarifas explícitas que aparecen en el mercado.

Si quisiéramos reducir o eliminar esta sobrecarga, el resumen A podría diseñarse de tal manera que, por ejemplo, el ordenante envíe un mensaje firmado que le demuestre a Alice todos los mensajes aprobados en el lote hasta el momento. Alice sabría entonces que no había ninguna transacción por delante (aunque un ordenante malicioso podría engañar a Alice, a un gran costo).

El diseño anterior se basa en la suposición de que la transacción en el resumen A tiene un campo de comentarios, que Alice puede usar para especificar ALICE_B como la dirección de destino para sus tokens de recepción. Si el resumen no tiene esta función, podemos usar la siguiente solución.

Alice puede registrar ALICE_B en el resumen B del contrato de registro secuencial y obtener una ID asignada secuencialmente (por lo que la ID de Alice es igual a la cantidad de usuarios registrados antes que ella). Establezca MAX_USER_COUNT en el número máximo de usuarios, este valor se puede ajustar hacia arriba con el tiempo si es necesario. Alice puede simplemente asegurarse de que TRADE_VALUE % MAX_USER_COUNT sea igual a (ID de Alice), usando los bits de orden inferior de TRADE_VALUE (este número representa un valor sin importancia) para indicar la cantidad de tokens que quiere intercambiar.

Si Alice transfiere tokens del paquete acumulativo B al paquete acumulativo A, se puede usar un mecanismo similar, pero los roles se invierten:

Alice envía fichas a IVAN_B

Después de un cierto retraso, se le dará derecho a retirar los tokens.

Si Ivan puede demostrarle a IVAN_B que envió tokens a Alice en el paquete acumulativo A, Alice pierde este derecho.

Entonces podemos ver que en este proceso, muchos "Ivans" son en realidad bancos descentralizados, que desempeñan el papel de máquinas de depósito y cajeros automáticos en los dos acumuladores respectivamente, y por lo tanto ganan tarifas de servicio.

Si Ivan es malvado, no hay necesidad de demasiada interacción entre el resumen A y el resumen B, y Alice puede proporcionar una prueba de la transferencia de monedas. Según Vitalik, en el escenario de transferir dinero del paquete acumulativo A al paquete acumulativo B, el paso de proporcionar pruebas se puede realizar directamente en el paquete acumulativo B. Siempre que el paquete acumulativo B pueda obtener el hash de bloque del paquete acumulativo A, puede calcular el hash de bloque de rollup A. registros de transacciones, reclamando así una compensación de Ivan.

En el proceso de reivindicación, Vitalik también dio más posibilidades. Por ejemplo, se puede agregar una "vía rápida" en Ivan B, y Alice B puede vender su ranura de retiro en Ivan B a otros usuarios.

Suponiendo que el usuario se llame Bob, entonces Bob puede transferir el dinero a Alice B primero, y luego, Bob obtendrá los fondos que Ivan B debe transferir a Alice B. Es decir, Bob primero adelanta fondos a Alice para mejorar la experiencia de usuario de Alice.Este proceso puede implicar minería y otros juegos.

Un usuario de Github mencionó si este modelo sería mejor si el intermediario Iván no fuera un individuo sino un grupo descentralizado de fondos. Vitalik dijo que esto implicará la propiedad del grupo de fondos en el resumen A (quizás todos los fondos en el grupo estén controlados por una clave privada), por el contrario, puede ser más razonable utilizar múltiples intermediarios como un "puente de fondos" descentralizado.

Esta es la idea general de DEX de acumulación cruzada. Aunque puede que no haya muchos escenarios aplicables, y algunos escenarios que afectan la seguridad de los fondos pueden no ser considerados, esto nos permite ver algunas posibilidades en la Capa 2. Desde algunas perspectivas, las soluciones de blockchain pueden ser un diseño de reglas.

Tags：

OKX Exchange App Download