PROTOCOLO SOCIAL PEER-TO-PEER A ESCALA WEB
TLDR:
- Estamos construyendo Solcial para ofrecer a los usuarios una experiencia lo más parecida posible a las plataformas de medios sociales de la web2, al mismo tiempo aprovechamos las tecnologías de la web3.
- Uno de los obstáculos a los que se enfrenta cualquier plataforma basada en la blockchain son las tarifas(fees) de los usuarios. Con el fin de eliminar las tarifas de los usuarios para las operaciones no relacionadas con los tokens, manteniendo al mismo tiempo la privacidad y el consenso, Solcial está construyendo una capa peer-to-peer (P2P) sobre Solana y la red está construida sobre libp2p que brinda contenido (feeds, “me gusta”, etc) a través de auto alojamiento y replicación entre pares.
- También hemos desarrollado un tipo especial de nodo que tiene el mismo protocolo externo que una aplicación típica de escritorio o móvil, con optimizaciones añadidas diseñadas para manejar decenas de miles de pares concurrentes, llamados Nodos Beacon. Los Beacons son esencialmente un conjunto de servicios de anclaje que preservarán el contenido de los usuarios cuando los creadores se desconecten y lo pondrán a disposición de otros usuarios. Todo el contenido de los usuarios se almacena en IPFS y se accede a él a través de una capa P2P sin depender de servidores o pasarelas censurables.
Introducción
Este es el primer post de una serie de notas que describen cómo el funcionamiento interno del protocolo Solcial le confiere unas propiedades únicas de resistencia a la censura al tiempo que mantiene un rendimiento razonable en el intercambio de datos.
Topología de la Red
Los nodos se comunican a través de la Internet pública, formando una red superpuesta específica de Solcial mediante una versión modificada del protocolo HyparView¹.
Cada nodo mantiene una lista de pares activos con un tamaño de log2(N)+1 donde N es el tamaño estimado de toda la red. El valor de N se extrae de la blockchain hallando el número de cuentas de usuario registradas hasta la fecha, y se actualiza periódicamente a medida que el número de usuarios crece. Las conexiones con los pares activos son estables, bidireccionales y persistentes y son los nodos con los que se comunican directamente durante el cotilleo o cualquier otra actividad p2p. Cada nodo también mantiene una lista de pares pasivos con un tamaño de 6⋅(log2(N)+1) que se utilizan como pares de respaldo en caso de que alguno de los pares activos se desconecte o deje de responder. El protocolo subyacente para las conexiones entre los pares activos es QUIC² con encriptación NOISE, todo ello alimentado por libp2p³.
El recorrido de árboles del NAT se consigue mediante tres métodos que se utilizan en función de las circunstancias de la red del par. El primer método consiste en utilizar IPv6 en lugar de IPv4 siempre que sea posible, ya que en ese caso no hay necesidad de NAT, aunque según las estadísticas solo menos del 40% de Internet está en IPv6⁴.
El mecanismo de fallback es utilizar AutoNAT empleando el protocolo de identidad de libp2p que pregunta a otros nodos de la red sobre la dirección visible de nuestra máquina. Esa dirección, al ser iniciada por el par detrás de un NAT, ya está registrada con su router hacia la máquina destino, sin embargo existen circunstancias en las que esto no funciona, entonces volvemos a la tercera y más confiable pero costosa opción.
La tercera opción es utilizar el protocolo libp2p de retransmisión de circuitos⁵ que imita el funcionamiento de un protocolo TURN⁶ al tener un nodo intermedio que retransmite paquetes entre dos pares detrás de NATs. Este papel puede ser asumido por los nodos baliza y algunos pares con IPs públicas que optan por ser relés con límites configurados. Más adelante en este artículo se hablará de los nodos baliza.
Identidad de los pares
Los pares se identifican utilizando su clave pública en forma de multihash⁷ que es igual a la clave pública de su dirección de billetera en Solana que está registrada en el contrato de la cadena de Solcial. La única forma de asumir un determinado ID público de par es poseer la clave secreta de un par de claves ED25519.
Este par de claves también se utiliza para establecer canales encriptados para todo el paso de mensajes entre pares, así como una forma de verificar la autenticidad de los mensajes que presumiblemente son producidos por el propietario de la billetera.
Afiliación a la red
Los pares con claves públicas no registradas en la cadena no podrán unirse a la overlay de la red HyparView y, por lo tanto, quedarán automáticamente excluidos de la red peer-to-peer de Solcial.
Todos los pares que quieran unirse al peer to peer de Solcial enviarán un mensaje JOIN a uno de los nodos de arranque (algunos de esos nodos de arranque son también nodos beacon) en el topic /solcial/public. La introducción de topics en HyparView es una de nuestras modificaciones al documento original.
Cualquier nodo que reciba una petición JOIN de un par, verificará primero que el multihash exista en la cadena y esté asociado a una cuenta Solcial, entonces enviará un mensaje FORWARDJOIN a uno de sus pares activos con un paseo aleatorio activo establecido en 3, ellos a su vez propagarán ese mensaje a todos sus pares activos, incrementando el número de saltos actual en uno hasta llegar a 3 saltos. Esto es una mitigación para los ataques DDoS contra los nodos de arranque, así como una técnica de descentralización efectiva para propagar y aleatorizar la conectividad entre los nodos tanto como sea posible.
Cualquier nodo que esté a menos de 3 saltos del receptor inicial de JOIN enviará un mensaje NEIGHBOR al solicitante inicial de JOIN estableciendo una conexión persistente activa entre ellos.
Periódicamente, cada 15 segundos, los nodos emitirán un mensaje SHUFFLE a un par activo aleatorio con una muestra aleatoria de sus pares activos y pasivos, y establecerán la longitud del paseo aleatorio de este mensaje en 4. Esto asegura que todos los pares de la red siempre tengan información fresca sobre otros pares que pueden almacenar en su vista pasiva para propósitos de reparación de la red, siempre que alguno de sus pares activos deje de responder o se desconecte explícitamente.
Eficiencia Gossip
Sólo los pares activos participan en la difusión de mensajes entre pares. Los pares activos forman una red superpuesta sobre la Internet pública y existen ciclos en el gráfico de conectividad entre los nodos. Para permitir un gossip eficiente de los mensajes entre pares en la red, necesitamos, en primer lugar, minimizar la propagación de mensajes duplicados entre pares y, en segundo lugar, encontrar la ruta más óptima para los mensajes.
Para ello se utiliza el algoritmo Epidemic Broadcast Trees⁸, que forma un árbol de extensión mínima entre pares, dividiendo los pares en un grupo de nodos eager-push y nodos lazy push. Los nodos "eager-push" siempre reciben mensajes tan pronto como los recibe cualquier nodo.
Los nodos lazy push reciben periódicamente, cada 500ms, un lote de IDs de mensajes vistos por el nodo actual. Cuando un nodo observa que hay un ID de mensaje en el lote de lazy push que no fue recibido de su nodo padre ascendente, reconstruirá (GRAFT) la conexión y restaurará su estado de active push. Esto constituye el mecanismo de reparación del árbol de expansión mínimo en caso de que uno de los nodos se caiga y se formen gráficos disjuntos. Los mensajes GRAFT restauran la conectividad completa de la red.
Cuando se descubre que un mensaje recibido es un duplicado de un mensaje previamente recibido de un nodo activo, entonces la conexión a ese nodo se considera un ciclo en el grafo y se transforma en un lazy push enviando un mensaje PRUNE.
Otro caso para “eliminar” (pruning) una conexión activa y sustituirla por una de la lista lazy es cuando observamos que el número de saltos que recorre un mensaje para llegar a nosotros a través de un nodo lazy es inferior a 4 saltos que el de un mensaje del par activo. Esto constituye el algoritmo de optimización del árbol de difusión.
Difusión de contenidos
Los mensajes “gosspieados” a través del protocolo p2p descrito en las secciones anteriores son mensajes IPFS Bitswap⁹ con CIDs de contenidos producidos por los usuarios de Solcial. Para entender mejor cómo se utiliza Bitswap e IPFS en Solcial, primero vamos a describir la estructura de un perfil de usuario.
Cada cuenta de usuario en la red tiene algo llamado índice de perfil. Este índice apunta a los CID de las últimas versiones de su contenido. El índice es una Secuencia Consistente Eventual CRDT que forma un registro inmutable de las operaciones realizadas por la cuenta.
El índice del perfil puede considerarse como una lista enlazada en la que cada elemento apunta al CID del elemento anterior y es aceptado por los pares como el siguiente elemento en la secuencia sólo si está firmado por la clave privada del propietario de la cuenta. Un ejemplo lógico de alto nivel de un feed de perfil publicado codificado en este formato tiene el siguiente aspecto:
{
"autor": "12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT",
"prev": "QmYtUc4iTCbbfVSDNKvtQqrfyezPnFvE33wFmutw9PBBk",
"action": "append-feed-post",
"timestamp": "2022-01-11T15:58Z",
"params": {
"content": "QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb"
"enckey": "z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq"
},
"signature":
"2Lpnvt23H6qHswCNPmwCCUSas7YNP[...]jV1dC9qdNPR4zDqsCuBX"
}
Una entrada así tiene su propio CID y se transmite como objeto IPFS PB-DAG¹⁰ al topic superpuesto HyparView /solcial/content. Esta entrada está vinculada a su entrada anterior y a cualquier contenido adicional mediante la consulta recursiva de los CID vinculados los usuarios pueden obtener todo el historial de la cuenta y el contenido.
Este objeto es validado primero por cualquier par receptor si la firma del contenido coincide con la clave pública del autor. En caso de que la verificación de la firma falle, el par remitente es expulsado permanentemente del nodo actual por violar el protocolo. Una validación de firma exitosa propaga el contenido a todos los demás pares interesados en el contenido creado por esta cuenta.
Cuando un par recibe un CID de este tipo, se añade al registro de operaciones del autor. La suma de todas las operaciones realizadas por el autor constituye el estado actual del perfil.
Por defecto, cada nodo pinea y siembra el contenido de su propia cuenta y el de sus amigos. Hay pares especiales que estamos construyendo como parte de nuestra infraestructura y que llamamos nodos beacon y son como los pares de los usuarios normales, excepto que están interesados en el contenido de todos y sirven como una especie de servicio de fijación de IPFS específico para todo el contenido en caso de que todos los sembradores actuales estén fuera de línea. Piensa en ellos como nodos que son pares de todos. La red puede funcionar sin ellos, pero proporcionan una capa extra de disponibilidad de contenidos.
Acceso de lectura
Todo el mundo en la overlay Solcial p2p puede consultar, descargar y proporcionar cualquier contenido del usuario mediante la emisión de mensajes IWANT y IHAVE Bitswap al topic /solcial/content con CID del índice raíz de nivel superior de la cuenta, y luego recursivamente solicitar todos los CIDs vinculados.
La sincronización inicial de una cuenta, o la obtención de las entradas más recientes de la cuenta, se logra mediante la emisión de un mensaje HEAD al tema /solcial/sync, donde otros pares que son sembradores (incluyendo nodos beacon) responden con el CID del último contenido del que tienen conocimiento. La traducción entre los handles de los usuarios y las claves públicas de los usuarios se realiza consultando la blockchain de Solana.
El campo de entrada anterior se puede utilizar para resolver los HEADs conflictivos y decidir la entrada más reciente.
Acceso de lectura
Para poder escribir en el registro de una cuenta, el usuario debe poseer la clave privada del par de claves ED25519 que corresponde a su ID de cuenta. Al tener esa clave, el usuario puede generar una firma válida de una entrada que está añadiendo al registro que no será rechazada por otros pares en la red.
Acceso a contenidos privilegiados
Algunos de los contenidos publicados por los usuarios están destinados únicamente a un grupo selecto de destinatarios, como los canales de suscripción de nivel 1 o 2. Esas publicaciones se cifran primero con una clave de cifrado simétrica AES-256. El hash de esa clave se adjunta a los metadatos del contenido en la publicación original.
La clave se difunde a un subconjunto aleatorio de pares elegibles a través del canal cifrado NOISE establecido durante el handshake de libp2p. El autor de la entrada puede optar por permitir que los nodos beacon también participen en este esquema de intercambio de claves para que el proceso sea casi instantáneo para todos los usuarios, pero no tiene por qué hacerlo si cree que su contenido es súper sensible. Cuando un usuario elegible quiere descifrar el contenido, envía un mensaje GETKEY al tema superpuesto /solcial/keyexchange con el hash de la clave de cifrado.
Todos los pares en posesión de esa clave que estén en línea comprobarán la elegibilidad del par para obtener esa clave consultando la cadena de bloques y verificando si el usuario posee los tokens necesarios para acceder al contenido. Tras una verificación satisfactoria, la clave se transmite al par solicitante mediante una conexión directa quic/noise que evita el protocolo gossip.
Soporte de la plataforma
Este protocolo peer-to-peer para contenidos resistentes a la censura sólo está disponible para clientes de escritorio y móviles y no está disponible a través de la interfaz web. Esto se debe a las limitaciones de los navegadores. Los navegadores están diseñados intrínsecamente como consumidores de contenidos alojados en servidores y su modelo de seguridad prohíbe aceptar conexiones aleatorias de otras máquinas.
La versión web estará casi siempre centralizada debido a la forma en que funcionan los navegadores y a que el tiempo de vida de una pestaña del navegador es corto, y cualquier contenido producido a través de la interfaz web será reflejado en p2p por los nodos beacon. Cualquier contenido consumido por el cliente web será una copia del p2p. El p2p es la fuente de la verdad.
El stack técnico subyacente se implementa utilizando Rust, libp2p con enlaces a React Native y Tauri¹¹.
[1] Leitao, Joao, José Pereira, and Luis Rodrigues. “HyParView: A membership protocol for reliable gossip-based broadcast.”
[2] https://en.wikipedia.org/wiki/QUIC
[3] https://libp2p.io/
[4] https://www.google.com/intl/en/ipv6/statistics.html
[5] https://docs.libp2p.io/concepts/circuit-relay/
[6] https://datatracker.ietf.org/doc/html/rfc5766
[7] https://docs.libp2p.io/reference/glossary/#multihash
[8] Leitao, Joao, Jose Pereira, and Luis Rodrigues. “Epidemic broadcast trees.” 2007 26th IEEE International Symposium on Reliable Distributed Systems (SRDS 2007). IEEE, 2007.
[9] https://docs.ipfs.io/concepts/bitswap/
[10] https://github.com/ipld/ipld/blob/master/specs/codecs/dag-pb/spec.md
Acerca de Solcial
Solcial es una red social descentralizada que pretende dar a los usuarios el poder de la web3 permitiendo que los usuarios interactúen entre sí sin miedo a la censura, y permitiendo que los creadores de contenidos sean recompensados de forma justa a valor de mercado.
Contáctenos
Telegrama: https://t.me/solcial
Discord: https://discord.gg/solcial
Twitter: https://twitter.com/solcialofficial
Blog: http://blog.solcial.io/
Página web: https://solcial.io
Correo electrónico: [email protected]
Linktree: https://linktr.ee/solcial
