아스타 네트워크 — 디앱 스테이킹 V3 개요 전문
경제적 인센티브 철학을 통한 디앱 스테이킹 시스템 강화의 도모 및 커뮤니티 자생 방안 확립
Kahori, Astar Official Ambassador “스테이커는 적극적인 투표 활동을 통해 추가적인 수익 기회를 놓치고 싶어하지 않을 것으로 기대됩니다. 동시에 프로젝트는 스테이커를 다시 확보하기 위해 창의력을 발휘할 것이므로, 아스타 커뮤니티는 활기를 더할 것으로 기대됩니다.”
본 기사는 Astar Forum에 공개된 dApps Staking v3 — proposal을 기반으로 작성되었습니다. 원문 및 관련 논의는 아래 링크를 통해 확인하실 수 있습니다.
1. 서론
아스타 네트워크의 디앱 스테이킹 (dApps Staking)의 핵심 목표는, 빌딩을 위한 플랫폼으로서 아스타 네트워크를 선택한 개발자에게 경제적 동기를 부여하는 것입니다.
$ASTR 또는 $SDN 홀더는 “디앱”을 대상으로 토큰을 스테이킹을 진행하며, 디앱 스테이킹 시스템에 등록된 애플리케이션 중, 홀더는 스스로 원하는 디앱을 선택하여 스테이킹합니다. 그리고 스테이커는 이 행동에 대한 보상으로 인플레이션의 일부를 받아갑니다.
등록된 디앱은 확보한 토큰 스테이킹 TVL에 따라 보상을 받습니다. 예를 들어, 디앱 A가 확보한 스테이킹의 양이 총 디앱 스테이킹 TVL의 10%를 차지한다면, A는 디앱 보상을 위해 할당된 인플레이션의 10%를 받게 됩니다.
2. 문제점
과거 2년 동안 디앱 스테이킹의 설계와 관련된 여러가지 문제가 있었습니다. 커뮤니티는 이에 대한 우려를 표현했고, 코어팀은 내부적으로도 이에 대해 깊이 논의했습니다.
다음은 해결해야하는 문제 및 과제를 요약한 내용입니다.
- 디앱 스테이킹 등재 및 제외에 대한 의사결정이 완전히 탈중앙화되어야 합니다.
- 등재된 디앱 중 몇몇은 인프라 제공자나 커뮤니티 프로젝트와 같은 디앱이 아닌 경우가 있었으나, 모두 동일한 혜택을 제공받았습니다.
- 디앱의 퍼포먼스 및 메트릭스에 대한 인사이트가 고려되지 않습니다.
- 디앱에 대한 보상 체계는 확장 가능하지 않으며, 제로섬 게임입니다.
- 하나의 디앱이 디앱 스테이킹을 위해 구비된 보상 풀의 100%를 받아가버리는 가능성이 존재합니다.
- 신규 디앱이 경제적 보상을 받기 위한 진입 장벽 높습니다. (억 단위의 TVL을 가진 다른 디앱과 즉시 경쟁해야 함).
- 스테이커의 저조한 리텐션으로 인해 Stake & Forget 현상이 발생합니다. 한 번 스테이킹하면, 추가적으로 요구되는 행동은 스테이킹 보상을 클레임하는 것이 전부이기 때문입니다.
- 청구되지 않은 잊혀진 보상이 소각되지 않는 문제가 있습니다.
3. 해결 방안 개요
앞서 언급한 문제들 중 여럿은 디앱 스테이킹의 팔렛(모듈)의 조정 및 재설계만으로는 해결하기 어렵습니다. 탈중앙화된 디앱 스테이킹 등재 시스템에는 거버넌스 통합이 필요하며, 등재된 디앱의 퍼포먼스 메트릭에는 UI가 통합된 오프체인 로직이 필요합니다 (이미 작업 중).
다음은 문제 해결을 위한 방안의 개요이며, 디앱 스테이킹의 프로토콜 단에서 변경되어야 할 내용을 서술합니다.
- 확장 가능한 보상 시스템: 디앱을 위한 보상의 풀은 한정되어 있기 때문에, 수용할 수 있는 디앱의 수에는 한계가 있습니다. 그러나 네트워크의 가치가 성장함에 따라, 양의 피드백 루프를 기반으로 지원 가능한 디앱의 수를 늘릴 수 있는 시스템이 필요합니다.
- 하나의 디앱이 얻을 수 있는 보상에 한계치를 설정합니다.
- 디앱 스테이킹 프로토콜에 신규로 입장한 디앱이, 즉시 상위 랭크의 디앱과 경쟁하지 않아도 현실적인 보상을 얻을 수 있어야 합니다. 그러나 동시에 네트워크의 성장을 위해 상호간의 경쟁이 장려되는 시스템이 필요합니다.
- 스테이커는 Stake & Forget이 아니라, 주기적인 스테이킹 참여 및 의사결정을 장려할 수 있는 시스템이 필요합니다.
- 즉 능동적인 스테이커는 수동적인 스테이커보다 더 많은 보상을 받을 수 있어야 합니다.
3.1. 락업과 스테이킹의 작업을 분리
디앱 스테이킹 V2에서는 락업과 스테이킹을 단일 작업 (bond_and_stake)으로 결합하고 있습니다. 마찬가지로 락업 해제와 언스테이킹 (unbond_and_unstake)도 동일합니다.
디앱 스테이킹 V3는 이러한 작업을 분리합니다.
- 자본을 “락업 상태” 로 만들고 나서 스테이킹에 사용이 가능하도록 합니다.
- 스테이킹 된 자본은, 해당 디앱에 대한 “투표” 로도 작용합니다.
- 스테이킹 되지 않은 자본은 어떠한 디앱에도 평가 점수에 기여하지 않습니다.
- 락업을 해제하기 위해선, 락업 해제 (Unbonding) 프로세스를 시작해야 합니다.
- 락업 해제를 위해 소요되는 시간이 경과하고 나서, 홀더는 그 자본을 자유자재로 사용할 수 있습니다.
- 최종 설계도에 따라 달라질 수 있으나, 스테이킹을 선택한 디앱을 변경하는 기능은 현재와 같이 유지될 가능성이 높습니다.
3.2. 디앱의 티어를 구분하여 개발자 보상을 책정
디앱 스테이킹 V2에서는 스테이킹을 확보한 $ASTR 수량에 선형적으로 비례하여 디앱에 보상이 지급되었습니다.
하지만 V3에서는 티어 기반의 보상 분배 시스템을 적용합니다.
위 그림에 기반하여 티어 기반의 보상 분배 시스템의 예시를 설명드리겠습니다.
3개의 티어가 존재하고, 총 23개의 디앱을 지원할 수 있는 반면, 현재 디앱 스테이킹에는 13개의 디앱만이 참여하고 있습니다.
한 Era가 종료되면서, 티어의 정렬 발생하였으며 총 13개의 디앱이 3개의 티어로 정렬됩니다.
디앱 A가 최상위 1번 티어로 들어갔습니다. 해당 티어에는 2개의 빈 자리가 있지만 다른 디앱은 참여 요건을 충족하지 못했습니다. 이 시스템은 디앱 스테이킹 위의 모든 디앱이 전체의 보상 풀을 할당받는 현재의 방식과는 크게 상이합니다.
2번 티어에는 4개의 디앱과 1개의 빈 자리가 있으며, 3번 티어에는 8개의 디앱과 7개의 빈 자리가 있기 때문입니다.
3.2.1. 티어 설정
티어에 대한 첫 번째 매개변수는 티어의 갯수입니다.
- 티어 갯수
그리고 각 티어마다 별도의 기본 설정 매개변수가 있을 것입니다:
- 디앱의 갯수 : 티어 별 참여할 수 있는 디앱의 수
- 티어 보상 할당 보상량 : 티어에 할당되는 보상의 백분율
이 두 매개변수를 사용하면 티어의 각 디앱이 얼마나 벌어들이는지 계산할 수 있습니다
작은 예를 들어보겠습니다.
- 블록당 인플레이션: 2.5 ASTR
- 디앱 보상을 위한 인플레이션 비율: 20% (즉 디앱 보상에 0.5 $ASTR 할당)
여러 티어가 있고 하나의 티어가 다음과 같은 기본 구성 매개변수를 가지고 있다고 가정해 봅시다
- 디앱의 갯수 = 20
- 티어 할당량 = 10%
단일 디앱이 받는 보상: 0.5 * 0.1 / 20 = 0.0025 ASTR을 블록 당 할당
현재 기준 1 Era는 7200개의 블록을 포함하므로, 해당 티어의 디앱은 1 Era 당 18 $ASTR을 할당받습니다. (이것은 단순한 예시이며 실제 숫자와는 상관이 없습니다)
또한 다음과 같은 추가적인 설정 매개변수를 가질 수 있습니다:
- 최소 TVL (또는 백분율): 특정 티어에 진입하기 위해 디앱이 확보해야하는 $ASTR 디앱 스테이킹 최소 기준.
이러한 임계값을 설정하면, 디앱 보상을 위해 할당된 모든 인플레이션을 모두에게 배분할 필요가 없습니다.
디앱의 티어를 분류하는 방법에는 다양한 아이디어가 존재합니다. 시스템에 유연성을 제공하기 위한 최선의 방법은, 디앱 스테이킹 코어 프로토콜 외부에 그 로직을 두는 것입니다. 필요한 경우 다른 런타임에 대해 서로 다른 티어 분류 함수를 설계할 수 있기 때문입니다.
따라서 티어 배치를 위한 함수는 핵심 매개변수가 될 것입니다.
물론 가장 기본적인 예시는 디앱 스테이킹으로부터 확보한 $ASTR의 TVL을 기준으로 설정하는 것입니다.
또한 특정 티어에 대한 특정 디앱을 화이트리스트로 등록하거나, 강제로 특정 티어에 넣을 수 있는 경우가 있을 것입니다. 초기 프로젝트 부트스트래핑을 위한 방법으로 응용할 수 있을 것이며, 디앱 스테이킹을 효율적으로 활용할 수 있는 방안입니다.
이것을 실현하기 위해 강제 티어 설정 매개변수를 설정하는 방법이 있습니다.
예를 들어, 먼저 특정 프로젝트가 3개월 동안 3번째 티어로 강제로 편입됩니다. 그 기간이 경과하면 강제 티어 매개변수가 제거되고, 기존의 스탠다드를 기반으로 티어 편성이 이루어질 것입니다.
화이트리스트라는 용어가 사용되었지만, 블랙리스트를 도입할 수도 있습니다. 프로젝트를 디앱 스테이킹으로부터 완전히 금지하거나 특정 티어로 제한하는 등의 조치를 취할 수 있습니다. 예를 들어, 특정 유형의 프로젝트는 최대 2번 티어에만 참여할 수 있도록 제한할 수 있습니다.
3.2.2. Era 및 티어 계산
일반적으로 스테이커 보상을 계산하는 것은 개발자 보상을 계산하는 것보다 계산이 쉽습니다. 개발자 보상 계산은 티어 배정에 관계있는 다양한 매개변수에 따라 시간이 많이 걸릴 수 있는 작업일 수 있으므로, 개발자 보상을 덜 빈번하게 (주간 또는 월간) 계산하는 것이 더 나을 수 있습니다.
그렇게 한다면 스테이커들은 현재와 같이 1 Era의 보상을 매일 클레임할 수 있을 것입니다. 그러나 개발자의 클레임 주기는 더욱 길어질 것입니다. 예를들어, 개발자 Era가 7일 동안 지속된다고 가정하면, 현재와 같은 7200* 대신 50400 동안 보상이 축적될 것입니다.
3.2.3. 클레임 관련 정보 추적
청구된 보상의 양과 청구되지 않은 보상의 양을 추적하는 것은 중요한 데이터가 될 것입니다.
일정량의 인플레이션이 디앱 보상으로 할당되지만, 티어 로직을 활용하면 모든 보상이 분배되는 가능성은 매우 낮습니다.
심지어 보상을 매우 오랫동안 청구하지 않는 개발자 및 스테이커도 있습니다.
이러한 값을 쉽게 추적할 수 있다면 체인 상에서 미청구/미사용 보상을 처리하는 것이 가능합니다.
3.3. 투표 기간 및 Build & Earn 기간
디앱 스테이킹 V2에서는 $ASTR 홀더의 스테이킹이 항상 그 Era의 디앱 TVL에 직접 기여하며, 기간의 개념은 없었습니다.
이에 스테이킹하고 잊어버림에 따라, 지원되지 않는 프로젝트에 대한 높은 지분이 스테이킹되는 현상이 발생할 수 있었습니다. 이러한 문제는 V3에서 해결될 예정입니다.
3.3.1. 두 종류의 기간 (투표 기간, Build & Earn 기간)
두 가지 다른 종류의 기간 개념이 도입될 것입니다.
- 투표 기간
- Build & Earn 기간
이 두 기간은 정기적으로 맞물려 돌아갑니다. 예를 들어, 일주일 동안 진행되는 투표 기간 뒤에 11 주 동안 진행되는 Build & Earn 기간이 뒤따릅니다.
(1) 투표 기간
투표 기간 동안 혹은 그 이전에 미리 프로젝트는 스테이커를 유치하기 위한 마케팅 캠페인을 진행할 수 있습니다. 투표 기간 동안에 이루어진 모든 지분은 Build & Earn 기간의 지분과는 별도입니다.
특히 프로젝트는 그 투표 기간 동안 다음 Build & Earn 기간에 무엇을 제공할 것인지 로드맵을 발표하거나 마일스톤을 약속하는 것이 장려될 것입니다. 오히려 투표 기간 + Build & Earn 싸이클 동안 프로젝트는 마케팅 및 프로젝트 활동을 구축하기 위한 기회로 삼을 수 있습니다.
투표는 다음 Build & Earn 기간에만 적용되며, 무기한으로 적용되는 것이 아닙니다.
투표 기간 동안 보상이나 분배는 이루어지지 않습니다.
(2) Build & Earn 기간
Build & Earn 기간 동안, 프로젝트는 개발에 집중합니다. 그리고 프로젝트의 티어에 따라 보상을 받습니다.
Build & Earn 기간에 추가 자본을 스테이킹하거나 오토컴파운딩을 진행할 경우, 투표 기간 동안과는 다른 방식으로 점수에 반영됩니다.
점수 = 투표 기간에서의 스테이킹 + 0.5 * Build & Earn 기간에서의 스테이킹
투표 기간에 더 큰 가중치를 부여하지만 Build & Earn 기간의 스테이킹도 의미를 가져갑니다. 물론 점수는 티어 배치를 위해 사용될 뿐이며, 스테이킹의 지분에 대한 가중치가 변동되는 것은 아닙니다.
3.3.2. 투표 기간 동안 누적된 보상
투표 기간 동안은 스테이커와 개발자 모두 보상을 획득할 수 없습니다. 그 대신, 보상은 충성도 보상 기금 (loyalty reward fund) 에 누적됩니다.
투표 기간에 스테이킹 (투표 행위)을 진행하고, 이후의 Build & Earn 기간 동안 스테이킹을 철회하지 않은 스테이커에 한하여 충성도 보상 기금에 누적된 보상을 청구할 수 있습니다. 즉 본인의 투표 행위에 대한 충성도를 증명한 스테이커에 한하여 추가 보상을 획득할 수 있는 것입니다.
보다 능동적인 스테이커에게 더 많은 보상을 할당하는 것이 목표입니다.
아래는 예시입니다.
투표 기간이 3개 블록 동안 지속되고 Build & Earn 기간이 4개 블록 동안 지속된다고 가정해 봅시다.
투표 기간 동안 생성된 블록에서 할당된 디앱 스테이킹 보상은 extra reward accumulator에 누적됩니다. Build & Earn 기간 동안에는 여느 때와 같이 디앱과 스테이커에 보상이 적립됩니다.
더욱이, 다음을 가정해 보겠습니다.
- 디앱 스테이킹에 단 하나의 디앱이 존재합니다.
- Build & Earn 기간은 4개 블록이 1 Era 입니다.
- 디앱 보상 인플레이션은 1 ASTR/블록입니다.
- 스테이커 보상 인플레이션은 2 ASTR/블록입니다.
- Alice, Bob 및 Charlie가 투표 기간 동안 스테이킹했습니다.
- Bob과 Charlie는 Build & Earn 기간 동안 계속해서 스테이킹을 유지합니다.
- Alice는 Build & Earn 기간 동안 스테이킹의 일부를 철회하였습니다.
블록 1
- Alice는 10 ASTR을 스테이킹
- Bob은 20 ASTR을 스테이킹
- Charlie는 40 ASTR을 스테이킹
- 투표 기간 중이므로, 모든 보상은 Eatra Reward Accumulator에 누적됩니다.
블록 2 ~ 3
- 투표 기간 중이므로, 모든 보상은 Eatra Reward Accumulator에 누적됩니다.
블록 4
- Build & Earn 기간이 시작되고, 디앱과 스테이커에 보상 적립이 시작됩니다.
블록 5
- Alice는 7 ASTR을 철회하였고, 3 ASTR만 스테이킹을 유지중입니다.
- Alice는 더 이상 Extra Reward의 대상이 아니지만, 3 ASTR에 해당하는 스테이킹 보상은 계속 적립됩니다.
블록 6 ~ 7
- Build & Earn 기간의 보상 적립이 지속됩니다.
블록 8
- 새로운 투표 기간이 시작되며, 적립된 보상의 클레임이 가능합니다.
- 먼저, TVL이 고려된 통상 보상이 지급됩니다.
- TVL은 10 + 20 + 40 = 70 ASTR 입니다.
- 스테이커 보상에는 8 ASTR이 적립되었습니다.
- Alice는 10 / 70 * 8 = 1.14 ASTR을 받게 됩니다.
- 그런 다음, 투표 기간 동안 스테이킹한 물량을 Build & Earn 기간 동안 유지한 경우에 대한 추가 보상이 주어집니다.
- Loyalty TVL은 Bob과 Charlie의 스테이킹만 합산한 것으로, 20 + 40 = 60 ASTR 입니다.
- Bob은 20 / 60 * 9 = 3 ASTR을 벌게 됩니다.
하나의 투표 기간 + Build & Earn 사이클이 종료되면, 투표의 수는 초기화됩니다.
About Astar Network
아스타 네트워크는 엔터테인먼트 및 게임 프로젝트를 포함한 다양한 기업 서비스가 일본과 아시아를 넘어 전 세계로 진출하기 위한 게이트웨이 역할을 합니다. 아스타는 폴리곤과 폴카닷을 기반으로 한 크로스 가상 머신을 활용하여 웹3 채택을 가속화하는 맞춤형 블록체인 솔루션을 제공하며, 특히 영지식 증명 기반의 이더리움 레이어2 스케일링 솔루션 (zkEVM), EVM, WASM을 꿰뚫는 혁신적인 생태계를 통해 강력하고 안전하며 상호 운용 가능한 웹3 기술을 선사합니다.
아스타 zkEVM은 영지식 기술을 활용하여 이더리움 상의 웹3 경험을 확장하는 새로운 레이어 2 솔루션입니다. 이로부터 아스타 네트워크는 이더리움에 존재하는 스마트 컨트랙트, 개발자 도구 및 지갑과 원활하게 통합되는 EVM 동등 환경을 가져갑니다.
한국 공식 커뮤니티를 통해 여러분의 의견을 들려주세요. 여러분의 모든 피드백은 생태계 성장에 언제나 큰 힘이 됩니다. 또한 한국 공지채널과 공식 블로그를 통해 다양한 교육자료 및 최신 소식을 전달드리오니 커뮤니티 여러분의 많은 관심 독려드립니다.
Website | Twitter | Discord | Telegram | GitHub | Reddit | YouTube
