Đồng sáng lập Fluence: Cách đảm bảo tính bảo mật của cơ sở dữ liệu phân tán

Trước khi máy tính cá nhân ra đời, tài nguyên máy tính được cung cấp bởi một số thiết bị đầu cuối. Các thiết bị đầu cuối này không yêu cầu nhiều phần cứng, miễn là chúng có thể được kết nối với máy chủ, chúng giống như các client nhẹ trong blockchain.

Khi phần cứng sau này trở nên đủ rẻ, tài nguyên máy tính bắt đầu Chuyển sang phía máy khách - phương tiện, trò chơi, gói văn phòng, bộ công cụ khoa học - tất cả đều chạy trên máy tính để bàn. Ngày nay, hầu hết điện toán đã chuyển sang đám mây. Bằng cách kết nối với máy chủ đám mây, trình duyệt hiện đóng vai trò tương tự như thiết bị đầu cuối trước đây, một mô hình có quy mô phù hợp với hàng tỷ người dùng.

Một số lượng lớn máy tính trong nhiều trung tâm dữ liệu tạo thành một đám mây, được kết nối với mạng thông lượng cao, sẵn sàng cung cấp tài nguyên máy tính và yêu cầu dịch vụ bất cứ lúc nào. Đây được gọi là IaaS - Cơ sở hạ tầng như một Dịch vụ. Nhà cung cấp đám mây có trách nhiệm giám sát và sửa chữa cơ sở hạ tầng này để các nhà phát triển có thể tập trung phát triển phần mềm.

Điện toán đám mây không chỉ cơ sở hạ tầng. Trên hết, các nhà cung cấp đám mây triển khai các dịch vụ trung gian: cơ sở dữ liệu, hàng đợi tin nhắn, hàm lambda, công cụ xử lý dữ liệu. Mặc dù các dịch vụ này không tương tác trực tiếp với người dùng cuối nhưng chúng tạo thành một phần quan trọng của kiến trúc phần mềm, thường được gọi là PaaS - Platform as a Service.

Thông thường, ở giữa đám mây Dịch vụ thực chất là một gói phần mềm nguồn mở hiện có được bao gồm trong dịch vụ lưu trữ. Ví dụ: AWS cung cấpRDSNhư Các phiên bản được lưu trữ phổ biến của cơ sở dữ liệu MySQL và PostgreSQL,MSKLà phiên bản được quản lý của Kafka, hàng đợi tin nhắn vàElastiCacheLà phiên bản được quản lý của Redis và Memcached.

Nếu có nhiều thư viện và framework mã nguồn mở khác nhau như vậy thì tại sao phát triển Mọi người sẽ sử dụng dịch vụ đám mây được quản lý chứ? Bởi vì việc sử dụng chúng dễ dàng hơn nhiều so với việc thực hiện tất cả các công việc DevOps thủ công cần thiết. Nhà cung cấp đám mây chịu trách nhiệm cung cấp phần cứng, sắp xếp sao lưu và sao chép, kết nối hệ thống giám sát và cảnh báo cũng như khôi phục dịch vụ nếu có vấn đề phát sinh. Ngoài ra, các dịch vụ lưu trữ tích hợp hoàn hảo với nhau và cho phép người dùng xây dựng các ứng dụng mới một cách đơn giản và nhanh chóng.

Tuy nhiên, sự tiện lợi này giá là các nhà phát triển bị ràng buộc chặt chẽ vào nhà cung cấp đám mây. Càng sử dụng nhiều dịch vụ đám mây, các nhà phát triển càng dễ bị tổn thương bởi các nhà cung cấp đám mây khác nhau.

Giao thức Web 3 có thể giảm Sự phụ thuộc vào người trung gian không quá phức tạp và các nhà phát triển có được trải nghiệm đơn giản và trực quan giống như các nhà cung cấp đám mây truyền thống. Trong trường hợp này, dịch vụ lưu trữ là một thỏa thuận riêng. Ví dụ: các dịch vụ lưu trữ đối tượng như AWS S3 có thể được thay thế bằng Filecoin, Swarm hoặc Arweave, dịch vụ quản lý khóa AWS KMS của NuCypher và dịch vụ truyền phát đa phương tiện AWS Elemental MediaConnect của LivePeer.

Sau đó, phân phối Điều gì có thể một dịch vụ đám mây trông như thế nào?

Giấc mơ đám mây phân tán

Một đám mây phi tập trung hoạt động trên một mạng lưới các nút không đáng tin cậy, trong đó phần mềm hoàn toàn tách biệt khỏi phần cứng cơ bản và bất kỳ ai có tài nguyên đều có thể chạy phần cứng. Các gói phần mềm nguồn mở như Redis, MySQL, Kafka hoặc Spark có thể được chuyển sang các đám mây phân tán và cung cấp các dịch vụ giống như các đám mây truyền thống.

Không cần phải triển khai lại hàng trăm công cụ nguồn mở đã tạo trước đó và Thư viện - Chúng chỉ có thể chạy trên cơ sở hạ tầng phi tập trung. Vì các dịch vụ này sẽ chạy trong một mạng mở nên chúng sẽ có thể tích hợp liền mạch với nhau.

Cuối cùng, khi chạy có vấn đề sẽ được nhiều nhà phát triển cộng đồng giám sát và sửa lỗi hơn là triển khai trên đám mây riêng. Cộng đồng nguồn mở sẽ có thể cộng tác và không chỉ viết mã mà còn chạy mã đó.

Tại sao ý tưởng này không' t chưa trở thành hiện thực à? Để trả lời câu hỏi này, chúng ta cần xem xét nền tảng của đám mây là gì. Mặc dù đám mây có thể bao gồm một số lượng lớn các dịch vụ và giao thức khác nhau nhưng về nền tảng, bạn chỉ có thể tìm thấy một số thành phần chính: điện toán, lưu trữ dữ liệu và kết nối mạng.

Việc lưu trữ dữ liệu phi tập trung dường như Một vấn đề gần như đã được giải quyết: Filecoin, Swarm và Arweave có thể đảm bảo tính khả dụng và độ bền của dữ liệu, đồng thời có khả năng rẻ hơn và mạnh hơn so với lưu trữ đám mây truyền thống.

Yêu cầu phân cấp tính toán Nhiều hơn nữa khó khăn, nhưng có một số cách khác nhau để chạy chương trình Turing-complete tùy ý:

Máy khách dày (còn được gọi là nút đầy đủ): Máy khách có tất cả dữ liệu cần thiết để chạy chương trình và thực hiện các phép tính cục bộ, về cơ bản tạo nên nút Đầy đủ của máy khách. Bản thân dữ liệu có thể được tải xuống từ bộ lưu trữ phi tập trung hoặc được lấy từ các nút mạng khác.

Mặc dù đơn giản nhưng cái này Cách tiếp cận không phải lúc nào cũng phù hợp với mô hình hiện tại, nơi các máy chủ gánh phần lớn khối lượng công việc và thông lượng mạng giữa máy khách và máy chủ bị hạn chế.

Bằng chứng không có kiến thức: nút đầy đủ có thể thực thi chương trình cục bộ , sau đó Cung cấp bằng chứng cho khách hàng rằng phép tính đã được thực hiện chính xác. Lý tưởng nhất là khách hàng nên dành rất ít tài nguyên để xác minh bằng chứng được cung cấp và chi phí chuẩn bị bằng chứng đó trên toàn bộ phía nút sẽ không đáng kể.

Thật không may, hiện tại, máy tính một bằng chứng không có kiến thức có thể yêu cầu nhiều tài nguyên hơn là thực hiện việc tính toán. Vì vậy, rất khó sử dụng phương pháp này để tính toán ở quy mô lớn.

Máy khách mỏng + Kerr mặc định Bằng chứng: Đối với bất kỳ cấu trúc dữ liệu dựa trên con trỏ nào, bằng chứng Merkle có thể được xây dựng để truy xuất một phần dữ liệu mà nó lưu trữ. Khách hàng chỉ có thể tải xuống những phần dữ liệu mà họ quan tâm từ mạng phi tập trung, xác minh rằng việc truy xuất là chính xác, thực hiện tính toán và tải kết quả lên mạng. Bằng cách này, mức tiêu thụ băng thông được giữ ở mức thấp và tài nguyên máy khách được sử dụng cẩn thận.

Ví dụ: đây là OrbitDB Một cách tiếp cận đã được sử dụng — cơ sở dữ liệu không có máy chủ để lưu trữ dữ liệu trong IPFS và sử dụng CRDT để đồng bộ hóa giữa các máy khách khác nhau — OrbitDB cho phép các nhà phát triển làm việc với các cấu trúc dữ liệu khá phức tạp: ngoài các kho lưu trữ khóa-giá trị. Ngoài ra, nó còn hỗ trợ các nhật ký có thể thay đổi và bất biến, bộ đếm và thậm chí cả chức năng tìm kiếm.  

Tuy nhiên, đối với Đối với nhiều trường hợp sử dụng, không thể sử dụng phương pháp này. Ví dụ: để xử lý các truy vấn tổng hợp đặc biệt hoặc các hoạt động nối, về cơ bản, máy khách cần phải là một nút đầy đủ, vì các loại truy vấn như vậy thường yêu cầu đọc một số lượng lớn các hàng từ một hoặc nhiều bảng, cần được chuyển đến máy khách. .

Thin client + khu vực Blockchain : Cuối cùng, các phép tính có thể được chạy trên một blockchain, trong đó nhiều nút chạy cùng một chương trình và xác minh lẫn nhau. Càng có nhiều nút chạy cùng một tính toán thì hệ thống càng trở nên an toàn hơn. Điều này là do xác suất phần lớn các nút làm điều xấu sẽ giảm khi số lượng nút tăng lên.

Trong Ethereum, số lượng nút có thể lên tới hàng nghìn, điều này khiến Ethereum là một hệ thống rất an toàn nhưng ít hiệu quả hơn so với đám mây. Phân mảnh chuỗi khối có thể giảm đáng kể số lượng nút cần thiết để chạy cùng một phép tính, nhưng mức giảm này có đủ để đạt được hiệu quả chi phí ở quy mô đám mây không?

Chúng ta cũng nên chú ý theo cách tiếp cận bằng chứng máy khách mỏng + Merkle (cũng như cách tiếp cận máy khách dày), các bên sẵn sàng sử dụng kết quả tính toán cần phải tin cậy bên thực hiện tính toán. Về cơ bản, kết quả tính toán từ một nhà tiên tri: Merkel đã chứng minh không thể ngăn chặn một khách hàng độc hại đã tải xuống 5 trong một khối và 3 trong một khối khác, sau đó tải 6 trở lại bộ lưu trữ phi tập trung dưới dạng tổng. Điều này có nghĩa là chỉ có bằng chứng không có kiến thức và phương pháp tiếp cận client-blockchain mới có thể cung cấp đủ khả năng kết hợp trong một môi trường không tin cậy.

Khoảng cách giữa các cơ sở dữ liệu phân tán

Hãy quay lại thực tế và xem xét một loại dịch vụ cơ sở dữ liệu được quản lý phần mềm trung gian đám mây đặc biệt nhưng rất hữu ích. Ngoài việc là một mô hình tuyệt vời để kết hợp tính toán và lưu trữ, cơ sở dữ liệu còn là một trong những dịch vụ đám mây được sử dụng phổ biến nhất - hầu hết mọi chương trình đều sử dụng cơ sở dữ liệu SQL hoặc NoSQL.

Điều đáng chú ý là , Chúng tôi chưa thấy phiên bản phi tập trung của AWS RDS (cung cấp MySQL và PostgreSQL được lưu trữ) hoặc AWS Elasticache (cung cấp Redis và Memcached được lưu trữ).

Tại sao lại như vậy? Lý do là cơ sở dữ liệu không chỉ có chức năng lưu trữ mà còn có chức năng tính toán. Ngoài các truy vấn tổng hợp và các thao tác nối đã được đề cập trong bài viết này, cơ sở dữ liệu có thể chạy các thủ tục được lưu trữ và tập lệnh người dùng, thực hiện cập nhật dữ liệu hàng loạt và áp dụng các hàm dựng sẵn và do người dùng xác định.

Kết hợp với các yêu cầu xử lý yêu cầu nhanh chóng và lưu trữ lượng lớn dữ liệu, việc chuyển cơ sở dữ liệu nguồn mở sang môi trường phân tán trở nên rất khó khăn. Cách tiếp cận sharding có vẻ là thực tế nhất, nhưng trước khi chúng ta bắt đầu đi theo con đường này, hãy phân tích xem cơ sở dữ liệu đám mây dự phòng thường có bao nhiêu dự phòng.

Dự phòng trong môi trường đám mây

Đầu tiên, cơ sở dữ liệu đám mây thường sử dụng nhiều bản sao để đạt được độ sẵn sàng cao và trong một số trường hợp, tăng thông lượng đọc. Thông thường, một trong những bản sao này được chỉ định làm bản sao chính và phục vụ tất cả các yêu cầu đọc và ghi, trong khi các bản sao khác đóng vai trò là bản dự phòng: nếu bản sao chính bị lỗi, một trong các bản sao dự phòng sẽ thay thế nó. Ngoài ra, mặc dù cơ sở dữ liệu dự phòng không phục vụ yêu cầu ghi nhưng chúng vẫn có thể phản hồi các truy vấn chỉ đọc, cho phép chúng song song hóa một số khối lượng công việc nhất định.

Các yếu tố sao chép thường gặp là gì đã sử dụng ? Nó phụ thuộc vào loại khối lượng công việc, nhưng đối với bản sao AWS RDS 2× (một bản sao chính và một bản sao dự phòng) thường được sử dụng để xử lý giao dịch trực tuyến và có thể làm tăng sự kết hợp giữa xử lý giao dịch và truy vấn phân tích. Việc triển khai Cassandra, một cơ sở dữ liệu NoSQL phân tán phổ biến, có thể cung cấp khả năng sao chép dữ liệu quan trọng gấp 3 lần cho cả bản sao tiêu chuẩn và bản sao 5x. Nói chung, có vẻ như mức độ dư thừa từ 2× đến 5× là phổ biến.

Thứ hai, ngoài việc sao chép cơ sở dữ liệu, người ta thường sử dụng các bản sao lưu. Trong trường hợp này, ảnh chụp nhanh trạng thái cơ sở dữ liệu được chụp định kỳ và tải lên dịch vụ lưu trữ bên ngoài như AWS S3. Nếu ảnh chụp nhanh được chụp hàng ngày, bộ nhớ ngoài có thể giữ lại các ảnh chụp nhanh của tuần trước.

Ở đây chúng ta cũng cần lưu ý rằng bộ nhớ ngoài rất có thể cũng sẽ có một số phần dư thừa. Mặc dù không có con số chính xác về số lượng bản sao của từng đối tượng lưu trữ mà AWS S3 có, dựa trên mức đảm bảo độ bền 99,999999999%, chúng tôi có thể suy đoán rằng thường có ít nhất ba thiết bị khác nhau chứa cùng một dữ liệu.

Nếu bản sao đã có tại chỗ, Tại sao lại sao lưu? Một trong những lý do quan trọng nhất là việc sao lưu cho phép khôi phục trạng thái cơ sở dữ liệu tại một thời điểm cụ thể. Điều này có thể hữu ích, ví dụ: nếu ai đó vô tình đưa ra lệnh DROP TABLE và sau đó lặp lại lệnh đó trong tất cả các bản sao đang giữ bảng này. Với sự trợ giúp của nhật ký hoàn tác riêng biệt, lệnh như vậy không thể dễ dàng khôi phục - nhưng việc sử dụng ảnh chụp nhanh mới nhất có thể khôi phục ít nhất một số dữ liệu được lưu trữ.

Tóm lại, những gì chúng tôi giả sử Độ dư thừa cần thiết cho cơ sở dữ liệu đám mây là hệ số sao chép gấp 2 đến 5 lần của bản sao chính/dự phòng cộng với một số ảnh chụp nhanh cơ sở dữ liệu được sao chép gấp 3 lần bộ lưu trữ bên ngoài. Chúng ta có thể lặp lại điều này với một chuỗi khối được phân chia không? Để đơn giản, bây giờ chúng ta hãy tạm quên các giao dịch giữa các phân đoạn - nhiều ứng dụng web chỉ sử dụng một phiên bản cơ sở dữ liệu.

Ngân sách danh mục

Giả sử chúng ta đã phân bổ ngân sách cho mức dự phòng chỉ từ 5x đến 10x. Chúng ta có thể làm điều này bằng cách khởi chạy trình xác thực dựa trên sự đồng thuận Byzantine chỉ với 7 trình xác thực, mỗi trình xác thực có một bản sao cơ sở dữ liệu không? Thật không may, điều đó không đơn giản như vậy - việc phân chia như vậy kém an toàn hơn.

An toàn cho đoạn mồ côi

Giả sử rằng một phần nhỏ các nút p trong mạng là độc hại. Nhiều công cụ đồng thuận Byzantine (ví dụ: Tendermint) có thể chấp nhận k nút độc hại trong phân đoạn bao gồm n = 3k + 1 nút. Ngược lại, chúng ta có thể nghĩ rằng nếu n - k (tức là 2n/3) hoặc nhiều nút hơn trong một phân đoạn là độc hại thì chúng hoàn toàn có thể chiếm lấy phân đoạn đó và "dung túng" các nút trung thực. Giả sử rằng các nút trong phân đoạn được lấy mẫu ngẫu nhiên từ mạng, xác suất phân đoạn đó tiếp quản là:

Đối với một phân đoạn mô hình có 7 nút, chỉ cần 5 nút độc hại để bắt được nó. Chúng tôi giả định rằng tỷ lệ các nút độc hại trong mạng là 10%. Bằng cách thay thế các giá trị này vào công thức trên, chúng ta nhận được rằng xác suất để một đoạn tiếp quản là khoảng 0,017%. Ngay cả đối với các ứng dụng tạm thời không có yêu cầu bảo mật nghiêm ngặt, con số này có thể quá cao.

Chúng ta làm cách nào để ngăn chặn điều này Tình trạng? Trong một số thiết kế, nếu các nút trung thực chiếm ⅔ đa số trong phân đoạn, chúng có thể cắt giảm tiền gửi của các nút đã ký kết khi chuyển đổi trạng thái không chính xác. Nhưng trong trường hợp của chúng tôi, các nút độc hại có thể thực hiện bất kỳ chuyển đổi trạng thái nào chúng muốn mà không cần trao đổi với các nút trung thực.

Hơn nữa, vì các nút độc hại được kết nối chặt chẽ nên chúng chỉ có thể phối hợp và hoạt động sai nếu chúng chiếm ⅔ đa số trong phân đoạn - về cơ bản, khi một nút độc hại ở đó không chấp nhận rủi ro. Điều này có nghĩa là nếu không có sự giám sát từ bên ngoài, client tối thiểu có thể không bao giờ biết rằng phân đoạn đó là không trung thực.

Bảo vệ sự phân mảnh bằng cách sử dụng nhóm trình xác thực được chia sẻ

Để bảo vệ các phân đoạn, cho dù chúng chỉ có một vài nút hay hàng trăm nút, hai kỹ thuật thường được sử dụng: xoay trình xác nhận và nút đánh cá. Về cơ bản, các kỹ thuật này rất giống nhau: một số nút trong mạng xác minh rằng phân đoạn chỉ thực hiện chuyển đổi trạng thái chính xác. Nếu trình xác thực phát hiện ra sự chuyển đổi trạng thái sai, nó có thể thách thức tình huống này. Trong trường hợp này, nếu nút xác thực có thể chứng minh rằng bản cập nhật trạng thái không chính xác thì nút đã phê duyệt chuyển đổi không chính xác sẽ mất khoản tiền gửi.

Một tùy chọn là để xác thực Nút thay thế một nút khác trong phân đoạn (trong trường hợp này, chúng tôi nói rằng bộ trình xác thực đã được xoay vòng) và phát lại một số giao dịch cuối cùng được thực hiện bởi phân đoạn đó. Một lựa chọn khác để xác thực các nút là duy trì sự độc lập và đánh bắt những chuyển đổi trạng thái không chính xác sang các phân đoạn khác nhau với hy vọng được khen thưởng. Bất kể phương pháp nào được sử dụng, ý tưởng vẫn giống nhau: một phân đoạn được bảo vệ không chỉ bởi các nút thuộc về nó mà còn bởi toàn bộ mạng.

Nghe hay đấy chứ? Nhưng làm cách nào để chuyển lịch sử giao dịch phân đoạn sang các nút xác thực hoặc ngư dân mới tham gia? Một vấn đề là nếu số lượng nút trong phân đoạn nhỏ thì việc chuyển lịch sử và trạng thái có thể đặt quá nhiều tải lên phân đoạn, cản trở khả năng xử lý giao dịch của phân đoạn trong thời gian thực. Một vấn đề khác là nút độc hại trong phân đoạn bị bắt có thể từ chối chia sẻ bằng chứng buộc tội.

Sự cứu rỗi của lưu trữ phi tập trung

Một giải pháp là lưu trữ lịch sử giao dịch của phân đoạn Ghi âm bên ngoài. Hãy xem xét những điều sau: Bất cứ khi nào phân đoạn xử lý một khối, nó có thể tải khối đó lên mạng lưu trữ phi tập trung và cung cấp cho khách hàng quan tâm bằng chứng rằng khối thực sự đã được tải lên và tải lên chính xác. Sau khi một đoạn được tải lên, mạng lưu trữ phi tập trung chịu trách nhiệm phục vụ dữ liệu được lưu trữ khi được yêu cầu. Hãy xem bài viết Swarm này để tìm hiểu thêm về cách giao thức thực hiện nhiệm vụ này.

Ngư dân giờ đây có thể tải xuống các phần lịch sử giao dịch khác nhau từ bộ lưu trữ phi tập trung, lặp lại các phép tính và thách thức các chuyển đổi trạng thái không chính xác. Như một tác dụng phụ, ngư dân sẽ tính toán trạng thái mới, sau đó họ có thể tải trạng thái này lên bộ lưu trữ phi tập trung dưới dạng ảnh chụp nhanh. Sau đó, ảnh chụp nhanh này có thể được sử dụng làm điểm bắt đầu để xác minh thêm hoặc làm bản sao lưu trong trường hợp toàn bộ phân đoạn bị lỗi.

Có thể triển khai xoay trình xác thực theo cách tương tự: trình xác thực mới sẽ tải xuống các phần bắt buộc của trạng thái và lịch sử giao dịch từ bộ lưu trữ phi tập trung mà không làm phân đoạn bị quá tải. Ngoài ra, ngay cả khi toàn bộ phân đoạn bị lỗi, nó vẫn có thể được khôi phục bằng cách sử dụng dữ liệu từ bộ lưu trữ phi tập trung làm bản sao lưu.

Xin lưu ý rằng do Điều này Các ngư dân trong thiết kế bị ngắt kết nối với các mảnh vỡ, do đó việc lựa chọn ngư dân hoàn toàn ngẫu nhiên. Bằng cách này, khi một phân đoạn đang xử lý một giao dịch, nó sẽ không biết liệu nó sẽ được xác minh bởi một ngư dân trung thực hay độc hại, điều này gây áp lực đáng kể lên các nút phân đoạn để hành động trung thực. Chúng tôi cũng sẽ đưa ra một gợi ý ở đây (được đề cập trong bài sau) để ngăn cản ngư dân biết liệu phán quyết của họ có được xác minh lại hay không.

Trò chơi xác minh và sự "đồng thuận" nhất quán

Trước đây, chúng tôi đã đề cập rằng việc xác thực các nút có thể chứng minh trạng thái Chuyển đổi không chính xác. Có thể làm điều này một cách hiệu quả về mặt chi phí? Câu trả lời là "có": một cách là sử dụng trò chơi xác minh kiểu TrueBit: nếu hai nút không đồng ý về cách giao dịch sẽ cập nhật trạng thái, thì có thể tìm thấy quá trình xử lý một lệnh máy ảo mà không cần đồng ý. Sau khi tìm thấy một hướng dẫn như vậy, một thẩm phán bên ngoài, đáng tin cậy (ví dụ: Ethereum) có thể được yêu cầu lặp lại hướng dẫn đó để tìm ra cách chính xác về cách xử lý hướng dẫn.

Lưu ý rằng trong trường hợp này chỉ một phần nhỏ tính toán được xử lý trên chuỗi, do đó phán đoán không bị quá tải. Hơn nữa, các hướng dẫn được đặt câu hỏi có thể được tìm thấy bằng cách tranh chấp các nút với sự trợ giúp của tìm kiếm n-ary - nghĩa là không cần nhiều chi phí tính toán.

Xin lưu ý rằng trò chơi phải được xác minh Cơ chế chỉ yêu cầu một nút trung thực để phát hiện hành vi nguy hiểm. Nói cách khác, các nút phân đoạn và ngư dân phải đạt được "sự đồng thuận" nhất trí về cách tiến hành chuyển đổi trạng thái.

Hãy cùng tìm hiểu chính xác The xác suất hành vi độc hại không được chú ý. Giả sử rằng ngoài phân đoạn bao gồm n nút, chúng ta còn có m ngư dân xác nhận độc lập phân đoạn này. Hành vi độc hại sẽ chỉ bị phát hiện nếu mảnh bị chiếm đoạt và tất cả ngư dân đều có ác ý:

Nếu chúng ta đặt 4 nút trong phân đoạn và 3 tài nguyên tính toán ngân sách được chia cho các nút ngư dân và giữ lại. Chúng tôi giả định rằng 10% nút trong mạng là độc hại, xác suất bỏ qua hành vi xấu trở thành 0,00037%. Xác suất này thấp hơn hai bậc so với mô hình ngây thơ trước đây của chúng tôi!

Nền kinh tế của hành vi độc hại

Khả năng này còn giảm hơn nữa nếu các nút phân đoạn không thể phối hợp với các nút câu cá. Hãy tưởng tượng rằng một số nút độc hại có thể chiếm lấy một phân đoạn. Chúng tôi cũng giả định rằng các nút này đã gộp 1.000 USD trên mạng. Cuối cùng, chúng ta hãy giả sử rằng các nút phân đoạn là hợp lý và chỉ thực hiện chuyển đổi trạng thái sai lầm khi lợi ích của chúng lớn hơn tổn thất.

Nếu ba ngư dân nút Khi sự phân mảnh sau đó được xác minh, xác suất một nút độc hại bị bắt và mất đi sự quan tâm là 1-0,13 = 99,9%. Bây giờ, hãy tính xem cần có bao nhiêu nút phân đoạn độc hại trước khi hành vi của chúng mang lại lợi nhuận về mặt tài chính.

Nếu chúng ta cho rằng chúng là chỉ kiếm lợi nhuận khi hành động của họ bị bỏ qua và lịch sử giao dịch của mảnh vỡ không được phục hồi, thì 999 trên 1000 mảnh họ sẽ mất 1.000 đô la tiền cổ phần của mình và không kiếm được gì. Trong 1 trong số 1000 trường hợp, họ sẽ nhận được $x, số tiền này sẽ bù đắp cho bất kỳ khoản cược nào họ thua. Giải phương trình đơn giản này, chúng tôi biết rằng một nút phân đoạn độc hại sẽ cần thu được ít nhất 999.000 USD để hòa vốn. Nói cách khác, khối lượng giao dịch của mảnh vỡ sẽ phải hơn một triệu đô la thì cuộc tấn công mới có ý nghĩa!

Điều này nghe có vẻ hay Thật đáng kinh ngạc, chúng tôi đồng ý: mô hình kinh tế của hành vi độc hại trong các hệ thống kết hợp phức tạp hơn nhiều. Thật không may, trong khi các nút phân đoạn không biết trước về ngư dân và do đó không thể bắt đầu cuộc trò chuyện sớm, một số ngư dân kém trung thực hơn có thể liên hệ với các nút phân đoạn nếu họ phát hiện hành vi không đúng. Sau đó, những ngư dân này có thể yêu cầu một khoản phí từ các nút phân mảnh đó để giữ im lặng. Chúng tôi sẽ xem xét các chi tiết kinh tế của cuộc tấn công này và các cuộc tấn công khác trong các bài đăng tiếp theo.

Đặt tất cả lại với nhau

Fluence Labs đang nỗ lực đưa đám mây phi tập trung đến gần hơn với thực tế bằng cách kết hợp cách tiếp cận chuỗi khối phân mảnh với mạng lưu trữ phi tập trung, các đánh giá đáng tin cậy và mô hình máy khách-máy chủ cổ điển để triển khai mạng cơ sở dữ liệu phi tập trung. đám mây truyền thống.

Fluence là một giải pháp kết hợp lược đồ, chúng tôi đã đề cập đến các khía cạnh khác nhau trước đó trong bài viết này. Mạng Fluence được chia thành các phân đoạn rất nhỏ, mỗi phân đoạn chịu trách nhiệm về một cơ sở dữ liệu độc lập. Các phân đoạn này tải các giao dịch lên bộ lưu trữ phi tập trung và sau đó một nhóm ngư dân dùng chung sẽ xác minh lịch sử giao dịch đã tải lên. Quá trình xác thực này được thực hiện không đồng bộ với quá trình xử lý giao dịch, cho phép độ trễ dịch vụ yêu cầu duy trì ở mức thấp và trải nghiệm người dùng mượt mà.

Thành phần phân đoạn trong mạng Fluence không thay đổi thường xuyên, điều này tránh truyền dữ liệu quá mức khi người xác thực mới tham gia phân đoạn. Thay vào đó, ngư dân được luân chuyển liên tục, điều này giúp tăng cường an ninh mạng tổng thể. Nếu bất kỳ nút nào không đồng ý về cách xử lý giao dịch, tranh chấp sẽ được bắt đầu trên chuỗi khối Ethereum và được giải quyết thông qua cơ chế trò chơi xác minh.

WebAssembly được sử dụng làm Máy ảo mục tiêu, kết hợp với hiệu quả chi phí, cho phép chuyển nhiều cơ sở dữ liệu nguồn mở được viết tốt sang mạng Fluence. Trên thực tế, chúng tôi vừa chuyển Redis và hiện đang tìm cách chuyển cơ sở dữ liệu SQL cấp sản xuất (đã có sản phẩm - LlamaDB), chẳng hạn như SQLite.

Chúng tôi cũng nên lưu ý rằng việc xác thực trì hoãn trong kiến trúc của chúng tôi Cho phép Fluence thực hiện thực hiện các giao dịch cơ sở dữ liệu chéo hiệu quả và an toàn, nhưng đó là chủ đề cho bài viết tiếp theo cũng như một số chi tiết cụ thể về kiến trúc của Fluence.

Nguồn: https://medium.com/fluence-network/securing-decentralized-databases-part-i-6736d2a4b2f4

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia