Phân tích kiến trúc công nghệ và phát triển hệ sinh thái Solana

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ác 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 độ phát khối. Cơ chế Turbine tối ưu hóa việc phát tán khối lớn thông qua mã hóa Reed-solomon. Máy ảo Solana (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 là thiết kế kiến trúc giúp Solana đạt hiệu suất cao, nhưng đồng thời cũng mang lại một số vấn đề, như ngừng hoạt động mạng, giao dịch thất bại, vấn đề MEV, sự phát triển trạng thái quá nhanh và vấn đề tập trung.

Hệ sinh thái Solana phát triển nhanh chóng, các chỉ số dữ liệu đều phát triển mạnh mẽ trong nửa đầu nă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 tới ứ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 công nghệ blockchain được áp dụng rộng rãi hơn. Bằng cách hỗ trợ như Solana Mobile và xây dựng SDK dành riêng cho các ứng dụng cho 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ừ đó nâng cao khả năng chấp nhận và sự tiện lợi cho người dùng.

Mặc dù Solana đã đạt được thị phần đáng kể trong ngành công nghiệp blockchain nhờ vào thông lượng 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. Base, 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, trong khi tổng giá trị khóa (TVL) của Solana trong lĩnh vực DeFi đạt ( và đã lập kỷ lục cao nhất mọi thời đại, nhưng các đối thủ như Base cũng đang nhanh chóng chiếm lĩnh thị phần, và số vốn huy động của hệ sinh thái Base 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 về công nghệ và mức độ chấp nhận trên thị trường, nhưng nó cần phải liên tục đổi mới và cải tiến để đối phó với những thách thức từ các đối thủ như Base. Đặc biệt trong việc nâng cao tính ổ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 trạng thái, Solana cần liên tục tối ưu hóa cấu trúc công nghệ và giao thức mạng của mình để duy trì vị thế dẫn đầu trong ngành công nghiệp blockchain.

Kiến trúc kỹ thuật

) 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, nó 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ật mã cơ bản nhất là 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, sẽ có và chỉ có một đầu ra duy nhất Y, do đó bất kỳ sự thay đổi nào đối với X sẽ dẫn đến Y hoàn toàn khác.

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, và do đó xác định tính toàn vẹn của các giao dịch trong đó. Lấy một ví dụ, nếu chúng ta đóng gói các giao dịch thành một khối, tạo ra giá trị băm sha256 tương ứng, thì các giao dịch trong khối này sẽ được xác định, bất kỳ thay đổi nào cũng sẽ dẫn đến sự thay đổi của giá trị băm, sau đó giá trị băm của khối này sẽ trở thành 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ì cả khối trước đó và khối tiếp theo đều sẽ được xác định, bất kỳ thay đổi nào cũng sẽ dẫn đến Y mới khác biệt.

Trong sơ đồ kiến trúc dò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 người xác thực trên chuỗi Validator, nút Lãnh đạo này thu thập giao dịch và sắp xếp thực hiện, tạo ra chuỗi POH, sau đó sẽ tạo ra một khối để phát tán đến các nút khác.

![Giải thích lại kiến trúc kỹ thuật Solana: Có phải sẽ迎来第二春?])panews/images/R5AS3PT13L.webp(

Để tránh điểm lỗi đơn trong nút Leader, do đó đã giới thiệu giới hạn thời gian. Trong Solana, đơn vị thời gian được phân chia theo epoch, mỗi epoch bao gồm 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(400ms) trong khoảng thời gian slot đã cho, nếu không, nó sẽ bỏ qua slot này và bầu lại nút Leader cho slot tiếp theo.

Nói chung, các 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, các nút Leader cần phát sóng khối trong một slot. Người dùng gửi giao dịch cho nút Leader thông qua nút RPC, nút Leader đóng gói giao dịch, sắp xếp và sau đó thực hiện để tạo ra khối, khối được truyền đến các xác thực viên khác, các xác thực viên cần đạt được sự đồng thuận thông qua một cơ chế để đồng thuận về các giao dịch trong khối cũng như thứ tự, 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 trong những triển khai 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 một khối, nếu phiếu bầu của các xác thực viên thực sự 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 xác thực viên 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 nào và chi tiết phiếu bầu của xác thực viên đều có thể được xác nhận một cách duy nhất.

![Tái giải cấu trúc công nghệ Solana: Liệu có迎来 mùa xuân thứ hai?])panews/images/90Jj8P8FH5.webp###

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 các xác thực viên đã bỏ phiếu chấp thuận, thì khối này sẽ được xác định. Lợi ích của cơ chế này là tiết kiệm 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ác 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ó rất nhiều giao dịch bỏ phiếu của các validator, và do hiệu quả từ việc trung tâm hóa của các node Leader 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 rất cao. Khi các khối lớn được phát tán, điều này cũng sẽ gây áp lực lớn lên mạng lưới. Solana sử dụng cơ chế Turbine để giải quyết vấn đề phát tán khối lớn.

( Turbine

Các nút Leader chia nhỏ khối thành các tiểu khối được 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ủa chúng theo đơn vị MTU), 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 là ###. Sau đó, việc sử dụng mã xóa Reed-solomon được áp dụng để đảm bảo tính toàn vẹn và khả năng sử dụng của dữ liệu.

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, do đó sử dụng mã hóa Reed-solomon để mã hóa bốn gói thành tám gói, bộ giải pháp này có thể chịu được tỷ lệ mất gói lên tới 50%. Trong các thử nghiệm thực tế, tỷ lệ mất gói của Solana khoảng 15%, do đó bộ giải pháp này có thể 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 ở lớp dưới, thường sẽ xem xét sử dụng giao thức UDP/TCP. Do Solana có khả năng chịu đựng tỷ lệ mất gói cao hơn, nên đã sử dụng giao thức UDP để truyền tải. Nhược điểm là khi mất gói sẽ không được truyền lạ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 thông đa lớp để thực hiện việc truyền. Node Leader sẽ giao khối cho bất kỳ một trình xác thực khối nào trước khi kết thúc mỗi Slot, sau đó trì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. Trình xác thực đó sẽ sau đó mở rộng việc truyền Turbine. Đầu tiên cần truyền đến node gốc, sau đó node gốc sẽ xác định các trình xác thực nào nằm ở lớp nào. Quá trình 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 số lượng SOL đã đặt cọc (, tức là quyền lợi của từng xác thực viên trong mạng ), 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 nhận ở lớp đầu tiên cũng sẽ tạo danh sách nút của riêng mình để xây dựng lớp đầu tiên của mình.

3. Hình thành lớp: Chia các nút thành các lớp từ đỉnh danh sách, 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 toàn bộ cây, tham số này sẽ ảnh hưởng đến tốc độ truyền shreds.

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

Ý 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 bá khối, cũng có một số nút ưu tiên, những nút này sẽ nhận được các mảnh shreds trước tiên để xây dựng khối hoàn chỉnh nhằm đạt được quá trình đồng thuận bỏ phiếu. Đưa sự dư thừa vào những tầng sâu hơn có thể tăng tốc đáng kể quá trình Finality và 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, nên việc bỏ phiếu của các nút tiếp theo trở nên không 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, đồng thuận Tower BFT và cơ chế truyền dữ liệu Turbine. Tuy nhiên, SVM là 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, tốc độ xử lý của SVM chậm, thì sẽ làm giảm thông lượng của toàn bộ hệ thống. Do đó, để cải thiện tốc độ thực hiện giao dịch cho SVM, Solana đã đề xuất động cơ thực thi song song Sealevel.

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à liệu các thao tác thay đổi trạng thái có xung đột hay không, có thể cho phép thực hiện các lệnh giao dịch của tài khoản mà không có xung đột trạng thái theo cách song song, mỗi lệnh được biểu diễn bằng Program ID. Và đó 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 rất cao, vì yêu cầu các validator có GPU/CPU hỗ trợ khả năng SIMD) lệnh đơn nhiều dữ liệu### và khả năng mở rộng vector nâng cao AVX.

Phát triển sinh thái

Trong quá trình phát triển hệ sinh thái Solana hiện tại, ngày càng có xu hướng thiên về tính hữu dụng thực tế, chẳng hạn như Blinks và Actions thậm chí là Solana Mobile, trong khi hướng phát triển ứng dụng được hỗ trợ chính thức cũng thiên về các ứng dụng cho người tiêu dùng, thay vì sự cạnh tranh vô hạn về cơ sở hạ tầng. Khi hiệu suất của Solana đủ ổn định, các loại ứng dụng trở nên phong phú hơn. Đối với Ethereum, do TPS của nó thấp hơn, nên hệ sinh thái Ethereum vẫn chủ yếu tập trung vào cơ sở hạ tầng và công nghệ mở rộng, trong trường hợp cơ sở hạ tầng không thể hỗ trợ ứng dụng, cũng không thể xây dựng ứng dụng cho người tiêu dùng, điều này dẫn đến tình trạng mất cân bằng khi đầu tư quá nhiều vào cơ sở hạ tầng nhưng lại đầu tư quá ít vào ứng dụng.

( DeFi

Trong các giao thức DeFi trên Solana, có nhiều dự án chưa phát hành token, bao gồm Kamino) Lending###, Marginfi( Lending + Restaking), SoLayer( Restaking), Meteora và nhiều dự án khác. Do bầu không khí cộng sinh của Solana, thường thì khi một dự án phát hành token, các dự án khác sẽ cố gắng tránh thời điểm đó để thu hút đủ sự chú ý từ thị trường.

Hiện tại, cạnh tranh trong toàn bộ DEX rất khốc liệt, và những người dẫn đầu cũng đã trải qua nhiều lần di chuyển, từ Raydium, Orca đến hiện tại là Jupiter chiếm ưu thế.

Cần lưu ý rằng khoảng 50% giao dịch trên DEX được khởi xướng bởi bot MEV, chủ yếu do phí thấp và giao dịch Meme sôi động đã tạo ra lợi nhuận cho MEV. Đây cũng là một trong những nguyên nhân chính dẫn đến việc giao dịch cao điểm của người dùng thường xuyên thất bại và hệ thống bị sập.

Các giao thức DeFi trên Solana đã chứng kiến sự gia tăng bùng nổ về TVL danh nghĩa USD cùng với sự tăng giá của SOL. Xu hướng tăng TVL vẫn chưa dừng lại, một đợt tăng mới đang hình thành.

![Giải thích lại kiến trúc kỹ thuật Solana: Liệu có đang chào đón mùa xuân thứ hai?](