안녕하세요 클레이튼 플랫폼에서 월렛 개발을 위해 공부중입니다.
고려해야할 사항으로는 지갑 생성시 개인키를 저희가 직접 관리할 생각입니다.
이 떄, 클레이튼과의 통신을 위한 방법으로 KAS의 사용이 대표적인데, KAS에서 지갑 계정을 생성시 그라운드X에서 관리하는 HSM에 별도로 저장된다고 알고 있어 caver.js 사용을 고려하고 있습니다.
질문은 다음과 같습니다.
caver.js를 사용하여 지갑(keyring 활용)을 생성 하였을경우 KAS 서비스를 일체 사용할 수 없나요?
ex) 컨트랙트 발행, NFT 발행, 메타데이터 업로드 등
caver.js를 사용하여 클레이튼 네트워크에 접근하고자 한다면 EN노드 운영은 필수인가요?
caver.js를 사용해서 KAS의 모든 기능을 구현 가능할까요?(시간과 노력이 많이 들겠지만…)
트랜잭션 수수료 처리 시 대납계정을 사용한다면, 수수료 처리 프로세스가 어떻게 되는걸까요?
ex) 대납계정(그라운드X)에 일정량의 클레이를 넣어두는 계약 체결 후 대납계정을 연동하여 트랜잭션 발생
KAS 의 KIP-17 서비스를 사용하고자 하는 것이 맞으실까요? 만약 그렇다면 caver-js-ext-kas SDK를 사용할 수 있습니다. 하지만 따로 키를 관리하고자 하는 경우 조금 다르게 구성을 해주셔야 합니다.
Klaytn SDK (caver-js) -> `caver.wallet`을 KeyringContainer 사용하여 제공
KAS SDK (caver-js-ext-kas) -> `caver.wallet`을 KAS Wallet Service 사용하여 제공
그렇기 때문에 KAS SDK를 사용하고 싶은데 키 관리를 별도로 구현하고 싶은 경우에는 KeyringContainer를 따로 생성해서 사용해야 합니다. 문서를 확인해 주세요.
만약 KIP-17 서비스를 사용하고자 하는 것이 아니라, 단순히 따로 EN을 운영하지 않고 KAS의 EN에 JSON RPC 요청을 보내고 싶은 경우에는 따로 request의 헤더에 auth를 설정하여 사용할 수 있습니다. 이 리포의 예제들은 모두 KAS EN 연결을 가정하고 있습니다.
헤더 세팅 방법은 각 예제의 run 함수 초기 구현체를 보시면 됩니다.
위에 답변드렸습니다.
caver-js에서 제공하지 않는 기능들은 모두 직접 구현하셔야 합니다. 예를 들어서 caver는 계정 별 트랜잭션 조회 등 블록체인 데이터를 가공해서 관리하는 기능은 제공되지 않습니다. 또한 키 관리의 경우에도 in-memory wallet만을 지원하고 있습니다.
마지막 질문은 조금 이해가 안되었지만 대납에 대해서 간단하게 설명드리겠습니다.
KLAY를 소유하고 있는 계정이라면 대납계정으로 사용할 수 있습니다.
예를 들어서 A, B 계정에 클레이가 충분하게 있는 경우 from: A, feePayer: B 또는 from: B, feePayer: A 모두 가능합니다.
하지만 여기서 B 계정의 특정 키를 수수료 대납할 때에만 사용이 가능하도록 권한을 제한하고 싶은 경우에는 계정의 키를 AccountKeyRoleBased로 업데이트해서 사용할 수 있습니다. (옵셔널)
KAS의 Wallet API에서는 사용자가 트랜잭션을 전송할 때 두 가지의 방법을 제공합니다.
하나는 사용자가 KAS Wallet - fee payer pool에 생성한 수수료 대납자를 사용하는 것과 또 다른 하나는 KAS Wallet에서 제공하는 global fee payer를 사용하는 방법입니다.
만약 KAS의 Wallet API를 사용하지 않고 단순히 수수료대납 트랜잭션을 사용하고 싶은 경우에는 수수료대납에 사용할 KLAY를 충분히 소유한 계정을 만들어서 트랜잭션에 from, fee payer 모두 서명한 뒤 노드로 전송하면 됩니다.
caver-js로 수수료 위임 트랜잭션 생성하고 서명하는 방법은 문서 참고하시기 바랍니다. caver-js-examples 리포에도 다양한 케이스의 예제가 구현되어 있으니 참고하시기 바랍니다.
계정 업데이트에 대한 개념은 Klaytn Docs의 관련문서들을 자세히 읽어보시기 바랍니다.
네 맞습니다. caver는 가공된 데이터는 제공하지 않습니다.
KAS의 KIP-17 서비스만 사용하여 토큰을 배포하고 사용하셔도 문제는 없을 것 같지만 실제 배포한 계정은 KIP-17 서비스에서 관리됩니다.
해당 서비스 기능에 대한 자세한 내용은 문서를 읽어보시거나 카테고리 달아서 별도의 질문으로 문의주시기 바랍니다.
그런 일반적인 월렛의 형태가 아니고 그러한 월렛을 개발하는데 필요한 기능을 제공합니다. address-private key(s) 매핑만 관리합니다. 해당 형태의 월렛은 이러한 SDK 기능을 사용해서 별도로 구현해야 합니다.
넵
바오밥의 경우 별도 EN을 제공하고 있지만 Cypress 메인넷은 별도로 EN이 제공되지 않기 때문에 KAS를 사용하지 않는다면 별도로 EN을 구축해야 합니다.