NEAR Teknik Raporu

저자 Alex Skidanov and Illia Polosukhin · 2019

🇺🇸 English (원문)

🇹🇷 Türkçe (번역)

샤딩 기본 사항

샤딩에 대한 가장 간단한 접근 방식부터 시작해 보겠습니다. 이 접근 방식에서는 대신 하나의 blockchain을 실행하면 여러 개를 실행하고 각각의 blockchain을 호출합니다. "샤드". 각 샤드에는 자체 validator 세트가 있습니다. 여기와 아래에서 우리는 거래를 확인하는 참가자를 지칭하는 일반적인 용어 "validator" 작업 증명과 같은 채굴이나 투표 기반을 통해 블록을 생성합니다. 1이 섹션은 이전에 https://near.ai/shard1.에 게시되었습니다. 이전에 읽으셨다면, 다음 섹션으로 건너뛰세요.

기구. 지금은 샤드가 서로 통신하지 않는다고 가정해 보겠습니다. 기타. 이 디자인은 간단하지만 샤딩의 몇 가지 초기 주요 과제를 설명하는 데 충분합니다. 1.1 검증인 파티셔닝 및 비콘 체인 시스템이 10개의 샤드로 구성되어 있다고 가정해 보겠습니다. 첫 번째 과제는 각각의 샤드에 자체 validator이 있으므로 각 샤드는 이제 샤드보다 10배 덜 안전합니다. 전체 체인. 따라서 X validators가 포함된 비샤딩 체인이 하드포크를 결정하면 샤딩된 체인으로 X validators를 10개의 샤드로 분할합니다. 이제 각 샤드는 X/10 validators만 있고, 샤드 하나를 손상시키려면 손상만 필요합니다. 총 validator 수의 5.1%(51% / 10)(그림 1 참조), 그림 1: validator을 여러 샤드로 분할 두 번째 요점은 누가 각 샤드에 대해 validator을 선택합니까? validator의 5.1%를 통제하는 것은 validator의 5.1%가 모두 손상되는 경우에만 해를 끼칩니다. 같은 샤드에 있습니다. validators가 검증할 샤드를 선택할 수 없는 경우 에서 validator의 5.1%를 제어하는 참가자는 모든 것을 얻을 가능성이 거의 없습니다. validator이(가) 동일한 샤드에 저장되어 손상 가능성이 크게 감소합니다. 시스템. 오늘날 거의 모든 샤딩 디자인은 무작위성의 소스에 의존합니다. validators를 샤드에 할당합니다. blockchain의 무작위성 자체는 매우 어려운 주제이며 이 문서의 범위를 벗어납니다. 지금은 우리가 사용할 수 있는 임의성의 소스입니다. 우리는 validator의 과제를 다음에서 다룰 것입니다. 자세한 내용은 섹션 2.1에서 확인하세요. 무작위성과 validator 할당 모두 계산이 필요하지 않습니다. 특정 샤드에만 적용됩니다. 해당 계산을 위해 기존의 거의 모든 디자인에는 작업 수행을 담당하는 별도의 blockchain이 있습니다. 전체 네트워크의 유지 관리에 필요합니다. 무작위로 생성하는 것 외에도번호를 지정하고 샤드에 validator을 할당하는 경우 이러한 작업은 종종 샤드에서 업데이트를 수신하고 스냅샷을 찍고 처리하는 것을 포함합니다. 지분 증명 시스템의 지분 및 삭감, 그리고 그 경우 샤드의 균형을 재조정합니다. 기능이 지원됩니다. 이러한 체인을 Ethereum에서는 릴레이 체인(Beacon Chain)이라고 합니다. PolkaDot의 체인, Cosmos의 Cosmos 허브. 이 문서 전체에서 우리는 이러한 체인을 비콘 체인(Beacon chain)이라고 부를 것입니다. 비콘 체인의 존재는 우리에게 다음 흥미로운 주제인 2차 샤딩. 1.2 2차 샤딩 샤딩은 종종 숫자에 따라 무한정 확장되는 솔루션으로 광고됩니다. 네트워크 운영에 참여하는 노드의 수입니다. 이론적으로는 가능하지만 이러한 샤딩 솔루션, 비콘 개념이 있는 모든 솔루션을 설계합니다. 체인에는 무한한 확장성이 없습니다. 이유를 이해하려면 Beacon을 참고하세요. 체인은 validators 할당과 같은 일부 장부 계산을 수행해야 합니다. 개수에 비례하는 샤드 또는 샤드 체인 블록의 스냅샷 생성 시스템의 샤드 수. 비콘 체인 자체는 단일 blockchain이므로 그것을 운영하는 노드의 계산 능력에 의해 제한된 계산, 샤드의 수는 당연히 제한되어 있습니다. 그러나 샤딩된 네트워크의 구조는 곱셈을 제공합니다. 노드 개선에 영향을 미칩니다. 임의의 경우를 고려하십시오. 네트워크의 노드 효율성이 향상되어 다음을 허용합니다. 거래 처리 시간이 더 빨라집니다. 비콘체인의 노드를 포함하여 네트워크를 운영하는 노드의 경우, 4배 더 빨라지면 각 샤드는 4배 더 많은 작업을 처리할 수 있습니다. 비콘 체인은 4배 더 많은 샤드를 유지할 수 있게 됩니다. 시스템 전체의 처리량은 4 × 4 = 16배로 증가합니다. 따라서 2차 샤딩이라는 이름이 붙었습니다. 샤드 개수를 정확하게 측정하기는 어렵습니다. 현재는 실행 가능하지만 가까운 미래에는 처리량이 증가할 가능성이 낮습니다. blockchain 사용자의 요구 사항은 2차 샤딩의 한계를 넘어설 것입니다. 이러한 대량의 샤드를 안전하게 운영하는 데 필요한 엄청난 수의 노드 모든 노드를 운영하는 노드 수보다 훨씬 더 많을 가능성이 높습니다. blockchain이 오늘 결합되었습니다. 1.3 상태 샤딩 지금까지 우리는 정확히 무엇이 분리되어 있지 않은지 잘 정의하지 못했습니다. 네트워크가 샤드로 분할될 때. 특히 blockchain의 노드 세 가지 중요한 작업을 수행합니다. 1) 트랜잭션을 처리할 뿐만 아니라 또한 2) 검증된 트랜잭션과 완료된 블록을 다른 노드에 전달하고 3) 전체 네트워크 원장의 상태와 기록을 저장합니다. 이 세 가지 각각 작업은 네트워크를 운영하는 노드에 점점 더 많은 요구 사항을 부과합니다.1. 거래를 처리하려면 더 많은 컴퓨팅 성능이 필요합니다. 처리되는 거래 수가 증가합니다. 2. 트랜잭션 및 블록을 중계해야 할 필요성으로 인해 중계되는 트랜잭션 수가 증가함에 따라 더 많은 네트워크 대역폭이 필요합니다. 3. 데이터를 저장해야 하는 필요성은 상태가 성장함에 따라 더 많은 저장 공간을 필요로 합니다. 중요한 것은 처리 능력 및 네트워크와 달리 트랜잭션 속도(처리된 트랜잭션 수)가 증가하더라도 스토리지 요구 사항이 증가한다는 것입니다. 초당)은 일정하게 유지됩니다. 위 목록에서 스토리지 요구 사항은 다음과 같을 수 있습니다. 시간이 지남에 따라 증가하는 유일한 것이기 때문에 가장 시급한 것입니다. 초당 트랜잭션 수가 변하지 않더라도 실제로는 오늘날 가장 시급한 요구 사항은 컴퓨팅 성능입니다. 전체 상태 Ethereum 이 글을 쓰는 시점에서 100GB는 대부분의 노드에서 쉽게 관리할 수 있습니다. 하지만 Ethereum이(가) 처리할 수 있는 거래 수는 약 20건입니다. 많은 실제 사용 사례에 필요한 것보다 크기가 작습니다. Zilliqa는 처리는 샤딩하지만 저장은 하지 않는 가장 잘 알려진 프로젝트입니다. 처리의 샤딩은 각 노드가 전체 정보를 갖기 때문에 문제가 더 쉽습니다. 상태, 즉 계약은 다른 계약을 자유롭게 호출하고 모든 데이터를 읽을 수 있음을 의미합니다. blockchain에서. 업데이트를 확인하려면 신중한 엔지니어링이 필요합니다. 상태의 동일한 부분을 업데이트하는 여러 샤드에서 충돌이 발생하지 않습니다. 에서 그런 점에서 질리카는 상대적으로 단순한 접근 방식을 취하고 있습니다2. 처리를 샤딩하지 않고 스토리지를 샤딩하는 것이 제안되었지만 매우 드물다. 따라서 실제로 스토리지 샤딩, 즉 상태 샤딩은 거의 항상 처리의 샤딩과 네트워크의 샤딩을 의미합니다. 실제로 상태 샤딩에서 각 샤드의 노드는 자신의 노드를 구축합니다. 로컬 부분에만 영향을 미치는 트랜잭션이 포함된 blockchain을 소유합니다. 해당 샤드에 할당된 전역 상태입니다. 따라서 validators는 샤드는 전역 상태의 로컬 부분만 저장하고 실행만 하면 됩니다. 그리고 그 자체로는 국가의 일부에 영향을 미치는 거래만을 중계합니다. 이 파티션은 모든 컴퓨팅 성능, 스토리지 및 네트워크 대역폭이 줄어들지만 데이터 가용성 및 교차 샤드 트랜잭션에 대해서는 아래에서 모두 다루겠습니다. 1.4 교차 샤드 트랜잭션 지금까지 설명한 샤딩 모델은 그다지 유용하지 않습니다. 샤드는 서로 통신할 수 없으며 여러 개보다 나을 것이 없습니다. 독립적인 blockchains. 오늘날에도 샤딩을 사용할 수 없는 경우에는 다양한 blockchain 사이의 상호 운용성에 대한 엄청난 수요. 지금은 각 참가자가 정확히 하나의 샤드에 계정을 갖는 간단한 결제 거래만 고려해 보겠습니다. 다른 곳에서 돈을 이체하고 싶다면 2그들의 접근 방식에 대한 분석은 여기에서 확인할 수 있습니다: https://medium.com/nearprotocol/ 8f9efae0ce3b동일한 샤드 내에서 한 계정에서 다른 계정으로 거래가 처리될 수 있습니다. 전적으로 해당 샤드의 validator에 의해 이루어집니다. 그러나 샤드에 상주하는 앨리스가

1은 샤드 #2에 거주하는 Bob에게 돈을 보내고 싶어하지만 validators도 마찬가지입니다.

샤드 #1(Bob의 계정에 크레딧을 제공할 수 없음)이나 validator의 샤드 샤드 #2(Alice의 계좌에서 인출할 수 없음)는 전체를 처리할 수 있습니다. 거래. 교차 샤드 트랜잭션에는 두 가지 접근 방식이 있습니다. • 동기식: 교차 샤드 트랜잭션을 실행해야 할 때마다 관련된 상태 전환을 포함하는 여러 샤드의 블록 트랜잭션은 모두 동시에 생성되며 여러 샤드의 validators가 이러한 트랜잭션을 실행하기 위해 협력합니다.3 • 비동기식: 여러 샤드에 영향을 미치는 크로스 샤드 트랜잭션 해당 샤드에서 비동기식으로 실행되며 "크레딧" 샤드가 실행됩니다. "Debit" 샤드가 해당 부분을 실행했다는 충분한 증거가 있으면 절반입니다. 이 접근 방식은 다음과 같은 이유로 더 널리 사용되는 경향이 있습니다. 단순성과 조정 용이성. 이 시스템은 현재 Cosmos, Ethereum Serenity, Near, Kadena 등에서 제안되었습니다. 이것에 문제가 있다 접근 방식은 블록이 독립적으로 생성되면 여러 블록 중 하나가 고아가 될 가능성이 0이 아니라는 것입니다. 거래가 부분적으로만 적용되었습니다. 두 가지를 묘사하는 그림 2를 고려하십시오. 포크와 교차 샤드 트랜잭션이 발생한 샤드 이에 따라 블록 A와 X'에 기록되었습니다. 체인이 A-B인 경우 V'-X'-Y'-Z'는 결국 해당 샤드에서 정식이 됩니다. 거래가 완전히 마무리되었습니다. A'-B'-C'-D' 및 V-X가 표준이 되면, 그러면 거래가 완전히 포기되며 이는 허용됩니다. 하지만 만약에, 예를 들어 A-B와 V-X가 정규화되면 트랜잭션의 한 부분이 마무리되고 다른 부분은 폐기되어 원자성 오류가 발생합니다. 우리 두 번째 부분에서는 포크 선택 규칙 및 합의에 대한 변경 사항을 다룰 때 제안된 프로토콜에서 이 문제가 어떻게 해결되는지 다룰 것입니다. 샤딩된 프로토콜을 위해 제안된 알고리즘. 체인 간 통신은 샤딩된 blockchain 외부에서 유용합니다. 너무. 체인 간의 상호 운용성은 많은 프로젝트에서 해결해야 할 복잡한 문제입니다. 해결하려고 노력하고 있습니다. 샤딩된 blockchains에서는 문제가 다소 더 쉽습니다. 블록 구조와 합의는 샤드 전반에 걸쳐 동일하며 조정에 사용할 수 있는 비콘 체인이 있습니다. 그러나 샤딩된 blockchain에서는 모든 샤드 체인은 동일하지만 글로벌 blockchain 생태계에는 다양한 대상 사용 사례, 분산화를 갖춘 다양한 blockchain이 많이 있습니다. 그리고 개인정보 보호를 보장합니다. 일련의 체인이 서로 다른 속성을 가지지만 시스템을 구축하는 것 충분히 유사한 합의 및 블록 구조를 사용하고 공통 비콘 체인을 보유하면 3The 가장 상세한 제안 알려진 에 는 작가 의 이 문서 이다 병합 블록, 설명 여기: https://ethresear.ch/t/ 병합 블록 및 동기 교차 샤드 상태 실행/1240그림 2: 비동기식 크로스 샤드 트랜잭션 작동하는 상호 운용성 하위 시스템. 이러한 시스템에는 validator 회전 기능이 없을 가능성이 높으므로 보안을 보장하기 위해 몇 가지 추가 조치를 취해야 합니다. 둘 다 Cosmos 및 PolkaDot은 사실상 그러한 시스템입니다4 1.5 악의적인 행위 이 섹션에서는 악의적인 validators를 유발할 수 있는 적대적인 행동을 검토합니다. 샤드가 손상되면 실행하세요. 우리는 고전적인 접근 방식을 검토할 것입니다 섹션 2.1에서 샤드 손상을 방지합니다. 1.5.1 악성 포크 일련의 악의적인 validator이 포크 생성을 시도할 수 있습니다. 그렇지 않다는 점 참고하세요 기본 합의가 BFT인지 아닌지가 중요합니다. 충분한 수를 손상시킵니다. validators를 사용하면 항상 포크를 생성할 수 있습니다. 전체 네트워크의 50% 이상이 손상될 가능성보다 단일 샤드의 50% 이상이 손상될 가능성이 훨씬 더 높습니다(우리는 섹션 2.1에서 이러한 확률에 대해 더 자세히 알아보세요. 섹션 1.4에서 논의한 바와 같이, 교차 샤드 트랜잭션에는 여러 샤드의 특정 상태 변경이 포함됩니다. 그러한 상태 변경을 적용하는 샤드의 해당 블록은 다음과 같아야 합니다. 모두 마무리되거나(즉, 해당하는 선택된 체인에 나타남) 샤드) 또는 모두 고아가 됩니다(즉, 해당 샤드의 선택한 체인에 표시되지 않음). 일반적으로 샤드가 손상될 가능성이 높기 때문에 4Cosmos: https://forum.cosmos.network/에서 Zaki Manian이 쓴 이 글을 참조하세요. t/polkadot-vs-cosmos/1397/2 및 이 문서의 첫 번째 작성자가 작성한 트윗 폭풍: 자세한 비교는 https://twitter.com/AlexSkidanov/status/1129511266660126720 둘 중

무시할 수 없는 수준이 아니므로 샤드 validator 사이에서 비잔틴 합의가 이루어지거나 많은 블록이 비잔틴 합의에 도달하더라도 포크가 발생하지 않을 것이라고 가정할 수 없습니다. 상태 변경으로 블록 상단에 생성됩니다. 이 문제에는 여러 가지 해결 방법이 있으며 가장 일반적인 해결 방법은 가끔 발생합니다. 최신 샤드 체인 블록을 비콘 체인에 교차 연결합니다. 포크 그런 다음 샤드 체인의 선택 규칙은 항상 체인을 선호하도록 변경됩니다. 교차 연결되었으며, 해당 블록에 대해서만 샤드별 포크 선택 규칙을 적용합니다. 마지막 교차 링크 이후 게시되었습니다. 1.5.2 잘못된 블록 승인 validator 세트가 상태 전환 기능을 잘못 적용하는 블록을 생성하려고 시도할 수 있습니다. 예를 들어 Alice가 있는 상태에서 시작하면 10개의 token이 있고 Bob은 0개의 token이 있는 경우 블록에는 다음과 같은 트랜잭션이 포함될 수 있습니다. Alice가 Bob에게 10개의 token을 보내지만 결국 Alice가 다음과 같은 상태가 됩니다. 그림 3에 표시된 대로 0 tokens이고 Bob은 1000 tokens를 갖습니다. 그림 3: 유효하지 않은 블록의 예 샤딩되지 않은 전통적인 blockchain에서는 이러한 공격이 불가능합니다. 네트워크 참가자는 모든 블록을 검증하고, 이를 가진 블록은 유효하지 않은 상태 전환은 다른 블록 생산자 모두에 의해 거부됩니다. 블록을 생성하지 않는 네트워크 참여자. 악의적이더라도 validators는 이러한 유효하지 않은 블록 위에 블록을 계속해서 생성합니다. 정직한 validators는 올바른 체인을 구축하여 잘못된 체인을 갖게 됩니다. 블록이 길어도 문제가 되지 않습니다. blockchain는 어떤 목적으로든 모든 블록을 검증하고 모든 블록을 삭제합니다. 유효하지 않은 블록 위에 구축됩니다. 그림 4에는 5개의 validator이 있으며 그 중 3개는 악성입니다. 그들은 유효하지 않은 블록 A'를 생성한 다음 그 위에 계속해서 새 블록을 구축했습니다. 그것의. 두 명의 정직한 validator가 A'를 유효하지 않은 것으로 폐기하고 그 위에 구축하고 있었습니다.그림 4: 샤딩되지 않은 blockchain에서 잘못된 블록을 생성하려고 시도했습니다. 그들에게 알려진 마지막 유효한 블록을 삭제하여 포크를 생성합니다. 수가 적기 때문에 validators 정직한 포크에서는 체인이 더 짧습니다. 그러나 클래식 비샤딩 blockchain에서는 어떤 목적으로든 blockchain을 사용하는 모든 참가자가 수신한 모든 블록의 유효성을 검사하고 상태를 다시 계산하는 일을 담당합니다. 따라서 blockchain에 관심이 있는 사람은 누구나 A'를 관찰할 것입니다. 유효하지 않으므로 B', C' 및 D'도 즉시 폐기합니다. 체인 A-B는 현재 가장 긴 유효한 체인입니다. 그러나 샤딩된 blockchain에서는 참가자가 모든 샤드의 모든 트랜잭션을 확인할 수 없으므로 이를 확인할 수 있는 방법이 필요합니다. blockchain의 샤드 기록 중 유효하지 않은 블록이 포함되지 않았습니다. 포크와 달리 비콘 체인에 대한 교차 연결은 충분한 솔루션이 아닙니다. 비콘 체인에는 검증할 수 있는 능력이 없기 때문입니다. 블록. 해당 샤드에 충분한 수의 validator이 있는지만 확인할 수 있습니다. 블록에 서명했습니다(그리고 그 정확성이 입증되었습니다). 아래 섹션 2.2에서 이 문제에 대한 해결책을 논의하겠습니다.

Parçalama Temelleri

Parçalamaya en basit yaklaşımla başlayalım. Bu yaklaşımda bunun yerine bir blockchain çalıştırıyorsak, birden fazla çalıştıracağız ve bunların her birine blockchain a adını vereceğiz "parça". Her parçanın kendine ait validator kümesi olacaktır. Burada ve aşağıda kullanıyoruz işlemleri doğrulayan katılımcılara atıfta bulunmak için genel bir terim olan “validator” ve Proof of Work gibi madencilik yoluyla veya oylamaya dayalı bir yöntemle bloklar üretin 1Bu bölüm daha önce https://near.ai/shard1. adresinde yayınlanmıştı. Daha önce okuduysanız, sonraki bölüme geçin.

mekanizma. Şimdilik parçaların hiçbir zaman birbiriyle iletişim kurmadığını varsayalım. diğer. Bu tasarım, basit olmasına rağmen, parçalamadaki başlangıçtaki bazı büyük zorlukların ana hatlarını çizmek için yeterlidir. 1.1 Doğrulayıcı bölümleme ve Beacon zincirleri Sistemin 10 parçadan oluştuğunu varsayalım. İlk zorluk, her biriyle kendi validator'lerine sahip olan her bir parça artık 10 kat daha az güvenli tüm zincir. Yani X validators içeren parçalanmamış bir zincir hard fork yapmaya karar verirse parçalanmış bir zincire ayırır ve X validator'yi 10 parçaya böler, her parça şimdi yalnızca X/10 validators var ve bir parçayı bozmak yalnızca bozmayı gerektirir Toplam validators sayısının %5,1'i (%51 / 10) (bkz. şekil 1), Şekil 1: validator'leri parçalara bölme bu da bizi ikinci noktaya getiriyor: kim her parça için validators seçer? validators'nin %5,1'ini kontrol etmek, yalnızca validators'nin %5,1'inin tamamının olması durumunda zarar verir aynı parçanın içindeler. validators hangi parçayı doğrulayacaklarını seçemiyorsa validator'lerin %5,1'ini kontrol eden bir katılımcının tümünü alması pek olası değil validator'leri aynı parçada bulunuyor ve bu da uzlaşma yeteneklerini büyük ölçüde azaltıyor sistem. Bugün neredeyse tüm parçalama tasarımları, bazı rastgelelik kaynaklarına dayanmaktadır. Parçalara validators atayın. blockchain üzerindeki rastgelelik başlı başına oldukça zorlu bir konudur ve bu belgenin kapsamı dışındadır. Şimdilik var olduğunu varsayalım kullanabileceğimiz bir tür rastlantısallık kaynağı. validator'in ödevini şu bölümde ele alacağız: Bölüm 2.1'de daha fazla ayrıntı verilmiştir. Hem rastgelelik hem de validator ataması, herhangi bir parçaya özeldir. Bu hesaplama için, pratik olarak mevcut tüm tasarımlarda, işlemleri gerçekleştirmekle görevli ayrı bir blockchain bulunur tüm ağın bakımı için gereklidir. Rastgele üretmenin yanı sırasayılar ve parçalara validator atama, bu işlemler genellikle aynı zamanda Parçalardan güncelleme almayı ve bunların anlık görüntülerini almayı, işlemeyi içerir Hisse Kanıtı sistemlerinde kazıklar ve kesintiler ve bu durumlarda parçaların yeniden dengelenmesi özelliği desteklenmektedir. Böyle bir zincire Ethereum'de Beacon zinciri, bir Röle denir PolkaDot'taki zincir ve Cosmos'deki Cosmos Hub. Bu belge boyunca böyle bir zincire Beacon zinciri olarak değineceğiz. Beacon zincirinin varlığı bizi bir sonraki ilginç konuya getiriyor: ikinci dereceden parçalama. 1.2 İkinci dereceden parçalama Parçalama genellikle sayıya göre sonsuz ölçeklenen bir çözüm olarak tanıtılır. Ağ işlemine katılan düğümlerin sayısı. Teorik olarak mümkün olmakla birlikte böyle bir parçalama çözümü tasarlayın, Beacon konseptine sahip herhangi bir çözüm zincirin sonsuz ölçeklenebilirliği yoktur. Nedenini anlamak için Beacon'a dikkat edin. zincirin, validator'ları atamak gibi bazı muhasebe hesaplamaları yapması gerekiyor sayısıyla orantılı olan parçalar veya anlık parça zincir blokları sistemdeki parçaların sayısı. Beacon zincirinin kendisi tek bir blockchain olduğundan, hesaplama, onu çalıştıran düğümlerin hesaplama yetenekleriyle sınırlıdır, parça sayısı doğal olarak sınırlıdır. Bununla birlikte, bölünmüş bir ağın yapısı çarpımsal bir değer verir. düğümlerindeki iyileştirmeleri etkiler. Keyfi bir durumun olduğu durumu düşünün Ağdaki düğümlerin verimliliğinde iyileştirmeler yapılarak daha hızlı işlem işlem süreleri sağlarlar. Beacon zincirindeki düğümler de dahil olmak üzere ağı işleten düğümler, dört kat daha hızlı hale gelirse her parça dört kat daha fazla işleyebilecek Beacon zinciri 4 kat daha fazla parçayı koruyabilecek. Sistem genelinde verim 4 × 4 = 16 faktörüyle artacaktır — dolayısıyla ikinci dereceden parçalama adı. Kaç parça olduğuna dair doğru bir ölçüm sağlamak zordur. bugün uygulanabilir, ancak öngörülebilir bir gelecekte üretim hacminin artması pek olası değildir. blockchain kullanıcılarının ihtiyaçları, ikinci dereceden parçalamanın sınırlamalarını aşacaktır. Bu kadar çok parçayı güvenli bir şekilde çalıştırmak için gereken çok sayıda düğüm var muhtemelen tüm düğümleri çalıştıran düğümlerin sayısından daha büyük mertebelerdedir. blockchains bugün birleşti. 1.3 Durum paylaşımı Şu ana kadar tam olarak neyin ayrılıp ayrılmadığını çok iyi tanımlamadık. bir ağ parçalara bölündüğünde. Özellikle, blockchain içindeki düğümler üç önemli görevi yerine getirirler: yalnızca 1) işlemleri işlemekle kalmazlar, ayrıca 2) doğrulanmış işlemleri ve tamamlanan blokları diğer düğümlere iletmek ve 3) tüm ağ defterinin durumunu ve geçmişini saklayın. Bu üçünün her biri görevler, ağı işleten düğümlere artan bir gereksinim getirmektedir:1. İşlemleri işleme zorunluluğu daha fazla bilgi işlem gücü gerektirir işlenen işlemlerin artan sayısı; 2. İşlemlerin ve blokların aktarılması gerekliliği, aktarılan işlem sayısının artmasıyla birlikte daha fazla ağ bant genişliği gerektirir; 3. Verilerin saklanması zorunluluğu, devlet büyüdükçe daha fazla depolama gerektirir. Daha da önemlisi, işlem gücü ve ağdan farklı olarak, işlem oranı (işlenen işlem sayısı) ne kadar yüksek olsa bile depolama gereksinimi artar. saniyede) sabit kalır. Yukarıdaki listeden depolama gereksiniminin şu şekilde olduğu görünebilir: en acil olanı, çünkü zamanla artan tek şey bu Saniyedeki işlem sayısı değişmese de pratikte günümüzün en acil gereksinimi bilgi işlem gücüdür. Tüm durumu Ethereum bu yazının yazıldığı an itibarıyla 100 GB'tır ve düğümlerin çoğu tarafından kolaylıkla yönetilebilir. Ancak Ethereum'in işleyebileceği işlem sayısı 20 civarındadır. birçok pratik kullanım durumu için gerekenden daha az büyüklük. Zilliqa, parça işlemeyi ancak depolamayı değil, en bilinen projedir. İşlemenin parçalanması daha kolay bir sorundur çünkü her düğüm tüm Bu, sözleşmelerin serbestçe diğer sözleşmeleri başlatabileceği ve herhangi bir veriyi okuyabileceği anlamına gelir blockchain'den. Güncellemelerin yapıldığından emin olmak için dikkatli bir mühendislik gereklidir. Durumun aynı bölümlerini güncelleyen birden fazla parçadan alınan bilgiler çakışmaz. içinde Zilliqa bu konuda nispeten basit bir yaklaşım benimsiyor2. İşlemenin parçalanması olmadan depolamanın parçalanması önerilmiş olsa da, son derece nadir. Bu nedenle pratikte depolamanın parçalanması veya Durum Parçalaması, neredeyse her zaman işlemenin parçalanması ve ağın parçalanması anlamına gelir. Pratik olarak, Durum Parçalaması altında her bir parçadaki düğümler kendi yalnızca yerel kısmını etkileyen işlemleri içeren kendi blockchain söz konusu parçaya atanan küresel durum. Bu nedenle, validator'ler Shard'ın yalnızca küresel durumun yerel bölümünü depolaması ve yalnızca yürütmesi gerekir, ve bu nedenle yalnızca devletin kendilerine ait kısmını etkileyen işlemleri aktarır. Bu bölümleme, tüm bilgi işlem gücü, depolama ve depolama gereksinimlerine olan gereksinimi doğrusal olarak azaltır. ağ bant genişliği, ancak veri kullanılabilirliği ve Her ikisini de aşağıda ele alacağımız çapraz parçalar arası işlemler. 1.4 Parçalar arası işlemler Şu ana kadar anlattığımız parçalama modeli pek kullanışlı değil çünkü eğer bireysel Parçalar birbirleriyle iletişim kuramazlar, birden fazla parçadan daha iyi değiller bağımsız blockchains. Bugün bile, parçalamanın mevcut olmadığı durumlarda, çeşitli blockchain'lar arasında birlikte çalışabilirlik konusunda büyük talep. Şimdilik yalnızca her katılımcının tam olarak bir parça üzerinde hesabının olduğu basit ödeme işlemlerini ele alalım. Eğer biri para transferi yapmak isterse 2Yaklaşımlarına ilişkin analizimizi burada bulabilirsiniz: https://medium.com/nearprotocol/ 8f9efae0ce3baynı parça içindeki bir hesaptan diğerine geçiş yapıldığında işlem gerçekleştirilebilir tamamen o parçadaki validator'ler tarafından. Ancak eğer parçada ikamet eden Alice

1, validators parçasının hiçbiri değil, #2 numaralı parçada ikamet eden Bob'a para göndermek istiyor

1 numaralı parçada (Bob'un hesabına para yatıramayacaklar) veya validator'lerde 2 numaralı parça (Alice'in hesabını borçlandıramayacaklar) tüm verileri işleyebilir işlem. Parçalar arası işlemlere yönelik iki yaklaşım ailesi vardır: • Eşzamanlı: Parçalar arası bir işlemin yürütülmesi gerektiğinde, ile ilgili durum geçişini içeren birden fazla parçadaki bloklar işlemlerin tümü aynı anda üretilir ve birden çok parçadan oluşan validator'ler bu tür işlemlerin yürütülmesinde işbirliği yapar.3 • Eşzamansız: birden fazla parçayı etkileyen, parçalar arası bir işlem bu parçalarda eşzamansız olarak yürütülür, "Kredi" parçası yürütülür "Borç" parçasının kendi payına düşeni yerine getirdiğine dair yeterli kanıt bulunduğunda yarısı. Bu yaklaşım daha yaygın olma eğilimindedir çünkü basitlik ve koordinasyon kolaylığı. Bu sistem bugün Cosmos, Ethereum Serenity, Near, Kadena ve diğerlerinde önerilmektedir. Bununla ilgili bir sorun Yaklaşım, eğer bloklar bağımsız olarak üretilirse, birden fazla bloktan birinin yetim kalma şansının sıfır olmadığı, dolayısıyla işlem yalnızca kısmen uygulandı. İkisini gösteren şekil 2'yi düşünün. her ikisi de çatalla karşılaşan parçalar ve parçalar arası işlem bu sırasıyla A ve X' bloklarına kaydedildi. A-B zincirleri ise ve V'-X'-Y'-Z' ilgili parçalarda kanonik hale gelir, işlem tamamen sonuçlandırılmıştır. A'-B'-C'-D' ve V-X kanonik hale gelirse, daha sonra işlem tamamen iptal edilir ve bu kabul edilebilir bir durumdur. Ama eğer, için Örneğin, A-B ve V-X kanonik hale gelir, daha sonra işlemin bir kısmı sonlandırılır ve bir kısmı terk edilir, bu da atomite hatası yaratır. Biz İkinci bölümde, çatal seçimi kuralları ve fikir birliğinde yapılan değişiklikleri ele alırken, önerilen protokollerde bu sorunun nasıl ele alındığı ele alınacaktır. Parçalanmış protokoller için önerilen algoritmalar. Zincirler arasındaki iletişimin parçalanmış blockchains dışında yararlı olduğunu unutmayın çok. Zincirler arasındaki birlikte çalışabilirlik, birçok projenin karşılaştığı karmaşık bir sorundur. çözmeye çalışıyoruz. Parçalanmış blockchains'de sorun biraz daha kolaydır çünkü Blok yapısı ve fikir birliği tüm parçalarda aynıdır ve koordinasyon için kullanılabilecek bir işaret zinciri vardır. Ancak parçalanmış bir blockchain'da, tüm parça zincirleri aynıdır, küresel blockchains ekosisteminde ise farklı hedef kullanım durumları ve merkezi olmayan çok sayıda farklı blockchain var ve gizlilik garantileri. Bir dizi zincirin farklı özelliklere sahip olduğu ancak yeterince benzer fikir birliği ve blok yapısı kullanmak ve ortak bir işaret zincirine sahip olmak, heterojen blockchain'lerden oluşan bir ekosistemi mümkün kılabilir. 3The çoğu detaylı teklif bilinen için the yazarlar arasında bu belge öyle Birleştir Bloklar, tarif edildi burada: https://ethresear.ch/t/ birleştirme blokları ve eşzamanlı çapraz parça durumu yürütme/1240Şekil 2: Eşzamansız parçalar arası işlemler Birlikte çalışabilirlik alt sistemi. Bu tür bir sistemin validator rotasyon özelliğine sahip olması pek olası değildir, bu nedenle güvenliği sağlamak için bazı ekstra önlemlerin alınması gerekir. Her ikisi de Cosmos ve PolkaDot bu tür sistemlerdir4 1.5 Kötü niyetli davranış Bu bölümde hangi düşmanca davranışların validators'ye zarar verebileceğini inceleyeceğiz. bir parçayı bozmayı başarırlarsa egzersiz yapın. Klasik yaklaşımları gözden geçireceğiz bölüm 2.1'deki parçaların bozulmasını önlemek için. 1.5.1 Kötü amaçlı çatallar Bir grup kötü niyetli validators bir çatal oluşturmaya çalışabilir. öyle olmadığını unutmayın Temel fikir birliğinin BFT olup olmadığı önemli değil, yeterli sayıyı bozuyor validators'nin sayısı her zaman bir çatal oluşturmayı mümkün kılacaktır. Tek bir parçanın %50'sinden fazlasının bozulması, tüm ağın %50'sinden fazlasının bozulmasından çok daha olasıdır (biz Bölüm 2.1'de bu olasılıkları daha derinlemesine inceleyin. Bölüm 1.4'te tartışıldığı gibi, Parçalar arası işlemler, birden fazla parçadaki belirli durum değişikliklerini içerir ve bu tür durum değişikliklerini uygulayan bu tür parçalardaki karşılık gelen blokların ya hepsi sonlandırılacak (yani ilgili zincirlerde seçilen zincirlerde görünecek) parçalar) veya tümü yetim kalmış (yani karşılık gelen parçalarda seçilen zincirlerde görünmüyor). Genel olarak parçaların bozulma olasılığı olduğundan 4Zaki Manian'ın Cosmos adresinden yazdığı şu yazıya bakın: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 ve bu belgenin ilk yazarının yazdığı şu tweet fırtınası: Ayrıntılı bir karşılaştırma için https://twitter.com/AlexSkidanov/status/1129511266660126720 ikisinden

ihmal edilebilir değil, validators parçaları arasında Bizans'a özgü bir fikir birliğine varılsa veya birçok blok bloke edilse bile çatallanmaların gerçekleşmeyeceğini varsayamayız. durum değişikliği ile bloğun üstünde üretilir. Bu sorunun birden fazla çözümü var; en yaygın olanı ara sıra olanıdır. en son parça zinciri bloğunun işaret zincirine çapraz bağlanması. Çatal Parça zincirlerindeki seçim kuralı daha sonra her zaman aşağıdaki zinciri tercih edecek şekilde değiştirilir. çapraz bağlantılıdır ve yalnızca parçaya özgü çatal seçimi kuralını bloklar için uygular. son çapraz bağlantıdan bu yana yayınlandı. 1.5.2 Geçersiz blokları onaylama Bir validator kümesi, durum geçiş fonksiyonunu yanlış uygulayan bir blok oluşturmaya çalışabilir. Örneğin, Alice'in bulunduğu bir durumdan başlayarak 10 tokens ve Bob'un 0 tokens'si varsa, blok şu şekilde bir işlem içerebilir: Alice'ten Bob'a 10 tokens gönderir, ancak sonunda Alice'in sahip olduğu bir durumla karşılaşır. Şekil 3'te gösterildiği gibi 0 tokens ve Bob'un 1000 tokens'si var. Şekil 3: Geçersiz blok örneği Parçalı olmayan klasik bir blockchain'de böyle bir saldırı mümkün değildir, çünkü hepsi ağdaki katılımcı tüm blokları ve buna sahip bloğu doğrular geçersiz bir durum geçişi diğer blok üreticilerinin her ikisi tarafından da reddedilecektir ve Ağın blok oluşturmayan katılımcıları. Kötü niyetli olsa bile validators, böyle geçersiz bir bloğun üzerinde bloklar oluşturmaya daha hızlı devam ediyor dürüst validator'ler doğru zinciri oluşturur, böylece geçersiz zincire sahip olurlar bloğun daha uzun olması önemli değil, çünkü bloğu kullanan her katılımcı blockchain herhangi bir amaç için tüm blokları doğrular ve tüm blokları atar geçersiz bloğun üzerine inşa edilmiştir. Şekil 4'te beş validator var ve bunların üçü kötü niyetli. onlar geçersiz bir A' bloğu oluşturdu ve ardından üstüne yeni bloklar oluşturmaya devam etti ondan. İki dürüst validator, A'yı geçersiz olarak değerlendirdi ve üstüne ekleme yaptılarŞekil 4: Parçalanmamış bir blockchain içinde geçersiz bir blok oluşturma girişimi Bildikleri son geçerli bloğun bir çatal oluşturmasını sağlar. Daha az sayıda olduğundan validators dürüst çataldadır, zincirleri daha kısadır. Ancak klasik parçalanmamış blockchain'da herhangi bir amaç için blockchain kullanan her katılımcı aldıkları tüm blokları doğrulamaktan ve durumu yeniden hesaplamaktan sorumludur. Dolayısıyla blockchain ile ilgisi olan herhangi bir kişi A' geçersizdir ve bu nedenle B', C' ve D'yi de derhal atın; A-B zincirini mevcut en uzun geçerli zincir olarak seçin. Bununla birlikte, parçalı bir blockchain'de hiçbir katılımcı tüm parçalardaki tüm işlemleri doğrulayamaz; bu nedenle, bunu hiçbir durumda onaylamak için bir yola sahip olmaları gerekir. blockchain parçasının herhangi bir parçasının tarihinde hiçbir geçersiz blok dahil edilmedi. Çatallardan farklı olarak Beacon zincirine çapraz bağlanmanın yeterli bir çözüm olmadığını unutmayın, çünkü Beacon zincirinin doğrulama kapasitesi yoktur. bloklar. Yalnızca söz konusu parçada yeterli sayıda validator olduğunu doğrulayabilir bloğu imzaladı (ve bu nedenle doğruluğunu onayladı). Bu sorunun çözümlerini aşağıdaki bölüm 2.2'de tartışacağız.

상태 유효성 및 데이터 가용성

샤딩된 blockchains의 핵심 아이디어는 대부분의 참가자가 네트워크를 사용하면 모든 샤드의 블록을 확인할 수 없습니다. 이처럼, 언제든지 모든 참가자는 일반적으로 사용할 수 없는 특정 샤드와 상호 작용해야 합니다. 샤드의 전체 기록을 다운로드하고 검증합니다. 그러나 샤딩의 파티셔닝 측면은 상당한 잠재력을 불러일으킵니다. 문제: 특정 기록의 전체 기록을 다운로드하고 검증하지 않고 샤드 참가자는 반드시 상태가 무엇인지 확신할 수 없습니다. 5하위 섹션 2.5.3을 제외하고 이 섹션은 이전에 https://near.ai/에 게시되었습니다. 샤드2. 이전에 읽으셨다면 다음 섹션으로 건너뛰세요.

그들이 상호 작용하는 것은 유효한 블록 시퀀스의 결과이며 그러한 시퀀스는 of block은 실제로 샤드의 정식 체인입니다. 그렇지 않은 문제 샤딩되지 않은 blockchain에 존재합니다. 먼저 제안된 이 문제에 대한 간단한 해결책을 제시하겠습니다. 여러 프로토콜을 사용하여 이 솔루션이 어떻게 중단될 수 있는지 분석하고 이를 해결하기 위한 시도가 이루어졌습니다. 2.1 검증인 교체 상태 타당성에 대한 순진한 해결책은 그림 5에 나와 있습니다. 전체 시스템에는 수천 개의 validator이 있으며 그 중 20% 이하가 악의적이거나 다른 방식으로 실패합니다(예: 온라인으로 블록을 생성합니다). 그런 다음 200개의 validator을 샘플링하면 확률은 1개 이상의 실용적인 목적으로 3개의 실패는 0으로 가정될 수 있습니다. 그림 5: 샘플링 validators 1 3은 중요한 기준점이다. 합의 프로토콜 계열이 있습니다. BFT 합의 프로토콜은 1보다 적은 기간 동안 이를 보장합니다. 3개 참가자가 충돌하거나 규정을 위반하는 방식으로 행동하여 실패합니다. 프로토콜을 통해 합의에 도달할 것입니다. 정직한 validator 백분율을 가정하여 현재 세트가 샤드의 validators는 우리에게 일부 블록을 제공하며 순진한 솔루션은 가정합니다. 블록이 유효하고 validators가 믿었던 것을 기반으로 구축되었습니다. 검증을 시작할 때 해당 샤드에 대한 정식 체인입니다. validators 이전 validator 세트에서 표준 체인을 배웠습니다. 캐노니컬 체인의 선두인 블록 위에 구축된 가정 그 전에. 유도에 의해 전체 체인이 유효하며 validators 세트가 없기 때문에 어느 시점에서든 포크가 생성되면 순진한 솔루션은 현재의 체인은 샤드의 유일한 체인입니다. 시각화는 그림 6을 참조하세요.

그림 6: BFT 합의를 통해 확정된 각 블록의 blockchain validators가 다음과 같을 수 있다고 가정하면 이 간단한 솔루션은 작동하지 않습니다. 이는 적응적으로 손상되었으며 이는 불합리한 가정이 아닙니다6. 적응적으로 1000개의 샤드가 있는 시스템에서 단일 샤드를 손상시키는 것이 훨씬 저렴합니다. 전체 시스템을 손상시키는 것보다. 따라서 프로토콜의 보안은 샤드 수에 따라 선형적으로 감소합니다. 타당성에 대한 확신을 갖기 위해 블록을 생성하려면 역사상 어느 시점에서든 시스템의 샤드가 없음을 알아야 합니다. validator의 대다수가 공모하고 있습니다. 적응형 적과 함께라면 우리는 더 이상 그런 확신. 섹션 1.5에서 논의한 것처럼 validators의 공모는 행사할 수 있습니다. 두 가지 기본적인 악의적 행동: 포크 생성 및 유효하지 않은 블록 생성. 악의적인 포크는 일반적으로 기존보다 훨씬 더 높은 보안을 갖도록 설계된 비콘 체인에 블록을 교차 연결하여 처리할 수 있습니다. 샤드 체인. 그러나 유효하지 않은 블록을 생성하는 것은 훨씬 더 많은 것입니다. 해결해야 할 어려운 문제. 2.2 상태 유효성 샤드 #1이 손상되고 악의적인 행위자가 생성하는 그림 7을 생각해 보세요. 유효하지 않은 블록 B. 이 블록 B에서 1000 tokens가 씬에서 생성되었다고 가정합니다. 앨리스 계정으로 방송됩니다. 그런 다음 악의적인 행위자는 유효한 블록 C를 생성합니다( C의 트랜잭션이 올바르게 적용되었음을 감지) B 위에서 난독화 유효하지 않은 블록 B를 삭제하고 샤드 #2에 대한 교차 샤드 트랜잭션을 시작합니다. 1000 token을 Bob의 계좌로 이체합니다. 지금부터 부적절하게 생성된 token은 샤드 #2의 완전히 유효한 blockchain에 상주합니다. 이 문제를 해결하기 위한 몇 가지 간단한 접근 방식은 다음과 같습니다. 6읽기 이 기사 에 대한 세부사항 에 어떻게 적응형 부패 할 수 있다 있다 운반 밖으로: https://medium.com/nearprotocol/d859adb464c8. 에 대한 더 세부사항 에 적응형 부패, 읽다 https://github.com/ethereum/wiki/wiki/Sharding-FAQ# 우리가 운영하고 있는 보안 모델은 무엇입니까?그림 7: 유효하지 않은 블록이 있는 체인의 교차 샤드 트랜잭션 1. 샤드 #2의 validators에 대해 트랜잭션이 발생한 블록을 검증합니다. 시작됩니다. 위의 예에서도 블록 C 때문에 작동하지 않습니다. 완전히 유효한 것 같습니다. 2. 샤드 #2의 validators에서 트랜잭션이 시작되는 블록 이전에 있는 다수의 블록을 검증합니다. 당연히, 수신 샤드에 의해 검증된 블록 수 N validators는 잘못된 블록 위에 N+1개의 유효한 블록을 생성할 수 있습니다. 생산. 이 문제를 해결하기 위한 유망한 아이디어는 샤드를 배열하는 것입니다. 각 샤드가 여러 다른 샤드에 연결된 무방향 그래프 인접한 샤드 간의 교차 샤드 트랜잭션만 허용합니다. Vlad Zamfir의 샤딩은 기본적으로 작동하며7, Kadena의 샤딩에서도 비슷한 아이디어가 사용됩니다. 체인웹 [1]). 샤드 간 교차 샤드 트랜잭션이 필요한 경우 이웃이 아닌 경우 이러한 트랜잭션은 여러 샤드를 통해 라우팅됩니다. 이 디자인에서는 각 샤드의 validator는 샤드의 모든 블록을 모두 검증해야 합니다. 모든 인접 샤드의 모든 블록도 마찬가지입니다. 아래 그림을 고려하십시오 샤드 10개, 각 샤드에는 4개의 이웃이 있고 더 많은 샤드가 필요한 샤드는 2개 없습니다. 그림 8에 표시된 교차 샤드 통신의 경우 홉이 2개 이상입니다. 샤드 #2는 자체 blockchain뿐만 아니라 blockchain도 검증합니다. 샤드 #1을 포함한 모든 이웃. 따라서 샤드 #1의 악의적인 행위자가 유효하지 않은 블록 B를 생성하려고 시도한 다음 그 위에 블록 C를 구축하려고 합니다. 교차 샤드 트랜잭션을 시작하면 이러한 교차 샤드 트랜잭션은 진행되지 않습니다. 샤드 #2가 샤드 #1의 전체 기록을 검증했기 때문에 유효하지 않은 블록 B를 식별하게 됩니다. 7여기에서 디자인에 대해 자세히 알아보세요: https://medium.com/nearprotocol/37e538177ed9

그림 8: 체인웹과 같은 시스템에서 잘못된 교차 샤드 트랜잭션이 발생합니다. 감지되다 단일 샤드를 손상시키는 것은 더 이상 실행 가능한 공격이 아니지만 소수의 샤드가 문제로 남아 있습니다. 그림 9에서는 두 샤드 모두를 손상시키는 적

1과 샤드 #2는 샤드 #3에 대한 교차 샤드 트랜잭션을 성공적으로 실행합니다.

유효하지 않은 블록 B의 자금으로: 그림 9: 체인웹과 같은 시스템에서 잘못된 교차 샤드 트랜잭션이 발생합니다. 감지되지 않음 샤드 #3은 샤드 #2의 모든 블록을 검증하지만 샤드 #1에서는 그렇지 않습니다. 악성 블록을 탐지할 방법이 없습니다. 상태 타당성을 적절하게 해결하는 데에는 두 가지 주요 방향이 있습니다.

및 계산의 암호화 증명. 2.3 어부 첫 번째 접근 방식의 기본 아이디어는 다음과 같습니다. 어떤 목적으로든 체인 간에 통신됩니다(예: 비콘 체인 또는 교차 샤드 트랜잭션)에는 일정 기간이 있습니다. 정직한 validator은 블록이 유효하지 않다는 증거를 제공할 수 있습니다. 거기 블록이 다음과 같다는 매우 간결한 증거를 가능하게 하는 다양한 구성입니다. 유효하지 않으므로 수신 노드의 통신 오버헤드가 훨씬 작습니다. 전체 블록을 받는 것보다 적어도 하나의 정직한 validator이 있는 한 이 접근 방식을 사용합니다. 샤드, 시스템은 안전합니다. 그림 10: 어부 이는 오늘날 제안된 프로토콜 중에서 (문제가 존재하지 않는 척하는 것 외에도) 지배적인 접근 방식입니다. 그러나 이 접근 방식에는 두 가지가 있습니다. 주요 단점: 1. 정직한 validator을 위해서는 도전 기간이 충분히 길어야 합니다. 블록이 생성되었음을 인식하고, 다운로드하고, 완전히 검증하고, 준비하는 것 블록이 유효하지 않은 경우 챌린지입니다. 그러한 기간을 도입하면 샤드 간 트랜잭션 속도가 현저히 느려집니다. 2. 챌린지 프로토콜의 존재로 인해 새로운 공격 벡터가 생성됩니다. 악성 노드가 유효하지 않은 챌린지로 스팸을 보낼 때. 확실한 해결책 이 문제는 도전자가 일정량의 token을 입금하도록 하는 것입니다. 챌린지가 유효한 경우 반환됩니다. 이는 부분적인 해결책일 뿐이므로 공격자가 시스템에 스팸을 보내는 것은 여전히 유익할 수 있습니다. 예금) 유효하지 않은 도전과 함께, 예를 들어 유효한 것을 방지하기 위해정직한 validator의 도전을 통과하세요. 이러한 공격은 애도 공격이라고합니다. 후자의 지점을 우회하는 방법은 섹션 3.7.2를 참조하세요. 2.4 간결한 비대화형 지식 논증 다중 샤드 손상에 대한 두 번째 해결책은 특정 계산(예: 일련의 거래에서 블록을 계산하는 것처럼)이 올바르게 수행되었습니다. 이러한 구조가 존재합니다. zk-SNARK, zk-STARK 및 기타 몇 가지 일부는 오늘날 개인 결제를 위해 blockchain 프로토콜에서 적극적으로 사용됩니다. 가장 주목할만한 것은 ZCash입니다. 이러한 기본 요소의 주요 문제점은 다음과 같습니다. 계산 속도가 매우 느립니다. 예: zk-SNARK를 사용하는 Coda 프로토콜 특히 blockchain의 모든 블록이 유효하다는 것을 증명하기 위해 증거를 만드는 데 거래당 30초가 걸릴 수 있다는 인터뷰 (이 숫자는 아마도 지금쯤에는 더 작을 것입니다). 흥미롭게도, 신뢰할 수 있는 당사자가 증명을 계산할 필요가 없습니다. 증명은 그것이 만들어진 계산의 타당성을 증명할 뿐만 아니라 증명 자체의 타당성. 따라서 그러한 증명의 계산은 분할될 수 있습니다. 것보다 중복성이 훨씬 적은 참가자 집합 중에서 신뢰할 수 없는 계산을 수행하는 데 필요합니다. 참가자에게도 허용됩니다. zk-SNARK를 계산하여 비용을 줄이지 않고 특수 하드웨어에서 실행하는 사람 시스템의 분산화. 성능 외에도 zk-SNARK의 과제는 다음과 같습니다. 1. 덜 연구되고 덜 테스트된 암호화 기본 요소에 대한 의존성 2. "독성 폐기물" — zk-SNARK는 그룹이 신뢰하는 설정에 의존합니다. 의 사람들이 일부 계산을 수행한 다음 중간 결과를 버립니다. 해당 계산의 값. 절차의 모든 참가자가 공모하는 경우 중간 값을 유지하면 가짜 증거가 생성될 수 있습니다. 3. 시스템 설계에 추가 복잡성이 도입되었습니다. 4. zk-SNARK는 가능한 계산의 하위 집합에 대해서만 작동하므로 프로토콜은 Turing-complete smart contract 언어로는 사용할 수 없습니다 SNARK는 체인의 유효성을 증명합니다. 2.5 데이터 가용성 우리가 다룰 두 번째 문제는 데이터 가용성입니다. 일반적으로 노드 특정 blockchain을 운영하는 것은 두 그룹으로 구분됩니다: 전체 노드, 모든 전체 블록을 다운로드하고 모든 거래를 검증하는 것, 그리고 Light 블록 헤더만 다운로드하고 부분에 Merkle 증명을 사용하는 노드 그림 11에서 볼 수 있듯이 그들이 관심을 갖고 있는 상태와 트랜잭션에 대해 설명합니다.

그림 11: 머클 트리 이제 대다수의 전체 노드가 공모하면 유효하거나 유효한 블록을 생성할 수 있습니다. 유효하지 않으며 hash을 라이트 노드로 보내지만 전체 내용을 공개하지 마십시오. 블록의. 그들이 그것으로부터 이익을 얻을 수 있는 방법은 다양합니다. 예를 들어, 그림 12를 살펴보세요. 그림 12: 데이터 가용성 문제 세 가지 블록이 있습니다. 이전 블록 A는 정직한 validators에 의해 생성되었습니다. 현재 B에는 validators가 공모하고 있습니다. 그리고 다음 C도 생산될 것이다. 정직한 validators(blockchain는 오른쪽 하단에 표시되어 있습니다). 당신은 상인입니다. 현재 블록(B)의 validators가 수신된 블록입니다. 이전 validators의 A는 귀하가 돈을 받는 블록을 계산했습니다.상태에 대한 Merkle 증명과 함께 해당 블록의 헤더를 보냈습니다. 당신은 돈이 있습니다 (또는 돈을 보내는 유효한 거래에 대한 머클 증명 당신에게). 거래가 완료되었음을 확신하고 서비스를 제공합니다. 그러나 validators는 블록 B의 전체 내용을 절대 배포하지 않습니다. 누구나. 따라서 블록 C의 정직한 validators는 블록을 검색할 수 없으며, 강제로 시스템을 정지시키거나 A 위에 구축해야 하므로 돈 상인. 동일한 시나리오를 샤딩에 적용할 때 전체 및 샤딩의 정의는 다음과 같습니다. 라이트 노드는 일반적으로 샤드별로 적용됩니다. 각 샤드의 validators는 매 다운로드마다 해당 샤드를 차단하고 해당 샤드의 모든 트랜잭션을 검증하지만 다른 스냅샷 샤드 체인 상태를 포함하는 시스템의 노드 비콘 체인의 경우 헤더만 다운로드하세요. 따라서 샤드의 validator은 다음과 같습니다. 해당 샤드의 노드를 사실상 가득 채우는 반면, 시스템의 다른 참가자는 비콘 체인을 포함하여 라이트 노드로 작동합니다. 위에서 논의한 어부 접근 방식의 경우 정직한 validators 비콘 체인에 교차 연결된 블록을 다운로드할 수 있어야 합니다. 악의적인 validators가 유효하지 않은 블록의 헤더를 교차 연결하거나 이를 사용하여 교차 샤드 트랜잭션을 시작하지만 블록을 배포하지는 않습니다. validators는 도전 과제를 만들 방법이 없습니다. 우리는 이 문제를 보완하는 세 가지 접근 방식을 다룰 것입니다. 서로. 2.5.1 양육권 증명 해결해야 할 가장 시급한 문제는 블록이 한 번만 사용 가능한지 여부입니다. 출판되었습니다. 제안된 아이디어 중 하나는 회전하는 소위 공증인을 갖는 것입니다. 유일한 작업이 다운로드인 validator보다 더 자주 샤드 사이에 다운로드할 수 있었다는 사실을 차단하고 증명합니다. 그들은 수 있습니다 전체 상태를 다운로드할 필요가 없기 때문에 더 자주 회전됩니다. 자주 회전할 수 없는 validator과 달리 샤드의 그림과 같이 샤드가 회전할 때마다 샤드의 상태를 다운로드해야 합니다. 13. 이 순진한 접근 방식의 문제점은 나중에 증명하는 것이 불가능하다는 것입니다. 공증인이 블록을 다운로드했는지 여부에 따라 공증인은 없이 블록을 다운로드할 수 있었다는 것을 항상 증명하도록 선택할 수 있습니다. 그것을 되찾으려고도 합니다. 이에 대한 한 가지 해결책은 공증인이 다음을 제공하는 것입니다. 어떤 증거를 확보하거나 블록이 다운로드되었습니다. 그러한 솔루션 중 하나가 여기에서 논의됩니다: https://ethresear.ch/t/ 1비트 집합 친화적 보관 채권/2236. 2.5.2 삭제 코드 특정 라이트 노드가 블록의 hash을 수신하면 노드의 라이트 노드를 늘리기 위해 블록이 사용 가능하다는 확신이 있으면 몇 가지 무작위 다운로드를 시도할 수 있습니다. 블록 조각. 이것은 완전한 해결책이 아닙니다. 왜냐하면 라이트 노드가 그렇지 않으면 악의적인 블록 생산자가 선택할 수 있는 전체 블록을 집합적으로 다운로드합니다.

그림 13: 유효성 검사기는 상태를 다운로드해야 하므로 회전할 수 없습니다. 자주 라이트 노드에 의해 다운로드되지 않은 블록 부분을 보류하기 위해, 따라서 여전히 블록을 사용할 수 없게 됩니다. 한 가지 해결책은 삭제 코드라는 구성을 사용하여 이를 가능하게 하는 것입니다. 그림과 같이 블록의 일부만 사용할 수 있는 경우에도 전체 블록을 복구하려면 그림 14에서. 그림 14: Merkle tree 삭제 코딩된 데이터 위에 구축됨 Polkadot 및 Ethereum Serenity는 모두 이 아이디어를 바탕으로 디자인했습니다. 라이트 노드가 블록을 사용할 수 있다고 합리적으로 확신할 수 있는 방법을 제공합니다. Ethereum Serenity 접근 방식은 [2]에 자세한 설명이 있습니다.2.5.3 데이터 가용성에 대한 Polkadot의 접근 방식 Polkadot에서는 대부분의 샤드 솔루션과 마찬가지로 각 샤드(파라체인이라고 함)가 비콘 체인(릴레이 체인이라고 함)에 해당 블록의 스냅샷을 찍습니다. 2f + 1이 있다고 가정해 보세요. 릴레이 체인의 validators. 파라체인 블록의 블록 생산자는 콜레이터, 일단 파라체인 블록이 생성되면 모든 f 부분이 충분하도록 2f +1 부분으로 구성된 블록의 삭제 코딩 버전을 계산합니다. 블록을 재구성합니다. 그런 다음 각 validator에 하나의 부품을 배포합니다. 릴레이 체인. 특정 릴레이 체인 validator은 릴레이 체인에만 서명합니다. 스냅샷된 각 파라체인 블록에 해당 부분이 있는 경우 블록을 차단합니다. 그러한 릴레이 체인 블록. 따라서 릴레이 체인 블록에 2f + 1의 서명이 있는 경우 validators, 그리고 그 중 f개 이상이 프로토콜을 위반하지 않는 한, 각각은 파라체인 블록은 validators에서 부품을 가져와서 재구성할 수 있습니다. 프로토콜을 따르는 것입니다. 그림 15를 참조하십시오. 그림 15: Polkadot의 데이터 가용성 2.5.4 장기적인 데이터 가용성 위에서 논의한 모든 접근 방식은 블록이 다음과 같다는 사실만 입증합니다. 전혀 게시되지 않았으며 현재 사용할 수 있습니다. 블록은 나중에 사용할 수 없게 될 수 있습니다. 다양한 이유: 노드가 오프라인 상태가 됨, 노드가 의도적으로 기록을 삭제함 데이터 및 기타. 이 문제를 해결하기 위해 언급할 가치가 있는 백서는 Polyshard [3]입니다. 여러 개의 블록이 있더라도 샤드 전체에서 블록을 사용할 수 있도록 삭제 코드를 사용합니다. 샤드는 데이터를 완전히 잃습니다. 불행하게도 그들의 특정 접근 방식에는 다음이 필요합니다. 모든 샤드는 다른 모든 샤드에서 블록을 다운로드해야 합니다. 비싸다. 장기적인 가용성은 문제만큼 시급하지 않습니다. 참가자가 없기 때문입니다. 시스템의 모든 체인을 검증할 수 있을 것으로 예상됩니다.

샤딩된 프로토콜의 보안은 다음과 같이 설계되어야 합니다. 일부 샤드의 일부 오래된 블록이 손상되더라도 시스템은 안전합니다. 전혀 사용할 수 없습니다.

Durum Geçerliliği ve Veri Kullanılabilirliği

Parçalanmış blockchain'lerdeki temel fikir, çoğu katılımcının işletim veya ağı kullanmak tüm parçalardaki blokları doğrulayamaz. Bu nedenle, ne zaman olursa olsun herhangi bir katılımcının genellikle yapamadığı belirli bir parçayla etkileşime girmesi gerekir Parçanın tüm geçmişini indirin ve doğrulayın. Bununla birlikte, parçalamanın bölümleme yönü önemli bir potansiyel ortaya çıkarmaktadır. sorun: belirli bir uygulamanın tüm geçmişini indirmeden ve doğrulamadan katılımcının parçanın bulunduğu durumdan mutlaka emin olması mümkün değildir. 5Bu bölüm, alt bölüm 2.5.3 hariç, daha önce https://near.ai/ adresinde yayınlanmıştır. parça2. Daha önce okuduysanız bir sonraki bölüme geçin.

etkileşime girmeleri bazı geçerli blok dizilerinin sonucudur ve bu dizi Blok sayısı gerçekten de parçadaki kanonik zincirdir. Çözülmeyen bir sorun parçalanmamış bir blockchain içinde mevcut. Öncelikle bu soruna önerilen basit bir çözüm sunacağız. birçok protokole göre analiz edin ve ardından bu çözümün nasıl bozulabileceğini ve ne olacağını analiz edin. giderilmesine yönelik girişimlerde bulunuldu. 2.1 Doğrulayıcıların rotasyonu Durum geçerliliğine yönelik saf çözüm şekil 5'te gösterilmektedir: diyelim ki tüm sistemde binlerce validators var, bunlardan %20'den fazlası kötü niyetli değildir veya başka şekilde başarısız olacaktır (örneğin, Bir blok oluşturmak için çevrimiçi). O zaman 200 validators örnek alırsak olasılık 1'den fazla 3 pratik amaçlar açısından başarısızlığın sıfır olduğu varsayılabilir. Şekil 5: Örnekleme validators 1 3 önemli bir eşik. Bir mutabakat protokolü ailesi var. BFT fikir birliği protokolleri; bu, 1'den az olduğu sürece bunu garanti eder 3'ü Katılımcılar ya kaza yaparak ya da kuralları ihlal eden bir şekilde hareket ederek başarısız olurlar. Protokolde fikir birliğine varılacak. Bu dürüst validator yüzdelik varsayımla, eğer mevcut Saf çözüm, bir parçadaki validators'nin bize bir miktar blok sağladığını varsayar bloğun geçerli olduğunu ve validators olduğuna inanılanlar üzerine inşa edildiğini doğrulamaya başladıklarında söz konusu parçanın standart zinciri. validator'lar kanonik zinciri önceki validators kümesinden öğrendi; Kanonik zincirin başı olan bloğun üzerine inşa edilen varsayım ondan önce. Tümevarımla zincirin tamamı geçerlidir ve validators kümesi olmadığından Çatal üretilen herhangi bir noktada, naif çözüm aynı zamanda mevcut olanın da kesin olduğudur. zincir, parçadaki tek zincirdir. Görselleştirme için şekil 6'ya bakın.

Şekil 6: Her bloğun BFT fikir birliğiyle sonlandırıldığı bir blockchain validators'nin olabileceğini varsayarsak bu basit çözüm işe yaramaz. uyumsal olarak bozulmuştur ki bu mantıksız bir varsayım değildir6. Uyarlanabilir 1000 parçadan oluşan bir sistemde tek bir parçayı bozmak çok daha ucuzdur tüm sistemi bozmak yerine. Bu nedenle protokolün güvenliği, parça sayısı arttıkça doğrusal olarak azalır. Geçerliliğinden emin olmak için bir blok, tarihin herhangi bir noktasında sistemdeki hiçbir parçanın olmadığını bilmeliyiz. validator'ların çoğunluğu gizli anlaşma yapıyor; uyarlanabilir düşmanlarla artık elimizde değil öyle bir kesinlik ki. Bölüm 1.5'te tartıştığımız gibi, validators ile gizli anlaşma yapmak işe yarayabilir iki temel kötü niyetli davranış: çatallar oluşturmak ve geçersiz bloklar üretmek. Kötü niyetli çatallanmalar, blokların genel olarak diğerlerine göre önemli ölçüde daha yüksek güvenliğe sahip olacak şekilde tasarlanan Beacon zincirine çapraz bağlanmasıyla ele alınabilir. kırık zincirler. Geçersiz bloklar üretmek ise önemli ölçüde daha fazla bir sorundur. üstesinden gelinmesi zor bir sorun. 2.2 Durum Geçerliliği 1. Parçanın bozulduğu ve kötü niyetli bir aktörün ürettiği Şekil 7'yi düşünün. geçersiz blok B. Diyelim ki bu B bloğunda 1000 tokens yoktan basıldı Alice'in hesabında yayın. Kötü niyetli aktör daha sonra geçerli C bloğunu üretir (bir C'deki işlemlerin doğru bir şekilde uygulandığını hissetmek) B'nin yanı sıra kafa karıştırıcı geçersiz B bloğunu kullanır ve Parça #2'ye bir çapraz parça işlemi başlatır. bu 1000 tokens'yi Bob'un hesabına aktarır. Bu andan itibaren uygunsuz bir şekilde oluşturulan token'ler, Parça #2'deki tamamen geçerli bir blockchain üzerinde bulunuyor. Bu sorunu çözmeye yönelik bazı basit yaklaşımlar şunlardır: 6Oku bu makale için ayrıntılar üzerinde nasıl uyarlanabilir yolsuzluk yapabilir olmak taşınan dışarı: https://medium.com/nearprotocol/d859adb464c8. için daha fazla ayrıntılar üzerinde uyarlanabilir yolsuzluk, okumak https://github.com/ethereum/wiki/wiki/Sharding-FAQ# altında-çalıştığımız-güvenlik modelleri nelerdirŞekil 7: Geçersiz bloğu olan bir zincirden gelen parçalar arası işlem 1. İşlemin yapıldığı bloğu doğrulamak amacıyla validators Parça #2 için başlatılır. Bu yukarıdaki örnekte bile işe yaramayacaktır çünkü C bloğu tamamen geçerli olduğu görülmektedir. 2. İşlemin başlatıldığı bloktan önceki çok sayıda bloğu doğrulamak için Parça #2'deki validators için. Doğal olarak, kötü niyetli alıcı parça tarafından doğrulanan herhangi bir sayıda blok N validators, geçersiz bloğun üstünde N+1 geçerli blok oluşturabilir üretildi. Bu sorunu çözmek için umut verici bir fikir, parçaları bir düzende düzenlemek olacaktır. her bir parçanın diğer birkaç parçaya bağlandığı yönlendirilmemiş grafik ve yalnızca komşu parçalar arasında çapraz parça işlemlerine izin ver (ör. Vlad Zamfir'in parçalaması esasen işe yarıyor7 ve benzer fikir Kadena'nınkinde de kullanılıyor Chainweb [1]). Parçalar arasında parçalar arası bir işlem gerekiyorsa komşular değil, bu tür işlemler birden fazla parça aracılığıyla yönlendirilir. Bu tasarımda Her bir parçadaki bir validator'nin, kendi parçalarındaki tüm blokları doğrulaması bekleniyor ve ayrıca tüm komşu parçalardaki tüm bloklar. Aşağıdaki şekli düşünün 10 parçadan oluşan, her birinin dört komşusu olan ve daha fazlasını gerektiren iki parçanın olmadığı Şekil 8'de gösterilen çapraz parça iletişimi için ikiden fazla atlama. Parça #2 yalnızca kendi blockchain parçasını değil aynı zamanda blockchain parçasını da doğruluyor 1 numaralı Parça dahil tüm komşular. Yani Parça #1'de kötü niyetli bir aktör varsa geçersiz bir B bloğu oluşturmaya çalışıyor, ardından bunun üzerine C bloğunu inşa ediyor ve parçalar arası bir işlem başlatın, bu tür parçalar arası işlem gerçekleşmeyecek Parça #2'den beri Parça #1'in tüm geçmişi doğrulanmış olacak. geçersiz B bloğunu tanımlamasına neden olacaktır. 7Tasarım hakkında daha fazla bilgiyi burada bulabilirsiniz: https://medium.com/nearprotocol/37e538177ed9

Şekil 8: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmek Tek bir parçayı bozmak artık geçerli bir saldırı olmasa da, bir parçayı bozmak artık geçerli bir saldırı değildir. birkaç parça sorun olmaya devam ediyor. Şekil 9'da bir düşman her iki Shard'ı da bozuyor

1 ve Parça #2, Parça #3'e yönelik bir çapraz parça işlemini başarıyla yürütür

geçersiz bir B bloğundan gelen fonlarla: Şekil 9: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmemek Parça #3, Parça #2'deki tüm blokları doğrular ancak Parça #1'deki tüm blokları doğrular ve kötü amaçlı bloğu tespit etmenin bir yolu yoktur. Durum geçerliliğini doğru şekilde çözmenin iki ana yönü vardır: balıkçılar

ve hesaplamanın kriptografik kanıtları. 2.3 Balıkçı İlk yaklaşımın arkasındaki fikir şudur: ne zaman bir blok başlığı Herhangi bir amaç için zincirler arasında iletilir (örneğin çapraz bağlanma gibi). işaret zinciri veya parçalar arası bir işlem), bu sırada belirli bir süre vardır dürüst herhangi bir validator bloğun geçersiz olduğuna dair kanıt sağlayabilir. Orada blokların çok kısa ve öz kanıtlarını sağlayan çeşitli yapılardır. geçersiz olduğundan alıcı düğümlerin iletişim yükü çok daha küçüktür tam bir blok almaktan daha fazla. En az bir dürüst validator olduğu sürece bu yaklaşımla Shard, sistem güvenlidir. Şekil 10: Balıkçı Bu, bugün önerilen protokoller arasında (sorun yokmuş gibi davranmanın yanı sıra) baskın yaklaşımdır. Ancak bu yaklaşımın iki önemli dezavantajlar: 1. Dürüst validator için meydan okuma süresinin yeterince uzun olması gerekir Bir bloğun üretildiğini tanımak, onu indirmek, tamamen doğrulamak ve hazırlamak blok geçersizse meydan okuma. Böyle bir dönemin getirilmesi Parçalar arası işlemleri önemli ölçüde yavaşlatır. 2. Challenge protokolünün varlığı yeni bir saldırı vektörü yaratıyor Kötü niyetli düğümler geçersiz sorgulamalarla spam yaptığında. Açık bir çözüm Bu sorunun çözümü, meydan okuyanların bir miktar tokens yatırmasını sağlamaktır. meydan okuma geçerliyse iade edilir. Bu yalnızca kısmi bir çözümdür, çünkü saldırganın sisteme spam göndermesi (ve yakması) yine de faydalı olabilir. örneğin geçerli işlemleri engellemek için geçersiz sorgulamalarla yapılan para yatırma işlemleri)dürüst bir validator'dan gelen meydan okuma. Bu saldırılar Kederli Saldırılar denir. İkinci noktayı aşmanın bir yolu için bölüm 3.7.2'ye bakın. 2.4 Kısa ve Etkileşimli Olmayan Bilgi Argümanları Çoklu parça bozulmasına karşı ikinci çözüm, belirli bir hesaplamanın (örneğin, bir dizi işlemden bir bloğun hesaplanması gibi) doğru bir şekilde gerçekleştirildi. Bu tür yapılar mevcuttur; zk-SNARK'lar, zk-STARK'lar ve birkaç kişi daha, ve bazıları bugün blockchain protokollerinde özel ödemeler için aktif olarak kullanılıyor, en önemlisi ZCash. Bu tür ilkellerle ilgili temel sorun, onların hesaplamanın oldukça yavaş olduğu biliniyor. Örn. zk-SNARK'ları kullanan Coda Protokolü özellikle blockchain içindeki tüm blokların geçerli olduğunu kanıtlamak için, birinde söylendi Kanıt oluşturmanın işlem başına 30 saniye sürebileceği görüşmelerden (bu sayı muhtemelen şimdiye kadar daha küçüktür). İlginç bir şekilde, bir kanıtın güvenilir bir tarafça hesaplanmasına gerek yoktur, çünkü Kanıt yalnızca oluşturulduğu hesaplamanın geçerliliğini kanıtlamakla kalmaz, aynı zamanda kanıtın kendisinin geçerliliği. Dolayısıyla bu tür kanıtların hesaplanması bölünebilir önemli ölçüde daha az yedekliliğe sahip bir grup katılımcı arasında bazı güvenilir hesaplamalar yapmak için gereklidir. Aynı zamanda katılımcıların zk-SNARK'ları özel donanım üzerinde çalışacak şekilde hesaplayanlar sistemin ademi merkeziyetçiliği. zk-SNARK'ların performansın yanı sıra karşılaştığı zorluklar şunlardır: 1. Daha az araştırılmış ve daha az zaman içinde test edilmiş kriptografik temellere bağımlılık; 2. “Zehirli atık” — zk-SNARK'lar, bir grubun içinde bulunduğu güvenilir bir kuruluma bağlıdır İnsanların oranı bir miktar hesaplama yapıyor ve ardından ara hesaplamayı atıyor bu hesaplamanın değerleri. Prosedürün tüm katılımcıları gizli anlaşma yaparsa ve ara değerleri koruyarak sahte deliller oluşturulabilir; 3. Sistem tasarımına eklenen ekstra karmaşıklık; 4. zk-SNARK'lar yalnızca olası hesaplamaların bir alt kümesi için çalışır, dolayısıyla bir protokol Turing-complete smart contract dilini kullanamazsınız Zincirin geçerliliğini kanıtlamak için SNARK'lar. 2.5 Veri Kullanılabilirliği Değineceğimiz ikinci sorun veri kullanılabilirliğidir. Genellikle düğümler belirli bir blockchain çalıştıran iki gruba ayrılır: Tam Düğümler, her tam bloğu indiren ve her işlemi doğrulayanlar ve Light Yalnızca blok başlıklarını indiren ve parçalar için Merkle kanıtlarını kullanan düğümler Şekil 11'de gösterildiği gibi ilgilendikleri durum ve işlemler.

Şekil 11: Merkle Ağacı Artık tam düğümlerin çoğunluğu gizli anlaşma yaparsa geçerli veya geçerli bir blok üretebilirler. geçersizdir ve hash dosyasını hafif düğümlere gönderin, ancak içeriğin tamamını hiçbir zaman açıklamayın bloğun. Bundan faydalanabilecekleri çeşitli yollar vardır. Örneğin, Şekil 12'yi düşünün: Şekil 12: Veri Kullanılabilirliği sorunu Üç blok vardır: önceki A, dürüst validators tarafından üretilmiştir; mevcut B'nin validators gizli anlaşması var; ve bir sonraki C de üretilecek dürüst validators tarafından (blockchain sağ alt köşede gösterilmektedir). Sen bir tüccarsın. Geçerli bloğun (B) validator'leri alınan blok Önceki validator'lerden A, içinde para aldığınız bir blok hesapladı,ve size o bloğun başlığını, içinde bulunulan durumun Merkle kanıtıyla birlikte gönderdim. paranız var (veya parayı gönderen geçerli bir işlemin Merkle kanıtı) sana). İşlemin tamamlandığından emin olduğunuzda hizmeti sağlarsınız. Ancak validator'ler hiçbir zaman B bloğunun tam içeriğini dağıtmaz. herhangi biri. Bu nedenle, C bloğunun dürüst validator'leri bloğu geri alamaz ve ya sistemi durdurmaya zorlanırlar ya da A'nın üzerine inşa ederek sizi bir sistem olarak mahrum bırakırlar. para tüccarı. Aynı senaryoyu parçalamaya uyguladığımızda tam ve hafif düğüm genellikle parça başına uygulanır: her parça indirmesinde validators o parçada bloke edin ve o parçadaki her işlemi doğrulayın, ancak diğer parça zincirlerinin anlık görüntüsünü alan düğümler de dahil olmak üzere sistemdeki düğümler işaret zinciri, yalnızca başlıkları indirin. Böylece parçadaki validator'ler sistemdeki diğer katılımcılar bu parça için etkili bir şekilde tam düğümler oluştururken, işaret zinciri de dahil olmak üzere ışık düğümleri olarak çalışır. Yukarıda tartıştığımız balıkçı yaklaşımının işe yaraması için dürüst validators işaret zincirine çapraz bağlı blokları indirebilmeniz gerekir. Kötü niyetli validator'ler geçersiz bir bloğun başlığını çapraz bağladıysa (veya bunu kullandıysa) parçalar arası bir işlem başlatır), ancak bloğu asla dağıtmaz, dürüst validator'lerin bir meydan okuma oluşturmanın hiçbir yolu yok. Bu sorunu çözmek için birbirini tamamlayan üç yaklaşımı ele alacağız. Birbirimiz. 2.5.1 Velayet Kanıtları Çözülmesi gereken en acil sorun, bir bloğun bir kez kullanılabilir olup olmadığıdır. yayınlandı. Önerilen fikirlerden biri dönüşümlü Noterlere sahip olmaktır. tek işi bir dosya indirmek olan validator'lerden daha sık parçalar arasında engelleyin ve indirebildiklerini doğrulayın. Onlar olabilir tüm durumu indirmeleri gerekmediği için daha sık dönüşümlü olarak kullanılıyor parçanın aksine, sık sık döndürülemeyen validator'lerin aksine şekilde gösterildiği gibi her döndüklerinde parçanın durumunu indirmeleri gerekir 13. Bu naif yaklaşımın sorunu daha sonra kanıtlamanın imkansız olmasıdır. Noterin bloğu indirip indiremediğine bağlı olarak Noter bloğu indirebildiklerini her zaman onaylamayı seçebilirler. hatta onu geri almaya çalışıyorum. Bunun bir çözümü Noterlerin sağlamasıdır. bloğun olduğunu kanıtlayan bazı kanıtlar veya bir miktar tokens stake etmek indirildi. Böyle bir çözüm burada tartışılmaktadır: https://ethresear.ch/t/ 1 bitlik toplama dostu saklama tahvilleri/2236. 2.5.2 Silme Kodları Belirli bir ışık düğümü bir bloğun hash değerini aldığında, düğümün Bloğun mevcut olduğundan emin olmak için rastgele birkaç tane indirmeyi deneyebilir bloğun parçaları. Bu tam bir çözüm değil çünkü ışık düğümleri Kötü niyetli blok üreticilerinin seçebileceği bloğun tamamını toplu olarak indirin

Şekil 13: Doğrulayıcıların durumu indirmesi gerekir ve bu nedenle döndürülemez sık sık bloğun herhangi bir ışık düğümü tarafından indirilmeyen kısımlarını alıkoymak, böylece bloğu hala kullanılamaz hale getiriyoruz. Çözümlerden biri, bunu mümkün kılmak için Silme Kodları adı verilen bir yapıyı kullanmaktır. gösterildiği gibi bloğun yalnızca bir kısmı mevcut olsa bile tüm bloğu kurtarmak için Şekil 14'te. Şekil 14: Merkle tree silme kodlu veriler üzerine inşa edilmiştir Hem Polkadot hem de Ethereum Serenity'nin tasarımları bu fikir etrafında şekilleniyor: Hafif düğümlerin blokların mevcut olduğundan makul ölçüde emin olmaları için bir yol sağlar. Ethereum Serenity yaklaşımının ayrıntılı açıklaması [2]'da bulunmaktadır.2.5.3 Polkadot'nin veri kullanılabilirliğine yaklaşımı Polkadot'de, çoğu parçalı çözümde olduğu gibi, her parça (parachain olarak adlandırılır) bloklarının anlık görüntüsünü işaret zincirine (aktarma zinciri olarak adlandırılır) alır. Diyelim ki 2f + 1 var Aktarma zincirinde validators. Parachain bloklarının blok üreticileri, harmanlayıcılar, parachain bloğu üretildiğinde, herhangi bir f parçası yeterli olacak şekilde 2f +1 parçadan oluşan bloğun silme kodlu versiyonunu hesaplarlar. bloğu yeniden inşa etmek için. Daha sonra her validator'e bir parça dağıtırlar. röle zinciri. Belirli bir geçiş zinciri validator yalnızca bir geçiş zincirinde imza atar anlık görüntüsü alınan her parachain bloğu için kendi paylarına sahiplerse bloklayın böyle bir röle zinciri bloğu. Dolayısıyla, eğer bir aktarma zinciri bloğu 2f + 1'den imzalara sahipse validators ve bunlardan en fazla f tanesi protokolü ihlal etmediği sürece, her biri parachain bloğu validators'den parçalar alınarak yeniden oluşturulabilir protokolü takip edenler. Bkz. şekil 15. Şekil 15: Polkadot'nin veri kullanılabilirliği 2.5.4 Uzun vadeli veri kullanılabilirliği Yukarıda tartışılan tüm yaklaşımların yalnızca bir bloğun olduğu gerçeğini doğruladığını unutmayın. yayınlandı ve şu anda mevcut. Bloklar daha sonra kullanılamayabilir çeşitli nedenlerden dolayı: düğümlerin devre dışı kalması, düğümlerin kasıtlı olarak geçmişi silmesi veriler ve diğerleri. Bu sorunu ele alan bahsetmeye değer bir teknik inceleme Polyshard [3]'dir, birden fazla parça olsa bile blokların parçalar arasında kullanılabilir olmasını sağlamak için silme kodlarını kullanan Parçalar verilerini tamamen kaybeder. Ne yazık ki onların özel yaklaşımı şunu gerektirir: diğer tüm parçalardan blok indirmek için tüm parçalar, bu da yasaklayıcı bir şekilde pahalı. Uzun vadeli kullanılabilirlik o kadar acil bir sorun değil: hiçbir katılımcı olmadığı için Sistemin tüm zincirlerdeki tüm zincirleri doğrulayabilmesi bekleniyor.

Parçalanmış protokollerin güvenliğinin böyle bir şekilde tasarlanması gerekir. bazı parçalardaki bazı eski bloklar bozulsa bile sistemin güvenli kalmasının bir yolu tamamen kullanılamaz.

Nightshade

3.1 샤드 체인에서 샤드 청크로 샤드체인과 비콘체인을 이용한 샤딩 모델은 매우 강력하지만 특정 복잡성이 있습니다. 특히 포크 선택 규칙을 실행해야 합니다. 각 체인에서 별도로 샤드 체인과 비콘의 포크 선택 규칙 체인은 다르게 구축하고 별도로 테스트해야 합니다. Nightshade에서 우리는 시스템을 단일 blockchain로 모델링합니다. 블록은 논리적으로 모든 샤드에 대한 모든 트랜잭션을 포함하고 모든 샤드의 전체 상태. 그러나 물리적으로 참가자 중 누구도 다운로드하지 않습니다. 전체 상태 또는 전체 논리 블록. 대신, 네트워크의 각 참가자는 트랜잭션을 검증하는 샤드에 해당하는 상태를 유지하며, 블록의 모든 트랜잭션 목록은 물리적으로 분할됩니다. 청크, 샤드당 하나의 청크. 이상적인 조건에서 각 블록은 샤드당 정확히 하나의 청크를 포함합니다. 이는 샤드 체인이 있는 모델과 대략적으로 일치합니다. 샤드 체인은 비콘 체인과 동일한 속도로 블록을 생성합니다. 그러나, 네트워크 지연으로 인해 일부 청크가 누락될 수 있으므로 실제로는 각 블록이 샤드당 1개 또는 0개의 청크를 포함합니다. 방법에 대한 자세한 내용은 섹션 3.3을 참조하세요. 블록이 생산됩니다. 그림 16: 왼쪽에 샤드 체인이 있고 하나의 체인에 샤드 체인이 있는 모델 블록은 오른쪽의 덩어리로 분할됩니다.

3.2 합의 오늘날 blockchains의 합의에 대한 두 가지 지배적인 접근 방식은 가장 긴(또는 가장 무거운) 체인, 가장 많은 작업이나 스테이크가 있는 체인 이를 구축하는 데 사용된 것은 정식으로 간주되며 BFT, 각 블록에 대해 validator 세트는 BFT 합의에 도달합니다. 최근 제안된 프로토콜에서는 후자가 더 지배적인 접근 방식입니다. 즉각적인 최종성을 제공하는 반면 가장 긴 체인에서는 더 많은 블록이 필요하기 때문입니다. 최종성을 보장하기 위해 블록 위에 구축됩니다. 종종 의미 있는 일을 위해 보안상 충분한 수의 블록을 구축하는 데 걸리는 시간은 시간 순서. 각 블록에서 BFT 합의를 사용하면 다음과 같은 단점도 있습니다. 1. BFT 합의에는 상당한 양의 의사소통이 필요합니다. 동안 최근의 발전으로 선형적인 시간 내에 합의에 도달할 수 있게 되었습니다. 참가자 수(예: [4] 참조)에서는 여전히 블록당 오버헤드가 눈에 띕니다. 2. 모든 네트워크 참여자가 BFT에 참여하는 것은 불가능합니다. 블록당 합의에 도달하므로 일반적으로 무작위로 샘플링된 참가자 하위 집합만 합의에 도달합니다. 무작위로 추출된 세트는 원칙적으로 다음과 같습니다. 적응적으로 손상되고 이론적으로는 포크가 생성될 수 있습니다. 시스템 그러한 이벤트에 대비하려면 모델링이 필요하므로 여전히 BFT 합의 외에 포크 선택 규칙이 있거나 폐쇄되도록 설계되었습니다. 이런 경우에는 다운됩니다. 다음과 같은 일부 디자인을 언급할 가치가 있습니다. Algorand [5], 적응형 손상 가능성을 크게 줄입니다. 3. 가장 중요한 것은 다음과 같은 경우 시스템이 정지된다는 것입니다. 전체 참가자 중 3명 이상이 오프라인. 따라서 일시적인 네트워크 결함이나 네트워크 분할로 인해 시스템이 완전히 정지될 수 있습니다. 이상적으로 시스템은 계속해서 작동할 수 있어야 합니다. 참가자 중 최소 절반이 온라인 상태인 한(가장 무거운 체인 기반 프로토콜은 참가자의 절반 미만이 온라인 상태인 경우에도 계속 작동하지만 이 속성의 바람직성은 더 논쟁의 여지가 있습니다. 커뮤니티 내에서). 사용된 합의가 일종의 가장 무거운 하이브리드 모델 체인이지만 일부 블록은 BFT 최종성 가젯을 사용하여 주기적으로 마무리되며 두 모델의 장점을 모두 유지합니다. 이러한 BFT 최종 가젯은 Casper FFG [6]는 Ethereum 2.0 8, Casper CBC에서 사용됩니다(https://vitalik. 참조). ca/general/2018/12/05/cbc_casper.html) 및 GRANDPA(https:// Medium.com/polkadot-network/d08a24a021b5) Polkadot에서 사용됩니다. Nightshade는 가장 무거운 체인 합의를 사용합니다. 특히 블록일 때 생산자는 블록을 생성하고(섹션 3.3 참조) 다음에서 서명을 수집할 수 있습니다. 다른 블록 생산자와 이전 블록을 증명하는 validators. 섹션을 참조하세요 이렇게 많은 수의 서명이 어떻게 집계되는지 자세히 알아보려면 3.8을 참조하세요. 무게 8Casper에 대한 심층적인 개요는 Justin Drake와의 화이트보드 세션도 참조하세요. FFG 및 이것이 GHOST의 가장 무거운 체인 합의와 통합되는 방법은 다음과 같습니다: https://www. youtube.com/watch?v=S262StTwkmo블록의 서명은 다음과 같은 서명을 가진 모든 서명자의 누적 지분입니다. 블록에 포함됩니다. 체인의 무게는 블록 무게의 합입니다. 가장 무거운 체인 합의 위에 우리는 다음을 사용하는 최종 장치를 사용합니다. 블록을 마무리하기 위한 증명입니다. 시스템의 복잡성을 줄이기 위해, 우리는 포크 선택 규칙에 어떤 식으로든 영향을 주지 않는 최종 장치를 사용합니다. 대신 추가 슬래싱 조건만 도입합니다. 최종 가젯으로 마무리된 경우 매우 큰 비율이 아니면 포크는 불가능합니다. 전체 지분 중 삭감됩니다. Casper CBC는 그러한 최종 장치이며 우리는 현재 Casper CBC를 염두에 두고 모델을 만들고 있습니다. 우리는 또한 TxFlow라는 별도의 BFT 프로토콜을 개발하고 있습니다. 당시 이 문서를 작성하면 Casper 대신 TxFlow가 사용될지 확실하지 않습니다. CBC. 그러나 우리는 최종 가젯의 선택이 나머지 설계와 대체로 직교한다는 점에 주목합니다. 3.3 블록 생산 Nightshade에는 블록 생산자와 validator라는 두 가지 역할이 있습니다. 언제든지 시스템에 w개의 블록 생산자가 포함되어 있고, 우리 모델에서는 w = 100이며, wv validators, 우리 모델에서는 v = 100, wv = 10, 000입니다. 시스템은 지분 증명입니다. 이는 블록 생산자와 validator 모두 내부에 일정 수의 내부 정보가 있음을 의미합니다. 통화("tokens"라고 함)는 해당 통화를 훨씬 초과하는 기간 동안 잠겨 있습니다. 체인을 구축하고 검증하는 임무를 수행하는 데 소요되는 시간입니다. 모든 지분 증명 시스템과 마찬가지로, 모든 w 블록 생산자가 아니라 모든 wv validator은 시행할 수 없기 때문에 다른 엔터티입니다. 각각 그러나 w 블록 생산자와 wv validators는 별도의 스테이크. 시스템에는 n개의 샤드가 포함되어 있으며 모델에서는 n = 1000입니다. 에서 언급했듯이 섹션 3.1, Nightshade에는 샤드 체인이 없습니다. 대신 모든 블록 생산자와 validator가 단일 blockchain를 구축하고 있습니다. 메인 체인. 메인체인의 상태는 n개의 샤드로 분할되며, 각 블록은 producer 및 validator은 언제든지 로컬에 하위 집합만 다운로드했습니다. 샤드의 일부 하위 집합에 해당하는 상태이며, 처리 및 주의 해당 부분에 영향을 미치는 거래를 검증합니다. 블록 생산자가 되기 위해 네트워크 참가자는 일부 대규모 잠금을 설정합니다. tokens(스테이크)의 양. 네트워크의 유지 관리는 시대별로 이루어집니다. 여기서 에포크는 일 단위의 기간입니다. 참가자 특정 시대가 시작될 때 가장 큰 지분을 가진 블록은 다음과 같습니다. 그 시대의 생산자. 각 블록 생산자는 sw 샤드에 할당됩니다(예: sw = 40, 즉 샤드당 sww/n = 4명의 블록 생산자가 됩니다. 블록 생산자는 에포크 이전에 할당된 샤드의 상태를 다운로드합니다. 시작되고 에포크 전반에 걸쳐 해당 샤드에 영향을 미치는 트랜잭션을 수집합니다. 그리고 이를 국가에 적용합니다. 메인 체인의 각 블록 b와 모든 샤드 s에 대해 다음 중 하나가 있습니다. b 관련 부분을 생산할 책임이 있는 블록 생산자를 s에게 할당했습니다. 샤드에. 샤드 s와 관련된 b 부분을 청크라고 하며 다음을 포함합니다. b에 포함될 샤드에 대한 트랜잭션 목록과 머클결과 상태의 루트. b는 궁극적으로 매우 작은 헤더만 포함하게 됩니다. 청크, 즉 적용된 모든 트랜잭션의 머클 루트(섹션 참조) 정확한 세부 사항은 3.7.1 참조) 및 최종 상태의 머클 루트입니다. 문서의 나머지 부분에서 우리는 종종 블록 생산자를 언급합니다. 특정 샤드에 대해 특정 시간에 청크를 생성하는 역할을 담당합니다. 청크 프로듀서로서. 청크 생산자는 항상 블록 생산자 중 하나입니다. 블록 생산자와 청크 생산자는 각 블록을 다음과 같이 회전합니다. 정해진 일정으로. 블록 생산자는 주문을 받고 반복적으로 생산을 합니다. 그 순서대로 블록을 쌓으세요. 예: 블록 생산자가 100명이면 첫 번째 블록은 생산자는 블록 1, 101, 201 등을 생산할 책임이 있으며, 두 번째는 2, 102, 202 등 생산 담당). 청크 생산은 블록 생산과 달리 유지 관리가 필요하므로 상태를 유지하며, 각 샤드에 대해 sww/n 블록 생산자만이 상태를 유지합니다. 샤드별로 해당 sww/n 블록 생산자만 순환하여 생성합니다. 덩어리. 예: 위의 상수와 4명의 블록 생산자가 할당되어 있습니다. 각 샤드, 각 블록 생산자는 4개의 블록마다 한 번씩 청크를 생성합니다. 3.4 데이터 가용성 보장 데이터 가용성을 보장하기 위해 우리는 Polkadot과 유사한 접근 방식을 사용합니다. 섹션 2.5.3에 설명되어 있습니다. 블록 생산자가 청크를 생성하면 다음을 생성합니다. 최적의 (w, ⌊w/6 + 1⌋) 블록 코드를 사용하여 삭제 코딩된 버전 덩어리. 그런 다음 삭제 코딩된 청크의 한 조각을 보냅니다(우리는 이러한 조각을 호출합니다). 청크 부분 또는 부분)을 각 블록 생산자에게 전달합니다. 우리는 나뭇잎과 같은 모든 부분을 포함하는 머클 트리를 계산합니다. 각 청크의 헤더에는 해당 트리의 머클 루트가 포함됩니다. 부품은 onepart 메시지를 통해 validators로 전송됩니다. 그런 메시지 하나하나 청크 헤더, 부분의 서수 및 부분 내용을 포함합니다. 는 메시지에는 해당 블록을 생성한 블록 생산자의 서명도 포함되어 있습니다. 해당 부분이 헤더에 해당함을 증명하기 위한 청크와 머클 경로 그리고 적절한 블록 생산자에 의해 생산됩니다. 블록 생산자가 메인 체인 블록을 받으면 먼저 블록 생성 여부를 확인합니다. 블록에 포함된 각 청크에 대해 하나의 메시지를 가집니다. 그렇지 않으면 블록 누락된 onepart 메시지가 검색될 때까지 처리되지 않습니다. 모든 onepart 메시지가 수신되면 블록 생산자는 피어로부터 남은 부분을 가져와 그들이 보유하고 있는 청크를 재구성합니다. 상태. 블록 생산자는 메인 체인 블록을 처리하지 않습니다. 블록에 포함된 청크에는 해당 onepart 메시지가 없거나 상태를 유지하는 하나 이상의 샤드에 대해 사용할 수 없는 경우 전체 청크를 재구성합니다. 특정 청크를 사용하려면 블록의 ⌊w/6⌋+1이면 충분합니다. 생산자는 자신의 역할을 갖고 이를 제공합니다. 따라서, 그 수만큼은 악의적인 행위자는 블록이 절반 이상인 체인이 없는 ⌊w/3⌋을 초과하지 않습니다. 그것을 만드는 생산자는 사용할 수 없는 청크를 가질 수 있습니다.그림 17: 각 블록에는 샤드당 1개 또는 0개의 청크가 포함되어 있으며, 각 청크는 삭제 코딩되어 있습니다. 삭제 코딩된 청크의 각 부분은 지정된 위치로 전송됩니다. 특별한 onepart 메시지를 통한 블록 생산자 3.4.1 게으른 블록 생산자 다루기 블록 생산자가 한 부분 메시지가 누락된 블록을 가지고 있는 경우, 블록이 체인에 연결되면 계속 서명하기로 선택할 수 있습니다. 블록 생산자에 대한 보상을 극대화할 것입니다. 블록에 대한 위험이 없습니다 왜냐하면 블록 프로듀서가 블록 프로듀서를 갖고 있지 않았다는 것을 나중에 증명하는 것이 불가능하기 때문입니다. 한 부분 메시지. 이 문제를 해결하기 위해 청크를 생성할 때 각 청크 생산자를 만듭니다. 향후 인코딩된 청크의 각 부분에 대해 색상(빨간색 또는 파란색)을 선택하고 저장합니다. 인코딩되기 전 청크에 할당된 색상의 비트마스크입니다. 각 부분 메시지에는 부품에 할당된 색상이 포함되며, 색상은 다음과 같은 경우에 사용됩니다. 인코딩된 부분의 머클 루트를 계산합니다. 청크 생산자가 이탈하는 경우 머클 루트는 그렇지 않기 때문에 프로토콜에서 쉽게 증명할 수 있습니다. onepart 메시지에 해당하거나, onepart 메시지의 색상에 해당합니다. 머클 루트에 해당하는 것은 청크의 마스크와 일치하지 않습니다. 블록 생산자가 블록에 서명하면 모든 블록의 비트마스크가 포함됩니다. 블록에 포함된 청크에 대해 받은 빨간색 부분입니다. 게시 잘못된 비트마스크는 슬래시 가능한 동작입니다. 블록 생산자가 메시지를 받지 못한 경우 메시지를 한 부분으로만 읽어도 메시지의 색상을 알 수 없습니다. 따라서 맹목적으로 서명을 시도하면 베임을 당할 확률이 50%입니다. 블록. 3.5 상태 전이 신청 청크 생산자는 청크에 포함할 트랜잭션만 선택하지만 청크를 생성할 때 상태 전환을 적용하지 마십시오. 이에 따라,

청크 헤더에는 이전의 머켈화된 상태의 머클 루트가 포함되어 있습니다. 청크의 트랜잭션이 적용됩니다. 트랜잭션은 청크를 포함하는 전체 블록에만 적용됩니다. 처리됩니다. 참가자는 다음의 경우에만 블록을 처리합니다. 1. 이전 블록이 수신되어 처리되었습니다. 2. 각 청크에 대해 참가자는 자신이 가지고 있는 상태를 유지하지 않습니다. onepart 메시지를 보았습니다. 3. 각 청크에 대해 참가자는 상태를 유지합니다. 전체 덩어리. 블록이 처리되면 참가자가 사용하는 각 샤드에 대해 상태를 유지하고 트랜잭션을 적용하고 새로운 상태를 계산합니다. 거래가 적용된 후부터 생산 준비가 완료됩니다. 다음 블록의 청크(샤드에 할당된 경우) 새로운 머켈화된 상태의 머클 루트. 3.6 교차 샤드 거래 및 영수증 트랜잭션이 둘 이상의 샤드에 영향을 미쳐야 하는 경우 연속적으로 수행되어야 합니다. 각 샤드에서 개별적으로 실행됩니다. 전체 트랜잭션이 첫 번째 샤드로 전송됩니다. 영향을 받고 트랜잭션이 해당 샤드의 청크에 포함되면 청크가 블록에 포함된 후 적용되면 소위 영수증이 생성됩니다. 트랜잭션이 필요한 다음 샤드로 라우팅됩니다. 처형되다. 추가 단계가 필요한 경우 영수증 거래 실행 새로운 영수증 거래 등을 생성합니다. 3.6.1 영수증 거래 수명 영수증 거래는 해당 거래가 발생한 블록 바로 다음 블록에 적용하는 것이 바람직하다. 영수증 거래는 블록 생산자가 이전 블록을 수신하고 적용한 후에 생성됨 원래 샤드를 유지하고 샤드가 생성될 때까지 알려져야 합니다. 다음 블록의 청크는 대상의 블록 생산자가 생성합니다. 파편. 따라서 영수증은 소스 샤드에서 샤드에 전달되어야 합니다. 두 이벤트 사이의 짧은 시간 내에 대상 샤드를 생성합니다. A를 영수증 r을 생성하는 트랜잭션 t를 포함하는 마지막으로 생성된 블록이라고 가정합니다. B를 다음으로 생성된 블록(즉, A를 갖는 블록)이라고 가정합니다. 이전 블록)에 r을 포함하려고 합니다. t가 샤드 a와 r에 있도록 하세요. 샤드에서 b. 그림 18에도 표시된 영수증의 수명은 다음과 같습니다. 영수증을 생성하고 보관합니다. 샤드의 청크 생산자 CPA a는 블록 A를 수신하고, 트랜잭션 t를 적용하고 영수증 r을 생성합니다. CPA 그런 다음 생성된 모든 영수증을 색인이 생성된 내부 영구 저장소에 저장합니다. 소스 샤드 ID로영수증을 배포합니다. CPA가 청크를 생성할 준비가 되면 블록 B에 대한 샤드 a, 샤드 a에 대한 블록 A의 트랜잭션을 적용하여 생성된 모든 영수증을 가져와 shrad에 대한 청크에 포함했습니다. 블록 B의 a. 해당 청크가 생성되면 cpa는 삭제 코딩된 삭제 코드를 생성합니다. 버전 및 해당하는 모든 onepart 메시지. cpa는 어떤 블록 생산자가 샤드의 전체 상태를 유지하는지 알고 있습니다. 특정 블록 생산자의 경우 bp cpa에는 블록 A의 거래를 적용하여 발생한 영수증이 포함됩니다. bp가 대상으로 관심을 갖는 샤드 중 하나를 포함하는 샤드 a의 경우 블록 B의 샤드 A에 대한 청크를 배포할 때 onepart 메시지에서 (onepart 메시지에 포함된 영수증을 보여주는 그림 17 참조) 영수증을 받고 있습니다. 참가자(블록 생산자와 validator 모두)는 단일 메시지를 받을 때까지 블록을 처리하지 않는다는 점을 기억하십시오. 블록에 포함된 각 청크에 대해. 따라서 특정 참가자가 블록 B를 적용할 때쯤에는 블록 B에 해당하는 모든 단일 부분 메시지를 갖게 됩니다. B에 청크가 있으므로 샤드가 있는 모든 수신 영수증을 갖게 됩니다. 참가자는 목적지로 상태를 유지합니다. 신청할 때 특정 샤드에 대한 상태 전환, 참가자는 두 가지 영수증을 모두 적용합니다. 그들은 onepart 메시지의 샤드를 위해 수집한 것뿐만 아니라 모든 청크 자체에 포함된 트랜잭션입니다. 그림 18: 영수증 거래의 수명 3.6.2 너무 많은 영수증 처리 특정 샤드를 대상으로 하는 영수증의 수가 특정 블록이 너무 커서 처리할 수 없습니다. 예를 들어 그림 19를 살펴보겠습니다. 각 샤드의 각 거래는 샤드 1을 대상으로 하는 영수증을 생성합니다. 다음 블록까지 샤드 1이 처리해야 하는 영수증 수는 다음과 같습니다. 처리하는 동안 모든 샤드가 결합되어 처리하는 부하와 비슷합니다. 이전 블록.

그림 19: 모든 영수증이 동일한 샤드를 대상으로 하는 경우 샤드는 그것을 처리할 수 있는 능력 이를 해결하기 위해 우리는 QuarkChain 9에서 사용된 것과 유사한 기술을 사용합니다. 구체적으로, 각 샤드에 대해 마지막 블록 B와 해당 샤드 내의 마지막 샤드 영수증이 적용된 블록이 기록됩니다. 새로운 샤드가 생성되면 생성되면 B에 남아있는 샤드부터 순서대로 영수증이 적용되며, 그런 다음 새 청크가 가득 찰 때까지 B를 따르는 블록에서. 정상 이하 부하가 균형 잡힌 상황에서는 일반적으로 모든 영수증이 발생합니다. 적용됩니다(따라서 마지막 블록의 마지막 샤드가 기록됩니다). 각 청크), 하지만 로드가 균형을 이루지 못하는 경우, 그리고 특정 샤드는 불균형적으로 많은 영수증을 받습니다. 이 기술을 사용하면 샤드는 다음과 같은 일을 할 수 있습니다. 포함된 거래 수 제한을 준수하면서 처리됩니다. 이러한 불균형 부하가 오랫동안 지속되면 지연이 발생합니다. 영수증 생성 전까지 신청은 무한정 늘어날 수 있습니다. 하나 이 문제를 해결하는 방법은 다음을 대상으로 하는 영수증을 생성하는 모든 거래를 삭제하는 것입니다. 일부 상수(예: 1 에포크)를 초과하는 처리 지연이 있는 샤드. 그림 20을 살펴보세요. 블록 B에서는 샤드 4가 모든 영수증을 처리할 수 없습니다. 따라서 블록 A의 최대 샤드 3에서 발생한 영수증만 처리합니다. 그것을 기록합니다. 블록 C에는 블록 B의 샤드 5까지의 영수증이 포함됩니다. 그런 다음 블록 D에서 샤드가 따라잡아 나머지 영수증을 모두 처리합니다. 블록 B와 블록 C의 모든 영수증. 3.7 청크 검증 특정 샤드에 대해 생성된 청크(또는 샤드 체인이 있는 모델에서 특정 샤드 체인에 대해 생성된 샤드 블록)는 오직 9여기에서 QuarkChain의 화이트보드 에피소드를 확인하세요: https://www.youtube.com/watch? v=opEtG6NM4x4, 여기에서는 교차 샤드 트랜잭션에 대한 접근 방식이 논의됩니다. 것들그림 20: 지연된 영수증 처리 상태를 유지하는 참가자. 그들은 블록 생산자가 될 수 있습니다, validators, 또는 상태를 다운로드하고 샤드를 검증한 외부 증인일 수도 있습니다. 자산을 저장하는 곳입니다. 이 문서에서는 대부분의 참가자가 저장할 수 없다고 가정합니다. 샤드의 상당 부분에 대한 상태입니다. 언급할 가치는 있지만, 다음과 같은 가정으로 설계된 샤딩된 blockchain이 있습니다. 대부분의 참가자는 대부분의 상태를 저장하고 검증할 수 있는 능력을 가지고 있습니다. QuarkChain과 같은 샤드. 참가자 중 극히 일부만이 샤드를 검증할 수 있는 상태를 갖고 있기 때문에 청크를 갖고 있는 참가자만 적응적으로 손상시킬 수 있습니다. 상태를 확인하고 잘못된 상태 전환을 적용합니다. 몇 번씩 validator을 샘플링하는 다중 샤딩 설계가 제안되었습니다. 일, 그리고 하루 이내에 2/3 이상인 샤드 체인의 모든 블록 해당 샤드에 할당된 validator의 서명이 즉시 고려됩니다. 최종. 이러한 접근 방식을 사용하면 적응력이 뛰어난 공격자는 2n/3+1만 부패시키면 됩니다. 샤드 체인의 validator 중 잘못된 상태 전환을 적용합니다. 해내기 어려울 가능성이 높지만 대중에게 충분한 보안 수준은 아닙니다. blockchain. 섹션 2.3에서 설명한 것처럼 일반적인 접근 방식은 상태가 있는 모든 참가자에 대해 블록이 생성된 후 특정 시간을 허용하는 것입니다. 그 타당성에 도전하는 것은 블록 생산자, validator 또는 외부 관찰자입니다. 이러한 참가자를 어부(Fishermen)라고 합니다. 낚시꾼이 할 수 있는 일 유효하지 않은 블록에 대해 이의를 제기하려면 해당 블록을 사용할 수 있는지 확인해야 합니다. 그들. Nightshade의 데이터 가용성은 섹션 3.4에서 논의됩니다. Nightshade에서는 블록이 생성되면 해당 청크가 검증되지 않습니다. 실제 청크 생산자가 아닌 사람. 특히, 블록 프로듀서는 블록이 당연히 대부분의 샤드에 대한 상태를 갖고 있지 않다고 제안했습니다.청크의 유효성을 검사할 수 없습니다. 다음 블록이 생성되면 여러 블록 생산자와 validator의 증명(섹션 3.2 참조)이 포함됩니다. 하지만 대부분의 블록 생산자와 validator은 상태를 유지하지 않기 때문에 대부분의 샤드에서도 유효하지 않은 청크가 하나만 있는 블록은 증명의 절반 이상을 수집하고 계속해서 가장 무거운 상태를 유지하게 됩니다. 체인. 이 문제를 해결하기 위해 우리는 다음 상태를 유지하는 모든 참가자를 허용합니다. 생성된 유효하지 않은 청크에 대해 온체인으로 챌린지를 제출하는 샤드 파편. 3.7.1 상태 타당성 문제 참가자가 특정 청크가 유효하지 않음을 감지하면 해당 청크가 유효하지 않다는 증거를 제공해야 합니다. 대부분의 네트워크 참여자는 유효하지 않은 청크가 존재하는 샤드에 대한 상태를 유지하지 않기 때문에 생성되면 증거에는 블록이 다음과 같은지 확인하는 데 충분한 정보가 있어야 합니다. 상태가 없으면 유효하지 않습니다. 우리는 단일 트랜잭션이 처리하는 상태량(바이트)의 한계 Ls를 설정합니다. 누적적으로 읽거나 쓸 수 있습니다. Ls 이상에 영향을 미치는 모든 거래 상태는 유효하지 않은 것으로 간주됩니다. 섹션 3.5에서 청크가 특정 블록 B에는 적용할 트랜잭션만 포함되어 있지만 새로운 상태 루트. 블록 B의 청크에 포함된 상태 루트가 상태입니다. 그러한 트랜잭션을 적용하기 전에는 루트이지만 다음에서 트랜잭션을 적용한 후에는 블록 이전의 동일한 샤드의 마지막 청크 B. 악의적인 행위자 잘못된 상태 전환을 적용하려고 하면 잘못된 상태 루트가 포함됩니다. 적용 결과로 발생한 상태 루트에 해당하지 않는 블록 B에서 이전 청크의 트랜잭션. 청크 생산자가 청크에 포함하는 정보를 확장합니다. 모든 트랜잭션을 적용한 후 상태를 포함하는 대신 각 연속 트랜잭션 집합을 적용한 후 상태 루트를 포함합니다. 상태의 Ls 바이트를 집합적으로 읽고 씁니다. 이 정보를 통해 상태 전환이 잘못 적용되는 문제를 만드는 어부 첫 번째 유효하지 않은 상태 루트를 찾고 Ls 바이트만 포함하면 충분합니다. 마지막 상태 루트(이는 유효한) 및 머클 증명이 포함된 현재 상태 루트입니다. 그러면 어떤 참가자라도 세그먼트의 트랜잭션을 검증하고 청크가 다음과 같은지 확인할 수 있습니다. 유효하지 않습니다. 마찬가지로, 청크 생산자가 다음을 읽는 트랜잭션을 포함하려고 시도한 경우 Ls 바이트 이상의 상태를 작성합니다. 이 문제의 경우 다음을 포함하는 것으로 충분합니다. 머클 증명과 접촉하는 첫 번째 L 바이트는 다음과 같이 충분합니다. 트랜잭션을 적용하고 시도가 있는 순간이 있는지 확인합니다. Ls 바이트를 초과하는 콘텐츠를 읽거나 씁니다.

3.7.2 어부와 빠른 샤드 간 거래 섹션 2.3에서 설명한 것처럼 샤드 청크(또는 샤드)가 샤드 체인이 있는 모델의 블록)은 유효하지 않으며 문제가 발생할 수 있습니다. 기간 동안 이는 최종성에 부정적인 영향을 미쳐 샤드 간 통신에 부정적인 영향을 미칩니다. 에서 특히, 샤드 간 거래의 대상 샤드는 확실할 수 없습니다. 원래 샤드 청크 또는 블록은 챌린지 기간이 끝날 때까지 최종입니다. (그림 21 참조) 그림 21: 영수증을 적용하기 전에 챌린지 기간을 기다리는 중 교차 샤드 트랜잭션을 수행하는 방식으로 이를 해결하는 방법 Instantenious는 대상 샤드가 챌린지 기간을 기다리지 않는 것입니다. 소스 샤드 트랜잭션이 게시된 후 영수증 트랜잭션을 적용합니다. 즉시, 그러나 소스와 함께 대상 샤드를 롤백합니다. 나중에 원래 청크나 블록이 유효하지 않은 것으로 밝혀지면 샤딩합니다(그림 참조). 22). 이는 샤드가 사용되는 Nightshade 디자인에 매우 자연스럽게 적용됩니다. 체인은 독립적이지 않지만 대신 샤드 청크가 모두 게시됩니다. 동일한 메인 체인 블록에 함께 있습니다. 유효하지 않은 청크가 발견되면 해당 청크가 포함된 전체 블록은 유효하지 않은 것으로 간주되며, 그 위에 구축된 모든 블록은 그것의 꼭대기. 그림 23을 참조하십시오. 위의 두 접근 방식 모두 챌린지가 다음과 같다고 가정하여 원자성을 제공합니다. 기간은 충분히 길다. 정상적인 상황에서 빠른 크로스샤드 트랜잭션을 제공하는 것이 불편함을 능가하기 때문에 우리는 후자의 접근 방식을 사용합니다. 다음 중 하나의 잘못된 상태 전환으로 인해 대상 샤드 롤백 이는 극히 드문 이벤트입니다. 3.7.3 validator 숨기기 문제가 존재하면 이미 다음과 같은 가능성이 크게 감소합니다. 잘못된 상태 전환 포스트로 청크를 마무리하기 때문에 적응형 손상그림 22: 영수증 즉시 적용 및 대상 롤백 소스 체인에 유효하지 않은 블록이 있는 경우 체인 그림 23: Nightshade의 어부 도전 적응형 적이 모든 참가자를 부패시키는 데 필요한 도전 기간 모든 validator을 포함하여 샤드의 상태를 유지합니다. 그러한 사건의 가능성을 추정하는 것은 매우 복잡합니다. 샤딩된 blockchain은 그러한 공격이 시도될 만큼 오랫동안 활성화되었습니다. 우리는 확률이 극히 낮지만 여전히 충분하다고 주장합니다. 수백만 건의 트랜잭션을 실행할 것으로 예상되는 시스템에 비해 규모가 크고 세계적인 금융 운영을 운영합니다. 이러한 믿음에는 두 가지 주요 이유가 있습니다. 1. 대부분의 지분 증명 체인과 채굴자의 validator

작업 증명 체인은 주로 재정적 측면에서 인센티브를 받습니다. 만약에 적응형 적군은 예상 수익보다 더 많은 돈을 제공합니다. 정직하게 운영하면 많은 validator이 발생할 것으로 예상하는 것이 합리적입니다. 그 제안을 받아들일 것이다. 2. 많은 기업이 지분 증명 체인을 전문적으로 검증합니다. 어떤 체인에서든 지분의 상당 부분이 그러한 단체로부터. 그러한 개체의 수는 한 기업에 비해 충분히 적습니다. 적응력이 뛰어난 적은 그들 대부분을 개인적으로 알아가고 그들의 부패 성향을 잘 이해하고 있습니다. 우리는 어떤 validator이 어떤 샤드에 할당되어 있는지 숨김으로써 적응형 손상 가능성을 줄이는 데 한 단계 더 나아갔습니다. 아이디어는 Algorand [5]이 validator을 숨기는 방식과 원격으로 유사합니다. Algorand에서와 같이 validator이 숨겨져 있더라도 주의하는 것이 중요합니다. 또는 아래 설명된 것처럼 적응형 손상은 이론상으로는 여전히 가능합니다. 동안 적응형 적수는 생성하거나 검증할 참가자를 알지 못합니다. 블록이나 덩어리, 참가자 스스로는 자신이 수행할 것임을 알고 있습니다. 그러한 작업을 수행하고 이에 대한 암호화 증거를 가지고 있습니다. 따라서 상대방은 다음과 같이 할 수 있다. 부패하려는 의도를 알리고 이를 제공할 참가자에게 비용을 지불합니다. 그러한 암호화 증명. 그러나 우리는 적이 그렇지 않기 때문에 손상시키려는 샤드에 할당된 validator을 알고 있으면 특정 샤드를 손상시키려는 의도를 다른 사람에게 알리는 것 외에는 다른 선택이 없습니다. 전체 커뮤니티. 그 시점에서는 정직한 사람이라면 누구에게나 경제적으로 이익이 됩니다. 참가자는 샤드를 검증하는 전체 노드를 가동합니다. 해당 샤드에 유효하지 않은 블록이 나타날 가능성이 있습니다. 챌린지를 만들고 관련 보상을 받으세요. 특정 샤드에 할당된 validator을 공개하지 않기 위해 우리는 다음(그림 24 참조): VRF를 사용하여 과제를 얻습니다. 각 시대가 시작될 때마다 validator은 VRF를 사용하여 validator이 할당된 샤드의 비트마스크를 가져옵니다. 각 validator의 비트마스크에는 Sw 비트가 있습니다(정의는 섹션 3.3 참조). SW의). 그런 다음 validator는 해당 샤드의 상태를 가져오고 수신된 각 블록에 대해 해당 에포크 동안 해당 청크의 유효성을 검사합니다. validator이 할당된 샤드에. 청크 대신 블록에 서명하세요. 샤드 할당이 숨겨져 있으므로 validator은 청크에 서명할 수 없습니다. 대신 항상 전체에 서명합니다. 따라서 어떤 샤드가 검증되었는지 공개하지 않습니다. 특히 validator이 블록을 수신하고 모든 청크를 검증할 때 메시지를 생성하거나 이는 validator이 할당된 모든 샤드의 모든 청크가 유효함(해당 샤드가 무엇인지 어떤 방식으로든 표시하지 않음) 또는 다음과 같은 메시지 청크가 유효하지 않은 경우 유효하지 않은 상태 전환에 대한 증거가 포함됩니다. 참조 이러한 메시지가 어떻게 집계되는지에 대한 자세한 내용은 섹션 3.8을, 섹션 3.7.4를 참조하세요. validators가 메시지에 편승하는 것을 방지하는 방법에 대한 세부정보 보상 및 처벌 방법에 대한 자세한 내용은 기타 validator 및 섹션 3.7.5를 참조하세요. validators는 잘못된 상태 전환 문제가 실제로 발생해야 성공한다는 것입니다.그림 24: Nightshade에 validator을 숨기기 3.7.4 커밋-공개 validators의 일반적인 문제 중 하나는 validator이 상태 다운로드와 실제로 청크 및 블록 유효성 검사를 건너뛸 수 있다는 것입니다. 네트워크를 관찰하고 다른 validator이 제출한 내용을 확인하고 반복하세요. 메시지. 이러한 전략을 따르는 validator은 추가 기능을 제공하지 않습니다. 네트워크 보안을 강화하지만 보상을 수집합니다. 이 문제에 대한 일반적인 해결책은 각 validator이 증거를 제공하는 것입니다. 예를 들어 고유한 추적을 제공하여 실제로 블록의 유효성을 검사했습니다. 상태 전이를 적용하는 방법이 있지만 그러한 증명은 비용을 상당히 증가시킵니다. 검증의. 그림 25: 커밋-공개

대신 우리는 검증 결과에 대해 validators의 첫 번째 커밋을 만듭니다(둘 중 하나). 청크의 유효성을 증명하는 메시지 또는 유효하지 않은 청크의 증거 상태 전환), 일정 기간 동안 기다렸다가 그림 25와 같이 실제 검증 결과를 공개합니다. 커밋 기간은 상태 전환과 교차하지 않습니다. 공개 기간이므로 게으른 validator은 정직한 validator을 흉내낼 수 없습니다. 더욱이, 부정직한 validator이 다음을 증명하는 메시지를 약속한 경우 할당된 청크의 유효성을 확인하고 적어도 하나의 청크가 유효하지 않은 경우 청크가 유효하지 않은 것으로 나타났습니다. validator은 슬래싱을 피할 수 없습니다. 섹션 3.7.5에서 볼 수 있듯이 이러한 상황에서 슬래시를 당하지 않는 유일한 방법은 잘못된 상태 전환에 대한 증거가 포함된 메시지를 제시하는 것입니다. 커밋과 일치합니다. 3.7.5 문제 처리 위에서 설명한 대로 validator이 유효하지 않은 청크가 있는 블록을 수신하면, 먼저 유효하지 않은 상태 전환에 대한 증거를 준비한 다음(섹션 3.7.1 참조) 그러한 증명을 수행하고(3.7.4 참조) 일정 기간이 지나면 도전 과제를 공개합니다. 공개된 챌린지가 블록에 포함되면 다음과 같은 일이 발생합니다. 1. 해당 블록을 포함하는 블록에서 발생한 모든 상태 전환 공개된 챌린지가 포함된 블록까지 유효하지 않은 청크를 얻습니다. 무효화되었습니다. 공개된 챌린지를 포함하는 블록 이전의 상태 포함된 블록 이전의 상태와 동일한 것으로 간주됩니다. 유효하지 않은 청크. 2. 특정 기간 내에 각 validator은 자신의 비트마스크를 공개해야 합니다. 그들이 검증한 샤드 중. 비트마스크는 VRF를 통해 생성되므로, 상태 전환이 잘못된 샤드에 할당되었습니다. 공개를 피할 수 없습니다. 비트마스크를 공개하지 못하는 모든 validator 샤드에 할당된 것으로 가정됩니다. 3. 해당 기간이 지나면 샤드에 할당된 것으로 확인된 각 validator, 해당 블록에 대한 일부 검증 결과를 커밋했습니다. 유효하지 않은 청크이며 유효하지 않은 상태 전환의 증거를 공개하지 않았습니다. 커밋에 해당하는 내용은 슬래시됩니다. 4. 각 validator은 새로운 샤드 할당을 받고 새로운 시대가 예약됩니다. 모든 validator가 다운로드하기에 충분한 시간이 지난 후에 시작하려면 상태는 그림 26과 같습니다. validators가 할당된 샤드를 공개하는 순간부터 참고하세요. 새로운 시대가 시작될 때까지 시스템의 보안은 샤드 할당이 공개되었습니다. 네트워크 참여자는 이를 유지해야 합니다. 해당 기간 동안 네트워크를 사용할 때 주의하세요. 3.8 서명 집계 수백 개의 샤드가 있는 시스템이 안전하게 작동하려면 다음을 수행해야 합니다. 10,000개 이상의 validator 주문. 섹션 3.7에서 논의한 것처럼 우리는 각각을 원합니다.그림 26: 과제 처리 validator 평균적으로 특정 메시지와 서명에 대한 커밋을 게시합니다. 블록당 한 번. 커밋 메시지가 동일하더라도 BLS 서명과 이를 검증하는 것은 엄청나게 비용이 많이 들었습니다. 하지만 당연히 커밋 및 공개 메시지는 validator에서 동일하지 않습니다. 따라서 그러한 메시지와 서명을 통합할 수 있는 방법이 필요합니다. 나중에 빠르게 검증할 수 있는 방법입니다. 우리가 사용하는 구체적인 접근 방식은 다음과 같습니다. 블록 생산자에 합류하는 검증인. 블록 생산자는 알려져 있습니다. 에포크가 시작되기 얼마 전에 다운로드할 시간이 필요하기 때문입니다. 에포크가 시작되기 전의 상태이며, validator과 달리 블록 생산자는 숨겨져 있지 않습니다. 각 블록 생산자는 v validator 슬롯을 갖습니다. 검증인이 제출 블록 생산자에게 v 중 하나로 포함되도록 오프체인 제안 validators. 블록 생산자가 validator을 포함하려는 경우 validator의 초기 오프체인 요청을 포함하는 트랜잭션, 그리고 validator을 블록 생산자에 참여시키는 블록 생산자의 서명입니다. 블록 생산자에게 할당된 validator이 반드시 필요한 것은 아닙니다. 블록 생산자가 청크를 생성하는 것과 동일한 샤드를 검증합니다. 만약 validator은 여러 블록 생산자에 합류하기 위해 적용되었으며, 첫 번째 블록 생산자가 성공할 것입니다. 블록 생산자는 커밋을 수집합니다. 블록 생산자는 validator에서 지속적으로 커밋 및 공개 메시지를 수집합니다. 이러한 메시지가 일정 개수 누적되면 블록 생산자는 머클을 계산합니다. 이러한 메시지의 트리를 만들고 각 validator에 머클 루트와 그들의 메시지에 대한 머클 경로. validator는 경로의 유효성을 검사하고 로그인합니다. 머클 루트. 그런 다음 블록 생산자는 BLS 서명을 블록에 축적합니다. validators의 머클 루트이며 머클 루트와 누적된 서명. 블록 생산자는 또한 해당 블록의 유효성에 서명합니다. 저렴한 ECDSA 서명을 사용하는 다중 서명. 다중 서명이 되지 않는 경우 제출된 머클 루트 또는 참여하는 validator의 비트마스크와 일치하면 슬래시 가능한 동작입니다. 체인을 동기화할 때 참가자는 validators의 모든 BLS 서명을 검증하도록 선택할 수 있습니다(validators 공개 키 집계가 포함되므로 매우 비쌉니다).블록 생산자의 ECDMA 서명을 사용하고 다음 사실에 의존합니다. 블록 프로듀서는 도전을 받고 삭감되지 않았습니다. 온체인 트랜잭션과 머클 증명을 사용하여 문제를 해결합니다. 그것 validators의 메시지가 없으면 공개할 가치가 없다는 점을 알 수 있습니다. 잘못된 상태 전환이 감지되었습니다. 실제 내용이 포함된 메시지만 유효하지 않은 상태 전환에 대한 증거가 공개되어야 하며, 그러한 메시지에 대해서만 이전 커밋과 일치하는지 표시해야 합니다. 메시지는 다음과 같습니다. 두 가지 목적으로 공개됩니다. 1. 실제로 체인의 롤백을 시작하기 전 순간으로 잘못된 상태 전환(섹션 3.7.5 참조). 2. validator이(가) 유효성을 증명하려고 시도하지 않았음을 증명하기 위해 잘못된 청크. 두 경우 모두 다음 두 가지 문제를 해결해야 합니다. 1. 실제 커밋은 체인에 포함되지 않았고 머클 루트만 포함되었습니다. 다른 메시지와 함께 집계된 커밋입니다. validator에서는 다음을 사용해야 합니다. 블록 생산자가 제공한 머클 경로와 원래 커밋 그들이 도전에 전념했음을 증명하십시오. 2. 잘못된 샤드에 할당된 모든 validator이(가) 가능합니다. 상태 전환은 손상된 블록 생산자에게 할당됩니다. 그들을 검열하고 있습니다. 이 문제를 해결하기 위해 우리는 그들이 공개 내용을 제출하도록 허용합니다. 온체인에서 일반 트랜잭션으로 처리하고 집계를 우회합니다. 후자는 유효하지 않은 상태 전환 증명에만 허용됩니다. 극히 드물기 때문에 블록에 스팸을 보내서는 안 됩니다. 해결해야 할 마지막 문제는 블록 생산자가 다음을 수행할 수 있다는 것입니다. 메시지 집계에 참여하지 않거나 특정 validator을 의도적으로 검열하지 않도록 선택하세요. 블록을 만들어 경제적으로 불리하게 만듭니다. 생산자 보상은 할당된 validator 수에 비례합니다. 우리 또한 시대 사이의 블록 생산자는 대체로 교차하기 때문에(이후 항상 가장 높은 지분을 가진 참가자 중 최고입니다.) validators는 대부분 동일한 블록 생산자와 협력하여 위험을 줄입니다. 과거에 그들을 검열했던 블록 생산자에게 배정되는 것입니다. 3.9 스냅샷 체인 메인체인의 블록은 매우 빈번하게 생성되기 때문에 다운로드가 전체 기록은 매우 빠르게 비용이 높아질 수 있습니다. 게다가 매 순간부터 블록에는 다수의 참가자의 BLS 서명이 포함되어 있으므로 서명을 확인하기 위한 공개 키의 집합이 엄청나게 커질 수 있습니다. 비싸기도 하고. 마지막으로, 가까운 미래에는 Ethereum 1.0이 1로 남을 가능성이 높기 때문입니다. 가장 많이 사용되는 blockchain 중 자산을 전송하는 의미 있는 방법이 있습니다.

Ethereum에 가까운 것이 요구 사항이며 오늘 BLS 서명을 확인하여 Ethereum 측의 근거리 차단 유효성은 불가능합니다. Nightshade 메인 체인의 각 블록은 선택적으로 Schnorr를 포함할 수 있습니다. 그러한 Schnorr를 포함하는 마지막 블록의 헤더에 다중 서명 다중 서명. 우리는 이러한 블록을 스냅샷 블록이라고 부릅니다. 가장 첫 번째 블록은 모든 에포크는 스냅샷 블록이어야 합니다. 이런 다중서명 작업을 하면서, 블록 생산자는 validators의 BLS 서명도 축적해야 합니다. 마지막 스냅샷 블록에서 설명된 것과 동일한 방식으로 집계합니다. 섹션 3.8. 블록 생산자 세트는 시대 전반에 걸쳐 일정하므로 유효성을 검사합니다. 각 에포크의 첫 번째 스냅샷 블록만 있으면 충분합니다. 많은 비율의 블록 생산자와 validator이 공모하고 생성되었다는 점을 지적합니다. 포크. 에포크의 첫 번째 블록에는 다음을 계산하기에 충분한 정보가 포함되어야 합니다. 해당 시대의 블록 생산자와 validator. 스냅샷만 포함된 메인체인의 서브체인을 호출합니다. 스냅샷 체인을 차단합니다. Schnorr 다중 서명을 생성하는 것은 대화형 프로세스이지만, 아무리 비효율적이라도 프로세스를 가끔씩만 수행하면 됩니다. 성공할 것이다. Schnorr 다중 서명은 Ethereum에서 쉽게 검증할 수 있습니다. 따라서 blockchain 교차 수행의 안전한 방법을 위한 중요한 기본 요소를 제공합니다. 의사소통. Near 체인과 동기화하려면 모든 스냅샷만 다운로드하면 됩니다. 차단하고 Schnorr 서명이 올바른지 확인한 다음(선택적으로 validators의 개별 BLS 서명도 확인) 동기화만 수행합니다. 마지막 스냅샷 블록의 메인 체인 블록.

Nightshade

3.1 Parça zincirlerinden parça parçalara Parça zincirleri ve işaret zinciri içeren parçalama modeli çok güçlüdür ancak belirli karmaşıklıklara sahiptir. Özellikle çatal seçim kuralının uygulanması gerekiyor her zincirde ayrı ayrı, parça zincirlerinde ve işaretçide çatal seçim kuralı Zincir farklı şekilde oluşturulmalı ve ayrı olarak test edilmelidir. Nightshade'de sistemi tek bir blockchain olarak modelliyoruz; her biri blok mantıksal olarak tüm parçalar için tüm işlemleri içerir ve tüm parçaların tüm durumu. Ancak fiziksel olarak hiçbir katılımcı dosyayı indirmez. tam durum veya tam mantıksal blok. Bunun yerine, ağın her katılımcısı yalnızca İşlemleri doğruladıkları parçalara karşılık gelen durumu korur ve bloktaki tüm işlemlerin listesi fiziksel olarak bölünmüştür parçalar, parça başına bir parça. İdeal koşullar altında her blok, parça başına tam olarak bir parça içerir. kabaca parça zincirli modele karşılık gelen blok parça zincirleri işaret zinciriyle aynı hızda bloklar üretir. Ancak, ağ gecikmeleri nedeniyle bazı parçalar eksik olabilir; bu nedenle pratikte her blok parça başına bir veya sıfır parça içerir. Nasıl yapılacağına ilişkin ayrıntılar için bölüm 3.3'e bakın. bloklar üretilir. Şekil 16: Solda parça zincirleri ve tek zinciri olan bir model bloklar sağ tarafta parçalara bölünmüş

3.2 Konsensüs Bugün blockchain'lerde fikir birliğine yönelik iki baskın yaklaşım şunlardır: En fazla işe veya hisseye sahip olan zincirin en uzun (veya en ağır) zincir oluşturmak için kullanılan kurallı kabul edilir ve BFT, burada her blok için bazı validator kümesi BFT fikir birliğine ulaştı. Son zamanlarda önerilen protokollerde ikincisi daha baskın bir yaklaşımdır, anında kesinlik sağladığından, en uzun zincirde daha fazla bloğa ihtiyaç duyulurken Kesinliği sağlamak için bloğun üzerine inşa edilecek. Çoğu zaman anlamlı Yeterli sayıda bloğun inşa edilmesi için gereken süre güvenlik gerektirir. saat sırası. Her blokta BFT fikir birliğini kullanmanın aşağıdaki gibi dezavantajları da vardır: 1. BFT fikir birliği önemli miktarda iletişim gerektirir. iken Son gelişmeler sayıca doğrusal zamanda fikir birliğine varılmasına olanak tanıyor katılımcıların sayısı (bkz. örneğin [4]), blok başına hala fark edilebilir bir yüktür; 2. Tüm ağ katılımcılarının BFT'ya katılması mümkün değildir. Blok başına fikir birliğine varılır, dolayısıyla genellikle yalnızca rastgele örneklenmiş bir katılımcı alt kümesi fikir birliğine varır. Rastgele örneklenmiş bir küme prensip olarak şu şekilde olabilir: uyarlanabilir bir şekilde bozulur ve teoride bir çatal oluşturulabilir. sistem her ikisinin de böyle bir olaya hazır olmak için modellenmesi gerekiyor ve bu nedenle hala BFT fikir birliğinin yanı sıra bir çatal seçeneği kuralına sahip olmak veya kapanacak şekilde tasarlanmış olmak böyle bir olayda aşağı. Bazı tasarımların olduğunu belirtmekte fayda var. Algorand [5], uyarlamalı yolsuzluk olasılığını önemli ölçüde azaltır. 3. En önemlisi şu durumlarda sistem durur: Tüm katılımcıların 3 veya daha fazlası çevrimdışı. Bu nedenle, herhangi bir geçici ağ arızası veya ağ bölünmesi, sistemi tamamen durdurabilir. İdeal olarak sistem devam edebilmelidir katılımcıların en az yarısı çevrimiçi olduğu sürece faaliyet göstermektedir (en yoğun Zincir tabanlı protokoller, katılımcıların yarısından azı çevrimiçi olsa bile çalışmaya devam eder, ancak bu özelliğin arzu edilirliği daha tartışmalıdır topluluk içinde). Kullanılan fikir birliğinin bir tür en ağır olduğu hibrit bir model zincir, ancak bazı bloklar BFT sonlandırma aracı kullanılarak periyodik olarak sonlandırılır ve her iki modelin de avantajları korunur. Bu tür BFT nihai gadget'lar Ethereum 2.0 8'de kullanılan Casper FFG [6], Casper CBC (bkz. https://vitalik.) ca/general/2018/12/05/cbc_casper.html) ve GRANDPA (bkz. https:// Medium.com/polkadot-network/d08a24a021b5) Polkadot'de kullanıldı. Nightshade en ağır zincir konsensüsünü kullanır. Özellikle bir blok Üretici bir blok ürettiğinde (bkz. Bölüm 3.3), imza toplayabilirler. diğer blok üreticileri ve önceki bloğu doğrulayan validator'lar. Bölüme bakın Bu kadar çok sayıda imzanın nasıl toplandığıyla ilgili ayrıntılar için 3.8'e bakınız. Ağırlık 8Ayrıca Casper'a derinlemesine bir genel bakış için Justin Drake ile yapılan beyaz tahta oturumuna bakın FFG ve GHOST en ağır zincir konsensüsüne nasıl entegre edildiği burada: https://www. youtube.com/watch?v=S262StTwkmobir bloğun payı, imzaları imzalanan tüm imzalayanların kümülatif hissesidir. bloğa dahil edilmiştir. Bir zincirin ağırlığı blok ağırlıklarının toplamıdır. En ağır zincir mutabakatının yanı sıra, aşağıdakileri kullanan bir nihai gadget kullanıyoruz: blokları sonlandırmak için onaylar. Sistemin karmaşıklığını azaltmak için, Çatal seçim kuralını hiçbir şekilde etkilemeyen bir sonlandırma aracı kullanıyoruz, ve bunun yerine yalnızca ekstra eğik çizgi koşulları getirir, öyle ki bir blok bir kez Nihai gadget tarafından sonlandırıldığında, çok büyük bir yüzde olmadıkça çatallanma imkansızdır. toplam bahis miktarı kesildi. Casper CBC son derece kaliteli bir cihazdır ve biz şu anda Casper CBC'yi göz önünde bulundurarak model oluşturuyorum. Ayrıca TxFlow adı verilen ayrı bir BFT protokolü üzerinde de çalışıyoruz. O sırada Bu belgeyi yazarken Casper yerine TxFlow'un kullanılıp kullanılmayacağı belli değil CBC. Ancak son cihaz seçiminin büyük ölçüde tasarımın geri kalanına dik olduğunu belirtmeliyiz. 3.3 Blok üretimi Nightshade'de iki rol vardır: blok yapımcıları ve validator'ler. herhangi bir zamanda sistemin w blok üreticilerini içerdiği nokta, modellerimizde w = 100 ve wv validators, modelimizde v = 100, wv = 10, 000. Sistem Proof-of-Stake'tir, bu, hem blok üreticilerinin hem de validator'lerin bir takım dahili bağlantılara sahip olduğu anlamına gelir para birimi ("tokens" olarak anılır) belirtilen süreyi aşan bir süre boyunca kilitlendi zinciri oluşturma ve doğrulama görevlerini yerine getirmek için harcadıkları zaman. Tüm Proof of Stake sistemlerinde olduğu gibi, tüm w blok üreticileri ve tüm wv validator'ler farklı varlıklardır, çünkü bu uygulanamaz. Her biri Bununla birlikte, w blok üreticilerinin ve wv validator'lerin ayrı bir hisse. Sistem n parça içeriyor, modelimizde n = 1000. Bahsedildiği gibi bölüm 3.1, Nightshade'de hiçbir parça zinciri yoktur, bunun yerine tüm blok üreticileri ve validator'ler tek bir blockchain inşa ediyor, biz bunu ana zincir. Ana zincirin durumu n parçaya bölünmüştür ve her blok yapımcı ve validator her an yerel olarak yalnızca bir alt kümesini indirdi bazı parçaların alt kümesine karşılık gelen ve yalnızca işlem ve Eyaletin bu kısımlarını etkileyen işlemleri doğrulamak. Bir blok üreticisi olmak için ağın bir katılımcısı bazı büyükleri kilitler tokens miktarı (bir hisse). Ağın bakımı dönemler halinde yapılır, burada bir dönem gün sırasına göre bir zaman dilimidir. Katılımcılar Belirli bir çağın başında en büyük riske sahip olan bloklar O dönemin yapımcıları. Her blok üreticisi yazılım parçalarına atanır (örneğin sw = 40, bu da sww/n = parça başına 4 blok üreticisi anlamına gelir). Blok yapımcı, atandığı parçanın çağdan önceki durumunu indirir başlar ve dönem boyunca söz konusu parçayı etkileyen işlemleri toplar, ve bunları devlete uygular. Ana zincirdeki her b bloğu ve her parça s için aşağıdakilerden biri vardır: blok üreticilerini b ile ilgili kısmı üretmekten sorumlu olanlara atadık parçaya. b'nin parçayla ilgili kısmına yığın denir ve şunları içerir: merkle'nin yanı sıra b'ye dahil edilecek parçaya ilişkin işlemlerin listesiortaya çıkan durumun kökü. b sonuçta yalnızca çok küçük bir başlık içerecektir parça, yani uygulanan tüm işlemlerin merkle kökü (bkz. bölüm Kesin ayrıntılar için 3.7.1) ve son durumun merkle kökü. Belgenin geri kalanında sıklıkla blok üreticisinden bahsediyoruz belirli bir parça için belirli bir zamanda bir parça üretmekten sorumlu olan bir parça üreticisi olarak. Parça üreticisi her zaman blok üreticilerinden biridir. Blok üreticileri ve parça üreticileri her bloğu ona göre döndürür. sabit bir programa göre. Blok üreticilerinin siparişi var ve tekrar tekrar üretim yapıyorlar. bu sırayla bloklar. Örn. 100 blok üreticisi varsa ilk blok üreticiler 1, 101, 201 vb. blokların üretiminden sorumludur, ikincisi ise 2, 102, 202 vb. üretmekten sorumludur. Parça üretimi, blok üretiminden farklı olarak bakım gerektirdiğinden durum ve her parça için yalnızca sww/n blok üreticileri durumu korur parça başına, buna uygun olarak yalnızca sww/n blok üreticileri, oluşturmak için dönüşümlü olarak çalışır. parçalar. Örn. dört blok üreticisinin atandığı yukarıdaki sabitlerle Her parça, her blok üreticisi her dört blokta bir parça oluşturacak. 3.4 Veri kullanılabilirliğinin sağlanması Veri kullanılabilirliğini sağlamak için Polkadot yaklaşımına benzer bir yaklaşım kullanıyoruz bölüm 2.5.3'te açıklanmıştır. Bir blok üreticisi bir parça ürettiğinde, optimal (w, ⌊w/6 + 1⌋) blok koduna sahip silme kodlu versiyonu yığın. Daha sonra silme kodlu parçanın bir parçasını gönderirler (bu tür parçalar diyoruz) her blok üreticisine parça parçaları veya sadece parçalar). Yapraklar gibi tüm parçaları içeren bir merkle ağacı hesaplıyoruz ve Her parçanın başlığı bu ağacın merkle kökünü içerir. Parçalar tek parça mesajları aracılığıyla validators'ye gönderilir. Bu tür mesajların her biri öbek başlığını, parçanın sırasını ve parça içeriğini içerir. mesaj aynı zamanda blok üreticisinin imzasını da içermektedir. parçanın başlığa karşılık geldiğini kanıtlamak için parça ve merkle yolu ve uygun blok üreticisi tarafından üretilmektedir. Bir blok üreticisi bir ana zincir bloğunu aldığında ilk olarak bu bloğun olup olmadığını kontrol eder. blokta yer alan her parça için tek parçalı mesajlar bulunur. Aksi takdirde blok eksik tek parçalı mesajlar alınana kadar işlenmez. Tüm tek parçalı mesajlar alındıktan sonra blok üreticisi, akranlarından kalan parçaları alır ve tuttukları parçaları yeniden yapılandırır devlet. Blok üreticisi en az bir ana zincir bloğunu işlemez. bloğa dahil edilen parçalarda karşılık gelen tek parçalı mesaj yoktur veya durumu korudukları en az bir parça için bunu yapamazlar tüm parçayı yeniden yapılandırın. Belirli bir parçanın mevcut olması için bloğun ⌊w/6⌋+1 olması yeterlidir Üreticiler kendi paylarına sahipler ve onlara hizmet ediyorlar. Böylece sayı kadar Kötü niyetli aktörler, yarım bloktan fazla bloğu olan hiçbir zincirin ⌊w/3⌋ değerini aşmaz bunu inşa eden üreticiler kullanılamayan parçalara sahip olabilir.Şekil 17: Her blok, parça başına bir veya sıfır parça içerir ve her parça silme kodludur. Silme kodlu yığının her bir parçası belirlenmiş bir yere gönderilir. özel bir tek bölümlü mesaj aracılığıyla yapımcıyı bloke etme 3.4.1 Tembel blok üreticileriyle uğraşmak Bir blok üreticisinin tek parçalı mesajın eksik olduğu bir bloğu varsa, yine de imzalamayı seçebilir, çünkü eğer blok zincire bağlanırsa blok üreticisinin ödülünü maksimuma çıkaracak. Blok için risk yok Daha sonra blok üreticisinin sahip olmadığını kanıtlamak imkansız olduğundan üretici tek parça mesajı. Bunu ele almak için, her bir parça üreticisini, parçayı oluştururken yapıyoruz. gelecekteki kodlanmış parçanın her bir parçası için bir renk (kırmızı veya mavi) seçin ve saklayın kodlanmadan önce yığındaki atanan rengin bit maskesi. Her bir parça mesaj parçaya atanan rengi içerir ve renk şu durumlarda kullanılır: kodlanmış parçaların merkle kökünün hesaplanması. Parça üreticisi saparsa protokole göre kolayca kanıtlanabilir, çünkü merkle kökü tek parça mesajlarına veya tek parça mesajlarındaki renklere karşılık gelir merkle köküne karşılık gelen, yığındaki maskeyle eşleşmeyecektir. Bir blok üreticisi bir bloğa imza attığında, tüm blokların bit maskesini ekler. bloğa dahil edilen parçalar için aldıkları kırmızı parçalar. Bir yayınlama yanlış bit maskesi kesilebilir bir davranıştır. Bir blok üreticisi bir sertifika almamışsa tek parçalı mesaj, mesajın rengini bilmelerinin hiçbir yolu yoktur ve dolayısıyla körü körüne imza atmaya kalkışmaları halinde %50 oranında kesintiye uğrama şansları vardır. Blok. 3.5 Durum geçiş başvurusu Parça üreticileri yalnızca parçaya hangi işlemlerin dahil edileceğini seçerler ancak bir yığın ürettiklerinde durum geçişini uygulamayın. Buna bağlı olarak,

yığın başlığı, daha önce olduğu gibi merkelize durumun merkle kökünü içerir yığındaki işlemler uygulanır. İşlemler yalnızca parçayı içeren tam bir blok olduğunda uygulanır işlenir. Bir katılımcı yalnızca şu durumlarda bir bloğu işler: 1. Önceki blok alındı ve işlendi; 2. Her parça için katılımcı sahip olduğu durumu korumaz tek parça mesajını gördüm; 3. Her parça için katılımcı, sahip oldukları durumu korur. tam yığın. Blok işlendikten sonra, katılımcının her bir parça için durumu korur, işlemleri uygular ve yeni durumu hesaplarlar işlemler uygulandıktan sonra üretime hazır hale gelirler herhangi bir parçaya atanmışlarsa bir sonraki bloğun parçaları yeni merkelleşmiş durumun merkle kökü. 3.6 Parçalar arası işlemler ve makbuzlar Bir işlemin birden fazla parçayı etkilemesi gerekiyorsa bunun ardışık olarak yapılması gerekir her parçada ayrı ayrı yürütülür. İşlemin tamamı ilk parçaya gönderilir etkilendiğinde ve işlem söz konusu parçanın öbeğine dahil edildiğinde ve öbek bir bloğa dahil edildikten sonra uygulanır, sözde bir makbuz üretir işlemin yapılması gereken bir sonraki parçaya yönlendirilen işlem idam edilecek. Daha fazla adımın gerekli olması halinde, alındı işleminin yürütülmesi yeni bir giriş hareketi oluşturur ve bu şekilde devam eder. 3.6.1 Makbuz işleminin ömrü Alış işleminin oluşturulduğu bloğun hemen ardından gelen blokta uygulanması arzu edilir. Makbuz işlemi yalnızca Önceki bloğun blok üreticileri tarafından alınıp uygulanmasından sonra oluşturulan kaynak parçayı koruyan ve o zamana kadar bilinmesi gereken Bir sonraki blok için parça, hedefin blok üreticileri tarafından üretilir kırık. Bu nedenle, makbuzun kaynak parçadan alıcıya iletilmesi gerekir. Bu iki olay arasındaki kısa zaman dilimindeki hedef parça. A, r girişini üreten bir t işlemini içeren son üretilen blok olsun. B bir sonraki üretilen blok olsun (yani A'yı içeren bir blok) r'yi içermek istediğimiz önceki bloğu). a ve r parçasında olsun kırıkta b. Şekil 18'de de gösterilen faturanın kullanım ömrü aşağıdaki gibidir: Makbuzların üretilmesi ve saklanması. Parça için parça üreticisi EBM'si a, A bloğunu alır, t işlemini uygular ve r makbuzunu oluşturur. EBM daha sonra üretilen tüm makbuzları dahili kalıcı depolama biriminde indekslenmiş olarak saklar kaynak parça kimliğine göre.Makbuzların dağıtılması. EBM, parçayı üretmeye hazır olduğunda B bloğu için a parçasını, a bloğu için A bloğundaki işlemlerin uygulanmasıyla oluşturulan tüm makbuzları getirir ve bunları parça için parçaya dahil ederler. B bloğunda a. Böyle bir yığın oluşturulduktan sonra, cpa onun silme kodunu üretir sürümü ve karşılık gelen tüm onepart mesajları. EBM, hangi blok üreticilerinin hangi parçalar için tam durumu koruduğunu bilir. Belirli bir blok üreticisi için bp cpa, A bloğundaki işlemlerin uygulanmasından kaynaklanan makbuzları içerir bp'nin hedef olarak önemsediği parçalardan herhangi birine sahip olan parça a için B bloğundaki a parçası için yığını dağıttıklarında tek parçalı mesajda (tek parçalı mesaja dahil edilen makbuzları gösteren şekil 17'ye bakın). Makbuzların alınması. Katılımcıların (hem blok üreticileri hem de validator'ler) tek parçalı mesajları alana kadar blokları işlemediklerini unutmayın. blokta yer alan her parça için. Böylece, herhangi bir katılımcı B bloğunu uyguladığında, B bloğuna karşılık gelen tüm tek parçalı mesajlara sahip olur. B'deki parçalar ve dolayısıyla parçaların bulunduğu tüm gelen makbuzlara sahipler katılımcı, varış yeri olarak durumunu korur. Uygularken belirli bir parça için durum geçişi, katılımcı hem makbuzları uygular tek parçalı mesajlarda parça için topladıklarının yanı sıra tüm yığının kendisinde yer alan işlemler. Şekil 18: Bir makbuz işleminin ömrü 3.6.2 Çok fazla makbuz işlemek Belirli bir parçayı hedefleyen faturaların sayısının belirli blok işlenemeyecek kadar büyük. Örneğin, şekil 19'u düşünün, her bir parçadaki her işlem, parça 1'i hedefleyen bir makbuz oluşturur. Bir sonraki blokta, parça 1'in işlemesi gereken faturaların sayısı şu şekilde olur: taşıma sırasında tüm parçaların bir araya getirdiği yükle karşılaştırılabilir önceki blok.

Şekil 19: Tüm faturalar aynı parçayı hedefliyorsa parçanın bunları işleme kapasitesi Bu sorunu çözmek için QuarkChain 9'da kullanılana benzer bir teknik kullanıyoruz. Spesifik olarak, her bir parça için son B bloğu ve onun içindeki son parça Fişlerin uygulandığı blok kaydedilir. Yeni parça ne zaman Oluşturulduğunda, fiş ilk önce B'de kalan parçalardan başlayarak uygulanır, ve sonra yeni yığın dolana kadar B'yi takip eden bloklar halinde. Normalin altında Dengeli bir yüke sahip koşullar altında, genellikle tüm tahsilatlar sonuçlanacaktır. uygulanıyor (ve böylece son bloğun son parçası kaydedilecek) her parça), ancak yükün dengeli olmadığı zamanlarda ve belirli bir Shard orantısız bir şekilde çok sayıda makbuz alıyor, bu teknik onların dahil edilen işlem sayısındaki sınırlara uyularak işlenecektir. Böyle dengesiz bir yükün uzun süre kalması durumunda gecikmenin Başvuruya kadar fiş oluşturma süresiz olarak büyümeye devam edebilir. Bir Bunu çözmenin yolu, bir hedefi hedefleyen bir makbuz oluşturan herhangi bir işlemi iptal etmektir. Belirli bir sabiti (ör. bir dönem) aşan bir işlem gecikmesine sahip olan parça. Şekil 20'yi düşünün. B bloğuna göre 4 numaralı parça tüm girişleri işleyemez, bu nedenle yalnızca A bloğundaki 3. parçaya kadar olan makbuzları işler ve onu kaydeder. C bloğunda B bloğundaki 5. parçaya kadar olan makbuzlar dahil edilir ve daha sonra D blokta parça yakalanır ve kalan tüm faturalar işlenir. B bloğu ve C bloğundaki tüm faturalar. 3.7 Parça doğrulama Belirli bir parça için üretilen bir parça (veya parça zincirli modelde belirli bir parça zinciri için üretilen bir parça bloğu) yalnızca şu şekilde doğrulanabilir: 9QuarkChain ile beyaz tahta bölümünü buradan izleyin: https://www.youtube.com/watch? v=opEtG6NM4x4, diğerlerinin yanı sıra parçalar arası işlemlere yaklaşımın tartışıldığı şeylerŞekil 20: Gecikmeli makbuz işleme Devleti koruyan katılımcılar. Blok üreticileri olabilirler, validators, veya yalnızca durumu indiren ve parçayı doğrulayan harici tanıklar varlıkları depoluyorlar. Bu belgede katılımcıların çoğunluğunun depolama yapamadığını varsayıyoruz. parçaların büyük bir kısmı için devlet. Ancak şunu belirtmekte yarar var varsayımıyla tasarlanmış parçalanmış blockchain'lerin bulunduğunu çoğu katılımcının durumunu saklama ve çoğu şeyi doğrulama kapasitesi vardır. QuarkChain gibi parçalar. Katılımcıların yalnızca bir kısmı parçayı doğrulama durumuna sahip olduğundan Parçalar halinde, yalnızca aşağıdaki özelliklere sahip olan katılımcıları uyarlanabilir şekilde yozlaştırmak mümkündür. durumu seçin ve geçersiz bir durum geçişi uygulayın. Her birkaç örnekte validators içeren birden fazla parçalama tasarımı önerildi gün ve bir gün içinde parça zincirinde 2/3'ten fazla olan herhangi bir blok söz konusu parçaya atanan validator'lerin imzalarının sayısı hemen dikkate alınır son. Böyle bir yaklaşımla, uyum sağlayabilen bir düşmanın yalnızca 2n/3+1'i yozlaştırması yeterlidir Geçersiz bir durum geçişi uygulamak için bir parça zincirindeki validator'lerin sayısı; Bunu başarmak muhtemelen zor olsa da, kamuya açık bir güvenlik düzeyi yeterli değil blockchain. Bölüm 2.3'te tartışıldığı gibi, ortak yaklaşım, durumu olan herhangi bir katılımcı için bir blok oluşturulduktan sonra belirli bir zaman aralığına izin vermektir (ister geçerliliğine meydan okuyan bir blok üreticisi, bir validator veya harici bir gözlemci). Bu tür katılımcılara Balıkçı denir. Bir balıkçının bunu yapabilmesi için Geçersiz bir bloğa itiraz edilmesi durumunda, böyle bir bloğun erişime açık olduğundan emin olunmalıdır. onlar. Nightshade'deki veri kullanılabilirliği bölüm 3.4'te tartışılmaktadır. Nightshade'de bir blok üretildiğinde parçalar gerçek parça üreticisi dışında herkes. Özellikle blok üreticisi bloğun doğal olarak çoğu parça için duruma sahip olmadığını öne sürdü veparçaları doğrulayamadı. Bir sonraki blok üretildiğinde, birden fazla blok üreticisinin ve validator'lerin onaylarını (bkz. bölüm 3.2) içerir, ancak blok üreticilerinin ve validator'lerin çoğunluğu durumu korumadığından çoğu kırık için de yalnızca bir geçersiz parçaya sahip bir blok, doğrulamaların yarısından önemli ölçüde fazlasını toplayacak ve en ağır blokta yer almaya devam edecek zincir. Bu sorunu çözmek için, durumunu koruyan herhangi bir katılımcıya izin veriyoruz. bu şekilde üretilen herhangi bir geçersiz parça için zincir üzerinde bir meydan okuma gönderecek bir parça kırık. 3.7.1 Devlet geçerliliği sorunu Bir katılımcı belirli bir parçanın geçersiz olduğunu tespit ettiğinde parçanın geçersiz olduğuna dair bir kanıt sunması gerekir. Ağ katılımcılarının çoğunluğu geçersiz parçanın bulunduğu parçanın durumunu korumadığından üretildiğinde, kanıtın bloğun doğrulandığını doğrulamak için yeterli bilgiye sahip olması gerekir. devlet olmadan geçersiz. Tek bir işlemin gerçekleştirebileceği durum miktarının (bayt cinsinden) Ls sınırını belirliyoruz. toplu olarak okuyabilir veya yazabilir. L'den daha fazlasına dokunan herhangi bir işlem durum geçersiz kabul edilir. Bölüm 3.5'ten hatırlayın ki yığın belirli bir B bloğunda yalnızca uygulanacak işlemleri içerir, ancak yeni durum kökü. B bloğundaki yığının içerdiği durum kökü durumdur root, bu tür işlemleri uygulamadan önce, ancak işlemleri uyguladıktan sonra B bloğundan önceki aynı parçadaki son parça. Kötü niyetli bir aktör geçersiz bir durum geçişi uygulamak istemeniz, yanlış bir durum kökü içerecektir uygulamadan kaynaklanan durum köküne karşılık gelmeyen B bloğunda önceki parçadaki işlemler. Bir parça üreticisinin parçaya dahil ettiği bilgiyi genişletiyoruz. Tüm işlemleri uyguladıktan sonra sadece durumu dahil etmek yerine, her bir bitişik işlem kümesi uygulandıktan sonra bir durum kökü içerir. toplu olarak Ls durum baytını okur ve yazar. Bu bilgilerle birlikte balıkçının devlet geçişinin yanlış uygulandığına dair bir zorluk yaratması Bu türden ilk geçersiz durum kökünü bulmak yeterlidir ve yalnızca Ls baytını içerir. son durum kökü arasındaki işlemlerden etkilenen durum (ki bu geçerli) ve merkle kanıtlarıyla birlikte mevcut durum kökü. Daha sonra herhangi bir katılımcı segmentteki işlemleri doğrulayabilir ve parçanın olduğunu doğrulayabilir geçersiz. Benzer şekilde, yığın üreticisi şunu okuyan işlemleri dahil etmeye çalışırsa: ve Ls bayttan daha fazla durum yazın, zorluk için dahil etmek yeterlidir Merkle kanıtlarıyla dokunduğu ilk Ls baytı, bu da yeterli olacaktır. işlemleri uygulayın ve bir girişimde bulunulacağı bir anın olduğunu onaylayın Ls bayt ötesinde içerik okuma veya yazma işlemi yapılır.

3.7.2 Balıkçılar ve hızlı çapraz parça işlemleri Bölüm 2.3'te tartışıldığı gibi, parça parçalarının (veya parçanın) modeldeki parça zincirli bloklar) geçersiz olabilir ve zorluk yaratabilir Bu durum nihailiği ve dolayısıyla parçalar arası iletişimi olumsuz etkiler. içinde özellikle herhangi bir çapraz parça işleminin hedef parçası kesin olamaz kaynak parça parçası veya blok, meydan okuma süresi bitene kadar nihaidir (bkz. şekil 21). Şekil 21: Makbuz uygulamadan önce sorgulama süresinin beklenmesi Bunu, parçalar arası işlemleri gerçekleştirecek şekilde ele almanın yolu hedef parçanın meydan okuma süresini beklememesi anlıktır kaynak parça işlemi yayınlandıktan sonra ve alındı işlemini uygulayın hemen, ancak daha sonra hedef parçayı kaynakla birlikte geri alın daha sonra kaynak parçanın veya bloğun geçersiz olduğu tespit edilirse parça (bkz. şekil 22). Bu, parçanın bulunduğu Nightshade tasarımı için çok doğal olarak geçerlidir. zincirler bağımsız değildir ancak bunun yerine parça parçalarının tümü yayınlanır birlikte aynı ana zincir bloğunda. Herhangi bir parçanın geçersiz olduğu tespit edilirse, bu parçaya sahip bloğun tamamı geçersiz kabul edilir ve üzerine inşa edilen tüm bloklar üstüne. Bkz. şekil 23. Yukarıdaki yaklaşımların her ikisi de, sorunun şu şekilde olduğu varsayılarak atomiklik sağlar: süre yeterince uzundur. Normal koşullar altında hızlı çapraz parça işlemlerinin sağlanması, hedef parça, aşağıdakilerden birinde geçersiz bir durum geçişi nedeniyle geri alınıyor son derece nadir bir olay olan kaynak parçaları. 3.7.3 validators gizleniyor Zorlukların varlığı, halihazırda bu olasılığı önemli ölçüde azaltıyor. uyarlanabilir yolsuzluk, çünkü bir yığını geçersiz bir durum geçiş gönderisiyle sonuçlandırmak içinŞekil 22: Makbuzların anında uygulanması ve varış noktasına geri alınması kaynak zincirinde geçersiz bir blok varsa zincir Şekil 23: Nightshade'de balıkçı mücadelesi Adaptif düşmanın tüm katılımcıları yozlaştırması gereken meydan okuma dönemi tüm validator'ler dahil olmak üzere parçanın durumunu koruyan. Böyle bir olayın olasılığını tahmin etmek son derece karmaşıktır, çünkü hiçbir Sharded blockchain bu tür bir saldırının denenmesine yetecek kadar uzun süredir yayında. Olasılığın son derece düşük olmasına rağmen hala yeterince yüksek olduğunu savunuyoruz. Milyonlarca işlemi yürütmesi beklenen bir sistem için büyük ve dünya çapında finansal operasyonlar yürütmek. Bu inancın iki temel nedeni vardır: 1. Proof-of-Stake zincirlerinin ve madencilerin validator'lerinin çoğu

İş Kanıtı zincirleri öncelikle finansal yükselişle teşvik ediliyor. Eğer Adaptif bir düşman onlara beklenen getiriden daha fazla para teklif eder dürüst bir şekilde faaliyet göstermekten dolayı, birçok validators'nin olmasını beklemek makul olacaktır. teklifi kabul edecek. 2. Birçok kuruluş Proof-of-Stake zincirlerinin doğrulamasını profesyonelce yapar ve Herhangi bir zincirdeki hisselerin büyük bir yüzdesinin bu tür kuruluşlardan. Bu tür varlıkların sayısı bir dönem için yeterince azdır. çoğunu kişisel olarak tanımak ve bozulmaya olan eğilimlerini iyi anlıyorlar. Hangi validator'lerin hangi parçaya atandığını gizleyerek uyarlamalı bozulma olasılığını azaltma konusunda bir adım daha ileri gidiyoruz. Fikir şu Algorand [5]'nin validators'yi gizlemesine uzaktan benzer. validator'ler, Algorand'da olduğu gibi gizlenmiş olsa bile, şunu unutmamak önemlidir: veya aşağıda açıklandığı gibi, uyarlanabilir bozulma teoride hala mümkündür. iken uyarlanabilir rakip, oluşturacak veya doğrulayacak katılımcıları tanımıyor Bir blok ya da yığın halinde, katılımcılar performans sergileyeceklerini kendileri biliyorlar. böyle bir görev ve bunun kriptografik bir kanıtı var. Böylece düşman yolsuzluk yapma niyetlerini yayınlayacak ve bunu sağlayacak herhangi bir katılımcıya ödeme yapacaktır. böyle bir kriptografik kanıt. Ancak şunu da belirtmeliyiz ki, rakip bunu yapmadığından bozmak istedikleri parçaya atanan validator'leri biliyorlarsa, belirli bir parçayı bozma niyetlerini yayınlamaktan başka seçeneği yok tüm topluluk. Bu noktada herhangi bir dürüst için ekonomik olarak faydalıdır. katılımcının bu parçayı doğrulayan tam bir düğümü döndürmesi için yüksek bir söz konusu parçada geçersiz bir bloğun görünme olasılığı; bir meydan okuma yaratın ve ilgili ödülü toplayın. Belirli bir parçaya atanan validator'leri açığa çıkarmamak için şunu yaparız: aşağıdakiler (bkz. şekil 24): Ödevi almak için VRF'yi kullanma. Her çağın başında her validator, validator'nin atandığı parçaların bit maskesini almak için bir VRF kullanır. Her validator'nin bit maskesi Sw bitlerine sahip olacaktır (tanım için bölüm 3.3'e bakın) Sw). validator daha sonra karşılık gelen parçaların durumunu getirir ve Alınan her blok için dönem boyunca karşılık gelen parçaları doğrular validator öğesinin atandığı parçalara. Parçalar yerine bloklar üzerinde oturum açın. Parça ataması gizlendiğinden validator parçalar üzerinde oturum açamaz. Bunun yerine her zaman bütünü imzalar böylece hangi parçaları doğruladığını açığa çıkarmıyor. Özellikle, validator bir blok alıp tüm parçaları doğruladığında ya bir mesaj oluşturur bu, validator öğesinin atandığı tüm parçalardaki tüm parçaların geçerli (bu parçaların ne olduğunu hiçbir şekilde belirtmeden) veya herhangi bir parçanın geçersiz olması durumunda geçersiz durum geçişinin kanıtını içerir. Bkz. Bu tür mesajların nasıl bir araya getirildiğine ilişkin ayrıntılar için bölüm 3.8, aşağıdakiler için bölüm 3.7.4: validators adlı kişinin gelen iletileri arka arkaya almasının nasıl önleneceğine ilişkin ayrıntılar nasıl ödüllendirileceği ve cezalandırılacağıyla ilgili ayrıntılar için diğer validators ve bölüm 3.7.5'e bakın validators başarılı bir geçersiz durum geçiş sorunu gerçekten meydana gelirse.Şekil 24: Nightshade'de validator'leri gizlemek 3.7.4 Taahhüt-Açıklama validators ile ilgili yaygın sorunlardan biri, validator'nin durumu indirmeyi ve aslında parçaları ve blokları doğrulamayı atlayabilmesi ve bunun yerine Ağı gözlemleyin, diğer validator'ların neler gönderdiğini görün ve yaptıklarını tekrarlayın. mesajlar. Böyle bir stratejiyi izleyen bir validator fazladan bir şey sağlamaz ağ için güvenlik sağlar, ancak ödüller toplar. Bu soruna yönelik yaygın bir çözüm, her validator için bir kanıt sağlamaktır örneğin benzersiz bir izleme sağlayarak bloğu gerçekten doğruladıklarını devlet geçişini uygulamak, ancak bu tür kanıtlar maliyeti önemli ölçüde artırıyor doğrulama. Şekil 25: Taahhüt-açıklama

Bunun yerine validators'nin doğrulama sonucuna ilişkin ilk taahhüdünü yaparız (veya parçaların geçerliliğini doğrulayan mesaj veya geçersiz olduğunun kanıtı durum geçişi), belirli bir süre bekleyin ve ancak bundan sonra şekil 25'te gösterildiği gibi gerçek doğrulama sonucunu ortaya çıkarın. ortaya çıkma dönemidir ve bu nedenle tembel bir validator dürüst validator'leri taklit edemez. Ayrıca, dürüst olmayan bir validator şunu doğrulayan bir mesaj gönderirse: atanan parçaların geçerliliği ve en az bir parçanın geçersiz olması durumunda öbeğin geçersiz olduğu gösterildiğinde validator eğik çizgiden kaçınamaz, çünkü, Bölüm 3.7.5'te gösterdiğimiz gibi böyle bir durumda kesilmemenin tek yolu geçersiz durum geçişinin kanıtını içeren bir mesaj sunmaktır. taahhütle eşleşir. 3.7.5 Zorluklarla baş etme Yukarıda tartışıldığı gibi, validator geçersiz parçaya sahip bir blok aldığında, önce geçersiz durum geçişinin kanıtını hazırlarlar (bkz. bölüm 3.7.1), ardından böyle bir kanıtı taahhüt edin (bkz. 3.7.4) ve bir süre sonra zorluğu ortaya çıkarın. Ortaya çıkan zorluk bir bloğa dahil edildiğinde aşağıdakiler gerçekleşir: 1. Bloktan gerçekleşen tüm durum geçişleri Ortaya çıkan zorluğun dahil edildiği bloğa kadar geçersiz parça hükümsüz kılındı. Ortaya çıkan mücadeleyi içeren bloktan önceki durum içeren bloktan önceki durumla aynı olduğu kabul edilir geçersiz yığın. 2. Belirli bir süre içinde her validator kendi bit maskesini göstermelidir doğruladıkları parçalar. Bit maskesi bir VRF aracılığıyla oluşturulduğundan, geçersiz durum geçişine sahip olan parçaya atandılar, ifşa etmekten kaçınamaz. Bit maskesini ortaya çıkaramayan herhangi bir validator parçaya atandığı varsayılmaktadır. 3. Bu süre sonunda parçaya atandığı tespit edilen her validator, içeren blok için bazı doğrulama sonuçları taahhüt etti geçersiz yığın ve bu geçersiz durum geçişinin kanıtını ortaya çıkarmadı bu onların taahhütlerine karşılık gelir. 4. Her validator yeni bir parça ataması alır ve yeni bir dönem planlanır tüm validator'ların indirmesi için yeterli bir süre sonra başlamak üzere Şekil 26'da gösterildiği gibi. validator'lerin kendilerine atanan parçaları ortaya çıkardığı andan itibaren unutmayın yeni dönem başlayana kadar sistemin güvenliği azaltılmıştır. Shard'ın ataması ortaya çıktı. Ağın katılımcılarının bunu saklaması gerekir Bu dönemde ağı kullanırken aklınızda bulundurun. 3.8 İmza Toplama Yüzlerce parçaya sahip bir sistemin güvenli bir şekilde çalışabilmesi için, 10.000 veya daha fazla validators sırası. Bölüm 3.7'de tartışıldığı gibi, her birini istiyoruz.Şekil 26: Mücadeleyi ele almak validator ortalama olarak belirli bir mesaja ve imzaya yönelik bir taahhüt yayınlamak için blok başına bir kez. Taahhüt mesajları aynı olsa bile, böyle bir şeyin toplanması BLS imzası ve bunun doğrulanması son derece pahalı olurdu. Ama doğal olarak taahhüt ve açıklama mesajları validators genelinde aynı değildir, dolayısıyla bu tür mesajları ve imzaları bir araya getirmenin bir yoluna ihtiyacımız var. Daha sonra hızlı doğrulamaya izin veren bir yol. Kullandığımız özel yaklaşım şudur: Doğrulayıcılar blok üreticilerine katılıyor. Blok üreticileri biliniyor çağın başlamasından bir süre önce, çünkü indirmeleri için biraz zamana ihtiyaçları var. çağ başlamadan önceki durum ve validator'lerden farklı olarak blok üreticileri gizlenmedi. Her blok üreticisinin v validator yuvası vardır. Doğrulayıcılar gönderir Blok üreticilerine v'lerinden biri olarak dahil edilmeleri için zincir dışı teklifler validators. Bir blok üreticisi validator eklemek isterse, validator'den gelen ilk zincir dışı talebi içeren işlem ve validator öğesinin blok üreticisine katılmasını sağlayan blok üreticisinin imzası. Blok üreticilerine atanan validator'lerin zorunlu olarak atanmadığını unutmayın. Blok üreticisinin parçalar ürettiği aynı parçaları doğrulayın. eğer bir Birden fazla blok üreticisini birleştirmek için validator uygulandı, yalnızca işlem ilk blok üreticisi başarılı olacaktır. Blok üreticileri taahhütleri toplar. Blok üreticisi sürekli olarak validators'den taahhüt ve açıklama mesajlarını toplar. Bu tür mesajların belirli bir sayısı toplandığında, blok üreticisi bir merkle hesaplar. bu mesajların ağacını oluşturur ve her validator'e merkle kökünü ve mesajlarına giden merkle yolu. validator yolu doğrular ve imzalar merkle kökü. Blok üreticisi daha sonra blok üzerinde bir BLS imzası biriktirir. validators'den merkle kökü ve yalnızca merkle kökü ve birikmiş imza Blok üreticisi aynı zamanda sözleşmenin geçerliliğini de imzalar. Ucuz bir ECDSA imzası kullanarak çoklu imza. Çoklu imza çalışmıyorsa gönderilen merkle köküyle veya katılan validator'ların bit maskesiyle eşleşirse, bu eğik çizgi çizilebilir bir davranıştır. Zinciri senkronize ederken bir katılımcı validator'lerden gelen tüm BLS imzalarını doğrulamayı seçebilir (bu, validator'nin ortak anahtarlarının toplanmasını gerektirdiğinden son derece pahalıdır) veya yalnızcaBlok üreticilerinin ECDMA imzalarına güveniyoruz ve blok üreticisine meydan okunmadı ve kesildi. Zorluklar için zincir içi işlemleri ve merkle kanıtlarını kullanma. o eğer hayırsa validators'den gelen mesajları açığa çıkarmanın hiçbir değeri olmadığı belirtilebilir. geçersiz durum geçişi algılandı. Yalnızca gerçek bilgiyi içeren mesajlar Geçersiz durum geçişinin kanıtlarının açıklanması gerekir ve yalnızca bu tür mesajlar için önceki taahhütle eşleştiklerinin gösterilmesi gerekir. Mesajın ihtiyacı var iki amaçla ortaya çıkar: 1. Zincirin geri dönüşünü fiilen başlatmak için geçersiz durum geçişi (bkz. bölüm 3.7.5). 2. validator belgesinin geçerliliğini kanıtlamaya çalışmadığını kanıtlamak için geçersiz yığın. Her iki durumda da iki konuyu ele almamız gerekiyor: 1. Gerçek taahhüt zincire dahil edilmedi, yalnızca merkle kökü diğer mesajlarla birleştirilmiş taahhüt. validator öğesinin şunu kullanması gerekiyor: Blok üreticisi tarafından sağlanan merkle yolu ve orijinal taahhütleri bu mücadeleye kararlı olduklarını kanıtla. 2. Tüm validator'lerin geçersiz parçaya atanması mümkündür. durum geçişi bozuk blok üreticilerine atanacak bunları sansürlüyorlar. Bunu aşmak için onların açıklamalarını göndermelerine izin veriyoruz Zincir üzerinde düzenli bir işlem olarak ve toplamayı atlayarak. İkincisine yalnızca geçersiz durum geçişinin kanıtları için izin verilir; son derece nadirdir ve bu nedenle blokların spam gönderilmesiyle sonuçlanmamalıdır. Ele alınması gereken son konu, blok üreticilerinin iletilerin toplanmasına katılmamayı veya belirli validators'leri kasıtlı olarak sansürlememeyi tercih edin. Blok haline getirerek ekonomik açıdan dezavantajlı hale getiriyoruz üretici ödülü, kendilerine atanan validators sayısıyla orantılıdır. Biz ayrıca dönemler arasındaki blok üreticilerinin büyük ölçüde kesiştiğinden (çünkü her zaman en yüksek hisseye sahip olan en üstteki katılımcılardır), validator'ler yapabilir Büyük ölçüde aynı blok üreticileriyle çalışmaya devam edin ve böylece riski azaltın Geçmişte onları sansürleyen bir blok üreticisine atanmak. 3.9 Anlık Görüntü Zinciri Ana zincirdeki bloklar çok sık üretildiğinden indirme tarihin tamamı çok hızlı bir şekilde pahalı hale gelebilir. Üstelik her zamandan beri blok çok sayıda katılımcının BLS imzasını içeriyorsa, yalnızca imzayı kontrol etmek için ortak anahtarların toplanması engelleyici hale gelebilir aynı zamanda pahalı. Son olarak, öngörülebilir bir gelecekte Ethereum 1.0 muhtemelen bir tane olarak kalacak en çok kullanılan blockchain'lerden biridir ve varlıkları aktarmanın anlamlı bir yolunu sunar

Ethereum'ye yakın olması bir gerekliliktir ve bugün BLS imzalarının doğrulanması Ethereum tarafında yakın blokların geçerliliği mümkün değildir. Nightshade ana zincirindeki her blok isteğe bağlı olarak bir Schnorr içerebilir böyle bir Schnorr içeren son bloğun başlığındaki çoklu imza çoklu imza. Bu tür bloklara anlık görüntü blokları diyoruz. İlk blok her çağ bir anlık görüntü bloğu olmalıdır. Böyle bir çoklu imza üzerinde çalışırken, blok üreticileri ayrıca validators'nin BLS imzalarını da biriktirmelidir son anlık görüntü bloğuna yerleştirin ve bunları bölümünde açıklandığı şekilde toplayın. bölüm 3.8. Blok üreticilerinin belirlediği dönem boyunca sabit olduğundan doğrulama hiçbir çağda yalnızca ilk anlık görüntü blokları yeterlidir. blok üreticilerinin ve validator'lerin büyük bir yüzdesinin gizli anlaşma yapıp yarattığını gösteriyor bir çatal. Çağın ilk bloğu hesaplamaya yetecek bilgiyi içermelidir dönemin blok üreticileri ve validator'ler. Ana zincirin yalnızca anlık görüntüsünü içeren alt zincirine diyoruz. anlık görüntü zincirini engeller. Schnorr çoklu imzası oluşturmak etkileşimli bir süreçtir, ancak ne kadar verimsiz olursa olsun bunu nadiren gerçekleştirmeniz gerekir; yeterli olacaktır. Schnorr çoklu imzaları Ethereum üzerinde kolayca doğrulanabilir, böylece çapraz-blockchain gerçekleştirmenin güvenli bir yolu için önemli temel öğeler sağlanır iletişim. Yakın zincirle senkronizasyon için yalnızca tüm anlık görüntülerin indirilmesi gerekir bloklar ve Schnorr imzalarının doğru olduğunu onaylar (isteğe bağlı olarak validators'nin bireysel BLS imzalarını da doğrular) ve ardından yalnızca senkronizasyon son anlık görüntü bloğundan ana zincir blokları.

결론

이 문서에서 우리는 샤딩된 blockchain을 구축하는 방법과 기존 접근 방식의 두 가지 주요 문제, 즉 상태 타당성을 다루었습니다. 및 데이터 가용성. 그런 다음 샤딩 디자인인 Nightshade를 선보였습니다. NEAR 프로토콜에 힘을 실어줍니다. 디자인 작업이 진행 중입니다. 의견, 질문 또는 피드백이 있는 경우 이 문서에서 https://near.chat.로 이동하세요.

Çözüm

Bu belgede parçalı blockchains oluşturmaya yönelik yaklaşımları tartıştık ve mevcut yaklaşımlarla iki büyük zorluğu, yani durum geçerliliğini ele aldı ve veri kullanılabilirliği. Daha sonra bir parçalama tasarımı olan Nightshade'i sunduk. NEAR Protokolüne güç verir. Yorumlarınız, sorularınız veya geri bildirimleriniz varsa tasarım üzerinde çalışma devam etmektedir bu belgede lütfen https://near.chat. adresine gidin