Я это все вынес в другую статью, которую пока не опубликовал. Рассматривал способы повышения производительности блокчейн сетей. А так да, в биткойн тоже есть скрипты, это правда. спасибо за дополнение!

Вероятно да, что-то упускаю.

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

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

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

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

Напишу видимо отдельную статью еще =)

Ну и добавлю, одна из причини тормозящая развитие, это cost of adoption. Условно проблема же решается и сейчас? Переход на смарт контракт поможет сократить издержки вероятно (тоже под вопросом), но кардинально жизнь в данном кейсе не улучшит. Потому оно, безусловно, перспективно, но не везде и далеко не сразу.

что значит «нужен»? давайте рассуждать в условно математическом поле, результат голосования должен быть подсчитанным правильно, а стороны должны поверить в то, что подсчет правильный. Достичь этого можно двумя путями:
1. централизованный актор, которому все верят соберет голоса и выдаст ответ.
2. децентрализованно стороны проверят подсчеты друг друга и достигнут консенсуса.

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

— спутники летают по орбитам и принадлежат разным странам, так как страны данные не шарят, потому что тайна, то спутники иногда сталкиваются

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

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

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

ну он виден всем, нужен все же вариант, который никому заранее не виден.

ну можно что-то придумать, если погуглить, то несколько различных вариантов найдется. например как-то так:

1. игроки генерят N и «прикапывают»
2. хэшируют N и присылают хэши и депозиты в контракт
3. по достижению критерия (достаточно игроков или депозит достиг чего-то), N раскрывают и тоже присылают
4. каждая N проверяется на соответствие хэшу
5. дальше скажем все N как-нибудь обрабатываются. xor или еще можно что-то придумать
6. получаем в итоге некое случайное число и уже в зависимости от него решаем, кто победит.

схема может быть не идеальной, но варианты возможны.

да, есть такое, вот например исследование: www.cs.umd.edu/~aseem/solidetherplas.pdf

Несколько месяцев назад общались с сингапурскими студентами на эту тему, вот их проект тут на тему формальной верификации: www.comp.nus.edu.sg/~loiluu/oyente.html

Плюс пока искал наткнулся на еще один проект: securify.ch

А еще есть Tezos, которые обещают вставить формальную верификацию в протокол. Но обещанного три года ждут )

вы конкретно про банки или вообще? я вообще отвечу. на вскидку вот список обширный: www.cryptocoinsnews.com/smart-contracts-12-use-cases-for-business-and-beyond

другой пример: голосование акционеров и контроль подсчета голосов.

но надо, конечно, отдавать отчет, что во многих случаях очень часто все упирается у регуляторку и опасения участников.

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

корректно тогда уж порассуждать о затратах банков на обслуживание свое инфраструктуры.

да мне кажется ставить вопрос ребром в вакууме хороша открытость или нет в корне неправильно. в каких-то сценариях хороша, в каких-то нет.

Это правда и это действительно компрометирует идею, но в том же кейсе появился независимый форк, который вполне себе живет. То есть как бы и тут демократия и распределенность. Плюс болезни роста.

Как верно пишут, ценность заключается в кол-ве транзакций, которая сеть проводит. Это как бы ее «польза». Если упрощенно, чем больше транзакций — тем больше пользы. Плюс скидка на высокую спекулятивность рынка в данный момент.

примерно 7-10, больше уже плохо.

да, альфа, бета1, бета2, бетаN, RC, RTM, GA. обычно примерно так.

первый абзац: Есть определенные задачи на конкретных людей(Вася занимается вот этой историей, Сергей вот этой), а есть задачи на всю команду, которые складываются из задач конкретных людей. Например чтобы сделать историю, надо закончить девелопмент задачи, протестировать ее, покрыть автотестами. Это все делают зачастую разные люди. Но им надо понимать, что они в одной лодке и должны закончить конкретную историю.

второй абзац: Версии в SVN, каждые полчаса проверка сборки билда и урезанный набор тестов. Каждую ночь полная пересборка и прогон большого BVT, два раза в неделю прогон «Общих» автотестов, он занимает до полутора суток. Таким образом тестируется регрессия. Оно делается не для каждого изменения, так как за день может быть несколько комитов, но все же довольно часто. Есть еще ручное тестирование, там отдельные уровни тестирования.

третий абзац: Да, не про скрам, ну так я и описывал как мы эволюционировали =). Нам как раз нужна быстрая адаптация к новым требованиям. Ну вероятно можно сказать относительно быстрая, но все же. Спецификации и мокапы да, стараемся писать до начала спринта, но не всегда получается. Выходим из ситуации рассказывая на грумингах как и что собираемся сделать.

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

чтобы понять где находится весь проект, мы используем burn-down на весь проект. Он, конечно, дает весьма примерное понимание, но так как у нас проект сопровождается постоянными изменениями, то в целом этого достаточно.