아르고 리오그 시 SQL 데이터 일관성 검증

아르고 SQL 기능

현재 IT 시장에서 블록체인 생태계를 도입하려면 블록체인 시스템뿐만 아니라 데이터베이스가 필요합니다. 레거시 생태계에서 데이터 수정 기능이 없는 블록체인만으로는 시스템을 관리하기 힘들기 때문입니다.

블로코는 블록체인 업체 최초로 데이터베이스를 따로 설치하지 않고 아르고 SQL 기능으로 기존 데이터베이스 영역에 도전해 보려 합니다.

아르고 기능에는 아르고 SQL(1.0.0)과 JDBC(1.3.0) 기능이 있습니다. 아르고 keystore 2.2.0 메인넷 릴리즈 준비를 위해 아르고 SQL, 아르고 JDBC 1.1, keystore 연동 테스트를 했고 성공적으로 마쳤습니다.

컨센서스와 SQL 관계도

아르고에는 여러 개의 컨센서스가 있으며 사용범위와 목적에 따라 퍼블릭(mainnet/testnet)/프라이빗(alpha)과 DPoS/Raft로 나눠져 있습니다.

아르고 SQL의 사용 영역이 무척 궁금해 아르고 SQL의 사용 영역과 아르고 컨센서스의 관계를 분석했는데, 아르고 퍼블릭 컨센서스에서는 DB 패키지 사용 불가로 SQL 데이터는 현재 사용이 불가한 것을 확인했습니다.

아르고 프라이빗 컨센서스는 투표를 통해 N 개 블록 프로듀서를 선정하여 1초당 한 블록 생산권을 순위권인 블록 노드에게 주는 DPoS 컨센서스와 N 개 블록후보 노드들이 빠른 네트워크 측정을 통해 1개의 블록에게만 생산권을 부여하는 Raft 컨센서스로 나눠집니다.

SQL 데이터는 보편적으로 노드 간 불일치하게 되면 큰 장애가 되기에 아르고 SQL이 리오그가 발생되지 않는 Raft에는 적합하다고 판단되지만, 네트워크 단절을 통해 리오그가 발생되는 DPoS에서도 안전할지 의문이 들었습니다.

이번 테스트를 통해 SQL 데이터는 네트워크 단절을 통한 리오그 발생 시 데이터 일관성이 유지되는지 확인해보았습니다.

아르고 체인 리오그 테스트 시나리오

  1. 체인 포크 시나리오
  • 체인 포크는 네트워크 단절 시 서로 다른 BP 노드가 같은 높이 블록을 생성하는 것입니다.
  • 체인 포크 재현을 목적으로 하나의 체인에서 포크가 발생하려면 네트워크 단절 후 서로 다른 BP 리스트가 동시에 블록을 생성합니다.

 

  1. 체인 리오그 시나리오
  • 체인 리오그는 단절된 네트워크가 다시 접속하게 되면 분기가 발생했을 때, 해당 시점에서 더 많은 작업 증명이 수행되어 길이가 더 긴 블록을 선택합니다.
  • 두 갈래로 기록된 블록들 중에 수행 길이가 짧은 체인은 버리고, 수행 길이가 긴 메인 체인을 선택하게 됩니다.

 

  1. SQL 포크, 리오그 시 데이터 일관성 점검 시나리오
  • 이 테스트의 목적은 아르고 SQL 데이터베이스도 체인 리오그 시 레코드의 일관성을 유지하는지 점검하는 것입니다.
각 프로세스 별 레코드 점검 항목

3-1. FORK 발생 단서 1은 각 노드의 BP 리스트 확인

  • 포크 이전 BP 리스트 기댓값 : [BP1, BP3, BP5]
  • 포크 이후 BP 리스트 기댓값 : [BP1, BP2, BP5(접속 안됨)], [BP4, BP5, BP1(접속 안됨)]
  • 리오그 이후 BP 리스트 기댓값 : [BP1, BP2, BP5]

3-2. FORK 발생 단서는 각 노드의 peer 정보 리스트 비교 → 네트워크 단절 및 재접속이 되는지 확인

  • 포크 이전 네트워크 상태 : [BP1 – BP2 – BP3 – BP4 – BP5]
  • 포크 이후 네트워크 상태 1 : [BP1 – BP2 – BP3], [BP4 – BP5]
  • 포크 이후 네트워크 상태 2 : [BP1 – BP2], [BP3 – BP4 – BP5]
  • 리오그 이후 네트워크 상태 : [BP1 – BP2 – BP3 – BP4 – BP5]

3-3. FORK 발생 후 각 노드 SQL tx 기록하고, 리오그 되었을 때 SQL 데이터베이스도 일관성 유지되는지 확인

  • 포크 이전 SQL 블록 정보 기댓값 : [BP1]
  • 포크 이후 네트워크 상태 1 SQL 블록 정보 기댓값 : [BP1, BP2], [BP1]
  • 포크 이후 네트워크 상태 2 SQL 블록 정보 기댓값 : [BP1, BP2], [BP1, BP4]
  • 리오그 이후 네트워크 상태 SQL 블록 정보 기댓값 : [BP1, BP2, BP5]

테스트 전 SQL Deploy 준비

SQL 기록 컨트랙트 deploy & SQL tx call
SQL tx: 각 노드의 블록 정보를 SQL로 기록하는 트랜잭션

SQL deploy 예시

 

각 BP의 SQL tx 전송주소 

  • [BP1] AmPpcKvToDCUkhT1FJjdbNvR4kNDhLFJGHkSqfjWe3QmHm96qv4R
  • [BP2] AmQ2tS46doLfqsH4vy7PXmvGn7paec8wgqPWmGrcJKiLZADrJcME
  • [BP3] AmN1HCGLsr5BEJMpz3mUnue7V9q44GzarvomBJdMTs7LCS4Mg5iq
  • [BP4] AmNWNd2hKZEev1eYq4hitgfnFMws8KaigS4fNqNGDMiCv9UVAFK6
  • [BP5] AmMZv5LTVPdm3R1MePghqA4ujHvKZqoaNg8KqA6Hoy1K2cVu154n

포크 이전 Mainchain 세팅 시나리오

BP1(500,000 아르고), BP3(100,000 아르고), BP5(400,000 아르고)는 BP 리스트며 네트워크 연결은 BP1-BP2-BP3-BP4-BP5로 이뤄진 메인 체인 상태에서 BP1에 블록 정보 SQL tx를 호출했습니다.

SQL 조회 시 Sidechain A는 BP2 기준, Sidechain B는 BP4 기준으로 JDBC 접속했습니다.

포크 이전 메인 체인이 분리되지 않은 상황에서 Sidechain A와 Sidechain B의 레코드가 동일한 것을 확인할 수 있습니다.

포크 이전 Mainchain 컨센서스

포크 이전 SQL 조회결과
  • Mainchain(Sidechain A)

  • Mainchain(Sidechain B)

Mainchain 구성 스크립트 실행

포크 이전 네트워크 상태

포크 되면 두 갈래로 나눠지는데 그 영역을 Sidechain A, Sidechain B로 정의했습니다.

포크 이후 Sidechain A 구성 시나리오

BP3, BP4 네트워크 단절 후 BP2(300,000 아르고)로 BP 리스트 수정했습니다.

Sidechain A 구성으로 BP1(500,000 아르고), BP2(300,000 아르고), BP5(400,000 아르고)가 BP 리스트이며 네트워크 연결은 [BP1-BP2-BP3] [BP4-BP5]로 이루어졌습니다.

그 후 Sidechain A인 BP2에 블록 정보 SQL tx를 호출했습니다.

[BP2] 레코드는 Sidechain A에서만 조회되고 Sidechain B에서는 누락된 것을 확인했습니다.

포크 이후 Sidechain A 컨센서스

포크 이후 SQL 조회결과
  • Sidechain A

  • Sidechain B

Sidechain A 구성 스크립트 실행

포크 이후 네트워크 상태

포크 이후 Sidechain B 구성 시나리오

BP2, BP3 네트워크 단절, BP3, BP4 네트워크 재연결 후 BP3을 초기화하여 BP4(200,000 아르고)로 BP 리스트 수정했습니다.

Sidechain B 구성으로 BP1(500,000 아르고), BP4(200,000 아르고), BP5(400,000 아르고)가 BP 리스트이며 네트워크 연결은 [BP1-BP2] [BP3-BP4-BP5]로 이루어졌습니다.

그 후 Sidechain B 영역인 BP4에 블록 정보 SQL tx를 호출했습니다.

Sidechain A에서는 [BP1], [BP2] 레코드가 Sidechain B에서는 [BP1], [BP4] 레코드가 조회됐으며, SQL 레코드가 포크된 것을 확인했습니다.

포크 이후 Sidechain B 컨센서스

포크 이후 SQL 조회결과
  • Sidechain A

  • Sidechain B

Sidechain B 구성 스크립트 실행

포크 이후 네트워크 상태

리오그 Mainchain 구성 시나리오

포크 발생된 Sidechain A와 Sidechain B의 리오그 발생을 위해 네트워크 단절된 BP2, BP3을 네트워크에 재연결 후 BP3을 초기화하여 리오그 발생으로 다시 BP 리스트를 수정했습니다.

Mainchain 구성으로 BP1(500,000 아르고), BP2(300,000 아르고), BP5(400,000 아르고)가 BP 리스트이며 네트워크 연결은 [BP1-BP2-BP3-BP4-BP5]로 이루어졌습니다.

그 후 Mainchain 영역인 BP5에 블록 정보 SQL tx를 호출했습니다.

기존 단계 Sidechain A에서는 [BP1], [BP2] 레코드가 Sidechain B에서는 [BP1], [BP4] 레코드가 조회되었고 [BP5] 레코드가 추가되었습니다.

그 결과 Sidechain A에서는 [BP5] 레코드가 추가된 [BP1], [BP2], [BP5] 레코드와 Sidechain B에서는 [BP4] 레코드 삭제 후 [BP5] 레코드가 추가된 [BP1], [BP2], [BP5] 레코드로 SQL 레코드가 동일한 것을 확인했습니다.

리오그 이후 Mainchain 컨센서스

리오그 이후 SQL 조회결과
  • Sidechain A

  • Sidechain B

리오그 구성 스크립트 실행

리오그 이후 네트워크 상태

결론

아르고 DPoS 내에서 네트워크 단절을 통해 포크 발생시켰고, 각 브랜치 A, B 영역에 다른 데이터를 넣고 다시 하나의 체인으로 통합하면 데이터의 일관성이 유지되었습니다.

결국 아르고 블록체인은 리오그 발생 시 SQL 데이터의 일관성을 지켰고, 데이터베이스 영역에 한 발짝 다가갔습니다.
아르고는 안전성, 성능 개선을 통해 앞으로 블록체인 데이터베이스로써 선두주자가 될 것입니다.

 

블록체인의 변화와 선택
왜 스마트 컨트랙트는 어렵게 개발해야 할까?

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

필수 입력 사항입니다.
필수 입력 사항입니다.
유효한 이메일 주소를 입력해주세요.
You need to agree with the terms to proceed

메뉴