블록
블록은 체인에 있는 이전 블록의 해시를 포함하는 트랜잭션의 묶음입니다. 해시는 블록 데이터에서 암호학적으로 파생되기 때문에 블록들을 (체인 형태로) 서로 연결합니다. 이는 사기를 방지합니다. 과거의 어떤 블록에서든 하나의 변경이 발생하면 모든 후속 해시가 변경되어 이후의 모든 블록이 무효화되고, 블록체인을 실행하는 모든 사람이 이를 알아차릴 수 있기 때문입니다.
전제 조건
블록은 초보자도 쉽게 이해할 수 있는 주제입니다. 하지만 이 페이지를 더 잘 이해하기 위해 먼저 계정, 트랜잭션 및 이더리움 소개를 읽어보시기를 권장합니다.
블록이 필요한 이유
이더리움 네트워크의 모든 참여자가 동기화된 상태를 유지하고 트랜잭션의 정확한 기록에 합의할 수 있도록, 트랜잭션을 블록으로 묶습니다. 이는 수십(또는 수백) 개의 트랜잭션이 한 번에 커밋되고, 합의되며, 동기화된다는 것을 의미합니다.
Ethereum EVM illustrated (opens in a new tab)에서 발췌한 다이어그램
커밋 간격을 둠으로써 모든 네트워크 참여자가 합의에 도달할 수 있는 충분한 시간을 제공합니다. 트랜잭션 요청이 초당 수십 번 발생하더라도, 이더리움에서 블록은 12초마다 한 번씩만 생성되고 커밋됩니다.
블록의 작동 방식
트랜잭션 기록을 보존하기 위해 블록은 엄격하게 정렬되며(생성된 모든 새 블록은 부모 블록에 대한 참조를 포함함), 블록 내의 트랜잭션도 엄격하게 정렬됩니다. 드문 경우를 제외하고, 네트워크의 모든 참여자는 항상 정확한 블록 수와 기록에 동의하며, 현재 진행 중인 트랜잭션 요청을 다음 블록으로 묶기 위해 작업합니다.
네트워크에서 무작위로 선택된 검증자가 블록을 구성하면, 해당 블록은 네트워크의 나머지 부분으로 전파됩니다. 모든 노드는 이 블록을 블록체인의 끝에 추가하고, 다음 블록을 생성할 새로운 검증자가 선택됩니다. 정확한 블록 조립 과정과 커밋/합의 과정은 현재 이더리움의 "지분 증명 (PoS)" 프로토콜에 의해 지정됩니다.
지분 증명 (PoS) 프로토콜
지분 증명은 다음을 의미합니다.
- 검증 노드는 악의적인 행동에 대한 담보로 32 ETH를 예치 컨트랙트에 스테이킹해야 합니다. 증명 가능한 부정직한 활동은 해당 스테이크의 일부 또는 전부를 파괴하므로 네트워크를 보호하는 데 도움이 됩니다.
- 매 슬롯(12초 간격)마다 검증자가 무작위로 선택되어 블록 제안자가 됩니다. 이들은 트랜잭션을 함께 묶고, 실행하며, 새로운 '상태'를 결정합니다. 이 정보를 블록으로 포장하여 다른 검증자들에게 전달합니다.
- 새 블록에 대해 들은 다른 검증자들은 트랜잭션을 다시 실행하여 제안된 전역 상태 변경에 동의하는지 확인합니다. 블록이 유효하다고 가정하면, 이를 자신의 데이터베이스에 추가합니다.
- 검증자가 동일한 슬롯에 대해 충돌하는 두 개의 블록에 대해 듣게 되면, 포크 선택 알고리즘을 사용하여 가장 많은 스테이킹된 ETH의 지원을 받는 블록을 선택합니다.
블록에는 무엇이 포함되어 있나요?
블록에는 많은 정보가 포함되어 있습니다. 가장 높은 수준에서 블록은 다음 필드를 포함합니다.
| 필드 | 설명 |
|---|---|
slot | 블록이 속한 슬롯 |
proposer_index | 블록을 제안하는 검증자의 ID |
parent_root | 이전 블록의 해시 |
state_root | 상태 객체의 루트 해시 |
body | 아래에 정의된 여러 필드를 포함하는 객체 |
블록 body 본체에는 자체적인 여러 필드가 포함되어 있습니다.
| 필드 | 설명 |
|---|---|
randao_reveal | 다음 블록 제안자를 선택하는 데 사용되는 값 |
eth1_data | 예치 컨트랙트에 대한 정보 |
graffiti | 블록을 태그하는 데 사용되는 임의의 데이터 |
proposer_slashings | 슬래싱될 검증자 목록 |
attester_slashings | 슬래싱될 증명자 목록 |
attestations | 이전 슬롯에 대해 이루어진 증명 목록 |
deposits | 예치 컨트랙트에 대한 새로운 예치 목록 |
voluntary_exits | 네트워크를 종료하는 검증자 목록 |
sync_aggregate | 경량 클라이언트를 지원하는 데 사용되는 검증자의 하위 집합 |
execution_payload | 실행 클라이언트에서 전달된 트랜잭션 |
attestations 필드에는 블록의 모든 증명 목록이 포함되어 있습니다. 증명에는 여러 데이터를 포함하는 자체 데이터 유형이 있습니다. 각 증명에는 다음이 포함됩니다.
| 필드 | 설명 |
|---|---|
aggregation_bits | 이 증명에 참여한 검증자 목록 |
data | 여러 하위 필드가 있는 컨테이너 |
signature | data 부분에 대한 검증자 집합의 집계 서명 |
attestation의 data 필드에는 다음이 포함됩니다.
| 필드 | 설명 |
|---|---|
slot | 증명과 관련된 슬롯 |
index | 증명하는 검증자의 인덱스 |
beacon_block_root | 체인의 헤드로 간주되는 비콘 블록의 루트 해시 |
source | 마지막으로 정당화된 체크포인트 |
target | 최신 에포크 경계 블록 |
execution_payload의 트랜잭션을 실행하면 전역 상태가 업데이트됩니다. 모든 클라이언트는 execution_payload의 트랜잭션을 다시 실행하여 새 상태가 새 블록의 state_root 필드와 일치하는지 확인합니다. 이것이 클라이언트가 새 블록이 유효하고 블록체인에 추가하기에 안전한지 알 수 있는 방법입니다. execution payload 자체는 여러 필드가 있는 객체입니다. 실행 데이터에 대한 중요한 요약 정보를 포함하는 execution_payload_header도 있습니다. 이러한 데이터 구조는 다음과 같이 구성됩니다.
execution_payload_header에는 다음 필드가 포함됩니다.
| 필드 | 설명 |
|---|---|
parent_hash | 부모 블록의 해시 |
fee_recipient | 트랜잭션 수수료를 지불할 계정 주소 |
state_root | 이 블록의 변경 사항을 적용한 후의 전역 상태에 대한 루트 해시 |
receipts_root | 트랜잭션 영수증 트라이의 해시 |
logs_bloom | 이벤트 로그를 포함하는 데이터 구조 |
prev_randao | 무작위 검증자 선택에 사용되는 값 |
block_number | 현재 블록의 번호 |
gas_limit | 이 블록에서 허용되는 최대 가스 |
gas_used | 이 블록에서 사용된 실제 가스 양 |
timestamp | 블록 타임 |
extra_data | 원시 바이트 형태의 임의의 추가 데이터 |
base_fee_per_gas | 기본 수수료 값 |
block_hash | 실행 블록의 해시 |
transactions_root | 페이로드 내 트랜잭션의 루트 해시 |
withdrawal_root | 페이로드 내 인출의 루트 해시 |
execution_payload 자체에는 다음이 포함됩니다(트랜잭션의 루트 해시 대신 실제 트랜잭션 목록과 인출 정보가 포함된다는 점을 제외하면 헤더와 동일하다는 점에 유의하세요).
| 필드 | 설명 |
|---|---|
parent_hash | 부모 블록의 해시 |
fee_recipient | 트랜잭션 수수료를 지불할 계정 주소 |
state_root | 이 블록의 변경 사항을 적용한 후의 전역 상태에 대한 루트 해시 |
receipts_root | 트랜잭션 영수증 트라이의 해시 |
logs_bloom | 이벤트 로그를 포함하는 데이터 구조 |
prev_randao | 무작위 검증자 선택에 사용되는 값 |
block_number | 현재 블록의 번호 |
gas_limit | 이 블록에서 허용되는 최대 가스 |
gas_used | 이 블록에서 사용된 실제 가스 양 |
timestamp | 블록 타임 |
extra_data | 원시 바이트 형태의 임의의 추가 데이터 |
base_fee_per_gas | 기본 수수료 값 |
block_hash | 실행 블록의 해시 |
transactions | 실행할 트랜잭션 목록 |
withdrawals | 인출 객체 목록 |
withdrawals 목록에는 다음과 같이 구성된 withdrawal 객체가 포함되어 있습니다.
| 필드 | 설명 |
|---|---|
address | 인출한 계정 주소 |
amount | 인출 금액 |
index | 인출 인덱스 값 |
validatorIndex | 검증자 인덱스 값 |
블록 타임
블록 타임은 블록 사이의 시간을 의미합니다. 이더리움에서 시간은 '슬롯'이라는 12초 단위로 나뉩니다. 각 슬롯에서는 단일 검증자가 블록을 제안하도록 선택됩니다. 모든 검증자가 온라인 상태이고 완전히 기능한다고 가정하면 모든 슬롯에 블록이 생성되며, 이는 블록 타임이 12초임을 의미합니다. 그러나 블록을 제안하도록 호출되었을 때 검증자가 오프라인 상태일 수 있으며, 이는 슬롯이 때때로 비어 있을 수 있음을 의미합니다.
이 구현은 블록 타임이 확률적이고 프로토콜의 목표 채굴 난이도에 의해 조정되는 작업증명 (PoW) 기반 시스템과 다릅니다. 이더리움의 평균 블록 타임 (opens in a new tab)은 이에 대한 완벽한 예시이며, 새로운 12초 블록 타임의 일관성을 기반으로 작업증명에서 지분 증명으로의 전환을 명확하게 유추할 수 있습니다.
블록 크기
마지막으로 중요한 점은 블록 자체의 크기가 제한되어 있다는 것입니다. 각 블록의 목표 크기는 3,000만 가스이지만, 블록의 크기는 네트워크 수요에 따라 블록 한도인 6,000만 가스(목표 블록 크기의 2배)까지 증가하거나 감소합니다. 블록 가스 한도는 이전 블록의 가스 한도에서 1/1024 비율로 상향 또는 하향 조정될 수 있습니다. 결과적으로 검증자는 합의를 통해 블록 가스 한도를 변경할 수 있습니다. 블록 내의 모든 트랜잭션에서 소비된 총 가스 양은 블록 가스 한도보다 작아야 합니다. 이는 블록이 임의로 커질 수 없도록 보장하기 때문에 중요합니다. 블록이 임의로 커질 수 있다면, 성능이 떨어지는 풀 노드는 공간 및 속도 요구 사항으로 인해 점차 네트워크를 따라잡지 못하게 될 것입니다. 블록이 클수록 다음 슬롯에 맞춰 처리하는 데 더 많은 컴퓨팅 성능이 필요합니다. 이는 중앙 집중화의 원인이 되며, 블록 크기를 제한함으로써 이를 방지합니다.
더 읽어보기
도움이 된 커뮤니티 리소스를 알고 계신가요? 이 페이지를 편집하고 추가해 주세요!