Wheelset용 분산 레지스트리: Hyperledger Fabric 경험

안녕하세요. 저는 DRD KP 프로젝트(휠 세트의 수명주기 모니터링을 위한 분산 데이터 레지스트리) 팀에서 일하고 있습니다. 여기에서는 기술의 제약 하에 이 프로젝트를 위한 엔터프라이즈 블록체인을 개발한 우리 팀의 경험을 공유하고 싶습니다. 대부분 Hyperledger Fabric에 대해 이야기하겠지만, 여기에 설명된 접근 방식은 허가된 모든 블록체인에 적용할 수 있습니다. 우리 연구의 궁극적인 목표는 최종 제품이 사용하기 즐겁고 유지 관리가 너무 어렵지 않은 방식으로 엔터프라이즈 블록체인 솔루션을 준비하는 것입니다.

발견이나 예상치 못한 해결책은 없을 것이며, 여기서는 어떤 독특한 개발도 다루지 않을 것입니다(왜냐하면 저는 그것들을 갖고 있지 않기 때문입니다). 나는 단지 내 겸손한 경험을 공유하고 "가능했다"는 것을 보여주고 아마도 댓글에서 좋은 결정과 그렇지 않은 결정을 내린 다른 사람의 경험에 대해 읽고 싶을 것입니다.

문제: 블록체인은 아직 확장 가능하지 않습니다.

오늘날 많은 개발자들의 노력은 블록체인을 아름다운 포장에 담긴 시한폭탄이 아닌 정말 편리한 기술로 만드는 것을 목표로 하고 있습니다. 상태 채널, 낙관적 롤업, 플라즈마 및 샤딩이 일반화될 수 있습니다. 타일. 아니면 TON이 다시 XNUMX개월 동안 출시를 연기하고 다음 플라즈마 그룹이 더 이상 존재하지 않게 될 수도 있습니다. 우리는 또 다른 로드맵을 믿고 밤에 훌륭한 백서를 읽을 수 있지만 지금 여기서는 우리가 가지고 있는 것을 가지고 뭔가를 해야 합니다. 일을 끝내세요.

현재 프로젝트에서 우리 팀에 할당된 작업은 일반적인 용어로 다음과 같습니다. 신뢰 관계를 구축하고 싶지 않은 수천 명에 달하는 많은 주제가 있습니다. 특별한 성능 요구 사항 없이 일반 PC에서 작동하고 중앙 집중식 회계 시스템보다 나쁘지 않은 사용자 경험을 제공하는 솔루션을 DLT를 기반으로 구축해야 합니다. 솔루션 이면의 기술은 악의적인 데이터 조작 가능성을 최소화해야 합니다. 이것이 바로 블록체인이 존재하는 이유입니다.

백서와 미디어의 슬로건은 다음 개발이 초당 수백만 건의 트랜잭션을 허용할 것이라고 약속합니다. 정말 무엇입니까?

메인넷 이더리움은 현재 ~30tps로 실행되고 있습니다. 이 때문에 어떤 면에서든 기업의 요구에 적합한 블록체인으로 인식하기는 어렵습니다. 허가된 솔루션 중에서 2000tps를 보여주는 벤치마크가 알려져 있습니다(정족수) 또는 3000tps(하이퍼 레더 직물, 출판물에는 조금 적은 내용이 있지만 벤치마크는 기존 합의 엔진에서 수행되었다는 점을 명심하세요.) 였다 Fabric을 근본적으로 재작업하려는 시도, 20000tps라는 최악의 결과는 아니지만 지금까지는 안정적인 구현을 기다리는 학문적 연구 일뿐입니다. 블록체인 개발자 부서를 유지할 여유가 있는 기업이 이러한 지표를 참을 가능성은 거의 없습니다. 그러나 문제는 처리량뿐만 아니라 대기 시간도 있습니다.

숨어 있음

거래가 시작된 순간부터 시스템의 최종 승인까지의 지연은 검증 및 주문의 모든 단계를 통과하는 메시지의 속도뿐만 아니라 블록 형성 매개변수에 따라 달라집니다. 블록체인을 통해 1000000tps로 커밋할 수 있지만 10MB 블록을 형성하는 데 488분이 걸린다고 해도 더 쉬워질까요?

시간이 걸리는 부분과 이것이 블록 형성 매개변수와 어떻게 관련되는지 이해하기 위해 Hyperledger Fabric에서 트랜잭션의 수명 주기를 자세히 살펴보겠습니다.

여기에서 가져온: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) 클라이언트는 트랜잭션을 형성하고 이를 승인하는 피어에게 보내고, 피어는 트랜잭션을 시뮬레이션하고(체인코드에 의해 변경된 사항을 현재 상태에 적용하지만 원장에 커밋하지 않음) RWSet(키 이름, 버전 및 CouchDB의 컬렉션에서 가져온 값, (2) 보증인은 서명된 RWSet를 클라이언트에 다시 보냅니다. (3) 클라이언트는 필요한 모든 피어(보증인)의 서명을 확인한 다음 트랜잭션을 주문 서비스에 보냅니다. , 또는 확인 없이 전송하면(확인은 나중에 수행됨) 주문 서비스가 블록을 형성하고 (4) 보증자뿐만 아니라 모든 피어에게 다시 보냅니다. 피어는 읽기 세트의 키 버전이 데이터베이스의 버전, 모든 보증인의 서명과 일치하는지 확인하고 마지막으로 블록을 커밋합니다.

그러나 그것이 전부는 아닙니다. "주문자가 블록을 형성합니다"라는 단어 뒤에는 거래 순서뿐만 아니라 리더가 팔로어에게 보내는 3개의 연속 네트워크 요청도 숨겨져 있습니다. 리더는 로그에 메시지를 추가하고 팔로어에게 보내고 후자는 그들의 로그는 성공적인 복제 확인을 리더에게 보내고, 리더는 메시지를 커밋하고, 팔로워에게 커밋 확인을 보내고, 팔로워는 커밋합니다. 블록 크기와 시간이 작을수록 주문 서비스가 합의를 수립해야 하는 경우가 더 자주 발생합니다.. Hyperledger Fabric에는 두 가지 블록 형성 매개변수가 있습니다. BatchTimeout - 블록 형성 시간 및 BatchSize - 블록 크기(트랜잭션 수 및 블록 자체의 크기(바이트)). 매개변수 중 하나가 한계에 도달하면 즉시 새 블록이 발행됩니다. Orderer 노드가 많을수록 시간이 더 오래 걸립니다. 따라서 BatchTimeout 및 BatchSize를 늘려야 합니다. 그러나 RWSets의 버전이 관리되므로 블록을 더 크게 만들수록 MVCC 충돌 가능성이 높아집니다. 또한 BatchTimeout이 증가하면 UX가 심각하게 저하됩니다. 이러한 문제를 해결하기 위한 다음 계획은 합리적이고 명백해 보입니다.

블록 완료를 기다리지 않고 거래 상태를 추적하는 방법

형성 시간과 블록 크기가 길어질수록 블록체인의 처리량은 높아집니다. 하나가 다른 하나를 직접 따르지는 않지만 RAFT에서 합의를 설정하려면 리더와 팔로어 간에 세 번의 네트워크 요청이 필요하다는 점을 기억해야 합니다. 주문 노드가 많을수록 시간이 더 오래 걸립니다. 블록 형성의 크기와 시간이 작을수록 그러한 상호 작용은 더 많아집니다. 최종 사용자의 시스템 응답 시간을 늘리지 않고 형성 시간과 블록 크기를 늘리는 방법은 무엇입니까?

먼저, 동일한 버전의 다양한 RWSets를 포함할 수 있는 큰 블록 크기로 인해 발생하는 MVCC 충돌을 어떻게든 해결해야 합니다. 분명히 클라이언트 측에서는(블록체인 네트워크와 관련하여 이는 백엔드일 수 있습니다. 내 말은) MVCC 충돌 처리기, 이는 재시도 논리가 있는 트랜잭션 시작 호출에 대한 별도의 서비스이거나 일반 데코레이터일 수 있습니다.

재시도는 지수 전략으로 구현될 수 있지만, 그러면 대기 시간도 기하급수적으로 저하됩니다. 따라서 특정 작은 제한 내에서 무작위 재시도를 사용하거나 일정한 재시도를 사용해야 합니다. 첫 번째 변형에서 충돌 가능성을 염두에 두고 있습니다.

다음 단계는 클라이언트와 시스템의 상호 작용을 비동기식으로 만들어 BatchTimeout으로 설정하는 15초, 30초 또는 10000000초를 기다리지 않도록 하는 것입니다. 그러나 동시에 거래로 인해 시작된 변경 사항이 블록체인에 기록되거나 기록되지 않도록 하는 기능을 유지해야 합니다.
데이터베이스를 사용하여 트랜잭션 상태를 저장할 수 있습니다. 가장 쉬운 옵션은 사용이 간편하기 때문에 CouchDB입니다. 데이터베이스에는 즉시 사용할 수 있는 UI와 REST API가 있으며 이에 대한 복제 및 샤딩을 쉽게 설정할 수 있습니다. Fabric이 월드 상태를 저장하는 데 사용하는 것과 동일한 CouchDB 인스턴스에 별도의 컬렉션을 생성할 수 있습니다. 우리는 이런 종류의 문서를 저장해야 합니다.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

이 문서는 트랜잭션이 피어에게 전송되기 전에 데이터베이스에 기록되며, 이것이 생성 작업인 경우 엔터티 ID가 사용자에게 반환되고(동일한 ID가 키로 사용됨) Status, TxID 및 Error 필드는 다음과 같습니다. 동료로부터 관련 정보가 수신되면 업데이트됩니다.

이 방식에서 사용자는 블록이 최종적으로 형성될 때까지 기다리지 않고 10초 동안 화면의 물레를 보면서 시스템으로부터 즉각적인 응답을 받고 작업을 계속합니다.

우리는 트랜잭션 상태를 저장하기 위해 BoltDB를 선택했습니다. 메모리를 절약해야 하고 특히 이 상호 작용이 일반 텍스트 프로토콜을 사용하여 발생할 때 독립형 데이터베이스 서버와의 네트워크 상호 작용에 시간을 낭비하고 싶지 않기 때문입니다. 그런데 CouchDB를 사용하여 위에서 설명한 구성표를 구현하든 아니면 단지 세계 상태를 저장하기 위해 사용하든 관계없이 CouchDB에 데이터가 저장되는 방식을 최적화하는 것이 합리적입니다. 기본적으로 CouchDB에서 b-트리 노드의 크기는 1279바이트입니다. 이는 디스크의 섹터 크기보다 훨씬 작습니다. 즉, 트리를 읽고 재조정하려면 더 많은 물리적 디스크 액세스가 필요합니다. 최적의 크기가 표준을 충족합니다. 고급 형식 4킬로바이트입니다. 최적화를 위해서는 매개변수를 설정해야 합니다. btree_chunk_size는 4096과 같습니다. CouchDB 구성 파일에 있습니다. BoltDB의 경우 이러한 수동 개입 필요 없음.

배압: 버퍼 전략

그러나 많은 메시지가 있을 수 있습니다. 시스템이 처리할 수 있는 것 이상으로 다이어그램에 표시된 것 외에도 XNUMX개의 다른 서비스와 리소스를 공유합니다. 이 모든 것은 Intellij Idea를 실행하는 것이 극도로 지루한 시스템에서도 완벽하게 작동해야 합니다.

통신 시스템(생산자와 소비자)의 서로 다른 처리량 문제는 다양한 방식으로 해결됩니다. 우리가 무엇을 할 수 있는지 봅시다.

적하: 우리는 T초 안에 최대 X개의 트랜잭션을 처리할 수 있다고 주장할 수 있습니다. 이 제한을 초과하는 모든 요청은 삭제됩니다. 매우 간단하지만 UX는 잊어버릴 수 있습니다.

제어: 소비자는 부하에 따라 생산자의 tps를 제어할 수 있는 인터페이스를 가지고 있어야 합니다. 나쁘지는 않지만 로드 클라이언트 개발자에게 이 인터페이스를 구현해야 할 의무가 있습니다. 미래의 블록체인은 수많은 기존 시스템에 통합될 것이기 때문에 우리에게는 이것이 용납될 수 없습니다.

버퍼링: 입력 데이터 스트림에 저항하려고 애쓰는 대신 이 스트림을 버퍼링하고 필요한 속도로 처리할 수 있습니다. 분명히 이것은 좋은 사용자 경험을 제공하려는 경우 최고의 솔루션입니다. RabbitMQ의 큐를 사용하여 버퍼를 구현했습니다.

두 가지 새로운 작업이 체계에 추가되었습니다. (1) API 요청을 받은 후 트랜잭션을 호출하는 데 필요한 매개변수와 함께 메시지가 대기열에 추가되고 클라이언트는 시스템에서 트랜잭션이 수락되었다는 메시지를 받습니다. 2) 백엔드는 대기열에서 구성에 지정된 속도로 데이터를 읽습니다. 트랜잭션을 시작하고 상태 저장소의 데이터를 업데이트합니다.
이제 원하는 만큼 빌드 시간과 블록 용량을 늘려 사용자에게 지연을 숨길 수 있습니다.

기타 도구

일반적으로 최적화할 내용이 없기 때문에 여기서는 체인코드에 대해 언급하지 않았습니다. 체인코드는 가능한 한 간단하고 안전해야 합니다. 이것이 필요한 전부입니다. 프레임워크는 체인코드를 간단하고 안전하게 작성하는 데 많은 도움이 됩니다. CSKit S7 Techlab 및 정적 분석기에서 부활^CC.

또한 우리 팀은 Fabric 작업을 간단하고 즐겁게 만들기 위해 다음과 같은 유틸리티 세트를 개발하고 있습니다. 블록체인 탐색기, 유틸리티 자동 네트워크 재구성 (조직 추가/제거, RAFT 노드), 유틸리티 인증서 해지 및 신원 제거. 기여하고 싶다면 환영합니다.

결론

이 접근 방식을 사용하면 Hyperledger Fabric을 Quorum, 기타 개인 이더리움 네트워크(PoA 또는 PoW)로 쉽게 교체하고 실제 처리량을 크게 줄이면서도 동시에 일반 UX를 유지할 수 있습니다(브라우저 사용자와 통합 시스템 측면 모두) ). 구성표에서 Fabric을 Ethereum으로 교체할 때 재시도 서비스/데코레이터의 논리만 MVCC 충돌 처리에서 원자 nonce 증가 및 재전송으로 변경하면 됩니다. 버퍼링 및 상태 저장을 통해 응답 시간과 블록 형성 시간을 분리할 수 있었습니다. 이제 수천 개의 주문 노드를 추가할 수 있으며 블록이 너무 자주 형성되어 주문 서비스를 로드하는 것을 두려워하지 않을 수 있습니다.

일반적으로 이것이 제가 공유하고 싶은 전부입니다. 누군가의 업무에 도움이 된다면 기쁘겠습니다.

출처 : habr.com