
Giải mã vạn từ về EVM song song: Làm cách nào phá vỡ điểm nghẽn hiệu năng blockchain?
Tuyển chọn TechFlowTuyển chọn TechFlow

Giải mã vạn từ về EVM song song: Làm cách nào phá vỡ điểm nghẽn hiệu năng blockchain?
EVM song song là một câu chuyện mới xuất hiện khi khối lượng giao dịch trên chuỗi phát triển đến một mức độ nhất định.
Tác giả: @leesper6
Giáo viên hướng dẫn: @CryptoScott_ETH
TL;DR
-
EVM song song là một câu chuyện mới xuất hiện khi khối lượng giao dịch trên chuỗi phát triển đến một mức độ nhất định. EVM song song chủ yếu được chia thành blockchain đơn thể và blockchain mô-đun. Blockchain đơn thể lại được chia thành L1 và L2. Các chuỗi công cộng L1 song song được chia thành hai phe chính: EVM và phi EVM. Hiện tại, câu chuyện về EVM song song đang ở giai đoạn đầu phát triển;
-
Phân tích đường đi thực hiện kỹ thuật của EVM song song, chủ yếu bao gồm hai khía cạnh: máy ảo và cơ chế thực thi song song. Trong ngữ cảnh blockchain, máy ảo đề cập đến một máy ảo tiến trình mô phỏng máy trạng thái phân tán, dùng để thực thi hợp đồng;
-
Thực thi song song nghĩa là tận dụng lợi thế của bộ xử lý đa nhân, cố gắng thực hiện nhiều giao dịch cùng lúc càng nhiều càng tốt, trong khi vẫn đảm bảo trạng thái cuối cùng giống với kết quả khi thực thi tuần tự;
-
Cơ chế thực thi song song được chia thành ba loại lớn: truyền tin nhắn, bộ nhớ chung và danh sách truy cập trạng thái nghiêm ngặt. Bộ nhớ chung lại được chia thành mô hình khóa bộ nhớ và tối ưu hóa lạc quan. Bất kể cơ chế nào cũng làm tăng độ phức tạp kỹ thuật;
-
Câu chuyện về EVM song song vừa có động lực nội tại từ sự tăng trưởng ngành, vừa đòi hỏi các chuyên gia phải đặc biệt chú ý đến những vấn đề an toàn tiềm tàng;
-
Các dự án EVM song song đều đưa ra các ý tưởng thực thi song song theo cách riêng, vừa có điểm chung về mặt kỹ thuật, vừa có những đóng góp độc đáo riêng.
1. Tổng quan ngành
1.1 Lịch sử phát triển
Hiệu suất đã trở thành nút thắt cản trở sự phát triển tiếp theo của ngành. Mạng blockchain đã tạo ra một nền tảng niềm tin phi tập trung mới cho việc giao dịch giữa cá nhân và doanh nghiệp.
Đại diện cho thế hệ blockchain đầu tiên, Bitcoin đã mở ra một mô hình giao dịch tiền điện tử phi tập trung hoàn toàn mới thông qua sổ cái phân tán, cách mạng hóa một kỷ nguyên mới. Đại diện cho thế hệ blockchain thứ hai, Ethereum đã phát huy trí tưởng tượng, đề xuất cách thức ứng dụng phi tập trung (dApp) thông qua máy trạng thái phân tán.
Kể từ đó, mạng blockchain bắt đầu hành trình phát triển nhanh chóng kéo dài hàng chục năm, từ hạ tầng Web3 đến vô số lĩnh vực đại diện như DeFi, NFT, mạng xã hội và GameFi, sinh ra vô số đổi mới cả về công nghệ lẫn mô hình kinh doanh. Sự phát triển mạnh mẽ của ngành đòi hỏi liên tục thu hút người dùng mới tham gia vào xây dựng hệ sinh thái dApp, điều này ngược lại đặt ra yêu cầu cao hơn về trải nghiệm sản phẩm.
Web3, với tư cách là một dạng sản phẩm "chưa từng có", không chỉ cần đổi mới để đáp ứng nhu cầu người dùng (yêu cầu chức năng), mà còn phải cân bằng giữa tính an toàn và hiệu suất (yêu cầu phi chức năng). Kể từ khi ra đời, con người đã đề xuất nhiều giải pháp khác nhau nhằm giải quyết vấn đề hiệu suất.
Những giải pháp này có thể được chia thành hai nhóm lớn: một là các giải pháp mở rộng trên chuỗi như phân mảnh (sharding) và đồ thị có hướng không chu trình (DAG); hai là các giải pháp mở rộng ngoài chuỗi như Plasma, mạng lưới sét (lightning network), sidechain và Rollups. Tuy nhiên, điều này vẫn chưa theo kịp tốc độ tăng trưởng nhanh chóng của giao dịch trên chuỗi.
Đặc biệt sau đợt bùng nổ DeFi mùa hè năm 2020 và sự bùng nổ liên tục của inscription trong hệ sinh thái Bitcoin cuối năm 2023, ngành công nghiệp cấp thiết cần các giải pháp nâng cao hiệu suất mới để đáp ứng yêu cầu "hiệu suất cao, phí thấp". Blockchain song song ra đời trong bối cảnh như vậy.

1.2 Quy mô thị trường
Câu chuyện EVM song song đánh dấu sự hình thành cục diện cạnh tranh hai phe mạnh trong lĩnh vực blockchain song song. Ethereum xử lý giao dịch theo kiểu tuần tự, các giao dịch phải được thực thi lần lượt theo thứ tự, tỷ lệ sử dụng tài nguyên không cao. Nếu chuyển phương thức xử lý tuần tự sang xử lý song song sẽ mang lại bước nhảy vọt về hiệu suất.
Các đối thủ cạnh tranh của Ethereum như Solana, Aptos và Sui đều sở hữu khả năng xử lý song song, hệ sinh thái cũng phát triển rất tốt, vốn hóa lưu hành đạt lần lượt 45 tỷ, 3,3 tỷ và 1,9 tỷ USD, họ tạo thành phe phi EVM song song. Trước thách thức này, hệ sinh thái Ethereum cũng không chịu thua kém, lần lượt đứng lên bổ sung sức mạnh cho EVM, hình thành nên phe EVM song song.
Sei tuyên bố đầy tự tin trong đề xuất nâng cấp phiên bản v2 rằng sẽ trở thành "blockchain EVM song song đầu tiên", vốn hóa lưu hành hiện tại là 2,1 tỷ USD, dự kiến sẽ còn phát triển hơn nữa. Monad, chuỗi công cộng EVM song song mới nổi bật nhất về mặt marketing hiện nay, rất được giới vốn ưa chuộng, tiềm năng cũng không thể xem nhẹ. Canto, chuỗi công cộng L1 vốn hóa 170 triệu USD, sở hữu hạ tầng công cộng miễn phí, cũng đã công bố đề xuất nâng cấp EVM song song của mình.
Ngoài ra, một loạt dự án L2 đang ở giai đoạn sớm cũng đang cung cấp khả năng nâng cao hiệu suất xuyên hệ sinh thái bằng cách tích hợp năng lực của nhiều chuỗi L1. Ngoài Neon đạt vốn hóa lưu hành 69 triệu USD, các dự án khác còn thiếu dữ liệu liên quan. Tin chắc rằng trong tương lai sẽ có thêm nhiều dự án L1 và L2 tham gia vào cuộc chiến blockchain song song.

Không chỉ câu chuyện EVM song song còn dư địa tăng trưởng thị trường rất lớn, mà toàn bộ lĩnh vực blockchain song song nơi nó thuộc về cũng còn dư địa tăng trưởng thị trường rất lớn, do đó triển vọng thị trường rất rộng mở.
Hiện tại, tổng vốn hóa lưu hành của L1 và L2 là 752,123 tỷ USD, vốn hóa lưu hành của blockchain song song là 52,539 tỷ USD, chiếm khoảng 7%. Trong đó, vốn hóa lưu hành của các dự án liên quan đến câu chuyện EVM song song là 2,339 tỷ USD, chỉ chiếm 4% vốn hóa lưu hành của blockchain song song.

1.3 Bản đồ ngành
Ngành thường chia mạng blockchain thành cấu trúc 4 lớp:
-
Lớp 0 (mạng): Mạng底层 blockchain, xử lý các giao thức truyền thông mạng cơ bản
-
Lớp 1 (hạ tầng): Mạng phi tập trung dựa vào các cơ chế đồng thuận khác nhau để xác minh giao dịch
-
Lớp 2 (mở rộng): Các giao thức lớp hai dựa vào Lớp 1, nhằm giải quyết các hạn chế của Lớp 1, đặc biệt là khả năng mở rộng
-
Lớp 3 (ứng dụng): Dựa vào Lớp 2 hoặc Lớp 1 để xây dựng các ứng dụng phi tập trung (dApp)
Các dự án theo câu chuyện EVM song song chủ yếu chia thành blockchain đơn thể và blockchain mô-đun, blockchain đơn thể lại chia thành L1 và L2. Từ tổng số dự án và sự phát triển của một vài lĩnh vực chính có thể thấy, hệ sinh thái các chuỗi công cộng L1 EVM song song so với hệ sinh thái Ethereum vẫn còn dư địa phát triển rất lớn.
Lĩnh vực DeFi có nhu cầu "tốc độ cao, phí thấp", lĩnh vực game có nhu cầu "tương tác thời gian thực mạnh", cả hai đều yêu cầu tốc độ thực thi nhất định. EVM song song chắc chắn sẽ mang lại trải nghiệm người dùng tốt hơn cho các dự án này, thúc đẩy ngành phát triển sang giai đoạn hoàn toàn mới.
L1 là các chuỗi công cộng mới có khả năng thực thi song song, là hạ tầng hiệu suất cao. Phái L1 này, các dự án như Sei v2, Monad và Canto tự thiết kế EVM song song, tương thích hệ sinh thái Ethereum và cung cấp khả năng xử lý giao dịch khối lượng lớn.
L2 thông qua việc tích hợp năng lực của các chuỗi L1 khác, cung cấp khả năng mở rộng xuyên hệ sinh thái, là đỉnh cao của rollup. Phái L2 này, Neon là bộ mô phỏng EVM trên mạng Solana, Eclipse sử dụng Solana để thực thi giao dịch nhưng thanh toán trên EVM. Lumio tương tự Eclipse, chỉ thay đổi lớp thực thi thành Aptos.

Bên ngoài các giải pháp blockchain đơn thể trên, Fuel đưa ra ý tưởng blockchain mô-đun riêng. Trong phiên bản thứ hai, nó sẽ định vị mình là hệ điều hành rollup Ethereum, cung cấp khả năng thực thi mô-đun linh hoạt và triệt để hơn.
Fuel tập trung vào thực thi giao dịch, còn phần còn lại được thuê ngoài cho một hoặc nhiều lớp blockchain độc lập, từ đó đạt được sự kết hợp linh hoạt hơn: có thể trở thành L2, cũng có thể trở thành L1, thậm chí là sidechain hay kênh trạng thái. Hiện tại hệ sinh thái Fuel có 17 dự án, tập trung chủ yếu vào ba lĩnh vực DeFi, NFT và hạ tầng.
Tuy nhiên, chỉ có oracles liên chuỗi Orally đã được đưa vào ứng dụng thực tế. Nền tảng cho vay phi tập trung Swaylend và nền tảng giao dịch hợp đồng vĩnh viễn SPARK đã lên testnet, các dự án khác vẫn đang trong quá trình phát triển.

2. Đường đi thực hiện kỹ thuật
Để thực hiện thực thi giao dịch phi tập trung, mạng blockchain phải thực hiện 4 nhiệm vụ:
-
Thực thi: Thực thi và xác minh giao dịch
-
Khả dụng dữ liệu: Phân phối khối mới đến tất cả các nút trong mạng blockchain
-
Cơ chế đồng thuận: Xác minh khối, đạt được sự đồng thuận
-
Thanh toán: Thanh toán và ghi lại trạng thái cuối cùng của giao dịch
EVM song song chủ yếu là tối ưu hóa hiệu suất ở lớp thực thi. Điều này lại chia thành hai loại giải pháp: mạng một lớp (L1) và mạng hai lớp (L2). Giải pháp L1 đưa vào cơ chế thực thi song song giao dịch, để giao dịch thực thi song song càng nhiều càng tốt trong máy ảo. Giải pháp L2 về bản chất là sử dụng máy ảo L1 đã được song song hóa để thực hiện mức độ nào đó "thực thi ngoài chuỗi + thanh toán trên chuỗi".
Vì vậy, để hiểu nguyên lý kỹ thuật của EVM song song, cần phân tích nó: trước tiên hiểu máy ảo (virtual machine) là gì, sau đó hiểu thực thi song song (parallel execution) là gì.
2.1 Máy ảo
Trong khoa học máy tính, máy ảo đề cập đến việc mô phỏng (virtualization) hoặc mô phỏng (emulation) một hệ thống máy tính.
Máy ảo được chia thành hai loại, một loại gọi là máy ảo hệ thống (system virtual machine), có thể ảo hóa một máy vật lý thành nhiều máy, chạy nhiều hệ điều hành, từ đó nâng cao hiệu suất sử dụng tài nguyên. Loại thứ hai gọi là máy ảo tiến trình (process virtual machine), cung cấp trừu tượng cho một số ngôn ngữ lập trình cao cấp, giúp chương trình máy tính viết bằng ngôn ngữ này có thể chạy theo cách độc lập với nền tảng trên các nền tảng khác nhau.
JVM là một máy ảo tiến trình được thiết kế cho ngôn ngữ lập trình Java. Chương trình viết bằng ngôn ngữ Java trước tiên được biên dịch thành bytecode Java (một mã nhị phân ở trạng thái trung gian), bytecode Java được JVM giải thích thực thi: JVM gửi bytecode đến trình thông dịch, trình thông dịch dịch thành mã máy trên các máy khác nhau, sau đó chạy trên máy.
Máy ảo blockchain là một dạng máy ảo tiến trình. Trong ngữ cảnh blockchain, máy ảo đề cập đến việc mô phỏng máy trạng thái phân tán, dùng để thực thi hợp đồng phân tán, chạy dApp. So sánh với JVM, EVM là một máy ảo tiến trình được thiết kế cho ngôn ngữ Solidity, hợp đồng thông minh trước tiên được biên dịch thành bytecode opcode, sau đó được EVM giải thích thực thi.
Các chuỗi công cộng mới ngoài Ethereum khi thực hiện máy ảo riêng, ngày càng sử dụng nhiều hơn máy ảo dựa trên bytecode WASM hoặc eBPF. WASM là một định dạng bytecode nhỏ gọn, tải nhanh, dễ di chuyển và dựa trên cơ chế bảo mật sandbox, các nhà phát triển có thể sử dụng nhiều ngôn ngữ lập trình (C, C++, Rust, Go, Python, Java thậm chí TypeScript...) để viết hợp đồng thông minh, sau đó biên dịch thành bytecode WASM và thực thi. Hợp đồng thông minh chạy trên chuỗi Sei chính là sử dụng định dạng bytecode này.
eBPF ban đầu là BPF (Berkeley Packet Filter - Bộ lọc gói Berkeley), ban đầu dùng để lọc dữ liệu mạng hiệu quả, sau đó tiến hóa thành eBPF, cung cấp tập lệnh phong phú hơn.
Đây là một công nghệ cách mạng cho phép can thiệp động và sửa đổi hành vi của nhân hệ điều hành mà không cần thay đổi mã nguồn. Sau đó công nghệ này thoát khỏi nhân, phát triển thành runtime eBPF ở không gian người dùng, sở hữu hiệu suất cao, an toàn và khả năng di chuyển. Hợp đồng thông minh chạy trên Solana sẽ được biên dịch thành bytecode eBPF và chạy trên mạng blockchain của nó.
Các chuỗi công cộng L1 khác, Aptos và Sui sử dụng ngôn ngữ lập trình hợp đồng thông minh Move, biên dịch thành bytecode đặc thù và thực thi trên máy ảo Move. Monad tự thiết kế máy ảo tương thích bytecode opcode EVM (Shanghai fork).

2.2 Thực thi song song
Thực thi song song là một công nghệ như sau:
-
Có thể tận dụng lợi thế của bộ xử lý đa nhân để xử lý nhiều nhiệm vụ đồng thời, tăng thông lượng hệ thống;
-
Đảm bảo kết quả giao dịch nhận được hoàn toàn giống với khi thực thi tuần tự theo thứ tự.
Mạng blockchain thường dùng TPS (số lượng giao dịch xử lý mỗi giây) làm chỉ số kỹ thuật đo tốc độ xử lý. Cơ chế thực thi song song khá phức tạp, cũng kiểm tra trình độ kỹ thuật của các nhà phát triển, không dễ giải thích rõ ràng. Dưới đây bắt đầu từ ví dụ về một "ngân hàng", giải thích thực thi song song là gì.
(1) Trước tiên, thực thi tuần tự là gì?
Tình huống 1: Nếu chúng ta coi hệ thống là một ngân hàng, CPU xử lý nhiệm vụ là quầy giao dịch, thì thực thi nhiệm vụ tuần tự giống như ngân hàng này chỉ có một quầy để xử lý nghiệp vụ. Lúc này khách hàng đến ngân hàng làm việc (nhiệm vụ) chỉ có thể xếp thành một hàng dài, lần lượt làm việc. Với mỗi khách hàng, nhân viên quầy phải lặp lại các thao tác giống nhau (thực thi lệnh) để phục vụ khách hàng. Khi chưa đến lượt mình, khách hàng chỉ có thể chờ đợi, điều này gây ra việc kéo dài thời gian giao dịch.
(2) Vậy thực thi song song là gì?
Tình huống 2: Lúc này ngân hàng thấy đông nghịt người, liền mở thêm vài quầy để xử lý nghiệp vụ, có 4 nhân viên quầy cùng xử lý nghiệp vụ, tốc độ nhanh hơn khoảng 4 lần so với trước, thời gian xếp hàng của khách hàng giảm còn khoảng 1/4, tốc độ xử lý nghiệp vụ của ngân hàng được nâng cao.
(3) Nếu không có biện pháp bảo vệ, hai người cùng chuyển tiền cho một người khác sẽ xảy ra lỗi gì?
Tình huống 3: Ba người A, B và C, số dư tài khoản lần lượt là 2 ETH, 1 ETH và 0 ETH, bây giờ A và B lần lượt chuyển 0,5 ETH cho C. Trong hệ thống thực thi giao dịch tuần tự, sẽ không xảy ra vấn đề gì (mũi tên trái "<=" biểu thị đọc sổ cái, mũi tên phải "=>" biểu thị ghi vào sổ cái, tương tự bên dưới):

Tuy nhiên, thực thi song song không đơn giản như vẻ bề ngoài. Có rất nhiều chi tiết tinh vi, chỉ cần sơ suất một chút có thể dẫn đếnlỗi cực kỳ nghiêm trọng. Nếu giao dịch chuyển tiền từ A và B đến C được thực thi song song, thì tùy theo thứ tự thực hiện các bước khác nhau, có thể tạo ra kết quả không nhất quán:

Nhiệm vụ song song 1 thực hiện chuyển tiền từ A đến C, nhiệm vụ song song 2 thực hiện chuyển tiền từ B đến C. Các bước đánh dấu * trong bảng đều có vấn đề: Do nhiệm vụ thực thi song song, trong bước 2 nhiệm vụ song song 1 chưa kịp ghi vào sổ cái phép tính cân bằng thu chi, trong bước 3 nhiệm vụ 2 đã đọc số dư tài khoản C (lúc này vẫn là 0), sau đó trong bước 5 dựa trên số dư 0 để tính toán sai phép cân bằng thu chi, rồi trong bước 6 thao tác cập nhật sổ cái đã cập nhật sai số dư tài khoản 0,5 thành 0,5 một lần nữa, khiến dù A và B đều chuyển 0,5 ETH cho C, nhưng sau khi giao dịch hoàn tất số dư tài khoản C chỉ còn 0,5 ETH, 0,5 ETH còn lại biến mất.
(4) Nếu không có biện pháp bảo vệ, hai nhiệm vụ không phụ thuộc nhau thực thi song song sẽ không bị lỗi
Tình huống 4: Nhiệm vụ song song 1 thực hiện A (số dư 2 ETH) chuyển 0,5 ETH cho C (số dư 0 ETH), nhiệm vụ song song 2 thực hiện B (số dư 1 ETH) chuyển 0,5 ETH cho D (số dư 0 ETH). Có thể thấy hai nhiệm vụ chuyển tiền nàykhông có phụ thuộc. Như vậy bất kể các bước của hai nhiệm vụ xen kẽ thực hiện thế nào, cũng sẽ không có vấn đề trên:

Từ so sánh hai tình huống có thể phân tích, chỉ cần giữa các nhiệm vụ tồn tạisự phụ thuộc, khi thực thi song song có thể xảy ra lỗi cập nhật trạng thái, ngược lại sẽ không xảy ra lỗi. Nếu thỏa mãn một trong hai điều kiện sau, thì giữa các nhiệm vụ (giao dịch) được coi là có quan hệ phụ thuộc:
-
Đầu ra mà một nhiệm vụ ghi vào là đầu vào mà nhiệm vụ khác đọc;
-
Hai nhiệm vụ đều ghi ra cùng một địa chỉ.
Điều này không phải đặc thù của phi tập trung. Bất kỳ tình huống nào liên quan đến thực thi song song đều có thể gặp phải hiện tượng dữ liệu không nhất quán do nhiều nhiệm vụ phụ thuộc truy cập tài nguyên chung không được bảo vệ («sổ cái» trong ví dụ ngân hàng, bộ nhớ chung trong hệ thống máy tính...), gọi làvấn đề điều kiện đua tranh (data races).
Ngành đã đề xuất ba cơ chế thực thi để giải quyết vấn đề điều kiện đua tranh trong thực thi song song:cơ chế truyền tin nhắn, cơ chế bộ nhớ chung và cơ chế danh sách truy cập trạng thái nghiêm ngặt.
2.3 Cơ chế truyền tin nhắn
Tình huống 5: Giả sử ngân hàng có 4 quầy cùng xử lý nghiệp vụ cho khách hàng, bây giờ phát cho mỗi nhân viên quầy một cuốn sổ cái riêng, chỉ mình họ có thể sửa đổi. Trên đó ghi số dư tài khoản khách hàng mà họ phục vụ.
Mỗi nhân viên khi xử lý nghiệp vụ cho khách hàng, nếu thông tin khách hàng tìm được trong sổ cái của mình thì trực tiếp xử lý; nếu không thì gọi to thông báo cho nhân viên khác biết nghiệp vụ khách hàng muốn làm, nhân viên khác nghe thấy sẽ xử lý.
Đây là nguyên lý của mô hình truyền tin nhắn.Mô hình Actor là một dạng mô hình truyền tin nhắn, mỗi thực thể xử lý giao dịch là một actor (nhân viên quầy), mỗi người đều có dữ liệu riêng tư có thể truy cập (sổ cái riêng), nếu muốn truy cập dữ liệu riêng tư của người khác, chỉ có thể thực hiện thông qua việc gửi tin nhắn.

Ưu điểm của mô hình Actor là mỗi actor chỉ có thể truy cập dữ liệu riêng tư của mình, do đó sẽ không xảy ra vấn đề điều kiện đua tranh.
Nhược điểm của nó có hai điểm, một là mỗi actor chỉ có thể thực thi tuần tự, trong một số tình huống không phát huy được lợi thế song song (ví dụ nhân viên quầy số 2, 3, 4 cùng lúc gửi tin nhắn hỏi nhân viên quầy số 1 số dư tài khoản A là bao nhiêu, trong mô hình này nhân viên số 1 chỉ có thể xử lý từng tin nhắn một, trong khi việc này vốn có thể xử lý song song).
Hai là không có thông tin toàn cục về trạng thái hệ thống hiện tại, nếu nghiệp vụ hệ thống phức tạp, sẽ rất khó hiểu toàn cảnh, định vị và sửa lỗi.
2.4 Cơ chế bộ nhớ chung
2.4.1 Mô hình khóa bộ nhớ
Tình huống 6: Giả sử ngân hàng chỉ có một cuốn sổ cái lớn, ghi tất cả số dư tài khoản khách hàng. Bên cạnh sổ cái chỉ có một cây bút ký để sửa đổi sổ cái.
Trong tình huống này, 4 nhân viên khi xử lý nghiệp vụ thì xem ai nhanh hơn: một nhân viên giành lấy cây bút trước (khóa) bắt đầu xử lý nghiệp vụ sửa đổi sổ cái, 3 nhân viên còn lại chỉ có thể chờ. Cho đến khi nhân viên dùng xong bỏ bút xuống (mở khóa), 3 nhân viên khác mới tranh giành quyền sử dụng bút, cứ như vậy lặp lại, đây làmô hình khóa bộ nhớ (memory locks).
Khóa bộ nhớ là khi nhiệm vụ thực thi song song truy cập tài nguyên chung thì thực hiện thao tác khóa (lock), sau khi khóa thì truy cập tài nguyên chung, lúc này nhiệm vụ khác phải chờ nó sửa đổi xong mở khóa (unlock) mới có thể khóa lại và truy cập.
Khóa đọc-ghi (read-write lock) xử lý tinh vi hơn, có thể đặtkhóa đọc (read lock) hoặckhóa ghi (write lock) cho tài nguyên chung. Điểm khác biệt là nhiều nhiệm vụ song song có thể đặt nhiều khóa đọc và đọc dữ liệu tài nguyên chung, lúc này không cho phép sửa đổi; còn khóa ghi chỉ có thể đặt một cái, và sau khi đặt thì chỉ người đặt khóa mới được truy cập độc quyền.

Solana, Sui và Sei v1 sử dụng mô hình bộ nhớ chung dựa trên khóa bộ nhớ. Cơ chế này nhìn thì đơn giản, nhưng thực hiện rất phức tạp, kiểm tra nghiêm khắc khả năng lập trình đa luồng của các nhà phát triển. Chỉ cần sơ suất một chút, sẽ để lại đủ loại lỗi:
-
Tình huống 1: Nhiệm vụ khóa tài nguyên chung, nhưng trong quá trình thực thi bị lỗi sập, tài nguyên chung bị khóa không thể truy cập;
-
Tình huống 2: Nhiệm vụ đã khóa, nhưng trong quá trình thực thi do logic nghiệp vụ lồng nhau xảy ra khóa lần hai, dẫn đến tự chờ chính mình.
Mô hình khóa bộ nhớ dễ gặp nhất là các vấn đềtắc nghẽn (dead lock), sống khóa (live lock) và đói tài nguyên (starvation):
(1) Nhiều nhiệm vụ song song tranh giành nhiều tài nguyên chung, mỗi nhiệm vụ chiếm giữ một phần, đều đang chờ đối phương giải phóng tài nguyên, sẽ xảy ra tắc nghẽn;
(2) Nhiệm vụ song song phát hiện còn nhiệm vụ song song khác đang hoạt động, chủ động nhường tài nguyên chung mình chiếm giữ, dẫn đến bạn nhường tôi, tôi nhường bạn, xảy ra sống khóa;
(3) Nhiệm vụ ưu tiên cao luôn giành được quyền truy cập tài nguyên chung, các nhiệm vụ ưu tiên thấp chờ đợi lâu dài, xảy ra «đói tài nguyên».

2.4.2 Tối ưu hóa lạc quan
Tình huống 7: Mỗi nhân viên quầy ngân hàng khi xử lý nghiệp vụ đều có thể độc lập tra cứu và sửa đổi sổ cái, bất kể nhân viên khác có đang dùng sổ cái hay không. Nhân viên khi dùng sổ cái thì dán một nhãn hiệu cá nhân lên nội dung tra cứu và sửa đổi. Mỗi lần xử lý nghiệp vụ xong sẽ duyệt lại một lượt, nếu phát hiện nhãn không phải của mình, chứng tỏ bản ghi đã bị nhân viên khác sửa đổi, nghiệp vụ lần này phải hủy và xử lý lại.
Đây là nguyên lý cơ bản củatối ưu hóa lạc quan. Tư tưởng cốt lõi của tối ưu hóa lạc quan làgiả định trước rằng tất cả các nhiệm vụ đều độc lập với nhau. Trước tiên thực thi song song các nhiệm vụ, sau đó xác minh từng nhiệm vụ, nếu xác minh không qua thì thực thi lại nhiệm vụ đó, cứ như vậy cho đến khi tất cả nhiệm vụ hoàn tất. Giả sử có 8 nhiệm vụ song song thực thi theo cách tối ưu hóa lạc quan, trong quá trình cần truy cập 2 tài nguyên chung A và B.
Giai đoạn 1 thực thi, nhiệm vụ 1, 2 và 3 thực thi song song. Nhưng nhiệm vụ 2 và 3 cùng truy cập tài nguyên chung B gây xung đột, do đó nhiệm vụ 3 được lên lịch lại ở giai đoạn tiếp theo. Giai đoạn 2 thực thi, nhiệm vụ 3 và 4 cùng truy cập tài nguyên chung B, lúc này nhiệm vụ 4 được lên lịch lại, cứ như vậy cho đến khi tất cả nhiệm vụ hoàn tất. Có thể thấy trong suốt quá trình, các nhiệm vụ xảy ra xung đột sẽ liên tục thực thi lại.

Mô hình tối ưu hóa lạc quan sử dụng mộtcấu trúc dữ liệu bộ nhớ đa phiên bản (multi-version in-memory data structure) để ghi lại mỗi giá trị ghi và thông tin phiên bản của nó (tương tự nhân viên quầy dán nhãn).
Việc vận hành mỗi nhiệm vụ song song chia thành hai giai đoạn: thực thi (execution) và xác minh (validation). Giai đoạn thực thi sẽ ghi lại tất cả hành vi đọc và ghi dữ liệu, tạo thành tập đọc (read set) và tập ghi (write set). Giai đoạn xác minh sẽ so sánh tập đọc và tập ghi với cấu trúc dữ liệu đa phiên bản, nếu phát hiện không phải mới nhất thì xác minh không qua.
Mô hình tối ưu hóa lạc quan bắt nguồn từbộ nhớ giao dịch phần mềm (Software Transaction Memory, viết tắt STM), đây là một cơ chế lập trình không khóa trong lĩnh vực cơ sở dữ liệu. Vì mạng blockchain xử lý giao dịch một cách tự nhiên có thứ tự xác định, do đó khái niệm này được đưa vào và phát triển thành cơ chế Block-STM. Aptos và Monad sử dụng Block-STM làm cơ chế thực thi song song của mình.
Đáng chú ý, chuỗi Sei trong phiên bản v2 sắp phát hành sẽ từ bỏ mô hình khóa bộ nhớ cũ, chuyển sang sử dụng mô hình tối ưu hóa lạc quan. Block-STM có tốc độ thực thi cực nhanh, trong môi trường thử nghiệm tốc độ thực thi giao dịch của Aptos đạt tới mức kinh ngạc 160k tps, nhanh hơn 18 lần so với thực thi tuần tự. Block-STM giao phó cơ chế phức tạp về thực thi và xác minh giao dịch cho đội ngũ cốt lõi thực hiện cơ chế底层, các nhà phát triển có thể dễ dàng viết hợp đồng thông minh như viết chương trình thực thi tuần tự.
2.5 Danh sách truy cập trạng thái nghiêm ngặt
Cơ chế truyền tin nhắn và bộ nhớ chung được thực hiện dựa trên mô hình dữ liệu tài khoản/số dư, ghi lại thông tin số dư tài khoản trên chuỗi. Giống như sổ cái ngân hàng ghi khách hàng A có số dư 1000 tệ, khách hàng B có số dư 600 tệ, mỗi lần xử lý giao dịch chỉ cần sửa đổi trạng thái số dư tài khoản.
Nếu đổi cách suy nghĩ, có thể chỉ ghi nội dung cụ thể của giao dịch mỗi lần, tạo thành bản ghi giao dịch, cũng có thể tính toán số dư tài khoản người dùng từ bản ghi giao dịch, ví dụ có bản ghi giao dịch như sau:
-
Khách hàng A mở tài khoản và gửi 1000 tệ;
-
Khách hàng B mở tài khoản (0 tệ);
-
Khách hàng A chuyển 100 tệ cho khách hàng B.
Thông qua việc đọc bản ghi và tính toán, có thể biết số dư tài khoản hiện tại của khách hàng A là 900 tệ; số dư tài khoản khách hàng B là 100 tệ.
UTXO (unspent tx output, đầu ra giao dịch chưa tiêu) tương tự mô hình dữ liệu bản ghi giao dịch như vậy, đây là cách Bitcoin, thế hệ blockchain đầu tiên, dùng để biểu thị tiền điện tử. Mỗi giao dịch đều có đầu vào (có được như thế nào) và đầu ra (tiêu như thế nào), UTXO có thể đơn giản hiểu là khoản nhận chưa tiêu.
Ví dụ khách hàng A có 6 BTC, chuyển 5,2 BTC cho khách hàng B, còn lại 0,8 BTC, từ góc độ UTXO có thể coi là: 6 UTXO trị giá 1 BTC của A bị hủy, B nhận được 1 UTXO mới tạo trị giá 5,2 BTC, đồng thời trả lại A 1 UTXO mới tạo trị giá 0,8 BTC. Tức là 6 UTXO bị hủy, tạo ra 2 UTXO mới.
Đầu vào và đầu ra của giao dịch nối thành chuỗi, sử dụng chữ ký số ghi lại thông tin quyền sở hữu, tạo thành mô hình UTXO. Blockchain áp dụng mô hình dữ liệu này cần cộng tổng tất cả UTXO của một địa chỉ tài khoản để biết số dư tài khoản hiện tại.Danh sách truy cập trạng thái nghiêm ngặt (strict state access list) dựa trên mô hình UTXO để thực hiện thực thi song song. Nó sẽ tính toán trước từng địa chỉ tài khoản mà mỗi giao dịch cần truy cập, tạo thành danh sách truy cập.
Danh sách truy cập có hai tác dụng:
(1) Đánh giá độ an toàn giao dịch: Nếu giao dịch truy cập địa chỉ không nằm trong danh sách truy cập khi thực thi, thì thực thi thất bại.
(2) Thực thi giao dịch song song: Dựa trên danh sách truy cập tạo thành nhiều tập hợp giao dịch, các tập hợp giao dịch này không giao nhau trên danh sách truy cập (không phụ thuộc), do đó nhiều tập hợp giao dịch có thể thực thi song song.
3. Động lực tăng trưởng ngành
Xét theo quy luật nội tại, mọi sự phát triển đều trải qua quá trình «từ không đến có» đến «từ có đến tốt», khát khao về tốc độ nhanh hơn của con người là vĩnh cửu. Để giải quyết vấn đề tốc độ thực thi mạng khối đã sinh ra đủ loại ý tưởng giải pháp trên chuỗi hay ngoài chuỗi. Các giải pháp ngoài chuỗi đại diện bởi rollup đã được khám phá đầy đủ giá trị, trong khi câu chuyện EVM song song còn dư địa khám phá rất lớn.
Xét theo bối cảnh lịch sử, cùng với SEC phê duyệt ETF Bitcoin giao ngay và sự kiện giảm thưởng Bitcoin sắp diễn ra, cộng thêm khả năng FED cắt giảm lãi suất, tiền mã hóa được kỳ vọng sẽ bước vào một thị trường tăng giá lớn, sự phát triển mạnh mẽ của ngành cần hạ tầng mạng blockchain có thông lượng lớn hơn làm nền tảng vững chắc.
Xét theo quản lý tài nguyên, mạng khối truyền thống xử lý giao dịch tuần tự, phương pháp xử lý này tuy đơn giản nhưng cũng là sự lãng phí tài nguyên xử lý. Blockchain song song đạt được việc sử dụng tối đa tài nguyên tính toán, tận dụng triệt để hiệu suất bộ xử lý đa nhân, nâng cao hiệu suất tổng thể của mạng khối.
Xét theo sự phát triển ngành, mặc dù đổi mới công nghệ và mô hình kinh doanh không ngừng xuất hiện, nhưng tiềm năng phát triển Web3 vẫn còn cần khai thác. Mạng tập trung có thể mỗi giây đẩy 50.000 tin nhắn, gửi 3,4 triệu email, hoàn thành 100.000 tìm kiếm Google và cho hàng ngàn người chơi cùng trực tuyến, trong khi phi tập trung tạm thời chưa làm được. Phi tập trung muốn đối đầu với tập trung, giành nửa giang sơn của mình, liên tục tối ưu hóa cơ chế thực thi song song, nâng cao thông lượng giao dịch cũng là con đường tất yếu.
Xét theo sự phát triển dApp phi tập trung, để thu hút thêm người dùng, phải đầu tư vào trải nghiệm. Tối ưu hóa hiệu suất là một hướng nâng cao trải nghiệm người dùng. Đối với người dùng DeFi, cần đáp ứng nhu cầu tốc độ giao dịch cao, phí thấp. Đối với người dùng GameFi, cần đáp ứng nhu cầu tương tác thời gian thực. Những điều này đều cần thực thi song song làm nền tảng.
4. Vấn đề tồn tại
Ba yếu tố phi tập trung, an toàn và khả năng mở rộng chỉ có thể thỏa mãn hai trong ba, đây là ngoại lệ bất khả thi blockchain. Vì «phi tập trung» là yếu tố không thể lay chuyển, vậy nên «khả năng mở rộng» tăng lên đồng nghĩa với «an toàn» giảm xuống. Mã nguồn do con người viết, mà do con người viết thì dễ mắc lỗi. Sự phức tạp kỹ thuật do tính toán song song mang lại đã tạo điều kiện cho các mối nguy hiểm an ninh sinh sôi.
Lập trình đa luồng dễ dẫn đến vấn đề điều kiện đua tranh do các thao tác kiểm soát đồng thời phức tạp không đúng cách; đồng thời dễ dẫn đến sập do truy cập địa chỉ bộ nhớ không hợp lệ, thậm chí xuất hiện lỗ hổng tràn bộ đệm có thể bị kẻ tấn công lợi dụng.
Ít nhất có thể đánh giá mức độ an toàn của dự án từ ba góc độ. Một là tiểu sử đội ngũ. Đội ngũ có kinh nghiệm lập trình hệ thống am hiểu sâu sắc lập trình đa luồng, đã gặp và xử lý được 80% các vấn đề nan giải. Lập trình hệ thống thường liên quan đến các lĩnh vực sau:
-
Hệ điều hành
-
Các loại driver thiết bị
-
Hệ thống tệp tin
-
Cơ sở dữ liệu
-
Thiết bị nhúng
-
Mật mã học
-
Mã hóa/giải mã đa phương tiện
-
Quản lý bộ nhớ
-
Mạng
-
Ảo hóa
-
Trò chơi
-
Ngôn ngữ lập trình cao cấp
Hai là tính duy trì mã nguồn, viết mã có tính duy trì cao là có quy tắc nhất định, ví dụ thiết kế kiến trúc rõ ràng, vận dụng hợp lý các mẫu thiết kế để đạt được khả năng tái sử dụng mã, áp dụng kỹ thuật phát triển dựa trên kiểm thử để viết đủ lượng lớn mã kiểm thử đơn vị, thông qua tái cấu trúc hợp
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News














