Как стать автором
Обновить

Комментарии 70

Все перечисленные пункты и сейчас возможны, и без Prover. И у меня вопрос, как создатели собираются убедить всех участников (бизнес и власть) доверять Prover? Такая система возможна только при наличии доверия к ней, а это как раз и не описано.
Доверие к Prover будет основано на открытых алгоритмах и их открытой реализации, которая будет размещена в github. С властью действительно сложно, но бизнес, когда поймет, что использование технологии упрощает и удешевляет их бизнес-процессы, дополнительных аргументов, уверен, не потребуется!
Бизнес доверяет тому с чем можно пойти в суд. Открытые алгоритмы и их реализация к таким вещам не относятся. Если власть пропишет в законе что суд может опираться на Prover — то да, тогда будут использовать. В противном случае, и пальцем не пошевелят.
Такая точка зрения тоже имеет право на жизнь, но наш опыт общения с теми же страховыми компаниями показывает, что деньги решают. Это вопрос регулирования договорных отношений с клиентом. А открытые алгоритмы — это лишь доверие к самой технологии.
Открытые алгоритмы не дают доверия к программному обеспечению, среднестатистический бизнесмен не умеет читать исходный код и не разбирается в алгоритмах, ему все равно что находится у вас в гитхабе, его интересует ответственность в случае если программное обеспечение ошибется, бизнесу нужны гарантии.

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

Как вы планируете 100% идентифицировать устройство? Если мне удастся узнать идентификатор чужого устройства и подсунуть его программе, как вы будете это определять?

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

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

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

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

Тут важно понимать, что любая метаинформация для нашей технологии вторична, т.е. ее действительно легко подделать. Решающим является видеоконтент — его подделка несоизмеримо сложнее. Именно поэтому введенный swype код является именно частью видеоконтента. Люблю приводить пример с геотегом — любые вкоряченные в запись gps координаты несложно подделать, но вот если навести камеру во время съемки на номер дома и название улицы — значительно секьюрнее.

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

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

Блокчейн тут насколько я понимаю только для того чтоб видео не было изменено уже после съемки.

Это слишком простой кейс. Существенно важнее, что видео не было снято заранее, т.е. в блокчейне фиксируется также время выдачи swype кода, который не мог быть известен пользователю заранее, следовательно, если он присутствует на видео (в видеопотоке), то видео не могло быть сделано заранее. Общая идея очень похожа на то, что использовал Ассанжд, чтобы доказать, что он жив http://www.coindesk.com/julian-assange-just-read-bitcoin-block-hash-prove-alive/
Это слишком простой кейс. Существенно важнее, что видео не было снято заранее, т.е. в блокчейне фиксируется также время выдачи swype кода, который не мог быть известен пользователю заранее, следовательно, если он присутствует на видео (в видеопотоке), то видео не могло быть сделано заранее. Общая идея очень похожа на то, что использовал Ассанжд, чтобы доказать, что он жив http://www.coindesk.com/julian-assange-just-read-bitcoin-block-hash-prove-alive/

Так просто будут делать видео заведомо лучшего качества и с нескольких точек, а потом ухудшать и имитировать swype с «естественным» дрожанием и прочим. При открытых исходных кодах можно тестировать своё ПО для имитации на своих вычислительных мощностях, не рискуя встревожить команду prover. В общем, подделку в результате будет реально сделать, но очень дорого. Тем более, что вряд ли найдётся энтузиаст, который напишет ПО для создания подделок, выложит в OpenSource и как‐то убедит вас закрыть на это глаза и не придумывать контрмеры.

Ну это вечная борьба добра со злом :)

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


А как ваша программа поведет себя при отсутствии подключения к интернету? Получит ли пользователь код? И будет ли видео считаться подлинным?


Ну и мне показалось или я где-то читал, что это будет открытый исходный код? Тогда почему бы мне не модифицировать код на получение определенного токена? Какая вообще защита ПО от модификации?

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

Монтаж монтажу рознь. Закрывание номеров мы и сами делали, прекрасно в режиме реального времени работает. Немного нашего бэкграунда — http://nordavind.ru/node/102. Выправить в режиме реального времени крыло помятой машины — будет либо дорого, либо сильно заметно:)

А как ваша программа поведет себя при отсутствии подключения к интернету? Получит ли пользователь код? И будет ли видео считаться подлинным?

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

Ну и мне показалось или я где-то читал, что это будет открытый исходный код? Тогда почему бы мне не модифицировать код на получение определенного токена? Какая вообще защита ПО от модификации?

У нас есть патент.
А как патент защитит вас от модифицированного клиента который отправит вам ложные данные? Согласно вашим алгоритмам это будет вполне себе подлинная запись.
Тогда поясните, что значит:
почему бы мне не модифицировать код на получение определенного токена?
Реверс-инженеринг, зашить в программу конкретный свайп-токен. Он заранее известен, снимаешь видео и накладываешь токен.
Кстати все же интерестно, что если поток будет браться не с камеры а с уже снятого видео? Я так понимаю именно для этого и создаются свайп-токены?
Swype код генерируется смартконтрактом, им же запоминается. Нам все равно, что происходит на стороне клиента, чтобы этот swype попал в видеоконтент (физически присутствовал на виде). Смысл программы на стороне клиента, помочь ему увидеть, что он все делает правильно и те же самые открытые алгоритмы на стороне того, кто будет проверять подлинность, дадут тот же результат.
открытый код ничем не поможет, пока пользователь не сможет загрузить самостоятельно весь стек бинарников на устройство

у вас x86 железо с opensource bios?

нет? тогда забудьте про какие то гарантии
Информационная безопасность тут вообще не причем:) (убил 10 лет своей жизни на работу с госзаказчиками по этому направлению). Неважно, какое у нас железо. Мы говорим про алгоритмы видеоанализа, которые отрыты, чтобы быть потенциально понятными и пользователям и использующему их бизнесу.
эээ, а причем тут бардак и доказательство подлинности видео? оно ну никак не корелирует.
Скажем, если например, Усманов — честнейший человек, купит Prover — это поможет убедить бизнес и власть? хм…
Усманов может убедить власть и без покупки Prover )))) А доказательством честности у него выступает налоговая отчетность, пока работает круче, чем Prover, правда, без блокчейна. )))
А для чего ICO в таком проекте? Чтобы у разработчиков были деньги на разработку? И что потом вкладчикам делать с этими очередными N-сотыми токенами, торговать ими?

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

Имхо, навязчивая мода на эти ICO превращает создание действующего проекта в создание простенького сайта и написания white_paper…
Это не просто фандирование разработки, хотя это тоже имеет место быть. У нас есть замкнутая экономика токенов и понимание, почему стоимость токенов будет расти. В рамках Prover мы создаем технологический слой, который будет использоваться для построения прикладных решений (страхование, видеодоговора и проч.). Прикладные сервисы будут покупать услуги Prover-а за токены. Чем больше прикладных сервисов, тем больше предоставляемая Prover-ом ценность для реального мира, а при ограниченной эмиссии токенов это будет приводить к росту их цены.
А для чего ICO в таком проекте?
Scam?
Кроме шуток, нет ни одного другого довода «за» использовать именно такой метод «финансирования». Если им для работы нужна криптовалюта (о чем весь предыдущий комментарий) — не обязательно ее продавать до запуска проекта, разве что кому-то очень хочется денег, да заранее
ICO — это не только метод «финансирования», также как краудфандинг — это часть не сбор средств для создания продукта (зачастую уже почти созданного). Эти инструменты — это замечательный пиар проекта/продукта в мировом масштабе.

Ну а скамом все-таки наш проект не является. Никакого обмана у нас нет. Мы делаем технологию с понятным назначением, создаем замкнутую экономическую систему с понятным структурированием токенов и т.п.
замечательный пиар проекта/продукта в мировом масштабе
Нет, на поезд уже опоздали, сейчас это больше анти-пиар, слишком много компаний слилось, слишком много даже не создалось
Никакого обмана у нас нет
Заранее это, к сожалению, неизвестно. Вон вы пишете, что цена вырастет. При этом читающему стоит самому додумывать звездочку, под которой будут пункты «если запустимся», «если запустимся успешно», «может быть, и не вырастет вообще»
скамом все-таки наш проект не является
Надеюсь (иначе совсем грустно), и вы правда что-то будете делать и даже сделаете. Но если вы не хотите, чтобы проект называли так — не стимулируйте искуственно продажу токенов, не обещайте, что их цена вырастет, а также не называйте их инвестицией. А еще круче — не продавайте их до появления связанного продукта
осталось перенести серверы в росию
Как предусмотрена борьба с тем, чтобы записать исходное видео в 4к, воспроизвести на качественном проекторе, а потом просто в меньшем разрешении снять часть экрана, водя по нему в соответствии с алгоритмом?
Очень люблю этот вопрос, его обычно задают люди, которые поняли суть проекта :) Это действительно одна из ключевых проблем, над решением которой работают наши математики. Есть вариант потребовать при «вводе» swype двигать смартфон не в одной плоскости, а обеспечивать наклоны вверх-вниз и повороты влево-вправо. Но мы пытаемся все-таки пока анализировать различные геометрические искажения, которые возникают при реальном движении и при съемке «с экрана». Это хорошая научная задача и у нас есть серьезные математики для ее решения!

А что со съёмкой во время движения? И с ней же, но для случая «часть объектов неподвижна относительно оператора, часть двигается»? Из списка как минимум играм должно понадобится, чтобы не заставлять пользователей замирать почём зря. Автострахованию, если вы как‐то прикрутите непрерывную съёмку, хотя с ней проще использовать второй способ.


С непрерывной съёмкой вообще как: можно будет ехать с видеорегистратором и отправлять видео в prover? А сделать в магазине камеру с сервоприводами, которая будет выполнять swype и отправлять видео (иначе она вообще не будет двигаться и «второй способ» будет бесполезен)? Или инфраструктура не справится? Если prover станет легальным доказательством подлинности видео вполне может начаться процесс, при котором такая съёмка станет вынужденной мерой, т.к. видео без prover не будут верить.


И, третье, непрерывная локальная съёмка — есть? Т.е. ваше ПО, но всё полностью на своих серверах, для работы в организациях, где посторонним видео видеть нельзя, но проверить, не подменяют ли его, хочется.

Интересные кейсы! :) Возможно, к ICO появятся новые главы в white paper, спасибо :)
Сама идея хороша, но есть концептуальные проблемы. Данные всех датчиков можно эмулировать, например, GPS, привет Покемоны )) И вообще, доверие к тому что приходит от клиентского устройства, весьма странная штука для удостоверяющего сервиса. Если и хэш файла берется на устройстве, т.е. файл не пересылается на сервер, то достоверными будут только факт отправки этого хэша и время отправки.
НЛО прилетело и опубликовало эту надпись здесь
Важно два таймштампа:
1. Время получения swype-кода, который должен оказаться непосредственно в видеоконтенте, что гарантирует, что этот видеоконтент не мог быть сформирован ранее времени, когда этот код был сгенерирован.
2. Время загрузки хэша файла, что гарантирует, что файл не был сформирован позже.

Понятно, что времени «выравниваются» по времени блока в конкретном блокчейне.
У меня тут просто куча вопросов:

1. На рутованом телефоне (или вообще в эмуляторе) я могу скормить приложению вообще всё что угодно. Как вы планируете бороться с этим? (на самом проблема шире — мне не нужен ни телефон с эмулятором, ни ваше приложение вообще, та как протокол открыт).

2. Двойное интегрирование данных с MEMS-сенсоров. Вы точно уверены? Точнее не так: на каком временном промежутке вы собираетесь интегрировать данные? Напоминаю, что точность MEMS сенсоров в телефонах оставляет желать лучшего. Особенно на длительных временных промежутках.

3. Визуальный контроль swype. Я снимаю 4К видео на камеру с широкоугольным объективом (или вообще с рыбьим глазом). Информации в этом видео будет достаточно для эмуляции swype-кода (т.е. я могу кропнуть видео и двигать кропнутый регион по полному кадру для повторения swype-кода). Как вы планируете бороться с таким подлогом?

4. Отказ от авторства. Зная IMEI чужого телефона, я могу создать видео «снятое» с этого телефона. Или это не проблема в вашей системе?

5. Автоматические (да и ручное тоже) детектирование склеек. Видели как камера слепнет при резком изменении освещенности? Например, при выходе из помещения на улицу. Как планируете бороться с этим?

6. Оффлайн работа. Я понимаю, что это в принципе невозможно. Но это несколько ограничивает спектр возможных применений.

4К и широкоугольника не должно быть достаточно, ваш “swype” будет двигаться в одной плоскости и при достаточно хорошем видео это должно быть можно засечь «математическим аппаратом» по видео, если он способен проверить движение по трём координатам. А 6. может дать сильно много времени на создание подделки.


С остальными пунктами согласен, но в любом случае система не выглядит как что‐то абсолютно непрошибаемое. Особенно, если исходные коды реализации проверки будут доступны. Сделать подделку дорогой и требующей больших вычислительных мощностей — prover сможет, если их «математический аппарат» работает. Но сделать подделку требующей больше вычислительной мощности, чем есть у всего человечества на данный момент — вряд ли.


И ещё есть интересный вопрос про уровень ложноположительных и ложноотрицательных срабатываний проверок на подлинность — это самый критичный из теоретических вопросов, без исследования которого допускать систему никуда нельзя. Хотя без готового ПО можно определить разве что нижнюю границу, проблема командой никак не упоминается.

4К и широкоугольника не должно быть достаточно, ваш “swype” будет двигаться в одной плоскости и при достаточно хорошем видео это должно быть можно засечь «математическим аппаратом» по видео, если он способен проверить движение по трём координатам.

На самом деле тот же «математический аппарат» работает и в другую сторону. До некоторых пределов, но тем не менее.
Есть методы, которые позволяют построить трехмерную сцену по видео. Это поможет при симуляции изменения перспективы при параллельном движении.

Сделать подделку дорогой и требующей больших вычислительных мощностей — prover сможет, если их «математический аппарат» работает.

Я уверен, что не они первые пытаются определить подлинность видео математически. Об особых прорывах в этой области пока не слышно. Собственно, сейчас это делается исключительно с помощью экспертов. Будет здорово, если у них что-то получится. Но эта задача очень далека от блокчейнов и умных контрактов.

Пока что у них есть только надежный способ доказать что конкретный хеш был посчитан в между моментами времени t1 и t2. Все остальное — из области вероятностей.
Т.е. да, использование «swype» позволяет утверждать что скорее всего видео было снято между t1 и t2. Но 100% гарантии нет. И, соответственно, это может быть опротестовано в суде.
Т.е. да, использование «swype» позволяет утверждать что скорее всего видео было снято между t1 и t2. Но 100% гарантии нет. И, соответственно, это может быть опротестовано в суде.

С prover вам в суде, в идеале, для опротестования придётся доказывать, что вы перешли дорогу на несколько сотен килобаксов кому‐то, у кого есть или может быть команда разработчиков, сама обходящаяся ещё на несколько порядков дороже. Если, конечно, судья понимает, сколько и чего стоит подделка видео для prover и она будет реально столько стоить. Это автоматически закроет возможность опротестовать видео во многих делах.


А 100% гарантии нет и для хешей. Просто я сейчас вижу ситуацию так: для подделки хешей вам придётся либо слетать в будущее, либо найти инопланетян с намного более мощными суперкомпьютерами (либо найти уязвимость в алгоритмах, но её наличие не гарантированно). А с prover вам будет нужна команда высококлассных разработчиков, неплохой, но вполне доступный сервер, заточенный под обработку графики и работу с программами prover и, возможно, профессиональное оборудование для съёмки поддельного видео. Ну и немного здравого смысла, чтобы не снимать ночью подделку под день или что‐то вроде этого — т.е. для не допущения ошибок, которые может определить человек, но не алгоритмы prover.

Нет, постойте. Можно считать что хеш абсолютно надежен на текущей степени развития научно-технического прогресса (если вы конечно не используете MD5). Эта часть меня устраивает.
Дальше в игру вступает экспертная оценка видео командой prover. Потому что суду пофигу на математику, если честно. Алгоритмы не судят. Суду нужен эксперт, который лично заверит что не нашел следов подделки на указанном видео (и будет отвечать за свои слова своей свободой, кстати).

Такие эксперты существуют и сейчас. Соответственно, ценность вашего продукта состоит в фиксации времени криптографическими методами и в упрощении работы экспертов с помощью алгоритмов, которые вы разрабатываете.
Давайте суды вынесем пока за скобки:) Нормативно-правовые вопросы — это задачи политиков и юристов, а мы техникой занимаемся. И эта техника вполне может быть встроена в бизнес-процессы, а в этом случае бизнес уже говорит клиенту «верю» или «не верю».
Ну вы сами привели пример с судом :)

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

А если шансов попасть в суд нет (например, в договоре написано что клиента всегда неправ), то какой смысл им привлекать третью сторону в свои отношения? Разве что в качестве конкурентного преимущества. Это да — это может сработать.
Разве что в качестве конкурентного преимущества. Это да — это может сработать.

Вот я именно об этом!
1. На рутованом телефоне (или вообще в эмуляторе) я могу скормить приложению вообще всё что угодно. Как вы планируете бороться с этим? (на самом проблема шире — мне не нужен ни телефон с эмулятором, ни ваше приложение вообще, та как протокол открыт).

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

2. Двойное интегрирование данных с MEMS-сенсоров. Вы точно уверены? Точнее не так: на каком временном промежутке вы собираетесь интегрировать данные? Напоминаю, что точность MEMS сенсоров в телефонах оставляет желать лучшего. Особенно на длительных временных промежутках.

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

3. Визуальный контроль swype. Я снимаю 4К видео на камеру с широкоугольным объективом (или вообще с рыбьим глазом). Информации в этом видео будет достаточно для эмуляции swype-кода (т.е. я могу кропнуть видео и двигать кропнутый регион по полному кадру для повторения swype-кода). Как вы планируете бороться с таким подлогом?

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

4. Отказ от авторства. Зная IMEI чужого телефона, я могу создать видео «снятое» с этого телефона. Или это не проблема в вашей системе?

Это не задача и не проблема нашей технологии.

5. Автоматические (да и ручное тоже) детектирование склеек. Видели как камера слепнет при резком изменении освещенности? Например, при выходе из помещения на улицу. Как планируете бороться с этим?

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

6. Оффлайн работа. Я понимаю, что это в принципе невозможно. Но это несколько ограничивает спектр возможных применений.

Пока да.
Ага. Т.е. если отбросить маркетинговую шелуху, то получается что блокчейн вам нужен для двух вещей: зафиксировать момент получения хеша видео и зафиксировать момент создания задачи для видео-оператора. Это очень хитрый ход, вне всяких сомнений. Раньше для фиксирования времени события приходилось пользоваться сторонними сервисами.

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

(а за рабочую ИНС на MEMS-датчиках вас расцелуют все коптероводы)
Ага. Т.е. если отбросить маркетинговую шелуху, то получается что блокчейн вам нужен для двух вещей: зафиксировать момент получения хеша видео и зафиксировать момент создания задачи для видео-оператора. Это очень хитрый ход, вне всяких сомнений. Раньше для фиксирования времени события приходилось пользоваться сторонними сервисами.

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

Сопоставимых — да.

Но я несколько раз натыкался на службы, которые своим авторитетом подтверждали время наступления определенного события. Собственно, наверное, все знают про трюк с отправкой письма самому себе. Но там точность, конечно, в пределах суток-двух. А в эру интернета были сайты которые гарантировали точность в секунды. Но не могу найти ничего подобного сейчас. Да и блокчейн надежней.
Фотография с газетой за сегодняшний день и часами. Сейчас вполне себе используется. :)
Да, можно по старинке :)
Обращение к контракту Эфириума через мобильное устройство сейчас чуть менее сложно, чем подделка видео. Если я всё правильно понял, то все данные сначала проходят через какой-то сервер, прежде чем сохраниться в контракте.
Получается, что система не является децентрализованной и блокчейн нужен только для внутренней валюты и краудфандинга?
Обращение к контракту Эфириума через мобильное устройство сейчас чуть менее сложно, чем подделка видео.

Это решаемо, но не обязательно.

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

Блокчейн нужен в качестве ДЕЦЕНТРАЛИЗОВАННОЙ БД для надежного доверенного хранения информации о сгенерированном swype-коде, времени его генерации и времени загрузки хэша. Архитектура конкретного прикладного решения может меняться, но блокчейн в качестве БД останется ядром любой из них.
Смутило, что запись в БД происходит только через один узел. Но это вряд ли проблема.

По поводу swype-кода тоже есть вопрос. Что если пользователь с заранее подготовленным видео будет говорить серверу о том, что он начинает съемку, до тех пор, пока не вернется нужный swype-код, который у него уже записан?

И не слишком ли дорого будет обходиться контракт в Эфириуме? При нынешней реализации контракта генерация swype-кода будет стоить 40911 gas. За 10.000 вызовов будет затрачиваться примерно 350$ со средней скоростью выполнения. А еще ведь запись хэшей и хранение данных.
По поводу swype-кода тоже есть вопрос. Что если пользователь с заранее подготовленным видео будет говорить серверу о том, что он начинает съемку, до тех пор, пока не вернется нужный swype-код, который у него уже записан?

Это может оказаться дорого, как Вы сами заметили:) Ну и сервис/смартконтракт может смутить такой «перебор» вариантов. Ну и можно посчитать, сколько вариантов надо перебрать, даже если подбираем swype и 5 цифр:)

И не слишком ли дорого будет обходиться контракт в Эфириуме? При нынешней реализации контракта генерация swype-кода будет стоить 40911 gas. За 10.000 вызовов будет затрачиваться примерно 350$ со средней скоростью выполнения. А еще ведь запись хэшей и хранение данных.

Совершенно согласен! Экономически более целесообразным может оказаться использование других блокчейнов, в частности мы планируем сразу после Ethereum делать реализацию на Emercoin.
По поводу того же газа:
Так как все запросы идут через сервер, то остается два варианта оплаты работы майнеров:
1. Оплачивать самостоятельно бесчисленные операции пользователей, в том числе вероятный спам.
2. Получать доступ к кошелькам пользователей, что, как мне кажется, противоестественно.
В любом случае это пугающая перспектива для монетизации, судьба которой лично для меня пока не ясна.
Единственное, что я тут вижу — сокращение расходов на экспертизу видео-материалов. Но это обеспечит третий этап проекта с разработкой алгоритмов для определения подлинности. Часть проекта, которая работает на блокчейне, если мы отбросим все мелкие сомнения, подтверждает только время начала съемки конкретного видео. В то же время, она имеет постоянные расходы на газ, в отличие от алгоритмов из третьего этапа.
Получается, что либо PROOF будет резервом для газа, либо придется брать плату с пользователей за каждое действие. Причем, на ранних стадиях проекта, вряд ли последний вариант будет иметь успех.
Может, я ошибаюсь, но разве выгодно использовать в качестве открытого хранилища «сторонний сервис», каким в данном случае является любой блокчейн? Ведь расходы будут зависеть не от успеха вашего сервиса и не от количества инвесторов, а от «настроения майнеров».

И еще, в контракте все хранилища в качестве индекса используют address.
Как пользователи доказывают своё владение адресом?
И как приложение будет использоваться людьми, не связанными с криптовалютой?
1. Мы не завязаны конкретно на Ethereum. Прежде всего мы создаем технологию. Она будет универсально работать и с Ethereum и с Emercoin и с любым другим блокчейном.
2. За свой «спам» пользователи должны платить своим газом.
3. Сама технологическая платформа Prover будет предоставлять услуги прежде всего прикладным сервисам, например, страхование КАСКО или что-то другое, т.е. вести расчет с ними в токенах, а они уже могут работать с пользователями в фиате или как им больше нравится.
2. За свой «спам» пользователи должны платить своим газом.

Но как сервер будет взаимодействовать с контрактом от имени аккаунтов пользователей?
Сервер может взаимодействовать с контрактом только от своего аккаунта. Мы не подтверждаем авторство, мы подтверждаем подлинность видеоконтента, что он был снят НЕ РАНЕЕ и НЕ ПОЗДНЕЕ определенного времени.
А если подменять видеоданные на уровне драйвера камеры?
Вот мы и защищаемся как раз от того, что кто-то запишет видео заранее и пропустит его через виртуальную видеокамеру. Защитой является как раз контент. Считайте, что введенный движением смартфона swype-код, это требование пользователю во время съемки показать в кадре последний номер журнала Playboy, т.е. мы будем точно знать, что видео записано не ранее месяца, когда был этот выпуск. И это даже если видео было подменено на уровне драйвера:)
а если сразу рендерить с свайпкодом? тоесть когда просит, тогда и рендерим
Рендерить весь окружающий мир с фиксируемым объектом (автомобилем, например)? :) Круто для смартфона:)
Видео рендерится на компьютере и по ADB передается на телефон
Обнаруживать «монтаж» и «рендеринг» мы будем алгоритмами видеоанализа. Если Ваш компьютер может рендерить сцены, неотличимые от реального мира, то у Вас очень хороший компьютер:) Такой рендеринг очень дорогой получается. Цена фрода слишком велика.
рендерить нужно только свайп-код, дальше можно просто подставить монтаж
Реднеринг и монтаж мы будем выявлять видеоаналитикой.
Скажите, пожалуйста: правильно ли я понимаю, что подлинность смартфона (точнее, его ПО) тоже подтверждается? Если да, то — закрытым ключом от Etherium?
Нет, подлинность смартфона и ПО нас не интересует, т.к. достоверно подтвердить их подлинность не представляется возможным, т.к. можно запустить ПО в виртуальном окружении (на эмуляторе, например) и подпихивать любые метаданные. Мы подтверждаем только видеоконтент, причем на основе содержимого этого самого видеоконтента.
Спасибо за ответ, но имелась ввиду цифровая подпись :) Подтверждающая, что именно Вася Пупкин снял видео (а точнее, ПО с приватным ключом Васи). Но, видимо, такой цели нет…
Проект интересный, хотя вопросов хватает.
Почему ищете деньги через краудсейл — инвесторы не заинтересовались? Или просто мода такая пошла?
Классический венчур не хотим, т.к. не хотим терять контроль над бизнесом. Сейчас финансируем из своих средств, благо есть работающий бизнес, близкий по тематике (http://nordavind.ru). ICO для нас не столько инструмент финансирования, сколько мощный пиар, нужный для вхождения в ведущие мировые страховые компании.

Не очень понял комментарий. Классический венчур предполагает, что у фаундеров всегда контрольный пакет.

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

Видимо, вы имеете ввиду классический русский венчур :)
Если надумаете — обращайтесь.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий