HYPERLEDGER FABRIC - Developing Applications - Process and Data Design

HYPERLEDGER FABRIC

  ㄴ Developing Applications

    ㄴ Process and Data Design

 

독자 : Architects, Application and smart contract developers, Business professionals

 

이번 topic은 기업 어음 프로세스와 PaperNet안에서 그들과 관련된 data structure를 설계하는 방법을 보여줍니다.

Analysis는 무슨 일이 일어나고 있는지 이해하기 위해 정확한 방법을 제공하는 transactions과 states를 사용하는 모델링된 PaperNet을 강조했습니다.

이제 PaperNet의 applications과 smart contracts의 설계를 돕기 위해, 크게 관련된 두가지 개념에 대해 자세히 설명하겠습니다.

 

Lifecycle

지금까지 살펴본 것처럼, 기업 어음을 다룰 때 우리에게 영향을 미치는 두 가지 중요한 개념인 states와 transactions이 있습니다.

실제 모든 블록체인 사용 사례입니다.

state로 모델링된 개념적 가치 객체가 있으며, 생명주기 전환은 transactions에 의해 설명됩니다.

states와 transactions를 효과적으로 분석하는 것은 성공적인 구현을 위한 필수 시작점입니다.

 

우리는 상태(state) 전환 다이어그램을 사용하여 기업 어음의 생명주기를 나타낼 수 있습니다.

기업 어음의 상태 전환 다이어그램입니다. 기업 어음은 issue, buy, redeem 트랜잭션에 의해 issued, trading, redeemed 상태 사이에서 전환됩니다.

 

어떻게 기업 어음이 시간이 지남에 따라 변하는지 설명하는 상태 다이어그램과 특정 transaction(트랜잭션)이 생명주기 전환을 어떻게 제어하는지 봅시다.

Hyperledger Fabric에서 smart contract은 그들의 다른 state와 기업 어음을 사이에서 전환하는 트랜잭션 로직을 구현합니다.

기업 어음 state는 실제로 원장 world state안에 있습니다. 그럼 좀 더 자세히 살펴봅시다.

 

Ledger state

기업어음의 구조를 생각해봅시다.

기업 어음은 각각 값이 있는 속성의 set으로 나타낼 수 있습니다. 일반적으로, 이런 속성의 조합 중 일부는 각각 어음의 고유한 key를 제공합니다.

 

기업 어음 paper 속성 값이 00001 그리고 Face value 속성 값이 5M USD를 갖는 것을 보세요.

가장 중요한 것은 Current state 속성 값이 기업 어음이 issued인지 trading인지 redeemed인지를 나타낸다는 것입니다.

조합 안에서, 전체 속성(properties)의 모든 집합은 기업 어음의 상태(state)를 구성합니다.

게다가, 이러한 개별 기업 어음 state의 전체 집합은 원장 world state을 구성합니다.

 

모든 원장 state는 다른 값을 가진 각각의 속성 set와 위 양식을 공유합니다.

이러한 multi-property(다중 속성)은 state 측면에서 강력한 기능입니다.

그것은 Fabric state를 단순한 스칼라가 아닌 벡터로 생각하게 합니다.

우리는 개별적인 state로 전체 객체에 대한 사실을 나타내며, 이후 트랜잭션 로직에 의해 state가 전환된다.

Fabric state는 key/value 쌍으로 구현되며, value는 객체의 여러 속성을 담아낸 형식으로 객체 속성을 인코딩한다. (일반적으로 JSON형식)

원장 database(ledger database)는 그들의 속성에 대비하여 고급 쿼리 작업을 지원할 수 있고, 복잡한 객체 검색에 매우 도움이 될 것입니다.

 

MagnetoCorp의 어음 00001이 다른 transaction에 따라 변화하는 state 벡터로 어떻게 표현되는지 확인해보세요.

기업 어음 state는 다른 거래의 결과로서 존재하고 전환됩니다. Hyperledger Fabric states는 스칼라가 아닌 벡터로 만들어진 다중 속성을 가지고 있습니다.

 

개별 어음은 빈 state로 시작하며, nil state라고 부르고, 존재하지 않음을 의미합니다.

어음 00001이 issue 트랜잭션에 의해 어떻게 존재하는지, 나중에 buy와 redeem 트랜잭션의 결과에 의해 어떻게 update되는지 확인하세요.

 

각각의 state가 가지고 있는 이름과 속성으로 스스로를 어떻게 설명하는지 확인해보세요.

비록 우리의 모든 기업 어음은 현재 같은 속성을 가지고 있지만, Hyperledger Fabric은 다른 속성을 가진 다른 state를 지원하므로 언제나 이런 것은 아닙니다.

같은 원장 world state는 asset의 다른 유형뿐만 아니라 같은 asset의 다른 유형도 포함할 수 있습니다.

또한, state의 구조를 업데이트할 수 있습니다.

추가의 data 필드가 필요한 새로운 규정을 상상해보세요.

유연한 state 속성은 시간이 지남에 따라 data 확장의 기본 요구사항을 지원합니다.

 

State keys

대부분 실제 applications에서 state는 주어진 context에서 그것을 고유하게 식별할 수 있는 속성의 조합인 key를 가지고 있습니다.

PaperNet 기업 어음을 위한 key는 Issuer과 paper 속성으로 의해 구성됩니다.

따라서, MagnetoCorp의 첫번재 어음은 MagnetoCorp00001입니다.

 

state key는 issue 트랜잭션의 결과로 만들어지고, buy와 redeem에 의해 나중에 업데이트되는 어음을 고유하게 식별할 수 있습니다.

Hyperledger Fabric은 원장의 각 state에 고유한 key가 필요합니다.

 

속성 집합에서 사용할 만한 고유 key가 없을 때, application에서 결정한 고유 키는 state를 만드는 트랜잭션에 입력으로 지정됩니다.

이 고유 key는 일반적으로 읽을 수는 없지만 표준 방식인 UUID 형식입니다.

원장 안에 있는 모든 개별 state 객체는 반드시 고유 key가 있어야합니다.

 

Note : key에 U+0000(nil byte)를 사용하지 않아야합니다.

 

Multiple states

PaperNet의 기업 어음은 원장에 state 벡터로 저장되어있다는 것을 살펴봤습니다.

원장에서 각각 다른 기업 어음을 조회할 수 있는 합리적인 필요조건입니다.

예를 들어, MagnetoCorp에 의해 issued된 모든 어음을 찾거나, 거기서 redeemed state인 모든 어음을 찾을 수 있습니다.

 

이러한 종류의 검색 작업을 가능하게 하기 위해, 모든 관련된 문서를 논리적인 목록으로 그룹화하는 것이 좋습니다.

PaperNet의 설계는 기업 어음 목록 개념을 포함하고, 기업 어음이 issued 또는 변경될 때마다 논리적 컨테이너는 업데이트됩니다.

 

- Logical representation

모든 PaperNet 기업 어음이 하나의 기업 어음 목록(commercial paper list)에 있다고 생각하면 도움이 될 것입니다.

MagnetoCorp에서 새로 생성한 기업 어음 00004는 이미 존재하는 기업 어음 리스트에 추가됩니다.

 

새로운 어음은 issue 트랜잭션의 결과로서 list에 추가될 수 있으며, 이미 리스트에 있는 어음은 buy와 redeem 트랜잭션에 의해 업데이트될 수 있습니다.

어떻게 list는 기술적인 이름을 가지고 있는지 확인해봅시다.

org.papernet.papers : 잘 선택된 이름은 당신의 블록체인 설계를 다른 사람에게 직관적으로 만들 수 있기 때문에, DNS 이름의 종류를 사용하는 것은 매우 좋은 생각입니다.

이 아이디어는 smart contract 이름에도 동일하게 적용됩니다.

 

- Physical representation

PaperNet안에 단일 어음 리스트를 생각하는 것은 옳지만, org.papernet.papers , list는 개별 Fabric states 집합으로서 가장 잘 구현되며, 조합 key는 state를 목록과 연결합니다. 

이러한 방식으로, 각각의 state의 조합 key는 고유하고 효과적인 list query를 지원합니다.

 

다른 Hyperledger Fabric states의 집합으로서 PaperNet 기업 어음의 list를 표현한 것

 

리스트의 각각 어음은 org.papernet.paper, Issuer, Paper 속성의 연속에 의해 만들어진 고유한 조합 key인 벡터 state에 의해 표현됩니다.

이 구조는 두가지 이유로 유용합니다.

• 별도의 목록을 참조하지 않고, 원장 안에 모든 state 벡터를 조사하여 어떤 목록에 있는지 확인할 수 있습니다. 스포츠 팬들을 보며, 그들의 티셔트 색상으로 응원하는 팀을 식별하는 것과 유사합니다. 스포츠 팬들은 팬 목록이 필요하지 않고, 그들이 지지하는 바를를 티셔츠를 통해 스스로 보여줍니다.
• Hyperledger Fabric은 원장을 update하기 위해 내부적으로 동시성 제어 메커니즘을 사용하므로, 별도 state 벡터에 원장을 보관하면 공유된 state 충돌의 가능성이 대단히 줄어듭니다. 이러한 충돌은 트랜잭션을 다시 제출하게 하고, application 설계를 더 복잡하게 만들고, 성능을 저하시킵니다.

state 벡터의 물리적인 설계는 매우 최고의 성능과 동작에 매우 중요하다는 두번째 요점은 Hyperledger Fabric의 핵심 사항입니다.

state 분리를 유지하세요!

 

Trust relationships

다른 비즈니스 이해관계뿐만 아니라 issuer, trader, 평가 기관과 같은 네트워크 안의 다른 역할이 트랜잭션에 승인을 해야 하는 사람을 결정하는 방법에 대해 논의했습니다.

Fabric안에서 이러한 룰은 보증 정책(Endorsement policies)으로 불립니다.

이런 규칙은 개별적인 state key뿐만 아니라 체인코드의 단위로 설정할 수 있습니다.

 

PaperNet에서 조직이 새로운 어음을 발행할 수 있는지를 결정하는 하나의 규칙을 namespace에 설정할 수 있음을 의미합니다.

나중에 buy, redeem 트랜잭션의 신뢰 관계를 포착하기 위한 개별적인 어음을 위해 규칙을 업데이트하고 설정할 수 있다.

 

다음 주제에서는 PaperNet 기업 어음의 smart contract를 구현하기 위해 어떻게 디자인 컨셉을 결합해야하는지, 그리고 application이 그것을 활용하는 것을 보여줄 것입니다.

 

 

 

출처 ]

https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/architecture.html#