Kaspa의 Toccata 하드 포크: 언약, ZK Opcode 및 새로운 6월 목표

카스파다가오는 토카타 하드 포크는 네트워크에 두 가지 새로운 프로그래밍 경로를 추가할 예정입니다. 하나는 네이티브 L1 코버넌트 프로그래밍이고, 다른 하나는 기반 제로 지식(zk) 애플리케이션 인프라입니다. 메인넷 활성화는 원래 5월 5일 목표에서 2026년 6월 5일~20일로 연기되었습니다.

Kaspa Core의 Michael Sutton이 다음 글을 발표했습니다. 상세 업데이트 이번 하드 포크의 내용, 날짜 변경 이유, 그리고 향후 몇 달간 어떤 상황이 전개될 것으로 예상되는지에 대해 알아보겠습니다. 이번 포크는 원래 오리 뉴먼이 비트코인 ​​커뮤니티의 OP_CAT 논의에 대한 대응으로 카스파 스크립트 엔진에 코버넌트 기능을 도입하기 위해 시작한 것이었으며, 이후 훨씬 더 큰 규모로 성장했습니다.

토카타 하드 포크란 무엇인가요?

토카타(Toccata)는 카스파(Kaspa) 네트워크의 예정된 하드 포크로, 새로운 기능을 기본 레이어에 직접 도입합니다. 하드 포크란, 익숙하지 않은 분들을 위해 설명드리자면, 이전 버전과의 호환성이 없는 프로토콜 업그레이드를 의미합니다. 모든 노드는 네트워크 참여를 계속하려면 업그레이드해야 합니다.

이 이름은 주요 업그레이드에 음악적 용어를 사용하는 Kaspa의 전통을 따릅니다. 이번 제품은 건반 악기의 기교를 뽐내기 위해 작곡된 고전 음악 형식인 토카타에서 이름을 따왔습니다.

전반적으로 토카타는 카스파에 두 가지를 더해줍니다.

• 네이티브 L1 계약 프로그래밍 Silverscript라는 새로운 컴파일러를 통해
• zk 기반 애플리케이션 인프라바로 그 언약의 토대 위에 세워진 것입니다.

이 두 시스템은 서로 호환되지 않습니다. 각각 다른 사용 사례와 대상 개발자층을 위해 설계되었습니다.

언약이란 무엇이며, 카스파에게 왜 중요한가요?

약정(Covenants)이란 거래 출력에 포함된 자금을 향후 어떻게 사용할 수 있는지에 대한 조건을 말합니다. 일반적인 비트코인 ​​또는 카스파 거래에서는 코인이 전송된 후 수신자가 원하는 대로 사용할 수 있습니다. 하지만 약정은 거래 스크립트에 직접 사용 규칙을 포함시켜 이러한 방식을 바꿉니다.

Kaspa는 비트코인과 유사한 UTXO 모델을 사용하며, 각 트랜잭션은 기존 출력을 소비하고 새로운 출력을 생성합니다. UTXO 시스템의 계약(Covenant) 기능을 통해 개발자는 기본 연산은 각 UTXO 내에서만 수행되지만, 놀라울 정도로 복잡한 상태 저장형 멀티 컨트랙트 흐름을 구축할 수 있습니다.

Kaspa Core는 계약서 개발 접근성을 높이기 위해 Ori Newman, Michael Sutton, IzioDev, Manyfest가 주도한 컴파일러인 Silverscript 개발을 마무리하고 있습니다. Silverscript는 개발자가 스크립트 엔진 수준에서 직접 작업할 필요 없이 Kaspa L1에 복잡한 계약서를 더 쉽고 안전하게 작성하고 배포할 수 있도록 설계되었습니다.

ZK 기반 애플리케이션이란 무엇인가요?

Toccata에 도입된 두 번째 프로그래밍 가능 기능은 zk 애플리케이션 기반입니다. 이는 두 기능 중 기술적으로 더 복잡하므로 자세히 살펴볼 가치가 있습니다.

유망한 프로젝트를 발견하세요...

유망한 프로젝트...

(광고)

기사는 계속됩니다...

ZK는 영지식(Zero-Knowledge)의 약자로, 기초 데이터를 공개하지 않고도 어떤 사실이 참임을 증명할 수 있는 암호화 방식입니다. ZK 증명은 오프체인 연산을 온체인에서 저렴하고 안전하게 검증할 수 있게 해주기 때문에 블록체인 확장에 점점 더 많이 사용되고 있습니다.

이 맥락에서 "기반"이란 zk 시스템이 L1 시퀀싱을 완벽하게 준수함을 의미합니다. 기반 zk 애플리케이션은 독립적으로 트랜잭션을 추가하거나 삭제할 수 없습니다. Kaspa 자체의 트랜잭션 순서에 고정되어 있기 때문에 별도의 시퀀서 없이도 신뢰할 수 있습니다.

Toccata는 이를 지원하기 위해 몇 가지 구성 요소를 도입했습니다.

• ZK 검증 오퍼코드유연한 Groth16 검증기와 RISC Zero STARK 검증기를 포함합니다.
• 시퀀싱 커밋 액세스 오퍼코드이를 통해 기반 애플리케이션이 L1 순서에 고정될 수 있습니다.
• KIP-21이는 zk 앱의 검증 비용이 전체 DAG 활동이 아닌 앱 자체 활동에 따라 확장되도록 보장하는 분할된 시퀀싱 커밋먼트 아키텍처입니다.

RISC Zero STARK 검증기는 이미 테스트넷 12에 구현 및 활성화되었습니다. 메인넷에서의 활성화 여부는 아직 결정되지 않았습니다.

비용 입증이 중요한 이유

zk 애플리케이션이 실용적이려면 증명 생성 비용이 애플리케이션 자체의 작업에 비례해야 합니다. 만약 zk 애플리케이션이 더 넓은 DAG 상의 모든 활동에 비례하여 작업을 증명해야 한다면, 비용은 예측 불가능하고 관리하기 어려워질 것입니다. KIP-21은 시퀀싱 커밋먼트를 분할하여 각 애플리케이션의 작업 부하를 독립적으로 유지함으로써 이 문제를 해결합니다.

이미 갖춰진 것은 무엇인가요?

하드 포크의 상당 부분이 이미 구현되었습니다. 다음 기능들이 이미 구축되었습니다.

• KIP-17에 따른 확장된 스크립트 엔진 오퍼코드 지원, 핵심 계약 기반
• KIP-20에 따른 계보 관리를 위한 합의 및 엔진 기능으로서의 코버넌트 ID
• KIP-16 환경에서 zk-verifier 사전 컴파일 서브시스템을 사용하는 ZK opcodes는 Alexander Safstrom이 작성했습니다.
• 시퀀싱 커밋 액세스 오퍼코드
• Sutton이 작성하고 Maxim Biryukov가 구현한 KIP-21은 구현이 완료되었으며 검토를 기다리고 있습니다.

Maxim은 인라인 zk 코버넌트 및 KAS 정규 브리지를 사용한 기반 zk 코버넌트를 포함한 개념 증명 마일스톤을 완료했으며, 이는 포크의 최종 설계를 구체화하는 데 중요한 역할을 했습니다.

하드 포크 일정이 6월로 변경된 이유는 무엇인가요?

원래 메인넷 출시 목표일은 2026년 5월 5일이었지만, 이후 2026년 6월 5일부터 20일 사이로 변경되었습니다.

이유는 아키텍처적인 문제입니다. zk 회로와 런타임이 시퀀싱 커밋 해싱 구조에 바인딩되면, 이후에 구조를 변경하면 호환성이 깨지는 문제가 발생합니다. 설계가 잘못되어 나중에 패치하는 것보다 지금 시간을 더 들여 수정하는 것이 훨씬 더 큰 문제를 야기할 수 있습니다.

KIP-21은 Kaspa의 장기 로드맵인 동기식 구성 가능 검증 프로그램(vprogs)에서 궁극적으로 요구될 커밋 체계와의 미래 호환성을 고려하여 설계되었습니다. 메인넷 활성화 전에 올바른 구조를 확정함으로써 나중에 발생할 수 있는 비용이 많이 드는 마이그레이션을 방지할 수 있습니다.

기능 업데이트는 2026년 4월 15일에 완료될 예정입니다.

기능 동결과 메인넷 출시 사이에 무슨 일이 일어날까요?

4월 15일 기능 동결 이후, Kaspa Core는 최종 기능 세트를 모두 포함하여 전용 테스트넷인 TN12를 완전히 재시작할 계획입니다. 이는 하드 포크 전환을 시뮬레이션하는 것이 아니라, 최종 형태의 모든 기능을 테스트하기 위한 깨끗한 네트워크입니다.

그 후, 팀은 오랜 기간 보류되었던 브랜치에서 수개월 동안 축적된 작업 내용을 마스터 코드베이스로 병합합니다. 이 과정에는 최종 감사, 미해결 항목 해결, 하드 포크 활성화 로직 완벽화, 데이터베이스 업그레이드 가능성 처리 등이 포함됩니다.

해당 작업이 완료되면, 메인넷 전환과 유사한 상황을 시뮬레이션하기 위해 장기 테스트넷인 TN10에서 하드 포크 테스트가 실행될 예정입니다. 메인넷 출시일은 해당 테스트가 팀원들의 만족스러운 결과를 얻은 후에야 확정됩니다.

노드 운영자가 기대해야 할 것

채굴자와 노드 운영자를 위해 이번 업그레이드는 간단하게 진행될 예정입니다. 노드를 업데이트하면 기존 기능은 계속 작동합니다. 디스크 공간 요구 사항은 약 20~50% 증가할 것으로 예상되며, 인프라에 큰 변화는 없을 것으로 보입니다.

Toccata가 Kaspa에게 실제로 제공하는 것은 무엇일까요?

Toccata는 Kaspa의 기본 레이어에 두 가지 프로그래밍 가능 시스템을 추가합니다. 하나는 Silverscript를 통한 네이티브 L1 코버넌트 스크립팅이고, 다른 하나는 KIP-16, KIP-20, KIP-21을 통한 zk 기반 애플리케이션 인프라입니다. 기술적인 작업의 상당 부분은 이미 완료되었습니다. 남은 작업은 인터페이스를 최종 확정하고, 보류 중인 브랜치를 마스터 브랜치에 병합하고, 메인넷 출시일 확정 전에 TN10에서 전체 리허설을 실행하는 것입니다.

2026년 6월 5일부터 20일까지의 기간이 설정된 이유는 팀이 실제 운영 환경에서 나중에 수정하는 대신 처음부터 시퀀싱 확정 아키텍처를 제대로 구축하기로 결정했기 때문입니다. 노드 운영자의 경우, 이번 업그레이드는 디스크 공간의 소폭 증가 외에는 주요 인프라 변경 사항 없이 간단하게 진행될 수 있도록 설계되었습니다.

리소스

1. X의 카스파: 게시물 (2026년 4월)

2. 마이클 서튼의 블로그 게시글: Kaspa Covenants++ “Toccata” 하드포크 전망