Блокчейн был придуман почти тридцать лет назад, в 1991 году. Два приятеля, физик и криптограф, Скотт Сторнетта и Стюарт Хабер задумались над тем, как сделать информацию не изменяемой. Нашли решение этой проблемы. Запатентовали решение, открыли компанию с многозначительным названием Surety и даже создали свой, весьма необычный распределенный реестр. Однако, по ряду причин технология блокчейн не получила широкого распространения в то время. И только через 17 лет она стала известна всем. И произошло это в связи с появлением первой криптовалюты Биткоин. С этого момента блокчейн становится «модной» темой. И с этого же момента технологию сопровождают два довольно устойчивых мифа.
Миф первый: блокчейн — это «про деньги». Причем, про очень сомнительные деньги. Что-то типа МММ на современном технологичесом уровне. Это не так. Блокчейн — всего лишь одна из многих технологий, которые используются в криптовалютах. С другой стороны, как бы кому не были интересны и важны криптовалюты, блокчейн является более универсальной (а на мой взгляд еще и фундаментальной) информационной технологией. И, следовательно, имеет большее значение. На рисунке ниже представлено близкое к реальности соотношение двух этих технологий.
Миф второй: блокчейн требует распределенной базы данных. Данные должны храниться параллельно у множества независимых друг от друга хранителей. И чем их больше, тем лучше. А если хранитель будет один, тогда вся технология теряет смысл. Почему это не соотвествует действительности, вы поймете из дальнейшего изложения.
Чтобы понять — как работает блокчейн, требуется сначала познакомиться с хэш-функциями. Исходное слово hash означает «фарш», «мешанина», «крошево». Хэш-функция принимает на входе данные произвольной длины, «крошит», «размешивает» и выдает на выходе битовую строку фиксированной длины. «Машинка» работает очень просто. Загружаете в нее, например:
«В траве сидел кузнечик»
получаете на выходе 256 бит (или 32 байта). Загружаете «Горе от ума», получаете другие 256 бит. Загружаете новый роман Пелевина, получаете третьи 256 бит. Очень удобно. У вас на выходе всегда 256 бит и они всегда разные. Звучит контринтуитивно. Ведь если ужимать большие тексты до 32 «букв», когда-нибудь да возникнет повторение. Это, конечно, справедливо. Но вопрос — когда. Представьте себе, что мы собрали все тексты, когда-либо созданные человеком и решили их пронумеровать. Число, которое у нас получится, вроде бы большое. Но, например, количество атомов в комнате, в которой вы сейчас сидите, тоже большое число. И я рискну предположить, что два этих числа вполне сопоставимы. В биткоине используется хэш-функция, дающая на выходе как раз 256-битовую строку. Насколько большим является 256-битовое число? Если перевести в привычный большинству десятичный вид, то это будет число с 77 нулями. А, например, по некоторым оценкам число атомов во всей наблюдаемой нами вселенной выражается числом с 80 нулями. Так что, может сами оценить вероятность этого «когда». Если вас все-таки смущает само наличие такой вероятности, просто примите во внимание, что компьютеры тоже считают не точно, а приблизительно, но никто не жалуется.
Теперь, после того, как мы разобрались с хэш-функциями, можно сказать, что самое сложное уже позади. Потому что идея блокчейна предельно проста.
Собственно, посмотрев на картинку, можно все понять. Берем данные первого блока, применяем хеш-функцию и получаем ключ(результат). Берем этот ключ, прицепляем к нему данные второго блока, применяем к этому всему хеш-функцию, получаем следующий ключ и т. д. Я выделил на картинке синим пунктиром то место, где происходит «сцепление» двух блоков данных. Само название технологии произошло от этого. Block chain — дословно «цепочка блоков».
У блокчейна одно-единственное, но зато бесценное свойство. Если вы захотите поменять данные где-нибудь в середине цепочки, то вам придется пересчитать все ключи с этого места и до самого конца. Иногда говорят, что блокчейн обеспечивает неизменяемость данных. Это не совсем правильно. В общем случае, блокчейн обеспечивает прозрачность. Любое изменение данных, в каком бы месте цепочки оно не произошло, как легко догадаться, обязательно «всплывет» в конце. Используя это свойство определенным образом, можно действительно добиться неизменяемости один раз введеных данных. Но можно этого и не делать, а ограничаться тем, что у вас есть прозрачность. Откуда берется эта прозрачность. Дело в том, что цепочку блоков очень легко проверить. Первым делом сравниваете начальный ключ текущего блока с конечным ключом предыдущего блока. Они должны совпадать. Потом вычисляете хэш-функцию начального ключа и данных и сравниваете результат с конечным ключом. Вот, собственно и весь алгоритм. Прелесть в том, что программа которая будет выполнять проверку, уложиться буквально в несколько строчек. Ее будет легко понимать и контролировать.
Где можно использовать это свойство. Ответ может показаться неожиданным, но вообще-то в любой базе данных, к которой есть доступ более чем у одного человека. Практически все базы данных так или иначе регистрируют некие события или состояния. И, на сегодняшний день, все они являются машинами времени. Если вы думаете, что я сейчас использовал метафору, то вы глубоко заблуждаетесь. Самая что ни на есть настоящая машина времени находится в распоряжении каждого, у кого есть возможность вносить изменения в какую-либо базу данных. И, как вы понимаете, в этом нет ничего хорошего. Данное свойство баз данных — очевидно вредное и от него надо как-то избавляться. Технология блокчейн как раз и позволяет нам это сделать. Организовав хранение данных в виде цепочки блоков, мы можем строго запретить изменение ранее введеных данных или, если строгий запрет нам по каким-то соображениям не подходит, мы можем обеспечить хронологическую последовательность изменений. Это делается путем регистрации изменения старых данных в конце цепочки. Ниже я расскажу об этом подробнее, а сейчас еще пара слов о том, кому нужен блокчейн.
Уже прямо сейчас эта технология потребуется вам, если вы хотите создать частные деньги. Это — наиболее очевидная и уже проверенная практикой область применения. Частные деньги у нас пока еще не отрегулированны законодательно, но если верить экономической науке, за ними будущее.
Также вам будет крайне необходима эта технология, если у вас есть одна база данных и несколько владельцев. В любой акционерной компании и просто в компании, где есть несколько владельцев, использование блокчейна обеспечит базам данных прозрачность и легкую проверку.
И, наконец, даже в том случае, когда вы являетесь единственным владельцем базы данных и вольны делать с ней все, что вам заблагорассудится, у вас могут быть причины желать сделать свою базу прозрачной и проверяемой. Это касается в первую очередь отношений комиссионеров и комитентов. Особенно актуальным это становится тогда, когда у одного очень большого комиссионера много мелких комитентов.
Я привел три, наиболее очевидных примера. Но, повторюсь, блокчейн имеет смысл использовать в любой базе данных, кроме сугубо личных. Тем более, что сама технология очень проста и не требует особых затрат.
Перейдем к особенностям использования приватного блокчейна в 1С. Не так давно я проводил конкурс на поиск уязвимостей в схеме приватного блокчейна на 1С. https://forum.infostart.ru/forum9/topic222624/ Некоторые из приведенных ниже рекомендаций родились из результатов данного конкурса. Другие — остались неизменными с момента первых публикаций: //infostart.ru/public/717210/ и //infostart.ru/public/728995/
Вот у нас есть какая-то база 1С. На основе типовой конфигурации, переделанная из типовой или полностью оригинальная. Первый вопрос — как подключить блокчейн к этой базе. Надо менять структуру каждого объекта метаданных? И что потом делать, если у нас чисто типовая конфигурация? Ответ — ничего менять не надо. Можно даже вообще не трогать контролируемую базу. Блокчейн может «жить» рядом, в отдельной базе. Вместо самих данных записываем в цепочку блоков ссылки, но хэш-функции при создании цепочки, а также при контроле считаем все же из данных. Получается что-то вроде журнала регистрации изменений. Только в отличие от простых журналов, этот будет защищен от изменений. Такой журнал может размещаться, как я уже сказал, в отдельной базе. И этот вариант является предпочтительным, потому что сводит к минимуму нагрузку на основную базу. У основной базы появляется всего лишь один новый пользователь, который только читает данные. Если все же мы хотим иметь такой журнал в той же базе, тогда следует задействовать механизм расширений.
Далее нам надо определиться с тем, что мы будем считать блоком данных. На первый взгляд, для 1С было бы естесвенным принять за блок данных документ. Но здесь проблема в том, что кроме документов в 1С есть еще и регистры. И в общем случае нет никаких препятствий к тому, чтобы в документе, например, стояло «списание со склада товара Х две штуки», а в регистре «списание со склада товара Y три штуки». Есть три способа решения данной проблемы. Можно рассматривать движения документа как его неотъемлемую часть и включать в блок данных как сам документ, так и его движения по регистрам. Можно вообще перевести фокус с документов на регистры. И считать блоком данных набор записей регистра. У этих двух способов есть определенные недостатки. В первом случае вам потребуется контролировать абсолютно все документы в базе, потому что записи в регистр могут быть внесены любым документом. Это может оказаться неудобным. Особенно для тяжелых типовых конфигураций. Второй способ чуть лучше, но он все еще будет неудобным в том случае, если мы захотим организовать множество отдельных блокчейнов, по одному для каждого нашего контрагента. Тут нам придется разбираться с ситуацией, когда один набор записей регистра относиться сразу к нескольким контрагентам. Поэтому я рекомендую третий способ, который заключается в том, чтобы просто игнорировать существование регистров. Мы изначально ориентируемся на то, что будем контролировать именно документы, а не их интерпретацию. В подавляющем большинстве случаев интерпретация документов очевидна. Поступление товаров увеличивает остаток на складе, списание уменьшает. Здесь вобщем-то нет предмета для споров. В сомнительной ситуации всегда можно задействовать пусть и более медленный, но надежный отчет по документам.
Прежде чем применить хеш-функцию к документу, вам сначала потребуется превратить документ в строку. Выражаясь научно, сериализовать его. И здесь вам потребуется решить, что делать с реквизитами ссылочных типов. Если сериализовать их как ссылки, тогда придется контролировать блокчейном не только документы, но и справочники. Иначе в вашем блокчейне будет уязвимость. Например, можно поменять местами два элемента справочника контрагентов и все документы, связанные с ними, поменяют свой смысл, а блокчейн этого не заметит. Поэтому я рекомендую другой способ. Сериализовать не ссылки, а наименования (или все содержимое элемента, если есть что-то, кроме наименования). Надо только иметь ввиду, что при этом способе редактирование уже существующего элемента справочника приведет к тому, что блокчейн зарегистрирует очень большое количество изменений. Так что потребуется принятие и выполнение достаточно строгой политики в отношении редактирования справочников.
И последний вопрос — что делать с редактированием старых документов. В иделогии 1С такое редактирование рассматривается, как обычное дело. Соотвественно, нам требуется как-то модифицировать схему построения цепочки блоков и ее проверки. Это не очень сложно. Измененные документы будем оставлять в цепочке на их прежнем месте. Данные и хеш-сумма при этом перестанут совпадать. Поэтому, мы пометим такой блок как измененный. Затем создадим новый блок, поместим его в конец цепочки и дадим на него ссылку в старом блоке. Алгоритм проверки усложниться не сильно. Теперь нам надо проверить блок на модифицированность. Для модифицированного блока пройти по ссылке и обработать уже этот новый блок.
Все сказаное выше относится к приватному блокчейну. Т.е. к такому, где есть всего один владелец. Как видите, он работоспособен и несложен в создании. В том числе и на платформе 1С. Задавайте вопросы здесь, а также здесь t.me/privateblockchain1C
И участвуйте в тестировании рабочей модели, которое будет проходить на Инфостарте ориентировочно во второй половине сентября 2024. Участников ждет скромное вознаграждение.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Надеюсь в 8.3.16 блокчейн встроят в конфигурацию как еще один механизм для тех кому нечем заняться, а выглядеть модным положение обязывает.
(1) Подайте заявку в 1С. Не ждите )))
(1) Вот вы смеетесь, а ведь добавят. И вместо «акционеров» — будут контролирующие органы, и если оборотка за конец прошлого периода совпадает с началом этого, а хеш-функция нет, то инспектор вставит руководству и главбуху ключ конечный 256 раз.
(3) Если к тому времени «контролирующие органы» еще будут, то почему-бы и нет.
(4)
Куда же они денутся…
(5) Туда же, куда делись, к примеру, гужевые повозки.
(1) А что именно добавлять то?
Сериализация объекта — есть
Расчёт хэш — есть
Чего не хватает?
(7) Я бы сказал — журнала.
(6) Кстати Игорь Рюрикович погиб при сборе податей еще до изобретения кибитки) Пока налоги берут — будут те кто будут их брать (контролировать) потому что горсть монет взял, горсть монет отдал, а руки — липкие…
(8) Не понял, журнала чего?
(9) В правильном направление мыслите. Липкие руки уже всех достали. И тех, кто отдает, и тех, кто получает. Обе стороны с интересом поглядывают в сторону алгоритмов. У них руки не липкие. У них их вообще нет.
(10) Журнала регистрации, чего еще.
(12) Не понял, в чём сложность писать сейчас в журнал?
Что вы от журнала регистрации ждёте в плане работы блокчейн?
Очень сложно анализировать ваши ответы.
(13) Сейчас никакой сложности. Что хочешь, то и пиши в журнал. А что не хочешь, удаляй. В этом, собственно, и проблема.
Вам сложно анализировать, видимо, потому, что вы не в теме. Задавайте вопросы. Я введу вас в курс дела
(13) Сейчас журнал регистрации не защищен.
(14)1. Зажита журнала это такой же подход к защите информации и вполне решается технически.
2. Я так и не понял, что такое связанное с блокчейном вы собрались фиксировать в журнал регистрации, что оно критично. Мне кажется, что вы придумываете использование его совсем не по назначению?
3. Что значит «А что не хочешь, удаляй»? Есть способ средствами 1С удалить из журнала что-то? Или это у вас банально код имеет файловый доступ — тогда админа на кол?
4. Защищать нужно многие этапы и в комплексе целиком.
5. Я достаточно в теме и именно по этому пытаюсь у вас узнать, чего вам конкретно не хватает и для чего по пунктам. И при этом я читал все ваши статьи.
(16) Вот и прекрасно. Теперь расскажите мне — как вы защитите журнал регистрации. А я вам расскажу, как любой школьник, интересующийся информатикой, вашу защиту сломает.
Удалить что-то из журнала можно средствами SQLite. Как работать с базой SQLite гуглится за 2 минуты.
Журнал регистрации должен быть не изменяем. Причем, никем. Даже пользователем с админскими правами. Для чего, собственно, и нужен блокчейн.
(14)Ну так при централизованном хранении все будет так же. В любой момент можно нажать «восстановить последовательность» и хеши магическим образом пересчитаются. И каждый, кто залезет в журнал после изменения увидит правильную цепочку.
Все вот это вот
работает только тогда, когда цепочка хэшей есть в нескольких экземплярах, её хранители одинаково авторитетны и не могут сговориться. В битке это сделано через сложность пересчета цепочки, в приватном это никто делать не будет — электричество дорого. А в приватном и централизованном хэши пересчитываются опять же
. То есть смысла в блокчейне нету.
(17)И как блокчейн этого добьется? Без распределенного хранения его точно также пересчитают в момент редактирования журнала.
В описанной вами ситуации проверяющий увидит неправильную цепочку. Проверяющий зафиксирует факт пересчёта и будет считать цепочку неправильной.
(20) как жеш он ее увидит, если все пересчитать?
(19) Факт пересчёта невозможно скрыть.
(21) Сравнит последний сохраненный ключ с ключом из пересчитанной цепочки и увидит расхождение.
(6)
Повозки-то делись, а вот люди (в том числе государевы) — остались, просто пересели из гужевых повозок в бензиновые.
Изменилась, как заметил мессир Воланд, «аппаратура», а люди — остались прежними, и отношения между ними остались прежними, просто потому, что природа человека не изменилась за тысячелетия.
Но автор истово верит в
крест животворящийалгоритм всемогущий, который исправит общественные отношения — при неизменной природе человека, ага…Впрочем, фанатикам всегда надо во что-то верить: в слово господне, в марксизм-ленинизм или в блокчейн — без разницы.
Так что спор этот полностью лишен смысла.
(24) Алгоритмы могут успешно заменять людей. Странно, что вы, будучи вероятно специалистом в ИТ-области, этого не понимаете.
(23) а что мешает переписать «последний сохраненный ключ»? тем паче, что переписывается вся цепочка
(25)
Глупости: алгоритмы реализуются людьми, а не сами собой.
А если настанет (не дай бог!) время, когда алгоритмы станут работать без участия людей… тогда что вы будете делать с несовершенными людьми, мешающими работе совершенных алгоритмов? Подсказываю: уничтожать. Или, в лучшем случае, изолировать (в гетто, всех в гетто!).
Не верите? Элементарно: в любой религии прописаны правильные алгоритмы: не лги, не кради, не убивай, люби ближнего и так далее. Напомнить, во что это всегда выливалось и сейчас выливается? Или вы все-таки историю учили в школе?
То, что вы будучи несомненно фанатиком-технократом, этого не понимаете — ничуть не странно, к сожалению.
(26) Никто не знает, где вы его храните.
(27) Алгоритмы создаются людьми, запускаются людьми, действуют в интересах людей и при необходимости останавливаются людьми. В процессе своей работы, они действуют без участия людей. И, в целом, ничего плохого не происходит, только хорошее.
(29)
Я так и думал. Пациент безнадежен, в морг!
(30) Можете сказать что-нибудь по-существу вопроса?
(28)Угу, пришел проверяющий с каким-то левых хешом. Как он вообще докажет, что это «последний сохраненный ключ»?
А если у него есть вся база до момента этого ключа (тогда доказательством валидности будет возможность пересчета ключа с выходом на те же данные) — то и ключ не имеет смысла — есть же база.
В общем, больше безопасности, чем подписанный акт сверки приватный блокчейн дать не может.
(32) Проверяющему ничего доказывать не требуется.
Вся база в общем случае не дает безопасности. Безопасность дает блокчейн.
Вот у вас есть архивная копия и текущая база. И что? Как вы обнаружите изменения?
Проверяющему ничего доказывать не требуется.
Вся база в общем случае не дает безопасности. Безопасность дает блокчейн.
Вот у вас есть архивная копия и текущая база. И что? Как вы обнаружите изменения?
(33) Аналогично: У вас есть последний хэш и он не сходится и что дальше?
(17) Элементарно — виртуальная ФС которая сразу отправляет всё записанное в журнал в хранилище недоступное рядовому админу 1С. Реализовать могу в течении недели.
Или вы запускаете сервер 1С под пользователем доменного администратора?
(35) Вопрос бессмысленный.
Вы провели инвентаризацию на складе и выявили недостачу. Что дальше?
В самом общем случае, если я — проверяющий и я обнаружил подмену цепочки, я просто перестаю доверять владельцу базы.
(36) Вот вам простая аналогия. У организации есть склад (база данных). На складе висит замок. Ключ от замка (админский пароль) есть у кладовщика (админ). По вашему получается, что больше ничего и не нужно.
Но в реальности это не так. Никого такое положение дел не устраивает. На складе регулярно проводят инвентаризацию.
Так вот, блокчейн — это постоянно действующая инвентаризации базы данных
(34) ОСВ на дату, потом карточка счета по изменившимся показателям? Собственно будни админа 1С.
(38) Только в условиях, когда инвентаризацию проводит админ и результаты инвентаризации у него же, то это не даёт никакой дополнительной безопасности по сравнению с полным фото содержимого склада.
И то, «фото» я пишу чтобы приблизится к миру вещей. В информационной реальности фото == складу.
То, о чем вы пишете, как о супердостижении блокчейна — это не блокчейн, а обеспечение аудиторского следа в учетной системе. В SAP он есть бай дезайн, в 1С его нету, а есть перепроведение задним числом.
В итоге — в сапе все без блокчейна работает, а в 1С и блокчейн не спасет. Так как факт изменения без возможности откатить куда надо никому в большинстве случаев не нужен.
Откатить можно при наличии бэкапа, но если есть в надежном месте бэкап, то блокчейн — лишняя сущность. Если же вы контрагент, и решаете «а стоит ли доверять базе партнера» то хэш блокчейна и акт сверки решают задачу одинаково эффективно, только первый «стильно модно молодежно» а второй — уже сто лет как.
(40) Правильно мыслите. Если вы используете блокчейн, то инвентаризацию проводит уже не админ. В этом и смысл.
Акт сверки — это замечательно. А что с чем сверяется вы не задумывались? База одного контрагента с базой другого. Потом выясняется, что есть расхождения. Потом начинается мучительное выяснение — чей сотрудник накосячил. С блокчейном ничего этого не будет. База одна. Проверяй хеши и спи спокойно.
(39) Прекрасно. Я внесу такие изменения в базу, которые ваша ОСВ не заметит и унесу домой чего-нибудь со склада. Ваша система никуда не годится.
(20) и с учетом
»
Миф второй: блокчейн требует распределенной базы данных. Данные должны храниться параллельно у множества независимых друг от друга хранителей. И чем их больше, тем лучше. А если хранитель будет один, тогда вся технология теряет смысл. Почему это не соотвествует действительности, вы поймете из дальнейшего изложения.
»
при одной цепочке констатирует полное отсутствие валидной базы данных.
Или второй миф таки оказался не мифом?
(43) С какого склада?
Если вы умудритесь так подправить базу, что у меня сойдутся баланс и прибыли и убытки и кэшфло, то несите. На эффективности фирмы ваш вынос не отразится.
Только вы максимум будете мусор на утилизацию не весь отправлять, а часть себе отсыпать на дачу и деньги на оплату утилизатора прикарманивать.
(41) И у кого из партнеров эта одна база?
и никаких мучений не будет. В акте сверки список всех операций с момента прошлого акта сверки. В итоге для блокчейна имеем «у нас есть расходждения» для акта сверки «вот эта пара строк отражена по разному, пошли поднимать первичку»
Ну и по поводу «не админ» — все, что делает база автоматически — это делает админ. Так как в 1С он может сделать, что она будет делать это так, как скажет он.
(42) Смотрите. Некто заинтересован в том,чтобы его базе доверяли. Он вкладывается в обеспечение прозрачности своей базы данных и он не станет просто так ломать систему. Отличие распределенного блокчейна от приватного только в том, что в первом случае базу нельзя уничтожить. В случае приватного блокчейна, владелец действительно может уничтожить свою базу данных. Но кто и зачем станет это делать?
(44) Прибыли и убытки у вас тоже на дату? На какую, интересно? На каждую?
При вашей системе нести можно с любого склада и в любом количестве, которое будет не очень заметно.
(40)А если изменения внести напрямую в базу данных, минуя 1С. Ну то есть прямо в таблицу на сервере базы данных некто выполнил изменение и что тогда? Блокчейн это проследит, а вот САП не сможет.
А если еще дать право генерить ключи для блокчейна для учета операций в 1С сразу на сайте налоговой инспекции, и проверять целостность цепочки данных там же, то потом и проверок налоговиками можно будет не проводить выездных. 🙂
(48) Кстати, некоторое время назад продвигалась идея налогового мониторинга. Но как-то, видимо, заглохла, столкнувшись с суровой прозой реализации интерфейса для сотрудников налоговой. Блокчейн — это еще и простой и понятный интерфейс. Вот вам список документов новых, а вот список измененных, а вот еще удаленных. Все просто.
(45) Блокчейн эту админскую вольницу отменяет.
(38) А под складом бункер куда падают (только в одну сторону!) все события происходящие со складом и за этот бункер одмин склада уже не отвечает и повлиять на него не может. Целостность событий попадающих в бункер можно обеспечить стопицот способами включая «блокчейн» и ничего особенного он не предлагает по сравнению с другими.
(37) Супер. А может просто сбой был? Или алгоритм кто-то некорректно соптимизировал или наоборот починили багу и он стал правильно работать.
Вам пытаются донести, что блокчейн:
1. Это обычный инструмент как тысячи других
2. Он не появился недавно, а эта фича всегда использовалась ещё в незапамятные времена.
3. Революция отменяется :о)
(51) В том-то и дело, что других нет. Назовите хоть один.
Какой-то сбой пересчитал всю цепочку? Шутите?
А я вам пытаюсь донести, что:
1. У этого инструмента нет аналогов.
2. Блокчейн стал использоваться в 2008-ом в криптовалюте. Другие области применения еще только появляются прямо сейчас.
3. Считать что-то революцией или нет — это дело вкуса.
(53) на вскидку
1. Банальный вариант запись потока на неперезаписываемый носитель.
2. Потоковый шифрование — это вообще отличный пример «древнего блокчейна»
3. Отправка данных на хранение одновременно в несколько хранилищ
(54) Вы называете блокчейном то, что было изобретено гораздо раньше 2008 года. И никаким волшебством не является
(55) И как это все будет работать в идеологии 1С, где ранее введенные документы могут исправляться?
Вы предлагаете что-то абстрактное. Лишь бы что-нибудь предложить и отстоять любой ценой свою точку зрения.
Попробуйте хотя бы на время переключиться со своей позиции.
(57)
Попробуйте хотя бы на время переключиться со своей позиции.
Ох, Михаил, и не говорите. Очень тяжело с такими персонажами.
(58) На самом деле, эти разговоры небесполезны. Из предыдущей ветки вышло много чего дельного.
(56) Вы ведь читали все мои статьи на эту тему. Я где-нибудь употреблял слово «волшебство»?
(60)»Волшебство» у вас сквозит во всех сообщениях, что вот теперь-то наступит всеобщее счастье.
В частности:
Отсюда напрашивается вывод, что только в 2008 придумали механизм проверки достоверности цепочки данных. Я показал, что это СОВСЕМ не так.
Вы постоянно ссылаетесь на то, что мифические «алгоритмы» теперь смогут заменить ведомства/людей. Но, что мешало это сделать раньше? Может потому что всё упирается не только в достоверность каких-либо данных?
Я вообще не понимаю всего хайпа вокруг блокчейна именно по причине что этому «методу» уже почти под полтинник. Плюс только в том что круговорот денег увеличивается, но вот реальный полезный выхлоп около нуля.
(57) Вы соскочили с темы. Мы обсуждали именно неизменяемость ЖУРНАЛА РЕГИСТРАЦИИ!!!! И то, что для обеспечения этой неизменяемости и ранее (до «изобретения» блокчейна) существовало куча методов. И то, что для реализации неизменяемости журнала совсем не обязательно какой-то отдельной поддержки от платформы 1С.
Каким образом это связано с возможностью изменения документов задним числом?
(61) Ну если у вас возникает такое ощущение, то что ж.. я могу только порадоваться.
Вы предубеждены. Попробуйте на время стереть ваши убеждения и посмотреть на вопрос свежим взглядом.
(62) Прямым ваши методы чисто умозрительны. На практике их пременить невозможно. А некоторые просто смешны. Например, неперезаписываемый носитель.
(64) Что умозрительно?
Хранилища специализированные на потоковое архивирование важной информации?
Использование потокового шифрования невозможно применить на практике?
(65) Ваши неперезаписываемые носители смешны. Что это за носитель такой? Можете назвать конкретно?
(63) В чём свежий взгляд? Объясните в чём заключается изобретение блокчейна в том виде как описываете вы? Чем оно отличается от методов реализации потокового шифрования стандартизованных в древнем 1981 году?
Я прекрасно понимаю как это можно использовать. Я прекрасно понимаю плюсы и ограничения. И про эти методы знал ещё в институтские годы.
(67) Хотя бы тем, что здесь не решается задача передачи шифрованного сообщения. Здесь решается в некотором смысле прямо противоположное. А именно, обеспечение прозрачности.
Вы лучше про неперезаписываемый носитель расскажите. Вместе посмеемся.
(68) Причём тут передача информации? Вы статью которую я привёл про виды потокового шифрования прочитали? Это сугубо вопрос выстроения зависимых друг от друга блоков Block в цепочки Chain, где последующий зависит от предыдущего. Этому способу полста лет в обед и рассказывается в техникумах и на первых курсах универов.
Если вам не нравится именно слово «шифрование» в широком смысле термина, то акцентируйтесь на эцп
Расширьте кругозор :о) И это тоже институскотехникумовский курс о системах хранения данных.
Для примера на вскидку
Такие же системы есть и от других вендоров. Ищите по аббревиатуре WORM
(69) Так называемый блокчейн существует давно и ничего плохого в нём нет. Это просто один из кучи способов достич достоверности данных. Но один он сам по себе без комплекса других мер чистая профанация. Не надо зацикливаться и делать из этого «серебрянную пулю», позволяющкю решить все проблемы (особенно когда и проблемы то нет).
И убедить то я пытаюсь только в этом.
(69) Так. И как эти ваши неперезаписываемые носители решат проблему прозрачности? Можете конкретно описать? Сдается мне, что вы чего-то недопонимаете. Ну или я чего-то недопонимаю )))
(70) Я тоже считаю, что ничего плохого в блокчейне нет. Только хорошее.
А вот насчет кучи способов готов с вами согласиться, только если вы опишите хотя бы один способ из этой ваше кучи.
(71)
Тем, что мы имеем ВСЮ историю изменений.
Недопонимание из-за постоянных перескакиваний с одной темы на другую и, что логично, ответ по одному вопросу становится бессмысленным для другого.
Давайте определимся чего мы хотим добиться в результате:
* Узнать, что данные были тупо изменены?
Да тогда шифрование с использованием CBC и подобных алгоритмов (то что вы в своей статье называли блокчейном) на выходе знать что был изменён какой-то ОДИН первый в цепочке объект. Но что дальше делать с этим знанием?
* Обеспечить достоверность данных?
Тогда нужно хранить все изменения, но это большие накладные расходы
Можно комбинировать эти способы, можно добавить придумать ещё. Но каждый из них не может решить все проблемы или будет неприемлемо дорогим.
(73) Мы хотим чтобы изменения нельзя было спрятать. И я утверждаю, что на сегодняшний день эта задача решается ТОЛЬКО блокчейном.
Если вы считаете, что есть другие решения, тогда опишите их. И я либо покажу вам, где вы ошибаетесь, либо соглашусь с вами, что, да, другие решения существуют.
И, кстати, неперезаписываемые носители не решают вообще ничего. Свойство неперезаписываемости конкретного носителя вам вообще ничего не дает. Подумайте сами. Купите себе ДВА неперезаписываемых компакт-диска. Положите их прямо перед собой. Посидите и помедитируйте над этим. И вы поймете — где ваша ошибка.
(66) Первое, что приходит на ум — CD ROM. Что в нем такого смешного?
(77) Смешно то, что кто-то рассчитывает с помощью этого CD ROM обеспечить неизменяемость данных.
(73) Кстати, хранение всех изменений, не обеспечивает достоверности данных. Подумайте над этим.
Михаил когда уже на Хабре будет пост с предложением 100К за найденную уязвимость? Вы же гарантируете что ваш приватный блокчейн нельзя скомпромитировать.
(82) На Хабре нет таких специалистов, что есть здесь. Как я уже говорил, не вижу смысла проводить конкурс на Хабре. Конкурс на Инфостарте будет в конце этого месяца, ориентировочно.
(84)
Да ладно?
(86) Да ладно.
(87)Считаете их квалификации не достаточно что бы оценить гениальность вашего замысла?
(84)
Конкурс на шутку месяца ты уже выиграл)) Ладно, я же обещал не тратить на твои клоунады время. Надеюсь, каждый несведущий человек, которого каким-то непонятным ветром занесёт в твои
исупражнения в блокчейне, догадается почитать что-нибудь более полезное.(88) Я считаю, что в этом замысле никакой гениальности нет. Все проще пареной репы. Но, как это обычно бывает, проверка конкретной реализации на конкретной платформе (в данном случае на 1С) требует специалистов именно в этой области.
(91)Не совсем понятно при чём тут 1с если обсуждается принцип, база данных может быть любой другой.
Специалистов «именно в этой области» на хабре достаточно и думаю их там даже больше чем специалистов по блокчейну на ИС.
(94) Ближайшее тестирование будет на реальной 1С-овской базе. И проверяться будет уже не принцип, а конкретная реализация.
(5)
Ну так Искусственный Идиот(ИИ) будет все контролировать после того как Крипто-анархия падет и придет великий Михчейн.
(38)Мишаня нету а админа никакого пароля, у тебя ведь в МихЧейне нету ключей ни паролей ничего
(84)
Снова теоретический взлом, теоретического блокчейна за 5 стартмани?
(104) Практический взлом реальной базы.
(107)
За 5 стартмани?
(108) Я думаю — это неплохая сумма. А вы сколько хотите?
(78) 1. У меня подозрение, что вы не знаете как хранится информация физически/битово/блочно ещё до уровня файловой системы.
2. У вас есть подозрение что, что-то имеет физический доступ к устройству и может давать команды приводу? Тогда добавляется комплекс административных мер.
3. Нужно обеспечить достоверность? Для этого есть ЭЦП
И всё вместе это называется КОМПЛЕКС МЕР!
(110)
5 стартмани это тарелка борща. Я ни сколько не хочу. Но то что вы предлагаете только 5 стартмани говорит мне о том что вы сами не верите в вашу систему. Как я могу доверять системе которой сам разработчик не доверяет?
(116) А как можно доверять критериям человека, который нисколько не хочет?
(117)
ad hominem
(118)
De (ех) nihilo nihil
(29)
(120) Как раньше говорилось: «Издержки переходного периода»
Но история прикольная, спасибо!