Phân tích kiến trúc công nghệ và phát triển hệ sinh thái của 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ô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 để tăng tốc độ tạo khối. Cơ chế Turbine tối ưu hóa việc truyền các 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 đều là thiết kế kiến trúc giúp Solana đạt được hiệu suất cao, nhưng 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ự 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 là trong các lĩnh vực DeFi, cơ sở hạ tầng, GameFi/NFT, DePin/AI và ứng dụng tiêu dùng. TPS cao của Solana và chiến lược hướng tới ứng dụng tiêu dùng cùng với môi trường hệ 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 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 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 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 sự chấp nhận và tiện lợi của người dùng.
Mặc dù Solana đã chiếm được một thị phần đá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 phải đối mặt với sự cạnh tranh gay gắt từ các chuỗi công khai mới nổi khác. Base, như một đối thủ tiềm năng trong hệ sinh thái EVM, đang nhanh chóng gia tăng số lượng địa chỉ hoạt động trên chuỗi, trong khi tổng giá trị khóa (TVL) của lĩnh vực DeFi của Solana, mặc dù đạt mức cao kỷ lục (, nhưng các đối thủ như Base cũng đang nhanh chóng chiếm lĩnh thị trường, và số vốn huy động của hệ sinh thái Base 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 về công nghệ và sự 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 các thách thức từ các đối thủ như Base. Đặc biệt là trong việc nâng cao độ ổ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 tiếp 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
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 thành nhanh chóng. Các thành phần này hoạt động như thế nào, cách chúng phát huy mục tiêu hiệu suất cao để 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, 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ã hóa cơ bản nhất 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ẽ chỉ có một đầu ra Y duy nhất, vì vậy bất kỳ sự thay đổi nào đối với X cũng 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, từ đó xác định tính toàn vẹn của các giao dịch 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ì 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ẽ đượ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ì cả khối trước và khối sau đề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.
Đâ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 lịch sử.
![Tái giải cấu trúc kỹ thuật Solana: Liệu có đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
Trong sơ đồ cấu 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 nút xác thực trên chuỗi, 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, 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 được chỉ định, 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, 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 đến nút Leader thông qua nút RPC, nút Leader đóng gói và sắp xếp các giao dịch rồi 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 đồng thuận thông qua một cơ chế, đạt được đồng thuận về các giao dịch trong khối cũng như thứ tự, đồ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 hiện thực hóa kỹ thuật cụ thể của nó, thuật toán này vẫn có 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 tự nó là một giao dịch, thì mã băm khối được hình thành từ giao dịch của người dùng và 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.
![Giải thích lại kiến trúc kỹ thuật Solana: Liệu có đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp###
Trong thuật toán Tower BFT quy định rằng, nếu tất cả các nhà xác thực bỏ phiếu cho khối này, và hơn 2/3 các nhà xác thực bỏ phiếu đồng ý, 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ơ chế đồng thuận truyền thống, thường áp dụng là phát tán khối, tức là một nhà xác thực nhận được khối và sau đó sẽ gửi đến các nhà xác thực xung quanh, điều này sẽ gây ra sự dư thừa lớn trong mạng, vì một nhà xác thực 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 hiệu quả mà việc trung tâm hóa 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 phát khối đều đặc biệt cao. Khi các khối lớn được truyền đi, điều này cũng gây ra áp lực lớn cho mạng. Solana sử dụng cơ chế Turbine để giải quyết vấn đề truyền tải khối lớn.
( Turbine
Nút Leader sử dụng một quy trình được gọi là Sharding để chia nhỏ các khối thành các khối con gọi là shred, kích thước của chúng dựa trên MTU), là 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, tính bằng ###. Sau đó, dữ liệu được bảo đảm 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 chặn việc mất gói và hư hỏng trong quá trình truyền dữ liệu, nên 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 đựng tỷ lệ mất gói tối đa 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 rất tương thích với kiến trúc hiện tại của Solana.
Trong việc truyền dữ liệu ở tầng dưới, thường sẽ xem xét việc sử dụng giao thức UDP/TCP. Do Solana có khả năng chịu đựng tỷ lệ mất gói cao, 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 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 độ và thông lượng truyền tải. 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, thông lượng có thể tăng gấp 9 lần.
Sau khi Turbine phân mảnh dữ liệu, sử dụng cơ chế truyền đa lớp để tiến hành truyền, nút Leader sẽ giao khối cho bất kỳ một xác thực khối nào trước khi kết thúc mỗi Slot, sau đó xác thực viên đó sẽ phân mảnh khối thành Shreds và tạo mã sửa lỗi, xác thực viên đó sẽ mở Turbine để truyền. Đầu tiên, phải truyền đến nút gốc, sau đó nút gốc sẽ xác định các xác thực viên nào nằm ở tầng nào. Quá trình như sau:
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 (, số lượng cao hơn sẽ nằm ở tầng đầu tiên, và cứ thế tiếp tục.
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 riêng của mình để xây dựng lớp đầu tiên của mình.
Tầng hình thành: Từ đầu danh sách, phân chia các nút thành các tầng, 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 độ phát tán của shreds.
Các nút có tỷ lệ quyền lợi cao hơn, khi phân chia cấp bậc, ở một cấp cao hơn, sẽ 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 khối hoàn chỉnh, trong khi các nút ở cấp dưới, do tổn thất trong quá trình truyền tải, xác suất nhận được các shreds hoàn chỉnh 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 tải lại trực tiếp. Lúc này, dữ liệu truyền tải sẽ hướng vào bên trong cây, trong khi các nút ở lớp đầu tiên đã hoàn thành việc xây dựng xác nhận khối hoàn chỉnh, thì thời gian để các người xác thực ở các 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 phát tán 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 shreds đầu 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 sâu hơn có thể tăng tốc độ diễn ra Finality một cách đáng kể, đồ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 lớp đầ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 sau đó sẽ 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à ở 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 chậm trong quá trình thực hiện giao dịch, thì tốc độ xử lý của SVM sẽ làm giảm thông lượng của toàn bộ hệ thống, do đó, Solana đã đề xuất Sealevel, một động cơ thực thi song song để tăng tốc độ thực hiện giao dịch cho SVM.
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 cũng như việ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. Đâ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 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 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 hướng tới tiện ích thực tế, chẳng hạn như Blinks và Actions, thậm chí cả Solana Mobile, trong khi 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, thay vì sự cạnh tranh vô hạn trong hạ tầng. Trong bối cảnh hiệu suất của Solana hiện tại đủ tốt, các loại ứng dụng trở nên phong phú hơn. Đối với Ethereum, do TPS tương đối thấp, nên hệ sinh thái Ethereum vẫn chủ yếu tập trung vào hạ tầng và công nghệ mở rộng. Khi hạ tầng không thể hỗ trợ các ứng dụng, cũng sẽ không thể xây dựng các ứ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 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ó rất nhiều dự án chưa phát hành token, bao gồm Kamino( đầu tiên Lending), Marginfi### Lending + Restaking(, SoLayer) Restaking(, Meteora và nhiều dự án khác. Do bầu không khí hợp tác của hệ sinh thái 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 đang rất gay gắt, và người dẫn đầu cũng đã trải qua nhiều lần chuyển giao, từ Raydium, Orca đến giờ một DEX nào đó đang giữ vị trí dẫn đầu.
Cần lưu ý rằng, khoảng 50% giao dịch trên DEX là do bot MEV.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
19 thích
Phần thưởng
19
6
Chia sẻ
Bình luận
0/400
staking_gramps
· 07-16 11:08
hiệu suất của sol thật tuyệt
Xem bản gốcTrả lời0
0xSunnyDay
· 07-15 15:18
Vua sập nguồn vẫn khoe hiệu suất à?
Xem bản gốcTrả lời0
CoconutWaterBoy
· 07-14 03:35
Lại thổi sol?
Xem bản gốcTrả lời0
SandwichTrader
· 07-14 03:21
Đừng chặn mà hãy mở ra, nghĩ một chút thì sẽ thấy ngưng hoạt động.
Phân tích kiến trúc công nghệ Solana và tình trạng phát triển hệ sinh thái
Phân tích kiến trúc công nghệ và phát triển hệ sinh thái của 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ô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 để tăng tốc độ tạo khối. Cơ chế Turbine tối ưu hóa việc truyền các 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 đều là thiết kế kiến trúc giúp Solana đạt được hiệu suất cao, nhưng 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ự 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 là trong các lĩnh vực DeFi, cơ sở hạ tầng, GameFi/NFT, DePin/AI và ứng dụng tiêu dùng. TPS cao của Solana và chiến lược hướng tới ứng dụng tiêu dùng cùng với môi trường hệ 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 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 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 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 sự chấp nhận và tiện lợi của người dùng.
Mặc dù Solana đã chiếm được một thị phần đá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 phải đối mặt với sự cạnh tranh gay gắt từ các chuỗi công khai mới nổi khác. Base, như một đối thủ tiềm năng trong hệ sinh thái EVM, đang nhanh chóng gia tăng số lượng địa chỉ hoạt động trên chuỗi, trong khi tổng giá trị khóa (TVL) của lĩnh vực DeFi của Solana, mặc dù đạt mức cao kỷ lục (, nhưng các đối thủ như Base cũng đang nhanh chóng chiếm lĩnh thị trường, và số vốn huy động của hệ sinh thái Base 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 về công nghệ và sự 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 các thách thức từ các đối thủ như Base. Đặc biệt là trong việc nâng cao độ ổ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 tiếp 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
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 thành nhanh chóng. Các thành phần này hoạt động như thế nào, cách chúng phát huy mục tiêu hiệu suất cao để 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, 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ã hóa cơ bản nhất 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ẽ chỉ có một đầu ra Y duy nhất, vì vậy bất kỳ sự thay đổi nào đối với X cũng 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, từ đó xác định tính toàn vẹn của các giao dịch 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ì 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ẽ đượ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ì cả khối trước và khối sau đề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.
Đâ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 lịch sử.
![Tái giải cấu trúc kỹ thuật Solana: Liệu có đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-83781275d369bad28954d579213dd93e.webp(
Trong sơ đồ cấu 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 nút xác thực trên chuỗi, 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, 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 được chỉ định, 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, 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 đến nút Leader thông qua nút RPC, nút Leader đóng gói và sắp xếp các giao dịch rồi 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 đồng thuận thông qua một cơ chế, đạt được đồng thuận về các giao dịch trong khối cũng như thứ tự, đồ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 hiện thực hóa kỹ thuật cụ thể của nó, thuật toán này vẫn có 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 tự nó là một giao dịch, thì mã băm khối được hình thành từ giao dịch của người dùng và 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.
![Giải thích lại kiến trúc kỹ thuật Solana: Liệu có đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp###
Trong thuật toán Tower BFT quy định rằng, nếu tất cả các nhà xác thực bỏ phiếu cho khối này, và hơn 2/3 các nhà xác thực bỏ phiếu đồng ý, 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ơ chế đồng thuận truyền thống, thường áp dụng là phát tán khối, tức là một nhà xác thực nhận được khối và sau đó sẽ gửi đến các nhà xác thực xung quanh, điều này sẽ gây ra sự dư thừa lớn trong mạng, vì một nhà xác thực 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 hiệu quả mà việc trung tâm hóa 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 phát khối đều đặc biệt cao. Khi các khối lớn được truyền đi, điều này cũng gây ra áp lực lớn cho mạng. Solana sử dụng cơ chế Turbine để giải quyết vấn đề truyền tải khối lớn.
( Turbine
Nút Leader sử dụng một quy trình được gọi là Sharding để chia nhỏ các khối thành các khối con gọi là shred, kích thước của chúng dựa trên MTU), là 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, tính bằng ###. Sau đó, dữ liệu được bảo đảm 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 chặn việc mất gói và hư hỏng trong quá trình truyền dữ liệu, nên 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 đựng tỷ lệ mất gói tối đa 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 rất tương thích với kiến trúc hiện tại của Solana.
Trong việc truyền dữ liệu ở tầng dưới, thường sẽ xem xét việc sử dụng giao thức UDP/TCP. Do Solana có khả năng chịu đựng tỷ lệ mất gói cao, 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 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 độ và thông lượng truyền tải. 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, thông lượng có thể tăng gấp 9 lần.
Sau khi Turbine phân mảnh dữ liệu, sử dụng cơ chế truyền đa lớp để tiến hành truyền, nút Leader sẽ giao khối cho bất kỳ một xác thực khối nào trước khi kết thúc mỗi Slot, sau đó xác thực viên đó sẽ phân mảnh khối thành Shreds và tạo mã sửa lỗi, xác thực viên đó sẽ mở Turbine để truyền. Đầu tiên, phải truyền đến nút gốc, sau đó nút gốc sẽ xác định các xác thực viên nào nằm ở tầng nào. Quá trình như sau:
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 (, số lượng cao hơn sẽ nằm ở tầng đầu tiên, và cứ thế tiếp tục.
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 riêng của mình để xây dựng lớp đầu tiên của mình.
Tầng hình thành: Từ đầu danh sách, phân chia các nút thành các tầng, 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 độ phát tán của shreds.
Các nút có tỷ lệ quyền lợi cao hơn, khi phân chia cấp bậc, ở một cấp cao hơn, sẽ 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 khối hoàn chỉnh, trong khi các nút ở cấp dưới, do tổn thất trong quá trình truyền tải, xác suất nhận được các shreds hoàn chỉnh 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 tải lại trực tiếp. Lúc này, dữ liệu truyền tải sẽ hướng vào bên trong cây, trong khi các nút ở lớp đầu tiên đã hoàn thành việc xây dựng xác nhận khối hoàn chỉnh, thì thời gian để các người xác thực ở các 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 phát tán 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 shreds đầu 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 sâu hơn có thể tăng tốc độ diễn ra Finality một cách đáng kể, đồ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 lớp đầ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 sau đó sẽ 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à ở 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 chậm trong quá trình thực hiện giao dịch, thì tốc độ xử lý của SVM sẽ làm giảm thông lượng của toàn bộ hệ thống, do đó, Solana đã đề xuất Sealevel, một động cơ thực thi song song để tăng tốc độ thực hiện giao dịch cho SVM.
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 cũng như việ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. Đâ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 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 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 hướng tới tiện ích thực tế, chẳng hạn như Blinks và Actions, thậm chí cả Solana Mobile, trong khi 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, thay vì sự cạnh tranh vô hạn trong hạ tầng. Trong bối cảnh hiệu suất của Solana hiện tại đủ tốt, các loại ứng dụng trở nên phong phú hơn. Đối với Ethereum, do TPS tương đối thấp, nên hệ sinh thái Ethereum vẫn chủ yếu tập trung vào hạ tầng và công nghệ mở rộng. Khi hạ tầng không thể hỗ trợ các ứng dụng, cũng sẽ không thể xây dựng các ứ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 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ó rất nhiều dự án chưa phát hành token, bao gồm Kamino( đầu tiên Lending), Marginfi### Lending + Restaking(, SoLayer) Restaking(, Meteora và nhiều dự án khác. Do bầu không khí hợp tác của hệ sinh thái 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 đang rất gay gắt, và người dẫn đầu cũng đã trải qua nhiều lần chuyển giao, từ Raydium, Orca đến giờ một DEX nào đó đang giữ vị trí dẫn đầu.
Cần lưu ý rằng, khoảng 50% giao dịch trên DEX là do bot MEV.