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

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

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

  1. a la SAP — в базе этого типа транзакция, будучи однажды одобренной, уже не подлежит изменению, изменение старых транзакций оформляется отдельной дополнительной транзакцией
  2. a la 1С — в этой базе старые транзакции могут правиться многократно

Что нам может дать блокчейн в базах первого типа? Как только что говорилось, в этих базах транзакции менять нельзя. Но если у меня есть соотвествующий доступ к базе, то кто мне помешает сделать UPDATE… WHERE ..., да так, что потом никто не найдет?

Создадим свой собственный журнал транзакций, но не простой, а на основе цепочки связанных записей:

  • Ключ начальный
  • Ссылка на транзакцию
  • Хеш транзакции
  • Ключ конечный

Здесь «Ключ конечный» — это хеш двух полей: «Ключ начальный» и «Хеш транзакции», а «Ключ начальный» — это «Ключ конечный» из предыдущей записи. «Ссылка на транзакцию» и «Хеш транзакции», думаю, не нуждаются в пояснениях.

Алгоритм контроля настолько прост, что даже удивительно. Для каждой записи журнала:

  1. Проверяем соответствие начального и конечного ключей
  2. Проверяем соответствие хеша транзакции в журнале и вновь вычисленного хеша транзакции

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

С базами второго типа (a-la 1С) все несколько сложнее, но не так, чтоб уж очень.
Немного расширим наш журнал:

  • Ключ начальный
  • Ссылка на транзакцию
  • Хеш транзакции
  • Ключ конечный
  • Предок
  • Потомок

«Предок» и «Потомок» — ссылки на записи самого журнала, при этом они могут быть пустыми.
А «Ключ конечный» теперь хеш трех полей: «Ключ начальный», «Хеш транзакции» и «Предок».
Соотвественно несколько усложняется алгоритм контроля:

  1. Проверяем соответствие начально и конечного ключей
  2. Проверяем связи предок-потомок, отсутствие циклических ссылок в этих связях
  3. Находим последнего в цепочке предок-потомок и уже только его проверяем на соответствие хешей
  4. Если хеши расходятся, тогда добавляем журнал новую запись с указанием предка.

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

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