Chương 3: Solana

Tổng quan

Solana là một blockchain lớp 1 (Layer 1) hiệu suất cao ra mắt mainnet vào năm 2020, được thiết kế với tham vọng trở thành "blockchain nhanh nhất thế giới". Thay vì chỉ cải thiện các công nghệ hiện có, Solana tiếp cận bài toán mở rộng của Ethereum — tốc độ xử lý chậm và phí giao dịch cao — bằng những đổi mới kiến trúc triệt để. Điểm khác biệt cốt lõi của Solana nằm ở việc kết hợp các công nghệ độc đáo như Thực thi song song (Parallel Execution) và Proof of History (PoH), hướng tới mục tiêu xử lý hàng chục nghìn giao dịch mỗi giây.

Trong chương này, chúng ta sẽ đi sâu vào 7 khái niệm cốt lõi tạo nên bản sắc của Solana. Bắt đầu từ các đổi mới ở tầng kiến trúc là Thực thi song song và Proof of History (PoH), tiếp đến là Program Derived Address (PDA) — cơ chế nâng cao bảo mật và trải nghiệm phát triển, rồi đến Thị trường phí cục bộ (Local Fee Markets) — mô hình phí giao dịch mang tính đột phá. Sau đó là Gulf Stream và Turbine — hai giao thức tối ưu hóa hiệu quả mạng lưới. Cuối cùng, chúng ta sẽ xem xét bản nâng cấp Alpenglow — yếu tố sẽ quyết định tương lai của Solana — để có được cái nhìn toàn diện về hiện tại lẫn hướng đi phía trước của nền tảng này.

Solana được ghi nhận với hiệu suất vượt trội, nhưng đồng thời cũng nhận không ít chỉ trích về các sự cố gián đoạn mạng lưới và lo ngại về mức độ tập trung hóa. Mục tiêu của chương này là giúp bạn đọc nắm bắt cân bằng cả điểm mạnh lẫn những đánh đổi trong kiến trúc Solana, từ đó đánh giá một cách phê phán giải pháp mở rộng blockchain độc đáo mà nền tảng này mang lại.

---

Thực thi song song (Parallel Execution)

Định nghĩa

Thực thi song song là cơ chế Solana dùng để xử lý giao dịch, trong đó các giao dịch tác động lên các tài khoản (account) khác nhau được thực thi đồng thời trên nhiều nhân CPU. Điều kiện tiên quyết để điều này khả thi là mỗi giao dịch phải khai báo trước danh sách tài khoản mà nó sẽ đọc hoặc ghi vào. Dựa trên khai báo này, runtime sẽ xác định trước xem các giao dịch có xung đột với nhau không: các giao dịch không xung đột được chạy song song, còn các giao dịch cùng truy cập một tài khoản thì xử lý tuần tự. Solana triển khai cơ chế này thông qua runtime song song mang tên Sealevel.

Điểm mấu chốt

• Nhiều quầy thanh toán vs. một hàng đợi duy nhất: Ethereum truy cập trạng thái toàn cục (global state) theo mô hình tuần tự — giống như một siêu thị chỉ mở một quầy thu ngân duy nhất. Solana thì ngược lại, vận hành như một siêu thị mở nhiều quầy thanh toán cùng lúc: các giao dịch xử lý các tài khoản khác nhau không cần phải xếp vào cùng một hàng, mà chạy độc lập và song song với nhau.

• Tầm quan trọng của khai báo trước (Pre-declaration): Mọi giao dịch trên Solana đều phải liệt kê rõ ràng danh sách tài khoản sẽ truy cập trước khi thực thi. Yêu cầu này là điều kiện bắt buộc để thực thi song song hoạt động, nhưng đồng thời cũng đặt thêm gánh nặng thiết kế lên vai các nhà phát triển. Các kiến trúc xác định đối tượng truy cập một cách động trong quá trình chạy sẽ phức tạp hơn đáng kể khi triển khai trên Solana.

• Lợi thế về hiệu suất: Thực thi song song là lý do nền tảng nhất giải thích tại sao Solana tuyên bố xử lý được hàng chục nghìn giao dịch mỗi giây. Các máy chủ hiện đại sở hữu hàng chục nhân CPU, vì vậy về lý thuyết, hiệu suất xử lý có thể tăng tỉ lệ thuận với số lượng nhân.

• Xử lý tuần tự khi xung đột: Các giao dịch cùng truy cập một tài khoản vẫn phải xử lý tuần tự. Khi hàng nghìn giao dịch đổ vào cùng một tài khoản — như trong các giao thức DeFi nổi tiếng hay sự kiện mint NFT — lợi thế của thực thi song song giảm đi đáng kể và bottleneck xuất hiện.

• Sự khác biệt căn bản với Ethereum: EVM của Ethereum được tối ưu hóa cho thực thi tuần tự với mô hình chuyển trạng thái toàn cục (global state transition). Để Ethereum áp dụng thực thi song song, cần bổ sung các thiết kế phức tạp như dự đoán truy cập tài khoản hay song song hóa lạc quan (optimistic parallelization). Ngược lại, Solana được xây dựng từ đầu với thực thi song song là nguyên lý thiết kế cốt lõi.

Mối liên hệ với các khái niệm khác

Thực thi song song kết nối mật thiết với tất cả các khái niệm liên quan đến hiệu suất của Solana. Thị trường phí cục bộ được thiết kế để phối hợp nhịp nhàng với thực thi song song: khi giao dịch dồn vào một tài khoản cụ thể, chỉ phí của tài khoản đó tăng lên, còn các luồng thực thi song song khác không bị ảnh hưởng. Gulf Stream đóng góp cho thực thi song song bằng cách chuyển giao dịch đến leader trước, giúp thu thập và sắp xếp thông tin tài khoản cần thiết từ sớm. Bản nâng cấp Alpenglow giữ nguyên kiến trúc thực thi song song trong khi cải thiện mạnh mẽ tầng đồng thuận, tạo ra hiệu ứng cộng hưởng tối đa cho toàn hệ thống.

---

Proof of History (PoH)

Định nghĩa

Proof of History (PoH) là cơ chế ghi nhận thời gian bằng mật mã học do Solana sáng tạo ra. Cơ chế này tạo ra một chuỗi hash SHA-256 liên tục, cho phép chứng minh về mặt toán học rằng các sự kiện nhất định đã xảy ra theo một thứ tự nhất định, tại một thời điểm nhất định. Trong các blockchain thông thường, các node cần trao đổi thông điệp phức tạp để đồng thuận về thứ tự và thời điểm xảy ra của các sự kiện. PoH thay thế quá trình đó bằng dấu thời gian mật mã học, giảm chi phí overhead của đồng thuận và tăng tốc độ xử lý. Cần lưu ý rằng PoH không phải là thuật toán đồng thuận độc lập — nó là tầng ghi nhận thời gian hỗ trợ cho cơ chế đồng thuận PoS của Solana, tức Tower BFT.

Điểm mấu chốt

• Chuỗi hash liên tục: PoH được triển khai bằng cách liên tục lấy đầu ra của hash trước làm đầu vào cho hash tiếp theo (sequential hashing). Do mỗi bước tính toán đều tốn thời gian, sự tồn tại của một giá trị hash nhất định đồng nghĩa với việc tất cả các hash trước đó chắc chắn đã được tính toán. Nói cách khác, thứ tự không thể bị làm giả.

• Vai trò đồng hồ toàn cục đáng tin cậy: Trong các hệ thống phân tán truyền thống, đồng bộ hóa thời gian giữa các node là một bài toán khó. PoH cung cấp một chiếc đồng hồ mật mã học tích hợp sẵn trong blockchain, cho phép tất cả người tham gia xác minh thứ tự tương đối của các sự kiện mà không cần máy chủ timestamp bên ngoài.

• Mối quan hệ với Tower BFT: PoH không trực tiếp đạt được đồng thuận — Tower BFT mới là cơ chế chịu trách nhiệm đó. PoH cung cấp thông tin thời gian làm nền tảng cho Tower BFT hoạt động. Các validator bỏ phiếu trên cấu trúc slot và epoch mà PoH tạo ra.

• Liên kết với lịch trình leader: Solana chỉ định trước validator nào sẽ đảm nhận vai trò leader (tạo block) cho mỗi slot. Dòng thời gian của PoH được đồng bộ với lịch trình leader này, tạo ra cấu trúc trong đó mỗi leader xử lý giao dịch đúng slot của mình rồi chuyển giao cho leader tiếp theo.

• Bị loại bỏ trong Alpenglow: PoH là công nghệ mang tính biểu tượng của Solana, nhưng sẽ bị loại bỏ hoàn toàn trong bản nâng cấp Alpenglow. Lịch slot cố định (fixed slot scheduling) sẽ thay thế PoH, hứa hẹn mang lại đồng thuận đơn giản hơn và nhanh hơn. Chức năng ghi nhận thời gian mà PoH từng đảm nhiệm sẽ được thực hiện theo phương thức mới.

Mối liên hệ với các khái niệm khác

PoH gắn kết chặt chẽ với toàn bộ cấu trúc đồng thuận của Solana. Thực thi song song hoạt động trên nền cấu trúc thời gian và lịch trình leader mà PoH tạo ra. Gulf Stream khai thác thông tin lịch trình leader từ PoH để chuyển giao dịch đến đúng leader trước. Khái niệm liên quan quan trọng nhất chính là Alpenglow — bản nâng cấp thay thế hoàn toàn PoH — vì vậy, hiểu rõ PoH chính là chìa khóa để hiểu Alpenglow đang cải thiện điều gì.

---

Program Derived Address (PDA)

Định nghĩa

Program Derived Address (PDA) là loại địa chỉ đặc biệt trên Solana được tạo ra bằng phương pháp toán học bởi chương trình (smart contract), và không có khóa riêng tư (private key) tương ứng. Địa chỉ ví Solana thông thường được tạo thành từ cặp khóa công khai-khóa riêng tư, trong đó chủ sở hữu khóa riêng tư kiểm soát tài sản của địa chỉ đó. PDA thì khác: nó được dẫn xuất bằng toán học từ ID chương trình kết hợp với các giá trị seed, tạo ra một điểm nằm ngoài đường cong elliptic (off-curve point), do đó không tồn tại bất kỳ khóa riêng tư nào. Chỉ duy nhất chương trình sở hữu PDA mới có thể "ký" và kiểm soát địa chỉ đó.

Điểm mấu chốt

• Giải quyết bài toán ký quỹ (escrow): Trong DeFi, chức năng escrow đòi hỏi bên thứ ba tạm thời lưu giữ tài sản. Theo cách truyền thống, phải có ai đó (hoặc một multisig) nắm giữ khóa quản lý tài sản này — làm nảy sinh rủi ro tham nhũng nội bộ hoặc bị hack. PDA không có khóa riêng tư, vì vậy không ai có thể rút tài sản tùy tiện từ PDA. Tài sản chỉ được di chuyển khi logic của chương trình sở hữu cho phép.

• Chỉ chương trình mới có thể ký trên PDA: Solana runtime cho phép một chương trình ký thay mặt PDA của chính nó — cơ chế này được gọi là "program signing" hay "CPI (Cross-Program Invocation) with signer". Chính cơ chế này cho phép chương trình di chuyển tài sản hoặc thay đổi dữ liệu trong tài khoản PDA.

• Tạo địa chỉ có tính xác định (deterministic): Với cùng một program ID và giá trị seed, PDA luôn tạo ra cùng một địa chỉ. Tính xác định này đảm bảo bất kỳ bên tham gia nào cũng có thể tính toán và xác minh trước địa chỉ PDA, mang lại tính minh bạch và khả năng dự đoán.

• Ứng dụng đa dạng: Ngoài escrow, PDA còn được sử dụng rộng rãi trong các mô hình phát triển DApp cốt lõi của Solana: pool thanh khoản của AMM (Automated Market Maker), tài khoản lưu trữ metadata NFT, tài khoản lưu trạng thái theo từng người dùng, dữ liệu cấu hình on-chain, và nhiều hơn nữa.

• So sánh với Ethereum: Smart contract trên Ethereum cũng có địa chỉ riêng và có thể lưu giữ tài sản. Tuy nhiên, PDA của Solana triển khai việc lưu ký tài sản theo cách tường minh và chi tiết hơn, nhờ vào mô hình tài khoản đặc thù và cấu trúc sở hữu chương trình của nền tảng.

Mối liên hệ với các khái niệm khác

PDA kết nối với toàn bộ mô hình lập trình của Solana. Liên quan đến Thực thi song song: các giao dịch có chứa PDA cũng phải khai báo tài khoản PDA đó trước, và tài khoản này được đưa vào lịch trình thực thi song song. Liên quan đến Thị trường phí cục bộ: khi nhiều người dùng truy cập cùng một PDA (ví dụ, pool thanh khoản của một DEX nổi tiếng), phí của tài khoản đó sẽ tăng lên. PDA là nền tảng bảo mật của các DApp Solana và sẽ tiếp tục là yếu tố cốt lõi trong mô hình lập trình ngay cả sau bản nâng cấp Alpenglow.

---

Thị trường phí cục bộ (Local Fee Markets)

Định nghĩa

Thị trường phí cục bộ (Local Fee Markets) là cơ chế định giá phí giao dịch của Solana, trong đó mức phí được xác định ở cấp độ từng tài khoản (account) riêng lẻ, thay vì dựa trên mức độ tắc nghẽn toàn mạng. Trên Ethereum, base fee được quyết định theo nhu cầu toàn mạng — khi một DApp tắc nghẽn, phí của tất cả các giao dịch không liên quan cũng bị đẩy lên. Ngược lại, trong thị trường phí cục bộ của Solana, khi giao dịch dồn vào một tài khoản cụ thể, chỉ priority fee của các giao dịch liên quan đến tài khoản đó mới tăng — các giao dịch xử lý tài khoản khác không bị ảnh hưởng.

Điểm mấu chốt

• Định giá phí ở cấp độ tài khoản: Mọi giao dịch Solana đều có base fee và priority fee tùy chọn. Khi nhiều giao dịch đổ vào một tài khoản, sự cạnh tranh priority fee cho tài khoản đó bùng phát. Hiệu ứng này thể hiện rõ nhất trong các sự kiện mint NFT nổi tiếng hay thanh lý (liquidation) DeFi, khi nhu cầu tập trung cao vào một tài khoản cụ thể.

• Tương phản với thị trường phí toàn cục của Ethereum: Khi một đợt mint NFT hot diễn ra trên Ethereum, giá gas tăng vọt trên toàn mạng — ngay cả một giao dịch chuyển token đơn giản không liên quan cũng trở nên đắt đỏ. Thị trường phí cục bộ của Solana giải quyết vấn đề này về mặt nguyên lý, giới hạn tác động của tắc nghẽn trong phạm vi tài khoản liên quan.

• Sức mạnh cộng hưởng với thực thi song song: Thị trường phí cục bộ phát huy hiệu quả cao nhất khi phối hợp với thực thi song song. Trong khi các giao dịch cạnh tranh phí cao để giành quyền truy cập tài khoản tắc nghẽn, các giao dịch trên tài khoản khác vẫn được xử lý bình thường trong làn thực thi song song với mức phí thấp.

• Hạn chế thực tế — dễ bị tấn công spam: Dù thiết kế thanh lịch về mặt lý thuyết, thị trường phí cục bộ bị chỉ trích là hoạt động không hoàn hảo khi xảy ra tấn công spam cực đoan hay lưu lượng bot lớn. Nếu spam được phân tán trên nhiều tài khoản khác nhau, hoặc khi mạng lưới bị bão hòa ở tầng vận chuyển, cơ chế phí cục bộ đơn thuần không đủ để đảm bảo chất lượng mạng. Đây là một trong những nguyên nhân dẫn đến các lần giảm hiệu suất mà Solana từng gặp phải.

• Liên kết với nâng cấp QUIC: Để khắc phục vấn đề spam, Solana đã chuyển giao thức truyền giao dịch từ UDP sang QUIC và triển khai stake-weighted QoS (chất lượng dịch vụ có trọng số theo stake). Đây là thừa nhận thực tế rằng thị trường phí cục bộ một mình chưa đủ để giải quyết hoàn toàn vấn đề.

Mối liên hệ với các khái niệm khác

Thị trường phí cục bộ là cơ chế phí được xây dựng trên nền kiến trúc của Thực thi song song. Các tài khoản bao gồm cả PDA đều chịu ảnh hưởng của thị trường phí cục bộ — PDA của các chương trình nổi tiếng thường là đối tượng của cuộc cạnh tranh phí. Gulf Stream chuyển giao dịch đến leader cùng với thông tin priority fee, giúp leader ưu tiên xử lý các giao dịch có lợi nhuận cao hơn. Alpenglow được kỳ vọng mang lại hiệu ứng gián tiếp là giảm bớt áp lực thời gian trong cạnh tranh phí nhờ tốc độ đồng thuận được cải thiện đáng kể.

---

Gulf Stream

Định nghĩa

Gulf Stream là giao thức chuyển tiếp giao dịch (transaction forwarding) của Solana. Trong hầu hết các blockchain như Bitcoin hay Ethereum, giao dịch được broadcast vào mempool công khai, nơi tất cả các node lưu giữ chúng cho đến khi leader (miner hoặc validator) chọn xử lý. Gulf Stream thay thế cách tiếp cận đó bằng cách chuyển tiếp giao dịch trực tiếp đến leader hiện tại và các leader sắp tới trong lịch trình. Điều này khả thi vì Solana biết trước các leader tương lai thông qua lịch trình leader dựa trên PoH.

Điểm mấu chốt

• Kiến trúc không có mempool: Solana không vận hành mempool công khai. Thay vào đó, Gulf Stream chuyển giao dịch trực tiếp đến các leader cần thiết thay vì broadcast ra toàn mạng, qua đó loại bỏ overhead mạng và độ trễ phát sinh từ giai đoạn broadcast truyền thống.

• Tận dụng lịch trình leader: Nhờ lịch trình leader mà PoH tạo ra, mọi node trên Solana đều biết trước ai sẽ là leader trong nhiều slot tới. Gulf Stream khai thác thông tin này để chuyển tiếp giao dịch không chỉ đến leader hiện tại mà còn đến các leader kế tiếp, đảm bảo rằng trước khi bắt đầu tạo block, leader đã sẵn có giao dịch cần xử lý.

• Giảm độ trễ: Trong mô hình mempool công khai, giao dịch phải lan truyền qua toàn mạng trước khi leader chọn xử lý — gây ra độ trễ lan truyền. Gulf Stream rút ngắn đường đi này, giảm thời gian giao dịch đến được leader và nhờ đó tăng tốc độ xác nhận (confirmation).

• Tác động đến MEV: Không có mempool công khai đồng nghĩa với việc dạng MEV front-running phổ biến trên Ethereum trở nên khó thực hiện hơn. Tuy nhiên, MEV vẫn tồn tại trên Solana dưới dạng leader sắp xếp lại (reorder) các giao dịch được chuyển đến — và đây là chủ đề đang được thảo luận sôi nổi trong cộng đồng.

• Lo ngại về tập trung hóa: Cấu trúc chuyển tiếp giao dịch đến một nhóm nhỏ các leader được chỉ định tạo ra khả năng về lý thuyết rằng các leader đó có thể kiểm duyệt (censor) hoặc thao túng thứ tự ưu tiên của các giao dịch. Đây là một trong những chỉ trích liên quan đến mức độ phi tập trung hóa của kiến trúc Solana.

Mối liên hệ với các khái niệm khác

Gulf Stream không thể hoạt động nếu thiếu lịch trình leader từ Proof of History (PoH). Khi PoH bị loại bỏ trong bản nâng cấp Alpenglow, cơ chế lịch trình leader cũng sẽ thay đổi, và giao thức Gulf Stream dự kiến sẽ được điều chỉnh tương ứng. Liên quan đến Thị trường phí cục bộ: các giao dịch được chuyển tiếp qua Gulf Stream kèm theo thông tin priority fee, là cơ sở để leader quyết định thứ tự xử lý. Turbine là đối trọng bổ sung của Gulf Stream: nếu Gulf Stream là quá trình tập hợp giao dịch đến leader, thì Turbine là quá trình phân phối block đã hoàn thành đến phần còn lại của các validator.

---

Turbine

Định nghĩa

Turbine là giao thức lan truyền block (block propagation) của Solana. Sau khi leader tạo ra một block, block đó cần được truyền đến tất cả các validator (người xác thực) trong mạng. Nếu gửi trực tiếp dữ liệu block dung lượng lớn đến hàng nghìn validator cùng lúc, băng thông mạng cần thiết sẽ là cực kỳ lớn. Turbine giải quyết vấn đề này bằng cách chia block thành các mảnh dữ liệu nhỏ gọi là "shred" và phân phối chúng qua cấu trúc cây validator (validator tree), tương tự nguyên lý BitTorrent. Giao thức tích hợp mã hóa dư thừa (erasure coding), cho phép khôi phục block đầy đủ ngay cả khi chỉ nhận được một phần dữ liệu.

Điểm mấu chốt

• Chia block thành shred: Turbine không truyền block nguyên vẹn mà chia thành nhiều shred có kích thước nhỏ. Mỗi shred được định tuyến độc lập qua mạng lưới validator, giúp giảm đáng kể yêu cầu băng thông tại mỗi điểm trong quá trình lan truyền.

• Cấu trúc cây phân phối: Các validator được tổ chức theo cấu trúc cây. Leader gửi shred đến một nhóm validator đầu tiên (lớp đầu tiên của cây), sau đó mỗi validator đó chuyển tiếp đến validator khác ở lớp kế tiếp. Phương pháp lan truyền theo từng lớp này giúp phân tán tải mạng một cách hiệu quả.

• Mã hóa dư thừa (Erasure Coding): Turbine sử dụng mã hóa dư thừa để tạo ra các shred dư thừa cùng với shred gốc. Nhờ đó, ngay cả khi một số shred bị mất trong quá trình truyền, validator vẫn có thể khôi phục block hoàn chỉnh từ t