KR20240004463A - 제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약 - Google Patents

제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약 Download PDF

Info

Publication number
KR20240004463A
KR20240004463A KR1020237038150A KR20237038150A KR20240004463A KR 20240004463 A KR20240004463 A KR 20240004463A KR 1020237038150 A KR1020237038150 A KR 1020237038150A KR 20237038150 A KR20237038150 A KR 20237038150A KR 20240004463 A KR20240004463 A KR 20240004463A
Authority
KR
South Korea
Prior art keywords
network
blockchain
application
service
mesh network
Prior art date
Application number
KR1020237038150A
Other languages
English (en)
Inventor
비제이 마디세티
아르쉬딥 바가
Original Assignee
비제이 마디세티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/302,552 external-priority patent/US11283865B2/en
Application filed by 비제이 마디세티 filed Critical 비제이 마디세티
Publication of KR20240004463A publication Critical patent/KR20240004463A/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

서로 통신하도록 구성된 네트워크 서비스 도메인들(3304)을 포함하는 네트워크 서비스 메시 네트워크(3300)를 포함하는, 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크(3200) 아키텍처로서, 각각의 상기 네트워크 서비스 도메인(3304)은 네트워크 서비스 엔드포인트들(3316) 및 상기 네트워크 서비스 엔드포인트들(3316)의 가용성을 브로드캐스팅하는 네트워크 서비스 관리자(3312)를 포함한다. 상기 아키텍처는 서로 통신하도록 구성된 애플리케이션을 포함하는 애플리케이션 서비스 메시 네트워크(3200) 및 네트워크 서비스 도메인(3304)을 포함하는 애플리케이션 서비스 메시 네트워크(3200)를 더 포함한다. 네트워크 서비스 메시 네트워크(3300)와 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보를 포함하는 스마트 계약(5114)이 블록체인 네트워크에 기록된다.

Description

제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약
본 발명은 블록체인 네트워크의 거래에서 스마트 계약 연결을 개선하기 위한 시스템 및 방법에 관한 것이다.
블록체인은 모든 거래(transaction) 기록을 유지하는 분산형 공개 원장(ledger)이다. 블록체인 네트워크는 진정한 P2P(peer-to-peer) 네트워크이며, 거래를 인증하거나 결재하거나 네트워크 인프라를 제어하기 위해 신뢰할 수 있는 중앙 기관이나 중개자가 필요하지 않다. 사용자는 자신이 소유하고 통제하는 외부 소유 계좌(EOA, Externally Owned Account)를 통해 블록체인 네트워크와 상호 작용하고 거래할 수 있다. 각 EOA에는 이와 관련된 잔고(balance)(블록체인 네트워크와 관련된 암호화폐의 특정 단위)가 있다. EOA에는 관련 코드가 없다. 블록체인 네트워크의 모든 거래는 EOA에 의해 시작된다. 이러한 계좌는 다른 EOA 또는 계약 계좌로 거래를 보낼 수 있다. 2세대 프로그래밍 가능한 블록체인 플랫폼이 지원하는 또 다른 유형의 계좌는 계약 계좌이다. 계약 계좌는 EOA에 의해 생성 및 소유되며 계좌와 함께 저장된 관련 계약 코드에 의해 제어된다. 계약 코드 실행은 EOA에서 보낸 거래 또는 다른 계약에서 보낸 메시지에 의해 트리거된다.
블록체인 네트워크는 공개되거나 비공개일 수 있다. 공개(public) 블록체인 네트워크는 무료이며 모두에게 개방되어 있으며, 모든 사용자는 계좌를 생성하고 공개 블록체인의 합의(consensus) 메커니즘에 참여하며 네트워크의 모든 거래를 볼 수 있다. 비공개(private) 블록체인 네트워크는 일반적으로 단일 조직에 의해 제어 및 운영되며, 거래 내역은 해당 조직 내의 사용자만 볼 수 있다. 공개 블록체인 네트워크는 일반적으로 모든 노드(node)가 합의 프로세스에 참여할 수 있으므로, 비허가형(unpermissioned) 또는 퍼미션리스(permissionless)이다. 일부 공개 블록체인 네트워크는 미리 선택된 노드 세트에 의해 합의 프로세스가 제어되는 허가형 모델을 채택한다. 비공개 블록체인 네트워크는 일반적으로 허가형 모델을 채택한다. 공개 블록체인 네트워크는 완전히 분산된 것으로 간주될 수 있지만 비공개 블록체인 네트워크는 부분적으로 분산되어 있다.
조직(organizations)은 각 네트워크가 특정 사용 사례, 부서 또는 비즈니스 분야 전용으로 사용되는 여러 개의 비공개 블록체인 네트워크를 보유할 수 있다. 조직 내의 블록체인 네트워크는 동일한 블록체인 플랫폼이나 기술을 사용하거나 다른 플랫폼이나 기술을 사용하여 생성될 수 있다.
각 블록체인 네트워크에서 사용자는 여러 외부 소유 계좌(EOA)를 만들 수 있다. 각 외부 소유 계좌(EOA)에는 연결된 공개-비공개 키 쌍(public-private key pair)이 있다. 계좌 주소는 공개 키에서 파생된다. 새로운 EOA가 생성되면 계좌와 연결된 공개 키와 비공개 키가 포함된 키 파일이 생성된다. 비공개 키는 계좌를 생성할 때 제공한 비밀번호로 암호화된다. 다른 계좌로 거래를 전송하려면 비공개 키와 계좌 비밀번호가 필요한다.
이러한 배경 정보는 본 출원인이 본 발명과 관련성이 있을 것으로 믿는 정보를 밝히기 위해 제공된다. 전술한 정보 중 임의의 것이 본 발명에 대한 선행 기술을 구성한다는 것을 반드시 인정하려는 의도는 없으며 그렇게 해석되어서도 안 된다.
발명의 요약
위 사항을 염두에 두고, 본 발명의 구현예들은 블록체인 네트워크와 실제 물리적 세계 내에서 그리고 그 사이에서 정보, 가치(value) 또는 토큰(token)을 교환하기 위한 시스템 및 관련 방법에 관한 것이다.
일부 구현예들에서, 상기 시스템, 장치 및 방법은 클라우드-기반 빌보드 아키텍처 또는 블록체인 기반 빌보드 아키텍처 중 하나를 사용하여 서로 상호 작용하는 다수의 스마트 계약에 의존하는 확장가능한(scalable) 블록체인 애플리케이션의 생성 및 배포를 허용한다. 이 아키텍처를 사용하면 기존 블록체인 애플리케이션을 확장하여 전역 공유 변수(global shared variables)(Solidity와 같은 언어로)를 사용하여 서로 정보를 교환하는 스마트 계약을 배포할 수 있다. 빌보드 아키텍처를 사용하면 현실 세계(예: 대출금 지불 또는 제품 판매와 같은 트리거)와 스마트 계약 및 오라클(oracle) 시스템 간의 확장가능한 정보 교환을 원활하고 효율적으로 통합할 수 있다. 푸시/풀(push/pull), 게시/구독(publish/subscribe), 소비자/제조자(consumer/producer)와 같은 몇 가지 친숙한 프로그래밍 모델이 프로덕션 배포를 위해 쉽게 지원될 수 있다.
서로 상호 작용하는 수많은 연결된 스마트 계약에 의존하는 이더리움(Ethereum), 하이퍼레져(Hyperledger), 네오(Neo), 리스크(Lisk) 및 EOS와 같은 2세대 및 3세대 블록체인 플랫폼의 분산형 블록체인 애플리케이션과 스마트 계약은 제안된 게시판 메시징 프레임워크(BBMF, Bulletin Board Messaging Framework)와 전역 변수 네임 시스템(GVNS, Global Variable Name System) 기술의 이점을 누릴 수 있다. 연결된 스마트 계약이 포함된 애플리케이션의 현재 구현에서 하나의 스마트 계약은 거래를 다른 계약으로 보내거나 다른 계약의 공개 상태 변수를 보낼 수 있다. 그러나 이러한 콜(call) 및 변수 참조는 스마트 계약에 코딩되어야 하며 일단 배포된 계약 코드는 변경할 수 없다. 연결된 계약 시스템의 한 계약을 변경해야 하는 경우 코드를 변경해야 하므로 연결된 다른 모든 계약을 재배포해야 한다. BBMF 및 GVNS 기술을 사용하면 현실 세계와 스마트 계약 및 오라클 시스템 간의 확장가능한 정보 교환을 원활하고 효율적으로 통합할 수 있다. 또한 레거시(legacy) 블록체인 기반 코드는 이전 공개 상태 변수에서 새롭거나 재정의된 변수로의 새로운 매핑 및 배포를 통해 BBMF 프레임워크의 변경을 통해 원활하게 업그레이드되고 기능이 수정될 수 있다.
일부 구현예들에서, 상기 방법 및 시스템은, 다음과 같은 기능을 제공하는 소매 결제, 로얄티 보상 및 P2P 대출 애플리케이션(nCash 모바일 애플리케이션으로 지칭됨) 및 관련 플랫폼(nCash 네트워크로 지칭됨)을 포함하지만 이에 국한되지 않는 핀테크 및 기업 애플리케이션을 더 포함할 수 있다:
● 현실 세계와 연결되는 확장가능한 블록체인 아키텍처: 새로운 빌보드 기반 정보 및 가치 분배 시스템을 사용하여, 실제 세계의 트리거 및 이벤트와 결합되고 이에 응답하는 매우 많은 상호 작용 스마트 계약을 기반으로 하는 분산형(decentralized) 애플리케이션 및 시스템;
● 안전한 블록체인 결제: 이 플랫폼은 프로그래밍 가능한 2세대 블록체인 네트워크(예: 이더리움)를 기반으로 구축되었으며 개인이 안전하게 결제를 보내고 받을 수 있도록 한다;
● 판매자에서 결제: nCash 애플리케이션을 통해 사용자는 제휴 판매자에서 플랫폼에서 관리하는 암호화폐 또는 명목화폐를 사용할 수 있다;
● 토큰으로 잔돈 받기: 사용자는 더 이상 구매할 때 거스름 잔돈을 돌려받는 불편함을 겪을 필요가 없으며 모바일 애플리케이션 지갑으로 거스름돈을 받을 수 있다;
● 로열티 보상 및 혜택: 사용자는 제휴 판매자에서 nCash 앱으로 결제하면 독점적인 로열티 보상, 할인 혜택 및 캐시백을 받을 수 있다;
● 다중 통화 지원: nCash 모바일 애플리케이션 지갑은 여러 레이어(layer)의 통화(명목화폐, 암호화폐 및 ERC-20 토큰)를 관리할 수 있다. 사용자는 신용카드나 직불카드, ACH 은행 송금 또는 지원되는 암호화폐(비트경화, 이더리움, 라이트코인 등 포함)로 결제하여 nCash 코인(NCC)이라는 기본 토큰을 구매할 수 있다;
● ERC20 토큰: nCash 코인(NCC)은 ERC-20 토큰 표준을 기반으로 한다. NCC 토큰은 nCash 앱에서 지원되는 명목화폐 또는 암호화폐로 구매할 수 있다;
● 연락처와 채팅 및 거래: nCash를 사용하면 사용자는 채팅을 통해 결제를 보내거나 연락처에 결제를 요청할 수 있다;
● 코인 차용(borrow) 및 대출(lend): nCash 애플리케이션에는 대출 시장이 포함되어 있으며 nCash 코인 차용 및 대출을 지원한다;
● 다양한 계좌 유형: nCash 애플리케이션은 고객, 판매자 관리자 및 판매자 운영자 계좌 유형을 지원한다.
또한, 본 발명의 구현예들은, 거래 금액 전역 변수 네임 요청 및 거래 금액을 포함하는 거래일 수 있는 제1 거래 스마트 계약을 수신하고, 제1 거래를 제1 블록체인 네트워크의 제2 거래 스마트 계약에 기록하고, 제1 거래 금액 전역 변수 네임을 전역 변수 네임 시스템에 등록하여 거래 금액 전역 변수를 정의하는 것을 포함하는 블록체인 네트워크를 통해 가치를 교환하는 방법에 관한 것이다. 상기 방법은, 거래 금액에 응답하여 거래 금액 전역 변수의 값을 정의하고, 금융 거래일 수도 있으며 제2 거래 전역 변수 네임 요청과 제2 거래 금액을 포함하는 제2 거래 스마트 계약을 수신하고, 제2 거래 전역 변수 네임 요청을 전역 변수 네임 시스템에 등록하여 제2 거래 전역 변수를 정의하는 것을 더 포함한다. 상기 방법은, 제2 거래 금액에 응답하여 제2 거래 전역 변수의 값을 정의하고, 제2 거래 전역 변수 네임과 거래 값(value)을 포함하는 거래 알림을 수신하고, 상기 거래 알림을 제2 스마트 계약에 기록하고, 상기 거래 값에 응답하여 제2 거래 전역 변수의 값을 업데이트하는 것을 더 포함한다.
일부 구현예들에서, 제2 거래 전역 변수의 값을 업데이트하는 것은 제2 거래 전역 변수의 업데이트된 값을 제1 메시징 서버의 제1 관리 토픽(topic)에 게시하고 관리 토픽에 공개된 콘텐츠를 제1 구독자에게 전송하는 것을 포함할 수 있다. 제1 구독자가 제1 관리 토픽에 게시된 콘텐츠를 수신하면 제1 스마트 계약에 대한 스마트 계약 거래가 시작될 수 있으며, 제1 스마트 계약은 제1 블록체인 네트워크에 기록된다.
거래 금액 전역 변수를 등록하는 단계, 제2 거래 전역 변수를 등록하는 단계, 상기 제2 거래 전역 변수를 등록하는 단계 각각은 전역 변수 등록 프로세스를 수행하는 단계를 포함하며, 이는 사용자로부터 전역 변수 네임 레지스타(registrar)에 서 전역 변수 네임 등록 요청 수신, 새로운 전역 변수의 정의, 전역 변수 네임 레지스트리(registry)에서 새로운 전역 변수에 대한 소유자 정의, 및 새로운 전역 변수에 대한 리졸버(resolver)의 정의를 포함할 수 있다. 추가적으로, 상기 방법은 새로운 전역 변수의 값을 업데이트하기 위해 업데이트 절차를 수행하는 단계를 더 포함할 수 있으며, 상기 업데이트 절차는 제1 메시징 서버의 스마트 계약 데이터 소스에 의해 생성된 트리거를 수신하고(상기 트리거는 새로운 전역 변수의 업데이트된 값을 포함한다), 상기 트리거에 포함된 업데이트된 값을 제1 메시징 서버의 상기 새로운 전역 변수와 연관된 제1 관리 토픽(topic)에 게시하고, 상기 관리되는 토픽에 게시된 트리거에 포함된 업데이트된 값을 제1 구독자에게 전송하는 것을 포함한다. 제1 구독자가 제1 관리 토픽에 게시된 콘텐츠를 수신하면 제1 스마트 계약에 대한 스마트 계약 거래가 시작될 수 있으며, 제1 스마트 계약은 제1 블록체인 네트워크에 기록된다.
일부 구현예들에서, 상기 방법은 담보 입력을 수신하고 담보 입력을 제1 블록체인 네트워크의 담보 스마트 계약에 기록하는 단계를 더 포함할 수 있다. 담보 입력은 유형 자산 담보 예금을 수신하고, 유형 자산 담보 예금과 연관된 담보 토큰을 생성하고, 상기 담보 토큰을 전송함으로써 생성된 담보 토큰일 수 있다. 상기 유형 자산은 제3자가 받을 수 있으며 담보 토큰은 제3자에 의해 생성될 수 있다. 일부 구현예들에서, 상기 방법은 상환 알림을 수신하고, 상환 알림을 제2 거래 스마트 계약에 기록하고, 제2 거래 전역 변수의 값을 업데이트하고, 담보 스마트 계약에 담보 릴리스(release)를 기록하는 단계를 더 포함할 수 있다. 일부 구현예들에서, 상기 방법은 기본 알림을 수신하고, 기본 알림을 제2 거래 스마트 계약에 기록하고, 제2 거래 전역 변수의 값을 업데이트하고, 제2 거래 전역 변수에 대한 담보 스마트 계약에 담보 릴리스를 기록하는 단계를 더 포함할 수 있다. 담보 입력은 암호화폐 또는 담보 토큰 중 적어도 하나를 포함할 수 있다.
일부 구현예들에서, 상기 방법은 할부 결재(installation payment)를 수신하는 것, 할부 결재 알림을 제2 거래 스마트 계약에 기록하는 것, 상기 할부 결재의 값에 응답하여 제2 거래 전역 변수를 업데이트하는 것, 그리고 상기 할부 결재의 값의 적어도 일부를 제2 거래 전역 변수와 연관된 엔터티(entity)에 전송하는 것을 더 포함할 수 있다.
일부 구현예들에서, 제1 거래 스마트 계약은 차용자(borrower) 조건을 집합적으로 정의하는 대출 기간 및 대출 금리를 더 포함할 수 있으며, 상기 방법은, 대출 기간 전역 변수 네임을 전역 변수 네임 시스템에 등록하고, 거래 금액에 따라 대출 기간 전역 변수의 값을 정의하고, 대출 이자율 전역 변수 네임을 전역 변수 네임 시스템에 등록하고, 대출 이자율에 따라 대출 이자율 전역 변수의 값을 정의하는 것을 더 포함한다. 상기 방법은, 복수의 대출자로부터 복수의 대출 제안을 수신하고(각 대출 제안은 대출 금액, 대출 기간 및 예상 수익을 포함), 집합적으로 대출 풀(pool) 조건을 정의하고, 복수의 대출 제안을 기록하고, 대출 풀을 제1 블록체인 네트워크의 제2 거래 스마트 계약에 대해 정의하고(복수의 대출 제안 중 대출 제안의 값은 대출 풀 조건을 정의함), 차용자 조건이 대출 풀 조건과 매칭되는지 결정하고, 제2 거래 스마트 계약으로부터 대출 제안을 제1 거래에 매칭하고, 차용자와 제2 거래 스마트 계약 간의 차용자 스마트 계약을 기록하고, 매칭되는 대출 제안과 관련된 대출자(lender)와 제2 거래 스마트 계약 간의 대출자 스마트 계약을 기록하는 것을 더 포함할 수 있다. 추가로, 상기 방법은, 복수의 대출자로부터 다수의 복수의 대출 제안을 수신하고(각각의 대출 제안은 대출 금액, 대출 기간 및 예상 수익을 포함), 각각의 복수의 대출 제안을 기록하고, 제1 블록체인 네트워크의 제2 거래 스마트 계약에 대출 풀을 정의하고(복수의 대출 제안 중 대출 제안의 값은 대출 풀 조건을 정의함), 복수의 제2 거래 스마트 계약을 제1 블록체인 네트워크의 풀 스마트 계약의 풀에 기록하고, 차용자 조건이 풀 스마트 계약의 풀에 포함된 복수의 제2 거래 스마트 계약 중 임의의 대출 풀 조건과 일치하는지 여부를 결정하고, 풀 스마트 계약의 풀의 대출 제안을 제1 거래와 매칭시키고, 거래 스마트 계약. 차용자와 풀 스마트 계약의 풀 간의 차용자 스마트 계약을 기록하고, 풀 스마트 계약의 풀과 제2 거래 스마트 계약 사이의 P2P(pool-to-pool) 스마트 계약을 기록하고, 매칭되는 대출 제안과 관련된 대출자(lender)와 제2 거래 스마트 계약 간의 대출자 스마트 계약을 기록하는 것을 더 포함할 수 있다.
일부 구현예들에서, 상기 방법은 차용자와 관련된 차용자 신원 정보를 수신하는 것, 차용자 신용 등급을 수신하는 것, 그리고 차용자 신용 등급을 제1 블록체인 네트워크의 신용 등급 및 평판 스마트 계약에 기록하는 것을 더 포함할 수 있다.
본 발명의 추가 구현예들은 프로세서, 상기 프로세서와 통신하도록 위치하는 데이터 저장소, 및 상기 프로세서, 상기 데이터 저장소 및 네트워크 각각과 통신하도록 위치하는 네트워크 통신 장치를 포함하는 블록체인 네트워크를 통해 가치(value)를 교환하기 위한 시스템에 관한 것일 수 있다. 상기 네트워크 통신 장치는 거래 금액 전역 변수 네 요청 및 거래 금액을 포함하는 제1 거래 스마트 계약을 수신하도록 동작가능 할 수 있다. 프로세서는 제1 거래를 제1 블록체인 네트워크의 제2 거래 스마트 계약에 기록하고, 제1 거래 금액 전역 변수 네임을 전역 변수 네임 시스템에 등록하여 거래 금액 전역 변수를 정의하도록 동작할 수 있다. 추가적으로, 네트워크 통신 장치는 제2 거래 전역 변수 네임 요청 및 제2 거래 금액을 포함하는 제2 거래 스마트 계약을 수신하도록 동작 가능할 수 있다. 더욱이, 프로세서는 제2 거래 전역 변수를 정의하는 전역 변수 네임 시스템에 제2 거래 전역 변수 네임 요청을 등록하여 동작가능 할 수 있다. 네트워크 통신 장치는 제2 거래 전역 변수 네임과 거래 값을 포함하는 거래 알림을 수신하도록 동작 가능할 수 있다. 프로세서는 거래 알림을 제2 거래 스마트 계약에 기록하고 거래 값에 응답하여 제2 거래 전역 변수의 값을 업데이트하도록 동작할 수 있다.
본 발명의 구현예들은 또한 서로 통신하도록 구성된 복수의 네트워크 서비스 도메인을 포함하는 네트워크 서비스 메시 네트워크를 포함하는 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처에 관한 것일 수 있으며, 각 네트워크 서비스 도메인은 네트워크 서비스 클라이언트와 통신하도록 구성된 복수의 네트워크 서비스 엔드포인트 및 복수의 네트워크 서비스 엔드포인트의 가용성을 네트워크 서비스 클라이언트에 브로드캐스팅하도록 구성된 네트워크 서비스 관리자를 포함한다. 상기 아키텍처는 네트워크 서비스 메시 네트워크와 통신하도록 위치하는 애플리케이션 서비스 메시 네트워크를 더 포함할 수 있고, 상기 애플리케이션 서비스 메시 네트워크는 서로 통신하도록 구성된 복수의 애플리케이션 및 복수의 네트워크 서비스 도메인 중 네트워크 서비스 도메인을 포함한다. 상기 네트워크 서비스 메시 네트워크와 애플리케이션 서비스 메시 네트워크로부터의 네트워크 슬라이싱 정보를 포함하는 복수의 스마트 계약이 블록체인 네트워크에 기록된다.
일부 구현예들에서, 상기 네트워크 서비스 메시 네트워크는, 복수의 등록된 전역 변수를 포함하는 전역 변수 네임 시스템, 및 게시판 서버로서 복수의 애플리케이션으로부터 이에 의해 수신된 메시지에 응답하여 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성된 상기 게시판 서버를 더 포함할 수 있다. 복수의 스마트 계약은 등록된 전역 변수를 포함할 수 있다. 복수의 스마트 계약은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성될 수 있다.
일부 구현예들에서, 게시판 서버는 복수의 토픽을 포함할 수 있으며, 각각의 토픽은 등록된 전역 변수를 포함하고, 복수의 토픽들 중 토픽은 복수의 애플리케이션에 의해 구독되도록 구성될 수 있어, 상기 토픽에 포함된 등록된 전역 변수에 대한 업데이트에 관한 정보가 해당 토픽을 구독하는 애플리케이션으로 전송된다. 추가 구현예들에서, 상기 애플리케이션으로부터 나오는 악성 트래픽은 그로부터 나오는 트래픽을 애플리케이션과 연관된 스마트 계약과 비교함으로써 식별될 수 있고, 게시판 서버는 악성 트래픽에 응답하여 완화 조치를 수행하도록 구성된다. 또 다른 구현예들에서, 완화 조치는 전역 변수 네임 시스템을 통해 연결을 공지하는 것, 영향을 받는 애플리케이션을 격리하는 것, 애플리케이션에 의해 수행될 작업을 복수의 애플리케이션 중 다른 애플리케이션으로 이동시키는 것 중 적어도 하나를 포함할 수 있다.
일부 구현예들에서, 상기 네트워크 서비스 메시 네트워크로부터의 네트워크 슬라이싱 정보의 제1 세트를 포함하는 제1 복수의 스마트 계약은 제1 블록체인 네트워크에 기록될 수 있고, 애플리케이션 서비스 메시 네트워크로부터의 네트워크 슬라이싱 정보의 제2 세트를 포함하는 제2 복수의 스마트 계약은 제2 블록체인 네트워크에 기록될 수 있다. 추가 구현예들에서, 상기 아키텍처는 복수의 등록된 전역 변수를 포함하는 전역 변수 네임 시스템과, 게시판 서버로서 이에 의해 사용자로부터 수신된 메시지에 응답하여 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성된 상기 게시판 서버를 더 포함할 수 있다. 제1 및 제2 복수의 스마트 계약은 등록된 전역 변수를 포함할 수 있고, 제1 및 제2 복수의 스마트 계약은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성될 수 있다.
일부 구현예들에서, 상기 복수의 애플리케이션은 컨테이너화된 네트워크 기능, 가상 네트워크 기능, 작업자 노드, 서버, 컨테이너, 포드(pod) 및 가상 머신 중 적어도 하나를 포함할 수 있다. 추가 구현예들에서, 상기 복수의 네트워크 서비스 도메인의 적어도 일 서브세트(subset)는 쿠버네티스(Kubernetes) 설치에 의해 관리될 수 있다.
도 1은 스마트 계약과 블록체인을 사용하는 소매 결제, 로얄티 보상 및 P2P(peer-to-peer) 대출 시스템의 개략도이다.
도 2는, 본 발명의 일 구현예에 따라, 고객이 nCash 플랫폼을 인식하는 판매자 키오스크/애플리케이션/판매 애플리케이션 시점 또는 하드웨어 장치에서 현금으로 지불하고, 거스름 잔돈을 받는 대신 nCash 모바일 애플리케이션 지갑에서 디지털 토큰을 받는 소매 결제 프로세스를 예시한 것이다.
도 3은, 본 발명의 일 구현예들에 따라, 고객이 현금으로 지불하고 거스름 잔돈을 받는 대신 nCash 모바일 애플리케이션의 판매자 계좌로부터 디지털 토큰을 받는 소매 결제 프로세스를 예시한 것이다.
도 4는, 본 발명의 일 구현예에 따라, nCash 모바일 애플리케이션 지갑의 구성요소를 예시한 것이다.
도 5는, 본 발명의 일 구현예에 따라, QR 코드 기반 결제 요청 및 승인 프로세스를 예시한 것이다.
도 6은, 본 발명의 구현예들에 따라, 신용카드 또는 직불카드로 코인을 구매하는 프로세스를 도시한 도면이다.
도 7은, 본 발명의 구현예들에 따라, ACH 은행 이체를 통해 코인을 구매하는 프로세스를 예시한 것이다.
도 8은, 본 발명의 구현예들에 따라, 암호화폐(Cryptocurrency)로 코인을 구매하는 프로세스를 예시한 것이다.
도 9는, 본 발명의 구현예들에 따라, 연결된 은행 계좌로의 코인 인출 과정을 예시한다.
도 10은, 본 발명의 일 구현예에 따라, nCash 소매 결제, 로얄티 보상 및 P2P 대출 플랫폼과 관련된 스마트 계약을 예시한 것이다.
도 11은, 본 발명의 일 구현예에 따라, P2P 대출 프로세스를 도시한 도면이다.
도 12는, 본 발명의 일 구현예에 따라, 블록체인 기반 P2P 대출 시스템의 개략도이다.
도 13은, 본 발명의 일 구현예에 따라, P2P 대출 시스템에 의해 사용되는 다중 서명 담보 계약을 예시한 것이다.
도 14는, 본 발명의 일 구현예에 따라, 대출 연쇄 프로세스를 도시한 도면이다.
도 15는, 본 발명의 일 구현예들에 따라, 차용자가 대출금을 성공적으로 상환하는 경우 담보로서 암호화폐나 토큰으로 대출하는 프로세스를 도시한 도면이다.
도 16은, 본 발명의 일 구현예들에 따라, 차용자가 대출금을 상환하지 못하는 경우 담보로서 암호화폐나 토큰으로 대출하는 프로세스를 도시한 도면이다.
도 17은, 본 발명의 구현예들에 따라, 물리적 자산을 담보로 대출하는 프로세스를 도시한다.
도 18은, 본 발명의 일 구현예에 따라, 코인의 구매 및 판매에 관련된 거래 수수료를 도시한다.
도 19는, 본 발명의 일 구현예에 따라, 대출 플랫폼과 관련된 스마트 계약, 그리고 스마트 계약과 차용자 및 대출자의 상호작용을 예시한 것이다.
도 20은, 본 발명의 일 구현예에 따라, 스마트 계약을 사용하여 캐시백 및 할인을 발행하는 프로세스를 예시한 것이다.
도 21은, 본 발명의 일 구현예에 따라, P2P2P(Peer-to-Pool-to-Peer) 대출 모델을 도시한다.
도 22는, 본 발명의 일 구현예들에 따라, 대출 풀 스마트 계약을 생성하기 위한 대출 풀 생성기(lending pool generator)를 도시한다.
도 23은, 본 발명의 일 구현예들에 따라, 차용자를 대출 풀에 매칭하기 위한 매칭 엔진을 도시한다.
도 24는, 본 발명의 일 구현예에 따라, 오라클을 사용하여 대출 풀 계약에 외부 데이터를 공급하는 방법을 도시한다.
도 25는, 본 발명의 일 구현예에 따라, 대출 풀을 위한 채널 및 트리거를 예시한 것이다.
도 26은, 본 발명의 일 구현예에 따라, 대출 풀과 관련된 스마트 계약을 도시한다.
도 27은, 본 발명의 일 구현예들에 따라, 다수의 대출 풀을 포함하는 PoP(pool-of-pools)을 도시한다.
도 28은, 본 발명의 일 구현예에 따라, 대출 풀 스마트 계약 구조 및 거래를 도시한다.
도 29는, 본 발명의 일 구현예에 따라, 위험 및 수익에 기초한 대출 풀의 예시적인 분류를 도시한다.
도 30은, 본 발명의 일 구현예들에 따라, 상호 운용 가능한 로얄티 포인트를 갖는 판매자들의 동맹을 도시한다.
도 31은, 본 발명의 일 구현예에 따라, 게시판 메시징 프레임워크(BBMF, Bulletin Board Messaging Framework)라고 불리는 분산형 메시징 프레임워크를 도시한다.
도 32는, 도 31에 도시된 게시-구독 메시징 프레임워크에서 지원되는 소비자/구독자 동작을 도시한 것이다.
도 33은, 본 발명의 일 구현예들에 따라, 외부 게시자 클라이언트를 사용하여 게시-구독 메시징 프레임워크에 메시지를 게시하는 스마트 계약 데이터 소스를 도시한 것이다.
도 34는, 본 발명의 일 구현예들에 따라, 통합 게시자 클라이언트를 사용하여 게시-구독 메시징 프레임워크에 메시지를 게시하기 위해 스마트 계약 데이터 소스를 도시한 것이다.
도 35는, 본 발명의 일 구현예에 따라, 게시-구독 메시징 프레임워크에 대한 메시지 형식을 도시한 것이다.
도 36은, 본 발명의 일 구현예에 따라, 게시-구독 메시징 프레임워크의 고객에 의해 업데이트되는 전역 변수 네임 시스템을 도시한 것이다.
도 37은, 본 발명의 일 구현예에 따라, 전역 변수 네임 시스템의 아키텍처를 도시한 것이다.
도 38은, 본 발명의 일 구현예에 따라, 게시-구독 메시징 프레임워크에서의 블록체인 체크포인팅(checkpointing) 액세스법을 도시한 것이다.
도 39는, 본 발명의 일 구현예에 따라, 스마트 계약 전반에 걸친 전역 변수 공유를 도시한 것이다.
도 40은, 본 발명의 일 구현예에 따라, 게시판 발행자/제조자 클라이언트 및 소비자/구독자 클라이언트의 예시적인 구현이다.
도 41은, 본 발명의 일 구현예에 따라, nCash 모바일 애플리케이션의 예시적인 인터페이스이다.
도 42는, 본 발명의 일 구현예에 따라, P2P 대출 옵션을 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스이다.
도 43은, 본 발명의 구현예들에 따라, 다양한 유형의 거래를 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스이다.
도 44는, 본 발명의 일 구현예에 따라, 채팅 및 지불 인터페이스를 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스이다.
도 45는, 본 발명의 일 구현예에 따라, 다양한 유형의 계좌에 대한 nCash 모바일 애플리케이션 구성을 도시한 것이다.
도 46은 가상 머신에서 컨테이너로의 네트워크 기능 가상화의 전개(evolution)를 도시한 것이다.
도 47은 쿠버네티스(Kubernetes) 아키텍처를 도시한 것이다.
도 48은 애플리케이션 서비스 메시의 아키텍처를 도시한 것이다.
도 49는 네트워크 서비스 메시의 아키텍처를 도시한 것이다.
도 50은, 본 발명의 구현예들에 따라, 네트워크 서비스 메시를 통한 애플리케이션 서비스 메시를 도시한 것이다.
도 51은, 본 발명의 일 구현예에 따라, 블록체인 보안 서비스 메시를 도시한 것이다.
도 52는, 본 발명의 일 구현예에 따라, 게시판 메시징 프레임워크(BBMF, Bulletin Board Messaging Framework) 및 전역 변수 네임 시스템(GVNS, Global Variable Name System)을 통해 블록체인에 트래픽을 로깅하는 프로세스를 도시한 것이다.
도 53은, 본 발명의 일 구현예들에 따라, 블록체인 보안 서비스 메시와 관련된 스마트 계약을 도시한 것이다.
도 54는 본 발명의 구현예들에 따라, 블록체인 보안 서비스 메시를 사용하여 공격(DDoS 등)을 탐지하고 완화하는 단계를 도시한 것이다.
도 55는, 본 발명의 일 구현예들에 따른, 서로 다른 레이어에서 컨테이너화된 네트워크 기능(Containerized Network Function, CNF)에 대한 과제 및 요구 사항을 도시한 것이다.
도 56은, 본 발명의 일 구현예들에 따라, 블록체인 보안 애플리케이션 서비스 메시 및 블록체인 보안 네트워크 서비스 메시를 사용하는 다중-레이어(multi-layer) 보호 접근 방식을 도시한 것이다.
도 57은, 본 발명의 일 구현예들에 따라, 서로 다른 레이어에서 서로 다른 블록체인을 사용하는 다중-레이어 보호 접근 방식을 도시한 것이다.
도 58은, 본 발명의 일 구현예에 따라, 다중-레이어 보호 접근 방식의 슈퍼체인과 서브체인을 도시한 것이다.
도 59는, 본 발명의 일 구현예에 따라, 다중-레이어 보호를 위한 블록그리드(BlockGrid) 아키텍처의 도시한 것이다.
도 60은, 본 발명의 일 구현예에 따라, 블록그리드 아키텍처 내의 서로 다른 블록체인들의 블록 간의 관계를 도시한 것이다.
도 61은, 본 발명의 일 구현예에 따라, 블록체인 신원(identity) 및 액세스 관리 플랫폼을 도시한 것이다.
도 62는, 본 발명의 일 구현예에 따라, B-IAM 시스템과 다른 블록체인 네트워크 및 탈중앙화 애플리케이션 간의 상호 작용을 도시한 것이다.
도 63은, 본 발명의 일 구현예에 따라, 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(Blockchain-Enabled Network & Application Service Mesh, BENASM)를 도시한 것이다.
도 64는, 본 발명의 일 구현예에 따라, 신원-포함 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(Blockchain-Enabled Network & Application Service Mesh with Identity, BENASMI)를 도시한 것이다.
도 65는, 본 발명의 일 구현예에 따라, 신원-포함 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(Blockchain-Enabled Network & Application Service Mesh with Identity, BENASMI)와의 크로스-러스터/크로스-도메인(cross-cluster/cross-domain) 연결성, 신원 및 관측가능성을 도시한 것이다.
도 66은, 본 발명의 일 구현예에 따라, 마이크로서비스 아키텍처를 도시한 것이다.
도 67은, 본 발명의 일 구현예에 따라, 가상화 및 컨테이너화를 사용하여 5G에서 리소스의 동적 할당(dynamic allocation )을 도시한 것이다.
도 68은, 본 발명의 일 구현예에 따라, 네트워크 슬라이스 코인을 도시한 것이다.
도 69는, 본 발명의 일 구현예에 따라, 블록체인을 사용한 네트워크 슬라이스 관리를 도시한 것이다.
도 70은, 본 발명의 일 구현예에 따라, 5G에서 계층적 합의 모델(hierarchical consensus model)을 도시한 것이다.
본 발명은 이제 본 발명의 바람직한 구현예들이 도시되어 있는 첨부 도면을 참조하여 이하에서 더욱 완전하게 설명될 것이다. 그러나 본 발명은 여러 가지 다른 형태로 구현될 수 있으며 본원에서 설명하는 구현예들에 한정되지 않는다. 오히려, 이들 구현예들은 본 개시가 철저하고 완전해지고, 통상의 기술자에게 본 발명의 범위가 완전하게 전달되도록 제공되는 것이다. 통상의 기술자는 본 발명의 구현예들에 대한 다음의 설명이 예시적이며 어떠한 방식으로든 제한하려는 의도가 아니라는 것을 인식한다. 본 발명의 다른 구현예들은 본 개시의 이점을 갖는 통상의 기술자에게 쉽게 제안될 것이다. 유사한 숫자는 전체적으로 유사한 요소를 나타낸다.
다음의 상세한 설명은 예시를 위해 많은 세부 사항을 포함하고 있지만, 통상의 기술자는 다음의 세부 사항에 대한 많은 변형 및 변경이 본 발명의 범위 내에 있음을 이해할 것이다. 따라서, 본 발명의 다음 구현예들은 청구된 발명에 대한 일반성(generality)을 잃지 않고, 제한을 부과하지 않고 설명된다.
본 발명의 상세한 설명에서, 통상의 기술자는 설명의 편의를 위해 "위", "아래", "상부", "하부" 등과 같은 방향 용어가 도면을 참고하여 독자의 편의를 위하여 사용된다는 점에 유의해야 한다. 또한, 통상의 기술자는 본 설명이 본 발명의 원리에서 벗어나지 않으면서 위치, 배향 및 방향을 전달하기 위해 다른 용어를 포함할 수 있다는 점에 유의해야 한다.
또한, 본 상세한 설명에서, 통상의 기술자는 "일반적으로", "실질적으로", "대체로"와 같은 정량적 한정 용어 및 기타 용어가 일반적으로 언급된 대상, 특성 또는 품질이 참조 주체(subject)의 대부분을 구성한다는 것을 의미하기 위해 사용된다는 점에 유의해야 한다. 이러한 용어들의 임의의 의미는 해당 용어가 사용되는 맥락에 따라 달라지며, 그 의미는 명시적으로 변경될 수 있다.
이제 도 1을 참조하여, 스마트 계약과 블록체인을 사용하는 소매 결제, 로얄티 보상 및 P2P 대출 시스템의 개략도를 더 자세히 설명한다. 사용자(100)와 판매자(102)는 애플리케이션 및 프리젠테이션 레이어(104)를 사용하여 거래를 완료할 수 있다. 애플리케이션 및 프리젠테이션 레이어(104)는 웹 인터페이스(106) 및/또는 모바일 애플리케이션(108)을 포함할 수 있다. 애플리케이션 및 프리젠테이션 레이어(104)의 요소(element)는 플랫폼/애플리케이션 서비스 레이어(110)의 클라이언트 측 요소일 수 있다. 플랫폼/애플리케이션 서비스 레이어(110)은 사용자 신원 및 액세스 관리 시스템(114)과 같은 보안 구성(112)을 포함할 수 있다. 플랫폼 /애플리케이션 서비스 레이어(110)은, 예를 들어, 메시징 서비스(118), 또는 애플리케이션, 클라우드 서비스 및 토큰 교환(120)을 위한 커넥터 서비스와 같은 통합 서비스(116)를 더 포함할 수 있다. 플랫폼/애플리케이션 서비스 레이어(110)은 컨피겨레이션(configuration) 관리 기능(122)을 더 포함할 수 있다. 컨피겨레이션 관리 기능(122)은 nCash 포털(124), 인센티브 관리 시스템(126) 및 라이센스 관리자(128)를 포함할 수 있다. 플랫폼/애플리케이션 서비스 레이어(110)은 거스름돈 관리 프레임워크(change management framework)(132), 토큰 프레임워크(469), 인센티브 지불 프레임워크(136), 대출 프레임워크(138) 및 nCash 지갑(140)과 같은 회계 및 거래 서비스(130)를 더 포함할 수 있다. 플랫폼/애플리케이션 서비스 레이어(110)는 분석 및 보고 시스템(144), 인센티브 입찰 시스템(146), 대출 매칭 시스템(148), 추천 시스템(150), 게시 및 판촉 시스템(152)과 같은 데이터 관리 및 분석 서비스(142)를 더 포함할 수 있다. 플랫폼/애플리케이션 서비스 레이어(110)은 블록체인 네트워크(156), 분산형 스토리지 플랫폼(158), 분산형 메시징 플랫폼(160), 또는 클라우드 컴퓨팅 리소스, 클라우드 스토리지 리소스 또는 클라우드 네트워킹 리소스와 같은 클라우드 인프라(162) 중 하나 이상을 포함할 수 있는 인프라 레이어(154)에서 기능할 수 있다.
이제 도 2를 참조하여, 고객이 현금으로 지불하고 거스름돈을 돌려받는 대신 nCash 모바일 애플리케이션에서 거스름돈을 디지털 토큰(nCash 코인 -“NCC”)으로 받는 소매 결제의 프로세스 흐름을 더 자세히 설명한다. 고객(200)은 단계 204에서 매장에서 구매 또는 대여한 물품 대금을 현금으로 결제한다. 고객(200)은 단계 206에서 nCash 앱을 실행하고 고객의 nCash 계좌번호 바코드를 표시한다. 단계 208에서 nCash 플랫폼(202)을 인식하는 판매자 키오스크/애플리케이션/판매 시점 관리 애플리케이션 또는 하드웨어 장치는 바코드를 스캔하고 항목(entry)이 원장에 추가되어 거스름돈을 nCash 계좌로 전송한다. 예를 들어 하루가 끝날 때와 같이 일정한 간격으로 nCash 계좌에 거스름돈을 적립하는 모든 거래가 결제 시스템에 의해 처리된다. 고객(200)은 단계 210에서 nCash 앱에서 거스름돈을 다시 수신한다.
이제 도 3을 참조하여, 고객이 현금으로 지불하고 거스름돈을 받는 대신 nCash 모바일 애플리케이션의 판매자 계좌로부터 디지털 토큰을 받는 소매 결제에 대한 프로세스 흐름이 더 자세히 설명된다. 고객(220)은 단계 224에서 매장에서 구매 또는 대여한 물품 대금을 현금으로 결제한다. 고객(220)은 nCash 앱을 열고 단계 226에서 QR 코드를 표시한다. nCash 모바일 애플리케이션이 설치된 모바일/태블릿 기기를 보유하고 있는 판매자/PoS 에이전트(222)는 단계 228에서 QR 코드를 스캔하여 거스름돈 금액을 입력하고 판매자 관리자 또는 운영자 계좌에서 즉시 해당 금액을 이체한다. 모든 PoS 에이전트(222)에는 거스름돈으로 지불하기 위해 매일 매장에서 일정 금액을 로딩하는 판매자(Merchant) nCash 앱이 있다. 고객(220)은 단계 230에서 nCash 앱에서 거스름돈을 다시 수신한다.
이제 도 4를 참조하여, nCash 모바일 애플리케이션 지갑(250)의 4가지 구성요소에 대해 보다 자세히 설명한다. nCash 지갑(250)은 명목화폐 지갑(252), 암호화폐 지갑(258), 쿠폰 및 바우처 관리 시스템(254), ERC-20 토큰 지갑(260), 에스크로 계좌(256) 및 선불 신용 계좌(262)를 포함할 수 있다. 소매 결제를 위해 명목화폐 또는 암호화폐 지갑(252, 258)의 일부 또는 선불 예금이 고려될 수 있다. 명목화폐 및 암호화폐 지갑(252, 258) 중 하나 또는 둘 다의 지갑 잔고는 고객이 판매자에게 보낸 지불금이 에스크로 계좌에 보관되고 주문이 이행될 때 릴리스되는(released) 에스크로(256)에도 적용될 수 있다.
이제 도 5를 참조하여, QR 코드 기반 결제 요청 및 승인에 대한 프로세스 흐름이 더 자세히 설명된다. 고객(302)은 단계 318에서 nCash 모바일 애플리케이션을 사용하여 고객의 nCash 지갑 주소와 일회성 수신 코드가 포함된 QR 코드를 표시한다. 단계 316에서 QR 코드는 판매자 계좌(308)가 있는 PoS 기계(306) 또는 nCash 앱에 의해 스캔되고, 고객 주소, 수신 코드 및 금액을 포함하는 요청이 nCash 네트워크(300)로 전송된다. 단계 312에서 nCash 네트워크(300)는 수신 코드를 검증하고 고객에게 결제 승인 요청을 보낸다. 고객(302)은 단계 314에서 nCash 앱으로부터의 결제를 승인한다. 단계 310에서 결제 확인이 판매자 계좌(308)를 통해 PoS 기계(306) 또는 nCash 앱으로 전송된다.
이제 도 6을 참조하여, 신용카드나 직불카드로 코인을 구매하는 프로세스 흐름이 더 자세히 설명된다. 고객(350)은 단계 356에서 신용 카드 또는 직불 카드를 사용하여 nCash 지갑에 금액을 로딩하라는 요청을 보낸다. nCash 네트워크(352)는 단계 358에서 고객(350)의 신용카드 또는 직불카드 정보를 요청한다. 고객(350)은 단계 360에서 nCash 모바일 애플리케이션에 신용 카드 또는 직불 카드 정보를 입력한다. 그런 다음 카드 정보는 단계 360에서 nCash 네트워크(352)를 통하지 않고 직접 명목화폐 결제 프로세서(354)로 전송된다. 단계 362에서 명목화폐 결제 프로세서(354)는 카드 정보를 검증하고 고객의 nCash 모바일 애플리케이션으로 전송되는 토큰을 생성한다. 단계 364에서 고객(350)은 결제를 확인하고 카드 토큰과 결제 금액이 포함된 요청을 보낸다. nCash 네트워크(352)는 단계 366에서 명목화폐 결제 프로세서(354)에 카드에 청구하기 위한 토큰 및 결제 금액이 포함된 요청을 보낸다. 단계 368에서 명목화폐 결제 프로세서(354)는 요청된 금액에 대해 고객의 카드에 요금을 청구하고 결제 확인이 nCash 네트워크(352)로 전송된다. nCash 네트워크(352)는 새로운 코인(nCash 토큰 스마트 계약에 정의된 디지털 토큰)과 토큰 스마트 계약(370)을 발행한다. nCash 네트워크(352)는 단계 372에서 이러한 새로운 코인(디지털 토큰)을 고객의 nCash 지갑 계좌에 추가한다.
이제 도 7을 참조하여, ACH 은행 이체를 통해 코인을 구매하는 프로세스 흐름을 더 자세히 설명한다. 고객(400)은 단계 406에서 ACH 은행 이체를 사용하여 nCash 지갑에 금액을 로딩하라는 요청을 nCash 네트워크(402)에 보낸다. nCash 네트워크(402)는 단계 408에서 명목화폐 결제 프로세서(404)에게 임시 계좌 세부정보를 요청한다. 단계 410에서 명목화폐 결제 프로세서(404)는 임시 계좌를 생성하고 임시 계좌에 대한 세부사항을 nCash 네트워크(402)로 전송한다. 그러면 nCash 네트워크(402)는 임시 계좌 세부사항을 고객의 nCash 모바일 애플리케이션에 전송한다. 고객(400)은 단계 414에서 ACH 은행 이체를 사용하여 임시 계좌로 지불금을 보낸다. 결제를 수신하면, 명목화폐 결제 프로세서(404)는 단계 416에서 nCash 네트워크(402)에 결제 확인을 보낸다. nCash 네트워크(402)는 새로운 코인(nCash 토큰 스마트 계약에 정의된 디지털 토큰)과 토큰 스마트 계약(418)을 발행한다. nCash 네트워크(402)는 단계 420에서 이러한 새로운 코인(디지털 토큰)을 고객의 nCash 지갑 계좌에 추가한다.
이제 도 8을 참조하여, 암호화폐로 코인을 구매하는 프로세스 흐름이 더 자세히 설명된다. 단계 456에서 고객(450)은 암호화폐를 사용하여 nCash 지갑에 금액을 로딩하라는 요청을 nCash 네트워크(452)에 보낸다. nCash 네트워크(452)는 단계 458에서 암호화폐 결제 프로세서(454)에게 임시 계좌 세부정보를 요청한다. 단계 460에서 암호화폐 결제 처리기(454)는 임시 계좌를 생성하여 이를 nCash 네트워크(452)로 전송한다. 그러면 nCash 네트워크(452)는 단계 462에서 고객의 nCash 모바일 애플리케이션에 임시 계좌 세부사항을 전송한다. 고객(450)은 단계 470에서 암호화폐 지갑을 이용하여 임시계좌로 결제금을 보낸다. 지불을 수신하면, 암호화폐 지불 프로세서(454)는 단계 472에서 nCash 네트워크(452)에 지불 확인을 보낸다. nCash 네트워크(452)는 새로운 코인(nCash 토큰 스마트 계약에 정의된 디지털 토큰)과 토큰 스마트 계약(480)을 발행한다. nCash 네트워크(452)는 단계 482에서 이러한 새로운 코인(디지털 토큰)을 고객의 nCash 지갑 계좌에 추가한다.
이제 도 9를 참조하여, 에서는 연결된 은행계좌로 코인을 인출하는 과정의 흐름을 더 자세히 설명한다. 고객(500)은 단계 508에서 은행(506)에 있는 고객의 연결 은행 계좌로 특정 금액의 토큰을 인출하라는 요청을 nCash 네트워크(502)에 보낸다. 출금 요청을 수신한 nCash 네트워크(502)는 고객 계좌에서 인출 금액에 해당하는 코인을 소각하고 토큰 스마트 계약(510)을 업데이트한다. 그러면 nCash 네트워크(502)는 단계 512에서 명목화폐 결제 프로세서(504)에 이체 요청을 보낸다. 인출 금액은 단계 514에서 명목화폐 결제 프로세서(504)에 의해 은행(506)에 있는 고객의 연결된 은행 계좌로 입금된다. 그 다음, 명목화폐 결제 프로세서(504)는 단계 518에서 nCash 네트워크(502)에 이체 확인을 보낸다. 그런 다음 단계 520에서 출금 확인이 고객(500)에게 전송된다.
이제 도 10을 참조하여, nCash 소매 결제, 로얄티 보상, P2P 대출 플랫폼과 관련된 스마트 계약의 10가지 예가 더 자세히 설명된다. nCash 블록체인 네트워크(588)는 nCash 네트워크상의 모든 거래 기록을 유지하는 분산 원장이다. 사용자(554)는 사용자가 소유하고 제어하는 외부 소유 계좌(EOA)(550)를 통해 블록체인 네트워크(588)와 상호 작용하고 거래한다. 각 EOA(550)는 계좌 주소(556), 계좌 공개-비공개 키(558) 및 이와 관련된 잔고(560)(블록체인 네트워크와 관련된 암호화폐의 특정 단위)을 갖는다. EOA에는 관련 코드가 없다. EOA는 암호화폐를 은행 계좌(552)에 예치하거나 인출할 수 있는 명목화폐로 교환할 수 있는 제3자 교환을 통해 사용자(554) 가 역시 소유한(566) 은행 계좌(552)와 상호작용(564)할 수 있다.
블록체인 네트워크의 모든 거래는 EOA에 의해 시작된다. 이러한 계좌는 다른 EOA 또는 계약 계좌로 거래를 보낼 수 있다. 2세대 프로그래밍 가능한 블록체인 플랫폼이 지원하는 또 다른 유형의 계좌는 계약 계좌이다. 스마트 계약(570)에는 관련 계약 계좌를 제어하는 계약 코드가 포함되어 있다. 스마트 계약(570)은 블록체인 네트워크(588)에 배포된다. nCash 네트워크에 관련된 스마트 계약(570)은 다음과 같다:
토큰 계약(572): 토큰 계약은 토큰 네임, 기호, 소수 자릿수, 토큰 공급, 토큰 전송 방법 및 계좌의 토큰 잔고 확인 방법을 포함한 nCash 토큰 정의를 제공한다;
토큰 배포(distribution) 계약(580): 토큰 배포 계약은 토큰 배포 및 가격 책정 모델을 정의하고 토큰 구매 및 청구 방법과 토큰 판매 수익금 인출 방법을 포함한다;
인센티브 계약(574): 인센티브 계약은 인센티브와 인센티브 배포를 위한 트리거 및 방법을 정의한다;
입찰 계약(582): 입찰 계약은 판매자가 인센티브를 추가할 수 있는 권리에 대해 경쟁, 입찰 또는 지불할 수 있도록 하는 입찰 메커니즘을 정의한다;
대출 스마트 계약(576): 대출 스마트 계약은 대출 조건을 시행하고, 대출 릴리스, 상환 또는 연장을 관리하는 데 사용된다;
신원(Identity) 스마트 계약(584): 신원 스마트 계약은 블록체인 계좌를 실제 사용자(차용자 또는 대출자)와 연결하는 데 사용된다;
신용 등급 및 평판 스마트 계약(578): 신용 등급 및 평판 스마트 계약은 차용자의 신용 점수와 평판을 추적하는 데 사용된다;
담보 스마트 계약(586): 담보 스마트 계약은 암호화폐 토큰이나 토큰화된 형태로 표시될 수 있는 물리적 자산과 같은 담보의 잠금 및 릴리스를 관리하는 데 사용된다.
이제 도 11을 참조하여, P2P 대출에 대한 프로세스 흐름이 더 자세히 설명된다. 차용자(600)는 606단계에서 대출 요청 형태로 제1 거래 스마트 계약을 생성한다. 대출 플랫폼(602)은 단계 616에서 대출 피어(lending peer)(대출자)(604)에게 대출 요청을 게시한다. 대출 플랫폼(602)은 차용 피어(600)와 관련된 신용 등급(612)을 획득하고 요청과 함께 신용 등급을 포함할 수 있다. 대출 피어(604)는 단계 620에서 대출 제안의 형태로 제2 거래 스마트 계약을 대출 플랫폼(602)에 보냄으로써 대출에 입찰한다. 단계 610에서 차용 피어(600)는 최상의 제안을 선택하고 대출 금액이 차용 피어에게 전송된다. 차용 피어(600)는 단계 608에서 대출 금액에 이자와 대출 플랫폼 수수료를 더한 금액을 대출 플랫폼(602)에 상환한다. 대출 플랫폼(602)은 단계 618에서 대출 금액에 이익을 더한 금액을 대출 피어(604)에게 반환한다. 대출 플랫폼(602)은 대출의 성공적인 상환 시 차용 피어(600) 및 대출 피어(604) 에게 로열티 포인트(614)를 발행하여 차용 피어 및 대출 피어(600, 604)가 차용 및 대출을 위해 대출 플랫폼을 다시 사용하도록 장려할 수 있다.
이제 도 12를 참조하여, 블록체인 기반 P2P 대출 시스템의 개략도가 더 자세히 설명된다. 블록체인 기반 P2P 대출 시스템을 통해 차용 피어 또는 차용자(652)는 대출 피어 또는 대출자(656)에게 게시되는 플랫폼(650)에 대출 요청을 보낼 수 있다. 대출자(656)은 블록체인 네트워크(678)에 배포된 대출 스마트 계약(668)에 의해 시행되는 결산 날짜를 포함하여 특정 금리(rate) 및 조건으로 대출을 보내도록 입찰할 수 있다. 대출 플랫폼(650)은 전자 결제 플랫폼과 공존할 수 있다. 차용자(652)는 대출 요청과 그들이 지불할 수 있는 금리를 플랫폼에 게시하고 대출자는 조건과 금리로 대출에 입찰한다. 플랫폼(650)은 차용자(652)가 그들의 nCash 모바일 애플리케이션 지갑(차용자 암호화 지갑)(662)으로부터 대출금을 자동으로 상환하거나 합의된 경우 또 다른 기간 동안 대출을 연장할 수 있게 한다. 플랫폼(650)은 신용화폐나 암호화폐로 대출금을 지급할 수 있다. 대출금이 지급되면 대출 금액은 대출자 암호화폐(Lender Crypto) 지갑(672)(대출자의 nCash 모바일 애플리케이션 지갑)에서 차용자 암호화폐(Borrower Crypto) 지갑(662)(차용자의 nCash 모바일 애플리케이션 지갑)으로 이체된다. 금리는 시장에 의해 결정된다. 위험이 높을수록 금리가 높아진다. 플랫폼(650)은 모든 거래에 대해 일정 비율의 금리를 부과할 수 있다. 플랫폼(650)에 포함된 차용자 신원 스마트 계약(658)은 차용자(652)의 신원 정보를 유지한다. 플랫폼(650)에 포함된 대출자 신원 스마트 계약(670)은 대출자(656)의 신원 정보를 유지한다. 차용자 평판 및 신용등급 플랫폼(650)에 포함된 스마트 계약(660)은 차용자(652)의 평판 정보 및 신용등급을 유지한다. 플랫폼(650)에 포함된 담보 스마트 계약(664)은 대출에 대한 담보 정보를 유지한다. 대출에 대한 평판 시스템과 담보는 대출 프로세스를 더욱 안정적으로 만든다. 대출 플랫폼(650)은 스마트 계약을 사용하여 차용자에 대한 신용 등급 및 평판 시스템을 생성한다. 각 상환 및 성공적인 대출은 차용자의 신용 등급에 포인트를 추가하며, 대출이 상환되지 않으면 포인트가 차용자의 신용 등급에서 차감된다. 이러한 지불은 대출자(656)를 위한 암호화폐 지갑(672)으로 이체될 수 있다. 대출을 요청하는 차용자(652)가 조건에 따라 상환하지 않는 경우, 그들의 신용 등급/평판은 떨어지고 대출자(656)은 후속 대출 요청에 대해 극도로 높은 이율과 더 높은 보증을 부과할 것이다. 대출 금액은 차용자(652)에 의한 담보 계좌에 대한 것일 수도 있고, 보증인(654)이나 다른 피어로부터 대출의 특정 부분을 보장하겠다는 서약을 받은 것일 수도 있다. 차용자가 그를 지원하겠다고 약속하면 위험 점수가 낮아진다. 위험 점수가 갑자기 변경되면 기존 대출자는 더 높은 금리가나 더 짧은 상환 기간을 선택할 수 있다는 알림을 받는다. 이로 인해 차용자는 이러한 마진 콜로부터 보호하기 위해 현명하게 돈을 빌릴 수 있다. 플랫폼(650)을 통해 발행된 대출은 담보(담보에 의한 보증)되거나 무담보일 수 있다. 플랫폼(650)의 매칭 엔진(666)은 대출 요청을 대출 제안과 일치시키고 차용자를 대출자에 연결한다. 이 플랫폼은 위험 평판, 대출 가치 및 금리 조건을 기준으로 차용자와 대출자를 연결한다. 담보 대출의 경우 차용자(652) 또는 보증인(654)은 암호화폐 토큰 또는 토큰화된 자산의 형태로 담보를 제시할 수 있다. 암호화폐 토큰이 담보로 제시되면 해당 토큰은 차용자에 의해 대출금이 상환되지 않을 때까지 토큰이 보관되는 담보 계약으로 이전된다. 대출금이 상환되면 토큰은 차용자(652)에게 게시된다. 대출금이 상환되지 않으면 토큰은 대출자(656)에게 게시된다. 금, 다이아몬드, 부동산 등의 물리적 자산은 토큰화되어 담보로 제시될 수 있다. 그러한 경우, 제3자를 고용하여 물리적 자산을 확인하거나 대출금이 상환될 때까지 자산을 보관할 수 있다. 대출 플랫폼(602)은 대출의 성공적인 상환 시 차용 피어(600) 및 대출 피어(604)에게 로열티 포인트(614)를 발행하여 차용 및 대출 피어(600, 604)가 대출 및 대출을 위해 대출 플랫폼을 다시 사용하도록 장려할 수 있다.
이제 도 13을 참조하여, 도 12에 도시된 P2P 대출 시스템에 의해 사용되는 다중 서명 담보 계약이 더 자세히 설명된다. 담보 토큰은 다중 서명 지갑 계약(700)에 저장된다. 차용자(702), 대출자(706), 대출 플랫폼(704) 및 선택적인 제3자(708)는 다중 서명 지갑 계약(700)에 대한 키를 보유한다. 계약에는 담보를 릴리스하기 위해 M-of-N 서명, 일반적으로 과반수(예: 2/3 또는 3/5)가 필요한다.
이제 도 14를 참조하여, 대출 체이닝(chaining)을 위한 프로세스 흐름이 더 자세히 설명된다. 대출 플랫폼은 신용 등급이 좋은 차용/대출 피어가 낮은 금리로 대출을 받고 신용 등급이 낮은 한 명 이상의 피어에게 더 높은 금리로 빌려줄 수 있는 체인 대출을 지원한다. 예를 들어, 피어 C(752)는 신용 등급이 좋고 대출 요청(760)을 보내고 피어 D(754)로부터 낮은 금리로 빌린다(762). 피어 C(752)는 낮은 신용 등급 또는 위험 프로필을 가진 피어 A 및 B(750, 756)로부터 대출 요청(758, 766)을 수신한 다음 피어 A 및 B(750, 756)에게 각각 더 높은 금리로 대출(764, 768)을 보낸다. 대출은 다양한 조건의 하위 대출로 분할될 수 있다. 대출자는 대출 요청의 일부 또는 분액(fraction)에 자금을 지원할 수 있다. 따라서 대출은 각각 다른 이율로 12개의 소액 대출로 충족될 수 있다. 예를 들어, 대형 대출자가 대출의 30%에 뛰어들면 소규모 대출자는 더 낮은 금리로 대출에 뛰어들 수 있다. 위험이 낮은 차용자는 대출을 할 수 있지만 고액 대출자(예: 기관 또는 은행)에 대한 입찰에는 25%만 게시된다. 그런 다음 차용자는 고액 대출자가 이 차용자를 조사할 것임을 알고 있는 소규모 대출자에 대출을 오픈(open)할 수 있다. 대출 피어는 특정 위험을 감수하고 특정 가격으로 대출 묶음(bundle)을 구매하거나 대출을 재판매할 수 있다. 대출 플랫폼을 사용하면 사용자가 대출을 구매, 풀링 및 재판매할 수 있는 시장을 만들 수 있다. 대출 플랫폼은 특정 조건이 충족될 경우 대출이 취소되도록 허용할 수 있다. 예를 들어, 자선가가 진료소에 자금을 지원하고 한 달에 500명의 환자를 치료한다면 그의 대출에 대한 대출 금리가 줄어들 수 있고, 농부가 두 가지 일자리를 창출하면 대출이 탕감될 수 있다.
이제 도 15를 참조하여, 차용자가 대출금을 성공적으로 상환하는 경우 암호화폐나 토큰을 담보로 대출하는 프로세스를 보다 자세히 설명한다. 차용자(800)는 단계 808에서 요청 금액 및 대출 조건을 포함하는 대출 요청을 생성한다. 대출 플랫폼(802)은 대출 계약(810)을 생성하고 단계 812에서 대출자에 대출 요청을 게시한다. 대출자(804)은 단계 814에서 대출 자금을 조달하는 데 동의한다. 다음으로, 차용자(800)는 단계(816)에서 암호화폐 또는 토큰을 담보 계약(818)에 담보로 예치한다. 대출자(804)은 단계 820에서 대출금에 자금을 조달한다. 대출 금액은 단계 822에서 차용자(800)에게 게시된다. 차용자(800)는 단계 824 및 828에서 대출 할부금을 대출 플랫폼(802)에 지불하고, 이는 단계 826 및 830에서 대출자(804)에게 릴리스된다. 대출 상환이 완료되면, 단계 832에서 담보가 차용자(800)에게 릴리스되고, 이러한 릴리스는 담보 계약(818)에 기록된다.
이제 도 16을 참조하여, 차용자가 대출금을 상환하지 못하는 경우 암호화폐나 토큰을 담보로 대출하는 과정을 보다 자세히 설명한다. 차용자(850)는 단계 858에서 요청 금액 및 대출 조건을 사용하여 대출 플랫폼(852)에 대출 요청을 생성한다. 대출 플랫폼(852)은 단계 862에서 대출 계약(860)을 생성하고 대출자에 대출 요청을 게시한다. 대출 요청이 게시된 N개의 대출자(856) 중 대출자(854)은 단계 864에서 대출 자금을 조달하는 데 동의한다. 다음으로, 차용자(850)는 단계(866)에서 암호화폐 또는 토큰을 담보 계약(868)에 담보로 예치한다. 대출자(854)는 단계 870에서 대출금에 자금을 조달한다. 대출 금액은 단계 872에서 차용자에게 게시된다. 차용자(850)가 단계 876에 표시된 대로 대출금을 상환하지 못하는 경우, 담보는 단계 874에서 대출자에게 게시된다.
이제 도 17을 참조하여, 물리적 자산을 담보로 대출하는 프로세스 흐름이 더 자세히 설명된다. 차용자(902)는 단계 858에서 요청 금액 및 대출 조건을 사용하여 대출 플랫폼(904)에 대출 요청을 생성한다. 대출 플랫폼(904)은 대출 계약(910)을 생성하고 단계 912에서 대출자에 대출 요청을 게시한다. 대출자(906)은 단계 914에서 대출 자금을 조달하는 데 동의한다. 다음으로, 차용자(902)는 단계 916에서 물리적 자산(예: 금, 다이아몬드 또는 부동산 소유권)을 제3자(900)에게 이전한다. 단계 918에서 제3자(900)는 자산을 토큰화하고 토큰을 차용자에게 이체한다. 차용자(902)는 단계 920에서 이러한 토큰을 담보 계약(922)의 대출 플랫폼(904)에 담보로 예치한다. 대출자(906)은 단계 924에서 대출금에 자금을 조달한다. 대출 금액은 단계 926에서 차용자에게 릴리스된다. 차용자는 단계 931에서 대출 플랫폼(904)에 대출금을 상환하고, 단계(930)에서 자금은 대출자(906)에 릴리스된다. 대출 상환이 완료되면 대출 플랫폼(904)은 단계 932에서 담보(토큰)를 차용자(902)에게 릴리스한다. 다음으로, 차용자(902)는 단계 934에서 토큰을 제3자(900)에게 이체한다. 그러면 제3자(900)는 단계 936에서 물리적 자산을 차용자(902)에게 반환한다.
이제 도 18을 참조하여, nCash 코인 구매 및 판매에 관련된 18가지 거래 수수료에 대해 자세히 설명한다. nCash 코인은 신용/직불 카드(950) 또는 ACH 은행 이체(952)를 사용하여 명목화폐(예: USD)로 지불하거나 암호화폐(954)(비트코인, 이더리움)로 지불하여 구입할 수 있다. 신용/직불 카드(960), ACH 은행 송금(앱을 통한 자동화(962) 또는 수동(964)) 또는 암호화폐(970)를 통해 코인을 구매하는 데에는 다양한 거래 수수료가 있다. nCash 네트워크 956 간의 거래(다른 사용자나 판매자에게 코인 보내기 등)의 경우 거래 수수료가 발생하지 않는다. 연결된 은행계좌(958)로 코인을 판매하고 인출하기 위하여, 앱(866)을 통한 자동 거래(866) 또는 수동 거래(968)에 대한 거래수수료가 수반된다.
이제 도 19를 참조하여, 대출 플랫폼과 관련된 스마트 계약과 차용자와 대출자와 스마트 계약의 상호 작용이 더 자세히 설명된다. 신원 스마트 계약(1012)은 블록체인 계좌를 차용자(1000) 또는 대출자(1002)의 계좌와 같은 실제 사용자에 연결하는 데 사용된다. 단계 1004에서 차용자(1000)가 제공한 신원 정보는 원본 또는 해싱된 형태로 신원 스마트 계약(1012)에 기록된다. 마찬가지로 단계 1020에서 대출자(1002)에 의해 제공된 신원 정보는 원본 또는 해시된 형태로 신원 스마트 계약(1012)에 기록된다. 신용 등급 및 평판 스마트 계약(1014)은 차용자(1000)의 신용 점수 및 평판을 추적하는 데 사용된다. 차용자(1000)의 신용 점수는 단계 1006에서 기록되고 각각의 새로운 대출 요청, 대출 상환 또는 대출 불이행 시 업데이트된다. 담보 스마트 계약(1016)은 토큰화된 형태로 표현될 수 있는 암호화폐 토큰 또는 물리적 자산과 같은 담보의 잠금 및 릴리스를 관리하는 데 사용된다. 차용자(1000)는 단계 1008에서 담보 토큰을 담보 스마트 계약(1016)에 예치한다. 대출 스마트 계약(1018)은 대출 조건을 시행하고 대출 릴리스, 상환 또는 연장을 관리하는 데 사용된다. 대출자의 1000건의 대출 요청, 대출금 수령 또는 대출 상환 완료와 관련된 정보는 대출 스마트 계약(1018)에 기록된다. 마찬가지로, 대출자(1002)의 대출 제안, 대출 지불 완료 또는 대출 상환 수령과 관련된 정보는 대출 스마트 계약(1018)에 기록된다. 스마트 계약(1012, 1014, 1016 및 1018)은 블록체인 네트워크(1026)에 배포된다.
이제 도 20을 참조하여, 스마트 계약을 사용하여 캐시백 및 할인을 발행하는 프로세스를 더 자세히 설명한다. 고객(1050)은 단계 1052에서 캐시백 또는 할인 조건에 맞는 쿠폰 코드를 사용하여 판매자와 거래를 한다. 단계 1056에서 인센티브 스마트 계약(1054)은 그에 포함된 캐시백 또는 할인 규칙을 확인하고 거래가 캐시백 또는 할인 기준을 충족하는 경우 캐시백 또는 할인을 트리거한다. 캐시백이나 할인이 실행되면 토큰 계약(1058)이 업데이트되고 토큰이 판매자 계좌에서 고객 계좌로 전송된다. 고객(1050)은 단계 1060에서 캐시백 또는 할인 알림을 수신한다. 스마트 계약(1054 및 1058)은 단계 1062에서 블록체인 네트워크(1064)에 배포된다.
이제 도 21을 참조하여, P2P2P(Peer-to-Pool-to-Peer) 대출 모델의 예시를 더 자세히 설명한다. 대출자(1100, 1102, 1104)는 조건에 따라 대출자 풀(1108)에 기여한다. 대출자가 돈을 빌려주는 조건에는 대출 금액, 대출 기간, 예상 수익 및 대출 결제 날짜가 포함될 수 있다. 대출은 조건에 따라 대출자 풀(1108)로부터 분배된다. 차용자(1118, 1120, 1122)는 대출 플랫폼(1110)을 통해 대출자 풀(1108)로부터 차용자의 요청(1114)을 제출할 수 있다. 각 차용자 요청에는 차용자의 대출 조건이 포함될 수 있다. 돈을 빌리는 차용자의 조건에는 차용 금액, 대출 기간 및 허용되는 금리가 포함될 수 있다.
대출 플랫폼(1110)의 매칭 엔진(1112)은 스마트 계약(1116)을 사용하여 높은 레벨(풀 레벨) 및 낮은 레벨(차용자 및 대출자) 제약 조건이 충족되도록 보장한다. 돈을 빌리려는 차용자의 요청은 스마트 계약(1116)을 사용하여 대출자(1100, 1102, 1104) 및 대출 풀(1108)의 조건에 자동으로 매칭된다. 각 대출자 풀(풀(1108)과 같은)은 풀 레벨 동작, 대출자(1100, 1102, 1104)에 대한 다양한 기간 및 예상 수익과 같은 조건 및 풀(1108)을 나가는 대출자를 새로운 대출자로 대체하는 것을 제어하는 대출 플랫폼(1110)의 스마트 계약(스마트 계약(1124)과 같은)으로 표시되는데, 왜냐하면 풀(1108)에 대한 대출자 중 일부는 상이한 기간을 가질 수 있고 그들은 나가서 새로운 대출자로 대체될 것이기 때문이다. 대출은 조건에 따라 대출자 풀(1108)로부터 분배된다.
P2P2P(Peer-to-Pool-to-Peer) 대출 모델은 기존 P2P(Peer-to-Peer) 대출 모델보다 더 효율적이며, 특히 대출을 원하는 대출자/투자자가 많은 경우 더욱 효율적이다. 각 대출자/투자자는 서로 다른 금액을 기여하고, 받고 싶은 최소 금리와 대출 금액을 지정한다. 마찬가지로, 차용자는 차입할 금액, 기간 및 허용 가능한 금리와 같은 유사한 조건을 지정한다. P2P2P 대출 모델에서 대출자의 돈은 하나의 대출 풀에 모인 다음 여러 대출자에게 빌려주는 반면, 스마트 계약은 대출자에 대한 지불금과 대출자에 대한 지불을 보장하는 반면 일부 대출자가 존재하고 일부 대출자의 회수가 이루어진다. 이는 대출에 사용되는 자금의 "풀"을 허용하는 반면, 낮은 레벨의 스마트 계약에서는 모든 하위 계약이 유지되도록 보장한다. 대출자와 차용자의 기여금(contribution) 및 인출이 지속적으로 발생하는 반면, 새로운 대출자와 차용자가 합류하거나 다른 사람들이 떠날 때 풀은 계속 활성화된다. 대출자는 N 대출에 대출을 하게 될 수 있고, 차용자는 P 대출자만 활성화된 기간(M>N 및 M>P) 동안 M 대출자로부터 대출을 받을 수 있다. 따라서 스마트 계약은 기록의 통합성(intergrity)을 유지하는 데 중요하다. P2P2P 대출 모델에서 풀의 거래는 블록체인 내부 피어 간의 하위 레벨 거래를 병합한다.
또한, 본 시스템 및 본원에 개시된 다른 시스템을 이용하여 다양한 대출이 실행될 수 있다는 것이 본 발명의 범위 내에 포함되는 것으로 고려되고 포함된다. 차용자가 요청하고 대출자가 제공하는 대출 유형에는 일반적으로 은행에서 제공하는 것과 같은 고액 대출이 포함될 수 있지만 판매자 터미널에서 수행되는 개인 소비자 거래(예: 소비재, 식료품 등의 구매를 위한 통상적인 일상 거래)를 포함한 소액 대출도 포함될 수 있다. 또한, 대출 요청은 암호화폐 요청, 향후 거래에 대한 신용, 가치가 있는 토큰 교환 등과 같은 명목화폐 외에 다른 가치 이전의 형태를 취할 수도 있다.
추가로, 대출 금액을 포함하는 대출이 고려되는 반면, 다른 유형의 금융 증권도 고려되고 본 발명의 범위 내에 포함된다. 보다 구체적으로, 증권 제공(security offer)은 제안자로부터 수신되고 제안 조건을 포함할 수 있으며, 증권 판매자 요청은 판매자로부터 수신되고 판매자 조건을 포함할 수 있다. 증권 제공은 증권 제공 스마트 계약에 기록될 수 있으며, 증권 제공 풀 스마트 계약에 기록되어 대출 풀과 마찬가지로 증권 제공 풀을 정의할 수 있다. 증권 제공의 조건은 증권 제공 풀 조건을 정의할 수 있다. 증권 판매자의 조건은 증권 제공 풀 조건과 비교될 수 있으며, 증권 판매자 조건이 증권 제공 풀 조건에 속한다고 판단되면 증권 판매자 요청 스마트 계약이 증권 제공 풀 스마트 계약에 기록될 수 있다.
이러한 증권에는 옵션 계약이 포함되나 이에 국한되지 않는다. 그러한 구현예들에서, 구매자 옵션은 구매자 옵션 스마트 계약에 수신되어 기록될 수 있으며, 이는 구매자 옵션 스마트 계약과 관련된 자산의 지정, 관련 자산의 수량, 만료일, 거래 유형(예: 해당 분야에 알려진 콜(call) 또는 풋(put)) 및/또는 자산의 행사 가격 또는 행사 가격 범위 중 적어도 하나를 포함할 수 있는 적어도 하나의 제공 조건을 포함할 수 있다. 이러한 구매자 옵션 스마트 계약은 위에서 설명한 대출자 스마트 계약 기록과 유사하게 블록체인 네트워크에 기록될 수 있다. 마찬가지로 판매자 옵션은 스마트 계약에 수신되어 기록될 수 있으며 구매자 옵션과 동일한 필드로 구성될 수 있으며 판매자는 행사 시 관련 자산을 교환 통화, 명목화폐 또는 암호화폐로 행사 가격으로 판매할 의무가 있다. 콜 만기일의 가격을 정하거나 풋(put) 만기일에 명목화폐 또는 암호화폐 통화를 사용하여 행사 가격으로 관련 자산을 구매한다.
또한 증권 제공을 수신하고 해석하여 해당 유형(예: 대출, 제안 등)을 결정할 수 있으며 결정된 증권 제공 유형은 관련 증권 제공 스마트 계약에 기록된다. 유사하게, 증권 판매자 요청이 수신되고 그 유형이 결정될 수 있으며, 결정된 증권 판매자 유형은 관련 증권 판매자 스마트 계약에 기록된다. 증권 제공 유형 표시 및 증권 판매자 요청은 각각의 관련 증권 제공 스마트 계약 및 증권 판매자 요청 스마트 계약에 기록될 수 있다.
이제 도 22를 참조하여, 대출 풀 스마트 계약을 생성하기 위한 대출 풀 생성기의 예시가 더 자세히 설명된다. 각 대출자(1200, 1202, 1204)는 대출할 금액, 대출 기간 및 예상 수익을 포함한 조건으로 대출 풀에 기여(1206)한다. 대출자(1200, 1202, 1204)는 서로 다른 조건을 가질 수 있으며 하나 이상의 대출 풀에 기여할 수 있다. 대출 풀 스마트 계약 생성기(1208)는 대출 풀을 나타내는 스마트 계약(1210, 1212, 1214)을 생성하는 데 사용된다.
이제 도 23을 참조하여, 차용자를 대출 풀에 매칭하기 위한 매칭 엔진의 예시가 더 자세히 설명된다. 각 차용자(1250, 1252, 1254, 1256)는 빌릴 금액, 돈을 빌릴 기간 및 허용 가능한 금리를 포함한 조건으로 돈을 요청한다. 매칭 엔진(1258)은 차용자 레벨 및 풀 레벨 조건이 충족되도록 차용자(1250, 1252, 1254, 1256)를 대출 풀 스마트 계약(1260, 1262, 1264)과 일치시킨다. 차용자(1250, 1252, 1254, 1256)는 하나 이상의 대출 풀에 매칭될 수 있다.
이제 도 24를 참조하여, 오라클을 사용하여 대출 풀 계약에 외부 데이터를 공급하는 방법이 더 자세히 설명된다. 대출 풀 및 관련 스마트 계약(1304)은 블록체인 네트워크(1306)에 배포된다. 오라클(1302)은 대출 풀 스마트 계약에 외부 또는 동적 정보(예: 환율, 담보의 시장 가치)를 제공하는 데 사용된다. 오라클(1302)은 이러한 정보를 외부 소스 및 웹(1300)으로부터 획득할 수 있다.
이제 도 25를 참조하여, 대출 풀을 위한 채널 및 트리거의 그림이 더 자세히 설명된다. 대출자(1320)를 포함하고 차용자(1330)에게 배포하는 대출 풀(1324, 1326, 1328)은 외부 트리거(1322)에 기초하여 풀 간의 풀 자금 전송을 위해 그들 사이에 채널(1332, 1334)을 가질 수 있다. 풀의 성능이 좋지 않고 높은 레벨(풀 레벨) 및 낮은 레벨(대출자 및 차용자 레벨) 제약 조건이 충족되지 않는 경우 한 풀에서 다른 풀로 자금을 이동해야 할 수 있다. P2P2P 대출 플랫폼은 각 대출 풀의 성과를 모니터링하고 한 풀에서 다른 풀로 자금을 이전하기 위한 트리거를 생성할 수 있다.
이제 도 26을 참조하여, 대출 풀과 관련된 스마트 계약이 더 자세히 설명된다. 각각의 대출자(1352)은 대출 풀(1350)의 개별 스마트 계약(1358)으로 표현된다. 마찬가지로, 각 차용자(1354)는 대출 풀(1350)의 개별 스마트 계약(1360)으로 표시된다. 대출자 스마트 계약(1358)은 대출 풀 계약(1356)을 통해 대출자(1352)를 대출 풀(1350)에 연결한다. 차용자 스마트 계약(1360)은 대출 풀 계약(1356)을 통해 차용자(1354)를 풀 대출(1350)에 연결한다. 블록체인 기반 P2P 대출 솔루션에 사용되는 전통적인 스마트 계약과 같이 대출자(1352)와 차용자(1354) 사이에는 직접적인 링크가 없다.
현재 대출 계획(특히 컴퓨터로 구현된 대출 계획 또는 블록체인 기반 P2P 대출 계획)에서, 대출 풀에 다수의 투자자가 있고 각각 투자하고 싶은 투자 금액, 그들이 받고 싶은 대출 금리를 기간(예: 3개월에 걸쳐 2.3% 또는 6개월에 걸쳐 2.2%)과 다양한 출구 전략과 조합하여 지정하고, 다수의 차용자가 다양한 조건과 상환 기간 및 조기 상환 옵션을 지정하는 경우, 다음과 같은 문제가 생긴다:
다수의 액티브(active) 및 패시브(passive) 투자자가 풀에 들어오고 나가는 경우 수동(manual) 조정이 불가능하다;
확장 가능하고 안전한 솔루션은 불가능하다.
대출 풀에서 "연결된(linked)" 스마트 계약을 통해 대출자와 차용자를 추출하면 수동 조정 및 확장성 문제가 해결된다. 또한 이 접근 방식은 다음과 같은 이점을 제공한다:
신용이 좋은 차용자는 더 좋은 이율로 돈을 빌릴 수 있고, 빌린 돈을 더 높은 이율로 신용이 나쁜 다른 차용자에게 빌려줄 수 있다;
특정 금리로 차용하거나 대출하여 주고 이러한 파생상품을 거래용으로 제공하는 옵션을 통해 원활한 대출 환경을 조성할 수 있다.
이제 도 27을 참조하여, 다수의 대출 풀을 포함하는 PoP(pool-of-pools)의 예시가 더 자세히 설명된다. 여러 대출 풀을 함께 묶어 PoP를 만들 수 있다. PoP 접근 방식은 차용자와 대출자가 계속해서 들어오고 나가고 높은 레벨(풀 레벨) 및 낮은 레벨(대출자 및 차용자 레벨) 제약 조건을 충족하기 어려운 변동성이 높은 풀에 유용하다. 여러 풀을 하나의 풀로 결합하면 P2P2P 대출 플랫폼에 안정성이 제공된다. PoP 접근 방식은 PoP(1400)과 각각 상호 작용하는 복수의 대출 풀(1402, 1404, 1406, 1408)을 포함할 수 있다. 복수의 대출 풀(1402, 1404, 1406, 1408) 각각은 각자의 차용자(1412, 1420, 1424, 1428)와의 차용자 스마트 계약 및 각자의 대출자(1410, 1418, 1422, 1426)와의 대출자 스마트 계약을 포함할 수 있다. 추가적으로, 일부 차용자(1416) 및 대출자(1414)는 PoP(1400)의 풀과 직접 상호 작용할 수 있다.
이제 도 28을 참조하여, 대출 풀 스마트 계약 구조 및 거래에 대한 설명이 더 자세히 설명된다. 계약 소유자(또는 대출 플랫폼)(1522)는 대출 풀 계약(1500)을 생성하고 소유한다(1520). 대출 풀 계약(1500)은 계약 생성 거래(1510)가 EOA(1518)에 의해 수행되어 대출 풀 계약(1500)이 생성(1502) 될 때 계약 소유자(또는 대출 플랫폼)(1522)의 외부 소유 계좌(EOA)(1518)로부터 생성된다. 대출자(1524)은 EOA(1528)를 사용하여 거래(1532)를 대출 풀 계약(1500)으로 보낸다. 대출자(1524)은 JoinPool 거래(1514)를 전송하여 대출 풀에 가입(1506) 할 수 있다. 차용자(1526)는 자신의 EOA(1530)를 사용하여 거래(1534)를 대출 풀 계약(1500)으로 보낸다. 차용자(1526)는 대출상환(repayLoan) 거래(1516)를 전송함으로써 대출 풀에서 가져온 대출금(1508)을 상환할 수 있다.
이제 도 29를 참조하여, 위험과 수익에 기초한 대출 풀의 예시적인 분류가 더 자세히 설명된다. 대출 풀은 위험과 수익에 따라 분류된다. 위험이 낮은 대출 풀은 수익률이 낮고 위험이 높은 대출 풀은 수익률이 높다. 대출 풀의 위험 레벨은 풀에 연결된 차용자 및 대출자의 평판과 신용 점수를 기반으로 계산된다. 신용 점수가 높은 차용자에게 돈을 빌려주는 풀은 일반적으로 이러한 대출이 안전한 것으로 간주되므로 낮은 금리로 빌려준다. 마찬가지로 신용 점수가 낮은 차용자에게 돈을 빌려주는 풀은 일반적으로 이러한 대출이 위험한 것으로 간주되므로 높은 금리로 빌려준다. 일부 구현예들에서, 대출 위험은 낮음, 중간 및 높음으로 분류될 수 있으며, 수익도 낮음, 중간 및 높음으로 특성화될 수 있다. 이로 인해 저위험-고수익(1600), 중간 위험-고수익(1602), 고위험-고수익(1604), 저위험-중수익(1608), 중간 위험-중수익(1618), 고위험-중수익(1620)의 위험 -보상 카테고리가 발생할 수 있다. 낮은 위험-낮은 수익(1612), 중간 위험-낮은 수익(1614) 및 높은 위험-낮은 수익(1616). 대부분의 대출 풀은 저위험-저수익(1612), 저위험-중수익(1608), 중간 위험-중수익(1618), 중간 위험-고수익(1602), 고위험-고수익(1604) 중 하나에 속한다.
이제 도 30을 참조하여, 상호운용 가능한 로얄티 포인트를 갖는 판매자 동맹의 예시가 더 자세히 설명된다. 고객(1150, 1152)은 nCash를 이용하여 판매자 매장(1156)에서 결제(1154)를 한다. 판매자 지불은 nCash 네트워크(1160)에 의해 처리된다(1158). 고객은 제휴 또는 네트워크 내의 모든 판매자나 제휴 판매자에서 근무하는 로열티 포인트를 받는다(1156). 이러한 로얄티 포인트는 동맹(alliance) 내 모든 판매자 간에 상호 운용 가능하며 다음 구매 시 할인에 적용될 수 있다.
이제 도 31을 참조하여, 분산형 메시징 프레임워크의 예시를 더 자세히 설명한다. 본원에 설명된 분산 게시-구독 메시징 프레임워크를 게시판 메시징 프레임워크(BBMF) 또는 "게시판"이라고 한다. 게시판 서버(1678)는 토픽(1680, 1682)을 관리한다. 게시판 클라이언트는 게시자/제조자 클라이언트(1670, 1672) 또는 소비자/구독자 클라이언트(1688, 1690) 일 수 있다. 게시자/제조자 클라이언트(1670, 1672)는 토픽(1680, 1682)에 데이터 또는 메시지를 게시한다. 게시자/제조자 클라이언트(1670, 1672)에서 토픽(1680, 1682)로 푸시된 데이터는 데이터 소스(1650)에서 유래할 수 있으며, 이는 스마트 계약(1652), 오라클(1654), 로그(1656), 센서(1658), 레코드(1660), 데이터베이스(1662), 스트림(1664) 및 이벤트(1668)를 포함할 수 있다. 소비자/구독자 클라이언트(1688, 1690)는 게시판 서버(Bulletin Board Server)(1678)로부터 메시지(1684, 1686)를 수신하여 토픽(1680, 1682)의 데이터를 소비한다. 게시판 서버(1678)는 메시지를 저장하고 재생할 수 있는 플러그인 메시지 저장소 백엔드(plug-in Message Storage Backend)(1692)를 지원한다. 상기 메시지 저장소 백엔드(1692)는 두 가지 옵션, 즉(1) 클라우드 데이터베이스 또는 클라우드 저장소(1694),(2) 메시지 해시를 블록체인(1696)에 정기적으로 검사하는 분산형 저장소 플랫폼(예: IPFS 또는 Swarm)(1698)을 사용하여 메시지를 유지한다. 게시판의 메시지는 임시 또는 영구 메시지일 수 있다. 임시 메시지는 메시지 저장소 백엔드에 저장되지 않는다. 지속성 메시지의 경우 TTL(Time-to-Live)을 지정할 수 있다. 제조자와 소비자는 HTTP-REST 또는 이더리움(Ethereum)용 Web3와 같은 클라우드 및 블록체인 프로토콜을 모두 지원한다. 이를 통해 기존 스마트 계약(예: Solidity 스마트 계약)이 게시판에 데이터를 게시하고 사용할 수 있으며, 기존 오라클은 게시판을 통해 웹에서 스마트 계약으로 데이터를 공급할 수 있다. 예를 들어 Solidity 언어로 구현된 스마트 계약은 게시자 클라이언트에 의해 게시판 서버에 게시되는 Solidity 이벤트 형식으로 알림을 생성하는 데이터 소스이다. Solidity 스마트 계약은 게시판에 메시지를 게시하기 위해 외부 게시자 클라이언트가 필요하다. 외부 게시자 클라이언트 없이도 데이터를 게시할 수 있는 게시판 API를 지원하기 위해 Solidity와 같은 스마트 계약 언어에 대한 확장을 구현할 수 있다. 이러한 확장 및/또는 스텁(stub)은 게시판에 대한 인터페이스를 구현하기 위한 적합한 코드를 생성하기 위해 전처리기(pre-processor)에 의해 사전-처리될 수 있는 프라그마(pragma) 지시어를 사용하거나 전역 변수 네임을 지원하기 위해 언어 자체에 대한 확장을 포함할 수 있다. 토픽은 나중에 메시지 저장소 백엔드(1692)에 저장되는 디스크의 정기적인 스냅샷을 통해 메모리 내에서 관리된다. 스냅샷의 메시지를 메시지 저장소 백엔드 1692(클라우드 및/또는 블록체인)로 이동하기 위한 압축 프로세스가 정의된다. 게시판 자체는 부분적으로 클라우드 기반 서비스 및/또는 블록체인을 사용하여 구현될 수 있으며 높은 처리량과 짧은 대기 시간 서비스를 제공하기 위해 하드웨어 가속기(예: ASIC 또는 FPGA) 및 그래픽 처리 장치(GPU)도 포함할 수 있다. 시스템 오류나 해킹 공격으로부터 저장된 메시지와 값을 보호하기 위해 클라우드 및 인터넷 네트워크에 대한 알려진 기술을 사용하여 추가 중복성, 인증 및 암호화 레이어가 하드웨어 및 소프트웨어에 제공될 수도 있다.
BBMF는 높은 처리량과 낮은 대기 시간의 메시징을 위해 설계되었다. 게시판 서버(1678)는 클라우드 컴퓨팅 환경에 배치될 수 있으며 수요에 따라 수직 또는 수평으로 확장될 수 있다. 수직 확장에서는 게시판 서버에 더 큰 가상 머신 인스턴스 크기(컴퓨팅 용량, 메모리 및 스토리지 측면에서)가 사용된다. 수평 확장에서는 게시판 서버의 여러 인스턴스가 실행되어 각 인스턴스가 게시판에서 관리하는 토픽의 서브세트(subset)를 관리한다.
BBMF는 푸시/풀 및 게시/구독 데이터 수집 모델과 데이터 전달 모델을 모두 지원한다. 또한, 데이터 전달은 최소 1회 전달 또는 정확히 1회 전달일 수 있다. BBMF는 클라우드 기반 또는 로컬로 컨피겨레이션된 컴퓨팅 시스템의 일부로 서버, ASIC/FPGA 및 GPU의 조합을 사용하여 하드웨어 및 소프트웨어로 구현될 수 있다.
게시판은 분산형 메시징 프레임워크이므로 일관성과 가용성 간에 절충(trade-off)이 존재한다. 이러한 절충은 파티셔닝(partitioning) 하에서 분산형 데이터 시스템이 일관성이 있거나 사용 가능하지만 동시에 두 가지 모두를 사용할 수는 없다는 CAP 정리로 설명된다. 게시판(Bulletin Board)은 궁극적으로 일관된 모델을 채택한다. 최종적 일관성 시스템에서는 작성자가 업데이트 작업을 수행한 후 결국 모든 판독기에서 이를 볼 수 있다. 소비자가 읽기 작업을 수행할 때 최근 완료된 쓰기 작업의 결과가 응답에 반영되지 않을 수 있다.
게시판 메시징 프레임워크는 우선순위에 따른 메시지 처리를 지원한다. 메시지 헤더 필드에서 우선순위를 설정할 수 있다. 메시지의 다양한 우선순위 클래스를 우선순위 헤더 필드에 정의하고 지정할 수 있다. 이러한 메시지 우선순위 분류는 대출 시스템에서 연결된 스마트 계약에 많은 수의 업데이트를 전파해야 하는 P2P2P(Peer-to-Pool-Peer) 대출 시스템에 매우 중요하다.
이제 도 32를 참조하여, 게시-구독 메시징 프레임워크에서 지원되는 소비자/구독자 작업에 대한 설명이 더 자세히 설명된다. 소비자 또는 구독자(1708)를 위해 다양한 액션 규칙 및 트리거(1710) 및 액션(1712)이 정의될 수 있다. 규칙 및 트리거(1712)는 데이터를 분류하고 선택하며 작업을 트리거하는 방법을 지정한다. 지원되는 동작(1716)은 스마트 계약 거래(1718), 웹후크 트리거(Webhook Trigger)(1720), 외부 데이터 저장소에 로그(1722), 이메일 알림(1724), SMS 알림(1726) 및 모바일 푸시 알림(1728)을 포함한다. 게시판 서버(1700)에 의해 관리되는 토픽(1702, 1704) 중 하나와 관련된 규칙과 매칭되는 메시지(1706)가 게시판 서버(1700)로부터 게시판 서버(1700)로부터 수신되면(예를 들어 온도 > 60 또는 ETH 가격 < $500) 작업이 수행된다. 메시지는 HTTP/REST 애플리케이션 및 WebSocket을 포함하지만 이에 국한되지 않는 본 기술 분야에 알려진 임의의 수단 또는 방법에 의해 소비자 또는 구독자 클라이언트(1708)로 전송될 수 있다. 스마트 계약 거래 작업은 대출 조건 변경을 알리는 메시지가 수신될 때 다수의 연결된 스마트 계약(예: 대출 풀의 스마트 계약)이 실행될 수 있는 위에서 설명한 P2P2P 대출 시스템에 특히 유용하다.
이제 도 33을 참조하여, 게시-구독 메시징 프레임워크에 메시지를 게시하기 위해 외부 게시자 클라이언트를 사용하는 스마트 계약 데이터 소스의 그림이 더 자세히 설명된다. Solidity 스마트 계약과 같은 스마트 계약 데이터 소스(1800)는 알림 또는 이벤트(1802)를 생성한다. 게시자/제조자 클라이언트(1804)는 스마트 계약(1800)에 의해 생성된 알림 또는 이벤트를 감시한다. 알림이나 이벤트가 생성되면 메시지는 게시판(1808)에 의해 관리되는 토픽(1810, 1812)에 게시(1806)된다. 이러한 메시지는 토픽(1810, 1812)을 구독한 소비자/구독자 클라이언트(1816)에게 전달(1814) 된다. 소비자/구독자 클라이언트(1816)는 메시지 수신 시 연결된 스마트 계약(1822, 1824)에 거래(1818, 1820)을 전송하도록 컨피겨게이션된 스마트 계약 거래 액션(action)을 갖는다.
이제 도 34를 참조하여, 게시-구독 메시징 프레임워크에 메시지를 게시하기 위해 통합 게시자 클라이언트를 사용하는 스마트 계약 데이터 소스의 그림이 더 자세히 설명된다. 통합 게시자/제조자 클라이언트(1850)를 갖춘 스마트 계약 데이터 소스는 알림(notification) 또는 이벤트를 생성한다. 알림 또는 이벤트는 게시판(1854)에 의해 관리되는 토픽(1856, 1858)에 메시지(1852)로 게시된다. 이러한 메시지는 토픽(1856, 1858)을 구독한 소비자/구독자 클라이언트(1862) 에게 전달(1860) 된다. 소비자/구독자 클라이언트(1862)는 메시지 수신 시 연결된 스마트 계약(1868, 1870)에 거래(1864, 1866)을 전송하도록 구성된 스마트 계약 거래 액션을 갖는다.
이제 도 35를 참조하여, 게시-구독 메시징 프레임워크에 대한 메시지 형식의 예시가 더 자세히 설명된다. 메시지 유형 필드(1750)는 메시지 유형을 정의한다. 게시판 프레임워크에서 지원되는 메시지 유형은 다음과 같다:
CONNECT: CONNECT 메시지는 클라이언트(제조자 또는 소비자)가 서버에 연결하기 위해 전송한다;
DISCONNECT: 클라이언트가 서버와의 연결을 끊기 위해 DISCONNECT 메시지를 보낸다.
PUBLISH: 새 메시지를 게시하는 데 사용된다;
SUBSCRIBE : 게시판에서 관리하는 토픽을 구독하기 위해 사용된다;
UNSUBSCRIBE: 토픽 구독을 취소하는 데 사용된다;
PINGREQUEST: 서버에 핑(ping) 요청을 보내는 데 사용된다;
PINGRESPONSE: 핑 요청에 응답하는 데 사용된다;
DATAREQUEST: 메시지나 데이터 항목을 요청하는 데 사용된다;
DATARESPONSE: 메시지나 데이터 항목에 대한 요청에 응답하는 데 사용된다.
데이터 페이로드(Data Payload) 필드(1752)는 JSON 데이터 페이로드로서 메시지를 포함한다. 상기 메시지는 보낸 사람이 서명하거나 암호화할 수 있다. 토픽 필드(1754)는 상기 메시지가 게시되는 토픽 목록을 포함한다. 헤더 필드(1756)는 다음과 같은 헤더를 포함한다:
발신자 또는 수신자 신원
메시지 서명
QoS 레벨
우선 사항
지속성 또는 임시 메시지
메시지 프로세싱에 도움이 되는 추가 플래그.
TTL(Time-to-Live) 필드(1758)는 메시지의 유효성 또는 수명을 지정하는 데 사용된다. 난스(Nonce) 필드(1760)는 메시지 작성 시 주어진 작업량이 수행되었음을 증명하는 데 사용할 수 있는 정수 값이다.
이제 도 36을 참조하여, 게시-구독 메시징 프레임워크의 블록체인 체크포인팅 접근 방식이 더 자세히 설명된다. 블록체인 및 분산형 저장소 플랫폼(IPFS 또는 Swarm) 기반 메시지 저장소 백엔드를 사용하는 경우 메시지(1780)는 해시되고(1782) 머클 트리(Merkle Tree)(1784)에 추가된다. 머클 트리(1784)의 루트 해시(root hash)(1786)(N개의 메시지마다)가 블록체인(1788)에 기록된다. 이렇게 하면 나중에 메시지가 변조될 수 없다.
이제 도 37을 참조하여, 게시-구독 메시징 프레임워크의 소비자에 의해 업데이트되는 전역 변수 네임 시스템의 예시가 더 자세히 설명된다. 전역 변수 네임 시스템(GVNS)(1916)은 전역 변수의 기록과 전역 변수에 대한 소유자 및 리졸버를 유지한다. 스마트 계약, 오라클, 로그, 센서, 기록, 데이터베이스, 스트림 또는 이벤트와 같은 데이터 소스(1900)는 게시자/제조자 클라이언트(1902)로 전송되는 데이터 또는 알림을 생성한다. 게시자/제조자 클라이언트(1902)는 게시판 서버(1906)에 의해 관리되는 하나 이상의 토픽(1908, 1910)에 메시지(1904)로서 데이터 또는 알림을 게시한다. 소비자/구독자 클라이언트(1914)는 메시지(1912)를 수신하고 GVNS(1916)에 등록된 전역 변수의 값을 업데이트한다. 스마트 계약(1918, 1920, 1922) 은 GVNS(1916)에 등록된 전역 변수를 참조한다.
이제 도 38을 참조하여, 전역 변수 네임 시스템의 아키텍처가 더 자세히 설명된다. 전역 변수 네임 시스템(GVNS)(1950)은 레지스트라(Registrar)(1952), 레지스트리(Registry)(1954) 및 리졸버(Resolver)(1956) 구성 요소를 포함한다. 1952 레지스트라(1952)는 새로운 변수 네임을 등록하고, 변수 네임에 대한 리졸버를 업데이트하고, 변수의 소유권을 이전하는 일을 담당한다. 레지스트리(1954)는 변수 네임의 소유자와 리졸버를 기록하고 변수 네임에 대한 리졸버를 반환하는 일을 담당한다. 리졸버(1956)는 변수 네임을 값(value)으로 리졸브하고 등록된 변수의 값을 업데이트하는 역할을 담당한다. GVNS(1950)에 전역 변수를 등록하고, 변수를 업데이트하고, 변수의 현재 값을 검색하는 단계는 다음과 같다. 단계 1(1958)에서 사용자(1980)는(외부 소유 계좌(1978) 또는 스마트 계약(1976)을 통해) 새로운 전역 변수 네임(예: ncash.supply)을 레지스트라(1952)에 등록하라는 요청을 보낸다. 단계 2(1960)에서 레지스트라(1952)는 레지스트리(1954)의 변수에 대한 소유자 및 리졸버를 설정한다. 단계 3(1970)에서 소비자/구독자 클라이언트(1972) 또는 스마트 계약(1974)은 전역 변수의 값을 업데이트하라는 요청을 리졸버(1956)에 보낸다. 단계 4(1962)에서 스마트 계약(1966)은 레지스트리(1954) 로부터 전역 변수의 값을 요청한다. 단계 5(1964)에서, 레지스트리(1954)는 변수에 대한 리졸버(1956)를 검색한다. 단계 6(1968)에서 리졸버(1956)는 전역 변수의 값을 반환한다.
이제 도 39를 참조하여, 스마트 계약 전반에 걸친 전역 변수 공유에 대한 그림이 더 자세히 설명된다. 대출 풀 스마트 계약(2004), 대출 요청 스마트 계약(2002) 및 대출 스마트 계약(2006)은 대출 작성 및 대출 서비스 프로세스에 사용되는 P2P2P(Peer-to-Pool-Peer) 대출 시스템의 연결된 스마트 계약이다. 대출 요청 스마트 계약(2002)는 대출 과정에서 사용된다. 차용자는 대출 시스템에 대출 요청을 보내고 각 대출 요청에 대해 대출 요청 스마트 계약이 생성된다. 대출 풀 스마트 계약(2004)는 대출 풀을 관리하는 데 사용된다. 대출 시스템이 대출 요청을 대출 풀에 일치시키면 새로운 대출 스마트 계약(2006)이 생성된다. 대출 스마트 계약(2006)은 대출금이 지급되는 시점부터 대출금이 상환될 때까지 대출의 대출 서비스 측면을 관리한다. 대출 스마트 계약(2006)은 대출 원금, 대출 금리, 대출이 상태 변수로 지출되는 대출 풀 계약 주소와 같은 대출 세부 정보를 캡처한다. 대출 스마트 계약 계약(2006)은 또한 상환된 대출 금액(LoanAmountRepaid) 및 대출 상태(LoanStatus)와 같은 전역 변수(2042)를 등록한다. Lending Pool 스마트 계약(2004) 및 Lending Request 스마트 계약(2002)은 전역 변수 네임 시스템(GVNS)(2000)(lendingPool_AmountRaised, lendingPool_numLenders, lendingRequest_AmountRequested)에 등록된(2010, 2008) 전역 변수 값(2022, 2012)을 갖는다. 이러한 전역 변수는 대출 스마트 계약(2006)에서(2032)로 참조된다.
각각의 스마트 계약(2002, 2004, 2006)에는, Solidity 스마트 계약 언어의 기존 요소/유형/컨스트럭트(construct)인 상태 변수(2014, 2024, 2034), 기능(2016, 2026, 2036), 모디파이어(modifier)(2018, 2028, 2038) 및 이벤트(2020, 2030, 2040)가 있다. Solidity 스마트 계약 언어 내의 GVNS 2000을 통해 여러 스마트 계약에서 공유되는 전역 변수에 대한 지원은 Solidity 언어 사양 확장을 통해 추가된다. 또한 GVNS 2000을 통해 공유되는 전역 변수에 대한 지원을 추가하기 위해 이더리움의 스마트 계약을 위한 런타임 환경인 이더리움 가상 머신(EVM, Ethereum Virtual Machine) 내에서 확장이 수행된다. Solidity와 이더리움은 블록체인에 대한 정보를 제공하는 제한된 전역 변수 세트(예: block.coinbase, block.difficulty, block.gaslimit, block.number, block.blockhash, block.timestamp, msg.data, msg.gas, msg.sender, msg.value, tx.gasprice, tx.origin, this.balance, addr.balance)에 대한 지원을 하지만, 두 개 이상의 연결된 스마트 계약이 전역 변수를 공유하는 것은 불가능하다. 전역 변수에 대한 이러한 추가 지원은 Solidity 언어 사양에 대한 확장 및 이더리움 가상 머신(EVM)에 대한 확장인 GVNS 2000을 통해 활성화된다. 전역 변수 지원은 연결된 스마트 계약(예: P2P2P 대출 시스템)이 작동하는 데 중요하다.
BBMF를 GVNS와 함께 사용하면 전역 변수 및 해당 유형의 업데이트 횟수에 대한 정보를 "분석 엔진"에 제공할 수 있고, 참조된 전역 변수 및 해당 유형에 대한 "게시 엔진"에도 정보를 제공할 수 있다.
이제 도 40을 참조하여, 게시판 게시자/제조자 클라이언트 및 소비자/구독자 클라이언트의 예시적인 구현이 더 자세히 설명된다. 게시자/제조자 클라이언트 구현에서는 게시판 클라이언트 클래스의 인스턴스(instance)가 생성된다. 클라이언트 클래스의 연결(connect)() 메소드는 게시판 서버 주소, 클라이언트 ID 및 클라이언트 비밀번호를 전달하여 게시판 서버에 대한 연결을 설정하는 데 사용된다. 클라이언트 클래스의 게시() 메소드는 게시판 서버에 메시지를 게시하는 데 사용된다. 게시판 서버에 게시된 메시지 개체에는 토픽 목록, 데이터 페이로드, 헤더, TTL(time-to-live) 및 난스(nonce) 필드가 포함되어 있다. 소비자/구독자 클라이언트 구현에서 클라이언트 클래스의 구독(subscribe)() 메소드는 게시판 서버의 모든 토픽 또는 선택된 토픽을 구독하는 데 사용된다. 새로운 메시지가 전달될 때마다 실행되는 _메시지(message)()에 대한 콜백 함수가 정의되어 있다.
이제 도 41을 참조하여, nCash 모바일 애플리케이션의 예시적인 인터페이스가 더 자세히 설명된다. 예시적인 인터페이스에는 코인 구매, 코인 보내기, 코인 받기, 판매자에게 코인 지불, 코인 판매 또는 인출, 연락처와 채팅 및 거래, 거래 목록 보기, 대출 및 설정 옵션 등의 옵션이 표시된다. 계좌번호, 네임, 계좌 잔고 등 고객의 계좌 세부정보도 표시된다.
이제 도 42를 참조하여, P2P 대출 옵션을 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스가 더 자세히 설명된다. 고객은 자신의 금융 및 교육 정보가 포함된 대출 프로필을 작성한 후 대출을 요청할 수 있다. 고객은 모바일 애플리케이션에서 nCash 신용 점수를 볼 수 있다. 차용 피어(차용자)는 새 대출 요청을 생성하고, 기존 대출 요청 상태를 보고, 대출 요청에 대해 대출 피어(대출자)로부터 받은 대출 제안을 보고, 대출을 상환할 수 있다. 대출 피어(대출자)는 네트워크의 모든 차용 피어(차용자)가 제출한 공개 대출 요청을 보고, 날짜 범위 또는 대출 요청 ID별로 특정 대출 요청을 검색하고, 대출 요청에 대한 대출 제안을 보내고, 수락된 대출 제안에 대한 자금을 릴리스할 수 있다.
이제 도 43을 참조하여, 다양한 유형의 거래를 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스가 더 자세히 설명된다. 관련된 거래 유형은 다음과 같다:
신용/직불 카드 또는 ACH 은행 송금을 통해 명목화폐(USD 등)로 결제하여 새로운 코인을 구매하는 거래
암호화폐(비트코인 등)로 결제하여 새로운 코인을 구매하는 거래
코인을 판매하고 연결된 은행계좌로 코인을 인출하는 거래
코인을 다른 사용자에게 양도하는 거래
캐시백 제안을 이용하여 받은 캐시백에 대한 거래
바우처 청구 시 받은 코인에 대한 거래.
이제 도 44를 참조하여, 채팅 및 결제 인터페이스를 보여주는 nCash 모바일 애플리케이션의 예시적인 인터페이스가 더 자세히 설명된다. 채팅 및 거래 인터페이스를 통해 두 명의 고객이 서로 채팅하고 결제를 보내거나 요청할 수 있다. 사용자가 받은 결제 요청은 채팅 및 거래 인터페이스 자체에서 승인되거나 거부될 수 있다.
이제 도 45를 참조하여, 다양한 계좌 유형에 대한 nCash 모바일 애플리케이션 기능이 설명되어 있다.
이제 도 46을 참조하여, 가상 머신에서 컨테이너로의 네트워크 기능 가상화의 전개(evolution)에 대하여 자세히 설명된다.
5G 개발은 가상화(Virtualization), 클라우드 네이티브(Cloud native), 컨테이너(Container) 및 마이크로서비스와 같은 기술에 의해 주도되고 있다. 네트워크 기능 가상화(NFV, Network Function Virtualisation)는 통신 네트워크의 가상화를 촉진하고 추진하기 위해 만들어졌다. 최근에는 가상 머신에서 컨테이너로 NFV가 전개되고 있다. 가상 네트워크 기능(VNF, Virtual Network Function)은 범용 물리적 서버에 가상화된 네트워크 기능을 구현한다. VNF(Virtual Network Function)는 NFV(Network Function Virtualization)를 기반으로 한 가상 네트워크 기능이다. 가상 머신에 배포된 VNF(가상 네트워크 기능)(3002)은 컨테이너화된 네트워크 기능(Containerized Network Function) 또는 클라우드 네이티브 네트워크 기능(CNF, Cloud-Native Network)(3012)으로 대체되고 있다. CNF는 VNF에 비해 초경량이며 휴대성과 확장성이 뛰어나다. CNF는 쿠버네티스(Kubernetes)(3016)과 같은 오픈 소스 컨테이너 오케스트레이션(orchestration) 시스템에서 실행되는 네트워크 기능이다. CNF 아키텍처는 비용을 절감하는 베어메탈(bare-metal) 서버(3018)을 통해 배포 가능하다. 5G 코어(Core)는 네트워크 기능 개발을 간소화하기 위해 컨테이너 오케스트레이션 시스템, 서비스 메시, 마이크로 서비스와 같은 클라우드 기반 기술을 사용한다. 5G 코어 네트워크(Core Network)는 Core의 각 기능을 서비스로 간주하고, 각 기능(서비스) 간의 인터페이스를 웹 기반 인터페이스(HTTP/REST)로 표준화하는 SBA(Service Based Architecture)를 사용한다.
이제 도 47을 참조하여, 쿠버네티스 아키텍처에 대하여 더 자세히 설명된다. K8s라고도 알려진 쿠버네티스는 오픈 소스 컨테이너 오케스트레이션 시스템이다. 노드 또는 작업자(3110, 3128)는 쿠버네티스가 설치되는 물리적 또는 가상 머신이다. 컨테이너는 작업자 컴퓨터에서 시작된다. 클러스터는 함께 그룹화된 노드 집합이다. 마스터(3100)는 쿠버네티스가 설치된 또 다른 노드로, 마스터로서 컨피겨레이션된다. 마스터(3100)는 클러스터의 노드를 감시하고 작업자 노드에서 컨테이너의 실제 오케스트레이션을 담당한다. 쿠버네티스는 API 서버(3102), ETCD 서비스(3108), kubelet 서비스(3122, 3132), 컨테이너 런타임(3118, 3136), 컨트롤러(3106) 및 스케줄러(3104)를 포함한 다양한 구성요소를 포함한다. API 서버(3102)는 쿠버네티스의 프런트엔드(front-end) 역할을 한다. 사용자, 관리 장치, 명령 라인(command line) 인터페이스는 모두 API 서버(3102)와 통신하여 쿠버네티스 클러스터와 상호 작용한다. ETCD(3108)은 클러스터를 관리하는 데 사용되는 모든 데이터를 저장하기 위해 쿠버네티스에서 사용하는 신뢰할 수 있는 분산 키-값 저장소이다. 스케줄러(3104)는 여러 노드에 작업이나 컨테이너를 배포하는 역할을 한다. 스케줄러는 새로 생성된 컨테이너를 찾아 노드에 할당한다. 컨트롤러(3106)는 오케스트레이션의 두뇌 역할을 하며 노드, 컨테이너 또는 엔드포인트가 다운될 때 이를 인지하고 대응하는 역할을 담당한다. 컨트롤러(3106)는 이러한 경우에 새로운 컨테이너를 불러오기로 결정한다. 컨테이너 런타임(3118, 3136)은 컨테이너(예: Docker)를 실행하는 데 사용되는 기본 소프트웨어이다. Kubelet(3122, 3132)는 클러스터의 각 노드에서 실행되는 에이전트이다. 에이전트는 컨테이너가 예상대로 노드에서 실행되고 있는지 확인하는 역할을 담당한다.
이제 도 48을 참조하여, 애플리케이션 서비스 메시(Application Service Mesh)의 아키텍처를 더 자세히 설명한다. 애플리케이션 서비스 메시는 보안, 재시도, 로깅 및 트레이싱(tracing)과 같은 많은 애플리케이션 레벨 작업을 오프로드(off-load)하는 프레임워크를 제공한다. 애플리케이션 서비스 메시를 사용하면 서비스 코드의 코드 변경이 거의 또는 전혀 없이 로드 밸런싱(load balancing), 서비스 간 인증, 모니터링 등을 통해 배포된 서비스 네트워크를 쉽게 생성할 수 있다. 애플리케이션 서비스 메시는 레이어 7 기능성을 지원한다. 애플리케이션 서비스 메시는 쿠버네티스에 다음 속성을 추가한다:
i) gRPC, WebSocket 및 TCP 트래픽에 대한 자동 로드 밸런싱
ii) 리치 라우팅 규칙(rich routing rule), 재시도, 장애 조치(failover) 및 결함 주입(fault injection)을 통해 트래픽 동작을 세밀하게 제어
iii) 액세스 제어, 속도 제한 및 할당량을 지원하는 플러그형 정책 레이어(pluggable policy layer) 및 컨피겨레이션 API
iv) 클러스터 수신 및 송신을 포함하여 클러스터 내의 모든 트래픽에 대한 자동 지표, 로그 및 트레이스
v) 강력한 신원 기반 인증 및 권한 부여를 통해 클러스터에서 서비스 간 통신을 보호함.
애플리케이션 서비스 메시(Istio 등)는 논리적으로 데이터 플레인(plane)(3248)과 제어 플레인(3246)으로 분할된다. 데이터 플레인(3248)은 사이드카(3212, 3218, 3224, 3230, 3234, 3240)로 배포된 지능형 프록시(예: Envoy 프록시) 세트를 포함한다. 사이드카 프록시는 포드(3210, 3216, 3222, 3228, 3232, 3238)에 배치된다. 이러한 프록시는 마이크로서비스와 애플리케이션(3214, 3220, 3226, 3244, 3236, 3242) 간의 모든 네트워크 통신을 중재하고 제어한다. 사이드카 프록시(sidecar proxies )는 또한 모든 메시 트래픽에 대한 원격 분석을 수집하고 보고한다. 제어 플레인(3246)은 트래픽을 라우팅하기 위해 프록시를 관리하고 컨피겨레이션한다. 제어 플레인(3246)은 컨피겨레이션(3202), 서비스 검색(3204), 인증서 관리(3206) 및 원격 측정(3208)을 위한 구성요소를 포함한다.
이제 도 49를 참조하여, 네트워크 서비스 메시(NSM, Network Service Mesh)의 아키텍처를 더 자세히 설명한다. 네트워크 서비스 메시(NSM)는 정교한 레이어 2 및 3 네트워크 컨피겨레이션과 옵션을 지원한다. 5G 핵심 네트워크는 일반적으로 각 클라우드의 레이어 2 및 3 설정 및 지원되는 프로토콜에 대한 요구 사항이 매우 다른 하이브리드 클라우드 환경에 배포된다. NSM을 사용하면 이러한 요구 사항을 클라우드 네이티브 방식으로 충족할 수 있다. NSM은 다양한 클러스터나 도메인을 연결하는 데 사용할 수 있다. NSM은 애플리케이션 서비스 메시의 개념을 L2/L3 페이로드에 매핑한다. NSM은 쿠버네티스의 네트워킹에 다음 속성을 추가한다:
i) 이종(heterogeneous) 네트워크 컨피겨레이션
ii) 엑소틱(exotioc) 프로토콜
iii) 1급 객체(first-class citizen)로서 터널링
iv) 1급 객체로서 네트워킹 콘텍스트
v) 정책 기반 서비스 기능 체이닝(SFC, service function chaining)
vi) 쿠버네티스 변경 필요성이 최소화됨
vii) 주문형 동적 협상 연결.
NSM은 네트워크 서비스 관리자(3312, 3326), 네트워크 서비스 엔드포인트(3316, 3320, 3324, 3328), 네트워크 서비스 클라이언트(3308, 3310, 3318, 3322) 및 네트워크 서비스 포워더(Network Service Forwarder)(3314, 3330)와 같은 구성 요소를 포함한다. 네트워크 서비스 엔드포인트는 클라이언트가 요청한 네트워크 기능성을 제공하는 구성 요소이다. 네트워크 서비스 클라이언트가 요청하고 네트워크 서비스 엔드포인트가 제공하는 네트워크 기능의 몇 가지 예는 다음과 같다:
i) 외부 인터페이스(예: 무선 네트워크 서비스)에 대한 액세스를 요청.
ii) SDN을 통해 네트워크 서비스에 대한 터널 요청.
iii) 두 개의 네트워크 서비스를 연결하여 외부 장치에 대한 액세스를 요청.
iv) L2 브리지 서비스
v) 분산 브리지 도메인.
네트워크 서비스 클라이언트가 요청한 기능은 네트워크 서비스 포워더(3314, 3330)를 통해 L2/L3 연결 형태로 네트워크 서비스 엔드포인트에 의해 제공된다. 포워더(forwarder)(3314, 3330)를 통한 L2/L3 연결 형태로 네트워크 서비스 엔드포인트에 의해 제공된다. L2/L3 연결은 IP 패킷, 이더넷 프레임 또는 MPLS 프레임과 같은 페이로드를 전달할 수 있다. 네트워크 서비스 레지스트리(3302)는 어떤 네트워크 서비스가 존재하는지, 각각의 네트워크 서비스 엔드포인트 및 네트워크 서비스 관리자에 대한 기록을 유지한다. 쿠버네티스 클러스터의 모든 노드에는 검색을 위해 네트워크 서비스 레지스트리(3302)에 게시하는 네트워크 서비스 관리자가 있다. 네트워크 서비스 관리자는 자신이 관리하는 네트워크 서비스 엔드포인트를 네트워크 서비스 레지스트리(3302)에 게시한다. 네트워크 서비스 관리자는 L2/L3 연결을 설정하기 위해 P2P(peer-to-peer)로 통신한다. 네트워크 서비스 레지스트리(3302)는 쿠버네티스 API 서버의 사용자 리소스 정의(CRD, Custom Resource Definition)를 통해 구현된다. 쿠버네티스 클러스터의 모든 노드는 네트워크 서비스 관리자 도메인이다. 또한 모든 노드는 교차 연결을 수행하는 데이터 플레인 역할을 하는 네트워크 서비스 포워더를 실행한다.
이제 도 50을 참조하여, 본 발명의 일 구현예에 따라, 네트워크 서비스 메시를 통한 애플리케이션 서비스 메시의 예시가 더 자세히 설명된다. 애플리케이션 서비스 메시는 네트워크 서비스 메시를 통해 배포될 수 있다. 네트워크 서비스 메시(3410, 3408, 3412)는 다양한 클러스터, 도메인 또는 클라우드 간의 연결을 조정한다. 애플리케이션 서비스 메시(3400)은 보안 서비스 대 서비스 통신, 관찰 가능성, 로깅, 원격 측정, 고급 정책, 지능형 라우팅 규칙, 트래픽 관리 및 카나리(canary) 배포와 같은 기능을 제공한다.
이제 도 51을 참조하여, 본 발명의 일 구현예들에 따른 블록체인 보안 서비스 메시(3500)의 예시가 더 자세히 설명된다. 제로-트러스트 모델은 더 이상 신뢰할 수 있는 인터페이스, 애플리케이션, 트래픽, 네트워크 또는 사용자가 없다고 가정한다. 블록체인 보안 서비스 메시(3500)은 다음과 같은 제로-트러스트 모델 요구 사항을 충족한다:
i) 모든 리소스는 안전한 방식으로 액세스되어야 한다;
ii) 액세스 통제는 꼭 알아야 할 사항에 기초하여 엄격하게 시행되어야 한다;
iii) 시스템은 검증해야 하며 절대 신뢰하지 않아야 한다;
iv) 모든 트래픽은 검사, 기록 및 검토되어야 한다;
v) 시스템은 아웃사이드 인(outside in) 대신 인사이드 아웃(inside out )으로 설계되어야 한다.
블록체인 보안 서비스 메시(3500)는 논리적으로 데이터 플레인(3556)과 제어 플레인(3554)으로 분할된다. 데이터 플레인(3556)은 사이드카(3520, 3526, 3532, 3538, 3544, 3550)로서 배치된 지능형 프록시 세트(예: Envoy 프록시)를 포함한다. 사이드카 프록시는 포드(3522, 3528, 3534, 3540, 3546, 3552)에 배치된다. 이러한 프록시는 CNF(3522, 3528, 3534, 3540, 3546, 3552) 사이의 모든 네트워크 통신을 중재하고 제어한다. 사이드카 프록시는 또한 모든 메시 트래픽에 대한 원격 분석을 수집하고 보고한다. 제어 플레인(3554)은 트래픽을 라우팅하기 위해 프록시를 관리하고 구성한다. 제어 플레인(3554)은 컨피겨레이션(3502), 서비스 검색(3504), 인증서 관리(3506), 원격 측정(3508), 블록체인(3510), BBMF 및 GVNS(3512), 스마트 계약(3514)및 규칙 및 패턴(3516)을 위한 구성 요소를 포함한다.
이제 도 52를 참조하여, 본 발명의 일 구현예에 따라, 게시판 메시징 프레임워크(BBMF, Bulletin Board Messaging Framework)(3614) 및 전역 변수 네임 시스템(Global Variable Name System, GVNS)(3628)을 통해 블록체인(3636)에서 트래픽을 로깅하는 프로세스에 대하여 자세히 설명된다. 전역 변수 네임 시스템(3628)은 전역 변수의 기록과 전역 변수의 소유자 및 리졸버를 유지 관리한다. CNF, VNF, 작업자 노드, 서버, 컨테이너, 포드, VM과 같은 데이터 소스(3600)는 서비스 프록시(3608)에서 실행되는 게시자/제조자 클라이언트(3610)로 전송되는 데이터 또는 알림을 생성한다. 게시자/제조자 클라이언트(3610)는 게시판 서버(3614)에 의해 관리되는 하나 이상의 토픽(3618, 3620)에 데이터 또는 알림을 메시지(3612)로 게시한다. 소비자/구독자 클라이언트(3624)는 메시지(3622)를 수신하고 GVNS(3628)에 등록된 전역 변수의 값을 업데이트한다. 스마트 계약(3630, 3632, 3534)는 GVNS(3628)에 등록된 전역 변수를 참조한다.
CNF(Containerized Network Function, 컨테이너화된 네트워크 기능) 또는 VNF(Virtualized Network Function, 가상화 네트워크 기능) 간의 모든 네트워크 트래픽 및 거래 블록체인 보안 서비스 메시(3616)의 BBMF-GVNS 구성 요소를 통해 블록체인에 기록된다. 블록체인(3636)은 CNF/VNF가 서로 악의적으로 행동하지 않도록 보장하는 데 사용된다. 모든 상호 작용은 블록체인(3636)에 저장되며 스마트 계약을 사용하여 보안 지침을 시행한다. 모든 거래는 처리되고 및 커밋(committ) 되기 전에 로그(log)되고 지워진다. 어떤 CNF /VNF도 다른 CNF/VNF를 신뢰하지 않는다.
이제 도 53을 참조하여, 본 발명의 일 구현예들에 따른 블록체인 보안 서비스 메시와 관련된 스마트 계약의 예시가 더 자세히 설명된다. 스마트 계약은 블록체인(3720)에 배포되며 BBMF 및 GVNS(3700)과 상호 작용한다. 관련된 스마트 계약은 다음과 같다:
CNF/VNF 특정 계약(3706)
거래 처리 계약(3712)
작업자 노드/서버 특정 계약(3708)
신원 스마트 계약(3714)
컨테이너/포드/VM 특정 계약(3710)
보안 정책 계약(3716).
이제 도 54를 참조하여, 본 발명의 구현예들에 따라, 블록체인 보안 서비스 메시를 사용하여 공격(DDoS 등)을 탐지하고 완화하는 단계를 더 자세히 설명한다. 블록체인 보안 서비스 메시는 네트워크 및 거래 데이터를 포함한 모든 트래픽을 로깅하고, 거래를 처리 및 삭제하며, CNF/VNF/VM/컨테이너/Pod/작업자 노드/서버가 서로 악의적으로 행동하는 것을 방지하고 보안 정책을 시행한다. 블록체인 보안 서비스 메시를 활용하여 온디맨드 방식으로 탐지 및 완화 대책을 제공할 수 있다. CNF/VNF/VM/컨테이너/포드/워커 노드/서버의 모든 트래픽은 게시판 서버를 사용하여 기록되고 해당 전역 변수 및 스마트 계약이 업데이트된다. 모든 악성 또는 변칙 트래픽은 스마트 계약을 통해 감지된다. 스마트 계약은 패턴을 일치시키는 데 사용되며 그 결과는 위험 및 확장성을 기반으로 CNF/VNF의 매핑을 변경하는 데 사용된다. BBMF를 통해 트리거되는 해당 완화 조치. 완화 조치에는 GVNS 및 블록체인을 통한 공격 게시, 감염된 구성 요소(CNF/VNF/VM/컨테이너/Pod/작업자 노드/서버) 격리 및 다른 VM/컨테이너/Pod/작업자 노드/서버로 이동이 포함된다. 단계 3800에서 서비스 프록시의 게시자/제조자 클라이언트는 소스(CNF, VNF, 작업자 노드, 서버, 컨테이너, 포드 또는 VM)의 데이터를 게시판에서 관리하는 토픽에 게시한다. 단계 3802에서 소비자/구독자 클라이언트는 게시판에 의해 관리되는 토픽을 구독하고 GVNS에 의해 유지되는 전역 변수를 업데이트한다. 단계 3804에서 스마트 계약은 GVNS가 유지 관리하는 전역 변수를 참조한다. 단계 3806에서는 스마트 계약을 통해 모든 악성 또는 변칙 트래픽이 감지된다. 단계 3808에서, GVNS 및 블록체인을 통한 공격을 게시하는 것, 감염된 구성 요소(CNF/VNF/VM/컨테이너/Pod/작업자 노드/서버)를 격리시키는 것 및 이를 다른 VM/컨테이너/포드/작업자 노드/서버로 이동시키는 것을 포함하는, BBMF를 통한 완화 조치가 트리거된다.
이제 도 55를 참조하여, 본 발명의 일 구현예들에 따른 다양한 레이어의 컨테이너화된 네트워크 기능(CNF)에 대한 과제 및 요구 사항에 대한 설명이 더 자세히 설명된다. 레이어 2(데이터 링크 레이어 3910) 및 레이어 3(네트워크 레이어 3908)의 과제는 다음과 같다:
네트워킹 및 로드 밸런싱(load balancing)
다중 테넌트 및 다중 지역
오케스트레이션, 업데이트, 유지 관리
스케줄링
서비스 발견
주문형 및 동적 연결
이종 네트워크 컨피겨레이션.
네트워크 서비스 메시(3920)는 레이어 2 와 3의 문제를 해결한다.
레이어 4(전송 레이어(3906)), 레이어 5(세션 레이어(3904)), 레이어 6(프리젠테이션 레이어(3902)) 및 레이어 6(애플리케이션 레이어(3900))에서의 과제는 다음과 같다:
애플리케이션 상태 및 성능 모니터링
애플리케이션 배포 및 비밀
회로 차단
교통 관리
카나리 배포
시간 초과, 재시도, 기한, 예산
백프레셔(Backpressure)
전송 보안
신원 및 액세스 제어
할당량 관리
프로토콜 번역
정책(Policy)
서비스 성능 모니터링.
애플리케이션 서비스 메시(3916)는 레이어 4, 5, 6 및 7의 문제를 해결한다.
이제 도 56을 참조하여, 본 발명의 일 구현예에 따라, 블록체인 보안 애플리케이션 서비스 메시(BSASM, Blockchain-Secured Application Service Mesh)(4014) 및 블록체인 보안 네트워크 서비스 메시(BSNSM, Blockchain-Secured Network Service Mesh)(4016)을 사용하는 다중-레이어 보호 액세스법의 예시가 더 자세히 설명된다. BSASM(4014) 및 BSNSM(4016)에는 자체 블록체인(4018 및 4020)이 있다. 각 블록체인에는 자체 스마트 계약과 공유할 수 있는 자체 GVNS 변수가 있다. BSASM과 BSNSM에는 자체 스마트 계약이 있거나 각 레이어에 자체 스마트 계약이 있다.
이제 도 57을 참조하여, 본 발명의 일 구현예들에 따른, 서로 다른 레이어에서 서로 다른 블록체인을 사용하는 다중-레이어 보호 접근 방식을 더 자세히 설명한다. 각 레이어 블록체인(4116, 4116, 4118, 4120, 4122, 4124, 4126)은 다른 레이어 블록체인을 통해 통신할 수 있다. 각 레이어(4100, 4102, 4104, 4106, 4108, 4110, 4112)은 자체 블록체인을 가질 수 있거나 레이어의 서브세트가 블록체인을 공유할 수 있다. 또는 인접 레이어가 블록체인을 공유할 수도 있다. 또는 서브세트가 겹칠 수 있고 경계 레이어가 두 블록체인의 일부일 수 있다. 또는 각 레이어 또는 L1~L7 레이어의 서브세트에 대한 여러 스마트 계약이 포함된 하나의 블록체인이다. 블록은 하나 이상의 서브세트에 속할 수 있다. 각 스마트 계약은 블록체인에 속하거나 여러 블록체인에 속할 수 있다. 제로-트러스트 그래프가 할당을 설정한다. 서브세트들은 오버랩(overlap)될 수 있으며 각 서브세트에는 인접한 레이어가 모두 포함될 필요는 없다. 그것은 레이어 L1, L6, L7만 포함할 수 있다.
이제 도 58을 참조하여, 본 발명의 일 구현예에 따라, 다중-레이어(multi-layer) 보호 접근 방식의 슈퍼체인과 서브체인에 대한 설명이 더 자세히 설명된다. 다중-레이어 보호 접근 방식은 하나의 슈퍼체인(4200)과, 서브체인(4202, 4204, 4206) 중 하나 이상의 레벨을 포함한다. 슈퍼체인은 레벨 1 서브체인의 요약 버전으로 작동한다. 마찬가지로 레벨(N-1) 서브체인은 레벨 N 서브체인의 요약 버전 역할을 한다. 슈퍼체인의 단일 블록에는 서브체인의 여러 블록에서 요약된 거래가 포함될 수 있다.
이제 도 59를 참조하여, 본 발명의 일 구현예에 따라, 다중-레이어 보호를 위한 블록그리드(BlockGrid) 아키텍처의 예시가 더 자세히 설명된다. 블록그리드는 블록 시간이 증가하고 분산(decentralization) 레벨이 증가하는 N 레벨의 블록체인을 포함하는 다중 체인(multi-chain) 아키텍처이다. 레벨 1(4300) 체인은 몇 밀리초에서 몇 초 범위의 블록 시간과 권한 증명(PoA, Proof-of-Authority) 또는 지분 증명(PoS, Proof-of-Stake) 합의를 갖는 "가장 빠른" 체인이다. 레벨 N 체인 4304는 몇 초에서 몇 분 범위의 느린 블록 시간과 높은 레벨의 분산화를 갖춘 작업 증명(PoW, Proof-of-Work) 체인이다. 블록그리드 아키텍처의 연속적인 레벨에 있는 블록은 블록 앵커(Block Anchor)를 통해 연결된다. 블록 앵커는 레벨 N-1 체인의 블록과 레벨 N 체인의 블록 사이의 링크로, 이러한 블록은 암호화 해시로 연결된다. 보다 구체적으로, 레벨 1 체인(4300)의 블록과 레벨 N-1 체인(4302)의 블록 사이에 블록 앵커가 존재할 수 있고, 레벨 N-1 체인(4302)의 블록과 레벨 N(4304) 체인의 블록 사이에 또 다른 블록 앵커가 존재할 수 있다.
블록그리드 네트워크는 완전히 중앙화된(centralized) 블록체인 네트워크와 완전히 분산형(decentralized) 블록체인 네트워크의 하이브리드로 볼 수 있다. 레벨 1 체인(4300)은 빠르고 블록 시간이 빨라야 하기 때문에 중앙화될 수 있는 반면, 레벨 N 체인(4304)은 완전히 분산될 수 있다. 게시판 메시징 시스템은 메시지와 이벤트 알림이 서로 다른 레벨의 체인 간에 교환되어야 하는 블록그리드에서 N 레벨의 체인을 조정하는 데 사용될 수 있다.
이제 도 60을 참조하여, 본 발명의 일 구현예에 따라, 블록그리드 아키텍처 내의 서로 다른 블록체인의 블록 간의 관계를 더 자세히 설명한다. 이 도면은 4개의 블록체인(4400, 4402, 4403, 4404)을 갖는 4 레벨 블록그리드 네트워크를 보여준다. 레벨 N 체인의 블록에는 레벨 N-1 체인의 해당 블록의 모든 거래가 포함되거나 해당 블록의 거래 요약 형태가 포함된다. 예를 들어, 레벨 4 체인(4404)의 블록 B4,0에는 레벨 3 체인(4403)의 해당 블록 B3,0의 모든 거래가 포함되어 있으며, 이는 다시 레벨 1 체인(4400)의 해당 블록 B1,0의 모든 거래를 포함한다. 마찬가지로 레벨 3 체인의 블록 B3,1은 레벨 2 체인(1942)의 해당 블록 B2,1 및 B2,2(1914)의 모든 거래를 포함한다.
서로 다른 블록체인의 블록 시간(또는 블록 간격)과 블록 생성 시간이 동기화될 수 있다. 예를 들어, 레벨 1 체인의 블록 시간이 100ms이고 레벨 2 체인의 블록 시간이 1초인 경우 레벨 1 체인의 10개 블록마다 레벨 2 체인의 새로운 블록이 생성될 수 있다. 이러한 경우 레벨 2 체인의 모든 블록에는 레벨 1 체인의 이전 10 개 블록의 거래가 포함된다.
이제 도 61을 참조하여, 본 발명의 일 구현예에 따라, 블록체인 신원 및 액세스 관리(B-IAM, Blockchain Identity & Access Management) 시스템의 예시가 더 자세히 설명된다. B-IAM 시스템의 인프라 레이어(4654)은 블록체인 네트워크(4634), 분산형 저장 플랫폼(4636), 분산형 메시징 플랫폼(4638) 및 클라우드 인프라(4640)를 포함한다. 사용자 신원 관리와 관련된 모든 스마트 계약(예: 인감 계약, 인증 계약, 역할 및 권한 계약)은 블록체인 네트워크(4634)에 배포된다.(4634)의 경우 이더리움과 같은 블록체인 플랫폼을 사용할 수 있다. 분산형 메시징 플랫폼(4638)은 B-IAM 시스템에 구축된 분산형 애플리케이션(Dapp) 간의 메시징에 사용된다. 4648의 경우 Whisper와 같은 분산형 메시징 플랫폼을 사용할 수 있다. Whisper 메시지는 본질적으로 일시적이며 TTL(Time-To-Live)이 설정되어 있다. 각 메시지에는 하나 이상의 토픽이 연결되어 있다. 블록체인 노드에서 실행되는 Dapp은 구독하려는 토픽에 대해 노드에 알린다. Whisper는 노드가 관심 있는 토픽을 피어에게 알리는 토픽 기반 라우팅을 사용한다. 토픽은 노드에 전달된 후 블록체인 노드에서 실행되는 Dapp에 배포되는 메시지를 필터링하는 데 사용된다. 분산형 저장 플랫폼(4636)은 사용자 사진, 스캔한 신원 문서 등의 사용자 데이터를 저장하는 데 사용된다. 4636의 경우 Swarm과 같은 분산형 스토리지 플랫폼을 사용할 수 있다. Swarm은 이더리움 블록체인 플랫폼을 위한 분산형 스토리지 플랫폼이자 콘텐츠 배포 서비스이다. Swarm은 스토리지 및 대역폭 리소스를 제공하는 피어가 유지 관리하는 P2P 스토리지 플랫폼이다. Swarm은 인기 있는 콘텐츠를 제공하기 위해 동적으로 확장되도록 설계되었으며 인기가 없거나 자주 요청되지 않는 콘텐츠의 가용성을 보장하는 메커니즘을 갖추고 있다. 클라우드 인프라(4640)는 애플리케이션 사용 데이터의 수집, 저장 및 분석에 사용된다.
B-IAM 시스템의 플랫폼 및 애플리케이션 서비스 레이어(4618)는 통합 서비스(4628), 신원 및 인증 서비스(4650), 사용자 등록 및 인증 서비스(4652), 데이터 관리 및 분석 서비스(4620)를 포함한다. 통합 서비스(4628)는 블록체인 간 및 블록체인 내 메시징 서비스(4630)와 애플리케이션, 클라우드 서비스 및 기타 블록체인 네트워크를 위한 다양한 커넥터(4632)를 포함한다. 신원 및 인증 서비스(4650)는 사용자 신원 및 액세스 관리 서비스(4642) 및 B-IAM 포털(4644)을 포함한다. B-IAM 포털(4644)을 통해 사용자(4600)는 B-IAM 시스템에 기록된 자신의 신원 데이터에 액세스 및 모니터링하고 다양한 애플리케이션에 의해 이루어진 신원 요청을 볼 수 있다. 사용자 등록 및 인증 서비스(4652)는 사용자 등록 서비스(4646) 및 사용자 인증 서비스(4648)를 포함한다. 데이터 관리 및 분석 서비스(4620)는 클라우드 인프라(4640)에 배포된다. 여기에는 분석 서비스(4622), 보고 서비스(4624) 및 경고 서비스(4626)가 포함된다. 분석 서비스(4622)는 규정 준수를 보장하기 위해 사용자 계좌의 다중 블록체인 동작을 분석할 수 있다. 이러한 모든 플랫폼 및 애플리케이션 서비스는 위에서 설명한 프로세서, 네트워크 통신 장치 및 데이터 저장 장치를 포함하는 컴퓨터 장치에서 작동 가능하다는 것이 본 발명의 범위 내에 포함되는 것으로 고려되고 포함된다.
B-IAM 시스템은 광범위한 애플리케이션에 대한 ID, 액세스 관리 및 인증 서비스를 제공하는 데 사용될 수 있다(4614). B-IAM 시스템으로부터 이익을 얻을 수 있는 일부 예시적인 애플리케이션에는 신원 확인 애플리케이션(4602), 액세스 제어 애플리케이션(4604) 및 블록체인 기반 결제 애플리케이션(4608)이 포함된다. 이들 모두는 사용자(4600)를 식별 및/또는 인증하는 제3자 장치 및 애플리케이션(4614) 과 통신할 수 있다.
이제 도 62를 참조하여, 본 발명의 일 구현예들에 따른 B-IAM 시스템(4548) 과 다른 블록체인 네트워크(4500) 및 분산형 애플리케이션(4560, 4562) 사이의 상호 작용을 자세히 설명한다. B-IAM 시스템은 다양한 블록체인 네트워크에 배포된 다양한 분산 애플리케이션에 대한 사용자 ID 및 액세스 관리 서비스를 제공하는 데 사용할 수 있다. B-IAM을 사용하면 사용자는 동일한 ID를 유지하면서 여러 블록체인 네트워크 또는 동일한 블록체인 네트워크에 배포된 여러 애플리케이션에서 작업할 수 있다. 블록체인 네트워크(4500)는 블록체인 간 메시징(Inter-Blockchain Messaging) 프로토콜(4524)을 사용하여 B-IAM 시스템과 통신할 수 있다. 블록체인 네트워크(4500)는 또한 사용 데이터(4532)(예: 애플리케이션 사용 및 사용자 상호 작용 데이터)를 B-IAM 시스템으로 보낼 수 있다. 블록체인 네트워크(4500)에 배포된 애플리케이션은 스마트 계약(4518, 4542) 또는 Dapp(4560, 4562)의 형태이다. 스마트 계약은 블록체인 네트워크에 배포되고 주소로 고유하게 식별되는 코드 조각이다. 블록체인 클라이언트를 통해 스마트 계약에 거래 또는 콜을 보낼 수 있는 최종 사용자(4514, 4550)가 스마트 계약을 직접 사용할 수 있지만, 스마트 계약에 보다 사용자 친화적인 인터페이스를 제공하기 위해 이러한 스마트 계약을 통해 Dapp을 개발하고 적용할 수 있다. Dapp(4560)은 하나 이상의 연관된 스마트 계약(4518), 프런트엔드(front-end) 사용자 인터페이스(4522)(일반적으로 HTML 및 CSS로 구현됨) 및 백엔드(back-end)(4520)(일반적으로 JavaScript로 구현됨)를 포함한다. 사용자는 Dapp의 웹 인터페이스 자체에서 Dapp과 관련된 스마트 계약(4518)에 거래를 제출할 수 있다. Dapp의 웹 인터페이스는 거래를 블록체인 플랫폼(4500)으로 전달하고 웹 인터페이스의 스마트 계약에 있는 거래 영수증 또는 상태 정보를 표시한다. Dapp은 Dapp의 웹 기반 사용자 인터페이스를 제공하는 블록체인 노드(4504)에 배포된다. Dapp 로직은 블록체인 플랫폼(4500)에 배포된 관련 스마트 계약(4518)에 의해 제어된다. 특별한 저장 요구 사항이 있는 Dapp은 분산형 저장 플랫폼(예: Swarm)을 사용할 수 있다. 마찬가지로 특별한 메시징 요구 사항이 있는 Dapp은 분산형 메시징 플랫폼(예: Whisper)을 활용할 수 있다. 블록체인 노드(4504)는 일반적으로 블록체인 네트워크(4500)에 거래를 보내는 블록체인 클라이언트(4506), 스마트 계약 컴파일러(4508), 분산형 스토리지 클라이언트 및 로컬 저장소(4510), 분산형 메시징 클라이언트(4512)를 포함한다. 스마트 계약이 블록체인 네트워크에 배포되는 동안, 블록체인 내 메시징(intra-blockchain messaging)(4516)(분산형 메시징 플랫폼을 통해) 및 분산형 저장/검색 요청(4564)(분산형 저장소 플랫폼을 통해)은 블록체인에 대한 합의가 필요하지 않으므로 체인 외부에서 작동한다.
이제 도 63을 참조하여, 본 발명의 일 구현예에 따라, 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(BENASM, Blockchain-Enabled Network & Application Service Mesh)(4700)의 예시가 더 자세히 설명된다. BENASM(4700)은 블록체인 기반 네트워크와 애플리케이션 서비스 메시가 결합된 것이다. 상기 결합된 메시는 단일 블록체인을 가질 수도 있고 네트워크 및 애플리케이션 레이어를 위한 별도의 블록체인이 있을 수도 있다. 각 블록체인에는 자체 스마트 계약과 공유할 수 있는 자체 GVNS 변수가 있다. 각 레이어 블록체인은 다른 레이어 블록체인과 통신할 수 있다. 네트워크 레이어에서 BENASM은 네트워크 컨피겨레이션 및 다양한 클러스터 또는 도메인 연결과 같은 레이어 2 및 3 기능을 활성화한다. 애플리케이션 레이어에서 BENAS은 로드 밸런싱, 서비스 간 인증, 모니터링, 보안, 재시도, 로깅 및 트레이싱 등과 같은 레이어 7 기능을 활성화한다. 결합된 메시를 통해 네트워크 및 애플리케이션 레이어 모두에 대한 가시성을 확보하고 레이어 간 정보 전달이 가능하다. 예를 들어 보안 관점에서 포트(port)가 한 레이어에서 열리면 애플리케이션 작업과 교차 확인되거나 상호 연관될 수 있다. 관찰 가능성의 관점에서 ASM은 애플리케이션 메트릭(metrics)을 제공하지만 네트워크 및 패킷 레벨 메트릭(packet level metrics)은 제공하지 않는다. 결합된 메시는 상위 레이어에서 하위 레이어로 하향식 드릴(drill) 옵션을 통해 모든 레이어에 가시성을 제공할 수 있다.
BENASM은 논리적으로 데이터 플레인(4764)과 제어 플레인(4762)으로 분할된다. 데이터 플레인(4764)은 사이드카(4720, 4734, 4748)로서 배치된 지능형 프록시(예: Envoy 프록시) 세트를 포함한다. 사이드카 프록시는 포드(4724, 4738, 4752)에 배포된다. 이러한 프록시는 마이크로서비스, 애플리케이션 또는 CNF(4726, 4740, 4754) 간의 모든 네트워크 통신을 중재하고 제어한다. 사이드카 프록시는 또한 모든 메시 트래픽에 대한 원격 분석을 수집하고 보고한다. 네트워크 서비스 관리자(4722, 4736, 4750), 네트워크 서비스 엔드포인트(4728, 4742, 4760), 네트워크 서비스 클라이언트(4732, 4746, 4758) 및 네트워크 서비스 포워더(4730, 4744, 4756) 와 같은 네트워크 서비스 메시 특정 구성요소도 포드(4724, 4738, 4752)에 배포된다. 제어 플레인(4762)은 트래픽을 라우팅하기 위해 프록시를 관리하고 컨피겨레이션한다. 제어 플레인(4762)은 컨피겨레이션(4702), 서비스 검색(4704), 인증서 관리(4706), 원격 측정(4708), 블록체인(4710), BBMF & GVNS(4712), 스마트 계약(4714), 규칙 및 패턴(4716) 및 네트워크 서비스 레지스트리(4718)에 대한 구성요소를 포함한다.
이제 도 64를 참조하여, 본 발명의 일 구현예에 따라, 신원-포함 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(Blockchain-Enabled Network & Application Service Mesh with Identity, BENASMI)의 예시가 더 자세히 설명된다. 신원 프레임워크를 갖춘 블록체인 기반 네트워크 및 애플리케이션 서비스 메시가 제안된다. 결합된 메시는 네트워크 및 애플리케이션 레이어의 기능은 물론 워크로드/서비스에 대한 보안 신원을 제공한다. BENASMI는 클러스터 또는 도메인의 각 워크로드/서비스에 고유한 신원을 할당한다. BENASMI는 여러 도메인이나 클러스터에서 작동한다. 블록체인 스마트 계약 기반 신뢰 인증서가 각 워크로드/서비스에 할당된다.
BENASMI는 논리적으로 데이터 플레인(4874)과 제어 플레인(4872)으로 분할된다. 데이터 플레인(4874)은 사이드카(4822, 4840, 4856)로서 배치된 지능형 프록시(예: Envoy 프록시) 세트를 포함한다. 사이드카 프록시는 포드(4830, 4854, 4860)에 배포된다. 이러한 프록시는 마이크로서비스, 애플리케이션 또는 CNF(4832, 4846, 4864) 간의 모든 네트워크 통신을 중재하고 제어한다. 사이드카 프록시는 또한 모든 메시 트래픽에 대한 원격 분석을 수집하고 보고한다. 네트워크 서비스 관리자(4824, 4842, 4858), 네트워크 서비스 엔드포인트(4834, 4852, 4870), 네트워크 서비스 클라이언트(4838, 4850, 4868) 및 네트워크 서비스 포워더(4836, 4848, 4866)와 같은 네트워크 서비스 메시 특정 구성요소도 포드(4830, 4854, 4860)에 배포된다. 제어 플레인(4872) 은 트래픽을 라우팅하기 위해 프록시를 관리하고 컨피겨레이션한다. 제어 플레인(4872)은 컨피겨레이션(4802), 서비스 검색(4804), 인증서 관리(4806), 원격 측정(4808), 블록체인(4810), BBMF 및 GVNS(4812), 스마트 계약(4816), 규칙 및 패턴(4720), 네트워크 서비스 레지스트리(4814) 및 신원 서비스 및 계약(4818)에 대한 구성요소를 포함한다.
이제 도 65를 참조하여, 본 발명의 일 구현예에 따라, 신원-포함 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(BENASMI)와의 교차-클러스터/교차 도메인의 연결성, 신원 및 관측가능성(observability)이 더 자세히 설명된다. BENASMI(4900)은 각 클러스터/도메인에 마이크로서비스, 애플리케이션 또는 CNF를 실행하는 여러 포드(4902, 4904, 4908, 4910, 4922, 4924, 4928, 4930, 4912, 4916, 4918, 4920)가 있는 여러 쿠버네티스 클러스터/도메인(4906, 4914, 4926)에 걸쳐 연결성, 신원 및 관측가능성 기능을 제공할 수 있다.
이제 도 66을 참조하여, 본 발명의 일 구현예에 따라, 마이크로서비스 아키텍처의 예시가 더 자세히 설명된다. 마이크로서비스는 모놀리식(monolithic) 소프트웨어를 개발하는 대신 잘 정의된 API를 통해 통신하는 여러 개의 소규모 독립 서비스를 개발하는 소프트웨어 개발에 대한 아키텍처 접근 방식이다. 마이크로서비스 아키텍처를 사용하면 확장이 더 쉬워지고 출시 기간이 단축된다. 마이크로서비스 아키텍처는 가상화 및 컨테이너화 기술을 활용한다.
5G의 맥락에서 마이크로서비스 아키텍처는 가상화 및 컨테이너화 기술과 함께 서비스 요구 사항에 대한 사전 지식 없이도 리소스의 동적 할당 및 배치, 네트워크 오케스트레이션 및 주문형 네트워크 슬라이스 생성을 허용할 수 있다. 다양한 레벨의 QoS를 충족하기 위해 블록체인 및 스마트 계약을 사용하여 리소스 할당을 자동화할 수 있다.
마이크로서비스가 급속히 성장함에 따라 서비스 검색과 관련된 다양한 문제, 여러 서비스 간의 라우팅, 버전, 신원, 권한 부여, 인증, 보안 및 로드 밸런싱이 발생한다. 쿠버네티스 및 애플리케이션 서비스 메시는 이러한 문제 중 일부를 해결하지만 다중-레이어 보안, DDoS 방지, 마이크로서비스 보안에 대한 제로-트러스트 접근 방식과 같은 문제가 있다. 신원-포함 블록체인 기반 네트워크 및 애플리케이션 서비스 메시(BENASMI)는 이러한 문제를 해결한다.
이제 도 67을 참조하여, 본 발명의 일 구현예에 따라, 가상화 및 컨테이너화를 사용하여 5G에서 자원의 동적 할당을 더 자세히 설명한다. 클라우드 컴퓨팅에서와 같은 가상화 및 컨테이너화 아이디어는 다양한 컨테이너가 유형별로 모델링되고 각 컨테이너가 자체 유형의 슬라이스 코인 및 리소스를 소비하는 캐리어 5G 네트워크로 확장될 수 있으며 스마트 계약을 통해 기업, 통신업체 및 클라우드 제공업체가 모두 가능하도록 보장한다. 다른 엔터티에 의해 부과된 기존 관계 및 운영 제약을 방해하지 않으면서 원활하게 실행된다. 가상화 및 컨테이너화 기술을 통해 5G 네트워크 사업자는 애플리케이션 인식 네트워크와 네트워크 인식 애플리케이션을 신속하게 구축하여 맞춤형 서비스와 비즈니스 모델을 제공할 수 있다. 블록체인 및 스마트 계약을 통해 엔드-투-엔드(end-to-end) 리소스 할당/공유, 네트워크 관리 및 원하는 서비스를 제공하는 오케스트레이션이 가능하다.
이제 도 68을 참조하여, 본 발명의 일 구현예에 따라, 네트워크 슬라이스 코인의 예시가 더 자세히 설명된다. 네트워크 슬라이싱(Network Slicing)은 공통 및 공유 인프라 레이어 위에 네트워크 슬라이스라는 논리적 네트워크를 생성하여 원하는 네트워크 특성을 실현하고 특정 고객 요구 사항을 해결하기 위한 특정 네트워크 기능을 제공할 수 있는 5G 기술이다.
네트워크 슬라이스를 규제하기 위해 "슬라이스코인(Slicecoin)"이라는 새로운 유형의 가상 화폐가 제안되었다. 슬라이스는 리소스용 코인, 다양한 서비스 유형용 코인, 제어, 컴퓨팅, 관리 등 다양한 기능용 코인과 같은 다양한 유형의 슬라이스코인에 의해 규제된다. 이러한 코인은 단일 또는 다중 블록체인에서 실행될 수 있는 스마트 계약을 활용하고 자원, 품질, 성능 및 비용 및 보안 제약에 따라 관리 및 제공, 운영 및 제어를 위해 ID 및 분산화를 활용하여 시간적 및 공간적 방식으로 할당, 소비, 생성 및 소각된다. 네트워크 슬라이스코인을 사용하면 신뢰하지 않는 당사자가 슬라이스를 사용하여 5G 네트워크를 공동 관리할 수 있다.
슬라이스 템플릿(5100), 리소스 사양 및 컨피겨레이션, 관리 모델 및 시스템 매개변수는 리소스 할당 및 네트워크 조정 프로세스를 자동화하는 스마트 계약(5114)을 생성하는 데 사용된다. 슬라이스코인은 블록체인의 기본 토큰 역할을 하여 맞춤형 서비스 제공과 5G의 새로운 충전 및 비즈니스 모델을 가능하게 하고 관련 단체에 보상을 제공한다. 사용자와 네트워크 운영자 간의 스마트 계약(5114) 은 사용자에게 요금을 청구하는 데 사용된다. 스마트 계약에 합의된 조건이 충족되면 자동으로 요금이 청구되므로 투명성이 향상되고 사기(fraud)가 최소화된다. 블록체인(5118) 거래에 대한 완전한 감사(audit) 추적을 유지하여 재무 조정을 더 쉽게 만든다.
이제 도 69를 참조하여, 본 발명의 일 구현예에 따라, 블록체인을 사용한 네트워크 슬라이스 관리가 더 자세히 설명된다. 네트워크 슬라이스는 네트워크 기능 세트와 이러한 네트워크 기능을 실행하는 리소스로, 특정 유형의 서비스에 필요한 특정 성능 레벨을 충족하기 위해 완전한 인스턴스화된 논리적 네트워크(complete instantiated logical network)를 형성한다. 네트워크 슬라이스는 엔드-투-엔드 대기 시간, 이동성, 사용자 밀도, 우선 순위, 적용 범위, 트래픽 용량 및 격리 정도와 같은 다양한 서비스 요구 사항을 해결할 수 있다. 물리적 또는 가상 인프라 리소스는 하나의 네트워크 슬라이스 전용이거나 다른 네트워크 슬라이스와 공유될 수 있다. 서비스 유형 및 슬라이스 성능 요구 사항에 대한 몇 가지 예는 다음과 같다:
1. 고정 무선 액세스를 위한 고속 광대역(고용량 및 고처리량)(5150)
2. 원격 미터링(metering)을 위한 대규모 IoT(저전력, 대규모 장치 연결)(5152)
3. 공장 자동화를 위한 미션-크리티컬 서비스(mission-critical service )(초저지연 및 고신뢰성)(5154).
슬라이스(5160, 5162, 5164) 각각은 세 가지 코어 차원(core dimension)에 따라 다양한 성능 기능을 제공한다:
1. 용량 및 처리량
2. 신뢰성 및 대기 시간
3. 연결성 규모.
슬라이스(5160, 5162, 5164)는 리소스용 코인, 다양한 서비스 유형용 코인, 제어, 컴퓨팅, 관리 등 다양한 유형의 기능용 코인과 같은 다양한 유형의 슬라이스코인에 의해 규제되며 블록체인 네트워크(5172)에 배포된다.
이제 도 70을 참조하여, 본 발명의 일 구현예에 따라, 5G의 계층적 합의 모델의 예시가 더 자세히 설명된다. 예를 들어 권한 증명 모델(proof of authority model)은 더 높은 레벨의 도메인에 적용되며 각 도메인 내에서는 서로 다른 합의 모델이 사용될 수 있다. 하나의 합의 모델은 다른 합의 모델 내에 포함될 수 있다. 최고 레벨에서 통신업체 네트워크(5G), 클라우드 제공업체 및 기업은 5G 및 컴퓨팅 리소스를 배분(assign), 할당 및 소비하는 하나의 합의 모델을 가질 수 있으며, 해당 도메인 내에서 자체 합의 모델을 가질 수 있다. 5G의 계층적 합의 모델(Hierarchical Consensus Model)을 사용하면 다음과 같은 사용 사례에 대해 고도의 이종(heterogeneous) 네트워크에서 수많은 상호 작용을 효율적으로 관리할 수 있다:
1. 합의된 스마트 계약을 기반으로 엔드-투-엔드 슬라이스를 안전하게 생성하고 리소스를 할당한다;
2. 다양한 산업 분야의 슬라이스 요청을 처리하고 이를 모바일 인프라 리소스 조정자(orchestrator)에게 이체한다.
위에 설명된 방법 모두는, 본 기술 분야에 모두 알려진 바와 같이, 프로세서, 상기 프로세서와 통신하는 위치에 있는 데이터 저장소(예: 메모리), 상기 프로세서와 통신하는 위치에 있고 네트워크를 통해 서로 통신하도록 동작하는 네트워크 통신 장치를 포함하는 컴퓨터 시스템에서 수행 가능하다.
본 발명의 예시적 측면들 중 일부는 본 명세서에 기술된 문제, 및 기술되지 않은, 통상의 기술자가 발견할 수 있는 다른 문제를 해결하는 데 유리할 수 있다.
위의 설명은 많은 특정성을 포함하고 있지만, 이는 임의의 구현예들의 범위에 대한 제한으로 해석되어서는 안 되며, 제시된 구현예들의 예시로서 해석되어야 한다. 다양한 구현예들의 교시 내에서 많은 다른 결과 및 변형이 가능하다. 본 발명은 예시적 구현예들을 참조하여 설명되었지만, 통상의 기술자는 본 발명의 범위를 벗어나지 않고 다양한 변경이 이루어질 수 있고 등가물이 그 요소로 대체될 수 있음을 이해할 것이다. 또한, 본 발명의 본질적인 범위를 벗어나지 않고 본 발명의 교시에 특정 상황이나 재료를 적용하기 위해 많은 수정이 이루어질 수 있다. 그러므로, 본 발명은, 본 발명을 수행하기 위해 고려되는 최선의 또는 유일한 모드로서 개시된 특정 구현예들에 제한되지 않고, 본 발명은 첨부된 청구범위의 범위 내에 속하는 모든 구현예들을 포함할 것으로 의도된다. 또한, 도면 및 설명에는 본 발명의 예시적인 구현예들이 개시되어 있으며, 특정 용어가 채용될 수 있지만, 달리 명시되지 않는 한 이는 일반적이고 설명적인 의미로만 사용되며 범위를 제한할 목적으로 사용되지는 않으며, 따라서 본 발명은 그에 제한되지 않는다. 더욱이, 제1(first), 제2(second) 등의 용어의 사용은 순서나 중요성을 나타내는 것이 아니라, 제1(first), 제2(second) 등의 용어는 한 요소를 다른 요소와 구별하는 데 사용된다. 또한, a, an 등의 용어의 사용은 수량의 제한을 의미하는 것이 아니라, 참조 항목 중 적어도 하나가 있음을 의미한다.
따라서 본 발명의 범위는 제공된 예시들에 의해서가 아니라 첨부된 청구범위와 그 법적 등가물에 의해 결정되어야 한다.

Claims (20)

  1. 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크(3200) 아키텍처로서,
    - 서로 통신하도록 구성된 복수의 네트워크 서비스 도메인(3304)을 포함하는 네트워크 서비스 메시 네트워크(3300)로서, 각각의 상기 네트워크 서비스 도메인(3304)은 하기를 포함하는 것인, 상기 네트워크 서비스 메시 네트워크(3300):
    네트워크 서비스 클라이언트(3310)와 통신하도록 구성된 복수의 네트워크 서비스 엔드포인트(3316); 및,
    상기 복수의 네트워크 서비스 엔드포인트(3316)의 가용성을 네트워크 서비스 클라이언트(3310)에 브로드캐스팅하도록 구성된 네트워크 서비스 관리자(3312); 및
    - 상기 네트워크 서비스 메시 네트워크(3300)와 통신하도록 위치하는 애플리케이션 서비스 메시 네트워크(3200)으로서, 서로 통신하도록 구성된 복수의 애플리케이션(3210) 및 상기 복수의 네트워크 서비스 도메인(3304) 중 네트워크 서비스 도메인(3304)을 포함하는, 상기 애플리케이션 서비스 메시 네트워크(3200)
    를 포함하고,
    상기 네트워크 서비스 메시 네트워크(3300) 및 상기 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보를 포함하는 복수의 스마트 계약(5114)이 블록체인 네트워크에 기록되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  2. 제1항에 있어서, 상기 네트워크 서비스 메시 네트워크(3300)는,
    복수의 등록된 전역 변수(global variable)를 포함하는 전역 변수 네임 시스템(3628); 및
    상기 복수의 애플리케이션(3210)으로부터 수신한 메시지에 응답하여 상기 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성된 게시판 서버(3614)
    를 더 포함하는 것이고,
    상기 복수의 스마트 계약(5114)은 등록된 전역 변수를 포함하고;
    상기 복수의 스마트 계약(5114)은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  3. 제2항에 있어서,
    상기 게시판 서버(3614)는 복수의 토픽(topic)(3618)을 포함하며, 각 토픽은 등록된 전역 변수를 포함하는 것이고,
    상기 복수의 토픽(3618) 중 토픽은 상기 복수의 애플리케이션(3210)에 의해 구독되도록 구성되어, 상기 토픽에 포함된 상기 등록된 전역 변수에 대한 업데이트에 관한 정보가 상기 토픽을를 구독하는 애플리케이션에 전송되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  4. 제3항에 있어서,
    상기 애플리케이션에서 나오는 악성 트래픽은 해당 애플리케이션에서 나오는 트래픽을 애플리케이션과 관련된 스마트 계약과 비교하여 식별되고,
    상기 게시판 서버(3614)는 상기 악성 트래픽에 대응하여 완화 조치를 수행하도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  5. 제4항에 있어서,
    상기 완화 조치는 상기 전역 변수 네임 시스템(3628)을 통해 상기 악성 트래픽을 게시하는 것, 상기 영향을 받는 애플리케이션을 격리하는 것, 및 상기 애플리케이션에 의해 수행될 작업을 상기 복수의 애플리케이션(3210) 중 다른 애플리케이션으로 이동시키는 것 중 적어도 하나를 포함하는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  6. 제1항에 있어서,
    상기 네트워크 서비스 메시 네트워크(3300)로부터의 제1 네트워크 슬라이싱 정보 세트를 포함하는 제1 복수의 스마트 계약이 제1 블록체인 네트워크에 기록되고;
    상기 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보의 제2 세트를 포함하는 제2 복수의 스마트 계약이 제2 블록체인 네트워크에 기록되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  7. 제6항에 있어서,
    복수의 등록된 전역 변수를 포함하는 전역 변수 네임 시스템(3628); 및
    게시판 서버(3614)로서, 이에 의하여 사용자로부터 수신된 메시지에 응답하여 상기 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성되는, 상기 게시판 서버(3614)
    를 추가로 포함하고,
    상기 제1 복수의 스마트 계약 및 제2 복수의 스마트 계약은 상기 등록된 전역 변수를 포함하는 것이고;
    상기 제1 복수의 스마트 계약 및 제2 복수의 스마트 계약은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  8. 제1항에 있어서,
    상기 복수의 애플리케이션(3210)은 컨테이너화된 네트워크 기능, 가상 네트워크 기능, 작업자 노드, 서버, 컨테이너, 포드(pod) 및 가상 머신 중 적어도 하나를 포함하는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  9. 제8항에 있어서,
    상기 복수의 네트워크 서비스 도메인(3304)의 적어도 하나의 서브세트는 쿠버네티스(Kubernetes) 설치에 의해 관리되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  10. 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크(3200) 아키텍처로서,
    - 서로 통신하도록 구성된 복수의 네트워크 서비스 도메인(3304)을 포함하는 네트워크 서비스 메시 네트워크(3300)로서, 각각의 상기 네트워크 서비스 도메인(3304)은 하기를 포함하는 것인, 상기 네트워크 서비스 메시 네트워크(3300):
    네트워크 서비스 클라이언트(3310)와 통신하도록 구성된 복수의 네트워크 서비스 엔드포인트(3316); 및
    상기 복수의 네트워크 서비스 엔드포인트(3316)의 가용성을 네트워크 서비스 클라이언트(3310)에 브로드캐스팅하도록 구성된 네트워크 서비스 관리자(3312);
    - 복수의 등록된 전역 변수(global variable)를 포함하는 전역 변수 네임 시스템(3628);
    - 상기 복수의 애플리케이션(3210)으로부터 수신한 메시지에 응답하여 상기 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성된 게시판 서버(3614); 및,
    - 상기 네트워크 서비스 메시 네트워크(3300)와 통신하도록 위치하는 애플리케이션 서비스 메시 네트워크(3200)으로서, 서로 통신하도록 구성된 복수의 애플리케이션(3210) 및 상기 복수의 네트워크 서비스 도메인(3304) 중 네트워크 서비스 도메인(3304)을 포함하는, 상기 애플리케이션 서비스 메시 네트워크(3200)
    를 포함하고,
    상기 복수의 애플리케이션(3210)은 컨테이너화된 네트워크 기능, 가상 네트워크 기능, 작업자 노드, 서버, 컨테이너, 포드(pod) 및 가상 머신 중 적어도 하나를 포함하는 것이고,
    상기 네트워크 서비스 메시 네트워크(3300) 및 상기 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보 및 등록된 전역 변수를 포함하는 복수의 스마트 계약(5114)이 블록체인 네트워크에 기록되는 것이고,
    상기 복수의 스마트 계약은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  11. 제10항에 있어서,
    상기 게시판 서버(3614)는 복수의 토픽(3618)을 포함하며, 각 토픽은 등록된 전역 변수를 포함하고,
    상기 복수의 주제(3618) 중 토픽은 상기 복수의 애플리케이션(3210)에 의해 구독되도록 구성되어, 상기 토픽에 포함된 상기 등록된 전역 변수에 대한 업데이트에 관한 정보가 상기 토픽을 구독하는 애플리케이션에 전송되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  12. 제11항에 있어서,
    상기 애플리케이션에서 나오는 악성 트래픽은 해당 애플리케이션에서 나오는 트래픽을 애플리케이션과 관련된 스마트 계약과 비교하여 식별되고,
    상기 게시판 서버(3614)는 상기 악성 트래픽에 대응하여 완화 조치를 수행하도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  13. 제12항에 있어서,
    상기 완화 조치는 상기 전역 변수 네임 시스템(3628)을 통해 상기 악성 트래픽을 게시하는 것, 상기 영향을 받는 애플리케이션을 격리하는 것, 및 상기 애플리케이션에 의해 수행될 작업을 상기 복수의 애플리케이션(3210) 중 다른 애플리케이션으로 이동시키는 것 중 적어도 하나를 포함하는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  14. 제10항에 있어서,
    상기 네트워크 서비스 메시 네트워크(3300)로부터의 제1 네트워크 슬라이싱 정보 세트를 포함하는 제1 복수의 스마트 계약이 제1 블록체인 네트워크에 기록되고;
    상기 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보의 제2 세트를 포함하는 제2 복수의 스마트 계약이 제2 블록체인 네트워크에 기록되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  15. 제10항에 있어서,
    상기 복수의 네트워크 서비스 도메인(3304)의 적어도 하나의 서브세트는 쿠버네티스(Kubernetes) 설치에 의해 관리되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  16. 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크(3200) 아키텍처로서,
    - 하기를 포함하는, 네트워크 서비스 메시 네트워크(3300):
    서로 통신하도록 구성된 복수의 네트워크 서비스 도메인(3304)으로서, 각각의 상기 네트워크 서비스 도메인(3304)은 하기를 포함하는 것인, 상기 복수의 네트워크 서비스 도메인(3304):
    네트워크 서비스 클라이언트(3310)와 통신하도록 구성된 복수의 네트워크 서비스 엔드포인트(3316), 및
    상기 복수의 네트워크 서비스 엔드포인트(3316)의 가용성을 네트워크 서비스 클라이언트(3310)에 브로드캐스팅하도록 구성된 네트워크 서비스 관리자(3312);
    복수의 등록된 전역 변수를 포함하는 전역 변수 네임 시스템(3628);
    및
    게시판 서버(3614)로서, 이에 의하여 상기 복수의 애플리케이션(3210)으로부터 수신된 메시지에 응답하여 상기 복수의 등록된 전역 변수에 대한 정보를 업데이트하도록 구성되는 상기 게시판 서버(3614);
    및
    - 상기 네트워크 서비스 메시 네트워크(3300)와 통신하도록 위치하는 애플리케이션 서비스 메시 네트워크(3200)로서, 서로 통신하도록 구성된 복수의 애플리케이션(3210) 및 상기 복수의 네트워크 서비스 도메인(3304) 중 네트워크 서비스 도메인(3304)을 포함하는, 상기 애플리케이션 서비스 메시 네트워크(3200)
    을 포함하고,
    상기 복수의 애플리케이션(3210)은 컨테이너화된 네트워크 기능, 가상 네트워크 기능, 작업자 노드, 서버, 컨테이너, 포드(pod) 및 가상 머신 중 적어도 하나를 포함하는 것이고;
    상기 복수의 네트워크 서비스 도메인(3304)의 적어도 하나의 서브세트는 쿠버네티스(Kubernetes)설치에 의해 관리되는 것이고,
    상기 네트워크 서비스 메시 네트워크(3300)로부터의 제1 네트워크 슬라이싱 정보 세트와 등록된 전역 변수를 포함하는 제1 복수의 스마트 계약이 제1 블록체인 네트워크에 기록되며;
    상기 애플리케이션 서비스 메시 네트워크(3200)로부터의 네트워크 슬라이싱 정보의 제2 세트와 등록된 전역 변수를 포함하는 제2 복수의 스마트 계약이 제2 블록체인 네트워크에 기록되고;
    상기 제1 복수의 스마트 계약 및 제2 복수의 스마트 계약은 그에 포함된 등록된 전역 변수의 변경에 응답하여 업데이트되도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크.
  17. 제16항에 있어서,
    상기 게시판 서버(3614)는 복수의 토픽(3618)을 포함하며, 각 토픽은 등록된 전역 변수를 포함하고,
    상기 복수의 토픽(3618) 중 토픽은 상기 복수의 애플리케이션(3210)에 의해 구독되도록 구성되어, 상기 토픽에 포함된 상기 등록된 전역 변수에 대한 업데이트에 관한 정보가 상기 토픽을 구독하는 애플리케이션에 전송되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  18. 제17항에 있어서,
    상기 애플리케이션에서 나오는 악성 트래픽은 해당 애플리케이션에서 나오는 트래픽을 애플리케이션과 관련된 스마트 계약과 비교하여 식별되고,
    상기 게시판 서버(3614)는 상기 악성 트래픽에 대응하여 완화 조치를 수행하도록 구성되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  19. 제18항에 있어서,
    상기 완화 조치는 상기 전역 변수 네임 시스템(3628)을 통해 상기 악성 트래픽을 게시하는 것, 상기 영향을 받는 애플리케이션을 격리하는 것, 및 상기 애플리케이션에 의해 수행될 작업을 상기 복수의 애플리케이션 중 다른 애플리케이션으로 이동시키는 것 중 적어도 하나를 포함하는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
  20. 블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크(3200) 아키텍처로서,
    - 서로 통신하도록 구성된 복수의 네트워크 서비스 도메인(3304)을 포함하는 네트워크 서비스 메시 네트워크(3300)로서, 각각의 상기 네트워크 서비스 도메인(3304)은 하기를 포함하는 것인, 상기 네트워크 서비스 메시 네트워크(3300):
    네트워크 서비스 클라이언트(3310)와 통신하도록 구성된 복수의 네트워크 서비스 엔드포인트(3316); 및
    상기 복수의 네트워크 서비스 엔드포인트(3316)의 가용성을 네트워크 서비스 클라이언트(3310)에 브로드캐스팅하도록 구성된 네트워크 서비스 관리자(3312); 및
    - 상기 네트워크 서비스 메시 네트워크(3300)와 통신하도록 위치하는 애플리케이션 서비스 메시 네트워크(3200)으로서, 서로 통신하도록 구성된 복수의 애플리케이션(3210) 및 상기 복수의 네트워크 서비스 도메인(3304) 중 네트워크 서비스 도메인(3304)을 포함하는, 상기 애플리케이션 서비스 메시 네트워크(3200)
    을 포함하고,
    상기 네트워크 서비스 메시 네트워크(3300) 및 애플리케이션 서비스 메시 네트워크(3200)로부터의 트래픽 정보를 포함하는 복수의 스마트 계약이 블록체인 네트워크에 기록되는 것인,
    블록체인 기반 네트워크 및 애플리케이션 서비스 메시 네트워크 아키텍처.
KR1020237038150A 2021-04-09 2022-04-08 제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약 KR20240004463A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202163172743P 2021-04-09 2021-04-09
US63/172,743 2021-04-09
US17/302,552 US11283865B2 (en) 2017-09-13 2021-05-06 Service meshes and smart contracts for zero-trust systems
US17/302,552 2021-05-06
PCT/US2022/071616 WO2022217267A1 (en) 2021-04-09 2022-04-08 Service meshes and smart contracts for zero-trust systems

Publications (1)

Publication Number Publication Date
KR20240004463A true KR20240004463A (ko) 2024-01-11

Family

ID=81392864

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237038150A KR20240004463A (ko) 2021-04-09 2022-04-08 제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약

Country Status (2)

Country Link
KR (1) KR20240004463A (ko)
WO (1) WO2022217267A1 (ko)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190228409A1 (en) * 2017-09-13 2019-07-25 Vijay Madisetti Transaction Pools Using Smart Contracts and Blockchains
WO2019195639A1 (en) * 2018-04-05 2019-10-10 Neji, Inc. Programmatic creation of blockchains

Also Published As

Publication number Publication date
WO2022217267A1 (en) 2022-10-13

Similar Documents

Publication Publication Date Title
US11316690B2 (en) Blockchain token-based cloud orchestration architecture for discrete virtual network instances
US11283865B2 (en) Service meshes and smart contracts for zero-trust systems
US11528147B2 (en) Verifying integrity and secure operations of cloud-based software services
US10243743B1 (en) Tokens or crypto currency using smart contracts and blockchains
Bajoudah et al. Toward a decentralized, trust-less marketplace for brokered IoT data trading using blockchain
US20210117962A1 (en) Methods and systems for digital reward processing
US10460283B2 (en) Smart contract optimization for multiparty service or product ordering system
US20190228409A1 (en) Transaction Pools Using Smart Contracts and Blockchains
US11316933B2 (en) Service meshes and smart contracts for zero-trust systems
US20190173854A1 (en) Decentralized information sharing network
KR20210024994A (ko) 디지털 자산 교환
US11201739B2 (en) Systems and methods for tying token validity to a task executed in a computing system
US11017469B2 (en) System and method for manufacturing and trading securities and commodities
TW202026997A (zh) 基於區塊鏈的商品購置方法和裝置
KR20190000747A (ko) 블록체인기법을 이용한 전자상거래 방식
EP3799401B1 (en) Systems and methods for facilitating authentication of emails sent by 3rd parties
US11201738B2 (en) Systems and methods for associating a user with a task executed in a computing system
Lim et al. Blockchain technologies in E-commerce: social shopping and loyalty program applications
TW202314621A (zh) 基於非同質化代幣之商務屬性
US11893613B2 (en) Systems, manufacture, and methods for controlling access to resources
Viriyasitavat et al. Augmenting cryptocurrency in smart supply chain
CN115809909A (zh) 区块链网络拥塞自适应数字资产事件处置系统和方法
EP4142206A1 (en) Verifying integrity and secure operations of cloud-based software services
CN111833193A (zh) 提供具有集中式和分布式数据结构的专利所有权保险的系统和方法
KR20240004463A (ko) 제로-트러스트 시스템을 위한 서비스 메시 및 스마트 계약

Legal Events

Date Code Title Description
A201 Request for examination