Приватный блокчейн и 1С популярно


Две предыдущие публикации на эту тему были сфокусированы преимущественно на технической стороне вопроса. Кроме того, их содержание оказалось понятным не каждому специалисту. В этой статье я постараюсь обяснить для всех и, что говорится, «на пальцах»: что такое приватный блокчейн, когда и зачем его следует применять и на что обратить внимание при использовании этой технологии в 1С.

Блокчейн был придуман почти тридцать лет назад, в 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. Участников ждет скромное вознаграждение.

99 Comments

  1. VmvLer

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

    Reply
  2. mkalimulin

    (1) Подайте заявку в 1С. Не ждите )))

    Reply
  3. FesenkoA

    (1) Вот вы смеетесь, а ведь добавят. И вместо «акционеров» — будут контролирующие органы, и если оборотка за конец прошлого периода совпадает с началом этого, а хеш-функция нет, то инспектор вставит руководству и главбуху ключ конечный 256 раз.

    Reply
  4. mkalimulin

    (3) Если к тому времени «контролирующие органы» еще будут, то почему-бы и нет.

    Reply
  5. TODD22

    (4)

    Если к тому времени «контролирующие органы» еще будут

    Куда же они денутся…

    Reply
  6. mkalimulin

    (5) Туда же, куда делись, к примеру, гужевые повозки.

    Reply
  7. A_Max

    (1) А что именно добавлять то?

    Сериализация объекта — есть

    Расчёт хэш — есть

    Чего не хватает?

    Reply
  8. mkalimulin

    (7) Я бы сказал — журнала.

    Reply
  9. FesenkoA

    (6) Кстати Игорь Рюрикович погиб при сборе податей еще до изобретения кибитки) Пока налоги берут — будут те кто будут их брать (контролировать) потому что горсть монет взял, горсть монет отдал, а руки — липкие…

    Reply
  10. A_Max

    (8) Не понял, журнала чего?

    Reply
  11. mkalimulin

    (9) В правильном направление мыслите. Липкие руки уже всех достали. И тех, кто отдает, и тех, кто получает. Обе стороны с интересом поглядывают в сторону алгоритмов. У них руки не липкие. У них их вообще нет.

    Reply
  12. mkalimulin

    (10) Журнала регистрации, чего еще.

    Reply
  13. A_Max

    (12) Не понял, в чём сложность писать сейчас в журнал?

    Что вы от журнала регистрации ждёте в плане работы блокчейн?

    Очень сложно анализировать ваши ответы.

    Reply
  14. mkalimulin

    (13) Сейчас никакой сложности. Что хочешь, то и пиши в журнал. А что не хочешь, удаляй. В этом, собственно, и проблема.

    Вам сложно анализировать, видимо, потому, что вы не в теме. Задавайте вопросы. Я введу вас в курс дела

    Reply
  15. mkalimulin

    (13) Сейчас журнал регистрации не защищен.

    Reply
  16. A_Max

    (14)1. Зажита журнала это такой же подход к защите информации и вполне решается технически.

    2. Я так и не понял, что такое связанное с блокчейном вы собрались фиксировать в журнал регистрации, что оно критично. Мне кажется, что вы придумываете использование его совсем не по назначению?

    3. Что значит «А что не хочешь, удаляй»? Есть способ средствами 1С удалить из журнала что-то? Или это у вас банально код имеет файловый доступ — тогда админа на кол?

    4. Защищать нужно многие этапы и в комплексе целиком.

    5. Я достаточно в теме и именно по этому пытаюсь у вас узнать, чего вам конкретно не хватает и для чего по пунктам. И при этом я читал все ваши статьи.

    Reply
  17. mkalimulin

    (16) Вот и прекрасно. Теперь расскажите мне — как вы защитите журнал регистрации. А я вам расскажу, как любой школьник, интересующийся информатикой, вашу защиту сломает.

    Удалить что-то из журнала можно средствами SQLite. Как работать с базой SQLite гуглится за 2 минуты.

    Журнал регистрации должен быть не изменяем. Причем, никем. Даже пользователем с админскими правами. Для чего, собственно, и нужен блокчейн.

    Reply
  18. Ndochp

    (14)Ну так при централизованном хранении все будет так же. В любой момент можно нажать «восстановить последовательность» и хеши магическим образом пересчитаются. И каждый, кто залезет в журнал после изменения увидит правильную цепочку.

    Все вот это вот

    У блокчейна одно-единственное, но зато бесценное свойство. Если вы захотите поменять данные где-нибудь в середине цепочки, то вам придется пересчитать все ключи с этого места и до самого конца. Иногда говорят, что блокчейн обеспечивает неизменяемость данных. Это не совсем правильно. В общем случае, блокчейн обеспечивает прозрачность. Любое изменение данных, в каком бы месте цепочки оно не произошло, как легко догадаться, обязательно «всплывет» в конце. Используя это свойство определенным образом, можно действительно добиться неизменяемости один раз введеных данных. Но можно этого и не делать, а ограничаться тем, что у вас есть прозрачность. Откуда берется эта прозрачность. Дело в том, что цепочку блоков очень легко проверить. Первым делом сравниваете начальный ключ текущего блока с конечным ключом предыдущего блока. Они должны совпадать. Потом вычисляете хэш-функцию начального ключа и данных и сравниваете результат с конечным ключом. Вот, собственно и весь алгоритм. Прелесть в том, что программа которая будет выполнять проверку, уложиться буквально в несколько строчек. Ее будет легко понимать и контролировать.

    работает только тогда, когда цепочка хэшей есть в нескольких экземплярах, её хранители одинаково авторитетны и не могут сговориться. В битке это сделано через сложность пересчета цепочки, в приватном это никто делать не будет — электричество дорого. А в приватном и централизованном хэши пересчитываются опять же

    буквально в несколько строчек

    . То есть смысла в блокчейне нету.

    Reply
  19. Ndochp

    (17)И как блокчейн этого добьется? Без распределенного хранения его точно также пересчитают в момент редактирования журнала.

    Reply
  20. mkalimulin

    В описанной вами ситуации проверяющий увидит неправильную цепочку. Проверяющий зафиксирует факт пересчёта и будет считать цепочку неправильной.

    Reply
  21. Fox-trot

    (20) как жеш он ее увидит, если все пересчитать?

    Reply
  22. mkalimulin

    (19) Факт пересчёта невозможно скрыть.

    Reply
  23. mkalimulin

    (21) Сравнит последний сохраненный ключ с ключом из пересчитанной цепочки и увидит расхождение.

    Reply
  24. user856012

    (6)

    Туда же, куда делись, к примеру, гужевые повозки.

    Повозки-то делись, а вот люди (в том числе государевы) — остались, просто пересели из гужевых повозок в бензиновые.

    Изменилась, как заметил мессир Воланд, «аппаратура», а люди — остались прежними, и отношения между ними остались прежними, просто потому, что природа человека не изменилась за тысячелетия.

    Но автор истово верит в крест животворящий алгоритм всемогущий, который исправит общественные отношения — при неизменной природе человека, ага…

    Впрочем, фанатикам всегда надо во что-то верить: в слово господне, в марксизм-ленинизм или в блокчейн — без разницы.

    Так что спор этот полностью лишен смысла.

    Reply
  25. mkalimulin

    (24) Алгоритмы могут успешно заменять людей. Странно, что вы, будучи вероятно специалистом в ИТ-области, этого не понимаете.

    Reply
  26. Fox-trot

    (23) а что мешает переписать «последний сохраненный ключ»? тем паче, что переписывается вся цепочка

    Reply
  27. user856012

    (25)

    Алгоритмы могут успешно заменять людей.

    Глупости: алгоритмы реализуются людьми, а не сами собой.

    А если настанет (не дай бог!) время, когда алгоритмы станут работать без участия людей… тогда что вы будете делать с несовершенными людьми, мешающими работе совершенных алгоритмов? Подсказываю: уничтожать. Или, в лучшем случае, изолировать (в гетто, всех в гетто!).

    Не верите? Элементарно: в любой религии прописаны правильные алгоритмы: не лги, не кради, не убивай, люби ближнего и так далее. Напомнить, во что это всегда выливалось и сейчас выливается? Или вы все-таки историю учили в школе?

    Странно, что вы, будучи вероятно специалистом в ИТ-области, этого не понимаете.

    То, что вы будучи несомненно фанатиком-технократом, этого не понимаете — ничуть не странно, к сожалению.

    Reply
  28. mkalimulin

    (26) Никто не знает, где вы его храните.

    Reply
  29. mkalimulin

    (27) Алгоритмы создаются людьми, запускаются людьми, действуют в интересах людей и при необходимости останавливаются людьми. В процессе своей работы, они действуют без участия людей. И, в целом, ничего плохого не происходит, только хорошее.

    Reply
  30. user856012

    (29)

    ничего плохого не происходит, только хорошее

    Я так и думал. Пациент безнадежен, в морг!

    Reply
  31. mkalimulin

    (30) Можете сказать что-нибудь по-существу вопроса?

    Reply
  32. Ndochp

    (28)Угу, пришел проверяющий с каким-то левых хешом. Как он вообще докажет, что это «последний сохраненный ключ»?

    А если у него есть вся база до момента этого ключа (тогда доказательством валидности будет возможность пересчета ключа с выходом на те же данные) — то и ключ не имеет смысла — есть же база.

    В общем, больше безопасности, чем подписанный акт сверки приватный блокчейн дать не может.

    Reply
  33. mkalimulin

    (32) Проверяющему ничего доказывать не требуется.

    Вся база в общем случае не дает безопасности. Безопасность дает блокчейн.

    Вот у вас есть архивная копия и текущая база. И что? Как вы обнаружите изменения?

    Reply
  34. mkalimulin

    Проверяющему ничего доказывать не требуется.

    Вся база в общем случае не дает безопасности. Безопасность дает блокчейн.

    Вот у вас есть архивная копия и текущая база. И что? Как вы обнаружите изменения?

    Reply
  35. A_Max

    (33) Аналогично: У вас есть последний хэш и он не сходится и что дальше?

    Reply
  36. A_Max

    (17) Элементарно — виртуальная ФС которая сразу отправляет всё записанное в журнал в хранилище недоступное рядовому админу 1С. Реализовать могу в течении недели.

    Или вы запускаете сервер 1С под пользователем доменного администратора?

    Reply
  37. mkalimulin

    (35) Вопрос бессмысленный.

    Вы провели инвентаризацию на складе и выявили недостачу. Что дальше?

    В самом общем случае, если я — проверяющий и я обнаружил подмену цепочки, я просто перестаю доверять владельцу базы.

    Reply
  38. mkalimulin

    (36) Вот вам простая аналогия. У организации есть склад (база данных). На складе висит замок. Ключ от замка (админский пароль) есть у кладовщика (админ). По вашему получается, что больше ничего и не нужно.

    Но в реальности это не так. Никого такое положение дел не устраивает. На складе регулярно проводят инвентаризацию.

    Так вот, блокчейн — это постоянно действующая инвентаризации базы данных

    Reply
  39. Ndochp

    (34) ОСВ на дату, потом карточка счета по изменившимся показателям? Собственно будни админа 1С.

    Reply
  40. Ndochp

    (38) Только в условиях, когда инвентаризацию проводит админ и результаты инвентаризации у него же, то это не даёт никакой дополнительной безопасности по сравнению с полным фото содержимого склада.

    И то, «фото» я пишу чтобы приблизится к миру вещей. В информационной реальности фото == складу.

    То, о чем вы пишете, как о супердостижении блокчейна — это не блокчейн, а обеспечение аудиторского следа в учетной системе. В SAP он есть бай дезайн, в 1С его нету, а есть перепроведение задним числом.

    В итоге — в сапе все без блокчейна работает, а в 1С и блокчейн не спасет. Так как факт изменения без возможности откатить куда надо никому в большинстве случаев не нужен.

    Откатить можно при наличии бэкапа, но если есть в надежном месте бэкап, то блокчейн — лишняя сущность. Если же вы контрагент, и решаете «а стоит ли доверять базе партнера» то хэш блокчейна и акт сверки решают задачу одинаково эффективно, только первый «стильно модно молодежно» а второй — уже сто лет как.

    Reply
  41. mkalimulin

    (40) Правильно мыслите. Если вы используете блокчейн, то инвентаризацию проводит уже не админ. В этом и смысл.

    Акт сверки — это замечательно. А что с чем сверяется вы не задумывались? База одного контрагента с базой другого. Потом выясняется, что есть расхождения. Потом начинается мучительное выяснение — чей сотрудник накосячил. С блокчейном ничего этого не будет. База одна. Проверяй хеши и спи спокойно.

    Reply
  42. mkalimulin

    (39) Прекрасно. Я внесу такие изменения в базу, которые ваша ОСВ не заметит и унесу домой чего-нибудь со склада. Ваша система никуда не годится.

    Reply
  43. Ndochp

    (20) и с учетом

    »

    Миф второй: блокчейн требует распределенной базы данных. Данные должны храниться параллельно у множества независимых друг от друга хранителей. И чем их больше, тем лучше. А если хранитель будет один, тогда вся технология теряет смысл. Почему это не соотвествует действительности, вы поймете из дальнейшего изложения.

    »

    при одной цепочке констатирует полное отсутствие валидной базы данных.

    Или второй миф таки оказался не мифом?

    Reply
  44. Ndochp

    (43) С какого склада?

    Если вы умудритесь так подправить базу, что у меня сойдутся баланс и прибыли и убытки и кэшфло, то несите. На эффективности фирмы ваш вынос не отразится.

    Только вы максимум будете мусор на утилизацию не весь отправлять, а часть себе отсыпать на дачу и деньги на оплату утилизатора прикарманивать.

    Reply
  45. Ndochp

    (41) И у кого из партнеров эта одна база?

    и никаких мучений не будет. В акте сверки список всех операций с момента прошлого акта сверки. В итоге для блокчейна имеем «у нас есть расходждения» для акта сверки «вот эта пара строк отражена по разному, пошли поднимать первичку»

    Ну и по поводу «не админ» — все, что делает база автоматически — это делает админ. Так как в 1С он может сделать, что она будет делать это так, как скажет он.

    Reply
  46. mkalimulin

    (42) Смотрите. Некто заинтересован в том,чтобы его базе доверяли. Он вкладывается в обеспечение прозрачности своей базы данных и он не станет просто так ломать систему. Отличие распределенного блокчейна от приватного только в том, что в первом случае базу нельзя уничтожить. В случае приватного блокчейна, владелец действительно может уничтожить свою базу данных. Но кто и зачем станет это делать?

    Reply
  47. mkalimulin

    (44) Прибыли и убытки у вас тоже на дату? На какую, интересно? На каждую?

    При вашей системе нести можно с любого склада и в любом количестве, которое будет не очень заметно.

    Reply
  48. FIGOR

    (40)А если изменения внести напрямую в базу данных, минуя 1С. Ну то есть прямо в таблицу на сервере базы данных некто выполнил изменение и что тогда? Блокчейн это проследит, а вот САП не сможет.

    А если еще дать право генерить ключи для блокчейна для учета операций в 1С сразу на сайте налоговой инспекции, и проверять целостность цепочки данных там же, то потом и проверок налоговиками можно будет не проводить выездных. 🙂

    Reply
  49. mkalimulin

    (48) Кстати, некоторое время назад продвигалась идея налогового мониторинга. Но как-то, видимо, заглохла, столкнувшись с суровой прозой реализации интерфейса для сотрудников налоговой. Блокчейн — это еще и простой и понятный интерфейс. Вот вам список документов новых, а вот список измененных, а вот еще удаленных. Все просто.

    Reply
  50. mkalimulin

    (45) Блокчейн эту админскую вольницу отменяет.

    Reply
  51. A_Max

    (38) А под складом бункер куда падают (только в одну сторону!) все события происходящие со складом и за этот бункер одмин склада уже не отвечает и повлиять на него не может. Целостность событий попадающих в бункер можно обеспечить стопицот способами включая «блокчейн» и ничего особенного он не предлагает по сравнению с другими.

    Reply
  52. A_Max

    (37) Супер. А может просто сбой был? Или алгоритм кто-то некорректно соптимизировал или наоборот починили багу и он стал правильно работать.

    Вам пытаются донести, что блокчейн:

    1. Это обычный инструмент как тысячи других

    2. Он не появился недавно, а эта фича всегда использовалась ещё в незапамятные времена.

    3. Революция отменяется :о)

    Reply
  53. mkalimulin

    (51) В том-то и дело, что других нет. Назовите хоть один.

    Reply
  54. mkalimulin

    Какой-то сбой пересчитал всю цепочку? Шутите?

    А я вам пытаюсь донести, что:

    1. У этого инструмента нет аналогов.

    2. Блокчейн стал использоваться в 2008-ом в криптовалюте. Другие области применения еще только появляются прямо сейчас.

    3. Считать что-то революцией или нет — это дело вкуса.

    Reply
  55. A_Max

    (53) на вскидку

    1. Банальный вариант запись потока на неперезаписываемый носитель.

    2. Потоковый шифрование — это вообще отличный пример «древнего блокчейна» https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

    3. Отправка данных на хранение одновременно в несколько хранилищ

    Reply
  56. A_Max

    (54) Вы называете блокчейном то, что было изобретено гораздо раньше 2008 года. И никаким волшебством не является

    The earliest modes of operation, ECB, CBC, OFB, and CFB (see below for all), date back to 1981 and were specified in FIPS 81, DES Modes of Operation.
    Reply
  57. mkalimulin

    (55) И как это все будет работать в идеологии 1С, где ранее введенные документы могут исправляться?

    Вы предлагаете что-то абстрактное. Лишь бы что-нибудь предложить и отстоять любой ценой свою точку зрения.

    Попробуйте хотя бы на время переключиться со своей позиции.

    Reply
  58. user928779

    (57)

    Лишь бы что-нибудь предложить и отстоять любой ценой свою точку зрения.

    Попробуйте хотя бы на время переключиться со своей позиции.

    Ох, Михаил, и не говорите. Очень тяжело с такими персонажами.

    Reply
  59. mkalimulin

    (58) На самом деле, эти разговоры небесполезны. Из предыдущей ветки вышло много чего дельного.

    Reply
  60. mkalimulin

    (56) Вы ведь читали все мои статьи на эту тему. Я где-нибудь употреблял слово «волшебство»?

    Reply
  61. A_Max

    (60)»Волшебство» у вас сквозит во всех сообщениях, что вот теперь-то наступит всеобщее счастье.

    В частности:

    Блокчейн стал использоваться в 2008-ом в криптовалюте. Другие области применения еще только появляются прямо сейчас.

    Отсюда напрашивается вывод, что только в 2008 придумали механизм проверки достоверности цепочки данных. Я показал, что это СОВСЕМ не так.

    Вы постоянно ссылаетесь на то, что мифические «алгоритмы» теперь смогут заменить ведомства/людей. Но, что мешало это сделать раньше? Может потому что всё упирается не только в достоверность каких-либо данных?

    Я вообще не понимаю всего хайпа вокруг блокчейна именно по причине что этому «методу» уже почти под полтинник. Плюс только в том что круговорот денег увеличивается, но вот реальный полезный выхлоп около нуля.

    Reply
  62. A_Max

    (57) Вы соскочили с темы. Мы обсуждали именно неизменяемость ЖУРНАЛА РЕГИСТРАЦИИ!!!! И то, что для обеспечения этой неизменяемости и ранее (до «изобретения» блокчейна) существовало куча методов. И то, что для реализации неизменяемости журнала совсем не обязательно какой-то отдельной поддержки от платформы 1С.

    Каким образом это связано с возможностью изменения документов задним числом?

    Reply
  63. mkalimulin

    (61) Ну если у вас возникает такое ощущение, то что ж.. я могу только порадоваться.

    Вы предубеждены. Попробуйте на время стереть ваши убеждения и посмотреть на вопрос свежим взглядом.

    Reply
  64. mkalimulin

    (62) Прямым ваши методы чисто умозрительны. На практике их пременить невозможно. А некоторые просто смешны. Например, неперезаписываемый носитель.

    Reply
  65. A_Max

    (64) Что умозрительно?

    Хранилища специализированные на потоковое архивирование важной информации?

    Использование потокового шифрования невозможно применить на практике?

    Reply
  66. mkalimulin

    (65) Ваши неперезаписываемые носители смешны. Что это за носитель такой? Можете назвать конкретно?

    Reply
  67. A_Max

    (63) В чём свежий взгляд? Объясните в чём заключается изобретение блокчейна в том виде как описываете вы? Чем оно отличается от методов реализации потокового шифрования стандартизованных в древнем 1981 году?

    Я прекрасно понимаю как это можно использовать. Я прекрасно понимаю плюсы и ограничения. И про эти методы знал ещё в институтские годы.

    Reply
  68. mkalimulin

    (67) Хотя бы тем, что здесь не решается задача передачи шифрованного сообщения. Здесь решается в некотором смысле прямо противоположное. А именно, обеспечение прозрачности.

    Вы лучше про неперезаписываемый носитель расскажите. Вместе посмеемся.

    Reply
  69. A_Max

    (68) Причём тут передача информации? Вы статью которую я привёл про виды потокового шифрования прочитали? Это сугубо вопрос выстроения зависимых друг от друга блоков Block в цепочки Chain, где последующий зависит от предыдущего. Этому способу полста лет в обед и рассказывается в техникумах и на первых курсах универов.

    Если вам не нравится именно слово «шифрование» в широком смысле термина, то акцентируйтесь на эцп

    Вы лучше про неперезаписываемый носитель расскажите. Вместе посмеемся.

    Расширьте кругозор :о) И это тоже институскотехникумовский курс о системах хранения данных.

    Для примера на вскидку https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/rzam4/rzam4optic­al.htm

    Такие же системы есть и от других вендоров. Ищите по аббревиатуре WORM

    https://www.google.ru/search?ie=UTF-8&hl=ru&q=worm%20storage%20solution

    Reply
  70. A_Max

    (69) Так называемый блокчейн существует давно и ничего плохого в нём нет. Это просто один из кучи способов достич достоверности данных. Но один он сам по себе без комплекса других мер чистая профанация. Не надо зацикливаться и делать из этого «серебрянную пулю», позволяющкю решить все проблемы (особенно когда и проблемы то нет).

    И убедить то я пытаюсь только в этом.

    Reply
  71. mkalimulin

    (69) Так. И как эти ваши неперезаписываемые носители решат проблему прозрачности? Можете конкретно описать? Сдается мне, что вы чего-то недопонимаете. Ну или я чего-то недопонимаю )))

    Reply
  72. mkalimulin

    (70) Я тоже считаю, что ничего плохого в блокчейне нет. Только хорошее.

    А вот насчет кучи способов готов с вами согласиться, только если вы опишите хотя бы один способ из этой ваше кучи.

    Reply
  73. A_Max

    (71)

    И как эти ваши неперезаписываемые носители решат проблему прозрачности?

    Тем, что мы имеем ВСЮ историю изменений.

    Сдается мне, что вы чего-то недопонимаете. Ну или я чего-то недопонимаю )))

    Недопонимание из-за постоянных перескакиваний с одной темы на другую и, что логично, ответ по одному вопросу становится бессмысленным для другого.

    Давайте определимся чего мы хотим добиться в результате:

    * Узнать, что данные были тупо изменены?

    Да тогда шифрование с использованием CBC и подобных алгоритмов (то что вы в своей статье называли блокчейном) на выходе знать что был изменён какой-то ОДИН первый в цепочке объект. Но что дальше делать с этим знанием?

    * Обеспечить достоверность данных?

    Тогда нужно хранить все изменения, но это большие накладные расходы

    Можно комбинировать эти способы, можно добавить придумать ещё. Но каждый из них не может решить все проблемы или будет неприемлемо дорогим.

    Reply
  74. mkalimulin

    (73) Мы хотим чтобы изменения нельзя было спрятать. И я утверждаю, что на сегодняшний день эта задача решается ТОЛЬКО блокчейном.

    Если вы считаете, что есть другие решения, тогда опишите их. И я либо покажу вам, где вы ошибаетесь, либо соглашусь с вами, что, да, другие решения существуют.

    И, кстати, неперезаписываемые носители не решают вообще ничего. Свойство неперезаписываемости конкретного носителя вам вообще ничего не дает. Подумайте сами. Купите себе ДВА неперезаписываемых компакт-диска. Положите их прямо перед собой. Посидите и помедитируйте над этим. И вы поймете — где ваша ошибка.

    Reply
  75. plevakin

    (66) Первое, что приходит на ум — CD ROM. Что в нем такого смешного?

    Reply
  76. mkalimulin

    (77) Смешно то, что кто-то рассчитывает с помощью этого CD ROM обеспечить неизменяемость данных.

    Reply
  77. mkalimulin

    (73) Кстати, хранение всех изменений, не обеспечивает достоверности данных. Подумайте над этим.

    Reply
  78. TODD22

    Михаил когда уже на Хабре будет пост с предложением 100К за найденную уязвимость? Вы же гарантируете что ваш приватный блокчейн нельзя скомпромитировать.

    Reply
  79. mkalimulin

    (82) На Хабре нет таких специалистов, что есть здесь. Как я уже говорил, не вижу смысла проводить конкурс на Хабре. Конкурс на Инфостарте будет в конце этого месяца, ориентировочно.

    Reply
  80. TODD22

    (84)

    На Хабре нет таких специалистов, что есть здесь.

    Да ладно?

    Reply
  81. mkalimulin

    (86) Да ладно.

    Reply
  82. TODD22

    (87)Считаете их квалификации не достаточно что бы оценить гениальность вашего замысла?

    Reply
  83. for_sale

    (84)

    На Хабре нет таких специалистов, что есть здесь.

    Конкурс на шутку месяца ты уже выиграл)) Ладно, я же обещал не тратить на твои клоунады время. Надеюсь, каждый несведущий человек, которого каким-то непонятным ветром занесёт в твои исупражнения в блокчейне, догадается почитать что-нибудь более полезное.

    Reply
  84. mkalimulin

    (88) Я считаю, что в этом замысле никакой гениальности нет. Все проще пареной репы. Но, как это обычно бывает, проверка конкретной реализации на конкретной платформе (в данном случае на 1С) требует специалистов именно в этой области.

    Reply
  85. TODD22

    (91)Не совсем понятно при чём тут 1с если обсуждается принцип, база данных может быть любой другой.

    Специалистов «именно в этой области» на хабре достаточно и думаю их там даже больше чем специалистов по блокчейну на ИС.

    Reply
  86. mkalimulin

    (94) Ближайшее тестирование будет на реальной 1С-овской базе. И проверяться будет уже не принцип, а конкретная реализация.

    Reply
  87. ogidni

    (5)

    Куда же они денутся…

    Ну так Искусственный Идиот(ИИ) будет все контролировать после того как Крипто-анархия падет и придет великий Михчейн.

    Reply
  88. ogidni

    (38)Мишаня нету а админа никакого пароля, у тебя ведь в МихЧейне нету ключей ни паролей ничего

    Reply
  89. TODD22

    (84)

    Конкурс на Инфостарте будет в конце этого месяца, ориентировочно.

    Снова теоретический взлом, теоретического блокчейна за 5 стартмани?

    Reply
  90. mkalimulin

    (104) Практический взлом реальной базы.

    Reply
  91. TODD22

    (107)

    Практический взлом реальной базы.

    За 5 стартмани?

    Reply
  92. mkalimulin

    (108) Я думаю — это неплохая сумма. А вы сколько хотите?

    Reply
  93. A_Max

    (78) 1. У меня подозрение, что вы не знаете как хранится информация физически/битово/блочно ещё до уровня файловой системы.

    2. У вас есть подозрение что, что-то имеет физический доступ к устройству и может давать команды приводу? Тогда добавляется комплекс административных мер.

    3. Нужно обеспечить достоверность? Для этого есть ЭЦП

    И всё вместе это называется КОМПЛЕКС МЕР!

    Reply
  94. TODD22

    (110)

    Я думаю — это неплохая сумма. А вы сколько хотите?

    5 стартмани это тарелка борща. Я ни сколько не хочу. Но то что вы предлагаете только 5 стартмани говорит мне о том что вы сами не верите в вашу систему. Как я могу доверять системе которой сам разработчик не доверяет?

    Reply
  95. mkalimulin

    (116) А как можно доверять критериям человека, который нисколько не хочет?

    Reply
  96. TODD22

    (117)

    А как можно доверять критериям человека, который нисколько не хочет?

    ad hominem

    Reply
  97. ogidni

    (118)

    ad hominem

    De (ех) nihilo nihil

    Reply
  98. slimper

    (29)

    Алгоритмы создаются людьми, запускаются людьми, действуют в интересах людей и при необходимости останавливаются людьми. В процессе своей работы, они действуют без участия людей. И, в целом, ничего плохого не происходит, только хорошее.

    Восстание машин началось. Google Play

    Reply
  99. mkalimulin

    (120) Как раньше говорилось: «Издержки переходного периода»

    Но история прикольная, спасибо!

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *