세상을 늦게 보기 위해 잃었던 것들

안녕하세요. 플라네타리움 엔진팀에서 Libplanet을 개발하고 있는 이수호입니다. 오늘은 Libplanet을 개발하면서 생겼던 문제 중 블록체인에서 흔히 말하는 확정(Confirmation)으로 인해 생긴 문제와 그 문제를 발견하고 해결하는 과정을 이야기하고자 합니다.

확정(Confirmation)

블록체인에서의 블록은, 어떠한 사건이라고 볼 수 있고 체인은 사건으로 이루어진 일련의 시간 흐름이라고 볼 수 있습니다. 이전의 시간 흐름과는 맞지 않는 사건이 발생했을 때, 관측자는 이 사건을 올바르지 않은 사건으로 분류하고 거절합니다. 이 ‘올바른 사건’이라는 규칙을 대다수가 공유하고 있다면, 사건들만 순서대로 공유했을 때에 모두가 같은 현상을 관측하고 있다고 할 수 있습니다.

하지만, 이 서로 다른 ‘올바른 사건’이 동시다발적으로 제출된다면 어떻게 될까요? 일시적으로 관측자들 사이에 혼란이 생길 것이지만 결과적으로는 올바른 시간대를 바라보게 됩니다. 하지만 이 혼란으로 인해 관측하고 있는 정보를 기반으로 하고 있는 다른 사용자들은 혼란을 겪게 됩니다.

예를 들면. 방금 전 사건까지만 해도 분명히 100원이 있었는데, 이 사건이 없던 걸로 되어서 0원이 되어 버린다던가 하는 일들이 생길 수 있습니다.

이를 막기 위해 사용자는 확정(Confirmation) 이라는 ‘여기서부터는 뒤집히지 않는다’ 라는 수치를 두고, 이 수치 이전까지는 블록이 들어와도 체인에 받지 않습니다. 세상을 늦게 보고 확실해질 때 까지 기다리는 것이죠.

Libplanet 에서의 확정(Confirmation)과 렌더러(Renderer)

Libplanet 은 이 확정(Confirmation)을 지원하고 있습니다. 정확히는 렌더링 과정에서 확정(Confirmation)을 거칩니다. 이 렌더링 역할을 해 주는 렌더러(Renderer)는 블록체인의 상태를 수신해서 변경이 일어났을 경우 해당 렌더러의 콜백을 블록체인의 이전 상태,현재 상태와 함께 호출해 주는 역할을 가지고 있습니다.

이 중에서도 지연 렌더러(DelayedRenderer)는 블록 자체를 늦게 인지하는 것이 아닌 블록을 전부 인지 및 연산한 후에 렌더링 하는 부분만 가지고 있다가 수치가 넘어가면 감싸고 있는 렌더러(Renderer)에 보내줍니다.

더 자세한 정보는 DelayedRenderer에서 확인할 수 있습니다.

문제 발생

어느 순간, 사용자들에게서 메모리 사용량이 급증한다는 제보를 받았습니다. 켜놓은 지 약 1시간이 지나면 메모리 누수가 심각하게 일어나는 것을 확인할 수 있었습니다. 특정하는 것은 어렵지 않았습니다. dotMemory를 사용하니 어떤 클래스에서 메모리를 가장 많이 사용하는지 특정할 수 있었습니다.

문제는 다음입니다. 왜 메모리 누수가 일어났을까? 눈치가 빠르거나 경험이 많으신 분들은 이미 눈치채셨을지도 모르겠습니다.

원인 및 해결

앞에서 언급했던 문구를 다시 가져와 보겠습니다

이를 막기 위해 사용자는 확정(Confirmation) 이라는 ‘여기서부터는 뒤집히지 않는다’ 라는 수치를 두고, 이 수치 이전까지는 블록이 들어와도 체인에 받지 않습니다. 세상을 늦게 보고 확실해질 때 까지 기다리는 것이죠.

힌트는 여기서부터는 뒤집히지 않는다 입니다. 작업 기반 증명(Proof-Of-Work, PoW)에서는 합의 무결성(Safety)를 보장할 수 없기 때문에, 이것은 그 누구도 보장할 수 없습니다.

따라서 사용자가 지정한 이 확정(Confirmation) 을 체인 안쪽까지 끌어와서 블록체인 네트워크 엔지니어가 경계 값(Threshold)을 지정할 수 있게 하는 작업이 필요했습니다. 해당 작업의 결과는 #1163 PR에서 보실 수 있습니다.

마치며

일련의 모든 블록체인 합의 과정에서의 설명은 모두 작업 기반 증명(Proof-Of-Work, PoW)을 기반으로 설명되었습니다. 지분 기반 증명(Proof-Of-Stake, PoS)나 다른 합의 알고리즘에서는 필요 없는 이야기일 수도 있습니다.

설명이 조금 모자라거나 틀린 부분이 있으면 의견 남겨주시면 감사하겠습니다.