Por Sergio Lerner, Jefe de Innovación Científica de IOVLABS

[TL;DR]Inventamos un nuevo tipo de cadena lateral de minería fusionada llamada SyncChain, que permite conectores entrantes y conectores salientes rápidos (entre Bitcoin y RSK, esto es tan bajo como 30 minutos para conectores entrantes y como 2 horas para conectores salientes) y se pueden parametrizar para proteger incondicionalmente el conector de los gastos dobles. Esta es una gran mejora de las cadenas laterales existentes que requieren cientos de confirmaciones de bloque y cuya seguridad se basa solo en suposiciones criptoeconómicas. El protocolo SyncChain, que se construyó en base a algunas ideas que publicamos en 2016, es ortogonal al método utilizado para desbloquear los conectores salientes; un diseño interesante es crear una SyncChain federada. Finalmente, analizamos los pros y los contras para que RSK migre de una cadena lateral SPV de Bitcoin a una SyncChain de Bitcoin, y establecemos un plan tentativo para una actualización de la red SyncChain. 

Introducción

Cuando se diseñó RSK inicialmente, uno de los objetivos de diseño era mantener lo más posible a RSK independiente de Bitcoin para evitar que cualquier falla en Bitcoin afectara a RSK. Durante el período 2015-2016, Bitcoin estuvo bajo una presión continua y amenazas de bifurcaciones duras contenciosas, y las tarifas de transacción aumentaron considerablemente, evitando el uso de Bitcoin para la inclusión financiera, que requiere pagos de poco valor. Por estas razones, RSK adoptó un consenso de minería fusionada por encima de un protocolo de superposición similar a la contraparte. La minería fusionada proporciona total independencia (incluso de las reversiones de bloque de Bitcoin) mientras que las superposiciones no. Utilizamos pruebas de SPV para probar el consenso extranjero, exactamente por la misma razón. 

El riesgo de que Bitcoin se destruya se ha diluido con el tiempo. Por lo tanto, podemos volver a considerar los requisitos para el conector bidireccional y examinar nuevamente el espacio de diseño buscando mejores alternativas.

La seguridad del puente SPV

En varias publicaciones de blog anteriores analizamos cómo funciona el conector de RSK. Una de las propiedades del conector de RSK es que la inversión del blockchain de bitcoin no implica la inversión del RSK Blockchain. Por lo tanto, para evitar un doble gasto, RSK requiere la mayor seguridad de que el blockchain de Bitcoin no retrocederá más allá de la transacción de conectores salientes, como esperar 100 confirmaciones de bloque de Bitcoin. Supongamos que el compromiso de minería fusionada es de alrededor del 50 %, y hay un gran grupo de minería maliciosa que llamaremos Mallory, que tiene el 51 % del hashrate de RSK (25 % del hashrate de Bitcoin). Mallory podría intentar usar todo su hashrate para crear un blockchain falso de solo encabezado y alimentarlo al puente, ocasionando la aceptación del puente de cualquier transacción falsa que Mallory afirme. Esta cadena de encabezado falsa no sería una blockchain de Bitcoin válida y, por lo tanto, Mallory no interrumpiría la blockchain de Bitcoin, pero no podría obtener recompensas de bloque durante la preparación del ataque. RSK está actualmente protegido de este ataque porque los funcionarios de la federación no emitirán un mensaje de registro de conector entrante si su mejor cadena local no coincide con la mejor cadena de Bitcoin cargada en el contrato del puente. Sin embargo, podemos pensar que si el conector entrante basado en SPV se descentralizó al máximo eliminando la intervención de la federación, entonces el ataque podría tener éxito. Llamaremos a esto un ataque de “conector entrante falso”. El costo de realizar un conector entrante falso para Mallory en una variante desprotegida de RSK es de aproximadamente 10 millones de dólares en electricidad. Aunque el ataque de conector entrante falso parece fácilmente atribuible al “minero desaparecido” al mirar las bases de monedas de bitcoin, Mallory podría afirmar que sus sistemas fueron pirateados y culpar a una parte desconocida. 

También está el ataque de doble gasto de conector entrante. Ese ataque requiere informar una mejor cadena alternativa al contrato del puente y, al mismo tiempo, aislar a los funcionarios de la federación para hacerles creer que esta mejor cadena alternativa es la única que existe. El costo del ataque sigue siendo de 10 millones de dólares en electricidad, además de piratear a los funcionarios, pero el saqueo ahora no es una creación arbitraria de bitcoin, sino solo el doble de la cantidad inicialmente invertida.

El ataque opuesto es el doble gasto del conector saliente. En este ataque, Mallory realiza un conector saliente y luego revierte el RSK blockchain al punto donde se encuentra la transacción que ordena el conector saliente. Nuevamente, el ataque tiene un alto costo en electricidad, pero, si la cantidad de bitcoins a robar es lo suficientemente alta, entonces el riesgo existe. Tenga en cuenta que RSK tiene una herramienta de monitoreo de red llamada Armadillo que permite alertas descentralizadas para prevenir ataques de minería fusionada “gratuitos”, pero este ataque aún es posible.

Otra desventaja del puente SPV es que requiere 100 confirmaciones de bloque de Bitcoin (o bloques RSK equivalentes para la misma dificultad acumulativa) para las conexiones entrantes y salientes. Esta situación perjudica el uso. ¿Podemos hacerlo mejor que el puente SPV en términos de seguridad y uso?

La seguridad de los conectores bidireccionales

Para comparar los diseños de los conectores bidireccionales, definimos 8 protecciones que evitan los ataques de doble gasto o el simple robo de bitcoins por parte de los mineros. No consideramos los ataques de ningún otro grupo. Estas protecciones se aplican a cualquier sistema de conexión S que acepte transferencias entre cadenas en dos blockchains de prueba de trabajo. Las protecciones se definirán en función de una suposición de seguridad o del costo del ataque (una suposición sobre el presupuesto del atacante). Las protecciones se ordenan de la más fuerte (1) a la más débil (8), pero un sistema puede ofrecer más de una protección. Un sistema S puede no estar completamente caracterizado por una combinación de las protecciones descritas porque un sistema podría usar diferentes protecciones para las conexiones entrantes y las conexiones salientes. Dado que el conector saliente es siempre el subprotocolo más débil, nos enfocaremos en la seguridad del conector saliente para todos los protocolos presentados en esta sección, ya que los atacantes elegirían el punto más débil para atacar. Además, un sistema puede requerir diferentes supuestos de solidez y vitalidad, pero en esta categorización nos centramos en la solidez. También en aras de la simplicidad, estamos ignorando otros ataques complementarios en la red, como la posibilidad de aislar un nodo. Tenga en cuenta que, en general, un ataque de doble gasto no causa una pérdida de recompensas de bloque para el atacante: si un atacante revierte un blockchain para crear en privado una nueva mejor cadena, esta nueva cadena se recompensará a sí misma, por lo que solo se pierden las recompensas de otros mineros. La única excepción a esta regla es la protección proporcionada por Armadillo, o algunos algoritmos de consenso (generalmente rotos) que califican los bloques por tiempo de recepción [1] [2] [3].

Dado que Bitcoin no puede evaluar la prueba acumulativa de trabajo de otra cadena lateral, asumimos la existencia de algún tipo de grupo de firma múltiple dinámico o estático para indicar conectores salientes y recibir conectores entrantes. Sin embargo, ignoramos cualquier ataque que involucre a titulares maliciosos de la firma múltiple que recibe las monedas vinculadas. Asumimos que los titulares de claves son 100 % honestos o que ejecutan Módulos de seguridad de hardware (HSM) que les impiden acceder a las claves privadas, como lo hace RSK.

En la siguiente tabla, comparamos RSK con otros tipos de conectores bidireccionales, pero modificándolos para conectar Bitcoin con una cadena lateral de minería fusionada. Esto ayuda a lograr una comparación justa de protocolos.

La primera protección “Seguridad incondicional”, lo que significa que bajo las reglas del protocolo para S, no pueden ocurrir gastos dobles. La siguiente es “Inviabilidad computacional” (2), que representa la imposibilidad de gastar dos veces en S con el supuesto de que el atacante no puede realizar una tarea computacional difícil. La siguiente protección es “Bitcoin M.A.D.” (3). M.A.D. significa destrucción mutua asegurada. Bitcoin M.A.D. protege un protocolo si, para realizar un doble gasto, el atacante se ve obligado a revertir la cadena principal, lo que afectaría el precio del token nativo de la cadena principal y, por lo tanto, los incentivos mineros a largo plazo para mantener la cadena principal sin daños también se aplican al conector. Se puede aplicar a la cadena lateral el mismo concepto que en (5). La protección “Conciencia de ataque largo” (4) es cuando la red puede detectar de antemano acciones maliciosas de un grupo de mineros confabulados. RSK más el sistema de monitoreo Armadillo tiene una variante criptoeconómica de Conciencia de ataque largo: el atacante revela que está preparando un ataque o necesita renunciar a las recompensas de bloque por los bloques que produce en privado. La siguiente protección es “Pérdida de recompensas de bloques de Bitcoin” (7), que representa todos los sistemas criptoeconómicos basados en pruebas de SPV donde el atacante necesita minar bloques con una transacción falsa para engañar al sistema en el desbloqueo de monedas en una cadena que no estaban bloqueadas en la cadena opuesta. El protocolo actual del conector RSK (con el sistema de monitoreo Armadillo) tiene esta protección como así también XCLAIM y TBTC. Las otras categorías se explican por sí mismas.

El diseño de SyncChain 

Un SyncChain proporciona una garantía de seguridad que es mucho más sólida que la proporcionada por la criptoeconomía. Proporciona seguridad incondicional a las conexiones entrantes y salientes. Con SyncChain podemos eliminar el riesgo de doble gasto y, por lo tanto, no sobrecargar la red de minería fusionada. En este informe técnico describimos el diseño de SyncChain en todas sus variantes. En esta publicación de blog más corta solo presentaremos las ideas en las que se basa SynChain y la más simple de sus variantes. Todas las variantes se basan en tres componentes: doble paternidad diferida, vinculación de transacciones de conectores y anclaje de base de monedas. La idea raíz de SyncChain (doble paternidad) se esboza en una de nuestras publicaciones de blog en 2016. La idea es que los bloques de cadena lateral deben especificar tanto un padre de cadena lateral como un padre de cadena principal. El estado heredado antes del procesamiento del bloque de cadena lateral corresponde a un estado después de que ambos padres hayan sido procesados, y la reversión de uno de los padres causa la reversión del bloque hijo de cadena lateral. Pero esta técnica no se puede usar para una cadena lateral con una velocidad de bloqueo más alta que la de la cadena principal, ya que una inversión del bloque de la cadena principal puede causar una inversión de muchos bloques de la cadena lateral. Se necesita una nueva forma de enredo que soporte mayores tasas de bloqueo pero que no sufra reversiones prolongadas.

Doble paternidad diferida

La doble paternidad es una técnica que consiste en enredar la cadena principal y la cadena lateral. La técnica se basa en que cada bloque de cadena lateral tenga dos padres, uno en la cadena lateral y el otro en la cadena principal. Pero no usamos esta técnica tal como está, usamos una variación de doble paternidad que llamamos Doble paternidad diferida (DDP). Primero, para simplificar nuestra terminología, llamaremos al padre de la cadena principal un “punto de control”, pero el lector no debe confundir un punto de control de sincronización con otros sistemas de puntos de control basados en las autoridades [4] [5]. Con DDP, el punto de control se ha quedado atrás con respecto a una cantidad de bloques (K bloques en promedio) según las marcas de tiempo y el recuento de confirmación de bloque de la cadena principal. Por ejemplo, un valor realista para K es 3, lo que obliga a los puntos de control a retrasarse en un promedio de 30 minutos. El siguiente diagrama muestra un ejemplo para K = 3.

Doble paternidad diferida

Como se describió anteriormente, el problema con el enredo inmediato es que la reversión de un bloque de Bitcoin provoca automáticamente la reversión de aproximadamente 20 bloques RSK, lo que no es tolerable desde una perspectiva UX pero, lo más importante, es un riesgo de seguridad de liquidación de transacciones. Con el punto de control retrasado, la RSK blockchain solo se revierte si se revierten más de K bloques de la cadena principal. Para simplificar las explicaciones, a lo largo de esta publicación de blog, asumiremos que el intervalo de bloqueo promedio de RSK es de 30 segundos y el intervalo de bloqueo promedio de Bitcoin es de 10 minutos. Luego, si el blockchain de Bitcoin se revierte, R bloquea donde R> K, entonces RSK blockchain se revertirá (R-K) * 20 bloques. En el siguiente diagrama, podemos ver que no hay eliminaciones sorpresa en RSK si solo se invierte un solo bloque de Bitcoin.

La reversión de un solo bloque de cadena principal no causa reversión en SyncChain

 

El valor mínimo para K es 1, lo que significa que un bloque solo se puede verificar si tiene un bloque adicional para confirmación.

Nodos duales

Un SyncChain requiere que cada cliente de cadena lateral ejecute tanto una instancia del nodo de la cadena principal como el nodo específico de la cadena lateral. La razón principal por la que inventamos SyncChain es para evitar que una rama de blockchain de Bitcoin no válida se presente a un contrato de puente basado en SPV como una cadena SPV válida (solo encabezado), porque una prueba de SPV puede ocultarse de la red honesta, y eso reduce la tensión M.A.D. Para maximizar la tensión, queremos que la transparencia detecte, juzgue y eventualmente castigue a los mineros tan pronto como comiencen a extraer bloques para un ataque, y antes de que finalice el ataque. Por lo tanto, debemos asegurarnos de que cualquier bloque que acepte el puente para validar un conector entrante o uno saliente esté completamente expuesto (tanto el encabezado como la carga útil de la transacción) y pueda incluirse en la blockchain de Bitcoin, según lo definido en el software de referencia de Bitcoin Core. Por lo tanto, un nodo SyncChain debería ejecutar el nodo de referencia de la cadena principal, junto con el nodo de solo cadena lateral. En otras palabras, un nodo synchain ejecuta una instancia de bitcoind y una instancia de rskj.

Un usuario todavía puede ejecutar únicamente el nodo solo de cadena lateral (rskj), pero no podrá validar las conexiones entrantes y salientes. En ese sentido, se convierte automáticamente en un nodo “ligero” de SPV, con el mismo modelo de seguridad que obtienen los clientes de SPV, tan pronto como haya una transacción de conector entrante o conector saliente. 

Para crear una doble paternidad diferida, necesitamos un Algoritmo de selección de punto de control (CSA). Un CSA es un algoritmo de consenso que selecciona el punto de control de la cadena principal y valida si un punto de control se selecciona correctamente. Un CSA debe basar esencialmente sus decisiones en las marcas de tiempo del bloque. Pero las marcas de tiempo de bloque en Bitcoin no reflejan los tiempos de reloj de pared y menos aún, de un reloj global. A El informe técnico de SyncChain presentados algoritmos simples RTA (MedianTime11 y AdjustedTime), por lo que no vamos a analizarlos nuevamente aquí. 

Puntos de control y procesamiento de bloques

En el encabezado del bloque de cadena lateral, el punto de control se define mediante un número de bloque de cadena principal (checkPointBN) y un hash de bloque de cadena principal (checkPointHash). Es posible usar un encabezado de tamaño reducido del resumen de hash para ahorrar espacio. 

Cada nodo de cadena lateral debe ejecutar un nodo de cadena principal (bitcoind en el caso de RSK) para controlar la corrección de los puntos de control en los encabezados de bloque RSK. Si el hash del punto de control RSK no coincide con el hash del bloque Bitcoin al que se hace referencia por el número de bloque, entonces el bloque RSK es “temporalmente inválido”. El bloque RSK podría reconsiderarse más tarde si se reorganiza la mejor cadena de Bitcoin.

No todos los bloques de Bitcoin serán un punto de control: los valores de checkPointBN no cubren todos los bloques y habrá lagunas. Cuando un bloque checkPointBN se refiere a una transacción de conector entrante en un bloque de Bitcoin, o salta sobre una transacción de conector entrante omitiendo el bloque, entonces el consenso de RSK ordena que el bloque de RSK relacionado DEBE incluir una transacción que envíe un mensaje de conector entrante al contrato de puente para liberar inmediatamente las monedas relacionadas conectadas de forma entrante. El consenso también exige que las transacciones de conector entrante tengan prioridad sobre las demás, lo que significa que las preceden en el bloque. 

Vinculación de transacciones de conectores 

Todas las transacciones de conectores entrantes y conectores salientes de Bitcoin están vinculadas entre sí. Esto se hace por varias razones. Una es evitar los ataques en los que el atacante reorganiza las blockchain de Bitcoin y las RSK blockchain para gastar dos veces los fondos de la firma múltiple de conectores, donde el mismo atacante ha entrado o salido. La vinculación reduce en gran medida la superficie de ataque. Pero una segunda razón se relaciona con la forma en que se protegen los conectores salientes y nos permite demostrar la inviabilidad de los gastos dobles de dichos conectores. “El siguiente diagrama muestra un conector entrante y un conector saliente para una cadena lateral federada como RSK. Los fondos fijos están protegidos por una firma múltiple federada, y las partes que tienen las claves privadas de esta firma múltiple se denominan funcionarios. En la cadena que se muestra, hay dos transacciones internas adicionales llamadas link-in (entrada) y link-out (salida) que explicaremos más adelante. La línea roja corresponde a una cadena de referencias que utilizan entradas/salidas “ficticias”. Todas las transacciones firmadas por funcionarios están vinculadas a esta cadena. Debido a que cada transacción consume una entrada ficticia y crea una salida ficticia, solo hay una salida de transacción no gastada en todo momento. Llamamos a este UTXO especial, el loken (forma abreviada de token de enlace). Usamos “cadena de loken” para referirnos a la cadena de transacciones que consumen y crean el loken. El valor del loken será un pequeño valor por encima del límite de polvo en Bitcoin.

 

La cadena loken

Se debe tener cuidado al actualizar los funcionarios de la federación agregando o quitando miembros. Esto desencadena, en RSK, un proceso prolongado y retrasado por la fuerza en el que los fondos se transfieren automáticamente de una antigua firma múltiple de federación a una nueva. Todavía no hemos propuesto un proceso de migración adaptado a un SyncChain, pero creemos que esto se puede hacer de forma segura.

Transacciones de conector entrante

El smart contract puente, que controla todos los procesos de conector entrante y conector saliente, ordena automáticamente a los funcionarios el reenvío de las monedas recibidas en la transacción de conector entrante a un UTXO diferente, cuya dirección puede ser igual o diferente a la del conector entrante, pero está igualmente controlado por la misma federación. Este reenvío inicial de monedas recibidas se realiza en una transacción de Bitcoin que llamamos link-in. La transacción link-in consume el loken y crea un nuevo loken. El siguiente diagrama de ejemplo muestra cómo una transacción iniciada por el usuario (“Peg-in Tx” en el diagrama) en el bloque 1 de la cadena principal desencadena acciones desde el puente cuando el bloque 1 es controlado por el bloque A de la cadena lateral. La primera acción es un período de espera inicial de 3 bloques de cadena lateral, y luego, en el bloque B, el puente ordena a los funcionarios de la federación que firmen y difundan la transacción link-in, que consume inmediatamente los fondos entrantes y los traslada a la dirección de vinculación final de múltiples firmas.

El proceso entrante

Las monedas de la cadena lateral se liberan inmediatamente en el bloque A, pero no puede producirse ninguna conexión saliente hasta que la transacción link-in se incluya en la cadena principal. 

Transacciones de conector saliente

Demostramos en nuestro artículo anterior que una cadena lateral de prueba de trabajo no puede proporcionar una atomicidad completa de las entradas y salidas sin la colaboración de los mineros en el proceso entrante/saliente. El atacante puede revertir alternativamente la cadena principal, luego la cadena lateral y, más tarde, la cadena principal nuevamente, y finalmente puede mantener los tokens de la cadena principal y los tokens de la cadena lateral. Ahora mostraremos cómo se puede lograr la protección criptoeconómica sin la ayuda de los mineros, y cómo se puede lograr una protección incondicional completa con la ayuda de los mineros.

Observamos que un sistema de cadena lateral completamente federado como Liquid, posiblemente basado en el consenso de tipo PBFT, no puede proporcionar una atomicidad completa de los conectores salientes porque tiene un carácter definitivo de liquidación. Una vez que se liquida una transacción en Liquid, incluso si Bitcoin se revierte, la cadena lateral no se revertirá para que coincida con la mejor cadena neta de Bitcoin.

Protocolos de conector saliente

Encontramos tres protocolos diferentes para lograr un M.A.D. y garantías incondicionales, basadas en diferentes supuestos para agregar al consenso estándar de Nakamoto. En las siguientes secciones describimos brevemente cada una.

• Conector saliente para una SyncChain con Preferencia de la cadena más alimentada (More-Populous-Chain-Wins, MPCW)
• Conector saliente para una SyncChain Sincronizada en T (T-Synchronized, TS)
• Conector saliente para una SyncChain GHOST-CSC (no sincronizada en T)

En nuestro artículo anterior, analizamos las tres variantes. En este artículo, solo mostraremos TS SynChain. Para mover los tokens de una cuenta en RSK a Bitcoin, se crea una transacción RSK llamada Solicitud de conector saliente que transfiere el RBTC al smart contract del puente. En la siguiente figura, esta transacción se ha incluido en el bloque con la etiqueta A. Después de un pequeño número de confirmaciones del bloque RSK (como 3), el puente crea una Plantilla de transacción de salida que contiene marcadores de posición para que los funcionarios de la federación inserten sus firmas. Esta plantilla puede usar el estándar de transacción de Bitcoin parcialmente firmada (PSBT) . Luego, el puente solicita a los funcionarios de la federación que lo firmen y este evento se denomina Solicitud de salida. Esto ocurre en el bloque B de RSK en la figura. La transacción de salida debe contener una salida de datos especial que comprende un OP_RETURN, el hash de bloque para el bloque A y el número de bloque de A. Llamamos a esta carga de datos acceso del punto de control de la cadena lateral. Este acceso puede contener uno o más puntos de control de cadenas laterales reales. Observamos que los puntos de control de la cadena lateral junto con los puntos de control de la cadena principal producen referencias de puntos de control recíprocos.

Proceso de transacción de conector saliente

Una vez que la mayoría de las firmas funcionales se recopilan para la transacción de salida, la transacción se transmite y se espera que se incluya pronto en la blockchain de Bitcoin. En la figura, esto ocurre en el bloque 4 de Bitcoin. La transacción de salida debe ser parte de la cadena de loken (debe consumir el loken y crear un nuevo loken).  Después de que la transacción de salida se incluya en un bloque 4 de Bitcoin, el bloque 4 debe ser referenciado por el punto de control de un bloque RSK (u omitido por un punto de control, lo que causa el mismo efecto). El punto de control para un bloque 4 generalmente se retrasará alrededor de 30 minutos. En la figura, el bloque 4 está referenciado en el bloque C de RSK. Luego, el puente esperará algunos bloques (166 en la figura). Una vez que finaliza el período de espera, el puente creará la Plantilla de transacción de conector saliente y solicitará a los funcionarios de la federación que la firmen. La transacción de conector saliente es la transacción final que realmente paga al usuario de Bitcoin la cantidad requerida. Como todas las transacciones de conector y enlace restantes firmadas por la federación, se vincula a la cadena loken. La transacción de conector saliente se incluirá en un bloque de Bitcoin, y esto ocurre en el bloque 11 de la figura. Después de aproximadamente 30 minutos, será referenciado por un punto de control RSK, y el loken estará disponible para otras transacciones de enlace de entrada o salida. Todo el proceso de separación, con un promedio de 2 horas y 10 minutos, requiere dos rondas de firmas de federación y produce dos transacciones de Bitcoin. Si se confirma una transacción de conector entrante mientras una transacción que consume un loken está esperando ser incluida en la cadena principal, el conector entrante se pondrá en cola. De hecho, muchas transacciones link-in y de conectores salientes podrían unirse en un lote, teniendo salidas/entradas de destrucciones y una sola creación de loken.

Seguridad del conector saliente

Las siguientes secciones analizan algunos ataques teóricos y nosotros mostramos cómo los resiste SyncChain. El ataque más importante a cualquier sistema de aceptación de criptomonedas es el doble gasto. Para intentar un doble gasto, el atacante podría intentar revertir RSK, revertir Bitcoin o revertir ambos. Actualmente, RSK es minería fusionada entre el 35 % y el 50 % de los mineros de Bitcoin. En este artículo, asumimos que el hashrate de RSK es más bajo que Bitcoin y, por lo tanto, si un atacante revierte Bitcoin, debido a la minería fusionada, también tiene la oportunidad de revertir ambas cadenas. 

Transacciones de conector saliente de doble gasto al revertir solo RSK 

Revertir RSK parece ser el camino más fácil para el doble gasto, ya que asumimos que el hashrate de RSK es más bajo que el de Bitcoin. Hemos visto cómo se sincronizan las transacciones de conector saliente, porque los bloques RSK dependen de los bloques de Bitcoin. Sin embargo, en la otra dirección, la sincronización no está garantizada. Por lo tanto, para los conectorer salientes, forzamos una transacción de enlace de salida en Bitcoin. La marca de tiempo de la transacción link-out establece un horizonte que RSK no puede superar sin realizar la solicitud de conector saliente correspondiente.

El consenso de Nakamoto establece reglas claras para cada aspecto del manejo de blockchain, excepto cuando una transacción se considera resuelta. Esto se deja a cada usuario, y la única guía que se da es que cuantas más confirmaciones de bloque, menor es la probabilidad de reversión. Para garantizar la inviabilidad de la duplicación de gastos en el conector de salida, debemos agregar al Consenso de Nakamoto en la cadena lateral una condición que debe cumplirse para aceptar transacciones. Primero, presentamos una definición: Un nodo de red está sincronizado en T si su mejor cadena local está T segundos atrás de la hora local actual. Para construir una SyncChain necesitamos que la cadena lateral cumpla con la siguiente nueva condición: los nodos solo aceptan una transacción como liquidada si están sincronizados en T. También podríamos aceptar la transacción W si se confirma mediante una gran cantidad de dificultad acumulativa, pero ahora usaremos la definición más simple posible. 

Debido a la propiedad de sincronización T, podemos ver que cualquier ataque que revierta la cadena lateral debe agregar al menos un bloque de cadena lateral con marca de tiempo más allá de la marca de tiempo del bloque C, donde el bloque 4 está marcado.  Por lo tanto, siempre que el tiempo entre el bloque 4 y el bloque C sea mayor que T, la cadena del atacante (en la cadena lateral) nunca puede confirmar las transacciones. Esto supone que la hora local del nodo no se revirtió. 

Transacciones de conector saliente de doble gasto al revertir Bitcoin y RSK (pero reproduciendo más tarde el tx del conector saliente)

Una posible forma de realizar un ataque de doble gasto es tratar de revertir la blockchain de Bitcoin antes de la transacción link-out y, al mismo tiempo, revertir la blockchain RSK antes de la solicitud del conector saliente, creando una nueva rama de Bitcoin que tiene tanto las transacciones link-out como las de conector saliente, pero en un bloque que aparece mucho más tarde. Por ejemplo, el atacante revierte 10 bloques de Bitcoin y extrae otros 10 bloques sin transacciones de conexiones, y finalmente agrega un undécimo bloque que contiene tanto el enlace de salida como el conector saliente. Suponiendo mineros racionales deshonestos, una reversión de 10 bloques cuesta aproximadamente 1,5 millones de dólares (1) y, por lo tanto, esa sería la cantidad máxima que la transacción de conexión saliente puede transferir. Pero si no queremos seguridad incondicional, entonces debemos hacerlo mejor con el anclaje. Con el anclaje, podemos evitar que la transacción de salida se traslade a bloques futuros.

Anclaje de conector saliente

La manera más fácil de anclar una transacción a un bloque específico sería agregando a Bitcoin un nuevo código de operación OP_CHECK_INPUT_BLOCK_HASH, que recibe un hash de bloque como argumento en The Stack e invalida el bloque si el hash del bloque dado no coincide con el hash del bloque donde se creó la entrada que se está gastando. No creemos que este nuevo código abierto sea aceptado por la comunidad de Bitcoin porque puede producir Bitcoins menos fungibles que otros. Otra alternativa de código abierto que puede hacer el mismo truco es OP_CHECK_INPUT_BLOCK_TIME. Este código abierto invalidaría la transacción si el bloque correspondiente a la entrada que se está gastando tiene una marca de tiempo más alta que el argumento del código abierto. En contraste, este código abierto cambia mucho menos la fungibilidad. Sin embargo, sin ningún nuevo código abierto, todavía hay una manera de lograr el mismo resultado y es consumir en las transacciones de conector saliente una salida de una transacción de coinbase que existe en un bloque B entre los bloques de transacciones link-out y de conector saliente. La transacción de salida sería inválida si B se revierte, y la única forma de eliminar el enlace de salida sería revertir B. La desventaja es que debido a que los resultados de la transacción coinbase tienen un período de vencimiento de 100 bloques, este enlace introduce un retraso de 100 bloques para el conector saliente. Si bien la transacción de conector saliente no podrá incluirse antes del período de 100 bloques, la transacción de conector saliente puede firmarse y publicarse mucho antes y, por lo tanto, el usuario tiene una garantía muy sólida de que se producirá la transacción de conector saliente. Para vincular el conector saliente a una coinbase, RSK puede solicitar que los mineros de minería combinada de RSK incluyan una salida adicional que pague una cantidad de 1 satoshi (2) a una dirección de federación específica, y ese satoshi se consume en la transacción de conector saliente.

Nota (1): De acuerdo con el sitio web crypto51.app.

Nota (2): No hay necesidad de superar el límite de “polvo” porque las transacciones de coinbase no se reenvían a través de la red antes de su inclusión en un bloque

Proceso de conector saliente con anclaje de coinbase

Migración de RSK a una SyncChain

Aunque SyncChain ofrece muchos beneficios sobre una cadena lateral SPV, es demasiado pronto para decir cuándo y cómo RSK podría hacer la transición para convertirse en una SyncChain. Hay beneficios pero también existen riesgos en la migración. La codificación, las pruebas, las simulaciones y las auditorías de seguridad deben validar cada decisión de diseño. Sin embargo, tener un diseño tan limpio que proporciona tantos beneficios tanto de usabilidad como de seguridad es reconfortante. Tan pronto como se hayan concluido todas las etapas de I + D, abriremos la discusión para una migración a SyncChain y, con suerte, con los comentarios de la comunidad RSK, podremos ver la migración en 2020 o 2021. 

Resumen

En esta publicación presentamos SyncChain, un nuevo tipo de cadena lateral que permite una reducción de 32x en el tiempo de conector entrante de 16 horas a 30 minutos. El tiempo para el conector saliente también se puede reducir de 16 horas a aproximadamente 1,6 horas, si mantenemos un limitador de velocidad, de modo que no se transfieran más de 38 BTC por hora. Además, presentamos una variante que utiliza el anclaje de coinbase para proporcionar seguridad al conector saliente incondicional, con un tiempo de conector saliente de 16 horas, que es menos de lo que RSK requiere actualmente teniendo solo seguridad criptoeconómica. También propusimos un nuevo código abierto OP_CHECK_INPUT_BLOCK_HASH para Bitcoin que permite los conectores salientes con seguridad incondicional en cuestión de horas y sin ningún límite de velocidad. 

Incluso si el conector saliente actual de RSK SPV también podría lograr confirmaciones de bloque del conector entrante y del conector saliente más bajas, si aumentaba el compromiso de minería de fusión, SyncChain ofrece un número menor de confirmaciones para el mismo nivel de compromiso. 

La syncchain también proporciona otros beneficios secundarios como: 

1. Reduce la cantidad de código que RSK ejecuta en consenso en rskj: parte de esa funcionalidad de código ahora es proporcionada directamente por bitcoind. 
2. Dependiendo del protocolo seleccionado, proporciona seguridad incondicional u obliga a un ataque a RSK a convertirse en un ataque a Bitcoin: la propiedad M.A.D. en la teoría de juegos.
3. Permite conectores entrantes de direcciones cruzadas, como invertir en un fondo colectivo directamente desde Bitcoin

SyncChain también tiene algunas desventajas menores. Por ejemplo, SyncChain no puede proporcionar una determinación de liquidación simplificada. Teniendo en cuenta los pros y los contras, SyncChain es ciertamente un protocolo superior para las cadenas laterales de Bitcoin.

Referencias

[1] Ren Zhang y Bart Preneel. Publish or perish: A backward-compatible defense against selfish mining in bitcoin [Publicar o perecer: una defensa retrocompatible contra la minería egoísta en bitcoin]. En Cryptographers’ Track en la Conferencia RSA, páginas 277–292. Springer, 2017

[2] A proposal to Modify Satoshi Consensus to Enhance Protection Against 51% Attacks [Una propuesta ara modificar el consenso de Satoshi para mejorar la protección contra ataques del 51 %]. A Penalty system for Delayed Block Submission [Un sistema de penalización por envío demorado en bloque].

https://www.horizen.global/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-Horizen.pdf

[3] Delaying chain reorgs [Retraso de las reorganizaciones de la cadena] .

 https://bitslog.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

[4] Transaction Finality through Ledger Checkpoints [Finalidad de la transacción a través de los puntos de control del libro mayor] ( https://ieeexplore.ieee.org/document/8975825 o https://github.com/MuhammadNurYanhaona/checkpoint-paper/blob/master/checkpoint-paper-reviewed.pdf)

[5] Securing Proof-of-Work Ledgers via Checkpointing [Asegurar los registros públicos de evidencia de trabajo mediante Checkpointing] ( https://eprint.iacr.org/2020/173.pdf )