KR20220025243A - Dlt를 사용한 관계형 데이터 관리 및 구성 - Google Patents
Dlt를 사용한 관계형 데이터 관리 및 구성 Download PDFInfo
- Publication number
- KR20220025243A KR20220025243A KR1020227004860A KR20227004860A KR20220025243A KR 20220025243 A KR20220025243 A KR 20220025243A KR 1020227004860 A KR1020227004860 A KR 1020227004860A KR 20227004860 A KR20227004860 A KR 20227004860A KR 20220025243 A KR20220025243 A KR 20220025243A
- Authority
- KR
- South Korea
- Prior art keywords
- distributed ledger
- database
- sql
- data
- transaction
- Prior art date
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/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
-
- 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/24—Querying
- G06F16/245—Query processing
-
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
관계형 데이터베이스 원리들에 따라 분산형 원장에 데이터를 저장하는 것을 가능하게 하도록 그 데이터의 관리 및 구성을 가능하게 하는 스마트 계약 및 오프-체인 툴들 둘 모두의 세트가 설명된다. 교차 분산형 원장 플랫폼 규격과 재사용가능한 핵심 구성요소들을 더한 것은 함께, 관계형 원리들에 의해 통제되는 분산형 원장으로의/으로부터의 데이터의 저장 및 검색을 가능하게 하도록 분산형 원장 플랫폼들 상에 구현될 수 있는 시스템을 생성한다. 이러한 시스템의 실현은 하이퍼레저® 패브릭에 대한 시스템 체인코드의 부가를 가능하게 하고, JSON으로 표현되는 스키마들 및 데이터를 사용한다. 사용 시, 사용자는 코드, 콘솔, 또는 스마트 계약으로부터 데이터를 생성하고, 업데이트하고, 그에 대해 질의할 수 있으며, 여기서, 모든 각각의 업데이트는 분산형 원장 트랜잭션이다.
Description
본 출원은, 관계형 데이터베이스 원리들에 따른 분산형 원장으로의/으로부터의 데이터의 저장 및 검색을 가능하게 하는 데이터의 관리 및 구성에 관한 것이다.
최초의 관계형 데이터베이스 시스템들은 1960년대 후반에 컴퓨팅에서의 주요한 새로운 개발에 응답하여 나타났다. 시스템들이 더 커지고 더 복잡해짐에 따라, 새로운 업데이트된 프로그램들은 더 오래된 프로그램들에 의해 생성된 데이터에 대해 작동할 필요가 있다는 것이 명백해졌다. 기존 시스템들은, 프로그램들이 종종 그들 고유의 방식으로 각각 데이터를 저장했기 때문에 이를 어려워지게 했다. 관계형 모델은 저장 및 검색의 중요 양상들을 표준화했으며, 이를 채택한 이들은, 더 저렴한 업그레이드들 및 감소된 공급업체 종속(vendor lock-in)을 포함하는 다양한 이점들을 향유하였다.
역으로, 여전히 컴퓨터 공급업체들에 의해 프로그램 특정 저장 접근법들로 인도된 이들은, 특히, 때때로, 관계형 데이터베이스 관리 시스템(RDBMS) 플랫폼으로 바꾸려는 오래 지연된 결정이 마침내 이루어졌을 때, 더 높은 유지보수 비용들 및 더 큰 추후의 노력을 견뎠었다. 최종적으로 비-관계형 허니웰(Honeywell) FACT 언어를 벗어나기 위한 수년간 이어진 1970년대의 오스트레일리아 국방부 프로젝트가 이러한 비용들에 대한 증거이다.
그 이후로 때때로, 컴퓨팅의 다른 영역들에서의 발전들은 기존 관계형 데이터베이스 툴들을 호환가능하지 않게 또는 불편해지게 했다. 예컨대, 초기 월드 와이드 웹의 파일 지향 속성은, RDBMS 백-엔드에 대한 웹 페이지들의 연결이 달성되어 실시될 때까지 많은 프로젝트들을 관계형 데이터베이스 이전의 비효율적인 때로 되돌려 놓았다. 유사하게, 객체 지향 프로그래밍의 부상은 일시적으로, 프로그래머들이 관계형 데이터 모델을 사용하여 데이터를 표현하는 것을 덜 자연스러워하게 했다. 객체들에 캡슐화된 데이터는 RDBMS 테이블들로 조각내는 것이 어려웠다. 그러나, 관계형 표현의 이점들은, 이제 객체 관계형 맵핑(ORM)이 여전히 객제 지향 프로그래밍이 사용되는 일반적인 접근법일 정도로 충분히 컸다.
다른 한편으로는, 분산형 원장 기술(DLT)은 금세기의 정보 기술 혁명을 점화하고 그에 버금가는 것을 가능하게 하는 잠재성을 갖는다. 분산형 원장 기술은, 인터넷의 가장 크고 가장 곤란한 난제들 중 하나인 신뢰 부족에 맞서 그를 해결하고 있다. 분산형 원장 기술은 초기이지만 강력한 분산형 컴퓨팅 패러다임이며, 실제적인 목적들을 위해 데이터를 변경불가능하게 만듦으로써 인터넷에 대한 신뢰를 주는 잠재성을 갖는 지금까지의 유일한 기술이다. 불운하게도, 기존 RDBMS 플랫폼들 및 툴들은 분산형 원장 기술의 제약들과 호환가능하지 않다. 결과적으로, 데이터가 프로그램에 불가분하게 링크되는 프로그램/데이터 종속은, 1960년대의 관계형 데이터베이스 이전 시기에 프로그램들에 대한 것보다, 분산형 원장들 상의 스마트 계약들에 대해 훨씬 더 크다. 분산형 원장들 내의 데이터가, 그것이 개발자의 특정 의도였던 경우, 배치된 스마트 계약의 세부사항들에만 종속될 시스템들 및 방법들이 바람직하다.
본원에 설명된 시스템들 및 방법들은, 분산형 원장 상의 저장 전에 관계형 데이터 관리 및 구성을 가능하게 하는 스마트 계약 및 오프-체인 툴들 둘 모두의 세트를 제공하여, 분산형 원장들의 이점들을 희생함이 없이 관계형 데이터베이스들에 관한 이전에 존재하는 개발자 지식을 활용하는 것을 가능하게 만듦으로써 관련 기술분야의 요구들을 해결한다. 본보기 실시예들에서, 데이터는 관계형 원리들에 따라 관리 및 구성되고, 선택된 분산형 원장 플랫폼 상에 저장되고, 개발자에게 이미 친숙한 프로그래밍 언어들, 이를테면 구조화된 질의 언어(SQL)를 사용하여 액세스된다. 그 결과는, 분산형 원장 상의 고도로 안전하고 감사가능한 관계형 데이터베이스이다. 또한, 본원에 설명된 시스템들 및 방법들은, 스마트 계약들과 함께 사용되어, 그 스마트 계약들의 데이터 저장 양상을 더 다루기 쉬워지게 할 수 있다.
본보기 실시예들에서, 교차 분산형 원장 플랫폼 규격과 재사용가능한 핵심 구성요소들을 더한 것은 함께, 하이퍼레저® 패브릭(Hyperledger® Fabric)과 같은 일반적인 분산형 원장 기술 플랫폼들 상에서 구현될 수 있고 Node.js®와 같은 인기 있는 프로그래밍 플랫폼들로부터 액세스될 수 있는 관계형 데이터 관리 및 구성 시스템을 생성한다. 관계형 데이터 관리 및 구성 시스템은, 하이퍼레저® 패브릭과 함께 사용하기 위한 시스템 체인코드를 부가하는 능력을 가능하게 하고, 자바스크립트 객체 표기법(JSON; JavaScript Object Notation)으로 표현되는 스키마들 및 데이터를 사용한다. 또한, 패브릭의 전역 상태(world state) 데이터베이스는 데이터 저장에 사용되고, 패브릭의 신원 제공자는, 예컨대, 데이터베이스 생성, 데이터베이스 액세스에 대한 사용자 권한부여, 테이블 부가 및 스키마 수정, 데이터 기입, 및 질의만을 포함하는 5개의 수준에 대한 데이터 액세스 제어에 사용된다. 사용 시, 사용자는 코드, 콘솔, 또는 스마트 계약으로부터 테이블들을 생성하고, 업데이트하고, 그에 대해 질의할 수 있으며, 여기서, 모든 각각의 업데이트는 분산형 원장 트랜잭션이다.
본보기 실시예들에서, 관계형 데이터베이스 관리 질의로 분산형 원장 상의 트랜잭션 데이터를 포함하는 분산형 원장을 구현하는 분산형 원장 플랫폼에 대해 질의하기 위한 시스템들 및 방법들이 제공된다. 방법은, 분산형 원장 상에 데이터베이스를 생성하고 데이터베이스에 관한 정보를 기록하는 단계, 및 수신된 관계형 데이터베이스 관리 질의를 분산형 원장 플랫폼에 의해 처리될 수 있는 질의 동작으로 변환하는 단계를 포함한다. 질의 동작이 분산형 원장 플랫폼 상에서 실행되어 질의 결과를 생성하며, 질의 결과는, 분산형 원장 상에 포함시키기 위해, 분산형 원장 플랫폼에 의해 처리될 수 있는 형태로 분산형 원장 플랫폼에 로그처리된다. 본보기 실시예들에서, 관계형 데이터베이스 관리 질의는, (1) 사용자 인터페이스를 통해 사용자로부터 구조화된 질의 언어(SQL) 질의를 수신하거나; (2) 애플리케이션 프로그램 인터페이스를 통해 사용자 애플리케이션으로부터 SQL 질의를 수신하거나; 또는 (3) SQL 질의를 실행하는 스마트 계약에 의해 생성된다.
본보기 실시예들에서, 관계형 데이터 관리 및 구성 시스템은, SQL 질의를, 데이터 조작 언어(DML) 기입 동작, DML 판독 동작, 또는 데이터 정의 언어(DDL) 동작 중 하나일 수 있는 SQL 동작을 파싱하도록 적응된다. SQL 동작 및 SQL 동작에 포함된 임의의 관계형 데이터의 자바스크립트 객체 표기법(JSON) 표현이 분산형 원장 플랫폼에 의한 처리를 위해 생성된다.
다른 본보기 실시예들에서, 예컨대, 대응하는 트랜잭션의 더 명확한 상태를 페치(fetch)하기 위해, DML 기입 동작의 끝에 동작 브로드캐스트 상태(OPSTAT) 명령어를 부가함으로써, SQL 동작의 실행으로부터 초래되는 트랜잭션이 플랫폼 관련 범위까지 분산형 원장으로의 수락을 위해 진행했는지 여부가 결정된다. 분산형 원장 플랫폼에 대해 질의 동작을 실행하는 것은, SQL 질의를 호출한 엔티티가 요청된 SQL 동작을 수행할 권한을 갖는다는 것을 확인하는 것을 더 포함할 수 있다. 분산형 원장 플랫폼에 대해 질의 동작을 실행하는 것은 또한, 질의 동작 및 그의 결과의 JSON 표현으로서 분산형 원장 플랫폼에 의해 처리 및 저장될 수 있는 질의 동작을 생성하는 것을 포함할 수 있다.
SQL 동작이 SQL DML 기입 동작인 경우에, 방법들은, SQL DML 기입 동작을 실행하는 데 요구되는 바와 같은 데이터를 분산형 원장 플랫폼으로부터 검색하는 단계, 검색된 데이터를 포함하여 SQL DML 기입 동작을 실행하는 단계, 질의 결과의 임의의 새로운 또는 업데이트된 기록들의 JSON 표현들을 준비하는 단계, 및 분산형 원장 상에 포함시키기 위해 분산형 원장 플랫폼에 의해 처리될 수 있는 형태로 분산형 원장 플랫폼에 SQL DML 기입 동작 및 임의의 업데이트된 기록들을 커밋(commit)하는 단계를 포함할 수 있다. 방법들은 또한, 분산형 원장으로의 SQL DML 기입 동작의 수락에 대해 분산형 원장을 모니터링하고, SQL DML 기입 동작이 성공적이었는지 여부를 SQL 질의를 호출한 엔티티에 통보하는 단계를 포함할 수 있다.
다른 한편으로는, SQL 동작이 SQL DML 판독 동작인 경우에, 방법들은, SQL DML 판독 동작을 실행하는 데 요구되는 바와 같은 데이터를 분산형 원장 플랫폼으로부터 검색하는 단계, 검색된 데이터를 포함하여 SQL DML 판독 동작을 실행하는 단계, 질의 결과의 JSON 표현을 준비하는 단계, 및 분산형 원장 상에 포함시키기 위해 분산형 원장 플랫폼에 의해 처리될 수 있는 형태로 분산형 원장 플랫폼에 질의 결과의 JSON 표현을 로그처리하는 단계를 포함할 수 있다. 방법은 또한, 질의 결과의 JSON 표현을 SQL 질의를 호출한 엔티티에 반환하는 단계를 포함할 수 있다.
본보기 실시예들에서, 분산형 원장 플랫폼은 하이퍼레저® 패브릭 플랫폼이다. 그러한 실시예들에서, 데이터베이스는, 채널을 생성하고 어느 피어 컴퓨터들이 데이터베이스의 사본을 유지할 것인지를 정의하는 구성 트랜잭션, 및 관계형 데이터베이스에 관한 메타데이터를 기입하는 정규 트랜잭션을 실행함으로써 하이퍼레저® 패브릭 플랫폼의 분산형 원장에 대한 전역 상태 데이터베이스로서 생성될 수 있다. 또한, 분산형 원장의 트랜잭션 데이터 및 트랜잭션 데이터를 수정하기 위한 트랜잭션 명령어들을 정의하는 체인코드가 생성될 수 있다. 본보기 실시예들에서, 체인코드는, 분산형 원장 플랫폼 상의 트랜잭션 데이터로서 자바스크립트 객체 표기법(JSON)으로 관계형 데이터베이스 속성들을 정의할 수 있다. 동작의 종료 시, 전역 상태 데이터베이스는 관계형 데이터베이스 속성들로 업데이트된다. 또한, 방법은, 분산형 원장 상에 포함시키기 위해, 분산형 원장 플랫폼에 의해 처리될 수 있는 형태를 설명하는 파싱되고 변환된 구조화된 질의 언어(SQL) 질의를 생성하는 단계를 포함할 수 있다. 예컨대, SQL 질의는, 하이퍼레저® 패브릭 플랫폼 상의 관계형 관리 및 구성 시스템 규격의 JSON 요소들을 설명할 수 있다.
다른 본보기 실시예들에서, 트랜잭션 데이터를 포함하는 분산형 원장을 구현하는 분산형 원장 플랫폼, 및 동작들을 수행하는 관계형 데이터 관리 및 구성 시스템을 구현하기 위한 명령어들을 실행하는 적어도 하나의 프로세서를 포함하는 시스템이 제공되며, 동작들은, 분산형 원장 상에 데이터베이스를 생성하고 데이터베이스에 관한 정보를 기록하는 것, 수신된 관계형 데이터베이스 관리 질의를 분산형 원장 플랫폼에 의해 처리될 수 있는 질의 동작으로 변환하는 것, 질의 결과를 생성하기 위해 분산형 원장 플랫폼 상에서 질의 동작을 실행하는 것, 및 분산형 원장 상에 포함시키기 위해 분산형 원장 플랫폼에 의해 처리될 수 있는 형태로 분산형 원장 플랫폼에 질의 결과를 로그처리하는 것을 포함한다. 시스템은, (1) 관계형 데이터 관리 및 구성 시스템에 대한 사용자 인터페이스 ― 이를 통해, 사용자는 구조화된 질의 언어(SQL) 질의를 제공함 ―, (2) 관계형 데이터 관리 및 구성 시스템에 대한 애플리케이션 프로그램 인터페이스를 통해 SQL 질의를 관계형 데이터 관리 및 구성 시스템에 전달하는 사용자 애플리케이션, 또는 (3) SQL 질의를 실행하는 스마트 계약을 포함하는, 관계형 데이터베이스 관리 질의를 생성하기 위한 수단을 더 포함할 수 있다.
시스템의 본보기 실시예들에서, 적어도 하나의 프로세서는 추가로, SQL 질의를 대안들로서 데이터 조작 언어(DML) 기입 동작, DML 판독 동작, 또는 데이터 정의 언어(DDL) 동작을 포함하는 SQL 동작으로 파싱하고, SQL 동작 및 SQL 동작에 포함된 임의의 관계형 데이터의 자바스크립트 객체 표기법(JSON) 표현을 생성하기 위한 명령어들을 실행한다. 적어도 하나의 프로세서는 추가로, SQL 동작의 실행으로부터 초래되는 트랜잭션이 플랫폼 관련 범위까지 분산형 원장으로의 수락을 위해 진행했는지 여부를 결정하기 위한 명령어들을 실행할 수 있다. 예컨대, 대응하는 트랜잭션의 더 명확한 상태를 페치하기 위해, OPSTAT 명령어가 DML 기입 동작의 끝에 부가될 수 있다.
추가적인 본보기 실시예들에서, 분산형 원장 플랫폼은 하이퍼레저® 패브릭 플랫폼이고, 적어도 하나의 프로세서는, 채널을 생성하고 어느 피어 컴퓨터들이 데이터베이스의 사본을 유지할 것인지를 정의하는 구성 트랜잭션, 및 관계형 데이터베이스에 관한 메타데이터를 기입하는 정규 트랜잭션을 실행함으로써 하이퍼레저® 패브릭 플랫폼의 분산형 원장에 대한 전역 상태 데이터베이스로서 데이터베이스를 생성하고, 분산형 원장의 트랜잭션 데이터 및 트랜잭션 데이터를 수정하기 위한 트랜잭션 명령어들을 정의하는 체인코드를 생성하기 위한 명령어들을 실행한다. 적어도 하나의 프로세서는 추가로, 분산형 원장 플랫폼 상의 분산형 원장의 트랜잭션 데이터로서 자바스크립트 객체 표기법(JSON)으로 관계형 데이터베이스 속성들을 정의하는 체인코드에 대응하는 그리고 관계형 데이터베이스 속성들로 전역 상태 데이터베이스를 업데이트하기 위한 명령어들을 실행할 수 있다. 적어도 하나의 프로세서는 또한, 분산형 원장 상에 포함시키기 위해 분산형 원장 플랫폼에 의해 처리될 수 있는 형태를 설명하는 파싱되고 변환된 구조화된 질의 언어(SQL) 질의를 생성하기 위한 명령어들을 실행할 수 있다.
본원에 설명된 실시예들은 또한, 본 개시내용 전반에 걸쳐 설명된 방법들을 구현하기 위한 명령어들로 코딩된 컴퓨터 시스템들 및 컴퓨터 판독가능 매체를 포함한다. 예컨대, 본원에 설명된 시스템들 및 방법들은, 본원에 설명된 바와 같이 분산형 원장 플랫폼 상에 구현된 데이터베이스에 액세스하고 그에 데이터를 저장하기 위한 기능성을 제공하도록 클라우드 내의 컴퓨팅 플랫폼 상에 구현될 수 있다.
동일한 참조번호들이 유사한 요소들을 표시하는 첨부된 도면들의 도해들에서, 본 개시내용이 제한으로서가 아니라 예로서 예시된다.
도 1은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 블록도이다.
도 2는 본보기 실시예들의, Node.js®가 프로그래밍 언어이고 하이퍼레저® 패브릭이 사용된 분산형 원장 플랫폼인 실현에서의 관계형 데이터 관리 및 구성 시스템의 구현의 블록도이다.
도 3은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템에 대한 데이터베이스 생성에 수반되는 활동들, 구성요소들, 및 데이터를 예시하는 블록도이다.
도 4는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 기존 데이터베이스에 관계형 데이터를 기입하기 위한 동작을 예시하는 블록도이다.
도 5는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 사용자 인터페이스에 의해 또는 관계형 데이터 관리 및 구성 시스템의 언어 특정 SDK 및 애플리케이션 프로그램 인터페이스를 통해 사용자의 애플리케이션에 의해 요청된 데이터 조작 언어(DML) 판독 질의들의 실행을 예시하는 블록도이다.
도 6은 본보기 실시예들의, 최고 관리자(super-admin) 수준 미만의 액세스에 대한 사용자들의 추가를 위한 관계형 데이터 액세스 제어의 제1 부분에 수반되는 구성요소들 및 데이터를 예시하는 블록도이다.
도 7은 본보기 실시예들의, 사용자 애플리케이션 노드로서 모델링되는, 엘리먼트(ELEMENT) 패브릭-Node.js® SDK와 사용자의 애플리케이션의 상호작용 및 그들 둘 모두가 호스팅되는 실행 환경을 예시하는 블록도이다.
도 8은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템을 사용하는 분산형 원장에 대한 성공적인 SQL DML 기입 동작의 예의 논리 흐름도이다.
도 9는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템을 사용하는 분산형 원장으로부터의 성공적인 SQL DML 판독 동작의 예의 논리 흐름도이다.
도 10은 본보기 실시예들의, 데이터 정의 언어(DDL) 기입들의 성공적인 실행을 예시하는 블록도이다.
도 11은 본원에 개시된 관계형 데이터 관리 및 구성의 하나 이상의 실시예를 구현하기에 적합한 특수 목적 컴퓨터로 프로그래밍될 수 있는 전형적인 범용 컴퓨터의 블록도이다.
도 12는 "선 실행 후 순서화(execute first and order next)" 설계를 예시한다.
도 13은 각각이 원장들의 사본들 및 스마트 계약들의 사본들을 보유할 수 있는 피어 노드들로 구성된 블록체인 네트워크를 예시한다.
도 14는 원장들의 인스턴스들 및 체인코드들의 인스턴스들을 호스팅하는 피어를 예시한다.
도 15는 다수의 원장들을 호스팅하는 피어를 예시한다.
도 16은 다수의 체인코드들을 호스팅하는 피어의 예를 예시한다.
도 17은, 원장이 모든 각각의 피어 상에서 최신으로 유지됨을 보장하는 피어들을 오더러(orderer)들과 함께 예시한다.
도 18은 특정 세트의 피어들 및 애플리케이션들이 블록체인 네트워크 내에서 서로 통신할 수 있게 하는 채널들을 예시한다.
도 19는 다수의 조직들을 갖는 블록체인 네트워크 내의 피어들을 예시한다.
도 20은, 피어가 채널에 연결될 때, 그의 디지털 인증서가 채널 MSP를 통해 자신의 소유 조직을 식별하는 것을 예시한다.
도 21은 배서(endorse)된 제안 응답들을 반환하는 피어들에 의해 독립적으로 실행되는 트랜잭션 제안들을 예시한다.
도 22는 블록들을 피어들에 배포하는, 오더러 노드의 제2 역할을 예시한다.
도 23은 2개의 상태를 포함하는 원장 전역 상태를 예시한다.
도 24는 유효한 신용 카드를 갖는 것으로 충분하지 않고 그것이 또한 상점에 의해 수락되어야 함을 예시한다.
도 25는 공개 키 기반구조(PKI)의 요소들을 예시한다.
도 26은 메리 모리스(Mary Morris)로 지칭되는 당사자를 기술하는 디지털 인증서를 예시한다.
도 27은, 메리가 메시지에 서명하기 위해 자신의 비공개(private) 키를 사용하는 예를 예시한다.
도 28은 상이한 행위자들에게 인증서를 배포하는 인증 기관을 예시한다.
도 29는, 루트 CA와 중간 CA들의 세트 사이에, 이러한 중간 CA들 각각의 인증서에 대한 발행 CA가 루트 CA 그 자체이거나 루트 CA에 대한 신뢰 체인을 갖는 한 신뢰 체인이 설정되는 것을 예시한다.
도 30은 인증서가 여전히 유효하다는 것을 확인하기 위해 CRL을 사용하는 것을 예시한다.
도 31은 액세스 수준들 및 허가 결정을 예시한다.
도 32는 데이터 및 동작 객체들의 개관을 예시한다.
도 1은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 블록도이다.
도 2는 본보기 실시예들의, Node.js®가 프로그래밍 언어이고 하이퍼레저® 패브릭이 사용된 분산형 원장 플랫폼인 실현에서의 관계형 데이터 관리 및 구성 시스템의 구현의 블록도이다.
도 3은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템에 대한 데이터베이스 생성에 수반되는 활동들, 구성요소들, 및 데이터를 예시하는 블록도이다.
도 4는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 기존 데이터베이스에 관계형 데이터를 기입하기 위한 동작을 예시하는 블록도이다.
도 5는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템의 사용자 인터페이스에 의해 또는 관계형 데이터 관리 및 구성 시스템의 언어 특정 SDK 및 애플리케이션 프로그램 인터페이스를 통해 사용자의 애플리케이션에 의해 요청된 데이터 조작 언어(DML) 판독 질의들의 실행을 예시하는 블록도이다.
도 6은 본보기 실시예들의, 최고 관리자(super-admin) 수준 미만의 액세스에 대한 사용자들의 추가를 위한 관계형 데이터 액세스 제어의 제1 부분에 수반되는 구성요소들 및 데이터를 예시하는 블록도이다.
도 7은 본보기 실시예들의, 사용자 애플리케이션 노드로서 모델링되는, 엘리먼트(ELEMENT) 패브릭-Node.js® SDK와 사용자의 애플리케이션의 상호작용 및 그들 둘 모두가 호스팅되는 실행 환경을 예시하는 블록도이다.
도 8은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템을 사용하는 분산형 원장에 대한 성공적인 SQL DML 기입 동작의 예의 논리 흐름도이다.
도 9는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템을 사용하는 분산형 원장으로부터의 성공적인 SQL DML 판독 동작의 예의 논리 흐름도이다.
도 10은 본보기 실시예들의, 데이터 정의 언어(DDL) 기입들의 성공적인 실행을 예시하는 블록도이다.
도 11은 본원에 개시된 관계형 데이터 관리 및 구성의 하나 이상의 실시예를 구현하기에 적합한 특수 목적 컴퓨터로 프로그래밍될 수 있는 전형적인 범용 컴퓨터의 블록도이다.
도 12는 "선 실행 후 순서화(execute first and order next)" 설계를 예시한다.
도 13은 각각이 원장들의 사본들 및 스마트 계약들의 사본들을 보유할 수 있는 피어 노드들로 구성된 블록체인 네트워크를 예시한다.
도 14는 원장들의 인스턴스들 및 체인코드들의 인스턴스들을 호스팅하는 피어를 예시한다.
도 15는 다수의 원장들을 호스팅하는 피어를 예시한다.
도 16은 다수의 체인코드들을 호스팅하는 피어의 예를 예시한다.
도 17은, 원장이 모든 각각의 피어 상에서 최신으로 유지됨을 보장하는 피어들을 오더러(orderer)들과 함께 예시한다.
도 18은 특정 세트의 피어들 및 애플리케이션들이 블록체인 네트워크 내에서 서로 통신할 수 있게 하는 채널들을 예시한다.
도 19는 다수의 조직들을 갖는 블록체인 네트워크 내의 피어들을 예시한다.
도 20은, 피어가 채널에 연결될 때, 그의 디지털 인증서가 채널 MSP를 통해 자신의 소유 조직을 식별하는 것을 예시한다.
도 21은 배서(endorse)된 제안 응답들을 반환하는 피어들에 의해 독립적으로 실행되는 트랜잭션 제안들을 예시한다.
도 22는 블록들을 피어들에 배포하는, 오더러 노드의 제2 역할을 예시한다.
도 23은 2개의 상태를 포함하는 원장 전역 상태를 예시한다.
도 24는 유효한 신용 카드를 갖는 것으로 충분하지 않고 그것이 또한 상점에 의해 수락되어야 함을 예시한다.
도 25는 공개 키 기반구조(PKI)의 요소들을 예시한다.
도 26은 메리 모리스(Mary Morris)로 지칭되는 당사자를 기술하는 디지털 인증서를 예시한다.
도 27은, 메리가 메시지에 서명하기 위해 자신의 비공개(private) 키를 사용하는 예를 예시한다.
도 28은 상이한 행위자들에게 인증서를 배포하는 인증 기관을 예시한다.
도 29는, 루트 CA와 중간 CA들의 세트 사이에, 이러한 중간 CA들 각각의 인증서에 대한 발행 CA가 루트 CA 그 자체이거나 루트 CA에 대한 신뢰 체인을 갖는 한 신뢰 체인이 설정되는 것을 예시한다.
도 30은 인증서가 여전히 유효하다는 것을 확인하기 위해 CRL을 사용하는 것을 예시한다.
도 31은 액세스 수준들 및 허가 결정을 예시한다.
도 32는 데이터 및 동작 객체들의 개관을 예시한다.
도 1 내지 도 32에 관한 다음의 설명은 관련 기술분야의 통상의 기술자들이 특정 실시예들을 실시할 수 있게 하도록 그 특정 실시예들을 충분히 예시한다. 다른 실시예들은, 구조적, 논리적, 프로세스, 및 다른 변경들을 포함할 수 있다. 일부 실시예들의 부분들 및 특징들은 다른 실시예들의 부분들 및 특징들에 포함되거나 이를 대체할 수 있다. 청구항들에 기재된 실시예들은 그 청구항들의 모든 이용가능한 등가물들을 포괄한다.
용어
분산형 원장 기술(DLT): 네트워크에 참여하는 다수의 컴퓨터들에 걸친 복제된, 공유된, 그리고 동기화된 디지털 데이터를 가능하게 하는 다수의 기술들 중 임의의 것이다. 분산형 원장 기술은, 일단 동기화되면 집합적으로 "분산형 원장"으로 알려지는 디지털 데이터의 수정에 본질적으로 저항하도록 설계된다. 분산형 원장은 전형적으로, 새로운 정보를 검증하기 위한 프로토콜을 집합적으로 준수하는 피어-투-피어 네트워크에 의해 관리된다. 분산형 원장을 생성하고 유지할 수 있는 시스템은 분산형 원장 플랫폼으로 알려져 있다. "분산형 원장 플랫폼"은, 아이온(Aion), 아크블록(ArcBlock), 카르다노(Cardano™), 코다(Corda), 에니그마(Enigma), 이오스(EOS), 이더리움(Ethereum), 하이퍼레저® 패브릭, 하이퍼레저® 이로하(Hyperledger® Iroha), 하이퍼레저® 소투스(Hyperledger® Sawtooth), 아이콘(ICON), 아이오타(IOTA), 코모도(Komodo), 리스크(Lisk™), 멀티체인(MultiChain), 네블리오(Neblio), 넴(NEM), 네오(NEO), 엔엑스티(NxT), 퀀텀(Qtum), 스마일로(Smilo), 스텔라(Stella), 스트라티스(Straitis), 테조스(Tezos), 완체인(Wanchain), 웨이브(Waves), 및 질리카(Zilliqa)와 전술한 것으로부터 파생된 것들, 및 다른 것들과 같은 알려진 플랫폼을 포함한다. 이러한 플랫폼들 중 다수는 또한, 분산형 원장 기술 플랫폼들의 서브세트인, "블록체인 기술" 또는 "블록체인" 플랫폼들이다.
스마트 계약: 분산형 원장 플랫폼에서 발생하는 범용 계산을 제공하는 컴퓨터 프로토콜이다 플랫폼. 스마트 계약 트랜잭션들은 단순할 수 있거나 복잡한 정교한 논리를 구현할 수 있다. 결과적인 트랜잭션들은 전형적으로 원장 참여자들에게 투명하고, 추적가능하고, 비-가역적이다.
JSON: 자바스크립트 객체 표기법은, 경량이고, 텍스트 기반이고, 인간이 판독가능한 데이터 상호교환 포맷이다.
SQL: 구조 질의 언어(Structure Query Language)는, 관계형 데이터베이스 관리 시스템들에 액세스하고 조작하기 위한 표준 언어이다.
Node.js®: 브라우저 외부에서 자바스크립트(JavaScript) 코드를 실행하는 자유 오픈 소스 서버 환경이다. Node.js®는 크롬(Chrome) 브라우저의 자바스크립트 런타임 상에 구축되는 비동기식 프로그래밍 플랫폼이다. Node.js®에 관한 더 많은 정보는 Node.js 파운데이션(Node.js Foundation)의 "About Node.js®" Node.js, https://nodejs.org/en/about/에서 찾아볼 수 있다.
하이퍼레저® 패브릭: 광범위한 산업 사용 경우들의 세트에 대해 모듈성 및 다양성을 제공하는 기업 등급의 허가된 분산형 원장 플랫폼이다. 패브릭의 아키텍처는, 신원 제공자, 채널들, 전역 상태 데이터베이스, 및 사용자 및 시스템 체인코드를 포함한다. 하이퍼레저® 패브릭에 관한 추가적인 세부사항들은 본원에 첨부된 부록 A에서 입수가능하다.
체인코드: 패브릭에서, 소프트웨어는 (a) 자산 또는 자산들, 및 자산(들)을 수정하기 위한 트랜잭션 명령어들을, 다시 말해서, 비즈니스 논리를 정의하거나, (b) 전자의 실행을 통제하는 규칙들 및 활동들을 포함하는 플랫폼을 확장하거나 수정한다. 체인코드는, 키-값 쌍들 또는 다른 상태 데이터베이스 정보를 판독 또는 변경하기 위한 규칙들을 시행한다. 체인코드 기능들은 원장의 현재 상태 데이터베이스에 대해 실행되고, 트랜잭션 제안을 통해 개시된다. 체인코드 실행은, 네트워크에 제출되어 모든 피어들 상의 원장에 적용될 수 있는 키-값 기입들의 세트(기입 세트)를 초래한다. 체인코드는, 스마트 계약들의 플랫폼-독립적 개념과 동등한 것으로 간주될 수 있다.
아파치 카우치DB®(Apache CouchDB®): 하이퍼레저® 패브릭에 통합되는 전역 상태 데이터베이스에 대한 옵션이다. 아파치 카우치DB®는, 체인코드 데이터 값들이 JSON으로서 모델링될 때 풍부한 질의들을 지원한다. 카우치DB® 인덱싱 및 질의는 본원에 설명된 관계형 데이터 관리 및 구성 시스템의 본보기 실시예들에서 사용하기 위한 옵션이다. 카우치DB®에 관한 추가적인 세부사항들은 본원에 첨부된 부록 A에서 입수가능하다.
개관
관계의 모델의 값은, 데이터의 표현과 그를 판독 및 기입하는 프로그램들 사이에 독립성을 설정하는 것에서 비롯된다. 데이터 관리에 대해 재사용가능 프레임워크들을 권장하는 것에 부가하여, 관계형 데이터베이스 관리 시스템(RDBMS)들은, 하나의 프로그램의 데이터 조작들이 그 데이터를 찾아내고 그에 액세스하는 다른 프로그램의 능력을 단절시키는 것을 불가능하게 하는, 데이터의 기입에 대한 규칙들을 시행한다. 이러한 원리들 중 제1 원리는 "순서화 종속성"을 금지하는 것이다. 하나의 프로그램이 특정 순서로 물리적으로 유지되는 데이터에 의존하는 경우, 이러한 요건을 인식하지 못한 다른 프로그램은 제1 원리를 단절시킬 수 있다. 제2 원리는 "인덱싱 종속성"의 방지이다. 인덱싱은, 아마도 다른 것들을 대가로 일부 동작들의 성능을 개선하기 위한 데이터의 중복 저장이다. 그것이 모든 각각의 프로그램의 성능 선호도들에 부응하는 것은 불가능하지만, 관계형 모델은 적어도, 데이터 세트에 대한 인덱스들이 변경되는 경우에 어떠한 프로그램도 중단되지 않을 것임을 보장한다. 제3 원리는 "액세스 경로 종속성"을 방지하는 것이다. 관계형 모델에서, 프로그램은 단지 자신이 판독 및 기입하기를 원하는 데이터가 무엇인지만을 알 필요가 있고, 데이터가 저장소에 구성되는 방식에 관한 부가적인 정보를 알 필요는 없다. RDBMS들 전에, 후속하여 재배열될 수 있는 계층적 구조들로 데이터가 구성되는 것이 일반적이었으며, 이는 불필요하게, 그 데이터를 찾아내고 그에 대해 작업하는 프로그램의 능력을 단절시킨다.
본원에 설명된 관계형 데이터 관리 및 구성 시스템은 이러한 3개의 원리를 달성한다. 그러나, 이러한 3개의 원리를 달성하는 분산형 원장들과 함께 사용하기 위한 관계형 데이터 관리 및 구성 시스템을 생성하는 데 수반된 난제들을 이해하기 위해, 먼저, 분산형 원장 플랫폼들에 특정한 일부 고려사항들을 이해할 필요가 있다.
분산형 원장 기술은, 대중의 생각에서는, 그에 대한 사용이 2009년에 발명된 암호화폐와 밀접하게 연관된다. 그러나, 피어-투-피어 화폐의 생성이 또한, 다른 목적들을 위한 분산형 계산에 대한 완전히 신규한 접근법의 발명이었다. 보장된 데이터 이용가능성, 중압집중식 제어로부터의 자유, 또는 암호화 위조 방지와 같은 특징들을 활용하기 위해 광범위하게 다양한 사용들이 탐구되고 있다.
현재의 분산형 원장 채택을 둘러싼 활기는 초기의 인터넷의 채택을 연상시킨다. 웹 사이트들이 충분히 발달함에 따라, 그들을 압박하던 데이터 관리와 관련된 동일한 잘못된 단계들을 되살리거나 피할 잠재성이 존재한다. 초기 웹 사이트들과 유사하게, 분산형 원장들의 암호화폐 사용들은, 비교적 단순한 데이터 구조들 및 그를 통제하기 위한 하드-코딩된 비즈니스 논리를 특징으로 한다. 그러나, 스마트 계약들의 후속 발명은 임의적 복잡도의 데이터 및 규칙들에 대한 기회를 열었다.
공급망 물류(supply chain logistics)와 같은 기업 사용 경우들은, 기존의 표준화된 데이터 관리 툴들의 이점 없이도 종래의 솔루션들에 필적하고 곧 그를 크게 앞설 양들로 정보 및 논리를 분산형 원장들 상에 부여하고 있다. 모든 각각의 프로그래머가 자신 고유의 저장소를 설계함에 따라, 그 결과는 또 다시, 데이터를 기입하는 프로그램들(스마트 계약들)에 밀접하게 결합된 데이터이다. 본원에 설명된 것과 같은 관계형 데이터 관리 및 구성 시스템은 이러한 결합을 감소시킬 필요가 있다.
불운하게도, 분산형 원장들에서 연결을 단절시키는 것은, 관계형 데이터베이스들을 구현할 때 직면한 상황보다 더 복잡하다. 그의 원래의 완전히 탈중앙집중형(decentralized) 형태에서, 분산형 원장들은 실제로, 논리와 데이터 간의 밀접한 연결에 의존하여, 참여자들 간의 합의 및 신뢰를 만든다. 모든 참여자들은 정확히 동일한 논리를 실행하여, 그들이 정확히 동일한 결론들을 수신함을 확인한다. 이는, 그 분산형 원장 플랫폼들 상의 데이터의 관리에 대한 일부 주요한 암시들로 이어진다. 예컨대, 분산형 원장으로의 데이터의 기입에 영향을 미치는 데이터 관리 시스템의 임의의 부분은, 데이터를 통제하는 스마트 계약들의 제어 하에서 및 스마트 계약 내에 위치되어, 본질적으로 스마트 계약 그 자체의 일부가 된다. 또한, 스마트 계약의 일부로서, 참여자들이 동일한 데이터 생성 논리를 실행할 수 있도록, 데이터는 네트워크 내의 모든 참여자들에게 전파된다.
그러나, 논리와 데이터 사이의 이러한 결합은, 제한적 분산형 원장 플랫폼들에 대해서도, 관계형 모델의 이점들을 무관해지게 하지 않는다. 첫째, 데이터가 집합적 동의에 의해 업데이트될 수 있게 하는 동일한 합의 메커니즘은, 참여자들이 기존의 스마트 계약들에 대한 업그레이드 또는 부가들에 동의할 수 있도록 구성될 수 있다. 그러나, 그 계약들이 기존의 분산형 원장 데이터를 판독하고 사용할 수 없는 경우, 이들은 유용하지 않을 것이다. 스마트 계약들은 일반적으로 오늘날 그렇게 할 수 없고, 결과적으로, 그러한 업그레이드들은, 그들의 유용성에도 불구하고, 생산 분산형 원장 시스템들에서 흔히 보이지 않는다.
개별 스마트 계약 프로그램들 내에서도, 계약들이 범위 및 복잡도가 증가함에 따라, 저장에 대한 일관된 접근법이 점점 더 중요해지고 있다. 오늘날의 전자 화폐들 및 거래가능 자산들의 비교적 단순한 규칙들은 많은 개발자들, 재사용가능 구성요소들, 및 진화하는 요건들을 수반하는 완전 분산형 원장 기반 공급망들 및 소셜 플랫폼들로 바뀌고 있다. 그 개발자들은, 그들이 많은 종래의 프로그램들에 대해 그러한 것처럼, 데이터 저장에 대한 예측가능한 접근법을 원할 것이며, 관계형 모델은 그러한 예측가능한 접근법을 제공한다.
관계형 모델의 유용성은 순수 판독 동작들에 대해 훨씬 더 큰데, 그 이유는, 이들이, 일부 플랫폼들에서 데이터 그 자체에 대한 액세스 허가에 대한 것 외에는, 합의에 의해 통제되지 않기 때문이다. 이는, 새로운 이유들로 기존 데이터를 사용하려고 노력할 만한 가치가 있는 더 많은 상황들로 이어진다. 분산형 원장 상의 데이터가 관계형 규칙들에 따라 저장되는 경우, 그것은, 원래의 스마트 계약 프로그래머들에 의해 구상된 것을 넘어서는 목적들을 위해서, 분산형 원장의 내부 또는 외부에서 실행되는 RDBMS 시스템에 의해 효율적으로 판독 및 처리될 수 있다.
분산형 원장 기술의 모든 각각의 구현이 모든 각각의 분산형 원장 기술 특징을 활용하거나 암호화폐들과 같은 공용 네트워크에서 볼 수 있는 상호 불신의 수준을 가정하도록 강제되는 것은 아니다. 특히, 기업 설정들에서, 다양한 이유들로 인해 부분적 채택이 실제로 더 흔하다. 일반적인 상황들은, 암호화 위조 방지 및 데이터 복제와 같은 특징들을 달성하기 위한 편리한 방식으로서의 분산형 원장 플랫폼들의 사용을 포함한다. 기업들은 또한, 아마도 향후의 더 분산된 애플리케이션을 향한 제1 단계로서, 완화된 합의 규칙들 또는 중앙집중형 프론트 엔드로, 그들의 완전한 제어 하에서 분산형 원장 네트워크를 구현한다. 또한, 높은 신뢰 수준들을 갖는 컨소시엄들은 지원 직원에 대한 엄격한 스마트 계약 시행과 함께 분산형 원장 네트워크를 설정하지만, 관리자들 및 내부 감사자들이 자신 고유의 권한으로 직접 분산형 원장 데이터를 업데이트하는 것을 허용한다. 이러한 경우들 각각에서, 판독 전용 동작들에 대해 대부분 그러할 수 있는 바와 같이, 분산형 원장 데이터가 판독 및 기입 둘 모두에 대해 종래의 데이터베이스처럼 정확히 관리될 수 있는 경우들이 존재한다.
본보기 실시예들
본원에 설명된 관계형 데이터 관리 및 구성 시스템은 위에서 논의된 이점들을 전달하며, 상이한 분산형 원장 플랫폼들 및 프로그래밍 언어들에 걸쳐 관계형 데이터 관리 및 구성 시스템의 구현들을 표준화할 수 있는 규격들의 세트를 제공한다. 본원에 설명된 관계형 데이터 관리 및 구성들은 또한, 분산형 원장에 대한 관계형 데이터의 관리 및 구성을 지시하는 데 사용하기 위한 구조화된 질의 언어(SQL)의 표준어(standard dialect)의 서브세트를 제공한다. 본원에 설명된 관계형 데이터 관리 및 구성 시스템은, 다양한 플랫폼들 및 언어들에 걸친 구현을 위해 추가로 설계되었다. 본보기 실시예들에서, 관계형 데이터 관리 및 구성 시스템은, Node.js®로 작성된 사용자 프로그램들을 지원하기 위한 메커니즘들로, 하이퍼레저® 패브릭 분산형 원장 네트워크 및 Node.js® 프로그래밍 언어 상에서 구현된다. 그러나, 다른 분산형 원장 플랫폼들 및 프로그래밍 언어들이, 그러한 플랫폼들 및 언어들의 수반되는 이점들 및 단점들과 함께 사용될 수 있다는 것이 인식될 것이다.
관계형 데이터 관리 및 구성 시스템의 설명이 모든 구현들을 안내하도록 의도된 규격들, 인터페이스들, 및 핵심 구성요소들의 세트로 시작될 것이다. 도 1은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템(100)의 블록도이다. 도 1에 예시된 관계형 데이터 관리 및 구성 시스템(100)의 부분들은 모든 구현들에 공통적인 반면, 다른 부분들은 맞춤화되지만 공통 규격들의 세트를 따른다. 도 1은 이러한 구성요소들 및 규격들을 도시하는 적응된 구성요소 도면이다. 본 설명 전반에 걸쳐, 관계형 데이터 관리 및 구성 시스템(100)은 설명의 용이성을 위해 "ELEMENT"로 또한 지칭된다.
공통 규격들은 개념적 요건들을 표시하기 위해 《규격》 정형화를 갖는 객체 요소들로서 표현된다. 규격들은 관계형 데이터 관리 및 구성 시스템의 모든 구현들 중에서 공통 방식으로 구현될 것으로 예상되는 양상들이다. 《추상화》 정형화는 존재하도록 요구되지만 각각의 실현에서 상이하게 구현될 실제 소프트웨어 구성요소들을 표현한다. 도시된 인터페이스들은 또한 모든 구현들에 공통인 규격들이다.
언어 특정 소프트웨어 개발 키트(SDK) 구성요소들(102)은 사용자 애플리케이션들과 통합되고, 관계형 데이터 관리 및 구성 시스템(ELEMENT) API (104)에 명령들을 중계한다. 언어 특정 SDK 규격(102)은 상이한 사용자 프로그래밍 언어들에 걸쳐 공통 경험을 생성하는 것을 목표로 한다. 지원되는 명령들 중에는 ELEMENT SQL(105)로서 본원에서 특정되는 SQL의 서브세트가 있다. 언어 특정 SDK(102)로부터의 모든 다른 호출들 및 ELEMENT 사용자 인터페이스(UI)(106)로부터의 입력들과 함께, 수신된 명령들은, ELEMENT 데이터 정의 언어(DDL)파서(110)에 대한 종속성을 갖는 ELEMENT 콘솔(108)에 의해 파싱, 검증 및 처리된다. ELEMENT UI(106)는 관리 및 보고 작업들을 위한 직접적인 인간 상호작용들을 처리한다. ELEMENT UI(106)는, 사용자가 유효한 입력 질의들을 구성하는 것을 지원하고 시스템 응답들을 구성된 포맷으로 표현하는 그래픽 웹 플랫폼이다.
본보기 실시예들에서, DDL 동작들만이 ELEMENT DDL 파서(110)를 통해 ELEMENT 콘솔(108)에 의해 처리된다. 데이터 조작 언어(DML) 동작들은 서비스 계층 인터페이스(114)를 통해 분산형 원장 플랫폼 특정 구성요소들(112)로 전달되고, 분산형 원장 플랫폼 특정 구성요소들(112)에 의한 처리를 위해 ELEMENT SQL DML 파서(116)에 의해 파싱된다. 위에 설명되지 않은 기능성은 일련의 분산형 원장 플랫폼 특정 구성요소들(112)에 의해 실현된다. 서비스 계층 인터페이스(114)는, 이러한 구성요소들 및 그들의 기능성에 대한 진입점인 분산형 원장 플랫폼 특정 계층(118)과 ELEMENT 콘솔(108) 사이의 링크로서의 역할을 한다. 서비스 계층 인터페이스(114)는 사용자들의 스마트 계약들에 의해 개시되는 동작들의 가능한 예외를 갖는 모든 동작들에 수반된다.
분산형 원장 플랫폼 특정 서비스 계층(118)은 관계형 데이터 관리 및 구성 시스템(100)의 주요 동작 논리를 형성하고, 모든 사용자 및 데이터 관리 동작들을 달성하는 것을 담당한다. 그러한 동작들은 분산형 원장 플랫폼 특정 서비스 계층(118) 그 자체와 ELEMENT 특징들이 부가된 분산형 원장 플랫폼(120) 사이에서 분할된다. 작업의 정확한 분할은 분산형 원장 플랫폼의 능력들에 의존한다. 기능성은 3개의 하위-규격들에 의해 제공된다:
1. 관계형 데이터 액세스 제어 규격(122)은, 관계형 데이터 관리 및 구성 시스템(100)의 모든 구현들이 따르는 5개 수준으로 개략적으로 나눠진 액세스 제어 모델을 특정한다. 이러한 규격은, 사용자 역할들 및 사용자들이 데이터에 대한 액세스를 포함하여 관계형 데이터 관리 및 구성 시스템(100)의 시스템 기능성에 대한 액세스에 어떻게 영향을 미치는지를 문서화한다. 액세스 제어는 상이한 플랫폼들에 대해 상당히 상이한 접근법들을 사용할 것이다. 그 규격은, 공통된 양상들을 문서화하는 부록 B이다.
2. 분산형 원장에 대한 관계형 데이터 규격(124)은 지원되는 데이터 표현들(JSON 스키마들) 및 데이터 동작들에 대한 요건들을 정의한다. 이러한 규격은, 부록 C에서 관계형 데이터 저장에 대한 요건들을 문서화한다.
3. 스마트 계약 통합 규격(126)은 어느 관계형 데이터 특징들이 스마트 계약들로부터 액세스가능한지를 특정한다.
언어 특정 SDK들(102) 각각은 분산형 원장 애플리케이션 구현자들에게 인기 있는 프로그래밍 언어로부터 ELEMENT API(104)의 전체 기능성에 액세스하기 위한 인터페이스들을 제공한다. 이러한 SDK들에 대한 규격은 기능 이름들, 파라미터 순서화 및 의미, 반환 값들 및 오류들 등에 관한 일관성을 최대화한다. 패브릭 및 Node.js®를 사용하여 구현되는 실현이 아래에서 설명된다.
본보기 실시예들에서, ELEMENT API(104)는 데이터베이스 동작들을 호출하기 위한 공통 진입점으로서 관계형 데이터 관리 및 구성 시스템(100) 내에서 내부적으로 사용되는 인터페이스이다. 이는, ELEMENT UI(106) 및 무엇이든 간에, 사용되고 있는 실현에 존재하는 언어 특정 SDK(102) 둘 모두에 의해 호출된다. 이는, 때때로 "REST API"로 지칭되는 웹 인터페이스의 형태로 특정된다. ELEMENT API(104)는 ELEMENTDB_Console(108)에 의해 구현되고 관계형 데이터 관리 및 구성 시스템(100)의 모든 실현들에서 재사용된다. ELEMENT API(104)의 추가적인 세부사항들은 부록 D에서 제공된다.
ELEMENT UI(106)는 사용자들이 관계형 데이터 관리 및 구성 시스템(100)에 의해 구현되는 데이터베이스에 대해 수동으로 작업할 수 있게 하는 사용자 인터페이스 구성요소이다. ELEMENT UI(106)는 사용자들을 추가하고 사용자 액세스 수준들을 조정하고, 내장된 텍스트 편집기를 사용하여 이용가능한 데이터베이스들에 대해 SQL 질의들을 실행하고, 질의 예들 및 ELEMENT 특정 SQL 언어 확장들의 구문을 포함하는 사용자 문서에 액세스하고, 제출된 질의들의 상태 정보를 보고 실행이 성공적으로 완료된 질의들로부터의 반환된 데이터를 보는 능력을 사용자들에게 제공한다.
ELEMENT 콘솔(108) 및 ELEMENT SQL DDL 파서(110)는 관계형 데이터 관리 및 구성 시스템(100)의 모든 실현들에 존재하는 핵심 구성요소들이다. ELEMENT 콘솔(108)은, 언어 특정 SDK(102)로부터 또는 ELEMENT 콘솔(108)이 또한 서빙하는 ELEMENT UI(106)를 통해 사용자들로부터 직접 비롯되는 데이터베이스 명령들을 ELEMENT API(104)(표현 상태 전달(REST) API일 수 있음)를 통해 수락한다. ELEMENT 콘솔(108)은 그 명령들을, 관계형 데이터 관리 및 구성 시스템(100)의 분산형 원장 플랫폼 특정 구성요소들(112)에 링크하는 서비스 계층 인터페이스(114)로 전달될 수 있는 형태로 변환한다.
본보기 실시예들에서, 관계형 데이터 관리 및 구성 시스템(100)의 공통 구성요소들(104, 106, 108, 110)은 필요한 경우 배치 유연성 및 수평 스케일링을 허용하는 웹 서비스로서 Node.js®로 구현된다.
일부 ELEMENT 특정 확장들과 함께 전형적인 SQL 동작들을 포함하는 ELEMENT SQL(105)은 개발자들에게 가장 친숙한 방식으로 RDBMS 동작들을 기술하기 위한 문법이다. 본보기 실시예들에서, 관계형 데이터 관리 및 구성 시스템(100)에 대한 SQL 구문은 ISO/IEC 9075(현재 SQL:2016)의 서브세트와의 호환성을 위해 설계되었다. 액세스 관리 및 구현을 위해서, ELEMENT SQL에서의 동작들은 DDL, DML 기입 및 DML 판독 질의들로 분류되었다.
SQL에 대한 ELEMENT 확장은 분산형 원장 데이터 환경에서 작업하기 위한 적응들 뿐만 아니라 편의성 기능들을 포함한다. 이러한 확장들은 SQL 구문과 조합되어 사용되어 ELEMENT 시스템에 대한 유의미한 질의를 형성할 수 있는 ELEMENT 특정 키워드들이다. 본보기 실시예들에서의 확장 키워드들은 다음을 포함한다:
1. 동작 브로드캐스트 상태(OPSTAT) - 이 동작은, 특정 동작의 트랜잭션이 이용된 특정 분산형 원장 플랫폼과 관련된 범위까지 분산형 원장 내로 진행되었는지 여부를 확인한다. DDL 동작들에 대한 OPSTAT는 관계형 데이터 관리 및 구성 시스템(100)에 대해 기본으로 설정되지만, OPSTAT는 그 트랜잭션의 더 명확한 상태를 페치하기 위해 DML 기입 동작의 끝에 부가될 수 있다. OPSTAT가 사용되는 동안 예상되는 3개의 가능한 응답, 즉, 성공(SUCCESS), 실패(FAILURE) 또는 시간초과(TIMEOUT)가 존재한다.
2. 질의수준(QUERYLEVEL) - QUERYLEVEL 특징은 관계형 데이터 관리 및 구성 시스템(100)의 특정 기록에 관한 메타데이터 정보를 페치하기 위해 DML 판독 동작들(예컨대, 선택(SELECT))과 배타적으로 작업된다. QUERYLEVEL을 사용함으로써 획득될 수 있는 2개의 수준의 정보가 존재하는데, 첫 번째는 기록에 관한 기본 정보이고, 두 번째는 기록 생성 날짜, 마지막 수정된 날짜, 사용자에 의한 수정, 및 다른 세부사항들과 같은 세분화된 정보를 제공하는 더 심도 있는 질의이다.
3. 북마크(BOOKMARK)- 이 특징은, 관계형 데이터 관리 및 구성 시스템(100) 내의 기록 카운트에 의해 정의되는 페이지에서의 테이블 데이터의 검색에 관한 것이다. 기본으로, 행 카운트에 대한 제한으로 실행되는 모든 각각의 질의는, 동일한 기준들에 기반하여 다음의 동일한 크기의 데이터 페이지에 대한 참조의 역할을 하는 북마크 값을 동반한다. 그것은 BOOKMARK 키워드가 제공되는 경우(SELECT 질의들에만 적용가능함) 질의 결과들과 함께 포함될 것이다.
4. ELEMENT_COLUMN_DEFAULT - 이 키워드는, 관계형 데이터 관리 및 구성 시스템(100) 내의 테이블 열에 대해 기본 값이 사용되어야 함을 표시하기 위해 업데이트(UPDATE) 또는 삽입(INSERT) SQL 동작들과 함께 사용된다. 기본 값은 테이블을 생성하는 동안 열에 배정될 수 있다. 기본 값 없이 구성된 열들은 이 키워드에 의해 영향을 받지 않을 것이다.
아래의 부록 E의 ELEMENT SQL 규격은, 관계형 데이터 관리 및 구성 시스템(100)에 의한 처리를 위한 질의들 및 명령들을 표현하는 데 사용될 수 있는 SQL 구문의 변형을 형성하도록 SQL 구문과 조합된, 이러한 키워드들 각각의 부가적인 세부사항들을 제공한다.
서비스 계층 인터페이스(114)는 분산형 원장 플랫폼에 대한 관계형 데이터 관리 및 구성 시스템(100)의 모든 각각의 실현에서 지원될 기능성들을 포함한다. 서비스 계층 인터페이스(114)에 대한 규격은 이러한 서비스 계층에서 또는 분산형 원장 플랫폼 그 자체 상에서 실현될 수 있는 기능들의 서브세트에 더하여 전체 인터페이스를 커버한다. 이러한 기능들은 다음을 포함한다:
데이터베이스 생성 및 드롭
테이블 생성, 변경 및 드롭
데이터베이스 객체 메타데이터의 검색
DML 동작들, 예컨대, 기록들의 삽입 및 선택
인덱스 생성, 변경, 및 드롭과 같은 추가적인 DDL 동작들
사용자 특권 관리.
분산형 원장 컨텍스트에서의 수정 및 삭제는, 분산형 원장 데이터 이력의 변경불가능성 때문에, 변경 또는 삭제 표시자들의 첨부에 의해 항상 행해질 것이라는 것이 유의된다. 관계형 데이터 관리 및 구성 시스템(100)은 또한, 적어도 기록-수준 변경들을 커버하는 벌크 트랜잭션 지원을 제공하도록 요구된다.
본보기 실시예들에서, 서비스 계층 인터페이스(114)는 Node.js®로 구현되고, 표적화된 SDK 언어 또는 분산형 원장 플랫폼에 관계없이 재사용된다. 인터페이스를 통해 수신된 요청들을 서비스하는 것은, 분산형 원장 특정 구성요소들(112)에 의해 수행되며; 일부 기능들은, 스마트 계약 통합을 달성하기 위해 요구되는 바와 같이, 분산형 원장 플랫폼 그 자체 상에서만 실현가능하다.
ELEMENT 특징 규격이 부가된 분산형 원장 플랫폼(120)은, 관계형 기능성이 그 플랫폼 상에서의 스마트 계약들에 의해 사용가능하기 위해 분산형 원장 플랫폼 상에 직접 구현되어야 하는 기능성을 설명한다. 플랫폼들 그 자체와 같이, 이러한 구현들은 접근법이 크게 상이할 것이다. 이러한 규격들은, 관계형 데이터 및 스키마들에 대한 공통 JSON 기반 데이터 포맷을 포함하여, 여전히 공통일 것들을 제시한다. 규격들은 3개의 범주: 분산형 원장에 대한 관계형 데이터, 액세스 제어, 및 스마트 계약 통합으로 분할된다.
1. 분산형 원장 상의 관계형 데이터(RDODL) 규격
관계형 데이터 관리 및 구성 시스템(100)에서의 관계형 데이터 및 관련된 기능성을 특정하는 데 5개의 친숙한 추상화가 사용된다. 이들은, 데이터베이스, 테이블, 필드, 인덱스, 및 기록이다. 이러한 개념들이 상이한 분산형 원장 플랫폼들에 대해 구현될 수 있는 방식에 상당한 차이들이 존재하지만, 다음은 모든 각각의 플랫폼에 대해 해당된다:
1. 5개의 요소 유형 각각의 인스턴스가 표준 ELEMENT 포맷으로 독립형 JSON 문서에 의해 표현될 것이다.
2. 이 문서들은 다른 분산형 원장 트랜잭션들과 동일한 방법 및 합의를 사용하여 분산형 원장에 기입된다.
3. 이러한 요소들 중 하나에 대한 상태의 각각의 수정 또는 변경은 분산형 원장에 JSON 문서의 완전한 업데이트된 버전을 첨부함으로써 표현된다.
5개의 객체에 대한 JSON 스키마 정의들 및 인덱싱을 위한 최소 요건들은 관계형 데이터 관리 및 구성 시스템(100)의 설계에서 형식적으로 특정된다.
2. 관계형 데이터 액세스 제어 규격
관계형 데이터 관리 및 구성 시스템(100)의 구현들은, 데이터베이스 수준에서 개별 분산형 원장 신원들에 대해 정의되는 개략적으로 나눠진 액세스 제어를 지원한다. 5개의 액세스 수준에 승인되는 특권들은 다음과 같다:
- 최고관리자(SuperAdmin) ― 생성 및 드롭과 같은 데이터베이스 관리에 더하여 관리자 액세스 수준의 모든 특권들.
- 관리자(Admin) ― 특권 관리 기능성에 대한 액세스에 대하여 DDL 액세스 수준의 모든 특권들.
- DDL ― (예컨대) 테이블들 및 인덱스들의 스키마를 변경하는 기능들을 포함하는, DDL로서 분류되는 기능성에 대한 액세스에 더하여, DML 기입 액세스 수준의 모든 특권들.
- DML 기입 ― 삽입들과 같은 데이터 기입들을 포함하는, DML 기입으로서 분류된 기능성에 대한 액세스에 더하여, DML 판독 액세스 수준의 특권들.
- DML 판독 ― DML 판독으로서 분류된 기능성에 대한 액세스. 이는, 관계형 데이터의 질의들의 선택, 스키마 검색, 통계 보기 등을 포함한다.
데이터 정의 언어(DDL)는, 관계형 데이터의 구조, 구성 또는 기술(description)을 변경하는 동작들을 지칭한다. 데이터 조작 언어(DML)는 관계형 데이터 그 자체를 수반하는 동작들을 지칭한다.
관계형 데이터 관리 및 구성 시스템(100)의 구현들은, 스마트 계약 통합을 가능하게 하는, 분산형 원장 동작들에 사용되는 것과 동일한 신원들에 대한 액세스, 그리고 관계형 데이터가 분산형 원장 상에 저장된 다른 데이터와 동등한 분산형 원장 특성들을 갖는 요건에 기반한다.
3. 스마트 계약 통합 규격
언급된 바와 같이, 관계형 데이터 관리 및 구성 시스템(100)의 주요 양상은, 스마트 계약들로부터 직접 관계형 데이터 기능성의 대부분에 액세스하는 능력이다. 스마트 계약 통합을 위해, 스마트 계약들은 DDL 데이터베이스 동작들을 제외한, 언어 특정 SDK(102)에 대해 특정된 것들과 동등한 기능들을 실행하는 능력을 갖는다. 이러한 호출들에 대한 분산형 원장 고려사항들, 예컨대, 입력들 및 결과들의 합의 및 변경불가능한 기록은 고유한 스마트 계약 실행과 동등하다. 또한, 이러한 기능들의 호출은, 관계형 데이터 관리 및 구성 시스템(100)이 실현되는 분산형 원장 플랫폼에서 가능한 범위까지 언어 특정 SDK(102)에서 설명된 형태, 명명, 및 의미론을 준수해야 한다. 스키마 변경들과 같은 DDL 동작들은 스마트 계약 통합에서 제외되는데, 그 이유는, 이러한 동작들이 종종, 단일 분산형 원장 트랜잭션 내에서 그들을 실행하는 것이 지원불가능할 정도의 관계형 저장에 대한 광범위한 업데이트들을 수반하기 때문이다.
ELEMENT 특징 규격이 부가된 분산형 원장 플랫폼(120)은, 구현에 상관없이, 비-분산형 원장 프로그래머들에게 이미 친숙한 구문 및 의미론을 사용하여 분산형 원장에 대한 관계형 데이터 저장 및 동작들을 가능하게 하고 분산형 원장 플랫폼들에 걸쳐 동일한 공통 인터페이스들, 구문, 및 요건들의 세트, 특히, 관계형 데이터 관리 및 구성 시스템(100)의 모든 구현들에 공통인 SQL 구문을 사용하는 능력을 설명한다는 것이 인식될 것이다. 저장은, 분산형 원장 플랫폼 구현들에 걸친 향후의 데이터 이식성(portability)을 용이하게 하는 표준화된 JSON 데이터 포맷을 사용하여 구현된다. 요구된 기능성들의 세트는 플랫폼들에 걸쳐 표준화되므로, 분산형 원장 플랫폼의 선택은 관계형 데이터 관리 및 구성 시스템(100)과 같은 RDODL 플랫폼을 사용하기로 한 결정과 별개의 관심사일 수 있다. 그러한 능력들은, 언어 특정 SDK(102), 사용자 콘솔 및 API, 또는 스마트 계약들을 통한 일관된 관계형 데이터 저장 액세스를 가능하게 한다.
하이퍼레저® 패브릭 상의 관계형 데이터 관리 및 구성 시스템(100)
본보기 실시예들에서, 자신의 분산형 원장 플랫폼에 하이퍼레저® 패브릭을 사용하는, Node.js® 애플리케이션을 위한 소프트웨어 개발 키트가 제공된다.
도 2는 패브릭 구현이 본원에 설명된 관계형 데이터 관리 및 구성 시스템(100)의 규격들에 더하여 부가적인 기능성을 실현하는 방식에 대한 시각적 개요를 제공한다. 본보기 실시예들에서, 패브릭 상의 관계형 데이터 관리 및 구성 시스템(100)의 RDODL 실현은 다음의 양상들을 수반한다. 관계형 데이터 관리 및 구성 시스템(100)의 데이터베이스들은 패브릭의 "채널" 개념을 이용한다. 관계형 데이터 관리 및 구성 시스템(100)의 패브릭 서비스 계층은, 새로운 데이터베이스가 요청될 때마다 패브릭 채널을 생성하기 위해 패브릭 SDK(분산형 원장 플랫폼과 함께 포함됨)를 사용한다. 관계형 데이터 관리 및 구성 시스템(100)의 기능성을 포함하는 시스템 체인코드는 피어 노드들에 이미 존재하고, 새롭게 생성된 채널에 액세스가능하게 된다. 채널 생성은 또한 모든 참여 피어 노드들 상에서 새로운 분산형 원장 및 "전역 상태" 데이터베이스를 자동으로 설정한다. 또한, 스크립트는 트랜잭션을 개시하여, 분산형 원장 상에 데이터베이스에 관한 고수준 정보를 기록하기 위해 관계형 데이터 관리 및 구성 시스템(100)의 시스템 체인코드를 호출한다. 모든 후속 데이터베이스 기입 동작들은 유사한 트랜잭션들, 및 RDODL 규격에 따라 JSON 포맷들로 분산형 원장에 데이터 객체들을 첨부하는 것을 수반한다. 원장에 대한 데이터베이스 정보의 각각의 그러한 첨부는 또한 그의 전역 상태 데이터베이스에 각각의 피어에 의해 반영된다. 이는, 각각의 데이터 객체의 현재 버전이 판독 동작들에 대해 신속하게 이용가능해지게 한다.
도 2는, 관계형 데이터 관리 및 구성 시스템(100)의 핵심 구성요소들 및 규격들에 부가하여, Node.js®가 프로그래밍 언어이고 하이퍼레저® 패브릭이 사용된 분산형 원장 플랫폼인 실현에서의 관계형 데이터 관리 및 구성 시스템의 구현의 블록도이다. 도 2는 패브릭/Node.js® 구현이 일부 부가적인 기능성들과 함께 도 1에 약술된 규격들을 실현하는 방식에 초점을 맞춘다.
도 2에 예시된 바와 같이, Node.js® SDK 구성요소(200)는, 언어 특정 SDK(102)의 사용자 언어 특정 기능성을 실현하고, 개발자들이 그들의 애플리케이션 코드로부터 직접 관계형 데이터 관리 및 구성 시스템(100)과 상호작용할 수 있게 한다. Node.js® 애플리케이션들과 함께 사용하기 위해 개발된 Node.js® SDK 구성요소(200)의 버전의 세부사항들은 부록 F에서 제공된다. ELEMENTDB 콘솔(108), ELEMENT API(104), ELEMENT UI(106), 및 서비스 계층 인터페이스(114)는 모든 구현들에 공통이며, 도 1과 동일하다. 그 아래에서, ELEMENT 패브릭서비스(FabricService)(202)는 모든 플랫폼 동작들에 대한 파사드(facade)를 실현한다. ELEMENT 패브릭서비스(202)는 API 계층과 분산형 원장 사이의 상호작용을 위한 중간자로서의 역할을 하는 서비스 계층 인터페이스(114)를 구현한다. 그의 서비스들은 부록 G에서 더 상세히 설명되는 바와 같은 RDBMS 관련 동작들을 수행하는 것을 돕는다. ELEMENT SQL 파싱의 실현은, 패브릭 실현에서 두 번 나타나는 ELEMENT 파서(Element_Parser)(204)로 지칭되는 구성요소에 의해 실현된다. 먼저, Element_Parser(204)는 ELEMENTDB 콘솔(108)에 종속된 것으로 나타나고 DDL 파서를 실현한다. 이는 모든 실현들에 공통이다. 둘째, Element_Parser(204)는 ELEMENT 체인코드(Element_Chaincode)(206)에 종속된 것으로 나타나고, DML SQL을 사용자 체인코드 스마트 계약들에서 지원가능하게 하는 DML 파싱을 제공한다. Element_Parser(204)에 대한 규격은 부록 H에서 제공된다.
분산형 원장 플랫폼에 ELEMENT 특징들을 더한 규격에 대한 그의 종속성을 통해 패브릭서비스(202)를 직접 지원하는 것은, 사용자들이 등록되고 액세스 특권들이 기록되는 신원 제공자(예컨대, 패브릭 인증 기관(208)), 특정 인덱싱 능력들을 위해 직접 액세스되는 전역 상태 데이터베이스(예컨대, 패브릭 전역 상태 데이터베이스(210)), ELEMENT 패브릭 피어 이미지(212), 및 관계형 데이터 관리 및 구성 시스템(100)에 맞춤화된 하이퍼레저® 패브릭(214)의 핵심 구성요소이다.
Element_Chaincode(206)는, 패브릭에 대한 모든 데이터베이스 관련 동작들을 수행하고 또한 신원 제공자(예컨대, 인증 기관(208)) 및 전역 상태 데이터베이스(예컨대, 패브릭 전역 상태 데이터베이스(210))에 대한 종속성들을 가지는 ELEMENT 패브릭 피어 이미지(212)에 부가된 부가적으로 생성된 시스템 체인코드이다. 피어 그 자체 내의 원장 저장과 결합되어, 이들은 ELEMENT 패브릭 피어(214)에게 액세스 제어로 관계형 데이터를 실현할 권한을 준다. 또한, 사용자의 스마트 계약들이 시스템 체인코드를 호출할 수 있으므로, 이는 스마트 계약 통합을 또한 실현한다. Element_Chaincode(206)에 대한 규격은 부록 I에서 제공된다.
도 3은 관계형 데이터 관리 및 구성 시스템(100)에 대한 데이터베이스 생성에 수반되는 활동들, 구성요소들, 및 데이터를 예시하는 블록도이다. 데이터에 관하여, 데이터베이스 생성은 2개의 패브릭 트랜잭션을 수반한다. 첫 번째는 채널을 생성하고 어느 피어가 데이터베이스의 사본을 유지할 것인지를 정의하는 "구성 트랜잭션"이다. 두 번째는 관계형 데이터베이스 그 자체에 관한 메타데이터를 기입하는 정규 트랜잭션이다.
도 3은 좌측 상에 예시된 통합 모델링 언어(UML) 활동 모델과 (우측 상의) ELEMENT 패브릭 서비스 계층(202)의 토폴로지 상에 오버레이된 UML 객체 도면의 조합, 및 이러한 객체들을 호스팅하는 배치된 패브릭 네트워크이다. 도 3은 좌측 상의 동작들의 시퀀스, 및 우측 상의 패브릭에서, 관계형 데이터 관리 및 구성 시스템(100)에서 새로운 데이터베이스를 생성할지를 시스템에 문의하는 동안 그리고 그 직후에 존재하는 관련 데이터를 예시한다. 데이터베이스를 생성하는 것은 패브릭의 채널(분산형 원장 데이터 분리) 생성 메커니즘에 부가된 기능성을 더한 것을 이용한다.
도 3의 좌측 절반 상의 블록들은 데이터베이스 생성과 관련된 구성요소들, 즉, 패브릭 서비스(202) 및 패브릭 피어(214)이다. 데이터베이스 생성 요청을 처음에 처리할 때, 서비스 계층에 의해 3개의 데이터 객체가 생성된다. 도시된 바와 같이, 패브릭 채널 구성 파일 준비 활동(300)은 네트워크에 의해 사용하기 위한 《채널 구성 파일》channel.tx(302)를 생성한다. 제네시스 블록을 갖는 구성 트랜잭션 생성 활동(304)은, 제네시스 블록을 포함하고 채널을 개시하는 특수 패브릭 트랜잭션 《패브릭 구성 tx》(306)를 생성한다. 제네시스 블록은, 분산형 원장에 기록될 제안된 제1 데이터 조각이며, 이는 그의 초기 구성을 포함한다. <database_name>.block은 제네시스 블록 그 자체이다. 그것과 채널 둘 모두에는 관계형 데이터 관리 및 구성 시스템(100)의 데이터베이스의 이름과 일관된 이름들이 주어진다. 채널 생성 및 채널에 대한 권한부여된 피어 노드들의 참가 활동(308)은, 《패브릭 구성 tx》(306)로부터 채널 구성 데이터(310)를 생성한다. 채널 생성 및 채널에 대한 권한부여된 피어 노드들의 참가 활동(308)은 또한, 제네시스 블록(314) 및 대응하는 비어 있는 전역 상태 데이터베이스(322)를 포함하는 원장(313)을 생성한다. 관계형 데이터 관리 및 구성 시스템(100)의 데이터베이스의 속성들의 데이터 표현들을 포함하는 패브릭 트랜잭션 준비 활동(312)은, 관계형 스키마를 표현하는 JSON 객체 및 관계형 데이터 관리 및 구성 시스템(100)의 이 데이터베이스에 저장될 데이터를 통제할 다른 속성들을 포함하는 패브릭 분산형 원장 트랜잭션 《패브릭 tx》(316)를 생성한다. 초기 데이터베이스 스키마를 갖는 패브릭 트랜잭션 제출(318)은 패브릭 분산형 원장 트랜잭션 《패브릭 tx》(316)를 패브릭 블록(320)에 통합한다. 마지막으로, 패브릭 피어(214)는 324에서 관계형 데이터 관리 및 구성 시스템(100)의 데이터베이스의 속성들로 전역 상태 데이터베이스(322)를 자동으로 업데이트한다.
채널들은 패브릭 분산형 원장 네트워크에서 데이터가 공유되는 경계들이다. 영역(326) 외부의 피어 노드는 스키마 정보 또는 데이터를 수신하지 않는다. 노드들 사이의 네트워크 연결들이 또한 도시된다. 그 연결들은 패브릭 노드들 사이의 통상적인 상호연결들에 더하여 HTTPS 경로(328)를 포함하며, 이를 통해, 패브릭 서비스 계층 내의 패브릭 SDK 라이브러리(도시되지 않음)가 피어 노드와 접촉한다. 패브릭 SDK는 하이퍼레저® 패브릭에 의해 공급되는 구성요소이며, 클라이언트 프로그램들이 패브릭 플랫폼 상에서 기본 분산형 원장 동작들을 개시할 수 있게 하는 관계형 데이터 관리 및 구성 시스템(100)의 패브릭 서비스 내의 종속된 것으로 포함된다는 것이 유의된다.
채널들이 생성되고 패브릭 네트워크에서 트랜잭션들이 처리되는 전체 프로세스는 모델링되지 않지만, 위의 객체들은 그러한 단계들 동안 네트워크에 통신되고, 나머지 객체들은 생성된다. 먼저, 채널이 생성될 때, 그 프로세스에 대해 패브릭에서 다음과 같은 통상적인 3개의 항목이 획득된다:
1. config.tx로부터의 채널 구성- 순서화 서비스는, 다른 것들 중에서도, 채널 데이터가 참여 노드들로 제한되는 것을 보장하기 위해 그를 사용하는 채널 구성 파일로부터의 정보를 보유한다.
2. 《원장》<database_name> - 채널/데이터베이스에 대한 첨부-전용 데이터 저장소가 생성되고 모든 각각의 참여 피어 노드에 복제된다.
3. 《전역 상태》<database_name> - 원장 내의 각각의 항목에 대한 최신 값만을 포함하는 원장에 대한 컴패니언 저장소가 훨씬 더 효율적으로 질의되는 형태로 제공된다. 관계형 데이터 관리 및 구성 시스템(100)에서, 이러한 데이터베이스는 패브릭에 대한 표준 선택들 중 하나인 카우치DB® 인스턴스일 수 있다.
채널이 생성된 후에, 데이터베이스 스키마(관계형 데이터 속성들)의 JSON 표현을 포함하는 통상적인 패브릭 트랜잭션이 처리된다.
후속 관계형 데이터베이스 동작들은 (원장에 커밋하는 것이 명시적으로 배제된 판독 질의들을 제외한) 추가로 첨부된 패브릭 트랜잭션에서 JSON 객체로서 표현된다. 도 4는 DML 기입 동작들의 실행을 예시한다. 이러한 프로세스는 JSON 관계형 데이터 객체들을 생성하며, 그 객체들은, 일단 전역 상태 데이터베이스로 가져와지면, 질의들 및 다른 요청들에 응답하기 위해 관계형 데이터 계층(100)의 시스템 체인코드에 의해 사용될 수 있다. 도 5는 이것을, 언어 특정 SDK(102) 및 ELEMENT API(104)를 통해 ELEMENT UI(106)에 의해 또는 사용자의 애플리케이션에 의해 요청된 DML 판독 질의들의 실행을 도시하여 나타낸다.
도 4는 관계형 데이터 관리 및 구성 시스템(100)의 기존 데이터베이스에 관계형 데이터를 기입하기 위한 동작을 예시하는 블록도이다. 좌측 상의 수영장 레인 모양들은 2개의 참여 구성요소, 즉, 관계형 데이터 관리 및 구성 시스템(100)의 패브릭서비스 및 시스템 체인코드를 표현한다. 각각의 수영장 레인 모양 내부에서의 UML 활동들은 그들이 수행하는 주요 활동들을 표현한다. 굵은 화살표들은 활동들을 순서대로 연결하고, 부가적인 화살표들은 활동에 의해 영향을 받는 데이터 객체에 연결된다.
업데이트 동작을 살펴보면, 정의된 채널에서의 패브릭 피어 노드(402) 내의 《원장》<database_name> 객체(400)는 각각의 피어 노드에서 복제될 수 있는 도 3에서 생성된 동일한 원장이다. 관계형 데이터베이스 동작을 특정하는《패브릭 트랜잭션》(406)을 포함하는 부가적인《패브릭 블록》(404)이 그 안에 첨부되었다. 이러한 특정 동작은 《패브릭 tx》를 생성하는 원하는 동작을 포함하는 패브릭 트랜잭션의 준비(408)를 포함하는 상류 프로세스에서 사용자로부터 수신되었을 것이고, 도 4의 좌측 절반 상에 위치된 활동 부분 아래에 예시된 바와 같이, 414에서의 트랜잭션의 실행 및 결과적인 데이터의 생성을 위해, 412에서, 동작을 포함하는 패브릭 트랜잭션을 피어 노드에 제출한다. 트랜잭션은 또한 트랜잭션이 블록으로 처리되었을 때 관계형 데이터 관리 및 구성 시스템(100)의 시스템 체인코드에 의해 실행되었을 그 동작의 결과들을 포함한다. 일부 경우들에서, 이러한 실행은 또한 체인코드가 전역 상태 데이터베이스로부터 데이터를 판독하는 것을 수반할 것이다. 이러한 흐름은 도시되진 않지만 도 5의 DML 판독 동작으로부터 이해될 수 있다.
결과적인 ELEMENT 관계형 데이터 JSON(416)은 새로운 또는 변경된 테이블들, 기록들, 사용자들, 및 데이터베이스 속성들을 표현하는 객체를 포함한다. 이들 각각은 영향을 받은 데이터를 식별하는 고유 키를 갖는다. 패브릭 네트워크는, 418에서, 트랜잭션 및 결과적인 데이터를 패브릭 블록으로 처리하고, 패브릭 블록을 원장(400)에 첨부한다. 트랜잭션의 일부로서 원장(400)에 영구적으로 기록되는 것에 부가하여, 시스템 체인코드는, 422에서, 현재 관계형 데이터로 전역 상태 데이터베이스(420)를 업데이트하고, 여기서, 데이터는 도 3에서 생성된 것과 동일한 전역 상태 데이터베이스인 《전역 상태》 데이터베이스(420)로 공급된다. 거기서, 동일한 키를 갖는 더 오래된 엔트리들이 관계형 데이터로 덮어 쓰여지며, 전역 상태 데이터베이스는 관계형 데이터 관리 및 구성 시스템(100)의 데이터베이스의 현재 상태만을 포함하는 반면, 원장(400)은 그 이력을 보존한다. 하나의 그러한 객체(424)가 전역 상태 데이터베이스(420) 내에 도시되어 있지만, 실제로는, 많은 키들 및 객체들이 존재할 것이다.
도 5는 도 4와 유사한 전제를 가지며, 모든 구성요소 및 데이터 객체들은 변경되지 않은 채 유지된다. 유일한 차이는, DML 판독 동작을 처리하는 동안 데이터 객체들이 거치는 활동들 및 프로세스들이라는 것이다. 패브릭 서비스 구성요소에서의 활동 부분은 DML 판독 동작이 성공적으로 실행된 후에 500에서 서비스 계층이 질의 응답을 수신한다는 것을 제외하고는, 도 4와 상당히 유사하다.
본보기 실시예들에서, 시스템 체인코드는, 502에서, 전역 상태 데이터베이스 인스턴스(504)에 대한 질의를 실행하며, 그에 대한 반환으로, 관련 ELEMENT 데이터 JSON이 공급된다. 시스템 체인코드는 추가로, 이러한 데이터를 추가로 처리하여, 질의의 개시자에게 되돌아갈 질의 결과(500)를 생성한다. 판독은 전역 상태 데이터에 대해 발생하므로, 후속하여, 업데이트 시나리오와 같은, 전역 상태에 대해 이루어진 어떠한 수정들도 존재하지 않는다. DML 판독은 피어 원장(400)에 액세스하지 않는다. 그러나, 패브릭 트랜잭션은, 기본 "OPSTAT" 옵션이 오버라이딩되지 않는 한, 동작의 기록을 유지하기 위해 트랜잭션이 수행되는 피어 노드의 원장에 로그처리된다. 506에서, "OPSTAT" 옵션이 선택된 경우, 패브릭 네트워크는 트랜잭션을 블록으로 처리하고 블록을 원장(400)에 첨부한다. 건의(memorialize)된 트랜잭션은, 결과적인 기록들이 아니라 질의를 나타내는 JSON인 입력을 포함한다.
사용자 체인코드(스마트 계약들)로부터 개시되는 DML 판독 동작들은, 질의 결과가 그의 추가적인 처리를 위해 스마트 계약으로 직접 반환된다는 것을 제외하고는, 도 5와 유사하게 동작한다.
5개의 요구되는 데이터베이스 액세스 허가 수준을 실현하기 위해, 2개의 패브릭 메커니즘이 재사용된다. 첫째, 데이터베이스 생성이 패브릭 채널들을 생성하는 전제조건 능력을 요구하므로, 패브릭 네트워크 관리자만이 그 허가에 자격이 있다. 나머지 4개의 액세스 수준에 대해, ELEMENT 패브릭은 패브릭의 기존 신원 제공자 기능성 위에 피기백(piggyback)한다. 패브릭 상에서의 ELEMENT 패브릭 관계형 데이터 액세스 제어 실현은 그에 따라, 모든 각각의 사용자에게 그를 신원 제공자에게 등록하는 동안 첨부되는 데이터베이스 특정 속성들을 수반한다. 또한, 사용자의 등록에 붙여진 속성들은 그 데이터베이스에 대한 사용자의 특정 액세스에 관한 것이다. 후속하여, 데이터베이스 메타데이터에 사용자를 추가하기 위해 ELEMENT 시스템 체인코드에 대한 트랜잭션이 개시될 수 있다.
도 6은 최고 관리자 수준 미만의 액세스에 대한 사용자들의 추가를 위한 관계형 데이터 액세스 제어의 제1 부분에서 수반되는 구성요소들 및 데이터를 예시하는 블록도이다. 제어 프로세스는 2개의 단계를 수반한다. 첫 번째는, 사용자 추가 동작(602)을 생성하기 위해, 600에서, 사용자 추가 동작을 건의하는 패브릭 트랜잭션을 준비함으로써, 패브릭 인증 기관과 같은 신원 제공자에 데이터베이스 특정 속성들을 갖는 사용자를 등록하는 것이다. 두 번째는, 608에서, 요청 엔티티의 권한을 사용하여 새로운 사용자 액세스 수준의 JSON 표현(604)을 신원 제공자(606)의 사용자 신원 카드에 첨부함으로써 데이터베이스 그 자체에 사용자를 추가하는 정규 트랜잭션이다.
도 3과 같이, 도 6은 실행 중인 ELEMENT 패브릭 서비스 계층 및 관련 패브릭 네트워크의 토폴로지에 덮어 씌어진 UML 객체 모델이다. UML 객체는, 관계형 데이터 관리 및 구성 시스템(100)에 사용자를 추가하기 위한, 모델의 좌측 부분 상의 언급된 패브릭 서비스 구성요소 및 관련된 순차적 활동들 및 우측 상의 연관된 데이터의 표현을 모델링한다. 도 3으로부터의 모델 설명들 및 동작 전제들은, 여기서, 패브릭 인증 기관 노드(606)와 같은 신원 제공자에 대한 주목할 만한 부가와 함께 적용되지만, 영향을 받은 부분들만이 모델에 표시된다. UML 모델은 서비스 계층, 패브릭 피어 노드, 및 순서화 서비스 노드들과 연결되어, 분산형 원장 신원들에 관한 정보를 그들에 서빙한다. 순서화 서비스 및 그 연결들은, 그들이, 패브릭 트랜잭션 처리에서 일반적인 것을 넘어서는 어떠한 특별한 역할도 이 프로세스에서 갖지 않기 때문에 이 모델에서 도시되지 않는다. 순서화 서비스 노드 및 신원 제공자(예컨대, 인증 기관)는 동시에 관계형 데이터 관리 및 구성 시스템(100)의 다른 피어 노드들, 채널들, 및 아마도 데이터베이스들을 서빙할 가능성이 있다는 것이 유의된다.
도 6의 데이터 객체들은 하나의 ELEMENT 데이터베이스에 대한 새로운 사용자의 추가 동안 생성된다. 사용자의 추가는, 데이터베이스 그 자체가 패브릭 채널 및 그의 원장 상에 구축되는 방식과 유사하게, 패브릭의 기존 신원 관리 위에 구축된다. 실제로, 가장 높은 수준의 액세스인 최고 관리자는 패브릭의 관리자 역할의 정확한 재사용이다. 도 6은 4개의 더 낮은 ELEMENT 액세스 수준 중 하나를 갖는 사용자를 추가하는 것에 관한 것이다. 모델은 프로세스에서의 그들의 관여의 대략적인 순서로 3개의 부분으로 분할될 수 있다:
1. ELEMENT 패브릭 서비스 계층 노드
2. 신원 제공자 노드, 예컨대, 인증서 제공자(CA)
3. ELEMENT 패브릭 피어 노드들 및 순서화 서비스 노드들
프로세스의 초기 부분은 이들 중 처음 2개를 수반한다: ELEMENT 패브릭 서비스 계층은, 신원 제공자(예컨대, 패브릭 인증 기관(606))가 사용자 신원을 등록하거나 또는 사용자 신원이 이미 존재하는 경우 관련 신원을 찾고, 그 신원에 ELEMENT 특권 속성들을 부가하는 것을 준비한다. 다수의 신원 제공자 노드들이 주어진 채널 및 그의 ELEMENT 데이터베이스를 지원하고 있을 수 있는 것이 가능하지만 도시되진 않는다는 것을 유의한다. 이러한 경우에서, 프로세스는 어느 권한이 수반되는지를 특정하는 것을 제외하고는 본질적으로 동일하다.
《사용자》 객체(604)는, 때때로 "신원 카드"로 지칭되는, 신원 제공자(예컨대, 인증 기관(606))에서의 그 신원의 표현이다. 그것은 맞춤 속성들로 확장가능하고, 관계 데이터 관리 및 구성 시스템(100)은 신원의 액세스 특권 수준을 표현하는 속성을 ELEMENT 데이터베이스에 부가함으로써 이를 활용한다. 속성은 모델에서 JSON 객체 라벨링된 사용자 액세스 수준 속성들(604)의 형태를 취한다.
프로세스의 다른 부분은 액세스 수준 변경을 분산형 원장(612)에 로그처리하는 대응하는 패브릭 트랜잭션(610)이다. 이러한 트랜잭션(610)은, 서비스 계층(사용자 추가 동작 JSON을 포함하는 《패브릭 tx》(614))에서 준비되고, 616에서, 먼저 하나의 피어 노드를 통해, 그런 다음 순서화 서비스로, 마지막으로 원장(612)에 첨부된 블록의 일부로서 모든 피어 노드들로 다시 원장(612)을 전달하는 프로세스에서 《원장》(612)에 부가된다.
원장(612)은 도 3 내지 도 5에 예시된 것과 동일하다. 모델은 사용자 추가 동작 JSON(614)을 포함하는 새로운 《패브릭 블록》에 초점을 맞추지만, 그 블록(614)은 실제로 도 3의 제네시스 및 구성 블록들(이 모델에서 제외됨) 및 도 4 및 도 5에 예시된 바와 같은 관계형 동작들을 위한 임의의 수의 블록들 후에 첨부될 것이다.
사용자 액세스 수준들이 정의된 후에, 분산형 원장 특정 구성요소들은 각각의 관계형 데이터베이스 동작 동안 그를 판독하여 동작이 권한을 부여받은지를 결정한다. 관계형 데이터베이스 동작들은 2개의 단계로 발생한다. 신원은 신원 제공자에 의해 검증되고, 액세스 수준이 확인된다. 호출한 사용자 액세스 수준이 그 기능을 호출하는 데 적절한 것으로 밝혀지는 경우에만 대응하는 기능에 대한 액세스가 승인되며, 이에 후속하여, 도 3과 관련하여 위에 설명된 바와 같이 실제 기능이 실행된다.
사용자 스마트 계약들과의 요구되는 통합을 달성하는 것은 패브릭 실현에서 간단하다. 사용자 체인코드는 ELEMENT 시스템 체인코드를 직접 호출할 수 있으며, 이는 벌크 동작들을 제외한 모든 DML 특징들에 대한 액세스를 제공한다.
그러나, 기본 패브릭 설정은 시스템 체인코드 플러그인들을 허용하지 않는다. 주요 변경은, ELEMENT 시스템 체인코드가 배치될 수 있게 하는 구축 태그로 패브릭 피어를 재구축하는 것을 수반한다. 그 후, 피어의 기본 구성 파일은 컴파일된 ELEMENT 시스템 체인코드 바이너리로의 경로에서의 수정을 요구한다. 이는, 패브릭 피어(들)가 재시작 시에 ELEMENT 시스템 체인코드를 판독하고 시작할 수 있게 한다.
패브릭 특정 서비스 계층은, 공통 콘솔/파서/API 구성요소로부터 데이터베이스 명령들을 수락하고, 그 명령들을, 전술된 바와 같이, ELEMENT 시스템 체인코드, 패브릭 인증 기관과 같은 신원 제공자, 및 전역 상태 데이터베이스의 조합을 호출함으로써 동작으로 변환한다.
ELEMENT Node.js® SDK는 주로, 개발자의 Node.js® 애플리케이션으로부터 공통 콘솔/파서/API 구성요소를 호출하기 위한 래퍼(wrapper) 함수들을 포함한다. 구체적으로, ELEMENT Node.js® SDK는 관계형 데이터 관리 및 구성 시스템(100)과의 연결을 생성하고, 테이블들 및 인덱스들을 정의하기 위해 DDL 동작들을 수행하고, 데이터 기입 및 질의를 위해 DML 동작들을 수행하고, 맞춤 스마트 계약을 채널에 부가하기 위한 래퍼 기능들을 제공한다.
도 7은 본보기 실시예들의, 사용자 애플리케이션 노드(700)로서 모델링되는, ELEMENT 패브릭-Node.js® SDK와 사용자의 애플리케이션(702)의 상호작용 및 그들 둘 모두가 호스팅되는 실행 환경을 예시하는 블록도이다. 이러한 노드(700)는 Node.js®에 대한 요구되는 지원 및 도시된 바와 같이 그의 REST ELEMENT API(104)를 통해 ELEMENT 콘솔(108)의 실행 인스턴스와 HTTPS를 통해 통신하도록 구성되는 능력에 의해 제약되는 광범위한 잠재적인 구현들을 커버한다.
도 7의 사용자 애플리케이션 노드(700)로 드릴 다운(drill down)하면, Node.js®의 사용자 애플리케이션(702)은, 또한 설치되는 패브릭/Node.js® ELEMENT SDK(704)에 대한 종속성을 갖는 구성요소로서 모델링된다. Node.js® 래퍼 함수 인터페이스들(706)은 사용자의 애플리케이션 코드(702)가 직접 이용가능한 기능들을 정의한다. 이러한 인터페이스들(706)은 일반적으로 도 1과 관련하여 설명된 언어 특정 SDK 《규격》(102)을 준수한다. 그러나, 이들은 몇몇 방식들로 규격을 넘어서서, 일부 부가적인 패브릭 특정 특징들을 지원한다. 이는, SDK의 이름에 "패브릭"을 포함시킴으로써 모델링에 반영된다. ELEMENT_SDK(704)의 코드는 그러한 인터페이스를 구현하여, SDK 기능 호출들을 ELEMENT API(104)에 대한 호출들로 변환한다.
ELEMENT 규격들에 의해 요구되는 기능들을 넘어서, 패브릭/Node.js® 실현은 또한, ELEMENTDB 콘솔(108) 또는 언어 특정 SDK(102)를 통해 스마트 계약들(사용자 체인코드)을 배치하고 생성된 데이터베이스들 사이에 (물리적 대 논리적 의미에서) 물리적 분리를 유지하는 능력들을 포함한다.
패브릭/Node.js® 실시예는, 패브릭 플랫폼의 내장된 특성들의 재사용을 최대화하는 패브릭 상의 관계형 데이터 구현뿐만 아니라 데이터베이스들 사이의 물리적 분리를 갖는 분산형 원장 상의 관계형 데이터를 제공하며, 그에 따라, 성능이 개선되고 플랫폼 변경들이 변경들의 단절을 도입할 가능성이 감소된다는 것이 인식될 것이다. 프로그래머 친화적 SDK는 또한, 분산형 원장 상의 관계형 데이터의 구조화를, 그 데이터를 사용하는 스마트 계약의 배치와 통합한다.
전체 ANSI SQL 언어 규격은 지원되지 않으며, 그 자체로는 저장된 절차들도 아니라는 것이 관련 기술분야의 통상의 기술자들에 의해 인식될 것이다. 그러나, 사용자 체인코드는 요구되는 경우 논리 및 관계형 데이터를 결합하는 유사한 능력을 제공한다. 예로서, 도 8 및 도 9는 SQL DML 기입 및 판독 동작들을 구현하기 위한 관계형 데이터 관리 및 구성 시스템(100)의 사용을 예시한다. 관련 기술분야의 통상의 기술자들은, 본원에 설명된 기법들이 또한, 본원에 설명된 바와 같은 분산형 원장 상에 구현되는 데이터베이스들에 저장된 데이터와의 상호작용을 위한 다른 SQL 활동들을 구현하는데 사용될 수 있다는 것을 인식할 것이다.
도 8은 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템을 사용하는 분산형 원장에 대한 성공적인 SQL DML 기입 동작의 예의 논리 흐름도이다. 예시된 바와 같이, SQL 질의는 적어도 3가지 방식으로 관계형 데이터 관리 및 구성 시스템(100)에 의해 수신될 수 있는데, 즉, 800에서, 사용자가 SQL 질의를 ELEMENT UI(106)에 입력할 수 있고; 802에서, 사용자 애플리케이션이 ELEMENT SDK(200)를 통해 SQL 질의를 전달할 수 있고; 804에서, 또는 스마트 계약이 SQL 질의를 실행할 수 있다. 806에서, 수신된 SQL 질의가 DML 기입 동작으로 파싱된다. 이어서, 808에서, 관계형 데이터 관리 및 구성 시스템(100)은 SQL 동작의 JSON 표현을 생성하고 임의의 포함된 관계형 데이터의 JSON 표현들을 통합한다. 이어서, JSON 표현(ELEMENT SQL)은 분산형 원장의 신원, 프라이버시, 및 합의 조항들을 보존하는 패브릭/Node.js® 동작들에 의해 처리된다. 그러한 동작들은, 810에서, 호출 신원이 적어도 DML 기입 권한을 갖는다는 것을 확인하는 것을 포함한다. 이어서, 관계형 데이터 관리 및 구성 시스템(100)은, 812에서, 관계형 동작을 실행하는 데 요구되는 바와 같은 데이터를 분산형 원장 플랫폼으로부터 검색하고, 814에서, 동작을 실행하고 결과적인 새로운 또는 변경된 기록들의 JSON 표현들을 준비한다. 동작 및 업데이트된 기록들은, 임의의 변경들의 기록들을 보존하기 위해, 816에서, 분산형 원장 플랫폼에 적절한 형태로 분산형 원장 플랫폼에 커밋된다. 이어서, 818에서, 분산형 원장 플랫폼은 동작 및 데이터를 자신의 분산형 원장에 통합한다. 또한, 요청되는 경우, 820에서, 관계형 데이터 관리 및 구성 시스템(100)은 분산형 원장에 의한 수락으로의 동작의 진행에 대해 분산형 원장 네트워크를 모니터링한다. 마지막으로, 822에서, 관계형 데이터 관리 및 구성 시스템(100)은, 동작의 성공을 호출자(UI(106), 사용자 애플리케이션(200), 또는 사용자 스마트 계약)에게 통보한다. 이러한 프로세스는 각각의 새로운 SQL DML 기입 동작에 대해 반복될 수 있다.
다른 한편으로는, 도 9는 본보기 실시예들의, 관계형 데이터 관리 및 구성 시스템(100)을 사용하는 분산형 원장으로부터의 성공적인 SQL DML 판독 동작의 예의 논리 흐름도이다. 예시된 바와 같이, SQL 질의는 적어도 3가지 방식으로 관계형 데이터 관리 및 구성 시스템(100)에 의해 수신될 수 있는데, 즉, 900에서, 사용자가 SQL 질의를 ELEMENT UI(106)에 입력할 수 있고; 902에서, 사용자 애플리케이션이 ELEMENT SDK(200)를 통해 SQL 질의를 전달할 수 있고; 904에서, 또는 스마트 계약이 SQL 질의를 실행할 수 있다. 906에서, 수신된 SQL 질의가 DML 판독 동작으로 파싱된다. 이어서, 908에서, 관계형 데이터 관리 및 구성 시스템(100)은 SQL 동작의 JSON 표현을 생성한다. 이어서, JSON 표현(ELEMENT SQL)은 분산형 원장의 신원, 프라이버시, 및 합의 조항들을 보존하는 패브릭/Node.js® 동작들에 의해 처리된다. 그러한 동작들은, 910에서, 호출 신원이 적어도 DML 판독 권한을 갖는다는 것을 확인하는 것을 포함한다. 이어서, 관계형 데이터 관리 및 구성 시스템(100)은, 912에서, 판독 동작을 실행하는 데 요구되는 바와 같은 데이터를 분산형 원장 플랫폼으로부터 검색하고, 914에서, 요청된 동작을 실행하고 질의 결과의 JSON 표현들을 생성한다. 의도적으로 억제되지 않는 한, 관계형 데이터 관리 및 구성 시스템(100)은, 기록들을 보존하기 위해, 916에서, 분산형 원장 플랫폼에 적절한 형태로 분산형 원장 플랫폼에 동작의 JSON 표현을 로그처리한다. 이어서, 918에서, 분산형 원장 플랫폼은 동작의 로그를 자신의 분산형 원장에 통합한다. 마지막으로, 920에서, 관계형 데이터 관리 및 구성 시스템(100)은, 질의 결과의 JSON 표현을 호출자(UI(106), 사용자 애플리케이션(200), 또는 사용자 스마트 계약)에게 반환한다. 이러한 프로세스는 각각의 새로운 SQL DML 판독 동작에 대해 반복될 수 있다.
도 10은 패브릭 실현에서의 데이터 정의 언어(DDL) 기입들의 성공적인 실행을 예시하는 블록도이다. 그러한 동작들은 기존의 관계형 데이터 관리 및 구성 시스템 데이터베이스의 스키마를 수정하거나 확장한다. 도면의 좌측 부분의 수영장 레인 모양들은 DDL 동작들을 담당하는 구성요소들을 표현한다. 각각의 레인 내의 활동들은 표기된 구성요소에 특정적이고, 프로세스에 대한 구성요소의 가능한 기여를 설명한다. 이전 도면들과 같이, 프로세스의 흐름은 인과적으로 연결될 수 있는 단계들 사이에서 굵은 화살표들로 표시된다. 부가적으로, 통상의 화살표들은 활동들을 그들이 생성하거나 수정할 수 있는 데이터 객체들에 연결하며, 이는, 우측 상의 객체 모델(데이터로 표시됨)에 도시된다.
DML 기입 동작들은 ELEMENTDB_Console(108)에 의해 식별되고 처리될 수 있다. 예컨대, 1000에서, ELEMENTDB_Console(108)은 SQL 명령을 수신하고 이를 DDL로서 식별할 수 있다. SQL 명령의 처리는, 1002에서, 동작의 SQL 설명을 분산형 원장 플랫폼 상에서 처리되고 표현될 수 있는 형태로 변환하기 위해 ELEMENT SQL DDL 파서(110)에 의해 파싱하는 것을 포함할 수 있다. 변환된 형태는 추가로, 1004에서, 패브릭서비스 구성요소에 의해, 배치된 패브릭 서비스 계층 내에 데이터로서 존재할 수 있는 데이터베이스 속성들(스키마)의 업데이트된 JSON 표현을 포함하는 원하는 동작(1005)을 포함하는 패브릭 트랜잭션으로 처리될 수 있다. 패브릭서비스 구성요소는 또한, 1006에서, 관계형 데이터 관리 및 구성 시스템 데이터베이스와 연관된 채널에서 패브릭 피어 노드에 네트워크 연결을 통해 결과적인 패브릭 트랜잭션이 제출되게 할 수 있다. 이어서, 패브릭 네트워크에 의한 정상적인 처리는 그 트랜잭션을 블록에 통합하고 그 블록을 그 채널에 대한 원장(1020) 내의 이전의 것들(1007)에 첨부할 것이다. 그러한 첨부에서 암시하는 것은, 블록이 채널 내의 다른 피어 노드들에 동일하게 첨부될 것이라는 것이다. 변경된 관계형 데이터 속성들이 조각 키-값 쌍 분산형 원장 데이터로서 표현될 수 있기 때문에, 1008에서, 패브릭의 시스템 체인코드는 후속하여, 이러한 더 최근의 관계형 데이터베이스 속성들로 동일한 키 하에 저장되었을 이전 속성들을 덮어 쓰기하기 위해, 전역 상태 데이터베이스 엔트리를 후속하여 업데이트할 수 있다. DDL 동작에 의해 표시되는 인덱스 변경들이 존재하는 경우들에서, 관계형 관리 및 구성 시스템은, 1010에서, 전역 상태 데이터베이스의 인덱싱, 예컨대, 카우치DB® 인스턴스의 인덱스 집합(1030)의 직접 수정에 의해 실제로 그들에 영향을 줄 수 있다. 인덱스 집합(1030)은, 동작이 실행되고 있는 관계형 데이터 관리 및 구성 시스템 데이터베이스에 대해 정의된 인덱스들을 포함한다. 이러한 변경들은 패브릭서비스에 의해 요청되고, 전역 상태 데이터베이스의 인덱싱 구현에 의해 수신되며, 후속하여, 1012에서, 《전역 상태》 데이터베이스에 적용되어, 업데이트된 인덱싱이, 전역 상태 데이터베이스를 수반하는 후속 질의 동작들에 적용되게 할 수 있다.
컴퓨터 실시예
도 11은 본원에 개시된 관계형 데이터 관리 및 구성 시스템(100)의 하나 이상의 실시예를 구현하기에 적합한 특수 목적 컴퓨터로 프로그래밍될 수 있는 전형적인 범용 컴퓨터(1100)의 블록도이다. 위에 설명된 관계형 데이터 관리 및 구성 시스템(100)은, 임의의 범용 처리 구성요소, 이를테면, 자신 상에 배치되는 필요한 작업부하를 처리하기 위한 충분한 처리 능력, 메모리 리소스들, 및 통신 처리량 능력을 갖는 컴퓨터 상에서 구현될 수 있다. 컴퓨터(1100)는, 보조 저장소(1104), 판독 전용 메모리(ROM)(1106), 랜덤 액세스 메모리(RAM)(1108)를 포함하는 메모리 디바이스들, 입력/출력(I/O) 디바이스들(1110), 및 네트워크 연결성 디바이스들(1112)과 통신하는 프로세서(1102)(중앙 프로세서 유닛 또는 CPU로 지칭될 수 있음)를 포함한다. 프로세서(1102)는 하나 이상의 CPU 칩으로서 구현될 수 있거나 하나 이상의 주문형 집적 회로(ASIC)의 일부일 수 있다.
보조 저장소(1104)는 전형적으로 하나 이상의 디스크 드라이브 또는 테이프 드라이브로 구성되고, 데이터의 비-휘발성 저장을 위해, 그리고 RAM(1108)이 모든 작업 데이터를 보유하기에 충분히 크지 않은 경우 오버-플로우 데이터 저장 디바이스로서 사용된다. 보조 저장소(1104)는 프로그램들을 저장하는 데 사용될 수 있으며, 그러한 프로그램들은, 실행을 위해 선택될 때 RAM(1108)에 로딩된다. ROM(1106)은 프로그램 실행 동안 판독되는 명령어들 및 아마도 데이터를 저장하는 데 사용된다. ROM(1106)은 전형적으로 보조 저장소(1104)의 더 큰 메모리 능력에 비해 작은 메모리 능력을 갖는 비-휘발성 메모리 디바이스이다. RAM(1108)은 휘발성 데이터를 저장하는 데 그리고 아마도 명령어들을 저장하는 데 사용된다. ROM(1106) 및 RAM(1108) 둘 모두에 대한 액세스는 전형적으로 보조 저장소(1104)에 대한 것보다 더 빠르다.
본원에 설명된 디바이스들은 컴퓨터 판독가능 명령어들을 저장하는 컴퓨터 판독가능 비-일시적 매체 및 메모리에 결합되는 하나 이상의 프로세서를 포함하도록 구성될 수 있으며, 컴퓨터 판독가능 명령어들을 실행할 때, 도 1 내지 도 10를 참조하여 위에 설명된 방법 단계들 및 동작들을 수행하도록 컴퓨터(1100)를 구성한다. 컴퓨터 판독가능 비-일시적 매체는 자기 저장 매체, 광학 저장 매체, 플래시 매체 및 솔리드 스테이트 저장 매체를 포함하는 모든 유형들의 컴퓨터 판독가능 매체를 포함한다.
추가로, 본 개시내용의 단계들 중 임의의 하나 또는 전부를 참조하여 위에 설명된 바와 같은 처리 및 동작들을 용이하게 하는 하나 이상의 컴퓨터 실행가능 명령어를 포함하는 소프트웨어가 본 개시내용에 부합하는 소비자 및/또는 생산자 도메인들 내의 하나 이상의 서버 및/또는 하나 이상의 라우터 및/또는 하나 이상의 디바이스에 설치되고 그와 함께 판매될 수 있다는 것이 이해되어야 한다. 대안적으로, 소프트웨어는, 예컨대, 소프트웨어 생성자가 소유한 서버로부터 또는 소프트웨어 생성자가 소유하지는 않지만 그에 의해 사용되는 서버로부터 획득하는 것을 비롯하여, 물리적 매체 또는 배포 시스템을 통해 소프트웨어를 획득하는 것을 포함하여, 본 개시내용에 부합하는 소비자 및/또는 생산자 도메인들 내의 하나 이상의 서버 및/또는 하나 이상의 라우터 및/또는 하나 이상의 디바이스에 획득되고 로딩될 수 있다. 소프트웨어는, 예컨대, 인터넷을 통한 배포를 위해 서버 상에 저장될 수 있다.
또한, 본 개시내용은, 본 개시내용의 적용이, 설명에서 기재되거나 도면들에 예시된 구성요소들의 구성 및 배열의 세부사항들로 제한되지 않는다는 것이 관련 기술분야의 통상의 기술자에 의해 이해될 것이다. 본원에서의 실시예들은 다른 실시예들이 가능하며, 다양한 방식들로 실시 또는 수행되는 것이 가능하다. 또한, 본원에서 사용되는 어법 및 용어는 설명의 목적을 위한 것이고, 제한적인 것으로 간주되지 않아야 한다는 것이 이해될 것이다. 본원에서 "구비", "포함, 또는 "갖는", 및 이들의 변형들의 사용은, 이후 열거되는 항목들 및 그들의 등가물들뿐만 아니라 부가적인 항목들을 포괄하는 것을 의미한다. 달리 제한되지 않는 한, 본원에서의 "연결", "결합", 및 "장착"이라는 용어들 및 이들의 변형들은 광범위하게 사용되며, 직접 및 간접 연결들, 결합들, 및 장착들을 포괄한다. 게다가, "연결" 및 "결합"이라는 용어들 및 이들의 변형들은 물리적 또는 기계적 연결들 또는 결합들로 제한되지 않는다. 추가로, 위, 아래, 최하부, 및 최상부와 같은 용어들은 상대적이고, 제한하는 것이 아니라 예시를 돕기 위해 이용된다.
예시된 실시예들에 따라 이용되는 예시적인 디바이스들, 시스템들 및 방법들의 구성요소들은, 적어도 부분적으로, 디지털 전자 회로, 아날로그 전자 회로, 또는 컴퓨터 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합들로 구현될 수 있다. 이러한 구성요소들은, 예컨대, 프로그래밍가능 프로세서, 컴퓨터, 또는 다수의 컴퓨터들과 같은 데이터 처리 장치에 의한 실행을 위해, 또는 그들의 동작을 제어하기 위해, 정보 캐리어, 또는 기계 판독가능 저장 디바이스에 유형적으로(tangibly) 구현된 컴퓨터 프로그램, 프로그램 코드 또는 컴퓨터 명령어들과 같은 컴퓨터 프로그램 제품으로서 구현될 수 있다.
컴퓨터 프로그램은, 컴파일 또는 해석되는 언어들을 포함하는 임의의 형태의 프로그래밍 언어로 작성될 수 있고, 이는 독립형 프로그램 또는 모듈, 컴포넌트, 서브루틴 또는 컴퓨팅 환경에서 사용하기에 적합한 다른 유닛을 포함하는 임의의 형태로 배포될 수 있다. 컴퓨터 프로그램은 하나의 위치에 있거나 다수의 위치들에 걸쳐 분산되어 통신 네트워크에 의해 상호연결되는 다수의 컴퓨터들 상에서 실행되거나 또는 하나의 컴퓨터 상에서 실행되도록 배치될 수 있다. 또한, 본원에 설명된 기법들을 달성하기 위한 기능 프로그램들, 코드들, 및 코드 세그먼트들은 관련 기술분야의 통상의 프로그래머들에 의해 본 개시내용의 범위 내에 있는 것으로서 용이하게 해석될 수 있다. 예시적인 실시예들과 연관된 방법 단계들은, (예컨대, 입력 데이터에 대해 동작하고/거나 출력을 생성함으로써) 기능들을 수행하기 위해 컴퓨터 프로그램, 코드 또는 명령어들을 실행하는 하나 이상의 프로그래밍가능 프로세서들에 의해 수행될 수 있다. 방법 단계들은 또한, 예컨대, 특수 목적 논리 회로, 예컨대, 필드 프로그래밍가능 게이트 어레이(FPGA) 또는 주문형 집적 회로(ASIC)에 의해 수행될 수 있고, 장치는 그들로서 구현될 수 있다.
본원에 개시된 실시예들과 관련하여 설명된 다양한 예시적인 논리 블록들, 모듈들 및 회로들은 범용 프로세서, 디지털 신호 프로세서(DSP), ASIC, FPGA 또는 다른 프로그래밍가능 논리 디바이스, 이산 게이트 또는 트랜지스터 논리, 이산 하드웨어 구성요소들, 또는 본원에 설명된 기능들을 수행하도록 설계된 이들의 임의의 조합으로 구현되거나 수행될 수 있다. 범용 프로세서는 마이크로프로세서일 수 있지만, 대안으로, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 기계일 수 있다. 프로세서는 또한 컴퓨팅 디바이스들의 조합, 예컨대, DSP와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 함께 결합된 하나 이상의 마이크로프로세서, 또는 임의의 다른 그러한 구성으로서 구현될 수 있다.
컴퓨터 프로그램의 실행에 적합한 프로세서들은, 예로서, 범용 및 특수 목적 마이크로프로세서들 둘 모두, 및 임의의 종류의 디지털 컴퓨터의 임의의 하나 이상의 프로세서를 포함한다. 일반적으로, 프로세서는 판독 전용 메모리 또는 랜덤 액세스 메모리 또는 이들 둘 모두로부터 명령어들 및 데이터를 수신할 것이다. 컴퓨터의 필수적인 요소들은 명령어들을 실행하기 위한 프로세서, 및 명령어들 및 데이터를 저장하기 위한 하나 이상의 메모리 디바이스이다. 일반적으로, 컴퓨터는 또한, 데이터를 저장하기 위한 하나 이상의 대용량 저장 디바이스, 예컨대, 자기, 자기 광학 디스크들, 또는 광학 디스크들을 포함하거나, 또는 이들로부터 데이터를 수신하기 위해 또는 이들에 데이터를 전달하기 위해, 또는 이 둘 모두를 수행하기 위해 동작가능하게 결합될 수 있다. 컴퓨터 프로그램 명령어들 및 데이터를 구현하기에 적합한 정보 캐리어들은, 예로서, 반도체 메모리 디바이스들, 예컨대, 전기적으로 프로그래밍가능한 판독 전용 메모리 또는 ROM(EPROM), 전기적으로 소거가능한 프로그래밍가능(EEPROM), 플래시 메모리 디바이스들, 및 데이터 저장 디스크들(예컨대, 자기 디스크들, 내부 하드 디스크들, 또는 착탈식 디스크들, 광자기 디스크들, 및 CD-ROM 및 DVD-ROM 디스크들)을 포함하는, 모든 형태들의 비-휘발성 메모리를 포함한다. 프로세서 및 메모리는 특수 목적 논리 회로에 의해 보충되거나, 그에 통합될 수 있다.
관련 기술분야의 통상의 기술자들은, 정보 및 신호들이 다양한 상이한 기술들 및 기법들 중 임의의 기술 및 기법을 사용하여 표현될 수 있다는 것을 이해한다. 예컨대, 위의 설명 전반에 걸쳐 참조될 수 있는 데이터, 명령어들, 명령들, 정보, 신호들, 비트들, 심볼들, 및 칩들은 전압들, 전류들, 전자기 파들, 자기장들 또는 자기 입자들, 광학 필드들 또는 광학 입자들, 또는 이들의 임의의 조합에 의해 표현될 수 있다.
관련 기술분야의 통상의 기술자들은 추가로, 본원에 개시된 실시예들과 관련하여 설명된 다양한 예시적인 논리 블록들, 모듈들, 회로들, 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이 둘의 조합들로서 구현될 수 있다는 것을 인식한다. 하드웨어와 소프트웨어의 이러한 상호교환가능성을 명확히 예시하기 위해, 다양한 예시적인 구성요소들, 블록들, 모듈들, 회로들, 및 단계들은 그들의 기능성의 관점에서 일반적으로 위에 설명되었다. 그러한 기능성이 하드웨어로서 구현되는지 또는 소프트웨어로서 구현되는지는 특정 애플리케이션 및 전체 시스템에 부과된 설계 제한들에 의존한다. 통상의 기술자들은, 설명된 기능성을 각각의 특정 애플리케이션에 대해 다양한 방식들로 구현할 수 있지만, 그러한 구현 결정들이 본 개시내용의 범위를 벗어나게 하는 것으로서 해석되어서는 안 된다. 소프트웨어 모듈은, 랜덤 액세스 메모리(RAM), 플래시 메모리, ROM, EPROM, EEPROM, 레지스터들, 하드디스크, 착탈식 디스크, CD-ROM, 또는 관련 기술분야에 알려져 있는 임의의 다른 형태의 저장 매체에 상주할 수 있다. 예시적인 저장 매체는 프로세서에 결합되고, 그러한 프로세서는 저장 매체로부터 정보를 판독하고, 저장 매체에 정보를 기입할 수 있다. 대안으로, 저장 매체는 프로세서에 통합될 수 있다. 다시 말해서, 프로세서 및 저장 매체는 통합된 회로에 상주하거나 별개의 구성요소들로서 구현될 수 있다.
본원에서 사용되는 바와 같이, "기계 판독가능 매체"는, 명령어들 및 데이터를 일시적으로 또는 영구적으로 저장할 수 있는 디바이스를 의미하고, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 버퍼 메모리, 플래시 메모리, 광학 매체, 자기 매체, 캐시 메모리, 다른 유형들의 저장소(예컨대, 소거가능한 프로그래밍가능 판독 전용 메모리(EEPROM)), 및/또는 이들의 임의의 적절한 조합을 포함할 수 있지만 이에 제한되지 않는다. "기계 판독가능 매체"라는 용어는, 프로세서 명령어들을 저장할 수 있는 단일 매체 또는 다수의 매체(예컨대, 중앙집중형 또는 분산형 데이터베이스, 또는 연관된 캐시들 및 서버들)를 포함하는 것으로 이해되어야 한다. "기계 판독가능 매체"라는 용어는 또한, 명령어들이, 하나 이상의 프로세서에 의해 실행될 때, 하나 이상의 프로세서로 하여금 본원에 설명된 방법론들 중 임의의 하나 이상을 수행하게 하도록, 하나 이상의 프로세서에 의한 실행을 위한 명령어들을 저장할 수 있는 임의의 매체 또는 다수의 매체의 조합을 포함하는 것으로 이해되어야 한다. 그에 따라서, "기계 판독가능 매체"는 단일 저장 장치 또는 디바이스뿐만 아니라, 다수의 저장 장치 또는 디바이스들을 포함하는 "클라우드 기반" 저장 시스템들 또는 저장 네트워크들을 지칭한다. 본원에서 사용되는 바와 같은 "기계 판독가능 매체"라는 용어는 신호들 그 자체는 배제한다.
위에 제시된 설명 및 도면들은 단지 예로서 의도되며, 첨부된 청구항들에 기재된 것을 제외하고는 어떠한 방식으로든 예시적인 실시예들을 제한하도록 의도되지 않는다. 위에 설명된 다양한 예시적인 실시예들의 다양한 요소들의 다양한 기술적 양상들은 다수의 다른 방식들로 조합될 수 있으며, 이들 모두는 본 개시내용의 범위 내에 있는 것으로 간주된다는 것이 유의된다.
그에 따라서, 예시적인 실시예들이 예시의 목적들을 위해 개시되었지만, 관련 기술분야의 통상의 기술자들은 다양한 수정들, 부가들, 및 치환들이 가능하다는 것을 인식할 것이다. 따라서, 본 개시내용은 위에 설명된 실시예들로 제한되지 않으며, 첨부된 청구항들의 등가물들의 전체 범위와 함께, 첨부된 청구항들의 범위 내에서 수정될 수 있다.
부록 A
하이퍼레저® 패브릭 개관
하이퍼레저® 패브릭 모델
포괄적이지만 맞춤화가능한 기업 분산형 원장 솔루션의 약속을 충족시키는 하이퍼레저® 패브릭으로 짜여지는 주요 설계 특징들은 다음을 포함한다:
● 자산들 ― 자산 정의들은, 네트워크를 통한, 전체 식품들로부터 골동품 차들 내지 화폐 선물들에 이르는 금전적 가치가 있는 거의 모든 것의 교환을 가능하게 한다.
● 체인코드 ― 체인코드 실행은 트랜잭션 순서화로부터 파티셔닝되어, 노드 유형들에 걸친 요구되는 신뢰 및 검증의 수준들을 제한하고, 네트워크 확장성 및 성능을 최적화한다.
● 원장 특징들 ― 변경불가능한 공유된 원장은 각각의 채널에 대한 전체 트랜잭션 이력을 인코딩하고, 효율적인 감사 및 분쟁 해결을 위한 SQL-유형 질의 능력을 포함한다.
● 프라이버시 ― 채널들 및 비공개 데이터 집합들은, 공통 네트워크 상에서 자산들을 교환하는 경쟁 비즈니스들 및 규제된 산업들에 의해 일반적으로 요구되는 비공개 및 기밀 다중-측방향 트랜잭션들을 가능하게 한다.
● 보안 & 멤버쉽 서비스 ― 허가된 멤버쉽은 신뢰되는 분산형 원장 네트워크를 제공하며, 여기서, 참여자들은, 모든 트랜잭션들이 권한부여된 규정자들 및 감사자들에 의해 검출되고 추적될 수 있다는 것을 알고 있다.
● 합의 ― 합의 대한 고유한 접근법은, 기업에 필요한 유연성 및 확장성을 가능하게 한다.
자산들
자산들은 유형적인 것(실면적(real estate) 및 하드웨어)으로부터 무형적(intangible)인 것(계약들 및 지적 재산)에 이르는 범위일 수 있다.
하이퍼레저® 패브릭은 체인코드 트랜잭션들을 사용하여 자산들을 수정하는 능력을 제공한다.
자산들은 키-값 쌍들의 집합으로서 하이퍼레저® 패브릭에서 표현되며, 상태 변경들은 채널 원장 상의 트랜잭션들로서 기록된다. 자산들은 바이너리 및/또는 JSON 형태로 표현될 수 있다.
자산들은 하이퍼레저 컴포저 툴을 사용하여 하이퍼레저® 패브릭 애플리케이션들에서 정의되고 사용될 수 있다.
체인코드
체인코드는 스마트 계약들에서의 자산 또는 자산들, 및 자산(들)을 수정하기 위한 트랜잭션 명령어들을 정의하는 소프트웨어이며; 다시 말해서, 체인코드는 비즈니스 논리이다. 체인코드는, 키-값 쌍들 또는 다른 상태 데이터베이스 정보를 판독 또는 변경하기 위한 규칙들을 시행한다. 체인코드 기능들은 원장의 현재 상태 데이터베이스에 대해 실행되고, 트랜잭션 제안을 통해 개시된다. 체인코드 실행은, 네트워크에 제출되어 모든 피어들 상의 원장에 적용될 수 있는 키-값 기입들의 세트(기입 세트)를 초래한다.
체인코드들에는 신원들이 전혀 없다. 체인코드는 다른 체인코드도 호출할 수 있지만, 트랜잭션 신원은 호출 체인 전체에 걸쳐 트랜잭션을 제출한 트랜잭션 서명자로서 항상 일정하게 유지된다. 따라서, 패브릭 네트워크 상에서, 기탁 계정을 설정하는 것은 외부 당사자를 추가하는 것을 수반한다. 결과적으로, 기탁을 담당하는 외부 계정은 나머지 참여자들에게 자신의 중립성을 증명해야 한다.
체인코드를 배치하는 것은 2단계 프로세스이다. 체인코드에 대한 실행가능한 바이너리가 실제로 원장 상에 존속하지 않기 때문에, 그들은 먼저, 그를 지원하기 위해 선택된 모든 각각의 배서 피어 상에 설치되어야 한다. 다음으로, 전체 채널은 "체인코드 인스턴스화"로 지칭되는 단계에 의해, 실행할 체인코드의 정확한 버전 및 트랜잭션들에 대한 배서 정책에 동의해야 한다. 인스턴스화 트랜잭션을 제출하는 사용자는, 컨소시엄이 설정되었을 때 그들이 미리 결정된 규칙들에 따라 그렇게 행하는 것을 승인받았음을 보장하기 위해, "인스턴스화 정책"에 대한 검증을 전달해야 한다.
체인코드들은 업그레이드가능하다. 이들은 이름 및 버전을 배정받는다. 업그레이드할 때, 새로운 버전이 배정될 것이고, 모든 기존 상태들은 자동으로 상속된다.
원장 특징들
원장은 패브릭 내의 모든 상태 전환들의 시퀀싱된 위조 방지 기록이다. 상태 전환들은 참여 당사자들에 의해 제출된 체인코드 호출들('트랜잭션들')의 결과이다. 각각의 트랜잭션은, 생성들, 업데이트들, 또는 삭제들로서 원장에 커밋되는, 자산 키-값 쌍들의 세트를 초래한다.
원장은 변경불가능한 시퀀싱된 기록를 블록들에 저장하기 위한 블록체인('체인')뿐만 아니라 현재의 패브릭 상태를 유지하기 위한 상태 데이터베이스로 구성된다. 채널당 하나의 원장이 존재한다. 각각의 피어는 그들이 구성원인 각각의 채널에 대한 원장의 사본을 유지한다.
패브릭 원장의 일부 특징들은 다음과 같다:
● 키 기반 순람들, 범위 질의들, 및 복합 키 질의들을 사용한 질의 및 원장 업데이트
● (상태 데이터베이스로서 카우치DB®를 사용하는 경우의) 풍부한 질의 언어를 사용한 판독 전용 질의들
● 판독 전용 이력 질의들 ― 데이터 출처 시나리오들을 가능하게 하는, 키에 대한 원장 이력 질의
● 체인코드로 판독된 키들/값들(판독 세트) 및 체인코드로 기입된 키들/값들(기입 세트)의 버전들로 이루어진 트랜잭션들
● 모든 각각의 배서 피어의 서명들을 포함하고 순서화 서비스에 제출되는 트랜잭션들
● 블록들로 순서화되고 순서화 서비스로부터 채널 상의 피어들로 "전달"되는 트랜잭션들
● 배서 정책들에 대해 트랜잭션들을 검증하고 정책들을 시행하는 피어들
● 블록을 첨부하기 전의, 판독되었던 자산들에 대한 상태들이 체인코드 실행 시간 이후로 변경되지 않았음을 보장하기 위한 버저닝(versioning) 확인의 수행
● 일단 트랜잭션이 검증되고 커밋되면 존재하는 변경불가능성
● 정책들, 액세스 제어 목록들, 및 다른 관련 정보를 정의하는 구성 블록을 포함하는, 채널의 원장
● 상이한 인증 기관들로부터 도출된 암호 자료들을 허용하는 하는 멤버쉽 서비스 제공자 인스턴스들을 포함하는 채널들
데이터베이스들, 저장 구조, 및 "질의 능력"에 대한 더 철저한 분석(deeper dive)에 대해서는 원장 항목을 참조한다.
프라이버시
하이퍼레저® 패브릭은, 채널별 기반의 변경불가능한 원장뿐만 아니라 자산들의 현재 상태를 조작 및 수정할 수 있는 체인코드(즉, 업데이트 키-값 쌍들)를 이용한다. 원장은 채널의 범위 내에 존재하며, (모든 각각의 참여자가 하나의 공통 채널 상에서 동작하고 있다고 가정하여) 전체 네트워크에 걸쳐 공유될 수 있거나, 특정 참여자 세트만을 포함하도록 비공개화될 수 있다.
후자의 시나리오에서, 이러한 참여자들은 별개의 채널을 생성하고 그에 의해 그들의 트랜잭션들 및 원장을 격리/분리할 것이다. 전체 투명성과 프라이버시 사이의 갭을 가교하기를 원하는 시나리오들을 해결하기 위해, 체인코드는 판독들 및 기입들을 수행하기 위해 자산 상태들에 액세스할 필요가 있는 피어들 상에만 설치될 수 있다(다시 말해서, 체인코드가 피어 상에 설치되지 않은 경우, 체인코드는 원장과 적절히 인터페이싱할 수 없을 것임).
그 채널 상의 조직들의 서브세트가 그들의 트랜잭션 데이터를 기밀로 유지할 필요가 있을 때, 조직들의 권한부여된 서브세트만이 액세스가능한, 논리적으로 채널 원장과 별개인 비공개 데이터베이스에 이러한 데이터를 분리하기 위해 비공개 데이터 집합(집합)이 사용된다.
그에 따라, 채널들은 더 넓은 네트워크로부터 트랜잭션들을 비공개로 유지하는 반면, 집합들은 채널 상의 조직들의 서브세트들 사이에서 데이터를 비공개로 유지한다.
추가로 데이터를 알기 어렵게 하기 위해, 체인코드 내의 값들은, 순서화 서비스에 트랜잭션들을 전송하고 원장에 블록들을 첨부하기 전에, AES와 같은 공통 암호화 알고리즘들을 사용하여 (부분적으로 또는 전체적으로) 암호화될 수 있다. 일단 암호화된 데이터가 원장에 기입되면, 그 데이터는, 암호문을 생성하는 데 사용된 대응하는 키를 소유한 사용자에 의해서만 암호해독될 수 있다. 체인코드 암호화에 대한 추가적인 세부사항들에 대해서는, 개발자들을 위한 체인코드 항목 참조한다.
패브릭에서, 비공개 상태는 피어의 실행 및 비공개 트랜잭션에 의한 배서 단계 동안 계산되고, 결과적인 비공개 상태는 입력과 함께 해시로 표현된다. 결과적으로, 합의 후의 모든 노드들에 대한 일관된 해시는, 비공개 트랜잭션들의 참여 노드들이 항상 비공개 상태들에 대해 동의하는 것을 보장한다.
패브릭은 또한, "채널들"의 개념을 갖는 다른 프라이버시 기술로서 완전한 데이터 격리를 제공한다. 패브릭 채널들은 별개의 블록체인들로서 생각될 수 있는데, 그 이유는, 각각의 채널이, 그 채널의 참여 노드들 간에 공유되는, 그의 원장의 완전히 별개의 인스턴스를 유지하기 때문이다. 대부분의 금융 상품들이 그러한 바와 같이, 컨소시엄이 주로 양방향 트랜잭션들과 관계된 경우, 채널들의 수는 상당히 많아진다: O(N^2)이며, N은 컨소시엄의 참여자들의 수이다.
자신의 블록체인 네트워크에 대한 프라이버시를 달성하는 방식에 대한 더 많은 세부사항들에 대해서는 비공개 데이터 항목을 참조한다.
보안 & 멤버쉽 서비스들
하이퍼레저® 패브릭은, 모든 참여자들이 알려진 신원들을 갖는 트랜잭션 네트워크를 지원한다. 공개 키 기반구조는 조직들, 네트워크 구성요소들, 및 최종 사용자들 또는 클라이언트 애플리케이션들에 결속된 암호화 인증서들을 생성하는 데 사용된다. 결과적으로, 데이터 액세스 제어는 더 넓은 네트워크 및 채널 수준들 상에서 조작 및 통제될 수 있다. 채널들의 존재 및 능력들과 결합된, 하이퍼레저® 패브릭의 이러한 "허가" 개념은 프라이버시 및 기밀성이 가장 중요한 관심사들인 시나리오들을 해결하는 것을 돕는다.
암호화 구현들, 및 하이퍼레저® 패브릭에서 사용되는 서명, 검증, 인증 접근법을 더 잘 이해하려면 멤버쉽 서비스 제공자들(MSP) 항목을 참조한다.
합의
분산형 원장 기술에서, 합의는 최근에 단일 기능 내에서 특정 알고리즘과 동의어가 되었다. 그러나, 합의는 단순히 트랜잭션들의 순서에 동의하는 것 이상의 것을 포함하며, 이러한 구별은 제안 및 배서로부터 순서화, 검증 및 커밋까지의 전체 트랜잭션 흐름에서의 그의 기본적인 역할을 통해 하이퍼레저® 패브릭에서 강조된다. 넛쉘(nutshell)에서, 합의는 블록을 포함하는 트랜잭션들의 세트의 정확성의 일주(full-circle) 검증으로서 정의된다.
패브릭은, 그의 합의 모델에서 비-결정론을 제거하는 것이 아니라 용인한다. 패브릭은 설계 원리로서 스마트 계약을 위한 전체 언어들을 제공한다. 패브릭 체인코드들은 3개의 전체 언어 런타임: 고랭(Golang), Node.js® 및 자바로 작성될 수 있다. 이는, 실행-순서화-검증(execute-order-validate) 합의 설계를 채택함으로써 가능해지며, 이에 따라, 블록체인 시스템은, 개발자들이 논리 및 구현을 계속 완벽하게 하는 동안 비-결정론적 체인코드에 의해 야기되는 불량 트랜잭션들을 견딜 수 있다.
도 12에 예시된 "선 실행 후 순서화" 설계는 일종의 동시성 버전 제어가 필요하다는 것을 암시하며, 그렇지 않으면, 다수의 트랜잭션들이 동일한 상태 값을 병렬로 수정하려고 시도할 때, 나중의 것은 앞선 트랜잭션의 결과 상에 구축되는 것이 아니라 앞선 트랜잭션을 덮어 쓰고 앞선 트랜잭션으로부터의 상태 전달을 완전히 지울 것이다. 패브릭은 데이터베이스 설계로부터 차용된 다중버전 동시성 제어(MVCC) 기법을 이용한다. 체인코드 엔진은 스마트 계약이 실행될 때 어떤 상태 값들이 (판독 세트에서) 보여지고 (기입 세트에서) 업데이트되는지를 계속 추적한다. 블록 내부에 포함된 각각의 트랜잭션이 검증되고 상태 전달이 적용되는 검증 단계 동안, 트랜잭션의 판독세트 내의 트랜잭션의 상태 값 버전들이, 전형적으로 이들이 블록 내의 앞선 트랜잭션에 의해 업데이트되었기 때문에, 현재 버전들과 매칭하지 않는 경우, 트랜잭션은 무효인 것으로 표기된다.
그것이 암시하는 것은, 일련의 트랜잭션들이 동일한 상태 값을 수정할 필요가 있는 경우, 이들은 하나 이하의 트랜잭션이 단일 블록 내에 놓이도록 조절되어야 한다는 것이다. 그렇지 않으면, 애플리케이션은 프로그램은 동시적인 수정들로 인해 많은 무효 트랜잭션을 관측할 것이다.
동일한 기본 상태 변수를 표적으로 하는 키들을 함께 그룹화하는 능력을 가지면서 각각의 트랜잭션에 대한 고유한 키들을 어셈블링하는 복합 키 능력을 활용하는 것과 같은, 이러한 제한을 피해서 프로그래밍하기 위한 기법들이 존재한다.
합의는 궁극적으로 블록의 트랜잭션들의 순서 및 결과들이 명시적 정책 기준 확인들을 충족했을 때 달성된다. 이러한 확인들 및 균형들은 트랜잭션의 수명주기 동안 발생하고, 어느 특정 구성원들이 특정 트랜잭션 부류를 배서해야 하는지를 지시하기 위한 배서 정책들뿐만 아니라 이러한 정책들이 시행되고 유지되는 것을 보장하기 위한 시스템 체인코드들의 사용을 포함한다. 커밋 이전에, 피어들은, 이러한 시스템 체인코드들을 이용하여, 충분한 배서들이 존재하고 이들이 적절한 엔티티들로부터 도출되었다는 것을 확실히 할 것이다. 더욱이, 트랜잭션들을 포함하는 임의의 블록들이 원장에 첨부되기 전에, 버저닝 확인이 발생할 것이며, 그 동안에 원장의 현재 상태가 동의 또는 합의된다. 이러한 최종 확인은 데이터 무결성을 손상시킬 수 있는 이중 지불 동작들 및 다른 위협들에 대한 보호를 제공하고, 기능들이 비-정적 변수들에 대해 실행되는 것을 허용한다.
발생하는 다수의 배서, 유효성 및 버저닝 확인들에 부가하여, 트랜잭션 흐름의 모든 방향들에서 발생하는 진행 중인 신원 검증들이 또한 존재한다. 액세스 제어 목록들은 (순서화 서비스로부터 아래로는 채널들에 이르는) 네트워크의 계층적 계층들 상에서 구현되고, 트랜잭션 제안이 상이한 아키텍처 구성요소들을 통과함에 따라 페이로드들은 반복적으로 서명되고, 검증되고, 인증된다. 결론을 내리자면, 합의는 단지 트랜잭션들의 배치(batch)의 합의된 순서로만 제한되지 않으며; 오히려, 제안으로부터 커밋까지의 트랜잭션의 여정 동안 발생하는 진행 중인 검증들의 부산물로서 달성되는 지배적인 특성화이다.
동작 통제
통제는, 컨소시엄 구성원 조직들이 의사 결정 프로세스들에 적절하게 참여하는 것을 보장하기 위한 프로토콜 런타임에 대한 프로세스 및 정책이다.
패브릭에는, 아키텍처의 모든 각각의 계층 상에 허가 통제가 내장되어 있다. 새로운 컨소시엄의 시작, 구성원들의 추가 또는 축출, 새로운 채널의 정의, 채널들에서의 참여자들의 추가 및 축출과 같은 동작들은 모두 적절한 조직들로부터 승인 서명들을 수집하는 것을 요구한다. 지배적인 정책 모델이 시스템 전체에 걸쳐 시행된다.
패브릭은, 2개의 수준의 허가 및 통제 지원, 즉, 컨소시엄 및 채널을 갖는다. 오더러들은 컨소시엄 수준에 대한 정책들 및 구성들을 관리한다. 모든 각각의 패브릭 블록체인 네트워크는 조직들 및 컨소시엄들을 정의하는 제네시스 블록 구성으로부터의 오더러 부트스트랩으로 시작한다. 피어들은 채널 수준에서 정책들 및 구성들을 관리한다. 구성들을 수정하는 것, 이를테면, 컨소시엄 또는 채널에 새로운 구성원 조직들을 추가하는 것은, 수정 정책 ― 기존 구성원들 중 임의의 구성원(ANY), 모든 구성원(ALL) 또는 대다수의 구성원(MAJORITY) ― 에 따라 서명들을 수집하는 것을 요구한다.
패브릭 아키텍처 그 자체는 탈중앙집중형 오더러 구현을 허용한다. 실제로, 버전 1.4에서의 래프트 기반(Raft based) 오더러 구현의 도입으로, 오더러 노드들을 중앙집중형 순서화 엔진과 페어링할 필요가 더 이상 없다. 각각의 오더러 노드 그 자체는 래프트 피어이고, 현재의 리더가 고장나거나 도달불가능하게 되는 경우에 리더 선출에 참여할 수 있다. 이는, 하나 초과의 조직이 오더러 노드들을 동작시키고 합의 및 제안 블록들에 참여할 수 있는 더 탈중앙집중화된 배치를 허용한다.
피어들
블록체인 네트워크는 주로 피어 노드들 (또는 간단히, 피어들)의 세트로 구성된다. 피어들은, 그들이 원장들 및 스마트 계약들을 호스팅하기 때문에 네트워크의 기본적인 요소이다. 원장은 (하이퍼레저® 패브릭에서 체인코드에 포함되는) 스마트 계약들에 의해 생성된 모든 트랜잭션을 변경불가능하게 기록한다. 스마트 계약들 및 원장들은 각각, 네트워크에서 공유 프로세스들 및 공유 정보를 캡슐화하는 데 사용된다. 피어의 이러한 양상들은, 이들이 패브릭 네트워크를 이해하기 위한 양호한 시작점이 되게 한다.
블록체인 네트워크의 다른 요소들: 원장들 및 스마트 계약들, 오더러들, 정책들, 채널들, 애플리케이션들, 조직들, 신원들, 및 멤버쉽도 물론 중요하다. 본 섹션은 피어들, 및 패브릭 네트워크 내의 다른 요소들에 대한 피어들의 관계에 초점을 맞춘다.
도 13은 각각이 원장들의 사본들 및 스마트 계약들의 사본들을 보유할 수 있는 피어 노드들로 구성된 블록체인 네트워크를 예시한다. 이러한 예에서, 네트워크(N)는 피어들(P1, P2 및 P3)로 이루어되며, 이들 각각은 분산형 원장(L1)의 그들 고유의 인스턴스를 유지한다. P1, P2 및 P3은 동일한 체인코드 S1을 사용하여, 그 분산형 원장의 그들의 사본에 액세스한다.
피어들은 생성, 시작, 중단, 재구성 및 심지어 삭제될 수 있다. 이들은 관리자들 및 애플리케이션들이 그들이 제공하는 서비스들과 상호작용할 수 있게 하는 API들의 세트를 노출시킨다.
용어에 대한 언질
패브릭은 체인코드로, 즉, 단순히, 지원되는 프로그래밍 언어들 중 하나로 작성된, 원장에 액세스하는 코드 조각으로 스마트 계약을 구현한다.
원장들 및 체인코드
원장 및 체인코드 둘 모두를 호스팅하는 것은 피어이다. 더 정확하게는, 피어는 실제로 원장의 인스턴스들 및 체인코드의 인스턴스들을 호스팅한다. 이는, 패브릭 네트워크에서 의도적인 중복을 제공한다는 것, 즉, 그것은 단일 실패 지점들을 피한다는 것을 유의한다.
도 14는 원장들의 인스턴스들 및 체인코드들의 인스턴스들을 호스팅하는 피어를 예시한다. 이러한 예에서, P1은 원장(L1)의 인스턴스 및 체인코드(S1)의 인스턴스를 호스팅한다. 개별 피어 상에서 호스팅되는 많은 원장들 및 체인코드들이 존재할 수 있다.
피어가 원장 및 체인코드에 대한 호스트이기 때문에, 애플리케이션들 및 관리자들은 그들이 이러한 리소스들에 액세스하기를 원하는 경우 피어와 상호작용해야 한다. 이것은, 피어들이 패브릭 네트워크의 가장 기본적인 구축 블록들로 간주되는 이유이다. 피어가 처음 생성될 때, 피어는 원장들도 체인코드들도 갖지 않는다.
다수의 원장들
피어는 하나 초과의 원장을 호스팅할 수 있으며, 이는, 그것이 유연한 시스템 설계를 가능하게 하기 때문에 도움이 된다. 가장 간단한 구성은 피어가 단일 원장을 관리하는 것이지만, 요구될 때 피어가 2개 이상의 원장을 호스팅하는 것이 절대적으로 적절하다.
도 15는 다수의 원장들을 호스팅하는 피어를 예시한다. 피어들은 하나 이상의 원장을 호스팅하고, 각각의 원장은 그들에 적용되는 0개 이상의 체인코드를 갖는다. 이러한 예에서, 피어 P1이 원장들 L1 및 L2를 호스팅한다는 것을 알 수 있다. 원장 L1은 체인코드 S1을 사용하여 액세스된다. 반면에, 원장 L2는 체인코드들 S1 및 S2를 사용하여 액세스될 수 있다.
피어는, 원장 인스턴스를, 그 원장에 액세스하는 임의의 체인코드들을 호스팅함이 없이 호스팅하는 것이 완벽하게 가능하지만, 피어들이 이러한 방식으로 구성되는 것은 드물다. 대다수의 피어들은 피어의 원장 인스턴스들에 대해 질의하거나 그를 업데이트할 수 있는 자신 상에 설치된 적어도 하나의 체인코드를 가질 것이다. 언급하는 김에, 사용자들이 외부 애플리케이션들에 의한 사용을 위해 체인코드들을 설치하였는지 여부에 관계없이, 피어들은 또한 항상 존재하는 특수 시스템 체인코드들을 갖는다는 것이 특기할 만하다.
다수의 체인코드들
피어가 갖는 원장의 수와 그 원장에 액세스할 수 있는 체인코드들의 수 사이에는 고정된 관계가 존재하지 않는다. 피어는 자신이 이용가능한 많은 원장들 및 많은 체인코드들을 가질 수 있다.
도 16은 다수의 체인코드들을 호스팅하는 피어의 예를 예시한다. 각각의 원장은 그에 액세스하는 많은 체인코드들을 가질 수 있다. 이러한 예에서, 피어 P1은 원장들 L1 및 L2를 호스팅하며, L1은 체인코드들 S1 및 S2에 의해 액세스되고, L2는 S1 및 S3에 의해 액세스된다는 것을 알 수 있다. S1은 L1 및 L2 둘 모두에 액세스할 수 있다.
애플리케이션들 및 피어들
원장-질의 상호작용들은 애플리케이션과 피어 사이의 간단한 3단계 대화를 수반하고; 원장-업데이트 상호작용들에는 조금 더 수반되는데, 2개의 가외의 단계를 요구한다.
애플리케이션들은, 그들이 원장들 및 체인코드들에 액세스할 필요가 있을 때 항상 피어들에 연결된다. 패브릭 소프트웨어 개발 키트(SDK)는 이를 프로그래머들에게 용이하게 하는데, 그의 API들은, 애플리케이션들이, 피어들에 연결되고, 체인코드들을 호출하여 트랜잭션들을 생성하고, 순번을 받아 분산형 원장에 커밋될 트랜잭션들을 네트워크에 제출하고, 이 프로세스가 완료될 때 이벤트들을 수신할 수 있게 한다.
피어 연결을 통해, 애플리케이션들은 체인코드들을 실행하여 원장에 대해 질의하거나 그를 업데이트할 수 있다. 원장 질의 트랜잭션의 결과는 즉시 반환되는 반면, 원장 업데이트는 애플리케이션들, 피어들 및 오더러들 사이의 더 복잡한 상호작용을 수반한다.
도 17은, 원장이 모든 각각의 피어 상에서 최신으로 유지됨을 보장하는 피어들을 오더러들과 함께 예시한다. 이러한 예에서, 애플리케이션 A는 P1에 연결되고 체인코드 S1을 호출하여 원장 L1에 대해 질의하거나 그를 업데이트한다. P1은 S1을 호출하여 질의 결과 또는 제안된 원장 업데이트를 포함하는 제안 응답을 생성한다. 애플리케이션 A는 제안 응답을 수신하고, 질의들에 대해, 프로세스가 이제 완료된다. 업데이트들의 경우, A는 모든 응답으로부터 트랜잭션을 구축하고, A는 순서화를 위해 이를 O1에 전송한다. O1은 네트워크에 걸쳐 그로부터 트랜잭션들을 블록들로 수집하고, 이들을 P1을 포함하는 모든 피어들에 배포한다. P1은 L1에 적용하기 전에 트랜잭션을 검증한다. 일단 L1이 업데이트되면, P1은 A에 의해 수신되는 이벤트를 생성하여 완료를 나타낸다.
피어는 질의의 결과들을 애플리케이션에 즉시 반환할 수 있는데, 그 이유는, 질의를 충족시키는 데 요구되는 모든 정보가 원장의 피어의 로컬 사본에 있기 때문이다. 피어들은 애플리케이션으로부터의 질의에 응답하기 위해 결코 다른 피어들과 협의하지 않는다. 그러나, 애플리케이션들은 하나 이상의 피어에 연결되어 질의를 발행할 수 있는데, 예컨대, 다수의 피어들 간의 결과를 확증하거나, 정보가 유효 기간이 지났을 수 있다는 의심이 존재하는 경우, 상이한 피어로부터 보다 최신의 결과를 검색할 수 있다. 도면에서, 원장 질의는 간단한 3단계 프로세스임을 알 수 있다.
업데이트 트랜잭션은 질의 트랜잭션과 동일한 방식으로 시작하지만 2개의 가외의 단계를 갖는다. 원장-업데이트 애플리케이션들이 또한 체인코드를 호출하기 위해 피어들에 연결되지만, 원장-질의 애플리케이션들과 달리, 개별 피어는 이때 원장 업데이트를 수행할 수 없는데, 그 이유는, 다른 피어들이 변경에 먼저 동의해야만 하기 때문이며, 이러한 프로세스를 합의로 지칭된다. 따라서, 피어들은 제안된 업데이트, 즉, 이 피어가 다른 피어들의 사전 동의를 조건으로 하여 적용할 업데이트를 애플리케이션에 반환한다. 제1 가외의 단계 ― 단계 4 ― 는, 애플리케이션들이, 매칭하는 제안된 업데이트들의 적절한 세트를, 피어들의 전체 네트워크에, 그들의 개개의 원장들에 대한 커밋을 위한 트랜잭션으로서 전송할 것을 요구한다. 이는, 오더러를 사용하여 트랜잭션들을 블록들로 패키징하고 이들을 피어들의 전체 네트워크에 배포하는 애플리케이션에 의해 달성되며, 여기서, 트랜잭션들은 원장의 각각의 피어의 로컬 사본에 적용되기 전에 검증될 수 있다. 이러한 전체 순서화 처리가 완료되는 데 얼마간의 시간(수 초)을 소요하므로, 단계 5에서 나타낸 바와 같이, 애플리케이션은 비동기식으로 통지받는다.
피어들 및 채널들
피어들은, 채널들을 통해, 즉, 블록체인 네트워크 내의 한 세트의 구성요소들이 비공개로 통신하고 트랜잭팅할 수 있는 메커니즘을 통해, 서로 그리고 애플리케이션들과 상호작용한다.
이러한 구성요소들은 전형적으로 피어 노드들, 오더러 노드들 및 애플리케이션들이며, 그들은, 채널에 참가함으로써, 그 채널과 연관된 원장의 동일한 사본들을 집합적으로 공유하고 관리하기 위해 협력하는 것에 동의한다. 개념적으로, 채널들은 친구들의 그룹들과 유사한 것으로 생각될 수 있다. 사람은 여러 그룹들의 친구들을 가질 수 있고, 각각의 그룹은 그들이 함께 행하는 활동들을 갖는다. 이러한 그룹들은 완전히 별개일 수 있거나(취미 친구들의 그룹에 비교하여 직장 친구들의 그룹), 그들 사이에 약간의 교차가 존재할 수 있다. 그럼에도 불구하고, 각각의 그룹은 일종의 "규칙들"을 갖는 자신 고유의 엔티티이다.
도 18은 특정 세트의 피어들 및 애플리케이션들이 블록체인 네트워크 내에서 서로 통신할 수 있게 하는 채널들을 예시한다. 이러한 예에서, 애플리케이션 A는 채널 C를 사용하여 피어들 P1 및 P2와 직접 통신할 수 있다. 채널은 특정 애플리케이션들과 피어들 사이에서의 통신들을 위한 경로로서 생각될 수 있다. (간략화를 위해, 오더러들은 이 도면에 도시되지 않지만, 기능 네트워크에 존재해야 한다.)
채널들은 피어들과 동일한 방식으로 존재하지 않는데, 채널을 물리적 피어들의 집합에 의해 형성되는 논리적 구조로서 생각하는 것이 더 적절하다. 피어들은 채널들로의 액세스 및 채널들의 관리를 위한 제어점을 제공한다.
피어들 및 조직들
블록체인 네트워크들은 단일 조직이 아니라 조직들의 집합에 의해 관리된다. 피어들은 이러한 종류의 분산형 네트워크가 구축되는 방식의 중심이 되는데, 그 이유는, 피어들이 이들 조직들에 의해 소유되고 이들 조직들에 대한 네트워크에 대한 연결점들이기 때문이다.
도 19는 다수의 조직들을 갖는 블록체인 네트워크 내의 피어들을 예시한다. 블록체인 네트워크는 상이한 조직들이 소유하고 그들에 의해 기여되는 피어들로부터 구축된다. 이러한 예에서, 네트워크를 형성하기 위해 4개의 조직이 8개의 피어에 기여하는 것을 참조한다. 채널 C는 네트워크 N 내의 이러한 피어들 중 5개(P1, P3, P5, P7 및 P8)에 연결된다. 이러한 조직들이 소유한 다른 피어들은 이 채널에 참가되어 있지 않지만, 전형적으로 적어도 하나의 다른 채널에 참가되어 있다. 특정 조직에 의해 개발된 애플리케이션들은 자신 고유의 조직의 피어들뿐만 아니라 상이한 조직들의 피어들에 연결될 것이다. 다시, 간략화를 위해, 오더러 노드는 이 도면에 도시되지 않는다.
네트워크는 리소스들을 자신에 기여하는 다수의 조직들에 의해 형성되고 관리된다. 피어들은 이 항목에서 논의하고 있는 리소스들이지만, 조직이 제공하는 리소스들은 단지 피어들만에 그치지 않는다. 여기서, 자신의 개별 리소스들을 집합적 네트워크에 기여하는 조직들 없이는 네트워크가 문자 그대로 존재하지 않는다는 원리가 작용한다. 더욱이, 네트워크는, 이러한 협력 조직들에 의해 제공되는 리소스들에 따라 성장하고 축소된다.
순서화 서비스 외에는, 어떠한 중앙집중형 리소스들도 존재하지 않는데, 위의 예에서, 조직들이 그들의 피어들에 기여하지 않는 경우 네트워크 N은 존재하지 않을 것이다. 이는, 조직들이 네트워크를 형성하는 리소스들에 기여하지 않는 한 그리고 기여할 때까지 네트워크가 임의의 유의미한 의미로 존재하지 않는다는 사실을 반영한다. 더욱이, 네트워크는 임의의 개별 조직에 의존하지 않는데, 네트워크는, 어느 것이든 다른 조직들이 오고 갈 수 있더라도 하나의 조직이 남아 있는 한 계속 존재할 것이다. 이는, 네트워크가 탈중앙집중화된다는 것이 어떤 의미인지에 대한 핵심이다.
위의 예에서와 같이, 상이한 조직들의 애플리케이션들은 동일할 수 있거나 동일하지 않을 수 있다. 그것은, 조직의 애플리케이션들이 원장의 그들의 피어들의 사본들을 처리하는 방식에 관해 전적으로 조직에 달려 있기 때문이다. 이는, 그들 개개의 피어들이 정확히 동일한 원장 데이터를 호스팅한다 하더라도, 애플리케이션 및 프리젠테이션 논리 둘 모두가 조직마다 다를 수 있다는 것을 의미한다.
애플리케이션들은, 요구되는 원장 상호작용의 속성에 따라, 그들의 조직 내의 피어들, 또는 다른 조직 내의 피어들에 연결된다. 원장-질의 상호작용들의 경우, 애플리케이션들은 전형적으로 자신 고유의 조직의 피어들에 연결된다. 원장-업데이트 상호작용들의 경우, 애플리케이션은 원장 업데이트를 배서하는 데 요구되는 모든 각각의 조직을 표현하는 피어들에 연결될 필요가 있다.
피어들 및 신원
피어들은 특정 인증 기관으로부터의 디지털 인증서를 통해 그들에 배정된 신원을 갖는다. 디지털 인증서는, 피어에 관한 많은 검증가능한 정보를 제공하는 ID 카드와 같다. 네트워크 내의 각각의 그리고 모든 각각의 피어는 자신의 소유 조직으로부터의 관리자에 의해 디지털 인증서를 배정받는다.
도 20은, 피어가 채널에 연결될 때, 그의 디지털 인증서가 채널 MSP를 통해 자신의 소유 조직을 식별하는 것을 예시한다. 이러한 예에서, P1 및 P2는 CA1에 의해 발행된 신원들을 갖는다. 채널 C는, 그의 채널 구성에서의 정책으로부터, CA1로부터의 신원들이 ORG1.MSP를 사용하여 Org1과 연관되어야 한다고 결정한다. 유사하게, P3 및 P4는 Org2의 일부인 것으로서 ORG2.MSP에 의해 식별된다.
피어가 채널을 사용하여 블록체인 네트워크에 연결될 때마다, 채널 구성에서의 정책은 피어의 신원을 사용하여 그의 권한들을 결정한다. 조직에 대한 신원의 맵핑은 멤버쉽 서비스 제공자(MSP)로 지칭되는 구성요소에 의해 제공되는데, 그 구성요소는, 피어가 특정 조직에서 특정 역할에 배정되고 그에 따라 블록체인 리소스들에 대한 적절한 액세스를 얻는 방식을 결정한다. 더욱이, 피어는 단일 조직에 의해서만 소유될 수 있으며, 따라서, 단일 MSP와 연관된다. MSP는 블록체인 네트워크에서 개별 신원과 특정 조직 역할 사이의 연관성을 제공한다.
피어들뿐만 아니라 블록체인 네트워크와 상호작용하는 모든 것은 그들의 디지털 인증서 및 MSP로부터 그들의 조직 신원을 취득한다. 피어들, 애플리케이션들, 최종 사용자들, 관리자들 및 오더러들은, 그들이 블록체인 네트워크와 상호작용하기를 원하는 경우, 신원 및 연관된 MSP를 가져야 한다. 신원을 사용하여 블록체인 네트워크와 상호작용하는 모든 각각의 엔티티에 이름 ― 주 대상(principal) ― 이 주어진다.
피어가 물리적으로 어디에 위치되는지 ― 피어는 클라우드에 또는 조직들 중 하나가 소유한 데이터 센터에 또는 로컬 기계 상에 상주할 수 있는 있음 ― 는 매우 중요하지는 않으며, 특정 조직이 소유한 것으로서 피어를 식별하는 것은 피어와 연관된 신원이다. 위의 예에서, P3은 Org1의 데이터 센터에서 호스팅될 수 있지만, 그와 연관된 디지털 인증서가 CA2에 의해 발행되는 한, 그것은 Org2가 소유한다.
피어들 및 오더러들
모든 각각의 피어의 원장이 일관되게 유지되는 것을 보장하도록 애플리케이션들 및 피어들이 서로 상호작용하는 메커니즘은, 오더러들로 지칭되는 특수 노드들에 의해 매개된다.
업데이트 트랜잭션은 질의 트랜잭션과 상당히 상이한데, 그 이유는, 단일 피어가 그 자체적으로는 원장을 업데이트할 수 없기 때문이며, 업데이트하는 것은, 네트워크 내의 다른 피어들의 합의를 요구한다. 피어는, 원장 업데이트가 피어의 로컬 원장에 적용될 수 있기 전에, 원장 업데이트를 승인할 것을 네트워크 내의 다른 피어들에게 요구한다. 이러한 프로세스는 합의로 지칭되며, 이는 간단한 질의보다 완료하는 데 훨씬 더 오래 걸린다. 그러나, 트랜잭션을 승인하는 데 요구되는 모든 피어들이 그렇게 하고, 트랜잭션이 원장에 커밋될 때, 피어들은 그들의 연결된 애플리케이션들에게 원장이 업데이트되었음을 통지할 것이다.
구체적으로, 원장을 업데이트하기를 원하는 애플리케이션들은 3단계 프로세스에 수반되고, 이는, 블록체인 네트워크 내의 모든 피어들이 그들의 원장들을 서로 일관되게 유지하는 것을 보장한다. 제1 단계에서, 애플리케이션들은 배서 피어들의 서브세트와 함께 작동하며, 배서 피어들 각각은 제안된 원장 업데이트의 배서를 애플리케이션에 제공하지만, 제안된 업데이트를 원장의 그들의 사본에 적용하지 않는다. 제2 단계에서, 이러한 별개의 배서들은 트랜잭션들로서 함께 수집되고 블록들로 패키징된다. 최종 단계에서, 이러한 블록들은 모든 각각의 피어에 다시 배포되며, 각각의 트랜잭션은 원장의 그 피어의 사본에 적용되기 전에 검증된다.
오더러 노드들은 이러한 프로세스의 중심이 된다. 애플리케이션들 및 피어들은, 오더러들을 사용하여, 분산형의 복제된 원장에 지속적으로 적용될 수 있는 원장 업데이트들을 생성한다.
단계 1:
트랜잭션 작업흐름의 단계 1은 애플리케이션과 피어들의 세트 사이의 상호작용을 수반하며, 그것은 오더러들을 수반하지 않는다. 단계 1은 상이한 조직들의 배서 피어들에게 제안된 체인코드 호출의 결과들에 동의하는지를 문의하는 애플리케이션과만 관계된다.
단계 1을 시작하기 위해, 애플리케이션들은 배서에 대해 요구된 피어들의 세트 각각에 그들이 전송하는 트랜잭션 제안을 생성한다. 이러한 배서 피어들 각각은 이어서, 트랜잭션 제안을 사용하여 체인코드를 독립적으로 실행하여 트랜잭션 제안 응답을 생성한다. 그것은 이러한 업데이트를 원장에 적용하지 않고, 오히려, 단순히 그에 서명하여 그것을 애플리케이션에 반환한다. 일단 애플리케이션이 충분한 수의 서명된 제안 응답들을 수신하면, 트랜잭션 흐름의 제1 단계가 완료된다.
도 21은 배서된 제안 응답들을 반환하는 피어들에 의해 독립적으로 실행되는 트랜잭션 제안들을 예시한다. 이러한 예에서, 애플리케이션 A1은 채널 C 상에서 피어 P1 및 피어 P2 둘 모두에게 자신이 전송하는 트랜잭션 T1 제안 P를 생성한다. P1은 자신이 E1로 배서하는 트랜잭션 T1 응답 R1을 생성하는 트랜잭션 T1 제안 P를 사용하여 S1을 실행한다. 독립적으로, P2는 자신이 E2로 배서하는 트랜잭션 T1 응답 R2를 생성하는 트랜잭션 T1 제안 P를 사용하여 S1을 실행한다. 애플리케이션 A1은 트랜잭션 T1에 대한 2개의 배서된 응답, 즉, E1 및 E2를 수신한다.
처음에, 제안된 원장 업데이트들의 세트를 생성하기 위해 애플리케이션에 의해 피어들의 세트가 선택된다. 애플리케이션에 의해 선택된 피어들은, 제안된 원장 변경이 네트워크에 의해 수락될 수 있기 전에 그 원장 변경에 배서할 필요가 있는 조직들의 세트를 정의하는 배서 정책(체인코드에 대해 정의됨)에 의존한다. 이는 문자 그대로 합의를 달성한다는 것이 어떤 의미인지를 나타내는데, 중요한 모든 각각의 조직은, 제안된 원장 변경이 임의의 피어의 원장 상에 수락되기 전에 그에 배서했어야 한다.
피어는 자신의 디지털 서명을 부가하고 자신의 비공개 키를 사용하여 전체 페이로드에 서명함으로써 제안 응답에 배서한다. 이러한 배서는 후속하여, 이 조직의 피어가 특정 응답을 생성했다는 것을 증명하는 데 사용될 수 있다. 위의 예에서, 피어 P1을 조직 Org1이 소유한 경우, 배서 E1은 "원장 L1 상의 트랜잭션 T1 응답 R1이 Org1의 피어 P1에 의해 제공되었다"는 디지털 증명에 대응한다.
단계 1은 애플리케이션이 충분한 피어들로부터 서명된 제안 응답들을 수신할 때 종료된다. 상이한 피어들은 동일한 트랜잭션 제안에 대해, 상이한 그리고 그에 따라서 일관되지 않은 트랜잭션 응답들을 애플리케이션에 반환할 수 있다. 단순히, 상이한 상태들의 원장들을 갖는 상이한 피어들 상에서 상이한 시간들에 결과가 생성된 것일 수도 있으며, 이 경우에, 애플리케이션은 단순히 더 최신의 제안 응답을 요청할 수 있다. 가능성은 적지만, 체인코드가 비-결정론적이기 때문에, 훨씬 더 심각하게 결과들이 상이했을 수 있다. 비-결정론은 체인코드들 및 원장들의 적이며, 이는, 발생하는 경우, 일관되지 않은 결과들은 명백하게 원장들에 적용될 수 없으므로, 제안된 트랜잭션에서 심각한 문제를 나타낸다. 개별 피어는 그들의 트랜잭션 결과가 비-결정론적이라는 것을 알 수 없는데, 트랜잭션 응답들은 비-결정론이 검출될 수 있기 전에 비교를 위해 함께 수집되어야 한다.
단계 1의 끝에서, 애플리케이션은, 일관되지 않은 트랜잭션 응답들을, 애플리케이션이 그렇게 하고자 하는 경우, 자유롭게 폐기하여, 트랜잭션 작업흐름을 조기에 효과적으로 종결시킨다. 애플리케이션이 원장을 업데이트하기 위해 일관되지 않은 트랜잭션 응답 세트를 사용하려고 시도하는 경우, 이는 거절될 것이다.
단계 2: 트랜잭션들의 블록들로의 순서화 및 패키징
트랜잭션 작업흐름의 제2 단계는 패키징 단계이다. 오더러는 이 프로세스에 대해 중심이 되는데, 오더러는 많은 애플리케이션들로부터 배서된 트랜잭션 제안 응답들을 포함하는 트랜잭션들을 수신하고 트랜잭션들을 블록들로 순서화한다. 순서화 및 패키징 단계에 관한 더 많은 세부사항에 대해서는, 순서화 단계에 관한 개념적 정보를 확인한다.
단계 3: 검증 및 커밋
단계 2의 끝에서, 오더러들은 제안된 트랜잭션 업데이트들을 수집하고, 이들을 순서화하고, 이들을 피어들에게 배포할 준비가 된 블록들로 패키징하는 간단하지만 필수적인 프로세스들을 담당한다.
트랜잭션 작업흐름의 최종 단계는, 오더러로부터 피어들로의 블록들의 배포 및 후속 검증을 수반하며, 여기서, 이들은 원장에 적용될 수 있다. 구체적으로, 각각의 피어에서, 블록 내의 모든 트랜잭션은, 그것이 원장에 적용되기 전에 모든 관련 조직들에 의해 일관되게 배서되었음을 보장하기 위해 검증된다. 실패한 트랜잭션들은 감사를 위해 유지되지만 원장에는 적용되지 않는다.
도 22는 블록들을 피어들에 배포하는, 오더러 노드의 제2 역할을 예시한다. 이러한 예에서, 주문자 O1은 블록 B2를 피어 P1 및 피어 P2에 배포한다. 피어 P1은 블록 B2를 처리하며, 그 결과, 새로운 블록이 P1 상의 원장 L1에 부가되게 된다. 병렬로, 피어 P2는 블록 B2를 처리하며, 그 결과, 새로운 블록이 P2 상의 원장 L1에 부가되게 된다. 일단 이러한 프로세스가 완료되면, 원장 L1은 피어들 P1 및 P2 상에 일관되게 업데이트되었으며, 각각은 트랜잭션이 처리되었다는 것을 연결된 애플리케이션들에 통보할 수 있다.
단계 3은 오더러가 블록들을 그에 연결된 모든 피어들에 배포하는 것으로 시작된다. 피어들은, 새로운 블록이 생성될 때, 오더러에 연결된 모든 피어들이 새로운 블록의 사본을 전송받도록, 채널들 상의 오더러들에 연결된다. 각각의 피어는 이러한 블록을 독립적으로, 그러나 채널 상의 모든 각각의 다른 피어와 정확히 동일한 방식으로 처리할 것이다. 이러한 방식으로, 원장은 일관되게 유지될 수 있다. 또한, 모든 각각의 피어가 오더러에 연결될 필요는 없는데, 피어들은 가십 프로토콜을 사용하여 다른 피어들에 블록들을 캐스케이딩할 수 있으며, 이들이 또한 그 블록들을 독립적으로 처리할 수 있다.
블록의 수신 시, 피어는 블록에서 트랜잭션이 나타나는 시퀀스로 각각의 트랜잭션을 처리할 것이다. 모든 각각의 트랜잭션에 대해, 각각의 피어는, 트랜잭션을 생성한 체인코드의 배서 정책에 따라, 요구되는 조직들에 의해 트랜잭션이 배서되었다는 것을 검증할 것이다. 예컨대, 일부 트랜잭션들은 단지 단일 조직에 의해 배서될 필요가 있는 반면, 다른 트랜잭션들은 그들이 유효한 것으로 간주되기 전에 다수의 배서들을 요구할 수 있다. 이러한 검증 프로세스는 모든 관련 조직들이 동일한 결론 또는 결과를 생성하였음을 검증한다. 또한, 이러한 검증은 단계 1에서의 배서 확인과 상이하며, 여기서, 애플리케이션이 배서 피어들로부터 응답을 수신하고 제안 트랜잭션들을 전송하기로 결정한다는 것을 유의한다. 애플리케이션이 잘못된 트랜잭션들을 전송함으로써 배서 정책을 위반하는 경우에, 피어는 여전히 단계 3의 검증 프로세스에서 트랜잭션을 거절할 수 있다.
트랜잭션이 올바르게 배서된 경우, 피어는 그 트랜잭션을 원장에 적용하려고 시도할 것이다. 이를 행하기 위해, 피어는, 원장의 현재 상태가, 제안된 업데이트가 생성되었을 때의 원장의 상태와 호환가능한지를 검증하기 위해 원장 일관성 확인을 수행해야 한다. 이는, 심지어 트랜잭션이 충분히 배서된 때에도, 항상 가능한 것은 아닐 수 있다. 예컨대, 다른 트랜잭션은, 트랜잭션 업데이트가 더 이상 유효하지 않고 따라서 더 이상 적용될 수 없도록, 원장 내의 동일한 자산을 업데이트했을 수 있다. 이러한 방식으로, 각각의 피어의 원장의 사본이 네트워크에 걸쳐 일관되게 유지되는데, 그 이유는, 이들 각각이 검증에 대해 동일한 규칙들을 따르기 때문이다.
피어가 각각의 개별 트랜잭션을 성공적으로 검증한 후, 피어는 원장을 업데이트한다. 실패한 트랜잭션들은 원장에 적용되지 않지만, 그 트랜잭션들은, 성공적인 트랜잭션들과 마찬가지로, 감사 목적으로 유지된다. 이는, 피어 블록들이, 블록 내의 각각의 트랜잭션에 대한 유효 또는 무효 표시자를 제외하고는, 오더러로부터 수신된 블록들과 거의 정확하게 동일하다는 것을 의미한다.
단계 3은 체인코드들의 실행을 요구하지 않는데, 이는, 단계 1 동안에만 행해지며, 그것은 중요하다. 이는, 체인코드들이 블록체인 네트워크 전체에 걸쳐서가 아니라 배서 노드들 상에서만 이용가능해야 한다는 것을 의미한다. 이는, 체인코드의 논리를 배서 조직들에 기밀로 유지하기 때문에 종종 도움이 된다. 이는, 피어들이 트랜잭션에 배서했든 그렇지 않든 채널 내의 모든 각각의 피어와 공유되는 체인코드들의 출력(트랜잭션 제안 응답들)과 대조적이다. 배서 피어들의 이러한 특수화는 확장성을 돕도록 설계된다.
마지막으로, 블록이 피어의 원장에 커밋될 때마다, 그 피어는 적절한 이벤트를 생성한다. 블록 이벤트들은 전체 블록 내용을 포함하는 반면, 블록 트랜잭션 이벤트들은, 블록 내의 각각의 트랜잭션이 검증되었는지 또는 무효화되었는지와 같은, 요약 정보만을 포함한다. 체인코드 실행이 생성한 체인코드 이벤트들이 또한 이때 게재될 수 있다. 애플리케이션들은, 이러한 이벤트들이 발생할 때 애플리케이션들이 통지받을 수 있도록 이들 이벤트의 유형들을 등록할 수 있다. 이러한 통지들은 트랜잭션 작업흐름의 제3 및 최종 단계를 종결시킨다.
요약하면, 단계 3은, 원장에 지속적으로 적용된 오더러에 의해 생성되는 블록들을 예상한다. 블록들로의 트랜잭션들의 엄격한 순서화는, 트랜잭션 업데이트들이 블록체인 네트워크에 걸쳐 일관되게 적용된다는 것을 각각의 피어가 검증할 수 있게 한다.
오더러들 및 합의
이러한 전체 트랜잭션 작업흐름 프로세스는 합의로 지칭되는데, 그 이유는, 모든 피어들이, 오더러들에 의해 매개되는 프로세스에서 트랜잭션들의 순서 및 내용에 대한 합의에 도달했기 때문이다. 합의는 다단계 프로세스이고, 애플리케이션들은 프로세스가 완료될 때 원장 업데이트들만을 통지받으며, 이는, 상이한 피어들에 대해 약간 상이한 시간들에 발생할 수 있다.
그에 따라, 오더러들은, 피어들이 검증하고 원장 상에 포함시킬 애플리케이션들로부터의 제안된 원장 업데이트들을 수집 및 배포하는 노드들인 것으로 간주될 수 있다. 반면에, 피어들은 네트워크를 형성하고, 체인코드 및 원장을 호스팅하고, 트랜잭션 제안들 및 응답들을 처리하며, 트랜잭션 업데이트를 원장에 일관되게 적용함으로써 원장을 최신으로 유지한다.
전역 상태
전역 상태는 원장 상태들의 세트의 현재 값들의 캐시를 유지하는 데이터베이스이다. 전역 상태는, 프로그램이 전체 트랜잭션 로그를 순회함으로써 상태의 현재 값을 계산해야 하는 것이 아니라 상태의 현재 값에 직접 액세스하는 것을 용이하게 한다. 원장 상태들은, 기본으로, 키-값 쌍들로서 표현된다. 상태들이 생성, 업데이트 및 삭제될 수 있으므로, 전역 상태는 빈번하게 변경될 수 있다.
전역 상태는 비즈니스 객체의 속성들의 현재 값을 고유 원장 상태로서 유지한다. 이는, 프로그램들이 일반적으로 객체의 현재 값을 요구하는데, 객체의 현재 값을 계산하기 위해 전체 블록체인을 순회하는 것은 번거로울 것이고, 단지 전역 상태로부터 그 현재 값을 획득하기만 하면 되기 때문에 유용하다.
도 23은 2개의 상태를 포함하는 원장 전역 상태를 예시한다. 제1 상태는: 키=CAR1 및 값=Audi이다. 제2 상태는 더 복잡한 값: 키 = CAR2 및 값 = {모델:BMW, 색상=적색, 소유자=제인(Jane)}을 갖는다. 두 상태들 모두는 버전 0에 있다.
원장 상태는 특정 비즈니스 객체에 관한 사실들의 세트를 기록한다. 위의 예는 각각이 키 및 값을 각각 갖는 2개의 차량에 대한 원장 상태들(CAR1 및 CAR2)을 나타낸다. 애플리케이션 프로그램은 간단한 원장 API들을 사용하여 상태들을 획득, 배치 및 삭제하는 스마트 계약을 호출할 수 있다. 상태 값이 어떤 방식으로 단순(Audi...)하거나 복합적(유형:BMW...)일 수 있는지에 주목한다. 전역 상태는 종종 특정 속성들을 갖는 객체들을 검색하기 위해, 예컨대, 모든 적색 BMW들을 찾기 위해 질의된다.
전역 상태는 데이터베이스로서 구현된다. 데이터베이스는 상태들의 효율적인 저장 및 검색을 위한 풍부한 연산자들의 세트를 제공한다. 하이퍼레저® 패브릭은, 상이한 전역 상태 데이터베이스들을 사용하여, 예컨대, 복잡한 질의들에서의, 애플리케이션들에 의해 요구되는 상이한 유형들의 상태 값들 및 액세스 패턴들의 요구들을 해결하도록 구성될 수 있다.
애플리케이션들은 전역 상태에 대한 변경들을 포착하는 트랜잭션들을 제출하고, 이러한 트랜잭션들은 결국 원장 블록체인에 커밋된다. 애플리케이션들은 하이퍼레저® 패브릭 SDK에 의해 이러한 합의 메커니즘의 세부사항들로부터 격리되고; 그들은 단지 스마트 계약을 호출하고, 트랜잭션이 블록체인에 포함되었을 때 (유효이든 무효이든) 통지받는다. 주요 설계점은 배서 조직들의 요구된 세트에 의해 서명된 트랜잭션들만이 전역 상태에 대한 업데이트를 초래할 것이라는 점이다. 트랜잭션이 충분한 배서자들에 의해 서명되지 않은 경우, 그것은 전역 상태의 변경을 초래하지 않을 것이다.
상태는 버전 번호를 가지며, 위의 도면에서, 상태들(CAR1 및 CAR2)은 그들의 시작 버전(0)에 있다. 버전 번호는 하이퍼레저® 패브릭에 의한 내부적 사용을 위한 것이고, 상태가 변경될 때마다 증분된다. 버전은, 현재 상태들이 배서 시의 버전과 매칭함을 확실히 하기 위해 상태가 업데이트될 때마다 확인된다. 이는, 전역 상태가 예상되는 바와 같이 변경되고 있고, 동시적 업데이트가 존재하지 않았다는 것을 보장한다.
마지막으로, 원장이 처음 생성될 때, 전역 상태는 비어 있다. 전역 상태에 대한 유효한 변경을 표현하는 임의의 트랜잭션이 블록체인 상에 기록되기 때문에, 이는, 전역 상태가 임의의 시간에 블록체인으로부터 재생성될 수 있다는 것을 의미한다. 이는 매우 편리할 수 있는데, 예컨대, 피어가 생성될 때 전역 상태가 자동으로 생성된다. 더욱이, 피어가 비정상적으로 실패하는 경우, 트랜잭션들이 수락되기 전에, 피어 재시작 시에 전역 상태가 재생성될 수 있다.
전역 상태는 원장 상태들의 간단하고 효율적인 저장 및 검색을 제공하기 위해 데이터베이스로서 물리적으로 구현된다. 원장 상태들은 단순한 또는 복합적인 값들을 가질 수 있고, 이를 수용하기 위해, 전역 상태 데이터베이스 구현이 다양할 수 있어서, 이러한 값들이 효율적으로 구현될 수 있다. 전역 상태 데이터베이스에 대한 옵션들은 현재 LevelDB 및 카우치DB®를 포함한다.
LevelDB는 기본값이고, 원장 상태들이 단순한 키-값 쌍들일 때 특히 적절하다. LevelDB 데이터베이스는 네트워크 노드와 밀접하게 함께 공통-위치되는데, 즉, 그것은 동일한 운영 체제 프로세스 내에 내장된다.
카우치DB®는 원장 상태들이 JSON 문서들로서 구조화될 때 특히 적절한 선택인데, 그 이유는, 카우치DB®가 비즈니스 트랜잭션들에서 종종 발견되는 풍부한 질의들 및 더 풍부한 데이터 유형들의 업데이트를 지원하기 때문이다. 구현에 관하여, 카우치DB®는 별개의 운영 체제 프로세스에서 실행되지만, 피어 노드와 카우치DB® 인스턴스 사이에 여전히 1:1 관계가 존재한다. 이러한 것 모두는 스마트 계약에는 보이지 않는다.
LevelDB 및 카우치DB®에서, 하이퍼레저® 패브릭의 중요한 양상인, 그것이 플러그가능하다는 것을 볼 수 있다. 전역 상태 데이터베이스는 관계형 데이터 저장소, 또는 그래프 저장소, 또는 시간 데이터베이스일 수 있다. 이는, 효율적으로 액세스될 수 있는 원장 상태들의 유형들에서 큰 유연성을 제공하여, 하이퍼레저® 패브릭이 많은 상이한 유형들의 문제들을 해결할 수 있게 한다.
하이퍼레저® 패브릭에서, 각각의 채널은 완전히 별개인 원장을 갖는다. 이는, 완전히 별개인 블록체인, 및 이름공간들을 포함하여, 완전히 별개인 전역 상태들을 의미한다. 애플리케이션들 및 스마트 계약들이 채널들 사이에서 통신하는 것이 가능하며, 이에 따라, 원장 정보가 채널들 사이에서 액세스될 수 있다.
상태 데이터베이스로서의 카우치DB®
카우치DB®는 임의적인 대안적인 외부 상태 데이터베이스이다. 카우치DB®는 체인코드로 모델링되는 임의의 바이너리 데이터를 저장할 수 있다(카우치DB® 첨부 기능성은 비-JSON 바이너리 데이터에 대해 내부적으로 사용됨). 그러나, JSON 문서 저장소로서, 카우치DB®는 부가적으로, 체인코드 값들(예컨대, 자산들)이 JSON 데이터로서 모델링될 때, 체인코드 데이터에 대한 풍부한 질의를 가능하게 한다.
카우치DB®는 키(자산)를 획득하고 설정하는 것, 및 키들에 기반하여 질의하는 것과 같은 핵심 체인코드 동작들을 지원한다. 키들은 범위별로 질의될 수 있고, 복합 키들은 다수의 파라미터들에 대한 동등한 질의들을 가능하게 하도록 모델링될 수 있다. 예컨대, 소유자의 복합 키(asset_id)가 사용되어, 특정 엔티티가 소유한 모든 자산들에 대해 질의할 수 있다. 이러한 키 기반 질의들은 원장을 업데이트하는 트랜잭션들에서 뿐만 아니라, 원장에 대한 판독 전용 질의들에 사용될 수 있다.
JSON으로서 자산들을 모델링하고 카우치DB®를 사용하는 경우, 체인코드 내에서 카우치DB® JSON 질의 언어를 사용하여, 체인코드 데이터 값들에 대해 복잡하고 풍부한 질의들이 또한 수행될 수 있다. 이러한 유형들의 질의들은 원장 상에 무엇이 있는지를 이해하는 데 우수하다. 이러한 유형들의 질의들에 대한 제안 응답들은 전형적으로 클라이언트 애플리케이션에 유용하지만, 전형적으로, 순서화 서비스에 대한 트랜잭션들로서 제출되지 않는다. 실제로, 풍부한 질의들에 대해 체인코드 실행 시간과 커밋 시간 사이에서 결과 세트가 안정적이라는 보장이 존재하지 않으며, 따라서, 풍부한 질의들은, 애플리케이션이, 체인코드 실행 시간과 커밋 시간 사이에서 결과 세트가 안정적임을 보장할 수 없거나 후속 트랜잭션들에서의 잠재적 변경들을 처리할 수 없는 한, 업데이트 트랜잭션들에서 사용하기에 적절하지 않다. 예컨대, 앨리스(Alice)가 소유한 모든 자산들에 대해 풍부한 질의를 수행하고 그를 밥(Bob)에게 전달하는 경우, 새로운 자산이 체인코드 실행 시간과 커밋 시간 사이의 다른 트랜잭션에 의해 앨리스에게 배정될 수 있고, 이러한 "실체가 없는(phantom)" 항목은 누락될 것이다.
카우치DB®는 피어와 함께 별개의 데이터베이스 프로세스로서 실행되며, 따라서, 설정, 관리, 및 동작들의 관점에서 부가적인 고려사항들이 존재한다. 체인코드 자산 데이터를 JSON으로서 모델링하는 것이 양호한 관행이며, 이에 따라, 향후에 필요한 경우 복잡하고 풍부한 질의들을 수행하는 옵션이 있다.
체인코드로부터의 카우치DB®의 사용
체인코드 질의들
체인코드 심(shim) API들 대부분은 카우치DB® 상태 데이터베이스, 예컨대, GetState, PutState, GetStateByRange, GetStateByPartialCompositeKey와 함께 활용될 수 있다. 부가적으로, 체인코드에서 카우치DB®를 상태 데이터베이스로서 그리고 모델 자산들을 JSON으로서 활용할 때, GetQueryResult API를 사용하고 카우치DB® 질의 스트링을 전달함으로써 상태 데이터베이스 내의 JSON에 대해 풍부한 질의들이 수행될 수 있다. 질의 스트링은 CouchDB JSON 질의 구문을 따른다.
marbles02 패브릭 본보기는 체인코드에서의 카우치DB® 질의들의 사용을 시연한다. 그것은, 소유자 id를 체인코드로 전달함으로써 파라미터화된 질의들을 시연하는 queryMarblesByOwner() 함수를 포함한다. 이어서, 그것은 JSON 질의 구문을 사용하여 "marble"의 docType 및 소유자 id와 매칭되는 JSON 문서들에 대한 상태 데이터에 대해 질의한다:
카우치DB® 페이지 매기기
패브릭은 풍부한 질의들 및 범위-기반 질의들에 대한 질의 결과들의 페이징을 지원한다. 페이지 매기기를 지원하는 API들은 페이지 크기 및 북마크들의 사용이 범위 질의 및 풍부한 질의 둘 모두에 사용될 수 있게 한다. 효율적인 페이지 매기기를 지원하기 위해, 패브릭 페이지 매기기 API들이 사용되어야 한다. 구체적으로, 카우치DB® 제한 키워드는 카우치DB® 질의들에서 준수(honor)되지 않을 것인데, 그 이유는, 패브릭 그 자체가 질의 결과들의 페이지 매기기를 관리하고, 카우치DB®에 전달되는 페이지크기(pageSize) 제한을 암시적으로 설정하기 때문이다.
페이지크기가 페이지가 매겨진 질의 API들(GetStateByRangeWithPagination(), GetStateByPartialCompositeKeyWithPagination(), 및 GetQueryResultWithPagination())을 사용하여 특정되는 경우, 결과들의 세트(페이지크기에 의해 제한됨)가 북마크와 함께 체인코드에 반환될 것이다. 북마크는 체인코드로부터 호출 클라이언트들로 반환될 수 있으며, 호출 클라이언트들은 후속 질의의 북마크를 사용하여 결과들의 다음 "페이지"를 수신할 수 있다.
페이지 매기기 API들은 판독 전용 트랜잭션에서만 사용하기 위한 것이며, 질의 결과들은 클라이언트 페이징 요건들을 지원하도록 의도된다. 판독 및 기입을 필요로 하는 트랜잭션들의 경우, 페이지가 매겨지지 않은 체인코드 질의 API들을 사용한다. 체인코드 내에서, 결과 세트들을 통해 원하는 깊이로 반복될 수 있다.
페이지 매기기 API들이 활용되는지 여부에 관계없이, 모든 체인코드 질의들은 core.yaml로부터의 totalQueryLimit(기본값 100000)에 의해 제한된다. 이는, 우연한 또는 악의적인 장기 실행 질의들을 피하기 위해, 체인코드가 반복하고 클라이언트로 반환할 최대 결과 수이다.
카우치DB® 인덱스들
카우치DB®의 인덱스들은 JSON 질의들을 효율적이게 하기 위해 요구되고, 한 종류의 임의의 JSON 질의에 대해 요구된다. 인덱스들은 /META-INF/statedb/couchdb/indexes 디렉토리에서 체인코드와 함께 패키징될 수 있다. 각각의 인덱스는 CouchDB 인덱스 JSON 구문에 따라 JSON으로 포맷팅된 인덱스 정의를 갖는 확장자가 *.json인 자신 고유의 텍스트 파일에 정의되어야 한다. 예컨대, 위의 marble 질의를 지원하기 위해, docType 및 소유자 필드들 상의 본보기 인덱스가 제공된다:
체인코드의 META-INF/statedb/couchdb/indexes 디렉토리 내의 임의의 인덱스는 배치를 위해 체인코드와 함께 패키징될 것이다. 체인코드가 피어 상에 설치될 뿐만 아니라 피어의 채널들 중 하나 상에 인스턴스화될 때, 인덱스는 (그것이 카우치DB®를 사용하도록 구성된 경우) 피어의 채널 및 체인코드 특정 상태 데이터베이스에 자동으로 배치될 것이다. 체인코드를 먼저 설치한 다음 채널 상에 체인코드를 인스턴스화하는 경우, 인덱스는 체인코드 인스턴스화 시간에 배치될 것이다. 체인코드가 채널 상에 이미 인스턴스화되어 있고 나중에 체인코드를 피어 상에 설치하는 경우, 인덱스는 체인코드 설치 시간에 배치될 것이다.
배치 시, 인덱스는 체인코드 질의들에 의해 자동으로 활용될 것이다. 카우치DB®는, 질의에서 사용되고 있는 필드들에 기반하여 어느 인덱스를 사용할지를 자동으로 결정할 수 있다. 대안적으로, 선택자 질의에서, 인덱스는 use_index 키워드를 사용하여 특정될 수 있다.
동일한 인덱스가, 설치된 체인코드의 후속 버전들에 존재할 수 있다. 인덱스를 변경하기 위해, 동일한 인덱스 이름을 사용하지만 인덱스 정의를 변경한다. 설치/인스턴스화 시에, 인덱스 정의는 피어의 상태 데이터베이스로 재배치될 것이다.
이미 대량의 데이터를 갖고, 나중에 체인코드를 설치하는 경우, 설치 시의 인덱스 생성은 시간을 약간 소요할 수 있다. 유사하게, 이미 대량의 데이터를 갖고, 체인코드의 후속 버전을 인스턴스화하는 경우, 인덱스 생성은 시간을 약간 소요할 수 있다. 인덱스가 초기화되는 동안 체인코드 질의가 시간초과될 수 있으므로, 이러한 시간들에 상태 데이터베이스에 대해 질의하는 체인코드 기능들을 호출하는 것을 피한다. 트랜잭션 처리 동안, 블록들이 원장에 커밋되는 경우 인덱스들은 자동으로 리프레시될 것이다.
카우치DB® 구성
카우치DB®는 상태 데이터베이스 구성 옵션을 goleveldb로부터 카우치DB®로 변경함으로써 상태 데이터베이스로서 인에이블링된다. 부가적으로, couchDBAddress는 피어에 의해 사용될 카우치DB®를 가리키도록 구성될 필요가 있다. 카우치DB®가 사용자명 및 패스워드로 구성되는 경우, 사용자명 및 패스워드 특성들은 관리자 사용자명 및 패스워드로 채워져야 한다. 부가적인 옵션들이 couchDBConfig 섹션에서 제공되고 적소에 문서화된다. core.yaml에 대한 변경들은 피어를 재시작한 직후에 유효할 것이다.
또한, core.yaml 값들, 예컨대, CORE_LEDGER_STATE_STATEDATABASE 및 CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS를 오버라이딩하기 위해 도커(docker) 환경 변수들을 전달할 수 있다.
이하는, core.yaml로부터의 stateDatabase 섹션이다:
상태:
# stateDatabase - 옵션들은 "goleveldb", "CouchDB"임
# goleveldb - goleveldb에 저장된 기본 상태 데이터베이스
# CouchDB - CouchDB 내의 저장 상태 데이터베이스
stateDatabase: goleveldb
# 질의별 반환할 기록들의 수에 대한 제한
totalQueryLimit: 10000
couchDBConfig:
# 피어와 동일한 서버 상에서 CouchDB를 실행하도록 추천되고,
# CouchDB 컨테이너 포트를 도커 컴포즈(docker-compose) 내의 서버 포트에 맵핑하지 않음
# 그렇지 않으면, 적절한 보안이 다음 사이의 연결에 제공되어야 함
# (피어 상의) CouchDB 클라이언트 및 서버
couchDBAddress: couchdb:5984
# 이 사용자명은 CouchDB 상에서 판독 및 기입 권한을 가져야 함
사용자명:
# 시동 동안 패스워드는 환경 변수로서 전달하도록 추천됨
# (예컨대, LEDGER_COUCHDBCONFIG_PASSWORD)
# 여기에 저장되는 경우, 파일은 액세스 제어 보호되어야 하며,
# 의도되지 않은 사용자들이 패스워드를 발견하는 것을 방지하기 위해서임
패스워드:
# CouchDB 오류들에 대한 재시도들의 수
maxRetries: 3
# 피어 시동 동안의 CouchDB 오류들에 대한 재시도들의 수
maxRetriesOnStartup: 10
# CouchDB 요청 시간초과(단위: 지속기간, 예컨대 20 초)
requestTimeout: 35s
# 각각의 CouchDB 질의별 기록들의 수에 대한 제한
# 체인코드 질의들은 totalQueryLimit에 의해서만 제한됨
# 내부적으로, 체인코드는 다수의 CouchDB 질의들을 실행할 수 있음
# 각각은 크기 internalQueryLimit를 가짐
internalQueryLimit: 1000
# CouchDB 벌크 업데이트 배치별 기록들의 수에 대한 제한
maxBatchUpdateSize: 1000
# 매 N개의 블록들 후에 인덱스들을 워밍(warm)함
# 이 옵션은 다음과 같은 임의의 인덱스들을 워밍함
# 매 N개의 블록들 후에 CouchDB에 배치된 임의의 인덱스들
# 1의 값은 매 블록 커밋 후에 인덱스들을 워밍할 것이며,
# 빠른 선택자 질의들을 보장하기 위해서임
# 값을 증가시키는 것은 피어 및 CouchDB의 기입 효율을 개선할 수 있음
# 그러나 그것은 질의 응답 시간을 저하시킬 수 있음
warmIndexesAfterNBlocks: 1
하이퍼레저® 패브릭과 함께 공급되는 도커 컨테이너들에서 호스팅되는 카우치DB®는 도커 컴포즈 스크립팅을 사용하여 COUCHDB_USER 및 COUCHDB_PASSWORD 환경 변수들과 함께 전달되는, 환경 변수들을 갖는 카우치DB® 사용자명 및 패스워드를 설정하는 능력을 갖는다.
패브릭과 함께 공급되는 도커 이미지들 외부의 카우치DB® 설치들의 경우, 그 설치의 local.ini 파일은 관리자 사용자명 및 패스워드를 설정하기 위해 편집되어야 한다.
도커 컴포즈 스크립트들은 컨테이너의 생성 시 사용자명 및 패스워드만을 설정한다. local.ini 파일은 컨테이너의 생성 후에 사용자명 또는 패스워드가 변경되어야 하는 경우 편집되어야 한다.
카우치DB® 피어 옵션들은 각각의 피어 시동 시에 판독된다.
신원
블록체인 네트워크 내의 상이한 행위자들은 피어들, 오더러들, 클라이언트 애플리케이션들, 관리자들 및 그 이상을 포함한다. 이러한 행위자들 ― 서비스들을 소비할 수 있는 네트워크 내부 또는 외부의 능동 요소들 ― 각각은 X.509 디지털 인증서에 캡슐화된 디지털 신원을 갖는다. 이러한 신원들은, 그들이 블록체인 네트워크에서 행위자들이 갖는 정보에 대한 액세스 및 리소스들에 대한 정확한 허가들을 결정하기 때문에 매우 중요하다.
디지털 신원은 또한, 패브릭이 허가들을 결정하기 위해 사용하는 일부 부가적인 속성들을 가지며, 그것은, 신원 및 연관된 속성의 결합에 특수한 이름 ― 주 대상(principal) ― 을 제공한다. 주 대상들은 userID들 또는 groupID들과 마찬가지이지만 약간 더 유연한데, 그 이유는, 그들이, 행위자의 조직, 조직 유닛, 역할 또는 심지어 행위자의 특정 신원과 같은, 행위자의 신원의 광범위한 특성들을 포함할 수 있기 때문이다. 주 대상들에 관해 말하자면, 이들은, 그들의 허가들을 결정하는 특성이다.
신원이 검증가능하기 위해서는, 신원은 신뢰되는 기관으로부터 비롯되어야 한다. 멤버쉽 서비스 제공자(MSP)는 이것이 패브릭에서 달성되는 방식이다. 더 구체적으로, MSP는 이 조직에 대한 유효한 신원들을 통제하는 규칙들을 정의하는 구성요소이다. 패브릭에서의 기본 MSP 구현은 X.509 인증서들을 신원들로서 사용하여, 종래의 공개 키 기반구조(PKI) 계층적 모델을 채택한다(PKI에 대해서는 나중에 더 상세히 다룸).
신원의 사용을 설명하기 위한 간단한 시나리오
약간의 식료품들을 구매하기 위해 슈퍼마켓을 방문한다고 가정해 본다. 계산대에서, 비자(Visa), 마스터카드(Mastercard) 및 아멕스(AMEX) 카드들만이 인정된다고 말하는 표시를 볼 수 있다. 상이한 카드 ― 이를 "상상한 카드"로 지칭함 ― 로 지불하려고 시도하는 경우, 그 카드가 진품인지 그리고 계좌에 충분한 자금이 있는지 여부는 중요하지 않다. 그 카드는 인정되지 않을 것이다.
도 24는 유효한 신용 카드를 갖는 것으로 충분하지 않고 그것이 또한 상점에 의해 인정되어야 함을 예시한다! PKI들 및 MSP들은 동일한 방식으로 함께 동작하는데, PKI는 신원들의 목록을 제공하고, MSP는 이들 중 어느 것이 네트워크에 참여하는 주어진 조직의 구성원들인지를 알려준다.
PKI 인증 기관들 및 MSP들은 유사한 기능 조합들을 제공한다. PKI는 카드 제공자와 유사한데, 많은 상이한 유형들의 검증가능한 신원들을 배포한다. MSP는 반면에, 어느 신원들이 상점 지불 네트워크의 신뢰되는 구성원들(행위자들)인지를 결정하는, 상점에 의해 수락되는 카드 제공자들의 목록과 유사하다. MSP들은 검증가능한 신원들을 블록체인 네트워크의 구성원들로 전환한다.
PKI들
공개 키 기반구조(PKI)는 네트워크에서 보안 통신들을 제공하는 인터넷 기술들의 집합이다.
도 25는 공개 키 기반구조(PKI)의 요소들을 예시한다. PKI는 당사자들(예컨대, 서비스의 사용자들, 서비스 제공자)에게 디지털 인증서들을 발행하는 인증 기관들로 구성되며, 당사자들은 그 후, 그들이 자신의 환경과 교환하는 메시지들에서 스스로를 인증하기 위해 그 디지털 인증서들을 사용한다. CA의 인증서 폐지 목록(CRL)은 더 이상 유효하지 않은 인증서들에 대한 참조를 구성한다. 인증서의 폐지는 다수의 이유들로 발생할 수 있다. 예컨대, 인증서는, 인증서에 연관된 암호화 비공개 자료가 노출되었기 때문에 폐지될 수 있다.
블록체인 네트워크는 통신 네트워크 그 이상이지만, 블록체인 네트워크는, 다양한 네트워크 참여자들 사이의 보안 통신을 보장하고, 블록체인 상에 게시된 메시지들이 적절히 인증되는 것을 보장하기 위해 PKI 표준에 의존한다. 따라서, PKI의 기본들 및 MSP들이 왜 그렇게 중요한지를 이해하는 것이 중요하다.
PKI에 대한 4개의 주요 요소가 존재한다:
● 디지털 인증서들
● 공개 및 비공개 키들
● 인증 기관들
● 인증서 폐지 목록들
디지털 인증서들
디지털 인증서는, 인증서의 보유자와 관련된 속성들의 세트를 보유하는 문서이다. 가장 흔한 유형의 인증서는 X.509 표준을 준수하는 인증서인데, 이는, 그의 구조에 당사자의 식별 세부사항들을 인코딩하는 것을 허용한다.
예컨대, 미시간(Michigan) 주 디트로이트(Detroit)에 있는 미첼 자동차(Mitchell Cars)의 제조 부서에 있는 메리 모리스는, C=US, ST=미시간, L=디트로이트, O=미첼 자동차, OU=제조, CN=메리 모리스/UID=123456의 대상(SUBJECT) 속성을 갖는 디지털 인증서를 가질 수 있다. 메리의 인증서는 메리의 정부 신원 카드와 유사한데, 그것은, 메리가 자신에 대한 주요 사실들을 증명하기 위해 사용할 수 있는 자신에 관한 정보를 제공한다.
도 26은 메리 모리스로 지칭되는 당사자를 기술하는 디지털 인증서를 예시한다. 메리는 인증서의 SUBJECT이고, 강조된 SUBJECT 텍스트는 메리에 관한 주요 사실을 보여준다. 인증서는 또한, 볼 수 있는 바와 같은 더 많은 정보 조각들을 보유한다. 가장 중요하게는, 메리의 공개 키는 메리의 인증서 내에서 배포되는 반면, 메리의 비공개 키는 그렇지 않다. 이러한 서명 키는 비공개로 유지되어야 한다.
중요한 것은, 메리의 속성들 모두가, 위조가 인증서를 무효화하도록 암호화(문자 그대로, "비밀로 작성")로 지칭되는 수학적 기법을 사용하여 기록될 수 있다는 것이다. 암호화는, 다른 당사자가 인증 기관(CA)으로 알려져 있는 인증서 발행자를 신뢰하는 한, 메리가 자신의 신원을 증명하기 위해 자신의 인증서를 다른 사람들에게 제시할 수 있게 한다. CA가 특정 암호화 정보(자신 고유의 비공개 서명 키를 의미함)를 안전하게 유지하는 한, 인증서를 판독하는 누구라도 메리에 관한 정보가 위조되지 않았음을 확신할 수 있을 것인데, 이는, 메리 모리스에 대한 그 특정 속성들을 항상 가질 것이다. 메리의 X.509 인증서를 변경하는 것이 불가능한 디지털 신원 카드로 생각해 본다.
인증, 공개 키들, 및 비공개 키들
인증 및 메시지 무결성은 보안 통신들에서 중요한 개념들이다. 인증은 메시지들을 교환하는 당사자들에게 특정 메시지를 생성한 신원이 보장될 것을 요구한다. 메시지가 "무결성"을 갖는다는 것은, 메시지의 송신 동안 수정될 수 없다는 것을 의미한다. 예컨대, 위장자(impersonator)가 아니라 실제 메리 모리스와 통신하고 있다는 것을 확신하기를 원할 수 있다. 또는, 메리가 메시지를 전송한 경우, 송신 동안 다른 누군가에 의해 메시지가 위조되지 않았음을 확신하기를 원할 수 있다.
종래의 인증 메커니즘들은, 이름이 시사하는 바와 같이, 당사자가 그의 메시지들을 디지털 방식으로 서명할 수 있게 하는 디지털 서명들에 의존한다. 디지털 서명들은 또한 서명된 메시지의 무결성에 대한 보장을 제공한다.
기술적으로 말하면, 디지털 서명 메커니즘들은 각각의 당사자가 2개의 암호화 방식으로 연결된 키, 즉, 널리 이용가능하게 되고 인증 앵커로서의 역할을 하는 공개 키, 및 메시지들 상에 디지털 서명들을 생성하는 데 사용되는 비공개 키를 보유할 것을 요구한다. 디지털 방식으로 서명된 메시지들의 수신자들은, 첨부된 서명이 예상 전송자의 공개 키 하에서 유효한지를 확인함으로써, 수신된 메시지의 출처 및 무결성을 검증할 수 있다.
비공개 키와 개개의 공개 키 사이의 고유한 관계는 보안 통신들을 가능하게 하는 암호화 기술이다. 키들 사이의 고유한 수학적 관계는, 비공개 키가 대응하는 공개 키만이 매칭할 수 있는 메시지 상에 그리고 동일한 메시지 상에만 서명을 생성하는데 사용될 수 있도록 이루어진다.
도 27에 예시된 예에서, 메리는 메시지에 서명하기 위해 자신의 비공개 키를 사용한다. 메리의 공개 키를 사용하여 서명된 메시지를 보는 누구라도 서명을 검증할 수 있다.
인증 기관들
행위자 또는 노드는, 시스템에 의해 신뢰되는 기관에 의해 그에 대해 발행된 디지털 신원의 수단을 통해 블록체인 네트워크에 참여할 수 있다. 가장 흔한 경우에서, 디지털 신원들(또는 간단히 신원들)은 X.509 표준을 준수하고 인증 기관(CA)에 의해 발행되는 암호화 방식으로 검증된 디지털 인증서들의 형태를 갖는다.
CA들은, 다른 것들 중에서도, 시만텍(Symantec)(원래, 베리사인(Verisign)), 지오트러스트(GeoTrust), 디지서트(DigiCert), 고대디(GoDaddy), 및 코모도(Comodo)와 같은 인터넷 보안 프로토콜들의 공통 부분이다.
도 28은 상이한 행위자들에게 인증서를 배포하는 인증 기관을 예시한다. 이러한 인증서들은 CA에 의해 디지털 방식으로 서명되고 행위자를 행위자의 공개 키와(그리고 임의적으로는, 특성들의 포괄적인 목록과) 함께 결속시킨다. 결과적으로, CA가 신뢰되는 경우(그리고 그의 공개 키를 알고 있는 경우), 행위자의 인증서에 대한 CA의 서명을 검증함으로써, 특정 행위자가 인증서에 포함된 공개 키에 결속되고, 포함된 속성들을 소유한다는 것이 신뢰될 수 있다.
인증서들이 행위자들 비공개 키 또는 CA의 비공개 키 중 어느 것도 포함하지 않기 때문에, 인증서들은 널리 유포될 수 있다. 그러므로, 인증서들은 상이한 행위자들로부터 오는 메시지들을 인증하기 위한 신뢰 앵커로서 사용될 수 있다.
CA들은 또한, 그들이 널리 이용가능하게 만든 인증서를 갖는다. 이는, 주어진 CA에 의해 발행된 신원들의 소비자들이, 인증서가 대응하는 비공개 키의 보유자(CA)에 의해서만 생성되었을 수 있다는 것을 확인함으로써 그들을 검증할 수 있게 한다.
블록체인 설정에서, 네트워크와 상호작용하기를 희망하는 모든 각각의 행위자는 신원을 필요로 한다. 이러한 설정에서, 하나 이상의 CA가 디지털 관점에서 조직의 구성원들을 정의하는데 사용될 수 있다고 말할 수 있다. CA는, 조직의 행위자들이 검증가능한 디지털 신원을 갖기 위한 기초를 제공하는 것이다.
루트 CA들, 중간 CA들, 및 신뢰 체인들
CA들은 2개의 종류(flavor), 즉, 루트 CA들 및 중간 CA들로 나타난다. 루트 CA들(시만텍, 지오트러스트 등)은 인터넷 사용자들에게 수억 개의 인증서들을 안전하게 분배해야 하기 때문에, 이러한 프로세스를 중간 CA들로 지칭되는 것들에 걸쳐 분산시키는 것이 타당하다. 이러한 중간 CA들은 루트 CA 또는 다른 중간 기관에 의해 발행된 그들의 인증서들을 가져서, 체인 내의 임의의 CA에 의해 발행되는 임의의 인증서에 대한 "신뢰 체인"의 설정을 허용한다. 루트 CA로 다시 추적하는 이러한 능력은 CA들의 기능을 확장할 뿐만 아니라 여전히 보안을 제공할 수 있게 하여, 인증서들을 소비하는 조직들이 신뢰를 갖는 중간 CA들을 사용할 수 있게 하는데, 이는, 손상되는 경우 전체 신뢰 체인을 위험에 빠뜨릴 루트 CA의 노출을 제한한다. 반면에, 중간 CA가 손상되는 경우, 훨씬 더 작은 노출이 존재할 것이다.
도 29는, 루트 CA와 중간 CA들의 세트 사이에, 이러한 중간 CA들 각각의 인증서에 대한 발행 CA가 루트 CA 그 자체이거나 루트 CA에 대한 신뢰 체인을 갖는 한 설정되는 신뢰 체인을 예시한다.
중간 CA들은, 그것이 다수의 조직들에 걸쳐 인증서들을 발행하게 될 때 엄청난 양의 유연성을 제공하며, 이는, (패브릭과 같은) 허가된 블록체인 시스템에서 매우 도움이 된다. 예컨대, 상이한 조직들은 상이한 루트 CA들, 또는 상이한 중간 CA들을 갖는 동일한 루트 CA를 사용할 수 있는데, 이는 실제로 네트워크의 요구들에 의존한다.
패브릭 CA
패브릭은, 사용자들이, 형성되는 블록체인 네트워크들에서 CA들을 생성할 수 있게 하기 위해, 내장된 CA 구성요소를 제공한다. 패브릭 CA로 알려져 있는 이러한 구성요소는, X.509 인증서들의 형태를 갖는 패브릭 참여자들의 디지털 신원들을 관리할 수 있는 비공개 루트 CA 제공자이다. 패브릭 CA가 패브릭의 루트 CA 요구들을 표적으로 하는 맞춤 CA이기 때문에, 그것은 본질적으로 브라우저들에서의 일반적/자동적 사용을 위한 SSL 인증서들을 제공할 수 없다. 그러나, 일부 CA는 (심지어 테스트 환경에서도) 신원을 관리하는 데 사용되어야 하기 때문에, 패브릭 CA는 인증서들을 제공하고 관리하는 데 사용될 수 있다. 공개/상업용 루트 또는 중간 CA를 사용하여 신원증명(identification)을 제공하는 것이 또한 가능하고, 충분히 적절하다.
인증서 폐지 목록들
인증서 폐지 목록(CRL)은, CA가 하나의 이유 또는 다른 이유로 폐지된 것으로 알고 있는 인증서들에 대한 참조들의 목록이다. 상점 시나리오에서, CRL은 도난된 신용 카드들의 목록과 유사한 것일 것이다.
제3자가 다른 당사자의 신원을 검증하기를 원할 때, 제3자는 먼저 인증서가 폐지되지 않았음을 확실히 하기 위해 발행 CA의 CRL을 확인한다. 검증자가 CRL을 확인할 필요는 없지만, 검증자가 그렇게 하지 않는 경우, 그들은 손상된 신원을 수락할 위험이 있다.
도 30은 인증서가 여전히 유효하다는 것을 확인하기 위해 CRL을 사용하는 것을 예시한다. 위장자가 검증 당사자에게 손상된 디지털 인증서를 전달하려고 시도하는 경우, 검증 당사자는 먼저 발행 CA의 CRL에 대해 확인하여, 그 인증서가 더 이상 유효하지 않은 것으로 열거되지 않은지를 확실히 할 수 있다.
폐지되는 인증서는 만료되는 인증서와 매우 상이하다는 것을 유의한다. 폐지된 인증서들은 만료되지 않았으며, 그들은, 다른 모든 각각의 척도에 의해서는 완전히 유효한 인증서이다.
참조들
패브릭 및 카우치DB®에 관한 위의 정보는 다음의 링크들에서 공개적으로 이용가능한 소스들로부터 취해졌다:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/fabric_model.html#
https://kaleido.io/enterprise-blockchain-protocols-ethereum-vs-fa
https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html#applications-and-peers
https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html#world-state-database-options
https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_as_state_database.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html#identity
https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html#fabric-ca
부록 B
관계형 데이터 액세스 제어
최고 관리자: 루트 허가
ELEMENT 내의 모든 다른 활동에 대한 전제조건은, 데이터베이스의 생성 및 그 데이터베이스에 대한 동작들을 수행하기 위한 적어도 하나의 신원의 권한부여이다. "최고 관리자" 액세스 수준은 이를 행하기 위한 허가를 승인한다.
데이터베이스의 구현이 고도로 플랫폼 특정적일 것이기 때문에, 그 존재 이외에 이러한 허가 수준에 대한 플랫폼-독립적 규격들은 존재하지 않는다.
ELEMENT 액세스 수준들
ELEMENT 시스템에서의 나머지 사용자 액세스 수준들은 데이터베이스별 기반으로 승인된다.
관계형 데이터 액세스 제어 관리는, ELEMENT에 성공적으로 등록할 시 분산형 원장 신원에 배정된 특정 고유 속성들에 기반한다. ELEMENT를 사용하는 모든 분산형 원장 신원들은 이러한 속성들에 기반하여 범주화되고 검증된다. 사용자들의 분류는, 특정 데이터베이스에 대한 그들의 신원에 기반하여, ELEMENT에 의해 승인된 동작 범위를 결정한다.
도 31은 액세스 수준들 및 허가 결정을 예시한다.
ELEMENT에는 5개의 액세스 수준이 존재하고, 그 수준들에 대한 개개의 특권들이 아래에서 논의된다.
최고 관리자
논의된 바와 같이, 최고 관리자는 ELEMENT에 대한 루트 허가 수준이고, 데이터베이스들의 생성을 포함하는 모든 동작들에 대한 허가를 갖는다:
- 데이터베이스 생성/드롭
- 특정/다수의 데이터베이스들에 대한 관리자 사용자의 임명/제거
- 특정/다수의 데이터베이스들에서의 사용자들의 추가/제거
- 네트워크에 걸친 모든 사용자들 및 사용자 정보 보기
- DDL 동작들의 수행
- DML 판독/기입 동작들의 수행
관리자
관리자 액세스 수준은 특정된 데이터베이스 내에서 가장 높은 특권들을 갖는 사용자이다. 관리자들은 최고 관리자 사용자에 의해 ELEMENT 데이터베이스에 대해 임명/등록된다. 관리자 액세스 수준에 대한 특권들은 다음과 같다:
- 배정된 데이터베이스에 대한 사용자들의 추가/제거
- 배정된 데이터베이스에 걸친 모든 사용자들 및 사용자 정보 보기
- DDL 동작들의 수행
- DML 판독/기입 동작들의 수행
비고: 관리자 사용자는 특정된 데이터베이스에 대해 더 많은 관리자들을 추가/제거할 수 있다.
DDL
이 액세스 수준은 사용자가 DML 동작들과 함께 특정 DDL 동작들(더 많은 세부사항들에 대해서는 ELEMENT SQL 규격 참조)을 수행할 수 있게 한다. 그렇지만, 이러한 액세스 수준 이하로부터 어떠한 사용자들의 추가도 허가되지 않는다.
- 특정된 데이터베이스 내의 ELEMENT 테이블들, 스키마들, 및 열들(인덱스들)의 생성/변경/드롭과 같은 DDL 동작들을 수행한다.
- DML 판독/기입 동작들의 수행
DML 기입
이 액세스 수준의 사용자들은 다음과 같은 특정 DML 기능들을 수행할 수 있다:
- ELEMENT 테이블에 대한 기록들의 삽입/업데이트/삭제
- LIMIT 및 OPSTAT와 같은 ELEMENT SQL 확장들이 DML 기입 동작들과 함께 사용될 수 있음 (ELEMENT SQL 규격들 참조)
DML 판독
DML 판독 액세스 수준은 사용자들이 데이터를 판독하는 것을 가능하게 하는 가장 기본적인 액세스이다. 이 수준의 사용자들은 데이터베이스의 임의의 데이터를 수정하는 것에 대한 액세스를 갖지 않는다. 이 액세스 수준에서 다음의 동작들이 수행될 수 있다:
- 특정된 데이터베이스로부터의 다양한 기록들의 선택 및 데이터의 오름차순 또는 내림차순으로 배열
- BOOKMARK, QUERYLEVEL, 및 LIMIT와 같은 ELEMENT SQL 확장들이 DML 판독 동작들과 함께 사용될 수 있음 (ELEMENT SQL 규격들 참조)
- 특정된 데이터베이스 내의 테이블들 및 테이블 세부사항들 보기
비고: CREATE 및 DROP 데이터베이스 DDL 동작들은 관리자 액세스 수준 및 관리자 아래의 모든 액세스 수준들에 대해 디스에이블링된다. 사용자가 이러한 동작들 중 임의의 것을 실행하려고 시도하는 경우, ELEMENT 시스템은 오류 - 403: 액세스 거부됨을 반환해야 한다.
사용자 등록
ELEMENT 시스템(v1.0)은 초대 전용 등록 시스템을 갖는다. 등록 프로세스는 공개되지 않는데, 최고 관리자만이 ELEMENT 데이터베이스를 사용하도록 새로운 사용자들을 추가할 특권을 가진다. 후속하여, 최고 관리자는 데이터베이스 소유자들(관리자들)을 배정할 수 있고, 그 소유자들은 그 특정 데이터베이스에 다른 사용자들을 더 추가할 수 있다. ELEMENT 사용자들은 분산형 원장 네트워크 상의 신원들의 기존 풀로부터 반드시 구축될 필요가 있는데, 그 이유는, ELEMENT 동작들이 분산형 원장 네트워크 능력들을 기초로 구축되기 때문이다.
사용자 등록은 사용자 등록(*Register User) ELEMENT API에 의해 처리되고, 이는 또한, ELEMENT 사용자 인터페이스를 통해 액세스가능하도록 특정되며, 여기서, 최고 관리자 및 관리자 액세스 수준들은 수동으로 데이터베이스들에 대한 사용자 액세스를 승인할 수 있다.
엔드포인트: http://<domain>:3000/api/user/register
API에 대한 요청 본문은 3개의 필수 파라미터를 포함한다:
1. username: 구성원에 대한 고유/비-기존 이름
2. database_id: 기존 데이터베이스의 이름
3. access_level: 구성원에 대한 액세스 특권들이며, 이 필드는 다음의 허용된 값들을 가질 수 있음 - "DDL", "DML_WRITE", "DML_READ", "ADMIN"
본보기 사용자 등록 요청 본문:
일단 등록이 성공적으로 행해지면(성공 응답들 및 가능한 오류들에 대해서는 ELEMENT™ API 규격 문서를 참조), 분산형 원장에 대한 동작을 건의하기 위해 ELEMENT 실현이 요구된다. 이러한 동작은 특정된 데이터베이스의 메타데이터 상에 사용자 정보를 부가한다. (데이터베이스 내의 사용자명들은 "사용자들"로 지칭되는 어레이로 저장된다.)
사용자 취소(REVOKE USER)
최고 관리자 및 관리자 액세스 수준들은 특정 데이터베이스/다수의 데이터베이스로부터 특정 사용자를 디스에이블링하는 것을 선택할 수 있다. 이는 네트워크 상의 다수의 데이터베이스들에 대한 선택적 사용자 액세스를 가능하게 한다.
적절한 특한들을 갖는 액세스 수준들은 사용자 취소 ELEMENT API를 사용함으로써 사용자를 디스에이블링할 수 있다.
엔드포인트: http://<domain>:3000/api/user/revoke
API에 대한 요청 본문은 2개의 필수 파라미터를 포함한다:
1. username: 구성원에 대한 정확한 이름
2. database_id: 구성원이 그 일부인 기존 데이터베이스의 이름
본보기 사용자 취소 요청 본문:
일단 취소 요청이 실행되면, invokeTransaction() 함수를 통해 revokeUser() 함수가 호출된다. revokeUser() 함수는 표적화된 데이터베이스로부터 관심 사용자의 메타데이터를 제거한다. (사용자는 데이터베이스의 "사용자들" 어레이로부터 제거된다.)
사용자 삭제(DELETE USER)
최고 관리자 액세스 수준은 네트워크로부터 사용자를 완전히 제거할 특권을 갖는다. 이는, 사용자 삭제 ELEMENT API를 사용함으로써 달성될 수 있다.
사용자가 삭제될 때, 신원이 그 일부인 모든 데이터베이스들로부터 관련 메타데이터가 제거된다. 메타데이터 외에도, 네트워크 상의 사용자의 디지털 신원이 또한 완전히 소거된다.
엔드포인트: http://<domain>:3000/api/user/delete
API에 대한 요청 본문은 1개의 필수 파라미터를 포함한다:
1. username: 구성원에 대한 정확한 이름
본보기 사용자 삭제 요청 본문:
부록 C
분산형 원장 상의 관계형 데이터 - 고수준 요건들
분산형 원장들 및 합의
관계형 데이터는 스마트 계약들에 액세스가능해야 한다.
관계형 데이터에 대한 첨부된 업데이트들은 정규 분산형 원장 데이터에 대한 첨부된 업데이트들에 사용되는 것과 동등한 합의 메커니즘에 의해 통제된다.
데이터를 수정하는 관계형 데이터 동작들은 분산형 원장에 로그처리되어야 한다. 스키마들을 수정하는 관계형 데이터 동작들이 또한 분산형 원장에 로그처리되어야 한다.
관계형 데이터는 가능한 경우 분산형 원장 내에 저장될 것이며, 분산형 원장 데이터와 동일한 수준의 변경불가능성 및 위조-입증(tamper-evidence)을 달성해야 한다.
관계형 스키마 정보는 가능한 경우 분산형 원장 내에 저장될 것이다.
로컬 대안들이 이용가능한 경우, 관계형 인덱스들은 분산형 원장 내에 저장되지 않을 것이다.
스키마들 및 인덱싱
테이블 스키마들은 단일 필드 고유 기본 키들을 지원한다. 테이블의 현재 상태에 대한 기본 키의 비-클러스터링 인덱싱이 지원될 것이다.
데이터 가시성
데이터, 스키마들, 및 로그처리된 동작들은, 규격 "관계형 데이터 액세스 제어"에서 권한부여된 신원들을 제외하고는, 휴지 상태에서 또는 전송 동안에 암호화되지 않은 형태로 가시적이지 않다.
데이터 및 동작 표현
관계형 데이터 및 로그처리된 관계형 데이터 동작들은 특정된 포맷들로 JSON으로서 분산형 원장(또는 위에 설명된 바와 같은 등가물) 상에 표현된다.
도 32는 데이터 및 동작 객체들의 개관을 예시한다.
───────────────────────────────────
ELEMENT 관계형 데이터 객체들
부록 D
ELEMENT API: 정의들
ELEMENT API에 의해 지원되는 기능들은 다음과 같다
데이터베이스 API들:
데이터베이스 생성
게시
https://<element_base_url>/api/1.0/database/create
허가: ELEMENT™ 관리자, 또는 관리자 또는 DDL 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
데이터베이스 드롭
게시
https://<element_base_url>/api/1.0/database/drop
허가: ELEMENT™ 관리자, 또는 관리자 또는 DDL 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
데이터베이스 보여주기
획득
https://<element_base_url>/api/1.0/database/show
허가: ELEMENT™ 관리자 또는 임의의 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
테이블 API들:
테이블 생성
게시
https://<element_base_url>/api/1.0/table/create
허가: DDL 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
테이블 변경
게시
https://<element_base_url>/api/1.0/table/alter
허가: DDL 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
일반적인 요청 본문
● 일반적인 요청-예:
요청 본문 - 열 부가
● 열 부가 요청-예:
요청 본문 - 열 드롭
● 열 드롭 요청-예
요청 본문 - 열 수정
● 열 수정 요청-예:
요청 본문 - 열 재명명
● 열 재명명 요청-예:
●
테이블 드롭
게시
https://<element_base_url>/api/1.0/table/drop
허가: DDL 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
테이블 보여주기
획득
https://<element_base_url>/api/1.0/table/show
허가: 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
테이블 설명
게시
https://<element_base_url>/api/1.0/table/desc/:table_id
허가: DDL 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
파라미터 요청(Request param)
● 요청-예:
https://<element_base_url>/api/1.0/table/desc/customers
성공 200
● 성공-응답:
HTTP/1.1 200 OK
기록 API들:
기록 삽입
게시
https://<element_base_url>/api/1.0/record/insert
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
기록 업데이트
게시
https://<element_base_url>/api/1.0/record/update
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
기록 삭제
게시
https://<element_base_url>/api/1.0/record/delete
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
기록 선택
게시
https://<element_base_url>/api/1.0/record/select
허가: DML_READ 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
사용자 API들:
사용자 등록
게시
https://<element_base_url>/api/1.0/user/register
허가: ELEMENT™ 관리자, 또는 관리자 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
사용자 취소
게시
https://<element_base_url>/api/1.0/user/revoke
허가: ELEMENT™ 관리자, 또는 관리자 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답
사용자 삭제
게시
https://<element_base_url>/api/1.0/user/delete
허가: ELEMENT™ 관리자, 또는 관리자 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답
인덱스 API들:
인덱스 생성
게시
https://<element_base_url>/api/1.0/index/create
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
인덱스 삭제
게시
https://<element_base_url>/api/1.0/index/delete
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
벌크 트랜잭션 API들:
벌크 기록 삽입
게시
https://<element_base_url>/api/1.0/record/bulk/insert
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
벌크 기록 업데이트
게시
https://<element_base_url>/api/1.0/record/bulk/update
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
벌크 기록 삭제
게시
https://<element_base_url>/api/1.0/record/bulk/delete
허가: DML_WRITE 액세스를 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문
● 요청-예:
성공 200
● 성공-응답:
HTTP/1.1 200 OK
SQL 질의 API들:
SQL 질의 실행
게시
https://<element_base_url>/api/1.0/query
허가: ADMIN, DDL, DML_WRITE & DML_READ 중에서 질의에 기반한 액세스 수준을 갖는 인증된 ELEMENT™ 사용자
헤더
● 헤더-예:
요청 본문 - 데이터베이스 생성 및 드롭 질의
요청 본문 - 모든 다른 질의들
● 요청 예
성공 응답 - 데이터베이스 생성 질의
성공 응답 - 데이터베이스 드롭 질의
성공 응답 - 테이블 생성 질의
성공 응답 - 테이블 변경 질의
성공 응답 - 테이블 드롭 질의
성공 응답 - 기록 삽입 질의
성공 응답 - 기록 업데이트 질의
성공 응답 - 기록 삭제 질의
성공 응답 - 기록 선택 질의
성공 응답 - 기록 벌크 삽입 질의
성공 응답 - 테이블 보여주기 질의
성공 응답 - 데이터베이스 보여주기 질의
성공 응답 - 테이블 설명 질의
● 성공-응답:
HTTP/1.1 200 OK
부록 E
ELEMENT SQL: 고수준 요건들
SQL 질의 입력 경로들
ELEMENT 1.0 실현들은, 다음의 표에 약술된 바와 같은 3개의 소스로부터 ELEMENT SQL 질의들을 수락한다:
ELEMENT에서 지원되는 SQL 개념들
본 명세서의 나머지에서 암시되는 것은, ELEMENT 구현들이 다음을 포함하는 다수의 공통 SQL 구성들에 대한 등가물들을 지원한다는 사실이다:
열들
데이터 유형들
식별자들
널 값들
행들(본원에서 기록들로 또한 지칭됨)
스키마 정의들
SQL-스키마 명령문들
SQL-명령문들
테이블들
데이터 유형들
ELEMENT의 데이터 유형들 - 배경기술
ELEMENT 시스템에서의 기록들은 특정 테이블과 연관된다. 모든 각각의 셀 값은, 그의 ELEMENT 테이블에 정의된 열에 의해 좌우되는 데이터 유형에 속한다.
ELEMENT SQL에서, 사전 정의된 데이터 유형의 이름은 예비된 키워드이다. 데이터 유형들은 기존 SQL 유형들로부터 영감을 받지만, ELEMENT 시스템은 이전 SQL 구현들과 상이한 고유 정밀도 및 범위 메트릭들로 구성된다.
모든 ELEMENT 사전 정의 데이터 유형들은 사실상 원자적인데, 즉, 값들이 다른 데이터 유형들의 값들로 구성되지 않는 데이터 유형이다.
ELEMENT 시스템은 현재 3개의 사전 정의된 데이터 유형을 지원한다:
1. 숫자
ELEMENT 시스템의 '숫자' 데이터 유형은 모든 연산 숫자 유형들을 지원한다. 그것은, 십진수 값들에 대한 정밀도를 또한 지원하는 NUMERIC, INTEGER 및 DECIMAL 유형들과 같은 친숙한 SQL 데이터 유형들의 조합이다.
'NUMBER'는 데이터 유형뿐만 아니라, SQL 질의들을 구성하는 동안의 임의의 수치 값들을 표시하는 키워드이다. 숫자에 대한 최대 길이 또는 정밀도는 소수(decimal fraction)의 소수점 자릿수(scale) 또는 자릿수들을 포함하는 정확히 16개 자릿수이다.
범위:
-9999999999999998 내지 9999999999999998
숫자 데이터 유형의 수용가능한 범위를 결정하기 위해 다음의 예들을 고려한다.
2. 스트링
ELEMENT 시스템에 대한 스트링 데이터 유형은 모든 스트링 관련 값들을 지원한다. 그것은, 가변 길이 문자 스트링 유형들의 구성이며, SQL에서의 TEXT 데이터 유형과 비슷하다.
스트링 데이터 유형은 모든 가변 길이 문자 스트링들을 수용하는 'STRING' 키워드에 의해 표시된다. ELEMENT v1.0은 고정 길이 스트링들을 지원하지 않는다. STRING 데이터 유형의 ELEMENT 구현-정의 범위는 설정된 엄격한 제한(hard limit)을 갖지 않지만, 운영 하드웨어, 연결성, 및 분산형 원장 플랫폼 구성들과 같은 다양한 인자들에 의해 정의되는 물리적 제한이 존재한다.
ELEMENT 질의들에 대한 입력 STRING 값들은 UTF-8 인코딩된다. CESU-8 및 수정된 UTF-8과 같은 대안적인 인코딩들은 유효한 UTF-8로서 취급되지 않는다.
3. 불 방식
불 방식 데이터 유형의 값은 참 또는 거짓이다.
미지의 진리값은 때때로 널 값으로 표현된다.
불 방식 열에 널 값이 인에이블되어 있는 경우, 널은 미지의 진리값을 표현한다.
글자표기(TYPOGRAPHICAL) 관례들
본 문서는 다음의 글자표기 및 구문 관례들을 포함하는 배커스-나우어형(BNF; Backus-Naur Form)의 간단한 변형의 텍스트 설명들로 이루어진다:
ELEMENT에 대한 SQL 구문 용어 해설
표준 SQL로부터의 키워드들
ELEMENT 1.0은 다음의 표준 키워드들에 더하여, 본 명세서에서 나중에 설명될 몇몇 ELEMENT 특정 키워드들을 포함하는 SQL 언어의 서브세트를 지원한다:
비고: ELEMENT 테이블의 모든 기록들/열들을 표시하는 * 기호가 또한 ELEMENT 시스템에 의해 지원된다.
널 키워드
널은 키워드뿐만 아니라 값으로서 사용된다.
널은 다음의 점들에서 다른 값들과 상이하다:
널 값은, 기록에 대해 데이터 유형 '널'을 사용함으로써 특정 필드들에 대한 블랭크(blank) 또는 값 없음(no value)을 나타내는 데 사용될 수 있다. 키워드로서의 널은, 비어 있는 기록들을 확인하기 위한 검증으로서 NOT 연산자와 함께 사용될 수 있다. 널은 또한 열의 기본 값을 널로서 설정하는 데 사용될 수 있다.
널의 값은 임의의 다른 값과 '동일'하지 않고, 유사하게, 임의의 다른 값과 '비-동일'하며, 널이 임의의 다른 주어진 값과 동일한지 여부는 알려지지 않는다. 임의의 유의미한 데이터 값의 부재가 널로서 표현될 수 있다.
식별자들
ELEMENT v1.0은 로컬 언어로서 영어만을 지원하며, 국제화(i18n)에 대한 지원은 향후의 릴리스에서 이용가능할 것이다. 2개의 유형의 식별자들이 ELEMENT에서 정의된다:
database_name 식별자들은 이러한 정규 표현식과 매칭한다:
identifier는 다음의 정규 표현식과 매칭하는 스트링이다:
모든 식별자들은 50 문자의 최대 길이를 갖는다.
identifier는 다음의 컨텍스트들에서 사용된다:
ELEMENT 시스템은 기본 및 예비 키워드들의 이름들을 포함하도록 identifier를 제한한다.
데이터 유형들 및 값들
ELEMENT v1.0은 3개의 사전 정의된 데이터 유형: 앞서 논의된 바와 같은, 스트링, 숫자, 및 불 방식을 지원한다.
<값> (선택된 데이터 유형에 대응함) - ELEMENT의 데이터 유형들 섹션을 참조한다.
비교 연산자들
ELEMENT SQL에서의 비교 연산자들은, 그들의 이름이 시사하는 바와 같이, 2개의 값의 비교를 허용한다. 그것은, 값들과 같음, 그 초과, 그 미만과 같은 관계들에 대해 스트링들 또는 숫자들을 동일시한다.
비교 연산자들의 목록:
조합 표현들
ELEMENT SQL은 WHERE 절과 함께 일반적으로 사용되는 조건부 키워드들을 사용하여 2개 이상의 상황 데이터 또는 선택들의 평가를 지원한다. 논리는 일부 비교 연산자들과 함께 ELEMENT 시스템에서 조합 연산자들을 형성한다. 지원되는 조합 연산자들이 아래에 언급된다:
ALL
ALL 연산자는 값을 부분질의(subquery)에 의해 반환된 값들의 목록 또는 값들의 세트와 비교함으로써 데이터에 대해 질의한다.
ANY
ANY 연산자는 값을 부분질의에 의해 반환된 값들의 목록 또는 값들의 세트에 비교한다.
IN
IN 연산자는 값이 값들의 목록 내의 임의의 값과 매칭하는지를 확인하기 위해 WHERE 절 내에서 사용된다.
AND, OR, 및 NOT 키워드들은 ELEMENT SQL의 논리 연산자들이다. 이러한 키워드들은 주로 SQL 명령문에서, 특히, WHERE 절에서 조건들을 합치거나 반전시키는데 사용된다. 논리 연산자들에 대한 구문은 다른 SQL 명령들의 조합과 함께 추가로 설명된다.
패턴 매칭
ELEMENT SQL은 정규 표현식(regex) 기반 스트링 패턴 매칭을 지원한다. LIKE 연산자를 사용하여 테이블 열들에 존재하는 기록 값들에 대해 패턴들이 매칭될 수 있다. LIKE 연산자는 '동일'(=) 연산자처럼 동작하여 스트링 패턴들을 매칭한다. LIKE 연산자와 함께 종종 사용되는 2개의 와일드카드가 존재한다:
% - 퍼센트 부호는 0, 1 또는 다수의 문자들을 표현한다.
_ - 밑줄은 단일 문자를 표현한다.
비고: 별표(*) 및 물음표(?)가 또한 지원된다.
부분질의
부분질의는, 더 큰 SQL 질의의, 일반적으로 WHERE 절에 끼워 넣어진, 내부에 내포(nest)된 SQL 질의이다.
부분질의는 SELECT, INSERT, UPDATE, 또는 DELETE 명령문 내부에 또는 다른 부분질의 내부에 내포될 수 있다. 이는 일반적으로, 다른 SQL SELECT 명령문의 WHERE 절 내에 부가된다. IN, ANY, 또는 ALL과 같은 조합 연산자들과 함께, >, <, 또는 =과 같은 비교 연산자들이 부분질의들과 함께 사용될 수 있다.
부분질의는 또한 내부 질의 또는 내부 선택으로 지칭되는 반면, 부분질의를 포함하는 명령문은 또한 외부 질의 또는 외부 선택으로 지칭된다.
부분질의에 대한 규칙들
- 부분질의는 주 질의의 실행 전에 실행된다.
- 부분질의 결과는 주 질의에 대한 입력으로서 처리된다.
- 부분질의는 괄호로 묶이지만, INSERT의 경우, 부분질의는 정규 SELECT 명령문으로서 취급된다.
- 비교 연산자의 우측 상에 부분질의가 배치된다.
- 부분질의들은 대응하는 결과들을 내부적으로 조작할 수 없으며, 따라서, ORDER BY 절은 부분질의에 부가될 수 없다. ORDER BY 절은 마지막 절이 될 주 SELECT 명령문에서 사용될 수 있다.
- SQL 연산자들은 부분질의에 의해 영향을 받는 행들의 수에 기반하여 사용되어야 한다.
- 부분질의가 주 질의에 널 값을 반환하는 경우, 주 질의는 WHERE 절에서 특정 조합 연산자들을 사용하는 동안 어떠한 행들도 반환하지 않을 것이다.
- ELEMENT 특정 키워드들 및 확장들은 부분질의에서 사용되지 않을 수 있다.
부분질의들의 유형
- 단일 행 부분질의: 0개 또는 하나의 행을 반환한다.
- 다수 행 부분질의: 하나 이상의 행을 반환한다.
- 다수 열 부분질의: 하나 이상의 열을 반환한다.
- 내포된 부분질의들: 부분질의들이 다른 부분질의 내에 배치된다.
DDL 명령들
데이터 정의 언어(DDL)는 데이터베이스 내의 데이터베이스 객체들의 구조를 생성하고 수정하는 데 사용되는 컴퓨터 언어이다. ELEMENT SQL에서의 지원되는 데이터베이스 객체들은 스키마들, 테이블들, 및 인덱스들을 포함한다. 다음의 DDL SQL 명령문들은 기술된 구문을 사용하여 ELEMENT 구현에 의해 지원된다.
고수준 요건들에서 언급된 바와 같이, DDL SQL 명령문들은 스마트 계약들에 의한 호출에 대해 지원될 수 있다.
데이터베이스 생성(CREATE DATABASE)
시스템에 새로운 데이터베이스를 생성한다.
database_name ::= Identifier
생성될 데이터베이스의 이름
테이블 생성(CREATE TABLE)
현재 데이터베이스에 새로운 테이블을 생성한다. 테이블은 다수의 열들을 가질 수 있고, 각각의 열 정의는 이름, 데이터 유형, 및 임의적인 열 정의로 이루어진다.
table_name ::= identifier
생성될 테이블의 이름
column_name ::= identifier
열의 이름
테이블 변경(ALTER TABLE)
기존 테이블에 대한 특성들, 열들, 또는 제약들을 수정한다.
비고: ALTER TABLE에 대한 ELEMENT SQL 문법은 한 번에 하나 초과의 동작을 지원하지 않는다.
이 구문에서, 동작 키워드는 사용자에 대해 이용가능한 테이블 변경 질의의 모든 ELEMENT 지원 변형들을 보여준다.
table_name ::= identifier
변경될 테이블의 이름
column_name ::= identifier
변경될 열의 이름
old_column_name ::= identifier
재명명될 열의 이름
new_column_name ::= identifier
변경 후의 열의 새로운 이름
테이블 드롭(DROP TABLE)
현재 데이터베이스로부터 테이블을 제거한다.
table_name ::= identifier
제거될 테이블의 이름
데이터베이스 드롭(DROP DATABASE)
ELEMENT 시스템으로부터 데이터베이스를 제거한다.
*비고: 데이터베이스 상의 데이터는 소거되지만, 데이터베이스는 네트워크로부터 물리삭제(hard-delete)되지 않는다. 데이터베이스 이름은, DROP DATABASE 동작을 사용한 후에도, 고유하며 재사용될 수 없다.
database_name ::= identifier
소거될 데이터베이스의 이름
테이블 보여주기(SHOW TABLES)
사용자가 액세스 특권들을 갖는 테이블들을 열거한다. 명령은 현재/특정된 데이터베이스에 대한 테이블들을 열거하는 데 사용될 수 있다.
출력은, 테이블 이름별로 사전식 순서로 순서화된 테이블들의 목록을 반환한다.
데이터베이스 보여주기(SHOW DATABASES)
분산형 원장 플랫폼 상에서 가시적일 드롭된 데이터베이스들을 포함하는, 사용자가 전체 계정에 걸쳐 액세스 특권들을 갖는 데이터베이스들을 열거한다.
출력은, 데이터베이스 이름별로 사전식 순서로 순서화된 데이터베이스들의 목록을 반환한다.
테이블 설명(DESCRIBE)
테이블에서의 열들 또는 현재 값들을 설명한다. DESCRIBE 질의는 선택된 테이블의 모든 세부사항들 및 메타데이터를 반환한다.
table_name ::= identifier
설명이 반환될 테이블의 이름
DML (기입) 명령들
데이터 조작 언어(DML)는 데이터베이스 내의 데이터를 부가(삽입), 삭제, 및 수정(업데이트)하기 위해 사용되는 컴퓨터 프로그래밍 언어이다. DML은 종종 SQL과 같은 더 넓은 데이터베이스 언어의 하위 언어이며, 여기서의 경우에서와 같이, DML은 언어의 연산자들 중 일부를 포함한다. 다음은 데이터의 현재 상태를 변경할 수 있는 DML SQL 기입 명령들이며, ELEMENT 실현들에 의해 지원된다.
기록 삽입(INSERT)
하나 이상의 행을 테이블에 삽입함으로써 테이블을 업데이트한다. 테이블의 각각의 열에 삽입된 값들은 명시적으로 특정될 수 있다.
table_name ::= identifier
데이터가 부가될 테이블의 이름
column_name ::= identifier
데이터가 부가될 열의 이름
비고: INSERT에 대한 값들은 필수적이고, 적어도 하나의 필드(기본 키 필드)는 명확한 값을 가질 것이다. 값들의 나머지는, 채워지지 않은 채로 남아 있는 경우, ELEMENT 시스템에 의해 널로서 간주될 것이다.
기록 삭제(DELETE)
테이블로부터 데이터를 제거한다. WHERE 절을 사용하여 특정 데이터가 제거된다.
table_name ::= identifier
기록들이 제거될 테이블의 이름
기록 업데이트(UPDATE)
표적 테이블의 특정된 행들을 새로운 값들로 업데이트한다.
table_name ::= identifier
수정될 테이블의 이름
column_name ::= identifier
특정 데이터에 대한 비교 또는 검색에 사용되는 열의 이름
DML (판독) 명령들
데이터의 판독 전용 선택은 때때로 별개의 데이터 질의 언어(DQL)의 일부인 것으로서 구별되지만 그것은 밀접하게 관련되어 있고 때때로 DML의 구성요소로 또한 간주된다. 다음의 SQL DML 판독 명령은 기술된 구문을 이용하여 ELEMENT 구현에 의해 지원된다.
선택(SELECT)
table_name ::= identifier
데이터가 판독되는 테이블의 이름
column_name ::= identifier
데이터가 검색되는 또는 그에 의해 결과들이 순서화되는 열의 이름
비고: ORDER BY 동작은 인덱싱된 열들에 대해서만 수행될 수 있다.
─────────────────────────────────
SQL에 대한 ELEMENT 확장들
ELEMENT 1.0 실현들은 또한 표준 SQL에 대한 확장들로서 다음의 키워드들을 지원한다.
1. OPSTAT
OPSTAT는 동작이 원장에 통합되었다는 표시를 추적하기 위한 요청이다.
OPSTAT가 콘솔 또는 SDK로부터 호출된 SQL DML 기입 질의의 끝에 부가될 때, 호출자는 사전 구성된 시간초과의 끝에 이르기까지 3개의 응답 중 하나를 수신할 것이다. 3개의 가능한 응답은 다음과 같다:
I. 성공(SUCCESS): 성공 응답들은, SQL 동작이 성공적으로 업데이트되고 데이터가 분산형 원장에 플랫폼 관련 범위까지 통합되었다는 것을 의미한다.
II. 실패(FAILURE): 실패 상태는, SQL 명령이 성공적으로 실행되지 않았고 데이터가 원장 상에 결코 업데이트되지 않았음을 표현한다.
III. 시간초과(TIMEOUT): SQL 명령이 사전 구성된 시간초과 기간을 초과할 때, 사용자들은 TIMEOUT 응답을 반환받는다. 현재, 질의 결과들이 원장에 통합되었다는 확인은 존재하지 않는다.
OPSTAT는 또한, 질의에 부가되든 그렇지 않든 간에, 모든 DDL 동작들에 대해 가정된다. 스마트 계약들로부터 직접 실행되는 질의들의 경우, OPSTAT는 포함된 경우 무시되고, 정규 질의 응답이 대신 반환된다. 이는, ELEMENT 동작이 더 큰 트랜잭션(스마트 계약의 호출) 내의 단계이기 때문이며, 이러한 이유로, 동작의 성공 또는 실패는 전체 스마트 계약 트랜잭션의 성공적인 실행의 일부인 경우를 제외하고는 정의되지 않는다.
OPSTAT에 대한 구문 규칙들:
- OPSTAT는 유효한 질의의 끝에서 사용되며, 이는, OPSTAT 키워드 이후에 어떠한 동작들 또는 절들도 나타나지 않을 수 있음을 의미한다.
- OPSTAT 키워드는 SELECT, UPDATE, INSERT 및 DELETE 동작들에 대해서만 사용된다.
예들:
2. 제한(LIMIT)
LIMIT 키워드는 일부 ELEMENT 특정 규칙들과 함께 종래의 SQL LIMIT 동작과 유사하다. LIMIT는 질의에 의해 반환되는 행들의 최대 수를 제한한다.
LIMIT에 대한 구문 규칙들:
- LIMIT는 SELECT, UPDATE 및 DELETE 동작들과 함께 사용된다.
- UPDATE 및 DELETE 질의들에 대해 OPSTAT 키워드 이전에 LIMIT가 사용된다.
- SELECT 질의에서, LIMIT는 BOOKMARK 또는 QUERY_LEVEL 키워드들 전에 사용된다.
예들:
3. 질의수준(QUERYLEVEL)
QUERYLEVEL 특징은 선택된 기록들에 관한 메타데이터 정보를 제공한다. 사용자는 SELECT 질의로 QUERYLEVEL 명령을 실행한 후에 질의 응답에서 정보를 수신한다.
이 기능성에 대해 2개의 정보 수준이 존재한다.
1. INFO: 이는, ELEMENT에 의해 설정된 기본 정보 수준이다. 이 수준에서, 사용자는 열 이름들 및 그들 개개의 값들을 제공받는다.
2. SYSTEM: SYS 또는 시스템 QUERYLEVEL은 선택된 기록들에 관한 상세한 정보를 제공한다. 상세한 메타데이터는 다음과 같은 필드들을 포함한다:
a. 생성 날짜
b. 마지막 수정된 날짜
c. 누가 생성했는지(created by)
d. 고유 ID들: 기록 ID, 테이블 ID
e. 버전 세부사항들
QUERYLEVEL에 대한 구문 규칙들:
- QUERYLEVEL은 판독 동작들을 위해, 즉, SELECT 질의에 대해서만 사용된다.
- 이는, LIMIT 키워드 전에 사용되고 질의의 끝에 위치된다.
- QUERYLEVEL의 위치는 BOOKMARK 키워드와 상호교환될 수 있다.
예들:
4. 북마크(BOOKMARK)
BOOKMARK 질의는 ELEMENT 테이블 데이터의 페이지 매기기에 사용된다. 테이블에 대한 페이지 크기는 북마크와 함께 LIMIT 키워드를 사용하여 설정된다. 기본적으로, 모든 페이지들은, 사용자가 BOOKMARK 질의를 사용함으로써 액세스할 수 있는 지정된 고유 마커를 갖는다. 질의는 BOOKMARK 및 질의 응답을 포함하는 객체를 반환한다. 획득된 BOOKMARK를 사용하여, 사용자는 후속 페이지 상의 데이터를 볼 수/그에 액세스할 수 있다.
BOOKMARK에 대한 구문 규칙들:
- BOOKMARK 키워드는 SELECT 질의에 대해서만 사용된다.
- BOOKMARK는 질의의 끝에서 사용되고, 그러므로, LIMIT 키워드 이후에 사용된다.
- BOOKMARK의 위치는 QUERYLEVEL 키워드와 상호교환될 수 있다.
예들:
HTTP/1.1 200 OK
Bookmark를 이용한 질의 응답
5. 기록들의 벌크 삽입(BULK INSERT)
ELEMENT는 BULK INSERT 특징을 사용하여 ELEMENT 테이블들에 대한 기록들의 다수의 삽입을 지원한다.
BULK INSERT 동작은 다수의 행들이 영향을 받는/수정되는 DELETE 및 UPDATE 질의들과 매우 유사하게 기능한다. 그러므로, 이러한 동작들에 대한 후속 질의 응답들에서의 '영향을 받는 행들의 수'(ELEMENT API 규격 - 부록 D에서 더 상세히 설명됨) 필드는 임의의 수 'n'일 수 있다. 그렇지만, 최적의 동작을 위해 ELEMENT 특정 제한이 설정되어 있다.
대조적으로, INSERT 명령은 단일 행만을 처리하므로, INSERT 질의 응답에서의 '영향을 받는 행의 수' 값은 1로 고정된다.
예:
HTTP/1.1 200 OK
:
벌크 삽입에 대한 질의 응답
부록 F
ELEMENT Node.js® SDK 기능 문서
도입부
ELEMENT의 언어 특정 SDK는 개발자들이 그들의 애플리케이션 코드로부터 직접 ELEMENT™ 시스템과 상호작용할 수 있게 하는 툴이다. 본 문서는 Node.js® 애플리케이션들과 함께 사용하기 위해 개발된 SDK의 버전을 상세히 설명한다.
Node.js® SDK("ELEMENT_SDK"로 지칭됨)는 상당히 간단하며, 특정 사용자 및 ELEMENT 데이터베이스에 사용하도록 그를 구성하는 구성기, 및 SQL 명령문 파라미터를 수용하는 함수를 포함한다. 데이터베이스 동작들 그 자체들은 SQL 파라미터의 구문을 사용하여 호출된다. 세부사항들에 대해서는, 부록 E를 참조한다.
Element_Chaincode에서의 재사용
패브릭 실현에서, Node.js®는 또한 ("시스템 체인코드"를 통해) 분산형 원장 플랫폼을 확장하기 위한 수락된 언어이다. 이 때문에, 패브릭 플랫폼에 배치된 Element_Chaincode에서 Node.js® ELEMENT_SDK에 대한 작업을 재사용할 기회가 존재했다. 결과적으로, ELEMENT_SDK는 2개의 유사한 패키지로 전환되었다. 첫 번째는 ELEMENT 규격들에 예시된 바와 같은 SDK로서 사용된다. 패키지의 제2 버전은, 패브릭 피어 노드들에 ELEMENT 특징들을 부가하는 Element_Chaincode 구성요소의 일부로서 배포된다. 이는, executeQuery() 함수를 "사용자 체인코드" 스마트 계약들에 이용가능하게 하여, ELEMENT 규격에 의해 요구되는 바와 같은 SQL의 사용을 가능하게 한다.
부록 G
패브릭 서비스 계층 인터페이스 규격
도입부
패브릭서비스는 ELEMENT 1.0 규격에서 플랫폼 특정 서비스 계층 추상화 구성요소를 실현하고, API 계층과 분산형 원장 플랫폼 사이의 상호작용을 위한 중간자로서의 역할을 하는 서비스 계층 인터페이스를 구현한다. 그의 서비스들은 RDBMS 관련 동작들을 수행하는 것을 돕는다.
이 부록은 패브릭서비스를 상세히 설명하며, 그의 기능 서명들(벌크 업데이트와 같은 몇몇 패브릭 특정 기능들을 제외함)은 서비스 계층 인터페이스에 대한 규격으로서 취해질 수 있다.
전제조건
ELEMENT™ 콘솔로 패브릭서비스를 배포하기 위해 다음의 전제조건들이 요구된다:
노드 8.x가 설치되어야 한다.
패브릭 설정이 적절히 구성되어야 한다.
서비스 및 방법들
패브릭 서비스
이 서비스들은 패브릭 분산형 원장 플랫폼 특정 서비스들이다. 아래는, 서비스들 및 그들의 방법들이다:
부록 H
ELEMENT™ 파서: 도입부
ELEMENT 파서는 다음의 방식들로 질의 스트링을 처리하는 ELEMENT™의 구성요소이다:
● 유효한 구문에 대한 질의를 확인한다.
● 파싱된 추상화 구문 트리를 반환한다.
● 질의가 무효인 경우 오류를 반환한다.
● 데이터베이스 ID, 테이블 ID, 및 열 이름들과 같은 식별자들이 ELEMENT SQL 규격에 언급된 바와 같은 특정된 구문을 따르는지 여부를 확인한다.
● ELEMENT SQL™으로 알려져 있는 ELEMENT 특정 키워드들과 조합하여 다양한 기존 SQL 키워드들을 처리한다.
파서는, SQL 질의들을 파싱하고 내부 PostgreSQL 파싱 트리를 반환하기 위해 실제 PostgreSQL 서버 소스를 사용하는 C 라이브러리를 사용하는 'pg-parser-native' 위에 구현된다.
파서는, SQL 질의들을, 고유 분산형 원장 데이터로서 ELEMENT에 의해 분산형 원장에 커밋될 수 있는 객체로 파싱함으로써, 관계형 데이터를 처리하는 편리한 방식을 제공한다. SQL을 파싱하는 ELEMENT의 능력은, 개발자들이, 이미 통상적으로 이해되는 구문을 사용하여 분산형 원장 상의 관계형 데이터를 조작하는 것을 가능하게 한다.
ELEMENT™ 파서: 고수준 요건들
ELEMENT 패브릭 실현에서 파서의 성공적인 소비를 보장하기 위해 다음의 요건들이 충족될 필요가 있다:
● ELEMENT 시스템 체인코드가 완전히 제대로 작동(up and running)해야 한다.
● ELEMENT 콘솔이 배치될 필요가 있다.
● 파서는 ELEMENT 콘솔에 Node.js® 모듈로서 설치되어야 한다.
● 파서는 또한, 시스템 체인코드가 설치된 모든 패브릭 피어들에 존재해야 한다. 이는, 시스템 체인코드가 파서에 로컬로 액세스할 수 있는 것을 보장한다.
파서 기능성의 분리
구현된 바와 같은 ELEMENT 파서는 단일의 통합 구성요소이다. 그러나, 파서 기능성은, 충족되는 ELEMENT 규격의 부분에 기반하여 2개의 부분으로 분할된다. 구체적으로, DDL 구성요소 및 DML 구성요소이다.
사용자 질의들/입력들의 DDL 파싱은, DDL 파서가 그의 구성인 ELEMENT 콘솔 내에서 수행된다. 콘솔은, DDL 파서의 도움으로, 모든 데이터베이스 구조 수정 요청들을 관리한다. DDL 기능들을 패브릭 네트워크 자체 내에서 전적으로 이용 가능하게 하는 것은 광범위한 수정 없이는 불가능하므로, 이러한 기능들은 패브릭-NodeJS 실현에서 액세스가능하지 않다.
입력 질의들에 대한 DML 파싱은 ELEMENT 특징들이 부가된 분산형 원장 플랫폼 내에서 요구된다. 이러한 NodeJS/패브릭 실현을 위해, DML 파서는 ELEMENT 시스템 체인코드에서 기능하고, 그에 따라, 스마트 계약들(사용자 체인코드)에 액세스가능하다.
입력 유형
ELEMENT 파서는 스트링 포맷의 질의 입력들을 취하고, "parseQuery"로 지칭되는 파서에 존재하는 기능을 사용하여 호출된다. 질의들은 Postgres SQL에 대한 질의 규격을 따른다. 규격들은 ELEMENT™ 1.0 ELEMENT SQL™ 문서에서 자세히 확인할 수 있다. 질의들은 부가된 엘리먼트 특정 키워드들을 특징으로 하며, 이는 데이터의 더 양호한 처리를 제공한다.
ELEMENT™ 파서의 구성
파서는 사용자 액세스 수준들과 동일한 라인들을 따라 분류되는 4개의 범주의 기능들로 구성된다. 다음의 표는 이러한 기능들을 요약한다:
ELEMENT™ 시스템 체인코드에서의 파싱
ELEMENT™ 시스템 체인코드에서의 파싱은 다음의 단계들을 수반한다:
1. 시스템 체인코드에 존재하는 '질의 실행' 기능에 의해 파서가 소비된다. 시스템 체인코드. DML 질의로 기능이 호출된 후에, 파서는 질의를 AST 객체로 파싱한다.
2. ELEMENT™ DML 동작들의 비즈니스 규칙들에 따라 객체가 검증된다. 무효인 객체들은 오류를 초래한다.
3. 검증된 AST 객체는 이어서, 질의가 의도된 동작에 기반하여 ELEMENT™ 시스템 체인코드에 존재하는 기능들에 특정한 키들을 포함하는 객체로 변환된다.
4. 이는, ELEMENT™ 시스템 체인코드가 입력 데이터를 추가로 처리하고 모든 DML 동작들을 처리하는 것을 가능하게 한다.
ELEMENT™ 콘솔에서의 파싱
ELEMENT™ 콘솔에서의 파싱은 다음의 프로세스를 따른다:
1. ELEMENT™ 콘솔에 존재하는 '질의 실행' 기능은, 호출될 때, 입력 질의들을 파싱하기 위해 파서를 이용한다.
2.
일단 파서가 ELEMENT™ DDL 및 DML 동작들의 비즈니스 규칙들에 따라 검증하면, 파서는 콘솔 그 자체에 존재하는 기능들에 특정한 키들을 포함하는 객체를 콘솔에 반환한다.
3. 콘솔은 이어서, 질의 기능에 기반하여 질의를 처리한다. DDL의 경우, 콘솔의 기능들이 호출되고, DML의 경우, 시스템 체인코드가 호출된다.
오류 처리
파서는 입력 질의를 자체적으로 검증함으로써 불필요한 ELEMENT™ 기능 호출들을 피한다. ELEMENT™의 비즈니스 규칙들을 준수하지 않는 데이터는 오류를 초래한다. 오류는 무효화된 규칙과 관련된 오류 메시지 및 오류 코드를 포함한다. 이는, 질의를 디버깅함에 있어서의 용이성, 및 오류들을 처리하는 시스템 방식을 또한 클라이언트에 제공한다.
ELEMENT 파서에서의 오류들
참조들
[1] https://www.npmjs.com/package/pg-query-native
[2] https://github.com/lfittl/libpg_query
부록 I
도입부
ELEMENT 체인코드는 패브릭에 대한 모든 데이터베이스 관련 동작들을 수행하기 위한 ELEMENT™의 기본 구성요소이다. 질의들의 형태의 사용자 입력들은 ELEMENT 체인코드를 사용하여 분산형 원장 상에서 처리된다. ELEMENT 체인코드는 특정 기능성들을 달성하기 위해 신원 제공자 및 전역 상태 데이터베이스에 대한 자신의 종속성을 갖는다.
ELEMENT 체인코드는 시스템 체인코드로서 배치되고 피어 프로세스의 일부로서 실행된다. 사용자 체인코드와 달리, 시스템 체인코드는 SDK들 또는 CLI로부터의 제안들을 사용하여 설치 및 인스턴스화되지 않으며, 오히려, 시스템 체인코드는 시동 시에 피어에 의해 등록 및 배치된다. 이러한 능력은 기본적으로 인에이블링되지 않으며, 대신에, 이러한 능력은, 피어가 개별적으로 구축될 것을 요구한다.
시스템 체인코드들은 Go 플러그인들을 사용하여 정적으로 또는 동적으로 피어에 링크될 수 있다. 그러나, 더 양호한 접근법은, 시스템 체인코드에 변경이 이루어질 때마다 재구축이 필요할 시나리오를 피하기 위해 시스템 체인코드를 플러그인으로서 로딩하는 것이다. 피어는 플러그인들을 로딩하는 것을 가능하게 하기 위해 한 번만 구축될 필요가 있다.
체인코드 상의 모든 각각의 동작은 트랜잭션으로서 처리되는 한편, 일부 동작들은 트랜잭션들의 세트로서 처리될 필요가 있다. 체인코드는 단일 트랜잭션으로서 동작을 처리하고, 트랜잭션들이 배치들로 처리되는 경우에는 트랜잭션들을 모의하기 위해 롤백 메커니즘이 사용된다.
체인코드에 대한 모든 각각의 동작은 유사한 흐름을 따르지만, 그 구현은 상이할 수 있다. 1차 단계로서, 일반적인 확인이 입력에 대해 수행되고, 임의의 불일치의 경우에, 요청이 반환되고, 그 영향은 원장 상에 나타나지 않을 것이다. 둘째로, 요청은 호출 엔티티가 (신원 제공자에 의해 처리되는) 그 동작의 프로세스에 대한 적절한 액세스를 갖는 경우에만 전달된다.
각각의 호출 엔티티에 대한 액세스는 그의 인증서들을 사용하여 확인된다. 등록 시에, 그 데이터베이스에 관련된 적절한 속성들이 그의 인증서에 부가된다. 각각의 후속 요청에 대해, 확인이 수행된다. 엔티티가 그 동작에 대한 액세스 특권들을 갖는 경우에만, 관계된 요청이 처리되며, 엔티티는 그 동작을 수행하기 위한 허가를 승인받을 것이다.
넓게는, 체인코드 상의 동작들은 데이터 정의 언어(DDL) 및 데이터 조작 언어(DML)로서 분류될 수 있다. DDL 동작들이 체인코드에서 파싱되지 않으므로, 체인코드는 다른 체인코드를 통한 DDL 동작 액세스를 제한한다. 그러므로, 모든 각각의 요청의 시작 시, ELEMENT 시스템은 호출이 체인코드에 직접 이루어지는지를 확인하기 위해 트랜잭션 제안을 사용한다. 트랜잭션이 다른 소스로부터 오는 경우, 임의의 체인코드 동작(DDL)에 대한 액세스가 방지된다.
DML 동작들의 경우, 질의들이 입력으로서 직접 전송될 수 있다. 이어서, 모든 각각의 질의는 파서로 전송되고, 파서로부터의 응답에 기반하여 대응하는 동작이 호출된다. 체인코드의 각각의 양상의 구현에 관한 더 상세한 정보는 아래의 섹션들에서 주어진다.
전제조건
다음의 전제조건들은 ELEMENT 체인코드를 등록하고 배치하는데 필수적이다:
● 패브릭 네트워크가 실행 중이어야 한다.
● 피어들은 "pluginsenabled"라는 이름의 구축 태그를 사용하여 구축될 필요가 있다.
배치
사용자 체인코드와 달리, 시스템 체인코드는 SDK들 또는 CLI로부터의 제안들을 사용하여 설치 및 인스턴스화되지 않는다. 시스템 체인코드는 시동 시에 피어에 의해 등록 및 배치된다. 이러한 능력은 기본적으로 인에이블링되지 않으며, 대신에, 피어가 "pluginsenabled"라는 이름의 구축 태그를 사용하여 구축될 것을 요구한다.
시스템 체인코드들은 2개의 방식으로 피어에 링크될 수 있다:
1. 정적으로 - 정적으로의 경우, 체인코드를 피어 프로세스의 일부로서 구축하기 위해, 접근법은, 체인코드가 [1] 'SelfDescribingSysCC' 인터페이스를 구현하게 하고 [2] 피어 시동 파일에 그의 인스턴스를 등록하게 하는 것일 것이다. 이에 후속하여, 피어는 이러한 수정된 코드를 사용하여 구축될 필요가 있다.
2. 동적으로 - 시스템 체인코드를 플러그인으로서 로딩하는 것이 더 양호하다. 이 방식에서는, 체인코드에 변경이 이루어질 때마다 피어를 재구축할 필요가 없다. 피어는 플러그인들을 인에이블링하기 위해 한 번 구축될 필요가 있다.
a. 배치 단계들 -
i. go에 시스템 체인코드를 기입한다.
ii. -buildmode=plugin 구축 플래그를 사용하여 이 go 플러그인을 컴파일하여, 공유 객체(.so) 라이브러리 파일을 생성한다.
go build -buildmode=plugin -o <output-file>.so <go-plugin>.go
iii. GO 플러그인들을 로딩하는 것을 가능하게 하도록 피어를 구축한다:
DOCKER_DYNAMIC_LINK=true GO_TAGS+="pluginsenabled" make peer-docker
비고 - 패브릭 버전의 go 버전의 동일한 go 버전 상에 go 플러그인을 구축한다는 것을 명심한다.
iv. 형성된 도커 이미지를 사용하여 네트워크를 시작한다.
v. 도커 피어에서 플러그인 파일 및 .so 파일을 복사한다.
vi. 피어의 구성 파일(core.yaml)에 시스템 체인코드 및 그의 정보를 부가한다.
vii. 피어를 재시작한다.
참조들
1.
https://github.com/hyperledger/fabric/blob/release-1.3/core/scc/sysccapi.go#L78
2.
https://github.com/hyperledger/fabric/blob/release-1.3/peer/node/start.go#L549
매소드(method)들
Init()
Init는 체인코드 등록 동안 호출된다. 이 매소드는 구성을 로딩하고 모든 다른 매소드들에서 사용되는 전역 변수들을 초기화하는 데 사용된다.
New()
이 매소드는, 이 매소드가 체인코드 인터페이스의 구현을 반환하기 때문에, 모든 각각의 동적으로 링크된 시스템 체인코드에 존재해야 한다. 체인코드 인터페이스는 모든 메소드들을 캡슐화하고 이들을 피어 프로세스의 일부로서 실행되도록 전달한다.
Invoke()
이 매소드는 체인코드 상에서 트랜잭션들을 수행하는 데 사용된다. 이는, 체인코드의 API들과 패브릭 피어 사이의 단일 접촉점으로서의 역할을 한다. 호출 엔티티는 체인코드의 임의의 다른 메소드들을 처리하기 위해 호출 메소드를 호출한다. 호출 엔티티가 적절한 액세스를 갖는지 그리고 입력들이 텍스트 표현으로 변환된(stringified) JSON으로서 정확하게 공식화되었는지를 확인한 후에, 다음이 이루어진다. 호출이 호출하도록 의도되는 대응하는 매소드로 요청이 중계된다.
CreateDatabase()
이 매소드는 데이터베이스 생성의 시작 시에 호출된다. 요청은 그 특정 데이터베이스에 대한 적절한 메타데이터를 생성함으로써 처리된다. 이러한 메타데이터는 체인코드의 모든 다른 매소드들에 의해 소비된다.
DropDatabaseMeta()
이 매소드는 데이터베이스의 삭제를 개시하기 위해 호출되며, 이는 사용자에 대한 배치 동작으로서 처리된다. 이 매소드는 프로세스의 시작을 표기하고 그 데이터베이스에 존재하는 모든 테이블들의 목록을 반환한다. 이에 후속하여, 테이블의 메타데이터 및 그의 모든 기록들을 삭제하기 위해 특정 호출들이 행해진다.
DropDatabaseCommit()
이 매소드는 배치 내의 모든 요청들이 성공적으로 처리된 후의 데이터베이스의 삭제에 대한 마무리 호출로서의 역할을 한다.
RegisterUser()
이 매소드는 데이터베이스에 새로운 사용자를 추가하는 데 사용되고, 이는 인증서에 대한 속성들의 부가에 후속된다.
관리자 특권들을 갖는 사용자들만이 다른 사용자들을 추가하도록 허용되므로, 호출 엔티티의 적절한 액세스를 확인한 후에, 요청에서 주어진 사용자 신원이 데이터베이스 메타데이터에 부가된다.
DeleteUser()
이 매소드는 데이터베이스로부터 사용자를 삭제하는데 사용되고, 이는 인증서로부터의 속성들의 제거에 후속된다.
관리자 특권들을 갖는 사용자들만이 다른 사용자들을 삭제하도록 허용되므로, 호출 엔티티의 적절한 액세스를 체크한 후에, 다음이 이루어진다. 요청에서 주어진 사용자가 데이터베이스 메타데이터로부터 삭제된다.
CreateTable()
이 매소드는 기존 데이터베이스에 새로운 테이블을 생성하고 부가하는 데 사용된다. 먼저, 현재 데이터베이스가 유휴 상태에 있지 않음을 검증하기 위한 확인이 수행된다. 이에 후속하여, ELEMENT 시스템은 데이터베이스에 테이블이 이미 존재하는지를 확인한다. 이러한 검증들과 함께, 입력 데이터가 일치하는 경우, 테이블 메타데이터가 형성되고 원장에 부가된다. 테이블 정보가 또한 데이터베이스 메타데이터에 부가된다. 테이블 메타데이터는 그 테이블에 대해 수행되는 모든 동작들을 검증하는 데 사용된다.
DropTableMeta()
이 매소드는 테이블의 삭제를 개시하기 위해 호출되며, 이는 사용자에 대한 배치 동작으로서 처리된다. 이 매소드는 프로세스의 시작을 표기하고 그 테이블 상에서의 다른 동작들을 제한하기 위해 DDL 플래그를 설정한다.
DropTableRecords()
이 매소드는 그 테이블에 대한 기록들을 삭제하는 데 사용된다. 이는, 특정된 테이블 기록들에 대해 재귀적으로 삭제 동작을 실행한다. 삭제는 기록들의 배치에 대해 수행되는 한편, 배치의 크기는 구성가능하다. 이는, 트랜잭션에 대한 시간 제한을 초과하는 것을 방지하기 위해 행해진다.
DropTableCommit()
이 매소드는 배치 내의 모든 요청들이 성공적으로 처리된 후의 테이블의 삭제에 대한 마무리 호출로서의 역할을 한다. 이 프로세스의 완료를 표기하기 위해 호출 엔티티로부터의 호출이 이루어진다. 모든 중간 트랜잭션 ID들이 원장에 저장되며, 이에 따라, 사용자는 단일 트랜잭션 ID를 반환받을 수 있다. 이에 후속하여, 그 테이블에 대한 메타데이터가 삭제되고, 테이블 이름이 향후의 동작들에서 새로운 테이블을 생성하는 데 재사용될 수 있다.
AlterTableMeta()
이 매소드는 테이블의 구조의 수정을 개시하기 위해 호출된다. 그것은 배치 동작으로서 처리된다. 이 매소드는 프로세스의 시작을 표기하고 그 테이블 상에서의 다른 동작들을 제한하기 위해 DDL 플래그를 설정한다. 요청 ELEMENT 시스템에서 주어진 입력들을 사용하여, 그 테이블의 모든 기록들을 업데이트하는 데 사용될 업데이트 템플릿을 공식화한다. 그 업데이트 템플릿은 응답에서 반환된다.
AlterTableRecords()
이 매소드는 그 테이블에 대한 기록들을 수정하는 데 사용된다. 이는, 테이블에 존재하는 모든 기록들을 수정한다. 변경은 기록들의 배치에 대해 수행되는 한편, 배치의 크기는 구성가능하다. 이는, 트랜잭션에 대한 시간 제한을 초과하는 것을 방지하기 위해 행해진다.
AlterTableCommit()
이 매소드는 배치 내의 모든 요청들이 성공적으로 처리된 후의 테이블의 수정에 대한 마무리 호출로서의 역할을 한다. 이 프로세스의 완료를 표기하기 위해 호출 엔티티로부터의 호출이 이루어진다. 모든 중간 트랜잭션 ID들이 원장에 저장되며, 이에 따라, 사용자는 단일 트랜잭션 ID를 반환받을 수 있다. 이에 후속하여, 그 테이블에 대해 다시 요청이 행해질 수 있다.
InsertRecord()
이 매소드는 테이블에 기록을 부가하는 데 사용된다. 테이블에 부가된 모든 각각의 기록은 테이블을 생성할 때 규칙 세트를 준수해야 한다. 그러므로, 각각의 요청에 대해, 먼저, 테이블 메타데이터에서의 제약들에 기반하여, 열 값들이 부가될 수 있는지가 확인된다. 이 매소드의 2개의 변형이 존재하는데, 하나는 호출 엔티티가 열들을 전달할 수 있는 것이고, 둘째로, 열 이름들이 생략되는 것이다. 변형들 둘 모두의 처리는 유사하고, 열 이름들이 생략되는 경우에, 열 이름들만이 테이블 메타데이터로부터 선택된다. 기록이 모든 확인들 및 검증을 통과하는 경우, 그 기록은 기록 ID로서 설정된 기본 키 값과 함께 원장에 부가된다.
UpdateRecord()
이 매소드는 테이블의 기존 열들의 값들을 업데이트하는 데 사용된다. 기록에 대해 행해진 모든 각각의 업데이트는 여전히, 테이블 메타데이터에 설정된 제약들을 준수해야 한다. 그러므로, 각각의 요청에 대해, 이전 기록 데이터가 원장으로부터 선택되고, 의도된 변경들이 기록에 대해 이루어진다. 기록이 모든 확인들 및 검증을 통과하는 경우, 기록은 기록 ID가 변경되지 않은 채로 원장에 업데이트된다.
비고 - 기본 키 값은 기록을 업데이트하는 동안 업데이트될 수 없다.
DeleteRecord()
이 매소드는 테이블로부터 이전의 기존 기록을 삭제하는 데 사용된다. 기록이 존재하고 테이블이 임의의 DDL 프로세스 하에 있지 않은 경우, 기록은 원장으로부터 삭제된다. 그 영향은, 일단 트랜잭션이 커밋되면 나타날 것이다.
CreateIndex()
이 매소드는 호출 엔티티가 기존 열들 상에 인덱스들을 부가하기를 원하는 경우에 사용된다. 먼저, 요청은, 주어진 열들에 대해 인덱싱이 수행될 수 있는지에 대해 확인된다. 이에 후속하여, 인덱스들은 상태 데이터베이스에 부가될 필요가 있다. 이러한 기능성은 본질적으로 패브릭에 존재하지 않으므로, 주어진 열들에 대해 인덱스들을 부가하기 위해 상태 데이터베이스에 대해 별개의 요청들이 행해질 필요가 있다.
DeleteIndex()
이 매소드는 호출 엔티티가 기존 열들 상의 인덱스들을 삭제하기를 원하는 경우에 사용된다. 먼저, 요청은, 주어진 열들에 대해 인덱싱이 수행될 수 있는지에 대해 확인된다. 이에 후속하여, 이전에 생성된 인덱스들이 상태 데이터베이스로부터 삭제된다.
SelectQueryWithPagination()
이 매소드는 상태 데이터베이스 상에서 주어진 질의를 실행하는 데 사용된다. 그 결과는, 의도된 질의 수준에 기반하여 호출 엔티티에 반환된다. 이 매소드는 판독 동작만을 수행하고, 그에 따라, 원장에 어떠한 영향도 주지 않는다. 호출 엔티티가 제한을 특정하지 않은 경우, 트랜잭션을 실행하는 것이 시간초과되는 것을 방지하기 위해 기본 제한이 취해진다.
BulkInsertRecord()
이 매소드는 배치들에 대해 삽입 동작들을 수행하는 데 사용된다. 삽입 동작은 모든 기록들에 대해 수행되고, 그들 중 어느 하나가 실패하는 경우, 배치는 원장에 영향을 주지 않고 반환된다. 삽입되는 모든 기록들은 열 값들이 테이블 메타데이터에 설정된 제약을 충족하는 경우에만 부가되어야 한다.
BulkUpdateRecord()
이 매소드는 배치들로 업데이트 동작들을 수행하는 데 사용된다. 업데이트 동작은 상태 데이터베이스에 대해 질의를 실행한 후에 획득된 배치 내의 모든 기록들에 대해 수행된다. 그들 중 어느 것이든 실패하는 경우, 배치는 원장에 영향을 주지 않고 반환된다. 업데이트된 모든 기록들은 테이블 메타데이터에 설정된 제약들을 준수해야 한다.
BulkDeleteRecord()
이 매소드는 배치들로 삭제 동작들을 수행하는 데 사용된다. 삭제 동작은, 재귀적으로, 상태 데이터베이스에 대해 질의를 실행한 후에 획득된 배치 내의 모든 기록들에 대해 수행된다. 그들 중 어느 것이든 실패하는 경우, 원장에는 어떠한 영향도 존재하지 않는다.
RollbackTransaction()
일부 동작들은, 호출 엔티티에 대해 단일 트랜잭션으로서 나타날 트랜잭션들의 세트로서 처리될 필요가 있다. 그들 중 어느 하나가 처리되지 않는 경우, 모든 이전 트랜잭션들이 복귀될 필요가 있다. 그러므로, 각각의 매소드에서, 롤백에 대한 메타데이터가 큐레이팅되고(curated), 이 매소드는 주어진 트랜잭션 ID를 갖는 임의의 이전 트랜잭션을 복귀시키는데 사용된다.
DeleteTransactionMeta()
일부 동작들은, 호출 엔티티에 대해 단일 트랜잭션으로서 나타날 트랜잭션들의 세트로서 처리될 필요가 있다. 그들 중 어느 것이든 처리되지 않는 경우, 모든 이전 트랜잭션들이 복귀될 필요가 있다. 그러므로, 각각의 매소드에서, 롤백에 대한 메타데이터가 큐레이팅된다. 모든 트랜잭션들이 성공적으로 처리된 경우, 이 매소드는 주어진 트랜잭션 ID에 대한 메타데이터를 삭제하는 데 사용된다.
ExecuteQuery()
이 매소드는 체인코드에서 DML 질의들을 실행하는 데 사용된다. 요청에서의 질의는 파서에 전송되고, 파서로부터의 출력은 대응하는 매소드를 처리하는 데 사용된다. 그 매소드에 대한 호출 엔티티의 액세스를 확인한 후에, 다음이 이루어진다. 적절한 매소드로 요청이 중계된다.
ShowDatabases()
이 매소드는 임의의 호출 엔티티가 액세스할 수 있는 모든 데이터베이스를 열거하는 데 사용된다. 모든 데이터베이스들이 호출 엔티티의 인증서에서 언급되므로, 모든 데이터베이스들의 이름을 페치하고 그를 반환하기 위해 호출 엔티티의 인증서가 사용된다.
ShowTables()
이 매소드는 데이터베이스에 존재하는 모든 테이블들을 열거하는 데 사용된다. 모든 테이블들이 데이터베이스 메타데이터에서 언급되므로, 데이터베이스 메타데이터를 페치하여 모든 테이블들의 목록을 반환한다.
DescTable()
이 매소드는 테이블이 생성될 때 설정된 모든 제약들을 획득하는 데 사용된다. 테이블 메타데이터는 모든 열들에 대한 제약들을 포함한다. 그러므로, 요청이 이루어질 때, 내부 정보를 제거한 후에 테이블 메타데이터가 반환된다.
Claims (19)
- 시스템으로서,
스마트 계약;
트랜잭션 데이터를 포함하는 분산형 원장을 구현하는 분산형 원장 플랫폼;
상기 분산형 원장 상의 데이터베이스; 및
동작들을 수행하는 관계형 데이터 관리 및 구성 시스템을 구현하기 위한 명령어들을 실행하는 적어도 하나의 프로세서
를 포함하며, 상기 동작들은,
상기 분산형 원장 상의 상기 데이터베이스에 관한 정보를 기록하는 것;
상기 스마트 계약으로부터 관계형 데이터베이스 관리 질의를 수신하는 것;
수신된 관계형 데이터베이스 관리 질의를 상기 분산형 원장 상의 상기 데이터베이스에 의해 처리될 수 있는 분산형 원장 트랜잭션으로 변환하는 것;
상기 분산형 원장 상에서 상기 분산형 원장 트랜잭션을 실행하여 트랜잭션 결과를 생성하는 것; 및
상기 트랜잭션 결과를 상기 스마트 계약에 반환하는 것을 포함하는, 시스템. - 제1항에 있어서, 상기 적어도 하나의 프로세서는 상기 분산형 원장 상의 포함을 위해 상기 분산형 원장 상의 상기 데이터베이스에 의해 처리될 수 있는 형태로 상기 트랜잭션 결과를 상기 분산형 원장 상의 상기 데이터베이스에 로그처리하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제1항에 있어서, 상기 스마트 계약은 데이터 정의 언어(DDL) 데이터베이스 동작들 및 스키마 변경들을 제외한 상기 분산형 원장의 DDL 동작들을 실행하는, 시스템.
- 제3항에 있어서, 상기 데이터베이스의 데이터베이스 관련 동작들은 상기 분산형 원장 상에서 체인코드로 구현되고, 상기 체인코드는 상기 스마트 계약의 적어도 하나의 자산 및 상기 적어도 하나의 자산을 수정하기 위한 적어도 하나의 트랜잭션 명령어를 정의하는, 시스템.
- 제4항에 있어서, 상기 스마트 계약은 실행을 위해 상기 체인코드를 호출하는, 시스템.
- 제4항에 있어서, 상기 스마트 계약은 상기 체인코드로부터 데이터 조작 언어(DML) 판독 동작들을 개시하는, 시스템.
- 제1항에 있어서, 상기 스마트 계약으로부터의 상기 관계형 데이터베이스 관리 질의는 상기 스마트 계약에 의해 실행되는 구조화된 질의 언어(SQL) 질의를 포함하는, 시스템.
- 제7항에 있어서, 상기 적어도 하나의 프로세서는 상기 SQL 질의를 SQL 데이터 조작 언어(SQL DML) 기입 동작, SQL DML 판독 동작, 또는 SQL 데이터 정의 언어(SQL DDL) 동작 중 하나를 포함하는 SQL 동작으로 파싱하는 것, 및 상기 SQL 동작의 JSON(JavaScript Object Notation) 표현 및 상기 SQL 동작에 포함되는 임의의 관계형 데이터를 생성하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제8항에 있어서, 상기 적어도 하나의 프로세서는 상기 SQL 동작의 실행으로부터 초래되는 트랜잭션이 플랫폼 관련 범위까지 상기 분산형 원장으로의 수락을 위해 진행했는지 여부를 결정하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제9항에 있어서, 상기 적어도 하나의 프로세서는 대응하는 트랜잭션의 더 명확한 상태를 페치하기 위해 DML 기입 동작의 끝에 동작 브로드캐스트 상태(OPSTAT) 명령어를 추가하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제8항에 있어서, 상기 분산형 원장 상의 상기 데이터베이스 상에서 상기 트랜잭션을 실행하는 것은 상기 스마트 계약이 상기 트랜잭션을 수행할 권한을 갖는다는 것을 확인하기 위한 명령어들을 실행하는 것을 포함하는, 시스템.
- 제8항에 있어서, 상기 분산형 원장 상의 상기 데이터베이스 상에서 상기 트랜잭션을 실행하는 것은 상기 SQL 동작 및 그의 결과의 JSON 표현으로서 상기 분산형 원장 플랫폼에 의해 처리 및 저장될 수 있는 SQL 동작을 생성하기 위한 명령어들을 실행하는 것을 포함하는, 시스템.
- 제8항에 있어서, 상기 SQL 동작은 SQL DML 기입 동작이고, 상기 적어도 하나의 프로세서는 상기 SQL DML 기입 동작을 실행하기 위해 상기 분산형 원장으로부터 데이터를 검색하는 것, 상기 검색된 데이터를 포함하는 상기 SQL DML 기입 동작을 실행하는 것, 상기 트랜잭션 결과에서 임의의 새로운 또는 업데이트된 레코드들의 JSON 표현들을 준비하는 것, 및 상기 분산형 원장 상의 포함을 위해 상기 분산형 원장 상의 상기 데이터베이스에 의해 처리될 수 있는 형태로 상기 SQL DML 기입 동작 및 임의의 업데이트된 레코드들을 상기 분산형 원장에 커밋하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제13항에 있어서, 상기 적어도 하나의 프로세서는 상기 분산형 원장으로의 수락을 위한 상기 SQL DML 기입 동작의 진행에 대해 상기 분산형 원장을 모니터링하는 것, 및 상기 SQL DML 기입 동작이 플랫폼 관련 범위까지 상기 진행을 행했는지를 상기 스마트 계약에 통보하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제8항에 있어서, 상기 SQL 동작은 SQL DML 판독 동작이고, 상기 적어도 하나의 프로세서는 상기 SQL DML 판독 동작을 실행하기 위해 상기 분산형 원장으로부터 데이터를 검색하는 것, 상기 검색된 데이터를 포함하는 상기 SQL DML 판독 동작을 실행하는 것, 상기 트랜잭션 결과의 JSON 표현을 준비하는 것, 및 상기 분산형 원장 상의 포함을 위해 상기 분산형 원장 상의 상기 데이터베이스에 의해 처리될 수 있는 형태로 상기 트랜잭션 결과의 상기 JSON 표현을 상기 분산형 원장에 로그처리하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제15항에 있어서, 상기 적어도 하나의 프로세서는 상기 트랜잭션 결과의 상기 JSON 표현을 상기 스마트 계약에 반환하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
- 제5항에 있어서, 상기 스마트 계약은 상기 분산형 원장 상에서 상기 데이터베이스의 관계형 데이터베이스 관리 질의들의 SQL 질의들의 적어도 서브세트를 실행하는, 시스템.
- 제1항에 있어서, 상기 스마트 계약은 데이터 조작 언어(DML) 질의들을 실행하는 것, 상기 분산형 원장 상의 상기 데이터베이스를 생성하는 것, 상기 분산형 원장 상의 상기 데이터베이스에 대한 액세스 권한들을 업데이트하는 것, 또는 데이터 정의 언어(DDL) 질의들을 실행하는 것을 포함하는 적어도 하나의 동작을 수행하는, 시스템.
- 제18항에 있어서, 상기 스마트 계약은, 상기 분산형 원장의 데이터 분리를 생성하고, 어느 피어 컴퓨터들이 상기 데이터베이스의 사본을 유지할 것인지를 정의하는 구성 트랜잭션을 실행하고, 상기 데이터베이스에 관한 메타데이터를 기입하는 정규 트랜잭션을 실행함으로써 상기 분산형 원장 상의 상기 데이터베이스를 생성하고, 상기 적어도 하나의 프로세서는 상기 분산형 원장 상의 트랜잭션 데이터 및 상기 트랜잭션 데이터를 수정하기 위한 트랜잭션 명령어들을 정의하는 코드를 생성하는 것을 포함하는 동작들을 수행하기 위한 명령어들을 더 실행하는, 시스템.
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16/544,538 | 2019-08-19 | ||
| US16/544,538 US10726002B1 (en) | 2019-08-19 | 2019-08-19 | Relational data management and organization using DLT |
| US16/899,400 US11657039B2 (en) | 2019-08-19 | 2020-06-11 | Relational data management and organization using DLT |
| US16/899,400 | 2020-06-11 | ||
| PCT/CA2020/051131 WO2021030910A1 (en) | 2019-08-19 | 2020-08-19 | Relational data management and organization using dlt |
| KR1020217026407A KR102364877B1 (ko) | 2019-08-19 | 2020-08-19 | Dlt를 사용한 관계형 데이터 관리 및 구성 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020217026407A Division KR102364877B1 (ko) | 2019-08-19 | 2020-08-19 | Dlt를 사용한 관계형 데이터 관리 및 구성 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20220025243A true KR20220025243A (ko) | 2022-03-03 |
| KR102579802B1 KR102579802B1 (ko) | 2023-09-19 |
Family
ID=71783562
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020217026407A KR102364877B1 (ko) | 2019-08-19 | 2020-08-19 | Dlt를 사용한 관계형 데이터 관리 및 구성 |
| KR1020227004860A KR102579802B1 (ko) | 2019-08-19 | 2020-08-19 | Dlt를 사용한 관계형 데이터 관리 및 구성 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020217026407A KR102364877B1 (ko) | 2019-08-19 | 2020-08-19 | Dlt를 사용한 관계형 데이터 관리 및 구성 |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US10726002B1 (ko) |
| EP (1) | EP3884397A4 (ko) |
| JP (1) | JP2022521915A (ko) |
| KR (2) | KR102364877B1 (ko) |
| CN (1) | CN113454619A (ko) |
| CA (1) | CA3125065C (ko) |
| MX (1) | MX2021009969A (ko) |
| SG (1) | SG11202106858TA (ko) |
| WO (1) | WO2021030910A1 (ko) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11436039B2 (en) * | 2019-05-04 | 2022-09-06 | Prasaga Foundation | Systemic extensible blockchain object model comprising a first-class object model and a distributed ledger technology |
| US11606442B2 (en) | 2019-06-07 | 2023-03-14 | Microsoft Technology Licensing, Llc | Subscription to edits of blockchain transaction |
| US20210042737A1 (en) * | 2019-08-07 | 2021-02-11 | Seatig Inc. | Distributed computing architecture with settlement mechanism to enable traceability of credit tokenization, disbursement and repayment |
| US11461324B2 (en) * | 2019-08-29 | 2022-10-04 | Oracle International Corporation | First futamura projection in the context of SQL expression evaluation |
| US11442957B2 (en) * | 2019-09-03 | 2022-09-13 | Sap Se | Cloud-based fiscal year variant conversion |
| US11115804B2 (en) * | 2019-10-04 | 2021-09-07 | Microsoft Technology Licensing, Llc | Subscription to dependencies in smart contracts |
| US11641364B2 (en) * | 2020-03-03 | 2023-05-02 | International Business Machines Corporation | Cross-domain state synchronization |
| US20210279690A1 (en) * | 2020-05-29 | 2021-09-09 | II Darrell Thompson | Pathfinder |
| US11630649B2 (en) * | 2020-06-02 | 2023-04-18 | International Business Machines Corporation | Intelligent application library management |
| US20210406876A1 (en) * | 2020-06-30 | 2021-12-30 | International Business Machines Corporation | Permissioned eventing in a decentralized database |
| US11475010B2 (en) * | 2020-09-09 | 2022-10-18 | Self Financial, Inc. | Asynchronous database caching |
| US11470037B2 (en) | 2020-09-09 | 2022-10-11 | Self Financial, Inc. | Navigation pathway generation |
| US20220075877A1 (en) | 2020-09-09 | 2022-03-10 | Self Financial, Inc. | Interface and system for updating isolated repositories |
| US11641665B2 (en) | 2020-09-09 | 2023-05-02 | Self Financial, Inc. | Resource utilization retrieval and modification |
| US11386053B2 (en) * | 2020-10-15 | 2022-07-12 | Google Llc | Automatic generation of a data model from a structured query language (SQL) statement |
| WO2022125595A1 (en) * | 2020-12-07 | 2022-06-16 | Deixis, PBC | Heterogeneous integration with distributed ledger blockchain services |
| US20220368533A1 (en) * | 2021-05-16 | 2022-11-17 | CodeNotary Inc. | System and method to cryptographically validate rich query results |
| US11599532B1 (en) * | 2021-08-11 | 2023-03-07 | Amdocs Development Limited | System, method, and computer program for preventing user mistakes when making database changes |
| US11704312B2 (en) * | 2021-08-19 | 2023-07-18 | Microsoft Technology Licensing, Llc | Conjunctive filtering with embedding models |
| US11972012B2 (en) * | 2021-08-31 | 2024-04-30 | Sap Se | Authorization check for nested queries in database systems |
| US20230076875A1 (en) * | 2021-09-03 | 2023-03-09 | International Business Machines Corporation | Avoiding data page updates after an insertion operation |
| CN113626850B (zh) * | 2021-10-13 | 2022-03-11 | 北京百度网讯科技有限公司 | 基于联盟链的请求处理方法、装置、设备和存储介质 |
| CN113918996B (zh) * | 2021-11-24 | 2024-03-26 | 企查查科技股份有限公司 | 分布式数据处理方法、装置、计算机设备和存储介质 |
| US20230283488A1 (en) * | 2022-03-01 | 2023-09-07 | DLT Global, Inc. | Blockchain rules engine |
| US11641280B1 (en) * | 2022-06-21 | 2023-05-02 | Northern Trust Corporation | Computing technologies for enabling blockchain-based digital tokens with asset-specific attributes |
| US20240160635A1 (en) * | 2022-11-11 | 2024-05-16 | Microsoft Technology Licensing, Llc | Distributed query technique to efficiently retrieve and merge data from multiple shards |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160371319A1 (en) * | 2015-06-19 | 2016-12-22 | Sap Se | Synchronization on reactivation of asynchronous table replication |
| US20190158594A1 (en) * | 2017-11-20 | 2019-05-23 | Moshe Shadmon | System and apparatus to manage data using a peer-to-peer network and the blockchain |
| US20190179939A1 (en) * | 2017-12-11 | 2019-06-13 | International Business Machines Corporation | Distributed database having blockchain attributes |
| US20190238525A1 (en) * | 2018-01-31 | 2019-08-01 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4326303B2 (ja) * | 2003-11-04 | 2009-09-02 | 株式会社クレオ | データベース移行装置及びそのプログラム |
| US11042560B2 (en) * | 2016-06-19 | 2021-06-22 | data. world, Inc. | Extended computerized query language syntax for analyzing multiple tabular data arrangements in data-driven collaborative projects |
| US10621233B2 (en) * | 2016-11-09 | 2020-04-14 | Cognitive Scale, Inc. | Cognitive session graphs including blockchains |
| US10831764B2 (en) * | 2017-12-02 | 2020-11-10 | International Business Machines Corporation | Query processing and access control in a blockchain network |
| US11257073B2 (en) * | 2018-01-31 | 2022-02-22 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment |
| US20190236606A1 (en) * | 2018-01-31 | 2019-08-01 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing a virtual chain model for distributed ledger technologies in a cloud based computing environment |
| CN108616578A (zh) * | 2018-04-09 | 2018-10-02 | 上海点融信息科技有限责任公司 | 跨区块链平台的业务处理方法、设备及计算机可读存储介质 |
| CN108563796A (zh) * | 2018-05-04 | 2018-09-21 | 蔷薇信息技术有限公司 | 区块链的数据压缩处理方法、装置及电子设备 |
| CN114662159A (zh) * | 2018-10-26 | 2022-06-24 | 蚂蚁双链科技(上海)有限公司 | 一种数据的处理方法、装置及设备 |
| CN109492053B (zh) * | 2018-11-08 | 2023-07-18 | 北京百度网讯科技有限公司 | 用于访问数据的方法和装置 |
-
2019
- 2019-08-19 US US16/544,538 patent/US10726002B1/en active Active
-
2020
- 2020-06-11 US US16/899,400 patent/US11657039B2/en active Active
- 2020-08-19 WO PCT/CA2020/051131 patent/WO2021030910A1/en unknown
- 2020-08-19 SG SG11202106858TA patent/SG11202106858TA/en unknown
- 2020-08-19 EP EP20855133.3A patent/EP3884397A4/en active Pending
- 2020-08-19 CN CN202080015222.4A patent/CN113454619A/zh active Pending
- 2020-08-19 KR KR1020217026407A patent/KR102364877B1/ko active IP Right Grant
- 2020-08-19 KR KR1020227004860A patent/KR102579802B1/ko active IP Right Grant
- 2020-08-19 CA CA3125065A patent/CA3125065C/en active Active
- 2020-08-19 MX MX2021009969A patent/MX2021009969A/es unknown
- 2020-08-19 JP JP2021549147A patent/JP2022521915A/ja active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160371319A1 (en) * | 2015-06-19 | 2016-12-22 | Sap Se | Synchronization on reactivation of asynchronous table replication |
| US20190158594A1 (en) * | 2017-11-20 | 2019-05-23 | Moshe Shadmon | System and apparatus to manage data using a peer-to-peer network and the blockchain |
| US20190179939A1 (en) * | 2017-12-11 | 2019-06-13 | International Business Machines Corporation | Distributed database having blockchain attributes |
| US20190238525A1 (en) * | 2018-01-31 | 2019-08-01 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment |
Also Published As
| Publication number | Publication date |
|---|---|
| SG11202106858TA (en) | 2021-07-29 |
| KR102364877B1 (ko) | 2022-02-17 |
| WO2021030910A1 (en) | 2021-02-25 |
| US20210056095A1 (en) | 2021-02-25 |
| CA3125065A1 (en) | 2021-02-25 |
| JP2022521915A (ja) | 2022-04-13 |
| MX2021009969A (es) | 2021-09-21 |
| CA3125065C (en) | 2023-11-28 |
| EP3884397A4 (en) | 2022-01-19 |
| CN113454619A (zh) | 2021-09-28 |
| KR20210146890A (ko) | 2021-12-06 |
| US11657039B2 (en) | 2023-05-23 |
| KR102579802B1 (ko) | 2023-09-19 |
| EP3884397A1 (en) | 2021-09-29 |
| US10726002B1 (en) | 2020-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102364877B1 (ko) | Dlt를 사용한 관계형 데이터 관리 및 구성 | |
| US11899817B2 (en) | Systems, methods, and apparatuses for storing PII information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information | |
| US11824970B2 (en) | Systems, methods, and apparatuses for implementing user access controls in a metadata driven blockchain operating via distributed ledger technology (DLT) using granular access objects and ALFA/XACML visibility rules | |
| US11469886B2 (en) | System or method to implement record level access on metadata driven blockchain using shared secrets and consensus on read | |
| US11886421B2 (en) | Systems, methods, and apparatuses for distributing a metadata driven application to customers and non-customers of a host organization using distributed ledger technology (DLT) | |
| US11803537B2 (en) | Systems, methods, and apparatuses for implementing an SQL query and filter mechanism for blockchain stored data using distributed ledger technology (DLT) | |
| US11783024B2 (en) | Systems, methods, and apparatuses for protecting consumer data privacy using solid, blockchain and IPFS integration | |
| US20210243193A1 (en) | Systems, methods, and apparatuses for implementing consensus on read via a consensus on write smart contract trigger for a distributed ledger technology (dlt) platform | |
| US20200034353A1 (en) | System and method for supporting sql-based rich queries in hyperledger fabric blockchains | |
| US20200387627A1 (en) | Multi-user database system and method | |
| Yussupov et al. | Protecting Deployment Models in Collaborative Cloud Application Development | |
| Khinchi | Evaluating various transaction processing characteristics of permissioned blockchain networks | |
| Liljefors et al. | Formalizing security properties in blockchain protocols |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A107 | Divisional application of patent | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |