Kiến trúc Solana: 8 Cải tiến Đằng sau Tốc độ của SOL

Lưu ý về độ chính xác: Hiệu suất mạng, số lượng validator, phí, tính năng giao thức, hỗ trợ ví và các tích hợp bên thứ ba thay đổi theo thời gian. Hãy coi các số liệu có ghi ngày tháng là ảnh chụp nhanh lịch sử và xác minh tài liệu nguồn gốc hiện tại.

Kiến trúc Solana thường được giải thích thông qua tám ý tưởng thiết kế từ các tài liệu kỹ thuật ban đầu của nó. Một số vẫn là trung tâm, trong khi những ý tưởng khác là đề xuất lịch sử hoặc đã phát triển, vì vậy bài viết này phân biệt mô hình ban đầu với các tuyên bố triển khai hiện tại.

Các tài liệu Solana ban đầu nhóm kiến trúc thành tám ý tưởng nhằm hỗ trợ thực thi thông lượng cao. Hiệu suất hiện tại, quyền sở hữu triển khai, các thành phần phần mềm và vai trò tổ chức đều phát triển, vì vậy bài viết này coi khung "tám cải tiến" như một mô hình giải thích lịch sử hơn là một đặc tả hiện tại đầy đủ.

Những điểm chính cần lưu ý

Kiến trúc của Solana được xây dựng trên tám trụ cột, mỗi trụ cột giải quyết một nút thắt hiệu suất cụ thể:

1. Proof of History (PoH): đồng hồ mật mã đóng dấu thời gian cho các sự kiện trước khi sự đồng thuận diễn ra
2. Tower BFT: Cơ chế đồng thuận sử dụng dấu thời gian PoH trong việc bỏ phiếu
3. Turbine: truyền bá khối bằng cách chia các khối thành các gói nhỏ hơn
4. Gulf Stream: chuyển tiếp giao dịch dựa trên những người dẫn đầu được lên lịch
5. Sealevel: môi trường thực thi Hợp đồng Thông minh song song
6. Pipelining: xử lý giao dịch theo giai đoạn
7. Cloudbreak: cơ sở dữ liệu tài khoản được thiết kế để truy cập đồng thời
8. Archivers: một đề xuất lưu trữ phân tán lịch sử

Lưu ý về hiệu suất: TPS lý thuyết trong lịch sử, thời gian slot mục tiêu, xác nhận, tính hoàn thiện, phí cơ bản và phí ưu tiên là các phép đo khác nhau. Xác minh các chỉ số hiện tại, có ghi ngày tháng và phương pháp đằng sau chúng.

Sự đánh đổi trung thực: Solana đã trải qua các đợt ngừng hoạt động mạng được ghi nhận kể từ khi khởi chạy Mainnet vào tháng 3 năm 2020 và các yêu cầu phần cứng validator của nó (khuyến nghị RAM 128+ GB) tạo ra áp lực tập trung hóa. Đây là những sự đánh đổi kiến trúc đã được biết đến, không phải là các vấn đề ngẫu nhiên.

Vấn đề mà Solana được xây dựng để giải quyết

Các blockchain truyền thống thường phải đối mặt với một hạn chế cơ bản: Bộ ba bất khả thi của Blockchain, một khái niệm được phổ biến bởi Vitalik Buterin, cho rằng một mạng lưới chỉ có thể đạt được đồng thời tối đa hai trong ba thuộc tính. Những thuộc tính đó là khả năng mở rộng (thông lượng cao), bảo mật (khả năng chống tấn công) và tính phi tập trung (kiểm soát phân tán). Hãy coi đó như một tam giác mà khi đẩy một góc ra xa sẽ luôn kéo hai góc còn lại vào trong. Bitcoin xử lý ~7 TPS với thời gian tạo khối 10 phút, ưu tiên bảo mật và tính phi tập trung bằng cái giá là thông lượng. Ethereum xử lý ~15–30 TPS ở lớp cơ sở trước khi các giải pháp mở rộng được thêm vào, cũng ưu tiên bảo mật và tính phi tập trung.

Anatoly Yakovenko, cựu kỹ sư hệ thống phân tán tại Qualcomm, đã tiếp cận hạn chế này theo cách khác. Vào tháng 11 năm 2017, ông đã xuất bản một Whitepaper có tiêu đề Proof of History: A Clock for Blockchain, mô tả một cơ chế chấm công mật mã có thể giảm đáng kể chi phí liên lạc trong các thuật toán đồng thuận. Greg Fitzgerald đã tham gia với tư cách là đồng sáng lập và CTO, và họ cùng nhau xây dựng giao thức trở thành Solana. Solana Labs, công ty vì lợi nhuận mà họ đồng sáng lập, dẫn đầu việc phát triển giao thức cốt lõi. Solana Foundation, một thực thể phi lợi nhuận riêng biệt có trụ sở tại Geneva, tài trợ cho các khoản tài trợ hệ sinh thái, các chương trình phi tập trung hóa validator và các sáng kiến giáo dục.

Kiến trúc tám trụ cột của Solana được thiết kế để đẩy ranh giới khả năng mở rộng đi xa nhất có thể trong các hạn chế của bộ ba bất khả thi đó. Thiết kế này cố tình chấp nhận các yêu cầu phần cứng validator cao hơn như một cái giá cho thông lượng đó. Solana không giải quyết bộ ba bất khả thi; nó chiếm giữ một vị thế cực kỳ quyết liệt trên trục khả năng mở rộng. Những sự đánh đổi đó có chi phí thực tế, được xem xét trong phần đánh đổi kiến trúc bên dưới.

Tám Trụ cột Kiến trúc của Solana: Tổng quan

Khung tám phần lịch sử bao gồm Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak và Archivers. Không nên giả định mọi mục đều vẫn là một hệ thống con hiện tại được triển khai riêng biệt, đặc biệt là đề xuất Archivers.

1. Proof of History: một chuỗi băm SHA-256 tuần tự tạo ra bản ghi dấu thời gian có thể xác minh trước khi sự đồng thuận diễn ra
2. Tower BFT: một Cơ chế đồng thuận chịu lỗi Byzantine được cải tiến bởi PoH, sử dụng dấu thời gian PoH để bỏ phiếu hiệu quả
3. Turbine: một giao thức truyền bá khối lấy cảm hứng từ BitTorrent, chia các khối thành các gói mã hóa xóa lỗi nhỏ được gọi là shred
4. Gulf Stream: một giao thức chuyển tiếp giao dịch không có Mempool, định tuyến các giao dịch trực tiếp đến những người dẫn đầu validator sắp tới
5. Sealevel: một môi trường thực thi Hợp đồng Thông minh song song chạy hàng nghìn chương trình không xung đột cùng một lúc
6. Pipelining: một hệ thống Tối ưu hóa Xác thực Giao dịch (TVO) xử lý các giao dịch thông qua bốn giai đoạn phần cứng đồng thời
7. Cloudbreak: một cơ sở dữ liệu tài khoản được mở rộng theo chiều ngang sử dụng các tệp ánh xạ bộ nhớ để hỗ trợ các hoạt động đọc và ghi đồng thời
8. Archivers: một đề xuất lịch sử về lưu trữ sổ lệnh phân tán bằng cách sử dụng các khái niệm bằng chứng sao chép

Mỗi trụ cột được trình bày chuyên sâu trong các phần bên dưới.

Proof of History (PoH): Công cụ Chấm công của Solana

Proof of History (PoH) là một chuỗi băm SHA-256 tuần tự tạo ra một bản ghi các sự kiện được sắp xếp theo thời gian, có thể xác minh được trước khi sự đồng thuận diễn ra, đóng vai trò như một đồng hồ mật mã chung cho toàn bộ mạng lưới. PoH không phải là Cơ chế đồng thuận của Solana; vai trò đó thuộc về Tower BFT. PoH là lớp chấm công giúp Tower BFT hoạt động nhanh chóng.

Hãy coi PoH như một đồng hồ bấm giờ mật mã chứng minh lượng thời gian đã trôi qua giữa các sự kiện, mà không yêu cầu mọi validator trên mạng phải kiểm tra đồng hồ của nhau trước. Trong các mạng blockchain truyền thống, các validator phải trao đổi tin nhắn dấu thời gian với nhau trong mỗi vòng đồng thuận, tạo thêm chi phí liên lạc tăng dần theo quy mô của tập hợp validator. PoH loại bỏ hoàn toàn việc trao đổi đó.

Về mặt kỹ thuật, PoH là một chuỗi băm SHA-256 tuần tự, trong đó mỗi đầu ra trở thành đầu vào cho tính toán tiếp theo. Vì SHA-256 không thể song song hóa ở dạng chuỗi này, nên độ dài của chuỗi là một bản ghi không thể giả mạo về thời gian đã trôi qua. Một validator tạo ra một chuỗi gồm N hàm băm đã chứng minh rõ ràng việc dành thời gian cần thiết để tính toán N hoạt động băm tuần tự. Không có lối tắt nào tồn tại. Anatoly Yakovenko lần đầu tiên mô tả cơ chế này trong Whitepaper tháng 11 năm 2017 của mình, Proof of History: A Clock for Blockchain.

PoH hoạt động như một Hàm Trì hoãn Có thể Xác minh (VDF): một phép tính tiêu tốn một khoảng thời gian dự đoán được và tuần tự để tính toán nhưng có thể được xác minh gần như ngay lập tức. Sự bất đối xứng giữa thời gian tính toán và thời gian xác minh này là yếu tố làm cho PoH trở nên thực tế. Các trình xác thực có thể phát sóng đầu ra PoH và bất kỳ người quan sát nào cũng có thể xác minh tính xác thực của nó trong vài micro giây, ngay cả khi việc tạo ra nó đòi hỏi thời gian thực trôi qua. Đây là đặc tính mà các nhà nghiên cứu học thuật và các nhà phân tích giao thức sẽ công nhận là nền tảng lý thuyết cho các thuộc tính bảo mật của PoH.

Bằng cách thiết lập một tham chiếu thứ tự có thể xác minh, PoH có thể giảm bớt một số hoạt động điều phối thời gian. Nó không loại bỏ việc truyền tin nhắn đồng thuận hoặc trực tiếp đảm bảo một slot, xác nhận hoặc thời gian hoàn tất cụ thể.

Một làm rõ quan trọng: Solana đôi khi được mô tả là một "Blockchain Proof of History", ngụ ý rằng PoH thay thế Proof of Stake (PoS). Điều này là không chính xác. Solana là một blockchain Proof of Stake tại lớp bảo mật kinh tế của nó. Các trình xác thực stake SOL làm tài sản thế chấp và đối mặt với hình phạt slashing đối với hành vi không trung thực. PoH là đồng hồ mật mã giúp Cơ chế đồng thuận PoS của Solana, được triển khai thông qua Tower BFT, nhanh hơn và hiệu quả hơn. Cả hai lớp đều cần thiết; không cái nào thay thế cái kia.

Tower BFT: Cơ chế đồng thuận của Solana

Tower BFT là Cơ chế đồng thuận của Solana: một biến thể nâng cao bởi PoH của Hệ thống chịu lỗi Byzantine thực tế (pBFT), sử dụng bản ghi dấu thời gian PoH làm đồng hồ dùng chung, cho phép các trình xác thực bỏ phiếu về trạng thái sổ cái mà không cần trao đổi các tin nhắn đồng bộ hóa đồng hồ.

Hệ thống chịu lỗi Byzantine (BFT) mô tả đặc tính của một hệ thống phân tán cho phép nó đạt được đồng thuận chính xác ngay cả khi một số người tham gia có hành vi ác ý hoặc không thể dự đoán được, được đặt tên theo bài toán Các vị tướng Byzantine trong tính toán phân tán. Các thuật toán pBFT truyền thống yêu cầu việc truyền tin nhắn rộng rãi giữa các nút để thiết lập một chế độ xem thời gian chung, điều này khiến chúng không thực tế ở quy mô lớn. Tower BFT thay thế việc truyền tin nhắn đó bằng bản ghi PoH. Các trình xác thực đã chia sẻ chung đồng hồ PoH; họ không cần phải thương lượng về dấu thời gian.

Trình xác thực là những người tham gia mạng lưới thực hiện stake SOL, xác thực các giao dịch, tạo các khối khi được chọn làm người dẫn dắt (leader) và bỏ phiếu về trạng thái sổ cái. Họ thực hiện các phiếu bầu bị khóa thời gian tăng theo cấp số nhân trên các Fork. Một trình xác thực bỏ phiếu cho một Fork cụ thể càng lâu, họ càng có nguy cơ mất nhiều SOL hơn thông qua slashing (cơ chế hình phạt loại bỏ các token đã stake đối với hành vi không trung thực hoặc không nhất quán) nếu Fork đó bị bỏ rơi. Cơ chế khóa phiếu bầu này tạo ra các khuyến khích kinh tế mạnh mẽ cho việc tham gia trung thực mà không yêu cầu các vòng giao tiếp bổ sung.

Tower BFT chấp nhận tối đa một phần ba tập hợp trình xác thực có hành vi Byzantine. Nếu ít hơn một phần ba số trình xác thực hành động ác ý, mạng lưới sẽ đạt được đồng thuận chính xác. Ngưỡng này bắt nguồn từ các yêu cầu toán học của bài toán Các vị tướng Byzantine, ban đầu được chính thức hóa bởi Lamport, Shostak và Pease vào năm 1982. Dòng dõi đồng thuận cho các nhà nghiên cứu: pBFT (Castro và Liskov, 1999) đã thiết lập thuật toán nền tảng; các biến thể tiếp theo bao gồm HotStuff và Tendermint đã cải thiện nó; Tower BFT (2017) tiến thêm một bước nữa là loại bỏ chi phí đồng bộ hóa đồng hồ thông qua PoH.

Thời gian slot mục tiêu không được trình bày như một đảm bảo về tính hoàn tất. Các ứng dụng nên phân biệt các mức độ cam kết đã xử lý, đã xác nhận và đã hoàn tất, đồng thời chọn các quy tắc xác nhận dựa trên mô hình rủi ro của họ.

Turbine: Truyền bá khối ở quy mô lớn

Phát sóng một khối đầy đủ tới mọi trình xác thực ở mức 65.000 TPS lý thuyết sẽ tạo ra nút thắt cổ chai về băng thông tăng tuyến tính theo quy mô mạng lưới. Turbine giải quyết vấn đề này giống như cách BitTorrent giải quyết việc phân phối tệp lớn: bằng cách chia nhỏ dữ liệu thành các phần nhỏ và phân bổ tải truyền bá trên toàn mạng lưới.

Turbine là giao thức truyền bá khối của Solana, lấy cảm hứng từ mô hình phân phối dựa trên từng phần của BitTorrent. Thay vì một leader phát sóng đồng thời một khối hoàn chỉnh tới mọi trình xác thực, Turbine chia các khối thành các gói mã hóa xóa (erasure-coded) nhỏ gọi là các shred và phân phối chúng qua một mạng lưới trình xác thực có cấu trúc hình cây.

Các shred được mã hóa xóa để dự phòng. Mỗi nút trong cây truyền bá nhận được một tập hợp con các shred, truyền lại chúng cho lớp tiếp theo và tái cấu trúc khối đầy đủ từ tập hợp con mà nó nhận được. Việc mã hóa xóa có nghĩa là ngay cả khi một số shred bị mất trong quá trình truyền tải, khối vẫn có thể được tái cấu trúc từ các gói còn lại. Yêu cầu băng thông tăng theo hàm logarit thay vì tuyến tính theo quy mô mạng lưới, vì mỗi trình xác thực chỉ xử lý một phần nhỏ tổng dữ liệu khối.

Việc mở rộng tập hợp trình xác thực không làm tăng tỷ lệ yêu cầu băng thông trên mỗi nút. Một mạng lưới với 2.000 trình xác thực không yêu cầu mỗi trình xác thực phải xử lý băng thông gấp 2.000 lần so với một hệ thống tập trung. Cây truyền bá phân bổ tải trọng. Cấu trúc shred của Turbine có liên quan đến các nhà vận hành trình xác thực khi lập kế hoạch tiếp nhận dữ liệu và khả năng tái cấu trúc khối.

Gulf Stream: Chuyển tiếp giao dịch không cần Mempool

Gulf Stream sử dụng tính năng chuyển tiếp nhận biết leader thay vì một mempool toàn cầu dùng chung thông thường. Điều này thay đổi mô hình xếp hàng nhưng không loại bỏ tình trạng tắc nghẽn hoặc các khuyến khích về thứ tự giao dịch.

Trên Ethereum, các giao dịch chưa xác nhận sẽ chờ trong mempool: nhóm chung gồm các giao dịch chưa xác nhận đang chờ được đưa vào một khối. Trong thời gian nhu cầu cao, nhóm này trở thành nguồn gây tắc nghẽn, leo thang phí và Giá trị có thể trích xuất tối đa (MEV), lợi nhuận thu được bằng cách sắp xếp lại, chèn hoặc kiểm duyệt các giao dịch trong mempool trước khi chúng được hoàn tất. Người dùng Ethereum mua (bid) phí gas cao hơn để ưu tiên các giao dịch của họ, đó là lý do tại sao phí trong lịch sử đạt tới 5–50 USD trở lên trong thời gian sử dụng cao điểm.

Thiết kế sử dụng lịch trình leader đã biết của Solana để chuyển tiếp các giao dịch tới các leader sắp tới thay vì phát sóng chúng tới một nhóm toàn cầu thông thường. Các trình xác thực có thể chuẩn bị sẵn các giao dịch trước lượt tạo khối của họ, điều này có thể làm giảm độ trễ xếp hàng trong khi vẫn để lại các vấn đề riêng biệt như tắc nghẽn, cạnh tranh phí, rớt giao dịch và MEV.

Việc chuyển tiếp giao dịch nhận biết leader thay đổi cách các giao dịch tiếp cận các leader đã lên lịch, nhưng nó không loại bỏ tắc nghẽn, cạnh tranh phí ưu tiên, MEV, giao dịch bị rớt hoặc áp lực tài nguyên của trình xác thực. Phí cơ bản và phí ưu tiên hiện tại nên được đo lường trực tiếp thay vì chuyển đổi sang một lượng USD cố định.

Việc không có mempool làm thay đổi mô hình gửi giao dịch đối với các nhà phát triển xây dựng trên Solana. Các giao dịch có lộ trình chuyển tiếp có thể dự đoán được, cho phép xác nhận lạc quan trước khi hoàn tất hoàn toàn. Phạm vi MEV trên Solana nhỏ hơn đáng kể so với trên Ethereum, mặc dù không phải bằng không; việc sắp xếp giao dịch theo trọng số stake tạo ra các động lực riêng mà các nhà thiết kế dApp nên nghiên cứu trước khi xây dựng.

Sealevel: Thực thi song song Hợp đồng Thông minh

Sealevel là môi trường thực thi song song Hợp đồng Thông minh của Solana, công cụ chạy các chương trình Trên chuỗi (thuật ngữ của Solana cho những gì Ethereum gọi là Hợp đồng Thông minh). Không giống như EVM của Ethereum, thực thi các hợp đồng một cách tuần tự từng cái một, Sealevel thực thi hàng nghìn chương trình không xung đột đồng thời trên các lõi GPU và CPU hiện có.

EVM của Ethereum xử lý các Hợp đồng Thông minh giống như một làn thanh toán duy nhất tại cửa hàng tạp hóa: mỗi lần một giao dịch, mọi người mua hàng đều phải đợi người phía trước. Sealevel mở đồng thời hai mươi làn thanh toán, chạy các giao dịch không xung đột song song. Đây là lý do kiến trúc chính khiến thông lượng của Solana vượt xa Ethereum ở lớp cơ sở.

Tính song song có thể thực hiện được vì mô hình lập trình của Solana yêu cầu mọi giao dịch phải khai báo, tại thời điểm gửi, các tài khoản (các đối tượng trạng thái lưu trữ dữ liệu trên Solana) mà nó sẽ đọc và ghi. Sealevel phân tích các danh sách truy cập tài khoản này để xác định các giao dịch không xung đột: những giao dịch chạm vào các tài khoản hoàn toàn khác nhau có thể chạy đồng thời mà không tạo ra các thay đổi trạng thái xung đột. Các giao dịch chia sẻ tài khoản phải thực hiện tuần tự. Runtime của Sealevel sử dụng khai báo này để lập lịch thực thi song song hoặc tuần tự trên các lõi phần cứng có sẵn.

Các chương trình Trên chuỗi chủ yếu được viết bằng Rust, được biên dịch sang mã bytecode Berkeley Packet Filter (BPF) và được thực thi bởi runtime của Sealevel. Việc thực thi song song trên các lõi GPU và CPU là điều làm cho mức 65.000 TPS lý thuyết có thể đạt được về mặt vật lý ở cấp độ phần cứng.

Ý nghĩa đối với các nhà xây dựng

Khi bạn triển khai một chương trình trên Solana, bạn phải khai báo tất cả các tài khoản mà chương trình của bạn sẽ đọc và ghi tại thời điểm gửi giao dịch. Danh sách truy cập tài khoản này không phải là tùy chọn; nó là cơ chế Sealevel sử dụng để lập lịch thực thi song song. Việc bỏ sót hoặc khai báo sai tài khoản sẽ gây ra lỗi giao dịch.

Các chương trình chia sẻ trạng thái với các chương trình khác (ghi vào cùng một tài khoản) không thể hưởng lợi từ tính song song và sẽ luôn thực thi tuần tự. Hãy thiết kế cấu trúc tài khoản của chương trình để giảm thiểu trạng thái chia sẻ bất cứ khi nào có thể. Các chương trình có mô hình truy cập tài khoản hẹp, không chồng chéo sẽ mang lại lợi ích cao nhất từ trình lập lịch song song của Sealevel.

Khung Anchor, một bộ công cụ dựa trên Rust cung cấp các macro và trừu tượng hóa giúp đơn giản hóa các mô hình chương trình phổ biến, là bộ công cụ phát triển được sử dụng rộng rãi nhất cho các chương trình Solana. Để biết tài liệu đầy đủ về mô hình tài khoản, địa chỉ dẫn xuất từ chương trình (PDA) và runtime của Sealevel, hãy xem tài liệu dành cho nhà phát triển Solana.

Pipelining: Xác thực giao dịch dưới dạng dây chuyền lắp ráp

Một dây chuyền lắp ráp ô tô không đóng xong hoàn toàn một chiếc xe trước khi bắt đầu chiếc tiếp theo. Mỗi trạm (hàn, sơn, lắp nội thất) làm việc trên một chiếc xe khác nhau một cách đồng thời. Solana áp dụng logic tương tự này cho việc xác thực giao dịch thông qua Tối ưu hóa xác thực giao dịch (TVO).

Pipelining trong Solana đề cập đến TVO, một ứng dụng của kiến trúc đường ống CPU vào xử lý giao dịch Blockchain. Quá trình xác thực giao dịch được chia thành bốn giai đoạn riêng biệt, mỗi giai đoạn được xử lý bởi một đơn vị phần cứng riêng biệt hoạt động đồng thời. Trong khi một lô giao dịch di chuyển qua một giai đoạn, lô tiếp theo đã ở giai đoạn trước đó.

Bốn giai đoạn là:

1. Fetch (Lấy dữ liệu): một đơn vị không gian nhân (kernel-space) truy xuất dữ liệu giao dịch đến từ mạng
2. Signature Verification (Xác minh chữ ký - SigVerify): GPU xác minh các chữ ký mã hóa trên toàn bộ lô một cách song song
3. Banking (Ngân hàng): CPU xử lý logic giao dịch, kiểm tra số dư tài khoản và cập nhật trạng thái tài khoản
4. Write Confirmation (Xác nhận ghi): đĩa ghi lại các thay đổi trạng thái đã hoàn tất

Trong khi lô A đang ở giai đoạn Banking, lô B đang ở SigVerify và lô C đang được Fetch. Không có phần cứng nào ở không để đợi lô trước đó kết thúc. Việc dàn giai đoạn liên tục này giúp loại bỏ thời gian CPU nhàn rỗi giữa các giai đoạn xử lý mà nếu không có nó sẽ làm giới hạn thông lượng.

Pipelining là một trong ba trụ cột, cùng với Sealevel và Gulf Stream, cùng nhau tạo ra tổng công suất xử lý giao dịch của Solana. Solana trích xuất nhiều thông lượng hơn từ cùng một phần cứng bằng cách giữ cho mọi thành phần xử lý luôn làm việc, thay vì để bất kỳ giai đoạn nào nhàn rỗi giữa các lô.

Cloudbreak: Cơ sở dữ liệu tài khoản được mở rộng theo chiều ngang

Cloudbreak là hệ thống tệp cho phép các bộ xử lý song song của Solana đọc và ghi dữ liệu tài khoản đồng thời mà không cần xếp hàng. Nếu không có nó, lớp lưu trữ sẽ tuần tự hóa tất cả các lần đọc và ghi tài khoản, và những lợi ích về tính song song của Sealevel sẽ tan biến tại ranh giới cơ sở dữ liệu.

Cloudbreak là cơ sở dữ liệu tài khoản được mở rộng theo chiều ngang của Solana: cấu trúc dữ liệu lưu trữ trạng thái của mọi tài khoản trên mạng. Nó sử dụng các tệp được ánh xạ bộ nhớ (memory-mapped files) và cấu trúc dữ liệu được tinh chỉnh cho ổ SSD để hỗ trợ đọc và ghi đồng thời trên nhiều luồng cùng lúc.

Các tài khoản được phân bổ trên nhiều cấu trúc dữ liệu có thể truy cập song song. I/O ánh xạ bộ nhớ của hệ điều hành cho phép Cloudbreak xử lý dữ liệu tài khoản thường trú trên đĩa như thể nó ở trong RAM, loại bỏ độ trễ tìm kiếm và cho phép truy cập đồng thời cấp độ luồng. Khi Sealevel lập lịch 10.000 giao dịch song song, Cloudbreak phục vụ 10.000 lượt đọc và ghi tài khoản đồng thời mà không cần xếp các yêu cầu vào hàng đợi tuần tự.

Kiến trúc cơ sở dữ liệu và runtime thực thi phụ thuộc lẫn nhau: không cái nào mang lại thông lượng cao mà thiếu cái kia. Mô hình I/O của Cloudbreak yêu cầu ổ SSD NVMe hiệu suất cao. Các ổ đĩa quay tiêu chuẩn không thể duy trì thông lượng đọc/ghi ngẫu nhiên mà mô hình truy cập đồng thời của Cloudbreak yêu cầu. Hiểu mô hình tài khoản của Cloudbreak là nền tảng cho thiết kế chương trình Solana: tất cả trạng thái nằm trong các đối tượng tài khoản riêng biệt, các chương trình hoạt động phi trạng thái trên các tài khoản đó và các quyết định về bố cục tài khoản ảnh hưởng trực tiếp đến hiệu suất đọc/ghi trong quá trình thực thi.

Archivers: Một đề xuất lưu trữ lịch sử

Khái niệm Archivers xuất hiện trong các tài liệu kiến trúc Solana thời kỳ đầu nhưng không nên được trình bày như một hệ thống con sản xuất hiện đang được triển khai nếu không có bằng chứng nguồn sơ cấp hiện tại.

Các tài liệu thiết kế ban đầu đã đề xuất Archivers, còn được gọi là Replicators trong một số mô tả, như các thành phần tham gia nhẹ lưu trữ các phần của dữ liệu sổ cái lịch sử và chứng minh việc lưu trữ. Điều này giải thích cách tiếp cận ban đầu đối với sự phát triển của sổ cái, nhưng nó không nên được mô tả như một mạng sản xuất mang lại phần thưởng đang hoạt động mà không có xác nhận nguồn sơ cấp hiện tại. Cơ sở hạ tầng lưu trữ và duy trì sổ cái hiện tại phải được ghi chép riêng biệt.

Với tất cả tám trụ cột kiến trúc được thiết lập, hệ thống kết hợp tạo ra các tiêu chuẩn hiệu suất giúp phân biệt Solana với hầu hết các Blockchain công khai khác, điều mà phần tiếp theo sẽ định lượng.

Tiêu chuẩn hiệu suất của Solana: TPS, phí và tính hoàn tất của khối

~65.000 TPS trong các tiêu chuẩn lý thuyết lịch sử là mức tối đa lý thuyết của Solana trong các điều kiện phòng thí nghiệm tối ưu, không phải là con số thực tế duy trì được. Sự khác biệt này quan trọng đối với bất kỳ ai sử dụng những con số này trong phân tích đầu tư hoặc thiết kế hệ thống.

Sử dụng các nguồn sơ cấp hiện tại và phương pháp đo lường nhất quán để so sánh hiệu suất.

Thông lượng Mainnet trong thế giới thực thấp hơn mức tối đa lý thuyết vì một số lý do. Không phải tất cả các vị trí giao dịch (transaction slots) đều được lấp đầy hoàn toàn trong điều kiện nhu cầu bình thường. Các cơ chế lọc thư rác từ chối các giao dịch chất lượng thấp trước khi chúng đến giai đoạn Banking. Các điều kiện mạng ảnh hưởng đến thời gian lan truyền. Việc tiếp cận trần lý thuyết đòi hỏi nhu cầu cao điểm được duy trì kết hợp với việc tận dụng tối đa phần cứng trên toàn bộ bộ trình xác thực, những điều kiện thường xảy ra trong các sự kiện lưu lượng truy cập cao cụ thể thay vì diễn ra liên tục.

Đặc tính thông lượng của Solana đến từ một vài nguồn kiến trúc hoạt động cùng nhau. PoH cung cấp một tham chiếu thứ tự có thể kiểm chứng giúp giảm thiểu chi phí điều phối thời gian. Sealevel thực thi song song các tác vụ không xung đột. Việc chuyển tiếp nhận biết leader có thể dàn xếp các giao dịch trước khi một slot block mở ra, giúp giảm bớt một số hàng đợi Mempool truyền thống mà không loại bỏ độ trễ mạng.

Hệ sinh thái Layer-2 của Ethereum (bao gồm Arbitrum và Optimism) cùng các nâng cấp sharding trong tương lai làm tăng thông lượng thực tế của Ethereum vượt xa con số của lớp cơ sở. Bất kỳ sự so sánh đầy đủ nào cũng nên tính đến khả năng mở rộng đó khi đánh giá hai Nền tảng cho một trường hợp sử dụng cụ thể.

Từ Kiến trúc đến Ứng dụng: Cách Thiết kế của Solana Kích hoạt các Trường hợp Sử dụng Thực tế

Các lựa chọn kiến trúc của Solana tạo ra những kết quả cụ thể, có thể đo lường được cho các ứng dụng được xây dựng trên Top của chúng, chứ không phải là những con số hiệu suất trừu tượng.

NFT: Phí của Solana nhìn chung thấp và việc thực thi song song có thể hỗ trợ đúc tiền với khối lượng lớn, nhưng phí ưu tiên, chi phí ứng dụng, tình trạng tắc nghẽn, lỗi và các tiêu chuẩn tài sản vẫn đóng vai trò quan trọng. Gulf Stream không loại bỏ sự cạnh tranh về phí.

DeFi: Runtime của Solana có thể xử lý song song các giao dịch không xung đột, trong khi phí thường thấp có thể hỗ trợ các tương tác thường xuyên. Độ trễ và chi phí hoán đổi thực tế bao gồm định tuyến, trượt giá, phí ưu tiên, giao dịch thất bại, tính toán chương trình và các điều kiện thị trường. Gulf Stream không loại bỏ rủi ro MEV hoặc chạy trước (front-running).

GameFi và các giao dịch vi mô: Phí nhìn chung thấp có thể hỗ trợ các hành động giá trị nhỏ, nhưng tổng chi phí ứng dụng và các giao dịch thất bại vẫn quan trọng. Chi phí Ethereum L1 và L2 nên được so sánh riêng biệt bằng cách sử dụng dữ liệu hiện tại.

Thanh toán: Các ứng dụng thanh toán dựa trên Solana có thể hướng tới phản hồi người dùng nhanh chóng, nhưng phê duyệt ví, xác nhận lạc quan, tính hoàn thiện gốc, khả năng chịu rủi ro của người bán và các hoạt động Ngoài chuỗi là các giai đoạn riêng biệt. Việc ủy quyền thẻ tín dụng không tương đương với Quyết toán trên blockchain công khai.

Cùng những lựa chọn kiến trúc cho phép các ứng dụng này cũng đi kèm với những đánh đổi đã được ghi nhận, điều mà phần tiếp theo sẽ xem xét một cách trực diện.

Đánh đổi Kiến trúc: Độ tin cậy của Mạng, Tính phi tập trung và Tốc độ

Solana đã trải qua các sự cố ngừng hoạt động mạng được ghi nhận kể từ khi ra mắt Mainnet vào tháng 3 năm 2020, chủ yếu do các đợt lũ giao dịch do Bot tạo ra làm quá tải bộ nhớ trình xác thực và khiến các trình xác thực mất đồng thuận.

Sự cố Ngừng hoạt động Mạng

Thiết kế thông lượng cao của Solana xử lý các giao dịch với bộ lọc trước tối thiểu, điều này tạo ra một lỗ hổng cụ thể. Khi các Bot làm tràn mạng bằng các giao dịch rác (spam), các trình xác thực có thể cạn kiệt bộ nhớ khả dụng trước khi các giao dịch đến giai đoạn lọc, gây ra tình trạng đình trệ đồng thuận. Các đợt ngừng hoạt động lớn đã được ghi nhận bao gồm đợt ngừng hoạt động vào tháng 9 năm 2021 kéo dài khoảng 17 giờ, được kích hoạt bởi sự gia tăng khối lượng giao dịch từ một sự kiện IDO do Bot điều khiển, và đợt ngừng hoạt động vào tháng 1 năm 2022 liên quan đến các giao dịch trùng lặp quá mức từ các trình xác thực. Các đợt ngừng hoạt động ngắn hơn khác đã xảy ra vào năm 2022 và 2023.

Solana Labs đã triển khai hai biện pháp giảm thiểu kiến trúc chính. Giao thức mạng QUIC đã thay thế UDP cho việc tiếp nhận giao dịch, cung cấp khả năng kiểm soát luồng ở cấp độ kết nối nhằm giới hạn số lượng giao dịch mà bất kỳ nguồn đơn lẻ nào có thể gửi. Chất lượng Dịch vụ (QoS) theo trọng số Staking ưu tiên chuyển tiếp giao dịch từ các trình xác thực có lượng SOL Staking lớn hơn, làm cho việc làm tràn thư rác từ các nguồn Staking thấp trở nên kém hiệu quả hơn. Thị trường phí cho các đơn vị tính toán tạo ra lực cản kinh tế đối với thư rác ở khối lượng lớn. Tần suất ngừng hoạt động đã giảm kể từ khi các biện pháp giảm thiểu này được triển khai. Lịch sử ngừng hoạt động vẫn là một yếu tố rủi ro đã biết đối với các ứng dụng yêu cầu tính khả dụng cao liên tục.

Mối lo ngại về sự Tập trung hóa của Trình xác thực

Các trình xác thực Solana yêu cầu phần cứng đáng kể. Theo tài liệu về trình xác thực của Solana Foundation,), cấu hình được đề xuất bao gồm RAM 128+ GB, ổ SSD NVMe hiệu suất cao và kết nối internet băng thông cao. Hãy xác minh các thông số hiện tại tại thời điểm đọc, vì các yêu cầu sẽ phát triển cùng với các lần nâng cấp giao thức. Những yêu cầu này vượt xa đáng kể so với những gì các trình xác thực Ethereum cần để tham gia vào đồng thuận PoS.

Rào cản phần cứng làm giảm nhóm trình xác thực tiềm năng xuống còn những nhà vận hành có vốn đầu tư đáng kể. Các yêu cầu phần cứng phục vụ một mục đích kỹ thuật thực sự: chúng là yếu tố mà các mục tiêu thông lượng hiện tại phụ thuộc vào. Chúng cũng là một rào cản thực sự đối với việc tham gia rộng rãi hơn của các trình xác thực. Solana Foundation tài trợ cho các chương trình phi tập trung hóa trình xác thực và các khoản tài trợ cho các nhà vận hành nhỏ hơn, nhưng sự căng thẳng giữa các mục tiêu hiệu suất và chi phí phần cứng là một đặc điểm cấu trúc của thiết kế, không phải là vấn đề chính sách ngẫu nhiên.

Định vị trong Bộ ba bất khả thi của Blockchain

Solana không loại bỏ Bộ ba bất khả thi của Blockchain. Kiến trúc của nó đại diện cho một lựa chọn có chủ ý nhằm ưu tiên khả năng mở rộng và duy trì tính bảo mật, đồng thời chấp nhận các yêu cầu phần cứng trình xác thực cao hơn tạo ra áp lực lên tính phi tập trung. Ethereum ưu tiên tính phi tập trung và bảo mật, giải quyết khả năng mở rộng thông qua các giải pháp Layer-2. Bitcoin ưu tiên bảo mật và tính phi tập trung với cái giá là thông lượng tối thiểu. Mỗi chuỗi chiếm một Vị thế kỹ thuật khác nhau trong cùng một bộ ba bất khả thi và không có cấu hình nào tối đa hóa đồng thời cả ba chiều.

Lịch sử ngừng hoạt động, áp lực tập trung hóa từ các yêu cầu phần cứng trình xác thực và vị trí trong bộ ba bất khả thi là những đầu vào quan trọng cho bất kỳ đánh giá kỹ thuật khắt khe nào về mạng Solana.

Solana so với Ethereum so với Bitcoin: So sánh Kiến trúc

Các tiêu chuẩn lịch sử cho thấy Solana có đặc tính thông lượng lớp cơ sở cao hơn Ethereum Mainnet, nhưng các phép đo không tương đồng với nhau. PoH cung cấp thứ tự trước đồng thuận, Sealevel chạy đồng thời các tác vụ không xung đột và việc chuyển tiếp nhận biết leader thay đổi cách định tuyến giao dịch. Các con số ~65.000 và ~15–30 TPS thường được trích dẫn là các điểm tham chiếu lỗi thời, phụ thuộc vào phương pháp luận chứ không phải là các đặc tính vĩnh viễn của mạng.

Thông lượng và mô hình thực thi

EVM của Ethereum thực thi các hợp đồng một cách tuần tự, từng cái một trên mỗi khối. Sealevel thực thi hàng nghìn hợp đồng không xung đột cùng một lúc. Đây là nguồn chính tạo ra khoảng cách TPS. Ethereum giải quyết thông lượng thông qua mở rộng Layer-2: các Rollups bao gồm Arbitrum và Optimism xử lý các giao dịch Ngoài chuỗi và Quyết toán các đợt nén trên lớp cơ sở Ethereum, làm tăng đáng kể công suất thực tế. Cách tiếp cận của Solana là mở rộng theo chiều ngang ở Layer-1, tránh sự phức tạp bổ sung mà các kiến trúc Layer-2 gây ra cho nhà phát triển và người dùng.

So sánh nền tảng nhà phát triển

Hệ sinh thái nhà phát triển của Ethereum (Solidity, công cụ EVM, các giao thức DeFi đã thiết lập với nhiều năm mã nguồn được kiểm toán) lớn hơn và trưởng thành hơn so với Solana. Mô hình Rust và Sealevel của Solana cung cấp thông lượng lớp cơ sở cao hơn và phí thấp hơn, nhưng yêu cầu hiểu mô hình tài khoản và yêu cầu khai báo quyền truy cập tài khoản, điều không có đối tác trực tiếp trong Ethereum. Các ứng dụng mà thông lượng và chi phí phí là các ràng buộc chính sẽ phù hợp tốt với kiến trúc của Solana. Các ứng dụng ưu tiên khả năng tương thích EVM, nhóm tài năng nhà phát triển rộng nhất hoặc tính phi tập trung lớp cơ sở tối đa sẽ phù hợp hơn với lớp cơ sở của Ethereum hoặc hệ sinh thái L2 của nó.

Bitcoin là điểm tham chiếu thứ ba

Kiến trúc của Bitcoin ưu tiên bảo mật và tính phi tập trung hơn thông lượng. Với ~7 TPS và thời gian tạo khối 10 phút, Bitcoin không được thiết kế cho các ứng dụng tần suất cao. Đồng thuận Proof of Work của nó tiêu tốn nhiều tài nguyên tính toán theo thiết kế: bảo mật thông qua tiêu thụ năng lượng thay vì Staking kinh tế. Cả Solana và Ethereum đều cung cấp các Nền tảng Hợp đồng Thông minh có thể lập trình mà Bitcoin không hỗ trợ nguyên bản. Vị thế kiến trúc của Bitcoin làm cho nó trở thành một loại hệ thống khác hơn là một đối thủ cạnh tranh trực tiếp cho việc triển khai ứng dụng.

Để so sánh dữ liệu đầy đủ trên cả năm khía cạnh, hãy xem bảng chuẩn hiệu suất ở trên.

Câu hỏi Thường gặp về Kiến trúc Solana

Proof of History trong Solana là gì?

Proof of History (PoH) là một chuỗi băm SHA-256 tuần tự tạo ra một bản ghi các sự kiện có thể xác minh, được sắp xếp theo thời gian trước khi quá trình đồng thuận diễn ra. Nó hoạt động như một đồng hồ mật mã chung trên toàn bộ mạng lưới validator, cho phép các validator xử lý giao dịch mà không cần trao đổi tin nhắn dấu thời gian. PoH không phải là Cơ chế đồng thuận của Solana. Tower BFT xử lý sự đồng thuận, sử dụng dấu thời gian PoH làm tham chiếu thời gian chung.

Solana có thể xử lý bao nhiêu giao dịch mỗi giây?

Các tài liệu lịch sử trích dẫn các phạm vi TPS lý thuyết và quan sát được, nhưng thông lượng thực tế phụ thuộc vào sự kết hợp giao dịch, kế toán bỏ phiếu, lọc, tắc nghẽn, phần mềm validator và phương pháp đo lường. Hãy sử dụng dữ liệu nguồn chính hiện tại và xác định rõ những gì đang được tính toán.

Solana được đồng sáng lập bởi Anatoly Yakovenko và Greg Fitzgerald. Yakovenko, một cựu kỹ sư Qualcomm từng làm việc về các hệ thống phân tán và đồng bộ hóa đồng hồ, lần đầu tiên mô tả cơ chế Proof of History trong một Whitepaper vào tháng 11 năm 2017. Solana Labs, công ty phát triển vì lợi nhuận do họ đồng sáng lập, dẫn đầu về kỹ thuật giao thức. Solana Foundation, một tổ chức phi lợi nhuận riêng biệt có trụ sở tại Geneva, hỗ trợ phát triển hệ sinh thái.

Một số lớp kiến trúc góp phần tạo nên sự khác biệt về hiệu suất. PoH cung cấp một tham chiếu thứ tự có thể xác minh giúp giảm bớt một số chi phí điều phối, Sealevel thực hiện các công việc không xung đột song song và việc chuyển tiếp nhận biết leader làm thay đổi cách thức giao dịch tiếp cận các validator đã lên lịch. Các số liệu TPS lịch sử phụ thuộc vào phương pháp luận và không nên được coi là các đặc tính vĩnh viễn của cả hai mạng lưới.

Các tài liệu ban đầu nhóm kiến trúc thành Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak và Archivers. Đây là một khung giải thích lịch sử, không phải là bằng chứng cho thấy mỗi hạng mục được nêu tên—đặc biệt là Archivers—vẫn là một hệ thống con được triển khai riêng biệt ngày nay.

Tower BFT là cơ chế lựa chọn Fork và bỏ phiếu dựa trên trọng số stake của Solana, được xây dựng xung quanh các slot PoH và tăng dần thời gian khóa bỏ phiếu (vote lockout). Đừng giả định một việc triển khai slashing tự động cụ thể hoặc tính các validator bằng nhau: các ngưỡng Byzantine được tính theo trọng số stake, và các giả định về tính an toàn và tính khả dụng cần được xử lý chính xác hơn.

Gulf Stream mô tả việc chuyển tiếp giao dịch nhận biết leader thay vì một Mempool toàn cầu thông thường. Nó có thể giảm bớt một số hàng đợi, nhưng không loại bỏ sự cạnh tranh phí ưu tiên, tắc nghẽn, rớt giao dịch, MEV hoặc rủi ro front-running. Hành vi mạng hiện tại nên được xác minh từ tài liệu triển khai.

Sealevel là môi trường thực thi Hợp đồng Thông minh song song của Solana. Không giống như EVM của Ethereum thực thi các hợp đồng lần lượt, Sealevel chạy hàng nghìn chương trình không xung đột đồng thời trên các lõi CPU và GPU có sẵn. Tính song song được thực hiện bằng cách yêu cầu mọi giao dịch phải khai báo các tài khoản mà nó sẽ truy cập tại thời điểm gửi, do đó môi trường thực thi có thể xác định các hoạt động không xung đột và lập lịch cho chúng đồng thời.

Có. Solana sử dụng Proof of Stake (PoS) làm lớp bảo mật kinh tế của mình. Các validator stake SOL làm tài sản thế chấp và phải đối mặt với các hình phạt slashing cho hành vi không trung thực hoặc không nhất quán. Proof of History là một cơ chế chấm công mật mã riêng biệt giúp quá trình đồng thuận PoS của Solana nhanh hơn. PoH không thay thế PoS; nó nâng cao hiệu quả của Tower BFT, cơ chế đồng thuận dựa trên PoS.

Các sự cố ngừng hoạt động đã được ghi nhận của Solana chủ yếu do lưu lượng giao dịch do bot tạo ra tràn ngập bộ nhớ validator, khiến các validator rơi ra ngoài sự đồng thuận. Thiết kế thông lượng cao của kiến trúc này xử lý các giao dịch với bộ lọc sơ bộ tối thiểu, tạo ra lỗ hổng cho các cuộc tấn công spam quy mô lớn. Solana Labs đã triển khai mạng QUIC và QoS dựa trên trọng số stake như các biện pháp giảm thiểu kiến trúc giúp giảm tần suất ngừng hoạt động. Xem phần đánh đổi kiến trúc để biết các sự kiện cụ thể đã được ghi lại.

Sự khác biệt cốt lõi về kiến trúc là mô hình thực thi (Sealevel song song so với EVM tuần tự), định tuyến giao dịch (Gulf Stream không có Mempool so với Mempool toàn cầu), ngôn ngữ lập trình (Rust so với Solidity) và thông lượng lớp cơ sở (~65.000 TPS lý thuyết so với ~15–30 TPS). Cả hai Blockchain đều sử dụng Proof of Stake để bảo mật kinh tế. Hệ sinh thái nhà phát triển lớn hơn và các lựa chọn Layer-2 của Ethereum phục vụ tốt cho các dự án tương thích với EVM; thông lượng lớp cơ sở và cấu trúc phí của Solana phục vụ các ứng dụng mà khối lượng giao dịch và chi phí là những ràng buộc chính.

Không có giải pháp hoàn chỉnh cho Bộ ba bất khả thi của Blockchain; thay vào đó, Solana thực hiện các sự đánh đổi. Kiến trúc ưu tiên khả năng mở rộng và duy trì bảo mật, đồng thời chấp nhận các yêu cầu phần cứng validator cao hơn tạo ra áp lực có thể đo lường được đối với tính phi tập trung. Đây là một quan điểm kỹ thuật cụ thể trong bộ ba bất khả thi, không phải là sự loại bỏ nó. Vị thế của Solana cực kỳ tích cực trên trục khả năng mở rộng so với các Blockchain lớn khác.

Các chương trình Trên chuỗi của Solana chủ yếu được viết bằng Rust, được biên dịch thành mã byte Berkeley Packet Filter (BPF) và được thực thi bởi môi trường thực thi Sealevel. C và C++ cũng được hỗ trợ. Khung Anchor, một bộ công cụ dựa trên Rust cung cấp các macro và trừu tượng hóa giúp đơn giản hóa các mẫu chương trình phổ biến, là bộ công cụ phát triển được sử dụng rộng rãi nhất. Để biết các công cụ hệ sinh thái hiện tại, hãy xem tài liệu dành cho nhà phát triển Solana.

Chi phí giao dịch Solana bao gồm một Phí cơ sở và có thể bao gồm phí ưu tiên cùng các chi phí liên quan đến tính toán. Giá trị USD thay đổi theo giá SOL, trong khi tình trạng tắc nghẽn và hành vi ứng dụng ảnh hưởng đến tổng chi phí thực thi. Gulf Stream không loại bỏ sự cạnh tranh về phí.

Tính đến thời điểm viết bài, Solana có hơn 1.000 validator đang hoạt động. Xác minh số lượng và sự phân bổ hiện tại thông qua thống kê validator của Solana Foundation.). Các validator yêu cầu đầu tư phần cứng đáng kể, bao gồm hơn 128 GB RAM và ổ SSD NVMe hiệu suất cao, tạo ra rào cản gia nhập cao hơn so với hầu hết các chuỗi Proof of Stake khác và là nguồn gốc chính của những lo ngại đang diễn ra về tính phi tập trung.

Khám phá SOL trên Bybit

Người đọc có thể xem lại thông tin thị trường SOL hiện tại) hoặc thị trường Giao ngay SOL/USDT.). Các liên kết này cung cấp quyền truy cập thị trường và không chứng minh rằng Solana, ví hoặc giao thức của Bên thứ ba là phù hợp với mọi người đọc.

Điểm mấu chốt: Kiến trúc của Solana có ý nghĩa gì đối với Hệ sinh thái Web3

Kiến trúc của Solana kết hợp một số quyết định thiết kế có mối liên kết chặt chẽ với nhau. PoH cung cấp tham chiếu thứ tự, Sealevel song song hóa việc thực thi không xung đột, chuyển tiếp nhận biết leader thay đổi định tuyến giao dịch, còn pipelining, Cloudbreak và Turbine giải quyết việc xử lý, lưu trữ và lan truyền. Lịch sử ngừng hoạt động đã được ghi nhận và các yêu cầu về tài nguyên validator nằm trong cùng một đánh giá kỹ thuật với các lợi ích về hiệu suất.

Đối với các nhà phát triển đang lựa chọn một nền tảng, Solana cung cấp thông lượng lớp cơ sở cao nhất và nằm trong số các mức phí giao dịch thấp nhất so với bất kỳ blockchain sản xuất lớn nào. Mô hình tài khoản và yêu cầu Rust làm tăng độ phức tạp trong thiết kế so với EVM của Ethereum. Yêu cầu khai báo truy cập tài khoản thay đổi cách bạn cấu trúc trạng thái chương trình và mô hình thực thi song song ưu tiên các thiết kế chương trình giảm thiểu trạng thái chia sẻ.

Đối với các nhà nghiên cứu, bản gốc Proof of History: A Clock for Blockchain (Tháng 11 năm 2017) của Anatoly Yakovenko vẫn là nguồn sơ cấp nền tảng cho thiết kế PoH. Solana Labs duy trì tài liệu kiến trúc hiện tại tại docs.solana.com. Solana Foundation công bố số liệu thống kê mạng lưới trình xác thực tại solana.org/validators. Dữ liệu mạng thời gian thực có sẵn thông qua Solana Beach.

Với sự hiểu biết về tám trụ cột kiến trúc của Solana, giờ đây bạn đã được trang bị để tự mình đánh giá các tuyên bố về hiệu suất, các sự đánh đổi và lộ trình Long-hạn của mạng lưới.

Miễn trừ trách nhiệm: Bài viết này chỉ dành cho mục đích thông tin và giáo dục. Nó không cấu thành lời khuyên tài chính, lời khuyên đầu tư hoặc khuyến nghị mua, bán hoặc nắm giữ SOL hoặc bất kỳ tiền điện tử nào khác. Tất cả các con số về hiệu suất có thể thay đổi. Hãy tham khảo ý kiến của cố vấn tài chính có trình độ trước khi đưa ra quyết định đầu tư.

Bài đọc liên quan

• Solana Proof of History
• Cơ chế đồng thuận Solana
• SolanaVM
• Tốc độ Solana