Poniendo fin al debate Bitcoin vs blockchain: Gideon Greenspan de MultiChain (1)

Bitcoin

(OroyFinanzas.com) – El debate sobre Bitcoin vs blockchain está latente desde hace mucho tiempo. ¿Puede existir una cadena de bloques (blockchain) sin bitcoins? ¿tiene sentido? Mientras que muchos defienden que Bitcoin y blockchain son inseparables, otros prefieren dejar de lado la criptomoneda para centrarse en la tecnología que la sustenta. Mucho se ha opinado sobre este tema en foros, blogs, redes y medios de comunicación especializados. En OroyFinanzas.com hemos encontrado relevante la postura de Gideon Greenspan de MultiChain, en un texto titulado “Poniendo fin al debate Bitcoin vs blockchain”, en el que Greenspan expone por qué desde su punto de vista, ambas posturas están en lo cierto. El autor defiende además que ambas opciones (cadenas de bloques con token y cadenas de bloques sin token) tienen aplicaciones útiles en diferentes ámbitos. Greenspan concluye que, a pesar de ello, ambas comparten algo muy importante: ofrecen la posibilidad de generar consenso en una base de datos distribuida. A continuación presentamos la traducción en castellano de la primera parte del texto de Gideon Greenspan, en la que adentra al lector en su argumento. En otro artículo, veremos la segunda parte del texto y las conclusiones finales a las que llega Greenspan.

¿Existe valor en una cadena de bloques (blockchain) sin una criptomoneda?

Este debate existe desde hace un tiempo, pero durante el último mes ha habido un serio repunte sobre ello. Las preguntas que deberíamos hacernos son:

¿Existe valor en una cadena de bloques (blockchain) sin una criptomoneda? ¿Y pueden estos “libros mayores de contabilidad compartidos sin token” ser denominados cadenas de bloques (blockchains)?

Así que me he leído el artículo de Bailey, he visto el vídeo de Tim, he leído este texto de Nasdaq, he seguido cada explicación de Richard, y hasta he tenido mi propio debate (ver comentarios) con Chris DeRose de la Counterparty Foundation.

Una cosa que Chris hace bien es reducir todo a la pregunta: ¿es la blockchain una innovación económica o una innovación informática? La implicación es que si las blockchains son una innovación puramente económica, no tienen sentido las cadenas de bloques sin criptomonedas. Por ello voy a exponer mi postura inicial:

La cadena de bloques de Bitcoin ha sido una innovación tanto económica como informática.

Utilizo el término “innovación” para definir una nueva combinación de técnicas existentes, más que como algo que no tiene ningún precedente. Esta definición permite que la World Wide Web sea considerada una innovación, a pesar de que no hizo más que combinar hipertexto con un grupo de protocolos de Internet que ya existían. Si quieres adoptar una definición más estricta de innovación, adelante, pero te sorprenderás de que quedan pocas “innovaciones” verdaderas. Parafraseando al Maestro, hay poco nuevo bajo el sol.

Para ser exactos, afirmo que las cadenas de bloques sin un token tienen un propósito, pero es un propósito diferente si lo comparamos con la cadena de bloques de Bitcoin original. Las Cripto-cabezas se ríen de las cadenas de bloques sin token porque no pueden proporcionar resistencia a la censura y la seguridad descentralizada a través de proof-of-work (prueba-de-trabajo). Las Fintech-cabezas se ríen de las cadenas de bloques públicas porque son lentas, costosas e inadecuadas para las finanzas tradicionales. Bueno, que se sigan riendo todos porque creo que todos están en lo correcto.

Voy a argumentar que las cadenas de bloques sin tokens son útiles para mantener bases de datos descentralizadas sincronizadas, incluso dentro de una sola organización en la que existe confianza. Y luego veremos lo que ofrecen otras características de las cadenas de bloques que las convierten en adecuadas para crear consenso para determinados tipos de transacciones entre organizaciones, donde la confianza no solo es limitada sino también imperfecta.

Para poder seguir el argumento, vamos a tener que adentrarnos primero en el modelo transaccional de Bitcoin; el control de concurrencia mediante versiones múltiples (database multiversion concurrency control – MVCC, en inglés), y el problema de la resolución de conflictos replicables en las bases de datos multi-master.

Modelo transaccional de Bitcoin

El modelo transaccional de Bitcoin es simple pero poderoso. Cada transacción Bitcoin tiene un conjunto de entradas (inputs) y un conjunto de salidas (outputs). Cada input “gasta” un output de una transacción anterior. Todos los bitcoins en los inputs de una transacción desembocan en dicha transacción y se distribuyen a través de outputs, de acuerdo a las cantidades escritas en su interior. De esta manera, las transacciones forman una cadena conectada de múltiples vías (multi-way) que finaliza en las transacciones “coinbase”, en las que se crean nuevos bitcoins.

Bitcoin tiene un montón de reglas adicionales que son ejecutadas por cada nodo de la red:

– Cada input en una transacción debe demostrar que tiene derecho a gastar el output anterior al que está conectado. Esto está restringido por las condiciones codificadas dentro del output previo.
– Una transacción debe tener suficientes bitcoin totales en sus inputs para cubrir el monto total de sus outputs. Las únicas excepciones son las transacciones coinbase que crean nuevas unidades de la moneda.
– Cada output solo puede gastarse una vez, en otras palabras, solo puede estar conectado a un input en una transacción posterior.

Debido a esta última regla, la red requiere un mecanismo para llegar a un consenso acerca de qué transacciones son válidas, y esto es lo que consigue la cadena de bloques. En concreto:

Si dos transacciones intentan gastar el mismo output, entonces solo una de esas transacciones será aceptada. La cadena de bloques actúa como un mecanismo unificado para detectar y prevenir estos conflictos a través de la red.

La cadena de bloques está estructurada como una serie de bloques enlazados, en el que cada bloque contiene un conjunto de operaciones que no entran en conflicto entre sí o con los bloques anteriores, empezando por el primer bloque creado en 2009. En teoría, la cadena podría contener una serie de transacciones individuales, pero mediante la agrupación de las transacciones en bloques, ganamos una serie de eficiencias que hacen que el esquema sea más práctico.

Entonces, ¿cuál es el propósito de un criptomoneda en todo esto? Todo se reduce a la cuestión de quién decide sobre cuáles son los bloques que forman la cadena. Bitcoin es descentralizado y no tiene ninguna autoridad que pueda tomar esta decisión, por lo que hay que encontrar otra manera de llegar a un consenso.

Podríamos utilizar un enfoque democrático, en el que los nodos de la red votan sobre los bloques, y gana la mayoría. Por desgracia, como cualquier encuesta de Internet puede demostrar, la democracia representativa no es posible en línea, debido al problema de la falsificación de identidad (también conocido como un ataque Sybil). Una persona puede tener más de un millón de ordenadores y decidir cómo votan, tomando así el control del consenso en la red. Y nadie ni siquiera sabría que esto ha sucedido.

Para solucionar esto, Bitcoin hace que sea deliberadamente difícil añadir un bloque a la cadena, a través de un proceso llamado “minería“. Para crear un bloque, se debe resolver un problema matemático difícil pero sin sentido que exige mucho poder de computación (y, por tanto, electricidad y dinero). También es necesario un poco de suerte, ya que estás en competencia con muchos otros mineros de bloques de todo el mundo. Y no puedes adelantarte durante mucho tiempo al resto con la inversión en un equipo de minería más potente, ya que la red ajusta regularmente el nivel de dificultad de minado para mantener constante la creación de un bloque cada 10 minutos.

Si es tan difícil y costoso crear un bloque, ¿por qué iba alguien a molestarse? La respuesta está en la recompensa que obtienen por bloque resuleto. El minero que logre resolver un bloque recibe la transacción coinbase de 25 bitcoins (esta cantidad se divide por la mitad cada cuatro años). Pueden vender estos bitcoins en el mercado por 7.000 dólares (aproximadamente al cambio actual), pagar su factura de la luz y embolsarse algunos beneficios. Los mineros también ganan un poco más de bitcoins con las cuotas que se adjuntan a las transacciones, aunque por ahora estas comisiones desempeñan un papel menor.

Así Bitcoin genera consenso a través de la prueba de trabajo (proof-of-work) y el meollo de la argumentación de las Bitcoin-cabezas es el siguiente: Sin criptomoneda, no hay una manera de incentivar la minería descentralizada de bloques. Por lo tanto, no hay manera de asegurar una cadena de bloques abierta contra los ataques sybil. Y por lo tanto, cualquiera puede monopolizar el consenso de la red y hacerla inútil. No argumentaré contra nada de eso.

Control de concurrencia mediante versiones múltiples

Una base de datos es un repositorio de información estructurada, agrupados en grupos de hojas de cálculo llamadas tablas. Un simple ejemplo de una tabla de este tipo es una lista de las cuentas bancarias, en el que cada fila contiene un número de cuenta junto con el saldo de esa cuenta. Digamos que su cuenta comienza el día con un saldo de 900 dólares. Se realiza el pago de la hipoteca automático de 750 dólares que está programado y también quieres sacar 400 dólares de un cajero automático. Si no tienes una línea de crédito, alguna de estas operaciones fallará.

Los procesos de pagos de hipotecas y retiros en cajeros automáticos se ejecutan en sistemas separados, los cuales acceden a esta base de datos única de la cuenta. Digamos que cada proceso funciona leyendo el balance de su cuenta, comprueba que es suficiente, inicia esa operación, la verificación de la operación se completa, se calcula el nuevo saldo, y finalmente se escribe en la base de datos.

Siempre y cuando el pago de la hipoteca y el retiro del cajero automático no se superpongan esta lógica no tendrán ningún problema. La primera operación se ejecutará con éxito, y la segunda se anulará porque su cuenta no tiene fondos suficientes.

Pero, ¿qué pasa si los dos procesos comienzan al mismo tiempo? En este caso, cada uno lee el balance de su cuenta y lo considera suficiente para proceder. Cuando el pago de la hipoteca se completa, se calculará el nuevo saldo de 150 dólares y lo escribe en la base de datos. Cuando el retiro del cajero automático se completa, de manera similar se escribirá su nuevo saldo de 500 dólares. Una de estas operaciones de escritura va a anular a la otra y, dependiendo de su suerte, usted recibirá 750 dólares o 400 dólares de su banco.

Por supuesto, esto en realidad no sucede, debido a una tecnología de base de datos denominada control de concurrencia. El control de concurrencia mantiene nuestros datos (especialmente financieros) sanos y seguros, y viene en muchas formas. Pero todos comparten el principio de que las operaciones de las bases de datos se agrupan en “transacciones”, que son tratadas de forma atómica, lo que significa que son aceptadas o rechazadas en su conjunto. La concurrencia conserva la consistencia mediante el bloqueo o la congelación de partes de una base de datos mientras están en uso por una transacción, para evitar que otras transacciones operen con la misma información de una manera conflictiva.

Si no necesitásemos ejecutar transacciones en paralelo, podríamos bloquear toda la base de datos durante la duración de cada transacción. Sin embargo, esto no es práctico en la mayoría de aplicaciones del mundo real. Un buen sistema de control de concurrencia permite operaciones paralelas bloqueando tan poca información como sea posible durante un tiempo lo más corto posible. En el ejemplo anterior, solo la fila de la base de datos correspondiente a su cuenta será bloqueada y solo para la fracción de segundo en la que una revisión final y la deducción se llevan a cabo. Una transacción conflictiva operando en paralelo simplemente tendría que esperar hasta que se libere este bloqueo.

Una técnica popular para el control de concurrencia se llama control de concurrencia mediante versiones múltiples o MVCC (por sus sigles en inglés) para abreviar. En MVCC, cada transacción ve un panorama coherente de los datos en un momento determinado en el tiempo, incluso si parte de esa información está en proceso de ser actualizado por una segunda transacción simultánea. Esta propiedad de aislamiento instantánea asegura, por ejemplo, que un estado que muestre nuestro saldo total a través de varias cuentas siempre será correcto, aunque algunos fondos están en el proceso de pasar de una cuenta a otra. Una transacción solo afectará a los datos vistos por una segunda transacción si la segunda comienza después de que todos los cambios de la primera se han aplicado con éxito.

Detrás de las escenas, MVCC funciona al permitir que varias versiones de una misma fila se mantenga al mismo tiempo, junto con una marca de tiempo que representa la fecha de cada versión de la última modificación. La modificación de una fila de la base de datos en MVCC marca la eliminación de la versión actual de esa fila, mientras que aplica dicha modificación en una copia de esa fila con una marca de tiempo actualizada. Desde la perspectiva de la capa de almacenamiento de la base de datos, no existe la modificación de una fila. Cada transacción sabe exactamente cuándo comenzó, y solo ve las versiones de filas cuya marca de tiempo es anterior en el tiempo. Las versiones antiguas de las filas se pueden quitar del almacenamiento una vez que no existen transacciones en curso que podrían necesitarlas.

Fundamentalmente para nuestros propósitos, MVCC evita conflictos entre operaciones de escritura. En concreto:

Si dos transacciones intentan eliminar la misma versión de la fila, solo una de estas transacciones será aceptada. El control de concurrencia mediante versiones múltiples actúa como un mecanismo unificado para detectar y prevenir estos conflictos dentro de una base de datos.

La réplica de bases de datos con múltiples copias (multi-master)

Ahora vamos a hablar acerca de la réplica de bases de datos, en la que existe una base de datos con múltiples copias. Hay una serie de razones para querer replicar una base de datos:

– Para aumentar la fiabilidad, por lo que si se pierde una copia de la base de datos (por ejemplo, debido a un fallo en el disco), podemos cambiar al instante a una segunda copia.
– Para aumentar el rendimiento, si el volumen de las operaciones va más allá de la capacidad de un único servidor de base de datos.
– Para reducir la latencia, de forma que los procesos que se ejecutan en la oficina de Singapur no tengan que esperar a que las respuestas de una base de datos de Toronto.

Cuando se trata de la lectura de datos desde bases de datos, la réplica es una técnica ideal, porque todas las réplicas contienen la misma información. Sin embargo, las cosas se complican cuando se trata de operaciones de escritura, porque tenemos que decidir dónde se llevan a cabo esas operaciones de escritura, y la forma en que se transfieren a otras copias de la base de datos.

La respuesta más común es usar la réplica master-esclavo, en la que una sola base de datos (la “master” o maestra) se considera autorizada. Cualquier cambio en los datos se lleva a cabo exclusivamente en la maestra y luego llegan a todas las otras bases de datos “esclavas” a través de un registro de transacciones. Esto mantiene todas las copias de bases de datos (más o menos) sincronizadas al instante.

Pero si las operaciones de escritura son frecuentes, la réplica master-esclavo nos vuelve a llevar al mismo problema para el que se diseñó la réplica. La base de datos maestra se convierte en un cuello de botella en términos de fiabilidad, rendimiento y latencia, ya que cada operación de escritura se realiza en ella sola.

Una estrategia más compleja se llama réplica con múltiples master o maestras (multi-master), en la que las operaciones de escritura se puede realizar en cualquiera de las copias de bases de datos, en lugar de en una sola maestra. En este caso, las copias comparten actualizaciones entre ellas de una manera de igual a igual para estar sincronizadas.

Esto suena simple en teoría, pero la réplica multi-master introduce un nuevo problema, ya que pueden surgir conflictos. ¿Qué pasa si dos copias de una base de datos actualizan la misma fila, al mismo tiempo, y a continuación, tratan de intercambiar estas actualizaciones con la otra? Ambas bases de datos se darán cuenta de que existe una actualización conflictiva y tienen que aplicar la estrategia acordada para resolver estos conflictos. Y aquí las cosas se complican – véase la documentación para MySQL, SQL Server u Oracle para algunos ejemplos de estrategias de resolución de conflictos.

Así que aquí es donde nos llevan todos estos antecedentes:

¿No sería bueno si pudiéramos tener el control de concurrencia multiversión distribuido, para evitar los conflictos que se producen en la réplica multi-master?

Y creo que esto es precisamente lo que hacen las cadenas de bloques.

Fuente: MultiChain

© OroyFinanzas.com

© OroyFinanzas.com

Sobre el autor

OroyFinanzas.com
El equipo de analistas de OroyFinanzas.com y sus autores invitados para fomentar el entendimiento del dinero.
mencionado en: