Ở ranh giới của tính tất định: Vòng đời giao dịch trong Solana Sealevel và Sui Object Runtime

Vòng đời của một giao dịch blockchain là gì?

Blockchain xử lý các giao dịch. Giao dịch tác động đến trạng thái (tức chế độ xem cập nhật của các tài khoản trên blockchain). Hiểu vòng đời giao dịch có thể là cách thể hiện rõ nhất triết lý thiết kế của một blockchain, cung cấp cho các bên liên quan về kỹ thuật những hiểu biết quan trọng về cách chuỗi được tối ưu hóa cho thông lượng và độ an toàn, các bảo đảm về tính tất định, chi phí kỹ thuật tương đối và những điểm nghẽn tiềm ẩn trong điều kiện thực tế.

Trong các phần tiếp theo, chúng ta sẽ xem xét các giai đoạn khác nhau mà giao dịch trải qua từ khi gửi đến khi hoàn tất, cũng như cách quy trình này ảnh hưởng đến việc thực thi ở nhiều cấp độ trong các chuỗi này.

Vòng đời giao dịch Solana

Blockchain Solana được xây dựng trên một thiết kế độc đáo, sử dụng Proof-of-Stake (PoS) làm cơ chế đồng thuận và Proof-of-History (PoH) làm cơ chế ghi nhận thời gian để sắp xếp giao dịch hiệu quả.

Mô hình thiết kế của Solana lấy tài khoản làm trung tâm, nói cách khác, “mọi thứ trên Solana đều là tài khoản”.

Tài khoản được dùng để lưu trữ dữ liệu, bao gồm trạng thái và các tệp nhị phân có thể thực thi (tức mã chương trình). Giao dịch chứa các lệnh làm thay đổi trạng thái tài khoản. Các node tham gia đồng thuận trên mạng và xử lý giao dịch được gọi là validator. Quy trình xử lý giao dịch để sửa đổi tài khoản được gọi là xử lý theo pipeline, còn các điểm mà giao dịch đi qua trong vòng đời được gọi là các giai đoạn.

Một giao dịch Solana

Trên Solana, giao dịch là một tập hợp chữ ký của các thông điệp đã tuần tự hóa, được ký bởi khóa đầu tiên trong khóa tài khoản của Message.

Thông điệp trong giao dịch là một cấu trúc dữ liệu chứa header, các khóa tài khoản, blockhash gần đây và các lệnh. Header chứa MessageHeader, mô tả cách tổ chức các khóa tài khoản của Message.

Mỗi lệnh xác định rõ các tài khoản mà nó có thể truy cập và quyền cần thiết cho từng tài khoản. Các quyền này cho biết tài khoản là chỉ đọc hay đọc-ghi, cũng như tài khoản có phải đã ký giao dịch chứa lệnh đó hay không.

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

Mỗi lệnh chứa danh sách tất cả tài khoản mà nó có thể truy cập, cùng các quyền cần thiết cho từng tài khoản.

Một Message chứa một danh sách phẳng dùng chung duy nhất gồm tất cả tài khoản mà mọi lệnh trong giao dịch yêu cầu. Danh sách phẳng này được tạo khi xây dựng Message, và các lệnh được chuyển đổi thành một tập hợp CompiledInstructions. Sau đó, các CompiledInstructions này tham chiếu theo chỉ mục đến những tài khoản cần thiết trong danh sách tài khoản dùng chung duy nhất.

Danh sách tài khoản dùng chung được sắp xếp theo quyền mà các tài khoản yêu cầu:

• Tài khoản có thể ghi và là bên ký.
• Tài khoản chỉ đọc và là bên ký.
• Tài khoản có thể ghi và không phải bên ký.
• Tài khoản chỉ đọc và không phải bên ký.

Với thứ tự này, các trường của MessageHeader mô tả tài khoản nào trong giao dịch yêu cầu quyền nào.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

Khi nhiều giao dịch truy cập cùng các tài khoản chỉ đọc, runtime có thể xử lý song song chúng trong một mục PoH. Các giao dịch truy cập cùng tài khoản đọc-ghi được xử lý tuần tự.

Giao dịch được gửi đến client qua Gulf Stream, giao thức chuyển tiếp giao dịch của Solana, rồi được xử lý qua hai quy trình nhiều giai đoạn theo pipeline trong validator, gọi là Transaction Processing Unit (TPU) và Transaction Validation Unit (TVU).

Các quy trình này phối hợp với runtime để bảo đảm những giao dịch sửa đổi các trạng thái tài khoản khác nhau được xử lý song song, còn những giao dịch sửa đổi cùng một trạng thái tài khoản được xử lý tuần tự.

TPU chạy khi validator ở chế độ leader (tức tạo block), còn TVU chạy khi validator ở chế độ validator (tức xác thực block). Trong cả hai trường hợp, phần cứng pipeline đều tương tự nhau: đầu vào mạng, ghi vào ổ đĩa, đầu ra mạng, v.v. Tuy nhiên, cách sử dụng phần cứng đó lại khác nhau. Nói đơn giản, TPU dùng để tạo các mục sổ cái, còn TVU dùng để xác thực các mục đó.

Ở cấp độ tổng quan, giao dịch được gửi qua client và được Gulf Stream xử lý qua QUIC tới TPU của leader. Giao dịch trải qua các bước kiểm tra xác minh rồi được giai đoạn banking lên lịch thực thi. Các cập nhật trạng thái được ghi trở lại trạng thái trong bộ nhớ của bank. Validator bỏ phiếu cho các block qua gossip, và block được hoàn tất bằng Tower BFT, một biến thể PBFT với cơ chế khóa theo trọng số stake.

Gulf Stream

Trong hầu hết blockchain, giao dịch do người dùng gửi được “xếp hàng” trong mempool (nghĩa đen là “bể nhớ”) để chờ mạng xử lý. Giao dịch đã ký có thể nằm trong mempool rất lâu, thậm chí vô thời hạn, chờ được thực thi nếu mạng không ở trạng thái tối ưu hoặc điều kiện thực thi chưa được đáp ứng. Kết quả là những giao dịch này có thể không bao giờ được đưa vào block nào.

Solana loại bỏ nhu cầu về một mempool toàn cục bằng cách dựa vào lịch leader tất định chịu ảnh hưởng bởi thuật toán theo trọng số stake, được gọi là Stake-Weighted Quality of Service (SWQoS), để ưu tiên các thông điệp giao dịch được định tuyến qua validator có stake.

Vì mọi node đang hoạt động đều biết trước lịch leader, các thông điệp giao dịch có thể được phân phối hiệu quả, bảo đảm các leader sắp tới đã có đủ giao dịch để xử lý trước khi đến lượt tạo block. Cơ chế này cho phép validator tiền xử lý giao dịch bằng cách xác minh chữ ký và loại bỏ trước các giao dịch trùng lặp hoặc sai định dạng.

Một ưu điểm khác của Gulf Stream là so với các chuỗi truyền thống dùng mempool, nhà sản xuất block còn phải truyền lại chính các giao dịch đó trong một block, nghĩa là mỗi giao dịch được truyền qua mạng ít nhất hai lần. Solana không cần tạo thêm tải cho gossip để đồng bộ các giao dịch đang chờ, và giao dịch không phải cạnh tranh không gian block qua đấu giá gas; thay vào đó, chúng được phân phối theo lịch.

Transaction Processing Unit (TPU)

TPU là logic cốt lõi của validator chịu trách nhiệm sản xuất block. Giao dịch được lấy từ client và chuyển tiếp trong các gói dữ liệu qua một thành phần gọi là QUIC streamer, thành phần này cấp phát bộ nhớ gói và đọc dữ liệu từ endpoint QUIC (được gọi là “Giai đoạn Fetch”). Mỗi stream truyền một gói trong giới hạn truyền QUIC được xác định bởi client (địa chỉ IP, pubkey của node) và server.

Sau đó, các gói được truyền đến Giai đoạn Sigverify, nơi chúng được loại bỏ bản trùng lặp bằng một cơ chế giảm tải đặc biệt để loại các gói dư thừa. Các gói đã khử trùng lặp tiếp tục được lọc để loại những gói có chữ ký không hợp lệ rồi chuyển đến giai đoạn banking.

Giai đoạn banking là thành phần chủ chốt trong quá trình thực thi runtime của Solana. Nó lên lịch các gói đến, tiếp tục lọc xung đột và đánh giá xem các gói đủ điều kiện để được xử lý, giữ lại hay chuyển tiếp theo lô. Nếu phát hiện node là nhà sản xuất block, nó xử lý các gói được giữ lại và mới nhận bằng thành phần Bank. Thành phần bank là biểu diễn trong bộ nhớ của toàn bộ trạng thái sổ cái tại một slot nhất định.

Trong giai đoạn banking và thành phần scheduler, giao dịch được theo dõi ở hai trạng thái:

• Trạng thái chưa xử lý, trong đó giao dịch sẵn sàng để lên lịch
• Trạng thái đang chờ, trong đó giao dịch đang được lên lịch hoặc đang được xử lý

Khi giao dịch xử lý xong, nó có thể được thử lại. Nếu có thể thử lại, giao dịch được chuyển về trạng thái chưa xử lý; nếu không, trạng thái sẽ bị loại bỏ. Các giao dịch hợp lệ đã xử lý được tạo thành một “Entry” qua các tick PoH, đóng gói thành block và phát dưới dạng shred đến các peer trên mạng thông qua Turbine, giao thức truyền bá block của Solana. Giao thức này tạo mã xóa để “tái tạo” các gói dữ liệu bị mất trước khi truyền gói đến peer mạng phù hợp trong Giai đoạn Broadcast.

Transaction Validation Unit (TVU)

TVU là logic trong các node validator không phải leader, chịu trách nhiệm xác thực và truyền bá block. Trong TVU, các gói dữ liệu được xử lý qua nhiều giai đoạn đa luồng trước khi được hoàn tất. Các giai đoạn này bao gồm lấy shred, xác minh chữ ký, truyền lại và phát lại.

Trong Giai đoạn Shred Fetch và giai đoạn Shred Verify Leader signature, các node không phải leader nhận shred từ những node khác qua UDP và xác minh chữ ký theo lô. Shred hợp lệ được truyền lại đến các node peer trong Giai đoạn Retransmit, và từng giao dịch được phát lại theo thứ tự trong Giai đoạn Replay.

Trong giai đoạn phát lại, runtime được gọi để tái thực thi tất định tất cả giao dịch, bảo đảm mọi thay đổi trạng thái, thuộc tính chương trình và hash bank khớp chính xác với đầu ra của leader.

Nếu một block được đánh giá là hợp lệ, validator ký một giao dịch bỏ phiếu và gửi phiếu này cho leader để đưa vào các block tiếp theo.

Runtime

Runtime là bộ xử lý giao dịch đồng thời của Solana, được dùng chung giữa TPU và TVU. Giao dịch chỉ định trước các phụ thuộc dữ liệu (tức những tài khoản chúng muốn đọc và/hoặc ghi) để cho phép thực thi bộ nhớ động một cách rõ ràng. Nhờ đó, việc đọc trạng thái có thể được tách biệt tốt khỏi thực thi chương trình, cho phép runtime điều phối truy cập đồng thời.

Runtime Solana sử dụng một công cụ thực thi gọi là Sealevel để bảo đảm các giao dịch truy cập tài khoản chỉ đọc được thực thi song song. Ngược lại, các giao dịch truy cập những tài khoản có thể ghi bị chồng lấp được tuần tự hóa và thực thi lần lượt.

Trong runtime, các giao dịch được thực thi nguyên tử; mọi lệnh trong một giao dịch phải được thực thi thành công thì giao dịch đó mới được commit vào bank, nếu không giao dịch sẽ thất bại.

Runtime tương tác với một chương trình nhất định qua entrypoint có giao diện được xác định rõ. Entrypoint này đơn giản là một hàm Rust mà tất cả chương trình on-chain đều công khai rõ ràng làm điểm bắt đầu thực thi, đồng thời đóng vai trò giao diện giữa runtime Solana và các chương trình. Công cụ thực thi ánh xạ khóa công khai tới tài khoản và định tuyến chúng đến entrypoint này. Tuy nhiên, nó áp dụng một số ràng buộc quan trọng để định hướng logic thực thi, được xác định bởi kiến trúc tập lệnh của máy ảo:

• Chỉ chương trình sở hữu mới có thể sửa đổi nội dung tài khoản.
• Tổng số dư trên tất cả tài khoản bằng nhau trước và sau khi thực thi giao dịch, nhưng điều này chỉ áp dụng ở mức tổng hợp. Lamport không được bảo toàn đối với chuyển khoản hệ thống và đốt.
• Sau khi giao dịch được thực thi, số dư tài khoản chỉ đọc phải bằng số dư trước giao dịch.
• Tất cả lệnh trong giao dịch được thực thi nguyên tử. Nếu một lệnh thất bại, mọi sửa đổi tài khoản đều bị hủy.

Pipeline TPU và TVU đi theo các đường hơi khác nhau khi tương tác với runtime. Runtime TPU bảo đảm các “entry” được ghi lại (qua tick PoH) trước khi bộ nhớ được commit, còn runtime TVU bảo đảm các “entry” được xác minh trước khi runtime xử lý bất kỳ giao dịch nào.

Đồng thuận

Đồng thuận là một trong những cơ chế nền tảng nhất của các hệ thống điện toán phân tán phức tạp. Trong vòng đời giao dịch Solana, đồng thuận diễn ra sau khi block được TVU thực thi và xác thực nhưng trước khi block được hoàn tất. Ý tưởng cốt lõi của đồng thuận là một thỏa thuận thống nhất, bảo đảm những bên tham gia mạng đồng ý về cùng một kết quả và sau khi đã quyết định thì không thể thay đổi quyết định đó.

Theo nghĩa chính thức, một cơ chế đồng thuận chịu lỗi phải đáp ứng các thuộc tính sau:

• Thỏa thuận thống nhất: Không có hai node đưa ra quyết định khác nhau.
• Tính toàn vẹn: Không node nào quyết định nhiều hơn một lần.
• Tính hợp lệ: Nếu một node quyết định một giá trị, giá trị đó phải do một node khác đề xuất.
• Tính kết thúc: Mọi node không gặp sự cố cuối cùng đều quyết định một giá trị nào đó.

Nhìn bề ngoài, mục tiêu của đồng thuận là khiến các node nhất trí về một điều gì đó. Với Solana, có nhiều tình huống các node cần đạt đồng thuận. Điều này nổi bật trong ba trường hợp:

Luân phiên leader

Tất cả node phải thống nhất ai là leader vì sự cố mạng có thể làm gián đoạn liên lạc và dẫn đến tình huống chia não, khi nhiều node nhầm tưởng mình đồng thời là leader.

Lịch leader được tạo bằng một seed định trước theo thuật toán sau: độ cao tick PoH (tức bộ đếm tăng đơn điệu) được dùng định kỳ để làm seed cho một thuật toán giả ngẫu nhiên ổn định.

Tại độ cao đó, bank lấy mẫu tất cả tài khoản có stake mang danh tính leader đã bỏ phiếu trong số tick do cluster cấu hình. Mẫu này được gọi là tập hoạt động và được sắp xếp theo trọng số stake. Seed ngẫu nhiên sau đó được dùng để chọn các node theo trọng số stake nhằm tạo thứ tự theo trọng số stake, có hiệu lực sau số tick do cluster cấu hình.

Đồng bộ hóa

Nếu không có timestamp đáng tin cậy, validator không thể xác định thứ tự các block đến. Solana dùng cơ chế gọi là Proof-of-History làm đồng hồ mật mã để sắp xếp giao dịch trước khi chúng trải qua đồng thuận. Theo tài liệu của Anza về đồng bộ hóa:

“Các node leader "đóng timestamp" cho block bằng bằng chứng mật mã cho thấy một khoảng thời gian đã trôi qua kể từ bằng chứng gần nhất. Mọi dữ liệu được hash vào bằng chứng chắc chắn đã xuất hiện trước khi bằng chứng được tạo. Sau đó, node chia sẻ block mới với các node validator có khả năng xác minh những bằng chứng đó. Các block có thể đến validator theo bất kỳ thứ tự nào hoặc thậm chí được phát lại nhiều năm sau. Với những bảo đảm đồng bộ hóa đáng tin cậy như vậy, Solana có thể chia block thành các lô giao dịch nhỏ hơn gọi là entry. Sau đó, các entry được stream đến validator theo thời gian thực, trước khi có bất kỳ khái niệm nào về đồng thuận block”.

Cần nhớ rằng dù Proof-of-History không phải cơ chế đồng thuận, nó vẫn tác động đáng kể đến hiệu suất đồng thuận Proof-of-Stake của Solana.

Commit nguyên tử

Một quy trình cần thiết khác mà các node phải thống nhất là commit nguyên tử. Trong một hệ thống hiệu suất cao như Solana, giao dịch có thể thất bại trên một số node nhưng thành công trên các node khác.

Để tránh thực thi một phần, Solana bảo đảm tính nguyên tử trong runtime theo nghĩa ACID, đồng thời bảo đảm tất cả node thống nhất về kết quả của giao dịch: hoặc rollback (nếu có sự cố) hoặc commit (nếu không có sự cố).

Mức commitment trong Solana đo tính chung cuộc của một block (slot) dựa trên số validator đã bỏ phiếu cho nó và độ sâu phiếu bầu của họ trong cơ chế khóa Tower BFT. Nó phản ánh mức độ đồng thuận của mạng đối với slot đó dựa trên phiếu của validator. Mỗi validator bỏ phiếu cho các slot (cụ thể là độ cao block) và cam kết không bỏ phiếu cho các fork xung đột; cơ chế khóa trong Tower BFT bảo đảm cam kết này được thực thi.

Solana có ba trạng thái commitment: processed, confirmed và finalized. Một block được xem là confirmed khi đại đa số validator có stake (≥66%) bỏ phiếu cho nó, và trở thành finalized khi có ít nhất 32 block confirmed được xây dựng bên trên.

Là hệ quả trực tiếp của khả năng thực thi song song lạc quan và lịch leader bất đồng bộ, Solana tuân theo mô hình “thực thi trước, bỏ phiếu sau”: giao thức không chờ tất cả validator đồng ý về một block mới tạo trước khi tạo block tiếp theo. Điều này cũng có thể dẫn đến fork (tức tình huống có hai hoặc nhiều chuỗi cạnh tranh cùng tồn tại). Khi một slot trở thành finalized, mọi fork cạnh tranh đều bị loại bỏ và fork đó trở thành chuỗi chính thức.

Alpenglow

Tại thời điểm viết bài, Solana sử dụng Tower BFT và sổ cái PoH để bảo đảm mạng đạt trạng thái đồng thuận ngay cả khi một số bên tham gia gặp sự cố.

Gần đây, nhóm nghiên cứu tại Anza đã đề xuất một thiết kế mới cho giao thức đồng thuận đơn giản và hiệu quả hơn mang tên Alpenglow. Alpenglow hướng đến cải tổ các thành phần cũ trong thiết kế đồng thuận hiện tại, bao gồm Proof of History, Tower BFT và việc sử dụng gossip để truyền bá phiếu bầu.

Về cốt lõi, Alpenglow sử dụng Votor và Rotor để tăng tốc đồng thuận của Solana:

Votor là cơ chế bỏ phiếu hai tầng, được thiết kế để đạt tính chung cuộc của block trong một vòng nếu 80% stake phản hồi và trong hai vòng nếu ít nhất 60% stake phản hồi.

Rotor tinh chỉnh giao thức Turbine hiện có bằng cách sử dụng một lớp node chuyển tiếp duy nhất để phân phối shred. Rotor cũng tận dụng băng thông của các node tham gia theo tỷ lệ stake để giảm số hop và tối ưu thông lượng của Solana. 

Sui

Khác với Solana sử dụng mô hình lấy tài khoản làm trung tâm, blockchain Sui sử dụng mô hình dữ liệu hướng đối tượng, biểu diễn dữ liệu trạng thái dưới dạng các đối tượng có mã định danh, thuộc tính và phương thức riêng biệt.

Trong Sui, smart contract cũng là một đối tượng gọi là gói Sui Move, có mã định danh duy nhất và dùng để thao tác với các đối tượng. Các gói Sui Move này gồm một tập hợp module Move bytecode của Sui. Mỗi module có tên riêng, và tổ hợp giữa ID on-chain của gói với tên module sẽ xác định duy nhất module đó.

Dù những chi tiết phức tạp về thiết kế đối tượng và metadata nằm ngoài phạm vi bài viết này, cần nhớ rằng mỗi đối tượng đều có một chủ sở hữu quyết định cách đối tượng đó được sử dụng trong giao dịch.

Đối tượng có thể thuộc các mô hình sở hữu sau:

• Đối tượng do địa chỉ sở hữu: Một đối tượng do địa chỉ sở hữu thuộc về một địa chỉ 32 byte cụ thể, có thể là địa chỉ tài khoản hoặc ID đối tượng. Chỉ chủ sở hữu mới có thể truy cập.
• Đối tượng bất biến: Một đối tượng bất biến không thể bị thay đổi, chuyển nhượng hoặc xóa. Chúng không có chủ sở hữu và bất kỳ ai cũng có thể truy cập trên toàn cục để sử dụng.
• Đối tượng dùng chung: Đối tượng dùng chung là đối tượng được chia sẻ và mọi người đều có thể truy cập.
• Đối tượng được bọc: Mô hình này bọc một đối tượng bên trong đối tượng khác. Đối tượng được bọc không tồn tại độc lập và chỉ có thể được truy cập qua đối tượng bao bọc.

Một giao dịch Sui

Trên Sui, giao dịch gồm một nhóm lệnh thực thi trên các đầu vào để xác định kết quả giao dịch. Những nhóm lệnh này được gọi là programmable transaction block (PTB), và chúng xác định mọi giao dịch người dùng trên Sui. PTB cho phép người dùng gọi nhiều hàm Move, quản lý các đối tượng và “coin” của họ trong một giao dịch duy nhất mà không cần xuất bản gói Move mới.

Cấu trúc của một PTB được định nghĩa như sau:

{
    inputs: [Input],
    commands: [Command],
}

inputs là một vector đối số, có thể là đối tượng hoặc giá trị thuần. Các đối tượng này có thể thuộc sở hữu của người gửi, hoặc có thể là đối tượng dùng chung hay bất biến. Trường commands là một vector gồm các lệnh giao dịch cấp cao.

Trong quá trình thực thi PTB, vector đầu vào được điền bằng các đối tượng đầu vào hoặc byte giá trị thuần. Sau đó, các lệnh giao dịch được thực thi theo thứ tự và kết quả được lưu trong vector kết quả, tức một mảng giá trị mà mỗi giá trị có thể thuộc bất kỳ kiểu Move nào dành riêng cho từng lệnh; khác với đầu vào, các giá trị không bị giới hạn ở đối tượng hoặc giá trị thuần. Cuối cùng, các hiệu ứng của giao dịch được áp dụng nguyên tử. 

Dù không thảo luận về cơ chế nội bộ của PTB trên Sui vì đây là một chủ đề phức tạp khác, cần lưu ý rằng khi bắt đầu thực thi, runtime PTB lấy các đối tượng đầu vào đã được tải và đưa chúng vào mảng đầu vào. Các đối tượng đã được mạng xác minh theo những quy tắc như sự tồn tại và quyền sở hữu hợp lệ. Các byte giá trị thuần cũng được tải vào mảng nhưng chưa được xác thực cho đến khi sử dụng.

Ở giai đoạn này, tác động lên gas coin có vai trò đặc biệt quan trọng. Ngân sách gas tối đa được rút khỏi gas coin. Ngân sách gas tối đa thường do người gửi giao dịch chỉ định khi gửi giao dịch, đại diện cho lượng gas tối đa mà giao dịch đó có thể tiêu thụ. Phần gas chưa dùng được hoàn lại vào gas coin khi kết thúc thực thi, ngay cả khi coin đã đổi chủ. Sau đó, từng lệnh giao dịch được thực thi theo thứ tự.

Sau khi gửi, Full node chứng nhận tất cả metadata được cung cấp bằng cách gửi giao dịch đến một node validator (giai đoạn Chứng nhận). Node validator thực hiện mọi bước kiểm tra tính hợp lệ cần thiết đối với giao dịch và ký để xác nhận tính hợp lệ nếu các bước kiểm tra thành công. Để được node validator coi là hợp lệ, giao dịch phải:

• Có chữ ký người dùng hợp lệ.
• Bảo đảm người khởi tạo giao dịch có quyền truy cập mọi đối tượng đầu vào thuộc sở hữu mà giao dịch sử dụng.
• Bảo đảm các đối tượng đầu vào dùng chung mà giao dịch sử dụng tồn tại.
• Chứa lượng gas ít nhất bằng mức được chỉ định trong ngân sách gas của giao dịch.

Nếu tất cả bước kiểm tra đều thành công, validator cố gắng khóa mọi đối tượng inputs thuộc sở hữu vào “transaction digest” đã cho để bảo đảm mỗi đầu vào thuộc sở hữu chỉ có thể được dùng một lần tại một thời điểm.

Nếu quá trình khóa thành công, validator ký giao dịch và trả chữ ký về Full node.

Về cơ bản, full node Sui là chế độ xem chỉ đọc của trạng thái mạng. Khác với node validator, full node không thể ký giao dịch, dù có thể xác thực tính toàn vẹn của chuỗi bằng cách tái thực thi các giao dịch mà một quorum validator đã commit trước đó. Full node không chỉ thu thập một chữ ký validator mà thu thập song song nhiều chữ ký validator nhất có thể; tuy nhiên, chỉ cần đại đa số (⅔+ stake) để tạo chứng chỉ giao dịch.

Thực thi và checkpoint

Sau khi giao dịch được cấp chứng chỉ, chúng được gửi đến một ủy ban validator (tức một tập hợp validator độc lập, cố định cho mỗi epoch) để thực thi. Validator không cần xác minh lại giao dịch mà chỉ cần xác minh các chữ ký trên chứng chỉ. Nếu chữ ký trên chứng chỉ hợp lệ, validator có thể chắc chắn giao dịch hợp lệ.

Trong quá trình thực thi, giao dịch được chia thành hai loại: giao dịch đối tượng thuộc sở hữu và giao dịch đối tượng dùng chung:

Giao dịch đối tượng thuộc sở hữu

Giao dịch đối tượng thuộc sở hữu không truy cập bất kỳ đối tượng đầu vào dùng chung nào và được thực thi ngay lập tức. Chúng còn được gọi là giao dịch fastpath, tức được thực thi sau khi xác thực và commit vào chuỗi chính thức. Các giao dịch này không “đi qua” đồng thuận (cuối cùng giao dịch fastpath vẫn đi qua đồng thuận, nhưng chỉ để tạo thứ tự chính thức nhằm đưa vào checkpoint). Về kỹ thuật, điều này khả thi vì không có rủi ro ghi xung đột, bởi chỉ chủ sở hữu mới có thể sửa đổi đối tượng. 

Giao dịch đối tượng dùng chung

Giao dịch đối tượng dùng chung truy cập các đối tượng dùng chung, do đó phải được sắp xếp qua đồng thuận so với những giao dịch khác sử dụng cùng các đối tượng dùng chung trước khi thực thi. Chúng còn được gọi là giao dịch slowpath. Chúng phải trải qua toàn bộ quy trình đồng thuận để bảo đảm tính nhất quán vì nhiều người dùng có thể truy cập và sửa đổi các đối tượng liên quan. 

Trước đây, mempool Narwhal của Sui tránh tình trạng tắc nghẽn thường gặp bằng cách tách việc phân phối giao dịch khỏi quá trình sắp xếp, lưu giữ các giao dịch đã được chứng nhận và ký trong một Đồ thị có hướng không chu trình (DAG) mà không tự sắp xếp chúng. Sau đó, Bullshark cung cấp thứ tự đồng thuận.

Để tiếp tục cải thiện hiệu suất và khả năng phục hồi, giao thức HammerHead được giới thiệu như một bản nâng cấp cho Bullshark, triển khai lựa chọn leader động dựa trên điểm số. Điều này giảm đáng kể độ trễ và cải thiện thông lượng, đặc biệt khi có leader bị lỗi hoặc gặp sự cố.

Dựa trên những tiến bộ này, Mysticeti hiện thay thế cả Narwhal và Bullshark, hợp nhất việc phân phối và sắp xếp giao dịch thành một giao thức duy nhất. Mysticeti sắp xếp giao dịch theo thứ tự toàn phần, tiếp tục tinh giản quy trình và đạt độ trễ thấp hơn cùng thông lượng cao hơn. Ngoài ra, nhờ mô hình sở hữu lấy đối tượng làm trung tâm của Sui, phần lớn giao dịch vẫn độc lập và không cần cạnh tranh cho một slot sắp xếp toàn cục.

Sau khi giao dịch được thực thi, validator ký các hiệu ứng của giao dịch và trả chúng về full node. Hiệu ứng giao dịch về cơ bản là danh sách mọi hành động mà giao dịch đã thực hiện, chẳng hạn tất cả đối tượng đã bị thay đổi, lượng gas đã tiêu và trạng thái thực thi của giao dịch.

Các chữ ký hiệu ứng tạo thành tập hợp chứng chỉ hiệu ứng mà full node thu thập từ đại đa số validator, bảo đảm giao dịch đã được hoàn tất.

Khi một giao dịch được đưa vào checkpoint, đánh dấu giai đoạn cuối trong vòng đời, các thay đổi trạng thái do giao dịch đó tạo ra đã được hoàn tất và áp dụng vào mạng.

Với giao dịch chỉ liên quan đến các đối tượng đầu vào thuộc sở hữu, validator thực thi và hoàn tất giao dịch trước khi gửi chúng đến lớp đồng thuận để sắp xếp.

Ngược lại, giao dịch liên quan đến đối tượng đầu vào dùng chung được gửi đến đồng thuận để sắp xếp trước khi thực thi và không được gửi lại để đưa vào checkpoint.

Validator thu thập các phần giao dịch đầy đủ, được sắp xếp theo quan hệ nhân quả từ lớp đồng thuận và xây dựng checkpoint. Checkpoint chứa cả danh sách transaction digest lẫn digest tương ứng của hiệu ứng từng giao dịch. Do đó, checkpoint đóng vai trò bản ghi bất biến của mọi chuyển đổi trạng thái đã hoàn tất trong mạng.

Tính chung cuộc

Một giao dịch trên Sui đạt tính chung cuộc ngay khi đại đa số (2𝑓 + 1) validator chấp nhận và đồng ký chứng chỉ giao dịch, ngay cả trước khi chứng chỉ được đồng thuận sắp xếp hoặc được thực thi. Tại thời điểm này, không giao dịch xung đột nào có thể xảy ra và giao dịch không thể bị thu hồi. Với giao dịch chỉ liên quan đến đối tượng thuộc sở hữu, kết quả thực thi được biết ngay khi đạt tính chung cuộc; với giao dịch đối tượng dùng chung, kết quả chỉ được xác định sau khi chứng chỉ được đồng thuận sắp xếp. Giao dịch đạt tính chung cuộc trong hai lượt khứ hồi mạng.

Quyết toán xảy ra khi giao dịch được đại đa số validator thực thi và chứng chỉ hiệu ứng được tạo. Với giao dịch đối tượng thuộc sở hữu, việc thực thi diễn ra ngay lập tức mà không cần chờ đồng thuận. Với giao dịch đối tượng dùng chung, việc thực thi và quyết toán diễn ra ngay sau khi chứng chỉ được đồng thuận sắp xếp. Trong cả hai trường hợp, checkpoint không làm chậm quyết toán, nhờ đó độ trễ thấp hơn quy trình tạo checkpoint.

Dù chứng chỉ giao dịch là dấu hiệu mạnh về tính chung cuộc, chỉ chứng chỉ hiệu ứng hoặc việc được đưa vào checkpoint đã chứng nhận mới cung cấp bảo đảm tuyệt đối, vì các trường hợp này yêu cầu đại đa số validator thực thi và commit hiệu ứng giao dịch.

Ở cấp độ tổng quan, vòng đời giao dịch Sui tận dụng mô hình lấy đối tượng làm trung tâm để tối đa hóa khả năng song song và hiệu quả. Khi giao dịch được gửi để chứng nhận, validator cố gắng khóa các phiên bản cụ thể của đối tượng đầu vào mà giao dịch tham chiếu.

Với đối tượng thuộc sở hữu, các khóa này được giành ngay trong quá trình chứng nhận, bảo đảm quyền truy cập độc quyền và ngăn chi tiêu hai lần. Với đối tượng dùng chung, khóa chỉ được thiết lập sau khi giao dịch được sắp xếp qua giao thức đồng thuận của Sui.

Sau khi có được tất cả khóa cần thiết, giao dịch được lên lịch thực thi. Thiết kế này cho phép các giao dịch hoạt động trên những tập đối tượng không giao nhau được thực thi độc lập và song song, giảm đáng kể tranh chấp và tắc nghẽn giữa các phần trạng thái không liên quan.

Sau khi thực thi thành công, validator ký hiệu ứng giao dịch. Khi thu thập được đại đa số chữ ký, chứng chỉ hiệu ứng được tạo. Chứng chỉ này bảo đảm tính chung cuộc của quyết toán, cho biết giao dịch giờ đây không thể đảo ngược và các hiệu ứng của nó là vĩnh viễn.

Checkpoint không nằm trên đường dẫn trọng yếu của quá trình thực thi hoặc đạt tính chung cuộc của giao dịch. Thay vào đó, chúng được xây dựng sau khi thực thi để cung cấp thứ tự giao dịch chính thức và hỗ trợ đồng bộ trạng thái cho các node không trực tiếp tham gia thực thi.

Mô hình đối tượng của Sui cho phép theo dõi chính xác các phụ thuộc ở cấp đối tượng, loại bỏ nhu cầu đồng bộ trạng thái toàn cục. Kiến trúc này hỗ trợ thực thi phân tán có khả năng mở rộng trên phần cứng phổ thông, thay vì dựa vào những tiến bộ về hiệu năng phần cứng để đạt thông lượng cao hơn.

Góc nhìn về thực thi, khả năng mở rộng và các đánh đổi trong thiết kế

Như đã nêu, hiểu vòng đời giao dịch có thể là cách thể hiện rõ nhất triết lý thiết kế của blockchain. Sự khác biệt trong vòng đời giao dịch giữa Solana và Sui cho thấy những triết lý sâu sắc về mô hình thực thi trên ba phương diện quan trọng: hiệu quả thực thi, ngưỡng mở rộng và các đánh đổi trong thiết kế.

Thực thi

Là một chuỗi lấy tài khoản làm trung tâm, Solana phát hiện động xung đột tài khoản thông qua việc khóa tài khoản trong Giai đoạn Banking. Điều này bảo đảm các giao dịch không sửa đổi cùng một tài khoản được xử lý song song, còn các giao dịch xung đột được xử lý tuần tự.

Dù cơ chế phát hiện tài khoản này có thể làm tăng chi phí runtime trong các tình huống DeFi tải nặng, đặc biệt khi chương trình cần thực thi logic trong chương trình khác (một cơ chế gọi là Cross-Program Invocation), công cụ thực thi của Solana vẫn đạt khả năng song song hóa rất lớn nhờ phát hiện xung đột động. Nhờ đó, chuỗi có thể thực thi giao dịch gần như tức thời với mức phí cực thấp.

Trong khi đó, Sui không cần lo về giao dịch xung đột vì khả năng song song được suy ra tại thời điểm biên dịch nhờ mô hình sở hữu lấy đối tượng làm trung tâm. Mô hình đối tượng dùng chung và đối tượng thuộc sở hữu cho phép suy ra xung đột theo cách tĩnh và đạt chi phí runtime gần như bằng không cho giao dịch đối tượng thuộc sở hữu.

Ngưỡng mở rộng

Về khả năng mở rộng, Sui đạt mở rộng theo chiều ngang và có thể mở rộng tuyến tính theo các phân vùng đối tượng bằng cách xử lý giao dịch đối tượng thuộc sở hữu mà không cần đồng thuận toàn cục, cho phép đạt tính chung cuộc gần như tức thời, dưới một giây và thông lượng chỉ bị giới hạn bởi phần cứng sẵn có. Giao dịch đối tượng dùng chung cần đồng thuận, nhưng với bản nâng cấp Mysticeti, chúng giờ đây cũng đạt tính chung cuộc dưới một giây và thông lượng cao. Kiến trúc của Sui cho phép cả việc phân phối block lẫn thực thi co giãn bằng cách bổ sung tài nguyên, giúp hệ thống xử lý hiệu quả khối lượng công việc gia tăng, dù đường đồng thuận không vô hạn như đường nhanh dành cho đối tượng thuộc sở hữu.

Do sử dụng cách tiếp cận một leader và phân phối thực thi bị giới hạn bởi tranh chấp tài khoản, Solana dường như chạm một ngưỡng mở rộng theo chiều ngang do mô hình trạng thái toàn cục một shard và cơ chế tiếp nhận giao dịch theo từng slot lấy leader làm trung tâm. Tuy nhiên, Solana tối ưu mạnh mẽ trong ngưỡng này bằng pipeline được xác định rõ, có PoH hỗ trợ. Giao dịch có thể được sắp xếp chính xác, xử lý trong chưa đến 400ms và đạt xác nhận lạc quan trong chưa đến một giây. Về mở rộng theo chiều dọc, Solana mở rộng mạnh theo phần cứng validator, đặc biệt là số lõi CPU và RAM, vì điều này hoàn toàn phù hợp với thiết kế vốn có.

Cần phân định rõ rằng Solana chọn mở rộng theo chiều dọc thay vì chiều ngang và chạm giới hạn do các đánh đổi trong thiết kế, chứ không phải do lỗi kiến trúc. Một số hướng tiếp cận theo chiều ngang (ví dụ thị trường phí cục bộ, subnet ảo và giảm thiểu trạng thái qua CMT) hiện đang được phát triển.

Các đánh đổi trong thiết kế

Solana bảo đảm tính tất định thông qua các ràng buộc runtime nghiêm ngặt, sự cô lập tài khoản và lịch leader tất định. Cơ chế giải quyết tranh chấp tài khoản động và pipeline được xác định rõ hỗ trợ tương tác sâu giữa các chương trình, cho phép Solana đạt khả năng kết hợp mạnh mẽ.

Sui bảo đảm tính tất định qua các đường thực thi tích hợp được xác định bằng phân tích quyền sở hữu đối tượng. Đồng thời, mô hình lấy đối tượng làm trung tâm của Sui hỗ trợ khả năng kết hợp thông qua đối tượng dùng chung và programmable transaction block (PTB), cho phép các tương tác phức tạp và thao tác nguyên tử giữa nhiều contract và người dùng. Điều này khả thi vì chủ sở hữu của một đối tượng có thể là một đối tượng khác, cho phép khả năng tương tác ở cấp đối tượng và tổ chức đối tượng thành các cây sở hữu. Những cấu trúc như vậy đặc biệt hữu ích khi các đối tượng thường xuyên được dùng cùng nhau hoặc khi cần tra cứu runtime để xác định đối tượng cần thao tác trong quá trình thực thi.

Tóm tắt

Cơ chế xử lý giao dịch từ lúc gửi đến khi đạt tính chung cuộc là nền tảng cho hiệu suất cao đáng kinh ngạc của Solana và Sui. Bằng cách xem xét vòng đời giao dịch, chúng ta có thể hiểu rõ các pipeline được thiết kế kỹ lưỡng nhằm bảo đảm độ trễ thấp và thông lượng cao cho cả hai chuỗi.

Solana được thiết kế theo mô hình lấy tài khoản làm trung tâm, và giao dịch trải qua một loạt quy trình đa luồng cùng pipeline để bảo đảm tính hợp lệ. Giao dịch được gửi đến leader, nơi chạy pipeline TPU để bảo đảm giao dịch được xác minh và lên lịch phù hợp: song song nếu không xung đột và tuần tự nếu có xung đột. Khi validator không sản xuất block, nó chạy pipeline TVU để sao chép và xác thực giao dịch. Cả TPU và TVU đều sử dụng runtime. Nhờ đó, Solana xử lý hàng nghìn giao dịch trong thời gian rất ngắn vì runtime có thể suy ra trước và theo cách tất định những tài khoản không chồng lấp, rồi thực thi song song các giao dịch không xung đột. Điều này khiến Solana phù hợp với các trường hợp thực tế như giao dịch tần suất cao, DeFi có khả năng kết hợp sâu, dApp phụ thuộc nhiều vào hạ tầng và dApp tiêu dùng có độ trễ thấp.

Trong khi đó, Sui sử dụng mô hình lấy đối tượng làm trung tâm, trong đó mỗi đối tượng được theo dõi bằng một mã định danh duy nhất. Bằng cách suy ra quyền sở hữu đối tượng, Sui có thể xác định tĩnh liệu một giao dịch có thể được thực thi song song hay không nếu giao dịch đó tác động đến các tập đối tượng không giao nhau. Thông qua mô hình đường thực thi kép (tức tách giao dịch thành giao dịch đối tượng thuộc sở hữu và giao dịch đối tượng dùng chung, đồng thời sử dụng checkpoint đã ký để giữ các Full node đồng bộ), Sui có thể xử lý giao dịch nhẹ mà không tạo gánh nặng cho lớp đồng thuận, trong khi vẫn đạt tính chung cuộc nhanh, đáng tin cậy và đồng bộ hiệu quả cho các node mới. Điều này cho phép Sui mở rộng theo chiều ngang khi tải tăng và rất hữu ích cho các ứng dụng có lượng tương tác đối tượng lớn, chẳng hạn DeFi, trò chơi, sàn giao dịch lấy tài sản làm trung tâm và tài sản có thể lập trình.

Tài liệu tham khảo

• Tài liệu chính thức của Solana
• Tài liệu chính thức của Anza
• Tài liệu chính thức của Sui
• Gulf Stream: Giao thức chuyển tiếp giao dịch không dùng mempool của Solana
• Sealevel — Xử lý song song hàng nghìn smart contract
• Cross-Program Invocation và PDA — sự kết hợp của hai cơ chế mạnh mẽ trên Anchor
• Narwhal và Tusk: Mempool dựa trên DAG và đồng thuận BFT hiệu quả
• Mở rộng quy mô thực thi Sui với Pilotfish
• SUI và Solana - TrustWallet
• Tower BFT: Cách Solana triển khai PBFT hiệu suất cao
• David J DeWitt và Jim N Gray: “Hệ thống cơ sở dữ liệu song song: Tương lai của các hệ thống cơ sở dữ liệu hiệu suất cao,” Communications of the ACM, tập 35, số 6, trang 85–98, tháng 6 năm 1992. doi:10.1145/129888.129894
• Jim N Gray và Leslie Lamport: “Đồng thuận về commit giao dịch,” ACM Transactions on Database Systems (TODS), tập 31, số 1, trang 133–160, tháng 3 năm 2006. doi:10.1145/1132863.1132867
• Leslie Lamport: “Thời gian, đồng hồ và thứ tự sự kiện trong một hệ thống phân tán,” Communications of the ACM, tập 21, số 7, trang 558–565, tháng 7 năm 1978.
• Michael J Fischer, Nancy Lynch và Michael S Paterson: “Tính bất khả thi của đồng thuận phân tán khi có một tiến trình bị lỗi,” Journal of the ACM, tập 32, số 2, trang 374–382, tháng 4 năm 1985. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: “MYSTICETI: Tiến đến giới hạn độ trễ với DAG không được chứng nhận”, [cs.DC], tháng 7 năm 2024.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: “HammerHead: Danh tiếng leader cho việc lập lịch động”, [cs.CR], tháng 9 năm 2023.