Poner fin al debate entre bitcoin y blockchain

¿Hay algún valor en una cadena de bloques sin una criptomoneda?

El debate se ha estado ejecutando durante un tiempo, pero el mes pasado ha visto un repunte serio. La pregunta que se hace es:

¿Hay algún valor en una cadena de bloques sin una criptomoneda? ¿Y pueden estos "libros contables compartidos sin token" llamarse blockchains?

Entonces he leído Artículo de Bailey, Visto El video de Tim, Lea esta publicación de Nasdaq, seguido de Richard cada por el temor e incluso tuve el mío debate de buen humor (ver comentarios) con Chris DeRose de la fundación de la contraparte. Tanto aire caliente

Una cosa que Chris hace bien es reducirlo a la pregunta: ¿la blockchain es una innovación económica o informática? La implicación es que si las cadenas de bloques son una innovación puramente económica, no tiene sentido las cadenas de bloques sin criptomonedas. Permítanme decir mi posición al principio:

La cadena de bloques de bitcoin fue a la vez económica y una innovación informática.

Estoy permitiendo que la "innovación" aquí incluya Una nueva combinación de técnicas existentes, en lugar de algo que no tiene precedente alguno. Esta definición permite que la World Wide Web sea considerada como una innovación, aunque hizo poco más que combinar el hipertexto con un giro en algunos protocolos de Internet existentes. Si desea adoptar una definición más estricta de innovación, sea mi invitado, pero se sorprenderá de las pocas verdaderas "innovaciones" que quedan. Parafrasear El Maestro, hay poco nuevo bajo el sol.

Para ser precisos, estoy afirmando que blockchains sin una ficha sirven para un propósitopero es un propósito diferente en comparación con el blockchain original de bitcoin. Las criptomonedas se ríen de las cadenas de bloques sin fichas porque no pueden proporcionar resistencia a la censura y seguridad descentralizada a través de la prueba de trabajo. Los jefes de tecnología financiera se ríen de las cadenas de bloques públicas porque son lentas, caras y no aptas para las finanzas tradicionales. Bueno, sigan riéndose de todos, porque creo que ambos tienen razón.

Voy a argumentar que las cadenas de bloques sin tokens son útiles para mantener sincronizadas las bases de datos descentralizadas, incluso en una sola organización en la que existe una confianza perfecta. Y luego veremos qué otras características ofrecen las cadenas de bloques, que las hacen adecuadas para crear consenso para tipos específicos de transacciones entre organizaciones, donde solo hay confianza limitada e imperfecta.

Desafortunadamente, para seguir el argumento, tendrá que analizar conmigo el modelo transaccional de bitcoin, el control de concurrencia de múltiples bases de datos (MVCC) y el problema de la resolución de conflictos en la replicación de bases de datos multimaestro. Haré todo lo posible para mantenerme en inglés, pero aún así, esto es algo técnico, y no hay forma de evitarlo.

Modelo transaccional de Bitcoin

El modelo transaccional de bitcoin es simple pero poderoso. Cada transacción de bitcoin tiene un conjunto de entradas y un conjunto de salidas. Cada entrada "gasta" una salida de una transacción anterior. Todas las entradas de bitcoin en una transacción fluyen en esa transacción y se distribuyen a través de sus salidas de acuerdo con las cantidades escritas dentro. De esta manera, las transacciones forman una cadena conectada de múltiples vías que termina en las transacciones de "coinbase" en las que se crean nuevos bitcoins.

Bitcoin tiene un montón de reglas adicionales que se aplican por cada nodo en la red:

• Cada entrada en una transacción debe demostrar que tiene derecho a gastar la salida anterior a la que está conectada. Ese derecho está restringido por condiciones codificadas dentro de la salida anterior.
• Una transacción debe tener suficiente bitcoin total en sus entradas para cubrir el total escrito en sus salidas. Las únicas excepciones son las transacciones con base de monedas que crean nuevas unidades de la moneda.
• Cada salida solo se puede gastar una vez, en otras palabras, solo se puede conectar a una entrada en una transacción posterior.

Debido a esta última regla, la red requiere un mecanismo para llegar a un consenso sobre qué transacciones son válidas, y esto es lo que hace la cadena de bloques. Específicamente:

Si dos transacciones intentan gastar la misma producción, solo una de esas transacciones será finalmente aceptada. Una cadena de bloques actúa como un mecanismo unificado para detectar y prevenir estos conflictos en la red.

La cadena de bloques está estructurada como una serie de bloques vinculados, en los que cada bloque contiene un conjunto de transacciones que no entran en conflicto entre sí o con bloques anteriores, comenzando desde el primer bloque creado en 2009. En teoría, la cadena podría contener un serie de transacciones individuales, pero al agrupar las transacciones en bloques, obtenemos una serie de eficiencias que hacen que el esquema sea más práctico.

Entonces, ¿cuál es el propósito de una criptomoneda en todo esto? Todo se reduce a la pregunta de quién decide sobre los bloques que forman la cadena. Bitcoin está descentralizado y no tiene autoridad para tomar esta decisión, por lo que necesita encontrar otra forma de llegar a un consenso.

Nos gustaría utilizar un enfoque democrático, en el que los nodos de la red voten por bloques y la mayoría gane. Desafortunadamente, como cualquier encuesta en Internet puede demostrar, la democracia representativa no es posible en línea, debido al problema de la suplantación (también conocido como Ataque de sibila). Una persona puede tomar más de un millón de computadoras y decidir cómo votar, tomando así el control del consenso de la red. Nadie más sabrá que esto ha sucedido.

Para resolver esto, bitcoin hace que sea deliberadamente difícil agregar un bloque a la cadena, a través de un proceso llamado "minería". Para crear un bloque, debe resolver un problema matemático difícil pero sin sentido que requiere mucho cálculo (y por lo tanto electricidad y dinero). También necesitas algo de suerte, ya que compites con muchos otros mineros de bloques de todo el mundo. No puede salir adelante por mucho tiempo comprando una computadora de minería más potente, porque la red ajusta regularmente la dificultad del problema para mantener una tasa global constante de un bloque por 10 minutos.

Si es tan difícil y costoso crear un bloque, ¿por qué alguien se molestaría? La respuesta está en la recompensa del bloque. El minero exitoso de un bloque controla la transacción de la base de monedas que le otorga 25 bitcoins (esta suma se reduce a la mitad cada cuatro años). Pueden vender estos bitcoins en el mercado abierto por $ 7,000 (al precio actual), pagar su factura de electricidad y, con suerte, obtener alguna ganancia. Los mineros también cobran un poco más de las tarifas que se adjuntan a las transacciones, aunque por ahora estas tarifas juegan un papel menor.

Entonces, bitcoin genera consenso a través de la prueba de trabajo y el quid del argumento de los bitcoin-heads es este: Sin una criptomoneda, no hay forma de incentivar la extracción descentralizada de bloques. Por lo tanto, no hay forma de asegurar una cadena de bloques abierta contra ataques de suplantación. Por lo tanto, cualquiera puede monopolizar el consenso de la red y hacer que todo sea inútil. No discutiré con nada de eso.

Control de concurrencia multiversion

Mientras tanto, quiero hablar sobre algo que puede parecer completamente ajeno.

Una base de datos es un depósito de información estructurada, agrupada en entidades similares a hojas de cálculo llamadas tablas. Un ejemplo simple de dicha tabla es una lista de cuentas bancarias, en la 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. Hoy está programado un pago hipotecario automático de $ 750 y también debe retirar $ 400 de un cajero automático. Lamentablemente, no tiene una facilidad de sobregiro, por lo que una de estas operaciones está configurada para fallar.

Los procesos para pagos de hipotecas y retiros de cajeros automáticos se ejecutan en sistemas separados, los cuales acceden a esta base de datos de cuenta única. Digamos que cada proceso funciona leyendo el saldo de su cuenta, verificando que sea suficiente para la operación, iniciando esa operación, verificando que la operación se completa, calculando el nuevo saldo y finalmente escribiéndolo en la base de datos.

Mientras su pago de hipoteca y retiro de cajero automático no se superpongan, esta lógica funcionará bien. La primera operación se ejecutará con éxito y la segunda se cancelará porque su cuenta no tiene fondos suficientes. Dependiendo del pedido, recibirá una llamada telefónica enojada del banco o un mensaje grosero en la pantalla del cajero automático.

Pero, ¿qué sucede si los dos procesos comienzan al mismo tiempo? En este caso, cada uno leerá el saldo de su cuenta y lo considerará suficiente para continuar. Cuando se complete el pago de la hipoteca, su nuevo saldo se calculará como $ 150 y se registrará en la base de datos. Cuando se complete el retiro del cajero automático, su nuevo saldo de $ 500 se escribirá de manera similar. Una de estas operaciones de escritura anulará a la otra y, según su suerte, recibirá un bono de $ 750 o $ 400 de su banco. Sin duda, pronto aprenderá a programar sus visitas al cajero automático para el día de la hipoteca.

Por supuesto, esto no sucede en realidad, debido a una tecnología de base de datos llamada control de concurrencia. El control de simultaneidad mantiene nuestros datos (especialmente financieros) sanos y seguros, y se presentan de muchas formas. Pero todos comparten el principio de que las operaciones de la base de datos se agrupan en "transacciones", que se tratan atómicamente, lo que significa que tienen éxito o fracasan en su conjunto. La concurrencia preserva la consistencia al bloquear o congelar partes de una base de datos mientras están en uso en una transacción, para evitar que otras transacciones operen con la misma información de manera conflictiva.

Si no necesitáramos ejecutar transacciones en paralelo, podríamos bloquear toda la base de datos durante toda la duración de cada transacción. Sin embargo, esto no es práctico en la mayoría de las aplicaciones del mundo real. Un buen esquema de control de concurrencia permite operaciones paralelas bloqueando la menor cantidad de datos posible durante el menor tiempo posible. En el ejemplo anterior, solo se bloquearía la fila de la base de datos correspondiente a su cuenta, y solo durante la fracción de segundo en la que se realizó una verificación y una deducción finales. Una transacción en conflicto que opera en paralelo simplemente tendría que esperar hasta que se libere este bloqueo.

Una técnica popular de control de concurrencia se llama control de concurrencia multiversion, o MVCC para abreviar. En MVCC, cada transacción ve una instantánea consistente de los datos en un momento determinado, incluso si parte de esos datos está en proceso de actualización mediante una segunda transacción simultánea. Esta aislamiento de instantánea La propiedad asegura, por ejemplo, que un estado de cuenta que muestre nuestro saldo total en varias cuentas siempre será correcto, incluso si algunos fondos están en proceso de pasar de una cuenta a otra. Una transacción solo afectará los datos vistos por una segunda transacción si la segunda comienza después de que todos los cambios de la primera se hayan aplicado con éxito.

Detrás de escena, MVCC funciona permitiendo que múltiples versiones de una fila se mantengan simultáneamente, junto con una marca de tiempo que representa la fecha de la última modificación de cada versión. La modificación de una fila de la base de datos en MVCC marca la versión actual de esa fila para su eliminación, mientras aplica la modificación a un 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 tal cosa como modificar una fila en su lugar. Cada transacción sabe exactamente cuándo comenzó y solo ve versiones de filas cuya marca de tiempo sea anterior a esa hora. Las versiones antiguas de filas se pueden eliminar del almacenamiento una vez que no haya transacciones en curso que puedan necesitar acceder a ellas.

De manera crucial para nuestros propósitos aquí, MVCC previene conflictos entre operaciones de escritura. Específicamente:

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

¿Suena alguna campana? Hay un fondo más que necesitamos discutir.

Replicación de base de datos multimaestro

Ahora hablemos de la replicación de la base de datos, en la que existe una base de datos en varias copias. Existen varias buenas razones para replicar una base de datos, como:

• Para aumentar la confiabilidad, de modo que si se pierde una copia de la base de datos (por ejemplo, debido a una falla del disco), podemos cambiar instantáneamente a una segunda copia.
• Para aumentar el rendimiento, si el volumen de operaciones supera la capacidad de un único servidor de base de datos.
• Para reducir la latencia, para que los procesos que se ejecutan en la oficina de Singapur no tengan que esperar las respuestas de una base de datos que se encuentra en Toronto.

Cuando se trata de lectura datos de bases de datos, la replicación es una técnica ideal, porque todas las réplicas contienen la misma información. Sin embargo, las cosas se ponen más difíciles cuando se trata de operaciones de escritura, porque debemos decidir dónde se realizan esas operaciones de escritura y cómo se transfieren a otras copias de la base de datos.

La respuesta más común es utilizar la replicación maestro-esclavo, en la que una sola base de datos (la “maestra”) se considera autorizada. Cualquier cambio en los datos se realiza exclusivamente en el maestro y luego se filtra a todas las otras bases de datos "esclavas" a través de un registro de transacciones. Esto mantiene todas las copias de la base de datos (más o menos) instantáneamente sincronizadas.

Desafortunadamente, si las operaciones de escritura son frecuentes, la replicación maestro-esclavo nos lleva de nuevo al problema para el que se diseñó la replicación. La base de datos maestra se convierte en un cuello de botella en términos de confiabilidad, rendimiento y latencia, ya que cada operación de escritura se realiza solo en ella.

Una estrategia más compleja se denomina replicación multimaestro, en la que se pueden realizar escrituras en cualquiera de las copias de la base de datos, en lugar de en un solo maestro. En este caso, las copias comparten actualizaciones entre sí de forma peer-to-peer para permanecer sincronizadas.

Esto suena simple en teoría, pero la replicación multimaestro introduce un nuevo problema porque pueden surgir conflictos. ¿Qué sucede si dos copias de una base de datos actualizan la misma fila al mismo tiempo y luego intentan intercambiar estas actualizaciones entre sí? Ambas bases de datos notarán que se ha producido una actualización conflictiva y deberán aplicar alguna estrategia acordada para resolver estos conflictos. Y aquí las cosas se ponen bastante complejo - ver los documentos para MySQL, SQL Server or Oracle para algunos ejemplos de estrategias de resolución de conflictos. (Estoy ignorando la replicación multimaestro síncrona o llamada "ansiosa", en la que todas las réplicas deben comprometerse a una operación de escritura antes de que pueda llevarse a cabo, porque eso da como resultado cada copia de la base de datos en un cuello de botella).

Así que aquí es donde nos lleva todo este trasfondo:

¿No sería bueno si pudiéramos haber distribuido el control de simultaneidad de múltiples versiones para evitar conflictos en la replicación de múltiples maestros?

Bueno, sí, me imagino que sería muy bonito. Y creo que esto es precisamente lo que hacen las cadenas de bloques.

Blockchains como MVCC distribuido

Copiemos un par de oraciones que escribí en negrita arriba:

Si dos transacciones intentan pasar lo mismo salida, entonces solo se aceptará una de esas transacciones. Una cadena de bloques actúa como un mecanismo unificado para detectar y prevenir estos conflictos a través de la red.

Si dos transacciones intentan borrar lo mismo versión de fila, solo se aceptará una de estas transacciones. Control de concurrencia multiversion actúa como un mecanismo unificado para detectar y prevenir estos conflictos dentro de una base de datos.

Estas oraciones son idénticas excepto por los términos en negrita. Así que esto es lo que voy a reclamar:

Un blockchain proporciona MVCC distribuido (con algunas campanas y silbatos adicionales).

Desarrollemos la comparación un poco más. Desde la perspectiva de un nodo de blockchain, el conjunto actual de salidas de transacciones de bitcoin no gastadas forma una base de datos, en la que cada fila es una única salida no gastada. Esto es similar a la base de datos de cuentas bancarias que describimos anteriormente, con la pequeña diferencia de que el saldo de cada cuenta se puede dividir en varias filas, cada una de las cuales está marcada con el mismo número de cuenta.

Una transacción de bitcoin gasta una o más de estas salidas y crea una o más salidas nuevas como resultado. Esto es exactamente como una transacción de base de datos que elimina una o más versiones de fila y crea una o más filas nuevas como resultado (recuerde que en MVCC no existe tal cosa como modificar una fila en su lugar). La cadena de bloques de bitcoin garantiza que una sola salida no se pueda gastar en más de una transacción. Esto equivale a asegurar que una versión de una sola fila no pueda ser eliminada por más de una transacción de base de datos.

Ahora, antes de dejarnos llevar, no estoy afirmando que las cadenas de bloques sean una gran tecnología de propósito general para la sincronización de bases de datos distribuidas en un entorno totalmente confiable. Hay muchas otras tecnologías como Paxos, Raft y Compromiso en dos fases que realizan el trabajo muy bien. Pero sí creo que las cadenas de bloques tienen un punto óptimo, que se puede caracterizar como aplicaciones donde:

• Podemos aceptar una pequeña demora entre el momento en que probablemente se acepta una transacción y el momento en que se acepta definitivamente. (Este retraso puede ser cuestión de segundos en lugar de 10 minutos como en bitcoin).
• Las transacciones en conflicto nunca deberían suceder si todos son honestos y sus sistemas funcionan correctamente.
• Cada transacción modifica solo unas pocas filas simultáneamente (de lo contrario, nuestras transacciones de blockchain tendrán un número difícil de entradas).
• El tamaño de cada fila de la base de datos es bastante pequeño (nuevamente, para evitar que nuestras transacciones de blockchain aumenten de tamaño).

Todos estos criterios se cumplen mediante aplicaciones financieras. El mundo financiero ya está acostumbrado a retrasos (¡de hasta 3 días!) Entre la realización de una transacción y su liquidación final. En términos de prevención de conflictos, cuenta con contratos y regulaciones para detectar fraudes y las consecuencias pueden ser graves. Y la cantidad de datos involucrados en cada transacción es bastante pequeña; piense en el ejemplo de cuenta bancaria anterior.

Hasta ahora, todo lo que he demostrado es que las cadenas de bloques son otro mecanismo de sincronización para bases de datos distribuidas. Gran sorpresa. Las cosas solo se vuelven realmente interesantes cuando consideramos las características adicionales que brindan las cadenas de bloques.

Blockchains más allá de MVCC

Una transacción de bitcoin hace mucho más que señalar algunos resultados de transacciones anteriores y crear algunos nuevos en su lugar. Incluso la transacción de bitcoin más simple tiene dos propósitos adicionales.

Primero, las reglas sobre transacciones válidas contienen parte de la lógica de aplicación para nuestra base de datos de cuentas. Recuerde que la cantidad total de bitcoins en las entradas de una transacción debe cubrir la cantidad total en las salidas. Traducido a la lógica de la aplicación de la base de datos, esta es una regla que establece que las transacciones de la base de datos (con la excepción de las bases de datos) no pueden aumentar la cantidad total de bitcoins en la base de datos. Este tipo de restricción va más allá de la base de datos normal. procedimientos almacenados porque no se puede eludir bajo ninguna circunstancia.

En segundo lugar, recuerde que cada salida de transacción de bitcoin codifica las condiciones en las que se puede gastar. Para las salidas regulares de bitcoins, esta condición se basa en la criptografía de clave pública. Una dirección pública está incrustada dentro del "script" de salida para que solo se pueda gastar usando la clave privada correspondiente a esa dirección pública. Si consideramos que esta salida es una fila de base de datos, lo que tenemos es una base de datos con permisos por fila que se basan en la criptografía de clave pública. Además, cada transacción presenta una prueba auditable públicamente de que sus creadores tenían derecho a eliminar / modificar sus filas anteriores. Esto (creo) es una verdadera novedad en la tecnología de bases de datos.

Y nuevamente, da la casualidad de que ambas características son increíblemente útiles para aplicaciones financieras. Nos gusta el hecho de que nuestra base de datos garantiza, al nivel más bajo posible, que no se pueda crear dinero de la nada. Y nos gusta tener una pista de auditoría incontrovertible que demuestre que cada transacción fue autorizada por el titular de los fondos que movió. Como discutido en detalle aquí, es posible que también nos guste realizar transacciones de intercambio atómico de igual a igual (entrega contra pago en conversaciones financieras), sin siquiera conocer la identidad de nuestra contraparte.

Entonces, ¿dónde está la ficha?

Por supuesto, nada de esto es una coincidencia, porque el bitcoin en sí mismo es una hermosa aplicación financiera de igual a igual. Aún así, ninguna de las características anteriores de una cadena de bloques depende en absoluto del token. Si modificamos nuestro esquema de "base de datos" para que cada fila pueda representar múltiples activos, en lugar de la moneda nativa de la cadena de bloques, entonces podemos deshacernos de esa moneda por completo. Esto nos deja con una cadena de bloques como una forma de lograr consenso y seguridad en una aplicación financiera peer-to-peer para cualquier clase de activo.

Sin embargo, solo una pequeña pregunta: ¿Quién realiza la minería para generar este consenso? En bitcoin, los mineros anónimos deben realizar costosos cálculos inútiles, y están incentivados para hacerlo por las recompensas en bloque (y las tarifas de transacción) denominadas en la moneda o token nativo de la cadena de bloques. ¿Tenemos otras opciones?

Resulta que lo hacemos. Podemos tener una lista cerrada de mineros permitidos, que se identifican firmando los bloques que crean. Reglas sobre consenso distribuido (o "diversidad minera" como lo llamamos en MultiChain) proporcionan una forma diferente de prevenir el control minoritario de la cadena de bloques, siempre que pueda aceptar que los mineros estén preaprobados. Por supuesto, para bitcoin esto no es aceptable, porque parte del objetivo es permitir la minería anónima, por lo que no hay forma de censurar las transacciones de forma centralizada. Pero si, por ejemplo, tuviéramos un sistema financiero altamente regulado, en el que el modelo de bitcoin era inaplicable, ¿quizás podríamos aceptar una lista preaprobada de mineros después de todo? Si tuviéramos suficientes, y los distribuyéramos lo suficientemente bien entre las instituciones, y tuviéramos contratos legales con todos ellos, ¿es realmente probable que se unan y socaven la red de la que dependen, cuando hacerlo los llevará a la cárcel?

Epílogo

Espero haber demostrado que las cadenas de bloques sin tokens tienen algunas aplicaciones útiles, incluso si son muy diferentes de las cadenas de bloques de bitcoin. No obstante, queda una pregunta:

¿Son estos sistemas contables compartidos autorizados sin tokens realmente dignos del nombre "blockchain"?

La respuesta corta es: ¿a quién le importa? Raramente vale la pena discutir sobre el significado de las palabras, porque hay no hay respuesta correcta.

Pero para ir un poco más profundo, digamos que acepto la premisa de que la cadena de bloques bitcoin es la cadena de bloques arquetípica. En ese caso, lo que realmente deberíamos preguntar es:

¿Son estos libros contables compartidos lo suficientemente similares a Bitcoin como para merecer el nombre de "blockchain"?

Mi propia opinión personal aquí es si. Porque comparten una gran cantidad de similitudes técnicas, incluso si difieren en el modelo de permisos y los incentivos económicos. Y lo más importante, porque ambos generan consenso en una base de datos distribuida a través de un cadena de bloques.

Gracias por leer.

solicite Sigueme aqui en twitter. Ver también: Entrega versus pago en una cadena de bloques.

Aquí hay un par de otras piezas que vale la pena leer sobre este tema por Piotr Piasecki y Cavó Campbell.