티스토리 뷰
Gas? |
트랜잭션을 발행하는 노드는 트랜잭션에 Gas라는 수수료를 포함시킨다.
이 트랜잭션을 수신한 노드중 채굴 노드가 만약에 블록 채굴에 성공했고 그 블록에 방금 수신된 트랜잭션을 포함시켰을 경우에 그 트랜잭션에 들어있던 수수료인 Gas를 채굴 보상으로 받게 되는것이다.
채굴자는 기본급(기본 채굴 보상) + 인센티브(그 블록에 포함된 트랜잭션들에 들어있는 수수료인 Gas) = 총합 Ether를 채굴 보상으로 받게 되는 것이다.
트랜잭션을 발행할때, 스마트 컨트랙트를 한줄 한줄 실행할때 모두 Gas가 필요하다.
solidity 언어로 작성된 스마트 컨트랙트는 EVM(Etherium Virtual Machine)위에서 작동한다.
엄밀히 말하면, 이 언어가 solidity 컴파일러로 번역되면 solidity 바이트코드로 변환되는데 이것이 블록체인에 저장되고, 그 바이트코드를 EVM이 한줄한줄 인터프리터 방식으로 실행시키는것이다.
이 바이트 코드 중에서는 덧셈,뺄셈,곱셈,나눗셈 부터 시작해서 레지스터에 저장,빼오기 등 다양한 연산이 있을텐데 이 연산 하나하나를 실행시킬때마다 일정량의 Gas를 소모하게 된다.(이것은 스마트 컨트랙트를 실행시킨 노드가 지불해야하는 수수료다)
Gas는 왜 필요한가? |
이더리움은 트랜잭션의 발행 수수료로써 가스(Gas)라는것을 사용한다. 이것은 결국에 소량의 이더와 맞먹는 가치를 지닌다.
수수료가 필요한 이유?
만약 이더리움에 수수료의 개념이 존재하지 않는다고 해보자. 그렇게 되면 스마트 컨트랙트를 짜는 개발자들이 코드의 최적화를 위해서 신경쓰지 않을것이다.
그렇게 될 경우 같은 기능을 가진 함수를 실행시키는데 시간이 더 걸린다거나 메모리를 더 쓴다거나 할 수 있다.
네트워크에서 스마트 컨트랙트를 실행시키는 트랜잭션의 처리 속도가 느려질 것이다.
Gas라는 수수료가 있기 때문에 코드를 최적화해서 짜게끔 유도하고 있는것이다.
또한, 스마트 컨트랙트를 실행시키는데 무료로 쓸 수 있을경우 악의적인 공격자가 무한 반복 기능을 가진 스마트 컨트랙트를 블록체인에 넣고, 모든 P2P네트워크의 노드들이 그 무한 반복 코드를 실행하게끔 할 수 도 있을것이다.
왜 이더리움이 수수료를 송금량의 일정 퍼센트로 정하지 않고 가스라는것을 도입했을까? 이렇게 할 경우에 더 관리가 쉬울텐데? -> Gas Price를 설정해서 블록에 포함될 트랜잭션의 우선순위를 정할 수 있기 때문
Gas Limit |
Gas Limit이라는것은 쉽게 말하자면 다음과 같다. 내 자동차인 K5로 서울에서 부산으로 가야한다. 연료통의 크기가 1000이라고 해보자. 근데 서울에서 부산까지 가는데 연료가 400정도 들것이라고 예상이 간다. 하지만, 딱 400만 넣고 갔다가 괜히 중간에 연료가 바닥나면 곤란하니까 600정도 넣고 간다고 해보자. 이때 이 600의 양이 Gas Limit이다. 다시말해서 내가 아무리 많이 써도 600의 가스까지는 쓸 의향이 있다는 뜻이다. 가스 소모의 상한?정도로 받아들이면 될듯.
내가 만약에 어떤 스마트 컨트랙트를 실행시키려고 하는데, 그 스마트 컨트랙트에서 가스를 400만큼 쓸것 같다고 예상이 간다. 근데 그렇다고 진짜 Gas 400으로 스마트 컨트랙트를 실행시키려고 했을때 만약에 그 스마트 컨트랙트에서 실제 사용한 가스가 402였다고 했을때 이 스마트컨트랙트는 가스가 모자라서 실행시키지 못한 연산이 있기 때문에 여태 실행했던 실행흐름을 스마트컨트랙트 실행전 상태로 초기화 시켜버리며, 가스는 환불해주지 않는다.
그럼 그냥 400의 가스는 날라가고 스마트 컨트랙트는 실행되지 못한것과 마찬가지가 돼버린다.
하지만 만약 Gas 600으로 스마트 컨트랙트를 실행했을 경우 실제 그 계약에서 가스 샤용량은 402이므로 나머지 198의 가스가 남게 되는데, 이것은 다시 환불이 된다.
그럼 가스는 어차피 환불 되기 때문에 Gas Limit은 무조건 높게 잡는게 좋을까? 아니다.
Block Gas Limit |
|
Block Gas Limit 이라는것은 하나의 블록이 포함할수 있는 가스의 총량을 의미한다. 하나의 블록에는 여러개의 트랜잭션이 포함될수 있다. 하나의 트랜잭션에 포함된 GasLimit은 보통 21000정도인데, Block Gas Limit은 보통 470만 정도 된다. 다시말해서 트랜잭션 470만/2만 = 약 트랜잭션 224개를 하나의 블록에 포함시킬수 있다는 의미이다.
위에서 말한 질문에 대한 답을 해보겠다. 가스 리밋은 무조건 높게 잡는게 좋을까?
-> 가스 리밋을 적당하게 높게 잡으면 어차피 사용되지 않은 나머지는 환불되기 때문에 웬만한 상황에선 좋으나 Block Gas Limit이라는 개념이 있기 때문에 블록이 포함할수 있는 Gas Limit을 초과시키는 트랜잭션은 채굴자가 그 트랜잭션을 블록에 포함시키지 않을 것이다. 만약에 Block Gas Limit이 100인데, 내가 발행한 트랜잭션의 Gas Limit이 90이라고 해보자. 그리고 그 블록에 이미 100중 40의 가스가 차있다고 했을때, 내가 발행한 트랜잭션은 그 블록에 포함될수 없게 되고, 그렇게 될 경우 다음 또는 그다음 블록 채굴할때 포함되기까지 트랜잭션풀에서 펜딩된 상태로 대기해야 한다.
-> 한마디로, Gas Limit은 너무 낮게도 너무 높게도 하지 않고 적당하게 높게 잡아야 좋다고 할 수 있다.
-> 그래야 빠른 시간에 내 트랜잭션이 블록에 포함 될 수 있을것이다.
이더리움은 블록을 약 15초마다 1개씩 생성하게끔 채굴 난이도가 자동 조절된다. 근데 요즘 15초에 트랜잭션이 224개가 아니라 엄청 나게 많은 트랜잭션이 발행되기 시작했다. 그래서 블록 가스 리밋을 늘리자는 투표가 있었고 현재는 블록 가스 리밋이 670만가스 정도 된다고 한다. 다시 말해서 하나의 블록에 더 많은 트랜잭션을 담을 수 있게 되었다는 뜻이다.
Q.Gas Limit은 그래서 왜 필요한가?
A.Block Gas Limit개념이 필요하기 떄문에 Gas Limit이 필요한것 같다.
블록에 너무 여러개의 트랜잭션을 포함시켜버리면 채굴자들이 한번에 너무 많은 보상을 받게 될 것이다. 따라서 적정량의 트랜잭션을 포함할수 있게끔 해야 하는데 그 값을 조절할수 있는것이 바로 Block Gas Limit이다. 트랜잭션당 적절한 Gas Limit이 존재하므로 이 Block Gas Limit이 의미가 있는것이다.
Gas Price |
가스 가격은 1Gas당 가격(wei)이다. 이 가스 가격이 높게 책정된 트랜잭션일 수록 마이너들이 트랜잭션풀에서 트랜잭션을 빼서 블록에 담을때 높은 우선순위를 갖게 된다. 같은 트랜잭션인데 가스 가격이 10인것과 1000인것중에서 1000인것이 좀더 빨리 블록체인상에 등록 될 것이다.
송금 트랜잭션의 수수료는 최소 21000가스를 사용해야 하는데, 가스 가격이 2.2*10^10wei일 경우
21000 * 2.2*10^10wei = 4.62*10^14wei가 된다.
10^18wei = 1ether이므로 이것은 대략 0.000462 ether가 된다.
그러니까 만약 5이더를 송금하고 싶으면 내가 가진 이더가 최소 5.000462는 되어야 한다는 뜻이다.
채굴자가 트랜잭션을 블록에 포함시켜준 대가로 받는 보상은 그 트랜잭션의 Gas Price * Gas Limit이다.
Gas Limit은 적당히 높게 잡는게 좋고 Gas Price도 적당히 잡는게 좋다. 가스 가격이 높은 경우 내 트랜잭션이 더 빠르게 블록에 등록 되겠지만 그만큼 내 이더를 더 사용해야 한다. 그렇다고 가스 가격을 너무 낮춰서 트랜잭션을 발생시킨경우 내 트랜잭션은 다른 트랜잭션들에게 우선순위가 밀려 어떤 마이너도 내 트랜잭션을 블록에 포함시키려 하지 않을 수도 있다.
이제 이것이 조금 해석이 될 것이다.
Gas Limit
내가 이 트랜잭션에 최대 320만 가스까지 사용하겠다.
Gas Price
1Gas당 20Gwei(2*10^10wei)를 지불하겠다.
Max Transaction Fee
내가 발행하려고 하는 트랜잭션의 총 수수료
20Gwei * 320만 = 0.064이더 이다.
cf) 1ether = 10^18 wei
Max Total
트랜잭션 수수료 + 송금 이더(이더 전송에 필요한 총 금액)
만약에 5이더를 송금했었다면 5.064이더가 Max Total이 되었을 것이다.
(현재는 0이더송금)
'컴퓨터 공학과 졸업 > 블록체인' 카테고리의 다른 글
전자서명 (0) | 2018.02.11 |
---|---|
블록체인 처리 흐름 (0) | 2018.02.04 |
블록체인 FAQ (2) | 2018.01.15 |
블록체인의 거래 정보 변경 불가 (0) | 2018.01.15 |
블록체인의 이중지불 문제 (0) | 2018.01.15 |
- Total
- Today
- Yesterday
- reflow
- hydrate
- atomic design
- typescript
- return type
- useEffect
- await
- react hooks
- state
- javascript
- mobx
- Babel
- rendering scope
- es6
- async
- type alias
- Polyfill
- storybook
- design system
- computed
- server side rendering
- Next.js
- reactdom
- reducer
- useRef
- Action
- react
- webpack
- props
- promise
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |