금융 라이브러리 - 파트2

금융 라이브러리에 대한이 DAML 마스터 클래스의 두 부분으로 구성된 하위 시리즈의 첫 번째 부분에서 금융 라이브러리 응용 프로그램을 리버스 엔지니어링 하기 시작했습니다.

여기에서 5 개의 큰 아이디어를 확인했고, 그중 첫 번째 부분에서 3 개를 제시했다. 나머지 두 가지 아이디어가 있습니다.

---

빅 아이디어 # 4 : 동적 서명자 집합 (a dynamic set of signatories)

때로는 계약에 동적 서명자 집합이 있어야 합니다.
이는 서명자가 계약의 선택을 미리 승인하기 때문에 중요할 수 있습니다.
이 메커니즘은 간단한 제안/수락 패턴으로도 작동하므로 여러 당사자가 서명 한 계약을 생성할 수 있습니다.

일반적으로 제안/수락 패턴은 다음과 같이 작동합니다. 제안 계약에는 서명자를 설정하는 변수가 있습니다. 최종 계약에 필요한 모든 서명자는 제안 계약 인스턴스의 진화(보관 및 생성)를 통해 단계적으로 서명자 집합에 추가됩니다.
의도된 모든 서명자들이 제안서 계약에 서명할 때까지, 그들은 취소할 수 있는 고정된 서명자 세트를 포함하는 최종 계약의 작성을 승인한 것입니다. (이 주제에 대한 이전 블로그 게시물 How DAML smart contracts are digital twins of human relationships을 참조하십시오.)

이 하위 시리즈의 첫 번째 부분의 세 번째 섹션(빅 아이디어 #3: multistep 결제 체인)에서 제시된 결제 체인의 경우에도 유사한 작업이 이루어지며, 이 경우 개별 단계의 모든 중간 발신자는 배정된 자금(자산 예금 계약)의 이전을 사전에 승인하고자 한다. 이것이 자산배분의 목적입니다.

이렇게 되면 이미 자금을 할당받은 발송인(발신자 완료 목록 구성원)은 다음 SettlementInstruction 계약 인스턴스의 서명자가 되고, 아직 자금을 할당하지 않은 발송인(발신자 보류 목록의 구성원)는 관찰자(observers) 가 됩니다.

where
    signatory union masterAgreement.id.signatories $ fromList sendersDone
    observer insert masterAgreement.party1 $ insert masterAgreement.party2
      $ union observers $ fromList sendersPending

sendersDone 및 sendersPending 목록의 구성원은 Either 데이터 유형 및 partitionEithers 함수를 사용하는 다음 목록(list) 함수에 의해 수집(collected)됩니다.

let (sendersDone, sendersPending) = partitionEithers $
          map (\x -> if isSome x.depositCid then Left x.senderAccount.owner else Right x.senderAccount.owner) steps

이미 자금을 할당받은 송금인(senders)은 isSome boolean 함수로 확인되는 선택적 자산예금계약(optional asset deposit contract) ID 필드가 이미 채워져있는 단계의 발송인임을 인식할 수 있다. partitionEithers 함수는 Either 값을 기반으로 파티션을 생성하여 Left a 값을 첫 번째 파티션으로 수집하고 Right a 값을 두 번째 파티션으로 수집합니다.

Either 데이터 유형 및 partitionEithers 함수의 기능을 이해하려면 DAML REPL에서 함수의 단순화 된 버전을 확인해 보세요.

아래의 DAML 표현식은 목록의 홀수 값과 짝수 값을 분할합니다. 동작을 테스트 할려면 DA.Either 라이브러리 모듈을 추가해야합니다.

daml> :m + DA.Either
daml> let odd (x : Int) = x % 2 == 1
daml> let (oddMembers, evenMembers) = partitionEithers $ map (\x -> if odd x then Left x else Right x) [1..10]
daml> oddMembers
[1,3,5,7,9]
daml> evenMembers
[2,4,6,8,10]
daml>

빅 아이디어 # 5 : 고급 원장 업데이트 : 가져 오기 및 보관 (advanced ledger update: fetch and archive)

fetchAndArchive 함수 (Utils 모듈에 정의 됨)가 간단하고 짧고 그 이름이 의미하는 것 이상을 수행하지 않기 때문에 이 기능은 특별하지 않은것 처럼 보일 수 있습니다.

-- | Fetches a contract, archives it and returns its value.
fetchAndArchive : Template a => ContractId a -> Update a
fetchAndArchive cid = do
  c <- fetch cid
  archive cid
  return c

그러나 이 기능은 다음과 같은 이유로 중요합니다.

DAML 원장 업데이트는 UTXO 모델 을 따르므로 어떤 의미에서 비트코인의 운영 모델과 유사합니다. 모든 원장 업데이트는 트랜잭션에 의해 소비되거나 소비되지 않을 수 있는 0 개 이상의 입력과 0 개 이상의 출력이 있는 트랜잭션입니다.

DAML에는 계약 템플릿 구문과 별개로 원장 업데이트 트랜잭션 구문이 없습니다. 모든 원장 업데이트는 create 명령을 실행하는 계약 템플릿 또는 exercise 명령을 사용하는 기존 계약 인스턴스에서 수행됩니다.

DAML 원장 업데이트 트랜잭션이 두 개 이상의 입력 계약을 어떻게 소비(consume)할 수 있는지 궁금할 것입니다. 답은, 업데이트가 특정 계약에 대한 선택으로 프로그래밍되며, 그 선택(choice)에는 트랜잭션의 다른 입력(들)을 가져와서 보관하는 업데이트가 포함되어야 한다는 것입니다(물론, 입력(input)이 소비되기를 원하는 경우에만 해당).

독립형 fetchAndArchive 함수는 이 중요한 케이스의 약어입니다(shorthand for this important case). 따라서 두 개의 기존 계약 인스턴스를 입력으로 사용하는 인스턴스에 대한 트랜잭션은 개념적으로 다음과 같습니다.

DAML Masterclass 시리즈의 후속 부분에서는 다음 참조 응용 프로그램에 대해 작성합니다.

• Asset Servicing
• Healthcare Claims Processing
• DABL Chess

출처 : The Finance Library — Part 2
https://medium.com/daml-masterclass/the-finance-library-part-2-f8123e99d5bd