VotingPower - beatoz/beatoz-go GitHub Wiki

BEATOZ는 합의 알고리즘으로 PBFT(Practical Byzantine Fault Tolerance) 기반의 DPoS(Delegated Proof of Stake) 합의 알고리즘을 채택하고 있다. DPoS 합의 알고리즘의 특성상, 블록체인 네트워크의 합의 과정에 참여하기 위해서는 Validator 자격을 획득해야 하며, 이를 위해 자산(BEATOZ 코인)을 Voting Power (Stake) 로 전환하는 과정이 필요하다. 이 과정을 Bonding 이라하고, 그 반대로 Voting Power 를 전송 가능한 자산으로 전환하는 것을 Unbonding 이라 한다.

BEATOZ 에서 Voting Power 확보 과정으로서 Bonding은 DeFi에서 일반적으로 사용되는 Staking 개념과는 본질적으로 다르다.
DeFi에서의 Staking은 특정 자산을 스마트 컨트랙트에 예치하고 이에 대한 보상(이자)을 받는 형태로서, 그 기반이 되는 블록체인 네트워크의 작동과는 무관한 방식으로 서비스 레이어 수준에서 구현되고 작동된다.
그러나 BEATOZ의 Bonding은 블록체인 네트워크의 합의 과정에 참여하기 위한 핵심적인 과정이다. Bonding된 자산은 단순히 보상을 위한 예치가 아니라, 네트워크의 보안과 안정성, 즉 블록의 생성과 합의 도달을 위해 필수적으로 요구되는 핵심 요소이다. 블록체인 네트워크 참여자는 Bonding을 통해서 Valdiator 가 되기 위해 필요한 Voting Power를 획득 한다. 그리고 Validator 는 블록 제안, 투표 참여의 역할을 수행하게 되는데, 당연히 Validator 가 없다면 블록의 생성 또한 없으며, 트랜잭션 처리 역시 이루어질 수 없음을 의미한다. 즉 블록체인 네트워크의 중지를 의미한다.
이와 같이 블록체인 네트워크 유지에 Validator는 필수적으로 존재해야 하며, 이 Validator가 되기 위한 유일한 방법이 Bonding 이다. (이에 대한 보상은 자산을 예치(잠금상태)한 것에 대한 대가로서의 보상이 아닌 Valdiator 역할 수행에 대한 보상이다.)
따라서, 자산을 잠금 상태로 만들고 그에 대한 보상(이자)를 받게되는 결과적 측면에서 유사하다 볼 수 있지만, 그것의 목적과 역할에 있어서 DeFi의 Staking 과는 본질적으로 다르다.

BEATOZ 상의 자산을 Voting Power 로 전환하는 과정이다.
BEATOZ의 Validator 로서 블록 합의 도달 과정에 직접적으로 참여고자 하는 계정은 TrxPayloadStaking 트랜잭션을 네트워크에 제출한다. 제출된 트랜잭션이 정상적으로 처리되면, 트랜잭션에 명시된 수량 만큼의 자산이 Voting Power로 전환되고, 이로 부터 일정 블록 이후 시점 부터 해당 계정은 Validator 자격을 득하게 된다. Validator가 되면 새로운 블록 제안, 투표를 통한 합의 도달 과정에 직접적으로 참여하게 되는데, 이 과정은 해당 계정의 소유자에 의한 수작업이 아닌, 해당 계정의 Private Key를 임포트하여 Validator에 의하여 실행되는 시스템, BEATOZ 노드에 의해 이루어진다. 즉 Validator는 자신의 Private Key를 임포트하여 네트워크에 연결되는 BEATOZ 노드를 운영해야 하며,

TrxPayloadStaking 트랜잭션 처리와 Voting Power 전환 과정은 다음과 같다.

Block_N

• TrxPayloadStaking 실행.

  BEATOZ의 원장에 해당 계정(sender)의 지분을 증가 시키고, 동시에 해당 수량 만큼 잔액(balance)를 감소 시킨다.

• Validator Set 계산

  앞선 지분 원장은 메모리상에서 업데이트 되었으나 아직 커밋되지 않은 상태이다. 마지막으로 커밋된 것은 이전 블록인 Block_N-1 에서 커밋된 원장이다. 따라서 Block_N-1 에서 커밋된 원장을 기준으로 새로운 Validator Set을 계산 하고, 이를 Consensus Engine 으로 전달 한다. (Voting Power 변경 없음)

• Validator Set 업데이트

  Consensus Engine 은 현재 NextValidatorSet 의 내용으로 다음 블록 Block_N+1에 적용할 Validator Set을 구성한다.
  이 시점에서 NextValidatorSet은 Block_N-2 원장을 기준으로 계산된 Validator Set 이다.
  새로 전달 받은 Validator Set 으로 NextValidatorSet을 설정한다.
  이 시점에서 NextValidatorSet은 Block_N-1 원장을 기준으로 계산된 Validator Set 이다. (아직 TrxPayloadStaking 실행 반영 안된 상태.)

• Block_N 커밋
  앞서 업데이트된 (TrxPayloadStaking 실행이 반영된) 원장을 커밋한다.

Block_N+1

• Validator Set 계산

• 마지막으로 커밋된 Block_N 원장을 기준으로 Validator Set을 계산하고, 그 결과를 Consensus Engine 으로 전달한다. (Voting Power 변경 있음)

• Validator Set 업데이트

  Consensus Engine 은 현재 NextValidatorSet 의 내용으로 다음 블록 Block_N+2에 적용할 Validator Set을 구성한다.
  이 시점에서 NextValidatorSet은 Block_N-1 원장을 기준으로 계산된 Validator Set 이다. (아직 TrxPayloadStaking 실행 반영 안된 상태.)
  새로 전달 받은 Validator Set 으로 NextValidatorSet을 설정한다.
  이 시점에서 NextValidatorSet은 Block_N 원장을 기준으로 계산된 Validator Set 이다. (아직 TrxPayloadStaking 실행 반영.)

• Bkock_N+1 커밋

  Voting Power 변경 없음.

Block_N+2

• Validator Set 계산

  마지막으로 커밋된 Block_N+1 원장을 기준으로 Validator Set을 계산하고, 그 결과를 Consensus Engine 으로 전달한다. (Voting Power 변경 없음)

• Validator Set 업데이트

  Consensus Engine 은 현재 NextValidatorSet 의 내용으로 다음 블록 Block_N+3에 적용할 Validator Set을 구성한다.
  이 시점에서 NextValidatorSet은 Block_N 원장을 기준으로 계산된 Validator Set 이다. (아직 TrxPayloadStaking 실행 반영.)
  새로 전달 받은 Validator Set 으로 NextValidatorSet을 설정한다.
  이 시점에서 NextValidatorSet은 Block_N+1 원장을 기준으로 계산된 Validator Set 이다.

• Bkock_N+2 커밋

  Voting Power 변경 없음.

Block_N+3

Block_N 에서 처리된 TrxPayloadStaking에 의해 변경된 Validator Set 에 의해 생성 및 서명된 최초 블록이다.

Block_N+4

Block_N에서 처리된 TrxPayloadStaking 에 의해 Validator 가된 계정에 대한 보상이 주어진다.

위와 같이 TrxPayloadStaking 트랜잭션의 처리가 이루어짐에 따라, Block_N 에서 Voting Power를 획득한 계정은,

• Block_N+3 에서 부터 Valdiator 자격을 획득하고,
• Block_N+4 에서 부터 보상을 받기 시작한다.

즉, 트랜잭션 처리 부터 보상이 이루어지기 까지 총 4 Bocks 지연이 존재한다. 이는 Unbonding 과정에도 동일하게 적용되어 TrxPayloadUnstaking 트랜잭션 처리와 보상 중지까지 동일한 지연이 존재한다.

Voting Power 를 다시 자산으로 전환하는 과정 이다.

BEATOZ의 Validator 로서의 역할을 그만 하고자 하는 Validator는 TrxPayloadUnstaking 트랜잭션을 네트워크에 제출한다. 이렇게 제출된 트랜잭션은 Bonding 에서 기술한 바와 같은 과정을 거쳐 처리된다. 즉 4 Blocks 지연을 거져 Validator Set 에서 제거된다.

그러나 Voting Power가 다시 전송 가능한 자산으로 전환되기 까지 또 다른 추가적인 지연이 존재한다. 이 때 발생하는 지연 시간은 Governance Parameters의 lazyUnstakingBlocks의 값으로 결정된다.

BEATOZ의 새로운 블록 생성은 Validator 중 Proposer 로 선출된 특정 Validator에 의한 블록 제안으로 시작된다.
Proposer는 현재 시점의 Validator 들 중에서 선출되는데, 이는 모든 노드에서 각자 계산한 선출 결과가 결정론적으로 동일함이 보장되어야 하며, 다음과 같은 알고리즘이 적용된다.

def ProposerSelection(ValidatorSet) :

    for each v in ValidatorSet:
        A(v) += VP(v)

    P = max(A)
    A(P) -= VP

현재 블록 높이에서의 모든 Validator(ValidatorSet)에 대하여, 각자 자신의 Voting Power(VP(v)) 더함 으로서 Valdiator v의 누적 우선 순위(A(v)) 를 업데이트 한다. 이렇게 업데이트된 누적 우선 순위를 기준으로 가장 큰 값을 갖는 Validator v 를 Proposer P로 선출한다. 여기서 선출된 P가 다음 선출과정에서도 연이어 선출되는 것을 막기 위하여 P의 누적 우선 순위는 전체 지분(VP) 만큼 다시 차감된다. (우선 순위가 낮아 진다.)

이와 같은 절차를 통해 모든 노드는 특정 블록 높이에서 동일한 P를 갖게 되며, Validator는 Voting Power(VP(v))가 클수록 더 자주, 더 많이 Proposer에 선출될 수 있다.

제안된 블록에 대한 확정 기준은 현재 Validator 들의 전체 Voting Power 의 2/3 이상의 서명이다. 여기서 주의 할 것은 Validator 수가 아니라 Validator 의 Voting Power 가 기준이라는 것이다.
이는 특정 Validator 가 전체 Voting Power의 2/3 이상을 독점하는 상황이 되면 해당 Validator에 의해 조작된 블록 제안이 가능해지며 이 블록에 대한 컴펌 역시 다른 Validator 들의 역할(서명) 없이 전체 네트워크에 받아들여지도록 할 수 있음을 의미한다.
또한 특정 Validator 가 전체 Voting Power의 1/3 이상을 독점하게 되면 블록 조작은 불가능하지만 블록 생성을 중단 시킬 수 있다.

이러한 이유로 특정 Validator 가 확보할 수 있는 최대 Voting Power 에 대하여 아래와 같은 제한이 적용된다.

• Validator 는 전체 Voting Power 의 1/3 이상의 Voting Power를 가질 수 없다.
• 변경되는 Voting Power 수량은 전체 Voting Power 의 1/3 이상 될 수 없다.
• Validator 는 자신의 전체 Voting Power 에서 일정 비율 이상 위임 받을 수 없다.