Нещодавно я бачив інтерв’ю на a16z, тема дуже прямо сформульована: чому відкриті мережі завжди перемагають (Why open networks win). Обговорювалася реальна проблема: якщо ви створюєте глобальну мережу, в кінцевому підсумку вам потрібно вирішити не продуктивність, а довіру.
Головним героєм цього інтерв’ю був Christian Catalini. Він раніше був ключовим учасником Libra і засновником Lightspark. У записі він сказав дуже гостру, але точну фразу: якщо ви хочете реформувати валютну систему, ніхто не довірятиме вашому корпораційному ланцюгу (Corp chain). Corp chain — це контроль, оновлення та розподіл прибутку, зосереджені в одній компанії або альянсі, що також сприяє припущенню, що вона служить внутрішнім інтересам.
Багато людей звинувачують у провалі Libra регулювання, але Christian пропонує іншу “правду”. Він зазначає, що регулювання дійсно має великий вплив, але це не єдина проблема. Головне — ринок ніколи не вірив, що одна компанія може створити “нейтральну валютну мережу”. Навіть якщо ви створите асоціацію для управління, навіть якщо CEO працює незалежно, зовнішній світ зробить один і той самий висновок: якщо головний гравець зникне, мережа втратить кров. Цей висновок по суті не спрямований проти Facebook, а проти організаційної форми “корпоративного ланцюга”.
Тому він дедалі більше схиляється до Bitcoin. Він вважає, що Bitcoin не є “найсучаснішим” технічним рішенням, розробка на Bitcoin — це болісний процес, ніби будувати машину у космосі. Але у нього є один фактор, який важко скопіювати: нейтральність, яка підтверджена історією. Засновники зникають, мережа стає без дозволу, правила важко переписати односторонньо, управління важко захопити однією точкою. Саме тому він може нести “глобальний перехід цінностей” і вимоги високої довіри. Ця логіка переводить дискусію з “якщо код хороший” у “хто може бути довіреним”.
У цьому інтерв’ю Christian також запропонував більш комерційний підхід: найбільший парадокс корпоративних ланцюгів у тому, що ви ніколи не переконаєте “другу за значущістю” компанію приєднатися до вашої мережі. Наприклад, якщо ви — найбільша платіжна компанія, чому друга за розміром компанія має довірити вам своє життя? Або, якщо ви — емітент стабільної монети, чому партнери мають вірити, що ви не розширитеся вниз по ланцюгу і не поглинете прибуткові потоки? Це питання часто виникає у Web2. Як тільки мережа починає отримувати прибуток, контролюючі сторони мають стимул максимізувати його.
Тому Christian дає таку оцінку: у короткостроковій перспективі можуть з’явитися нові закриті мережі, можливо навіть період “домінування корпоративних ланцюгів”. Але у довгостроковій перспективі гроші завжди будуть текти у відкриті мережі.
Ця дискусія також нагадала мені статтю, яку я раніше писав — «Обговорення запуску Web3: чи потрібно відкривати код у криптопроектах?». Там я зосереджувався на двох силах: відкритий код створює довіру, але також несе ризик копіювання; відкритий код — основа Web3, але не всі команди можуть дозволити собі повністю відкритий підхід. Також я наводив приклад Uniswap і SushiSwap, показуючи, що копіювання — не рідкість, а бар’єри входу не обов’язково зводяться лише до коду.
Цього разу a16z додало глибший аспект: воно переосмислює “відкритий код” як щось подібне до заяви про нейтральність. Але насправді, навіть якщо команда опублікує код, це не автоматично робить її нейтральною. При оцінці нейтральності ринок дивиться не на GitHub, а на контроль.
Що таке нейтральність і як її досягти? Portal Labs пропонує розбити цю ідею на три більш операційні виміри:
- Правила нейтральні
Правила нейтральні стосуються можливості одностороннього переписування ключових правил. Вартість протоколу, розрахунки, заморожування, дозволи, оновлення — якщо ці положення можна змінити кількома особами, їх важко вважати громадською інфраструктурою. Нейтральність правил не означає, що їх зовсім не можна оновлювати. Вона означає, що право оновлення має обмеження і ці обмеження можна зовнішньо контролювати. Відповідає на питання: “Чи можу я змінити правила в будь-який момент?”
- Нейтральність доступу
Нейтральність доступу стосується того, чи не обмежує вас ваша екосистема. Чи потрібно дозволу для інтеграції, чи можна відкликати інтерфейси, чи потрібно схвалення для вузлів або валідаторів, чи доступ до ключових ресурсів відкритий лише для власної компанії. Це визначає, чи є мережа публічною дорогою чи приватним районом. Нейтральність доступу не означає відсутність бар’єрів, але означає, що бар’єри не можна штучно підвищувати однією стороною. Відповідає на питання: “Чи можуть інші вільно приєднатися?”
- Нейтральність інтересів
Нейтральність інтересів стосується розподілу цінностей і того, чи не буде він зосереджений у руках контролюючих. Чи можете ви через дозволи спрямовувати транзакції до власних продуктів, змінювати розподіл прибутку у критичний момент, надавати особливі умови окремим партнерам, концентрувати прибутки у грошовому потоці компанії. Якщо відповідь “так” часто, ринок вважає вас платформою, а не мережею. Відповідає на питання: “Чи перетворюєш ти мережу на грошову машину?”
У практиці ці три стандарти зводяться до одного — оцінки Web3-проекту: чи ти створюєш “децентралізований продукт” чи “децентралізовану мережу”? Продукт орієнтований на ефективність і контроль. Мережа — на надійність і можливість приєднання. Обидва можуть співіснувати, але пріоритети різні. Головне для Web3-стартапу — визначити позицію і потім вирішити питання нейтральності та відкритого коду.
Для цього Portal Labs пропонує простий набір питань для самоперевірки:
Q1: Чи дозволяє ваша система будь-кому без дозволу інтегруватися і запускатися?
Якщо ні — ви ближче до продукту. Це швидко відсіює багато “псевдо-мереж”.
Q2: Чи існують у вашому протоколі односторонні екстрені кнопки, наприклад, заморожування, відкат, примусове оновлення?
Якщо так — потрібно пояснити, як ці повноваження обмежені. Це відповідає правилу нейтральності.
Q3: Чи залежить ваш екосистемний вхід від єдиного інтерфейсу або порядку?
Якщо так — ви створюєте платформу. Це відповідає准入中立.
Q4: Чи дозволяєте конкурентам заробляти у вашій системі і не пригнічуєте їх правилами?
Якщо ні — ви не можете бути громадською мережею. Це відповідає利益中立.
Коли на ці питання є відповіді, відкритий код стає більш раціональним технічним рішенням. Звісно, відкритий код має свої рівні — він не обов’язково має бути двовибірним.
Перший рівень — перевірене відкриття. Команда публікує ключові контракти і безпековий код для аудиту і відтворення. Це вирішує проблему прозорості і підвищує довіру, але не означає відмову від бізнес-контролю. Багато інструментальних продуктів зупиняються на цьому рівні. Це відповідає “Я хочу, щоб інші повірили, що я не зробив погано”.
Другий рівень — можливість замінити відкритий код. Команда дозволяє стороннім форкати і запускати, не закриваючи ключові операційні права у себе. Це створює конкуренцію і підвищує стійкість до цензури. Це відповідає “Я не залежу від монополії на управління”.
Третій рівень — можливість вийти з відкритого коду. Команда поступово делегує оновлення і управління, роблячи себе менш важливою у структурі. Bitcoin — крайній приклад, але у реальності є і проміжні варіанти. Ethereum все ще потребує координації і аудиту, але його управління — це довгостроковий еволюційний процес, а не статут компанії. Відкрита мережа — не відсутність управління, а управління, яке не належить конкретній компанії.
Обговорення відкритих мереж, здавалося б, — про відкриття коду, але по суті — про нейтральність. Якщо контроль зосереджений, друга за значущістю компанія не приєднається, екосистема не стане громадською базою, і система в кінцевому підсумку залишиться у вигляді продукту.
Тому для Web3-стартапів відкритий код — це стратегічний вибір. Наскільки ви готові його відкривати, які повноваження передаєте, скільки ризиків берете — все це визначає, чи створюєте ви платформу чи відкриту мережу.
Зрозумівши це, питання відкритого коду стає простішим: ви не вирішуєте “відкрити чи ні”, а — “стати мережею чи ні”.
