- 배포(deploy)관련 파일은 migration 폴더에 생성해준다. 파일이름은 2_deploy_HelloWorld.js로 하겠다.
var hello = artifacts.require("HelloWorld");
module.exports = function(deployer) {
deployer.deploy(hello, "Hello, World!");
}
- 아래 코드에 <CONTENT_OF_ABI>에는 ABI를 입력하고, <CONTENT_OF_BIN>에 ByteCode를 입력하면 배포를
할 수 있다. 하지만 번거롭고 실수할 여지가 많다. truffle을 사용하면 개발자가 이를 신경쓰지 않아도 된다.
- 아래코드는 truffle-config.js의 코드중 일부이다. 배포 타겟을 설정하는 코드로, 아래와 같이 입력하면
로컬 가나슈에 배포하기위한 코드이다.
// 로컬 가나 슈 디폴트 포트와 네트워크 아이디
development: {
host: "127.0.0.1", // Localhost (default: none)
port: 7545, // Standard Ethereum port (default: none)
network_id: "5777", // Any network (default: none)
- 배포 타겟이 여러개이면 아래와 같이 작성도 가능하다고 하는데 일단 넘어가도록 하자.
참고로 rinkeby는 테스트 넷의 이름이다.
- 이제 가나슈를 실행해준다. 가나슈를 실행하면 10개의 테스트 주소를 만들어 준다
위에서 작성한 코드와 같이 로컬서버의 NETWORK ID : 5777, PORT : 7545 임을 알 수 있다.
- 이후 파워쉘을 열어 truffle migrate --network development 를 입력해주면?
- 위와같은 결과가 나오면서 컨트랙트를 배포할 수 있다. 참고로 가나슈를 나가게 되면 초기화가 되기 때문에
사용할 때 마다 배포를 해주어야한다. truffle migrate --network development --reset을 통해 재 배포를 할 수 있다.
- 여기서 계정(Account)이란 20bytes의 16진수 40자리 고정길이이다. 계정에는 두 가지 종류가 있는데
하나는 위와 같은 Contract Address(CA), 하나는 Externally Owned Account(EOA) 이다.
CA는 이더리움에 배포된 컨트랙트 주소이고, EOA는 사람이 소유한 계정(지갑주소) 이다.
이 두 가지는 주소만 놓고 보면 구분할 수 없다.
- truffle은 컨트랙트의 메소드를 직접 실행해 볼 수 있도록 콘솔을 제공한다.
tuffle console --network development를 통해 트러플 콘솔로 이동 할 수 있다.
cf) web3라고 입력하면 지원하는 모듈, 함수등을 알 수 있다.
- 테스트를 위해 var hello = await HelloWorld.at("HelloWorld의 컨트랙트 주소") 를 입력하고 hello.say()로 호출해 본다.
(5.x 버전의 트러플이라 문법이 계속 바뀌어서 고생했다. 4.x 버전에서는 await를 붙이지 않음)
이후 hello.setGreeting 메소드를 사용하여 상태변수 값을 바꿔 볼 것이다.
(sendTransaction은 굳이 붙이지 않아도 됨, 리턴결과만 조금 달라짐)
- 이번에는 앞에처럼 tx 메시지를 호출하지 않고 스토리지에서 바로 메시지를 읽는 방법을 테스트하자.
(web3.eth.getStorageAt("아까 컨트랙트주소")
- 위와같이 16진수로 나오기 때문에 읽을 수가 없다. 이를 아스키코드로 변환하여 읽어보자
(web3.extend.utils.toAscii('위 결과')
- 위와같이 결과가 잘 나오는 것을 볼 수 있다(중간에 느낌표 하나 더 붙여봤음). 하지만 실제로 스토리지에 직접
접근하는 일은 없다고 봐도 된다.
- 위의 테스트들을 보면 'gasUsed'가 있음을 알 수 있다. 이처럼 이더리움은 트랜잭션을 수행하는데 가스비를 내야한다.
이더리움의 스마트 컨트랙트는 EVM(이더리움 가상머신)이 실행하는데, EVM이 컨트랙트의 메소드
즉, ByteCode (OPCode)를 실행하는데 가스를 소비한다. 그렇다면 메소드 실행에 필요한 가스비를 개발자가
미리 알 수 있을까? 그것은 아니다. 하지만 대략의 가스비를 조회해 볼 수 는 있다.
setGreeting으로 상태변수를 "hello Change" 로 바꾸었을 때의 가스비를 조회하면 아래와 같다.
- 가스비는 항상 같은 양이 소모되는 것이 아니라 여러 요소에 의해 달라질 수 있다. 그렇다면 만약 트랜잭션을
수행하는데에 필요한 가스비가 부족하면 어떻게 될까? 메소드 옆에 {gas:gas limit} 를 통해 해당 트랜잭션에서
지불할 가스비의 최대량을 제한할 수 있다.
- 아까 estimateGas로 조회한 가스비는 약 30000이었는데 gas limit을 21000으로 설정하니
base fee가 gas limit를 초과하였다는 문구와 함께 트랜잭션을 수행할 수 없었다.
이후 gas limit을 40000으로 설정해 본 결과 정상적으로 트랜잭션이 수행 되었다.
- 참고로 gas limit을 설정하지 않았을 때의 디폴트 값은 아래와 같은 방법으로 조회 할 수 있다.
- 그런데 지금까지와 같은 방식으로 메소드를 테스트 하는것은 사실상 불가능하다.
그러므로 스마트 컨트랙은 단위 테스트가 반드시 필요하다.
'Block Chain Development' 카테고리의 다른 글
이더리움 기반 Dapp 개발 연습 #6 (로직) (0) | 2022.02.05 |
---|---|
이더리움 기반 Dapp 개발 연습 #5 (Truffle React Unboxing) (0) | 2022.01.31 |
이더리움 기반 Dapp 개발 연습 #4 (단위 테스트) (0) | 2022.01.27 |
이더리움 기반 Dapp 개발 연습 #2 (컴파일) (0) | 2022.01.23 |
이더리움 기반 Dapp 개발 연습 #1 (개발환경 셋팅) (0) | 2022.01.21 |