블로그 1뉴스 개발자 엔터프라이즈 블록 체인 설명 이벤트 및 컨퍼런스 보도 자료뉴스 레터

뉴스 레터 구독.

이메일 주소

우리는 귀하의 개인 정보를 존중합니다

홈 블로그 엔터프라이즈 블록 체인

블록 체인 대 분산 원장 기술 (DLT) : 2 부

Ethereum, Hyperledger Fabric 및 R3 Corda의 아키텍처 및 지배 역학에 대한 비교 분석 .by ConsenSys May 23, 2018Posted on May 23, 2018

블록 체인 dlt 2 영웅

이것은 Ethereum, Hyperledger Fabric 및 R3 Corda의 두 부분으로 구성된 비교 분석의 파트 2입니다. 블록 체인과 DLT의 파트 1 읽기. 

블록 체인 vs. 분산 원장 기술 플랫폼

데이터베이스 조정과보다 효율적인 코드 할당이 시스템의 원하는 기능이라면 블록 체인이 반드시 조직이 찾고있는 솔루션이 아닐 수도 있다는 점을인지해야합니다. Hyperledger Fabric 또는 R3 Corda와 같은 분산 원장 기술 (DLT) 시스템은 블록 체인 시스템과 유사한 기능을 수행 할 수 있지만 블록 체인은 코드 조정 이상의 추가 기능을 가진 분산 원장의 별도 하위 집합이라는 점을 고려해야합니다. 블록 체인은 분산 원장이 시스템 구성에 따른 디지털 가치의 인스턴스화 측면에서 볼 수없는 기능을 수행 할 수 있습니다..

이 문서에서는 블록 체인 기능에 기여하는 측면을 식별하는 아키텍처 고려 사항을 살펴 봅니다. 블록 체인이 수행 할 수있는 것과 DLT가 제공하는 것 사이에 상충 관계가있을 수 있습니다. DLT는 신뢰할 수있는 공유 환경에서 트랜잭션 처리를위한 것이었고 진정한 블록 체인은 계정의 높은 충실도와 불변성을 달성하기 위해 신뢰할 수있는 설정의 필요성을 희생하도록 설계되었습니다. 높은 충실도와 불변성의 측면은 자산을 적절하게 디지털화하는 데 필수적입니다. 이 문서의 분석은 플랫폼 전반에 걸쳐 이러한 기술적 뉘앙스를 더욱 명확하게하기 위해 비즈니스 프로세스 전반에 걸쳐 아키텍처 구성 요소를 오버레이합니다..

그림 1 기술 스택과 기능 및 사용 사례를 비교하는 방법을 구별하는 것이 중요합니다. 분산 원장 기술은 블록 체인 기술의 영향을 많이 받았지만 기술 플랫폼의 아키텍처 고려 사항을 구별해야합니다.기술 스택과 기능 및 사용 사례 측면에서 비교하는 방법을 구분하는 것이 중요합니다. 분산 원장 기술은 블록 체인 기술의 영향을 많이 받았지만 기술 플랫폼의 아키텍처 고려 사항을 구별해야합니다..

소프트웨어 플랫폼 내에 존재하는 몇 가지 주요 구별 기능을 기반으로 비교가 이루어집니다. 이 문서에서 살펴볼 주요 영역은 다음과 같습니다.

  • 상태: 상태는 컴퓨팅 환경에서 정보 표현을 용이하게하기 위해 코드를 구성 할 수있는 논리의 기본 단위를 의미합니다. 상태는 다른 맥락에서 다양한 의미를 가질 수 있지만, 블록 체인 및 분산 원장 환경에서 상태 사용은 데이터 구조의 존재 론적 특성의 현재 구성으로 구성됩니다..
  • 업무: 블록 체인 환경 내에서 트랜잭션은 개발 생태계 내에서 발생하는 상태 또는 상태 전환의 생성으로 이어질 수있는 계산 이벤트로 간주됩니다. 거래는 계약을 시작하거나 기존 계약을 요청할 수 있습니다..
  • 스마트 계약: 아키텍처 관점에서 블록 체인 플랫폼을 평가할 때 스마트 계약 코드의 구조와 실제 블록 체인 네트워크 토폴로지와 관련하여 작동하는 방식을 결정하는 것이 중요합니다. 스마트 계약은 플랫폼 생태계 내에서 작업을 실행하는 개별 코드 단위로 간주됩니다..

다음 표는 각 플랫폼의 다양한 기술적 기능 간의 주요 차이점에 대한 간략한 개요를 보여줍니다..

플랫폼 기능Ethereum, Hyperledger Fabric 및 R3 Corda의 기술적 기능에 대한 개요.

I. 상태

이더 리움

공유 된 분산 구성이있는 생태계로서 Ethereum은 “계정”이라는 개체 구성을 통해 “상태”개념을 인스턴스화합니다. Ethereum에는 두 가지 유형의 계정이 있습니다.

  • 계약 계정 — 계약 코드로 제어되는 계정
  • 외부 소유 계정 — 개인 키로 제어되는 계정

이더 리움은 계정 주소와 계정 상태의 매핑 인 World State 개념을 사용합니다. State_Root는 시스템에서 계정 통합의 Patricia Merkle Tree 루트입니다. 그리고 계정 내에서 계약 상태는이 Patricia Merkle Tree 데이터 구조에서도 구성됩니다. 상태의 루트 해시는 머클 트리에있는 데이터의 ID를 보호하는 데 사용할 수 있으므로 네트워크 전체에 복제를 허용하여 궁극적으로 시스템의 이론적 불변성을 초래합니다..

진정한 블록 체인은이 Patricia Merkle Tree 데이터 구조에 대한 의존도와 시스템 상태를 인스턴스화하는 데 사용되는 블록 간의 오케스트레이션에 따라 DLT와 구별됩니다.이 개념은 블록 체인 시스템 아키텍처의 데이터 무결성 유효성 및 충실도에 필수적입니다.진정한 블록 체인은이 Patricia Merkle Tree 데이터 구조에 대한 의존도와 시스템 상태를 인스턴스화하는 데 사용되는 블록 간의 오케스트레이션에 따라 DLT와 구별됩니다. 이 개념은 블록 체인 시스템 아키텍처의 데이터 무결성, 유효성 및 충실도에 필수적입니다..

해설

Ethereum World State가 만드는 기능은 디지털 형식으로 가치를 인스턴스화 할 수있는 신뢰할 수없는 시스템입니다. 토큰 이코노미 고유의 디지털 표현 가치의 출처는 이더 리움의 계정 구성과 하위 데이터 구조에서 파생 될 수 있습니다. 논리 게이트가 기존 엔지니어링에서 기능적 알고리즘을 인스턴스화 할 수있는 것과 동일한 방식.

Ethereum 클라이언트 및 개인 구현을 포함하여 Ethereum에서 파생 된 플랫폼은 상태 보존 및 논리 구현과 관련하여 이러한 표준에 대한 확신을 통해 이러한 가치 인스턴스화의 이점을 누릴 수 있습니다. 이러한 논리적 가치 기반 기능 중 하나를 인스턴스화하지 못하는 플랫폼은 진정한 탈 중앙화 디지털 자산 가치의 생성을 촉진 할 수 없습니다..

하이퍼 레저 패브릭

Hyperledger Fabric에서 상태는 상태에 대한 키 / 값 저장소에 의존하여 데이터베이스 구조에 보존됩니다. Chaincode 프로그램 간의 상호 작용과 플랫폼 토폴로지에 설치되는 방법을 통해 시스템에 명령과 작업을 실행할 수 있습니다. 이러한 작업으로 인해 트랜잭션이 원장이라고하는 상태가 업데이트되므로 데이터 저장소가 업데이트됩니다. 원장은 분산 컴퓨팅 환경에서 발생하는 정보 및 트랜잭션에 대한 우수한 액세스를 사용자에게 제공하는 공유 분산 데이터베이스로 구성됩니다. 상태는 기존 소프트웨어 개발 도구를 통해 데이터베이스 환경 내에 중첩됩니다.

  • LevelDB는 키 / 값 데이터베이스를 생성합니다.
  • CouchDB는 문서 JSON 데이터베이스를 보유합니다.

패브릭 아키텍처패브릭 아키텍처에서 모든 프로세스가 구성되는 방식에 대한 데이터베이스 형식은 트랜잭션 처리를 증가시키고 에코 시스템에서 계산 효율성을 극대화 할 수 있습니다..

상태 데이터베이스에서 체인 트랜잭션 로그의 키에 대한 최신 버전 값은 키 / 값 쌍으로 저장됩니다. World State로 알려진 키 값은 채널 아키텍처 내에 존재하는 트랜잭션 로그를보기 위해 인덱싱됩니다. CouchDB는 체인 코드 API에서 업데이트를 수신하는 별도의 데이터베이스 프로세스로 작동합니다..

해설

Hyperledger Fabric은 높은 처리량의 상태 전환을 달성하는 대가로 블록 체인 시스템의 핵심 원칙을 대체하는 프로세스를 만들었습니다. 현재 아키텍처를 사용하면 상태를보다 쉽게 ​​수정하고 기존 소프트웨어 스키마 내에서 명시 할 수 있으므로 읽기 / 쓰기 액세스가 가능합니다. Fabric 환경 내의 상태 배열은 효율적이지만 Ethereum 또는 Bitcoin과 같은 진정한 블록 체인이 할 수있는 것과 같은 방식으로 공공 분산 생태계에서 가치를 인스턴스화하는 기능이 부족합니다. Fabric의 소프트웨어 환경에서 데이터 이동은 분산 데이터베이스가 무엇을 할 수 있는지를 나타냅니다. Fabric 내에서 디지털 자산을 생성하는 것은 본질적으로 디지털 상품의 경제 구조를 고수하지 않고 컨소시엄 내의 제어 당사자 또는 그룹이 제어하는 ​​데이터베이스에 저장된 디지털 정보입니다..

R3 Corda

R3 Corda에서 State는 플랫폼 아키텍처 내에서 다양한 데이터 세트의 시퀀싱 및 버전 관리를 기반으로합니다. 시스템에서 네트워크는 시스템 내에서 추적되는 과거 상태를 저장하는 데이터베이스 인 Vault를 유지합니다. Corda에서 상태는 새 후속 작업을 생성하는 데 사용되지만 반드시 업데이트되지는 않은 디스크 파일과 유사한 불투명 한 데이터를 포함하는 것으로 간주됩니다. 이 시스템은 사용자가 제어하고 공유하는 환경 내에서 일련의 수정 및 재 포장 된 상태 업데이트 역할을합니다..

그림 5 원장은 활성화 된 모든 현재 상태의 집합으로 간주됩니다. 비트 코인 UTXO 모델에서 차용하지만 블록 체인 기술에 존재하는 패트리샤 머클 트리의 특성을 보존하는 것과 동일한 상태를 구현하지는 않지만 일부 기술을 사용하지만 코어와 반대되는 플랫폼의 하위 섹션 상태는 볼트에 저장된 클래스의 인스턴스로 작동하지만 데이터의 순서 지정 및 버전 관리는 데이터를 저장하는 실행 가능한 수단을 제공합니다.원장은 활성화 된 모든 현재 상태의 집합으로 간주됩니다. 이는 비트 코인 UTXO 모델에서 차용하지만, 코어가 아닌 플랫폼의 하위 섹션에서 일부 기술을 사용하지만 블록 체인 기술에 존재하는 패트리샤 머클 트리의 특성을 보존하는 것과 동일한 상태를 구현하지는 않습니다. 상태는 저장소에 저장된 클래스의 인스턴스 역할을하지만 데이터의 순서 지정 및 버전 관리는 데이터를 저장하는 실행 가능한 수단을 제공합니다..

Corda에서 상태는 데이터를 저장하는 클래스로 간주됩니다. 클래스는 플랫폼 내에서 상호 운용성 레이어 역할을하는 ‘ContractState’인터페이스의 구현입니다. 특정 “상태”데이터 필드에는 다음이 포함될 수 있습니다.

  • 배급
  • 소유자
  • faceValue 및 금액>
  • 만기일

이 디자인의 형식은 이벤트 체인에 데이터를 추가하여 제어 된 환경에서 데이터의 출처를 추적 할 수 있도록하는 것이 었습니다. 출처는 소프트웨어 플랫폼에 대한 특정 액세스 제어 권한이있는 컨소시엄 구성원이 제어합니다. 이 설정을 사용하여 은행 및 금융 기관은 공유 원장 생태계에서 정보 처리 측면에서 효율성을 극대화 할 수 있습니다. 신뢰할 수없는 상대방 간의 실질적인 신뢰 필요성을 줄이면서 조직간에 데이터를 더 잘 이동하고 처리 할 수 ​​있습니다..

해설

이 아키텍처 설정은 유사하게 상대방이 서로를 완전히 신뢰할 필요가없는 반 신뢰 환경에서 공유 데이터를 처리 할 수 ​​있습니다. 플랫폼에는 명확한 가치를 공개 할 수있는 블록 체인 시스템의 구성 요소가 부족하지만 데이터는 성공적으로 처리되고 Corda가 상태로 간주하는 항목에 추가 될 수 있습니다. Corda에서 상태는 논리적 구조가 아니라 데이터베이스와 같은 원장에 추가 된 정보입니다. 자산은 사용 및 사용되지 않은 상태 형식으로 디지털화되고 저장 될 수 있지만, 뱅킹 소프트웨어는 신뢰할 수 있지만 자산은 비트 코인, 이더 리움 및 토큰 이코노미가 새로운 시장을 창출하는 방식과 유사한 고유 한 가치 단위가 될 수 없습니다. 현재 은행 시스템이 현재 작동하는 방식과 유사하게 안전한 비공개 정보에 대한 증명 허브 역할을하는 데 도움이되는 설정.

II. 업무

이더 리움은 거래의 글로벌 상태가 블록 내에 저장되는 거래 기반 기계 생태계입니다. 트랜잭션이 발생하면 상태 전환이 시스템의 새로운 상태로 이어집니다. 이 프로세스는 블록 체인 Patricia Merkle Tree 데이터 구조 구성 내에서 해당 상태로 이어진 트랜잭션은 물론 상태를 상징하는 시스템의 무결성을 위해 빠른 데이터베이스 트랜잭션 처리 속도를 희생합니다..

그림 6이 아키텍처 내에서 상태 전환으로 이어지는 트랜잭션과 함께 상태는 Patricia Merkle Trees를 활용하여 데이터를 블록 내에서 실현되는 역사적 현실로 잠그는 소프트웨어 패러다임에 보존됩니다.이 아키텍처 내에서 상태 전환으로 이어지는 트랜잭션과 함께 상태는 Patricia Merkle Trees를 활용하여 데이터를 블록 내에서 실현되는 역사적 현실로 잠그는 소프트웨어 패러다임에 보존됩니다..

두 가지 유형의 거래가 있습니다.

  • 메시지 호출
  • 계약 생성.

거래에는 가치 이전의 내부 메커니즘이 포함됩니다. 계약 계정 내부의 가치 이전으로 인해 상태가 변경됩니다. 이 시스템은 트랜잭션 실행 이벤트 사이에 존재하는 스마트 계약 간의 가치 이전을 기반으로하기 때문에 다양한 구획화 된 상태를 사용하여 충실도 높은 비즈니스 로직과 계약을 인스턴스화 할 수 있습니다..

해설

이더 리움의 주요 특징은 트랜잭션이 이더 리움 블록 체인 환경 내에서 개별 프로세스 단위로 사용되며이 구성을 통해 시스템 내에서 트랜잭션 상태에 대한 영구적 인 기록을 유지한다는 것입니다. Ethereum은 기존의 분산 원장 데이터베이스 관련 기술 기능뿐만 아니라 원하는 신뢰와 디지털 가치를 결합 할 수 있습니다. 이더 리움 블록 체인에서 파생 된 기술은 트랜잭션과 비즈니스 로직을 블록 체인 블록으로 그룹화 할 수 있습니다. 이 설정에서 파생 된 비즈니스 기능은 다음과 같습니다.

  • 진정한 디지털 경제
  • 조직 / 독점적 인센티브가 아닌 경제적 인센티브로 통제되는 디지털 상품 및 자산
  • 민간 기관과 공공 디지털 경제 간의 상호 작용 인터페이스

Ethereum의 아키텍처를 통해 제휴 플랫폼은 암호화 경제 인센티브 계층을 시스템에 인스턴스화 할 수 있습니다. 즉, 기존 소프트웨어 설계에서 제공하는 중앙 제어 서비스에 의존하는 대신 전체 네트워크를 보호하기 위해 다양한 인센티브 계층 및 메커니즘 설계를 생성 할 수 있습니다. 이 암호화 경제 인센티브 계층은 디지털 상품 경제뿐만 아니라 블록 체인 플랫폼의 개인 및 공용 버전 간의 인터페이스 계층 모두에 적용될 수 있습니다..

하이퍼 레저 패브릭

모든 트랜잭션은 패브릭 다중 채널 아키텍처 내에서 실행되어 신뢰할 수있는 환경 내에서 높은 트랜잭션 처리량을 보장합니다. 트랜잭션은 런타임 환경 내에 존재하는 공유 원장에 추가됩니다. 이 아키텍처를 통해 Fabric은 소프트웨어 환경에 대한 읽기 / 쓰기 액세스 및 가용성을 허용하여 메인 프레임과 같은 기능 및 유용성을 허용합니다. SQL 데이터베이스는 현재 사용 가능한 어떤 블록 체인보다 성능이 몇 배 더 높은 것으로 알려져 있으며 Fabric 구성은 기존 데이터베이스 도구에서 사용되는 패러다임에서 많은 것을 빌려 우수한 트랜잭션 처리량을 허용합니다..

두 가지 유형의 거래가 있습니다.

  • 트랜잭션 배포 — 새 체인 코드를 생성합니다. 소프트웨어 개발 환경에 체인 코드를 설치합니다.
  • 트랜잭션 호출 — 이전에 생성 된 체인 코드와 해당 기능을 호출합니다. 이것이 성공적으로 실행되면 체인 코드는 기능을 수행하고 상태를 변경합니다.
  • 호출 함수는 ‘get’또는 ‘set’트랜잭션을 발생시킵니다.

효율적인 데이터 처리와 우수한 속도를 극대화하기 위해 개별 트랜잭션 AKA blob은 Apache Kafka Ordering Service에 의해 일괄 처리되고 배달 이벤트를 통해 ‘블록’으로 출력됩니다. 트랜잭션 (blob)은 Apache Kafka Ordering Service에 의해 주문되고 Kafka 파티션에 추가됩니다. 이것이 의미하는 바는 Fabric 아키텍처가 Apache Kafka Ordering Service의 사용에서 명백한 것처럼 신뢰할 수있는 데이터 스트리밍 환경 내에서 더 빠른 트랜잭션 처리 및 처리량을 얻기 위해 진정한 블록 체인 시스템의 무결성과 데이터 충실도를 희생한다는 것입니다..

그림 7 Fabric 문서에서 평가할 수 있듯이 주문 된 트랜잭션은 Kafka 주제와 관련된 파티션에 직접 추가됩니다. 이로 인해 신뢰할 수있는 데이터 스트리밍 환경에서 발생하는 높은 처리량 트랜잭션이 발생합니다. Source Apache KafkaFabric 문서에서 평가할 수 있듯이 주문 된 트랜잭션은 Kafka 주제와 관련된 파티션에 직접 추가됩니다. 그 결과 신뢰할 수있는 데이터 스트리밍 환경에서 발생하는 높은 처리량의 트랜잭션이 발생합니다. (출처 : Apache Kafka)

해설

이 시스템은 블록 체인과 같은 용어를 사용하지만 패트리샤 머클 트리 데이터 구조에서 상태 및 상호 보완적인 트랜잭션을 보존하지 않는다는 점에서 전통적인 의미의 블록 체인이 아닙니다. Hyperledger Fabric은 블록 체인이 아닌 DLT입니다. Fabric의 아키텍처는 Kafka 데이터 스트리밍 주문 서비스에 데이터 블록을 추가 할 때 알 수 있듯이 우수한 트랜잭션 처리를 위해 설계되었습니다. 이는 신뢰할 수있는 환경에서 이루어지기 때문에 시스템에서 자유롭게 실행할 수 있습니다. 가치 전송 시스템에서이 구성을 사용하는 것은 모든 신뢰가 공유 에코 시스템이나 프로토콜이 아닌 하나의 단일 엔티티에서 하나의 소프트웨어 아키텍처에 직접적으로 귀속되어야한다는 점을 고려할 때 이상적이지 않습니다. 기술 문서에서 알 수 있듯이 Fabric은 트랜잭션 구성 요소 간의 우수한 처리를 확보하기 위해 블록 체인 플랫폼에서 달성 된 데이터 무결성 및 보안을 구조적으로 포기했습니다..

R3 Corda

R3 Corda에서 트랜잭션은 원장이라고 할 수있는 데이터베이스 Vault 업데이트 제안으로 간주됩니다. 거래는 공증인이 이중 지출이 아니며 필요한 당사자가 서명했는지 확인할 수있는 환경에서 실행되어야합니다. 이는 비트 코인 생태계에서 사용되는 개념과 유사하지만 이중 지출 방지는 신뢰할 수있는 시스템에 의해 촉진됩니다..

두 가지 기본 유형의 트랜잭션이 있습니다.

  • 공증인 변경 트랜잭션-시스템에서 공증인을 순환하기 위해 실행됩니다. 공증인은 이중 지출을 방지하고 거래를 확인할 수 있습니다.
  • 고유성 합의 제공
  • 일반 거래 — 다른 모든 작업에 사용

최종 상태

트랜잭션은 시스템 내의 다른 당사자로부터 서명을 확인해야하는 데이터베이스 환경 상태에 대한 제안 된 업데이트입니다. 거래가 유효하려면 다음을 수행해야합니다.

  1. 관련 당사자의 서명
  2. 거래를 결정하는 계약 코드로 확인

클라이언트 아키텍처

공유 데이터베이스 환경에서 UTXO와 유사한 모델을 사용하면 Corda 플랫폼이 상태 및 전환을 제어 할 수 있습니다. 공증인의 사용과 네트워크 구성에서 Flows와 Cordapp 간의 다양한 상호 작용은 상태가 시스템 아키텍처에 필수적인 데이터 형식으로 보존되는 공유 분산 환경을 보여줍니다. 트랜잭션을 사용하여 Flows와 노드로 프로그래밍되는 Cordapp 사이의 노드 기반 환경 내에서 상태 인스턴스화를 탐색하는 것은 상태 변경을 원장으로 실행하는 실행 가능한 수단을 나타냅니다..

해설

디지털 자산의 형성을 위해 사용자와 상대방은 전체 Corda 플랫폼의 신뢰에 의존합니다. 민감한 금융 데이터를 보관하기위한 강력하고 신뢰할 수있는 공유 분산 원장 시스템 역할을하면서이 시스템은 은행 생태계에 존재하는 다양한 표준에 따라 작동합니다. 플랫폼은 다음을 제공합니다.

  • 비공개 재무 데이터의 우수한 저장
  • 비 신뢰 금융 기관을위한 신뢰할 수있는 설정
  • 비즈니스 상호 작용의 고급 보관

노드 간의 흐름 및 런타임 환경을 포함하는 아키텍처 다이어그램은 Corda가 컨소시엄 플랫폼의 신뢰할 수있는 구성원간에 액세스를 분할하도록 설계되었음을 보여줍니다. R3 Corda는 유용성의 특정 측면을 수행 할 수 있지만 암호화 경제 인센티브 계층과 공용 디지털 자산 환경이 없기 때문에 경제적, 사회적 및 정치적 가치 이전을위한 보편적 인 기질이되는 고유의 기능이 부족합니다. 시스템이 폐쇄 되었기 때문에 경제적 인센티브 기반 생태계를 구축하는 데 필요한 레일과 기술적 특성이 부족합니다. R3 Corda는 디지털 자산 생성은 아니지만 전통적인 은행 인프라의 특정 측면에 가장 잘 사용됩니다..

III. 스마트 계약

이더 리움

Ethereum에서 스마트 계약은 solidity, LLL 또는 Viper와 같은 고급 프로그래밍 언어로 작성되고 EVM 바이트 코드로 컴파일되어 Ethereum Virtual Machine (EVM)에서 바이너리를 실행할 수 있습니다. Ethereum 네트워크의 노드는 Ethereum 생태계에서 스마트 계약을위한 런타임 환경 역할을하는 자체 EVM 구현을 실행합니다. 상태 전환으로 이어지는 상태 및 트랜잭션은 EVM에 의한 복제를 통해 이더 리움 블록 체인의 세계 상태로 상징화되어 일련의 스펙트럼에서 부패 할 수없는 신뢰를 구현할 수있는 시스템이됩니다..

EVM 1

EVM은 트랜잭션을 반복 할 때 시스템 상태 및 머신 상태를 계산하기 위해 상태 전환을 반복적으로 실행하는 런타임 환경의 역할을합니다..

  • 시스템 상태 = 이더 리움 글로벌 상태
  • 머신 상태 = 계약 계정의 비즈니스 로직 & EVM 런타임에 복제 된 코드

모든 스마트 계약 코드가 EVM의 모든 노드에 의해 복제되므로 이더 리움 블록 체인 및 관련 인스턴스화는 계약의 일관성을 보장하기 위해 코드의 유효성을 보존 할 수 있습니다. 계약의 일관성은 이더 리움 블록 체인과 관련 클라이언트 및 구현의 실질적인 불변성에 기여합니다. Ethereum의 스마트 계약은 트랜잭션을 인스턴스화하여 전체 생태계를 하나로 묶어 결국 전체 가상 머신 환경 내에서 새로운 상태로 전환됩니다..

해설

EVM의 구현은 Ethereum Yellow Paper에 지정된 사양을 엄격하게 준수하기 때문에 Ethereum (공용, 사설 및 컨소시엄)의 다양한 인스턴스화는 고급 언어의 공통 컴파일에서 결정된대로 스마트 한 형태로 상호 운용 할 수 있습니다. 계약 — EVM에 의해 Ethereum 바이트 코드로. 이더 리움의 이러한 배치를 통해 대규모 기관 개인 데이터 시설의 다양한 측면과 최근 토큰 이코노미 생성으로 인해 현재 진화하고 결실을 맺고있는 공공 디지털 상품 경제 사이의 중간 계층 역할을 할 수 있습니다..

이더 리움 체인간에이 기능을 허용함으로써 개인 이더 리움 플랫폼의 데이터 조정 및 처리 시스템간에 경제적 최종성을 퍼블릭 체인의 디지털 상품에 할당하는 전체 상호 운용 가능한 시스템을 구축 할 수 있습니다. 이더 리움의 스마트 계약은 이러한 시스템 내에서 프로그래밍 가능한 로직을 캡슐화하고 개발자가 기술 인프라 내에서 새로운 상태 환경을 생성하는 트랜잭션을 통해 이더 리움 가상 머신과 상호 작용할 수 있도록합니다. 상호 운용 가능한 퍼블릭 체인, 프라이빗 체인 및 컨소시엄 체인 환경 내에서 포괄적 인 사용 사례가 개발됨에 따라 이더 리움에서 사용되는 스마트 계약은 공통 논리적 인터페이스 하에서 시스템을 하나로 묶을 수 있습니다..

하이퍼 레저 패브릭

체인 코드는 반드시 계정 기반 블록 체인에 배포 된 스마트 계약이 아니라 설치되고 이후에 API를 통해 인터페이스를 구현하는 프로그램입니다. API 인터페이스에는 기존 소프트웨어 개발 환경과 유사하게 시스템 전체에 비즈니스 로직 및 기능을 지시하는 코드 기반 지침이 필요합니다. API와 관련된 메서드는 다음과 같습니다.

  • Init — 응용 프로그램 상태 시작
  • 호출 — 거래 제안 처리

체인 코드는 API에서 인터페이스를 구현해야합니다.

  • 체인 코드 인터페이스
  • ChaincodeStubInterface

Hyperledger Fabric에서 체인 코드는 보증 피어가 실행하는 프로세스에서 격리되는 보안 Docker 컨테이너에서 실행됩니다. 코드는 일반적으로 Go 또는 Node.js로 작성되어 비즈니스 로직을 처리하는 상호 작용을 허용합니다. 명심해야 할 뉘앙스는 패브릭 체인 코드가 진정한 블록 체인 아키텍처에서 기대되는 것과 동일한 방식으로 생태계 내의 노드에 의해 복제되지 않는다는 것입니다..

체인 코드는 처음에 피어에 설치된 다음 채널로 인스턴스화됩니다. 프로세스 흐름은 다음 다이어그램에 자세히 설명되어 있습니다.

체인 코드 프로세스 흐름 전반에 걸쳐 실행 가능한 피어 프로세스 내에서 실행되는 시스템 체인 코드와 격리 된 컨테이너와의 다양한 상호 작용이 발생합니다. 이것은 보증 정책 또는 수명주기 프로세스없이 시스템 동작을 구현하는 데 사용됩니다. 시스템 체인 코드는 일반 체인 코드의 코드 수명주기를 거치지 않습니다.Chaincode 프로세스 흐름 전반에 걸쳐 실행 가능한 피어 프로세스와 격리 된 컨테이너 내에서 실행되는 System Chaincode와 다양한 상호 작용이 발생합니다. 이는 보증 정책이나 라이프 사이클 프로세스없이 시스템 동작을 구현하는 데 사용됩니다. 시스템 체인 코드는 일반 체인 코드의 코드 라이프 사이클을 거치지 않습니다.. 체인 코드 인터페이스의 Shim API에서 두 가지 기능이 구현됩니다. 코드가 피어에 의해 컴파일되고 유지됩니다. Chaincode는 개발자가 프로그램을 추가로 설치하기를 원한다고 결정할 때까지 채널 또는 주문자와 관련이 없습니다.체인 코드 인터페이스의 Shim API에서 두 가지 기능이 구현됩니다. 코드는 피어에 의해 컴파일되고 유지됩니다. 체인 코드는 개발자가 프로그램을 추가로 설치하기를 원한다고 결정할 때까지 채널 또는 주문자와 관련이 없습니다..

체인 코드는 궁극적으로 원장 데이터베이스에 저장되는 키-값 쌍으로 작동하는 자산을 생성하도록 구성 할 수 있습니다. 시작 명령을 보내고 트랜잭션을 호출하는 워크 플로는 시스템을 통해 명령이 이동되는 방식과 관련하여 위의 다이어그램에 자세히 설명되어 있습니다. 비즈니스 로직은 네트워크 규칙 내에서 인코딩되고 클라이언트 측 애플리케이션을 통해 호출됩니다. 코드 조정 및 상호 작용의 유형은 기존 기능 및 시작 인터페이스에 대한 의존을 통해 기존 소프트웨어 개발을 매우 잘 나타냅니다..

해설

이 네트워크 구성을 통한 체인 코드의 이동은 시스템의 능률적 인 구성을 가능하게합니다. 소프트웨어 아키텍처는 데이터를 배포하고 특정 엔터프라이즈 사용 사례를위한 소프트웨어 개발 환경을 구성하는 측면에서 매우 효율적인 명령 및 제어 구조로 작동하도록 준비되어 있습니다. 패키지, 설치, 인스턴스화, 업그레이드 설정에서 알 수 있듯이이 아키텍처는 코드 처리에 필요한 접점을 최적화하도록 설계되었습니다. 트랜잭션이 처리 될 때 필요한 API 인터페이스는 기존 소프트웨어 디자인을 매우 연상시킵니다. 주목할 부분 :

  • 최대 제어를위한 모 놀리 식 아키텍처
  • 상대방 간의 안전한 비즈니스 상호 작용
  • 트랜잭션 처리량을 위해 중앙에서 조정 된 처리

체인 코드는 블록 체인에 의해 복제되는 스마트 계약 언어 라기보다는 명령 시스템에 가깝습니다. Hyperledger Fabric 생태계는 분산 원장으로서 기능 및 디자인 측면에서 강력한 특성을 가지고 있기 때문에 실제로 시스템은 진정한 블록 체인 시스템의 고유 한 특성이 부족합니다. 기존 인프라 및 패러다임과 통합하는 데 사용할 수있는 도구 인 Fabric은 위에서 설명한 아키텍처 설계에서 추론 할 수있는 기존 소프트웨어 표준을 준수하므로 효과적입니다..

Fabric이 대형 메인 프레임 및 데이터 센터를 중심으로 설계된 시스템을 상징하는 시스템 측면에서 기능이 향상되는 경우, 본질적으로 분산 된 디지털 토큰 경제에서 액세스 할 수있는 계산의 경제적 요인에 대한 분산 연결 측면에서 다른 측면에서 손실됩니다. . Fabric이 진정한 블록 체인 환경에 통합된다면 퍼블릭 블록 체인 생태계와 상호 작용하기 전에 정보를 검증하는 안전한 분산 데이터베이스 환경에 적합 할 것입니다..

R3 Corda

Corda에서 스마트 계약은 Contract 인터페이스를 구현하는 클래스로 간주됩니다. 스마트 계약은 Java / Kotlin으로 작성되며 코드가 실행되는 컴퓨팅 머신 인 JVM (Java Virtual Machine)을 통해 컴파일됩니다. 계약에 사용되는 주요 기능은 “확인”기능입니다..

코드는 거래가 공증 시스템을 통해 처리되는 JVM에서 실행되며 비즈니스 로직은 서로 다른 상대방 간의 비즈니스 프로세스를 수용하고 격리 할 수있는 흐름 내에서 제한됩니다..

상태 객체

스마트 계약 구성 요소 :

  • 실행 가능한 코드
  • 트랜잭션 변경 확인
  • 상태 개체
  • 원장에 보관 된 데이터
  • 계약 현황
  • 거래의 입력과 출력을 사용합니다.
  • 명령어
  • 추가 정보
  • 실행 가능한 계약 코드를 지시하는 데 사용

Java 및 Kotlin 코드는 JVM을 통해 동일한 바이트 코드로 컴파일됩니다. 명령어는 상태에없는 추가 데이터를 계약 코드로 전달합니다. 명령은 거래에 서명하는 데 사용되는 공개 키가 첨부 된 데이터 구조로 작동하지만 계약은 디지털 서명으로 직접 작동하지 않는다는 점을 인정해야합니다. 이 환경 내의 계약은 흐름이 신뢰할 수있는 당사자간에 조정하는 방식의 맥락에서 시스템 전체에 복제됩니다..

해설

계약 코드는 Corda 환경 내에서 사용 사례의 요구 사항에 적합하며 트랜잭션 처리량에 필요한 기능을 수행 할 수 있습니다. 제한 사항에는 다른 생태계와의 상호 운용성이 포함됩니다. 시스템이 Corda와 상호 운용되도록하려면 폐쇄 된 DLT를 중심으로 설계된 Corda 계약 코드 프레임 워크를 활용해야합니다. 개인 인스턴스화와 공개 인스턴스화 사이의 경제 프로세스와 기능 사이의 상호 운용성 계층 역할을 할 수있는 Ethereum과 같은 진정한 블록 체인 플랫폼과 달리 Corda는 폐쇄 형 시스템 내의 프로세스에 더 집중함으로써 스스로를 제한합니다. JVM의 사용은 인스턴스가 Corda 생태계 내에서 격리되어 있지만 혁신적입니다. 이 시나리오에서 Corda는 안전한 환경에서 트랜잭션 처리를 확보하는 동시에 상호 운용 가능한 시스템이 할 수있는 것처럼 서로 다른 블록 체인 환경간에 상호 운용 및 조정하는 기능을 희생합니다..

IV. 결론 및 평가

분석에 따르면 이더 리움이 DLT 기능 이상으로 구현할 수있는 주요 구별 요소는 다음과 같습니다.

  • 디지털 자산 또는 토큰 경제
  • 프로토콜의 암호화 경제 인센티브 계층
  • 컨소시엄과 퍼블릭 블록 체인 간의 상호 운용성

R3 Corda 및 Hyperledger Fabric과 같은 DLT는 공유 데이터베이스 관리 및 트랜잭션 처리 수명주기에서 기능을 달성 할 수 있지만 위에서 설명한 주요 기능을 달성 할 수 있다는 보장은 없습니다. 이러한 플랫폼은 결함이있는 것이 아니라 진정한 블록 체인 만이 주장 할 수있는 일부 순수 사용 사례를 보여주기 위해 아키텍처 구성에 제한이 있습니다..

블록 체인 기술은 그 신뢰에서 생성되는 유형의 가치와 함께 그 안에서 인스턴스화 된 신뢰를 결합하도록 설계되었습니다. 블록 체인의 핵심 기초로 구축 된 진정한 플랫폼을 통해서만 소프트웨어 프로토콜의 인프라 내에서 사회, 정치 및 경제 시스템이 근본적으로 봉헌 될 수 있습니다. DLT 중심의 데이터베이스 관리 플랫폼은 블록 체인 플랫폼과 통합 및 상호 운용 될 수 있지만,이 신뢰의 가치 전달 및 조정이 구축 될 레일은 신뢰, 불변성, 무결성 및 정보 충실도의 핵심 원칙을 구현하는 블록 체인이어야합니다..

이 분석에서 드러난 것은 특정 시스템이 다른 시스템보다 낫다는 것이 아니라 다른 용량에서 유용하다는 것입니다. 높은 트랜잭션 처리량과 기능을 갖춘 사설 분산 데이터베이스로 작동하는 DLT 플랫폼의 기능을 통해 은행 / 금융 데이터 또는 금융 데이터와 같은 개인 정보의 특정 측면이 평가에 필요할 때 블록 체인 플랫폼 내에서 상호 운용 할 수있는 신뢰할 수있는 시스템으로 작동 할 수 있습니다. 대중에게 공개해서는 안되는 민간 기관의 내부 작업과 관련된 민감한 정보. DLT와 관련된 개인 데이터의 이러한 소스를 활용하는 방법에 대한 다양한 비즈니스 모델은 아직 개발 중이며 블록 체인과 DLT 간의 일부 상호 작용에 분산 형 디지털 가치 시스템이 필요하므로 블록 체인 인터페이스를 염두에두고 반복되어야합니다..

블록 체인 전문가와 연결

당사의 글로벌 솔루션 팀은 블록 체인 교육, 전략적 자문, 구현 서비스 및 파트너십 기회를 제공합니다. 최신 이더 리움 뉴스, 엔터프라이즈 솔루션, 개발자 리소스 등을 보려면 뉴스 레터를 구독하십시오.블록 체인 비즈니스 네트워크에 대한 완전한 가이드안내서

블록 체인 비즈니스 네트워크에 대한 완전한 가이드

토큰 화 소개웨비나

토큰 화 소개

금융 디지털 자산 및 DeFi의 미래웨비나

금융의 미래 : 디지털 자산 및 DeFi

엔터프라이즈 이더 리움이란?웨비나

엔터프라이즈 이더 리움이란??

중앙 은행과 화폐의 미래백지

중앙 은행과 화폐의 미래

상품 무역 금융을위한 Komgo 블록 체인케이스 스터드

Komgo : 상품 무역 금융을위한 블록 체인

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me