Solana Transaction Pipelining: TPU 4-Stage Pipeline

Hướng dẫn kỹ thuật này giải thích đường ống 4 giai đoạn TPU của Solana và cách nó hỗ trợ xử lý song song.

Solana tạo ra một khối mới xấp xỉ mỗi 400 mili giây. Hầu hết các blockchain xử lý giao dịch từng cái một, chờ đợi mỗi giao dịch hoàn thành trước khi bắt đầu giao dịch tiếp theo. Solana thì không.

Xử lý giao dịch theo hàng đợi của Solana là phương pháp mà Đơn vị xử lý giao dịch của Solana di chuyển các giao dịch đến thông qua bốn giai đoạn tuần tự: Fetch (Nạp), SigVerify (Xác minh Chữ ký), Banking (Ngân hàng) và Writing (Ghi). Nhiều lô giao dịch đi qua các giai đoạn này đồng thời, sao cho trong khi một lô đang được ghi vào sổ cái, lô tiếp theo đang được xác thực và lô thứ ba đang được nạp. Việc xử lý song song này là những gì cho phép Solana (SOL), tài sản gốc của blockchain Solana (sổ lệnh phân tán nơi tất cả các giao dịch được ghi lại), đạt được các con số thông lượng vượt xa hầu hết các mạng Lớp 1.

Solana được xây dựng bởi Anatoly Yakovenko, cựu kỹ sư Qualcomm, người đã xuất bản Whitepaper Bằng chứng Lịch sử vào năm 2017, giới thiệu cơ chế đồng hồ mật mã làm cho tốc độ của đường ống khả thi. Solana Labs, tổ chức có trụ sở tại San Francisco đã phát triển giao thức, đã triển khai xử lý theo hàng đợi như một tính năng cốt lõi của trình xác thực. Kết quả là một mạng lưới đã trở thành Nền tảng hàng đầu cho tài chính phi tập trung (DeFi) ứng dụng, bao gồm các sàn giao dịch phi tập trung, giao thức cho vay và thị trường Phái sinh trên chuỗi yêu cầu thời gian hoàn tất giao dịch dưới một giây.

Bộ ba bất khả thi của Blockchain được trích dẫn rộng rãi Blockchain cho rằng các blockchain chỉ có thể ưu tiên hai trong ba thuộc tính: khả năng mở rộng, bảo mật và phi tập trung. Xử lý giao dịch theo hàng đợi của Solana là câu trả lời kiến trúc của nó cho khía cạnh khả năng mở rộng. Bài viết này bao gồm xử lý theo hàng đợi là gì, bốn giai đoạn TPU hoạt động về mặt cơ học như thế nào, Bằng chứng Lịch sử cho phép đường ống như thế nào, cách Gulf Stream và Turbine bao bọc đầu vào và đầu ra của đường ống, cách Sealevel mở rộng nguyên tắc xử lý theo hàng đợi cho việc thực thi Hợp đồng Thông minh, cách Solana so sánh với Ethereum về kiến trúc và nơi chứa các đánh đổi và giới hạn được ghi nhận của đường ống.

Mục lục

1. Xử lý giao dịch theo hàng đợi của Solana là gì? (Và tại sao nó quan trọng đối với SOL)
2. Đường ống TPU của Solana hoạt động như thế nào: Giải thích bốn giai đoạn
3. Bằng chứng Lịch sử: Đồng hồ mật mã làm cho Pipelining khả thi
4. Gulf Stream: Giao dịch đi vào đường ống như thế nào trước khi sẵn sàng
5. So sánh đường ống CPU: Tại sao kiến trúc của Solana lại quen thuộc với các Kỹ sư
6. Turbine: Đầu ra của đường ống đến mạng lưới như thế nào
7. Sealevel: Pipelining được mở rộng cho việc thực thi Hợp đồng Thông minh
8. Solana so với Ethereum: So sánh kiến trúc đường ống
9. Hạn chế, tắc nghẽn và các đánh đổi thực tế của kiến trúc đường ống Solana
10. Câu hỏi thường gặp về Xử lý giao dịch theo hàng đợi của Solana
11. Xử lý giao dịch theo hàng đợi của Solana và Luận điểm Đầu tư SOL

Xử lý giao dịch theo hàng đợi của Solana là gì? (Và tại sao nó quan trọng đối với SOL)

Xử lý giao dịch theo hàng đợi của Solana là kỹ thuật chia nhỏ việc xử lý giao dịch thành các giai đoạn riêng biệt và chạy các giai đoạn đó đồng thời trên nhiều lô giao dịch, sao cho không có phần cứng xác thực nào bị rảnh rỗi chờ đợi giai đoạn khác hoàn thành. Hãy nghĩ về nó giống như một dây chuyền lắp ráp ô tô: các phương tiện khác nhau ở các trạm khác nhau cùng lúc và dây chuyền không bao giờ dừng lại để một chiếc xe hoàn thành hoàn toàn trước khi chiếc tiếp theo vào.

Solana mượn ý tưởng này từ các bộ xử lý máy tính. Các CPU hiện đại đạt được thông lượng cao thông qua xử lý theo hàng đợi ở cấp độ lệnh: trong khi một lệnh đang được thực thi, lệnh tiếp theo đang được giải mã và lệnh sau đó đã được nạp. Solana áp dụng cùng một logic cho các giao dịch ở cấp độ người xác thực. Bản đồ đầy đủ các giai đoạn CPU với các giai đoạn TPU của Solana được đề cập trong phần so sánh CPU bên dưới, nhưng nguyên tắc cốt lõi là giống nhau: giữ cho mọi giai đoạn luôn bận rộn.

Hầu hết các blockchain xử lý giao dịch tuần tự, nghĩa là người xác thực phải hoàn thành toàn bộ quá trình xử lý trên một giao dịch (hoặc lô) trước khi bắt đầu giao dịch tiếp theo. Mô hình tuần tự này tạo ra một trần thông lượng được xác định hoàn toàn bởi tốc độ mà một chuỗi thao tác duy nhất có thể chạy. Xử lý theo hàng đợi phá vỡ trần đó bằng cách chạy nhiều thao tác song song trên các thành phần phần cứng chuyên dụng, giảm độ trễ xác nhận (thời gian từ khi gửi giao dịch đến khi nhận được xác nhận hoàn tất) mà không yêu cầu mỗi giai đoạn riêng lẻ phải chạy nhanh hơn.

TPS lý thuyết của Solana, theo tài liệu kỹ thuật của Solana, là khoảng 65.000 giao dịch mỗi giây. Con số này đại diện cho mức tối đa của đường ống trong điều kiện lý tưởng. TPS thực tế không bao gồm giao dịch bỏ phiếu thấp hơn đáng kể, thường dao động từ 2.000 đến 4.000 TPS tùy thuộc vào tải mạng và thành phần giao dịch. Solana đếm riêng các giao dịch bỏ phiếu xác thực và các giao dịch không bỏ phiếu do người dùng tạo; tổng số TPS bao gồm cả bỏ phiếu cao hơn nhưng ít ý nghĩa hơn với tư cách là một chỉ số thông lượng cho người dùng. Để so sánh, Ethereum xử lý khoảng 15 đến 30 giao dịch mỗi giây ở Lớp 1, và Bitcoin xử lý khoảng 7 giao dịch mỗi giây.

Thống kê chính

Đường ống TPU của Solana tạo ra một khối mới khoảng mỗi ~400ms, nhanh hơn khoảng 30 lần so với thời gian khối ~12 giây của Ethereum. TPS lý thuyết: ~65.000. TPS thực tế không bao gồm giao dịch bỏ phiếu: ~2.000-4.000 (thay đổi theo tải mạng).

Lưu ý phương pháp tính TPS: Con số ~65.000 là mức tối đa lý thuyết từ tài liệu kỹ thuật của Solana. Thông lượng thực tế không bao gồm giao dịch bỏ phiếu thay đổi theo điều kiện mạng. Các giao dịch bỏ phiếu được loại trừ khỏi con số 2.000-4.000. Các con số của Ethereum đại diện cho thông lượng Lớp 1 và loại trừ các giải pháp Lớp 2.

Cơ chế làm cho điều này khả thi là Đơn vị xử lý giao dịch (TPU) của Solana, một đường ống bốn giai đoạn chạy bên trong mỗi trình xác thực dẫn đầu. Phần tiếp theo giải thích cách đường ống đó hoạt động về mặt cơ học.

Đường ống TPU của Solana hoạt động như thế nào: Giải thích bốn giai đoạn

Cơ chế đằng sau tốc độ của Solana là một đường ống bốn giai đoạn được đặt trong Đơn vị xử lý giao dịch (TPU), chạy bên trong trình xác thực dẫn đầu cho mỗi slot, xử lý nhiều lô giao dịch đồng thời thông qua phần cứng chuyên dụng ở mỗi giai đoạn.

Đơn vị xử lý giao dịch (TPU) là gì?

Trong Solana, Đơn vị xử lý giao dịch (TPU) là bộ máy đường ống bên trong mỗi nút xác thực thực hiện xử lý giao dịch. Đây là thuật ngữ chuyên dụng của Solana và không liên quan đến Tensor Processing Unit của Google được sử dụng trong học máy.

TPU hoạt động độc quyền trên trình xác thực dẫn đầu cho mỗi khe ~400ms. Các trình xác thực không phải là người dẫn đầu chạy Đơn vị Xác thực Giao dịch (TVU), đơn vị này phát lại và xác minh các khối do người dẫn đầu tạo ra. Solana xác định trình xác thực nào hoạt động như người dẫn đầu thông qua Lịch trình Dẫn đầu mang tính xác định, được công bố trước cho mỗi kỷ nguyên (khoảng 2 đến 3 ngày), nhằm chỉ định các khe dẫn đầu của mỗi trình xác thực dựa trên trọng số đặt cược của nó. Lịch trình này là yếu tố giúp định tuyến trước giao dịch của Gulf Stream trở nên khả thi, như đã thảo luận trong phần Gulf Stream bên dưới.

Để biết chi tiết kỹ thuật về kiến trúc TPU, xem tài liệu chính thức về TPU của Solana và tài liệu về thời gian khe của Solana.

Bốn Giai đoạn của Đường ống TPU Solana

Đường ống TPU xử lý các giao dịch qua bốn giai đoạn tuần tự, mỗi giai đoạn được xử lý bởi phần cứng chuyên dụng, mỗi giai đoạn chuyển đầu ra của nó cho giai đoạn tiếp theo đồng thời nhận đầu vào mới từ giai đoạn trước.

1. Truy xuất: Ngăn xếp mạng nhận các gói giao dịch thô qua QUIC (một giao thức truyền tải hiện đại thay thế kết nối UDP ban đầu để cải thiện khả năng kiểm soát tắc nghẽn). Giai đoạn Truy xuất là bộ phận tiếp nhận của đường ống. Nó lấy các giao dịch từ bộ đệm đã được tải trước mà Gulf Stream đã lấp đầy trước khi khe bắt đầu, và chuyển các gói đã xác minh cho SigVerify.

2. Xác minh chữ ký (SigVerify): GPU xác minh chữ ký mật mã trên các giao dịch đến. Mỗi giao dịch Solana bao gồm một hoặc nhiều chữ ký số phải được xác thực trước khi bất kỳ thay đổi trạng thái nào có thể xảy ra. Việc tăng tốc GPU cho phép hàng nghìn lượt xác minh chữ ký chạy song song trong một giai đoạn duy nhất này. SigVerify là điểm kiểm tra xác thực: các giao dịch vượt qua sẽ chuyển sang Giai đoạn Xử lý Tài khoản (Banking); các giao dịch không vượt qua sẽ bị loại bỏ.

3. Xử lý Tài khoản (Banking): CPU áp dụng các giao dịch đã được xác thực vào trạng thái sổ cái, thực hiện các giao dịch ghi nợ và ghi có tài khoản cũng như xử lý các thay đổi trạng thái hợp đồng thông minh. Giai đoạn Xử lý Tài khoản là bộ phận kế toán của đường ống và là giai đoạn tốn nhiều tài nguyên tính toán nhất. Đây cũng là điểm nghẽn chính dưới tải cao: khi khối lượng giao dịch vượt quá khả năng xử lý của Giai đoạn Xử lý Tài khoản, đường ống sẽ bắt đầu loại bỏ các giao dịch thay vì xếp chúng vào hàng đợi.

4. Ghi: SSD NVMe ghi các mục nhập sổ cái đã xác nhận vào đĩa, và giai đoạn này phát dữ liệu khối kết quả tới phần còn lại của mạng thông qua Turbine. Giai đoạn Ghi là giai đoạn phân phối và lưu trữ: sau khi hoàn thành, khối đó tồn tại trên chuỗi và quá trình lan truyền bắt đầu.

Cơ chế đường ống cốt lõi hoạt động trên tất cả bốn giai đoạn cùng một lúc. Trong khi lô N đang ở Giai đoạn Xử lý Tài khoản, lô N-1 đã ở Giai đoạn Ghi, và lô N+1 đã ở Giai đoạn Xác minh chữ ký. Không có giai đoạn nào chờ giai đoạn khác hoàn thành lô hiện tại trước khi bắt đầu lô tiếp theo. Đây là cách đường ống đạt được thông lượng song song: mọi phần cứng đều được sử dụng mọi lúc trong khe.

[CẦN SƠ ĐỒ: DIAGRAM-01] Đường ống bốn giai đoạn hiển thị các lô A, B, C, D tại các giai đoạn khác nhau đồng thời. Lô A: Ghi (SSD NVMe). Lô B: Xử lý Tài khoản (CPU). Lô C: Xác minh chữ ký (GPU). Lô D: Truy xuất (mạng). Các mũi tên hiển thị sự tiến triển của mỗi lô qua các giai đoạn VÀ hoạt động đồng thời trên cả bốn giai đoạn.

Ai Điều hành Đường ống? Trình xác thực và Lịch trình Dẫn đầu

Các trình xác thực Solana là những nhà điều hành nút vật lý chạy đường ống TPU. Mỗi trình xác thực là một máy chủ chuyên dụng chạy phần mềm Solana, chịu trách nhiệm hoặc tạo khối (nếu nó là người dẫn đầu hiện tại) hoặc xác minh và phát lại các khối do người dẫn đầu tạo ra (sử dụng TVU).

Lịch trình Dẫn đầu chỉ định trình xác thực nào chạy TPU cho mỗi khe ~400ms. Lịch trình được tính toán theo cách xác định từ tập hợp các trình xác thực đã cân nhắc trọng số đặt cược khi bắt đầu mỗi kỷ nguyên, vì vậy các trình xác thực biết các khe dẫn đầu sắp tới của họ trước nhiều ngày. Khả năng dự đoán này cho phép Gulf Stream định tuyến trước các giao dịch đến người dẫn đầu sắp tới trước khi khe của họ bắt đầu, đảm bảo bộ đệm Giai đoạn Truy xuất đầy khi khe bắt đầu.

Việc chạy đường ống TPU đòi hỏi phần cứng cấp doanh nghiệp: một GPU chuyên dụng cho giai đoạn Xác minh chữ ký, một CPU có số lượng lõi cao cho giai đoạn Xử lý Tài khoản, SSD NVMe cấp doanh nghiệp cho giai đoạn Ghi và mạng băng thông cao cho giai đoạn Truy xuất. Những yêu cầu này cao hơn đáng kể so với ngưỡng phần cứng trình xác thực của Ethereum, tạo ra sự đánh đổi về tập trung hóa được đề cập trong phần hạn chế. Đối với các thông số kỹ thuật phần cứng trình xác thực hiện tại, xem tài liệu yêu cầu trình xác thực của Solana.

Lịch sử Bằng chứng (Proof of History): Đồng hồ mật mã giúp Đường ống hoạt động

Proof of History (PoH) là cơ chế mật mã cho phép đường ống của Solana hoạt động nhanh như phần cứng cho phép, mà không yêu cầu các trình xác thực phải giao tiếp với nhau để thống nhất về thời gian của mỗi lô giao dịch trước khi chuyển sang giai đoạn tiếp theo.

Cơ chế hoạt động như sau. PoH tạo ra một chuỗi băm SHA-256 liên tục, trong đó mỗi giá trị băm lấy giá trị băm trước đó làm đầu vào. Bởi vì tính toán SHA-256 mất một lượng thời gian có thể đo lường và xác minh được, chuỗi băm kết quả tạo thành một bằng chứng mật mã cho thấy một lượng thời gian cụ thể đã trôi qua giữa bất kỳ hai sự kiện nào được ghi lại trong chuỗi. Mọi trình xác thực đều có thể xác minh chuỗi này một cách độc lập mà không cần liên hệ với các trình xác thực khác.

Kết nối với đường ống là trực tiếp. Nếu không có PoH, đường ống sẽ phải tạm dừng ở mỗi giai đoạn và chờ mạng đạt được sự đồng thuận về thứ tự của lô giao dịch hiện tại trước khi giai đoạn tiếp theo có thể bắt đầu. Vòng lặp giao tiếp giữa các nút đó sẽ là yếu tố độ trễ chi phối, khiến thời gian khe 400ms không thể thực hiện được ở quy mô mạng. PoH loại bỏ sự chờ đợi này bằng cách cung cấp một chiếc đồng hồ được chia sẻ, có thể xác minh mà tất cả các trình xác thực có thể kiểm tra cục bộ. Đường ống tiến triển dựa trên đồng hồ PoH, chứ không phải dựa trên các vòng lặp tin nhắn mạng.

Anatoly Yakovenko đã giới thiệu Lịch sử Bằng chứng trong Whitepaper Lịch sử Bằng chứng xuất bản năm 2017, dựa trên nền tảng của ông về hệ thống phân tán từ thời làm việc tại Qualcomm.

PoH không phải là Bằng chứng về Stake.

Lịch sử Bằng chứng KHÔNG phải là cơ chế đồng thuận của Solana. Nó là một chiếc đồng hồ mật mã giúp sắp xếp các sự kiện và chứng minh thời gian trôi qua. Solana sử dụng Bằng chứng về Stake (cụ thể là Tower BFT, việc triển khai Lỗi Bằng chứng Thực tế của nó) cho sự đồng thuận, cơ chế này xác định trình xác thực nào đủ điều kiện về mặt kinh tế để tham gia và trình xác thực nào dẫn đầu mỗi khe. PoH cung cấp thứ tự và thời gian. Bằng chứng về Stake cung cấp bảo mật kinh tế và khả năng chống Sybil. Đây là các chức năng riêng biệt.

Để có lời giải thích đầy đủ về cách thức hoạt động của Lịch sử Bằng chứng, bao gồm cả cấu trúc mật mã của nó và mối quan hệ của nó với cơ chế đồng thuận của Solana, hãy xem [trình giải thích Lịch sử Bằng chứng chuyên dụng của chúng tôi].

PoH cung cấp chiếc đồng hồ. Gulf Stream đảm bảo hộp thư đến của đường ống luôn đầy.

Gulf Stream: Cách Giao dịch Đi vào Đường ống Trước Khi Sẵn sàng

Gulf Stream là giao thức chuyển tiếp giao dịch của Solana, và nó là yếu tố đảm bảo Giai đoạn Truy xuất của đường ống không bao giờ bị đình trệ vì chờ đợi giao dịch đến. Hầu hết các blockchain lưu giữ các giao dịch chưa được xác nhận trong một mempool toàn cầu, nơi chúng chờ bất kỳ trình xác thực nào lấy chúng. Solana không có mempool toàn cầu. Gulf Stream thay thế mô hình này bằng việc định tuyến trước mang tính xác định.

Cơ chế hoạt động theo bốn bước:

1. Lịch trình Dẫn đầu của Solana công bố trước trình xác thực nào sẽ dẫn đầu mỗi khe ~400ms sắp tới.
2. Khi người dùng hoặc ứng dụng gửi một giao dịch, Gulf Stream sẽ định tuyến nó trực tiếp đến trình xác thực sẽ dẫn đầu khe liên quan tiếp theo, chứ không phải đến một nhóm chia sẻ.
3. Vào thời điểm khe dẫn đầu của trình xác thực đó bắt đầu, bộ đệm Giai đoạn Truy xuất của nó đã được nạp sẵn các giao dịch.
4. Giai đoạn Truy xuất lấy dữ liệu từ bộ đệm đã được nạp sẵn này thay vì chờ đợi giao dịch đến trong khe.

Thiết kế không có mempool này mang lại ba lợi ích có thể đo lường được: nó giảm độ trễ xác nhận vì giao dịch tốn ít thời gian chờ đợi hơn, nó loại bỏ chi phí bộ nhớ mà mempool toàn cầu áp đặt lên mỗi trình xác thực và nó giảm đáng kể yêu cầu bộ nhớ trên mỗi trình xác thực.

Sự đánh đổi này là có hệ quả: vì không có bộ đệm giao dịch lâu dài, các giao dịch không được xử lý nhanh chóng sẽ bị hủy thay vì được xếp vào hàng đợi. Người dùng nhận được lỗi “giao dịch hết hạn” và phải gửi lại. Dưới tải mạng cao, hành vi này là một trong những cơ chế góp phần gây ra các sự kiện tắc nghẽn, như đã thảo luận trong phần hạn chế.

Gulf Stream kết nối trực tiếp với giai đoạn Fetch.

Gulf Stream định tuyến trước các giao dịch đến người lãnh đạo sắp tới bằng cách sử dụng Lịch trình Lãnh đạo tất định. Khi giai đoạn Fetch TPU của trình xác thực kích hoạt, nó sẽ lấy dữ liệu từ một bộ đệm được tải sẵn, chứ không phải từ mempool toàn cầu. Đây là lý do tại sao pipeline của Solana hiếm khi phải chờ đầu vào ở giai đoạn Fetch trong điều kiện bình thường.

Nếu Gulf Stream là cơ chế đầu vào của pipeline, thì Turbine là cơ chế đầu ra.

Phép so sánh Pipeline CPU: Tại sao Kiến trúc của Solana Nên quen thuộc với Kỹ sư

Pipeline giao dịch của Solana vay mượn nguyên tắc kiến trúc giống như những gì làm cho CPU hiện đại nhanh chóng: pipelining cấp độ lệnh. Đây không phải là phép ẩn dụ. Thiết kế này được lấy cảm hứng kiến trúc từ kỹ thuật thông lượng giống như trong văn bản nền tảng Computer Organization and Design của Patterson và Hennessy.

Một pipeline lệnh CPU hoạt động như sau. Thay vì chờ một lệnh hoàn thành tất cả các giai đoạn xử lý trước khi lấy lệnh tiếp theo, CPU chia quá trình thực thi thành các giai đoạn tuần tự (Fetch, Decode, Execute, Write-back) và chạy các giai đoạn đó đồng thời trên các lệnh khác nhau. Trong khi lệnh N đang thực thi, lệnh N+1 đang được giải mã và lệnh N+2 đã được lấy. Kết quả là thông lượng tăng tỷ lệ thuận với số lượng giai đoạn pipeline, mà không yêu cầu bất kỳ giai đoạn riêng lẻ nào chạy nhanh hơn.

Pipeline TPU của Solana áp dụng nguyên tắc tương tự cho các giao dịch. Việc ánh xạ từng giai đoạn rất trực tiếp:

[CẦN BIỂU ĐỒ: DIAGRAM-02] Biểu đồ so sánh song song. Bên trái: Pipeline lệnh CPU với các giai đoạn Fetch, Decode, Execute, Write-back và các mũi tên sóng cho thấy xử lý lệnh đồng thời. Bên phải: Pipeline TPU Solana với các giai đoạn Fetch, SigVerify, Banking, Writing và các mũi tên sóng cho thấy xử lý lô đồng thời. Các đường ánh xạ giữa các giai đoạn tương tự.

Nơi phép so sánh giữ nguyên: Cả hai kiến trúc đều đạt được tăng thông lượng bằng cách giữ cho tất cả các giai đoạn bận rộn đồng thời. Không bên nào chờ một mục hoàn thành trước khi bắt đầu mục tiếp theo. Cả hai đều xử lý các mục theo từng đợt, với nhiều mục ở các giai đoạn khác nhau tại bất kỳ thời điểm nào. Hiểu biết cơ bản là giống nhau: xử lý tuần tự lãng phí năng lực phần cứng; song song hóa pipeline loại bỏ sự lãng phí đó.

Nơi phép so sánh bị phá vỡ: Ba sự khác biệt quan trọng phân biệt pipeline của Solana với pipeline CPU.

Thứ nhất, pipeline của Solana hoạt động trên các thành phần phần cứng phân tán được kết nối bằng mạng, không phải trong một chip duy nhất. Điều kiện mạng ảnh hưởng đến hiệu suất pipeline theo những cách không có tương tự nào trên CPU.

Thứ hai, các chế độ lỗi khác nhau. Các nguy cơ của pipeline CPU bao gồm phụ thuộc dữ liệu (một lệnh cần đầu ra của lệnh trước đó chưa hoàn thành) và dự đoán sai nhánh (bộ xử lý đã lấy các lệnh đi sai đường). Các nguy cơ của pipeline Solana khác về bản chất: tấn công giao dịch hoạt động như một nguy cơ cấu trúc bằng cách làm quá tải giai đoạn Banking vượt quá khả năng xử lý của nó, và tắc nghẽn mạng hoạt động như một điều kiện tạm dừng làm chậm giai đoạn Fetch và Writing. Đây là các nguy cơ bên ngoài, được điều khiển bởi nhu cầu thay vì các nguy cơ bên trong, phụ thuộc vào dữ liệu.

Thứ ba, pipeline của Solana không có gì tương đương với việc thực thi ngoài luồng. Đồng hồ Proof of History thực thi thứ tự giao dịch nghiêm ngặt trong mỗi lô, do đó pipeline không thể sắp xếp lại các giao dịch để tránh xung đột theo cách mà CPU có thể sắp xếp lại các lệnh để tránh nguy cơ dữ liệu.

Hiểu phép so sánh này và giới hạn của nó là điều phân biệt kiến thức bề nổi về tốc độ của Solana với sự hiểu biết sâu sắc về kiến trúc.

Turbine: Cách Đầu ra của Pipeline Tiếp cận Mạng

Turbine là giao thức truyền khối của Solana và nó xử lý những gì xảy ra sau khi giai đoạn Writing của pipeline hoàn thành. Nếu Gulf Stream đảm bảo pipeline luôn được cung cấp dữ liệu, thì Turbine đảm bảo đầu ra của pipeline đến phần còn lại của mạng một cách hiệu quả nhất có thể.

Sau khi giai đoạn Writing cam kết một lô giao dịch đã xác nhận vào sổ cái, Turbine chia khối kết quả thành các gói dữ liệu nhỏ hơn gọi là shreds và truyền chúng qua một mạng lưới các trình xác thực có cấu trúc cây. Thay vì phát sóng toàn bộ khối đến mọi trình xác thực đồng thời (điều này sẽ yêu cầu băng thông tải lên khổng lồ từ người lãnh đạo), Turbine phân phối tải truyền qua mạng. Mỗi trình xác thực trong cây nhận một tập hợp các shreds và chuyển tiếp chúng đến các trình xác thực khác xa hơn trong cây, tương tự về nguyên tắc như cách BitTorrent phân phối tệp bằng cách có nhiều nút chia sẻ tải phân phối. (Turbine sử dụng cây có cấu trúc thay vì một nhóm ngang hàng, đây là một sự khác biệt quan trọng đối với độ tin cậy của mạng.)

Thiết kế tương thích với pipelining có ý nghĩa ở đây: các shred bắt đầu được truyền đến phần còn lại của mạng trong khi trình xác thực lãnh đạo đã xử lý lô giao dịch tiếp theo qua pipeline. Việc truyền khối ở cấp độ mạng và sản xuất khối chạy song song. Việc phân tán khối N ở cấp độ mạng không tạo ra một khoảng dừng trong việc sản xuất khối N+1.

Lợi ích kỹ thuật là Solana đạt được băng thông khối cao mà không yêu cầu băng thông tải lên cấp doanh nghiệp ở mọi nút trình xác thực. Chỉ trình xác thực lãnh đạo mới chịu toàn bộ tải sản xuất; việc truyền được phân phối trên toàn mạng.

Bộ bao bọc đầu vào/đầu ra xung quanh pipeline TPU:

Gulf Stream: đầu vào pipeline (định tuyến trước các giao dịch đến người lãnh đạo sắp tới trước khi kỳ bắt đầu). Turbine: đầu ra pipeline (phân phối dữ liệu khối đã xác thực dưới dạng shreds qua mạng lưới trình xác thực). Cùng nhau, chúng đảm bảo pipeline TPU không bao giờ bị rảnh rỗi ở bất kỳ đầu nào.

Turbine xử lý đầu ra của pipeline ở cấp độ khối. Sealevel mở rộng nguyên tắc pipelining sâu hơn, đến lớp thực thi Hợp đồng Thông minh.

Sealevel: Pipelining Mở rộng đến Thực thi Hợp đồng Thông minh

Pipelining giao dịch không dừng lại ở TPU. Sealevel mở rộng cùng nguyên tắc xử lý song song đến việc thực thi Hợp đồng Thông minh, và đó là một trong những lợi thế kiến trúc ít được đánh giá cao nhất của Solana.

Sealevel là runtime Hợp đồng Thông minh song song của Solana. Nó cho phép hàng nghìn Hợp đồng Thông minh (gọi là programs trong kiến trúc Solana, một sự khác biệt với thuật ngữ của Ethereum có ý nghĩa đối với các nhà phát triển) thực thi đồng thời thay vì tuần tự. EVM của Ethereum (Máy ảo Ethereum) xử lý các Hợp đồng Thông minh trên một luồng đơn, nghĩa là chỉ có một hợp đồng có thể thực thi tại một thời điểm trên mỗi khối. Sealevel sử dụng tất cả các lõi CPU có sẵn để thực thi nhiều chương trình một cách song song.

Cơ chế này phụ thuộc vào mô hình tài khoản của Solana. Mỗi giao dịch Solana phải tuyên bố trước những tài khoản nào nó sẽ đọc và ghi vào. Sealevel sử dụng các tuyên bố này để sắp xếp các giao dịch thành các nhóm không chồng chéo: các giao dịch truy cập vào các tài khoản khác nhau có thể thực thi đồng thời mà không có rủi ro xung đột trạng thái, trong khi các giao dịch chia sẻ cùng tài khoản phải được xử lý tuần tự để đảm bảo tính chính xác.

Yêu cầu tuyên bố trước này là một ràng buộc thiết kế mà các nhà phát triển Solana phải tính đến khi xây dựng kiến trúc chương trình. Các chương trình phải tuyên bố trước tất cả các tài khoản mà chúng sẽ truy cập, điều này khác với mô hình truy cập trạng thái cởi mở hơn của Ethereum, nơi quyền truy cập lưu trữ của hợp đồng không được tuyên bố trước.

Sự tương đồng với cơ chế đường ống (pipelining) của TPU là rất rõ ràng. Giống như đường ống TPU giữ cho cả bốn giai đoạn phần cứng luôn bận rộn bằng cách xử lý các lô giao dịch khác nhau ở các giai đoạn khác nhau đồng thời, Sealevel giữ cho tất cả các lõi CPU có sẵn luôn bận rộn bằng cách thực thi các chương trình không xung đột đồng thời. Nguyên tắc giữ cho tất cả phần cứng luôn bận rộn mọi lúc được áp dụng ở đây tại lớp thực thi.

Để tìm hiểu sâu hơn về cách thức hoạt động của các tuyên bố tài khoản và mô hình tài khoản của Solana trong thực tế, hãy xem bài viết [Giải thích Mô hình Tài khoản Solana] của chúng tôi.

Solana so với Ethereum: So sánh Kiến trúc Đường ống

Sự khác biệt về hiệu suất giữa Solana và Ethereum bắt nguồn từ một lựa chọn kiến trúc cơ bản: xử lý đường ống song song so với thực thi giao dịch tuần tự.

EVM của Ethereum xử lý các giao dịch trong một hàng đợi đơn luồng. Một giao dịch phải hoàn tất trước khi giao dịch tiếp theo bắt đầu. Thiết kế này là có mục đích: thực thi tuần tự giúp đơn giản hóa việc quản lý trạng thái, làm cho hành vi của Hợp đồng Thông minh dễ suy luận hơn và cho phép các trình xác thực tham gia với phần cứng cấp độ người tiêu dùng, tạo ra một bộ trình xác thực rộng lớn và tương đối phi tập trung. Ethereum hiện có khoảng 900.000 hoặc nhiều hơn các trình xác thực đang hoạt động.

Ngược lại, đường ống TPU song song của Solana xử lý đồng thời nhiều lô giao dịch qua bốn giai đoạn phần cứng chuyên dụng. GPU tăng tốc xác minh chữ ký. CPU áp dụng các thay đổi trạng thái đồng thời trên các chương trình không xung đột thông qua Sealevel. Ổ cứng SSD NVMe xử lý các hoạt động ghi trong khi Turbine chạy quá trình truyền tin song song. Thiết kế này tạo ra thông lượng Lớp 1 cao hơn đáng kể, nhưng nó đòi hỏi phần cứng mạnh hơn nhiều và tạo ra một bộ trình xác thực tập trung hơn với khoảng 2.000 trình xác thực đang hoạt động.

Các con số về hiệu suất là rất cụ thể. Thời gian tạo khối của Ethereum là khoảng 12 giây; thời gian slot của Solana là khoảng 400 mili giây. TPS Lớp 1 của Ethereum là khoảng 15 đến 30; TPS thực tế (không bao gồm phiếu bầu) của Solana là khoảng 2.000 đến 4.000 tùy thuộc vào điều kiện mạng. (Bitcoin, để tham khảo theo quy mô, xử lý khoảng 7 giao dịch mỗi giây.) Các giải pháp Lớp 2 của Ethereum, bao gồm Arbitrum và Optimism, làm tăng đáng kể thông lượng hiệu quả của Ethereum vượt xa mức cơ sở Lớp 1 của nó, một bối cảnh quan trọng khi so sánh các con số Lớp 1 thô.

Để biết chi tiết về cách so sánh các kiến trúc này trên các phương diện đầu tư và phát triển, hãy xem bản so sánh đầy đủ kiến trúc Solana và Ethereum.

Không có kiến trúc nào là vượt trội hoàn toàn. Cả hai đều đại diện cho những sự đánh đổi có tính toán trong Bộ ba bất khả thi của Blockchain được đề cập rộng rãi. Ethereum đã đổi thông lượng để lấy sự phi tập trung và một hệ sinh thái Lớp 2 phong phú. Solana đã đổi sự phi tập trung để lấy thông lượng Lớp 1. Sự đánh đổi nào phục vụ tốt hơn cho một ứng dụng hoặc luận điểm đầu tư cụ thể còn tùy thuộc vào các yêu cầu riêng biệt.

Các hạn chế, Tắc nghẽn và Sự đánh đổi Thực tế của Kiến trúc Đường ống Solana

Kiến trúc đường ống của Solana mang lại những lợi thế về hiệu suất đã được chứng minh, và nó cũng đi kèm với những sự đánh đổi rõ ràng. Hiểu rõ cả hai là cần thiết cho bất kỳ sự đánh giá nghiêm túc nào về mạng lưới này, dù là để phát triển hay đầu tư.

Khi đường ống bị quá tải: Cách thức hoạt động của sự tắc nghẽn

Tắc nghẽn đường ống xảy ra khi khối lượng giao dịch vượt quá khả năng xử lý của giai đoạn Ngân hàng (Banking). Trình tự các sự kiện diễn ra cụ thể như sau. Giai đoạn Ngân hàng bị tụt lại phía sau khối lượng giao dịch đang đổ vào. Vì thiết kế Gulf Stream không có Mempool của Solana không duy trì bộ đệm giao dịch liên tục, các giao dịch không thể được xử lý nhanh chóng sẽ bị loại bỏ thay vì được xếp hàng chờ. Người dùng nhận được lỗi "giao dịch hết hạn" và phải gửi lại. Ở mức độ tắc nghẽn cực độ, các trình xác thực có thể mất đồng thuận vì đường ống không thể xử lý các giao dịch bỏ phiếu đủ nhanh so với tổng khối lượng giao dịch, khiến mạng bị đình trệ.

Solana đã trải qua các đợt ngừng hoạt động mạng lớn vào tháng 9 năm 2021, tháng 1 năm 2022 và tháng 5 năm 2022, cùng với các giai đoạn khác. Nguyên nhân không giống nhau. Trong một số trường hợp, khối lượng giao dịch quá lớn đã làm quá tải khả năng của giai đoạn Ngân hàng. Trong những trường hợp khác, nguyên nhân là các chiến dịch spam giao dịch có phối hợp, lỗi phần mềm hoặc lỗi đồng thuận không liên quan đến giới hạn thông lượng của đường ống. Việc quy kết tất cả các vụ ngừng hoạt động của Solana cho cơ chế đường ống là không chính xác. Các giới hạn công suất của đường ống, khi bị vượt quá trong các điều kiện cụ thể, đã góp phần vào một số sự cố ngừng hoạt động, trong khi các đợt ngừng hoạt động khác có những nguyên nhân gốc rễ riêng biệt.

Để có lịch sử được ghi chép lại về các sự kiện mạng của Solana và nguyên nhân của chúng, hãy xem bài viết [Ngừng hoạt động mạng Solana: Lịch sử và ý nghĩa đối với nhà đầu tư] của chúng tôi.

Các phản ứng về kiến trúc của Solana đối với sự tắc nghẽn

Solana đã thực hiện một số thay đổi về kiến trúc kể từ năm 2022 để giải quyết tình trạng tắc nghẽn đường ống:

• Áp dụng giao thức QUIC: Solana đã thay thế kết nối UDP ban đầu tại giai đoạn Fetch bằng QUIC (một giao thức truyền tải hiện đại cung cấp khả năng kiểm soát tắc nghẽn và quản lý kết nối mà UDP thiếu). QUIC cho phép giai đoạn Fetch quản lý việc tiếp nhận giao dịch thông minh hơn dưới tải trọng cao, giảm hiệu quả của việc spam giao dịch chi phí thấp.
• Chất lượng dịch vụ theo trọng số Staking (SWQoS): Solana đã giới thiệu chất lượng dịch vụ theo trọng số stake (SWQoS), ưu tiên các giao dịch được chuyển tiếp từ các trình xác thực có trọng số stake cao hơn. Điều này làm giảm khả năng của các tác nhân có stake thấp trong việc làm tràn đường ống bằng các giao dịch spam tiêu tốn năng lực của giai đoạn Ngân hàng, gây ảnh hưởng đến các giao dịch hợp lệ của người dùng.
• Phí ưu tiên: Người dùng có thể đính kèm phí ưu tiên vào các giao dịch, báo hiệu sự sẵn lòng trả tiền để được xử lý nhanh hơn qua đường ống trong các giai đoạn nhu cầu cao.
• Firedancer: Firedancer, một bản thực thi ứng dụng trình xác thực độc lập được phát triển bởi Jump Crypto, đang được phát triển và nhằm mục đích tăng đáng kể thông lượng đường ống và cải thiện khả năng phục hồi của mạng bằng cách cung cấp một ứng dụng thay thế giúp giảm rủi ro phụ thuộc vào một bản thực thi duy nhất.

Sự đánh đổi về tính tập trung: Yêu cầu phần cứng cao

Các yêu cầu phần cứng cao cho trình xác thực của Solana tạo ra một sự đánh đổi về tính tập trung có thể đo lường được. Việc vận hành đường ống TPU yêu cầu GPU doanh nghiệp cho giai đoạn SigVerify, CPU có số nhân cao cho giai đoạn Ngân hàng, ổ SSD NVMe doanh nghiệp cho giai đoạn Ghi (Writing), và mạng băng thông cao cho Fetch và Turbine. Những thông số kỹ thuật này tạo ra rào cản chi phí đáng kể đối với các trình xác thực cá nhân tại nhà.

Kết quả là một tập hợp trình xác thực tập trung hơn so với Ethereum. Solana có khoảng 2.000 trình xác thực đang hoạt động; Ethereum có khoảng 900.000 hoặc nhiều hơn (cả hai con số đều biến động và nên được xác minh theo dữ liệu mạng hiện tại). Solana Labs và Solana Foundation đã công nhận sự đánh đổi này một cách rõ ràng: các yêu cầu phần cứng là hệ quả tất yếu của lựa chọn thiết kế ưu tiên thông lượng, đại diện cho vị thế của Solana trên trục khả năng mở rộng - phi tập trung của Bộ ba bất khả thi của Blockchain. Việc sự đánh đổi này có thể chấp nhận được hay không tùy thuộc vào những gì người đánh giá ưu tiên.

Các câu hỏi thường gặp: Hệ thống đường ống giao dịch Solana

Đơn vị xử lý giao dịch (TPU) của Solana là gì?

Đơn vị xử lý giao dịch (TPU) của Solana là động cơ đường ống bên trong một nút trình xác thực, nơi trực tiếp xử lý các giao dịch. Đây là thuật ngữ của Solana, hoàn toàn không liên quan đến Đơn vị xử lý Tensor (TPU) của Google được sử dụng trong học máy. TPU chỉ chạy trên trình xác thực dẫn đầu (leader) cho mỗi slot ~400ms và hoạt động qua bốn giai đoạn: Fetch, SigVerify, Banking và Writing. Các trình xác thực không phải là leader sẽ chạy TVU (Đơn vị xác thực giao dịch) để xác minh và phát lại các khối thay thế.

Proof of History là gì và nó liên quan như thế nào đến hệ thống đường ống?

Proof of History (PoH) là một đồng hồ mật mã tạo ra một chuỗi các hàm băm SHA-256 có thể xác minh và được sắp xếp theo thời gian. PoH hỗ trợ hệ thống đường ống bằng cách loại bỏ nhu cầu các trình xác thực phải giao tiếp và đồng thuận về thứ tự giao dịch trước khi tiến hành từng giai đoạn đường ống. Không có PoH, độ trễ giao tiếp giữa các nút sẽ là nút thắt cổ chai chính; với PoH, đường ống tiến triển dựa trên một đồng hồ chung có thể xác minh cục bộ mà không cần phản hồi mạng lưới.

Gulf Stream trong Solana là gì?

Gulf Stream là giao thức chuyển tiếp giao dịch không có Mempool của Solana. Thay vì giữ các giao dịch chưa xác nhận trong một nhóm chung, Gulf Stream sử dụng Lịch trình Leader định trước để định tuyến các giao dịch trực tiếp đến trình xác thực dẫn đầu sắp tới trước khi slot của nó bắt đầu. Khi giai đoạn Fetch của leader được kích hoạt, nó sẽ lấy từ một bộ đệm đã được tải trước. Việc định tuyến trước này là lý do tại sao Solana có thể duy trì thời gian slot ~400ms mà giai đoạn Fetch không phải chờ giao dịch đến.

Sealevel là gì?

Sealevel là môi trường thực thi Hợp đồng Thông minh song song của Solana. Nó cho phép hàng nghìn Hợp đồng Thông minh (được gọi là các chương trình trong kiến trúc của Solana) thực thi đồng thời bằng cách yêu cầu mỗi giao dịch phải khai báo trước những tài khoản nào nó sẽ đọc và ghi. Sealevel xác định các giao dịch không chồng chéo và chạy chúng song song trên tất cả các lõi CPU có sẵn, mở rộng cùng một nguyên tắc xử lý song song từ đường ống TPU sang lớp thực thi Hợp đồng Thông minh.

Hệ thống đường ống giao dịch của Solana có gây ra sự cố mạng không?

Tắc nghẽn đường ống đã góp phần gây ra một số sự cố mạng của Solana, nhưng không phải tất cả. Khi khối lượng giao dịch vượt quá công suất của giai đoạn Ngân hàng, thiết kế không có Mempool khiến các giao dịch bị loại bỏ thay vì xếp hàng, và khi tắc nghẽn cực độ, các trình xác thực có thể mất đồng thuận. Solana cũng từng gặp phải các sự cố do lỗi phần mềm, lỗi đồng thuận và spam giao dịch có phối hợp không liên quan đến giới hạn thông lượng đường ống. Việc áp dụng QUIC và SWQoS đã giảm thiểu các lỗi do tắc nghẽn kể từ năm 2022.

TPS thực tế của Solana là bao nhiêu?

TPS lý thuyết của Solana là khoảng 65.000, đại diện cho mức tối đa của đường ống trong điều kiện lý tưởng theo tài liệu kỹ thuật của Solana. TPS thực tế không bao gồm phiếu bầu (non-vote) thường dao động từ 2.000 đến 4.000, tùy thuộc vào tải mạng, thành phần loại giao dịch và hiệu suất của trình xác thực. Solana tính các giao dịch bỏ phiếu của trình xác thực tách biệt với các giao dịch do người dùng tạo; tổng số bao gồm cả phiếu bầu thì cao hơn nhưng ít có ý nghĩa hơn như một chỉ số hiệu suất đối với người dùng.

Solana nhanh hơn Ethereum như thế nào?

Đường ống dẫn TPU song song bốn giai đoạn của Solana xử lý đồng thời nhiều lô giao dịch, trong khi EVM của Ethereum xử lý các giao dịch tuần tự trên một luồng duy nhất. Kết quả là: thời gian slot của Solana xấp xỉ 400 mili giây so với thời gian tạo khối khoảng 12 giây của Ethereum, và TPS lớp 1 của Solana xấp xỉ 2.000 đến 4.000 so với mức khoảng 15 đến 30 của Ethereum. Cả hai kiến trúc đều đại diện cho những lựa chọn thiết kế có chủ đích với các sự đánh đổi khác nhau về Bộ ba bất khả thi của Blockchain.

Điều gì xảy ra khi đường ống Solana bị tắc nghẽn?

Khi khối lượng giao dịch vượt quá khả năng xử lý của giai đoạn Ngân hàng (Banking stage), Solana sẽ loại bỏ các giao dịch thay vì xếp hàng chúng, vì thiết kế Gulf Stream không có Mempool không duy trì bộ đệm cố định. Các giao dịch bị ảnh hưởng sẽ trả về lỗi "giao dịch hết hạn" và phải được gửi lại. Khi tắc nghẽn nghiêm trọng, việc xử lý giao dịch bỏ phiếu (vote transaction) có thể bị chậm lại, khiến các trình xác thực mất đồng thuận. QUIC và SWQoS giúp giảm thiểu tác động của tắc nghẽn do spam, mặc dù giới hạn công suất cơ bản vẫn là một sự đánh đổi về kiến trúc đã được biết đến.

Khám phá SOL trên Bybit

Sử dụng trang giá Solana để xem xét dữ liệu thị trường SOL hiện tại hoặc truy cập thị trường Giao ngay SOL/USDT nếu Giao dịch Giao ngay phù hợp với mục tiêu của bạn. Hoạt động giao dịch trên Bybit không giống với việc gửi một giao dịch Trên chuỗi Solana; phí mạng vẫn có thể áp dụng khi nạp hoặc rút SOL trên mạng lưới Solana.

Các nhà giao dịch phái sinh có kinh nghiệm cũng có thể xem xét thị trường Hợp đồng Vĩnh viễn SOLUSDT.. Phái sinh đi kèm với rủi ro bổ sung và không cung cấp quyền sở hữu SOL giao ngay.

Hệ thống đường ống giao dịch Solana và Luận điểm đầu tư SOL

Hệ thống đường ống giao dịch (transaction pipelining) của Solana là một sự đổi mới kiến trúc thực sự, không phải là một tuyên bố tiếp thị. Đường ống TPU bốn giai đoạn đại diện cho một cách tiếp cận kỹ thuật nhất quán đối với thông lượng Lớp 1. Proof of History cung cấp đồng hồ mật mã cho phép đường ống tiến triển mà không bị trễ do đồng thuận mạng. Gulf Stream tải trước đầu vào của đường ống. Turbine phân phối đầu ra của đường ống. Sealevel mang cùng một nguyên tắc song song đó vào việc thực thi Hợp đồng Thông minh.

Đối với các nhà đầu tư đang nắm giữ hoặc đánh giá Solana (SOL), hiểu về hệ thống đường ống có nghĩa là hiểu về nền tảng kỹ thuật tạo nên sự khác biệt về hiệu suất của Solana. Lợi thế về tốc độ của kiến trúc này mang tính cấu trúc chứ không phải ngẫu nhiên. Nó bắt nguồn từ những lựa chọn kỹ thuật cụ thể về cách áp dụng các nguyên tắc xử lý song song ở mọi lớp của chu kỳ giao dịch.

Những lựa chọn kỹ thuật đó đi kèm với những sự đánh đổi thực sự. Các sự kiện tắc nghẽn vào năm 2021 và 2022 đã chứng minh rằng thiết kế không có Mempool và trần thông lượng của giai đoạn Ngân hàng là những hạn chế thực tế trong điều kiện tải cực lớn hoặc bị tấn công. Các yêu cầu phần cứng cao đối với trình xác thực tạo ra một tập hợp các trình xác thực tập trung hơn so với Ethereum, đại diện cho một vị thế có chủ đích trên trục khả năng mở rộng - phi tập trung của Bộ ba bất khả thi của Blockchain. Sự tiến hóa kiến trúc liên tục của Solana, bao gồm việc áp dụng QUIC, triển khai SWQoS và máy khách Firedancer đang được phát triển bởi Jump Crypto, phản ánh một giao thức đang tích cực làm việc để nâng cao các giới hạn đó. Đây là những lộ trình phát triển, không phải là những vấn đề đã được giải quyết hoàn toàn.

Thông lượng đường ống của Solana đã biến nó thành một Nền tảng có ý nghĩa cho các ứng dụng DeFi yêu cầu tính xác thực giao dịch dưới một giây. Ethereum vẫn là một lựa chọn kiến trúc hợp lệ với các ưu tiên khác nhau: tính phi tập trung rộng hơn, hệ sinh thái Lớp 2 trưởng thành và cơ sở nhà phát triển lớn hơn. Cả hai mạng lưới đều chiếm giữ những vị trí riêng biệt trong số các blockchain thực tế.

Tuyên bố miễn trừ trách nhiệm: Bài viết này chỉ dành cho mục đích giáo dục và không cấu thành lời khuyên đầu tư, lời khuyên tài chính, lời khuyên giao dịch hoặc bất kỳ hình thức tư vấn nào khác. Solana (SOL) là một loại tiền điện tử. Tiền điện tử là tài sản có tính biến động cao và tiềm ẩn rủi ro thua lỗ đáng kể. Luôn thực hiện nghiên cứu của riêng bạn và tham khảo ý kiến của cố vấn tài chính có chuyên môn trước khi đưa ra quyết định đầu tư.

Bài đọc liên quan từ nhóm chủ đề này:

• Solana vs. Ethereum: So Sánh Toàn Diện Kiến Trúc: so sánh toàn diện kiến trúc Solana vs. Ethereum