Comments 11
Да нифига они не умные, это слишком громкое название. Даже Бутерин говорил, что они погорячились с таким названием. Правильне их называть… хранимыми процедурами.
UFO just landed and posted this here
> застрахованный подкупит дежурного пожарного, и тот зафиксирует ложный страховой случай
Если вы об этом догадались подумать, страховая компания (или более релевантно — вкладчики в ICO / держатели токенов) тоже догадается.
> со службой такси
См выше. Очевидные проблемы не являются проблемами в данном случае. А неочевидные проблемы — которых я уверен мы увидим еще множество — со временем будут приниматься во внимание и последующие дизайны их будут учитывать.
> законы должны разрабатываться относительно независимыми экспертами в предметной области и юриспруденции;
Еда должна производиться профессиональными шеф-поварами. Это я к тому что в идеале кто что хочет то то и покупает.
> работа над разработкой, исполнением законов, контролем этого процесса и разрешением конфликтов отнимает значительное время, а потому делегируется обществом государственному аппарату
Планировка плантации и продажа урожая хлопка отнимает значительное время, а потому делегируется рабами хозяевам плантации. Ситуацию «подчиняйся или умри» мы не описываем словом «делегируется».
1. Мы не знаем как будут использоваться технологии в будующем. На данный момент львиная доля смарт-контрактов это ERC20 — кто мог такое предугадать пять лет тому назад? Следующая волна это децентрализированные обменники, всякие DeFi и MakerDao, плюс плазма и ей подобные решения.
2. Не хотите — не пользуйтесь. Это главное. Плохой инструмент? Не пользуйтесь. Критиковать кстати это нужно и важно, так что я не против критики разумеется — но и сравнивать добровольное с насильственным нужно учитывать эффекты насилия, то есть чего стоит и к чему приводит всё это простигоспади «государство».
Если вы об этом догадались подумать, страховая компания (или более релевантно — вкладчики в ICO / держатели токенов) тоже догадается.
> со службой такси
См выше. Очевидные проблемы не являются проблемами в данном случае. А неочевидные проблемы — которых я уверен мы увидим еще множество — со временем будут приниматься во внимание и последующие дизайны их будут учитывать.
> законы должны разрабатываться относительно независимыми экспертами в предметной области и юриспруденции;
Еда должна производиться профессиональными шеф-поварами. Это я к тому что в идеале кто что хочет то то и покупает.
> работа над разработкой, исполнением законов, контролем этого процесса и разрешением конфликтов отнимает значительное время, а потому делегируется обществом государственному аппарату
Планировка плантации и продажа урожая хлопка отнимает значительное время, а потому делегируется рабами хозяевам плантации. Ситуацию «подчиняйся или умри» мы не описываем словом «делегируется».
1. Мы не знаем как будут использоваться технологии в будующем. На данный момент львиная доля смарт-контрактов это ERC20 — кто мог такое предугадать пять лет тому назад? Следующая волна это децентрализированные обменники, всякие DeFi и MakerDao, плюс плазма и ей подобные решения.
2. Не хотите — не пользуйтесь. Это главное. Плохой инструмент? Не пользуйтесь. Критиковать кстати это нужно и важно, так что я не против критики разумеется — но и сравнивать добровольное с насильственным нужно учитывать эффекты насилия, то есть чего стоит и к чему приводит всё это простигоспади «государство».
А есть по этим проблемам книги, статьи? Мне кажется, вы подняли эту тему, но тут тянет на книгу)
Невозможность изменения контрактов после запуска, а также тот факт,
что на них могут храниться огромные суммы средств, иногда приводят к большим проблемам.
В одном из обновлений разработчики кошелька Parity,
в основе которого лежал смарт-контракт именуемый contract multiowned,
поменяли название его внутренней функции multiowned на initMultiowned.
Казалось бы, небольшое улучшение названия на более красивое…
Но до обновления эта функция совпадала с именем самого контракта,
что означало, что она была конструктором, и могла быть вызвана только один раз, сразу после деплоя.
После обновления, initMultiowned, разумеется, перестала считаться конструктором:
теперь эту функцию мог вызвать любой желающий.
Этот факт и выпал из внимания разработчиков.
А функция важная, так как она назначает всех администраторов кошелька, которые и управляют деньгами.
Последствия печальны: злоумышленник сработал оперативно, и за одну ночь отыскал в сети эфира вообще все существующие кошельки Parity (а это несколько тысяч смарт-контрактов), после чего избавил их от предыдущих хозяев. Общие потери составили около 100 миллионов долларов.
Гарантированно предотвратить подобные инциденты можно, только если писать код с математически доказанной надёжностью.
Но это приводит к десятикратному удорожанию разработки, и выходит далеко за рамки интеллектуальных возможностей подавляющего большинства крипто-деятелей.
Почему люди не используют формальные методы
что на них могут храниться огромные суммы средств, иногда приводят к большим проблемам.
В одном из обновлений разработчики кошелька Parity,
в основе которого лежал смарт-контракт именуемый contract multiowned,
поменяли название его внутренней функции multiowned на initMultiowned.
Казалось бы, небольшое улучшение названия на более красивое…
Но до обновления эта функция совпадала с именем самого контракта,
что означало, что она была конструктором, и могла быть вызвана только один раз, сразу после деплоя.
После обновления, initMultiowned, разумеется, перестала считаться конструктором:
теперь эту функцию мог вызвать любой желающий.
Этот факт и выпал из внимания разработчиков.
А функция важная, так как она назначает всех администраторов кошелька, которые и управляют деньгами.
Исходный код функции до и после
До:
После:
// constructor is given number of sigs required to do protected "onlymanyowners" transactions
// as well as the selection of addresses capable of confirming them.
function multiowned(address[] _owners, uint _required) {
m_numOwners = _owners.length + 1;
m_owners[1] = uint(msg.sender);
m_ownerIndex[uint(msg.sender)] = 1;
for (uint i = 0; i < _owners.length; ++i) {
m_owners[2 + i] = uint(_owners[i]);
m_ownerIndex[uint(_owners[i])] = 2 + i;
}
m_required = _required;
}
После:
// constructor is given number of sigs required to do protected "onlymanyowners" transactions
// as well as the selection of addresses capable of confirming them.
function initMultiowned(address[] _owners, uint _required) {
m_numOwners = _owners.length + 1;
m_owners[1] = uint(msg.sender);
m_ownerIndex[uint(msg.sender)] = 1;
for (uint i = 0; i < _owners.length; ++i) {
m_owners[2 + i] = uint(_owners[i]);
m_ownerIndex[uint(_owners[i])] = 2 + i;
}
m_required = _required;
}
Последствия печальны: злоумышленник сработал оперативно, и за одну ночь отыскал в сети эфира вообще все существующие кошельки Parity (а это несколько тысяч смарт-контрактов), после чего избавил их от предыдущих хозяев. Общие потери составили около 100 миллионов долларов.
Гарантированно предотвратить подобные инциденты можно, только если писать код с математически доказанной надёжностью.
Но это приводит к десятикратному удорожанию разработки, и выходит далеко за рамки интеллектуальных возможностей подавляющего большинства крипто-деятелей.
Почему люди не используют формальные методы
Честно говоря, пока не вижу примеров смарт-контракта, которые будут выполняться исключительно в пределах блокчейна. То есть, на входе и выходе будут сторонние данные, которые можно скомпрометировать, что снижает ценность смарт-контракта.
А что по поводу Теории игр?
Товар может продаваться через интернет по следующей схеме:
Вот тут таблица выигрышей продавца и покупателя для определения равновесия Нэша
Товар может продаваться через интернет по следующей схеме:
- При продаже товара у продавца и клиента замораживается депозит. У продавца 0,5 от суммы товара, а у покупателя 1,5 от суммы товара (т.е. всего 2-х кратная сумма).
- При получении товара, покупатель отправляет транзакцию — товар получен. Ему возвращается 0.5 суммы, а продавцу 1,5 части суммы (оплата за товар + возврат 0,5 депозита)
- Если покупатель не сообщает в блокчейн такую информацию, то оба лишаются средств: продавец 0,5 суммы + стоимость товара (если он его отправлял), покупатель 1,5 суммы денег (или за минусом стоимости товара — если товар все же получил). Таким образом покупателю и продавцу выгодно быть честным — отправить товар и подтвердить получение товара.
Вот тут таблица выигрышей продавца и покупателя для определения равновесия Нэша
А тут получается что покупателю нужно всегда говорить что товар получил, чтобы вернуть хотя бы 0,5 не зависимо от того получил или нет.
Но в любом случае пример надуманный, кто в здравом уме будет на это соглашаться?
Слишком сложно, можно эффективнее это делать через «доверенную третью сторону».
Вообще, блокчейн можно натянуть на что угодно, на какой угодно процесс. Весь вопрос в том, надо ли?
Вообще, блокчейн можно натянуть на что угодно, на какой угодно процесс. Весь вопрос в том, надо ли?
Ответ по поводу Теории игр в смарт контрактах...
Тут красота — в том, что здесь работает математика. Советую почитать по теорию игр хотя бы в Википедии. Также советую посмотреть лекции на ютубе Савватеева.
Основная идея если коротко: давайте возьмем миллион таких сделок и посмотрим что в итоге получилось с ними — мы увидим, что практически все будут сходиться к равновесию Нэша, т.е. продавцы и покупатели будут выбирать честную для них стратегию.
Конечно тут есть тонкий момент — возьмем миллион совершенных сделок. Их сейчас нет. Сейчас проблема яйца и курицы. Люди боятся пробовать так как нет опыта и нет успешной истории. А истории нет, так как никто так еще не делает.
Если подумать конструктивно — т.е. с точки зрения внедрения технологии блокчейн в экономику, то можно посоветовать:
1) Интернет-магазинам взять на себя риск нечестного поведения (например, мотивируя покупателя скидкой если он подтвердит получения товара).
2) Сумму депозита покупателя заложить в цену товара и возвращать ее покупателю при честном поведении
3) Ввести гибридную схему с эскроу, т.е. если покупатель не делает подтверждение — в игру вступает третья сторона. Причем систему эскроу сделать многоуровневую, возможность эскалации вплоть до создателя блокчейна (которому точно есть что терять).
P.S.
Здесь не может быть все сразу понятно. Это не пример. Это целая технология. А теория игр — целая наука. Здесь не может быть сразу все понятно.
Я понимаю что для внедрения данной схемы нужно еще много подумать, чтобы каждой домохозяйки было все четко понятно. Но это вопрос решаемый, раньше и компьютером не каждый мог пользоваться, а кто пользовался тот назвался программистом.
Вопрос в том, кто готов думать в этом направлении, есть на Хабре такие люди?
Тут красота — в том, что здесь работает математика. Советую почитать по теорию игр хотя бы в Википедии. Также советую посмотреть лекции на ютубе Савватеева.
Основная идея если коротко: давайте возьмем миллион таких сделок и посмотрим что в итоге получилось с ними — мы увидим, что практически все будут сходиться к равновесию Нэша, т.е. продавцы и покупатели будут выбирать честную для них стратегию.
Конечно тут есть тонкий момент — возьмем миллион совершенных сделок. Их сейчас нет. Сейчас проблема яйца и курицы. Люди боятся пробовать так как нет опыта и нет успешной истории. А истории нет, так как никто так еще не делает.
Если подумать конструктивно — т.е. с точки зрения внедрения технологии блокчейн в экономику, то можно посоветовать:
1) Интернет-магазинам взять на себя риск нечестного поведения (например, мотивируя покупателя скидкой если он подтвердит получения товара).
2) Сумму депозита покупателя заложить в цену товара и возвращать ее покупателю при честном поведении
3) Ввести гибридную схему с эскроу, т.е. если покупатель не делает подтверждение — в игру вступает третья сторона. Причем систему эскроу сделать многоуровневую, возможность эскалации вплоть до создателя блокчейна (которому точно есть что терять).
P.S.
Здесь не может быть все сразу понятно. Это не пример. Это целая технология. А теория игр — целая наука. Здесь не может быть сразу все понятно.
Я понимаю что для внедрения данной схемы нужно еще много подумать, чтобы каждой домохозяйки было все четко понятно. Но это вопрос решаемый, раньше и компьютером не каждый мог пользоваться, а кто пользовался тот назвался программистом.
Вопрос в том, кто готов думать в этом направлении, есть на Хабре такие люди?
Sign up to leave a comment.
Что такое смарт-контракты?