클레이튼이 원천으로 삼은 이더리움에도 지난 8월 유사한 문제가 있었으나, 이더리움 네트워크는 정상적으로 운영됐기 때문이다.
이 같은 차이는 그라운드X에 집중된 폐쇄적인 개발 체계 때문이라는 지적이다.
# 사고 원인
클레이튼은 이번 셧다운 원인 분석 보고서에서 “확률적으로 매우 낮은 사용 패턴이 발생했다”고 밝혔다.
하나의 블록 안에 서명 키가 두 개 존재하게 됐다는 것. 쉽게 말해 계좌 비밀번호를 바꾸는 과정에서 서로 다른 서명이 쓰였고, 이를 다른 노드들이 “검증->반려->다시 검증”을 반복했다는 것이다.(아래 그림 참조)
블록 검증이 무한 루프를 돌면서 시스템을 셧다운시켜야만 했다는 설명이다.
# 이더리움 개발 랭귀지 버그
이더리움 네트워크에 정통한 한 개발자는 “클레이튼에 발생한 오류는 지난 8월 이더리움 네트워크에서도 나타났던 것”이라고 말했다.
이더리움에 사용되는 프로그램 언어 고(GO)의 특성 때문에 이러한 오류가 있었다는 것. 이더리움의 경우는 고(GO) 언어 외에 C++ 계열, 파이선 등 다른 언어로 된 체인이 있었고, 따라서 큰 문제 없이 오류 수정이 가능했다는 설명이다.
이 개발자는 “클레이튼 개발팀의 실력이 떨어진다는 차원이 아니라, 그리고 이런 오류를 일일이 다 발견하고, 대비해야만 했다는 차원이 아니라, 클레이튼 소스 코드 관리 체계에 아쉬움이 있다”고 지적했다.
# “보는 눈이 많으면 버그도 쉽게 잡는다”
클레이튼은 이더리움과 같이 고(GO) 언어로 프로그램을 개발했다. 그러나 이더리움과 달리 다른 언어를 지원하지 않는다. 그라운드X 밖의 개발자가 소스 코드 개선에 기여하는 체계도 약하다. 심지어 거버넌스 카운슬 소속 기업도 개발에서 분리돼 있다.
이더리움에 능통한 개발 전문가는 “클레이튼 거버넌스 카운슬에 30개 노드가 있지만 이들은 단순 운영에만 참여할 뿐 개발 참여는 이뤄지지 않는 것으로 안다”고 말했다.
이더리움은 문제의 버그를 다른 언어로 개발된 프로그램이 훌륭하게 커버했다. 고(GO) 언어에서 비롯된 버그를 사전에 막지는 못했지만 대체가 가능했다는 것.
반면 그라운드X 개발팀이 문제를 알고, 원인을 분석하고, 해법을 내놓을 때까지 36시간 동안 오직 그라운드X 직원 또는 극히 일부의 외부 인력들에 의존했다.
블록체인 메인넷을 개발 중인 다른 개발사 관계자는 “오류 보고서에 클라이튼 측이 어떤 노력을 했는지는 소상이 나와 있으나, 사고 처리에 시간이 너무 오래 걸렸다. 그라운드X가 소스 코드 컨트롤 능력이 있는지 솔직히 의심이 든다”고 말했다.
# “홀로 완벽해질 수는 없다”
어떤 블록체인도 100% 완전한 시스템이 아니라는 것은 전문 개발자들도 인정하다.
메인네 개발사 관계자는 “이더리움, 솔라나 등 대형 프로토콜에서도 거래소만 인지할 정도의 소소한 장애는 수시로 일어난다. 원인을 신속하게 파악해서 패치를 돌리는 일도 흔하다”고 말했다.
문제는 지금처럼 그라운드X가 집중화된 개발 체계를 고집할 경우 이번 셧다운과 같은 사고가 다시 또 일어날 수 있다는 것이다.
그라운드X측은 “별도의 개발 네트워크 조직은 없으나, 코드가 공개돼 있고, 누구든 원한다면 개발에 참여할 수 있다”고 말했다.
그라운드X측은 “개발 및 생태계 기여를 위한 제안서를 제출하고 선정이 되면, 클레이(KLAY)를 지원하는 펀드 프로그램도 있다”고 밝혔다.
외부 개발자가 참여를 위해 제안한 것들을 들여다보는 주체 역시 그라운드X다. 모든 것이 중앙 기구의 손에 달려 있다는 뜻이다.
같이 읽으면 좋을 기사
