En Technical Challenge, describimos una implementación ligera para lograr el comercio entre cadenas. A través del conjunto de transacciones atómicas basadas en HTLC, los pedidos en diferentes cadenas se pueden igualar y liquidar. Sin embargo, la idea tiene varios desafíos que enfrentar, incluyendo
Retraso en el canje Ordenamiento de correspondencia Solución común Costo de tiempo y costo de tarifa.
Con base en el mecanismo y dando una solución a los problemas mencionados anteriormente, proponemos nuestra solución de comercio entre cadenas, Portus.
Recordemos el conjunto de transacciones de las operaciones de Alice y Bob en el Desafío Técnico.
tx_1: Alice -> Bob hashlock (p_A) timelock (t_1) tx_2: Bob -> Alice hashlock (p_A) timelock (t_2)
Los dos problemas principales del conjunto de transacciones antes mencionado son el canje demorado y el requisito del receptor.
El problema con la redención retrasada es que el iniciador de redención es uno de los participantes. La aplicación de un tercero que no sea beneficioso para iniciar la redención puede evitar que la iniciación sea controlada por el participante.
tx_3: Charlie -> Alice hashlock (p_C) timelock (t_1) tx_4: Alice -> Bob hashlock (p_C) timelock (t_2) tx_5: Bob -> Charlie hashlock (p_C) timelock (t_3)
En este conjunto de transacciones, hashlock (p_C) es un hashlock creado por Charlie. Charlie es el tercero que mencionamos anteriormente. Cuando se emiten las transacciones anteriores, Charlie es el que puede iniciar el canje. Alice puede reclamar sus fondos de tx_3y Bob puede reclamar sus fondos de tx_4. Después de que Charlie reclama sus fondos al revelar la preimagen ordenador personal, la acción más beneficiosa para Alice y Bob es reclamar sus fondos. Ni Alice ni Bob pueden beneficiarse al retrasar la redención. Alice, Bob y Charlie juegan diferentes roles en la estructura del intercambio. Alice y Bob son usuarios. Charlie es el operador del intercambio.
Otro problema es el requisito del receptor. Como mencionamos, cuando los usuarios hacen sus pedidos, la contraparte aún no está decidida. Considerando este problema, le damos diferentes definiciones a Alice y Bob: Maker y Taker. Con las tres acciones principales de negociar en un intercambio, la transacción se puede revisar de la siguiente manera.
tx_E: Exchange -> Taker hashlock (p_E) timelock (t_E) tx_T: Taker -> Maker hashlock (p_E) timelock (t_T) tx_M: Maker -> Exchange hashlock (p_E) timelock (t_M)
tx_E es la transacción de finalización coincidente, TXT es la transacción del tomador, y tx_M Es la transacción del fabricante.
Emparejamiento y retirada
Hay varias fases en un proceso completo.
Liquidación de órdenes del fabricante Liquidación de órdenes del agente Procesamiento de correspondencia de intercambio Retiro
Como el fabricante proporciona el pedido inicial, ofrecemos una opción para que cierre el saldo en primer lugar en lugar de esperar en línea. El siguiente procedimiento se completará automáticamente sin el participante del fabricante.
En la fase 1, el fabricante liquida el pedido del fabricante firmando y transmitiendo la transacción del pedido del fabricante tx_M.
En la fase 2, el tomador proporciona la información del pedido y procede con el intercambio. El intercambio luego responde por la transacción de la orden. El tomador resuelve el orden del tomador TXT.
En la fase 3, el intercambio revela la preimagen Educación física para canjear los fondos y crear y transmitir la transacción de finalización correspondiente.
En la fase 4, tomador y creador pueden canjear los fondos en Taker hashlock (p_E) y Creador de hashlock (p_E) por la preimagen revelada Educación física.
Cancelado
Como el fabricante debe tener derecho a cancelar el pedido del fabricante, tx_M debería poder ser reembolsado.
t_M es un momento específico en que los fondos en Exchange hashlock (p_E) timelock (t_M) se puede reembolsar a Maker después de t_M.
Para la transacción del tomador, también se debe considerar el proceso de reembolso. En una situación común, tx_E y TXT se crean solo cuando los pedidos coinciden, por lo que la función de reembolso no debería ser necesaria para TXT. Sin embargo, si el fabricante reembolsa tx_M después de que el pedido coincida (tx_E y TXT se crean) y el intercambio aún no se canjea tx_M al revelar la preimagen Educación física, los fondos del tomador estarán bloqueados Creador de hashlock (p_E). Aunque esta no es una situación normal, aún necesitamos diseñar un mecanismo de reembolso para que el tomador cancele la transacción.
El bloqueo de tiempo establecido en TXT También influye en el tiempo de espera del fabricante. El tomador puede reembolsar la transacción después de t_T. Por otro lado, el fabricante tiene que canjear la transacción antes t_T, o el tomador podría recuperar los fondos.
Después de aplicar la solución del conjunto de transacciones, la mayoría de los problemas que mencionamos pueden resolverse. Sin embargo, se identifican dos problemas.
Cada transacción debe liquidarse en la cadena, lo que requiere mucho tiempo y tarifas. Cada categoría de par comercial requiere la implementación del controlador para resolver el conjunto de transacciones atómicas. En otras palabras, a medida que el sistema expande el soporte en una nueva cadena, el esfuerzo de desarrollo crece en una tasa cuadrática.
Hablando sobre el problema del tiempo y la tarifa, es bastante similar a las dificultades del intercambio descentralizado temprano. Los usuarios proponen sus solicitudes para realizar, reclamar y cancelar un pedido. El administrador de pedidos y el manejador de transacciones atómicas HTLC (HAT) procederán con la solicitud y crearán las transacciones correspondientes a la cadena. Cada pedido debe liquidarse en la cadena principal, y cada pedido debe coincidir mediante un comando que se envía al contrato inteligente.
La solicitud del usuario es procesada por el Administrador de pedidos y convertida a las transacciones correspondientes por el controlador de transacciones atómicas (HAT) de HTLC. Las transacciones se liquidarán en cadenas.
Este problema se puede aliviar de varias maneras diferentes. En DINNGO, resolvimos este problema utilizando una estructura híbrida, que coordina los datos fuera de la cadena y la liquidación dentro de la cadena. Aunque Bitcoin no tiene un recurso tan poderoso para soportar la verificación complicada y el siguiente acuerdo, los desarrolladores implementaron su solución de capa 2 para resolver el problema de escalabilidad. HTLC también se propone bajo esta demanda, Lightning Network.
Cuando el usuario propone un pedido, el sistema de correspondencia procesa la información y se establece de inmediato en la cadena. Cada acción requiere el tiempo de confirmación y la tarifa para procesar. Al aplicar una estructura de capa 2, la información comercial temporal no requiere ser establecida en la cadena principal.
Después de que el gestor de pedidos y el controlador HAT procesen la solicitud, las transacciones se liquidan en un servicio de capa 2 en lugar de liquidarse directamente en la cadena.
Además de reducir el costo y el tiempo de procesamiento, la capa adicional puede resolver el problema de expandir el par comercial a una nueva cadena. Similar al esquema de enrutamiento que se propone en Lightning Network, el pago entre Alice y Bob no requiere que se construya un canal directo entre ellos. Mientras haya una ruta disponible entre ellos, como Alice a Charlie, Charlie a Dave, Dave a Eve y Eve a Bob, la transacción se puede procesar. Por lo tanto, el par comercial no requiere que las cadenas involucradas tengan la misma función de hash (todavía se requiere una ruta disponible), y no cada dos cadenas necesitan construir un sistema comercial independiente.
La tecnología de se está desarrollando a un ritmo rápido. Sin embargo, la idea principal de es evitar que una persona específica lo controle. Esto dificulta la actualización y la migración de una cadena. Estas fronteras construyeron su sistema, ganaron usuarios y demostraron sus valores. Los próximos sistemas se mejorarán resolviendo problemas de diferentes maneras, a fin de satisfacer las necesidades en diferentes escenarios. A la luz de la naturaleza de ejecución descentralizada de cada , puede que no haya una cadena omnisciente en el futuro. En cambio, encontrar una manera de comunicarse entre los existentes, e incluso los próximos, es más razonable. Bajo esta circunstancia, un intercambio es una de las infraestructuras más importantes de la tecnología . Esa es también la razón por la que creemos que no debería ser otro servicio centralizado. Para un servicio descentralizado maduro, diferentes cadenas de bloques pueden proporcionar diferentes recursos para la operación, y la interoperabilidad es la última pieza del rompecabezas. Para lograr la interoperabilidad entre toda la red , Portus tiene como objetivo proporcionar una idea de una solución ligera garantizando la atomicidad del conjunto de transacciones de diferentes cadenas.
