블록은 이전블록의 해시(prevHash라고 부르도록 하겠다.)와 트랜잭션의 묶음이라고 생각할 수 있다. 해시는 블록의 데이터를 통해 계산되기 때문에 체인의 형태로 구성될 수 있다. 만약, 블록이 생성된 이후에 블록의 데이터를 변경하게 되면, 해당 블록의 블록해시(block hash)가 바뀌고, 이는 이후 생성된 다른 블록들에 영향을 주어 모든 검증자들이 알아차릴 수 있기 때문에, 다음 블록이 모두 무효화되어 임의 변조를 막을 수 있다.

네트워크의 모든 참가자들이 동기화된(Syncronized) 상태(State)를 유지하고, 모든 트랜잭션에 동의를 하기 쉽게 하기 위해 다수의 트랜잭션들을 한 개의 블록으로 묶어서 Commit, agree, Syncronize를 한 번에 처리한다.

출처:  https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

 

모든 블록들이 적절하게 검증을 받을 수 있도록, 네트워크는 참여자들에게 검증을 할 수 있는 충분한 시간을 부여한다. 트랜잭션은 초당 수십~수백개씩 발생할 수 있지만, 블록은 12초에 한 번 이더리움에서 생성되고 commite된다.

즉, 블록이 없다면, 모든 validator(트랜잭션(혹은 블록)을 검증하는 객체)는 매 초 모든 트랜잭션을 검증해야하며, 네트워크 상태에 따라 트랜잭션이 누락되는 경우에도 이를 검증하고, 블록을 네트워크에 추가해야하기 때문에, 블록을 사용할 때에 비해 Fork의 수가 수없이 많아지게 될 것이다.

(이정도면 블록이 있는 이유에 대해 충분히 알아본 것 같다…!)

블록의 작동 방식

transaction history를 보존하기 위해 블록은 상위 블록에 대한 참조를 가지고있어야 하며(prevHash에 대한 정보가 기록되어야 함), 블록 내에 있는 트랜잭션 또한 엄밀한 과정을 거쳐 블록에 정렬된다.

→ 추후에 더 알아볼 예정

PoS시스템에서, 네트워크에서 무작위로 선택된 검증자(PoS에서는, Proposer라고 부른다.)가 블록을 빌드하면, 이를 전체 네트워크에 Broadcast하게 되고, 합의의 과정 이후에 모든 노드는 이 블록을 블록체인의 끝에 추가하고 새로운 Proposer가 선출되어 다음 블록이 생성되는 과정을 통해 블록 추가해 대한 commitment와 consensus 프로세스를 명시하고 있다.

블록의 구조

slot 블록이 속한 슬롯

proposer_index Proposer의 ID
parent_root prevHash
state_root state root hash
body 블록 데이터를 담고있는 객체 (바로 아래에서 설명)

Body

randao_reveal 다음 block의 Proposer를 선택하기 위한 값(RANDAO seed)

eth1_data deposit contract에 대한 정보
graffiti 블록 태그를 위한 임의의 데이터
proposer_slashings slash당할 validator의 리스트
attester_slashings slash당할 attestor의 리스트
attestations 이 블록에 대한 attestation 리스트 (바로 아래에서 설명)
deposits list of new deposits to the deposit contract
voluntary_exits 네트워크를 떠난 validator 리스트
sync_aggregate light client에게 serve하는 validator subset
execution_payload execution client에서부터 넘어온 정보(트랜잭션 데이터 등) (아래에서 설명)

Attestations

→ list of attestations

aggregation_bits 어느 validator가 이 attesttation에 참여했는지에 대한 목록

data a container with multiple subfields (아래에서 설명)
signature 모든 attester들의 aggregate signature
  • data (in attestation)slot attestation이 실행된 slot
    index validator의 ID
    beacon_block_root 이 object를 포함하는 비콘블록의 루트해시
    source the last justified checkpoint
    target the latest epoch boundary block

Execution Payload header

parent_hash parent block의 hash

fee_recipient 트랜잭션 수수료를 받는 주소
state_root 이 블록으로 인한 state 변화를 적용한 global state의 root hash
receipts_root tx_receipt trie의 root hash
logs_bloom 이벤트로그를 포함하는 데이터 구조
prev_randao random validator selection에 사용된 value (RANDAO seed)
block_number 블록 번호
gas_limit 이 블록에 allow된 최대 gas
gas_used 이 블록에서 사용된 실제 가스
timestamp block time
extra_data arbitrary additional data as raw bytes
base_fee_per_gas base fee value
block_hash Hash of execution block
transactions_root 트랜잭션들의 root hash
withdrawal_root withdrawal 데이터의 root hash

Execution payload

parent_hash parent block의 hash

fee_recipient 트랜잭션 수수료를 받는 주소
state_root 이 블록으로 인한 state 변화를 적용한 global state의 root hash
receipts_root tx_receipt trie의 root hash
logs_bloom 이벤트로그를 포함하는 데이터 구조
prev_randao random validator selection에 사용된 value (RANDAO seed)
block_number 블록 번호
gas_limit 이 블록에 allow된 최대 gas
gas_used 이 블록에서 사용된 실제 가스
timestamp block time
extra_data arbitrary additional data as raw bytes
base_fee_per_gas base fee value
block_hash Hash of execution block
transactions 실행될 트랜잭션들의 리스트
withdrawals withdrawal 객체의 리스트
  • withdrawalsaddress withdraw한 객체의 주소
    amount withdraw한 ETH총량
    index withdrawal index value
    validatorIndex validator index value
  • 스테이킹된 이더를 인출하는것과 관련된 데이터 필드

Blocktime

블록타임(Blocktime)은 블록을 나누는 시간 단위. 이더리움에서는 12초 단위로 시간이 쪼개지며, 이를 slot(슬롯)이라는 시간 단위로 사용한다. 각 slot에서, 랜덤한 프로세스를 거쳐(RANDAO) single validator가 선출되어 블록을 propose한다. 모든 validator가 온라인 상태이고 문제없이 작동한다고 가정했을 때의 blocktime이 12초가 된다. 그러나, 종종 validator가 오프라인상태라면, 해당 검증자의 슬롯은 비워질 수 있다.

Blocksize

블록은 블록 사이즈에 의해 나눠지기도 한다. (Blocktime에서는 한 블록이 몇 초에 한 번 생성되는지를 이야기했다면, 이 말은 한 블록의 사이즈가 얼마나 되는냐는 말이다.) 각 블록의 일반적인 크기는 1500만 gas이며, 네트워크 상태에 따라 증가, 감소가 가능하여 최대 3000만 gas까지 늘어날 수 있다.

Blocksize가 늘어나는 매커니즘

블록의 크기는 한번에 확 증가하는 것이 아닌, 점진적으로 증가/감소하는 방식을 가지고 있다. 그 증가/감소 비율을 최대 $\frac{1}{1024}$의 비율만큼 늘어날 수 있는 것인데, 예를 들어 현재 블록의 크기가 1500만 gas라면, 다음 블록의 최대 크기는 $15,000,000 + (15,000,000/1024==14,648)=15,014,648$ 만큼의 크기를 가질 수 있게 된다는 말이며, 이러한 블록 크기 증가가 여러번 반복되어 최대 30,000,000 gas 크기까지 도달할 수 있다는 말이다.

결과적으로, validator는 합의를 통해 블록의 gas limit을 변경할 수 있으며, 블록의 모든 트랜잭션의 gas 소비량이 블록의 gas limit보다 작을 수 있도록 이를 조절하여야 한다. 블록의 사이즈가 임의대로 커질 수 있다면, 성능이 떨어지는 Full node는 공간 및 속도 요구사항을 충족시키지 못하여 네트워크의 속도를 따라잡을 수 없을 것이다. 블록이 클수록 다음 슬롯에 맞춰 처리하는 데 필요한 컴퓨팅 성능을 더 많이 요구하기 떄문에, 이는 적절히 조절되어야 할 것이다.

반응형

지난편에 이어서 이번 포스팅에서는 비트코인의 거래(Transaction)에 대해 한번 공부해보도록 해야겠다.

 

등장하는 단어들이 다소 어려운 감이 없지않아 있기 때문에, 정말 하나하나 다 설명하면서 넘어가보도록 하겠다.

 

비트코인 백서: 2. 거래

우리는 전자 화폐(electronic coin)를 디지털 서명의 체인으로 정의한다.

 

비트코인에서 정의한 전자화폐(가상화폐)는 바로 '디지털 서명의 체인'이라는 방식인 것이다. 이게 무슨 말일까?

우선 그 전에, 디지털 서명을 전자서명과 헷갈릴 수 있을 것 같아 이 둘의 차이점을 짚으면서 개념을 확인해보자. 차이점이라기 보다는 범주의 차이? 정도이다. 전자서명 안에 디지털서명이 있다.

전자서명?

미 전자 상거래법에서는 전자 서명을 전자적 수단에 의해 생성,전송,전달,수신 또는 저장되는 서명의 역할로 계약을 위해 포함되거나 논리적으로 만들어진 기호, 또는 프로세스라고 정의하고 있음.

즉, 비밀번호, PIN, 이메일 인증등이 포함된다고 할 수 있음.

디지털서명?

해싱, 서명, 검증 이 세 가지 알고리즘으로 이루어진 전자서명의 일종이라고 볼 수 있음. 디지털서명에 대해 좀 더 자세히 다루고 싶긴 하지만, 거기까지 가면 불필요하게 내용이 깊어질 듯 하여 일단은 넘어가도록 하겠다.

어쨋든, 디지털 서명이 어떤 역할을 하는지 알아보자면,

  1. 무결성 보장: 거래 데이터가 서명 과정을 통해 암호화되므로, 데이터가 전송 중에 변경되면 서명이 무효화됩니다. 이는 거래의 무결성을 보장한다.
  2. 비역전성: 한 번 거래가 서명되고 네트워크에 의해 확인되면, 거래를 실행한 사람은 그 거래를 부인할 수 없다.

계속 읽다보면 알겠지만, 비트코인은 화폐의 개념보다는, 디지털 서명과 이전 기록들(체인들)의 연속체라는 개념으로 받아들이는 것이 좋을 것이다. 

 

일단 이정도만 알고, 다음 과정으로 넘어가보자.

출처:  https://bitcoin.org/files/bitcoin-paper/bitcoin_ko.pdf

 

각 화폐 소유자는 자신에게 그 화폐를 보낸 직 전 거래 명세(the previous transaction) 및 그 화폐를 받는 다음 소유자의 공개키 (the public key of the next owner)를 해시 처리한 값에 디지털 방식으로 서명하고 이를 화폐 끝에 추가해 다음 소유자에게 송금한다. 수취인(payee)은 그 서명을 검증해 화폐 소유권의 체인을 검증할 수 있다.

 

잠깐 개념정리

1. 공개키와 개인키

다소 어려운 문장들인 것 같다. 천천히 살펴보자. 우선 여기에 공개키, 개인키라는 용어가 등장하는데, 비트코인에서는 타원곡선 디지털 서명 알고리즘(ECDSA: Eliptic Curve Digital Signature Algorithm)을 이용하여 전자서명(디지털서명)을 수행한다. 이 때 사용되는 key들이 바로 위 그림에 등장하는 공개키와 개인키인 것이다.

공개키는 같은 네트워크의 모든 참여자들이 알 수 있도록 하는 키이며 (검증 등에 사용된다.)

개인키는 본인 이외에는 아무도 몰라야 하는 키이다.(서명 등에 활용된다. )

 

2. 해시

비트코인에서의 해시(Hash)는 암호학적 해시(Cryptographical Hash)라고도 부르는데, 암호학적으로 무결?한 해시라는 말인 것 같다. 기본만 말하자면 해시는 일방향함수라고 할 수 있다. 즉, 역함수가 존재하지 않는 함수인데, 랜덤한 길이의 입력값에 대해 항상 같은 길이의 결과를 출력하는 알고리즘이라고 볼 수 있겠다. 비트코인에서 사용하는 해시알고리즘인 SHA-256의 경우, 랜덤한 길이의 Input에 대해 256-bit 길이의 출력값을 뱉는다.

 

그림이 너무 위에 있어 다시 그림을 가져왔다. 

출처:  https://bitcoin.org/files/bitcoin-paper/bitcoin_ko.pdf

 

위 그림에서 왼쪽부터 user 1, 2, 3이라고 해보자.

user1은 user2에게 비트코인을 송금하는 트랜잭션을 수행하고 싶다.

이 경우, 위에서 설명한대로 직전 거래 명세(user1이 가지고 있는 비트코인 거래 data: 위 그림에서는 첫 번째 블록에 대한 데이터이다.) + 다음 소유자(수취인)의 공개키(user2의 공개키)를 SHA-256으로 해싱하여 그 값을 본인(user 1)의 개인키를 이용하여 ECDSA 알고리즘에 서명하여 다음 소유자(user2)에게 송금한다.

그리고, 다음 소유자인 user2는 user1의 공개키를 이용하여 검증할 수 있다.

 

굵게 표시한 부분이 이해가 좀 힘들 수 있다. 그런데... 이정도 설명이 최선인 듯 하여 두세번 더 읽어보며 이해해보기 바란다. 

 

문제 및 해결?

이 과정의 문제는 화폐 소유자 가운데 이중지불(double spending)하지 않은 한 사람을 수취인(user2)가 검증할 수 없다는 점이다. 이에 대한 기존 사회의 솔루션은 신뢰받는 중앙통제기관이나 조폐국을 세우고 모든 거래마다 이중지급 여부를 점검하는 것이다. 거래를 마칠 때마다 이 화폐는 조폐국으로 회수되어 새로운 화폐로 발행돼야하며, 조폐국에서 직접 발행된 화폐만이 이중지급되지 않았다는 신뢰를 받는다(여러 인증 수단을 통해서...)

 

이 솔루션을 적용할 때 문제는 마치 은행처럼 모든 거래가 거쳐가야 하는 조폐국 운영 회사 또는 기관에 전체 통화체계의 운명이 달려있다는 것이다.

 

따라서 비트코인에는 직전화폐(이전 거래내역) 소유자가 앞서 어떤 거래에도 서명하지 않았음을 수취인에게 알릴 수단이 필요하다. 이런 목적에 따라 비트코인은 가장 앞선(가장 먼저 실행된) 거래 하나만을 인정하고, 뒤따르는 동일한 출처의 이중지급 시도를 모두 무시하도록 하는 솔루션이 필요하다.

 

이중지급 거래가 없음을 확인할 유일한 방법은 모든 거래를 인식하는 것 뿐이다. 조폐국 기반 모델에서, 그들은 모든 거래를 인식했고(서버 등의 중앙 데이터베이스를 통해.) 어느 거래라 최초의 거래인지를 인식하고 결정했다.

 

신뢰받는 제삼자 없이 이 방식을 달성하려면, 거래는 1. 공개적으로 알려져야하고, 2. 참가자가 받은 거래 순서의 이력(코인 송금)에 합의하는 시스템이 필요하다.

 

또한, 수취인(user2)에게는 각 거래 당시 그게 최초로 받은 것이라고 노드 다수가 동의했다는 증명이 필요하다. 

 

이를 해결하는 것이 다음 챕터에서 다룰 타임스탬프 서버이다.

반응형

+ Recent posts