아이콘, LFT2 합의 알고리즘

링크: https://medium.com/helloiconworld/lft2-consensus-algorithm-5ee4322b2fd4

 

 

* 오역과 의역이 있을 수 있으며, 댓글로 알려주시면 감사하겠습니다.

 

 

 

 

간단히 말해서

 

LFT2는 PBFT 합의 모델에 기반을 두고 있으며, 메시지를 2단계 합의 프로세스에 완료하는 독점 알고리즘을 가지고 있습니다.

이것은 PBFT의 3단계 합의 프로세스의 통신 오버헤드와 복잡성을 완화시켜 좀더 가벼우면서, 성능은 뛰어난 블록체인 합의 알고리즘이 됩니다. 또한, LFT2는 부분적으로 동기화된 네트워크에서 제기될 수 있는 잠재적인 보안 문제를 해결하기 위해 후보/커밋 블록 메커니즘을 통합함으로써, 단순화된 체계에서도 안전과 내구성을 보장합니다.

간단히 말해서, LFT2는 네트워크 지연시간, 블록확인 및 트랜잭션 처리에서 복잡함을 줄임으로써 성능은 향상되고 동일한 이점을 누리게 되는 혁신적인 PBFT 구현이다.
LFT2는 최근 한국의 대표적인 연구 대학 중 하나인 카이스트(KAIST)로부터 감사가 진행되고 있습니다. [4월 9일 오후 5시 PST에서 발표될 감사 보고서 - 후속 조치 링크].

자세한 내용은 [LFT2 백서]를 참조해주세요.

LFT2 백서: https://github.com/icon-project/LFT2/blob/master/Whitepaper%20-%20LFT2%20(ENG).pdf

 

 

 

다양한 PBFT

 

PBFT는 실제로 응용하기 위해 설계된 학술적 프로토타입으로 간주될 수 있지만 알고리즘을 실제 소프트웨어로 구현하기 위해서는 몇 가지 주요 최적화가 필요합니다. 널리 사용되는 제품으로는 텐더민트(Tendermint)가 있으며, 이 제품들은 본격적인 PBFT 시스템을 만들기 위해 여러가지 주요 설계 결정에 중점을 둡니다.

PBFT 시스템. 예를 들어 View-Change 단계를 제거하여, 추가적인 프로세스 및 가십 프로토콜 없이 잘못된 리더 교체가 가능하게 해서, 시스템 크기에 의존하지 않는 일정한 크기의 메시지를 전달할 수 있습니다. 일반적으로 텐더민트는 결함이 있는 노드 책임에 중점을 둔 블록체인에 적합한 PBFT 구현입니다.

 

PBFT는 근본적인 함정이 있습니다. 블록에 대한 합의를 이끌어내기 위해서는 많은량의 메시지 교환이 필요합니다. 효율성 문제를 해결하는 방법 중 하나는 보안 부분에 있어 어떠한 타협도 없이 복잡성을 줄이는 것입니다.
Casper FFG와 같은 다른 PBFT기반 블록체인 프로토콜의 노력으로는, 메세지 유형을 두가지(준비 및 커밋)을 단 하나 (투표(Vote))로 단순화하기도 합니다.

 

ICON 네트워크는 복잡한 비즈니스 로직과 크로스 체인 상호운용성을 갖춘 스마트 컨트렉트에 충족시키는 것을 목표로 하고 있습니다. 이러한 목적을 달성하기 위해, 보다 최적화된 합의 알고리즘이 필수적이며 그것이 LFT2의 설계 목표입니다. 다음으로, 우리는 LFT2가 어떻게 이 위업을 달성하는지 살펴볼 것입니다.

 

 

 

LFT2 작동방식

 

^{그림1. LFT2 블록 합의 과정}

 

 

그림 1에서 볼 수 있듯이 각 합의 라운드는 제안 및 투표의 두단계로 구성됩니다. LFT2는 합의 과정의 두라운드에서 블록을 확인하고 다음 블록에서 블록을 커밋합니다. 즉, 블록 n+1은 블록n을 확인하고 커밋합니다. 더 깊이 들어갑니다.

 

그러려면, 먼저 아래 용어를 숙지해주세요.

 

 

 

 

리더 노드는 블록 (블록n) 을 제안하고 블록을 네트워크의 모든 검증 노드에 송출(Broadcast) 합니다. 각 검증노드는 블록n의 무결성을 검증하고 투표메세지를 네트워크의 다른 모든 노드에 송출(Broadcast)합니다. 리더노드와 유효성 검사 노드는 블록에서 트랜잭션을 실행하여 동시에 유효성 검사결과를 생성합니다.

 

블록 n이 위의 프로세스를 통해 ⅔ 이상의 투표를 수신하면 라운드는 성공한 것으로 간주되고 블록n은 후보 블록이됩니다. 이 시점에서 블록이 완전히 확인되지 않았지만 정족수 수준에 도달했습니다.

 

블록n + 1의 리더 노드는 블록n (후보 블록)의 실행 결과를 포함하고 블록을 네트워크의 모든 노드에 제안합니다. 성공적인 라운드로 블록n + 1에 투표 한 후, 블록n의 상태 해시가 최종 확인되고 블록은 커밋 블록으로 바뀝니다. 이 시점에서, 블록 확인은 라운드2의 끝에서 완료되고 블록n + 1은 새로운 후보 블록이되고 유사한 과정이 계속됩니다.

 

 

^{그림2. 이전 상태 해시가 다음 블록에 저장되는 방식}

 

 

위 그림은 다음 블록에 이전 상태 해시가 저장되고 블록1에서 블록1이 확인되는 것을 보여줍니다. 결정적 가상머신에서 다음블록의 이전블록 상태 해시를 확인하는 LFT2의 고유한 설계는 더 빠른 블록 확인 속도를 제공합니다.

 

 

 

성능비교

 

 

^{그림3. 트랜잭션 실행 시간에 대한 블록 확인 시간 (낮을 수록 빠름)}

 

 

위 그림은 트랜잭션 실행 시간에 대한 블록 확인 시간을 보여줍니다. 위의 그래프는 두 알고리즘 모두 다음블록에서 확인한다는 가정을 기반으로합니다. 그래프에서 볼 수 있듯이 LFT2는 차트 전체에서 PBFT보다 빠른 블록을 확인할 수 있습니다.

 

 

^{그림4. 네트워크 대기 시간에 따른 블록 확인 시간}

 

 

위 그래프는 블록 확인 시간이 네트워크 대기 시간 설정에 따라 어떻게 다른지 보여줍니다. 일반적으로 LFT2는 네트워크 대기 시간이 길어질수록 더 빠르게 수행됩니다.

^{그림5. n개의 블록을 확인하는 시간}

 

 

위 그림은 n개의 블록을 확인하는 시간을 보여줍니다. 보시다시피, LFT2는 블록이 증가함에 따라 PBFT에 대해 더 빠른 속도로 블록을 확인할 수 있다. 실제 네트워크 환경에서는 네트워크 지연이 발생함에 따라 격차가 더욱 커진다(이전 그래프 참조).

 

수학적으로 LFT2는 투표 메시지를 단일 라운드에 한 번에 송출(Broadcast)하며, 총 n + n² 개의 메시지를 가집니다. PBFT는 투표 메세지를 한 라운드에 두 번 송출하여 n + 2n² 개의 메시지를 생성합니다.  메시지 감소는 네트워크 송출를 완화시켜 메시지 송출 병목현상이 줄어듦에 따라 네트워크 대기 시간을 효과적으로 줄입니다.

 

 

 

추가 정보

 

자세한 내용은 [LFT2 백서]를 참조해주세요. LFT2는 어떠한 애플리케이션이나 블록체인에서도 사용할 수 있는 라이브러리로 구현됩니다. 코드는 [ICON 프로젝트 Github]에서 오픈 소스로 제공됩니다.

ICON 네트워크는 향후 LFT2로 업그레이드 될 예정입니다.

 

 

아이콘 깃허브: https://github.com/icon-project/LFT2