Giải thích về SolanaVM: Máy ảo Solana

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

SolanaVM (còn được gọi là Máy ảo Solana hoặc SVM) là môi trường thực thi của blockchain Solana: lớp phần mềm xử lý và chạy các chương trình Trên chuỗi. Nó đảm nhận việc tính toán, thực thi logic chương trình và cam kết kết quả trở lại mạng lưới. SolanaVM không phải là một sản phẩm hoặc token riêng biệt; nó là công cụ thực thi cốt lõi được tích hợp vào giao thức Solana.**

Lưu ý về thuật ngữ: Trong bối cảnh blockchain, SVM là viết tắt của Solana Virtual Machine. SVM cũng là viết tắt của Support Vector Machine, một thuật ngữ thuật toán máy học không liên quan đến blockchain. Trong suốt bài viết này, SVM chỉ đề cập đến Máy ảo Solana.

Nội dung: Cách SolanaVM hoạt động | SolanaVM so với EVM | Xây dựng trên SolanaVM | Chấp nhận đa chuỗi | Sự phát triển của việc chấp nhận SolanaVM | Câu hỏi thường gặp

Blockchain là một Sổ lệnh phân tán ghi lại các giao dịch trên một mạng lưới máy tính mà không phụ thuộc vào một cơ quan trung ương. Các blockchain hiện đại làm được nhiều việc hơn là chỉ ghi lại việc chuyển giao giá trị. Chúng chạy các chương trình: phần mềm xử lý việc cho vay, giao dịch, quản trị và hàng nghìn chức năng Trên chuỗi khác. Để chạy các chương trình, một blockchain cần một môi trường thực thi, một lớp phần mềm được kiểm soát để nhận các hướng dẫn, xử lý chúng theo các quy tắc đã xác định và ghi kết quả Trên chuỗi. Mọi blockchain hợp đồng thông minh đều cần một môi trường thực thi. Trên Solana, môi trường đó là SolanaVM.

Solana là một blockchain Lớp 1 (Layer 1), một mạng lưới lớp cơ sở với Cơ chế đồng thuận riêng và token gốc gọi là SOL. SolanaVM không giống với Solana. Mối quan hệ này tương tự như động cơ xe hơi và chính chiếc xe đó: SolanaVM là động cơ; Solana là toàn bộ phương tiện. SOL là nhiên liệu trả tiền cho việc thực thi. Đây là ba thực thể riêng biệt, và việc gộp chung chúng lại sẽ gây ra sự nhầm lẫn thực sự khi đánh giá kiến trúc của Solana.

SolanaVM được xây dựng dựa trên triết lý thiết kế ưu tiên thông lượng, bắt nguồn trực tiếp từ Anatoly Yakovenko, người đồng sáng lập Solana và là cựu kỹ sư Qualcomm, người đã xác định chi phí vận hành sắp xếp giao dịch là điểm nghẽn chính trong các thiết kế blockchain hiện có.

Cách thức hoạt động của SolanaVM: Mô hình Kiến trúc và Thực thi

SolanaVM thực thi các chương trình Solana thông qua một đường ống năm giai đoạn chạy trên hạ tầng trình xác thực phân tán của mạng lưới, xử lý các giao dịch không xung đột song song thay vì tuần tự.

Trên SolanaVM, các hợp đồng thông minh được gọi là Solana programs (thuật ngữ SolanaVM dành cho hợp đồng thông minh). Đây là thuật ngữ chính thức của Solana Foundation, không phải là một biến thể phong cách. Sự khác biệt về tên gọi phản ánh một sự phân biệt thực sự về kiến trúc. Các hợp đồng thông minh EVM lưu trữ cả logic chương trình và dữ liệu trạng thái bên trong cùng một đối tượng hợp đồng. Các chương trình Solana là không trạng thái (stateless): mã chương trình nằm trong một tài khoản Trên chuỗi, và dữ liệu mà nó vận hành nằm trong các tài khoản dữ liệu riêng biệt. Sự tách biệt này là thứ giúp cho việc thực thi song song có tính khả thi ở quy mô lớn.

Đường ống thực thi SolanaVM tuân theo năm giai đoạn:

1. Một nhà phát triển viết một chương trình Solana bằng Rust
2. Mã Rust được biên dịch thành bytecode sBPF
3. Bytecode đã biên dịch được triển khai dưới dạng một tài khoản chương trình Trên chuỗi
4. Một người dùng gửi một giao dịch gọi chương trình với dữ liệu hướng dẫn
5. Các trình xác thực Solana (các nút mạng chạy SolanaVM) thực thi bytecode sBPF, tiêu thụ các đơn vị tính toán và cam kết kết quả vào sổ cái

Các trình xác thực Solana chạy SolanaVM trên phần cứng chuyên dụng và đạt được đồng thuận thông qua hai cơ chế riêng biệt: Proof of History (PoH) để sắp xếp giao dịch, và Tower BFT, một Cơ chế đồng thuận Bằng chứng Stake, để xác thực kết quả. Mạng lưới trình xác thực của Solana được bảo mật bởi Tower BFT. Trong khi PoH sắp xếp các giao dịch, Tower BFT quyết định sự đồng thuận về tính hợp lệ của chúng. Đây là các vai trò riêng biệt và không được đánh tráo.

Proof of History (Bằng chứng lịch sử) là một cơ chế sắp xếp mật mã được phát minh bởi Anatoly Yakovenko, được trình bày chi tiết trong Whitepaper Solana Proof of History.). PoH hoạt động như một chiếc đồng hồ đồng bộ cho phép tất cả các trình xác thực đồng ý về thời điểm mỗi giao dịch xảy ra mà không cần phải bán (hỏi) lẫn nhau, loại bỏ một điểm nghẽn phối hợp lớn. Bằng cách sắp xếp trước các giao dịch bằng mật mã, PoH cung cấp cho SolanaVM nền tảng thời gian cần thiết để xử lý nhiều giao dịch cùng một lúc. PoH không phải là một Cơ chế đồng thuận; nó là một giao thức đánh dấu thời gian và sắp xếp cung cấp dữ liệu cho sự đồng thuận Tower BFT.

sBPF là gì? Định dạng Bytecode của SolanaVM

sBPF (Solana Berkeley Packet Filter) là định dạng bytecode mà SolanaVM thực thi: phiên bản sửa đổi của Solana từ bộ hướng dẫn Berkeley Packet Filter, được điều chỉnh đặc biệt cho việc thực thi chương trình blockchain.

Khi một nhà phát triển viết một chương trình Solana bằng Rust, mã Rust đó không chạy trực tiếp Trên chuỗi. Trình biên dịch Rust chuyển đổi nó thành bytecode sBPF, một định dạng hướng dẫn cấp thấp, nhỏ gọn mà công cụ thực thi của SolanaVM có thể xử lý hiệu quả. Các trình xác thực thực thi bytecode sBPF trực tiếp; đây là nơi việc tính toán thực sự diễn ra trên mạng lưới.

sBPF khác biệt với BPF (Berkeley Packet Filter) nguyên bản, một công nghệ mạng được sử dụng trong các nhân hệ điều hành để lọc gói tin. sBPF của Solana là một Fork được sửa đổi để thích ứng với các hạn chế của việc thực thi máy ảo blockchain. Luôn sử dụng "sBPF" thay vì chỉ ghi "BPF" khi đề cập đến định dạng bytecode của Solana.

Đối với các nhà phát triển đến từ hệ sinh thái EVM, sBPF đóng vai trò chức năng tương tự như các mã opcode của EVM: đó là bộ hướng dẫn cấp thấp mà máy ảo giải thích và chạy.

Thực thi song song: Cách SolanaVM xử lý nhiều giao dịch đồng thời

SolanaVM xử lý các giao dịch không xung đột đồng thời thay vì từng giao dịch một, một sự thay đổi cơ bản so với mô hình thực thi tuần tự của EVM.

Hãy tưởng tượng một ngân hàng nơi mỗi giao dịch viên xử lý một khách hàng khác nhau cùng một lúc thay vì một hàng dài được phục vụ bởi một cửa duy nhất. Việc thực thi song song của SolanaVM hoạt động tương tự đối với các giao dịch không chạm vào cùng một tài khoản.

Cơ chế này là Sealevel, công cụ thực thi song song của SolanaVM. Trước khi thực thi bất kỳ giao dịch nào, Sealevel phân tích sự phụ thuộc tài khoản của mỗi giao dịch: giao dịch này đọc từ những tài khoản nào và ghi vào những tài khoản nào? Nếu hai giao dịch truy cập vào các tài khoản hoàn toàn khác nhau, chúng không có xung đột và có thể chạy đồng thời trên nhiều lõi CPU. Các giao dịch có chung tài khoản sẽ xếp hàng tuần tự cho các tài khoản cụ thể đó, trong khi tất cả các giao dịch không liên quan tiếp tục được xử lý song song.

Kết quả là một giới hạn thông lượng có thể mở rộng theo phần cứng của trình xác thực thay vì một điểm nghẽn tuần tự cố định. Thông lượng tối đa theo lý thuyết của Solana đạt khoảng 65.000 giao dịch mỗi giây trong điều kiện tối ưu, so với khoảng 15 đến 30 TPS trên Ethereum Mainnet (Nguồn: Solana Foundation, solana.com; ethereum.org, tính đến Quý 1 năm 2025). Thông lượng thực tế dưới tải thấp hơn cho cả hai mạng, và các chuỗi tương thích máy ảo Ethereum (L2) Layer 2 được xây dựng trên Ethereum đạt thông lượng cao hơn đáng kể so với chính Ethereum Mainnet.

SolanaVM và máy ảo Ethereum: So sánh hai Môi trường Thực thi

SolanaVM và máy ảo Ethereum (EVM) đại diện cho hai phương pháp kiến trúc khác nhau để thực thi chương trình blockchain, mỗi phương pháp có những đánh đổi có thể đo lường được, ưu tiên các trường hợp sử dụng khác nhau. Một tiêu chuẩn máy ảo thứ ba, WebAssembly (WASM), được sử dụng bởi các chuỗi như NEAR Protocol và Polkadot, đại diện cho một lựa chọn kiến trúc khác với cả máy ảo Ethereum và SolanaVM.

Máy ảo Ethereum (EVM): Tiêu chuẩn đã được thiết lập

Máy ảo Ethereum (EVM), ban đầu được thiết kế bởi Vitalik Buterin và nhóm Ethereum, là môi trường thực thi được chia sẻ trên Ethereum và tất cả các chuỗi tương thích máy ảo Ethereum. Toàn bộ Tài liệu về máy ảo Ethereum có sẵn trên ethereum.org.

Máy ảo Ethereum xử lý giao dịch tuần tự: từng giao dịch một, theo thứ tự nghiêm ngặt. Mọi giao dịch trong một khối đều được thực thi sau khi giao dịch trước đó hoàn thành. Các chương trình được viết bằng Solidity hoặc Vyper và được biên dịch thành các mã opcode của máy ảo Ethereum. Mô hình tuần tự này tạo ra một giới hạn thông lượng gắn liền với thời gian khối thay vì năng lực phần cứng, nhưng nó cũng đơn giản hóa việc suy luận trạng thái. Tại bất kỳ thời điểm nào của quá trình thực thi, toàn bộ trạng thái đều có tính xác định và hoàn toàn nhất quán.

Lợi thế cạnh tranh bền vững nhất của máy ảo Ethereum là hiệu ứng mạng lưới. Hơn 100 chuỗi tương thích máy ảo Ethereum, bao gồm Polygon, Arbitrum, Avalanche C-Chain và BNB Chain, chia sẻ cùng một tiêu chuẩn thực thi. Các nhà phát triển học Solidity có thể triển khai trên bất kỳ chuỗi nào tương thích máy ảo Ethereum mà không cần viết lại mã của họ. Khả năng di động này đã tích lũy trong hơn một thập kỷ, tạo ra một hệ sinh thái công cụ (Hardhat, Foundry, Remix, OpenZeppelin) và một cộng đồng nhà phát triển mà SolanaVM chưa sánh kịp về quy mô.

SolanaVM và máy ảo Ethereum: So sánh song song

SolanaVM và máy ảo Ethereum khác biệt cơ bản nhất ở cách chúng xử lý giao dịch: SolanaVM chạy các giao dịch không xung đột song song, trong khi máy ảo Ethereum xử lý giao dịch tuần tự. Bảng dưới đây ánh xạ những khác biệt kiến trúc này trên sáu chiều cốt lõi.

Các số liệu TPS đại diện cho mức tối đa theo lý thuyết trong điều kiện tối ưu và thay đổi đáng kể dưới tải mạng thực tế. Các chuỗi L2 tương thích máy ảo Ethereum đạt thông lượng cao hơn đáng kể so với Ethereum Mainnet. Cập nhật lần cuối: Quý 1 năm 2025. Nguồn: Solana Foundation (solana.com), ethereum.org.

Hiệu ứng mạng lưới của máy ảo Ethereum trên hơn 100 chuỗi là lợi thế cạnh tranh bền vững của nó. Kiến trúc thực thi song song của SolanaVM mang lại lợi thế thông lượng có thể đo lường được cho các trường hợp sử dụng tần suất cao cụ thể, nhưng tốc độ thô chỉ là một khía cạnh trong quyết định xây dựng hoặc đầu tư.

Chương trình Solana và Hợp đồng Thông minh Ethereum: Sự khác biệt là gì?

Các chương trình Solana (thuật ngữ chính thức của Solana Foundation cho Hợp đồng Thông minh trên SolanaVM) khác với Hợp đồng Thông minh máy ảo Ethereum không chỉ về tên gọi mà còn về kiến trúc cấu trúc.

Các chương trình Solana là không trạng thái. Logic chương trình nằm trong một tài khoản trên chuỗi; dữ liệu mà chương trình hoạt động trên đó nằm trong các tài khoản dữ liệu riêng biệt mà chương trình đọc và ghi. Ngược lại, một Hợp đồng Thông minh máy ảo Ethereum đóng gói cả logic và trạng thái vào một đối tượng hợp đồng duy nhất. Hợp đồng đó sở hữu bộ nhớ lưu trữ của riêng mình. Sự tách biệt trong mô hình của Solana là những gì cho phép Sealevel xác định các phụ thuộc tài khoản trước khi thực thi: các tài khoản liên quan đến bất kỳ giao dịch nào được khai báo rõ ràng trước, cung cấp cho công cụ thực thi thông tin cần thiết để lập lịch thực thi song song một cách an toàn.

SolanaVM không tương thích với máy ảo Ethereum. Nguồn trích dẫn Neon EVM như một môi trường máy ảo Ethereum của Bên thứ ba riêng biệt liên quan đến Solana. Nó không làm cho SVM tự tương thích, và kiến trúc hiện tại, trạng thái triển khai, hỗ trợ công cụ và các hạn chế của nó phải được đánh giá độc lập.

Xây dựng trên SolanaVM: Ngôn ngữ, Công cụ và Bắt đầu

Các chương trình Solana chủ yếu được viết bằng Rust, một ngôn ngữ lập trình hệ thống được chọn vì các đảm bảo an toàn bộ nhớ và đặc tính hiệu suất của nó, và được biên dịch thành bytecode sBPF trước khi triển khai trên SolanaVM.

Rust thực thi an toàn bộ nhớ tại thời điểm biên dịch thông qua mô hình sở hữu loại bỏ toàn bộ các lớp lỗi: con trỏ null bị dereference, cuộc đua dữ liệu và tràn bộ đệm, tất cả mà không cần dựa vào trình thu gom rác. Các thuộc tính này phù hợp với các yêu cầu bảo mật và hiệu suất của việc thực thi trên chuỗi, nơi các lỗi không thể được vá sau khi triển khai và chi phí thực thi rất quan trọng ở cấp độ lệnh. C và C++ cũng được hỗ trợ kỹ thuật bởi SolanaVM, nhưng Rust là tiêu chuẩn thực tế trong toàn bộ hệ sinh thái nhà phát triển Solana.

Khung Anchor cho phát triển Solana trừu tượng hóa phần lớn sự phức tạp cấp thấp của Rust và sBPF, hoạt động tương tự như Hardhat hoặc Foundry trong hệ sinh thái máy ảo Ethereum. Anchor cung cấp xác thực tài khoản có cấu trúc, xử lý lỗi và định nghĩa giao diện chương trình, giảm đáng kể mã boilerplate cần thiết để viết một chương trình Solana chính xác. Lưu ý rằng Khung Anchor cho Solana không liên quan đến Anchor Protocol, giao thức cho vay Terra/Luna của Bên thứ ba DeFi đã sụp đổ vào năm 2022.

Kiến trúc thực thi song song của SolanaVM làm cho nó đặc biệt phù hợp với các ứng dụng DeFi yêu cầu thông lượng cao: sổ lệnh trên chuỗi, các công cụ Thanh lý, và các chương trình tối ưu hóa lợi suất đòi hỏi độ trễ thấp và mật độ giao dịch cao. Các giao thức DeFi gốc trên SolanaVM bao gồm Raydium (nhà tạo lập thị trường tự động), Jupiter (DEX tổng hợp), và Kamino (tối ưu hóa lợi suất). SOL có thể được mua trên các sàn giao dịch Tiền điện tử lớn và được sử dụng để thanh toán cho các đơn vị tính toán khi tương tác với các chương trình SolanaVM.

Để có hướng dẫn nhanh hoàn chỉnh cho nhà phát triển, hãy truy cập tài liệu nhà phát triển Solana chính thức.

Đơn vị Tính toán: Cách SolanaVM Đo lường việc Thực thi Chương trình

Đơn vị tính toán (CU) là đối tượng tương đương với gas của Ethereum trên SolanaVM: đơn vị đo lường tài nguyên tính toán được tiêu thụ bởi việc thực thi một chương trình Solana.

Mỗi giao dịch SolanaVM hoạt động trong một ngân sách đơn vị tính toán. Mức tối đa hiện tại là 1,4 triệu CU mỗi giao dịch, như được quy định trong tài liệu của Solana Foundation (Nguồn: docs.solana.com, tính đến Quý 1 năm 2025). Một chương trình vượt quá ngân sách CU của nó trong quá trình thực thi sẽ bị hủy bỏ và giao dịch đó sẽ thất bại. Nhà phát triển yêu cầu một giới hạn CU cụ thể cho mỗi giao dịch; yêu cầu quá mức sẽ lãng phí khoản tiết kiệm phí tiềm năng, trong khi yêu cầu không đủ sẽ gây ra các lỗi có thể tránh được.

Phí giao dịch trên Solana được thanh toán bằng SOL và được xác định một phần bởi mức tiêu thụ CU. Một Phí cơ sở được áp dụng cho tất cả các giao dịch; thị trường phí ưu tiên tùy chọn cho phép người dùng trả nhiều tiền hơn để được ưu tiên trong lập lịch slot trong các giai đoạn nhu cầu cao. Các đơn vị tính toán (Compute units) hoạt động tương tự như gas của Ethereum ở chỗ cả hai đều đo lường chi phí tính toán, nhưng hệ thống CU của Solana sử dụng Phí cơ sở giá cố định thay vì đấu giá hoàn toàn năng động, với các phí ưu tiên được xếp lớp lên Top.

Bạn có thể chuyển các Hợp đồng Thông minh EVM sang SolanaVM không?

Việc chuyển đổi trực tiếp hợp đồng từ EVM sang SolanaVM là không thể nếu không viết lại. Các chương trình Solana yêu cầu mã Rust và bytecode sBPF, chứ không phải Solidity và opcode EVM. Các mô hình thực thi khác nhau về mặt kiến trúc đến mức không tồn tại bản dịch từng dòng một.

Các Hợp đồng Thông minh EVM và các chương trình Solana sử dụng các mô hình trạng thái và tài khoản khác nhau, vì vậy một quá trình di chuyển gốc thường đòi hỏi các thay đổi về kiến trúc. Một môi trường EVM riêng biệt có thể bảo tồn các phần của quy trình làm việc Solidity, trong khi việc phát triển SVM gốc sử dụng các bộ công cụ khác nhau. Hãy so sánh tính tương thích, hiệu suất, kiểm toán, sự phụ thuộc vận hành và sự hỗ trợ hiện tại thay vì coi bất kỳ con đường nào là mặc định.

SolanaVM bên ngoài Solana: Áp dụng Đa chuỗi và Hệ sinh thái SVM

SolanaVM hoạt động bên ngoài mạng chính Solana, với các dự án Layer 2 triển khai nó như một môi trường thực thi độc lập trên các Blockchain lớp cơ sở khác.

Mặc dù SolanaVM được thiết kế như một môi trường thực thi Layer 1, việc nó được các dự án Layer 2 áp dụng đánh dấu một bước tiến hóa kiến trúc đáng kể. Luận điểm về tính di động, rằng SolanaVM có thể hoạt động như một tiêu chuẩn thực thi chung trên nhiều chuỗi giống như cách EVM làm, đang chuyển từ lý thuyết sang thực tế.

Bảng dưới đây liệt kê các chuỗi SVM hiện tại theo loại và trạng thái:

Cập nhật lần cuối: Quý 1 năm 2025. Xác minh trạng thái dự án hiện tại trước khi xuất bản lại. Nguồn: eclipse.xyz, tài liệu của Solana Foundation. Các dự án rollup SVM bổ sung đang trong quá trình phát triển; bảng này yêu cầu cập nhật định kỳ khi hệ sinh thái phát triển.

Trên tất cả các chuỗi SVM, các ứng dụng DeFi, đặc biệt là các sàn DEX, giao thức cho vay và các chương trình tối ưu hóa lợi nhuận, đại diện cho trường hợp sử dụng chính cho khả năng thực thi song song của SolanaVM. Neon EVM đại diện cho một khía cạnh khác của sự tăng trưởng hệ sinh thái SVM, cho phép các hợp đồng tương thích với EVM chạy trên SolanaVM của Solana và kết nối hai hệ sinh thái Hợp đồng Thông minh lớn nhất.

Eclipse: SolanaVM như một Ethereum Layer 2

Nguồn tin trích dẫn Eclipse như một ví dụ về công nghệ SVM được sử dụng bên ngoài Solana. Kiến trúc hiện tại, mô hình Quyết toán, tính sẵn có của dữ liệu, các giả định bảo mật và hiệu suất đo lường được của nó nên được xác minh từ các nguồn sơ cấp có ghi ngày tháng thay vì được tóm tắt như là kế thừa một sự đảm bảo bảo mật chung.

Kiến trúc này tách biệt hai chức năng mà hầu hết các Blockchain gộp lại với nhau. SolanaVM xử lý việc thực thi: nó nhận các giao dịch, xử lý các chương trình Solana song song bằng Sealevel và tạo ra các đầu ra trạng thái với tốc độ cao. Ethereum xử lý việc Quyết toán: Eclipse gửi dữ liệu giao dịch trở lại Ethereum, kế thừa mô hình bảo mật và tính hữu hạn của nó. Eclipse tách biệt tốc độ thực thi khỏi mô hình bảo mật của chuỗi cơ sở, truy cập cả hai một cách độc lập.

Kiến trúc này chứng minh rằng SolanaVM có thể hoạt động như một tiêu chuẩn thực thi di động bên ngoài mạng Solana. Nó tuân theo tính di động kiến trúc tương tự đã cho phép EVM lan rộng trên hàng chục chuỗi. Việc triển khai của Eclipse là bằng chứng hiện tại rõ ràng nhất cho luận điểm về tính di động của SVM.

Để biết chi tiết đầy đủ về kiến trúc, hãy truy cập tài liệu chính thức của Eclipse tại eclipse.xyz.

SVM Rollups: Ranh giới tiếp theo của việc áp dụng SolanaVM

Một SVM rollup (một giải pháp Layer 2 được hỗ trợ bởi SolanaVM) là một Blockchain sử dụng SolanaVM làm môi trường thực thi trong khi gửi dữ liệu giao dịch lên một chuỗi lớp cơ sở để Quyết toán và đảm bảo tính sẵn có của dữ liệu.

Kiến trúc rollup tách biệt tốc độ thực thi của SolanaVM khỏi mô hình bảo mật của bất kỳ chuỗi đơn lẻ nào. Thay vì yêu cầu một chuỗi độc lập mới, một SVM rollup có thể cắm vào một lớp cơ sở hiện có (Ethereum, Celestia hoặc chính Solana) để có tính sẵn có của dữ liệu và tính hữu hạn. Hiệu suất thực thi song song của SolanaVM trở nên khả dụng trên toàn bộ hệ sinh thái Blockchain rộng lớn thay vì chỉ dành riêng cho mạng của chính Solana.

Việc triển khai mạng chính của Eclipse đại diện cho kiến trúc SVM rollup tiên tiến nhất hiện đang hoạt động. Các dự án SVM rollup bổ sung đang được phát triển, mặc dù trạng thái của chúng thay đổi thường xuyên. Nếu việc áp dụng SVM rollup tiếp tục theo quỹ đạo hiện tại, sự hiện diện đa chuỗi của SolanaVM có thể tiếp cận phạm vi áp dụng của EVM, mặc dù quy mô hệ sinh thái nhà phát triển vẫn là biến số phân biệt chính.

Phần này đề cập đến các bước phát triển hệ sinh thái hướng tới tương lai. Trạng thái dự án yêu cầu xác minh định kỳ. Cập nhật lần cuối: Quý 1 năm 2025.

Việc áp dụng SolanaVM bên ngoài Solana đang phát triển như thế nào

SolanaVM đang cho thấy những dấu hiệu sớm của việc áp dụng đa chuỗi, với các dự án như Eclipse triển khai nó như một lớp thực thi bên ngoài mạng Solana. Liệu SolanaVM có đạt được sự tiêu chuẩn hóa đa chuỗi giống như EVM hay không tùy thuộc vào tỷ lệ áp dụng của nhà phát triển, sự hoàn thiện của các công cụ và sự thành công của các dự án SVM rollup.

Bằng chứng về phạm vi tiếp cận ngày càng tăng của SolanaVM là rất cụ thể. Eclipse vận hành một mạng chính trực tiếp sử dụng SolanaVM làm môi trường thực thi trên Ethereum. Các dự án SVM rollup đang chuyển từ giai đoạn công bố sang hoạt động. Anchor Framework đã phát triển đến mức việc phát triển trên SolanaVM dễ tiếp cận hơn đáng kể so với hai năm trước. Các giao thức DeFi trên Solana (Raydium, Jupiter, Kamino) chứng minh rằng kiến trúc thực thi song song của SolanaVM tạo ra hoạt động kinh tế thực sự, chứ không chỉ là các con số thông lượng lý thuyết.

Các trở ngại cũng cụ thể không kém. EVM đã có lợi thế dẫn trước một thập kỷ trong việc áp dụng cho nhà phát triển, sự hoàn thiện của công cụ và triển khai đa chuỗi. Một nhà phát triển biết Solidity có thể triển khai trên hơn 100 chuỗi hiện nay; một nhà phát triển biết Rust và Anchor Framework có thể triển khai trên mạng chính Solana và Eclipse, với nhiều chuỗi SVM khác sẽ xuất hiện dần dần. Hiệu ứng mạng của EVM đại diện cho một con hào cạnh tranh thực sự, không phải là một gánh nặng di sản mà SolanaVM tự động thay thế. Kiến trúc thực thi song song của SolanaVM mang lại những lợi thế có thể đo lường được cho các trường hợp sử dụng DeFi thông lượng cao, nhưng ưu thế kỹ thuật ở một khía cạnh không tự động chuyển thành việc được cả hệ sinh thái áp dụng.

Việc áp dụng SolanaVM ngày càng tăng trên mạng gốc của Solana làm tăng nhu cầu đối với SOL như một token phí cho việc thanh toán đơn vị tính toán. Các chuỗi SVM Quyết toán trên các mạng khác (chẳng hạn như Eclipse Quyết toán trên Ethereum) có thể sử dụng các cấu trúc phí khác nhau; mối quan hệ nhu cầu SOL thay đổi theo kiến trúc chuỗi.

Nội dung này chỉ dành cho mục đích thông tin và không cấu thành lời khuyên tài chính hoặc đầu tư. SolanaVM và SOL (Tiền điện tử gốc của Solana) mang những rủi ro cố hữu đối với công nghệ Blockchain và Tài sản kỹ thuật số. Người đọc nên thực hiện nghiên cứu độc lập trước khi đưa ra bất kỳ quyết định đầu tư nào.

Quỹ đạo áp dụng SolanaVM trên mạng chính Solana, Eclipse và các SVM rollup mới nổi sẽ được quyết định bởi sự tăng trưởng của cộng đồng nhà phát triển nhiều như bởi giá trị kiến trúc. Cơ sở kiến trúc cho SolanaVM đã được thiết lập tốt. Cơ sở hệ sinh thái vẫn đang được xây dựng.

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, một ví, hoặc một giao thức của Bên thứ ba là phù hợp cho mọi người đọc.

Các câu hỏi thường gặp: Giải thích về SolanaVM

SolanaVM là gì?

SolanaVM (còn được gọi là Solana Virtual Machine hoặc SVM) là môi trường thực thi của blockchain Solana: lớp phần mềm xử lý các chương trình Solana và cam kết kết quả của chúng vào mạng lưới. SolanaVM không phải là một token hay sản phẩm riêng biệt; nó là một thành phần kiến trúc cốt lõi của Solana. Trong các ngữ cảnh blockchain, SVM là viết tắt của Solana Virtual Machine, không phải Support Vector Machine.

SolanaVM khác với EVM như thế nào?

SolanaVM và máy ảo Ethereum (EVM) khác nhau ở ba khía cạnh kiến trúc chính. Thứ nhất, SolanaVM xử lý các giao dịch không xung đột song song bằng công cụ Sealevel; EVM xử lý giao dịch tuần tự. Thứ hai, SolanaVM thực thi bytecode sBPF được biên dịch từ Rust; EVM thực thi các opcode được biên dịch từ Solidity hoặc Vyper. Thứ ba, SolanaVM đo lường chi phí thực thi bằng đơn vị tính toán (CU); EVM sử dụng gas. EVM có hệ sinh thái đa chuỗi lớn hơn đáng kể.

Ngôn ngữ lập trình nào được sử dụng cho SolanaVM?

Các chương trình Solana chủ yếu được viết bằng Rust, một ngôn ngữ lập trình hệ thống được đánh giá cao nhờ các đảm bảo an toàn bộ nhớ và hiệu suất. Mã Rust được biên dịch thành bytecode sBPF trước khi triển khai Trên chuỗi. Anchor Framework cho Solana đơn giản hóa việc phát triển Rust bằng cách xử lý các đoạn mã xác thực tài khoản và cấu trúc chương trình. C và C++ cũng được hỗ trợ về mặt kỹ thuật nhưng Rust là tiêu chuẩn thực tế.

SolanaVM có nhanh hơn EVM không?

Thông lượng tối đa lý thuyết của SolanaVM đạt khoảng 65.000 TPS trong điều kiện tối ưu; Ethereum Mainnet xử lý khoảng 15 đến 30 TPS theo trình tự (Nguồn: Solana Foundation, ethereum.org, tính đến Q1 2025). Việc thực thi song song của SolanaVM mang lại lợi thế tốc độ đo lường được cho các khối lượng công việc giao dịch không xung đột. Các chuỗi L2 tương thích EVM như Arbitrum và Optimism đạt được các con số thông lượng thu hẹp đáng kể khoảng cách này trong thực tế.

sBPF trong Solana là gì?

sBPF (Solana Berkeley Packet Filter) là định dạng bytecode mà SolanaVM thực thi: phiên bản sửa đổi của Solana đối với bộ hướng dẫn Berkeley Packet Filter, được điều chỉnh cho việc thực thi chương trình blockchain. Khi một nhà phát triển viết chương trình Solana bằng Rust, trình biên dịch Rust sẽ dịch nó thành bytecode sBPF trước khi triển khai. Sau đó, các validator thực thi trực tiếp bytecode sBPF đó. sBPF khác với công nghệ mạng BPF ban đầu được sử dụng trong nhân hệ điều hành.

Có thể chạy các hợp đồng EVM trên SolanaVM không?

Bytecode EVM không chạy gốc trên SolanaVM vì các mô hình thực thi và tài khoản khác nhau. Một môi trường EVM Bên thứ ba riêng biệt có thể hỗ trợ một phần quy trình làm việc của Solidity, trong khi việc triển khai SVM gốc yêu cầu một ngôn ngữ và kiến trúc tương thích. Hãy xác minh hỗ trợ công cụ hiện tại và đánh giá hiệu suất của khối lượng công việc thực tế trước khi chọn hướng đi.

Blockchain Eclipse là gì và nó sử dụng SolanaVM như thế nào?

Eclipse là một blockchain Ethereum Layer 2 sử dụng SolanaVM làm môi trường thực thi trong khi Quyết toán giao dịch trên Ethereum. Eclipse xử lý các giao dịch bằng công cụ thực thi song song Sealevel của SolanaVM, đạt được thông lượng ngang Solana. Việc Quyết toán và tính khả dụng dữ liệu được xử lý bởi Ethereum, kế thừa mô hình bảo mật của nó. Eclipse chứng minh rằng SolanaVM có thể hoạt động như một tiêu chuẩn thực thi di động vượt ra ngoài mạng lưới Solana.

Chương trình Solana là gì?

Chương trình Solana là thuật ngữ chính thức của SolanaVM cho hợp đồng thông minh: mã Trên chuỗi tự thực thi mà SolanaVM xử lý khi được gọi bởi một giao dịch. Không giống như các hợp đồng thông minh EVM, nơi lưu trữ cả logic và trạng thái trong cùng một đối tượng hợp đồng, các chương trình Solana là không trạng thái. Logic chương trình nằm trong một tài khoản chương trình; dữ liệu mà nó hoạt động nằm trong các tài khoản dữ liệu riêng biệt. Thiết kế không trạng thái này cho phép công cụ thực thi song song của SolanaVM chạy an toàn nhiều chương trình đồng thời.

Đơn vị tính toán trong Solana là gì?

Đơn vị tính toán (CU) là tương đương của Ethereum gas trong SolanaVM: đơn vị đo lường tài nguyên tính toán tiêu thụ bởi việc thực thi một chương trình Solana. Mỗi giao dịch SolanaVM hoạt động trong phạm vi ngân sách CU tối đa là 1,4 triệu CU cho mỗi giao dịch (Nguồn: tài liệu Solana Foundation, docs.solana.com, tính đến Q1 2025). Các chương trình vượt quá ngân sách CU của chúng sẽ bị hủy. Phí giao dịch trên Solana được thanh toán bằng SOL, một phần được xác định bởi mức tiêu thụ CU, với một thị trường phí ưu tiên cho các thời kỳ nhu cầu cao.

SolanaVM có đang trở thành một tiêu chuẩn blockchain mới không?

Nguồn xác định việc áp dụng SVM sớm ngoài Solana, bao gồm Eclipse và các dự án được công bố khác. Việc triển khai và hoạt động hiện tại cần được xác minh. Liệu công nghệ SVM có trở nên được tiêu chuẩn hóa rộng rãi hay không vẫn còn không chắc chắn và không nên được trình bày như một dự báo.

Đọc thêm

• Kiến trúc Solana
• Solana có tương thích EVM không?
• Tiêu chuẩn Token Solana