9. Ledger

아메숑 2019. 3. 31. 10:21

9. Ledger

블록체인 원장

블록 체인 원장은 world state와 블록 체인 두 부분으로 구성된다.

첫째로 원장 상태 집합의 현재 값을 보유하는 데이터베이스인 world state가 있다. World state는 프로그램이 모든 트랜잭션 로그를 탐색하여 계산하지 않고 원장의 현재 상태 값을 쉽게 얻도록 한다. 원장 상태는 기본적으로 키 - 값 쌍으로 표시된다. state가 생성, 업데이트 및 삭제될 수 있기 때문에 world state는 자주 변경될 수 있다.

두 번째로 블록 체인 (blockchain)이 있다. 트랜잭션 로그는 world state를 결정하는 모든 변경 사항을 기록한다. 트랜잭션은 블록 체인에 추가된 블록 내부로 수집되므로 현재 상태가 되기 전 변경 내역을 알 수 있다. 블록 체인 데이터 구조는 일단 기록되면 수정할 수 없으므로 world state와 매우 다르다. 블록의 순서는 변경될 수 없고, 각 블록에는 순서가 지정된 트랜잭션 집합이 들어 있다.

원장 L은 블록 체인 B와 world state W로 구성된다. 블록 체인 B는 world state W를 결정하며 W가 블록 체인 B에서 파생된다고도 표현된다.

Hyperledger Fabric 네트워크에 하나의 논리적 원장이 있다고 생각하면 된다. 실제로 네트워크는 원장 사본을 여러 개 보유한다. 이 사본은 합의라고하는 프로세스를 통해 다른 모든 사본과 일관되게 유지된다. 분산 원장 기술 (DLT)이라는 용어는 논리적으론 한 개 이지만, 네트워크 전체에 많이 분산되고 일관된 사본이 존재한다.

World state

World state는 모든 원장 상태의 현재 값을 나타낸다. 프로그램은 일반적으로 원장 상태의 현재 값이 필요하며 언제든 쉽게 이용할 수 있기 때문에 매우 유용하다. 원장 상태의 현재 값을 계산하기 위해 전체 블록 체인을 탐색할 필요가 없다. 단지 world state에서 직접 얻을 수 있다.

원장 상태는 블록 체인을 통해 공유할 어플리케이션 정보를 기록하는데 사용된다. 위의 예는 CAR1과 CAR2 두 대의 원장 상태를 보여준다. 상태에는 key와 value가 있으며 어플리케이션은 간단한 API를 통해 상태에 액세스하는 체인 코드를 호출한다. 상태 key를 사용하여 상태를 가져오고 삭제할 수 있다. 상태의 value는 단순형(CAR1) 또는 복합형(CAR2)일 수 있다.

물리적으로 world state는 데이터베이스로 구현된다. 이는 데이터베이스가 상태를 효율적으로 저장하고 검색할 수 있는 풍부한 연산자 집합을 제공하므로 많은 의미가 있다.

트랜잭션은 world state에 대한 변경 사항을 기록하며 예상대로 트랜잭션은 수명주기가 있다. 트랜잭션은 어플리케이션에 의해 생성되며 마침내 원장 블록 체인에 추가된다. Hyperledger 패브릭의 핵심 설계 포인트는 승인 조직 집합이 서명한 트랜잭션만 world state를 업데이트한다는 것이다. 트랜잭션이 충분한 endorsers에 의해 서명되지 않으면 유효성 검사가 실패하고 그러므로 world state로 업데이트되지 않는다.

또한 상태에는 버전 번호가 있다. 그림에서 CAR1과 CAR2 상태는 시작 버전 0에 있다. 상태의 버전 번호는 상태가 변경될 때마다 증가한다. 또한 상태가 업데이트 될 때마다 버전을 검사해 트랜잭션이 생성될 때 버전과 일치하는지 확인한다. 이 검사는 world state가 트랜잭션이 생성될 때와 동일한 예상 값으로 변경되도록 한다.

마지막으로 원장이 처음 만들어지면 world state는 비어 있다. world state를 변경한 모든 유효한 트랜잭션이 블록 체인에 기록되기 때문에 언제든지 블록 체인에서 world state를 다시 생성할 수 있다. 이것은 매우 편리하다. 예를 들어 피어가 생성되면 world state가 자동으로 생성된다. 또한 피어가 비정상적으로 실패하면 트랜잭션을 수락하기 전에 피어 재시작시 world state를 다시 생성할 수 있다.

블록 체인

블록 체인은 서로 연결된 블록으로 구성된 트랜잭션 로그이다. 각 블록에는 world state에 대한 쿼리 또는 업데이트를 나타내는 일련의 트랜잭션이 들어 있다. 중요한 것은 블록의 순서와 블록 내 트랜잭션의 순서가 블록을 처음 만들 때 설정된다는 것이다.

각 블록의 헤더에는 블록의 트랜잭션 해시와 이전 블록 헤더의 해시 사본이 포함된다. 이렇게 하면 원장의 모든 트랜잭션 순서가 지정되고 암호화되어 연결된다. 이 해싱 및 연결은 원장 데이터를 매우 안전하게 한다. 원장을 호스팅하는 한 노드가 조작된 경우에도 원장이 노드 네트워크 전체에 독립적으로 분산되어 있기 때문에 다른 노드에 '올바른' 블록 체인이 있다고 확신할 수 없다.

물리적으로 블록 체인은 데이터베이스를 사용하는 world state와 달리 항상 파일로 구현된다. 블록 체인 데이터 구조가 매우 단순한 작업으로 구성되었기 때문에 이는 현명한 디자인 선택이다. 기본적으로 블록 체인의 끝에 추가하는 작업이며 쿼리는 현재 비교적 드문 작업이다.

그림에서 B2 블록에는 모든 트랜잭션 (T5, T6, T7)을 포함하는 블록 데이터 D2가 있다.

가장 중요한 점은 B2에는 이전 블록 B1와 동일한 해시뿐만 아니라 D2에있는 모든 트랜잭션의 암호화 해시를 포함하는 블록 헤더 H2가 있다는 것이다. 이런 방식으로, 블록은 서로 뗄 수 없으며 불변하게 연결되어 있다.

마지막으로 그림에서 볼 수 있듯이 블록 체인의 첫 번째 블록을 genesis 블록이라고 한다. 원장의 시작점이지만 사용자 트랜잭션은 포함되어 있지 않습니다. 그 대신 네트워크 채널의 초기 상태를 포함하는 구성 트랜잭션을 포함한다.

블록

블록은 3개의 섹션으로 구성되어 있다.

- 블록 헤더

이 섹션은 블록이 생성될 때 작성되는 세 개의 필드로 구성된다.

블록 번호 : 0 (genesis 블록)에서 시작하는 정수이며 블록 체인에 새로 추가된 블록에 대해 1 씩 증가한다.
현재 블록 해시 : 현재 블록에 포함된 모든 트랜잭션의 해시이다.
이전 블록 해시 : 블록 체인의 이전 블록의 해시 사본이다.

- 데이터 블록

이 섹션에는 순서대로 정렬된 트랜잭션 목록이 들어 있으며 블록 작성시 생성된다. 이러한 트랜잭션은 풍부하지만 단순한 구조를 가지고 있다.

- 메타 데이터 블록

이 섹션에는 블록 작성자의 인증서, 공개키 및 서명뿐만 아니라 블록 작성 시간이 포함된다. 이후 블록 committer는 트랜잭션이 유효한지 여부 표시도 추가한다. 이 정보는 해시에 포함되지 않지만 블록이 생성될 때 같이 생성된다.

트랜잭션

그림에서 다음 필드를 볼 수 있다.

- 헤더

H4에 설명된 이 필드는 트랜잭션에 대한 필수 메타 데이터 (예 : 관련 체인 코드의 이름 및 버전)를 기록한다.

- 서명

S4로 표시된 이 필드는 클라이언트 어플리케이션에서 생성한 암호화 서명이 들어 있다. 이 필드는 트랜잭션 생성 시 어플리케이션의 개인키가 필요하므로 트랜잭션 세부 정보가 변경되지 않았는지 확인하기 위해 사용된다.

- 요청

P4로 표시된 이 필드는 제안된 원장 업데이트를 생성하는 체인 코드에 어플리케이션이 제공하는 입력 매개 변수를 인코딩한다. 체인코드가 실행될 때, 이 제안은 현재의 world state와 함께 새로운 world state를 결정하는 일련의 입력 매개 변수를 제공한다.

- 응답

R4로 표시된 이 필드는 읽기 쓰기 세트로 world state의 이전과 이후 값을 캡처한다. 그것은 체인코드의 결과이며, 트랜잭션이 성공적으로 검증되면, 그것은 world state를 갱신하기 위해 원장에 적용될 것이다.

- 승인

E4에 나타낸 것과 같이, 이것은 승인 정책을 충족하기에 충분한 각 조직의 서명된 트랜잭션 응답 목록이다. 트랜잭션은 오직 하나의 트랜잭션 응답을 포함하지만, 응답내에는 다수의 승인이 있다. 왜냐하면 각 승인은 조직의 특정 트랜잭션 응답을 효과적으로 인코드하기 때문이다. 즉, 조직들의 충분한 승인을 받지 못한 트랜잭션 응답은 유효하지 않아서 거부되기 때문에 포함할 필요가 없으며, world state에도 업데이트 되지 않는다.

World State database options

world state는 원장 상태에 대해 간단하고 효율적인 저장과 검색을 제공하기 위해 데이터베이스로서 물리적으로 구현된다. 우리가 본 대로, 원장 상태는 단순하거나 복잡한 값을 가질 수 있으며, 이를 수용하기 위해 world state 데이터베이스 구현이 다양하여 이러한 값들이 효율적으로 구현될 수 있다. world state 데이터베이스 옵션에는 현재 LevelDB와 CouchDB가 있다.

LevelDB는 기본값이며, 원장 상태가 단순한 키-값 쌍일 때 특히 적합하다. LevelDB 데이터베이스는 네트워크 노드와 함께 배치되며, 동일한 운영 체제 프로세스 내에 내장된다.

CouchDB는 비즈니스 거래에서 흔히 사용되며, 풍부한 쿼리와 풍부한 데이터 유형의 업데이트를 지원하기 때문에 원장 상태가 JSON 문서로 구조화될 때 유용하다. 구현 측면에서, CouchDB는 별도의 운영 체제 프로세스로 실행되지만, 네트워크 노드와 CouchDB 인스턴스 사이에는 여전히 1:1의 관계가 있다.

LevelDB와 CouchDB는 하이퍼레저 패브릭의 pluggable특성을 잘 보여준다. world state 데이터베이스는 관계형 데이터 저장소, 그래프 저장소 또는 임시 데이터베이스일 수 있다. 이것은 원장 상태의 유형에 있어서 효율적으로 접근할 수 있으므로 유연성을 제공하며, 그러므로 하이퍼레저 패브릭은 다른 유형의 문제들을 보다 많이 해결할 수 있다.

원장의 예 : fabcar

Fabcar sample app은 다양한 색상, 제조사, 모델 및 소유자의 10대의 자동차 세트를 생성한다. 그림은 처음 4대의 자동차가 생성된 후 원장의 상태를 나타낸다.

원장의 world state에는 CAR0, CAR1, CAR2 및 CAR3가 포함되어 있다. CAR0의 value는 자동차가 Tomoko가 소유한 Blue Toyota Prius임을 나타내며, 다른 자동차에서도 이러한 state와 value를 갖는다. 또한 그림에서 모든 자동차의 버전 번호는 0이다. 이 번호는 시작 버전 번호임을 나타내며, 생성된 이후로 한번도 업데이트되지 않았음을 의미한다.

원장 블록 체인에는 두 개의 블록이 있다. 블록 0은 기원 블록이며 자동차와 관련된 트랜잭션은 포함되어 있지 않다. 그러나 블록 1은 트랜잭션 T1, T2, T3, T4를 포함하며, 이는 world state에서 CAR0부터 CAR3까지 초기 상태를 생성한 트랜잭션집합이다. 블록 1은 블록 0에 연결되어 있다.