Phân tích kiến trúc kỹ thuật Solana: Sẽ đó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 tăng tốc độ tạo khối. Cơ chế Turbine tối ưu hóa việc truyề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 đều là thiết kế kiến trúc của Solana để đạt được 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, 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 tập trung vào ứng dụng cho người 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 cho người tiêu dùng, Solana đã thể hiện tầm nhìn của mình về việc thúc đẩy ứ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ợ các ứng dụng 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 sự chấp nhận và 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 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. Base, như một đối thủ tiềm năng trong hệ sinh thái EVM, đang nhanh chóng tăng số lượng địa chỉ hoạt động trên chuỗi, trong khi tổng giá trị khóa (TVL) trong 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ị phần, và 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à độ chấp nhận của 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 là trong việc cải thiện 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 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 để 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, mạng truyền dữ liệu Trubine và máy ảo SVM mang lại TPS cao và Finality nhanh. Chúng tôi sẽ giới thiệu ngắn gọn về cách thức hoạt động của từng thành phần, cách chúng phát huy mục tiêu hiệu suất cao trong thiết kế kiến trúc, cũng như những bất lợi và vấn đề phát sinh dưới thiết kế kiến trúc này.
) thuật toán POH
POH###Proof of History( là một kỹ thuật 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. Kỹ thuật 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, cho một đầu vào X, sẽ có và chỉ có một đầu ra duy nhất Y, vì vậy 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, đồng nghĩa với việc 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 giao dịch thành một khối, tạo ra giá trị băm sha256 tương ứng, thì giao dịch trong khối này sẽ được xác định, bất kỳ sự 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 được xác định, bất kỳ sự thay đổi nào cũng sẽ dẫn đến Y mới khác nhau.
Điều này chính là ý nghĩa cốt lõi của công nghệ Proof of History, mã 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ử.
![Tái giải cấu trúc kỹ thuật Solana: Liệu có đón chào mùa xuân thứ hai không?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
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 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 Validator trên chuỗi, nút Lãnh đạo này thu thập các 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 sự cố điểm đơn tại nút Leader, giới hạn thời gian đã được đưa vào. Trong Solana, đơn vị thời gian được chia thành 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(400ms) trong thời gian slot đã cho, nếu không, nó sẽ bỏ qua slot này và bầu chọn 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, 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 rồi thực hiện để tạo ra khối, khối được phát tán cho các người xác nhận khác, các người xác nhậ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 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 xuất phát 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 một 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ì băm khối 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 sử dụng như một 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 duy nhất.
![Giải thích lại kiến trúc kỹ thuật Solana: Có phải sẽ đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.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 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 là có thể 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 tán khối, tức là một xác thực viên nhận được khối và sau đó gửi nó 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ó nhiều giao dịch bỏ phiếu của các validator, và nhờ vào hiệu suất cao do sự tập trung của các nút Leader cũng như 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 xuất khối đều đặc biệt cao. Khi các khối lớn được phát tán, nó cũng gây ra áp lực lớn cho 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
Node Leader chia nhỏ các khối thành các sub-block gọi là shreds thông qua một quá trình được gọi là Sharding, kích thước của chúng theo MTU) đơn vị dung lượng truyền tối đa, mà không cần chia nhỏ thành các đơn vị nhỏ hơn có thể gửi từ một nút sang nút tiếp theo với khối lượng dữ liệu tối đa ###. Sau đó, sử dụng phương pháp mã sửa lỗi Reed-solomon để đảm bảo tính toàn vẹn và khả 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 việc 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 đựng tới 50% tỷ lệ mất gói. 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 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 nền, người ta thường xem xét việc sử dụng giao thức UDP/TCP. Do độ dung nạp của Solana đối với 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 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ẽ giảm đáng kể tốc độ truyền 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 mảnh dữ liệu, nó sử dụng cơ chế lan truyền nhiều lớp để tiến hành lan truyền. Nút Leader sẽ giao khối cho bất kỳ trình xác thực khối nào trước khi mỗi Slot kết thúc, sau đó trình xác thực sẽ phân mảnh khối thành Shreds và tạo mã sửa lỗi, trình xác thực đó sẽ bắt đầu lan truyền Turbine. Đầu tiên, nó phải được lan truyền đến nút gốc, sau đó nút gốc sẽ xác định các trình xác thực nào nằm ở cấp độ 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 người xác thực hoạt động vào một danh sách, sau đó sắp xếp theo quyền lợi của mỗi người xác thực trong mạng, tức là số lượng SOL đã được đặt cọc (, người có trọng số cao hơn sẽ nằm ở tầng đầu tiên, và cứ như vậy.
Nhóm nút: Sau đó, mỗi người xác thực nằm ở tầng đầu tiên cũng sẽ tạo danh sách nút riêng của mình để xây dựng tầng đầu tiên của riêng mình.
Hình thành lớp: Chia các nút thành các lớp từ đầu danh sách, thông qua việc 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.
Node có tỷ lệ quyền lợi cao hơn, khi phân chia cấp độ, sẽ ở cấp cao hơn, do đó có thể nhận được shreds đầy đủ sớm hơn, lúc này có thể phục hồi khối đầy đủ, trong khi các node ở 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 đi. Nếu những shreds này không đủ để xây dựng mảnh hoàn chỉnh, sẽ yêu cầu Leader trực tiếp truyền tải lại. Lúc này, dữ liệu sẽ được truyền vào bên trong cây, trong khi các node ở tầng đầu tiên đã xây dựng xong xác nhận khối đầy đủ, thời gian sau khi các xác thực ở các tầng phía sau hoàn thành việc xây dựng khối để 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 nút 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 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ự thừa thãi đến một mức độ sâu hơn có thể tăng tốc đáng kể quá trình Finality, đồng thời tối đa hóa thông lượng và hiệu quả. Bởi vì thực tế, vài lớp đầ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 sau sẽ không còn quan trọng nữa.
) SVM
Solana có khả năng 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 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 đó, để cải thiện tốc độ thực hiện giao dịch cho SVM, Solana đã đưa ra độ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 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 xung đột về trạng thái, mỗi lệnh được biểu diễn 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 trình xác thực của Solana rất cao, vì yêu cầu các trình xác thực có GPU/CPU hỗ trợ SIMD### lệnh đơn dữ liệu đa( 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 hướng tới 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 nghiêng về các ứng dụng dành cho người tiêu dùng, chứ không phải sự cạnh tranh vô hạn về cơ sở 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 thấp hơn, nên hệ sinh thái Ethereum vẫn chủ yếu dựa 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ể tiếp nhận ứng dụng, cũng không thể xây dựng các ứng dụng dành 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 đầu tư vào ứng dụng lại quá ít.
) 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í đoàn kết 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 xa để thu hút đủ sự chú ý từ thị trường.
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.
17 thích
Phần thưởng
17
10
Đăng lại
Chia sẻ
Bình luận
0/400
GateUser-2fce706c
· 08-01 04:55
Mọi người đều đang chờ đợi đợt đáy này, những người không hiểu vẫn đang do dự. Đã nói rằng bây giờ chính là cơ hội để sắp xếp.
Xem bản gốcTrả lời0
MidsommarWallet
· 08-01 02:18
sol khó nói lắm, thôi không nhìn nhiều về tăng hay giảm nữa.
Xem bản gốcTrả lời0
SmartContractRebel
· 07-31 10:04
Nói nhiều quá, còn không bằng làm nhiều coin hơn.
Xem bản gốcTrả lời0
ApeWithNoChain
· 07-29 20:43
Quá lạc quan về sol!
Xem bản gốcTrả lời0
SigmaBrain
· 07-29 20:43
bull ơi, đợt này có thể kiếm được tiền
Xem bản gốcTrả lời0
MevHunter
· 07-29 20:41
Chậc chậc, vẫn phải dựa vào công nghệ để nói chuyện.
Xem bản gốcTrả lời0
MiningDisasterSurvivor
· 07-29 20:33
sàn giao dịch重启就等着Bị thanh lý吧
Xem bản gốcTrả lời0
WalletWhisperer
· 07-29 20:22
các mô hình giao dịch cho thấy sol đã chạm đáy... giai đoạn tích lũy được phát hiện fr
Phân tích công nghệ Solana và phát triển hệ sinh thái: Liệu kiến trúc hiệu suất cao có thể giúp tái xuất hiện?
Phân tích kiến trúc kỹ thuật Solana: Sẽ đó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 tăng tốc độ tạo khối. Cơ chế Turbine tối ưu hóa việc truyề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 đều là thiết kế kiến trúc của Solana để đạt được 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, 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 tập trung vào ứng dụng cho người 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 cho người tiêu dùng, Solana đã thể hiện tầm nhìn của mình về việc thúc đẩy ứ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ợ các ứng dụng 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 sự chấp nhận và 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 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. Base, như một đối thủ tiềm năng trong hệ sinh thái EVM, đang nhanh chóng tăng số lượng địa chỉ hoạt động trên chuỗi, trong khi tổng giá trị khóa (TVL) trong 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ị phần, và 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à độ chấp nhận của 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 là trong việc cải thiện 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 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 để 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, mạng truyền dữ liệu Trubine và máy ảo SVM mang lại TPS cao và Finality nhanh. Chúng tôi sẽ giới thiệu ngắn gọn về cách thức hoạt động của từng thành phần, cách chúng phát huy mục tiêu hiệu suất cao trong thiết kế kiến trúc, cũng như những bất lợi và vấn đề phát sinh dưới thiết kế kiến trúc này.
) thuật toán POH
POH###Proof of History( là một kỹ thuật 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. Kỹ thuật 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, cho một đầu vào X, sẽ có và chỉ có một đầu ra duy nhất Y, vì vậy 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, đồng nghĩa với việc 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 giao dịch thành một khối, tạo ra giá trị băm sha256 tương ứng, thì giao dịch trong khối này sẽ được xác định, bất kỳ sự 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 được xác định, bất kỳ sự thay đổi nào cũng sẽ dẫn đến Y mới khác nhau.
Điều này chính là ý nghĩa cốt lõi của công nghệ Proof of History, mã 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ử.
![Tái giải cấu trúc kỹ thuật Solana: Liệu có đón chào mùa xuân thứ hai không?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
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 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 Validator trên chuỗi, nút Lãnh đạo này thu thập các 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 sự cố điểm đơn tại nút Leader, giới hạn thời gian đã được đưa vào. Trong Solana, đơn vị thời gian được chia thành 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(400ms) trong thời gian slot đã cho, nếu không, nó sẽ bỏ qua slot này và bầu chọn 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, 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 rồi thực hiện để tạo ra khối, khối được phát tán cho các người xác nhận khác, các người xác nhậ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 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 xuất phát 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 một 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ì băm khối 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 sử dụng như một 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 duy nhất.
![Giải thích lại kiến trúc kỹ thuật Solana: Có phải sẽ đón nhận mùa xuân thứ hai?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.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 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 là có thể 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 tán khối, tức là một xác thực viên nhận được khối và sau đó gửi nó 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ó nhiều giao dịch bỏ phiếu của các validator, và nhờ vào hiệu suất cao do sự tập trung của các nút Leader cũng như 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 xuất khối đều đặc biệt cao. Khi các khối lớn được phát tán, nó cũng gây ra áp lực lớn cho 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
Node Leader chia nhỏ các khối thành các sub-block gọi là shreds thông qua một quá trình được gọi là Sharding, kích thước của chúng theo MTU) đơn vị dung lượng truyền tối đa, mà không cần chia nhỏ thành các đơn vị nhỏ hơn có thể gửi từ một nút sang nút tiếp theo với khối lượng dữ liệu tối đa ###. Sau đó, sử dụng phương pháp mã sửa lỗi Reed-solomon để đảm bảo tính toàn vẹn và khả 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 việc 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 đựng tới 50% tỷ lệ mất gói. 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 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 nền, người ta thường xem xét việc sử dụng giao thức UDP/TCP. Do độ dung nạp của Solana đối với 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 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ẽ giảm đáng kể tốc độ truyền 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 mảnh dữ liệu, nó sử dụng cơ chế lan truyền nhiều lớp để tiến hành lan truyền. Nút Leader sẽ giao khối cho bất kỳ trình xác thực khối nào trước khi mỗi Slot kết thúc, sau đó trình xác thực sẽ phân mảnh khối thành Shreds và tạo mã sửa lỗi, trình xác thực đó sẽ bắt đầu lan truyền Turbine. Đầu tiên, nó phải được lan truyền đến nút gốc, sau đó nút gốc sẽ xác định các trình xác thực nào nằm ở cấp độ 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 người xác thực hoạt động vào một danh sách, sau đó sắp xếp theo quyền lợi của mỗi người xác thực trong mạng, tức là số lượng SOL đã được đặt cọc (, người có trọng số cao hơn sẽ nằm ở tầng đầu tiên, và cứ như vậy.
Nhóm nút: Sau đó, mỗi người xác thực nằm ở tầng đầu tiên cũng sẽ tạo danh sách nút riêng của mình để xây dựng tầng đầu tiên của riêng mình.
Hình thành lớp: Chia các nút thành các lớp từ đầu danh sách, thông qua việc 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.
Node có tỷ lệ quyền lợi cao hơn, khi phân chia cấp độ, sẽ ở cấp cao hơn, do đó có thể nhận được shreds đầy đủ sớm hơn, lúc này có thể phục hồi khối đầy đủ, trong khi các node ở 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 đi. Nếu những shreds này không đủ để xây dựng mảnh hoàn chỉnh, sẽ yêu cầu Leader trực tiếp truyền tải lại. Lúc này, dữ liệu sẽ được truyền vào bên trong cây, trong khi các node ở tầng đầu tiên đã xây dựng xong xác nhận khối đầy đủ, thời gian sau khi các xác thực ở các tầng phía sau hoàn thành việc xây dựng khối để 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 nút 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 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ự thừa thãi đến một mức độ sâu hơn có thể tăng tốc đáng kể quá trình Finality, đồng thời tối đa hóa thông lượng và hiệu quả. Bởi vì thực tế, vài lớp đầ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 sau sẽ không còn quan trọng nữa.
) SVM
Solana có khả năng 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 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 đó, để cải thiện tốc độ thực hiện giao dịch cho SVM, Solana đã đưa ra độ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 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 xung đột về trạng thái, mỗi lệnh được biểu diễn 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 trình xác thực của Solana rất cao, vì yêu cầu các trình xác thực có GPU/CPU hỗ trợ SIMD### lệnh đơn dữ liệu đa( 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 hướng tới 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 nghiêng về các ứng dụng dành cho người tiêu dùng, chứ không phải sự cạnh tranh vô hạn về cơ sở 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 thấp hơn, nên hệ sinh thái Ethereum vẫn chủ yếu dựa 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ể tiếp nhận ứng dụng, cũng không thể xây dựng các ứng dụng dành 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 đầu tư vào ứng dụng lại quá ít.
) 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í đoàn kết 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 xa để thu hút đủ sự chú ý từ thị trường.
Hiện tại trong toàn bộ DEX