Derivados de blockchain: resolviendo el problema por $ 500 billones y ganando el hackatón Consensus 2018

El 11 y 12 de mayo de 2018, el equipo de 8base en la persona de Evgeny Semushin, Gabe Kelly y yo decidimos probar mi fuerza y ​​competir por el premio AlphaPoint en el hackathon Consensus 2018 , que se celebró en Nueva York. En total, 33 equipos participaron en el hackathon, y entre sus patrocinadores se encontraban gigantes como CoinDesk, Microsoft, IBM, Hyperledger y Quorum.



En la competencia AlphaPoint, se requería escribir una solicitud vinculada a un intercambio de criptomonedas, por lo que esperábamos que mi experiencia en un fondo de cobertura fuera muy útil. Queríamos crear algo más que un front-end para la solución blockchain existente. Nuestro objetivo era resolver el problema real mediante la aplicación de las capacidades únicas de la arquitectura blockchain, nuestra propia experiencia en el desarrollo de contratos inteligentes y el conocimiento de la mecánica interna de las finanzas.

Hemos creado un conjunto de contratos inteligentes en la red Ethereum, que le permite crear derivados descentralizados y administrar su suministro en función de la cadena de bloques. Con nuestra solución, cualquier usuario puede convertirse en garante en virtud de un contrato para la venta o compra de cualquier activo ERC20 sin una gestión externa de los requisitos y su cumplimiento. Como resultado, ganamos el premio principal.

Bajo el corte, los matices de la implementación de este proyecto.

El problema

Los derivados son una cosa seria. La capitalización del mercado mundial de derivados se estima en casi $ 500 billones. Si compara esto con el mercado de criptomonedas (alrededor de $ 0,4 billones), efectivo (alrededor de $ 40 billones) y el mercado de valores global (alrededor de $ 70 billones), se hace evidente cuán importante es el papel de los derivados en la economía global. Solo mira esta infografía . Los bancos, fondos y empresas utilizan activamente opciones, futuros, swaps y otros derivados para gestionar el riesgo.



Capitalización de mercado de varios activos:

• Cripto - criptomonedas
• Dinero líquido - efectivo
• Mercados públicos mundiales de valores - mercado mundial de valores
• Derivados - derivados

La principal dificultad con los contratos de derivados es que generalmente utilizan el apalancamiento, ya que los riesgos potenciales son más altos que los montos que las partes realmente tienen. Debido a esto, surge un complejo sistema de acuerdos mutuos, así como requisitos para un margen mínimo y solicitudes de aumento de margen: el nivel de garantía debe permanecer de tal manera que la salida de la transacción siempre sea más costosa que su ejecución.

Todo esto se derrumbó en 2008. Enredados en las complejidades de los contratos de derivados, los jugadores de Wall Street perdieron el control de la situación. Como resultado, el "efecto dominó" funcionó: una oleada de solicitudes para aumentar los márgenes y la incapacidad para cumplirlas condujo al colapso de Lehman Brothers y otros jugadores. El gobierno de los Estados Unidos tuvo que intervenir y actuar como garante de Wall Street en las gigantescas cantidades de contratos pendientes para derivados. Todos sabemos a qué condujo esto ...

Solución

BlockSigma es un conjunto de contratos inteligentes para organizar transacciones en derivados de criptomonedas y administrar tales transacciones. La gestión de garantías se basa en la cadena de bloques, por lo tanto, para garantizar el cumplimiento de los requisitos de margen mínimo para los fondos registrados en el contrato inteligente, no se requiere intermediario.

La principal innovación es la gestión de márgenes basada completamente en la cadena de bloques, sin control centralizado y el flujo de cotizaciones previsto. Para hacer esto, integramos el protocolo Bancor . El protocolo de Bancor ya se está implementando activamente en operaciones de intercambio y operaciones de servicios diarios por millones de dólares. Bancor utiliza una función de precio determinista basada en la relación de oferta y demanda de un activo en particular. En consecuencia, el precio del token básico se puede determinar directamente en la cadena de bloques, lo que le permite formular con precisión los requisitos para el margen mínimo y a tiempo para crear solicitudes para aumentar los márgenes.

La lógica de los contratos inteligentes está diseñada para que el comprador de la opción cierre la posición por la fuerza tan pronto como la garantía en el contrato inteligente caiga por debajo del requisito de margen mínimo obligatorio. La función de determinar el margen mínimo tiene en cuenta el exceso de reserva, lo que crea incentivos económicos para que el comprador de la opción monitoree cuidadosamente la posición y obtenga esta reserva (junto con el exceso) cuando se ve obligado a cerrar en caso de incumplimiento del requisito de margen mínimo. A su vez, el vendedor (garante) de la opción también tiene incentivos económicos para reponer el colateral a tiempo si la transacción no tiene éxito para no perder el exceso de reserva.

Implementación

El código fuente de la solución completa se publica en el repositorio de GitHub .

La solución consta de tres archivos principales de Solidity: BlockSigmaBase.sol, BlockSigmaCall.sol y BlockSigmaPut.sol. BlockSigmaBase implementa una lógica común, mientras que BlockSigmaCall y BlockSigmaPut lo heredan e implementa la lógica de los contratos para la compra y venta, respectivamente.

Así es como se ve la interfaz del contrato:

contract BlockSigmaBase is StandardToken { /** * @dev Constructor * @param _underlyingTokenAddress address of the underlying ERC20 token. * @param _currencyTokenAddress address of the currency ERC20 token. * @param _strike option strike denominated in the currency token. * @param _exp expiration timestamp. * @param _minReserve minimum (excess) reserve * @param _underlyingBancorConverter address of the Bancor converter contract that converts underlying token into BNT. * @param _currencyBancorConverter address of the Bancor converter contract that converts currency token into BNT. * @param _issuer address that is allowed to issue(underwrite) new contracts. */ function BlockSigmaBase(address _underlyingTokenAddress, address _currencyTokenAddress, uint256 _strike, uint256 _exp, uint256 _minReserve, address _underlyingBancorConverter, address _currencyBancorConverter, address _issuer) public; /** * @dev get the required maintenance margin level in currency token. */ function getRequiredReserve() public view returns (uint256); /** * @dev Get price of the underlying token expressed in currency token from Bancor */ function getUnderlyingPrice() public view returns (uint256); /** * @dev Ability for writer to issue(underwrite) new contracts * @param amount how many contracts to issue (in wei). */ function issue(uint256 amount) public onlyIssuer returns (bool); /** * @dev Buyer can exercise the option anytime before the maturity. Buyer deposits currency(call) or underlying tokens(put). */ function exercise() public returns (bool); /** * @dev Writer delivers the underlying tokens(call) or currency(put). * @param to which buyer to deliver to. */ function deliver(address to) public onlyIssuer returns (bool); /** * @dev Buyer can force liquidation if exercise is past due or reserve is below requirement */ function forceLiquidate() public returns (bool); /** * @dev Writer can deposit additional reserve * @param amount how much currency token to deposit. */ function depositReserve(uint256 amount) public returns (bool); /** * @dev Writer can withdraw reserve * @param amount how much currency token to withdraw. */ function withdrawReserve(uint256 amount) public onlyIssuer returns (bool); /** * @dev Is reserve below the requirement? */ function isReserveLow() public view returns (bool); /** * @dev Is option series expired? */ function isExpired() public view returns (bool); /** * @dev Can option be liquidated? */ function canLiquidate() public view returns (bool); } 

Ahora considere los flujos de trabajo básicos para un contrato de venta. Tomemos, por ejemplo, un contrato para la venta de tokens EOS denominados en DAI, que le permite proteger eficazmente los activos en EOS frente al dólar estadounidense. El ciclo de vida de dicho contrato será el siguiente:

1. Cualquier usuario puede publicar un contrato BlockSigmaPut para un tema específico de opciones . Al publicar, debe especificar: (1) el token base, (2) el token de moneda, (3) la fecha de vencimiento, (4) la huelga, (5) la dirección del emisor autorizado para actuar como garante de los contratos en este tema y (6) el requisito de reserva mínima bajo el contrato. Ejemplo: vender EOS antes del 1 de julio de 2018 con una huelga de 10 DAI y una reserva mínima de 2 DAI. Dicho contrato le da al comprador el derecho de vender EOS al garante por 10 DAI en cualquier momento hasta el 1 de julio de 2018. El margen mínimo requerido para cada contrato en este caso será 2 + máximo (0, 10 - precio actual EOS).
2. El emisor especificado actúa como garante de un cierto número de contratos, colocando la reserva necesaria en una ficha de moneda. Para el ejemplo anterior, al precio actual de mercado de EOS de $ 12, el emisor debe colocar 2 + max (0, 10 - 12) = 2 DAI para emitir 1 contrato de opción. Los contratos emitidos se considerarán tokens ERC20 ordinarios, lo que les permitirá cotizar en el intercambio para la venta.
3. El comprador que quiera cumplir el contrato debe dar permiso para transferir la EOS al contrato de opción inteligente y luego llamar al método de ejercicio. Después del inicio de la ejecución del contrato, el vendedor tendrá 24 horas para transferir el pago en un token de moneda. En nuestro ejemplo, el vendedor debe dar 10 DAI por cada token EOS.
4. El emisor da permiso para transferir tokens DAI de su cuenta al contrato de opción inteligente y llama al método de entrega. Un contrato inteligente ejecutado liquida automáticamente la transacción: transfiere DAI y EOS al comprador y al vendedor (emisor), respectivamente, y la reserva se devuelve al vendedor.
5. (Opcional) Si el vendedor no ha realizado el pago dentro de las 24 horas, el comprador puede llamar al método forceLiquidate para devolver el EOS colocado junto con la reserva para cubrir las acciones incorrectas del vendedor.

Ahora considere cómo se implementa la gestión de garantías. En nuestro ejemplo, el precio de EOS en el momento en que se emitió el contrato de opción era de $ 12. Supongamos que ella bajó a $ 9. Entonces, la reserva necesaria será 2 + max (0, 10 - 9) = 3. Esto significa que el vendedor debe depositar adicionalmente 1 DAI por cada contrato bajo el cual actúa como garante. Si el vendedor no puede hacer esto, entonces el comprador tendrá un incentivo económico para cerrar la posición con fuerza:

• Si el comprador ejerce la opción, recibirá un pago de 10 - 9 = 1 DAI por cada contrato (es decir, comprará EOS en el mercado por $ 9 y se lo venderá al emisor por $ 10).
• Por otro lado, si el comprador cierra la posición por la fuerza, recibirá la reserva completa, que para nuestro ejemplo es de 2 DAI por cada contrato.

Esto motiva al comprador a cerrar posiciones con fuerza lo antes posible para obtener ganancias rápidamente.

Dificultades

De ninguna manera es una solución preparada. Su objetivo principal es mostrar las capacidades innovadoras de blockchain y contratos inteligentes para automatizar acuerdos mutuos y administrar la provisión de contratos de opciones. Tradicionalmente, estos servicios son proporcionados por intermediarios, y también requieren trabajo manual y pago de comisiones.

Aunque nuestra solución es muy prometedora a este respecto, vemos una serie de dificultades serias:

• El protocolo Bancor no se ha probado en condiciones estrictas. Utiliza una función de precio determinista que converge para cambiar los precios a través del arbitraje. Todavía no está claro cómo funcionará este mecanismo con una volatilidad mucho mayor y / o con graves brechas de precios.
• El mecanismo de gestión de garantías es inestable ante brechas de precios agudas. Teóricamente, es posible una situación en la que la responsabilidad del garante excede la reserva, por lo que la garantía desea romper la transacción y el comprador no recibe una compensación completa. Para evitar esto, puede aumentar la reserva mínima. Además, puede hacerlo de la manera tradicional: los usuarios del sistema depositan fondos en un "grupo de seguros" distribuido, que cubre automáticamente la escasez en casos excepcionales.
• Dado que Bancor utiliza una función de precio determinista, son posibles varias manipulaciones para aumentar los pagos a un lado del contrato de opción en detrimento del otro. Esto puede suceder solo con una pequeña reserva del convertidor Bancor (es decir, con alta sensibilidad al precio) en relación con la cantidad de posición de opciones. En este caso, la manipulación de precios en Bancor puede resultar más rentable que los pagos de opciones resultantes de dicha manipulación. Sin embargo, este problema es típico no solo para las criptomonedas, sino también para los mercados tradicionales (por ejemplo, prender fuego a una casa para obtener un seguro).
• Incertidumbre en la regulación. No estudiamos aspectos regulatorios, porque hasta ahora nuestro proyecto tiene objetivos puramente de investigación.

Si observa algún problema que no esté en la lista, escríbalo en los comentarios.

Conclusiones

La solución descrita en términos generales refleja los cambios fundamentales que la cadena de bloques traerá a la industria financiera en los próximos años. Además de acuerdos más efectivos y gestión de garantías, esta tecnología introducirá reglas uniformes, transparentes y autocumplidas para todos los participantes del mercado.

Nuestro equipo de 8base no se especializa en las soluciones y protocolos especializados descritos en este artículo. Esperamos un crecimiento explosivo de tecnologías revolucionarias similares en los próximos años en la ola de transformación digital. En consecuencia, nos estamos enfocando en construir el próximo nivel de infraestructura para brindar a los usuarios comerciales un acceso fácil a estas tecnologías y la capacidad de integrarlas en el software empresarial para lograr los objetivos comerciales.

Fuentes de GitHub