Solana Sealevel: Cơ chế Xử lý Song song

Solana Sealevel Xử lý Song song cho phép môi trường runtime thực thi các giao dịch không xung đột cùng lúc khi các giao dịch đó khai báo các tài khoản mà chúng sẽ đọc và ghi. Do đó, Sealevel là một mô hình thực thi, không phải là một Cơ chế đồng thuận độc lập hay một sự đảm bảo rằng mọi khối lượng công việc sẽ chạy song song.

Các số liệu hiệu suất trong bài viết này cần ngữ cảnh. Con số TPS 65.000 thường được trích dẫn là một phép đo lý thuyết hoặc thử nghiệm có kiểm soát, không phải là thông lượng Mainnet được đảm bảo. Mục tiêu slot khoảng 400 mili giây không giống như tính cuối cùng của giao dịch, và phí thay đổi theo số chữ ký, mức sử dụng tính toán, cài đặt ưu tiên và điều kiện mạng.

Ethereum xử lý khoảng 15 giao dịch mỗi giây trên lớp cơ sở của nó. Tài liệu của Solana trong lịch sử đã đưa ra con số lên tới 65.000 TPS trong các điều kiện lý thuyết hoặc có kiểm soát; thông lượng thực tế mà người dùng nhận được thay đổi. Khoảng cách đó không phải là ngẫu nhiên. Động cơ đằng sau nó được gọi là Sealevel.

Sealevel là môi trường runtime hợp đồng thông minh song song của Solana: cơ chế thực thi xử lý hàng nghìn giao dịch độc lập đồng thời thay vì từng giao dịch một. Nó được hình thành bởi Anatoly Yakovenko, một cựu kỹ sư Qualcomm, người đã thành lập Solana Labs (công ty đứng sau sự phát triển cốt lõi của Solana) và là tác giả của Whitepaper nền tảng của Solana vào năm 2017.

Hãy tưởng tượng một đường cao tốc lớn trong giờ cao điểm. Solana (một blockchain, hoặc sổ cái kỹ thuật số chống giả mạo phân tán) sử dụng Sealevel để xây dựng hàng trăm làn đường và phân loại lưu lượng truy cập đến theo điểm đến. Mọi xe trên Ethereum đều phải sử dụng một làn đường duy nhất. Xe xếp hàng sau nhau và di chuyển về phía trước từng chiếc một. Sealevel phân loại xe theo điểm đến: những xe đi đến các địa chỉ khác nhau sẽ di chuyển đồng thời, không phải chờ đợi. Chỉ những xe đi đến cùng một địa chỉ chính xác mới phải xếp hàng. Cơ chế phân loại đó là hiểu biết kiến trúc đằng sau lợi thế tốc độ của Solana.

Bài giải thích này bao gồm Sealevel là gì, tính song song dựa trên tài khoản của nó hoạt động cơ học như thế nào, nó so sánh với môi trường thực thi của Ethereum ra sao, những điểm còn hạn chế và ý nghĩa của những khả năng đó đối với các nhà phát triển và nhà đầu tư khi đánh giá Solana.

Solana Sealevel Xử lý Song song: Tổng quan Nhanh

• Sealevel là môi trường runtime hợp đồng thông minh song song của Solana, xử lý hàng nghìn giao dịch đồng thời.
• Cách hoạt động: các giao dịch khai báo trước các tài khoản phụ thuộc; Sealevel chạy các giao dịch không xung đột một cách song song.
• Thông lượng: tối đa lý thuyết ~65.000 TPS; các giao dịch không bỏ phiếu trong thế giới thực thường đạt 2.000–4.000 TPS.
• So với Ethereum: máy ảo Ethereum (EVM) của Ethereum xử lý từng giao dịch một; Sealevel xử lý các giao dịch độc lập cùng lúc.
• Hạn chế thực tế: Solana đã gặp sự cố mất mạng vào năm 2021 và 2022 do lỗi nhập dữ liệu phía trên Sealevel.

Thực thi Tuần tự so với Song song: Vấn đề Cốt lõi mà Sealevel Giải quyết

Thực thi tuần tự và song song là hai phương pháp xử lý giao dịch blockchain khác biệt về cơ bản, và sự khác biệt này giải thích phần lớn khoảng cách hiệu suất giữa Solana và Ethereum.

Thực thi tuần tự có nghĩa là một giao dịch hoàn thành hoàn toàn trước khi giao dịch tiếp theo bắt đầu. Một giao dịch đến, blockchain khóa trạng thái liên quan, chạy tính toán, ghi kết quả, mở khóa trạng thái, và chỉ sau đó mới bắt đầu giao dịch tiếp theo. Mỗi bước đều chặn bước phía sau nó. Không có sự chồng chéo, không có đồng thời, không có xử lý đồng thời các công việc độc lập.

Trần thông lượng mà điều này tạo ra là có thật. máy ảo Ethereum (EVM) của Ethereum xử lý khoảng 15–30 giao dịch mỗi giây trên chuỗi cơ sở Lớp 1 (L1) của nó mà không có các Rollups Lớp 2 (L2), theo tài liệu của Ethereum Foundation. Con số đó đã gần như không đổi trong nhiều năm vì nút thắt cổ chai là do kiến trúc.

Thách thức lớn hơn được thể hiện qua bộ ba về khả năng mở rộng (scalability trilemma) thường được trích dẫn, đó là quan sát thấy các blockchain trong lịch sử gặp khó khăn trong việc tối đa hóa sự phân quyền và bảo mật trong khi vẫn đạt được khả năng mở rộng cao. Thực thi tuần tự là hạn chế chính về khả năng mở rộng. Thêm phần cứng nhanh hơn không giải quyết được vấn đề này vì mô hình thực thi tự nó tuần tự hóa mọi công việc thông qua một đường ống duy nhất.

Xử lý song song mang đến một câu trả lời khác. Thay vì một nhân viên thu ngân cho tất cả khách hàng, hãy tưởng tượng một siêu thị với 500 quầy thanh toán. Khách hàng mua các mặt hàng hoàn toàn khác nhau (không có thiết bị thanh toán chung, không có tài khoản khách hàng thân thiết chung) có thể thanh toán đồng thời trên tất cả các quầy. Chỉ những khách hàng thực sự cần dùng chung một thiết bị thanh toán mới phải xếp hàng chờ. Tổng thông lượng của cửa hàng tăng lên theo cấp số nhân, không phải vì bất kỳ nhân viên thu ngân cá nhân nào trở nên nhanh hơn, mà bởi vì các giao dịch độc lập đã ngừng chặn lẫn nhau.

Một môi trường runtime hợp đồng thông minh là môi trường phần mềm thực thi mã hợp đồng thông minh trên một blockchain. Đó là lớp thực sự chạy mã chương trình. Trên Solana, các hợp đồng thông minh được gọi là "chương trình" (thuật ngữ chuẩn trong tài liệu của Solana, mặc dù "hợp đồng thông minh" vẫn được hiểu rộng rãi và được sử dụng thay thế ở đây). Sealevel là môi trường runtime của Solana: được xây dựng từ đầu để chạy hàng nghìn chương trình này đồng thời thay vì tuần tự.

Hiểu cách Sealevel đạt được điều này một cách an toàn, không có xung đột cạnh tranh (race conditions) hoặc trạng thái bị hỏng, đòi hỏi phải hiểu cơ chế kiến trúc làm cho tính song song trở nên an toàn. Cơ chế đó là mô hình tài khoản của Solana.

Cách Sealevel Hoạt động: Mô hình Tài khoản và Khai báo Trạng thái Sớm

Sealevel đạt được thực thi song song một cách an toàn thông qua hai tính năng kiến trúc hoạt động cùng nhau: mô hình tài khoản của Solana và việc sắp xếp thứ tự giao dịch trước được cung cấp bởi Proof of History (PoH), một cơ chế đồng hồ mật mã tạo ra dấu thời gian có thể xác minh cho mọi sự kiện trên mạng Solana. Phần này giải thích cả hai.

Mô hình Tài khoản của Solana: Tách biệt Mã khỏi Trạng thái

Sealevel có thể thực thi các giao dịch một cách song song vì mô hình tài khoản của Solana cung cấp cho nó thông tin cần thiết để làm điều đó một cách an toàn trước khi thực thi bắt đầu.

Trên Solana, các chương trình chỉ chứa mã thực thi và bản thân chúng không lưu trữ dữ liệu. Đây là các chương trình không trạng thái: chúng mang các chỉ dẫn nhưng không giữ trạng thái riêng. Dữ liệu nằm trong các đối tượng tài khoản riêng biệt mà các chương trình có thể đọc hoặc ghi vào. Thiết kế này tách mã khỏi trạng thái ở cấp độ kiến trúc. Nó khác với mô hình của Ethereum, nơi một hợp đồng thông minh lưu trữ cả mã thực thi và trạng thái của nó tại một địa chỉ hợp đồng duy nhất.

Mọi giao dịch Solana phải khai báo trước các tài khoản mà nó sẽ đọc và các tài khoản mà nó sẽ ghi vào, trước khi thực thi bắt đầu. Sealevel đọc các khai báo này để lên lịch thực thi. Một giao dịch bỏ qua bước này sẽ bị từ chối bởi môi trường runtime. Đây không phải là việc ghi sổ tùy chọn: đó là điều kiện tiên quyết cấu trúc làm cho tính song song an toàn trở nên khả thi.

Hãy tưởng tượng hai đầu bếp làm việc trong một căn bếp có sáu bếp ga. Đầu bếp A đang nấu mì ống và cần bếp một và hai. Đầu bếp B đang làm món xào và cần bếp bốn và năm. Họ có thể làm việc đồng thời mà không cần bất kỳ sự phối hợp nào vì bề mặt làm việc của họ không trùng lặp. Không ai cần chờ đợi người kia. Chỉ khi cả hai đầu bếp cùng cần bếp ba thì một người mới phải chờ. Sealevel áp dụng chính xác logic này cho các giao dịch: những giao dịch sử dụng các tài khoản khác nhau sẽ chạy song song; những giao dịch chia sẻ một tài khoản ghi sẽ chạy tuần tự.

Lưu ý cho nhà phát triển: Môi trường thực thi sẽ từ chối các giao dịch truy cập vào những tài khoản không được khai báo. Quyền truy cập tài khoản phải được xác định tại thời điểm xây dựng giao dịch, chứ không phải trong quá trình thực thi. Ràng buộc này là cơ chế thiết kế cho phép lập lịch song song được mô tả dưới đây.

Cách Sealevel lập lịch thực thi song song

Khi một giao dịch đến Sealevel, quy trình lập lịch sẽ tuân theo bốn bước riêng biệt.

1. Một giao dịch đến mang theo một tệp kê khai (manifest): danh sách đầy đủ các tài khoản mà nó sẽ đọc và các tài khoản mà nó sẽ ghi dữ liệu.
2. Sealevel xây dựng một biểu đồ phụ thuộc (một bản đồ các giao dịch dùng chung tài khoản) bằng cách so sánh đồng thời các tệp kê khai của tất cả các giao dịch đang chờ xử lý.
3. Các giao dịch không dùng chung bất kỳ tài khoản ghi dữ liệu nào là độc lập. Sealevel gửi chúng đến các lõi xử lý riêng biệt cùng một lúc, chạy chúng song song trên tất cả các lõi CPU và GPU hiện có.
4. Các giao dịch khai báo sự phụ thuộc ghi trên cùng một tài khoản sẽ bị xung đột. Sealevel tuần tự hóa các giao dịch cụ thể đó, thực thi chúng lần lượt theo thứ tự được thiết lập bởi PoH, trong khi tất cả các giao dịch không xung đột khác tiếp tục chạy song song.

Cách tiếp cận này là tính song song xác định: Sealevel xác định các xung đột trước khi bắt đầu thực thi thay vì giải quyết chúng sau đó. Nó không thực thi các giao dịch theo kiểu suy đoán rồi hoàn tác các thất bại. Điều này giúp phân biệt nó với các phương pháp tiếp cận đồng thời lạc quan (optimistic concurrency) như Aptos Block-STM, nơi các giao dịch được thực thi suy đoán trước và chạy lại khi có xung đột.

Sealevel cũng có thể định tuyến các tác vụ xác minh chữ ký đến các lõi GPU, tương tự như cách một GPU chạy hàng nghìn tính toán shader đồng thời trong khối lượng công việc Gaming hoặc AI. Đơn vị Xử lý Giao dịch (TPU) của Solana sử dụng kỹ thuật đường ống (pipelining) để chạy các giai đoạn xác thực giao dịch đồng thời trên các đơn vị phần cứng, với Sealevel xử lý giai đoạn thực thi của đường ống đó.

Sealevel so với Ethereum EVM: So sánh trực tiếp về kiến trúc

Solana nhanh hơn Ethereum ở lớp cơ sở chủ yếu nhờ vào Sealevel, môi trường thực thi Hợp đồng Thông minh song song của nó. Trong khi EVM của Ethereum xử lý từng giao dịch một theo trình tự nghiêm ngặt, Sealevel xử lý hàng nghìn giao dịch độc lập đồng thời trên nhiều lõi xử lý.

So sánh Sealevel và EVM

EVM xử lý các giao dịch lần lượt vì kiến trúc hợp đồng có trạng thái của nó gây khó khăn về mặt kiến trúc để xác định trước giao dịch nào là an toàn để song song hóa. Các Hợp đồng Thông minh trên Ethereum lưu trữ trạng thái của chính chúng. Hai hợp đồng bất kỳ về mặt lý thuyết đều có thể chia sẻ trạng thái, và nếu không biết trước giao dịch nào là độc lập, việc song song hóa chúng sẽ có nguy cơ làm hỏng trạng thái. Đây không phải là một khiếm khuyết trong thiết kế của Ethereum; đó là hệ quả từ kiến trúc của nó.

Solana biên dịch các chương trình sang mã bytecode eBPF (bộ lọc gói Berkeley mở rộng) đã được sửa đổi của Solana: một tập lệnh nhỏ gọn được điều chỉnh từ một định dạng gốc Linux đã được thiết lập tốt. Sealevel thực thi mã bytecode này ở tốc độ gần như nguyên bản. Ngược lại, EVM bytecode chạy trên một máy ảo mô phỏng bằng phần mềm tùy chỉnh. Phương pháp BPF cung cấp các lộ trình tối ưu hóa ở cấp độ phần cứng mà định dạng tùy chỉnh của EVM không có, góp phần tạo nên lợi thế về thông lượng của Sealevel ở cấp độ thực thi lệnh.

Điều làm cho Solana khác biệt về kiến trúc so với Ethereum:

• Mô hình thực thi: song song xác định (Sealevel) so với tuần tự (EVM)
• Kiến trúc trạng thái: các chương trình không trạng thái và các tài khoản dữ liệu riêng biệt so với các hợp đồng có trạng thái
• Cách tiếp cận mở rộng: thực thi song song L1 so với L2 Rollups và sharding
• Ngôn ngữ phát triển: Rust so với Solidity

Để hiểu rõ bối cảnh về sự khác biệt của các mô hình tài khoản trên các kiến trúc Blockchain Layer-1, sự tương phản giữa phương pháp khai báo trước của Solana và các thiết kế lưu trữ Trên chuỗi khác là rất hữu ích.

Sealevel so với Aptos Block-STM và Monad: Các phương pháp thực thi song song khác nhau như thế nào

Sealevel không phải là kiến trúc thực thi song song duy nhất đang hoạt động. So sánh phương pháp của nó với Aptos Block-STM, Monad, cũng như Sui, sẽ làm lộ rõ các đánh đổi riêng biệt mà mỗi thiết kế đưa ra.

Aptos sử dụng Block-STM (Bộ nhớ giao dịch phần mềm), một phương pháp tiếp cận đồng thời lạc quan. Nó thực thi các giao dịch theo kiểu suy đoán song song mà không yêu cầu khai báo tài khoản trước, sau đó xác thực kết quả và thực thi lại bất kỳ giao dịch nào gây ra xung đột. Ưu điểm cho các nhà phát triển: không cần khai báo các phụ thuộc tài khoản tại thời điểm xây dựng. Sự đánh đổi: khối lượng công việc có nhiều xung đột sẽ kích hoạt thực thi lại, gây tốn thời gian. Sealevel tránh hoàn toàn việc thực thi lại vì nó xác định các xung đột trước khi chạy.

Monad nhắm tới việc thực thi EVM song song với khả năng tương thích Ethereum Solidity. Nó áp dụng kỹ thuật đường ống cho các giai đoạn thực thi và áp dụng tính song song lạc quan trên mô hình EVM. Monad đặt cược rằng khả năng tương thích EVM xứng đáng với chi phí kiến trúc bỏ ra. Sealevel đã đưa ra lựa chọn ngược lại: một mô hình tài khoản mới hoàn toàn với tính song song thô cao hơn nhưng yêu cầu các nhà phát triển phải áp dụng một mô hình lập trình mới.

Sui sử dụng quyền sở hữu dựa trên đối tượng làm đơn vị song song của mình. Các giao dịch chạm vào các đối tượng độc lập sẽ chạy song song theo định nghĩa, mà không yêu cầu khai báo rõ ràng. Theo tài liệu hiện tại, mỗi phương pháp (mô hình xác định của Sealevel, mô hình lạc quan của Block-STM, mô hình sở hữu đối tượng của Sui) đại diện cho một câu trả lời khác nhau cho cùng một câu hỏi: làm thế nào để đạt được tính song song an toàn ở quy mô lớn.

Không có phương pháp nào là vượt trội hoàn toàn. Việc khai báo trước của Sealevel tạo ra gánh nặng cho nhà phát triển. Mô hình lạc quan của Block-STM gây ra chi phí thực thi lại khi tải nặng các xung đột. Monad đánh đổi tiềm năng hiệu suất thô để lấy khả năng tương thích Solidity. Lựa chọn đúng đắn phụ thuộc vào các yêu cầu của trường hợp sử dụng và hệ sinh thái nhà phát triển mà một nhóm đã và đang hoạt động.

Vai trò của Sealevel trong kiến trúc Tám cải tiến của Solana

Tính song song của Sealevel chỉ an toàn vì Proof of History (PoH) đã thiết lập một thứ tự giao dịch đáng tin cậy trước khi quá trình thực thi bắt đầu. Hiểu được sự phụ thuộc này sẽ tiết lộ cách Sealevel phù hợp với kiến trúc tám cải tiến rộng lớn hơn của Solana và tại sao các thành phần không thể được đánh giá một cách riêng lẻ.

Kiến trúc của Solana dựa trên tám cải tiến được thiết kế cùng nhau: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, Archivers. Mỗi cải tiến xử lý một giai đoạn riêng biệt của vòng đời giao dịch. Sealevel là lớp thực thi: công cụ chạy các chương trình.

PoH là một cơ chế đồng hồ mã hóa tạo ra một dấu thời gian có thể xác minh cho mọi sự kiện trên mạng Solana. Mọi trình xác thực (validator) đều đồng ý về chuỗi dấu thời gian này. Tại thời điểm các giao dịch đến Sealevel, vấn đề thứ tự đã được giải quyết xong. Sealevel không điều phối. Nó lập lịch.

Hãy nghĩ về nó như một dây chuyền lắp ráp. PoH là băng chuyền chuyển các mặt hàng công việc đã được phân loại trước theo trình tự đã được xác minh. Sealevel là nhóm công nhân tại dây chuyền, những người nhặt và xử lý các mặt hàng không xung đột cùng một lúc. Các công nhân không cần phải thương lượng xem nên xử lý mặt hàng nào tiếp theo vì băng chuyền đã xác định thứ tự rồi. Nếu không có băng chuyền, các công nhân sẽ phải dừng lại và điều phối liên tục, loại bỏ hoàn toàn lợi ích của tính song song.

Bởi vì PoH sắp xếp trước các giao dịch và mô hình tài khoản yêu cầu khai báo trạng thái trước, Sealevel xác định các giao dịch nào xung đột trước khi quá trình thực thi bắt đầu. Các xung đột được giải quyết một cách chủ động, không phải sau khi sự việc đã xảy ra, không giống như các mô hình đồng thời lạc quan thực thi trước rồi chạy lại khi có va chạm.

Các cải tiến còn lại đều đóng vai trò hỗ trợ. Tower BFT (Cơ chế đồng thuận của Solana, một biến thể tối ưu hóa PoH của Practical Byzantine Fault Tolerance) xác thực các khối mà Sealevel tạo ra. Gulf Stream (giao thức chuyển tiếp giao dịch không cần Mempool) đẩy các giao dịch đến các trình xác thực trước khi xác nhận khối, vì vậy Sealevel có thể bắt đầu xử lý đợt tiếp theo trong khi khối hiện tại đang được hoàn tất. Cloudbreak (cơ sở dữ liệu tài khoản) được đồng thiết kế với Sealevel để hỗ trợ đọc và ghi đồng thời trên hàng nghìn luồng thực thi song song.

Hiệu suất thực tế: Những gì Sealevel thực sự mang lại (và những nơi nó thất bại Short)

Sealevel mang lại mức tăng thông lượng thực sự so với các Blockchain thực thi tuần tự, nhưng hiệu suất thực tế của nó thấp hơn nhiều so với mức tối đa lý thuyết và mạng lưới đã từng trải qua những đợt ngừng hoạt động đáng kể. Cả hai sự thật này đều quan trọng đối với một đánh giá trung thực.

Thông lượng Lý thuyết so với Thực tế

Các số liệu thông lượng của Solana cần được đọc cẩn thận vì con số thường được trích dẫn, xấp xỉ 65.000 giao dịch mỗi giây (TPS), mô tả mức trần kiến trúc lý thuyết, không phải hiệu suất Mainnet điển hình.

Các con số TPS được công bố thường bao gồm cả các giao dịch bỏ phiếu nội bộ của trình xác thực, điều này làm thổi phồng con số được báo cáo. TPS không phải bỏ phiếu phản ánh thông lượng giao dịch thực tế đối với người dùng.

Con số ~65.000 TPS là có thật với tư cách là mức trần thiết kế kiến trúc. Nó mô tả những gì Sealevel có thể xử lý trong các điều kiện lý tưởng với hồ sơ giao dịch tối ưu. Con số thực tế thấp hơn vì một số lý do đã được ghi nhận: độ phức tạp của giao dịch, sự tranh chấp tài khoản trong các chương trình phổ biến và các hạn chế ở cấp độ mạng phía trên bản thân Sealevel. Mặc dù vậy, thông lượng Mainnet của Solana vẫn vượt xa lớp cơ sở của Ethereum ở mức xấp xỉ 15–30 TPS (tài liệu của Ethereum Foundation).

Khả năng thực thi song song của Sealevel là một thực tế kiến trúc đã được ghi nhận, không phải là một tuyên bố tiếp thị. Con số TPS lý thuyết phản ánh thiết kế của thời gian chạy; con số thực tế phản ánh môi trường hoạt động xung quanh nó.

Ngừng hoạt động mạng và tắc nghẽn: Một đánh giá trung thực

Solana đã trải qua một số đợt ngừng hoạt động mạng lớn vào năm 2021 và 2022, và bất kỳ cách xử lý trung thực nào về Sealevel cũng phải giải thích tại sao những đợt ngừng hoạt động đó lại xảy ra bất kể khả năng xử lý song song của thời gian chạy.

Một sự cố vào tháng 9 năm 2021 đã kéo dài khoảng 17 giờ. Một botnet cố gắng giành lợi thế trong một đợt ra mắt token đã làm tràn ngập lớp tiếp nhận giao dịch của mạng lưới bằng thư rác, khiến nó bị quá tải. Các đợt ngừng hoạt động đáng kể bổ sung đã xảy ra vào tháng 1 năm 2022 và tại nhiều thời điểm trong suốt năm 2022. Đây là các sự kiện lịch sử đã được ghi nhận với các báo cáo phân tích sau sự cố đã được công bố.

Các đợt ngừng hoạt động không phải là lỗi logic thực thi song song của Sealevel. Chúng là lỗi của cơ sở hạ tầng tiếp nhận giao dịch ở phía trên Sealevel. Công suất ~65.000 TPS của Sealevel mô tả số lượng giao dịch hợp lệ mà nó có thể xử lý; nó không làm cho mạng miễn nhiễm với lũ lụt giao dịch. Một xa lộ có 100 làn xe vẫn bị tắc nghẽn khi một tỷ chiếc xe cố gắng đi vào đường dẫn cùng một lúc. Mức trần xử lý và khả năng chống thư rác là các vấn đề kỹ thuật riêng biệt.

Các sự kiện đúc Token không thể thay thế (NFT), nơi hàng nghìn người dùng cố gắng đúc đồng thời, đã tạo ra một số đợt tăng tải mãnh liệt nhất mà mạng lưới từng đối mặt và làm lộ ra cùng một nút thắt cổ chai ở lớp tiếp nhận.

Kể từ đó, Solana đã thực hiện một số phản ứng kỹ thuật: giao thức QUIC thay thế UDP để tiếp nhận giao dịch (cung cấp khả năng kiểm soát tắc nghẽn tốt hơn), thị trường phí cục bộ cho phép các ứng dụng đặt phí ưu tiên khi tải nặng và ứng dụng khách trình xác thực Firedancer do Jump Crypto phát triển được kỳ vọng sẽ cải thiện thông lượng và khả năng phục hồi hơn nữa. Những phản ứng này cho thấy sự cải thiện lặp đi lặp lại, nhưng không có bản nâng cấp nào loại bỏ được sự căng thẳng cơ bản giữa việc gửi giao dịch truy cập mở và công suất xử lý có hạn.

Việc thực thi song song đa lõi của Sealevel cũng yêu cầu các trình xác thực chạy phần cứng cấu hình cao: bộ xử lý đa lõi nhanh, phân bổ RAM lớn và kết nối mạng băng thông cao. Điều này tạo ra các rào cản có ý nghĩa đối với việc tham gia của trình xác thực và đại diện cho một sự đánh đổi về tính phi tập trung mà các nhà phê bình kiến trúc của Solana đã xác định một cách chính xác.

Sealevel có phải là một con hào cạnh tranh bền vững cho Solana (SOL)?

Sealevel mang lại cho Solana một lợi thế thông lượng thực sự ở lớp cơ sở. Việc lợi thế đó có cấu thành một con hào cạnh tranh bền vững hay không đòi hỏi phải tách biệt các sự thật về kiến trúc khỏi các biến số của hệ sinh thái.

Lập luận về tính bền vững bắt đầu với chiều sâu tích hợp. Kiến trúc của Sealevel được kết hợp chặt chẽ với các thành phần được đồng thiết kế khác của Solana. PoH sắp xếp trước các giao dịch trước khi chúng đến Sealevel. Cloudbreak xử lý các lần đọc lưu trữ đồng thời mà các luồng song song của Sealevel yêu cầu. Gulf Stream làm giảm lượng giao dịch tồn đọng mà Sealevel phải xử lý. Việc sao chép hiệu suất của Sealevel một cách riêng lẻ, không có toàn bộ ngăn xếp này, sẽ không tái tạo được lợi thế đó. Sự tích hợp đó là một rào cản thực sự đối với việc sao chép: không phải là tuyệt đối, nhưng cũng không hề tầm thường.

Mô hình tài khoản cũng tạo ra chi phí chuyển đổi thực sự cho các nhà phát triển đã xây dựng các ứng dụng thực tế xung quanh mô hình của Sealevel. Các kiến trúc chương trình được thiết kế xung quanh việc khai báo tài khoản trước, các mẫu PDA và khung phát triển Anchor không thể chuyển sang các chuỗi EVM mà không có sự tái cấu trúc kiến trúc đáng kể. Thư viện ngày càng tăng của các công cụ Rust, tài nguyên Anchor, dịch vụ kiểm toán và các triển khai tham chiếu càng làm tăng thêm quán tính.

Lập luận chống lại tính bền vững vĩnh viễn cũng thực tế không kém. Aptos và Monad chứng minh rằng các kiến trúc thực thi song song có thể được xây dựng trên các nền tảng kỹ thuật khác nhau. Hệ sinh thái L2 của Ethereum (Arbitrum, Optimism, Base) đạt được thông lượng cao thông qua thực thi Ngoài chuỗi với Quyết toán Trên chuỗi, một con đường khác để mở rộng quy mô giúp tránh hoàn toàn các hạn chế của Sealevel. Đối với nhiều trường hợp sử dụng Tài chính phi tập trung (DeFi) (bao gồm các nhà tạo lập thị trường tự động, hay AMM, và các sàn giao dịch phi tập trung, hay DEX như Orca và Raydium), thông lượng L2 rollup là đủ mà không yêu cầu sự thay đổi mô hình Sealevel.

Nơi lợi thế của Sealevel có khả năng phòng thủ về mặt cấu trúc nhất là trong các trường hợp sử dụng yêu cầu cập nhật trạng thái Trên chuỗi đồng thời với tần suất cao: sổ lệnh Trên chuỗi, công cụ Thanh lý và các sự kiện đúc NFT lớn nơi hàng nghìn giao dịch độc lập phải Quyết toán đồng thời. Những trường hợp sử dụng này vẫn khó khăn về mặt kiến trúc trên các chuỗi EVM ngay cả với các giải pháp L2, bởi vì Quyết toán L2 vẫn yêu cầu sự điều phối với lớp L1 để có tính hoàn thiện.

Sealevel đại diện cho một điểm khác biệt kiến trúc thực sự và đã được ghi nhận ở lớp cơ sở. Con hào cạnh tranh của nó là có thật nhưng không vĩnh viễn. Nó phải đối mặt với áp lực từ các chuỗi song song mới nổi và hệ sinh thái L2 đang mở rộng của Ethereum. Sự bền vững trong Vị thế của Solana phụ thuộc vào hiệu ứng mạng lưới (sự chấp nhận của nhà phát triển, tổng giá trị bị khóa DeFi, cơ sở hạ tầng tổ chức) cũng như vào kiến trúc kỹ thuật thô của thời gian chạy.

Để biết thêm ngữ cảnh về định vị cạnh tranh Lớp 1 trên các mạng lưới Blockchain và cách các sự đánh đổi về kiến trúc diễn ra trên các thiết kế L1 khác nhau, các điểm tương đồng với các lựa chọn thiết kế của Sealevel sẽ mang tính hướng dẫn.

Phần này chỉ dành cho mục đích thông tin và giáo dục và không cấu thành lời khuyên tài chính, đầu tư hoặc giao dịch. Các khoản đầu tư Tiền điện tử mang theo rủi ro đáng kể, bao gồm cả rủi ro mất toàn bộ vốn. Hãy tham khảo ý kiến của một cố vấn tài chính đủ điều kiện trước khi đưa ra quyết định đầu tư.

Tài nguyên Kiến trúc Solana Liên quan

Sealevel phụ thuộc vào mô hình tài khoản Solana và là một phần của kiến trúc tốc độ rộng hơn của Solana. Người đọc thị trường có thể tham khảo trang giá SOL. Hợp đồng Vĩnh viễn SOLUSDT là một công cụ phái sinh đòn bẩy và mang rủi ro Thanh lý; nó không phải là thước đo hiệu suất kỹ thuật của Sealevel.

FAQ: Xử lý song song Sealevel của Solana

Các câu hỏi thường gặp này giải quyết các điểm nhầm lẫn phổ biến nhất về mô hình thực thi song song của Sealevel, số liệu thông lượng và mối quan hệ với các kiến trúc blockchain khác.

Sealevel là gì trong Solana?

Sealevel là trình chạy hợp đồng thông minh song song của Solana: công cụ thực thi xử lý hàng nghìn giao dịch độc lập đồng thời thay vì từng giao dịch một. Bằng cách xác định các giao dịch nào không chia sẻ sự phụ thuộc dữ liệu thông qua mô hình tài khoản của Solana, Sealevel sẽ phân phối chúng đến các lõi xử lý riêng biệt cùng lúc, cho phép thông lượng mà việc thực thi tuần tự không thể sánh kịp.

Sealevel cho phép xử lý giao dịch song song như thế nào?

Sealevel yêu cầu mỗi giao dịch phải khai báo trước các tài khoản nào nó sẽ đọc và ghi. Nó sử dụng các khai báo này để xây dựng một biểu đồ phụ thuộc, xác định các giao dịch nào không có tài khoản trùng lặp. Các giao dịch độc lập đó chạy đồng thời trên nhiều lõi xử lý. Các giao dịch chia sẻ một tài khoản ghi sẽ được tuần tự hóa và thực thi theo trình tự, trong khi tất cả các giao dịch không xung đột khác tiếp tục xử lý song song.

Sealevel của Solana khác với máy ảo Ethereum (EVM) như thế nào?

Máy ảo Ethereum (EVM) xử lý các giao dịch tuần tự, từng giao dịch một, vì kiến trúc hợp đồng có trạng thái của Ethereum khiến việc xác định trước các giao dịch nào có thể song song hóa một cách an toàn trở nên khó khăn về mặt kiến trúc. Sealevel xử lý các giao dịch không xung đột đồng thời vì mô hình tài khoản của Solana yêu cầu các giao dịch khai báo sự phụ thuộc trạng thái của chúng trước, cung cấp cho Sealevel thông tin cần thiết để song song hóa một cách an toàn trước khi bắt đầu thực thi.

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

Theo tài liệu của Solana Labs, Solana về lý thuyết có thể xử lý tới ~65.000 TPS trong điều kiện lý tưởng. Trên thực tế, thông lượng mainnet thực tế cho các giao dịch không bỏ phiếu thường nằm trong khoảng 2.000–4.000 TPS, tùy thuộc vào độ phức tạp của giao dịch, sự tranh chấp tài khoản và điều kiện mạng. Con số này vẫn cao hơn đáng kể so với thông lượng lớp cơ sở của Ethereum khoảng 15–30 TPS.

Bạn sử dụng ngôn ngữ lập trình nào để xây dựng trên Sealevel?

Các chương trình Solana chủ yếu được viết bằng ngôn ngữ lập trình Rust, mặc dù C và C++ cũng được hỗ trợ. Tất cả các chương trình đều được biên dịch sang định dạng bytecode eBPF (extended Berkeley Packet Filter) đã sửa đổi của Solana trước khi triển khai trên chuỗi. Khung Anchor là một công cụ phát triển dựa trên Rust được sử dụng rộng rãi, trừu tượng hóa quản lý tài khoản và giảm thiểu mã lặp lại cho việc phát triển chương trình Solana.

Tại sao Solana gặp sự cố mạng nếu Sealevel rất nhanh?

Các sự cố mạng năm 2021 và 2022 của Solana không phải do lỗi trong logic thực thi song song của Sealevel. Chúng là kết quả của lượng lớn giao dịch rác và giao dịch bị lỗi làm quá tải lớp thu nhận giao dịch của mạng, một hệ thống riêng biệt ở phía trước Sealevel. Giới hạn TPS của Sealevel mô tả số lượng giao dịch hợp lệ mà nó có thể xử lý; nó không làm cho mạng miễn nhiễm với các cuộc tấn công tràn ngập giao dịch ở lớp thu nhận.

Mối quan hệ giữa Proof of History và Sealevel là gì?

Proof of History (PoH) cho phép Sealevel bằng cách thiết lập một thứ tự giao dịch đáng tin cậy trước khi thực thi bắt đầu. PoH là một cơ chế đồng hồ mật mã tạo ra một chuỗi dấu thời gian có thể xác minh mà mọi trình xác thực đều đồng ý. Vì thứ tự giao dịch đã được xác định trước khi Sealevel nhận được các giao dịch, Sealevel không cần phải tạm dừng và phối hợp với các trình xác thực. Nó có thể ngay lập tức lên lịch các giao dịch không xung đột trên các luồng xử lý song song.

Kết luận: Sealevel có ý nghĩa gì đối với Tương lai của Solana

Sealevel là câu trả lời rõ ràng nhất mà Solana đưa ra cho câu hỏi mà mọi blockchain phải đối mặt: làm thế nào để xử lý nhiều giao dịch hơn mà không làm mất đi tính bảo mật hoặc phi tập trung?

Thực thi song song của Sealevel là một khả năng kiến trúc thực tế và được ghi chép rõ ràng, tách biệt mô hình thực thi của Solana khỏi mọi blockchain thực thi tuần tự ở Lớp-1. Thông lượng thực tế của nó có ý nghĩa, cao hơn đáng kể so với lớp cơ sở của Ethereum, nhưng vẫn thấp hơn mức tối đa lý thuyết và vẫn chịu sự hạn chế của lớp thu nhận đã gây ra các sự cố mạng. Độ bền của nó như một lợi thế cạnh tranh phụ thuộc vào sự phát triển của hệ sinh thái và tốc độ của các kiến trúc thực thi song song cạnh tranh cũng như thiết kế của chính trình chạy.

Việc ra mắt trình khách xác thực Firedancer và sự trưởng thành của các chuỗi song song cạnh tranh như Monad sẽ làm sắc nét bức tranh cạnh tranh trong những năm tới. Câu hỏi liên quan không còn là liệu việc thực thi song song ở lớp cơ sở có khả thi hay không. Đó là cách tiếp cận kiến trúc nào phục vụ tốt nhất cho từng trường hợp sử dụng ở quy mô lớn.

Đọc thêm

• Thực thi Hợp đồng Thông minh của Ethereum: Khung giao dịch 5 bước
• Mô hình tài khoản hoạt động như thế nào trên các kiến trúc Trên chuỗi
• So sánh Kiến trúc Lớp-1 của Tiền điện tử: Near Protocol so với FetchAI

Nguồn

1. Anatoly Yakovenko, "Solana: A new architecture for a high performance blockchain v0.8.13," 2017. https://solana.com/solana-whitepaper.pdf
2. Tài liệu dành cho nhà phát triển Solana: mô hình lập trình và mô hình tài khoản. https://docs.solana.com/developing/programming-model/accounts
3. Tài liệu chương trình trên chuỗi Solana. https://docs.solana.com/developing/on-chain-programs/overview
4. Ethereum Foundation: Tài liệu Máy ảo Ethereum (EVM). https://ethereum.org/en/developers/docs/evm/
5. Báo cáo sự cố mạng và hiệu suất của Solana. https://solana.com/news/
6. Tài liệu thực thi song song Aptos Block-STM. https://aptoslabs.com/developer