MỚI: Helius mua lại Light Protocol
Mọi điều bạn cần biết về bản cập nhật v1.17 của Solana
Blog/Cập nhật

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

Developer Experience Engineer0xIchigo trên X0xIchigo trên LinkedIn0xIchigo trên GitHub
Đọc trong 17 phút
Mục lục

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

Mạng Solana đã đạt một cột mốc quan trọng khi v1.17, phiên bản mới nhất của client validator Solana Labs, được đại đa số áp dụng. Sau sự cố gián đoạn mạng gần đây, các validator đã khởi động lại bằng phiên bản 1.17.20. Tại thời điểm viết bài, ~68,6% validator đang chạy phiên bản 1.17.21 và ~31,3% đang chạy phiên bản 1.17.20.  Phiên bản mới này mang đến một loạt cải tiến nhằm nâng cao hiệu quả, khả năng mở rộng và các trường hợp sử dụng của mạng. Từ những bước tiến tiên phong về bằng chứng không kiến thức đến việc tinh chỉnh giao thức Gossip, v1.17 đánh dấu một bước ngoặt trong quá trình phát triển liên tục của Solana.

Bài viết này trình bày mọi điều bạn cần biết về bản cập nhật phiên bản 1.17 cho client validator Solana Labs. Chúng ta sẽ tìm hiểu quy trình kiểm thử nghiêm ngặt của v1.17, sự cố gián đoạn mạng gần đây và các tính năng mới được triển khai trong bản cập nhật này.

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

v1.17 đã chạy trên testnet từ ngày 3 tháng 10 năm 2023. Phiên bản này thường xuyên được kiểm thử tải với khối lượng transaction lớn. Solana Labs cũng triển khai một số node canary mainnet-beta chạy v1.17 để theo dõi độ ổn định của phiên bản trong điều kiện thực tế. Các node này đã hoạt động ổn định trong vài tháng qua. Bạn có thể xem hoạt động và tiến trình trước đây của các node canary này bằng cách truy cập kênh #canaries-monitoring trong Solana Tech Discord. Ngoài ra, kể từ ngày 4 tháng 12 năm 2023, một nhóm nhỏ node mainnet-beta tình nguyện đã nâng cấp lên v1.17. 

Nhiều trình fuzz runtime đã được phát triển để thực thi các transaction được ngẫu nhiên hóa một phần, nhằm 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. Các transaction này được thực thi trên nhiều phiên bản để đảm bảo hiệu năng nhất quán. v1.17 đã được các đơn vị bên ngoài kiểm toán nhiều lần; các báo cáo sẽ được đăng lên kho lưu trữ GitHub Solana Security Audits khi có sẵn.

Sự cố gián đoạn tháng 2

Vào lúc 9:53 UTC ngày 6 tháng 2 năm 2024, mainnet-beta gặp sự cố khiến quá trình hoàn tất block tạm thời dừng lại. Hoạt động mạng bị gián đoạn trong khoảng năm giờ, cho đến khi cơ chế đồng thuận tiếp tục vào lúc 14:55 UTC. Nguyên nhân sự cố là một lỗi liên quan đến cách mạng biên dịch và lưu vào bộ nhớ đệm mã của chương trình để thực thi, đặc biệt ảnh hưởng đến các phiên bản program loader cũ.

Nguyên nhân gốc bắt nguồn từ cách validator xử lý đầu ra được biên dịch đúng lúc (JIT) của các chương trình thường dùng. Một hệ thống bộ nhớ đệm mới, vốn nhằm tối ưu hóa quy trình này, đã vô tình tạo ra lỗi nghiêm trọng. Hệ thống mới có thể rơi vào vòng lặp biên dịch lại vô hạn đối với một số chương trình cũ. Điều này làm đình trệ cơ chế đồng thuận của Solana vì phần lớn validator gặp phải vấn đề và không thể tiếp tục xử lý transaction.

Nguyên nhân gốc được xác định nhanh chóng vì lỗi này có nhiều điểm tương đồng với sự cố devnet gần đây. 1.17.20 đã được sửa đổi để xử lý trực tiếp vấn đề, đồng thời các validator phối hợp khởi động lại mạng. Bản sửa lỗi gồm hai phần: một giải pháp ngắn hạn vô hiệu hóa khả năng kích hoạt vòng lặp vô hạn bằng cách ngừng hỗ trợ hai loader cũ có thể gây ra vòng lặp, và một điều chỉnh toàn diện hơn đối với hệ thống bộ nhớ đệm chương trình mới để ngăn các vấn đề tương tự trong tương lai. 

Báo cáo chính thức, ban đầu do Anza công bố, có thể được xem tại đây.

ZK Token Proof Program

ZK Token Proof Program dự kiến được phát hành cùng bản cập nhật 1.16. Tuy nhiên, việc kích hoạt đã bị trì hoãn do quá trình kiểm toán mở rộng. Lịch kích hoạt Feature Gate đánh dấu chương trình là Đang chờ kích hoạt trên testnet với phiên bản tối thiểu là 1.17.12. 

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

Khi ZK Token Proof Program được kích hoạt, tính năng Chuyển khoản bảo mật cuối cùng sẽ khả dụng. Chuyển khoản bảo mật sử dụng bằng chứng không kiến thức để mã hóa số dư token và số tiền chuyển của SPL token. Mục tiêu chung ở đây là tính bảo mật thay vì tính ẩn danh. Mã hóa đồng cấu cho phép thực hiện phép tính trên dữ liệu đã mã hóa mà không cần giải mã. Ví dụ, có thể cộng hoặc trừ số dư mà không cần giải mã rồi mã hóa lại các giá trị được chỉ định trong những phép toán này. Vì vậy, các phép tính này được mã hóa theo cách tương tự như khi chúng được áp dụng trên văn bản thuần túy.

Chuyển khoản bảo mật sử dụng Twisted ElGamal Encryption và Sigma Protocols để thực hiện transaction an toàn, riêng tư mà không tiết lộ thông tin nhạy cảm. 

Thông tin bổ sung:

  • Twisted ElGamal Encryption là một biến thể đơn giản của cơ chế mã hóa ElGamal tiêu chuẩn, trong đó bản mã được chia thành một cam kết Pedersen của thông điệp đã mã hóa và một khóa hỗ trợ giải mã để cho phép thực hiện các phép toán ẩn trên bản mã
  • Sigma Protocols được dùng để xác thực Chuyển khoản bảo mật. Đây là một lớp bằng chứng không kiến thức đặc biệt, trong đó một bên (tức bên chứng minh) có thể chứng minh cho bên còn lại (tức bên xác minh) rằng họ biết một số thông tin nhất định mà không tiết lộ thông tin đó

Chuyển khoản bảo mật chỉ cho phép account nắm giữ khóa giải mã xem số dư đã mã hóa của mình. Hệ thống kiểm toán viên toàn cục được triển khai cho các tình huống cần bên thứ ba xem xét (ví dụ: kiểm tra tuân thủ hoặc kiểm toán). Hệ thống này cho phép chủ account cấp quyền đọc có chọn lọc đối với các account cụ thể thông qua khóa giải mã riêng, đồng thời tích hợp một “khóa mã hóa của kiểm toán viên” cho hoạt động mint nhằm hỗ trợ kiểm toán an toàn.

Các transaction sử dụng tham số đã mã hóa cho số tiền của người gửi, người nhận và kiểm toán viên, cùng với bằng chứng để bảo đảm quyền riêng tư và tính toàn vẹn. Số dư account được chia thành “Đang chờ” và “Khả dụng” để ngăn các cuộc tấn công front-running. Nếu không, người dùng độc hại có thể gửi token đến một account để làm mất hiệu lực các bằng chứng được tạo bằng số dư đã mã hóa.

Cần lưu ý rằng Chuyển khoản bảo mật yêu cầu sử dụng một cặp khóa mới. 

Hỗ trợ dòng lệnh

Hỗ trợ Giao diện dòng lệnh (CLI) cho Chuyển khoản bảo mật thông qua crate spl-token cũng đã khả dụng. Sau khi được kích hoạt, lệnh create-token đã được mở rộng để bao gồm cờ –enable-confidential-transfers auto. Điều này cho phép người dùng mint token với tiện ích Chuyển khoản bảo mật được bật. Ngoài ra còn có một số lệnh hữu ích khác, chẳng hạn như:

  • configure-confidential-transfer-account - cấu hình một account có sẵn để sử dụng Chuyển khoản bảo mật. Chỉ chủ account mới có thể cấu hình Chuyển khoản bảo mật cho account
  • deposit-confidential-tokens - gửi token từ một account không bảo mật vào account bảo mật. Lưu ý rằng token đã gửi sẽ không còn tồn tại trong số dư không bảo mật của account vì chúng đã được chuyển hoàn toàn sang số dư bảo mật
  • apply-pending-balance - chuyển số dư từ “Đang chờ” sang “Khả dụng”. Thao tác này là cần thiết vì bất cứ khi nào account nhận token bảo mật từ một giao dịch chuyển hoặc nạp tiền, số dư sẽ xuất hiện trong phần “Đang chờ” của account. Do đó, người dùng không thể truy cập tiền ngay lập tức và cần áp dụng số dư đang chờ
  • transfer (khi bật cờ –confidential) - chuyển token đến một account khác đã được cấu hình cho Chuyển khoản bảo mật. Lưu ý rằng thao tác này có thể mất nhiều thời gian hơn giao dịch chuyển token thông thường vì cần nhiều transaction phụ thuộc lẫn nhau
  • withdraw-confidential-tokens - rút token từ số dư bảo mật của account sang số dư không bảo mật. Hãy bảo đảm mọi số dư đang chờ đã được áp dụng trước khi chạy lệnh này để rút toàn bộ số token dự kiến
  • update-confidential-transfer-settings - cập nhật cấu hình chuyển khoản bảo mật cho một token mint nhất định. Lệnh cung cấp tùy chọn tự động đặt chính sách phê duyệt chuyển khoản bảo mật (tức cờ –aprove-policy) và đặt khóa công khai của kiểm toán viên (tức cờ –auditor-pubkey). Lệnh cũng có các cờ bổ sung để chỉ định blockhash, authority của Chuyển khoản bảo mật, tệp cấu hình, thông tin bên trả phí, URL JSON RPC, thông tin account nonce, định dạng đầu ra và ID chương trình token

Khả năng tương thích 

Lưu ý rằng các tổ hợp tiện ích sau không hoạt động hoặc không phù hợp để kết hợp với Chuyển khoản bảo mật:

  • Chuyển khoản bảo mật + Không thể chuyển nhượng
  • Chuyển khoản bảo mật + phí (sẽ không hoạt động cho đến phiên bản 1.18)
  • Chuyển khoản bảo mật + Transfer Hooks (vì các giao dịch chuyển này chỉ có thể thấy account nguồn hoặc đích, do đó không thể xử lý số tiền được chuyển)

Kiểm toán

Chuyển khoản bảo mật và Token-2022 Program nói chung đã được kiểm toán kỹ lưỡng bởi các công ty như Halborn, Zellic, Trail of Bits, NCC Group và OtterSec (hai lần — lần kiểm toán đầu tiên tập trung vào Token-2022, còn lần kiểm toán thứ hai tập trung cụ thể vào Chuyển khoản bảo mật).

Syscall Poseidon

Poseidon là một họ hàm băm thân thiện với bằng chứng không kiến thức. Các hàm băm Poseidon được phần lớn dự án blockchain dựa trên ZK sử dụng, bao gồm Zcash, Mina và Light Protocol của Solana. Hiện tại, việc tính toán hàm băm Poseidon trên Solana quá tốn kém để thực hiện trong một transaction. Các syscall Poseidon sẽ thay đổi điều này. Chúng hiện dự kiến được phát hành cùng v1.17.5 và đang chờ kích hoạt trên testnet.

Giải thích theo cách dễ hiểu

Hãy tưởng tượng bạn đang dùng một máy tính nâng cao có thể giải hiệu quả một số loại câu đố dùng trong giao tiếp bảo mật. Máy tính này nhận các mẩu thông tin, chia nhỏ rồi trộn chúng lại với nhau theo một cách độc đáo. Thông tin được trộn sao cho nội dung ban đầu bị ẩn hoàn toàn nhưng vẫn có thể xác minh.

Quá trình trộn này sử dụng một phương pháp đặc biệt để cộng các số và nâng chúng lên những số mũ nhất định thuộc một tập hợp số đã được xác định trước. Phương pháp này bảo đảm quá trình trộn luôn được thực hiện kỹ lưỡng và nhất quán.

Poseidon thực hiện chính xác điều tương tự như chiếc máy tính nâng cao này. Những loại hàm băm này đặc biệt hiệu quả khi tạo mạch không kiến thức. Về cơ bản, mạch là một tập hợp các phép toán. Chúng biểu diễn bằng toán học việc một bên (bên chứng minh) chứng minh cho bên khác (bên xác minh) rằng họ biết một số thông tin nhất định mà không tiết lộ thông tin đó. Nói chung, hãy hình dung đây là việc chứng minh bạn biết bên trong một chiếc hộp niêm phong có gì mà không thực sự mở nó. Bạn có thể chứng minh điều này cho người đã niêm phong hộp bằng một chuỗi thao tác gõ hoặc các bước. Những thao tác hoặc bước này được thiết kế để không tiết lộ bất kỳ chi tiết nào về nội dung hay cách mở hộp, và chỉ có thể được hiểu nếu bạn đã mở hộp.

Điều này rất hữu ích cho blockchain vì khả năng giữ transaction riêng tư trong khi vẫn xác minh được tính xác thực là vô cùng quan trọng. 

Các đặc tính thân thiện với ZK

Các hàm băm Poseidon được xem là thân thiện với bằng chứng không kiến thức vì một số lý do. Cụ thể:

  • Poseidon được thiết kế để thực hiện hiệu quả các phép toán phổ biến trong tính toán bằng chứng không kiến thức (tức phép cộng, phép nhân và phép lũy thừa)
  • Các hệ thống bằng chứng không kiến thức yêu cầu chuyển logic tính toán thành bằng chứng mật mã. Thiết kế của Poseidon tạo ra độ phức tạp mạch thấp hơn các hàm băm khác nhờ thiết kế thân thiện với số học, S-box được tối ưu hóa, tham số có thể tùy chỉnh và số vòng thấp (tức chuỗi thao tác được áp dụng lặp lại cho dữ liệu đầu vào hoặc trạng thái nội bộ của hàm băm). Điều này có nghĩa là cần ít bước hơn để tạo bằng chứng cho một dữ liệu nhất định
  • Các hàm băm Poseidon dựa trên cấu trúc sponge. Nghĩa là Poseidon được thiết kế bằng một lớp thuật toán nhận chuỗi bit có độ dài bất kỳ và tạo đầu ra có độ dài bất kỳ. Điều này giúp việc tích hợp các hàm băm Poseidon vào nhiều ứng dụng không kiến thức trở nên cực kỳ dễ dàng.

So sánh với các hàm băm truyền thống

Hiệu quả tính toán của Poseidon được tối ưu riêng cho bằng chứng không kiến thức mang lại lợi thế rõ rệt so với các phép toán tổng quát và tốn nhiều tài nguyên của những hàm băm truyền thống như SHA-256. 

Dù an toàn và đáng tin cậy, các hàm băm truyền thống thường tạo ra những mạch lớn và phức tạp hơn trong bằng chứng không kiến thức. Nguyên nhân là các hàm băm này ban đầu không được thiết kế theo những ràng buộc cụ thể của hệ thống bằng chứng không kiến thức. Trên blockchain, bằng chứng không kiến thức thực hiện tính toán trong các trường hữu hạn. Trường hữu hạn là một tập hợp số mà trong đó mọi phép toán số học (cộng, trừ, nhân và chia) đều được thực hiện theo phép modulo với một số nguyên tố. Điều này khiến các giá trị “quay vòng” trong tập hợp và bảo đảm mọi phép toán luôn nằm trong tập hợp số đó. 

Các hàm băm truyền thống như SHA-256 phụ thuộc nhiều vào phép toán bit và các chuỗi thao tác được xác định trước. Những chức năng này không tương thích trực tiếp với các phép toán số học dùng trong trường hữu hạn. Việc triển khai chúng trong bối cảnh trường hữu hạn sẽ cần thêm nhiều bước, cuối cùng làm tăng độ phức tạp của mạch.

Hơn nữa, các hàm băm truyền thống thường sử dụng số học modulo dựa trên lũy thừa của 2. Cách này khác với số học modulo của trường hữu hạn dùng trong bằng chứng không kiến thức, vốn thường dựa trên số nguyên tố. Sự không tương thích này đòi hỏi thêm nhiều bước nữa, làm tăng kích thước và độ phức tạp của mạch.

Mục tiêu của việc xây dựng bằng chứng không kiến thức là tạo ra một biểu diễn toán học của logic tính toán để chứng minh rằng một bên biết thông tin nhất định mà không tiết lộ thông tin đó. Việc biểu diễn kiến thức này hiệu quả và đơn giản có vai trò thiết yếu đối với khả năng mở rộng của các bằng chứng. Họ hàm băm Poseidon trực tiếp đáp ứng những nhu cầu này bằng các phép toán hiệu quả trong trường hữu hạn, qua đó giảm đáng kể số bước cần thiết để tạo mạch. Kết quả là mạch nhỏ hơn và ít phức tạp hơn. Các hàm băm truyền thống không được tối ưu riêng cho nhu cầu xây dựng mạch — chúng được thiết kế cho mục đích chung. 

Việc tích hợp syscall Poseidon trong v1.17 đánh dấu bước chuyển sang sử dụng các công cụ mật mã chuyên biệt để đơn giản hóa quá trình tạo và xác thực bằng chứng không kiến thức trên Solana. Điều này giúp xử lý transaction nhanh hơn, giảm chi phí và tăng khả năng mở rộng cho các phép tính không kiến thức. Cùng với tính linh hoạt và khả năng tùy chỉnh của Poseidon, việc tạo và xác thực bằng chứng không kiến thức trên Solana trở nên dễ dàng hơn nhiều.

Chi tiết triển khai

v1.17 giới thiệu syscall sol_poseidon — một lời gọi hệ thống nhận đầu vào là một lát cắt byte 2D và tính hàm băm Poseidon tương ứng làm đầu ra. Syscall này sử dụng đường cong BN254 và nhận các tham số Poseidon sau:

  • S-box x^5 (tức các hộp thay thế)
  • Đầu vào với 1 ≤ n ≤ 12
  • Độ rộng với 2 ≤ t ≤ 13
  • 8 vòng đầy đủ và số vòng một phần tùy thuộc vào t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Việc tính toán các hàm băm Poseidon này sẽ được thực hiện bằng crate light-posiedon, vốn đã được kiểm toán và tương thích với Circom. 

Lưu ý rằng trong phần tiếp theo, chúng tôi thảo luận về việc bổ sung syscall alt_bn128. BN254 thường được gọi là BN128 (theo số bit bảo mật), alt_bn128 hoặc alt_bn_128. Ở đây, chúng tôi đang đề cập đến cùng một đường cong.

Syscall alt_bn128

v1.16 đề xuất tăng cường hỗ trợ runtime cho các phép tính không kiến thức, cụ thể là các phép toán đường cong elliptic 128 bit. Các syscall alt_bn128, vốn rất quan trọng để tạo bằng chứng hiệu quả, dự kiến được phát hành cùng v1.16. Tuy nhiên, chúng đã bị trì hoãn. Lịch kích hoạt Feature Gate hiện dự kiến các syscall alt_bn128 sẽ có trong v1.17.15 và đang chờ kích hoạt trên mainnet-beta, còn tính năng nén alt_bn128 dự kiến có trong v1.17.15 và đang chờ kích hoạt trên testnet.

Thông tin bổ sung dành cho những ai quan tâm sâu hơn: alt_bn128 chỉ việc triển khai đường cong elliptic Barreto-Naehrig (BN-128). Đây là một đường cong elliptic cụ thể, thân thiện với phép ghép cặp, cho phép thực hiện zk-SNARK hiệu quả (Lập luận tri thức không tương tác, ngắn gọn và không kiến thức). Đường cong này được xem là “thân thiện với phép ghép cặp” vì cho phép thực hiện một số phép tính và bằng chứng không kiến thức hiệu quả hơn. Trong Solana, các syscall alt_bn128 cho phép chương trình tận dụng đường cong này để đơn giản hóa việc xác minh bằng chứng không kiến thức, qua đó tăng cường bảo mật và quyền riêng tư. Việc bổ sung syscall g1 và g2 của alt_bn128 giúp hỗ trợ nén bằng chứng Groth16. Điều này làm giảm đáng kể không gian cần thiết cho mỗi bằng chứng, tối ưu hiệu quả dung lượng cho các chương trình Solana.

Việc giới thiệu syscall alt_bn128 giúp thu hẹp khoảng cách tương thích giữa Solana và các hợp đồng dựa trên Solidity, vốn phụ thuộc vào hợp đồng được biên dịch sẵn để thực hiện các phép toán đường cong elliptic được quy định trong EIP-196, EIP-197 và EIP-198. Các phép toán này (bn256Add, bn256ScalarMult, bn256Pairing) hỗ trợ xác minh zk-SNARK trong giới hạn gas của Ethereum. Các hợp đồng Solidity dựa vào những phép toán đường cong elliptic này giờ đây có thể chuyển sang hoặc thậm chí tương tác với Solana dễ dàng hơn.

Cải tiến Gossip

v1.17 cải thiện hiệu quả truyền thông điệp Gossip bằng cách tăng cường truyền thông điệp push và giảm phụ thuộc vào pull request. Việc tinh giản hoạt động của giao thức gossip giúp giảm mức sử dụng tài nguyên cho các validator đồng thuận.

Để hiểu rõ hơn, Dịch vụ Gossip của Solana đóng vai trò thiết yếu trong việc trao đổi thông tin giữa các validator. Thông tin này bao gồm độ cao ledger, thông tin liên hệ và phiếu bầu đồng thuận. Dịch vụ sử dụng thông điệp “push” và “pull” để chia sẻ cũng như xác minh thông tin trên toàn mạng. Hệ thống nhắn tin này bảo đảm mọi node luôn được đồng bộ. 

Trước đây, AccountsHashVerifier đẩy hàm băm account của mình lên gossip. Tuy nhiên, không thành phần mạng nào từng kéo dữ liệu này, khiến quy trình trở nên dư thừa. Các thao tác cũ, chẳng hạn như so sánh hàm băm account từ gossip với giá trị của các validator đã biết, đã bị loại bỏ khi EpochAccountsHash được giới thiệu.  Phương thức RPC getHealth cũng được viết lại để không còn phụ thuộc vào hàm băm account từ gossip — chúng ta sẽ tìm hiểu kỹ hơn trong phần tiếp theo. Vì vậy, kể từ v1.17, không còn thành phần nào kéo hàm băm account từ gossip. AccountsHashVerifier đã được sửa đổi để ngừng đẩy account lên gossip, đồng thời các hàm chịu trách nhiệm đẩy và kéo hàm băm account từ gossip cũng đã bị loại bỏ.

getHealth 

Trước đây, lời gọi RPC getHealth có thể phản ánh sai trạng thái của một node nhất định. Nguyên nhân là sự khác biệt giữa lệnh CLI solana catchup và lời gọi RPC getHealth, khiến một node có thể đồng thời được hiển thị là đã bắt kịp và đang tụt lại. Điều này có thể khiến các node khỏe mạnh bị đánh dấu nhầm là không khỏe mạnh và có khả năng bị loại khỏi RPC pool.

Ban đầu, tình trạng hoạt động được xác định bằng cách so sánh slot hàm băm account cục bộ được công bố trong gossip với slot của các node khác, sử dụng giá trị so sánh mặc định là 100 slot. Cách này có thể thiếu chính xác, đặc biệt đối với các node được cấu hình với giá trị lớn hơn 100 slot. getHealth đã được viết lại để sử dụng slot được xác nhận lạc quan mới nhất từ cluster (tức slot cuối cùng mà tất cả validator đã xử lý và được đại đa số xác nhận nhưng chưa được hoàn tất). Cách này cung cấp phép so sánh chính xác hơn vì có thể so sánh slot đã được cluster xác nhận với bank được xác nhận lạc quan mới nhất để xác định node đang tụt lại bao xa. Thay đổi này mang đến khả năng kiểm tra chi tiết hơn, giảm nguy cơ âm tính giả (tức node khỏe mạnh bị đánh dấu là không khỏe mạnh) và tránh bị ảnh hưởng bởi các vấn đề xảy ra với validator đã biết, qua đó ngăn hiệu ứng domino. 

Cờ –skip-health-check cũng đã được bổ sung cho các lệnh wait-for-restart-window và exit để xử lý vấn đề với getHealth. Cờ này cho phép validator bỏ qua bước kiểm tra xem node có khỏe mạnh hay không.

QUIC

v1.17 giới thiệu khả năng phát shred và thực hiện sửa chữa bằng QUIC. Các endpoint QUIC của Turbine và quy trình sửa chữa hiện bị vô hiệu hóa vì chưa cần thiết cho đến khi testnet chuyển hoàn toàn sang QUIC. Tuy nhiên, điều này đặt nền móng cho việc chuyển các giao thức này sang QUIC. Một số PR đã được hợp nhất để giới thiệu chức năng nền tảng này, bao gồm:

Kết nối TPU bất đồng bộ

v1.17 giới thiệu kết nối client TPU bất đồng bộ, cải thiện đáng kể cơ chế bộ nhớ đệm kết nối. Bản cập nhật này được thiết kế để giảm độ trễ transaction bằng cách cho phép thiết lập kết nối trong nền với kích thước connection pool mặc định là bốn. Kết nối client TPU bất đồng bộ bảo đảm quá trình xử lý transaction mượt mà hơn mà không cần thời gian chờ như kết nối đồng bộ. 

Tinh giản quá trình khởi động validator và cập nhật định dạng snapshot

v1.17 tinh giản quá trình khởi động validator bằng cách giới thiệu một cờ mới và cập nhật các định dạng tệp snapshot được hỗ trợ. Điều này giúp validator khởi động nhanh hơn, có ý nghĩa quan trọng vì góp phần tăng khả năng phục hồi của mạng bằng cách giảm thời gian ngừng hoạt động.

v1.17 giới thiệu cờ –use-snapshot-archives-at-startup mới. Cờ này cho phép validator đẩy nhanh quá trình khởi động bằng cách chọn giữa snapshot cục bộ, trạng thái cục bộ trên ổ đĩa hoặc tự động chọn tùy chọn mới nhất trong hai loại. Cờ này loại bỏ nhu cầu xử lý snapshot khi trạng thái trên ổ đĩa mới hơn, nhờ đó rút ngắn thời gian khởi động lại.

Trước đây, Solana hỗ trợ nhiều định dạng nén cho snapshot — các định dạng lưu trữ gồm bz2, gzip, zstd, lz4, tar và không nén. Tuy nhiên, bản cập nhật mới nhất thu hẹp lựa chọn xuống còn zstd và lz4 để tối ưu hiệu quả và giảm độ phức tạp khi hỗ trợ. Các định dạng khác đã ngừng được hỗ trợ cho đối số –snapshot-archive-format, mặc dù validator vẫn có thể đọc snapshot hiện có ở những định dạng này để bảo đảm khả năng tương thích ngược. Điều này vốn dĩ giúp đơn giản hóa giao diện dòng lệnh cho solana-validator và solana-ledger-tool. 

Kết luận

Với hàng loạt tính năng được triển khai và việc nhanh chóng khắc phục sự cố gián đoạn mạng gần đây, bản cập nhật v1.17 của Solana là một bước tiến lớn. Bản cập nhật mở ra khả năng và mức hỗ trợ chưa từng có cho công nghệ không kiến thức với việc phát hành ZK Token Program, syscall Poseidon và syscall alt_bn128. Cùng với các cải tiến dành cho validator và hiệu quả mạng, bản cập nhật này tạo nền tảng vững chắc cho phiên bản tiếp theo. Bản cập nhật có quy mô nhỏ hơn v1.16 và phù hợp với mục tiêu phát hành phiên bản mới ba tháng một lần. Bạn có thể xem lịch phát hành 1.18 tại đây.

Nếu đã đọc đến đây, cảm ơn bạn, anon! Hãy 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? 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 ngay hôm nay.

Tài nguyên bổ sung

Bài viết liên quan

Đăng ký nhận tin từ Helius

Luôn cập nhật những thông tin mới nhất về phát triển Solana và nhận thông báo khi chúng tôi đăng bài

Hình ảnh phóng to