코스모스 거버넌스와 루나민트의 투표
거버넌스의 중요성
메인넷이 시작된 지 3주가 지나고 있는 시점에서, 현재 코스모스 허브는 두 개 프로포절에 대한 투표가 진행되고 있습니다. 코스모스는 거버넌스 기능이 프로토콜의 핵심에 있는 몇 안 되는 블록체인 시스템입니다.
블록체인에서 합의는 가장 중요한 절차 중 하나입니다. 근본적으로 블록체인이라는 시스템은 ‘분산된 원장의 변경에 대한 합의’가 가장 핵심적인 기능이며, 이를 결정하는데 컴퓨터 연산력(PoW) 또는 토큰 지분(PoS) 등 다양한 지표들이 합의를 결정하는 데 사용됩니다.
이런 컴퓨터 간의 거버넌스는 모든 참가자(검증인, 채굴기, 노드 등)가 하나의 규칙(코드)을 기반으로 작동되는 시스템 내에서 이루어지는 컴퓨터 데이터들의 합의입니다.
하지만 한 걸음 물러서서 이 시스템이 작동하는 규칙(코드) 자체를 변경하는 것은 어떤 합의 절차로 이루어지는 것이 맞을까요?
암호화폐 생태계 내에서 특정 프로젝트의 분열이 발생한 경우는 매번 이 포괄적인 합의 절차가 실패했기 때문입니다. 대표적으로 ‘TheDAO 해킹 자금을 복구할 것인가?’에 대한 갈등으로 이더리움과 이더리움 클래식이 분열했고, ‘비트코인의 블록 크기를 인상할 것인가’에 대한 갈등으로 비트코인과 비트코인 캐시가 분열했습니다.
컴퓨터 데이터 간의 갈등(fork와 uncled block)은 코드가 정한 규칙을 따라서 해결할 수 있지만, 인간 간의 갈등으로 발생한 분열은 쉽게 해결하기가 어렵습니다. 아직도 수많은 비트코인 포크들이 존재하는 것이 이를 증명합니다.
결국 사회적 합의가 없는 시스템은 기술적으로 완벽할 수 있어도 ‘가치( value)’를 인정받을 수 없기 때문에 큰 의미를 가질 수 없게 됩니다.
이런 이유로 코스모스는 ‘거버넌스(governance)’라는 형태로 토큰 보유자들의 직간접적인 사회적 합의가 코드에 반영될 수 있도록 시스템을 설계했습니다.
코스모스 거버넌스 시스템의 독특한 점 중 하나는 ‘액체 민주주의(liquid democracy)’라는 개념을 블록체인에 적용했다는 것입니다.
검증인은 본인의 위임자를 대표한 투표 행사권을 가지지만, 위임자가 원한다면 검증인과 다른 표를 직접적으로 행사할 수 있다는 것입니다. 이런 시스템의 의도는 직접 민주주의의 가장 큰 문제인 저조한 참여율을 방지하고, 동시에 소수 위임자의 의견이 대표자 투표에 반영이 되지 않는 대표 민주주의의 문제를 해결하는 의도가 있습니다.
루나민트의 투표
Proposal #1: blocks_per_year 값 수정 (YES)
코스모스 허브의 첫 프로포절은 국내 검증인 팀 비하베스트가 제안한 인플레이션 파라미터 변경 프로포절이었습니다. 코스모스 허브가 인플레이션을 계산하는 공식에는 blocks_per_year 라는 값이 포함되어있습니다.
코스모스 허브의 스테이킹 보상은 블록마다 분배됩니다. 그렇기 때문에 설정된 1년 기준 인플레이션(현재 값은 7%-20%)을 1 블록 기준으로 계산을 해야 합니다. blocks_per_year (1년이라는 기간에 만들어지는 블록 수) 값은 바로 이때 사용됩니다.
질문: 그냥 시간 기준으로 계산하면 안되나요? 왜 굳이 블록 기준으로 하는건가요?
블록체인은 분산화 시스템이기 때문에 ‘지금이 몇시야?’라는 값의 정답을 내기가 다소 어렵습니다.
저희 개인 컴퓨터의 경우 한번 사용자가 직접 시간을 설정한 후 컴퓨터 내의 시계가 시간을 계산하는 방법이 있지만, 대부분의 컴퓨터는 위 사진과 같이 특정 서버가 알려주는 시간을 기준으로 현재 시각을 알려줍니다.
하지만 만약 코스모스가 이렇게 애플 서버 기준으로 시간을 계산하다가, 시계에 오류가 발생하여 시간이 20배 더 빠르게 갔다면 어떻게 될까요? 오류가 발생한 시간 동안 더 많은 아톰이 발행되게 됩니다. 다양한 악의적인 행동을 감내할 수 있는 블록체인 탈중앙화 시스템에서 단일 고장점(single point of failure)을 만들게 되는 것이죠. 그리고 이 고장점은 블록체인 경제학적 설계를 망가트릴 수 있는 위험이 있는 것입니다.
텐더민트는 전 세계의 각 노드가 탈중앙화된 형식으로 시간을 계산할 수 있는 ‘BFT 시간(BFT Time)’ 기능을 지원합니다. 대표적으로 텐더민트 합의 알고리즘을 사용해 탈중앙화 GPS 시스템을 만드는 FOAM이 BFT 시간 기능을 사용합니다. 하지만 이런 형태로 시간을 찾는 것은 소수의 악의적인 행동으로 인해 블록체인의 시간을 조작할 수 있다는 가능성이 존재합니다. 그렇기 때문에 조금 더 간단하게 ‘1년에 생산되는 블록의 수’ 기준으로 매 블록 발행되는 아톰 수량(인플레이션)을 계산하는 것입니다.
문제는 현재 시작된 코스모스 허브는 5초마다 1블록 생산될 것이라는 전제하에 저 blocks_per_year 값을 설정했지만, 실제 메인넷에서는 6+초 마다 블록이 생산되고 있는 상황입니다. 즉, 의도했던 인플레이션보다 낮은 인플레이션이 발생하고 있는 상황이며, 이로 인하여 위임자들의 스테이킹 보상 또한 의도했던 수치보다 낮게 발생하고 있습니다.
프로포절 #1은 이 blocks_per_year 수치를 실제 블록이 생성되는 속도를 반영하도록 코스모스 허브의 코드를 변경하기 위한 프로포절입니다.
이 프로포절은 코드의 의도와 실제 작동하는 코드가 일치하지 않는 상황을 수정하는 것이기 때문에 루나민트는 YES 투표를 했습니다.
다만, 루나민트는 앞으로 코스모스 허브가 성장하기 위해서는 사용하기 편한 블록체인이 되어야 한다고 생각합니다. 이를 위해서는 네트워크의 보안을 해치지 않는 한에서 블록이 더 빠르게 만들어지는 것이 중요하다고 생각합니다.
코스모스 허브는 현재 블록체인의 크기가 과도하게 증가하는 것을 방지하기 위해서 인위적으로 블록 생성 시간을 늦춘 상황입니다. 앞으로 state pruning(블록체인 상태 데이터 제거) 같은 기능이 추가되면서 블록체인의 블록 생성 속도를 높이며 인플레이션 수치가 올바르게 작동할 수 있었으면 좋겠다는 바람이 있습니다.
Proposal #2: 토큰 전송을 위한 코스모스 허브 업그레이드 절차 (NO)
프로포절 #2는 아톰 전송을 활성화하는 절차에 대한 제안입니다.
루나민트는 텐더민트 팀의 제안을 따라 해당 프로포절에 NO 투표를 행사했습니다.
아톰 토큰 전송이 시작되는 것은 코스모스 허브가 충분한 안전성을 확보했다는 것을 모두에게 알리는 것과 같으며, 3개의 메인넷 단계 중 두 번째 단계로 넘어가는 중요한 결정이기도 합니다. 아톰 전송 활성화는 커뮤니티가 가장 관심 가지고 있는 이슈 중 하나입니다.
저희는 토큰 전송 활성화가 네트워크 탈중앙화를 시작하는 첫 단계라고 생각합니다. 현재 코스모스 허브는 대략 1,000명의 펀드레이저 참여자만 있는 폐쇄적인 네트워크입니다. 토큰의 손바뀜이 일어나며 더 많은 사람이 아톰 토큰을 보유하며 코스모스 허브 스테이킹과 거버넌스에 참여한다면 검증인 보팅 파워와 거버넌스 투표에 변화가 있을 것을 기대하고 있습니다. 그런 의미에서 저희 검증인은 최대한 빠른 시일 내에 토큰 전송화를 활성하는 것을 지지하고 있습니다.
하지만 프로포절 #2는 일부 검증인과 커뮤니티 개발자들의 강한 반발을 불러왔습니다. 프로포절 #2가 제안하는 소프트웨어 업그레이드 방식이 명확하지 않은 부분과, 소프트웨어 버전을 커뮤니티가 인정하는 투표가 생략되었다는 것이 주요 논점이었습니다. 일부 개발자들은 프로포절 #2가 제안하는 절차가 텐더민트 팀이 코스모스 허브 소프트웨어에 끼치는 영향력을 과도하게 부여한다는 이의를 제기했습니다.
아톰 전송 활성화에 대한 자세한 논의는 코스모스 포럼 글에서 확인하실 수 있습니다.
텐더민트 팀은 전송 일정을 최대한 미루지 않는 방향 내에서 두 단계의 프로포절 (1단계: 소프트웨어 버전 승인, 2단계: 업그레이드 날짜 결정)로 토큰 전송이 활성화될 수 있는 방안을 제시했고, 이에 대한 재투표가 곧 진행될 것으로 보입니다.
코스모스 허브의 탈중앙화는 매우 중요한 이슈입니다. 하지만 지금까지 텐더민트 팀이 개발을 주도해왔던 만큼, 하루 아침에 텐더민트 팀이 코스모스 허브에 끼치는 영향력이 없어질 것을 기대하는 것은 비현실적이라고생각합니다.
저희는 네트워크 초기에는 이상적이지만 비현실적인 탈중앙화보다 현실적이고 지속 가능한 탈중앙화를 추구하는 거버넌스 투표를 실행하도록 하겠습니다.
