hbs2/docs/papers/hbs2-browser/design.tex

63 lines
2.7 KiB
TeX
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

% vim: set textwidth=70:
\chapter{Дизайн}
Итак, \term{hbs2-browser}{hb2-browser} это компонент, который позволяет
просматривать некие метаданные, сохраненные в \term{ref}{ссылках}, видимо,
типа \term{refchan}{рефчан}.
Почему refchan:
\begin{enumerate}
\item Требуется несколько авторов, т.е агентов,
которые будут публиковать данные;
\item Требуется при этом исключить компрометацию всей
системы при компрометации какого-то одного приватного ключа <<автора>>;
\item Требуется возможность валидации;
\item Требуется проверка ACL;
\item Требуется включение/исключение авторов.
\end{enumerate}
\section{Стейт}
Исходя из требований, введём стейт как рефчан блоков транзакций, где каждая транзакция содержит
ссылку на блок, а каждый блок является \term{sstable}{sstable}, т.е индексированным, однократно
записываемым отсортированным множеством пар \texttt{(ключ, значение)}.
Такой формат гарантирует нам, что одинаковая кодовая база (в плане настроек LSM и соглашений) будет
порождать идентичные блоки.
В тоже время --- каждая отдельная <<транзакция>>, то есть <<факт>> -- не будет порождать отдельного
адресуемого объекта, таким образом, будут снижены все связанные с этим накладные расходы.
При этом мы можем относительно быстро находить блок и проверять его наличие в прочих сегментах.
% \section{Структуры данных и протоколы}
% \subsection*{Предпосылки}
% \subsection*{Возможное византийское поведение узлов}
% \begin{description}
% \end{description}
% \subsubsection*{Сообщение фактически неверных данных}
% \subsubsection*{Флуд}
% \section{Стейт}
% Дизайн стейта строится из следующих предпосылок:
% \paragraph{Жопа}
% \paragraph{Кита}
% \paragraph{Печень}
% \paragraph{Трески}