Немного поздновато, но всё же: упоминается вариант аутентификации в методах контракта через хранение хеша пароля и передачу пароля в методы контракта. Но тогда, если я правильно понимаю, этот пароль будет светиться во всех транзакциях в качестве параметров к вызову метода?
Реальный кэш выходит трушнее децентрализован: в кошельках хоть триллион триллионов людей может хранить свои деньги и передавать их туда-сюда сколько угодно. Но тут проблема с подделками и копированием, если уже переходить в электронный «кэш». Проблема цифровых подделок решается цифровыми гос. подписями, а вот чтобы избежать копирования (двойной траты) подходит централизованный или блокчейн-реестр владельцев «банкнот»… И трушность опять уходит… «п-проблема Бен Б-бецалеля»)
За земельный кадастр отвечает одна организация. Блокчейн там за уши притянут.
Полагаю, что тут цель — избавиться или хотя бы уменьшить функционал и, соответственно, персонал подобной организации. Также как ты владеешь криптой, ты владеешь землей. У тебя есть ключ, за которым закреплено определенное кол-во земли. И ты можешь выполнять транзакции с землей, доказывая владение своим ключом.
Не нужно никуда обращаться и доказывать что это твоё и заключать договор, чтобы выполнить передачу. Всё сохранено в распределенном реестре и все видят историю каждого клочка земли. Нельзя продать дважды, нельзя продать чужое, нельзя продать и ничего не получить. В идеале тут должна быть и крипта, чтобы была возможность автоматически и оплачивать сделки. А иначе нужен арбитр, который подтверждает передачу денег в случае конфликтов.
Как считаете, можно ли сервисы Exonum использовать как бизнес-логику разрабатываемой системы?
Вот допустим, мы делаем проект типа хабра: есть пользователи, посты, комменты, рейтинги пользователей, лайки постов и комментов и проч. И (ВДРУГ) мы хотим сохранять инфу в блокчейн, чтобы… ммм… несколько организаций (участники-организаторы проекта) могли иметь инфу у себя и другие участники не могли бы её подделать в свою выгоду (ну допустим это завязано на деньги потом как-то будет, поэтому важна достоверность).
Предполагается ли в концепции exonum, что всю логику можно делать как сервисы exonum, или всё же нужно делать ещё один слой бизнес-логики, который отправляет данные в exonum (и синхронно или асинхронно это тогда делать)?
И как быть с ключами пользователей для шифрования транзакций, если делать веб-морду для этого (или придется делать только приложение?)? Транзакция: «Я, Вася, с таким-то открытым ключом, оставил этот коммент, вот я его подписал закрытым ключом». Закрытые ключи не хотелось бы в профиле на сайте хранить, его взлом будет означать потерю доверия всем транзакциям.
Полагаю скомпрометировать таким образом маленький альткоин/блокчейн вообще легко — подключить в перестройку цепочки пул, превосходящий по мощностям текущих майнеров на порядок.
1) На данный момент никто не обязан, но подавляющее большинство организаторов конференций всё равно желает разместить на сайте информацию о конференции. Когда приходит информация о конференции в отдел, который сопровождает сайт, там делают страницу на YConfs (+дают права представителю организатора конференции, если это необходимо) и делают анонс конференции в новостной ленте на сайте университета.
Сейчас ничего это нет, просто любой админ конференции принимает или отклоняет заявку на участие. До перевода на Yii была функция рецензирования, которую реализовывали для одной конференции (рецензенты заполняли форму из нескольких полей и потом админ конференции принимал или отклонял заявку на основе мнений рецензентов). На Yii не переносили этот функционал, т. к. пока не было надобности. Для статей в журнал используем OJS, где есть рецензирование.
Если новую инфу ему надо будет говорить также, как в Прологе, допустим, будут ли его воспринимать именно как ИИ? Соответственно и задачи многие он решать не сможет из естественной жизни.
Числа и арифметика нужна часто для выполнения и обычных задач (например, роботу могут сказать «дай соль с пятой полки»). Но числа это пример того, что может понадобиться. Арифметику можно и зашить в ИИ изначально, но нельзя же зашить всё. Через 1000 лет он должен осилить что-то, чего не было на момент его создания (как и человек, не всегда же он знал что такое галстук и что такое корень квадратный). Для Вашего примера ИИ должен знать и про одежду что-то, и как она относится к людям, какой формы/длины обычно галстуки, что они на шее «висят».
Описать арифметику фреймами/слотами. Число — фрейм, пара чисел — фрейм, являться суммой, являться произведением — слоты. Аксиомы разные добавить, типа, x «являться суммой» (0, x). Не знаю, хватит ли выразительности конкретно фреймов или OWL для всех аксиом арифметики.
Чтобы ИИ был похож на человека/личность, он должен сам, по мере необходимости и возможности, добавлять себе такие фреймы/понятия, слоты/отношения, аксиомы. Типа говорит «учитель», которому можно верить: «икс плюс ноль будет всегда икс для любого икс», а ИИ себе обновляет семантическую сеть / правила. Это надо сильный конвертор из естественного языка в формальный, а для этого нужен ИИ, который мы еще и не сделали)
Может быть и другая мотивация:
1) возможный шпионаж со стороны Америки в настоящем или в будущем
2) ограничение доступа к важным сервисам в случае обострения внешнеполитической ситуации
Если у нас ничего не останется своего — документы, календари, почта и т. д. на чужих серверах, навигация по чужим спутникам, компьютеры/телефоны на ОС, которые автоматически могут обновиться до чего угодно, международные платёжные системы… Если одномоментно заблокировать всё, то мы будем как первобытные люди — приходи и бери нас голыми руками!)
изредка используем более современную профессиональную видеокамеру Sony HVR-Z1, картинка для сравнения: tube.sfu-kras.ru/video/1602 (в другом помещении, но всё же)
Мы сводим говорящую голову с презентациями средствами JW Player, есть плагин для него, правда который давным-давно не обновляется. Пример работы: tube.sfu-kras.ru/video/1590. Иногда снимаем экран проектора прямо камерой, когда есть сомнения, что получим оригиналы презентации (приезжие лекторы изредка отказываются давать презентации, иногда из-за регламента мероприятия тяжело получить все презентации докладчиков).
Наше железо — DV-камера Canon XM2, петличный радиомикрофон Azden (двухканальный, правда почти не используем эту фичу). В некоторых случаях забираем звук с микшеров этим же радиомикрофоном (иногда страхуем рекордером ZOOM H4n — берет с jack или xlr, пишет на флэшку). Хотим попробовать микрофон типа такого www.sony.ru/product/cac-microphones/ecm-aw3, чтобы без проводов, быстрее нацепить на лектора (важно, если много лекторов подряд, типа конференции/семинара).
Мы делали такое в нашем универе один раз на многодневные спортивные соревнования — туча железа, людей, нервов) Пример tube.sfu-kras.ru/video/1307. Пришлось в спорткомплексе занимать две комнаты — одну под ПТС-ку с режиссером, звукорежиссёром, прочими технарями (трансляция на сайт, на телевизоры в корпусах, тот который диафрагму крутит на камерах, не знаю как называется даже), другую под комментаторов.
Полагаю, что тут цель — избавиться или хотя бы уменьшить функционал и, соответственно, персонал подобной организации. Также как ты владеешь криптой, ты владеешь землей. У тебя есть ключ, за которым закреплено определенное кол-во земли. И ты можешь выполнять транзакции с землей, доказывая владение своим ключом.
Не нужно никуда обращаться и доказывать что это твоё и заключать договор, чтобы выполнить передачу. Всё сохранено в распределенном реестре и все видят историю каждого клочка земли. Нельзя продать дважды, нельзя продать чужое, нельзя продать и ничего не получить. В идеале тут должна быть и крипта, чтобы была возможность автоматически и оплачивать сделки. А иначе нужен арбитр, который подтверждает передачу денег в случае конфликтов.
Вот допустим, мы делаем проект типа хабра: есть пользователи, посты, комменты, рейтинги пользователей, лайки постов и комментов и проч. И (ВДРУГ) мы хотим сохранять инфу в блокчейн, чтобы… ммм… несколько организаций (участники-организаторы проекта) могли иметь инфу у себя и другие участники не могли бы её подделать в свою выгоду (ну допустим это завязано на деньги потом как-то будет, поэтому важна достоверность).
Предполагается ли в концепции exonum, что всю логику можно делать как сервисы exonum, или всё же нужно делать ещё один слой бизнес-логики, который отправляет данные в exonum (и синхронно или асинхронно это тогда делать)?
И как быть с ключами пользователей для шифрования транзакций, если делать веб-морду для этого (или придется делать только приложение?)? Транзакция: «Я, Вася, с таким-то открытым ключом, оставил этот коммент, вот я его подписал закрытым ключом». Закрытые ключи не хотелось бы в профиле на сайте хранить, его взлом будет означать потерю доверия всем транзакциям.
Обучать естественному языку на формальном языке?
Чтобы ИИ был похож на человека/личность, он должен сам, по мере необходимости и возможности, добавлять себе такие фреймы/понятия, слоты/отношения, аксиомы. Типа говорит «учитель», которому можно верить: «икс плюс ноль будет всегда икс для любого икс», а ИИ себе обновляет семантическую сеть / правила. Это надо сильный конвертор из естественного языка в формальный, а для этого нужен ИИ, который мы еще и не сделали)
1) возможный шпионаж со стороны Америки в настоящем или в будущем
2) ограничение доступа к важным сервисам в случае обострения внешнеполитической ситуации
Если у нас ничего не останется своего — документы, календари, почта и т. д. на чужих серверах, навигация по чужим спутникам, компьютеры/телефоны на ОС, которые автоматически могут обновиться до чего угодно, международные платёжные системы… Если одномоментно заблокировать всё, то мы будем как первобытные люди — приходи и бери нас голыми руками!)
Наше железо — DV-камера Canon XM2, петличный радиомикрофон Azden (двухканальный, правда почти не используем эту фичу). В некоторых случаях забираем звук с микшеров этим же радиомикрофоном (иногда страхуем рекордером ZOOM H4n — берет с jack или xlr, пишет на флэшку). Хотим попробовать микрофон типа такого www.sony.ru/product/cac-microphones/ecm-aw3, чтобы без проводов, быстрее нацепить на лектора (важно, если много лекторов подряд, типа конференции/семинара).