Protocolo Basado en Blockchain para la Gestión de Canales para Microcompras Equitativas

Actas de las XV Jornadas de Ingeniería Telemática (JITEL 2021), A Coruña (España), 27-29 de octubre de 2021. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) Protocolo Basado en Blockchain para la Gesti´ on de Canales para Microcompras Equitativas M. Magdalena Payeras Capell` a, Miquel ` A. Cabot-Nadal, Maci` a Mut Puigserver Departament de Ci` encies Matem` atiques i Inform` atica, Universitat de les Illes Balears Crta. de Valldemossa, Km, 7.5 07122, Palma [email protected], [email protected], [email protected] Jordi Castell` a Roca Departament d’Enginyeria Inform` atica i Matem` atiques, UNESCO Chair in Data Privacy, Universitat Rovira i Virgili Av. Pa¨ ısos Catalans 26, E-43007 Tarragona [email protected] El desarrollo de aplicaciones de comercio electr´ onico que requieren el pago de peque˜ nas cantidades de dinero para la compra de servicios o bienes presenta desaf´ ıos en los campos de la seguridad y la privacidad. Estos pagos se denominan micropagos y ofrecen un equilibrio entre los requisitos de eficiencia y seguridad para pagar art´ ıculos de bajo valor. Con la aparici´ on de las criptomonedas nuevos protocolos de compra pueden proponerse, benefici´ andose de las cualidades de estos sistemas de pago. En este art´ ıculo se presenta un protocolo de compra o intercambio de pago por producto o recibo utilizando canales de pago. El sistema presenta las particularidades de permitir pagos de poca cuant´ ıa y proporcionar un intercambio justo entre la criptomoneda y el bien o servicio deseado. Finalmente, el protocolo incluye operaciones para el tratamiento de los pagos recibidos, como la transferibilidad que convierte al sistema en multihop o la posibilidad de reembolso del dinero no gastado en el canal. Palabras Clave—Micropago, microcompra, canal, equidad, blockchain I. INTRODUCCI ´ ON El campo del comercio electr´ onico (e-commerce) evoluciona d´ ıa a d´ ıa introduciendo nuevas aplicaciones y servicios. Una de estas aplicaciones es el pago de peque˜ nas cantidades de dinero para adquirir bienes o servicios de bajo coste. Este tipo de pagos se denomina micropago y tienen requisitos funcionales y de seguridad ´ unicos dentro del campo de los pagos electr´ onicos. Los micropagos se pueden aplicar f´ acilmente a la venta intangible de bienes como informaci´ on (peri´ odicos, rese˜ nas de productos, servicios basados en la ubicaci´ on, etc.), obsequios virtuales o datos electr´ onicos (m´ usica, v´ ıdeos, etc.). Todos estos ejemplos involucran transacciones de bajo valor, por lo que el costo operativo debe ser lo m´ as bajo posible para que sea rentable para comerciantes y clientes. Por un lado, las propiedades de seguridad son una preocupaci´ on principal para el desarrollo de sistemas de micropagos para evitar riesgos financieros para los comerciantes y tambi´ en para garantizar la privacidad de los clientes. Por otro lado, la eficiencia y el costo de las transacciones individuales son factores cr´ ıticos para el desarrollo de estos sistemas. Sin embargo, la eficiencia y la seguridad generalmente se oponen, por lo que los micropagos deben proporcionar una compensaci´ on entre estos requisitos. En los ´ ultimos tiempos hemos visto el auge de las criptomonedas, unos medios digitales de intercambio, que utilizan la criptograf´ ıa y est´ an controladas por bases de datos descentralizadas e inalterables como son las cadenas de bloques o blockchain. ´ Estas presentan muchas ventajas respecto a las monedas fiducitarias, pero tambi´ en presentan limitaciones, como son los elevados costes de las transacciones realizadas sobre las blockchain. Adem´ as, las operaciones realizadas en la blockchain no son completamente an´ onimas, ya que pueden ser rastreadas al ser visibles p´ ublicamente. A´ un as´ ı, los usuarios no pueden ser f´ acilmente identificados, ya que utilizan direcciones que son seud´ onimos. Podemos realizar transacciones instant´ aneas fuera de la blockchain utilizando los llamados canales de pago, que nos permitir´ an hacer transacciones instant´ aneas con criptomonedas. ´ Estos nos permiten superar los problemas de la blockchain en cuanto a costes elevados y de escalabilidad, en t´ erminos de transacciones por segundo y de espacio ocupado en la misma. Los 184 Payeras, Cabot, Mut, 2021. canales de pago se basan en la inclusi´ on de muchas operaciones en la misma transacci´ on de la blockchain principal. Por ello, son una excelente soluci´ on de segunda capa que eliminan la dependencia directa de la blockchain. A. Contribuci´ on En [1] propusimos un esquema de micropagos novedoso, eficiente y seguro para pagar art´ ıculos de bajo valor asegurando la privacidad de los clientes. En el presente art´ ıculo proponemos una versi´ on mejorada del protocolo basada en el uso de blockchain. El anterior sistema descrito en [1] utilizaba monedas espec´ ıficas para cada comerciante en cambio, con la introducci´ on de la blockchain, el nuevo sistema utiliza criptomonedas en un intercambio equitativo entre clientes y comerciantes para pagar el bien o servicio deseado. Tambi´ en, nuestra nueva propuesta evita el uso de un banco que administre las cuentas de los clientes y comerciantes gracias al despliegue de smart contracts en la blockchain. El sistema crea un canal de pago, evita el doble gasto y el gasto excesivo, protege contra la falsificaci´ on y, adem´ as, permite a los clientes solicitar un reembolso seguro de la cantidad no utilizada. El comerciante puede cobrar las cantidades pagadas incluso antes del cierre del canal y este puede redirigirse, permitiendo la transferabilidad de las criptomonedas, en lo que se denomina una soluci´ on multihop. B. Organizaci´ on El trabajo est´ a organizado de la siguiente forma. Primero, en la siguiente secci´ on, describimos brevemente las caracter´ ısticas y los requisitos de seguridad de los micropagos, las criptomonedas, los canales de pago y los protocolos de compra, analizando el trabajo relacionado. En la secci´ on III damos una visi´ on general de la propuesta y los actores implicados. Luego, en la secci´ on IV, definimos el protocolo de microcompra equitativa. En la secci´ on V presentamos una descripci´ on general de seguridad del protocolo. Finalmente, en la secci´ on VI, el trabajo incluye las conclusiones y trabajos futuros. II. SITUACI ´ ON ACTUAL En [1] se presenta un esquema de micropagos eficiente y seguro, donde se describe un intercambio equitativo entre la moneda y el bien o servicio deseados, asegurando el anonimato y la imposibilidad de rastrear a los clientes. En el presente art´ ıculo se pretende mejorar dicho esquema, aprovechando las ventajas que nos ofrece actualmente la blockchain. En [5], los autores introdujeron dos esquemas simples de micropago, PayWord y MicroMint, que utilizaban cadenas de hashes fuera de l´ ınea, pero no utilizaba a´ un la tecnolog´ ıa blockchain. En [3] ya se propuso un sistema descentralizado que utilizaba la blockchain Bitcoin, mediante el cual las transacciones se env´ ıan a trav´ es de una red de canales de micropago. Estas transferencias de valor se realizan fuera de la blockchain, que las validaba posteriormente. La irrupci´ on de la blockchain Ethereum [6] supuso un paso m´ as en las tecnolog´ ıas de cadenas de bloques, al presentar el paradigma de una m´ aquina transaccional singleton descentralizada con estado compartido. Esta tecnolog´ ıa ha propiciado la propuesta de multitud de soluciones con canales de micropago. Por ejemplo, los canales de micropagos sobre la red Ethereum ya han sido tratados en [2], tratando de mejorar su rendimiento y coste. El protocolo propuesto en este art´ ıculo escala logar´ ıtmicamente con la capacidad del canal, utilizando una variante del ´ arbol Merkle, y no requiere que el pagador bloquee todo el saldo en la creaci´ on del canal. En [4] Di Ferrante tambi´ en mostr´ o c´ omo construir canales de pago en Ethereum usando s´ olo ”50 l´ ıneas de c´ odigo”, entre el pagador y el beneficiario. El smart contract implementado permite verificar las firmas digitales de los pagos realizados fuera de la blockchain utilizando el c´ odigo de operaci´ on ecrecover, que devuelve la direcci´ on del firmante. [7] tambi´ en utiliza la tecnolog´ ıa Ethereum, proponiendo el intercambio de tokens h´ ıbrido descentralizado (HEX) para combinar los beneficios de los intercambios de tokens CEX (centralizados) y DEX (descentralizados). Este HEX ampl´ ıa las soluciones existentes al agregar una nueva capa de canal de pago para beneficiar a los comerciantes frecuentes y aliviar la congesti´ on de transacciones pendientes. En [8] se propuso el uso de una red de canales de pago multihop y an´ onimo. La soluci´ on se basa en la criptograf´ ıa de curva el´ ıptica (ECC) y se ha demostrado que es segura al tiempo que logra la privacidad de la ruta de pago y el anonimato del remitente y el receptor. Tambi´ en existen otras redes como Raiden [9], una red para transacciones instant´ aneas, que opera sobre la plataforma Ethereum y es un an´ alogo a la idea de Lightning Network. Esta red pretende resolver el problema de escalabilidad que tiene actualmente la red Ethereum. De todas formas, a pesar de que las redes de canales de pago hayan intentado mitigar los problemas de escalabilidad inherentes a las redes blockchain, ´ estas a´ un no brindan garant´ ıas significativas de seguridad y privacidad, como se demuestra en [11]. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 185 Protocolo Basado en Blockchain para la Gestión de Canales para Microcompras Equitativas III. VISI ´ ON GENERAL DEL SISTEMA El protocolo est´ a formado por diferentes fases. En la primera de ellas se realiza la configuraci´ on del sistema y la generaci´ on de claves. A continuaci´ on, el usuario comprador selecciona el comercio en el que desea realizar las compras y solicita el servicio o producto a adquirir. En la siguiente fase se realiza la apertura del canal. Una vez el canal se halla abierto pueden realizarse las operaciones de compra, que incluyen el pago y el env´ ıo del producto o servicio adquirido. Finalmente el sistema cuenta con la fase de cobro o liquidaci´ on de canal o, alternativamente, la fase de transferencia del canal (multihop exchange), donde se realiza la reconversi´ on del canal para la operaci´ on de compra con un nuevo usuario. A. Actores Los actores que intervienen en el protocolo de compra son el comprador Ci el vendedor M. Adem´ as de ´ estos, el protocolo viene regulado por un smart contract (SC) desplegado en la blockchain que regula las operaciones sobre el canal de pago abierto entre CyMguardando los datos del intercambio en la blockchain. Al tratarse de un sistema de canales transferibles tambi´ en pueden intervenir m´ ultiples vendedores. Para definir la transferencia del canal se denominar´ aNal segundo vendedor. B. Notaci´ on La tabla I muestra la notaci´ on utilizada en la descripci´ on del protocolo. Tabla I NOTACI ´ ON. Notaci´ on Descripci´ on CComprador MVendedor NVendedor en un canal transferido SC Smart Contract Sid Identificador del servicio ΓConjunto de elementos del canal WLC Generador de la cadena W0CIdentificador de la cadena W0MIdentificador para la liquidaci´ on de la cadena cN´ umero de µ-monedas de pago. vValor de lsa µ-monedas TExp Fecha de caducidad ∆T D Per´ ıodo de dep´ osito ∆T R Per´ ıodo de reintegro. KsClave de sesi´ on EKs[M]Cifrado Sim´ etrico del mensaje Mcon la clave Ks ChannelId Identificador del canal H() Funci´ on de Hash QCantidad asociada al canal de pago IV. PROTOCOLO De acuerdo con el apartado anterior, describimos el protocolo de pago en sus diferentes fases: Solicitud del servicio por parte de un cliente, Apertura del canal de pago, Compra (realizaci´ on del intercambio entre el pago por un producto o servicio), Liquidaci´ on del canal de pago y, finalmente, Transferencia del canal de pago para otros usos (multihop). Todas estas fases, a excepci´ on de la fase de Compra, se realizan con comunicaciones onchain. Esto significa que las acciones, que realizan los distintos actores, las llevan a cabo a trav´ es de llamadas a funciones al smart contract desplegado para regular el canal de pago. Este smart contract controlar´ a que cada actor s´ olo pueda realizar las acciones que le corresponden y dejar´ a constancia de las mismas en la blockchain. A continuaci´ on se describen cada una de las fases del protocolo propuesto: A. Solicitud de Servicio En esta fase el cliente debe seleccionar un servicio de les ofrecidos por los diferentes vendedores. Por tanto, cada vendedor Mtiene publicado su lista de servicios disponibles, SIdi. Luego, Cselecciona un vendedor My un servicio de la lista de servicios que ofrece. El servicio seleccionado se identifica mediante Sid. El cliente decide cuantas µ-monedas cquiere utilizar en el canal. Cada µ-moneda tendr´ a un valor vque se puede determinar en funci´ on del precio del servicio seleccionado (el precio de Sid ser´ a un m´ ultiplo de v). El cliente env´ ıa estos datos a Mque genera WLM (donde L= 2c+ 1) y aplica la funci´ on de hash L veces sobre este ´ ıtem W0M=HL(WLM ). El vendedor Mtransmite W0M aCpara que pueda abrir el canal de pago para este servicio. Cabe rese˜ nar que esta cadena se genera para permitir liquidaciones parciales del canal. En caso de permitir una ´ unica liquidaci´ on entonces seria suficiente que Maplicase la funci´ on de hash una ´ unica vez sobre el generador para obtener el identificador. B. Apertura del Canal Cprocede a la apertura del canal para micropagos transfiriendo la cantidad Q=c∗val smart contract, recordemos que ces el n´ umero de µ-monedas que quiere depositar en el canal y que ves su valor. Este realiza una comprobaci´ on del saldo de la transacci´ on de Cy almacena la cantidad Q. Entonces Cgenera WLC , donde L= 2c+ 1 y aplica sobre ´ el Lveces una funci´ on de hash para obtener W0C. Llamaremos W(L−1)Cal resultado de aplicar la funci´ on de hash a WLC .El ´ ultimo elemento de la cadena se denominar´ aW0C. Dentro de esta cadena los elementos con sub´ ındice impar representar´ an µ-monedas mientras que los elementos con sub´ ındice par representar´ an la prueba de pago de la anterior µ-moneda. Se ha decidido que la cadena de Mtenga la misma longitud que la cadena de Cpara simplificar la notaci´ on aunque una cadena con la mitad de elementos seria suficiente ya que la cadena de Mno contiene ´ ıtems de pago intercalados con ´ ıtems de prueba. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 186 Payeras, Cabot, Mut, 2021. Fig. 1. Estructura de la cadena de ´ ıtems de compra TExp es la fecha de caducidad del canal, ∆T D define un per´ ıodo posterior a la fecha de caducidad en el cual puede realizarse la transferencia del contenido del canal a la cuenta del receptor del pago o bien la trasferencia del canal a un nuevo vendedor, mientras que ∆T R representa un per´ ıodo para el reintegro del dinero restante, no utilizado para pagos en el canal, por parte de Cy para una posible transferencia del canal por parte de M(ver Figura 2). Con estos elementos, el comprador Cgenera el elemento Γ=(W0M, SId,2c, v, TExp,∆T D,∆T R, W0C). Posteriormente, el comprador Cllama a una funci´ on del smart contract para publicar en la blockchain el elemento Γy, de esta manera, hacer efectiva la creaci´ on del canal de pago. Adicionalmente, el smart contract configura el contador j= 0 que simboliza el n´ umero de secretos revelados para el gasto/cobro de las µmonedas. Identificaremos un canal en concreto por ChannelId =H(Γ). C. Compra (Intercambio de pago y producto/servicio) Pueden realizarse tantas operaciones de pago como µ−monedas contenga el canal antes de TExp. Por ello M, a trav´ es del smart contract, comprobar´ a antes de cada pago que la fecha actual es menor que la fecha de caducidad. El proceso de compra est´ a formado por tres pasos, formando un intercambio equitativo entre la µ−moneda y el producto o servicio. En cada operaci´ on de compra pueden utilizarse una o varias µ−monedas, de modo que la suma de sus valores sea igual a la cantidad a pagar en la operaci´ on de compra. La operaci´ on de compra equitativa consta de tres pasos que se ejecutan off-chain, entre CyM: env´ ıo de las µ−monedas, env´ ıo del producto o servicio y env´ ıo de la prueba de pago. Las µ−monedas se revelar´ an en orden inverso a su creaci´ on en la cadena de hash. Para este proceso se utilizar´ a una clave secreta de sesi´ on Ks compartida por CyM. 1) Paso 1. Cenv´ ıa a Mel mensaje m1= [EKs[WiC ], ChannelId]. Al recibir el mensaje, M descifra WiC , verifica la fecha y el identificador del canal, es decir comprueba que el canal est´ e abierto en el smart contract. A continuaci´ on, el vendedor Mcomprueba que no se ha producido reutilizaci´ on de µ-moneda, comprobando que i > j, siendo iel n´ umero de orden de la µ-moneda utilizada en el pago y j el n´ umero de orden de la prueba de la ´ ultima µ-moneda utilizada. Adem´ as, Mverifica que WiC pertenece a la cadena Hi−j(WiC ) == WjC . Si se trata del primer pago realizado en este canal, la comprobaci´ on se har´ a del siguiente modo: Hi(WiC ) == W0C. Una vez finalizadas estas verificaciones, Mguarda SId,ChannelId,WiC y (j=i). 2) Paso 2. Menv´ ıa el producto o servicio mediante el mensaje m2=EKs[service/product]. Al recibir el mensaje, Cdescifra m2y prepara la prueba adjunta a la µ-moneda. 3) Paso 3. Cenv´ ıa la prueba asociada a la µ-moneda de forma cifrada, junto con el ´ ındice correspondiente a su posici´ on en la cadena. m3=EKs[W(i+1)C,(i+1)]. El vendedor Mdescifra y verifica W(i+1)C. Esta verificaci´ on se realiza aplicando una funci´ on de hash sobre la prueba y se verifica que el resultado se corresponde con la µ-moneda utilizada para el pago WiC . Finalmente, Mguarda el valor W(i+1)C y actualiza j=i+ 1. D. Liquidaci´ on del canal Para que los fondos asociados con las operaciones de compra se transfieran a M, este debe realizar la operaci´ on This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 187 Protocolo Basado en Blockchain para la Gestión de Canales para Microcompras Equitativas Fig. 2. Ciclo de vida del Canal de pago Fig. 3. Subprotocolo de Compra de cobro. Esta operaci´ on puede realizarse una vez se hayan utilizado todas las µ-monedas asociadas al canal, pero tambi´ en puede efectuarse si Mha recibido una o diversas µ-monedas asociadas con el canal de pago, aunque no se trate de su totalidad. En caso extremo, M podr´ ıa realizar el cobro por cada µ-moneda individual gastada. Para esto Mdebe revelar cada uno de los WiM en orden inverso a su creaci´ on. (Cabe destacar que la finalidad de los canales de pago es reducir costes y por tanto la eficiencia del sistema se consigue mediante el cobro simult´ aneo de diferentes µ−monedas.) Esta operaci´ on se realiza on-chain y para ello M accede al smart contract, el cual realizar´ a la transferencia unificando la cantidad asociada a las µ-monedas reveladas. En un primer paso, el smart contract verificar´ a que la fecha actual se encuentre en el per´ ıodo correcto. El per´ ıodo de cobro se encuentra entre TExp yTExp +∆T D. Sin embargo, Mtambi´ en puede ejecutar la funci´ on de cobro antes de TExp para realizar un cobro parcial con las µ-monedas recibidas (en este escenario se podr´ an producir a posteriori m´ as pagos con µ-monedas del canal). En la ejecuci´ on de la funci´ on de cobro del smart contract, Mutilizar´ a como par´ ametros los valores de ChannelId,WkM ,WkC ,k, siendo kel ´ ındice de la ´ ultima micromoneda recibida (o de la ´ ultima moneda que se quiere cobrar). El smart contract verifica que: •k > j. Mediante esta comprobaci´ on se evita la reutilizaci´ on de micromonedas. •WjM == Hk−j(WkM ). Esta comprobaci´ on permite verificar que el usuario que ejecuta la funci´ on es el destinatario del canal de pago. •WjC == Hk−j(WkC ). Se verifica que la µ-moneda pertenece a ´ este canal. Una vez realizadas todas las comprobaciones, el smart contract realiza la transferencia del balance asociado a los micropagos a M. Para ello determina el valor en funci´ on de la cantidad de µ-monedas transferidas y del valor de cada una de ellas establecido en el canal. El n´ umero de µ-monedas transferidas se determina a partir del ´ ındice proporcionado por M. Si el ´ ındice es par se transferir´ a el valor de (k−j)/2mientras que si es impar se transferir´ a el valor de (k−j−1)/2ya que se tiene en cuenta que los ´ ındices incluyen las µ-monedas de prueba. Despu´ es de esta operaci´ on el smart contract tiene que actualizar el ´ ındice j=k. E. Transferencia del Canal El protocolo se ha dise˜ nado teniendo en cuenta el inter´ es en conseguir canales transferibles (o multihop), es decir, canales en los que el dinero pueda cambiar de manos en diferentes ocasiones sin necesidad de una transferencia de fondos hacia una wallet particular. Con el fin de realizar una descripci´ on m´ as sencilla, pero sin quitar generalidad al funcionamiento del protocolo, supondremos que Mva ha utilizar µ-monedas del mismo valor en ambos canales (el protocolo podr´ ıa f´ acilmente This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 188 Payeras, Cabot, Mut, 2021. extenderse al uso de µ-monedas de valor diferente). El subprotocolo para que Mpueda transferir los fondos del canal utilizado con Cpara realizar pagos a trav´ es de un nuevo canal a otro vendedor Nes el siguiente: •Msolicita al smart contract que las µ-monedas recibidas pasen a otro canal, para efectuar pagos aNinvocando a una funci´ on del smart contract que gestiona los canales de pago. Esta funci´ on solo se podr´ a ejecutar de forma alternativa a la funci´ on de liquidaci´ on de canal. Para ello Ngenera W0N yMgenera W0 0M, de forma an´ aloga a como se gener´ oW0MyW0Cen el proceso de apertura del canal. W0N=Hn(WnN )yW0 0M=Hn(W0 nM ). Como ya hemos mencionado, en este caso el valor de las µ-monedas ves el mismo que en el canal transferido. Por otra parte el numero de µ-monedas del canal puede ser igual o inferior al n´ umero de micromonedas del canal original c0<=j. Por tanto, el valor de nutilizando es n=c0∗v. •Mgenera Γ0=(W0N, SIdN ,2c0, v, T0 Exp,∆0 T D, ∆0 T R, W0 0M). •Mpuede utilizar las µ-monedas del canal para realizar compras en N, siguiendo el subprotocolo de compra descrito anteriormente. Finalmente, si as´ ı lo desea, Nrecibir´ ıa la transferencia del dinero mediante el subprotocolo de liquidaci´ on del canal. F. Reembolso Una vez se ha liquidado el canal, las µ-monedas no utilizadas en operaciones de pago se retornar´ an a C. Se ha decidido que este reembolso no sea efectuado de forma autom´ atica por el Smart Contract para permitir a C decidir si quiere obtener el reembolso o bien reconvertir el canal para el pago a un nuevo vendedor. El procedimiento de transferencia de canal puede ser utilizado tambi´ en por Cpara crear un nuevo canal para cambiar las µ-monedas no gastadas y utilizarlas en un nuevo canal con otro vendedor M∗. Este cambio puede efectuarse en la ventana comprendida entre (TExp +∆T d) y (TExp + ∆T d + ∆T r). Estas operaciones de transferencia del canal permiten reducir los costes asociados las operaciones de transferencia sobre la blockchain. V. PROPIEDADES En esta secci´ on de describir´ an brevemente las principales propiedades del protocolo de gesti´ on de canales para compras equitativas. A. Anonimato Los usuarios CyM, (y Nsi es el caso) acceden al smart contract mediante sus direcciones de blockchain. Sin embargo, el canal se asocia al conocimiento de unos determinados valores. El usuario que conozca los elementos de la cadena de liquidaci´ on asociada al canal ser´ a el usuario que podr´ a efectuar la liquidaci´ on o la transferencia del canal. Por tanto, el usuario ejecuta el protocolo sin la necesidad de identificaci´ on. El hecho de tratarse de canales multi-hop, con posibilidad de transferencia del canal sin que se produzca un movimiento de saldos sobre la blockchain permite que un usuario haya participado en las operaciones de compra sin la necesidad de que su cuenta en la blockchain haya emitido ni recibido ninguna transacci´ on. B. Equidad La operaci´ on de compra se considera una aplicaci´ on de intercambio equitativo de valores. Por una parte, se realiza un pago y por otra se proporciona un servicio o producto. En este protocolo el intercambio se realiza sin la intervenci´ on de ninguna tercera parte de confianza. Para realizar este intercambio equitativo se procede a la ejecuci´ on de un subprotocolo off-chain, donde los mensajes se intercambian directamente entre los usuarios CyM. El procedimiento consta de tres pasos y podr´ ıa interrumpirse sin llegar a completar la operaci´ on. Los posibles puntos de interrupci´ on son los siguientes. •Despu´ es del primer paso del intercambio, donde C proporciona la µ−moneda WiC ,Mno sigue con el protocolo y no proporciona el producto o servicio. –En este caso Cno enviar´ a el elemento de prueba W(i+1)C. –La operaci´ on de compra se considera no realizada. Cno recibe el producto o servicio yMno puede incluir la µ−moneda en la operaci´ on de liquidaci´ on del canal o de transferencia ya que desconoce el elemento de prueba asociado a la ´ ultima µ−moneda. –En este primer escenario, efectivamente Mno va a poder cobrar la ´ ultima µ−moneda pero s´ ı que podr´ ıa cobrar todas las anteriores. Por tanto, el cliente si quiere eliminar el riesgo de perder parcialmente el ´ ultimo µ−pago, al no recibir el correspondiente servicio, puede ajustar el valor de la µ−moneda a cada servicio y eliminar completamente este conflicto. No obstante, es This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 189 Protocolo Basado en Blockchain para la Gestión de Canales para Microcompras Equitativas previsible que Mno tenga este tipo de conductas ya que por cometer este µ−fraude perder´ ıa las siguientes ventas al cliente y, por tanto, correr´ ıa el riesgo de perder m´ as que lo que ha ganado con este peque˜ no fraude. En todo caso, se trata de un riesgo controlado y regulado por el cliente, depende de ´ el anular o no este potencial problema. •Despu´ es del segundo paso del intercambio, Cno sigue el protocolo y no proporciona el elemento de prueba asociado a la µ−moneda, W(i+1)C.. –En este caso la compra se considera realizada. –Cdispone del elemento adquirido mientras que Mno puede incluir la µ−moneda en las operaciones de liquidaci´ on o transferencia del canal. –Al realizar un nuevo pago con el canal, C utilizar´ a la µ−moneda W(i+2)C.A partir de esta µ−moneda, Mpuede derivar el elemento de prueba de la operaci´ on de compra anterior W(i+1)C. –En este escenario un comprador ´ unicamente puede dejar sin validaci´ on una ´ unica µ−moneda por canal, lo cual entra dentro de los riesgos aceptables en operaciones de micropago. Por otra parte, el fraude asociado a la creaci´ on de canales para el robo de µ−monedas individuales se descarta teniendo en cuenta que la creaci´ on del canal implica unos costes de ejecuci´ on que hacen inviable conseguir un beneficio de la creaci´ on de un canal para proceder al robo de una µ−moneda. C. Transferibilidad El protocolo de compra se basa en el uso de un canal de pago establecido sobre blockchain. Este canal permite el pago desde un comprador Ca aun vendedor V. En un escenario simple de ejecuci´ on Mliquidar´ a el canal despu´ es de recibir los pagos con las µ−monedas asociadas al canal. Esta liquidaci´ on representar´ a una transacci´ on sobre la blockchain. Sin embargo, con el objetivo de incrementar la eficiencia del sistema se ha dise˜ nado el protocolo teniendo en cuenta la posibilidad de que los canales de pago sean multihop. En un canal multihop las µ−monedas pueden cambiar de manos diversas veces sin necesidad de que cada cambio de manos represente una transacci´ on en la blockchain. La operaci´ on de transferencia del canal permite realizar los m´ ultiples saltos del canal multihop. Si reas la recepci´ on de las µ−monedas el receptor, en lugar de realizar la liquidaci´ on del canal, opta por ejecutar la funci´ on de transferencia puede reorientar el canal para realizar pagos con el hacia un nuevo receptor. Los canales pueden prepararse para un n´ umero limitado de transferencias, ya que una transferencia ilimitada podr´ ıa desembocar a una p´ erdida de eficiencia del sistema y debe tenerse en cuenta que en el escenario habitual de ejecuci´ on los canales no son transferidos m´ as de un n´ umero reducido de veces. El protocolo tambi´ en contempla la posibilidad de que un usuario comprador no utilice todas las µ−monedas del canal antes de la fecha de expiraci´ on del canal. Estos fondos pueden reembolsarse en la cuenta del comprador mediante una operaci´ on de transacci´ on programada en el smart contract. Esta operaci´ on no se ha automatizado proporcionando al comprador la posibilidad de realizar una redirecci´ on del canal hacia un nuevo vendedor. D. Imposibilidad de Falsificaci´ on, Sobregasto y Doble Gasto El protocolo se ha dise˜ nado para impedir la falsificaci´ on de las µ−monedas as´ ı como su reutilizaci´ on o el uso de m´ as µ−monedas de las establecidas en el canal. •Todas las µ−monedas recibidas como medio de pago en el protocolo de compra deben pertenecer al canal asociado. Esta comprobaci´ on se realiza mediante la operaci´ on Hi(WiC ) == W0C, donde W0Cdebe coincidir con el valor almacenado dentro del elemento Γdel canal. •La reutilizaci´ on de una µ−moneda se evita mediante la comprobaci´ on Hi−j(WiC ) == WjC , donde ies el ´ ındice de la µ−moneda actual y jel ´ ındice de la µ−moneda utilizada en el ´ ultimo pago en el canal, por lo que idebe ser mayor que j. •La sobreutilizaci´ on se evita con dos procedimientos. Por una parte, el dinero correspondiente a las µ−monedas asociadas al canal queda depositado en el smart contract antes de iniciarse las operaciones de compra. Por otra parte el n´ umero de µ−monedas asociadas al canal es limitado y la ´ ultima µ−moneda del canal viene determinada por el elemento W(L−1)C.El vendedor no aceptar´ a ninguna µ−moneda que requiera una validaci´ on en la cadena de hash con m´ as de Loperaciones. E. Coste Reducido Un coste por pago reducido es una caracter´ ıstica fundamental de los µ−pagos ya que nunca debe superar el beneficio asociado a ese pago y mucho menos al valor de la cantidad transferida. El protocolo presentado en este trabajo reduce considerablemente el cose de una operaci´ on de pago This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 190 Payeras, Cabot, Mut, 2021. mediante criptomonedas mediante la creaci´ on de un canal de pago. Aunque el n´ umero de operaciones de pago que pueden realizarse es de coperaciones por canal, el n´ umero de transferencias sobre la blockchain se reduce a uno canal, si no se contemplan las operaciones de transferencia. Cuanto mas a largo t´ ermino sean las relaciones entre comprador y vendedor m´ as largas podr´ an ser las cadenas de µ−monedas asociadas al canal y mayor ser´ a la eficiencia del sistema. Por otra parte, el dise˜ no de canales multihop permite reducir el n´ umero de transferencias reales sobre la blockchain, ya que un canal transferible no requiere liquidaci´ on despu´ es de el uso entre los dos primeros usuarios. VI. CONCLUSIONES En este trabajo hemos presentado un esquema de microcompras, es decir un sistema de intercambio equitativo entre un micropago y el acceso al producto o servicio comprado. Los micropagos son pagos de cantidades muy reducidas donde el margen de beneficio es escaso con lo que el sistema no debe tener unos costes asociados que reduzcan sustancialmente o eliminen totalmente ese margen de beneficio. Para ello los mecanismos de seguridad y privacidad asociados a los micropagos deben dise˜ narse en consecuencia. En el caso de las criptomonedas la soluci´ on para implementar micropagos se encuentra en dise˜ nar protocolos de capa dos [12] en los que se evite que cada operaci´ on de pago represente una transacci´ on en la blockchain. Un canal, una vez abierto, permite la realizaci´ on de operaciones off-chain que no se materializaran sobre la blockchain hasta el momento de liquidaci´ on del canal. El art´ ıculo presenta un protocolo de gesti´ on de canales mediante smart contracts. El sistema se basa en el protocolo de micropagos sin blockchain presentado en [1]. Igual que en el protocolo de [1] el pagador construye una cadena de elementos donde se intercalan micromonedas y elementos de prueba que permitir´ an otorgar atomicidad a las operaciones de compra. El protocolo est´ a formado por una fase inicial de solicitud de servicio seguido por una operaci´ on on-chain en la que se crea el canal. El canal no est´ a asociado a un vendedor concreto, sino que este dispondr´ a de un ´ ıtem que le autentifica como el liquidador veraz del canal. A continuaci´ on, la operaci´ on de compra se realiza tantas veces como sea necesario de forma off-chain. Finalmente, el vendedor puede liquidar el canal con lo que se proceder´ a a la transacci´ on de transferencia de fondos sobre la blockchain. Hemos a˜ nadido al protocolo b´ asico las operaciones de transferencia del canal y reembolso para incrementar la eficiencia del sistema y evitar transacciones innecesarias. En el art´ ıculo se realiza un an´ alisis informal de las propiedades del sistema, incluyendo anonimato, equidad, transferibilidad, imposibilidad de falsificaci´ on, sobregasto y reutilizaci´ on de monedas as´ ı como una valoraci´ on de la eficiencia del sistema. Como trabajo futuro se pretende estudiar la reversibilidad del canal y realizar las modificaciones necesarias al protocolo para permitir pagos bidireccionales sobre el canal. Por otra parte, se realizar´ a la implementaci´ on del protocolo sobre una blockchain de tipo ethereum mediante la programaci´ on de los smart contracts que se encargaran de las operaciones on-chain del protocolo, como la creaci´ on y la liquidaci´ on del canal. AGRADECIMIENTOS El proyecto FeltiCHAIN (RTI2018-097763-B-I00) est´ a financiado por: FEDER/Ministerio de Ciencia e Innovaci´ on, Agencia Estatal de Investigaci´ on, (MCI/AEI/FEDER, UE). REFERENCIAS [1] Isern-Dey` a, A. P., Payeras-Capell` a, M. M., Mut-Puigserver, M., Ferrer-Gomila, J. L. (2013). ”Anonymous and Fair Micropayment Scheme with Protection against Coupon Theft.” International Journal of Adaptive, Resilient and Autonomic Systems (IJARAS), 4(2), 54-71. doi:10.4018/jaras.2013040103 [2] Galal H.S., ElSheikh M., Youssef A.M. (2019) ”An Efficient Micropayment Channel on Ethereum”. In: P´ erez-Sol` a C., Navarro-Arribas G., Biryukov A., Garcia-Alfaro J. (eds) Data Privacy Management, Cryptocurrencies and Blockchain Technology. DPM 2019, CBT 2019. Lecture Notes in Computer Science, vol 11737. Springer, Cham. https://doi.org/10.1007/978-3-030-31500-9 13 [3] Poon, Joseph, and Thaddeus Dryja. ”The bitcoin lightning network: Scalable off-chain instant payments.” (2016). [4] Di Ferrante, M. ”Ethereum payment channel in 50 lines of code.” Medium, June (2017). [5] Rivest, Ronald L., and Adi Shamir. ”PayWord and MicroMint: Two simple micropayment schemes.” International workshop on security protocols. Springer, Berlin, Heidelberg, 1996. [6] Wood, Gavin. ”Ethereum: A secure decentralised generalised transaction ledger.” Ethereum project yellow paper 151.2014 (2014): 1-32. [7] Luo, Xuan, et al. ”A payment channel based hybrid decentralized ethereum token exchange.” 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2019. [8] Tripathy, Somanath, and Susil Kumar Mohanty. ”Mappcn: Multihop anonymous and privacy-preserving payment channel network.” International Conference on Financial Cryptography and Data Security. Springer, Cham, 2020. [9] https://raiden.network/ [10] https://blog.althea.net/universal-payment-channels/ [11] G. Malavolta, P. Moreno-Sanchez, C. Schneidewind, A. Kate, and M. Maffei, ”Anonymous multi-hop locks for blockchain scalability and interoperability” in Network and Distributed System Security Symposium (NDSS), 2019. [12] Lewis Gudgeon, Pedro Moreno-Sanchez, Stefanie Roos, Patrick Mccorry, and Arthur Gervais. ”SoK: Layer-Two Blockchain Protocols”. In International Conference on Financial Cryptography and Data Security, pages 201-226. Springer, 2020. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) 191