Sự kiện Hardfork tập trung vào Covenant sắp tới của Kaspa: Những gì chúng ta biết

Bản cập nhật phân nhánh (hardfork) tập trung vào giao ước của Kaspa là gì?

Theo Bài viết của Terah, gàu đang chuẩn bị một đợt hardfork tập trung vào giao ước, dự kiến ​​diễn ra vào kích hoạt mạng chính Vào ngày 5 tháng 5 năm 2026. Bản nâng cấp mở rộng... Lớp 1 (L1) Khả năng lập trình được tăng cường bằng cách giới thiệu các tài sản gốc và chức năng giao ước mở rộng. Điều này cũng đặt nền tảng cho... các chương trình có thể kiểm chứng (vProgs) và các tích hợp không tiết lộ thông tin (ZK).

Kaspa hoạt động như một blockchain dựa trên cơ chế bằng chứng công việc (proof-of-work) sử dụng kiến ​​trúc blockDAG. Nâng cấp Crescendo Vào tháng 5 năm 2025, thông lượng đã được tăng lên 10 khối mỗi giây (BPS). Do đó, đợt hardfork sắp tới sẽ được xây dựng trên nền tảng đó mà không thay đổi các yêu cầu về nút hoặc các nguyên tắc cơ bản về cơ chế đồng thuận.

Các nhà phát triển cốt lõi mô tả bản phát hành này là một bản nâng cấp có phạm vi giới hạn. Nó tập trung vào việc cho phép phát hành token gốc, các quy tắc chi tiêu có thể lập trình và xác minh ZK trên L1. 

Lịch trình cho đợt hardfork ngày 5 tháng 5 năm 2026 là gì?

Theo bài đăng của Terah, có một số cột mốc quan trọng cần đạt được trước khi mạng chính thức được kích hoạt:

• Thiết lập lại Testnet 12 (TN12): Dự kiến ​​vào đầu tháng 2 năm 2026 sẽ hỗ trợ việc kiểm tra các điều khoản ràng buộc và tài sản bản địa.
   
• Cam kết bộ giải trình tự KIP: Dự kiến ​​vào khoảng ngày 12 tháng 2 năm 2026. Đề xuất này đưa ra các cam kết về tải trọng khai thác để tăng cường tính phi tập trung theo thời gian thực.
   
• Thông cáo báo chí của SilverScript: Một ngôn ngữ lập trình cấp cao để viết chương trình trên Kaspa. Được phát triển bởi Ori Newman và các cộng tác viên, nó giúp đơn giản hóa việc phát triển giao ước.
   
• Hardfork Mainnet: Có thể 5, 2026.

Các nâng cấp sau hardfork bao gồm DAGKnight, hướng đến cơ chế đồng thuận thích ứng và thông lượng trên 100 BPS, cùng với việc triển khai đầy đủ vProgs.

Các tài sản và giao ước bản địa trên đảo Kaspa hoạt động như thế nào?

Tài nguyên gốc trên Lớp 1

Bản cập nhật này giới thiệu các tài nguyên gốc, bao gồm hỗ trợ cho Mã thông báo KRC20Các tài sản này tồn tại trực tiếp trên L1 và có thể được chuyển giao một cách nguyên tử.

Việc chuyển giao nguyên tử áp dụng cho:

• Các điều khoản nội tuyến thông thường
• Việc thực thi thỏa thuận ZK và không phải ZK
• Chuyển khoản token KRC20

Các giao dịch nội tuyến tạo ra bằng chứng tức thì trong ví. Không có sự tách rời giữa dữ liệu giao dịch và quá trình chuyển đổi trạng thái. Thiết kế này hỗ trợ tính nguyên tử và thực thi có tính xác định.

Giao ước mở rộng (Giao ước++)

Hệ thống giao ước của Kaspa được lấy cảm hứng từ nghiên cứu của Bitcoin về các điều kiện chi tiêu UTXO có thể lập trình. Covenants++ mở rộng hệ thống này để cho phép các quy tắc giao dịch biểu đạt hơn.

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...

Các trường hợp sử dụng bao gồm:

• Các biện pháp kiểm soát an ninh kiểu hầm chứa
• Cơ chế ký quỹ
• Chuyển khoản có điều kiện
• Logic mã thông báo có cấu trúc

Hệ thống này duy trì mô hình UTXO thay vì các hợp đồng thông minh dựa trên tài khoản hoàn chỉnh.

Đồ thị định hướng chu trình tính toán (CDAG) là gì?

Bản cập nhật phân nhánh (hardfork) giới thiệu DAG tính toán (CDAG).). CDAG ghi lại tất cả các khai báo đọc và ghi do các chương trình thực hiện.

Cấu trúc này:

• Theo dõi mức sử dụng tài nguyên
• Điều chỉnh sự phụ thuộc giữa các chương trình.
• Thực thi các cam kết về khí đốt

Thiết kế này tương tự như các mô hình thực thi trong các blockchain như Solana và Sui, nhưng được triển khai đầy đủ trong môi trường blockDAG của Kaspa.

CDAG đóng vai trò trung tâm trong việc đảm bảo tính tự chủ của vProgs.

vProgs là gì và chúng khác với hợp đồng thông minh như thế nào?

vProgs là các chương trình độc lập thực thi bên ngoài L1 trong khi xử lý kết quả trên L1 thông qua các bằng chứng.

Thuộc tính chính:

• Thi hành án tối cao: Mỗi vProg tự định nghĩa các quy tắc về thông lượng và phụ thuộc riêng.
• Kiểm soát sự phụ thuộc vào khí đốt: Một vProg không thể đọc trạng thái của một vProg khác trừ khi nó trả phí gas cho việc tiêu thụ tài nguyên.
• Các chuyển giao không liên quan đến nguyên tử: Các vProg không được L1 xử lý một cách minh bạch giống như các tài nguyên gốc. Quá trình truyền tải diễn ra không đồng bộ và không mang tính nguyên tử.
• Yêu cầu KAS được đóng gói: Bất kỳ giao ước nào không phải là giao ước nội tuyến đều phải sử dụng KAS được đóng gói thông qua một cầu nối chuẩn. Không thể sử dụng KAS L1 gốc trực tiếp.

Thiết kế này tách biệt quá trình tính toán và trạng thái khỏi L1 trong khi vẫn duy trì trình tự và quá trình thanh toán chung.

Ai nên xây dựng vProgs?

Theo các cuộc thảo luận trong cộng đồng, hầu hết các nhà phát triển ứng dụng thông thường có thể không cần đến vProgs.

Tuy nhiên, vProgs có thể hấp dẫn đối với:

• Kiến trúc sư Appchain
• Các nhóm đang đánh giá các hệ thống kiểu tổng hợp
• Các dự án xây dựng tác nhân AI với trạng thái trên chuỗi lớn
• Các nhà thiết kế hệ thống đang so sánh các hợp đồng L1, các hợp đồng tổng hợp L2 và các mô hình lai.

vProgs kết hợp trình tự L1 thống nhất với trạng thái và tính toán được tách biệt bên ngoài.

Vai trò của Zero-Knowledge (ZK) là gì?

Bản cập nhật này tích hợp xác minh ZK trên L1, mở rộng các đề xuất trước đó như... KIP-16.

Các tính năng được hỗ trợ bao gồm:

• Groth16 chứng minh xác thực
• Các cầu nối không cần tin cậy đến hệ thống L2
• Các ứng dụng tiềm năng hướng đến quyền riêng tư

Các ứng dụng ban đầu dự kiến ​​sẽ chạy trực tiếp, với ví điện tử tạo ra bằng chứng ngay lập tức. Ngay cả các triển khai ZK dựa trên giao ước do các nhà đóng góp như Hans và Maxim phát triển cũng dự kiến ​​sẽ chạy trên phần cứng thông thường. Không cần cơ sở hạ tầng chứng minh chuyên dụng cho các triển khai ban đầu.

Một máy tính xách tay thông thường có thể tạo ra các bằng chứng dựa trên các giả định hiện tại.

Về mặt kỹ thuật, các chương trình tập trung vào quyền riêng tư hoàn toàn khả thi sau đợt hardfork. Tuy nhiên, quyền riêng tư không được liệt kê là trọng tâm chính trong lộ trình phát triển.

Sparkle có liên quan gì đến vProgs?

Sparkle là một kiến ​​trúc do Anton đề xuất nhằm kết hợp các đồ thị định hướng không chu trình (DAG) tính toán và các bằng chứng ZK. Mặc dù cả Sparkle và vProgs đều sử dụng các thành phần CDAG và ZK, nhưng chúng giải quyết các vấn đề thiết kế khác nhau.

Đặc điểm nổi bật của vProgs là khả năng điều chỉnh sự phụ thuộc. Mỗi chương trình tự kiểm soát thông lượng của mình và tránh các phụ thuộc bên ngoài tùy ý. Mô hình này hỗ trợ khả năng kết hợp trong khi vẫn duy trì tính độc lập.

Liệu đợt hardfork này có ảnh hưởng đến bảo mật, MEV hay yêu cầu về node không?

• Ngân sách an ninh: Không có tác động trực tiếp nào được dự kiến ​​trong ngắn hạn. Việc cải thiện phụ thuộc vào việc người dùng thực sự sử dụng sản phẩm hơn là thay đổi cơ sở hạ tầng.
   
• Yêu cầu về nút: Không thay đổi.
   
• Đấu giá MEV Kickback: Xét đến giai đoạn phát triển hiện tại của hệ sinh thái, việc này được coi là quá sớm.
   
• Cày PoW để kiếm STARK: Các cuộc thảo luận đề cập đến hành vi trong quá khứ của Ethereum thời kỳ đầu, nơi các địa chỉ có số 0 đứng đầu giúp giảm chi phí gas, từ đó dẫn đến các thị trường "cày" bằng chứng công việc. Việc đề cập này mang tính ngữ cảnh hơn là một tính năng hiện tại.

SilverScript mang lại những lợi ích gì?

SilverScript là một ngôn ngữ cấp cao được thiết kế cho các chương trình Kaspa. Mục tiêu của nó là đơn giản hóa việc phát triển giao ước và chương trình.

Các mục tiêu thiết kế của nó bao gồm:

• Cú pháp dễ đọc
• Khả năng tiếp cận dành cho các nhà phát triển mới
• Khả năng tương thích với các công cụ tự động

SilverScript dự kiến ​​sẽ giảm bớt rào cản trong việc viết các ứng dụng dựa trên giao ước khi các tài sản gốc được đưa vào hoạt động.

Kết luận

Bản nâng cấp Kaspa tập trung vào giao ước mở rộng chức năng Lớp 1 thông qua các tài sản gốc, giao ước mở rộng và xác minh ZK. Nó giới thiệu CDAG để theo dõi phụ thuộc có cấu trúc và đặt nền tảng cho vProgs chủ quyền. Bản nâng cấp này bảo toàn các yêu cầu nút hiện có và cơ chế đồng thuận bằng chứng công việc trong khi cho phép phát hành mã thông báo có thể lập trình và chuyển khoản nguyên tử.

Việc kích hoạt vào ngày 5 tháng 5 năm 2026 đánh dấu một bước tiến kỹ thuật trong lộ trình phát triển của Kaspa. Nó bổ sung khả năng lập trình có cấu trúc ở cấp độ giao thức và chuẩn bị mạng lưới cho các nâng cấp tiếp theo, bao gồm DAGKnight và triển khai vProgs đầy đủ.

Nguồn:

• Hard Fork tập trung vào Kaspa ConvenantĐếm ngược trên Kas.live
• Terah X ThreadCác cột mốc sắp tới và đợt nâng cấp hệ thống tập trung vào giao ước (Covenant-centric Hard Fork):
• Nghiên cứu Kaspa: Một mô hình xương sống chính thức cho đồ thị định hướng không chu trình (DAG) tính toán vProg