Federated byzantine agreement

PBFT (Byzantne Agreement)
우리는 합의 구조는 기존의 PBFT에서 제안하는 방식을 기본으로 한다. PBFT는 이젠 다 아시죠?
GitHub에 다양한 구현체가 존재
Paxos 에서 다양한 phase의 합의 중첩 효과를 검토 하여 적용
위의 합의 구조에서는 전체 노드수가 2f+1 or 3f+1일 때 f개의 오류를 견뎌낼 수 있다.

FBA
두개 이상의 PBFT가 연립하여 Federated 된 구조. 그럼 두 PBFT 간 합의는 어떻게
처리할 것인가?
기본적인 답은 쿼럼 인터섹션 개념 도입하여 해결한다.
PBFT PBFT

Properties of Consensus Protocol
• A consensus protocol provides safety if. . .
- Agreement – All outputs produced have the same value, and
- Validity – The output value equals one of the agents’ inputs
• A consensus protocol provides liveness if. . .
- Termination – Eventually non-faulty agents output a value (No Stuck)
• A consensus protocol provides fault tolerance if. . .
- It can recover the failure of an agent at any point
- Fail-stop protocols handle agent crashes
- Byzantine-fault-tolerant protocols handle arbitrary agent behavior
Theorem (FLP impossibility result)
No deterministic consensus protocol can guarantee all three of safety, liveness, and fault tolerance in an
asynchronous system.

FBA 쿼럼 인터섹션 Health Check
노드 개수가 T개와 T’개의 두개의 쿼럼이 존재한다.
Quorum A의 fault tolerance : T = 2f + 1
Quorum B의 fault tolerance : T’= 2f’+1
Quorum A Quorum B
T T’

FBA 쿼럼 인터섹션 Health Check (depth 2)
노드 개수가 T개와 T’개의 두개의 쿼럼을 전체 합집합 개수 N개로 인터섹션 한다.
Quorum A Quorum B
T T’
N

T-N T’-N
Safety : 두 쿼럼의 교차가 적어도 1개 노드 이상 존재해야 한다.
Liveness : fault를 제외해도 온전한 쿼럼이 존재해야 한다.
쿼럼 교차는 Safety와 Liveness를 모두 만족해야 하므로 같은 기준으로 관리되는
것이 편리하다. 즉, Safety Failure = Liveness Failure
N
Quorum A Quorum B
T T’T+T’-N

T’-NT-N
수식으로 표현하면
Safety : fS = T + T’ - N - 1
Liveness : fL = T - N (for Quorom A)
fL = T’ - N (for Quorum B)
N
Quorum A Quorum B
T T’T+T’-N

Safety와 Liveness의 fault를 같은 수 정의해야 네트워크의 안정성을 체크하기 쉽기
때문에
fS = fL
T+T’-N-1 = N-T (for A) T+T’-N-1= N-T’ (for B)
2T+T’ = 2N +1 (for A) T+2T’ = 2N+1 (for B)
2N = (2T+T’)-1 (for A) 2N = (T+2T’)-1 (for B)
N은 같기 때문에
(2T+T’)-1 = (T+2T’)-1
그래서 T=T’
즉, 두 개의 쿼럼이 같은 fS와 fL을 같기 위해서는 두 쿼럼의 사이즈(T, T’)가 같아야
한다.

앞 조건에 따라
수식으로 표현하면
Safety : fS = 2T - N - 1
Liveness : fL = N - T (for Quorom A, B)
N
N-T T N-T
Quorum A
T
Quorum B
2T-N

만일 fS= fL이라면 T = T’ 이다. 그러면 T의 fault tolerance는 2f+1이다.
T+T’-N-1 = N-T (for A) T+T’-N-1= N-T’ (for B)
2T-N-1 = N-T ( fS= fL , T = T’)
2N = 3T-1
N = (3T-1)/2 (T의 fault tolerance인 2f+1을 T에 대입하면)
N = (3(2f+1)-1)/2 = (6f+2)/2 = 3f+1
그래서 N = 3f+1
즉 fS = fL인 경우 T는 T=2f+1의 fault tolerance를 가진다면
N은 N=3f+1의 fault tolerance(FT)를 가진다. (fS= fL=f)
개개의 쿼럼의 FT가 더 커진다면 쿼럼교차의 FT가 더 낮아진다. (위험함)

모든 쿼럼의 개수가 T이고 3개 쿼럼이 intersection되어 depth가 3인 경우를 정리하면 다음과 같다.
N
N-T T N-T
Quorum A
T
Quorum B
2T-N
T
N-T
Quorum C

Quorom Intersection
Safty와 Liveness를 적절히(?) 제공할 수 있는 형태로 쿼럼을 구성하여 두 쿼럼의 intersection을 만든다.
How? THRESHOLD_PERCENT and the “3f+1 rule” 등등등 기존 SCP에서 제공하는 형태를 분석한 후 적용
예로 두 쿼럼이 intersection을 이룬 2번과 3번에 의해 Txs가 Qa과 Qb 사이에 공유되고 합의됨.
PBFT PBFT1
2
3
4
Qa Qb

Quorom Set (QSet)
각 노드에서 동일한 PBFT 합의 과정을 통해 합의가 연방형 쿼럼들 사이를 전달할 수 있는
SW 구조는 무엇일까?
우선 구현 사항과 관련하여 설정되는 PBFT의 QSet을 어떻게 설정하면될까?
PBFT PBFT1
2
3
4
Qa Qb

Quorom Set (QSet)
설정되는 PBFT의 QSet을 어떻게 설정하면될까?
1 :{ 1, 2, 3 }
4 : { 2, 3, 4 }
그럼 2번과 3번은?
2 { 1,2,3}? 3 {2,3,4}?
PBFT PBFT1
2
3
4
Qa Qb

Quorom Set (QSet) Proposal
설정되는 PBFT의 QSet을 어떻게 설정하면될까?
1 { 1, 2, 3 } Qa
4 { 2, 3, 4 } Qb
2 {1,2,3,4} Qa+b
3 {1,2,3,4} Qa+b
2, 3번이 참여하는 가상 쿼럼인 Qa+b 쿼럼의 PBFT 합의 과정에서 두 쿼럼이 합의됨.
PBFT PBFT1
2
3
4
Qa Qb
2N and 3N 가상
쿼럼 Q(a+b)

결과적으로 Quorum intersection된 노드가 자신이 intersect된 양쪽 노드를 가상 쿼
럼으로 여기고 PBFT 합의에 참여
결과적으로 확장된 쿼럼 구조를 통해 intersected 노드가 PBFT 합의를 이루면
PBFT PBFT1
2
3
4
Qa Qb
가상쿼럼 Q(a+b)

PBFT PBFT1
2
3
4
Qa Qb
가상쿼럼 Q(a+b)1 2 3 4
Tx1
in bc bc
bc in bc bc
bc bc in bc
bc bc in
Tx2
bc bc in
bc bc in bc
bc in bc bc
in bc bc
Tx1
Tx2
in : transaction input
bc : transaction broadcast

Dynamic Quorom
가상 쿼럼을 고정적으로 만드는 형태는 네트워크의 확장에 불리하게 작용할 것으
로 판단함.
1 { 1, 2, 3 } Qa
2 { 1, 2, 3 } Qa
3 { 1, 2, 3 } Qa
Qa에 4 노드가 Qb 쿼럼을 구성하여 연결하고자 하는 경우 4는 { 2, 3, 4 }를 Qset으
PBFT PBFT1
2
3
4
Qa Qb

Dynamic Quorom
각 노드의 설정된 QSet과 다이나믹하게 변하는 ValidateSet(VSet)을 분리하고
VSet을 통해 PBFT 합의를 진행함. VSet이 가상쿼럼이 될 수 있음.
PBFT PBFT1
2
3
4
Qa Qb
PBFT FBA (add Qb)
QSet VSet Qset VSet
1 {1,2,3} {1,2,3} {1,2,3} {1,2,3}
2 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
3 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
4 {2,3,4} {2,3,4}
노드 4가 자신의 QSet을 2, 3번 노드에 전달하여 4번 노드의 QSet을 2, 3번 노드에 전달하여 VSet을 업데
이트함

Dynamic Quorom
각 노드의 설정된 QSet과 다이나믹하게 변하는 ValidateSet(VSet)을 분리하고
VSet을 통해 PBFT 합의를 진행함. VSet이 가상쿼럼이 될 수 있음.
PBFT PBFT1
2
3
4
Qa Qb
PBFT FBA (add Qb)
QSet VSet Qset VSet
1 {1,2,3} {1,2,3} {1,2,3} {1,2,3}
2 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
3 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
4 {2,3,4} {2,3,4}
노드 4가 자신의 QSet을 2, 3번 노드에 전달하여 4번 노드의 QSet을 2, 3번 노드에 전달하여 VSet을 업데
이트함
가상쿼럼 Q(a+b) =
VSet
Q(a+b)

Dynamic Quorom : Update VSet Proposal
1. 4N이 누군가(?)에게 2, 3번 노드 PBKey를 제안 받음
2. 4N이 제안받은 2, 3번 노드에 P2P 연결을 시도
3. 2, 3번이 각각 인증(?)하고 인증
4. 인증 통과 후 4번에게 QSet 요청
5. 2, 3번 QSet 받은 후 VSet 업데이트
PBFT PBFT1
2
3
4
Qa Qb
PBFT FBA (add Qb)
QSet VSet Qset VSet
1 {1,2,3} {1,2,3} {1,2,3} {1,2,3}
2 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
3 {1,2,3} {1,2,3} {1,2,3} {1,2,3,4}
4 {2,3,4} {2,3,4}
PBFT
VSet
Q(a+b)

Dynamic Quorom : 이슈 및 해결
1. QSet은 admin이 설정하는 Quorum Set으로 실제 PBFT합의는 VSet을 기반으로 함.
2. 일반적인 노드의 경우는 QSet은 VSet과 같음.
3. Q-intersect된 노드의 경우는 VSet > QSet 임.
1. 문제점
a. 결과적으로 Q-intersect가 많은 노드의 경우
트래픽 로드가 증가하여 제한 필요
b. 4N에 2N, 3N을 누가 제안하지?
2. 해결방안
a. 부트스트랩 프로토콜
b. 이더리움이나 비트코인의 경우에도 초기 부팅시에
연결을 돕는 Bootstrap 노드가 존재함
c. DDos 공격에도 BOS-Net에 영향이 없어야함.
PBFT PBFT1
2
3
4
Qa Qb
PBFT
VSet
Q(a+b)

Dynamic Quorom : by Bootstrap Node
1. 역활
a. 신규 full 노드 요청 받음
b. 신규 노드(full, light, others)의 최초 연결 시
i. full : 쿼럼 구성 제공
ii. light : 연결 노드 제안
c. 노드 제안을 통한 노드별 트래픽을 분산함.
2. 데이터
a. { NodeID, IP Address,
QSet, VSet Count WaterMark }
3. 방법
a. 노드들은 VSet 개수가 변할 때 마다 B-Node
데이터 업데이트 (트래픽 줄이려면 적극적으로)
b. 신규 노드 요청 시 VSet 개수가 작은 노드를
제안함으로써 네트워크 로드를 분산함.
c. 전체적인 모니터링?
PBFT PBFT1
2
3
4
Qa Qb
PBFT
VSet
Q(a+b)
B

Dynamic Quorom : by Bootstrap Node
추가 고민 사항
1. QSet 제공
a. Bootstrap 노드가 쿼럼을 바로 제공할 것인가?
b. Bootstrap 노드가 Candidate 노드를 제공하고
실제 구성은 노드가 할 것인가?
c. 보안과 관리 측면에서 고민 필요하다.
2. Bootstrap 프로토콜
a. QSet 제공 방법에 따라 구현 필요
PBFT PBFT1
2
3
4
Qa Qb
PBFT
VSet
Q(a+b)
B

Dynamic Quorom : by Contract
1. 컨트랙트 API
a. 신규 노드(full, light, others) 요청 시
i. full : 쿼럼 구성 제공 및 설정
ii. light : 연결 노드 제안
b. 노드 제안을 통한 노드별 트래픽을 분산함.
2. 컨트랙트 데이터
a. 노드 토폴로지 정보
b. { NodeID, IP Address,
QSet, VSet Count WaterMark }
3. 방법
a. 노드들은 VSet 개수가 변할 때 마다 B-Node
데이터 업데이트 (트래픽 줄이려면 적극적으로)
b. 신규 노드 요청 시 VSet 개수가 작은 노드를
제안함으로써 네트워크 로드를 분산함.
PBFT PBFT1
2
3
4
Qa Qb
PBFT
VSet
Q(a+b)

Dynamic Quorom : by Contract
Bootstrap node를 사용하는 방식에 비해 contract를 사용하면 다음과 같은 효과가 있다.
- 모든 노드에서 동작하기 때문에 각 노드로부터의
다양한 성능 측정 가능
- 분산되어 처리되므로 공격포인트가 특정되지 않음
- 투명하게 네트워크 정보가 공개됨
- 각 노드별로 연결 depth를 일정하게 하면
공개되더라도 다양한 공격으로 부터 상대적으로
안전함.
현재는 가장 간단한 형태를 제안하였고
추가로 다양한 형태의 분산 로직 구성 가능할 것으로 보임
PBFT PBFT1
2
3
4
Qa Qb
PBFT
VSet
Q(a+b)

More
- 보안적 측면의 고민 필요
- Openmebership 측면에서 일부 동기화된 상태에서의 consensus가 아닌 다양한 방식에 대한 검토가
필요
- Algorand의 cryptographic lottery 방식에 대한 검토 필요

Federated byzantine agreement

More Related Content

Similar to Federated byzantine agreement

Federated byzantine agreement