Sui & Aptos: Những điều cơ bản về cấu trúc và vận hành

Những điểm chung cơ bản của Aptos và Sui

Quy trình xử lý giao dịch

Các validator sẽ phê chuẩn các giao dịch một cách riêng lẻ. Điều này sẽ giúp giảm được độ trễ mạng và tăng cao số lượng giao dịch trên một giây. Quá trình xử lý giao dịch của Aptos và Sui có thể được tóm lược như sau:

1. Người dùng gửi đi các giao dịch
2. Các validator sẽ vote cho các giao dịch đó dựa vào các luật lệ về cơ chế đồng thuận Proof of Stake.
3. Sender sẽ thu thập những vote của các validator và tạo chúng thành 1 Certificate.
4. Sender phát đi certificate này.

Người dùng có thể thực hiện nhiều giao dịch con trên các tài khoản on-chain khác nhau chỉ trong một giao dịch gốc. Ví dụ, một người dùng có thể chuyển 100 ETH sang các tài khoản khác nhau chỉ trong 1 giao dịch.

Ngôn ngữ Move

Move là một ngôn ngữ được phát triển dựa trên ngôn ngữ lập trình Rust. Việc sử dụng ngôn ngữ Move sẽ giúp cho Aptos, Sui thu hút một lượng lớn các dev từ các hệ sinh thái blockchain sử dụng nền tảng là ngôn ngữ Rust như Solana, Near, CosmWASM và Polkadot.

Ngôn ngữ Move tập trung chủ yếu vào sự di chuyển các tài sản. Các asset có thể vừa là input vừa là ouput của một hàm. Việc này giúp gia tăng khả năng tương tác (Interproperability) của các dự án sử dụng ngôn ngữ Move.

Trạng thái của các giao dịch sẽ được lưu trữ ở tài khoản của chính các users. Users sẽ cần trả tiền để lưu trữ các trạng thái giao dịch đó và sẽ được hoàn lại tiền nếu xóa bỏ chúng.

Aptos sử dụng ngôn ngữ Move nguyên bản từ Libra (Diem) trong khi đó Sui đã điều chỉnh một số thứ để ngôn ngữ này phù hợp hơn cho việc phát triển GameFi.

Vấn đề của các dự án sử dụng EVM

Có thể nói EVM là nền tảng máy ảo xử lý Smart Contract có thị phần lớn nhất hiện nay. Kể từ khi EVM được phát minh, nó đã được sử dụng bởi rất nhiều các dev/dự án và hệ sinh thái từ Ethereum cho đến BNB Smart Chain, Avalanche, Polygon.

Thế nhưng EVM đang tồn tại một điểm yếu cố hữu là việc xử lý các giao dịch phải theo tuần tự. Máy chủ EVM luôn luôn để các giao dịch khác vào trạng thái chờ khi đang xử lý một giao dịch và chỉ khi giao dịch đó được hoàn thành thì trạng thái của blockchain mới được cập nhật lại. Kể cả khi có 2 giao dịch không liên quan và phụ thuộc đến nhau ví dụ như một giao dịch chuyển tiền từ người A sang B và một giao dịch chuyển tiền từ người C sang D thì EVM không thể xủ lý được 2 giao dịch này song song với nhau. Trong khi không thể phủ nhận ràng cách xử lý giao dịch theo tuần tự này rất phù hợp với flash loan, thế nhưng nó không mang tới hiệu quả cao và rất khó để có thể scale (mở rộng).

Việc xử lý giao dịch theo tuần tự đã trở thành nút thắt trong throughput của mạng lưới. Số lượng giao dịch trung bình mà Ethereum có thể xử lý trong 1s hiện tại chỉ vào khoảng 11.8- 13.8 Transaction Per Second.

Sự hạn chế trong tốc độ và khả năng xử lý giao dịch có thể dẫn đến những hậu quả lớn hơn như việc các con bot thi nhau tăng phí gas để giao dịch của mình được ưu tiên xử lý. Làm cho phí gas tăng cao đột ngột. Việc này làm cho mức phí gas của Ethereum có lúc chạm ngưỡng trung bình 0.2 ETH khiến cho không ít người dùng cảm thấy ngán ngẩm vì số tiền bỏ ra cho 1 giao dịch là quá lớn.

Vấn đề tiếp theo của việc xử lý các giao dịch theo tuần tự của EVM là sự thiếu hiệu quả của mạng lưới các node. Phương pháp xử lý này không tận dụng được các chíp đa nhân, làm hạn chế khả năng mở rộng của mạng lưới cũng như làm tiêu tốn quá nhiều năng lượng điện không cần thiết.

Parallel Execution - Giải pháp được sử dụng bởi Aptos và Sui

Nắm bắt được điểm yếu chí mạng của EVM, các Layer 1 sinh sau đẻ muộn đang tập trung vào một cơ chế xử lý giao dịch khác - Parallel Execution. Việc xử lý song song các giao dịch khác nhau sẽ tối ưu được khả năng xử lý đa luồng của các con chíp hiện nay, tận dụng được tối đa hiệu năng cũng như mở ra khả năng tốt hơn cho việc mở rộng mạng lưới. Tận dụng được tối đa các luồng của chíp cũng sẽ trực tiếp ảnh hưởng đến tốc độ xử lý giao dịch của các dự án sử dụng cơ chế Parallel Execution. Trong những thời điểm khi mà lượng giao dịch đạt đỉnh cao thì các validator có thể cho phép nhiều hơn các nhân của chíp hoạt động để xử lý nhiều giao dịch cùng một lúc hơn.

Tận dụng tài nguyên tốt hơn, xử lý được nhiều hơn và cải thiện được trải nghiệm người dùng là 3 ý chính để tóm gọn lại ưu điểm của Parallel Execution.

Một ưu điểm khác của phương pháp này nằm ở việc cải thiện độ trễ khi xác thực giao dịch. Việc này cũng dựa trên sự tận dụng được tối đa tài nguyên của phần cứng. Các giao dịch sẽ không cần phải xếp hàng dài hàng chục hàng trăm block hay phải trả thêm lượng phí đắt đỏ để được ưu tiên nữa. Một khi đảm bảo được độ trễ thấp khi xác thực giao dịch, Parallel Execution sẽ mở ra cánh cửa cho những use case không thể thực hiện được trước đây.

Trên thực tế, concept của Parallel Execution rất đơn giản. Cơ chế hoạt động của nó là nhận diện xem những giao dịch nào không phụ thuộc vào nhau và xử lý những giao dịch đó đồng thời. Điểm mấu chốt ở đây là làm sao để biết những giao dịch nào phụ thuộc vào nhau và những giao dịch nào thì không.

Ví dụ cho những dependent transactions (giao dịch phụ thuộc vào nhau) là khi bạn thực hiện 2 giao dịch swap liên tiếp trong cùng một Liquidity Pool. Hai giao dịch đó phụ thuộc lẫn nhau và cần phải được thực hiện tuần tự chứ không thử thực hiện đồng thời. Để giải quyết vấn đề xác định tính phụ thuộc của các giao dịch, cả Aptos và Sui đều có những phương pháp khác nhau trong Parallel Execution của mình, những điểm khác nhau này sẽ được phân tích kĩ hơn ở phần tiếp theo.

So sánh chi tiết về cấu trúc của Aptos và Sui

Consensus

Cả Aptos và Sui đều có cốt lõi là cơ chế đồng thuận Byzantine Fault Tolerance. Và bạn không nhầm đâu, nó được dựa trên bài toán kinh điển “Vấn đề của các vị tướng Byzantine” (Byzantine Generals Problem) của khoa học máy tính về đường truyền dữ liệu. Nôm na mà nói, hoàn cảnh của bài toán này là những vị tướng Byzantine đang muốn đưa ra một quyết định chung là tiến đánh hay rút lui. Vấn đề ở đây không nằm ở việc họ chọn tiến đánh hay rút lui mà nằm ở việc quyết định đó phải được tất cả đồng thuận và làm theo thì mới có thể giành được phần thắng. Mỗi quyết định của một vị tướng sẽ được phát đi cho các vị tướng khác bằng người đưa thư. Từ đó, có những vấn đề sau nảy sinh:

• Thông tin gửi đi có thể bị delay, mất, thay đổi hoặc phá hủy bởi người đưa thư.
• Vì một lí do nào đó, một hay nhiều vị tướng có thể cố tình phá thế cuộc bằng cách phát đi những tín hiệu sai lầm, gây confuse cho các vị tướng khác.

Nếu ta áp dụng bài toán này vào blockchain thì một node sẽ đóng vai trò là một vị tướng, và các node phải đồng thuận với nhau về trạng thái của mạng lưới (quyết định đánh hay lùi). Nói cách khác, phần đa số của các node phải đồng thuận với nhau về một quyết định và hành động đúng theo quyết định đó. Do đó, cách duy nhất để giải quyết bài toán này là số node đáng tin cậy phải chiếm ít nhất 2/3 tống số các node. Từ đó cơ chế đồng thuận Byzantine Fault Tolerance ra đời, nó cho phép nhiều nhất 1/3 số validator có thể offline hoặc cố tình làm sai lệch thông tin thì mạng lưới vẫn có thể hoạt động bình thường.

Aptos

Aptos sử dụng cơ chế đồng thuận AptosBFT dựa trên cơ chế cũ phát triển bởi Diem là DiemBFT:

• Một leader sẽ suggest một block và các validator còn lại sẽ vote cho block đó.
• Do các validator chỉ giao tiếp với leader nên số message được phát đi nhỏ hơn rất nhiều so với trường hợp các validator gửi message cho lẫn nhau
• Người được chọn làm leader sẽ thay đổi qua từng vòng voting và sẽ được chọn ngẫu nhiên.
• Leader có thể làm việc với nhiều block khác nhau cùng lúc - cơ chế hoạt động này gọi là Pipelining.

Sui

Sui có nhiều điểm đột phá hơn. Một trong số đó là việc loại bỏ cơ chế đồng thuận đối với các giao dịch đơn giản. Những giao dịch độc lập như chuyển các token qua các địa chỉ ví khác nhau sẽ được hoàn thành gần như tức khắc.

Tuy nhiên đối với các giao dịch phức tạp hơn (phụ thuộc lẫn nhau như đã đề cập ở phần trước) thì Sui cũng dùng cơ chế đồng thuận BFT nhưng kiểu truyền thống hơn so với Aptos.

Việc phân loại giao dịch và sử dụng các cơ chế đồng thuận khác nhau đối với từng loại làm cho Sui trở thành một Layer 1 hoàn hảo cho những dApp có nhu cầu tạo ra nhiều giao dịch đơn giản, yêu cầu việc xử lý nhanh gọn và không quan tâm lắm đến vấn đề phi tập trung (ví dụ như GameFi và Airdrop).

Cơ chế đồng thuận của Sui có một cái tên khá thú vị là Narwhal and Bullshark (trước đây là Narwhal and Tusk). Thực chất đây là một module được phát triển bởi mốt số researchers tới từ cả Mysten Labs và Aptos Labs nhưng nó có mã nguồn mở nên bất cứ blockchain nào cũng có thể tích hợp sử dụng (thực tế thì đã có Celo và Sommerlier sử dụng module này). Việc đặt tên của module này cũng có ý nghĩa riêng khi mà Narwhal và Bullshark sẽ đảm nhận 2 vai trò riêng biệt của cơ chế đồng thuận:

• Narwhal: Đảm bảo tính availability của các data được gửi đến cơ chế đồng thuận với mô hình Directed Acylic Graph (DAG) và hoạt động giống với chức năng giống như một Mempool.
• Bullshark (hoặc trước đó là Tusk): Cơ chế đồng thuận dựa trên BFT giúp ordering các giao dịch từ Narwhal.
• Lưu ý: Narwhal và BullShark là 2 thành phần tách biệt trong cơ chế đồng thuận của Sui, Narwhal có thể kết hợp được với cả Tendermint và Tusk, việc chọn Bullshark là do Mysten Labs đánh giá cao Bullshark hơn Tusk ở việc cải thiện Latency và cải fairness (tính công bằng).

Ưu điểm của cặp đôi Narwhal và Bullshark là sự kết hợp của 2 hệ thống này có thể giải quyết 2 vấn đề sau:

• Sự tăng vọt về Latency trước khi xử lý giao dịch đối với các blockchain đang thử nghiệm việc tăng blocksize.
• Các blockchain có khả năng xử lý giao dịch nhanh nhưng Mempool và Consensus của nó lại không theo kịp

Để hiểu rõ hơn về Latency thì các bạn hãy sang đọc bài viết này:

Blockchain 101  và Bản chất của Scaling Blockchain

Parallel Execution - Xử lý song song

Aptos

Aptos được xây dựng trên ngôn ngữ Move để tạo ra blockchain có TPS cao sử dụng cơ chế Parallel Execution. Như đã đề cập ở trên, Sui và Aptos sẽ có những cơ chế khác nhau để giải quyết vấn đề phân biệt sự phụ thuộc của các giao dịch. Đối với Aptos, blokchain này sử dựng một phiên bản tinh chỉnh của Software Transaction Memory (STM) gọi là Block-STM. Block-STM có nhiệm vụ đưa các giao dịch vào trạng thái pre-ordered ở các block và được phân tách ở các luồng xử lý khác nhau để chuẩn bị cho Optimistic Execution. Cái tên Optimistic Execution đã nói lên tất cả. Các giao dịch đã được chuẩn bị sẵn này sẽ được cho là không phụ thuộc lẫn nhau (giống như việc Optimistic Rollups assume các giao dịch off-chain đều valid). Khi các giao dịch này làm thay đổi bộ nhớ thì việc làm đó sẽ được lưu lại. Tất cả các kết quả giao dịch sẽ được xác thực sau khi giao dịch được xử lý. Trong lúc xác thực, nếu bất kì giao dịch nào bị phát hiện là có truy cập đến phần bộ nhớ được thay đổi bởi giao dịch trước (tức là 2 giao dịch này có phụ thuộc nhau) thì giao dịch đó sẽ được xác định là invalid. Kết quả của giao dịch đó sẽ bị hủy bỏ và giao dịch đó sẽ được xử lý lại. Quy trình này sẽ lặp đi lặp lại cho đến khi tất cả giao dịch trong block đó được xử lý.

Block-STM cải thiện tốc độ xử lý giao dịch khá đáng kể khi nó tận dụng được chíp đa nhân (điều mà Ethereum đã lãng phí với cơ chế sequential execution). Việc tốc độ được cả thiện bao nhiêu tất nhiên còn phụ thuộc vào các giao dịch đầu vào có mức độ phụ thuộc lẫn nhau cỡ nào. Đội ngũ phát triển của Aptos đã tự tin khẳng định rằng với chip 32 nhân thì tốc độ của Aptos sẽ được cải thiện nhanh gấp 8 lần đối với các giao dịch có mức độ phụ thuộc lẫn nhau cao và gấp 16 lần với giao dịch có mức độ phụ thuộc lẫn nhau thấp. Trong trường hợp xấu nhất tất cả các giao dịch đều phụ thuộc vào nhau thì Block-STM sẽ còn xử lý giao dịch chậm hơn cả sequential execution. Throughput của Aptos được dự đoán có thể chạm lên đến mức 160,000 TPS.

Sui

Khác với Aptos, Sui lại chọn một phương thức tiếp cận giống với Solana hơn. Solana định nghĩa lại một Memory Cell (đơn vị của bộ nhớ máy tính) sẽ là một account và khi một giao dịch sửa đổi account nào đó, nó phải thông báo là mình đã sửa đổi account nào (Aptos không yêu cầu các giao dịch chỉ ra chúng đã can thiệp vào phần nào của memory).

Sui sử dụng mô hình lưu trữ các trạng thái của giao dịch để xác định tính phụ thuộc của chúng. Bằng cách gán ID cho các object (các object đại diện cho các asset có thể được chia sẻ, tức là nhiều người có thể thay đổi, chỉnh sửa các object đó), Sui có thể dễ dàng xác định được tính phụ thuộc lẫn nhau của các giao dịch chỉ đơn giản thông qua việc kiểm tra xem các giao dịch đó có đang sử dụng chung một object hay không.

Mô hình phức tạp hơn của Sui đồng nghĩa với việc giảm bớt áp lực cho Parallel Execution Engine và tăng thêm gánh nặng cho các developer trong việc xác định tính phụ thuộc của các giao dịch. Developer sẽ phải làm quen với mô hình mới của Sui và tập viết Apps/ Smart Contracts hổ trợ khai báo loại giao dịch (independent/ dependent) ngay từ đầu. Từ đó ta có thể suy ra về lý thuyết thì Sui sẽ có performance và khả năng mở rộng tốt hơn nhưng developers sẽ cần thêm thời gian hơn để làm quen.

Nhận định

Sui hay Aptos đều là những dự đáng trông chờ trong những năm tới. Trước giờ chỉ có Solana đi tiên phong trong việc áp dụng Parallel Execution, nay có thêm Sui và Aptos. Dù mô hình là khác nhau nhưng Parallel Execution là một hướng đi đáng mong chờ trong việc scaling blockchain bên cạnh các giải pháp Layer 2. Dù chưa thực sự ra mắt, nhưng những cải tiến về công nghệ do Sui và Aptos đưa ra rất đáng được mong chờ, hứa hẹn sẽ thúc đẩy sự cải tiến cho các Layer 1.