얼라이언스 체인은 어디로 향하고 있습니까?

碳链价值

特邀专栏作者

2020-01-03 10:42 (UTC+8)

이 기사는 약 10518자로, 전체를 읽는 데 약 16분이 소요됩니다

어떤 얼라이언스 체인 기술이 강력한가요? 오픈 소스 아키텍처 Fabric, FISCO BCOS(이하 "BCOS") 및 CITA 기술 비교.

AI 요약

펼치기

어떤 얼라이언스 체인 기술이 강력한가요? 오픈 소스 아키텍처 Fabric, FISCO BCOS(이하 "BCOS") 및 CITA 기술 비교.

편집자 주: 이 기사의 출처는탄소 사슬 값(ID: cc-value), 저자: Carbon Chain Value Research Institute, 승인을 받아 Odaily에서 재인쇄함.

요약

보조 제목

요약

제46차 세계경제포럼 다보스 연례회의에서는 '4차 산업혁명'에서 블록체인, 인공지능, 자율주행 등을 다뤘다. The Economist는 2015년 10월 표지 기사 "Trust Machine"에서 블록체인을 소개한 적이 있습니다.

블록체인이 신뢰할 수 있는 기계라고 불리는 이유는 분산과 변조 방지라는 두 가지 핵심 특성에서 비롯되며, 이는 기존 데이터베이스와 다른 블록체인의 핵심 특성이기도 합니다. 여기에서 분산은 두 가지 의미를 내포하고 있습니다: 하나는 전통적인 분산 저장소이고 다른 하나는 블록체인의 기본 프로토콜이 가져오는 협업입니다.여기서는 분산 협업 기능을 더 많이 의미합니다.

블록체인에서 "신뢰할 수 있는 협업"은 주로 합의 알고리즘, 스마트 계약, 거버넌스, 크로스체인, 프라이버시 등을 통해 실현되므로 이 기사에서는 이러한 측면에서 기반 기술의 차이점을 분석하고 엔터프라이즈 애플리케이션 시나리오를 결합합니다. 비즈니스 사용자가 더 나은 선택을 할 수 있도록 지원합니다. 동시에 유지 관리 가능성, 성능, 개발 도구, 확장성 및 소프트웨어 프로토콜 측면에서 기존 엔터프라이즈 소프트웨어를 분석하고 비교합니다.

컨소시엄 체인의 역사와 그것과 퍼블릭 체인의 차이점에 관한 한, 초기에는 큰 차이가 없지만 지금은 시장 세그먼트가 계속 심화됨에 따라 퍼블릭 체인과 컨소시엄의 차이가 체인이 점점 더 분명해지고 있습니다.

우선, 퍼블릭 체인은 통제할 수 없는 시나리오에 직면해 있으며 보안, 성능 및 탈중앙화 사이의 균형을 찾는 것이 필요합니다. 컨소시엄 체인 엔터프라이즈 서비스 시나리오에서 참여자 수는 상대적으로 더 제어 가능하며 컨소시엄 체인은 성능 및 보안 측면에서 돌파구를 만들 가능성이 더 큽니다. 그러나 참여자(노드)의 제어 가능성으로 인해 탈중앙화는 보다 독특한 디자인을 가집니다. 또한 퍼블릭 체인에서는 모든 정보가 공개되고 투명하며 확인할 수 있으며 각 참여자는 상대적으로 평등합니다. 그러나 산업계에서는 이를 용납할 수 없습니다. 처리해야 하는 공개 대 공개 데이터 프라이버시가 많고 기업에는 권한을 설정해야 하는 여러 조직 모델이 있습니다.

이러한 특성을 바탕으로 제휴 체인의 발전에는 노드 관리, 합의 선택, 권한 제어 및 계약 설계 패러다임이 포함되며 동시에 서로 다른 프레임워크는 계약 설계 패러다임에 대한 이해가 다릅니다. 또한 블록체인은 오픈소스와 클로즈드소스로 나눌 수 있는데 블록체인이 만드는 신뢰는 오픈소스 코드를 기반으로 하며 오픈소스가 없으면 진정한 의미의 블록체인 시스템이 아니다. 따라서 연구의 객관성을 위해 이 글은 주로 오픈소스 프레임워크에 초점을 맞춘다. 현재 국내 시장에서 널리 사용되는 오픈소스 아키텍처는 Fabric, FISCO BCOS, CITA이다.

Hyperledger Fabric은 높은 수준의 기밀성, 유연성 및 확장성을 제공하는 모듈식 아키텍처를 기반으로 하는 분산 원장 솔루션용 플랫폼입니다. 다양한 구성 요소의 플러그형 구현을 지원하고 경제 생태계 전반에 존재하는 복잡성에 적응하도록 설계되었습니다. Fabric은 원래 IBM에서 설계 및 개발했으며 해당 소스 코드는 2015년 Linux Foundation의 Hyperledger 프로젝트에 전용되었습니다.

FISCO BCOS는 2017년에 탄생하여 Golden Chain Alliance에서 출시한 국내 표준 바닥 레이어입니다. Golden Chain Alliance는 2016년 5월 31일 Shenzhen Financial Technology Association, Shenzhen Qianhai WeBank 및 Shenzhen Securities Express를 비롯한 20개 이상의 금융 기관 및 기술 회사가 공동으로 설립하고 설립한 비영리 조직입니다.

CITA는 높은 안정성, 고성능 및 높은 확장성을 갖도록 설계된 오픈 소스 블록체인 운영 체제 커널입니다. CITA 오픈 소스 프로젝트는 2016년 Cryptape에 의해 시작되었습니다. 현재 Xita Technology와 같은 CITAHub 커뮤니티 기업이 공동으로 유지 관리하고 있습니다. CITA는 마이크로 서비스 아키텍처 설계를 채택하고 풍부한 개발 도구 세트와 유연한 블록체인 거버넌스 도구를 제공합니다.개발자는 다양한 유형의 블록체인 네트워크에 대한 2차 개발 또는 구성을 수행할 수 있습니다.

블록체인의 다양한 구현과 디자인 아이디어를 구별하기 위해 먼저 블록체인 자체의 정의를 명확히 할 수 있습니다. 일반적으로 블록체인 자체의 정의는 탈중앙화되고 분산된 원장이며, 이벤트 및 트랜잭션을 기록하는 불변 원장이기도 합니다. 이 원장에서 불변 속성은 합의 알고리즘에 의해 보장됩니다. 이러한 관점에서 기존 컨소시엄 체인은 Fabric으로 대표되는 전통적인 데이터베이스가 지배하는 분산 데이터베이스 기술과 "블록체인 정신"에 더 부합하는 FISCO BCOS 및 CITA의 두 가지 범주로 나눌 수 있습니다.

Fabric 기능: IBM Fabric은 분산된 합의 메커니즘을 생략하고 블록체인에서 분산되고 변조할 수 없는 수정의 두 지점을 보장하며 IBM Fabric은 프레임워크에 실제 분산된 합의 메커니즘이 없습니다. Fabric 아키텍처에서 참여자(노드)는 주문 노드, 보증 노드 및 제출 노드의 세 가지 역할로 나뉩니다. 각 트랜잭션에 대해: 컨센서스 상태 프로세스는 클라이언트, 보증 노드 및 제출 노드에 의해 완료되며 주문 노드는 상태 합의 전략이 아닌 트랜잭션 순서의 합의에 대해서만 책임을 집니다. 정렬 노드에서의 합의 방식은 Kafka 또는 Raft인데, 이는 기존 분산 데이터베이스 합의 방식과 사실상 일치하며 내결함성이 없습니다.

CITA 및 FISCO BCOS의 특성: FISCO BCOS 및 CITA의 경우 위에서 언급한 블록체인의 모든 특성이 보장되지만 설계 패러다임은 사용 시 기존 프로젝트와 상당히 다를 것입니다. 분산 원장으로서 데이터가 변조될 수 없도록 보장할 수 있으며 1/3 내결함성 비율을 보장하는 비잔틴 내결함성 분산 합의 메커니즘을 사용할 수도 있습니다. 이 두 프레임워크에서 체인의 참여자는 합의 노드와 읽기 전용 노드로 구분되며, 합의 노드는 장부 권한이 있는 참여자이고 읽기 전용 노드는 모든 데이터에 액세스할 수 있는 참여자입니다.

이더리움이 블록체인의 정신을 나타낸다면 CITA와 FISCO BCOS는 퍼블릭 체인을 계승합니다. CITA 및 FISCO BCOS는 시나리오 및 사용 측면에서 퍼블릭 체인과 완전히 다르지만 여전히 일부 기본 논리에서 퍼블릭 체인의 상속을 볼 수 있습니다. 엄밀히 말하면 이더리움의 가상 머신을 물려받는다는 것은 이더리움의 거대한 생태계를 물려받는 것을 의미합니다. 다음으로 이 기사에서는 기술 구현의 관점에서 세 가지 차이점을 비교합니다.

보조 제목

합의 및 거래 흐름

컨센서스 메커니즘은 블록체인의 영혼이며 퍼블릭 체인이든 얼라이언스 체인이든 컨센서스 메커니즘은 블록체인의 거래 처리 능력과 확장성을 근본적으로 제한하고 분산 협업 기능의 기반이기도 합니다. 합의는 데이터 또는 네트워크의 최종 상태에 대해 분산 시스템의 노드가 도달한 합의입니다. 제어할 수 없는 네트워크 환경과 노드 상태로 인해 합의 메커니즘은 성능, 안정성, 보안 및 기타 문제를 동시에 고려해야 합니다. 넓은 관점에서 합의 메커니즘은 액세스가 필요하지 않은 Nakamoto Consensus 및 기타 합의 메커니즘과 액세스가 필요한 PBFT 및 기타 합의 메커니즘의 두 가지 범주로 나눌 수 있습니다.

Nakamoto 합의는 퍼블릭 체인에서 널리 사용되지만 확률 모델은 높은 신뢰성을 제공하는 동시에 효율성을 희생합니다. 특정 상용 애플리케이션 환경에서 라이센스 메커니즘은 노드 신뢰도를 어느 정도 보장하며 이러한 전제 하에서 사용자는 실행 효율성과 완결성에 더 많은 관심을 갖습니다. 이것이 얼라이언스 체인에서 BFT 합의가 인기 있는 이유입니다.

다음으로 이 기사에서는 먼저 FISCO BCOS, CITA 및 Fabirc 합의 기술의 구현을 소개한 다음 성능, 애플리케이션 시나리오, 확장성 및 보안 측면에서 비교 분석을 수행합니다.

기술적 실현

BCOS 합의 메커니즘의 효율성은 비교적 전통적입니다.

FISCO BCOS의 합의 메커니즘은 전통적인 PBFT 합의를 채택하고 합의 프로세스는 주로 사전 준비, 준비 및 커밋의 세 단계를 포함합니다.

1. 사전 준비: 리더 노드는 블록을 실행하고 서명을 생성하며 다른 합의 노드에 제안을 브로드캐스트합니다.

2. 준비: 컨센서스 노드는 제안을 검증하고 서명을 방송하며 동시에 다른 노드의 서명을 수집합니다.노드는 2f + 1의 서명을 수집한 후 Commit 패키지를 방송하기 시작합니다.

3. Commit: 리더 노드는 Commit 패킷을 수집하고 노드는 2*f + 1 Commit 패킷을 수집한 후 로컬 데이터베이스를 업데이트하여 다른 노드에 브로드캐스트하고 다른 노드는 이를 수신하여 로컬 데이터베이스를 업데이트합니다.

다음 그림은 표준 PBFT 프로세스를 보여줍니다.

블록체인에서 컨센서스 노드는 커밋 단계에서 투표를 통합해야 하므로 최종 커밋 단계는 약간 다릅니다. 리더 노드가 2*f+1 커밋 패키지를 수신한 후 최종 커밋 패키지를 다른 컨센서스 노드에 브로드캐스트합니다. 통합 투표.

전체 합의 프로세스에서 트랜잭션은 사전 준비 단계에서 한 번 실행되고 준비 단계에서 한 번 확인됩니다.FISCO BCOS에서 사용되는 전통적인 PBFT 프로세스는 먼저 실행한 다음 확인하는 모드이며 실행에 두 가지 시간 길이를 포함합니다. 업무.

CITA는 자체 개발 합의 프로토콜을 채택합니다.

CITA는 블록체인의 지속적인 합의 특성에 따라 최적화된 CITA-BFT를 구현합니다. 블록체인은 지속적인 합의 프로세스이며, CITA는 트랜잭션 실행과 합의를 분리하여 이중 실행 문제를 방지합니다. 상태 기계 복제 원칙에 따라 초기 상태가 일관되고 트랜잭션 실행 순서가 일관되며 실행 프로세스가 결정적이며 세 가지 조건이 모두 충족되면 최종 결과가 일관됨을 보장할 수 있습니다. 블록체인에서 초기 상태는 제네시스 블록에 의해 일관성이 보장되고 가상 머신은 완전히 결정적이므로 트랜잭션 순서가 일관성이 있는 한 최종 결과가 일관성이 있음을 보장할 수 있습니다. 블록체인에서 블록의 preHash는 이미 마지막 블록의 트랜잭션 처리 후 세계 상태 정보를 담고 있습니다. CITA-BFT는 현재 블록의 트랜잭션 순서와 이전 블록의 실행 결과에 동의합니다. 이러한 방식으로 합의 과정에서 트랜잭션을 실행할 필요가 없고 합의가 완료된 후 트랜잭션 처리가 한 번만 처리되므로 전체 체인의 처리량이 크게 향상됩니다. CITA-BFT는 블록체인의 지속적인 합의의 특성에 최적화되어 있으며, 먼저 합의 후 처리하는 방식을 채택하여 합의 과정에서 트랜잭션을 실행할 필요가 없고 합의가 이루어진 후에만 트랜잭션을 실행하면 됩니다. 완전한. 검증 후 가장 간단한 증서 입금 거래에서 합의 성능이 약 35% 향상되었습니다.

CITA-BFT는 합의 프로토콜에서 리더 브로드캐스트의 마지막 라운드 프로세스를 피합니다. 전통적인 PBFT의 마지막 Commit 단계에서 Leader는 충분한 Commit 패킷을 수신하고 다른 노드에 브로드캐스트해야 합니다. 블록체인은 지속적인 합의 과정입니다.CITA-BFT에서 블록의 합의 투표는 이전 블록의 투표이므로 리더가 Commit 단계와 다음 높이의 제안 단계에서 최종 블록을 브로드캐스팅하는 과정은 한 번의 방송 과정을 거친 후 Commit 투표 정보는 다음 고도의 Proposal 과정을 통해 통일됩니다.

CITA-BFT는 제안 전처리 기술을 사용하여 합의 및 실행을 병렬로 진행하여 시스템 성능을 향상시킵니다. 대부분의 경우 컨소시엄 체인의 네트워크 상태가 양호하고 한 라운드의 합의 과정에서 합의가 완료될 수 있기 때문에 CITA는 제안 전처리 기술을 도입합니다. 컨센서스 프로세스가 완료될 때까지 기다리지 않고 제안을 수신하고, 컨센서스 프로세스가 완료되면 트랜잭션 처리자에게 컨센서스 결과를 알립니다. 기존의 PBFT 프로세스에서는 트랜잭션 처리와 합의가 순차적으로 이루어지지만 제안 전처리를 도입한 후 합의의 준비 단계와 커밋 단계를 트랜잭션 처리와 병렬로 수행할 수 있으므로 전체 시스템의 처리량이 크게 향상됩니다. 테스트 후 간단한 트랜잭션 처리를 위해 약 10%에서 20%의 성능 향상이 있습니다.

CompactBlock 기술은 CITA에서 컨센서스 블록의 크기를 압축하고 네트워크 대역폭 활용을 개선하는 데 사용됩니다. 블록 내의 트랜잭션은 단독으로 한 번만 브로드캐스트되었으므로 트랜잭션 ID만 합의 블록에 포함하면 되므로 블록 메시지의 크기를 크게 줄일 수 있습니다. 네트워크 상태가 좋은 경우 단순 트랜잭션 처리에 대해 5%~10%의 성능 향상이 있는 것으로 테스트되었습니다.

패브릭 합의 메커니즘은 비즈니스 효율성 향상을 제한합니다.

Fabric은 노드 역할을 정렬 노드, 보증 노드 및 제출 노드로 나눕니다. 클라이언트는 먼저 보증 노드에 트랜잭션 요청을 전송합니다. 보증 노드가 실행된 후 읽기/쓰기 세트와 서명을 클라이언트에 반환합니다. 클라이언트가 동일한 결과를 충분히 수집한 후 읽기/쓰기 세트를 구성합니다. 서명 및 트랜잭션 요청 서명된 트랜잭션을 정렬 노드로 전송 정렬 노드가 블록을 형성한 후 제출 노드로 브로드캐스팅 제출 노드는 읽기/쓰기 설정 및 서명 수를 만족하는지 확인하고 법적 결과를 해당 원장에 저장합니다.

Fabric에서 트랜잭션 실행은 비결정적이며 이는 FISCO BCOS 및 CITA의 설계 개념과 다릅니다. 따라서 보증 노드는 먼저 트랜잭션을 실행해야 하며 클라이언트는 보증 정책에 따라 결과를 비교한 다음 정렬 노드로 전송하고 마지막으로 제출 노드는 해당 데이터베이스를 확인하고 업데이트합니다. 컨센서스 상태 프로세스는 클라이언트, 승인 노드 및 제출 노드의 공동 참여에 의해 완료되며 주문 노드는 상태 컨센서스가 아닌 거래 순서의 컨센서스에만 책임이 있습니다. 트랜잭션 상태 합의 및 주문을 위해 다양한 전략을 채택할 수 있습니다. 예를 들어 트랜잭션 상태는 동일한 상태의 3/4 이상을 채택할 수 있으며 주문 노드의 합의는 전통적인 Raft 또는 Solo 합의를 사용하며 전통적인 CFT 합의는 대부분의 시나리오를 충족할 수 있습니다. 여기서 문제는 트랜잭션이 사용자의 서명, 여러 보증 노드의 서명 및 읽기/쓰기 세트를 포함해야 하므로 트랜잭션이 매우 커진다는 것입니다.

Fabric이 A와 B 사이의 빈번한 이체와 같은 트랜잭션 상태에 충돌이 있는 경우 각 트랜잭션이 AB의 계정 잔액을 수정하므로 트랜잭션 충돌이 발생합니다. 충돌 거래 블록당 최대 하나의 거래만 처리할 수 있으므로 비즈니스 계약의 시나리오가 크게 제한됩니다.

FISCO BCOS：

성능 비교
CITA 컨센서스 성능 양호

CITA：

전통적인 PBFT
합의 과정에서 트랜잭션은 반복적으로 실행되며 합의 효율성은 평균입니다.
첫 번째 합의 후 실행, 하나의 트랜잭션만 실행되므로 전반적인 효율성이 더 높습니다.
커밋 단계에서 리더 브로드캐스트 프로세스를 최적화하여 합의 시간 단축

Fabric：

제안 사전 실행 기술은 합의와 실행을 병렬화하고 전반적인 성능을 향상시킵니다.
CompactBlock 기술은 대역폭 활용도를 향상시킵니다.

트랜잭션에는 여러 보증 노드 서명과 읽기/쓰기 세트가 필요하므로 매우 큰 트랜잭션이 발생합니다.

애플리케이션 시나리오

FISCO BCOS는 전통적인 PBFT를 채택하고 합의 효율성은 평균이며, CITA는 자체 개발한 CITA-BFT를 채택하고 합의 및 거래 처리 성능이 50% 이상 향상되었습니다. 전체 프로세스를 실행, 정렬, 검증으로 나누고 유연성을 높이지만 검증과 실행을 분리하면 매우 큰 트랜잭션이 발생합니다.

애플리케이션 시나리오

패브릭: 합의 프로세스를 실행, 정렬 및 검증으로 분할하여 유연성이 더 높지만 결과 트랜잭션 구조가 매우 크고 충돌하는 트랜잭션의 각 블록은 하나의 트랜잭션만 체인에 업로드할 수 있어 비즈니스 계약 장면을 크게 제한합니다. 예를 들어 통계적 투표 계약의 경우 총 투표 결과가 공유 상태이기 때문에 N명의 투표자가 있고 각 투표자는 트랜잭션을 전송하여 투표합니다. 이 경우 각 블록은 하나의 트랜잭션만 처리할 수 있습니다. 예를 들어 란다오 프로젝트의 경우 참여자들이 제출한 모든 정보를 수집해야 하는데 이때 정보를 저장하기 위한 설정변수가 필요하며 각 참여자의 트랜잭션은 이 설정변수를 수정하게 되므로 각 블록은 오직 처리만 가능하다. 하나의 제출된 트랜잭션 및 컬렉션 변수로 인해 읽기/쓰기 세트가 매우 커집니다.

확장성

안전

확장성

Fabric의 경우 실행, 정렬 및 제출 노드 기능이 분리되어 실행(검증) 및 정렬이 서로 다른 합의 전략을 채택할 수 있으므로 보안 전략은 사용자가 자유롭게 파악할 수 있으며 클라이언트는 상태 합의에 참여합니다. 그리고 실행.

스마트 계약

보조 제목

스마트 계약

"스마트 계약"이라는 용어는 다소 오해의 소지가 있습니다. 지능은 종종 사람들에게 어느 정도의 신비를 가져다주며 계약 기능 자체에 대한 "지능"은 없습니다. 블록체인이 등장하기 전에 모든 시스템은 중앙 집중식 아키텍처를 채택했으며 규제자와 사용자는 시스템 기능의 정확성을 확인 및 보장할 수 없었고 데이터가 악의적으로 수정되지 않았으며 데이터의 보안을 보장할 수 없었습니다. . 블록체인의 등장으로 거래는 제3자에 의존하지 않고 확실하게 이루어질 수 있으며, 거래는 추적이 가능하고 되돌릴 수 없습니다. 스마트 계약의 핵심 의미는 블록체인 기반의 신뢰할 수 있는 컴퓨팅과 블록체인 프로토콜이 보장하는 추적성과 비가역성을 실현하는 것입니다.

비트코인의 거래는 주로 P2P 현금 결제에 사용되며, 이더리움은 튜링 완전 스마트 계약 도입으로 블록체인 2.0으로 불린다. 이론적으로 이더리움의 스마트 계약은 튜링 완전하지만 거래 수수료, 계약 지침, 블록 가스 상한, 노드 신뢰성 등의 제한으로 인해 퍼블릭 체인 스마트 계약은 기존 기업 개발에 적합하지 않습니다.

컨소시엄 체인은 제한된 수의 노드로 인해 엔터프라이즈 개발에 더 적합하며 노드 운영자는 고성능 하드웨어 장치와 기본 프로토콜 지원을 사용할 수 있습니다. 먼저 이 글은 세 가지 스마트 계약의 기술적 구현을 소개하고 보안, 사용 용이성 및 사용성이라는 세 가지 측면에서 비교 분석을 수행합니다.

기술적 실현

BCOS와 CITA 모두 EVM과 미리 컴파일된 계약을 지원합니다. 이더리움 스마트 계약의 완전한 생태계의 도움으로 두 가지 모두 이를 기반으로 맞춤화되었으며 풍부한 계약 작성 및 테스트 도구가 있습니다.

Fabric의 계약은 ChainCode를 통해 Docker 형태로 오프라인에 설치되고 트랜잭션을 통해 활성화됩니다. ChainCode 컨트랙트의 배포는 상대적으로 무겁지만 다국어(Go, Javascript 등)를 지원합니다. 정확하고 내부 논리의 특정 구현에 대해 신경 쓰지 않습니다.

안전

Fabric은 계약 작성에 전통적인 언어를 사용하기 때문에 가상 머신의 불확실성으로 인해 개발자가 새로운 언어를 배울 필요가 없지만 ChainCode 방법은 Fabric의 합의 실행, 합의 및 검증에만 적합하며 다재.

안전

보안은 스마트 계약을 다른 프로그램과 구별하는 주요 기능으로 여기에는 확실성, 검증 가능성, 감사 가능성 및 추적 가능성과 같은 기능이 포함됩니다.

비교를 통해 BCOS/CITA 트랜잭션이 체인에서 실행되기 때문에 BCOS/CITA의 스마트 계약이 더 결정적이고 검증 가능하며 감사 가능하고 비가역적이며 추적 가능하다는 것을 알 수 있습니다.

사용의 용이성

Fabric의 계약 코드는 보증 노드에 의해 각각 배포 및 업그레이드되며 검증 가능성, 감사 가능성 및 추적 가능성을 보장할 수 없습니다. 그러나 Fabric의 설계 개념에서 클라이언트는 실행 후 계약을 검증합니다.이 기사는 계약의 최종 결과가 클라이언트와 보증 노드에 의해 결정된다고 생각할 수 있습니다.트랜잭션 결과가 보증 정책을 준수하는 한 사용자의 기대를 충족하는 코드 확인 요구 사항은 상대적으로 덜 중요합니다.

사용의 용이성

BCOS/CITA는 계약 사용 편의성 측면에서 Fabric보다 약간 우수합니다.

유효성

BCOS/CITA/Fabric은 기업의 복잡한 비즈니스 논리에 대처하고 보다 복잡한 계약 계산 및 처리를 지원할 수 있으며 CITA는 체인에서 타이밍 작업을 지원합니다.

보조 제목

성능

최근 몇 년 동안 블록체인의 기본 기술이 개발된 후, 얼라이언스 체인의 성능은 더 이상 주요 병목 현상이 아닙니다.

BCOS 공식 문서는 성능 데이터를 제공하지 않습니다. 이 기사는 제3자가 제공한 데이터를 기반으로만 판단할 수 있습니다. 우리는 비교적 신뢰할 수 있는 두 가지 정보 출처를 찾았습니다. 중국 정보 통신 기술 아카데미(China Academy of Information and Communications Technology)의 신뢰할 수 있는 블록체인에 대한 최신 평가(2019년 11월-19일)에서 BCOS 단일 체인 TPS는 20,000을 초과했습니다. [2019년 7월 말 보도자료](미정) 테스트 팀이 블록체인 성능이 10,000TPS에 도달했다고 말했을 때 Zhang Kaixiang은 WeChat 그룹에서 그의 인생에서 가장 큰 빨간 봉투를 팀에 보냈습니다. 두 테스트 데이터는 테스트 환경, 노드 수, 사용된 합의 프로토콜(BCOS는 Raft 지원) 등을 제공하지 않았기 때문에 서로 다른 합의 방식과 노드 수를 테스트에 사용했을 것으로 추측된다.https://arxiv.org/pdf/1801.10228.pdf공식 문서에 있는 CITA 최신 버전의 트랜잭션 성능은 15,000+ TPS에 도달할 수 있습니다. 데이터는 CITA 버전 0.16(2018년 5월 15일)에서 가져옵니다. 4개의 노드가 4개의 32코어, 64G 클라우드 서버에 배포됩니다. 각 서버 구성 100M 대역폭.

](https://arxiv.org/pdf/1801.10228.pdf)), 32코어 CPU와 10노드의 경우 성능은 약 3400에 도달할 수 있습니다. 이 보고서에 따르면 보증 노드는 실제로 합의에 참여하지 않기 때문에 보증 노드의 수는 성능에 거의 영향을 미치지 않습니다.

이 단계에서 동맹의 성능은 큰 진전을 이루었고 상륙 시나리오와 비교할 때 성능은 더 이상 주요 병목 현상이 아닙니다. 동시에 국내 연맹 체인은 성능면에서 외국 대형 브랜드에 지지 않고 외국보다 앞섰다.

보조 제목

저장

콘텐츠 측면에서 블록체인 스토리지는 주로 블록 및 트랜잭션 스토리지와 세계 상태 스토리지라는 두 가지 측면을 포함합니다. 이 기사에서는 먼저 각각의 구현 방법을 소개한 다음 지원되는 데이터베이스 유형, 스토리지 효율성, 확장성 및 데이터 유지 관리 측면에서 비교 분석을 수행합니다.

실현 방법

BCOS의 상태 저장은 두 가지 저장 모드를 지원합니다.

블록의 저장을 위해 BCOS 트랜잭션 목록, 트랜잭션 영수증 등은 모두 기존의 MPT 방식으로 저장됩니다. World State의 경우 BCOS는 스토리지 상태와 MPT 상태의 두 가지 스토리지 모드를 채택합니다. MPT 상태는 RocksDB 및 외부 저장소를 지원합니다 MPT 저장소는 기록 상태를 저장하면서 저장소 데이터를 최소화합니다. Storage State는 RocksDB, MySQL, External을 지원하며, Storage State Storage를 사용할 경우 일부 추적성은 희생되나 성능 향상을 가져오며 SQL 문 쿼리 및 통계를 지원할 수 있습니다. 세계의 상태는 항상 트랜잭션을 통해 복원될 수 있으므로 성능 향상 및 상태 쿼리와 교환하여 일부 추적 가능성을 희생하는 것이 허용됩니다.

CITA는 RocksDB 및 외부 저장소를 지원합니다. MPT를 사용하여 상태를 저장하고 Simple Merkle Tree를 사용하여 거래 및 거래 영수증을 저장합니다. 상태 스토리지의 경우 CITA는 과거 상태를 저장하고 동시에 스토리지 데이터를 최소화하는 클래식 MPT 스토리지를 선택했습니다. 트랜잭션 및 트랜잭션 영수증의 경우 Simple Merkle Tree 스토리지를 사용하면 저장된 데이터의 양을 최적화하고 해시 계산을 줄일 수 있습니다.

Fabric의 블록 스토리지도 MPT 방식으로 저장됩니다. 세계 상태 스토리지는 KV 및 CouchDB 스토리지를 지원합니다.세계 상태를 저장할 때 Fabric은 과거 상태 보존을 지원하지 않는 동시에 성능이 향상되고 풍부한 조건부 쿼리 및 통계를 지원합니다.

비교 분석

비교하려고:

본 논문은 트랜잭션 저장 측면에서 노드는 히스토리컬 레코드를 유지해야 하며 world state의 히스토리컬 스토리지는 트랜잭션을 통해 복원할 수 있다고 생각하며, 이 경우 BCOS/Fabric은 사용자에게 더 나은 쿼리 기능과 더 높은 성능을 제공합니다. 좋은 트레이드 오프.

통치

보조 제목

통치

얼라이언스 체인과 퍼블릭 체인의 가장 큰 차이점은 거버넌스 방식이 다르다 퍼블릭 체인은 개방형 시스템이기 때문에 서로 다른 역할 간의 관계를 조정하기 위해 일정한 경제적 인센티브가 필요하고 얼라이언스 체인은 노드는 액세스 메커니즘이므로 거버넌스 방식이 퍼블릭 체인과 매우 다릅니다. 제휴 체인의 거버넌스는 주로 노드 관리, 계정 권한 및 경제 모델을 포함합니다.

노드 관리

BCOS 및 CITA의 경우 노드는 주로 합의 노드와 일반 노드의 두 가지 범주로 나뉩니다. 컨센서스 노드는 컨센서스 블록 생성을 담당하며 일반 노드는 패키지 트랜잭션에 대한 권한 없이 데이터를 동기화하고 데이터를 검증할 수만 있습니다.

Fabric의 경우 노드는 보증 노드, 주문 노드 및 제출 노드로 나뉩니다. 보증 노드는 트랜잭션을 실행하고 결과를 반환하는 역할을 하고, 정렬 노드는 트랜잭션을 정렬하고 블록으로 패키징하는 역할을 하며, 제출 노드는 트랜잭션을 확인하고 상태를 업데이트하는 역할을 합니다.

컨센서스 노드 BCOS/CITA의 경우 시스템 컨트랙트를 사용하여 관리하며 노드 추가 및 삭제는 컨센서스 노드의 컨센서스가 필요합니다. Fabric 노드의 추가 및 삭제는 합의 없이 노드 관리자가 수정할 수 있지만 새로운 구성 파일을 활성화하려면 트랜잭션 전송 및 합의가 필요합니다.

이 기사는 화이트리스트/블랙리스트 또는 CA를 통해 노드 ID를 관리하는 것이 대부분의 동맹 체인 시나리오를 만족시킬 수 있으며 CA는 노드 ID를 확인하는 데 더 엄격하다고 생각합니다.

사용자 권한 관리

컨소시엄 체인의 경우 컨소시엄 및 컨소시엄 내의 각 역할에는 더 복잡한 권한 관리가 필요하므로 서로 다른 역할은 권한이 부여된 리소스에만 액세스할 수 있습니다.

CITA/BCOS에서 사용자의 트랜잭션 권한은 트랜잭션 보내기, 계약 생성, 계약 메서드 호출 권한 등을 포함한 복잡한 권한 관리를 통해 관리됩니다.

Fabric은 구성 파일(정책)을 통해 사용자 권한을 관리합니다.

BCOS/CITA 권한 관리는 구성 파일을 통해 수정된 Fabric보다 더 블록체인 기반인 트랜잭션을 통해 관리되며 거버넌스 작업은 추적을 유지합니다.

경제 모델

CITA는 두 가지 경제 모델을 지원합니다.