11. Transaction의 개요

Blockchain.info를 열어, Block #0을 검색한 뒤,그 page에서 "해시"난의 "다음 블록"링크를 누르면 ,Block #1을 볼 수 있다. 이런 과정을 계속하여,#2,#3, . . .등을 보면,한동안 계속 Coinbase Tx만 있는 Block이 이어질 것이다.
보통의 Tx, 즉 Coinbase Tx이 아닌 것은 Block #170에서 처음 나타난다. Block #170을 열어 보라.
그곳 아래쪽을 보면 두개의 거래가 나와 있는데, 두번째 거래의 Txid는
f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
으로 나와 있을 것인데, 이것이 Blockchain사상 첫 정상적Transaction이다.
이 Txid는 푸른색(링크)으로 써있을 것이다. 이것을 클릭하여 이 Transaction의 상세 내용을 열어보자.
위쪽에 개요가 나와 있는데,
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
라는 Address로 부터,다음의 두 Address로 각각 10BTC, 40BTC 가 보내졌음을 알 수 있다.
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 10 BTC
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 40BTC

전에 한번 해 보았듯이, 주소줄의 끝에 "?format=hex"를 추가한후, Return Key를 누르면,이 Tx의 내용을 hex로 받을 수 있다.
다음이 그것이다.

11.1 Transaction의 구조

Transaction은 크게 4 Parts로구성되어 있다. 위에서 든 우리의 실례,Txid=f4184fc. . . . 9e16 의 내용을 4 Parts로 나누어 본것이
다음이다.

이 4 Parts를 차례로 설명한다.

(1)Version Number: 4 Byte

Transaction을 어떻게 작성하고,또 그것을 어떻게 검증하는가 하는 여러 규칙의 Version을 말한다. 물론,그 Tx을 작성한 Software,가령 Bitcoin Wallet, 가 어떤 Version에 입각하여 작성했는지를 보이는 것이다. 위의 예에서는
00000001(Big Endian 으로)이었다.

(2)Inputs: 가변 Byte길이

보낼 자금의 근거들과 함께,자신이 그 자금들을 사용할 자격이 있다는 증거들을 제시하는 곳이다.
"Inputs"의 끝에 복수라는 의미의 "s"가 붙었음에 주의 하여라. 가령,과거 어느 때 내 주소로 1.2BTC를 받은 적이 있고,
또 다른 시점에 1.5BTC를 받은 적이 있는 경우,가령 Address X로 2.0BTC를 보내야 한다면, 이 2개의 과거 기록을 모두 언급(Refering)해야 할 것이다.

(3)Outputs:가변 Byte길이

Inputs에서 근거로 제시한 금액(Satoshi)을 어느 곳으로 각각 몇Satoshi씩 보낼 것인지를 기술한다.
물론,이 금액 합은 Inputs의 자금 총계와 같거나 적어야 하며, 차액이 있는 경우 이것은 채굴자에게 가는 Tx Fee로 간주 된다.

(4)Lock time: 4 Byte

Lock time은 해당 거래서가 Blockchain에 추가 되는 것을 지연시키고자 원할 때,이용된다.
보통은 00000000으로 해 두는 것이 대부분이다. 지연을 두지 않는다는 뜻이 된다.
그러나,어떤 특정시간(Unix Epoch time)이 경과한 후에 Blockchain에 들어가기를 원한다면 그렇게 지정 할 수 있다.
그런 경우,Node들은 이 Tx을 따로 관리해 두고 있다가,그 특정 시간이 지난 후에야,Block채굴에 그 Tx을 포함하기 시작할 것이다.
(N Block을 더 지난후 Block에 추가토록 지정하는 것도 가능하다.)

11.2 Outputs의 구조와 의미

설명의 편이상 Inputs가 아니라,Outputs를 먼저 설명하겠다. 우선, 다음 그림의 맨 아랫쪽
근방을 보라.

Outputs의 구조는 윗 그림에 나타나 있는 것 처럼,
(1)Outputs Count (1Byte)
(2)Amount (8Byte)
(3)OutputScript(가변길이)
단, (2)및 (3)은 Outputs Count에서 지정한 수 만큼 열거 된다.

우리의 이 실례에서, Outputs Count가 2이므로,(2)와 (3)이 두번 열거 되어 있다.
첫Amount를,
[00][00][00][00][3b][9a][ca][00]
으로 파악해야 하므로(Little Endian방식으로 써있다는 것에 유념),

[3b]x256^3+[9a]x256^2+[ca]x256+[00]
=(59)x256^3+(154)x256^2+(202)x256=1,000,000,000 Satoshis =10BTC
그 뒤를 OutputScript가 따르고 있는데,여기서 독자들은 아마,Amount 뒤에 Bitcoin Address가 뒤따라야 하는게 아니냐 라고 단순하게 생각할지 모른다. 그러나,장래에 다양한
Payment방식에 융통성 있게 대처하기 위해서 "Output Script"라는 것을 두는 것으로 했다.
Output Script란 "관문(關門)"이라는 뜻으로 이해하면 좋다. 원래 이 "관(關)"자는 "빗장"이라는 뜻이다.
무협소설을 보면,"소림파" 장문인을 만나려고,주인공이 소림파의 "관문"을 통과하는 이야기가 나온다. 무공이 출중해야 이 위험한 관문을 통과하여 소림파 장문인을 만날 자격이 주어지는 것이다.
Output Script는 Bitcoin을 위해서 고안된 명령어(Byte Code)와 data들로 작성되어 있다. 어떤 "시험(test)"과정이 Code로 기술되어 있다는 이야기다. "시험에 들지 않게 하옵시며. . ."할 때의 그 "시험"또는 "시련" 말이다.

영어로 된 책자에서는 "Satoshi Value값에 Encumbrance를 걸어 둔다" 라고들 말한다.
즉,각각의 Satoshi Value에 OutputScript라는 것을 써서, Encumbrance(장애물/빗장/關門)를 걸어 두는 것이다. (문헌에서는 Amount가 아니라 Value라고들 한다.)

두번째 Amount는 40BTC로 계산 될 것이다. 다음 그림은 Block #170 page의 Transaction부분을 보인 것인데, 2번째 거래를 보라(첫거래는 Coinbase Tx).

과연,10BTC와 40BTC를 다음 두 Address로 보내는 것으로 되어 있다.
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3
12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

이 40BTC는 Address "12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S"로 보내 졌는데,
나중에 이Address의 소유자가 40BTC를 "소비"(또 다른 Address로 보내는 것)하고자 하고자 한다면,
Tx을 작성할 때, Input에서, 자금의 근거로써 이 Txid=f418. . . .9e16 와 Output index=1 (두번째 Output이란 뜻)을 쓰고나서,그뒤에 InputScript를 달아 주는데,이 InputScript는 이40BTC에 걸어 두었던 Encumbrance(관문,즉 OutputScript)를 Pass하기위한 Script인 것이다. 결국 중요한 핵심은, "Satoshi Amount에 OutputScript로써 Encumbrance(관문)를 걸어 두는데,나중에 그 금액을 "소비"할 때, InputScript로써 그 Encumbrance를 Pass(돌파)한다" 라고 하는 점이다! 이것이, Node들이 Tx을 검증할 때의,주요 작업내용이다.

주의 할 점 한가지. 가령,윗그림에서 40BTC Amount의 뒤를 잇는 Byte들 중 첫Byte는 Byte Count로써, "OutputScript"가 몇개의 Byte로 되어있는가를 표시하는 것이므로,
선두의 [43](10진수; 67)을 제외한 이후의 67개의 Byte ,"410411. . . . 12a3ac", 가 OutputScript의 본 내용이다. 이것은 Input Script에서도 마찬가지다.
이 OutputScript의 본 내용중, 제일 첫Byte인 [41]과 맨 끝Byte인 [ac]가 명령어(Opcode라 부름)이며, "0411. . .12a3"는 data이다. Opcode는 [ ]안에 넣어 구분하고,data들은 < >를 써서 구분 표시한다면,
[41]<0411. . . .12a3>[a3]
의 꼴이 되어 약간 가독성(可讀性)이 좋아질 것이다. 어떻게 Opcode와 data를 구분해 내었는가 궁금하겠지만, 차차 알게 될것이다.

11.3 Inputs의 구조와 의미

Inputs부분은 다시,
(1) Inputs Count(1 Byte)
(2)Txid (32Byte)
(3)Output index(4Byte)
(4)Input Script
(5)Sequence(4Byte) : ffffffff
단, (2)~(5)는 Input Count의 횟수 만큼 계속 나열된다. Sequence는 input들을 구분하는 Byte열로 이해하면 된다.

우리의 실례에서는 Input가 단 한개이다. 그 Input이 언급하는 자금 출처를 보면,Big Endian방식으로 읽을 때,
Txid=0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
Output index=00000000
으로 되어 있으므로,
Txid=0437. . . .97c9인 Tx의 Outputs에 열거 된것중,제일 처음의 Output,을 자금의 근거로 제시한 것이다.
그리고,바로 뒤를 따르는 Input Script의 본내용은 (Byte Count 48은 제외!),

47304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901
가 된다.

이것이 무엇이겠는가? 이것은 바로,
Txid=0437. . . .97c9, Output index=0 에 걸어 놓았을 "관문(關問)장치"(Output Script)에 대응하여, 그 관문을 통과하기 위한 "증빙자료"인 것이다.

이 Input Script의 "본 내용"(Byte Count"48"을 제외한)을 Opcode와 data로 구분해 표시해 보면,
[47]<3044. . .0901>
가 된다. 지금은 그러려니 하고 넘어가자.

이제, Txid=0437. . . .97c9 ,Output index=0 에, 어떤 "관문(關問)"(Output Script)이 걸려 있었는지를 조사하여,어떻게 "검증과정"이 진행되었는지를 알고지 한다. 그러자면,이 Tx을 Blockchain.info에서 검색하여,그 내용중 Outputs부분을 보면 될 것이다. 독자들도 이 Txid를 써서 검색을 시도해 보라.

필자가 검색을 해 보니,Oops! 다음과 같이, 찾을 수 없었다는 내용이 뜬다!

이것은 너무 오래된 Tx이라서,이 Server의 index에 아예 담고 있지 않은 것으로 보인다.
그렇다고,그 거래 기록이 없어질 리는 절대 없다. 어찌 해야 할까?
필자는 Address로 검색을 하여,약간 머리를 쓴 결과, 이 Tx이 Block #9의 Coinbase Tx 이었음을 알아 내었으며,
그 Txid를 클릭하여 다음 같이 열수 있었다. (독자들은, 필자가 어떻게 이 page를 열었는지 궁리를 해 보라)

독자들은 Block #9을 열고,그것의 Coinbase Tx의 Txid를 클릭하여, 이 Tx의 page를 열 수 있을 것이다.
여기서,이번에는 좀 다른 Format로 이 Tx의 내용을 Browser로 받아보자. 전에는 "?format=hex"를 덧붙였었으나,이번엔
"?format=json"을 추가 해보라. 보기에 편리한 구조적인 형태로 보는 방법이다. 그 page의 "Out"에서 OutputScript를 볼 수있다. 다음과 같을 것이다.

Output Script:
410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac

이것을 앞서의 예에 따라,Opcode와 data로 구분하여 표시해 보면,
[41]<0411. . . .12a3>[ac]
로 된다.

결국,Block Reward로 받은 50BTC에는 Encumbrance로써
[41]<0411. . . .12a3>[ac]
가 걸려 있었는데, 이 관문을 Pass하기 위하여,
[47]<3044. . .0901>
를 제출 한것이 된다. 이제 12절에서는 이 Pass과정(검증과정)이 어떻게 진행 되었는지를 설명할 것이다.

12. Transaction의 검증.

우리의 Tx실례인,
Txid=f418. . . . 9e16 인 거래,즉 Block #170의 2번째 거래가, 어떻게 Node들의 검증을 Pass하여,Block #170에 수록이 되었는지를 복기(復棋)해 보도록 하자.
먼저 각Node들은,각자 독립적으로,
input에서 제시하는 자금근거인 Txid=0437. . . .97c9인 거래가 존재하는지와,그것의 첫번째 Ouput이 혹시 중복하여 "소비"하는 것은 아닌지를 Check한다.
한번이라도 Input에서 사용된 적이 있는 Output은 거부 되어야 하니까(Double Spend방지).

그 다음,
InputScript의 본 내용과, 그에 대응하는 Encumbrance(Output Script)의 본 내용을 이어 붙여서,이를 하나의 Excutable Program으로 보는 것이다.
즉, 우리의 실례의 경우,
[47]<3044. . .0901>[41]<0411. . . .12a3>[ac]
가 "검증"을 위해 실행해야 할 Program이 되는 것이다.

이제 Program의 실행과정,즉 검증 과정, 을 설명한다.
우선 선두 첫Byte는 Opcode(명령어)로 보고 시작한다.

첫 Opcode인 [47]은,이후에 따르는 [47]개(71개)의 Byte를 data로써 Stack에 Push하라는 명령이다. Byte수를 세어 보면 알겠지만 <3044. . . .0901>은 전부 71Byte임을 확인할 수 있을 것이다. 사실, [01]~[4b]의 Opcode는 전부 그런 의미의 명령인데, 명령어의 Name조차 지정되어 있지 않다.
<3044. . . .0901>은 원래 무엇 이었을까? 이것은 이 Tx( Txid=f418. . . . 9e16 )의 내용을 대상으로 해서, Private Key로 Encrypt해서 얻는 결과물로써,소위 "Signature"라고 부르는 것이다.
더 정확히 말하면,Tx (Txid=f418. . . . 9e16)의 내용중, 이 Signature부분은 제외한 내용, 을 대상으로 하여,Private Key로 Encrypt한 결과물로 이해하면 좋다. 이를 앞으로는 < Sig >라고 쓰기로 하자.
물론, 이 Private Key는 Address 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 에 대응하는 비밀Key를 말한다.

이 < Sig >는 이 Private Key로부터 계산 되어지는 Public Key(이후 Pubkey로 약기)로 Decrypt해야만 제대로 해독이 되어,원래의 원본 내용,즉 Tx중 < Sig > 를 제외한 내용을 볼수 있다.

실행(Execution)을 계속하자. 단,지금 Stack에는 < Sig >가 들어 있다.
[41]이 다음 Opcode인데,앞서 이야기 했듯이,이것은 이후의 [41]개(65개)의 Byte를 Stack에 넣으라는 명령이다.
따라서 이번에는,<0411. . . .12a3>가 Stack에 들어 간다. 세어보면 <0411. . . .12a3>는 65Byte길이 임을 알 것이다.
이 <0411. . . .12a3>는 원래 무엇 이었을까? 이것은 Address 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 에 대응하는
Pubkey였던 것이다. (Pubkey는 65Byte의 길이를 갖는다) 그래서 이data를 < Pubkey >로 쓰기로 하자.

따라서 지금은 Stack의 제일 위에는 < Pubkey >가 있고,그 아래엔 < Sig >가 있다.
다음 Opcode인 [ac]는 "OP_CHECKSIG" 라고 하는 명령어 Name을 갖고 있는데,이 명령어는 Stack에서 Pop한 것,즉 < Pubkey >,를 key로 하여, 또한번 Pop한 것,즉 < Sig >,의 내용을 Decrypt(해독)한다음,그 결과를, Tx의 원본(물론,< Sig>는 제외한)과 비교하라는 뜻이다.
양자가 일치하면, 이 < Sig >가 확실히 그 < Pubkey >에 대응하는 Private Key로 Encrypt한 것이 틀림없다는 것이 증명되므로, 검증을 Pass하게 되는 것이다.

이제 독자들은 어떻게 검증이 Pass하였는지를 ,그리고 Script중에서 Opcode와 data를 필자가 어떻게 구분해 낼 수 있었는지도 이해 되었으리라 본다. 사실은 Script의 전체의 문맥상 어떤 것은 Opcode가 되고,어떤 것은 data가 되는 것이다.
한편, < Sig > 는 관문을 Pass하기 위한 증거물이기도 하지만,또 한편으로는 Tx의 내용을 보호하는 역할도 같이 수행함이 이해 되었으리라 본다. 만약 Node로의 data전송과정에서 Hacker들이 Tx의 내용을 1Bit라도 변조를 하면 그것은 전체 Tx을 무효화 하는 것이 된다. 검증과정에서 실패하게 될테니까.

한편, 검증에 사용한 Script Program 인
[47]<3044. . .0901>[41]<0411. . . .12a3>[ac]
를,가독성(可讀性)좋게, 표시하면,
[47]< Sig >[41]< Pubkey >OP_CHECKSIG
가 되는데,[47] ,[41]들은 아예 생략하여,
< Sig > < Pubkey >OP_CHECKSIG
로 표시하는 경우가 많다. 즉, 그렇게 써 놓고는,해설을 할 때는,

< Sig >를 Stack에 Push
< Pubkey >를 Stack에 Push
Stack에서 하나를 뽑아(Pop) 그것을 Key로 삼고,
Stack에서 또하나를 뽑아(Pop) 그 내용을,위의 Key로 Decrypt한 후, 그 결과를
약속된 원본과 비교한다.

이런 식인 것이다. 그래서 Opcode [01]~[4b]는 Opcode명칭도 할당하지 않았고, 그냥 총칭하여 Constant류(類)의 Opcode라 한다.
가령 11.3에서 보인 바 있는, Txid=0437. . . .97c9 의 page 아랫쪽을 보면, "출력 스크립트"가 있는데 그곳엔
0411db93. . . . .b412a3 OP_CHECKSIG
로 써 있음을 볼 수 있다. 여기서도 선두 Opcode인 Constant [41]은 슬쩍 생략 되어 있다.
단, json format으로 들여다 보면,그곳의 Script에는 [41]도 포함한 Script전체가 Hex로 기술되어 있을 것이다.

이제 어떤 Tx의 내용을 볼 때, 그page의 "Input 스크립트" ,"Output 스크립트"의 내용에 있는 것들이 Script라고 부르는 일종의 Program Language 라는 점이 이해되었을 것이다.
다만,거기에 함께 나와 있는 두 Script가 서로의 쌍은 아니라는 점이다. 즉, 그곳의 "Input스크립트"와 쌍이 되는 상대방은,Tx의 Inputs에서 기술된 Previous Txid 와 index에 걸려있던 Output Script인 것이다.

우리가 검토한 이 Output Script의 실례는 Bitcoin초기의 구식방식이며, "Pubkey로 Pay하는(송금하는)방식"이므로, "P2PK (Pay to Public Key)"방식이라고 들 부른다. 오늘날엔 쓰지 않는 방식이다. 사실 Block #170 당시에는 Bitcoin Address라는 개념이 도입되기 전이었다. 따라서, Block #170에 나오는 Address는, 그 Pubkey에 현재의 Address계산 알고리즘을 소급적으로 적용하여,그것을 보이고 있는 것이다.

이상과 같이 Inputs부분에 대한 검증이 Pass되면, 2차적으로 Outputs부분에 대한 검사가 이루어 지는데, 그내용은, Outputs부분의 Value(Satoshi)총합이 Inputs의 자금 총합을 넘지는 않는가를 검사하는 것이다. OuputScript의 내용은 일절Check하지 않는 것으로 안다. 그곳에 Pass불가능한 관문이 설치되어 영영 그 Satoshi에 접근을 할 수 없게 되어도 할 수 없는 일이다. (그러한 것을 Unspendable Output이라고 부른다.)

모든 검증/검사를 무사히 Pass한 Tx은 다른 몇몇 Node들에게도 전달되며("소문"이 퍼지는 과정처럼),그것을 받은 Node들은 각자 독립적으로 검증/검사를 실시한다. 검증을 Pass하지 못한 Tx은 버려진다(Reject).