Front-end 에서 await caver.rpc.klay.signTransaction( … )을 통해 FeeDelegatedSmartContractExecution 트랜잭션을 생성하고, Back-end로 전송했는데, Exception 처리 되는 case가 있었습니다.
(Exception이야 제가 수정하면 되는 것이니 문의 드릴 내용은 아닌데요)
이 때, Kaikas 지갑에서는 한번에 하나의 트랜잭션만 가능하다면서 기존 실패된 트랜잭션을 취소하라고 알림이 떠서 취소를 했는데요, klaytnscope (baobab)에서 조회를 하면 체인에 올라가지도 않은 TX HASH가 Cancel 되었다는 이력이 조회가 됩니다.
제가 만든 것들이 올리지는 않았을 것이니 KAIKAS에서 취소 한 내용이 올라간 것 같은데요,
- 이 때, 각 Cancel Transaction들마다 붙어 있는 TX FEE(KLAY) 0.000525 들은 보유 KLAY에서 차감이 되는 것인 지 문의 드립니다.
- Front-end에서 API 요청이 실패되는 경우, KAIKAS의 Transaction 취소를 할 수 있는 방법이 있는 지 문의 드립니다.
해당 문제는 Kaikas 팀에 문의드려야 할 것 같습니다.
현재 Kaikas 개발팀은 별도의 고객센터를 운영하고 있으니, 공식 고객센터를 통해서 질문을 하시는 것이 더 빠른 답을 얻으실 수 있을 것으로 예상합니다.
아래 링크를 참고하세요.
문의 등록 – Kaikas (zendesk.com)
감사합니다.
안녕하세요 @relician
우선 1번의 경우, 엄연히 Cancel Transaction을 사용자 계정으로 발생시키는 것이기 때문에 Klay 수수료를 부담하는게 맞습니다.
이렇게 구현되어있는 이유를 간단하게 설명드리자면, fee delegation tx같은 경우 Kaikas 서명 후 DApp에서 fee payer로 서명하기 위해 들고 있고 Kaikas 입장에서는 이걸 하염없이 기다리고 있는 상황이기 때문에 (그렇다고 그 사이 Kaikas에서 다른 서명을 해버리면 nonce가 꼬일 수 있음) 혹시 DApp이 계속 처리를 안 해주면 명시적으로 Cancel tx를 날려서, 나중에 예상치 못하게 tx가 들어가는 걸 방지하기 위함입니다.
또, 2번의 경우는 Kaikas 트랜잭션 내역에서 취소버튼을 눌러주시면 되겠습니다.
감사합니다.
Front-end가 FeeDelegatedSmartContractExecution 트랜잭션을 생성하고
sender 서명을 하기 위해 Kaikas를 통해 SignTransaction 하면,
Kaikas가 대기하는 건 이해가 됩니다.
그런데 FeePayer 서명을 하는 과정에서 체인 네트워크로 send 하지도 못했는데,
(일종의 DApp 장애로 tx가 체인 네트워크로 올라가지 않은 상황이겠지요.)
Cancel tx를 날리는 수수료를 DApp이 아닌 DApp User가 내야 한다는 것이 이해가 되지 않습니다.
이것을 클래이튼 기반 DApp에 있어서는 상당히 큰 위험 요소가 될 것이라
인식하는 것은 제가 너무 예민한 것일까요?
말씀하신 것처럼 사용자가 취소 수수료를 부담하는 것은 불합리합니다.
하지만 이처럼 DApp에서 제대로 처리를 해주지 않는 상황에서 DApp에 취소 요청을 하는 것은 그 결과를 보장받기 어렵고, 결국 확정적으로 해당 tx를 무효화시키 위한 방법은 그 사이 계정의 nonce를 올리거나 Cancel Tx를 날리는 방법 밖에 없다고 생각됩니다. 그렇지 않으면 이 tx는 “언제 실행될지 모르는” 상태로 계속 DApp이 보유하게 됩니다.
물론, 말씀주신 대로 취소 수수료에 대한 불만이 발생하겠지만, 이러한 불만이 누적되는 DApp 서비스라면 애초에 fee delegation에 대한 처리가 미진한 서비스로, 자연스럽게 유저에게 외면받지 않을까…라는 생각을 해봅니다…
