Tái giải cấu trúc kỹ thuật Solana: Liệu có đón nhận mùa xuân thứ hai?

Solana là một nền tảng blockchain hiệu suất cao, sử dụng kiến trúc công nghệ độc đáo để đạt được thông lượng cao và độ trễ thấp. Công nghệ cốt lõi của nó bao gồm thuật toán Proof of History (POH) đảm bảo thứ tự giao dịch và đồng hồ toàn cầu, Lịch trình luân phiên lãnh đạo và cơ chế đồng thuận Tower BFT nâng cao tốc độ tạo khối. Cơ chế Turbine tối ưu hóa việc truyền lớn khối thông qua mã hóa Reed-solomon. Solana Virtual Machine (SVM) và động cơ thực thi song song Sealevel tăng tốc độ thực thi giao dịch. Tất cả những điều này đều là thiết kế kiến trúc giúp Solana đạt được hiệu suất cao, nhưng đồng thời cũng mang lại một số vấn đề, như mất mạng, giao dịch thất bại, vấn đề MEV, tăng trưởng trạng thái quá nhanh và vấn đề tập trung. Chúng tôi cũng đã nhấn mạnh những vấn đề do cơ chế này gây ra trong bài viết này.

Hệ sinh thái Solana phát triển nhanh chóng, các chỉ số dữ liệu trong nửa đầu năm đều phát triển mạnh mẽ, đặc biệt trong các lĩnh vực DeFi, cơ sở hạ tầng, GameFi/NFT, DePin/AI và ứng dụng cho người tiêu dùng. TPS cao của Solana và chiến lược hướng đến ứng dụng cho người tiêu dùng, cùng với môi trường sinh thái có hiệu ứng thương hiệu yếu, đã cung cấp nhiều cơ hội khởi nghiệp cho các doanh nhân và nhà phát triển. Trong lĩnh vực ứng dụng cho người tiêu dùng, Solana đã thể hiện tầm nhìn của mình trong việc thúc đẩy sự ứng dụng công nghệ blockchain trong các lĩnh vực rộng lớn hơn. Bằng cách hỗ trợ như Solana Mobile và SDK được xây dựng riêng cho ứng dụng người tiêu dùng, Solana đang nỗ lực tích hợp công nghệ blockchain vào các ứng dụng hàng ngày, từ đó tăng cường mức độ chấp nhận và sự tiện lợi cho người dùng. Ví dụ, các ứng dụng như Stepn kết hợp công nghệ blockchain và di động, mang đến cho người dùng trải nghiệm thể dục và xã hội mới mẻ. Mặc dù hiện tại nhiều ứng dụng cho người tiêu dùng vẫn đang khám phá mô hình kinh doanh và định vị thị trường tốt nhất, nhưng nền tảng công nghệ và hỗ trợ hệ sinh thái mà Solana cung cấp chắc chắn đã tạo ra một nền tảng vững chắc cho những nỗ lực đổi mới này. Với sự phát triển tiếp theo của công nghệ và sự trưởng thành của thị trường, Solana có khả năng đạt được nhiều bước đột phá và trường hợp thành công hơn trong lĩnh vực ứng dụng cho người tiêu dùng.

Solana mặc dù đã đạt được thị phần đáng kể trong ngành công nghiệp blockchain nhờ vào khả năng xử lý cao và chi phí giao dịch thấp, nhưng nó cũng phải đối mặt với sự cạnh tranh gay gắt từ các chuỗi công cộng mới nổi khác. Một nền tảng giao dịch như một đối thủ tiềm năng trong hệ sinh thái EVM, số lượng địa chỉ hoạt động trên chuỗi của nó đang tăng nhanh chóng, đồng thời, tổng giá trị khóa (TVL) trong lĩnh vực DeFi của Solana mặc dù đã lập kỷ lục cao nhất mọi thời đại, nhưng các đối thủ cạnh tranh như nền tảng giao dịch đó cũng đang nhanh chóng chiếm lĩnh thị phần, và số vốn huy động trong hệ sinh thái của nền tảng giao dịch đó cũng lần đầu tiên vượt qua Solana trong quý 2.

Mặc dù Solana đã đạt được một số thành tựu trong công nghệ và mức độ chấp nhận trên thị trường, nhưng nó cần phải đổi mới và cải tiến liên tục để đối phó với những thách thức từ các đối thủ như một nền tảng giao dịch. Đặc biệt trong việc cải thiện độ ổn định của mạng, giảm tỷ lệ giao dịch thất bại, giải quyết vấn đề MEV và làm chậm tốc độ tăng trạng thái, Solana cần tiếp tục tối ưu hóa kiến trúc công nghệ và giao thức mạng của mình để giữ vững vị trí dẫn đầu trong ngành công nghiệp blockchain.

Kiến trúc kỹ thuật

Solana nổi tiếng với thuật toán POH, cơ chế đồng thuận Tower BFT, mạng truyền dữ liệu Trubine và máy ảo SVM mang lại TPS cao và độ hoàn tất nhanh chóng. Chúng tôi sẽ giới thiệu ngắn gọn cách thức hoạt động của từng thành phần, cách mà chúng đạt được mục tiêu hiệu suất cao cho thiết kế kiến trúc, cũng như những bất lợi và vấn đề phát sinh từ thiết kế kiến trúc này.

thuật toán POH

POH (Proof of History) là một công nghệ xác định thời gian toàn cầu, không phải là cơ chế đồng thuận, mà là một thuật toán xác định thứ tự giao dịch. Công nghệ POH xuất phát từ công nghệ mã hóa cơ bản SHA256. SHA256 thường được sử dụng để tính toán tính toàn vẹn của dữ liệu, với một đầu vào X nhất định, sẽ có và chỉ có một đầu ra Y duy nhất, do đó bất kỳ thay đổi nào đối với X sẽ dẫn đến Y hoàn toàn khác biệt.

Trong chuỗi POH của Solana, việc áp dụng thuật toán sha256 có thể đảm bảo tính toàn vẹn của toàn bộ chuỗi, đồng nghĩa với việc đảm bảo tính toàn vẹn của các giao dịch bên trong. Ví dụ, nếu chúng ta đóng gói các giao dịch thành một khối và tạo ra giá trị băm sha256 tương ứng, thì các giao dịch trong khối đó đã được xác định, bất kỳ sự thay đổi nào cũng sẽ dẫn đến việc thay đổi giá trị băm, sau đó giá trị băm của khối này sẽ được sử dụng làm một phần của X trong hàm sha256 tiếp theo, và thêm giá trị băm của khối tiếp theo, thì khối trước và khối sau cũng sẽ được xác định, bất kỳ sự thay đổi nào cũng sẽ dẫn đến Y mới khác biệt.

Đây là ý nghĩa cốt lõi của công nghệ Proof of History, hash của khối trước sẽ được sử dụng như một phần của hàm sha256 tiếp theo, giống như một chuỗi, Y mới nhất luôn chứa bằng chứng lịch sử.

Trong sơ đồ kiến trúc luồng giao dịch của Solana, mô tả quy trình giao dịch dưới cơ chế POH, trong một cơ chế luân phiên được gọi là Lịch trình Luân phiên Lãnh đạo, sẽ tạo ra một nút Lãnh đạo trong tất cả các xác thực viên trên chuỗi Validator, nút Lãnh đạo này thu thập giao dịch và thực hiện sắp xếp, tạo ra chuỗi POH, sau đó sẽ tạo ra một khối và phát tán cho các nút khác.

Để tránh xảy ra lỗi điểm đơn tại nút Leader, nên đã giới thiệu giới hạn thời gian. Trong Solana, đơn vị thời gian được chia theo epoch, mỗi epoch chứa 432.000 slot, mỗi slot kéo dài 400ms, trong mỗi slot, hệ thống luân phiên sẽ phân bổ một nút Leader trong mỗi slot, nút Leader phải phát hành khối trong khoảng thời gian slot được chỉ định (400ms), nếu không, nó sẽ bỏ qua slot này và bầu lại nút Leader cho slot tiếp theo.

Tổng thể, nút Leader sử dụng cơ chế POH có thể xác định tất cả các giao dịch lịch sử. Đơn vị thời gian cơ bản của Solana là Slot, nút Leader cần phát sóng khối trong một slot. Người dùng gửi giao dịch qua nút RPC đến nút Leader, nút Leader đóng gói và sắp xếp giao dịch rồi thực hiện để tạo ra khối, khối được phát tán đến các nhà xác thực khác, các nhà xác thực cần đạt được sự đồng thuận thông qua một cơ chế đối với các giao dịch trong khối và thứ tự của chúng, sự đồng thuận này sử dụng cơ chế đồng thuận Tower BFT.

Cơ chế đồng thuận Tower BFT

Giao thức đồng thuận Tower BFT đến từ thuật toán đồng thuận BFT, là một triển khai kỹ thuật cụ thể của nó, thuật toán này vẫn liên quan đến thuật toán POH. Khi bỏ phiếu cho khối, nếu phiếu bầu của người xác thực chính là một giao dịch, thì giao dịch của người dùng và khối băm được hình thành từ giao dịch của người xác thực cũng có thể được coi là bằng chứng lịch sử, chi tiết giao dịch của người dùng và chi tiết phiếu bầu của người xác thực đều có thể được xác nhận một cách duy nhất.

Trong thuật toán Tower BFT quy định rằng, nếu tất cả các xác thực viên bỏ phiếu cho khối này, và hơn 2/3 số xác thực viên bỏ phiếu chấp thuận, thì khối này có thể được xác định. Lợi ích của cơ chế này là tiết kiệm một lượng lớn bộ nhớ, vì chỉ cần bỏ phiếu cho chuỗi băm để xác nhận khối. Tuy nhiên, trong cơ chế đồng thuận truyền thống, thường sử dụng phương pháp phát khối, nghĩa là một xác thực viên nhận được khối và sau đó sẽ gửi cho các xác thực viên xung quanh, điều này sẽ gây ra sự dư thừa lớn trong mạng, vì một xác thực viên nhận được cùng một khối không chỉ một lần.

Trong Solana, do có một lượng lớn giao dịch bỏ phiếu của các trình xác thực, và do hiệu quả mà sự tập trung của các nút Leader mang lại cùng với thời gian Slot 400ms, điều này dẫn đến kích thước khối tổng thể và tần suất tạo khối đều đặc biệt cao. Các khối lớn khi được phát tán cũng sẽ gây áp lực lớn lên mạng, Solana sử dụng cơ chế Turbine để giải quyết vấn đề phát tán các khối lớn.

Turbine

Các nút Leader chia nhỏ khối thành các khối con gọi là shred thông qua một quá trình được gọi là Sharding, kích thước tiêu chuẩn được đo bằng MTU (Đơn vị truyền tối đa, lượng dữ liệu tối đa có thể gửi từ một nút đến nút tiếp theo mà không cần chia nhỏ thành các đơn vị nhỏ hơn). Sau đó, dữ liệu được bảo đảm tính toàn vẹn và khả năng sử dụng bằng cách sử dụng phương án mã xóa Reed-Solomon.

Bằng cách chia khối thành bốn Data Shreds, sau đó để ngăn chặn mất gói và hư hỏng trong quá trình truyền dữ liệu, mã hóa Reed-solomon được sử dụng để mã hóa bốn gói thành tám gói, giải pháp này có thể chịu được tỷ lệ mất gói lên đến 50%. Trong các thử nghiệm thực tế, tỷ lệ mất gói của Solana khoảng 15%, vì vậy giải pháp này tương thích rất tốt với kiến trúc hiện tại của Solana.

Trong việc truyền dữ liệu ở tầng cơ sở, thường sẽ xem xét việc sử dụng giao thức UDP/TCP. Do Solana có độ dung nạp đối với tỷ lệ mất gói cao, nên đã áp dụng giao thức UDP để truyền tải. Nhược điểm của nó là không thực hiện truyền lại khi mất gói, nhưng ưu điểm là tốc độ truyền nhanh hơn. Ngược lại, giao thức TCP sẽ truyền lại nhiều lần khi mất gói, điều này sẽ làm giảm đáng kể tốc độ truyền và thông lượng. Với Reed-Solomon, giải pháp này có thể tăng đáng kể thông lượng của Solana, trong môi trường thực tế, thông lượng có thể tăng gấp 9 lần.

Sau khi Turbine phân mảnh dữ liệu, nó sử dụng cơ chế truyền đa lớp để thực hiện việc truyền tải. Nút Leader sẽ chuyển giao khối cho bất kỳ nhà xác thực khối nào trước khi kết thúc mỗi Slot, sau đó nhà xác thực đó sẽ phân mảnh khối thành các Shreds và tạo mã sửa lỗi. Nhà xác thực đó sau đó sẽ bắt đầu việc truyền tải Turbine. Đầu tiên, nó sẽ truyền tới nút gốc, sau đó nút gốc sẽ xác định các nhà xác thực nào nằm ở tầng nào. Quá trình này được mô tả như sau:

1. Tạo danh sách nút: Nút gốc sẽ tổng hợp tất cả các xác thực viên hoạt động vào một danh sách, sau đó sắp xếp theo quyền lợi của mỗi xác thực viên trong mạng (tức là số lượng SOL đã được đặt cọc), những người có trọng số cao hơn sẽ ở tầng đầu tiên, và cứ như vậy.

2. Nhóm nút: Sau đó, mỗi người xác thực ở tầng đầu tiên cũng sẽ tạo danh sách nút của riêng mình để xây dựng tầng đầu tiên của mình.

3. Hình thành lớp: Từ đầu danh sách, phân chia các nút thành các lớp, bằng cách xác định hai giá trị độ sâu và độ rộng, có thể xác định hình dạng tổng thể của cây, tham số này sẽ ảnh hưởng đến tốc độ lan truyền của shreds.

Nút có tỷ lệ quyền lợi chiếm ưu thế, khi phân chia cấp bậc, ở một cấp cao hơn, thì có thể nhận được đầy đủ shreds trước, lúc này có thể phục hồi được khối hoàn chỉnh, trong khi các nút ở cấp độ sau, do sự mất mát trong quá trình truyền tải, xác suất nhận được đầy đủ shreds sẽ giảm. Nếu những shreds này không đủ để xây dựng một mảnh hoàn chỉnh, sẽ yêu cầu Leader truyền tải lại trực tiếp. Vào lúc này, việc truyền tải dữ liệu sẽ diễn ra bên trong cây, trong khi các nút ở cấp độ đầu tiên đã xây dựng xong xác nhận khối hoàn chỉnh, thì thời gian để các xác nhận ở cấp độ sau hoàn thành việc xây dựng khối và tiến hành bỏ phiếu sẽ càng lâu.

Ý tưởng của cơ chế này tương tự như cơ chế nút đơn của nút Leader. Trong quá trình truyền phát khối, cũng tồn tại một số nút ưu tiên, những nút này sẽ nhận được các shreds trước tiên để tạo thành khối hoàn chỉnh nhằm đạt được quá trình đồng thuận bỏ phiếu. Đẩy sự dư thừa xuống các tầng sâu hơn có thể làm tăng đáng kể tốc độ của Finality, đồng thời tối đa hóa thông lượng và hiệu suất. Bởi vì thực tế, vài tầng đầu tiên có thể đại diện cho 2/3 số nút, vì vậy việc bỏ phiếu của các nút tiếp theo không còn quan trọng.

SVM

Solana có thể xử lý hàng nghìn giao dịch mỗi giây, lý do chính là nhờ vào cơ chế POH, sự đồng thuận Tower BFT và cơ chế truyền dữ liệu Turbine. Tuy nhiên, SVM như một máy ảo chuyển đổi trạng thái, nếu nút Leader trong quá trình thực hiện giao dịch mà SVM xử lý chậm, thì sẽ làm giảm thông lượng của toàn bộ hệ thống, do đó đối với SVM, Solana đã đề xuất động cơ thực thi song song Sealevel để tăng tốc độ thực hiện giao dịch.

Trong SVM, lệnh được cấu thành từ 4 phần, bao gồm ID chương trình, lệnh chương trình và danh sách tài khoản để đọc/ghi dữ liệu. Bằng cách xác định tài khoản hiện tại đang ở trạng thái đọc hay ghi và xem liệu các thao tác thay đổi trạng thái có xung đột hay không, có thể cho phép các lệnh giao dịch của tài khoản được song song hóa mà không có xung đột về trạng thái, mỗi lệnh được biểu thị bằng Program ID. Và đây cũng là một trong những lý do tại sao yêu cầu đối với các validator của Solana lại rất cao, vì yêu cầu các validator có GPU/CPU có thể hỗ trợ SIMD (đơn lệnh đa dữ liệu) và AVX cao.