아키텍처 개요 및 가정(Assumptions)

Caton 0.18.x 버전을 기준으로 작성되어 있습니다.
여기에서 가정(Assumptions)이란 Canton시스템 구축을위한 밑바탕이 되는 조건들이 준비되어 있는 전제를 가정합니다.

개요 및 가정

이 섹션에서는 Canton아키텍처의 개요및 엔터티(신뢰 도메인 정의) 그리고 구성 요소를 설명합니다. 이후 서로 다른 엔티티에 대한 신뢰 가정과 통신 링크(communication links)에 대한 가정을 설명합니다.

Canton은 높은 수준의 요구사항을 충족하도록 설계되었습니다. 이글을 읽는 사용자는 스마트 계약 언어 DAML 및 DA 원장 모델의 계층적 트랜잭션에 익숙하다고 가정합니다.

Canton 101

기본 예제

Canton의 작동 방식에 대한 배경 지식을 제공하기 위해 간단한 DVP(delivery-versus-payment,배송 대 지불) 예제를 사용합니다. Alice와 Bob은 은행이 Alice에게 준 IOU를 Bob이 소유 한 주식으로 교환하려고 합니다. 우리는 Alice(일명 A), Bob(일명 B), 은행 및 등록된 주식(share registry SR, SR은 정확한 소유자의 이름으로 등록 된 주식입니다. 등록된 주식의 소유자가 자신의 주식을 판매하는 경우, 새로운 소유자는 이름과 주소로 등록해야합니다. 등록 된 주식은 발행자에게 항상 자신의 주주가 누구인지 정확히 알 수있게 해주는 이점을 제공합니다.)의 네 개의 당사자가 있습니다. 그리고 다음과 같이 3가지 유형의 계약도 있습니다.

1. 은행을 기반으로하는 Iou 계약
2. 항상 SR을 사용하는 계약
3. Alice와 Bob 간의 DvP 계약

Alice가 소유 한 Iou를 Bob이 소유 한 SR로 교환하는 DvP 계약 인스턴스에 대해 스왑(swap) 선택(choice) 실행권한과, Iou 및 Share 계약 인스턴스가 DvP에 이미 할당되었다고 가정합니다. Alice는 이 스왑 선택(choice)을 실행하는 트랜잭션을 커밋하려고 합니다. 거래구조는 다음과 같습니다.

Canton의 거래(트랜잭션)처리

Canton에서 예제 트랜잭션 커밋은 두 단계로 구성됩니다.

1. Alice의 참가자는 거래에 대한 확인 요청 (confirmation request)을 준비합니다. 요청은 거래에 대한 서로 다른 견해를 제공합니다. 참가자는 당사자가 이해 관계자의 계약을 행사(exercising)및 가져(fetching)오거나 생성(creating)하는 하위 트랜잭션(subtransactions)만 볼 수 있습니다 (더 정확하게는, 당사자가 정보를 제공하는 하위 트랜잭션). DvP 및 수신자에 대한 보기는 아래 그림에 나와 있습니다. Alice의 참가자는 Canton 도메인에서 모든 확인 요청을 주문하는 시퀀서(sequencer)에게 요청서를 제출합니다. 두 참가자가 동일한 두 요청을 볼 때마다 이 시퀀서 순서에 따라 볼 수 있습니다.(whenever two participants see the same two requests, they will see them according to this sequencer order) 시퀀서에는 메시지 순서 지정과 지정된 수신자에게 전달하는 두 가지 기능만 있습니다. 메시지 내용은 암호화되어 시퀀서에 표시되지 않습니다.

트랜잭션 뷰: 각 상자는 오른쪽 하단 모서리에있는 참가자에게 표시되는 트랜잭션 부분을 나타냅니다. 참가자는 여러개의 뷰를 볼수 있으며 그중 일부는 중첩 될 수 있습니다.

2. 수신자는 수신한 뷰의 유효성을 확인합니다. 유효성 검사는 세 가지 측면을 다룹니다.

   1. DA 원장 모델에 정의된 유효성 : 일관성(주로 이중 지출 없음), 적합성 (뷰는 유효한 DAML 해석의 결과) 및 승인(액터와 제출자가 뷰의 작업을 수행할 수 있음을 보장)
   2. 진위성(authenticity) : (액터(actors)와 제출자(submitters)가 자신의 권한 및 신분이 정확하다고 보장)
   3. 투명성 (통보를 받아야 하는 참가자가 알림을 받도록 보장).

적합성, 승인(인증및 권한), 진위성 및 투명성 문제는 제출자의 악의로 인해 발생하지만, 일관성 문제는 악의가 없이도 발생할 수 있습니다. 예를 들어 Bob에게 전송될 Iou는 이미 사용되었을 수 있습니다 (DAML의 "잠금"기법을 사용하지 않는다고 가정). 검사 결과(check’s result)에 따라 확인자(confirmers)라 불리는 수신자 하위 집합이 각 뷰에 대해 개별적으로(긍정적 또는 부정적) 확인 응답(confirmation response)을 준비합니다. 요청과 관련된 확인 정책은 거래의 정보 제공자를 고려하여 어떤 참여자가 확인자인지 명시합니다.

확인자(confirmers)는 전체 확인 요청에 대한 응답을 단일 결정으로 집계하는 또 다른 특수 엔티티 인 중재자(mediator)에게 응답을 보냅니다. 중재자는 참가자의 신원을 서로 숨기는 역할을 합니다 (은행과 SR이 동일한 거래의 일부임을 알 필요가 없도록). 시퀀서(sequencer)와 마찬가지로 중개자는 거래 내용을 학습하지 않습니다(the mediator does not learn the transactions’ contents). 대신 Alice의 참가자는 요청서를 보내는 것 외에도 중재자에게 각 뷰의 정보 제공자에 대해 동시에 알립니다. 중재자는 아래 다이어그램에 개념적으로 시각화된 것처럼 뷰의 정보 제공자만 표시되고 내용이 블라인드 된 트랜잭션 버전을 받습니다.

중재자(mediator)에 대한 정보 제공자 트리에서 모든 거래 내용은 숨겨져 있습니다.

이를 통해 중재자(mediator)는 확인 요청이 승인된 것으로 결정하기 위해 필요한 (긍정적인,positive) 확인 응답을 도출합니다.

악의적인 참가자가 제출 한 요청에는 가짜 뷰(bogus views)가 포함될 수 있습니다. 참가자는 개인 정보 보호(privacy) 이유로 인해 요청의 일부만 볼 수 있으므로 요청에 대한 승인을 받으면 각 참가자는 해당 요청에 표시되는 가짜 뷰를 로컬에서 필터링하고 승인된 확인 요청의 나머지 유효한 보기를 모두 수락합니다. 확인 정책의 신뢰 가정(Under the confirmation policy’s trust assumptions)에 따라 프로토콜은 정직한 참가자의 로컬 결정(local decisions)이 공동으로 보는 모든 견해와 일치하도록 보장합니다. 따라서 프로토콜은 트랜잭션이 유효한 뷰로 구성된 참가자 간에 가상 공유 원장을 제공합니다. 승인되면 승인된 보기는 최종적입니다. 즉, 참가자의 기록이나 가상 원장에서 절대 제거되지 않습니다.

예제의 각 당사자가 자신의 참여자 노드를 실행한다고 가정하면 위에서 설명한 확인 워크 플로우를 다음 메시지 시퀀스 다이어그램으로 나타낼 수 있습니다.

시퀀서(sequencer)와 중재자(mediator)는 소위 ID(신원)관리자(identity manager)와 함께 Canton 도메인을 구성합니다. 도메인 내의 모든 메시지는 시퀀서를 통해 교환되므로 도메인 내에서 교환되는 모든 메시지 간 전체 순서가 보장됩니다.

전체 순서의 보장은 참가자가 모든 확인 요청과 응답을 동일한 순서로 볼 수 있도록 합니다. Canton프로토콜은 추가로 모든 비 비잔틴(non-Byzantine)(즉, 악의적이거나 타협되지 않은) 참가자가 비잔틴 제출자와 동일한 순서로 공유된 뷰(예 : 은행과 A의 참가자 간에 공유되는 Iou 전송 실행)를 볼 수 있도록 합니다. 이는 다음과 같은 의미를 갖습니다.

1. DAML은 결정론적(DAML is deterministic)이기 때문에 각 뷰에 대한 올바른 확인 응답은 항상 고유하게 결정됩니다. 그러나 성능상의 이유로 참가자가 비잔틴 방식으로 행동하거나 논쟁을 벌일 때 가끔 부정확 한 응답을 허용합니다. 이 시스템은 정직한 참가자에게 응답의 정확성 또는 부정확 한 거부 이유에 대한 증거를 제공합니다.

2. 글로벌 순서는 시퀀서에서 측정된 도메인 내에서 (가상)글로벌 시간(global time)을 생성합니다. 참가자는 시퀀서로부터 메시지를 받을 때마다 시간이 진행되었음을 알게 됩니다. 이 전역 시간은 충돌을 감지 및 해결하고(detecting and resolving conflicts) 타임아웃(timeout) 발생 시기를 결정하는 데 사용됩니다. 따라서 개념적으로는 각 참가자가 다른 물리적 시간에 이 단계를 수행하지만이 글로벌 시간과 관련하여 여러 참가자에서 동시에 해당 단계를 수행한다고 말할 수 있습니다. 예를 들어 위의 메시지 시퀀스 다이어그램에서 Alice, Bob, Bank 및 공유 레지스트리(RS)의 참가자는 서로 다른 물리적 시간에 확인 요청을 받지만 개념적으로는 글로벌 시간의 타임스탬프 ts1 및 타임스탬프 ts6의 결과 메시지와 유사합니다.

이 문서에서는 단일 도메인이 있는 Canton의 기본 버전에 중점을 둡니다. Canton은 또한 참가자를 여러 도메인에 연결하는 것을 지원합니다. 현재 도메인에서 생성된 계약은 해당 도메인에서만 사용할 수 있도록 도메인이 격리되있지만, 다른 도메인에서 자유로운 계약의 사용을 지원하는 기능을 추가하고 있으며 구현이 완료되면 설계를 발표할 것입니다.

도입부에서 언급했듯이 Canton의 주요 과제는 당사자들이 과부하, 오프라인 또는 단순히 응답을 거부할 수 있다는 점을 감안할 때 확인 기반 설계로 진행 상황을 보장하는 동시에 무결성 및 개인 정보 보호 문제를 조정하는 것입니다. 이 문제에 대처하는 주요 방법은 다음과 같습니다.

• 타임 아웃을 사용합니다. 타임 아웃 (도메인 전체 상수) 후에 트랜잭션의 유효성을 확인할 수 없는 경우 트랜잭션이 거부됩니다.

• 타임 아웃 시간이 초과될 경우, 시스템은 요청서를 제출하는 참가자에게 확인 응답을 보내지 못한 사실을 알립니다. 이를통해 제출하는 참가자가 악행에 대한 대역 외 조치(out of band actions)를 취할 수 있습니다.

• 유연한 확인 정책(Flexible confirmation policies) : 신뢰, 무결성 및 생기성(liveness) 간의 균형을 제공하기 위해 Canton 도메인에서 확인 정책(confirmation policies)을 선택할 수 있습니다. 확인 정책은 어떤 참가자가 어떤 뷰를 확인해야 하는지 지정합니다. 이를 통해 중재자는 요청이 승인되었음을 선언하기에 충분한 조건을 결정할 수 있습니다. 특히 흥미로운 것은 VIP 확인 정책으로, 모든 행동에 대해 정보 제공자로서 신뢰할 수 있는 (VIP) 당사자가 참여하는 거래에 적용됩니다. VIP 파티의 예시는 시장 운영자(Operator)입니다. 이 정책은 VIP 당사자의 참가자가 올바르게 행동한다고 가정하여 원장의 유효성을 보장합니다. 이 경우에도 잘못된 동작을 감지하고 입증할 수 있지만 결과는 시스템 외부에서 처리해야 합니다. 또 다른 중요한 정책은 모든 서명자와 행위자가 확인해야 하는 서명자 확인 정책입니다. 이를 위해서는 서명자 또는 액터를 호스팅 하는 참가자가 응답하지 않을 때 활성(liveness)을 희생하는 VIP 확인 정책에 비해 낮은(최소한) 수준의 신뢰가 필요합니다. 더 이상 사용되지 않는 또 다른 정책은 모든 정보 제공자가 확인해야 하는 전체 확인 정책입니다. 이를 위해서는 가장 낮은(최소한) 수준의 신뢰가 필요하지만 관련 참가자 중 일부가 응답하지 않으면 활력(liveness)을 희생합니다.

• 향후에는 온 디맨드 VIP 참가자로 생각할 수 있는 증명자(attestators)을 지원할 예정입니다. VIP 당사자가 모든 작업에 대해 정보를 제공하도록 DAML 모델을 구성하는 대신 증명자는 요청 시에만 사용됩니다. 거래를 커밋하려는 참가자는 증명자에게 하위 거래의 유효성에 대한 명확한 증거를 제공할 수 있도록 충분한 양의 내역을 공개해야 합니다. 그런 다음 증명자의 진술이 응답하지 않는 참가자의 확인을 대체합니다.

다음 이미지는 확인 요청의 상태 전환 다이어그램을 보여줍니다. Submitted을 제외한 모든 상태는 최종 상태입니다.

확인 요청은 여러 가지 이유로 거부 될 수 있습니다.

다중 도메인 (Multiple domains)
다른 Canton 도메인에서 생성 된 계약을 사용하려고했습니다. 다중 도메인 트랜잭션은 현재 지원되지 않습니다.

요청 시간 초과 (time out)
확인 정책에 따라 트랜잭션을 수락한 것으로 선언할 수 있는 제한 시간 내에 불충분한 확인이 수신되었습니다. 이것은 관련된 참가자 중 한 명이 응답하지 않기 때문에 발생합니다. 그러면 요청이 시간 초과되고 중단됩니다. 앞으로 제출 당사자 또는 제출된 거래에서 계약을 제어하는 다른 사람이 중단을 트리거할 수 있는 기능을 추가할 예정입니다. 중단은 시간 초과 후에도 여전히 발생해야 하지만 필수는 아닙니다. 또한 증명자(attestators)를 사용하여 응답하지 않는 참가자의 확인을 대체할 수 있습니다.

불일치 (Inconsistency)
이전 보류 중인 요청, 즉 아직 승인되거나 거부되지 않은 요청과 충돌합니다. Canton은 현재 간단한 비관적 충돌 해결 정책(simple pessimistic conflict resolution policy)을 구현하고 있으며, 이는 이전 요청 자체가 나중에 어느 시점에서 거부되더라도 항상 이후 요청에 실패합니다.

상충되는 응답 (Conflicting responses)
상충되는 응답을 받았습니다. 캔톤에서는 참가자 중 한 명이 비잔틴인 경우에만 발생합니다.

충돌 감지

참가자는 트랜잭션이 소비하는 계약을 잠가(locked) 동시 트랜잭션 간의 충돌을 감지합니다. 참가자는 계약을 보관(archives)하는 트랜잭션의 확인 요청을 받으면 계약을 잠급니다. 잠금은 계약이 보관될 수 있음을 나타냅니다. 중재자의 결정이 나중에 도착하면 계약이 다시 잠금 해제되고 거래가 승인되면 보관됩니다. 거래가 보관된 계약을 사용하려는 경우가 거래는 Canton의 현재 버전에서는 거부됩니다. 이 디자인 결정은 트랜잭션이 일반적으로 수락된다는 낙관적 가정을 기반으로 합니다. 따라서 나중에 충돌하는 거래는 비관적으로 거부(pessimistically rejected)될 수 있습니다.

다음 3개의 다이어그램은 DA 원장 모델의 카운터 오퍼 예제(counteroffer)를 사용하여 잠금 및 비관적 거부(pessimistic rejections)를 보여줍니다. 2개의 트랜잭션과 3개의 당사자가 있으며 모든 당사자는 자체 참가자 노드를 실행합니다.

• 화가 P는 트랜잭션 tx1에서 A의 반대 카운터오퍼를 수락합니다. 이 거래는 두 가지 계약을 소비합니다.

  • A와 은행 사이의 Iou, c1이라고 합니다.
  • 이해 관계자 A와 P에 대한 카운터오퍼 (c2라고 함).
    생성된 계약(새 Iou 및 PaintAgreement)은 이 예제와 관련이 없습니다.

• 카운터오퍼에 A가 제어하는 추가 소비 선택이 포함되어 있다고 가정합니다. 예를 들어 Alice는 Counteroffer를 철회할 수 있습니다. 트랜잭션 tx2에서 A는 Counteroffer를 사용하(consuming)기 위해 이 선택(choice)을 실행(exercises)합니다.

시퀀서의 메시지는 (가상)글로벌 시간에 모든 참가자를 동기화하므로 모든 참가자가 동시에 잠금, 잠금 해제 및 보관을 수행한다고 생각할 수 있습니다.

첫 번째 다이어그램에서 시퀀서는 tx2보다 먼저 tx1을 시퀀스 합니다. 결과적으로 A와 Bank는 확인 요청을 받으면 c1을 잠그고 c2에 대해 A와 P도 잠급니다. 따라서 tx2가 나중에 A와 P에 도착하면 계약 c2가 잠깁니다. 따라서 A와 P는 거절로 응답하고 중재자는 이를 따릅니다. 이와 대조적으로 모든 이해관계자는 tx1을 승인합니다. 중재자의 승인이 참가자에게 도착하면 각 참가자는 적절한 계약을 보관합니다. A 보관 c1 및 c2, 은행 보관 c1 및 P 보관 c2.

두 트랜잭션이 진행중에 충돌하면 이후 트랜잭션은 항상 거부됩니다.

두 번째 다이어그램은 P가 카운터오퍼를 수락하기 전에 A의 철회 순서가 지정되는 시나리오를 보여줍니다. 따라서 A와 P는 시퀀서로부터 tx2에 대한 확인 요청을 받고 나중에 승인할 때 c2를 잠급니다. tx2, A 및 P의 경우 c2가 보관될 가능성이 있으므로 tx2를 거부하는 반면 Bank에서는 모든 것이 괜찮아 보입니다. 따라서 은행과 A는 일관성을 위해 중재자가 tx1에 대한 거절을 보낼 때까지 c1을 잠그게 됩니다.

이제 트랜잭션 tx2가 tx1보다 먼저 제출됩니다. 소비된 계약 c1은 중재자가 결과 메시지를 보낼 때까지 거부된 트랜잭션에 의해 잠긴 상태로 유지됩니다.

[노트]
실제로 참가자는 트랜잭션 전체가 아닌 각 뷰를 개별적으로 승인합니다. 따라서 A는 tx1에 대해 두 개의 응답을 보냅니다. c1의 보관에 대한 승인과 c2의 보관에 대한 거부입니다. 다이어그램은 이 전문성을 생략합니다.

세 번째 다이어그램은 잠금 및 비관적 거부가 부정확 한 응답으로 이어질 수 있는 방법을 보여줍니다. 이제 화가의 tx1 수용은 첫 번째 다이어그램에서와 같이 Alice의 철회 전에 순서가 지정되지만 A와 Bank 사이의 Iou는 이미 앞서 보관 되었습니다. P는 Iou c1의 이해관계자가 아니기 때문에 화가는 c2에 대한 뷰 만 받습니다. 모든 것이 괜찮아 보이므로 tx1에 대한 확인 요청이 도착하면 P는 c2를 잠급니다. 일관성을 위해 A는 동일한 작업을 수행하지만 A는 이미 c1이 아카이브 되어 트랜잭션이 실패할 것임을 알고 있습니다. 따라서 P와 A는 잠긴 계약 c2를 소비하려고 하기 때문에 tx2를 거부합니다. 나중에 tx1의 거부가 도착하면 c2가 다시 활성화되지만 트랜잭션 tx2는 거부된 상태로 유지됩니다.

이전 트랜잭션 tx1이 나중에 거부되더라도 나중에 충돌하는 트랜잭션 tx2는 거부된 상태로 유지되고 계약은 결과 메시지가 나타날 때까지 잠긴 상태로 유지됩니다.

도메인 엔티티

Canton 도메인은 세 개의 엔티티로 구성됩니다.

• 시퀀서 (sequencer)
• 중재자 (mediator)
• ID 관리자(identity manager), PKI 인프라(PKI infrastructure)를 제공하고 참여자 매핑을 제공합니다.

이를 도메인 엔티티라고합니다. 도메인 엔터티 간의 상위 수준 통신 채널(high-level communication channels)이 아래에 설명되어 있습니다.

일반적으로 모든 도메인 엔터티는 별도의 트러스트 도메인에서 실행될 수 있습니다 (즉, 독립적인 조직에서 운영할 수 있음). 실제로 모든 도메인 엔터티가 단일 조직에서 실행되고 도메인 엔터티가 단일 트러스트 도메인에 속한다고 가정합니다.

또한 각 참가자 노드는 자체 신뢰 도메인에서 실행되며, 참가자는 ID 관리 인프라의 일부를 예컨데 인증 기관에 아웃소싱 할 수 있습니다. 참가자가 이 인프라를 신뢰한다고 가정합니다. 즉, 참가자와 해당 ID 관리가 동일한 신뢰 도메인에 속한다고 가정합니다. 일부 참가자 노드는 VIP 노드로 지정될 수 있습니다. 이는 신뢰할 수 있는 당사자가 운영합니다. 이러한 노드는 VIP 확인 정책에 중요합니다.

일반적으로 구성원은 도메인 엔터티 또는 참여자 노드를 나타냅니다.

시퀀서 (Sequencer)

이제 시퀀서에 대한 하이레벨의 요구 사항을 나열합니다.

순서 (Ordering) : 시퀀서는 메시지에 고유한 타임스탬프가 지정되고 글로벌 순서가 타임스탬프에서 파생되는 글로벌 전체 주문/순서 멀티 캐스트(global total-order multicast)를 제공합니다. 시퀀서는 단일 메시지를 전달하는 대신 메시지 일괄 처리, 즉 개별 메시지 목록이을 제공합니다. 이 모든 메시지는 포함된 배치의 타임스탬프를 얻습니다.(All these messages get the timestamp of the batch they are contained in) 각 메시지는 다른 수신자 집합을 가질 수 있습니다. 각 수신자의 배치(일괄처리)에 있는 메시지는 보낸 배치와 동일한 순서로 되어 있습니다.

증거 (Evidence) : 시퀀서는 수신인에게 배치 순서에 대한 증거를 포함하여 전달하는 모든 메시지 배치에 대한 암호화된 진위 증명을 제공합니다.

발신자 및 수신자 개인 정보 보호 (Sender and Recipient Privacy) : 수신자는 제출 한 참가자의 신원을 알지 못합니다. 수신인은 자신이 해당 메시지의 받는 사람인 경우 배치(일괄적으로)에서 특정 메시지에 대한 받는 사람의 ID(신원) 만 학습합니다.

중재자 (Mediator)

중재자의 목적은 확인 요청에 대한 최종 결과를 계산하여 참가자에게 배포함으로써 참가자 간에 거래가 원자 적으로 수행되도록 하는 동시에 참가자의 개인 정보를 서로에게 공개하지 않음으로써 개인 정보를 보호하는 것입니다. 하위레벨 요구사항 :

• 참가자로부터 확인 응답을 수집
• Canton 프로토콜에 따라 검증
• 확인 정책에 따라 결론 (승인 / 거부 / 시간 초과)을 계산
• 결과 메시지를 전송

또한 감사 가능성을 위해 중개자는 수신된 모든 메시지 (정보 제공자 정보 또는 확인 응답 포함)를 장기간 보관 상태로 유지하고 감사자가 이 저장소에서 메시지를 검색할 수 있도록 허용합니다.

ID 관리자 (Identity Manager)

ID 관리자를 통해 참가자는 Canton 도메인에 가입 및 탈퇴할 수 있으며 공개키를 등록, 해지 및 교체할 수 있습니다. 아는 주어진 참가자가 주최하는 당사자를 알고 있습니다(It knows the parties hosted by a given participant). 각 참가자의 신뢰 수준을 정의하며, 신뢰 수준은 보통 또는 VIP입니다. VIP 신뢰 수준은 참가자가 정직하게 행동할 수 있음을 나타냅니다. 예들들면, 신뢰할 수 있는 시장 운영자에 의해 운영되는 참가자들일수 있습니다.

참가자 내부 Canton 구성 요소 (Participant-internal Canton Components)

Canton은 코드 재사용을 촉진하기 위해 DAML-on-X 아키텍처를 사용합니다. 이 아키텍처에서 참여자 노드는 일련의 서비스 세트로 세분화되며 그중 하나를 제외한 모든 서비스는 원장 구현에서 재사용됩니다. 이 원장 별 서비스는 Canton이 프로토콜을 사용하여 구현하는 원장 동기화 서비스 (Ledger Synchronization Service)(LSS)라고 합니다. 이 구현은 더 나아가 여러 구성 요소로 더 세분화됩니다. 이제 각 구성 요소의 인터페이스와 속성을 설명합니다. 다음 그림은 서로 다른 구성 요소 간의 상호 작용과 기존 Ledger API의 명령 및 이벤트 서비스와의 관계를 보여줍니다.

다음으로 각 구성 요소를 차례로 설명합니다.

트랜젝션 (Transactions)
이것은 Canton 내 LSS의 핵심 구성 요소입니다. 아래에서 주요 작업에 대해 설명합니다.

제출 및 분리 (Submission and Segregation) : DAML 트랜잭션은 트리와 같은 구조를 갖습니다. 원장 개인정보보호 모델은 거래의 어느 부분이 어느 당사자에게 표시되는지에 따라서 참가자에게 표시되는지 정의합니다. 각 수신자는 볼 수 있는 하위 트랜잭션(projection)만 얻습니다. 트랜잭션의 다른 부분은 암호화된 형식이 아니라도 참가자와 공유되지 않습니다. 또한 확인 정책에 따라 일부 정보 제공자는 확인자로 표시됩니다. 참가자들에게 거래 projections을 배포하는 것 외에도 제출자는 거래에 대한 정보 제공자 및 확인자에 대해 중재자에게 알립니다.

유효성 및 확인 응답 (Validity and Confirmations Responses) : 요청된 트랜잭션의 각 정보 수신인은 가시적인 하위 트랜잭션의 유효성에 대해 로컬 검사를 수행합니다. 정보 제공자는 제공된 프로젝션(projection)이 DAML 의미 체계(semantics) 및 원장 권한 부여 모델을 준수하는지 확인합니다. 또한 요청이 수락되었거나 아직 결정되지 않은 이전 요청과 충돌하는지 여부를 확인합니다. 이를 바탕으로, 그들은 그들의 프로젝션(projection)를 위한 정보와 함께 응답(각각의 견해에 대해 하나씩)을 중재자에게 보냅니다. 다른 참가자 또는 도메인 엔터티가 프로토콜에 따라 동작하지 않는 경우 (예 : 적시에 확인 응답을 보내지 않거나 잘못된 요청을 보내면) 트랜잭션 처리 구성 요소가 경보를 발생시킵니다.

확인 결과 처리(Confirmation Result Processing) : 중개자의 결과 메시지에 따라 트랜잭션 구성 요소가 요청된 트랜잭션을 커밋하거나 중단합니다.

시퀀서 클라이언트 (Sequencer Client)

시퀀서 클라이언트는 시퀀서에 대한 연결을 처리하고 순차 전달을 보장하며 시퀀서의 메시지에 대한 암호화 인증 증명을 저장합니다.

ID 클라이언트 (Identity Client)

ID 클라이언트는 도메인 ID 관리자에서 오는 메시지를 처리하고 수신된 ID 정보 변경의 유효성을 확인합니다 (예 : 공개 키 위임의 유효성).

시스템 모델 및 신뢰 가정 (System Model And Trust Assumptions)

Canton 도메인이 지정하는 다양한 규칙 세트는 다양한 방식으로 보안 및 활성(liveness) 속성에 영향을 미칩니다. 이 섹션에서는 우리가 가정하는 시스템 모델과 신뢰 가정(trust assumptions)을 소개합니다. 일부 신뢰 가정은 텍스트에 표시된 도메인 규칙에 따라 다릅니다. 하이 레벨 요구 사항에 지정된 대로 시스템은 정직하게 대표되는 당사자에게만 보증을 제공합니다. 따라서 모든 당사자는 프로토콜을 올바르게 실행하기 위해 참가자(다른 참가자는 제외)를 완전히 신뢰해야 합니다. 특히, 참여 노드의 서명은 거래 프로토콜에서 당사자의 행동의 증거로 간주될 수 있습니다.

시스템 모델 (System Model) 가정

• 두 시스템 구성원 간에 쌍방향 통신이 가능
• 참가자 노드를 시퀀서 및 referees에 연결하는 링크는 대부분 문제 없음
• there exists a known bound on the delay such that the overwhelming majority of messages exchanged between the participant and the sequencer are delivered within
• Domain entities are assumed to have clocks that are closely synchronized (up to some known bound) for an overwhelming majority of time
• 참가자가 시스템 내 메시지 대기 시간에 대한 확률 분포를 알고있음

일반 신뢰 가정 (General Trust Assumptions)

이러한 가정은 개인 정보를 제외한 모든 시스템 속성과 관련이 있습니다.

• 시퀀서는 증거와 함께 글로벌 총 주문 멀티 캐스트 서비스를 올바르게 제공하고 발신자와 수신자의 프라이버시를 보장하는 것으로 신뢰됩니다..
• 중재자는 모든 결과를 올바르게 생성하고 배포하는 것으로 신뢰됩니다.
• 정직한 참여자의 ID 관리자 (기본 공개 키 인프라 포함)가 올바르게 작동하고 있습니다.

VIP 확인 정책과 함께 트랜잭션이 제출되면(이 경우 트랜잭션의 모든 작업에는 VIP 정보 수신자가 한 명 이상 있어야 함) 추가 무결성 가정이 있습니다.

• 모든 VIP 이해 관계자는 정직한 참가자, 즉 거래 프로토콜을 올바르게 실행하는 참가자가 호스팅 해야 합니다.

가정이 너무 강력하다고 간주되는 경우 비잔틴 내결함성 복제 프로토콜을 사용하여 여러 조직 간에 신뢰할 수 있는 엔터티를 복제하면 가정이 약화될 수 있습니다. 또한 프로토콜에 대한 일부 확장을 통해 대부분의 경우 적어도 한 명의 참가자가 감지할 수 있는 위의 가정 중 하나를 위반할 수 있으며 다른 참가자 나 외부 주체에게도 증명할 수 있습니다. 이를 위해서는 참가자 간의 직접적인 의사소통이 필요하며 향후 작업으로 남겨 둡니다.

개인 정보 보호와 관련된 가정 (Assumptions Relevant for Privacy)

다음과 같은 일반적인 가정은 개인 정보 보호와 관련이 있습니다.

• 정직한 참가자의 개인 키는 손상되지 않으며 정직한 참가자가 사용하는 모든 인증 기관을 신뢰할 수 있습니다.

• 시퀀서(sequencer)는 다음과 같은 권한을 가집니다.

  1. 모든 메시지의 제출자와 수신자
  2. 정보 제공자 및 확인 당사자를 포함하여 확인 요청의 트랜잭션 보기 구조
  3. 확인 자의 확인 응답 (승인 / 거부 / 잘못된 형식).
  4. 암호화된 트랜잭션 보기
  5. 모든 메시지의 타임스탬프

• 시퀀서는 운영 절차 (예 : 오프라인 당사자에게 메시지 전달 또는 충돌 복구)에 필요한 것보다 오랫동안 메시지를 저장하지 않는 것으로 신뢰됩니다.

• 중재자(mediator)는 다음과 같은 권한을 가집니다.

  1. 정보 제공자 및 확인 당사자, 제출 당사자를 포함한 트랜잭션의 보기 구조
  2. 확인 자의 확인 응답 (승인 / 거부 / 잘못된 형식)
  3. 메시지의 타임스탬프

• 거래의 일부에 대한 정보제공자는 동일한 부분에서 다른 이해관계자의 개인정보를 침해하지 않는 것으로 신뢰됩니다. 특히 제출자는 트랜잭션 및 계약 ID에 대해 강력한 임의성을 선택하는 것으로 신뢰됩니다. Canton은 이러한 ID의 고유성을 보장하므로 이러한 가정은 무결성과 관련이 없다는 점에 유의하십시오

VIP 확인 정책을 사용하여 트랜잭션을 제출할 때 트랜잭션의 모든 작업에는 적어도 한 명 이상의 VIP 정보 수신자가 있어야 합니다. 따라서 VIP 정보 제공자는 원장 개인정보 보호 모델에 따라 거래의 전체 내용에 대해(볼수있는) 자동으로 권한을 갖습니다.

활성과 관련된 가정 (Assumptions Relevant for Liveness)

일반적인 신뢰 가정 외에도 시스템의 활성(liveness)및 제한된 활성 기능 요구 사항과 관련하여 다음과 같은 추가 가정이 관련됩니다. 제한된 결정 시간 및 불필요한 거부 없음(bounded decision time, and no unnecessary rejections)

• Canton의 모든 도메인 엔티티(시퀀서, 중재자 및 ID 관리자)는 가용성이 높습니다.

• 시퀀서는 메시지를 시기적절하고 공정하게 전달하도록 신뢰됩니다 (대기 시간에 대한 확률 분포로 측정).

• 도메인 ID 관리자는 모든 ID 업데이트를 올바르게 전달(forwards)합니다.

• 확인 정책(confirmation policy)에 따라 확인 당사자를 호스팅하는 참가자는 가용성이 높고 올바르게 응답하는 것으로 간주됩니다. 예를 들어 VIP 확인 정책(VIP confirmation policy)에서는 VIP 참가자만 참석 가능해야 하는 반면 서명자 정책(signatory policy)에서는 활성 상태가 서명자와 행위자를 호스트하는 모든 참가자의 가용성(참석 가능)에 따라 달라집니다.

원문 : Overview and Assumptions
https://www.canton.io/docs/stable/user-manual/architecture/overview.html