안녕하세요.
아래는 KAS쪽에 문의한 내용인데 KAS측에서 이곳에 문의해보는게 좋을 것같다고 하여 문의드립니다.
[아래]
KIP17토큰은 소각하게 되면 0x00000… 지갑으로 이동하고
Burn을 하였을 때 0x0000…으로 이체되는것을 이해가 되지만
0x00000…의 지갑의 PirvateKey를 알고 있는 Klaytn 쪽에서 KIP17에 대한 토큰을 임의적으로 이체할 수 있을거라고 생각되어 사용자 입장에서 문제가 될것처럼 생각됩니다.
정리하면
burn을 하고 burn한 토큰ID를 Mint요청했을 때 0x0000…에서 이체가 되는 프로세스가 맞나요?
0x00000…의 지갑을 임의로 조작하여 탈취할 수 있나요?? (보안성 문제)
이렇게 2가지 입니다.
감사합니다.
안녕하세요 먼저 이해가 안가는 문구가 있어서 질문드립니다.
소각한 Token ID를 Minting 하였을 때 오류가 아닌 0x00000…으로 이체가 되는것이 이해가 되지 않습니다.
문맥상 소각한 Token ID를 민팅하면 0x000… → ToAddress를 의미하시는게 맞나요?
그리고 0x000… 주소는 Null 주소라고 생각하시면 됩니다.
해당 주소를 public key(0x000…)라고 했을경우 해당키에대한 private key를 구하실 수 있다면 말씀하신대로 해당 주소에 대한 권한을 갖습니다.
하지만 현재 processing power대비 암호체계의 복잡도를 생각하면 불가능에 가깝습니다. 그리고 해당 private key는 클레이튼도 마찬가지로 알지 못하며 그래서 소각의 주소로 사용되고 있다고 보시면 될 것 같습니다.
1 Like
@jack_jin
답변 감사합니다
우선 헷갈리게 해드린점 죄송합니다.
샘플 Tx 인데 해당 Token ID를 발급하고 burn하고 나서 다시 같은 Token ID로 Mint요청한 결과입니다.
1 Like
@jack_jin
안녕하세요. 테스트하면서 궁금한게 생겨 문의드립니다
테스트링크 를 보시면 Token ID 5번이 신규로 발급하고 burn한 토큰입니다.
burn 호출하고 성공하였고 To Address로 0x0000…(Null 주소)로 transfer가 되는것도 확인하였습니다.
@ToTheMoon 소각되었을때 Holder로 보이지 않으면 가장 좋을거 같긴한데요, 어차피 해당 Holder의 NFT balance체크를 해보시면 갯수는 3개가 아닌 2개로 표시됩니다.
제가 tokenId를 이용해 ownerOf( )함수를 호출해 보았을 경우 1~4까지는 잘 되는데요, 5번에서는 에러가 발생하네요, 이 에러부분은 잘 정제되어서 리턴되면 더 좋을 거 같다는 생각이 듭니다. 한번 github에 이슈등록해보시는건 어떠세요 ㅎㅎ?
제가 해보았을 때 발생하는 에러는 아래와 같습니다. 추상적인 에러긴 하네요…
klaytnscope는 제가 알기로는 다른 방식으로 데이터를 가져오기때문에 실제 caver-js를 이용해 가져오는 데이터와 차이가 있을 수 있는데요, 현재 app을 개발하시는 입장에서 소각된 NFT가 최근 Holder에게 유지가 되고 있다는 걱정은 우선은 안하셔도 될 것 같습니다.
1 Like
@jack_jin
답변감사합니다
Pepper
June 20, 2022, 5:54am
7
여기에 new issue 버튼 누르고 등록해주시면 감사하겠습니다.
1 Like
