직물의 기본 개념
처음에 응용 프로그램은 장부 갱신 권장 사항을 생성하기 위해 피어 세트를 선택합니다. 어떤 피어가 서명 정책을 기반으로 선택될지, 이 정책은 방송 장부 업데이트 제안 전에 어떤 조직이 업데이트 제안에 서명해야 하는지를 결정합니다. 이것은 이해 방식에 영향을 줄 수 있다. 업데이트 제안의 승인 여부에 관심이 있는 모든 조직은 해당 제안을 피어에 브로드캐스트하고 피어에 받아들여지기 전에 해당 제안이 승인되었는지 확인합니다.
제안된 응답에 대한 피어의 승인은 그의 디지털 서명을 응답에 추가하고 그의 개인 키로 전체 응답에 서명하는 것이다. 그런 다음 주석의 내용을 사용하여 해당 응답이 조직의 동료에 의해 생성되었음을 증명할 수 있습니다. 이 예에서 피어 P 1 소유 조직 1(Org 1) 인 경우 E 1 을 인정하는 것은 증명 트랜잭션 t/kloc 와 같습니다
응용 프로그램이 충분한 서명 제안 응답을 받으면 첫 번째 단계가 종료됩니다.
Peer 가 다른 정보를 반환할 수 있으므로 동일한 트랜잭션에 대해 일관되지 않은 반환 정보가 있을 수 있습니다. 이는 응답이 서로 다른 시간, 등가 및 다른 장부에서 생성되기 때문일 수 있습니다. 대부분의 경우 응용프로그램은 제안된 응답 업데이트를 여러 번 요청할 수 있습니다. 또한 더 심각하지만 체인 코드의 불확실성으로 인해 응답이 일치하지 않을 확률이 적습니다. 불확실성은 체인 코드와 장부의 대적이다. 이런 상황이 발생하면, 의거래에는 매우 심각하며, 일관되지 않은 제의응답은 장부에 제출되지 않을 것이다. 독립 노드는 트랜잭션 결과가 불확실하다는 것을 알 수 없습니다. 불확실성 트랜잭션을 감지하기 전에 트랜잭션을 요약하고 비교할 필요가 있습니다 (엄밀히 말하면, 이것이 충분하지 않더라도, 우리는 이 토론을 트랜잭션 부분으로 미루고 트랜잭션 부분의 불확실성에 대해 상세히 논의할 필요가 있습니다).
첫 번째 단계가 끝나면 응용 프로그램이 원할 경우 일관되지 않은 응답을 안전하게 폐기하여 트랜잭션을 미리 종료할 수 있습니다. 나중에 응용 프로그램이 원장에 제출한 응답이 일치하지 않으면 거부된다는 것을 알 수 있습니다.
공정 2 포장
두 번째 거래 과정은 포장입니다. 가입자 노드는 이 프로세스의 핵심 요소로서 많은 응용 프로그램에서 승인된 제안된 트랜잭션 응답을 수신합니다. 주문자는 거래를 정렬하고, 대량의 거래를 블록으로 포장하며, 배서 당사자를 포함하여 주문자에 연결된 모든 피어에게 블록을 배포할 준비를 합니다.
가입자의 첫 번째 역할은 장부 업데이트 건의를 포장하는 것이다. 위 예에서 애플리케이션 A 1 주문 대상 O 1 E 1 및 E2 가 배서한 거래 T 1 을 보냅니다. 또한 A2 를 적용하여 주문자 O 1 에게 E 1 배서된 거래 T2 를 보냅니다. O 1 A 1 의 거래, A2 의 거래 및 기타 거래를 B2 블록으로 패키지화합니다. 블록 B2 의 트랜잭션 순서는 T 1, T2, T3, T4, T6, T5 이며, 반드시 주문자 노드에 도착하는 순서를 따를 필요는 없습니다 (이 예는 매우 간단한 가입자 구성을 보여 줍니다).
가입자 노드는 또한 네트워크 채널의 다른 애플리케이션에서 보낸 장부 업데이트 권장사항을 수신합니다. 가입자 노드의 임무는 미리 정의된 순서대로 이러한 업데이트 권장 사항을 구성하고 다음 배포를 위해 블록으로 패키지화하는 것입니다. 이 돌들은 하나의 블록체인을 형성할 것이다. 가입자 노드가 예상 크기의 블록을 생성하거나 최대 대기 시간을 초과하면 가입자는 해당 블록을 특정 채널에 연결된 피어로 보냅니다. 세 번째 프로세스는이 프로세스에 대해 자세히 설명합니다.
블록의 트랜잭션 순서는 트랜잭션이 order 노드에 도달하는 순서와 직접적인 관계가 없습니다. 트랜잭션은 한 블록에서 임의의 순서로 정렬할 수 있습니다. 이 순서는 트랜잭션이 실행되는 순서입니다. 요점은 엄격한 거래 순위가 있지만 순위가 얼마인지는 중요하지 않다는 것이다.
블록의 엄격한 트랜잭션 순서를 통해 Fabric 은 공용 체인의 트랜잭션이 여러 개의 서로 다른 블록으로 패키지화될 수 있는 경우와는 다릅니다. Fabric 에서는 이러한 상황이 발생할 수 없습니다. 다중 order 생성 블록이 최종 블록입니다. 트랜잭션이 블록에 기록된 후 트랜잭션의 위치 순서가 결정되기 때문입니다. 이것은 직물이 갈라지지 않는다는 것을 의미한다. 트랜잭션이 블록에 기록되면 나중에 다시 쓸 수 없습니다.
보시다시피, peer 는 책과 체인 코드를 저장하고, Order 는 전혀 저장하지 않습니다. 각 거래가 order 에 도착하면 order 는 거래의 가치와 한도에 관계없이 기계적으로 거래를 블록으로 포장합니다. 이것은 직물의 중요한 특징이다. 모든 트랜잭션은 트랜잭션이 삭제되지 않고 엄격한 순서로 정렬됩니다.
2 단계가 끝나면 가입자의 임무는 필요하고 간단한 거래 갱신 제안을 수집하고, 정렬하고, 포장하고, 배포할 준비를 하는 것임을 이해할 수 있습니다.
프로세스 3 인증
마지막 트랜잭션 워크플로우는 주문 당사자에서 피어 당사자로 블록을 배포 및 검증하는 것입니다. 검증이 성공하면 총계정 원장에 제출됩니다.
특히 각 피어에서 블록의 각 거래는 장부로 갱신되기 전에 검증되어 모든 거래가 관련 조직에 의해 승인되었는지 확인합니다. 실패한 거래는 향후 심사를 위해 보류되고 장부에서 업데이트되지 않을 것이다.
프로세스 2 의 패키지 역할 외에도 Orderer 는 프로세스 3 의 피어 노드에 블록을 배포할 책임이 있습니다. 이 예에서 O 1 은 P 1 및 P2 에 블록을 배포합니다. P 1 Block 2 를 처리하고 Block 2 를 P 1 의 장부 L 1 에 추가합니다. 동시에 P2 는 블록 2 를 처리한 다음 블록 2 를 P2 의 장부 L 1 에 추가합니다. 작업이 완료되면 장부 L 1 이 P 1 및 P2 에서 업데이트되고 각 피어가 처리 결과를 연결된 응용 프로그램으로 보낼 수 있습니다.
가입자가 블록을 그에게 연결된 피어에 나누어 주는 것이 프로세스 3 의 시작이다. 가입자 노드에 연결된 채널의 피어는 가입자가 생성한 새 블록의 복사본을 받습니다. 각 피어 노드는 수신된 블록을 독립적으로 처리하지만 모든 피어 노드는 동일한 방식으로 블록을 처리합니다. 이렇게 하면 서로 다른 동료의 장부가 * * * 지식을 얻을 수 있다. 모든 피어가 orderer 노드에 연결되어야 하는 것은 아닙니다. 블록은 gossip 프로토콜을 통해 피어 간에 전달될 수 있으므로 피어가 동일한 블록을 독립적으로 처리할 수 있습니다.
블록이 수신되면 peer 는 블록에 나타나는 순서대로 트랜잭션을 처리합니다. 각 거래에 대해 peer 은 거래를 생성한 체인 코드 승인 정책에 따라 거래가 관련 조직의 승인을 받았는지 확인합니다. 예를 들어, 일부 거래에는 하나의 조직만 배서하면 되고, 다른 거래에는 여러 조직이 동시에 배서해야 할 수 있습니다. 검증 프로세스는 모든 관련 조직의 결과나 출력이 일치하는지 검증합니다. 또한 3 단계 검증은 1 단계와 다릅니다. 첫 번째 단계에서는 응용 프로그램이 배서 노드로부터 응답만 받고 거래 제안을 보내야 하는지 여부를 결정합니다. 응용 프로그램이 잘못된 거래를 보내고 배서 정책을 위반하면 peer 는 여전히 세 번째 검증 단계에서 거래를 거부할 수 있습니다.
거래 배서가 정확하면 peer 는 거래를 원장에 제출하려고 시도합니다. 장부를 쓰기 위해 peer 는 장부의 일관성을 검사하여 현재 장부가 갱신된 장부와 일치하는지 확인해야 한다. 이런 상태가 항상 일치하는 것은 아니다, 설령 거래에 완전한 배서가 있다 하더라도. 예를 들어, 다른 거래가 원장의 동일한 자산을 갱신할 수 있으므로 갱신할 거래는 원장에 기록되지 않습니다. 이 경우 각 노드의 장부는 네트워크를 통해 통지를 유지해야 하며 각 노드의 인증 방법은 동일합니다.
Peer 가 각 독립 거래를 확인한 후 원장이 갱신됩니다. 실패한 거래는 심사 자료로 보관됩니다. 즉, 트랜잭션 성공 또는 실패를 나타내는 블록의 플래그를 제외하고 피어의 블록은 주문 당사자로부터 받은 블록과 동일합니다.
체인 코드는 3 단계에서 실행되지 않으며 이 단계는 1 단계에서만 수행된다는 점도 유의해야 합니다. 즉, 체인 코드는 배서 노드에서만 사용할 수 있고, 전체 네트워크에서 사용할 수 없으며, 배서 기관에서 체인 코드의 보안과 프라이버시를 보장합니다. 이는 체인 코드 실행 결과를 수신하는 것과는 다릅니다. 실행 결과는 트랜잭션에 서명할 수 있는지 여부에 관계없이 채널의 모든 피어와 공유됩니다. 배서 노드는 이렇게 설계되어 쉽게 확장할 수 있습니다.
마지막으로 피어의 장부에 블록을 제출할 때마다 피어가 해당 이벤트를 생성합니다. 블록 이벤트에는 한 블록의 모든 내용이 포함되는 반면 블록 트랜잭션 이벤트에는 각 블록의 트랜잭션이 유효한지 여부와 같은 간단한 정보만 포함됩니다. 체인 코드 실행으로 인한 체인 코드 이벤트도 이때 해제할 수 있습니다. 애플리케이션은 이러한 이벤트를 등록하고 이벤트가 발생할 때 알림을 받을 수 있습니다. 이러한 알림은 트랜잭션 워크플로우의 세 번째이자 마지막 단계에서 완료됩니다.
일반적으로, 우리는 3 단계 orderer 에서 생성된 블록이 장부에 끊임없이 동기화되어 있다는 것을 알 수 있다. 블록 체인의 엄격한 거래 정렬을 통해 각 피어는 블록 체인 네트워크의 거래를 일관되게 검증하고 원장에 제출할 수 있습니다.
가입자 및 * * * 지식
전체 트랜잭션 작업 흐름을 * * * 지식이라고 합니다. 모든 peer 는 트랜잭션 정렬 및 내용에 동의하며 실행 중 orderer 노드에 의해 조정되기 때문입니다. * * * knowledge 는 * * * knowledge 프로세스가 끝날 때만 응용 프로그램에 알리는 다단계 프로세스이지만 알림 시간은 피어마다 다를 수 있습니다.
우리는 나중에 주문자에 대해 더 많이 토론할 것이다. 이제 우리는 orderer 를 응용 프로그램에서 장부 업데이트 제안을 수집하여 피어에 배포하는 과정으로 볼 뿐, 피어는 장부를 검증하고 업데이트할 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure