¿Qué es el DEX de acumulación cruzada que dijo V God?

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 traduce la propuesta y la interesante discusión entre Vitalik y los miembros de la comunidad de la siguiente manera: supongamos que tenemos dos informes, el informe A y el informe 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.

Vitalik, el fundador de Ethereum, publicó un artículo de investigación sobre la "ruta de terminación de una sola ranura": Jinse Finance informó que el 25 de enero, Vitalik, el fundador de Ethereum, publicó un artículo de investigación sobre la "ruta de terminación de una sola ranura". El argumento infiere que aunque Ethereum ahora tiene más de 280,000 verificadores, todavía es posible reducir el tiempo de confirmación final de Ethereum a un solo tiempo Slot.

Lograr la "terminación de una sola ranura" puede mejorar la experiencia del usuario, reducir las cadenas de reorganización con el propósito de MEV y reducir la complejidad del protocolo y la probabilidad de error. Pero este es un plan a largo plazo, y su orden se clasificará después de PoS, sharding y Verkle tree. En la actualidad, las principales ideas para lograr este objetivo son:

1. Realizado a través del supercomité, es decir, a través de al menos cientos de verificadores del supercomité para completar el trabajo de verificación en un solo espacio en el consenso.

2. Permitir que la gran cantidad de verificadores de hoy desempeñen un papel más rápido y eficiente, es decir, hacer que el proceso de firma agregado sea más eficiente.

Además, existen 4 requisitos específicos para la implementación de la "terminación de un solo intervalo".

1. Intensificar la optimización del trabajo de agregación de firmas 2. Determinar el tamaño del supercomité 3. Investigar, llegar a un consenso y especificar un consenso ideal y una selección de mecanismos de bifurcación 4. Acordar e implementar estos en el camino de implementación. [2022/1/25 9:11:04]

Propuesta

V God: Zcash está descentralizado: el 12 de octubre, V God respondió a los internautas de Twitter que incluso si la Fundación Zcash y la empresa de desarrollo de Zcash, Electric Coin Company, están cerradas mañana, la cadena de bloques de Zcash seguirá funcionando bien. Desde esta perspectiva, Zcash está descentralizado. . [2020/10/12]

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).

V Dios: la agricultura de ingresos de DeFi es como la impresión de dinero loca del banco central: el cofundador de Ethereum, Vitalik Buterin, cree que la agricultura de ingresos de DeFi es tan insostenible como la impresión loca de dinero del banco central para salvar la economía, y es escéptico sobre el DeFi actual forma de auge del mercado. Vitalik Buterin también insinuó: Hasta ahora, la única estrategia que he visto generar tarifas a largo plazo es algún tipo de ataque financiero extraño, tomando liquidez y robando efectos de red de las transacciones de intercambio, y soy pesimista acerca de esta estrategia. Algunas personas piensan que la retórica de Vitalik Buterin puede estar insinuando Uniswap + herramienta de agricultura de ingresos Sushiswap. Vitalik Buterin sugiere que es mejor alejarse por completo de la agricultura de rendimiento hasta que evolucione hacia una industria más sostenible. (descifrado)[2020/9/1]

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-ethdax la transacción. La operación prevista es simple: -Alice envía una transacción a IVAN_A con 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. la

Voice | V God: La próxima ola de aplicaciones de criptomonedas no se basará en exageraciones: según ambcrypto, V God habló sobre el desarrollo del campo de las criptomonedas en una entrevista. También habló sobre la próxima gran ola en el espacio de las criptomonedas en 2019. Desde principios de este año, el valor de la mayoría de las principales criptomonedas en el mercado se ha reducido a más de la mitad. Vitalik cree que el espacio actualmente necesita más "aplicaciones prácticas" técnicas para impulsarlo. Todo el equipo ha estado trabajando duro para lograr un mucho tiempo Construir esa tecnología. Él dijo: “Al igual que la próxima ola de adopción de criptomonedas no se basará en la exageración porque la exageración básicamente ya está aquí, la próxima ola tiene que provenir de aplicaciones realmente útiles y algo que brinde valor a las personas.[ 2018/12/ 1]

Coste de Capital

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 puede contener 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.

V God: "Únete a Google" es una broma: V God (Vitalik Buterin) respondió a los rumores sobre "dejar Ethereum y unirse a Google" en las Diez preguntas de Wang Feng. V God dijo que el incidente de Google era una broma. Obviamente, este correo electrónico provino de un reclutador de Google. Es posible que haya utilizado el algoritmo de reclutamiento de Google. Los programadores que están calificados para sus trabajos enviarán automáticamente correos electrónicos de reclutamiento. [2018/6/23]

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). la

Observaciones

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. la

Transacción del rollup B al rollup A

Si Alice transfiere tokens del rollup B al rollup A, se puede usar un mecanismo similar, pero los roles se invierten: - Alice envía tokens a IVAN_B - después de un tiempo, obtiene el derecho de retirar tokens - si Ivan puede demostrarle a IVAN_B que envió tokens a Alice en el paquete acumulativo A, y Alice pierde este derecho

Resumen

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 hace algo malo, no hay necesidad de demasiada interacción entre el rollup A y el rollup 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. Supongamos que el usuario se llama Bob, luego Bob puede transferir el dinero a AliceB 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：

Mejor intercambio de Bitcoin