Не буду комментировать весь тред, скажу лишь, что как раз вот такие вещи смарт-контракты позволяют делать удобно и дёшево:
1) замораживать средства;
2) размораживать только с подтверждения обеих сторон или арбитра;
3) позволять переводы только на определённые аккаунты (например, поставщика материалов);
4) предоставлять залог на случай мошенничества любого рода
и т.д.
Другими словами, грамотное использование смарт-контрактов позволяет не исключить мошенничество, но усложнить его (что тоже неплохо).
Кроме того, технически довольно просто в бумажном договоре отождествить стороны с адресами в блокчейне. А вот вопрос признания такого договора государственным судом — это уже вопрос не к смарт-контрактам, а к судебной системе.
Полностью поддерживаю ваши слова о том, каким должен быть язык смарт-контрактов.
Что касается формальной верификации: думают, наболее актуальная информация должна быть тут (сам ещё не слушал).
С точки зрения смарт-контракт — никак, т.к. мы уже за его пределами, на поле централизации. Но при этом на наши отношения с централизованным оракулом можно переносить все уже существующие практики: письменный договор, репутация, суд. Какую конкретно конфигурацию выбрать — зависит от конкретной задачи. Например, можно советовать просто обращаться к общепризнанному оракулу; такому, что для него прибыль от обмана будет меньше репутационных (и иных) издержек.
Проблема действительно фундаментальная. Будет она решена или нет, станет ли её нерешаемость принципиальной проблемой для смарт-контрактов — для меня вопросы открытые. Но как минимум можно говорить о том, что смарт-контракты позволяют если не избавиться от доверия, то уменьшить его (см. выше в комментариях кейс с гаражом). А также о том, что смарт-контракты, как и любой другой инструмент, следует использовать, помня о границах их применимости.
Ну и в любом случае остаётся ряд применений (непонятно, насколько полезных, но тем не менее), никак не завязанных на оракул: например, multisignature кошельки, токенсейлы, временная заморозка средств и т.д.
Совершенно верно, смарт-контракт выполнен, деньги ушли, тут уже ничего не поделаешь. Как оракулы поступают в такой ситуации на практике — интересный вопрос, сходу не отвечу (возможно, освещу в уже запрошенной выше следующей статье). Среди возможных способов решения: 1) неустойка, которую по сути и описали вы, 2) в принципе не полагаться на один оракул, а брать результат «голосования» нескольких. Но пока в случае ошибки оракула всё скорее всего на уровне «ну опаньки, бывает».
С точки зрения смарт-контракта уже ничего не исправить: данные попали в него, отыграть назад не получится (если только такой механизм явно не реализован в коде самого контракта). С точки зрения оракула — как минимум, этому оракулу перестанут доверять (по идее). Кроме того, оракул может, например, обещать неустойку в случае предоставления недостоверных данных (на практике не знаю таких). Но технически уже ничего не сделаешь. Оракул по сути и является single point of failure, тем самым местом, где мы вынуждены доверять (оракулу). Бороться с этим можно по-разному: например, использовать несколько оракулов и в качестве финального ответа брать результат их «голосования».
Если отвечать на него строго, то любая связь с внешним миром — это уже не смарт-контракт. Корректность обработки данных внутри смарт-контракта гарантирована математически (с оговорками); корректность внешних данных гарантирована математически быть не может. В строгом смысле в рамках смарт-контракта могут быть имлементированы только передачи эфиров/токенов по определённым заранее заданным правилам, в частности, игры (хотя, например, получение случайного числа внутри смарт-контракта — тоже нетривиальная задача).
Если же отвечать на вопрос с практических позиций, то сейчас связь с внешним миром реализована при помощи оракулов, подробней можно почитать, например, тут. В двух словах — с помощью third party контрактов, создатели которых зарабатывают тем, что помещают в блокчейн Эфириума достоверные данные о внешнем мире. Более детальный ответ заслуживает отдельной статьи.
Что касается двух предложенных кейсов:
1. Смарт-контракт сам не может выкачать данные по двум причинам: во-первых, он запускается не сам, а только по запросу пользователя (или другого контракта), во-вторых, он не может обращаться к внешнему миру. Так что, напротив, пользователь (или сервер) обращается к смарт-контракту, помещая в него данные. При этом технически гарантировать, что данные пришли именно из определённого источника (например, доверенного спортивного сайта) нельзя; но другие пользователи смогут проверить результат и сообщить, если оракул соврал. Соответственно, проблемы с выполнением смарт-контракта не возникает, т.к. это не он запрашивает данные с сервера, а сервер вызывает его; если сервер не отработает — не будет вызван контракт.
2. Статьи, которые ссылаются на то, что кейс с гаражом — это и есть область применимости смарт-контрактов, на мой взгляд ошибочны. Эта проблема действительно не решена и строго решена не может быть. Но можно говорить о том, что смарт-контракты не устраняют необходимость в доверии, а снижают её. Т.е. если раньше мне нужно было доверять, что а) в систему корректно будут введены данные об установке ворот, б) заказчик после этого преведёт деньги, то теперь б) автоматизировано, и доверять остаётся только в а).
Уточню, что мой ответ носит очень поверхностный характер. Хороший глубокий ответ — отдельная статья. Спасибо за вопрос и идею для статьи!)
Это правда, разговоров очень много, и, к сожалению, очень существенная часть — не по делу. Тем не менее трудно отрицать, что что-то из этого точно получится, а что именно — покажет время. Мы со своей стороны стараемся не фантазировать, а решать практическую задачу безопасности.
1) замораживать средства;
2) размораживать только с подтверждения обеих сторон или арбитра;
3) позволять переводы только на определённые аккаунты (например, поставщика материалов);
4) предоставлять залог на случай мошенничества любого рода
и т.д.
Другими словами, грамотное использование смарт-контрактов позволяет не исключить мошенничество, но усложнить его (что тоже неплохо).
Кроме того, технически довольно просто в бумажном договоре отождествить стороны с адресами в блокчейне. А вот вопрос признания такого договора государственным судом — это уже вопрос не к смарт-контрактам, а к судебной системе.
Что касается формальной верификации: думают, наболее актуальная информация должна быть тут (сам ещё не слушал).
Ну и в любом случае остаётся ряд применений (непонятно, насколько полезных, но тем не менее), никак не завязанных на оракул: например, multisignature кошельки, токенсейлы, временная заморозка средств и т.д.
Если отвечать на него строго, то любая связь с внешним миром — это уже не смарт-контракт. Корректность обработки данных внутри смарт-контракта гарантирована математически (с оговорками); корректность внешних данных гарантирована математически быть не может. В строгом смысле в рамках смарт-контракта могут быть имлементированы только передачи эфиров/токенов по определённым заранее заданным правилам, в частности, игры (хотя, например, получение случайного числа внутри смарт-контракта — тоже нетривиальная задача).
Если же отвечать на вопрос с практических позиций, то сейчас связь с внешним миром реализована при помощи оракулов, подробней можно почитать, например, тут. В двух словах — с помощью third party контрактов, создатели которых зарабатывают тем, что помещают в блокчейн Эфириума достоверные данные о внешнем мире. Более детальный ответ заслуживает отдельной статьи.
Что касается двух предложенных кейсов:
1. Смарт-контракт сам не может выкачать данные по двум причинам: во-первых, он запускается не сам, а только по запросу пользователя (или другого контракта), во-вторых, он не может обращаться к внешнему миру. Так что, напротив, пользователь (или сервер) обращается к смарт-контракту, помещая в него данные. При этом технически гарантировать, что данные пришли именно из определённого источника (например, доверенного спортивного сайта) нельзя; но другие пользователи смогут проверить результат и сообщить, если оракул соврал. Соответственно, проблемы с выполнением смарт-контракта не возникает, т.к. это не он запрашивает данные с сервера, а сервер вызывает его; если сервер не отработает — не будет вызван контракт.
2. Статьи, которые ссылаются на то, что кейс с гаражом — это и есть область применимости смарт-контрактов, на мой взгляд ошибочны. Эта проблема действительно не решена и строго решена не может быть. Но можно говорить о том, что смарт-контракты не устраняют необходимость в доверии, а снижают её. Т.е. если раньше мне нужно было доверять, что а) в систему корректно будут введены данные об установке ворот, б) заказчик после этого преведёт деньги, то теперь б) автоматизировано, и доверять остаётся только в а).
Уточню, что мой ответ носит очень поверхностный характер. Хороший глубокий ответ — отдельная статья. Спасибо за вопрос и идею для статьи!)