Giới thiệu

“Chúng tôi biết nhỏ hơn, nhanh hơn, rẻ hơn tốt hơn bất kỳ ai khác trên thế giới, và bây giờ chúng tôi đang áp dụng những khái niệm đó vào blockchain.” — Greg Fitzgerald, đồng sáng lập viên Solana

Solana là một blockchain hiệu suất cao, thấp độ trễ nổi tiếng với tốc độ, hiệu suất và sự tập trung vào trải nghiệm người dùng. Kiến trúc tích hợp duy nhất của nó cho phép hàng nghìn giao dịch mỗi giây trên một mạng phân cấp toàn cầu. Với thời gian khối là 400 mili giây và phí giao dịch chỉ là một phần của một xu, nó đáp ứng cả về tốc độ lẫn hiệu quả chi phí. Báo cáo này sẽ đi sâu vào các chi tiết của thiết kế và hoạt động của Solana, khám phá các cơ chế chính và cấu trúc mạng mà đóng góp vào khả năng của nó.

Solana đưa ra một cách tiếp cận tích hợp cho việc phát triển blockchain, tận dụng các thập kỷ kinh nghiệm của đội ngũ sáng lập trong việc xây dựng hệ thống phân phối. Một trong những nguyên tắc cốt lõi của Solana là phần mềm không bao giờ cản trở phần cứng. Điều này có nghĩa là phần mềm tận dụng mọi phần cứng mà nó chạy trên một cách tối đa và mở rộng theo nó. Với hệ sinh thái thống nhất, tất cả các ứng dụng được xây dựng trên nền tảng này đều kế thừa tính tương hợp, cho phép chúng tương tác và xây dựng lên nhau một cách liền mạch. Kiến trúc này cũng đảm bảo một trải nghiệm người dùng trực quan và dễ hiểu mà không cần cầu nối, các ID chuỗi riêng biệt, hoặc sự phân mảng thanh khoản.

Solana đang phát triển nhanh chóng, với những tiến triển gần đây bao gồm SVM rollups vàNén ZKnhư những giải pháp tăng cường quan trọng. Trong khi những dự án này có thể một ngày nào đó định hình cách chúng ta nhìn nhận về Solana trong tương lai, thì hiện tại chúng đều đang ở giai đoạn phát triển hoặc áp dụng rất sớm và sẽ không được bao gồm trong báo cáo này.

Vòng Đời Giao Dịch

Góc nhìn chính của chúng tôi để hiểu về Solana trong báo cáo này sẽ là vòng đời của một giao dịch điển hình. Để xây dựng một mô hình cơ bản để hiểu về các giao dịch trên Solana, chúng ta có thể phác thảo quá trình như sau:

• Người dùng khởi chạy giao dịch, tất cả đều được gửi đến nhà sản xuất khối dẫn đầu hiện tại (được gọi là người đứng đầu). Người đứng đầu tổng hợp những giao dịch này thành một khối, thực thi chúng và cập nhật trạng thái cục bộ của họ.
• Khối giao dịch này sau đó được truyền ra khắp mạng để các validator khác thực thi và xác nhận.

Các phần tiếp theo của báo cáo này sẽ mở rộng mô hình này và đi sâu vào quá trình này chi tiết hơn rất nhiều, bắt đầu bằng các người tham gia chính – người dùng.

Nhớ

Các thay đổi đáng kể đối với giao thức cốt lõi Solana sẽ đi qua một quy trình chính thức, minh bạchquy trìnhviệc nộp một Tài liệu Cải tiến Solana (SIMD) mà các thành viên cộng đồng và lõi kỹ thuật sẽ đánh giá công khai. SIMDs sau đó được bỏ phiếu bởi mạng lưới.

Sáu giai đoạn

Chúng tôi sẽ tham khảo hình ảnh sáu giai đoạn được hiển thị ở trên trong suốt báo cáo này, vì nó cung cấp cho chúng tôi một khung nhìn nhất quán để hiểu về mối quan hệ giữa các yếu tố cốt lõi của Solana.

Các chương trước được sắp xếp theo sáu giai đoạn này. Những chương cuối cùng - Gossip, Archive, Economics và Jito - buộc chặt mọi sự rối. Quan trọng là lưu ý rằng một số chương sẽ bao quát nhiều giai đoạn, và một số giai đoạn sẽ xuất hiện trong nhiều chương.

Sự chồng chéo này là không thể tránh khỏi vì khung công việc sáu bước có những hạn chế của nó. Trong thực tế, Solana là một hệ thống phân tán phức tạp với nhiều yếu tố phụ thuộc lẫn nhau.

Người dùng

“Solana có tiềm năng trở thành Apple của tiền điện tử” — Raj Gokal, cộng sự sáng lập Solana

Hành trình của người dùng thường bắt đầu bằng việc thiết lập và tài trợ cho một ứng dụng ví tiền. Có nhiều ứng dụng ví tiền phổ biến cho Solana, có thể là ứng dụng di động gốc hoặc tiện ích mở rộng trình duyệt.

Ví tiền điện tử tạo ra cặp khóa ngẫu nhiên mật mã của người dùng, bao gồm khóa công khai và khóa riêng. Khóa công khai hoạt động như làm định danh duy nhất cho tài khoản của họ và được biết đến bởi tất cả các thành viên trong mạng lưới. Tài khoản của người dùng trên Solana có thể được coi là một cấu trúc dữ liệu chứa thông tin và trạng thái liên quan đến tương tác của họ với chuỗi khối Solana. Theo cách này, khóa công khai tương tự như một tên tệp: giống như một tên tệp định danh duy nhất một tệp trong hệ thống tệp, một khóa công khai Solana định danh duy nhất một tài khoản trên chuỗi khối Solana. Khóa công khai trên Solana được biểu diễn dưới dạng chuỗi mã hóa Base58 32 byte.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Một khóa riêng tư - cũng được biết đến với tên gọi là khóa bí mật - có thể được coi như mật khẩu hoặc chìa khóa truy cập cấp quyền để truy cập và sửa đổi tài khoản. Ký bằng khóa riêng tư là cách mà các chuỗi khối xử lý quyền ủy quyền. Việc biết về khóa riêng tư mang lại quyền lực tuyệt đối đối với tài khoản. Khóa riêng tư Solana cũng có độ dài 32 byte. Cặp khóa là sự kết hợp 64 byte của khóa công cộng (nửa đầu) và khóa riêng tư (nửa sau). Ví dụ:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Các khóa riêng tư cũng có thể được tạo ra từ cụm từ gieo mầm mnemonics, thường có độ dài 12 hoặc 24 từ. Định dạng này thường được sử dụng trong ví để dễ dàng sao lưu và khôi phục. Có thể tạo ra nhiều khóa một cách xác định từ một cụm từ gieo mầm duy nhất.

Solana sử dụngEd25519, một thuật toán chữ ký số trên đường cong elliptic được sử dụng phổ biến, cho nhu cầu mật mã khóa công khai của mình. Ed25519 được ưa chuộng vì kích thước khóa nhỏ, kích thước chữ ký nhỏ, tính toán nhanh và miễn dịch với nhiều cuộc tấn công phổ biến. Mỗi địa chỉ ví Solana đại diện cho một điểm trên đường cong elliptic Ed25519.

Người dùng ký giao dịch bằng khóa riêng của họ. Chữ ký này được bao gồm trong dữ liệu giao dịch và có thể được xác minh bởi các bên tham gia khác bằng cách sử dụng khóa công khai của người gửi. Quá trình này đảm bảo giao dịch không bị can thiệp và được ủy quyền bởi chủ sở hữu của khóa riêng tương ứng. Chữ ký cũng đóng vai trò như một định danh duy nhất cho giao dịch.

Giao dịch Solana

Gửi giao dịch là cách duy nhất để biến đổi trạng thái trên Solana. Bất kỳ hoạt động ghi nào cũng được thực hiện thông qua một giao dịch, và các giao dịch là nguyên tử—hoặc mọi thứ mà giao dịch cố gắng thực hiện xảy ra hoặc giao dịch thất bại. Một giao dịch, chính thức được biết đến là một “tin nhắn giao dịch,” bao gồm bốn phần: một tiêu đề, một danh sách các địa chỉ tài khoản, một blockhash gần đây và các hướng dẫn.

• Đầu trang: Phần đầu trang chứa các tham chiếu đến danh sách địa chỉ tài khoản, cho biết tài khoản nào phải ký giao dịch.
• Địa chỉ tài khoản: Danh sách này bao gồm tất cả các tài khoản sẽ được đọc từ hoặc ghi vào trong quá trình giao dịch. Xây dựng một danh sách như vậy cho mỗi giao dịch là một yêu cầu độc đáo của Solana và có thể là thách thức đối với các nhà phát triển. Tuy nhiên, việc biết trước các phần của trạng thái mà một giao dịch sẽ tương tác với cho phép tối ưu hóa mà không thể thực hiện trên nhiều blockchain khác.
• Blockhash gần đây: Được sử dụng để ngăn chặn giao dịch trùng lặp và lạc hậu. Một blockhash gần đây hết hạn sau 150 block (khoảng 1 phút). Theo mặc định, RPC cố gắng chuyển tiếp giao dịch mỗi 2 giây cho đến khi giao dịch được hoàn tất hoặc blockhash gần đây hết hạn, lúc đó giao dịch sẽ bị loại bỏ.
• Hướng dẫn: Đây là phần quan trọng của giao dịch. Mỗi hướng dẫn đại diện cho một hoạt động cụ thể (ví dụ: chuyển, phát hành, đốt, tạo tài khoản, đóng tài khoản). Mỗi hướng dẫn chỉ định chương trình cần thực thi, các tài khoản cần thiết, và dữ liệu cần thiết cho việc thực thi hướng dẫn.

Số lượng hướng dẫn trong một giao dịch được giới hạn trước hết bởi kích thước của nó, có thể lên đến 1.232 byte. Còn giới hạn về số tài khoản có thể được tham chiếu. Cuối cùng, có giới hạn về độ phức tạp của một giao dịch được đo bằng đơn vị tính toán (CUs). CUs định lượng các tài nguyên tính toán tiêu tốn trong quá trình xử lý giao dịch.

Nhớ

Đơn vị nhỏ nhất của SOL được biết đến là một “lamport,” tương đương với một tỷ phần của SOL, tương tự như một satoshi trong Bitcoin. Lamport được đặt theo tên củaLeslie Lamport, một nhà khoa học máy tính và toán học người nghiên cứu đã xác lập nhiều nền tảng lý thuyết của các hệ thống phân phối hiện đại.

Chi phí trong SOL để thực hiện giao dịch được chia thành 2 phần - một phí cơ bản và một phí ưu tiên. Phí cơ bản là 5000 lamports cố định cho mỗi chi phí chữ ký bất kể độ phức tạp của giao dịch - thường có 1 chữ ký cho mỗi giao dịch.

Các khoản phí ưu tiên về mặt kỹ thuật là tùy chọn, nhưng trong những giai đoạn cần nhiều không gian khối trở nên cần thiết. Những khoản phí này được định giá trong micro-lamports (phần triệu của lamport) cho mỗi đơn vị tính toán. Mục đích của chúng là hoạt động như một tín hiệu giá, khiến giao dịch trở nên hấp dẫn kinh tế hơn đối với các nút xác thực để bao gồm vào các khối của họ.

tổng phí = phí ưu tiên + phí cơ bản

phí ưu tiên = giá đơn vị tính toán (micro-lamports) x giới hạn đơn vị tính toán

Hiện nay, 50% phí liên quan đến giao dịch được đốt cháy, gỡ bỏ vĩnh viễn SOL này khỏi lưu thông với 50% còn lại được chuyển đến người sản xuất khối. Một thay đổi mới (SIMD 96) sắp được giới thiệu cho phép 100% phí ưu tiên được chuyển đến người sản xuất khối. Phí cơ sở vẫn không thay đổi.

‍

Gửi giao dịch

Một người dùng kết nối ví của họ với ứng dụng, cho phép ứng dụng đọc khóa công khai của người dùng. Khóa riêng tư vẫn được mã hóa và an toàn trong môi trường riêng biệt so với ứng dụng.

Ứng dụng xây dựng các tham số tin nhắn giao dịch dựa trên tương tác của người dùng. Ví dụ, nếu người dùng muốn hoán đổi hai mã thông báo, họ sẽ chỉ định số lượng mã thông báo muốn mua, các mã thông báo tương ứng để bán và mức lệch giao dịch chấp nhận được.

Khi tin nhắn giao dịch đã sẵn sàng, nó được gửi đến ví để ký bằng khóa riêng của người dùng. Tại điểm này, người dùng sẽ nhìn thấy một cửa sổ pop-up để xác nhận sự sẵn lòng của họ để thực hiện giao dịch. Cửa sổ pop-up này có thể bao gồm một mô phỏng kết quả của giao dịch. Khi đã được ký, tin nhắn giao dịch và chữ ký sẽ được trả về ứng dụng, sau đó ứng dụng có thể chuyển tiếp giao dịch đến một nhà cung cấp RPC theo sự lựa chọn của họ, hoặc sử dụng nhà cung cấp của ví.

Nhà cung cấp RPC (Remote Procedure Call) hoạt động như trung gian giữa các ứng dụng và các nhà xác nhận xây dựng các khối. Đó là một dịch vụ quan trọng cho phép các ứng dụngnộphoặc mô phỏng giao dịch được ký và lấy dữ liệu trên chuỗi hiệu quả. Ứng dụng muốn tương tác với mạng thông qua điểm cuối JSON-RPC hoặc WebSocket ( tài liệu).

Nhớ

Thuật ngữ "giao dịch thất bại" trên Solana là gây hiểu lầm và gây khó hiểu. Những giao dịch này phải trả phí và được thực thi thành công bởi runtime đúng như người ký định. Chúng "thất bại" do logic của giao dịch yêu cầu phải như vậy. +80% giao dịch "thất bại" đến từ mã lỗi 0x1771, mã cho việc vượt quá số lượng slippage.dữ liệu). Đáng chú ý, 95% giao dịch này được gửi bởi chỉ có 0.1% số địa chỉ Solana hoạt động, chủ yếu là các bot tự động cố gắng tận dụng cơ hội giao dịch chênh lệch giá theo thời gian.

Dòng vịnh

“Đích thực mục tiêu của Solana là thực hiện các giao dịch nhanh chóng như tin tức lan truyền trên toàn thế giới - vận tốc của ánh sáng qua sợi quang. Đối thủ mà chúng tôi đang cạnh tranh là NASDAQ và Sở giao dịch New York.” - Anatoly Yakovenko, đồng sáng lập Solana

RPCs (Remote Procedure Calls) đề cập đến các nút RPC. Những nút này có thể được coi là cổng để tương tác và đọc dữ liệu từ mạng. Chúng chạy cùng phần mềm như các máy chủ xác thực đầy đủ nhưng với cài đặt khác nhau, cho phép họ mô phỏng giao dịch một cách chính xác và duy trì một cái nhìn cập nhật về trạng thái hiện tại. Đến thời điểm viết bài này, có hơn 4.000 nút RPC trên mạng Solana.

Không giống như các nút xác thực đầy đủ, các nút RPC không giữ bất kỳ cổ phần nào trong mạng lưới. Thiếu cổ phần, họ không thể bỏ phiếu hoặc xây dựng khối. Thiết lập này khác biệt so với hầu hết các blockchain khác, nơi mà các nút xác thực và RPC thường là cùng một. Vì các nút RPC không nhận được phần thưởng staking, kinh tế của việc vận hành các nút RPC khác biệt so với các nút xác thực với nhiều nút hoạt động như một dịch vụ trả tiền cho các nhà phát triển chạy ứng dụng Solana.

Solana nổi bật vì nó được thiết kế từ đầu để hoạt động mà không cần một mempool. Không giống như các chuỗi khối truyền thống sử dụng giao thức gossip để lan truyền giao dịch ngẫu nhiên và rộng rãi trên mạng lưới, Solana chuyển tiếp tất cả giao dịch đến một validator dẫn đầu được xác định trước, được gọi là leader, cho mỗi slot.

Callout

Solana hoạt động trên bốn cụm: Localnet, Testnet, Devnet và Mainnet-Beta. Khi mọi người đề cập đến Solana hoặc mạng Solana, họ hầu như luôn đề cập đến Mainnet-Beta. Mainnet-Beta là cụm duy nhất nơi các token có giá trị thực sự, trong khi các cụm khác chỉ được sử dụng cho mục đích kiểm thử.

Khi RPC nhận được thông báo giao dịch được đưa vào khối, nó phải được chuyển tiếp đến đơn vị chỉ huy. Một lịch trình lãnh đạo được tạo ra trước mỗi kỷ nguyên (khoảng hai ngày một lần). Kỷ nguyên sắp tới được chia thành các khe, mỗi vị trí cố định ở 400 mili giây và một đơn vị chỉ huy được chọn cho mỗi khe. Những người xác thực có cổ phần cao hơn sẽ được chọn thường xuyên hơn để trở thành người dẫn đầu trong mỗi kỷ nguyên. Trong mỗi khe, tin nhắn giao dịch được chuyển tiếp đến người lãnh đạo, người có cơ hội tạo ra một khối. Khi đến lượt trình xác thực, họ chuyển sang "chế độ lãnh đạo", bắt đầu chủ động xử lý các giao dịch và phát các khối đến phần còn lại của mạng.

Chất lượng Dịch vụ Cân bằng Cổ phần Đặt cọc - SWQoS

Vào đầu năm 2024, Solana giới thiệu một cơ chế mới nhằm ngăn chặn spam và tăng cường khả năng chống lại Sybil, được biết đến với tên gọi “Chất lượng Dịch vụ Dựa trên Stake” (SWQoS). Hệ thống này cho phép các nhà lãnh đạo ưu tiên các thông điệp giao dịch được truyền qua các máy chủ xác thực khác. Ở đây, các máy chủ xác thực với Stake cao hơn được cấp một khả năng truyền các gói tin thông điệp giao dịch tới nhà lãnh đạo theo tỷ lệ tương ứng. Cách tiếp cận này hiệu quả làm giảm tác động của các cuộc tấn công Sybil từ các nút không có Stake trên toàn mạng.

Dưới mô hình này, các bộ xác minh cũng có thể tham gia vào các thỏa thuận để cho thuê khả năng trọng số cổ phần của họ cho các nút RPC. Đổi lại, các nút RPC sẽ có băng thông tăng cường, giúp họ đạt được tỷ lệ bao gồm giao dịch lớn hơn trong các khối. Đáng chú ý, 80% của khả năng của một người dẫn đầu (2,000 kết nối) được dành riêng cho SWQoS. 20% còn lại (500 kết nối) được phân bổ cho các tin nhắn giao dịch từ các nút không đặt cược. Chiến lược phân phối này tương tự như làn đường ưu tiên trên các đường cao tốc, nơi các tài xế trả tiền qua các trạm thu phí để tránh kẹt xe.

SWQoS đã ảnh hưởng đến hệ sinh thái Solana bằng cách nâng cao yêu cầu để chuyển tiếp giao dịch đến người dẫn và giảm hiệu quả của các cuộc tấn công spam. Sự thay đổi đã tạo động lực cho các ứng dụng có lưu lượng cao để tích hợp theo chiều dọc hoạt động của họ. Bằng cách vận hành nút kiểm chứng của riêng họ, hoặc thông qua việc truy cập kết nối đã đặt cược, các ứng dụng có thể đảm bảo quyền truy cập đặc quyền đến người dẫn, do đó tăng cường khả năng xử lý giao dịch của họ.

Một Ghi Chú Ngắn

Vào cuối năm 2022, Solana đã áp dụngGiao thức mạng QUICđể quản lý việc truyền tin nhắn giao dịch tới người điều hành. Việc chuyển đổi này được thúc đẩy bởi sự cố mạng do bot spam khiến cho việc tạo ra NFT trên chuỗi bị gián đoạn. QUIC tạo điều kiện cho việc truyền thông nhanh chóng, không đồng bộ.

Ban đầu được phát triển bởiGoogleVào năm 2012, QUIC cố gắng cung cấp sự kết hợp tốt nhất từ cả hai thế giới. Nó tạo điều kiện cho việc giao tiếp nhanh chóng, không đồng bộ tương tự như UDP, nhưng với các phiên an toàn và chiến lược kiểm soát luồng tiên tiến của TCP. Điều này cho phép giới hạn được đặt cho các nguồn lưu lượng cá nhân để mạng có thể tập trung xử lý các giao dịch chân thực. Nó cũng có khái niệm về các luồng riêng biệt; vì vậy nếu một giao dịch bị thả, nó không cần phải chặn các giao dịch còn lại. Nói một cách ngắn gọn, QUIC có thể được coi là cố gắng kết hợp những đặc điểm tốt nhất của TCP và UDP.

Callout box

Trọng số cược là một nguyên tắc tái diễn được tìm thấy trong toàn bộ các hệ thống của Solana, bao gồm phần thưởng bỏ phiếu, cây turbine, lịch trình người lãnh đạo, Dòng Gulf, và mạng lăng nhăng. Các Validator có cược lớn hơn được ưu đãi cao hơn và có vai trò ưu tiên trong mạng lưới.

Xây dựng khối

“Chúng tôi coi SVM (Solana Virtual Machine) là tốt nhất về công nghệ máy ảo hiện tại.” — Andre Cronje, Fantom Foundation

Nhiều mạng blockchain xây dựng toàn bộ các khối trước khi phát sóng chúng, được biết đến là xây dựng khối rời rạc. Solana, ngược lại, sử dụng cách xây dựng khối liên tục giúp tổng hợp và truyền khối động một cách linh hoạt khi chúng được tạo ra trong một khoảng thời gian cụ thể, giảm đáng kể độ trễ.

Mỗi khe thời gian kéo dài 400 mili giây, và mỗi nhà lãnh đạo được giao bốn khe thời gian liên tiếp (1,6 giây) trước khi chuyển giao cho nhà lãnh đạo tiếp theo. Để một khối được chấp nhận, tất cả giao dịch bên trong nó phải hợp lệ và có thể tái tạo bởi các nút khác.

Trước khi đảm nhận vai trò lãnh đạo, một validator tạm dừng chuyển tiếp giao dịch để chuẩn bị cho công việc sắp tới của mình. Trong khoảng thời gian này, lưu lượng traffic đến tăng cao, đạt hơn một gigabyte mỗi giây khi toàn bộ mạng chuyển hướng gói tin đến người lãnh đạo mới.

Khi nhận được, các tin nhắn giao dịch sẽ nhập vào Đơn vị Xử lý Giao dịch (TPU), logic cốt lõi của máy xác minh chịu trách nhiệm sản xuất khối. Ở đây, chuỗi xử lý giao dịch bắt đầu với Giai đoạn Truy xuất, nơi giao dịch được nhận thông qua QUIC. Tiếp theo, các giao dịch tiến triển đến Giai đoạn SigVerify, trải qua các kiểm tra xác minh nghiêm ngặt. Ở đây, máy xác minh xác nhận tính hợp lệ của chữ ký, kiểm tra số lượng chữ ký đúng và loại bỏ các giao dịch trùng lặp.

Banking Stage

Giai đoạn ngân hàng có thể được mô tả như là giai đoạn xây dựng khối. Đây là giai đoạn quan trọng nhất của TPU, được đặt tên từ “ngân hàng”. Một ngân hàng chỉ là trạng thái tại một khối cụ thể. Đối với mỗi khối, Solana có một ngân hàng được sử dụng để truy cập trạng thái tại khối đó. Khi một khối trở thành cuối cùng sau khi đủ số lượng người xác thực bỏ phiếu cho nó, họ sẽ đẩy các cập nhật tài khoản từ ngân hàng xuống đĩa, làm cho chúng trở nên vĩnh viễn. Trạng thái cuối cùng của chuỗi là kết quả của tất cả các giao dịch được xác nhận. Trạng thái này luôn có thể được tái tạo từ lịch sử blockchain theo cách xác định.

Các giao dịch được xử lý song song và được đóng gói thành các "mục" sổ cái, là các lô gồm 64 giao dịch không xung đột. Xử lý giao dịch song song trên Solana được thực hiện dễ dàng vì mỗi giao dịch phải bao gồm một danh sách đầy đủ tất cả các tài khoản mà nó sẽ đọc và ghi vào. Lựa chọn thiết kế này đặt gánh nặng cho các nhà phát triển nhưng cho phép trình xác thực tránh các điều kiện đua bằng cách dễ dàng chọn các giao dịch không xung đột để thực hiện trong mỗi mục. Giao dịch xung đột nếu cả hai đều cố gắng ghi vào cùng một tài khoản (hai lần ghi) hoặc nếu một người cố gắng đọc và người kia ghi vào cùng một tài khoản (đọc + ghi). Do đó, các giao dịch xung đột đi vào các mục khác nhau và được thực hiện tuần tự, trong khi các giao dịch không xung đột được thực hiện song song.

Có sáu luồng xử lý giao dịch song song, với bốn luồng dành riêng cho giao dịch bình thường và hai luồng độc quyền xử lý giao dịch bỏ phiếu mà là phần không thể thiếu của cơ chế đồng thuận của Solana. Tất cả quá trình xử lý song song được thực hiện thông qua nhiều lõi CPU; các máy chủ xác thực không cần yêu cầu GPUtài liệu).

Khi các giao dịch đã được nhóm thành các bản ghi, chúng sẵn sàng được thực thi bởi Máy Ảo Solana (SVM). Các tài khoản cần thiết cho giao dịch đã bị khóa; kiểm tra được thực hiện để xác nhận giao dịch là gần đây nhưng chưa được xử lý. Các tài khoản được tải và logic giao dịch được thực thi, cập nhật trạng thái tài khoản. Một băm của bản ghi sẽ được gửi đến dịch vụ Proof of History để được ghi lại (thêm thông tin về điều này trong phần tiếp theo). Nếu quá trình ghi âm thành công, tất cả các thay đổi sẽ được cam kết vào ngân hàng và khóa trên mỗi tài khoản đặt trong bước đầu tiên sẽ được mở khóa. Thực thi được thực hiện bởi SVM, một máy ảo được xây dựng bằng bản sao Solana của rBPF, một thư viện để làm việc với việc biên dịch JIT, và máy ảo cho các chương trình eBPF. Lưu ý Solana không bắt buộc các máy chủ xác thực chọn cách sắp xếp giao dịch trong một khối. Sự linh hoạt này là một điểm quan trọng mà chúng tôi sẽ trở lại sau trong phần Kinh tế + Jito của báo cáo này.

Nhớ

Thuật ngữ SVM có thể gây hiểu lầm, vì nó có thể ám chỉ đến cả “Máy Ảo Solana” hoặc “Máy Ảo Mực Nước.” Cả hai thuật ngữ này đề cập đến cùng một khái niệm, với Sealevel là tên của môi trường chạy của Solana. Thuật ngữ SVM vẫn được sử dụng một cách lỏng lẻo mặc dù đã có những nỗ lực gần đây để xác định rõ ràng.xác định ranh giới của nó.

Khách hàng

Solana là một mạng lưới bao gồm hàng nghìn nút hoạt động độc lập cùng hợp tác để duy trì một sổ cái thống nhất duy nhất. Mỗi nút bao gồm một máy chạy hiệu suất cao chạy cùng một phần mềm mã nguồn mở được biết đến là một “khách hàng”.

Solana được ra mắt với một phần mềm máy chủ xác thực duy nhất - ban đầu là bản khách hàng của Solana Labs, hiện nay được biết đến với tênKhách hàng Agave— viết bằng Rust. Việc mở rộng sự đa dạng của khách hàng đã là ưu tiên từ lâu và sẽ thực sự trở thành sự thật với việc ra mắt củaKhách hàng FiredancerFiredancer là một bản viết lại hoàn toàn từ đầu của client gốc bằng ngôn ngữ lập trình C. Được xây dựng bởi một nhóm kinh nghiệm từ công ty giao dịch tần suất cao Jump, nó hứa hẹn sẽ là client xác thực hiệu suất cao nhất trên mọi blockchain.

Chứng minh về Lịch sử

“Tôi uống hai cốc cà phê và một lon bia, và tôi thức đến 4:00 sáng. Tôi có khoảnh khắc eureka rằng bài toán tương tự như chứng minh về việc sử dụng hàm băm SHA-256 chống lại preimage... Tôi biết rằng tôi có mũi tên của thời gian này.” — Anatoly Yakovenko, đồng sáng lập Solana

Chứng minh lịch sử (PoH) là một loại nước số bí mật của Solana, hoạt động như một chiếc đồng hồ đặc biệt trong mỗi máy xác minh để tạo điều đồng bộ trên toàn mạng. PoH tạo ra một nguồn tin cậy về thứ tự các sự kiện và quá trình thời gian. Quan trọng nhất, nó đảm bảo tuân thủ theo lịch trình của nhà lãnh đạo. Mặc dù có tên gọi tương tự, nhưng Chứng minh lịch sử không phải là một thuật toán đồng thuận như Chứng minh công việc.

Chi phí giao tiếp giữa các nút thường tăng khi mạng mở rộng, và việc phối hợp trở nên ngày càng phức tạp hơn. Solana giảm thiểu điều này bằng cách thay thế giao tiếp từ nút này sang nút khác bằng một tính toán địa phương PoH. Điều này có nghĩa là các người xác minh có thể cam kết vào một khối chỉ với một vòng bỏ phiếu duy nhất. Thời gian đánh dấu thời gian tin cậy trong các thông điệp đảm bảo rằng các người xác minh không thể vượt qua nhau và bắt đầu khối của họ một cách sớm hơn.

Cơ sở của PoH là các đặc tính độc đáo của thuật toán băm, cụ thể làSHA256:

• Xác định: Cùng một đầu vào sẽ luôn tạo ra cùng một băm.
• Kích thước cố định: Bất kể kích thước đầu vào là bao nhiêu, băm đầu ra luôn luôn là 256 bit.
• Hiệu quả: Việc tính toán băm cho bất kỳ đầu vào nào cũng nhanh chóng.
• Kháng cự trước hình ảnh: Tìm ra đầu vào ban đầu từ đầu ra băm là không khả thi tính toán.
• Tác động tuyết lở: Một thay đổi nhỏ trong đầu vào (thậm chí chỉ một bit duy nhất) dẫn đến một băm khác biệt đáng kể, một đặc tính được biết đến là hiệu ứng tác động tuyết lở.
• Sự chống đụng: Việc tìm ra hai đầu vào khác nhau nhưng tạo ra cùng một đầu ra băm là không khả thi.

Trong mỗi máy chủ xác thực, dịch vụ "Chứng minh lịch sử" được cấp phát liên tục chạy thuật toán băm SHA256 tạo ra một chuỗi băm. Đầu vào của mỗi băm là đầu ra của băm trước đó. Chuỗi này hoạt động giống như một hàm trễ có thể xác minh, vì công việc băm phải được thực hiện theo trình tự và kết quả của băm trong tương lai không thể biết trước. Nếu dịch vụ PoH tạo ra một chuỗi gồm nghìn băm, chúng ta biết rằng đã trôi qua thời gian để tính toán mỗi băm theo trình tự - điều này có thể được coi là một "chứng minh công việc nhỏ." Tuy nhiên, các máy chủ xác thực khác có thể xác minh tính chính xác của nghìn băm này song song với tốc độ nhanh hơn nhiều so với tốc độ sản xuất vì đầu vào và đầu ra của mỗi băm đã được phổ biến trên mạng. Do đó, PoH là khó sản xuất nhưng dễ xác minh.

Khoảng hiệu suất tính toán SHA-256 trên các CPU khác nhau có phạm vi hẹp đáng ngạc nhiên, chỉ có những khác biệt nhỏ giữa những máy nhanh nhất. Một giới hạn trên thông thường đã được đạt, mặc dù đã có sự đầu tư đáng kể về thời gian và nỗ lực để tối ưu hàm này, chủ yếu do sự phụ thuộc của Bitcoin vào nó.

Trong một khe của người lãnh đạo, dịch vụ PoH sẽ nhận các bản ghi được xử lý mới từ giai đoạn ngân hàng. Hash PoH hiện tại cộng với một hash của tất cả các giao dịch trong bản ghi được kết hợp thành hash PoH tiếp theo. Điều này phục vụ như một dấu thời gian chèn bản ghi vào chuỗi hash, chứng minh chuỗi các giao dịch đã được xử lý. Quy trình này không chỉ xác nhận việc trôi qua của thời gian mà còn phục vụ như một bản ghi mật mã của các giao dịch.

Trong một khối duy nhất, có 800.000 băm. Luồng PoH cũng bao gồm các “tick,” đó là các mục nhập trống chỉ ra tính sống còn của người dẫn và sự trôi chảy của thời gian xấp xỉ một phần nhỏ của một giây. Mỗi tick xảy ra mỗi 6.25 mili giây, dẫn đến 64 tick trên mỗi khối và tổng thời gian của mỗi khối là 400 mili giây.

Các nhà xác thực tiếp tục chạy đồng hồ PoH ngay cả khi họ không phải là người đứng đầu vì nó đóng vai trò quan trọng trong quá trình đồng bộ hóa giữa các nút.

Nhớ

Lợi ích chính của PoH là đảm bảo lịch trình của người đứng đầu phải tuân thủ đúng, ngay cả khi một nhà sản xuất khối không trực tuyến - một trạng thái được biết đến là "bất chính". PoH ngăn chặn một người xác minh độc hại từ việc tạo ra các khối trước lượt của họ.

Mô hình Tài khoản

“Tách mã và trạng thái trong SVM là quyết định thiết kế tốt nhất. Phước lành cho các nhà phát triển hệ thống nhúng đã tận tâm đào sâu khái niệm này vào não tôi.” — Anatoly Yakovenko, đồng sáng lập Solana

Trong một validator Solana, trạng thái toàn cầu được duy trì trong cơ sở dữ liệu tài khoản được biết đến là AccountsDB. Cơ sở dữ liệu này chịu trách nhiệm lưu trữ tất cả các tài khoản, cả trong bộ nhớ và trên ổ đĩa. Cấu trúc dữ liệu chính trong chỉ mục tài khoản là một hashmap, khiến cho AccountsDB về cơ bản là một hệ thống lớncửa hàng key-valueỞ đây, key là địa chỉ tài khoản, và value là dữ liệu tài khoản.

Theo thời gian, số tài khoản Solana đã tăng vọt lên hàng trăm triệu. Số lượng lớn này một phần là do, như những người phát triển Solana thích nói, “Mọi thứ trên Solana đều là một tài khoản!

tài khoản Solana

Tài khoản là một container lưu trữ dữ liệu một cách liên tục, tương tự như một tập tin trên máy tính. Chúng có nhiều dạng khác nhau:

• Tài khoản người dùng: Những tài khoản này có một khóa riêng và thường được tạo ra bởi phần mềm ví cho người dùng.
• Tài khoản dữ liệu: Những tài khoản này lưu trữ thông tin trạng thái, chẳng hạn như số lượng của một token cụ thể mà người dùng đang nắm giữ.
• Tài khoản chương trình: Đây là những tài khoản lớn chứa bytecode có thể thực thi, tương đương với một tệp .exe trên Windows hoặc một tệp .app trên Mac.
• Tài khoản chương trình bản địa: Đây là các tài khoản chương trình đặc biệt đã được triển khai trước để thực hiện các chức năng cốt lõi khác nhau của mạng.Ví dụbao gồm Chương trình Bỏ phiếu và Trình tải BPF.

Tất cả các tài khoản đều có các trường sau:

Chương trình

Tài khoản chương trình Solana chỉ chứa logic có thể thực thi. Điều này có nghĩa là khi một chương trình được chạy, nó thay đổi trạng thái của các tài khoản khác nhưng chính nó vẫn không thay đổi. Sự tách biệt này giữa mã và trạng thái phân biệt Solana với các blockchain khác và hỗ trợ nhiều tối ưu hóa của nó. Nhà phát triển chủ yếu viết các chương trình này bằng Rust, một ngôn ngữ lập trình đa dụngbiếtvới sự tập trung mạnh mẽ vào an toàn và hiệu suất. Ngoài ra, có sẵn nhiều SDK trong TypeScript và Python để tạo điều kiện cho việc tạo ra giao diện trước ứng dụng và cho phép tương tác theo chương trình với mạng lưới.

Nhiều chức năng phổ biến được cung cấp sẵn trong các chương trình native. Ví dụ, Solana không yêu cầu nhà phát triển triển khai mã để tạo một token. Thay vào đó, các hướng dẫn được gửi đến một chương trình native đã triển khai trước sẽ thiết lập một tài khoản để lưu trữ dữ liệu siêu dữ liệu của token, hiệu quả tạo ra một token mới.

Thuê

Rent là một cơ chế được thiết kế để khuyến khích người dùng đóng tài khoản và giảm quá tải trạng thái. Để tạo một tài khoản mới, tài khoản phải giữ một số lượng SOL tối thiểu, được gọi là “số lượng miễn phí cho thuê”, Điều này có thể coi là chi phí lưu trữ phát sinh để duy trì tài khoản sống trong bộ nhớ của người xác minh. Nếu kích thước dữ liệu của tài khoản tăng, yêu cầu thuê số dư tối thiểu tăng tương ứng. Khi tài khoản không còn cần thiết nữa, nó có thể được đóng và số tiền thuê sẽ được trả lại cho chủ sở hữu tài khoản.

Ví dụ, nếu một người dùng giữ một stablecoin được định giá bằng đô la, trạng thái này được lưu trữ trong một tài khoản token. Hiện nay, số lượng miễn phí cho việc thuê một tài khoản token là 0,002 SOL. Nếu người dùng chuyển toàn bộ số dư stablecoin của họ cho một người bạn, tài khoản token có thể được đóng và người dùng sẽ nhận lại 0,002 SOL của họ. Các chương trình thường xử lý việc đóng tài khoản tự động cho người dùng. Có một số ứng dụng có sẵn để giúp người dùng dọn dẹp các tài khoản cũ, không sử dụng và lấy lại các số lượng nhỏ SOL được lưu trữ trong đó.

Sở hữu

Mặc dù việc đọc dữ liệu tài khoản được cho phép phổ biến, mô hình quyền sở hữu của Solana tăng cường bảo mật bằng cách hạn chế chính xác ai có thể sửa đổi (ghi) dữ liệu của tài khoản. Khái niệm này rất quan trọng để thực thi các quy tắc và quyền trên blockchain Solana. Mỗi tài khoản đều có một chương trình "chủ sở hữu". Chủ sở hữu tài khoản chịu trách nhiệm quản lý tài khoản đó, đảm bảo rằng chỉ các chương trình được ủy quyền mới có thể thay đổi dữ liệu của tài khoản. Một ngoại lệ đáng chú ý đối với quy tắc này là việc chuyển nhượng lamports (đơn vị nhỏ nhất của SOL) — việc tăng số dư lamports của tài khoản được cho phép phổ biến, bất kể quyền sở hữu.

Lưu trữ trạng thái

Chương trình Solana, là các tệp thực thi chỉ đọc, phải lưu trạng thái bằng cách sử dụng “Các Địa chỉ Phát sinh từ Chương trình” (PDAs). PDAs là loại tài khoản đặc biệt liên kết với và sở hữu bởi một chương trình thay vì một người dùng cụ thể. Trong khi địa chỉ người dùng Solana bình thường được phát sinh từ khóa công khai của một cặp khóa Ed25519, PDAs không có khóa riêng. Thay vào đó, khóa công khai của họ được phát sinh từ sự kết hợp của các tham số—thường là các từ khóa hoặc các địa chỉ tài khoản khác—cùng với ID chương trình sở hữu (địa chỉ).

Địa chỉ PDA tồn tại "nằm ngoài đường cong," có nghĩa là chúng không nằm trên đường cong Ed25519 như các địa chỉ bình thường. Chỉ có chương trình sở hữu PDA mới có thể tự động tạo ra chữ ký cho nó, đảm bảo rằng chỉ có chương trình đó mới có thể sửa đổi trạng thái của PDA.

Trên: Các tài khoản token Solana là các ví dụ cụ thể của Địa chỉ Phát sinh từ Chương trình (PDAs). Chúng được sử dụng để giữ token và tồn tại ngoài “đường cong.” Chương trình Tài khoản Token Liên kết (ATA) đảm bảo rằng mỗi ví chỉ có thể có một tài khoản token liên kết cho mỗi loại token, cung cấp một cách chuẩn để quản lý các tài khoản token.

Turbine

“Phần thú vị nhất về Solana không phải là việc song song hóa, SVM, hoặc các tweet của Toly. Đó là điều mà bạn có lẽ chưa từng nghe: Turbine.” — Mert Mumtaz, Helius

Trong giai đoạn ngân hàng, các giao dịch được tổ chức thành các bản ghi và được gửi đến luồng Proof of History để được ghi thời gian. Ngân hàng của khối được cập nhật và các bản ghi giờ đã sẵn sàng cho giai đoạn tiếp theo - Turbine.

Turbine là quá trình mà thông qua đó người lãnh đạo truyền bá khối của họ đến phần còn lại của mạng. Lấy cảm hứng từ BitTorrent, nó được thiết kế để nhanh chóng và hiệu quả, giảm thiểu chi phí giao tiếp và tối thiểu hóa lượng dữ liệu mà một nhà lãnh đạo cần phải gửi.

Turbine đạt được điều này bằng cách phân tích dữ liệu giao dịch thành “shreds” thông qua quá trình gọi là “shredding.” Shreds là các gói dữ liệu nhỏ, lên đến 1280 byte, tương tự như các frame cá nhân trong luồng video. Khi được lắp ráp lại, các shreds này cho phép các validator phát lại toàn bộ block. Các shreds được gửi qua internet giữa các validator sử dụng UDP và sử dụng mã hóa xóa để xử lý mất gói tin hoặc việc vứt gói tin một cách độc hại.Mã hóa xóa, ađa thức-based lược đồ phát hiện và sửa lỗi, đảm bảo tính toàn vẹn dữ liệu. Ngay cả khi một số mảnh bị mất, khối vẫn có thể được tái tạo.

Các mảnh được nhóm thành các nhóm được biết đến là các nhóm sửa lỗi chuyển tiếp (FEC). Theo mặc định, các nhóm này bao gồm 64 mảnh (32 mảnh dữ liệu + 32 mảnh khôi phục). Việc khôi phục dữ liệu xảy ra trên mỗi nhóm FEC, có nghĩa rằng có thể mất hoặc bị hỏng tới một nửa số gói trong một nhóm, và tất cả dữ liệu vẫn có thể được khôi phục. Mỗi nhóm 64 mảnh được merkelized với gốc được ký bởi người điều hành, và được nối với nhóm trước đó. Quy trình này đảm bảo rằng các mảnh có thể được thu thập một cách an toàn từ bất kỳ nút nào trong mạng mà nắm giữ chúng, vì chuỗi các gốc Merkle cung cấp một đường dẫn xác minh được tính xác thực và toàn vẹn.

Người lãnh đạo ban đầu phát sóng đến một nút gốc duy nhất, nơi phân phối các mảnh thành tất cả các nút xác nhận khác. Nút gốc này thay đổi với mỗi mảnh. Các nút xác nhận được tổ chức thành các tầng, tạo thành “Cây Turbine.” Các nút xác nhận có số lượng cổ phần lớn thường được đặt ở phía trên cây, trong khi những người có số lượng cổ phần thấp được đặt ở phía dưới.

Cây thường có hai hoặc ba bước nhảy, tùy thuộc vào số lượng các nhà xác thực hoạt động. Vì mục đích minh họa một cách trực quan, một số 3 được mô tả ở trên, nhưng giá trị thực tế của số 3 của Solana hiện đang được đặt là 200. Vì lý do an ninh, thứ tự của cây được xoay vòng cho mỗi lô shred mới.

Mục tiêu chính của một hệ thống như vậy là giảm áp lực xuất dữ liệu ra ngoài trên các nút trưởng và gốc. Bằng cách sử dụng hệ thống truyền và truyền lại, tải được phân phối giữa nút trưởng và các bộ truyền lại, giảm sức ép lên bất kỳ nút nào.

Đồng thuận

“Một số người thông minh nói với tôi rằng có một cộng đồng nhà phát triển thông minh nghiêm túc trên Solana… Tôi hy vọng cộng đồng có cơ hội phát triển công bằng của mình” — Vitalik Buterin, cộng sáng lập Ethereum

Khi một nhà xác minh nhận được một khối mới từ người điều hành thông qua Turbine, nó phải xác minh tất cả các giao dịch trong mỗi mục nhập. Điều này bao gồm việc chơi lại toàn bộ khối, xác minh các băm PoH song song, tái tạo các giao dịch theo trình tự do PoH quy định và cập nhật ngân hàng cục bộ của nó.

Quy trình này được xử lý bởi Đơn vị Xác nhận Giao dịch (TVU), tương tự như Đơn vị Xử lý Giao dịch của người đứng đầu (TPU), đóng vai trò là logic cốt lõi chịu trách nhiệm xử lý các mảnh và xác nhận khối. Giống như TPU, luồng TVU được chia thành nhiều giai đoạn, bắt đầu từ Giai đoạn Lấy Mảnh nơi các mảnh được nhận qua Turbine. Trong Giai đoạn Xác minh Chữ ký Lãnh đạo Mảnh tiếp theo, các mảnh trải qua nhiều kiểm tra sức khỏe, đặc biệt là việc xác minh chữ ký của lãnh đạo, đảm bảo rằng các mảnh nhận được xuất phát từ lãnh đạo.

Trong Giai đoạn Retransmit, người xác minh, dựa trên vị trí của mình trong cây Turbine, chuyển tiếp các mảnh dữ liệu đến các người xác minh hạ tầng thích hợp. Trong Giai đoạn Phát lại, người xác minh tạo lại mỗi giao dịch một cách chính xác và theo đúng thứ tự trong khi cập nhật phiên bản ngân hàng cục bộ của mình.

Giai đoạn Phát lại tương tự như giai đoạn ngân hàng trong TPU; đây là giai đoạn quan trọng nhất và có thể được mô tả trực tiếp hơn như là giai đoạn xác nhận khối. Phát lại là một vòng lặp quá trình đơn luồng điều phối nhiều hoạt động chính, bao gồm bỏ phiếu, đặt lại đồng hồ PoH và chuyển ngân hàng.

Phía trên: giai đoạn phát lại chịu trách nhiệm chuyển đổi người xác thực thành chế độ lãnh đạo và bắt đầu sản xuất khối. Trực quan ban đầu: Justin Starry, Anza

Consensus

Để đạt được sự nhất quán, Solana sử dụng Tower BFT (TBFT), một sự triển khai tùy chỉnh của PracticalLỗi ByzantineThuật toán Tolerant (PBFT), thường được sử dụng bởi hầu hết các chuỗi khối để đồng ý về trạng thái của chuỗi. Giống như tất cả các chuỗi khối khác, Solana giả định sự hiện diện của các nút độc hại trong mạng, vì vậy hệ thống phải chịu được không chỉ sự cố của nút mà còn cấp độ của các cuộc tấn công nhất định.

Tower BFT khác biệt với các chuỗi khác bằng cách tận dụng đồng hồ đồng bộ được cung cấp bởi Bằng chứng về Lịch sử. Trong khi PBFT truyền thống yêu cầu nhiều vòng tròn giao tiếp để đồng ý về thứ tự giao dịch, các nút Solana sử dụng thứ tự sự kiện đã được thiết lập trước đó, giảm đáng kể overhead tin nhắn.

Bỏ phiếu

Để tham gia vào sự đồng thuận và kiếm phần thưởng, người xác minh gửi phiếu bầu cho các khối mà họ tin rằng hợp lệ (tức là, không có vấn đề như chi tiêu kép hoặc chữ ký không chính xác) và nên được xem xét là cơ bản. Người xác minh trả phí giao dịch cho những phiếu bầu này, được xử lý bởi người dẫn đầu và được bao gồm trong một khối cùng với các giao dịch của người dùng thông thường. Điều này là lý do tại sao các giao dịch Solana thường được phân loại thành giao dịch bầu cử và giao dịch không bầu cử. Khi người xác minh gửi một phiếu bầu chính xác và thành công, họ kiếm được một tín dụng. Cơ chế này khuyến khích người xác minh bầu cử cho nhánh mà họ tin rằng có cơ hội tốt nhất để được bao gồm, tức là, nhánh “nặng” nhất.

Forks

Một phần của thiết kế của Solana, làm cho nó trở nên nhanh chóng, đó là mạng không chờ đợi tất cả các validator đồng ý với một khối mới được tạo ra trước khi tạo ra khối tiếp theo. Kết quả là, không phải là điều hiếm gặp khi hai khối khác nhau được liên kết với cùng một khối cha, tạo ra các nhánh.

Các validator của Solana phải bỏ phiếu cho những nhánh này và sử dụng thuật toán đồng thuận để xác định nhánh nào để chấp nhận. Khi có những nhánh cạnh tranh tồn tại, chỉ có một nhánh cuối cùng sẽ được mạng lưới chấp nhận, trong khi các khối trong những nhánh bị loại bỏ.

Mỗi khe có một nhà lãnh đạo xác định trước và chỉ khối của nhà lãnh đạo đó sẽ được chấp nhận; không thể có hai khối đề xuất cho một khe duy nhất. Do đó, số lượng các nhánh tiềm năng bị hạn chế thành một “danh sách nhảy có/ không có” các nhánh có thể xuất hiện tại các ranh giới của các khe quay lãnh đạo. Khi một người xác minh chọn một nhánh, nó sẽ cam kết với nhánh này cho đến khi hết thời gian khóa, có nghĩa là nó phải tuân thủ lựa chọn của mình trong một khoảng thời gian tối thiểu.

Tỷ lệ “bỏ qua” của Solana—phần trăm các khe mà trong đó một khối không được tạo ra—dao động từ 2% đến 10%, với các phân nhánh là nguyên nhân chính cho việc bỏ qua các khe này. Những nguyên nhân khả dĩ khác cho việc bỏ qua các khe bao gồm sự bắt đầu của một kỷ nguyên mới, một nhà lãnh đạo không hoạt động, hoặc sự sản xuất của một khối không hợp lệ.

Nhớ

Trạng thái của một giao dịch trên Solana thay đổi tùy thuộc vào giai đoạn hiện tại trong quá trình đồng thuận:

• Đã xử lý: Giao dịch đã được bao gồm trong một khối.

• Xác nhận: Khối giao dịch đã được bỏ phiếu bởi đa số siêu lớn hai phần ba.

• Đã hoàn tất: Hơn 31 khối đã được xây dựng trên khối giao dịch.

Đến nay, chưa từng có một trường hợp nào trong lịch sử của Solana mà một block được xác nhận (một cách lạc quan) không trở thành cuối cùng.

Đối với mỗi khối, Solana sử dụng một ngân hàng để truy cập trạng thái tại khối đó. Khi một ngân hàng được hoàn tất, các cập nhật tài khoản từ ngân hàng đó và tổ tiên của nó được đẩy xuống đĩa. Ngoài ra, bất kỳ cập nhật tài khoản từ các ngân hàng trước đó mà không phải là tổ tiên của ngân hàng đã hoàn tất sẽ bị cắt bỏ. Quy trình này cho phép Solana duy trì nhiều trạng thái tiềm năng một cách hiệu quả.

Gossip + Lưu trữ

“Một chuỗi khối đòi hỏi một sự kết hợp thông minh giữa mật mã, hệ thống phân tán, hệ điều hành và ngôn ngữ lập trình. Sức mạnh siêu phàm của Solana là sự sẵn lòng chạy trốn khỏi những vấn đề hấp dẫn nhất trong mỗi lĩnh vực.” — Greg Fitzgerald, đồng sáng lập Solana

Gossip

Mạng tin đồn có thể được coi nhưcontrol planecho mạng Solana. Không giống như mặt phẳng dữ liệu, mà xử lý luồng giao dịch, mặt phẳng điều khiển phổ biến dữ liệu quan trọng về trạng thái chuỗi khối, chẳng hạn như thông tin liên lạc, chiều cao sổ cái và thông tin bỏ phiếu. Mà không có tin đồn, các nhà xác minh và RPCs sẽ không biết địa chỉ và cổng nào mở để giao tiếp qua các dịch vụ khác nhau. Các nút mới cũng phụ thuộc vào tin đồn để tham gia vào mạng.

Gossip protocol của Solana sử dụng giao tiếp không chính thức, ngang hàng với phương pháp truyền thông cây được truyền cảm hứng bởi thuật toán PlumTree được điều chỉnh. Phương pháp này truyền thông thông tin một cách hiệu quả mà không phụ thuộc vào bất kỳ nguồn trung tâm nào.

Lời đồn hoạt động một cách tương đối như một hệ thống cô lập, độc lập với hầu hết các thành phần xác nhận khác. Người xác nhận và RPC chia sẻ các đối tượng dữ liệu đã ký mỗi 0,1 giây qua UDP thông qua lời đồn, đảm bảo sẵn có thông tin trên toàn mạng. Tất cả các tin đồn phải ít hơn hoặc bằng đơn vị truyền tải tối đa (MTU) của 1280 byte, được gọi là “cấu trúc gói” trong mã nguồn.

Bản ghi lời đồn là các đối tượng dữ liệu thực sự được chia sẻ giữa các nút. Có khoảng 10 loại bản ghi khác nhau, mỗi loại phục vụ mục đích khác nhau. Bản ghi lời đồn được ký, phiên bản và ghi thời gian để đảm bảo tính toàn vẹn và tính hiện tại.

Có bốn loại tin đồn:

• Push: Những tin nhắn phổ biến nhất, chia sẻ thông tin với một phần của "đồng đẳng push".
• Kiểm tra định kỳ tin nhắn bị bỏ lỡ, với phản hồi kéo trả lại thông tin mà các nút không có.
• Cắt tỉa: Cho phép các nút giảm số lượng kết nối mà họ duy trì một cách lựa chọn.
• Ping & Pong: Kiểm tra sức khỏe cho các nút-nếu một ping được gửi, một pong được mong đợi trở lại, cho biết nút đồng bộ vẫn hoạt động.

Dữ liệu tin đồn được lưu trữ trong một Công cụ Lưu trữ Dữ liệu Đa Cụm (CrdsTable). Cấu trúc dữ liệu này có thể phát triển rất lớn và cần được cắt tỉa định kỳ.

Lưu trữ

Solana nổi bật so với các blockchain khác bằng việc không yêu cầu toàn bộ lịch sử để xác định trạng thái hiện tại của một tài khoản. Mô hình tài khoản của Solana đảm bảo rằng trạng thái tại mọi slot cụ thể đều được biết, cho phép các validator lưu trữ trạng thái hiện tại của mỗi tài khoản mà không cần xử lý tất cả các khối lịch sử. RPCs và các validator, theo thiết kế, không giữ lại toàn bộ sổ cái lịch sử. Thay vào đó, họ thường chỉ lưu trữ dữ liệu giao dịch trong 1 hoặc 2 kỷ nguyên (tương đương 2-4 ngày), đủ để xác minh đầu mối của chuỗi.

Hiện tại, các bản ghi được quản lý bởi các “nút kho”, do các nhà cung cấp dịch vụ RPC chuyên nghiệp, Quỹ Solana và các bên tham gia hệ sinh thái khác quan tâm đến việc đảm bảo lịch sử giao dịch có sẵn. Các nút kho thường duy trì một hoặc cả hai trong số các yếu tố sau:

1. Lưu trữ Ledger: Tải lên bản ghi gốc của ledger và bản chụp AccountsDB phù hợp để chơi lại từ đầu.

2. Google Bigtable Instance: Lưu trữ dữ liệu khối từ khối khởi đầu trở đi, được định dạng để phục vụ các yêu cầu RPC.

Kinh tế + Jito

“Mọi người đang nhận ra rằng Solana là chuỗi duy nhất hiện có hôm nay sẽ hỗ trợ các ứng dụng tiêu dùng chính thống.” — Ted Livingston, nhà sáng lập Code

Solana sử dụng lạm phát để phân phối phần thưởng chống đầu cơ bằng cách tạo ra các mã thông báo SOL mới trong mỗi kỷ nguyên. Quá trình này làm cho phần trăm mạng của những người không đầu cơ giảm so với người đầu cơ, dẫn đến việc chuyển giao tài sản từ người không đầu cơ sang người đầu cơ. Lạm phát bắt đầu vào đầu năm 2021 với tỷ lệ ban đầu là 8% giảm đi 15% hàng năm cho đến khi ổn định ở mức tỷ lệ dài hạn là 1.5%.

Bất kỳ chủ sở hữu token SOL nào đều có thể kiếm được phần thưởng và giúp bảo vệ mạng bằng cách đặt cược token vào một hoặc nhiều nhà xác minh. Gán token cho một nhà xác minh được biết đến là ủy quyền. Ủy quyền token cho một nhà xác minh cho thấy sự tin tưởng vào nhà xác minh. Tuy nhiên, điều này không đưa ra quyền sở hữu hoặc kiểm soát token cho nhà xác minh. Tất cả các hành động đặt cược, rút cược và ủy quyền đều được thực hiện vào đầu kỷ nguyên mới tiếp theo.

‍

Phần thưởng bình chọn

Khi một validator nộp một phiếu bầu, họ sẽ kiếm được một tín dụng nếu phiếu bầu là chính xác và thành công. Giao dịch bầu cử có giá 0,000005 SOL và được miễn phí ưu tiên. Chi phí bầu cử lên đến khoảng 1 SOL mỗi ngày mỗi validator, làm cho đó là chi phí vận hành chính của việc chạy một validator. Trong suốt một epoch, các validator tích luỹ tín dụng từ việc bầu cử, mà họ có thể trao đổi để nhận một phần của lạm phát vào cuối epoch.

Các máy chủ xác thực hiệu suất cao thành công bỏ phiếu cho khoảng 90% các khe. Lưu ý rằng tỷ lệ khe không có khối (tỷ lệ khe bị bỏ qua) dao động từ 2% đến hơn 10%, và những khe này không thể được bỏ phiếu. Máy chủ xác thực trung bình thành công bỏ phiếu cho khoảng 80% các khe, kiếm được 345.600 tín dụng trong một kỷ nguyên của 432.000 khe.

Tổng cục phát hành lạm phát được chia sẻ dựa trên số tín dụng kiếm được cho kỷ nguyên. Phần trăm của một validator trong tổng số tín dụng (số tín dụng của họ chia cho tổng số tín dụng của tất cả các validator) xác định phần thưởng tương ứng của họ. Điều này được trọng số thêm bởi số cổ phần.

Do đó, một người xác minh có 1% tổng số cổ phần nên kiếm được khoảng 1% tổng lạm phát nếu họ có một số tín dụng trung bình. Nếu họ có số tín dụng trên hoặc dưới trung bình, phần thưởng của họ sẽ biến động tương ứng.

Sự khác biệt về hiệu suất bỏ phiếu là một trong những lý do khiến lợi nhuận (đo lường theo APY) mà các validator cung cấp cho người staker khác nhau. Một yếu tố khác là tỷ lệ hoa hồng mà các validator thu, đó là một phần trăm của tổng số phần thưởng lạm phát được chuyển đến validator của họ. Ngoài ra, việc một validator bị offline hoặc không đồng bộ với blockchain (được biết đến với tên gọi là sự cẩu thả) ảnh hưởng đáng kể đến lợi nhuận.

Phần thưởng khối

Các nhà xác minh được chỉ định là người dẫn đầu cho một khối cụ thể sẽ nhận được phần thưởng khối bổ sung. Những phần thưởng này bao gồm 50% phí cơ bản và 50% phí ưu tiên của tất cả giao dịch trong khối đó, phần còn lại của phí sẽ được đốt cháy. Chỉ có nhà xác minh tạo ra khối mới nhận được phần thưởng này. Khác với phần thưởng đặt cược, được phân phối theo kỷ nguyên, phần thưởng khối sẽ được ghi có ngay lập tức vào tài khoản danh tính của nhà xác minh khi khối được tạo ra.

Staking dạng lưu

Việc đặt cọc lỏng đã trở thành một lựa chọn phổ biến thay thế cho việc đặt cọc gốc. Người tham gia nhận một token, được biết đến là Liquid Staking Token (LST) hoặc Liquid Staking Derivative (LSD), để đặt cọc SOL của họ, thường là trong một pool đặt cọc mà ủy quyền token của họ trên nhiều validator. Các token LST mới nhận đại diện cho phần trăm của người dùng đặt cọc SOL. Những token này có thể được giao dịch, sử dụng trên các ứng dụng, hoặc chuyển cho người khác trong khi vẫn nhận phần thưởng đặt cọc. Ưu điểm chính của hệ thống này là nó cải thiện đáng kể hiệu quả vốn.

Giá của LST = (tổng số SOL đặt cược trong hồ * giá của SOL) / tổng số LST được đúc

Với việc đặt cọc bản địa theo cách truyền thống, theo thời gian, người stake sẽ trực tiếp tích luỹ thêm SOL. Trong khi đó, với việc đặt cọc linh hoạt, phần thưởng được đầu tư trở lại vào pool tăng giá trị công bằng của LST. Miễn là có cơ chế để đổi LST cho SOL đã stake bên dưới, nhà giao dịch cơ hội sẽ đảm bảo rằng giá token vẫn hợp lý.

Jito

Tính đến thời điểm viết bài, hơn 80% (nguồn) của cổ phần trên Solana sử dụng phần mềm xác thực Jito client. Client này, một bản fork của client gốc Agave, giới thiệu một phiên đấu giá không theo giao thức về không gian khối, cung cấp cho các máy chủ xác thực động lực kinh tế bổ sung thông qua tiền boa. Động lực bổ sung này là một yếu tố chính trong việc áp dụng rộng rãi của client Jito trong số các máy chủ xác thực.

Khi các nhà lãnh đạo sử dụng khách hàng xác thực Jito, giao dịch của họ ban đầu được chuyển tiếp đến Jito-Relayer. Phần mềm mã nguồn mở này hoạt động như một bộ định tuyến proxy giao dịch. Các nút mạng khác không nhận biết sự tồn tại của Jito-Relayer, vì chúng đơn giản gửi giao dịch đến địa chỉ và cổng cấu hình mà nhà lãnh đạo đã quảng cáo trên mạng lưới tiếng thì thầm như là ingress_socket của họ, giả định rằng đó là của nhà lãnh đạo.

Relayer giữ tất cả các giao dịch trong 200 mili giây trước khi chuyển tiếp chúng đến đơn vị chỉ huy. Cơ chế "gờ giảm tốc" này trì hoãn các tin nhắn giao dịch đến, cung cấp một cửa sổ ngắn để tiến hành đấu giá. Sau 200 mili giây, người chuyển tiếp lạc quan phát hành các giao dịch bất kể kết quả đấu giá như thế nào.

Đấu giá khoảng trống diễn ra ngoài chuỗi thông qua Jito Block Engine, cho phép người tìm kiếm và ứng dụng gửi các nhóm giao dịch được thực hiện theo nguyên tử được gọi là bó. Những bó này thường chứa các giao dịch đòi hỏi thời gian như cơ hội thương mại hoặc thanh lý. Jito tính phí 5% trên tất cả các tài liệu, với tối thiểu 10,000 lamports. Các tài liệu hoạt động hoàn toàn ngoài giao thức, riêng biệt với ưu tiên và phí cơ sở trong giao thức. Trước đây, Jito đã vận hành dịch vụ bộ nhớ mem-pool ngoài giao thức kiểu mẫu, nhưng hiện đã bị loại bỏ.

Miễn trừ trách nhiệm：

1. Bài viết này được sao chép từ [Solanahelius]. Tất cả bản quyền thuộc về tác giả gốc [Lostin]. Nếu có ý kiến phản đối về việc tái bản, vui lòng liên hệ với Học cửađội ngũ và họ sẽ xử lý ngay lập tức.
2. Miễn trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.