P2P-споры на блокчейне

[omgiafs]

Ну шо, кто первый запилит букмекерские конторы без возможности обмана клиента, в обход налоговой и прочего обвеса? Бегите пейсать код, хипстеры, ваш час пробил!

[BoogerWooger]

welcome, по сложившейся традиции, первый пост в статье про блокчейн принадлежит хейтерам

[rPman]

bitshares prediction market существует уже несколько лет, с ui обычной биржи (стакан, торги,..), при этом возможно использование не криптовалют с высокой волатильностью (+-10% за сутки — норма) а обеспеченных стаблкоин, usd и cny даже с неплохой ликвидностью, грубо говоря если вам надо делать ставки на десятки тысяч баксов (можно и больше но нужно понимать что такое ликвидность, иначе можно заплатить высокую комиссию в момент проблем, если вдруг понадобится запросить обеспечение в обход рынка), то велкам.

[robert_ayrapetyan]

Почему бы не заменить арбитра (человека) в данной схеме на оракула (скрипт)?

[mxpaul]

В статье так и написано

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

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

Фишка в том что адрес арбитра здесь это адрес в эфире. Это может быть адрес кошелька за которым стоит живой человек, или адрес другого смарт-контракта, который умеет вызывать из нас несколько методов. Как работат этот контракт-арбитр вопрос открытый. Можно сделать оракул, можно голосование группы людей, ну или что-то другое что придет в голову.

[Bloxy]

А чем это решение лучше чем Augur, Gnosis, Delphi? И это самые крупные — решений prediction market и betting тоже достаточно. Чем вы лучше?

[mxpaul]

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

И кто «вы» лучше? Если вы это Smartz.io, то сложно сравнивать, Smartz это маркетплейс где можно найти контракт удовлетворяющий запросам пользователя и развернуть свой инстанс с готовой админкой не обладая навыками программирования на solidity.

[Luxo]

Почему ставки оппонентов всегда должны быть равны? По-моему это сильное упущение.
Почему вывод средств нужно запрашивать отдельно, если можно организовать вывод сразу на основании транзакции арбитра с решением? Заодно и уничтожение контракта выполнить.
Не проще ли вместо «State Version Number» просто запретить смену условий контракта?

[mxpaul]

Почему ставки оппонентов всегда должны быть равны? По-моему это сильное упущение.

Можно написать отдельный контракт который делает так. Просто не стояло такой задачи, поэтому сделали вариант наименее болезненный для конечного пользователя платформы. Ethereum, да и любая другая blockchain-сеть на сегодняшний день не слишком дружелюбны к пользователю. Людей которые понимают как этим пользоваться примерно как в начале 90-х было людей которые понимали как отправить электронную почту. Поэтому даже небольшое усложнение логики может стать препятствием на пути к использованию.

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

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

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

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

Не проще ли вместо «State Version Number» просто запретить смену условий контракта?

Допустим я запускаю контракт спора с формулировкой «в декабре один биткойн будет стоить полмиллиона рублей». Ввожу дедлайн полгода, прописываю проценты, штрафы, и даже оппонета для спора нашел и вписал. Показываю контракт арбитру, он говорит все хорошо, только давай формулировку уточним: «в декабре 2018 один биткойн будет стоить не менее полумиллиона рублей». И тут выясняется что параметры контракта менять нельзя. Придется уничтожить этот контракт и запустить новый с другой формулировкой. Но зачем так делать, если можно достаточно безболезненно разрешить изменение параметров спора в ходе переговоров? Да, вводить state непривычно для сегодняшнего пользователя. Но так же непривычно для него то что нельзя редактировать параметры которые им же раньше были введены. Мы выбрали редактируемость, потому что вероятность того что пользователь ошибется в формулировке достаточно высока.

[BoogerWooger]

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

[Luxo]

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

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

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

Откат всей транзакции — это не стандартный выход, а стандартное поведение функции transfer(). Которое да — при неправильном использовании ведёт к багам. Стандартный же выход (ИМХО) — простая техника pendingWithdrawals.

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

Спорный вопрос) Зачем усложнять код контракта, рискуя наплодить там дырок, если пользователю можно достаточно безболезненно просто создать новый контракт?

[mxpaul]

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

Я за честность. Арбитр не должен платить за перечисление эфира другим участникам. Ваш вариант тоже имеет право на жизнь, но, как сказал однажды в своем докладе greediness «Решили так».

Откат всей транзакции — это не стандартный выход, а стандартное поведение функции transfer(). Которое да — при неправильном использовании ведёт к багам. Стандартный же выход (ИМХО) — простая техника pendingWithdrawals.

revert это не стандартное, а единственное поведение функции transfer. Безревертный аналог называется send. Я стараюсь учитывать рекомендации по разработке беопасных смарт контрактов, consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls. В данном случае не вижу причины чтобы их нарушать.

Погуглил по словам pendingWithdrawals и не нашел чего-то стандатрного. Можете описать алгоритм который имеете в виду или дать ссылку на стандарт? Для меня pending withdrawal это как раз вариант в котором тот кому причитается эфир сам отправляет транзакцию чтобы его забрать. Это и реализовано в контракте спора.

Спорный вопрос) Зачем усложнять код контракта, рискуя наплодить там дырок, если пользователю можно достаточно безболезненно просто создать новый контракт?

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

[Luxo]

Погуглил по словам pendingWithdrawals и не нашел чего-то стандатрного. Можете описать алгоритм который имеете в виду или дать ссылку на стандарт? Для меня pending withdrawal это как раз вариант в котором тот кому причитается эфир сам отправляет транзакцию чтобы его забрать. Это и реализовано в контракте спора.

что-то приблизительно такое:

contract ContractPendingWithdrawals {
  mapping (address => uint) public pendingWithdrawals;
  function transfer_safe(address addr, uint amount) internal {
    if (!addr.send(amount)) {
      pendingWithdrawals[addr] += amount;
    }
  }
  function withdrawPendingWithdrawal() external {
    amount = pendingWithdrawals[msg.sender];
    require(amount!=0);
    pendingWithdrawals[msg.sender] = 0;
    if (!msg.sender.call.value(amount)()) {
      revert();
    }
  }
}
contract MyContract is ContractPendingWithdrawals {
  ...
  transfer_safe(arbiter, 1 Ether);
  transfer_safe(opponent, 10 Ether);
  ...
}

[mxpaul]

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