Comparación entre las diferentes redes para desplegar Smart Contract: Ethereum, Hyperledger Fabric y Corda

45

Con este artículo, ofrecemos un breve análisis de las diferencias más notables entre las tecnologías de contabilidad distribuida (DLT) para desplegar Smart Contract: Hyperledger Fabric, R3 Corda y Ethereum. Nuestra intención es dar orientación sobre DLT e información detallada sobre los casos de uso de estas redes.

Tres marcos diferentes

A partir de los Whitepaper de Hyperledger Fabric, R3 Corda (posteriormente, solo referido como Fabric y Corda, respectivamente) y Ethereum, resulta obvio que estos marcos tienen visiones muy diferentes en mente con respecto a los posibles campos de aplicación.

El desarrollo de Fabric y Corda está impulsado por casos de uso concreto. Los casos de uso de Corda provienen de la industria de servicios financieros. En consecuencia, aquí es donde Corda ve su principal campo de aplicación. Por el contrario, Fabric pretende proporcionar una arquitectura modular y ampliable que pueda emplearse en diversas industrias, desde la banca y la sanidad hasta las cadenas de suministro.

Ethereum también se presenta como completamente independiente de cualquier campo específico de aplicación. Sin embargo, a diferencia de Fabric, no es la modularidad lo que se destaca sino la provisión de una plataforma genérica para todo tipo de transacciones y aplicaciones.

INFORMACIÓN DE LA TABLA

Participación de pares

Con el almacenamiento de datos central convencional, solo una entidad única, el propietario, guarda una copia de la base de datos subyacente, por ejemplo, un libro de contabilidad. En consecuencia, esta entidad controla qué datos se aportan y qué otras entidades pueden contribuir.

Con el advenimiento de DLT, esto cambia radicalmente a favor del almacenamiento de datos distribuidos donde múltiples entidades tienen una copia de la base de datos subyacente y naturalmente se les permite contribuir. Todas las entidades que participan en el almacenamiento distribuido de datos forman una red de los llamados nodos o pares.

Debido al almacenamiento distribuido de datos, surge la dificultad de garantizar que todos los nodos acuerden una verdad común, por ejemplo, la exactitud de un libro mayor, ya que los cambios realizados por un nodo deben propagarse a todos los demás nodos pares de la red. El resultado de llegar a una verdad común se llama consenso entre los nodos y se describe a continuación.

Con respecto a participar en el consenso, hay dos modos de operación: sin permiso y con permiso. Si la participación no tiene permiso, cualquiera puede participar en la red. Este modo es cierto para Ethereum como una cadena de bloques pública. Por otro lado, si se autoriza la participación, los participantes se seleccionan por adelantado y el acceso a la red está restringido solo a estos. Esto es cierto para Fabric y Corda. El modo de participación, sin permiso o autorizado, tiene un profundo impacto en cómo se llega al consenso.

Consenso

Ethereum

Con Ethereum, todos los participantes deben llegar a un consenso sobre el orden de todas las transacciones que han tenido lugar, independientemente de si un participante ha participado en una transacción en particular o no. El orden de las transacciones es crucial para el estado consistente del libro mayor. Si no se puede establecer un orden de transacciones definitivo, existe la posibilidad de que se hayan producido gastos dobles, es decir, que dos transacciones paralelas transfieran la misma moneda a diferentes destinatarios, lo que hace que el dinero salga de la nada.

Como la red podría involucrar a partes desconfiadas y anónimas, se debe emplear un mecanismo de consenso que proteja el libro mayor contra los participantes fraudulentos o adversos que intentan gastar doblemente. En la implementación actual de Ethereum, este mecanismo se establece mediante la minería basada en el esquema de prueba de trabajo (PoW). Todos los participantes deben acordar un libro de contabilidad común y todos los participantes tienen acceso a todas las entradas registradas.

Las consecuencias son que PoW afecta desfavorablemente el rendimiento del procesamiento de transacciones. En cuanto a los datos almacenados en el libro, aunque los registros se anonimizan, son accesibles para todos los participantes, lo que es problemático para aplicaciones que requieren un mayor grado de privacidad .

En contraste con Ethereum, la interpretación de consenso de Fabric y Corda es más refinada y no se reduce a la minería basada en PoW o un derivado de la misma. Debido a que opera en un modo permitido, Fabric y Corda proporcionan un control de acceso más detallado a los registros y, por lo tanto, mejoran la privacidad. Además, se logra un aumento en el rendimiento ya que solo las partes que participan en una transacción deben llegar a un consenso.

Fabric

El entendimiento de Fabric sobre el consenso es amplio y abarca todo el flujo de transacción, desde proponer una transacción a la red hasta comprometerla con el libro mayor. Además, los nodos asumen diferentes roles y tareas en el proceso de llegar al consenso. Esto contrasta con Ethereum, donde los roles y tareas de los nodos que participan en alcanzar el consenso son idénticos.

Dentro de Fabric, los nodos se diferencian en función de si son clientes, pares u ordenantes. Un cliente actúa en nombre de un usuario final y crea, y por lo tanto invoca, las transacciones. Se comunican con sus pares y ordenantes. Los pares mantienen el libro mayor y reciben mensajes de actualización ordenados de ordenantes para comprometer nuevas transacciones al libro mayor.

Estos son un tipo especial de pares, su tarea es respaldar una transacción comprobando si cumplen las condiciones necesarias y suficientes (por ejemplo, la provisión de firmas requeridas). Los remitentes proporcionan un canal de comunicación a los clientes y pares sobre los mensajes que contienen transacciones que pueden emitirse. Con respecto al consenso en particular, los canales aseguran que todos los pares conectados reciban exactamente los mismos mensajes con exactamente el mismo orden lógico.

En este punto, surge el problema de que pueden producirse fallas en la entrega de mensajes cuando se utilizan muchos ordenantes mutuamente desconfiados. Como consecuencia, se debe usar un algoritmo de consenso para alcanzar el consenso a pesar de las fallas, por ejemplo, orden incoherente de mensajes, lo que hace tolerable la replicación de las fallas del libro mayor distribuido.

Con Fabric, el algoritmo empleado es “conectable”, lo que significa que dependiendo de los requisitos específicos de la aplicación se pueden usar varios algoritmos. Por ejemplo, para tratar con fallas de replicación aleatorias o maliciosas como se describió anteriormente, se podría usar una variante de los algoritmos de tolerancia a fallas bizantinos (BFT).

Además, los canales de mensajes de partición fluyen, lo que significa que los clientes solo ven los mensajes y las transacciones asociadas de los canales a los que están conectados y no conocen otros canales. De esta forma, el acceso a las transacciones se restringe solo a las partes involucradas, con la consecuencia de que el consenso solo debe alcanzarse a nivel de transacción y no a nivel de libro mayor como ocurre con Ethereum.

Los roles de los nodos descritos anteriormente se describen ahora en el contexto del flujo de transacción: un cliente envía una transacción a los endosantes conectados para iniciar una actualización del libro mayor. Todos los endosantes deben ponerse de acuerdo sobre la transacción propuesta, por lo que se debe llegar a algún tipo de consenso con respecto a la actualización propuesta del libro mayor.

El cliente ahora recolecta sucesivamente la aprobación de todos los endosantes. La transacción aprobada ahora se envía a ordenantes conectados que nuevamente alcanzan el consenso. Posteriormente, la transacción se remite a los pares que tienen el libro mayor para comprometer la transacción.

Sin entrar en detalles, queda claro que Fabric permite un control detallado sobre el consenso y el acceso restringido a las transacciones, lo que se traduce en una mejor escalabilidad y privacidad del rendimiento.

Corda

De manera similar a Fabric, el consenso en Corda también se alcanza al nivel de transacción involucrando solo a las partes. Sujeto a consenso es la validez de la transacción y la singularidad de la transacción.

La validez se garantiza ejecutando el código de Smart Contract (los contratos inteligentes se describen en detalle a continuación) asociado con una transacción, verificando todas las firmas requeridas y asegurando que todas las transacciones a las que se hace referencia también sean válidas.

La unicidad se refiere a los estados de entrada de una transacción. Específicamente, se debe garantizar que la transacción en cuestión sea el único consumidor de todos sus estados de entrada. En otras palabras, no existe otra transacción que consuma cualquiera de los mismos estados. La razón para esto es evitar el doble gasto. El consenso sobre la singularidad se alcanza entre los participantes llamados notarios, mientras que el algoritmo empleado es “conectable” como con Fabric. Entonces, una vez más, podría usarse un algoritmo BFT.

Smart Contract

El término  Smart Contract causa un malentendido considerable cuando se lo encuentra por primera vez, ya que evoca la idea de algún tipo de contrato que actúe inteligentemente en nombre de uno. Sin embargo, la naturaleza del contrato sigue siendo vaga, pero intuitivamente parece estar vinculada a asuntos legales.

Dicho esto, los contratos focales no son inteligentes en el sentido de que son, por ejemplo, impulsados ​​por la inteligencia artificial, al menos no todavía, ni en general codifican obligaciones y derechos jurídicamente vinculantes.

El código de Smart Contract simplemente denota software escrito en un lenguaje de programación. Actúa como un agente de software o delegado de la parte que lo empleó con la intención de que cumpla con ciertas obligaciones, ejerza los derechos y pueda tomar el control de los activos dentro de un libro mayor distribuido de manera automatizada. Por lo tanto, asume tareas y responsabilidades en el mundo del libro mayor distribuido ejecutando código que modela o emula la lógica de contrato en el mundo real, aunque su justificación legal puede no ser clara.

Todos los DLT presentan Smart Contract en el sentido de un código de contrato inteligente que puede escribirse en Go o Java para Fabric, en Solidity para Ethereum y en Java o Kotlin para Corda.

En Fabric, el término “chaincode” se utiliza como sinónimo de contrato inteligente. Como ejemplo ilustrativo, se recuerda al lector el uso de un código de contrato inteligente en el mecanismo de consenso de Corda para garantizar la validez de la transacción. Sin embargo, existe una diferencia notable entre Fabric y Ethereum, por un lado, y Corda, por el otro, que está conectado a la segunda forma en que se utiliza el término de Smart Contract.

En Corda, los contratos inteligentes no solo consisten en código, sino que también se les permite contener prosa legal. Por lo tanto, los contratos legales inteligentes son prosa legal que se formulan de forma tal que puedan expresarse e implementarse en un código de contrato inteligente. La razón detrás de esto es otorgarle al código legitimidad arraigada en la prosa legal asociada. Tal construcción se llama Contrato Ricardiano.

En este punto, nuevamente queda claro que Corda fue diseñado explícitamente para dar cuenta del entorno altamente regulado de la industria de servicios financieros. Tanto Fabric como Ethereum carecen de esta característica.

Moneda incorporada

Otra diferencia notable es que Ethereum presenta una criptomoneda incorporada llamada Ether. Se utiliza para pagar recompensas a los nodos que contribuyen a llegar a un consenso mediante la minería de bloques, así como para pagar las tarifas de transacción. Por lo tanto, se pueden construir aplicaciones descentralizadas (DApps) para Ethereum que permitan transacciones monetarias. Además, se puede crear un token digital para casos de uso personalizados mediante la implementación de un contrato inteligente que cumpla con un estándar predefinido. De esta forma, se pueden definir monedas propias o activos.

Fabric y Corda no requieren una criptomoneda incorporada ya que no se llega a un consenso a través de la minería. Con Fabric, sin embargo, es posible desarrollar una moneda nativa o un token digital con chaincode. Con Corda, no se pretende crear monedas o tokens digitales.

En resumen, Fabric y Ethereum son muy flexibles, pero en diferentes aspectos. El potente motor de Smart Contract de Ethereum lo convierte en una plataforma genérica para, literalmente, cualquier tipo de aplicación. Sin embargo, el modo de operación sin autorización de Ethereum y su total transparencia se logra a costa de la escalabilidad y la privacidad del rendimiento.

Fabric resuelve los problemas de escalabilidad y privacidad del rendimiento mediante el modo de funcionamiento permitido y, específicamente, mediante el uso de un algoritmo BFT y un control de acceso. Además, la arquitectura modular permite que Fabric se personalice para una multitud de aplicaciones.

Corda está ubicado en el otro extremo. Se concibió conscientemente como DLT para la industria de servicios financieros. En particular, toma en cuenta el entorno altamente regulado mediante el aumento de los Smart Contract con la prosa legal.

Desde Token Develop, especialistas en el mercado asiático, desplegamos Smart Contract en diferentes redes (Hyperledger, Ethereum, Corda….). Además estamos desarrollando una nueva red IPFS para el despliegue de contratos inteligentes. Para más información, no dude en contactarnos por correo electrónico: [email protected]

Valora este Articulo: 1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (Ninguna valoración todavía)
Cargando…