출처
YouTube, https://www.youtube.com/watch?v=rrQp-ncNFm4
하이퍼레저 패브릭 거래 처리
하이퍼레저 패브릭 거래
거래
- 블록체인에 스마트 계약 프로그램인 체인코드(chaincode)를 설치하고 기존에 설치된 체인코드를 실행하기 위해 호출하는 동작(operation)
- 전체 네트워크의 피어들에게 전달되어 블록체인에 기록되기 전에 먼저 보증 피어들에 의해 보증
- 보증 피어에 의해 보증된 거래들만 확정(commit)되어 블록체인에 기록 가능
- 체인코드가 블록체인에 저장되어 있고 거래를 통해 체인코드를 실행하고 그 결과가 블록체인에 저장
- 블록체인에 기록되기 전에 보증 피어가 보증해야 함
거래 유형
배치 거래(deploy transaction)
- 블록체인에 체인코드를 저장하는 거래
- 체인코드 프로그램을 매개변수로 수신
- 체인코드는 해당 체인코드를 실행하기 위한 조건을 설정하는 보증 정책(endorsing policy) 지정을 포함
- “이 체인코드를 실행하는 거래는 어떤 보증 노드에서 실행되고 그 거래를 요청한 참여자에게 전달되어야 한다” 같은 게 보증 정책
- 배치 거래가 성공적으로 실행되면 설치된 체인코드의 ID(chaincodeID) 반환
호출 거래(invoke transaction)
- 블록체인에 있는 체인코드를 호출하는 거래
- 특정 체인코드와 해당 체인코드의 특정 함수를 참조
- 지정된 함수가 성공적으로 실행되면 블록체인의 상태를 갱신할 수 있는 결과 반환
- 블록체인 상태의 실제 갱신은 순서화 서비스를 거쳐 검증 및 확정 단계에서 수행
거래 처리 과정
하이퍼레저 패브릭 트랜잭션 흐름
- 클라이언트가 거래 하나를 생성하면 거래를 누구한테 보내냐면 endorsing node들한테 보냄
- 체인코드를 호출하는 거래는 어느 endorsing node들에 의해 실행될지 정해진 node들임
- endorsing node 셋은 실행한 후 결과를 클라이언트한테 보냄
- 클라이언트는 트랜잭션과 실행결과를 같이 보냄
- 블록에 거래 사이의 순서를 어떻게 정할지 Ordering Service에 참여하는 노드들이 합의함
- 합의 결과를 블록체인을 유지하는 모든 노드들에게 보냄(endorsing node를 비롯한 모든 노드)
- 거래 실행에 참여하진 않지만 블록체인을 유지하는 노드들을 commiting peer라 함
- commiting peer는 endorsing node들이 실행한 거래 결과를 검증하여 문제가 없음을 판별
- 자신이 유지하는 블록체인에 거래를 저장하고 거래 결과를 갱신함
- 어떤 클라이언트가 어떤 체인코드를 어느 endorsing node에 보낼지 정한다면 그 거래를 실행하지 않은 다른 endorsing node는 다른 거래를 실행하면 됨
- 따라서 병렬성이 있어 퍼포먼스가 높음
처리 단계
거래 보증(transaction endorsing)
- 거래를 실행하여 정상적으로 거래가 될 것임을 보증
- 수표 endorse(배서)에서 유래한 듯
거래 순서화(transaction ordering)
- 거래들을 블록에 저장하는 순서를 정하는 작업
거래 확정(transaction commiting)
- 정해진 순서대로 거래들을 검증하여 블록체인에 저장하는 단계
PROPOSE 메시지
- 클라이언트가 거래를 처리하는 endorsing node에게 거래를 전달할 때 전달되는 정보
- <PROPOSE, clientID, chaincodeID, txPayload, timestamp, clientSig>
- clientID: 거래를 제출하는 클라이언트의 ID
- chaincodeID: 거래가 적용되는 체인코드의 ID
- txPayload: 거래 수행에 필요한 정보, 호출 거래의 경우 체인코드의 함수와 매개변수 그리고 호출 거래를 설명하는 메타데이터(metadata)가 포함되고 배치 거래의 경우 체인코드의 소스 코드(source code), 체인코드와 응용을 설명하는 메타데이터 그리고 해당 체인코드의 보증 정책
- timestamp: 새로운 거래가 생성될 때마다 증가하는 정수 값, 클라이언트에 의해 유지됨
- clientSig: 거래를 제출하는 클라이언트의 서명 –> 서명은 등록 인증서에 해당하는 서명을 사용하는 것이 아니고 거래 인증서에 해당되는 서명을 보냄
TRANSACTION-ENDORSED 메시지
- endorsing node 결과를 클라이언트에게 전달할 때 전달되는 정보 –> 두 개의 자료구조(readset, writeset)
- readset은 거래를 실행하기 위해 읽은 키 값과 버전
- writeset은 거래 실행 결과 블록체인에 저장되어야 할 정보를 전달
- <TRANSACTION-ENDORSED, tid, eplD, chaincodeID, txContent, readset, writeset, epSig>
- tid: 거래의 ID
- epID: 보증 피어의 ID
- txContent: 거래의 페이로드 정보
- readset: 거래에 의해 호출된 체인코드가 읽는 키(key)와 키 버전(key version) 쌍의 집합. readset은 거래가 실행되기 전에 생성
- writeset: 거래 실행 과정에서 값이 변경되는 키(key)와 값(value) 쌍의 집합
- epSig: 보증 피어의 서명
거래 보증 정책
전형적인 거래 보증 정책
- 어떤 보증 노드(endorsing node)에게 거래를 실행하게 할 것인가
- 보증 노드의 서명을 사용하여 작성
- 보증 피어 집합 E = {Alice, Bob, Charlie, Dave, Eve, Frank, George}를 지정하는 것으로 가정
보증 정책의 예
- E의 모든 보증 피어들로부터 동일한 내용에 대한 적합한 서명을 수신하여야 한다.
- E에 속한 임의의 보증 피어로부터 적합한 서명을 수신하여야 한다.
- (Alice OR Bob) AND (any tow of (Charlie, Dave, Eve, Frank, George))의 조건을 충족시키는 보증 피어로부터 동일한 내용에 대한 적합한 서명을 수신하여야 한다.
- 전체 7개의 보증 피어들 중에서 임의의 5개의 보증 피어들로부터 동일한 내용에 대한 적합한 서명을 받아야 한다.
보증 정책 설정
- 체인코드에 대해 설정하되 보증 정책은 시스템에 의해 미리 작성
- 체인코드 개발자가 특정 체인코드를 선택하고 매개변수 설정을 통해 보증 정책을 설정
거래 확정과 블록체인 갱신
현재 블록체인의 전체 상태(world state)
- 현재 정보의 이름에 해당하는 키, 값, 키의 버전 정보가 상태 정보로 유지됨
- 이 정보들이 어떻게 업데이트 되는가 예를 들어 보면
- 현재 블록체인의 상태: (k1, 1, v1), (k2, 1, v2), (k3, 1, v3), (k4, 1, v4), (k5, 1, v5), (k6, 1, v6)
현재 블록의 거래 순서
- 여러 클라이언트들이 거래의 순서를 잡고 검증하고 확정하여 블록체인 갱신하려고 할 때
- 검증하는 과정을 예를 들어 보면
- T1 –> Write(k1, v11), Write(k2, v22) –> (k1, 2, v11), (k2, 2, v22), …
- T2 –> Read(k1), Write(k3, v33) –> Read(k1, 1)(k1의 버전이 2인게 갱신이 아직 안 됨), (k3, 2, v33), …
- T2가 k1을 실행할 때 버전이 1이었는데 T1이 k1의 값을 읽고 갱신해버리고 T2는 이전 버전을 읽은 꼴 –> Invalid
- 검증한다는 것은 최신 상태를 가지고 실행하는가 안 하는가를 보는 것
- T3 –> Write(k2, v222) –> (k2, v222, 3), … 문제 없음
- T4 –> Write(k2, v2222), read(k2) –> k2의 이전 버전을 읽을 것이기 때문에 Invalid
- T5 –> Write(k6, v66), read(k5) –> (k6, 2, v66), k5 읽는 것 이상 없음
거래 확정 및 갱신
- T1의 readset = {}, writeset = {(k1, v11), (k2, v22)}이다. readset이 비어 있으므로 읽기 의존성은 자동으로 충족된다. 따라서 T1 거래의 결과 블록체인의 전체 상태는 (k1, 2, v11), (k2, 2, v22)로 갱신된다. 갱신과정에서 writeset의 값으로 상태가 수정되고 대응되는 키의 버전 번호가 증가된다.
- T2의 readset은 {(k1 1)}이다. 그런데 현재 블록체인의 전체 상태의 k1의 버전은 거래 T1에 의해 이미 2로 갱신되어 있기 때문에 읽기 의존성 검증에 실패하고 따라서 T2의 거래는 부적합 거래로 처리되어 블록체인 갱신이 적용되지 않는다.
- T3의 readset = {}, writeset = {(k2, v222)}이다. readset이 비어 있으므로 읽기 의존성은 자동으로 충족된다. 블록체인의 전체 상태는 (k3, 3, v222)로 갱신된다.
- T4의 readset은 {(k2, 1)}이다. 그런데 현재 블록체인의 전체 상태의 k1의 버전은 거래 T1과 T3에 의해 이미 3으로 갱신되어 있기 때문에 읽기 의존성 검증에 실패하고 따라서 T4 거래는 부적합 거래로 처리되어 블록체인 갱신이 적용되지 않는다.
- T5의 readset = {k5, 1)}, writeset = {(k6, v66)}이다. 키 k5의 값은 이전의 거래 T1~T4에 의해 갱신되지 않았으므로 버전이 1로 유지가 되고 있고 읽기 의존성이 충족된다. 블록체인 전체 상태는 (k6, 2, v66)로 갱신된다.
여기서 질문자가 나온다
질문: 교수님 위 예시에서 T2의 순서가 계속 아래쪽에 있다면 이 거래들이 블록에 영원히 기록되지 않을 수 있는데 이를 방지하는 것이 있을까요? 교수: 비트코인은 수수료와 관계없이 거래가 미루어지면 그 거래 처리에 대해 우선순위를 높게 주는 알고리즘이 존재하는데 하이퍼레저 패브릭도 그러한 것이 있는지 잘 모르겠다. 아마 있겠지??
- 뭐 여튼 이러한 구조는 기존의 값이 무엇이었는지 버전을 타고 올라가서 볼 수 있도록 설계가 되어 있음
합의 프로토콜
장착형 합의 프로토콜
- 응용의 요구사항에 따라 적합한 합의 프로토콜을 선택하여 사용
- 버전 0.6에서의 합의 프로토콜, 간단함
- SOLL - 하나의 중앙 집중형 순서화 노드를 통해 거래의 순서를 결정
- Kafka - f개의 노드가 고장(crash)이 나서 동작을 멈추더라도 분산된 순서화 서비스를 제공할 수 있는 합의 프로토콜. (2f+1)개 이상의 노드를 사용
- PBFT(Practical Byzantine Fault Tolerant) - f개의 노드가 고장으로 인한 멈춤을 포함한 임의의 오동작(Byzantine fault)에도 분산된 순서화 서비스 제공. (3f+1)개 이상의 노드 사용
- 버전 1.0에는 자세한 합의 프로토콜 설명이 없음
- 관심 있는 사람은 Kafka, PBFT와 관련된 논문을 찾아 읽으셈
Kafka
- f개가 고장나도 합의를 이룰 수 있는 알고리즘
- 고장이 단순히 작동을 하지 않는 것 말고 오작동(비잔틴 장애)는 고려 안 한것
PBFT
- 비잔틴 장애를 극복하는 알고리즘
Comments