라리월드

*  본 포스팅은 하이퍼레저 패브릭 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];

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

하이퍼레저 컴포저는 세가지 유형의 테스팅을 지원한다. 반응형테스트, 자동화된 단위 테스트, 자동화된 시스템 테스트이다. 이 세가지는 모두 다른 목적을 가지고 있으며 블록체인 프로젝트의 성공을 보증하기 위한 필수요소이다.

비즈니스 네트워크 정의를 배포하고 나면 종종 배포가 올바르게 되었는지 확인하기 위해 반응형 "smoke test"를 하는 것이 유용하다. composer CLI는 이런 smoke test를 하는 몇몇 커맨드를 갖고 있다.

또 Docker Compose와 Mocha/Chai를 사용해 full-blown 시스템 테스트를 할 수도 있다. 이는 런타임을 시작하며 비즈니스 네트워크 정의를 배포하고 프로그래밍적으로 asset을 생성하고 transaction을 제출해 asset registry들의 상태를 조사한다.

단위테스트는 트랜잭션이 처리될 때 world-state에 대한 변화가 올바르게 이뤄지는지에 초점을 두고 있다.

단위테스트와 시스템테스트 모두 Jenkins, TravisCI, Circle CI 등과 같은 CI/CD build pipeline을 통해 자동화되어있다.

Interactive Testing

플레이그라운드를 사용해 참가자, 자산 생성 및 트랜잭션 제출을 반응형으로 테스트할 수 있다.

Testing from the Command Line

커맨드라인은 런타임 상태를 확인하고 트랜잭션을 제출하는데 사용할 수 있다. composer network list 커맨드를 사용해 asset과 participant registries의 상태를 볼 수 있고, composer transaction submit 커맨드를 통해 트랜잭션을 제출할 수 있다.

Creating Unit Tests

트랜잭션 처리 함수에 있는 비즈니스 로직은 100% 코드 커버리지에 속하기 때문에 단위 테스트를 해야만 한다. 이를 통해 비즈니스 로직 내 오타나 로직 오류가 없는지를 확인할 수 있다.

트랜잭션 처리 함수 내 비즈니스 로직에 대한 단위 테스트를 수행하기 위해 Mocha, Chai, Sinon, Istanbul 같은 JavaScript 테스팅 라이브러리를 사용할 수도 있다.

embedded 런타임은 단위 테스트에 매우 유용하다. 이는 하이퍼레저 패브릭을 켜지 않고 시뮬레이팅한 Node.js 블록체인 환경에서 비즈니스 로직을 빠르게 테스트할 수 있다.

단위 테스트용 샘플 네트워크는 아래를 참조

https://github.com/hyperledger/composer-sample-networks/blob/master/packages/bond-network/test/Bond.js

오랜만에 맘스터치를 방문했습니다.
언빌리버블버거 & 인크레더블 버거로 인기가 핫한 맘스터치!

오늘의 선택은 딥치즈버거 & 치킨커틀렛 버거

 딥치즈버거는 닭가슴살패티에 치즈가 추가되어
딥~한 맛을 즐길 수 있는(?) 버거입니다.

가격은
단품 4,000원 / 세트 6,000원 

영양성분
* (1일 영양소 기준치에 대한 비율)

※ 1회 제공량 : 220 g
※ 칼로리 : 409 kcal
※ 나트륨 : 737(37) mg
※ 당류 : 3 g
※ 포화지방 : 5(33) g
※ 단백질 : 28(51) g

사실 햄버거가 다 그렇듯 칼로리는 어마어마하지만
맛있으니까요ㅋㅋㅋㅋ

포장을 뜯으면 위와 같은 모습입니다.
닭가슴살의 뜨끈뜨끈한 온기에
치즈가 촉촉하게 흘러내려요~

맛은 맘스터치는 뭘 시켜도 기본은 보장되어 있으니까요.
개인적으로는 음.......사실
싸이버거가 더 맛있었어요>_< 
약~간....아주 약....간 느끼했습니다ㅠㅠ
목이 메였어요.

같이 간 친구는 치킨커틀렛버거를 주문했습니다.

통 가슴살 패티에 새콤달콤 커틀렛 소스와
아삭아삭 양배추채가 들어간 버거라고 하네요.

가격은 
단품 3,200원 / 세트 5,400원 

영양성분
* (1일 영양소 기준치에 대한 비율)

※ 1회 제공량 : 210 g
※ 칼로리 : 469 kcal
※ 나트륨 : 804(40) mg
※ 당류 : 8 g
※ 포화지방 : 4(27) g
※ 단백질 : 30(55) g

딥치즈버거보다 칼로리가 살~짝 높습니다.

포장을 뜯으니 아삭아삭 양배추채와
새콤달콤한 커틀렛 소스가 흘러나오고 있어요.

보너스로 맘스터치 하면 빠질 수 없는
감자튀김

* (오늘의 느낀점)

맘스터치는 맛있다. 신메뉴도 물론.
근데 싸이버거가 최강자인데는 이유가 있는듯(?)

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

이벤트는 하이퍼레저 컴포저에 의해 발생할 수 있으며 외부 애플리케이션에 의해 구독될 수 있다. 이벤트는 비즈니스 네트워크 정의의 모델 파일에 정의되어 있고, 트랜잭션 처리 함수의 자바스크립트로 된 트랜잭션에 의해 발생한다. 이벤트를 발생시키는 코드는 트랜잭션 처리 함수 내부에 있지만, 이 코드가 실행될 때 이벤트가 발생되지는 않음에 주의하라. 대신에 이벤트는 트랜잭션이 커밋될 때마다 발생한다.

Before you begin

비즈니스 네트워크에 이벤트를 추가하기 전에 비즈니스 네트워크의 모델링 언어에 대한 이해도가 있어야 하며, 완전한 비즈니스 네트워크 정의를 구성하는 요소에 대해 알고 있어야 한다.

Procedure

1. 이벤트는 비즈니스 네트워크 정의의 모델 파일 (.cto) 에 정의되어 있고 asset과 participant도 동일하게 여기 있다. 이벤트는 다음 형태를 따른다.

event BasicEvent {
}

2. 이벤트가 발생하려면 이벤트를 생성하는 트랜잭션이 3개의 함수를 호출해야 한다. 첫 번재 함수는 getFactory 함수이다. getFactory함수는 이벤트가 트랜잭션의 일부로 생성되게 한다. 다음으로 이벤트는 factory.newEvent('org.namespace', 'BasicEvent') 를 사용해 생성되어야 한다. 이는 네임스페이스에 정의된 BasicEvent를 생성한다. 그리고나서 이벤트 요구속성들이 셋팅되어야 한다. 마지막으로 이벤트는 emit(BasicEvent)를 통해 발생한다. 이벤트를 호출하는 간단한 트랜잭션은 다음과 같다.

/**
 * @param {org.namespace.BasicEventTransaction} basicEventTransaction
 * @transaction
 */
async function basicEventTransaction(basicEventTransaction) {
    let factory = getFactory();

    let basicEvent = factory.newEvent('org.namespace', 'BasicEvent');
    emit(basicEvent);
}

이 트랜잭션은 비즈니스 네트워크 모델 파일에 정의된 BasicEvent 타입의 이벤트를 생성하고 발생시킨다. getFactory 함수에 대한 더 자세한 정보는 아래 링크를 참고하시오.

https://hyperledger.github.io/composer/latest/jsdoc/module-composer-runtime.html#getFactory

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

비즈니스 네트워크 정의는 배포되기 전에 비즈니스 네트워크 아카이브 (.bna) 파일로 패키징되어야 합니다. composer archive create 커맨드는 디스크에 있는 비즈니스 네트워크 정의 폴더에서 비즈니스 네트워크 아카이브 파일을 생성하느데 사용됩니다.

비즈니스 네트워크 아카이브 파일이 생성되면 composer network start 커맨드 이후 composer network install 커맨드를 통해 하이퍼레저 패브릭에 배포할 수 있습니다.

예를 들면 아래와 같습니다.

composer network install --archiveFile tutorial-network@1.0.0.bna --card PeerAdmin@fabric-network
composer network start --networkName tutorial-network --networkVersion 1.0.0 --card PeerAdmin@fabric-network --networkAdmin admin --networkAdminEnrollSecret adminpw

이미 배포된 비즈니스 네트워크에 비즈니스 네트워크 정의를 업그레이드하려면 composer network upgrade CLI 커맨드를 사용합니다.

Deploying business networks to Hyperledger Fabric v1.2

하이퍼레저 패브릭 v1.2에서 피어는 관리자와 멤버 컨셉을 사용합니다. 관리자는 새로운 비즈니스 네트워크를 위한 하이퍼레저 패브릭 체인코드를 피어들에게 설치할 수 있는 권한을 가집니다. 멤버들은 체인코드를 설치할 권한이 없습니다. 피어들에게 비즈니스 네트워크를 배포하기 위해서는 모든 피어에 대한 관리 권한이 있는 identity를 제공해야 합니다.

이런 identity를 만들고 certificates를 사용가능하게 하려면 피어 관리자 신원과 관련된 certificate와 private key를 사용해 피어 관리자 비즈니스 네트워크 카드를 생성해야 합니다. 하이퍼레저 컴포저는 샘플 하이퍼레저 패브릭 v1.2 네트워크를 제공합니다. 이 네트워크의 피어 관리자는 PeerAdmin이라 불리며 이 관리자의 신원은 네트워크를 시작하기 위해 샘플 스크립트를 사용할 때 자동으로 import됩니다. 다른 하이퍼레저 패브릭 네트워크에서는 피어 관리자가 다른 이름을 가질 수도 있음에 주의하세요.

중요: 비즈니스 네트워크를 하이퍼레저 패브릭 v1.2에 배포할 때, bootstrap registrar는 하이퍼레저 패브릭 Certificate Authority (CA) 환경설정에 정의되어 있습니다. 하이퍼레저 컴포저 개발환경은 bootstrap registrar의 등록 ID와 secret으로 미리 설정된 하이퍼레저 패브릭 객체를 포함하고 있습니다.

Business network administrators

비즈니스 네트워크를 배포할 때, 접근 제어는 비즈니스 네트워크 정의에 명시된 접근 제어 규칙마다 이루어집니다. 각 비즈니스 네트워크는 적어도 한 명의 참가자를 보유해야 합니다. 그리고 그 참가자는 비즈니스 네트워크에 접속할 수 있는 유효한 신원을 갖고 있어야 합니다. 그렇지 않으면 클라이언트 애플리케이션은 비즈니스 네트워크와 상호작용할 수 없습니다.

비즈니스 네트워크 관리자는 비즈니스 네트워크 배포 후에 해당 조직의 비즈니스 네트워크 구성을 설정하는 역할을 하는 참가자입니다. 또한 해당 조직의 다른 참가자들을 참여시키는 역할도 합니다. 비즈니스 네트워크는 여러 조직을 포함하기 때문에 주어진 비즈니스 네트워크용 다수의 비즈니스 네트워크 관리자가 있어야합니다.

내장된 참가자 유형인 org.hyperledger.composer.system.NetworkAdmin은 하이퍼레저 컴포저가 제공하는 비즈니스 네트워크 관리자를 나타냅니다. 이 내장된 참가자 유형은 특별한 권한을 갖고 있지 않습니다. 그냥 비즈니스 네트워크 정의에 명시된 접근 제어 규칙의 주체입니다. 그렇기 때문에 아래 접근 제어 규칙 샘플을 통해 비즈니스 네트워크 관리자에게 비즈니스 네트워크에 접근할 수 있는 모든 권한을 부여하는 것을 추천합니다.

rule NetworkAdminUser {
    description: "Grant business network administrators full access to user resources"
    participant: "org.hyperledger.composer.system.NetworkAdmin"
    operation: ALL
    resource: "**"
    action: ALLOW
}

rule NetworkAdminSystem {
    description: "Grant business network administrators full access to system resources"
    participant: "org.hyperledger.composer.system.NetworkAdmin"
    operation: ALL
    resource: "org.hyperledger.composer.system.**"
    action: ALLOW
}

기본적으로, 하이퍼레저 컴포저는 자동으로 배포중에 한 명의 비즈니스 네트워크 관리자인 참가자를 생성합니다. 이 신원은 비즈니스 네트워크를 배포하는데 사용되며 비즈니스 네트워크 관리자인 참가자와 바인딩되어 있습니다. 그래서 이 신원은 배포 후 비즈니스 네트워크와 상호작용하는데 사용됩니다.

하이퍼레저 패브릭 피어 관리자는 하이퍼레저 CA를 사용해 새로운 신원을 발생하는 권한을 갖고 있지 않을 것입니다. 이는 비즈니스 네트워크 관리자가 조직에 다른 참가자들을 참여시키는 능력을 제한합니다. 이러한 이유로 하이퍼레저 패브릭 CA를 사용해 새로운 신원을 발급할 수 있는 권한을 가진 비즈니스 네트워크 관리자를 생성하는 것을 선호합니다.

composer network start커맨드에 추가 옵션을 사용해 비즈니스 네트워크 배포 중에 생성되는 비즈니스 네트워크 관리자를 명시할 수 있습니다. 

비즈니스 네트워크 관리자가 등록된 ID와 secret을 갖고 있다면 -A (비즈니스 네트워크 관리자)와 -S (비즈니스 네트워크 관리자가 사용하는 secret) 플래그를 사용할 수 있습니다. 예를 들어 아래 커맨드는 기존 admin ID의 비즈니스 네트워크 관리자를 생성하는 커맨드입니다.

composer network start --networkName tutorial-network --networkVersion 1.0.0 --c PeerAdmin@fabric-network -A admin -S adminpw

Deploying business networks using Playground locally

주의: 비즈니스 네트워크를 하이퍼레저 패브릭 v1.2에 배포하기위해 로컬 플레이그라운드 객체를 사용할때, 배포 과정의 일부분으로 초기 비즈니스 네트워크 참가자용 credentials을 어떻게 제공할지 선택해야 합니다. 초기 참가자는 NetworkAdmin이 될 것입니다.

플레이그라운드를 사용해 비즈니스 네트워크를 배포할 때, 초기 참가자를 위한 credentials를 입력할 것입니다. credentials는 certificate로 제공되거나 이미 정의된 ID, secret으로 사용할 수 있습니다. 하이퍼레저 컴포저 개발환경에 셋팅된 하이퍼레저 패브릭 객체를 사용한다면, bootstrap registrar ID는 admin이고 secret은 adminpw입니다. 이 초기 참가자는 하이퍼레저 패브릭 CA에 있는 bootstrap registrar용으로 설정된 credentials를 사용하며 이는 NetworkAdmin이 될 것입니다.

로컬에서 플레이그라운드를 사용해 비즈니스 네트워크를 배포할 때, 적어도 하나의 비즈니스 네트워크 카드는 PeerAdmin 역할을 해야 하며 또 하나는 ChannelAdmin 역할을 해야 합니다. 이 비즈니스 네트워크 카드는 각각 올바른 admin certificates를 갖고 있어야 합니다.