블록 체인에 코드를 넣는 방법은 여러 가지가 있습니다
블록 체인에 대한 대부분의 토론에서“스마트 계약”이라는 개념이 등장하는 데 오래 걸리지 않습니다. 대중적인 상상에서 스마트 계약은 신뢰할 수있는 중개자를 요구하지 않고 당사자 간의 상호 작용을 자동화합니다. 그들은 단어가 아닌 코드로 법적 관계를 표현함으로써 의도적이든 아니든 거래를 직접 오류없이 수행 할 수 있도록 약속합니다.
기술적인 관점에서 볼 때 스마트 계약은 좀 더 구체적인 것입니다. 즉, 블록체인에 상주하고 해당 체인의 트랜잭션에 대한 규칙을 정의하는 컴퓨터 코드입니다. 이 설명은 간단하게 들릴 수 있지만 그 이면에는 이러한 규칙이 표현, 실행 및 검증되는 방식에 많은 변화가 있습니다. 새로운 애플리케이션을 위한 블록체인 플랫폼을 선택할 때 "이 플랫폼이 스마트 계약을 지원합니까?"라는 질문이 있습니다. 묻는 것이 옳지 않습니다. 대신 "이 플랫폼은 어떤 유형의 스마트 계약을 지원합니까?"라고 질문해야 합니다.
이 기사에서는 저의 목표는 현명한 계약 접근 방식과 이들이 나타내는 트레이드 오프 간의 주요 차이점을 조사하는 것입니다. 이를 위해 몇 가지 형태의 맞춤형 온 체인 코드를 지원하는 XNUMX 개의 인기있는 엔터프라이즈 블록 체인 플랫폼을 살펴 보겠습니다. 먼저 IBM의 하이퍼 레더 직물계약을 "체인 코드"라고합니다. 둘째, 멀티 체인 플랫폼은 스마트 필터 버전 2.0에서. 제삼, 이더리움 (그리고 그 허가 정족수 와 굴 "스마트 계약"이름을 대중화하는 스핀 오프). 그리고 마지막으로, R3 Corda거래에서 '계약'을 참조합니다. 모든 다른 용어에도 불구하고, 궁극적으로이 모두는 체인 규칙을 정의하는 응용 프로그램 특정 코드와 같은 것을 의미합니다.
더 나아 가기 전에 다음 내용 중 많은 부분이 본질적으로 기술적이며 일반적인 프로그래밍 및 데이터베이스 개념에 익숙하다고 가정합니다. 좋든 나쁘 든, 이것은 피할 수 없습니다. 세부 사항에 들어 가지 않으면 특정 프로젝트에 블록 체인을 사용할지 여부와 (있는 경우) 올바른 유형의 블록 체인을 사용할 지에 대한 정보에 근거한 결정을 내릴 수 없습니다.
블록 체인 기본
문맥부터 시작합시다. 기본 데이터베이스를 기반으로하는 여러 조직에서 공유하는 응용 프로그램을 상상해보십시오. 전통적인 중앙 집중식 아키텍처에서이 데이터베이스는 모든 참가자가 서로를 신뢰하지 않더라도 신뢰하는 단일 당사자가 호스팅하고 관리합니다. 데이터베이스를 수정하는 트랜잭션은 종종 참가자로부터받은 메시지에 대한 응답으로이 중앙 시스템의 응용 프로그램에 의해서만 시작됩니다. 응용 프로그램은 암시 적으로 신뢰할 수있는 트랜잭션 만 보내도록 암시 적으로 신뢰되기 때문에 데이터베이스는 단순히 알려진 내용을 수행합니다.
블록 체인은 신뢰할 수있는 중개자없이 공유 데이터베이스를 관리하는 대체 방법을 제공합니다. 블록 체인에서 각 참가자는 데이터베이스의 사본을 보유하고이를 수정하는 트랜잭션을 독립적으로 처리하는 "노드"를 실행합니다. 참가자는 공개 키 또는 "주소"를 사용하여 식별되며, 각 키에는 ID 소유자에게만 알려진 해당 개인 키가 있습니다. 모든 노드에서 트랜잭션을 생성 할 수 있지만 트랜잭션의 출처를 증명하기 위해 개시 자의 개인 키로 "디지털 서명"됩니다.
노드는 피어 투 피어 방식으로 서로 연결되어 트랜잭션과 네트워크를 통해 타임 스탬프 및 확인되는 "블록"을 빠르게 전파합니다. 블록 체인 자체는 말 그대로 이러한 블록의 체인으로 모든 기록 트랜잭션의 순서 로그를 형성합니다. “합의 알고리즘”은 중앙 집중식 제어없이 모든 노드가 블록 체인의 내용에 동의하도록 보장하는 데 사용됩니다. (이 설명 중 일부는 각 노드에 데이터베이스의 일부 사본 만 있고 글로벌 블록 체인이없는 Corda에는 적용되지 않습니다. 나중에 자세히 설명하겠습니다.)
원칙적으로 모든 공유 데이터베이스 응용 프로그램은 핵심에서 블록 체인을 사용하여 설계 할 수 있습니다. 그러나 그렇게하면 중앙 집중식 시나리오에는 존재하지 않는 여러 가지 기술적 과제가 발생합니다.
- 거래 규칙. 참가자가 데이터베이스를 직접 변경할 수있는 경우 응용 프로그램 규칙을 준수하도록하려면 어떻게해야합니까? 한 사용자가 셀프 서비스 방식으로 데이터베이스의 내용을 손상시키지 못하게하는 요인은 무엇입니까?
- 결정론. 이러한 규칙이 정의되면 자체 데이터베이스 사본에 대한 트랜잭션을 처리 할 때 여러 노드에서 여러 번 적용됩니다. 모든 노드가 정확히 동일한 결과를 얻도록하려면 어떻게해야합니까?
- 갈등 예방. 중앙 조정없이 애플리케이션 규칙을 따르는 두 가지 트랜잭션을 어떻게 처리하지만 서로 충돌합니까? 충돌은 의도적으로 시스템을 게임하려는 시도에서 비롯되거나 운과 타이밍이 좋지 않은 무고한 결과 일 수 있습니다.
스마트 계약, 스마트 필터 및 체인 코드는 어디에서 제공됩니까? 그들의 핵심 목적은 이러한 과제를 해결하기 위해 블록 체인의 기본 인프라와 협력하는 것입니다. 스마트 계약은 하나의 중앙 위치에서 실행되는 대신 블록 체인의 여러 노드에서 실행되어 해당 데이터베이스의 내용을 수정하는 트랜잭션을 생성하거나 유효성을 검사하는 분산 된 응용 프로그램 코드입니다.
첫 번째 과제 인 트랜잭션 규칙부터 시작하여 Fabric, MultiChain, Ethereum 및 Corda에서 각각 어떻게 표현되는지 살펴 보겠습니다.
거래 규칙
트랜잭션 규칙은 블록 체인 기반 데이터베이스에서 특정 기능을 수행합니다. 변환 데이터베이스 상태에서 수행 할 수 있습니다. 이는 블록 체인의 거래가 참여자 중 누구에 의해 시작될 수 있기 때문에 필요하며, 이들 참여자는 그들이 원하는대로 데이터베이스를 수정할 수 있도록 서로를 충분히 신뢰하지 않습니다.
트랜잭션 규칙이 필요한 이유에 대한 두 가지 예를 살펴 보겠습니다. 먼저 참가자가 게시 한 PDF 문서를 집계하고 타임 스탬프하도록 설계된 블록 체인을 상상해보십시오. 이 경우 문서를 제거하거나 변경할 권한이 아무도 없습니다. 문서의 지속성이라는 시스템의 전체 목적을 손상시킬 수 있기 때문입니다. 둘째, 사용자의 잔액을 추적하는 공유 재무 원장을 나타내는 블록 체인을 고려하십시오. 참가자가 자신의 잔고를 임의로 부풀 리거나 다른 사람의 돈을 빼앗길 수 없습니다.
입력 및 출력
당사의 블록 체인 플랫폼은 거래 규칙을 표현하기 위해 두 가지 광범위한 접근 방식을 사용합니다. 내가 "입력-출력 모델"이라고 부르는 첫 번째는 MultiChain과 Corda에서 사용됩니다. 여기서 트랜잭션은 명시 적으로 삭제하고 생성 한 데이터베이스 행 또는 "상태"를 나열하여 각각 "입력"및 "출력"세트를 형성합니다. 행 수정은 해당 행을 삭제하고 대신 새 행을 작성하는 것과 동등한 조작으로 표시됩니다.
데이터베이스 행은 입력에서만 삭제되고 출력에서만 작성되므로 모든 입력은 이전 트랜잭션의 출력을 "지출"해야합니다. 데이터베이스의 현재 상태는 "사용되지 않은 트랜잭션 출력"또는 "UTXO"세트, 즉 아직 사용되지 않은 이전 트랜잭션의 출력으로 정의됩니다. 트랜잭션에는“메타 데이터”,“명령”또는“첨부 파일”이라고하는 추가 정보가 포함될 수 있으며이 정보는 데이터베이스의 일부가 아니지만 의미 나 목적을 정의하는 데 도움이됩니다.
이 세 가지 입력, 출력 및 메타 데이터 세트를 고려하면 MultiChain 또는 Corda의 트랜잭션 유효성은 해당 세트에서 임의의 계산을 수행 할 수있는 일부 코드로 정의됩니다. 이 코드는 트랜잭션의 유효성을 검사하거나 해당 설명과 함께 오류를 반환 할 수 있습니다. 입력-출력 모델은 트랜잭션이 각각의 모든 규칙을 준수하도록하는 체크리스트를 보유한 자동화 된 "검사기"로 생각할 수 있습니다. 트랜잭션이 해당 검사 중 하나에 실패하면 네트워크의 모든 노드에서 자동으로 거부됩니다.
입력-출력 모델을 공유 함에도 불구하고 MultiChain과 Corda는이를 매우 다르게 구현합니다. MultiChain에서 출력은 자산, 데이터를 JSON, 텍스트 또는 이진 형식으로 포함 할 수 있습니다. 규칙은 "트랜잭션 필터"또는 "스트림 필터"에 정의되어 있으며 모든 트랜잭션을 확인하거나 특정 자산 또는 데이터 그룹과 관련된 트랜잭션 만 확인하도록 설정할 수 있습니다. 반대로 Corda 출력 "상태"는 정의 된 데이터 필드와 함께 Java 또는 Kotlin 프로그래밍 언어의 객체로 표시됩니다. Corda의 규칙은 특정 주에 첨부 된 "계약"에 정의되어 있으며 주 계약은 해당 주가 입력 또는 출력에 포함 된 거래에만 적용됩니다. 이것은 Corda와 관련이 있습니다. 특이한 가시성 모델거래 당사자는 거래 상대방 또는 후속 거래가 영향을받는 거래자 만 거래를 볼 수 있습니다.
계약 및 메시지
“계약 메시지 모델”이라고하는 두 번째 방법은 Hyperledger Fabric 및 Ethereum에서 사용됩니다. 여기서, 여러 "스마트 계약"또는 "체인 코드"를 블록 체인에서 생성 할 수 있으며 각각 자체 데이터베이스 및 관련 코드를 가지고 있습니다. 계약의 데이터베이스는 블록 체인 거래가 아닌 코드로만 수정할 수 있습니다. 이 디자인 패턴은 객체 지향 프로그래밍에서 코드 및 데이터의 "캡슐화"와 유사합니다.
이 모델을 사용하면 블록 체인 트랜잭션이 일부 선택적 매개 변수 또는 데이터와 함께 계약으로 전송되는 메시지로 시작됩니다. 계약 코드는 메시지 및 매개 변수에 대한 반응으로 실행되며 해당 반응의 일부로 자체 데이터베이스를 자유롭게 읽고 쓸 수 있습니다. 계약은 또한 다른 계약으로 메시지를 보낼 수 있지만 서로의 데이터베이스에 직접 액세스 할 수는 없습니다. 관계형 데이터베이스의 언어에서 계약은 강요된 데이터베이스에 대한 모든 액세스는 사전 정의 된 코드를 통해 수행되는 "저장 프로 시저"
Ethereum의 변형 인 Fabric과 Quorum은 네트워크가 여러 개의 "채널"또는 "개인 상태"를 정의 할 수있게하여이 그림을 복잡하게 만듭니다. 목표는 별도의 환경을 만들어 블록 체인 기밀성 문제를 완화하는 것입니다. 각 환경은 특정 하위 그룹의 참가자 만 볼 수 있습니다. 이것은 이론적으로 유망한 것처럼 들리지만 실제로 각 채널 또는 개인 상태의 계약 및 데이터는 다른 채널의 계약 및 데이터와 분리되어 있습니다. 결과적으로 스마트 컨트랙트 측면에서 이러한 환경은 별도의 블록 체인과 동일합니다.
예제 규칙
이 두 가지 모델로 단일 자산 재무 원장에 대한 거래 규칙을 구현하는 방법을 살펴 보겠습니다. 원장 데이터베이스의 각 행에는 소유자의 주소와 소유 한 자산의 수량을 포함하는 두 개의 열이 있습니다. 입 / 출력 모델에서 트랜잭션은 다음 두 가지 조건을 만족해야합니다.
- 트랜잭션 출력의 총 자산 수량은 입력의 총 자산과 일치해야합니다. 이것은 사용자가 돈을 임의로 만들거나 삭제하는 것을 방지합니다.
- 모든 거래는 각 입력의 소유자가 서명해야합니다. 이것은 사용자가 허가없이 서로 돈을 쓰지 못하게합니다.
종합하면,이 두 가지 조건은 단순하지만 실행 가능한 재무 시스템을 만드는 데 필요한 전부입니다.
계약 메시지 모델에서 자산 계약은 발신자 주소, 수신자 주소 및 발송 수량의 세 가지 매개 변수를 사용하는 "지급 송금"메시지를 지원합니다. 이에 따라 계약은 다음 네 단계를 수행합니다.
- 발신자가 트랜잭션에 서명했는지 확인하십시오.
- 발신자에게 충분한 자금이 있는지 확인하십시오.
- 발신자 행에서 요청 수량을 차감합니다.
- 해당 수량을 수신자 행에 추가하십시오.
처음 두 단계의 점검 중 하나가 실패하면 계약이 중단되고 지불이 이루어지지 않습니다.
따라서 입 / 출력 및 계약 메시지 모델은 모두 트랜잭션 규칙을 정의하고 공유 데이터베이스를 안전하게 유지하는 효과적인 방법입니다. 실제로 이론적 인 수준에서 이러한 각 모델을 사용하여 다른 모델을 시뮬레이션 할 수 있습니다. 그러나 실제로 가장 적합한 모델은 구축중인 응용 프로그램에 따라 다릅니다. 각 거래가 몇 개 또는 많은 정보에 영향을 줍니까? 거래 독립성을 보장 할 수 있어야합니까? 각 데이터 조각에 명확한 소유자가 있거나 공유 할 전역 상태가 있습니까?
답변이이 두 모델 사이의 선택에 어떻게 영향을 미치는지 살펴 보는 것은 여기서 우리의 범위를 벗어납니다. 그러나 일반적인 지침으로 새로운 블록 체인 응용 프로그램을 개발할 때 트랜잭션 규칙을 두 가지 형식으로 표현하고 더 자연스럽게 맞는 것을 보는 것이 좋습니다. 차이점은 (a) 프로그래밍의 용이성, (b) 스토리지 요구 사항 및 처리량, (c) 충돌 감지 속도 등의 측면에서 자체적으로 표현됩니다. 이 마지막 문제에 대해서는 나중에 이야기하겠습니다.
내장 규칙
트랜잭션 규칙과 관련하여 MultiChain이 Fabric, Ethereum 및 Corda와 특별히 다른 한 가지 방법이 있습니다. 이러한 다른 플랫폼과 달리 MultiChain에는 블록 체인 기반 애플리케이션을위한 기본 빌딩 블록을 제공하는 몇 가지 기본 제공 추상화가 있습니다. 요구하는 개발자는 자신의 코드를 작성합니다. 이러한 추상화는 (a) 동적 권한, (b) 양도 가능한 자산 및 (c) 데이터 저장과 같이 일반적으로 필요한 세 가지 영역을 다룹니다.
예를 들어, MultiChain은 네트워크 연결, 트랜잭션 송수신, 자산 또는 스트림 생성 또는 다른 사용자의 권한 제어 권한을 관리합니다. 여러 개의 가용 자산을 안전하게 원자 적으로 발행, 이전, 처분 또는 교환 할 수 있습니다. 체인, 체인 또는 오프 체인 데이터를 JSON, 텍스트 또는 이진 형식으로 게시, 인덱싱 및 검색하기 위해 체인에 여러 개의 "스트림"을 만들 수 있습니다. 이러한 추상화에 대한 모든 트랜잭션 규칙은 기본적으로 제공됩니다.
MultiChain에서 애플리케이션을 개발할 때이 내장 기능을 무시하고 스마트 필터 만 사용하여 트랜잭션 규칙을 표현할 수 있습니다. 그러나 스마트 필터는 기본 동작을 활성화하여 내장 추상화와 함께 작동하도록 설계되었습니다. 한정된 맞춤형 방식으로. 예를 들어 특정 활동에 대한 권한은 관리자가 수행하는 기본 동작이 아니라 특정 관리자가 제어 할 수 있습니다. 특정 자산의 양도는 시간에 따라 제한되거나 특정 금액 이상의 추가 승인이 필요할 수 있습니다. 특정 스트림의 데이터는 필수 필드와 값이있는 JSON 구조로만 구성되도록 유효성을 검증 할 수 있습니다.
이러한 모든 경우에 스마트 필터는 트랜잭션을 검증하기위한 추가 요구 사항을 작성하지만 제거 이를 통해 블록 체인 애플리케이션의 주요 과제 중 하나를 해결하는 데 도움이 될 수 있습니다. 일부 온 체인 코드의 버그로 인해 치명적인 결과가 발생할 수 있습니다. 우리는 이더 리움 블록 체인에서이 문제의 끝없는 예를 보았습니다. DAO의 결의 그리고 패리티 다중 서명 버그. 광범위한 설문 조사 Ethereum 스마트 계약에서 공격자가 다른 사람들의 자금을 훔치거나 동결시킬 수있는 많은 공통적 인 취약점을 발견했습니다.
물론 멀티 체인 스마트 필터에도 버그가있을 수 있지만 그 결과는 범위가 더 제한적입니다. 예를 들어 기본 제공 자산 규칙은 스마트 필터에 포함 된 다른 논리에 관계없이 한 사용자가 다른 사용자의 돈을 쓰거나 실수로 돈을 버는 것을 방지합니다. 스마트 필터에서 버그가 발견되면 원장의 기본 무결성이 보호되는 동안 버그를 비활성화하고 수정 된 버전으로 교체 할 수 있습니다. 철학적으로 MultiChain은 기존 데이터베이스 아키텍처에 더 가깝습니다. 여기서 데이터베이스 플랫폼은 열, 테이블, 인덱스 및 제약 조건과 같은 여러 내장 추상화를 제공합니다. 응용 프로그램 개발자는 실제로 필요한 경우 트리거 및 저장 프로 시저와 같은보다 강력한 기능을 선택적으로 코딩 할 수 있습니다.
| 거래 규칙 | 구조 | 멀티 체인 | 이더리움 | 코다 |
|---|---|---|---|---|
| 모델 | 계약 메시지 | 입출력 | 계약 메시지 | 입출력 |
| 내장 | 없음 | 권한 + 자산 + 스트림 |
없음 | 없음 |
결정론
대결의 다음 부분으로 넘어 갑시다. 어떤 접근 방식을 선택하든 블록 체인 응용 프로그램의 사용자 지정 트랜잭션 규칙은 응용 프로그램 개발자가 작성한 컴퓨터 코드로 표현됩니다. 중앙 집중식 응용 프로그램과 달리이 코드는 각 트랜잭션에 대해 두 번 이상 실행됩니다. 서로 다른 참여자에 속하는 여러 블록 체인 노드가 각각 해당 트랜잭션을 확인 및 / 또는 실행해야하기 때문입니다.
이처럼 반복적이고 중복 된 코드 실행은 중앙 집중식 응용 프로그램에서 거의 찾아 볼 수없는 새로운 요구 사항 인 결정론을 도입합니다. 계산의 맥락에서 결정 성이란 코드의 실행 위치 및 시간에 관계없이 동일한 코드에 대해 항상 동일한 응답을 제공한다는 것을 의미합니다. 결정 성없이 해당 체인의 노드 사이의 합의가 파괴 될 수 있기 때문에 이는 블록 체인과 상호 작용하는 코드에 절대적으로 중요합니다.
입력-출력 모델에서 이것이 실제로 어떻게 보이는지 봅시다. 두 노드가 거래가 유효한 지에 대해 다른 의견을 가지고 있다면, 하나는 해당 거래를 포함하는 블록을 수락하고 다른 하나는 그렇지 않습니다. 모든 블록이 명시 적으로 이전 블록으로 다시 연결되기 때문에 네트워크에서 영구적 인 "포크"를 생성하게되는데, 그 시점부터 하나 이상의 노드가 전체 블록 체인의 내용에 대한 대다수의 의견을 받아들이지 않습니다. 소수의 노드는 데이터베이스의 진화하는 상태에서 잘리고 더 이상 응용 프로그램을 효과적으로 사용할 수 없습니다.
이제 계약 메시지 모델에서 합의가 실패하면 어떻게되는지 봅시다. 두 노드가 계약이 특정 메시지에 어떻게 응답해야하는지에 대한 의견이 다른 경우 데이터베이스 내용이 다를 수 있습니다. 이는 다른 계약으로 보내는 메시지를 포함하여 향후 메시지에 대한 계약의 응답에 영향을 줄 수 있습니다. 결과적으로 다른 노드의 데이터베이스 상태에 대한 관점이 점점 더 다양 해지고 있습니다. (이더 리움 블록의 "상태 루트"필드는 계약 응답의 차이로 인해 일정 기간 동안 숨겨져있을 위험이없이 완전히 치명적인 블록 체인 포크로 즉시 이어질 수 있습니다.)
비결정론의 근원
따라서 블록 체인 코드의 비결 정성은 분명히 문제입니다. 그러나 산술과 같은 기본 계산 블록이 결정 론적이라면 무엇을 걱정해야합니까? 글쎄요, 몇 가지 사항이 있습니다.
- 가장 분명하게, 난수 생성기는 정의에 따라 매번 다른 결과를 생성하도록 설계 되었기 때문입니다.
- 노드가 정확히 동시에 트랜잭션을 처리하지 않기 때문에 현재 시간을 확인하고 어떤 경우에도 시계가 동기화되지 않을 수 있습니다. (블록 체인 자체에서 타임 스탬프를 참조하여 시간 종속 규칙을 구현할 수 있습니다.)
- 인터넷, 디스크 파일 또는 컴퓨터에서 실행중인 기타 프로그램과 같은 외부 리소스 쿼리 이러한 자원이 항상 동일한 응답을 제공한다고 보장 할 수 없으며 사용 불가능하게 될 수 있습니다.
- 여러 코드 조각을 병렬 "스레드"로 실행하면 이러한 프로세스가 완료되는 순서를 예측할 수없는 "경주 조건"이 발생하기 때문에
- 부동 소수점 계산을 수행하여 다른 컴퓨터 프로세서 아키텍처에 대해 아주 작은 답변을 제공 할 수 있습니다.
우리의 XNUMX 가지 블록 체인 플랫폼은 이러한 함정을 피하기 위해 여러 가지 접근 방식을 사용합니다.
결정 론적 실행
이더 리움의 접근 방식이 가장 "순수"하므로 우선 시작하겠습니다. 이더 리움 계약은 이더 리움 가상 머신 ( "EVM")에 의해 실행되는 "이더 리움 바이트 코드"라는 특수 목적 형식으로 표현됩니다. 프로그래머는 바이트 코드를 직접 쓰지 않고 Solidity라는 JavaScript와 같은 프로그래밍 언어에서 바이트 코드를 생성하거나 "컴파일"합니다. (다른 언어는 사용 가능했지만 그 이후에는 더 이상 사용되지 않습니다.) 결정 성은 Solidity 및 Ethereum 바이트 코드가 결정적이지 않은 연산을 인코딩 할 수 없다는 사실에 의해 보장됩니다. 그것은 간단합니다.
MultiChain 필터와 Corda 계약은 기존 프로그래밍 언어와 런타임 환경을 조정하여 다른 접근 방식을 선택합니다. MultiChain은 Google에서 실행되는 JavaScript를 사용합니다. V8 엔진은 Chrome 브라우저 및 Node.js 플랫폼의 핵심을 형성하지만 비 결정적 소스는 비활성화되어 있습니다. 마찬가지로 Corda는 Java 또는 코 틀린이 둘은 Java Virtual Machine (“JVM”) 내에서 실행되는“Java bytecode”로 컴파일됩니다. 현재 Corda는 Oracle의 표준 비 결정적 JVM을 사용하지만 결정적 버전. 한편 Corda 계약 개발자는 코드에서 비결 정성을 허용하지 않도록주의해야합니다.
이더 리움의 순수성은 MultiChain과 Corda의 진화론 적 접근법과 어떻게 비교됩니까? 이더 리움의 주요 장점은 위험 최소화입니다. 내장 된 가상 머신에는 의도하지 않은 비결 정성 소스가 포함되어 있지 않습니다. 그러한 감독은 소프트웨어 업데이트로 해결할 수 있지만, 운이 좋지 않은 체인에는 지장을 줄 수 있습니다. 그러나 이더 리움의 문제는 Solidity와 EVM이 더 넓은 프로그래밍 언어 및 런타임 환경에서 작고 초기 생태계를 구성한다는 것입니다. 이에 비해 JavaScript와 Java는 Github의 상위 XNUMX 개 언어, 수십억 개의 디지털 기기에서 실행되며 수십 년에 걸쳐 최적화 된 런타임이 있습니다. 아마도 이것이 공개 이더 리움 블록 체인이 eWASM새로운 웹 어셈블리 표준의 결정 론적 포크입니다.
보증에 의한 결정론
결정론과 관련하여 Hyperledger Fabric은 완전히 다른 접근법을 채택합니다. Fabric에서 "클라이언트"노드가 일부 체인 코드로 메시지를 보내려고 할 때 먼저 해당 메시지를 일부 "엔도 서"노드로 보냅니다. 이러한 각 노드는 체인 코드를 독립적으로 실행하여 메시지의 의견을 만듭니다. 효과 그 체인 코드의 데이터베이스에. 이러한 의견은 공식적인 "승인"을 구성하는 디지털 서명과 함께 고객에게 다시 전송됩니다. 고객이 의도 한 결과에 대한 충분한 승인을 받으면 해당 승인을 포함하는 거래를 생성하고이를 체인에 포함시키기 위해 브로드 캐스트합니다.
결정 성을 보장하기 위해, 각 체인 코드에는 거래를 유효하게하기 위해 필요한 승인 수준을 정확하게 정의하는 "인증 정책"이 있습니다. 예를 들어, 하나의 체인 코드 정책에 따르면 블록 체인 노드의 절반 이상에서 보증이 필요하다고 명시 할 수 있습니다. 다른 하나는 신뢰할 수있는 세 당사자 중 한 곳의 보증을 요구할 수 있습니다. 어느 쪽이든, 모든 노드는 필요한 승인을 받았는지 독립적으로 확인할 수 있습니다.
차이점을 명확히하기 위해 대부분의 블록 체인 플랫폼에서 결정론은“이 데이터에서이 코드를 실행 한 결과는 무엇입니까?”라는 질문에 기초합니다. – 모든 노드가이 질문에 똑같이 대답 할 것을 절대적으로 확신해야합니다. 이와 대조적으로 Fabric의 결정론은 다른 질문에 근거합니다. "이 데이터에 대해이 코드를 실행 한 결과에 대해 충분한 보증인이 동의합니까?" 대답은 계산의 간단한 문제이며 비결정론이 발생할 여지가 없습니다.
승인에 의한 Fabric의 결정론은 많은 흥미로운 결과를 가져옵니다. 첫째, 체인 코드는 다양한 프로그래밍 언어로 작성 될 수 있는데, 이는 결정론에 맞게 조정할 필요가 없기 때문입니다 (Go, Java 및 JavaScript는 현재 지원됨). 둘째, 체인 코드는 클라이언트와 보증인 만 실행할 수 있기 때문에 일부 블록 체인 참여자로부터 숨길 수 있습니다 (데이터베이스 자체는 전 세계에 표시됩니다). 마지막으로 패브릭 체인 코드는 온라인 웹 API를 사용하여 날씨를 확인하는 등 다른 블록 체인 환경에서 금지 된 작업을 수행 할 수 있습니다. 최악의 경우, 모든 보증인이이 API에서 다른 답변을받는 경우, 클라이언트는 특정 결과에 대해 충분한 보증을 얻지 못하며 거래가 발생하지 않습니다. (직물 팀원은 여전히 권하다 놀라움을 피하기 위해 체인 코드 내에서 결정 론적 논리를 사용합니다.)
Fabric은 이러한 유연성에 대해 어떤 가격을 지불합니까? 블록 체인의 목적이 공유 데이터베이스 중심 응용 프로그램에서 중개자를 제거하는 것이라면 Fabric의 보증인에 대한 의존은 그 목표에서 크게 벗어납니다. 체인 참여자에게는 더 이상 체인 코드의 규칙을 준수하기에 충분하지 않으며, 그렇게했다는 데 동의 할 특정 다른 노드도 필요합니다. 더 나쁜 것은 악의적 인 보증인 하위 집합이 체인 코드를 따르지 않는 데이터베이스 변경을 승인 할 수 있다는 것입니다. 이를 통해 거래를 검열 할 수는 있지만 블록 체인의 규칙을 위반할 수없는 일반 블록 체인의 검증 자보다 보증 자에게 훨씬 많은 권한을 부여합니다. 블록 체인 응용 프로그램 개발자는이 절충이 자신의 특정한 경우에 적합한 지 결정해야합니다.
| 결정론 | 구조 | 멀티 체인 | 이더리움 | 코다 |
|---|---|---|---|---|
| 모델 | 추천 | 적응 된 런타임 | 특수 목적의 VM | 적응 된 런타임 |
| 언어 | Go + 자바 + 자바스크립트 | 자바 스크립트 | 견고 | 자바 + 코 틀린 |
| 코드 가시성 | 상대방 + 보증인 |
블록체인 | 블록체인 | 상대방 + 부양 가족 |
| 강제 | 아니 | 가능 | 가능 | 아니요 (현재) |
갈등 예방
지금까지 서로 다른 블록 체인 플랫폼이 코드로 트랜잭션 규칙을 표현하는 방법과 모든 노드가 해당 규칙을 동일하게 적용하도록 결정하는 방법에 대해 논의했습니다. 이제 대결의 세 번째 측면에 대해 이야기 할 차례입니다. 각 플랫폼은 자체적으로 유효한 두 트랜잭션이 서로 충돌 할 가능성을 어떻게 처리합니까? 가장 간단한 예에서 Alice가 재무 장부에 10 달러를 가지고 있고 Bob에게 $ 8를 보내고 다른 하나는 Charlie에게 $ 7를 보내는 두 가지 트랜잭션을 브로드 캐스트한다고 가정하십시오. 분명히, 이러한 트랜잭션 중 하나만 성공할 수 있습니다.
두 가지 모델
이 문제에 대한 MultiChain과 Corda의 접근 방식을 그룹화하여 시작할 수 있습니다. 앞에서 설명한 것처럼이 두 가지 모두 트랜잭션과 해당 규칙을 나타내는 입력 / 출력 모델을 사용하며 각 트랜잭션 입력은 이전 트랜잭션 출력을 사용합니다. 이는 충돌을 방지하기위한 간단한 원칙으로 이어집니다. 모든 출력은 한 번만 사용할 수 있습니다. MultiChain 필터와 Corda 계약은 해당 플랫폼을 사용하여이 제한을 절대적으로 적용 할 수 있습니다. Alice의 10 달러는 이전 거래 결과로 표시되므로이 단일 지출 규칙은 자동으로 Bob과 Charlie에게 보내는 것을 중지합니다.
이러한 유사성에도 불구하고 MultiChain과 Corda가 충돌을 방지하는 방법의 주요 차이점을 지적하는 것이 중요합니다. MultiChain에서 모든 노드는 모든 트랜잭션을보고 각 출력이 한 번만 소비되는지 독립적으로 확인할 수 있습니다. 이전에 확인 된 거래에 대해 이중 지출을 수행하는 거래는 즉시 자동으로 거부됩니다. 반면 Corda에는 글로벌 블록 체인이 없으므로 이러한 이중 지출을 방지하기 위해 "공증인"이 필요합니다. 모든 Corda 출력 상태는 공증인에게 할당되며, 공증인은 해당 출력에 대한 거래 지출에 서명하여 이전에 사용되지 않았 음을 확인해야합니다. 블록 체인 참가자는이 규칙을 정직하게 준수하기 위해 공증인을 신뢰해야하며 악의적 인 공증인은 마음대로 혼란을 일으킬 수 있습니다. Fabric의 승인과 마찬가지로이 "서비스로 단일 지출”디자인은 기밀성 측면에서 이점이 있지만 블록 체인 구조에 반하는 중개자를 다시 도입합니다. (코다 공증인은 합의 알고리즘을 사용하여 참가자 그룹이 실행할 수 있으므로 원장의 무결성을 여전히 개별 악의적 행위자로부터 보호 할 수 있음을 분명히하는 것이 중요합니다).
이더 리움으로 넘어 갑시다. 이더 리움은 입력과 출력 대신 계약과 메시지를 사용합니다. 결과적으로 Alice의 두 지불과 같은 거래 충돌은 블록 체인 엔진에 즉시 표시되지 않습니다. 대신에, 그들은에 의해 감지되고 차단됩니다. 계약 체인에서 주문이 확인 된 후 거래를 처리합니다. Alice의 각 지불을 처리 할 때 계약은 그녀의 잔액이 충분한 지 확인합니다. Bob에게 $ 8를 지불하는 거래가 먼저 이루어지면 평소와 같이 처리되어 Alice가 계정에 $ 2를 남깁니다. 결과적으로, 계약이 Charlie에게 $ 7를 지불하는 두 번째 거래를 처리 할 때 Alice에게 필요한 자금이 부족하고 거래가 중단 된 것을 알 수 있습니다.
출력 대 계약
지금까지 충돌 트랜잭션을 방지하기위한 MultiChain 및 Corda의 단일 지출 출력과 이더 리움의 계약 기반 검증이라는 두 가지 기술을 살펴 보았습니다. 그래서 어느 것이 더 낫습니까?
이 질문에 대답하기 위해 Gavin과 Helen을 대신하여 1 달러를 보유하고 있고 둘 중 한 사람이 그 돈을 독립적으로 사용할 수 있도록하는“2/100 다중 서명”계정의 예를 고려해 봅시다. Gavin은 자신의 신청서에 Donna에게 80 달러를 내라고 지시하고 몇 초 후에 Helen은 40 달러를 Edward에게 보내려고합니다. 두 지불에 대한 자금이 충분하지 않기 때문에 이러한 거래는 필연적으로 충돌합니다. 두 거래가 모두 방송되는 경우, 결과는 체인 중 첫 거래에 따라 결정됩니다. Alice의 예와 달리이 충돌은 우연한아무도 애플리케이션의 규칙을 어기려고하지 않기 때문에 운이 좋지 않은 타이밍을 가졌습니다.
이 갈등이 발생할 가능성을 고려할 때 중요한 질문은 다음과 같습니다. Gavin이 거래를 보낸 후 Helen의 노드가 지불이 실패 할 수 있음을 알기까지 얼마나 걸립니까? 이 기간이 짧을수록 Helen은 해당 지불 시도를 중단 할 가능성이 높아져 그녀와 그녀의 응용 프로그램이 후속 놀라움에서 구해집니다.
입력-출력 모델을 사용하면 두 트랜잭션이 동일한 이전 출력을 명시 적으로 사용하려고하기 때문에 트랜잭션 간의 충돌이 블록 체인 플랫폼에 직접 표시됩니다. MultiChain에서 이것은 Gavin의 거래가 보통 XNUMX 초 이내에 Helen의 노드로 전파되는 즉시 발생합니다. Corda에서 출력의 공증인은 이미 Gavin의 서명을했기 때문에 Helen의 거래에 서명하라는 요청을 거부하므로 Helen은 즉시 지불이 실패 할 것임을 알 수 있습니다. (Corda 공증인 자체가 배포 된 경우에도 응답을 기다리는 데 몇 초 정도 기다려야 할 수도 있습니다.) 어느 쪽이든, 블록 체인에서 거래가 확인되고 주문 될 때까지 기다릴 필요가 없습니다.
이더 리움 모델은 어떻습니까? 이 경우 블록 체인 플랫폼이 충돌이 발생한다는 것을 즉시 알 수있는 방법은 없습니다. Helen의 노드는 네트워크에서 Gavin의 트랜잭션을 볼 수 있지만 이것이 Helen의 자체 트랜잭션에 어떤 영향을 미치는지 알 수는 없습니다. 관점에서 볼 때 이는 단순히 두 개의 메시지가 동일한 계약으로 전송되기 때문입니다. 아마도 XNUMX 초 후, 충돌하는 거래의 최종 주문이 블록 체인에서 확인되면 Helen의 노드는 예상 결과 대신 실제를 다시 계산하고 응용 프로그램은 그에 따라 디스플레이를 업데이트합니다. 그동안 개빈과 헬렌은 모두 어둠 속에 남아있을 것이다.
그러나 우리는 입 / 출력 모델이 항상 가장 잘 작동한다고 결론 내려서는 안됩니다. Gavin과 Helen이 정확히 동시에 40 달러의 원래 잔고에서 더 적은 100 달러의 지불을 요청하는 예제 시나리오의 변형을 고려하십시오. 입 / 출력 모델에서는 이러한 트랜잭션이 모두 $ 100를 포함하는 동일한 데이터베이스 행을 사용하고 있으며 지불 중 하나만 성공하기 때문에 충돌합니다. 그러나 이더 리움에서는 최종 주문에 관계없이 두 거래가 모두 성공적으로 처리 될 것입니다. 계좌에는 두 가지를위한 충분한 자금이 포함되어 있기 때문입니다. 이 경우 이더 리움은 개빈과 헬렌의 의도를 더욱 충실히 이행합니다.
읽기 / 쓰기 세트
마지막으로 보증 기반 접근 방식이이 두 기술의 하이브리드 인 Fabric에 대해 이야기 해 봅시다. 앞에서 설명한 것처럼 Fabric "클라이언트"노드는 계약서에 메시지를 보내려고 할 때 먼저 일부 승인 노드가 해당 메시지를 대신하여 해당 메시지를 실행하도록 요청합니다. 승인 노드는 로컬 데이터베이스에 대해 계약을 실행하는 Ethereum과 유사한 방식으로 수행하지만이 프로세스는 즉시 적용되는 것이 아니라 관찰됩니다. 각 승인자는 해당 시점의 정확한 행 버전을 기록하고 읽고 쓸 행 세트를 기록합니다. 버전이 지정된 행의이 "읽기-쓰기 세트"는 보증에서 명시 적으로 참조되며 클라이언트가 브로드 캐스트하는 트랜잭션에 포함됩니다.
체인에서 주문이 완료되면 Fabric 트랜잭션 간의 충돌이 해결됩니다. 모든 노드는 승인 정책을 확인하고 지정된 데이터베이스 변경 사항을 적용하여 각 트랜잭션을 독립적으로 처리합니다. 그러나 트랜잭션이 이전 트랜잭션에 의해 이미 수정 된 데이터베이스 행 버전을 읽거나 쓰면 두 번째 트랜잭션은 무시됩니다. Bob과 Charlie에 대한 Alice의 상충되는 지불로 돌아 가기 위해 두 트랜잭션 모두 Alice가 시작한 10 달러가 포함 된 동일한 행 버전을 읽고 수정합니다. 따라서 두 번째 거래는 안전하고 자동으로 중단됩니다.
충돌 해결에 대한 Fabric의 접근 방식은 잘 작동하지만 성능과 유연성 측면에서 이전 두 모델 중 최악의 모델을 결합합니다. 보증은 거래를 특정 읽기 / 쓰기 세트로 변환하기 때문에 Gavin과 Helen의 동시에 지불 할 수있는 $ 40 지불은 Ethereum이 피하는 충돌로 이어질 것입니다. 그러나 승인자는 확인되지 않은 트랜잭션을 무시하고 블록 체인으로 확인 된 최신 버전의 데이터베이스에 대해 계약을 실행하므로 Fabric은 입력-출력 모델의 속도 이점을 얻지 못합니다. 따라서 헬렌이 개빈 후 몇 초 만에 결제를 시작했지만 블록 체인에서 개빈이 확인되기 전에 Fabric은 순수한 입출력 모델이 피하는 상충되는 거래를 만듭니다.
| 갈등 예방 | 구조 | 멀티 체인 | 이더리움 | 코다 |
|---|---|---|---|---|
| 모델 | 읽기 / 쓰기 세트 | 단일 지출 | 계약 확인 | 단일 지출 |
| 확인 | 독립 | 독립 | 독립 | 신뢰할 수있는 공증인 |
| 속도 | ~ 10 초 (확인) | ~ 1 초 (전파) | ~ 10 초 (확인) | 0 ~ 5 초 (공증인) |
복잡한 선택
이 기사에서는 Corda, Ethereum, Fabric 및 MultiChain이“스마트 계약”또는 블록 체인에 포함 된 응용 프로그램 코드의 주요 과제를 해결하는 다양한 방법을 검토했습니다. 그리고 각 플랫폼에는 XNUMX 가지 핵심 질문에 대한 답변이 다릅니다. 거래 규칙은 어떻게 표현됩니까? 코드는 어떻게 결정적으로 실행됩니까? 그리고 우리는 어떻게 갈등을 방지합니까?
스마트 계약 대결의 승자는 누구입니까? 지금까지는 간단한 대답이 없다는 것이 분명합니다. 각 플랫폼은 유연성, 단순성, 성능, 중단, 안전 및 기밀성 간의 복잡한 다자간 균형을 나타냅니다. 따라서 특정 응용 프로그램에 대한 플랫폼 선택은 해당 응용 프로그램의 트러스트 모델, 관련된 트랜잭션 유형 및 가능한 충돌 패턴에 대한 자세한 이해로 시작해야합니다. 이러한 질문에 대한 답을 알기 전에 특정 스마트 계약 솔루션을 추진하는 사람이 있으면 정중하지만 단호하게 "더 똑똑한"접근 방식을 채택 할 것을 제안합니다.
의견을 적어주세요 링크드 인에.
