블록 체인 결정론, 종료 및 격리

Question

결정 성, 종료 및 격리의 매개 변수를 중심으로 가상 기계 (Ethereum 용)와 Docker (Hyperledger Fabric 용)를 비교하는 매트릭스가 있습니다.

이 이미지는 모든 정보를 잘 캡처하지 못합니다. 예를 들어 Hyperledger의 결정론에서는 Docker 동작 자체보다 계약 개발의 과제를 불러냅니다.

Hyperbridger Fabric이 독창적 인 디자인을 통해 Docker를 자체 VM이 아닌 컨테이너로 선택하게 된 이유는 무엇입니까?

Answer 1

초창기 Hyperledger Fabric에서는 스마트 계약을 가장 효과적으로 구현하는 방법에 대해 많은 논의가있었습니다. 다양한 참여자가 고객 계약/자체 프로젝트를 진행하면서 EVM의 결함을 발견했습니다 (EVM이 Turing 코드로 완료되었지만 구조로 가스 및 계정에 의존하고 수행하기가 어렵 기 때문에 정당한 이유가 있음) 복잡한 데이터 모델링 등).

새로운 계약 언어와 실행 언어를 만들려고하기보다는 우리는 사람들이 선택한 프로그래밍 언어의 모든 힘을 지니도록해야한다고 결정했습니다. (오늘날 골란은 완전히 지원되며 Java는 실험적입니다. JavaScript는 다음 릴리스에서 제공됩니다).

이제는 다국어 계약을 허용하고 복잡한 임베디드 인터프리터 등을 만들지 않기 위해, 우리는 프로세스에서 체인 코드를 컴파일하고 실행했습니다. 그런 다음 이러한 외부 프로세스를 "격리"(그리고 어느 정도 관리) 할 수있는 방법을 찾아 내야하고 Docker를 사용하는 것이 매우 실용적인 옵션 인 것처럼 보였습니다. 주의 할

몇 가지 : - chaincode 프로세스/용기 만 (즉, 그들이 피어와의 통신을 시작하고 자신의 끝점을 노출하지 않음) 피어 처리와 통신 - chaincode 실제로 피어에 명령을 전달합니다 (즉, Get/Put 상태 일 때 실제로 이것은 안전한 gRPC 연결을 통해 피어로 전송됩니다.) - 피어는 실제로 다른 호출에서 각 체인 코드 호출을 관리/격리합니다. 즉, 하나의 호출이 다른 호출의 상태에 액세스 할 수 없음을 의미합니다) - Hyperledger 패브릭 자체는 체인 코드가 피어 관리자가 실제로 설치해야하는 메커니즘을 제공합니다 (이는 허가 된 블록 체인을 실행하는 이점입니다). 따라서 체인 코드가 실제로 설치되기 전에 피어의 관리자/소유자는 체인 코드를 검사하여 악성 코드를 전혀 수행하지 않도록 할 수 있습니다.

비 결정론과 관련하여 몇 가지 사항을 조사했습니다. 예를 들어 다양한 언어의 특정 기능을 허용 목록에 추가했습니다. 그러나 결국에는 v1.0 아키텍처로 체인 ​​코드 기반 당 비 결정 성을 보장하는 것은 실제로 필요하지 않습니다. v1.0 모델에서 각 노드는 체인 코드를 실행하고 출력은 실제로 상태 액세스/변경에 대한 읽기/쓰기 세트입니다. 체인 코드 논리가 성공적으로 실행되면 피어는 응답에 서명합니다. 이것을 시뮬레이션 및 보증이라고합니다. 추천 코드 (즉, 체인 코드를 성공적으로 실행해야하는 피어)의 수는 정책을 통해 구성 할 수 있습니다. 트랜잭션에 대한 충분한 보증이 수집되면 패키지이며 주문 서비스에 제출되어 주문 트랜잭션의 블록을 생성하고 검증 및 약정을 위해이를 피어에게 전달합니다. 이 논리는 100 % 결정적입니다 (트랜잭션이 올바른지 확인하고 정책을 충족 할 충분한 보증이 있는지 확인하고 마지막으로 충돌을 피하기 위해 MVCC 검사를 수행합니다 (일명 "이중 지출"이라고도 함).

바라기를 이것은 도움이