이제는 자세한 설명이 필요 없을 것이다. Block #1의 Hex format을 받아 Header와 Transaction부분을 분리하여 좀 정리하면 다음 같이 된다.
Header의 2번째 항목,즉 Previous Block의 Hash(사실은 DSha256)가 Little Endian Format으로 써 있음을 알 수 있을 것이다.
이렇게 해서,부모Block과 자식Block의 연계가 맺어지는 것이다.
이것은, 가령 중요한 계약서가 여러Page에 걸쳐서 작성되는 경우,변조나 누락 추가가 불가능하도록
n page와 n+1 page를 겹쳐놓고 겹치는 부분에 날인을 하는 행위에 비유 할수 있다.
비록 물리적으로는 여러Page로 구성되지만,사실상 1page의 계약서나 다름 없게 되는 것이다.
그러므로,Blockchain도 한개의 커다란 Block이나 다름이 없다. Chain중의 어떤 Block도 변조/삭제될 수 없고,새로운 것이 끼어 들어 올 수도 없다. 시간을 거슬러 올라가 역사를 고처 쓸 수가 없는 것과 같다. 자연계의 모든 과정(Process)이 계(系)의 엔트로피가 증대하는 비가역적 과정의 계속된 누적이듯이,Blockchain은 거래역사의 비가역적 기록의 누적이다. 그리고,평균 10분에 1Block씩 끊임없이,새로운 거래의 역사가 계속 기록 되어 쌓여간다. 게다가,누구의 지시나 권유가 없어도,이윤동기에 의해서,Node를 운영하여 채굴을 도모하는 사람들은 늘 흘러 넘칠 것이다. Node의 수가 늘어 날수록,Blockchain은 갈수록
더 철옹성처럼 견고 해진다. "불변성"에 더하여, "영속성", "안전,견고성",까지 갖는 System인 것이다.
약간 딴 길로 샜었는데,본론으로 돌아오자.
Block #1의 Hex data로 부터, 복습삼아, Header부분을 DSha256하여 이 Block의 Block id를 확인해 보고,이것이 채굴 합격범위에 들었음을 확인해 보라.
또,Coinbase Tx을 DSha256하여 Txid를 구해 보고,이것이 또한 Header의 Merkle Root과 같음도 확인해 보라.
(단,Transaction부분의 선두 1Byte 는 Tx count이므로, Coinbase Tx의 내용에 포함되지 않는 점에 주의)
Transaction이 많을 때 Merkle Root를 구하는 Rule을 설명하겠다.
그 Rule은 마치 운동경기에서 "토나멘트"방식과 유사한 점이 있어서,그 이야기를 잠시 하겠다.
9팀이 참가했다고 하자. 제 1회전을 하려니 참가팀 수가 홀수라서,할 수 없이 가령 추첨을 통해서 , 운좋은 한팀은 부전승을 통해서 2회전에 올라가게 된다. 따라서,2회전은 1회전을 통과한 4팀과 부전승으로 올라온 1팀을 합하여 5팀이 겨루게 되는데,여기서도 홀수인 관계로 또한번 추천이 있게 된다.
3회전은 3팀이 겨루게 되는데,홀수인 관계로, 여기서도 추첨이 필요하다. 4회전은 2팀이므로 추천이 필요없다.
4회전에서 드디어 우승팀이 결정되는 것이다.
Merkle Root에서는, 추천이란 없다. 그럼 어떻게 하는가?
예를 드는 것이 빠를 것이다. 쉬운 예로써 Tx의 수가 5라고 하자.
Block에 나열된 순서대로,이들을 차례로 T1,T2,T3,T4,T5 라고 표시하자. (물론 T1은 Coinbase Tx일 것이다.)
일단은 각Tx의 Txid를 먼저 구한다.
즉, DSha256(T1),DSha256(T2),DSha256(T3), . . . . 이런식으로.
그렇게 해서 얻은 Txid를 U1,U2,U3,U4,U5 라고 표시하자.
이제,토나멘트 1회전은 다음 같이 하는 것이다. 단, "U1:U2"란 U1에 U2를 이어 붙친 것을 의미한다.
DSha256(U1:U2)
DSha256(U3:U4)
DSha256(U5:U5)
즉,차례로 둘씩을(순서에 입각하여)묶되,마지막에 홀로 남게 되는 것이 있으면,그 땐 자신자신의 복사본과 묶는다는 이야기다.
이렇게 해서 얻는 1회전의 출력을 V1,V2,V3라고 하자.
이제 감이 왔을 것이다. 즉, 2회전은 다음과 같이 치루어 진다.
DSha256(V1:V2)
DSha256(V3:V3)
이제는 남은 3회전을 치루면 단 한개의 출력(32Byte)을 얻을 것인바,이게 바로 Merkle Root다. 충분히 이해가 되었으리라 본다.
다음은 Block #99993을 Hex로 받아본 것이다. 이 Block에 포함된 4개의 Tx이 보일 것이다.
독자들은 이 Block의 Merkle Root를 한번 계산해 보라.
필자도 한번 해 보았다. 일단,4개의 Tx의 DSha256을 구해보니,차례로 다음을 얻었다. 단,DSha256은 Sha256을 2회 거듭한다는 것임을 잊지 말라. 또, Sha256-hex-input을 이용할 때, "Enter as hex"옵션을 선택하는 것과, hash함수중 "SHA256"을 선택함도 잊지 말도록.
502408e8da276b38db6309e7e887b141e6cb238f9a0f699dc9ca729cc9a10bbd
8a9091a722fd88bf7a5e2efdff55d39937eff9ae7d69c700d19d795113a35312
7f2cb618ff7de0545ab22f33ae3002e7495346510a20340b4dfcc4a853017351
680a0652aa057a18833b982d12ea3e4aa7349731b50f256f5f4422ac4090aae3
차례로 둘씩 묶어서,1회전(?)을 하고 나니, 다음 2개로 되었다.
5f5b93f718e92f2c48825c3b6a37268fc4c48accf435cb036dc8304c41ca4d01
f44bda750a919593c4664d7c54c8c9bdacc8dc8a10d4907db127f7e6440ad89e
이제 2회전(?)을 하고 나니,
701179cb9a9e0fe709cc96261b6b943b31362b61dacba94b03f9b71a06cc2eff
를 얻었다. 이것이 Merkle Root이다.
과연,이것은 위에서 보인 바 있는, Block #99993의 Header중의 3번째 항목인, 701179cd. . . . . 2eff와 같다.
한편,Blockchain.info Web site에서 Block #99993을 열었을 때 나타나는 Page에서는
Txid들및 Merkle Root는 "Big Endian Format"으로 보이고 있다.
이점, 약간 헷갈릴 수가 있으나,그러려니 하고 넘어가자.
하여튼,Memory에 기록할때나 연산을 할 때는 "寺國佛"이라고 쓰지만,이것을 인간들에게 읽어줄 때는 "佛國寺"로 읽는다는 것을 상기하여라.
이상으로,지금까지 우리는 Bitcoin의 "채굴"과정,즉 화폐의 발권(發券)이 어떻게 이루어지는지를 살펴 보았다.
Bitcoin의 이러한 방식을 "Proof of Work(POW)"방식이라고들 부른다.
그 말이 의미하듯,과연 "채굴"은 거저 손쉽게 뚝딱 이루어지는게 아니고,Nonce에 맞는 답을 넣어 "채굴"에 성공하자면,
무수한 Try and Error를 거쳐,그것도 운이 좋아야만, 성공할 수 있다. 채굴에 성공한 Node는 주위의 몇몇 Node에게 이 사실과 함께 채굴된 Block내용을 전한다. 소식을 받은 Node들은 다시 자기 주위의 Node들에게 알린다. 즉,Broadcast되는 것이다. 소문이 퍼지듯이 번져서,통상 3~4초 정도 후에는 모든 Node에 통보된다고 한다.
다른 Node들은 받은 Block내용을 보고 검증함으로써,과연 "채굴"에 성공했는지,다시 말해서 "일(Work)을 제대로 했는지"를, 확인할 수 있다. 채굴된 Block은 Blockchain에 추가 된다.
현재 이 "Proof of Work"방식에 대해서,쓸데없이(?) 에너지를 낭비하여 환경을 악화시킨다고 하는 비판의 소리도 들린다.
가령,Lotto처럼 추첨방식으로 하면 될 듯도 하지만,누가 추첨을 할 것인가? 어떤 Server나 Node가 추첨의 진행을 맡는다면,이는 Centralized System이 되는 즉, 온갖 부정의 온상이 되기 싶상이다. 또,추첨에 당첨되었다는 Proof를 어떻게 Block내에서 확실히 입증할 수 있겠는가? 추첨을 맡은 그 Server나 Node가 계속 Autonomous하게, 영속적으로, 존재하고 작동하리라는 보장이 어디 있겠는가?
하여튼,앞으로 다른 대안이 나올 수도 있겠으나, 현재로써는 필자가 보기에는 POW는,
"Fair"하고,"자기입증성"이 있고,"영속성"이 보장된 우수한 방식이다.
다음 Post에서는 Transaction에 대해서,비록 약간 겉핥기 식이지만, 이야기 해 보려한다.
