Phân tích kiến trúc kỹ thuật Solana: Đón chào 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 quay vòng lãnh đạo và cơ chế đồng thuận Tower BFT cải thiện tốc độ tạo 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. 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 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ư sự cố 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.

Hệ sinh thái Solana phát triển nhanh chóng, các chỉ số dữ liệu đều tăng trưởng 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 đế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 công nghệ blockchain áp dụng trong nhiều lĩnh vực rộng rãi hơn. Thông qua việc 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 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 blockchain và công nghệ di động để cung cấp trải nghiệm thể dục và xã hội mới mẻ cho người dùng. Mặc dù hiện nay 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à sự hỗ trợ của 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 công nghệ tiếp theo và sự trưởng thành của thị trường, Solana có khả năng đạt được nhiều độ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.

Mặc dù Solana đã chiếm lĩnh thị trường đáng kể trong ngành công nghiệp blockchain với thông lượng cao và chi phí giao dịch thấp, nhưng nó cũng đang 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 nhanh chóng tăng lên. Đồng thời, tổng giá trị tài sản khóa (TVL) của Solana trong lĩnh vực DeFi, mặc dù đã lập kỷ lục mới, nhưng các đối thủ như Base cũng đang nhanh chóng chiếm lĩnh thị trường. Số vốn huy động trong 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 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 trạng thái, Solana cần tối ưu hóa liên tục kiến 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

Solana nổi tiếng với thuật toán POH, cơ chế đồng thuận Tower BFT, cũng như 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 tôi sẽ giới thiệu ngắn gọn cách mà các thành phần này hoạt động, cách chúng phát huy mục tiêu hiệu suất cao để thực hiện thiết kế kiến trúc, cũng như những bất lợi và các 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, 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 có nguồn gốc 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 Y duy nhất, 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, qua đó xác định tính toàn vẹn của các giao dịch trong chuỗi đó. 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 đó 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, 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 được xác định, bất kỳ thay đổi nào cũng sẽ dẫn đến Y mới khác biệt.

Đây chính 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 của lịch sử.

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 từ tất cả các trình xác thực 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 được phát tán đến các nút khác.

Để tránh sự cố điểm đơn tại 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 thời gian slot quy định, nếu không, nó sẽ bỏ qua slot này và tiến hành bầu chọn lại nút Leader cho slot tiếp theo.

Nói chung, 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 thông qua nút RPC tới Leader, 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 tới 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ế, đạt được sự đồng thuận về các giao dịch trong khối và thứ tự, sự đồng thuận này sử dụng chính là 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 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 cũng như chi tiết phiếu bầu của người xác thực đều có thể được xác nhận 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, 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ận. 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á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 đến 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 lưới, 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 xác thực viên, và do tính hiệu quả đến từ việc trung tâm hóa của các nút 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 phát khối rất cao. Khi các khối lớn được phát tán, nó cũng gây áp lực rất 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 các khối lớn.

Turbine

Các nút Leader chia nhỏ các 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, có kích thước 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 đó, dữ liệu được đảm bảo tính toàn vẹn và khả dụng thông qua việc sử dụng mã xóa Reed-solomon.

Bằng cách chia khối thành bốn Data Shreds, sau đó để ngăn ngừa mất gói và hỏng hóc 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 đế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 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.

![Giải thích lại kiến trúc kỹ thuật Solana: Liệu có sắp đến mùa xuân thứ hai?]###https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Trong việc truyền tải dữ liệu ở lớp dưới, thường sẽ xem xét việc sử dụng giao thức UDP/TCP. Do Solana có độ dung nạp cao đối với tỷ lệ mất gói, nên đã sử dụng giao thức UDP để truyền tải, nhược điểm là không truyền lại khi mất gói, nhưng ưu điểm là tốc độ truyền tải 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 tải và thông lượng. Với sự xuất hiện của 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 chia dữ liệu, nó sử dụng cơ chế truyền thông đa lớp để tiến hành truyền tải. Node Leader sẽ giao khối cho bất kỳ một người xác thực khối nào trước khi kết thúc mỗi Slot, sau đó người xác thực đó sẽ phân chia khối thành các Shreds và tạo mã sửa lỗi. Người xác thực đó sau đó sẽ khởi động quá trình truyền Turbine. Đầu tiên, nó sẽ được truyền đến node gốc, sau đó node gốc sẽ xác định các người xác thực nào nằm ở tầng 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 dựa trên 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 stake (, những người có trọng số cao hơn sẽ ở tầng đầu tiên, và cứ thế tiếp theo.

2. Nhóm nút: Sau đó, mỗi người xác thực nằm ở 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ừ đầu 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 quát của toàn bộ cây, tham số này sẽ ảnh hưởng đến tốc độ lan truyền của shreds.

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

Ý tưởng của cơ chế này tương tự như cơ chế một nút của nút Leader. Trong quá trình phát tán khối cũng tồn tại một số nút ưu tiên, những nút này trước tiên nhận được các shreds để 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 các lớp sâu hơn có thể làm tăng đáng kể tốc độ hoàn tất (Finality) và tối đa hóa thông lượng và hiệu suất. Bởi vì thực tế, vài lớp đầu tiên có thể đại diện cho 2/3 số nút, do đó, việc bỏ phiếu của các nút tiếp theo cũng 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ờ cơ chế POH, đồ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, 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, vì vậy đố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 xem 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 song song hóa các lệnh giao dịch của tài khoản 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 khiến yêu cầu đối với các validator của Solana rất cao, vì yêu cầu các validator phải có GPU/CPU hỗ trợ SIMD### lệnh đơn nhiều dữ liệu( và khả năng mở rộng vector cao cấp AVX.

Phát triển hệ sinh thái

Trong quá trình phát triển của hệ sinh thái Solana hiện tại, ngày càng nghiêng về tính hữu dụng thực tế, chẳng hạn như Blinks và Actions, thậm chí cả Solana Mobile, và hướng phát triển ứng dụng được chính thức hỗ trợ cũng thiên về các ứng dụng cho người tiêu dùng, chứ không phải cơ sở hạ tầng.