지난 2020년 3월 발생했던 klaytn consensus delay의 원인을 이해하고자 코드를 살펴보다가, 질문이 생겨 글 남깁니다.
위 링크를 통해, 그룹 1은 block을 수용하여 lock이 된 후에, timeout이 되어 round change를 실행되었고,
그룹 2는 proposer로부터 메시지를 받기 전 timeout되어서 바로 round change가 발생한 것으로 이해했습니다.
그 과정을 코드로 살펴보았습니다.
우선 그룹 1의 경우에 proposer의 pre-prepare 메시지를 수용한 후, 문제가 없으므로 sendprepare을 하게 됩니다. (handlePreprepare() 함수)
LockHash에 걸릴려면 handlePrepare()함수 내에서, 2f이상의 agreements를 받아야합니다.
하지만, 당시의 문제 상황이 발생했을 당시에는 2f의 이상의 충분한 prepare 메시지를 받을 수 없어 lock에 걸릴 수 없는 것 같습니다.
제가 이해한 것에 잘못된 부분이 있다면, 어떻게 lock에 걸린 것인지 설명 부탁드리겠습니다.
감사합니다.
저는 가장 최근 깃허브에 올라왔던 코드를 보고 있습니다. 혹시 버전의 문제일까요? 그렇다면 당시 코드 상황에 대한 간략한 설명 부탁드리겠습니다.
안녕하세요. Klaytn 개발팀의 Aidan입니다.
Klaytn 상세한 동작에 관심을 가져주셔서 감사합니다.
정확하게는 그룹1, 2 모두 proposer로부터 pre-prepare 메시지를 받은 상황입니다. 다만, 그룹1은 충분한 prepare 메시지를 받았고, 그룹2는 충분한 prepare 메시지를 받지 못한채 round change가 발생한 상황입니다.
LockHash를 위해서는 2f+1 이상의 prepare 메시지가 필요한데, 2f 미만의 CN이 Lock에 걸리는 것이 가능하냐는 의문을 가지실 것 같습니다. 알고리즘만 보면 불가능할 것 같지만, Network delay가 존재하는 실제 운영환경에서는 가능합니다.
설명을 위해서 CN 4개 존재하는 네트워크를 가정하겠습니다. 이 경우에 f는 1이고, LockHash를 위해서는 3개 이상의 prepare가 필요합니다. 이 네트워크 환경에서 아래 현상이 순서대로 진행되면 2개의 노드만 Lock에 걸릴 수 있습니다.
Proposer가 pre-prepare 메시지를 생성한 후, round timeout 직전에 다른 CN들에게 전파
모든 CN은 pre-prepare 메시지를 받고 preprare 메시지를 다른 CN들에게 전파
비교적 네트워크 환경이 좋던 CN0과 CN1은 4개의 prepare 메시지를 먼저 수신 (LockHash)
round timeout 시간에 도달하여 다음 round로 전환
CN2와 CN3는 timeout 전까지 수신한 prepare 메시지가 3개 미만이어서 Lock을 걸지 않았음
이 현상은 현재 코드에도 발생할 수 있습니다. 다만, 이 이슈와는 별개로 개선을 진행하여 당시의 코드보다는 Lock에서 빠르게 빠져나올 수 있는 조건이 추가되었습니다. 이러한 개선내용들은 Github repository에서 Release Note를 확인하시거나 관련 코드의 History나 Blame 기능을 통해 확인하실 수 있습니다.
