Blockchain 2nd ethereum_core

목차
 이더리움 코어 설치(geth, mist)
 Metamask 를 사용하여 이더리움 전송하기
 이더리움 어카운트의 구조와 종류
 이더리움 개인키, 공개키, 어카운트 생성원리
 이더리움 블록, 트랜잭션의 구조와 동작원리
 이더와 가스의 개념
 RLP Encoding/HP Encoding
 머클 패트리시아 트리
 이더리움의 합의 알고리즘(ethash)
 이더리움 확장성 솔루션

이더리움 코어 설치 – geth 소스설치 (ubuntu)
 Golang 설치 : https://golang.org/dl/
 실행경로 추가 : /etc/profile or $HOME/.profile
 Geth 소스 다운로드후 빌드 : evm 등 모든 실행화일 생성시 make all
 실행경로 추가
$ curl -O
https://storage.googleapis.com/golang/go1.9.5.linux-
amd64.tar.gz
$ tar -C /usr/local -xzf go1.9.5.linux-amd64.tar.gz
$ export PATH=$PATH:/usr/local/go/bin
$
$ git clone https://github.com/ethereum/go-ethereum
$ cd go-ethereum
$ make geth
$ ihpark92@ubuntu:~/go-ethereum/build/bin$ ls
$ geth

이더리움 코어 설치 – 메인넷, 테스트넷 접속
 Geth 버전 확인
 메인넷 접속
ihpark92@ubuntu:~$ geth version
Geth
Version: 1.8.3-stable
Git Commit: 329ac18ef617d0238f71637bffe78f028b0f13f7
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.9.5
Operating System: linux
GOPATH=/usr/local/go
GOROOT=/usr/local/go
ihpark92@ubuntu:~$
ihpark92@ubuntu:~$ geth –-fast –-cache 1024 console
 Ropsten 테스트넷 접속 : PoW 테스트
 Rinkeby 테스트넷 접속 : PoA 테스트
ihpark92@ubuntu:~$ geth –-testnet –-fast –cache 1024 console
ihpark92@ubuntu:~$ geth –-rinkeby --fast –cache 1024 console

블록체인 동기화 방법
 전체 동기화(Full sync)
- 제네시스 블록부터 현재블록까지 모든블록을 동기화
 빠른 동기화(Fast sync)
- 최근의 상태, 트랜잭션, 리시트 등을 포함하는 블록헤더만을 동기화.
 경량 동기화(Light sync)
- 현재 상태정보만 동기화
- 특정 세부항목들의 검증이 필요할 경우 해당 세부항목 값을 포함하는 전체 정보를 다운로드하여 처리
// sync mode : fast, full, light
$ geth --syncmode "fast"

이더리움 코어 설치 – geth 바이너리 설치 (windows)
 windows용 geth 바이너리 다운로드
: https://ethereum.github.io/go-ethereum/downloads/

이더리움 코어 설치 – mist 설치 (windows)
 https://github.com/ethereum/mist/releases/

Genesis 블록을 생성하여 private net 구성하기
{
"config": {
"chainId" : 15,
"homesteadBlock" : 0,
"eip155Block" : 0,
"eip158Block" : 0
},
"nonce" : "0x0000000000000042",
"timestamp": "0x00",
"parentHash":
"0x0000000000000000000000000000000000000000000000000000000000000000",
"extraData": "0x00",
"gasLimit": "0x800000",
"difficulty": "0x400",
"mixhash":
"0x0000000000000000000000000000000000000000000000000000000000000000",
"coinbase": "0x3333333333333333333333333333333333333333",
"alloc": {
}
}
1. genesis.json 파일 작성
2. genesis.json 초기화
geth --datadir "C:ihparkGethdata" init "C:ihparkGethdatagenesis.json“
3. private net으로 geth 실행
geth --identity "PrivateNetwork" --datadir "C:ihparkGethdata" --port "30303" --rpc --rpcaddr "127.0.0.1"
--rpcport "8080" --rpccorsdomain "*" --nodiscover --networkid 1900 --nat "any"
--rpcapi "db,eth,net,web3,miner" console

 Private net 을 구성하기 위해 기본적으로 갖추어야 할 사항
 동일한 genesis.json
 동일한 --networkid<번호>
 노드 탐색을 위한 부트스트랩 노드

 노드 1(부트 노드)
 노드 2(일반 노드)
 노드 3(마이너 노드) : 노드 2와 동일한 방법으로 노드를 구동
 private net 연결확인
$ geth --datadir "private-data" init genesis.json
$ geth --datadir "private-date" --networkid 15
> admin.nodeInfo.enode
"enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a
4cac9f77166ad92a0@[::]:30303",
$ geth --datadir "private-data" init genesis.json
$ geth --datadir "private-date" --networkid 15 console
>admin.addPeer("enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a
82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@172.31.7.182:30303“)
> personal.newAccount()
> miner.setEtherbase(eth.accounts[0])
> eth.coinbase
> miner.start(1) // 쓰레드 1개로 마이너 구동, 마이닝 종료시 miner.stop()
> net.peerCount
2
> admin.peers
... // 접속된 노드 정보 출력

private net 에서 마이닝하기
 잔액조회
 마이닝 : miner.start(), miner.stop()
> eth.accounts
["0x6f45ffa37ed51bc77f7476998c3d71221240b12e"]
> eth.getBalance(eth.coinbase)
10000000000000000000
>
> miner.start()
INFO [04-02|22:55:39] Updated mining threads threads=0
INFO [04-02|22:55:39] Transaction pool price threshold updated
price=18000000000
null
> INFO [04-02|22:55:39] Starting mining operation
INFO [04-02|22:55:39] Commit new mining work number=69 txs=0
uncles=0 elapsed=132.014µs
> INFO [04-02|22:55:39] Successfully sealed new block number=69
hash=61e6ef…61a88f
INFO [04-02|22:55:39] 🔨 mined potential block number=69
hash=61e6ef…61a88f
INFO [04-02|22:55:40] Successfully sealed new block number=70
hash=81a7e6…a68b62
INFO [04-02|22:55:40] 🔨 mined potential block number=70
hash=81a7e6…a68b62
90000000000000000000
95000000000000000000
> web3.fromWei(eth.getBalance(eth.coinbase), "ether");
295
310
350
350
 마이닝중 잔액조회

Metamask 이용하여 이더리움 전송하기
 테스트 이더 받기

Metamask 이용하여 이더리움 전송하기

이더리움 vs 비트코인
 이더리움 : 스마트 컨트랙트 실행에 중점을 둔 플랫폼(World Computer)
 복잡하고 다양한 기능을 제공
 튜링 완전성 스크립트 언어를 지원(Solidity)
 어카운트(Account) 기반
 합의 알고리즘(Ethash) : 작업증명 + 지분증명 -> 지분증명
 블록 생성시간 : 평균 12초, 평균 12 TPS
 비트코인 : 거래에 중점을 둔 화폐(Crypto Currency)
 단순하지만 견고한 구조
 튜링 불완전한 단순한 스택 기반의 스크립트 언어를 지원
 UTXO 기반
 합의 알고리즘(SHA256) : 작업증명
 블록생성시간 : 평균 10분. 평균 7 TPS

이더리움 어카운트
 외부소유 어카운트 (EOA : Externally Owned Account)
 일반적으로 거래에 사용되는 사용자의 지갑주소
 개인키(Private key)를 사용하여 트랜잭션을 생성하고 실행
 컨트랙트 어카운트 (CA : Contract Account)
 스마트 컨트랙트의 주소
 랜덤넘버를 생성하거나 운영체제를 조작하는 API는 호출할수 없음
 자신이 직접 트랜잭션을 실행할수 없음

EOA와 CA의 동작상의 차이
 EOA
 일반적인 EOA 간의 거래, EOA에서 CA로의 거래는 이더의 전송을 의미
 CA
 EOA나 다른 컨트랙트의 코드에 의해서만 실행가능

개인키, 공개키를 이용한 어카운트 주소 생성
 이더리움은 암호화 알고리즘으로 256비트 ECDSA 알고리즘 사용 (secp256k1)
 개인키 : 32바이트 크기의 1 to 2^256-1 사이의 랜덤한 모든값
 형식 : 3a1076bf45ab87712ad64ccb3b10217737f7faacbf2872e88fdd9a537d8fe266
 공개키 : 타원곡선곱셈함수를 사용하여 개인키를 입력을 받아 생성되는 64바이트의 값
 형식 :
04836b35a026743e823a90a0ee3b91bf615c6a757e2b60b9e1dc1826fd0dd16106f7bc1e8179f665015f43c
6c81f39062fc2086ed849625c06e04697698b2185
 어카운트 주소 : 공개키를 keccak256 hash 함수를 통한 결과값인 32바이트 값에서 하위 20바이트
 형식 : 0x7e5f4552091a69125d5dfcb7b8c2659029395bdf

이더리움 블록
 https://etherscan.io/block/5529578

블록의 trie 데이타
 stateRoot, txHash, receiptHash만 블록체인에 직접 저장
 머클 패트리시아 트리의 형태로 저장
 이더리움의 데이터 유형
 영구 데이터 : 트랜잭션(Transaction), 영구적으로 블록에 저장
 임시 데이터 : 계정의 잔액(State), 별도의 DB에 저장

블록과 State trie의 관계
 이더리움은 단 하나의 State trie를 가지고 있으며, 지속적으로 업데이트됨
 이더리움의 모든 계정에 대한 key-value 쌍을 가지고 있음

State trie와 Storage trie의 관계
 Storage trie는 모든 Smart Contract의 State Data가 저장되어 있는곳
 각각의 이더리움 어카운트는 고유의 저장공간을 가지고 있음

블록, State trie, Storage trie의 관계

트랜잭션(Transaction)의 구조
 다른 어카운트나 컨트랙트로 보낼 데이타 구조체로서 전자서명으로 암호화
 어카운트에서 다른 어카운트로 이더를 전송하거나 스마트 컨트랙트의 특정함수를 호출할때
 트랜잭션의 발신자는 트랜잭션이 유효함을 입증하기 위해 ECDSA 알고리즘을 사용하여 개인키로 서명
 트랜잭션의 실행비용은 Price * GasLimit로 계산
type Transaction struct {
data txdata
// caches
hash atomic.Value
size atomic.Value
from atomic.Value
}
type txdata struct {
AccountNonce uint64 `json:"nonce" gencodec:"required"`
Price *big.Int `json:"gasPrice" gencodec:"required"`
GasLimit uint64 `json:"gas" gencodec:"required"`
Recipient *common.Address `json:"to" rlp:"nil"` // nil means contract creation
Amount *big.Int `json:"value" gencodec:"required"`
Payload []byte `json:"input" gencodec:"required"`
// Signature values
V *big.Int `json:"v" gencodec:"required"`
R *big.Int `json:"r" gencodec:"required"`
S *big.Int `json:"s" gencodec:"required"`
// This is only used when marshaling to JSON.
Hash *common.Hash `json:"hash" rlp:"-"`
}

트랜잭션(Transaction)의 구조
 AccountNonce : 발신자에 의해 보내진 트랜잭션의 갯수로 0부터 시작
 Price : 각 실행단계에서 지급되는 Gas 비용으로 Wei 단위
 GasLimit : 트랜잭션 수행시 지급가능한 최대범위
 Recipient : 메세지 수신처의 주소, 수신자가 nil로 비어있는 경우는 트랜잭션으로 인해 새로운
Contract Account가 생성됨을 의미
 Amount : 수신처로 전송할 이더의 양으로 Wei 단위
 Payload : 옵션필드로 메세지 호출시 매개변수등이 전달
 V,R,S : ECDSA 전자서명을 만드는데 사용되는 값(V는 1바이트로 ECDSA가 복원한 공개키 4개중 어
떤공개키를 사용할지 지정한값이고, R, S는 32바이트 서명데이타)

트랜잭션의 암호화
 공개키 암호화 – 비트코인
 암호화시 공개키를 사용하기 때문에 해당 공개키에 대응하는 개인키로만 복호화 가능
 전자서명 암호화 – 이더리움
 암호화시 개인키를 사용하기 때문에 공개키를 가진 모든 사용자는 암호화된 메시지 복호화 가능
 이더리움에서는 비대칭키 및 암호화 알고리즘으로 256비트 ECDSA를 사용

트랜잭션의 서명
var rawTx = {
nonce: web3.toHex(0),
gasPrice: web3.toHex(20000000000),
gasLimit: web3.toHex(100000),
to: '0x687422eEA2cB73B5d3e242bA5456b782919AFc85’,
value: web3.toHex(1000),
Data: '0xc0de'
};

트랜잭션 확인
 https://ropsten.etherscan.io/tx/0x8b69a0ca303305a92d8d028704d65e4942b7ccc9a99917c8c9e940c9d57a9662

함수호출 트랜잭션의 Payload(Data) 필드 구성
 https://ropsten.etherscan.io/tx/0xaf4a217f6cc6f8c79530203372f3fbec160da83d1abe048625a390ba1705dd57

함수호출 트랜잭션의 Payload(Data) 필드 구성
 함수 transfer(address _to, uint256 _value) 호출
 keccak256(‘transfer(address,uint256)’) =
a9059cbb2ab09eb219583f4a59a5d0623ade346d962bcd4e46b11da047c9049b
 address _to = 0x7adee867ea91533879d083dd47ea81f0eee3a37e
0x0000000000000000000000007adee867ea91533879d083dd47ea81f0eee3a37e
 uint256 _value = 0x2ab486cedbffff
0x000000000000000000000000000000000000000000000000d02ab486cedbffff

Contract Account 주소 생성
 Recipient 필드가 null로 비어있는 경우 새로운 Contract Account 생성
 address = keccak256(rlp_encode(creator_account, creator_account_nonce))[12:]
 트랜잭션의 Sender 주소와 nonce 값으로 Contract Account의 주소는 이미 확정되어있음

트랜잭션의 검증
/**
* Determines if the signature is valid
* @return {Boolean}
*/
verifySignature () {
const msgHash = this.hash(false)
// All transaction signatures whose s-value is greater than secp256k1n/2 are
considered invalid.
if (this._homestead && new BN(this.s).cmp(N_DIV_2) === 1) {
return false
}
try {
let v = ethUtil.bufferToInt(this.v)
if (this._chainId > 0) {
v -= this._chainId * 2 + 8
}
this._senderPubKey = ethUtil.ecrecover(msgHash, v, this.r, this.s)
} catch (e) {
return false
}
return !!this._senderPubKey
}
/**
* ECDSA public key recovery from signature
* @param {Buffer} msgHash
* @param {Number} v
* @param {Buffer} r
* @param {Buffer} s
* @return {Buffer} publicKey
*/
exports.ecrecover = function (msgHash, v, r, s) {
var signature = Buffer.concat([exports.setLength(r, 32),
exports.setLength(s, 32)], 64)
var recovery = v - 27
if (recovery !== 0 && recovery !== 1) {
throw new Error('Invalid signature v value')
}
var senderPubKey = secp256k1.recover(msgHash, signature, recovery)
return secp256k1.publicKeyConvert(senderPubKey, false).slice(1)
}
 Message hash와 서명을 사용하여 공개키를 복구
 4개의 공개키를 복구가능하며, 4개중 어느 공개키를 선택할지가 서명에 포함되어 있음
 복구한 공개키를 사용하여 서명이 올바른 개인키로 생성된것인지 검증

트랜잭션의 처리과정
 트랜잭션을 개인키로 ECDSA 전자 서명 암호화
 해당 트랜잭션을 마이너를 포함한 네트워크에 연결된 모든 노드에 브로드캐스팅
 마이너는 해당 트랜잭션의 유효성 검증
 문법에 맞게 구성되어 있는지
 개인키에 해당하는 공개키를 사용하여 해당 전자서명은 유효한지
 사용자의 어카운트에 있는 넌스(nonce)값과 맞는지
 트랜잭션 처리비용 계산 : Gas limit * Gas price
 모든 검증작업이 끝나면 최종 실행을 위해 트랜잭션풀에 해당 트랜잭션을 등록
 마이너는 트랜잭션풀에서 가스실행비용이 높은순으로 트랜잭션을 선택
 수신자 주소에 따라 실행
 EOA : 수신자 주소로 이더를 전송
 CA : 해당 컨트랙트 코드를 수행

이더(Ether)
 이더리움 시스템에서 사용되는 암호화폐
명칭 WEI 기준 Ether 기준
WEI 1 0.000000000000000001
Ada 1000 0.000000000000001
Fentoether 1000 0.000000000000001
Kwei 1000 0.000000000000001
Mwei 1000000 0.000000000001
Babbage 1000000 0.000000000001
Pictoether 1000000 0.000000000001
Shannon 1000000000 0.000000001
Gwei 1000000000 0.000000001
Nano 1000000000 0.000000001
Szabo 1000000000000 0.000001
Micro 1000000000000 0.000001
Microether 1000000000000 0.000001
Finney 1000000000000000 0.001
Milli 1000000000000000 0.001
Milliether 1000000000000000 0.001
Ether 1000000000000000000 1
Einstein 1000000000000000000000 1000
Kether 1000000000000000000000 1000
Grand 1000000000000000000000 1000
Mether 1000000000000000000000000 1000000
Gether 1000000000000000000000000000 1000000000
Tether 1000000000000000000000000000000 1000000000000

가스(Gas)
 트랜잭션의 비용지불에 사용되는 운영토큰
 이더가 거래소등에서 거래가 되며 변동성이 크기때문에, 변동성이 없는 가스를 만들어 트랜
잭션 비용지불에 사용
 스마트컨트랙트의 실행이나 트랜잭션이 실행될때 이더리움 시스템의 리소스를 사용하기때문
에 이러한 사용에 대한 비용을 지불
 마이닝에 대한 수수료로 채굴자에게 지불
 무분별한 트랜잭션이나 악의적인 스마트 컨트랙트의 실행을 방지하기 위한 목적으로도 사용
 트랜잭션에 사용되는 비용은 "가스 총량 * 가스 가격"으로 계산
 트랜잭션에서의 이 비용이 높을수록 해당 트랜잭션은 채굴자에 의해 우선적으로 선택
 블록가스 총량(Block Gas Limit)은 한 블록에 담을수 있는 가스의 총량으로 현재 한블록당
블록가스 총량은 6,700,000 가스
 하나의 트랜잭션당 최소 처리비용은 21,000 가스

Gas price 계산
https://ethgasstation.info/

트랜잭션의 수행후 정상종료
 GasLimit 값으로 초기화가 되면서 GasLimit * Price 에 해당하는 이더가 사용자의 계좌에
서 차감
 최종 트랜잭션이 수행된후에는 남은 가스는 다시 사용자에게 반환

트랜잭션 수행과정에서 가스부족
 트랜잭션이 시작된후 완료되기 전에 가스를 다 사용하게 되면 진행중인 트랜잭션은 취소가
되고 revert
 사용한 가스는 채굴자에게 보상으로 지급되기 떄문에 반환되지 않음

RLP 엔코딩
 다양한 복잡한 형식의 데이타를 하나의 정형화된 형식으로 직렬화하여 저장하거나 전송
 이더리움 내부에서 임의의 길이의 배열이나 문자를 엔코딩하기위해 개발된 엔코딩 패키지
 이더리움 헤더의 state root, transaction root, receipt root와 통신 프로토콜상의 메시지등
이더리움에서 전체적으로 사용
 기존의 Base64, 유니코드, UTF-8등 다양한 엔코딩 방식에 비해 엔코딩 과정이 단순하고 바
이트단위의 일관성을 확보하기 쉬운 장점
 RLP 엔코딩은 아이템(item)을 단위로 사용
 바이트배열로 변환이 될 스트링 : ["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]
 스트링의 배열 : ["cat", "horse"] : "cat", "horst", ["cat", "horst"]

RLP 엔코딩 알고리즘
 1바이트의 데이타가 [0x00, 0x7f] 사이의 값이면 해당 바이트를 그대로 사용
 RLP(0x01) = 0x01, RLP(0x7f) = 0x7f
 스트링의 길이가 0~55 바이트인 경우, 0x80에 스트링의 길이를 더한값을 앞에 붙이고 이어
서 스트링을 붙임. 따라서 첫번째 바이트는 [0x80, 0xb7] 사이의 값을 가짐.
 RLP("hello world") = [0x8b, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x77, 0x6f, 0x72, 0x6c,
0x64]
: "hello world" 길이는 11(0x0b), 0x8b = 0x80 + 0x0b
 스트링의 길이가 55바이트를 넘어가는 경우, 0xb7에 스트링의 길이값의 바이트값을 더하고,
스트링의 길이를 이어서 붙인후, 스트링의 바이트를 붙임. 첫번째 바이트는 [0xb8, 0xbf] 사
이의 값을 가짐.
 RLP("aaa...") [1024개의 a로 이루어진 스트링] = [0xb9, 0x04, 0x00, 0x61, 0x61, …]
: 0xb9 = 0xb7 + 0x02 (스트링 사이즈가 1024이며, 이는 0x0400(0x04, 0x00,
즉 길이의 바이트수는 2)

RLP 엔코딩 알고리즘
 배열의 아이템들이 RLP 엔코딩된 아이템의 총길이가 0~55 바이트 사이인 배열인 경우, 0xc0에
각각 아이템들을 RLP엔코딩한 값들의 길이를 더하고 각각의 아이템을 RLP엔코딩한 데이타를
이어 붙임. 첫번째 바이트는 [0xc1, 0xf7] 사이의 값을 가짐.
 RLP([“hello”, “world”]) = [0xcc, 0x85, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x85, 0x77, 0x6f,
0x72, 0x6c, 0x64]
: RLP("hello") = 0x85, 0x68, 0x65, 0x6c, 0x6c, 0x6f,, 즉 길이는 6
RLP("world") = 0x85, 0x77, 0x6f, 0x72, 0x6c, 0x64, 즉 길이는 6
따라서 0xcc = 0xc0 + 0x06 + 0x06
 배열의 아이템들이 RLP 엔코딩된 아이템의 총길이가 55보다 큰경우, 0xf7에 각각 아이템들
의 RLP 엔코딩한 결과의 길이를 더한 길이값의 바이트값을 더하고, 각각 RLP엔코딩한 아이
템들의 길이값의 합을 붙이고, 이어서 각각 아이템들의 RLP 엔코딩된 값을 이어붙임. 이와같
이 3개 파트로 구성되며, 첫번째 바이트는 [0xf8, 0xff] 사이의 값을 가짐.
 RLP("a...", "a...") [a 50개로 이루어진 배열] = [0xf8, 0x66, 0xb2, 0x61..., 0xb2,, 0x61...]
: 0xf8 = 0xf7 + 0x01 (a 50개로 이루어진 배열의 RLP 엔코딩결과의 길이는 51, 2개이기
때문에 총 102(0x66), 즉 전체길이는 0x66 1바이트로 표현됨
0x66 = 각각 아이템 배열의 RLP 엔코딩된 전체길이

RLP 디코딩 알고리즘
 디코딩 과정
 입력 데이타의 첫번째 바이트에 따라, 데이타의 타입과 아이템의 갯수를 파악
 데이타의 유형 및 오프셋에 따라 데이타를 디코딩
 나머지 입력데이타를 계속해서 디코딩
 데이타의 유형 및 오프셋을 디코딩하는 규칙
 첫번째 바이트가 [0x00, 0x7f] 사이의 값이면 그값 자체가 문자 데이터
 첫번째 바이트가 [0x80, 0xb7] 사이의 값이면 문자열이고, 첫번째 바이트에서 0x80을 뺀 값
이 문자열의 길이
 첫번째 바이트가 [0xb8, 0xbf] 사이의 값이면, 첫번째 바이트에서 0xb7을 뺀값이 바이트로 표
현된 RLP 아이템의 갯수가 되고, 이어서 그 갯수만큼 문자가 이어짐
 첫번째 바이트가 [0xc0, 0xf7] 사이의 값이면, 배열을 의미하고, 첫번째 바이트에서 0xc0를
뺀값이 배열의 갯수를 의미
 첫번째 바이트가 [0xf8, 0xff] 사이의 값이면, 배열을 의미하고, 첫번째 바이트에서 0xf7을 뺀
값이 아이템의 갯수이고, 이어서 RLP 엔코딩되어 연결된 데이타가 첫번째 바이트 이후에 이어
짐

HP(Hex Prefix) 엔코딩
 Path : 3-2-3
 Root: {1: 'Dog', 2: B, 3: A}
 A: {1: C, 2: D, 3: 'Cat'}
 B: {1: 'Goat', 2: 'Bear', 3: 'Rat'}
 C: {1: 'Eagle', 2: 'Parrot', 3: E}
 D: {1: 'Shark', 2: 'Dolphin', 3: 'Whale'}
 E: {1: 'Duck', 2: 'Chinken', 3: 'Pig'}
 위의 자료구조를 통해 다음의 용어를 정의
 키(Key) : 왼쪽의 Root, A, B, C, D, E
 노드(Node) : 키와 연관된 오른쪽 요소 (예를 들어 {1: 'Dog', 2: B, 3: A})
 값(Value) : 노드의 모든 요소는 key-value 구조로 구성되어 있으며, value는 요소의 오른쪽 값이
며, 위의 예에서는 value는 키가 될수도 있고, 동물이름(Dog, Goat, Gear 등)이 될수도 있음.
 니블(Nibble) : 4비트의 hex form. 예를 들어 0x1, 0x4, 0xf 등

HP(Hex Prefix) 엔코딩의 목적
 리프(Leaf)노드와 확장(Extension)노드를 구분하기 위해서 선행구분자를 붙이기 위한것
 리프노드는 더이상 확장이 되지않는 값을 가지는 최종노드
 확장노드는 다음 노드를 가리키는 확장되는 노드
 리프노드는 "terminator"로 끝나며 이것은 0x10에 해당
 HP 엔코딩의 목적
 "terminator"가 없이 리프노드와 확장노드를 구분
 경로를 짝수길이로 변환
 HP 엔코딩 알고리즘
 입력에 "terminator"가 있다면 "terminator"를 제거
 리프노드와 확장노드에 따라 하기의 prefix를 앞에 추가
 만약 prefix가 0x0, 0x2이면 경로를 짝수로 만들기 위해 패딩 0을 붙여서 0x00, 0x20으로 만들어줌
 prefix를 경로에 추가
node type path length | prefix hexchar
--------------------------------------------------
extension even | 0000 0x0
extension odd | 0001 0x1
leaf even | 0010 0x2
leaf odd | 0011 0x3

HP(Hex Prefix) 엔코딩의 예
 > [ 1, 2, 3, 4, 5]
 '11 23 45'
 > [ 0, 1, 2, 3, 4, 5]
 '00 01 23 45'
 > [ 0, f, 1, c, b, 8, 16]
 '20 0f 1c b8'
 > [ f, 1, c, b, 8, 16]
 '3f 1c b8'
- [1,2,3,4,5] 는 마지막에 16(0x10)이 없이 때문에 리프노드가 아닌
확장노드 (0x0, 0x1중 선택가능)
- 경로가 홀수개이기 때문에 0x1 선택
- 경로는 짝수로 만들어야 하기 때문에 앞에 prefix 1을 붙여 11
- 나머지는 각 경로를 2개씩 묶어서 짝수로 해서 23, 45.
- 최종 경로는 11 23 45

머클 패트리시아 트리
{
'cab8': 'dog',
'cabe': 'cat',
'39': 'chicken',
'395': 'duck',
'56f0': 'horse'
}
 이더리움에서 노드는 위와같이 key-value의 형태로 저장
 key는 value의 hash 값으로 이루어짐
 value는 17개의 요소로 구성되며 첫 16개의 요소는 위의 그림과 같이 hex 값을 나타내고 마지막 17번
째 요소에 노드가 가지고 있는 데이타가 저장
 key값에 해당하는 hash 값은 "database lookup" 에 사용되는데, 이는 레벨DB로 저장되어 있는 데이타
베이스에서 특정 노드를 검색하는데 사용
 value는 "tree lookup"에 사용되며, 이는 기수트리에서 패스를 통해 데이타를 찾는데 사용

머클 패트리시아 트리
 데이타셋에 포함되어있는 395 키에 해당하는 값을 찾는 과정(TDL, TTL로 나누어짐)
 키값 395는 패스로 3,9,5 로 분리를 하여 순서대로 패스에 사용
 rootHash에서 패스에 해당되는 연관된 rootNode를 레벨DB에서 검색합니다. (TDL)
 rootHash에서 첫번째 경로인 3에 해당하는 값 hashA 를 검색합니다. (TTL)
 DB에서 hashA를 검색한후에(TDL), hashA의 9번째 인자를 검색하여 hashC임을 확인합니다.
(TTL)
 DB에서 hashC를 검색한후에(TDL), hashC의 5번째 인자를 검색하여 hashD임을 확인합니다.
(TTL)
 이 단계에서 검색경로(395)가 종료되기 때문에 이때 hashD 의 값이 최종 값이며, 이는 "duck"임을
알수 있습니다.
 value를 찾기위한 경로는 기수트리(Radix trie)가 사용되고, 트리의 각 노드에서 특정 노드의
value 가 변경되면 머클트리의 특성에 따라 rootHash가 변경

개선된 머클 패트리시아 트리
 데이타의 끝까지 분기되는 경로가 없는 경우(56f0)
 리프(leaf) 노드를 정의하여 메모리 낭비를 개선
 기존에 16개의 값을 저장하는 공간을 값 하나만 저장하는 공간으로 변경하여 메모리를 절약
 기수트리에서 메모리 낭비를 없애기 위해 분기가 발생하지않는 이어진 경로를 하나로 합쳐서 메모
리를 절약하는 방법에 해당

 중간에 분기되는 경로가 있는(cab8, cabe)
 확장(extension) 노드를 정의하여 메모리 낭비를 개선

 나머지 리프노드를 모두 재정의한 최적화된 메모리 구조

 HP 엔코딩을 하여 확장노드와 리프노드에 prefix를 추가한 최종 패트리시아 트리

도식화한 머클 패트리시아 트리

이더리움의 합의 알고리즘(작업증명)

메모리 기반의 합의 엔진 이대시(ethash)
 비트코인의 합의 알고리즘은 강력한 Hash연산이 필요하여, 이러한 Hash 연산에 특화된
ASIC 장치가 출현
 ASIC 장비로 인해 채굴자는 점점 연산력이 대형화되고, 중앙집중화
 이더리움의 합의 엔진인 이대시(Ethash)은 기본적으로 Hash 계산에 특화된 ASIC 장비를 무
력화
 Hash 연산이 중앙집중화되는것을 막고, 경량 클라이언트에서 블록을 검증할수 있는것을 목
표로 개발
 ASIC 장비를 무력화하기 위해 메모리를 쓰는 방식을 채택
 컴퓨터 메모리상의 일정량의 데이타를 읽은후 이것을 nonce와 함께 hash 계산하는 방식을
반복
 ASIC 장비가 무력화되어 일반 PC에서 GPU를 사용한 마이닝이 가능
 10~15초마다 새로운 블록이 생성되도록 설계되어 있으며, DAG 알고리즘을 사용

이대시(ethash) DAG 생성
 geth 클라이언트에서 마이닝을 동작시키면 캐시영역을 확보하기위해 시드해시를 생성
 시드해시로부터 생성된 약 2GB 정도의 캐시 데이타집합을 DAG(Directed Acyclic Graph)
파일
 30,000 블록을 주기로 이 DAG 파일 전체를 다시 재생성하게 되며, 이러한 30,000 블록 단
위를 에포크(Epoch)
 시드해시는 각각의 에포크(epoch)마다 달라지게 됨
 첫번째 에포크에서 시드해시는 0으로 이루어진 32바이트의 hash 값. 이어지는 에포크에는
이전 시드해시의 hash값이 다시 새로운 시드해시로 사용되어짐

이대시(ethash) DAG 생성
 DAG화일과 cache 크기는 30000 블록(에포크)마다 재계산되어 생성되며, 블록이 증가될수
록 선형적으로 증가하도록 되어있고, 현재 2048 에포크까지 크기가 미리 계산되어 있음

이대시(ethash) 마이닝 알고리즘
1. 이전 블록의 헤더와 임의로 추정된 nonce를 keccak256 해시를 하여 첫번째 mixHash를 구성
2. 첫번째 mixHash를 사용하여 DAG로부터 첫번째 페이지를 추출
3. 이더리움의 믹싱함수를 사용하여 추출된 DAG의 첫번째 페이지와 첫번째 mixHash로부터 다음번 mixHash를 생성
4. 이 과정을 64회 반복하여 64번째 mixHash를 생성
5. 64번째 mixHash값을 사용하여 32바이트의 mixDigest 값을 구성
6. 믹스다이제스트값과 미리 정의된 32바이트의 마이닝 목표값과 비교하여 믹스다이제스트값이 마이닝목표값보다 작
거나 같다면 nonce는 성공한것으로 판단하고 이 nonce 값을 블록에 포함하여 다른 노드들에 브로드캐스팅
6.1 만약 믹스다이제스트값이 마이닝목표값보다 크다면 nonce 값을 하나 증가하여 앞의 과정을 반복
m : mixHash
n : nonce
Hn(ex) : nonce와 mixHash를 제외한 새로운 블록의 헤더
Hn : 블록의 nonce
d : 대용량 DAG 화일

이대시(ethash) 마이닝 알고리즘

이더리움의 P2P 네트워크
 완전 분산형 P2P 토폴로지로 구성 : 연결된 모든 노드는 같은 역할과 기능을 수행
 이더리움 지갑, Mist, Geth 모두 하나의 노드
 이론적으로 모든 노드가 블록체인의 모든 데이터를 동기화해야 효율적으로 운영가능
ethernodes.org

이더리움의 P2P 프로토콜 – RLPx/devP2P
 P2P 네트워크상에서 일반전송과 애플리케이션간 통신을 위해 사용하는 암호화된 피어간 네
트워크 프로토콜
 피어간의 노드를 탐색하기 위한 기능
 ECDSA 방식으로 서명된 UDP 프로토콜과 암호화된 TCP 프로토콜
 이더리움 전반에 걸쳐 사용되는 P2P 네트워크 기능이 모두 포함
 이더리움 노드간의 P2P 연결, 노드 디스커버리, eth(블록체인 동기화), shh(whisper),
bzz(swarm) 프로토콜 등 상위 프로토콜에서 공통으로 사용하는 기반 프로토콜
 먼저 노드 디스커버리 프로토콜을 통해 노드를 찾은후 eth, shh, bzz등 어떤 응용 프로토콜을
사용할것인지를 결정

부트스트랩 노드
 일반노드가 이더리움 네트워크에 연결되면 최초 탐색을 위해 부트스트랩 노드에 접속하여 연결된 노드
의 목록을 받은후 해당 노드들과 접속
 부트스트랩 노드의 작동순서
 부트스트랩노드는 항상 작동하며, 일정시간 접속했던 노드들의 목록을 유지
 새로운 피어노드가 최초 접속시 연결되어, 지난시간동안 접속했던 노드들의 목록을 공유
 공유받은 목록으로 피어노드들에 연결한후에 부트스트랩 노드와의 연결을 종료
 이더리움 네트워크에서 부트스트랩 노드에 연결하는 방법
 geth 구동시 하드코딩된 부트스트랩 노드 목록을 참고하여 연결
 geth 구동시 –bootnodes 옵션을 사용하여 부트스트랩 노드를 직접 지정하여 연결
 geth 실행중 콘솔상에서 admin.addPeer(“enode URL”) 을 사용하여 노드 지정후 연결
 geth 구동시 정적노드 기능을 사용하여 연결할 노드를 지정하여 연결
 geth 데이터 디렉토리에 static-nodes.json 파일 생성
 static-nodes.json 파일에 “enode URL” 을 지정
 enode URL : ECDSA를 사용하여 개인키로 서명한 512비트의 공개키
enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e140724
1d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301

노드 디스커버리 프로토콜
 UDP기반 RPC 프로토콜로 ping, pong, findnode, neighbors 패킷타입으로 다른노드 탐색
패킷타입 패킷타입 값 설명
ping 1 노드가 온라인 상태인지 확인. ping을 받은 노드는 pong 패킷을 보내 응답하고, 연결되어 있는 피어 노드 중
첫번째 노드에게 자신의 ping을 보냄
pong 2 ping에 대한 응답패킷
findnode 3 목표노드의 주변에 위치한 피어노드들에게 전달됨. 수신자는 해당 목표노드 주변에 위치한 노드들을 알고 있
다면 해당 노드들의 목록을 neighbors 패킷에 포함하여 반환
neighbors 4 findnode 에 대한 응답패킷. 요청된 목표노드의 인접한 노드들을 포함하여 반환

이더리움 PoS 알고리즘 – 캐스퍼(Casper)
 PoW에서 PoS 방식으로 변경하려는 이유
 PoW로 인해 낭비되는 에너지를 줄임
 비트코인의 경우 전세계 전력 사용량의 0.5%를 사용. 아일랜드 연평균 전력량과 동일
 ASIC과 중앙화된 채굴집단으로 인해서 메인체인이 변경될 가능성 방지
 여러 암호화폐를 대상으로 한 51% 공격 : Bitcoin Gold, ZenCash, Litecoin Cash 등
 Casper FFG(Casper the Friendly Finality Gadget)
 PoW와 PoS가 혼합된 하이브리드 PoW/PoS 시스템
 투표(vote) 메시지를 통해 블록에 대한 투표진행
 검증인(Validator)가 되기위해 Casper 스마트컨트랙트에 예치금(1500 이더)을 맡김
 블록이 올바르게 생성된 경우 예치금을 맡긴 검증인들에게 보상이 주어짐
 합의과정에서 잘못된 행동을 한경우 예치금을 몰수
 50번째 블록(체크포인트) 마다 투표를 진행

Transaction speeds
실질적인 VISA의 TPS는 평균 1700

확장성 솔루션 : 라이덴, 플라즈마, 샤딩
 비탈릭 부테린이 2017년 9월, 이더리움 네트워크가 비자와 같은 속도에 도달하기까지 2년이
걸릴것이라고 예측
 라이덴 네트워크
 Off-chain을 통해 블록체인 기록을 최소화하고 수수료를 절약
 플라즈마
 Child-chain을 통해 블록체인의 기록을 최소화
 샤딩
 이더리움 노드가 처리하는 데이터를 분할하여 TPS를 극대화
 시너지 효과
 라이덴 네트워크를 통해 결재 속도와 수수료를 절감
 플라즈마를 통해 Dapp의 데이터 처리속도를 향상
 샤딩을 통해 초당 처리량을 향상

라이덴 네트워크(Raiden Network)
 이더리움 네트워크 위에 구현된 지불 네트워크
 라이덴 네트워크의 특징
 확장성 : 거래수에 따른 선형 스케일 (매초 100만 이상의 처리 가능)
 고속성 : 순식간에 거래 인증과 완료가 이루어짐
 익명성 : 개개인의 거래가 공공장부에 기록되지 않음
 상호 운용성 : 이더리움의 표준화된 코인 API와의 연동
 낮은 수수료 : 온체인과 비교해 100만분의 1 이하의 수수료
 마이크로 페이먼트 : 낮은 수수료에 따라 초 소액결재가 가능(IoT의 M2M 트랜잭션, 고속 분산형 거래소)

라이덴 네트워크 : 지불 채널
 단방향 지불채널
 양방향 지불채널

플라즈마(Plasma)
 Off-chain 솔루션
 이더리움 메인체인이 처리하던 트랜잭션을 별도의 플라즈마 체인에 분산하여 TX 수를 늘림
 비탈릭 부테린과 비트코인의 라이트닝 네트워크 개발자인 조셉 푼 공동개발
 블록체인과 함께 작동할수 있는 소액 계약의 인터페이스 레이어를 만드는것
 루트 체인과 플라즈마 체인으로 구분하고, 플라즈마 체인의 TX 기록이 머클루트의 형태로 루
트 체인에 주기적으로 기록

플라즈마 체인
 Root chain에는 다수의 Plasma chain이 연결
 Root chain에 연결된 chain은 Parent chain
 Parent chain에 연결되어 있는 chain은 Child chain
 Parent chain에 다수의 Child chain이 연결가능
 Plasma chain에 참여하기 위해서는 Root chain에 ETH를 예
치(Deposit)해 놓아야 하고, 이에 따라 Plasma ETH(PETH)
가 Plasma chain에서 사용됨
 특정 TX를 블록체인에 동기화시킬때 필요한 연산은 Plasma
Chain에서 주로 이루어짐
 Plasma Chain 블록헤더의 머클루트만 Root chain에 기록하
기 때문에 Root chain에서는 최소한의 기록만 수행

샤딩(Sharding)
 PoS 기반의 합의 알고리즘으로 전환되는것을 기반으로 구현
 전체 네트워크를 분할한뒤 트랜잭션을 영역별로 저장하고 이를 병렬적으로 처리하여 블록체인에 확장
성을 부여하는 On-Chain 솔루션
 메인체인을 n개의 샤드로 분할하고, 각 샤드는 네트워크의 전체 트랜잭션을 병렬적으로 처리
 네트워크의 전체 처리량은 샤드의 배수만큼 향상

샤스퍼(Shasper : Sharding + Casper) 프로젝트

Blockchain 2nd ethereum_core

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Blockchain 2nd ethereum_core

Similar a Blockchain 2nd ethereum_core (20)

Último

Último (8)

Blockchain 2nd ethereum_core