[논문 리뷰] ChainifyDB: How to Blockchainify any Data Management System

Felix Schuhknecht, Ankur Sharma외 2명|arXiv (Cornell University)|2019. 12. 10.

Blockchain Technology Applications and Security참고 문헌 26인용 수 5

한 줄 요약

ChainifyDB는 기존의 이질적인 관계형 데이터베이스 관리 시스템에 블록체인 기능을 통합할 수 있도록 하는 새로운 블록체인 레이어를 도입한다. 이는 Whatever-LedgerConsensus(WLC) 모델을 통해 일관성 확보를 위해 거래 순서가 아닌 실행 결과에 대해 합의를 이루는 방식으로, 실행 순서에 대한 결정성 가정 없이도 고성능이고 내구성이 뛰어난 통합을 가능하게 한다. 이로 인해 결정성 실행이나 무결성 보장된 로컬 스토리지에 대한 가정 없이도 기존의 다양한 DBMS를 통합할 수 있으며, Fabric 대비 최대 6배 높은 처리량을 달성하고 상태 이탈에 대한 강력한 복구 기능도 제공한다.

ABSTRACT

Today's permissioned blockchain systems come in a stand-alone fashion and require the users to integrate yet another full-fledged transaction processing system into their already complex data management landscape. This seems odd as blockchains and traditional DBMSs share large parts of their processing stack. Thus, rather than replacing the established data systems altogether, we advocate to simply 'chainify' them with a blockchain layer on top. Unfortunately, this task is far more challenging than it sounds: As we want to build upon heterogeneous transaction processing systems, which potentially behave differently, we cannot rely on every organization to execute every transaction deterministically in the same way. Further, as these systems are already filled with data and being used by top-level applications, we also cannot rely on every organization being resilient against tampering with its local data. Therefore, in this work, we will drop these assumptions and introduce a powerful processing model that avoids them in the first place: The so-called Whatever-LedgerConsensus (WLC) model allows us to create a highly flexible permissioned blockchain layer coined ChainifyDB that (a) is centered around bullet-proof database technology, (b) makes even stronger guarantees than existing permissioned systems, (c) provides a sophisticated recovery mechanism, (d) has an up to 6x higher throughput than the permissioned blockchain system Fabric, and (e) can easily be integrated into an existing heterogeneous database landscape.

연구 동기 및 목표

• 기존 데이터 관리 인fra구조에 독립형 블록체인 시스템을 도입할 때 발생하는 높은 통합 비용과 복잡성을 해결하기 위해.
• 비결정적 동작를 보일 수 있거나 데이터 변조에 취약한 이질적인 기존 데이터베이스 시스템에 대해 안전하고 확장성 있고 내구성이 뛰어난 블록체인 기능을 제공하기 위해.
• 허가된 블록체인 설계에서 결정성 거래 실행과 불변성 보장된 로컬 스토리지에 대한 가정에 의존하지 않도록 하기 위해.
• 데이터 마이그레이션이나 애플리케이션 재작성 없이도 기존의 다양한 데이터베이스 환경에 원활하게 통합될 수 있는 블록체인 레이어를 설계하기 위해.
• 전체 네트워크를 정지시키지 않고도 상태 이탈을 탐지하고 복구할 수 있는 복구 메커니즘을 제공하기 위해.

제안 방법

• 실행 중 결정성 행동에 대한 가정을 피하기 위해, 합의를 실행 후 단계인 파이프라인의 끝에서 수행하는 Whatever-LedgerConsensus(WLC) 모델을 도입한다.
• 순서-실행-합의(OEC) 처리 모델을 구현하여, 거래 순서나 실행 로직이 아닌 최종 상태 효과에 대해 합의를 이룬다.
• 실행 결과의 암호화 해시를 통해 상태 이탈을 탐지하고, 일관성이 손상된 경우 가장 최근 체크포인트로 롤백하는 복구 메커니즘을 설계한다.
• 유연한 합의 정책(예: Any-2, All-3)을 지원하여, 일부 조직이 복구 중이거나 지연되더라도 다수의 조직이 현재 상태에 합의하면 네트워크가 계속 진행될 수 있도록 한다.
• 거래 및 합의 메시지의 진위성과 무결성을 보장하기 위해 여러 단계에서 암호화 서명과 검증을 구현한다.
• 기반 DBMS에서 충돌이 없는 거래를 동시에 실행할 수 있도록 병렬 처리를 활용하여 처리량을 극대화한다.

실험 결과

연구 질문

• RQ1 실행 의미 체계를 완전히 제어할 수 없는 이질적이고 비결정적, 또는 변조 가능성이 있는 데이터베이스 시스템 위에 블록체인 레이어를 구축할 수 있는가?
• RQ2 다양한 DBMS 간에 일관성과 장애 내성 보장을 확보하면서도, 거래 순서가 아닌 시스템 상태 효과에 대해 합의를 이룰 수 있는 방법은 무엇인가?
• RQ3 암호화 연산과 병렬 실행의 성능 오버헤드는 얼마이며, 이를 최소화할 수 있는 방법은 무엇인가?
• RQ4 일부 조직에서 데이터 손상이나 처리 지연이 발생할 경우, 시스템은 상태 분열을 어떻게 처리하고 복구하는가?
• RQ5 블록 크기와 합의 정책이 이질적인 환경에서 시스템 처리량과 네트워크 생존성에 미치는 영향은 무엇인가?

주요 결과

• ChainifyDB는 기존의 허가된 블록체인 시스템인 Hyperledger Fabric 대비 최대 6배 높은 처리량을 달성한다. 이는 효율적인 병렬 거래 실행 덕분이다.
• 서명 및 검증과 같은 암호화 연산은 처리량에 7~8.5%의 오버헤드만 추가하여 성능에 미치는 영향이 극히 미미하다.
• 데이터 손상이나 비결정적 실행으로 인한 상태 이탈을 성공적으로 탐지하고, 가장 최근 체크포인트로 복구하여 일관성을 복원한다.
• 느린 또는 장애가 발생한 조직이 있는 이질적 환경에서도 ChainifyDB는 Any-2와 같은 합의 정책을 통해 네트워크의 생존성을 유지한다.
• 동일한 환경에서는 상태 이탈 복구가 복구 중인 조직에만 영향을 주며, 나머지 네트워크는 영향을 받지 않으며, 복구 소요 시간은 약 4초 내외이다.
• 블록 크기를 증가시키면 병렬 실행의 활용도가 향상되어 처리량이 증가하며, 블록 크기와 성능 간의 상관관계는 로그 스케일링 특성을 보인다.