Sí, es posible que necesites una cadena de bloques

Balaji S. Srinivasan es ex director de tecnología de Coinbase, socio de la junta directiva de Andreessen Horowitz y miembro del consejo asesor de CoinDesk.

El siguiente artículo apareció originalmente en la Consensus Magazine, distribuida exclusivamente a los asistentes al evento Consensus 2019 de CoinDesk.

Hay un cierto tipo de desarrollador que afirma que las cadenas de bloques son simplemente...horrible Bases de datos. Según la narrativa, ¿por qué no usar PostgreSQL para su aplicación? Es una plataforma madura, robusta y de alto rendimiento. En comparación con las bases de datos relacionales, el escéptico afirma que las cadenas de bloques son simplemente bases de datos lentas, torpes y costosas que no escalan.

Si bien ya existen algunas críticas a esta crítica (1,2), propondría una refutación simple de una oración: las cadenas de bloques públicas son útiles para almacenar un estado compartido, particularmente cuando ese estado compartido representa datos valiosos que los usuarios quieren exportar/importar sin errores, como su dinero.

El problema de la exportación/importación de datos

Eche un vistazo a los diagramas de nubes paraServicios web de Amazon,Microsoft Azure, o Google CloudHay íconos para balanceadores de carga, transcodificadores, colas y funciones lambda.

Hay íconos para VPC y todo tipo de bases de datos MON, incluidas las más nuevas. blockchain administradaservicios (que son distintos de las cadenas de bloques públicas, aunque potencialmente útiles en algunas circunstancias).

Para lo que no hay un ICON es para el estado compartido entre cuentas. Es decir, todos estos diagramas de nube asumen implícitamente que una sola entidad y sus empleados (es decir, la entidad con acceso a la cuenta raíz de la nube) es el ONE que diseña el diagrama de arquitectura y lee o escribe en la aplicación que lo sustenta. Más precisamente, estos diagramas suelen asumir la presencia de un único actor económico: la entidad que paga las facturas de la nube.*

Pero si visualizamos los diagramas de nubes no solo para ONE , sino para ONE actores económicos corporativos a la vez, surgen preguntas inmediatas: ¿Pueden estos actores interoperar? ¿Pueden sus usuarios extraer sus datos e incorporarlos a otras aplicaciones? Y, dado que los usuarios son actores económicos, si estos datos representan algún valor monetario, ¿pueden los usuarios tener la seguridad de que no se modificaron durante todo este proceso de exportación e importación?

Estas son las preguntas que surgen cuando consideramos la exportación e importación de datos desde la aplicación de cada entidad como un requisito fundamental. Y (con excepciones que explicaremos más adelante), en general, la respuesta actual suele ser no.

No, las diferentes aplicaciones generalmente no tienen software interoperable, ni permiten a sus usuarios exportar o importar fácilmente sus datos en un formato estándar, ni dan a los usuarios la certeza de que sus datos no fueron manipulados intencionalmente ni corrompidos inadvertidamente durante todo el proceso de exportación e importación.

La razón se reduce a los incentivos. Para la mayoría de los principales servicios de internet, simplemente no existe ningún incentivo financiero para que los usuarios exporten sus datos, y mucho menos para que la competencia los importe rápidamente. Aunque algunos llaman a esto...portabilidad de datosProblema, llamémoslo el problema de exportación/importación de datos para centrar la atención en los mecanismos específicos de exportación e importación.

Enfoques actuales del problema de la exportación/importación de datos

Si bien aún no existen incentivos financieros para una solución general al problema de la exportación/importación de datos, se han creado mecanismos para muchos casos especiales importantes. Estos mecanismos incluyen API, exportaciones JSON/PDF/CSV, archivos MBOX y (en el contexto bancario) SFTP.

Analicemos cada uno de ellos para comprender el estado actual de las cosas.

• API. Una de las formas más populares de exportar e importar datos es mediante interfaces de programación de aplicaciones (API). Algunas empresas permiten extraer algunos de sus datos o escribirlos en su cuenta. Sin embargo, esto tiene un costo. En primer lugar, su formato interno de datos suele ser propietario y no un estándar de la industria. En segundo lugar, a veces las API no son esenciales para su negocio CORE y pueden ser... apagadoEn tercer lugar, a veces las API son fundamentales para su negocio CORE y el precio puede ser... dramáticamente elevadoEn general, si lees o escribes en una API alojada, estás a merced del proveedor de la API. A esto lo llamamos riesgo de plataforma, y ser desbancado bruscamente de la plataforma ha...perjudicado muchos a puesta en marcha.
• Formato JSON.Otra solución relacionada es permitir que los usuarios o scripts descarguen archivos JSON o los lean/escriban en las API mencionadas. Esto está bien hasta cierto punto, pero JSON es muy libre y puede describir prácticamente cualquier cosa. Por ejemplo, Facebook...API de gráficosy LinkedInAPI RESTtratan cosas similares pero devuelven resultados JSON muy diferentes.
• PDF.Otra solución muy parcial es permitir a los usuarios exportar un PDF. Esto funciona para documentos, ya que el PDF es un...estándar abierto Que puede ser leído por otras aplicaciones como Vista Previa, Adobe Acrobat, Google Drive, Dropbox, etc. Pero un PDF está diseñado para ser un producto final, para ser leído por un Human. No está diseñado para ser una entrada para ninguna aplicación que no sea un visor de PDF.
• CSV.El archivo de valores separados por comas, aunque sencillo, se acerca más a lo que buscamos como solución general para el problema de importación/exportación de datos. A diferencia del backend de una API propietaria, CSV es unformato estándardescrito porRFC 4180A diferencia de JSON, que puede representar prácticamente cualquier cosa, un CSV suele representar solo una tabla. Y a diferencia de un PDF, un CSV puede ser editado localmente por un usuario mediante una hoja de cálculo o utilizado como entrada legible por máquina en una aplicación local o en la nube. Dado que la mayoría de los tipos de datos se pueden representar en una base de datos relacional, y dado que estas bases de datos suelen ser...exportado Como conjunto de archivos CSV posiblemente gigantescos, también es bastante general. Sin embargo, los archivos CSV presentan varias desventajas. En primer lugar, a diferencia de una API propietaria, no están alojados. Es decir, no existe un único lugar canónico para leer o escribir un archivo CSV que represente, por ejemplo, un registro de transacciones o una tabla de metadatos de mapas. En segundo lugar, los archivos CSV no son resistentes a la manipulación. Si un usuario exporta un registro de transacciones del servicio A, lo modifica y lo vuelve a subir al servicio B, el segundo servicio no se daría cuenta. En tercer lugar, los archivos CSV no cuentan con comprobaciones de integridad integradas para proteger contra errores involuntarios. Por ejemplo, las columnas de un archivo CSV no tienen información de tipo explícita, lo que significa que una columna que contenga los meses del año del 1 al 12 podría convertir automáticamente su tipo a un entero simple al importarla, lo que provocaría... confusión.
• MBOX.Aunque es menos conocido que el CSV, elFormato MBOXpara representar colecciones de mensajes de correo electrónico es lo más parecido a una estructura de datos estandarizada diseñada para la importación y exportación entre plataformas principales y aplicaciones independientes. De hecho, ha habidopapeles Proponiendo el uso de MBOX en contextos distintos al correo electrónico. Mientras que CSV representa datos tabulares, MBOX representa un tipo de datos estructurados en registros. Es esencialmente un único archivo de texto plano enorme con mensajes de correo electrónico en orden cronológico, pero también puede representar... imágenes/archivos adjuntos a través de MIME. Al igual que los archivos CSV, los archivos MBOX son... estándar abiertoY se puede exportar, editar localmente y reimportar. Al igual que CSV, MBOX tiene las desventajas de no tener un host canónico ni verificación intrínseca de la integridad de los datos.
• SFTP. Antes de continuar, hay ONE mecanismo de exportación/importación de datos que merece la pena mencionar: el protocolo seguro de transferencia de archivos (SFTP). Si bien es un método venerable, en realidad es la forma en que las personas se envían pagos ACH entre sí. En esencia, las instituciones financieras utilizan servidores SFTP para recibir datos de transacciones electrónicas. archivos con formato especialy transmitirlo a la Reserva Federal cada día para sincronizar los débitos y créditos ACH entre sí (veraquí,aquí,aquí, y aquí).

Cada uno de estos mecanismos se utiliza ampliamente. Sin embargo, son insuficientes para permitir la importación y exportación, en general, de datos valiosos sin manipulación entre actores económicos arbitrarios, ya sean entidades corporativas, usuarios individuales o scripts descentralizados. Para ello, necesitamos cadenas de bloques públicas.

Las cadenas de bloques públicas habilitan el estado compartido al incentivar la interoperabilidad. Convierten diversos tipos de problemas de importación y exportación de datos en una clase general de problemas de estado compartido. Y lo hacen, en parte, incorporando muchas de las mejores características de los mecanismos descritos anteriormente.

• Las cadenas de bloques públicas ofrecen métodos canónicos de acceso de lectura y escritura, como una API corporativa alojada, pero sin el mismo riesgo de plataforma. Ningún actor económico puede bloquear ni denegar el servicio a los clientes de una cadena de bloques pública descentralizada como Bitcoin o Ethereum.
• También permiten a los usuarios individuales exportar datos críticos a su computadora local o a una nueva aplicación como JSON/CSV/ MBOX (ya sea enviando fondos o exportando claves privadas) al tiempo que brindan garantías criptográficas de integridad de los datos.
• Proporcionan un medio para que cualquier actor económico (ya sean corporaciones, usuarios individuales o programas) interopere sin problemas. Todo actor económico que lee de una blockchain pública obtiene el mismo resultado, y cualquier actor económico con fondos suficientes puede escribir en una blockchain pública de la misma manera. No es necesario crear una cuenta y no se puede bloquear el acceso de lectura/escritura a ningún actor.
• Y quizás lo más importante es que las cadenas de bloques públicas ofrecen incentivos financieros para la interoperabilidad y la integridad de los datos.

Este último punto merece mayor explicación. Una cadena de bloques pública como Bitcoin o Ethereum suele registrar la transferencia de valores monetarios. Estos valores pueden ser la Criptomonedas intrínseca de la cadena, un token emitido en la parte superior de la cadena u otro tipo de activo digital.

Dado que los datos asociados a una cadena de bloques pública representan un valor monetario, finalmente ofrecen el incentivo financiero para la interoperabilidad. Después de todo, cualquier aplicación web o móvil que desee recibir, por ejemplo, BTC , debe respetar las convenciones de la cadena de bloques de Bitcoin . De hecho, los desarrolladores de aplicaciones no tendrían otra opción, ya que Bitcoin , por diseño, cuenta con una única cadena de prueba de trabajo canónicamente más larga, con validación criptográfica de cada bloque de dicha cadena.

Entonces ese es el incentivo financiero para la importación.

En cuanto al incentivo para la exportación, especialmente en lo que respecta al dinero, los usuarios exigen la posibilidad de exportar con total fidelidad y rapidez. No se trata de las fotos de sus gatos, que podrían perder por inconvenientes o problemas técnicos. Se trata de su dinero, sus Bitcoin, sus Criptomonedas. Cualquier aplicación que lo conserve debe permitir su exportación cuando quieran retirarlo, ya sea mediante la función de envío, ofreciendo copias de seguridad de claves privadas o ambas. De lo contrario, es poco probable que la aplicación reciba depósitos.

Ese es el incentivo financiero para la exportación. Por lo tanto, una blockchain pública incentiva económicamente a todos los actores económicos que interactúan con ella a utilizar el mismo formato de importación/exportación que los demás, ya sean corporaciones, usuarios o programas. Dicho de otro modo, las blockchains públicas son el siguiente paso después del código abierto, ya que proporcionan datos abiertos. Cualquiera puede programar su propio explorador de bloques leyendo desde una blockchain pública, y cualquiera puede crear su propia billetera capaz de escribir en ella.

Esto es un verdadero avance. Ahora contamos con una forma fiable de incentivar el uso del estado compartido, permitiendo simultáneamente que millones de personas y empresas accedan a leer (y miles a escribir) el mismo almacén de datos, aplicando un estándar común y manteniendo un alto nivel de confianza en la integridad de los datos.

Esto es muy diferente de lo habitual. Normalmente no se comparte la contraseña raíz de la base de datos en internet, ya que una base de datos que permite a cualquiera leer y escribir en ella suele corromperse. Las cadenas de bloques públicas resuelven este problema con criptografía en lugar de permisos, lo que aumenta considerablemente el número de usuarios simultáneos.

Es cierto que hoy en día las cadenas de bloques públicas suelen centrarse en aplicaciones monetarias y financieras, donde el conjunto de datos subyacente representa un historial de transacciones de solo anexión con registros inmutables. Esto limita su generalidad, en cuanto a abordar todas las diferentes versiones del problema de importación/exportación de datos. Sin embargo, se están desarrollando versiones de cadenas de bloques públicas de plataformas como OpenStreetMaps, Wikipedia y Twitter, así como de sistemas como Filecoin/IPFS. Estas no solo representarían registros de transacciones financieras donde la inmutabilidad fuera un requisito, sino que podrían representar otros tipos de datos (como entradas de mapas o enciclopedias) que se actualizarían periódicamente.

Si se implementan correctamente, estos nuevos tipos de sistemas públicos basados ​​en blockchain pueden permitir a cualquier actor económico con fondos suficientes o credenciales criptográficas no solo leer y escribir, sino también editar sus propios registros, preservando la integridad de los datos. Dada esta capacidad, no hay razón T no ONE una capa SQL sobre una blockchain pública para trabajar con el estado compartido que ofrece, al igual que una base de datos relacional tradicional. Esto da como resultado un nuevo tipo de base de datos sin propietario privilegiado, donde los siete mil millones de humanos del planeta (¡y sus scripts!) son usuarios autorizados, y en la que cualquier entidad con fondos suficientes puede escribir.

Ese día aún no ha llegado. Queda por ver hasta dónde podemos impulsar los casos de uso de las cadenas públicas. Y los desafíos de escalabilidad abundan. Pero con suerte, está claro que, si bien las cadenas de bloques públicas son, de hecho, un nuevo tipo de base de datos, ofrecen algo muy diferente a lo que ofrece una base de datos tradicional.

* La ONE excepción es la función "El solicitante paga", que ofrecen Amazon y otros servicios en la nube. Esta función es muy útil y permite pagar para escribir en tu bucket de S3. Sin embargo, es permisionada: requiere que cada posible escritor abra una cuenta de AWS, y el propietario del bucket debe permitir que todos escriban en él, por lo que sigue habiendo un único propietario distinguido.

Imagen de base de datos vía Shutterstock