Escrito por Christopher Antonio
Resumen
Wormhole se complace en presentar su propuesta para permitir Lending y Borrowing entre cadenas. El equipo de Wormhole ya ha creado un ejemplo de referencia para Venus y está comprometido a ayudar a desarrollar la solución completa mientras brinda soporte continuo de productos y contratos inteligentes a Venus y su comunidad.
Antes de eso, una introducción rápida a Wormhole: Wormhole es el protocolo líder de interoperabilidad entre cadenas, que permite la mensajería genérica en 15 cadenas de bloques heterogéneas y pronto habrá muchas más. De hecho, acabamos de anunciar nuestro lanzamiento en Aptos devnet.
Desde su lanzamiento en la red principal en agosto de 2021, se han transmitido 1,2 millones de mensajes. Algunos son mensajes regulares (por ejemplo, datos de Pyth Oracle), algunos son puentes de tokens y todo el uso se ha producido de forma orgánica, sin incentivos.
Venus es un proyecto fundamental para el ecosistema BNB. Creemos que Wormhole es la mejor solución de cadena cruzada para Venus por 3 razones clave:
- Diseño e implementación robusta: los detalles importan, particularmente en el contexto de un protocolo complejo que servirá como capa fundamental para el desarrollo futuro y las aplicaciones disponibles. El equipo de Wormhole ha reflexionado profundamente sobre este nuevo paradigma y, posteriormente, ha creado un ejemplo de referencia, específicamente para Venus.
- Modelo de seguridad y descentralización: Wormhole tiene diecinueve guardianes compuestos por los principales validadores de PoS que atestiguan conjuntamente los mensajes. Cada guardián tiene el mismo peso en la gobernanza y el consenso. Wormhole requiere que más de dos tercios de los 19 guardianes obtengan el consenso y pasen la verificación, por lo que asumimos que al menos un tercio de nuestro conjunto de guardianes es confiable.
Wormhole tiene un plan de seguridad integral que consiste en todo el desarrollo open source, uno de los programas de recompensas de errores más grandes ($ 10 millones), que incluye 5 auditorías de calidad 1 (por ejemplo, Neodyme, Kudelski, Ottersec) de su código base completo (auditorías de Certik , Trail of Bits, etc. en curso).
3.Pila de integración simplificada y consolidada: Pyth cruzará la cadena a través de Wormhole; por lo tanto, la integración planificada de Venus con Pyth 2 implica la dependencia de Wormhole. Con esta dependencia establecida, será óptimo usar Wormhole para otros elementos de los objetivos de cadena cruzada de Venus en lugar de introducir un nuevo conjunto de dependencias puente y suposiciones de confianza. La integración de Wormhole también agilizaría el mantenimiento futuro del mecanismo de Oracle, ya que Oracle y la mensajería genérica entre cadenas estarían dictadas por los mismos estándares de interoperabilidad subyacentes.
Consideraciones de diseño
La calidad del diseño importa mucho. Hay una serie de detalles importantes que determinan la dinámica de préstamos y préstamos entre cadenas; pensar y exponer estos detalles de antemano es vital para cualquier propuesta de integración de calidad. Wormhole ha pasado muchos ciclos pensando en este tipo de aplicación de cadena cruzada, y prevemos varias opciones diferentes que compensan la complejidad y la funcionalidad.
El status quo es sencillo: para casi todos los protocolos de préstamos, no hay capacidades de cadena cruzada. Cada cadena está aislada, y los usuarios que desean pedir prestado y prestar a través de diferentes cadenas de bloques deben administrar y monitorear saldos separados en diferentes contratos y protocolos. El prestatario en el escenario a continuación no puede depositar ETH en Ethereum y tomar prestado SOL de Solana.
Status Quo: Cadenas Independientes
¿Cómo puede Venus ser Cross - Chain? Hay una serie de posibilidades y el equipo de Wormhole está abierto a colaborar con Venus para desarrollar implementaciones secuenciales o apuntar al desarrollo de la implementación más compleja desde el principio. Sugerimos dejar esta decisión a los titulares de XVS y animar a los delegados de Venus a debatir los méritos de cada enfoque. Hay dos variantes principales: vaults de una sola cadena y de varias cadenas.
Vault de una sola cadena
En la implementación base, Wormhole podría habilitar grupos de garantía de una sola cadena, donde un usuario puede depositar garantías en cualquier cadena y pedir prestado en cualquier otra cadena y viceversa. Pyth transmitirá simultáneamente los precios al protocolo, lo que permitiría el monitoreo de garantías en la cadena de origen. Los usuarios pagarían el préstamo en la cadena de la que tomaron prestados los tokens y luego retirarían su garantía en la cadena de origen. Ilustramos el flujo de trabajo a continuación.
Vaults multi cadena
Pasando a una versión más sofisticada: un prestatario puede buscar depositar dos o más formas separadas de garantía en dos o más cadenas distintas. Aquí tenemos fondos de garantía de múltiples cadenas en cualquier cadena compatible que permite a los usuarios pedir prestado en una cadena designada. Los usuarios pagarían el préstamo en la cadena de préstamo designada y luego retirarían cada forma de garantía en sus respectivas cadenas. Ilustramos el flujo de trabajo a continuación.
El caso dos introduce una complejidad adicional en el diseño, ya que ahora tenemos que sincronizar entre dos cadenas. Los prestatarios podían tomar prestado de una cadena designada mientras ofrecían garantías en cadenas heterogéneas. Aquí solo necesitamos dar cuenta de la garantía proporcionada en todas las demás cadenas en la cadena seleccionada en la que los usuarios toman prestados los activos, pero todas las demás cadenas solo necesitan realizar un seguimiento de la garantía proporcionada en su cadena respectiva. Luego, el usuario iniciaría el préstamo en cada cadena de préstamo, dividiendo el préstamo total del prestatario por garantía. Este diseño nos permite mantener las liquidaciones en cada cadena de prestatarios, ya que el liquidador podría verificar si la relación entre la garantía de esa cadena y la cantidad prestada que se origina en esa cadena está por debajo de la relación de liquidación.
Ejemplo de referencia
Proporcionamos un ejemplo de referencia sobre cómo las bóvedas de una sola cadena podrían funcionar con BNB y Ethereum. (Tenga en cuenta que esta es una prueba de concepto ligeramente probada y no debe usarse en producción). Permitimos que 1 token ERC-20 se use como garantía en BNB y otro token ERC-20 se tome prestado en Ethereum y viceversa. Luego, este diseño podría adaptarse para integrarse con el código base de Venus existente.
En nuestro ejemplo, un usuario puede depositar BUSD en BNB como garantía y pedir prestado WETH en Ethereum usando las siguientes funciones:
- El usuario primero llama a add Collateral (collateral Amount) en el contrato BNB con la cantidad de BUSD que le gustaría suministrar. Esto transfiere el collateral Amount al contrato y luego este monto se refleja en los activos depositados de su cuenta y la liquidez total de BUSD en el contrato.
- Luego, el usuario llama a initial Borrow (borrow Amount) en el contrato de BNB con la cantidad de WETH que le gustaría tomar prestada en Ethereum. Esto calculará la cantidad máxima de WETH que pueden pedir prestada en función de la relación de garantía para BUSD/WETH y luego enviará un mensaje al contrato de Wormhole en BNB.
- Por último, el usuario llama a complete Borrow (signed Wormhole Message) en el contrato de Ethereum con el mensaje de Wormhole firmado producido en el paso 2. El mensaje de Wormhole se decodifica y se verificará si hay suficiente liquidez WETH para que tomen prestado. Se les transfiere la cantidad prestada especificada en el mensaje y luego esta cantidad se refleja en los activos prestados de la cuenta y la liquidez total WETH en el contrato. Si no hay suficiente liquidez de WETH para que tomen prestado, se enviará un mensaje de Wormhole al contrato de BNB para permitirles retirar su garantía.
Luego, el usuario podría pagar el préstamo WETH en Ethereum y recuperar su garantía BUSD en BNB de la siguiente manera:
- El usuario primero llama a Initiate Repay (borrow Amount) en el contrato de Ethereum con el monto del préstamo que desea pagar. Para pagar el préstamo completo, el usuario también podría llamar a Initiate Repay In Full. Cualquiera de estas funciones transferirá el reembolso al contrato y actualizará los activos prestados de la cuenta y la liquidez WETH total en el contrato. Luego se enviará un mensaje al contrato de Wormhole en Ethereum, indicando cuánto del préstamo se ha reembolsado.
- Por último, el usuario llama a complete Repay (signed Wormhole Message) en el contrato de BNB con el mensaje de Wormhole firmado producido en el paso 1. Luego, el mensaje se decodifica y verifica si el préstamo se pagó en su totalidad. Si se ha llamado a complete Repay dentro del período de gracia definido, los activos prestados de la cuenta se establecerán en cero y la liquidez WETH en el contrato BNB se reducirá por el monto reembolsado. Si no se llamó a complete Repay dentro del período de gracia, se enviará un mensaje al contrato de Wormhole en BNB, identificando que el préstamo no se pagó a tiempo. Si el préstamo no se ha reembolsado en su totalidad, los activos prestados de la cuenta y la liquidez WETH rastreada en el contrato BNB se reducirán por el monto reembolsado.
Aunque no implementamos liquidaciones en nuestro ejemplo de referencia (proporcionamos un flujo de trabajo de ejemplo), el liquidador:
- Se llama a Initiate Liquidation On Target Chain el contrato de BNB que debe determinar si una posición en particular no tiene garantía suficiente consultando la variable de estado de los activos de la cuenta para la cuenta pasada. Si una cuenta no tiene garantía suficiente, este método debería generar un mensaje de Wormhole enviado al contrato de Wormhole en BNB.
- Se llama a Complete Repay On Behalf (signed Message) en Ethereum con el mensaje de Wormhole firmado producido cuando llama a initial Liquidation On Target Chain. Si el prestatario aún no ha devuelto el préstamo cuando llega el mensaje de Wormhole a la cadena de destino, esta función transferirá los fondos prestados adeudados por el liquidador al contrato y enviará otro mensaje de Wormhole al contrato de Wormhole en Ethereum. Al igual que con la función complete Replay, debe haber una funcionalidad de reversión con un mensaje de vuelta a la cadena de origen si el prestatario ya ha devuelto el préstamo.
- Luego llama a complete Liquidation (signed Message) en BNB con el mensaje de Wormhole firmado producido cuando llama a complete Repay On Behalf. La garantía del prestatario se enviaría luego al liquidador menos las tarifas de liquidación determinadas por el protocolo.
- Nota: para que un liquidador vea el estado de las posiciones, una función necesitaría devolver la lista de direcciones con posiciones abiertas y otra función que le permita consultar la variable de estado account Assets para una cuenta en particular.
Integración con Venus
Venus podría potencialmente integrar Wormhole con las siguientes adiciones a la base de código:
- Mantener la infraestructura existente alrededor de los mercados de entrada y salida, ya que estos métodos sólo permiten al usuario intentar tomar prestados estos activos.
- Como estamos rastreando los depósitos en la cadena de origen (en el primer modelo), podemos mantener la función mintFresh tal como está.
- Agregue la lógica de inicio de préstamo en una nueva función borrowFreshXChain que imita la lógica de borrowFresh, pero en lugar de transferir el monto del token prestado al usuario, la función enviaría un mensaje al contrato de Wormhole en BNB como se muestra en la función de inicio de préstamo en el ejemplo de referencia.
- Agregue la lógica completeBorrow en una función completeBorrowXChain que permite que un repetidor/usuario envíe el mensaje de Wormhole firmado el contrato VToken.sol en Ethereum que realmente transferirá los fondos prestados al usuario.
- Agregue la lógica de pago en una función repayBorrowFreshXChain que imita la lógica de repayBorrow pero en lugar de transferir los tokens prestados más los intereses al contrato, la función enviaría un mensaje al contrato Wormhole en Ethereum como se muestra en la función de pago en el ejemplo de referencia.
- Agregue la lógica completeReplay en una función completeReplayXChain que permite que un repetidor/usuario envíe el mensaje de Wormhole firmado el contrato VToken.sol en BNB que devolverá la garantía al usuario.
Descentralización y Seguridad
Wormhole se basa en un consenso PoA con 19 guardianes. Cada guardián ejecuta su propio nodo para cada cadena y tiene el mismo peso en el gobierno y la votación. De los 19 guardianes, Wormhole requiere más de dos tercios para llegar a un consenso y aprobar la verificación; por lo tanto, asumimos que al menos un tercio de nuestro grupo de guardianes es honesto. Nuestro conjunto de guardianes está compuesto por los principales validadores de PoS con miles de millones en delegaciones activas en las cadenas de PoS más grandes: P2P, Chorus One, Everstake, Staked.us, por nombrar algunas.
Sin embargo, a pesar del alto grado de descentralización de Wormhole, seguimos decididos a mejorar nuestras suposiciones de confianza; por lo tanto, estamos realizando grandes inversiones para avanzar hacia un sistema completamente sin confianza basado en pruebas de conocimiento cero .
Solo en los últimos 90 días, Wormhole ha transmitido más de 300k mensajes. Wormhole ha manejado con facilidad algunos de los períodos volátiles recientes en DeFi, facilitando 44k mensajes en solo un día. Nuestro protocolo sin permiso probado y probado se ha ganado la confianza de algunos de los desarrolladores de mayor reputación en el espacio.
Finalmente, reconocemos que Wormhole se ganó algo de prensa por el truco en febrero de este año; creemos que Wormhole es más fuerte por eso. Wormhole, por ejemplo, tiene los programas de recompensas por errores más generosos en criptografía (más de $ 10 millones y contando ), incluidas 5 auditorías de calidad (por ejemplo, Neodyme, Kudelski, Ottersec) de su base de código completa (auditorías de Certik, Trail of Bits, etc. .en marcha ). Wormhole continuará en ambos frentes para mantener altos estándares de seguridad para sus usuarios y protocolos en todos los ecosistemas compatibles.
Dependencia existente
Venus pronto se integrará con Pyth para proporcionar datos de precios de alta calidad a sus feeds de precios y garantizar liquidaciones oportunas y precisas. Debido a que Pyth en BNB implica la transmisión de precios desde Pythnet a través de Wormhole, esa integración ya crearía una integración descendente entre Venus y Wormhole. Con esta dependencia en su lugar, tiene sentido usar Wormhole para otros elementos de los objetivos de cadena cruzada de Venus, incluido el préstamo y préstamo de cadena cruzada. Además de eliminar la necesidad de un conjunto diferente de suposiciones de confianza de puente, la integración de Wormhole también podría optimizar el mantenimiento futuro del mecanismo de Oracle, ya que los requisitos fundamentales de interoperabilidad regirán tanto el Oracle como la mensajería entre cadenas.
Esperamos colaborar con la comunidad de Venus en nuestra propuesta.
Hendrik
- Wormhole Foundation.
Traducción del artículo en inglés: Cross-chain expansion via Wormhole?
