블록체인 vs. 분산 원장 기술 Part2: 지배 역학 (4)

블록체인 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 연재

III. 스마트 컨트랙트 (Smart Contracts)

이더리움(Ethereum)

이더리움에서 스마트 컨트랙트는 solidity, LLL또는 Viper와 같은 고급 프로그래밍 언어로 작성되고 EVM 바이트 코드(bytecode)로 컴파일되어 이더리움 가상 머신(EVM)에서 바이너리를 실행합니다. 이더리움 네트워크의 노드는 이더리움 생태계에서 스마트 컨트랙트를 위한 런타임 환경으로 작동하는 자체적인 EVM 구현을 실행합니다. 상태 변환으로 이어지는 상태와 변환은 EVM에 의해 복제되어 이더리움 블록체인의 World State로 표시되어 스펙트럼 배열 위에 소멸하지 않는 신뢰를 구현할 수 있는 시스템이 됩니다.

EVM은 트랜잭션을 통해 루프 할 때 시스템 상태 및 머신 상태를 연산하기 위해 반복적으로 상태 변환을 실행하기위한 런타임 환경으로 작동합니다.

시스템 상태(System state) = 이더리움 글로벌 상태(Ethereum globla state)
머신 상태(Machine state) = EVM 런타임에 복제된 코드와 컨트랙트 계정의 비지니스 로직

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

논평(Commentary)

EVM의 구현은 이더리움의 황서(Yellow Paper)에 명시된 사양을 엄격하게 준수하기 때문에 퍼블릭, 프리이빗 및 컨소시엄의 다양한 인스턴스화는 EVM에 의한 이더리움 바이트 코드와 스마트 컨트랙트의 형태의 고급언어의 공통 컴파일에서 결정된 바와 같이 상호 운용이 가능합니다. 이더리움의 이러한 처리로부터, 대규모의 사설 데이터 시설과 공공 디지털 상품 경제의 다양한면 사이에서 중개 계층으로 활동할 수 있으며, 현재는 토큰 이코노미의 생성으로부터 결실을 맺고 진화하고 있습니다.

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

IBM Fabric

체인코드는 필수적으로 계정 기반(Acount-based) 블록체인에 전개되는 스마트 컨트랙드가 아니라, 설치된 후에 API를 통해 구현되는 프로그램입니다. API 인터페이스는 기존의 소프트웨어 개발 환경과 유사하게 시스템 전반에 비즈니스 로직 및 기능을 지시하는 코드 기반 지침을 필요로합니다. API와 관련된 방법에는 다음이 포함됩니다.

Init-어플리케이션 상태 시작
Invoke-트랜잭션 제안 처리

체인코드는 API로 부터 다음의 인터페이스를 구현해야 합니다.

체인코드 인터페이스
체인코드 StubInterface.

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

체인코드는 처음에 피어에 설치된 다음 채널로 인스턴스화됩니다. 프로세스 플로우는 아래의 다이어그램에서 자세히 설명합니다.

_{체인 코드 인터페이스의 Shim API에서 제공하는 두 가지 기능이 구현됩니다. 코드는 피어에 의해 컴파일되고 유지 관리됩니다. 개발자가 프로그램을 추가로 설치하기로 결정할 때까지 체인 코드는 채널이나 주문자와 관련이 없습니다.}

체인코드는 결과적으로 원장 데이터베이스에 저장되는 키-값 쌍으로 작동하는 자산을 생성하도록 구성할 수 있습니다. 시작 명령을 전송하고 트랜잭션을 호출하는 워크 플로우는 위의 다이어그램에서 명령이 시스템을 통해 이동하는 방법에 대해 자세히 설명합니다. 비즈니스 로직은 네트워크 규칙 내에서 인코딩되며 클라이언트 측 응용 프로그램을 통해 호출됩니다. 코드의 조정과 상호작용은 초기 인터페이스와 전통적인 기능에 대한 의존을 통해 전통적인 소프트웨어 개발을 직접적으로 보여줍니다.

논평(Commentary)

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

참고 :

최대 제어를 위한 단일 아키텍처
카운터파티(Counterparty)간 안전한 비즈니스 상호 작용
트랜잭션 처리량을 위한 중앙 집중식 처리

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

패브릭이 대형 메인 프레임과 데이터 센터 주위에 설계된 시스템으로 다소 상징적인 시스템으로 기능면에서 이득을 얻는다면, 본질적으로 분산 된 디지털 토큰 경제에 액세스 할 수 있는 컴퓨팅 경제 요소에 대한 분산 연결이라는 점에서 다른 측면의 손실이 됩니다. 패브릭이 실제 블록체인 환경에 통합될 경우, 퍼블릭 블록체인 생태계와 상호작용하기 이전에 정보의 유효성을 검증하는 안전한 분산 데이터베이스 환경으로 적합합니다.

R3 Corda

Corda 에서 스마트 컨트랙트는 컨트랙트 인터페이스를 구현하는 클래스로 여겨집니다. 스마트 컨트랙트는 Java / Kotlin으로 작성되며 코드가 실행되는 컴퓨팅 머신 인 자바 가상 머신(JVM)을 통해 컴파일됩니다. 컨트랙트에서 사용되는 주요 기능은 "검증"기능입니다.

코드는 공증 시스템을 통해 트랜잭션이 처리되는 JVM에서 실행되며 서로 다른 카운터파티간의 비즈니스 프로세스를 저장하고 보호할 수 있는 플로우(Flow)내에서 비즈니스 로직이 제한됩니다.

스마트 컨트랙트 구성요소:

실행 코드
트랜잭션의 유효성 검사
상태 객체
원장에 보유된 데이터
컨트랙트 현황
트랜잭션이 인풋 아웃풋 사용
명령어
추가 데이터
실행가능한 컨트랙트 코드 지시에 사용된 것

Java 와 Kotlin 코드는 JVM을 통해 동일한 바이트 코드로 컴파일됩니다. 명령은 상태에 존재하지 않는 추가 데이터를 컨트랙트 코드에 전달합니다. 명령어는 컨트랙트 서명에 사용되는 공개 키가 포함된 데이터 구조 역할을 하지만 계약이 디지털 서명으로 직접적으로 작동하지 않는다는 것을 알아야합니다. 이러한 환경에서 컨트랙트는 플로우(Flow)가 신뢰할 수 있는 카운터파티간에 어떻게 조정되는지에 따라 시스템 전체에 복제됩니다.

논평(Commentary)

컨트랙트 코드는 Corda 환경에서 사용사례의 니즈에 부합하며, 트랜잭션 처리량의 필요 기능을 충족합니다. 제한 사항에는 다른 생태계와의 상호 운용성이 포함됩니다. 시스템이 Corda와 상호 운용되도록하려면 폐쇄 된 DLT를 중심으로 설계된 Corda 컨트랙트 코드 프레임 워크를 사용해야합니다. Corda는 프라이빗 인스턴스화와 퍼블릭 인스턴스화 사이의 기능과 경제적 프로세스간의 상호운용가능한 계층의 역할을 할 수있는 이더리움과 같은 진정한 블록체인과는 달리 폐쇠된 시스템 내에서 프로세스에 더 집중함으로써 자체를 제한합니다. 인스턴스가 Corda 생태계에서 분리되어 있지안, JVM의 사용은 혁신적입니다. 이러한 시나리오에서 Corda는 안전한 환경에서 트랜잭션 처리를 확보하는 반면에 상호 운용이 가능한 시스템이 가능한 것처럼 서로 다른 블록 체인 환경간 상호 운용성과 조정 기능을 희생합니다.

*본 번역은 스티미언들의 후원으로 이루어졌습니다.
*후원해 주시면 더 많은 글을 번역하고 게시할 수 있습니다.