OAuth от гугл, фейсбука итд еще хорош и тем, что усложняет массовую регистрацию ботов, т.к. нужно попотеть еще с регистрацией там.
Если хотите заставить пользователя попотеть, всегда можно воспользоваться технологией типа этой github.com/poanetwork/poa-popa. Пользователь получает открытку по почте, вводит код с нее, профит. Бот не пройдет.
По факту защититься от ботов пока еще никто не смог. Все принимаемые меры просто удорожают создание аккаунта. В Ethereum если вы хотите сделать создание аккаунта дорогим, вы можете просто требовать перечислить эфир при его создании.
Ну вот и получается, что если ты потерял код/забыл пароль, то всё — аккаунт ты уже никак не восстановишь.
Потерять бумажку из сейфа примерно так же сложно как потерять номер телефона. А попробуйте гугл аккаунт восстановить без доступа к телефону, даже если помните пароль, но Google хочет убедиться что вы это вы. Это не придуманный кейс, это реальная проблема из моего опыта. Нерешенная.
Общая комиссия за газ в Вашем варианте больше. Разделение оплаты между всеми вроде как и честнее, но суммарно для участников менее выгодно.
Я за честность. Арбитр не должен платить за перечисление эфира другим участникам. Ваш вариант тоже имеет право на жизнь, но, как сказал однажды в своем докладе greediness «Решили так».
Откат всей транзакции — это не стандартный выход, а стандартное поведение функции transfer(). Которое да — при неправильном использовании ведёт к багам. Стандартный же выход (ИМХО) — простая техника pendingWithdrawals.
Погуглил по словам pendingWithdrawals и не нашел чего-то стандатрного. Можете описать алгоритм который имеете в виду или дать ссылку на стандарт? Для меня pending withdrawal это как раз вариант в котором тот кому причитается эфир сам отправляет транзакцию чтобы его забрать. Это и реализовано в контракте спора.
Спорный вопрос) Зачем усложнять код контракта, рискуя наплодить там дырок, если пользователю можно достаточно безболезненно просто создать новый контракт?
Согласен, вопрос спорный. Но как раз в этом случае мне показалось что удобство пользователя стоит некоторого усложнения логики.
Почему ставки оппонентов всегда должны быть равны? По-моему это сильное упущение.
Можно написать отдельный контракт который делает так. Просто не стояло такой задачи, поэтому сделали вариант наименее болезненный для конечного пользователя платформы. Ethereum, да и любая другая blockchain-сеть на сегодняшний день не слишком дружелюбны к пользователю. Людей которые понимают как этим пользоваться примерно как в начале 90-х было людей которые понимали как отправить электронную почту. Поэтому даже небольшое усложнение логики может стать препятствием на пути к использованию.
Почему вывод средств нужно запрашивать отдельно, если можно организовать вывод сразу на основании транзакции арбитра с решением? Заодно и уничтожение контракта выполнить.
Исполнение транзакции в ethereum стоит газа. Если сделать перечисление денег транзакцией арбитра, получится что за газ платит он, и от его комиссии съедается кусочек. При большой комисии это не проблема, но если арбитр зарабатывает понемногу на сотнях и тысячах споров, комиссия может стать ощутимой.
Кроме того, есть вопросы безопасности. Например, может быть так что на адрес одной из сторон эфир перевести не получилось. Стандартный выход при такой ситуации — откат всей транзакции. Если, допустим, оппонент не принимает эфир, арбитр не сможет вывести свой процент и все деньги навечно зависнут в контракте.
Ну и для ситуации когда арбитр вообще до дедлайна никаких транзакций не прислал все равно придется сделать вывод эфира каждым участником сделки самостоятельно.
Не проще ли вместо «State Version Number» просто запретить смену условий контракта?
Допустим я запускаю контракт спора с формулировкой «в декабре один биткойн будет стоить полмиллиона рублей». Ввожу дедлайн полгода, прописываю проценты, штрафы, и даже оппонета для спора нашел и вписал. Показываю контракт арбитру, он говорит все хорошо, только давай формулировку уточним: «в декабре 2018 один биткойн будет стоить не менее полумиллиона рублей». И тут выясняется что параметры контракта менять нельзя. Придется уничтожить этот контракт и запустить новый с другой формулировкой. Но зачем так делать, если можно достаточно безболезненно разрешить изменение параметров спора в ходе переговоров? Да, вводить state непривычно для сегодняшнего пользователя. Но так же непривычно для него то что нельзя редактировать параметры которые им же раньше были введены. Мы выбрали редактируемость, потому что вероятность того что пользователь ошибется в формулировке достаточно высока.
Названные это все же prediction market, и в статье нет упоминаний что данное решение лучше или хуже кого-то другого. Откуда вы делаете такие выводы?
И кто «вы» лучше? Если вы это Smartz.io, то сложно сравнивать, Smartz это маркетплейс где можно найти контракт удовлетворяющий запросам пользователя и развернуть свой инстанс с готовой админкой не обладая навыками программирования на solidity.
Для части споров можно заменить группу арбитров контрактом, использующим одного или нескольких оракулов.
Но в другой части споров этого сделать нельзя. Например, если я с другом (находясь, конечно, в гостинице) поспорил что он не сможет десять раз подряд зажечь свою зажигалку, оракула найти будет сложно. Легче найти ночного портье с кошельком в эфире.
Фишка в том что адрес арбитра здесь это адрес в эфире. Это может быть адрес кошелька за которым стоит живой человек, или адрес другого смарт-контракта, который умеет вызывать из нас несколько методов. Как работат этот контракт-арбитр вопрос открытый. Можно сделать оракул, можно голосование группы людей, ну или что-то другое что придет в голову.
Те проблемы, про которые вы говорите "каким-то образом гарантировать", решаются блокчейном из коробки. Все мы понимаем что Tim Towtdi еще не умер. Давайте обсуждать какую-то конкретную техническую альтернативу, потому что аргументы вида "это можно сделать и без блокчейна" пока разбиваются о логичный вопрос "а будет ли это 'без блокчейна' работать лучше/быстрее и будет ли оно проще/дешевле в реализации?".
Вот мы уже поняли что требования к системе примерно такие:
нужна гарантия того что на сервере выполняется тот код который заявлен (в любой момент времени существует гарантированный способ зафиксировать и проанализировать что именно сейчас выполняется, а лучше еще чтобы можно было узнать какая версия кода выполнялась месяц назад, и это может сделать кто угодно, а не только разработчик/maintainer ПО)
нужна гарантия того что данные попадут в систему (не будут отфильтрованы) и не будут изменены если уж они в систему попали
нужен доступ к данным по какому-то API, так чтобы любой желающий мог проверить что хранится в системе по конкретному счетчику.
запросов на запись пусть будет 2500/c, этого достаточно чтобы все население Швейцарии присылало данные с персонального счетчика раз в час.
Какую архитектуру предложите взамен описанной в этой статье и какие преимущества она даст?
Для меня проблема сейчас есть. Я каждый месяц смотрю глазами на счетчик и отправляю показания довольно неудобным способом. Мне нужна система которая избавляет меня от необходимости следить за отправкой данных. Если будет выбор между приватной системой и EOS-реализацией с открытым кодом, да еще с апишкой которая позволит не прикручивать вебсервер к дачику — я, конечно, выберу блокчейн.
Нельзя не заметить что статьи про то как написать hello world на solidity заполонили хабр, но это не основание говорить что блокчейн не нужен или что он чем-то хуже реализации . В данной задаче его применение как раз таки очень даже оправдано.
Сможет ли поставщик меня обмануть — это, пожалуй, офтопик (ну при чем тут тарифы и комиссии?). Как и вопрос кто будет делать так чтобы блокчейн применялся в конкретной задаче корректным способом. С блокчейном обмануть будет гораздо сложнее чем без него. Кстати, сама возможность валидации смарт контракта в блокчейне это еще один большой плюс в сравнении с закрытой реализацией.
Плохая — в EOS данные хранятся в памяти, поэтому хватить должно именно RAM-а, а не диска. В наши дни это примерно 32Гб на весь блокчейн, в недалеком будущем по мере роста объема данных назваются размеры RAM-а 1 или 2 Tb.
Хорошая — EOS поддерживает (по крайней мере собирается поддержать) InterBlockchainCommunication, и не ограничивается одним централизовнным mainnet-ом. Так, например, поставщик электроэнергии может поднять собственный кластер EOS, или же сделать по кластеру на город. В последнем случае в центральном кластере нужно агрегировать необходимые данные, а не хранить все.
Ну и 0.3с это особенность данного конкретного счетчика. Никто не запрещает отправлять данные на сервер раз в минуту или раз в час, для задачи с электричеством такая точность вполне достаточна, важнее всего что это происходит автоматизированно, и то что будучи переданной в EOS эта информация становится защищенной от подмены.
Надо конечно же понимать что EOS это еще молодая технология, продуктовых решений на ней пока не существует. То есть нельзя сказать что система A дает N транзакций в секунду, а система EOS дает M транзакций в секунду, и сравнить эти M и N. Но потенциал развития по производительности у EOS большой, и в основном по замыслу авторов он получится именно за счет IBC, то есть параллельного существования нескольхих скоростных блокчейнов обменивающихся информацией друг с другом с меньшей интенсивностью.
Сферический блокчейн в вакууме лучше централизованного сервера тем что в нем хранится история операций, которую крайне сложно переписать, особенно переписать так чтобы никто не заметил.
В данном случае в статье описано именно практическое применение. Я как потребитель хочу быть уверен что поставщик электроэнергии меня не обсчитывает, а поставщик хочет получать данные автоматизированно, без необходимости держать штат «надсмотрщиков». Как это сделать при помощи централизованного сервера — еще надо подумать. Как хранить — понятно, а как защитить даннные от подделки (любой из сторон) — это вопрос. Блокчейн позволяет решить эту проблему из коробки.
И кстати, чем в вашем представлении отличается централизованный сервер (во множественном числе — скажем 100 серверов) от EOS-кластера?
По факту защититься от ботов пока еще никто не смог. Все принимаемые меры просто удорожают создание аккаунта. В Ethereum если вы хотите сделать создание аккаунта дорогим, вы можете просто требовать перечислить эфир при его создании.
Потерять бумажку из сейфа примерно так же сложно как потерять номер телефона. А попробуйте гугл аккаунт восстановить без доступа к телефону, даже если помните пароль, но Google хочет убедиться что вы это вы. Это не придуманный кейс, это реальная проблема из моего опыта. Нерешенная.
Я за честность. Арбитр не должен платить за перечисление эфира другим участникам. Ваш вариант тоже имеет право на жизнь, но, как сказал однажды в своем докладе greediness «Решили так».
revert это не стандартное, а единственное поведение функции transfer. Безревертный аналог называется send. Я стараюсь учитывать рекомендации по разработке беопасных смарт контрактов, consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls. В данном случае не вижу причины чтобы их нарушать.
Погуглил по словам pendingWithdrawals и не нашел чего-то стандатрного. Можете описать алгоритм который имеете в виду или дать ссылку на стандарт? Для меня pending withdrawal это как раз вариант в котором тот кому причитается эфир сам отправляет транзакцию чтобы его забрать. Это и реализовано в контракте спора.
Согласен, вопрос спорный. Но как раз в этом случае мне показалось что удобство пользователя стоит некоторого усложнения логики.
Можно написать отдельный контракт который делает так. Просто не стояло такой задачи, поэтому сделали вариант наименее болезненный для конечного пользователя платформы. Ethereum, да и любая другая blockchain-сеть на сегодняшний день не слишком дружелюбны к пользователю. Людей которые понимают как этим пользоваться примерно как в начале 90-х было людей которые понимали как отправить электронную почту. Поэтому даже небольшое усложнение логики может стать препятствием на пути к использованию.
Исполнение транзакции в ethereum стоит газа. Если сделать перечисление денег транзакцией арбитра, получится что за газ платит он, и от его комиссии съедается кусочек. При большой комисии это не проблема, но если арбитр зарабатывает понемногу на сотнях и тысячах споров, комиссия может стать ощутимой.
Кроме того, есть вопросы безопасности. Например, может быть так что на адрес одной из сторон эфир перевести не получилось. Стандартный выход при такой ситуации — откат всей транзакции. Если, допустим, оппонент не принимает эфир, арбитр не сможет вывести свой процент и все деньги навечно зависнут в контракте.
Ну и для ситуации когда арбитр вообще до дедлайна никаких транзакций не прислал все равно придется сделать вывод эфира каждым участником сделки самостоятельно.
Допустим я запускаю контракт спора с формулировкой «в декабре один биткойн будет стоить полмиллиона рублей». Ввожу дедлайн полгода, прописываю проценты, штрафы, и даже оппонета для спора нашел и вписал. Показываю контракт арбитру, он говорит все хорошо, только давай формулировку уточним: «в декабре 2018 один биткойн будет стоить не менее полумиллиона рублей». И тут выясняется что параметры контракта менять нельзя. Придется уничтожить этот контракт и запустить новый с другой формулировкой. Но зачем так делать, если можно достаточно безболезненно разрешить изменение параметров спора в ходе переговоров? Да, вводить state непривычно для сегодняшнего пользователя. Но так же непривычно для него то что нельзя редактировать параметры которые им же раньше были введены. Мы выбрали редактируемость, потому что вероятность того что пользователь ошибется в формулировке достаточно высока.
И кто «вы» лучше? Если вы это Smartz.io, то сложно сравнивать, Smartz это маркетплейс где можно найти контракт удовлетворяющий запросам пользователя и развернуть свой инстанс с готовой админкой не обладая навыками программирования на solidity.
Но в другой части споров этого сделать нельзя. Например, если я с другом (находясь, конечно, в гостинице) поспорил что он не сможет десять раз подряд зажечь свою зажигалку, оракула найти будет сложно. Легче найти ночного портье с кошельком в эфире.
Фишка в том что адрес арбитра здесь это адрес в эфире. Это может быть адрес кошелька за которым стоит живой человек, или адрес другого смарт-контракта, который умеет вызывать из нас несколько методов. Как работат этот контракт-арбитр вопрос открытый. Можно сделать оракул, можно голосование группы людей, ну или что-то другое что придет в голову.
Те проблемы, про которые вы говорите "каким-то образом гарантировать", решаются блокчейном из коробки. Все мы понимаем что Tim Towtdi еще не умер. Давайте обсуждать какую-то конкретную техническую альтернативу, потому что аргументы вида "это можно сделать и без блокчейна" пока разбиваются о логичный вопрос "а будет ли это 'без блокчейна' работать лучше/быстрее и будет ли оно проще/дешевле в реализации?".
Вот мы уже поняли что требования к системе примерно такие:
Какую архитектуру предложите взамен описанной в этой статье и какие преимущества она даст?
Нельзя не заметить что статьи про то как написать hello world на solidity заполонили хабр, но это не основание говорить что блокчейн не нужен или что он чем-то хуже реализации . В данной задаче его применение как раз таки очень даже оправдано.
Сможет ли поставщик меня обмануть — это, пожалуй, офтопик (ну при чем тут тарифы и комиссии?). Как и вопрос кто будет делать так чтобы блокчейн применялся в конкретной задаче корректным способом. С блокчейном обмануть будет гораздо сложнее чем без него. Кстати, сама возможность валидации смарт контракта в блокчейне это еще один большой плюс в сравнении с закрытой реализацией.
Плохая — в EOS данные хранятся в памяти, поэтому хватить должно именно RAM-а, а не диска. В наши дни это примерно 32Гб на весь блокчейн, в недалеком будущем по мере роста объема данных назваются размеры RAM-а 1 или 2 Tb.
Хорошая — EOS поддерживает (по крайней мере собирается поддержать) InterBlockchainCommunication, и не ограничивается одним централизовнным mainnet-ом. Так, например, поставщик электроэнергии может поднять собственный кластер EOS, или же сделать по кластеру на город. В последнем случае в центральном кластере нужно агрегировать необходимые данные, а не хранить все.
Ну и 0.3с это особенность данного конкретного счетчика. Никто не запрещает отправлять данные на сервер раз в минуту или раз в час, для задачи с электричеством такая точность вполне достаточна, важнее всего что это происходит автоматизированно, и то что будучи переданной в EOS эта информация становится защищенной от подмены.
Надо конечно же понимать что EOS это еще молодая технология, продуктовых решений на ней пока не существует. То есть нельзя сказать что система A дает N транзакций в секунду, а система EOS дает M транзакций в секунду, и сравнить эти M и N. Но потенциал развития по производительности у EOS большой, и в основном по замыслу авторов он получится именно за счет IBC, то есть параллельного существования нескольхих скоростных блокчейнов обменивающихся информацией друг с другом с меньшей интенсивностью.
В данном случае в статье описано именно практическое применение. Я как потребитель хочу быть уверен что поставщик электроэнергии меня не обсчитывает, а поставщик хочет получать данные автоматизированно, без необходимости держать штат «надсмотрщиков». Как это сделать при помощи централизованного сервера — еще надо подумать. Как хранить — понятно, а как защитить даннные от подделки (любой из сторон) — это вопрос. Блокчейн позволяет решить эту проблему из коробки.
И кстати, чем в вашем представлении отличается централизованный сервер (во множественном числе — скажем 100 серверов) от EOS-кластера?