[Klaytn] 대(신)납(부) 기능 (feat. Fee Delegated)

 Klaytn 대학(원)생 간담회에 참석을 하고, Klaytn에 대한 소개를 들었을 때.

가장 관심이 있었던 부분은 수수료에 대한 부분을 누군가 대신납부 할 수 있다는 것이였다.

많은 게임 업체 혹은 서비스 업체들이 이더리움 대신 이오스를 택하는 것이 대부분 '수수료'의 문제라고 생각하기 때문이다.

 

Klaytn Private Testnet이 종료 되고, Public Testnet인 Baobab(배오뱁!)이 시작 되었기 때문에

실제로 '대납'이 어떻게 이루어지는지 간략하게 정리 해보자!

 

https://docs.klaytn.com/klaytn/enterprise_proxy#necessity-of-enterprise-proxy

 

Klaytn Docs에 위 기능이 필요한 이유가 영어!로 서술 되어 있다.

처음 이 기능에 대한 이야기를 들었을 때는 별다른 고민 없이 'SmartContract를 작성 할 때, 무언가 추가 하겠군.' 이라고 생각했지만

사실 유저의 Transaction에 Service Provider가 대신 서명을 하여 Transaction을 제출 하는 형태였다.

 

기존 생각

- SmartContract에 Fee Delegate 에 대한 코드 추가

 

실제 동작

- (1) Service User가 트랜잭션에 서명 -> (2) Service Provider가 해당 트랜잭션을 다시 서명하여 제출

 

https://docs.klaytn.com/api/toolkit/caverjs/caver.klay#sendtransaction-fee_delegated_value_transfer

 

Klaytn Docs API탭에 보면 FEE_DELEGATED 시리즈를 확인 할 수 있다.

모든 예제를 다 할 수는 없기에 이번 글에서는

Transaction Type 중 'FEE_DELEGATED_VALUE_TRANSFER'만 다루어 볼 생각이다.

 

[1 Step] 정상적인 유저의 송금

FEE_DELEGATED가 이루어지려면, 당연 User의 정상적인 송금이 이루어져야 한다.

    // Normal Transfer 
  transfer = async () => {
    const userPrivateKey = '0xb83edaf89879b3c615bb6019af65313984812aa94dce7ca5b5d8abef899c1141';
    const userAddress = '0x22Bd0365568F9266810A69a2b90f36064148042D'

    // (1) Add User Private Key
    cav.klay.accounts.wallet.add(userPrivateKey)
  
    // (2) Create Transaction
    const transaction = {
      type: 'VALUE_TRANSFER',
      from: userAddress,
      to: '0xe99D1d10d8CB255a7ce9fAeF69c6B9C8e8b8343C',
      gas: '300000',
      value: cav.utils.toPeb('0.01', 'KLAY'),
    }
  
    // (3) Send Transaction
    cav.klay.sendTransaction(transaction)
    .on('transactionHash', console.log)
    .on('receipt', async (receipt) => {
      const newAccountBalance = await cav.klay.getBalance(userAddress)
      console.log(newAccountBalance);
    })
    .on('error', console.log)
  }

 

 위의 코드는 정상적인 User 송금이다. 실행하게 되면 Klaytn Scope에 해당 Transaction이 성사된 모습을 볼 수 있다.

 

https://baobab.klaytnscope.com/tx/0xb6a7f82ec22e0999837719d5f8753371501b097018cffad595cd67d25255746e

[2 Step] Fee Payer와 함께하는 유저의 송금

 // Fee Delegated Transfer
  feeDelegatedTransfer = async () => {
    const feePayerPrivateKey = '0xb83edaf89879b3c615bb6019af65313984812aa94dce7ca5b5d8abef899c1141';
    const feePayerAddress = '0x22Bd0365568F9266810A69a2b90f36064148042D'
    const userPrivateKey = '0xda97fa897322ae70245eec9b3db873126eacc426b0e70327f3e9dd2fca3b8d57'
    const userAddress = '0xe99D1d10d8CB255a7ce9fAeF69c6B9C8e8b8343C'
    
    // (1) New Wallet Private Key
    cav.klay.accounts.wallet.add(userPrivateKey)

    // (2) Create Transaction (User Transaction)
    const transaction = {
      type: 'FEE_DELEGATED_VALUE_TRANSFER',
      from: userAddress,
      to: '0x22Bd0365568F9266810A69a2b90f36064148042D',
      gas: '300000',
      value: cav.utils.toPeb(0, 'KLAY'),
    }

    // (3) Create rawTransaction
    const { rawTransaction: senderRawTransaction } = await cav.klay.accounts.signTransaction(transaction, userPrivateKey)

    // (4) Create Fee Delegated Transaction
    const feePayerTransaction = {
      type: 'FEE_DELEGATED_VALUE_TRANSFER',
      feePayer: feePayerAddress,
      senderRawTransaction: senderRawTransaction,
    }

    // (5) feePayer(EnterPrise Account) Send Transaction
    cav.klay.accounts.wallet.add(feePayerPrivateKey)

    cav.klay.sendTransaction(feePayerTransaction)
    .on('transactionHash', console.log)
    .on('receipt', async (receipt) => {
      console.log(receipt)
    })
    .on('error', console.log)
  }

 

(2) Create Transaction (User Transaction)

- 기존 송금과 달리 Transaction Type이 변경 되었다. (VALUE_TRANSFER -> FEE_DELEGATED----)

 

(3) Create rawTransaction

- 기존 송금 예제에서는 SignTransaction을 호출 하지 않았다. sendTransaction에서 처리해주었기 때문이다.

 

(4) Create Fee Delegated Transaction

- User의 서명이 들어간 rawTransaction을 이용하여, 새로운 Transaction을 만든다. (Docs 예제에서는 chainID, nonce 등을 설정해주기도 하지만 선언해주지 않아도 자동적으로 입력되는 것을 확인할 수 있다. 다만, 구현할 Service에 필요에 따라 수정되어야할 것 이다.

 

(5) feePayer(EnterPrise Account) Send Transaction

- 일반 송금과 동일하게 sendTransaction을 호출한다. 다만, user의 입장에서 Transaction을 보내는 것이 아닌 서비스 혹은 대신 납부해줄 사람이 Transaction을 발생시킨다.

 

일반 User 계정 / From 은 대납자가 아닌, User로 유지되고 있는 모습

Transaction을 조회하면 Tx Type이 Fee Delegated Value 로 되어있다. 일반 계좌 조회로 보면 Value Transfer / Transaction 조회로 보면 Fee Delegated 로 조회 된다. Klaytn Scope의 의도인지는 잘 모르겠다. 

 

예제를 통해 정리된 것

 

(1) 정상적인 rawTransaction을 가지고 와서 대신납부는 불가능 하다. (Transaction Type이 다르기 때문)

 

(2) balance가 0인 계좌에 대한 대납은 불가능 하다.

> Klaytn의 개발자 분들께 문의를 드린 상태이고, 개선 될 것인지. 아닐지는 아직 모르겠다.

> 하지만, 대(신)납(부)라는 것이 Klaytn의 장점인 만큼 이 부분은 개선될 것이라 생각된다.

> 기존 balance가 0인 (신규 계좌 혹은 돈이 없는 계좌) user도 서비스를 이용할 수 있기 때문에..

 

(3) 대신납부에도 Type이 여러가지 있다.

> FEE_DELEGATED_VALUE_TRANSFER

> FEE_DELEGATED_VALUE_TRANSFER_WITH_RATIO

> FEE_DELEGATED_VALUE_TRANSFER_MEMO

> FEE_DELEGATED_VALUE_TRANSFER_MEMO_WITH_RATIO

 

(4) 대신납부에 대한 어뷰징 관리는 서비스에서 처리 해야한다.

> 현재 balance가 0인 계좌는 대납이 애초에 불가능 하지만, 개선 여부와 관계 없이 어뷰징 방지는 해야 한다.

> 혹은 feeRatio를 통해 일정 부분 유저가 부담하는 방법이 있다.

> n개의 블록 당 n번 횟수 제한에 대한 것을 docs 에서 확인 한 것 같은데..? 이런 방법을 사용할 수도 있을 것 같다.

 

 아직 테스트넷이여서 많은 것들이 변화 될 수 있겠지만, Klaytn의 대표적인 기능이라고 할 수도 있는? Fee Delegate를 공부해보았다.

많은 기능들이 있어 천천히 살펴보아야할 것 같다.

분명한 것은 서비스 제공자의 입장에서는 많은 메리트가 있을 것 같다.

 

그럼 20000!

 

---

Contract 호출도 실행해보았는데. Transfer와 크게 다르지 않았습니다.

혹시나, 다른점을 확인해보고 싶으시다면 참고하시면 될 것 같습니다.

(다음글) [Klaytn] Contract Execution (feat. Fee Delegated)