Технология «блокчейн» прекрасна и перспективна. Всё в ней было бы совсем замечательно, если бы несколько досадных нюансов:
- Очень долго. Время добавления транзакции в цепочку биткоина, например, оценивается от минуты до получаса. В Ethereum добавляется быстрее, но в любом случае довести время до долей секунды невозможно. Нечего и думать о том, чтобы сделать добавление данных в блокчейн частью OLTP-транзакции.
- Майнинг — это очень ресурсоёмко. Он, собственно, и нужен для того, чтобы добавить в архитектуру вычислительную сложность.
- Очень дорого. Следствие ресурсоёмкости.
- Технология отвратительно масштабируется как вверх, так и вниз. Если нужно построить систему, которая будет регистрировать миллиарды записей ежедневно, блокчейн не годится. Также блокчейн будет стрельбой из пушки по воробьям, если его пытаться приспособить для надёжного логирования какой-нибудь мелкой ерунды.
Хотелось бы иметь технологию, которая бы одновременно и реестры позволяла вести непрошибаемо надёжным образом, и была бы как-то попроще и подешевле.
Самые сладкие объёмы продаж делаются на самом ходовом и, как следствие, дефицитном товаре. Менеджеры-продажники — ребята ушлые. Они быстро сообразили, что самый верный способ иметь хорошие бонусы — постоянно мониторить поставки, и как только на складе появляется дефицит, быстренько резервировать его под себя. Создавать фиктивный «Заказ покупателя», набивать его дефицитом и говорить всем, что это клиент, который пока что думает, что ему нужно взять ещё (в общем, нормальная ситуация). Потом, когда появляется реальный запрос на дефицит, быстренько убирать требуемое количество из фиктивного счёта, и в ту же секунду добавлять в реальный.
В результате бизнес несёт убытки. На складе неделями валяется товар, который должен был бы уйти в первый же день. Департамент продаж вместо того, чтобы заниматься поиском новых клиентов и выстраиванием взаимоотношений с ними, целыми днями мониторит поставки. Склоки, нервотрёпка, взаимные упрёки и обиды. С этим что-то надо было сделать, но так, чтобы это не повредило основному бизнес-процессу. Решили для начала логировать операции резервирования. Отследить ситуации, когда дефицит резервируется «заказом покупателя», но потом это резервирование не превращается в продажу этим же документом. Тех, кто этим больше всех злоупотребляет, вешать на позорном столбе.
Поначалу помогло, но потом начал наблюдаться странный эффект: показатели зависания дефицита на складе вернулись к прежним, хотя по логам всё было шоколадно. Оказалось, что что в реализации не была учтена сила обаяния менеджеров по продажам. Ради высоких бонусов они повадились сговариваться с системными администраторами, чтобы те вычищали из логов компромат. В ход пошёл весь арсенал средств — подкуп, шантаж, флирт, женские слёзы. Парням из службы администрирования оказалось нечего противопоставить такой атаке.
Встал вопрос о том, чтобы техническими средствами сделать невозможным искажение лога задним числом. Посмотрели в сторону блокчейна, но выяснили, что пропускать резервирование товара через популярные блокчейн-платформы слишком накладно, а городить отдельную серверную стойку под собственный блокчейн для улаживания дрязг в департаменте продаж тоже никакого желания нет. Что делать — не понятно.
В принципе, на этом можно было бы публикацию закончить и предложить уважаемой публике пофантазировать в комментах о том, как можно сделать супернадёжную запись трензакций в условиях тотального недоверия всех ко всем без того, чтобы бессмысленно прожигать процессорные мощности никчёмным подбором хеш-функций. Но для того, чтобы единственным ответом на вопрос не было банальное «это невозможно» или что-нибудь про сайдчейны, попробую предложить свой вариант.
Сразу оговорюсь, что речь вовсе не о том, «как нам реорганизовать биткоин». Пусть биткоин остаётся таким, какой он есть, а мы поговорим о том, как сделать что-то функционально аналогичное блокчейну, но пригодное к использованию для самых разных нужд в частности в корпоративных системах. Дешёвое и сердитое.
Для начала внимательно посмотрим на саму задачу. Во-первых, мы уже имеем сам защищаемый от фальсификации реестр. Во-вторых, нам не очень важна распределённость системы. Удобнее всего, если система защиты реестра будет централизованной. В идеале — на том же самом сервере, что и сам реестр. Распределённость реестра и системы его защиты тоже может быть во многих случаях полезна, но начать нужно с простого. С принципа защиты.
Система защиты реестра в инфраструктуре корпоративной системы:
Априорно считаем, что всё происходящее на серверах — в полной власти администраторов, и эти администраторы с их человеческими страстями — слабое звено. Поэтому функция контроля целостности реестра частично возлагается на рабочие места пользователей. Реализуется принцип «не доверяй, проверяй». Администратор может сделать что угодно с расположенными на сервере данными, но он не в силах отследить, куда и по каким компьютерам (а также смартфонам, планшетам, флешкам и т.п.) расползлись контрольные суммы, фиксирующие целостность реестра. В клиентское приложение (или, возможно, в отдельное специальное контролирующее приложение) встраивается функция, которая при обнаружении факта нарушения целостности реестра зажигает красную лампочку и позволяет сформировать криптографически достоверное обвинительное заключение.
Защищаемый реестр и его контрольные суммы:
Для каждой записи реестра подсчитывается собственный хеш (H0i), а также автоматически наращивается бинарное дерево хешей второго, третьего и так далее порядков (H1, H2,...). После того, как очередная запись занесена в реестр, клиентскому приложению возвращается сама занесённая запись, а также такой набор хешей более высоких уровней, чтобы он полностью покрывал все предыдущие записи реестра. Например, при добавлении шестой записи возвращается D5, H05, H12 и H20 (удобнее смотреть на картинке ниже). При добавлении 15-й записи, соответственно, возвращается D14, H014, H16, H22 и H30. Получив ответ от сервера, клиентское приложение:
- Проверяет соответствие Di тому, что оно собиралось занести в реестр.
- Самостоятельно рассчитывает H0i и проверяет, равно ли получившееся тому, что прислал сервер.
- Запоминает себе в локальную базу полученный от сервера ответ.
Для того, чтобы исключить подделку ответа сервера и прочие неприятности, этот ответ можно защитить электронной подписью сервера.
Экспресс-проверка неизменности собственных записей клиента
Когда клиент добавил в реестр очередную запись, он может сверить новый полученный срез хешей со срезами, полученными при предыдущих обращениях. Поскольку с предыдущего обращения могли нараститься дополнительные уровни, для сверки хешей может потребоваться некоторое количество дополнительны данных от сервера. Например, если клиент сначала добавил D5, а потом добавил D14, то для сверки H20 с H30 он запрашивает с сервера значение H13, затем на основании H12 и H13 вычисляет H21, после чего на основании H20 и H21 рассчитывает H30, которое сравнивает с полученным. Если значения не совпадают, включается красная лампочка и сигнал тревоги.
Серым цветом показаны данные, отсутствующие на клиенте. При добавлении первой своей записи (D5) клиент в своей локальной базе сохранил данные, выделенные зелёным, а при добавлении следующей записи (D14) получил данные, выделенные синим. Выделенное жёлтым запрашивается с сервера защиты дополнительно.
Сплошная проверка участка реестра
Клиент запрашивает с сервера участок реестра и проверяет, возможно ли от полученных данных выйти на те значения хешей, которые сохранены в его локальном хранилище.
В результате имеем:
- Скорость добавления данных в реестр. Майнить коины оказывается незачем. Увеличение производительности вплоть до того, что данные в защищённый реестр можно записывать внутри OLTP-транзакции.
- Надёжность. Незаметно удалить запись из реестра невозможно. Сложность искажения данных равна сложности подбора полной хеш-коллизии.
- Простота реализации. Прекрасная масштабируемость «вниз».
- Прекрасная масштабируемость «вверх». Даже если в реестре сто миллиардов записей, количество уровней бинарного дерева оказывается равным 36. Если используется хеширование SHA-256, передаваемые с сервера данные хешей составляют менее 2 килобайт.
- Хоть ведение реестра становится централизованным (что для случая криптовалюты в стиле биткоина не очень хорошо), вполне возможна распределённая архитектура на основе репликации и оперативного переключения со скомпрометированных узлов на те, которые не были уличены в подлоге.
P.S. Про исходники на гитхабе, пожалуйста, не спрашивайте. Их нет. Идея уходит в публикацию с колёс.
Комментарии (89)
vanxant
26.06.2017 22:14+1Вот тоже была мысль, что в рамках государства именно блокчейн не ок, слишком много электричества впустую.
Проблему доверия, например, между банками, тоже лучше решать не тупой физической мощью (в РФ, например, Сбер на пару с ВТБ при желании всех банально забрутфорсят), а на паритетных началах, Т.е. чтобы блок считался подписанным, его должны подписать больше половины имеющих лицензию банков, а не те два-три слона, которые контролируют более половины вычислительных мощностей. Опять же, в отличие от блокчейна, у банков уже развернута очень секурная инфраструктура асимметричных ключей (PKI).maslyaev
26.06.2017 22:42+1Вот и я примерно о том же. Для обслуживания относительно небольшого потока данных, имеющих какое-никакое общемировое значение, блокчейн подходит. А как только вываливаешься за коридор допустимых масштабов, приходится или городить мерзкие костыли типа каких-нибудь сайдчейнов, или убираться несолоно хлебавши.
eugenebabichenko
26.06.2017 22:56В Ethereum сейчас для этого ввели систему Proof of Authority — она делает именно то, о чём вы сказали, но всё ещё не настолько быстро. Для решения проблемы со скоростью разрабатываются так называемые state/payment channels — происходит обмен информацией/средствами между участниками сети напрямую, а финальное состояние пишется в блокчейн.
Gorthauer87
27.06.2017 09:02+1Вы только что придумали алгоритм византийского консенсуса. Только там нужно 2/3n+1
unsafePtr
26.06.2017 22:30Надёжность. Незаметно удалить запись из реестра невозможно. Сложность искажения данных равна сложности подбора полной хеш-коллизии.
Получается если мы хотим гарантировать невозможность удаления данных придется делать обязательную репликацию.maslyaev
26.06.2017 22:36Репликация нужна если хочется не только выявлять подлог, но и восстанавливать попорченные данные. Если же вопрос только в выявлении (один раз расстрелять продажных админов, и после этого поползновений больше не будет), то репликация даже и не нужна.
vanxant
26.06.2017 23:12+1Репликация на условных блокчейнах нужна для построения распределённой системы в условиях, когда узлы (реплики) полностью независимы и не очень-то доверяют даже не столько друг другу, сколько промежуточным сетям передачи, надёжности техники и человеческому фактору.
Те же банки не просто так хайпят блокчейн. Сейчас все их системы строго централизованы, т.е. у каждой валюты есть ЦБ или главный расчётный центр, который собирает все транзакции и один раз в рабочие сутки производит расшивку, какой банк какому сколько должен по итогу всех транзакций за опердень. Это медленно, это единая точка отказа, и это просто огромнейшая куча дополнительного геморроя при международных расчётах, когда платёж идет через несколько юрисдикций. По сравнению с этим даже сегодняшний биткоин это просто недостижимый спринтер.maslyaev
26.06.2017 23:27И это, конечно, тоже. Но придание описанной здесь конструкции свойств автоматического изгнания безобразников и восстановления после сбоев и атак — отдельная тема. Сейчас я чисто интуитивно чувствую, что такое можно сделать, но, конечно, могу и ошибаться.
6opoDuJIo
26.06.2017 23:07А как будет считаться хеш H13 при добавлении записи D6, если запись D7 отсутствует в реестре?
maslyaev
26.06.2017 23:17+2Никак. Хеши начиная с уровня 1 при добавлении очередной записи нужны только для того, чтобы покрыть собой предыдущие записи.
То есть при добавлении D6 вернётся H06 (что естественно), H12 и H20.
smetanez
26.06.2017 23:10+2EOS. Блокчейн-архитектура, предназначенная для горизонтального и вертикального маштабирования децентрализованных приложений. Но по сути поста мне сказать нечего.
maslyaev
26.06.2017 23:12Пока не могу сказать что-то определённое про EOS. Возможно, тоже вариант. Почему бы и нет? Пусть цветёт тысяча цветов.
mwizard
27.06.2017 00:09+4ха, да это ж дерево Меркле, только динамически растущее и, похоже, интересное.
qw1
27.06.2017 00:40+1Со стороны «админов» проще всего не включать некоторые записи в дерево, но на остальную логику они должны влиять. Алгоритм не гарантирует, что резерв какого-то заказа как-то связан с хешами.
И в режиме OLTP вряд ли получится работать. Проблема в упорядочивании транзакций в реальном времени при наличии конкурентного доступа.
Вот пример:
Чёрным отмечены закоммиченные транзакции, красным и синим — транзакции двух клиентов, ещё не закоммиченные.
Синий клиент не видит записи красного, хотя его вершина дерева зависит от них.
Кроме того, сложно сделать схему, когда сразу после коммита клиент повторно запрашивает только что записанные данные, т.к. синие транзакции могут быть закоммичены раньше красных, и их хеш ещё не готов.
Также есть вариант, что красный запрос будет отменён (исключение в бизнес-логике) и сколько ждать его завершения, в общем случае неизвестно.
Выход можно найти в каком отдельном агенте, который считывает закоммиченные транзакции, складывает их себе в одну линейно упорядоченную очередь и самостоятельно нумерует заново. Но тут уже получается не так красиво — клиент после операции записи должен дождаться агента, когда он обработает только что сделанную запись, и только тогда сможет сверить хеши.maslyaev
27.06.2017 10:46Да, с транзакциями не очень красиво получается, но тут можно предложить всё же фиксировать в реестре (естественно, навечно) незакоммиченные транзакции, но потом, если в основной бизнес-логике транзакция откатилась, вписывать в реестр сторнирующие записи. Такая вот «грязная запись» :(
mickvav
27.06.2017 12:45Вообще, исходная задача решается грамотным разделением прав/логинов/паролей и парой триггеров в БД. Грубо говоря есть таблица, в которую пишется лог операций по триггерам update/insert/delete и в которую «админы» не имеют доступа.
qw1
27.06.2017 14:42Для настройки этой системы нужны другие «админы», тоже уязвимые.
Кроме того, если первые админы имеют физический доступ к железу (и админский доступ к ОС), защита триггерами становится ненадёжной.mickvav
28.06.2017 00:56Репликация логов на отдельную машину? Если у уязвимых админов есть рут от всего, то кто им мешает «обновить» мобильные аппликухи и оставить на них закладки, позволяющие потереть логи без палева?
DrPass
28.06.2017 00:58Если у уязвимых админов есть рут от всего, то кто им мешает «обновить» мобильные аппликухи и оставить на них закладки
Я так понимаю, задача состояла в том, чтобы бороться с нерадивым DBA, а не с компьютерным богом, который имеет рут от всего, знает структуру базы и способен внедрять свои закладки в бинарники приложений.qw1
28.06.2017 07:07Из сценария я понял, что нет никакого DBA.
Есть тыж-программисты, которые пишут приложение, админят БД, содержат железо.
Есть юзеры, и есть их начльство.
Вот все роли.
И недоверие тут выражено всей касте тыж-программистов, без деления на роли (иначе бы всё решалось грамотным разделением доступа и отвественности)maslyaev
28.06.2017 11:49Описанная в примере ситуация — это, конечно, смешная мышиная возня. Но вообще тема ведения защищённых реестров — это ни фига не смешно.
У нас сейчас всё переводится в цифру. Тот факт, что человек вообще родился — это уже запись в базе данных. Учился, женился, работал, родил детей, обзавёлся имуществом — тоже. Все факты биографии, все права собственности — это всё если ещё и не до конца оцифровано, то скоро будет. И вся эта правда о нашем прошлом, настоящим и будущем полностью беззащитна перед глупостью, некомпетентностью и злонамеренностью людей с рутовыми правами. Мы даже не имеем возможности знать, кто, где и на что конкретно эти самые рутовые права имеет. «Уволить нерадивого админа»… Ха! Мы даже не знаем, кто они, эти админы, и уж точно не имеем никаких полномочий их увольнять.
Вы думаете почему народ так вцепился в эти самые блокчейны? Только ли дело в возможности разбогатеть на спекуляциях цифровыми фантиками? Это, конечно, тоже, но кроме этого есть ещё куча гораздо более серьёзных проблем. Включая вопросы жизни и смерти.
Блокчейн в том виде, в котором мы его знаем мог бы быть решением, если бы не те «досадные нюансы», о которых я написал в начале статьи. Если для того, чтобы добавить запись в базу, нужно спалить, условно говоря, киловатт-час — это точно не то решение, которое подходит для массового повседневного использования для самых разных нужд.
«Есть сервисы, которые...». Да замечательно, что они есть. Удачи им в делах и счастья в личной жизни. Но это опять вопрос доверия разработчикам и владельцам этих прекрасных сервисов. Плюс ещё немножко людей с рутовыми правами, про которых мы ничего не знаем. Проблема локально устраняется, но в целом, глобально, только усугубляется.
С позиции каждого конкретного игрока правильный сервис защиты его чувствительных данных от подделки — это флешка, лежащая у него в кармане. Мы не владеем «облаками», централизованными базами данных, государственными реестрами и прочими несомненно прекрасными вещами. Если контроль целостности никак не завязан на то, чем владеем лично и персонально мы сами (например, на флешку в кармане), мы обязаны признать, что происходящее нам неподконтрольно. Собственно, как раз в этом и состоит суть и смысл описанной технологии.DrPass
28.06.2017 13:29Вы думаете почему народ так вцепился в эти самые блокчейны? Только ли дело в возможности разбогатеть на спекуляциях цифровыми фантиками? Это, конечно, тоже,
Мне кажется, вы серьезно недооцениваете количество желающих и саму силу желания разбогатеть на спекуляциях цифровыми фантиками. Мы с вами живем в цифровом мире уже не одно десятилетие. Финансы управляются банками уже много сотен лет, из которых последние полвека — с помощью компьютеров. И при этом каких-то реальных проблем с системой, которые в силу своей природы призван решать блокчейн, мы до сих пор не встретили, все они сугубо теоретические. Вот, дескать, вас может обмануть ваш банк. Вот, дескать, кто-то может подменить ваши записи в нотариальном реестре.
Да, банк может обмануть. А кто-то другой может спереть мой пароль от биткойн-кошелька. Но в случае, если развалится банк с моими вкладами, я по крайней мере через какое-то время получу компенсацию от государства, да и при продаже имущества банка я, как физлицо, буду стоять в числе первых на получение возмещения. А в случае кражи или вообще любого мошенничества с крипто-кошельком я могу только сочинить красивую эпитафию моим деньгам.
Нотариальный реестр? Крайне маловероятно, при этом нагло и весьма рискованно для злоумышленника, тем более что оригиналы документов все равно у меня.
Так что полезность блокчейна для вашей личной безопасности весьма и весьма преувеличена. Это в основном маркетинг. Вы прекрасно обойдётесь без жевательной резинки с голубыми кристаллами. Но те, кто её продают, заинтересованы в том, чтобы вы почувствовали в ней потребность. Вот они и убеждают вас, что эти кристаллы вам так нужны для морозной свежести в вашем рту, равно как и сама морозная свежесть. Так же и блокчейн — он якобы даёт вам возможность самостоятельно управлять своими данными, а вам эта возможность якобы необходима.maslyaev
28.06.2017 15:28при этом каких-то реальных проблем с системой, которые в силу своей природы призван решать блокчейн, мы до сих пор не встретили
Спасаемся бумагой. Вы заметили, что при переходе на безбумажные технологии расход бумаги только возрастает? Там, где раньше учёт обходился записью одной операции в книгу, теперь оно проводится по компьютеру, а потом печатается А4 в минимум двух экземплярах, подписывается, пропечатывается. А всё это почему? Потому, что ноликам и единичкам, существующим внутри компьютерных мозгов, доверия никакого. Сегодня они смотрят в одну сторону, а завтра уже в другую. Выглядит оно так, как будто всегда так было. Если нет бумажки с подписью и печатью, никто никогда потом ничего никому не докажет.
получу компенсацию от государства, да и при продаже имущества банка я, как физлицо, буду стоять в числе первых на получение возмещения
Если такое случится, за компенсацией приходите с бумажками. Имеется ненулевая вероятность того, что в базе лопнувшего банка будет записано, что он Вам ничего не должен.
Есть, конечно, электронная подпись. По идее (и даже по закону) она приравнена к собственноручной. Но есть нюанс. Допустим, ключ украли и краденым ключом наподписывали кучу всего интересного. Разумеется, задним числом. Как доказать, что эти подписи сделаны после кражи ключа? Можно, конечно, вспомнить про time stamp protocol, но где гарантия тому, что через десять лет сегодняшние секретные ключи центров штампов времени не будут продаваться по центу за сто штук?
От бумажности безбумажных технологий всё равно рано или поздно придётся избавляться. Потому что не дело. Весь вопрос в том, как. Блокчейн — накладно. Накрутить очередное 100500-е «authority» — не вариант. Цент за сто штук — вот настоящая цена этих «authority». Вопрос открытый, поле непаханное.DrPass
28.06.2017 15:36Спасаемся бумагой. Вы заметили, что при переходе на безбумажные технологии расход бумаги только возрастает?
Скорее нет, чем да. Вот я живу в далеко не самой технологически передовой стране. Я один раз заполнил бумажную анкету в налоговой на получение ключей ЭЦП, и один раз в банке — договор и ключи ЭЦП. Ну и повторяю эту процедуру раз в пару лет. Всё остальное происходит вообще без бумаг. Я без бумаг получаю оплату за работу, без бумаг плачу за коммунальные услуги, без бумаг отчитываюсь за свои доходы и плачу налоги. Поэтому не всё так плохо, если где-то количество бумажек возросло, это вопрос больше к некачественной реализации бизнес-процесса, чем к недоверию технологиям.maslyaev
28.06.2017 17:10Без бумаг нормально получается, когда имеет место асимметричное взаимодействие. То есть когда один из участников сразу назначен «authority», которому другой участник взаимодействия вынужден доверять. Или, как в случае с PKI, когда пиры смогли договориться между собой договориться, какую третью сторону они согласны взять в «authority».
Мы, двуногие существа, очень склонны к иерархическим общественным структурам, и для нас естественно плюнуть на все рациональные соображения и заложиться на благочестивость батюшки-вождя. Потому что если оно не так, то вообще страшно жить. Когда большой и сильный постучал себе кулаком в волосатую грудь и пообещал, что будет всё хорошо, мы мгновенно распознаём этот паттерн и успокаиваемся. Нас не смущает даже то, что почти весь наш предыдущий опыт нам настоятельно не рекомендует так поступать.
С интернет-банкингом всё хорошо. Но говорят, что им не пользуются не только те, кто безнадёжно отстал от жизни, но и те, кто преподаёт интернет-банкинг.DrPass
28.06.2017 21:27Без бумаг нормально получается, когда имеет место асимметричное взаимодействие. То есть когда один из участников сразу назначен «authority», которому другой участник взаимодействия вынужден доверять.
Абсолютно верно. Но зачем от этого отказываться? Я понимаю частные случаи, когда вы хотите перебросить денюжку вашему товарищу или коллеге за работу. Вам в идеале посредник не нужен, он выполняет сугубо техническую роль. Но давайте посмотрим, например, на онлайн-покупки. Насколько вы доверяете неизвестному вам контрагенту? Полагаю, куда меньше, чем вашему банку, верно? Так вот, в случае работы через банки он деанонимизирован и прошел какую-то верификацию, а при вашем желании (если сделка крупная), большой, сильный и волосатый банкир может выступить ещё и вашим гарантом, что вас не обманут.
С интернет-банкингом всё хорошо. Но говорят, что им не пользуются не только те, кто безнадёжно отстал от жизни, но и те, кто преподаёт интернет-банкинг.
Не относитесь к этому всерьёз. Уровень надежности таких систем достаточный, чтобы ими пользоваться.
Кстати, я в своё время их разрабатывал :)maslyaev
28.06.2017 22:12Совсем отказываться категорически и навсегда — незачем. Но фишка в том, что наличие полиции не отменяет полезность держать в доме ружьё, а наличие скорой помощи — уметь останавливать кровотечения.
Цивилизация по ходу своего развития выработала много разных полезных централизованных «вертикальных» институтов, которым мы с удовольствием делегируем свои заботы. Но чем больше делегируем, тем больше сами становимся зависимыми от этих не контролируемых нами систем. Беспомощными и социально атомизированными. Надо всё же как-то потихоньку аккуратно пытаться забирать рычажочки обратно в свои руки. Хотя бы для начала в плане контроля. А там, глядишь, и горизонтальные структуры выстраивать научимся.
Уровень надежности таких систем достаточный, чтобы ими пользоваться.
Это у меня просто вспомнилась старая добрая шутка.
Конечно можно пользоваться. Только надо помнить, что если банк лопнет, с доказательствами обоснованности претензий могут быть проблемы.
qw1
28.06.2017 17:27Но вообще тема ведения защищённых реестров — это ни фига не смешно.
Проблема в том, что записи легко компрометируются. Забыл в USB-разъёме свой ключ, и троян написал в блокчейн, что ты должен кому-то 100500 денег. Или что есть непогашенная судимость, или ещё что-то. И удалить это уже нельзя, как ни старайся. Поэтому я не думаю, что такие базы будут использоваться вместо государственных реестров.maslyaev
28.06.2017 17:51Вот тут я не согласен. Плохая запись — тоже запись. Не нравится плохая запись — вводим сторнировку. В реестре остаётся и факт пакости, и факт её исправления. Обычное дело в системах, не допускающих правку задним числом.
qw1
29.06.2017 08:00Что должен подумать HR, если он видит, что в реестре у соискателя судимость сторнирована? Подумать, что бывает — технический сбой, или что он накопил денег и дал взятку, чтобы провели аннулирование?
sumanai
28.06.2017 19:01Вы преувеличиваете озабоченность людей своими данными. Они в большинстве своём склонны доверять крупным компаниям и государству, и с лёгкостью вписывают свои данные в сервисе почты, отсылают всю музыку в Google и привязывают банковскую карту и подтверждают оплату отпечатком пальца в iPhone.
maslyaev
28.06.2017 19:56Сам сто раз так делал.
В 99.9% случаев всем на всё наплевать. И это правильно. Но есть некоторый хоть и маленький, но очень важный процент случаев, когда совсем не наплевать. И тогда хоть плачь.
Tangeman
27.06.2017 01:39Насколько я вижу из описания, это то что уже сравнительно давно применяется и имеется куча готовых решений — известно под названием «keyless signature infrastructure» или даже просто «keyless signatures».
AirLight
27.06.2017 02:51Прям какой-то заговор против мифического злого блокчейна на который надо много вычислений и электричества. Хорошо хоть в настроящем блокчейне (который даже не биткоин) можно самостоятельно выбирать сложность вычислений, вплоть до минимальной, необходимой для вычисления одного хеша на подпись блока.
NIKOSV
27.06.2017 03:01Не понимаю, зачем в блокчейне хранить все транзакции всех клиентов? Достаточно ведь хранить состояние «кошельков» клиентов, по сути хеши кошельков клиентов. А дальше пусть каждый клиент хранит состояние своего «кошелька» и свои транзакции у себя. Дальше если хочешь заплатить/перевести деньги, отправляешь свой «кошелек». Принимающая сторона сравнивает его хеш с хешем в блокчейне, если все ок, обновляется состояние обоих кошельков и новые хеши обоих кошельков постятся в сеть. Понятное дело что это все очень поверхностно, есть купа проблем которые нужно решить, к примеру чтобы оба клиента не вступили в сговор, но концепция понятна.
flyaway
27.06.2017 03:45+2>В Ethereum добавляется быстрее, но в любом случае довести время до долей секунды невозможно.
Graphene (Steem, Golos, BitShares) вы, надо понимать, не видели? 100.000 tx/sec
Не говоря уже о DAG (Byteball, IOTA)
>Майнинг — это очень ресурсоёмко. Он, собственно, и нужен для того, чтобы добавить в архитектуру вычислительную сложность.
>Очень дорого. Следствие ресурсоёмкости.
Про PoS тоже не слышали.
А мнение имеете.haiflive
27.06.2017 05:38+3да возможно кому-то стоит провести обзор новых крипт на Хабре, а то народ-то оказывается не в курсе…
maslyaev
27.06.2017 11:39+1Всеми лапами поддерживаю это предположение. Очень трудно ориентироваться в этой изрядно замусоренной маркетинговым хайпом теме.
haiflive
27.06.2017 13:42Да вот в том-то и проблема, я вроде бы нахватался кусками, да, много интересных, полезных и действительно прорывных технологий на блокчейн построили, некоторые уже встроили защиту от DDOS и улучшенные алгоритмы достижения консенсуса, другие полную анонимность, кто-то повышает скорость и масштабируемость, уже биржи на блокчейн умудрились построить, вроде бы всё что можно уже изобрели и всё равно продолжают изобретать каждый день…
… но к сожалению изучать более подробно каждую крипту не могу, каждый месяц выходят чуть ли не по 50 новых крипт…
хабре действительно нужен поверхностный обзор? или это будет воспринято как маркетинговый хайп?maslyaev
27.06.2017 13:46+1Мне кажется, вообще невозможно заранее угадать, что нужно уважаемой публике и что как будет воспринято. Так что лучше, наверно, действовать по вдохновению. Если вдохновение есть и сил нет молчать, то зачем себя мучить?
aleks_raiden
29.06.2017 08:11Настоящих криптовалют, со своим блокчейном — уже давно столько не выходит. Токены выпускают да, но и это до десятка в неделю, не наш случай. А все приведенные монеты с интересными технологическими решениями — их пару десятков всего родилось за все время существования технологии. Статья нужна, наверное стоит заняться
haiflive
29.06.2017 10:30Если бы они выходили со словами «это не новая технология мы просто форкнули вон тот проект и сделали сайт», да было бы проще, но каждая из них выходит с кучей маркетинга и конечно же словами «это новая революционная технология, ничего подобного ранее не было»
maslyaev
27.06.2017 11:33+1Мне идея PoS не нравится. Во-первых, она как бы приглашает денежный мешок прийти и цинично поиметь всю остальную мелкую публику. Во-вторых, вообще себе не представляю, как идею PoS натянуть на модельную ситуацию с продажниками и резервированием товара. С кого будем требовать депозит? И, главное, зачем?
PoS исходит из предположения, что больше всего в правильном функционировании системы заинтересован тот, кто вложил в неё больше всего бабосов. Предположение это может быть не верным сразу по нескольким причинам.
Этак можно плавно дойти до технологии PoG. Proof of gun. У кого пушка, тот и прав :))qw1
27.06.2017 14:52она как бы приглашает денежный мешок прийти и цинично поиметь всю остальную мелкую публику
Я тоже так думал, пока не изучил алгоритмы.
Но оказалось вот что.
Условие майнинга блока:
hash(timestamp, prev-chain-state, UTXO) < d * f( money(UTXO) ) * g( age(UTXO) )
где UTXO — некая транзакция-приход на твой кошелёк, d — коэф. сложности, money — кол-во денег в транзакции, age — как давно сделана транзакция.
Чем дольше лежит монетка без движения, тем больше шанс получить награду майнинга. Но при этом выигрывшая транзакция расходуется, и приходит новая, с обнулённым возрастом. Это несколько смягчает правило «только богатые богатеют».
Можно разделить сумму на много UTXO, тогда их будет много с растущим age, но в каджой будет меньше сумма, а значит, и вероятность намайнить, поэтому на этом не сыграешь.
Минус текущих блокчейнов в том, что полных нод очень мало. В-основном, все майнят в пуле (которые являются полными нодами). А значит, нет большой избыточности и надёжности сети.
С PoS, чтобы майнить, нужно держать полную ноду в онлайне (выключил ноду — пропустил возможную выдачу награды). Поэтому PoS-майнинг хорошо скажется на кол-ве узлов и доступности p2p-сети.qw1
27.06.2017 14:58Кстати, если ф-цию
f(money)сделать логарифмической, от разница вероятности выигрыша между миллионером и бедняком будет всего лишь в 10 раз.
При этом, миллионеру будет пофиг на майнинг, потому что награда блока всегда фиксированная, ему при миллионе денег плюс/минус 5 монет ничего не стоит.
maslyaev
27.06.2017 15:10Если навскидку, такая технология мотивирует участников держать деньги без движения. Для системы, ориентированной на накопление и сбережение актива это норм, а для системы, призванной быть расчётным механизмом — очень не очень. Грубо говоря, деньги в огромных количествах копятся в матрацах, но торговля чахнет, потому что всех жаба душит тратить.
Сказка, как всегда, кончается в тот момент, когда народ решает наконец-то распотрошить матрацы и уйти в кэш. Кто успел — молодцы, а кто не успел, тот топит печку деньгами. В данном случае у нас даже печку такими деньгами не растопишь.
Чтобы денежка была устойчивой, бывает полезно, чтобы у её денежной массы должна быть высокая оборачиваемость. Соответственно, конструктивные фичи, мотивирующие на снижение оборачиваемости, можно рассматривать как зло.
2PAE
27.06.2017 08:32Классическая проблема, кто сторожит сторожей?
В предложенной ситуации, я про отдел продаж, надо не логи вести, а системщиков защищать. Они и оказались слабым звеном.
И вероятно поднять им зарплату или взять на работу женатых устойчивых или вобще педерастов, будет заметно дешевле и надежнее чем городить очередную железку, которую они сами же и смогут обойти.
yukon39
27.06.2017 10:55+4Вообще решение организационных вопросов техническими методами редко приводит к ожидаемым результатам.
В обсуждаемом примере, ИМХО, надо решать исходную посылку — повышенные бонусы при продаже дефицитного товара.
Хотя что это за посыл такой вообще? Ходовой товар никак не может быть дефицитным (отдел закупок, вы здесь вообще?). В свою очередь дефицитный товар не может месяцами лежать на складе.
Здесь проблема не отдельных продажников, а руководителя отдела продаж и руководителя отдела закупок. Первый не мониторит оборачиваемость «дефицитного» товара на складе, второй не обеспечивает поставки «ходового» товара в необходимых объемах. Крайними же назначили ИТ-шников. Шикарно!
SergeyUstinov
27.06.2017 11:58Проблема даже не в начальниках отделов, а в директоре и выше. :)))
Сама по себе проблема действительно может возникать, но только при плохом руководстве.
«Оказалось, что что в реализации не была учтена сила обаяния менеджеров по продажам. Ради высоких бонусов они повадились сговариваться с системными администраторами, чтобы те вычищали из логов компромат.»
Ну что тут сказать…
maslyaev
27.06.2017 12:01Организационные методы тоже частенько бывают не торт. Наблюдал многократно, как бизнес-процесс обрастает многочисленными сложными разграничениями областей ответственности, запутанными маршрутами согласования и прочей бюрократией. В результате никто ничего сам сделать не может и никто ни за что не отвечает. В таких системах назначить и примерно наказать крайнего — не проблема. Проблема хоть что-нибудь сделать, потому что организационный паралич.
Бонусы, конечно, не за продажу дефицита, а просто за продажу. Но дефицит лучше продаётся, поэтому тот, кто урвал себе дефицит, тот и имеет хорошие продажи.
Отдел закупок может всеми силами хотеть закрыть дефицит, но объективная реальность может быть сильнее. Ну не смог конкретно сейчас произвести производитель больше, чем позволяют его мощности. Бывает.
Дело, конечно, не конкретно в этой ситуации. Это просто пример, чтобы можно было говорить предметно о защищённых реестрах. И чтобы мысль ежесекундно не соскакивала на модную тему криптовалют. Криптовалюты тоже, конечно, интересны, но хочется рассмотреть чуть более широкую проблему.
Firz
27.06.2017 15:21Всякое бывает. Вот Вам пример(пускай даже и кратковременно длящийся) из жизни — видеокарты и блоки питания высокой мощности, которые теперь(точнее пока что) дефицит на рынке комплектующих.
DrPass
27.06.2017 16:48В обсуждаемом примере, ИМХО, надо решать исходную посылку — повышенные бонусы при продаже дефицитного товара.
Скорее всего, не в этом дело. Я с таким не раз сталкивался, дело даже не в каких-то особых бонусах, а в обычной системе мотивации продажника. Если товар дефицитный, а спрос на него большой, менеджер естественным путем сможет сделать на нем неплохую наценку. Поэтому он будет хотеть его заполучить первым.
Но, честно говоря, в первый раз сталкиваюсь, чтобы эта проблема не решалась на уровне сотрудников, которые обрабатывают заказы/резервы от продажников.
igorbarinov
27.06.2017 10:27Следующий уровень — руты деревьев зацеплять за публичный блокчейн транзакциями.
Примеры таких протоколов:
https://opentimestamps.org/
https://chainpoint.org
Tatooine
27.06.2017 12:11-1Интересно почему не пробовали лишать премии тех кто мухлевал с заказами и потом подбивал админов? Или даже уволить парочку?
maslyaev
27.06.2017 12:26+1Наказание — одновременно самый популярный и самый неэффективный способ отучить воспитываемого от нежелательного поведения. С точки зрения воспитываемых причина получения розг не в том, что сделал пакость, а в том, что угораздило попасться. Поведенческая психология.
DrPass
27.06.2017 12:49Наказание — одновременно самый популярный и самый неэффективный способ отучить воспитываемого от нежелательного поведения.
Вы зря так считаете. Речь-то идёт не про воспитание подростков, а про борьбу с халатностью и грубым нарушением должностных инструкций. Получается, работники, по сути, занимаются вредительством на своём рабочем месте, а вы их поощряете к этому. Это в корне неверно. В вашей ситуации надо было делать не хитрый реестр, а триггер, который логирует удаления куда-нибудь, куда нет доступа у администратора этой базы. И потом по итогам анализа логов публично повесить администратора за яйца. И поверьте, это решит проблему раз и навсегда.
Даже более того, можно и без всяких логов, достаточно сделать выгрузку резервов «до» и «после», и сам факт, что кто-то удалил резерв из базы — достаточное основание, чтобы наказать руководителя админов базы (ибо это его непосредственная ответственность). А они уже после этого сами разберутся у себя в отделе, как поступать с менеджерами по продажам, не сомневайтесь.
Понимаете, есть человеческий фактор, есть ошибки и т.д., за них действительно нельзя наказывать, и нужно стараться с помощью технических средств устранять места, которые позволяют допускать ошибки. Но в вашем случае сотрудник, в обязанности которого входит защита данных вашей компании, сознательно занимается их подделкой с целью обмана компании. Как можно к такому относиться лояльно?maslyaev
27.06.2017 13:51+2Из всех методов борьбы с нежелательным поведением самый эффективный (не самый эффектный, а именно самый эффективный) называется «сделать нежелательное поведение невозможным». Если хочется развлечь коллектив кровавым зрелищем, то практика наказаний — именно то, что нужно. А если надо просто и скучно сделать так, чтобы всё было в порядке, есть смысл подумать над выстраиванием системы профилактики.
DrPass
27.06.2017 14:46-1Тут дело не в эффектности. Можно лечить симптомы, можно лечить болезнь. В вашей организации есть реальная болезнь — или вредитель, или дурак на должности DBA. Причем это опасная болезнь для бизнеса. А вы, вместо того, чтобы его выявить и уволить или хотя бы научить уму/разуму, лечите один симптом, который принесла его деятельность.
maslyaev
27.06.2017 15:19На всякий случай ещё раз обращу внимание на то, что описанная ситуация — художественный вымысел. Хоть и по мотивам, но всё же вымысел. Просто моделька на поиграть. Можно придумать ещё миллион ситуаций, в которых функциональность супернадёжного ведения реестра была бы очень кстати.
Да всю свою жизнь мы, чёрт возьми, вынуждены полагаться на добросовестность тех товарищей, чью добросовестность проверить у нас нет никакой возможности. И накручивание проверяющих, контролирующих, лицензирующих, утверждающих, согласующих и т.п. органов не только не решает эту проблему, но даже значительно её усугубляет.DrPass
27.06.2017 16:49На всякий случай ещё раз обращу внимание на то, что описанная ситуация — художественный вымысел. Хоть и по мотивам, но всё же вымысел
Если история придуманная, то это другое дело. Но я с некоторым недоверием отношусь к решениям, которые решают теоретические проблемы :)
Tatooine
27.06.2017 16:49Зерно истины в ваших словах есть, но тут систематические нарушения ДИ, получение личной выгоды, при которой страдает вся фирма в целом. Как известный мем где несколько человек в лодке, которые разбирают лодку по частям и строят собственные лодки. Тем более что вторая часть где манагеры вошли в сговор с IT — за такое нужно увольнять сотрудников обоих отделов.
Понимаю что вся ситуация вымысел, но очень напоминает некоторые эпизоды из моей трудовой карьеры.
sergeyns
27.06.2017 12:21Пример неудачный. Для того чтобы админы не лазили в базы (и не терли логи) давно придумали шифрование.
ЗЫ: Это не помешает восстановить базу при необходимости, но защитит от «подчистки» отдельных записей.
А вообще увольнение таких админов сразу решит проблему «нечего противопоставить».maslyaev
27.06.2017 12:23Не понятно, что конкретно вы предлагаете шифровать.
Публичными казнями, безусловно, некоторые проблемы решаются. Но я бы не рискнул рекомендовать этот метод как универсальное лекарство от всех болезней :))
rumkin
27.06.2017 12:23Уф. Когда вы (все) уже поймете что блокчейн, распределенная структура и майнинг это раздельные технологии!? Ну, серьезно, сколько можно! Git тоже использует блокчейн, но без майнинга. А блокчейн может быть и централизованным.
maslyaev
27.06.2017 12:36Естественно, вы правы. Если есть доверие к инфраструктуре, жизнь прекрасна и легка, но что делать в ситуации, когда априорного доверия нет и не может быть ни к кому и ни к чему? Ну то есть вообще ни капли? В такой ситуации остро встаёт вопрос обеспечения возможности каждому участнику самому убеждаться в том, что никто нигде не смухлевал. Описанная технология именно на это и нацелена.
rumkin
27.06.2017 13:33Если нет доверия к инфраструктуре, используется шифрование, цифровая подпись или такое число разнообразных каналов/получателей, которое физически невозможно взломать. Но это все имеет мало отношения к блокчейну, точнее оно так же относится к блокчейну, как и к любому другому способу проверки целостности.
maslyaev
27.06.2017 14:19Шифрование и подпись нужны когда нет доверия к каналу связи. А блокчейн и описанная здесь игра с хешами нужна когда нет доверия к адресату. Разница.
corr256
27.06.2017 14:27остро встаёт вопрос обеспечения возможности каждому участнику самому убеждаться в том, что никто нигде не смухлевал
всех убить, планету взорвать. другое не поможет
ncix
27.06.2017 13:48Модельная ситуация (художественный вымысел по мотивам реальных событий)
В пример очень даже верю — но выводы и решения руководителей близки к невменяемости. Достаточно было устроить одну показательную порку менеджера, пойманного на таких махинациях, и админа, потершего логи.
После — доработать систему так, чтобы убытки за фиктивный резерв вешались на менеджеров.
Блокчейн тут конечно вроде бы в тему, но суть проблемы в плохой дисциплине.
maslyaev
27.06.2017 14:17+1Не относитесь, пожалуйста, слишком серьёзно к этому вымыслу. Он здесь только для того, чтобы придать разговору некоторую наглядность. Чтобы не возникало совсем уж полных непоняток типа «что за такие загадочные реестры?».
Если говорить в целом, то ситуация «использование сервиса в условиях, когда к владельцу сервиса нет доверия» случается с нами примерно постоянно. У меня не может быть полного доверия к кассиру в супермаркете, и поэтому у меня должна быть возможность проверить по чеку взятую с меня сумму. У меня не может быть доверия к водителю автобуса, что он не повезёт меня куда попало, поэтому пусть у меня будет окно, посмотрев в которое я смогу убедиться, что едем в правильном направлении. И так далее. Применительно к информационной системе у меня должна быть возможность проверить, что там по-прежнему лежит то, что я туда положил (это просто), а также что там ничего не подкрутили задним числом, в результате чего то, что я сейчас делаю, станет глупостью и/или преступлением (для этого у нас блокчейны и вот эта описанная здесь технология).
Логотип автобусной компании может быть сколь угодно красивым, водитель может выглядеть сколь угодно основательно, но всё же ребята, дайте мне окно, чтобы в правильности происходящего я мог убедиться сам. Никому не в обиду, просто так правильно.
shalomman
27.06.2017 21:05+1я бы в этой ситуации гит поставил + удаленно запустил какой нибудь дженкинс, чтобы все время тянул обновления. Если кто-то попытается пепеписать историю, то я обязательно узнаю.
AirLight
03.07.2017 19:36Вы удивитесь, но в гите те же самые хэши и деревья, почти все как у автора.
maslyaev
03.07.2017 21:17Хеш-деревья (Merkle trees) — весьма популярная тема. Используются много для чего. В том числе даже, если не ошибаюсь, в «типовом» биткойновском блокчейне.
Но фишка здесь не в этом, а в том, что такая конструкция позволяет так покрыть хешами всю имеющуюся предыдущую цепочку, чтобы оперативная проверка её целостности была простой, дешёвой и никому не напряжной.
В принципе, предыдущую цепочку можно фиксировать всего одним хешем, но тогда контроль целостности будет требовать прочитки всего реестра, и это уже не сделаешь частью процедуры, выполняющейся при каждом обращении.
mickvav
Гхм, а кэшировать n+1-ю строку реестра взяв в качестве соли кэш от n-й строки не проще?
vanxant
Для проверки придется считать с нулевой записи, это O(n). Здесь же типа дерево предлагается, O(log n)
maslyaev
Точно.
Реестр может быть очень большим, и если для быстрой проверки нужно будет выкачать всё, что туда свалилось за последний, например, месяц, проверка эта уже не будет быстрой. Следовательно, в качестве обязательной процедуры при добавлении новой записи это уже не встроить.
mickvav
Ну тут вопрос в том, держат ли клиенты локальные копии реестра. Если держат — там все равно куча O(n) операций, от ещё одной сильно хуже уже не будет.
maslyaev
Клиенту незачем держать у себя весь реестр. Клиент может быть в том числе мобильной приложухой. Он держит у себя только собственные операции + хеши, фиксирующие предыдущие состояния реестра. Объём хранимого на клиенте получается что-то вроде O(log(NT) * NC), где NT — полный объём реестра, а NC — собственные операции клиента.
MikailBag
А может там плюс?
maslyaev
Наверно, всё же умножить, потому что борода хешей хвоста приваливает с каждой собственной операцией.
Не суть. Всё равно получается никому не больно. Потому что собственные операции всё равно нужно иметь у себя, а логарифм — штука не напряжная.
Gorthauer87
А это разве не блокчейн уже?