SUI 스테이킹에 대한, 당신이 아마 모르고 있을 하드코어 지식

저자: Sui Network

SUI 주요 용도

• PoS: 위임 지분 증명 메커니즘에 참여하는 데 사용
• 가스 메커니즘: 네트워크 거래 및 저장 비용을 지불하는 데 사용
• 유동성: Sui 경제에서 체인 상의 원주율 유동성을 제공
• 커뮤니티 거버넌스: Sui의 미래 거버넌스에 영향을 미칠 가능성

스테이킹 프로세스

Q1: 스테이커란 무엇인가요?

Sui 주소를 가진 누구나 선택한 하나 이상의 검증 노드에 SUI를 스테이킹하여 스테이킹을 할 수 있으며, 스테이커에는 SUI를 스테이킹하는 검증 노드 또는 제3자 SUI 보유자가 포함됩니다.

Q2: 스테이킹된 SUI는 어디로 가나요?

안심하세요, 그것들은 귀하의 주소에 안전하게 잠겨 있습니다! 다른 네트워크의 기존 유동성 스테이킹 솔루션과는 달리, 그 솔루션에서는 스테이커가 스테이킹한 토큰의 제어권을 제3자의 유동성 스테이킹 스마트 계약에 넘겨야 합니다. 그러나 Sui는 SUI 보유자가 선택한 검증 노드에 직접 SUI를 스테이킹하면서 스테이킹 토큰에 대한 완전한 제어권을 유지할 수 있도록 합니다. 스테이킹 토큰은 Sui 프로토콜 레이어의 보호를 받으며, 제3자 스마트 계약의 취약성의 영향을 받지 않습니다.

Q3: 스테이킹 풀은 무엇인가요?

각 Sui 검증 노드는 스테이킹된 수량을 추적하고 스테이킹 보상을 누적하기 위해 자신의 스테이킹 풀을 유지합니다. 검증 노드 풀은 각 epoch 경계에서 계산된 환율 시계열과 함께 작동합니다. 이 환율은 과거의 각 SUI 스테이커가 미래에 인출할 수 있는 SUI의 수량을 결정합니다. 중요한 것은, 더 많은 보상이 스테이킹 풀에 입금됨에 따라 환율이 상승하고, SUI가 스테이킹 풀에 입금된 시간이 길어질수록 누적된 보상이 많아진다는 것입니다.

각 검증 노드는 특정 스테이킹 풀에 해당하는 환율 시계열을 가지고 있으며, 스테이킹 풀 객체 내부에서 체인 상에 저장됩니다. SUI 스테이커의 관점에서, 다음의 합의를 통해 스테이킹 가치를 추적할 수 있습니다.

E'시의 SUI = (E 시에 입금된 SUI) * (E'시의 환율 / E 시의 환율)

개념적으로, 스테이킹 풀의 작동 방식은 유동성 풀과 완전히 동일합니다. SUI가 epoch E에 스테이킹 풀에 입금될 때, epoch E의 환율에 따라 유동성 토큰으로 전환됩니다. 스테이킹 풀이 보상을 받을수록 환율이 상승합니다. epoch E'에서 이러한 유동성 토큰의 가치는 더 높아져 더 많은 SUI로 전환될 수 있습니다.

Sui 스테이킹 풀과 전형적인 유동성 풀 간의 유일한 차이점은 Sui에서는 유동성 토큰이 존재하지 않는다는 것입니다. 대신, 글로벌 환율 표가 계산을 추적하는 데 사용됩니다. 이러한 설계의 장점 중 하나는 스테이킹 풀의 모든 SUI가 동일하므로, 그것들이 처음에 새로운 스테이킹으로 입금되었든 스테이킹 보상으로 입금되었든, 모든 SUI가 즉시 스테이킹으로 간주되며 보상이 즉시 복리 계산된다는 것입니다.

스테이킹 풀은 시스템 수준의 스마트 계약(staking_pool.move)이며, Sui 프레임워크의 일부입니다.

Q4: SUI 스테이킹의 발전 과정은 어떤 단계가 있었나요?

스테이킹 v1: [원래 설계, 사용 중단됨]

이 설계는 테스트넷 2단계에서 사용되었으나 현재는 사용 중단되었으며, 두 가지 주요 구현이 제거되었습니다:

• 이전에는 스테이킹 프로세스가 두 단계로 나뉘어 있었습니다. 먼저, 스테이커가 SUI를 입금하면 즉시 잠금된 SUI를 포함하는 StakedSUI 객체를 받습니다. 둘째, epoch가 끝날 때 스테이킹 풀의 환율이 업데이트되면 사용자는 사용자 풀 토큰을 포함하는 Delegation 객체를 받습니다. Delegation 객체는 epoch이 종료될 때까지 기다려야 하며, epoch 내에서는 종료 시기의 환율을 미리 알 수 없기 때문에 전체 epoch 내에서 수집된 가스 수수료의 양에 따라 달라집니다. 이 방법은 epoch 경계에서 매우 많은 거래를 재구성해야 하므로 스테이킹 v2에서 Delegation 객체가 제거되었습니다(아래 참조).
• 이전에는 스테이킹 회수 시 회수된 스테이킹이 대기 스테이킹 상태로 들어가고 epoch 경계가 종료된 후 처리되었습니다. 이렇게 하는 이유는 현재 epoch의 스테이킹 보상이 전체 epoch 내에서 결정되기 때문에, epoch가 여전히 활성화되어 있을 때 종료 epoch 시의 환율을 완전히 예측할 수 없기 때문입니다. 따라서 이 설계는 업데이트된 환율로 회수하기 전에 epoch가 종료될 때까지 기다려야 했습니다. 이러한 상황은 더 이상 존재하지 않으며, 회수는 즉시 이전 epoch의 환율에 따라 처리됩니다.

스테이킹 v2: [현재 메인넷 설계]

두 가지 주요 변화는 다음과 같습니다:

• 스테이킹 풀의 회계가 간소화되었습니다. 이전과 마찬가지로 사용자가 SUI를 스테이킹할 때 이러한 객체는 StakedSUI 객체로 포장됩니다. 그러나 스테이킹 풀은 더 이상 Delegation 객체를 통해 각 사용자의 스테이킹 풀에 대한 상대적 소유권을 구현하지 않습니다. 대신, 회계는 StakedSUI 객체의 타임스탬프(입금이 발생한 시점)와 입금 epoch와 회수 epoch 간의 환율 변화를 통해 직접 이루어집니다. 각 스테이킹 풀의 데이터 구조는 해당 풀의 환율 시계열을 포함합니다. 이러한 환율은 해당 풀의 모든 스테이커의 인출 상황을 결정하는 데 사용될 수 있습니다.
• 스테이킹 회수는 즉시 이전 epoch의 환율에 따라 처리되며, 현재 epoch가 종료될 때까지 기다릴 필요가 없습니다. 회수에는 사용자가 입금한 원래 스테이킹과 이전 epoch까지 누적된 모든 스테이킹 보상이 포함됩니다. 이 방법의 단점은 회수된 epoch 내에서 스테이커가 스테이킹 보상을 받지 못한다는 것입니다. epoch가 종료될 때까지는 현재 epoch 내에서 누적될 스테이킹 보상을 미리 알 수 없기 때문에 회수에 포함할 수 없습니다. 따라서 모든 사용자는 즉시 스테이킹을 회수하고 다음과 같이 받을 수 있습니다:

E'시 회수된 SUI = (E 시에 입금된 SUI) * (E'-1 시의 환율 / E 시의 환율)

스테이킹 v3: [미래 업데이트]

이는 최종적으로 메인넷으로 추진될 장기 솔루션입니다.

스테이킹 v2 설계의 주요 도전 과제는 네트워크 보안에 필수적인 해제 기간(또는 쿨다운 기간)을 처리할 수 없다는 것입니다. Sui가 회수 요청을 처리하는 방식을 수정하여 이를 두 단계로 나누어 구현합니다:

• 첫 번째 거래에서 스테이커는 회수 요청을 제출하고 WithdrawalReceipt를 받습니다. 이때 스테이커는 SUI를 받지 않습니다.
• 두 번째 거래에서 예정된 해제 기간이 지나면 스테이커는 WithdrawalReceipt를 제출하고 그들의 SUI 원금과 누적 보상을 받을 수 있습니다.

중요한 것은, 해제 기간을 활성화하는 것 외에도 이 설계는 사용자가 WithdrawalReceipt를 회수한 후 그들이 받을 모든 보상을 받을 수 있도록 합니다. 회수 요청이 제출된 epoch가 종료될 때 회수가 이루어져야 하기 때문입니다. 이 설계는 스테이킹 v1에서 발생했던 매우 큰 재구성 거래의 문제를 피할 수 있습니다. WithdrawalReceipt 객체는 언제든지 교환할 수 있으며(해제 기간이 끝난 후), epoch 경계에 의존하지 않습니다.

Q5: 내 스테이킹 입금 요청은 언제 효력이 발생하나요?

스테이킹 입금 요청이 제출되면 즉시 스테이킹 풀의 대기 상태로 들어갑니다. Sui 지갑은 사용자 계정의 모든 대기 스테이킹 입금 요청을 반영합니다. 그러나 대기 스테이킹 입금 요청은 요청이 있는 epoch가 종료될 때까지 효력이 발생하지 않습니다.

Q6: 내 해제 스테이킹 요청은 언제 효력이 발생하나요?

해제 스테이킹 또는 회수 요청이 접수되면 즉시 처리됩니다. 스테이커는 처음 입금한 SUI와 이전 epoch 경계까지 누적된 모든 스테이킹 보상을 받게 됩니다. 다시 말해, 현재 epoch의 스테이킹 보상은 포함되지 않습니다. 이 구현에 대한 더 자세한 내용은 스테이킹 v2를 참조하십시오. 향후 스테이킹 v3가 구현되면 해제 스테이킹 요청은 즉시 처리되지 않을 것입니다.

Q7: 각 검증자 풀의 환율은 어떻게 계산되나요?

각 검증 노드 풀의 환율은 각 epoch 경계에서 다음과 같이 계산됩니다:

E+1 시 환율 = (1 + (E 시 스테이킹 보상 / E 시 스테이킹 금액)) * (E 시 환율)

중요한 것은, epoch E 동안 스테이커가 얻는 스테이킹 보상은 해당 epoch 내에서 검증 노드 풀이 얻는 총 스테이킹 보상의 하위 집합이라는 것입니다. 다시 말해, 검증 노드 풀이 얻는 총 스테이킹 보상은 누가 얻었는지에 따라 세 가지 독립적인 부분으로 나눌 수 있습니다:

스테이킹 보상 = 스테이커 보상 + 검증 노드 수수료 + 저장 기금 보상

일반 SUI 스테이커는 스테이커 보상만을 받습니다. 한편, 검증 노드는 이러한 보상에 대한 수수료(검증 노드 수수료)와 저장 기금에 귀속되는 보상을 받습니다.

검증 노드 풀의 환율은 스테이커 보상의 금액을 통해서만 업데이트되어 SUI 스테이커가 얻는 보상을 완전히 추적할 수 있습니다. 그러나 이 계산 방법은 Sui가 업데이트된 환율을 통해 추가 StakedSUI 객체의 형태로 검증 노드 수수료 및 저장 기금 보상을 검증 노드에 제공하여 검증 노드가 얻는 보상을 추적할 수 있게 합니다.

Q8: 제3자 SUI 보유자와 비교하여 검증 노드의 스테이킹 프로세스는 어떻게 다른가요?

프로세스는 동일합니다. SUI를 함께 스테이킹하는 검증 노드는 해당 검증 노드와 함께 스테이킹하는 모든 제3자 SUI 보유자와 동일한 프로세스를 따릅니다.

Q9: SUI 스테이커와 비교하여 검증 노드의 스테이킹 보상 계산은 어떻게 다른가요?

주어진 검증 노드 스테이킹 풀에서 모든 스테이커는 풀의 환율 상승을 통해 동일한 비율의 보상을 얻습니다. 또한, 검증 노드는 스테이킹 관리에서 수수료와 저장 기금 보상을 얻기 때문에, 검증 노드는 각 epoch 종료 시 이러한 금액의 비율에 따라 추가 StakedSUI 객체를 받습니다.

스테이킹 보상

Q1: 스테이킹 보상은 어디서 오나요?

스테이킹 보상은 현재 epoch 내에서 얻은 거래 가스 수수료와 epoch 종료 시 방출되는 스테이킹 보조금에서 나옵니다.

스테이킹 보상 = 스테이킹 보조금 + 가스 수수료

스테이킹 보조금은 네트워크 초기 단계에서 보조금을 제공하기 위해 설계되었으며, 자금 출처는 10%의 SUI입니다. 이 분배가 소진되면 스테이킹 보상의 전체는 일반 네트워크 운영을 통해 수집된 가스 수수료로 구성됩니다.

Q2: 스테이킹 보상은 자동으로 복리 계산되나요?

네! 위의 "Q3: 스테이킹 풀은 무엇인가요?"의 답변을 참조하십시오.

Q3: 메인넷에서 얼마나 많은 스테이킹 보상이 있을까요?

스테이킹 보상은 가스 수수료와 스테이킹 보조금으로 구성됩니다. 각 epoch 분배의 총 금액은 다음과 같이 결정됩니다:

• 스테이킹 보조금: 각 epoch 분배의 금액은 epoch 시작 전에 예정된 시간표에 따라 결정됩니다.
• 가스 수수료: 각 epoch의 금액은 전체 epoch 내에서 얻은 총 가스 수수료에 따라 달라집니다. 각 Sui 거래는 실행된 가스 단위와 가스 가격이라는 두 변수에 따라 가스 수수료를 지불합니다:

가스 수수료 = 가스 가격 * 가스 단위

수집된 가스 수수료 총액은 epoch 내에서 처리된 모든 거래의 가스 수수료 총합에 해당합니다. 일반적인 시장 조건에서 우리는 대부분의 거래의 가스 가격이 기준 가스 가격과 같을 것으로 예상합니다. 향후 Sui는 네트워크가 혼잡할 때 가스 가격이 기준 가스 가격보다 높아지도록 혼잡 가격 책정 메커니즘을 도입할 것입니다. 이는 사용자가 실제로 검증 노드에 우선권을 위해 팁을 주기 때문입니다.

스테이킹 제한

Q1: 활성 검증 노드의 스테이킹에서 일부를 해제할 수 있나요?

지원하지 않습니다. 각 StakedSUI 객체의 해제는 전부 해제하거나 해제하지 않거나 둘 중 하나입니다.

그러나 사용자는 임의의 수의 SUI 객체를 어떤 검증 노드에 스테이킹할 수 있습니다. 따라서 그들이 한 검증 노드에서 일부 SUI 객체의 스테이킹을 해제하면, 실제로 검증 노드에서 일부 스테이킹을 해제할 수 있습니다. StakedSUI 객체는 여러 객체로 나눌 수 있으므로, 스테이커가 먼저 하나의 StakedSUI 객체를 여러 객체로 나눈 후 일부 객체의 스테이킹을 해제하면, 스테이커는 항상 효과적으로 일부 스테이킹을 해제할 수 있습니다.

Q2: 단일 검증 노드의 최소 스테이킹 금액은 얼마인가요?

최소 스테이킹 금액은 1 SUI입니다.

Q3: 검증 노드의 스테이킹과 합의에서의 투표권은 어떤 관계가 있나요?

관례상, 스테이킹 금액에 관계없이 총 투표권은 항상 10,000이며, 법정 문턱은 6,667(2/3 비율)입니다. 각 검증 노드의 합의 투표권은 그들의 스테이킹에 비례하지만, 예외가 있습니다: 단일 검증 노드의 투표권 상한은 1,000(총 투표권의 10%)입니다.

Q4: 단일 검증 노드의 최대 스테이킹 금액은 얼마인가요?

제한이 없습니다. 그러나 합의에서 단일 검증 노드의 투표권은 10%로 상한이 설정됩니다. 만약 검증 노드가 총 스테이킹의 10%를 초과하면, 해당 검증 노드의 투표권은 10%로 유지되며, 나머지 투표권은 나머지 검증 노드 집합에 분산됩니다.

유사하게, 검증 노드의 스테이킹 보상 비율도 동일한 10% 상한을 사용하여 스테이킹 관리 금액을 계산합니다(참조: 스테이킹 보상 계산). 다시 말해, 검증 노드가 총 스테이킹의 10%를 초과하면, 각 스테이킹의 SUI 보상은 감소하기 시작합니다. 왜냐하면 스테이킹 풀이 더 이상 그들이 얻는 스테이킹 보상의 수량을 증가시키지 않기 때문입니다.

스테이킹 보상 계산

참고: 공식이 너무 많으니, 관심 있는 분들은 신중하게 읽어보시기 바랍니다.

검증 노드

Q1: 기준 가스 가격이란 무엇이며, 검증 노드는 언제 참여해야 하나요?

Sui의 설계는 최종 사용자가 일반 네트워크 운영 중에 가스 가격을 안정적이고 예측 가능하게 유지할 수 있도록 합니다. 이는 각 epoch 시작 시 검증 노드가 네트워크의 기준 가스 가격을 설정함으로써 이루어집니다.

운영적으로 이는 "가스 가격 조사"를 통해 이루어지며, 단계는 다음과 같습니다:

• 각 epoch E 동안 각 검증 노드는 다음 epoch E+1의 최적 기준 가스 가격을 제출합니다.
• epoch 경계에서 Sui가 epoch E에서 epoch E+1로 전환될 때, 네트워크는 검증 노드 집합의 가스 가격을 관찰하고 2/3 지점에서 투표 가중치를 기준으로 다음 epoch의 기준 가스 가격을 설정합니다. 따라서 각 epoch의 기준 가스 가격은 전체 epoch 동안 일정하며, epoch 변경 시에만 업데이트됩니다.

가스 가격 조사 제출 과정은 매우 간단합니다. 각 검증 노드는 자신의 기준 가스 가격을 포함하는 객체를 가지고 있습니다. 검증 노드가 자신의 제안을 변경하고 싶다면, 해당 객체의 값을 업데이트하기만 하면 됩니다. 검증 노드는 자신의 작업 능력 객체를 양도하여 가스 가격 제안 설정 능력을 다른 계정에 위임할 수 있습니다.

Q2: 통계 규칙은 어떤 형태이며, 검증 노드는 언제 참여해야 하나요?

Sui의 설계는 검증 노드 집합의 커뮤니티 모니터링을 장려하고 강제하기 위해 고안되었습니다. 이는 통계 규칙을 통해 이루어지며, 각 검증 노드는 다른 모든 검증 노드를 모니터링하고 평가하여 모든 사람이 효율적으로 운영되도록 하며, 네트워크의 최선의 이익을 고려합니다. 비준수 검증 노드는 벌금을 부과받고 그들의 스테이킹 보상이 삭감됩니다.

프로토콜은 epoch 경계에서만 전역 통계 규칙 점수를 계산하도록 규정하므로, 검증 노드의 적극적인 모니터링에 의존하여 다른 검증 노드의 행동 변화가 감지되면 점수를 변경합니다. 일반적으로 통계 규칙의 기본 옵션은 모든 검증 노드의 점수를 1로 설정해야 하며, 운영 부적합이 확인될 때만 0으로 변경해야 합니다. 실제로 통계 규칙은 각 검증 노드가 소유한 객체 집합으로 구성되며, 이 객체의 기본 점수는 1입니다. 따라서 검증 노드는 일반적으로 필요할 때만 다른 검증 노드와의 점수에 해당하는 객체를 업데이트합니다. 가스 가격 제안 제출과 유사하게, 검증 노드는 자신의 작업 능력 객체를 양도하여 통계 규칙 참여 권한을 다른 계정에 위임할 수 있습니다.

Q3: 검증 노드가 통계 규칙에서 0점을 부여받는 기준은 무엇인가요?

통계 규칙은 사회적 균형을 통해 시행되어야 합니다. 검증 노드 집합은 스스로를 적극적으로 모니터링해야 하며, 만약 어떤 검증 노드가 명백히 성과가 좋지 않다면, 다른 검증 노드는 해당 검증 노드에 0점을 부여하고 그들의 보상을 삭감해야 합니다. 향후 Sui 네트워크가 성숙해짐에 따라, 우리는 커뮤니티가 검증 노드의 성과를 추적하기 위한 공개 대시보드를 시작할 것으로 예상하며, 이는 검증 노드 운영에 대한 추가적인 신호로 활용될 수 있습니다.

Q4: 여러 검증 노드에 0점을 부여할 수 있나요?

가능합니다. 통계 규칙을 통해 각 검증 노드는 다른 모든 검증 노드에 점수를 부여하며, 각 검증 노드가 제출할 수 있는 0점 또는 1점의 수에 대한 제한은 없습니다.