brunch

You can make anything
by writing

C.S.Lewis

by SKKRYPTO Nov 15. 2018

Bitcoin#7: Coinbase 와 우선순위

블록 구조 (3편)

결국 모든 비트코인은 보상, 즉 생성 거래(Coinbase transaction)로부터 시작했다.

이전 글을 통해 '거래의 과정'을 살펴봤을 때 utxo들이 꼬리에 꼬리를 물고 연결되어 있는 형태에서 항상 시초로 올라가게 되면 생성 거래가 utxo의 시작이 된다. 생성 거래는 곧  비트코인 프로토콜 상 주어지는 보상이다. (필자는 '생성 거래'라는 단어보다 'coinbase transaction'이라는 표현을 더 좋아하기에 이후에 나오는 생성 거래를 'Coinbase Tx'라고 표기하겠다.)


Coinbase Tx는 ‘채굴자’가 ‘본인 주소로’ ‘채굴 중인 블록의 높이에 맞는 보상액 + 블록에 담은 거래들의 수수료’를 설정 한 거래다. 


다음과 같은 거래를 채굴자가 직접 생성하여 본인이 만들고 있는 블록에 함께 담아 채굴에 성공할 경우, 보상과 거래들의 수수료를 얻게 되는 것이다. 즉, 분산화된 환경에서 보상과 수수료를 채굴자에게 주어지는 과정은 이러한 과정을 통해서 진행되는 것이다.


50BTC의 보상으로 시작한 비트코인 블록체인은 21만 블록마다 반감기를 지니고 있다. 이러한 방식을 고려하여 계산하였을때, 2140년쯤 20,999,999.98BTC가 총 발행량이 될 것으로 예상된다. 즉, 총 발행량이 정해져있지 않으며, 프로토콜상 최대 발행량을 예측할 수 있다. 하지만 왜 '고정된'이 아닌, '최대' 발행량일까?


재밌는 사실이, 이기적인 채굴자가 coinbase tx의 금액을 실제 채굴 중인 블록의 높이를 고려한 정확한 보상을 책정하지 않고 그보다 높게 설정하였을 경우, 해당 블록을 전파하여 노드들이 검증할 때 해당 블록은 검증에 실패하게 된다. 하지만 반대로, 실제 보상보다 적게 설정한 coinbase tx는 페널티가 부여되지 않고 있다. 실제로도 이미 ‘보상금액’에 맞지 않은 coinbase tx들이 발행이 되었고, 그에 따라 사토시 나카모토가 반감기를 고려하여 설계한 총 비트코인 발행량은 예상보다 적게 형성된다는 사실을 알 수 있다. 


즉, coinbase tx는 비트코인 프로토콜이 허락하는 특별한 생성 거래다.


거래가 input과 output으로 형성되는 utxo모델은 항상 '소유권 이전'을 통해 소비가 되는 형태였다. 그렇다면 다음과 같은 의문이 들 수 있다.

coinbase tx는 누구의 소유권을 옮기는 것인가?


coinbase tx는 소유권 이전을 위해 입력값(Input)으로 ‘본인의 소유권을 해제’, 즉 해제 스크립트(scriptSig)를 넣지 않는다. 즉, coinbase tx 입력값(input)이 비어있게 된다. coinbase tx는 이러한 비어있는 input값에 코인베이스(coinbase)가 들어가게 된다. 


538695번째 블록 coinbase tx


CoinBase

Coinbase는 coinbase tx (생성 거래)의 입력값(input)이다. 

coinbase를 통해 채굴자들은 다양한 활동을 이어나갔다.


1. 블록의 높이를 인코딩하여 추가하였다. 

실제로 ‘블록의 높이’는 별도의 공간에 저장되지 않고, 블록 헤더 해시가 블록의 고윳값을 나타내었지만, coinbase에 블록의 높이를 추가하기 시작하였다.


2. 추가 nonce 공간

채굴 과정에서 난이도 상승에 의한 추가 nonce 공간이 필요하였고, 채굴자들은 이 공간을 이용하기도 하였다.


3. 문자열 삽입 (ASCII 변환)

실제 277316번째 블록의 코인베이스를 살펴보자

277316번째 블록의 coinbase


coinbase의 16 진법 값인 03443b0403858402062f503253482f 의 값을 살펴보자


'03'는 다음 3바이트를 스크립트 스택 올리라는 의미이다.

'443b04'는  블록 높이 '277316'을 인코딩한 값이다.

'0385840206' 은 추가 넌스를 위해 사용하였다.


그렇다면 마지막 '2f503253482f'는 무슨 문자열을 포함하고 있을까?


코인베이스를 통한 문자열 삽입은 흥미로운 사용 중 하나이다. 채굴자들은 비트코인 프로토콜 변경 투표에 있어서 해당 공간을 이용하여 진행하기도 하였다. 위 해당 코인베이스를 해독한 값 중 "/P2SH/" 를 살펴볼 수 있다. 즉, 2f503253482f 는위 사진에서 확인할 수 있듯이 /P2SH/ 를 ASCII 변환한 값이다.


실제로 BIP0016에서 거래 script 구조 중 하나인 P2SH 도입을 제안하였고 해당 제안의 찬성 여부를 coinbase에 투표를 진행하였다. /P2SH/ 는 BIP0016과 BIP0017중 BIP0016을 지지한다는 표시를 한 것이며 BIP0017 지지를 한 채굴자들은 p2sh/CHV  (CheckHashVerify)를 코인베이스에 담았다. 채굴자가 참여하는 비트코인의 거버넌스를 엿볼 수 있는 구조중에 하나이다.


BIP16


BIP17

BIP0016은 1주일 동안 투표가 진행되었으며 2012년 2월 1일 자로 결과 확인에 따라 2월 15일 00시부터  P2SH가 채택되었다.


문자열 삽입에 관한 가장 흥미로운 사례는, 실제로 사토시 나카모토가 첫 블록을 생성하였을 때의 첫 coinbase에 문자열을 인코딩해 놓았으며, 내용은 다음과 같다

Genesis Block의 Coinbase
 The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

이는 The Times 에 실린 세계금융위기에 대한 기사 제목을 말하며, 중앙화된 은행의 신뢰 문제를 담아 비트코인의 탄생 배경을 함축해 놓은 듯하다.


Coinbase tx가 UTXO의 시작이라면, Block의 시작은 Genesis Block이다. 비트코인의 제네시스 블록을 살펴보면 다음과 같다.


Genesis Block

비트코인 제네시스 블록 (Genesis Block)



사토시 나카모토가 비트코인을 개발 중이라는 사실을 2008년 11월 1일 밝혔으며 Genesis block은 2009년 1월 3일에 생성되었음을 알 수 있다.


블록에 거래를 담는 채굴자들은 coinbase tx의 이기적인 조작을 할 수 없었으나 바디에 거래를 담는 과정에서는 어떠한 제한이 있는지 살펴보자.

블록의 바디에 거래를 채굴자 마음대로 담을 수 있는가?

블록 구성

블록의 크기는 1MB로 정해져 있다. 그중 블록의 바디는 거래들로 이루어져 있지만, 담는 기준이 설정되어 있다. 채굴자들은 물론 수수료가 높은 거래들로 담기 위해 노력을 한다. 그에 따라 이를 쉽게 설명한 글들은 ‘수수료 낮은 거래들은 블록에 담기지 않는다’로 얘기가 되어있지만 실제로는 그렇지 않다.


블록의 첫 50킬로바이트는 'utxo 우선순위'에 따라 거래들을 담도록 설정되어 있다.

 우선순위 = (수수료 + 나이) / (거래의 크기)

쉽게 말해서 txpool에 오래 담겨있으면 (나이가 높다면) 수수료가 없이 형성된 utxo를 소비하는 거래도 채택될 가능성이 있다는 것이다. 실제로 ‘높은 우선순위’의 utxo가 input으로 있는 거래가 제일 먼저 블록에 포함된다.

‘높은 우선순위’ ≥576*10⁵ (1 BTC가 250바이트 크기의 거래에서 하루 머물렀을 때의 크기)

‘높은 우선순위’의 utxo가 input으로 쓰인 거래들이 먼저 담긴 후, 50킬로바이트 중 남은 공간에 한해서 ‘우선순위’에 따라 거래들이 의무적으로 담긴다. 이후 나머지 공간은 채굴자들이 선택적으로 거래를 담게 되고, 일방적으로 수수료가 높은 거래들을 우선적으로 담는다. 



참고

Antonopoulos, Andreas M. Mastering Bitcoin: Unlocking Digital Crypto-Currencies. OReilly, 2016.

Genesis Block 

Genesis Block CoinBase

277316번째 블록 Coinbase

BIP0016BIP0017

사진 출처

https://www.thetimes03jan2009.com/


손동하/ sohn@skkrypto.io

매거진의 이전글 Bitcoin#6: 난이도와 목푯값
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari