들어가며

이 글은 Klaytn에 대해 사전 지식이 있는 개발자를 대상으로 작성하였습니다.

Kaia v1.0.0 테스트넷 ‘Kairos’가 출시되었다. 이 글에서는 Kaia에 새롭게 추가된 기능을 살펴본다.

“기술적인 관점에서는 Klaytn 네트워크를 기반으로 Kaia 체인이 작동하는 형태.” - 토큰 스왑 안내

위 언급된 것처럼, 기존 Klaytn 네트워크에서 특정 블록넘버를 기준으로 ‘하드포크’하는 형태로 Kaia 네트워크로 전환된다. 즉, Klaytn chaindata는 유지된다.

PR: Klay -> Kaia in RPC

PR: Klaytn -> Kaia in comments

위 스크린샷들을 통해 새로운 Kaia 네트워크는 기존 Klaytn 소스코드를 기반으로 만들어진 것을 알 수 있다.

이제부터 Kaia에 새롭게 추가된 3개의 기능에 대해 알아본다.

Priority tip

해당 기능은 간단히 말해 EIP-1559가 카이아 네트워크에 완전히 구현한 것이다.

기존 클레이튼에는 baseFee 기능만 제공하고, TIP은 0으로 고정되어 있었다.

스팸 Transaction을 막기 위한 목적으로 도입되었다

이제 카이아에서는 EIP-1559와 동일한 Type:2 트랜잭션을 만들 수 있으며 Tip순으로 펜딩 트랜잭션이 정렬된다.

기존 legacy tx나 klaytn type tx는 gasPrice 필드가 그대로 effectiveGasPrice로 적용된다. 따라서 tip = gasPrice - baseFee가 된다.

getTotalSupply(blockNumber)

Add klay_getTotalSupply API PR을 통해 구현되었다.

참고로 Geth에도 Supply delta live tracer 비슷한 기능이 추가되었다.

기존에는 아래와 같은 API를 통해 정보를 얻을 수 있었으나, 이는 KAS 서비스의 API 일부로써 GroundX에 의해 자체적으로 제공되는 기능이었다.

$ curl https://klay-api.klaytnapi.com/v1/total-supply
5964547725.012343

이제는 JSON-RPC를 통해 특정 블록 시점의 KAIA 공급량을 조회할 수 있다.

> klay.getTotalSupply('latest')
{
  burntFee: "0x28ee933736fa159f39364",
  deadBurn: "0x40bea489f3f8944d93efbd",
  kip103Burn: "0x111d0449fb2a238eca3b1720",
  kip160Burn: "0x0",
  totalBurnt: "0x116051d7b8918bc471c29a41",
  totalMinted: "0x24971a118ccfd6cbe4800000",
  totalSupply: "0x1336c839d43e4b0772bd65bf",
  zeroBurn: "0x0"
}

type SupplyManager interface {
	Start()
	Stop()
	GetTotalSupply(num uint64) (*TotalSupply, error)
}

type TotalSupply struct {
	TotalSupply *big.Int // The total supply of the native token. i.e. Minted - Burnt.
	TotalMinted *big.Int // Total minted amount.
	TotalBurnt  *big.Int // Total burnt amount. Sum of all burnt amounts below.
	BurntFee    *big.Int // from tx fee burn. ReadAccReward(num).BurntFee.
	ZeroBurn    *big.Int // balance of 0x0 (zero) address.
	DeadBurn    *big.Int // balance of 0xdead (dead) address.
	Kip103Burn  *big.Int // by KIP103 fork. Read from its memo.
	Kip160Burn  *big.Int // by KIP160 fork. Read from its memo.
}

PR에서 위 구조체를 확인 가능하다.

for lastAccRewardBlockNumber < CurrentBlock {
  // 누적 작업
}
logger.Info("Total supply big step catchup done")

sm.chainHeadSub = sm.chain.SubscribeChainHeadEvent(sm.chainHeadChan)
for {
  select {
  case <-sm.quitCh:
    return
  case head := <-sm.chainHeadChan:
    // 누적 작업

  }
}

계산 로직도 확인 가능하다.

Public Delegation

기존 클레이튼에서는 GC가 아닌 일반 사용자가 클레이튼의 컨센서스에 참여하기 위해서는 SKlay 등의 서드파티 기능을 사용해야 했다.

카이아에서는 PublicDeligation을 지원한다. Kaia 진행 상황 및 기능 업데이트 글을 통해서도 확인 가능하다.

1. PublicDeligation 직접 해보기

하드포크를 통해 156660000 블록부터 Baobab 테스트넷이 ‘Kairos’ 테스트넷으로 전환되었다. - 참고

LineNext Public Delegated KAIA를 접속하면 현재 테스트넷의 PublicDeligation Contract와 상호작용이 가능하다. 위 UI를 통해 PublicDeligation의 한 사이클을 진행해보자

Staking

klaytnscope

1 KAIA를 스테이킹하고 0.986389 LineNext-pdKAIA를 받았다.

Reward

> maxWithdraw(address)
1000000183872229967

> maxWithdraw(address)
1000000220280861781

Scope UI를 통해 호출 가능하다.

maxWithdraw 함수를 호출하면 받을 수 있는 보상 KAIA의 수량을 확인 가능하다. 함수를 호출할 때마다 결과가 증가하고 있다. 이는 고정된 pdKAIA 토큰에 대해 KAIA의 교환비율이 증가하는 구조임을 의미한다.

Withdraw

klaytnscope

출금신청과 동시에 즉시 pdKAIA는 소각되고, 출금될 KAIA 수량은 확정된다.

주의해야할 부분은, withdraw() 함수는 실제 ‘KAIA 출금’이 아니다는 점이다.

• withdraw() 함수를 통해 출금 신청 (이때 pdKaia는 즉시 소각된다)
• 7일이 지난 후에 claim()을 통해 실제 자산 인출(D+7)
• 그러나 추가적으로 7일이 지나면 (D+14) 해당 요청이 만료

‘출금신청’에 대해서는 아래 CnStakingV3 부분 에서 한번 더 언급한다.

2. Contract 간단히 살펴보기

PublicDelegation.md 내용을 잠시 소개하겠다.

Public Delegation은 General User가 자신이 소유한 KAIA를 Kaia Governance Council(GC)에 delegate 하거나 redelegate 할 수 있는 non-transferable ERC-4626 기반의 Contract입니다. GC는 CnStakingV3MultiSig(CnSV3)를 사용하며 Public Delegation을 활성화합니다.

Contract는 delegator에게 pdKAIA라는 토큰화된 주식(shares)을 발행합니다. pdKAIA는 위임된 모든 KAIA에서 delegator의 몫을 나타내는 비양도성 이자 지급 토큰입니다. 보상이 복리로 누적됨에 따라 pdKAIA와 KAIA의 교환 비율이 증가합니다. 위임자는 pdKAIA를 소각하여 KAIA를 다시 받을 수 있습니다.

PublicDelegation.constructor()

pdKAIA 토큰을 생성하는것을 확인 가능하다.

PublicDelegation.stake()

주석을 통해 확인 가능하다. (커미션 비율은 commissionRate 변수에 저장되어있다)

Public Delegation 함수에 value transfer 트랜잭션을 제출해도, 스테이킹이 동작한다는 것을 확인 가능하다.

PublicDelegation.withdraw()

PublicDelegation.claim()

기간 초과 때문에 실패할 경우 pdKAIA가 발행되며, 다시 출금신청 후 7일을 기다려야 한다.

CnStakingV3

CnStakingV3.md 내용을 살펴보자.

Kaia 거버넌스 위원회(GC)의 구성원은 최소한 하나 이상의 CnStaking Contract를 소유해야 합니다. 현재까지 세 가지 버전의 CnStaking이 있습니다.

• [deprecated] legacy/CnStakingContract (CnSV1): Klaytn 메인넷이 시작된 이후로 사용됨
• CnStakingV2 (CnSV2): V1의 모든 인터페이스를 포함하고, 새로운 거버넌스 관련 기능이 추가된 CnSV1의 업그레이드 버전입니다.
• CnStakingV3MultiSig (CnSV3): V2의 모든 기능과 새로운 PublicDelegation 기능이 추가된 CnSV2의 업그레이드 버전입니다.

CnSV3 Contract에는 두 가지 Operation Mode가 있습니다:

• PublicDelegation 비활성화: 이 모드에서는 CnSV2와 동일하게 작동합니다.
• PublicDelegation 활성화: 일반 사용자가 KAIA를 CnSV3에 위임할 수 있습니다.

지금까지 소개한 내용들을 통해 스테이킹한 실제 KAIA를 가지고 있는 컨트랙트는 CnStakingV3 컨트랙트라는것을 이해 가능하며, “출금 신청 후 7일 ~ 14일 제한” 로직은 CnStakingV3에 구현된 로직임을 이해 가능하다. (PublicDelegation Contract에는 관련된 로직이 없다)

마치며

현재 테스트넷에서 Bughole, LineNext 와 같은 KAIA의 새로운 GC들을 확인 가능하다.

GC 목록은 AddressBook 컨트랙트를 통해 확인 가능하다.

abook.md 참고

예를 들어 위와 같이 LineNext GC의 Address를 조회 가능하다.