Define paust-db fault

[kwjooo]

Define paust-db fault

Problem

• tendermint의 consensus는 validator 수가 많아짐에 따라 latency가 증가함. 반대로 validator수가 적어짐에 따라 security는 취약해짐.

Purpose

• decentralized-store에 적합한 consensus를 고안하는 것

Derive

• decentralized 상황에서 가장 중요한 특성은 데이터 무결성
• paust-db data 무결성에 영향을 주는 fault가 무엇인 지를 정리하고자 함.
• fault는 client입장에서의 fault와 clustering 입장에서의 fault로 나누어 정리.

Due date

• 4/11

[kwjooo]

client입장에서의 fault

client 입장에서의 fault는 서버의 오작동을 의미함

1. tx가 put이 되지 않음(network 문제, byzantin node가 tx처리하지 않는경우)
2. tx가 put이 되었다고 response가 왔으나 query로 조회가 불가능함(byzantine node가 tx를 위변조하는 경우)
3. 잘못된 query response(ex.단일 node query 시 byzantine node에 의해 잘못된 response를 받는 경우, 부분 state에서 query response를 받는 경우)

Node입장에서의 fault

node 입장에서의 fault는 client 혹은 peer node의 오작동을 의미 함.

1. invalid transaction이 전파된 경우(client에서 invalid한 transaction이 오는 경우 혹은 byzantine node가 invalid한 transaction을 전파하는 경우)
2. 전체 state를 찾을 수 없는 경우
3. 통신할 peer가 없는 경우
4. 전체 state가 하나가 아닌 경우

[elon0823]

• tendermint 의 pbft 기반의 consensus 가 왜 paust-db 의 consensus 와 맞지 않는지에 대한 것 부터 나열해보세요. 단지 validator 의 수 때문에 우리의 구조와 맞지 않는걸까요?

• 기존의 DB 관점에서 접근하는게 좋을듯합니다. cockroach db 나 zookeeper 같은 분산 환경의 노드들에 대한 데이터 동기화, 무결성, 일관성을 어떻게 보장하는지 보고 가져와서 엔드류의 base 에 합쳐서 구현해보는것부터 해봐요. 저런 시스템은 fault 를 어떻게정의하는지도 보고요 (대부분 connection 이 끊어지거나 timeout 에 대해서만 정의되있지않을까합니다.) 물론 테스트할땐 엔드류가 관리하는 분산 노드일거니 malicious 한 action 을 하지않지만 실 환경은(탈중앙화) 신뢰할수 없는 노드들간 연결이 되겠죠. 그럼 저정도의 분산환경상의 fault 만 가져가면 분명 문제가 생길탠데 어떻게 해결할 수 있을까? 어떤문제들이 생길까? 같은 질문들을 던지며 실험해보세요. 100프로 무결성은 보장할 수 없을태니 pbft 처럼 1/3 미만만 정상동작하면 무결성을 보장할 수 있다 같은 rule base 를 설계해볼 수 있지 않을까합니다.

[1dennispark]

@elon0823 의 말에 덧붙이자면 사용자가 타임시리즈 디비에서 fault를 받는 시나리오가 무엇이 있는지 고민하고 어떻게 해결하면 좋을지 생각해보는 것에서 시작해야할것같아요.

예를 들어, 처음에 제시한 tendermint의 consensus에서 validator node가 증가함에 따라 latency가 늘어난다고 했는데 그건 어떤 blockchain 이든 full-copy를 기준으로 생각한다면 전부 다 똑같이 latency가 늘어납니다.

오히려 데이터는 중복되어 처리성능을 높이되 모든 노드가 중복되지 않아도 되는 consensus를 생각한다면 tendermint의 consensus 알고리즘에서 조금만 변형을 일으켜도 가능하지 않을까 싶습니다.

그런데 어떤 transaction을 공유해야하고 하지 말아야하는지는 elon이 말했던 것과 같이 룰베이스로 처리할 수 밖에 없습니다.

cockroach db나 google global cache 서버 같이 사용자의 입력에 따라 데이터가 자연스럽게 balance를 갖을 수도 있고 zookeeper와 같이 공평한 관계에서 물리적으로 (수동) master를 바꿀 수 있도록 해도 됩니다.

어쨋든 기존의 discovery 알고리즘들에서 우리 니즈에 맞게 어떻게 변형시킬 것인지 생각해야합니다. 오히려 tendermint나 zookeeper 와 같은 라이브러리를 구현한다와 같은 방식보다는 그 근본을 더 알아야할 필요가 있습니다.

[elon0823]

@co1god 노드는 full copy 하지 않고 부분적으로 copy를 한 상태로 consensus 가 이루어지는 네트워크를 생각하면서 설계를 해보면 되겠네요. 그러려면 기존의 pbft 기반의 블록을 쌓는데만 사용하는 것 뿐만 아니라 query 요청에 대해서도 합의하는 과정이 필요하겠죠?

[kwjooo]

https://github.com/paust-team/paust-db/issues/163#issuecomment-481974340 대부분의 blockchain consensus는 모든 node가 같은 state를 유지하기 위해 같은 message(block)을 전파받기 위함에 목적이 있습니다. tendermint는 모든 node가 같은 block을 전파받은 후 다 저장합니다. 전체 copy는 어떤 node에 요청을 하던 같은 query response를 바로 얻을 수 있다는 장점이 있습니다. 하지만 단일 node에만 query를 하지 않고 전체 state에 대한 response를 할 수 있는 logic이 있다면 full-copy에 비해 response 속도는 느릴 수 있으나 full-copy를 하지 않아도 됩니다.

[kwjooo]

@co1god 어떤 transaction을 공유하고 하지 말아야 할지에 대한 rule이 있다는 건 network의 모든 node가 같은 message를 받지 않아도 된다고 이해했는데, 이럴 경우 data integrity를 유지하기 어렵지 않을까요? 악의적인 node가 다른 message를 peer에 전달할 경우 정상적인 node입장에서 어떤 message가 올바른 데이터인 지 파악하기 힘들 것 같습니다