Hard fork Toccata của Kaspa: Giao ước, mã ZK và mục tiêu mới vào tháng 6

gàuBản nâng cấp Toccata sắp tới của sẽ bổ sung hai lộ trình lập trình mới cho mạng lưới: lập trình giao ước L1 gốc và cơ sở hạ tầng ứng dụng không tiết lộ thông tin (zero-knowledge - zk), với việc kích hoạt mạng chính hiện được lên kế hoạch từ ngày 5 đến 20 tháng 6 năm 2026, lùi lại so với mục tiêu ban đầu là ngày 5 tháng 5.

Michael Sutton của Kaspa Core đã xuất bản một bài viết. cập nhật chi tiết Bài viết này sẽ đề cập đến những gì bản cập nhật hard fork bao gồm, lý do dời ngày và dự kiến ​​những diễn biến trong vài tháng tới. Bản cập nhật này ban đầu được khởi xướng bởi Ori Newman nhằm mục đích đưa các giao ước vào công cụ kịch bản của Kaspa, một phần để đáp ứng cuộc thảo luận về OP_CAT trong cộng đồng Bitcoin. Kể từ đó, nó đã phát triển thành một thứ lớn hơn đáng kể.

Toccata Hard Fork là gì?

Toccata là một bản nâng cấp hệ thống (hard fork) theo kế hoạch dành cho mạng Kaspa, nhằm bổ sung các khả năng mới trực tiếp vào lớp nền tảng. Đối với những người chưa quen thuộc, hard fork là một bản nâng cấp giao thức không tương thích ngược. Tất cả các nút mạng phải nâng cấp để tiếp tục tham gia vào mạng.

Tên gọi này tiếp nối truyền thống của Kaspa trong việc sử dụng các tham chiếu âm nhạc cho các bản nâng cấp lớn. Bản nâng cấp này lấy tên từ một thể loại âm nhạc cổ điển, toccata, một tác phẩm được thiết kế để phô diễn kỹ năng kỹ thuật trên nhạc cụ bàn phím.

Nhìn chung, Toccata bổ sung thêm hai yếu tố cho Kaspa:

• Lập trình giao ước L1 bản địa thông qua một trình biên dịch mới có tên là Silverscript
• Dựa trên cơ sở hạ tầng ứng dụng zkđược xây dựng trên nền tảng của chính những giao ước đó.

Đây không phải là những hệ thống có thể thay thế cho nhau. Chúng phục vụ các trường hợp sử dụng khác nhau và nhắm đến các đối tượng nhà phát triển khác nhau.

Giao ước là gì và tại sao chúng lại quan trọng đối với Kaspa?

Các điều khoản ràng buộc là những điều kiện được đặt ra về cách thức chi tiêu số tiền trong kết quả giao dịch trong tương lai. Trong một giao dịch Bitcoin hoặc Kaspa tiêu chuẩn, sau khi tiền được gửi đi, người nhận có thể làm bất cứ điều gì họ muốn với số tiền đó. Các điều khoản ràng buộc thay đổi điều đó bằng cách nhúng trực tiếp các quy tắc chi tiêu vào kịch bản giao dịch.

Kaspa sử dụng mô hình UTXO, tương tự như Bitcoin, trong đó mỗi giao dịch tiêu thụ các đầu ra hiện có và tạo ra các đầu ra mới. Các điều khoản trong hệ thống UTXO cho phép các nhà phát triển xây dựng các luồng đa hợp đồng có trạng thái phức tạp đáng ngạc nhiên, mặc dù quá trình tính toán cơ bản vẫn diễn ra cục bộ trong mỗi UTXO.

Để giúp việc phát triển giao ước trở nên dễ tiếp cận hơn, Kaspa Core đang hoàn thiện Silverscript, một trình biên dịch do Ori Newman, Michael Sutton, IzioDev và Manyfest khởi xướng. Silverscript được thiết kế để giúp việc viết và triển khai các giao ước phức tạp trực tiếp trên Kaspa L1 trở nên dễ dàng và an toàn hơn, mà không cần các nhà phát triển phải làm việc ở cấp độ công cụ kịch bản thô.

Ứng dụng dựa trên ZK là gì?

Trụ cột lập trình thứ hai được giới thiệu trong Toccata dựa trên các ứng dụng zk. Đây là trụ cột phức tạp hơn về mặt kỹ thuật và đáng được phân tích kỹ lưỡng.

Khám phá những dự án đầy hứa hẹn...

Các dự án đầy hứa hẹn...

(Quảng cáo)

Bài viết còn tiếp tục...

ZK là viết tắt của zero-knowledge (không tiết lộ thông tin), một phương pháp mã hóa cho phép một bên chứng minh điều gì đó là đúng mà không tiết lộ dữ liệu cơ bản. Bằng chứng ZK ngày càng được sử dụng rộng rãi trong việc mở rộng quy mô blockchain vì chúng cho phép xác minh các phép tính ngoài chuỗi trên chuỗi một cách tiết kiệm và an toàn.

Trong ngữ cảnh này, "dựa trên" có nghĩa là hệ thống zk tuân thủ hoàn toàn trình tự L1. Một ứng dụng zk dựa trên L1 không thể thêm hoặc xóa giao dịch một cách độc lập. Nó được neo vào thứ tự giao dịch riêng của Kaspa, điều này làm cho nó đáng tin cậy mà không cần một bộ điều khiển trình tự riêng biệt.

Toccata giới thiệu một số thành phần để hỗ trợ điều này:

• Mã lệnh xác minh ZKbao gồm trình xác thực Groth16 linh hoạt và trình xác thực RISC Zero STARK.
• Mã lệnh truy cập cam kết trình tự, cho phép các ứng dụng dựa trên đó tự neo vào thứ tự L1.
• KIP-21Một kiến ​​trúc cam kết trình tự phân vùng đảm bảo chi phí chứng minh của ứng dụng zk tỷ lệ thuận với hoạt động của chính nó, chứ không phải với hoạt động tổng thể của DAG.

Bộ xác thực RISC Zero STARK đã được triển khai và kích hoạt trên mạng thử nghiệm 12. Việc có kích hoạt trên mạng chính hay không vẫn đang được quyết định.

Tại sao việc chứng minh chi phí lại quan trọng?

Để bất kỳ ứng dụng zk nào có thể hoạt động hiệu quả, chi phí tạo bằng chứng cần phải tỷ lệ thuận với những gì ứng dụng đó thực hiện. Nếu một ứng dụng zk phải chứng minh công việc liên quan đến tất cả hoạt động trên DAG rộng hơn, chi phí sẽ trở nên khó dự đoán và khó quản lý. KIP-21 giải quyết vấn đề này bằng cách phân chia các cam kết trình tự, giữ cho khối lượng công việc của mỗi ứng dụng được tự chứa.

Những gì đã có sẵn?

Một phần đáng kể của bản cập nhật hard fork đã được triển khai. Các tính năng sau đây đã được xây dựng:

• Hỗ trợ mã lệnh mở rộng cho công cụ kịch bản, xương sống của các giao ước cốt lõi, theo KIP-17
• Mã định danh giao ước để quản lý dòng dõi như một tính năng đồng thuận và công cụ, thuộc KIP-20
• Các mã lệnh ZK với hệ thống biên dịch trước zk-verifier, theo KIP-16, do Alexander Safstrom biên soạn.
• Mã lệnh truy cập cam kết trình tự
• KIP-21, do Sutton soạn thảo và Maxim Biryukov thực hiện, đã được triển khai đầy đủ và đang chờ xem xét.

Các cột mốc chứng minh tính khả thi, bao gồm các giao ước zk nội tuyến và các giao ước zk dựa trên cầu nối chuẩn KAS, cũng đã được Maxim hoàn thành và đóng vai trò quan trọng trong việc định hình thiết kế cuối cùng của nhánh này.

Vì sao ngày thực hiện Hard Fork lại được dời sang tháng Sáu?

Mục tiêu ban đầu khi ra mắt mainnet là ngày 5 tháng 5 năm 2026. Tuy nhiên, thời gian dự kiến ​​đã được điều chỉnh sang khoảng từ ngày 5 đến ngày 20 tháng 6 năm 2026.

Lý do nằm ở kiến ​​trúc. Một khi các mạch zk và môi trường thực thi liên kết với cấu trúc băm cam kết trình tự, bất kỳ thay đổi cấu trúc nào sau đó đều trở thành thay đổi gây lỗi. Thiết kế sai và vá lỗi sau đó sẽ gây ra sự gián đoạn lớn hơn nhiều so với việc dành thêm thời gian ngay bây giờ.

KIP-21 đã được thiết kế để tương thích với sơ đồ cam kết trong tương lai mà vprogs, lộ trình dài hạn của Kaspa dành cho các chương trình có thể kiểm chứng và kết hợp đồng bộ, sẽ yêu cầu trong tương lai. Việc khóa cấu trúc phù hợp trước khi kích hoạt mạng chính sẽ tránh được các quá trình chuyển đổi tốn kém sau này.

Dự kiến ​​việc ngừng phát triển tính năng sẽ diễn ra vào ngày 15 tháng 4 năm 2026.

Điều gì xảy ra giữa giai đoạn đóng băng tính năng và thời điểm ra mắt mạng chính?

Sau khi đóng băng tính năng vào ngày 15 tháng 4, Kaspa Core dự định khởi động lại hoàn toàn mạng thử nghiệm chuyên dụng TN12, bao gồm đầy đủ các tính năng cuối cùng. Đây không phải là mô phỏng quá trình phân nhánh cứng. Đây là một mạng lưới sạch để thử nghiệm toàn bộ bộ tính năng ở dạng cuối cùng.

Từ đó, nhóm sẽ hợp nhất khối lượng công việc tích lũy trong nhiều tháng từ một nhánh chờ xử lý tồn tại lâu năm trở lại mã nguồn chính. Quá trình này bao gồm kiểm toán cuối cùng, giải quyết các vấn đề còn tồn đọng, hoàn thiện logic kích hoạt hard-fork và xử lý khả năng nâng cấp cơ sở dữ liệu.

Sau khi công việc đó hoàn tất, một đợt phân nhánh cứng thử nghiệm sẽ được thực hiện trên TN10, mạng thử nghiệm dài hạn, để mô phỏng quá trình chuyển đổi hoàn toàn theo kiểu mạng chính. Ngày ra mắt mạng chính thức sẽ chỉ được mã hóa sau khi quá trình diễn tập diễn ra và nhóm phát triển hài lòng.

Những gì các nhà điều hành nút nên mong đợi

Đối với người khai thác và người vận hành nút mạng, quá trình nâng cấp được thiết kế đơn giản. Các nút mạng cần được cập nhật, và các chức năng hiện có sẽ tiếp tục hoạt động. Dung lượng ổ đĩa cần thiết dự kiến ​​sẽ tăng khoảng 20 đến 50 phần trăm. Không có thay đổi lớn nào về cơ sở hạ tầng được dự đoán.

Toccata thực sự mang lại điều gì cho Kaspa?

Toccata bổ sung hai hệ thống lập trình hoạt động vào lớp nền của Kaspa: kịch bản giao ước L1 gốc thông qua Silverscript và cơ sở hạ tầng ứng dụng zk dựa trên KIP-16, KIP-20 và KIP-21. Phần lớn công việc kỹ thuật đã được hoàn thành. Những gì còn lại là hoàn thiện giao diện, hợp nhất nhánh đang chờ xử lý vào nhánh chính và chạy thử nghiệm đầy đủ trên TN10 trước khi ngày ra mắt mạng chính được xác nhận.

Khoảng thời gian từ ngày 5 đến 20 tháng 6 năm 2026 được chọn vì nhóm phát triển đã quyết định hoàn thiện kiến ​​trúc cam kết trình tự ngay từ đầu thay vì sửa chữa sau này trong điều kiện hoạt động thực tế. Đối với các nhà điều hành nút, quá trình nâng cấp được thiết kế đơn giản, không có thay đổi lớn nào về cơ sở hạ tầng ngoài việc tăng nhẹ dung lượng ổ đĩa.

Trung Tâm Tài Liệu

1. Kaspa trên X: Bài đăng (tháng 4 năm 2026)

2. Bài viết trên blog của Michael Sutton: Giao ước Kaspa++ Triển vọng Hard-Fork “Toccata”