У проекта есть несколько слабых мест, которые сводят всю идею на нет.

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

Второе: бинарный формат слишком усложняет всю схему. От логов не требуется структурирования, для этого есть СУБД и специализированные логи (например, лог Apache и postfix имеет жесткую структуру для которой испокон веков есть парсеры). Лог должен быть предельно простым и наглядным. Средства анализа и ведения базы событий - это уже другая тема и для неё должны создаваться отдельные надстройки. В случае kernel.org админ бегло взглянул на лог и аномалия бросилась в глаза, в Journal он бы погряз в обилии информации и её структурирование только бы помешало.

Аутентифицированность отправителя тоже миф - имея root, по прежнему можно притвориться кем угодно.

Про необходимость индексации и быстроты просмотра ерунда, лог просматривается не так часто, чтобы обращать на это внимание.

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