voidlizard
/
hbs2
mirror of https://github.com/voidlizard/hbs2
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

wip, doc

This commit is contained in:
Dmitry Zuikov 2024-03-16 17:02:27 +03:00
parent 49c2571023
commit 9f8ad486a5
1 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/papers/hbs2-git-doc-0.24.1.tex
View File

@ -129,24 +129,23 @@ broadcast сообщений, DNS бутстрапа и списка извес
прочее, $git~push$ происходит в \term{references}{ссылку}, которая поддерживается всеми пирами,
которые согласны поддерживать эту ссылку.
Узел hbs2-peer может постить \term{transaction}{транзакции} обновления ссылок и получать их, а также
получать журнал транзакций в виде дерева Меркла.
Узел hbs2-peer может отправлять и получать транзакции обновления ссылок, а также получать журнал
транзакций как дерево Меркла.
Как было сказано выше, hbs2-git использует механизм \term{references}{ссылок} для своей работы.
Ссылка представляет собой некий идентификатор, как правило, ассоциированный с публичным ключом
шифрования. Технически это может быть что угодно, что может быть хэшировано, но это что-то
должно быть идентифицировано с тем, кто эту ссылку обновляет, а так же, по возможности должно быть
уникально в рамках вселенной.
Ссылка --- это идентификатор, часто связанный с публичным ключом шифрования, который может быть
любым хешируемым объектом. Она должна однозначно ассоциироваться с обновляющим её пользователем и
быть уникальной.
Одним из способов добиться подобной уникальности --- является использование пары публичный
ключ/приватный ключ и публичного ключа в качестве уникального идентификатора.
Одним из способов добиться уникальности является использование пары публичный
ключ/приватный ключ и публичного ключа в качестве идентификатора.
Владелец приватного ключа очень заинтересован в том, что бы его приватный ключ был уникален и
известен только ему и он изо всех сил старается эту уникальность поддерживать, в частности,
использует качественный генератор случайных чисел и никому свой приватный ключ не сообщает.
Владелец приватного ключа заинтересован в том, что бы его приватный ключ был уникален и известен
только ему и он изо всех сил старается эту уникальность поддерживать, в частности, использует
качественный генератор случайных чисел и никому свой приватный ключ не сообщает.
Так же мы предполагаем, что подобрать секретный ключ по известному публичному ключу --- очень
Мы предполагаем, что подобрать секретный ключ по известному публичному ключу --- очень
сложная задача.
Ссылки могут быть разных типов. Конкретно, hbs2-git использует ссылки двух видов:
@ -154,9 +153,9 @@ broadcast сообщений, DNS бутстрапа и списка извес
\begin{description}
\item[LWWRef] В терминах CRDT это Last~Write~Wins~Register, где некое значение
ассоциировано с монотонно возрастающим счётчиком, и все участники (пиры) принимают
то значение, у которого этот счётчик больше. Так же: lwwref, lww-cсылка.
то значение, у которого этот счётчик больше. См: lwwref, lww-cсылка.
\item[RefLog] В терминах CRDT это G-Set или же Grow~Only~Set транзакций, так же множество
\item[RefLog] В терминах CRDT это G-Set или же Grow~Only~Set транзакций, где множество
транзакций представлено деревом Меркла. Транзакции (в рамках RefLog) упорядочены строго
по их хэшам. Содержимое транзакций может быть произвольно и определяется клиентским приложением.
Наличие порядка, таким образом, приводит к тому, что всё множество может быть адресовано
@ -756,7 +755,7 @@ bdfb845c343eb1da14fe1969219c303c1397980e refs/heads/master
$seed$ содержится в блоке значения ссылки $L_1$.
$PK_2$ также содержится в блоке значения ссылки $L_1$.
$PK_2$ аналогично, содержится в блоке значения ссылки $L_1$.
Таким образом, все имеют доступ к публичному ключу рефлога $PK_2$ и могут проверять подпись автора
для даннго рефлога, и только автор имеет доступ к приватному ключу $SK_2$ и имеет возможность