[블록체인] 4. 트랜젝션과 네트워크 : Blockchain Transaction & Network

 

목차 : 네트워크 개요 / 비트코인의 트랜젝션 / 비트코인의 네트워크

 

네트워크 개요

- Client-Server

단일 중앙서버, 클라이언트의 요청에 서버가 응답, 병목 현상 발생 가능성

구현비용 비싸지만, 안정적이고 확장 가능

 

- P2P Network

네트워크의 각 클라이언트가 서로 데이터 공유

각 노드가 자체 데이터를 보유하며, 구현 비용은 저렴하지만 노드 수 증가하면 문제발생 가능성 증가

 

- 금융 네트워크의 필수 요소

1. 거래 처리 대리인

2. 이중지불을 검증하는 검증자

3. 거래내역 저장하는 DB

4. 대리인과 검증자에 대한 신뢰

 

- 중앙 서버가 없는 블록체인에서는?

 

- 비잔틴 장군 문제 (BFT : Byzantine Fault Tolerance)

 

비잔티움 제국의 장군들이 적의 수중에 있는 도시를 포위하려 한다. 전투 준비를 마친 각 장군들은 제국군의 대부분이 한꺼번에 도시를 공성해야지만 이 도시를 함락시킬수 있음을 알고 있다.
그러나 비잔티움의 장군들은 자신들 중 몇몇이 이미 적과 내통하고 있음과 서로에게 연락할 전령들이 도시에서 나온 척후대에게 사로잡힐 수 있음도 알고 있다.
어떤 장군이 황제에게 충성스러운지, 혹은 모반을 하려는지 확실하지 못한 상황에서 충성스러운 장군들은 배신자들이 병력을 물려 공성을 방해하거나 적에게 소식을 넘길수 있다는 상황 때문에 딜레마에 빠진다.

충직한 장군들은 전령들이 보낸 명령을 충실하게 따르며 이 외의 행동은 하지 않는다. 그러나 전체 장군 중 일부인 배신자 장군들은 전령에 얽매이지 않고 마음대로 행동할 수 있다. 이 때 배신자의 존재에도 불구하고 충직한 장군들이 동일한 공격 계획을 세우기 위해서는 충직한 장군들의 수가 얼마나 있어야 하며, 장군들이 어떤 규칙을 따라 교신해야 하는지에 대한 문제가 바로 비잔티움 장군 문제이다.

이러한 참사를 해결하기 위해 장군들은 배신자를 찾아내거나, 배신자라면 알 수 없는 암호를 통해 전령을 보내거나, 여러 장군들에게 한꺼번에 전령을 보내 명령을 대조해보는 등 여러 방법을 사용해야만 한다.

이는 비트코인 블록체인의 노드들이 서로간의 정보를 대조하거나, 시스템 상 오류가 있는 프로그램들이 있어도 타 프로그램들이 오류를 우회할 수 있는 상황을 가정하는 데에 도움을 준다.

 

비트코인의 트랜젝션

UTXO : Unspent Transaction Output

- 잔고 = 사용하지 않은 트랜젝션 output

- UTXO의 사용 여부를 확인함으로써 자산의 안전성 확인

 

Transaction

- B가 C에게 비트코인을 전송하려고 한다.

1. B는 우선 이전에 A에게 받았던 잔액 기록의 위치(UTXO)를 찾는다.

2. 이 Output-b은 A가 B의 공개키로 잠궈놨고, B의 개인키로 해제할 수 있다.(전자서명)

3. B는 C의 주소정보와 송금할 금액을 기록한다.

4. 그리고 C의 공개키 해시로 잠금한다.

5. 이제 Output-b는 더이상 사용이 불가능

 

- 블록체인에서는 트랜잭션들도 chaind으로 연결되어 있으므로, Coinbase를 제외한 모든 거래 내역을 추적 가능하다.

- 어느 UTXO가 사용되었는지 알 수 있으므로, 이중지불이 방지됨

 

Transaction 구조

 

- 입력부 : 송신자의 UTXO 포인터와 전자서명 등

Version, Input Count, Previous Output, Output Index, Script Length, Script Sig

 

- 출력부 : 수신자의 공개키 해시와 송금 금액 등

Sequence, Output Count, Value, Script Length, Script PubKey, Lock Time

 

 

Transaction 수수료 (Fee)

전체 input - 전체 output = 트랜잭션 수수료

 

- 채굴자들은 적은 용량 & 높은 수수료 선호

 

Coinbase Transaction

- 채굴자가 성공할 때 받는 기본 수수료는 가장 첫번째 거래로 블록에 포함됨.

- 코인베이스 트랜젝션 특징

1. 채굴 기본 보상 수수료와 채굴한 블록에 포함된 거래 수수료를 포함하여 채굴자에게 전송

2. 트랜잭션 수수료가 없음

3. 송신자의 주소가 없음 (추적 불가능)

 

 

비트코인의 네트워크

(Tx)

- B는 C에게 3BTC를 전송하는 트랜젝션을 생성했다.

1. B는 생성한 트랜잭션 Tb를 인근 노드들에 전송

2. 노드들은 Tb를 검증하고, 다시 인근 노드에 전파 (Transaction Relay)

3. 전파 과정을 통해 Tb가 풀 노드에 도착

4. 풀 노드가 자신의 블록체인 데이터에서 해당 트랜잭션이 가리키는 UTXO를 확인

 

- 4번 과정에서 검증 스크립트를 활용함

- 검증 스크립트 : OP코드로 구성 (Operation code)

Stack을 통해 실행

보안상 반목문은 없음

 

비트코인 OP 코드 중 OP_DUP에서 OP_CHECKSIG까지의 과정은 비트코인 거래 확인 중에 수행되는 일련의 작업입니다.

OP_DUP - 상위 스택 항목 복제
OP_DUP opcode는 스택의 맨 위 항목을 복제하여 스택에 밀어넣습니다. 일반적으로 서명 확인 프로세스에서 사용될 공용 키 해시의 복사본을 만드는 데 사용됩니다.

OP_HASH160 - 상단 스택 항목 해시
OP_HASH160 opcode는 SHA-256 알고리즘과 RIPEMD-160 알고리즘을 사용하여 스택의 최상위 항목을 해시합니다. 일반적으로 공개 키를 블록 체인에 저장하기에 더 짧고 효율적인 해시로 변환하는 데 사용됩니다.

OP_EQUALVERIFY - 상위 두 스택 항목 비교 및 제거
OP_EQUALVERIF opcode는 스택의 상위 두 항목을 비교하고 동일한 경우 항목을 제거합니다. 일반적으로 공용 키 해시가 이전 트랜잭션의 출력 스크립트에 저장된 해시와 일치하는지 확인하는 데 사용됩니다.

OP_CHECKSIG - 공개 키에 대한 서명 확인
OP_CHECKSIGopcode는 트랜잭션 입력 스크립트에 제공된 서명이 이전에 해시된 공용 키에 대해 유효한지 확인합니다. 일반적으로 트랜잭션 입력이 공용 키 해시와 연결된 개인 키의 소유자에 의해 인증되도록 하는 데 사용됩니다.

 

5. 풀 노드에 의해 검증된 Tb는 이를 전파하고, 이를 받은 마이너 노드도 유효성 검증

6. 검증되면 다른 Tx들과 합쳐 새 블록 생성

7. 생성된 새 블록을 풀 노드들에 전파

8. Tb 거래 완료

9. 이후 블록이 6개 더 추가되면, 완전 승인으로 판단

 

 

- 풀 노드는 Tx 수신 시 Tx의 input이 가리키는 output이 UTXO인지 확인하기 위한 별도의 DB(UTXO set) 관리

- 따라서 풀 노드는 빠르게 Ta의 output을 찾음

- Tb 승인 후 Ta의 output은 spent 상태가 됨 (이중지불 방지, 내용이 바뀌는 건 아님)

 

(Mining)

- 마이너 노드는 Tx들을 모아 머클 루트 계산

블록의 첫 Tx는 Coinbase Tx, Segwit 도입 후 전자서명을 모아 Coinbase Tx에 기록

 

- Difficulty Target (Bits) : 채굴의 성공 여부를 판단하는 정보

블록헤더 해시값의 상한선(헤더 해시)이 타겟값보다 작아야 유효한 블록으로 인정

마이너 노드는 넌스 값을 바꿔가며 해시가 타겟보다 더 작아지는 넌스를 찾음 (작업증명)

 

- 블록 채굴 시, 넌스 값을 위해 컴퓨터 파워를 소비함으로써 거래 위변조 공격 방지

- 블록의 신뢰성 보장

- 전체 Network hash에 따라 difficulty 비례

 

 

- 만약 거의 동시에 두 채굴자가 서로 다른 유효 블록을 생성한다면?

블록체인의 일시적 분기 발생.

각 채굴자는 자신이 생성한 블록을 인근 노드에 전파, 풀 노드는 먼저 받은 블록을 Main chain에 연결

다음 생성 블록이 Parent로 선택하는 블록이 유효한 것으로 인정.

 

연결되지 못한 블록은 폐기됨 -> 포함된 트랜잭션과 채굴 보상은 취소

- 취소된 트랜잭션은 다음 블록 생성 시 포함될 수 있음

 

- 채굴자들은 안전한 보상을 위해 폐기 가능성이 적은 Longest Chain을 선택.

 

- 부모가 없는 고아 블록을 전달받을 수 있음

짧은 시간 안에 연달아 이어진 블록이 생성됐을 때, 임시저장소 보관 후 부모블록이 도착하면 처리

 

 

Hard Fork & Soft Fork

 

- 개발자들이 소프트웨어 변경할 때 블록체인이 분기될 수 있음

 

- 소프트 포크 : 새 sw가 기존 sw와 호환

sw개발 계획에 채굴자들이 동의하고 업그레이드, Chain이 하나로 유지됨

업그레이드하지 않은 채굴자에 의해 일시적 분기 발생 가능

(일시적 분기 블록은 폐기될 가능성이 큼 -> 업그레이드하는게 유리)

 

- 하드 포크 : 변경된 sw가 호환되지 않을 때

새로운 sw 채굴자와 기존 sw 채굴자가 각자 블록을 생성하여, 영구적인 분기를 만듦

두 Chain은 완전히 다른 새로운 코인이 됨

네트워크가 분리되고 비트코인 전체 가치 하락 위험