Смарт апдейты против смарт контрактов

в 10:06, , рубрики: биткоин, блокчейн, децентрализованные сети, платежные системы, Смарт контракты

Что есть смарт контракт и зачем он был нужен?

Давным давно, после появления биткоина — первой реплицируемой стейт машины — люди начали замечать что функциональность заложенная в консенсус слишком ограничена. Я не говорю сейчас про добавление торговлей криптокотов, а про вполне реальные юзкейсы — DNS где каждый домен принадлежит публичному ключу а не централизованному регистратору, всякого рода токены и финансовые деривативы (ведь хочется владеть акциями так же как ты владеешь биткоином), ончейн обменки (чтобы торговать на крупные суммы без доверия обменке), пеймент каналы (быстро перераспределять общий escrow между двумя аккаунтами без оверхеда сообщения о транзакции вообще всем)…

Выходов для добавления функций было три:

1) самый очевидный — вписать их в код самого блокчейн, нативно.

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

2) создать другой блокчейн с этим функционалом.

Так и произошло с несколькими «блокчейнами одной идеи» аля namecoin. Вскоре было замечено что люди не хотят использовать новую сеть ради одной функции, также нужна interoperability и очень многие вещи зависят друг от друга (кредиты, айдентити и сами ассеты хотят жить в одном адресном пространстве)

3) реализовать функции средствами внутренней виртуальной машины и опкодов.

Даже в биткоин Сатоши заложил Script именно из-за проблемы обновлений, который позволял сделать многое, но его было не достаточно. Поэтому эфиром был предложен расширенный скрипт (теперь turing complete) и с ним якобы можно сделать что угодно (в теории).

image

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

Что такое смарт апдейт?

Оборачиваясь на последние пару лет смарт контрактов, можно четко сказать что ожидания они не оправдали. Да, бум ICO был невозможен на биткоине, но и вводить продвинутую EVM только ради токенов erc20 было перебором.

Писать даже маленький «патч» на солидити крайне сложно. На нижнем уровне вас ждет сырая VM которая имеет очень мало опкодов (by design) и простенькую key-value базу данных. Все операции крайне дорогие (gas cost) и вам не развернуться от слова совсем.

Сложные юзкейсы — практически невозможно. Посмотрите на райден github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts — тысячи строк кода, на сырейшем инопланетном языке (solidity), для управления сложной финансовой системы. Мы видели несколько взломов парити и ДАО с помощью простых атак, какие же атаки нас ждут на такую монструозную код-базу?

SQL базы нет, NoSQL нет, графовой бд тоже не намечается. Итерация по ключам, many-to-many? ORM? Ничего этого внутри контракта не существует. Тулинг тоже очень слабый относительно известных языков программирования.

95% работы современного solidity проекта это именно борьба с солидити а не архитектура кода. Та же идея может быть реализована на javascript в десятки раз быстрее и надежнее, просто потому что мы знаем и умеем писать javascript а экосистема solidity ушла не сильно дальше экосистемы языка brainfuck.

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

Onchain governance = Smart Updates

Наевшись горя с solidity, давайте вернемся в 2012 и вспомним отброшенный первый вариант с добавлением юзкейсов нативно в блокчейн.

image

Как многие заметили, после реализации EVM сама EVM не перестала обновляться как это предполагалось (базовый уровень не меняется никогда, весь новый код только внутри EVM) — наоборот она регулярно хардфоркается диктатурой этереума.

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

В таком виде идея смарт контрактов абсолютно провальная — мы уже имеем authority который диктует как работает слой консенсуса (гитхаб аккаунт этериума), нафига нам лишняя и неэффективная абстракция если мы не смогли избавиться от обновлений основного слоя?

Раз уж мы не можем избавиться от обновлений, давайте хотя бы придумаем как обновлять нам этот основной слой максимально децентрализованно?

Мы можем предлагать патчи к софту прямо внутри блокчейна, валидаторы могут за них голосовать, и выигрышные патчи просто у всех реализуются синхронно через какой то период. Эта идея «onchain governance» витала в воздухе довольно давно, но первыми ее описали, если не ошибаюсь, Tezos. Что тезос упустили из виду — ончейн гавернанс прямой конкурент смарт контрактам (поэтому я называю его смарт апдейты).

Если у вас есть смарт апдейты, вам попросту не нужны смарт контракты. Любой юзкейс может быть реализован быстрее, качественне, с любой базой данных на ваш вкус (SQL/NoSQL/whatever), на любом языке программирования (вы же выполняете код уже на уровне машины, и ничем не ограничены). Полная свобода, минус те самые 95% оверхеда что вы тратили на солидити, и нам не нужно лепить новый блокчейн как в решение #2.

Есть ровно два минуса у смарт апдейтов

1. Теперь далеко не каждый юзкейс будет одобрен валидаторами, так как они думают и голосуют какого рода патч будет полезен для сети (и отсекают откровенно вредоносные бэкдоры). Вещи типа криптокотят врядли когда либо будут одобрены большинством (трешолд в 67% или 95%, конфигурируется внутри самой сети)

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

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

Итог

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

За смарт апдейтами будущее, и практически все блокчейны что сейчас в разработке их включают с самого начала (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc). Даже в самих смарт контрактах сейчас стараются внутри себя включить механизм обновления, поняв что концепция set-in-stone не работает, и обновляться как-то рано или поздно придется.

Вот более подробная вики на эту тему (на англ. Умиляюсь как Vitalik и Vlad Zamfir пытаются очернить смарт апдейты, их прямого конкурента делающего EVM полностью obsolete.

Автор: Homakov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js