Приватный блокчейн и 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

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