(OroyFinanzas.com) – El debate sobre Bitcoin vs blockchain está latente desde hace mucho tiempo. En otro artículo ya exponíamos la línea por la que Gideon Greenspan de MultiChain argumentaba que ambas posturas en este debate estaban en lo correcto [1]. A continuación, veremos el desenlace de su argumentación con la que defiende la existencia de ambas opciones (cadenas de bloques con token [2] y cadenas de bloques sin token) para aplicaciones y usos diferentes y en la que defiende que ambas ofrecen la posibilidad de generar consenso en una base de datos distribuida.
Blockchains como bases de datos MVCC (multiversion concurrency control) distribuidas
En la primera parte del texto, Greenspan ha asegurado:
“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”.
“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”.
Estas dos frases son idénticas excepto por los términos en negrita. Por lo que Greenspan expone que:
Una cadena de bloques proporciona MVCC distribuidos (con algunas características adicionales).
Profundizaremos en ello. Desde la perspectiva de un nodo [3] de la cadena de bloques, el conjunto actual de outputs de las transacciones Bitcoin no gastadas forman una base de datos, en la que cada fila es un solo output no utilizado. Esto es similar a la base de datos de las cuentas bancarias que hemos descrito anteriormente, con la diferencia de menor importancia de que el saldo de cada cuenta se divide en varias filas, cada una de las cuales está marcada con el mismo número de cuenta.
Una transacción bitcoin gasta uno o más de estos outputs y crea uno o más nuevos outputs como resultado. Esto es exactamente igual a una transacción de base de datos que elimina una o más versiones de filas, y crea una o más filas nuevas como resultado (Recordemos que en MVCC no existe la modificación de una fila). La cadena de bloques de Bitcoin asegura que un solo output no se puede gastar en más de una transacción y esto equivale a garantizar que una sola versión de la fila no se puede eliminar por más de una transacción de la base de datos.
Ahora, antes de dejarnos llevar, no estoy afirmando que las cadenas de bloques son una gran tecnología de propósito general para la sincronización de base de datos distribuidas en un ambiente de plena confianza. Hay un montón de otras tecnologías como Paxos [4], Raft [5] y Two-phase commit [6] que llevan a cabo esto muy bien. Pero yo creo que las cadenas de bloques añaden algo más, que puede implementarse en aplicaciones en las que:
– Podemos aceptar un pequeño retraso entre el momento en una transacción probablemente se efectúe y cuando es aceptada definitivamente. (Este retraso puede ser una cuestión de segundos en lugar de 10 minutos como en Bitcoin.)
– Transacciones en conflicto nunca deben suceder si todo el mundo está siendo honesto y sus sistemas están funcionando correctamente.
– Cada transacción modifica solo un par de filas de forma simultánea (de lo contrario nuestras transacciones blockchain tendrán un número inmanejable de insumos).
– El tamaño de cada fila de una base de datos es bastante pequeño (de nuevo, para evitar que nuestras transacciones blockchain se inflen demasiado).
Todos estos criterios se cumplen por las aplicaciones financieras. El mundo financiero ya utiliza retrasos (¡de hasta 3 días!) entre la realización de una transacción y su liquidación final. En cuanto a la prevención de conflictos, tiene contratos y reglamentos establecidos para detectar el fraude, y las consecuencias pueden ser graves. Y la cantidad de datos que intervienen en cada operación es bastante pequeña – piense en el ejemplo anterior de la cuenta bancaria.
Hasta ahora, todo lo que ha demostrado el autor es que las cadenas de bloques son otro mecanismo de sincronización de bases de datos distribuidas. Pero las cosas se ponen realmente interesante si tenemos en cuenta las características adicionales que las cadenas de bloques proporcionan.
Blockchains más allá de MVCC
Una transacción Bitcoin hace mucho más que únicamente anotar outputs de las transacciones anteriories y crear otros nuevos en su lugar. Incluso la transacción bitcoin más simple tiene dos propósitos adicionales:
En primer lugar, las normas relativas a las transacciones válidas contienen algo de la lógica de la aplicación de nuestra contabilidad en la base de datos. Recordemos que la cantidad total de bitcoin en los inputs de una transacción debe cubrir la cantidad total de los outputs. Traducido a lógica de la aplicación de base de datos, se trata de una regla que establece que las transacciones de base de datos (con la excepción de coinbases) no se les permite aumentar la cantidad total de bitcoin en la base de datos. Este tipo de restricción va más allá de los procedimientos almacenado [7]s de las base de datos regulares porque no se puede evitar en cualquier circunstancia.
En segundo lugar, recordemos que cada output de las transacciones Bitcoin codifica las condiciones en las que se puede gastar. Para los outputs bitcoin regulares, esta condición se basa en la criptografía de clave pública [8]. Una dirección pública está incrustada dentro del “guión” del output de modo que solo puede ser gastado utilizando la clave privada correspondiente a esa dirección pública. Si consideramos este output en una fila de una 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 que su creador (o creadores) tenían el derecho de eliminar / modificar sus filas anteriores. Esto (creo) es una auténtica novedad en la tecnología de bases de datos.
Y una vez más, da la casualidad de que ambas características son muy útiles para aplicaciones financieras. Nos gusta el hecho de que nuestra base de datos asegura, en el nivel más bajo posible, que el dinero no se puede crear de la nada. Y nos gusta tener una pista de auditoría irrefutable que demuestra que cada transacción fue autorizada por el titular de los fondos a que se moviese. Dependiendo del caso de uso, puede que también nos guste realizar transacciones atómicamente seguras de intercambio peer-to-peer (Delivery versus payment – DVP [9]), sin ni siquiera saber la identidad de nuestra contraparte.
¿Y dónde está el token?
Por supuesto, nada de esto es una coincidencia, porque Bitcoin en sí mimso es una aplicación peer-to-peer [10] financiera hermosa. Sin embargo, ninguna de las características anteriores de una cadena de bloques dependen del token en absoluto. 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 librarnos de esa moneda en su totalidad. Esto nos deja con una cadena de bloques como un medio de lograr el consenso y la seguridad en una aplicación financiera peer-to-peer para cualquier clase de activo.
Pero, ¿quién ejecuta la minería para generar este consenso? En Bitcoin los mineros anónimos [11] deben realizar cálculos inútiles y caros, y son incentivados a hacerlo por las recompensas de resolución de bloques (y las tasas de transacción) denominados en la moneda nativa de la cadena de bloques o token. ¿Tenemos alguna otra opción?
Resulta que sí. Podemos tener una lista cerrada de mineros, que se identifican a través de la firma de los bloques que crean. Las reglas sobre el consenso distribuido (o “diversidad minera”, como lo llamamos en MultiChain [12]) proporcionan una forma diferente de prevenir el control de la minoría de la blockchain, siempre y cuando aceptes que los mineros sean pre-autorizados. Por supuesto, para Bitcoin esto no es aceptable, ya que parte de su espítitu es permitir el anonimato en la minería, para que no haya una manera de censurar las transacciones de forma centralizada. Pero si, por ejemplo, tenemos un sistema financiero altamente regulado, en el que el modelo de Bitcoin es inaplicable, tal vez podríamos aceptar una lista de mineros pre-autorizados Si tuviésemos suficientes de ellos, y los extendiésemos bien entre las instituciones, y tuvieramos contratos legales con todos ellos, ¿sería realmente probable que creasen pandillas y socavaran la red de la que dependen si al hacerlo fueran a la cárcel?
Epílogo
Espero haber demostrado que las cadenas de bloques sin tokens tienen algunas aplicaciones útiles, incluso si éstas son muy diferentes de las de la cadena de bloques Bitcon. No obstante queda una pregunta:
¿Son estos sistemas de contabilidad compartidos sin token y con autorización realmente dignos de ser llamados “blockchain”?
La respuesta corta es: ¿a quién le importa? Rara vez vale la pena discutir sobre el significado de las palabras, porque no hay una respuesta correcta.
Pero para profundizar un poco más, digamos que acepto la premisa de que el cadena de bloques de Bitcoin es la cadena de bloques arquetípica. En ese caso, lo que realmente deberíamos preguntarnos es:
¿Son estos libros mayores de contabilidad compartidos lo suficientemente similares a Bitcoin para merecer el nombre de “blockchain”?
Mi opinión personal es que sí. Debido a que comparten un gran número de similitudes técnicas, aunque difieren en el modelo de permisos y los incentivos económicos. Y lo más importante, ya que ambos generan consenso en una base de datos distribuida a través de una cadena de bloques.
Fuente: MultiChain [13]
© OroyFinanzas.com