오프체인 데이터로 블록체인 확장

플라톤에 의해 재발행

팔로워 : 0

해시가 백만 단어의 가치가있을 때

지금까지 많은 블록 체인 사용 사례가 금융 거래와 관련이 없음이 분명합니다. 대신, 체인의 목적은 분산 된 집계, 순서, 타임 스탬프 및 보관을 가능하게하는 것입니다. 어떤 구조화 된 데이터, 서신 또는 문서를 포함한 정보 유형. 블록 체인의 핵심 가치는 참여자가 신뢰할 수있는 중개자에 의존하지 않고 언제, 누구에 의해 입력 된 데이터에 정확하게 그리고 영구적으로 합의 할 수있게합니다. 예를 들어, SAP는 최근에 시작 블록 체인 플랫폼, MultiChain 및 Hyperledger Fabric을 지원하는 광범위한 공급망 및 기타 비재무 애플리케이션을 대상으로합니다.

데이터를 기록하기 위해 블록 체인을 사용하는 가장 간단한 방법은 각 데이터 조각을 트랜잭션에 직접 포함시키는 것입니다. 모든 블록 체인 거래는 하나 이상의 당사자에 의해 디지털 서명되고, 모든 노드에 복제되며, 체인의 합의 알고리즘에 의해 주문 및 타임 스탬프되며, 변조 방지 방식으로 영구적으로 저장됩니다. 따라서 트랜잭션 내의 모든 데이터는 누가 언제 작성했는지에 대한 증거와 함께 모든 노드에서 동일하지만 독립적으로 저장됩니다. 체인 사용자는 나중에이 정보를 검색 할 수 있습니다.

예를 들어, MultiChain 1.0을 사용하면 하나 이상의 명명 된 "스트림"을 블록 체인에서 생성 한 다음 원시 데이터를 저장하고 검색하는 데 사용할 수 있습니다. 각 스트림에는 고유 한 쓰기 권한 세트가 있으며 각 노드는 구독 할 스트림을 자유롭게 선택할 수 있습니다. 노드가 스트림을 구독하면 해당 스트림의 내용을 실시간으로 색인화하여 순서, 타임 스탬프, 블록 번호 또는 게시자 주소를 기반으로 항목을 "키"(또는 레이블)를 통해 빠르게 검색 할 수 있습니다. 항목에 태그를 지정할 수 있습니다. MultiChain 2.0 (알파 1 이후) 확장 스트림은 유니 코드 텍스트 또는 JSON 데이터뿐만 아니라 항목 당 여러 키와 트랜잭션 당 여러 항목을 지원합니다. 또한“JSON merge”와 같은 요약 기능을 추가하여 항목을 동일한 키 또는 게시자와 유용한 방식으로 결합합니다.

기밀성과 확장 성

데이터를 블록 체인에 직접 저장하는 것이 잘 작동하지만 기밀성과 확장 성의 두 가지 단점이 있습니다. 기밀성으로 시작하기 위해 모든 스트림 항목의 내용이 체인의 모든 노드에 표시되므로 반드시 바람직한 결과는 아닙니다. 대부분의 경우 순서, 타임 스탬프 및 공증에 도움을주기 위해 다른 노드가 필요한 경우에도 일부 데이터는 노드의 특정 하위 집합에만 표시되어야합니다.

기밀성은 트랜잭션에 포함되기 전에 정보를 암호화하여 해결하기가 비교적 쉬운 문제입니다. 각 데이터 조각의 암호 해독 키는 데이터를 보려는 참가자와 만 공유됩니다. 비대칭 암호화를 사용하여 온 체인으로 키 전달을 수행 할 수 있습니다 ( 여기에 설명되어있다.) 또는 원하는대로 일부 오프 체인 메커니즘을 통해. 항목을 해독 할 키가없는 노드는 이진 횡설수설 만 볼 수 있습니다.

반면에 확장 성은 더 중요한 과제입니다. 적절한 블록 체인 플랫폼은 초당 500 트랜잭션의 네트워크 처리량을 지원해야한다고 가정 해 봅시다. 체인의 목적이 정보 저장소 인 경우 각 트랜잭션의 크기는 주로 포함 된 데이터의 양에 따라 다릅니다. 각 트랜잭션에는 또한 보낸 사람의 주소, 디지털 서명 및 몇 가지 다른 비트와 조각을 저장하기 위해 최소한 100 바이트의 오버 헤드가 필요합니다.

각 항목이 100 바이트의 작은 JSON 구조 인 쉬운 경우를 가정하면 전체 데이터 처리량은 초당 100 킬로바이트 (500 × (100 + 100))로 계산됩니다. 이것은 1 메가 비트 / 초 이하의 대역폭으로 변환되며, 이는 현대 인터넷 연결 용량 내에 편안하게 들어갑니다. 데이터는 연간 약 3 테라 바이트의 속도로 누적되며 이는 적은 양이 아닙니다. 하지만 현재 12 테라 바이트의 하드 드라이브 폭넓게 활용 가능한및 RAID 여러 개의 물리적 드라이브를 하나의 논리적 드라이브로 결합하는 컨트롤러를 사용하면 번거 로움이나 비용없이 모든 노드에 10-20 년의 데이터를 쉽게 저장할 수 있습니다.

그러나 스캔 한 문서와 같은 더 큰 정보를 저장하는 경우 상황이 매우 다르게 보입니다. A4 용지의 합리적인 품질의 JPEG 스캔 크기는 500 킬로바이트입니다. 이 값에 초당 500 개의 트랜잭션을 곱하면 처리량은 250입니다. 메가 바이트 초당. 이것은 2 기가비트 / 초의 대역폭으로 변환되어 인터넷 연결은 물론 대부분의 로컬 네트워크보다 빠릅니다. 아마존 웹 서비스에서 가장 저렴한 공시 가격 기가 바이트 당 0.05 USD의 경우 노드 당 연간 400,000 만 달러의 대역폭 청구를 의미합니다. 그리고 각 노드는 매년 생성되는 8000 테라 바이트의 새로운 데이터를 어디에 저장합니까?

많은 양의 데이터를 저장하는 블록 체인 응용 프로그램의 경우 직접적인 온 체인 스토리지가 실용적인 선택이 아니라는 것이 분명합니다. 부상에 대한 모욕을 더하기 위해 기밀성 문제를 해결하기 위해 데이터를 암호화하는 경우 노드는 읽을 수없는 엄청난 양의 정보를 저장하도록 요청받습니다. 이것은 네트워크 참가자들에게 매력적인 제안이 아닙니다.

해싱 솔루션

그렇다면 데이터 확장 성의 문제를 어떻게 해결할 수 있습니까? 데이터를 체인의 모든 노드에 복제하지 않고 블록 체인의 분산 된 데이터 공증을 어떻게 활용할 수 있습니까?

그 해답은 "해시"라고하는 영리한 기술입니다. 해시는 하나의 데이터를 고유하게 식별하는 긴 숫자 (256 비트 또는 80 진수 XNUMX 정도)입니다. 해시는 데이터를 사용하여 계산합니다. 단방향 기능 중요한 암호화 속성이 있습니다. 데이터가 있으면 해시를 쉽고 빠르게 계산할 수 있습니다. 그러나 특정 해시가 주어지면 해시를 생성하는 데이터 조각을 찾는 것은 계산 상 불가능합니다. 그리고 "계산 불가능"이라고 말할 때, 우리는 알려진 우주에 원자가있는 것보다 더 많은 계산을 의미합니다.

해시는 트랜잭션과 블록을 고유하게 식별하여 모든 블록 체인에서 중요한 역할을합니다. 또한 비트 코인과 같은 작업 증명 시스템의 계산 문제에 기초합니다. BLAKE2, MD5 및 RIPEMD160과 같은 gobbledygook 이름을 사용하여 다양한 해시 함수가 개발되었습니다. 그러나 모든 해시 함수를 신뢰하려면 광범위한 학술 검토 및 테스트를 견뎌야합니다. 이러한 테스트는 "사전 이미지"(주어진 해시로 입력 찾기), "두 번째 사전 이미지"(주어진 입력과 동일한 해시로 두 번째 입력 찾기) 및 "충돌"(예 : 해시가 동일한 두 개의 다른 입력). 이 결투에서 살아남는 것은 쉬운 일이 아닙니다. 길고 비극적 인 해시 함수의 역사는 유명한 최대 값을 증명합니다.“자신의 암호를 굴리지 마십시오.”

원래 문제로 돌아가려면 데이터 자체 대신 트랜잭션 내에 큰 데이터 조각의 해시를 포함시켜 블록 체인의 데이터 확장 성을 해결할 수 있습니다. 각 해시는 입력 데이터에 대한“약속”역할을하며 데이터 자체는 블록 체인 또는“오프 체인”외부에 저장됩니다. 예를 들어, 널리 사용되는 SHA256 해시 함수를 사용하면 500KB JPEG 이미지를 32 바이트 숫자로 표현할 수있어 15,000 배 이상 줄어 듭니다. 초당 500 개의 이미지 속도로도 체인 자체에 저장된 데이터 측면에서 실현 가능한 대역폭 및 스토리지 요구 사항의 영역으로 편안하게 돌아갑니다.

물론, 오프 체인 이미지가 필요한 블록 체인 참가자는 해시에서이를 재생할 수 없습니다. 그러나 이미지를 다른 방식으로 검색 할 수 있으면 온 체인 해시가 이미지를 만든 사람과시기를 확인하는 역할을합니다. 일반 온 체인 데이터와 마찬가지로 해시는 디지털 서명 된 트랜잭션에 포함되며 합의에 의해 체인에 포함됩니다. 이미지 파일이 하늘에서 떨어지고 해당 이미지의 해시가 블록 체인의 해시와 일치하면 해당 이미지의 원본과 타임 스탬프가 확인됩니다. 따라서 블록 체인은 이미지가 체인에 직접 포함 된 것처럼 공증 측면에서 정확히 동일한 값을 제공합니다.

배달 문제

여태까지는 그런대로 잘됐다. 원본 데이터 대신 블록 체인에 해시를 포함시킴으로써 확장 성 문제를 쉽게 해결할 수 있습니다. 그럼에도 불구하고 한 가지 중요한 질문이 남아 있습니다.

체인 자체를 통하지 않고 원본 오프 체인 컨텐츠를 필요한 노드에 어떻게 제공합니까?

이 질문에는 몇 가지 가능한 답변이 있으며 MultiChain 사용자가 모두 적용한다는 것을 알고 있습니다. 기본적인 접근 방법 중 하나는 신뢰할 수있는 당사자에게 중앙 저장소를 설정하는 것입니다. 여기서 모든 오프 체인 데이터를 업로드 한 다음 검색합니다. 이 시스템은 자연스럽게 "콘텐츠 주소 지정"을 사용할 수 있습니다. 즉, 각 데이터 조각의 해시가 검색을위한 식별자 역할을 직접 수행합니다. 그러나이 설정은 개념 증명에 효과적 일 수 있지만 블록 체인의 핵심은 신뢰할 수있는 중개자를 제거하는 것이므로 프로덕션에는 적합하지 않습니다. 온 체인 해시로 인해 중개자가 데이터를 위조하는 것을 막을 수는 있지만 기술적 오류나 악의적 인 직원의 행동으로 인해 데이터를 삭제하거나 일부 참가자에게 전달하지 못할 수도 있습니다.

보다 유망한 가능성은 지점 간 통신으로, 일부 오프 체인 데이터가 필요한 노드는 데이터를 게시 한 노드에서 직접 요청합니다. 이렇게하면 신뢰할 수있는 중개자에 의존하지 않아도되지만 다음과 같은 세 가지 단점이 있습니다.

일부 데이터 소비자가 게시자와 직접 통신 할 수 있으려면 블록 체인 주소를 IP 주소로 매핑해야합니다. 블록 체인은 일반적으로 이러한 유형의 정적 네트워크 구성을 피할 수 있으며 이는 장애 조치 및 개인 정보 보호 측면에서 문제가 될 수 있습니다.
원래 게시자 노드가 네트워크를 떠나거나 일시적으로 서비스가 중단 된 경우 다른 사람이 데이터를 검색 할 수 없습니다.
많은 수의 노드가 일부 데이터에 관심이있는 경우 게시자는 요청에 압도 될 것입니다. 이로 인해 심각한 네트워크 정체가 발생하고 게시자의 시스템 속도가 느려질 수 있으며 해당 데이터를 검색하려는 사람들이 오랜 시간 지연 될 수 있습니다.

이러한 문제를 피하기 위해 분산 된 전달 메커니즘을 사용하는 것이 이상적입니다. 노드는 개별 시스템에 의존하지 않고도 필요한 데이터를 검색 할 수 있어야합니다 (중앙 저장소 또는 데이터의 원본 게시자). 여러 당사자가 데이터를 가지고있는 경우, 원하는 다른 사람에게 데이터를 제공해야하는 부담을 공유해야합니다. 온 체인 해시는 데이터가 변경되지 않았 음을 증명할 수 있기 때문에 개별 데이터 소스를 신뢰할 필요가 없습니다. 악의적 인 노드가 해시에 대해 잘못된 데이터를 제공하면 해당 데이터를 버리고 다른 사람에게 물어볼 수 있습니다.

경험이있는 사람들을 위해 피어 투 피어 파일 공유 Napster, Gnutella 또는 BitTorrent와 같은 프로토콜은 모두 매우 친숙하게 들릴 것입니다. 실제로 많은 기본 원칙이 동일하지만 두 가지 주요 차이점이 있습니다. 먼저, 엔터프라이즈 컨텍스트에서 블록 체인을 사용한다고 가정하면 시스템은 인터넷 전체가 아닌 비공개 참가자 그룹 내에서 실행됩니다. 둘째, 블록 체인은 분산 형 순서, 타임 스탬프 및 공증 백본을 추가하여 모든 사용자가 언제, 누구에게 무슨 일이 일어 났는지 정확하게 일관되고 변조 방지보기를 유지할 수 있도록합니다.

블록 체인 응용 프로그램 개발자는 이러한 분산 된 오프 체인 콘텐츠 전달을 어떻게 달성 할 수 있습니까? 한 가지 일반적인 선택은 기존의 PXNUMXP 파일 공유 플랫폼을 사용하는 것입니다. 행성 간 파일 시스템 (IPFS)를 블록 체인과 함께 사용하십시오. 각 참가자는 블록 체인 노드와 IPFS 노드를 모두 실행하며 둘 사이에 미들웨어가 조정됩니다. 오프 체인 데이터를 게시 할 때이 미들웨어는 원래 데이터를 IPFS에 저장 한 다음 해당 데이터의 해시를 포함하는 블록 체인 트랜잭션을 작성합니다. 일부 오프 체인 데이터를 검색하기 위해 미들웨어는 블록 체인에서 해시를 추출한 다음이 해시를 사용하여 IPFS에서 컨텐츠를 가져옵니다. 로컬 IPFS 노드는 검색되지 않은 컨텐츠를 해시에 대해 자동으로 검증하여 변경되지 않았는지 확인합니다.

이 솔루션은 가능하지만 다소 어색하고 불편합니다. 첫째, 모든 참가자는 데이터를 별도의 장소에 저장하는 세 가지 소프트웨어 (블록 체인 노드, IPFS 노드 및 미들웨어)를 설치, 유지 관리 및 업데이트해야합니다. 둘째, 각각 고유 한 구성, 네트워크 포트, ID 시스템 및 권한을 가진 두 개의 개별 피어 투 피어 네트워크가 있습니다 (IPFS는 아직 닫힌 네트워크를 지원하지는 않습니다). 마지막으로 IPFS와 블록 체인을 긴밀하게 연결하면 미들웨어가 점점 더 복잡해집니다. 예를 들어, 자동 재 시도를 통해 일부 블록 체인 트랜잭션에서 참조하는 오프 체인 데이터를 즉시 검색하려면 미들웨어가 자체적으로 복잡한 상태를 유지하면서 지속적으로 실행해야합니다. 블록 체인 노드 가이 모든 것을 우리에게 해주면 좋지 않을까요?

MultiChain 2.0의 오프 체인 데이터

오늘 우리는 출시를 기쁘게 생각합니다 세 번째 미리보기 버전 오프 체인 데이터를위한 완벽하게 통합 된 완벽한 솔루션을 갖춘 MultiChain 3의 알파 2.0 스트림에 게시 된 모든 정보는 원하는대로 온 체인 또는 오프 체인 일 수 있으며 MultiChain은 다른 모든 것을 처리합니다.

아니, 우리는 의미 모두. MultiChain을 기반으로하는 개발자는 해시, 로컬 스토리지, 컨텐츠 검색, 분산 전송 또는 데이터 확인에 대해 걱정할 필요가 없습니다. 뒤에서 일어나는 일은 다음과 같습니다.

게시 MultiChain 노드는 로컬 스토리지에 새 데이터를 작성하여 큰 항목을 청크로 분할하여 쉽게 소화하고 전달할 수 있습니다.
오프 체인 스트림 항목을 게시하기위한 트랜잭션은 청크 해시 및 크기 (바이트)를 포함하여 자동으로 빌드됩니다.
이 트랜잭션은 서명되고 네트워크에 브로드 캐스트되어 일반적인 방식으로 노드간에 전파되고 블록 체인에 들어갑니다.
스트림을 구독 한 노드가 일부 오프 체인 데이터에 대한 참조를 볼 때 해당 데이터의 청크 해시를 검색 큐에 추가합니다. (이전 스트림을 구독 할 때 노드는 검색을 위해 이전에 게시 된 오프 체인 항목도 대기열에 넣습니다.)
백그라운드 프로세스로서, 노드의 검색 큐에 청크가 있으면 해시로 식별 된 해당 청크를 찾기 위해 쿼리가 네트워크로 전송됩니다.
이러한 청크 쿼리는 피어 투 피어 방식으로 네트워크의 다른 노드로 전파됩니다 (현재 XNUMX 개의 홉으로 제한됨 – 아래 기술 세부 정보 참조).
청크에 대한 데이터가있는 모든 노드가 응답 할 수 있으며이 응답은 쿼리와 동일한 경로를 따라 가입자에게 다시 중계됩니다.
청크 쿼리에 응답하는 노드가 없으면 나중에 다시 시도하기 위해 청크가 큐로 다시 반환됩니다.
그렇지 않으면 가입자는 홉 및 응답 시간을 기준으로 청크에 대해 가장 유망한 소스를 선택하고 이전 응답과 동일한 피어 투 피어 경로를 따라 해당 청크 데이터에 대한 요청을 보냅니다.
소스 노드는 동일한 경로를 다시 사용하여 요청 된 데이터를 전달합니다.
가입자는 원래 요청에 대해 데이터의 크기와 해시를 확인합니다.
모든 것이 체크 아웃되면 가입자는 데이터를 로컬 스토리지에 기록하여 스트림 API를 통해 즉시 검색 할 수 있습니다.
요청 된 컨텐츠가 도착하지 않았거나 원하는 해시 또는 크기와 일치하지 않으면 청크는 나중에 다른 소스에서 검색 할 수 있도록 큐로 다시 리턴됩니다.

가장 중요한 것은이 모든 것이 매우 빠르게 일어난다는 것입니다. 지연 시간이 짧은 네트워크에서는 소규모 오프 체인 데이터가이를 참조하는 트랜잭션의 2.0 초 내에 가입자에게 도착합니다. 또한로드가 많은 애플리케이션의 경우 MultiChain 3 alpha 1000는 중간 범위의 서버 (Core i25)에서 7 개 이상의 오프 체인 아이템 또는 초당 1MB의 오프 체인 데이터를 검색 할 수있는 것으로 나타났습니다. 인터넷 연결. 온 체인 데이터의 64MB 제한을 훨씬 초과하는 최대 2.0GB 크기의 오프 체인 항목에서 모든 것이 잘 작동합니다. 물론 베타 단계에서 MultiChain XNUMX을 최적화하는 데 시간을 할애하여 이러한 수치를 더욱 향상시킬 수 있기를 바랍니다.

스트림에서 온 체인 데이터가 아닌 오프 체인 데이터를 사용할 때 MultiChain 응용 프로그램 개발자는 정확히 두 가지 작업을 수행해야합니다.

데이터를 게시 할 때 "offchain"플래그를 해당 API에 전달하십시오.
스트림 쿼리 API를 사용하는 경우 "available"플래그로보고 된대로 일부 오프 체인 데이터를 아직 사용할 수 없을 가능성을 고려하십시오. 이러한 상황은 일반적인 상황에서는 드물지만 응용 프로그램 개발자가 적절하게 처리하는 것이 중요합니다.

물론, 모든 노드가 모든 오프 체인 아이템을 검색하는 것을 방지하기 위해, 아이템은 적절한 방식으로 스트림으로 그룹화되어야하며, 각 노드는 해당 스트림에 가입해야합니다.

온 체인 및 오프 체인 항목은 동일한 스트림 내에서 사용될 수 있으며 다양한 스트림 쿼리 및 요약 기능은 두 유형의 데이터와 동일하게 관련됩니다. 이를 통해 게시자는 나머지 응용 프로그램에 영향을주지 않고 스트림의 모든 항목에 대해 적절한 선택을 할 수 있습니다. 예를 들어, 사람들의 활동에 관한 JSON 항목 스트림은 개인 식별 정보를 위해 오프 체인 데이터를 사용하고 나머지는 온 체인 데이터를 사용할 수 있습니다. 가입자는 MultiChain의 JSON 병합을 사용하여 두 유형의 정보를 단일 JSON으로 결합하여 읽을 수 있습니다.

오프 체인 스트림 아이템을 시험 해보고 싶다면 MultiChain의 레귤러를 따르십시오. 시작 가이드 튜토리얼을 읽고 섹션 5를 건너 뛰지 마십시오.

그럼 다음은 뭐니?

오프 체인 데이터에 대한 완벽한 지원을 통해 MultiChain 2.0은 대규모 데이터 타임 스탬프 및 공증에 중점을 둔 블록 체인 애플리케이션을위한 큰 발전을 제공합니다. 장기적으로, 우리는 이미 MultiChain의 Community 및 / 또는 Enterprise 에디션을 위해이 기능에 대해 향후 개선 될 수있는 기능에 대해 이미 생각하고 있습니다.

스트림 구현 읽기 오프 체인 항목, 솔트 해시, 서명 된 청크 쿼리 및 암호화 된 배달의 조합을 사용하는 권한
오프 체인 데이터가 개별 노드에 의해 또는 온 체인 메시지에 대한 응답으로 모든 노드에 의해 명시 적으로 "잊혀 질"수 있습니다.
선택적 스트림 구독. 여기서 노드는 특정 게시자 또는 키가있는 오프 체인 항목의 데이터 만 검색합니다.
사용 병합 나무 단일 온 체인 해시가 무제한의 오프 체인 항목을 나타낼 수 있도록하여 확장 성 측면에서 또 다른 큰 도약을 제공합니다.
플러그 가능한 스토리지 엔진으로 오프 체인 데이터를 로컬 디스크가 아닌 데이터베이스 또는 외부 파일 시스템에 보관할 수 있습니다.
시간이 지남에 따라 각 유형의 오프 체인 데이터가 일반적으로 네트워크에서 제공되고 청크 쿼리에 적절히 초점을 맞추는 노드.

우리는 당신의 의견을 들으십시오 위의 목록뿐만 아니라 일반적으로 오프 체인 항목에. MultiChain 2.0은 공식적으로 알파 버전이므로 최종 출시 전에이 기능을 향상시킬 시간이 충분합니다.

한편, 우리는 이미 MultiChain 2.0 Community에 대해 계획된 마지막 주요 기능인 "Smart Filters"에 대한 작업을 시작했습니다. 스마트 필터는 블록 체인에 포함 된 코드로 데이터 또는 트랜잭션의 유효성을 검사하기위한 사용자 지정 규칙을 구현합니다. 스마트 필터는 "스마트 계약"과 유사한 점이 있으며 동일한 작업을 많이 수행 할 수 있지만 안전성과 성능 측면에서 중요한 차이점이 있습니다. 우리는 적시에 더 많은 것을 알려 드리기를 기대합니다.

의견을 적어주세요 링크드 인에.

기술적 세부 사항

MultiChain 2.0의 오프 체인 스트림 항목은 사용하기 쉽지만 많은 디자인 결정과 관심있는 추가 기능이 포함되어 있습니다. 아래 목록은 주로 블록 체인 응용 프로그램을 작성하는 개발자와 관련이 있으며 덜 기술적 인 유형으로 건너 뛸 수 있습니다.

스트림 별 정책. 멀티 체인 스트림이 생성되면 선택적으로 온 체인 또는 오프 체인 데이터 만 허용하도록 제한 할 수 있습니다. 각 게시자가 스스로 결정할 수 있도록 허용하는 대신 몇 가지 가능한 이유가 있습니다. 예를 들어 온 체인 품목은 강력한 가용성을 보장하는 반면, 기존의 오프 체인 품목은 게시자와 다른 가입자가 네트워크를 끊으면 검색 할 수 없게됩니다. 반면에, 온 체인 아이템은 블록 체인을 수정하지 않고는“잊어 버릴”수 없지만 오프 체인 아이템은 더 유연합니다. 이는 유럽의 새로운 GDPR 규정과 같은 데이터 개인 정보 보호 규칙 측면에서 중요 할 수 있습니다.
온 체인 메타 데이터. 오프 체인 품목의 경우, 온 체인 거래에는 여전히 품목의 발행인, 키, 형식 (JSON, 텍스트 또는 이진) 및 총 크기가 포함됩니다. 이 모든 작업은 공간을 거의 차지하지 않으며 응용 프로그램 개발자가 오프 스트림 항목을 사용할 수없는 것이 특정 스트림 쿼리와 관련이 있는지 판단하는 데 도움이됩니다.
XNUMX 홉 제한. 피어 투 피어 네트워크를 통해 청크 쿼리를 릴레이 할 때 도달 가능성과 성능간에 균형이 있습니다. 모든 쿼리가 모든 단일 경로를 따라 전파되는 것이 좋지만 불필요한 "채터"로 네트워크를 방해 할 수 있습니다. 따라서 현재 청크 쿼리는 두 개의 홉으로 제한됩니다. 즉, 노드는 피어의 모든 피어에서 오프 체인 데이터를 검색 할 수 있습니다. 엔터프라이즈 블록 체인을 특징 짓는 경향이있는 1000 개 미만의 노드로 구성된 소규모 네트워크에서는 이것이 잘 작동 할 것이라고 생각하지만, 잘못된 것으로 판명되면이 제약 조건을 조정하거나 매개 변수로 제공하는 것이 쉽습니다.
로컬 스토리지. 각 멀티 체인 노드는 효율적인 이진 형식과 LevelDB 인덱스를 사용하여 일반 블록 체인 디렉토리의 "청크"디렉토리에 오프 체인 데이터를 저장합니다. 각 구독 스트림의 항목과 노드 자체가 게시 한 항목에 별도의 하위 디렉토리가 사용됩니다. 각 하위 디렉토리 내에서 중복 청크 (같은 해시 포함)는 한 번만 저장됩니다. 노드가 스트림에서 구독을 취소하면 해당 스트림에 대해 검색된 오프 체인 데이터를 제거할지 여부를 선택할 수 있습니다.
이진 캐시. 온 체인이든 오프 체인이든 이진 데이터의 큰 조각을 게시 할 때 응용 프로그램 개발자는 단일 JSON-RPC 요청으로 해당 데이터를 MultiChain의 API로 보내는 것이 실용적이지 않을 수 있습니다. 따라서 MultiChain 2.0은 이진 캐시를 구현하여 여러 API 호출을 통해 많은 양의 데이터를 구축 한 다음 간단한 최종 단계로 게시 할 수 있습니다. 이진 캐시의 각 항목은 블록 체인 디렉토리의 "캐시"하위 디렉토리에 간단한 파일로 저장되므로 파일 시스템을 통해 기가 바이트의 데이터를 직접 푸시 할 수도 있습니다.
모니터링 API. MultiChain 2.0 alpha 3에는 오프 체인 데이터의 비동기 검색을 모니터링하기위한 두 개의 새로운 API가 추가되었습니다. 첫 번째 API는 큐의 현재 상태를 설명하여 대기 또는 쿼리 또는 검색중인 청크 수 (및 데이터 수)를 보여줍니다. 두 번째 API는 다양한 유형의 실패 수를 포함하여 노드 시작 이후 전송 된 모든 청크 쿼리 및 요청에 대한 집계 통계를 제공합니다.
게시시 플러시 오프 체인 항목을 게시 할 때 MultiChain은 데이터를 참조하는 트랜잭션이 네트워크로 브로드 캐스트됨을 참조하는 트랜잭션 전에 로컬 데이터 복사본이 실제 디스크 드라이브에 완전히 기록 (또는 "플러시")되도록합니다. 그렇지 않으면, 노드가 트랜잭션을 브로드 캐스트 한 후 즉시 전원을 잃을만큼 운이 좋지 않으면 오프 체인 데이터가 영구적으로 손실 될 수 있습니다. 청크 검색 시도 사이의 지연이 시간이 지남에 따라 자동으로 증가하기 때문에 이는 멀티 체인 자체에는 문제가되지 않습니다. 그러나 응용 프로그램 수준에서 문제가 발생할 수 있습니다. 응용 프로그램 수준에서는 모든 사람이 일부 데이터의 존재를 알고 있지만 아무도 그것을 찾을 수 없습니다.
퍼블리싱 퍼포먼스. 이러한 방식으로 오프 체인 데이터를 디스크로 플러시함으로써 MultiChain은 물리적 디스크가 느리기 때문에 성능 저하를 초래할 수 있습니다. 예를 들어, 중간 범위의 7200rpm 하드 드라이브는 초당 약 100 개의 무작위 데이터 쓰기 만 수행 할 수 있으며 개별 노드가 오프 체인 항목을 게시 할 수있는 속도를 제한합니다. 이 문제에 대한 세 가지 가능한 해결 방법이 있습니다. 가장 간단한 방법으로, 노드는 초당 10,000 개의 랜덤 쓰기 작업을 지원하는 일반 하드 드라이브 대신 SSD (Solid State Device) 드라이브를 사용할 수 있습니다. 둘째,“createrawsendfrom”API를 사용하여 여러 개의 비 사슬 품목을 단일 트랜잭션으로 게시 할 수 있습니다. 이 경우 MultiChain은 단일 디스크 작업으로 트랜잭션이 참조하는 모든 오프 체인 데이터를 씁니다. 마지막으로, 멀티 체인은이를 참조하는 트랜잭션을 브로드 캐스트하기 전에 오프 체인 데이터를 디스크로 플러시하지 않도록 구성 할 수 있습니다. 이 옵션은주의해서 사용하십시오.
기본 통화 통합. 이를 필요로하는 사용 사례의 경우, 멀티 체인은 항상 거래 스팸을 방지하고 블록 유효성 검사기 ( "광부")를 장려하기 위해 블록 체인에서 기본 통화를 사용하는 옵션을 제공했습니다. 이 경우, 거래는 체인에서 중계되고 확인되기 위해 채굴 자에게 바이트 단위의 크기에 비례하는 최소 수수료를 제공해야합니다. 이 메커니즘은 트랜잭션에서 참조되는 오프 체인 데이터의 킬로바이트 당 최소 추가 요금을 요구하여 오프 체인 스팸을 방지 할 수 있도록 확장되었습니다.
아카이브 노드. 노드가 모든 스트림을 구독하여 게시 된 모든 오프 체인 항목을 검색 및 저장하려는 경우 "autosubscribe"런타임 매개 변수를 사용하여 구성 할 수 있습니다. 이러한 노드는 전체 네트워크의 백업 역할을하여 다른 노드가 사라지더라도 오프 체인 항목을 잃어 버리거나 사용할 수 없도록합니다. 이를 상업적 서비스로 제공하는 타사 회사를 상상할 수 있습니다.