NEAR ホワイトペーパー
Hiệu lực của trạng thái và tính sẵn có của dữ liệu
Ý tưởng cốt lõi trong sharded blockchains là hầu hết người tham gia đều vận hành hoặc việc sử dụng mạng không thể xác thực các khối trong tất cả các phân đoạn. Như vậy, bất cứ khi nào bất kỳ người tham gia nào cũng cần tương tác với một phân đoạn cụ thể mà họ thường không thể tải xuống và xác thực toàn bộ lịch sử của phân đoạn. Tuy nhiên, khía cạnh phân vùng của sharding làm tăng tiềm năng đáng kể vấn đề: không tải xuống và xác thực toàn bộ lịch sử của một ứng dụng cụ thể phân đoạn, người tham gia không nhất thiết phải chắc chắn rằng trạng thái của nó 5Phần này, ngoại trừ tiểu mục 2.5.3, đã được xuất bản trước đây tại https://near.ai/ mảnh vỡ2. Nếu bạn đã đọc nó trước đó, hãy chuyển sang phần tiếp theo.
chúng tương tác với nhau là kết quả của một chuỗi khối hợp lệ nào đó và chuỗi đó của các khối thực sự là chuỗi chuẩn trong phân đoạn. Một vấn đề không tồn tại trong blockchain không được phân chia. Đầu tiên chúng tôi sẽ trình bày một giải pháp đơn giản cho vấn đề này đã được đề xuất bằng nhiều giao thức và sau đó phân tích xem giải pháp này có thể bị hỏng như thế nào và điều gì đã có những nỗ lực để giải quyết nó. 2.1 Xoay vòng xác thực Giải pháp đơn giản cho tính hợp lệ của trạng thái được thể hiện trên hình 5: giả sử chúng ta giả sử mà toàn bộ hệ thống có khoảng hàng nghìn validator, trong đó không quá 20% là độc hại hoặc sẽ thất bại (chẳng hạn như không thể trực tuyến để tạo ra một khối). Sau đó, nếu chúng ta lấy mẫu 200 validators thì xác suất nhiều hơn 1 3 không đạt trong mục đích thực tế có thể được coi là bằng không. Hình 5: Đang lấy mẫu validators 1 3 là một ngưỡng quan trọng. Có một nhóm các giao thức đồng thuận, được gọi là BFT giao thức đồng thuận, đảm bảo rằng chỉ cần ít hơn 1 3 trong số người tham gia thất bại, do vi phạm hoặc do hành động theo cách nào đó vi phạm giao thức thì sẽ đạt được sự đồng thuận. Với giả định về tỷ lệ phần trăm validator trung thực này, nếu tập hợp hiện tại validator trong một phân đoạn cung cấp cho chúng ta một số khối, giải pháp ngây thơ giả định rằng khối đó hợp lệ và nó được xây dựng dựa trên những gì validator được cho là chuỗi chuẩn cho phân đoạn đó khi họ bắt đầu xác thực. validators đã học chuỗi chuẩn từ tập hợp validator trước đó, cũng bằng cách đó giả định được xây dựng trên khối đứng đầu chuỗi kinh điển trước đó. Bằng quy nạp, toàn bộ chuỗi là hợp lệ và vì không có tập hợp validator nào tại bất kỳ thời điểm nào sản xuất nĩa, giải pháp ngây thơ cũng chắc chắn rằng hiện tại chuỗi là chuỗi duy nhất trong phân đoạn. Xem hình 6 để hình dung.
Hình 6: blockchain với mỗi khối được hoàn tất thông qua sự đồng thuận BFT Giải pháp đơn giản này sẽ không hiệu quả nếu chúng ta giả sử rằng validator có thể bị hỏng một cách thích ứng, đây không phải là một giả định vô lý6. Thích ứng làm hỏng một phân đoạn trong hệ thống có 1000 phân đoạn sẽ rẻ hơn đáng kể hơn là làm hỏng toàn bộ hệ thống. Do đó, tính bảo mật của giao thức giảm tuyến tính theo số lượng phân đoạn. Để có sự chắc chắn về tính hợp lệ của một khối, chúng ta phải biết rằng tại bất kỳ thời điểm nào trong lịch sử không có phân đoạn nào trong hệ thống có phần lớn validator thông đồng; với những đối thủ có khả năng thích ứng, chúng ta không còn có sự chắc chắn như vậy. Như chúng ta đã thảo luận trong phần 1.5, việc thông đồng với validator có thể gây ảnh hưởng hai hành vi độc hại cơ bản: tạo nhánh và tạo các khối không hợp lệ. Các nhánh độc hại có thể được xử lý bằng các khối được liên kết chéo với chuỗi Beacon thường được thiết kế để có độ bảo mật cao hơn đáng kể so với các chuỗi khác. những chuỗi mảnh vỡ. Tuy nhiên, việc tạo ra các khối không hợp lệ là một vấn đề đáng kể hơn. vấn đề đầy thách thức cần giải quyết. 2.2 Hiệu lực của tiểu bang Hãy xem hình 7 trong đó Shard #1 bị hỏng và một tác nhân độc hại tạo ra khối B không hợp lệ. Giả sử trong khối B này 1000 token được đúc từ mỏng phát sóng trên tài khoản của Alice. Sau đó, tác nhân độc hại tạo ra khối C hợp lệ (trong một cảm thấy rằng các giao dịch trong C được áp dụng chính xác) trên B, làm xáo trộn khối B không hợp lệ và bắt đầu giao dịch chéo tới Phân đoạn số 2 chuyển 1000 tokens đó vào tài khoản của Bob. Từ lúc này trở đi không đúng cách đã tạo token nằm trên blockchain hoàn toàn hợp lệ trong Phân đoạn #2. Một số cách tiếp cận đơn giản để giải quyết vấn đề này là: 6Đọc cái này bài viết cho chi tiết trên làm thế nào thích nghi tham nhũng có thể được mang theo ra: https://medium.com/nearprotocol/d859adb464c8. cho hơn thế nữa chi tiết trên thích nghi tham nhũng, đọc https://github.com/ethereum/wiki/wiki/Sharding-FAQ# mô hình bảo mật mà chúng tôi đang vận hành là gìHình 7: Giao dịch chéo từ chuỗi có khối không hợp lệ 1. Dành cho validator của Phân đoạn số 2 để xác thực khối nơi giao dịch được thực hiện được khởi xướng. Điều này sẽ không hoạt động ngay cả trong ví dụ trên, vì khối C dường như hoàn toàn hợp lệ. 2. Dành cho validator trong Phân đoạn số 2 để xác thực một số lượng lớn khối trước khối mà giao dịch được bắt đầu. Đương nhiên, đối với bất kỳ số lượng khối N nào được xác nhận bởi phân đoạn nhận độc hại validators có thể tạo N+1 khối hợp lệ lên trên khối không hợp lệ mà họ được sản xuất. Một ý tưởng đầy hứa hẹn để giải quyết vấn đề này là sắp xếp các mảnh thành một đồ thị vô hướng trong đó mỗi phân đoạn được kết nối với một số phân đoạn khác và chỉ cho phép giao dịch chéo giữa các phân đoạn lân cận (ví dụ: đây là cách Về cơ bản, sharding của Vlad Zamfir hoạt động7 và ý tưởng tương tự được sử dụng trong Kadena Chuỗi mạng [1]). Nếu cần một giao dịch chéo giữa các phân đoạn không phải hàng xóm, giao dịch đó được định tuyến qua nhiều phân đoạn. Trong thiết kế này validator trong mỗi phân đoạn phải xác thực cả hai khối trong phân đoạn của chúng cũng như tất cả các khối trong tất cả các mảnh lân cận. Hãy xem xét một hình dưới đây với 10 phân đoạn, mỗi phân đoạn có bốn phân đoạn lân cận và không có phân đoạn nào yêu cầu nhiều hơn hơn hai bước nhảy cho giao tiếp chéo được hiển thị trên hình 8. Phân đoạn số 2 không chỉ xác thực blockchain của chính nó mà còn blockchain của tất cả những người hàng xóm, bao gồm cả Shard #1. Vì vậy, nếu một tác nhân độc hại trên Shard #1 đang cố gắng tạo khối B không hợp lệ, sau đó xây dựng khối C lên trên khối đó và bắt đầu một giao dịch chéo, giao dịch chéo đó sẽ không diễn ra kể từ khi Phân đoạn số 2 sẽ xác thực toàn bộ lịch sử của Phân đoạn số 1 sẽ khiến nó xác định khối B không hợp lệ. 7Đọc thêm về thiết kế tại đây: https://medium.com/nearprotocol/37e538177ed9
Hình 8: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ bị phát hiện Mặc dù việc làm hỏng một phân đoạn không còn là một cuộc tấn công khả thi nữa, việc làm hỏng một vài mảnh vẫn còn là một vấn đề. Trên hình 9, một đối thủ đang làm hỏng cả Shard
1 và Shard #2 thực hiện thành công giao dịch chéo tới Shard #3
với số tiền từ khối B không hợp lệ: Hình 9: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ không bị phát hiện Phân đoạn số 3 xác thực tất cả các khối trong Phân đoạn số 2, nhưng không có trong Phân đoạn số 1 và không có cách nào để phát hiện khối độc hại. Có hai hướng chính để giải quyết đúng đắn tính hợp lệ của trạng thái:
và bằng chứng mật mã của tính toán. 2.3 ngư dân Ý tưởng đằng sau cách tiếp cận đầu tiên là như sau: bất cứ khi nào một tiêu đề khối được truyền đạt giữa các chuỗi vì bất kỳ mục đích nào (chẳng hạn như liên kết chéo với chuỗi đèn hiệu hoặc giao dịch chéo), có một khoảng thời gian trong mà bất kỳ validator trung thực nào cũng có thể cung cấp bằng chứng cho thấy khối không hợp lệ. Ở đó là những công trình khác nhau cho phép chứng minh rất ngắn gọn rằng các khối không hợp lệ, do đó chi phí liên lạc cho các nút nhận sẽ nhỏ hơn nhiều hơn là nhận được một khối đầy đủ. Với cách tiếp cận này miễn là có ít nhất một validator trung thực trong mảnh vỡ, hệ thống được an toàn. Hình 10: ngư dân Đây là cách tiếp cận chủ đạo (ngoài việc giả vờ như vấn đề không tồn tại) trong số các giao thức được đề xuất hiện nay. Tuy nhiên, cách tiếp cận này có hai nhược điểm lớn: 1. Thời gian thử thách cần phải đủ dài đối với người trung thực validator để nhận biết một khối đã được tạo, tải xuống, xác minh đầy đủ và chuẩn bị thử thách nếu khối không hợp lệ. Giới thiệu một thời kỳ như vậy sẽ làm chậm đáng kể các giao dịch chéo. 2. Sự tồn tại của giao thức thử thách tạo ra một hướng tấn công mới khi các nút độc hại spam với các thách thức không hợp lệ. Một giải pháp rõ ràng của vấn đề này là bắt những người thách đấu gửi một số tiền tokens được trả lại nếu thử thách hợp lệ. Đây chỉ là giải pháp một phần vì nó vẫn có thể có lợi cho kẻ thù gửi thư rác vào hệ thống (và đốt cháy tiền gửi) với những thách thức không hợp lệ, ví dụ để ngăn chặn hợp lệthách thức từ validator trung thực khi vượt qua. Những cuộc tấn công này là được gọi là Cuộc tấn công đau buồn. Xem phần 3.7.2 để biết cách giải quyết điểm sau. 2.4 Lập luận ngắn gọn về kiến thức không tương tác Giải pháp thứ hai cho vấn đề hỏng nhiều phân đoạn là sử dụng một số loại cấu trúc mật mã cho phép người ta chứng minh rằng một tính toán nhất định (chẳng hạn như như việc tính toán một khối từ một tập hợp các giao dịch) đã được thực hiện chính xác. Những công trình như vậy tồn tại, ví dụ: zk-SNARK, zk-STARK và một số loại khác, và một số được sử dụng tích cực trong các giao thức blockchain ngày nay để thanh toán riêng tư, đáng chú ý nhất là ZCash. Vấn đề chính với những thứ nguyên thủy như vậy là chúng nổi tiếng là tính toán chậm. Ví dụ. Giao thức Coda, sử dụng zk-SNARK cụ thể là để chứng minh rằng tất cả các khối trong blockchain đều hợp lệ, được nói trong một trong số các cuộc phỏng vấn rằng có thể mất 30 giây cho mỗi giao dịch để tạo bằng chứng (con số này có lẽ bây giờ đã nhỏ hơn). Điều thú vị là, bằng chứng không cần phải được tính toán bởi một bên đáng tin cậy, vì bằng chứng không chỉ chứng thực tính hợp lệ của tính toán mà nó được xây dựng mà còn giá trị pháp lý của chính bằng chứng. Vì vậy, việc tính toán các chứng minh đó có thể được chia giữa một nhóm người tham gia với mức độ dư thừa ít hơn đáng kể so với cần thiết để thực hiện một số tính toán không tin cậy. Nó cũng cho phép người tham gia những người tính toán zk-SNARK để chạy trên phần cứng đặc biệt mà không làm giảm phi tập trung hóa hệ thống. Những thách thức của zk-SNARK, ngoài hiệu suất, là: 1. Sự phụ thuộc vào các mật mã nguyên thủy ít được nghiên cứu và thử nghiệm ít thời gian hơn; 2. ”Chất thải độc hại” — zk-SNARK phụ thuộc vào thiết lập đáng tin cậy trong đó một nhóm mọi người thực hiện một số tính toán và sau đó loại bỏ kết quả trung gian các giá trị của phép tính đó. Nếu tất cả những người tham gia thủ tục thông đồng và giữ nguyên các giá trị trung gian, có thể tạo ra bằng chứng giả; 3. Độ phức tạp cao hơn được đưa vào thiết kế hệ thống; 4. zk-SNARK chỉ hoạt động đối với một tập hợp con các phép tính có thể, do đó, một giao thức với ngôn ngữ Turing-complete smart contract sẽ không thể sử dụng SNARK để chứng minh tính hợp lệ của chuỗi. 2,5 Tính sẵn có của dữ liệu Vấn đề thứ hai chúng ta sẽ đề cập đến là tính sẵn có của dữ liệu. Nói chung các nút việc vận hành một blockchain cụ thể được tách thành hai nhóm: Nút đầy đủ, những thứ tải xuống mọi khối đầy đủ và xác thực mọi giao dịch và Light Các nút chỉ tải xuống tiêu đề khối và sử dụng bằng chứng Merkle cho các bộ phận của nhà nước và các giao dịch mà họ quan tâm, như thể hiện trên hình 11.
Hình 11: Cây Merkle Bây giờ nếu phần lớn các nút đầy đủ thông đồng với nhau, chúng có thể tạo ra một khối, hợp lệ hoặc không hợp lệ và gửi hash của nó tới các nút ánh sáng nhưng không bao giờ tiết lộ toàn bộ nội dung của khối. Có nhiều cách khác nhau để họ có thể hưởng lợi từ nó. Ví dụ, xét hình 12: Hình 12: Vấn đề về tính sẵn có của dữ liệu Có ba khối: khối trước, A, được tạo bởi validators trung thực; hiện tại, B, có validator thông đồng; và loại tiếp theo, C, cũng sẽ được sản xuất bởi validators trung thực (blockchain được mô tả ở góc dưới cùng bên phải). Bạn là một thương gia. validators của khối hiện tại (B) đã nhận được khối A từ validator trước đó, đã tính toán một khối trong đó bạn nhận được tiền,và gửi cho bạn tiêu đề của khối đó cùng với bằng chứng Merkle về trạng thái bạn có tiền (hoặc bằng chứng Merkle về giao dịch hợp lệ gửi tiền cho bạn). Tin chắc rằng giao dịch đã hoàn tất, bạn cung cấp dịch vụ. Tuy nhiên, validator không bao giờ phân phối toàn bộ nội dung của khối B cho bất cứ ai. Do đó, validator trung thực của khối C không thể truy xuất khối và hoặc bị buộc phải đình trệ hệ thống hoặc xây dựng trên đỉnh A, tước bỏ tư cách của bạn người buôn tiền. Khi chúng tôi áp dụng kịch bản tương tự cho sharding, các định nghĩa về đầy đủ và nút nhẹ thường áp dụng cho mỗi phân đoạn: validators trong mỗi lần tải xuống phân đoạn chặn trong phân đoạn đó và xác thực mọi giao dịch trong phân đoạn đó, nhưng các giao dịch khác các nút trong hệ thống, bao gồm cả các nút có trạng thái chuỗi phân đoạn nhanh vào chuỗi đèn hiệu, chỉ tải xuống các tiêu đề. Do đó, validator trong phân đoạn là các nút đầy đủ hiệu quả cho phân đoạn đó, trong khi những người tham gia khác trong hệ thống, bao gồm chuỗi đèn hiệu, hoạt động như các nút ánh sáng. Để cách tiếp cận của ngư dân mà chúng ta đã thảo luận ở trên có hiệu quả, validators trung thực cần có khả năng tải xuống các khối được liên kết chéo với chuỗi đèn hiệu. Nếu validator độc hại liên kết chéo tiêu đề của một khối không hợp lệ (hoặc sử dụng nó để bắt đầu một giao dịch chéo), nhưng không bao giờ phân phối khối, thì giao dịch trung thực validator không có cách nào để tạo ra thử thách. Chúng tôi sẽ đề cập đến ba cách tiếp cận để giải quyết vấn đề này, bổ sung cho lẫn nhau. 2.5.1 Bằng chứng về quyền nuôi con Vấn đề trước mắt nhất cần giải quyết là liệu một khối có sẵn một lần hay không nó được xuất bản. Một ý tưởng được đề xuất là có cái gọi là Công chứng viên luân phiên giữa các phân đoạn thường xuyên hơn validator có công việc duy nhất là tải xuống chặn và chứng thực rằng họ có thể tải xuống nó. Họ có thể được luân chuyển thường xuyên hơn vì họ không cần tải xuống toàn bộ trạng thái của phân đoạn, không giống như validator không thể xoay thường xuyên vì chúng phải tải xuống trạng thái của phân đoạn mỗi lần chúng xoay, như thể hiện trên hình 13. Vấn đề với cách tiếp cận ngây thơ này là không thể chứng minh sau này cho dù Công chứng viên có thể tải xuống khối hay không, vì vậy Công chứng viên có thể chọn luôn chứng thực rằng họ có thể tải xuống khối mà không cần thậm chí còn cố gắng lấy lại nó. Một giải pháp cho vấn đề này là Công chứng viên cung cấp một số bằng chứng hoặc đặt cược số lượng token chứng thực rằng khối đã được đã tải xuống. Một giải pháp như vậy được thảo luận ở đây: https://ethresear.ch/t/ Trái phiếu lưu ký thân thiện với tập hợp 1 bit/2236. 2.5.2 Mã xóa Khi một nút nhẹ cụ thể nhận được hash của một khối, để tăng sức mạnh của nút đó tin rằng khối đó có sẵn, nó có thể thử tải xuống một vài thông tin ngẫu nhiên các mảnh của khối. Đây không phải là một giải pháp hoàn chỉnh, vì trừ khi các nút ánh sáng tải xuống chung toàn bộ khối mà nhà sản xuất khối độc hại có thể chọn
Hình 13: Trình xác thực cần phải tải xuống trạng thái và do đó không thể xoay được thường xuyên để giữ lại các phần của khối không được tải xuống bởi bất kỳ nút ánh sáng nào, do đó vẫn làm cho khối không có sẵn. Một giải pháp là sử dụng một cấu trúc có tên là Erasure Codes để thực hiện điều đó. để khôi phục toàn bộ khối ngay cả khi chỉ có một phần của khối, như được hiển thị trên hình 14. Hình 14: Merkle tree được xây dựng dựa trên dữ liệu đã mã hóa bị xóa Cả Polkadot và Ethereum Serenity đều có thiết kế xoay quanh ý tưởng này cung cấp một cách để các nút nhẹ có thể tin cậy một cách hợp lý rằng các khối có sẵn. Phương pháp Ethereum Serenity có mô tả chi tiết trong [2].2.5.3 Cách tiếp cận của Polkadot đối với tính khả dụng của dữ liệu Trong Polkadot, giống như trong hầu hết các giải pháp phân đoạn, mỗi phân đoạn (được gọi là parachain) chụp nhanh các khối của nó vào chuỗi báo hiệu (được gọi là chuỗi chuyển tiếp). Giả sử có 2f + 1 validator trên chuỗi chuyển tiếp. Các nhà sản xuất khối của khối parachain, được gọi là đối chiếu, sau khi khối parachain được tạo ra, hãy tính toán một phiên bản mã hóa xóa của khối bao gồm 2f +1 phần sao cho bất kỳ phần f nào cũng đủ để xây dựng lại khối. Sau đó, họ phân phối một phần cho mỗi validator trên chuỗi rơle. Chuỗi chuyển tiếp cụ thể validator sẽ chỉ đăng nhập vào chuỗi chuyển tiếp khối nếu họ có phần của mình cho mỗi khối parachain được chụp nhanh vào khối chuỗi chuyển tiếp như vậy. Do đó, nếu khối chuỗi chuyển tiếp có chữ ký từ 2f + 1 validators và miễn là không quá f trong số chúng vi phạm giao thức, mỗi khối parachain có thể được xây dựng lại bằng cách tìm nạp các phần từ validators tuân theo giao thức. Xem hình 15. Hình 15: Tính khả dụng của dữ liệu Polkadot 2.5.4 Tính sẵn có của dữ liệu dài hạn Lưu ý rằng tất cả các phương pháp được thảo luận ở trên chỉ chứng thực thực tế là một khối đã được xuất bản và hiện có sẵn. Các khối sau này có thể không còn khả dụng vì nhiều lý do: các nút ngoại tuyến, các nút cố tình xóa lịch sử dữ liệu và những thứ khác. Sách trắng đáng được đề cập giải quyết vấn đề này là Polyshard [3], sử dụng mã xóa để cung cấp các khối trên các phân đoạn ngay cả khi một số mảnh vỡ hoàn toàn mất dữ liệu của họ. Thật không may, cách tiếp cận cụ thể của họ đòi hỏi tất cả các phân đoạn để tải xuống các khối từ tất cả các phân đoạn khác, điều này bị cấm đắt tiền. Tính khả dụng lâu dài không phải là vấn đề cấp bách: vì không có người tham gia trong hệ thống dự kiến sẽ có khả năng xác nhận tất cả các chuỗi trong tất cả
phân đoạn, tính bảo mật của giao thức phân đoạn cần phải được thiết kế theo cách cách mà hệ thống được an toàn ngay cả khi một số khối cũ trong một số phân đoạn trở thành hoàn toàn không có sẵn.
状態の有効性とデータの可用性
シャード化された blockchains の中心的な考え方は、ほとんどの参加者が操作または ネットワークを使用すると、すべてのシャード内のブロックを検証できません。このように、いつでも 参加者は通常はできない特定のシャードと対話する必要があります シャードの履歴全体をダウンロードして検証します。 ただし、シャーディングのパーティショニングの側面により、大きな可能性が高まります。 問題: 特定の履歴全体をダウンロードして検証しないと 参加者は、シャードの状態がどのような状態であるかを必ずしも確信できるわけではありません。 5このセクションは、サブセクション 2.5.3 を除き、https://near.ai/ で以前に公開されました。 シャード2。すでに読んでいる場合は、次のセクションに進んでください。
それらの相互作用は、ブロックの有効なシーケンスの結果であり、そのシーケンスは of block は確かにシャード内の正規チェーンです。そうならない問題 シャード化されていない blockchain に存在します。 まず、この問題に対して提案されている簡単な解決策を紹介します。 多くのプロトコルで解析し、このソリューションがどのように壊れるか、何が壊れるかを分析します。 それに対処する試みがなされてきました。 2.1 バリデーターのローテーション 状態の妥当性に対する素朴な解決策を図 5 に示します。 システム全体には数千個の validator があり、そのうち 悪意のあるもの、またはそうでなければ失敗するものは 20% 未満です (たとえば、 オンラインでブロックを生成します)。次に、200 validator をサンプリングすると、確率は 1つ以上の 実用的な目的での 3 つの失敗はゼロであると想定できます。 図5: validators をサンプリングしています 1 3 は重要なしきい値です。と呼ばれるコンセンサスプロトコルのファミリーがあります。 BFT コンセンサス プロトコル。1 未満である限りそれを保証します。 3の 参加者は、クラッシュするか、何らかの方法でルールに違反する動作をすることによって失敗します。 議定書では合意が得られます。 この正直な validator パーセンテージを仮定すると、現在のセットが シャード内の validators はいくつかのブロックを提供します。素朴な解決策では次のように仮定します。 ブロックが有効であり、validator が信じているものに基づいて構築されていること 検証を開始したときのそのシャードの正規チェーン。 validator さん 以前の validator セットから正規チェーンを学習しました。 正規チェーンの先頭であるブロックの上に構築された仮定 その前に。帰納法により、チェーン全体が有効になり、validator のセットがないため、 フォークが生成されたどの時点でも、単純な解決策では、現在の チェーンはシャード内の唯一のチェーンです。視覚化については、図 6 を参照してください。
図6: BFT コンセンサスを介して最終化された各ブロックを含む blockchain validator が次の可能性があると仮定すると、この単純な解決策は機能しません。 適応的に破損しますが、これは不合理な仮定ではありません6。適応的に 1,000 個のシャードがあるシステム内の 1 つのシャードを破損する方が大幅にコストが安くなります システム全体を破壊するよりも。したがって、プロトコルのセキュリティはシャードの数に応じて直線的に低下します。有効性について確実性を持たせるためには、 ブロックである場合、歴史のどの時点においても、システム内のシャードにはブロックが存在しないことを知っておく必要があります。 validator の大多数が共謀している。適応的な敵対者にとって、私たちはもはや そのような確実性。セクション 1.5 で説明したように、共謀した validator は、行使できる可能性があります。 2 つの基本的な悪意のある動作: フォークの作成と無効なブロックの生成。 悪意のあるフォークは、ブロックがビーコン チェーンにクロスリンクされることで対処できます。ビーコン チェーンは一般に、ビーコン チェーンよりも大幅に高いセキュリティを持つように設計されています。 シャードチェーン。 ただし、無効なブロックの生成はさらに重要です。 取り組むべき困難な問題。 2.2 状態の有効性 図 7 では、シャード #1 が破損し、悪意のある攻撃者によって生成されたものを考えてみましょう。 無効なブロック B。このブロック B で 1000 個の token が薄いブロックから鋳造されたとします。 アリスのアカウントで放送します。次に、悪意のある攻撃者は有効なブロック C を生成します ( C のトランザクションが正しく適用されていることを意味します）B の上に重ねて難読化します 無効なブロック B を削除し、シャード #2 へのクロスシャード トランザクションを開始します。 これら 1000 token をボブのアカウントに転送します。この瞬間から、不適切な 作成された token は、シャード #2 の完全に有効な blockchain に存在します。 この問題に対処する簡単なアプローチは次のとおりです。 6読む これ 記事 のために 詳細 に どうやって 適応的な 汚職 できる なる 運ばれた アウト: https://medium.com/nearprotocol/d859adb464c8. のために もっと見る 詳細 に 適応的な 汚職、 読む https://github.com/ethereum/wiki/wiki/Sharding-FAQ# 私たちが運用しているセキュリティモデルとは何ですか図 7: 無効なブロックを持つチェーンからのクロスシャード トランザクション 1. シャード #2 の validator について、トランザクションの送信元のブロックを検証します。 が開始されます。ブロック C があるため、上記の例でもこれは機能しません。 完全に有効であると思われます。 2. シャード #2 の validator については、トランザクションが開始されるブロックに先行する多数のブロックを検証します。当然のことながら、 受信シャードによって検証された任意の数のブロック N validators は、無効なブロックの上に N+1 個の有効なブロックを作成できます。 生産された。 この問題を解決する有望なアイデアは、シャードを配置して 各シャードが他のいくつかのシャードに接続されている無向グラフ、および 隣接するシャード間のクロスシャードトランザクションのみを許可します（例：これが方法です） Vlad Zamfir のシャーディングは基本的に機能し7、同様のアイデアが嘉手納のシャーディングでも使用されています。 チェーンウェブ [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 つの方向があります。
そして暗号による計算の証明。 2.3 漁師 最初のアプローチの背後にある考え方は次のとおりです。 あらゆる目的（チェーンへのクロスリンクなど）でチェーン間で通信されます。 ビーコン チェーン、またはクロスシャード トランザクション）、次の期間があります。 正直な validator であれば、ブロックが無効であるという証拠を提供できます。そこに ブロックが存在するという非常に簡潔な証明を可能にするさまざまな構造です。 無効であるため、受信ノードの通信オーバーヘッドははるかに小さくなります。 フルブロックを受信するよりも。 このアプローチは、少なくとも 1 つの正直な validator が存在する限り、 シャード、システムは安全です。 図 10: 漁師 これは、現在提案されているプロトコルの中で (問題が存在しないふりをすることを除けば) 主流のアプローチです。 ただし、このアプローチには次の 2 つの点があります。 主な欠点: 1. 正直な validator にとって、チャレンジ期間は十分に長い必要があります ブロックが生成されたことを認識し、ダウンロードし、完全に検証し、準備する ブロックが無効な場合のチャレンジ。 このような期間を導入すると、 シャード間のトランザクションが大幅に遅くなります。 2. チャレンジプロトコルの存在が新たな攻撃ベクトルを生み出す 悪意のあるノードが無効なチャレンジでスパムを送信した場合。明らかな解決策 この問題には、挑戦者にある程度の token を預けさせる必要があります。 チャレンジが有効な場合は返されます。これは部分的な解決策にすぎません。 敵対者がシステムにスパムを送信する（そして焼き付ける）ことが依然として有益である可能性があります。 デポジット) に無効なチャレンジが含まれる場合 (たとえば、有効なチャレンジを防ぐため)正直な validator からの挑戦です。これらの攻撃は、 グリービングアタックと呼ばれます。 後者の点を回避する方法については、セクション 3.7.2 を参照してください。 2.4 知識に関する簡潔な非対話型議論 複数のシャードの破損に対する 2 番目の解決策は、特定の計算 (たとえば、 トランザクションのセットからブロックを計算するなど) は正しく実行されました。 このような構造は実際に存在します。 zk-SNARK、zk-STARK、その他いくつか、 一部は今日、プライベートな支払いのためにblockchainプロトコルで積極的に使用されています。 最も注目すべきはZCashです。このようなプリミティブの主な問題は、 計算が遅いことで有名です。例えば。 zk-SNARK を使用する Coda プロトコル 特に、blockchain 内のすべてのブロックが有効であることを証明するためであると、ある論文では述べられています。 証拠を作成するのに 1 件の取引につき 30 秒かかる可能性があるというインタビューの結果 (この数字はおそらく今ではもっと小さくなっているでしょう)。 興味深いことに、証明は信頼できる当事者によって計算される必要はありません。 この証明は、その目的で構築された計算の正当性を証明するだけでなく、 証明そのものの有効性。したがって、そのような証明の計算は分割できます。 冗長性が従来よりも大幅に低い参加者のセットの間で行われます。 トラストレス計算を実行するために必要です。参加者も可能です zk-SNARK を計算して、特殊なハードウェア上で実行するために、 システムの分散化。 zk-SNARK には、パフォーマンス以外にも次のような課題があります。 1. 研究が少なく、テストもあまり行われていない暗号プリミティブへの依存。 2. 「有毒廃棄物」 — zk-SNARK は、グループが連携する信頼できるセットアップに依存しています。 の人々が何らかの計算を実行し、中間計算を破棄します。 その計算の値。手続き参加者全員が共謀した場合 中間値を保持すると、偽の証明を作成できます。 3. システム設計に余分な複雑さが導入される。 4. zk-SNARK は可能な計算のサブセットに対してのみ機能するため、プロトコル チューリング完全な smart contract 言語では使用できません チェーンの正当性を証明するためのSNARK。 2.5 データの可用性 2 番目の問題については、データの可用性について触れます。一般にノード 特定の blockchain を操作するノードは、フル ノード、 すべての完全なブロックをダウンロードし、すべてのトランザクションを検証するものと、ライト ブロックヘッダーのみをダウンロードし、パーツにマークル証明を使用するノード 図 11 に示すように、関心のある状態とトランザクションを確認します。
図 11: マークルツリー フルノードの大多数が結託した場合、有効または無効のブロックを生成できるようになりました。 無効であり、その hash をライト ノードに送信しますが、完全な内容は決して公開しないでください ブロックの。そこから利益を得ることができるさまざまな方法があります。たとえば、 図 12 を考えてみましょう。 図 12: データの可用性の問題 3 つのブロックがあります。前の A は、正直な validators によって生成されます。 現在の B には validator が共謀しています。そして次のCも生産されます 正直なvalidatorsによるものです（blockchainは右下隅に描かれています）。 あなたは商人です。現在のブロック (B) の validator がブロックを受信しました 以前の validator から、お金を受け取るブロックを計算しました。そして、そのブロックのヘッダーを状態のマークル証明とともに送信しました。 お金を持っていること（またはお金を送金する有効な取引のマークル証明） あなたへ）。取引が完了したと確信してサービスを提供してください。 ただし、validator はブロック B の完全なコンテンツを配布することはありません。 誰でも。そのため、ブロック C の正直な validator はブロックを取得できません。 システムを停止させるか、A の上に構築することを強いられ、 お金の商人。 同じシナリオをシャーディングに適用すると、フルとシャーディングの定義は次のようになります。 ライト ノードは通常、シャードごとに適用されます: 各シャードの validators のダウンロード間隔 そのシャード内でブロックし、そのシャード内のすべてのトランザクションを検証しますが、その他の システム内のノード (スナップショット シャード チェーンの状態を含むノードも含む) ビーコン チェーンでは、ヘッダーのみをダウンロードします。したがって、シャード内の validator は次のようになります。 そのシャードのノードが効率的にフルになる一方で、システム内の他の参加者は、 ビーコンチェーンを含め、ライトノードとして動作します。 上で説明した漁師のアプローチが機能するには、正直なvalidators ビーコンチェーンにクロスリンクされたブロックをダウンロードできる必要があります。 悪意のある validator が無効なブロックのヘッダーをクロスリンクした場合 (またはそれを使用した場合) クロスシャードトランザクションを開始します）が、ブロックを配布することはありませんでした。 validator には課題を作成する方法がありません。 この問題に対処するための 3 つのアプローチを説明します。 お互いに。 2.5.1 保管証明 解決すべき最も差し迫った問題は、ブロックが一度利用できるかどうかです。 それは出版されています。 提案されたアイデアの 1 つは、いわゆる公証人を交代で配置することです。 シャード間での使用頻度は、 ブロックして、ダウンロードできたという事実を証明します。それらは可能です 状態全体をダウンロードする必要がないため、より頻繁にローテーションされます 頻繁にローテーションできない validator とは異なり、シャードの 図に示すように、シャードが回転するたびにシャードの状態をダウンロードする必要があります 13. この素朴なアプローチの問題は、後で証明することが不可能であることです。 公証人がブロックをダウンロードできたかどうかにかかわらず、公証人は ブロックをダウンロードすることなくブロックをダウンロードできたことを常に証明することを選択できます。 それを取り戻そうとしたとしても。これに対する解決策の 1 つは、公証人が提供するものです。 ブロックがあったことを証明する何らかの証拠、またはある程度の token を賭ける ダウンロードされました。そのようなソリューションの 1 つがここで説明されています: https://ethresear.ch/t/ 1 ビット アグリゲーションに優しいカストディ ボンド/2236。 2.5.2 消去コード 特定のライト ノードがブロックの hash を受信すると、ノードの ブロックが利用可能であるという確信があれば、いくつかのランダムなダウンロードを試みることができます ブロックの破片。これは完全な解決策ではありません。 悪意のあるブロック作成者が選択できるブロック全体をまとめてダウンロードする
図 13: バリデーターは状態をダウンロードする必要があるため、ローテーションできません 頻繁に ライトノードによってダウンロードされなかったブロックの部分を差し控えるため、 したがって、ブロックは引き続き使用できなくなります。 1 つの解決策は、イレイジャー コードと呼ばれる構造を使用して、それを可能にすることです。 図に示すように、ブロックの一部しか利用できない場合でも、ブロック全体を復元するには 図 14 に示します。 図 14: Merkle tree イレイジャーコーディングされたデータの上に構築 Polkadot と Ethereum Serenity は両方とも、このアイデアに基づいた設計を行っています。 ライトノードがブロックが利用可能であることを十分に確信できる方法を提供します。 Ethereum Serenity アプローチについては、[2] で詳しく説明されています。2.5.3 Polkadot のデータ可用性に対するアプローチ Polkadot では、ほとんどのシャード ソリューションと同様に、各シャード (パラチェーンと呼ばれます) がそのブロックのスナップショットをビーコン チェーン (リレー チェーンと呼ばれます) に作成します。 2f + 1があるとします。 リレーチェーン上のvalidator。パラチェーンブロックのブロックプロデューサーは、と呼ばれます コレーターは、パラチェーン ブロックが生成されると、任意の f 部分が十分になるように、2f +1 個の部分で構成されるブロックの消失符号化バージョンを計算します。 ブロックを再構築します。次に、各 validator に 1 つのパートを配布します。 リレーチェーン。特定のリレー チェーン validator はリレー チェーンにのみ署名します スナップショットが作成される各パラチェーン ブロックのパートがある場合は、ブロックします。 そんなリレーチェーンブロック。したがって、リレー チェーン ブロックに 2f + 1 からの署名がある場合、 validator 件、そのうち f 件以下がプロトコルに違反しない限り、それぞれ パラチェーン ブロックは、validators からパーツをフェッチすることで再構築できます。 プロトコルに従うもの。図 15 を参照してください。 図 15: Polkadot のデータの可用性 2.5.4 長期的なデータの可用性 上で説明したすべてのアプローチは、ブロックが すでに出版されており、現在も入手可能です。ブロックは後で使用できなくなる可能性があります さまざまな理由で: ノードがオフラインになる、ノードが意図的に履歴を消去する データ、その他。 この問題に対処する注目に値するホワイトペーパーは、Polyshard [3] です。 これは消去コードを使用して、複数のシャードが存在する場合でもブロックをまたがって利用できるようにします。 シャードはデータを完全に失います。残念ながら、彼らの具体的なアプローチには次のことが必要です すべてのシャードが他のすべてのシャードからブロックをダウンロードすることは法外です 高価な。 長期的な可用性は、参加者がいないため、それほど差し迫った問題ではありません。 システムでは、すべてのチェーンのすべてを検証できることが期待されます。
シャードの場合、シャード プロトコルのセキュリティは次のように設計する必要があります。 たとえ一部のシャード内の古いブロックが壊れたとしてもシステムが安全である方法 完全に利用不可。
Nightshade
3.1 Từ chuỗi mảnh đến mảnh vỡ Mô hình sharding với chuỗi phân đoạn và chuỗi đèn hiệu rất mạnh mẽ nhưng có những phức tạp nhất định. Đặc biệt, quy tắc lựa chọn ngã ba cần được thực thi trong mỗi chuỗi riêng biệt, quy tắc lựa chọn ngã ba trong chuỗi phân đoạn và đèn hiệu chuỗi phải được xây dựng khác nhau và được thử nghiệm riêng biệt. Trong Nightshade, chúng tôi lập mô hình hệ thống dưới dạng một blockchain duy nhất, trong đó mỗi khối chứa tất cả các giao dịch cho tất cả các phân đoạn một cách hợp lý và thay đổi toàn bộ trạng thái của tất cả các mảnh vỡ. Tuy nhiên, về mặt vật lý, không có người tham gia nào tải xuống trạng thái đầy đủ hoặc khối logic đầy đủ. Thay vào đó, mỗi người tham gia mạng chỉ duy trì trạng thái tương ứng với các phân đoạn mà họ xác thực giao dịch và danh sách tất cả các giao dịch trong khối được chia thành các phần vật lý khối, một khối cho mỗi mảnh. Trong điều kiện lý tưởng, mỗi khối chứa chính xác một đoạn trên mỗi phân đoạn. khối, gần tương ứng với mô hình với các chuỗi phân đoạn trong đó chuỗi phân đoạn tạo ra các khối có cùng tốc độ với chuỗi đèn hiệu. Tuy nhiên, do sự chậm trễ của mạng, một số khối có thể bị thiếu, vì vậy trong thực tế mỗi khối chứa một hoặc không khối trên mỗi phân đoạn. Xem phần 3.3 để biết chi tiết về cách khối được sản xuất. Hình 16: Một mô hình có các chuỗi mảnh ở bên trái và có một chuỗi có các khối được chia thành các khối bên phải
3.2 Sự đồng thuận Hai cách tiếp cận chủ yếu để đạt được sự đồng thuận trong blockchain ngày nay là chuỗi dài nhất (hoặc nặng nhất), trong đó chuỗi có nhiều công việc hoặc cổ phần nhất được sử dụng để xây dựng nó được coi là chuẩn và BFT, trong đó đối với mỗi khối một số tập hợp validator đạt được sự đồng thuận BFT. Trong các giao thức được đề xuất gần đây thì cách thứ hai là cách tiếp cận ưu việt hơn, vì nó cung cấp tính hữu hạn ngay lập tức, trong khi ở chuỗi dài nhất cần nhiều khối hơn được xây dựng trên đỉnh của khối để đảm bảo tính cuối cùng. Thường vì một ý nghĩa bảo mật mất thời gian để xây dựng đủ số khối thứ tự giờ. Việc sử dụng sự đồng thuận BFT trên mỗi khối cũng có những nhược điểm, chẳng hạn như: 1. BFT sự đồng thuận đòi hỏi lượng trao đổi đáng kể. Trong khi những tiến bộ gần đây cho phép đạt được sự đồng thuận trong thời gian tuyến tính về số lượng của người tham gia (xem ví dụ: [4]), chi phí này vẫn đáng chú ý trên mỗi khối; 2. Tất cả những người tham gia mạng lưới đều không thể tham gia BFT sự đồng thuận trên mỗi khối, do đó thường chỉ có một tập hợp con người tham gia được lấy mẫu ngẫu nhiên đạt được sự đồng thuận. Về nguyên tắc, một tập hợp được lấy mẫu ngẫu nhiên có thể là về mặt lý thuyết có thể bị hỏng một cách thích ứng và một nhánh phân nhánh có thể được tạo ra. hệ thống hoặc cần phải được lập mô hình để sẵn sàng cho một sự kiện như vậy, và do đó vẫn có quy tắc lựa chọn nhánh bên cạnh sự đồng thuận BFT hoặc được thiết kế để đóng xuống trong một sự kiện như vậy. Điều đáng nói là một số thiết kế như Algorand [5], giảm đáng kể khả năng tham nhũng thích ứng. 3. Quan trọng nhất là hệ thống sẽ ngừng hoạt động nếu 1 3 hoặc nhiều hơn trong số tất cả những người tham gia là ngoại tuyến. Do đó, bất kỳ trục trặc mạng tạm thời hoặc sự chia tách mạng nào cũng có thể khiến hệ thống bị đình trệ hoàn toàn. Lý tưởng nhất là hệ thống phải có khả năng tiếp tục hoạt động miễn là có ít nhất một nửa số người tham gia trực tuyến (nặng nhất các giao thức dựa trên chuỗi tiếp tục hoạt động ngay cả khi có ít hơn một nửa số người tham gia trực tuyến, nhưng mức độ mong muốn của đặc tính này còn gây tranh cãi hơn trong cộng đồng). Một mô hình kết hợp trong đó sự đồng thuận được sử dụng là một trong những mô hình nặng nề nhất chuỗi, nhưng một số khối được hoàn thiện định kỳ bằng cách sử dụng tiện ích cuối cùng BFT duy trì những ưu điểm của cả hai mô hình. BFT tiện ích cuối cùng như vậy là Casper FFG [6] được sử dụng trong Ethereum 2.0 8, Casper CBC (xem https://vitalik. ca/general/2018/12/05/cbc_casper.html) và GRANDPA (xem https:// Medium.com/polkadot-network/d08a24a021b5) được sử dụng trong Polkadot. Nightshade sử dụng sự đồng thuận chuỗi cao nhất. Cụ thể khi một khối nhà sản xuất tạo ra một khối (xem phần 3.3), họ có thể thu thập chữ ký từ các nhà sản xuất khối khác và validator chứng thực khối trước đó. Xem phần 3.8 để biết chi tiết về cách tổng hợp số lượng chữ ký lớn như vậy. trọng lượng 8Ngoài ra, hãy xem phiên bảng trắng với Justin Drake để có cái nhìn tổng quan sâu sắc hơn về Casper FFG và cách nó được tích hợp với sự đồng thuận chuỗi nặng nhất GHOST tại đây: https://www. youtube.com/watch?v=S262StTwkmocủa một khối khi đó là cổ phần tích lũy của tất cả những người ký có chữ ký được đưa vào khối. Trọng lượng của chuỗi là tổng trọng lượng của khối. Để đạt được sự đồng thuận cao nhất trong chuỗi, chúng tôi sử dụng tiện ích cuối cùng sử dụng các chứng thực để hoàn thiện các khối. Để giảm độ phức tạp của hệ thống, chúng tôi sử dụng một tiện ích cuối cùng không ảnh hưởng đến quy tắc lựa chọn ngã ba dưới bất kỳ hình thức nào, và thay vào đó chỉ đưa ra các điều kiện cắt bổ sung, sao cho khi một khối được được hoàn thiện bởi tiện ích cuối cùng, việc phân nhánh là không thể trừ khi có một tỷ lệ phần trăm rất lớn tổng số cổ phần bị cắt giảm. Casper CBC là một tiện ích cuối cùng và chúng tôi hiện đang lưu ý đến mô hình Casper CBC. Chúng tôi cũng làm việc trên một giao thức BFT riêng biệt có tên là TxFlow. Vào thời điểm viết tài liệu này, không rõ liệu TxFlow có được sử dụng thay vì Casper hay không CBC. Tuy nhiên, chúng tôi lưu ý rằng việc lựa chọn tiện ích cuối cùng phần lớn là trực giao với phần còn lại của thiết kế. 3.3 Sản xuất khối Trong Nightshade có hai vai trò: nhà sản xuất khối và validators. Tại bất kỳ điểm hệ thống chứa w nhà sản xuất khối, w = 100 trong mô hình của chúng tôi và wv validators, trong mô hình của chúng tôi v = 100, wv = 10.000. Hệ thống là Bằng chứng cổ phần, có nghĩa là cả nhà sản xuất khối và validator đều có một số quyền nội bộ loại tiền tệ (được gọi là ”tokens”) bị khóa trong một khoảng thời gian vượt xa thời gian họ dành để thực hiện nhiệm vụ xây dựng và xác nhận chuỗi. Giống như tất cả các hệ thống Proof of Stake, không phải tất cả các nhà sản xuất khối w và không tất cả wv validator đều là các thực thể khác nhau vì điều đó không thể thực thi được. Mỗi Tuy nhiên, trong số các nhà sản xuất khối w và wv validators có một sự tách biệt cổ phần. Hệ thống chứa n phân đoạn, n = 1000 trong mô hình của chúng tôi. Như đã đề cập ở phần 3.1, trong Nightshade không có chuỗi phân đoạn, thay vào đó tất cả các nhà sản xuất khối và validator đang xây dựng một blockchain duy nhất mà chúng tôi gọi là chuỗi chính. Trạng thái của chuỗi chính được chia thành n phân đoạn và mỗi khối nhà sản xuất và validator bất kỳ lúc nào cũng chỉ tải xuống cục bộ một tập hợp con của trạng thái tương ứng với một số tập hợp con của phân đoạn và chỉ xử lý và xác thực các giao dịch ảnh hưởng đến các phần đó của trạng thái. Để trở thành nhà sản xuất khối, một người tham gia mạng sẽ khóa một số lượng lớn số lượng tokens (tiền đặt cọc). Việc bảo trì mạng được thực hiện theo thời gian, trong đó một kỷ nguyên là một khoảng thời gian theo thứ tự ngày. Những người tham gia với w cổ phần lớn nhất vào đầu một kỷ nguyên cụ thể là khối nhà sản xuất của thời đại đó. Mỗi nhà sản xuất khối được gán cho các phân đoạn sw, (giả sử sw = 40, điều này sẽ tạo ra sww/n = 4 nhà sản xuất khối trên mỗi phân đoạn). khối nhà sản xuất tải xuống trạng thái của phân đoạn mà họ được chỉ định trước kỷ nguyên bắt đầu và trong suốt thời kỳ đó sẽ thu thập các giao dịch ảnh hưởng đến phân đoạn đó, và áp dụng chúng cho nhà nước. Đối với mỗi khối b trên chuỗi chính và với mỗi phân đoạn, có một trong giao các nhà sản xuất khối cho s, người chịu trách nhiệm sản xuất phần liên quan của b đến mảnh vỡ. Phần của b liên quan đến phân đoạn s được gọi là đoạn và chứa danh sách các giao dịch cho phân đoạn được bao gồm trong b, cũng như merklegốc của trạng thái kết quả. b cuối cùng sẽ chỉ chứa một tiêu đề rất nhỏ của đoạn, cụ thể là gốc merkle của tất cả các giao dịch được áp dụng (xem phần 3.7.1 để biết chi tiết chính xác) và nghiệm merkle của trạng thái cuối cùng. Trong suốt phần còn lại của tài liệu, chúng tôi thường đề cập đến nhà sản xuất khối có trách nhiệm tạo ra một đoạn tại một thời điểm cụ thể cho một phân đoạn cụ thể với tư cách là một nhà sản xuất chunk. Nhà sản xuất chunk luôn là một trong những nhà sản xuất khối. Các nhà sản xuất khối và các nhà sản xuất khối xoay vòng từng khối theo theo một lịch trình cố định. Các nhà sản xuất khối có đơn đặt hàng và liên tục sản xuất khối theo thứ tự đó. Ví dụ. nếu có 100 nhà sản xuất khối thì khối đầu tiên nhà sản xuất chịu trách nhiệm sản xuất khối 1, 101, 201, v.v., khối thứ hai là chịu trách nhiệm sản xuất 2, 102, 202, v.v.). Vì sản xuất theo khối, không giống như sản xuất theo khối, đòi hỏi phải duy trì trạng thái và đối với mỗi phân đoạn, chỉ có nhà sản xuất khối sww/n mới duy trì trạng thái trên mỗi phân đoạn, tương ứng chỉ những nhà sản xuất khối sww/n mới xoay vòng để tạo khối. Ví dụ. với các hằng số ở trên với bốn nhà sản xuất khối được gán cho mỗi phân đoạn, mỗi nhà sản xuất khối sẽ tạo ra các khối cứ bốn khối một lần. 3,4 Đảm bảo tính sẵn có của dữ liệu Để đảm bảo tính khả dụng của dữ liệu, chúng tôi sử dụng phương pháp tương tự như phương pháp của Polkadot được mô tả ở phần 2.5.3. Khi nhà sản xuất khối tạo ra một đoạn, họ sẽ tạo một phiên bản được mã hóa xóa của nó với mã khối tối ưu (w, ⌊w/6 + 1⌋) của khúc. Sau đó, họ gửi một phần của đoạn mã bị xóa (chúng tôi gọi những phần đó là từng phần hoặc chỉ các phần) cho mỗi nhà sản xuất khối. Chúng tôi tính toán một cây merkle chứa tất cả các phần là lá và tiêu đề của mỗi đoạn chứa gốc merkle của cây đó. Các bộ phận được gửi tới validator thông qua tin nhắn một phần. Mỗi tin nhắn như vậy chứa tiêu đề chunk, thứ tự của phần và nội dung phần. các tin nhắn cũng chứa chữ ký của nhà sản xuất khối đã tạo ra chunk và đường dẫn merkle để chứng minh rằng phần đó tương ứng với tiêu đề và được sản xuất bởi nhà sản xuất khối thích hợp. Khi nhà sản xuất khối nhận được khối chuỗi chính, trước tiên họ sẽ kiểm tra xem chúng có có các thông điệp một phần cho mỗi đoạn được bao gồm trong khối. Nếu không, khối không được xử lý cho đến khi các tin nhắn onepart bị thiếu được lấy ra. Sau khi nhận được tất cả các tin nhắn một phần, nhà sản xuất khối sẽ tìm nạp các phần còn lại từ các đồng nghiệp và xây dựng lại các khối mà chúng nắm giữ nhà nước. Nhà sản xuất khối không xử lý khối chuỗi chính nếu có ít nhất một khối đoạn được bao gồm trong khối thì chúng không có thông báo một phần tương ứng hoặc nếu đối với ít nhất một phân đoạn mà chúng duy trì trạng thái thì chúng không thể xây dựng lại toàn bộ đoạn. Để có sẵn một đoạn cụ thể, chỉ cần ⌊w/6⌋+1 của khối là đủ nhà sản xuất có bộ phận của họ và phục vụ họ. Vì vậy, miễn là số lượng tác nhân độc hại không vượt quá ⌊w/3⌋không có chuỗi nào có hơn nửa khối các nhà sản xuất xây dựng nó có thể có những phần không có sẵn.Hình 17: Mỗi khối chứa một hoặc không có khối trên mỗi phân đoạn và mỗi khối được mã hóa xóa. Mỗi phần của đoạn mã xóa được gửi đến một địa chỉ được chỉ định nhà sản xuất khối thông qua tin nhắn onepart đặc biệt 3.4.1 Đối phó với các nhà sản xuất khối lười biếng Nếu nhà sản xuất khối có một khối bị thiếu thông báo một phần, họ sẽ có thể chọn vẫn đăng nhập vào nó, bởi vì nếu khối đó cuối cùng vẫn nằm trong chuỗi sẽ tối đa hóa phần thưởng cho nhà sản xuất khối. Không có rủi ro cho việc chặn nhà sản xuất vì sau này không thể chứng minh rằng nhà sản xuất khối không có tin nhắn một phần. Để giải quyết vấn đề này, chúng tôi tạo ra mỗi nhà sản xuất đoạn khi tạo đoạn để chọn một màu (đỏ hoặc xanh) cho từng phần của đoạn được mã hóa trong tương lai và lưu trữ bitmask của màu được gán trong đoạn trước khi nó được mã hóa. Mỗi phần một sau đó thông báo chứa màu được gán cho phần đó và màu này được sử dụng khi tính toán gốc merkle của các phần được mã hóa. Nếu nhà sản xuất chunk đi chệch hướng từ giao thức, điều đó có thể được chứng minh dễ dàng vì gốc merkle sẽ không tương ứng với tin nhắn một phần hoặc màu sắc trong tin nhắn một phần tương ứng với gốc merkle sẽ không khớp với mặt nạ trong đoạn. Khi nhà sản xuất khối ký vào một khối, họ sẽ bao gồm một bitmask của tất cả phần màu đỏ mà họ nhận được cho các khối có trong khối. Xuất bản một bitmask không chính xác là một hành vi có thể gạch chéo. Nếu nhà sản xuất khối chưa nhận được một tin nhắn, họ không có cách nào biết được màu sắc của tin nhắn, và do đó có 50% khả năng bị chém nếu họ cố gắng mù quáng ký vào bản hợp đồng. khối. 3,5 Ứng dụng chuyển trạng thái Nhà sản xuất khối chỉ chọn những giao dịch nào sẽ được đưa vào khối nhưng không áp dụng chuyển đổi trạng thái khi chúng tạo ra một đoạn. Tương ứng,
tiêu đề chunk chứa gốc merkle của trạng thái merkelized như trước các giao dịch trong chunk được áp dụng. Các giao dịch chỉ được áp dụng khi một khối đầy đủ bao gồm đoạn được xử lý. Một người tham gia chỉ xử lý một khối nếu 1. Khối trước đó đã được nhận và xử lý; 2. Đối với mỗi đoạn, người tham gia không duy trì trạng thái vì họ có đã xem tin nhắn onepart; 3. Đối với mỗi đoạn, người tham gia duy trì trạng thái vì họ có đoạn đầy đủ. Sau khi khối được xử lý, đối với mỗi phân đoạn mà người tham gia duy trì trạng thái, áp dụng các giao dịch và tính toán trạng thái mới kể từ sau khi các giao dịch được áp dụng, sau đó họ đã sẵn sàng sản xuất các khối cho khối tiếp theo, nếu chúng được gán cho bất kỳ phân đoạn nào, vì chúng có gốc merkle của trạng thái merkelized mới. 3.6 Giao dịch và biên lai chéo Nếu một giao dịch cần ảnh hưởng đến nhiều phân đoạn, thì nó cần phải được thực hiện liên tục được thực hiện trong từng phân đoạn riêng biệt. Giao dịch đầy đủ được gửi đến phân đoạn đầu tiên bị ảnh hưởng và khi giao dịch được bao gồm trong khối cho phân đoạn đó và được áp dụng sau khi đoạn được đưa vào một khối, nó tạo ra cái gọi là biên nhận giao dịch, được chuyển đến phân đoạn tiếp theo mà giao dịch cần thực hiện được thực thi. Nếu cần nhiều bước hơn, việc thực hiện giao dịch nhận tạo ra một giao dịch biên nhận mới, v.v. 3.6.1 Thời gian nhận giao dịch Điều mong muốn là giao dịch nhận được áp dụng trong khối ngay sau khối mà nó được tạo. Giao dịch nhận tiền chỉ được tạo sau khi khối trước đó được các nhà sản xuất khối nhận và áp dụng duy trì phân đoạn ban đầu và cần được biết vào thời điểm chunk cho khối tiếp theo được tạo ra bởi nhà sản xuất khối của đích mảnh vỡ. Do đó, biên nhận phải được truyền từ phân đoạn nguồn đến phân đoạn đích trong khung thời gian ngắn giữa hai sự kiện đó. Đặt A là khối được tạo cuối cùng chứa giao dịch t tạo ra biên nhận r. Đặt B là khối được tạo tiếp theo (tức là khối có A là khối trước đó của nó) mà chúng ta muốn chứa r. Đặt t ở trong mảnh a và r là trong mảnh vỡ b. Thời hạn sử dụng của biên nhận, cũng được mô tả trên hình 18, như sau: Lập và lưu trữ hóa đơn. Cpa của nhà sản xuất chunk cho phân đoạn a nhận khối A, áp dụng giao dịch t và tạo biên nhận r. cpa sau đó lưu trữ tất cả các biên lai được tạo ra như vậy trong bộ lưu trữ liên tục nội bộ được lập chỉ mục theo id phân đoạn nguồn.Phân phối các khoản thu. Khi cpa đã sẵn sàng để tạo đoạn cho phân đoạn a cho khối B, họ tìm nạp tất cả các biên lai được tạo bằng cách áp dụng các giao dịch từ khối A cho phân đoạn a và đưa chúng vào đoạn cho phân đoạn a trong khối B. Một khi đoạn như vậy được tạo ra, cpa sẽ tạo ra mã xóa của nó phiên bản và tất cả các thông báo onepart tương ứng. cpa biết nhà sản xuất khối nào duy trì trạng thái đầy đủ cho phân đoạn nào. Đối với một nhà sản xuất khối cụ thể bp cpa bao gồm các khoản thu được từ việc áp dụng các giao dịch trong khối A đối với phân đoạn a có bất kỳ phân đoạn nào mà bp quan tâm làm đích đến của họ trong tin nhắn onepart khi họ phân phối đoạn cho phân đoạn a trong khối B (xem hình 17, hiển thị các biên nhận có trong thông báo một phần). Nhận biên lai. Hãy nhớ rằng những người tham gia (cả nhà sản xuất khối và validator) không xử lý các khối cho đến khi họ có thông báo một phần cho mỗi đoạn có trong khối. Do đó, vào thời điểm bất kỳ người tham gia cụ thể nào áp dụng khối B, họ có tất cả các thông báo một phần tương ứng với các khối trong B và do đó họ có tất cả các biên nhận đến có các phân đoạn người tham gia duy trì trạng thái làm điểm đến của họ. Khi áp dụng các chuyển trạng thái cho một phân đoạn cụ thể, người tham gia sẽ áp dụng cả biên lai mà họ đã thu thập cho phân đoạn trong tin nhắn một phần, cũng như tất cả các giao dịch được bao gồm trong chính đoạn đó. Hình 18: Thời gian tồn tại của một giao dịch biên nhận 3.6.2 Xử lý quá nhiều biên lai Có thể số lượng biên lai nhắm mục tiêu vào một phân đoạn cụ thể trong một khối cụ thể quá lớn để được xử lý. Ví dụ, hãy xem xét hình 19, trong mỗi giao dịch trong mỗi phân đoạn sẽ tạo ra một biên nhận nhắm mục tiêu phân đoạn 1. Ở khối tiếp theo, số biên nhận mà phân đoạn 1 cần xử lý là có thể so sánh với tải mà tất cả các phân đoạn kết hợp được xử lý trong khi xử lý khối trước đó.
Hình 19: Nếu tất cả các khoản thu đều nhắm mục tiêu vào cùng một phân đoạn thì phân đoạn đó có thể không có khả năng xử lý chúng Để giải quyết vấn đề này, chúng tôi sử dụng một kỹ thuật tương tự như kỹ thuật được sử dụng trong QuarkChain 9. Cụ thể, đối với mỗi phân đoạn, khối B cuối cùng và phân đoạn cuối cùng trong đó khối mà biên lai được áp dụng được ghi lại. Khi có phân đoạn mới được tạo, biên nhận được áp dụng theo thứ tự đầu tiên từ các phân đoạn còn lại trong B, và sau đó theo các khối theo B, cho đến khi khối mới đầy. Dưới mức bình thường trường hợp có tải trọng cân bằng nhìn chung sẽ dẫn đến tất cả các khoản thu đang được áp dụng (và do đó phân đoạn cuối cùng của khối cuối cùng sẽ được ghi lại cho từng đoạn), nhưng trong những thời điểm tải không cân bằng và một phần cụ thể phân đoạn nhận được nhiều biên lai không tương xứng, kỹ thuật này cho phép họ được xử lý đồng thời tôn trọng các giới hạn về số lượng giao dịch được đưa vào. Lưu ý rằng nếu tải không cân bằng như vậy tồn tại trong một thời gian dài thì độ trễ từ việc tạo biên lai cho đến khi ứng dụng có thể tiếp tục phát triển vô thời hạn. một cách để giải quyết vấn đề này là loại bỏ bất kỳ giao dịch nào tạo ra biên nhận nhắm mục tiêu phân đoạn có độ trễ xử lý vượt quá một số hằng số (ví dụ: một kỷ nguyên). Hãy xem xét hình 20. Theo khối B, phân đoạn 4 không thể xử lý tất cả các biên nhận, vì vậy nó chỉ xử lý nguồn gốc biên lai từ tối đa phân đoạn 3 trong khối A và ghi lại nó. Trong khối C, bao gồm các khoản thu lên tới phân đoạn 5 trong khối B và sau đó đến khối D, phân đoạn sẽ bắt kịp, xử lý tất cả các khoản thu còn lại trong khối B và tất cả các khoản thu từ khối C. 3,7 Xác thực khối Một đoạn được tạo cho một phân đoạn cụ thể (hoặc một khối phân đoạn được tạo cho một chuỗi phân đoạn cụ thể trong mô hình có chuỗi phân đoạn) chỉ có thể được xác thực bởi 9Xem tập bảng trắng với QuarkChain tại đây: https://www.youtube.com/watch? v=opEtG6NM4x4, trong đó cách tiếp cận các giao dịch chéo được thảo luận, cùng với các vấn đề khác nhiều thứHình 20: Xử lý biên lai bị trì hoãn những người tham gia duy trì trạng thái. Họ có thể là nhà sản xuất khối, validators, hoặc chỉ những nhân chứng bên ngoài đã tải xuống trạng thái và xác thực phân đoạn trong mà họ lưu trữ tài sản. Trong tài liệu này chúng tôi giả định rằng phần lớn những người tham gia không thể lưu trữ trạng thái cho một phần lớn các phân đoạn. Tuy nhiên, điều đáng nói là rằng có blockchain được phân chia được thiết kế với giả định rằng hầu hết người tham gia đều có khả năng lưu trữ trạng thái và xác thực hầu hết các phân đoạn, chẳng hạn như QuarkChain. Vì chỉ một phần nhỏ người tham gia có trạng thái xác thực phân đoạn các khối, có thể thích ứng với tham nhũng chỉ những người tham gia có trạng thái và áp dụng chuyển đổi trạng thái không hợp lệ. Nhiều thiết kế phân đoạn đã được đề xuất lấy mẫu validator cứ sau vài lần ngày và trong vòng một ngày, bất kỳ khối nào trong chuỗi phân đoạn có hơn 2/3 chữ ký của validator được gán cho phân đoạn đó sẽ được xem xét ngay lập tức cuối cùng. Với cách tiếp cận như vậy, đối thủ thích ứng chỉ cần làm hỏng 2n/3+1 của validator trong chuỗi phân đoạn để áp dụng chuyển đổi trạng thái không hợp lệ, trong đó, mặc dù có thể khó thực hiện nhưng mức độ bảo mật không đủ cho công chúng blockchain. Như đã thảo luận trong phần 2.3, cách tiếp cận phổ biến là cho phép một khoảng thời gian nhất định sau khi khối được tạo cho bất kỳ người tham gia nào có trạng thái (cho dù đó là nhà sản xuất khối, validator hoặc người quan sát bên ngoài) để thách thức tính hợp lệ của nó. Những người tham gia như vậy được gọi là Ngư dân. Để một ngư dân có thể thách thức một khối không hợp lệ, phải đảm bảo rằng khối đó có sẵn để họ. Tính khả dụng của dữ liệu trong Nightshade được thảo luận trong phần 3.4. Trong Nightshade khi một khối được tạo ra, các khối không được xác thực bởi bất cứ ai ngoại trừ nhà sản xuất chunk thực sự. Đặc biệt, nhà sản xuất khối đó đề xuất khối tự nhiên không có trạng thái cho hầu hết các phân đoạn vàđã không thể xác nhận các khối. Khi khối tiếp theo được tạo ra, nó chứa các chứng thực (xem phần 3.2) của nhiều nhà sản xuất khối và validators, nhưng vì phần lớn các nhà sản xuất khối và validator không duy trì trạng thái đối với hầu hết các phân đoạn, một khối chỉ có một đoạn không hợp lệ sẽ thu thập được hơn một nửa số chứng thực và sẽ tiếp tục ở trạng thái nặng nhất. chuỗi. Để giải quyết vấn đề này, chúng tôi cho phép bất kỳ người tham gia nào duy trì trạng thái một phân đoạn để gửi thử thách trên chuỗi cho bất kỳ đoạn không hợp lệ nào được tạo ra trong đó mảnh vỡ. 3.7.1 Thử thách tính hợp lệ của trạng thái Khi người tham gia phát hiện thấy một đoạn cụ thể không hợp lệ, họ cần cung cấp bằng chứng cho thấy đoạn đó không hợp lệ. Vì phần lớn những người tham gia mạng không duy trì trạng thái cho phân đoạn có đoạn không hợp lệ được tạo ra, bằng chứng cần phải có đủ thông tin để xác nhận khối đó là không hợp lệ nếu không có trạng thái. Chúng tôi đặt giới hạn Ls về số lượng trạng thái (tính bằng byte) mà một giao dịch đơn lẻ có thể đọc hoặc viết tích lũy. Bất kỳ giao dịch nào chạm nhiều hơn Ls trạng thái được coi là không hợp lệ. Hãy nhớ từ phần 3.5 rằng đoạn trong khối B cụ thể chỉ chứa các giao dịch được áp dụng chứ không chứa gốc trạng thái mới. Gốc trạng thái có trong đoạn trong khối B là trạng thái root trước khi áp dụng các giao dịch đó, nhưng sau khi áp dụng các giao dịch từ đoạn cuối cùng trong cùng phân đoạn trước khối B. Một tác nhân độc hại mong muốn áp dụng chuyển đổi trạng thái không hợp lệ sẽ bao gồm gốc trạng thái không chính xác trong khối B không tương ứng với gốc trạng thái do áp dụng các giao dịch ở đoạn trước. Chúng tôi mở rộng thông tin mà nhà sản xuất chunk đưa vào chunk. Thay vì chỉ thêm trạng thái sau khi áp dụng tất cả các giao dịch, nó thay vào đó bao gồm một gốc trạng thái sau khi áp dụng từng bộ giao dịch liền kề đọc và ghi chung Ls byte trạng thái. Với thông tin này cho Fisherman tạo ra một thách thức rằng việc chuyển đổi trạng thái được áp dụng không chính xác là đủ để tìm ra gốc trạng thái không hợp lệ đầu tiên và chỉ bao gồm Ls byte của trạng thái bị ảnh hưởng bởi các giao dịch giữa trạng thái gốc cuối cùng (được hợp lệ) và trạng thái gốc hiện tại với bằng chứng merkle. Sau đó bất kỳ người tham gia nào có thể xác thực các giao dịch trong phân đoạn và xác nhận rằng đoạn đó là không hợp lệ. Tương tự, nếu nhà sản xuất chunk cố gắng đưa vào các giao dịch đọc và ghi nhiều hơn L byte trạng thái, đối với thử thách này, chỉ cần bao gồm Ls byte đầu tiên mà nó chạm tới với bằng chứng merkle, điều này sẽ đủ để áp dụng các giao dịch và xác nhận rằng sẽ có lúc cố gắng thực hiện đọc hoặc ghi nội dung vượt quá Ls byte được thực hiện.
3.7.2 Ngư dân và giao dịch xuyên mảnh nhanh chóng Như đã thảo luận trong phần 2.3, khi chúng ta giả định rằng các đoạn phân đoạn (hoặc phân đoạn các khối trong mô hình có chuỗi phân đoạn) có thể không hợp lệ và gây ra thách thức theo thời gian, nó ảnh hưởng tiêu cực đến tính cuối cùng và do đó giao tiếp giữa các phân đoạn. trong cụ thể, phân đoạn đích của bất kỳ chuyển đổi chéo nào đều không thể chắc chắn đoạn hoặc khối phân đoạn ban đầu là cuối cùng cho đến khi giai đoạn thử thách kết thúc (xem hình 21). Hình 21: Chờ đợi thời gian thử thách trước khi áp dụng biên nhận Cách giải quyết vấn đề theo cách thực hiện các giao dịch chéo tức thời là để mảnh đích không phải đợi đến giai đoạn thử thách sau khi giao dịch phân đoạn nguồn được xuất bản và áp dụng giao dịch biên nhận ngay lập tức, nhưng sau đó khôi phục phân đoạn đích cùng với phân đoạn nguồn phân đoạn nếu sau đó đoạn hoặc khối ban đầu được phát hiện là không hợp lệ (xem hình 22). Điều này áp dụng rất tự nhiên cho thiết kế Nightshade trong đó mảnh vỡ các chuỗi không độc lập mà thay vào đó, các đoạn phân đoạn đều được xuất bản cùng nhau trong cùng một khối chuỗi chính. Nếu bất kỳ đoạn nào được phát hiện là không hợp lệ, toàn bộ khối có đoạn đó được coi là không hợp lệ và tất cả các khối được xây dựng trên trên hết. Xem hình 23. Cả hai cách tiếp cận trên đều cung cấp tính nguyên tử giả định rằng thách thức thời gian đủ dài. Chúng tôi sử dụng phương pháp thứ hai vì việc cung cấp các giao dịch chéo nhanh trong các trường hợp thông thường sẽ vượt qua sự bất tiện của phân đoạn đích quay trở lại do chuyển đổi trạng thái không hợp lệ ở một trong các các mảnh nguồn, đây là một sự kiện cực kỳ hiếm. 3.7.3 Đang ẩn validators Sự tồn tại của những thách thức đã làm giảm đáng kể khả năng xảy ra tham nhũng thích ứng, vì để hoàn thiện một đoạn có bài chuyển đổi trạng thái không hợp lệHình 22: Áp dụng biên lai ngay lập tức và quay trở lại điểm đến chuỗi nếu chuỗi nguồn có khối không hợp lệ Hình 23: Thử thách làm ngư dân trong Nightshade giai đoạn thử thách mà đối thủ thích ứng cần để làm hỏng tất cả những người tham gia duy trì trạng thái của phân đoạn, bao gồm tất cả validator. Việc ước tính khả năng xảy ra một sự kiện như vậy là vô cùng phức tạp, vì không có sharded blockchain đã tồn tại đủ lâu để thực hiện bất kỳ cuộc tấn công nào như vậy. Chúng tôi lập luận rằng xác suất, mặc dù cực kỳ thấp, nhưng vẫn đủ lớn đối với một hệ thống dự kiến sẽ thực hiện hàng triệu giao dịch và điều hành các hoạt động tài chính trên toàn thế giới. Có hai lý do chính cho niềm tin này: 1. Hầu hết validator của chuỗi Bằng chứng cổ phần và công cụ khai thác của
Chuỗi Proof-of-Work chủ yếu được khuyến khích bởi lợi ích tài chính. Nếu một đối thủ có khả năng thích ứng mang lại cho họ nhiều tiền hơn lợi nhuận kỳ vọng từ việc vận hành một cách trung thực, thật hợp lý khi mong đợi rằng nhiều validators sẽ chấp nhận lời đề nghị. 2. Nhiều tổ chức thực hiện xác thực chuỗi Proof-of-Stake một cách chuyên nghiệp và người ta dự kiến rằng một tỷ lệ lớn cổ phần trong bất kỳ chuỗi nào sẽ được từ các thực thể đó. Số lượng các thực thể như vậy đủ nhỏ để đối thủ thích nghi để tìm hiểu cá nhân hầu hết họ và có một hiểu rõ khuynh hướng của họ là bị tha hóa. Chúng tôi tiến thêm một bước nữa trong việc giảm khả năng xảy ra lỗi thích ứng bằng cách ẩn validator được gán cho phân đoạn nào. Ý tưởng là tương tự như cách Algorand [5] che giấu validators. Điều quan trọng cần lưu ý là ngay cả khi validator bị ẩn, như trong Algorand hoặc như được mô tả dưới đây, về mặt lý thuyết, tham nhũng thích ứng vẫn có thể xảy ra. Trong khi đối thủ thích ứng không biết những người tham gia sẽ tạo hoặc xác thực một khối hay một đoạn, bản thân những người tham gia đều biết rằng họ sẽ thực hiện một nhiệm vụ như vậy và có bằng chứng mật mã về nó. Vì vậy, đối thủ có thể truyền bá ý định tham nhũng của họ và trả tiền cho bất kỳ người tham gia nào sẽ cung cấp một bằng chứng mật mã như vậy. Tuy nhiên, chúng tôi lưu ý rằng vì đối thủ không biết validator được gán cho phân đoạn mà chúng muốn làm hỏng, chúng không có lựa chọn nào khác ngoài việc truyền bá ý định làm hỏng một phân đoạn cụ thể tới toàn bộ cộng đồng. Vào thời điểm đó, nó mang lại lợi ích kinh tế cho bất kỳ người trung thực nào. người tham gia tạo ra một nút đầy đủ để xác thực phân đoạn đó vì có mức cao khả năng một khối không hợp lệ xuất hiện trong phân đoạn đó, đây là cơ hội để tạo ra một thử thách và thu thập phần thưởng liên quan. Để không tiết lộ validator được gán cho một phân đoạn cụ thể, chúng tôi thực hiện sau đây (xem hình 24): Sử dụng VRF để nhận nhiệm vụ. Vào đầu mỗi thời đại, mỗi validator sử dụng VRF để lấy mặt nạ bit của các phân đoạn mà validator được gán cho. Mặt nạ bit của mỗi validator sẽ có các bit Sw (xem phần 3.3 để biết định nghĩa của Sw). validator sau đó tìm nạp trạng thái của các phân đoạn tương ứng và trong kỷ nguyên cho mỗi khối nhận được sẽ xác thực các khối tương ứng vào các phân đoạn mà validator được gán cho. Đăng nhập vào khối thay vì khối. Vì việc gán phân đoạn bị ẩn nên validator không thể đăng nhập vào các phân đoạn. Thay vào đó nó luôn ký trên toàn bộ chặn, do đó không tiết lộ những phân đoạn mà nó xác nhận. Cụ thể, khi validator nhận được một khối và xác thực tất cả các khối, nó sẽ tạo ra một thông báo chứng thực rằng tất cả các đoạn trong tất cả các phân đoạn mà validator được chỉ định là hợp lệ (không cho biết những phân đoạn đó là gì) hoặc một thông báo rằng chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ nếu bất kỳ đoạn nào không hợp lệ. Xem phần 3.8 để biết chi tiết về cách tổng hợp các thông báo đó, phần 3.7.4 để biết chi tiết về cách ngăn chặn validator lợi dụng tin nhắn từ validators khác và phần 3.7.5 để biết chi tiết về cách khen thưởng và trừng phạt validators nếu thử thách chuyển đổi trạng thái không hợp lệ thành công thực sự xảy ra.Hình 24: Che giấu validator trong Nightshade 3.7.4 Cam kết-Tiết lộ Một trong những vấn đề phổ biến với validator là validator có thể bỏ qua việc tải xuống trạng thái và thực sự xác thực các khối và khối, thay vào đó quan sát mạng, xem những gì validator khác gửi và lặp lại tin nhắn. validator tuân theo chiến lược như vậy sẽ không cung cấp thêm bất kỳ bảo mật cho mạng nhưng thu thập phần thưởng. Một giải pháp phổ biến cho vấn đề này là mỗi validator cung cấp bằng chứng rằng họ thực sự đã xác thực khối đó, chẳng hạn như bằng cách cung cấp dấu vết duy nhất áp dụng chuyển đổi trạng thái, nhưng những bằng chứng như vậy làm tăng đáng kể chi phí xác nhận. Hình 25: Cam kết tiết lộ
Thay vào đó, chúng tôi thực hiện cam kết đầu tiên của validator với kết quả xác thực (hoặc thông báo chứng thực tính hợp lệ của các khối hoặc bằng chứng về tính hợp lệ của chuyển trạng thái), đợi một khoảng thời gian nhất định và chỉ sau đó mới tiết lộ kết quả xác thực thực tế, như được hiển thị trên hình 25. Khoảng thời gian cam kết không giao nhau với khoảng thời gian tiết lộ và do đó một validator lười biếng không thể bắt chước những validator trung thực. Hơn nữa, nếu một validator không trung thực cam kết thực hiện một thông báo chứng thực tính hợp lệ của các đoạn được gán và ít nhất một đoạn không hợp lệ một khi nó được đã chỉ ra rằng đoạn đó không hợp lệ nên validator không thể tránh được việc gạch chéo, vì, như chúng tôi trình bày trong phần 3.7.5, cách duy nhất để không bị chém trong tình huống như vậy là đưa ra một thông báo chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ phù hợp với cam kết. 3.7.5 Xử lý thử thách Như đã thảo luận ở trên, khi validator nhận được một khối có đoạn không hợp lệ, đầu tiên họ chuẩn bị bằng chứng về sự chuyển đổi trạng thái không hợp lệ (xem phần 3.7.1), sau đó cam kết với một bằng chứng như vậy (xem 3.7.4), và sau một thời gian hãy tiết lộ thách thức. Khi thử thách được tiết lộ được đưa vào một khối, điều sau đây sẽ xảy ra: 1. Tất cả các chuyển đổi trạng thái xảy ra từ khối chứa đoạn không hợp lệ cho đến khi khối chứa thử thách được tiết lộ bị vô hiệu hóa. Trạng thái trước khối bao gồm thử thách được tiết lộ được coi là giống với trạng thái trước khối chứa đoạn không hợp lệ. 2. Trong một khoảng thời gian nhất định, mỗi validator phải tiết lộ mặt nạ bit của mình của các phân đoạn mà họ xác nhận. Vì mặt nạ bit được tạo thông qua VRF, nếu họ được gán cho phân đoạn có quá trình chuyển đổi trạng thái không hợp lệ, họ không thể tránh khỏi việc tiết lộ nó. Bất kỳ validator nào không tiết lộ được mặt nạ bit được cho là được gán cho phân đoạn. 3. Mỗi validator sau khoảng thời gian đó được phát hiện sẽ được gán cho phân đoạn, đã cam kết với một số kết quả xác thực cho khối chứa đoạn không hợp lệ và điều đó không tiết lộ bằng chứng về việc chuyển đổi trạng thái không hợp lệ tương ứng với cam kết của họ bị cắt giảm. 4. Mỗi validator nhận được một phân đoạn mới và một kỷ nguyên mới được lên lịch bắt đầu sau một khoảng thời gian đủ để tất cả validator tải xuống trạng thái, như thể hiện trên hình 26. Lưu ý rằng kể từ thời điểm validator tiết lộ các phân đoạn mà chúng được chỉ định cho đến khi kỷ nguyên mới bắt đầu, tính bảo mật của hệ thống sẽ bị giảm do phân công mảnh vỡ được tiết lộ. Những người tham gia mạng cần phải giữ nó lưu ý khi sử dụng mạng trong thời gian đó. 3,8 Tổng hợp chữ ký Để một hệ thống có hàng trăm phân đoạn hoạt động an toàn, chúng tôi muốn có trên đơn hàng từ 10.000 trở lên validators. Như đã thảo luận trong phần 3.7, chúng tôi muốn mỗiHình 26: Xử lý thử thách validator để xuất bản một cam kết cho một tin nhắn nhất định và một chữ ký ở mức trung bình một lần cho mỗi khối. Ngay cả khi các thông điệp cam kết giống nhau, việc tổng hợp như vậy Chữ ký BLS và việc xác nhận nó sẽ rất tốn kém. Nhưng đương nhiên các thông báo cam kết và tiết lộ không giống nhau trên validators, và do đó chúng ta cần một số cách để tổng hợp các thông điệp và chữ ký đó trong một cách cho phép xác nhận nhanh chóng sau này. Cách tiếp cận cụ thể mà chúng tôi sử dụng như sau: Người xác nhận tham gia các nhà sản xuất khối. Các nhà sản xuất khối được biết đến một thời gian trước khi kỷ nguyên bắt đầu, vì họ cần một chút thời gian để tải xuống trạng thái trước khi kỷ nguyên bắt đầu và không giống như validator, các nhà sản xuất khối không che giấu. Mỗi nhà sản xuất khối có v validator vị trí. Trình xác nhận gửi đề xuất ngoài chuỗi cho các nhà sản xuất khối để được đưa vào như một trong những v validators. Nếu nhà sản xuất khối muốn bao gồm validator, họ sẽ gửi giao dịch chứa yêu cầu ngoài chuỗi ban đầu từ validator và chữ ký của nhà sản xuất khối khiến validator tham gia nhà sản xuất khối. Lưu ý rằng validator được gán cho nhà sản xuất khối không nhất thiết xác thực các phân đoạn tương tự mà nhà sản xuất khối tạo ra các khối. Nếu một validator áp dụng để tham gia nhiều nhà sản xuất khối, chỉ giao dịch từ nhà sản xuất khối đầu tiên sẽ thành công. Các nhà sản xuất khối thu thập các cam kết. Nhà sản xuất khối liên tục thu thập các thông báo cam kết và tiết lộ từ validator. Khi một số lượng tin nhắn như vậy nhất định được tích lũy, nhà sản xuất khối sẽ tính toán một merkle cây của những tin nhắn này và gửi tới mỗi validator gốc merkle và đường dẫn merkle đến tin nhắn của họ. validator xác thực đường dẫn và đăng nhập rễ merkle. Sau đó, nhà sản xuất khối sẽ tích lũy chữ ký BLS trên gốc merkle từ validators và chỉ xuất bản gốc merkle và chữ ký tích lũy Nhà sản xuất khối cũng ký vào tính hợp lệ của đa chữ ký bằng cách sử dụng chữ ký ECDSA giá rẻ. Nếu đa chữ ký không khớp với gốc merkle được gửi hoặc bitmask của validator tham gia, đó là hành vi có thể cắt được. Khi đồng bộ hóa chuỗi, người tham gia có thể chọn xác thực tất cả chữ ký BLS từ các validator (việc này cực kỳ tốn kém vì nó liên quan đến việc tổng hợp các khóa công khai của validator) hoặc chỉchữ ký ECDMA từ các nhà sản xuất khối và dựa vào thực tế là nhà sản xuất khối không bị thách thức và bị chém. Sử dụng các giao dịch trên chuỗi và bằng chứng merkle để giải quyết các thách thức. Nó có thể lưu ý rằng việc tiết lộ tin nhắn từ validator sẽ không có giá trị gì nếu không chuyển đổi trạng thái không hợp lệ đã được phát hiện. Chỉ những tin nhắn có chứa thông tin thực tế bằng chứng về việc chuyển đổi trạng thái không hợp lệ cần phải được tiết lộ và chỉ dành cho những tin nhắn như vậy nó cần phải được chứng minh rằng chúng phù hợp với cam kết trước đó. Thông điệp cần phải được tiết lộ nhằm hai mục đích: 1. Để thực sự bắt đầu quá trình khôi phục chuỗi về thời điểm trước khi thực hiện chuyển trạng thái không hợp lệ (xem phần 3.7.5). 2. Để chứng minh rằng validator không cố gắng chứng thực tính hợp lệ của đoạn không hợp lệ. Trong cả hai trường hợp, chúng ta cần giải quyết hai vấn đề: 1. Cam kết thực tế không được đưa vào chuỗi, chỉ có gốc merkle của cam kết tổng hợp với các tin nhắn khác. validator cần sử dụng đường dẫn merkle do nhà sản xuất khối cung cấp và cam kết ban đầu của họ đối với chứng minh rằng họ đã cam kết với thử thách. 2. Có thể tất cả validator được gán cho phân đoạn có giá trị không hợp lệ quá trình chuyển đổi trạng thái xảy ra được gán cho các nhà sản xuất khối bị hỏng đang kiểm duyệt chúng. Để giải quyết vấn đề này, chúng tôi cho phép họ gửi tiết lộ của mình như một giao dịch thông thường trên chuỗi và bỏ qua việc tổng hợp. Cái sau chỉ được phép đối với các bằng chứng về sự chuyển đổi trạng thái không hợp lệ, đó là cực kỳ hiếm và do đó sẽ không dẫn đến việc gửi thư rác vào các khối. Vấn đề cuối cùng cần được giải quyết là các nhà sản xuất khối có thể chọn không tham gia vào việc tổng hợp tin nhắn hoặc cố tình kiểm duyệt validators cụ thể. Chúng tôi làm cho nó trở nên bất lợi về mặt kinh tế bằng cách tạo ra khối phần thưởng của nhà sản xuất tỷ lệ thuận với số validator được chỉ định cho họ. Chúng tôi cũng lưu ý rằng vì các nhà sản xuất khối giữa các kỷ nguyên phần lớn giao nhau (vì luôn là những người tham gia có số tiền đặt cược cao nhất), validator có thể phần lớn tập trung vào làm việc với cùng một nhà sản xuất khối và do đó giảm thiểu rủi ro về việc được giao cho một nhà sản xuất khối đã kiểm duyệt chúng trong quá khứ. 3,9 Chuỗi ảnh chụp nhanh Vì các khối trên chuỗi chính được sản xuất rất thường xuyên nên việc tải xuống toàn bộ lịch sử có thể trở nên đắt đỏ rất nhanh. Hơn nữa, vì mỗi khối chứa chữ ký BLS của một số lượng lớn người tham gia, chỉ cần tổng hợp các khóa công khai để kiểm tra chữ ký có thể trở nên quá khó khăn. đắt tiền là tốt. Cuối cùng, vì trong bất kỳ tương lai gần nào Ethereum 1.0 có thể sẽ vẫn là một trong số blockchain được sử dụng nhiều nhất, có một cách hiệu quả để chuyển nội dung từ
Gần Ethereum là một yêu cầu và hôm nay việc xác minh chữ ký BLS để đảm bảo Không thể có hiệu lực ở các khối gần về phía Ethereum. Mỗi khối trong chuỗi chính Nightshade có thể tùy ý chứa Schnorr đa chữ ký trên tiêu đề của khối cuối cùng bao gồm Schnorr đa chữ ký. Chúng tôi gọi những khối như vậy là khối chụp nhanh. Khối đầu tiên của mỗi kỷ nguyên phải là một khối ảnh chụp nhanh. Trong khi làm việc trên một hệ thống đa chữ ký như vậy, nhà sản xuất khối cũng phải tích lũy chữ ký BLS của validators trên khối ảnh chụp nhanh cuối cùng và tổng hợp chúng theo cách tương tự như được mô tả trong phần 3.8. Vì bộ sản xuất khối không đổi trong suốt kỷ nguyên, nên việc xác thực chỉ các khối ảnh chụp nhanh đầu tiên trong mỗi kỷ nguyên là đủ với giả định rằng không có chỉ ra một tỷ lệ lớn các nhà sản xuất khối và validator đã thông đồng và tạo ra một cái nĩa. Khối đầu tiên của kỷ nguyên phải chứa thông tin đủ để tính toán nhà sản xuất khối và validator cho kỷ nguyên. Chúng tôi gọi chuỗi con của chuỗi chính chỉ chứa ảnh chụp nhanh chặn một chuỗi ảnh chụp nhanh. Tạo đa chữ ký Schnorr là một quá trình tương tác, nhưng vì chúng ta chỉ cần thực hiện nó không thường xuyên, bất kỳ quy trình nào, dù kém hiệu quả đến đâu sẽ đủ. Có thể dễ dàng xác thực đa chữ ký Schnorr trên Ethereum, do đó cung cấp các nguyên hàm quan trọng để thực hiện một cách an toàn chéo-blockchain giao tiếp. Để đồng bộ với chuỗi Gần, người ta chỉ cần tải xuống tất cả ảnh chụp nhanh chặn và xác nhận rằng chữ ký Schnorr là chính xác (tùy chọn cũng xác minh chữ ký BLS riêng lẻ của validators), sau đó chỉ đồng bộ hóa khối chuỗi chính từ khối ảnh chụp nhanh cuối cùng.
Nightshade
3.1 シャードチェーンからシャードチャンクへ シャード チェーンとビーコン チェーンを使用したシャーディング モデルは非常に強力ですが、 にはある種の複雑さがあります。特に、フォーク選択ルールを実行する必要があります。 各チェーンで個別に、シャード チェーンとビーコンでのフォーク選択ルール チェーンは別々に構築し、個別にテストする必要があります。 Nightshade では、システムを単一の blockchain としてモデル化します。 ブロックにはすべてのシャードのすべてのトランザクションが論理的に含まれており、 すべてのシャードの全体状態。ただし、物理的には、参加者は誰もダウンロードしません。 完全な状態または完全な論理ブロック。代わりに、ネットワークの各参加者のみが トランザクションを検証するシャードに対応する状態を維持し、ブロック内のすべてのトランザクションのリストが物理的なトランザクションに分割されます。 チャンク、シャードごとに 1 つのチャンク。 理想的な条件下では、各ブロックにはシャードごとに 1 つのチャンクが含まれます。 ブロック。これは、シャード チェーンを含むモデルにほぼ対応します。 シャード チェーンは、ビーコン チェーンと同じ速度でブロックを生成します。ただし、 ネットワークの遅延により、一部のチャンクが欠落している可能性があるため、実際には各ブロックが欠落している可能性があります。 シャードごとに 1 つまたはゼロのチャンクが含まれます。方法の詳細については、セクション 3.3 を参照してください。 ブロックが生成されます。 図 16: 左側にシャード チェーンがあり、1 つのチェーンが 右側のブロックに分割されたブロック
3.2 コンセンサス 今日のblockchainのコンセンサスへの主要なアプローチは 2 つあります。 最も長い (または最も重い) チェーン。その中で最も多くの作業またはステークを持つチェーン ビルドに使用されたものは正規とみなされ、BFT ではブロックごとにいくつかの validator のセットが BFT のコンセンサスに達しました。 最近提案されたプロトコルでは、後者のアプローチがより有力です。 これは即時的な最終性を提供しますが、最長のチェーンではより多くのブロックが必要となるためです。 ファイナリティを保証するためにブロックの上に構築されます。多くの場合、意味のあることを目的として セキュリティ上、十分な数のブロックが構築されるまでに時間がかかります。 時間の順序。 各ブロックで BFT コンセンサスを使用すると、次のような欠点もあります。 1. BFT コンセンサスにはかなりの量のコミュニケーションが必要です。その間 最近の進歩により、数の点で直線的な時間内に合意に達することが可能になりました 参加者の数 (例: [4] を参照) であっても、ブロックあたりのオーバーヘッドは依然として顕著です。 2. すべてのネットワーク参加者が BFT に参加することは不可能です。 したがって、通常はランダムに抽出された参加者のサブセットのみがコンセンサスに達します。ランダムにサンプリングされたセットは、原則として次のようになります。 適応的に破損し、理論上はフォークが作成される可能性があります。システム どちらもそのようなイベントに備えてモデル化する必要があるため、 BFT コンセンサス以外にフォーク選択ルールがある、またはシャットダウンするように設計されている このようなイベントでダウンします。いくつかのデザインについて言及する価値があります。 Algorand [5] により、適応型破損の可能性が大幅に減少します。 3. 最も重要なのは、次の場合にシステムが停止することです。 参加者全員のうち3名以上が オフライン。したがって、一時的なネットワーク障害やネットワークの分裂により、システムが完全に停止する可能性があります。理想的には、システムは継続的に動作できる必要があります。 参加者の少なくとも半数がオンラインである限り動作します (最も重い チェーンベースのプロトコルは、参加者の半分未満がオンラインであっても動作し続けますが、この特性が望ましいかどうかについては議論の余地があります。 コミュニティ内）。 使用されるコンセンサスが最も重いものであるハイブリッド モデル チェーンですが、一部のブロックはBFT フィナリティ ガジェットを使用して定期的にファイナライズされ、両方のモデルの利点が維持されます。このようなBFT フィナリティ ガジェットは、 Ethereum 2.0 8、Casper CBC で使用される Casper FFG [6] (https://vitalik. を参照) ca/general/2018/12/05/cbc_casper.html) および GRANDPA (https:// を参照) Medium.com/polkadot-network/d08a24a021b5) Polkadot で使用されます。 Nightshade は最も重いチェーンのコンセンサスを使用します。 特にブロックのとき プロデューサーはブロックを生成し (セクション 3.3 を参照)、ブロックから署名を収集できます。 他のブロックプロデューサーと前のブロックを証明するvalidator。セクションを参照 このような多数の署名がどのように集約されるかについては、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 という 2 つの役割があります。 いずれにしても システムには w ブロックプロデューサーが含まれている点、モデルでは w = 100、および wv validators、私たちのモデルでは v = 100、wv = 10,000。システムはプルーフ・オブ・ステークです。 つまり、ブロックプロデューサーとvalidatorの両方がいくつかの内部 通貨 (「tokens」と呼ばれます) は、 チェーンの構築と検証という職務の遂行に費やす時間。 すべての Proof of Stake システムと同様、すべての W ブロックプロデューサーがブロックするわけではありません。 それを強制することはできないため、すべての wv validator は異なるエンティティになります。それぞれ ただし、w ブロックプロデューサーと wv validator には別個の 賭け金。 システムには n 個のシャードが含まれており、このモデルでは n = 1000 です。で述べたように セクション 3.1 で説明したように、Nightshade にはシャード チェーンはなく、代わりにすべてのブロック プロデューサーと validator が単一の blockchain を構築しています。 メインチェーン。メインチェーンの状態は n 個のシャードに分割され、各ブロックは プロデューサーと validator は、現時点では、ローカルにダウンロードしたのは、 シャードの一部のサブセットに対応し、プロセスとのみに対応する状態 州のこれらの部分に影響を与えるトランザクションを検証します。 ブロックプロデューサーになるために、ネットワークの参加者はいくつかの大きなロックを行います。 token の金額 (ステーク)。ネットワークのメンテナンスはエポック単位で行われます。 ここで、エポックは数日程度の期間です。 参加者 特定のエポックの開始時に最大の賭け金が得られるブロックは、 その時代のプロデューサー。各ブロックプロデューサーは sw シャードに割り当てられます (たとえば、 sw = 40、これにより、sww/n = 4 シャードあたりのブロックプロデューサーになります）。ブロック プロデューサーは、エポック以前に割り当てられているシャードの状態をダウンロードします。 が開始され、エポック全体を通じてそのシャードに影響を与えるトランザクションを収集します。 そしてそれらを状態に適用します。 メインチェーン上の各ブロック b およびすべてのシャード s には、次のいずれかが存在します。 b に関連する部分を生成する責任がある s にブロック生成者を割り当てます。 シャードに。シャード s に関連する b の部分はチャンクと呼ばれ、 b に含まれるシャードのトランザクションのリストとマークル結果の状態のルート。 b には最終的には非常に小さなヘッダーのみが含まれます。 チャンク、つまり適用されたすべてのトランザクションのマークル ルート (セクションを参照) 正確な詳細については 3.7.1 を参照)、最終状態のマークル ルート。 ドキュメントの残りの部分では、ブロック プロデューサーについてよく言及します。 特定のシャードに対して特定の時間にチャンクを生成する役割を果たします。 チャンクプロデューサーとして。チャンクプロデューサーは常にブロックプロデューサーの 1 つです。 ブロックプロデューサーとチャンクプロデューサーは、次のように各ブロックをローテーションします。 固定スケジュールに。ブロックプロデューサーは命令を受けて繰り返し生産します。 この順序でブロックします。 例えば。 ブロックプロデューサーが 100 人いる場合、最初のブロック プロデューサーはブロック 1、101、201 などの生成を担当し、2 番目はブロックです。 2、102、202など）の制作を担当。 チャンク生成はブロック生成と異なりメンテナンスが必要となるため、 状態、および各シャードについてのみ sww/n ブロックプロデューサーが状態を維持します シャードごとに、それに対応して、それらの sww/n ブロックプロデューサーのみがローテーションして作成されます。 塊。例えば。上記の定数と 4 つのブロック プロデューサーが割り当てられたもの 各シャード、各ブロックプロデューサーは 4 ブロックごとにチャンクを作成します。 3.4 データの可用性を確保する データの可用性を確保するために、Polkadot と同様のアプローチを使用します。 セクション 2.5.3 で説明されています。ブロックプロデューサーがチャンクを生成すると、 の最適な (w, ⌊w/6 + 1⌋) ブロック コードを使用したその消失符号化バージョン チャンク。 次に、消去符号化されたチャンクの 1 つの部分を送信します (このような部分を チャンク部分、または部分のみ）を各ブロックプロデューサーに送信します。 すべての部分を葉として含むマークル ツリーを計算します。 各チャンクのヘッダーには、そのようなツリーのマークル ルートが含まれます。 パーツは onepart メッセージを介して validator に送信されます。そういったメッセージ一つ一つが チャンクヘッダー、パートの序数、およびパートの内容が含まれます。の メッセージには、ブロックを作成したブロックプロデューサーの署名も含まれています。 チャンクとその部分がヘッダーに対応することを証明するマークル パス 適切なブロックプロデューサーによって生成されます。 ブロックプロデューサーがメインチェーンブロックを受け取ると、まず、それらがメインチェーンブロックであるかどうかを確認します。 ブロックに含まれるチャンクごとに 1 つのパート メッセージが含まれます。そうでない場合はブロック 欠落している onepart メッセージが取得されるまで処理されません。 すべての onepart メッセージが受信されると、ブロックプロデューサーは 残りの部分をピアから取得し、ピアが保持するチャンクを再構築します。 状態。 少なくとも 1 つのメイン チェーン ブロックの場合、ブロック プロデューサーはメイン チェーン ブロックを処理しません。 ブロックに含まれるチャンクに対応する onepart メッセージがない場合、または状態を維持する少なくとも 1 つのシャードについては、 チャンク全体を再構築します。 特定のチャンクを利用可能にするには、ブロックの ⌊w/6⌋+1 だけで十分です 生産者は自分の役割を持ち、それを提供します。したがって、その数が続く限り、 悪意のあるアクターは ⌊w/3⌋ ブロックの半分を超えるチェーンを超えない それを構築するプロデューサーは、使用できないチャンクを持つ可能性があります。図 17: 各ブロックにはシャードごとに 1 つまたはゼロのチャンクが含まれており、各チャンクには 消去符号化されています。 Erasure Code チャンクの各部分は、指定されたアドレスに送信されます。 特別な onepart メッセージを介してプロデューサーをブロックする 3.4.1 遅延ブロックプロデューサーへの対処 ブロックプロデューサーに onepart メッセージが欠落しているブロックがある場合、 ブロックがチェーン上に存在することになった場合、まだ署名することを選択する可能性があります。 ブロックプロデューサーの報酬を最大化します。ブロックのリスクはありません ブロックプロデューサーが持っていなかったことを後で証明することは不可能であるため、プロデューサー ワンパートメッセージ。 これに対処するために、チャンクを作成するときに各チャンクをプロデューサーにします。 今後エンコードされるチャンクの各部分の色 (赤または青) を選択し、保存します エンコード前のチャンク内の割り当てられた色のビットマスク。それぞれのパート メッセージにはパーツに割り当てられた色が含まれており、その色は次の場合に使用されます。 エンコードされた部分のマークルルートを計算します。チャンクプロデューサーが外れると プロトコルから、マークルルートが存在しないため、それは簡単に証明できます。 onepart メッセージ、または onepart メッセージの色に対応します。 マークル ルートに対応するものは、チャンク内のマスクとは一致しません。 ブロックプロデューサーがブロックに署名するとき、すべてのブロックのビットマスクが含まれます。 ブロックに含まれるチャンクとして受け取った赤い部分。の出版 不正なビットマスクはスラッシュ可能な動作です。ブロックプロデューサーが 一部のメッセージでは、メッセージの色を知る方法がありません。 したがって、彼らが盲目的に署名しようとすると、切りつけられる可能性が50％あります。 ブロック。 3.5 状態遷移アプリケーション チャンクプロデューサーは、チャンクに含めるトランザクションを選択するだけですが、 チャンクを生成するときに状態遷移を適用しません。これに対応して、
チャンクヘッダーには、以前のメルケル化状態のマークルルートが含まれます チャンク内のトランザクションが適用されます。 トランザクションは、チャンクを含む完全なブロックが存在する場合にのみ適用されます。 処理されます。参加者は次の場合にのみブロックを処理します。 1. 前のブロックが受信され、処理されました。 2. 各チャンクについて、参加者はその状態を維持しません。 onepart メッセージを確認しました。 3. 各チャンクについて、参加者は状態を維持します。 完全なチャンク。 ブロックが処理されると、参加者が参加するシャードごとに 状態を維持し、トランザクションを適用して新しい状態を計算します トランザクションが適用された後の時点で、トランザクションを生成する準備が整います。 次のブロックのチャンク（シャードに割り当てられている場合）。 新しいメルケル化国家のマークルルート。 3.6 クロスシャードトランザクションと領収書 トランザクションが複数のシャードに影響を与える必要がある場合は、連続して影響を与える必要があります。 各シャードで個別に実行されます。トランザクション全体が最初のシャードに送信されます 影響を受け、トランザクションがそのようなシャードのチャンクに含まれると、 チャンクがブロックに含まれた後に適用され、いわゆるレシートが生成されます。 トランザクション。トランザクションが必要な次のシャードにルーティングされます。 処刑される。さらに多くの手順が必要な場合は、受領トランザクションの実行 新しい領収書トランザクションなどを生成します。 3.6.1 受信トランザクションの有効期間 レシートトランザクションは、それが生成されたブロックの直後のブロックで適用されることが望ましい。受け取り取引のみです 前のブロックがブロックプロデューサーによって受信および適用された後に生成されます 元のシャードを維持しており、 次のブロックのチャンクは宛先のブロックプロデューサーによって生成されます 破片。したがって、受領書はソースシャードからシャードに通信される必要があります。 これら 2 つのイベントの間の短い時間枠で宛先シャードを作成します。 A を、レシート r を生成するトランザクション t を含む、最後に生成されたブロックであるとします。 B を次に生成されるブロック (つまり、A を持つブロック) とします。 その前のブロック)、r を含めたいとします。 t をシャード a と r に含めます。 シャード内 b. 図 18 にも示されているレシートの有効期間は次のとおりです。 領収書の作成と保管。シャードのチャンクプロデューサーの CPA a はブロック A を受け取り、トランザクション t を適用し、レシート r を生成します。公認会計士 次に、作成されたすべてのレシートをインデックス付きの内部永続ストレージに保存します。 ソースシャードIDによって異なります。領収書を配布します。 CPA がチャンクを生成する準備ができたら、 ブロック B のシャード a、ブロック A からシャード a のトランザクションを適用することによって生成されたすべてのレシートをフェッチし、それらをシュラッドのチャンクに含めます。 ブロック B 内の a。そのようなチャンクが生成されると、cpa はその消去符号化を生成します。 バージョンと、対応するすべての onepart メッセージ。 cpa は、どのブロックプロデューサーがどのシャードの完全な状態を維持しているかを知っています。特定のブロックプロデューサーの場合 bp cpa には、ブロック A のトランザクションを適用した結果生じた入金が含まれます bp が宛先として気にしているシャードのいずれかを含むシャード a の場合 ブロック B のシャード a のチャンクを配布したときの onepart メッセージ内 (onepart メッセージに含まれるレシートを示す図 17 を参照)。 領収書の受け取り。参加者 (ブロック プロデューサーと validator の両方) は、onepart メッセージを取得するまでブロックを処理しないことに注意してください。 ブロックに含まれるチャンクごとに。したがって、特定の参加者がブロック B を適用するまでに、参加者は、以下に対応するすべての onepart メッセージを取得します。 B にチャンクがあるため、シャードを含むすべての受信レシートが存在します。 参加者は目的地としての状態を維持します。 適用するときは、 特定のシャードの状態遷移の場合、参加者は両方のレシートを適用します onepart メッセージ内のシャード用に収集したものと、すべての チャンク自体に含まれるトランザクション。 図 18: 領収書トランザクションの有効期間 3.6.2 多すぎる領収書の処理 特定のシャードをターゲットとする受信の数が、 特定のブロックが大きすぎて処理できません。たとえば、図 19 を考えてみましょう。 各シャードの各トランザクションは、シャード 1 を対象とするレシートを生成します。 次のブロックまでに、シャード 1 が処理する必要があるレシートの数は次のとおりです。 処理中にすべてのシャードが結合して処理された負荷に相当します 前のブロック。
図 19: すべてのレシートが同じシャードをターゲットにしている場合、シャードには それらを処理する能力 これに対処するために、QuarkChain 9 で使用されているのと同様の技術を使用します。 具体的には、各シャードの最後のブロック B とその中の最後のシャード s レシートが適用されたブロックが記録されます。新しいシャードが作成されるとき 作成されると、レシートは B の残りのシャードから順に適用されます。 次に、B に続くブロックで、新しいチャンクがいっぱいになるまで続けます。正常時 バランスのとれた負荷がある状況では、通常、すべての受信が発生します。 適用されます (したがって、最後のブロックの最後のシャードが記録されます) 各チャンク)、負荷のバランスが取れていない時間帯、および特定の シャードは不釣り合いに多くのレシートを受け取りますが、このテクニックにより、シャードは次のことが可能になります。 含まれるトランザクション数の制限を尊重しながら処理されます。 このような偏荷重が長時間続くと、 アプリケーションが無限に成長し続けるまで、レシートの作成は行われません。 1 つ これに対処する方法は、 ある定数 (1 エポックなど) を超える処理遅延があるシャード。 図 20 を考えてみましょう。ブロック B により、シャード 4 はすべてのレシートを処理できなくなります。 したがって、ブロック A のシャード 3 までの受信のみを処理します。 それを記録します。ブロック C には、ブロック B のシャード 5 までのレシートが含まれており、 その後、ブロック D までにシャードが追いつき、残りのすべてのレシートを処理します。 ブロック B とブロック C からのすべてのレシート。 3.7 チャンクの検証 特定のシャード用に生成されたチャンク (またはシャード チェーンを含むモデル内の特定のシャード チェーン用に生成されたシャード ブロック) は、 9QuarkChainを使用したホワイトボードのエピソードはこちらでご覧ください: https://www.youtube.com/watch? v=opEtG6NM4x4: クロスシャード トランザクションへのアプローチなどが説明されています。 物図 20: 領収書の処理が遅れている 状態を維持する参加者。これらはブロックプロデューサー、validators、 または、状態をダウンロードしてシャードを検証した外部の証人だけ 彼らは資産を保管します。 この文書では、参加者の大多数がデータを保存できないことを想定しています。 シャードの大部分の状態。ただし、言及する価値があります。 次のことを前提として設計されたシャード化された blockchain が存在すること ほとんどの参加者は、ほとんどの状態を保存し、検証する能力を持っています。 QuarkChain などのシャード。 参加者の一部だけがシャードを検証する状態を持っているため、 チャンクを持っている参加者だけを適応的に破損させることが可能です。 状態を変更し、無効な状態遷移を適用します。 数回ごとに validator をサンプリングする複数のシャーディング設計が提案されました 2/3 を超えるシャード チェーン内のブロックは 1 日以内に削除されます。 そのようなシャードに割り当てられた validator の署名が直ちに考慮されます 最後。このようなアプローチでは、適応型の敵対者は 2n/3+1 を破壊するだけで済みます。 シャード チェーン内の validator の無効な状態遷移を適用します。 実現するのは難しいと思われますが、一般の人々にとってセキュリティのレベルは十分ではありません blockchain。 セクション 2.3 で説明したように、一般的なアプローチは、状態 (状態に関係なく) を持つ参加者に対してブロックが作成された後、一定の時間枠を許可することです。 それはブロックプロデューサー、validator、または外部オブザーバーです) の正当性に異議を唱えます。このような参加者はフィッシャーマンと呼ばれます。漁師ができるようになるためには、 無効なブロックに異議を唱える場合は、そのようなブロックが利用可能であることを確認する必要があります。 彼ら。 Nightshade でのデータの可用性については、セクション 3.4 で説明します。 Nightshade では、ブロックが生成されると、チャンクは検証されませんでした。 実際のチャンクプロデューサー以外の誰でも。特に、ブロックプロデューサーは、 ブロックには自然にほとんどのシャードの状態が存在しないことを示唆し、チャンクを検証できませんでした。次のブロックが生成されると、そのブロックには複数のブロック生成者の証明書 (セクション 3.2 を参照) と validator が含まれます。 ただし、ブロックプロデューサーとvalidatorの大部分は状態を維持しないため ほとんどのシャードでも、無効なチャンクが 1 つだけあるブロックは、半分以上の認証を収集し、最も重いブロックに残り続けます。 チェーン。 この問題に対処するために、次の状態を維持する参加者を許可します。 シャードで生成された無効なチャンクに対してオンチェーンでチャレンジを送信するためのシャード 破片。 3.7.1 状態の有効性のチャレンジ 参加者が特定のチャンクが無効であることを検出したら、そのチャンクが無効であるという証拠を提供する必要があります。ネットワーク参加者の大多数は、無効なチャンクが含まれるシャードの状態を維持しないため、 証明には、ブロックが正しいことを確認するのに十分な情報が必要です。 状態がなければ無効です。 単一トランザクションが実行できる状態量 (バイト単位) の制限 Ls を設定します。 累積的に読み取りまたは書き込みができます。 Ls を超えるトランザクション 状態は無効とみなされます。セクション 3.5 で述べたチャンクを思い出してください。 特定のブロック B には、適用されるトランザクションのみが含まれますが、 新しい状態のルート。ブロック B のチャンクに含まれるステート ルートはステートです。 そのようなトランザクションを適用する前、ただしトランザクションを適用した後は root にアクセスします。 同じシャード内のブロックの前の最後のチャンク B. 悪意のある攻撃者 無効な状態遷移を適用しようとすると、不正な状態ルートが含まれる可能性があります 適用の結果生じるステートルートに対応しないブロック B 内 前のチャンク内のトランザクション。 チャンクプロデューサーがチャンクに含める情報を拡張します。 すべてのトランザクションを適用した後の状態を単に含めるのではなく、 連続する各トランザクション セットを適用した後の状態ルートが含まれます。 Ls バイトの状態をまとめて読み書きします。 この情報をもとに、 漁師は、状態遷移が誤って適用されるという課題を作成します。 最初の無効な状態ルートを見つけて、その Ls バイトだけを含めるには十分です。 最後のステート ルート (以前のステート ルート) 間のトランザクションによって影響を受けるステート 有効）とマークル証明付きの現在の状態ルート。その後、参加者全員が セグメント内のトランザクションを検証し、チャンクが有効であることを確認できます。 無効です。 同様に、チャンクプロデューサーが以下のトランザクションを含めようとした場合、 Ls バイトを超える状態を書き込みます。チャレンジには、以下を含めるだけで十分です。 マークル証明と接触する最初の Ls バイト。これで十分です。 トランザクションを適用し、次の処理が実行される瞬間があることを確認します。 Ls バイトを超えるコンテンツの読み取りまたは書き込みが行われます。
3.7.2 漁師と高速クロスシャードトランザクション セクション 2.3 で説明したように、シャード チャンク (またはシャード) が シャード チェーンを含むモデル内のブロック）が無効になり、問題が発生する可能性があります その間、それはフィナリティに悪影響を及ぼし、したがってシャード間の通信に悪影響を及ぼします。で 特に、シャード間トランザクションの宛先シャードは確実ではありません。 元のシャード チャンクまたはブロックは、チャレンジ期間が終了するまで最終的なものとなります (図 21 を参照)。 図 21: レシートを適用する前にチャレンジ期間を待っています クロスシャードトランザクションを行う方法でこれに対処する方法 瞬時とは、宛先シャードがチャレンジ期間を待たないことです。 ソースシャードトランザクションが公開された後、レシートトランザクションを適用します すぐにロールバックしますが、その後、ソースシャードとともに宛先シャードをロールバックします。 元のチャンクまたはブロックが後で無効であることが判明した場合のシャード (図を参照) 22）。これは、シャードが含まれる Nightshade のデザインにも非常に自然に当てはまります。 チェーンは独立していませんが、代わりにシャード チャンクがすべて公開されます 同じメインチェーンブロック内に一緒に。いずれかのチャンクが無効であることが判明した場合、 そのチャンクを含むブロック全体が無効とみなされ、その上に構築されたすべてのブロックが無効と見なされます。 その頂上。図 23 を参照してください。 上記のアプローチは両方とも、チャレンジを前提としてアトミック性を提供します。 期間が十分に長い。通常の状況下では高速なクロスシャード トランザクションを提供する方が不便さを上回るため、後者のアプローチを使用します。 いずれかの無効な状態遷移により、宛先シャードがロールバックします。 ソースシャード、これは非常にまれなイベントです。 3.7.3 validator を非表示にしています 課題の存在により、すでに次のような可能性が大幅に減少しています。 無効な状態遷移ポストでチャンクを終了するため、適応的な破損が発生します。図 22: 領収書をただちに適用し、宛先をロールバックする ソースチェーンに無効なブロックがあった場合はチェーン 図 23: ナイトシェイドでの漁師チャレンジ 適応的な敵対者がすべての参加者を堕落させるために必要なチャレンジ期間 すべての validator を含む、シャードの状態を維持するもの。 このようなイベントが発生する可能性を推定することは非常に複雑です。 シャード化された blockchain は、そのような攻撃が試行されるのに十分な期間存続しています。我々は、その可能性は極めて低いとはいえ、それでも十分にあると主張する。 数百万のトランザクションを実行することが予想されるシステムとしては大規模であり、 世界規模の金融業務を運営します。 この考えには主に 2 つの理由があります。 1. Proof-of-Stake チェーンおよびマイナーの validator のほとんど
Proof-of-Work チェーンは主に財務上の好転によって奨励されます。もし 適応的な敵対者は、期待される利益よりも多くの資金を提供します 正直に動作することから、多くの validator が発生することが予想されます。 申し出を受け入れるでしょう。 2. 多くの企業が Proof-of-Stake チェーンの検証を専門的に行っており、 どのチェーンでも株式の大部分が そのような実体から。そのようなエンティティの数は、 適応的な敵対者として、彼らのほとんどを個人的に知り、 彼らが腐敗する傾向があることをよく理解しています。 どの validator がどのシャードに割り当てられているかを非表示にすることで、適応型破損の可能性を減らすためにさらに一歩進んでいます。アイデアは Algorand [5] が validator を隠す方法とほぼ同じです。 Algorand のように、validator が隠蔽されている場合でも注意することが重要です。 あるいは、以下で説明するように、適応的な破損は理論的には依然として可能です。その間 適応型の敵対者は、作成または検証する参加者を知りません。 ブロックでもチャンクでも、参加者自身が自分が実行することを知っています。 そのようなタスクを実行し、その暗号による証明を持っています。 したがって、敵は、 腐敗させる意図をブロードキャストし、提供してくれる参加者に報酬を支払う そのような暗号証明。ただし、敵はそうではないため、 破損させたいシャードに割り当てられている validator を知っている場合、 特定のシャードを破壊する意図をブロードキャストする以外に選択肢はありません。 コミュニティ全体。その時点で、正直な人にとっては経済的に有益です。 参加者は、そのシャードを検証する完全なノードをスピンアップします。 そのシャードに無効なブロックが出現する可能性があり、これは チャレンジを作成し、関連する報酬を集めます。 特定のシャードに割り当てられている validator を公開しないようにするには、 以下のとおりです (図 24 を参照)。 VRF を使用して割り当てを取得します。各エポックの開始時にそれぞれ validator は VRF を使用して、validator が割り当てられているシャードのビットマスクを取得します。 各 validator のビットマスクには Sw ビットがあります (定義についてはセクション 3.3 を参照してください) スイス）。次に、validator は対応するシャードの状態をフェッチし、 エポック中に、受信したブロックごとに、対応するチャンクを検証します validator が割り当てられているシャードに。 チャンクではなくブロックにサインオンします。シャードの割り当ては隠蔽されているため、validator はチャンクに署名できません。代わりに、常に全体に署名します ブロックするため、どのシャードを検証するかは明らかにされません。具体的には、validator がブロックを受信してすべてのチャンクを検証すると、メッセージが作成されます。 これは、validator が割り当てられているすべてのシャード内のすべてのチャンクが 有効 (それらのシャードが何であるかをまったく示さずに)、または次のようなメッセージ いずれかのチャンクが無効な場合、無効な状態遷移の証明が含まれます。を参照してください。 このようなメッセージがどのように集約されるかについてはセクション 3.8、詳細についてはセクション 3.7.4 を参照してください。 validators が次からのメッセージに便乗するのを防ぐ方法の詳細 その他のvalidator、および報酬と罰の詳細についてはセクション 3.7.5 を参照してください。 validators は、無効な状態遷移チャレンジが実際に成功した場合に発生します。図 24: Nightshade で validator を隠す 3.7.4 コミットと公開 validators に関する一般的な問題の 1 つは、validator が状態のダウンロードと実際のチャンクとブロックの検証をスキップし、その代わりに ネットワークを観察し、他の validator が送信した内容を確認し、その内容を繰り返します。 メッセージ。このような戦略に従う validator は、追加の機能を提供しません。 ネットワークのセキュリティを確保しますが、報酬も収集します。 この問題の一般的な解決策は、validator ごとに証明を提供することです。 たとえば独自のトレースを提供するなどして、ブロックを実際に検証したこと 状態遷移を適用する必要がありますが、そのような証明はコストを大幅に増加させます 検証の。 図 25: コミットと公開
代わりに、validators を最初に検証結果にコミットします (どちらか チャンクの有効性を証明するメッセージ、または無効であることの証明 状態遷移)、図 25 に示すように、一定期間待機してから初めて実際の検証結果が表示されます。コミット期間は次の期間と交差しません。 公開期間があるため、怠惰な validator は正直な validator をコピーできません。 さらに、不正な validator が、 割り当てられたチャンクの有効性、および少なくとも 1 つのチャンクが無効になった場合 チャンクが無効であることが示されているため、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 に示す状態。 validator が割り当てられたシャードを明らかにした瞬間から注意してください。 新しいエポックが始まるまで、システムのセキュリティは低下します。 シャードの割り当てが明らかになります。ネットワークの参加者はそれを保管する必要があります その間ネットワークをご利用になる際はご注意ください。 3.8 署名の集約 数百のシャードを含むシステムが安全に動作するには、 10,000 validator 以上の注文。セクション 3.7 で説明したように、それぞれが必要です。図 26: 課題への対処 validator 特定のメッセージに対するコミットと署名を平均して公開します ブロックごとに 1 回。たとえコミットメッセージが同じであっても、そのようなメッセージを集約すると、 BLS 署名とその検証には法外な費用がかかるでしょう。でも 当然のことながら、コミット メッセージとリビール メッセージは validator 間で同じではありません。 したがって、そのようなメッセージと署名を 1 つのファイルに集約する何らかの方法が必要です。 これにより、後で迅速に検証できるようになります。 私たちが使用する具体的なアプローチは次のとおりです。 ブロックプロデューサーに参加するバリデーター。ブロックプロデューサーは既知です エポックが始まる少し前に、ダウンロードするのに時間がかかるため、 エポックが開始する前の状態であり、validator とは異なり、ブロックプロデューサーは 隠蔽されていない。各ブロックプロデューサーには v validator スロットがあります。バリデーターが送信する ブロックプロデューサーへのオフチェーンの提案で、ブロックプロデューサーの 1 つとして含めることができます。 validator秒。ブロックプロデューサーがvalidatorを含めたい場合は、 validator からの最初のオフチェーンリクエストを含むトランザクション、および validator をブロック プロデューサーに参加させるブロック プロデューサーの署名。 ブロックプロデューサーに割り当てられた validator は必ずしも ブロックプロデューサーがチャンクを生成するのと同じシャードを検証します。 もし validator は複数のブロックプロデューサーの結合に適用されます。ブロックプロデューサーからのトランザクションのみです。 最初のブロックプロデューサーが成功します。 ブロックプロデューサーはコミットを収集します。ブロック プロデューサーは、validator からコミット メッセージとリビール メッセージを常に収集します。このようなメッセージが一定数蓄積されると、ブロックプロデューサーはマークルを計算します。 これらのメッセージのツリーを作成し、各 validator にマークル ルートと 彼らのメッセージへのマークルパス。 validator はパスを検証し、サインオンします。 マークルルート。次に、ブロックプロデューサーは BLS 署名を validators からマークル ルートを取得し、マークル ルートと 積み上げたサイン。ブロックプロデューサーは、ブロックの有効性にも署名します。 安価な ECDSA 署名を使用したマルチ署名。マルチ署名が機能しない場合 送信されたマークル ルート、または参加している validator のビットマスクと一致する場合、これはスラッシュ可能な動作です。チェーンを同期するとき、参加者は validators からのすべての BLS 署名を検証することを選択できます (validators の公開鍵の集約が必要なため、非常にコストがかかります)、またはのみを検証することもできます。ブロックプロデューサーからの ECDMA 署名を使用し、次の事実に依存します。 ブロックプロデューサーは異議を申し立てられず、切り捨てられました。 オンチェーントランザクションとマークルプルーフをチャレンジに使用します。それ そうでない場合、validators からのメッセージを公開しても意味がないことに注意してください。 無効な状態遷移が検出されました。実際の内容を含むメッセージのみ 無効な状態遷移の証拠は、そのようなメッセージに対してのみ明らかにされる必要があります。 それらが前のコミットと一致することを示す必要があります。メッセージには次のことが必要です 次の 2 つの目的で公開されます。 1. 実際にチェーンのロールバックを開始して、直前の時点に戻します。 無効な状態遷移 (セクション 3.7.5 を参照)。 2. validator が、 無効なチャンクです。 いずれの場合も、次の 2 つの問題に対処する必要があります。 1. 実際のコミットはチェーンに含まれておらず、マークルルートのみがチェーンに含まれていました。 他のメッセージと集約されたコミット。 validator は、 ブロックプロデューサーによって提供されるマークルパスとその元のコミット 彼らがその挑戦に真剣に取り組んでいることを証明します。 2. シャードに割り当てられているすべての validator が無効である可能性があります。 状態遷移は破損したブロックプロデューサーに割り当てられているため、 彼らを検閲しているのだ。それを回避するために、私たちは彼らが公開を提出することを許可します オンチェーン上の通常のトランザクションとして、集約をバイパスします。 後者は、無効な状態遷移の証明にのみ許可されます。 非常にまれであるため、ブロックのスパム送信にはならないはずです。 対処する必要がある最後の問題は、ブロックプロデューサーが次のことを行うことができるということです。 メッセージ集約に参加しないことを選択するか、特定の validator を意図的に検閲します。ブロック化することで経済的に不利になります プロデューサーの報酬は、割り当てられた validator の数に比例します。私たち また、エポック間のブロックプロデューサーが大部分で交差していることにも注意してください（ 常に最も高い賭け金を持つ上位 2 人の参加者です)、validator は次のことができます 同じブロックプロデューサーとの連携にほぼ固執するため、リスクが軽減されます。 過去に検閲を行ったブロックプロデューサーに割り当てられたことについて。 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 署名が正しいことを確認し (オプションで validator の個々の BLS 署名も検証します)、同期のみを行います。 最後のスナップショット ブロックからのメイン チェーン ブロック。
Phần kết luận
Trong tài liệu này, chúng tôi đã thảo luận các phương pháp tiếp cận để xây dựng blockchain phân đoạn và đã giải quyết được hai thách thức lớn với các phương pháp tiếp cận hiện có, đó là tính hợp lệ của trạng thái và tính sẵn có của dữ liệu. Sau đó chúng tôi đã giới thiệu Nightshade, một thiết kế sharding quyền hạn NEAR Giao thức. Thiết kế đang được tiến hành, nếu bạn có ý kiến, câu hỏi hoặc phản hồi trên tài liệu này, vui lòng truy cập https://near.chat.
結論
このドキュメントでは、シャード化された blockchain を構築するアプローチについて説明しました。 既存のアプローチの 2 つの主要な課題、つまり状態の妥当性をカバーしました。 データの可用性。次に、Nightshade というシャーディング デザインを提案しました。 NEAR プロトコルを強化します。 デザインは進行中です。コメント、質問、フィードバックがありましたら このドキュメントについては、https://near.chat. にアクセスしてください。