PREDA: Mảnh ghép cuối cùng của câu đố VM song song

Người viết: PREDA Nguồn: chainfeeds 

Tóm tắt

Nhìn vào lịch sử song song của máy tính: cấp độ song song đầu tiên là song song ở cấp độ lệnh. Song song ở cấp độ hướng dẫn là cách kiến ​​trúc chính cải thiện hiệu suất trong hai thập kỷ cuối của thế kỷ 20. Tính song song ở cấp độ hướng dẫn có thể cải thiện hiệu suất trong khi vẫn duy trì khả năng tương thích nhị phân của chương trình, điều này được các lập trình viên đặc biệt đánh giá cao. Sự song song ở cấp độ hướng dẫn được chia thành hai loại. Một là song song thời gian, đó là đường dẫn hướng dẫn. Dây chuyền lắp ráp hướng dẫn cũng giống như dây chuyền lắp ráp trong một nhà máy sản xuất ô tô. Nhà máy sản xuất ô tô sẽ không đợi một chiếc ô tô được lắp đặt trước khi bắt đầu sản xuất chiếc ô tô tiếp theo. trong nhiều quá trình. Cái còn lại là song song không gian, tức là đa phát xạ hoặc siêu vô hướng. Nhiều làn đường giống như đường có nhiều làn đường và việc thực hiện không theo thứ tự cho phép vượt trên nhiều làn đường. Siêu vô hướng và thực hiện không theo thứ tự thường được sử dụng cùng nhau để nâng cao hiệu quả. Sau khi RISC xuất hiện vào những năm 1980, sự phát triển của song song cấp độ hướng dẫn đã đạt đến đỉnh cao trong 20 năm sau đó. Sau năm 2010, không còn nhiều cơ hội để khám phá thêm về song song cấp độ hướng dẫn.

Mức song song thứ hai là song song cấp dữ liệu, chủ yếu đề cập đến cấu trúc vectơ của Luồng lệnh đơn Nhiều luồng dữ liệu ( SIMD) . Sự song song cấp độ dữ liệu sớm nhất xuất hiện trong ENIAC. Máy vector do Cray đại diện rất phổ biến vào những năm 1960 và 1970, từ Cray-1 và Cray-2 cho đến sau này là Cray X-MP và Cray Y-MP. SIMD đã không hoạt động một thời gian cho đến Cray-4, nhưng bây giờ nó đang hoạt động trở lại và ngày càng được sử dụng nhiều hơn. Ví dụ: hướng dẫn đa phương tiện AVX trong X86 có thể sử dụng đường dẫn 256 bit để thực hiện bốn thao tác 64 bit hoặc tám thao tác 32 bit. Là một sự bổ sung hiệu quả cho tính song song ở mức hướng dẫn, SIMD đã đóng một vai trò quan trọng trong lĩnh vực truyền phát trực tuyến. Trong những ngày đầu, nó chủ yếu được sử dụng trong các bộ xử lý có mục đích đặc biệt, nhưng giờ đây nó đã trở thành một cấu hình tiêu chuẩn cho mục đích chung. bộ xử lý.

Cấp độ song song thứ ba là song song cấp nhiệm vụ. Sự song song ở cấp độ nhiệm vụ tồn tại rộng rãi trong các ứng dụng Internet. Tính song song ở cấp độ tác vụ được thể hiện bằng bộ xử lý đa lõi và bộ xử lý đa luồng, đây là những phương pháp chính để cải thiện hiệu suất của kiến ​​trúc máy tính hiện tại. Độ chi tiết song song của tính song song ở cấp độ nhiệm vụ lớn hơn và một luồng chứa hàng trăm lệnh trở lên.

Từ góc độ phát triển điện toán song song, chuỗi khối ngày nay đang trong quá trình chuyển đổi từ cấp độ đầu tiên sang cấp độ thứ hai. Các hệ thống blockchain chính thống thường áp dụng kiến ​​trúc chuỗi đơn hoặc đa chuỗi. Các chuỗi đơn, chẳng hạn như Bitcoin và Ethereum thông thường, chỉ có một chuỗi trong toàn bộ hệ thống. Mỗi nút trong chuỗi thực hiện chính xác cùng một giao dịch hợp đồng thông minh và duy trì trạng thái hoàn toàn nhất quán trên chuỗi. Trong mỗi nút blockchain, các giao dịch hợp đồng thông minh thường được thực hiện tuần tự, dẫn đến thông lượng của toàn bộ hệ thống thấp.
Mặc dù một số hệ thống blockchain hiệu suất cao xuất hiện gần đây áp dụng kiến ​​trúc chuỗi đơn, nhưng chúng cũng hỗ trợ thực hiện song song các giao dịch hợp đồng thông minh. Thomas Dickerson và Maurice Herlihy của Đại học Brown và Đại học Yale lần đầu tiên đề xuất một mô hình thực thi song song dựa trên phương pháp STM (Bộ nhớ giao dịch phần mềm) trong bài báo PODC'17 của họ. song song Nếu một giao dịch gặp phải xung đột truy cập trạng thái trong quá trình thực thi song song, trạng thái sẽ được khôi phục thông qua STM và sau đó các giao dịch có xung đột trạng thái này sẽ được thực hiện tuần tự. Cách tiếp cận này đã được áp dụng cho nhiều dự án blockchain hiệu suất cao, bao gồm Aptos, Sei, Monad, v.v. Tương ứng, một mô hình thực thi song song khác dựa trên sự đồng thời bi quan (song song bi quan). Tức là trước khi một giao dịch được thực hiện song song, cần phải phát hiện xem có xung đột về trạng thái mà giao dịch đó truy cập hay không. được thực hiện song song. Loại phương pháp này thường áp dụng phương pháp tính toán trước, sử dụng các công cụ phân tích chương trình để phân tích tĩnh mã hợp đồng thông minh và xây dựng các phần phụ thuộc trạng thái, chẳng hạn như biểu đồ chu kỳ có hướng (DAG). Khi một giao dịch đồng thời được gửi tới hệ thống, hệ thống sẽ xác định liệu giao dịch đó có thể được thực hiện song song hay không dựa trên các trạng thái mà giao dịch cần truy cập và sự phụ thuộc giữa các trạng thái. Chỉ các giao dịch không có trạng thái phụ thuộc lẫn nhau mới được thực hiện song song. Loại phương pháp này đã được áp dụng cho các dự án blockchain hiệu suất cao như Zilliqa (phiên bản CoSplit) và Sui. Các mô hình thực thi song song ở trên có thể cải thiện đáng kể thông lượng của hệ thống. Hai giải pháp này tương ứng với sự song song ở cấp độ hướng dẫn được đề cập ở trên. Tuy nhiên, những công trình này gặp phải hai vấn đề: 1) vấn đề về khả năng mở rộng và 2) vấn đề biểu hiện ngữ nghĩa song song, mà chúng tôi sẽ giải thích rõ hơn ở phần sau.

Thiết kế song song

Chúng tôi sẽ sử dụng các giải pháp kỹ thuật của các dự án Solana và Monad điển hình làm ví dụ . Loại bỏ thiết kế kiến ​​trúc song song của chúng, bao gồm phân loại song song, phụ thuộc dữ liệu và các chỉ báo quan trọng khác sẽ ảnh hưởng đến tính song song và TPS.

Solana

Từ cấp độ cao, Solana được thiết kế với ý tưởng rằng sự đổi mới blockchain sẽ phát triển khi phần cứng tiến bộ. Khi phần cứng tiếp tục được cải tiến theo Định luật Moore, Solana được thiết kế để hưởng lợi từ việc tăng hiệu suất và khả năng mở rộng. Người đồng sáng lập Solana, Anatoly Ykovenko, ban đầu đã thiết kế kiến ​​trúc song song của Solana hơn 5 năm trước và ngày nay, tính song song đang nhanh chóng lan rộng như một nguyên tắc thiết kế blockchain.

Solana sử dụng song song hóa xác định  (Song song hóa xác định), xuất phát từ kinh nghiệm trước đây của Anatoly trong việc sử dụng các hệ thống nhúng, các nhà phát triển Thông thường đều nêu được khai báo ở phía trước. Điều này cho phép CPU hiểu tất cả các phần phụ thuộc và do đó có thể tìm nạp trước các phần bộ nhớ cần thiết. Kết quả là việc thực thi hệ thống được tối ưu hóa, nhưng một lần nữa, nó đòi hỏi nhà phát triển phải thực hiện thêm công việc trả trước. Trên Solana, tất cả các phần phụ thuộc bộ nhớ của một chương trình đều được yêu cầu và tính đến trong các giao dịch được xây dựng (tức là danh sách truy cập), cho phép bộ thực thi lên lịch và thực hiện nhiều giao dịch song song một cách hiệu quả.
Thành phần chính tiếp theo của kiến ​​trúc Solana là Sealevel VM, hỗ trợ xử lý song song nhiều hợp đồng và giao dịch dựa trên số lõi mà trình xác thực có. Người xác minh trong chuỗi khối là những người tham gia mạng chịu trách nhiệm xác minh và xác nhận giao dịch, đề xuất các khối mới cũng như duy trì tính toàn vẹn và bảo mật của chuỗi khối. Vì các giao dịch khai báo trước những tài khoản nào yêu cầu khóa đọc-ghi nên bộ lập lịch Solana có thể xác định giao dịch nào có thể thực hiện đồng thời. Do đó, tại thời điểm xác thực, “nhà sản xuất khối” hoặc người lãnh đạo có thể sắp xếp hàng nghìn giao dịch đang chờ xử lý và lên lịch song song các giao dịch không chồng chéo.

Monad

Monad đang xây dựng lớp 1 EVM song song với tính hoàn chỉnh của Turing.  Monad độc đáo không chỉ ở công cụ song song hóa mà còn ở công cụ tối ưu hóa mà họ đã xây dựng ở hậu trường.  Monad áp dụng cách tiếp cận độc đáo đối với thiết kế tổng thể của nó, kết hợp một số tính năng chính, bao gồm quy trình, I/O không đồng bộ, sự đồng thuận và thực thi tách rời cũng như MonadDB.

Tương tự như Sei, chuỗi khối Monad sử dụng "Kiểm soát đồng thời tối ưu (OCC)" để thực hiện các giao dịch. Xử lý giao dịch đồng thời xảy ra khi có nhiều giao dịch tồn tại trong hệ thống cùng một lúc. Phương thức giao dịch này có hai giai đoạn: thực hiện và xác minh.

Trong giai đoạn thực hiện, các giao dịch được xử lý một cách lạc quan và tất cả các lần đọc/ghi được lưu trữ tạm thời trong bộ lưu trữ dành riêng cho giao dịch. Sau đó, mỗi giao dịch sẽ bước vào giai đoạn xác minh, trong đó thông tin trong hoạt động lưu trữ tạm thời sẽ được kiểm tra dựa trên mọi thay đổi trạng thái do các giao dịch trước đó thực hiện. Nếu các giao dịch là độc lập thì các giao dịch sẽ chạy song song. Nếu một giao dịch đọc dữ liệu được sửa đổi bởi một giao dịch khác thì xung đột sẽ xảy ra.

Một cải tiến quan trọng trong thiết kế Monad là đường dẫn hơi lệch một chút. Phần bù này cho phép song song hóa nhiều quy trình hơn bằng cách chạy nhiều phiên bản cùng một lúc. Do đó, các quy trình được sử dụng để tối ưu hóa nhiều chức năng, chẳng hạn như quy trình truy cập trạng thái, quy trình thực hiện giao dịch, quy trình trong sự đồng thuận và thực thi cũng như các quy trình trong chính cơ chế đồng thuận. Trong hình bên dưới, chúng tương ứng với việc giặt, sấy, gấp quần áo và các thao tác khác. cất chúng vào tủ.

p>

Trong Monad, các giao dịch được sắp xếp tuyến tính trong các khối, nhưng mục tiêu là đạt đến trạng thái cuối cùng nhanh hơn bằng cách tận dụng khả năng thực thi song song. Monad sử dụng thuật toán Song song hóa tối ưu để thiết kế công cụ thực thi của nó. Công cụ của Monad xử lý các giao dịch đồng thời và sau đó phân tích chúng để đảm bảo rằng nếu các giao dịch được thực hiện lần lượt thì kết quả sẽ giống nhau. Nếu có xung đột thì phải thực hiện lại. Việc thực thi song song ở đây là một thuật toán tương đối đơn giản, nhưng việc kết hợp nó với những cải tiến quan trọng khác của Monad làm cho phương pháp này trở nên mới lạ. Một điều cần lưu ý ở đây là ngay cả khi việc thực thi lại xảy ra, nó thường rẻ vì đầu vào được yêu cầu bởi giao dịch không hợp lệ hầu như luôn được giữ trong bộ đệm, vì vậy đây sẽ là một tra cứu bộ đệm đơn giản. Việc thực hiện lại chắc chắn sẽ thành công vì bạn đã thực hiện giao dịch trước đó trong khối.

Ngoài khả năng thực thi lười biếng, Monad còn cải thiện hiệu suất bằng cách tách rời khả năng thực thi và sự đồng thuận, tương tự như Solana và Sei. Ý tưởng ở đây là nếu bạn nới lỏng điều kiện thực thi hoàn thành khi đồng thuận hoàn tất, bạn có thể chạy song song cả hai, giúp cả hai có thêm thời gian. Tất nhiên, Monad xử lý tình huống này bằng thuật toán xác định để đảm bảo rằng một trong số chúng không đi quá xa để bắt kịp.

Cho dù áp dụng thực thi song song lạc quan hay bi quan, các hệ thống trên đều sử dụng bộ nhớ dùng chung làm sự trừu tượng hóa mô hình dữ liệu cơ bản, nghĩa là, bất kể có bao nhiêu đơn vị song song có các đơn vị song song Tất cả dữ liệu có thể được lấy (ở đây đề cập đến tất cả dữ liệu trên chuỗi trong chuỗi khối) và dữ liệu trạng thái có thể được truy cập trực tiếp bởi các đơn vị thực thi song song khác nhau (nghĩa là tất cả dữ liệu trên chuỗi có thể được đọc trực tiếp và viết bằng đơn vị song song). Đối với hệ thống blockchain sử dụng bộ nhớ dùng chung làm mô hình dữ liệu cơ bản, tính đồng thời của nó thường bị giới hạn ở một nút vật lý duy nhất (Solana) và khả năng tương tranh của mỗi nút vật lý bị giới hạn bởi khả năng tính toán của nút, nghĩa là, số lượng luồng vật lý (giả sử Mỗi luồng hỗ trợ một máy ảo).

Phương pháp song song nội bộ nút này chỉ yêu cầu sửa đổi kiến ​​trúc của lớp thực thi hợp đồng thông minh và không yêu cầu sửa đổi logic của lớp đồng thuận hệ thống, làm cho nó rất phù hợp để cải thiện thông lượng hệ thống đơn lẻ. Do đó, vì việc lưu trữ dữ liệu không bị phân chia nênmỗi nút trong mạng blockchain vẫn cần thực hiện tất cả giao dịch và lưu trữ tất cả trạng thái. Đồng thời, so với kiến ​​trúc không chia sẻ phù hợp hơn cho việc mở rộng phân tán, các hệ thống sử dụng bộ nhớ dùng chung làm trừu tượng hóa mô hình dữ liệu cơ bản này không thể mở rộng theo chiều ngang khả năng xử lý của chúng, điều này có thể đạt được bằng cách tăng số lượng của máy vật lý. Việc mở rộng khả năng lưu trữ và thực thi trạng thái hệ thống về cơ bản không thể giải quyết được vấn đề về khả năng mở rộng của blockchain.

Vậy đã có giải pháp sẵn sàng chưa?

Mô hình lập trình song song

Trước khi giới thiệu PREDA, chúng tôi muốn đặt một câu hỏi tự nhiên: :Tại sao nên sử dụng lập trình song song? Trong suốt những năm 1970, 1980 và thậm chí một phần những năm 1990, chúng tôi hoàn toàn hài lòng với lập trình đơn luồng, hay còn gọi là lập trình nối tiếp. Bạn có thể viết một chương trình để hoàn thành một nhiệm vụ. Sau khi thực hiện sẽ cho bạn kết quả. Nhiệm vụ hoàn thành, mọi người sẽ hạnh phúc! Mặc dù nhiệm vụ đã hoàn thành, nhưng nếu bạn đang thực hiện mô phỏng hạt yêu cầu hàng triệu hoặc hàng tỷ phép tính mỗi giây hoặc đang xử lý hình ảnh có hàng chục nghìn pixel, bạn sẽ muốn chương trình chạy nhanh hơn, điều đó có nghĩa là bạn cần nhanh hơn. CPU.
Trước năm 2004, các nhà sản xuất CPU IBM, Intel và AMD đều có thể cung cấp cho bạn bộ xử lý ngày càng nhanh hơn. Tần số xung nhịp của bộ xử lý tăng từ 16 MHz, 20 MHz, 66 MHz, 100 MHz và tăng dần lên 200 MHz. 333 MHz, 466 MHz... Có vẻ như chúng có thể liên tục tăng tốc độ của CPU, tức là chúng có thể liên tục cải thiện hiệu suất của CPU. Nhưng đến năm 2004, rõ ràng là việc tăng tốc độ CPU không thể duy trì được do những hạn chế về mặt kỹ thuật. Điều này đòi hỏi các công nghệ khác phải tiếp tục mang lại hiệu suất cao hơn. Giải pháp từ các nhà sản xuất CPU là đặt hai CPU vào một CPU, mặc dù cả hai CPU đều hoạt động chậm hơn một CPU. Ví dụ: hai CPU (các nhà sản xuất gọi chúng là lõi) hoạt động ở tốc độ 200 MHz cùng nhau có thể thực hiện nhiều phép tính mỗi giây (nghĩa là bằng trực quan) so với CPU một lõi hoạt động ở tốc độ 300 MHz.
Câu chuyện nghe như mơ về "một CPU nhiều lõi" đã trở thành hiện thực, điều đó có nghĩa là các lập trình viên giờ đây phải học các phương pháp lập trình song song để tận dụng lợi thế của hai lõi này. Nếu CPU có thể thực thi đồng thời hai chương trình thì người lập trình phải viết cả hai chương trình. Nhưng điều này có chuyển thành tốc độ của chương trình gấp đôi không? Nếu không thì có điều gì đó không ổn với ý tưởng của chúng tôi về 2×200 > Điều gì xảy ra nếu một lõi không có đủ công việc? Tức là chỉ có một lõi thực sự bận trong khi lõi còn lại không làm gì? Trong trường hợp này, tốt hơn là sử dụng lõi đơn 300 MHz. Nhiều vấn đề tương tự đã xuất hiện khi giới thiệu đa lõi và việc sử dụng hiệu quả các lõi này chỉ có thể đạt được thông qua lập trình.

p>

Trong hình bên dưới, chúng ta tưởng tượng Bob và Alice là hai người đào vàng và việc khai thác vàng cần bốn bước:

1. Lái xe đến mỏ

2. Khai thác

3. Đang tải quặng

4. Lưu trữ và đánh bóng

Toàn bộ quá trình khai thác bao gồm bốn nhiệm vụ độc lập nhưng có thứ tự, mỗi nhiệm vụ kéo dài 15 phút. Khi Bob và Alice làm việc cùng lúc, họ có thể hoàn thành gấp đôi khối lượng công việc khai thác trong một giờ - vì họ có ô tô riêng, họ có thể đi chung đường và có thể dùng chung dụng cụ mài.
Nhưng nếu một ngày, chiếc xe tải khai thác mỏ của Bob bị hỏng. Anh ta để chiếc xe tải khai thác ở tiệm sửa chữa và để quên chiếc cuốc khai thác trong xe tải khai thác. Khi họ quay lại nhà máy chế biến thì đã quá muộn nhưng họ vẫn còn việc phải làm. Họ vẫn có thể khai thác hai quặng mỗi phút chỉ bằng cách sử dụng xe khai thác của Alice và 1 chiếc cuốc sắt bên trong chứ?
Trong ví dụ trên, bốn bước khai thác là các luồng, phương tiện khai thác là cốt lõi; mỏ là đơn vị dữ liệu cần được thực thi bởi hợp đồng thông minh; cái cuốc là đơn vị thực thi; hai thành phần luồng phụ thuộc lẫn nhau: Bạn không thể thực thi luồng 2 cho đến khi luồng 1 thực thi xong. Lượng khoáng sản thu hoạch được phản ánh hiệu quả của chương trình. Thành tích càng cao thì phần thưởng dành cho cốm của Bob và Alice càng cao. Hãy coi mỏ như một bộ nhớ mà từ đó bạn nhận được một đơn vị dữ liệu (mỏ vàng), do đó việc chọn quặng trong luồng 1 tương tự như đọc một đơn vị dữ liệu từ bộ nhớ.
Bây giờ, hãy xem điều gì sẽ xảy ra nếu xe tải khai thác của Bob bị hỏng. Bob và Alice cần dùng chung một chiếc ô tô, đây không phải là vấn đề ban đầu, tuy nhiên, với tiền đề là đảm bảo hiệu quả khai thác, sau khi thiết bị khai thác được nâng cấp, mọi thứ trở nên khác biệt; một nút thắt đối với hiệu quả tổng thể, bởi vì cho dù máy khai thác được sử dụng hiệu quả đến đâu thì lượng quặng có thể được gửi để nghiền và chế biến vẫn bị hạn chế bởi "công suất tối đa của xe đẩy để chứa khoáng sản."

Đây cũng là bản chất của VM song song của Solana, chia sẻ cốt lõi.

Chia sẻ cốt lõi

Yếu tố thiết kế cuối cùng của Solana là < strong>"Đường ống". Đường ống xảy ra khi dữ liệu cần được xử lý thông qua một loạt các bước và phần cứng khác nhau chịu trách nhiệm cho từng bước. Ý tưởng chính ở đây là lấy dữ liệu cần chạy tuần tự và song song hóa dữ liệu đó bằng cách sử dụng một đường dẫn. Các quy trình này có thể chạy song song và mỗi giai đoạn quy trình có thể xử lý một loạt giao dịch khác nhau. Tốc độ xử lý của phần cứng (khả năng chịu tải của xe tải khai thác) càng cao thì khả năng song song xuyên suốt càng cao. Ngày nay, các yêu cầu về nút phần cứng của Solana đã khiến các nhà khai thác nút chỉ có một lựa chọn – trung tâm dữ liệu, mang lại hiệu quả nhưng lại đánh bại mục đích của blockchain.

Các phụ thuộc dữ liệu không bị phân chia (chia sẻ tài nguyên bộ nhớ)

Sau khi nâng cấp phương tiện khai thác In trong tương lai, do năng lực sản xuất khai thác không thể theo kịp nên các phương tiện khai thác thường không được chất đầy. Vì vậy, Bob đã mua một máy khai thác với giá cao để nâng cao hiệu quả khai thác (nâng cấp đơn vị thực thi). Trong cùng 15 phút, có thể tạo ra 10 khoáng sản, nhưng do công việc nghiền quặng vẫn được thực hiện thủ công như trước nên số lượng quặng sản xuất ra trên một đơn vị thời gian không thể chuyển thành nhiều vàng hơn, và nhiều quặng hơn được ép trong kho; cho thấy điều gì xảy ra khi truy cập bộ nhớ là yếu tố hạn chế tốc độ thực thi chương trình của chúng tôi. Việc xử lý dữ liệu nhanh đến mức nào (tức là tốc độ lõi) không còn quan trọng nữa. Chúng tôi sẽ bị giới hạn bởi tốc độ thu thập dữ liệu.
Tốc độ I/O chậm hơn sẽ khiến chúng tôi thực sự khó chịu vì I/O là phần chậm nhất của máy tính và việc đọc dữ liệu không đồng bộ (I/O không đồng bộ) sẽ trở nên quan trọng.
Ngay cả khi Bob có một máy khai thác có thể khai thác 10 khoáng sản trong 15 phút, nếu xảy ra tranh chấp về quyền truy cập bộ nhớ, chúng vẫn sẽ bị giới hạn ở 2 khoáng sản cứ sau 15 phút. Các giải pháp blockchain song song hiện có cho vấn đề này thuộc hai phe – thực thi bi quan và thực thi lạc quan.
Cái trước yêu cầu phải xác định rõ ràng sự phụ thuộc của trạng thái dữ liệu trước khi ghi và đọc dữ liệu, điều này đòi hỏi các nhà phát triển phải đưa ra các giả định về sự phụ thuộc kiểm soát tiền tĩnh. Trong lĩnh vực lập trình hợp đồng thông minh, những giả định này thường sai lệch so với thực tế. . Cái sau không đưa ra bất kỳ giả định hoặc hạn chế nào trong việc ghi dữ liệu và quay lại nếu xảy ra xung đột.
Lấy kế hoạch thực hiện lạc quan của Monad làm ví dụ: Thực tế là phần lớn khối lượng công việc là thực hiện giao dịch và không có nhiều tình huống song song như tưởng tượng. Hình dưới đây cho thấy các loại nguồn tiêu thụ phí gas của Ethereum trong một ngày, bạn sẽ thấy rằng mặc dù mức phân bổ này không cao bằng các hợp đồng thông minh phổ biến nhưng trên thực tế, các loại giao dịch khác nhau thực sự không được phân bổ đồng đều. Logic song song với khả năng thực thi lạc quan là khả thi trong thời đại Web2, vì phần lớn yêu cầu của ứng dụng Web2 là quyền truy cập chứ không phải là sửa đổi như Taobao và Douyin, bạn thực sự không có nhiều cơ hội để sửa đổi trạng thái của các Ứng dụng này. Nhưng trong lĩnh vực Web3 thì ngược lại. Hầu hết các yêu cầu hợp đồng thông minh đều nhằm mục đích sửa đổi trạng thái - cập nhật sổ cái. Trên thực tế, điều này sẽ mang lại nhiều sự quay trở lại bất ngờ hơn, khiến chuỗi không khả dụng.

p>

Vì vậy, kết luận là Monad thực sự có thể đạt được tính song song, nhưng có một giới hạn trên về mặt lý thuyết cho tính song song (Đồng thời), nằm trong phạm vi Gấp 2 đến 3 lần mạnh>, thay vì 100K như quảng cáo. Thứ hai, giới hạn trên này không thể được mở rộng bằng cách thêm máy ảo, tức là không có cách nào đạt được đa lõi tương đương với việc tăng sức mạnh xử lý. Cuối cùng, đây là một câu hỏi phổ biến vì dữ liệu không được phân chia nên Monad thực sự không đáp ứng các yêu cầu đối với các nút do việc mở rộng trạng thái trên chuỗi mang lại. Sau đây là các yêu cầu của nó đối với các nút đã vượt quá giới hạn đó. một máy tính ở nhà có thể mang theo và khi mạng chính của nó trực tuyến, nếu dữ liệu không được phân chia, chúng ta chắc chắn có thể thấy Monad đi theo hướng của Solana. Và cuối cùng nhưng không kém phần quan trọng, việc thực thi lạc quan không phù hợp với tính song song trong lĩnh vực blockchain.

p>

Sau khi khai thác được một lúc, Bob tự đặt câu hỏi: "Tại sao mình phải đợi Alice quay lại rồi mới đánh bóng? Trong khi anh ấy đang đánh bóng, mình có thể tải chiếc xe vì Quá trình tải và quá trình nghiền mất cùng một khoảng thời gian và chúng tôi chắc chắn sẽ không rơi vào tình huống phải đợi quá trình nghiền ở trạng thái không hoạt động trước khi Alice hoàn thành việc khai thác, vì vậy cả hai chúng tôi đều có thể bận rộn 100%.” ý tưởng thiên tài đã cho phép họ quay trở lại hiệu quả gấp đôi mà không cần thêm xe tải khai thác. Điều quan trọng là Bob đã thiết kế lại chương trình, tức là thứ tự thực hiện luồng, để tất cả các luồng sẽ không bao giờ bị kẹt khi chờ tài nguyên dùng chung trong lõi (chẳng hạn như xe khai thác và cuốc đá).
Đây là phiên bản song song chính xác bằng cách phân tách trạng thái của hợp đồng thông minh, việc truy cập các tài nguyên được chia sẻ sẽ không khiến một luồng đi vào hàng đợi cũng như không đạt được tính nguyên tử cuối cùng do giới hạn Đường ống của dữ liệu I/O. . tốc độ.
Mô hình PREDA hiển thị cấu trúc truy cập theo trạng thái hợp đồng khi mã hợp đồng được thực thi ở lớp thực thi, để lớp thực thi có thể lên lịch dễ dàng và hợp lý, tránh hoàn toàn việc khôi phục kết quả thực thi. Chế độ song song này còn được gọi là song song không đồng bộ.

Song song không đồng bộ

Vì chỉ có tính song song là không đồng bộ nên việc thêm các luồng sẽ đi đến Cải tiến tuyến tính . Nó sẽ không giống như ví dụ trước khi công suất của phương tiện khai thác được nâng cấp nhưng phương tiện khai thác lại trống do thiết bị khai thác lỗi thời. Môi trường thực thi song song của PREDA có điểm khác biệt cơ bản nhất so với Moand và Solana - giống như sự khác biệt giữa CPU và GPU đa lõi, hiệu suất xử lý của lõi chia sẻ của nó sẽ không phải là điểm nghẽn của tính song song và không có I/O đọc và thời gian ghi Vấn đề phụ thuộc dữ liệu và quan trọng hơn là tính song song của mô hình song song PREDA sẽ tăng lên do sự gia tăng số luồng, tương tự như GPU. Trong logic của blockchain, việc tăng số luồng (VM) sẽ giảm yêu cầu phần cứng của full node, từ đó cải thiện hiệu suất mà vẫn đảm bảo tính phân cấp.

p>

Cuối cùng, để đạt được mục đích cuối cùng của chuỗi khối song song này, thứ mà ngành này thiếu không chỉ là thiết kế kiến ​​trúc mà còn là cách diễn đạt ngữ nghĩa của các ngôn ngữ lập trình song song.

Biểu hiện ngữ nghĩa của các ngôn ngữ lập trình song song

Giống như Nvidia cần CUDA, blockchain song song Một giải pháp mới ngôn ngữ lập trình cũng cần thiết: PREDA. Các nhà phát triển hợp đồng thông minh ngày nay thể hiện ngữ nghĩa song song và không thể sử dụng hiệu quả sự hỗ trợ được cung cấp bởi kiến ​​trúc đa chuỗi cơ bản (phân chia dữ liệu hoặc phân chia thực thi hoặc cả hai) và không thể đạt được tính song song hiệu quả của các giao dịch hợp đồng thông minh nói chung. Tất cả các hệ thống đều sử dụng các ngôn ngữ lập trình hợp đồng thông minh truyền thống và phổ biến như Solidity, Move và Rust về ngôn ngữ lập trình. Các ngôn ngữ lập trình này thiếu khả năng diễn đạt ngữ nghĩa song song, tức là chúng không có các mô hình lập trình song song trong lĩnh vực điện toán hiệu năng cao hay dữ liệu lớn như CUDA và khả năng của các ngôn ngữ lập trình trong việc diễn đạt luồng điều khiển và dữ liệu luồng giữa các đơn vị song song.

Việc thiếu các mô hình lập trình song song và ngôn ngữ lập trình phù hợp với hợp đồng thông minh sẽ dẫn đến việc không thể tái cấu trúc các ứng dụng và thuật toán từ nối tiếp sang song song. vào hệ thống blockchain cơ bản có khả năng thực thi song song, do đó không cải thiện được hiệu quả thực thi của ứng dụng và thông lượng chung của hệ thống blockchain.

Mô hình lập trình phân tán này do PREDA đề xuất thực hiện phân chia chi tiết trạng thái hợp đồng thông qua phạm vi hợp đồng có lập trình và sử dụng ngữ nghĩa chuyển tiếp chức năng (Rơle chức năng) để phân tách việc thực hiện giao dịch luồng và phân phối nó để thực thi trên nhiều công cụ thực thi song song.

Mô hình này cũng xác định sơ đồ phân chia trạng thái hợp đồng thông qua phạm vi có thể lập trình (Programmable Scope), cho phép nhà phát triển tối ưu hóa theo chế độ truy cập của ứng dụng. Thông qua chức năng chuyển tiếp không đồng bộ, luồng thực hiện giao dịch có thể được chuyển đến công cụ thực thi cần truy cập trạng thái để tiếp tục, thực hiện chuyển động của quá trình thực hiện thay vì chuyển động của dữ liệu.

Mô hình này thực hiện phân chia trạng thái hợp đồng và chia sẻ lưu lượng giao dịch mà không yêu cầu nhà phát triển quan tâm đến các chi tiết của hệ thống đa chuỗi cơ bản. Kết quả thử nghiệm cho thấy mô hình PREDA có thể đạt được mức cải thiện thông lượng lên tới 18 lần trên 256 công cụ thực thi, tiến gần đến giới hạn song song về mặt lý thuyết. Mức độ song song được cải thiện hơn nữa thông qua việc sử dụng các kỹ thuật như bộ đếm phân vùng và các hướng dẫn có thể tráo đổi.

Kết luận

Các hệ thống blockchain thường sử dụng một công cụ thực thi tuần tự duy nhất (chẳng hạn như EVM) để xử lý tất cả các giao dịch, do đó hạn chế khả năng mở rộng. Các hệ thống đa chuỗi chạy các công cụ thực thi song song, nhưng mỗi công cụ xử lý tất cả các giao dịch của hợp đồng thông minh và không thể đạt được khả năng mở rộng ở cấp hợp đồng. Bài viết này thảo luận về sự chia sẻ cốt lõi thiết yếu của tính song song xác định được đại diện bởi Solana và lý do tại sao tính song song lạc quan được đại diện bởi Monad không thể chạy ổn định trong các kịch bản ứng dụng blockchain thực và phải đối mặt với khả năng khôi phục tần số cao. và giới thiệu công cụ thực thi song song của PREDA. Nhóm PREDA đề xuất một mô hình lập trình mới có thể mở rộng quy mô một hợp đồng thông minh bằng cách phân vùng trạng thái của hợp đồng thông minh và phân phối lưu lượng giao dịch trên các công cụ thực thi. Nó giới thiệu phạm vi hợp đồng có thể lập trình để xác định cách phân chia trạng thái hợp đồng. Mỗi phạm vi chạy trên một công cụ thực thi chuyên dụng. Rơle chức năng không đồng bộ được sử dụng để chia nhỏ luồng thực hiện giao dịch và di chuyển trạng thái được yêu cầu trên các công cụ thực thi khi nó nằm ở nơi khác.

p>

Điều này tách logic giao dịch khỏi phân vùng trạng thái hợp đồng, cho phép thực hiện song song vốn có mà không cần chi phí di chuyển dữ liệu. Mô hình song song của nó không chỉ phân chia trạng thái ở cấp hợp đồng thông minh, tách rời các phần phụ thuộc ở cấp phát hành dữ liệu mà còn cung cấp kiến ​​trúc cụm công cụ thực thi Đa luồng tương tự như Move. Quan trọng hơn, nó đã đưa ra một mô hình lập trình mới, PREDA một cách sáng tạo, có thể là mảnh ghép cuối cùng cho tính song song của blockchain.