ABI encoded constructor를 추출하고 싶습니다

https://remix.ethereum.org/?#activate=klaytn-remix-plugin,fileManager&optimize=false&runs=200&evmVersion=null&version=soljson-v0.5.17+commit.d19bba13.js

리믹스에서 사이프레스 카이카스 지갑 계정을 연동 시켰고. 컨트랙트를 컴파일, 디플로이 시켰습니다.

컨트랙트 주소 : 0xd8f44fb168931305acc68cd8181b626a92639ec2
컨트랙트 디플로이 주소 : 0xa437ddacf59630d4506fa2bc4ea5f4b2ea500f9cb49f6cf32fcbc683b3f22c26

이 다음 단계에서 심사를 위해 constructor 인수를 추출할 필요가 있는 것 같습니다.

이를 위해서는 어떻게 해야 하는지 궁금합니다.

  • 컨트랙트 디플로이 때 constructor 실행이 되기 때문에. 토큰 컨트랙트 주소의 컨트랙트 코드 값과 컨트랙트 디플로이의 트랜잭션 인풋값을 비교하여 끝에 추가로 된 값이 constructor의 16진 인코딩 된 값이라 이해했습니다. 하지만, 제가 생각했던 데이터를 찾을 수 없었습니다. 제가 무엇을 잘못하고 있는 것일까요.

안녕하세요, 먼저 제가 질문을 잘 이해하지 못하겠습니다.

  • 어떤 심사를 말씀하시는건지 설명해 주실 수 있나요?
  • 컨트랙트 코드 값과 컨트랙트 디플로이의 트랜잭션 인풋값을 비교한다는게 어떤 의미인지 잘 모르겠습니다. 조금만 더 자세히 설명해 주실 수 있나요?
1 Like

클레이튼 스코프에는 없지만, 클레이튼 파인더에서는 토큰 등록을 위한 제출 폼에서 ABI로 인코딩된 생성자 인수를 요구합니다.

아래 내용은 제출 폼에 적힌 내용입니다.

“ABI로 인코딩된 생성자 인수
컨트랙트에 생성자 인수가 필요한 경우 ABI 16진수 인코딩 형식으로 ABI 인코딩 생성자 인수 필드에 추가합니다. 생성자 인수는 Solidity에 의해 컴파일될 때 계약 소스 바이트코드의 END에 추가됩니다. 이러한 인수를 찾는 쉬운 방법은 트랜잭션 세부 정보의 입력 데이터를 계약 소스 바이트코드와 비교하는 것입니다.
견본
000000000000000000000000000006595656b93ce14834f0d22b7bbda4382d5ab51000000000000000000000000000000000000000000000000d8d726b7177a8000”

이를 해결하기 위해 어떤 일을 해야 하는지 갈피를 못 잡고 있습니다. 도움 바랍니다.

네 그건 remix에서 컴파일된 byte코드와, 배포된 byte코드를 비교해보시면 된다는 의미입니다.
컨트랙트 코드는 remix에서 확인하시면 될거같구요, 배포된 byte코드는 트랜잭션의 raw input data를 확인하시면 됩니다.

확인해 보시면 raw input data 끝부분에 remix에서 컴파일된 바이트코드와 차이나는 부분이 있을텐데요 그부분을 복사해서 finder에 넣어주시면 될것같습니다.

1 Like
  1. 컴파일.

  2. 컴파일 탭에서 constructor와 모든 설정 정보를 상속받은 토큰 컨트랙트에 맞춰두고 좌측하단 Bytecode 클릭.

  3. 코드가 인코딩 된 object를 전부 발췌.

Smart Contract Deploy tx : klaytnfinder

  1. Deploy 트랜잭션의 Input data 탭에서 Original Value에서 처음의 0x를 삭제하여 발췌.

  2. constructor 실행 전 바이트 코드와 constructor 실행 후 바이트 코드를 비교하면 토큰의 이름, 심볼명, 발급량 등의 constructor 내용이 16진 인코딩 추가 돼 있어야 한다.

이렇게 이해하고 있는데, 컴파일 탭의 바이트 코드 오브젝트 정보와 디플로이 트랜잭션의 인풋 데이터가 같게 나옵니다. REMIX IDE의 설정을 찾아봐야 할까요?

똑같으시다면, 작성하신 contract의 생성자에 argument가 없으실것같은데 한번 확인해주세요

1 Like

네, 이해하신 부분이 맞습니다. abi-encoded constructor argument는, Remix로 컴파일 후 얻은 Bytecode와, klaytnfinder의 input data - Original value에서 찾을 수 있는 바이트 코드의 차이나는 부분입니다.

만약 HashEx로 설정한 constructor의 argument 값 및 타입이 모두 정확하다면, 사진상 첨부하신 Encoded data가 윗 차이나는 부분과 동일해야합니다.


++ 클레이튼 스코프에 컨트랙트 코드가 등록되어있어 확인해보니, consturctor의 argument를 넘겨주는 것이 아니라, constructor 내에서 하드코딩으로 값이 설정되어 있네요. 이 경우 argument가 아니기 때문에 둘 차이가 없는 것이 정상입니다.

3 Likes
  1. 컨트랙트 작성 시 컨스트럭터의 세팅값을 외부에서 받아주게 작성 한 후에 컴파일.

  2. 디플로이 버튼 옆의 입력 받을 공란을 채우고.

  3. 컨스트럭터 세팅값을 넣어 트랜잭션을 발생

  4. 디플로이 발생 때 외부 인풋값만 추가로 붙고 이를 확인하여 클레이튼 파인더 ABI 등록폼에 넣는다.

이 구조로 이해 완료 됐습니다.

현재 상태에서 등록을 위해서는

하드 코딩된 인자값이 섞인 컨트랙트는 클레이튼 파인더에 신청할 수가 없는 걸까요.

ABI 제출이 문제군요.

아니요, 해당 부분은 optional 입니다. (constructor argument가 없을 수 있기 때문입니다.) 만약 이미 디플로이 된 컨트랙트를 계속 사용하실 예정이고 등록하시고 싶으시다면, abi-encoded constructor argument 부분은 빼고 제출하시면 될 것 같습니다.

2 Likes

답변에 감사 드립니다. 모두의 도움으로 빠르게 신청하게 되었습니다.

1 Like