Sending Labs знаходиться на передньому краї вишкріллю децентралізованого стеку протоколів зв'язку, що безпосередньо протистоять вродженим централізаційним проблемам TCP/IP. Ця ініціатива підтримує комунікацію між пірами на основі гаманців, що фундаментально перетворює інтернет-інфраструктуру для значного підвищення безпеки, конфіденційності та емповерменту користувачів.

Огляд TCP/IP-стеку протоколів Web2

У епосі Web2 комунікація, обчислення та зберігання разом утворюють основу Інтернету. Серед них стек протоколів TCP/IP є найбільш базовою і широкою формою мережевої комунікації. Він працює на всіх рівнях і надає єдину комунікаційну структуру та стандарт для всіх рівнів від фізичного до застосування. Майже всі програми Web2 залежать безпосередньо чи опосередковано від цієї системи. Тому стек протоколів TCP/IP став стандартизованою основою для Інтернет-комунікації.

Проблеми з протоколом TCP/IP в епоху веб2

З розвитком технологій Інтернету стек протоколів TCP/IP почав виявляти деякі структурні проблеми. Ці дефекти чатують в нашому щоденному веб-використанні. Вплив цих проблем можна конкретно продемонструвати на прикладі двох користувачів, які спілкуються через додаток для чатування. Припустимо, що користувач A надсилає повідомлення користувачу B. Повідомлення спочатку розбивається на кілька пакетів даних, а потім передається користувачу B через кілька серверів в Інтернеті.

• На рівні додатка, коли користувачі отримують доступ до веб-сайту додатка, їм потрібно покладатися на DNS для вирішення адреси служби. Якщо DNS забруднений або атакований, користувачі можуть помилково отримати доступ до зловмисного сервера, що призводить до витоку конфіденційності або зміни даних.
• На рівні транспортного рівня, якщо уповноважений орган (CA), на якому ґрунтується протокол SSL/TLS, піддається атакам або втрачає довіру, комунікація між користувачами може підслуховуватися або підроблятися третьою стороною. Наприклад, якщо повідомлення користувача передаються через ненадійний канал, хакери можуть перехопити ці пакети або навіть підробити недостовірну інформацію. Тим часом, залежність від централізованих CA приносить ризики довіри.
• На мережевому рівні, оскільки IP-адреси служб додатків контролюються та розподіляються кількома організаціями, обмежена природа IP-адрес та проблема централізованого розподілу призводить до того, що права контролю ресурсів в основному концентруються в руках кількох країн та організацій, що призводить не лише до несправедливого розподілу, але й робить всю мережеву архітектуру вразливою перед загрозою централізованого контролю.

Внутрішня централізація TCP/IP призводить до глибоко закорінених проблем, які не можуть бути вирішені простими виправленнями. Радикальний технологічний переворот необхідний для досягнення повної децентралізації стеку протоколів, що є важливим для вирішення цих фундаментальних проблем. Sending Labs перебуває на передньому краї цієї трансформації, працюючи над децентралізованим стеком протоколів зв'язку. Ця нова модель перевершить TCP/IP, дозволяючи пряме взаємодію між рівнями через адреси гаманця, революціонізуючи інтернет-інфраструктуру та значно покращуючи безпеку, конфіденційність та контроль користувача.

Створення нового стандарту зв'язку в епоху Web3: Перебудова стеку протоколів TCP/IP

В епоху Web3 нам потрібно реконструювати стек протоколів TCP/IP, щоб вирішити проблеми в поточній системі. Web3-версія стека протоколів TCP/IP матиме такі характеристики: по-перше, це забезпечує необмежену пропозицію IP-адрес та дозволяє уникнути монополії ресурсів кількома країнами чи організаціями; По-друге, він передає аутентифікацію довіри транспортного рівня до децентралізованого механізму, заснованого на блокчейні. Більше не покладайтеся на одне сертифікаційне агентство ЦА; по-третє, перенести ключові протоколи, такі як DNS, в блокчейн, щоб позбутися залежності від традиційних постачальників послуг DNS; Крім того, заохочувати громадськість налаштовувати власні маршрутизатори для створення децентралізованої інфраструктури фізичного рівня; Нарешті, мережевий комунікаційний термінал отримує фінансові атрибути, щоб він був безпосередньо пов'язаний з системою блокчейн-рахунків і, природно, підтримував фінансові функції.

За допомогою цього нового стека протоколів у майбутньому буде сильно змінено спосіб серфінгу в Інтернеті: користувачі відкривають браузер, вводять доменне ім'я ENS, а браузер парсить відповідну адресу через блокчейн та ініціює запит на підключення. Перед встановленням з'єднання система використовує цифровий підпис терміналу та аутентифікацію системи DID на основі блокчейну, щоб підтвердити особи обох сторін, що спілкуються, перед встановленням з'єднання. Під час цього процесу всі дані обробляються через величезну фізичну систему маршрутизації, щоб гарантувати, що дані передаються з одного кінця в інший. Коли справа доходить до оплати, оскільки термінал зв'язку має фінансові атрибути, користувачі можуть платити безпосередньо на відповідну адресу гаманця ENS, уникаючи ризику фішингового шахрайства та забезпечуючи безпечну та надійну оплату. Будь то соціальні мережі, електронна комерція чи інші програми, вони успадкують функції безпеки та децентралізації мережевого та транспортного рівня.

Далі ми детально розглянемо, як реалізувати ці децентралізовані функції на мережевому рівні, транспортному рівні, рівні додатків та фізичному рівні.

Мережевий рівень

Дизайн мережевого рівня повинен відповідати чотирьом основним вимогам: по-перше, IP-адреси повинні бути достатніми, щоб забезпечити рівномірне розподіл коду області адреси глобально; по-друге, IP-адреса повинні мати фінансові атрибути і можуть бути безпосередньо пов'язані з обліковим записом блокчейну; по-третє, перед повністю переходити на мережу Web3, підтримувати сумісність з IPv4/IPv6; по-четверте, забезпечити децентралізацію розв'язання доменних імен. З цієї причини у нас є два основних типи адрес: унікастні адреси та анікастні адреси, включаючи:

• Унікаст-адреса: вона є унікальною та детермінованою. Вона складається з кількох ідентифікаторів, таких як ідентифікатор сегмента мережі, ідентифікатор підмережі, ідентифікатор хоста та ідентифікатор мережевої карти. Вона може унікально визначити пристрій мережевої карти в мережі. Виконувати швидке маршрутизування на основі префіксів ідентифікаторів сегментів мережі та підмереж для зменшення складності таблиці маршрутизації.
• Адреса Anycast: Відповідно до адреси гаманця, до неї можна прив'язати кілька адрес unicast для досягнення ефективної передачі даних. Цей дизайн не тільки оптимізує ефективність маршрутизації мережі, але й значно підвищує потужність постачання адрес IP. Коли відправник ініціює запит на підключення до адреси Anycast, маршрутизатор відправляє пакет на найближчу адресу unicast, прив'язану до адреси Anycast, на основі маршрутної відстані. Оскільки послуги, які надаються всіма адресами unicast, прив'язаними до адреси Anycast, однакові, відправник може задовольнити свої комунікаційні потреби, спілкуючись з будь-якою адресою unicast.

Одноадресні адреси досягають швидкого маршрутизації через префікси адрес, і їхня довжина може бути розроблена так, щоб перевищувати 160-бітові адреси гаманців, які теоретично можуть бути постачані необмежено. Адреса Anycast еквівалентна адресі гаманця, яка надає фінансові атрибути IP-адресі.

Так як реалізувати виділення адрес для одиночного доступу у децентралізований спосіб? У епоху Web2 IP-адреси надаються центральними органами. У Web3 ці адреси виділяються за допомогою розумних контрактів. Розумний контракт генерує різні ідентифікатори ліцензій NFT мережевих сегментів на основі розміру мережі та авторизує операторів керувати конкретними підмережами. Оператори, що утримують ідентифікатори мережевих сегментів, можуть підрозділити підмережі та продавати їх операторам нижнього рівня або кінцевим користувачам. Оператори керують вузлами маршрутизаторів для обробки даних, досягають прибутковості та забезпечують справедливий та децентралізований розподіл IP-адрес.

Протокол розподілу доменних імен - протокол DNS, хоча визначений на рівні застосунку в Web3, логічно більше схожий на протокол для найменування мережевих кінцевих точок передачі даних на рівні мережі. Ми вважаємо його тут протоколом рівня мережі, який може бути використаний іншими протоколами рівня застосунку. DNS повинен бути протоколом розподілу на ланцюжку в Web3, а реалізація повинна бути щось на зразок ENS. Контракт на ланцюжку визначає відповідний зв'язок між доменним ім'ям та гаманцем, тим самим реалізовуючи залежність від організації доменного імені DNS та усуваючи залежність від центру, тим самим уникнувши проблеми з забрудненням DNS.

Для забезпечення нормальної роботи мережі та вирішення проблеми холодного запуску до повного масштабування потрібно зробити мережу сумісною з існуючими IPv4/IPv6. Коли маршрутизатор не може знайти адресу призначення в своїй безпосередньо підключеній мережі, він інкапсулює дані в пакети IPv4/IPv6 та відправляє їх на маршрутизатори в інших підмережах. Приймаючий маршрутизатор розбирає ці пакети та продовжує маршрутизацію в межах підмережі, поки не буде знайдено адресу призначення. Цей процес схожий на початкові етапи досягнення IPv6 сумісності через тунелі в мережі IPv4.

Крім того, маршрутизатор також відповідає за проникнення внутрішньої мережі. Коли дані потрібно ввести внутрішній мережі через шлюз IPv4, пристрій маршрутизації публічної мережі буде пересилати ці з'єднання. Ці пристрої діють як зворотні проксі для внутрішньої мережі, дозволяючи даним безпечно ввійти в адресу внутрішньої мережі через тунель.

Для реалізації цих трансформацій на мережевому рівні необхідно внести відповідні покращення на фізичному та транспортному рівнях. Фізичний рівень потребує достатнього обладнання маршрутизаторів, а також стимулює кінцевих користувачів, постачальників оптоволоконних послуг або поточних операторів постачання послуг Інтернету придбати це обладнання для створення мережевого ефекту та поступово замінити існуючу IP мережу. На рівні транспорту необхідно провести подальші покращення для перевірки зв'язку адрес anycast та unicast та забезпечення безпеки та непідробленості зв'язку.

Транспортний рівень

Забезпечуючи безпечну передачу даних, транспортний рівень виключає довіру до ЦС та усуває необхідність покладатися на будь-яку централізовану організацію для процесу сертифікації безпеки.

Зазвичай забезпечення безпеки Інтернет-з'єднань (таких як веб-сайти, що використовують HTTPS) ґрунтується на протоколах SSL/TLS, які стикаються з необхідністю підтвердження автентичності відвідуваних веб-сайтів відповідно до вимог відповідних органів сертифікації. Ми сподіваємося використовувати документи DID, засновані на ланцюгах, для збереження безпеки, при цьому уникнувши залежності від централізованих сутностей.

Цей процес взаємної аутентифікації виконується шляхом доступу до документа DID на ланцюжку. Оскільки anycast-адреси обох сторін вже зареєстровані в блокчейні та пов'язані з їхніми адресами гаманців, DNS-служби, які потрібні традиційним СА, більше не потрібні. Як тільки буде знайдено та пов'язано документ DID та адресу гаманця, і відповідна сторона надасть дійсний підпис, ви можете підтвердити, що сутність, з якою ви спілкуєтеся, є законним власником ідентифікатора.

Таким чином встановлюється підключення від гаманця до гаманця, що дозволяє зручну передачу даних через сокети. Схоже на те, як SSL/TLS працює в конкретному середовищі сокету, ця система надає нову опцію для цих з'єднань.

Приклад сокету

Ми запропонували кілька способів реконструкції мережевого та транспортного рівнів, наведений нижче код сокету - це приклад. Кожен рівень вирішує свої конкретні виклики. На цій основі, оскільки адреса гаманця має фінансові функції - функцію, якої звичайні IP-адреси не мають - ми можемо використовувати код сокету для встановлення з'єднання, а потім відправляти інструкції по транзакціям через нього.

Отже, цей новий стек технології TCP/IP інтегрує функції SSL/TLS, маршрутизацію IP та фінансові транзакції. Нижче наведено короткий зразок коду.

Рівень додатків

У стеку протоколів TCP/IP є багато протоколів прикладного рівня. До поширених належать HTTP(S), XMPP, SMTP, POP3, FTP, SIP, RTMP, CDN тощо. Ці протоколи традиційно покладалися на централізовані сервери, такі як XMPP для серверів обміну миттєвими повідомленнями та SMTP для поштових серверів. Однак в епоху Web3 децентралізовані мережеві вузли замінять традиційні центральні сервери, а протоколи прикладного рівня більше не дбають про сервер додатків. На додаток до визначення формату пакетів даних на транспортному рівні/мережевому рівні, ці протоколи засновані на децентралізованій мережевій інфраструктурі мережевого рівня, що дозволяє мережевому рівню забезпечувати надійну децентралізовану мережу для різних додатків. База.

Серед усіх протоколів рівня застосунків HTTPS, XMPP, SMTP тощо є найбільш поширеними і становлять основу наших щоденних соціальних дій. У рамках архітектури Web3 ми розробили перший приклад застосунку - децентралізований протокол соціальних миттєвих повідомлень, що використовує протокол, схожий на XMPP. У цьому протоколі користувачі використовують свої адреси гаманця як соціальні облікові записи для проведення шифрованих чатів з кінця в кінець, створення приватних або групових чатів, надсилання голосових та відео повідомлень, а також навіть здійснення аудіо- та відеовикликів. Ці функції використовують можливості безпечного зв'язку транспортного рівня та обширну мережу вузлів мережевого рівня, використовуючи адресу гаманця як новий мережевий ідентифікатор.

Крім протоколів миттєвого обміну повідомленнями, схожих на XMPP, які ми надаємо, на рівні застосунку також існує велика кількість сценаріїв застосування, таких як:

• Веб-додатки на основі HTTP і HTTPS: Розробники можуть просто розгортати свій веб-сайт в мережі на основі адреси гаманця/доменного імені ENS, насолоджуючись швидким доступом, який забезпечується спільним використанням пропускної здатності мережі, забезпечуючи при цьому опір цензурі застосунків та безпечний доступ.
• Поштові програми, такі як SMTP/POP3: Розраховуючи на цю мережу, децентралізовані поштові системи стануть простими. Коли вам потрібно надіслати електронного листа власнику доменного імені ENS, вашій програмі лише потрібно знайти вузол, що відповідає адресі ENS через мережевий шар адресації, завантажити електронний лист, і одержувач може завантажити електронний лист з вузла.
• Застосування протоколу розподілу ресурсів CDN: Завдяки цій мережі розробники можуть розподіляти свої дані на вузли в основних маршрутизаторах або центрах обробки даних. Велика мережа вузлів, побудована на основі стимулюючого механізму, дозволить розподілити вузли майже по всьому світу, в глибині кожного будинку. Велика мережа вузлів дозволяє протоколу CDN ефективно використовувати вільні ресурси пропускної здатності, що дозволяє розробникам і користувачам насолоджуватися вищою швидкістю застосування.
• Застосування протоколів стрімінгових медіа, таких як SIP/RTMP/WebRTC: Залежно від обширних ресурсів вузлів та спільного використання простою пропускною здатністю, додатки стрімінгового медіа можуть реалізувати розподілене зберігання та кешування вмісту стрімінгових медіа для прискорення доступу та покращення швидкості та плавності стрімінгових медіа.
• Застосування протоколів передачі файлів та доступу, таких як FTP: через велику мережу вузлів, поєднану з проектом децентралізованого зберігання web3, мережа може активно кешувати ресурси вмісту проектів, таких як IPFS/Arweave, прискорювати часто використовуваний вміст та покращувати активність та застосування обсягу проекту.
• Застосування протоколів VPN, таких як OpenVPN: додатки VPN можуть раціонально використовувати IP-ресурси, які діляться маршрутизаційними пристроями, значно розширюючи діапазон IP-ресурсів додатків та надаючи найбільш базові IP та пропускні здатності для VPN.
• Протоколи черги повідомлень, такі як Kafka та RabitMQ: Протоколи черги повідомлень є широко використовуваними на рівні додатків у розподілених та кластерних додатках. Велика кількість додатків потребують їх для здійснення комунікації між модулями або процесами додатків. У епоху web3 ці додатки можуть покладатися на велику мережу вузлів та використовувати ці вузли як природних носіїв черги повідомлень, щоб надавати спільні, високошвидкісні послуги черги повідомлень для широкого спектру додатків.

Фізичний рівень

Основна ідея фізичного рівня полягає в тому, щоб просувати децентралізовані роутери за допомогою стимулів, щоб вони могли бути широко прийняті домогосподарствами і нарешті генерувати мережеві ефекти. Ці роутери дозволяють користувачам використовувати невикористану домашню пропускну здатність для збільшення загальної мережевої потужності. Інтегруючись з нашими протоколами мережевого рівня, ці пристрої підвищують можливості кешування даних та прискорення для користі із децентралізованих додатків у межах екосистеми. Ці пристрої оптимізують використання пропускної здатності та дозволяють користувачам заробляти дохід від їх внесків у пропускну здатність.

На початковому етапі ми можемо встановити трансмісійний канал безпосередньо до комунікаційного терміналу через тунель IPv4 на основі архітектури IPv4. По мірі популярності вузлів ми подальше залучатимемо більше постачальників оптичних волоконних послуг для приєднання за допомогою стимулів для досягнення повної взаємодії нашої апаратної мережі на фізичному рівні.

Висновок

Вплив перебудови стеку протоколів TCP/IP вийде далеко за межі технічних змін. Інтегруючи маршрутизацію на основі адрес гаманця, вирішення доменних імен та аутентифікацію безпосередньо в основні протоколи Інтернету, ми активно будуємо фундамент децентралізованої мережі. Беручи децентралізовану миттєву комунікацію як наш початковий протокол на рівні застосування, у майбутньому буде сформовано децентралізований екосистему, що інтегрує повідомлення, фінансові транзакції та управління цифровими активами. Цей зсув очікується значно покращити онлайн-приватність, безпеку та свободу, відзначаючи ключовий крок у досягненні відкритого Інтернету.

Як вже зазначалося, SendingNetwork запустив децентралізований протокол обміну повідомленнями як перший протокол рівня додатків у нашому стеку децентралізованих протоколів. Користувачі можуть використовувати свою адресу гаманця для відправлення кінцевим-кінцем зашифрованих повідомлень, брати участь у приватних або загальнодоступних чатах, а також проводити голосові та відеовиклики. Мережа складається з наступних трьох ролей:

• Вузол краю: Відповідальний за пересилання, передачу повідомлень та надання доказу роботи.
• Вічний вузол: Надсилання випадкових викликів до вузла Edge для виявлення його робочого стану.
• Вартовий вузол: Перевірте доказ роботи вузла Edge та оцініть якість його обслуговування, таку як стабільність, на основі результатів виклику WatchDog.

Мережа використовує доказ проходження як доказ роботи для релею повідомлень, та використовує доказ доступності для оцінки якості обслуговування вузла. Наразі ми відкрили першу фазу тестової мережі, в якій крайові вузли можуть заробляти бали через пересилання повідомлень. Далі ми поступово додамо ролі Сторожового пса та Сторожа до мережі, щоб забезпечити стабільну роботу мережі в децентралізованому середовищі.

Ми запрошуємо розробників та користувачів приєднатися до цієї мережі обміну повідомленнями та допомогти користувачам Web3 взаємодіяти між різними додатками за допомогою цього крос-платформеного протоколу. Водночас ми також запрошуємо більше однодумців приєднатися до нас, щоб свідчити про перетворення TCP/IP, дійсно реалізувати взаємодію екосистеми Web3, створити більш безпечний, приватний та децентралізований онлайн-світ і перетворити інфраструктуру цифрового майбутнього в область комунікацій.

Disclaimer：

1. Ця стаття перепечатана з [ Ланцюжок], Усі авторські права належать оригінальному автору [Індустрія експрес]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з Гейт Навчитисякоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.