Sending Labs está a la vanguardia en la creación de una pila de protocolos de comunicación descentralizada que enfrenta directamente los problemas de centralización inherentes de TCP/IP. Esta iniciativa respalda la comunicación entre pares basada en billeteras, transformando fundamentalmente la infraestructura de Internet para elevar significativamente la seguridad, privacidad y empoderamiento del usuario.

Visión general del stack de protocolos TCP/IP de Web2

En la era Web2, la comunicación, la computación y el almacenamiento forman juntos la piedra angular de Internet. Entre ellos, la pila de protocolos TCP/IP es la forma más básica y amplia de comunicación en red. Se ejecuta a través de todos los niveles y proporciona un marco de comunicación unificado y estándar para todos los niveles, desde la capa física hasta la capa de aplicación. Casi todas las aplicaciones Web2 dependen directa o indirectamente de este sistema. Por lo tanto, la pila de protocolos TCP/IP se ha convertido en la base estandarizada para la comunicación en Internet.

Problemas con el Protocolo TCP/IP en la era Web2

Con la evolución de la tecnología de Internet, la pila de protocolos TCP/IP ha comenzado a revelar algunos problemas estructurales. Estas fallas acechan en nuestro uso diario de la web. El impacto de estos problemas se puede demostrar concretamente utilizando el ejemplo de dos usuarios que se comunican a través de una aplicación de chat. Supongamos que el usuario A envía un mensaje al usuario B. El mensaje se divide primero en varios paquetes de datos y luego se transmite al usuario B a través de varios servidores en Internet.

• En la capa de aplicación, cuando los usuarios acceden al sitio web de la aplicación, necesitan depender de DNS para resolver la dirección del servicio. Si el DNS está contaminado o es atacado, los usuarios pueden acceder por error a un servidor malicioso, lo que resulta en fugas de privacidad o manipulación de datos.
• En la capa de transporte, si la Autoridad de Certificación (CA) en la que se basa el protocolo SSL/TLS es atacada o pierde su confianza, las comunicaciones entre los usuarios pueden ser interceptadas o manipuladas por un tercero. Por ejemplo, si los mensajes de un usuario se transmiten a través de un canal no seguro, los hackers pueden interceptar estos paquetes o incluso falsificar información errónea. Al mismo tiempo, la dependencia de estas AC centralizadas conlleva riesgos de confianza.
• En la capa de red, debido a que las direcciones IP de los servicios de aplicación son controladas y asignadas por unas pocas organizaciones, la naturaleza limitada de las direcciones IP y el problema de la asignación centralizada conllevan a que los derechos de control de recursos estén mayormente concentrados en manos de unos pocos países y organizaciones, lo cual no solo resulta en una distribución injusta, sino que también hace que la arquitectura de toda la red sea vulnerable ante la amenaza del control centralizado.

La centralización inherente de TCP/IP conduce a problemas arraigados que no pueden resolverse con soluciones simples. Se requiere una transformación tecnológica radical para lograr la descentralización completa de la pila de protocolos, lo cual es crucial para abordar estos problemas fundamentales. Sending Labs está a la vanguardia de esta transformación, trabajando en una pila de protocolos de comunicación descentralizada. Este nuevo modelo reinventará TCP/IP al permitir la comunicación directa de igual a igual a través de direcciones de monedero, revolucionando la infraestructura de internet y mejorando significativamente la seguridad, privacidad y el control del usuario.

Construyendo un Nuevo Estándar de Comunicación en la Era Web3: Reconstruyendo la Pila de Protocolos TCP/IP

En la era de Web3, necesitamos reconstruir la pila de protocolos TCP/IP para resolver los problemas en el sistema actual. La versión Web3 de la pila de protocolos TCP/IP tendrá las siguientes características: En primer lugar, garantiza un suministro ilimitado de direcciones IP y evita el monopolio de recursos por parte de algunos países u organizaciones; en segundo lugar, transfiere la autenticación de confianza de la capa de transporte a un mecanismo descentralizado basado en la cadena de bloques. Ya no depende de una sola agencia de certificación de CA; en tercer lugar, transfiere protocolos clave como DNS a la cadena de bloques para eliminar la dependencia de los proveedores de servicios DNS tradicionales; además, fomenta que el público configure sus propios enrutadores para construir una infraestructura descentralizada de capa física; por último, se otorgan atributos financieros al terminal de comunicación de red para que esté directamente relacionado con el sistema de cuentas de la cadena de bloques y admita naturalmente funciones financieras.

Con la ayuda de esta nueva pila de protocolos, la forma de navegar por Internet cambiará drásticamente en el futuro: los usuarios abren un navegador, ingresan el nombre de dominio ENS, y el navegador analiza la dirección correspondiente a través de la cadena de bloques e inicia una solicitud de conexión. Antes de que se establezca la conexión, el sistema utiliza la firma digital del terminal y la autenticación del sistema DID basada en la cadena de bloques para confirmar las identidades de ambas partes que se comunican antes de establecer la conexión. Durante este proceso, todos los datos se procesan a través de un gran sistema de enrutamiento físico para garantizar que los datos se transmitan de un extremo a otro. En cuanto al pago, debido a que el terminal de comunicación tiene atributos financieros, los usuarios pueden pagar directamente a la dirección de billetera correspondiente de ENS, evitando el riesgo de fraude de phishing y garantizando un pago seguro y confiable. Ya sea en redes sociales, comercio electrónico u otras aplicaciones, heredarán las características de seguridad y descentralización de la capa de red y la capa de transporte.

A continuación, introduciremos en detalle cómo implementar estas características descentralizadas en la capa de red, capa de transporte, capa de aplicación y capa física.

Capa de red

El diseño de la capa de red debe cumplir con cuatro requisitos principales: primero, las direcciones IP deben ser suficientes para garantizar que el código de área de la dirección se distribuya de manera justa a nivel mundial; segundo, la dirección IP debe tener atributos financieros y poder asociarse directamente con la cuenta de blockchain; tercero, antes de hacer la transición completa a la red Web3, mantener la compatibilidad con IPv4/IPv6; cuarto, garantizar la descentralización de la resolución de nombres de dominio. Por esta razón, tenemos dos tipos principales de direcciones: direcciones unicast y direcciones anycast que incluyen:

• Dirección unicast: Es única y determinista. Está compuesta por varios IDs como el ID del segmento de red, el ID de la subred, el ID del host y el ID de la tarjeta de red. Puede determinar de forma única un dispositivo de tarjeta de red en la red. Realiza enrutamiento rápido basado en los prefijos de ID de segmentos de red y subredes para reducir la complejidad de la tabla de enrutamiento.
• Dirección anycast: Correspondiente a la dirección de la billetera, se pueden vincular múltiples direcciones unicast para lograr una transmisión eficiente de datos. Este diseño no solo optimiza la eficiencia del enrutamiento de la red, sino que también mejora en gran medida la capacidad de suministro de direcciones IP. Cuando el remitente inicia una solicitud de conexión a una dirección anycast, el enrutador envía el paquete a la dirección unicast más cercana vinculada a la dirección anycast en función de la distancia de enrutamiento. Debido a que los servicios proporcionados por todas las direcciones unicast vinculadas a la dirección anycast son iguales, el remitente puede satisfacer sus necesidades de comunicación comunicándose con cualquier dirección unicast.

Las direcciones unicast logran un enrutamiento rápido a través de prefijos de direcciones, y su longitud puede diseñarse para superar las direcciones de billetera de 160 bits, que teóricamente pueden suministrarse de forma ilimitada. La dirección anycast es equivalente a una dirección de billetera, lo que otorga atributos financieros a la dirección IP.

Entonces, ¿cómo implementar la asignación de direcciones unicast de manera descentralizada? En la era Web2, las direcciones IP son asignadas por autoridades centrales. En Web3, estas direcciones son asignadas a través de contratos inteligentes. El contrato inteligente genera diversos NFT de Licencia de ID de segmento de red basados en el tamaño de la red y autoriza a los operadores a gestionar subredes específicas. Los operadores que poseen IDs de segmento de red pueden subdividir subredes y venderlas a operadores de niveles inferiores o usuarios finales. Los operadores operan nodos de enrutador para procesar el tráfico de datos, lograr rentabilidad y garantizar una distribución justa y descentralizada de direcciones IP.

Resolución de nombres de dominio - protocolo DNS, aunque esté definido en la capa de aplicación en Web3, lógicamente es más similar a un protocolo para nombrar terminales de transmisión de red en la capa de red. Lo consideramos aquí como un protocolo de capa de red, que puede ser reutilizado por otros protocolos de capa de aplicación. DNS debería ser un protocolo de resolución en cadena en Web3, y la implementación debería ser algo similar a ENS. El contrato en cadena define la relación correspondiente entre el nombre de dominio y la dirección de billetera, logrando así la dependencia de la organización del nombre de dominio DNS y eliminando la dependencia del centro, evitando así el problema de contaminación de DNS.

Para garantizar que la red pueda operar normalmente y resolver el problema de arranque en frío antes de que esté completamente escalado, necesitamos hacer que la red sea compatible con IPv4/IPv6 existente. Cuando un enrutador no puede encontrar la dirección de destino en su red conectada directamente, encapsulará los datos en paquetes IPv4/IPv6 y los enviará a enrutadores en otros subredes. El enrutador receptor analiza estos paquetes y continúa el enrutamiento dentro de la subred hasta que se encuentre la dirección de destino. Este proceso es similar a las primeras etapas de IPv6 logrando compatibilidad a través de túneles en la red IPv4.

Además, el enrutador también es responsable de la penetración de la intranet. Cuando los datos necesitan ingresar a la intranet a través de la puerta de enlace IPv4, el dispositivo de enrutamiento de red pública reenviará estas conexiones. Estos dispositivos actúan como proxies inversos para la intranet, permitiendo que los datos ingresen de forma segura a la dirección de la intranet a través del túnel.

Para realizar estas transformaciones en la capa de red, se deben realizar mejoras correspondientes en la capa física y la capa de transporte. La capa física requiere equipo de enrutador suficiente, y al mismo tiempo anima a los usuarios finales, proveedores de servicios de fibra u operadores actuales de ISP a comprar estos equipos para formar un efecto de red y reemplazar gradualmente la red IP existente. En la capa de transporte, necesitamos más mejoras para verificar la unión de direcciones de anycast y unicast y garantizar la seguridad y la imposibilidad de falsificación de las comunicaciones.

Capa de transporte

Al garantizar la transmisión segura de datos, la capa de transporte elimina la confianza en la CA y elimina la necesidad de depender de cualquier organización centralizada para el proceso de certificación de seguridad.

Normalmente, garantizar la seguridad de las conexiones a Internet (como los sitios web que utilizan HTTPS) se basa en los protocolos SSL/TLS, que dependen de las autoridades de certificación para verificar la autenticidad de los sitios web visitados. Esperamos adoptar documentos DID basados en cadena para mantener la seguridad y eliminar la dependencia de entidades centralizadas.

Este proceso de autenticación mutua se realiza accediendo al documento DID en la cadena. Dado que las direcciones anycast de ambas partes ya están registradas en la cadena de bloques y vinculadas a sus direcciones de billetera, los servicios de DNS requeridos por las AC tradicionales ya no son necesarios. Una vez que se encuentran y asocian el documento DID y la dirección de billetera, y la parte correspondiente proporciona una firma válida, se puede confirmar que la entidad con la que está comunicando es el propietario legal del identificador.

De esta manera, se establece una conexión de monedero a monedero, lo que permite una transmisión de datos conveniente a través de sockets. Similar a cómo SSL/TLS opera en un entorno de socket específico, este sistema proporciona una nueva opción para estas conexiones.

Ejemplo de Socket

Hemos propuesto algunas formas de reconstruir la capa de red y la capa de transporte, el siguiente código de socket es un ejemplo. Cada nivel aborda sus desafíos específicos. Sobre esta base, debido a que la dirección de la billetera tiene funciones financieras, una función que las direcciones IP ordinarias no tienen, podemos usar el código de socket para establecer una conexión y luego enviar instrucciones de transacción a través de él.

Por lo tanto, esta nueva pila de tecnología TCP/IP integra las características de SSL/TLS, enrutamiento IP y transacciones financieras. A continuación se muestra un código de muestra corto.

Capa de aplicación

Hay muchos protocolos de capa de aplicación en la pila de protocolos TCP/IP. Algunos comunes incluyen HTTP(S), XMPP, SMTP, POP3, FTP, SIP, RTMP, CDN, etc. Estos protocolos tradicionalmente han dependido de servidores centralizados, como XMPP para servidores de mensajería instantánea y SMTP para servidores de correo. Sin embargo, en la era Web3, los nodos de red descentralizados reemplazarán a los servidores centrales tradicionales, y los protocolos de capa de aplicación ya no se preocuparán por el servidor de aplicación. Además de definir el formato de paquete de datos en la capa de transporte/capa de red, estos protocolos se basan en la infraestructura de red descentralizada de la capa de red, lo que permite que la capa de red proporcione una red descentralizada sólida para diversas aplicaciones. Base.

Entre todos los protocolos de capa de aplicación, HTTPS, XMPP, SMTP, etc. son los más comunes, y constituyen la base de nuestras actividades sociales diarias. Bajo la arquitectura de Web3, desarrollamos el primer ejemplo de aplicación, un protocolo de aplicación social de mensajería instantánea descentralizada utilizando un protocolo similar a XMPP. En este protocolo, los usuarios utilizan sus direcciones de billetera como cuentas sociales para llevar a cabo chats cifrados de extremo a extremo, establecer grupos de chat privados o públicos, enviar mensajes de voz y video, e incluso realizar llamadas de audio y video. Estos reutilizan las capacidades de comunicación segura de la capa de transporte y la extensa red de nodos de la capa de red, utilizando la dirección de billetera como una nueva identidad de red.

Además de los protocolos de mensajería instantánea similares a XMPP que ofrecemos, la capa de aplicación también tiene una gran cantidad de escenarios de aplicación, como:

• Aplicaciones web basadas en HTTP y HTTPS: los desarrolladores pueden simplemente implementar su sitio web en una red basada en la dirección de billetera/nombre de dominio ENS, disfrutar del acceso de alta velocidad proporcionado por el intercambio de ancho de banda de la red, mientras se aseguran la resistencia a la censura de la aplicación y el acceso seguro.
• Las aplicaciones de correo como SMTP/POP3: Al depender de esta red, los sistemas de correo descentralizados se volverán fáciles. Cuando necesite enviar un correo electrónico a un propietario de un nombre de dominio ENS, su aplicación solo necesita encontrar el nodo correspondiente a la dirección ENS a través del direccionamiento de la capa de red, cargar el correo electrónico y el destinatario puede descargar el correo electrónico desde el nodo.
• Aplicación del protocolo de distribución de recursos de CDN: Confiando en esta red, los desarrolladores pueden distribuir sus datos a nodos en dispositivos de enrutador principales o centros de datos. La enorme red de nodos construida sobre la base del mecanismo de incentivos permitirá que los nodos se dispersen casi por todo el mundo, en profundidad. En cada hogar, la vasta red de nodos permite que el protocolo de CDN utilice eficientemente los recursos de ancho de banda inactivos, lo que permite a los desarrolladores y usuarios disfrutar de una experiencia de aplicación de mayor velocidad.
• Aplicación de protocolos de transmisión de medios como SIP/RTMP/WebRTC: Confiando en el extenso recurso de nodos y el intercambio de ancho de banda inactivo, las aplicaciones de transmisión de medios pueden realizar almacenamiento distribuido y almacenamiento en caché de contenido de medios de transmisión para acelerar el acceso y mejorar la velocidad de acceso y la fluidez de los medios de transmisión.
• Aplicación de protocolos de transferencia y acceso de archivos como FTP: A través de una gran red de nodos, combinada con el proyecto de almacenamiento descentralizado web3, la red puede almacenar en caché activamente los recursos de contenido de proyectos como IPFS/Arweave, acelerar el acceso frecuente al contenido y mejorar la actividad y aplicación del alcance del proyecto.
• Aplicación de protocolos VPN como OpenVPN: Las aplicaciones de VPN pueden utilizar racionalmente los recursos IP compartidos por los dispositivos de enrutamiento, ampliar en gran medida el rango de recursos IP de las aplicaciones y proporcionar los recursos IP y de ancho de banda más básicos para VPN.
• Protocolos de cola de mensajes como Kafka y RabitMQ: Las colas de mensajes son protocolos de capa de aplicación ampliamente utilizados en aplicaciones distribuidas y de clúster. Un gran número de aplicaciones requieren de ellos para implementar la comunicación entre módulos o procesos de aplicación. En la era web3, estas aplicaciones pueden depender de una extensa red de nodos y utilizar estos nodos como transportadores naturales de colas de mensajes para proporcionar servicios compartidos y de alta velocidad de colas de mensajes para una amplia gama de aplicaciones.

Capa física

La idea principal de la capa física es promover enrutadores descentralizados a través de incentivos para que sean ampliamente adoptados por los hogares y generen efectos de red. Estos enrutadores permiten a los usuarios utilizar el ancho de banda doméstico no utilizado para aumentar la capacidad de la red en general. Al integrarse con nuestros protocolos de capa de red, estos dispositivos mejoran el almacenamiento en caché de datos y las capacidades de aceleración para beneficiar a las aplicaciones descentralizadas dentro del ecosistema. Estos dispositivos optimizan el uso del ancho de banda y permiten a los usuarios obtener ingresos de sus contribuciones de ancho de banda.

En la etapa inicial, podemos establecer un enlace de transmisión directamente al terminal de comunicación a través de un túnel IPv4 basado en la arquitectura IPv4. A medida que los nodos se vuelvan más populares, atraeremos a más proveedores de servicios de fibra óptica para unirse a través de incentivos y lograr la interconexión completa de nuestra red de hardware en la capa física.

Conclusión

El impacto de reconstruir la pila de protocolos TCP/IP irá mucho más allá de los cambios técnicos. Al integrar enrutamiento basado en la dirección de la billetera, resolución de nombres de dominio y autenticación directamente en los protocolos centrales de Internet, estamos construyendo activamente la base de una web descentralizada. Tomando la comunicación descentralizada de mensajería instantánea como nuestro protocolo de capa de aplicación inicial, en el futuro se formará un ecosistema descentralizado que integra mensajería, transacciones financieras y gestión de activos digitales. Se espera que este cambio mejore significativamente la privacidad, seguridad y libertad en línea, marcando un paso clave hacia la consecución de un internet abierto.

Como se mencionó anteriormente, SendingNetwork ha lanzado un protocolo de mensajería descentralizado como el primer protocolo de capa de aplicación en nuestra pila de protocolos descentralizados. Los usuarios pueden usar su dirección de billetera para enviar mensajes cifrados de extremo a extremo, participar en chats privados o públicos, y hacer llamadas de voz y video. La red está compuesta por los siguientes tres roles:

• Nodo de borde: Responsable de reenviar, relé de mensajes y presentar prueba de trabajo.
• Nodo WatchDog: Envía mensajes de desafío aleatorios al nodo Edge para detectar su estado de funcionamiento.
• Nodo guardián: Verificar la prueba de trabajo del nodo Edge y evaluar su calidad de servicio como estabilidad basada en los resultados del desafío de WatchDog.

La red utiliza Prueba de Retransmisión como prueba de trabajo para la retransmisión de mensajes, y utiliza Prueba de Disponibilidad para evaluar la calidad del servicio del nodo. Actualmente, hemos abierto la primera fase de la red de prueba, en la que los nodos Edge pueden ganar puntos mediante el reenvío de mensajes. A continuación, agregaremos gradualmente los roles de WatchDog y Guardian a la red para asegurarnos de que la red pueda operar de manera estable en un entorno descentralizado.

Invitamos a desarrolladores y usuarios a unirse a esta red de mensajería y ayudar a los usuarios de Web3 a interconectarse entre diferentes aplicaciones a través de este protocolo multiplataforma. Al mismo tiempo, también invitamos a más amigos con ideas afines a unirse a nosotros para presenciar la transformación de TCP/IP, realmente realizar la interconexión del ecosistema Web3, crear un mundo en línea más seguro, privado y descentralizado, y remodelar la infraestructura de comunicaciones del futuro digital.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [GateChaincatcher], Todos los derechos de autor pertenecen al autor original [Industry Express]. If there are objections to this reprint, please contact theGate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.