Наследование в данном примере исключительно ради структурирования кода, чтобы было удобнее дергать законченными кусками в свои контракты. Деплоить надо только EasyCrowdsale, хотя чисто технически можно деплоить любой из рассмотренных контрактов.
Информационная безопасность тут вообще не причем:) (убил 10 лет своей жизни на работу с госзаказчиками по этому направлению). Неважно, какое у нас железо. Мы говорим про алгоритмы видеоанализа, которые отрыты, чтобы быть потенциально понятными и пользователям и использующему их бизнесу.
Это видимо совсем классический:) По нашему опыту общения с многочисленными инвесторами (по самым разным проектам) инвестор либо претендует на контрольный пакет, либо при своем миноритарном пакете просит наделить его такими правами, что как-будто у него контрольный. Но не суть. Психологически эта схема для нас некомфортна.
Классический венчур не хотим, т.к. не хотим терять контроль над бизнесом. Сейчас финансируем из своих средств, благо есть работающий бизнес, близкий по тематике (http://nordavind.ru). ICO для нас не столько инструмент финансирования, сколько мощный пиар, нужный для вхождения в ведущие мировые страховые компании.
Нет, подлинность смартфона и ПО нас не интересует, т.к. достоверно подтвердить их подлинность не представляется возможным, т.к. можно запустить ПО в виртуальном окружении (на эмуляторе, например) и подпихивать любые метаданные. Мы подтверждаем только видеоконтент, причем на основе содержимого этого самого видеоконтента.
Сервер может взаимодействовать с контрактом только от своего аккаунта. Мы не подтверждаем авторство, мы подтверждаем подлинность видеоконтента, что он был снят НЕ РАНЕЕ и НЕ ПОЗДНЕЕ определенного времени.
Обнаруживать «монтаж» и «рендеринг» мы будем алгоритмами видеоанализа. Если Ваш компьютер может рендерить сцены, неотличимые от реального мира, то у Вас очень хороший компьютер:) Такой рендеринг очень дорогой получается. Цена фрода слишком велика.
1. Мы не завязаны конкретно на Ethereum. Прежде всего мы создаем технологию. Она будет универсально работать и с Ethereum и с Emercoin и с любым другим блокчейном.
2. За свой «спам» пользователи должны платить своим газом.
3. Сама технологическая платформа Prover будет предоставлять услуги прежде всего прикладным сервисам, например, страхование КАСКО или что-то другое, т.е. вести расчет с ними в токенах, а они уже могут работать с пользователями в фиате или как им больше нравится.
Swype код генерируется смартконтрактом, им же запоминается. Нам все равно, что происходит на стороне клиента, чтобы этот swype попал в видеоконтент (физически присутствовал на виде). Смысл программы на стороне клиента, помочь ему увидеть, что он все делает правильно и те же самые открытые алгоритмы на стороне того, кто будет проверять подлинность, дадут тот же результат.
По поводу swype-кода тоже есть вопрос. Что если пользователь с заранее подготовленным видео будет говорить серверу о том, что он начинает съемку, до тех пор, пока не вернется нужный swype-код, который у него уже записан?
Это может оказаться дорого, как Вы сами заметили:) Ну и сервис/смартконтракт может смутить такой «перебор» вариантов. Ну и можно посчитать, сколько вариантов надо перебрать, даже если подбираем swype и 5 цифр:)
И не слишком ли дорого будет обходиться контракт в Эфириуме? При нынешней реализации контракта генерация swype-кода будет стоить 40911 gas. За 10.000 вызовов будет затрачиваться примерно 350$ со средней скоростью выполнения. А еще ведь запись хэшей и хранение данных.
Совершенно согласен! Экономически более целесообразным может оказаться использование других блокчейнов, в частности мы планируем сразу после Ethereum делать реализацию на Emercoin.
Вот мы и защищаемся как раз от того, что кто-то запишет видео заранее и пропустит его через виртуальную видеокамеру. Защитой является как раз контент. Считайте, что введенный движением смартфона swype-код, это требование пользователю во время съемки показать в кадре последний номер журнала Playboy, т.е. мы будем точно знать, что видео записано не ранее месяца, когда был этот выпуск. И это даже если видео было подменено на уровне драйвера:)
Обращение к контракту Эфириума через мобильное устройство сейчас чуть менее сложно, чем подделка видео.
Это решаемо, но не обязательно.
Если я всё правильно понял, то все данные сначала проходят через какой-то сервер, прежде чем сохраниться в контракте.
Получается, что система не является децентрализованной и блокчейн нужен только для внутренней валюты и краудфандинга?
Блокчейн нужен в качестве ДЕЦЕНТРАЛИЗОВАННОЙ БД для надежного доверенного хранения информации о сгенерированном swype-коде, времени его генерации и времени загрузки хэша. Архитектура конкретного прикладного решения может меняться, но блокчейн в качестве БД останется ядром любой из них.
Важно два таймштампа:
1. Время получения swype-кода, который должен оказаться непосредственно в видеоконтенте, что гарантирует, что этот видеоконтент не мог быть сформирован ранее времени, когда этот код был сгенерирован.
2. Время загрузки хэша файла, что гарантирует, что файл не был сформирован позже.
Понятно, что времени «выравниваются» по времени блока в конкретном блокчейне.
Ну я бы не сказал, что видео-монтаж на лету это будет дорого, если ваша программа будет получать уже модифицированный видео-поток на 3 секунды позже, в Европе во всю используются видео-регистраторы которые на лету номера машин закрывают. Так что проблем мне кажется нет.
Монтаж монтажу рознь. Закрывание номеров мы и сами делали, прекрасно в режиме реального времени работает. Немного нашего бэкграунда — http://nordavind.ru/node/102. Выправить в режиме реального времени крыло помятой машины — будет либо дорого, либо сильно заметно:)
А как ваша программа поведет себя при отсутствии подключения к интернету? Получит ли пользователь код? И будет ли видео считаться подлинным?
Без интернета все превратится в тыкву. Нам нужно получить через интернет swype-код и загрузить хэш в блокчейн.
Ну и мне показалось или я где-то читал, что это будет открытый исходный код? Тогда почему бы мне не модифицировать код на получение определенного токена? Какая вообще защита ПО от модификации?
можно записать как
Но с точки зрения понимания сути оно мне кажется хуже, хотя и вероятность ошибки ниже.
Есть и другие полезные константы, типа minutes, days, years и т.п.
2. За свой «спам» пользователи должны платить своим газом.
3. Сама технологическая платформа Prover будет предоставлять услуги прежде всего прикладным сервисам, например, страхование КАСКО или что-то другое, т.е. вести расчет с ними в токенах, а они уже могут работать с пользователями в фиате или как им больше нравится.
Это может оказаться дорого, как Вы сами заметили:) Ну и сервис/смартконтракт может смутить такой «перебор» вариантов. Ну и можно посчитать, сколько вариантов надо перебрать, даже если подбираем swype и 5 цифр:)
Совершенно согласен! Экономически более целесообразным может оказаться использование других блокчейнов, в частности мы планируем сразу после Ethereum делать реализацию на Emercoin.
Это решаемо, но не обязательно.
Блокчейн нужен в качестве ДЕЦЕНТРАЛИЗОВАННОЙ БД для надежного доверенного хранения информации о сгенерированном swype-коде, времени его генерации и времени загрузки хэша. Архитектура конкретного прикладного решения может меняться, но блокчейн в качестве БД останется ядром любой из них.
1. Время получения swype-кода, который должен оказаться непосредственно в видеоконтенте, что гарантирует, что этот видеоконтент не мог быть сформирован ранее времени, когда этот код был сгенерирован.
2. Время загрузки хэша файла, что гарантирует, что файл не был сформирован позже.
Понятно, что времени «выравниваются» по времени блока в конкретном блокчейне.
Монтаж монтажу рознь. Закрывание номеров мы и сами делали, прекрасно в режиме реального времени работает. Немного нашего бэкграунда — http://nordavind.ru/node/102. Выправить в режиме реального времени крыло помятой машины — будет либо дорого, либо сильно заметно:)
Без интернета все превратится в тыкву. Нам нужно получить через интернет swype-код и загрузить хэш в блокчейн.
У нас есть патент.