Как стать автором
Обновить
63
0
Сергей Прилуцкий @BoogerWooger

Software Researcher

Отправить сообщение
1. раздаются в деканате
2. через заранее заданное время позиция удаляется из рейтинга (с первой «вытесняющей» транзакцией), замороженные токены освобождаются и позицию надо будет восстановить. Либо использовать gradedTCR с постепенным освобождением токенов и «спуском» позиции вниз
3. Студенты «голосуют» за любимых преподов, «замораживая» произвольное количество своих токенов. Елси позиция уйдет из реестра, токены автоматически возвращаются
4. Контроль распределения токенов, обновление контракта реестра (если найдены ошибки). Конечно сотрудники также работают с токеном системы. Поступил студент в ВУЗ — выдали токен. Кто то стырил все токены — обновили контракт и восстановили реестр.
Окей, давайте обсудим реестр «любимых» преподавателей ВУЗ. Преподаватели, которые находятся в реестре, получают 10% премию к зарплате. Я считаю, что можно было бы организовать эту систему в виде TCR реестра.
Перед тем, как начать обсуждать алгоритмы не нужны никакие юзкейсы — мы не ТЗ здесь пишем. Мы не забыли про скрипт на Питончике и про «методики, которые наработало научное сообщество»? Что там за методики, которые убедят меня что вы не наврали в сборе статистики, что вас не взломали, что у вас не купили место в реестре, что не накрутили статистику? TCR — это и есть один из БАЗОВЫХ элементов тех самых «методик».
Я правильно понимаю, что ваш посыл в том что «изначальный посыл дрянь» и не стоит этим заниматься? В таком случае это аргумент для фейсбука, но никак не для хабра. Если есть аргументы относящиеся к алгоритму, описывающие конкретные атаки на TCR — welcome, для нас такие комментарии — чистое золото, т.к. каждый — потенциальная атака на алгоритм. А поговорить «кому оно это всё нужно» — это можно на фейсбуке, мы там такие разговоры уже задолбались вести.
1. Можно (и нужно) сделать экспоненциальную модель stake-инга, ввести ограничения и лимиты. «отняли здесь, прибавили там» — это про унылый фиат, здесь свобода в плане алгоритмов почти полная
2. замороженные токены, который можно оспорить и перераспределить — это имхо уже не «исключительное владение». Сам базовый токен — возможно (да и то, если использовать мультисиг, то тоже можно поспорить)
3. также ограничивается программными методами и может быть исправлено на более справедливые варианты. К примеру передача токена возможна только уже голосовавшим, а остальным — лишь в сильно ограниченном объёме.

Я как раз за усложнение всех этих моделей и уход от самой примитивной модели токена — она как раз крайне неустойчива к запретам и беготне с пистолетами. К сожалению сейчас придется организовывать это с участием «традиционных ценностей» — спекулянства и pump-ов-dump-ов — и это крайне печалит. Успокаивает то, что были же времена, когда люди к автомобилю на лошади подъезжали, увы, разом на децентрализованные системы не перескочишь.
Есть куда более порочное в попытке считать токен системы баблом. Именно благодаря этому перекошенному видению развивается спекулянство и торговля криптой, а не технологии, грамотно использующие ее преимущества.
эти контракты — скорее библиотеки, и TCR — это алгоритм, а не конкретный контракт. Искать в блокчейне контракты, использующие внутри себя TCR — это как искать в интернете сайты, на которых есть «таблица с сортировками». Ну а навскидку, активность там такая же, как и остальных популярных смарт-контрактов — крайне небольшая. Люди пока в основе своей только торговлю токенами освоили, более сложные контракты пока крайне мало кем используются.
Платить будут те, кто хочет чтобы в реестре появился преступник и кто не боится, что остальные участники реестра его «выкинут», отняв токены. А держателям токена невыгодно, чтобы преступник появился в реестре, т.к. тогда ценность токена упадет. Там много всего можно запрогать под конкретный TCR — и запрет на разовую передачу большой доли токенов, или истекающий time-to-live «голосов», или еще сто разных механизмов.
Это как минимум честнее любых существующих систем для «честных» реестров. До идеала, ясен пень, еще далеко, но это хороший шаг вперед.
В IOTA вроде нашли дыру в самописной хеш функции. У всех DAG-ов крайне непонятная ситуация с атаками на консенсус. Атакующий может валить в DAG много собственных транзакций, «прокачивая» собственные, и в IOTA по-моему вначале как раз не было серьезных доводов против таких атак. В ByteBall эту проблему решают с помощью 12 доверенных узлов, а в IOTA вроде уже попробовали несколько вариантов решения, но общее впечатление, что перспективы «голого» DAG
(без работы с вспомогательной основной цепочкой, как в BURST) пока мутные. Хотя это не отвергает того, что DAG — похоже единственный true способ получить такой блокчейн, чтобы каждая нода хранила не весь объем транзакций, а только те, которые интересуют только ее (ну и вспомогательные, для обеспечения работы консенсуса). Все имхо, канеш
Плюс, любой массив, не ограниченный сверху — это потенциальная дыра. Если количество элементов дорастет до некоторого большого значения, а внутри цикла будут потребляться вычислительные ресурсы, можно упереться в лимит по газу (больше определенного числа вычислений нельзя выполнить в транзакции). Запись значения в storage стоит десятки тысяч газа, hardlimit — вроде сейчас 8млн, так что особо много циклами не сделаешь. Только в вычислительных задачах, причем довольно простых. Поэтому смарт-контракт — это набор крайне легковесных функций
Вот сейчас было обидно, вообще то «линуксовая программа с вызовом web апи» была сделана одним членом команды из пяти часа за два-три, попробовавшим две разных железки. После этого команда пилила систему контрактов на C++, тесты, полностью работоспособный фронтенд да плюс еще и сделала удобную инфру для тестирования контрактов. А эта задачка под EOS в его текущем виде крайне нетривиальная. Ну а рынок для разработки — пусть он и рассудит
Думаю с хабра дискуссию пора переносить, ибо она уже давно ушла от собственно статьи, которая попросту описывает один из вариантов решения задачи. Можем продолжить в любой соцсети например, или забить. Можем даже лично пообщаться, нам разумный подход крайне близок, и инфа от тех, кто разбирается в индустрии IoT нам крайне интересна, в ответ расскажем честно как дела обстоят у блокчейн-разрабочиков. Также напомню, что это все таки хакатон, а не подрядная работа на заказ от большой компании — и выбор темы хакатона — это все таки не стратегия выхода на рынок. Ну а логика и аргументация у нас точно есть — я могу запустить первый счетчик прямо сейчас и он будет платить сразу же в реальной криптовалюте не запустив ни одного сервера, не платя за хостинги, не делая бекапов, не нанимая админов. Вся моя система — набор из нескольких контрактов и железка с элементарным setup-ом. Уже есть юрисдикции, где такие платежи совершенно законны, и Россия точно скоро будет одной из них. В текущих реалиях, чтобы повторить то же самое но с рублями и централизованной базой показаний — объем вопросов, которые нужно решить на порядки больше. Значит такая система как минимум существенно упростит мне выход на рынок, что бы там мои датчики не считали. Это разве не преимущество?
В нашей системе все точно так же, только конкурирующие компании держат лишь несколько стандартных нод EOS, да и те — просто для гарантии доступности и личного удобства. Поэтому их затраты на поддержку инфраструктуры гораздо ниже, в связи с чем они могут предлагать более низкие цены на основной сервис. Это только с инфраструктурной точки зрения, также, в этой системе меньше точек отказа и векторов потенциального взлома.
Комментарий про «сеть любого масштаба» и комиссии совершенно справедлив. Но я все равно убежден, что именно за таким архитектурами будущее, и уверен, что проблемы комиссий и масштабирования — вопрос времени. Пускай сейчас это действительно дорого для IoT, пускай «децентрализация» пока только условная (в биткоине она тоже условная, ибо большим майнинговым пулам сговориться можно без проблем). Но архитектурных преимуществ это систему не лишает. Ну а незрелость и нездоровость темы сейчас — это да, в большом количестве случаев необходимость децентрализации притягивают за уши, мы скорее всего тоже этим тоже грешим, это все таки наш хлеб. Но конкретно в данном вопросе считаем что этот подход более выигрышный, чем любой другой из существующих
ну мы постарались заюзать кусочек, который представляет реальную проблему — это учет показаний, выверка счетчиков, автооплата. Понятно, что никто не собирается использовать блокчейн как тупую базу данных для датчиков. Блокчейн — это в первую очередь про учет событий, а не про их содержание, и для платежей за энергоносители подходит неплохо, ибо данные небольшие и платежи нечастые, плюс строгий учет нужен, а свомещенный с автооплатой — вообще отлично.
Преимущество схемы в простоте и доступности владения системой датчиков — не надо держать ни одного центрального сервера, защищать его. Работоспособность сети — забота совершенно других людей, которым выгодно, чтобы она работала. Имхо, для разработчиков это очень круто — можно запустить сеть произвольного масштаба не владея ни одним сервером. Но можно еще долго сравнивать с централизованными решениями, и еще несколько лет децентрализованные будут проигрывать по многим статьям, но это точно ненадолго
В общих словах, если ты на железке можешь поставить подпись при помощи модуля ECC (для микрожелезяк это серьезное довольно вычисление) — то в общем можешь считать, что она годится «в блокчейн». Удобно тем, что не надо поднимать никакие сервера для приема данных, выложил в сеть смарт-контракт, и железяки в него ходят, а процессят трназакции block-producer-ы. Несмотря на кучу тонкостей в реализации, эта схема все равно удобней IoT разработчику — он занимается строго железкой и может не волноваться о работоспособности сети, пускай об этом block-producer-ы волнуются, они за это профит получают
В первую очередь отсутствием общего секрета со счетчиком и отсутствием необходимости защищать центральную базу показаний счетчиков. В традиционном решении вы ставите какой нить mysql или sql server, и сделать его открытым всему миру не можете, его сразу завалят. В блокчейне этой проблемы нет, за счет «оплаты» отправки транзакций и встроенной подписи каждой транзакции такая система попросту получается на порядок проще — поэтому ее и реально сделать за хакатон. Тут никакого волшебства, платить за эту простоту приходится избыточностью хранения, но для задач учета — это отлично подходит.
Странный тест — поведение маппингов и массивов подробно описано в доке. Зачем статью из этого делать — неясно
У нас были полностью публичные картинки, распространять которые собственно и являлось основной задачей сайта :) Можно, наверное, прятать оригинал фотки, и выкладывать обработанную версию, хешировать тоже по ней (с пострипанным EXIF-ом, заресайзенную, с нашим водяным знаком, тогда одним движением не получится — проверящему придется сделать нужную обработку собственной фотки.
Спасибо, отличная статья.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность