Desempaquetamiento de los vectores de centralización en la Web3

Hace un año ilustré la pila de la Web3 tal como la entendía en ese momento. Más recientemente, publiqué las megatesis sobre criptomonedas de Multicoin, explicando la tesis de inversión para la Web3. Ahí resalté que una de las implicaciones clave de la Web3 es que la propiedad de los datos y la lógica de las aplicaciones se disocia.

En este ensayo, explicaré los problemas específicos inherentes a este proceso de desempaquetamiento y cómo hemos estado pensando en hacer inversiones en la pila de la Web3.

¿Dónde están las bases de datos y los datos?

Para fines prácticos, la gran mayoría de las aplicaciones modernas puede considerarse como un UX encima de una base de datos. Aunque hay algunas excepciones (por ejemplo, el streaming de videos y los videojuegos), en términos generales así funciona. Prácticamente todos los servicios de consumo principales (Facebook, Reddit, Evernote, Twitter, Google Docs, Gmail, iMessage, etc) pueden entenderse de manera simplificada como un UX encima de una base de datos.

En el modelo de la Web2, los proveedores de aplicaciones almacenan y administran los datos de los usuario para que los usuarios no tengan que hacerlo. Es más, los proveedores de aplicaciones de la Web2 siempre están conectados, porque ejecutan servidores las 24 horas del día, los 7 días de la semana, mientras que los usuarios se desconectan con mucha frecuencia (subterráneos, mala señal, problemas de batería, etc). En el modelo de la Web3, no hay un proveedor de aplicaciones centralizado, por lo que todo el paradigma de propiedad de los datos tiene que ser reformulado.

Eso hace necesario que nos planteemos un par de preguntas:

1. ¿Dónde almacena un usuario —llamémosla Alice— sus datos (asumiendo que no tenga un servidor propio)?
2. ¿Y cómo le envía a Alice contenido el remitente, si Alice está desconectada?

La respuesta más obvia es que Alice almacena el contenido en algún lugar que siempre está conectado y accesible, y que garantiza que cuando vuelva a conectarse ella sabrá dónde encontrar el contenido que le fue enviado. Este paradigma encapsula las aplicaciones tanto P2P como de mensajería y bases de datos tradicionales como periódicos, redes sociales y aplicaciones de toma de notas.

La ejecución de ese modelo plantea algunos desafíos mecánicos:

1. Alguien diferente a Alice debe saber cómo almacenar el contenido y tener un índice de ese contenido para que Alice pueda encontrarlo y descargarlo después.
2. Alice necesita saber dónde encontrar ese índice.
3. Con ese índice, Alice necesita encontrar y descargar los datos subyacentes que en sí mismos.
4. Quien almacena los datos no debe poder leer el contenido (si es privado) ni censurarlo.

Resolver esos problemas haría posible la disociación de la propiedad de datos y de la lógica de las aplicaciones, lo cual permitiría a su vez que la Web3 prosperara.

Antes de explorar cómo los empresarios modernos de la Web3 están resolviendo esos problemas, vale la pena analizar cómo otros han tratado de resolverlos en el pasado.

Intentos previos de descentralizar Internet

Ha habido unos pocos equipos de trabajo —incluyendo, entre otros, Zeronet, Freenet y Scuttlebutt— que han intentado lo que ellos mismos llaman "descentralizar Internet". Trataron de hacerlo antes de la era moderna de las criptomonedas tal y como la conocemos hoy. La mayoría de esos esfuerzos se centraron en apoyar casos en contextos de uso limitado; por ejemplo, mensajes y tableros de mensajes resistentes a la censura dirigidos a usuarios de países con regímenes autoritarios.

Si tienes curiosidad, te recomiendo probar cada uno de esos sistemas. Encontrarás que las UX dejan mucho que desear. Aunque esos sistemas tienen muchos problemas con las UX, el más grande con creces es la velocidad. Todo es fastidiosamente lento.

¿Qué pasa? ¿Por qué son tan lentos?

Porque todos están descentralizados desde el punto de vista lógico.

Esos sistemas adoptaron diferentes variaciones de la siguiente arquitectura. Describiré sus arquitecturas en el contexto de una aplicación de mensajería P2P cifrada:

1. Esos sistemas se basan en la idea de que si alguien le envía un mensaje a Alice mientras ella está desconectada, más bien se lo envían a Bob y Bob almacenará el mensaje en nombre de Alice.
2. Cuando Alice vuelve a conectarse, le pregunta a Bob si se perdió de algo mientras estaba desconectada (índice de mensajes).
3. Desafortunadamente, Alice no tiene garantía de que 1) Bob esté conectado en este momento, 2) Bob haya estado en línea mientras ella no lo estuvo, ni de que 3) Bob tendrá el índice completo de mensajes que ella perdió mientras estuvo desconectada. Para remediar eso, Bob puede preguntarles a sus compañeros si saben de algún mensaje que se le haya enviado a Alice. Sin embargo, puede que esos pares también estén o hayan estado desconectados, así que puede que también tengan información incompleta.

En este paradigma, simplemente no es posible garantizar la entrega de mensajes, ya que no está claro adónde se deben enviar los mensajes y quién debe almacenar el índice de los mismos. Eso crea más problemas cuando la destinataria vuelve a conectarse, ya que no sabe dónde encontrar la lista de mensajes que le fueron enviados, ni la referencia de los mensajes de datos.

Scuttlebutt, que se centra en construir una red social P2P, intenta resolver eso adoptando un sistema de amigos de registro con confirmación, similar al de Facebook. Es decir, una vez que Alice y Bob se hacen amigos, comparten entre sí sus listas de amigos para que Bob pueda indexar y almacenar contenido publicado por los amigos de Alice, en nombre de Alice. Eso exige que Alice les notifique a todos sus amigos que Bob es su representante y viceversa. Entonces, cuando los amigos de Alice publican una actualización mientras Alice está desconectada, los amigos de Alice pueden enviarle esa actualización a Bob, que puede hospedarla para Alice.

Zeronet y Freenet, que son más generalizados que las redes sociales P2P, usan un modelo similar, excepto que no hay un modelo de amigos de registro con confirmación. Eso le añade varias complejidades al sistema y lentifica aún más las cosas. A diferencia del modelo Scuttlebutt, donde los amigos acuerdan ayudarse mutuamente para tener rutas de información definidas, los usuarios de Freenet y Zeronet tienen que comprobar la disponibilidad de otros usuarios de manera aleatoria y preguntarles qué información tienen. Esa es la causa fundamental de la lentitud de esos sistemas.

1. Digamos que Alice logra finalmente recomponer las piezas del índice de todo lo que se perdió mientras estaba desconectada. Es decir, ella sabe que Carol le envió una foto y que Dave está guardando esa foto en “dave.com/alicepic1.png”. Si Dave está desconectado, ¿cómo puede Alice acceder a la foto?

Esos problemas no son triviales. Descentralizar Internet es difícil.

(Des)centralización lógica y arquitectónica

La causa raíz de todos los problemas descritos es la falta de almacenamiento e indexación centralizados de forma lógica. ¿Qué es el almacenamiento centralizado de forma lógica? Para responder a esa pregunta, ayuda entender los tres vectores de la descentralización en los sistemas distribuidos:

1. Arquitectónico: el número de computadoras que tiene el sistema
2. Político: el número de personas que pueden ejercer influencia sobre el sistema
3. Lógico: el número de interfaces por medio de las cuales los agentes externos interactúan con el sistema

Para una explicación más sólida de esos conceptos, recomiendo este ensayo de Vitalik Buterin.

Los monopolios de la Web2 resolvieron todos los problemas descritos en la sección anterior porque dependen del almacenamiento centralizado de forma lógica. Es decir, cuando Alice vuelve a conectarse, solo le pregunta al servicio web centralizado, que mantiene el almacenamiento centralizado, qué mensajes se perdió desde la última vez que estuvo conectada. El servicio web consulta una base de datos que controla, y que contiene todos los mensajes de los usuarios, y luego entrega los mensajes correctos.

El problema de este modelo es que estos sistemas Web2 agrupan todas las formas de centralización: están centralizados de forma lógica, política y (excluyendo los fines de escalamiento) arquitectónica.

Entonces, ¿hay sistemas de almacenamiento que estén centralizados desde el punto de vista lógico, mas no desde el punto de vista arquitectónico ni político?

Afortunadamente, la respuesta es un sí rotundo: el sistema de archivos interplanetarios (IPFS) para el almacenamiento por contrato y Arweave para el almacenamiento permanente (almacenamiento por contrato: almacenar X bytes de datos durante un período Y con garantías de recuperación Z. AWS, GCP, Azure, Filecoin y Sia son sistemas de almacenamiento por contrato).

¿Qué significa exactamente que el sistema esté centralizado desde el punto de vista lógico, pero descentralizado desde el punto de vista arquitectónico y político? La mejor manera de entenderlo es analizando cómo es que una computadora recupera archivos básicos de otro servidor de la web hoy en día (direccionamiento por ubicación) y luego comparar eso con el enfoque IPFS/Arweave (direccionamiento por contenido).

En la arquitectura de la Web2, si Alice quiere descargar una imagen de un servidor, usa un URL que es más o menos así: website.com/image.png. ¿Qué pasa exactamente cuando Alice intenta ir a ese URL?

Usando el DNS, Alice sabe dónde encontrar el servidor en website.com y le pide al servidor la imagen que aloja y que está ubicada en su sistema de archivos local en “/image.png”. Suponiendo que el servidor quiera cooperar, este revisa su directorio para ubicar /image.png y, si el archivo existe, se lo entrega a Alice.

Noten lo frágil que es el sistema: si el archivo se mueve o se cambia, si el servidor está ocupado o no coopera por el motivo que sea, la solicitud de Alice falla.

La web está construida sobre esa base hoy en día.

En un sistema de direccionamiento por contenido, como el utilizado en IPFS y Arweave, el URL que Alice visita es más bien algo así: QmTkzDwqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D.

Aunque ningún humano puede leerlo, se genera de manera determinista a partir del contenido del que se deriva. Es decir, solo hay una pieza de contenido en el universo que, al crearse el hash, produce ese cadena exacta. La magia de IPFS y Arweave es que manejan toda la complejidad que le permite a una computadora resolver QmTkzDwW... en esta página web.

(Si quieres aprender más sobre el trabajo de IPFS, esta serie de 6 partes es un excelente punto de partida).

El contenido de las redes de IPFS y Arweave se almacena en muchas máquinas. Independientemente de cuántas máquinas almacenen el contenido y en qué parte del mundo se encuentren, esos protocolos resuelven direcciones como QmTkzDwW... sin importar dónde se almacene el contenido real.

Esa es la magia del direccionamiento por contenido. Este expone una única interfaz lógica —la dirección basada en el contenido— que siempre se resuelve correctamente sin importar dónde se almacenen los datos subyacentes a lo largo de una amplia red de computadoras descentralizadas desde el punto de vista arquitectónico y político.

De los cuatro principales problemas técnicos descritos al comienzo de este ensayo, el direccionamiento por contenido resuelve los problemas número 1, 3 y 4 (almacenar el contenido, hacer que el contenido esté disponible para descargar y asegurarse de que el hospedador no pueda leer información privada). Pero ¿qué pasa con el problema número 2: saber dónde buscar los datos?

La indexación

Aunque IPFS y Arweave actúan como sistemas de archivos centralizados desde el punto de vista lógico pero descentralizados desde lo arquitectónico y lo político, no son bases de datos. Es decir, no hay manera de consultarlos y pedirles: “por favor muéstrame todos los mensajes que Bob le envió a Alice entre las fechas X y Y”.

Afortunadamente, hay varias maneras de resolver ese problema.

Un enfoque es almacenar el índice de mensajes directamente en cadenas de bloques. Las cadenas de bloques son bases de datos centralizadas desde el punto de vista lógico pero descentralizadas desde el punto de vista arquitectónico y político. Utilizando un servicio descentralizado como The Graph o un servicio centralizado como dFuse, Alice puede consultar los índices almacenados en las cadenas de bloques. La cadena de bloques no almacena los datos subyacentes, sino solo un hash de los datos. Ese hash es solo un apuntador hacia el contenido almacenado en IPFS o Arweave. Hoy, tanto The Graph como dFuse funcionan, y muchas aplicaciones han adoptado ese modelo de almacenamiento de hashes en la cadena que apuntan a datos almacenados en sistemas de direcciones basadas en el contenido.

El segundo enfoque es usar Textile. Textile ha construido una tecnología única a la que llaman Threads, y estos "threads" o hilos actúan como base de datos personal privada y encriptada encima de IPFS. Dado que esa base de datos está construida sobre IPFS, está centralizada desde el punto de vista lógico, pero descentralizada desde el punto de vista arquitectónico y político. Como base de datos centralizada desde el punto de vista lógico, los remitentes y receptores saben adónde enviar la información y dónde leerla. Es más, hace poco, Textile lanzó Cafes, que les permite a los usuarios establecer un servidor para alojar sus Threads (en lugar de alojar Threads de manera local). El siguiente paso para Textile sería construir una capa económica para incentivar a los validadores para que alojen Cafes para otros usuarios, lo que es análogo al modo en que Filecoin es la capa económica de IPFS.

El tercer enfoque es usar OrbitDB. OrbitDB es similar a Threads de Textile, excepto que OrbitDB está diseñado principalmente para datos públicos (por ejemplo, para construir un Twitter descentralizado), mientras que Threads de Textile integra de forma nativa el cifrado y la administración de claves para información privada (por ejemplo, los mensajes P2P). Al igual que Textile, OrbitDB ya está disponible, y el equipo de OrbitDB está trabajando en una capa económica que pueda ir encima de la tecnología subyacente.

Por último, hay varios equipos que están construyendo bases de datos tradicionales efectivas con diferentes vectores de descentralización: las construcciones de Fluence operarán en entornos sin permisos con garantías de BFT, mientras que Bluzelle está construyendo un sistema de dos niveles con un conjunto de nodos maestros políticamente centralizados, y un conjunto arquitectónicamente descentralizado de nodos réplica.

Dado el trabajo que los equipos de contratos inteligentes están haciendo para resolver el problema de disponibilidad de datos a escala, como es el caso de los Replicadores de Solana, somos escépticos frente a la idea de sumar una capa BFT encima de bases de datos tradicionales. Así que hemos optado por invertir en bases de datos "cripto-nativas" como Textile y en la capa API de desarrolladores en la forma de The Graph y dFuse.

Con los protocolos y servicios descritos —IPFS, Filecoin, Arweave, The Graph, dFuse, Textil y OrbitDB— hay una ruta clara por la que la Web3 podría llegar a florecer. Todos esos servicios existen actualmente, aunque no estén del todo listos para la producción ni hayan llegado a la escala necesaria ni cuenten con una criptoeconomía a prueba de batallas. Sin embargo, hay soluciones conocidas para el problema más importante: exponer una única interfaz centralizada desde el punto de vista lógico para los sistemas descentralizados desde el punto de vista político y arquitectónico.

¿Falta algo?

Lógica de alto nivel

Ahora que tenemos soluciones para el almacenamiento, la indexación y la recuperación centralizada desde el punto de vista lógico pero descentralizada desde el punto de vista arquitectónico, podemos permitirnos pensar en la lógica de alto nivel. A continuación, algunos ejemplos:

1. ¿Cómo administra Alice varias identidades? Por ejemplo, puede que Alice no quiera usar la misma clave pública en todas sus plataformas (Facebook, Google, Snapchat y Reddit). ¿Y qué pasa si quiere administrar esas identidades en una sola interfaz sin vincularlas públicamente?
2. Dado que Alice quiere enviarle información privada a Bob pero almacenarla en IPFS o Arweave —que son por definición sistemas públicos— deben usar el establecimiento de comunicación (handshake) mediante el secreto perfecto hacia adelante (PFS). ¿Cómo configuran el PFS de manera asincrónica y cómo administran todas las claves asociadas?
3. Dado que los esquemas tradicionales de cifrado están diseñados para la comunicación exclusiva entre dos partes, ¿cómo puede el sistema admitir comunicaciones privadas para grupos grandes de personas como tableros de mensajes o grupos de chat grandes?
4. ¿Cómo habilita el sistema patrones UX comunes como el descubrimiento de grupos, la recuperación de datos de usuario, la eliminación de contenido, etc.?

Aunque esos son problemas técnicos distintos, yo los agrupo todos bajo la categoría general de problemas de “lógica de alto nivel”.

Threads de Textile se ocupan precisamente de ese tipo de problemas. En muchos sentidos, se puede pensar en Textile como una iCloud para IPFS. Aunque esa analogía no es perfecta, generalmente funciona: Así como iCloud sintetiza la sincronización entre dispositivos y la copia de seguridad de datos para aplicaciones (brindándole una mejor experiencia al usuario y al desarrollador), Textile brinda todas las herramientas lógicas de orden más elevado encima de IPFS para que el desarrollo de aplicaciones sea perfecto para los desarrolladores, garantizando al mismo tiempo la óptima sincronización entre dispositivos y copias de seguridad perfectas para los usuarios en IPFS.

Mirando hacia el futuro

El ecosistema de la Web3 es increíblemente diverso en muchas dimensiones: en los tipos de problemas que se están resolviendo, en las ubicaciones de los equipos, en los modelos económicos que se están empleando y muchas más. El hecho de que la pila de la Web3 se esté formando a pesar de que no haya ninguna entidad centralizada desde el punto de vista lógico que coordine todo es realmente notable. Sin embargo, eso también significa que hay mucha entropía en el sistema, de modo que resulta difícil entender los temas de más alto nivel. En este ensayo, traté de destilar eso de la siguiente manera:

El mayor desafío en la transición de la Web2 a la Web3 es la transición de sistemas en los que los tres vectores de centralización (lógica, arquitectónica y política) se han asociado a sistemas centralizados desde el punto de vista lógico pero descentralizados desde el punto de vista político y arquitectónico.

Si estás construyendo infraestructura o aplicaciones básicas en la pila de la Web3, por favor ponte en contacto con nosotros o envíame un DM por medio de Twitter. Buscamos hacer más inversiones en la Web3. Creemos que la Web3 va a ser un cambio de paradigma que pondrá a circular billones de dólares en valor durante la próxima década, y nosotros queremos apoyar a los mejores emprendedores que se ocupan hoy día de construir la infraestructura fundamental necesaria.

Gracias a Andrew Hill y Sam Williams por sus comentarios sobre este ensayo.

*Revelaciones: Multicoin Capital ha invertido en Solana, The Graph, Textile, Arweave y Dfuse. Multicoin Capital se rige por una "política de no negociación" para los activos enumerados en este informe durante los 3 días ("período de no negociación") siguientes a su publicación. 9 Ningún funcionario, directivo ni empleado comprará ni venderá ninguno de los activos antes mencionados durante el Período de no negociación.*