잠재적 서명자에 대한 적합한 디자인 패턴

Q

몇 가지 잠재적인 서명자 중 하나가 될 수 있는 서명인이 있는 템플릿을 사용하는 데 가장 적합하거나 가장 많이 사용되는 패턴은 무엇입니까? (Jean, Pierre 또는 Paul 중 한 사람이 계약서의 서명자 일 수 있습니다. 가능합니까?)

A1
러한 종류의 것은 권한 부여 측면에서 구현할 수 있지만 그룹 / 역할에 대한 변경 사항이 (불변) 계약을 통해 전파되어야 하므로 현재 개인 정보 / 가시성 측면에서 까다 롭습니다. 그러한 변화가 영향을 미칩니다.

가시성 문제를 무시하고 다음을 구현할 수 있습니다.

template TradeApproverGroup
  with
     admins : Set Party
     members : Set Party
     groupName : Text
  where
     signatory admins
     observer members
     key (admins, groupName) : (Set Party, Text)
     maintainer key._1

     choice AddMember ...
     choice RemoveMember ...
     choice PromoteMember ...
     choice DemoteAdmin ...


template TradeApprovalRequest
  with
     group : TradeApproverGroup
     requester : Party
  where
     signatory requester
     observer group.members

     choice Accept : ContractId TradeApproval
     with
       approver : Party
     do
       (groupCid, actualGroup) <- fetchByKey @TradeApproverGroup (group.admins, group.name)
       assert (approver /= requester && group == actualGroup)
       create TradeApproval with ..

위의 문제는 미결 TradeApprovalRequest가 있는 동안 그룹이 업데이트되는 경우 요청에서 그룹을 어떻게 업데이트합니까?

제안 된 솔루션은 이러한 그룹에 당사자를 할당하는 것입니다

template TradeApproverGroup
  with
     admins : Set Party
     groupParty : Party
     members : Set Party
  where
     signatory admins, groupParty
     observer members
     key groupParty : Party
     maintainer key

     choice AddMember ...
     choice RemoveMember ...
     choice PromoteMember ...
     choice DemoteAdmin ...


template TradeApprovalRequest
  with
     group : Party
     requester : Party
  where
     signatory requester
     observer group

     choice Accept : ContractId TradeApproval
     with
       approver : Party
     do
       (groupCid, actualGroup) <- fetchByKey @TradeApproverGroup group
       assert (approver /= requester && approver `elem` actualGroup.members)
       create TradeApproval with ..

이러한 작업을 수행하는 데 누락된 기능은 모든 구성원이 TradeApprovalRequest를 볼 수 있도록 API를 통해 그룹 파티로 읽을 수 있다는 것입니다. 안타깝게도 아직 가능하지 않기 때문에 지금은 멤버십을 비교적 안정적으로 유지하거나 관찰자에게 변경 사항을 전파해야 합니다.

A2
DAML에서 이러한 종류의 모델 제약 조건을 표현하는 것은 항상 흥미롭습니다. DAML 시스템을 확장할 수 있도록 DAML 원장 모델은 제약 조건을 표현하는 방법에 몇 가지 엄격한 제한 (시스템 제약)을 부과합니다. 제 경험으로는 이것이 실망스러울 수 있지만 설계 내에서 이러한 사항을 고려하고 수용하는 것은 일반적으로 비즈니스 문제에 대한 이해도를 향상시키며, 더 중요한 것은 최종 설계가 덜 취약하고 미래의 요구사항 변화에 더 잘 적응할 수 있게 합니다.

1. DAML 트랜잭션이 아는 유일한 것은 원장에서 읽을 수 있는 내용이며, 원장에서 내용을 알 수 있는 유일한 방법은 그것에 대해 명시적으로 표현하는것(explicitly told about it)입니다. 이는 정확히 하나의 예외를 제외하고 DAML의 모든 제약이 실존 적으로 표현되어야 함을 의미합니다. DAML에서 보편적으로 정량화된 유일한 제약은 키 고유성 제약이며, 전체 유지 관리의 의미(whole maintainer semantic) 체계와 키 유지 관리 프로토콜을 도입해야 하는 제약도 있습니다.

2. 키의 고유성을 제외하고 (다시)새로운 계약 생성에 대한 모든 제약조건은 계약 자체의 정적 로컬 범위 내에서 평가되어야 합니다.

이 두 가지 모두 계약의 생성과 계약 이행을 보장하며, 제한된 계약 집합(bounded set of contracts)을 참조하여 초이스(chioce)을 평가하고 유효성을 검사 할 수 있습니다.

DAML이 다수의 당사자로 확장될 수 있도록 하려면 DAML의 모든 제약조건은 계약에 대한 제약으로 실존 적으로 표현되어야합니다. 따라서 제출자는 자신이 알지 못하는 계약의 존재를 통보 받음으로써 거래 결과에 놀라지 않을 것입니다. 이는 DAML이 분산 시스템으로 효과적으로 확장될 수 있도록 하는 데 중요합니다.

따라서 문제에 대해 생각해보면..

1. 템플릿에는 서명자가 없으며 계약만 있습니다. 따라서 이 답변의 나머지 부분에서는 " … 사이에 서명인과의 계약"을 보장해 주길 원한다고 가정하겠습니다.

2. 시스템 제약 사항 1(system-constraint 1) 을 상기하십시오. DAML이 알고 있는 유일한 것은 원장에서 읽을 수 있는 것입니다. 즉, "서명자가 반드시 사인을 해야할 부분(parties from which the signatories must be drawn)"라는 생각이 어떻게 든 원장에 존재해야 합니다. DAML은 대칭적인 다자간 시스템이라는 것을 유의하세요. 전통적인 아키텍처와 달리 특권적인 관점, 슈퍼 유저, 선험적 센터가 없습니다.

그 결과 DAML 모델(즉, 템플릿)은 어쨌든 당신에게 특권이 있다는 생각을 표현할 수 없고,Jean이 계약을 "Jean, Pierre, Paul"로 제한할 수 있는 어떤 모델도 Andrae가 계약을 "John, Peter, Paula"로 제한할 수 있다는 제약조건을 표현할 수 있다는 것입니다. 왜냐하면 그렇게 하지않으면 원장의 보편적인 속성을 표현하는 것이 될 것이고, 우리는 실존 적 예측으로 국한될것이기 때문입니다.

따라서 우리는 제약의 맥락을 실존적으로 모델링할 필요가 있습니다. 구체적으로는 서술자 (Jean 또는 Andrae)의 관점을 명시적으로 모델링해야 합니다. 모든 모델링에서와 같이 이것은 적어도 두 가지 방식, 즉 의도적으로 또는 확장 적으로 달성될 수 있습니다. 제 경험상 DAML은 의도적으로 사용할 때 최고이므로 먼저 다룰 것입니다.

집중적 모델은 행동과 함의(함축)에 초점을 맞추고 있습니다. 우리는 상태를 데이터로 모델링하는 것이 아니라 이전 행위에 암시된 일련의 행동(choices)및 해당 행동에 대한 제약으로 모델링합니다. 이 접근 방식은 DAML을 대칭 분산 시스템에서 실행(praxis)의 일관성을 달성하는 동시에 중앙 권한을 거부하는 수단으로 간주합니다.

이것이 의미하는 바는 원장에 계약이 있는 경우 어느 시점에서 잠재적인 행위에 대한 합의가 있었으며 그중 하나가 이 계약을 생성하게 된 것입니다.(계약 생성에 대한 합의)

즉 계약이 있는겨우

-- (Note the explicit modelling of the `predicator`, there is no implicit authority you can appeal to, there is nothing that is not on the ledger).

template OneOfN
  with
    predicator: Party
    signer: Party
  where
    signatory predicator, signer

그렇다면이 계약을 작성할 권리가 있었을 것입니다.

template RightToCreateOneOfN
  with
    predicator: Party
    potentialSigners: Set Party
  where
    signatory predicator

    nonconsuming choice CreateOneOfN: ContractId OneOfN
      with
        signer: Party
      controller signer
      do
        create OneOfN with predicator; signer

… 이제 근거(predicate)를 통해 말할 수 있습니다. Jean은 권한 내의 모든 OneOfN 계약이 지정된 서명자 중 한 사람이 서명해야 한다고 요구합니다. 제약조건 자체는 원장의 데이터로 모델링 되는 것이 아니라 해당 계약의 생성으로 이어진 사전 선택/행동권이 어떤것에 의해 인가된 행동권이 그 계약을 체결하게 된다는 점에 유의하도록 합니다. (but as a choice, a right to act that has been authorised by whatever prior 'choice/right-to-act' led to the creation of that contract.)

그렇습니다, 의도적으로는 동의를 요구하거나 대표하지 않는 일방적인 발언을 자체적으로 승인할 때까지 느리게 진행됩니다.(turtles)

그렇습니다, 긴장감 있게 합의및 동의를 요구하거나 대표하지 않는 일방적인 연설 행위에 도달할 때까지 내내 느리게 진행됩니다.

대안은 이 모델을 확장적으로 모델링하는 것입니다. 이는 시스템의 상태를 데이터로 나타내고 시스템에 대한 제약을 해당 데이터의 허용 값에 대한 제약조건으로 나타냅니다. 따라서 당연히 이것은 시스템 제약 2를 준수해야 합니다. 제약조건 1을 다시 표현하는 한 가지 방법은 "모든 강도의 제약조건은 실존적으로 예측되어야 한다" 입니다. 유사하게 제약조건 2도 다음과 같이 표현될 수 있다 : "모든 확장적 제약조건은 로컬 계약 이어야 한다".

따라서 계약 서명자를 일련의 당사자로 제한하려는 경우 해당 조건자는 해당 계약의 데이터 측면에서만 독점적으로 표현되어야 합니다. 그래서:

template OneOfNLocal
  with
    signer: Party
    potentialSigners: Party
  where
    signatory signer
    ensure signatory elem potentialSigners

이제 이 제약 조건이 요구 사항의 문자를 인코딩 하지만 정신에 훨씬 못 미친다는 것을 즉시 알 수 있습니다(it falls well short of the spirit.). 위에서 언급했듯이 DAML은 집중(강도높은) 모델링 언어를 선호합니다. 이 난관의 근본은 중앙 권한이 없다는 것입니다. 그래서 단일 서명 템플릿으로서, 이것은 조건부 상태에 대한 합의가 아니라 서명자에 의한 일방적 발언 행위를 나타냅니다. 여기서 우리는 필연적으로 진실을 표현할 수 있는 모든 시스템이 필요에 따라 거짓말을 표현할 수 있다는 에코의 관찰을 볼 수 있습니다.

이러한 이유 때문에 DAML 모델링에서 보증 조항이 거의 없습니다. 그러나 이러한 종류의 제약이 적절할 때가 있기 때문에 이 토론에서 무시하고 싶지 않았습니다.

일반적으로 계약의 선택(contract’s choices)에 대한 전제 조건을 보장합니다 (예 : 목록 / 집합이 비어 있지 않거나 숫자가 양수이거나 0이 아님 등).

요약 : DAML은 대칭적이고 비 중심적입니다. 그러한 모델링은 권위에 대해 명시적이고 실존적으로 예측되고 항상 집중(강도높은)되어야 하기 때문입니다. 이는 항상 암묵적인 중앙 권한을 가지고 있고 보편적으로 정량화된 다양한 술어(existentially predicated)를 허용하며, 확장 데이터의 조작을 중심으로하는 기존 모델링에서 크게 벗어났습니다.
그러나 이 방식은 결과 모델의 확장 가능하고 분산 된 응용 프로그램에있어 좋은 일이며 필수적입니다.

원문 : Indicate list of OR signatories
https://discuss.daml.com/t/indicate-list-of-or-signatories/786