큐브 소개

저자: 부아크

출처: https://medium.com/cube-bitcoin/introducing-cube-8b3702e470a5

" 큐브(Cube )"는 비트코인 ​​고유의 방식으로 신뢰할 수 없는 스마트 계약 실행을 가능하게 하도록 특별히 설계된 가상 머신입니다. 큐브는 단방향 종료 기능을 갖춘 신뢰할 수 없는 실행 환경을 제공하여 사용자가 자금에 대한 완전한 통제권을 유지할 수 있도록 보장합니다. 비트VM(BitVM)과 "타임아웃 트리"를 결합하고 비트코인 ​​블록체인을 "데이터 가용성(DA)" 계층으로 활용함으로써, 큐브는 "전역 상태"를 가진 가상 머신에 비트코인을 직접 내장합니다. 이러한 접근 방식은 비트코인의 기본 설계와 튜링 완전 스마트 계약 실행 모델을 결합하면서도 거래 상대방 리스크 도입하지 않아 비트코인의 기능을 확장할 수 있는 완전히 새로운 프레임 제공합니다.

성배

비트코인은 가장 안전하고 오랜 기간 검증된 암호화폐이지만, 스크립팅 및 확장성 측면에서의 한계로 인해 P2P 결제 이상의 복잡한 금융 거래를 지원하는 데 제약이 있습니다. 이는 결함이 아니라 비트코인의 가치를 부여하는 속성, 즉 검열 저항성, 자체 보관성, 그리고 복원력을 보호하기 위해 의도적으로 설계된 제약입니다. 그러나 결과적으로 비트코인은 글로벌 화폐 시스템에 필요한 프로그래밍 기능, 처리량, 그리고 금융 복잡성을 기본적으로 지원할 수 없습니다. 스마트 계약, 탈중앙화 금융, 그리고 고빈도 결제는 모두 비트코인이 기본 레이어에서 의도적으로 제공하도록 설계되지 않은 실행 환경을 필요로 합니다.

해결책은 비트코인을 바꾸는 것이 아니라, 그 위에 새로운 것을 구축하는 것입니다. 의미 있는 레이어 2 네트워크는 비트코인의 핵심 속성을 희생하지 않으면서 그 기능을 확장해야 합니다. 프로그래밍 가능한 스마트 계약을 제공 하면서도 자체 보관 기능을 유지해야 합니다. 즉, 어떤 중개자도 사용자의 자금을 동결 하거나 압수할 수 없어야 합니다. 이 모든 것을 비트코인 ​​프로토콜을 변경하거나, 도난당할 수 있는 신뢰할 수 있는 중개자를 도입하거나, 사용자가 배경을 알 수 없는 출시 행사, 위원회, 브리지 운영자를 신뢰하도록 강요하지 않고 달성해야 합니다.

제안된 여러 확장 솔루션들이 비트코인의 기능을 확장해 왔지만, 비트코인의 핵심적인 무신뢰성이라는 본질을 희생시켜 왔습니다. 많은 설계 방식은 1-of-n 신뢰 가정에 기반하는데, 이는 보안이 최소한 한 명의 운영자가 정직해야 한다는 것을 의미합니다. 이러한 설계 방식은 비트코인의 핵심 윤리인 탈중앙화 와 무신뢰성을 훼손하며, 비트코인의 지속 가능한 장기적인 확장 솔루션이 될 수 없습니다.

입방체

Cube는 비트코인의 프로그래밍 가능성에 완전히 새로운 접근 방식을 제시합니다. 이는 브리징 계약, 운영자 컨소시엄, 외부 합의 시스템, 심지어 비트코인 ​​프로토콜 수정 없이도 비트코인 ​​상에서 직접 완전히 신뢰할 수 없는 스마트 계약을 실행할 수 있도록 특별히 설계된 네이티브 레이어 2입니다. 프로그래밍 가능성을 위해 비트코인을 다른 신뢰 영역으로 옮기는 대신, Cube는 비트코인의 고유한 자체 보관 및 결제 모델을 프로그래밍 가능한 실행 환경으로 확장하면서 비트코인 ​​네트워크에 대한 연결을 유지합니다.

Cube의 핵심 목표는 한때 비트코인 ​​시스템 내에서 상충되는 것으로 여겨졌습니다. 바로 신뢰할 수 없는 자산 보관과 보편적인 프로그래밍 가능성이기 때문입니다. 기존 스마트 계약 환경은 비트코인의 소유권 및 결제 모델을 추상화하고 외부 검증자, 연결 계약, 다중 서명 또는 컨소시엄 에스크로 가정을 통해 프로그래밍 가능성을 구현합니다. 하지만 Cube는 이러한 방식을 사용하지 않습니다. Cube의 실행 계층 아래에는 비트코인 ​​고유의 소유권 모델이 존재하여, 프로그래밍 가능한 스마트 계약이 일방적인 종료 기능(자체 보관 또는 비트코인의 강제 상환 보장)을 희생하지 않고 실행될 수 있도록 합니다.

Cube는 비트코인 ​​자체를 실행 환경 내에서 결제, 분쟁 해결 및 최종 소유권 계층으로 활용합니다. 스마트 계약 환경은 오프체인에서 낙관적 모드로 작동하는 반면, 결제 보장, 단방향 출구 및 챌린지-응답 메커니즘의 시행은 모두 비트코인 ​​고유의 기본 요소를 통해 비트코인 ​​자체로 되돌아갑니다.

Cube의 아키텍처는 참여자로부터 거래 입력을 받아 일괄 순서 하고 비트코인 ​​네트워크에 연동된 정산 거래를 생성하는 조정 계층인 "엔진"을 중심으로 구성됩니다. 정상적인 운영에서 엔진은 즉각적인 온체인 정산 없이 상태 전환을 촉진하고 실행을 조정합니다. 중요한 점은 엔진이 단순히 조정자일 뿐, 수탁자가 아니라는 것입니다.

Cube의 주요 설계 목표는 비트코인의 고유한 자체 보관 특성을 희생하지 않고 신뢰할 수 없는 프로그래밍 가능성을 제공하는 것입니다. 각 참여자는 MuSig2 다중 서명으로 모방되고 비트코인 ​​스크립트에 의해 직접 시행되는 제한을 통해 항상 자신의 자금에 대한 일방적인 통제권을 유지합니다. 자금은 협력적인 2대2 다중 서명 구조(참여자와 엔진 간의 1대1)로 잠겨 있으며, 이는 Cube 실행 환경을 지배하는 소유권 기본 요소를 형성합니다.

Cube는 참여자의 자금을 직접 관리하지 않기 때문에 Engine은 자산을 이동시키거나, 잔액 몰수하거나, 일방적인 인출을 막을 수 없습니다. 참여자는 "타임아웃 트리" 정산 경로 및 챌린지-응답 메커니즘을 통해 비트코인 ​​네트워크에서 직접 일방적인 탈퇴 조건을 적용할 수 있습니다.

결과적으로 Cube는 수탁 수준에서 완전한 무신뢰성을 유지하면서 일반적인 스마트 계약 프로그래밍 기능을 비트코인에 직접 제공합니다. 참여자는 자금 보호를 위해 운영자, 위원회, 컨소시엄 또는 외부 검증자의 신뢰성에 의존하지 않습니다. 소유권 보장은 비트코인 ​​스크립트, 단방향 출금 경로 및 암호화된 챌린지-응답 구조를 통해 직접적으로 시행됩니다. 프로토콜 구조 자체가 이를 허용하지 않기 때문에 엔진은 도난당할 수 없습니다. 키와 비트코인에 의해 시행되는 상환 보장을 통해 참여자는 자신의 자금에 대한 통제권을 중단 없이 유지할 수 있습니다.

가상화 컴퓨팅 소유권

Cube의 실행 아키텍처는 Bitcoin에 내재된 두 가지 기본 요소의 조합입니다. (1) Ark 스타일 타임아웃 트리 소유권 가상화 및 (2) BitVM 스타일 반증 가능 계산.

타임아웃 트리는 확장 가능한 가상화된 소유권과 단방향 상환 보장을 제공하여 참여자들이 오프체인에서 가상 출력을 교환하는 동시에 독립적으로 비트코인 ​​체인으로 복귀할 수 있는 기능을 유지할 수 있도록 합니다. BitVM은 가상화된 소유권을 가상화된 연산으로 확장하여 비트코인 ​​고유의 반증 가능성 연산을 통해 주장된 상태 전환을 검증하고 강제할 수 있도록 함으로써 이 모델을 보완합니다.

Cube는 이 두 가지 기본 요소를 " 제로 지식 시간 잠금 계약(ZKLTC) "이라는 통합 실행 기본 요소로 결합합니다.

개념적으로 (1) 타임아웃 트리는 소유권 가상화 문제를 해결하고 (2) BitVM은 강제 계산 문제를 해결합니다. Cube는 이 둘을 결합하여 프로그래밍 가능한 상태 전환이 오프체인에서 낙관적으로 발생할 수 있도록 하면서 항상 비트코인 ​​자체를 통해 상환 및 이의 제기 기능을 유지합니다.

(역자 주: 여기서 "낙관적"이라는 것은 다른 누군가가 반대하지 않는 한 제안된 상태 변화가 유효하다는 것을 의미합니다.)

요약하자면, ZKTLC 는 BitVM 챌린지 메커니즘을 통해 강제할 수 있는 영지식 연산 어설션을 전달하는 타임아웃 트리 가상 출력입니다.

ZKTLCs

ZKTLCs Ark 스타일 타임아웃 트리 시스템에서 사용되는 VTXO 모델을 확장하여 프로그래밍 가능한 연산과 챌린지-응답 의미론을 추가합니다. 기존 VTXO가 주로 일방적인 가치 청구를 나타내는 반면, ZKTLC 사용자와 엔진 간의 검증 가능한 연산 주장도 나타냅니다. 따라서 출력은 가치 청구일 뿐만 아니라 엔진이 주장하는 상태 전환의 정확성에 대한 주장도 포함합니다.

추상적으로 말하자면, 이러한 관계는 비트코인에서 존재하는 양자 계약과 유사하다고 볼 수 있습니다. 라이트닝 네트워크에서 채널은 대부분 사용자와 라이트닝 네트워크 서비스 제공업체(LSP) 간의 일대일 관계를 나타냅니다. 아크(Ark) 방식 시스템에서 가상 출력은 해당 시스템 내에서 사용자와 아크 서비스 제공업체 간의 일대일 관계를 나타냅니다. 그리고 큐브(Cube)에서 ZKTLC 는 사용자와 엔진 간의 일대일 BitVM 챌린지-응답 관계를 나타냅니다.

Cube의 실행 환경은 BitVM3 패러다임의 실행 모델을 따릅니다. 즉, 주장된 Groth16 검증자 계산은 Bitcoin의 네이티브 챌린지-응답 메커니즘을 통해 실행될 수 있는 가비지 회로 검증자 환경으로 변환됩니다. 이러한 주장된 계산은 엔진이 약속한 상태 전환에 해당합니다. 더 구체적으로, 엔진은 제안된 상태 전환이 (1) Bitcoin 및 (2) CubeVM의 합의 규칙에 따라 올바르게 실행되었으며, 이전에 약속된 상태와 관련하여 유효하지 않은 상태 전환이 발생하지 않았음을 증명해야 합니다.

Cube는 비트코인 ​​가맹점에 대해 임의의 계산을 직접 수행하는 대신, 간결한 검증자 어설션을 실행하며, 이 어설션의 정확성은 BitVM3 검증 환경에서 추후 검증될 수 있습니다. 따라서 기본 검증자 회로는 실행 의미론, 계약 제약 조건, 잔액 불변 조건, 상태 전환 유효성 조건, 그리고 결제 정확성을 규정하는 관련 비트코인 ​​합의 규칙을 포함하여 CubeVM 상태 전환 시스템 자체의 유효성 규칙을 나타냅니다.

주장된 연산은 가비지 테이블, 와이어 레이블 커밋먼트, 챌린지 레코드, 그리고 검증자 회로에 해당하는 비밀 값 공개 구조로 표현됩니다. 협력적 실행 환경에서는 판정 환경이 비활성화된 상태로 유지되며, 엔진은 낙관적으로 상태 전이를 진행합니다. 적대적 상황에서는 참여자가 검증 가능한 입력값(주장 자체를 확인하여)의 공개를 강제하고, 가비지된 Groth16 검증자를 로컬에서 재구성하여 커밋먼트를 획득한 후, 주장된 상태 전이를 직접 평가할 수 있습니다. 평가 결과가 유효하지 않으면, 가비지된 검증자는 오류 출력 와이어 레이블에 해당하는 반증 비밀 값을 생성하여 참여자가 이미 커밋된 비트코인 ​​해시 락 조건과 관련된 징벌적 정산 경로를 실행할 수 있도록 합니다.

따라서 참여자들은 일방적인 상환권과 암호학적으로 검증된 엔진이 주장하는 강제 실행 상태에 대한 권리를 모두 포함하는 가상화된 소유권 객체를 제어합니다.

기존의 영지식 증명 시스템은 전체 생태계가 참여하는 신뢰할 수 있는 초기화 의식(또는 다자간 보안 계산 위원회)에 의존합니다. Cube는 각 참여자에게 독립적인 환경을 제공한다는 점에서 차별화됩니다. 계정 초기화 과정에서 각 참여자는 엔진과 직접 상호 작용하여 개별 초기화 의식을 수행하고, 고유한 증명 매개변수를 생성하며, 유해 폐기물 생성에 참여하고, 자신의 유해 폐기물 파기를 제어합니다. (여기서 "유해 폐기물"은 초기화 의식과 관련된 정보를 유출할 수 있는 데이터를 의미합니다.)

결과적으로, 장치 자체를 실행함으로써 참여자는 신뢰할 수 없는 상태를 프로그래밍하게 됩니다. 신뢰는 외부 MPC 위원회, 조정자 또는 공유 증명 환경으로 향하는 것이 아니라 참여자 자신의 ZKTLC 환경에 국한됩니다.

타임아웃 트리

Cube는 실행 환경보다 낮은 수준의 기본 소유권 및 일방적 종료 아키텍처로 타임아웃 트리를 활용합니다.

타임아웃 트리는 미리 서명된 거래들의 트리 구조로, 대량 의 가상화된 소유권 객체가 공통된 결제 구조를 공유하면서도 각 참여자의 일방적 상환 보장을 보호할 수 있도록 합니다. 비트코인 ​​블록체인 내에서 모든 중간 소유권 이전이 즉시 정산되는 대신, 참여자들은 공유 거래 트리에 내장된 가상화된 결과물을 기반으로 낙관적인 거래를 진행합니다.

협력 실행 중에는 타임아웃 트리가 비활성 상태로 유지되며, 소유권 이전은 오프체인에서 발생합니다. 조정이 실패하거나 엔진이 부정직한 행위를 하는 경우, 참여자들은 관련 타임아웃 조건이 충족되면 비트코인 ​​체인 내에서 해당 타임아웃 트리 분기를 독립적으로 생성하고 상환할 수 있습니다.

Cube는 ZKTLC 실행 메커니즘 하에서 타임아웃 트리를 기본 정산 및 소유권 요소로 사용합니다. 시스템 참여자 각자의 잔액 궁극적으로 비트코인 ​​스크립트를 통해 실행될 수 있는 타임아웃 트리 상환 경로로 결정됩니다.

개념적으로, 타임아웃 트리 구조는 Cube에 소유권 가상화 기능을 제공하며, ZKTLCs 이러한 소유권 객체에 프로그래밍 가능한 연산 및 챌린지-응답 의미론을 추가합니다. 이러한 관점에서 Cube의 실행 아키텍처는 Ark의 가상 소유권과 BitVM의 증명 가능한 연산을 결합한 것으로 이해할 수 있으며, 둘 다 비트코인 ​​결제 보장에 직접적으로 기반을 두고 있습니다.

CubeVM

Cube는 "CubeVM"이라는 맞춤형 가상 머신을 소개합니다. CubeVM은 비트코인 ​​스크립트(프로그래밍 언어)의 확장 및 복제본으로, 비트코인 ​​상에서 신뢰할 수 없는 스마트 계약을 실행하기 위해 특별히 설계되었습니다. CubeVM은 비트코인의 스크립트 실행 방식을 대체하는 것이 아니라, 비트코인 ​​스크립트의 스택 기반 실행 환경을 확장하여 단방향 종료 및 위조 연산에 최적화된 프로그래밍 가능한 전역 상태 환경을 제공합니다.

CubeVM은 일반적인 스마트 계약 연산에 필요한 추가 연산 코드를 제공하여 Bitcoin Script를 확장합니다. 이 가상 머신은 전역 상태 관리, 영구적인 계약 저장소, 격리된 실행 환경, 향상된 메모리 관리, 256비트 연산, 타원 곡선 연산, 스택 요소 연산, 계약 호출 의미 체계, 그리고 기본 자산인 비트코인을 직접 조작하는 프로젝션 연산 코드를 기본적으로 지원합니다.

이더 가상 머신(EVM)과 같은 계정 기반 가상 머신과는 달리, CubeVM은 비트코인의 기본 자체 저장 메커니즘에 프로그래밍 가능한 실행 기능을 도입하는 것을 목표로 처음부터 설계되었습니다. 따라서 스마트 계약의 상태 전환은 항상 Cube의 타임아웃 트리 정산 구조 및 위조 모드와 호환됩니다.

CubeVM의 핵심 아키텍처 요소는 " 프로젝션 "에 대한 네이티브 지원입니다. 이를 통해 계약에 의해 제어되는 논리적 잔액 참여자에게 속한 일방적 상환 객체에 지속적으로 투영할 수 있습니다. 프로젝션 연산은 프로그래밍 가능한 스마트 계약 실행과 비트코인의 키 기반 소유권 모델 사이의 의미론적 연결 고리 역할을 합니다. 이 메커니즘을 통해 CubeVM은 프로그래밍 가능한 스마트 계약이 비트코인에서 직접 작동하면서 계약 실행 중에 완벽하게 보장된 일방적 상환 및 자체 보관 특성을 유지할 수 있도록 합니다.

투사

이더 같은 프로그래밍 가능한 스마트 계약 시스템은 비트코인의 기본 설계와는 근본적으로 다른 소유권 모델을 기반으로 작동합니다. 비트코인에서 자금은 공개 키로 관리됩니다. 소유권은 유효한 디지털 서명을 생성할 수 있는 능력으로 표현되며, 서명 권한을 자유롭게 행사하는 계정이 궁극적으로 코인을 관리합니다. 스마트 계약은 이와 완전히 다릅니다. 스마트 계약은 계정에 내재된 재량권이나 자유 의지를 갖지 않습니다. 계약은 계약 자체의 자금으로 관리되며, 전적으로 결정론적인 절차적 논리와 상태 전환에 의해 움직입니다. 특히, 계약 논리 자체가 가치의 관리자가 됩니다. 이러한 차이로 인해 비트코인의 기본 소유권 모델과 프로그래밍 가능한 스마트 계약의 의미론은 근본적으로 양립할 수 없습니다.

BitVM과 난독화된 회로는 기본적으로 키 기반 환경 내에서 작동합니다. 이러한 기본 요소는 공개 키, 서명, 챌린지-응답 프로토콜, 그리고 개별 엔티티와 관련된 검증 가능한 연산을 중심으로 구성됩니다. BitVM은 임의의 연산을 검증할 수 있지만, 그 근본적인 소유권 모델은 변하지 않았습니다. 비트코인은 여전히 ​​논리가 아닌 키를 이해합니다. 실행 가능한 논리 자체는 UTXO 형태의 비트코인을 직접 저장할 수 없습니다. 결과적으로 두 가지 서로 다른 의미 영역이 나타납니다. 비트코인은 공개 키의 언어를 사용하는 반면, 스마트 계약은 논리의 언어를 사용합니다. 비트코인에는 논리가 가치를 저장할 수 있도록 하는 기본적인 추상화가 부족하기 때문에 이 두 시스템은 자연스럽게 상호 운용되지 않습니다. 이러한 비호환성을 해결하기 위해 본 연구에서는 "프로젝션"이라는 중간 추상화를 도입합니다.

프로젝션은 비트코인 ​​로직의 기본 수탁 모델과 비트코인의 기본 보유 의미론 사이에 존재하는 변환 계층입니다. 실행 가능한 로직 자체를 비트코인을 보유하는 개체로 만드는 대신, 계약이 관리하는 잔액 각 참여자의 공개 키와 연결된 잔액 집합으로 투영할 수 있도록 합니다. 프로젝션의 핵심은 자금이 계약 로직의 수탁 하에 일시적으로 보관될 수 있지만, 경제적인 관점에서 볼 때 이러한 자금은 계약 수명 주기 동안 개별 참여자에게 여전히 속한다는 것입니다.

일반적으로 이더 과 같은 프로그래밍 가능한 스마트 계약 시스템에서 자금은 반복적인 관리 주기를 거칩니다. 처음에는 계좌 소유자의 직접 소유권 하에 있다가, 계약에 의해 일시적으로 논리적 관리 하에 있다가, 인출이나 결제가 발생하면 다시 계좌 소유자의 직접 소유권으로 돌아갑니다. 참여자는 처음에는 자신의 네이티브 키로 관리되는 계좌 잔액 통해 자금을 관리할 수 있습니다. 그런 다음, 이 참여자는 비트코인 ​​기반 스테이블코인 계약, 자동 마켓메이커(AMM)(AMM) 유동성 풀 또는 다른 프로그래밍 가능한 금융 기본 요소와 같은 스마트 계약에 자금을 예치할 수 있습니다. 이 시점부터 자금은 더 이상 참여자의 서명 권한에 의해 직접 관리되지 않고, 계약의 실행 논리와 상태 전환 규칙에 따라 전적으로 관리됩니다. 최종적으로 담보가 상환되거나, 유동성이 인출되거나, 계약이 결제되면 자금은 참여자의 공개 키 관리 하에 다시 돌아옵니다. 따라서 이 과정의 문제점은 중간 단계에서 자금이 참여자의 공개 키에 의해 직접적으로 통제되지 않고, 논리적 관리 하에 있기 때문에 공개 키로 보유된 잔액 으로 표현될 수 없다는 것입니다. 바로 이 논리적 관리 하에 있는 중간 단계가 비트코인의 고유한 소유권 의미 체계와 스마트 계약의 고유한 실행 의미 체계가 자연스럽게 조화를 이룰 수 없는 지점입니다.

(역자 주: 실제로 이더 과 같은 프로토콜에서는 네이티브 이더 리움 통화인 ETH만 공개 키를 사용하여 직접 보유할 수 있습니다. 다른 통화는 발행 계약의 실행 로직에 따라 공개 키를 통해서만 조작할 수 있으며, 이는 논리적 보관이 주요 기능임을 의미합니다.)

프로젝션은 계약의 보관 자체가 아닌 참여자에 대한 계약의 의무를 표현함으로써 이러한 비호환성을 해결합니다. 계약 잔액 특정 계약 상태(경제적 의미에서)에서 참여자의 공개 키가 보유한 특정 금액에 해당하는 잔액 집합에 지속적으로 투영됩니다. 이 투영된 표현, 즉 섀도우 상태는 비트코인의 기본 구조를 사용하여 표현할 수 있지만, 그 기본 보관은 여전히 ​​실행 가능한 로직에 의해 완전히 제어됩니다. 이 메커니즘을 통해 계약에 의해 관리되는 자금은 참여자의 공개 키와 연결된 타임아웃 트리에 지속적으로 투영되어 일방적인 인출이 가능합니다. 결과적으로, 기본 비트코인은 논리적으로 보관되지만, 참여자는 어떤 상태에서든 특정 금액에 대한 상환 권리를 항상 보유합니다. 따라서 프로젝션은 BitVM의 기본 키 챌린지 프레임 와 스마트 계약 기반 논리적 보관 사이의 의미론적 연결 고리 역할을 합니다. 실행 가능한 로직이 자금을 관리하지만, 이러한 자금의 섀도우는 비트코인의 기본 공개 키 구조를 통해 항상 상환될 수 있습니다.

투영 공간

구현 관점에서 프로젝션 추상화 메커니즘은 " 프로젝션 공간 "이라고 하는 전용으로 관리되는 할당 공간을 생성합니다. Cube에 배포된 각 스마트 계약에는 자체 프로젝션 공간이 할당되며, 이는 참여자의 섀도우 잔액 관리하는 원장 계층입니다. 개념적으로 프로젝션 공간은 계약 자체에서 할당하는 데이터베이스로,账户公钥-> 影子余额매핑으로 구성됩니다. 각 항목은 계약이 에스크로를 통해 보유하는 비트코인이 실제로는 참여자 계정에 경제적으로 속하는(또는 "지급받아야 할") 비트코인의 양을 나타냅니다. 따라서 프로젝션 공간은 UTXO 형태의 통화 소유권을 나타내는 것이 아니라, 계약이 보유한 유동성의 계획된 상환 상태를 나타내며, BitVM의 기본 키 프레임 프레임 및 일방적 출구 프레임 와 호환되는 형태를 갖습니다. 섀도우 잔액의 할당은 전용 프로젝션 오퍼레이션 코드 세트를 통해 생성 및 관리되며, 이를 통해 계약은 상태 변화 시 참여자의 잔액 초기화, 증가, 감소 및 비례적으로 조정할 수 있습니다.

참가자 계정별로 다음 두 항목의 합계는 다음과 같습니다.

1. 계좌의 최초 잔액;
2. 모든 계약에 걸쳐 이 계정에 속하는 섀도우 할당;

특정 상태에서 타임아웃 트리 상의 참가자의 실제 사용 가능 잔액 정의합니다.

중요한 점은, 계약에 대한 섀도우 할당 총액은 해당 계약이 보유한 실제 잔액 에 의해 엄격하게 제한된다는 것입니다. 계약의 예측 공간 내 모든 섀도우 잔액 의 합은 해당 계약이 현재 보유하고 있는 비트코인 ​​양을 절대 초과할 수 없습니다. 즉 Contract Balance ≥ ∑Shadow Allocations

실제 계약의 비트코인 ​​잔액 초과하는 섀도우 할당을 초래하는 모든 작업은 가상 머신 수준에서 무효로 간주되어 거부됩니다. 이러한 제약 조건은 예상되는 모든 섀도우 잔액 계약이 보유한 유동성으로 항상 완전히 보장되도록 하여 모든 참여자의 잔액 에 대해 충분한 일방적 출금 유동성을 보장합니다.

프로젝션 오프코드

CubeVM은 계약의 프로젝션 공간을 관리하기 위해 자체 개발한 일련의 오퍼레이션 코드를 통합하고 있습니다.

- 투영 연산 코드 -

이러한 오퍼레이션 코드는 계약 실행 중 참여자에게 귀속되는 섀도우 잔액 관리하는 데 필요한 상태 전환 기본 요소를 제공합니다. OP_SHADOW_ALLOC 계약의 프로젝션 공간 내에서 참여자 계정에 대한 새로운 섀도우 할당 항목을 초기 잔액 0으로 초기화합니다. 할당 후 OP_SHADOW_UP 및 OP_SHADOW_DOWN 사용하여 해당 참여자와 관련된 섀도우 할당량을 늘리거나 줄일 수 있습니다.

예를 들어 비트코인을 담보로 하는 스테이블코인 계약을 생각해 보겠습니다. 참여자가 이 계약에 비트코인을 담보로 예치하면, 예치된 자금은 더 이상 참여자의 서명 권한이 아닌 계약의 내부 실행 로직에 따라 관리됩니다. 테스트 후, 계약은 OP_SHADOW_UP 함수를 호출하여 참여자의 섀도우 할당량을 담보 금액만큼 증가시킵니다. 예치된 비트코인은 기술적으로 계약의 논리적 관리 하에 있지만, 참여자 잔액의 동일한 잔액 타임아웃 트리에 투영되어 투영 공간을 통한 일방적 인출이 가능해집니다. 이는 충분한 일방적 인출 유동성을 보장하여, 기초 자산이 가상화되어 계약 내에 잠겨 있더라도 참여자가 언제든지 자금을 인출할 수 있도록 합니다. 이것이 BitVM의 키 기반 상환 모델과 스마트 계약 기반 논리적 관리의 핵심 메커니즘입니다.

CubeVM은 계정 기반 오퍼레이션 코드 외에도 OP_SHADOW_UP_ALL 및 OP_SHADOW_DOWN_ALL 과 같은 비례적으로 조정되는 오퍼레이션 코드를 제공합니다. 단일 참여자의 잔액 만 변경하는 OP_SHADOW_UP 및 OP_SHADOW_DOWN 과 달리, 이러한 오퍼레이션 코드는 프로젝션 공간 내 모든 참여자의 섀도우 할당량을 (현재 상대적 가중치를 기반으로) 비례적으로 증가시키거나 감소시킵니다. 이러한 오퍼레이션 코드는 AMM과 같은 풀링 유동성 시스템에 특히 유용합니다. 스왑, 수수료 또는 유동성 이벤트로 인해 풀링된 비트코인 ​​유동성이 증가하거나 감소할 때, 계약은 각 유동성 공급자의 섀도우 할당량을 개별적으로 조정하는 대신 단일 오퍼레이션 코드 실행을 통해 모든 유동성 공급자의 섀도우 할당량을 비례적으로 균형 있게 조정해야 합니다. 이는 모든 참여자에게 완전한 일방향 출구를 보장하면서 풀링 금융 기본 요소의 구현 복잡성을 크게 단순화합니다.

영사기

Cube는 비트코인에 현재 네이티브 제약 조건 연산 코드가 없기 때문에 경량 제약 조건 모방 메커니즘으로 수정된 MuSig2 집계 구조를 사용합니다. 프로토콜 수준의 제약 조건 기본 요소에 의존하는 대신, Cube는 값에 바인딩된 집계 서명 구조를 사용하여 제약 조건을 시뮬레이션합니다. 이 집계 서명 구조를 "프로젝터"라고 합니다.

기존 MuSig2 집계 서명과 달리, 프로젝터는 집계된 제약 조건 항 ​​공개 키를 서명자의 신원뿐만 아니라 명시적인 수치적 커밋먼트에도 연결합니다. 이는 암호학적으로 제약 조건 항 ​​스크립트 공개 키를 의도된 값 상태에 연결합니다.

프로젝터의 주요 목표는 참여자들이 계약 실행 상태나 거래 내용에 대한 완전한 의미론적 이해 없이도 안전하게 제약 조건 서명 세션에 참여할 수 있도록 경량화된 제약 조건 실행 환경을 구축하는 것입니다. 프로젝터 참여자는 무한한 수의 제약 조건 논리 가능성을 분석할 필요가 없으며, 최소한의 결정론적 검증만으로도 안전하게 작업을 수행하면서 재실행, 재바인딩 및 악의적인 중복 서명 시도를 방지할 수 있습니다.

추상적으로 말하자면, 프로젝터는 제한된 조건의 서명을 제약 조건이 있는 투영 문제로 변환합니다. 실행 가능한 계약 상태는 BitVM의 공개 키에 대한 기본 챌린지 모드와 호환되는 값에 바인딩된 공개 키 구조로 투영됩니다.

프로젝터는 사전 처리 계획 단계를 통해 원래 MuSig2 집계 프로세스를 확장합니다. 이 계획 단계는 표준 KeyAgg(pk_1 … pk_u) 단계( BIP-327 에 정의됨) 이전에 실행됩니다.

Cube는 참가자의 공개 키를 KeyAgg 함수에 직접 입력하는 대신 값을 바인딩하는 결정론적 프로젝션 함수를 도입했습니다.

 KeyProjectorAgg(pk_1...pk_u, val_1...val_u)

안에:

• pk_i 는 참가자의 공개 키입니다.
• val_i 각 참여자와 관련된 사토시 단위의 투자 금액을 나타냅니다.

각 참가자(번호 i 로 구분됨)에 대해 다음과 같이 예측 조정 항이 계산됩니다.

 t_i = H CubeProjector(val_i // i)

여기서 H CubeProjector "CubeProjector"라는 레이블을 사용하여 레이블이 지정된 해시 함수를 나타냅니다.

그러면 각 공개 키는 다음과 같이 표현됩니다.

 pk_i'= pk_i + t_i.G

최종적으로 예상되는 공개 키 세트는 다음과 같습니다.

 (pk_1', pk_2', ... , pk_u')

그런 다음, 이들은 원래의 MuSig2 집계 프로세스로 전달됩니다.

 KeyAgg(pk_1', pk_2', ... , pk_u')

나머지 MuSig2 서명 프로세스는 더 이상 수정할 필요가 없습니다. 서명의 정확성과 관련하여 각 참여자는 동일한 조정을 사용하여 자신의 개인 키를 검증할 수 있습니다.

 sk_i' = sk_i + t_i

미리 생성된 개인 키는 원래 프로토콜과 마찬가지로 나머지 MuSig2 논스 생성 및 조각 서명 생성에 사용됩니다. 최종적으로 생성되는 통합 공개 키("프로젝터 공개 키"라고 함)는 서명자의 신원과 명시적 값 커밋먼트에 동시에 연결됩니다.

이 값 바인딩 속성은 경량 제한 조항 시뮬레이션에 매우 중요합니다. 표준 MuSig2 구조에서 집계는 서명자의 공개 키만 커밋합니다. 결과적으로 악의적인 코디네이터는 서명자가 무엇에 서명하는지 완전히 알지 못하는 한, 유효한 여러 제한 조항 상태에 서명을 시도할 수 있습니다.

프로젝터에서 이러한 공격은 집계된 제한 조건 공개 키 자체가 약속된 값이 변경될 때마다 변경되기 때문에 상당히 제한됩니다. 제한 조건 스크립트 공개 키는 프로젝션된 집계 공개 키에서 파생되므로 서명 권한은 본질적으로 특정 값 상태에 종속됩니다. 따라서 불완전하게 검증된 서명 환경에서도 최소한의 결정론적 검증 로직만 실행하면 제한 조건 실행에 안전하게 참여할 수 있습니다.

본체 박스 돌출부

"호스팅 박스 프로젝션"은 광범위한 제한 조항 시행 그래프에 대한 맥락적 인식이 제한적인 경량 제한 조항 서명 환경을 의미합니다. 기본적으로 호스트 박스는 사용자가 제어하는 ​​장치에서 실행되는 경량의 상시 작동 제한 조항 시뮬레이션 서비스로, 백그라운드에서 작동하는 라우터, 리피터 또는 노드 소프트웨어와 유사합니다. 이 장치는 참여자가 직접 실행하거나 외부 호스팅 인프라에 배포할 수 있지만, 그 역할은 의도적으로 정의되어 있습니다. 즉, 엔진의 요청에 따라 프로젝션 서명 세션에 참여하는 것입니다.

호스트 박스는 완전한 스마트 계약 런타임 환경이 아니라, 바인딩된 값에 대한 프로젝터 서명 프로세스에 참여하는 역할만 하는 제한적이고 제약된 시뮬레이션 노드입니다. 호스트 박스는 계약의 의미론, 트랜잭션 흐름, 심지어 실행 내용까지 완전히 이해할 필요가 없습니다. 단지 프로젝터 서명 세션에 안전하게 참여하기만 하면 되는데, 이 프로세스는 다음과 같은 몇 가지 확정적 속성만 검증하면 됩니다.

• 귀하의 공개 키가 집계 세트에 포함되어 있는지 여부,
• 요청된 값 바인딩 프로젝터 매개변수가 유효한가요?

이러한 검사를 통과하면 호스트 시스템은 나머지 MuSig2 서명 프로세스에 안전하게 참여하여 예상되는 통합 공개 키에 대한 조각 서명을 생성할 수 있습니다.

이 모델의 보안은 바인딩된 값 자체의 집계에서 비롯됩니다. 제한 조항 스크립트 공개 키가 명시적 값 커밋에 암호학적으로 바인딩되어 있기 때문에, 악의적인 시도로 인해 다른 제한 조항 상태에서 서명 권한을 재사용하더라도 프로젝터 집계 공개 키와 제한 조항 스크립트 공개 키만 달라질 뿐입니다. 따라서 호스트 장치는 제한 조항 실행에 대한 완전한 정보 없이도 경량 제한 조항 에뮬레이션 엔진으로 안전하게 작동할 수 있으며, 따라서 상시 가동되는 저전력 장치에도 적합합니다.

블랙박스 프로젝션

프로젝터는 또한 "블랙박스 프로젝션"이라는 광범위한 미래 연구 영역을 열어줍니다. 이 모델에서 제한 조항 서명 환경은 내부 상태, 서명 논리 및 실행 의미론을 가능한 한 최소한으로 노출하면서도 값에 바인딩된 제한 조항의 실행에 안전하게 참여할 수 있는 제한된 입출력 시스템입니다.

예상되는 커밋먼트는 제약 조건 수준에서 값을 구속하기 때문에 블랙박스 프로젝션은 비대화형 제약 조건 참여를 가능하게 할 수 있습니다. 즉, 서명 런타임 환경은 더 이상 관련 실행 컨텍스트를 완전히 해석하거나 검증할 필요 없이 가장 간단한 구조적 검사만 수행하면 됩니다. 이는 제약 조건 시뮬레이션 프로세스를 훨씬 원활하게 만들고 상호 작용의 복잡성을 줄이며, 확장성이 뛰어나고 경량화된 제약 조건 서명 런타임 환경을 (완전한 상태 저장 실행 참여자가 아닌) 제약 조건이 있는 암호화 프로젝션 장치로 활용할 수 있는 가능성을 열어줍니다.

가상 블랙박스

한 가지 가능한 방향은 입출력 블랙박스처럼 작동하는 격리된 가상 제약 조건 서명 환경을 구축하는 것입니다. 이러한 시스템은 서명자 팀 검증 및 값 바인딩된 프로젝터 매개변수가 서명자 팀과 일치하는지 확인하는 것과 같은 최소한의 결정론적 검증 로직만 수행함으로써 프로젝터 서명 세션에 안전하게 참여할 수 있습니다. 프로젝터 집계 공개 키가 값 바인딩되어 있기 때문에 여러 제약 조건 상태에 걸쳐 재실행하거나 악의적인 이중 서명 시도가 이미 제한됩니다. 따라서 매우 간소화된 서명 환경에서도 스마트 계약 실행에 대한 완전한 정보 없이 제약 조건 실행에 안전하게 참여할 수 있습니다.

물리적 블랙박스

보다 불확실한 방향은 물리적으로 블랙박스 형태의 제한 장치를 사용하는 것입니다. 이상적으로는 이러한 시스템을 통해 서명 장치를 적에게 실제로 전달하더라도, 그 안에 저장된 개인 키 자료가 검사나 변조를 위해 노출되지 않도록 할 수 있어야 합니다.

하나의 가상적인 아키텍처는 서명 개인 키를 안정적이고 지속 가능한 전자기장이나 진공으로 격리된 밀폐 환경에 저장하는 것을 포함할 수 있습니다. 이러한 방식에서는 장치에 대한 물리적 감지, 분해 또는 간섭이 발생할 경우 밀폐 환경이 파괴되어 그 안에 있는 개인 키도 필연적으로 손실됩니다. 다소 비현실적일 수 있지만, 이러한 시스템은 제한 조항 서명 인프라의 장기적인 방향을 제시합니다. 즉, 강력한 암호학적 격리를 유지하면서 프로젝터 제한 조항 시행에 안전하게 참여할 수 있는 물리적으로 제한된 서명 환경을 구현하는 것입니다.

도약

"리프팅"이란 비트코인 ​​UTXO가 블록체인 내 가상 출력으로 원자적으로 변환되는 과정을 말합니다. 개념적으로, 점프는 비트코인을 블록체인 내 직접 소유권에서 블록체인 가상화 실행 환경으로 "이전"하는 것으로, 이후 자금은 일반적인 전송 및 스마트 계약 호출에 참여할 수 있게 됩니다.

비트코인은 큐브 시스템 내에서 유통되기 전에 먼저 '점프' 과정을 거쳐야 합니다. 따라서 점핑은 외부 온체인 유동성이 큐브 실행 환경으로 진입하는 공식적인 메커니즘이며, 이 과정의 모든 단계에서 비트코인의 보관이 유지됩니다.

- 점프 -

점프 출력

Lift 는 온체인 비트코인을 큐브(Cube)의 네이티브 가상 출력으로 변환하는 데 사용되는 전용 소개 트랜잭션 출력입니다. Lift 출력에 자금이 충전되면 참여자와 해당 엔진은 점프 과정에서 이를 1:1 비율의 상응하는 VTXO 로 교환합니다. 사실상 Lift Lift 타임아웃 트리 가상 소유권 객체로 승격됩니다. Lift 출력은 다음과 같은 지출 조건을 가집니다: (Self + Engine) or (Self after 3 months)

• 점프 경로 : 참가자와 그들의 엔진은 Self + Engine 경로를 통해 협력적으로 서명합니다. 그 대가로 참가자는 큐브 시스템 내에서 1:1로 대응하는 VTXO 받게 됩니다.
• 종료 경로 : 엔진이 협조하지 않거나 점프 작업 처리를 거부하는 경우, 참가자는 정의된 타임아웃 기간이 종료된 후 타임아웃 복구 경로를 통해 독립적으로 비트코인을 회수할 수 있습니다.

단계별 종료 및 포크 증인

- 일방적 출구 경로 -

협력하지 않는 경우, 즉 엔진이 참가자 인출 또는 계약 종료 처리에 협력을 거부하는 경우, Cube는 tx::exit-ladder 라는 메타데이터를 포함하는 트랜잭션 유형인 일방적인 종료 메커니즘을 제공합니다.

참가자는 다음 두 가지 자금 지원 방식 중 하나에 대해 일방적인 탈퇴 경로를 이용할 수 있습니다.

1. 미해결 스왑아웃 항목과 같은 잔액 직접 인출합니다.
2. Call -> Swapout 실행 경로를 통해 계약이 관리하는 섀도우 잔액 인출하세요.

일반적으로 이러한 종료 ​​활동은 각 엔진에서 "일괄 처리" 방식으로 협업하여 처리됩니다. 엔진이 참여자가 요청한 종료 활동을 포함하거나 실행하지 않는 경우, 참여자는 체인 내에 tx::exit-ladder 트랜잭션을 브로드캐스팅하여 강제로 실행할 수 있습니다.

tx::exit-ladder 트랜잭션에는 엔진이 협력적 처리를 거부하는 보류 중인 종료 작업을 인코딩하는 메타데이터가 포함되어 있습니다. 구체적으로, 이 트랜잭션은 수행하려는 배치 작업에 해당하는 APE로 인코딩된 "진입 종류"를 포함합니다. 따라서 이 일방적 종료 트랜잭션은 인체인 이의 제기 경로입니다(그렇지 않으면 관련 상태 전환은 오프체인에서 가상화된 상태로 유지됩니다).

tx::exit-ladder 트랜잭션은 종료 메타데이터 자체 외에도 "포크 증명"을 위한 "커넥터" 출력 지점을 포함합니다.

이 커넥터는 BitVM 기반 브리징 계약 및 분쟁 해결 아키텍처에서 발생하는 근본적인 "포크 선택 문제"를 해결하기 위해 존재합니다. 즉, 챌린저와 프로바이더 모두 분쟁이 발생한 상태 전환이 실제로 어느 정통 체인에서 일어났는지 확실하게 증명할 수 없습니다.

그러한 증인이 없다면 악의적인 운영자는 존재하지 않는 포크 에서 일방적으로 거래를 종료하여 활성화 검증 메커니즘이나 ZKTLC 의 제재 절차를 회피하는 부정직한 대안 포크 찾아내거나 전달하려고 시도할 수 있습니다.

Cube는 포인트 위트니스를 명시적으로 출력함으로써 이러한 공격을 방지합니다.

tx::exit-ladder 트랜잭션의 커넥터 입력은 해당 tx::fork-attest 트랜잭션의 입력이 됩니다. 커넥터는 반드시 일방적 종료 트랜잭션 자체에서 시작되어야 하므로, 엔진은 이 `exit-ladder` 트랜잭션이 존재하지 않는 충돌 체인에서는 유효한 포크 증명 경로를 구성할 수 없습니다.

따라서, 일방적 탈퇴 거래의 존재는 암호학적으로 이의 제기 가능한 분쟁 환경 자체와 연결되어 있습니다. 엔진은 일방적 탈퇴 요청을 하지 않은 다른 포크 체인을 선택적으로 확인하는 방식으로 활성화 이의 제기 메커니즘을 회피할 수 없습니다.

tx::fork-attest 트랜잭션은 2-of-2 아키텍처를 사용하여 구성되며, SIGHASH_ALL | ANYONECANPAY 태그로 사전 서명되고, 추가적으로 SIGHASH_ALL CHECKSIG 검증 경로를 포함하여 트랜잭션에 tx::exit-ladder 트랜잭션의 커넥터 출력 지점이 포함되도록 합니다.

궁극적으로, 명확한 출력 지점으로 연결된 일방적 종료 경로는 해당 경로가 속한 체인을 증명합니다. 이를 통해 이의 제기자와 참여자는 일방적 종료 요청으로 이어진 분쟁 체인을 확실하게 입증할 수 있으며, ZKTLC 제기-응답 메커니즘에 대한 모호한 포크 선택 공격을 방지할 수 있습니다.

데이터 가용성 코딩

- 인코딩 방식 비교 -

Cube는 " Airly Payload Encoding(APE) "이라는 맞춤형 트랜잭션 인코딩 형식을 사용하는데, 이는 Cube의 데이터 가용성 효율성을 최적화하도록 특별히 설계되었습니다.

APE의 주요 목표는 각 트랜잭션의 코딩 오버헤드를 최소화하여 비트코인 ​​블록 공간 내 트랜잭션 밀도를 극대화하는 것입니다. Cube는 적극적인 페이로드 압축, 효율적인 인덱싱, 그리고 집계 기반 코딩 전략을 통해 기존 EVM 또는 zkEVM 아키텍처에 비해 단일 비트코인 ​​블록 내에서 더 많은 상태 전환을 안정적으로 처리할 수 있습니다.

RLP와 같은 일반적인 코딩 방식은 유연성과 재귀적 구조 표현을 우선시하는 반면, APE는 결정론적 롤업 실행과 간결한 상태 전이 코딩을 위해 특별히 설계되었습니다. 이 코딩 방식은 사전 정의된 타입 시스템, 결정론적 호출 데이터 형식, 프로토콜 계층의 숨겨진 보장을 갖춘 제한된 실행 환경을 가정하므로, Cube는 기존 EVM 호환 시스템에서 요구되는 메타데이터 오버헤드를 대량 제거할 수 있습니다.

APE는 여러 상호 보완적인 압축 및 인코딩 기술로 구성됩니다.

1. 비트 수준 인코딩

Cube는 EVM 및 zkEVM 시스템에서 사용하는 기존의 바이트 기반 인코딩 방식 대신 거래 필드 및 숫자 유형에 비트 수준 인코딩을 사용합니다.

RLP 와 같은 기존 인코딩 방식은 바이트 수준에서 작동합니다. 즉, 실제 값의 엔트로피를 표현하는 데 필요한 비트 수가 훨씬 적더라도 값은 바이트 정렬된 표현으로 확장됩니다. 대규모 트랜잭션 페이로드의 경우 이로 인해 상당한 누적 오버헤드가 발생할 수 있습니다.

APE는 이러한 바이트 정렬 가정을 제거하고 명목상의 타입 너비가 아닌 실제 엔트로피를 기반으로 값을 비트로 직접 인코딩합니다.

예를 들어, 기존 시스템은 다음과 같은 특징을 가졌습니다.

• u32 (부호 없는 32비트 정수) 값을 직렬화하려면 4바이트를 사용합니다.
• u64 값을 직렬화하려면 8바이트를 사용합니다.

실제 표현 범위와는 관계없이 말입니다. 하지만 실제로는 인덱스 번호, 태그, 선택기, 카운터, 간결한 숫자 유형과 같은 많은 거래 필드는 전체 공간을 거의 사용하지 않습니다.

따라서 APE는 이러한 필드를 일반적으로 더 작은 바이트 표현으로 동적으로 압축합니다.

• 이렇게 하면 u32 값 하나당 약 1~3바이트를 절약할 수 있습니다.
• 이렇게 하면 u64 값 하나당 약 1~7바이트를 절약할 수 있습니다.

추가적인 오버헤드는 1~2비트에 불과할 것입니다.

Cube는 결정론적이고 프로토콜에 의해 제약된 실행 환경에서만 작동하며, 호출되는 데이터의 형식과 유형 구조가 알려져 있기 때문에 이 접근 방식은 매우 효율적입니다. 따라서 Cube는 RLP 와 같은 재귀적이고 자체 설명적인 메타데이터 구조를 필요로 하지 않고도 직렬화 오버헤드를 적극적으로 줄일 수 있습니다.

참고: 숫자 유형 .

2. 순위 기반 지표

Cube는 계정과 계약을 등록 순서가 아닌 거래 빈도를 기준으로 색인화합니다.

계정이 거래를 시작하거나 계약이 실행될 때마다 해당 계정의 점수는 1점씩 증가합니다. 시간이 지남에 따라 자주 액세스되는 계정과 계약은 더 작은 점수 비중을 차지하게 됩니다.

이를 통해 AMM 풀, 스테이블코인 계약, 주요 유동성 센터와 같이 많이 사용되는 시스템 기본 요소들을 매우 작은 인덱스 표현으로 압축할 수 있으며, 일반적으로 단일 바이트 주소 지정이 가능해집니다.

이 순위 및 인덱싱 시스템은 메모리와 실행 계층에서 유지되므로 Cube는 20바이트 EVM 주소 또는 고정 길이 계약 식별자와 같은 대용량 정적 식별자를 반복적으로 전송하는 것을 방지할 수 있습니다.

참조: 등록 관리자 .

3. 접두사가 없는 통화 데이터

큐브는 데이터 요소를 미리 정의된 형식에 직접 매핑하며, 각 형식은 정해진 길이를 가집니다.

결과적으로, calldata 요소는 데이터 앞에 숫자 길이를 접두사로 붙이는 명시적인 재귀적 인코딩 방식(예: RLP 방식)을 필요로 하지 않습니다. 디코더가 calldata 형식의 예상 구조와 필드 너비를 이미 알고 있기 때문에 추가적인 접두사 메타데이터가 불필요해집니다.

이를 통해 EVM 호출 데이터 직렬화와 항상 연관되어 있던 접두사 오버헤드가 제거되는 동시에 결정론적 페이로드 구문 분석이 단순화됩니다.

자세한 내용은 Calldata 요소를 참조하세요.

4. 일반적인 숫자 조회 테이블

Cube는 자주 발생하는 거래 값에 대해 조회 기반 인코딩 메커니즘을 사용합니다.

자주 사용되는 값(예: 일반적인 이체 금액, 유동성 수량, 계약 상호 작용 금액)은 전체 너비 형식으로 반복적으로 직렬화하는 대신 간결한 조회 테이블 인덱스로 표현됩니다.

이 최적화는 대규모 거래 데이터 세트에서 액면가 패턴이 반복적으로 나타나는 금융 데이터에 특히 유용합니다. Cube는 반복되는 숫자 패턴을 간결한 조회 테이블 인덱스로 인코딩함으로써 대량 인 로드 오버헤드를 크게 줄입니다.

참고: 공통 값 .

5. 간결한 메서드 호출

Cube는 또한 AtomicVal 이라는 간결한 가변 길이 기본 요소를 사용하여 계약 호출 메서드를 인코딩합니다.

EVM은 4바이트 함수 선택기를 사용하는 반면, Cube는 계약 내에서 호출될 수 있는 메서드를 표현하기 위해 가능한 한 적은 비트를 동적으로 할당합니다.

예를 들어, 호출 가능한 메서드가 네 개 있는 계약은 단 2비트만 사용하여 메서드를 선택할 수 있습니다.

이는 각 호출의 오버헤드를 크게 줄여주며, 트랜잭션 처리량이 증가할수록 더욱 큰 이점을 제공합니다.

참고: AtomicVal .

6. 서명 집계

Cube는 계정의 Schnorr 공개 키를 BLS 호환 집계 공간 에 매핑하고 거래 간에 비대화형 서명 집계를 수행합니다.

그 결과, 여러 거래에 대한 서명을 고정 길이의 통합 서명으로 압축 할 수 있으며, 각 거래마다 서명을 하거나 대량의 영지식 유효성 증거를 필요로 하지 않게 됩니다.

이는 서명과 관련된 데이터 가용성 오버헤드를 크게 줄이는 동시에 간결한 블록 수준 검증 의미론을 유지합니다.

참고: BLS .

7. 최소화된 목표 인코딩

Cube는 또한 기존의 nonce 기반 트랜잭션 순서Target 이라는 간결하고 리플레이 공격에 강한 필드로 대체합니다.

큐브에서 항목은 단조롭게 증가하는 계정 논스를 가지는 대신, 특정 배치 높이에서 실행되도록 의도된 항목을 나타내는 최소한으로 인코딩된 대상을 가집니다. 이 대상 메커니즘은 현재의 배치 메커니즘과 제한된 백트래킹 윈도우(최대 5개 배치)를 지원합니다.

이는 재전송 라인의 지연을 방지합니다(악의적인 엔진은 실행하려는 항목을 보류하거나 이전에 서명된 항목을 방송하기 전에 향후 상태 전환을 기다릴 수 있습니다). 항목은 의도된 실행 기간 내에서만 유효하므로 이후의 재전송 시도는 무효화됩니다.

실제로 대부분의 항목은 현재 배치 높이를 대상으로 하므로 인코딩 오버헤드가 매우 작습니다. 현재 높이에서의 실행을 나타내는 데 1비트면 충분하며, 추가적인 백트래킹 깊이를 나타내는 데에는 2비트만 더 필요합니다.

그 결과, Cube는 기존의 고정 폭 논스 필드(일반적으로 8바이트)를 여러 비트를 필요로 하는 재실행 방지 메커니즘으로 대체했습니다. 자세한 내용 은 항목을 참조하십시오.

자세한 내용은 Target 웹사이트를 참조하세요.

8. 경제적 영역을 최소화하십시오

Cube는 기존의 통계적 가스 필드를 Ops Price 및 Ops Budget 이라는 간결하고 운영 기반의 필드로 대체합니다.

Cube는 각 항목에 대해 크고 고정된 너비의 가스 매개변수를 반복적으로 인코딩하는 대신 프로토콜에서 정의된 기본값을 가정하고 해당 기본값과의 차이만 인코딩합니다.

Ops Price 필드는 이 항목에 프로토콜의 기본 실행 가격을 사용할지 또는 추가 실행 프리미엄을 지정할지를 나타냅니다. 일반적으로 기본 가격 사용을 나타내는 데에는 1비트면 충분합니다. 프리미엄이 필요한 경우 기본 가격과의 차액을 간결하게 인코딩하면 됩니다.

마찬가지로, Ops Budget 필드는 이 항목에 대해 사용자 지정 실행 예산을 지정해야 하는지 여부를 나타냅니다. 1비트만으로도 명시적인 예산이 있는지 여부를 판단할 수 있습니다. 예산이 있는 경우, 추가 비트는 요청된 예산 금액을 인코딩합니다.

실제로 대부분의 항목은 기본 실행 가정에 따라 작동하며 두 필드는 일반적으로 매우 적은 비트를 사용합니다. 그럼에도 불구하고 필요한 경우 가변 실행 가격과 제한된 실행 제어를 지원할 수 있습니다.

자세한 내용은 운영 비용 및 운영 예산을 참조하십시오.

9. 주장

Cube는 어설션 기반 실행 모드로 작동하며, 유효한 트랜잭션만 가치 있는 배치에 포함되도록 합니다.

상태 전환 실패는 최종 페이로드에서 제외되므로 영구 데이터 공간을 소모하지 않습니다. 이와 대조적으로 EVM 및 zkEVM 시스템은 실행 결과가 유효하지 않거나 반대로 되어 있더라도 실패한 트랜잭션을 온체인 영구적으로 기록합니다.

Cube는 실패한 실행을 영구적으로 기록하는 메커니즘을 제거함으로써 기록 블록 공간 효율성을 높이고 더욱 명확한 실행 상태 패턴을 형성합니다.

TPS 예측

다음 섹션에서는 표준 APE 트랜잭션 패러다임을 사용한다고 가정했을 때 Cube의 이론적인 트랜잭션 처리량을 추정합니다. 이 추정치는 주로 원시 데이터 가용성 효율성에 초점을 맞추고 Cube를 zkEVM 스타일 롤업 및 기존 EVM 트랜잭션 형식과 비교합니다.

Cube는 비트 수준 인코딩, 컴팩트 인덱싱, 논스 프리 메커니즘, 경제 필드 최소화, 컴팩트한 호출 데이터 형식, 상황별 호출 메서드 인코딩 등을 통해 트랜잭션 직렬화 오버헤드를 획기적으로 줄이기 때문에 평균 트랜잭션 페이로드 크기가 기존 스마트 계약 시스템보다 훨씬 작습니다.

AMM 스왑

-자동 마켓메이커(AMM) 스왑 - TPS 예측-

일반적인 자동 마켓메이커(AMM) 스왑 작업을 예로 들면, 각 큐브 트랜잭션은 약 10.7바