Мережевий соціальний одноранговий протокол
TLDR:
- Solcial розробляється, щоб надати користувачам досвід, максимально наближений до платформ соціальних медіа Web2, використовуючи переваги технологій Web3.
- Однією з перешкод, з якою стикається будь-яка платформа на основі блокчейну, є плата за користування. Щоб усунути плату користувачів за операції, не пов’язані з токенами, зберігаючи конфіденційність і консенсус, Solcial створює одноранговий рівень (P2P), прив’язаний до Solana і побудований на основі libp2p, який реалізує контент (пости, лайки тощо) за допомогою самостійного хостингу та однорангової реплікації.
- Ми також розробили особливий тип вузла, який має такий же зовнішній протокол, як і звичайний настільний або мобільний додаток, із доданими оптимізаціями, призначеними для роботи з десятками тисяч одночасних однорангових вузлів, які називаються Beacon Nodes (далі в тексті - маяки). Маяки — це, по суті, набір пінінгових (сигнальних) служб, які зберігатимуть вміст користувачів, коли автори виходять із мережі, і роблять його доступним для інших користувачів; весь вміст користувача зберігається на IPFS і доступ до нього здійснюється через рівень P2P, не покладаючись на сервери з цензурою або шлюзи.
Вступ
Це перша публікація у серії приміток, які описують, як внутрішня робота протоколу Solcial надає йому унікальні властивості та стійкість до цензури, зберігаючи при цьому розумну продуктивність обміну даними.
Топологія мережі
Вузли спілкуються через загальнодоступний Інтернет, утворюючи оверлейну мережу, специфічну для Solcial, використовуючи модифіковану версію протоколу HyparView¹.
Кожен вузол підтримує список активних однорангових вузлів розміром log 2(N)+1, де N - передбачуваний розмір всієї мережі. Значення N витягується з блокчейну, знаходячи кількість облікових записів користувачів, зареєстрованих на даний момент, і періодично оновлюється в міру зростання кількості користувачів. З’єднання з активними пірами є стабільними, двонаправленими та постійними, і це вузли, з якими вони взаємодіють безпосередньо під час контактів або будь-якої іншої діяльності P2P. Кожен вузол також підтримує список пасивних однорангових елементів розміром 6⋅(log2(N)+1), які використовуються як резервні однорангові пристрої на випадок, якщо будь-який з активних однорангових вузлів відключається або не відповідає. Основним протоколом для з'єднань між активними одноранговими є QUIC² із шифруванням NOISE, який працює на базі libp2p³.
Обхід NAT (NAT Traversal (NAT-T) - протокол, який інкапсулює трафік VPN-з'єднання, що працює за такими протоколами як IPSec або PPTP, створюючи пакети UDP.) досягається за допомогою трьох методів, які використовуються залежно від мережевих обставин піра. Перший метод використовує IPv6 замість IPv4, коли це можливо, тому що в цьому випадку немає потреби в NAT, однак за статистикою лише менше 40% Інтернету перебуває на IPv6⁴.
Резервний механізм полягає у використанні AutoNAT за допомогою протоколу ідентифікації libp2p, який запитує інші вузли мережі про видиму адресу нашої машини. Ця адреса, ініційована піром після NAT, вже зареєстрована їх маршрутизатором на цільовій машині, однак існують обставини, коли це не працює, тоді ми повертаємося до третього і найнадійнішого, але дорогого варіанту.
Третій варіант полягає у використанні протоколу ретрансляції ланцюга libp2p⁵, який імітує роботу протоколу TURN⁶, маючи проміжний вузол, який передає пакети між двома пірами за NAT. Цю роль можуть взяти на себе вузли-маяки та деякі піри з загальнодоступними IP-адресами, які вибирають бути ретрансляторами із налаштованими обмеженнями. Докладніше про вузли-маяки пізніше в цій публікації.
Ідентичність пірів
Піри ідентифікуються за допомогою їхнього відкритого ключа у вигляді мультихешу⁷, який дорівнює відкритому ключу їхньої адреси гаманця на Solana, який зареєстрований у контракті соціального ланцюга. Єдиний спосіб прийняти даний загальнодоступний ідентифікатор піру - це володіти секретним ключем пари ключів ED25519.
Ця пара ключів також використовується для встановлення зашифрованих каналів для всіх повідомлень, що передаються між пірами, а також для способу перевірки автентичності повідомлень, які ймовірно створює власник гаманця.
Overlay членство
Піру із відкритими ключами, не зареєстрованими в ланцюжку, не буде дозволено приєднатися до оверлею мережі HyparView і, відповідно, автоматично виключені з однорангової мережі Solcial.
Усі піри, які бажають приєднатися до Solcial p2p, надішлють повідомлення JOIN одному з вузлів завантаження (деякі з цих вузлів завантаження також є вузлами-маяками) у темі /solcial/public. Введення тем у HyparView є однією з наших модифікацій оригінальної статті.
Будь-який вузол, який отримує запит JOIN від піру, спершу перевірить, що мультихеш існує в ланцюжку та пов’язаний з обліковим записом соціальної мережі, потім він надішле повідомлення FORWARDJOIN одному зі своїх активних пірів з активним випадковим блуканням, встановленим на 3, вони в turn розповсюдить це повідомлення всім своїм активним піром, збільшуючи поточне число переходів на один, поки воно не досягне 3 стрибків. Це пом’якшення DDoS-атак на вузли завантаження, а також ефективна техніка децентралізації для максимального поширення та рандомізації зв’язку між вузлами.
Будь-який вузол, що знаходиться в межах 3 стрибків від початкового одержувача JOIN , надсилає повідомленняNEIGHBOR початковому запитувачу JOIN , встановлюючи між ними активне постійне з’єднання.
Періодично кожні 15 секунд вузли транслюватимуть повідомленняSHUFFLE випадковому активному піру з випадковою вибіркою його активних і пасивних пірів і встановлюють довжину випадкового обходу цього повідомлення рівним 4. Це гарантує, що всі піри в мережі завжди мають свіжу інформацію про інші піри, які вони можуть зберігати у своєму пасивному представленні для цілей відновлення мережі, щоразу, коли будь-який із їхніх активних пірів не відповідає або явно відключається.
Ефективне спілкування
Тільки активні піри беруть участь у поширенні повідомлень між пірами. Активні однорангові пристрої утворюють мережу накладання через загальнодоступний Інтернет, і існують цикли в графі підключення між вузлами. Щоб забезпечити ефективну передачу повідомлень між пірами в мережі, нам потрібно, по-перше, звести до мінімуму поширення подвійних повідомлень між ними, а по-друге, знайти найбільш оптимальний маршрут для повідомлень.
Це досягається за допомогою алгоритму Epidemic Broadcast Trees⁸, який утворює мінімальне охоплююче дерево між одноранговими партнерами, шляхом поділу однорангових вузлів на групу вузлів, що працюють з нетерпінням і лінивих вузлів. Вузли Eager-push завжди отримують повідомлення, щойно їх отримує будь-який вузол.
Ліниві вузли натискання періодично, кожні 500 мс, отримують пакет ідентифікаторів повідомлень, які бачить поточний вузол. Всякий раз, коли вузол помічає, що в пакеті відкладеного натискання є ідентифікатор повідомлення, яке не було отримано від його вищестоящого батьківського вузла, він відновить (GRAFT) з’єднання та відновить його статус активного натискання. Це є мінімальним механізмом відновлення опорного дерева на випадок, якщо один з вузлів виходить з ладу і формуються графи, що не перетинаються. Повідомлення GRAFT відновлюють повне підключення до мережі.
Всякий раз, коли виявляється, що отримане повідомлення є дублікатом попередньо отриманого повідомлення від активного вузла, з’єднання з цим вузлом вважається циклом у графі та перетворюється на Lazy-Push шляхом надсилання повідомленняPRUNE.
Інший випадок скорочення активного з’єднання та заміни його одним із лінивого списку – це коли ми помічаємо, що кількість стрибків, які пройшли повідомлення, щоб досягти нас через лінивий вузол, менша за 4 стрибки, ніж у повідомленні від активного піру. Це і складає алгоритм оптимізації Broadcast Tree.
Поширення контенту
Повідомлення, які передаються через протокол p2p, описаний у попередніх розділах, є повідомленнями IPFS Bitswap⁹ з ідентифікаторами вмісту, створеного користувачами Solcial. Щоб краще зрозуміти, як Bitswap і IPFS використовуються в Solcial, спочатку опишемо структуру профілю користувача.
Кожен обліковий запис користувача в мережі має так званий індекс профілю. Цей індекс вказує на ідентифікатори CID останніх версій їх вмісту. Індекс — це CRDT кінцевої послідовності, який утворює незмінний журнал операцій, які виконує обліковий запис.
Індекс профілю можна розглядати як зв’язаний список, де кожен елемент вказує на CID попереднього елемента і приймається пірами як наступний елемент у послідовності, лише якщо він підписаний закритим ключем власника облікового запису. Логічний приклад високого рівня каналу профілю, опублікованого в цьому форматі, виглядає так:
{“author”: “12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT”,“prev”: “QmYtUc4iTCbbfVSDNKvtQqrfyezPPnFvE33wFmutw9PBBk”,“action”: “append-feed-post”,“timestamp”: “2022–01–11T15:58Z”,“params”: {“content”: “QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb”“enckey”: “z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq”},“signature”: “2Lpnvt23H6qHswCNPmwCCUSas7YNP[…]jV1dC9qdNPR4zDqsCuBX”}
Подібний запис має власний CID і транслюється як об’єкт IPFS PB-DAG¹⁰ у тему накладання /solcial/public HyparView. Цей запис пов’язано з попереднім записом і будь-яким додатковим вмістом шляхом рекурсивного запиту пов’язаних ідентифікаторів клієнта, користувачі можуть отримати всю історію облікового запису та вміст.
Цей об’єкт спочатку перевіряється будь-яким одержувачем, якщо підпис вмісту відповідає відкритому ключу автора. У разі невдалої перевірки підпису пір відправник назавжди блокується на поточному вузлі через порушення протоколу. Успішна перевірка підпису поширює вміст до всіх інших пірів, зацікавлених у вмісті, автором якого є цей обліковий запис.
Коли такий CID отримує пір, він додається до журналу операцій автора. Сума всіх виконаних автором операцій складає поточний стан профілю.
За замовчуванням кожен вузол закріплює та заповнює власний вміст облікового запису та вміст своїх друзів. Існують спеціальні піри, які ми створюємо як частину нашої інфраструктури, які ми називаємо вузлами-маяками, і вони схожі на звичайні піри, за винятком того, що вони цікавляться вмістом кожного та служать свого роду службою закріплення IPFS для всього вмісту, що стосуються соціальних мереж. у випадку, якщо всі поточні вузли не в мережі. Думайте про них як про вузли, які є другом кожного. Мережа може функціонувати без них, але вони забезпечують додатковий рівень доступності вмісту.
Доступ для читання
Кожен, хто користується оверлеєм Solcial p2p, може запитувати, завантажувати та надавати будь-який користувальницький вміст, транслюючи повідомлення IWANT та IHAVE Bitswap у тему /solcial/public із CID кореневого індексу верхнього рівня облікового запису, а потім рекурсивно запитувати всі пов’язані CID.
Початкова синхронізація облікового запису або отримання останніх записів облікового запису досягається шляхом передачіHEAD повідомлення в тему /solcial/sync, де інші однорангові партнери, які є розсадниками (включаючи вузли-маяки), відповідають CID останнього вмісту, про який вони знають. з Трансляція між дескрипторами користувача та відкритими ключами користувача здійснюється шляхом запиту блокчейну Solana.
Поле попереднього запису можна використовувати для вирішення конфліктних HEADs і прийняття рішення щодо останнього запису.
Доступ до запису
Щоб мати можливість записувати в журнал облікового запису, користувач повинен володіти закритим ключем пари ключів ED25519, який відповідає ідентифікатору облікового запису. Маючи цей ключ, користувач може створити дійсний підпис запису, який він додає до журналу, який не буде відхилено іншими одноранговими в мережі.
Привілейований доступ до вмісту
Деякий вміст, опублікований користувачами, призначений лише для певної групи одержувачів, наприклад канали передплати рівня 1 або рівня 2. Ці повідомлення спочатку шифруються за допомогою симетричного ключа шифрування AES-256. Хеш цього ключа додається до метаданих вмісту в оригінальній публікації.
Ключ розповсюджується до випадкової підмножини відповідних однорангових пристроїв через зашифрований канал NOISE, встановлений під час рукостискання libp2p. Автор публікації може дозволити вузлам-маякам також брати участь у цій схемі обміну ключами, щоб зробити процес майже миттєвим для всіх користувачів, але це не обов’язково, якщо вони вважають, що їхній вміст є надзвичайно чутливим. Коли відповідний користувач хоче розшифрувати вміст, він надсилає повідомлення GETKEY на тему накладання /solcial/keyexchange з хешем ключа шифрування.
Усі однорангові, які володіють цим ключем, які знаходяться в мережі, перевірять придатність партнера для отримання цього ключа, запитуючи блокчейн і перевіряючи, чи має користувач необхідні токени для доступу до вмісту. Після успішної перевірки ключ передається запитувачу за допомогою прямого швидко-шумного з'єднання, яке обходить протокол розмов.
Підтримка платформи
Цей одноранговий протокол для вмісту, стійкого до цензури, доступний лише для настільних і мобільних клієнтів і не доступний через веб-інтерфейс. Це пов’язано з обмеженнями браузера. Браузери за своєю суттю створені як споживачі вмісту, розміщеного на серверах, і їхня модель безпеки забороняє приймати випадкові з’єднання з інших машин.
Веб-версія майже завжди буде централізованою через те, як працюють браузери, і що термін служби вкладки браузера короткий, а будь-який вміст, створений через веб-інтерфейс, буде дзеркально відображатися на p2p вузлами-маяками. Будь-який вміст, який споживає веб-клієнт, буде копією p2p. P2P є джерелом правди.
Базовий технічний стек реалізовано за допомогою Rust, libp2p із прив’язками до React Native та Tauri¹¹.
[1] Лейтао, Жоао, Жозе Перейра та Луїс Родрігеш. «HyParView: протокол членства для надійного мовлення на основі пліток».
[2] https://en.wikipedia.org/wiki/QUIC
[4] https://www.google.com/intl/uk/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] Лейтао, Жоао, Жозе Перейра та Луїс Родрігеш. «Epidemic broadcast trees.». 2007 26-й Міжнародний симпозіум IEEE з надійних розподілених систем (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
Про компанію Solcial
Solcial - це децентралізована соціальна мережа, яка надає користувачам можливості Web3, дозволяючи людям взаємодіяти один з одним, не побоюючись цензури,і яка дозволяє авторам контенту отримувати справедливу винагороду за ринковою вартістю.
Посилання на офіційні сторінки Solcial
Telegram: https://t.me/solcial
Discord: https://discord.gg/solcial
Twitter: https://twitter.com/solcialofficial
Blog: http://blog.solcial.io/
Website: https://solcial.io
Email: [email protected]
Linktree: https://linktr.ee/solcial
