В сознании разработчика блокчейна: кризис управления

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

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

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

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

Proof-of-work – это механизм, позволяющий свести к минимуму непереносимость византийских ошибок – доказать, что BFT не так просто, как люди любят притворяться. Это не система управления. Биткойну не нужна система управления, потому что это не универсальный компьютер. Причина, по которой компьютеры общего назначения нуждаются в системе управления, заключается в том, что компьютеры нуждаются в обновлении.

Нет необходимости в более четких доказательствах, чем масштаб изменений, запланированных для Ethereum 2.0, и агрессивная пропаганда принятия необходимых хард-форков. Мы не первые, кто указывает на эту проблему. Основатели Tezos точно спрогнозировали эту проблему, но в конечном итоге им не удалось предоставить протокол, удовлетворяющий потребности большинства разработчиков, по следующим причинам:

1. Блокчейн написан на другом языке, чем смарт-контракты.
2. Они представили политический процесс, в котором принятие решений происходит вне сети.
3. Они не смогли предоставить явный путь обновления в цепочке.
4. Им не удалось установить отдельные классы, которые могли бы действовать как сдержки и противовесы.

Умные умные контракты

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

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

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

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

Проверки и противовесы

Принято считать, что в любой экономике существуют три основных фактора производства: земля (инфраструктура), рабочая сила и капитал. Каждый крупный блокчейн признает только один класс: капитал. В цепочках PoW те, у кого больше всего капитала, покупают большинство ASIC и определяют, какие обновления могут быть выполнены. В цепях доказательства доли владения и делегированного доказательства доли владения контроль со стороны капитала более прямой.

В дополнение к тому, что на первый взгляд проблематично, отсутствие каких-либо других классов, которые могли бы сдерживать капитал, имеет парадоксальный эффект, ведущий к политическому параличу. Ни одна группа не является однородной. Классы, правильно измеренные, создают эффективность, а не неэффективность, заставляя членов класса приходить к консенсусу относительно их общих интересов. Без такого давления подклассы (группы внутри класса) будут сражаться друг с другом, что приведет к тупику. Правильно спроектированные классы мотивируют своих членов прийти к внутреннему консенсусу, чтобы они могли максимизировать свое влияние на систему по сравнению с другими классами.

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

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

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