HYPERLEDGER FABRIC
ㄴ Developing Applications
ㄴ Application design elements
ㄴ Chaincode namespace
독자 : Architects, application and smart contract developers, administrators
체인코드 namespace를 사용하면 다른 체인코드로부터 해당 체인코드의 world state 분리를 유지할 수 있습니다.
특히, 같은 체인코드안에 있는 스마트 계약은 동일한 world state에 직접 접근하는 것을 공유하는 반면 다른 체인코드안에 있는 스마트 계약은 서로 다른 world state에 직접 접근할 수 없습니다.
만약 스마트 계약이 또 다른 체인코드 world state에 접근해야 한다면, 체인코드 대 체인코드 호출을 수행하여 이를 할 수 있습니다.
마지막으로 블록체인은 다른 world state와 관련된 트랜잭션을 포함할 수 있습니다.
이번 주제에서는 아래의 내용들을 다룹니다.
- The importance of namespaces
- What is a chaincode namespace
- Channels and namespaces
- How to use chaincode namespaces
- How to access world states across smart contracts
- Design considerations for chaincode namespaces
Motivation (The importance of namespaces)
namespace는 일반적인 개념입니다.
우리는 Park Street, New York and Park Street, Seattle이 비록 같은 이름을 가지고 있지만 서로 다른 거리라는 것을 이해하고 있습니다.
도시는 Park Street의 namespace을 형성하며, 동시에 자유와 명확성을 제공합니다.
컴퓨터 시스템에서도 마찬가지입니다. namespace를 사용하면 서로 다른 사용자가 공유 시스템의 다른 부분을 서로 방해하지 않고 프로그래밍하고 동작할 수 있습니다.
많은 프로그래밍 언어는 namespace를 가지고 있으므로 같은 일을 하는 다른 프로그램을 걱정하지 않고 자유롭게 변수 이름 같은 고유한 식별자를 할당할 수 있습니다.
Hyperledger Fabric은 스마트 계약을 다른 스마트 계약으로부터 그들의 원장 world state 분리를 유지하는데 namespace를 사용합니다.
Scenario (What is a chaincode namespace)
아래 다이어그램을 사용하여 어떻게 원장 world state가 채널안의 조직에 중요한 비즈니스 객체에 대한 사실을 구성하는지 살펴봅시다.
이러한 객체가 기업 어음이든 채권이든 차량 등록이든 그들의 생명주기와 관계없이, 원장 world state database안에서 state로 유지됩니다.
스마트 계약은 원장(world state와 blockchain)과 상호작용하면서 그들의 비즈니스 객체를 관리하고 대부분의 경우 원장 world state를 업데이트하고 쿼리합니다.
원장 world state가 접근하는 스마트 계약의 체인코드에 따라서 분리된다는 것은 매우 중요합니다. 그리고 이 분리와 namespacing은 설계자, 관리자, 프로그래머에게 중요한 설계 고려사항입니다.
원장 world state는 액세스하는 체인코드에 따라 다른 namespace로 분리되어 있습니다. 주어진 채널 안에서 같은 체인코드내에 있는 스마트 계약은 같은 world state를 공유합니다. 그리고 다른 체인코드내에 있는 스마트 계약은 서로의 world state에 직접 접근할 수 없습니다. 마찬가지로 블록체인은 다른 체인코드 world state와 연관있는 트랜잭션을 포함할 수 있습니다.
이 예에서 체인코드 컨테이너에 있는 두 개의 다른 체인코드내에 정의된 네 개의 스마트 계약을 확인할 수 있습니다.
papers 체인코드에 정의된 euroPaper과 yenPaper 스마트 계약. bonds 체인코드내에 정의된 euroBond와 yenBond 스마트 계약.
이 설계는 application 프로그래머가 그들이 유로와 엔으로 책정된 기업어음 또는 채권의 동작 이해를 도우며, 각 금융 상품의 규칙은 다른 통화로 변경되지 않는 것이기 때문에 같은 체인 코드에서 그들의 배치를 관리하는 것이 합리적입니다.
이 다이어그램은 선택한 배치의 결과를 보여줍니다.
데이터베이스 관리 시스템(DBMS)는 papers와 bonds 체인코드와 그들안에 포함된 스마트 계약에다가 다른 world state database들을 만듭니다.
각각 별개의 데이터베이스안에 world state A와 world state B가 위치하고 있습니다. 단일 world state query가 두 world state에 접근할 수 없도록 데이터는 서로 격리됩니다.
world state는 그것의 체인코드에 따라 namespace가 지정됩니다.
world state A는 기업어음인 paperListEuro와 paperListYen의 목록들을 포함하고 있습니다.
PAP11과 PAP21 state는 euroPaper과 yenPaper 스마트 계약에 의해 관리되는 어음의 인스턴스입니다.
그들은 같은 체인코드 namespace를 공유하기 때문에, 그들의 keys(PAPxyz)는 papers 체인코드의 namespace안에서 고유해야합니다. 마치 거리 이름이 도시 내에서 고유한 것과 비슷합니다.
동일한 namespace를 공유하기 때문에 유로나 엔으로 가격이 책정된 모든 기업어음의 합계 계산을 수행하는 papers 체인코드에서 스마트 계약을 작성하는것이 어떻게 가능한지 확인하세요.
채권의 상황도 비슷합니다. 채권은 별도의 bonds 데이터베이스에 맵핑되는 world state B내에 보유되며, 그들의 key는 유니크해야합니다.
중요한 것은 euroPaper과 yenPaper이 직접 world state B에 접근할 수 없다는 것과 euroBond와 yenBond가 world state A에 접근할 수 없다는 것을 namespace는 의미한다는 것입니다.
이 분리는 기업 어음과 채권이 다른 속성과 다른 규칙을 가지고 있는 매우 뚜렷한 금융 상품이기 때문에 도움이 됩니다.
또한 papers와 bonds는 다른 namespace에 있기 때문에 같은 key를 가지고 있을 수 있음을 의미합니다.
이는 이름 지정에 상당한 자유도를 제공합니다.
이 자유를 사용하여 다른 비즈니스 객체에 의미있는 이름을 지정하세요.
가장 중요한 것은 블록체인은 특정 채널에서 동작하는 peer와 연관있고, 그것은 world state A 뿐만 아니라 world state B에 영향을 미치는 트랜잭션을 포함하고 있습니다.
블록체인이 peer에 포함된 가장 기본적인 데이터 구조이기 때문입니다.
world state들은 블록체인의 트랜잭션의 결과로 누적되므로, 언제나 이 블록체인으로부터 재생성될 수 있습니다.
world state는 일반적으로 state의 현재 값만 필요하므로, 스마트 계약을 단순화하고 그들의 효율성을 높이는데 도움이 됩니다.
namespace를 통해 world state 분리하는 것은 다른 world state에 해당하는 트랜잭션에 대한 걱정할 필요없이 스마트 계약이 그들의 로직을 다 다른 스마트 계약과 분리하는 것에 도움이 됩니다.
예를 들어, bonds 계약은 paper 트랜잭션의 결과적인 world state를 볼 수 없으므로 paper 트랜잭션에 대해서 걱정할 필요가 없습니다.
피어, 체인코드 컨테이너 그리고 DBMS는 모두 논리적으로 다른 프로세스라는 점도 주목할 가치가 있습니다.
피어와 모든 체인코드 컨테이너는 언제나 물리적으로 운영체제 프로세스와 분리되어 있지만 DBMS는 유형(Key Concepts » Ledger)에 따라 포함되거나 분리되도록 구성할 수 있습니다.
LevelDB의 경우 DBMS는 완전히 피어에 포함되지만, CouchDB는 운영체제 프로세스에서 분리됩니다.
채권으로부터 기업 어음을 분리해야하지만 이 예제에서 선택된 namespace는 다른 통화의 기업 어음을 공유하기 위한 비즈니스 요구사항의 결과라는 것을 기억하는 것은 중요합니다.
namespace 설계는 모든 금융 자산 클래스를 분리하거나 모든 기업어음, 채권을 공유하기 위한 비즈니스 요구사항을 충족하기 위해 어떻게 수정되는지 생각해보세요.
Channels (Channels and namespace)
피어가 여러 채널에 연결되면, 각 채널에 새로운 블록체인이 만들어지고 관리됩니다.
게다가 새로운 채널에서 체인코드가 인스턴스화 될 때마다, 새로운 world state database가 만들어집니다.
이는 채널이 world state의 체인코드와 나란히 일종의 namespace를 구성하는 것을 의미합니다.
그러나, 같은 피어와 체인코드 컨테이너 프로세스는 동시에 여러 채널에 연결할 수 있습니다. 블록체인, world state 데이터베이스와 달리 이러한 프로세스는 연결된 채널의 수에 따라 증가하지 않습니다.
예를 들어, papers와 bonds 체인코드가 새로운 채널에 인스턴스화되면, 거기에 완전히 별도의 블록체인을 생성하고, 두개의 새로운 world state 데이터 베이스가 생성됩니다.
그러나 피어와 체인코드 컨테이너는 증가하지 않고, 각각은 여러 채널에 연결됩니다.
Usage (How to use chaincode namespaces)
어떻게 application이 namespace에 있는 스마트 계약을 사용하는지 알기위해 우리의 기업 어음 예제를 사용해봅시다.
application은 peer와 커뮤니케이션하고, 피어는 적절한 체인코드 컨테이너에 요청을 보낸 다음 DBMS에 액세스한다는 점은 주목할만한 가치가 있습니다.
이 라우팅은 다이어그램에서 보이는 피어 핵심(core) 컴포넌트에 의해 수행됩니다.
유로와 엔으로 가격이 책정된 기업어음과 채권 둘 다 사용하는 application의 코드가 여기 있습니다. 코드는 매우 자명합니다.
const euroPaper = network.getContract(papers, euroPaper);
paper1 = euroPaper.submit(issue, PAP11);
const yenPaper = network.getContract(papers, yenPaper);
paper2 = yenPaper.submit(redeem, PAP21);
const euroBond = network.getContract(bonds, euroBond);
bond1 = euroBond.submit(buy, BON31);
const yenBond = network.getContract(bonds, yenBond);
bond2 = yenBond.submit(sell, BON41);
application 보기
- pepers 체인코드를 지정하는 getContract() API를 사용하여 euroPaper과 yenPaper 계약에 접근합니다. 1a와 2a를 확인하세요.
- bonds 체인코드를 지정하는 getContract() API를 사용하여 euroBond와 yenBond 계약에 접근합니다. 3a와 4a를 확인하세요.
- euroPaper계약을 사용하여 issue 트랜잭션을 기업 어음 PAP11의 네트워크에 제출합니다. 1a를 확인하세요. 이 결과는 world state A의 PAP11 상태로 표현된 기업 어음의 생성입니다. 1b를 확인하세요. 이 동작은 1c에서 블록체인의 트랜잭션으로 보여집니다.
- yenPaper 계약을 사용하여 redeem 트랜잭션을 기업 어음 PAP21의 네트워크에 제출합니다. 2a를 확인하세요. 결과는 world state A의 PAP21 상태로 표현된 기업 어음의 생성입니다. 2b를 확인하세요. 이 동작은 2c에서 블록체인의 트랜잭션으로 보여집니다.
- euroBond 계약을 사용하여 채권 BON31 의 네트워크에 buy 트랜잭션을 제출합니다. 3a에서 확인하세요. 결과는 world state B의 BON31 상태로 표현된 채권의 생성입니다. 3b에서 확인하세요. 이 동작은 3c에서 블록체인의 트랜잭션으로 보여집니다.
- yenBond 계약을 사용하여 채권 BON41의 네트워크에 sell 트랜잭션을 제출합니다. 4a에서 확인하세요. 결과는 world state B의 BON41 상태로 표현된 채권의 생성입니다. 4b에서 확인하세요. 이 동작은 4c에서 블록체인의 트랜잭션으로 보여집니다.
어떻게 스마트 계약이 world state와 상호작용하는지 확인하세요
- euroPaper과 yenPaper 계약은 world state A에 직접 접근할 수 있지만 world state B에는 그럴 수 없습니다. world state A는 papers 체인코드에 해당하는 DBMS의 papers 데이터베이스에 물리적으로 보관됩니다.
- euroBond와 yenBond 계약은 world state B에 직접 접근할 수 있지만 world state A에는 그럴 수 없습니다. world state B는 bonds 체인코드에 해당하는 DBMS의 bonds 데이터베이스에 물리적으로 보관됩니다.
어떻게 블록체인이 모든 world state의 트랜잭션을 확인하는지 보세요.
- 트랜잭션에 해당하는 1c와 2c는 기업어음 PAP11과 PAP21을 만들고 업데이트합니다. 이런 것들은 둘다 world state A안에 포함되어있습니다.
- 트랜잭션과 해당하는 3c와 4c 둘다 BON31과 BON41을 업데이트합니다. 이런 것들은 world state B에 포함되어있습니다.
- 만약 world state A 또는 world state B가 어떤 이유에 의해 파괴되었다면, 그들은 블록체인 안에서 모든 트랜잭션을 재현하여 다시 생성할 수 있다.
Cross chaincode access (How to access world states across smart contracts)
우리의 예제에서, euroPaper과 yenPaper은 world state B에 직접 접근할 수 없다.
체인코드와 스마트 계약을 체인코드와 world state가 서로서로 별도로 분리되게 설계했기 때문입니다.
그러나 euroPaper이 world state B에 접근하는 것이 필요로 하다는 것을 가정해봅시다.
왜 이런 일이 일어날까요?
기업 어음이 발행되었을 때, 스마트 계약은 유사한 만기일을 가진 채권이 현재 수익률에 따라 어음 가격을 책정하려고 한다고 상상해보세요.
이런 경우 euroPaper 계약은 world state B의 채권 가격을 쿼리할 수 있어야할 것입니다.
어떻게 상호작용하는지 구조를 보려면 다음 다이어그램을 참조하세요.
체인코드와 스마트 계약이 그들의 체인코드를 통해 또 다른 world statd에 간접적으로 접근하는 방법
방법을 확인하세요.
- application은 euroPaper 스마트 계약의 issue 트랜잭션을 PAP11를 발행하기 위해 제출합니다. 1a를 보세요.
- euroPaper의 issue 트랜잭션은 euroBond 스마트 계약의 query 트랜잭션을 호출합니다. 1b를 확인하세요.
- euroBond의 query는 world state B로부터 정보를 검색할 수 있습니다. 1c를 확인하세요.
- issue 트랜잭션에 제어권이 돌아올 때, 응답의 정보를 사용해서 어음의 가격을 측정하고 world state A를 업데이트합니다. 1d를 확인하세요.
- 엔화로 책정된 기업어음의 발행의 제어 흐름은 동일합니다. 2a, 2b, 2c, 2d를 확인하세요.
제어권는 invokeChaincode() API를 사용하여 체인코드간에 전달됩니다.
이 API는 하나의 체인코드에서 다른 체인코드로 제어권를 전달합니다.
예제에서 query 트랜잭션을 설명했지만, 호출된 체인코드의 world state를 업데이트 할 스마트 계약을 부를 수 있습니다.
아래 고려사항을 참고해보세요.
Considerations (Design considerations for chaincode namespaces)
- 일반적으로 각 체인코드는 단일 스마트 계약을 가집니다.
- 매우 밀접하게 연관되어 있는 경우에만 여러 스마트 계약이 동일한 체인코드안에 배포됩니다. 일반적으로 만약 같은 word state를 공유한다면 필연적입니다.
- 체인코드 namespace는 다른 world state 사이에 독립을 제공합니다. 일반적으로 서로 관련없는 데이터의 독립은 좋습니다. 체인코드 namespace는 선택할 수 없습니다. Hyperledger Fabric에 의해 할당되며, 체인코드 이름은 직접 매핑됩니다.
- invokeChaincode() API를 사용하여 체인코드 간 상호작용을 하기 위해 두 체인코드는 반드시 같은 피어에 설치되어있어야 합니다.
- 호출된 체인코드의 world state만 쿼리해야하는 상호작용을 하기 위해 호출은 호출한 체인코드에 다른 채널에 있을 수 있습니다.
- 호출된 체인코드의 world state를 업데이트하는 상호작용을 하기 위한 호출은 호출한 체인코드로서 같은 채널에 있어야만 합니다.
출처 ]
hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/chaincodenamespace.html