HỎI ĐÁP VỀ BẢO MẬT ELROND

Vấn đề bảo mật của mạng blockchain là ưu tiên hàng đầu của chúng tôi, do đó chúng tôi sẽ bắt đầu loạt bài viết thảo luận về việc thiết kế mạng blockhain an toàn. Để bắt đầu, bài viết này sẽ trả lời 2 câu hỏi quan trọng mà chúng tôi gặp phải trong quá trình trao đổi vời các nhà phát triển gần đây.

CÂU HỎI: Làm thế nào để hạn chế nhóm các thợ mỏ xấu tạo các khối bằng việc sử dụng các giao dịch

Tôi sẽ bắt đầu giải thích các yêu cầu tối thiểu cho hệ thống của chúng tôi. Trong ngày đầu tiên phát hành mạng lưới chính, giao thức Elrond đã có sự tham gia của ít nhất 800 nốt xác nhận, 400 nốt shard và 400 nốt cho siêu chuỗi (metachain). Chúng tôi đã đặt ra yêu cầu bất kỳ shard nào cũng phải chứa ít nhất 400 nốt xác nhận , nếu không khi shard đó được tạo ra, nó sẽ hợp nhất với shard khác.

Một số điều cần chú ý:

• Giao thức chịu lỗi Byzatine (BFT) yêu cầu ít nhất 75% số nốt là các nốt tốt;
• Xác suất được tính toán với giả định rằng 25% các nốt xấu. Ở cấp độ shard, hệ thống chấp nhận tối đa 33% các nốt xấu. Tính toán được thực hiện với 10 shard, 4000 nốt trong đó có1000 nốt xấu.
• Việc chọn nốt xác nhận ban đầu cho việc phân bổ shard là hoàn toàn ngẫu nhiên, và được chon từ siều chuỗi (metachain). Khi một nốt mới tham gia hệ thống, nó được phân bổ ngẫu nhiên cho hoạt động shard. Nhiều nhất là 30% các nốt sẽ được sắp xếp lại sau mỗi lần lựa chọn.
• Kích thước nhóm đồng thuận trong siêu chuỗi là 400, nốt chính (leader) thay đổi ở mỗi vòng lựa chọn (5 giây), để xác nhận nốt ⅔ + 1 số nốt sẽ phả ký, tức là 267 nốt xác nhận.
• Kích thước nhóm đồng thuận trong shard là 63, và được chọn ngẫu nhiên từ 400 nốt, liên tục thay đổi ở mỗi vòng ⅔* 63 + 1 bằng 43 nốt sẽ ký xác nhận
• Hạt giống ngẫu nhiên (random seed, hàm khởi tạo các bộ sinh số ngẫu nhiên) là một chuỗi hạt giống, không lệch, không thể dự đoán, không thể thay đổi. Nốt chính của khối hiện tại sẽ ký xác nhận hạt giống ngẫu nhiên của khối trước bằng khóa riêng của nó, sử dụng chữ ký đơn BLS, sau đó sẽ được mã hóa bằng hàm băm trở thành hạt giống ngẫu nhiên cho đợt lựa chọn tiếp theo;
• Chữ ký đơn BLS – một tin nhắn đã được ký với khóa riêng và được cố định.
• Hoàn thành khối: khối N được hoàn thành nếu tất cả các khối N-1, N-2,.., N-K được ký. Siêu chuỗi chỉ xác nhận những khối cuối cùng. Ở đây, chúng tôi đã chọn K = 1

Xác suất để đa số các nốt xấu (> 67%) được chọn cho cùng một vòng là 10 ^ -9, ngay cả khi 33% các nút tham gia quá trình sharding là nốt xấu. Trong trường hợp đó, các nốt này có thể đề xuất một khối và ký – giả dụ nốt đó được gọi là BLOCK M, nhưng nó sẽ không được công nhận bởi siêu chuỗi. Siêu chuỗi chỉ xác nhận BLOCK M, chỉ khi BLOCK M + 1 được xây dựng trên nó. Để tạo ra BLOCK M + 1, nhóm các nốt đồng thuận tiếp theo phải đồng ý với BLOCK M. Chỉ nhóm các nốt xấu sẽ đồng ý với BLOCK M, vì vậy nhóm tiếp theo phải có đa số nốt xấu được chọn. Vì hạt giống ngẫu nhiên là hoàn toàn ngẫu nhiên, nên xác suất chọn một nhóm đa số các nốt độc hại là xấp xỉ 10 ^ -9 - chính xác là 5,38 * 10 ^ -10.
Xác suất để tạo ra 2 khối giả liên tiếp bằng mới xác suất lựa chọn 2 nhóm có ít nhất 2/3*63 +1 thừ các nhóm nốt xấu. Xác xuất này là xấp xỉ 10 ^ -18.

Thêm vào đó, 2 nhóm nốt xấu liên tiếp được chọn cần phải thông đồng với nhau, không các khối tạo ra sẽ không được ký xác nhận.

Như vậy là chúng tôi đã chứng minh được là giao thức hết sức an toàn trước các giao dịch không hợp lệ.

CÂU HỎI: Làm thế nào để hạn chế việc thâu tóm các shard? Liệu việc thâu tóm các shard có thể xảy ra?

Giao thức được thiết kế hết thức an toàn và xác suất thâu tóm các shard chỉ ở mức 2.88*10^-78. Bằng việc xây dựng cấu trúc shard như vậy làm cho việc thâu tóm các shard gần như không khả thi.

Giải pháp hạn chế thâu tóm shard:

Giải pháp dự phòng, ngay cả khi không xảy ra. Trạng thái: đã hoàn thành nghiên cứu, 2 giải pháp khả thi được đề xuất và dự kiến sẽ được áp dụng sau khi phát hành testnet lần đầu.

Giải pháp 1:

Khi một khối mới được tạo, nốt chính (leader) sẽ thêm vào bằng chứng rằng đồng tiền tạo ra hoàn toàn có cơ sở. Bằng chứng này sẽ được xác nhận bởi siêu chuỗi (metachain) và mỗi shard điểm đến.

Giải pháp 2:

Khi một nốt chính (leader) đề xuất một khối mới,, nó sẽ thêm vào tiêu đề bằng chứng xác thực merke cho một số tài khoản đã thay đổi số dư của họ trong quá trình tạo khối. Việc lựa chọn các tài khoản này là goàn toàn xác định, ví dụ: lấy tài khoản từ giao dịch đầu tiên trong khối nhỏ và cung cấp bằng chứng đ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 nhóm các nốt xấu, gốc trạng thái (state root) 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ệ liên quan đến cây trạng thái).

Việc cung cấp bằng chứng merkle kết hợp cho một số tài khoản cho phép một nút trung thực có thể thách thức các bằng chứng giả tạo. Các nút trung thực sẽ cung cấp chuỗi các giao dịch, cây merkle rút gọn với tất cả các tài khoản bị ảnh hưởng trước khi áp dụng xem xét các 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ỏ. Ngược lại khối thách bị thức được coi là hợp lệ.

Giá của việc đưa ra một thách thức không hợp lệ là tất cả số tiền được gửi trong nốt đó.

Điều này sẽ cho phép các chuỗi siêu thử và áp dụng các thay đổi vì nó đã biết cây các trạng thái trước đó (chỉ dành cho các tài khoản bị ảnh hưởng) và giúp phát hiện các 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 lại nguyên nhân và nhóm đồng thuận tham gia sẽ bị loại bỏ khỏi siêu chuỗi. Đồng thời, nốt thách thức sẽ được thưởng một phần số tiền bị tịch thu từ các nốt xấu. Chúng ta cần xác định kích thước chuẩn cho 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 ngay cả khi điều này xảy ra, 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 rút gọn chỉ khi có thử thách, nốt thách thức trình bày cả bằng chứng rút gọn khi áp dụng khối không hợp lệ và chính khối của nó.

Tuy nhiên, nhóm nốt xấu có thể ẩn khối khỏi các nút khác - những nhóm nốt tốt. 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 xác nhận bởi siêu chuỗi), 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 tạo lan truyền các khối đã tạo đến các shard lân cận và yêu cầu chũng xác nhận việc tiếp nhận, gửi xác nhận đó đến siêu chuỗi. Trong trường hợp này, chúng tôi có thể có những thách thức từ các shard lân cận, 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 shard 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 khối siêu nhỏ đến các shard lân cận. Các shard chéo luôn được gửi theo các chủ đề khác nhau chỉ có thể truy cập bởi các nút liên quan. Cuối cùng, các thách thức có thể được tạo ra bởi nhiều nốt trung thực.

Một giải pháp khác được đưa dựa trên cách mà thông điệp ngang hàng được thiết lập. Việc liên lạc từ một shard tới siêu chỗii được thực hiện thông qua một tập hợp các chủ đề/kênh được xác định – siêu chuỗi 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 siêu chuỗi chỉ trong trường hợp có thách thức, khả năng rất thấp 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 siêu chuỗi sẽ thực hiện xác minh nhiều bằng chứng như vậy đến từ các shard khác nhau. Chúng chỉ công chứng các khối từ các shard, mà không có thử thách được đưa ra, và đối với những shard khác có thử thách, chúng sẽ được xử lý càng sớm càng tốt, với ưu tiên phục vụ theo thức tự ngay cả các nốt đưa ra các thách thức sai sẽ mất toàn bộ số cổ phần.

Hơn nữa, nếu nhiều thách thức như vậy được xác nhận, siêu chuỗi 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 xấu bị cắt ngay lập tức và 30% tổng số nút được sắp xếp 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 shard nào sẽ làm gián đoạn chặn giao thức trong một thời gian dài và có đủ các nút trong mỗi shard có thể đảm bảo an ninh. Mặt khác, nếu chúng ta chỉ laoij bỏ các nốt xấu một vài lần và không kết thúc mỗi vòng chọ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 shard tổng thể giảm.

Chúng tôi vừa mô tả giải pháp trong trường hợp gần như 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ác nốt độc hại được hình thành bên trong một shard được chọn.

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

Nếu chúng ta coi việc có 33% tổng số nốt xấu, thì xác suất có 267 nút độc hại (tấn công chiếm siêu chuỗi) 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 shard (tấn công toàn diện), trong trường hơp 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ó số nốt xấu ít hơn ⅔ + 1, nhưng nhiều hơn ⅓ số nốt xác nhận trong một shard (ít hơn 267, lớn hơn 133), thì shard 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 hoàn thành, 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í nếu có ít hơn 1/3 số nốt xác nhận trong một shard, chúng ta sẽ trở lại tình huống được mô tả và giải thích trong câu hỏi đầu tiên.

Nói chung, 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 kênh truyền thông của Elrond:

• Elrond Github: https://github.com/ElrondNetwork
• Elrond Community Platform: https://community.elrond.com
• Twitter: https://twitter.com/elrondnetwork
• Official website: www.elrond.com