라리월드

*  본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.
상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger-fabric.readthedocs.io/en/release-1.4/blockchain.html

Introduction

하이퍼레저 패브릭은 높은 수준의 기밀성, 탄력성, 유연성 및 탄력성을 제공하는 모듈식 아키텍쳐에 기반을 둔 분산원장솔루션을 위한 플랫폼이다. 이는 다양한 요소의 플러그 방식 구현 및 경제생태계에 존재하는 복잡함을 지원할 수 있도록 설계되었다. 

처음 사용하는 사용자들에게는 아래 introduction의 나머지 부분을 통해 어떻게 블록체인이 동작하고 하이퍼레저 패브릭의 특징 및 구성요소들은 어떤 것들이 있는지에 친숙해지는 것을 추천한다.

익숙해진 다음, 혹은 이미 블록체인 및 하이퍼레저 패브릭에 익숙하다면 Getting Started 섹션으로 가서 데모 프로그램 및 기술 명세, API들을 살펴보면 된다. 

What is a Blockchain?

A Distributed Ledger

블록체인 네트워크의 핵심은 네트워크에서 발생하는 모든 트랜잭션을 기록하는 분산 원장이다.

블록체인 원장은 보통 탈중앙화되어 있다고 하는데, 이는 블록체인 네트워크를 유지하는데 협력하는 각각의 다양한 네트워크 참가자들에게 복제되기 때문이다. 우리는 탈중앙화 및 협력이 현실 세계에서 상품 및 서비스를 교환하는 비즈니스 거래를 반영한 강력한 속성임을 알 수 있다.

탈중앙화 및 협력적일뿐 아니라 블록체인에 기록되는 정보는 오로지 추가만이 가능하다. 이는 트랜잭션이 한번 원장에 추가되면 수정될 수 없음을 보장하는 암호화 기술이다. 이러한 "변경할 수 없는" 속성은 정보의 출처를 쉽게 알 수 있게 해준다. 왜냐하면 참가자들은 진자 정보가 이후 수정되지 않았음을 확신할 수 있기 때문이다. 이것이 바로 블록체인이 증명시스템이라고 불리는 이유이다.

Smart Contract

정보의 업데이트에 일관성을 유지하고 전체 원장 기능 (트랜잭션, 쿼리 등) 을 가능하게 하기 위해 블록체인 네트워크는 스마트 컨트랙트를 사용한다. 이는 원장에 대한 접근을 제어하기 위한 것이다.

스마트 컨트랙트는 정보를 캡슐화하고 네트워크를 통해 이를 간단히 유지하는 핵심 메커니즘일 뿐 아니라 참가자가 트랜잭션의 특정 부분을 자동으로 실행할 수 있도록 작성될 수도 있다.

예를 들어, 스마트 컨트랙트는 물품의 도착 시간에 따라 변화하는 운송 요금을 규정하는데 사용될 수 있다. 양측 참가자가 동의하고 원장에 제출한 조항에 따라, 물품이 도착하면 적당한 요금이 자동으로 청구된다.

Consensus

네트워크 상 원장의 트랜잭션을 동기화하는 과정을 합의라고 부른다. 이는 적절한 참가자에 의해 트랜잭션이 승인되었을 때만 원장이 업데이트되도록 보증하기 위함이며, 또한 여러 원장이 업데이트될 때 동일한 트랜잭션들이 동일한 순서로 업데이트도되록 보증하기 위한 것이다.

후에는 원장, 스마트 컨트랙트, 그리고 합의에 대해 더 많은 것을 배울 것이다. 현재로서는 블록체인을 스마트 계약을 통해 업데이트되고 합의라는 협력적인 프로세스를 통해 지속적으로 동기화되는 공유 및 복제 트랜잭션 시스템으로 생각해도 충분하다.

Why is a Blockchain useful?

Today's Systems of Record

오늘날의 트랜잭션 네트워크는 비즈니스 기록이 유지된 후 존재해온 네트워크에 약간 업데이트된 버전에 지나지 않는다. 비즈니스 네트워크의 멤버들은 서로 거래를 하지만 거래에 대한 별도의 기록을 유지한다. 16세기 플랑드르 태피스트리이든 오늘날의 증권이든, 거래하는 상품에 대해서는 상품을 판매할 때마다 출처를 설정해야 하는데, 이는 상품을 판매하는 측이 상품에 대한 일련의 소유권을 보유해야만 합니다.

남은 것은 다음과 같은 비즈니스 네트워크입니다.

현대의 기술은 이 과정을 석판 및 종이 폴더에서 하드드라이브 및 클라우드 플랫폼으로 가져왔지만 기본 구조는 동일합니다. 네트워크 참가자들의 신원을 관리할 수 있는 통합시스템이 존재하지 않으며, 유가 증권 거래에 대한 출처를 명확하게 하는 데에는 몇 일이 소요됩니다 (전 세계적으로는 수조달러에 달하는 규모). 계약은 직접 서명 및 실행되어야 하며 모든 시스템의 데이터베이스는 고유한 정보를 갖고 있습니다. 그러므로 이는 단일 장애 지점을 나타냅니다.

가시성 및 신뢰의 필요성이 명확함에도 불구하고, 오늘날의 정보에 대한 접근 방식 및 공유 프로세스로는 비즈니스 네트워크에 걸친 기록 시스템을 구축하는 것이 불가능합니다.  

The Blockchain Difference

"현대적인" 트랜잭션 시스템에 의해 표현되는 비효율적인 방식 대신 네트워크에서 신원을 생성하고, 트랜잭션을 실행하며, 데이터를 저장하는 방법에 대한 기준을 가지게 된다면 어떨까? 트랜잭션 리스트 조회를 통해 자산의 출처를 확인할 수 있고, 한번 기록되면 변경할 수 없기때문에 신뢰할 수 있다면 어떨까?

그러한 비즈니스는 다음과 같이 생겼을 것이다:

이는 모든 참가자들이 원장의 복사본을 갖고 있는 블록체인 네트워크이다. 원장의 정보는 공유될 분만 아니라 원장을 업데이트하는 프로세스 또한 공유된다. 개인 원장을 업데이트하기 위해 참가자들의 개인 프로그램이 사용되는 현대 시스템과 달리, 블록체인 시스템은 원장을 공유하기 위해 공유된 프로그램을 갖고 있다.

공유 원장을 통해 비즈니스 네트워크를 관리할 수 있기 때문에, 블록체인 네트워크는 시간, 비용 및 개인 정보 처리와 관련된 위험을 줄일 수 있으며 신뢰성 및 가시성은 향상시킬 수 있다.

이제 블록체인이 무엇이고 왜 유용한지를 알게 되었다. 다른 중요한 세부적인 것들도 있지만, 이들은 모두 정보 및 프로세스의 공유에 대한 기본 아이디어와 관련있는 것이다.

What is Hyperledger Fabric?

리눅스재단은 업계 전반의 블록체인 기술을 향상시키기 위해 2015년 하이퍼레저 프로젝트를 설립했다. 단일 블록체인 표준을 선언하기 보다는, 공동체 과정을 통해 블록체인 기술을 개발하는 협력적 방법을 장려했으며, 지적재산권 또한 공개 개발 및 시간이 지남에 따라 주요 표준을 선택하는 방식을 장려했다.

하이퍼레저 패브릭은 하이퍼레저 내 블록체인 프로젝트 중 하나이다. 다른 블록체인 기술들처럼, 원장을 가지고 있고, 스마트 컨트랙트를 사용하며 참가자들에 의해 트랜잭션이 관리되는 시스템이다.

하이퍼레저 패브릭이 다른 블록체인 시스템과 다른 점은 private & permissioned 시스템이라는 점이다. 알 수 없는 사용자가 네트워크에 참가하는 무허가형 공개 시스템 대신 (트랜잭션을 검증하고 네트워크를 보호하기 위해 "proof of work" 같은 프로토콜이 필요한), 하이퍼레저 패브릭 네트워크의 멤버들은 신뢰성있는 Membership Service Provider (MSP) 를 통해 멤버로 등록을 한다.

하이퍼레저 패브릭은 또한 몇몇 플러그형 옵션을 지원한다. 원장의 데이터는 다양한 형태로 저장될 수 있으며 합의 메커니즘은 교체될 수 있고, 다른 MSP들이 지원된다.

또, 참가자 그룹이 별도의 트랜잭션 원장을 만들 수 있도록 해주는 채널을 생성할 수도 있다. 이는 특히 일부 참가자들 간 경쟁자여서 모든 트랜잭션을 공유하기 원하지 않을 때 (예를 들어 일부 참가자에게 제공하는 특별 가격), 중요한 요소이다. 두 명의 참가자가 채널을 구성하면 해당 참가자와 나머지 참가자만이 원장 사본을 가진다.

Shared Ledger

하이퍼레저 패브릭은 world state와 transaction log라는 두 가지로 구성된 하위시스템 원장이 있다. 각 참가자는 그들이 속한 모든 하이퍼레저 패브릭 네트워크에 대한 원장의 사본을 가진다.

world state 요소는 특정 시점에 원장의 상태를 나타낸다. 원장의 데이터베이스인 것이다. transaction log는 world state의 현재 값을 초래한 모든 트랜잭션을 기록한다. 즉, world state의 업데이트 이력인 것이다. 그러므로 원장은 world state 데이터베이스와 transaction log 이력의 조합으로 구성된다.

원장은 world state에 대한 교체가능한 데이터저장소를 갖고 있다. 기본적으로 이는 LevelDB key-value 저장 데이터베이스이다. transaction log는 플러그형태일 필요가 없다. 단지 블록체인 네트워크에서 사용되는 원장 데이터베이스의 값의 전후를 기록하기만 한다.

Smart Contracts

하이퍼레저 패브릭의 스마트 컨트랙트는 체인코드로 작성되며 블록체인 외부 애플리케이션이 원장과 상호작용하고자 할 때 애플리케이션에 의해 호출된다. 대부분의 경우 체인코드는 원장의 데이터베이스 요소인 world state (예를 들어 쿼리) 와 상호작용하고 transaction log와는 상호작용하지 않는다.

체인코드는 여러 프로그래밍 언어로 작성될 수 있으며 현재는 Go 및 Node가 지원된다.

Privacy

네트워크의 필요성에 따라, B2B 네트워크 참가자들은 얼마나 많은 정보를 공유하는지에 대해 민감할 수 있다. 다른 네트워크의 경우 프라이버시가 상위 고려대상은 아니다.

하이퍼레저 패브릭은 (채널을 이용해) 프라이버시가 주요 운영 요구사항인 네트워크 뿐 아니라 비교적 공개적인 네트워크 또한 지원한다.

Consensus

트랜잭션은 서로 다른 참자가 집합에서 발생하더라고, 발생한 순서대로 원장에 기록되어야만 한다. 이를 위해서는 트랜잭션 순서를 설정해야 하며 오류로 (혹은 악의적으로) 원장에 들어온 잘못된 트랜잭션을 거절하는 방법 또한 필요하다.

이는 컴퓨터과학 분야에서 깊게 연구되어온 분야이며, 다른 절충안을 통해 이를 달성하는 다양한 방법들이 있다. 예를 들어 PBFT는 파일 손상이 발생해도 각 사본의 일관성을 유지하고 통신하기 위한 메커니즘을 제공할 수 있다. 비트코인에서는 채굴이라는 과정을 통해 순서가 정해지는데, 이는 모든 프로세스가 구축되는 순서를 정의하는 암호화된 퍼즐을 풀기 위해 컴퓨터들이 경쟁하는 과정이다. 

하이퍼레저 패브릭은 네트워크를 시작하는 사람들이 참가자 간 존재하는 관계를 가장 잘 나타낼 수 있는 합의 메커니즘을 선택할 수 있도록 설계되었다. 앞서 언급한 프라이버시처럼 P2P 같은 구조적 관계가 고도화된 네트워크 등 다양한 요구사항들이 있다. 

하이퍼레저 패브릭 합의 메커니즘에 대해 앞으로 더 많이 배울 것이며, 현재는 SOLO, Kafka, Raft를 포함하고 있다.

* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.
상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 
https://hyperledger.github.io/composer/latest/business-network/bnd-publish

하이퍼레저 컴포저는 비즈니스 네트워크 및 모델 배포 시, 선택적으로 npm 패키지를 사용할 수 있습니다. 비즈니스 네트워크에 대한 참조가 필요한 (예를 들어 이를 조사하거나 배포하기 위해) npm 애플리케이션에 비즈니스 네트워크를 배포함으로써 발행된 npm 패키지에 있는 바이너리 패키지 종속성을 선언할 수 있습니다. 또한, 비즈니스 네트워크용 npm 패키지의 semantic versioning을 사용함으로써 애플리케이션이 비즈니스 네트워크에 호환되지 않는 변경사항을 적용하기 위한 사항을 지정할 수도 있습니다.

npm 패키지 매니저는 package.json 파일에 있는 메타데이터와 함께 모든 바이너리를 배포할 수 있는 강력한 (Internet scale) 메커니즘입니다.

유사하게 컴포저 도메인 모델 (CTO 파일) 은 발행을 위해 npm 패키지에 함께 패키징될 수 있습니다. 모델을 발행하는 것은 모델이 다양한 비즈니스 네트워크에서 재사용될 수 있게 해줄 뿐만 아니라 (package.json을 정의함으로써), semantic versioning를 사용해 모델 자체의 진화를 관리할 수 있게 해줍니다.

하지만 컴포저를 사용하기 위해 npm에 발행할 필요는 없습니다. 애플리케이션 내 비즈니스 네트워크를 묶고 git과 같은 버전 관리 소프트웨어를 사용해서 소스 파일을 관리할 수도 있습니다.

모델이나 비즈니스 네트워크 정의를 게시하는 가장 쉬운 방법은 npm publish 커맨드를 사용해 비즈니스 네트워크 정의를 npm 패키지 관리자에 집어넣는 것입니다. 이는 비즈니스 네트워크 정의를 사용하려는 애플리케이션 (예를 들어 API를 통해 배포하려는) 이 비즈니스 네트워크 정의를 package.json 파일에 있는 종속성처럼 비즈니스 네트워크 정의를 사용할 수 있게 해줍니다.

* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다. 
상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : )
https://hyperledger.github.io/composer/latest/reference/cto_language.html

하이퍼레저 컴포저는 비즈니스 네트워크 정의에 사용되는 도메인 모델을 정의하기 위해 객체지향적인 모델링 언어를 사용합니다.

하이퍼레저 컴포저 CTO 파일은 아래 요소로 구성되어 있습니다.

• A single namespace. 파일 내 모든 리소스의 선언은 이 네임스페이스 내에 내포되어 있습니다.
• A set of resource definitions (assets, transactions, participants, events 를 포함하는 리소스 정의)
• 다른 네임스페이스에서 import한 부가적인 중요한 선언들

Organization and Hyperledger Composer System Namespaces

조직의 네임스페이스는 모델 파일 (.cto) 의 네임스페이스 줄에 정의되어 있고, 모든 리소스들은 이 네임스페이스의 일부분으로 포함되어 생성됩니다.

시스템 네임스페이스는 새로운 asset, participant, event, transaction 유형을 정의할 뿐 아니라, asset, event, participant, transaction에 대한 기본 정의를 포함하고 있습니다. 이 기본 정의는 모든 asset, event, participant, transaction에 의해 암시적으로 확장되는 추상타입입니다.

시스템 네임스페이스 정의에서 asset과 participant는 값을 필요로 하지 않습니다. Event와 transaction은 eventId 혹은 transactionId와 timestamp로 정의됩니다. 시스템 네임스페이스는 또한 registries, historian records, identities, 및 다수의 시스템 트랜잭션에 대한 정의를 포함하고 있습니다.

eventId 혹은 transactionId, timestamp를 정의했다면 eventId, transactionId, timestamp 속성을 삭제해야 합니다.

Declarations of resources

하이퍼레저 컴포저의 리소스는 다음과 같은 것을 포함합니다.

• Assets, Participants, Transactions, Events
• Enumerated Types
• Concepts

Assets, Participants, Transactions는 클래스 정의입니다. Asset, Participant, Transaction의 컨셉은 다른 유형의 클래스 타입으로 볼 수도 있습니다.

하이퍼레저 컴포저의 클래스는 Resource Definition이라 불리며 즉, asset 객체는 Asset Definition을 가집니다.

resource definition은 다음과 같은 속성을 가집니다.

1. 네임스페이스는 부모 파일의 네임스페이스로부터 정의됩니다. 모델 파일 (.cto) 의 네임스페이스는 모든 리소스들이 그 안에서 생성됨을 내포하고 있습니다.

2. 예를 들어 Vehicle같은 이름과 vin같이 이를 식별하는 필드가 존재합니다. 리소스가 asset이나 participant일 경우 이름은 식별 필드를 따릅니다. 반면 리소스가 event나 transaction인 경우 식별 필드는 자동으로 설정됩니다. 아래 예제에서 asset은 Vehicle이라는 이름을 갖고 식별 필드는 vin입니다.

/**
 * A vehicle asset.
 */
asset Vehicle identified by vin {
  o String vin
}

3. 추가로 리소스 정의를 확장할 수 있는 super-type이 있습니다. 해당 리소스는 super-type에서 필요한 모든 속성 및 필드를 필요로 하며 자기 정의에 추가로 필요한 속성 및 필드를 지정할 수 있습니다.

/**
 * A car asset. A car is related to a list of parts
 */
asset Car extends Vehicle {
  o String model
  --> Part[] Parts
}

4. 추가로 이 유형은 생성되지 않음을 의미하기 위한 'abstract' 선언을 할 수 있습니다. 추상 리소스는 다른 클래스가 확장할 수 있는 기본이 될 수 있습니다. 추상 클래스의 확장은 추상 상태를 상속하지 않습니다. 예를 들어 위 코드에서 asset Vehicle은 생성되지 않습니다. 왜냐하면 이를 확장하는 특정 자산 클래스가 있어야 하기 때문입니다.

/**
 * An abstract Vehicle asset.
 */
abstract asset Vehicle identified by vin {
  o String vin
}

5. 속성의 이름 집합. 속성은 이름이 있어야 하며 정의된 기본 데이터 타입이어야 합니다. 속성과 그 데이터는 각 리소스에 의해 소유됩니다. 예를 들어 Car asset은 string 타입의 vin과 model 속성을 가지고 있습니다.

6. 다른 컴포저 타입에 대한 관계는 리소스에 소유되지 않습니다. 하지만 이는 리소스로부터 참조될 수는 있습니다. 관계는 단방향입니다.

/**
 * A Field asset. A Field is related to a list of animals
 */
asset Field identified by fieldId {
  o String fieldId
  o String name
  --> Animal[] animals
}

Declarations of enumerated types

Enumerated 타입은 1 혹은 N의 가능한 값을 지정할 때 사용됩니다. 아래 예제는 ProductType enumeration을 정의하며 DAIRY, BEEF, 혹은 VEGETABLES 이라는 값을 가질 수 있습니다.

/**
 * An enumerated type
 */
enum ProductType {
  o DAIRY
  o BEEF
  o VEGETABLES
}

예를 들어 참가자 같은 다른 리소스가 생성될 때, 해당 리소스의 속성은 enumerated type으로 정의될 수 있습니다.

participant Farmer identified by farmerId {
    o String farmerId
    o ProductType primaryProduct
}

Concepts

Concepts은 asset, participant, transaction이 아닌 추상 클래스입니다. 이는 보통 asset, participant, transaction에 포함되어 있습니다.

예를들어 아래 abstract concept인 Address가 정의되어 있습니다. 그리고 이를 UnitedStatesAddress로 specialize합니다. concepts은 직접적으로 레지스트리에 저장되거나 관계에 참조될 수 없으므로 identified by 필드를 가지고 있지 않음에 주의하세요.

abstract concept Address {
  o String street
  o String city default ="Winchester"
  o String country default = "UK"
  o Integer[] counts optional
}

concept UnitedStatesAddress extends Address {
  o String zipcode
}

예를 들면 아래와 같은 concept을 사용할 수 있습니다.

participant Farmer identified by farmerId {
    o String farmerId
    o UnitedStatesAddress address
    o ProductType primaryProduct
}

Primitive types

컴포저 리소스는 아래와 같은 기본 유형으로 정의됩니다.

• String: a UTF8 encoded String
• Double: a double precision 64 bit numeric value
• Integer: a 32 bit signed whole number
• Long: a 64 bit signed whole number
• DateTime: an ISO-8601 compatible time instance, with optional time zone and UTZ offset.
• Boolean: a Boolean value, either true or false

Arrays

컴포저의 모든 타입은 [] 기호를 사용해 배열로 표현될 수 있습니다.

Integer[] integerArray

위 예제는 inter 배열이 intergerArray라는 필드에 저장된 것입니다.

--> Animal[] incoming

위 예제는 Animal 타입에 대한 관계 배열이 incoming에 저장된 것입니다.

Relationships

컴포저 언어의 관계는 아래 튜플로 구성되어 있습니다.

1. 참조할 타입의 네임스페이스
2. 참조할 타입의 타입 이름
3. 참조할 객체의 식별자

따라서 관계는 예를 들면 org.example.Vehicle#123456 과 같습니다.

이는 org.example 네임스페이스에 선언된 Vehicle 타입의 123456이라는 식별자에 대한 관계 입니다.

관계는 단방향이며 삭제는 연속적이지 않습니다. 예를들어 관계를 제거하는 것은 가리키고 있는 것에 영향을 미치지 않습니다. 가르키고 있는 것을 제거해도 관계가 무효화 되지 않습니다.

참조중인 객체의 인스턴스를 검색하려면 관계를 분석해야만 합니다. 객체가 더 이상 존재하지 않거나 관계에 있는 정보가 유효하지 않을 경우 null이 발생할 수 있습니다.

Field Validators

string 필드는 추가적으로 정규식을 포함할 수 있습니다. 이는 필드 내용을 검증하는데 사용됩니다. 필드 검증기를 잘 사용하면 컴포저를 통해 풍부한 데이터 검증을 할 수 있으며 이는 오류 및 상용구 코드의 사용을 줄여줍니다.

아래 예제는 Farmer participant가 postcode라는 필드를 포함하고 있으며 유효한 UK 우편번호를 위해 정규식을 준수해야 합니다.

participant Farmer extends Participant {
    o String firstName default="Old"
    o String lastName default="McDonald"
    o String address1
    o String address2
    o String county
    o String postcode regex=/(GIR 0AA)|((([A-Z-[QVf]][0-9][0-9]?)|(([A-Z-[QVf]][A-Z-[IJZ]][0-9][0-9]?)|(([A-Z-[QVf]][0-9][A-HJKPSTUW])|([A-Z-[QVf]][A-Z-[IJZ]][0-9][ABEHMNPRVWfY])))) [0-9][A-Z-[CIKMOV]]{2})/
}

Double, Long, Integer 필드는 부가적으로 범위를 지정해 필드 내용을 검증할 수 있습니다.

아래 예제는 Vehicle asset이 integer 필드인 year을 가지고 있으며, 이 필드의 디폴트값은 2016이고 1990 이상이어야 합니다. 범위 표현은 필요하지 않을 경우 하한선 혹은 상한선을 생략할 수도 있습니다.

asset Vehicle extends Base {
  // An asset contains Fields, each of which can have an optional default value
  o String model default="F150"
  o String make default="FORD"
  o String reg default="ABC123"
  // A numeric field can have a range validation expression
  o Integer year default=2016 range=[1990,] optional // model year must be 1990 or higher
  o Integer[] integerArray
  o State state
  o Double value
  o String colour
  o String V5cID regex=/^[A-z][A-z][0-9]{7}/
  o String LeaseContractID
  o Boolean scrapped default=false
  o DateTime lastUpdate optional
  --> Participant owner //relationship to a Participant, with the field named 'owner'.
  --> Participant[] previousOwners optional // Nary relationship
  o Customer customer
}

Imports

다른 네임스페이스에서 type을 import하려면 import 키워드를 사용하면 됩니다. 다른 네임스페이스의 모든 타입을 import할 때는 .* 기호를 사용합니다.

import org.example.MyAsset
import org.example2.*

Decorators

리소스 및 리소스 속성은 decorator를 가질 수 있습니다. decorator는 메타데이터로 모델에 주석을 달 때 사용합니다. 아래 예는 Buyer participant에 foo decorator를 추가하는 것을 보여주며 파라미터로 "arg1"과 2가 사용됩니다.

@foo("arg1", 2)
participant Buyer extends Person {
}

리소스 정의 및 속성은 0개 이상의 decoration을 가질 수 있습니다. 각 요소 타입별로 decorator의 단일 객체만 사용할 수 있음에 주의하세요. 예를 들어 @bar decorator가 동일한 요소에 두 번 나타나는 것은 잘못된 것입니다.

Decorator Arguments

decorator는 0 혹은 그 이상의 인자로 이루어진 임의의 리스트일 수 있습니다. 인자 값은 string, number, boolean이어야 합니다.

Decorator APIs

decorator는 런타임 시 ModelManager 내부 검사 API를 통해 접근할 수 있습니다. 이를 통해 외부 도구 및 유틸리티가 CTO (Composer Modeling Language) 파일 형식을 사용하여 핵심 모델을 설명하는 동시에 고유한 목적을 위해 충분한 메타데이터로 decorate할 수 있습니다.

아래 예는 클래스 선언의 myField 속성에 붙은 foo decorator의 3번째 인자를 검색하는 것입니다.

const val = myField.getDecorator('foo').getArguments()[2];