¿Qué es Lightning Protocol + Raiden? Guía de soluciones de escalamiento de blockchain.
Bitcoin y Ethereum se están volviendo cada vez más populares, no se puede negar eso. Este es un gráfico del número de transacciones diarias de bitcoins rastreadas a lo largo de los años:
Y aquí tenemos la cantidad de transacciones de ethereum por mes a lo largo de los años:
¿Qué es el protocolo Lightning? Soluciones de escalamiento de blockchain
Si bien esta es una gran señal y muestra cómo las criptomonedas se están volviendo ampliamente utilizadas y aceptadas, existe un gran problema que ha asomado su fea cabeza en los últimos tiempos. Debido al aumento repentino en la cantidad de transacciones, tanto Bitcoin como ethereum se enfrentan a graves problemas de escalabilidad.
Los problemas de escalabilidad se derivan de la forma en que está diseñado el sistema de libro mayor abierto. Supongamos que Alice tiene que enviar 1 BTC a Bob, ¿cómo funcionará el proceso? Alice no puede darle físicamente a Bob el dinero, después de todo, bitcoin es digital. La forma en que se llevará a cabo la transacción es simple:
- Alice declara que quiere enviar 1 BTC a Bob y enviar los detalles de la transacción a los mineros.
- Los mineros verifican que sí es Alice quien envía la solicitud y nadie más y, en consecuencia, aprueban la transacción colocándola en los bloques que han extraído.
- Bob obtiene el 1 BTC.
Entonces, ¿cuál es el problema en toda esta secuencia?
Los mineros se convierten en un cuello de botella para toda la transacción.
El hecho es que los mineros simplemente no pueden mantenerse al día ya que el número de transacciones sigue aumentando. Existe una gran cantidad de atrasos que ocurren como resultado de transacciones que no se verifican lo suficientemente rápido.
Además, también existe la pequeña cuestión de las tarifas de transacción. Siempre que los mineros extraen un bloque, se convierten en dictadores temporales de ese bloque. Lo que eso significa es que pueden cobrar una “tarifa de transacción” nominal para insertar datos de transacción en sus bloques. Sin embargo, para que sus transacciones se realicen más rápido y para saltar la cola, por así decirlo, las personas pueden pagar tarifas de transacción más altas para incentivar a los mineros a verificar sus transacciones primero.
Desafortunadamente, esto genera un gran problema.
Los usuarios normales de bitcoins que pagan las tarifas de transacción normales, la mayoría de las veces necesitan esperar mucho tiempo para que sus transacciones sean aprobadas. De hecho, veamos cuánto tiempo uno tendría que esperar, en promedio, si pagara las menores tarifas de transacción posibles.
Si paga las tarifas de transacción más bajas posibles, tendrá que esperar un tiempo medio de 13 minutos para que se realice la transacción. 13 minutos! La mayoría de las veces, las transacciones tenían que esperar hasta que se extraía un nuevo bloque (que son 10 minutos en bitcoin), porque los bloques más antiguos se llenarían de transacciones.
Ahora las cosas se ven bastante sombrías cuando se trata de bitcoin. Veamos cómo se ven las cosas en la esquina de Ethereum.
En teoría, se supone que ethereum procesa 1000 transacciones por segundo. Sin embargo, en la práctica, ethereum está limitado por un límite de 6,7 millones de gas en cada bloque.
Dado que cada bloque tiene un límite de gas, los mineros solo pueden agregar transacciones cuyos requisitos de gas se sumen a algo que sea igual o menor que el límite de gas del bloque.
Esto, una vez más, proporciona un cuello de botella en la cantidad de transacciones que pueden realizarse por bloque.
ethereum administraba solo 20 transacciones por segundo mientras que Bitcoin avanzaba a 7. Cuando compara esto con el hecho de que Paypal administra 193 transacciones por segundo y Visa hace 1667 por segundo, puede ver por qué había un gran problema y por qué esto era necesario. para ser resuelto rápidamente.
Una forma en que bitcoin está resolviendo su problema de escalabilidad es a través de Segwit y el aumento del tamaño del bloque. Sin embargo, en este artículo, nos centraremos en dos propuestas muy interesantes que no solo pueden resolver los problemas de escalabilidad, sino que, de hecho, pueden permitir miles de transacciones por segundo. Son:
Protocolo Lightning (Bitcoin).
Red Raiden (Ethereum).
¿Qué es el protocolo de iluminación? + Raiden
Antes de entrar en estos dos, hay algunas cosas que deben abordarse.
Un canal de estado es un canal de comunicación bidireccional entre los participantes que les permite realizar interacciones, que normalmente ocurrirían en la cadena de bloques, fuera de la cadena de bloques. Lo que esto hará es que disminuirá el tiempo de transacción de manera exponencial, ya que ya no depende de un tercero, como un minero, para validar su transacción.
Entonces, ¿cuáles son los requisitos para hacer un canal estatal fuera de la cadena?
- Un segmento del estado de la cadena de bloques está bloqueado mediante firma múltiple o algún tipo de contrato inteligente, que es acordado por un conjunto de participantes.
- Los participantes interactúan entre sí firmando transacciones entre ellos sin enviar nada a los mineros.
- Luego, todo el conjunto de transacciones se agrega a la cadena de bloques.
Los canales estatales se pueden cerrar en un punto predeterminado por los participantes según el fundador de Slock.it, Stephan Thual. Podría ser:
- Tiempo transcurrido, por ejemplo. los participantes pueden acordar abrir un canal estatal y cerrarlo después de 2 horas.
- Podría basarse en la cantidad total de transacciones realizadas, por ejemplo. cierre la cadena después de que se hayan realizado transacciones por valor de $ 100.
Entonces, en la imagen de arriba. Tenemos un automóvil que interactúa directamente con el cargador y realiza transacciones por un valor total de $ 39.19. Finalmente, después de una serie de interacciones, todo el fragmento de la transacción se agrega a la cadena de bloques. ¡Imagínese cuánto tiempo les habría llevado si tuvieran que ejecutar cada transacción a través de la cadena de bloques!
Un canal de pago es básicamente un canal estatal que se ocupa exclusivamente de pagos y micropagos entre partes. Recuerde, todas las interacciones en los canales son cosas que podrían suceder en la cadena de bloques pero suceden fuera de ella. Hay varios tipos de diseños de canales de pago; veamos algunos de los más populares.
Uno de los primeros ejemplos del canal de pago fue sugerido por el propio Satoshi Nakamoto.
Este sistema utiliza algunas características interesantes:
- Reemplazo de transacción.
- Ingrese los números de secuencia (nSequence).
- nLocktime.
“NLocktime” es básicamente el parámetro que define el tiempo antes del cual la transacción no podría ser aceptada en el bloque. El concepto es muy simple. Hay un valor llamado “UINT_MAX” y nSequence no puede exceder ese número. Así que suponga que hay una transacción no confirmada y uno puede seguir cambiándola antes de ponerla en el bloque antes de que se agote el tiempo “nLocktime” O que nSequence se vuelve igual a “UINT_MAX”. Para cada reemplazo, el número de secuencia aumenta.
Sin embargo, hubo muchos problemas de seguridad con esto y nunca se ejecutó correctamente.
Antes de continuar, hay dos cosas que debemos tener en cuenta.
En primer lugar, nos gustaría agradecer a David A Harding la explicación de los canales de pago estilo Spillman y estilo CLTV.
En segundo lugar, antes de continuar, debe saber qué significa una dirección P2SH multi-sig.
Cuando se trata de direcciones en bitcoin, hay dos tipos:
- Dirección P2PKH también conocida como dirección Hash de Pay-to-PubKey.
- Dirección P2SH también conocida como dirección Hash de pago por secuencia de comandos.
Una dirección de Bitcoin “normal” se ve así: “15fXdTyFL1p53qQ8NkrjBqPUbPWvWmZ3G9”. Esta es una dirección P2PKH normal. Para gastar los bitcoins enviados a esta dirección, uno simplemente tiene que descifrar usando la clave privada correspondiente y obtener acceso.
Sin embargo, un Bitcoin puede tener condiciones de gasto más versátiles que eso. Puede crear mucho más que simples transacciones P2PKH. La gente se dio cuenta de eso desde el principio y empezaron a jugar con el “scriptPubKey” en el lenguaje de script de Bitcoin.
¿Qué es scriptPubKey?
Así es como se ve una transacción simple de 1 entrada y 1 salida:
El “scriptPubKey” en el “resultado” anterior básicamente dicta las condiciones de gasto. Básicamente, puede agregar sus propias líneas de código al scriptPubKey y definir la condición de gasto usted mismo. Los desarrolladores centrales previeron que esto sucedería y para evitar que los gastadores pusieran largas líneas de código en las condiciones, les permitieron simplemente poner hash de sus condiciones. Estas condiciones se denominan canjear script. En una transacción P2SH, scriptPubKey solo contiene el hash del script de canje. El script en sí solo se revela y verifica durante la transacción pendiente.
Ahora, debido a esto, sucede algo muy importante. Debido a que la verificación del script ocurre solo durante la transacción de gasto, elimina la responsabilidad de proporcionar el script de canje completo del remitente al receptor. Esto, a su vez, ofrece muchas ventajas:
- Un remitente puede enviar dinero a cualquier transacción multifirma sin conocer todos los detalles de la transacción. Esto ayuda mucho en la abstracción. La mayoría de las veces, cada vez que gasta dinero, rara vez se preocupa por lo que sucederá con su dinero después de haberlo entregado. Aquí también se utiliza la misma lógica.
- Es mucho más sencillo para los remitentes enviar dinero a hash cortos y bien definidos, también conocidos como hash de script, en lugar de a scripts largos y confusos.
Un remitente puede enviar dinero a cualquier transacción multifirma sin conocer todos los detalles de la transacción. Esto ayuda mucho en la abstracción. La mayoría de las veces, cada vez que gasta dinero, rara vez se preocupa por lo que sucederá con su dinero después de haberlo entregado. Aquí también se utiliza la misma lógica.
Es mucho más sencillo para los remitentes enviar dinero a hash cortos y bien definidos, también conocidos como hash de script, en lugar de a scripts largos y confusos.
- Alice (el comerciante) le da su clave pública a su cliente, también conocido como Bob.
- Bob usa su clave pública y la clave pública de Alice para crear una dirección p2sh de múltiples firmas que requerirá firmas de Alice y Bob para gastar los fondos pagados en esa dirección.
- Bob crea una transacción pero no la transmite. Utiliza esa transacción para pagar la dirección de firma múltiple. Esta transacción es el depósito.
- Bob ahora crea una segunda transacción que es la misma que antes y la usa para sobrescribir la transacción anterior. Como resultado de esto, el primero se remonta a la dirección de Bob. Bob luego declara un bloqueo de tiempo en la segunda transacción para asegurarse de que no ingrese al bloque antes de un período de tiempo específico y lo firma.
- Bob le da esta segunda transacción a Alice, quien luego procede a firmarla y devolvérsela a Bob. Recuerde, Alice aún no ha visto la transacción de depósito, es decir, la primera transacción todavía.
- Ahora, Bob tiene una transacción que ha sido firmada tanto por él como por Alice y actúa como un reembolso. Entonces, si Alice, la comerciante, no hace un trabajo en particular antes de que se agote el tiempo de espera, Bob puede reclamar la transacción de reembolso por sí mismo.
- Ahora que todas las partes presentes han firmado el reembolso, Bob puede declarar de forma segura su transacción de depósito y agregarla a la cadena de bloques.
Si bien el estilo Spillman fue útil para crear un canal de pago que mantendría a los comerciantes honestos, aún era susceptible a la maleabilidad. Cuando Bob transmite la transacción de depósito, debe ser byte por byte igual que la transacción de reembolso. Si no es así, la transacción de reembolso ya no es válida.
Para resolver estos problemas, se implementaron canales de pago estilo CLTV después del BIP 65. Veamos cómo funciona:
- Alice (el comerciante) le da su clave pública a Bob (el cliente).
Bob usa su clave pública y la de Alice para crear una dirección P2SH usando las siguientes condiciones: Condición 1: Tanto Alice como Bob firman cualquier transacción que ocurra a través de esta dirección Condición 2: Solo Bob puede firmar cualquier transacción por su cuenta, excepto esas transacciones debe tener un tiempo de bloqueo mayor que el depósito de reembolso.
Bob crea inmediatamente una transacción de depósito y la transmite en la cadena de bloques. Debido a la condición 2 anterior, se le asegura el hecho de que prácticamente puede generar un reembolso a pedido. - Ahora recuerde, la primera condición establece que Alice y Bob deben firmar cualquier transacción que ocurra en la dirección P2SH. Entonces, Bob (el cliente) puede firmar su parte de la transacción y Alice puede firmar su parte sin revelar los detalles de su firma a Bob. Al hacer esto, Alice puede transmitir el pago final a la cadena de bloques antes de que se pueda transmitir el reembolso.
La mayor ventaja que tiene este método sobre Spillman-Style es la eliminación de maleabilidad que puede afectarlo. En el estilo de Spillman, Bob estaba atascado por el hecho de que necesitaba transmitir un depósito que coincidiera con el reembolso byte por byte. Básicamente, necesitaba comprometerse previamente, lo que ya no necesita hacer. Estos canales utilizan el “opcode OP_CLTV” que se habilitó gracias a BIP 65.
Los contratos de bloqueo de tiempo hash o “HTLC” son una de las aplicaciones más convenientes de los canales de pago. De hecho, el Protocolo Lightning es una implementación del HTLC. Entonces, ¿qué es un HTLC? Hasta ahora hemos visto canales que utilizan “timbres de tiempo”. Un HTLC “amplía” eso al introducir “Hashlocks” junto con los temporizadores.
El HTLC permite la apertura de canales de pago donde los fondos pueden transferirse entre las partes antes de una fecha límite acordada previamente. Estos pagos se reconocen mediante la presentación de pruebas criptográficas. Junto con eso, otra característica brillante de los HTLC es que permite que una parte pierda el pago que se le haya otorgado y se lo devuelva al pagador. Además de eso, los pagos también se pueden realizar a través de canales.
Además, hay otra característica sorprendente que viene gracias al HTLC. Hace posibles las transacciones entre cadenas. Esto se denomina comercio de cadena cruzada atómica y permite a los usuarios intercambiar una parte de la criptomoneda en una cadena (por ejemplo, bitcoin en la cadena de bloques principal) por una parte de la criptomoneda en otra cadena (bitcoin en una cadena lateral).
Muy bien, entonces, ¿cómo funciona HTLC?
Imagina que Alice tiene que enviar algunos fondos a Charlie a través de Bob.
- Alice abre un canal con Bob y Bob abre un canal con Charlie.
- Suponga que Alice declara que quiere interactuar con Charlie.
- Charlie declara un número aleatorio y genera su hash SHA256 y se lo entrega a Alice. Básicamente, si Charlie elige un número A, le dará el hash del número H (A).
- Alice envía 0.1 BTC a Bob con la condición de que solo alguien que pueda enviar los datos requeridos para obtener el mismo hash pueda recuperar el pago. Para que Bob haga un mal uso de los fondos, deberá tener los datos, también conocidos como la imagen previa necesaria para generar ese hash. Básicamente, Bob tendrá que dar una “A” que no tiene.
- Bob ahora le entrega los fondos a Charlie con la misma condición. Charlie finaliza el pago de Bob entregándole la imagen previa “A”.
- Bob finaliza el pago de Alice entregándole su “A”.
Lightning Network es un sistema de micropagos de estilo HTLC fuera de la cadena que está diseñado para hacer que las transacciones funcionen más rápido en la cadena de bloques. Fue conceptualizado por Joseph Poon y Tadge Dryja en su documento técnico que tenía como objetivo resolver el límite de tamaño de bloque y los problemas de demora en las transacciones. Opera sobre Bitcoin y a menudo se lo denomina “Capa 2”.
Como señala Jimmy Song en su artículo mediano:
“Lightning Network funciona creando una transacción con doble firma. Es decir, tenemos un nuevo cheque que requiere que ambas partes firmen para que sea válido. El cheque especifica cuánto se envía de una parte a otra. A medida que se realizan nuevos micropagos de una parte a la otra, se cambia el monto del cheque y ambas partes firman el resultado “.
Entonces, echemos un vistazo a algunas de las funciones que vienen gracias a la red Lightning:
- Pagos rápidos: los pagos son casi instantáneos.
- No depende de los mineros: las transacciones no necesitan ser aprobadas y verificadas por los mineros para que se lleven a cabo.
- Amigable con los micropagos: los micropagos anteriores eran extremadamente inconvenientes en la cadena de bloques de bitcoin. Ahora son posibles gracias a la red Lightning.
- Compatible con múltiples firmas: las transacciones se llevarán a cabo si y solo si todos los presentes en el canal lo aprueban.
- Reduce la carga de la cadena de bloques: con tantas transacciones ocurriendo en la cadena, se reduce en gran medida la carga que la cadena principal tiene que soportar.
- Disminuye el tiempo de espera: dado que las transacciones se realizan fuera de la cadena y sin la intervención del minero, hay poco o ningún tiempo de espera.
- Ayuda en la escalabilidad ya que aumentará la cantidad de transacciones que ocurren por segundo.
Por sorprendente que sea la red de rayos, había un obstáculo importante frente a ella que necesitaba ser manejado. La red Lightning, como con todos los métodos de canales de pago, es susceptible a la maleabilidad de las transacciones.
Antes de que entendamos qué es la maleabilidad de las transacciones, es importante recapitular una de las funciones más importantes del modelo criptoeconómico … el hash. Hemos escrito un artículo antes que cubre el hash en detalle. Solo para brindarle una breve descripción general, una función hash puede tomar cualquier entrada de cualquier longitud, pero la salida que da es siempre de una longitud fija.
Sin embargo, hay otra función importante del hash que necesita conocer para comprender el “error de maleabilidad de la transacción” como se le llama. Cualquier pequeño cambio en los datos de entrada cambiará drásticamente el hash de salida.
P.ej. Consulte esta prueba que hicimos con SHA-256, también conocido como el algoritmo hash utilizado en bitcoin:
Esto es una prueba
C7BE1ED902FB8DD4D48997C6452F5D7E509FBCDBE2808B16BCF4EDCE4C07D14E
esto es una prueba
2E99758548972A8E8822AD47FA1017FF72F06F3FF6A016851F45C398732BC50C
¿Mira eso?
Acabamos de cambiar “T” de mayúsculas a minúsculas, ¡y mire lo que le hizo a la salida!
Una cosa más que debe comprender sobre la cadena de bloques es que es inmutable, es decir, una vez que los datos se han insertado en un bloque, nunca se pueden cambiar. Si bien esto demuestra una red de seguridad contra la corrupción, hubo una debilidad que nadie vio venir.
¿Qué pasa si los datos fueron alterados?
incluso entró en la cuadra? Incluso si la gente se entera más tarde, no hay nada que nadie pueda hacer al respecto porque los datos una vez ingresados en un bloque nunca se pueden eliminar. Esa, en esencia, es la razón por la que la maleabilidad de las transacciones es un problema.
Ahora bien, ¿por qué ocurre la maleabilidad de las transacciones?
Cada transacción de bitcoin tiene datos de entrada y datos de salida.
Veamos los datos de entrada en particular:
Consiste en el número de entradas de transacciones tomadas y los datos de la firma. Los datos de la firma provocan dos problemas:
- Es extremadamente voluminoso y ocupa mucho espacio.
- Puede manipularse y, por tanto, provocar maleabilidad en las transacciones.
De hecho, la manipulación de datos de firmas puede hacer que parezca que la transacción ni siquiera sucedió en primer lugar. Veamos esto en un ejemplo.
Supongamos que Bob quiere que Alice le envíe 3 BTC. Alice inicia una transacción de 3 BTC a la dirección pública de Bob y luego la envía a los mineros para su aprobación. Mientras la transacción está esperando en la cola, Bob usa la maleabilidad de la transacción para alterar la firma de Alice y cambiar el ID de la transacción.
Ahora existe la posibilidad de que esta transacción manipulada se apruebe antes de que se apruebe la de Alice, lo que a su vez sobrescribe la transacción de Alice. Cuando Bob obtiene sus 3 BTC, simplemente puede decirle a Alice que no recibió los 3 BTC que ella le debía. Alice verá que su transacción no se realizó y la reenviará. Como resultado, Bob terminará con 6 BTC en lugar de 3 BTC.
Entonces, aclaremos esto. ¿Puede la maleabilidad destruir permanentemente los protocolos de rayos? No, no puede. Sin embargo, puede hacer que toda la experiencia sea muy lenta y molesta. Las transacciones maltratadas se atascarán en varios pasos del canal. La única forma en que esto puede resolverse de forma permanente es introduciendo confianza en el sistema o estableciendo tiempos de espera muy inconvenientes. Hay muchas razones por las que esto no es deseable:
- Los tiempos de espera pueden volverse molestos.
- Cualquier sistema basado en la confianza es corruptible. Esa es la filosofía fundamental detrás de bitcoin, construir un sistema que sea completamente sin confianza. Un sistema que puede mantenerse honesto sin depender de la confianza de los seres humanos es el sistema perfecto.
Entonces, para avanzar y escalar realmente con el rayo, se necesitaba una solución para el problema de maleabilidad y esa solución llegó en forma de Segwit.
Segwit, también conocido como testigo segregado, tenía un concepto muy simple. Si la mayoría de los problemas surgían de los datos de la firma en los bloques, ¿por qué no podemos simplemente recogerlos y mantenerlos en una cadena lateral paralela? Básicamente, ingrese toda la transacción menos los datos de la firma en la cadena principal y coloque todos los datos de la firma en una cadena lateral.
Así es como se vería un bloque después de segwit:
Entonces, al eliminar los datos de la firma de las transacciones, estaba matando dos pájaros de un tiro, el espacio del bloque se vació y las transacciones se volvieron maleables y libres. De un solo golpe, Segwit resolvió el problema de maleabilidad y allanó el camino para una integración perfecta de la red Lightning.
La versión de Ethereum del protocolo relámpago se llama Raiden. En ethereum, ocurren 20 transacciones por segundo. Para acelerar las cosas y permitir transacciones más rápidas de tokens Ether y ERC20, se está introduciendo la red Raiden, que actuará de manera muy similar al protocolo Lightning y permitirá transacciones rápidas en canales privados.
Si bien es posible que la red Raiden en toda regla aún no esté completamente lista, el hecho es que muchas personas solo necesitan Raiden para las funcionalidades de pago de muchos. Entonces, para ellos, se ha creado micro Raiden (µRaiden) que permite estructuras de micropago fáciles y rápidas.
La cuestión es que Ethereum es poco práctico para transacciones instantáneas. Hay una larga fila de espera para que se agreguen transacciones a los distintos bloques de la cadena de bloques y, en la mayoría de los casos, tendrá que pagar tarifas elevadas para cortar la línea. Lo que va a hacer la red Raiden es que ayudará a las personas en la red a realizar pagos instantáneos a través de los canales de pago.
Raiden se estructurará como una estructura de tipo malla que se ejecuta en la parte superior de la cadena principal de ethereum:
Raiden fue conceptualizado por la tecnología Brainbot. Esto es lo que el fundador y CEO Heiko Hees dijo sobre Raiden:
“Básicamente, todas las aplicaciones basadas en blockchain que quieran escalar al uso en el mundo real se beneficiarán de Raiden. Se puede usar para aplicaciones como el intercambio de activos en juegos o finanzas, pagos minoristas, micropagos por contenido (piense en el próximo YouTube o Spotify, donde los creadores reciben un pago directo por cada segundo consumido). Pero también es adecuado como infraestructura para la banca corresponsal más barata, rápida y segura “.
Entonces, ¿cómo funciona Raiden?
Suponga que Alice y Bob quieren interactuar entre sí usando Raiden. Así es como lo harán
- Alice y Bob abren un canal de pago entre ellos que estará fuera de la cadena e implementan un contrato inteligente.
- Ambas partes realizan un depósito de seguridad en el contrato inteligente.
- Supongamos que Alice quiere enviar 3 fichas a Bob, firma el mensaje “3” y se lo envía a Bob. Bob ahora tiene prueba de que Alice le envió 3 fichas.
- Ahora, suponga que Alice quiere enviarle a Bob 4 tokens más. Actualizará el estado del mensaje a “7”. Esto muestra que el mensaje transmite la transacción anterior y la última también.
- En el momento en que Bob quiera canjear los 7 tokens, irá a la cadena de bloques y cerrará el canal. Obtendrá los 7 tokens del depósito que inicialmente se realizó en el canal.
- La información se transmitirá a la cadena de bloques y el único registro que se almacenará es el depósito final de 7 tokens realizado a Bob.
Raiden tendrá una ICO para financiar su proceso de configuración. Durante la ICO, los inversores tendrán en sus manos el token RDN de Raiden. ¿Cuál es el uso de este token? El diseño de la Red Raiden es tal que inevitablemente costará tarifas. Parte de la red es tal que la gente tendrá que sentarse y observar sus canales para asegurarse de que no se robe nada de la diversión. Sin embargo, en lugar de sentarse en sus computadoras y ver sus fondos todo el día, simplemente podrían subcontratar este trabajo a alguien y pagarle por RDN.
¿Cuáles son algunas de las características de Raiden Network?
- Interfaz de programación de aplicaciones (API) utilizable y simple.
- Habilita la escalabilidad de ethereum.
- Puede ser operado por un token ERC20.
- Permite una transferencia de dinero rápida y sencilla.
- Disminuirá la carga en la cadena de bloques ethereum.
Para que las cadenas de bloques se amplíen, deben tener soluciones fuera de la cadena. Los canales de pago son uno de los mejores métodos para hacerlo. Si Bitcoin y ethereum pueden atrapar a Lightning y Raiden, entonces las posibilidades son infinitas. ¿Imagina tener miles de transacciones por segundo mientras paga tarifas de transacción insignificantes y tiene la capacidad de comerciar y conectarse con otras cadenas de bloques? Todo eso ya no es una quimera. ¡No podemos esperar a ver cómo funciona!