파이썬으로 배우는 블록체인 구조와 이론-4장 트랜잭션(Transaction)
비트코인 네트워크의 목적은 트랜잭션이다. 암호, 지갑, 채굴 등 트랜잭션 이외의 모든 요소는 트랜잭션을 안전하게 만들기 위한 부수적인 것들이다.
1. 트랜잭션의 구조
트랜잭션에는 입력부와 출력부가 있다. 입력부에는 자신의 UTXO포인터와 전자서명이 들어 있다. 출력부에는 수신자의 공개키 해시와 송금할 금액이 들어 있다.
비트코인 네트워크에서는 UTXO 관리와 채굴을 통해 이중 지급을 방지한다.
트랜잭션 데이터 구조
필드 크기(Byte)
각 필드의 크기는 고정 크기와 가변 크기, 그리고 압축 크기로 정의돼 있다.
숫자로 표시된 필드는 모두 고정 크기다.
Var로 표시된 필드는 가변 크기다. 가변크기는 Script length에 지정된다.
*C로 표시된 것은 압축 크기다. 압축 크기는 값의 범위에 따라 크기가 정해지는 것이다.
바이트 오더
데이터를 메모리에 저장하거나 네트워크로 전송할 때 데이터를 배열하는 순서를 바이트 오더라 한다.
바이트 오더는 크게 빅 엔디언(Big-endian)과 리틀 엔디언(little-endian) 방식으로 나눌 수 있다.
빅 엔디언은 숫자의 큰 단위가 앞에 오고, 리튼 엔디언은 숫자의 작은 단위가 앞에 오는 방식이다.
직렬화(Serialization)
트랜잭션 데이터를 메모리에 저장하고 네트워크에 전송하려면 바이트 오더 규칙에 맞게 배열해야 한다. 이 과정을 직렬화라 한다. 트랜잭션 데이터는 스크립트 부분을 제외하고 모두 리틀 엔디언 형태이다.
합치고 나면 최종적인 트랜잭션의 원시(raw)데이터다. 트랜잭션은 이 형태로 비트코인 네트워크로 전송되고 블록에도 기록된다. 트랜잭션을 받은 노드는 이 데이터를 다시 빅 엔디언 형태로 바꿔서 처리한다.
트랜잭션ID
트랜잭션 데이터는 최종적으로 블록체인의 특정 블록에 저장된다. 이 트랜잭션이 어느 블록 몇 번째 위치에 있는지 찾으려면 이 트랜잭션에 대한 고유 ID가 필요하다. 블록체인 특성상 분상형 네트워크이기에 순차적인 ID를 부여할 수 없기 때문에 트랜잭션의 고유 ID로는 트랜잭션 데이터의 해시 값이 사용된다.
2. 전자서명 생성
해시타입
전자서명은 트랜잭션의 모든 입력부와 모든 출력부를 대상으로 한다. 그러나 때에 따라서 일부 입력부와 출력부를 전자서명에서 제외할 수도 있다. 해시 타입은 전자서명 대상의 범위를 지정한 것이다.
3. 전자서명 검증
트랜잭션을 만든 사람은 전자서명을 생성하고, 트랜잭션을 받은 사람은 전자서명을 검증한다. 전자서명을 검증하려면 트랜잭션의 입력부에 기록돼 있는 Script Sig와 UTXO의 출력부에 기록돼 있는Script Pubkey가 필요하다.
스크립트 검증
비트코인은 전자서명을 위해 스크립트 방식을 사용한다. 스크립트는 일종의 프로그래밍 언어로 스택을 통햇 실행되는 간단한 형태의 언어다. 스택에 넣거나 빼면서 스크립트의 유효성을 평가한다.
4. 트랜잭션 가변성
전자서명이 완료된 트랜잭션은 중간에 다른 사람들이 변경할 수 없다. 그러나 전자서명 부분의 OP코드를 조작해 원본과는 다른 트랜잭션 ID를 가진 새로운 트랜잭션을 전파하는 방식으로 변경 가능성이 제기 됐다. 이와 같이 트랜잭션의 유효성은 유지되면서 내용의 일부가 변경될 수 있는 위험을 트랜잭션 가변성이라 한다.
이 문제의 근본적인 해결을 위해 전자서명을 트랜잭션과 분리하는 세그윗 방식이 개발됐다.
5. 다중 서명
여러 명이 한 개의 지갑을 공동으로 사용하는 경우는 여러 명의 전자서명이 필요하다. 이런 기능을 다중 서명이라 한다. 다중 서명을 사용하는 지갑은 개인키와 공개키가 여러 개이고, 지갑 주소는 1개다. 다중 서명은 일반적으로 M-of-N 방식을 사용한다. N은 전체 키의 수, M은 필요한 서명의 수이다.
6. Pay-to-Script Hash(P2SH)
트랜잭션을 생성할 때 출력부에 수금자의 공개키 해시를 기록하는 형태를 Pay-to-Public-Key-Hash(P2PKH) 방식이라 한다. Pay-to-Script Hash(P2SH)는 트랜잭션 출력부에 공개키 해시가 아닌 일종의 스크립트 해시를 기록하는 방식이다. 스크립트 언어를 활용해서 다양한 조건으로 거래를 생성할 수 있는 매우 강력한 기능이다.
7.세그윗
세그윗(SegWit)은 비트코인의 확장성 문제를 완화하고 트랜잭션 가변성 문제를 근본적으로 해결하기 위해 피터 윌리박사가 제안했으며, 2017년 8월 비트코인 네트워크에 적용됐다.
세그윗 개요
세그윗은 트랜잭션의 전자서명 부분을 분리해 별도로 처리하는 방식이다. 분리된 전자서명을 위트니스라한다. 트랜잭션에서 가장 큰 데이터인 서명 부분을 분리하면 트랜잭션의 크기가 작아지고 한 블록에 더 많은 트랜잭션을 담을 수 있다.
하드포크는 기존에 이어져 오던 블록체인에 새로운 블록을 연결하지 않고 새로운 블록체인을 만드는 것을 말한다.
소프트포크는 기존의 규칙과 새로운 규칙(변경된 합의 사항)이 적용되어 만들어진 블록을 기존의 블록체인에 계속 적용되어 블록이 생성되는 것을 말한다.
8. 세그윗과 위트니스 머클 트리
머클 트리는 블록에 기록된 트랜잭션들의 내용이 변경되는 것을 막아 준다. 그런데 위트니스를 분리한 트랜잭션으로 머클 트리를 만들면 트랜잭션의 내용만 보호되고 위트니스의 내용은 보호되지 않는다. 따라서 위트니스도 별도의 머클 트리를 만들어서 보호해야 한다.
9. 세그윗 트랜잭션
세그윗 트랜잭션은 기존의 트랜잭션 입력부에서 서명 부분(위트니스)을 따로 분리한 것이다. 즉 트랜잭션의 구조가 변경됐다. 세그윗 기능을 업그레이드 하지 않은 기존 노드도 이 트랜잭션을 거부하지 말아야 네트워크로 널리 전파될 수 있다.
세그윗 트랜잭션의 구조
세그윗 트랜잭션의 구조는 기존의 트랜잭션 구조에 마커와 플래그가 추가됐고, 입력부의 ScriptSig 서명 부분이 스크립트 위트니스로 분리 됐다. 트랜잭션 ID는 위트니스를 제외한 트랜잭션이고, 위트니스 ID는 위트니스를 포함한 트랜잭션이다. 세그윗 기능으로 업그레이드한 노드는 위트니스 ID를 받고, 세그윗 기능이 없는 기존의 노드는 트랜잭션 ID를 받는다.
10. Bech32주소
Base58Check 인코딩 방식은 읽고 쓰기가 불편하고, QR코드에 공란이 많고, 오류 검출 능력이 약하고, 인코딩 속도가 느리다는 등의 단점이 있다. Bech32 인코딩을 사용하면 이런 단점들을 보완할 수 있다. Bech32 주소는 앞부분이 ‘bc1’으로 시작한다.
