Thực hiện song song nghiên cứu hệ thống blockchain

Người viết: PREDA; Biên soạn bởi: ChainFeeds Research

Nội dung và mục đích của bài viết này

Việc thiết kế các mô hình thực thi song song, cho dù trong lĩnh vực cơ sở dữ liệu truyền thống hay trong blockchain công nghệ phức tạp hơn. Điều này là do nhiều chiều cần được xem xét trong quá trình thiết kế và việc lựa chọn từng chiều sẽ có tác động sâu sắc đến hiệu suất tổng thể và khả năng mở rộng của hệ thống. Bài viết này sẽ xem xét sâu hơn về một số kiến ​​trúc song song của lớp thực thi blockchain tiêu biểu nhất và trình bày chi tiết các kết quả thử nghiệm mà chúng tôi đã tiến hành về hiệu suất và khả năng mở rộng của các kiến ​​trúc này.

Từ một khía cạnh, lĩnh vực blockchain đã không ngừng theo đuổi hiệu suất cao và khả năng mở rộng cao của chuỗi. Ngay cả sau khi xuất hiện các hệ thống đa chuỗi và hệ thống Layer2, khả năng thực thi của từng hợp đồng thông minh vẫn bị hạn chế bởi khả năng của một máy ảo duy nhất VM. Với sự xuất hiện của các máy ảo song song (Parallel VM), hạn chế này đã bị phá bỏ. Các máy ảo song song cho phép các giao dịch của một hợp đồng thông minh được thực hiện đồng thời trên nhiều EVM/VM, từ đó sử dụng nhiều lõi CPU hơn để cải thiện hiệu suất.

Chúng tôi tin rằng trong số nhiều hệ thống blockchain hiệu suất cao hỗ trợ song song VM, Sei (V2), Aptos, Sui, Crystality và PREDA Tiêu biểu nhất, mỗi hệ thống đều có những ưu điểm riêng về thiết kế.

Ở phần đầu của bài viết này, chúng tôi trình bày tập hợp kết quả thử nghiệm đầu tiên. Biểu đồ bên dưới hiển thị giá trị tuyệt đối của giao dịch mỗi giây (TPS) đối với Sei, Aptos, Sui, Crystality và PREDA khi thực hiện cùng một hợp đồng thông minh ERC20 trên máy 128 lõi. Từ tập hợp kết quả thử nghiệm này, mô hình PREDA có lợi thế đáng kể trong việc so sánh TPS và khả năng mở rộng của năm hệ thống thực thi song song.

Chúng tôi sẽ mở rộng chi tiết về dữ liệu thử nghiệm và phân tích khác sau.

Trước tiên, chúng tôi so sánh các giá trị TPS, tức là thông lượng, của năm hệ thống. Khối lượng giao dịch được sử dụng trong các thử nghiệm so sánh TPS được thực hiện trên các chuỗi khác nhau là như nhau.

Vì các ngôn ngữ lập trình và máy ảo cơ bản khác nhau được sử dụng trong các hệ thống khác nhau nên một so sánh thông lượng đơn lẻ không thể giải thích đầy đủ những ưu điểm và nhược điểm của hệ thống. Chúng tôi cũng so sánh các kết quả tăng tốc tương đối, cụ thể là Tỷ lệ tăng tốc. , đó là Hiệu ứng tăng tốc của việc thực hiện cùng một số lượng giao dịch trên nhiều VM so với một VM. Trong Sui, Aptos, Crystality và PREDA, mỗi luồng được gán một lõi CPU chuyên dụng.

Để biết tất cả dữ liệu thử nghiệm chi tiết, bao gồm giá trị TPS tuyệt đối và tỷ lệ tăng tốc, vui lòng tham khảo Báo cáo thử nghiệm đầy đủ .

Bảng sau đây trình bày các nguồn dữ liệu, quy trình thực hiện và phương pháp đánh giá được sử dụng trong thử nghiệm.

Tổng quan về các mô hình thực thi song song

Dự án Aptos và Sui đều bắt nguồn từ dự án blockchain thất bại Diem of Meta (trước đây gọi là Facebook). Cả hai dự án đều được thành lập bởi các cựu kỹ sư Meta - Aptos của Avery Ching và Sui của Sam Blackshear. Các lộ trình kỹ thuật mà cả hai đi theo là khác nhau. Aptos tuân thủ nghiêm ngặt ngôn ngữ lập trình Move ban đầu được phát triển cho Diễm, nhưng Tùy đã thực hiện rất nhiều sửa đổi đối với Move.

Tiếp theo, chúng ta sẽ khám phá sự khác biệt giữa mô hình song song hóa của Aptos và Sui, phân tích cách các phương pháp tiếp cận khác nhau tác động đến hiệu suất và nêu bật những lợi thế tương ứng của chúng.

Aptos: Lớp 1 hiệu suất cao sử dụng song song tối ưu

Aptos là Lớp 1 triển khai thực thi song song các hợp đồng thông minh thông qua cơ chế song song tối ưu, từ đó cải thiện hiệu suất cao. Cụ thể trong song song hóa lạc quan, các giao dịch ban đầu được giả định là không có xung đột trạng thái và được thực hiện song song. Sau khi thực hiện, hệ thống sẽ kiểm tra các xung đột và giải quyết chúng bằng cách thực hiện lại các giao dịch xung đột thông qua khôi phục và thực hiện nối tiếp hoặc thông qua lập kế hoạch khác. Phương pháp thực hiện suy đoán này tối đa hóa lợi ích của việc thực hiện song song bằng cách giả định rằng hầu hết các giao dịch sẽ không xung đột, đồng thời cung cấp cơ chế dự phòng để xử lý xung đột.

Ưu điểm của song song hóa lạc quan: (1) Không cần sửa đổi chương trình: nó có thể được triển khai dễ dàng mà không cần thay đổi mã hiện có. (2) Hiệu quả trong các tình huống mà xung đột chỉ chiếm tỷ lệ thấp đến trung bình: bằng cách cho phép nhiều giao dịch tiến hành đồng thời và xử lý xung đột khi chúng phát sinh, tối đa hóa thông lượng, trong nhiều tình huống trong thế giới thực, xung đột là tương đối hiếm.

Aptos sử dụng ngôn ngữ lập trình MOVE để phát triển hợp đồng thông minh và sử dụng máy ảo Aptos MOVE trong triển khai hệ thống.

Sui: Lớp 1 hiệu suất cao với sự song song bi quan

Sui áp dụng chiến lược song song bi quan. Trong song song bi quan, hệ thống sẽ kiểm tra trước các giao dịch về khả năng tranh chấp tài nguyên trước khi thực hiện. Lập trình viên cần chỉ định các tài nguyên (tức là trạng thái) mà mỗi giao dịch cần truy cập. Hệ thống kiểm tra trước từng giao dịch nhận được để phát hiện các xung đột tiềm ẩn. Chỉ các giao dịch không liên quan đến tranh chấp tài nguyên với các giao dịch hiện đang thực hiện mới được gửi đến công cụ thực thi để thực hiện song song.

Ưu điểm của song song bi quan: (1) Tránh khôi phục: Bằng cách xác định và tránh xung đột trước khi thực thi, phương pháp này giảm thiểu nhu cầu khôi phục và thực thi lại, dẫn đến hiệu suất dễ dự đoán hơn. (2) Hiệu quả trong các tình huống xung đột cao: Nó rất hiệu quả trong môi trường xung đột cao, đảm bảo rằng chỉ các giao dịch không xung đột mới được thực hiện song song, giảm chi phí do giải quyết xung đột.

Sui cũng sử dụng ngôn ngữ lập trình MOVE, nhưng có phần mở rộng Sui MOVE riêng và sử dụng máy ảo Sui MOVE trong quá trình triển khai hệ thống.

Sei: Sự song song lạc quan tương thích với Solidity và EVM

Khi Sei lần đầu tiên ra mắt chuỗi công khai, nó được định vị là một chuỗi ứng dụng giao dịch được xây dựng trên Cosmos SDK. đến chuỗi EVM song song đầu tiên. Ở cấp độ thực thi song song, Sei áp dụng cách tiếp cận tương tự như mô hình Aptos mà chúng tôi gọi là song song hóa lạc quan.

Tính song song lạc quan được Sei (V2) áp dụng độc đáo ở chỗ nó sử dụng ngôn ngữ lập trình Solidity và Máy ảo Ethereum (EVM) tiêu chuẩn để đảm bảo khả năng tương thích EVM và Solidity.

Crystality và PREDA: Kiến trúc thực thi chuyển tiếp song song

Cả Crystalality và PREDA đều hỗ trợ Kiến trúc phân tán thực thi chuyển tiếp song song. PREDA được thiết kế đặc biệt cho các hợp đồng thông minh có mục đích chung song song trong kiến ​​trúc chuỗi khối đa EVM. Mối quan hệ giữa cả hai là Crystality là ngôn ngữ lập trình cho EVM/GPU song song dựa trên mô hình PREDA. Từ góc độ hệ thống, PREDA lần đầu tiên trong lĩnh vực blockchain có thể song song hóa hoàn toàn các chức năng hợp đồng, do đó tối đa hóa tính đồng thời của một tập hợp giao dịch. Điều này đảm bảo việc sử dụng hiệu quả tất cả các phiên bản EVM, mang lại hiệu suất và khả năng mở rộng tối ưu cho một cấu hình phần cứng nhất định.

Khác với việc thực thi tuần tự Solidity và Move cũng như thiết kế kiến ​​trúc của Mọi thứ được chia sẻ, mô hình PREDA lần đầu tiên áp dụng kiến ​​trúc Không chia sẻ để phá vỡ sự phụ thuộc trạng thái trong thực thi song song và đảm bảo rằng EVM khác nhau các phiên bản sẽ không bao giờ truy cập vào cùng một phần trạng thái hợp đồng, do đó gần như tránh được hoàn toàn xung đột ghi.

Trong PREDA, các chức năng hợp đồng được phân tách thành nhiều bước có thứ tự, mỗi bước dựa trên một phần trạng thái có thể song song hóa và không xung đột. Các giao dịch do người dùng thực hiện trước tiên sẽ được gửi đến EVM chứa trạng thái địa chỉ của người dùng. Trong quá trình thực hiện giao dịch, luồng thực thi có thể được chuyển từ một EVM giữ trạng thái hợp đồng cần thiết cho quản lý hiện tại sang EVM khác bằng cách phát hành giao dịch chuyển tiếp,để nhận ra rằng dữ liệu không di chuyển và luồng thực thi đang ở trạng thái EVM theo sự phụ thuộc dữ liệu di chuyển giữa.

Dữ liệu thử nghiệm của năm hợp đồng đại diện

Trong đánh giá của mình, chúng tôi đã thử nghiệm năm hợp đồng thông minh được sử dụng rộng rãi - ETH TokenTransfer, Voting, Airdrop, CryptoKitties và MillionPixel và MyToken ( ERC20). Các hợp đồng này được thực hiện trên các hệ thống blockchain khác nhau bao gồm Sei, Aptos, Sui, Crystality và PREDA. Chúng tôi đã tiến hành các thử nghiệm chi tiết để so sánh hiệu suất của các hệ thống thực thi song song khác nhau, tập trung vào giao dịch mỗi giây (TPS) và tốc độ tăng tốc, đo lường hiệu suất khi thực thi trên nhiều VM so với một VM duy nhất cho mỗi hệ thống.

Để biết tất cả dữ liệu thử nghiệm chi tiết, bao gồm giá trị TPS tuyệt đối và tỷ lệ tăng tốc, vui lòng tham khảo Báo cáo thử nghiệm đầy đủ .

1. Hợp đồng chuyển mã thông báo ETH: Thử nghiệm này sử dụng các giao dịch ETH lịch sử thực tế giống như hợp đồng thông minh ERC20 tiêu chuẩn.

2. Hợp đồng biểu quyết: Hợp đồng biểu quyết là một ví dụ tuyệt vời về cách mô hình PREDA đơn giản hóa các thuật toán biểu quyết song song. Nó tận dụng các cơ chế phân tách, chuyển tiếp và thực thi dữ liệu của Crystality và PREDA, vượt trội so với các phương pháp song song lạc quan (Aptos) và bi quan (Sui) ở cả TPS tuyệt đối và tăng tốc. Các thuật toán tuần tự ban đầu trong Solidity giờ đây cho phép bỏ phiếu song song trên các máy ảo, với kết quả được tổng hợp từ các mảng tạm thời.

3. AirDrop: Hợp đồng này kích hoạt nhiều lần chuyển mã thông báo hoặc NFT từ một địa chỉ đến nhiều địa chỉ. Nó có mô hình thay đổi trạng thái một-nhiều. Trong trường hợp này, hai giao dịch Sei, Aptos hoặc Sui không thể được thực hiện song song. Chỉ thông qua mô hình PREDA với độ chi tiết song song cao hơn, các giao dịch này mới có thể được xử lý song song ở chế độ đường ống.

4. CryptoKitties: Hợp đồng này là một hợp đồng trò chơi phổ biến trên Ethereum liên quan đến việc nhân giống mèo con dựa trên gen của mèo bố mẹ. Khác với hợp đồng trước, hợp đồng này cần truy cập vào nhiều trạng thái địa chỉ khi xử lý các giao dịch do người dùng thực hiện, bao gồm "mèo mẹ", "mèo cái" và "mèo sơ sinh". Hợp đồng này cũng bao gồm những phép tính phức tạp hơn hợp đồng trước đó trong việc tính toán gen của mèo sơ sinh từ gen của bố mẹ.

5. MillionPixel: Trong hợp đồng trò chơi trên Ethereum này, người dùng phải là người đầu tiên đánh dấu tọa độ trên bản đồ. Hợp đồng thông minh này được sử dụng để chứng minh tính linh hoạt của mô hình PREDA. Ngoài việc phân vùng trạng thái hợp đồng theo địa chỉ, lập trình viên cũng có thể tùy chỉnh khóa phân vùng, chẳng hạn như chuyển từ loại địa chỉ sang loại uint32 trong trường hợp này.

   

Nhằm giúp người đọc có thể hiểu được lượng lớn dữ liệu trên , phần sau đây tập trung phân tích hai hợp đồng mang tính đại diện cụ thể.

Hợp đồng chuyển mã thông báo ETH: Khi phát lại dữ liệu giao dịch lịch sử ETH, tỷ lệ thông lượng và khả năng mở rộng tuyệt đối của năm hệ thống đã giảm so với thử nghiệm ERC20. Điều này là do các địa chỉ trùng lặp trong các giao dịch lịch sử gây ra tranh chấp trạng thái (xung đột đọc-ghi hoặc xung đột ghi-ghi), điều này ngăn cản việc thực hiện đồng thời các giao dịch này trong EVM song song.

Hợp đồng biểu quyết: Hợp đồng Sei hầu như chỉ được thực hiện tuần tự, không tăng tốc khi chạy nhiều EVM. Kết quả tương tự sẽ xảy ra trong các hệ thống khác nếu thuật toán không được chuyển sang song song. Để triển khai song song Aptos và Sui, nhiều tài nguyên phải được khởi tạo ở các địa chỉ khác nhau để có kết quả tạm thời của biến "đề xuất". Ngoài ra, việc triển khai song song phải cung cấp khả năng lập lịch thủ công dựa trên địa chỉ của cử tri, hướng các giao dịch của cử tri đến các máy ảo khác nhau và truy cập các kết quả tạm thời để thực hiện song song.

Cảm hứng từ kết quả thử nghiệm

Chúng tôi lấy cảm hứng sau từ kết quả thử nghiệm:

So sánh các phương pháp song song lạc quan và bi quan

Aptos và Sui mỗi người hoạt động tốt nhất trong các tình huống cụ thể khác nhau. Trong trường hợp chuyển khoản ERC20, Aptos hoạt động tốt hơn Sui vì chuyển khoản ERC20 sử dụng địa chỉ được tạo ngẫu nhiên trong mỗi giao dịch, dẫn đến rất ít xung đột. Ngược lại, trong trường hợp thử nghiệm ETH, Sui hoạt động tốt hơn Aptos do có số lượng lớn xung đột xảy ra khi phát lại các giao dịch lịch sử ETH.

Phân tích thời gian thực thi Aptos

Bảng dưới đây trình bày dữ liệu phân tích hiệu suất của Aptos khi chạy 2 hợp đồng này (sử dụng cùng một hợp đồng thông minh, tuy nhiên, dữ liệu giao dịch sử dụng dữ liệu giao dịch lịch sử hoặc được tạo ngẫu nhiên tương ứng). Vì việc phân tích hiệu suất tốn nhiều thời gian nên số lượng máy ảo song song được sử dụng để thử nghiệm bị giới hạn ở mức tối đa là 64.

Việc thực hiện giao dịch Aptos bao gồm cả việc thực hiện và xác minh Ở bước này, dữ liệu thử nghiệm cho thấy một số lượng lớn trạng thái thực hiện giao dịch được đánh dấu là "TẠM NGỪNG" (bị tạm dừng) và việc thực hiện các giao dịch này mất nhiều thời gian. "TẠM NGỪNG" có nghĩa là việc thực hiện giao dịch bị tạm dừng cho đến khi các phụ thuộc trạng thái của nó được giải quyết trước khi có thể tiếp tục thực hiện. Đối với các giao dịch ngẫu nhiên trên 64 máy ảo, tổng số lần thực hiện và xác minh lần lượt là 102.219 và 139.426. Đối với các giao dịch trong lịch sử, những con số này tăng lên 186.948 và 667.148, với giao dịch đang chờ xử lý tăng từ 66 lên 46.913. Do đó, khi xảy ra một số lượng lớn xung đột trạng thái trong quá trình thực hiện giao dịch, việc khôi phục sẽ trở thành gánh nặng cho quá trình song song hóa lạc quan.

Phân tích thời gian thực hiện Sui

Biểu đồ sau đây cho thấy Sui trong quá trình kiểm tra hợp đồng chuyển mã thông báo ETH và thời gian kiểm tra hợp đồng biểu quyết -chi tiết tiêu thụ. Trong công cụ thực thi song song của Sui, có ba bước chính: (1) Thời gian xếp hàng: thời gian chờ trước khi người quản lý giao dịch chọn; (2) Thời gian quản lý tác vụ: giao dịch được đặt vào bản đồ băm Txns Đang thực thi của Sui hoặc Đang chờ xử lý. Bản đồ băm Txns, khoảng thời gian kể từ khi Trình điều khiển thực thi của Sui nhận được nó; (3) Thời gian thực thi hàm: thời gian khi hàm hợp đồng được thực thi bởi luồng công nhân trong Trình điều khiển thực thi.

Thời gian quản lý tác vụ bao gồm hai phần: Khóa và chờ đợi. So sánh hai biểu đồ này, có thể thấy thời gian quản lý tác vụ trong bài kiểm tra Bỏ phiếu chiếm tỷ trọng lớn hơn đáng kể trong toàn bộ thời gian thực hiện so với bài kiểm tra chuyển ETH Token. Điều này là do trong thử nghiệm Biểu quyết, việc truy cập các đối tượng dùng chung yêu cầu khóa và chờ để tránh xung đột, khiến thời gian quản lý tác vụ dài hơn 2 đến 4 bậc so với thời gian thực hiện chức năng và thời gian xếp hàng. Ngược lại, trong thử nghiệm chuyển Token ETH, vì chỉ sử dụng Đối tượng sở hữu nên việc kiểm soát đồng thời bị bỏ qua và thời gian quản lý tác vụ ít hơn nhiều.

Hạn chế của Aptos và Sui

Tóm lại, Aptos sử dụng phương pháp song song lạc quan, cho phép thực hiện giao dịch song song ngay cả khi có xung đột. Cách tiếp cận này dựa trên kiểm soát đồng thời lạc quan (OCC) rất hiệu quả đối với khối lượng công việc đọc chiếm ưu thế, phổ biến hơn trong cơ sở dữ liệu và hệ thống dữ liệu lớn nơi yêu cầu ghi không thường xuyên. Tuy nhiên, trong các hệ thống blockchain, cách tiếp cận này có thể phát sinh chi phí gas rất lớn do phí gas liên quan đến việc thực hiện trên chuỗi. Trong thực tế, người dùng thường gửi yêu cầu chỉ đọc (chẳng hạn như giao dịch lịch sử hoặc truy vấn khối) đến cơ sở dữ liệu ngoài chuỗi như Etherscan, trong khi yêu cầu ghi được sử dụng để thực thi trên chuỗi. Trong trường hợp này, các hệ thống OCC như Aptos sẽ thường xuyên gặp phải tình trạng "Tạm dừng" và treo giao dịch, do đó làm giảm hiệu suất tổng thể của máy ảo song song.

Ngược lại, Sui áp dụng song song bi quan, xác minh nghiêm ngặt sự phụ thuộc trạng thái giữa các giao dịch và ngăn ngừa xung đột trong quá trình thực thi thông qua cơ chế Khóa. Cách tiếp cận dựa trên kiểm soát đồng thời bi quan (PCC) này phù hợp hơn với khối lượng công việc tính toán chuyên sâu, trong trường hợp đó, chi phí liên quan đến PCC thậm chí không đáng kể. Nhưng trong các hoạt động đơn giản về mặt logic, chi phí liên quan đến PCC có thể dễ dàng trở thành nút cổ chai về hiệu suất. Trong thế giới thực, nhiều giao dịch được thực hiện trên hệ thống blockchain, chẳng hạn như chuyển mã thông báo ERC20, chuyển mã thông báo Move hoặc chuyển NFT, bao gồm các hoạt động tương đối đơn giản. Cụ thể, việc chuyển mã thông báo ERC20 thường liên quan đến việc trừ một số tiền nhất định từ một địa chỉ và thêm nó vào một địa chỉ khác. Tương tự, chuyển mã thông báo di chuyển hoặc chuyển NFT liên quan đến việc di chuyển tài nguyên hoặc đối tượng từ địa chỉ này sang địa chỉ khác. Ngay cả khi tính đến các bước kiểm tra bổ sung như xác minh quyền sở hữu, các hoạt động này vẫn diễn ra rất nhanh. Tại thời điểm này, chi phí liên quan đến PCC trở thành yếu tố hạn chế về hiệu suất hệ thống song song.

Để giải quyết những thách thức này, PREDA đề xuất một hệ thống gần như tránh hoàn toàn chi phí PCC và nhu cầu thực hiện lại OCC. Cách tiếp cận này cho phép thực thi song song hầu như không có xung đột bằng cách phân chia trạng thái trên chuỗi một cách hiệu quả.

Hiệu suất của Crystalality và PREDA

Trong tất cả các thử nghiệm hợp đồng, dữ liệu hiệu suất của Crystalality và PREDA tốt hơn đáng kể so với Sei, Aptos và Sui, trong đó PREDA hoạt động đặc biệt tốt vì nó thực thi ở chế độ nhị phân gốc thay vì WASM. Hiệu suất cao này là do thực thi song song hầu như không có xung đột. PREDA đã xem xét hai khía cạnh chính sau đây ngay từ khi bắt đầu thiết kế:

1. Xác định các phạm vi trạng thái hợp đồng khác nhau và hệ thống sẽ điều chỉnh trạng thái dựa trên phạm vi này Chia và duy trì.

2. Để chuyển luồng thực hiện giao dịch từ máy ảo này sang máy ảo khác.

Cốt lõi của PREDA là giới thiệu Phạm vi hợp đồng có thể lập trình, phân chia trạng thái hợp đồng thành các mảnh Fine-grained không chồng chéo và có thể song song hóa; và giới thiệu Rơle chức năng không đồng bộ để mô tả việc chuyển đổi luồng thực thi giữa các EVM khác nhau.

Hãy giải thích thêm ý nghĩa của các khái niệm này. Trong PREDA, hàm hợp đồng được phân tách thành nhiều bước có thứ tự. Mỗi bước dựa trên một đoạn trạng thái có thể song song hóa duy nhất mà không có xung đột.

Ví dụ: Thông thường, việc chuyển Token bao gồm hai bước: một là bước trích xuất, tức là truy cập trạng thái của Người gửi và trích xuất số lượng Token được chỉ định, và hai là bước gửi tiền, đó là là truy cập trạng thái Người nhận và gửi số lượng Token tương ứng. Các cơ chế song song gần đây được triển khai như Sei, Aptos và Sui cố gắng thực hiện đồng bộ tất cả các bước trong mỗi giao dịch. Nếu trạng thái truy cập giữa hai giao dịch được chia sẻ hoặc cập nhật, chẳng hạn như khi Người gửi hoặc Người nhận giống nhau, hai giao dịch sẽ không được thực hiện song song.

Tuy nhiên, PREDA sử dụng cơ chế có thể phân tách và không đồng bộ, trong đó các bước riêng lẻ của giao dịch được phân tách theo sự phụ thuộc vào quyền truy cập dữ liệu của chúng, cho phép mỗi bước được thực thi không đồng bộ, độc lập với các bước khác. Quyền truy cập vào cùng một trạng thái được tuần tự hóa nghiêm ngặt theo thứ tự được xác định trong khối giao dịch ban đầu và được đảm bảo bởi thuật toán đồng thuận, tức là do người tạo khối ra lệnh.

Ví dụ: Giao dịch chuyển mã thông báo Txn 0 (chuyển mã thông báo từ trạng thái địa chỉ A sang trạng thái B) và Txn 1 (chuyển từ trạng thái A sang trạng thái C) có thể truy cập A hai lần theo trình tự (tương ứng với Txn 0 và Txn 1), sau đó truy cập song song B và C.

So sánh kiến ​​trúc của việc thực thi song song trong Aptos, Sei và PREDA

Hạn chế của PREDA và Crystalality

Mặc dù PREDA và Crystality có thể trao quyền cho các hệ thống blockchain và mang lại những lợi thế đáng kể về hiệu suất, những hạn chế của chúng cũng được phản ánh ở các khía cạnh sau.

Mất cân bằng khối lượng công việc giữa các EVM song song

Cơ chế chuyển hướng luồng thực thi và phân chia dữ liệu của Crystality có thể khiến các EVM song song gặp phải tình trạng tải khi chạy Sự cố mất cân bằng. Chúng tôi đã quan sát thấy sự cố này khi sử dụng hợp đồng MyToken để phát lại các giao dịch chuyển mã thông báo ETH lịch sử.

Để đánh giá mức phân bổ tải, chúng tôi đã đếm số lượng giao dịch được thực hiện trên mỗi EVM, cả thô và chuyển tiếp, sau đó tính toán phạm vi và độ lệch chuẩn của những con số này. Kết quả cho thấy số lượng giao dịch được thực hiện trên 64 EVM rất khác so với phạm vi trên 2 EVM, điều đó có nghĩa là có những điểm nóng tại một số địa chỉ EVM nhất định (nghĩa là tập trung các giao dịch lịch sử xảy ra trên một tập hợp con địa chỉ). Điều tra sâu hơn về bộ dữ liệu ETH cho thấy mỗi địa chỉ nóng có liên quan đến hơn 4.000 giao dịch. Ở đây cần phải chỉ ra rằng, theo như chúng tôi biết, Aptos và Sui không thể thực hiện song song trong trường hợp này.

Dữ liệu thử nghiệm của chúng tôi cho thấy rằng khi số lượng EVM tăng lên thì độ lệch chuẩn sẽ giảm xuống, điều đó có nghĩa là việc bổ sung thêm nhiều EVM sẽ giúp giảm bớt vấn đề mất cân bằng tải.

Để giải quyết các vấn đề nóng trên blockchain, một giải pháp khả thi là sử dụng nhiều địa chỉ thay vì một địa chỉ duy nhất để gửi hoặc nhận mã thông báo. Nếu sự mất cân bằng tải xảy ra do một số địa chỉ không nóng ánh xạ tới cùng một máy ảo thì các phương pháp hiện có trong phân chia chuỗi khối, chẳng hạn như di chuyển dữ liệu, có thể hữu ích.

Viết lại chương trình

Một hạn chế đáng kể khác của PREDA và Crystality là các nhà phát triển cần sử dụng các lệnh để viết lại hợp đồng thông minh. Nếu có một công cụ có thể tự động dịch các hợp đồng thông minh hiện có được viết bằng Solidity, Move hoặc Rust thành các hợp đồng thông minh Crystality tương đương, thì nó sẽ tối ưu hóa đáng kể trải nghiệm của nhà phát triển. Đánh giá từ kinh nghiệm trước đây, điều này không khó để đạt được. Đã có một số nghiên cứu khám phá khả năng dịch giữa các ngôn ngữ khác nhau, chẳng hạn như từ Solidity sang Move và từ Python sang Solidity.

Những tiến bộ công nghệ trong xử lý ngôn ngữ tự nhiên đã nâng cao đáng kể tiềm năng tạo mã tự động. Những tiến bộ này kết hợp với công nghệ dịch trình biên dịch dựa trên quy tắc và mẫu (chẳng hạn như dịch SQL sang MapReduce cho dữ liệu lớn và dịch đồ thị tính toán sang ma trận để học sâu) hoàn toàn có thể hỗ trợ phát triển các công cụ dịch hợp đồng thông minh tự động.

Kết luận

So sánh hiệu suất giữa Sei, Aptos, Sui và Crystality/PREDA nêu bật lĩnh vực song song hóa blockchain đang phát triển. Aptos (với Sei) và Sui lần lượt thể hiện tiềm năng của các cơ chế song song lạc quan và bi quan, mỗi cơ chế đều cho thấy lợi thế trong các tình huống khác nhau. Tuy nhiên, những cải tiến hiệu suất đáng kể của Crystalality và PREDA cho thấy các mô hình song song hóa tiên tiến hơn có thể là chìa khóa để mở ra mức độ mở rộng và hiệu quả cao hơn.

Để tóm tắt những khám phá và quan sát của chúng tôi về ba phương pháp song song chính trong lĩnh vực blockchain, chúng tôi đã biên soạn một bảng. Nếu bạn muốn Takeaway từ bài đăng này, đó là những gì có trong biểu mẫu này.