- Реплика. Когда реплика получает блок от пропоузера, она проверяет полученный блок и принимает или реджектит его. Если блок принят, он добавляется в локальный блокчейн и реплика голосует за него. Голосование происходит следующим образом: реплика определяет следующего пропоузера, подписывает своим ключом хэш хедера принятого блока и посылает дайджест следующему пропоузеру.
message VotePayload {
QuorumCertificate cert = 1; (известный реплике QC с самой большой высотой - самый свежий)
Signature signature = 2;
BlockHeader header = 3;
}
- Пропоузер. Проползем в начале своего раунда собирает подписи подписи предыдущего блока. Собирает он их либо пока не соберет 2f + 1 (две трети плюс 1) штук либо пока не истечет время дельта. Если собрано 2f + 1 голосов, пропоузер аггрегирует подписи и выпускает QC. Затем пропоузер делает новый блок, родителем которого назначает блок из QC и проставляет QC в блок. Таким образом получается следующая конструкция:
message ProposalPayload {
QuorumCertificate cert = 1; (сформированный QC)
Signature signature = 2;
Block block = 3; (внутри блока в хедере тот же сформированный QC)
}
message QuorumCertificate {
BlockHeader header = 1;
SignatureAggregate signatureAggregate = 2;
}
message SignatureAggregate {
bytes bitmap = 1;
bytes signature = 2;
}
Если Не удалось собрать 2f + 1 подписей, то пропоузер все равно выпускает блок, но в него включает самый свежий QC, который ему известен и посылает его всем репликам, включая его в пропоузале.
Сам по себе QC он же Сесиль, нужен для того, чтобы зафиксировать факт того, что блок в нем проверен сильным большинством (две трети плюс один). Это цель номер один. Включаем в блок мы его не только для этого, а еще для того, чтобы организовать некое подобие happens-before. Мы уже говорили, что распределенные системы в общем про синхронизацию времени между нодами, так вот это такой способ синхронизировать время. По QC в блоке (не путать с блоком в QC) мы можем сказать о следующем: блок выпущен после блока на который этот QC выпущен и между ними ровно len_Block - lenQC пропущено. Ситуация когда разница между блоком QC и текущим блоком равна 1 для нас особенно важна о ней дальше.
Это следующая конструкция. Пусть есть блок на высоте к + 1 назовем его b’’ и блок на высоте k назовем b’’’. Тогда если b’’.parent == b’’’ и b’’.QC.block == b’’’ верно, говорят, что b’’ образует one-chain (на самом деле эквивалентно b’’.parent == b’’.QC.block). Напомню что (b.height - b.QC.block.height) === 1
Сделаем шаг индукции. Говорят, что b’ на высоте k + 2 образует two-chain если b’’ образует one-chain и b’.parent == b’’ и b’.QC.block == b’’. Так же b’’.QC (QC на b’’’) называют lockedQC.
А вот тут не индукция! Тут более мягкое условие: пусть есть блок b* на высоте p такой что (p > k + 2) и b*.QC.block == b’, при этом b’ образует two-chain. То что между b* и его QC блоком могут быть дырки в высоте меня и подвело, это баг который я правил эти два дня)
One-chain - мы можем гарантировать, что блок b’’’ проверили, то есть этап пропоузинга пропоузер на высоте k выполнил верно и то, что этот блок верный знают как минимум f+1 честных участников сети (есть QC). К тому же пропоузер на высоте k + 1 честно собирает подписи и выпускает QC, это может быть немного не понятно, но об этом подробнее завтра в контексте атак Two-chain - в этом случае мы можем сказать, про блок b’’’ еще и то, что о том что он верный известно как минимум f + 1 честному участнику сети, так как QC на него видели гарантированно в сети (выпущен QC на блок где содержится QC на b’’’). Именно этот факт нам позволяет считать этот блок locked, и все последующие блоки должны и будут содержать в цепочке своих предшественников этот блок. Также пропоузер на высоте k + 1 еще и проползти честно блоки и пропоузер на высоте k+2 их честно собирает. Three-chain - в этом случае b’’’ считаем закоммиченным.
TBD
Время жизни блокчейна разделено на раунды, раунд это минимальный промежуток времени по истечении которого можно говорить о гарантированном прогрессе. Каждый следующий раунд увеличивает ViewNumber на единицу. Высота создаваемого блока всегда равна номеру текущего раунда.
Во время раунда могут произойти следующие события:
- P собрал 2*f + 1 голос и отправил остальным пирам новый блок со сформированным из голосов QC
- P не смог собрать голоса за ∆ и отправил остальным пирам новый блок и самый старший QC известный ему
- P не смог собрать голоса и не смог отправить блок, раунд длится 2*∆ и P переходит к следующему раунда
- Р если это последний раунд в эпохе Р переходит к старту новой эпохи
- R ждет ∆ нового блока, когда получает его принимает решение голосовать или нет
Блокчейн растет за счет последовательного увеличения своей длинны в процессе proposing(аналогично майнингу) новых блоков.
- В Hello сообщении будет содержаться высота текущего блока у других пиров, мы пытаемся синхронизироваться до этой высоты и скачатьизвестные блоки. После синхрониизации высота блокчейна + 1 совпадает с текущим вью
- Когда мы в качестве репликии получаем валидный Proposal, валидным мы считаем Proposal полученный от текущего proposer
- Когда мы в качестве текущего proposer делаем Proposal
- Когда мы добавляем пустой блок и переходим к следующему вью по таймауту
- Когда мы синхронизируемся по StartEpoch и заполняем пропущенные блоки пустыми
Высота блокчейна никогда не отличается от текущего номера вью больше че на единицу . --- это верно???
- Proposer послал нам блок отличный от блоков других участников, тогда
| Before | Vote | Adversary P | Vote | Proposer P |
|---|---|---|---|---|
| B'(B) | B' | B''(B') | B'' | B'''(B'') |
| B'(B) | B' | A(B') | A | B'''(B'') |
У второго пира будет форк B - B' - A B - B' - B'' - B''', даже если второй и последующий Proposer окажутся злоумышленниками, в худшем случае они смогут растить форки на блоке B' подобные А, очевидно, что они не соберут QC для своего блока и второй пир рано или поздно узнает новый QC Более того, в этом случае у нас будет доказательство мошенничества в виде блока B'' из соответствующего QC и блока A из proposal
- Adversary может не послать блок и тогда он либо не достигнет прогресса и мы получим новый блок на этой высоте от нового Proposer, в случае если он не собрал QC, что аналогично первому случаю для пииров который получили Proposal. Либо Proposer соберет нужное количество воутов и соберет QС, который мы получим в новом блоке, что аналогично проблеме в сети.
Proofs of equivocation (PoE) не являются частью протокола консенсуса, а будут перенесен на следующий уровень, в протокол который будет реализовывать финансовый уровень Таким образом PoE будут специальными транзакцииями, по типу майнинговых, где penalty будет переводиться нашедшему нарушение пропоузеру. Комиссию при этом будет платить пропоузер, который включил poe в блок. В случае невалидного poe комиссия будет просто списваться с нашедшего без зачисления ему награды
Vote
- Голосование за несколько блоков на одной высоте одному пропозеру (легкий пруф)
- Голосование за несколько блоков на одной высоте разным пропоузерам (такого не может быть) (легкий пруф)
- Голосование за блок, который не экстендит PREF() (форки) (легкий пруф прекоммит серт у всех один)
- Голосование за невалидный блок (легкий пруф)
- Голосование другому пропозеру (вряли нарушение)
- Не проголосовать ни за что (Withheld предыдущий пропозер мог не прислать пропозал никому, что не возможно доказать)
Proposal
- Пропозал блока который не экстендит PREF() (легкий пруф прекоммит серт у всех один)
- пропозал не на своей высоте (легкий пруф)
- пропозал не всем (Withheld не доказуемо, здесь можно поиграть с экономической мотивацией)
- пропозал невалидного блока (легкий пруф)
- Пропозал разных блоков разным пирам (форки если прогресс есть, то кто-то увидит блок за который он голосовал в отказаном форке и у него будет доказательство вины пропозера)
QC
- Невалидный QC (легкий пруф)
- QC на изъятый блок -- не возможно, этот блок видели как минимум f + 1 честных пиров
- QC лежит на другом форке (легкий пруф) StartEpoch неверная подпись сообщения неверная высота
Withheld самое сложное доказать withheld, очевидное решение это давать награду за воут, которая будет превышать награду за ложный донос, но тут можно не учесть все факторы и выгода от ложного доноса может перевесить выгоду от голосования.
-Eclipse attack. Proposal withheld направленный, который не останавливает прогресс основной части сети Злоумышленники могут действовать в сговоре и заставить конкретного пира отстать от основной сети и пропустить свою очередь делать proposal или экстендить не PREF() форк. Первое возможно, если злоумышленники не посылаюст proposals намеренно, второе возможно, если когда злоумышленники заставляют жертву делать пропозал без части блоков (онии их изъяли), в таком случае жертва заполняет пробелы пустыми блоками, расщиряя неосновную ветку В общем случае мы не можем наказывать за пропуск своей очереди для пропозинга, это проблема