**a16z зайняв важливу позицію в галузі шифрування, щоб керувати розвитком галузі завдяки своїм глибоким статтям, надаючи нам вказівки, необхідні для когнітивного вдосконалення та трансформації. Останнім часом a16z зосереджується на проблемах, що виходять за межі економіки токенів. Він розпочався з розмови на тему «Дизайн токенів», потім пішла «Токенологія: за межами економіки токенів», а тепер довгоочікуваний курс «Дизайн протоколів». Як лектор курсу, Едді Лазарін, технічний директор a16z crypto, неодноразово підкреслював, що ключ до виходу з економіки токенів лежить у дизайні протоколу, а дизайн токенів є лише допоміжним засобом. У цьому курсі, присвяченому розробці протоколів, він ділився більше години, приносячи цінну інформацію та просвітництво підприємцям, допомагаючи їм глибше зрозуміти ключову роль дизайну протоколу в успіху проекту. Ця стаття є спрощеним варіантом перекладу. Для отримання більш захоплюючого вмісту перегляньте посилання на повнотекстову версію перекладу. **
Внутрішні закони еволюції протоколу
Інтернет-протокол: зв’язок взаємодії
Інтернет — це мережа протоколів, що включає різні типи протоколів. Деякі протоколи є короткими, як-от діаграма стану HTTP, а інші досить складні, як-от діаграма взаємодії протоколу Maker. На малюнку нижче показані різні протоколи, включаючи Інтернет-протоколи, фізичні протоколи та політичні протоколи. Зліва на зображенні нижче ми бачимо інтерактивну карту перехрестя вулиць, яка здається нам знайомою та цікавою.
Спільним для цих протоколів є те, що всі вони є формалізованими інтерактивними системами, які сприяють складній груповій поведінці, яка є основним компонентом протоколу. Потужність Інтернет-протоколу полягає в його здатності з’єднувати не лише взаємодію між людьми, але й програмне забезпечення. Ми знаємо, що програмне забезпечення дуже адаптивне та ефективне, здатне інтегрувати механізми. Таким чином, Інтернет-протокол, можливо, є одним із наших найважливіших, якщо не найважливішим, типів протоколів.
Розвиток протоколу: Web1 - Web2 - Web3
На діаграмі нижче горизонтальна вісь відображає ступінь децентралізації та централізації протоколу, тобто ступінь контролю над протоколом. На вертикальній осі є узгоджена економічна модель, конкретно вказуючи на те, чи є економічна модель явною чи невизначеною. Ця відмінність може здатися ледве помітною, але вона має важливі наслідки.
Web1: децентралізовано та немає чіткої економічної моделі
Протоколи періоду Web1 (такі як NNTP, IRC, SMTP і RSS) були нейтральними з точки зору потоку вартості, власності, прав доступу та механізмів оплати, без чіткої економічної моделі. Серед них Usenet — це протокол, схожий на сучасний Reddit для обміну публікаціями та файлами. IRC був раннім і широко використовуваним протоколом чату, а SMTP і RSS використовувалися для електронної пошти та підписки на вміст.
Usenet — це організована таксономія платформа, яка дозволяє користувачам публікувати відповідний вміст на підсерверах певних категорій. Це була важлива частина ранньої інтернет-культури та існувала поза HTTP. Для використання Usenet потрібен певний клієнт і постачальник послуг Інтернету (ISP), який підтримує Usenet. Usenet поширюється на велику кількість серверів новин, які постійно змінюються, якими може керувати будь-хто, а повідомлення автоматично пересилаються на інші сервери, утворюючи децентралізовану систему. Хоча користувачі рідко платять за доступ безпосередньо до Usenet, наприкінці 2000-х деякі почали платити за комерційні сервери Usenet. Загалом, Usenet не має чіткої економічної моделі протоколу, і користувачі повинні використовувати його через власні транзакції.
Ці протоколи Web1 схожі за архітектурою та походять від однакових значень. Навіть маючи невеликі знання про протоколи, ми можемо зрозуміти, як вони працюють, що показує важливість **розбірливості протоколу Web1 і чітких шаблонів. **Однак ці протоколи поступово зазнавали збоїв або змінювалися з часом. Причини невдачі можна пояснити двома аспектами: по-перше, відсутність специфічних функцій, нездатність конкурувати з конкурентами Web2, по-друге, труднощі з отриманням коштів. Зрештою, успіх протоколу залежить від його спроможності використовувати децентралізований підхід і розробити стійку економічну модель із включенням певних функцій. Підсумовуючи, протокол Web1 можна класифікувати як децентралізований і не має чіткої економічної моделі.
Web2: Централізація та чітка економічна модель
Web2 породив цікаву тенденцію: Reddit замінив такі форуми, як Usenet, а централізовані системи обміну повідомленнями, такі як WhatsApp та iMessage, замінили такі форуми, як IRC. Хоча електронна пошта все ще існує, їй загрожує проблема спаму. Крім того, RSS погано конкурував з Twitter. **Web2 усуває обмеження протоколу Web1 і надає певні функції. ** Електронна пошта та інші децентралізовані протоколи не можуть перевірити легітимність повідомлення, особу відправника, повноваження та економічні відносини, тому робота зі спамом стає проблемою. У незрілих децентралізованих системах відсутність цих функцій дозволяє централізованим конкурентам перевершувати своїх попередників, пропонуючи унікальні функції.
**Протокол Web2 повністю контролюється власником, обмежений лише бізнес-політикою та законодавством. **Щоб стимулювати розвиток протоколу Web1, потрібна більш чітка економічна модель. Однак неможливо досягти чіткої економічної моделі, зберігаючи децентралізацію, без використання децентралізованого консенсусу, перевірених обчислень і інструментів технології шифрування. **Погодження зазвичай переходить від нижнього лівого кута простору дизайну до верхнього правого кута. Іноді протоколи стають де-факто централізованими, наприклад електронна пошта. Оскільки понад 50% електронних листів обробляються централізованими постачальниками послуг електронної пошти, електронна пошта стала дуже централізованою. Електронна пошта відчуває тиск через проблеми зі спамом, відсутність економічної моделі, розподіл витрат на реєстрацію DNS і високі витрати на перемикання.
За відсутності життєздатної економічної моделі електронна пошта може бути стійкою лише як побічний проект великих технологічних компаній. Методи зменшення спаму покладаються на економію масштабу та зв’язування даних, і компаніям, які розміщують мільйони облікових записів електронної пошти, легше виявити аномалії. Крім того, важливим фактором є вартість перемикання. Тепер нам потрібно розпізнати дві ключові централізуючі сили, які впливають на різні компоненти протоколу**, які постійно діють на кожному кроці процесу розробки протоколу, і це мережеві ефекти та витрати на перемикання. **
**Мережеві ефекти — це явище накопичення потужності в міру масштабування системи та її широкого використання. Витрати на перемикання стосуються економічних, когнітивних або часових витрат, необхідних для того, щоб користувачі залишили поточну систему та перейшли на іншу систему. **У прикладі електронної пошти витрати на перехід є критичними для користувачів, які використовують Gmail. Якщо ви використовуєте Gmail, але не маєте власного домену, вартість переходу буде високою. Однак якщо у вас є власне доменне ім’я, ви можете змінити постачальника поштових послуг і продовжувати використовувати будь-якого постачальника послуг для отримання пошти. Компанія може збільшити витрати на перехід за допомогою розробки протоколу, змушуючи або заохочуючи користувачів використовувати певні компоненти, тим самим зменшуючи ймовірність переходу користувачів до інших постачальників.
Візьмемо Reddit, систему, яка дозволяє модераторам в односторонньому порядку контролювати підфоруми, стираючи межу між децентралізацією та централізацією. Хоча дозвіл будь-кому бути модератором можна розглядати як форму децентралізації, вони все одно є повністю централізованими системами, якщо остаточна влада залишається в руках адміністраторів (наприклад, команд Reddit). Високоякісний користувальницький досвід не має нічого спільного з централізованим живленням, але забезпечення високоякісного користувацького досвіду часто вимагає фінансової підтримки. ** В епоху Web1 через брак коштів децентралізовані протоколи часто не можуть забезпечити хорошу взаємодію з користувачем. **Фінансування відіграє важливу роль у забезпеченні високоякісної взаємодії з користувачем.
Web3: децентралізована та чітка економічна модель
На платформі **Web2, як-от Twitter, Facebook, Instagram або TikTok, вибір користувача обмежений залежно від рішень інтерфейсу платформи. **Однак як децентралізовані компоненти, представлені Web3, змінять протокол? Використання технології шифрування та блокчейну може зменшити залежність від довіри, прояснюючи економіку та підтримуючи децентралізацію. **Web3 забезпечує відкритість, взаємодію та відкритий вихідний код із чіткою економічною моделлю та можливістю інтегрувати кошти в протокол для досягнення сталого розвитку та уникнення монополізації всіх цінностей. **
**Як розробник, найкращим вибором буде створення децентралізованої системи з чіткою економічною моделлю. Цей спосіб забезпечує постійне існування системи та розуміє пов’язані з нею економічні відносини, не дозволяючи економічним відносинам розвиватися поза угодою. ** З точки зору стабільності та захоплення цінності, це потрібно розглядати інакше. Вибір створення на основі децентралізованої системи важливий, оскільки це дозволяє уникнути потенційних ризиків і створює проект, який є довговічним і має потенціал стати найбільшою можливою системою.
Побудова Інтернету більше не вважається божевільною поведінкою, оскільки сам Інтернет є повністю децентралізованою системою. Так само використання мов програмування з відкритим кодом і використання веб-браузерів стало міцною основою для побудови амбітних проектів. Будівництво на основі централізованої системи може бути обмежено та перешкодити масштабу та розмаху проекту. Web3 приваблює чудових розробників, які можуть створювати більші та амбітніші проекти. Можуть з’явитися інші системи чи платформи, які можуть конкурувати з існуючою платформою Web2, відповідати нормам і мати конкурентну перевагу, а також жорстко конкурувати з платформою Web2.
Найбільшою проблемою мережі Web2 є її крихкість і надмірно оптимізована бізнес-модель. Ці мережі прагнуть оптимізувати певні показники, ігноруючи речі, не пов’язані з їхніми цілями, що призводить до відсутності інновацій та розробки нових продуктів. Хоча вони мають сильний мережевий вплив, недостатній для формування монополії, вони вразливі до контрзаходів проти своїх слабких місць.
Навпаки, **Web3 забезпечує більш стійкий та інноваційний простір завдяки децентралізації та чіткій економічній моделі. **Подібно до багатої та різноманітної екосистеми тропічного лісу, система Web3 створила інфраструктуру та протоколи, придатні для розробки будь-яких цікавих речей, створюючи більш благодатний ґрунт для інновацій. Використовуючи криптовалюти та економічні моделі токенів, учасники отримують впевненість у тому, що їх креативність і готовність до ризику будуть винагороджені, сприяючи розвитку системи.
Тому **Web3 має кращу стійкість екосистеми та інноваційний потенціал, а не покладається виключно на накопичення економічних ресурсів. **Чітка економічна модель і функції децентралізації дозволяють Web3 досягати інновацій і розвитку в справжньому сенсі, подалі від скрутного становища надмірної оптимізації та централізованого накопичення в одній сфері. Впроваджуючи технологію шифрування та економічну модель токенів, Web3 надає учасникам більший творчий простір і механізм повернення, а також сприяє розвитку системи в більш цінному та тривалому напрямку.
Приклад проектування протоколу Web3
Історія справи та цілі дизайну
Почнемо з цікавого прикладу, «Stable Horde» — безкоштовна система для генерації зображень і протоколу Web2. Він використовує функцію спільного рівня, яка дозволяє користувачам просити інших людей, які бажають допомогти створити зображення. Клієнт надсилає завдання до робочої черги, робочий виконує обробку висновків і надсилає результат до сховища результатів, звідки клієнт може отримати результат і виплатити бали Kudos робочому. У Stable Horde Kudos — це система безкоштовних балів, яка використовується для визначення пріоритетності завдань. Однак, чим довша черга, тим довше потрібно для створення зображення через обмеження надання обчислювальних ресурсів.
Ми зіткнулися з цікавою проблемою: як масштабувати цю систему, щоб зробити її більшою та спеціалізованою, залишаючись відкритою та сумісною, не ризикуючи централізацією зруйнувати оригінальний дух проекту. **Одна з пропозицій полягає в тому, щоб конвертувати результати Kudos у токени ERC20 і записати їх у блокчейн. Однак просте додавання блокчейна може спричинити низку проблем, таких як атаки з помилковими результатами тощо.
Давайте переосмислимо процес розробки протоколу. **Ви завжди повинні починати з чіткої мети, потім розглядати обмеження та, нарешті, визначити механізм. **Розробка системи вимагає визначення цілей і визначення ефективних механізмів. Обмеження бувають в ендогенних і екзогенних формах, і, обмежуючи простір проектування, механізми можна чіткіше визначити. Сутністю протоколу є такі механізми, як кліринг, ціноутворення, ставки, стимули, платежі та перевірка. Проекти повинні відповідати обмеженням і відповідати чітко визначеним цілям.
Приклад протоколу Web3: нестабільний Спантеличеність
Давайте перейдемо до абсолютно нового протоколу Web3 під назвою «Unstable Confusion». Далі ми окреслимо кілька цікавих напрямків, запропонованих у контексті перетворення існуючого протоколу Web2 «Stable Horde» на протокол Web3 «Unstable Confusion».
Як згадувалося раніше, існує проблема з надсиланням неправдивих результатів, тому потрібен механізм, який би гарантував, що користувачі отримають те, що їм потрібно, це називається «підтвердження перевірки». Простіше кажучи, нам потрібно перевірити міркування, щоб переконатися, що його результати відповідають очікуванням. Інша проблема стосується працівників «Стійкої Орди». Працівники запитують наступне завдання з бази даних у тому порядку, у якому їх запитували, і призначають завдання працівнику, який зробив запит раніше. Але в системі, де задіяні гроші, працівники можуть вимагати виконання великої кількості завдань, щоб отримати більше грошей, але насправді не мають наміру їх виконувати. Вони можуть конкурувати за низьку затримку, захоплювати завдання та спричиняти перевантаження системи. **
Для вирішення вищезазначених проблем пропонуються деякі рішення. Перший — «Оплата пропорційна внеску», де працівники отримують платню відповідно до їх внеску, змагаючись за виконання завдань у спосіб, який є вигідним для мережі. По-друге, «гнучка участь», тобто працівники можуть вільно приєднуватися або виходити з системи за нижчою ціною, залучаючи більше учасників. Нарешті «Низька затримка», тобто те, наскільки швидко реагує програма, має вирішальне значення для взаємодії з користувачем. ** Повертаючись до нашої мети, створити децентралізований, сумісний ринок для створення зображень. Хоча ми все ще маємо деякі ключові обмеження, їх можна буде додати, змінити або деталізувати більш конкретні деталі пізніше. Тепер ми можемо оцінити здійсненність різних механізмів.
Потенційна конструкція механізму
1. Механізм перевірки
Ми можемо використовувати такі методи, як теорія ігор і криптографія, щоб забезпечити точність міркувань. Механізми теорії ігор можуть бути використані в системах вирішення суперечок, де користувачі можуть передавати суперечки на ескалацію та приймати участь у певних ролях. Іншим підходом є безперервний або вибірковий аудит, який полягає в перегляді роботи працівників, забезпеченні призначення завдань різним працівникам і записі, які працівники пройшли перевірку. Докази з нульовим знанням у криптографії можуть генерувати ефективні докази для перевірки правильності міркувань. Традиційні методи включають надійні сторонні установи та відгуки користувачів, але існують ризики централізації та мережеві ефекти.
Інші можливі механізми перевірки включають те, що кілька працівників виконують те саме завдання, а користувач вибирає з результатів. Це може бути дорогим, але якщо вартість досить низька, це можна вважати підходом.
2. Цінова стратегія
Що стосується стратегії ціноутворення, книга замовлень може бути створена в мережі. Також можна використовувати проксі-метрики обчислювальних ресурсів, які можна перевірити в мережі, наприклад газ. Цей підхід відрізняється від простого вільного ринку, де користувачі просто публікують, скільки вони готові заплатити за висновки, які працівники можуть прийняти, або вони можуть робити ставки, щоб конкурувати за завдання. Натомість користувачі можуть створити проксі-метрику, подібну до газу, де конкретний висновок вимагає певної кількості обчислювальних ресурсів, а кількість обчислювальних ресурсів безпосередньо визначає ціну. Таким чином можна спростити роботу всього механізму.
Крім того, можна використовувати книгу замовлень поза ланцюгом, яка є менш дорогою у використанні та потенційно дуже ефективною. Однак проблема полягає в тому, що той, хто володіє цією книгою замовлень, може зосередити мережевий ефект на собі.
3. Механізм зберігання
Механізм зберігання дуже важливий для того, щоб результати роботи могли бути доставлені користувачеві правильно, але важко зменшити ризик довіри та довести, що робота була доставлена правильно. Користувачі можуть запитувати, чи було доставлено товар, подібно до того, як скаржитися на неотримання очікуваного товару. Аудиторам може знадобитися перевірити процес розрахунку та перевірити точність вихідних результатів. Тому вихідні дані мають бути видимими для протоколу та зберігатися там, де протокол може отримати до них доступ.
Що стосується механізму зберігання, у нас є кілька варіантів. Перший – зберігати дані в ланцюжку, але це дорого. Іншим варіантом є використання спеціальної мережі шифрування сховищ, яка є складнішою, але намагається вирішити проблему одноранговим способом. Крім того, існує можливість зберігати дані поза мережею, але це викликає інші проблеми, оскільки той, хто контролює цю систему зберігання, може впливати на інші аспекти, такі як процес перевірки та передача остаточного платежу.
4. Стратегія розподілу завдань
Також необхідно враховувати спосіб розподілу завдань, що є відносно складною сферою. Можна вважати, що працівник самостійно вибирає завдання після його подання, або угода розподіляє завдання після подання завдання, і також можна дозволити користувачеві або кінцевому користувачеві вибрати конкретного працівника. У кожного підходу є плюси та мінуси, а також розгляньте комбінацію способів, якими протокол вирішує, які працівники можуть запитувати які завдання.
Розподіл завдань передбачає багато цікавих деталей. Наприклад, у системі, що базується на протоколі, йому потрібно знати, чи працівник онлайн і доступний, щоб вирішити, чи призначати йому завдання. Також потрібно знати потужність і навантаження кожного працівника. Тому в протоколі необхідно враховувати різні додаткові фактори, які, можливо, не були включені в початкову просту реалізацію.
Ключові моменти розробки децентралізованого протоколу
7 ключових елементів дизайну, які можуть призвести до ризику централізації
До них належать імена простору, запроваджені електронною поштою, платіжні системи, репутація та зберігання, відповідність, системи ціноутворення та системи перевірки. Ці елементи можуть стати централізованими через вплив мережі або високу вартість перемикання. Керуйте протоколом, пом’якшуючи накопичення мережевих ефектів, направляючи мережеві ефекти в протокол і створюючи децентралізований контрольний рівень у протоколі, щоб забезпечити довгострокову працездатність системи. Децентралізований контроль може бути досягнутий за допомогою мінливих токенів або інших механізмів управління, таких як системи репутації або механізми ротації виборів.
Зменшіть витрати на перемикання та сприяйте взаємодії
Щоб заохотити підприємців створювати додатки в системі, важливо зменшити витрати на перемикання та сприяти взаємодії між різними системами. Уникайте введення високих витрат на перехід і зменшіть надмірну залежність від книг замовлень поза мережею або сторонніх систем перевірки.
Використання технології Web3 для створення децентралізованої системи
Використовуйте інструменти та принципи Web3 для розробки систем, які розширюють можливості підприємців і уникають надмірної централізації. Протоколи, які охоплюють принципи Web3, як правило, мають більший масштаб, довший термін служби та більш активну екосистему, забезпечуючи плідні області для інноваційних досліджень за межами, встановленими найбільшими лідерами.
Глибоке дослідження та вибір найкращого рішення
При розробці протоколу та визначенні стратегії необхідно глибоко вивчити різні аспекти. Для автентифікації найкращим вибором є криптографічні рішення. З точки зору ціноутворення, проксі-метрики, що використовують обчислювальні ресурси, які можна перевірити в ланцюжку, можна адаптувати до різноманітних завдань логічного висновку або машинного навчання. З точки зору призначення завдань, протокол для оновлення можливостей і статусу працівників у режимі реального часу приймається для справедливого розподілу завдань і дозволяє працівникам самостійно вирішувати, чи приймати завдання. Для проблем зберігання можна розглянути такі рішення, як технологія сегментування прототипів, щоб вирішити проблеми за короткий проміжок часу та застосувати тимчасові методи зберігання.
Під час проектування децентралізованої системи наведені вище міркування можуть допомогти створити систему з довгостроковою надійністю та властивостями децентралізації.
Оригінал: Дизайн протоколу: Чому і як
Посилання на повнотекстовий переклад:
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
a16z Курс підприємництва з шифрування: після «Розробки маркерів» запускається «Розробка протоколу»
Автор Едді Лазарін
Збірка: Сіссі
Вступ:
**a16z зайняв важливу позицію в галузі шифрування, щоб керувати розвитком галузі завдяки своїм глибоким статтям, надаючи нам вказівки, необхідні для когнітивного вдосконалення та трансформації. Останнім часом a16z зосереджується на проблемах, що виходять за межі економіки токенів. Він розпочався з розмови на тему «Дизайн токенів», потім пішла «Токенологія: за межами економіки токенів», а тепер довгоочікуваний курс «Дизайн протоколів». Як лектор курсу, Едді Лазарін, технічний директор a16z crypto, неодноразово підкреслював, що ключ до виходу з економіки токенів лежить у дизайні протоколу, а дизайн токенів є лише допоміжним засобом. У цьому курсі, присвяченому розробці протоколів, він ділився більше години, приносячи цінну інформацію та просвітництво підприємцям, допомагаючи їм глибше зрозуміти ключову роль дизайну протоколу в успіху проекту. Ця стаття є спрощеним варіантом перекладу. Для отримання більш захоплюючого вмісту перегляньте посилання на повнотекстову версію перекладу. **
Внутрішні закони еволюції протоколу
Інтернет-протокол: зв’язок взаємодії
Інтернет — це мережа протоколів, що включає різні типи протоколів. Деякі протоколи є короткими, як-от діаграма стану HTTP, а інші досить складні, як-от діаграма взаємодії протоколу Maker. На малюнку нижче показані різні протоколи, включаючи Інтернет-протоколи, фізичні протоколи та політичні протоколи. Зліва на зображенні нижче ми бачимо інтерактивну карту перехрестя вулиць, яка здається нам знайомою та цікавою.
Спільним для цих протоколів є те, що всі вони є формалізованими інтерактивними системами, які сприяють складній груповій поведінці, яка є основним компонентом протоколу. Потужність Інтернет-протоколу полягає в його здатності з’єднувати не лише взаємодію між людьми, але й програмне забезпечення. Ми знаємо, що програмне забезпечення дуже адаптивне та ефективне, здатне інтегрувати механізми. Таким чином, Інтернет-протокол, можливо, є одним із наших найважливіших, якщо не найважливішим, типів протоколів.
Розвиток протоколу: Web1 - Web2 - Web3
На діаграмі нижче горизонтальна вісь відображає ступінь децентралізації та централізації протоколу, тобто ступінь контролю над протоколом. На вертикальній осі є узгоджена економічна модель, конкретно вказуючи на те, чи є економічна модель явною чи невизначеною. Ця відмінність може здатися ледве помітною, але вона має важливі наслідки.
Web1: децентралізовано та немає чіткої економічної моделі
Протоколи періоду Web1 (такі як NNTP, IRC, SMTP і RSS) були нейтральними з точки зору потоку вартості, власності, прав доступу та механізмів оплати, без чіткої економічної моделі. Серед них Usenet — це протокол, схожий на сучасний Reddit для обміну публікаціями та файлами. IRC був раннім і широко використовуваним протоколом чату, а SMTP і RSS використовувалися для електронної пошти та підписки на вміст.
Usenet — це організована таксономія платформа, яка дозволяє користувачам публікувати відповідний вміст на підсерверах певних категорій. Це була важлива частина ранньої інтернет-культури та існувала поза HTTP. Для використання Usenet потрібен певний клієнт і постачальник послуг Інтернету (ISP), який підтримує Usenet. Usenet поширюється на велику кількість серверів новин, які постійно змінюються, якими може керувати будь-хто, а повідомлення автоматично пересилаються на інші сервери, утворюючи децентралізовану систему. Хоча користувачі рідко платять за доступ безпосередньо до Usenet, наприкінці 2000-х деякі почали платити за комерційні сервери Usenet. Загалом, Usenet не має чіткої економічної моделі протоколу, і користувачі повинні використовувати його через власні транзакції.
Ці протоколи Web1 схожі за архітектурою та походять від однакових значень. Навіть маючи невеликі знання про протоколи, ми можемо зрозуміти, як вони працюють, що показує важливість **розбірливості протоколу Web1 і чітких шаблонів. **Однак ці протоколи поступово зазнавали збоїв або змінювалися з часом. Причини невдачі можна пояснити двома аспектами: по-перше, відсутність специфічних функцій, нездатність конкурувати з конкурентами Web2, по-друге, труднощі з отриманням коштів. Зрештою, успіх протоколу залежить від його спроможності використовувати децентралізований підхід і розробити стійку економічну модель із включенням певних функцій. Підсумовуючи, протокол Web1 можна класифікувати як децентралізований і не має чіткої економічної моделі.
Web2: Централізація та чітка економічна модель
Web2 породив цікаву тенденцію: Reddit замінив такі форуми, як Usenet, а централізовані системи обміну повідомленнями, такі як WhatsApp та iMessage, замінили такі форуми, як IRC. Хоча електронна пошта все ще існує, їй загрожує проблема спаму. Крім того, RSS погано конкурував з Twitter. **Web2 усуває обмеження протоколу Web1 і надає певні функції. ** Електронна пошта та інші децентралізовані протоколи не можуть перевірити легітимність повідомлення, особу відправника, повноваження та економічні відносини, тому робота зі спамом стає проблемою. У незрілих децентралізованих системах відсутність цих функцій дозволяє централізованим конкурентам перевершувати своїх попередників, пропонуючи унікальні функції.
**Протокол Web2 повністю контролюється власником, обмежений лише бізнес-політикою та законодавством. **Щоб стимулювати розвиток протоколу Web1, потрібна більш чітка економічна модель. Однак неможливо досягти чіткої економічної моделі, зберігаючи децентралізацію, без використання децентралізованого консенсусу, перевірених обчислень і інструментів технології шифрування. **Погодження зазвичай переходить від нижнього лівого кута простору дизайну до верхнього правого кута. Іноді протоколи стають де-факто централізованими, наприклад електронна пошта. Оскільки понад 50% електронних листів обробляються централізованими постачальниками послуг електронної пошти, електронна пошта стала дуже централізованою. Електронна пошта відчуває тиск через проблеми зі спамом, відсутність економічної моделі, розподіл витрат на реєстрацію DNS і високі витрати на перемикання.
За відсутності життєздатної економічної моделі електронна пошта може бути стійкою лише як побічний проект великих технологічних компаній. Методи зменшення спаму покладаються на економію масштабу та зв’язування даних, і компаніям, які розміщують мільйони облікових записів електронної пошти, легше виявити аномалії. Крім того, важливим фактором є вартість перемикання. Тепер нам потрібно розпізнати дві ключові централізуючі сили, які впливають на різні компоненти протоколу**, які постійно діють на кожному кроці процесу розробки протоколу, і це мережеві ефекти та витрати на перемикання. **
**Мережеві ефекти — це явище накопичення потужності в міру масштабування системи та її широкого використання. Витрати на перемикання стосуються економічних, когнітивних або часових витрат, необхідних для того, щоб користувачі залишили поточну систему та перейшли на іншу систему. **У прикладі електронної пошти витрати на перехід є критичними для користувачів, які використовують Gmail. Якщо ви використовуєте Gmail, але не маєте власного домену, вартість переходу буде високою. Однак якщо у вас є власне доменне ім’я, ви можете змінити постачальника поштових послуг і продовжувати використовувати будь-якого постачальника послуг для отримання пошти. Компанія може збільшити витрати на перехід за допомогою розробки протоколу, змушуючи або заохочуючи користувачів використовувати певні компоненти, тим самим зменшуючи ймовірність переходу користувачів до інших постачальників.
Візьмемо Reddit, систему, яка дозволяє модераторам в односторонньому порядку контролювати підфоруми, стираючи межу між децентралізацією та централізацією. Хоча дозвіл будь-кому бути модератором можна розглядати як форму децентралізації, вони все одно є повністю централізованими системами, якщо остаточна влада залишається в руках адміністраторів (наприклад, команд Reddit). Високоякісний користувальницький досвід не має нічого спільного з централізованим живленням, але забезпечення високоякісного користувацького досвіду часто вимагає фінансової підтримки. ** В епоху Web1 через брак коштів децентралізовані протоколи часто не можуть забезпечити хорошу взаємодію з користувачем. **Фінансування відіграє важливу роль у забезпеченні високоякісної взаємодії з користувачем.
Web3: децентралізована та чітка економічна модель
На платформі **Web2, як-от Twitter, Facebook, Instagram або TikTok, вибір користувача обмежений залежно від рішень інтерфейсу платформи. **Однак як децентралізовані компоненти, представлені Web3, змінять протокол? Використання технології шифрування та блокчейну може зменшити залежність від довіри, прояснюючи економіку та підтримуючи децентралізацію. **Web3 забезпечує відкритість, взаємодію та відкритий вихідний код із чіткою економічною моделлю та можливістю інтегрувати кошти в протокол для досягнення сталого розвитку та уникнення монополізації всіх цінностей. **
**Як розробник, найкращим вибором буде створення децентралізованої системи з чіткою економічною моделлю. Цей спосіб забезпечує постійне існування системи та розуміє пов’язані з нею економічні відносини, не дозволяючи економічним відносинам розвиватися поза угодою. ** З точки зору стабільності та захоплення цінності, це потрібно розглядати інакше. Вибір створення на основі децентралізованої системи важливий, оскільки це дозволяє уникнути потенційних ризиків і створює проект, який є довговічним і має потенціал стати найбільшою можливою системою.
Побудова Інтернету більше не вважається божевільною поведінкою, оскільки сам Інтернет є повністю децентралізованою системою. Так само використання мов програмування з відкритим кодом і використання веб-браузерів стало міцною основою для побудови амбітних проектів. Будівництво на основі централізованої системи може бути обмежено та перешкодити масштабу та розмаху проекту. Web3 приваблює чудових розробників, які можуть створювати більші та амбітніші проекти. Можуть з’явитися інші системи чи платформи, які можуть конкурувати з існуючою платформою Web2, відповідати нормам і мати конкурентну перевагу, а також жорстко конкурувати з платформою Web2.
Найбільшою проблемою мережі Web2 є її крихкість і надмірно оптимізована бізнес-модель. Ці мережі прагнуть оптимізувати певні показники, ігноруючи речі, не пов’язані з їхніми цілями, що призводить до відсутності інновацій та розробки нових продуктів. Хоча вони мають сильний мережевий вплив, недостатній для формування монополії, вони вразливі до контрзаходів проти своїх слабких місць.
Навпаки, **Web3 забезпечує більш стійкий та інноваційний простір завдяки децентралізації та чіткій економічній моделі. **Подібно до багатої та різноманітної екосистеми тропічного лісу, система Web3 створила інфраструктуру та протоколи, придатні для розробки будь-яких цікавих речей, створюючи більш благодатний ґрунт для інновацій. Використовуючи криптовалюти та економічні моделі токенів, учасники отримують впевненість у тому, що їх креативність і готовність до ризику будуть винагороджені, сприяючи розвитку системи.
Тому **Web3 має кращу стійкість екосистеми та інноваційний потенціал, а не покладається виключно на накопичення економічних ресурсів. **Чітка економічна модель і функції децентралізації дозволяють Web3 досягати інновацій і розвитку в справжньому сенсі, подалі від скрутного становища надмірної оптимізації та централізованого накопичення в одній сфері. Впроваджуючи технологію шифрування та економічну модель токенів, Web3 надає учасникам більший творчий простір і механізм повернення, а також сприяє розвитку системи в більш цінному та тривалому напрямку.
Приклад проектування протоколу Web3
Історія справи та цілі дизайну
Почнемо з цікавого прикладу, «Stable Horde» — безкоштовна система для генерації зображень і протоколу Web2. Він використовує функцію спільного рівня, яка дозволяє користувачам просити інших людей, які бажають допомогти створити зображення. Клієнт надсилає завдання до робочої черги, робочий виконує обробку висновків і надсилає результат до сховища результатів, звідки клієнт може отримати результат і виплатити бали Kudos робочому. У Stable Horde Kudos — це система безкоштовних балів, яка використовується для визначення пріоритетності завдань. Однак, чим довша черга, тим довше потрібно для створення зображення через обмеження надання обчислювальних ресурсів.
Ми зіткнулися з цікавою проблемою: як масштабувати цю систему, щоб зробити її більшою та спеціалізованою, залишаючись відкритою та сумісною, не ризикуючи централізацією зруйнувати оригінальний дух проекту. **Одна з пропозицій полягає в тому, щоб конвертувати результати Kudos у токени ERC20 і записати їх у блокчейн. Однак просте додавання блокчейна може спричинити низку проблем, таких як атаки з помилковими результатами тощо.
Давайте переосмислимо процес розробки протоколу. **Ви завжди повинні починати з чіткої мети, потім розглядати обмеження та, нарешті, визначити механізм. **Розробка системи вимагає визначення цілей і визначення ефективних механізмів. Обмеження бувають в ендогенних і екзогенних формах, і, обмежуючи простір проектування, механізми можна чіткіше визначити. Сутністю протоколу є такі механізми, як кліринг, ціноутворення, ставки, стимули, платежі та перевірка. Проекти повинні відповідати обмеженням і відповідати чітко визначеним цілям.
Давайте перейдемо до абсолютно нового протоколу Web3 під назвою «Unstable Confusion». Далі ми окреслимо кілька цікавих напрямків, запропонованих у контексті перетворення існуючого протоколу Web2 «Stable Horde» на протокол Web3 «Unstable Confusion».
Як згадувалося раніше, існує проблема з надсиланням неправдивих результатів, тому потрібен механізм, який би гарантував, що користувачі отримають те, що їм потрібно, це називається «підтвердження перевірки». Простіше кажучи, нам потрібно перевірити міркування, щоб переконатися, що його результати відповідають очікуванням. Інша проблема стосується працівників «Стійкої Орди». Працівники запитують наступне завдання з бази даних у тому порядку, у якому їх запитували, і призначають завдання працівнику, який зробив запит раніше. Але в системі, де задіяні гроші, працівники можуть вимагати виконання великої кількості завдань, щоб отримати більше грошей, але насправді не мають наміру їх виконувати. Вони можуть конкурувати за низьку затримку, захоплювати завдання та спричиняти перевантаження системи. **
Для вирішення вищезазначених проблем пропонуються деякі рішення. Перший — «Оплата пропорційна внеску», де працівники отримують платню відповідно до їх внеску, змагаючись за виконання завдань у спосіб, який є вигідним для мережі. По-друге, «гнучка участь», тобто працівники можуть вільно приєднуватися або виходити з системи за нижчою ціною, залучаючи більше учасників. Нарешті «Низька затримка», тобто те, наскільки швидко реагує програма, має вирішальне значення для взаємодії з користувачем. ** Повертаючись до нашої мети, створити децентралізований, сумісний ринок для створення зображень. Хоча ми все ще маємо деякі ключові обмеження, їх можна буде додати, змінити або деталізувати більш конкретні деталі пізніше. Тепер ми можемо оцінити здійсненність різних механізмів.
Потенційна конструкція механізму
1. Механізм перевірки
Ми можемо використовувати такі методи, як теорія ігор і криптографія, щоб забезпечити точність міркувань. Механізми теорії ігор можуть бути використані в системах вирішення суперечок, де користувачі можуть передавати суперечки на ескалацію та приймати участь у певних ролях. Іншим підходом є безперервний або вибірковий аудит, який полягає в перегляді роботи працівників, забезпеченні призначення завдань різним працівникам і записі, які працівники пройшли перевірку. Докази з нульовим знанням у криптографії можуть генерувати ефективні докази для перевірки правильності міркувань. Традиційні методи включають надійні сторонні установи та відгуки користувачів, але існують ризики централізації та мережеві ефекти.
Інші можливі механізми перевірки включають те, що кілька працівників виконують те саме завдання, а користувач вибирає з результатів. Це може бути дорогим, але якщо вартість досить низька, це можна вважати підходом.
2. Цінова стратегія
Що стосується стратегії ціноутворення, книга замовлень може бути створена в мережі. Також можна використовувати проксі-метрики обчислювальних ресурсів, які можна перевірити в мережі, наприклад газ. Цей підхід відрізняється від простого вільного ринку, де користувачі просто публікують, скільки вони готові заплатити за висновки, які працівники можуть прийняти, або вони можуть робити ставки, щоб конкурувати за завдання. Натомість користувачі можуть створити проксі-метрику, подібну до газу, де конкретний висновок вимагає певної кількості обчислювальних ресурсів, а кількість обчислювальних ресурсів безпосередньо визначає ціну. Таким чином можна спростити роботу всього механізму.
Крім того, можна використовувати книгу замовлень поза ланцюгом, яка є менш дорогою у використанні та потенційно дуже ефективною. Однак проблема полягає в тому, що той, хто володіє цією книгою замовлень, може зосередити мережевий ефект на собі.
3. Механізм зберігання
Механізм зберігання дуже важливий для того, щоб результати роботи могли бути доставлені користувачеві правильно, але важко зменшити ризик довіри та довести, що робота була доставлена правильно. Користувачі можуть запитувати, чи було доставлено товар, подібно до того, як скаржитися на неотримання очікуваного товару. Аудиторам може знадобитися перевірити процес розрахунку та перевірити точність вихідних результатів. Тому вихідні дані мають бути видимими для протоколу та зберігатися там, де протокол може отримати до них доступ.
Що стосується механізму зберігання, у нас є кілька варіантів. Перший – зберігати дані в ланцюжку, але це дорого. Іншим варіантом є використання спеціальної мережі шифрування сховищ, яка є складнішою, але намагається вирішити проблему одноранговим способом. Крім того, існує можливість зберігати дані поза мережею, але це викликає інші проблеми, оскільки той, хто контролює цю систему зберігання, може впливати на інші аспекти, такі як процес перевірки та передача остаточного платежу.
4. Стратегія розподілу завдань
Також необхідно враховувати спосіб розподілу завдань, що є відносно складною сферою. Можна вважати, що працівник самостійно вибирає завдання після його подання, або угода розподіляє завдання після подання завдання, і також можна дозволити користувачеві або кінцевому користувачеві вибрати конкретного працівника. У кожного підходу є плюси та мінуси, а також розгляньте комбінацію способів, якими протокол вирішує, які працівники можуть запитувати які завдання.
Розподіл завдань передбачає багато цікавих деталей. Наприклад, у системі, що базується на протоколі, йому потрібно знати, чи працівник онлайн і доступний, щоб вирішити, чи призначати йому завдання. Також потрібно знати потужність і навантаження кожного працівника. Тому в протоколі необхідно враховувати різні додаткові фактори, які, можливо, не були включені в початкову просту реалізацію.
Ключові моменти розробки децентралізованого протоколу
7 ключових елементів дизайну, які можуть призвести до ризику централізації
До них належать імена простору, запроваджені електронною поштою, платіжні системи, репутація та зберігання, відповідність, системи ціноутворення та системи перевірки. Ці елементи можуть стати централізованими через вплив мережі або високу вартість перемикання. Керуйте протоколом, пом’якшуючи накопичення мережевих ефектів, направляючи мережеві ефекти в протокол і створюючи децентралізований контрольний рівень у протоколі, щоб забезпечити довгострокову працездатність системи. Децентралізований контроль може бути досягнутий за допомогою мінливих токенів або інших механізмів управління, таких як системи репутації або механізми ротації виборів.
Зменшіть витрати на перемикання та сприяйте взаємодії
Щоб заохотити підприємців створювати додатки в системі, важливо зменшити витрати на перемикання та сприяти взаємодії між різними системами. Уникайте введення високих витрат на перехід і зменшіть надмірну залежність від книг замовлень поза мережею або сторонніх систем перевірки.
Використання технології Web3 для створення децентралізованої системи
Використовуйте інструменти та принципи Web3 для розробки систем, які розширюють можливості підприємців і уникають надмірної централізації. Протоколи, які охоплюють принципи Web3, як правило, мають більший масштаб, довший термін служби та більш активну екосистему, забезпечуючи плідні області для інноваційних досліджень за межами, встановленими найбільшими лідерами.
Глибоке дослідження та вибір найкращого рішення
При розробці протоколу та визначенні стратегії необхідно глибоко вивчити різні аспекти. Для автентифікації найкращим вибором є криптографічні рішення. З точки зору ціноутворення, проксі-метрики, що використовують обчислювальні ресурси, які можна перевірити в ланцюжку, можна адаптувати до різноманітних завдань логічного висновку або машинного навчання. З точки зору призначення завдань, протокол для оновлення можливостей і статусу працівників у режимі реального часу приймається для справедливого розподілу завдань і дозволяє працівникам самостійно вирішувати, чи приймати завдання. Для проблем зберігання можна розглянути такі рішення, як технологія сегментування прототипів, щоб вирішити проблеми за короткий проміжок часу та застосувати тимчасові методи зберігання.
Під час проектування децентралізованої системи наведені вище міркування можуть допомогти створити систему з довгостроковою надійністю та властивостями децентралізації.
Оригінал: Дизайн протоколу: Чому і як
Посилання на повнотекстовий переклад: