코스모스 GOS(Game of Stakes) 1차 이슈 정리

Jeong-hwan, Yun
Cosmonauts In Korea
5 min readDec 20, 2018

GOS(Game of Stakes)란?

GOS는 코스모스 허브의 목표 검증인 수인 약 300명의 검증인(코스모스 허브는 100명의 검증인으로 시작해서 10년에 거쳐서 300명의 검증인까지 늘어나게 됩니다)이 메인넷 이전에 서로 적대적인 환경에서의 네트워크와 합의를 실험하기 위한 이벤트입니다. 메인넷에서는 게임이론에 의해서 검증인들은 서로 협력하게 되어있지만 GOS에서는 그렇지 않습니다. 이를 통해 극한의 상황에서도 합의가 잘 작동하는지 테스트하고 검증인들은 실제 메인넷에서 있을 여러 공격들에 대비해 연습하게 될 것 입니다.

블록 생성 간격이 이상했던 문제

GOS 체인 초반에 블록 생성 시간이 몇분 간격으로 아주 느리게 생성되는 일이 있었습니다. GOS는 애초에 비정상적인 네트워크, 합의 상황에서의 테스트 용으로 더 높은 등수를 차지하기 위해 상대방 검증인과 협력하지 않고 공격해도 되는 것으로 전제가 되었기 때문에 어떤 익명의 검증인 집단에서 다른 검증인들을 공격하기 위해서 합의를 방해한 것으로 추정됩니다. 1/3에 준하거나 그 이상의 익명의 검증인 집단에서 이러한 공격이 효과가 있는지 실험을 해본 것으로 보입니다. 하지만 현재까지 이 공격 때문에 실제로 피해를 본 검증인은 없습니다.

실제 메인넷에서는 이러한 문제는 게임 이론에 따라 일어나지 않을 것입니다. 검증인은 자신의 자산을 스테이킹하고 검증인이 되었기 때문에 노드를 제대로 운영할 동기가 있습니다. 또한 노드를 제대로 운영하지 않으면 위임을 받지 못해서 검증인이 되지 못하거나 최악의 경우 자산이 삭감당할 수도 있습니다.

블록 프로포져 선택 알고리즘 버그 논란

https://github.com/tendermint/tendermint/issues/3044

텐더민트의 블록 프로포져 선택 알고리즘에 버그가 있다는 의견이 제기되었습니다.

하지만 이는 결론적으로 버그가 아니였습니다. 텐더민트는 WRR(Weighted Round Robin) 방식으로 매 라운드마다 검증인 중 블록 프로포져를 선택하게 됩니다. 각 검증인의 보팅파워에 비례하여 프로포져가 될 기회를 얻을 수 있습니다. 그렇기 때문에 위의 경우처럼 연속적으로 프로포져가 되는 것이 버그처럼 보일 수 있습니다.

텐더민트의 합의 방식은 매 라운드마다의 Safety를 보장하기 위해서 어느 라운드에 커밋되더라도 동일한 블록이 커밋된다는 것을 보장합니다. 하지만 그 블록이 어느 라운드에서 커밋될지는 보장하지 않습니다. 어느 검증인에서는 블록이 R 라운드에 커밋되었더라도 다른 검증인은 경우에 따라 R+1 이나 그 이상의 라운드에서 커밋될 수 있습니다. 어느 라운드에서 블록이 커밋될 지 알 수 없기 때문에 블록 프로포져를 선택할 canonical한 기준이 필요하게 됩니다. 텐더민트에서 다음 높이로 넘어갈 때 이전 높이의 자신이 커밋한 마지막 라운드의 블록 프로포져 선택 정보를 계승하지 않고 각 높이에 따른 독립된 블록 프로포져 선택 정보를 가지게 됩니다. 그래서 블록 프로포져는 (H, R) == (H+1, R-1)이 됩니다. 그렇기 때문에 경우에 따라 연속적인 프로포져가 선택될 수 있습니다.

블록 최대 크기 설정 문제

https://github.com/cosmos/game-of-stakes/issues/242

GOS 체인에서 제네시스 설정 파일은 블록의 최대 크기를 50kb로 제한하고 있습니다. 아마 이 설정 파일을 만든 분은 50kb 까지의 트랜잭션이 들어가기를 바랐을 것으로 보입니다만 실제로 이 블록의 최대 크기에는 트랜잭션 뿐만 아니라 그 블록의 커밋 정보들과 이전 블록에서의 서명 정보 등의 증거들도 포함되게 됩니다. https://github.com/tendermint/tendermint/blob/v0.27.3/types/block.go#L305

현재 GOS 체인에서 검증인은 약 200명으로 이들의 서명과 이전 블록에서의 서명 정보들로도 이미 50kb의 대부분을 차지하게 되어 실제 트랜잭션이 들어갈 공간이 매우 작아졌습니다. 그 결과 블록에는 대략 5–7개 정도의 트랜잭션밖에 들어가지 못하고 있습니다.

이 문제를 해결하기 위해 특정 블록 높이에서의 상태를 계승해서 새로운 체인을 시작하는 온체인 거버넌스 제안이 제출되었지만…

GOS 체인 정지(halt)

https://github.com/cosmos/cosmos-sdk/issues/3160

검증인이 언본딩하고 검증인 목록에서 제외될 때 그 검증인이 위임자에게서 받은 커미션중 따로 회수하지 않은 커미션은 소각되게 됩니다. 예상외의 소각으로 인해, 계산된 유통량과 실제 유통량이 맞지 않아 이를 확인하는 로직에서 오류가 발생했습니다.

https://github.com/cosmos/game-of-stakes/pull/247

GOS는 위의 최대 블록 사이즈 문제와 언본딩 시 버그도 해결하여 오류가 난 블록보다 두번째 앞의 블록의 상태를 계승해서 다시 시작하는 것으로 오프체인에서 의견이 모이고 있습니다.

현실적으로 지금까지의 모든 블록과 tx를 유지하면서 소프트포크하는 것보다는 계정 잔고, 스테이킹 정보 등의 상태만 계승해서 새로운 체인을 다시 시작하는 것이 낫다고 판단하는 것으로 보입니다.

GOS는 곧 메인넷을 앞둔 코스모스 개발팀과 검증인들에게 좋은 경험이 될 것입니다. 코스모스 개발팀에서 아직 미숙한 모습을 보이기도 했는데요. 이 경험을 발판삼아 완벽한 메인넷을 할 것이라 믿습니다. 앞으로 점점 더 흥미진진해질 GOS에 많은 관심 부탁드립니다.

--

--