Más allá de "La cadena de bloques es la aplicación"

Mic Bowman es un ingeniero principal de Intel 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.

Cuatro vehículos autónomos llegan a una intersección. ¿Quién pasa primero?

Sí, esto suena a chiste malo, pero el problema es muy real y sorprendentemente complejo. La solución reside en la computación descentralizada, un campo emergente que probablemente involucrará cadenas de bloques, junto con muchas otras tecnologías. Para comprender los problemas que intenta resolver, profundicemos en este impasse suburbano...

Si asumimos que no existe una infraestructura estática —por ejemplo, una baliza— para arbitrar la intersección, los vehículos tendrán que buscar una solución utilizando únicamente su capacidad de cálculo. ¿Cuáles serían las instrucciones del ordenador? Bueno, existen algunas reglas sociales generales: ONE quiere un accidente; todos quieren pasar la intersección lo más rápido posible; y existe un cierto concepto de "justicia" ("¡En serio, llegué primero, así que puedo pasar primero!").

Todo esto suena más o menos factible, salvo que los vehículos podrían estar equipados con un "botoncito rojo" que truca la negociación para pasar primero. (En serio, si llegas tarde al trabajo, pulsarías el botón, ¿verdad?).

Sin embargo, desde la perspectiva de la arquitectura de sistemas, este escenario presenta grandes problemas. Algunos de ellos son: no existe una autoridad central que decida qué coche va en qué orden. En segundo lugar, la única infraestructura disponible para el cálculo reside en los coches; es decir, los recursos se asignan dinámicamente para el cálculo. En tercer lugar, cada conductor está motivado por objetivos que impulsarán el cálculo de su vehículo, y si bien algunos objetivos, como pasar la intersección sin accidentes, son compartidos por todos, otros serán exclusivos de cada individuo.

(Llego tarde, así que déjame pasar primero).

Es esta última característica la que hace que la computación descentralizada sea tan desafiante.

Aplicaciones y desafíos

Las criptomonedas son las aplicaciones más consolidadas de la computación descentralizada. Pero existen muchas otras. En la mayoría de los casos, las cadenas de bloques, que funcionan como una alternativa descentralizada y basada en el consenso a la confianza en una autoridad centralizada, probablemente desempeñarán un papel clave. Sin embargo, las cadenas de bloques son inútiles por sí solas. Para que la computación descentralizada funcione, deben interactuar con otras soluciones.

Una aplicación muy debatida de la computación descentralizada es la procedencia en las cadenas de suministro. Walmart anunció recientemente que todos sus proveedores de alimentos deben subir sus datos a un sistema basado en blockchain para que los usuarios puedan monitorear la cadena de suministro en busca de alimentos contaminados. Ideas similares se están aplicando al rastreo de minerales libres de conflicto.

En estos casos de procedencia, la cadena de bloques es un componente crucial, pero de ninguna manera el ONE. Como comenté en la Consensus Magazine del año pasado, si bien una cadena de bloques puede proporcionar gestión transaccional, almacenamiento y actualización de datos persistentes y transparentes, la capacidad de rastrear la procedencia también requiere una entrada de datos eficiente y de alta integridad. La calidad del monitoreo de la cadena de bloques depende de los datos recopilados. Sin una supervisión adecuada, la entrada de datos (por ejemplo, mediante datos de sensores y telemetría) puede ser manipulada por un participante malicioso para falsear la procedencia.

Las aplicaciones de la cadena de suministro también demuestran la importancia de la confidencialidad y la Privacidad de los datos, ya que, en CORE, se centran en el acceso interorganizacional a datos compartidos. Consultas sobre los datos como "¿de dónde proviene esta lechuga?" son relativamente indiscutibles y, en la mayoría de los casos, coherentes con los objetivos compartidos de los participantes. Sin embargo, otras son más conflictivas, y son precisamente estas las que exponen las dificultades para gestionar la confidencialidad en sistemas descentralizados.

¿Puede un proveedor demostrar, por ejemplo, que puede cumplir con los requisitos de entrega sin revelar detalles confidenciales de sus operaciones internas? Aquí reside un problema CORE para la computación descentralizada: cómo realizar computación en toda la red con datos confidenciales sin exponer los detalles de esa información confidencial al grupo.

Considere los desafíos que presentan los datos genómicos. Con la investigación en busca de curas para enfermedades, existe un enorme valor social y potencialmente comercial al realizar cálculos en el conjunto más amplio posible de fuentes de datos genómicos, fuentes que a menudo son creadas, gestionadas o propiedad de diferentes organizaciones. Sin embargo, cada base de datos contiene datos de gran valor como propiedad intelectual y que están restringidos por regulaciones que protegen la Privacidad de quienes Colaboradores a dichos datos genómicos.

Dilema.

O podríamos simplemente volver a nuestros vehículos autónomos, que probablemente siguen estacionados en la intersección. ("Tú pasa primero". "No, tú pasa primero", "No, TÚ pasa primero"). Un requisito reciente para operar un AV es que debe tener una "caja negra" que registre datos de telemetría que puedan usarse para analizar el comportamiento pasado; por ejemplo, para determinar la causa de un accidente. Esta es básicamente la misma función que desempeña una caja negra en un avión, con una diferencia clave: un avión está prácticamente solo en el cielo, mientras que un vehículo autónomo interactúa continuamente con otros vehículos (potencialmente autónomos). La caja negra en un vehículo proporciona una perspectiva histórica única.

Sin embargo, no proporciona información sobre las acciones o decisiones de los demás vehículos autónomos en la carretera. Todo esto se complica por el aprendizaje automático adversario, que podría crear un nuevo vector de ataque para los vehículos autónomos. ¿Cómo puede una computadora, basándose en un simple registro local de datos de telemetría, diferenciar entre un error interno del vehículo autónomo, un ataque externo a su telemetría o las acciones de un participante malicioso en el protocolo de coordinación?

Idealmente, para proporcionar un historial del comportamiento del vehículo resistente a ataques, la caja negra compararía los datos de telemetría del vehículo con los de los vehículos cercanos, así como información sobre las interacciones con estos; en otras palabras, una instantánea completa del sistema. Esto nos devuelve al problema de realizar cálculos con información confidencial de fuentes no confiables.

Tratando a Blockchain como el ancla de la confianza

El Internet de las Cosas exigirá aplicaciones descentralizadas. Sin embargo, desarrollar versiones no triviales de ellas es difícil. Se sabe que problemas relativamente sencillos, como el intercambio justo determinista entre dos partes, son imposibles sin un tercero de confianza que gestione la interacción. En este caso, una cadena de bloques aporta un gran valor porque, en efecto, se convierte en un tercero de confianza basado en la tecnología que puede arbitrar protocolos multipartitos. Aun así, debemos abordar muchos otros desafíos antes de lograr la computación descentralizada de propósito general.

En parte, para llegar a ese punto es necesario hacer una transición de "blockchain es la aplicación" a "blockchain es el ancla de confianza".

Es una transición que ya estamos viendo en Bitcoin. Por ejemplo, la Red Lightning traslada la gestión de las transacciones de Bitcoin a un canal externo creado por dos participantes que solo cerrarán sus saldos a la blockchain si surge una disputa externa.

De esta manera, la cadena de bloques funciona como un ancla de confianza, mientras que Lightning Network es la aplicación descentralizada.

Mientras tanto, Thunderella, un algoritmo de consenso desarrollado en la Universidad de Cornell, logra una mejora sustancial del rendimiento al combinar un protocolo de consenso "fuera de cadena" optimista y de alto rendimiento con una ruta lenta asincrónica que utiliza un protocolo de consenso de blockchain tradicional como ancla de confianza de respaldo cuando fallan las suposiciones optimistas.

En este caso, el rol de la cadena de bloques subyacente es publicar evidencia de que las suposiciones optimistas ya no se cumplen y restablecer las opiniones inconsistentes.

Nuestro trabajo sobre Objetos de Datos Privados, un proyecto de Hyperledger Labs para explorar modelos de computación descentralizada, divide la ejecución de contratos en un componente externo a la cadena que realiza el cálculo real y un componente interno a la cadena que simplemente garantiza un orden de actualizaciones que respeta las dependencias entre los objetos del contrato. Por lo tanto, intuitivamente, la cadena de bloques funciona como un registro descentralizado de confirmación/coordinación para las actualizaciones de la base de datos.

Enfrentando el desafío de la confidencialidad

¿Cómo escalar esto y proteger la confidencialidad?

Bueno, un enfoque requiere que reconozcamos que equilibrar las tensiones entre los objetivos compartidos e individuales se simplifica si ampliamos nuestras nociones de computación exitosa. Bajo el principio de Privacidad diferencial, podemos reducir, o "fuzzear", la precisión requerida de una base de datos para preservar la confidencialidad. Por ejemplo, podríamos convertir un resultado preciso como "el camión de reparto está en la calle 4 y Wilshire" en algo menos definitivo como "el camión de reparto llegará en unos 10 minutos".

Considere cómo este concepto —donde algunos objetivos deben cumplirse para el éxito, mientras que otros se "difuminan" para completar el cálculo— podría aplicarse a nuestros vehículos autónomos. Quizás no sea necesario que el primer vehículo en llegar a la intersección sea el ONE en cruzarla, siempre que no haya accidentes y pueda continuar a tiempo hasta su destino. La equidad y el orden de llegada siguen siendo los objetivos, pero podrían no ser requisitos para el éxito.

Otros avances en informática también podrían ser útiles. Las criptomonedas que preservan la privacidad y utilizan pruebas de conocimiento cero (ZKP), como Zcash y Monero, demuestran el poder de la criptografía para permitir la computación en conjuntos de datos con privacidad protegida. Sin embargo, hasta la fecha, los desarrolladores han tenido dificultades para llevar esta Tecnología computacionalmente compleja a la escala necesaria para la computación descentralizada de propósito general.

En este caso, los entornos de ejecución confiables (TEE) basados ​​en hardware ofrecen una alternativa potencial. Muchos procesadores modernos incorporan Tecnología para realizar cálculos que garantiza la integridad y confidencialidad de los mismos en determinadas circunstancias.

Entre los productos disponibles se incluyen TrustZone de ARM, Software Guard Extensions (SGX) de Intel y Secure Encrypted Virtualization (SEV) de AMD. Para quienes prefieren las especificaciones de hardware abiertas, el Proyecto Keystone, de investigadores de la Universidad de California en Berkeley y el MIT, busca desarrollar una TEE de código abierto para el procesador RISC-V.

Un TEE basado en hardware proporciona un entorno informático de propósito general que aborda los requisitos de rendimiento y flexibilidad que limitan la aplicabilidad de las tecnologías ZKP. Sin embargo, la confianza basada en hardware no debe considerarse una panacea. Cuando se integra adecuadamente en el contexto general del diseño de seguridad, podría ser una forma eficaz de...

ejecutar cálculos confidenciales de manera optimista.

En otras palabras, la computación descentralizada requiere una combinación de soluciones. Me da rabia decírselo, pero esos coches atascados en la intersección tendrán que realizar múltiples tareas.

Imagen de la placa basevía Shutterstock