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

Bài viết này nói về điều gì?

Mạng lưới validator của Solana đã đạt thành công mức siêu đa số trong việc áp dụng phiên bản 1.16, bản nâng cấp mới nhất cho client validator của Solana Labs. Sau một giai đoạn kiểm tra toàn diện với sự hỗ trợ tận tâm của các tình nguyện viên và node canary, cột mốc này là thành quả của gần mười tháng phát triển nghiêm ngặt.

Trong các phần tiếp theo, chúng ta sẽ tìm hiểu cách v1.16 được kiểm thử, cũng như hệ thống feature gate của Solana — một khuôn khổ kiểm soát cách các tính năng mới được triển khai theo từng giai đoạn trên mạng. Sau đó, chúng ta sẽ xem xét các tính năng mới được triển khai trong v1.16.

v1.16 đã được kiểm thử như thế nào?

v1.16 đã trải qua quá trình kiểm thử nghiêm ngặt trong vài tháng qua. Bản phát hành v1.16 đã chạy trên testnet từ ngày 7 tháng 6 năm 2023 và trải qua nhiều bài kiểm thử tải. Ngoài ra, một nhóm nhỏ các node tình nguyện đã cập nhật lên v1.16 từ ngày 23 tháng 8 năm 2023. Những tình nguyện viên này đã xác định và khắc phục nhiều vấn đề như RPC node khởi động chậm và lỗi bảo vệ chung. Solana Labs cũng triển khai một số node canary lên mainnet-beta để theo dõi độ ổn định của các node v1.16 trong điều kiện thực tế. Để xem hoạt động trước đây và tiến độ của các node canary này, hãy truy cập kênh #canaries-monitoring trên Discord Solana Tech.

Để phát hiện các trường hợp biên hoặc điều kiện tranh chấp hiếm gặp, nhiều runtime fuzzer đã được sử dụng để thực thi các giao dịch ngẫu nhiên một phần. Những giao dịch này được thực thi trên nhiều phiên bản runtime khác nhau nhằm bảo đảm hiệu suất nhất quán. v1.16 cũng đã được Halborn kiểm tra toàn diện. Các báo cáo kiểm tra được đăng lên repository này khi có sẵn.

Feature gate

Điều quan trọng cần lưu ý là một số tính năng được thảo luận trong các phần tiếp theo hiện chưa hoạt động. Thay vào đó, các tính năng được triển khai từ từ bằng hệ thống feature gate. Chúng được kích hoạt tại những epoch nhất định dựa trên mức độ ưu tiên tương đối và thứ tự kích hoạt trên các mạng khác. Cho đến nay, lịch kích hoạt feature gate được quyết định tùy từng trường hợp dựa trên một danh sách tiêu chí mà bạn có thể xem tại đây. Về cơ bản, các gate này cần được kích hoạt trước tiên trên testnet, sau đó là devnet và cuối cùng là mainnet-beta. Để kích hoạt một tính năng, kỹ sư có cặp khóa kích hoạt cần thiết sẽ gửi một giao dịch. Giao dịch này được xử lý và đưa tính năng vào hoạt động ở epoch tiếp theo. Mỗi mạng chỉ nên kích hoạt một feature gate tại một thời điểm để bảo đảm hiệu suất phù hợp. Cần lưu ý rằng một số tính năng có thể cần thời gian “soak”, điều này có thể trì hoãn việc kích hoạt các gate có mức ưu tiên thấp hơn.

Hệ thống feature gate này giúp bảo đảm các thay đổi phá vỡ đồng thuận không khiến validator chạy phiên bản mới hơn phân nhánh khỏi chuỗi chính thức nhưng vẫn tiếp tục tạo block. Ví dụ, validator v1.14 không biết về các tính năng mới của v1.16 và có thể làm sập mạng khi xảy ra tranh chấp. Một commit được hợp nhất trong tuần này vào codebase của Solana khuyến khích mọi thay đổi phá vỡ đồng thuận phải có Solana Improvement Document (SIMD). Mẫu issue dành cho feature gate giờ đây sẽ có thêm yêu cầu cung cấp SIMD của issue đó. Điều này giúp chuẩn hóa quy trình phát triển và tăng tính minh bạch cho các thay đổi mới thông qua tài liệu.

Chuyển khoản bảo mật

Chuyển khoản bảo mật, một tính năng do Token2022 giới thiệu, sử dụng bằng chứng không kiến thức để mã hóa số dư và số tiền giao dịch của token SPL. Mục tiêu chính của tính năng này là cải thiện quyền riêng tư của người dùng bằng cách chú trọng tính bảo mật thay vì tính ẩn danh.

Chuyển khoản bảo mật tận dụng Mã hóa Twisted ElGamal để thực hiện các phép toán trên số tiền đã mã hóa. Các giao dịch chuyển khoản này được xác thực bằng Sigma Protocols, một nhóm bằng chứng không kiến thức chuyên biệt mà trong đó một bên (bên chứng minh) có thể chứng minh với bên còn lại (bên xác minh) rằng họ biết một bí mật nhất định mà không thực sự tiết lộ bí mật đó. Hãy đọc bài viết Token2022 là gì? của chúng tôi để tìm hiểu sâu hơn về những điểm phức tạp của Chuyển khoản bảo mật.

Một tính năng hữu ích đi kèm với việc triển khai Chuyển khoản bảo mật là bổ sung hỗ trợ Giao diện dòng lệnh (CLI). Lệnh create-token đã được mở rộng để bổ sung cờ --enable-confidential-transfers, cho phép người dùng mint token với tính năng chuyển khoản bảo mật được bật. Ngoài ra, lệnh update-confidential-transfer-settings đã được thêm vào để cho phép thay đổi linh hoạt cấu hình chuyển khoản bảo mật của một mint nhất định. Nhờ đó, khóa kiểm toán viên và các thiết lập phê duyệt có thể được cập nhật.

Hỗ trợ runtime tốt hơn cho bằng chứng không kiến thức

Bản phát hành v1.16 tăng cường khả năng không kiến thức của Solana bằng cách cải thiện hỗ trợ runtime cho các phép tính không kiến thức, cụ thể là phép toán đường cong elliptic 128 bit. v1.16 giới thiệu các syscall alt_bn128, thành phần thiết yếu để tạo bằng chứng hiệu quả.

alt_bn128 đề cập đến một cách triển khai cụ thể của đường cong elliptic dùng cho các phép toán mật mã, được gọi là đường cong Barreto-Naehrig (BN-128). BN-128 là một loại đường cong elliptic thân thiện với phép ghép cặp, cho phép triển khai hiệu quả zk-SNARKs (Đối số kiến thức không tương tác, cô đọng và không kiến thức). Nói thêm, một đường cong elliptic được xem là “thân thiện với phép ghép cặp” nếu nó cho phép thực hiện một số phép tính hiệu quả hơn. Vì vậy, trong trường hợp này, việc sử dụng đường cong BN-128 giúp xử lý toán học và bằng chứng không kiến thức nhanh hơn đáng kể.

Syscall, hay lời gọi hệ thống, được dùng để yêu cầu dịch vụ từ kernel của hệ điều hành. Trong bối cảnh Solana, syscall cho phép các chương trình chạy trong Solana Virtual Machine (SVM) tương tác với tài nguyên bên ngoài.

Do đó, syscall alt_bn128 là lời gọi mà các chương trình Solana có thể sử dụng để tương tác với đường cong BN-128 có hiệu suất cao. Điều này giúp tinh giản quá trình xác minh bằng chứng không kiến thức, đồng thời mang lại các tính năng bảo mật và quyền riêng tư tốt hơn trên Solana. Các syscall alt_bn128 g1 và g2 cũng mới được bổ sung, cho phép nén bằng chứng Groth16. Điều này rất quan trọng vì mỗi bằng chứng loại này chiếm 256 byte dữ liệu instruction, còn các chương trình Solana riêng tư (PSP) hiện cần xác minh hai bằng chứng Groth16. Với khả năng nén g1 và g2, số byte cần thiết cho mỗi bằng chứng có thể giảm một nửa xuống còn 128 byte, yếu tố thiết yếu để sử dụng không gian hiệu quả.

Ngoài ra, các contract dựa trên Solidity gặp vấn đề tương thích với Solana nếu chứa lời gọi đến những contract biên dịch sẵn sau đây để thực hiện phép toán đường cong elliptic:

• bn256Add - Thực hiện phép cộng trong các phép toán đường cong elliptic
• bn256ScalarMult - Thực hiện phép nhân vô hướng trong các phép toán đường cong elliptic
• bn256Pairing - Thực hiện phép ghép cặp đường cong elliptic để xác minh zkSNARKs trong giới hạn gas của block

Các phép toán này được tiêu chuẩn hóa trên Ethereum thông qua EIP-196, EIP-197 và EIP-198. Việc giới thiệu các syscall alt_bn128 là một bước tiến lớn trong quá trình thu hẹp khoảng cách tương thích. Giờ đây, các contract Solidity dựa vào những phép toán đường cong elliptic này có thể chuyển sang hoặc thậm chí tương tác với Solana dễ dàng hơn.

Việc đưa syscall alt_bn128 vào bản cập nhật v1.16 của Solana đánh dấu một bước tiến lớn trong khả năng xử lý bằng chứng không kiến thức một cách hiệu quả và an toàn. Hãy xem các pull request sau nếu bạn muốn tìm hiểu thêm về syscall alt_bn128:

• Đã thêm các syscall alt_bn
• Đã thêm các bài kiểm thử syscall alt_bn128 và khắc phục những vấn đề liên quan
• Tính năng (syscall): thêm khả năng nén altbn128 g1 & g2

Validator

Bản cập nhật v1.16 giảm đáng kể mức sử dụng RAM của validator. Trước đây, Solana dựa vào RAM để lập chỉ mục account. Giờ đây, hệ thống đã được cấu hình lại để mặc định lập chỉ mục account trên ổ đĩa, qua đó giảm đáng kể mức sử dụng RAM. Yanshu từ Luganodes cho biết kể từ khi v1.16 được phát hành, validator của họ chạy ổn định chỉ với ~39 GB RAM, so với ~120 GB ở các phiên bản trước:

Bản phát hành v1.16 cũng giới thiệu một hệ thống lấy mẫu peer được thiết kế lại cho các gossip pull request. Hệ thống mới này giúp giảm băng thông khởi động cho validator. Trong các phiên bản trước, validator có thể gặp giới hạn băng thông do số lượng gossip pull request quá lớn. Điều này có thể làm validator chậm lại hoặc thậm chí bị quá tải. v1.16 giải quyết vấn đề bằng cách bổ sung biến thời gian kể từ yêu cầu gần nhất. Biến này được dùng để đánh giá lưu lượng truy cập đến và áp dụng giới hạn tốc độ, ngăn validator bị quá tải khi khởi động.

Các validator đã stake bị tụt lại phía sau mạng giờ đây có thể bắt kịp trạng thái hiện tại nhanh hơn nhờ tính năng yêu cầu sửa chữa mới, với mức độ ưu tiên tỷ lệ thuận với lượng stake. Mỗi khi một validator có lượng stake lớn bị phân nhánh khỏi mạng, validator đó sẽ gửi yêu cầu sửa chữa. Giờ đây, validator này sẽ nhận shred nhanh hơn vì có lượng stake lớn. Điều này bảo đảm validator không còn bị phân nhánh khỏi mạng và có thể tiếp tục đóng góp. Các validator đã stake có mức ưu tiên xử lý yêu cầu sửa chữa cao hơn RPC node vì RPC node không tạo block.

Ngưỡng độ trễ để gửi yêu cầu sửa chữa shred cũng đã tăng từ 100ms lên 200ms. Thay đổi này nhằm giảm số lượng yêu cầu sửa chữa cho các shred cuối cùng vẫn được phân phối qua Turbine. Nói thêm, Turbine là cơ chế truyền block nhiều lớp mà Solana sử dụng để phát các mục ledger đến tất cả node. Trong cơ chế này, cluster Solana tự chia thành nhiều lớp node và mỗi node trong một lớp nhất định có trách nhiệm truyền dữ liệu xuống lớp tiếp theo. Đây là một điều chỉnh quan trọng vì nó giảm thiểu các yêu cầu sửa chữa không cần thiết, qua đó tăng hiệu quả truyền dữ liệu của Turbine.

Việc vận hành validator riêng chưa bao giờ dễ dàng đến thế. Với những người muốn vận hành validator riêng, Solana cung cấp Solana Validator Education, một chuỗi workshop dành cho validator trên kênh YouTube của họ.

Hỗ trợ account có thể thay đổi kích thước

Khi triển khai một chương trình trên Solana, dung lượng được phân bổ cho chương trình luôn bằng hai lần kích thước chương trình. v1.16 cho phép triển khai chương trình với data account có thể thay đổi kích thước. Điều này có nghĩa là bạn có thể triển khai chương trình với account nhỏ hơn, sau đó mở rộng kích thước và chỉ trả phí cho phần chênh lệch bộ nhớ. Khả năng hỗ trợ account có thể thay đổi kích thước mang lại sự linh hoạt cao hơn và phân bổ tài nguyên hiệu quả hơn cho các nhà phát triển triển khai ứng dụng trên Solana.

Epoch Accounts Hash

Trong các phiên bản trước, đã có vấn đề liên quan đến block và việc xác minh toàn bộ account trong trạng thái. Nếu một validator không tương tác với một account nhất định trong thời gian dài, validator đó có thể lưu phiên bản bị hỏng của account mà không hề nhận ra. Nguyên nhân là trạng thái account không được đối chiếu với trạng thái do các validator node khác nắm giữ vì không có giao dịch nào thay đổi trạng thái của account đó.

v1.16 giải quyết vấn đề này bằng cách giới thiệu Epoch Accounts Hash. Đây là hash của tất cả account, được tạo ở cuối mỗi epoch ngay cả khi những account đó chưa được tương tác. Epoch Accounts Hash cho phép mạng xác định và phân nhánh các node có dữ liệu bị hỏng, qua đó tăng tính toàn vẹn và bảo mật của Solana.

Tinh chỉnh hệ thống

Tinh chỉnh hệ thống là quá trình tối ưu hóa cấu hình hệ điều hành và phần cứng của validator để đạt hiệu suất tối ưu. Trong bản phát hành v1.16, solana-sys-tuner đã bị loại bỏ và kiểm thử thủ công hiện được khuyến nghị. Tùy chọn này bị loại bỏ vì ở các phiên bản trước, các cột TransactionStatus và AddressSignature của RocksDB không được dọn dẹp đúng cách. Ngoài ra, quá trình nén định kỳ nhằm thu hồi không gian lưu trữ bị tắt theo mặc định. Điều này khiến các cột đó tăng trưởng không giới hạn trên những node chạy với cờ --enable-rpc-transaction-history. Nhờ commit sau đây, các validator sử dụng cờ này giờ sẽ quản lý không gian lưu trữ hiệu quả hơn. Đây là một cải tiến đáng kể giúp tinh giản yêu cầu lưu trữ của validator bằng cách loại bỏ nhu cầu lưu trữ trạng thái giao dịch và chữ ký địa chỉ không cần thiết.

Kết luận

Bản phát hành v1.16 của Solana đánh dấu một cột mốc quan trọng, kết tinh từ mười tháng phát triển. Việc phát hành chậm là do QUIC được ưu tiên, vì vậy những cải tiến về chuyển khoản bảo mật, hỗ trợ không kiến thức và tối ưu hóa validator này đã được mong đợi từ lâu. Dù vậy, những cải tiến này thực sự mang tính đột phá. Bản phát hành này giúp Solana đạt được những cấp độ mới về hiệu quả và quyền riêng tư.

Trong thời gian tới, Solana Labs sẽ chuyển sang chu kỳ phát hành linh hoạt hơn, với mục tiêu phát hành phiên bản mới khoảng ba tháng một lần. Các bản phát hành trong tương lai sẽ nhỏ hơn nhiều so với v1.16. Điều này cho phép lặp nhanh hơn và giảm rủi ro khi triển khai. Bạn có thể xem lịch phát hành v1.17 tại đây. Đây hứa hẹn sẽ là một bản phát hành rất được mong đợi khác, với khả năng hỗ trợ không kiến thức tốt hơn nữa và có thể giới thiệu syscall Posidon.

Nếu bạn đã đọc đến đây, anon, xin cảm ơn! Với chu kỳ phát hành linh hoạt hơn cùng hàng loạt tính năng và cải tiến mới, tương lai của Solana đang tươi sáng hơn bao giờ hết. Dù bạn là nhà phát triển, nhà đầu tư, validator hay người đam mê Solana, hãy nhớ theo dõi các bản phát hành sắp tới! Hành trình Solana của bạn chỉ mới bắt đầu.

Tài nguyên bổ sung / Đọc thêm

• Lịch kích hoạt feature gate
• Quy trình kích hoạt feature gate
• Các cuộc kiểm tra bảo mật Solana
• Solana Beach - Trang validator

‍