Mọi điều bạn cần biết về bản cập nhật v1.18 của Solana

Giới thiệu

Việc bản cập nhật 1.18 của Solana được đại đa số áp dụng là một cột mốc quan trọng. Bản cập nhật mang đến hàng loạt cải tiến và tính năng mới nhằm nâng cao hiệu năng, độ tin cậy và hiệu quả của mạng. Một trong những thay đổi đáng chú ý nhất là sự ra mắt của bộ lập lịch trung tâm. Bộ lập lịch mới này giúp tinh giản quá trình xử lý giao dịch, đồng thời bảo đảm việc tính toán mức độ ưu tiên chính xác và hiệu quả hơn. Các cải tiến khác đối với môi trường runtime và hoạt động triển khai chương trình cũng giúp mang lại hiệu năng ổn định hơn, ngay cả khi tải mạng đạt đỉnh.

Bài viết này khám phá các cập nhật và cải tiến có trong bản phát hành 1.18. Chúng ta sẽ tìm hiểu động lực đằng sau những thay đổi này, chi tiết của các tính năng mới và tác động dự kiến của chúng đối với việc cải thiện mạng. Dù bạn là người vận hành validator, nhà phát triển hay người dùng Solana thông thường, phần tổng quan toàn diện về bản cập nhật 1.18 này sẽ cung cấp thông tin cần thiết để bạn hiểu và tận dụng lợi ích từ những cải tiến mới.

Trước tiên, chúng ta cần tìm hiểu về Anza, một công ty phát triển mới thành lập đang thúc đẩy những thay đổi này, cùng vai trò của họ trong quá trình phát triển liên tục của Solana.

Anza là gì?

Anza là một công ty phát triển phần mềm mới thành lập, do các cựu lãnh đạo và kỹ sư cốt lõi của Solana Labs sáng lập. Sự ra đời của Anza là một bước đi chiến lược nhằm củng cố hệ sinh thái Solana, với mục tiêu nâng cao độ tin cậy, tính phi tập trung và sức mạnh của mạng. Anza được thành lập để phát triển hệ sinh thái Solana thông qua việc xây dựng cơ sở hạ tầng thiết yếu, đóng góp cho các giao thức quan trọng và thúc đẩy đổi mới công cụ.

Đội ngũ sáng lập gồm Jeff Washington, Stephen Akridge, Jed Halfon, Amber Christiansen, Pankaj Garg, Jon Cinque và một số kỹ sư cốt lõi từ Solana Labs.

Anza tập trung phát triển và hoàn thiện các client validator của Solana thông qua việc tạo ra Agave — một fork của client validator Solana Labs. Tham vọng của Anza không chỉ dừng ở việc phát triển client validator mà còn hướng tới các cải tiến trên toàn hệ sinh thái. Trong đó có việc phát triển Token Extensions và một chuỗi công cụ Rust / Clang tùy chỉnh. Bằng cách thúc đẩy phương thức phát triển cởi mở và mang tính cộng tác, Anza cam kết đẩy nhanh và cải thiện hệ sinh thái Solana.

Agave là gì?

Như đã đề cập ngắn gọn ở phần trước, Agave là một fork của client validator Solana Labs do Anza dẫn dắt. Trong ngữ cảnh này, thuật ngữ “fork” có nghĩa là đội ngũ phát triển của Anza lấy mã hiện có từ kho lưu trữ Solana Labs và bắt đầu một hướng phát triển mới, tách biệt với cơ sở mã gốc. Điều này cho phép Anza triển khai các cải tiến, tính năng và tối ưu hóa riêng cho client Solana Labs.

Quá trình di chuyển

Quá trình chuyển client sang tổ chức GitHub của Anza bắt đầu vào ngày 1 tháng 3. Ban đầu, Agave sẽ phản chiếu kho lưu trữ Solana Labs để cộng đồng có thời gian thích nghi. Trong giai đoạn này, Anza sẽ xử lý việc đóng các pull request (PR) và chuyển những issue liên quan sang kho lưu trữ của Agave. Agave và các phiên bản 1.17, 1.18 của client Solana Labs sẽ có chức năng giống hệt nhau. Anza đặt mục tiêu phát hành Agave v2.0 vào mùa hè này, đồng thời lưu trữ client Solana Labs và khuyến nghị 100% mạng chuyển sang client Agave mới.

Quá trình di chuyển từ Solana Labs sang Agave được theo dõi công khai trên GitHub của họ.

Agave Runtime

Agave Runtime kế thừa kiến trúc nền tảng từ Solana Virtual Machine (SVM) và là xương sống để thực thi các chức năng cốt lõi do Sealevel runtime xác định. 

Giao thức Solana xác định runtime là một thành phần thiết yếu để xử lý giao dịch và cập nhật trạng thái trong cơ sở dữ liệu tài khoản. Đặc tả này đã được các client Agave và Firedancer áp dụng rồi tiếp tục hoàn thiện. Điểm cốt lõi của SVM là khả năng thực thi song song tất cả chương trình Solana và sửa đổi trạng thái tài khoản.

Khái niệm bank đóng vai trò then chốt trong việc xử lý giao dịch và tìm hiểu các thay đổi sắp có trong 1.18. Một bank vừa là một phần logic, vừa là biểu diễn trạng thái của sổ cái tại một thời điểm cụ thể. Nó hoạt động như một bộ điều khiển tinh vi, quản lý cơ sở dữ liệu tài khoản, giám sát việc theo dõi tài khoản client, quản lý quá trình thực thi chương trình, đồng thời duy trì tính toàn vẹn và tiến trình của sổ cái Solana. Một bank đóng gói trạng thái hình thành từ các giao dịch có trong một block nhất định, đóng vai trò như ảnh chụp nhanh của sổ cái tại thời điểm đó.

Mỗi bank được trang bị bộ nhớ đệm và các tham chiếu cần thiết để thực thi giao dịch, cho phép khởi tạo từ ảnh chụp nhanh trước đó hoặc genesis block. Trong Banking Stage, nơi validator xử lý giao dịch, các bank được dùng để tập hợp block rồi xác minh tính toàn vẹn của chúng. Vòng đời này gồm tải tài khoản, xử lý giao dịch, đóng băng bank để chốt trạng thái và cuối cùng xác lập bank làm root nhằm bảo đảm tính vĩnh viễn.

Nhìn chung, công cụ xử lý giao dịch trong Agave Runtime có nhiệm vụ tải, biên dịch và thực thi chương trình. Công cụ này sử dụng biên dịch Just-In-Time (JIT), lưu các chương trình đã biên dịch vào bộ nhớ đệm để tối ưu hiệu quả thực thi và giảm việc biên dịch lại không cần thiết. Các chương trình được biên dịch sang định dạng eBPF trước khi triển khai. Sau đó, runtime sử dụng bộ công cụ rBPF để tạo một máy ảo eBPF, thực hiện biên dịch JIT từ eBPF sang các lệnh mã máy x86_64 và tận dụng tối đa phần cứng hiện có. Điều này bảo đảm các chương trình được thực thi hiệu quả.

Bản cập nhật 1.18 giới thiệu bộ lập lịch giao dịch trung tâm, gắn chặt với những cải thiện hiệu quả vận hành mà Agave Runtime mang lại. Bằng cách cải thiện cách biên dịch, thực thi và quản lý giao dịch thông qua các bank, bản cập nhật 1.18 tạo ra quy trình lập lịch tinh gọn và hiệu quả hơn. Nhờ đó, giao dịch được xử lý nhanh hơn và thông lượng được nâng cao. Agave Runtime mới cùng client của nó là nền tảng cho những cải tiến này. Vì vậy, chúng ta cần có hiểu biết tổng quan trước khi đi sâu vào những điểm phức tạp của bộ lập lịch mới. 

Nếu muốn tìm hiểu thêm về Agave Runtime, tôi khuyên bạn đọc bài viết của Joe Caulfield về chủ đề này. Bài viết đi sâu vào nhiều chi tiết và cung cấp các đoạn mã hữu ích xuyên suốt.

Bộ lập lịch giao dịch hiệu quả hơn

Cách triển khai hiện tại

Trong pipeline xử lý giao dịch, các gói giao dịch trước tiên đi vào hệ thống qua ingress gói tin. Sau đó, chữ ký của các gói được xác minh trong giai đoạn SigVerify. Bước này bảo đảm mỗi giao dịch đều hợp lệ và được người gửi cho phép.

Sau khi xác minh chữ ký, các giao dịch được gửi đến Banking Stage. Banking Stage có sáu luồng — hai luồng chuyên xử lý giao dịch bỏ phiếu từ Transaction Processing Unit (TPU) hoặc Gossip, và bốn luồng tập trung vào giao dịch không bỏ phiếu. Mỗi luồng hoạt động độc lập và nhận các gói tin từ một kênh dùng chung. Cụ thể, SigVerify gửi các gói tin theo từng lô, còn mỗi luồng lấy giao dịch từ kênh dùng chung đó rồi lưu vào bộ đệm cục bộ. 

Bộ đệm cục bộ nhận giao dịch, xác định mức độ ưu tiên rồi sắp xếp tương ứng. Hàng đợi này có tính động, liên tục cập nhật để phản ánh những thay đổi theo thời gian thực về trạng thái giao dịch và nhu cầu của mạng. Khi giao dịch được thêm vào hàng đợi, thứ tự của chúng được đánh giá lại để bảo đảm các giao dịch có mức ưu tiên cao nhất sẵn sàng được xử lý trước.

Quá trình này diễn ra liên tục, còn điều xảy ra với các gói giao dịch phụ thuộc vào vị trí của validator trong lịch leader. Nếu validator không được lên lịch trở thành leader trong tương lai gần, validator sẽ chuyển tiếp các gói tin đến leader sắp tới rồi loại bỏ chúng. Khi validator tiến gần đến slot được lên lịch làm leader (còn khoảng ~20 slot), validator vẫn tiếp tục chuyển tiếp nhưng không còn loại bỏ các gói tin. Điều này bảo đảm các gói tin có thể được đưa vào một trong các block của chính validator nếu các leader khác không xử lý chúng. Khi chỉ còn 2 slot trước lúc trở thành leader, validator bắt đầu giữ các gói tin — tiếp nhận nhưng chưa làm gì để có thể xử lý chúng khi validator trở thành leader.

Trong quá trình tạo block, mỗi luồng lấy 128 giao dịch đầu tiên từ hàng đợi cục bộ, cố gắng giành lock, sau đó kiểm tra, tải, thực thi, ghi lại và commit giao dịch. Nếu không giành được lock, giao dịch sẽ được thử lại sau. Hãy tìm hiểu kỹ hơn từng bước:

• Lock: Bước này kiểm tra những giao dịch mà luồng có thể giành lock. Mỗi giao dịch sẽ đọc và ghi một số tài khoản, vì vậy validator cần bảo đảm không có xung đột
• Checks: Bước này kiểm tra giao dịch có quá cũ hoặc đã được xử lý hay chưa. Lưu ý rằng các bank có bộ nhớ đệm trạng thái để theo dõi giao dịch trong 150–300 slot gần nhất
• Loads: Bước này tải các tài khoản cần thiết để thực thi một giao dịch nhất định. Bước này cũng kiểm tra liệu người trả phí có thực sự đủ khả năng thanh toán phí hay không và chương trình được gọi có hợp lệ hay không. Về cơ bản, bước này tải các tài khoản và thực hiện một số thiết lập ban đầu
• Execute: Bước này thực thi từng giao dịch
• Record: Kết quả của các giao dịch đã thực thi được gửi đến Proof of History Service để băm. Đây là nơi chữ ký giao dịch được gửi đi
• Commit: Nếu bước ghi thành công, các giao dịch sẽ được commit. Bước này cũng truyền các thay đổi trở lại hệ thống tài khoản để những giao dịch sau này trong slot hiện tại hoặc các slot tiếp theo có được trạng thái mới nhất của từng tài khoản‍
• Unlock: Các lock được đặt cho từng tài khoản ở bước đầu tiên sẽ được gỡ bỏ

Banking Stage sử dụng phương pháp multi-iterator để tạo các lô giao dịch này. Multi-iterator là một mẫu lập trình cho phép duyệt đồng thời một tập dữ liệu theo nhiều trình tự. Hãy hình dung có nhiều người cùng đọc một cuốn sách, mỗi người bắt đầu từ một chương khác nhau và phối hợp để bảo đảm họ không đọc cùng một trang vào cùng thời điểm nếu cách hiểu nội dung của họ có thể ảnh hưởng lẫn nhau. Trong Banking Stage, những “người đọc” này là các iterator, còn “cuốn sách” là tập hợp giao dịch đang chờ xử lý. Mục tiêu của multi-iterator là sàng lọc giao dịch hiệu quả, nhóm chúng thành các lô có thể xử lý mà không xảy ra xung đột lock.

Ban đầu, các giao dịch được tuần tự hóa thành một vector theo mức độ ưu tiên. Điều này cung cấp cho multi-iterator một trình tự có cấu trúc để phân chia các giao dịch thành những lô không xung đột. Multi-iterator bắt đầu từ đầu vector đã tuần tự hóa, đặt các iterator tại những điểm mà giao dịch không xung đột với nhau. Qua đó, nó tạo ra các lô gồm 128 giao dịch không có xung đột đọc-ghi hoặc ghi-ghi. Nếu một giao dịch xung đột với lô đang được tạo, giao dịch đó sẽ bị bỏ qua và không được đánh dấu, cho phép đưa vào một lô sau khi xung đột không còn tồn tại. Quá trình lặp này điều chỉnh linh hoạt trong khi giao dịch tiếp tục được xử lý. 

Sau khi tạo lô thành công, các giao dịch được thực thi. Nếu thành công, chúng được ghi vào Proof of History Service và truyền phát lên mạng.

Những vấn đề của cách triển khai hiện tại

Cách triển khai hiện tại có một số điểm có thể ảnh hưởng tiêu cực đến hiệu năng, dẫn đến nguy cơ tắc nghẽn trong quá trình xử lý giao dịch và thiếu nhất quán khi xác định mức độ ưu tiên. Những thách thức này chủ yếu bắt nguồn từ kiến trúc của Banking Stage và bản chất của cách hệ thống xử lý giao dịch.

Một vấn đề căn bản là bốn luồng độc lập xử lý giao dịch không bỏ phiếu có cách nhìn riêng về mức độ ưu tiên của giao dịch trong từng luồng. Sự khác biệt này có thể gây dao động hoặc thiếu nhất quán trong thứ tự giao dịch. Những khác biệt trở nên rõ rệt hơn khi mọi giao dịch có mức ưu tiên cao đều xung đột. Vì mỗi luồng về cơ bản lấy ngẫu nhiên các gói tin từ kênh dùng chung của SigVerify, mỗi luồng sẽ có một tập hợp ngẫu nhiên trong tổng số giao dịch. Trong các sự kiện cạnh tranh, chẳng hạn như đợt mint NFT phổ biến, nhiều giao dịch có mức ưu tiên cao nhiều khả năng sẽ xuất hiện trong nhiều luồng Banking Stage. Đây là vấn đề vì nó có thể gây xung đột lock giữa các luồng. Do làm việc với các tập hợp mức ưu tiên khác nhau, các luồng có thể cạnh tranh để xử lý những giao dịch ưu tiên cao này, vô tình lãng phí thời gian xử lý do các lần giành lock không thành công.

Hãy hình dung Banking Stage như một dàn nhạc, trong đó mỗi luồng là một bộ phận khác nhau — bộ dây, bộ đồng, bộ gỗ và bộ gõ. Trong điều kiện lý tưởng, nhạc trưởng sẽ điều phối các bộ phận để bảo đảm màn trình diễn hài hòa. Tuy nhiên, hệ thống hiện tại giống như một dàn nhạc cố gắng biểu diễn một tác phẩm phức tạp mà không có nhạc trưởng. Mỗi bộ phận chơi giai điệu riêng và thường xuyên xung đột với nhau. Các giao dịch có mức ưu tiên cao chính là những đoạn độc tấu mà mọi bộ phận đều cố chơi cùng lúc, gây ra sự hỗn loạn. Việc thiếu phối hợp này cho thấy Solana cần một “nhạc trưởng” tập trung để bảo đảm quá trình xử lý giao dịch hiệu quả và hài hòa, giống như cách nhạc trưởng dẫn dắt một dàn nhạc.

Bộ lập lịch giao dịch mới

Bản cập nhật 1.18 giới thiệu một luồng lập lịch trung tâm, thay thế mô hình trước đây gồm bốn luồng banking độc lập, mỗi luồng tự quản lý việc ưu tiên và xử lý giao dịch. Trong cấu trúc mới này, bộ lập lịch trung tâm là nơi duy nhất nhận giao dịch từ giai đoạn SigVerify. Nó xây dựng hàng đợi ưu tiên và triển khai đồ thị phụ thuộc để quản lý việc ưu tiên và xử lý giao dịch.

Đồ thị phụ thuộc này được gọi là prio-graph. Đây là một đồ thị có hướng không chu trình được đánh giá trì hoãn khi giao dịch mới được thêm vào. Các giao dịch được chèn vào đồ thị để tạo thành chuỗi thực thi, sau đó được lấy ra theo thứ tự ưu tiên-thời gian. Khi xử lý các giao dịch xung đột, giao dịch được chèn trước sẽ luôn có mức ưu tiên cao hơn. Trong ví dụ trên, chúng ta có các giao dịch từ A đến H. Lưu ý rằng giao dịch A và E có mức ưu tiên cao nhất trong các chuỗi tương ứng và không xung đột. Bộ lập lịch di chuyển từ trái sang phải, xử lý giao dịch theo lô:

Giao dịch A và E được xử lý trong lô đầu tiên; tiếp theo là B và F; sau đó là C, D, G; và cuối cùng là H. Như bạn có thể thấy, các giao dịch có mức ưu tiên cao nhất nằm ở đầu đồ thị (tức là ngoài cùng bên trái). Khi bộ lập lịch xem xét giao dịch theo thứ tự giảm dần, nó xác định các xung đột. Nếu một giao dịch xung đột với giao dịch có mức ưu tiên cao hơn, một cạnh sẽ được tạo trong đồ thị để biểu diễn sự phụ thuộc này (ví dụ: C và D xung đột với B).

Mô hình bộ lập lịch mới giải quyết một số vấn đề chính vốn có của phương pháp multi-iterator:

• Nhất quán khi xử lý mức độ ưu tiên: Bằng cách tập trung hóa việc tiếp nhận và lập lịch giao dịch, hệ thống mới bảo đảm mọi giao dịch được xử lý theo thứ tự ưu tiên nhất quán. Điều này loại bỏ dao động trước đây do nhiều luồng có cách nhìn khác nhau về mức độ ưu tiên của giao dịch
• Giảm độ trễ xử lý: Prio-graph bảo đảm các lô được chuẩn bị để thực thi có khả năng thành công rất cao mà không gặp xung đột lock, qua đó tinh giản thời gian xử lý và mọi độ trễ do tranh chấp lock gây ra. Hãy lưu ý cụm từ “có khả năng thành công rất cao” — nói prio-graph tạo ra các lô không thể thất bại khi lock là không hoàn toàn chính xác, vì chúng vẫn có thể xung đột với các luồng bỏ phiếu, dù đây là trường hợp biên rất hiếm
• Khả năng mở rộng và tính linh hoạt: Thiết kế bộ lập lịch mới này cho phép tăng số lượng luồng mà không gặp những lo ngại trước đây về việc gia tăng xung đột lock. Điều này có được nhờ góc nhìn tập trung về các lock và việc phân phối giao dịch có kiểm soát hơn giữa các worker 

Việc giới thiệu bộ lập lịch trung tâm trong 1.18 dự kiến sẽ cải thiện đáng kể cách xử lý giao dịch, giảm độ phức tạp và chi phí vận hành liên quan đến hệ thống trước đây. Điều này nhiều khả năng sẽ giúp xử lý giao dịch nhanh hơn, tăng thông lượng và ổn định mạng hơn. Do 1.18 phát hành chậm, bộ lập lịch đã được cải thiện kể từ khi ra đời. Ví dụ: việc xác minh precompile cho giao dịch đã được chuyển sang các luồng worker để nâng cao hiệu quả. Ngoài ra, các giới hạn CU hiện hợp lý hơn, với tỷ lệ ước tính/thực tế thấp hơn nhiều so với bộ lập lịch cũ. Bộ lập lịch mới hiện có thể dùng CU để điều tiết các hàng đợi công việc đã lập lịch, ngăn quá nhiều công việc bị xếp hàng do xung đột tài khoản.

Lưu ý rằng bộ lập lịch trung tâm không được bật theo mặc định và phải được bật bằng cờ --block-production-method central-scheduler mới khi khởi động validator. Hiện tại, tính năng này chỉ được bật khi người dùng chủ động chọn, nhưng sẽ trở thành bộ lập lịch mặc định trong các bản phát hành tương lai. Ngoài ra, bộ lập lịch cũ có thể được bật bằng cờ --block-production-method thread-local-multi-iterator (cờ này được bật theo mặc định, nhưng vui lòng không làm vậy trong các bản phát hành tương lai — bộ lập lịch trung tâm hiệu quả hơn nhiều và giải quyết các vấn đề của bộ lập lịch cũ).

Tính mức độ ưu tiên hiệu quả hơn 

1.18 cũng hoàn thiện cách xác định mức độ ưu tiên của giao dịch, giúp quy trình công bằng và hiệu quả hơn về mức sử dụng tài nguyên và thu hồi chi phí. Trước đây, việc ưu tiên giao dịch chủ yếu dựa trên mức độ ưu tiên của ngân sách tính toán, đôi khi dẫn đến định giá compute unit chưa tối ưu. Nguyên nhân là quá trình ưu tiên chưa xem xét đầy đủ các khoản phí cơ sở đã thu, dẫn đến trường hợp tài nguyên bị định giá quá thấp và ảnh hưởng đến hiệu quả vận hành của mạng.

Phương pháp mới điều chỉnh cách tính mức độ ưu tiên của giao dịch để xem xét phí giao dịch và chi phí liên quan theo công thức Mức độ ưu tiên = Phí / (Chi phí + 1). Trong đó, phí là phí giao dịch gắn với một giao dịch nhất định, còn chi phí là mức tiêu thụ tài nguyên và năng lực tính toán do mô hình chi phí của Solana xác định. Việc thêm “1” vào mẫu số là biện pháp an toàn để tránh phép chia cho 0. 

Chúng ta có thể phân tích thêm công thức để làm rõ Phí và Chi phí:

Chi phí của một giao dịch hiện được tính toàn diện, có xét đến mọi chi phí tính toán và vận hành liên quan. Điều này bảo đảm phép tính mức độ ưu tiên phản ánh mức tiêu thụ tài nguyên thực tế của giao dịch. Theo đó, nhà phát triển và người dùng sẽ được ưu tiên cao hơn nếu yêu cầu ít compute unit hơn. Điều này cũng có nghĩa là các giao dịch chuyển đơn giản, ngay cả khi không có phí ưu tiên, vẫn có một mức độ ưu tiên nhất định trong hàng đợi.

Cải thiện hoạt động triển khai chương trình

1.18 cũng cải thiện đáng kể hoạt động triển khai chương trình về độ tin cậy khi triển khai và hiệu quả thực thi. 

Bản cập nhật mới giải quyết vấn đề các chương trình được triển khai trong slot cuối cùng của một epoch không áp dụng chính xác những thay đổi môi trường runtime đã lên kế hoạch cho epoch tiếp theo. Do đó, một chương trình được triển khai trong giai đoạn chuyển tiếp này sẽ dùng nhầm môi trường runtime cũ. 1.18 điều chỉnh quy trình triển khai để bảo đảm môi trường runtime của mọi chương trình được triển khai vào cuối epoch đều đồng bộ với môi trường của epoch sắp tới.

1.18 cũng giải quyết việc không thể đặt giá hoặc giới hạn compute unit cho các giao dịch triển khai bằng cách thêm cờ --with-compute-unit-price vào các lệnh triển khai chương trình của CLI. Có thể dùng cờ này với các lệnh solana program deploy và solana program write-buffer. Giới hạn compute unit được thiết lập bằng cách mô phỏng từng loại giao dịch triển khai và đặt giới hạn bằng số compute unit đã tiêu thụ.  

Một cải tiến quan trọng khác liên quan đến cách xử lý blockhash cho các đợt triển khai chương trình lớn. Trước 1.18, các giao dịch được gửi bằng sign_all_messages_and_send bị giới hạn ở 100 TPS. Với các chương trình lớn hơn, số lượng giao dịch triển khai có thể lên đến hàng nghìn. Điều này có nghĩa là giao dịch có thể bị trì hoãn và có nguy cơ dùng blockhash đã hết hạn vì nhiều giao dịch sẽ bị trễ hơn 10 giây mỗi lần. 1.18 trì hoãn việc ký các giao dịch triển khai bằng blockhash gần đây cho đến sau khoảng thời gian điều tiết. Blockhash hiện được làm mới mỗi 5 giây, vì vậy các đợt triển khai có hơn 500 giao dịch sẽ được hưởng lợi nhờ sử dụng blockhash mới hơn.

Ngoài ra, 1.18 còn cải thiện cách mạng xử lý hoạt động triển khai chương trình và xác minh giao dịch. Trước đây, một số chương trình bị đánh dấu nhầm là FailedVerification do lỗi trong việc xác định trạng thái tài khoản. Điều này có thể gắn nhãn sai cho những chương trình chưa thực sự thất bại ở bất kỳ bước kiểm tra nào. Các chương trình này hiện được xác định chính xác là Closed nếu chúng không được phép hoạt động. Thay đổi này bảo đảm chỉ những chương trình có vấn đề mới bị gắn cờ để kiểm tra lại và giúp ngăn việc xác minh lại không cần thiết.

Quy trình cập nhật trạng thái chương trình cũng được hoàn thiện. Giờ đây, chương trình có thể chuyển từ trạng thái Closed sang trạng thái hoạt động ngay trong cùng slot triển khai. Điều này giúp chương trình đi vào hoạt động nhanh chóng và đáng tin cậy hơn, đặc biệt quan trọng trong thời gian nhu cầu cao. Tuy nhiên, cần lưu ý rằng cải tiến này vẫn chịu giới hạn thời gian chờ một slot khi hủy triển khai/triển khai lại/triển khai và độ trễ hiển thị một slot. Do đó, dù những điều chỉnh này giúp quản lý tải mạng hiệu quả hơn và ngăn một số dạng tắc nghẽn, chúng không thay đổi đáng kể quy trình làm việc của nhà phát triển dApp.

“Bản vá tắc nghẽn” — Xử lý tắc nghẽn tốt hơn

Testnet phiên bản 1.18.11, được ca ngợi là “Bản vá tắc nghẽn,” đã đề xuất các thay đổi nhằm giải quyết tình trạng tắc nghẽn gần đây của Solana. Lưu ý rằng bản phát hành này không dành riêng cho 1.18 và đã được backport sang 1.17.31. Dù vậy, chúng ta vẫn cần thảo luận về nó.

Thay đổi lớn là QUIC hiện coi các peer có lượng stake cực thấp như peer không stake trong Stake-Weighted Quality of Service (SWQoS). Mục đích là giải quyết việc các node có stake rất nhỏ có thể lạm dụng hệ thống để nhận lượng băng thông không tương xứng. Ngoài ra, các chỉ số hiện tại không thể cho biết tỷ lệ gói tin được gửi xuống và bị điều tiết giữa các node có stake so với node không stake. Vì vậy, các chỉ số này đã được bổ sung để tăng khả năng quan sát. Cách xử lý các phần gói tin cũng được tối ưu hóa bằng việc thay các phiên bản vec bằng smallvec để tiết kiệm một lần cấp phát cho mỗi gói tin. Điều này khả thi vì các stream có kích thước bằng gói tin, nên dự kiến số lượng sẽ ít. 

Trước đây, trong Banking Stage, mọi gói tin đều được chuyển tiếp đến node tiếp theo. Tuy nhiên, 1.18 thay đổi điều này để chỉ chuyển tiếp các gói tin từ node có stake. Bản cập nhật này khiến các kết nối có stake trở nên quan trọng hơn bao giờ hết trong tương lai, vì chúng có trọng số lớn hơn khi tính mức độ ưu tiên và chuyển tiếp giao dịch.

Cải thiện tài liệu

Bản cập nhật 1.18 cũng cải thiện đáng kể khả năng hỗ trợ bản dịch cho tài liệu Solana chính thức, giúp người dùng toàn cầu dễ dàng tiếp cận hơn. Các cập nhật gồm nâng cấp CLI và cấu hình Crowdin (giúp tinh giản việc đồng bộ tài liệu giữa các ngôn ngữ), đồng thời giới thiệu lệnh serve mới để kiểm thử cục bộ tốt hơn qua Docusaurus. Tài liệu cũng cải thiện cách xử lý nội dung tĩnh bằng cách liên kết trực tiếp các tệp PDF với blob trên GitHub để tránh vấn đề về đường dẫn tương đối trong các bản build đã dịch.

Đối với nhà phát triển, quy trình đóng góp bản dịch được làm rõ bằng một README đã cập nhật, hướng dẫn xử lý các vấn đề thường gặp như biến môi trường bắt buộc và lỗi build điển hình. Bên cạnh đó là các cải tiến đối với quy trình tích hợp liên tục, hiện chỉ bao gồm bản dịch trong các bản build của kênh ổn định. Điều này bảo đảm chỉ tài liệu đã được kiểm duyệt và ổn định mới đến tay người dùng cuối. Những thay đổi này nhằm đơn giản hóa việc đóng góp, nâng cao chất lượng tài liệu chính thức và giúp mọi người dùng tiếp cận thông tin đáng tin cậy, chính xác.

Kết luận

Được Anza thúc đẩy, bản cập nhật 1.18 cải thiện đáng kể cách xử lý giao dịch, tính mức độ ưu tiên, triển khai chương trình, tài liệu chính thức và hiệu năng tổng thể của mạng. Với sự ra mắt của bộ lập lịch trung tâm cùng nhiều bản sửa lỗi nhằm giải quyết tình trạng tắc nghẽn gần đây, Solana được trang bị tốt hơn để xử lý tải cao điểm và bảo đảm mạng vận hành hiệu quả, đáng tin cậy. Solana là cơ hội tốt nhất để hiện thực hóa một blockchain có khả năng mở rộng, và bản cập nhật này khẳng định tiềm năng đó.

Nếu đã đọc đến đây, cảm ơn bạn, anon! Hãy nhớ nhập địa chỉ email bên dưới để không bao giờ bỏ lỡ thông tin mới nhất về Solana. Sẵn sàng tìm hiểu sâu hơn? Hãy khám phá các bài viết mới nhất trên blog Helius và tiếp tục hành trình Solana của bạn ngay hôm nay.

Tài nguyên bổ sung

• Client Agave
• Lịch trình chuyển đổi sang Agave
• Anza
• Crate Prio-graph
• Banking Stage và bộ lập lịch của Solana
• Tiêu điểm: Bộ lập lịch của Solana