chữ

Cuộc khảo sát này đã so sánh các hệ thống triển khai tương tự như Ethereum, đồng thời phân tích những khó khăn và khả năng thực hiện song song các giao dịch. Bản thân chuỗi được thiết kế dựa trên mô hình Tài khoản thay vì mô hình UTXO.

tiêu đề cấp đầu tiên

1. Nhiều chuỗi liên minh ở Trung Quốc, chẳng hạn như FISCO-BCOS, hỗ trợ thực hiện song song xác minh giao dịch bên trong khối.

2. Khipu, một dự án chuỗi công khai, là một triển khai scala của giao thức Ethereum.

3. Aptos, dự án chuỗi công khai, Di chuyển máy ảo.

tiêu đề cấp đầu tiên

Khó khăn trong việc thực hiện song song các giao dịch

Trước tiên chúng ta hãy xem lại quy trình thực hiện giao dịch truyền thống:

Mô-đun thực thi đưa ra từng giao dịch một từ khối, sau đó thực hiện từng giao dịch một. Trong quá trình thực hiện, trạng thái thế giới mới nhất sẽ được sửa đổi.Sau khi một giao dịch được thực hiện, trạng thái sẽ được tích lũy để đạt đến trạng thái thế giới mới nhất sau khi hoàn thành khối. Việc thực hiện khối tiếp theo hoàn toàn phụ thuộc vào trạng thái của thế giới sau khi thực hiện khối trước đó, do đó, quy trình thực hiện giao dịch tuyến tính truyền thống không thể được tối ưu hóa tốt để thực hiện song song.

1. Xung đột tài khoản. Nếu hai luồng xử lý số dư hoặc các thuộc tính khác của tài khoản địa chỉ cùng một lúc, liệu chúng có nhất quán với kết quả xử lý tuần tự hay không, nghĩa là trạng thái thế giới có phải là một máy trạng thái hữu hạn xác định hay không.

3. Xung đột cuộc gọi giữa các hợp đồng. Ban đầu, hợp đồng Ar được triển khai trước và hợp đồng B cần đợi cho đến khi hợp đồng A được triển khai để gọi hợp đồng A. Tuy nhiên, khi các giao dịch diễn ra song song, không có thứ tự như vậy và xảy ra xung đột.

FISCO-BCOS

tiêu đề cấp đầu tiên

So sánh các sơ đồ song song giao dịch

tiêu đề cấp đầu tiên

Tổng quan

FISCO-BCOS 2.0 sử dụng cấu trúc đồ thị trong quá trình xử lý giao dịch và thiết kế bộ thực thi giao dịch song song (PTE, Parallel Transaction Executor) dựa trên mô hình DAG. PTE có thể phát huy hết lợi thế của bộ xử lý đa lõi, để các giao dịch trong khối có thể được thực hiện song song nhiều nhất có thể. Đồng thời, nó cung cấp cho người dùng một giao diện lập trình đơn giản và thân thiện, do đó người dùng không cần quan tâm đến các chi tiết triển khai song song rườm rà. Kết quả thử nghiệm của chương trình kiểm tra điểm chuẩn cho thấy so với sơ đồ thực thi giao dịch nối tiếp truyền thống, trong điều kiện lý tưởng, PTE chạy trên bộ xử lý 4 nhân có thể đạt được mức cải thiện hiệu suất khoảng 200% ~ 300% và mức cải thiện về điện toán tương đương với số lượng lõi Theo tỷ lệ trực tiếp, càng nhiều lõi, hiệu suất càng cao.

Chi Tiết Chương Trình

Đồ thị có hướng không có chu trình được gọi là đồ thị theo chu trình có hướng (DAG). Trong một lô giao dịch, các tài nguyên loại trừ lẫn nhau do mỗi giao dịch chiếm giữ có thể được xác định theo một cách nhất định và sau đó có thể xây dựng biểu đồ DAG phụ thuộc vào giao dịch theo thứ tự giao dịch trong khối và mối quan hệ chiếm giữ của các tài nguyên loại trừ lẫn nhau . Như thể hiện trong hình bên dưới, tất cả các giao dịch có độ bằng 0 (không có tác vụ đặt hàng trước phụ thuộc) có thể được thực hiện song song. Sau khi sắp xếp cấu trúc liên kết dựa trên thứ tự của danh sách giao dịch ban đầu ở bên trái, có thể thu được DAG giao dịch ở bên phải.

kiến trúc mô-đun

• Người dùng bắt đầu giao dịch trực tiếp hoặc gián tiếp thông qua SDK.

• Sau đó, giao dịch được đồng bộ giữa các nút, và nút có quyền đóng gói gọi bộ niêm phong (Sealer) để lấy một lượng giao dịch nhất định từ (TxPool) và đóng gói thành một khối. Sau đó, khối được gửi đến đơn vị đồng thuận (Consensus) để có sự đồng thuận giữa các nút.

• Xác minh giao dịch cần được thực hiện trước khi đạt được sự đồng thuận và đây là lúc công việc của PTE bắt đầu. Như có thể thấy từ sơ đồ kiến ​​trúc, trước tiên, PTE đọc các giao dịch trong khối một cách tuần tự và nhập chúng vào Trình xây dựng DAG. Hàm tạo DAG sẽ xây dựng một DAG giao dịch chứa tất cả các giao dịch dựa trên các thành phần phụ thuộc của từng giao dịch. PTE sau đó đánh thức nhóm luồng công nhân và sử dụng nhiều luồng để thực hiện DAG giao dịch song song. Trình nối chịu trách nhiệm tạm dừng luồng chính cho đến khi tất cả các luồng trong nhóm luồng công nhân kết thúc việc thực thi DAG. Tại thời điểm này, Joiner chịu trách nhiệm tính toán gốc trạng thái và gốc nhận dựa trên các bản ghi sửa đổi trạng thái của từng cặp giao dịch và trả về kết quả thực hiện cho trình gọi cấp trên.

• Sau khi vượt qua xác minh khối, khối sẽ được tải lên chuỗi. Sau khi giao dịch được thực hiện, nếu trạng thái của mỗi nút nhất quán, sẽ đạt được sự đồng thuận. Khối này sau đó được ghi vào kho lưu trữ bên dưới (Storage) và được ghi vĩnh viễn trên chuỗi khối.

Quá trình xây dựng DAG giao dịch

1. Lấy tất cả các giao dịch của khối ra khỏi khối được đóng gói.

2. Khởi tạo phiên bản DAG với số lượng giao dịch là số đỉnh tối đa.

3. Đọc tuần tự tất cả các giao dịch. Nếu một giao dịch có thể song song hóa, hãy giải quyết miền xung đột của nó và kiểm tra xem có bất kỳ giao dịch nào trước đó xung đột với giao dịch này hay không. Nếu có xung đột, một cạnh phụ thuộc được tạo giữa các giao dịch tương ứng. Nếu giao dịch không thể được thực hiện song song, thì nó được coi là phải được thực hiện sau khi tất cả các giao dịch trước đó được thực hiện, do đó, một cạnh phụ thuộc được thiết lập giữa giao dịch này và tất cả các giao dịch trước đó.

Nhận xét: Sau khi tất cả các cạnh phụ thuộc được thiết lập, chúng không thể thực hiện song song mà chỉ có thể thực hiện tuần tự.

Quy trình thực hiện DAG

1. Trước tiên, luồng chính sẽ khởi tạo một nhóm luồng có kích thước tương ứng theo số lượng lõi phần cứng, nếu không đạt được số lượng lõi phần cứng thì sẽ không có luồng nào khác được tạo.

2. Khi DAG chưa thực thi xong, luồng sẽ lặp lại và đợi phương thức waitPop từ DAG thực hiện giao dịch sẵn sàng với độ bằng 0. Nếu giao dịch được thực hiện được thực hiện thành công, giao dịch sẽ được thực hiện và mức độ của các tác vụ phụ thuộc tiếp theo sẽ giảm đi 1 sau khi thực hiện. Nếu mức độ của giao dịch giảm xuống 0, hãy thêm giao dịch vào topLevel. Nếu thất bại, điều đó có nghĩa là DAG đã được thực thi và luồng đã thoát.

vấn đề và giải pháp

1. Đối với cùng một khối, làm thế nào để đảm bảo tất cả các nút đều được thực thi và có cùng trạng thái (ba gốc khớp nhau)?

FISCO BCOS sử dụng phương pháp xác minh xem bộ ba gốc trạng thái, gốc giao dịch và gốc nhận có bằng nhau hay không để xác định xem trạng thái có nhất quán hay không. Gốc giao dịch là một giá trị băm được tính toán dựa trên tất cả các giao dịch trong khối. Miễn là dữ liệu khối được xử lý bởi tất cả các nút đồng thuận là như nhau, thì gốc giao dịch phải giống nhau. Vì điều này tương đối dễ đảm bảo, nên trọng tâm là cách đảm bảo rằng trạng thái được tạo sau khi giao dịch được thực thi giống với trạng thái gốc của biên nhận.

Ai cũng biết rằng đối với các lệnh được thực hiện song song trên các lõi CPU khác nhau, thứ tự thực hiện giữa các lệnh không thể dự đoán trước. Điều này cũng đúng với các giao dịch được thực hiện song song. Trong sơ đồ thực hiện giao dịch truyền thống, mỗi khi một giao dịch được thực hiện, gốc trạng thái sẽ thay đổi một lần và gốc trạng thái đã thay đổi được ghi vào biên lai giao dịch. Sau khi tất cả các giao dịch được thực hiện, gốc trạng thái cuối cùng biểu thị trạng thái hiện tại của chuỗi khối và gốc biên nhận được tính dựa trên tất cả các biên lai giao dịch.

Có thể thấy rằng trong sơ đồ thực thi truyền thống, gốc trạng thái đóng vai trò tương tự như biến chia sẻ toàn cục. Khi các giao dịch được thực hiện song song và không theo thứ tự, cách tính toán gốc trạng thái truyền thống rõ ràng là không còn được áp dụng. Điều này là do thứ tự thực hiện của các giao dịch nói chung là khác nhau trên các máy khác nhau và tính nhất quán của gốc trạng thái cuối cùng không thể được đảm bảo tại thời điểm này. Tương tự, tính nhất quán của gốc biên nhận không thể được đảm bảo.Trong FISCO BCOS, các giao dịch được thực hiện song song trước và lịch sử thay đổi trạng thái của từng giao dịch được ghi lại. Sau khi tất cả các giao dịch được thực hiện, gốc trạng thái được tính toán toàn diện dựa trên các bản ghi lịch sử này. Điều này đảm bảo rằng ngay cả khi các giao dịch được thực hiện song song, các nút đồng thuận cuối cùng vẫn có thể đạt được sự đồng thuận.

2. Làm thế nào để xác định hai giao dịch có phụ thuộc nhau hay không?

Nếu hai giao dịch không có quan hệ phụ thuộc nhưng được đánh giá là phụ thuộc thì sẽ gây ra tổn thất hiệu suất không cần thiết; ngược lại, nếu hai giao dịch sẽ viết lại trạng thái của cùng một tài khoản nhưng được thực hiện song song thì trạng thái cuối cùng của tài khoản có thể không chắc chắn. . Vì vậy,

Việc xác định các yếu tố phụ thuộc là một vấn đề quan trọng ảnh hưởng đến hiệu suất và thậm chí xác định liệu chuỗi khối có thể hoạt động bình thường hay không.

Trong một giao dịch chuyển khoản đơn giản, chúng ta có thể đánh giá liệu có sự phụ thuộc giữa hai giao dịch hay không dựa trên địa chỉ của người gửi và người nhận chuyển khoản.

Lấy 3 giao dịch chuyển tiền sau đây làm ví dụ: A→B, C→D, D→E. Có thể dễ dàng nhận thấy giao dịch D→E phụ thuộc vào kết quả của giao dịch C→D, nhưng giao dịch A→B không có mối liên hệ nào với 2 giao dịch còn lại nên có thể thực hiện song song.

Phân tích này đúng trong các chuỗi khối chỉ hỗ trợ chuyển khoản đơn giản. Nhưng vì chúng tôi không thể biết chính xác những hoạt động nào trong hợp đồng chuyển nhượng do người dùng viết, nên một khi loại phân tích này được đưa vào chuỗi khối Turing hoàn chỉnh và chạy các hợp đồng thông minh, nó sẽ không đủ chính xác.

Tình huống có thể xảy ra là: Giao dịch A → B dường như không liên quan gì đến trạng thái tài khoản của C và D, nhưng trong triển khai cơ bản của người dùng, A là một tài khoản đặc biệt và mọi khoản tiền được chuyển qua tài khoản A trước tiên phải được được chuyển từ C. Một khoản phí xử lý nhất định sẽ được khấu trừ từ tài khoản. Trong trường hợp này, ba giao dịch đều có liên quan, vì vậy chúng không thể được thực hiện song song. Nếu các giao dịch cũng được phân chia theo phương pháp phân tích phụ thuộc trước đây, chắc chắn sẽ nảy sinh các vấn đề.

Vì vậy, chúng tôi có thể tự động suy ra những phụ thuộc nào thực sự tồn tại trong giao dịch dựa trên nội dung hợp đồng của người dùng không? câu trả lời là tiêu cực. Như đã đề cập trong phân tích tĩnh, rất khó để phân tích các phụ thuộc hợp đồng và quá trình thực hiện.

FISCO BCOS giao nhiệm vụ chỉ định các phụ thuộc giao dịch cho các nhà phát triển quen thuộc hơn với nội dung hợp đồng. Cụ thể, các tài nguyên loại trừ lẫn nhau mà một giao dịch phụ thuộc vào có thể được biểu diễn bằng một tập hợp các chuỗi. FISCO BCOS hiển thị giao diện cho nhà phát triển. Nhà phát triển xác định các tài nguyên mà giao dịch phụ thuộc vào dưới dạng chuỗi và thông báo cho người thực thi trên chuỗi. Người thực thi tự động sắp xếp tất cả các giao dịch trong khối thành một DAG giao dịch theo phụ thuộc giao dịch được chỉ định bởi nhà phát triển. . Ví dụ, trong một hợp đồng chuyển nhượng đơn giản, nhà phát triển chỉ cần xác định rằng phần phụ thuộc của mỗi giao dịch chuyển nhượng là {địa chỉ người gửi + địa chỉ người nhận}. Hơn nữa, nếu nhà phát triển giới thiệu một địa chỉ bên thứ ba khác trong logic chuyển, thì phần phụ thuộc cần được xác định là {địa chỉ người gửi + địa chỉ người nhận + địa chỉ bên thứ ba}.

Phương pháp này trực quan hơn và dễ thực hiện hơn, đồng thời nó cũng tổng quát hơn, áp dụng cho tất cả các hợp đồng thông minh, nhưng nó cũng làm tăng trách nhiệm lên vai các nhà phát triển theo đó. Các nhà phát triển phải rất cẩn thận khi chỉ định các phụ thuộc giao dịch, nếu các phụ thuộc không được viết chính xác, hậu quả sẽ khó lường.

Hợp đồng khung song songFISCO BCOS đã thiết lập một số thông số kỹ thuật viết hợp đồng cho các nhà phát triển để sử dụng khuôn khổ hợp đồng song song, chi tiết như sau:song songHai giao dịch có thể được thực hiện song song hay không tùy thuộc vào việc hai giao dịch đó có tồn tại hay không。

loại trừ lẫn nhau

• . Loại trừ lẫn nhau có nghĩa là hai giao dịch đượcCó một giao điểm giữa các bộ biến lưu trữ hợp đồng hoạt độngVí dụ: trong kịch bản chuyển giao, giao dịch là hoạt động chuyển giao giữa những người dùng. Sử dụng transfer(X, Y) để biểu thị giao diện truyền từ người dùng X sang người dùng Y, loại trừ lẫn nhau như sau:thông số loại trừ lẫn nhau

• :hợp đồnggiao diện

, các tham số liên quan đến thao tác "đọc/ghi" của các biến lưu trữ hợp đồng. Ví dụ: giao diện truyền là transfer(X, Y), trong đó X và Y là các tham số loại trừ lẫn nhau.

Mutex

: Trong một giao dịch, nội dung cụ thể loại trừ lẫn nhau được trích xuất theo các tham số loại trừ lẫn nhau. Ví dụ: giao diện truyền là transfer(X, Y) và trong một giao dịch gọi giao diện này, tham số cụ thể là transfer(A, B), thì đối tượng loại trừ lẫn nhau của thao tác này là [A, B]; một giao dịch khác Tham số của lệnh gọi là transfer(A, C), thì đối tượng mutex của thao tác này là [A, C].

Việc đánh giá liệu hai giao dịch có thể được thực hiện song song cùng một lúc hay không là đánh giá liệu các đối tượng loại trừ lẫn nhau của hai giao dịch có trùng nhau hay không. Các giao dịch có giao điểm với nhau là trống có thể được thực hiện song song.

FISCO-BCOS cung cấp hai cách để viết hợp đồng song song, một là hợp đồng vững chắc và hai là hợp đồng biên dịch sẵn. Chỉ có hợp đồng solidity được giới thiệu ở đây và hợp đồng được biên dịch trước cũng vậy.

khung song song hợp đồng solidity

Khi viết một hợp đồng solidity song song, về cơ bản, bạn chỉ cần sử dụng ParallelContract.sol làm lớp cơ sở của hợp đồng cần song song và gọi phương thức registerParallelFunction() để đăng ký giao diện song song.

Mã ParallelContract như sau:

• Sau đây là hợp đồng chuyển nhượng được soạn thảo dựa trên hợp đồng khung song song:

Xác định xem một giao diện có thể song song hóa được không

Một giao diện hợp đồng song song phải đáp ứng:

Không có cuộc gọi đến các hợp đồng bên ngoài.

• Không có giao diện để gọi các chức năng khác.

Xác định tham số loại trừ lẫn nhau

Trước khi viết một giao diện, bạn cần xác định các tham số loại trừ lẫn nhau của giao diện, loại trừ lẫn nhau của giao diện là loại trừ lẫn nhau của các biến toàn cục. Các quy tắc để xác định các tham số loại trừ lẫn nhau là:

• Giao diện truy cập ánh xạ toàn cục và khóa của ánh xạ là một tham số loại trừ lẫn nhau."globalA",• Giao diện truy cập mảng toàn cục và chỉ số dưới của mảng là tham số loại trừ lẫn nhau.

• Giao diện truy cập các biến toàn cục kiểu đơn giản và tất cả các biến toàn cục kiểu đơn giản chia sẻ một tham số mutex và sử dụng các tên biến khác nhau làm đối tượng mutex.Ví dụ: Có nhiều loại biến toàn cục đơn giản trong hợp đồng và các giao diện khác nhau truy cập các biến toàn cục khác nhau. Nếu bạn cần song song hóa các giao diện khác nhau, bạn cần xác định một tham số loại trừ lẫn nhau trong các tham số giao diện đã sửa đổi biến toàn cục và chỉ định biến toàn cục nào được sử dụng khi gọi. Khi gọi, hãy chủ động chuyển "tên biến" của biến toàn cục được sửa đổi tương ứng cho tham số mutex để chỉ ra đối tượng mutex của giao dịch này. Ví dụ: nếu tham số toàn cục globalA được sửa đổi trong hàm setA(int x), thì hàm setA cần được xác định là set(string aflag, int x) và khi gọi, hãy chuyển vào setA(

10), sử dụng tên biến "globalA" để chỉ ra rằng đối tượng mutex của giao dịch này là globalA.string、address、uint 256、int 256 Sau khi xác định các tham số loại trừ lẫn nhau, xác định loại tham số và thứ tự theo quy tắc, quy tắc là:

Xác định loại tham số và thứ tự

- Các tham số giao diện được giới hạn ở:

(Nhiều loại sẽ được hỗ trợ trong tương lai).- Tất cả các tham số loại trừ lẫn nhau được sắp xếp ở trên cùng của các tham số giao diện.。

Khipu

Như có thể thấy,

Trên thực tế, tính song song của giao dịch FISCO-BCOS chủ yếu dựa vào đặc điểm kỹ thuật của hợp đồng do người dùng viết. Nếu hợp đồng do người dùng viết không được chuẩn hóa và hệ thống vội vàng thực hiện nó song song, nó có thể gây ra vấn đề gốc sổ cái không nhất quán

tiêu đề cấp đầu tiên

Tổng quan

Không giống như FISCO-BCOS, Khipu tin rằng việc người dùng xác định và đánh dấu các dải địa chỉ sẽ xảy ra xung đột tĩnh khi viết hợp đồng mà không có lỗi là điều không thực tế.

Cuộc đua sẽ diễn ra hay không, ở đâu và trong những điều kiện nào chỉ có thể được đánh giá khi việc mua lại tất định liên quan đến trạng thái hiện tại. Với ngôn ngữ lập trình hợp đồng hiện tại, hầu như không thể có được kết quả hoàn toàn không có lỗi và không thiếu thông qua phân tích mã tĩnh.

Khipu đã nỗ lực toàn diện về vấn đề này và đã hoàn thành việc thực hiện dự án.

Chi Tiết Chương Trình

Khi triển khai Khipu, mỗi giao dịch trong cùng một khối bắt đầu từ trạng thái thế giới của khối trước đó, sau đó thực hiện song song, ghi lại cả ba cuộc đua trên gặp phải trên con đường trải nghiệm lý tưởng trong quá trình thực hiện. Sau khi giai đoạn thực hiện song song kết thúc, nó sẽ chuyển sang giai đoạn hợp nhất. Trong giai đoạn hợp nhất, các quốc gia trên thế giới song song được hợp nhất từng cái một, khi hợp nhất một giao dịch, trước tiên người ta sẽ đánh giá từ các điều kiện tĩnh được ghi lại xem có xung đột với điều kiện chủng tộc đã hợp nhất trước đó hay không. Nếu không, hợp nhất trực tiếp. Nếu vậy, hãy thực hiện lại giao dịch này bắt đầu từ trạng thái thế giới đã hợp nhất trước đó. Trạng thái thế giới hợp nhất cuối cùng sẽ được hoàn thiện với hàm băm của khối. Đây là tuyến phòng thủ cuối cùng, nếu xác minh sai, sơ đồ song song trước đó sẽ bị hủy bỏ và các giao dịch trong khối sẽ được thực hiện lại hàng loạt.chỉ số song song：

Khipu đã giới thiệu một chỉ số song song ở đây, tức là tỷ lệ các giao dịch trong một khối có thể hợp nhất trực tiếp các kết quả mà không cần thực hiện lại. Qua nhiều ngày quan sát phát lại trên Ethereum từ khối gốc đến khối mới nhất, Khipu nhận thấy rằng tỷ lệ này (song song) có thể đạt trung bình 80%.

Nói chung, nếu các tác vụ tính toán có thể được song song hóa hoàn toàn, thì khả năng mở rộng của một chuỗi đơn lẻ sẽ là vô hạn, bởi vì luôn có thể thêm nhiều lõi CPU vào một nút. Nếu đây không phải là trường hợp, tốc độ lý thuyết tối đa bị giới hạn bởi

định lý Andal

Giới hạn mà bạn có thể tăng tốc hệ thống là nghịch đảo của giới hạn không thể song song hóa. Nghĩa là, nếu bạn có thể song song hóa 99% thời gian, bạn có thể đạt được tốc độ tăng gấp 100 lần. Nhưng nếu bạn chỉ có thể đạt được mức song song hóa 95%, thì bạn chỉ có thể đạt được tốc độ tăng tốc 20 lần.

đánh dấu xung đột

Từ việc phát lại tất cả các giao dịch trong Ethereum, khoảng 80% giao dịch có thể được song song hóa và 20% không thể song song hóa.Do đó, hiệu quả trung bình của Khipu để tăng tốc Ethereum là khoảng 5 lần.

Thông qua việc giải thích các hướng dẫn mã evm, có thể thấy rằng mâu thuẫn là một số hướng dẫn hạn chế tạo ra quá trình đọc và ghi cho stroage, do đó, một bộ đọc và ghi có thể được hình thành bằng cách ghi lại các vị trí đọc và ghi này. Chỉ phân tích mã tĩnh không thể đảm bảo rằng các quy trình này được ghi lại, do đó, cần phải thực hiện song song trước từng giao dịch khi xử lý các giao dịch trong mỗi khối. Thông qua quy trình trước khi thực hiện, có thể biết liệu các giao dịch này có đọc và ghi vào cùng một tài khoản hoặc bộ lưu trữ hay không, sau đó tạo một readSet và writeSet cho mỗi giao dịch. Nói tóm lại, quy trình trước khi thực hiện trước tiên là tạo nhiều bản sao của trạng thái thế giới làm trạng thái ban đầu của tất cả các giao dịch. Giả sử rằng có 100 giao dịch trong chuỗi khối, thì 100 giao dịch này có thể được thực hiện song song thông qua nhóm luồng. Mỗi hợp đồng có cùng trạng thái thế giới ban đầu và 100 readSets và writeSets sẽ được tạo trong quá trình thực thi và 100 trạng thái mới sẽ được tạo cho mỗi trạng thái.

Thông qua việc phát lại giao dịch của mạng chính Ethereum, có thể thấy rằng nơi có nhiều xung đột, hầu hết là các giao dịch có liên quan đến nhau được thực hiện bởi các sàn giao dịch trong cùng một khối, điều này cũng phù hợp với quy trình này.

Aptos

Biểu đồ luồng tiến trình

Quy trình thực thi song song cụ thể

tiêu đề cấp đầu tiên

Tổng quan

Aptos đã tạo ra một chuỗi thông lượng cao dựa trên ngôn ngữ Move của Diem và MoveVM, cho phép thực thi song song. Cách tiếp cận của Aptos là phát hiện các liên kết đồng thời minh bạch với người dùng/nhà phát triển. Nghĩa là, các giao dịch không bắt buộc phải nêu rõ ràng phần nào của trạng thái (vị trí bộ nhớ) mà chúng sử dụng.

Chi Tiết Chương Trình

Aptos đã triển khai một công cụ thực thi song song dựa trên giấy Block-STM, sử dụng phiên bản sửa đổi của Bộ nhớ giao dịch phần mềm có tên là Block-STM.

Block-STM sử dụng MVCC (Kiểm soát đồng thời nhiều phiên bản) để tránh xung đột ghi-ghi. Tất cả các thao tác ghi vào cùng một vị trí được lưu trữ với các phiên bản chứa tx-id của chúng và số lần thao tác ghi tx được thực hiện lại. Khi giao dịch tx đọc giá trị của một vị trí bộ nhớ nhất định, nó sẽ nhận được giá trị được ghi vào vị trí xuất hiện trước tx từ MVCC, cũng như phiên bản được liên kết để xác định xem có xung đột đọc-ghi hay không. Trong Block-STM, các giao dịch được sắp xếp trước trong một khối và được phân chia giữa các luồng của bộ xử lý trong quá trình thực thi để thực hiện song song. Trong thực thi song song, giả sử không có phụ thuộc để thực hiện giao dịch, các vị trí bộ nhớ được sửa đổi bởi giao dịch sẽ được ghi lại. Sau khi thực hiện, tất cả các kết quả giao dịch được xác minh. Trong quá trình xác thực, nếu một giao dịch được tìm thấy để truy cập vào một vị trí bộ nhớ được sửa đổi bởi một giao dịch trước đó, thì giao dịch đó sẽ bị vô hiệu. Làm mới kết quả của giao dịch và thực hiện lại giao dịch. Quá trình này được lặp lại cho đến khi tất cả các giao dịch trong khối đã được thực hiện. Block-STM tăng tốc độ thực thi khi sử dụng nhiều lõi bộ xử lý. Tốc độ tăng tốc phụ thuộc vào mức độ phụ thuộc lẫn nhau giữa các giao dịch.

Có thể thấy rằng sơ đồ được Aptos áp dụng gần giống với Khipu đã đề cập ở trên, nhưng các chi tiết triển khai hơi khác một chút. Sự khác biệt chính như sau:

• Khipu sử dụng thực thi song song và xác minh tuần tự cho các giao dịch trong khối, trong khi Aptos sử dụng thực thi song song và xác minh song song cho các giao dịch trong khối. Cả hai lựa chọn đều có ưu điểm và nhược điểm. Kế hoạch của Khipu dễ thực hiện, nhưng kém hiệu quả hơn một chút. Việc triển khai Block-STM của Aptos sử dụng các hoạt động đồng bộ hóa và tín hiệu trong nhiều luồng, điều này khó triển khai trong mã nhưng hiệu quả hơn.

• Vì Move vốn hỗ trợ đánh địa chỉ tài nguyên toàn cầu nên Aptos sẽ sắp xếp lại các giao dịch, thậm chí trên các khối, nếu nó có lợi cho việc thực thi song song. Các quan chức tuyên bố rằng giải pháp này không chỉ có thể cải thiện hiệu quả song song mà còn giải quyết được vấn đề MEV, nhưng liệu điều này có ảnh hưởng đến trải nghiệm người dùng hay không vẫn còn phải xem xét.

điểm chuẩn

Sau khi tích hợp Block-STM, Aptos đã tạo một điểm chuẩn tương ứng và so sánh hiệu suất của một khối 10k giao dịch trong trường hợp thực thi tuần tự và thực thi song song.Kết quả như sau:

Như có thể thấy từ hình trên, Block STM đạt được tốc độ tăng gấp 16 lần so với việc thực thi tuần tự các luồng khi 32 luồng được thực thi song song, trong khi Block-STM đạt được tốc độ tăng hơn 8 lần trong các điều kiện cạnh tranh cao.

tiêu đề cấp đầu tiên

tóm tắt

Tóm lại, một số giải pháp yêu cầu người dùng ghi bộ nhớ theo các quy tắc đã thiết lập khi viết hợp đồng, để có thể tìm thấy các phụ thuộc bằng phân tích tĩnh và động. Solana và Sui có cách tiếp cận tương tự, nhưng với nhận thức của người dùng khác nhau. Các giải pháp như vậy về cơ bản là thay đổi mô hình lưu trữ để thu được kết quả phân tích tốt hơn.

Các giải pháp của Khipu và Aptos không được người dùng biết đến. Nghĩa là, người dùng không cần phải viết hợp đồng cẩn thận và máy ảo sẽ tự động phân tích các phụ thuộc trước khi thực thi, do đó sẽ không có việc thực thi song song các phụ thuộc. Loại kế hoạch này rất khó thực hiện và mức độ song song phụ thuộc ở một mức độ nhất định vào việc phân chia tài khoản của giao dịch. Khi có nhiều xung đột giao dịch, việc thực hiện lại liên tục sẽ dẫn đến suy giảm hiệu suất nghiêm trọng. Aptos đã đề cập trong bài báo rằng một số tối ưu hóa có thể được thực hiện cho các hợp đồng do người dùng viết trong tương lai, để phân tích các phụ thuộc tốt hơn và đạt được tốc độ thực thi nhanh hơn.

Xem xét các vấn đề về triển khai kỹ thuật và hiệu quả, OlaVM rất có thể sẽ áp dụng giải pháp mô hình lưu trữ tùy chỉnh Khipu+. Trong khi cải thiện hiệu suất, hãy tránh sự phức tạp do giới thiệu Block-STM mang lại và tạo điều kiện tối ưu hóa kỹ thuật tốt hơn trong giai đoạn sau.

2.FISCO-BCOS Github, FISCO-BCOS

3.Khipu Github, GitHub - khipu-io/khipu: An enterprise blockchain platform based on Ethereum

4.Aptos Github, GitHub - aptos-labs/aptos-core: Aptos is a layer 1 blockchain built to support the widespread use of of blockchain through better technology and user experience.

tham khảo:

1. Bài viết về Block-STM: [ 2203.06871 ] Block-STM: Mở rộng quy mô thực thi chuỗi khối bằng cách biến lời nguyền đặt hàng thành lời chúc phúc về hiệu suất (arxiv.org)

tiêu đề cấp đầu tiên

về chúng tôi

Sin7y được thành lập vào năm 2021 và bao gồm các nhà phát triển chuỗi khối hàng đầu. Chúng tôi vừa là vườn ươm dự án vừa là nhóm nghiên cứu công nghệ chuỗi khối, khám phá các công nghệ tiên tiến và quan trọng nhất như EVM, Lớp 2, chuỗi chéo, điện toán bảo mật và các giải pháp thanh toán tự động. Nhóm đã ra mắt sách trắng OlaVM vào tháng 7 năm 2022, nhằm xây dựng ZKVM nhanh, có thể mở rộng và tương thích với EVM đầu tiên.

Tài khoản công khai WeChat: Sin 7 y

Trang web chính thức: https://sin 7 y.org/

Sách trắng: https://olavm.org/

Github：Sin 7 y

Cộng đồng: http://t.me/sin 7 y_labs