Nghiên cứu về Thực thi song song: Mọi thứ bạn cần biết

lời nói đầu

Nghiên cứu này so sánh các hệ thống triển khai tương tự như Ethereum và phân tích những khó khăn cũng như khả năng đạt được việc thực hiện song song các giao dịch.

Cần lưu ý rằng các chuỗi được phân tích cho nghiên cứu này dựa trên sơ đồ thiết kế mô hình Tài khoản, không bao gồm sơ đồ UTXO.

Đối tượng nghiên cứu

1. FISCO-BCOS, một trong những chuỗi khối của tập đoàn hỗ trợ thực hiện song song việc xác minh giao dịch trong các khối.

   
   

2. Chuỗi công khai Khipu, triển khai scala của giao thức Ethereum.

   
   

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

Khó khăn với việc thực thi song song

Chúng ta hãy xem quy trình thực hiện giao dịch truyền thống.

Mô-đun thực thi lấy từng giao dịch ra khỏi khối và thực hiện tuần tự.

Trạng thái thế giới mới nhất sẽ được sửa đổi trong quá trình thực thi và sau đó trạng thái sẽ được cộng lại sau khi hoàn thành giao dịch để đạ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 thi khối tiếp theo hoàn toàn phụ thuộc vào trạng thái thế giới từ khối hiện tại/khối trước đó, do đó, quy trình thực thi đơn luồng, tuần tự này không phù hợp lắm để thực thi song song.

Dưới đây là những xung đột chính trong các phương thức thực thi song song Ethereum hiện tại:

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, làm cách nào để chúng tôi đảm bảo rằng nó nhất quán với kết quả xử lý tuần tự, 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 không?

2. Xung đột lưu trữ của cùng một địa chỉ : trong đó cả hai hợp đồng đã sửa đổi lưu trữ của cùng một biến toàn cầu.

   
   

3. Xung đột cuộc gọi hợp đồng chéo: Nếu hợp đồng A được triển khai trước, hợp đồng B cần đợi cho đến khi việc triển khai hợp đồng A hoàn tất để gọi hợp đồng A. Tuy nhiên, khi các giao dịch song song, không có trình tự như vậy, dẫn đến xung đột.

Đề án thực thi song song

FISCO-BCOS

trừu tượng

FISCO-BCOS 2.0 sử dụng cấu trúc đồ thị trong xử lý giao dịch. Các nhà phát triển đã thiết kế Trình thực thi giao dịch song song (PTE) dựa trên mô hình Đồ thị theo chu kỳ có hướng (DAG).

PTE có thể giúp bạn tận dụng triệt để các ưu điểm 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 ở mức có thể.

Đồng thời, nó cung cấp một giao diện lập trình đơn giản và thân thiện cho người dùng, do đó người dùng không phải quan tâm đến các chi tiết tẻ nhạt của việc triển khai song song.

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, PTE chạy trên bộ xử lý 4 nhân trong điều kiện lý tưởng có thể cải thiện hiệu suất khoảng 200% ~ 300% và cải thiện tính toán tỷ lệ thuận với số của lõi.

Càng nhiều lõi, hiệu năng càng tốt.

Đề án chung

Đồ thị có hướng theo chu kỳ thường được gọi là Đồ thị theo chu kỳ 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 xác định; sau đó một DAG phụ thuộc vào giao dịch được xây dựng theo trình tự các giao dịch trong khối và mối quan hệ chiếm đóng 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ó mức độ gửi đến là 0 (không có tác vụ đặt hàng trước phụ thuộc) có thể được thực hiện song song. DAG giao dịch ở bên phải có thể thu được bằng cách sắp xếp tô pô dựa trên thứ tự của danh sách giao dịch ban đầu ở bên trá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ộ hóa giữa các nút và nút có cùng quyền đóng gói sẽ gọi Sealer (TxPool) để lấy một lượng giao dịch nhất định từ (txpool) và đóng gói chúng thành một khối. Sau đó, các khối được gửi đến đơn vị Đồng thuận để chuẩn bị cho sự đồng thuận giữa các nút.

• Xác thực giao dịch được thực hiện trước khi đạt được sự đồng thuận và đây là lúc PTE bắt đầu quy trình làm việc của mình. 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 theo thứ tự và nhập chúng vào Trình xây dựng DAG, công cụ này sẽ xây dựng một DAG giao dịch chứa tất cả các giao dịch theo sự phụ thuộc của từng giao dịch. PTE sau đó đánh thức nhóm công nhân. Sử dụng nhiều luồng để thực hiện giao dịch DAG song song. Trình tham gia tạm dừng luồng chính cho đến khi DAG được thực thi bởi tất cả các luồng trong nhóm công nhân. Tại thời điểm này, Joiner tính toán gốc trạng thái và gốc nhận dựa trên bản ghi sửa đổi trạng thái của từng giao dịch và trả lại kết quả cho người gọi ở cấp trên.

• Sau khi khối được xác minh, khối được tải lên chuỗi. Sau khi một 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 và khối này sau đó được ghi vào bộ lưu trữ cơ bản, được ghi vĩnh viễn trên chuỗi khối.

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

1. Lấy tất cả các giao dịch trong khối từ 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 tất cả các giao dịch theo thứ tự. Nếu một giao dịch có thể hợp nhất, hãy giải quyết trường xung đột của giao dịch đó và kiểm tra xem có giao dịch nào trước đó xung đột với giao dịch đó không. Nếu vậy, hãy xây dựng một cạnh phụ thuộc giữa các giao dịch tương ứng. Nếu giao dịch không thể hợp nhất, 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 tạo giữa giao dịch và tất cả các giao dịch trước đó.

Lưu ý : Khi tất cả các cạnh phụ thuộc đã được tạo, chúng không thể được hợp nhất và chỉ có thể được thực hiện tuần tự.

Quy trình thực thi DAG

1. Trước tiên, luồng chính sẽ khởi tạo một nhóm nhỏ các luồng dựa trên số lượng lõi phần cứng và nếu lõi phần cứng bị lỗi, sẽ không có luồng nào khác được tạo.

   
   

2. Khi DAG chưa hoàn thành, vòng lặp luồng sẽ chờ giao dịch sẵn sàng với mức độ bằng 0 được lấy ra từ phương thức waitPop của DAG. 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. Nếu không thành công, DAG đã hoàn thành 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 để chúng tôi đảm bảo rằng tất cả các nút đã thực hiện xong và ở cùng một trạng thái (ba nút gốc khớp nhau)?

FISCO BCOS xác minh rằng các bộ ba, tức là gốc trạng thái, gốc giao dịch và gốc biên nhận, có bằng nhau để xác định xem các trạng thái có được thỏa thuận hay không. Gốc giao dịch là giá trị băm được tính dựa trên tất cả các giao dịch trong khối.

Miễn là tất cả các nút đồng thuận xử lý cùng một dữ liệu khối, gốc giao dịch phải giống nhau, điều này tương đối dễ đảm bảo. Điều quan trọng là đảm bảo rằng trạng thái và gốc nhận được tạo sau khi giao dịch giống nhau.

Ai cũng biết rằng không thể dự đoán trước thứ tự thực hiện giữa các lệnh được thực hiện song song trên các lõi CPU khác nhau và điều này cũng đúng đối với các giao dịch được thực hiện song song.

Trong sơ đồ thực thi giao dịch truyền thống, gốc trạng thái thay đổi sau mỗi giao dịch được thực hiện và gốc trạng thái đã thay đổi được ghi vào biên nhận 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. Đồng thời, 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 cách triển khai truyền thống, gốc trạng thái hoạt động như một biến được chia sẻ toàn cầu.

Khi các giao dịch được thực hiện song song và không theo thứ tự, cách tính gốc trạng thái truyền thống không còn áp dụng được nữa vì các giao dịch được thực hiện theo một thứ tự khác trên các máy khác nhau và gốc trạng thái cuối cùng không được đảm bảo nhất quán, cũng như gốc nhận được không được đảm bảo để phù hợp.

Trong FISCO BCOS, các giao dịch lần đầu tiên được thực hiện song song và lịch sử thay đổi trạng thái của mỗi 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 dựa trên lịch sử.

Đồng thời, gốc trạng thái trong xác nhận giao dịch trở thành gốc trạng thái cuối cùng sau khi tất cả các giao dịch đã được thực hiện, do đó đảm bảo rằng các nút đồng thuận vẫn có thể đạt được thỏa thuận ngay cả khi các giao dịch được thực hiện song song.

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

Nếu hai giao dịch không phụ thuộc nhưng được đánh giá là phụ thuộc thì sẽ dẫn đến giảm hiệu suất không cần thiết. Ngược lại, nếu cả hai giao dịch 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.

Do đó, việc xác định tính phụ thuộc là một vấn đề quan trọng ảnh hưởng đến hiệu suất và thậm chí có thể 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 tiền đơn giản, chúng ta có thể đánh giá liệu hai giao dịch có phụ thuộc vào địa chỉ của người gửi và người nhận hay không. Lấy ba giao dịch chuyển tiền sau đây làm ví dụ, A→B, C→D và D→E.

Dễ 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 liên quan gì đến 2 giao dịch còn lại nên có thể thực hiện song song.

Loại phân tích này đúng trong một chuỗi khối chỉ hỗ trợ chuyển khoản đơn giản, nhưng nó có thể không chính xác trong chuỗi khối hoàn chỉnh Turing chạy hợp đồng thông minh, bởi vì chúng tôi không biết chính xác điều gì đang diễn ra trong hợp đồng chuyển nhượng do người dùng viết . Đây là những gì có thể xảy ra.

Có vẻ như giao dịch của A → B 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ột khoản phí nhất định phải được khấu trừ từ tài khoản của C cho mọi khoản tiền được chuyển qua tài khoản của A.

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 phân chia theo phương pháp phân tích phụ thuộc trước đây, chắc chắn sẽ gây ra sai lầm.

Chúng tôi có thể tự động suy ra những yếu tố phụ thuộc nào thực sự tồn tại trong một 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à không. Như đã đề cập trước đó, rất khó để phân tích các phụ thuộc hợp đồng và quy trình thực hiện trong phân tích tĩnh.

Trong FISCO BCOS, việc chỉ định các phụ thuộc thương mại được dành 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à 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, người xác định các tài nguyên mà giao dịch phụ thuộc vào ở dạng chuỗi và thông báo cho người thực thi trên chuỗi.

Người thực thi sẽ tự động sắp xếp tất cả các giao dịch trong khối vào DAG giao dịch theo các phụ thuộc giao dịch do nhà phát triển chỉ định.

Ví dụ: trong một hợp đồng chuyển nhượng đơn giản, nhà phát triển chỉ cần chỉ định rằng phần phụ thuộc cho 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}.

Cách tiếp cận này trực quan, đơn giản và chung chung và á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 đối với nhà phát triển.

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ả là khó lường.

Hợp đồng khung song song

Để các nhà phát triển sử dụng khuôn khổ hợp đồng song song, FISCO BCOS đã thiết lập một số thông số kỹ thuật để viết hợp đồng. Các thông số kỹ thuật như sau:

Song song loại trừ lẫn nhau

Việc hai 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ó loại trừ lẫn nhau hay không. Loại trừ lẫn nhau đề cập đến giao điểm của tập hợp các biến lưu trữ của hai giao dịch.

Ví dụ: trong kịch bản chuyển giao tài sản, giao dịch là hoạt động chuyển giao giữa những người dùng. transfer(X, Y) đại diện cho giao diện chuyển từ người dùng X sang người dùng Y và loại trừ lẫn nhau như sau.

• Tham số loại trừ lẫn nhau: Tham số liên quan đến thao tác “đọc/ghi” của biến lưu trữ hợp đồng trong giao diện hợp đồng. Lấy ví dụ chuyển giao diện chuyển giao (X, Y). X và Y là các tham số loại trừ lẫn nhau.

  
  

• Mutex: Nội dung mutex cụ thể được trích xuất từ ​​một giao dịch theo các tham số mutex. Lấy ví dụ chuyển giao diện chuyển giao (X, Y). Trong giao dịch chuyển A sử dụng giao diện này, tham số cụ thể là chuyển (A, B) và đột biến của thao tác này là [A, B]. Đối với một giao dịch khác, transfer(A, C) được gọi và mutex cho hoạt động này là [A, C].

Để xác định xem hai giao dịch có thể được thực hiện song song cùng một lúc hay không là xác định xem giao điểm của hai giao dịch có giao nhau hay không. Các giao dịch có giao điểm trống có thể được thực hiện song song.

FFISCO-BCOS cung cấp hai cách để viết hợp đồng song song, hợp đồng biên dịch sẵn và hợp đồng solidity, chỉ những cách sau được mô tả ở đây. Điều tương tự cũng xảy ra với các hợp đồng được soạn sẵn.

Khung song song hợp đồng Solidity

Để viết một hợp đồng solidity song song, trên hết, chỉ cần đặtParallelContract.sol lớp cơ sở cho các hợp đồng bạn muốn song song. Phương thức registerParallelFunction() được gọi để đăng ký các giao diện có thể được song song hóa.

Mã hợp đồng song song như sau:

 pragma solidity ^0.4.25; //Precompile the contract interface contract ParallelConfigPrecompiled { function registerParallelFunctionInternal(address, string, uint256) public returns (int); function unregisterParallelFunctionInternal(address, string) public returns (int); } //The parallel contract base class needs to be registered and the subcontract needs to be implement enable or disable interface contract ParallelContract { ParallelConfigPrecompiled precompiled = ParallelConfigPrecompiled(0x1006); function registerParallelFunction(string functionName, uint256 criticalSize) public { precompiled.registerParallelFunctionInternal(address(this), functionName, criticalSize); } function unregisterParallelFunction(string functionName) public { precompiled.unregisterParallelFunctionInternal(address(this), functionName); } function enableParallel() public; function disableParallel() public; }

Ví dụ sau đây là hợp đồng chuyển nhượng được viết dựa trên hợp đồng khung song song:

 pragma solidity ^0.4.25; import "./ParallelContract.sol"; // Introduce ParallelContract.sol contract ParallelOk is ParallelContract // useParallelContract as a base class { // Contract implementation mapping (string => uint256) _balance; // Global mapping // The mutually exclusive variables from and to are the first two parameters at the beginning of transfer (). It can be seen that the contract requirements are still very strict, which will make users uncomfortable to write function transfer(string from, string to, uint256 num) public { _balance[from] -= num; // From is the key of the global mapping, and is a mutually exclusive parameter _balance[to] += num; //// To is the key of the global mapping, and is a mutually exclusive parameter } // The mutex variable name comes first as an argument to the beginning of set() function set(string name, uint256 num) public { _balance[name] = num; } function balanceOf(string name) public view returns (uint256) { return _balance[name]; } // Register contract interfaces that can be parallel function enableParallel() public { // The function definition string (note that there are no Spaces after ",") and the first few arguments are mutex arguments (mutex arguments must be first when designing a function) //The number 2 indicates that the first two are mutex parameters, and the system decodes the mutex according to the function signature and abi registerParallelFunction("transfer(string,string,uint256)", 2); // critical: string string // registerParallelFunction("set(string,uint256)", 1); // critical: string } // Deregister the parallel contract interface function disableParallel() public { unregisterParallelFunction("transfer(string,string,uint256)"); unregisterParallelFunction("set(string,uint256)"); } }

Xác định xem giao diện có thể song song không

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

• Không có hợp đồng bên ngoài được gọi.
• Không có giao diện chức năng nào khác được gọi.

Xác định tham số Mutex

Trước khi lập trình giao diện, hãy xác định các tham số loại trừ lẫn nhau của giao diện. Các tham số loại trừ lẫn nhau của giao diện loại trừ lẫn nhau đối với 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 như sau:

• Nếu ánh xạ toàn cầu được truy cập bởi giao diện, khóa của ánh xạ là tham số loại trừ lẫn nhau.

• Nếu mảng toàn cục được truy cập bởi giao diện, chỉ số dưới của mảng là tham số loại trừ lẫn nhau.

• Nếu giao diện truy cập các biến toàn cục thuộc loại đơn giản. Tất cả các biến toàn cục của một loại đơ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.

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

Sau khi xác định các tham số loại trừ lẫn nhau, hãy xác định loại tham số và thứ tự theo quy tắc. Luật như sau:

• Các tham số giao diện được giới hạn ở chuỗi, địa chỉ, uint256 và int256 (nhiều loại hơn sẽ được hỗ trợ trong tương lai).

• Tất cả các thông số loại trừ lẫn nhau phải xuất hiện trong các thông số giao diện.

• Tất cả các tham số loại trừ lẫn nhau đều ở vị trí đầu tiên của tham số giao diện.

Có thể thấy rằng giao dịch song song của FISCO-BCOS phần lớn phụ thuộc vào thông số kỹ thuật của hợp đồng do người dùng viết.

Nếu các thông số kỹ thuật của hợp đồng do người dùng viết không được chuẩn hóa, hệ thống sẽ vội vàng thực hiện song song, điều này có thể gây ra sự không nhất quán gốc rễ của sổ sách kế toán.

Khipu

trừu tượng

Khipu tin rằng việc người dùng xác định và gắn nhãn phạm vi địa chỉ sẽ tạo ra xung đột tĩnh tại thời điểm viết hợp đồng mà không có lỗi là không thực tế. Điều này trái ngược với quan điểm của FISCO-BCOS.

Chỉ có thể đánh giá điều kiện đua sẽ xuất hiện ở đâu, ở đâu và trong những điều kiện nào khi việc đạt được mức độ chắc chắn liên quan đến trạng thái hiện tại.

Loại phán đoán này, với các ngôn ngữ lập trình hợp đồng hiện tại, khiến cho việc phân tích mã tĩnh hầu như không thể có được kết quả hoàn toàn chính xác và không bị bỏ sót.

Khipu đã thực hiện một nỗ lực toàn diện hơn để giải quyết vấn đề này và đã hoàn thành một quy trình để thực hiện nó.

Đề án chung

Trong 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 ba điều kiện chủng tộc trên gặp phải dọc theo tất cả các lộ trình trải nghiệm lý tưởng trong quá trình thực hiện.

Tiếp theo giai đoạn thực hiện song song là giai đoạn hợp nhất, khi các trạng thái 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 hãy đánh giá xem bạn có xung đột với các điều kiện cuộc đua đã hợp nhất trước đó từ các điều kiện tĩnh được ghi lại hay không.

Nếu không, hợp nhất trực tiếp. Nếu vậy, giao dịch được thực hiện lại bắt đầu với trạng thái trước đó của thế giới đã được hợp nhất.

Trạng thái thế giới hợp nhất cuối cùng được kiểm tra dựa trên hàm băm của khối. Đây là tuyến phòng thủ cuối cùng. Nếu kiểm tra không chính xác, quá trình hợp nhất trước đó sẽ bị hủy bỏ và khối được thực thi lại.

Chỉ số song song

Ở đây, Khipu giới thiệu một chỉ số về tính song song, đề cập đến tỷ lệ các giao dịch trong một khối có thể kết hợp trực tiếp các kết quả mà không cần phải thực hiện lại.

Quan sát của Khipu về việc phát lại Ethereum trong vài ngày từ khối tạo đến khối mới nhất cho thấy tỷ lệ này (song song) có thể đạt trung bình 80%.

Nói chung, nếu các tác vụ điện 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ẻ là vô hạn. Bởi vì bạn luôn có thể thêm nhiều lõi CPU hơn vào một nút. Nếu đây không phải là trường hợp, thì 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 phụ thuộc vào sự tương hỗ của các phần không thể song song hóa. Vì vậy, nếu bạn có thể song song 99%, bạn có thể tăng tốc lên 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ể nhanh hơn tối đa 20 lần.

Trong số tất cả các giao dịch trên Ethereum, khoảng 80% có thể được thực hiện song song và 20% không thể, do đó, giới hạn tốc độ của Khipu là khoảng 5 lần.

Dấu hiệu xung đột

Khi tìm hiểu các lệnh trong mã evm, người ta thấy rằng một số lượng hạn chế các lệnh đã tạo ra các quá trình đọc và ghi cho bộ lưu trữ, vì vậy có thể ghi lại các quá trình đọc và ghi này để tạo thành một bộ sưu tập đọc và ghi các mã tĩnh. phân tích không thể đảm bảo rằng các quá trình này đã được ghi lại.

Do đó, cần phải thực hiện trước mỗi giao dịch một lần khi xử lý từng khối. Quá trình trước khi thực hiện cho chúng tôi biết liệu các giao dịch có được đọc và ghi vào cùng một tài khoản hoặc bộ lưu trữ hay không và tạo một readSet và writeSet cho mỗi giao dịch.

Nếu 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, cũng như 100 trạng thái mới mỗi trạng thái.

Khi quá trình tiền xử lý kết thúc, giai đoạn xử lý tiếp theo bắt đầu. Lý tưởng nhất là nếu 100 mục readSet và writeSet không xung đột, thì chúng có thể được hợp nhất trực tiếp để tạo ra trạng thái thế giới cuối cùng của tất cả các giao dịch trong khối. Tuy nhiên, giao dịch thường không lý tưởng như vậy.

Cách giải quyết chính xác là so sánh readSet và writeSet sau khi thực hiện giao dịch đầu tiên với readSet và writeSet sau khi thực hiện hợp đồng thứ hai và xem liệu chúng có đọc và ghi cùng một tài khoản hoặc bộ nhớ hay không.

Nếu vậy, điều đó có nghĩa là hai thỏa thuận đang xung đột. Sau đó, giao dịch thứ hai sẽ bắt đầu sau khi hoàn thành giao dịch đầu tiên và sẽ được thực hiện lại.

Tương tự, khi máy trạng thái hợp nhất tiếp tục, tập hợp xung đột sẽ tiếp tục tích lũy và miễn là các giao dịch tiếp theo xung đột với các giao dịch trước đó, chúng sẽ được thực hiện tuần tự cho đến khi tất cả các giao dịch được thực hiện.

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

Quy trình chung

Quá trình song song cụ thể

Aptos

trừu tượng

Aptos được xây dựng trên ngôn ngữ Move của Diem và MoveVM để tạo ra một chuỗi thông lượng cao 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.

Đề án chung

Aptos sử dụng phiên bản sửa đổi của bộ nhớ giao dịch Phần mềm được gọi là Block-STM và triển khai công cụ thực thi song song của nó dựa trên 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ữ cùng 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 một giao dịch (tx) đọc một giá trị cho một vị trí bộ nhớ, nó sẽ nhận giá trị được ghi từ MVCC vào vị trí đó xảy ra trước tx cùng với 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 các khối và được phân chia giữa các luồng xử lý để thực hiện song song trong quá trình thực thi. Trong thực thi song song, giả định rằng 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 được ghi lại. Sau khi thực hiện, xác minh tất cả các kết quả giao dịch. 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 đó không hợp lệ.

Làm mới kết quả của giao dịch, sau đó 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ý. Sự tăng tốc phụ thuộc vào mức độ phụ thuộc lẫn nhau của các giao dịch.

Có thể thấy rằng lược đồ mà Aptos sử dụng gần giống với Khipu đã đề cập ở trên, nhưng có một số khác biệt trong cách triển khai, được trình bày chi tiết 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. Tuy nhiên, Aptos triển khai thực thi và xác minh song song cho các giao dịch trong khối. Hai kế hoạch này có ưu điểm và nhược điểm. Khipu rất dễ thực hiện và hiệu quả thấp hơn một chút. Thông qua Block-STM, Aptos sử dụng hoạt động đồng bộ hóa và tín hiệu trong nhiều luồng, hiệu quả cao nhưng khó triển khai mã.

• Vì Move hỗ trợ đánh địa chỉ tài nguyên toàn cầu một cách nguyên bản nên Aptos sẽ sắp xếp lại các giao dịch, thậm chí trên các khối, khi nó có lợi cho việc thực thi song song. Aptos tuyên bố rằng sơ đồ này không chỉ có thể cải thiện hiệu quả của song song mà còn giải quyết vấn đề MEV. Tuy nhiên, 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.

• Aptos lưu tập hợp ghi kết quả trong bộ nhớ trong khi thực thi để có tốc độ thực thi tối đa và sau đó sử dụng nó làm bộ nhớ đệm cho khối tiếp theo sẽ được thực thi. Mọi thao tác ghi lặp lại chỉ cần được ghi một lần vào bộ nhớ ổn định.

Kiểm tra điểm chuẩn

Aptos đã thực hiện một điểm chuẩn tương ứng sau khi tích hợp khối-STM và so sánh giữa thực thi tuần tự và thực thi song song của một Khối giao dịch 10k. Kết quả so sánh được thể hiện như sau:

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

Phần kết luận

Dựa trên so sánh và phân tích ở trên, có thể kết luận rằng một số lược đồ 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 sử dụng các kế hoạch tương tự, nhưng nhận thức của người dùng là khác nhau. Đề án này về cơ bản là một sự thay đổi mô hình lưu trữ để có được kết quả phân tích tốt hơn.

Khipu và Aptos là các chương trình bất khả tri của người dùng. Các nhà phát triển không cần phải suy nghĩ về điều này khi viết hợp đồng.

Máy ảo phân tích động các mối quan hệ phụ thuộc trước khi thực hiện, do đó thực hiện thực thi song song mà không có mối quan hệ phụ thuộc.

Điều này rất khó thực hiện và mức độ song song phụ thuộc ở một mức độ nào đó 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, hiệu suất sẽ giảm đáng kể do liên tục thực hiện lại.

Aptos đã đề cập rằng họ sẽ tối ưu hóa các hợp đồng do người dùng tạo trong tương lai để phân tích các phụ thuộc tốt hơn và do đó đạt được hiệu suất thực thi nhanh hơn.

Chỉ cần sửa đổi sơ đồ dựa trên nối tiếp thành sơ đồ song song có thể mang lại sự cải thiện thông lượng giao dịch gấp 3 ~ 16 lần trong môi trường chuỗi công cộng và nếu điều đó có thể được kết hợp với các khối lớn và giới hạn gas lớn, thì thông lượng L2 sẽ được tối ưu hóa hơn nữa, có khả năng là khoảng 100 lần.

Từ góc độ kỹ thuật, liên quan đến việc triển khai và hiệu quả, OlaVM rất có thể sẽ áp dụng sơ đồ Khipu cộng với giải pháp mô hình lưu trữ tùy chỉnh, có thể cải thiện hiệu suất đồng thời tránh sự phức tạp do giới thiệu Block-STM gây ra và tạo điều kiện tối ưu hóa kỹ thuật tốt hơn.

Người giới thiệu

1. FISCO-BCOS Github, FISCO-BCOS
2. Khipu GitHub, GitHub - khipu-io/khipu: Nền tảng chuỗi khối doanh nghiệp dựa trên Ethereum
3. Aptos GitHub, GitHub - aptos-labs/aptos-core: Aptos là chuỗi khối lớp 1 được xây dựng để hỗ trợ việc sử dụng rộng rãi chuỗi khối thông qua công nghệ và trải nghiệm người dùng tốt hơn.

Về chúng tôi

Được thành lập vào năm 2021 và được hỗ trợ bởi các nhà phát triển chuỗi khối hàng đầu, Sin7y là một nhóm nghiên cứu công nghệ chuỗi khối và vườn ươm dự án khám phá các công nghệ tiên tiến và quan trọng nhất, bao gồm EVM, Layer2, chuỗi chéo, điện toán bảo mật, giải pháp thanh toán tự trị, v.v. .

Chúng tôi hiện đang làm việc trên một ZKVM tương thích với EVM, nhanh và có thể mở rộng được gọi là OlaVM. Nếu bạn muốn nói chuyện với chúng tôi, vui lòng tham gia nhóm TG của chúng tôi hoặc gửi email cho chúng tôi theo địa chỉ [email protected] .