위의 두 트랜잭션을 비교해보면 하나는 TX type 이 Fee Delegated Smart Contract Execution 으로, 다른 하나는 Legacy Transaction 으로 표기됩니다.
동일한 KIP37 규격인데 후자의 Legacy Transaction 은 Input data 값이 64바이트 더 깁니다.
설명서상에선 kip 37과 1155가 큰 차이가 없다고 하는데 두 트랜잭션의 input data가 달라지는 특별한 이유가 있나요?
이러한 질문을 드리는건 아래 두 TXID와 같이 동일한 컨트랙트를 대상으로 트랜잭션을 발생시켰을때 legacy는 성공하고 그렇지 않은 경우는 실패해서 그렇습니다.
0x36108794e248c3b7e97b22845a502e3358d988c1bfc2bb81c476bf58e4aa27b1
0x51f6640cd6a3ad2645cf2fb9c37961d5f270ba3fcd67f00dd90d800e6bc0d9fc
안녕하세요.
우선 첨부해주신 두 Tx의 인풋값은 서로 다릅니다. 동일한 함수를 실행시켰다고 하더라도 From 주소가 다르기 때문입니다.
어떤 함수를 어떻게 실행하셨는지 등의 상세 맥락 정보를 공유해주실 수 있을까요?
From 주소가 달라서 Revert 가 난 것은 아닌지도 확인해보셔야 할 거 같아요.
ERC1155(KIP-37)의 safeTransferFrom 을 사용했습니다.
해당 메소드의 인자값은 {“name”:“from”,“type”:“address”},{“name”:“to”,“type”:“address”},{“name”:“id”,“type”:“uint256”},{“name”:“amount”,“type”:“uint256”},{“name”:“data”,“type”:“bytes”} 로써 input data의 값이 순서대로 함수 해시값 / 보내는 주소 / 받는 주소 / 보내는 토큰아이디 / 보내는 수량 / 기타 데이터 입니다.
이때 기타 데이터의 값이 특별한 값이 아닌 0일 경우 이더리움의 ERC-1155에서는 ‘00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000’ 가 붙고, 클레이튼 예제 문서에 등록된 바오밥 예제에서도 마찬가지의 값이 붙어있습니다.
그런데 제가 링크를 단 컨트랙트의 경우 이 뒤의 data 가 컨트랙트에 따라 어떤것은 뒤에 128바이트의 값(0 64개) 가 더 붙어서 ‘00000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000’ 이 붙어야만 정상적인 인풋데이터라고 판단합니다.
KIP-37로 등록된 컨트랙트의 safetransferfrom 함수 사용내역을 뒤져본 결과 tx type이 변경되었을때 외에는 64바이트가 더 붙는 차이를 발견할 수 없었습니다. from 주소가 달라서 발생하는 문제는 아니라고 봅니다.
안녕하세요.
트랜잭션을 전송하실 때 어떻게 전송하셨는지 코드를 공유해주실 수 있을까요?
그리고 정상적인 인풋데이터라고 판단한다는 게 어떤 말씀이실까요?
Revert 여부를 말씀하는 걸까요?
KIP37 컨트랙트 로직 상에서 뒤에 붙는 data로 전송 가능여부를 검증하는 부분은 별도로 존재하지 않기 때문에
뒤에 나오는 부분의 바이트가 더 긴지 짧은지 여부는 중요한 요소가 아니라는 생각이 듭니다.
최초에 공유해주신 아래 두 트랜잭션의 경우도 input data를 보면 전송하는 토큰 아이디는 동일한데 value가 다릅니다.
0x36108794e248c3b7e97b22845a502e3358d988c1bfc2bb81c476bf58e4aa27b1
0x36108794e248c3b7e97b22845a502e3358d988c1bfc2bb81c476bf58e4aa27b1
from: 0x54A8F36ce75BEFFA028ABE5B5332aA4330d5b454
to:0x796f2c1a2D12dEeF4179677F707aD362B2e50f1C
id: 1
value: a
0x51f6640cd6a3ad2645cf2fb9c37961d5f270ba3fcd67f00dd90d800e6bc0d9fc
0x51f6640cd6a3ad2645cf2fb9c37961d5f270ba3fcd67f00dd90d800e6bc0d9fc
from: 0x796f2c1a2D12dEeF4179677F707aD362B2e50f1C
to: 0x54A8F36ce75BEFFA028ABE5B5332aA4330d5b454
id: 1
value: 1
제 생각엔 잔고가 0xa (=10진수로 10개) 보다 적은데 10개를 전송하려 해서 에러가 나는 것으로 생각이 드는데요, 이 부분도 확인부탁드려요.