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

Навiть платформи, запущенi з найкращими намiрами бути вiдкритими, нейтральними та вiльними вiд контролю, можуть перетворитися на форми централiзацiї.

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

Вибір інфраструктурного дизайну має значення з першого дня.

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

Ми вже бачили цей фільм раніше

"Влада має тенденцію концентруватися, навіть якщо ніхто цього не планує"

Це тонка, але глибока правда, яку я вивчив на власному досвіді, працюючи над інтернет-продуктами великого масштабу.

Коли народжувалася «децентралізована галузь», здавалося, що це другий шанс. Ми дивилися на Біткоїн, Ефіріум та інші криптовалюти як на способи втечі від старих структур влади.

Зміст був простим: поверніть контроль, відкиньте посередників і дозвольте коду забезпечити справедливість.

Але нам потрібно бути чесними, з часом ті самі тиски, що централізували Інтернет, також почали впливати на ці 'децентралізовані' системи.

Але як Інтернет став централізованим?

Хіба Інтернет не починався як децентралізована P2P-мережа, яка могла витримати навіть ядерну війну?

Щоб зрозуміти, чому ці децентралізовані системи піддаються централізуючим тискам, вам потрібно зрозуміти, що сталося з Інтернетом.

Вам потрібно подивитися, як він перетворився зі своїх ідеалістичних початків в високоцентралізовану екосистему.

Ранній Інтернет: коли Peer-to-Peer був нормою

“На початку ніхто не тримав всі ключі, і жоден гравець не був визначальним”

Найбільш рання версія того, що ми зараз називаємо Інтернетом, по суті почалася в Міністерстві оборони США, з такими речами, як ARPANET наприкінці 60-х років.

Джерело: @DailySwig

Уся ідея з першого дня полягала в уникненні такої однієї точки відмови, щоб переконатися, що жодне падіння не може забрати з собою все інше.

Ця мережа була намірено спроектована для децентралізації.

Обґрунтування було стратегічним: розподілена система може витримати відмову будь-якого окремого вузла, роблячи зв'язок більш стійким перед обличчям збоїв, таких як несправності обладнання або навіть умови воєнного часу.

Надійна та децентралізована комунікаційна мережа, яка може витримати навіть ядерну атаку.

Кожен вузол був «рівнем», здатним надсилати та отримувати дані без покладання на одну централізовану владу. Будь-яка машина, незалежно від апаратного забезпечення або операційної системи, могла «розмовляти» по TCP/IP та обмінюватися даними.

В 70-х і 80-х роках університети та дослідницькі лабораторії з'єдналися через NSFNET та ARPANET, і раптово ви мали таке середовище, де ніхто не мав всіх ключів і жоден гравець не приймав всі рішення.

Це проявилося в фундаменталах:

TCP/IP, FTP, Telnet, новинні групи Usenet і DNS не були про те, щоб закріпити когось на одному місці. Було мало стимулу накладати жорсткі контролі або ієрархії.

Наприклад, Usenet поширює повідомлення в повністю децентралізованому P2P-режимі. DNS делегує авторитет назви в розподіленій ієрархії, але кожен компонент все ще виступає як клієнт і сервер до певної міри.

Все це підтвердило той початковий принцип:

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

Але в початку 90-х років Всесвітня павутиння та браузери змінили всю гру.

Відтворена сторінка першого веб-сайту (Зображення: CERN)

Зростання моделі клієнт/сервера

Tim Berners-Lee: Візіонер За Світовою Павутинкою

Під час стрімкого зростання користувацької бази Інтернету почали виявлятися тріщини в початковому дизайні, що стосувалися відкритої участі та взаємної довіри

Світова павутиння, представлена в 1989–1991 роках, була побудована на відкритих стандартах (HTTP, HTML), які свідомо були розміщені в громадському доступі. У своїй найпершій формі Веб зробив це тривіальним для окремих осіб, невеликих організацій чи будь-кого, у кого був модем і можливість хостингу, створити веб-сайт.

Інфраструктура все ще в основному була «плоскою» та децентралізованою, з безліччю незалежних веб-сторінок, які були пов’язані разом у вільній федерації.

Але на початку 90-х щось стало дуже популярним.

Це сталося, коли 'Web Browsing' став 'убиваючою програмою'.

Веб-сайти стали прилавками, новинними ресурсами та розважальними центрами. Звичайна людина не запускала свій власний сервер або не розміщувала свої сторінки.

Домашня сторінка Netscape у 1994 році зі своїм символом Mozilla, як видно в NCSA Mosaic 3.0

[Скріншот: Алекс Пастернак / OldWeb.today]

Вони запускали веб-браузери (клієнти), спочатку з тими повільними модемами, потім широкосмуговими, щоб отримувати контент з великих, відомих веб-серверів. Раптово, хостинг великих обсягів даних і налаштування електронної комерції або пошукових систем стали великою річчю.

Ранні пошукові системи, такі як AltaVista, Yahoo! і пізніше Google, з'явилися, щоб допомогти людям орієнтуватися в швидкорозширюючомуся онлайн-світі.

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

Алгоритм PageRank від Google перетворив його на єдину браму до безмежності вебу.

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

По мере появления поставщиков услуг Интернета для обслуживания миллионов новых пользователей инфраструктура естественным образом оптимизировалась для доставки вниз.

Швидкість завантаження вища, ніж швидкість вивантаження (асиметричне підключення до широкосмугового Інтернету, таке як ADSL або кабельне) має економічний сенс, оскільки більшість користувачів споживають більше, ніж виробляють. Мережа «вивчила», що більшість кінцевих точок є лише клієнтами.

І коли користувачів Інтернету стало все більше, почали з'являтися тріщини в початковому дизайні, який передбачав відкриту участь та взаємну довіру.

Безпека, мережеві фільтри та закриті ворота

«Свобода і відкритість без захисту можуть спричинити зловживання, які змушують нас будувати вищі стіни».

Оригінальні протоколи не були побудовані для того, щоб працювати з масштабною, різноманітною громадою, багатьма з бізнес-інтересами або мотиваціями, які випробовують відкритість системи.

Без реальних захисних заходів спам став великою проблемою, експлуатуючи цю відкриту середу.

Оригінальний відкритий дизайн зробив кожного хоста доступним з будь-якого іншого хоста, що було добре, коли Інтернет був невеликим, довіреним співтовариством.

Але зростання викликів, спроби вторгнення та зловмисні дії розбухали.

Джерело:emailtray.com

Аналогічно, без якогось способу забезпечити справедливе використання пропускної здатності, деякі програми навчилися витиснювати межі і отримувати перевагу на чужий рахунок.

Ці недоліки дизайну підштовхнули Інтернет до більшої регуляції та контролю.

Для захисту внутрішніх мереж організації використовують брандмауери для блокування вхідних з'єднань. Технологія мережевої адресації (NAT) додатково ізолює внутрішні комп'ютери за допомогою спільної IP-адреси.

Це обмежило безпосередній характер комунікацій.

Хости за NAT-ами та брандмауерами фактично були змушені виконувати лише клієнтську роль, не були більше безпосередньо доступні зовнішньому світу.

З часом ці рішення щодо інфраструктури посилювали одне одного.

З'явлення ворітників

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

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

Іншими словами, середовище практично торкнулося Мережі до кількох централізованих гігантів.

На початку 2000-х років кілька компаній зрозуміли, що контроль над дата-центрами та володіння величезною серверною інфраструктурою давали їм величезні конкурентні переваги.

Вони можуть надавати швидкі, надійні та зручні послуги порівняно з випадковим підключеним користувачем в мережі.

Ця тенденція була на стероїдах наприкінці 2000-х років.

Джерело:datareportal.com

Пошукові системи, такі як Google, великі платформи, такі як Amazon, гіганти соціальних медіа, такі як Facebook, та мережі розподілу вмісту побудували величезну інфраструктуру, яка забезпечувала доставку контенту та додатків з неперевершеною швидкістю та масштабом.

Ці великі компанії також використовували "доброчесний цикл" даних та алгоритмів.

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

Потім модель доходів Інтернету суттєво змінилася на користування цільовою рекламою.

З часом ця петля зворотного зв'язку ще більше сконцентрувала владу, оскільки менші конкуренти намагалися зрівнятися з інвестиціями в інфраструктуру та перевагами великих гравців у сфері даних.

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

Такі гіганти, як Amazon (AWS), Microsoft (Azure) та Google Cloud, тепер є головною хмарною інфраструктурою Інтернету. Цей зсув стався тому, що ведення масштабу, надійної і безпечної інфраструктури стало настільки складним і капіталомістким, що змогли ефективно зробити це лише кілька компаній.

Стартапи навіть вже визнані компанії знайшли зручніше та дешевше полагатися на цих великих постачальників хмарних послуг.

Сервіси, такі як CDN (наприклад, Cloudflare або Akamai), та резольвери DNS також нахилялися до кількох великих гравців.

Складність і економічні переваги цих керованих рішень означали менше причин для організацій «розгортати власну» інфраструктуру.

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

Післяматч: влада сконцентрована в декількох руках

«Великі гравці не починалися злі; вони просто оптимізували для зручності, продуктивності та прибутку.

Це був природній результат ранніх архітектурних рішень в основній мережі.

Зі зростанням масштабу та централізації з'явилася більша потужність та контроль.

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

З часом алгоритми рекомендацій та політики щодо контенту цих платформ стали фактичними арбітрами громадського діалогу.

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

Зараз ці компанії, в певній мірі, мають вплив, який можна порівняти з впливом урядів: вони можуть формувати громадський діалог, впливати на комерцію та контролювати цілі екосистеми розробників сторонніх сторін.

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

Це не була якась велика схема концентрації влади. І ця ситуація не виникла внаслідок одного єдиного "неправильного повороту".

Великі гравці не починали злі; вони просто оптимізували зручність, продуктивність та прибуток. Це був природний результат початкових виборів архітектурного дизайну в основній мережі.

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

З часом ці вибори накопичилися в системі, де кілька компаній домінують.

Те ж саме відбувається перед нашими очима в децентралізованій галузі.

Шлях до централізації вкритий "тимчасовими" рішеннями

«Тяга до централізації не завжди є результатом зловмисних намірів; часто це спроба виправити проблеми системи, яка ніколи не була побудована для децентралізації на масштабі».

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

Це найлегше побачити на прикладі спроб Ethereum масштабуватися.

Високі комісії та повільна пропускна здатність змусили розробників прийняти рішення про використання рішень Layer-2 (L2): rollups, які пакують транзакції поза ланцюжком, а потім вирішують їх на Ethereum. У теорії ці L2s повинні зберігати довіру Ethereum.

На практиці багато хто залежить від одного «послідовника» (центрального сервера, який впорядковує транзакції), що веде одна компанія.

Зараз одне певне рішення L2 має найбільшу активність та загальну кількість заблокованих цінностей, але воно також найбільш централізоване,

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

З плином часу ці «тимчасові» рішення мають тенденцію стає постійними. Та ж сама схема може виникнути з майбутніми шаровими підходами; деякі навіть можуть не заморочуватися обіцянкою будь-якого шляху до децентралізації.

«Вхід у соціальні мережі» може здатися корисним: він дозволяє людям легко почати користуватися сервісом, не жонглюючи приватними ключами чи складними інтерфейсами. Але якщо ці логіни залежать від централізованого компонента, ви знову довіряєте одній компанії, що вона робить правильні речі.

Ось чому, коли ми створювали zkLogin, ми створювали та інтегрували його без довіри. Було важко, але ми не можемо йти на компроміси і вводити централізацію для зручності.

Схожа ситуація виникла в екосистемі NFT.

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

Недавно цей ринок вирішив припинити заборону на стягнення роялті з вторинних продажів.

Так, це збільшило обсяг торгівлі, але це підводить творців, які поклалися на ці роялті як на основне джерело доходу.

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

Їх гегемонія також поширилась поза торгівлею, оскільки багато проектів також залежали від їх API та інфраструктури.

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

Проте чому це продовжує траплятися?

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

Ні один із цих кроків не починається як великі плани на монополію. Вони просто практичні відповіді на складні технічні та ринкові виклики.

Але з часом ці "пластирі" вбудовуються в ДНК системи, створюючи структуру, де кілька гравців утримують ключі.

Тому ці системи повинні бути розроблені з нуля для розробників, а не лише для споживачів.

Будування для розробників, а не тільки споживачів

«Якби я запитав людей, чого вони хочуть, вони сказали би швидших коней.» - Генрі Форд

Більшість споживачів просто хочуть кращої версії того, що вони вже мають.

Але коли ми лише переслідуємо ці короткострокові поліпшення, ми ризикуємо виявитися з системами, які на поверхні виглядають децентралізовано, але все ще мають кількох ключових гравців, які тягнуть за рушії.

Якщо ми дійсно хочемо уникнути повторення помилок, які привели до сучасних цифрових gatekeepers, нам потрібно зосередитися на творцях майбутнього, будівельників, а не лише споживачів.

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

0:00 / 0:38

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

Ось чому ці системи повинні бути розроблені з нуля, щоб посилити децентралізацію, навіть якщо вони повинні масштабуватися до рівня Інтернету.

Технічний борг проти дизайнерського боргу

"Технічний борг можна виправити за допомогою рефакторингу; дизайнерський борг часто вимагає повного скидання."

З моїх початкових років роботи з системами, які масштабуються до мільярдів користувачів, одна урок залишився зі мною: як тільки система стає критично важливою, ви не можете просто все розібрати і перебудувати без великого розладу.

Момент, коли мільйони користувачів покладаються на закріплені у системі поведінкові моделі та припущення, навіть пропонуючи радикальні архітектурні зміни, стає неприйнятним.

Це розірвало би додатки, бізнес-моделі та довіру цілих спільнот, побудованих на верхньому рівні.

Це поняття «дизайн-боргу» в своєму найважчому випадку.

Мова йде не тільки про чистоту коду; Йдеться про фундаментальні архітектурні рішення, які визначають, як довіра, влада та цінність протікають через мережу.

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

Люди побудували на цьому припущенні, вважаючи, що воно таке ж незмінне, як гравітація. Але це не було так.

Воно виросло з несповних архітектур, які були: великі глобальні спільні стани, обмежені моделі даних, що робили неможливими паралелізм і модульне масштабування.

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

За цих умов додавання шарів (наприклад, L2, які покладаються на централізовані секвенсори, або стиснених активів, які залежать від централізованого сховища) лише замазує тріщини.

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

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

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

Урок очевидний: ви повинні правильно встановити архітектуру з самого початку.

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

Це про переосмислення всієї технічної стопки з першого дня.

Отримання Основ Правильно З Першого Дня

“Єдиний справжній метод позбутися дизайн-боргу - це не накопичувати його в першу чергу.”

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

Тому, коли ми розробляли Sui, ми хотіли вбудувати ці основоположні принципи з першого дня.

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

Розгляньте саму модель програмування:

Об'єктно-центричний підхід Sui є свідомим відходом від облікових парадигм, які домінували в багатьох блокчейнах.

Модель програмування, яка базується на об'єктах

У центрі філософії дизайну Суї лежить модель програмування, спрямована на об'єкти.

У світі, де розробники Web2 природно думають в термінах об'єктів, таких як файли, записи та активи, не має сенсу зводити все до монолітної моделі облікового запису.

Це змушує розробників до натуральних моделей мислення. Воно вводить складність, яка готова до помилок.

Модель програмування, зорієнтована на об'єкти, природно відповідає тому, як інженери Web2 вже розмірковують про програмне забезпечення.

Об'єкти є першокласними громадянами, що дозволяє просто представляти активи, визначати правила та уникати поширених проблем, таких як помилки повторного входу, без заплутаного коду, що вимагається.

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

В результаті код стає більш зрозумілим, безпечним та легше сприймається.

Це прямий міст від об'єктно-орієнтованого мислення Web2 до недовірливого середовища Web3, що стало можливим завдяки правильним припущенням з самого початку.

Масштабування за дизайном, а не за допомогою скотчу

Але велика модель програмування нічого не значить, якщо вона розгинається під навантаженням.

З самого початку Sui був побудований для роботи з реальним навантаженням. Він був спроектований для горизонтального масштабування зі збереженням синхронної атомної композиції.

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

З Sui кожен об'єкт ефективно є власним шардом. Потрібна більша потужність? Додайте більше обчислювальної потужності для обробки навантаження.

Прототип Pilotfish:https://blog.sui.io/pilotfish-execution-scalability-blockchain/

Розробники не повинні турбуватися про розподіл логіки, з'єднання кількох доменів або гачок інфраструктури для досягнення масштабу.

Отже, система може обробляти більше трафіку по мірі зростання мережі, але як забезпечити справедливе розподіл ресурсів?

Якщо один популярний актив або dApp захоплює ринок оновлень стану, він може збільшувати вартість та погіршувати досвід для всіх інших.

Замість покладання на одне, глобальне аукціонування місця в блоках, де одне популярне застосування може піднімати ціни для всіх, місцеві ринки оплати дозволяють системі цінувати ресурси на більш детальному рівні грануляції.

Кожен «об'єкт» або шар може мати свій власний ринок комісій, що гарантує, що перенавантаження в одній області не перекидається і не покарає непов'язані частини мережі.

Все воплощено в базовом дизайне платформы, что обеспечивает то, что даже с ростом спроса система не возвращается к устаревшим схемам преград и огороженных садов.

Проектування для децентралізації також означає вбудовування перевірки прямо в рівні зберігання та комунікації.

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

Перевірне зберігання без централізованих хостів

Справжнє децентралізоване застосування не може покладатися на одного хмарного провайдера або централізовану базу даних.

Walrus надає децентралізований, перевірений шар зберігання, який можна порівняти за потужністю та масштабом з централізованими пропозиціями, такими як AWS або Google Cloud.

З валрусом перевірка даних не є вторинною думкою, але є вбудованою властивістю.

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

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

Зараз, проектуючи для децентралізації, також означає, що це не повинно зупинятися на рівні консенсусу або виконання; воно повинно поширюватися на саму мережу.

Мережеві рівні не повинні ґратися на кількох потужних постачальниках послуг Інтернету або маршрутизаційних службах. Це також централізація.

Мережевий шар, побудований для децентралізації

Мережевість є ще одним елементом головоломки, який часто не береться до уваги в Web3.

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

SCION - це мережевий протокол нового покоління, який ставить під сумнів цей статус кво, роблячи маршрутизацію більш безпечною, надійною і стійкою до централізованого контролю.

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

Інтегруючи SCION в Sui, ми забезпечуємо, що базова мережа не є єдиним точком відмови або контролю.

Жодна окрема сутність не має права диктувати потік даних, і користувачі можуть довіряти тому, що основні маршрути не будуть маніпульовані або монополізовані.

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

Ви не додаєте децентралізацію як післядумка; ви вбудовуєте її в основу.

Ця простота зменшує складність і не дозволяє використовувати "зручні", але централізовані обхідні шляхи. Найголовніше, правильне засвоєння основ означає ніколи не ставити на себе ризик з "ми все виправимо пізніше".

Усі дороги ведуть до звукового дизайну

«Децентралізація не полягає у кількості валідаторів. Справжня децентралізація полягає в архітектурі, яка утримує владу від зосередження в одному місці». gate

Суть всього, що ми досліджували, проста: якщо ви хочете систему, яка не може бути зла, ви повинні почати з правильної архітектури.

Якщо ви починаєте з неправильних припущень, жодна кількість додаткового коду або розумних фокусів не врятують вас.

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

Ось чому так важлива архітектурна основа.

Децентралізація - це не лише підрахунок кількості вузлів. Справжня децентралізація означає розробку на рівні кореня так, щоб довіра, справедливість та перевірка були неможливі до обхіду.

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

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

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

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

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

У вас буде мережа, яка вже справедлива, стійка і готова служити основою для наступного покоління цифрових вражень.

Відмова від відповідальності:

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