쿼크체인 설명 2부:공유 — 블록 체인의 간략 소개 및 과제

존재하는 확장성 솔루션 안에서, 샤딩은 수평 측정 가능성을 실현하는 가장 채용되고 있는 솔루션입니다. 샤딩의 기본적인 생각은, 글로벌 시스템 상태를 복수의 서브 스테이트, 즉 샤드에 분할하고 각 샤드의 트랜잭션을 비교적 독립해서 처리하는 것입니다. 적절한 샤딩 기술 설계, 시스템의 능력은, 샤딩 및 프로세서(노드)의 수가 증가하면서 증가합니다. 즉, 리니어 스케일입니다.

샤딩를 적용하려면 다음의 2가지 중요한 질문에 답할 필요가 있습니다.

글로벌 시스템 상태는 무엇입니까?또, 시스템 상태를 변경하는 방법은 있습니까?

-예를 들어, 분산 키 값(KV)스토어(BigTable, Cassandra등)에서는, 시스템 상태는 임의의 바이트(키)에서 임의의 바이트(값)맵이며, 시스템을 삭제하는 작업(CRUD)입니다.

-또 하나의 예는, 배포된 추가 전용 파일 시스템(예:Google File System(GFS), Hadoop Distributed File System(HDFS)입니다. 시스템 상태는 디렉토리와 파일의 오픈 리스트이며, 조작은 2개입니다:
모든 조작을 제대로 효율적으로 처리할 수 있도록, 시스템의 상태를 분할하는 방법.시스템 성능에 있어서 파티션 분할은 중요하며, 파티션의 설계가 부적절한 경우는 시스템의 성능이 저하합니다. 파티션을 설계하려면, 몇가지 주요한 측면을 고려해야 합니다.

시스템 상태를 파편으로 분할하여 모든 작업을 올바르고 효율적으로 처리하는 방법은 무엇입니까?

파티션을 분할하는 방법은 시스템 성능에 매우 중요하며, 파티션 설계가 부적절할 경우 시스템 성능이 저하될 수 있습니다. 파티션을 설계하려면 몇가지 주요 측면을 고려해야 합니다.

-분할의 상태:시스템 상태의 어느 부분을 분할합니까. 시스템 모델을 단순화하려면, 시스템 상태의 부분 중 1)1개의 노드에 들어가기에는 너무 큰 사이즈를 갖는 부분만을 떼어 낼지, 2)1초에 고도의 동작이 필요하거나, 시스템 상태의 부분을 충분한 양의 작은 호스트 상태에서 분할하지 않는다. 예를 들어 GFS/HDFS의 초기 버전에서는, 파일 내의 데이터만을 분할화하고있습니다만, 디렉토리의 데이터 사이즈는 비교적 작기 때문(파일 내의 데이터와 비교해서), 디렉토리의 분할화는 가지 않고 있습니다)

-동작(트랜잭션)시멘틱스 확보:시스템 상태를 분할하고 동작 시멘틱스를 채우려면 어떻게 해야 합니까. 1개의 중요한 의미론은 원자력성이다, 어느 운영이 복수의 공유 내의 상태를 원자에 변화시키는 경우, 이런 운영은(예를 들어, 분산 잠금을 통해서)공유 간 적절한 조정을 필요로 하는 비용이 높아질 가능성이 있습니다. 그래서, 이러한 운용의 퍼포먼스는, 테크놀로지의 배제에 의한 이점이 거의 없고 퍼포먼스가 더 나빠질 일도 있습니다. 이런 문제를 회피하기 위해서 대부분의 최근 샤딩 시스템은 1개의 샤딩에서 원자력 배치 동작을 지원하고 복잡한 멀티 점유율 아토믹성 문제를 상위 계층 애플리케이션으로 처리할 수 있도록 합니다.

-균형 잡힌 부하/사이즈:시스템 상태를, a), 모든 공유에 대한 부하가 통계적으로 고루 분산되도록 분할하는 방법, 및 b), 분할된 시스템 상태의 사이즈도 통계적으로 균일하게 모든 공유로 분산하는 방법. 이를 실현하는 것은 선형 스케일의 주요 전제 조건입니다. 부하/사이즈가, 보다 많은 공유를 추가한 뒤에 골고루 분산되는 한, 새로운 공유를 처리하는 노드를 추가, 시스템 용량을 자기 부상으로 늘릴 수 있습니다. 이들의 분포는, 사용자 동작 패턴과 관련성이 높으므로, 사용자 동작 패턴이 시간과 함께 크게 변화하면, 부하가 불균일합니다.(일시적 또는 영구적으로)가능성이 있다는 점에 주의하십시오.
장애성:공유를 추가하는 방법, 및 새로운 노드에서 새로운 공유를 처리하는 방법. 다른 공유를 추가하면, 새로운 공유는 오래 된 공유에서 몇가지의 상태에서 구성됩니다. 이 상태는 새로운 노드로 이행됩니다. 다시 구축 중의 이행에는 시간이 걸리고 기존의 서비스가 일시 정지하는 경우가 있습니다. 또, 지원되는 오퍼레이션의 시멘틱스는 수정전과 수정 후에 동일하게 만들어야 합니다.

쿼크체인에 관한 전술의 질문에 답하기 전에, 우선 시스템 모델로, 기존의 블록 체인 샤딩의 어려움에 대해서 소개하겠습니다.

기존 블록 체인의 시스템 상태 및 트랜잭션

우리는 이더리움과 유사한 계정 기반 블록 체인 모델을 고려합니다. 여기서 시스템 상태는 기본적으로 주소에서 계정 데이터까지의 키 값입니다. 주소에는 두가지 유형이 있습니다.

-사용자 주소
-스마트 계약 주소

계정 데이터는

-균형,
-고지;
-코드;
-보관;

여기서 사용자 주소의 코드와 주소가비어 있습니다.

CRUD작업에는 두가지 유형의 트랜잭션이 지원됩니다.

1. 두 사용자 주소 간의 트랜잭션을 전송합니다. 기본적으로 두 주소의 잔액과 발신인의 부재를 업데이트합니다.

2, 스마트 계약 거래

-보낸 사람의 소음을 업데이트합니다;

-여러 사용자 주소의 잔액을 업데이트합니다.

-잔액 및 위임 통화를 통해 여러 스마트 계약의 잔액 및 보관 상태를 업데이트합니다.

-여러 사용자 주소 및 계정 데이터를 생성합니다.

-여러개의 스마트 계약을 만듭니다.

블록체인 샤딩에서의 기회

기존의 확장성 솔루션과 비교하면, 블록 체인 시스템 상태는 분산형 KV스토어(BigTable과 Cassandra등)과 똑같이 있는 것이 좋은 점입니다.

게다가, 분산화된 세계에서는, 모든 공유 내의 트랜잭션을 안전하게 처리하기 위해서 적절한 합의를 구축할 필요가 있기 위하여 더 많은 과제가 발생합니다. 새로운 샤딩 컨센서스에 의해서, 공격의 새로운 가능성이 열립니다. 그래서, 스레드 모델에 대한 포괄적인 분석을 하지 않더라도, 쉽게 공격 가능성을 배제할 수 있습니다.

분할과 합의에 관한 과제에 넣고, 공유에 관한 좀 1개의 일반적인 문제는 공유 간 상호 운용성입니다. 기초가 되는 원리는 사용성입니다. 스마트한 계약을 포함한 모든 리소스에, 사용자가 효율적으로 접근하는 방법입니다.

이하의 기사에서는, blockchain.com의 과제에 관한 쿼크체인의 솔루션에 대해서 설명하고 쿼크체인을 Google의 BigTable 같은 기존의 집중 관리 시스템과 비교하고, 유사점과 차이점을 설명합니다.