KR20210038272A - 블록 체인 시스템 - Google Patents

블록 체인 시스템 Download PDF

Info

Publication number
KR20210038272A
KR20210038272A KR1020190146359A KR20190146359A KR20210038272A KR 20210038272 A KR20210038272 A KR 20210038272A KR 1020190146359 A KR1020190146359 A KR 1020190146359A KR 20190146359 A KR20190146359 A KR 20190146359A KR 20210038272 A KR20210038272 A KR 20210038272A
Authority
KR
South Korea
Prior art keywords
block
transaction
miners
hash
present
Prior art date
Application number
KR1020190146359A
Other languages
English (en)
Other versions
KR102386922B1 (ko
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
Application filed by 주식회사 샌드스퀘어 filed Critical 주식회사 샌드스퀘어
Publication of KR20210038272A publication Critical patent/KR20210038272A/ko
Application granted granted Critical
Publication of KR102386922B1 publication Critical patent/KR102386922B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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
    • 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
    • H04L2209/38—
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 발명은 블록 체인 시스템이 제공된다. 상기 블록 체인 시스템은, 블록을 생성하는 m개의 채굴자(formulator)를 포함하는 채굴 그룹 및 상기 블록의 검증을 수행하는 옵저버 노드를 포함하되, 상기 채굴 그룹은 채굴자 순위에 따라 구별되는 블록 생성자, 동기화 그룹 및 대기 그룹을 포함하고, 상기 블록 생성자는 상기 m개의 채굴자 중 1순위의 채굴자를 포함하여 상기 블록을 생성하고, 상기 동기화 그룹은 상기 m개의 채굴자 중 2순위 내지 n순위의 채굴자를 포함하고, 상기 대기 그룹은 상기 m개의 채굴자 중 n+1순위 내지 m순위의 채굴자를 포함하고, 상기 1순위의 채굴자가 블록을 생성하면 2순위 내지 m순위의 채굴자의 상기 채굴자 순위가 각각 1순위 내지 m-1순위로 변경된다.

Description

블록 체인 시스템{Blockchain system}
본 발명은 블록 체인 시스템에 관한 것이다.
블록체인은 비트코인 등과 같은 분산형 가상화폐 거래 시스템에서 노드들간 서로 주고받는 가상화폐의 거래(트랜잭션)를 지속적으로 기록하는 거래기록장부의 기능을 가지고 있다. 이와 같이 거래기록장부의 기능을 하는 블록체인이 분산형 가상화폐 거래 시스템에서 필요한 이유는 가상화폐가 실물의 물리적 화폐로 존재하는 것이 아니라 가상에서만 존재하기 때문이다.
따라서, 현재 거래하는 가상화폐가 정당성을 가지고 있는가를 판단할 수 있는 자료는 최초 생성시부터 현재까지 일관성 있게 정당성을 가지는지 여부를 확인는 것이다. 이를 위해서는, 가상화폐가 최초 생성될 때부터 현재까지 거래 내역을 역추적할 수 있어야 한다.
은행과 같은 중앙서버가 총괄적으로 화폐를 관리하는 경우에는 중앙서버에서 가상화폐 거래기록을 총괄적으로 기록한다. 반면, 블록체인과 같은 암호화폐의 경우는 분산형 노드들로 이루어진 분산형 시스템 내에서 노드들에 의해 기록된다. 또한, 블록체인이 거래될 때마다 그 거래내용을 암호화하여 블록을 생성하고 새롭게 생성된 블록을 블록체인에 결합하여 거래장부를 업데이트 한다.
블록체인을 이용하는 가상화폐 거래 시스템에서는 시시각각으로 이루어지는 거래가 전체 노드에 전파되고, 새로운 거래기록은 블록으로 암호화되며 생성되며, 생성된 새로운 블록은 다시 기존의 블록체인에 결합되는 작업이 끊임없이 진행된다. 이와 같이, 새롭게 이루어지는 거래내역들을 함께 묶어서 일정한 주기동안 한 개의 새로운 블록을 생성하고, 그 블록이 정당성을 가지면 기존의 블록체인에 연결하는 과정을 소위 '작업증명(Proof of work)'이라고 한다.
이를 위해서는 작업증명을 수행하는 참여자(이하, 채굴자)들에게 적극적으로 참여할 수 있는 보상 동기를 주어야 하는데, 이 부분이 소위 말하는 '채굴'이다. 즉, 채굴을 수행하는 채굴자가 새로운 블록을 생성하면 일정한 가상화폐를 보상으로 지불받게 된다.
다만, 채굴의 특성상, 채굴은 참여하는 컴퓨터 능력에 의존할 수밖에 없기 때문에, 컴퓨터 능력을 집중화한 소수의 개체 또는 단체들에게 채굴이 집중되는 경향을 보이게 되는 점에서 문제가 있었다. 또한, 가상화폐 시스템의 신규화폐 공급은 채굴자가 채굴한 가상화폐를 통해 이루어지기 때문에 가상화폐가 소수의 과점 채굴자에게 편중되어 가상화폐의 빈익빈 부익부 현상을 가중시킬 수 있다는 점에서도 문제가 있었다.
본 발명의 목적은, 채굴자 간의 합의된 블록 생성 순서에 따라 블록을 생성하고, 복수의 옵저버 노드를 이용하여 블록을 검증함으로써, 완성된 블록의 검증 및 전파속도를 높이고, 의도치 않은 포크가 발생시키는 것을 방지할 수 있는 블록체인 컨센서스를 제공하는 것이다.
본 발명의 목적들은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있고, 본 발명의 실시예에 의해 보다 분명하게 이해될 것이다. 또한, 본 발명의 목적 및 장점들은 특허 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.
상기 기술적 과제를 달성하기 위한 본 발명의 실시예에 따른 블록 체인 시스템은, 블록을 생성하는 m개의 채굴자(formulator)를 포함하는 채굴 그룹 및 상기 블록의 검증을 수행하는 옵저버 노드를 포함하되, 상기 채굴 그룹은 채굴자 순위에 따라 구별되는 블록 생성자, 동기화 그룹 및 대기 그룹을 포함하고, 상기 블록 생성자는 상기 m개의 채굴자 중 1순위의 채굴자를 포함하여 상기 블록을 생성하고, 상기 동기화 그룹은 상기 m개의 채굴자 중 2순위 내지 n순위의 채굴자를 포함하고, 상기 대기 그룹은 상기 m개의 채굴자 중 n+1순위 내지 m순위의 채굴자를 포함하고, 상기 1순위의 채굴자가 블록을 생성하면 2순위 내지 m순위의 채굴자의 상기 채굴자 순위가 각각 1순위 내지 m-1순위로 변경된다.
본 발명은, 레벨 트리 구조로 트랜잭션을 관리하고 레벨 트리 루트 해시를 사용함으로써, 계산 비용을 줄이고 검증 성능 및 처리 속도를 향상시킬 수 있다.
또한, 본 발명은, 트랜잭션에 불필요한 서명 수를 줄이고 한 쌍의 키만 사용함으로써, 트랜잭션 및 검증과정을 최적화시키고, 트랜잭션비용 및 자원소모를 감소시킬 수 있다.
본 발명의 효과는 전술한 효과에 한정되지 않으며, 본 발명의 당업자들은 본 발명의 구성에서 본 발명의 다양한 효과를 쉽게 도출할 수 있다.
도 1은 기존의 블록 체인 구조 및 본 발명의 실시예에 따른 블록 체인의 구조를 비교 설명하기 위한 도면이다.
도 2는 본 발명의 실시예에 따른 블록 체인의 트랜잭션 내에서의 단일 서명 트랜잭션 및 다중 서명 트랜잭션을 설명하기 위한 도면이다.
도 3은 본 발명의 실시예에 따른 UTXO 형식과 종래의 UTXO와의 차이를 설명하기 위한 도면이다.
도 4는 본 발명의 실시예에 따른 블록 직렬화를 설명하기 위한 도면이다.
도 5는 본 발명의 실시예에 따른 트랜잭션 내 서명의 유효성에 대해 설명하기 위한 도면이다.
도 6은 본 발명의 실시예에 따른 트랜잭션 내 노드들을 설명하기 위한 도면이다.
도 7은 본 발명의 다른 실시예에 따른 멀티 노드 병렬 트랜잭션 처리를 설명하기 위한 도면이다.
도 8은 본 발명의 또 다른 실시예에 따른 자산 트랜잭션을 설명하기 위한 도면이다.
도 9는 본 발명의 또 다른 실시예에 따른 발행 트랜잭션을 설명하기 위한 도면이다.
도 10은 본 발명의 실시예에 따른 토큰 체인 및 토큰 계약을 설명하기 위한 도면이다.
도 11은 본 발명의 실시예에 따른 분산형 응용 프로그램 트랜잭션과 토큰 체인의 관계에 대해 설명하기 위한 도면이다.
도 12는 본 발명의 실시예에 따른 점수 계산 및 순위 목록을 설명하기 위한 도면이다.
도 13은 본 발명의 몇몇 실시예들에 따른 채굴자 목록 동기화를 설명하기 위한 도면이다.
도 14는 본 발명의 실시예에 따른 옵저버 노드와 채굴자 그룹의 관계에 대해 설명하기 위한 도면이다.
도 15는 본 발명의 실시예에 따른 옵저버 노드에 의한 포크 예방을 설명하기 위한 도면이다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 따라서, 본 명세서의 예 및 실시 예는 본 개시의 범위를 제한하는 것으로 해석되어서는 안된다.
본 명세서에서 사용된 "컴퓨터"는 다음에 따라 데이터를 조작할 수 있는 임의의 기계, 장치, 회로, 구성 요소 또는 모듈, 또는 임의의 기계, 장치, 회로, 구성 요소, 모듈 등의 시스템을 의미한다. 예를 들어, 프로세서, 마이크로 프로세서, 중앙 처리 장치, 범용 컴퓨터, 클라우드, 슈퍼 컴퓨터, 개인용 컴퓨터, 랩톱 컴퓨터, 팜탑 컴퓨터, 모바일 장치, 태블릿 컴퓨터, 노트북 컴퓨터, 데스크탑 컴퓨터, 워크 스테이션 컴퓨터, 서버 등, 또는 프로세서, 마이크로 프로세서, 중앙 처리 장치, 범용 컴퓨터, 슈퍼 컴퓨터, 개인용 컴퓨터, 랩톱 컴퓨터, 팜탑 컴퓨터, 모바일 장치, 태블릿 컴퓨터, 노트북 컴퓨터, 데스크탑 컴퓨터, 워크 스테이션 컴퓨터, 서버 등 을 포함할 수 있다.
본 개시에서 사용되는 "서버"는 클라이언트-서버 아키텍처의 일부로서 연결된 클라이언트들에 대한 서비스를 수행하기위한 적어도 하나의 애플리케이션 및/또는 적어도 하나의 컴퓨터를 포함하는 소프트웨어 및/또는 하드웨어의 임의의 조합을 의미한다. 적어도 하나의 서버 애플리케이션은 예를 들어, 클라이언트로 응답을 다시 전송함으로써 클라이언트로부터의 서비스 요청에 대한 연결을 수락할 수 있는 애플리케이션 프로그램을 포함할 수 있지만, 이에 제한되지는 않는다. 서버는 최소한의 사람의 지시로 장시간 동안 무인 워크로드 하에서 적어도 하나의 애플리케이션을 실행하도록 구성될 수 있습니다. 서버는 복수의 컴퓨터를 포함할 수 있으며, 적어도 하나의 애플리케이션은 워크로드에 따라 컴퓨터들 간에 분할된다. 예를 들어 간단한 로드 중 하나 이상의 응용 프로그램이 단일 컴퓨터에서 실행될 수 있다. 그러나, 로드량이 많은 경우 하나 이상의 응용 프로그램을 실행하려면 여러 대의 컴퓨터가 필요할 수 있다. 서버 또는 해당 컴퓨터가 있는 경우 워크 스테이션으로도 이용할 수 있다.
본 명세서에서 사용되는 "데이터베이스"는 적어도 하나의 애플리케이션 및/또는 적어도 하나의 컴퓨터를 포함하는 소프트웨어 및/또는 하드웨어의 임의의 조합을 의미한다. 데이터베이스는 구조화된 기록 모음 또는 데이터 모델에 따라 구성된 데이터를 포함할 수 있다. 데이터 모델은 예를 들어, 관계형 모델, 계층적 모델, 네트워크 모델 등이 포함될 수 있으며, 위에 적힌 모델들로 제한되지 않는다. 데이터베이스는 기술에서 알려진 대로 데이터베이스 관리 시스템 애플리케이션(DBMS)을 포함할 수 있다. 최소한 하나의 애플리케이션은, 예를 들어, 클라이언트로부터의 서비스 요청에 대한 연결을 수신할 수 있는 애플리케이션 프로그램을 포함할 수 있지만, 이에 한정되는 것은 아니다. 데이터베이스는 최소한의 사람 지시에 의해 장시간 무인으로, 종종 많은 업무량 하에서 적어도 하나의 애플리케이션을 실행하도록 구성될 수 있다.
본 개시에서 사용되는 "통신 링크"는 적어도 2개의 지점들 사이에서 데이터 또는 정보를 전달하는 유무선 매체를 의미한다. 유선 또는 무선 매체는 예를 들어, 금속 도체 링크, 무선 주파수(RF) 통신 링크, 적외선 (IR) 통신 링크, 또는 광 통신 링크 등을 제한없이 포함할 수 있다. RF 통신 링크는 예를 들어 WiFi, WiMAX, IEEE 802.11, DECT, 0G, 1G, 2G, 3G, 4G 또는 5G 셀룰러 표준, 블루투스 등을 포함할 수 있다.
본 개시에서 사용되는 "네트워크"는, 예를 들어, 근거리 통신망 (LAN), 광역 통신망 (WAN), 대도시 통신망 (MAN), 및 개인 영역 네트워크(PAN), 캠퍼스 영역 네트워크, 회사 영역 네트워크, 글로벌 영역 네트워크(GAN), 광대역 영역 네트워크(BAN), 셀룰러 네트워크, 인터넷, 클라우드 네트워크 등, 또는 전술 한 것의 임의의 조합으로써, 무선 및/또는 유선 통신 매체. 이러한 네트워크는 TCP/IP, IRC로 제한되지 않는 다양한 프로토콜을 실행할 수 있다.
본 명세서에서 사용되는 용어 "포함하는", "포함하는" 및 그 변형은, 달리 명시되지 않는 한 "포함하지만 이에 제한되지 않는"을 의미한다.
명시적으로 달리 명시되지 않는 한, 서로 통신하는 장치는 서로 지속적으로 통신할 필요는 없다. 또한, 서로 통신하는 장치는 하나 이상의 중개자를 통해 직접 또는 간접적으로 통신할 수 있다.
프로세스 단계, 방법 단계, 알고리즘 등이 순차적으로 설명될 수 있지만, 이러한 프로세스, 방법 및 알고리즘은 교대 순서대로 동작하도록 구성될 수 있다. 다시 말해서, 설명될 수 있는 임의의 순서 또는 단계 순서는 반드시 단계들이 그 순서로 수행되어야 한다는 요구사항을 나타내는 것은 아니다. 반드시 단계를 순서대로 수행할 요구 사항을 표시하지 않습니다. 본 명세서에 기술된 프로세스, 방법 및 알고리즘의 단계는 임의의 순서로 수행될 수 있다. 또한, 일부 단계들이 동시에 수행될 수 있다.
단일 장치 또는 물품이 본 명세서에 기술될 때, 하나 이상의 장치 또는 물품이 단일 장치 또는 물품 대신 사용될 수 있다. 유사하게, 하나의 장치 또는 물품이 본 명세서에 기술되는 경우, 하나 이상의 장치 또는 물품이 하나의 장치 또는 물품 대신 사용될 수 있다. 장치의 기능 또는 특징은 대안적으로 그러한 기능 또는 특징을 갖는 것으로 명시되지 않은 하나 이상의 다른 장치에 의해 구현될 수 있다.
본 명세서에서 사용되는 "컴퓨터 판독 가능 저장 매체"는 컴퓨터에 의해 판독될 수 있는 데이터 (예를 들어, 명령)를 제공하는데 참여하는 임의의 매체를 의미한다. 이러한 매체는 비휘발성 매체, 휘발성 매체 및 전송 매체를 포함하여 많은 형태를 취할 수 있다. 비휘발성 매체는 예를 들어, 광학 또는 자기 디스크 및 기타 영구 메모리. 휘발성 매체는 동적 랜덤 액세스 메모리 (DRAM)를 포함할 수 있다. 전송 매체는 시스템 버스를 구성하는 와이어를 포함하여 동축 케이블, 구리 와이어 및 광섬유를 포함할 수 있다. 전송 매체는 무선 주파수 (RF) 및 적외선 (IR) 데이터 통신 동안 발생된 것과 같은 음향 파, 광파 및 전자기 방출을 포함하거나 전달할 수 있다. 컴퓨터 판독가능 매체의 일반적인 형태는, 예를 들어 플로피 디스크, 플렉시블 디스크, 하드 디스크, 자기 테이프, 임의의 다른 자기 매체, CD-ROM, DVD, 임의의 다른 광학 매체, 펀치 카드, 종이 테이프, 구멍 패턴을 갖는 임의의 다른 물리적 매체, RAM, PROM, EPROM, FLASH-EEPROM, 기타 메모리 칩 또는 카트리지, 여기에 기술된 반송파 또는 컴퓨터가 읽을 수 있는 기타 매체 등을 포함할 수 있다. 컴퓨터 판독가능 매체에는 "클라우드"가 포함될 수 있으며, 여기에는 여러 대의(예: 수천 대의) 컴퓨터 상에서 여러 대의(예: 수천 대의) 메모리 캐시에 걸쳐 파일을 배포하는 것이 포함된다.
컴퓨터에 명령 시퀀스를 전달하는데 다양한 형태의 컴퓨터 판독 가능 매체가 포함될 수 있다. 예를 들어, 명령 시퀀스 (i)는 RAM에서 프로세서로 전달될 수 있고, (ii) 무선 전송 매체를 통해 전달될 수 있으며, (iii) WiFi, WiMAX, IEEE 802.11, DECT, 0G, 1G, 2G, 3G, 4G 및 5G 셀룰러 표준, 블루투스 등을 포함하여 기타 다양한 형식, 기준 또는 프로토콜에 따라 형식화 될 수 있다.
도 1은 기존의 블록 체인 구조 및 본 발명의 실시예에 따른 블록 체인의 구조를 비교 설명하기 위한 도면이다.
도 1을 참조하면, 기존 블록체인의 구조는 어카운트 구조(account structure) 혹은 UTXO(Unspent Transaction Output, 미사용 트랜잭션 출력) 구조 중 하나만 선택하여 체인을 구성한다. 이 때, 어카운트 구조는 UTXO 구조에 비해서 상대적으로 적은 데이터를 필요로 하고 처리가 빠르다. 반면, UTXO 구조는 어카운트 구조에 비해서 필요한 데이터가 상대적으로 큰 용량을 차지한다. 단, UTXO 구조 트랜잭션(20)은 어카운트 주소를 체인에 등록하는 절차 없이 바로 사용가능 하므로, 매 트랜잭션시 키를 생성하여 사용하는 경우 보안적 측면의 강점을 가질 수 있다.
본 발명의 몇몇 실시예들에 따른 블록 체인은 어카운트 구조 혹은 UTXO 구조가 상호 연동가능 하도록 구성되었으며, 어카운트 구조에서 UTXO 구조로, UTXO 구조에서 어카운트 구조로의 이동은 중간과정을 거치지 않고 자유롭게 전송이 가능하다. 본 발명의 몇몇 실시예들에 따른 블록 체인은 UTXO 구조를 사용해서 트랜잭션을 하는 것도 가능하고, 어카운트 구조를 사용해서 트랜잭션을 하는 것도 모두 가능할 수 있다.
기존의 UTXO 구조 트랜잭션(10)은 트랜잭션 헤더(transaction header), 입력 인덱스(vin), 출력 인덱스(vout) 및 서명(signatures)을 포함할 수 있다. 입력 인덱스(vin)는 해시 트랜잭션 아이디(TxID(hash)) 및 난스(Nonce)(N)를 포함할 수 있다. UTXO 구조 트랜잭션(20)도 트랜잭션 헤더(transaction header), 입력 인덱스(vin), 출력 인덱스(vout) 및 서명(signatures)을 포함할 수 있다. 입력 인덱스(vin)는 트랜잭션 아이디(height, index) 및 난스(N)를 포함할 수 있다.
도 1의 기존의 UTXO 구조 트랜잭션(10)은 3개의 입력 인덱스(vin), 출력 인덱스(vout) 및 서명(signatures)을 포함하는 것으로 도시하였으나, 이는 예시에 불과할 뿐, 입력 인덱스(vin), 출력 인덱스(vout) 및 서명(signatures)의 개수는 이에 제한되는 것은 아니다. 도 1의 UTXO 구조 트랜잭션(20)도 3개의 입력 인덱스(vin) 및 출력 인덱스(vout)와 1개의 서명(signatures)을 포함하는 것으로 도시하였으나, 이는 예시에 불과할 뿐, 입력 인덱스(vin), 출력 인덱스(vout) 및 서명(signatures)의 개수는 이에 제한되는 것은 아니다.
기존의 UTXO 구조 블록(50)에서는 해시 트랜잭션 아이디(TxID(hash))가 해시(hash)를 사용하여 생성되고, 생성된 해시 트랜잭션 아이디(TxID(hash))는 서명(Signature)에 사용될 수 있다. 그러나, 이러한 해시 트랜잭션 아이디(TxID(hash))를 통해서는 블록의 위치와 트랜잭션의 위치를 직접 알 수 없고, 상기 블록의 위치와 트랜잭션의 위치를 알기 위해서는 추가적인 인덱싱(Indexing)이 필요할 수 있다. 기존의 UTXO 구조 트랜잭션(10)은 이 과정에서 큰 자원을 소모하며, 해시 트랜잭션 아이디(TxID(hash))를 표시하기 위해 32바이트의 큰 용량이 입력 인덱스(Vin)에 사용될 수 있다. 기존의 UTXO 구조 트랜잭션(10)은 또한, 4바이트의 난스(N)를 포함할 수 있다.
반면, 본 발명의 몇몇 실시예들에 따른 UTXO 구조 트랜잭션(20)은 32바이트의 해시 트랜잭션 아이디(TxID(hash))에서 크기가 줄어든 6바이트의 트랜잭션 아이디(TxID)를 포함할 수 있다. UTXO 구조 트랜잭션(20)의 트랜잭션 아이디(TxID)의 구성은 하기와 같다.
TxID:{Height(4), Index(2)}
즉, 트랜잭션 아이디(TxID)는 4바이트의 블록의 높이(height)와 2바이트의 블록 내 트랜잭션의 위치(index)를 포함할 수 있다. UTXO 구조 트랜잭션(20)은 32바이트의 해시 트랜잭션 아이디(TxID(hash)) 대신 6바이트의 트랜잭션 아이디(TxID)를 사용함으로써 용량을 감소시킬 수 있다. 또한, 본 발명의 몇몇 실시예들에 따른 UTXO 구조 트랜잭션(20)은 난스(N)도 2바이트를 이용하여 기존의 UTXO 구조 트랜잭션(10)의 난스(N)에 비해서 용량을 절반으로 감소시킬 수 있다.
본 발명의 몇몇 실시예들에 따른 블록 체인의 UTXO 구조 트랜잭션(20)은 트랜잭션 아이디 및 난스(N)의 용량이 감소됨에 따라, 직렬화, 처리과정, 트랜잭션 및 검색 등 모든 부분에서 처리 속도가 향상될 수 있다. 또한, 기존의 UTXO 구조 트랜잭션(10)을 본 실시예들에 따른 블록 체인의 UTXO 구조 트랜잭션(20)으로 바꾸면 약 33퍼센트의 용량을 더 절감할 수 있고, 이에 따라 전반적인 처리 성능이 40프로정도 향상될 수 있다.
트랜잭션에 필요한 트랜잭션 아이디는 모두 완성된 UTXO 구조 트랜잭션(20)에서 참조될 수 있다. 또한, 완성된 블록의 경우 블록의 높이(height) 및 블록 내 트랜잭션의 위치(index)가 고정되므로, UTXO 구조 트랜잭션(20)은 트랜잭션의 해시를 사용하지 않아도 모두 동일한 값을 참조하게 된다.
본 발명의 몇몇 실시예에 따른 블록체인의 네트워크는, 고속 트랜잭션 처리와 그에 기반한 분산형 응용 프로그램(Divisional Applications)의 완전히 독립적인 환경을 지원하도록 설계될 수 있다. 상기 고속 트랜잭션은 블록당 향상된 생성 시간과 트랜잭션 볼륨을 의미할 수 있다. 이러한 고속 트랜잭션을 위해서, 본 실시예들에 따른 블록 체인은 검증 속도를 높이고 데이터 용량을 줄이며, 멀티 노드 병렬 트랜잭션 처리를 통한 병렬 확장이 가능하도록 블록 구조가 기존과 다르게 재설계될 수 있다. 또한, 본 실시예들에 따른 블록 체인은 독립적인 체인 구성 및 분산형 응용 프로그램 실행을 통해 체인 간의 프로세스 간섭을 줄이고 각 분산형 응용 프로그램이 최적의 수준에서 수행되도록 할 수 있다.
트랜잭션을 수행하기 위해 본 발명의 몇몇 실시예들에 따른 블록체인은 블록 및 트랜잭션을 통해 소유권을 확인하고 전송한다. 이러한 특성을 고려할 때, 본 실시예들에 따른 블록체인은 직렬화를 빠르게 하고, 직렬화 해제 단계에서 병렬로 블록 검증을 수행하고, 라이트 노드(Light Node)와 그에 따른 검증을 수행하고, 멀티 노드 병렬 트랜잭션 처리를 지원하는 것을 가능하게 할 수 있다.
본 발명의 몇몇 실시예들에 따른 블록 체인의 코인의 소유권은 UTXO의 소유권과 동일하므로 UTXO를 사용하여 트랜잭션을 생성할 수 있다. 트랜잭션은 UTXO 생성시 삽입된 공용 키(public key)와 개인 키(private key) 입력을 이용하여 서명(Signature)을 통해 검증된다. 따라서, UTXO를 주체로 사용하는 계정은 하나의 공용 키(public key)와 개인 키(private key)를 한 쌍으로 볼 수 있다.
일반적으로 트랜잭션은 이전에 발생한 트랜잭션의 산출물로부터 UTXO를 입력 받은 다음 그 결과물을 다시 입력하는 것으로 구성될 수 있다. 그러나, 이것은 같은 주체가 트랜잭션을 수행하고 있더라도 복수의 서명(Signature)이 입력되기 때문에 불필요하게 트랜잭션 규모를 부풀릴 수 있다.
반면에, 본 실시예들에 따른 블록 체인의 단일 계정은 단일 주소를 가지며, 트랜잭션 당 하나의 서명(Signature)만이 필요할 수 있다. 본 발명의 몇몇 실시예들에 따른 블록 체인은 어카운트 방식일 때, 트랜잭션에 필요한 서명(Signature) 수를 줄이고 트랜잭션과 검증을 최적화하기 위해 계정당 한 쌍의 키만 사용할 수 있다.
도 2는 본 발명의 실시예에 따른 블록 체인의 트랜잭션 내에서의 단일 서명 트랜잭션 및 다중 서명 트랜잭션을 설명하기 위한 도면이다.
도 2를 참조하면, 본 발명은 계정당 하나의 공용 키(public key)와 개인 키(private key) 쌍을 사용하므로 단일 서명 트랜잭션(30)에는 단일 서명(single signature)이 존재한다.
구체적으로, 단일 서명 트랜잭션(30)은 서명(signature), 입력 인덱스(vin) 및 출력 인덱스(vout)로 구성될 수 있다. 입력 인덱스(vin)는 트랜잭션 아이디(height, index) 및 난스(N)로 구성될 수 있다. 또한, 출력 인덱스(vout)는 금액(Amount) 및 주소(Address)로 구성될 수 있다. 여기서, 입력 인덱스(vin)에 대한 UTXO 입력의 공용 키(public key)는 모두 동일한 값이어야 한다. 그러나, 다중 서명(Multiple Signature) 기능을 제공할 수 없으므로 트랜잭션은 다중 서명 트랜잭션(40)과 같이 확장되어 다중 서명(Multiple Signature)을 지원한다.
다중 서명 트랜잭션(40)은 서명(signature), 입력 인덱스(vin) 및 출력 인덱스(vout)를 포함할 수 있다. 또한, 출력 인덱스(vout)는 금액(Amount) 및 주소(Address)를 포함할 수 있다.
블록 체인에서는 원칙적으로 일치하는 공개 키 목록을 가진 UTXO만 입력 인덱스(Vin)를 입력할 수 있으며, 이것은 단일 계정에서 소유하는 단일 서명 UTXO를 포함하는 다중 서명 UTXO를 허용한다. 따라서, 입력 인덱스(vin)에 포함된 주소 수는 트랜잭션에 포함된 서명(signature) 수와 같아야 하며, 각 입력 인덱스(vin)의 주소 목록은 같아야 한다.
도 3은 본 발명의 실시예에 따른 UTXO 형식과 종래의 UTXO와의 차이를 설명하기 위한 도면이고, 도 4는 본 발명의 실시예에 따른 블록 직렬화를 설명하기 위한 도면이다.
도 3 및 도 4를 참조하면, 기존의 UTXO 구조 블록(50) 및 UTXO 구조 블록(60)은 각각 블록 헤더(block header)와 트랜잭션(transactions)으로 구성된다. 기존의 UTXO 구조 블록(50)의 블록 헤더(block header)는 트랜잭션 아이디(txid)를 사용하는 이전(previous) 블록과 머클 트리 루트 해시(Merkle Tree root Hash)의 트랜잭션을 포함한다.
트랜잭션(transactions)의 크기를 줄이고 블록과 트랜잭션(transactions)의 위치를 즉시 추적하기 위해 본 발명의 몇몇 실시예들에 따른 블록 체인은 트랜잭션 아이디(txid)의 형식은 64비트로, 32비트의 블록 높이(height)와 16비트의 인덱스(index) 구조로 구성된다.
위의 구조는 32비트의 블록 높이(height)와 16 비트의 트랜잭션 인덱스(index, 블록 내 트랜잭션 위치)로 구성된다. 이를 사용하면 32비트의 시프트 연산(Shift operation)만으로 블록 높이를 쉽게 얻을 수 있으며, 16 비트의 시프트 연산 및 비트 마스킹(Bits Masking)를 통해 블록의 트랜잭션 위치를 얻을 수 있다.
기존의 블록체인의 구조에서는 머클 트리(Merkle Tree)를 사용하는데 이는 2개의 서로 다른 값으로부터 하나의 고유 값을 만들어 내는 방식(이하, BW)을 이용하여, 모든 값을 대표하는 값을 만들어 낸다. 머클 트리는 P2P(peer to peer) 파일 공유 방식에서 비롯되었는데, 하나의 파트와 그 인접 파트가 완성되면 BW로 완성된 값을 보장한다. 상기 BW로 완성된 값의 인접파트가 BW되면 2개의 BW된 값으로 다시 BW하여 완성된 값을 보장하는 범위를 늘릴 수 있다. 이런 방식으로 BW를 반복하면 최종적으로는 하나의 BW된 값(머클 트리 루트)로 파일의 신뢰성을 보장한다.
이 과정을 블록 체인에서 차용하여 머클 트리 루트를 통해 블록의 신뢰성 보장을 한다. 하나의 트랜잭션 파트를 검사하고 BW 하는 과정에서 P2P 파일 공유의 경우, 하나의 파트를 완성하는 시간(혹은 용량)이 BW시간(혹은 용량)보다 길어(커)서 머클 트리로 머클 트리 루트를 완성하는데 소모되는 비용이 적다.
반면, 블록 체인의 경우 트랜잭션 하나의 크기가 작기 때문에 하나의 트랜잭션 파트를 검사하는 시간(혹은 용량)이 BW 시간(혹은 용량) 보다 작아서 BW로는 비효율적이며 머클 트리의 크기는 트랜잭션 서명의 전체 목록과 같은 수준(N이 1보다 클 때 N-1)의 개수를 가지고 있으며 이를 모두 가지고 있어야만 검증이 가능하다. 머클 트리는 비효율적인 계산 구조를 가지고 있기 때문에 간단한 트랜잭션 목록으로 라이트 노드 데이터를 확인하고 교환하기 어렵다.
따라서, 본 발명의 몇몇 실시예에 따른 블록 체인에서는 머클 트리 대신에 레벨 트리(level tree)를 채용하였다. 머클 트리는 블록 체인과 같은 P2P 네트워크 시스템에서 종종 데이터 전송 시 변경 사항을 감지하는 데 사용되지만, 이를 위해서는 전체 머클 트리가 필요할 수 있다.
이 때, 기존의 UTXO 구조 블록(50)은 단일 노드(node)에서 로드되고 머클 트리는 전체 트랜잭션 아이디(txid) 목록과 거의 같은 크기를 가질 수 있다. 따라서, 기존의 UTXO 구조 블록(50)에서 머클 트리의 데이터 변경을 감지하는 것은 P2P 데이터 전송 시 사용한 부분을 확인하기 어려우므로 단순히 다른 각도에서 해시 함수(예를 들어, SHA256)로 해시를 추가적으로 수행하는 것과 다르지 않을 수 있다.
반면에, 본 발명의 몇몇 실시예들에 따른 블록 체인의 UTXO 구조 블록(60)에서는 16개의 서로 다른 값으로부터 하나의 고유 값을 만들어 내는 방식(이하, HW)으로 대표 값을 만들 수 있다. 이로 인해 하나의 파트를 완성하는 시간이 HW 시간보다 길지 않게 되어 보다 더 효율적인 구조를 가질 수 있다. 나아가, 본 발명의 몇몇 실시예들에 따른 블록 체인의 UTXO 구조 블록(60)은 라이트 노드 및 병렬 처리의 지원도 가능할 수 있다.
레벨 트리는 16개의 1레벨 해시값을 가지고, 각각의 1레벨 해시값은 16개의 2레벨 해시값을 가지며, 2레벨 해시값은 각각 16개의 3레벨 해시값을 가진다. 마지막으로 3레벨 해시값은 각각 16개의 트랜잭션을 가진다. 본 발명의 몇몇 실시예들에 따른 블록 체인의 UTXO 구조 블록(60)은 블록의 헤더에 3레벨의 오프셋(Offset)을 저장하여 트랜잭션 위치를 바로 알 수 있고, 어느 위치에서든 검증을 시작할 수 있어 병렬 처리에 유리하다. 1레벨 해시값 및 2레벨 해시값의 데이터의 크기는 예를 들어, 총 8880바이트(1레벨 해시값 크기: 512바이트, 2레벨 해시값 크기: 8192바이트)로 한 블록에 대한 검증 데이터를 보관할 수 있다. 단, 본 실시예가 이에 제한되는 것은 아니다.
또한, 본 발명의 몇몇 실시예들에 따른 블록 체인의 UTXO 구조 블록(60)은 트랜잭션 아이디(txid)에서 블록 높이 및 블록 내부의 인덱스 값을 즉시 알 수 있으므로 3레벨 해시값에 해당하는 512바이트 및 평균 3600바이트에 해당하는 16개의 트랜잭션만 가져오면 전체 레벨 트리 구조를 검증할 수 있어 라이트 노드로 사용이 가능하다.
본 실시예에 따른 블록 체인의 UTXO 구조 블록(60)은 블록 헤더(block header)와 트랜잭션 목록(transactions)으로 구성되며 레벨 트리를 사용하여 라이트 노드 및 병렬 처리를 지원한다. UTXO 구조 블록(60)은 블록 내에 블록 헤더(block header)와 트랜잭션 서명(transaction signatures), 트랜잭션(transactions) 및 블록 서명(block signatures)을 포함할 수 있다. 또한, 블록 헤더(block header)는 블록의 버전과 해시 이전 블록, 해시 레벨 루트 및 타임스탬프(Timestamp)를 포함할 수 있다.
먼저, 레벨 트리는 트랜잭션의 해시값을 16개씩 묶고 해당 묶음의 해시를 다시 사용하는 16진 트리 구조일 수 있다. 즉, 레벨 트리는 한 블록에 최대 기재 가능한 트랜잭션 수를 65535개로 잡고, 각 레벨 단계마다 16개의 자식을 가지도록 한 트리 구조일 수 있다. 따라서 레벨은 1레벨, 2레벨 및 3레벨이 존재한다.
블록 헤더(block header)에는 16개의 1레벨의 해시 레벨 루트가 기재되고, 1레벨의 해시 레벨 루트는 각각 16개의 2레벨 해시값에 대한 해시 값일 수 있다. 2레벨의 해시값은 각각 16개의 3레벨 해시값에 대한 해시 값일 수 있다. 3레벨의 해시값은 16개의 트랜잭션의 해시값을 이어 붙여서 이를 해시한 값을 사용한다.
여기서 해시를 구성할 때에는 해시 값들 사이에 지정된 패턴의 1바이트 패딩(Padding)을 삽입하여 연결한 값을 해시하는 해시 함수(Hash function)를 사용할 수 있다. 단, 본 실시예가 이에 제한되는 것은 아니다.
해시 함수는 제1 해시부터 제 16 해시까지 더한 후 각 해시마다 1바이트씩 추가할 수 있다. 이를 통해, 속도를 향상시키고 변조 가능성을 낮추도록 하였다.
블록 직렬화는 블록을 빠르게 병렬로 검증할 수 있도록 설계될 수 있다. 직렬화된 블록(70)은 블록 헤더(block header)와 블록 서명(block signatures), 트랜잭션 개수(transaction count)와 3레벨 인덱스(lv3 offsets), 트랜잭션 서명(transaction signatures) 및 트랜잭션(transactions)으로 구성될 수 있다. 또한, 블록 서명(block signatures)은 제작자 1개의 서명(Generator signature) 및 9개의 서명(6개의 Ranker signature, 3개의 Observer signature)을 포함할 수 있다. 단, 본 실시예가 이에 제한되는 것은 아니다.
여기서 블록 헤더(block header)와 트랜잭션 개수(transaction count)는 고정된 크기이며, 3레벨 인덱스(lv3 offsets) 및 트랜잭션 서명(transaction signatures)은 트랜잭션 개수(transaction count)에 비례하는 고정 크기이다. 이는 트랜잭션(transactions)의 2진법 위치를 바로 확인할 수 있다는 것을 의미하며, 3레벨 인덱스(lv3 offsets)를 이용하면 16개 단위로 뭉쳐진 트랜잭션(transactions)의 위치를 바로 알 수 있어 병렬로 빠르게 2진법 데이터를 가져가서 바로 검증할 수 있다.
블록 서명(block signatures)은 블록 헤더(block header)에 대한 해시 값을 이용한 서명으로서, 생성자의 서명(Generator signature)과 블록 생성 그룹 노드(Ranker node) 및 옵저버 노드(Observer node)의 서명(Ranker signature, Observer signature)으로 구성되어 있다.
이때, 블록 생성은 블록 생성자가 수행할 수 있다. 즉, 블록 생성은 생성자 및 블록 생성 그룹이 하고, 그에 대한 내용 승인은 옵저버 노드에서 수행할 수 있다. 여기서, 옵저버 노드의 서명이 완료되고 완전히 검증된 블록에도 트랜잭션 서명(transaction signatures)이 같이 기재되어 전송된다. 또한, 개별 노드에서도 트랜잭션과 서명을 모두 검증하므로 잘못된 트랜잭션이 형성될 수 없다.
도 5는 본 발명의 실시예에 따른 트랜잭션 내 서명의 유효성에 대해 설명하기 위한 도면이다.
도 5를 참조하면, 트랜잭션의 해시 레벨을 구성하고 레벨 트리의 해시 레벨 루트와 비교하여 트랜잭션(transactions)의 전체 일관성을 확인할 수 있다. 트랜잭션 서명(transaction signatures)을 16개로 나누고 3레벨 인덱스(lv3 offsets)를 사용하여 트랜잭션(transactions)을 16개로 나누어 트랜잭션 서명(transactions signatures), 트랜잭션(transactions) 및 레벨을 병렬로 비교하여 서명의 유효성을 확인할 수 있다.
이러한 모든 기능은 읽기 작업이므로 레벨 트리를 통해 블록의 수신과, 트랜잭션(transactions)을 16개씩 확인하는 것과, 해시를 3레벨로 구성하는 것을 동시에 수행할 수 있다. 따라서, 본 실시예들의 레벨 트리 구조는 라이트 노드의 검증에도 유리하다.
도 6은 본 발명의 실시예에 따른 트랜잭션 내 노드들을 설명하기 위한 도면이다.
도 6을 참조하면, 라이트 노드(Light Node)는 1레벨 당 512바이트와 2레벨 당 8192바이트를 가지므로, 라이트 노드(Light Node)는 블록 헤더를 포함하여 블록 당 8880바이트의 유효데이터를 포함할 수 있다. 특정 트랜잭션에 대한 데이터가 필요한 경우, 트랜잭션 아이디에 높이가 표시되므로 상기 트랜잭션 아이디를 통해서 특정 트랜잭션이 포함되는 블록을 즉시 알 수 있다. 또한, 특정 트랜잭션의 블록 내 위치가 인덱스에 표시되므로 특정 트랜잭션을 포함하는 레벨 트리 노드를 즉시 알 수 있다. 3레벨 내 트리에서 각각 512바이트와 3600바이트에 해당하는 16개의 트랜잭션을 가져오면, 트리 구조를 통해 트랜잭션 내용을 알 수 있다. 따라서, 라이트 노드(Light node)는 적은 데이터 수신으로 높은 수준의 트랜잭션을 확인할 수 있다.
현재 본 발명에는 데이터를 저장하기 위한 데이터 분할 및 이를 처리하기 위한 트랜잭션 분할의 2가지 공유형식이 있다. 아래 설명된 멀티 노드 병렬 트랜잭션 처리는 여러 노드를 샤드(Shard)로 이용함으로써 트랜잭션을 병렬로 처리하는 것을 말한다.
도 7은 본 발명의 다른 실시예에 따른 멀티 노드 병렬 트랜잭션 처리를 설명하기 위한 도면이다.
도 7을 참조하면, 본 발명의 각 샤드(shard #1~shard #4)는 독립적인 블록체인으로 취급되므로 온전히 병렬 방식으로 작동된다. 그러나, 사용자의 공용 키(public key) 및 개인 키(private key)는 샤드에 관계없이 동일한 값을 사용하여 마치 하나로 처리된 것처럼 보이고 사용될 수 있다. 이 방법을 사용하여 이중 지불이 불가능한 완전 병렬 멀티 노드 병렬 트랜잭션 처리 방법이 실행될 수 있다. 도 7에는 예시적으로 4개의 샤드가 도시되었으나, 본 실시예가 이에 제한되는 것은 아니다.
사용자 지갑의 수수료는 트랜잭션을 수행하는데 사용되는 입력 및 출력 수에 비례하여 적절하게 측정된다. 트랜잭션은 여러 개의 샤드에 트랜잭션을 전송하기 위해 각 샤드의 입력을 수집하여 트랜잭션에 이용하고 원하는 출력을 트랜잭션에 분배할 수 있다.
기본적으로 지갑은 최소한의 트랜잭션을 생성하여 가장 적은 수의 샤드를 거치도록 설계되었다. 이를 통해, 본 실시예들에 따른 블록 체인은 필요에 따라 가장 작은 크기의 샤드 중 하나를 사용할 수 있고, 많은 양이 필요한 상황에는 큰 크기의 샤드를 사용할 수 있다. 이것이 가능하지 않을 경우, 본 실시예에 따른 블록 체인은 가능한 가장 큰 크기의 샤드를 사용하고, 나머지 양에 대해 위의 절차를 반복하여 가능한 최소한의 샤드를 사용할 수 있다. 이에 따라, 트랜잭션은 최소한의 제약을 가지고 이루어지며, 사용자는 사용한 샤드 수와 관계없이 동일한 수수료를 지불한다.
고급 트랜잭션은 사용을 확장하기 위해 추가된 유형의 트랜잭션이다. 이는 코인 트랜잭션에만 사용되었던 이전 모델보다 확장성이 뛰어나고 스마트 계약보다 처리하기가 쉽다. 고급 트랜잭션은 유형 및 구조가 추가된 코인 트랜잭션으로써 간단하게 설명될 수 있고, 기존 모델과 마찬가지로 쉽게 트랜잭션이 가능하다.
도 8은 본 발명의 또 다른 실시예에 따른 자산 트랜잭션을 설명하기 위한 도면이다.
도 8을 참조하면, 자산 트랜잭션은 특정 데이터에 대한 상품 또는 권한을 교환하는데 사용된다. 데이터 필드를 추가함으로써, 우선 트랜잭션 소유자는 상기 필드의 데이터에 대한 권리를 주장할 수 있고, 트랜잭션을 다시 제출함으로써 그 소유자는 트랜잭션 내의 데이터에 대한 권리를 행사할 수 있다.
예를 들어, 제1 사용자가 쿠폰 코드를 생성하고(1), 제1 사용자가 제2 사용자에게 쿠폰 코드가 포함된 자산을 발행하고(2), 제2 사용자는 제3 사용자에게 쿠폰을 제공하기 위해 데이터 필드에 쿠폰을 자산 트랜잭션으로 제시할 수 있다(3). 그 후, 트랜잭션 중에 제3 사용자는 그 트랜잭션에 서비스 ID를 쓸 수 있고(4), 그 서비스 ID에 쿠폰이 적용될 수 있다(5). 이 트랜잭션은 입력 인덱스(Vin)와 출력 인덱스(Vout)가 각각 1개씩만 있으며, 코인 트랜잭션과 마찬가지로 다중 서명(Multiple Signature) 기능을 허용할 수 있다.
자산 트랜잭션에서는 코드를 개발하지 않고도 쿠폰 발행 및 트랜잭션 처리가 가능하며, 트랜잭션 속도는 본 발명의 블록체인에서 제공하는 고속 트랜잭션 속도를 이용할 수 있다. 메인 체인(Main chain) 외에도 독립적인 속도와 경제성이 필요한 경우, 토큰을 발행하여 토큰 체인 내에서도 사용할 수 있다.
또한, 자산 트랜잭션을 이용하면 더 이상의 코드 개발 없이 쿠폰 발행과 처리가 용이하며, 자산 트랜잭션 속도도 본 발명의 블록 체인의 고속 트랜잭션 속도를 이용할 수 있다. 이것은 메인 체인뿐만 아니라 토큰 체인에서도 똑같이 사용할 수 있다.
이하에서는 발행 트랜잭션에 대해 설명한다. 발행 트랜잭션 명령은 토큰을 작성하고 발행계약서를 발행할 때 사용된다. 발행 트랜잭션은 지정된 토큰을 발행하는 발행 트랜잭션을 배포하고, 이 트랜잭션의 해시 값을 해당 토큰 체인의 첫 해시로 사용할 수 있다. 토큰 체인에서는 채굴 알고리즘과 보상 메커니즘을 정의하는 토큰 계약을 발행 트랜잭션에서 함께 배포해야 한다.
도 9는 본 발명의 또 다른 실시예에 따른 발행 트랜잭션을 설명하기 위한 도면이다.
도 9를 참조하면, 발행 트랜잭션은 토큰과 본 실시예들의 코인을 교환할 수 있는 메커니즘을 제공할 수 있다. 또한, 그 반대의 경우 토큰으로 교환된 본 실시예들의 블록 체인의 코인은 토큰 관리자의 주소로 이동하여 토큰 생성을 위한 발행 트랜잭션이 발행될 수 있다. 토큰 체인(token chain)은 발행 트랜잭션을 확인하고 관련 금액이 입금된 주소에 제공할 지정된 토큰을 생성할 수 있다.
토큰 트랜잭션(token transaction)은 토큰 체인(token chain)에서 발행된 토큰을 처리하는 트랜잭션으로 사용된다. 이는 토큰 정보가 토큰 체인 블록에 기록된다는 점을 제외하면 일반 코인 트랜잭션과 완전히 동일할 수 있다.
도 10은 본 발명의 실시예에 따른 토큰 체인 및 토큰 계약을 설명하기 위한 도면이다.
도 10을 참조하면, 토큰 체인(token chain)의 경우, 채굴 보상 및 체인에 대한 기타 정보를 상세히 기술하는 토큰 계약이 있으며, 토큰 관리자는 토큰 계약을 수정하여 보상 메커니즘을 업데이트할 수 있다. 이러한 관리방식은 나중에 관리자를 지정하는 투표를 도입할 것이며, 정해진 기간 동안 유권자 대다수가 동의할 경우, 토큰 계약은 더 이상 지갑 업데이트(Wallet update) 없이 새로운 보상 과정이 적용될 수 있도록 업데이트 될 수 있다.
분산형 응용 프로그램 트랜잭션 명령은 토큰 관리자가 분산형 응용 프로그램에 대한 새 데이터 체인을 작성할 때 사용된다. 본 발명의 분산형 응용 프로그램 토큰(DApp Token)은 독점 토큰 체인과 독립적인 보상 메커니즘으로 각 기능을 토큰화 할 수 있다. 서브 체인(Sub Chain)을 만들기 위하여 분산형 응용 프로그램 트랜잭션 명령이 사용될 수 있다.
도 11은 본 발명의 실시예에 따른 분산형 응용 프로그램 트랜잭션과 토큰 체인의 관계에 대해 설명하기 위한 도면이다.
도 11을 참조하면, 분산형 응용 프로그램 트랜잭션(DApp transaction)을 수행한 후, 토큰 관리자는 해당 트랜잭션 아이디를 사용하여 계약 트랜잭션을 작성할 수 있으며 계약 트랜잭션은 해당 서브 체인에서 스마트 계약을 분배하고 업데이트할 수 있다. 그런 다음 트랜잭션 명령을 사용하여 스마트 계약을 호출할 수 있다.
채굴자(formulator; 이하, 채굴자)를 생성하려면, 트랜잭션을 형성하기 위해 지정된 수의 코인을 묶어야 한다. 본 발명의 블록체인에서 채굴자는 블록에 서명해야 하기 때문에, 공식 채굴자의 공용 키(public key) 및 개인 키(private key)를 미리 정의하고 배포해야 한다. 따라서, UTXO를 사용하여 채굴자 트랜잭션을 생성하며, 이때, 블록 서명 유효성을 정확히 검증하기 위해 새로 생성된 공용 키 및 개인 키 중 공용 키만 채굴자 트랜잭션에 기록된다. 이후에 채굴자 트랜잭션을 해제하는 트랜잭션을 생성하면, 이전 미사용 트랜잭션 출력값(UTXO)에 저장된 수수료의 총액에 해당하는 금액을 돌려받을 수 있다.
본 명세서에서 컨센서스(Consensus)는 블록 생성에 대한 합의를 뜻한다. 일반적으로 컨센서스는 난이도를 기반으로 합의하여 네트워크 전체에 블록을 전파시켜 임의의 사용자도 채굴이 가능하도록 지원하였다,
본 발명은 PoF(Proof-of-Formulator, 이하 PoF)를 개발하여 채굴자 보상 순서를 이용하여 채굴을 할 대상을 정한 후 전파 범위를 좁혀서 빠르게 블록을 생성하고 전파할 수 있다. 블록체인에는 옵저버 노드를 두어 즉시 승인처리를 하고 포크(Fork)를 예방할 수 있다.
본 발명에서 블록 생성은 공공 IP(Internet Protocol)로 24시간 상시 실행함으로써 보상을 받는 채굴자들에 의해 수행될 수 있다. 채굴자가 생성한 블록에 대한 보상은 해당 채굴자가 생성한 채굴자 트랜잭션의 UTXO 주소로 이동될 수 있다. UTXO에 다중 서명(Multiple Signature)이 생성될 경우, 보상이 다중 서명(Multiple Signature)을 통해서만 사용될 수 있도록 모든 주소에 전송될 수 있다.
본 발명은 이러한 목록을 사용하여 채굴 순서에 대한 합의를 생성하므로 채굴자 목록에 대한 계약이 매우 중요하다. 이것은 체인이 아니라 네트워크에서 실시간으로 합의될 수 있다.
도 12는 본 발명의 실시예에 따른 점수 계산 및 순위 목록을 설명하기 위한 도면이다.
도 12를 참조하면, 합의 알고리즘은 임의의 값, 보상 시간 및 네트워크 시간을 사용하여 다음과 같이 점수를 계산할 수 있다.
블록 보상 점수(score)=블록 해시 차이(block_hash_diff) + 대기 시간 차이(wait_time_diff)
여기서, 블록 해시 차이(block_hash_diff)는 '절대값([채굴자 트랜잭션 생성 블록, 마지막 보상 블록]의 마지막 블록의 해시 - 해당 블록 이전 100개 블록의 해시)'로 계산되고, 대기 시간 차이(wait_time_diff)는 '(현재 시간-[채굴자 트랜잭션 생성 블록 시간, 발견 시간, 마지막 보상 블록 시간]의 마지막 값)'으로 계산할 수 있다.
따라서, 블록 생성을 통해 보상받을 가능성을 증가시킴으로써 블록 보상 점수(score)를 증가시킬 수 있다. 여기서, 해당 채굴자(formulator)가 블록을 생성할 때까지 해당 채굴자(formulator)의 채굴 트랜잭션 생성 블록 및 마지막 보상 블록은 고정된다.
따라서, 블록 보상 점수(score)는 블록 높이가 증가하지 않으면 변경될 수 없다. 현재의 시간은 모두에게 공평하게 증가하기 때문에 차이가 없다. 이전의 경우와 같이 블록 높이가 증가하지 않으면 블록 높이가 변경되지 않으므로 채굴자 트랜잭션 생성 블록 시간 및 마지막 보상블록 시간은 합의될 수 있다. 문제는 발견시간이 하나뿐이기 때문에, 공식 목록 동기화를 사용하여 모든 채굴자(formulator)들이 가능한 동일한 값을 가질 수 있도록 한다.
즉, 공식 목록 동기화는 순서를 섞기 위해 해시를 사용하고, 동시에 블록 생성 보상 가능성을 높이기 위해 마지막 보상 블록 시간이 더 나중에 일어난 경우 채굴자(formulator)들의 점수를 증가시킨다.
마지막으로 보상된 블록 시간이 더 오래 걸리면 채굴자(formulator)의 점수를 증가시킨다. 여기서 특정 채굴자(formulator)들의 채굴자 트랜잭션 생성 블록은 고정되고, 특정 채굴자(formulator)들이 블록을 생성하기 전까지 마지막 보상 블록 또한 고정된다. 블록 높이가 증가하지 않고 변경되지 않으므로 합의가 이루어질 수 있다.
이 때, 시간은 모든 사람들에게 차별없이 공평하게 증가된다. 그리고 위와 같이 블록 높이가 증가하지 않으면, 채굴자 트랜잭션 생성 블록 시간 및 마지막 보상 블록 시간은 변경되지 않는다.
이에 따라서, 채굴자(formulator)들은 블록 보상 점수(score)에 따라서 순위가 지정된 경우, 마지막 순위의 채굴자(formulator)까지 모두 블록을 생성하기 전까지는 새로운 채굴자(formulator)가 유입되지 않는다. 만일, 마지막 순위의 채굴자(formulator)까지 모두 블록을 생성한 경우에는 새로운 페이즈(phase)에서 현재의 채굴자(formulator)의 블록 보상 점수(score)를 다시 산정하여 채굴자(formulator) 순위를 부여할 수 있다.
도 13은 본 발명의 몇몇 실시예들에 따른 채굴자 목록 동기화를 설명하기 위한 도면이다.
도 13을 참조하면, 채굴자(formulator)는 네트워크 수준에서 일반 트랜잭션 외에도 특정 수의 채굴자 트랜잭션자를 유지하도록 설계되었다. 채굴자 목록을 동기화하기 위해, 각 채굴자(formulator)는 채굴자 개인 목록에 채굴자 목록을 요청한다. 새로운 채굴자(formulator)가 발견되면, 새로운 채굴자(formulator)는 목록에 추가되고 모든 채굴자 트랜잭션자들에게 전송된다. 이 발견 시간이 현재 시간으로부터 설정된 시간에 걸친 시간 간격을 넘는 경우, 발견 시간은 현재 시간으로 업데이트되며, 이후 저장 및 배포에도 이 시간이 사용된다. 이 과정은 점수를 높이기 위해 발견 시간을 변조하는 것을 방지하여 검색 시간이 안전하게 공유된다. 또한, 검색 시간 간격을 줄이기 위해 새로운 채굴자(formulator)가 네트워크에 배포되는 시간이 매우 중요하다.
발견된 채굴자 트랜잭션이자 목록은 모두에게 알려진 네트워크에 빠르게 배포되어 신속하게 처리됨으로써 해결책이 될 수 있다. 따라서, 채굴자 발견 시간은 작은 오차 한계 내에서 서로의 노드와 공유되며, 이러한 방식으로 인한 발견 시간의 영향은 점수 계산에 큰 영향을 끼치지 않는다. 그리고 채굴자가 블록을 생성하여 최소 한 번 이상의 보상을 받는 경우, 그 후에 고정 값이 사용되어 연결이 끊어지지 않는 한 점수에서 추론된 순서가 더 확실해진다.
채굴자 순위는 예를 들어, 1순위에서 20순위의 범위를 갖는다. 가장 높은 순위의(1순위의) 채굴자가 블록 생성을 끝내고 순위를 벗어나면, 이전 2순위가 최고 순위가 되어 블록을 생성한다. 동시에 2~19번째 노드는 순위에 참여할 다음 채굴자를 선정하기 위해 투표에 참여한다. 그러면 투표 수가 가장 많은 채굴자가 채굴 그룹 및 순위에 참여하게 되며, 참여할 때 옵저버 노드로부터 하나 이상의 투표를 받아 상위 순위를 차지하려는 순서 변경 공격을 방지할 수 있다.
블록의 생성은 채굴자(formulator) 간의 합의된 블록 생성 순서에 따라 진행되게 되며, 이 때 생성한 블록의 보상은 블록을 생성한 채굴자(formulator)가 받는다. 블록 생성 순서는 전술한 채굴자 동기화를 사용하여 동기화된다.
균형 잡힌 네트워크 내에서 알고리즘은 관리되고 직접적으로 또는 여러 트랜잭션자들을 통해 연결에 접근하여, 네트워크 전체에서 그에 상응하는 블록 생성 순서에 대한 합의를 도출한다. 또한, 블록 생성은 서명이 들어감으로써 1순위만 가능하므로, 포크(fork) 생성이 가능한 노드는 최상위 노드만 가능하여 이를 방지하면 포크가 발생할 수 없다. 즉, 옵저버 노드가 실시간으로 확인되면 포크는 발생하지 않는다.
도 14는 본 발명의 실시예에 따른 옵저버 노드와 채굴자 그룹의 관계에 대해 설명하기 위한 도면이다.
도 14를 참조하면, 채굴 그룹은 채굴자(formulator) 중 1순위의 블록 생성자(Generator), 2순위부터 10순위까지의 동기화 그룹(Sync Group) 및 11순위부터 20순위까지의 대기 그룹(Wait Group)을 포함한다. 동기화 그룹(Sync Group)은 보상 순서에 동의하고 옵저버 노드(observers)는 컨텐츠 검증을 수행한다. 도 14의 동기화 그룹(Sync Group) 및 대기 그룹(Wait Group)의 채굴자의 개수는 예시에 불과하고, 본 실시예가 이에 제한되는 것은 아니다.
즉, 블록 생성자(Generator)는 블록을 생성하고, 생성된 블록을 동기화 그룹(Sync Group) 및 옵저버 노드(observers)로 전송하고, 동기화 그룹(Sync Group)은 블록 생성자(Generator)의 순서와 헤더를 확인한 후 서명을 진행하여 옵저버 노드(observers)로 전송한다. 옵저버 노드(observers)는 동기화 그룹(Sync Group)으로부터 6개의 서명을 수신한 후에, 블록의 모든 트랜잭션 서명을 검토하고 옵저버 노드(observers) 간에 서명을 교환한다. 5개의 옵저버 노드(observers)에서 3개의 서명을 수집하면 블록이 완료되고, 옵저버 노드는 완성된 서명 부분을 동기화 그룹으로 전송한다. 이 때, 상술한 옵저버 노드(observers)의 개수 및 각각의 서명의 개수는 예시에 불과하여 본 실시예가 이에 제한되는 것은 아니다.
동기화 그룹(Sync Group)은 이전에 수신한 블록에 서명을 부착하여 완료된 블록을 생성하여 대기 그룹에 전송한 다음 블록을 네트워크에 배포한다. 이러한 방식의 블록 생성자(Generator)는 블록을 신속하게 생성할 수 있으며, 옵저버 노드(observers)의 과반수가 서명하므로, 적어도 하나 이상의 옵저버 노드(observers)가 포크(fork)를 감지하기 때문에 포크가 발생할 수 없다. 그리고 동기화 그룹(Sync Group)이 검증 목적으로 순서에 서명하기 때문에, 편향된 옵저버 노드(observers)의 서명이 방지된다. 그리고, 동기화 그룹(Sync Group) 및 대기 그룹(Wait Group)의 역할 분담은 전송 트래픽을 분할하고 더 넓고 빠르게 네트워크에 블록이 퍼질 수 있도록 지원할 수 있다.
1순위 채굴자(formulator)의 채굴을 촉진하기 위해, 2순위 채굴자(formulator)가 미리 준비될 수 있도록 2순위 채굴자(formulator)와 옵저버 노드(observers) 모두에 생성된 블록을 전송할 수 있다. 물론, 1순위 채굴자(formulator)에 의해 전송된 블록에 문제가 있거나 서명에 실패하면, 수신자 노드는 상기 블록을 폐기하고 새로운 블록을 준비하여 전달한다.
본 실시예에 따른 블록 체인은 생성된 블록에 문제가 없는 경우라면 빠르게 서명을 수행할 수 있다. 1순위 채굴자(formulator)가 제1 기준 시간(예, 1초) 이상 정상적인 블록을 생성하지 못하면, 2순위 채굴자(formulator)는 경우에 따라 자체적으로 새 블록을 생성할 수도 있다. 단, 본 실시예가 이에 제한되는 것은 아니다.
또한, 이후에도 1순위 채굴자(formulator)가 제2 기준 시간(예, 3초) 이상 일반 노드를 생성하지 못하면 2순위 채굴자(formulator)는 즉시 작성된 블록을 전송하고 블록 생성을 계속 진행할 수 있다. 옵저버 노드(observers)는 1순위 채굴자(formulator)가 제2 기준 시간 이상 만들지 못함을 확인하고 서명 프로세스를 진행할 수 있다. 이 때, 제2 기준 시간은 상기 제1 기준 시간보다 긴 시간일 수 있다. 단, 본 실시예가 이에 제한되는 것은 아니다.
1순위 채굴자(formulator)가 블록을 생성하고 옵저버 노드의 서명을 받으면, 옵저버 노드는 해당 블록을 서명하고 저장한다. 동기화 그룹에 의해 서명이 완료되면, 블록을 수신하고 블록체인이 진행되어 포크(fork) 블록이 발생하여도 옵저버 노드(observers)를 통과하지 못하여 계획적으로 포크 발생을 차단할 수 있다.
즉, 채굴자 순서가 정확하게 구성되면 1순위 채굴자(formulator)에게만 블록을 생성하고 서명할 수 있는 권리가 주어지며, 블록 체인을 포크하기 위해 2개 이상의 블록을 만드는 것은 옵저버 노드(observers)에 의해 중지된다. 따라서, 채굴자 순위 순서가 동기화되면, 블록 생성자(Generator)와 옵저버 노드(observers) 서명을 검증하는 것만으로도 포크가 되지 않은 블록을 수신할 수 있다. 이는 만들어진 블록이 확정성을 가지며 이에 따라 옵저버 노드(observers)를 거쳐서 승인된 모든 블록 트랜잭션은 즉시 승인이 된다.
도 15는 본 발명의 실시예에 따른 옵저버 노드에 의한 포크 예방을 설명하기 위한 도면이다.
도 15를 참조하면, 공격자는 옵저버 노드(observers)에 의하여 이중지불을 유도하는 포크 블록(Fork Block)을 생성할 수 없게 된다. 그리고 블록 생성의 주체는 채굴자이므로 블록 체인 유지는 채굴자를 생성한 개인이 담당하고, 옵저버 노드(observers)는 보상을 받지 않으므로 보상은 채굴자를 소유한 개인에게 제공된다.
여기서 유일하게 제어 가능한 부분은 채굴자 보상 순서 작업이지만, 모든 보상 순서는 점수에 의해 관리되고 보상받은 노드는 강제로 뒤로 밀기 때문에, 순서를 위조하는 유일한 방법은 채굴자 목록을 위조하는 것이다. 채굴자 목록은 채굴자가 네트워크에 올바르게 연결되어 있는지 여부를 평가하는데 사용되며, 위에서 동기화되어 작성된 목록을 직접 평가하므로 특정 노드를 제외하는 것은 매우 어렵다. 채굴자 블록 연결은 실제로 배포 과정에 참여하는 옵저버 노드(observers)에 의해 평가되므로 실제로 연결을 손상시키는 공격은 작동하지 않는다.
가능한 나머지 공격은 의도적으로 서명을 거부하여 1순위에서 생성된 일반 블록이 필요한 서명을 받지 못하게 하는 것이다. 옵저버 노드(observers)는 서명을 수집하기 때문에 동기화 그룹으로부터 서명의 결과 또는 거부 이유를 수신한다. 유효하지 않은 거부 사유가 도착하거나 1초 이상 응답이 없으면 옵저버 노드는 5개 중 3개의 서명을 수신하고 이 정보를 동기화 그룹(Sync Group)에 분배하고 블록 생성 그룹은 해당 특정 노드를 제외한다. 동기화 그룹(Sync Group)은 옵저버 노드(observers)뿐만 아니라 전체 동기화 그룹(Sync Group)에도 블록 서명 요청을 보내므로 옵저버 노드(observers)의 응답이 유효한지 확인할 수 있다. 특정 노드가 동시에 제외 요청과 서명을 받는 경우, 노드는 서명 단계를 완료하기 위해 서명 정보를 옵저버 노드(observers)로 전송한다.
토큰은 토큰 체인에서 트랜잭션되며 블록 생성 및 토큰 발행은 해당 토큰의 토큰 계약에 설명된 방법에 따라 수행된다. 토큰 체인은 새로운 블록을 만들 때 메인 체인의 블록 번호 및 해시 값을 열거하여 메인 체인에 있어서의 발행 트랜잭션 처리를 보증한다. 토큰 체인은 그 아래에 분산형 응용 프로그램 트랜잭션을 생성하여 토큰에 대해 분산형 응용 프로그램을 실행할 서브 체인을 생성할 수 있다. 생성된 서브 체인은 PoF를 채굴 알고리즘으로써 따르고, 작업 증명서, 상태증명서, 상향식 기반 소셜 플랫폼 또는 토큰 생성자가 원하는 과정의 보상 메커니즘으로써 지원할 수 있다.
발행 계약은 분산형 응용 프로그램의 기초가 되는 토큰을 생성하며 토큰과 본 발명 코인을 교환할 책임이 있다. 발행 계약에는 본 발명 코인이 토큰으로 변환되는 속도, 최대값 및 토큰 관리자가 받은 토큰 등 필요한 모든 값이 포함되어 있다. 따라서, 발행 계약은 최초 배포 후 수정할 수 없으므로, 배포하기 전에 신중하게 검토해야 한다. 사용자는 발행 계약 내에 본 발명 코인을 예치하면 토큰을 받을 수 있다. 여기서 발행 계약을 생성하는 트랜잭션과 토큰을 받는 트랜잭션을 발행 트랜잭션이라고 한다. 발행 계약은 메인 체인에 의해 운영되고 관리되며, 블록은 메인 체인을 기준으로 토큰 체인에 의해 생성되므로 토큰 생성 동기화가 가능하다.
토큰 계약에는 토큰 체인이 블록을 생성하는 방법, 특정 블록 높이에서의 보상 메커니즘, 블록 생성 과정 및 블록 생성을 위한 토큰 보상에 대한 정보를 포함한다. 토큰 계약을 사용할 때의 장점은 토큰 경제 구조화 시, 채굴 알고리즘과 보상 메커니즘을 지갑을 무리하게 사용하지 않고도 업데이트할 수 있다는 것이다. 물론 토큰 계약의 업데이트는 관리를 통한 의결에 의해 결정되므로 토큰 관리자는 업데이트 일정을 발행할 수 있지만 최종적으로는 토큰 소유자가 결정한다. 최고조 관리방식은 의결기간에 따라 정해지기 때문에, 토큰 계약 내에서 변동 계산은 마지막 최고조 관리방식을 통해 지원된다.
데이터 체인은 분산형 응용 프로그램 트랜잭션을 통해 생성된 서브 체인을 나타낸다. 데이터 체인은 분산형 응용 프로그램에 속하는 스마트 계약 데이터를 관리 및 보관하며, 토큰은 토큰 체인과 관련하여 해당 분산형 응용 프로그램의 계정에서 입금 및 출금을 할 수 있다. 이 연결에 대한 데이터 체인에 블록을 생성할 때 처리된 토큰 체인의 블록 번호와 해시 값이 나열된다.
특정 분산형 응용 프로그램을 사용하려면, 분산형 응용 프로그램에 트랜잭션 호출을 보내 기능을 작동시킨다. 콜 커미션(Call Commission) 기능은 체인 생성 단계에서 무료로 설정되며, 이후 단계에서 관리자는 이를 확보하거나 보유한 토큰에 비례하여 여러 기능을 호출할 수 있다. 분산형 응용 프로그램의 데이터 체인은 모두 다르기 때문에, 각각 독립적으로 작동하여 용량, 커미션(Commission), 분산형 응용 프로그램 우선 실행 및 업데이트 문제를 해결한다.
데이터 체인 유형은 이벤트 소싱을 기반으로 한다. 분산형 응용 프로그램의 데이터 체인에서 작동하는 스마트 계약은 토큰 및 코인과 독립적으로 작동하므로 분산형 응용 프로그램 서비스를 최적화하도록 구성할 수 있다. 각 스마트 계약은 검토할 이벤트를 결정할 수 있으며 이벤트가 스마트 계약 증명을 통과하면 블록체인에 실행되고 기록된다. 블록체인에 기록된 이벤트는 각 노드로 전파되며 분산형 응용 프로그램 서비스를 제공하는 서버 전단은 관련 이벤트 스트림(Event Stream)에 가입하고 서비스 및 데이터를 제공하기 위해 적절한 저장소 형식을 제공한다. 만약에 특정 작업으로 인해 이벤트가 발생하면 스마트 계약으로 전송된 후 이를 검토하고 실행한다. 이는 단일 포인트 쓰기 검증과 동일하고 분산 환경에서 실행되므로, 충돌없이 일관성을 유지할 수 있어 결과적으로 일관성을 유지할 수 있다. 새 이벤트를 처리할 때는 새 스마트 계약을 배포하기만 하면 되며, 기존 이벤트 처리기 업데이트는 이동을 통해 업데이트 할 수 있다. 스마트 계약은 공통 인터페이스를 통해 확인되는 한 언어에 관계없이 인터페이스를 지원할 수 있으므로 현재 다양한 언어에 대한 지원이 가능하다.
이때, 토큰 체인과 데이터 체인은 별도의 체인이며, 토큰 이동 및 생성된 데이터 체인의 분산형 응용 프로그램 주소는 토큰 체인에 저장된다. 실제 데이터 이동 및 스마트 계약 실행 평가는 데이터 체인에서 수행된다. 데이터 체인은 토큰 체인을 참조하므로 토큰 체인의 분산형 응용 프로그램 주소에 대한 입금 내역은 데이터 체인에서 처리될 수 있다. 문제는 특정 작업을 통해 인출이 확인되면 이 인출은 토큰 체인의 분산형 응용 프로그램 주소에서 가져와야 한다.
데이터 체인을 생성하는 분산형 응용 프로그램 트랜잭션에서 데이터 체인의 모든 옵저버 주소(Observer address)를 나열해야 한다. 그런 다음 데이터 체인의 옵저버 노드(Observers)의 5개 중 3개에서 승인한 인출 트랜잭션의 경우, 해당 데이터 체인의 분산형 응용 프로그램 주소에서 인출이 허용된다. 이를 통해 스마트 계약에 의해 구동되는 데이터 체인을 여러 조각으로 분할하는 동시에 토큰 인출을 허용할 수 있다. 또한, 인출 트랜잭션에서 인출을 호출한 데이터 체인의 트랜잭션 아이디를 기록하여 필요할 때마다 확인할 수 있다.
이상의 설명은 본 실시예의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 실시예들은 본 실시예의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 실시예의 기술 사상의 범위가 한정되는 것은 아니다. 본 실시예의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 실시예의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
10: 기존의 UTXO 구조 트랜잭션
20: UTXO 구조 트랜잭션
30: 단일 서명 트랜잭션
40: 다중 서명 트랜잭션

Claims (10)

  1. 블록을 생성하는 m개의 채굴자(formulator)를 포함하는 채굴 그룹; 및
    상기 블록의 검증을 수행하는 옵저버 노드를 포함하되,
    상기 채굴 그룹은 채굴자 순위에 따라 구별되는 블록 생성자, 동기화 그룹 및 대기 그룹을 포함하고,
    상기 블록 생성자는 상기 m개의 채굴자 중 1순위의 채굴자를 포함하여 상기 블록을 생성하고,
    상기 동기화 그룹은 상기 m개의 채굴자 중 2순위 내지 n순위의 채굴자를 포함하고,
    상기 대기 그룹은 상기 m개의 채굴자 중 n+1순위 내지 m순위의 채굴자를 포함하고,
    상기 1순위의 채굴자가 블록을 생성하면 2순위 내지 m순위의 채굴자의 상기 채굴자 순위가 각각 1순위 내지 m-1순위로 변경되는 블록 체인 시스템.
  2. 제1 항에 있어서,
    상기 블록은 복수의 트랜잭션을 포함하고,
    상기 복수의 트랜잭션은 각각 트랜잭션 서명을 포함하고,
    상기 블록 생성자는 상기 블록을 생성하여 상기 옵저버 노드로 전송하고,
    상기 옵저버 노드는 상기 트랜잭션 서명을 검토하고, 옵저버 서명을 수행하는 블록 체인 시스템.
  3. 제2 항에 있어서,
    상기 옵저버 노드는 제1 내지 제k 옵저버 노드를 포함하고,
    상기 옵저버 서명을 수행하는 것은 상기 제1 내지 제k 옵저버 노드 중 과반수 이상의 서명을 수행하는 것을 포함하는 블록 체인 시스템.
  4. 제3 항에 있어서,
    상기 k는 5인 블록 체인 시스템.
  5. 제1 항에 있어서,
    상기 블록은 블록 헤더를 포함하고,
    상기 동기화 그룹은 상기 블록 생성자로부터 상기 블록을 수신하여 상기 블록 헤더와 상기 채굴자 순위를 확인하고,
    상기 블록에 동기화 그룹 서명을 수행하여 상기 옵저버 노드 및 상기 대기 그룹으로 전송하는 블록 체인 시스템.
  6. 제1 항에 있어서,
    상기 채굴자 순위는 상기 m개의 채굴자가 모두 블록을 생성한 경우에는 재설정되는 블록 체인 시스템.
  7. 제1 항에 있어서,
    상기 채굴자 순위는 블록 보상 점수가 높은 순서로 지정되고,
    상기 블록 보상 점수는 블록의 해시 값에 따라 생성되는 블록 체인 시스템.
  8. 제7 항에 있어서,
    상기 블록 보상 점수는 블록 해시 차이와 대기 시간 차이의 합이고,
    상기 블록 해시 차이는 채굴자 트랜잭션 생성 블록과 마지막 보상 블록 중 더 마지막 블록의 해시값과, 해당 블록 이전 블록의 해시 사이의 차이값이고,
    상기 대기 시간 차이는 현재 시간과, 채굴자 트랜잭션 생성 블록 시간, 발견 시간 및 마지막 보상 블록 시간 중 마지막 값 사이의 차이값인 블록 체인 시스템.
  9. 제8 항에 있어서,
    상기 해당 블록 이전의 블록의 해시는 해당 블록 이전의 100개의 블록의 해시인 블록 체인 시스템.
  10. 제1 항에 있어서,
    상기 n은 10인 블록 체인 시스템.
KR1020190146359A 2019-09-30 2019-11-15 블록 체인 시스템 KR102386922B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020190120672 2019-09-30
KR20190120672 2019-09-30

Publications (2)

Publication Number Publication Date
KR20210038272A true KR20210038272A (ko) 2021-04-07
KR102386922B1 KR102386922B1 (ko) 2022-04-20

Family

ID=75469471

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020190146359A KR102386922B1 (ko) 2019-09-30 2019-11-15 블록 체인 시스템
KR1020190146358A KR102386921B1 (ko) 2019-09-30 2019-11-15 블록 데이터를 기록한 컴퓨터로 읽을 수 있는 기록 매체

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020190146358A KR102386921B1 (ko) 2019-09-30 2019-11-15 블록 데이터를 기록한 컴퓨터로 읽을 수 있는 기록 매체

Country Status (1)

Country Link
KR (2) KR102386922B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023177358A1 (en) * 2022-03-18 2023-09-21 National University Of Singapore Distributed verifiable ledger database

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180128874A (ko) * 2018-11-14 2018-12-04 주식회사 미탭스플러스 트랜잭션 검증을 이용한 암호화폐 거래소 입금 승인 장치 및 방법
KR20190071778A (ko) * 2016-10-28 2019-06-24 엔체인 홀딩스 리미티드 블록체인을 통한 결정론적 유한 오토마타(DFAs) 구현을 위한 시스템 및 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101660627B1 (ko) * 2015-02-03 2016-09-28 한양대학교 에리카산학협력단 암호화 화폐의 거래를 보호하는 방법 및 장치

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190071778A (ko) * 2016-10-28 2019-06-24 엔체인 홀딩스 리미티드 블록체인을 통한 결정론적 유한 오토마타(DFAs) 구현을 위한 시스템 및 방법
KR20180128874A (ko) * 2018-11-14 2018-12-04 주식회사 미탭스플러스 트랜잭션 검증을 이용한 암호화폐 거래소 입금 승인 장치 및 방법

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
Breaking Down FLETA’s Proof-of-Formulation, https://medium.com/fleta-first-chain/breaking-down-fletas-proof-of-formulation-2860c6cb7178 (2019.01.16.) *
Ethereum Sharding: Overview and Finality, https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649 (2017.12.27.) *
FLETA - Blockchain Ecosystem for DApps, https://levelup.gitconnected.com/fleta-blockchain-ecosystem-for-dapps-bd698fb4235b (2019.09.02.) *
fleta level tree, https://medium.com/fleta-first-chain/fletas-block-redesign-level-tree-validation-and-parallel-sharding-82f11488fe04 (2019.01.22) *
Fleta_whitepaper, https://icosbull.com/whitepapers/5766/Fleta_whitepaper.pdf (2018.) *
https://medium.com/decipher-media/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8-%ED%99%95%EC%9E%A5%EC%84%B1-%EC%86%94%EB%A3%A8%EC%85%98-%EC%8B%9C%EB%A6%AC%EC%A6%88-4-1-sharding-%EC%83%A4%EB%94%A9-611a311c80e6 *
TechWhitepaper, https://fleta.io/download/FLETA_TechWhitepaper_EN_V2-web.pdf (2019.) *
Whitepaper, https://fleta.io/download/FLETA_Buisness%20Whitepaper_EN.pdf *

Also Published As

Publication number Publication date
KR102386922B1 (ko) 2022-04-20
KR102386921B1 (ko) 2022-04-20
KR20210038271A (ko) 2021-04-07

Similar Documents

Publication Publication Date Title
JP7362654B2 (ja) 分割されたブロックチェーンネットワークにおけるブロックチェーンのブロックの維持管理
AU2020200149B2 (en) Methods and apparatus for a distributed database within a network
EP3438903B1 (en) Hierarchical network system, and node and program used in same
Kaur et al. Scalability in blockchain: Challenges and solutions
Kaur et al. Blockchain: A path to the future
CN113570466B (zh) 一种交易数据处理方法、装置以及可读存储介质
WO2018229633A1 (en) Method and system of mining blockchain transactions provided by a validator node
JP2017200196A (ja) プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム
Wang et al. Performance benchmarking and optimization for blockchain systems: A survey
KR20190068799A (ko) 서비스 존 기반의 계층적 합의 방법 및 장치
Qin et al. A secure and effective construction scheme for blockchain networks
Ren et al. Interoperability in blockchain: A survey
Bai et al. On parallel mechanism of consortium blockchain: Take pov as an example
KR102386921B1 (ko) 블록 데이터를 기록한 컴퓨터로 읽을 수 있는 기록 매체
Wang et al. Chainsim: A p2p blockchain simulation framework
Hu et al. A master-slave chain model for multiple blockchains
US20240211941A1 (en) Blockchain provision system and method using non-competitive consensus algorithm and micro-chain architecture to ensure transaction processing speed, scalability, and security suitable for commercial services
Fang et al. A blockchain consensus mechanism for marine data management system
Li et al. Research and implementation of blockchain warehouse receipt trading platform based on BFT
Nezhadsistani et al. Blockchain consensus algorithms: Past, present, and future trends
JP2024091243A (ja) 商業サービスに有用な取引処理速度及び拡張性、セキュリティ性を保障するための非競争的合意アルゴリズムとマイクロチェーンアーキテクチャを用いたブロックチェーンシステム及び方法
Xie et al. Research on Distributed Blockchain Expansion Scheme Based on Xinghuo Blockchain
Goroshevsky et al. Acki Nacki: A Probabilistic Proof-of-Stake Consensus Protocol with Fast Finality and Parallelisation
JP2021077366A (ja) 情報処理装置及びプログラム
Huang et al. Secure Collaboration Between Consortiums in Permissioned Blockchains

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right