유효성을 검사하는 동료는 누구입니까?

Question

Glossary에 '피어 및 유효성 검사를하지 않는 피어 확인'이라는 용어 정의가 표시되지 않습니다. 좋은 정의의 문학이 이러한 유형의 동료들에 의존하는 것처럼이 정의를 갖는 것이 중요합니다.

내 주요 질문이 있습니다.

Blockchain을 데이터 저장소로 살펴보면이 데이터 저장소가 함수를 노출하여 저장소 상태를 변경하고 읽을 수 있음을 알 수 있습니다. 따라서 유효성을 검사하는 피어는 X가 상태 전이고 T는 적용된 트랜잭션이고 X는 결과 상태라는 사실을 확인하는 엔터티입니까?

유효성을 검사하는 피어는 T가 나타내는 비즈니스 논리와 T를 호출하기 위해 존재해야하는 액세스 수준도 확인합니까?

중앙 집중식 유추는 SQL 엔진을 사용하여 저장소 상태를 노출하는 RDBMS입니다. 이 저장소는 비즈니스 로직 (예 : 규칙 엔진)과 SQL 명령 (예 : INSERT, SELECT 등)의 조합을 통해 업데이트 될 수 있습니다. 내 질문은 SQL 명령이 성공적으로 작동하는지 확인하는 데 필요한 유효성 검사기입니까? 또는 유효성 검사를 규칙 엔진으로 확장합니까?

Answer 1

유효성 검사 대상이라는 용어는 v0.6 of Hyperledger Fabric에서 사용되었습니다. 그들은 주문자들이었고, 타당성을 입증하지 않은 다른 동료 인 동료들이었습니다. V1.0에서

이 있습니다

• 엔도 동료를 : 그들은 거래를받을 수 있습니다. 그런 다음 그들은 Smart Contrat와의 거래를 실행하고 결과에 서명합니다. 그들은 서명 한 트랜잭션을 보낸 피어에게 보냅니다.
• 커미터 피어 : 피어는 블록 (유효성 검사 트랜잭션이 있음)을 가져와 장부에 커밋합니다.
• Orderes : 트랜잭션을 정렬하고 블록을 생성하는 노드.

편집 (다음 추가) :

피어는 엔도와 Comitter 수 있습니다. 또한, Endorser Peer는 자체 트랜잭션을 실행할 수 있습니다.

흐름 (짧게) :

• 피어는 클라이언트 요청을 가져옵니다. 이 피어 (초기 피어)는 해당 요청을 엔드 커 피어에 보냅니다.
• Endorser Peers는 스마트 계약서에 대한 요청을 실행합니다. 응답에 서명하고 초기 피어에게 보냅니다.
• 모든 응답의 결과가 동일하고 서명이 올바른 경우 초기 피어는 부호가있는 트랜잭션을 작성합니다. 그것은 주문자에게 보내진다.
• 주문 서비스에서 서명이 확인됩니다. Ordering Service는 시간순으로 그리고 채널별로 블록을 생성합니다. 그들은 Comitter Peers로 보내집니다.
• 각 Comitter 피어는 블록의 각 트랜잭션의 유효성을 검사합니다. 확인을 클릭하면 각 로컬 원장에 블록이 추가됩니다.