Технологию блокчейн, как правило, соотносят с децентрализованными базами данных. Однако, блокчейн сам по себе может быть полезен и в обычной базе.
Возьмем, к примеру, какую-нибудь бухгалтерскую базу. Для наших целей все бухгалтерские базы следует разделить на два типа:
Что нам может дать блокчейн в базах первого типа? Как только что говорилось, в этих базах транзакции менять нельзя. Но если у меня есть соотвествующий доступ к базе, то кто мне помешает сделать UPDATE… WHERE ..., да так, что потом никто не найдет?
Создадим свой собственный журнал транзакций, но не простой, а на основе цепочки связанных записей:
Здесь «Ключ конечный» — это хеш двух полей: «Ключ начальный» и «Хеш транзакции», а «Ключ начальный» — это «Ключ конечный» из предыдущей записи. «Ссылка на транзакцию» и «Хеш транзакции», думаю, не нуждаются в пояснениях.
Алгоритм контроля настолько прост, что даже удивительно. Для каждой записи журнала:
После чего, добавляем в наш журнал, те транзакции, которые в него еще не попали.
Вот, собственно, и все. Теперь уже не важно, какой у меня пароль. Поменять запись в базе незаметно я не смогу. Мне потребуется поменять журнал. А он устроен так, что просто изменить запись в середине нельзя. Надо менять все записи журнала от середины до самого конца. Такая подмена журнала будет гарантированно обнаружена. (Есть несколько простых и надежных способов обнаружить подмену. Некоторые из них дополнительно создают такую ситуацию, что подмену надо будет делать очень быстро, задействуя значительные ресурсы.)
С базами второго типа (a-la 1С) все несколько сложнее, но не так, чтоб уж очень.
Немного расширим наш журнал:
«Предок» и «Потомок» — ссылки на записи самого журнала, при этом они могут быть пустыми.
А «Ключ конечный» теперь хеш трех полей: «Ключ начальный», «Хеш транзакции» и «Предок».
Соотвественно несколько усложняется алгоритм контроля:
Теперь изменение старой транзакции не приводит к исключительной ситуации, а просто добаваляется в конец журнала. При этом мы все равно держим базу под контролем. Изменить что-либо незаметным образом нельзя. Все изменения «всплывают» в конце нашего журнала и там уже достаточно просто контролируются.
Такая нехитрая технология позволит вам контролировать достоверность данных в любой базе.
Возьмем, к примеру, какую-нибудь бухгалтерскую базу. Для наших целей все бухгалтерские базы следует разделить на два типа:
- a la SAP — в базе этого типа транзакция, будучи однажды одобренной, уже не подлежит изменению, изменение старых транзакций оформляется отдельной дополнительной транзакцией
- a la 1С — в этой базе старые транзакции могут правиться многократно
Что нам может дать блокчейн в базах первого типа? Как только что говорилось, в этих базах транзакции менять нельзя. Но если у меня есть соотвествующий доступ к базе, то кто мне помешает сделать UPDATE… WHERE ..., да так, что потом никто не найдет?
Создадим свой собственный журнал транзакций, но не простой, а на основе цепочки связанных записей:
- Ключ начальный
- Ссылка на транзакцию
- Хеш транзакции
- Ключ конечный
Здесь «Ключ конечный» — это хеш двух полей: «Ключ начальный» и «Хеш транзакции», а «Ключ начальный» — это «Ключ конечный» из предыдущей записи. «Ссылка на транзакцию» и «Хеш транзакции», думаю, не нуждаются в пояснениях.
Алгоритм контроля настолько прост, что даже удивительно. Для каждой записи журнала:
- Проверяем соответствие начального и конечного ключей
- Проверяем соответствие хеша транзакции в журнале и вновь вычисленного хеша транзакции
После чего, добавляем в наш журнал, те транзакции, которые в него еще не попали.
Вот, собственно, и все. Теперь уже не важно, какой у меня пароль. Поменять запись в базе незаметно я не смогу. Мне потребуется поменять журнал. А он устроен так, что просто изменить запись в середине нельзя. Надо менять все записи журнала от середины до самого конца. Такая подмена журнала будет гарантированно обнаружена. (Есть несколько простых и надежных способов обнаружить подмену. Некоторые из них дополнительно создают такую ситуацию, что подмену надо будет делать очень быстро, задействуя значительные ресурсы.)
С базами второго типа (a-la 1С) все несколько сложнее, но не так, чтоб уж очень.
Немного расширим наш журнал:
- Ключ начальный
- Ссылка на транзакцию
- Хеш транзакции
- Ключ конечный
- Предок
- Потомок
«Предок» и «Потомок» — ссылки на записи самого журнала, при этом они могут быть пустыми.
А «Ключ конечный» теперь хеш трех полей: «Ключ начальный», «Хеш транзакции» и «Предок».
Соотвественно несколько усложняется алгоритм контроля:
- Проверяем соответствие начально и конечного ключей
- Проверяем связи предок-потомок, отсутствие циклических ссылок в этих связях
- Находим последнего в цепочке предок-потомок и уже только его проверяем на соответствие хешей
- Если хеши расходятся, тогда добавляем журнал новую запись с указанием предка.
Теперь изменение старой транзакции не приводит к исключительной ситуации, а просто добаваляется в конец журнала. При этом мы все равно держим базу под контролем. Изменить что-либо незаметным образом нельзя. Все изменения «всплывают» в конце нашего журнала и там уже достаточно просто контролируются.
Такая нехитрая технология позволит вам контролировать достоверность данных в любой базе.