El statu quo de blockchain y los smart contracts en el año 2018. Comparativa de un contrato de seguro tradicional y un contrato de seguro inteligente, a cargo de Carlos Tur Faúndez

AD 63/2018

ABSTRACT:

En el presente artículo se realiza una comparativa entre el contrato de seguro tradicional y el smart legal contract, cuyo funcionamiento tiene su base en la tecnología blockchain. De esta manera, se repasan conceptos básicos sobre la cadena de bloques, y se analizan las diferencias entre la contratación tradicional y la realizada mediante la ejecución del smart contract, todo ello con ejemplos ilustrativos y una conclusión final a modo de reflexión.

PALABRAS CLAVE:

  • Smart contracts
  • Blockchain
  • Seguros
  • Criptomoneda
  • Ethereum
  • Contrato de seguro inteligente
  • Contrato de seguro
  • Oráculo

Iniciamos el mes de septiembre del año 2018, y podemos afirmar, sin ningún género de dudas que, a día de hoy, conceptos como criptomoneda, blockchain (o DLT) y, tal vez en menor medida, smart contracts, no son desconocidos para la generalidad de los juristas que desarrollan su labor en el mundo de las nuevas tecnologías. Llegados a este punto consideramos, sin embargo, que se hace imprescindible una profunda reflexión sobre los avances que se han producido en la materia y sobre la posibilidad de que dicha tecnología tenga aplicación real en el mundo de los negocios jurídicos, de tal forma que pueda vislumbrarse la adopción global de la misma por administraciones, empresas y particulares. A tal efecto, hemos considerado adecuado observar, de forma paralela, un contrato de seguro tradicional, que bien podría suscribirse mediante la firma de un documento entre una compañía aseguradora y un particular y un contrato legal inteligente (smart legal contract).

Un contrato de seguro, está perfectamente definido en el artículo 1 de la Ley 50/1980, de 8 de octubre, que textualmente dispone lo siguiente:

El contrato de seguro es aquel por el que el asegurador se obliga, mediante el cobro de una prima y para el caso de que se produzca el evento cuyo riesgo es objeto de cobertura a indemnizar, dentro de los límites pactados, el daño producido al asegurado o a satisfacer un capital, una renta u otras prestaciones convenidas.

Sea pues un simple contrato de seguro en el que los pactos son los siguientes:

  • RIESGO OBJETO DE COBERTURA: retraso  superior a 2 h en salida del vuelo de una línea aérea del que el asegurado ha adquirido un billete.
  • PRIMA 20 €
  • INDEMNIZACIÓN = PRIMA * 10 = 20 X 10 = 200 €

Analicemos las diferencias entre la contratación tradicional y la realizada mediante la ejecución del smart contract anteriormente descrito.  

Sin profundizar en exceso en las particularidades formales, previa suscripción por ambas partes del contrato mediante aceptación de sus términos y condiciones:

  • El asegurado debe transferir el precio de la prima (20 €)  a la cuenta designada por el asegurador.
  • Llegado el día del vuelo, el asegurador verificará por los medios que estime más oportunos si se ha producido el retraso en los términos pactados.
  • En caso de que dicho retraso se haya producido transferirá el importe de la indemnización (200 €) a la cuenta corriente designada por el asegurado.

Como podemos observar el contrato se basa, exclusivamente, en la confianza depositada en el asegurador.  Es decir que el asegurado contrata con éste, porque considera que su solvencia está contrastada y por ende, considera predecible el cumplimiento de las prestaciones. En caso de incumplimiento por parte del asegurador, la solvencia económica determinará el recobro, por parte del asegurado, de las sumas adeudadas en el supuesto de que se ejercitasen acciones ante los órganos jurisdiccionales.

No cabe decir lo mismo del asegurador que se limita a cobrar por adelantado el importe de la prima y no asume nada más que el riesgo estadístico de que se produzca el riesgo indemnizable.

Antes de entrar en el análisis del smart contract que se integrará en nuestro contrato de seguro inteligente,  consideramos oportuno exponer, si bien de forma breve, una serie de conceptos que consideramos fundamentales:

Blockchain o cadena de bloques: la cadena de bloques es una base de datos apoyada en tecnología peer to peer  y, por tanto, compartida por múltiples nodos, en la que se registran bloques de información. El término nodo se refiere a cualquier ordenador que, previa descarga y ejecución, en el mismo, de uno o varios programas, se convierte en parte integrante de la red descentralizada de la cadena de bloques, e inmediatamente pasa a conservar una réplica exacta de todos los registros integrantes de la misma. La “copia completa del libro de registro”, se actualizará, en lo sucesivo, cada vez que el nodo se conecte a Internet. La cadena de bloques presenta las siguientes características:

  1. Consenso: para que la información contenida en un bloque sea considerada como válida, todos los participantes deben estar de acuerdo.
  2. Origen: todos los nodos pueden verificar el momento en que determinada transacción se ha registrado en la cadena de bloques.
  3. Inmutabilidad: ningún participante en la cadena de bloques puede manipular la información una vez ha sido registrada.

Los smart contracts son secuencias de código y datos, que se almacenan en la cadena de bloques. La actual acepción, se debe al uso indebido de la misma por parte de los creadores de la plataforma Ethereum, y somos conscientes de que es inadecuada e induce a error. Sin embargo, a la vista de la plena aceptación de la misma en la comunidad internacional de desarrolladores, consideramos que es poco realista la proposición de una definición distinta.

Una vez aclarado que un smart contract no es un contrato sino un programa informático, se hace oportuno establecer una nueva clasificación, distinguiendo así entre los SC con relevancia jurídica y aquellos otros que carecen de ella.

Veamos el siguiente ejemplo:

Captura de pantalla 2018-09-13 a las 0.30.30.pngSe trata de una simple prueba de código y tan solo sirve para visualizar una cadena de texto, por lo que carece de interés para los juristas.

Existen otros ejemplos mucho más complejos y que sin embargo carecen de relevancia jurídica y que pueden servir al ocio u otras finalidades, no obstante lo anterior, una parte relevante de los smart contracts cumplen la finalidad de servir como instrumento para la ejecución de determinadas prestaciones contractuales, tal es el caso del ejemplo que se expone a continuación:

Captura de pantalla 2018-09-13 a las 0.32.10.pngSomos plenamente conscientes de que el programa anteriormente expuesto es extremadamente básico y que son múltiples los ejemplos que pueden hallarse en el repositorio GitHub,  verificados y funcionales, sin embargo, en aras a una mayor claridad conceptual, hemos preferido optar por un ejemplo sencillo (el programa tiene una finalidad meramente didáctica y no ha sido auditado su funcionamiento, por lo que puede contener errores).

A diferencia del smart contract holaMundo al que nos hemos referido precedentemente, el que hemos denominado seguroBasico es jurídicamente relevante en tanto que  ha sido creado con el objetivo de producir efectos jurídicos, siempre y cuando se den las condiciones necesarias para su ejecución automática.  

Sin perjuicio de lo expuesto, no habrá contrato hasta tanto no concurran las condiciones establecidas en el artículo 1261 del Código Civil, esto es, consentimiento, objeto y causa, por lo que, a tal fin,  deberemos proporcionar a las partes las herramientas necesarias.

Es preciso indicar que, gracias a la bibilioteca denominada Web3 JavaScript API, pueden desarrollarse aplicaciones web descentralizadas denominadas Dapps, perfectamente accesibles para cualquier ciudadano medio y en cuya parte no visible (back end), existe un smart contract que se ejecuta automáticamente, de forma que las partes puedan prestar libremente su consentimiento sobre los términos y condiciones.

Podemos definir, por tanto, los contratos legales inteligentes como aquellos contratos celebrados a través de una página web o una aplicación móvil  accesible para las partes cuya forma está constituida por la interfaz de usuario de la aplicación externa o Dapp (front end) y uno o varios programas autoejecutables (smart contracts) residentes en la cadena de bloques (back end) con capacidad para interactuar recíprocamente y con los usuarios a través de dicha interfaz.

Volvamos, nuevamente al smart contract seguroBasico con el fin de obtener una descripción en lenguaje humanamente comprensible de su contenido:

  • Por tratarse de un smart contract (programa) creado en Solidity e integrado en la blockchain de Ethereum, presenta características poco comunes:
    • Dispone de un número de cuenta o address identificado con un código alfanúmerico hexadecimal que siempre irá precedido por 0x (un  ejemplo podría ser 0x4e632D85C1B34955c69AC7b6e7BE8dc7297a5EfE).
    • Dicha cuenta tiene ciertas capacidades entre las que se encuentran la capacidad de almacenar Ether (criptomoneda de la plataforma Ethereum) u otras criptomonedas o tokens compatibles con el estándar ERC20, o transferirlas a otras cuentas si así está programado en el smart contract.
    • En el modelo de ejemplo, no podemos observar la cadena alfanumérica o número de cuenta. Ésta le es asignada, automáticamente, por la Red Ethereum tan pronto como el smart contract se introduce en la cadena de bloques mediante las oportunas instrucciones. En  el sitio web https://etherscan.io/ pueden verificarse las direcciones (address) de todos los smart contracts existentes.
    • Con un poco de esfuerzo adicional, podemos constatar que en las primeras líneas del programa se establecen otras variables precedidas de la palabra address, y que se corresponden con las cuentas corrientes pertenecientes al asegurador, al asegurado y al oráculo al que nos referiremos más adelante.  La única cuenta conocida en el estadio inicial del programa es la de éste último, puesto que las demás se harán patentes tan pronto como el smart contract inicie su ejecución.

Con el fin de no aburrir excesivamente al lector con cuestiones técnicas, trataremos de explicar de forma simple el funcionamiento del programa:

1) El asegurador es el encargado de iniciar la ejecución del programa, para ello debe llevar a efecto las siguientes acciones:

  • determinar el importe de la prima del seguro (en Ether).  20 €, equivalen a 0,135 Ether a las 18:18 horas del 12 de Septiembre de 2018.
  • depositar en la cuenta del contrato el importe de la indemnización que, como antes hemos indicado, equivale a 10 veces el importe de la prima, esto es 1,35 Ether (200 € en el día y hora antes indicado).

2) Tan pronto como ocurra lo anterior, el programa identifica:

  • Que la address asegurador, corresponde al número de cuenta que ha transferido el importe de la indemnización siempre y cuando haya transferido el importe de 1.35 Ether.
  • Que el precio de la prima es de 0,135 Ether.
  • Que el importe de la indemnización a satisfacer es de 1.35 Ether, si se produce el siniestro.
  • Que el saldo depositado en su propia cuenta (address) es de 1.35 Ether.

3) En ese preciso instante, el smart contract queda “a la espera” de que el asegurado transfiera desde su cuenta (address) en Ethereum, el importe de la prima (0.135 Ether)  e identifique el número de vuelo, de forma que:

  • Si dicho importe no es transferido, la cantidad depositada en la cuenta será restituida a la cuenta (address) del asegurador.
  • Si dicho importe es transferido (se requiere para poder hacerlo que se identifique el número de vuelo). El smart contract permanece a la espera de que el oráculo determine si el vuelo se ha retrasado o no por un tiempo superior a 2 horas:

. Si la respuesta del oráculo es SI, el smart contract transferirá al asegurado la indemnización y al asegurador el importe de la prima.

. Si la respuesta del oráculo es NO, el smart contract transferirá al asegurador el total del saldo de la cuenta.

Aun cuando, tal y como hemos manifestado, la secuencia anteriormente expuesta tiene como finalidad automatizar la ejecución del pago de la indemnización en un contrato de seguro, resulta obvio que no es un contrato, puesto que, si bien es cierto que puede vislumbrarse su finalidad jurídicamente relevante, no representa, per sé, ningún acuerdo de voluntades.

La “inteligencia” de los smart contracts es limitada. Con ello queremos significar que tales programas pueden verificar la información que existe en la cadena de bloques, pero no disponen de recursos para buscar información en el mundo real y discernir cuál es correcta y cuál no lo es. En consecuencia, tampoco pueden determinar, sin la colaboración de agentes externos, si una determinada condición se ha cumplido.

Para conocer si se ha producido el riesgo indemnizable, es necesario conocer si el retraso se ha producido realmente y el único modo posible es mediante el acceso a una  a una fuente externa (por ejemplo, un sitio web confiable) en la que se hagan públicas las incidencias de las aeronaves. Los oráculos cumplen dicha función. Se trata de empresas externas respecto a la cadena de bloques que pueden facilitar al programa cualquier tipo de información y que han creado un software propio compatible que les permite interaccionar con el smart contract. El desarrollador del smart contract deberá implementar en éste el código propuesto por el oráculo y establecer, además, como condición para la ejecución (en uno u otro sentido) el sentido de la respuesta del oráculo (una vez más, en aras a la brevedad, no hemos incluido el código necesario para que un verdadero oráculo pueda ser “llamado”). Cabe destacar de entre los más relevantes a día de hoy http://www.oraclize.it/, siendo un ejemplo de entre los descentralizados https://chain.link/ que a nuestro juicio, proporciona, en mayor medida,  la confianza que le es exigible a un smart contract.

¿Existen a día de hoy aplicaciones web (Dapps) que nos permitan la creación de contratos inteligentes? Lo cierto es que pueden hallarse dos sitios web en los que se han desarrollado soluciones, aparentemente, muy similares.

Etherisc (https://fdd.etherisc.com/) es una aplicación web a través de la cual podemos contratar online una póliza que asegure el riesgo derivado del retraso de un determinado vuelo. Pertenece al grupo ORACLICE, y por ende, parece previsible cual es la entidad (oráculo) que proporciona la información de los vuelos. Sin embargo son varias las cuestiones que llaman nuestra atención:

  1. Al pie de la página web, podemos hallar un enlace a su código fuente en el repositorio Github, lo que genera apariencia de seriedad y transparencia. Sin embargo no existe modo alguno de comprobar que son, realmente esos,  los smart contracts que se ejecutan. Tampoco existe forma posible de averiguar cómo se establecen los mecanismos de interacción entre la página web y dichos programas.
  2. Como hemos explicado, la cadena de bloques, no es capaz de comunicarse con el exterior sin un oráculo, de la misma manera que no se puede operar en Ethereum con moneda de curso legal. Todas las transferencias y depósitos realizados tanto en las cuentas de los smart contracts, como en las particulares deben efectuarse en Ether. No existe información disponible que explique cuáles son las funciones (javascript) que se han ejecutado en la página web, para que se abra una address, a nuestro nombre, en la plataforma Ethereum, ni como el importe en Euros que hemos satisfecho mediante nuestra tarjeta de crédito, se ha transformado mágicamente en Ether.
  3. Desconocemos total y absolutamente si la verificación del retraso del vuelo, la realiza un oráculo o si más bien (permítame, el lector, la expresión) “hay un hombre detrás de la pantalla del ordenador” que hace las búsquedas.

En definitiva, existe una persona física o jurídica en la que nos vemos obligados a confiar, por lo que resulta irrelevante si se utiliza o no la cadena de bloques de forma accesoria.

El conocido grupo asegurador AXA, nos ofrece un servicio similar a través de su sitio web https://fizzy.axa/en-gb/. Si investigamos los contenidos de la pestaña Q&A, nos encontramos con una aseveración muy prometedora: “nuestro smart contract está alojado en la cadena de bloques Ethereum”. Pues bien, hemos verificado el smart contract que está publicado en la dirección indicada (https://etherscan.io/address/0xe083515d1541f2a9fd0ca03f189f5d321c73b872#code) y hemos podido constatar que se trata de un simple “almacén” de incidencias, y que por ende no dispone de una sóla función que permita transferir Ether al asegurado.

Es obvio que toda la operativa del negocio se desarrolla fuera de la cadena de bloques. Se trata de una simple póliza de seguros online.

CONCLUSIONES:  

Tal y como se ha expuesto,  los contratos de seguro tradicionales se basan en la confianza que el asegurado deposita en el asegurador, por tratarse de una entidad de reconocida solvencia económica que normalmente cumple sus prestaciones contractuales.

Para que un contrato legal inteligente (en este caso un contrato de seguro inteligente) sea confiable el pago de la indemnización debe realizarse, automáticamente y sin intervención alguna de la aseguradora, si se produce el hecho dañoso. A día de hoy, la tecnología blockchain avanza a buen ritmo, pero sería deshonesto afirmar que podemos contratar un seguro que cumpla con tales condiciones. Existen algunos escollos que deben ser esquivados y proyectos que discurren por el buen camino. Ejemplo de ello son los siguientes:

  1. https://ipfs.io/ y https://swarm-gateways.net/bzz:/theswarm.eth/  “Hosting” de sitios web, descentralizado, en redes P2P. El objetivo es evitar la caída del servidor en el que la web que sirve la aplicación genere una denegación del servicio.
  2. https://chain.link/  Se trata de un oráculo descentralizado. No es un sólo nodo el que proporciona la información desde el exterior de la cadena de bloques sino múltiples modos. Con ello estamos evitando la posibilidad de una interrupción del servicio por caída del servidor del oráculo, o lo que es peor, que se “deje llevar” por intereses oscuros o deshonestos.
  3. https://www.uport.me/ Permite identificar a las partes contratantes dentro y fuera de la cadena de bloques respetando el contenido del RGPD.
  4. La creación de una criptomoneda estable interbancaria, podría cerrar la brecha entre el dinero FIAT (o de curso legal) y la criptomoneda residente en la cadena de bloques.  Existen iniciativas como la de Union Bank AG, de Liechtenstein.
  5. La creación de una criptomoneda de curso legal emitida por el Banco Central Europeo con paridad frente al Euro, proporcionaría, indudablemente, el impulso definitivo. Se han elaborado diversos informes que defienden  su instauración alguno de ellos bastante prometedores. Véanse sitios web: https://www.bankofengland.co.uk/-/media/boe/files/working-paper/2018/competition-for-retail-deposits-between-commercial-banks-and-non-bank-operators.pdf?la=en&hash=79C52E7C196677080CA3D1FA2F9ADEC1187BFB5B y https://www.finextra.com/finextra-downloads/newsdocs/ipol_stu.pdf )

Lamentablemente, las palabras smart contracts y blockchain han sido utilizadas con excesiva frecuencia y con escaso celo. Produce cierto hartazgo, el observar como abundan los vendedores de la panacea universal y como una legión de incautos la compran, víctimas de su ignorancia o de su imprudencia.  Debemos dejar que la ciencia avance y que los investigadores tomen el tiempo necesario para ello, aplaudiendo a quienes obtienen resultados satisfactorios. Del mismo modo, debemos comprometernos a criticar, enérgicamente, a todos aquellos que, bajo el estandarte de la innovación y las nuevas tecnologías,  pretenden obtener provecho económico del desconocimiento ajeno.

Palma de Mallorca, 13 de septiembre de 2018

 



GXnkJRc5_400x400.jpg

Autor: Carlos Enrique Tur Faúndez

Abogado, Master U. Salamanca Derecho TIC. Profesor en Facultad de Derecho de la UIB. #blockchain Autor de la monografía: ” #smartcontracts análisis jurídico”

Twitter: @TURFAUNDEZ_eOMS

Web: eoms.eu

 



 

2 comentarios sobre “El statu quo de blockchain y los smart contracts en el año 2018. Comparativa de un contrato de seguro tradicional y un contrato de seguro inteligente, a cargo de Carlos Tur Faúndez

  1. Los contratos inteligentes son desarrollados por Nick Szabo como un software autoejecutable que permite la liquidación cuando se cumplen ciertos parámetros, ni más ni menos. El nombre Smart Contract hace referencia a que son acuerdos entre partes que puede llevar confusión por su traducción literal, pero nada más lejos de eso, nadie dice que tenga implicaciones jurídicas.
    Decir que los desarrolladores de Ethereum lo implementan de una forma indebida es un error completo y absurdo, fruto de alguien que desconoce el campo informatico. Ethereum implementa la EVM que permite ejecutar Smart Contracts para Dapps, DAO y otros, permitiendo la ejecución de un código con determinados parámetros. Básicamente tenemos las condiciones establecidas en el software que se basan en una serie de inputs que cuando se cumplen ofrecen uno o varios outpus.
    Los Oráculos no son más que Smart Contracts que realizan llamadas externas a webs confiables y obtienen datos introduciendolos en la blockchain. Una Dapp puede llamar a un Oráculo para que le de un valor o verificar un dato. Lo que denominas empresas externas que hacen la función de oráculos, son empresas de desarrollo que crean un software de Oráculo que permite realizar llamadas. Los Oráculos presentan el problema de que requieren mucha potencia de computo, mucho espacio y tienen mucho consumo de Gas, así que son bastante ineficientes por el momento.
    Que se quiera disertar si un Smart Contract entre partes pueda tener un valor jurídico-legal me parece muy bien pero la idea básica es un software autoejecutable con unas condiciones establecidas entre dos partes o bien como elemento para construir otros elementos. Cabe destacar que los Smart Contracts no se implementan por primera vez en Ethereum, sino que ya estan presentes desde el minuto cero en Bitcoin, lo que hace Ethereum es mediante Turing Completo ampliar las funciones de estos y lo que pueden hacer. NEO, Tron, NEM y tantos otros implementan Smart Contract para crear ICO y Dapps.

    Me gusta

    1. Los smart contracts, fueron definidos por Nick Szabo (que no desarrollados). Sus artículos originales están publicados en la web y son accesibles en los siguientes enlaces:
      http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html
      http://ojphi.org/ojs/index.php/fm/article/view/548/469.
      Como Vd. mismo puede comprobar en los textos originales, la idea de Nick Szabo (vinculada a la máquina de “vending”) SÍ atribuye valor contractual a los smart contracts.

      Si Vd. ha leído con atención mi artículo, como así parece, observará que no critico la implementación de los smart contracts en la EVM, sino el uso indebido del término contrato (contract) que se utiliza para todos los programas que se despliegan en dicha cadena de bloques.
      Defender el uso del término “contract” o contrato para las secuencias de código Solídity que se ejecutan en la EVM, induce a error y pone de relieve un profundo desconocimiento del Derecho y de sus instituciones más elementales. Otras plataformas como Hyperledger, han preferido descartar el término y bautizar el código que se ejecuta en su cadena de bloques como chaincode.

      Es cierto que un oráculo requiere un smart contract que permita la comunicación con una API externa. No es menos cierto, sin embargo, que por regla general, este servicio se presta por terceras personas, que se supone confiables.
      Para evitar el problema de la centralización implícita en el hecho de que sea el propio proveedor de la Dapp el que establezca la comunicación a través de Web3 js con la API externa, estimamos más adecuada a los propios fines de la blockchain la creación de oráculos descentralizados, o si Vd. lo prefiere “plataformas descentralizadas que prestan el servicio de oráculo” como https://chain.link/ .

      Al fin y al cabo, si alguien está proporcionando un servicio presuntamente descentralizado y me exige que confíe en él ¿qué aporta la cadena de bloques? (¿Cómo, el usuario, puede tener la certeza de que no ha habido manipulación de datos?)

      Me consta que Ethereum, no es la única plataforma que implementa smart contracts, sino aquella que a día de hoy tiene un uso más generalizado. Para el caso de creación de tokens, puede Vd consultar las estadísticas y verificar cuántos han sido creados con el stándar ERC20 y cuántos con Waves, NEM (mosáic) u otras.

      El lenguaje Script, de Bitcoin, no es Turing complete, como Vd. bien dice y no fue creado inicialmente para la implementación de smart contracts, si bien es cierto que, con limitaciones, algunos OP_CODE, permiten tal carácterística. Un ejemplo en este enlace:

      https://bitcoinmagazine.com/articles/yes-bitcoin-can-do-smart-contracts-and-particl-demonstrates-how/
      Un cordial saludo.

      Carlos Tur.

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s