2023-2학기/블록체인

Ethereum (account, address, block structure)

킹버거 2023. 11. 28. 18:05

안녕하세요. 오랜만에 돌아온 쿼카예요. 왜냐하면 지금 무진장 열받았거든요. 이번 학기에 블록체인 과목을 수강해서 고생하고 있는데요. 수업만으로는 이해하기 힘들어서 여기저기 검색해보면서 다시 정리해보려고 해요. 근데 저 블록체인 관심 없는데요. 이렇게까지 해야 할까요? 흠냐

 

* 본 게시글은 일개 학부생이 복습 목적으로 작성하는 것이므로 잘못된 내용이 포함되어 있을 수 있음을 알립니다. 참고용으로만 이용하시길 바랍니다. 

Ethereum 개요 

  • 이더리움이란 블록체인 기술을 기반으로 스마트 계약 기능을 구현하기 위한 분산 컴퓨팅 플랫폼이자 플랫폼의 자체 통화명
  • 비트코인은 정적인 거래내역만 기록하나, 이더리움은 정적기록 외에 코드(스마트 계약)도 저장
    • 스마트 계약: 블록체인에 코딩되어 있는 프로그램으로 금융, 부동산, 공증 등 다양한 형태의 계약을 처리
  • 이더리움에서 사용하는 암호 화폐인 이더(ETH)의 가장 작은 단위: Wei (= 10^-18 ETH)
    • 초기의 채굴 보상: 5 ETH (비트코인은 50 BTC)
  • Consensus Algorithm: PoW → PoS
    • PoW를 사용하던 Ethereum 1.0에서 PoS를 사용하는 Ethereum 2.0으로 전환 중에 있음 (Serenity 과정)
  • Cryptography 
    • Hash Function : Keccak-256 (SHA-3 최종 선정)
    • Signature : ECDSA (Private Key, message: 256 bits / Public Key, Signature: 512 bits)
  • Block creation : Every 12 seconds
  • Difficulty : 매 블록마다 설정 ( 평균 블록 생성 시간이 12초이므로 12초마다 설정)

Ethereum의 Account 개요

1) EOA (Externally owned Account)

- Bitcoin에서의 address와 동일한 개념

- public/private keypair로 구성 > 특정 사용자에게 귀속

- 두 개의 EOA 사이에서 발생하는 트랜잭션은 ETH(value)만 송금

- EOA의 address는 public key의 hash 값으로 생성됨 

 

2) CA (Contract Account) 

- code에 의해  controlled (일종의 프로그램)

- CA의 address는 'Contract creation' 트랜잭션을 보낸 sender의 address, nonce 값을 hash 한 값으로 생성됨

- 구체적으로는) sender account의 address와 nonce 값을 Encoding하고 Hash한 값 256bits중 마지막 160bits를 선택

 

* Ethereum에서 사용하는 Hash Function은 Keccak-256이므로 출력 256bits 중 마지막 160bits(20bytes)만 address로 사용

* 근데 교수님이 address는 256bits (즉, 32bytes)라고 번복하심. 왜일까? Keccak-256 사용하는 것 때문에 헷갈려 할까봐 편의상 정정하신 듯

* RLP는 Recursive Length Prefix의 약자로, Ethereum에서 데이터를 직렬화하고 인코딩하는 데 사용되는 방식

* KEC는 Keccak-256

Ethereum의 Account 구조 및 각 요소 

* nonce: 하나의 account에서 생성한 transaction의 수(일련번호라고 생각해도 이해하기 편할 듯). Block header에 포함된 nonce와는 다르게 카운터 용도로 사용됨. Nonce의 주요 목적은 트랜잭션의 순서를 추적하고, 두 번 이상의 동일한 트랜잭션이 발생하지 않도록 하는 것

  • nonce가 3이면 해당 계정은 해당 시점까지 총 세 개의 트랜잭션을 생성했고 해당 트랜잭션의 번호는 3이라는 것. 

* balance: 해당 account가 소유하고 있는 Wei의 양

* storage hash: Contract Account의 모든 데이터가 저장되어 있는 Merkle Patricia Tree의 root 값 

*code hash: EVM에서 실행되는 코드의 해시 값

      *CA에는 해당 계정에서 실행시킬 코드의 해시값

      *EOA에서는 코드를 저장할 수 없기 때문에 비어 있는 문자열의 해시 값

 

의문) EOA에서 code hash처럼 storage hash도 사용하지 않으므로 비어 있는 문자열의 해시 값으로 들어가려나?

 

Block Structure

 

Block header 요소

 

parentHash: previous block의 hash 값 

Nonce: 난이도목표 값 이하를 구할 때 입력 값으로 사용 (PoS에서는 사용 안 함)

Timestamp: 블록생성 시각(유닉스 시각)

ommersHash: Ommer(Uncle) block의 hash 값 

Beneficiary: 블록 채굴 보상금을 수령할 address

logsBloom: 사건 발생 유무를 알려주는 Bit Stream

Difficulty: 블록생성 난이도

extraData: 임의의 데이터, 주로 채굴자의 이름을 적음

Number: 상위의 조상 블록 개수

gasLimit: 블록에 담긴 트랜잭션들의 총 Gas(수수료)

gasUsed: 사용된 Gas 총량

mixHash: 난스를 찾을 때 사용된 시드 값

stateRoot: 상태데이터 트리의 루트 노드 해시값

transactionsRoot: 트랜잭션 데이터 트리의 루트 노드 해시값

receiptsRoot: 트랜잭션 영수증 트리의 루트노드 해시값

world state는 account's address: account's state 매핑 정보가 저장됨. 해당 state tree의 root 값이 Block header의 field 중 하나인 stateRoot에 저장됨.

* 한 block에 포함되는 최대 2개까지의 ommer block의 header는 각각 hash 되어 block header의 ommersHash field에 따로  저장된다. 

* ommer block에게 incentive를 제공하는 방식이 하나의 longest chain으로 수렴하는 걸 가속화해주는 원리
: ommer block도 보상을 받을 수 있기 때문에 참여자들이 여러 블록을 동시에 채굴하는 경우가 많아지고 이는 하나의 longest chain이 생성되는 걸 도와주는 꼴. (제 추측입니다.)