# голосование гозаландия

## intro

1. Первое голосование:
1. атестатор комитета 1 запрашивает gwat и отправляет свои кандидаты *(1,2,3)*
2. атестатор в субсети получает другие кандидаты от других атесторов *(1,2,3 или 1,2,4)*
3. ждет 1/4 слота либо 2/3 голосов атесторов
1. Второе голосование
1. атестатор вычисляет, подписывает и отправляет общую часть, *подписывает (1,2)*
1. Аггрегация комитета
1. агрегатор собирает общую подпись от атесторов *(1,2 1,2,3)*
1. агрегатор ждет 1/4 слота либо 2/3 от второго голосования общей части
1. агрегаторы всех комитетов отправляют пропозеру агрегированные результаты
1. Создание блока
1. пропозер ждет 2/4 времи слота или 2/3 агрегированных голосов от агрегаторов
1. пропозер публикует блок со всеми полученными агрегированными подписями комитетов (1,2, 1,2,3, 1,2,4, 1,2)
1. валидация кандидатов на использовании цепочки *1,2 - 1,2,3- 1,2,3,4*

1. При получении блока нодой дополнительно валидируется голосование кандидатов:
1. Назначенный Пропозер
1. Состав каждого комитета (Агрегатор и Аттестаторы)
1. Данные голосования кандидатов (агрегацию, подписи, ... - по аналогии с с обработкой текущих аттестацией)
1. Подпись блока в целом
1. Если данные не валидны - отбрасываем блок, иначе обновляем стейт в порядке текущей работы, и с учетом соответствующего обновления кандидатов.

1. При наступлении следующего слота Бикон берет (из стейта) агрегированные голоса и вычисляет общую часть по кандидатам, которые передаются в параметр финализации при вызове `dag.Sync`. В ответе `dag.Sync` приходят новые кандидаты, которые будут использованы для очередного рабочего цикла.

> убираем Candidates и Finalization из block.Body.Eth1Data - вычисляем из агрегированных аттестаций. Тут наверное надо еще раз подумать, посмотреть код, поскольку вероятно в стейт попадает Eth1Data.

## Implementation

### CandidatesVoting Pool
Для аттестаций используется два пулла - для неагрегированных и агрегированных.
см. `beacon-chain/operations/attestations/kv/unaggregated.go` и `beacon-chain/operations/attestations/kv/aggregated.go`
Нам наверное тоже нужен дополнительный пулл для сбора голосов Первого Голосования комитета.
Ресетим пул в начале каждого слота.

> TODO проработать

### Реализация субсети
Нам нужна сеть для сбора голосов по Первому Голосованию (для Второго используем уже существующую)
Структура сообщений наверное одинаковая и используем существующую.
Можно сделать после внесения изменений в структуру AttestationData

#### Определить месседж голосования кандидатов в `beacon-chain/p2p/topics.go`
#### Реализовать функционал бродкаста месседжей
по аналогии из `beacon-chain/p2p/broadcaster.go` (например `func (s *Service) BroadcastSyncCommitteeMessage(ctx context.Context, subnet uint64, sMsg *ethpb.SyncCommitteeMessage) error` или `func (s *Service) BroadcastAttestation(ctx context.Context, subnet uint64, att *ethpb.Attestation) error`)
#### Получение и обработка сообщений субсети (Subscription)

##### Beacon side subscription

смотри `beacon-chain/sync/subscriber.go`

// SubscribeToAllSubnets defines a flag to specify whether to subscribe to all possible attestation/sync subnets or not.
SubscribeToAllSubnets = &cli.BoolFlag{
Name: "subscribe-all-subnets",
Usage: "Subscribe to all possible attestation and sync subnets.",
}

используется три типа подписки
1. **subscribe**: subscribe to a given topic with a given validator and subscription handler.The base protobuf message is used to initialize new messages for decoding.
> общая подписка
1. **subscribeStaticWithSubnets**: subscribe to a static subnet with the given topic and index.A given validator and subscription handler is used to handle messages from the subnet. The base protobuf message is used to initialize new messages for decoding.
> Позволяет сделать подписку на все субсети, возможно тестовый режим, активируется цмд-флагом `subscribe-all-subnets`
> ```
> // SubscribeToAllSubnets defines a flag to specify whether to subscribe to all possible attestation/sync subnets or not.
>SubscribeToAllSubnets = &cli.BoolFlag{
> Name: "subscribe-all-subnets",
> Usage: "Subscribe to all possible attestation and sync subnets.",
> }
> ```
1. **subscribeDynamicWithSubnets**: subscribe to a dynamically changing list of subnets. This method expects a fmt compatible string for the topic name and the list of subnets for subscribed topics that should be maintained.
> запуск без флага из пункта выше, т.е. дефолтная подписка.

В случае Гозаландии подписываемся на последних две по примеру аттестации и синкКомитета

`beacon-chain/sync/subscriber.go`

// Register PubSub subscribers
func (s *Service) registerSubscribers(epoch types.Epoch, digest [4]byte) {
    ...
	if flags.Get().SubscribeToAllSubnets {
		s.subscribeStaticWithSubnets(
			p2p.AttestationSubnetTopicFormat,
			s.validateCommitteeIndexBeaconAttestation,   /* validator */
			s.committeeIndexBeaconAttestationSubscriber, /* message handler */
			digest,
		)
	} else {
		s.subscribeDynamicWithSubnets(
			p2p.AttestationSubnetTopicFormat,
			s.validateCommitteeIndexBeaconAttestation,   /* validator */
			s.committeeIndexBeaconAttestationSubscriber, /* message handler */
			digest,
		)
	}
    ...
}

##### Validator side subscription

Кажется тут всего хватает, наверное особых доработак не требуется

// subscribeToSubnets iterates through each validator duty, signs each slot, and asks beacon node
// to eagerly subscribe to subnets so that the aggregator has attestations to aggregate.
func (v *validator) subscribeToSubnets(ctx context.Context, res *ethpb.DutiesResponse) error 

###### вызовы

/home/mezin/go/src/tesseract/validator/client
validator.go
UpdateDuties
		if err := v.subscribeToSubnets(context.Background(), resp); err != nil {
...

Method
UpdateDuties
Usages in All Places
Unclassified
.workspace
/home/mezin/go/src/tesseract/validator/client
runner.go
run
	if err := v.UpdateDuties(ctx, headSlot); err != nil {
			if err := v.UpdateDuties(ctx, slot); err != nil {

### Перестроить тайминги обработки слота валидатора

1. Аттестатор **сразу** получает и отправляет текущее кандидаты (голосование 1)
1. Аттестатор ждет **первую 1/4** слота или количество голосов 1(по которым набирается 2/3 общей части) и отправляем общую часть(кандидаты и чекпоинты) (голосование 2)
1. Агрегатор ждет **вторую 1/4** слота или пока не получит 2/3 голосов 2 и отправляет мультиподпись
1. Пропозер ждет **третью 1/4** слота или 4 мультиподписи и создает блок.
1. **последняя 1/4** слота распространяется блок по сети

В текущей реализации слот разбит на три части, которые определяют выполнение заданной логики валидатором в соответствии с назначенной ролью.

Задаются wait-методами:
`waitOneThirdOrValidBlock` (аттестатор)

func (v *validator) waitOneThirdOrValidBlock(ctx context.Context, slot types.Slot)

`waitToSlotTwoThirds` (агрегатор)

func (v *validator) waitToSlotTwoThirds(ctx context.Context, slot types.Slot)

Вместо этих методов по аналогии реализуем свои методы разбивки слота на четверти в соответствии с нашими таймингами.

##### Добавить валидатору события `voting1Feed` и `voting2Feed`, а также `agregatedFeed` (для пропозера) по аналогии с `blockFeed`
Отправка фида инициируется на Бикон, когда из подсети приходит нужное кол-во голосов.

###### validator feed

type validator struct {
	blockFeed                          *event.Feed
}

###### feed sending
`validator/client/validator.go:320`

func (v *validator) ReceiveBlocks(ctx context.Context, connectionErrorChannel chan<- error)

###### block streeming
`beacon-chain/rpc/prysm/v1alpha1/validator/blocks.go:16`

func (vs *Server) StreamBlocksAltair(req *ethpb.StreamBlocksRequest, stream ethpb.BeaconNodeValidator_StreamBlocksAltairServer) error

##### func (v *validator) attWaitFirstSlotQuarterOr1Voting(ctx context.Context, slot types.Slot)
пункт 2. Аттестатор ждет **первую 1/4** слота или количество голосов 1(по которым набирается 2/3 общей части) и отправляем общую часть(кандидаты и чекпоинты) (голосование 2)

##### func (v *validator) agrWaitSecondSlotQuarterOr2Voting(ctx context.Context, slot types.Slot)
пункт 3. Агрегатор ждет **вторую 1/4** слота или пока не получит 2/3 голосов 2 и отправляет мультиподпись

##### func (v *validator) propWaitThirdSlotQuarterOr1Voting(ctx context.Context, slot types.Slot)
пункт 4. Пропозер ждет **третью 1/4** слота или 4 мультиподписи и создает блок.

### Вычисление ~~назначения 4-х~~ количества комитетов на слот
используем текущий функционал. см. функцию:
`beacon-chain/core/helpers/beacon_committee.go:46`

func SlotCommitteeCount(activeValidatorCount uint64) uint64

Результаты вычислений
| activeValidatorCount | SlotCommitteeCount |
| -------------------- | ------------------ |
| < 256 * 32 | 1 |
| 256 * 32 | 2 |
| 256 * 64 | 4 |
| 256 * 128 | 8 |
| 256 * 256 | 16 |
| 1 000 000 | 64 |

### Назначение комитетов

текущая реализация нам подходит
`beacon-chain/core/helpers/beacon_committee.go:160`

// CommitteeAssignments is a map of validator indices pointing to the appropriate committee
// assignment for the given epoch.
//
// 1. Determine the proposer validator index for each slot.
// 2. Compute all committees.
// 3. Determine the attesting slot for each committee.
// 4. Construct a map of validator indices pointing to the respective committees.
func CommitteeAssignments(
	ctx context.Context,
	state state.BeaconState,
	epoch types.Epoch,
) (map[types.ValidatorIndex]*CommitteeAssignmentContainer, map[types.ValidatorIndex][]types.Slot, error) 

### Назначение криейторов

1. Перепроверить назначение криейторов с учетом нескольких комитетов (брать криейторов только из одного комитета)
2. Переделать(или добавить отдельный метод) с передачей в параметры слота и стейта, что позволит расчитывать криейторов в прошлом для синхронизации (учитывать ресурсозатратность вычислений).

### message AttestationData
1. Добавить поле **candidates**
2. перегенерировать структуры
3. Добавить поле в функционале клонирования (критически важно)
4. Вывод в апи
5. Просмотреть, исправить все использования

Occurrences of 'message AttestationData' in Project
Unclassified
.workspace
/home/mezin/go/src/tesseract/proto/eth/v1
attestation.proto
message AttestationData {
/home/mezin/go/src/tesseract/proto/prysm/v1alpha1
attestation.proto
message AttestationData {

message AttestationData {
    // Attestation data includes information on Casper the Friendly Finality Gadget's votes
    // See: https://arxiv.org/pdf/1710.09437.pdf

    // Slot of the attestation attesting for.
    uint64 slot = 1 [(ethereum.eth.ext.cast_type) = "github.com/prysmaticlabs/eth2-types.Slot"];

    // The committee index that submitted this attestation.
    uint64 index = 2 [(ethereum.eth.ext.cast_type) = "github.com/prysmaticlabs/eth2-types.CommitteeIndex"];

    // 32 byte root of the LMD GHOST block vote.
    bytes beacon_block_root = 3 [(ethereum.eth.ext.ssz_size) = "32"];

    // The most recent justified checkpoint in the beacon state
    Checkpoint source = 4;

    // The checkpoint attempting to be justified for the current epoch and its epoch boundary block
    Checkpoint target = 5;

    // The 32 byte array of hashes presented sequence of the GWAT spines candidates.
    // ssz_max = 32 * 128
    bytes candidates = 6 [(ethereum.eth.ext.ssz_max) = "4096"];
    // ^^^^^^^^^^^^^^^^^^^^^^^^^ add this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}

### Аттестатор (SubmitAttestation)

Реализует основной функционал Аттестатора

`validator/client/attest.go:35`

func (v *validator) SubmitAttestation(ctx context.Context, slot types.Slot, pubKey [fieldparams.BLSPubkeyLength]byte)

###### Первое голосование
1. Получение кандидатов

    data, err := v.validatorClient.GetAttestationData(ctx, req)

Доработать функционал в Биконе
`beacon-chain/rpc/prysm/v1alpha1/validator/attester.go:28`

    func (vs *Server) GetAttestationData(ctx context.Context, req *ethpb.AttestationDataRequest) (*ethpb.AttestationData, error) 

В начале слота происходит вызов dag.Sync который кэширует кандидатов из результата. Реализовать получение закэшированных кандидатов и добавить в AttestationData.
> После реализации этого пункта система должна работать еще на старом консенсусе, блоки должны проходить валидацию в `onBlock`

1. Сформировать и подписать данные (по аналогии с текущей реализацией)
1. Отправка кандидатов в подсеть комитета (см. **Реализация субсети**)
1. Получение кандидатов от Аттестаторов комитета (см. **Реализация субсети** подписка)

1. Ожидание 1/4 слота либо 2/3 голосов атесторов `attWaitFirstSlotQuarterOr1Voting` (см. выше)

###### Второе голосование

1. Получить все голоса и вычислить общую часть
Шлем запрос на Бикон который вычисляет и возвращает общую часть (по аналогии с `GetAttestationData`)
Общая логика расчета кандидатов реализована в методе ниже, но основана на кандидатах, полученных из предшествующих стейтов. Надо реализовать на кандидатах из голосования (получаем из пула)

`beacon-chain/blockchain/spine.go:105`

    func (s *Service) CalculateFinalizationSpinesByBlockRoot(blockRoot [32]byte) (gwatCommon.HashArray, error) 

1. Сформировать и подписать данные (по аналогии с текущей реализацией)
1. Отправить данные в подсеть для аггрегации. Используем текущую реализацию
`validator/client/attest.go:148`

attResp, err := v.validatorClient.ProposeAttestation(ctx, attestation)

### Агрегатор (SubmitAggregateAndProof)

Реализует основной функционал Агрегатора

`validator/client/aggregate.go:27`

// SubmitAggregateAndProof submits the validator's signed slot signature to the beacon node
// via gRPC. Beacon node will verify the slot signature and determine if the validator is also
// an aggregator. If yes, then beacon node will broadcast aggregated signature and
// proof on the validator's behalf.
func (v *validator) SubmitAggregateAndProof(ctx context.Context, slot types.Slot, pubKey [fieldparams.BLSPubkeyLength]byte)

1. Ожидание второй четверти (2/4) слота или пока не получит 2/3 голосов (2 голосование).
Вместо `v.waitToSlotTwoThirds(ctx, slot)` `validator/client/aggregate.go:65` используем нашу `agrWaitSecondSlotQuarterOr2Voting`

1. Получить данные голосования
Данные получаем из Бикона запросом

   	res, err := v.validatorClient.SubmitAggregateSelectionProof(ctx, &ethpb.AggregateSelectionRequest{
		Slot:           slot,
		CommitteeIndex: duty.CommitteeIndex,
		PublicKey:      pubKey[:],
		SlotSignature:  slotSig,
	}) 

1. На Биконе добавить вычисление общей части (должно быть уже реализованно для Аттестатора) в соотв. методе:
`beacon-chain/rpc/prysm/v1alpha1/validator/aggregator.go:22`

    // SubmitAggregateSelectionProof is called by a validator when its assigned to be an aggregator.
    // The aggregator submits the selection proof to obtain the aggregated attestation
    // object to sign over.
    func (vs *Server) SubmitAggregateSelectionProof(ctx context.Context, req *ethpb.AggregateSelectionRequest) (*ethpb.AggregateSelectionResponse, error) 

1. Подпись данных (как есть)
1. Сабмит данных (как есть)

	_, err = v.validatorClient.SubmitSignedAggregateSelectionProof(ctx, &ethpb.SignedAggregateSubmitRequest{
		SignedAggregateAndProof: &ethpb.SignedAggregateAttestationAndProof{
			Message:   res.AggregateAndProof,
			Signature: sig,
		},
	})

### Пропозер (ProposeBlock)

Реализует основной функционал Пропозера

`validator/client/propose.go:41`

// ProposeBlock proposes a new beacon block for a given slot. This method collects the
// previous beacon block, any pending deposits, and ETH1 data from the beacon
// chain node to construct the new block. The new block is then processed with
// the state root computation, and finally signed by the validator before being
// sent back to the beacon node for broadcasting.
func (v *validator) ProposeBlock(ctx context.Context, slot types.Slot, pubKey [fieldparams.BLSPubkeyLength]byte)

1. Пропозер ждет **третью 1/4** слота или 4 мультиподписи `propWaitThirdSlotQuarterOr1Voting`

1. Запускает создание блока. По этому методу кажется больше ничего не надо, основная реализация на стороне Бикона. Инициируется вызовом:

b, err := v.validatorClient.GetBeaconBlock(ctx, &ethpb.BlockRequest{
		Slot:         slot,
		RandaoReveal: randaoReveal,
		Graffiti:     g,
})

#### Beacon side (ProposeBlock)
`beacon-chain/rpc/prysm/v1alpha1/validator/proposer.go:87` - Обработчик запроса валидатора - ничего интересного.
Основная логика реализована тут:
``

// Build data required for creating a new beacon block, so this method can be shared across forks.
func (vs *Server) buildPhase0BlockData(ctx context.Context, req *ethpb.BlockRequest) (*blockData, error) {
    ...
    eth1Data, err := vs.eth1DataMajorityVote(ctx, head)
    ...
    
    deposits, atts, err := vs.packDepositsAndAttestations(ctx, head, eth1Data)
    ...
    return &blockData{
        ParentRoot:        parentRoot,
        Graffiti:          graffiti,
        ProposerIdx:       idx,
        Eth1Data:          eth1Data,
        Deposits:          deposits,
        Attestations:      atts,
        ProposerSlashings: validProposerSlashings,
        AttesterSlashings: validAttSlashings,
        VoluntaryExits:    validExits,
    }, nil
}

func (vs *Server) packAttestations(ctx context.Context, latestState state.BeaconState) ([]*ethpb.Attestation, error) {
	    ...
        atts := vs.AttPool.AggregatedAttestations()
	atts, err := vs.validateAndDeleteAttsInPool(ctx, latestState, atts)
	...
	uAtts, err := vs.AttPool.UnaggregatedAttestations()
        ...
	uAtts, err = vs.validateAndDeleteAttsInPool(ctx, latestState, uAtts)
	...
        atts = append(atts, uAtts...)
        ...
	return atts, nil
}

1. Проверить и выработать решение по "отставшим аттестациям" (uAtts)
1. Внести правки в `packAttestations`
1. В принципе должно работать, но обязательно выполнить ревизию и проверку функционала.

### method __CalcAgrCandidates(ctx, atts []*eth.Attestation)__
С учетом того, что мы планируем исключить Кандидатов и Финализацию из Eth1Data, реализовать вычисление Спайнов из Агрегированных Аттестаций, и в дальнейшем использовать этот функционал. Реализовать в Спайнах `beacon-chain/blockchain/spine.go`.

### method __onBlock__ (Beacon: обработка пропагейт блока)

Распространяемые по сети блоки обрабатываются методом:
`beacon-chain/blockchain/process_block.go:91`

// onBlock is called when a gossip block is received. It runs regular state transition on the block.
// The block's signing root should be computed before calling this method to avoid redundant
// computation in this method and methods it calls into.
// ...
func (s *Service) onBlock(ctx context.Context, signed block.SignedBeaconBlock, blockRoot [32]byte) error

#### Валидация блока

Убираем нашу старую валидацию (возможно она имеет смысл в рамках проверки GWAT на консистентность следующему состоянию сети? Но это уже точно не повод отбрасывать блок)

    if s.CurrentSlot() == signed.Block().Slot() {
// это убираем >>>>>>>>>>>>>>         
        isValidCandidates, err := s.ValidateBlockCandidates(signed.Block())
        if err != nil {
            log.WithError(err).WithField("slotCandidates", isValidCandidates).Warn("could not verify new new block candidates")
        }
        if !isValidCandidates {
            return errBadSpineCandidates
        }
// это убираем ^^^^^^^^^^^^^^
    }

Вместо этого реализуем:
1. Валидация Комитета
- проверяем Аттестаторов
- проверяем Пропозера
1. Проверяем аггрегацию, подписи (тут надо разобраться как это работает)
1. ~~Проверяем консенсус~~ (не надо если Спайны вычисляем из агрегаций)
1. ~~Проверяем вычисление кандидатов~~ (не надо если Спайны вычисляем из агрегаций)

Если все ок - продолжаем обработку, нет - выбрасываем ошибку, прерываем обработку

### Финализация в GWAT

Вычисляем кандидатов из стейта/блока для параметров вызова `dag.Sync`.

`beacon-chain/blockchain/receive_attestation.go:113`

// This routine processes fork choice attestations from the pool to account for validator votes and fork choice.
func (s *Service) spawnProcessAttestationsRoutine(stateFeed *event.Feed) {
...
    for {
        select {
            ...
        case <-st.C():
            if err := s.NewSlot(s.ctx, s.CurrentSlot()); err != nil {}
            ...
        }
    }
...
}

#### Доработка Eth1Data
> по факту откатывается к исходному виду

/home/mezin/go/src/tesseract/proto/eth/v1
beacon_block.proto
message Eth1Data {
/home/mezin/go/src/tesseract/proto/prysm/v1alpha1
beacon_block.proto
message Eth1Data {

Убрать поля Finalization и Сandidates (и соотв. функционал)

    // The 32 byte array of hashes presented sequence of the GWAT spines candidates.
    // ssz_max = 32 * 128
    bytes candidates = 4 [(ethereum.eth.ext.ssz_max) = "4096"];

    //The 32 byte array of hashes presented sequence of the GWAT spines to finalization.
    // ssz_max = 32 * 128
    bytes finalization = 5 [(ethereum.eth.ext.ssz_max) = "4096"];

Результат:

// Eth1Data represents references to the Ethereum 1.x deposit contract.
message Eth1Data {
    // The 32 byte deposit tree root for the last deposit included in this
    // block.
    bytes deposit_root = 1 [(ethereum.eth.ext.ssz_size) = "32"];

    // The total number of deposits included in the beacon chain since genesis
    // including the deposits in this block.
    uint64 deposit_count = 2;

    // The 32 byte block hash of the Ethereum 1.x block considered for deposit
    // inclusion.
    bytes block_hash = 3 [(ethereum.eth.ext.ssz_size) = "32"];
}

Сделать ревизию использования логики.
Например из `beacon-chain/blockchain/spine.go`
в частности излишними будут:

/home/mezin/go/src/tesseract/beacon-chain/rpc/prysm/v1alpha1/validator
proposer_eth1data.go
eth1DataMajorityVote
	finalization := vs.HeadFetcher.GetCacheFinalization()
	finalization := vs.HeadFetcher.GetCacheFinalization()
	finalization := vs.HeadFetcher.GetCacheFinalization()
	finalization := vs.HeadFetcher.GetCacheFinalization()
	finalization := vs.HeadFetcher.GetCacheFinalization()
	finalization := vs.HeadFetcher.GetCacheFinalization()

и аналогичное обновление кандидатов там же.