블록체인 vs. 분산 원장 기술 Part2: 지배 역학 (1) ~ (2)
블록체인 vs. 분산 원장 기술 Part2: 지배 역학
이더리움(Ethereum), 하이퍼레져 페브릭(Hyperledger Fabric), R3 코다(Rc Corda)에 대한 아키텍쳐 고려사항
원문 Blockchain vs. Distributed Ledger Technologies Part 2: Governing Dynamics
번역 @partykim
기획 @krexchange
by 브랜트 수(Breant xu)-ConsenSys, 프로토콜 비지니스 설계자, 벌컨 리서치 (Vulkan Research) CRO : 덴드로비움 프로젝트(Dendrobium Project)
컨센시스 미디어(ConsenSys Media)의 블록체인 vs 분산화 원장 기술 Part1을 읽으세요.
Part2 연재
- 번역 수정 사항이 있어 1편을 같이 올립니다.
블록체인 vs. 분산 원장 기술 플랫폼
데이터베이스 조정과 더 효율적인 코드의 할당이 시스템이 원하는 기능이라면 블록체인은 조직이 필수적으로 찾고 있는 솔루션이 아니라는 것을 인정해야합니다. IBM Fabric 또는 R3Corda와 같은 분산 원장 기술 (DLT) 시스템은 블록체인 시스템과 유사한 기능을 수행 할 수 있지만 블록체인은 코드조정을 넘어서는 추가기능을 가진 분산원장의 분리된 하위집합이라는 것을 고려해야 합니다. 블록체인은 시스템의 구성에 따른 디지털 값의 인스턴스 생성 관련하여 분산 원장이 수행하지 못하는 기능을 수행 할 수 있습니다.
이 문서에서는 블록체인 기능에 기여하는 부분을 확인하는 아키텍쳐 고려사항에 대해 탐구합니다. 아마도 블록체인이 달성 가능한 것과 DLT가 제공하는 것 사이의 트레이드 오프(Trade-off)에 대한 조사가 될 것입니다. DLT는 신뢰할 수 있는 공유 환경에서의 트랜잭션 처리를 위한 것이었지만, 진정한 블록체인은 높은 충실도(High-Fidelity)와 계정의 불변성을 달성하기 위해 신뢰할 수 있는 설정의 필요성을 희생하도록 설계되었습니다. 높은 충실도(High-Fidelity)와 불변의 측면은 적절하게 디지털화된 자산의 성공에 필수적입니다. 이 문서에서 분석한 내용은 여러 비즈니스 프로세스 전반의 아키텍처 구성 요소를 통합하여 플랫폼 전체의 기술적 차이를 더욱 명확히 설명합니다.
그림1: 어떻게 기능과 사용사례 측면에서 비교하고 기술스택 사이에 구분짓는 것은 매우 중요합니다. 분산 원장 기술은 블록체인 기술의 영향을 많이 받아 왔지만, 기술 플랫폼의 아키텍쳐 고려 사항을 구분해야 합니다.
비교는 소프트웨어 플랫폼 내에 존재하는 몇 가지 주요 구별되는 특징들을 기반으로 이루어질 것입니다. 이 문서에서 살펴볼 주요 영역은 다음과 같습니다.
상태(State): 컴퓨팅 환경에서 정보를 쉽게 표현할 수 있도록 코드를 구성 할 수있는 논리의 기본 단위입니다. 상태는 다양한 상황에서 다양한 의미를 가질 수 있지만, 블록체인과 분산 원장 환경에서의 상태의 사용은 데이터 구조의 온톨로지(Ontological) 특성의 최근 구성으로 이루어집니다.
트랜잭션(Transactions): 블록체인 환경에서 트랜잭션은 개발 환경 내에서 상태 발생 또는 상태 변환를 유도 할 수있는 컴퓨팅 이벤트로 간주됩니다. 트랜잭션은 계약을 시작하거나 기존 계약을 요청할 수 있습니다.
스마트 컨트랙트(Smart Contracts): 아키텍처 관점에서 블록체인 플랫폼을 평가할 때는 스마트 계약 코드의 구조와 실제 블록체인 네트워크 토폴로지와 관련하여 어떻게 작동하는지를 결정하는 것이 중요합니다. 스마트 컨트랙트는 플랫폼 생태계 내에서 작업을 실행하는 개별 코드 단위로 간주됩니다.
다음 표에서는 각 플랫폼의 다양한 기술적 기능 간의 주요 차이점을 간략히 보여 줍니다.
I. 상태(State)
이더리움(Ethereum)
이더리움은 공유 분산 구성을 가진 생태계로서 "계정"이라는 개체 구성을 통해 "상태"개념을 인스턴스화합니다. 이더리움에는 두 가지 유형의 계정이 있습니다.
- 컨트랙트 계정 : 컨트랙트 코드로 관리되는 계정
- 외부 소유 계정: 개인 키로 관리되는 계정
이더리움은 계정 주소와 계정 상태의 매핑 인 World State의 개념을 사용합니다.
State_Root는 시스템에서 계정을 병합하는 패트리샤 머클 트리 루트입니다. 그리고 계정안에는 컨트랙트 상태가 패트리샤 머클 트리 데이터 구조안에 구성이 됩니다. 상태의 루트 해시는 궁극적으로 시스템의 불변성을 가져오는 네트워크 전체의 복제를 허용하는 머클 트리의 데이터 아이덴티티를 보호하는데 사용이 됩니다.
논평(Commentary)
이더리움 World State가 생성하는 기능은 가치를 디지털 형태로 인스턴스화하는 것을 허용하는 신뢰가 필요없는 시스템입니다. 토큰 경제에서 만들어진 디지털로 대표되는 가치의 근원은 기존의 엔지니어링에서 논리 게이트가 기능적 알고리즘을 인스턴스화 할 수 있는것과 같은 방식으로 이더리움의 하위 데이터 구조와 계정의 구성으로 부터 만들어졌습니다. 프라이빗 구성과 이더리움 클라이언트를 포함한 이더리움에서 파생 된 플랫폼들은 로직 구성과 상태 보존에 대한 기준의 확신으로 가치를 인스턴스화하는 것으로 가치를 실현할 수 있습니다. 이러한 논리 가치 기반 기능 중 하나를 인스턴스화하지 못한 플랫폼은 진정한 분산형 디지털 자산 가치를 창출하지 못하게됩니다.
IBM Fabric
IBMFabric에서 상태는 상태에 대한 키/값 저장소에 의존하여 데이터베이스 구조로 보관됩니다. 체인코드 프로그램과 이 프로그램이 플랫폼 토폴로지에 설치되는 방법 사이의 상호 작용을 통해 시스템에 명령과 동작을 실행할 수 있습니다. 이러한 작업은 트랜잭션으로 인해 원장이라고 하는 상태로 업데이트되므로 데이터저장소에 업데이트를 생성합니다. 원장은 분산 컴퓨팅 환경에서 발생하는 정보 및 트랜잭션에 대한 뛰어난 액세스 권한을 사용자에게 제공하는 공유 분산 데이터베이스로 구성됩니다. 상태는 기존 소프트웨어 개발 도구를 통해 데이터베이스 환경 내에 중첩됩니다.
- LevelDB는 키/값 데이터베이스를 생성합니다.
- CouchDB는 문서 JSON 데이터베이스를 보유합니다.
Fabric 아키텍처에서 모든 프로세스가 구성되는 데이터베이스 형식은 트랜잭션 처리를 향상시키고 생태계에서 컴퓨팅 효율성을 극대화할 수 있습니다.
상태 데이터베이스에서 체인 트랜잭션 로그의 키에 대한 최신 버전 값은 키 / 값 쌍으로 저장됩니다. World State 라고 알려진 키 값은 채널 아키텍처에 존재하는 트잰잭션 로그를 보기위해 색인화 됩니다. CouchDB는 체인코드 API의 업데이트를 받는 별개의 데이터 프로세스로 작동합니다.
논평(Commentary)
IBM Fabric은 높은 처리량 상태 변환을 달성하는 대신 블록체인 시스템의 주요 원리를 대체하는 프로세스를 만들었습니다. 현재 아키텍처를 사용하면 기존 소프트웨어 스키마 내에서 상태를 보다 쉽게 수정하고 표시할 수 있으므로 읽기/쓰기 액세스가 가능합니다. Fabric 환경 내에서 상태를 구성하는 것은 효율적이지만, 이더리움이나 비트코인과 같은 진정한 블록체인과 같은 방식으로 퍼블릭 분산화 생태계에 가치를 인스턴스화하는 기능이 부족합니다. Fabric의 소프트웨어 환경에서 데이터가 이동하는 것은 분산 데이터베이스가 무엇을 할 수 있는지를 나타냅니다. Fabric 내에서 디지털 자산을 생성하는 것은 기본적으로 디지털 상품의 경제적 구조를 고수하지 않고 컨소시엄 내에서 관리 당사자 또는 그룹에 의해 제어되는 데이터베이스에 저장되는 디지털 정보일 것입니다.
R3 Corda
R3Corda에서 상태는 플랫폼 아키텍처 내에서 서로 다른 데이터 조합의 시퀀싱 및 버저닝(Versioning)을 기반으로 합니다. 이 시스템에서 네트워크는 시스템 내에서 추적하는 과거 상태를 저장하는 데이터베이스인 Vault를 유지 관리합니다. Corda 에서는 새로운 뒤를 잇는 것을 만들기 보다, 상태는 업데이트될 필요가 없는 디스크 파일과 비슷한 불명료한 데이터를 포함하는 것으로 간주됩니다. 이 시스템은 사용자가 공유하고 조작하는 환경에서 수정되고 재처리된 상태 업데이트의 연속으로 작동합니다.
원장은 활성화된 모든 현재 상태의 구성으로 여겨집니다. 이것은 코어에 반대되는 플랫폼의 하위 섹션에서 일부 기술을 사용하지만, 블록체인 기술에 있는 패트리샤 머클 트리의 특성을 보존하는 같은 상태를 구성하지 않는 비트코인 UTXO로 부터 차용한 것입니다. 상태는 볼트(Vault)에 저장된 클래스의 인스턴스로 작동하지만 데이터의 시퀀싱과 버저닝(Versioning)은 데이터를 저장할 수 있는 실행 가능한 방법을 제공합니다.
Corda에서 상태는 데이터를 저장하는 클래스로 여겨집니다. 클래스는 플랫폼에서 상호운영성(Interoperability) 계층으로 작동 하는 "ContractState"의 인터페이스의 구현입니다. 특정한 "상태" 데이터필드는 다음을 포함할 수 있습니다.
- 발행물
- 소유자
faceValue and Amount<Issued<Currency>>- 만기일
이러한 형식의 설계는 체인의 이벤트에 데이터를 첨부할 수 있도록 하여 통제된 환경에서 데이터가 발생하는 출처를 추적할 수 있도록 하는 것이었습니다. 출처는 소프트웨어플랫폼의 특정한 접근권한을 가진 컨소시엄 멤버들에 의해 통제됩니다. 이러한 설정을 사용해 은행과 금융 기관은 공유 원장 생태계에서 정보 처리의 측면에서 효율성을 극대화할 수 있을 것입니다. 신뢰할 수 없는 상대방 간에 상당한 신뢰를 받아야 하는 필요성을 줄이면서 조직간에 데이터를 보다 효율적으로 이동하고 처리할 수 있습니다.
논평(Commentary)
이러한 아키텍처 설정은 상대방이 서로 완전히 신뢰할 필요가 없는 반 신뢰된(Semi-trusted) 환경에서 공유 데이터를 처리할 수 있는 것과 유사합니다. 데이터는 성공적으로 Corda가 상태로 여기는 것에 처리되고 첨부될 수 있지만, 플랫폼은 모호한 값을 공개할 수 있는 블록체인 시스템의 구성요소가 부족합니다. Corda에서 상태는 논리 구조가 아니라 오히려 데이터 베이스와 같은 원장에 첨부 된 데이터 조각입니다. 자산은 사용되거나 또는 사용되지않은 상태의 형식으로 디지털화되어 저장될 수 있지만, 이 자산은 비트코인이나 이더리움 그리고 새로운 시장을 형성하는 토큰 경제와 같은것 처럼 개별의 가치단위가 될 수 없습니다. 하지만 오늘날 현재 작동하는 뱅킹 시스템과 비슷하게 안전한 공개적이지 않은 정보를 위한 공증허브로 작동해 신뢰받는 뱅킹 소프트웨어의 구성이 될 수 있습니다.
3편으로 이어집니다.
*본 번역은 스티미언들의 후원으로 이루어졌습니다.
*후원해 주시면 더 많은 글을 번역하고 게시할 수 있습니다.
블록체인 vs. 분산 원장 기술 플랫폼 데이터베이스에 대해 관심이 가네요. 감사합니다!