Comments 34
В связи с чем у Лаборатории Касперского такой интерес к блокчейну?
Блокчейн влияет (или может повлиять) на рынок антивирусов?
Блокчейн влияет (или может повлиять) на рынок антивирусов?
ЛК давно делает не только антивирусы, плюс у нас тут много энтузиастов, которые просто интересуются новыми технологиями и блокчейн как технология достижения консенсуса может пригодиться в самых различных сферах. Отвечу как-то так.
Сейчас только ленивый не говорит о биткоинах и блокчейнах.
Логично что ребята решили немножко внимания к себе привлечь на этом.
Вполне логично. Жаль что в статье одна вода, буквально полтора слова по теме, но может кому-то и это будет интересно.
Логично что ребята решили немножко внимания к себе привлечь на этом.
Вполне логично. Жаль что в статье одна вода, буквально полтора слова по теме, но может кому-то и это будет интересно.
Вы не могли бы привести какой-то более жизненный пример? Что именно могут вычислять банки для того, чтобы прийти к какому-то (какому именно) соглашению? Техническая сторона смарт-контрактов понятна, а вот как это можно применить на практике кроме оплаты криптовалютой, пока не встретил ни в одной статье на эту тему.
вы конкретно про банки или вообще? я вообще отвечу. на вскидку вот список обширный: www.cryptocoinsnews.com/smart-contracts-12-use-cases-for-business-and-beyond
другой пример: голосование акционеров и контроль подсчета голосов.
но надо, конечно, отдавать отчет, что во многих случаях очень часто все упирается у регуляторку и опасения участников.
другой пример: голосование акционеров и контроль подсчета голосов.
но надо, конечно, отдавать отчет, что во многих случаях очень часто все упирается у регуляторку и опасения участников.
Скажите, есть ли ограничения в использовании смарт-контрактов? Для всех ли видов сделок они подходят?
Например, можно ли с помощью смарт-контракта купить вагон сахара? Как быть, если формально сахар доставлен покупателю, но качество не соответствует условиям контракта?
Или смарт-контракты подходят только для сделок, поддающихся четкой формализации?
Например, можно ли с помощью смарт-контракта купить вагон сахара? Как быть, если формально сахар доставлен покупателю, но качество не соответствует условиям контракта?
Или смарт-контракты подходят только для сделок, поддающихся четкой формализации?
скорее для четкой формализации, другое дело, что можно создать четкую формализацию для каждой сделки. тут скорее проблема больше, смарт контракты не имеют связи с условно внешним миром, то есть в вашем примере, должен быть какой-то сервис в интернете, который продает вагон сахара и кроме того, должна быть связь из блокчейна с таким сервисом через какой-то оракл, которому стороны должны будут доверять.
Насчет вагона с сахаром я погорячился. Это несколько неудачный пример. Но вот пример, который уже давно функционирует и имеет много признаков «настоящего» смарт-контракта. Я имею ввиду покупку товара на Алиэкспрессе. Выбрав товар, мы его оплачиваем, деньги поступают на аккаунт продавца, но пока ему недоступны. Средства разблокируются либо спустя определенное число дней после отправки товара, либо после подтверждения покупателем получение товара и удовлетворенностью его качеством. Иногда посылки не доходят и часто качество страдает, но покупатель имеет возможность выставить претензию, которую рассматривает уже администрация Алиэкспресса.
Другими словами, в этой схеме велико значение человеческого фактора. Махинации возможны со стороны всех участников процесса, хотя, на первый взгляд, процесс достаточно формализован.
Поясните, как можно уменьшить значение человеческого фактора в смарт-контрактах, например, на базе Эфириума?
Другими словами, в этой схеме велико значение человеческого фактора. Махинации возможны со стороны всех участников процесса, хотя, на первый взгляд, процесс достаточно формализован.
Поясните, как можно уменьшить значение человеческого фактора в смарт-контрактах, например, на базе Эфириума?
Тут максимум что можно — убрать центральное звено, а именно администрацию АлиЭкспресса. Но его надо будет чем-то заменить. Формальные правила это да, но надо еще откуда-то в контракт залить инфорацию о товаре, о трекномере и т.п., тогда мы должны будем внести некое другое доверенное лицо, например условная «Почта России» соглашается выступать в качестве надежного источника данных (оракула), а именно они сообщают о том дошла ли посылка, и получатель осматривает содержимое в присутствии их сотрудника, после чего сотрудник вносит эту информацию в блокчейн (при мне он открыл, все было ок, или «какашка приехала»). При условии что доверие к условной Почте России будет больше чем к администрации Али — такой вариант будет применим и заметно более удобен/надежен. При этом технически служба доставки имеет больше объективной информации чем администрация магазина (почта видит саму посылку физически, а маркетплейс оперирует только репутацией и перепиской пользователей. Однако сам по себе смарт-контракт тут ничем не поможет, ибо у него нет информации из внешнего мира, а если все три стороны договоряться использовать смартконтракт (т.е. и продавец и покупатель и арбитр) то лишнего выигрыша все равно не будет, ведь и так и так доверять арбитру.
Смартконтракты немного не для этого (по крайней мере пока).
Смартконтракты немного не для этого (по крайней мере пока).
получатель осматривает содержимое в присутствии их сотрудника, после чего сотрудник вносит эту информацию в блокчейн (при мне он открыл, все было ок, или «какашка приехала»)
Что мешает получателю быть в сговоре с работником почты, спросит продавец. И будет прав.
Но с Вами соглашусь, смарт-контракты годятся для узкой области применения, где можно провести полную формализацию процесса.
Что мешает получателю быть в сговоре с работником почты, спросит продавец.
Что мешает работнику АлиЭкспрес быть в сговоре с покупателем или с продавцом? Тут все зависит от того насколько удачно будут организованны бизнес-процессы. В удаленном же контроле у администрации маркетплейса нет вообще никакой возможности узнать правду и повлиять на процесс. Тут можно хоть на видео рекламацию снимать. Всё хоть какой дополнительный фактор.
Ничто не мешает, только вероятность такого сговора меньше в силу масштаба. Точно не знаю, но предположу, что арбитр в алиэкспресс по претензии выбирается случайным образом. Учитывая число продавцов и число сотрудников, сговор теряет смысл.
В случае локальной почты, вероятность выше. Работница почты может быть сестрой вашего одноклассника, например. И вполне может «помочь» при получении дорогостоящей вещи. И в этом случае даже видеофиксация не поможет :)
Хотя есть вариант для дорогостоящих вещей делать уникальные метки и, например, с помощью смартфона считывать при открытии посылки. Если метка совпадает с данными отправителя, которые можно при отправке вносить в базу алиэкспресса (как пример), то груз доставлен корректный. Но в этом случае все равно остается проблема контроля отправлений. Ведь метку можно вместо iPhone прикрепить к кирпичу :)
В случае локальной почты, вероятность выше. Работница почты может быть сестрой вашего одноклассника, например. И вполне может «помочь» при получении дорогостоящей вещи. И в этом случае даже видеофиксация не поможет :)
Хотя есть вариант для дорогостоящих вещей делать уникальные метки и, например, с помощью смартфона считывать при открытии посылки. Если метка совпадает с данными отправителя, которые можно при отправке вносить в базу алиэкспресса (как пример), то груз доставлен корректный. Но в этом случае все равно остается проблема контроля отправлений. Ведь метку можно вместо iPhone прикрепить к кирпичу :)
У нас в одной гос.конторе где я работал были «секс-пакеты» для образцов. (Вообще они назывались сейф-пакеты, но так их никто не называл). Схема в теории простая — инспектор отбирает образцы от клиентской партии, запечатывает в секс-пакет, а клиент уже его сам везет в авторизованную лабораторию. У каждого секс-пакета индивидуальный номер, и заклеивается он одноразово. Внутри кармашек с сопроводительными документами, в которых указан номер секс-пакета. Размеры пакетов бывают разные. Цену пакетов не помню, но в целом даже с учетом больших откатов цена как помню была доступная.
Понятное дело что клиенты с инспекторами часто бывали в сговоре и инспектора часто давали им просто новые секс-пакеты и те загружали в них что хотели. Ну и лаборатории тоже химичили.
Но в контексте задачи контроля сотрудника службы доставки — достаточно снимать процесс распаковки целиком, начиная с момента сверки номера секс-пакета.
Смысл тут в том, что да, с человеком здесь и сейчас, который рядом с тобой — договориться проще. Но… и что это даст? Подменить на свой кирпич и вылать его обратно? Но видео во многом поможет. Ну и прокатит разово. Если процент проблем с отдельным сотрудником выше среднего по палате… Но при этом у проверяющего есть доступ к объективной информации. А арбитр хоть и случайный, что снижает шанс сговора, но… имеет минимум информации, и зачастую вынужден решать методом потолка.
Понятное дело что клиенты с инспекторами часто бывали в сговоре и инспектора часто давали им просто новые секс-пакеты и те загружали в них что хотели. Ну и лаборатории тоже химичили.
Но в контексте задачи контроля сотрудника службы доставки — достаточно снимать процесс распаковки целиком, начиная с момента сверки номера секс-пакета.
Смысл тут в том, что да, с человеком здесь и сейчас, который рядом с тобой — договориться проще. Но… и что это даст? Подменить на свой кирпич и вылать его обратно? Но видео во многом поможет. Ну и прокатит разово. Если процент проблем с отдельным сотрудником выше среднего по палате… Но при этом у проверяющего есть доступ к объективной информации. А арбитр хоть и случайный, что снижает шанс сговора, но… имеет минимум информации, и зачастую вынужден решать методом потолка.
Ну и добавлю, одна из причини тормозящая развитие, это cost of adoption. Условно проблема же решается и сейчас? Переход на смарт контракт поможет сократить издержки вероятно (тоже под вопросом), но кардинально жизнь в данном кейсе не улучшит. Потому оно, безусловно, перспективно, но не везде и далеко не сразу.
UFO just landed and posted this here
что значит «нужен»? давайте рассуждать в условно математическом поле, результат голосования должен быть подсчитанным правильно, а стороны должны поверить в то, что подсчет правильный. Достичь этого можно двумя путями:
1. централизованный актор, которому все верят соберет голоса и выдаст ответ.
2. децентрализованно стороны проверят подсчеты друг друга и достигнут консенсуса.
1. централизованный актор, которому все верят соберет голоса и выдаст ответ.
2. децентрализованно стороны проверят подсчеты друг друга и достигнут консенсуса.
Вы упускаете какой-то фактор, и вас не понимают.
Либо это должно быть тайное голосование, тогда надо объяснить как можно сделать голосование тайным в цифровом мире, и без центрального узла (знаю что возможно, но вот сходу не придумаю), или если голосование публичное (ну по крайней мере среди голосующих), то нужно объяснить зачем кому-то считать голоса если они и так публичны — все всем сказали свой голос (публичный протокол собрания, почтовая рассылка куда все шлют и т.п.), и все посчитали… обождите, но это ведь и есть смарт-контракт — все считают одно и тоже. А нет, не совсем. Надо чтобы это происходило внутри цифровой формализованной среды, а не в бумажном виде и в реальном мире. (строго говоря поименное голосование когда каждый проверяет ведущего это тоже смарт-контракт, но договоренности в реальном мире выполняемые людьми обычно так не называют, а только в цифровом мире).
Либо это должно быть тайное голосование, тогда надо объяснить как можно сделать голосование тайным в цифровом мире, и без центрального узла (знаю что возможно, но вот сходу не придумаю), или если голосование публичное (ну по крайней мере среди голосующих), то нужно объяснить зачем кому-то считать голоса если они и так публичны — все всем сказали свой голос (публичный протокол собрания, почтовая рассылка куда все шлют и т.п.), и все посчитали… обождите, но это ведь и есть смарт-контракт — все считают одно и тоже. А нет, не совсем. Надо чтобы это происходило внутри цифровой формализованной среды, а не в бумажном виде и в реальном мире. (строго говоря поименное голосование когда каждый проверяет ведущего это тоже смарт-контракт, но договоренности в реальном мире выполняемые людьми обычно так не называют, а только в цифровом мире).
Вероятно да, что-то упускаю.
Давайте попробую исправиться. В ваших примерах публичным и доверенным может быть только то, голосование, в котором стороны собрались в одном помещении, по команде подняли руки за и против и посчитали. Все увидели кто как проголосовал.
Собрать то же самое по почте — уже не публичное, почта взламывается, тот кто собирает может ошибаться, может действовать злонамеренно и так далее.
Потому если мы говорим о голосовании распределенном(через интернет), то тут уже масса сложностей возникает. Не для всех кейсов необходимо все сложности преодолевать, где-то хватит и упомянутого выше сбора по почте, но все же.
Плюс сюда добавляются требования анонимности, сокрытия промежуточного результата голосования и прочие интересные штуки. Все это ведет нас к появлению не менее интересных протоколов голосования, богатых разного рода математикой и криптографией. Вот, скажем, если выполнять эти протоколы голосования в среде смарт контрактов (я сейчас очень упрощаю, описание протокола тянет на отдельную статью), то у нас появляется дополнительное свойство системы, которое заключается в проверяемом выполнении кода. Что полезно в определенных кейсах.
Напишу видимо отдельную статью еще =)
Давайте попробую исправиться. В ваших примерах публичным и доверенным может быть только то, голосование, в котором стороны собрались в одном помещении, по команде подняли руки за и против и посчитали. Все увидели кто как проголосовал.
Собрать то же самое по почте — уже не публичное, почта взламывается, тот кто собирает может ошибаться, может действовать злонамеренно и так далее.
Потому если мы говорим о голосовании распределенном(через интернет), то тут уже масса сложностей возникает. Не для всех кейсов необходимо все сложности преодолевать, где-то хватит и упомянутого выше сбора по почте, но все же.
Плюс сюда добавляются требования анонимности, сокрытия промежуточного результата голосования и прочие интересные штуки. Все это ведет нас к появлению не менее интересных протоколов голосования, богатых разного рода математикой и криптографией. Вот, скажем, если выполнять эти протоколы голосования в среде смарт контрактов (я сейчас очень упрощаю, описание протокола тянет на отдельную статью), то у нас появляется дополнительное свойство системы, которое заключается в проверяемом выполнении кода. Что полезно в определенных кейсах.
Напишу видимо отдельную статью еще =)
Ну голосование с одним частично доверенным центром очень простое.
В ФИДО голосование было примерно следующим (детали могу за давностью позабыть, если что пусть кто подправит) — ноды отправляли свой голос неткоординатору или кому повыше, причем голос был в формате «кодовое слово» + вариант за который голосуют.
В конце срока голосования «считающий» публиковал списки — какое кодовое слово за какой вариант. Каждый мог найти свое кодовое слово, и убедиться что оно именно в нужном месте, ну и пересчитать все варианты.
Да, есть коллизии по кодовым словам, но тут можно регламентировать какой-то хеш от адреса ноды и случайной соли, тогда коллизий не будет. Да, приватность нетмыла была довольно условной. Да сетка там была довольно дырявая по части MitM, и тд и т.п. Но это вообще не задачи голосования или смарт-контрактов. Шифрование/подпись решает проблему канала, нужно еще проконтролировать чтобы люди могли сравнить что протокол у всех одинаковый, т.е. нужно как-то обменяться хешем протокола.
Все что сможет «считающий» это знать кто проголосовал, и знать как они проголосовали. Ну и конечно «мертвые души», но тут уже варианты специфичны от конкретного голосования, как определяется список голосующих.
Что характерно — тут нигде нет смарт-контрактов. Все вопросы организационные, или уровня протокола (шифрование, публикация результата — все это можно так или иначе отнести к блокчейну, но не смарт-контракту).
Очевидно что именно полной анонимности (от центрального органа) и отсутствием мертвых душ (составлением тех кто имеет право голосовать) может заняться смартконтракт. Но хотелось бы большемяса технических подробностей.
В ФИДО голосование было примерно следующим (детали могу за давностью позабыть, если что пусть кто подправит) — ноды отправляли свой голос неткоординатору или кому повыше, причем голос был в формате «кодовое слово» + вариант за который голосуют.
В конце срока голосования «считающий» публиковал списки — какое кодовое слово за какой вариант. Каждый мог найти свое кодовое слово, и убедиться что оно именно в нужном месте, ну и пересчитать все варианты.
Да, есть коллизии по кодовым словам, но тут можно регламентировать какой-то хеш от адреса ноды и случайной соли, тогда коллизий не будет. Да, приватность нетмыла была довольно условной. Да сетка там была довольно дырявая по части MitM, и тд и т.п. Но это вообще не задачи голосования или смарт-контрактов. Шифрование/подпись решает проблему канала, нужно еще проконтролировать чтобы люди могли сравнить что протокол у всех одинаковый, т.е. нужно как-то обменяться хешем протокола.
Все что сможет «считающий» это знать кто проголосовал, и знать как они проголосовали. Ну и конечно «мертвые души», но тут уже варианты специфичны от конкретного голосования, как определяется список голосующих.
Что характерно — тут нигде нет смарт-контрактов. Все вопросы организационные, или уровня протокола (шифрование, публикация результата — все это можно так или иначе отнести к блокчейну, но не смарт-контракту).
Очевидно что именно полной анонимности (от центрального органа) и отсутствием мертвых душ (составлением тех кто имеет право голосовать) может заняться смартконтракт. Но хотелось бы больше
На сколько я понимаю, ошибки в разработке смартконтрактов будут обходится очень дорого. Может кто-нибудь занимается применением к ним систем формальной верификации? Мне попадался backend Idris (языка с зависимыми типами, позволяющего доказывать корректность программ), компилирующий в Solidity, но мне он показался сырым.
да, есть такое, вот например исследование: www.cs.umd.edu/~aseem/solidetherplas.pdf
Несколько месяцев назад общались с сингапурскими студентами на эту тему, вот их проект тут на тему формальной верификации: www.comp.nus.edu.sg/~loiluu/oyente.html
Плюс пока искал наткнулся на еще один проект: securify.ch
А еще есть Tezos, которые обещают вставить формальную верификацию в протокол. Но обещанного три года ждут )
Несколько месяцев назад общались с сингапурскими студентами на эту тему, вот их проект тут на тему формальной верификации: www.comp.nus.edu.sg/~loiluu/oyente.html
Плюс пока искал наткнулся на еще один проект: securify.ch
А еще есть Tezos, которые обещают вставить формальную верификацию в протокол. Но обещанного три года ждут )
Не очень понятно, почему многие говорят про применение именно методов формальной верификации к этой задаче — далеко не всегда удобно составлять спецификацию контракта. Ну и контракты будут становиться больше, и формальную верификацию станет сложнее применять на практике.
Более того, ощущение, что иногда, говоря про формальную верификацию, на самом деле говорят про статический анализ (алгоритмы, взятые из теории построения компиляторов и примененные к поиску уязвимостей, багов и т.п.). Тот же самый securify, по ощущениям, проводят обычный статический анализ (как минимум наряду с попытками формальной верификации).
Мы вот в SmartDec давно занимаемся инструментами статического анализа, и, применив к Solidity, увидели, что это хорошо работает. Сейчас готовим первый релиз инструмента и научную статью на тему, но инструмент показывает уже лучшие результаты, чем у Oyente, Securify и Remix.
По понятный причинам за рынком инструментов мы следим, и видим, что вендоры начали этим заниматься. Однако на данный момент для смарт контрактов как никогда нужен ручной аудит кода на безопасность, и лично я бы рассматривал инструмент как помощь в этом деле.
Более того, ощущение, что иногда, говоря про формальную верификацию, на самом деле говорят про статический анализ (алгоритмы, взятые из теории построения компиляторов и примененные к поиску уязвимостей, багов и т.п.). Тот же самый securify, по ощущениям, проводят обычный статический анализ (как минимум наряду с попытками формальной верификации).
Мы вот в SmartDec давно занимаемся инструментами статического анализа, и, применив к Solidity, увидели, что это хорошо работает. Сейчас готовим первый релиз инструмента и научную статью на тему, но инструмент показывает уже лучшие результаты, чем у Oyente, Securify и Remix.
По понятный причинам за рынком инструментов мы следим, и видим, что вендоры начали этим заниматься. Однако на данный момент для смарт контрактов как никогда нужен ручной аудит кода на безопасность, и лично я бы рассматривал инструмент как помощь в этом деле.
Имхо неудачный пример с лотереей. Главное требование к смарт контрактам — что следующее состояние для нового блока вычисляется однозначно. Когда одна нода майнит следующий блок, то все остальные ноды перепроверяют транзакции внутри нового блока — повторяют вычисления смарт контрактов. При этом состояние транзакций обязано совпасть. Не понимаю как в данной модели можно впихнуть функцию «рандом» в вычисления.
ну можно что-то придумать, если погуглить, то несколько различных вариантов найдется. например как-то так:
1. игроки генерят N и «прикапывают»
2. хэшируют N и присылают хэши и депозиты в контракт
3. по достижению критерия (достаточно игроков или депозит достиг чего-то), N раскрывают и тоже присылают
4. каждая N проверяется на соответствие хэшу
5. дальше скажем все N как-нибудь обрабатываются. xor или еще можно что-то придумать
6. получаем в итоге некое случайное число и уже в зависимости от него решаем, кто победит.
схема может быть не идеальной, но варианты возможны.
1. игроки генерят N и «прикапывают»
2. хэшируют N и присылают хэши и депозиты в контракт
3. по достижению критерия (достаточно игроков или депозит достиг чего-то), N раскрывают и тоже присылают
4. каждая N проверяется на соответствие хэшу
5. дальше скажем все N как-нибудь обрабатываются. xor или еще можно что-то придумать
6. получаем в итоге некое случайное число и уже в зависимости от него решаем, кто победит.
схема может быть не идеальной, но варианты возможны.
Банально смотрим хэш предыдущего блока, это будет рэндомное число.
Можно еще примеры в коммерческой сфере? По указанной ссылке асе примеры чисто технические типа идентификации, сбора данных и тд. А до конца на практике как эио может быть применимо, если честно не совсем понятно. К примеру, как может применить такие контракты государство? Или же обычная коммерция, например аэрофлот?
ну например активно изучают применение для страховки опоздания рейсов. там выплаты небольшие и может показаться странным, что страховые компании хотят их выплачивать, так как это заметно повышает лояльность клиента. Сейчас чтобы получить такую выплату, необходимо оформить довольно много документов, а раз выплата небольшая, то этим пассажиры не занимаются. на смартконтрактах потенциально это можно заметно автоматизировать.
Проблема в том, что на самом деле применимость и, главное, преимущества смарт контактов очень условная и ограниченная. Примеры придумать можно, но в этих примерах не будет тех преимуществ перед аналогичными централизованными (условно) системами, которые так все сми расписывают.
Я с трудом придумал пару живых примеров на базе эфириума открытой сети, где хоть какие то преимущества остаются
если думать в рамках существующих бизнес сценариев, которые уже реализованы, то да, преимущество не очевидны и далеко не всегда смарт контракт нужен. тут надо думать в сторону новых сценариев, которые ранее не возможно было реализовать используя централизованную систему. например:
— спутники летают по орбитам и принадлежат разным странам, так как страны данные не шарят, потому что тайна, то спутники иногда сталкиваются
можно придумать алгоритм, при котором можно шарить траекторию спутника не раскрывая ее и отвечать на вопрос будут ли столкновения.
— спутники летают по орбитам и принадлежат разным странам, так как страны данные не шарят, потому что тайна, то спутники иногда сталкиваются
можно придумать алгоритм, при котором можно шарить траекторию спутника не раскрывая ее и отвечать на вопрос будут ли столкновения.
Немного дополню статью.
Смарт-контракты есть даже в биткоине.
На самом деле там нет передачи битков со счета на счет, а есть отправка монет на определенный скрипт, и воспользоваться ими (перевести еще куда-то) может только тот, кто может удовлетворить требованиям этого скрипта. Просто стандартный код скрипта это «нужна подпись с таким-то открытым ключом».
Язык «смарт-контрактов» в биткоине жутко урезан, и не является тьюринг-полным, и это не по недосмотру, а специально. Там вырезана любая возможность циклов и т.п. Нет команды перехода, только ветвление (либо эту цепочку либо эту).
Сделано это для того чтобы избежать бомб с зацикливанием. В эфире это решается при помощи газа, а тут простым запретом.
Но даже при таких ограничениях возможны довольно сложные алгоритмы.
Например недавно начали практиковать атомарный обмен. Т.е. обмен монет биткоина на монеты из другой криптовалюты (например Лайткоин который во многом идентичен биткоину) без взаимного доверия и использования бирж.
Или например легкая сеть — протокол при котором люди обмениваются монетами, но в блокчейн они транзакции не отправляют, а просто подписывают транзакции и отдают друг-другу. Магия в том что если кто-то не выполнит своих обязательств и опубликует что-то не то, то другой сразу опубликует свое, и получит больше чем тот. Достигается это тем что в скрипте есть несколько условий, например помимо подписи нужно опубликовать еще и сам ключ (или секретную фразу). Ну а на случай если что-то пошло не так, то отправитель может забрать деньги назад. Но… только спустя определенное время.
Не буду в комментарии расписывать механизм подробно ибо многобукв, гуглить atomic swap и lightning network.
Смарт-контракты есть даже в биткоине.
На самом деле там нет передачи битков со счета на счет, а есть отправка монет на определенный скрипт, и воспользоваться ими (перевести еще куда-то) может только тот, кто может удовлетворить требованиям этого скрипта. Просто стандартный код скрипта это «нужна подпись с таким-то открытым ключом».
Язык «смарт-контрактов» в биткоине жутко урезан, и не является тьюринг-полным, и это не по недосмотру, а специально. Там вырезана любая возможность циклов и т.п. Нет команды перехода, только ветвление (либо эту цепочку либо эту).
Сделано это для того чтобы избежать бомб с зацикливанием. В эфире это решается при помощи газа, а тут простым запретом.
Но даже при таких ограничениях возможны довольно сложные алгоритмы.
Например недавно начали практиковать атомарный обмен. Т.е. обмен монет биткоина на монеты из другой криптовалюты (например Лайткоин который во многом идентичен биткоину) без взаимного доверия и использования бирж.
Или например легкая сеть — протокол при котором люди обмениваются монетами, но в блокчейн они транзакции не отправляют, а просто подписывают транзакции и отдают друг-другу. Магия в том что если кто-то не выполнит своих обязательств и опубликует что-то не то, то другой сразу опубликует свое, и получит больше чем тот. Достигается это тем что в скрипте есть несколько условий, например помимо подписи нужно опубликовать еще и сам ключ (или секретную фразу). Ну а на случай если что-то пошло не так, то отправитель может забрать деньги назад. Но… только спустя определенное время.
Не буду в комментарии расписывать механизм подробно ибо многобукв, гуглить atomic swap и lightning network.
Sign up to leave a comment.
О смарт-контрактах простыми словами