Почему многие кейсы применения умных контрактов попросту неосуществимы

https://www.coindesk.com/three-smart-contract-misconceptions/
  • Перевод
Одно из предназначений смарт-контрактов — автоматизация платежных операций между контрагентами. На этом рынке работает и наш платежный блокчейн-сервис Wirex. Несмотря на перспективность смарт-контрактов, автор материала анализирует недостатки этой технологии.

Как разработчика популярной блокчейн-платформы меня иногда спрашивают есть ли в планах развития нашего сервиса Multichain место умным контрактам по типу тех, что используются в Ethereum. В ответ всегда звучит: «Нет, или во всяком случае не сейчас».

image

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

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

Умный контракт — фрагмент кода, хранящийся в блокчейне. Он приводится в действие блокчейн-транзакциями и читает из блокчейна или пишет в него данные. Вот и все. Ни больше, ни меньше.

Умный контракт — всего лишь звучное название кода, который работает на блокчейне и взаимодействует с его состоянием. Что же это за код? Это Pascal, Python или PHP. А может быть, Java, Fortran или C++. Если мыслить форматом баз данных, то его можно представить в виде процедур, написанных на каком-либо расширении SQL.

Фундаментально все эти языки эквиваленты, они решают те же самые виды задач, применяя те же способы их решения. Конечно, у каждого из них есть сильные и слабые стороны. Вы сошли бы с ума, пытаясь создать веб-сайт на C или сжать HD-видео в Ruby. Но по крайней мере чисто теоретически вы могли бы это сделать, если бы захотели. Вам просто пришлось бы заплатить высокую цену с точки зрения удобства, производительности, и весьма вероятно, потерять немало волос на голове.

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

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

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

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

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

1. Взаимодействие с внешними сервисами


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

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

Звучит довольно просто. Просто и в то же время невозможно. Почему? Потому что блокчейн — это основанная на консенсусе система, а это означает, что работать она будет, только если каждый узел сети достигает одинакового состояния после обработки каждой транзакции и каждого блока.

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

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

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

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

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

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

Если это будет какой-то один узел, то что произойдет, если именно этот узел, умышленно или непроизвольно начнет сбоить? А если обращаться будут все узлы, можем ли мы доверять каждому узлу пароль от API? Да и оправдано ли будет делать сотни обращений вместо одного? И что еще хуже: если умному контракту необходимо определять успешность обращения к API, то мы снова сталкиваемся с проблемой зависимости от внешних данных.

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

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

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

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

Подробнее мы раскроем этот факт далее в материале.

2. Выполнение платежей внутри чейна


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

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

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

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

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

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

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

3. Потребность спрятать конфиденциальные данные


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

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

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

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

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

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

Аналогично и в случае со спрятанными в умном контракте данными, требуется всего лишь внести изменения в ПО для работы с блокчейном, чтобы оно отображало полное состояние контракта и вся видимость секретности сразу же сойдет на нет.

Любой программист средней руки справится с этой задачей не более чем за час.

Каково предназначение умных контрактов?


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

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

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

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

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

Способов соблюдения этих правил можно придумать великое множество, но в настоящее время преобладают две парадигмы, получившие распространение под влиянием Биткоина и Ethereum. Метод Биткоина, который по-другому можно назвать «ограничением транзакций» оценивает каждую транзакцию с точки зрения: a) записей в БД, удаленных с помощью этой транзакции и б) созданных записей.

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

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

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

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

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

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

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

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

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

image
Wirex 117,11
Мобильный банкинг нового поколения
Поделиться публикацией
Комментарии 35
  • –1
    1. Если хранить историю осадков в блокчейне то все будет работать. Это могут быть даже разные блокчейны, просто такой контракт будет стоить дороже.
    • +2
      Вопрос в том, кто эту историю будет в блокчейн вписывать. Надо ведь, чтобы все доверяли этому «кому-то».
      • 0
        В самом контракте и должен быть прописан «доверенный поставщик входящих данных» для его исполнения.
        • +5
          Ключевое слово «доверенный». То есть обе стороны доверяют третьей стороне, от которой, по факту, и зависит исполнение/не исполнение контракта. И это при том, что смарт-контракты должны, по идее, предоставить среду, где можно вести сделки, не доверяя никому. Присутствие оракула в сделке, получается, ничем не отличается от наличия арбитра/суда/банка/регулирующего правительственного органа в случае с бумажным контрактом.
          • –1
            Там именно это и написано:
            «оба подхода требуют наличия некой доверенной третьей стороны для управления взаимодействиями между блокчейном и внешним миром. Несмотря на теоретическую возможность реализации такой модели, любая децентрализация в ее рамках теряет всякий смысл».
            • +2
              Мои рассуждения касались комментария Barnaby. К тексту статьи претензий нет.
            • –1
              Контракт в любом случае «о чём-то», то есть присутствует ещё кто-то или что-то кроме двух сторон контракта. И даже больше — есть наверняка ещё четвёртая сторона, которая будет осуществлять финансовые транзакции. И всем им нужны внешние данные не из цепочки, которым можно доверять. Если это взаимодействие не предусмотрено изначально в механизме, то это не «умные контракты», а какие-то утопическо-сферические контракты в вакууме, зачем они нужны такие непонятно.
              • –1

                Вот вы и кратко пересказали весь пост. Так о чем тогда спор, если вы согласны с ним? Только об определении "умных контрактов"?


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

                • +1
                  Это не вполне определенный термин, а некая эфемерная сущность как «облака» или «зелёная энергетика». Будут какие-то юзабельные реализации, решающие конкретные задачи — не вопрос, протестируем.
                • 0
                  Даже профессионал не может ответить что именно могло бы быть реализовано на контрактах, и невозможно на биткоине — то видать пока таких идей нет. Возможно можно было бы сделать систему одалживания или систему сведения долгов через третьих лиц — но в текущей версии такое наверно не провернуть, потому что на сколько я понимаю — все расчеты ведутся в одной валюте — эфир.
        • +4
          Мне кажется, самая большая проблема блокчейна как технологии — зацикленность на одних и тех же кейсах. Существуют миллионы различных применений, от кофеварок до пиратских сокровищ, но все раз за разом изобретают очередной реестр или замену долларам. Скука
          • +2
            Подскажите, как поможет блокчейн кофеваркам или пиратам, прячущим сокровища? К сожалению, не могу представить такие кейсы…
            • 0
              А еще с принтерами. Как только запатентую (или хоть в статью нормальную оформлю, мороки с этими патентами) — может и подскажу :)
              На самом деле, это ведь просто совокупность распределенной структуры данных и реализующих ее протоколов. С капелькой воображения можно придумать великое множество юзкейсов, многие из которых притом имеют конкретные задачи не только для криптоманьяков и анархистов, но и бизнеса, и простых людей. И нет, не в том виде, в котором оно существует сейчас (когда все об этом пишут, но на практике там одно слово от него)
              • 0
                У вас очень гибкая фантазия, я был немного в шоке, когда узнал о попытке создания мобильной связи на блокчейне, но ваши идеи выглядят ещё более необычными.
                • 0
                  идеи выглядят ещё более необычными
                  С пиратами она и правда необычна, это из чисто хобби, прототип новой proof of системы и типа блоков на основе стеганографии, ее точно выложу, когда хотя бы теорию завершу. А с кофеварками как раз ничего особо необычного, они не те штуки, с которыми фантазии разыграться можно
                • +3
                  совокупность распределенной структуры данных и реализующих ее протоколов

                  Это называется «Интернет», и ему уж 30 лет!
            • –2
              Может я конечно не в теме и «кто знает, тот поймет», но первая часть текста как будто написана генератором текста. Вроде все предложения правильно построены, но что такое умный контакт, кроме того что это «код» на любом языке и что у меня по поводу этого контакта должны быть какие-то завышеные ожидания, я из так и не понял.
              • –4
                Внимательно прочитал статью «от» и «до» и так и не понял, почему же многие кейсы не осуществимы) Мы(и далеко не одни только мы) в Jincor занимаемся в том числе упрощением работы с умными контрактами для бизнеса. Большая часть из озвученных Вами проблем более чем решаема. Часть проблем решается банальными оракулами, часть приватными блокчейнами, часть децентрализованным арбитражным судом, часть привязкой умных контрактов к реальным и так далее. Так или иначе, абсолютно все проблемы, озвученные Вами в статье имеют решение и, как правило, далеко не одно)

                Узнать подробней о природе умных контрактов и сферах применения можно в тут
                • +3
                  Дело не в том, что эти проблемы нельзя решить, а в том, что в процессе их решения оказывается, что использовать блокчейн в таких системах бессмысленно, т.к. теряются все его преимущества над традиционными централизованными БД.
                  • 0
                    Это только в том случае, если единственное преимущество, которое Вы увидили в блокчейн — децентрализация. А это далеко не так.
                    • +2
                      А какие у него есть преимущества, которые не нивелируются при выделении централизованных доверенных узлов?
                      • 0
                        Неизменяемость внесенных в чейн данных. Задним числом ничего изменить невозможно, даже если источник информации был централизованным доверенным узлом и пытается потом от опубликованного отказаться.
                        • +1
                          Переспрошу и здесь. А уже имеющимися возможностями — это какая-то проблема?
                          Цифровые подписи не вчера придуманы. Да и бумажный договор, от которого у каждой стороны остаётся своя копия, подделать так, чтобы прокатило — занятие крайне сложное.
                          • –2
                            Есть два документа с разным содержанием. Оба подписаны. Кому верить?
                            Другой сценарий: анонимный источник информации (в понимании «источник публичного ключа которого мы не знаем»).
                            • 0
                              Расскажите, как сделать два документа с разным содержанием, чтобы они были подписаны и моей и вашей подписями, но при этом мы с вами сначала подпишем только одну из версий. Моего ключа у вас естественно нет.
                              • +2
                                А почему Вы рассматриваете только контракты подписанные более чем одним ключем? Возьмите к примеру банальную оферту — документ вида «прайс на услуги нашей компании». Вы приходите в компанию, а там Вам говорят «а это не тот прайс, правильный вон этот». Или взять в исходном тексте пример с сельскохозяйственным страховым полисом. Сколько подписей будет у документа подтверждающего информацию о фактической погоде? Или третий пример: подача рекламации в ситуации когда продавец отказывается ее принимать и соответственно подписывать своим ключем.
                                • +1
                                  > Вы приходите в компанию, а там Вам говорят «а это не тот прайс, правильный вон этот».
                                  Что помешает компании в таком случае положить в блокчейн новую запись с прайсом и сказать — с сегодняшнего дня действует вот этот?

                                  > Сколько подписей будет у документа подтверждающего информацию о фактической погоде?
                                  Достаточно подписи той стороны, которой и вы и страховая доверяете, просто сохраняете у себя копию подписанной записи и подписант не сможет опровергнуть факт подписания.
                                  > Неизменяемость внесенных в подписанный документ данных. Задним числом ничего изменить невозможно, даже если источник информации был централизованным доверенным узлом и пытается потом от опубликованного отказаться.
                                  :)

                                  > Или третий пример: подача рекламации в ситуации когда продавец отказывается ее принимать и соответственно подписывать своим ключем.
                                  И отказывается включать в блокчейн, над которым имеет контроль. А если не имеет, то получается, что единственная польза от блокчейна — децентрализация, см. начало треда, где утверждалось что это совсем нет так и есть какие-то другие.
                                  • 0
                                    Что помешает компании в таком случае положить в блокчейн новую запись с прайсом и сказать — с сегодняшнего дня действует вот этот?

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

                                    Задним числом ничего изменить невозможно

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

                                    А если не имеет, то получается, что единственная польза от блокчейна — децентрализация, см. начало треда, где утверждалось что это совсем нет

                                    Ну, мы говорим здесь о промежуточном варианте, где возможна частичная централизация в виде существования выделенных доверенных узлов. Это не полная децентрализация как в биткоине или эфире, но все же и совершенно не вариант где Вы над чейном контроля не имеете вообще.
                                    • +1
                                      В любом случае, для любого из этих вариантов, вам нужна будет ещё какая-то третья сторона, которая принудит вашего контрагента выполнять то, что было заложено, что в контракт, что в блокчейн. И всё упрётся опять в неё. Или вам предъявят свой вариант блокчейна, который майнился внутри компании и содержит другую информацию и скажут — это твой чейн левый. И начнётся обычное судебное разбирательство, где каждая сторона будет носить документы и доказывать кто прав.

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

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

                                      А всякие страховательные чейны и т.д., что мешает компаниям просто скинуться, создать оператора, который будет хранить ту же самую информацию в write only postgresql базе без всяких накладных расходов блокчейна?
                                      • 0
                                        что мешает компаниям просто скинуться, создать оператора, который будет хранить ту же самую информацию в write only postgresql базе без всяких накладных расходов блокчейна?
                                        А ничего. Основная идея эфира и других умных блокчейнов — создать уже готового распределенного оператора и инструментария для работы с ним. Тогда этим компаниям будет банально дешевле сделать все на нем, а не полностью нового оператора с нуля пилить. Чисто бизнес)
                            • +1
                              Ну и к чему было спрашивать? Чтобы просто молча поминусовать валидный ответ?
                  • 0
                    Спасибо, Капитан Очевидность.

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


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

                    А доверие убрать нельзя полностью. Допустим, что вы решили купить товар. И для минимизации доверия вы решили использовать самую надёжную валюту — кусочки, с высокой долей содержания дефицитного во вселенной химического элемента. Но вы всё равно доверяете продавцу, что товар, который вы покупаете, будет именно тем товаром, который был обещан и который вы расчитываете получить. И продавец всё равно доверяет вам, что деньги, которые вы ему дадите, действительно сделаны из редкого элемента, а не из его имитации. Также вам приходится доверять своим головам и органам чувств, что вы верно поняли друг друга.
                    • 0
                      Как-то вы не расскрыли свой посыл, как мне кажется.

                      Взаимодействие с внешними сервисами у вас в тексте так и не расскрыто почему это невозможно?

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

                      То есть некто X выпускает смартконтракт, который в зависимости от наступления условия Y зачислит условно на ваш баланс Z% от некоторой суммы. Проверку наступления условий смартконтракт осуществляет обращаясь к оракулу, можно даже не одному, а нескольким, разным, и условие считается наступившим, только в случае если все оракулы ответили одинаково.

                      Есть ли в этом сценарии потеря децентрализаиции и появляются ли некоторые доверенные участники? Да. Но сам реестр продолжает быть таким каким он был, без потери своих свойств. То есть у нас просто есть смартконтракт, который по сути является программным кодом и представляет из себя аналог обычного бумажного контракта, только за его исполнением следит программный код. В этом и есть основная суть смартконтрактов. А вы как потребитель выбираете чей смартконтракт вам интересен и на чьи условия вы готовы согласиться.

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

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

                      Оракулы имеют свою комиссию и поэтому предоставление некорректных данных поставит крест на его существовании, так как факт предоставления таких данных будет отражен в том самом распределенном реестре.

                      То есть в итоге смартконтракты служат для уменьшения посредников и повышения прозрачности.

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

                      Все это мое оценочное суждение :)
                      • 0
                        Упс, не обратил внимания, что это перевод, а не ваш текст. В общем по поводу критики текста это не к вам, а к Dr Gideon Greenspan, не уверен правда, что он сюда заглядвает :)
                      • +1
                        Вы сошли бы с ума, пытаясь создать веб-сайт на C

                        В качестве примера высоконагруженного сайта с движком на С — крупнейший русский имиджборд 2ch.hk.

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

                        Самое читаемое