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

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


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

    Similar posts

    Comments 20

      +1

      Больше похоже на blockchain-based git repository.

        0
        Так оно и есть, по сути апп блокчейна получает страничку в кошельке где можно послать пулл реквест (GNU diff) в сам апп.
        +1

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


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

          0
          Это правда (и лично мое мнение что им нет смысла быть одновременно), но смарт апдейт это суперсет по возможностям, он по определению может все сделать все качественнее и быстрее. Для опробывания уже существует эфир EVM, поиграться :)

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

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


            На мой взгляд разделение должно быть таким: апдейты для инфраструктуры и движка, контракты для пользовательского кода. Благо скоро подъедет WASM и проблемы с тулингом для исполняемого кода передаваемого по сети решатся за счет эфекта от масштаба.

              0
              В этом есть логика, но лично я «not sold» по идее что юз-кейсов настолько много что нужно тащить тюринг полноту. Я очень мало вижу ценных идей. Может они вот-вот появятся и я изменю свое мнение. А пока — сугубо регистры, деривативы и ассеты. Что вполне умещается в редкое обновление и оттачивание через одни лишь апдейты. Поживем увидем!
                0

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

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

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

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

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

          EVM достаточно полна для реализации не только erc20(и тем более не только логики токенов). На базе EVM вы можете реализовать что угодно в рамках экосистемы. Другой вопрос — сколько это будет стоить. Тривиальную задачу сохранения jpg-картинки в ethereum реализовать возможно. Но стоить это будет крайне дорого. Понятно, что если вы не умещаетесь своей транзой в блок, то потребуется out of the EVM box логика для отправки в несколько транз. Но сохранение будет в любом случае через EVM. EVM довольно хороша.
          Писать даже маленький «патч» на солидити крайне сложно.

          Пример? Brainfuck видели? Вот там — сложно. В солидити все очень чисто, функционально и понятно.
          На нижнем уровне вас ждет сырая VM которая имеет очень мало опкодов (by design) и простенькую key-value базу данных.

          Пруфы? Вы можете создавать, хранить и манипулировать вполне себе сложными структурами.
          // Structs
          struct Bank {
          address owner;
          uint balance;
          }
          Bank b = Bank({
          owner: msg.sender,
          balance: 5
          });
          // or
          Bank c = Bank(msg.sender, 5);

          c.balance = 5; // set to new value
          delete b;

          Почти ООП. Читайте методички learnxinyminutes.com/docs/solidity
          Все операции крайне дорогие (gas cost) и вам не развернуться от слова совсем.

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

          Все возможно. Если вы не смогли найти решение, это не значит, что система плоха.
          тысячи строк кода, на сырейшем инопланетном языке (solidity)

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

          И не должен существовать. Контракт имеет свою память, в которой вы — царь, делаете что хотите. Создаете любые структуры и интерфейсы. Достаточно простые структуры и интерфейсы. Было бы в блоке больше места, можно было бы сделать парсеры, чтобы реализовать SQL/ORM. Но задач в рамках контракта таких не представляю. Храните нужные данные простыми структурами в контракте, остальное — в интерфейсе делайте.
          95% работы современного solidity проекта это именно борьба с солидити а не архитектура кода.

          Это непрофессиональный необоснованный буллшит. Если у вас не получилось — это ваши проблемы, а не языка/системы.
          Та же идея может быть реализована на javascript в десятки раз быстрее и надежнее, просто потому что мы знаем и умеем писать javascript

          Я вас понял.
          а экосистема solidity ушла не сильно дальше экосистемы языка brainfuck.

          Простите, вы totally непрофессиональны.

          Что конкретно вам непонятно в solidity? Что не получилось?
          Готов помочь вам во имя мира во всем мире. Пока вижу, что вы сложили субъективное мнение, взглянув издалека, не попробовав решить проблему(и у вас позиция «не осилил, плохая технология»). Либо вы реально пробовали и наткнулись на какую-то нерешаемую проблему. С первым помочь не смогу, не психолог, чтобы ваши клубки распутывать. Со вторым — с удовольствием помогу.
            0
            > На самом деле в блокчейне важны только данные. Клиенты, которые обеспечивают возможности сети могут изменяться как угодно, лишь бы данные, хранящиеся на нодах были сохранены

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

            >Это непрофессиональный необоснованный буллшит. Если у вас не получилось — это ваши проблемы, а не языка/системы.

            У меня все получилось, я отлично знаю солидити. И делаю намного лучше без него, двухслойные сети платежных каналов например как райден, с 50х меньшей сложностью. Если вы дальше кастомного токена ничего не пытаетесь сделать — конечно солидити вас устраивает и не ограничивает :)

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

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

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

              Вы вполне себе нормальный ЯП назвали эльфийским языком, обласкали технологию. Да, не идеальна, как и любая другая технология, как все в этом мире.
              Но ключевое — безосновательность.
              тысячи строк кода, на сырейшем инопланетном языке (solidity)

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

              И не должно существовать. В чистом C нет ни SQL, ни NoSQL. В них даже GUI нет. Как и в упомянутом js. Вызовите-ка мне из js SQL базу данных или создайте many-to-many поле. Не в node.js а именно в js, на html странице. Ох, так вам еще и сервер-обработчик нужен. Ну даете.
              вам не развернуться от слова совсем.

              Примеры, пруфы, обоснования.
              Пока что вы не показали никакой экспертности, просто сливаетесь под видом «перешли на личности».
              Конечно буду переходить, если вы так остро пишите без обоснования точки зрения.
            +1
            Многовато вкусовщины сказано про солидити, хорошо бы подтверждать.

            Solidity дает хранимые процедуры в реплицированной state machine. Если теперь посмотреть на языки для хранимых процедур, то есть давайте уж сравнивать именно подобные языки между друг другом, то у нас есть T-SQL, PL/SQL и ко. И Solidity неплохо смотрится рядом с ними. Ближе к доменной области, проще с синсаксисом.

            Это я не к тому, что Solidity прекрасен. Отнюдь. А к тому, что надо бы сравнивать хоть отчасти сравнимые вещи, а резкие заявления подкреплять.

            И да, язык решает только свои задачи, своей доменной области. Принять, обработать, сохранить в файл — это не про него, а про Service model Ethereum. К LES аккаунтинг недавно прикручивали, то же с Swarm. Надо эту часть допиливать.
              0
              Вовсе не было задачи сравнить solidity с похожими языками с теми же задачами (он и правда хорош в этом плане) а доказать что он не нужен с самого начала и берется за задачу которая ему не по зубам. Проблема добавления новых функций решается куда эффективнее нативно.
                0
                Можете рассказать про «проблема добавления новых функций решается куда эффективнее нативно»? Очевидно это ваш ответ на мои слова про service model. Соответственно жду развернутого ответа, что не так с service model. *ну или голословности*
                  0
                  Я делаю проект похожий на райден, это не сервис модель а сложная система в себе, хранящая разного рода каналы, диспьюты, ребалансировки. Средств солидити недостаточно, писать сильно сложнее чем если бы это впилилось на нативном уровне.

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

                  Пример проблемы — банк становится insolvent и нам надо проитерировать по его долгам. Можно конечно сделать storage banks =… и внутри хронить долги и итерировать кое-как. И тут нам понадобилось обратная итерация — найти все банки которые должны что-то некому юзеру. Тут уже нужна many to many итерация, и никаких трюков в солидити не хватит чтобы ее реализовать.
                    0
                    Задачей вкручивания микротранзакций в LES Ethereum мне доводилось заниматься и я пока не увидел, почему это не часть сервисной модели. Расскажите?
                      0
                      Пеймент каналы это не только микротранзакции, это вообще любые транзакции сделанные офчейн. Масштабирование, краеугольная проблема. Это реализуемо на солидити, но сложность запредельная. Та же проблема с плазмой. Я допускаю что реализации райдена/плазмы скоро появятся (два года то спустя), но и атак будет много и поддерживать это будет слишком сложно в отличии от тех же фич на нативном уровне. Имхо
                      0
                      В блокчейне бывает любая задача.
                      Если я правильно понимаю суть работы raiden — паблишим смарт-контракт, на него любой желающий отправляет токены и после этого может моментально обменивать через сервер свои токены на чужие или пользоваться токенами в соответствии с балансом, заведенным на сервере.
                      типа:
                      — Вася отправил 20 ABC на контракт, у него баланс на сервере raiden = 20 ABC, на контракте 20 ABC
                      — Петя отправил 13 QQQ на контракт, у него баланс на сервере raiden = 13 QQQ, на контракте 20 ABC, 13 QQQ.
                      — Вася продал Пете 10 ABC за 2 QQQ через сервер. у Васи баланс на сервере 10 ABC, 2 QQQ, у Пети 10 ABC, 11 QQQ.
                      — Петя решил оплатить на каком-то сервисе что-то токенами ABC на сумму 1 ABC. Сервис не подключен к raiden поэтому выводим с контракта по запросу Пети 1 ABC куда Пете надо, у Пети на балансе сервера 9 ABC, 11 QQQ, у Васи 10 ABC, 2 QQQ
                      — если бы сервис был подключен к raiden, трансфер был бы моментальным и бесплатным(не платим комиссии на сервере).
                      Собственно вопрос один — за вывод токена кто-то должен заплатить эфиром. Кто это будет? Или кто-то будет аккумулировать эфир на контракте? зачем?
                      В целом, совсем несложная задача, если я все правильно понимаю.
                      Скорректируйте, Homakov, если не прав.
                      Спасибо
                        0
                        Это если только совсем в грубом виде. Сервера райден как такового нет, есть куча контрагентов где каждый может общаться с каждым (и узаконивать отношения ончейн).

                        Райден копирует идею lightning.network — почитайте концепт пеймент канала там. Есть куча corner case. Например HTLC.

                        Комиссии вроде платит тот кто делает транзакцию. Это еще простая часть.
                          0
                          Понял, сервер я поднимаю на локали у себя.

              Only users with full accounts can post comments. Log in, please.