Maxim Orlovsky, LNP/BP 표준 협회
이 논문에서는 필수 소프트 포크없이 비트 코인 레이어 1 (블록 체인/타임 체인)을 업그레이드하는 방법을 제안합니다. 업그레이드는 클라이언트 측 유효성 검사의 속성을 활용하고 점진적 일 수 있으며 권한없는 배포 옵션 (즉, 다수의 지원 또는 광부 협력이 필요하지 않음)이 있으며 주문의 확장 성이 있습니다.
비트 코인이라는 단어는 여러 의미를 얻었으므로보다 구체적인 용어를 사용하여 구별합니다. 우리는 비트 코인을 시스템 전체를 나타내는 일반적인 우산 용어로 사용합니다. 여기에는 여러 계층 (일부 미래 포함)과 Satoshi Nakamoto에서 유래 한 피어 투 피어 전자 현금 시스템의 전반적인 아이디어가 포함될 수 있습니다. 동시에, 우리는 BTC를 사용하여 비트 코인을 디지털 부족, 돈 및 통화로 표시합니다. 또한 Bitcoin Pow Consensus (다음 블록 생산자를 선택하는 규칙), Nakamoto Consensus (암호 경제적 광부 처벌 수단으로 강화 된 POW 합의 포함), 비트 코인 블록 체인 (대안으로 명명 된 Timechain )을 비트 코인 레이어 1 및 비트 코인 프로토콜 (BP)은 비트 코인 트랜잭션 온 체인 (가능한 임의의 층 1)으로 일하기위한 일련의 표준, 기술 및 도구입니다.
Nakamoto Satoshi의 Bitcoin의 원래 구현은 모든 사람이 전 세계의 거래를 확인해야한다는 이상한 생각을 가져 왔습니다. 이 아이디어는 블록 체인 또는 때로는 Timechain 의 이름을 받았으며, 이는 공개 접근이있는 원장의 완곡 성이되었습니다. 원장의 도입은 확장 성이없고 개인 정보가 부족한 두 가지 문제를 일으켰습니다. 첫 번째는 채택 및 네트워킹 효과가 발생하는 것을 방지합니다. 다른 하나는 비트 코인의 원래 사이퍼 펑크 정신과 모순되며 전략적 문명 위험을 나타냅니다 (적절한 문명과 사이프 러스 선언문을위한 Cypherpunk의 필연적 참조).
확장 성 및 부분적으로 개인 정보 보호 문제는 나중에 Lightning Network 및 기타 제안 된 솔루션과 같은 계층 2 시스템의 도입에 의해 해결되었습니다. 그중에서도 가장 유익한 것은 Sidechain의 아이디어가 있었는데, 이는 오리지널 블록 체인 기술 제한의 대부분을 물려받은 동시에 프로그래밍 가능성이 낮은 문제 만 해결하고 실험을위한 샌드 박스를 만들었고 부분적으로는 개인 정보의 일부 측면을 만들었습니다. Lightning Network- 이미 배포되고 운영되고있는보다 성공적인 계층 2 솔루션은 유동성 과도한 측면화의 필요성, 가십 트래픽 처리량의 한계 (네트워크 중앙 집중화로 이어지는) 및 보안/신뢰성 감소로 인해 자체 확장 성 문제가 있습니다. 높은 기본 층 조건에서 [..]. ARK와 같은 다른 제안 된 대안은 여러 기본 계층 변경 (하나 또는 2 개의 SoftForks)이 필요하며, 이는 배치에 대한 과제를 나타냅니다. 마지막으로, 기존 또는 제안 된 제 2 계층 솔루션 중 어느 것도 원래 비트 코인베이스 레이어 개인 정보 보호 문제를 해결하지 못하고 다른 개인 정보 중심의 계층 -1 솔루션 (Coinjoin과 같은)은 여전히 법률 당국으로부터 보호하지 않고 추가 BTC 열무성 문제를 도입하지 않습니다.
따라서, 위의 문제를 해결하기 위해 완전히 다시 생각 해야하는 것은 층 1을 구축하기위한 원장 기반 블록 체인 접근법이라고 결론 지을 수 있습니다. 이 공간의 첫 번째 아이디어는 2016 년과 2017 년에 Peter Todd의 Back Back과 함께 일부 주 소유자 (예 : BTC 또는 기타 국가 계약)가 거래 기록의 일부를 확인해야한다고 지적했습니다. 소유권과 직접 관련이 있으며 나머지는 생략합니다. 그는 자신의 접근 방식 고객 측 검증을 지명했습니다. Giacomo Zucco는 RGB 라는이 접근법을 사용하여 자산을 생성 할 수있는 프로토콜을 설계했습니다. LNP/BP 표준 협회 (LNP/BP Standards Association)에서의 이전 작업에서 RGB를 더욱 발전시켜 풍부한 상태 및 제한된 튜링 컴퓨팅 컴퓨팅을 갖춘 최초의 일반 클라이언트 측면 검증 스마트 계약 시스템으로 변환 할 수 있었으며, 블록 체인 기반 스마트 계약으로 수행 할 수 있지만 공개 원장/블록 체인이없는 사용자 데이터를 저장하지 않고 Bitcoin POW Consensus 프로토콜의 더블 지출 방지 속성을 직접 사용합니다. 이 시스템은 4 년 동안 공개적으로 개발되었으며 2023 년 4 월에 출시되었습니다.
현재 제안에서 우리는 비트 코인 (RGB와 같은 상태 가득한 클라이언트 측면 검증 레이어)이 제공되는 경우 공개 원장 (블록 체인)의 제한 속성없이 시스템으로 업그레이드 할 수 있으며 POW Consensus 프로토콜을 보존하는 동안 시스템으로 업그레이드 할 수 있습니다. 새로운 확장 가능한 비 블록 체인 레이어 1 (코드 라임 프라임 )에 다시 기반 할 수 있습니다. 이 계층은 상태, 컴퓨팅 및 유효성 검사가 위의 클라이언트 측 식 레이어로 이동하기 때문에 이론적으로 무기한 거래 수 (분당 최소 수십억)를 호스팅 할 수 있습니다. 이러한 설계는 최악의 시나리오에서 번개 네트워크 또는 기타 확장 성 및 기타 확장 성 및 지불 계층이 필요하지 않습니다.
프로토콜에는 3 가지 배포 옵션 (허가 없음, 광부 활성화 및 소프트 포크)이 있으며, 처음 두 개는 소프트 (또는 하드) 포크가 필요하지 않습니다. 옵션은 독립적이지만 결과적으로 배포 할 수도 있습니다.
이 제안은 비트 코인에게 디지털 현금으로 몇 가지 이점을 제공합니다.
제안 된 시스템의 일부 상대 단점은 다음과 같습니다.
제안 된 시스템 (CodeName Prime )은 4 가지 주요 구성 요소로 구성됩니다.
이러한 구성 요소는 블록 체인 유형 원장과의 기능에서 공동으로 동일합니다. 그러나 우리의 디자인에서 그들은 추상화되어 다른 블록 체인 시스템보다 훨씬 더 많은 확장 성과 개인 정보를 제공합니다.
Foundation Prime에서는 타임 스탬핑 서비스를 실행하여 일련의 헤더를 생성하며, 각각의 헤더 시퀀스를 생성합니다.
ClassDiagram
방향 LR
`헤더 n` <|-`헤더 n+1 '
클래스`헤더 n` {
prev_commitment
merkle_root
merkle_tree_height
타임 스탬프
// pow 필드
tlv_extensions
}
클래스`헤더 n+1` {
prev_commitment
merkle_root
merkle_tree_height
타임 스탬프
// pow 필드
tlv_extensions
}
각 헤더에는 옵션 TLV 확장이 장착되어 있으며 향후 프로토콜 업그레이드에 사용될 수 있습니다. 크기는 클라이언트 측면 검증 데이터의 머클 트리에 포함 된 트랜잭션 수와 무관하며 (TLV 데이터에 따라) 100 바이트 순서입니다.
프라임은 이중 지출로부터 보호를 제공하지 않습니다. 시스템의 클라이언트 측면 검증 부분에 의해 제공됩니다. 검증 된 타임 스탬핑 시스템의 유일한 부분은 다음과 같습니다.
프라임 헤더는 공개적으로나 전 세계적으로 제공 해야하는 유일한 정보입니다. 이것은 분산 된 P2P 네트워크를 사용하여 달성 할 수 있습니다.
증거 머킬 트리 ( PMT )는 클라이언트 측면 데이터를 헤더에 연결하는 중간 및 임시 구조입니다. PMT는 광부에 의해 생산되며 헤더와 동일하거나 다른 수단을 통해 대중에게 제공됩니다. 그러나 헤더와 달리 지속될 필요는 없습니다. 각 네트워크 사용자는 모든 새로운 PMT를 추적하고 소유 한 상태와 관련된 정보의 일부를 추출하고이를 클라이언트 측면 데이터의 자체적으로 보관하고 나머지 PMT를 폐기합니다.
임시 특성으로 인해 검증이없고 다음 헤더를 채굴하기위한 PMT 컨텐츠를 알 필요가 없기 때문에 PMT 크기는 시스템 확장성에 영향을 미치지 않습니다. 따라서 PMT는 (다중) 기가 바이트 크기 일 수 있으며 수십억 및 수십억 건의 거래를 약속 할 수 있습니다.
나무의 잎에는 한 번의 사용을 닫는 증인이 포함되어 있습니다. 다음 섹션에서 자세히 설명 된 메커니즘. PMT는 다중 보호대안 결정 론적 약속 체계 LNPBP-4 표준에 따라 구성되며 오늘날 RGB에서 비트 코인 트랜잭션에서 약속을 주최하는 데 사용됩니다 (쇄 및 내부 오프 체인 프로토콜 모두 Lightning과 같은 Offchain 프로토콜). 이는 각 단일 이용 시알에 PMT에 고유 한 사전 정의 된 배치가 있음을 의미하므로 단일 머클 경로와 잎 증인이 주어진 헤더. 사용자는 아직 닫히지 않은 단일 사용 (UTXO 세트의 아날로그) 세트를 추적하고 새로 생산 된 각 PMT에서 상대 증거를 추출합니다. 그들의 물개가 닫히지 않았다면, 이것들은 비수법의 증거입니다 (증인은 그 길에서 다른 단일 이용 실 밀봉이 닫히는 것을 보여주기 때문에).
증거는 클라이언트 측면 검증 이력의 시간 의존적 성장 부분을 구성합니다. 노드에 대한 메모리 요구 사항은 다음과 같이 시간 의존적으로 증가합니다.
어디
이것은 메모리 요구 사항이
어디
어디
그만큼
어디
단일 이용 할 수있는 프로토콜은 시스템에 대한 이중 지출 공격을 방지합니다.
단일 이용 밀봉 (또는 씰 )은 Peter Todd가 제안한 특별한 형태의 암호화 약속입니다. 원시는 해시 함수 및 타임 스탬핑을 포함하는 다른 형태의 암호화 약정과 비교할 수 있습니다.
일회용 밀봉 건설에 대한 자세한 내용은 LNPBP-8 표준에 나와 있습니다. Prime은 기존 프로토콜 (RGB)에 사용 된 것과는 다른 특수 설계된 단일 이용 실용 형태를 사용합니다.
일회용 밀봉의 정의는 두 가지 구성 요소로 구성됩니다.
unique_id : Contract_ID, Contract Operation HASH 및 Contract Operation Output Number에서 결정적으로 생성 될 수있는 Globally-Unique 사용자 생성 식별자;spending_conditions_cmt : 씰이 닫을 수있는 조건의 약속 (Bitcoin Transaction Output의 scriptPubkey 와 유사). 씰은 클라이언트 측 확인 스마트 계약 시스템 (RGB 또는 RGB 유사)에 정의됩니다. 각 씰은 예를 들어 BTC 균형 또는 기타 풍부한 데이터와 같은 지정된 상태 (RGB에서와 같이)를 가질 수 있습니다. 사용자가 해당 상태를 업데이트하거나 다른 사용자에게 소유권을 전송하는 것을 좋아하는 경우, 새로운 일회용 밀봉 및 새로운 상태를 정의하여 상태 전환을 준비해야합니다. 다음으로, 단일 이용 실 밀봉이 구성되어 주 전환 데이터를 약속하고 소스 스크립트를 제공하고 지출 조건의 약속과 일치하며 해당 스크립트/조건을 만족하는 데이터를 마감한다는 증인 . 제안은 사용 된 특정 스크립팅 시스템의 초록을 초록합니다 (오늘날 RGB에서와 같이 단순성, Aluvm이 될 수 있으며 EVM이 아님; :); 스크립팅 엔진은 version 필드를 사용하여 지정할 수 있으며, 시간이 지남에 따라 새 엔진 또는 오크 코드를 도입 할 수 있습니다 (업그레이드 섹션 참조).
ClassDiagram
방향 LR
정의 <|- 증인 : 고유 한
클래스 정의 {
고유 한
Spending_Conditions_CMT
}
클래스 증인 {
버전
고유 한
state_transition_cmt
지출 _conditions_src
만족 _data
}
증인은 ptree의 잎 안에 명백한 형태로 배치되어 광부에게 제공되어 ptree와 헤더를 구성합니다. 잎은 SEAL unique_id (예 : 슬롯)에 관해 결정적으로 머클 트리 안에 넣어야합니다.
Leaf Matching unique_id 에 대한 머클 경로, 잎 내용물 (증인 데이터 제공)과 함께 각 단일 이용 실 밀봉은 스마트 계약의 역사에서 한 번만 한 번만 폐쇄되었는지 확인할 수 있으며 스크립트를 만족 시켜서 닫혀 있음을 확인할 수 있습니다. 정황. 정의 시점부터 폐쇄까지의 각 단일 이용 실용 고유 unique_id 에 대한 증거는 축적되어야합니다. 이 증거는 다른 unique_id 고유 한 지출 조건 소스 코드 및 만족 데이터를 생략하여 해시 만 제공 할 수 있습니다. 따라서 역사적 증인은 고정 된 규모 일 수 있습니다. 앞에서 언급했듯이 확장 성 목적으로 증명 기록은 제로 지식 증명을 사용하여 추가로 압축 될 수 있습니다.
이 시스템은 권한없는 옵션으로 배포 할 때 자체 합의 프로토콜이 필요합니다. 프로토콜의 보안은 아래에 설명 된 전용 메커니즘으로 비트 코인 POW 보안에 맞춰져 있기 때문에 중요하지 않습니다. 합의에 대한 유일한 요구 사항은 검열에 강한 것이며, 이는 신원이없는 광부/검증 자의 개방 된 세트를 의미합니다. 이러한 특성을 만족시키는 것으로 알려진 유일한 두 합의 프로토콜은 POW와 광부 보상에 의해 암호 경제적으로 보안 된 BFT 합의의 ouroboros crypsinous 변형입니다.
타임 스탬핑 서비스는 암호 화폐를 깎지 않으며 광부는 1 일부터 수수료를 보상합니다. 광부 수수료에 대한 전용 계약은 RGB 또는 기타 고객 측면 검증 된 스마트 계약 프로토콜 (BTC)에 의해 제공됩니다 (BTC , stablecoin 또는 토큰 화 지불). 광부는 허가없는 익명의 P2P 네트워크에 참여해야하며, 여기서 프로토콜 사용자는 "다음 헤더를 광산하는 사람"에게 수수료를 지불하는 거래가 장착 된 증인을 게시합니다. 광부는 이러한 거래를 고객 측면 검증 이력에 포함시키고 향후 획득 자금을 사용할 수있는 능력을 갖추고 있습니다.
시스템의 순간에 비트 코인 블록 체인에 위의 더러워진 양의 SAT가있는 전용 "모든 사람-캔 스펜드"출력을 시작합니다. 이 UTXO에 대한 정보는 창세기의 일부가되어 마이닝 단일 이용 실용 의 정의 역할을합니다. POW Challenge를 해결하는 광부는 해당 생산량을 지출해야하며 지출 비트 코인 거래 내부에서는 채굴 된 헤더와 다음 광부에 대한 새로운 "모든 사람이 스펜한"단일 이용 할 수 있습니다. 이것은 생성 된 헤더를 비트 코인 블록 체인에 고유 한 방식으로 고정시켜 유효한 타임 스탬프 헤더 시퀀스 가이 단일 사용 시퀀스를 따르는 것입니다.
당사자가 약속을 만들지 않고 현재 광부 단일 이용 밀봉을 소비하거나 충분한 POW없이 헤더를 약속하는 경우, 그러한 폐쇄는 무효로 간주됩니다. 이 경우, 모든 당사자는 새로운 광부 단일 이용 실 밀봉 ( 프로토콜 재설정 )에 대해 공개적으로 식별 가능한 OP_RETURN 정보 ( "공지")를 제공하는 특수 비트 코인 트랜잭션을 만들 수 있습니다. 적절한 절차로 닫힌 첫 번째 OP_RETURN 발표 만 합의 규칙에 따라 유효한 것으로 간주됩니다.
POW 단일 이용 실 밀봉 앵커링은 다른 추가 합의 (POW 또는 BFT)없이 시스템에서 실행할 수있는 완전한 합의 프로토콜을 나타냅니다. 또는 2 차 합의 프로토콜의 보안이 비트 코인 POW 보안보다 낮지 않으면 Bitcoin POW가 우선 순위를 가짐으로써 2 차 합의와 결합 될 수 있습니다. 조건이 충족되지 않습니다.
우리는 여러 대체 시스템이 시장 중심의 방식으로 공존하고 경쟁 할 수 있기 때문에이 제안에서 P2P 네트워크 구조의 문제를 고의적으로 다루지 않습니다. 대신, 네트워크 속성은 프로젝트의 목표에 중요하므로 P2P 네트워크 선택에 대한 일반적인 요구 사항을 정의합니다.
현재의 순간에 우리는 앞서 언급 한 속성을 만나는 네트워크가 보이지 않습니다. 그러나 우리는 여러 네트워크가 그들을 향해 발전 할 가능성이 있습니다.
우리는 Storm 프로토콜의 이전 작업을 활용하고 BIP-324 스타일의 엔드 투 엔드 암호화를 사용하여 Renostr 프로젝트를 진행할 계획입니다. 다른 프로젝트는 대체 솔루션을 구축 할 수 있으며 시장에서 가장 좋은 옵션을 선택해야합니다.
제안 된 솔루션을 Bitcoin에 배포하는 방법에 대한 세 단계 또는 옵션이 있습니다. 각 단계는 선택 사항입니다. 시스템은 한두 가지없이 작동 할 수 있습니다. 또한 각 옵션에는 자체 트레이드 오프가 있지만 결과적으로 단계적으로 배포하면 이러한 트레이드 오프가 점차 해결됩니다.
이 시스템은 Bitcoin Timechain과 독립적으로 출시 될 수 있으며, 단일 사용에 기반한 전용 메커니즘 (논문에서 설명)을 통해 Bitcoin Pow의 보안에 합의 된 합의가 있습니다. 이를 위해서는 광부 또는 비트 코인 소프트/하드 포크의 변경이 필요하지 않지만이 설정을 통해 BTC는 한 가지 방법으로 만 새로운 시스템으로 전송 될 수 있으며 다른 방법으로는 연합이 필요합니다.
Bitcoin Miners는 Prime Transactions를 처리하기 시작하고 병합 마이닝의 경우와 같이 Bitcoin 블록 체인 코인베이스에 대한 타임 스탬핑 서비스 헤더에 대한 노력을 기울입니다. 이로 인해 전용 프라임 컨센서스가 필요하지 않지만 해시 전력 공격에 취약하므로 대다수의 광부가 배치 전에 프로토콜에 가입해야합니다.
이 제안에는 특정 소프트 포크가 필요하지 않지만, 현재 비트 코인 컨센서스 규칙에 따라 BTC가 새로운 프라임 시스템에서 비트 코인 블록 체인으로 이동하는 신뢰할 수없는 방법을 제공 할 수는 없습니다. 우리는 이것을 요구 사항으로 보지 않지만 (Prime은 블록 체인에 대해 너무 많은 이점이있어 블록 체인이 이미 장기적으로 죽었다고 생각합니다) 단기적으로는 플랫폼 채택에 대한 과제를 제시 할 수 있습니다.
그러한 기능을 가능하게하는 다양한 소프트 포크 제안이 있습니다. 그들은 두 가지 주요 범주에 속합니다.
이러한 제안을 채택하면 프라임 플랫폼에서 BTC에 대한 신뢰할 수없는 페그 아웃이 가능합니다. 우리 자신의 선호도는 제로 지식을 향상시키는 OP 코드 이후에 진행됩니다. 왜냐하면 그들은 다른 많은 혜택이 있고 드라이브 체인에서 피할 수없는 트레이드 오프를 제공하지 않기 때문입니다.
클라이언트 측면 검증 시스템 업그레이드는 블록 체인 또는 P2P 네트워크 (Lightning) 업그레이드와 매우 다릅니다. 이는 블록 체인이 완전히 복제 된 상태 머신 인 컨센서스 프로토콜이며 클라이언트 측 유효성 검사는 부분 복제를 사용한다는 사실에 의해 발생합니다. 이것은 한편으로, 알 수없는 상태와 관련된 부분으로 시스템을 업그레이드하는 것이 더 간단하지만, 다른 한편으로는 네트워크가 제공하는 전 세계적으로 접근 가능한 상태에 대한 비 암성 경제적 구동 보증이 없기 때문에 , 업그레이드를 조정하는 것이 훨씬 어렵습니다.
다시 말해, 클라이언트 측 확인 업그레이드는 근본적으로 블록 체인 하드 포크 및 소프트 포크와 다르며 새로운 개념과 용어를 도입해야합니다.
업그레이드 후 유효하지 않은 것이 유효하지 않은 경우 (우리는이 빠른 변화를 호출합니다), 모든 기존 사용자는 영향을받지 않습니다. 이미 유효한 상태를 소유하고 관리합니다. 그러나 이전 버전의 소프트웨어를 실행하는 사용자와 상호 작용할 수 없을 수도 있습니다. 동료가 업그레이드에 동의하는 경우 해결할 수 있습니다. 업그레이드는 그들이 보유한 주를 사용하지 않기 때문에 해당 동료들에게는 위험을 초래하지 않으며 업그레이드는 역사적 데이터에 영향을 미치지 않습니다.
반면에, 무언가가 유효하고 새로운 규칙에 따라 유효하지 않은 상황은 매우 다릅니다. 사용자는 기존 상태를 영원히 잃을 수 있으며 가능한 한 업그레이드에 반대해야합니다. 우리는 그러한 업그레이드를 푸시백 이라고 부르며, 중요한 버그가 발견 된 경우에만 허용 가능한 것으로 간주합니다. 버그가 도입 한 문제를 피하려는 성실한/비 체적 사용자의 욕구에 의해 업그레이드가 "조정"됩니다.
RGB 또는 RGB에서 영감을 얻은 시스템이 스마트 계약 구성 요소로 사용되는 경우이 부분으로의 업그레이드에는 또 다른 특징이 있습니다. RGB는 각 프로그램 ( "스마트 계약")을 샌드 박스로 분리합니다. 그리고 계약이 발행되면 새 버전의 프로토콜로 업그레이드 할 수 없습니다. 업그레이드하는 유일한 방법은 발행자 (또는 커뮤니티를 포함하여 발행인이 위임 한 당사자)가 이전 계약에서 새 계약으로 주 양도를 수행 할 때 새로운 계약을 체결하는 것입니다. 소유자는 이에 동의합니다.
이 방법 으로이 접근 방식은 블록 체인 세계에서 달성 할 수없는 새로운 기능, 지침 등을 점진적으로 도입 할 수 있습니다. 새로운 계약의 발행자는 이전 프로토콜 버전에 의존하지 않으며 추가 업그레이드 위험 또는 추가 업그레이드 위험없이 더 많은 고급 솔루션을 제안 할 수 있습니다. 커뮤니티 조정.
저자는 제한된 블록 체인에 대한 비트 코인 의존성을 제거하고 고객 측정을 앞으로 나아가는 것을보고 있다는 아이디어를 가진 사람이었던 Giacomo Zucco에게 감사합니다. 수년 동안 그와 Peter Todd와의 여러 논의는 시스템의 많은 부분을 설계하는 데 도움이되었습니다. 다른 작가 중에서도 클라이언트 측정, 블록 체인 결함 및 블록 체인없는 디자인과 관련된 문제를 논의하는 데 많은 시간을 보냈던 대담자인 Alex Kravets, Federico Tenga, Olga Ukolova를 언급하고 싶습니다.
