Validator’s Note 7 — Sui Wave 2 Validator Game을 되돌아보며

Youngbin Park
DSRV
Published in
14 min readMar 2, 2023

Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생한 결과에 대해 어떤 부분에서도 DSRV는 책임을 지지 않습니다. 본문이 포괄하는 내용들은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다.

수이 테스트넷 웨이브 2 (Sui Testnet Wave 2)가 2/15일 성공적으로 종료되었습니다. 웨이브 2는 수이의 토크노믹스, 즉 수이 토큰을 스테이킹하였을 때 리워드는 어떻게 부여되는지, 가스비는 어떻게 책정되는지 등 수이 토큰의 경제적인 인센티브 구조를 테스트하기 위하여 진행되었는데요. DSRV 밸리데이터팀 또한 웨이브 2에 참여한 결과 밸리데이터 게임(Validator Game)에서 2위라는 좋은 성적을 거두었습니다!

웨이브 2에서 밸리데이터는 활성화된 스테이킹 기능을 사용하여 사용자들이 위임한 SUI 토큰을 바탕으로 수이의 컨센서스에 참여합니다. 또한 밸리데이터들은 네트워크가 원활하게 유지될 수 있도록 노드를 운영하는 것뿐만 아니라, 수이의 가스비를 결정하는 매커니즘에서도 중요한 역할을 하는데요. 이와 관련하여 수이의 가스비 메커니즘을 테스트해 보는 것이 바로 밸리데이터 게임입니다.

따라서 본 글에서는 DSRV 밸리데이터 팀이 밸리데이터 게임에 참여한 과정과 이를 통해 얻은 경험을 수이의 토크노믹스와 수이 밸리데이터 노드 운영 두 측면에서 정리해 보려고 합니다.

Validator Game Overview

밸리데이터 게임에서 가장 주요하게 테스트 되었던 것은 바로 Reference Gas Price를 결정하기 위한 Gas Price Survey와 Tallying Rule 입니다. Reference Gas Price는 밸리데이터를 통해 결정되어 한 에폭동안 유지되는 값으로, 사용자들은 이 가격을 기준으로 가스비를 산정하여 원활하게 트랜잭션을 실행할 수 있습니다. 이에 따라 밸리데이터들은 각 에폭 마다 수행해야 할 두 가지 임무가 있었습니다.

1. Gas Price Survey

밸리데이터들은 각 에폭이 끝날 때마다 다음 에폭의 Reference Gas Price 투표를 제출합니다. 수이는 모든 밸리데이터들이 제출한 다음 에폭의 Reference Gas Price를 오름차순으로 정렬하고 밸리데이터들의 보팅 파워를 누적하였을 때 2/3에 해당하는 가스 가격을 다음 에폭의 Reference Gas Price로 결정합니다. Reference Gas Price 결정 과정에서 밸리데이터의 보팅 파워는 최대 10%까지 유효하며, 초과한 보팅 파워는 다른 밸리 데이터에게 분배됩니다.

2. Tallying Rule

벨리데이터들은 Tallying Rule을 위한 투표도 제출합니다. Tallying Rule은 네트워크에 참여하는 밸리데이터들이 서로를 모니터링 하여 올바르게 작동하고 있는지 주관적으로 점수를 매기는 시스템입니다. 웨이브 2 에서 Tallying Rule은 일부만 구현된 상태로 다른 밸리데이터들에 대하여 1혹은 0의 점수를 제출할 수 있게 하였습니다. 각 밸리데이터의 점수는 다른 밸리데이터에게 받은 모든 점수를 내림차순으로 정렬하고 그들의 보팅 파워를 누적하였을 때 2/3에 해당하는 점수로 결정됩니다. 점수가 0 으로 결정된 밸리데이터들은 리워드를 삭감당할 수 있으며, 삭감당한 밸리데이터의 리워드는 다른 밸리데이터들의 리워드로 분배됩니다.

수이의 토큰노믹스 문서에 따르면 수이는 Incentivized Stake Reward Distribution Rule을 통하여 Gas Price Survey 및 Tallying Rule로 계산된 점수에 따라 리워드의 차등을 두는 방식을 도입하려 합니다. 하지만 이는 아직 웨이브 2 테스트넷에 완전히 구현되지 않았습니다. 따라서 밸리데이터 게임에서는 Gas Price Survey에 대하여 수이 개발사인 미스틴 랩스(Myten Labs)가 점수를 별도로 채점하여 벨리데이터들이 간접적으로 매커니즘을 경험해 볼 수 있게 하였으며, Tallying Rule은 단순화된 방식으로 적용되었습니다.

Rules

밸리데이터 게임에 참여하는 밸리데이터들은 두가지 항목에서 점수를 얻어 경쟁하게 됩니다.

  1. 제출한 Reference Gas Price를 오름차순으로 정렬하였을 때 보팅 파위의 2/3안에 포함되는 경우
  2. 제출한 Reference Gas Fee 값에 대하여 밸리데이터가 수익을 내고 있는 경우.

$ Validator’s Profits in Epoch e = ($ Validator’s Rewards in Epoch e) — ($ Validator’s Cost in Epoch e)

해당 에폭에서의 밸리데이터의 수익은 밸리데이터가 받는 리워드에서 트랜잭션을 실행하는데 필요한 노드의 운영 비용을 차감한 값으로 계산됩니다. 밸리데이터들은 게임 기간 동안 사용할 가상의 가스 당 운영 비용을 랜덤하게 부여받고, 이를 통해 수익성에 대한 점수를 채점 받습니다. 운영 비용은 에폭마다 정해진 값이기 때문에 수익성 계산에는 밸리데이터들이 받는 리워드가 큰 영향을 미치게됩니다.

별도의 블록 리워드가 없는 수이에서 밸리데이터의 리워드는 대부분 해당 에폭에서 지불된 가스비로 구성됩니다. (정확한 리워드 계산 식이 궁금하시다면 이전 아티클을 확인하세요.) 따라서 위의 수익성 계산식은 아래와 같이 다시 정리해 볼 수 있습니다. 이때 운영 비용는 달러로 고정된 값이지만 가스비는 SUI 토큰으로 계산되어 에폭마다 그 달러 환산 가치가 다를 수 있습니다. 결국 밸리데이터는 에폭마다 SUI의 토큰 가격 및 자신의 운영 비용을 고려하여 적절한 Reference Gas Price를 찾아야 합니다.

$ Validator’s Profits in Epoch e
≈ (Gas Units Executed in Epoch e)*(Reference Gas Price)*($ SUI Token Price in Epoch e)*(Validator’s share of total stake) — (Gas Units Executed in Epoch e)*(Cost in $ per Gas Unit in Epoch e)
≈ (Reference Gas Price) * (SUI Token Price in Epoch e)*(Validator’s share of total stake) — (Cost in $ per Gas Unit in Epoch e)

예를 들어 운영 비용이 높은데 수이 토큰의 가격이 낮은 상태일 경우에는 수익을 내기 위하여 Reference Gas Price를 높은 값으로 제출해야 하지만, 이 경우 제출한 Reference Gas Price가 보팅 파위의 2/3안에 포함되지 않을 확률이 높아지게 됩니다. 한 가지 더 고려할 것은 밸리데이터의 스테이킹량으로, 높은 스테이킹량을 가진 밸리데이터는 리워드를 상대적으로 많이 받게 되어 운영 비용이 높더라도 낮은 Reference Gas Price 값을 제출할 수 있는 여유가 생기게 됩니다.

토크노믹스 측면

스테이킹량의 변화

웨이브 2에는 시작(에폭 0)부터 많은 사용자가 참여하여, 밸리데이터들에게 테스트넷 SUI를 스테이킹 하였습니다. 하지만 첫번째 에폭이 지난 후 한 밸리데이터가 다른 밸리데이터들에 비해 많은 스테이킹을 받아, 전체의 25%이상의 보팅 파워를 차지하는 모습이 나타났습니다. 이는 사용자들이 스테이킹할 때 사용하는 수이 지갑의 밸리데이터 목록의 상단에 위치하였기 때문인 것으로 파악되었습니다.

에폭 0에서 스테이킹된 SUI는 에폭 1에서 활성화되어, 에폭 2부터 리워드가 지급되기 시작합니다. 따라서 에폭 2부터는 밸리데이터의 스테이킹 풀에 쌓인 리워드에 따른 이자율(APY)로 지갑의 밸리데이터 목록 순위가 변경되었습니다. 낮은 스테이킹량을 가졌던 밸리데이터는 가장 높은 이자율을 가진 것으로 상위 순위에 표시되며 한 에폭만에 가장 많은 스테이킹을 받은 밸리데이터가 되었습니다.

웨이브2 에서는 모든 밸리데이터들의 수수료가 15%로 고정되어 있고, 별도의 Tallying Rule로 인한 리워드 삭감이 발생하지 않은 게임 초기에는 모든 밸리데이터들이 스테이킹 비율대로 리워드를 받아 이론적으로 이자율도 같게 표시되어야 합니다. 하지만 지갑에서 계산된 이자율에는 미세한 차이가 발생하여, 목록의 상위에 위치한 밸리데이터에게 많은 위임이 추가되었습니다.

Reference Gas Fee 계산 과정에서 스테이킹량을 많이 가지고 있는 밸리데이터의 보팅 파워가 최대 10%로 제한되기는 하지만, 위에서 살펴본 바와 같이 스테이킹량이 높은 밸리데이터는 더 많은 리워드를 받아 더욱 낮은 Reference Gas Price 값을 제출하고도 수익성을 유지할 수 있어 스테이킹량이 낮은 밸리데이터들보다 유리한 위치를 점할 수 있었습니다.

스테이킹량이 낮은 밸리데이터들은 수익성을 포기하고 낮은 Reference Gas Price 값을 제출하거나, Reference Gas Price 순위를 포기하고 수익성을 챙기는 선택을 할 수밖에 없었습니다. 이처럼 지갑의 UI에서 비롯된 스테이킹량의 차이는 밸리데이터간 경쟁에 큰 영향을 미쳤습니다. 이를 완화하기 위하여 에폭 9부터는 미스틴 랩스가 밸리데이터들의 스테이킹량을 동등하게 조절하였고, 이후에는 밸리데이터들이 조금 더 공정한 상황에서 게임에 참여할 수 있었습니다. 그렇지만, 이러한 스테이킹량의 집중은 사실 메인넷에서도 발생할 수 있는 사용자들의 행동 양식을 보여주는 자연스러운 사건이었습니다.

Reference Gas Fee에서 발생한 버그

에폭 8 및 9 에서는 Reference Gas Fee가 예상보다 높은 값으로 결정되는 사건이 있었습니다. 밸리데이터 게임의 중요한 요소인 Reference Gas Fee의 결정 코드에서 발생한 버그로 인해 밸리데이터들은 두 에폭동안 혼란을 겪었습니다. 미스틴 랩스는 빠르게 버그를 수정하여 에폭 10부터는 정상적으로 작동하였으나 정확히 어떠한 문제였는지는 알리지 않았습니다.

Tallying Rule을 통한 리워드 삭감

에폭 14부터는 Tallying Rule이 시작되었습니다. Tallying Rule에 따라 밸리데이터들은 sui_system 모듈의 report_validator 함수를 호출하는 트랜잭션을 전송하여 올바르지 않은 행동한 특정 밸리데이터에게 0을 투표합니다. 다른 밸리데이터들의 투표를 통하여 최종 점수가 0으로 결정된 밸리데이터들은 리워드를 삭감당할 수 있습니다.

에폭 14에서 미스틴 랩스는 Tallying Rule을 통한 리워드 삭감이 실제로 어떻게 일어나는지를 파악할 수 있도록 밸리데이터들에게 의도적으로 미스틴 랩스의 노드에 0을 제출하도록 하였습니다. 따라서 에폭 14에서 미스틴 랩스의 밸리데이터 노드는 최종적으로 0을 받아, 테스트넷의 리워드 삭감율에 따라 실제로 약 50%의 리워드만을 수령하였습니다.

epoch 13. 출처: Suiscan
epoch 14. 출처: Suiscan
epoch 15. 출처: Suiscan

수이의 스테이킹 리워드는 오브젝트의 형태로 전달되며, 자동으로 다시 스테이킹됩니다. 따라서 해당 에폭에서 밸리데이터의 리워드는 에폭이 끝날 때마다 전달된 스테이킹 오브젝트에 담긴 잔액으로 확인할 수 있습니다. 위 이미지는 각각 Myten Labs-1 밸리데이터가 에폭 13, 에폭 14 및 에폭 15에 해당하는 리워드를 오브젝트 형태로 수령한 것입니다. 오른쪽 상단의 잔액을 살펴보면, Tallying Rule을 통해 리워드의 삭감이 발생한 에폭 14의 경우 전후 에폭의 리워드보다 확연히 적은 양의 리워드를 수령했음을 확인할 수 있습니다.

밸리데이터 노드 운영 측면

에폭(Epoch) & 체크포인트(Checkpoint)

수이에는 에폭 및 체크포인트라는 개념이 있습니다. 수이의 오브젝트로 데이터를 저장하는 구조 및 합의 알고리즘은 트랜잭션들을 개별적으로 검증하여 병렬적으로 처리할 수 있게합니다. 이처럼 수이는 여타 블록체인과는 다르게 블록이라는 단위로 트랜잭션을 처리하지 않기 때문에 개별적으로 실행한 트랜잭션이 일정량 추가될 때마다 밸리데이터들 간 합의를 통하여 체크포인트를 설정합니다. 이 고정된 개수의 체크포인트가 쌓인 것이 바로 에폭입니다.

수이는 1/26일 성공적으로 제네시스 세레머니를 완료하여 에폭 0으로 시작하였습니다. 수이는 에폭 0에서 한 에폭을 약 24시간으로 유지하고자 28800개의 체크포인트를 포함하고 있었습니다. 하지만 에폭 0에서 체인 바이너리 문제로 모든 벨리데이터들의 온보딩이 정상적으로 이루어지지 못하였고, 일부 밸리데이터들이 수이의 컨센서스에 정상적으로 참여하지 못하면서 체크포인트가 쌓이는 속도가 느려지는 현상이 발생하였습니다.

이에 따라 에폭 0은 애초에 의도했던 24시간보다 더 오랜 시간 이어졌습니다. 에폭 시간이 지연되는 문제를 해결하기 위하여 수이는 다음 에폭 1에서 한 에폭 당 포함되는 체크포인트 개수를 28800에서 19000으로 감소시키는 방향으로 설정을 변경하여 에폭 시간을 24시간에 맞게 조절하였습니다. 하지만 이는 일시적인 방편이었으며, 이후에도 여러 번 업그레이드가 이루어졌습니다.

아래는 테스트넷이 진행되는 동안 DSRV 노드에서 체크포인트가 쌓이는 속도를 모니터링한 것입니다. 2/2일 경에는 체인이 멈추는 사고가 있었지만, 업그레이드 이후 체크포인트가 쌓이는 속도가 정상적으로 돌아와 에폭 시간이 약 20시간으로 감소하였습니다. 이후 2/6일 진행한 업그레이드에서는 min_header_delay라는 변수를 새로이 적용시켜 컨센서스 지연시간을 개선하였고, 에폭 시간이 20시간에서 12시간으로 대폭 감소하였습니다. [1]

Checkpoint Velocity. 출처: DSRV

기타

또한 컨센서스와는 별개로, DSRV가 운영하던 밸리데이터 노드의 CPU 및 디스크 사용량이 급증하며 갑작스럽게 작동을 멈추는 문제가 발생하기도 하였습니다. [2]이러한 비정상적인 현상은 처음에는 몇 분, 이후에는 1시간 가량 후 에 별다른 조치없이 자동적으로 복구되었습니다. 유사한 문제를 겪은 다른 밸리데이터도 존재하나 아직까지 정확한 원인은 알 수 없는 상태입니다.

마무리

지금까지 DSRV 밸리데이터 팀이 웨이브 2에서 수이의 에폭 및 체크포인트 시스템, 그리고 가스비 및 리워드 매커니즘을 테스트해 본 과정을 살펴보았습니다. 웨이브 2는 사용자들이 참여할 수 있는 스테이킹 기능이나 Frenemies Game 등의 효과로 지난 웨이브 1보다 더욱 많은 사용량을 기록하였습니다.

하지만 네트워크 부하 및 컨센서스에서 발생한 문제로 체크포인트 및 에폭에 지연이 발생하기도 하였습니다. 웨이브 2에서는 약 3주간의 기간 동안 3번의 체인 중지가 있었고 수이의 밸리데이터 노드에서는 여러 문제를 해결하기 위하여 총 8번의 업그레이드가 진행되었습니다. 그럼에도 불구하고 미스틴 랩스는 문제 상황에 대하여 신속하게 대처하였고, 밸리데이터들은 웨이브 2 끝까지 네트워크를 무사히 운영할 수 있었습니다. 이후 단계들 에서는 웨이브 2에서 발생했던 문제들이 개선되어 노드를 더욱 안정적으로 작동할 수 있기를 바랍니다.

밸리데이터 게임을 통하여 살펴본 Gas Price Survey 및 Tallying Rule과 같은 매커니즘은 여타 블록체인에서는 살펴보지 못한 수이의 특별한 방식이었습니다. 사용자들에게 합리적인 가스 가격(Reference Gas Price)를 제공하기 위하여, 수이의 가스비 결정 매커니즘은 밸리데이터의 리워드와 밀접하게 연결되어 있으며 밸리데이터들이 그 참여 과정에서 낮은 가스 가격을 제출하고 이에 따라 트랜잭션을 처리하도록 장려합니다.

웨이브 2에서 밸리데이터들은 완전한 구현은 아니더라도 밸리데이터 게임을 통해 추후 메인넷 전환 후의 실제 밸리데이터의 수익과도 밀접한 관련이 있는 토큰노믹스를 미리 이해해 볼 수 있는 좋은 기회를 가질 수 있었습니다. 수이가 많은 관심속에 진행된 웨이브 2를 통해 다양한 문제 상황들을 경험할 수 있었던 만큼, 이를 개선하여 다음 단계로 나아갈 수 있기를 기대합니다. 읽어주셔서 감사합니다.

더욱 자세한 내용이 궁금하시다면, 수이에서 작성한 웨이브2 요약도 살펴시면 좋을 것 같습니다.

Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)

Reference

[1] https://github.com/MystenLabs/sui/pull/7970
[2] https://github.com/MystenLabs/sui/issues/8142

--

--