본문 바로가기

BlockChain/클레이튼

Klaytn 클레이튼 스마트계약과 탈중앙앱 - 블록체인 상태와 트랜젝션

728x90

이 글은 `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의를 보고 개인적으로 정리한 글입니다.

블록체인의 상태

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

(어카운트 기반) 블록체인의 상태를 예로 들어보자.

블록체인은 트랜젝션으로 변화하는 상태기계라 할 수 있다. 상태기계의 경우 항상 초기값(i)이 있고 그리고 최종값(f) 을 가진다. 초기값 (i) + change = 최종값 (f) 라고 보면 편할 것이다.

 

블록 0 번을 보면 최초값 i 는 none 으로 시작한다. 그리고 change 를 기록하게되는데,  엘리스에게 토큰 100개를 주었다고 기록한 뒤 최종값 f 에 엘리스에게 100 개의 토큰이 있다고 기록한다.

 

블록 1 번을 보면 블록 0 번의 최종값을 초기값 i 로 가지고 있는것을 볼 수 있다. 즉, 블록 1번에 초기값에는 엘리스가 100 개의 토큰을 가지고있다는 내용이 있는 것이다. 여기에 변경사항이 들어갈 것이다. 예를들어 엘리스가 밥에게 30 개를 보낼때, 누군가 블록을 생성했을때 받는 보상인 coinbase 로 엘리스에게 100 개의 토큰이 부여되며, 최종 결과로 엘리스는 토큰170 개 밥은 30 개를 블록 1 번에 기록하게된다. 참고로 이해를 돕기위해 여기서 수수료는 생각하지 않았다.

즉 초기값은 이전블록의 상태이고 최종값은 현재블록의 상태이며 이러한 변경값들이 트랜젝션이라고 할 수 있다.

 

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

 


 

Transaction

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

이더리움이 관리하는 상태라는 것은 어카운트들의 상태를 말한다.

즉, 블록체인의 상태는 어카운트들의 상태를 모아놓은 것이라 말할 수 있다.

그런데 스마트컨트렉트는 특정 주소에 존재하는 실행가능한 프로그램이다. 프로그램이란 것은 일반적으로 명령어와 상태를 갖는다. 그리고 일반적으로 프로그램이란 것을 코드(함수/기능)와 데이터(실행을 위한 상태들)로 분류하기도 한다. 

즉, 스마트컨트렉트는 프로그램이기 때문에 상태가 필요하고 이를 어카운트로 사용한다.

External Account 와 Contract Account 의 가장 큰 차이점은 프로그램을 만들고 이것을 기록할 수 있는것은 External Account 밖에 없다. 때문에 Contract Account 는 스스로 TX 를 만들어 내지 못하는 수동적인 특성을 가지고 있다.

 

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

트랜젝션의 목적은 그렇다면 블록체인의 상태를 변경하는 것이라 할 수 있다.

To(Recipient) 가 누구인지에 따라 TX 의 목적이 달라진다.

  • Sender 가 External Account(사용자) 이고 Recipient 또한 External Account 인 경우 -> 보통의 토큰전송인 경우
  • Sender 가 External Account(사용자) 이고 Recipient 가 Contract Account 인 경우 -> Contrac 의 실행인 경우
  • Recipient 가 지정이 되지 않은 경우 -> 새로운 Contract 를 배포하는 경우

이더리움의 경우 마이닝하는사람들이 GAS 비를 많이 내는사람들의 TX 를 먼저 처리해준다.

클레이튼은 GAS 에 따른 차별보다 단순히 네트워크가 빠르면될것이라 생각하게 되었다. 때문에 클레이튼에는 TX 를 보낼때 GAS 를 따로 내지 않고 먼저 낸 사람이 먼저 처리된다.

 


Transaction 과 서명

 

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

 트랜젝션을 만들어 보내는것에 비용이들 경우 만약 다른사람이 자신의 어카운트로 트랜젝션을 보내면 손해가 발생할 수 있다. 그래서 특정 어카운트를 사용해 트랜젝션을 보내기위해서는 어카운트로 검증할 수 있는 서명을 함께 보낸다.

따라서 트랜젝션은 항상 서명과 함께 보내진다. 이 서명의 검증 과정은

  • 노드가 트랜젝션을 받아서 얼마만큼의 GAS 가 필요한지 확인한다.
  • Sender 를 확인해서 어카운트에 그만큼의 balance 가 있는지 확인한다.
  • balance 가 충분하면 노드가 기다리고 있다가 블록에 넣을 수 있는 시점에 넣는다.
  • 블록에 들어가 모두에게 브로드캐스트(TX 가 체결) 되면 그때 GAS 를 차감한다.

서명을 확인하는 방법으로 비트코인의 경우 TX 에 Sender 의 주소 , Sender 의 퍼블리키 , Sender 의 서명이 들어가 있다. 퍼블리키를 가지고 주소를 뽑았더니 서명이면 인정하게 된다. 이때 Size 가 약 160 bit + 32byte + 32byte + 알파 만큼 커진다. 이더리움의 경우 네트워크 비용을 최소화하기위해 Sender 의 주소를 넣지않고 서명만 넣는다. 대신 서명에서 공개키를 도출할 수 있는 함수를 넣어 서명에서 공개키를 뽑아내고 공개키로 주소가 만들어지면 그 주소가 실제로 존재하는 주소면 인정하게된다.(존재하지 않는 주소는 블록체인 상태에 기록이 안되어있기에 허점은 없다) 그런데 여기서의 이슈는 연산량이 늘어난다. 이더리움의 성능이 안좋다라고 말하는 것이 서명에서부터 공개키를 도출하는 함수때문(약 30%비중의 성능 영향을 준다.)이기도 하다. 

클레이튼은 이더리움을 기반으로 만들어진 것이다. 이더리움에서 합의 알고리즘을 바꾸고 TX 처리를 바꾸며 성능을 높인것이 클레이튼이다. 또한 이더리움 기반으로 만들어졌지만, 클레이튼의 경우 TX 에 비트코인처럼 주소를 포함시켰다.

 


 

블록체인과 트랜젝션

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

트랜젝션은 일반적으로 위와같이 생겼다. TX 을 또 보내는 것을 방지하기위한 nonce 라는 개념은 어카운트 기반 블록체인들의 특징이다. 때문에 어카운트들은 Sequence 하게 움직일 수 밖에 없다. 이는 블록체인의 병렬화를 막는 원인이다. 누군가가 비트코인은 병렬화가 가능하지만 이더리움은 그렇지 않다고 말한다면 바로 nonce 를 얘기하는 것이다.

from 은 Sender 의 주소, to 는 Recipient 의 주소 , value 는 몇개의 토큰을 전송하는지에 대한 숫자이다.

 

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

위에서 언급했듯이 이더리움의 경우 from 이 없다. 또한 gas 가 있고 gasPrice 가 있다. gas * gasPrice 가 사용자가 트랜젝션을 실행하기위해 지불할 비용이다. 그리고 이러한 비용이 balance 에 없으면 실행하지 않는다. 

v , r , s 가 서명이다. v 값은 식별자로 사용되며 엄밀히 따지면 서명은 r , s 이다.

 

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

이더리움과 다르게 위에서 언급했듯이 from 이 존재한다. 또한 어떤용도의 트랜젝션인지 알려주는 type 정보가 있다. 이더리움의 경우 type 이 없기에 to 가 누구인지 확인하기 전까지는 어떤용도의 트랜젝션인지 알 수 없다.(토큰전송, 컨트렉트실행, 컨트랙트배포) 

클레이튼은 gasPrice 가 고정되어있고 이를 사용자가 임의로 변경하게 된다면, TX 를 거절한다. 내부적으로 gasPrice 를 25stone 으로 고정시켰는데, 이는 value transfer TX 를 실행했을때 정확히 클레이로 0.000525 클레이만큼 사용하게된다. 이 값은 1클레이로 약 200회정도 실행할 수 있는 값이다. 이 값을 정한 이유는 이더리움의 gas 비의 10분의 1 미만으로 설정되게끔 정해놨다. 이러한 고정 값은 전체 노드들이 합의하면 변동될 수 있다.

 


 

트랜젝션의 이동경로

TX 은 External Account 만 만들 수 있고, 보낼 수 있다.

이것을 참고해 트랜젝션의 이동경로를 살펴보자

User 가 TX 를 만든다 -> Node 에 전송한다. -> Node 는 블록에 TX 를 넣기 위해 노력하며 블록에 들어가는 순간 User 에게 Receipt 라는 영수증을 준다. Receipt 는 TX 가 실행되었고 TX 가 실행된 결과를 알려주는 값으로 정말 유용한 자료가된다. 즉, Receipt 를 통해 TX 가 블록에 언제 들어갔는지(Receipt 의 status 값이 1이면 성공) 확인가능하다.

출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료
출처 : `인프런 - Klaytn 클레이튼 스마트계약과 탈중앙앱` 강의 자료

Receipt 의 경우 Contract 를 배포할때 유용하게 사용될 수 있다. Contract 를 배포하고 나면 Contract 가 어느 주소에 배포되었는지 Receipt 에 기록된다.

 


 

728x90