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

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

Это не потому, что кто-то намерен быть “злым”; это просто естественное гравитационное притяжение технологии и рынков, когда определенные проектные решения заложены с самого начала.

Выбор дизайна инфраструктуры имеет значение с самого начала.

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

Мы уже видели этот фильм раньше

«Власть имеет тенденцию концентрироваться, даже если никто не планирует этого»

Это тонкая, но глубокая правда, которую я узнал на собственном опыте, работая над крупными интернет-продуктами.

Когда родилась ‘децентрализованная индустрия’, казалось, что наступил второй шанс. Мы смотрели на Биткоин, Эфириум и другие как на способы избежать старых властных структур.

Сюжет был прост: вернуть контроль, убрать посредников и позволить коду обеспечивать справедливость.

Но мы должны быть честными, со временем те же давления, которые централизовали Интернет, начали действовать и на эти «децентрализованные» системы.

Но как интернет стал централизованным?

Интернет не начинался как децентрализованная сеть P2P, которая могла бы выдержать даже ядерную войну?

Чтобы понять, почему эти децентрализованные системы поддаются централизующему давлению, вам нужно понять, что произошло с Интернетом.

Вы должны посмотреть, как он перешел от идеалистических начал в высокоцентрализованную экосистему.

Ранний Интернет: когда P2P был стандартом

«В начале никто не держал все ключи, и ни один игрок не решал все вопросы»

Самая ранняя версия того, что мы сейчас называем Интернетом, по сути, началась под эгидой Министерства обороны США, с такими вещами, как ARPANET в конце 60-х годов.

Источник: @DailySwig

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

Эта сеть была намеренно создана для децентрализации.

Логика была стратегической: распределенная система могла выдержать отказ любого отдельного узла, делая связь более устойчивой к сбоям, таким как неисправности оборудования или даже военные условия.

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

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

К 70-м и 80-м годам университеты и исследовательские лаборатории стали связываться через NSFNET и ARPANET, и вдруг у вас появилась среда, где никто не держал все ключи, и ни один игрок не диктовал все условия.

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

TCP/IP, FTP, Telnet, новостные группы Usenet и DNS не предполагали привязки пользователей к одному месту. Не было особых стимулов для введения строгого контроля или иерархий.

Usenet, например, распространял сообщения в полностью децентрализованном P2P-режиме. DNS делегировало авторитет именования в распределенной иерархии, но каждый компонент все равно действовал в качестве клиента и сервера в определенной степени.

Все это подтвердило исходный принцип:

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

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

Воссозданная страница первого веб-сайта (Изображение: CERN)

Развитие клиент-серверной модели

Тим Бернерс-Ли: Видение за созданием всемирной паутины

«По мере роста пользовательской базы Интернета, исходные предположения о открытом участии и взаимном доверии начали трещины»

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

Инфраструктура оставалась в значительной степени «плоской» и децентрализованной, с бесчисленными независимыми веб-страницами, связанными в свободной федерации.

Но в начале 90-х что-то стало действительно популярным.

Это произошло, когда «Веб-просмотр» стал «убийственным приложением».

Веб-сайты стали витринами, информационными ресурсами и центрами развлечений. Средний человек не запускал свой сервер и не размещал свои страницы.

Домашняя страница 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, теперь являются хозяевами основы большей части Интернета. Этот сдвиг произошел потому, что запуск масштабной, безопасной и надежной инфраструктуры стал настолько сложным и капиталоемким, что только несколько компаний могут делать это эффективно.

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

Сервисы, такие как CDNs (например, Cloudflare или Akamai) и DNS-резолверы, также приблизились к нескольким крупным игрокам.

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

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

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

Большие игроки не начинали злых; они просто оптимизировали удобство, производительность и прибыль.

Это был естественный результат ранних архитектурных проектных решений в основной сети.

Со масштабом и централизацией пришла большая власть и контроль.

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

Со временем алгоритмы рекомендаций и политики контента этих платформ стали фактическими арбитрами общественного диалога.

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

Теперь эти компании, в некотором отношении, обладают властью, сравнимой с властью правительств: они могут формировать общественный дискурс, влиять на коммерцию и контролировать целые экосистемы сторонних разработчиков.

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

Это не была какая-то большая схема для концентрации власти. Не также это положение проистекло из одного «неправильного поворота».

Крупные игроки не начинали с злых умыслов; они просто оптимизировали удобство, производительность и прибыль. Это был естественный результат ранних архитектурных выборов в основной сети.

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

Со временем эти выборы привели к системе, в которой небольшое количество компаний доминирует.

То же самое происходит перед нашими глазами в децентрализованной индустрии.

Дорога к Централизации вымощена “Временными” Решениями

“Тяга к централизации не всегда является результатом злонамеренных действий; часто это попытка исправить проблемы системы, которая никогда не была создана для децентрализации в масштабе.”

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

Самое легкое это увидеть на примере попыток Ethereum масштабирования.

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

На практике многие полагаются на один «секвенсор» (центральный сервер, упорядочивающий транзакции), управляемый одной компанией.

В настоящее время одно конкретное решение L2 имеет наибольшую активность и общую заблокированную стоимость, но оно также является наиболее централизованным,

Идея в том, что децентрализация когда-нибудь придет, но мы это уже слышали раньше.

Со временем эти «временные» решения имеют свойство становиться постоянными. Тот же самый шаблон может возникнуть с будущими слоистыми подходами; некоторые даже не побеспокоятся обещать какой-либо путь к децентрализации.

«Социальные входы» могут показаться полезными: они упрощают начало использования сервиса без необходимости управления личными ключами или сложными интерфейсами. Но если эти входы зависят от централизованного компонента, вы снова доверяете одной компании сделать правильное решение.

Вот почему, когда мы создавали zkLogin, мы создали и интегрировали его в доверительном режиме. Это было сложно, но мы не можем идти на компромисс и вводить централизацию для удобства.

Похожий образец возник в экосистеме NFT.

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

Недавно этот рынок решил прекратить взимание выплат роялти с продаж на вторичном рынке.

Да, это увеличило объем торговли, но это подводит создателей, которые полагались на роялти как на основной источник дохода.

Это является ясным примером последствий, когда централизованные платформы могут изменять правила в любое время по своему усмотрению.

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

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

Но почему это продолжается?

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

Ни один из этих шагов не начинается как великие планы по монополизации. Они просто практические ответы на сложные технические и рыночные вызовы.

Но со временем эти «пластыри» становятся встроенными в ДНК системы, создавая структуру, в которой несколько игроков держат ключи.

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

Строим для строителей, а не только для потребителей

«Если бы я спросил людей, что они хотят, они бы сказали, что хотят более быстрых лошадей». - Генри Форд

Большинство потребителей хотят только лучшей версии того, что у них уже есть.

Но когда мы преследуем только эти краткосрочные улучшения, мы рискуем оказаться в системах, которые на поверхности выглядят децентрализованными, но по-прежнему имеют нескольких ключевых игроков, тянущих за веревки.

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

Вот почему я всегда говорю своей команде, что потребители всегда будут просить о более быстрой лошади; это строители, которые представляют себе автомобиль.

0:00 / 0:38

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

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

Технический долг против дизайн-долга

«Технический долг может быть исправлен рефакторингом; долг дизайна зачастую требует полной переработки».

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

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

Это разрушило бы приложения, бизнес-модели и доверие целых сообществ, построенных сверху.

Это понятие “долга дизайна” в самой тяжелой форме.

Это не просто о чистоте кода; это о фундаментальных архитектурных выборах, которые определяют, как доверие, власть и ценность протекают через сеть.

На заре этой индустрии так называемая «трилемма блокчейна или масштабируемости», идея о том, что децентрализация, безопасность и масштабируемость не могут быть одновременно, рассматривалась как закон природы.

Люди построились на этом предположении, считая, что оно такое же неизменное, как гравитация. Но это не так.

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

Единственный путь вперед - сгруппировать все транзакции вместе, заставив каждого участника бороться за одни и те же ограниченные ресурсы, независимо от того, что они делают. Результат? Неэффективные аукционы для блокировки пространства, которые повышают стоимость во время всплесков спроса и не изолируют конгестии там, где они действительно возникают.

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

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

Таким образом, долг по дизайну накапливается в форме “технической гравитации”, которая тянет все к централизации.

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

Урок ясен: нужно правильно спроектировать архитектуру с самого начала.

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

Это о переосмыслении всего технологического стека с первого дня.

Правильное понимание основ с первого дня

«Единственный настоящий способ избавиться от долга по дизайну - не накапливать его в первую очередь».

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

Вот почему, когда мы разрабатывали Sui, мы хотели внести эти основополагающие принципы с самого начала.

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

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

Подход Sui к объектам является преднамеренным отходом от господствовавших на многих блокчейнах аккаунт-ориентированных парадигм.

Модель программирования, ориентированная на объекты

В основе философии дизайна Sui лежит объектно-ориентированная модель программирования.

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

Это заставляет разработчиков действовать внеестественным образом. Это вносит сложности, которые готовы к ошибкам.

Модель объектно-ориентированного программирования естественным образом соответствует тому, как инженеры Web2 уже рассуждают о программном обеспечении.

Объекты служат полноправными гражданами, что делает простым представление активов, определение правил и избежание распространенных проблем, таких как ошибки реентрансии, без запутанного шаблонного кода.

Эта знакомая модель радикально снижает концептуальные накладные расходы и распространенные проблемы, такие как рекурсия. Вместо написания шаблонных проверок или сложных защитных ограждений для предотвращения эксплойтов, разработчики полагаются на Move VM, чтобы обеспечить безопасность на уровне выполнения.

В результате код становится более читаемым, безопасным и легче понимаемым.

Это прямой мост от объектно-ориентированного мышления Web2 к доверительной среде Web3, обеспечиваемый правильными предположениями с самого начала.

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

Но великая модель программирования ничего не значит, если она ломается под нагрузкой.

С самого начала Sui был создан для работы с реальной нагрузкой. Он был разработан для горизонтального масштабирования с сохранением синхронной атомной атомарной составляемости.

Объектная модель системы обеспечивает Sui детальное понимание того, какие части состояния затрагивает каждая транзакция, обеспечивая параллельное выполнение в масштабе. Это является резким контрастом по отношению к системам, основанным на EVM, которые должны блокировать весь глобальный стейт. Это замедляет все процессы и способствует централизованным решениям для обработки объема транзакций.

С Sui каждый объект фактически представляет собой свой собственный шард. Нужна большая мощность? Добавьте больше вычислительной мощности для обработки нагрузки.

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

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

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

Если один популярный актив или dApp захватывает рынок обновлений состояния, это может повлечь за собой увеличение затрат и ухудшение опыта для всех остальных.

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

Каждый «объект» или осколок может иметь свой собственный рынок сборов, обеспечивая, что затор в одной области не перетекает и не наказывает несвязанные части сети.

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

Проектирование для децентрализации также означает включение проверяемости прямо в слои хранения и коммуникации.

Если хранение данных зависит от одной доверенной стороны, вы вернулись к исходной точке. Вам нужны решения для хранения, которые позволяют любому проверять целостность данных без зависимости от посредника.

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

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

Walrus предоставляет децентрализованный, верифицируемый уровень хранения, сравнимый по мощности и масштабу с централизованными предложениями, такими как AWS или Google Cloud.

С тюленем проверяемость данных не является послеумысленностью, а внутренним свойством.

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

Другими словами, Walrus расширяет философию «правильности построения» от выполнения к хранению, обеспечивая целостность вашего приложения на каждом уровне.

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

Сетевые уровни не должны зависеть от нескольких мощных поставщиков услуг интернета или сервисов маршрутизации. Это также централизация.

Сетевой уровень, созданный для децентрализации

Сетевые технологии - еще один часто пренебрегаемый аспект в Web3.

Традиционная маршрутизация Интернета контролируется несколькими поставщиками услуг Интернета, что создает потенциальные узкие места и уязвимости.

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

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

Интегрируя SCION в Sui, мы обеспечиваем, чтобы базовая сеть не была единственной точкой отказа или контроля.

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

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

Вы не добавляете децентрализацию, как после сделанного; вы встраиваете ее в основу.

Эта простота снижает сложность и оставляет дверь закрытой для «удобных», но централизованных обходных путей. Самое главное, правильное понимание основ означает, что вы никогда не должны делать ставку на менталитет «мы исправим это позже».

Все дороги ведут к звуковому дизайну

«Децентрализация - это не количество валидаторов. Настоящая децентрализация - это архитектура, которая не допускает концентрации власти в одном месте».

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

Если вы начнете с неправильных предположений, никакое количество дополнительного кода или умных трюков не спасет вас.

Архитектура, которая вознаграждает gatekeepers. Модель данных, которая заставляет каждого актера конкурировать за один и тот же редкий ресурс. Уровень сетевой связи, разработанный вокруг централизованных хабов. В конечном итоге, вы скатитесь в те же старые паттерны контроля и иерархии.

Вот почему так важно архитектурное основание.

Децентрализация — это не только подсчет количества узлов. Истинная децентрализация означает проектирование на уровне корней таким образом, чтобы доверие, справедливость и верифицируемость были невозможны для обхода.

Это означает создание систем, где ни группа китов, ни хорошо обеспеченная компания не могут тихо наклонить игровое поле. Речь идет о том, чтобы обеспечить каждому участнику равные возможности, и чтобы ни одна точка удушения, ни какое-либо тонкое проектирование не могли привести к росту централизации.

Sui - это один пример того, что происходит, когда вы проектируете с учетом этих принципов с самого начала, а не пытаетесь адаптировать их позже.

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

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

Постройте его правильно с самого начала, и вам не придется обещать будущие исправления или полумеры.

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

Отказ от ответственности:

1. Эта статья перепечатана с [ Недостаточно информации для перевода]. Все авторские права принадлежат оригинальному автору [@EvanWeb3]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь со Gate Learnкоманда и они незамедлительно займутся этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, принадлежат только автору и не являются инвестиционным советом.
3. Команда Gate Learn занимается переводами статей на другие языки. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.