Блокчейн в базе 1С

Вокруг блокчейна в последнее время поднято много шума. Курс биткоина кого-то радует, кого-то злит, но впечатляет всех. За всем этим остается не увиденной и не оцененной по достоинству изящная простота самой технологии. Блокчейн можно без особых затрат добавить к любой базе данных, и база 1С не исключение. В моем рабочем примере менее 200 строк кода в обработке, которая создает цепочку блоков. Еще 30 строчек занимает процедура контроля. Ниже я покажу по шагам - как сделать блокчейн в любой базе 1С, и что это даст в итоге.

Перейти к публикации

Комментарии
135. Александр Иванов (tunesoft) 203 19.12.17 13:05 Сейчас в теме
(82) про стоимость непонятно, поясните, пожалуйста. Инсайдер-админ в 1С базе может внести любые изменения и ему неважно что цепочка записей в блокчейн неправильная, может полностью все записи блокчейна удалить.
(135) Админ может и базу удалить. И не только админ, а даже уборщица.
152. Александр Иванов (tunesoft) 203 19.12.17 17:10 Сейчас в теме
(138) "Стоимость успешной атаки на мою систему зависит от выставленного уровня сложности."
Не зависит от уровня сложности.
Зависит за какую сумму согласится "уборщица" или "админ" удалить базу. :)
(152) Вы не знаете - что делать, когда удалили базу? Могу подсказать )))
238. Сергей Смирнов (milanse) 31 22.12.17 09:37 Сейчас в теме
(82) Каким образом регулируется сложность атаки ?

Да и в чем смысл атаки, если таблица полностью в руках одного участника и он может менять ее как ему заблагорассудится.
(238) Сложностью нахождения "красивого" хэша. Таблицу нельзя менять, как заблагорассудится. Таблицу надо менять так, чтобы она прошла контроль. Надо заново найти "красивые" хэши, потратить на это большие ресурсы.
80. Вадим Мориков (vadim1011985) 45 18.12.17 17:02 Сейчас в теме
(78) Что значит с неизменяемыми транзакциями ?? Документ можно изменить - просто система укажет на это - в данном случае это тот же журнал регистрации.
(80) Журнал регистрации можно изменить. Можно изменить базу, не меняя журнала регистрации. Ничего этого моя система не позволяет.
88. Вадим Мориков (vadim1011985) 45 18.12.17 17:19 Сейчас в теме
(83) Еще раз, вашу систему можно изменить - например поставить сложность 0 поменять документ, сформировать пересчитать хеши (при 0 сложности доли секунды) или вообще изменить код проверки , в общем изменить код вашей обработки. Я уже говорил об этом. Интересно когда пользователь догадается что код изменен ?
(88) Пользователь с утра выпьет чашечку кофе. Почитает новости на инфостарт, а заодно и скачает контрольную обработку. Вот собственно и все.
Насчет сложности в обработке генерации - примерно то же самое. Вообще атака путем подмены кода - легка, изящна, и... легко отражаема.
95. Вадим Мориков (vadim1011985) 45 18.12.17 17:35 Сейчас в теме
(91) У вас есть машина ? Вы каждый раз прежде чем поехать лезите в мотор смотрите каждый винтик шурупчик и т.д. заказываете оригинал двигателя что бы убедится что у вас все ок ?
(95) Ну я иногда бензин заливаю. Да что там иногда. Постоянно заливаю! ))))
100. Вадим Мориков (vadim1011985) 45 18.12.17 17:48 Сейчас в теме
(98) Мотор значит не смотрите ? Так почему вы считаете что пользователь должен каждый раз заходить и проверять не изменился ли код ? так и изменения можно вернуть обратно после своих "грязных дел" ))

или удалили все документы Блоков - и все понятно что кто-то залез а где и что изменяли - непонятно
(100) Изменения кода вернуть обратно нельзя. Это же атака на код. Она потому и отражается легко, что нельзя. Ваши "грязные дела" спрятаны только до тех пор, пока код изменен. Вернули нормальный код, "дела" тут же и всплыли.
Что касается удаления блоков. Так ведь и базу можно легко удалить. И что вы тогда делать будете?
(100) Я хочу ездить на машине - я заливаю бензин.
Я хочу иметь безопасную базу - я закачиваю безопасную обработку.
Все просто.
136. Александр Иванов (tunesoft) 203 19.12.17 13:07 Сейчас в теме
(83) что значит система не позволяет ? администратор не сможет удалить все записи вашей системы ? как вы это обеспечите ?
(136) Это не останется незамеченным. Также, как не останется незамеченным удаление всей базы.
154. Александр Иванов (tunesoft) 203 19.12.17 17:13 Сейчас в теме
(148) Согласен, будет заметно что что-то изменили, но кто и что изменил будет неизвестно в случае удаления всех записей блокчейна.
(80) Система укажет на это. Будет проведено расследование и документ будет восстановлен.
85. Серега (SerVer1C) 67 18.12.17 17:09 Сейчас в теме
Как быть с тем, если в первичном документе требуется поменять какое-то неправильно введенное значение? Такое часто бывает. При работе. Людей. Тогда придется пересчитать весь остаток цепочки.... Как-то грустно и дОлгО...
(85) Ввести в систему документ коррекции. Если изменения существенны. Если надо поменять всего лишь комментарий, тогда, при правильной настройке (см. интерфейс обработок), ничего дополнительно делать не надо.
87. Серега (SerVer1C) 67 18.12.17 17:18 Сейчас в теме
(86) Вы реально представляете, сколько документов может меняться в прошлых периодах в продакшн-базе? Только и придется затратить все вычислительные мощности, чтобы пересчитывать хэши. Ваша статья интересна в академических целях и для другого применения технологии блокчейн, но не ради того, чтобы знать, что документы не изменялись.
(87) Представляю. От ни одного до очень много. Вы, быть может, видели только одну "продакшн-базу" с одной идеологией корректировки. А я видел своими глазами множество баз где все изменения вносились отдельными корректирующими документами. И в этих базах не было ни одного документа, измененного задним числом. По крайней мере, владельцы очень на это надеялись.
Кстати, практика работы "задним числом" потому и получила такое широкое распространение, что запрет не имел смысла. Не было надежной гарантии от изменения старых документов.
93. Серега (SerVer1C) 67 18.12.17 17:33 Сейчас в теме
(90) До блокчейна было версионирование или простой "триггер" на запись документа. ))) Отследить изменение можно намного более простыми методами. А с применением блокчейна: ну изменили док, ну вы поняли, что док изменен и что дальше? Как блокчейн поможет НЕ изменять документ???
(93) Он делает цену изменения документа непомерно высокой.
111. Артём Шарипов (borodatii) 1 19.12.17 07:22 Сейчас в теме
(96) непомерно высокая цена изменений означает такую же цену внесения данных.

Если уж фантазировать, что нашелся человек, который может писать напрямую в базу, то почему бы ему не сделать копию базы, забрать её к себе и там, в спокойной обстановке запустить пересчет хешей за день-два. И потом залить их в реальную базу. Даже пересчет двух хешей, изменённого документа, и следующего за ним, покажет, что изменили второй документ, а не первый. И что делать?
115. Серега (SerVer1C) 67 19.12.17 09:10 Сейчас в теме
(96) А вот с этого момента, пожалуйста, подробнее. Может быть вы хотели сказать, что высока цена сокрытия факта изменения документа, а не самого документа?
(115) А какая, собственно, разница? Если вы не можете скрыть факт изменения, это значит что в современном мире, где уже многие знают значение слова бэкап, вы не можете изменить документ.
139. Серега (SerVer1C) 67 19.12.17 13:26 Сейчас в теме
(129) Дешевле сравнить хэш дока из бэкапа с хэшем дока в базе. Имея некоторый доступ к системе можно прописать красивый хэш предыдущему доку, от него рассчитать по данному алгоритму красивый хэш для текущего дока - и вы уже не заметите, что док был изменен, вы же не станете верифицировать весь блокчейн?
(139) Процедура контроля проверяет всю цепочку. Посмотрите.
89. Вадим Мориков (vadim1011985) 45 18.12.17 17:23 Сейчас в теме
(86) Опять же читайте про блокчейн - систему можно взломать , при условии что у злоумышлиников будет доступ к 60-70 % узлов данной сети (в реальности можно считать что такой результат трудно достичь , я бы даже сказал невозможно) - в вашем случае получается все 100 %
(89) У вас неверные сведения. Есть только одна (гипотетическая конечно) атака на биткоин. Это получение 51% мощностей. Узлы тут вообще ни при чем.
Я не говорю, что мою систему нельзя атаковать. Я говорю, что вы, как пользователь, можете сами установить цену атаки и сделать ее бессмысленной.
92. Вадим Мориков (vadim1011985) 45 18.12.17 17:32 Сейчас в теме
И еще один вопрос - многопользовательская работа - допустим какой-то холдинг на 300 пользователей - можете сказать скорость обработки допустим при сложности 3 (ну или 2) на сколько это повесит систему ? А если учесть еще и раздельную работу например один пользователь создает документ - второй проверяет корректирует , третий тоже что-то вносит не существенное , как будет вести себя ваша система.
(92) Вообще не повесит. Ну работает еще один "пользователь", читает документы время от времени.
(92) В том то и дело, что система достаточна автономна по отношению к основной системе. Вся нагрузка - однократное (за все время) прочтение каждого контролируемого документа.
103. Эльдар Мухамедзянов (lastcontra) 42 18.12.17 20:40 Сейчас в теме
Михаил, спасибо за публикацию. Согласен, что многие оппоненты отошли от новизны идеи. Появилась мысль: сложность динамически высчитывать в зависимости от времени работы алгоритма блокчейна по исходным документам за 1 день, как в примере биткоина (длина блока зависит от скорости добывания новых блоков). Жалко, конечно, что зависимость скорости от сложности - это не линейная функция.
gubanoff; +1 Ответить
(103) Спасибо за отзыв. Ваша мысль интересна. Дополнительно храним в блоке сложность. Непонятно пока как защитится от такой атаки: для перестроения цепочки атакующий подменяет исходную сложность на минимальную.
105. Доржи Цыденов (support) 4154 18.12.17 21:50 Сейчас в теме
Снимаю шляпу! Реально, все гениальное просто. Технология блокчейн действительно можно использовать для контроля последовательности проведения документов! Это же лежало на поверхности.
Это дает огромные возможности для создание ERP-системы нового поколения.
Можно создать систему с прозрачным и надежным к взлому аудиторским следом, до бесконечности. Именно то, что повышает капитализацию предприятия для инвестора. То, чего не хватало 1С. Это возможность выхода на мировой рынок.
С точки зрения маркетинга это тоже супер!
Надо создать подсистему для типовой, возможно с облачным сервисом, который будет обладать огромными вычислительными мощностями и сдаваться для вычисления красивого хеша. Опять же майнеров перепродавать.
davydoff; +1 Ответить
(105) Спасибо за лестный отзыв! Вам, возможно, будет интересно узнать, что идея родилась несколько дней назад здесь:
https://forum.infostart.ru/forum95/topic183216/
Из обсуждения вы можете увидеть, что я сам сначала нелестно отозвался об идее прикрутить блокчейн к обычной базе. Потом подумал: а вдруг в этом что-то есть. Понял, что есть. Идея показалась настолько простой и красивой, что ближайшие выходные были принесены в жертву тому, чтобы донести ее до уважаемого сообщества. Надеюсь, что эта публикация даст старт множеству интересных разработок. Ваша идея насчет облака очень интересна. Тут действительно открываются необыкновенные возможности. Можно наполовину майнить, наполовину обсчитывать безопасность. Можно задействовать майнеров и частично снять с них упреки в том, что они понапрасну тратят электроэнергию. Вот же сахар со склада не воруют. Есть польза? Есть.
112. Александр П. (tiniji) 149 19.12.17 07:28 Сейчас в теме
(105) Это отличная идея майнинга за стартмани ;)
117. Доржи Цыденов (support) 4154 19.12.17 09:42 Сейчас в теме
(112) вообще, в этом виде можно реализовать блокчейн для стартмани. Хранить цепочку транзакций. Хеш брать из суммы, адресата, отправителя, даты. Только что это даст? Надо подумать.
Т.е. это не в чистом виде криптовалюта, а просто контроль последовательности транзакций. Но мне кажется и так все доверяют транзакциям стартмани.
113. Maxim Kolkin (the1) 293 19.12.17 08:29 Сейчас в теме
(105) Доржи, что-то Нью-Васюки всомнились )
108. Сергей Начина (serg_gres) 133 19.12.17 01:24 Сейчас в теме
Вот так вот прогресс шел, шел...все ускорял и оптимизировал проведение документов, а тут пришли биткоин с блокчейном, все поломали и развернули вспять...

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

Наверное проще хэши документов хранить в какой то удаленной базе, и документы будут быстро проводиться и контроль будет
DAAbramov; the1; +2 Ответить
109. Роман Уничкин (unichkin) 818 19.12.17 01:25 Сейчас в теме
Автор, ознакомтесь с ИТС, перед тем как писать код..
https://its.1c.ru/db/v8std/content/2149184103/hdoc
https://its.1c.ru/db/v8std/content/2149184090/hdoc
и т.п.
Если говорить о кодинге в конфигураторе - то соблюдение элементарных правил это хороший тон.. Если про статью - то имхо, обязанность. Кто-то смотрит, учится на таких примерах, копирует их. А учится на подобном не стоит.
Плюсанул только за интерес к контексту и поднятое обсуждение.
li5enok; eden_gmail; artbear; DAAbramov; +4 4 Ответить
114. Дмитрий Абрамов (DAAbramov) 19.12.17 08:44 Сейчас в теме
Всем привет! Все же суть блокчейна в его децентрализованности. Чтобы каждый из сети получал полную уверенность в том, что все играют "по-честному". Здесь же вся инфа хранится в одной базе, а так же можно получить физический доступ к ней(Напомню, что ни одна серверная ОС не гарантирует секьюрность в случае получения фактического доступа, и поэтому я считаю, что это противоречит самой идеологии блокчейна.
Тем не менее статья подняла обсуждение и думаю данный алгоритм(не блокчейн) - может применяться в некоторых случаях, а каких надо думать =)
116. Доржи Цыденов (support) 4154 19.12.17 09:35 Сейчас в теме
(114) Никаких противоречий, цепочку можно хранить децентрализовано. Основной смысл, что физический доступ не дает преимуществ.
Хранить цепочки будут майнеры, которые могут получать доход с каждого проведения. А за хранение проведения будет платить компания, которой нужен блокчейн аудиторский след.
120. Владислав Свинцов (VSvintsov) 13 19.12.17 10:29 Сейчас в теме
хорошая статья - только зря не рассматриваете эти доработки в качестве нормальных крипто денег.
крипто деньги не могут быть средством накопления, но вот средством обмена запросто : товар - крипта - товар.

ресурсы даже внутри организации ограничены - поэтому можно предположить футуристическую картинку, когда руководство каждому отделу в начале месяца выделяет некоторое количество крипты для оплаты работы сотрудников IT :) .
нужно -потратили, не нужно - хорошо работаете и конвертируете эту крипту в премию :-)
125. Алексей Князьков (AKnyazkov) 19.12.17 11:38 Сейчас в теме
А зачем такой треш в функции ПолучитьДокументСтрокой() , а чего бы не использовать ЗначениеВСтрокуВнутр(<Значение>) ?
(125) Я хотел продемонстрировать хэш не по всем реквизитам, а только по выбранным. Для типовых конфигураций это актуально.
(125) К тому же, строковое представление документа может включать в себя записи движений регистров. Тут уже ЗначениеВСтроку не поможет.
149. Алексей Князьков (AKnyazkov) 19.12.17 16:00 Сейчас в теме
(141) там в функции вы получаете массив, а вот он то как раз отлично значением в строку и преобразуется, вот что я имел ввиду.
(149) Действительно можно и так. Массив значений, а потом массив в строку. Заодно и ИД получим.
151. Алексей Князьков (AKnyazkov) 19.12.17 16:05 Сейчас в теме
(150) Ага, и дешево и сердито и красиво
130. Вадим Мориков (vadim1011985) 45 19.12.17 12:51 Сейчас в теме
Я бы в блок добавил автора документа и Текущего пользователя (кто изменяет , удаляет или редактирует) и все изменения писал бы новый блок, а так же реальное время изменения (создания , редактирования документа). Тогда реально можно смотреть историю документа , кто когда и как изменял.

Еще плюс к этому в сейчас блокчейндж работает по одному документу поиск последнего блока идет без привязки к типу документа , может стоит разделить цепочки для каждого из типов?
131. Роман С (Dach) 95 19.12.17 12:57 Сейчас в теме
Спасибо за статью!

Прикручиваем РИБ. Включаем в блоки все документы. И вот, на уровне всей системы уже реальный механизм контроля неизменности документов (это к вопросу о применяемости). Обработку контроля вешаем на регламентное задание с отправкой письма, как только кто-то поменял в документе 100 рублей на 1 рубль и цепочка разрушилась... Вуаля))
134. Вадим Мориков (vadim1011985) 45 19.12.17 13:05 Сейчас в теме
(131) тут вопрос синхронизации при добавлении нового блока система должна оповещать всю сеть и каждый узел сети, после проверки должен добавить блок в свою копию цепочки. поэтому с РИБ проблематично
143. Роман С (Dach) 95 19.12.17 14:00 Сейчас в теме
(134)
ут вопрос синхронизации при добавлении нового блока система должна оповещать всю сеть и каждый узел сети, после проверки должен добавить блок в свою копию цепочки. поэтому с РИБ проблематично


если Вы попробуете скачать локальный кошел любой криптовалюты - то именно это и происходит. По сути, Вы себе на свой домашний ПК затаскиваете весь блокчейн от самой первой транзакции до самой последней. И периодичски еще синхроните, если хотите с кошельком работать
132. Анатолий Ситников (acsent) 1053 19.12.17 13:00 Сейчас в теме
А какова последовательность действий когда документ все-таки изменили?
Теперь он будет пожизненно висеть в измененных?
(132) Провести расследование и восстановить документ в базе.
181. Сергей Коцюра (CheBurator) 3411 20.12.17 01:01 Сейчас в теме
(137) имхо, плохая идея. может быть, что не получится восстановить документ в первозданном виде и придется пересчитывать всю цепочку от измененного документа...

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

> Документ проводится, затем попадает в цепочку.
- чем это обеспечивается? если подменили "процедуру" "Документ проводится, затем попадает в цепочку"..? надо обеспечивать неизменность "процедуры"...?
(181) А еще, бывает, люди базы теряют. Ну что значит "не получится"? Все бэкапы потеряют? И бумажный тоже?
Подмена кода ничего не даст атакующему. Код восстановят и его атака всплывет.
142. Александр Глебов (HanterVol) 8 19.12.17 13:56 Сейчас в теме
Идея то хорошая, но что будет если в документ добавят новый реквизит? или в движениях?
Хэш то изменится....хотя документ никто не трогал
(142) Посмотрите решение. Там хеш строится по выбранным реквизитам.
144. Артём Андриянов (CSiER) 15 19.12.17 14:44 Сейчас в теме
Спасибо за интересную статью, ещё бы код оформить до более читаемого вида и было бы супер :)
Просьба описать подробнее - где и как планируете применять данное решение.
Данный вопрос возник потому, что:
Теоретически, конечно, можно попросить знакомого китайского майнера задействовать его ферму для решения данной задачи.
- в данном случае такой же запас мощности понадобится и Вам, чтобы получить результат функции "ПолучитьКонечныйКлюч". Например, есть блок документа 1 и нужно получить хэш для блока документа 2. В случае запуска ПолучитьКонечныйКлюч с минимальным значением сложности злоумышленнику не составит труда "напакостить". Если же сложность очень высока, то Вам уже понадобятся большие вычислительные ресурсы для подписи каждого блока.
Стоимость атаки на мою защиту зависит от выбранной сложности и может быть сколь угодно большой.
- чем выше сложность, тем больше нужно вычислительной мощности в первую очередь Вам, чтобы система просто работала. Другими словами, в данном варианте защита строится на том, что у Вас изначально мощность больше, чем у злоумышленника (он ведь и за выходные может это пересчитать, а Вам нужно опеспечить онлайн работу системы, то есть функция ПолучитьКонечныйКлюч должна работать за какое-то ограниченное время, скажем, чтобы уложиться в ограничения транзакции СУБД на проведение документа). В этой системе отсутствует "сложность решения обратной задачи" (классический пример - алгоритм RSA), где злоумышленнику нужно приложить намного больше "усилий" для взлома системы, чем самим пользователям. То есть и Вы и злоумышленник будете решать одну и ту же задачу - перебор результатов хэш-фукнции в зависимости от переданной соли.
Представьте - у вас 10 компов работают с 10 часов до 20 часов. Ну добавили вы к ним еще один, который работает круглосуточно. Какие ресурсы? Для большинства случаев - этого будет достаточно.
- злоумышленнику в этом случае понадобится такой же комп, а в случае выбранного алгоритма хэширования - б.у. со средней видяхой двухлетней давности. Если же есть такой "свободный" и надежный комп (ведь если
его скомпрометируют и он начнет выдавать "левые" хэши или перестанет работать - а тут отчетность, простои и т.д.) и хочется использовать блокчейн - имхо проще убрать майнинговую составляющую в функции ПолучитьКонечныйКлюч и хранить последний хэш каждого дня на этом компе (похожий пример с отличным описанием и кодом на Gitbuh можно глянуть тут).
(144) Идея строится на том, что атакующий будет вынужден догонять. И для этого, ему придется задействовать более серьезные мощности, чем есть у вас. Но ваш вопрос - интересный. Действительно можно придумать ситуацию, когда атакующий будет не догонять, а идти параллельно. Тут надо подумать.
155. Артём Андриянов (CSiER) 15 19.12.17 17:14 Сейчас в теме
(146), не до конца понял логику (о том, что атакующий будет догонять) - просьба описать детальнее (если можно, то на примере). Например, злоумышленник решил "прихватизировать" 2 кг сахара, он знает как работает система, имеет доступ к серверу с субд и 1С. Генерация хэшей идет на том же сервере, где работает служба 1С (например, с помощью механизма фоновых заданий). Чтобы сложность была выше, документы добавляются в блок не по одному, а пачкой с разбивкой по часу (то есть можно геренировать 1 хэш за час). За 8 часов рабочего дня получится 8 блоков. Злоумышленник в конце рабочего дня (после генерации последнего хэша) меняет количество сахара в документе. Теперь ему нужно пересчитать 1 хэш и на это у него около 16 часов. С таким запасом времени он может сгенерировать 16 хешей - то есть поменять данные за текущий и предыдущий рабочие дни. Злоумышленник в этом случае впереди.
Вариант, когда у злоумышленника нет доступа к серверу/железу и т.д. думаю рассматривать смысла нет, так как здесь есть более простые реализации защиты (даты запрета, версионирование, сохранять ВерсияДанных при записи и т.д.).
Думаю, что идею защиты нужно строить на том, что злоумышленник всегда впереди, но ему просто невыгодно заниматься взломом (например, потребуется полный перебор, который с учётом закона Мура закончится к моменту, когда защищаемая информация безнадежно устареет).
156. Вадим Мориков (vadim1011985) 45 19.12.17 17:23 Сейчас в теме
(155) Кстати да ,злоумышленнику вообще парится не нужно , зная как работает система достаточно внести изменения до момента попадания документа в блок, Автор предлагает делает это разово, что бы уменьшить количество ресурсов на вычисление красивых хешей. т.е. на момент записи мы должны быть уверенны что документ содержит актуальные данные (тут уже гарантии нет) , тогда выходит что документ должен попадать в блок во время его проведения , а это в свою очередь может вести к подвисанию системы а если работает человек 100- 200 будут бить данные документы - где-то ошибаться и т.д.
(156) При правильно организованной работе по учету и контролю, нет смысла подменять документ в тот же день. Обнаружат. И в эту неделю тоже обнаружат. Есть шанс проскочить незамеченным, если подменять документ полугодовой или хотя бы месячной давности.
(155) Все не так просто. Атакующий подменит документ, а бухгалтерия его на следующий день проверит. На практике успешные атаки проходили тогда, когда заменяли документ, например, месячной давности. Такой, который никто уже проверять точно не будет. Поэтому я и говорю, что атакующий должен догонять. Но вы правы в том, что есть проблема. Атакующий может начать строить параллельную цепочку и через месяц ее подменить. У этой проблемы есть несколько решений, но их еще надо обдумать.
197. Артём Андриянов (CSiER) 15 20.12.17 12:01 Сейчас в теме
(160), Проблема как раз в том, что идет только гонка мощностей системы и злоумышленника - в этом случае система всегда в проигрыше. Как надумаете реальное решение - просьба поделиться.
159. Murad K (karimov_m) 19.12.17 18:18 Сейчас в теме
Как то все не так..
Какова структура вашего блока? Т.е. у вас вы определяете "блок" как документ? Почему вы храните только один Хэш? Ведь по идее,в блоке, надо хранить как хэш текущего рассматриваемого блока, так и хэш предыдущего. При чем создавать блок (у вас документ) только в случае если есть предыдущий хэш.
Ваш подход, конечно же не кошерный (если я все правильно понял из публикации - я человек и тоже могу ошибаться), сейчас поясню:
Для работы блокчейн-пдохода - необходим принцип Доказательства работы.

Что это значит?

Доказательство выполнения работы (Proof-of-work, POW) — принцип защиты распределенных систем, основанный на необходимости выполнения запрашивающей стороной некоторой достаточно сложной длительной работы (POW-задачи), результат которой легко и быстро проверяется обслуживающей стороной (односторонняя функция).

Т.е главная особенность блокчейна заключается в асимметрии затрат времени - затраты значительны для инициатора запроса (взломщика) и весьма малы для проверяющего (нашей системы).

У вас (на сколько я вижу) данный принцип не соблюден - от этого толку от него не много, разве что действительно, тратить вычислительные ресурсы вами же.

Полезно почитать историю, если кому интересно тут: Доказательство выполнения работы
Откуда все началось..


Данные о блоках (документах) и блоки необходимо хранить также децентрализовано (например на клиентах), также необходим механизм принятия блока и сообщения о новых блоках.
Когда кто-то создает новый блок (документ) - он оповещает об этом всех клиентов сети. Когда новый "клиент системы" (пользователь, который может генерировать блоки/документы) - он должен получать информацию о последнем блоке..
И еще немного надо сделать.. уже нет времени писать)) В следующий раз дополню)
Evgen.Ponomarenko; +1 Ответить
(159) Один блок - один документ. В нем хранятся начальный хеш, хеш документа и конечный хеш. Смотрите публикацию.
Главная идея - нет никакой распределенной сети. Все работает в одной базе. Ассиметрия есть. Сравните процедуру генерации и процедуру контроля.
168. Murad K (karimov_m) 19.12.17 18:46 Сейчас в теме
(161) И в чем ассиметрия? Если вы и там и там используете SHA256 и при генерации блока и при его проверки?
SHA256 само собой не подходит для задачи ассиметричной проверки..
(168) Генерация находит красивый хеш. Контроль проверяет на красивость. Вот здесь ассиметрия.
178. Murad K (karimov_m) 19.12.17 19:50 Сейчас в теме
(174)Нда.. понятно.
На этом закроем наш диалог)

ЗЫ почитайте проОдносторонние функции, чтоли..
162. Вадим Мориков (vadim1011985) 45 19.12.17 18:32 Сейчас в теме
(159) КлючНачальный содержит хеш предыдущего блока так что с этим все впорядке

а в bitcoin как работает доказательство работы - Вычислением хеша ?
164. Артём Андриянов (CSiER) 15 19.12.17 18:36 Сейчас в теме
(164) Да, да. И двойной хеш. Я сделал одинарный для наглядности.
(162) Ровно также, как и в публикации. Ищется хеш с определенным количеством нулей в начале. У меня только шаг сложности большой - 4 бита.
169. Murad K (karimov_m) 19.12.17 18:46 Сейчас в теме
(162) это только для проверки связности цепи, но не проверка POW..
167. Артём Андриянов (CSiER) 15 19.12.17 18:43 Сейчас в теме
(159), а зачем автору POW? У него блокчейн всегда с одним узлом, сами данные блока - документы. ИМХО, можно вообще убрать вычисление красивого хеша - будет цепочка подписанных блоков.
170. Murad K (karimov_m) 19.12.17 18:51 Сейчас в теме
(167) Все так) тот же "блокчейн в кармане" я их называю)
Суть реализации - создание реестра связанных документов, по алгоритму взятия хэша предыдущих данных (документа) для создания хэша текущего обрабатываемого документа.
Без децентарлизованной сети.. можно начать генерить "свою ветку" правильных документов и сказать что эта ветка - правильная и ничего что там везде суммы уменьшены в два раза))
(170) Можно. Но надо будет догнать основную ветку. Вот здесь и сработает POW.
176. Артём Андриянов (CSiER) 15 19.12.17 19:08 Сейчас в теме
(170), да, я именно в этом и увидел интересность статьи, но практическое применение пока туманно )
(167) Для того, чтобы атакующему сложно было догнать.
175. Артём Андриянов (CSiER) 15 19.12.17 19:06 Сейчас в теме
(172), у атакующего трудозатраты такие же, как и у системы. Вот если бы была какая-то алгоритмическая сложность разная или "секрет" - тогда да. Например, в фукнцию вычисления хэша добавить пароль - без знания данного "секрета" злоумышленнику практически нереально подобрать хэш. При этом администратор системы очень быстро может проверить неразрывность блоков. Но все это не работает, пока у злоумышленника есть доступ к системе.
(175) Затраты ресурсов у атакующего не могут быть такими же. Он догоняет.
189. Артём Андриянов (CSiER) 15 20.12.17 03:35 Сейчас в теме
(177), чтобы не дублироваться - посмотрите комментарий 155 - реальный пример, когда злоумышленник по мощности (и времени на выполнение атаки) обгоняет в 2 (!) раза. Приведите пример, где атакующий будет "догонять".
(189) Я уже ответил, но, видимо, недостаточно развернуто. Всякая система учета и контроля основана на проверке первичных документов. Бухгалтерия берет бумажную накладную и проверяет соответствующую запись в базе или сама бухгалтерия вносит запись. В серьезных случаях каждый документ проверяется неоднократно. Этот процесс занимает некоторое время и является элементом неопределенности для атакующего. Точно можно сказать, что если подменить сегодняшний документ сегодня, то это 100% раскроется в течение нескольких дней. Для успешной атаки надо подменять достаточно старые записи.
196. Артём Андриянов (CSiER) 15 20.12.17 11:55 Сейчас в теме
(195), 160 коммент не увидел сразу :(
179. Murad K (karimov_m) 19.12.17 19:53 Сейчас в теме
(175)Вся суть, что тут нет ассиметричного алгоритма на генерацию блока и его проверки. для показать "концепцию" (хотя тут ее нет, т.к. нет децентрализации) SHA256 сойдет, но для реальной работы, конечно же смешно) Генерировать и проверять блоки за одно и тоже время, не ассиметрично.. увольте.
(179) Вы можете скачать обе обработки, запустить на любой базе и убедиться в ассиметричности своими, что называется, глазами.
201. Дмитрий Кинаш (Dementor) 242 20.12.17 20:34 Сейчас в теме
(179) Вы невнимательно посмотрели обработки. При "проверке" генерация SHA256 происходит всего один раз, а при "создании контрольного числа" запускается цикл с использованием инкрементируемого счетчика, выходом из которого будет нахождение "красивого" хеша.
182. Сергей Коцюра (CheBurator) 3411 20.12.17 01:08 Сейчас в теме
... ПолучитьХэшДокумента().. - требуется обеспечивать неизменность реквизитов и реквизитов реквизитов, входящих в документ..? - это сама по себе задача... по уму (?) все что определяет уникальность/ценность документа как объекта желательно должно входить в документ чистыми значениями, а не ссылками для простоыт контроля.. но это - утопия... Клиент попросил чтобы в договоре номер обозначался не "№", а "N" - все, контроль не пройден... включать полное версионирование (?) и при контроле читать именно ту версию которая была на момент создания хеша..?
(182) Я чистые значения и использую. Но лучше всего - и значения и ссылки. Иначе, можно будет создать дубль с таким же значением.
183. Сергей Коцюра (CheBurator) 3411 20.12.17 01:10 Сейчас в теме
Но что хорошо, я хоть на этомпримере, надеюсь, хоть чуть понял что такое блокчейн... надеюсь...
(183) Спасибо. Собственно ради этого и старался.
184. Сергей Коцюра (CheBurator) 3411 20.12.17 01:14 Сейчас в теме
а.. и это..
теряем процедуру расчета хеша документа и контроль накрывается медным тазиком.
надо обеспечивать а) 100% надежность хранения процедуры расчета хеша и 2) обеспечивать при этом ее неизменность
- кто гарантирует что вот эта процедура расчета хеша - легитимная?
(извините, если бред)
(184) Инфостарт дает 100% надежность хранения процедур как расчета, так и контроля. Он же обеспечивает их неизменность. Разве нет?
Оставьте свое сообщение