Đối với chúng tôi, bảo mật của mạng là mối quan tâm hàng đầu, do đó chúng tôi đang bắt đầu một loạt các bài viết thảo luận về thiết kế mạnh mẽ của chúng tôi. Để bắt đầu, bài viết này trả lời hai câu hỏi quan trọng xuất hiện trong các tương tác gần đây của chúng tôi với các nhà phát triển.

Q: Làm thế nào để bạn giảm thiểu nếu một nhóm độc hại tạo ra một khối đã ký với các giao dịch chéo xấu?

Tôi sẽ bắt đầu với việc giải thích các yêu cầu tối thiểu của hệ thống của chúng tôi. Vào ngày đầu tiên ra mắt, giao thức Elrond sẽ có ít nhất 800 trình xác nhận, 400 cho một phân đoạn và 400 khác cho metachain. Chúng tôi có một yêu cầu rằng bất kỳ phân đoạn nào cũng phải chứa ít nhất 400 trình xác nhận, nếu không thì phân đoạn sẽ không được tạo hoặc nó sẽ được hợp nhất với một trình phân tích khác.

Một vài điểm nổi bật hơn:

• Yêu cầu / giả định BFT 75% trong tổng số các nút là các tác nhân tốt;
• Xác suất được tính toán với giả định rằng 25% các nút là độc hại. Ở cấp độ phân đoạn, chúng tôi chấp nhận tối đa 33% các nút độc hại. Tính toán được thực hiện với 10 phân đoạn, 4000 nút trong đó 1000 nút độc hại.
• Trình xác nhận ban đầu để phân bổ shard là ngẫu nhiên, nguồn ngẫu nhiên cho đến từ metachain. Khi một trình xác nhận mới xuất hiện, nó được phân bổ ngẫu nhiên cho một phân đoạn hiện có. Nhiều nhất là 30% các nút được chia sẻ lại vào cuối mỗi kỷ nguyên;
• Kích thước nhóm đồng thuận trong metachain là 400, người lãnh đạo thay đổi ở mỗi vòng (5 giây), để ký một khối ⅔ + 1 phải ký tên, đó là 267 người xác nhận;
• Kích thước nhóm đồng thuận trong phân đoạn là 63, nó được chọn ngẫu nhiên từ bộ đệm 400, thay đổi ở mỗi vòng. * 63 + 1 bằng 43 - trình xác nhận cần thiết để ký một khối.
• Hạt giống ngẫu nhiên là một chuỗi hạt giống, không thiên vị, không dự đoán được, không thể thay đổi. Người lãnh đạo của khối hiện tại ký hạt giống ngẫu nhiên của khối trước bằng khóa riêng của mình, sử dụng lược đồ chữ ký đơn BLS, số đó được băm và trở thành hạt giống ngẫu nhiên cho lựa chọn nhóm tiếp theo;
• Chữ ký đơn BLS - một tin nhắn đã ký với kết quả khóa riêng được cố định;
• Khối tài chính: khối N chỉ là cuối cùng nếu khối N-1, khối N-2 khối khối NK được ký. Metachain chỉ có công chứng khối cuối cùng. Hiện tại chúng tôi đã chọn K = 1;

Xác suất để một siêu đa số độc hại (> 67%) được chọn cho cùng một vòng trong cùng một sự đồng thuận là 10 ^ -9, ngay cả khi 33% các nút từ phân đoạn là độc hại. Trong trường hợp đó, họ có thể đề xuất một khối và ký tên - hãy gọi nó là BLOCK M, nhưng nó sẽ không được công chứng bởi metachain. Metachain công chứng BLOCK M, chỉ khi BLOCK M + 1 được xây dựng trên nó. Để tạo BLOCK M + 1, nhóm đồng thuận tiếp theo phải đồng ý với BLOCK M. Chỉ một nhóm độc hại sẽ đồng ý với BLOCK M, vì vậy nhóm tiếp theo phải có siêu đa số độc hại một lần nữa. Vì hạt giống ngẫu nhiên cho lựa chọn nhóm không thể bị can thiệp, nên xác suất chọn một nhóm siêu đa số độc hại là ~ 10 ^ -9 - chính xác là 5,38 * 10 ^ -10.

Xác suất ký hai khối độc hại liên tiếp bằng với việc chọn hai nhóm con có ít nhất (* 63 + 1) thành viên từ nhóm độc hại. Xác suất cho điều này là: ~ 10 ^ -18.

Hơn nữa, các nhóm được chọn do đó phải thông đồng, nếu không các khối sẽ không được ký.

Chúng tôi đã chứng minh rằng giao thức được chứng minh an toàn trước các giao dịch không hợp lệ.

Q: Làm thế nào để bạn giảm thiểu việc phân mảnh chiếm giữ ? Có phải việc phân mảnh chiếm giữ là có thể?

Giao thức được thiết kế theo cách an toàn có thể chứng minh được và xác suất việc phân mảnh chiếm giữ là cực kỳ thấp: 2,88 * 10 ^ -78 . Một kiến ​​trúc phân mảnh phải được xây dựng theo cách như vậy, khiến nó không thể bị chiếm giữ bởi một mảnh vỡ.
Phân giải phân mảnh chiếm giữ :

Giải pháp dự phòng, ngay cả đối với trường hợp không thể này. Tình trạng: nghiên cứu được thực hiện, hai giải pháp có thể, thực hiện kế hoạch sau khi thử nghiệm mạng đầu tiên ra mắt.

Giải pháp 1:

Khi tạo ra mỗi khối, nhà lãnh đạo sẽ thêm một bằng chứng rằng tiền không được tạo ra từ không khí mỏng. Bằng chứng này sẽ được xác minh bởi metachain và bởi mỗi phân đoạn đích.

Giải pháp 2:

Khi nhà lãnh đạo đề xuất một khối, anh ta thêm vào tiêu đề cũng là bằng chứng xác thực cho một vài tài khoản đã thay đổi số dư của họ trong quá trình thực thi khối. Việc lựa chọn các tài khoản này cần phải có tính xác định, ví dụ: lấy tài khoản từ giao dịch đầu tiên trong mỗi xe buýt nhỏ và cung cấp bằng chứng tổng hợp đi từ tất cả các tài khoản này đến hàm băm gốc được đăng ký trong khối. Khi một khối không hợp lệ được đề xuất bởi đa số độc hại, gốc trạng thái bị giả mạo với kết quả không hợp lệ (sau khi bao gồm các thay đổi không hợp lệ đối với cây trạng thái).

Bằng cách cung cấp bằng chứng merkle kết hợp cho một số tài khoản, điều này cho phép thách thức cho bằng chứng đó được đưa ra bởi một nút trung thực. Các nút trung thực sẽ cung cấp khối giao dịch, cây merkle giảm trước đó với tất cả các tài khoản bị ảnh hưởng trước khi áp dụng khối bị thách thức và trạng thái SC. Nếu các bằng chứng không được cung cấp trong khung thời gian giới hạn, thử thách được coi là không đầy đủ và tất cả các tin nhắn sẽ bị loại bỏ. Không có dấu gạch chéo xảy ra, khối thách thức được coi là hợp lệ.

Chi phí của một thách thức không hợp lệ là toàn bộ cổ phần của nút.

Điều này sẽ cho phép metachain thử và áp dụng các thay đổi vì nó đã có cây trạng thái trước đó (chỉ dành cho các tài khoản bị ảnh hưởng) và sẽ có thể phát hiện sự không nhất quán, giao dịch không hợp lệ hoặc gốc trạng thái không hợp lệ. Điều này có thể được truy tìm và nhóm đồng thuận có thể bị cắt giảm. Đồng thời, người thách đấu có thể được thưởng một phần số tiền bị cắt. Chúng ta cần điểm chuẩn kích thước của một bằng chứng như vậy cho các giao dịch được phép tối đa trong khối. Cũng như nếu vấn đề liên quan đến hoạt động hợp đồng thông minh, thì việc thực thi SC là cần thiết, nhưng đối với điều này, chúng tôi vẫn có thể đảm bảo ít nhất là không có khoản tiền nào được tạo ra mà không xác nhận tính đúng đắn của việc thực thi SC.

Giải pháp được tối ưu hóa hơn nữa bằng cách gửi bằng chứng cây merkle giảm chỉ khi thử thách , người thách thức trình bày cả bằng chứng giảm trước khi áp dụng khối không hợp lệ và chính khối đó.

Tuy nhiên, một nhóm độc hại thậm chí có thể ẩn khối khỏi các nút khác - những nhóm không độc hại. Trong trường hợp này, các nút trung thực, ngay cả khi họ biết rằng các khối mới đã được tạo ra (bằng cách nhìn thấy các tiêu đề mới được công chứng bởi metachain), họ không thể đưa ra các thách thức vì họ không có quyền truy cập vào dữ liệu khối. Không thể chứng minh điều đó.

Giải pháp là bắt buộc việc truyền bá từng khối được sản xuất đến mảnh vỡ của anh chị em và yêu cầu họ xác nhận việc tiếp nhận, gửi xác nhận cho metachain. Trong trường hợp này, chúng tôi có thể có những thách thức được nêu ra từ phân đoạn anh chị em, vì các nút đó có quyền truy cập vào các khối và cũng có thể xác minh chúng. Một lợi thế khác với điều này là có một kênh khác nơi các nút trung thực có thể yêu cầu dữ liệu nếu chúng bị từ chối bởi các nút phân đoạn của chính chúng. Chi phí liên lạc được giảm thêm bằng cách chỉ gửi các xe buýt nhỏ xâm nhập đến mảnh vỡ anh chị em. Các xe buýt nhỏ shard chéo luôn được gửi theo các chủ đề khác nhau có thể truy cập bởi các nút quan tâm. Cuối cùng, các thách thức có thể được đưa ra bởi nhiều nút trung thực.

Một sự bảo vệ khác được đưa ra bằng cách các chủ đề và thông điệp P2P được thiết lập. Việc liên lạc từ một phân đoạn tới metachain được thực hiện thông qua một tập hợp các chủ đề / kênh được xác định - metachain sẽ không chấp nhận bất kỳ tin nhắn nào khác từ các kênh khác.

Giải pháp này đưa ra một số độ trễ trong metachain chỉ trong trường hợp có thách thức, số lượng rất thấp và không có khả năng cao vì nếu được phát hiện (xác suất cao bị phát hiện), các nút có nguy cơ toàn bộ cổ phần của chúng. Sự đồng thuận của metachain sẽ thực hiện xác minh nhiều bằng chứng như vậy đến từ các phân đoạn khác nhau. Chúng tôi chỉ công chứng các khối từ các mảnh vỡ, nơi không có thử thách nổi bật, và đối với những người khác có thử thách, hãy cố gắng xử lý chúng càng sớm càng tốt, với ưu tiên được ưu tiên phục vụ trước và thực hiện việc chém cho người thách đấu nếu có sai báo động hoặc cho nhóm nếu thách thức được xác nhận.

Hơn nữa, nếu nhiều thách thức như vậy được xác nhận, metachain có thể kích hoạt lệnh kết thúc sớm. Trong trường hợp này, các nút độc hại bị cắt ngay lập tức và 30% tổng số nút được chia sẻ lại - những người vẫn có đủ cổ phần. Điều này đảm bảo rằng không có sự tiếp quản phân đoạn nào sẽ chặn giao thức trong một thời gian dài và có đủ các nút trong mỗi phân đoạn có thể đảm bảo an ninh. Mặt khác, nếu chúng ta chỉ chém một vài lần và không kết thúc kỷ nguyên, mỗi lần chúng ta loại bỏ 43 nút khỏi phân đoạn, chúng ta sẽ có ít hơn và ít nút hơn và bảo mật phân đoạn tổng thể giảm.

Vì vậy, chúng tôi đã mô tả giải pháp trong trường hợp không thể xảy ra, bây giờ chúng tôi chứng minh rằng xác suất thực tế là 0 đối với một nhóm siêu đa số độc hại được hình thành bên trong một mảnh vỡ được chọn.

Để tiếp quản phân đoạn, nhóm độc hại cần phải có ⅔ + 1 thành viên trong một phân đoạn duy nhất từ ​​bộ đệm đồng thuận 400. Điều này tương đương với 267 trình xác nhận. Cân nhắc các giả định ở trên, 25% tổng số nút là độc hại, xác suất của các nhóm độc hại có siêu đa số trong một phân đoạn là 2,88 * 10 ^ -78 .

Nếu chúng tôi coi việc có 33% tổng số nút mạng là độc hại, thì xác suất có 267 nút độc hại (metachain tiếp quản cuộc tấn công) là 2,84 * 10 ^ -47 . Tương tự, nếu chúng tôi xem xét có 400 nút độc hại bên trong phân đoạn (tấn công toàn diện), trong đó không có nút trung thực nào có thể đưa ra thách thức, thì xác suất thực tế là 0 ( 10 ^ -211 ).

Nếu có ít thành viên độc hại hơn ⅔ + 1, nhưng nhiều hơn số người xác nhận trong một phân đoạn (ít hơn 267, hơn 133), thì phân đoạn sẽ chỉ bị đình trệ, nó sẽ không tạo ra bất kỳ giao dịch nào, vì không có khối nào sẽ có được trạng thái hữu hạn của nó, các nút tốt sẽ không xây dựng trên các khối xấu.

Nếu thậm chí có ít hơn số người xác nhận trong một phân đoạn, chúng ta sẽ gặp tình huống được mô tả và giải thích trong câu hỏi đầu tiên.

Để kết luận, chúng tôi đã chứng minh rằng hệ thống này có thể được bảo đảm an toàn trước các cuộc tấn công chiếm đoạt.

Các cửa hàng chính thức của Elrond :

Elrond Github: https://github.com/ElrondNetwork
Nền tảng cộng đồng Elrond: https://community.elrond.com
Twitter: https://twitter.com/elrondnetwork
Trang web chính thức: https://elrond.com