저자: 피터 토드
출처: https://petertodd.org/2024/covenant-dependent-layer-2-review
온체인 지갑은 거래에서 거래로 (대략) 일대일 매핑을 구현합니다. 사용자가 수행하려는 경제적인 거래를 위해서는 대략 블록체인 거래가 필요합니다. 트랜잭션 집계, 코인조인, 컷스루 및 기타 기술은 모두 약간씩 차이가 있지만 일반적으로 우리의 진술은 여전히 정확합니다.
라이트닝 채널은 다대일 매핑을 구현합니다. 라이트닝 채널의 마법은 사실상 무제한의 경제적 거래가 채널 내에서 발생할 수 있고 채널 자체가 사용되지 않은 거래 출력(UTXO)에 바인딩된다는 것입니다. 본질적으로 우리는 "시간" 차원(트랜잭션)을 포착하고 이 차원을 축소하여 상당한 확장을 달성했습니다.
그러나 각 사용자가 UTXO를 생성하도록 하는 것만으로는 충분하지 않습니다(적어도 틀림없이). 따라서 더 큰 확장 효과를 달성하기 위해 자율적인 보관을 위해 여러 사용자가 UTXO를 공유할 수 있도록 하는 많은 제안이 등장했습니다. 이번에는 "공간" 차원(사용자)이 UTXO로 축소됩니다.
여기서 나의 목표는 이러한 모든 제안을 검토하고, 공유하는 기술 패턴을 식별하고, 필요한 새로운 opcode 유형 또는 소프트 포크 업그레이드를 식별한 다음, 모두 테이블에 들어갈 수 있는 포괄적인 테이블을 구축하는 것입니다. 이 과정에서 우리는 "레이어 2 프로토콜"이 무엇인지, 라이트닝 네트워크에서 이미 어떤 확장이 가능한지 정의하고, 이러한 제안을 구현하기 위해 멤풀에 어떤 업그레이드가 필요한지 이해하게 될 것입니다.
이 연구에 자금을 지원한 Fulgur Ventures 에 감사드립니다. 그들은 이 기사의 내용에 대한 편집 권한이 없으며 출판 전에 검토하지 않았습니다.
출판 전에 검토해주신 Daniela Brozzoni , Sarah Cox 및 기타 분들께 감사드립니다.
1 정의
1.1 "레이어 2"란 무엇입니까?
일반적으로 사람들은 "레이어 2"에 대한 광범위한 정의를 사용하므로 은행(예: Liquid)도 레이어 2로 정의할 수 있습니다. 이 기사의 목적을 위해 우리는 더 좁은 정의를 채택할 것입니다. 레이어 2는 BTC가 온체인 거래보다 더 높은 빈도로 관련 당사자 간에 거래될 수 있도록 하기 위해 존재하는 비트코인 표시 시스템입니다.
- 시스템 내의 벌금과 비용을 고려하면 누구도 시스템에서 자금을 훔쳐서 이익을 얻을 수 없습니다. 평판 손상, 법적 결과 등과 같은 시스템 외부의 비용 및 처벌은 우리의 정의에서 고려되지 않습니다 .
- (선호) 자금의 실제 소유자는 제3자의 협력 없이 일방적으로(거래 수수료 제외) 자신의 자금을 인출할 수 있습니다.
첫 번째 항목은 L2 시스템이 온체인으로 표시하기에는 너무 작은 금액과 거래를 표시할 수 있기를 원하기 때문에 필요합니다. 예를 들어, 라이트닝 채널에서 HTLC는 온체인으로 표현하기에는 너무 작은 액면가를 가질 수 있습니다. 이 경우 약정된 거래의 거래 수수료에 HTLC의 가치가 추가됩니다. 라이트닝 노드는 더스트 HTLC를 "훔치기" 위해 목표한 방식으로 채널을 닫을 수 있지만 그렇게 하는 것은 매우 비용이 많이 들고 [1] 비용이 HTLC 자체의 가치를 초과하므로 도난은 수익성이 없습니다.
두 번째 항목은 일방적인 철수가 항상 우리의 주요 설계 목표라는 것입니다 [2] .
이 정의에 따르면 라이트닝 채널은 L2 시스템으로 간주됩니다. 그러나 Liquid, Cashu 및 Fedemint와 같은 시스템은 다른 당사자(또는 당사자)가 귀하의 자금을 통제하기 때문에 L2 가 아닙니다 . "클라이언트 측 검증" 솔루션(예: RGB) 도 이 정의에 따른 L2가 아닙니다 . 왜냐하면 BTC 자체를 무신뢰로 전송할 수 없기 때문입니다. 마지막으로, “ Statechains ”도 이 정의( 중국어 번역 )를 충족하지 않습니다. 왜냐하면 Statechain 엔터티(서비스 제공자)가 의도적으로 계약을 준수하지 않는 경우 자금이 도난당할 수 있기 때문입니다.
1.2 "제한사항"이란 무엇입니까?
...그렇다면 왜 L2 시스템에 더 큰 확장성을 달성하기 위해 제약이 필요한가요?
비트코인 스크립트 프로그래밍에서 "제한 조항"은 트랜잭션 출력(txout)이 소비되는 방식을 미리 제한할 수 있는 메커니즘을 말하며, 이 txout을 소비하는 트랜잭션의 형태가 미리 정의되거나, 제한하는 방식으로 전자 서명에 전적으로 의존하지 않는 비용입니다. 여러 참여자 간에 UTXO를 공유하는 L2 시스템에는 L2 프로토콜의 규칙과 인센티브를 구현하기 위해 UTXO가 소비되는 방식을 제한해야 하기 때문에 제한 조항이 필요합니다.
1.2.1 재귀적 제한
재귀 제한은 UTXO가 소비되는 방식을 제한하는 규칙이 재귀적으로 적용될 수 있으며 지출 거래의 하위 UTXO까지 무기한 확장되는 속성을 갖는 제한입니다. 재귀적 제한은 자금이 영구적으로 묶일 수 있기 때문에 일부에서는 오랫동안 바람직하지 않은 것으로 간주되어 왔습니다 . 아니면 적어도 정부와 같은 제3자의 허가 없이 영원히 갇혀 있게 될 수도 있습니다.
2골
Lightning 채널은 현재 레이어 2 시스템 중 "리더"입니다. 그러나 여기에는 다음과 같은 제한 사항도 있습니다.
- 확장성 - Lightning Channel에서는 현재 각 최종 사용자가 최소한 하나의 UTXO를 보유해야 합니다 [3] .
- 유동성 - 라이트닝 채널에는 자금이 채널에 묶여 있어야 합니다.
- 대화형 – Lightning 채널을 사용하려면 무신뢰 결제를 받으려면 결제 수취인이 온라인 상태여야 합니다.
레이어 2 시스템을 평가할 때 우리의 목표는 이상적으로는 새로운 제한 사항을 도입하지 않고 이러한 주요 제한 사항을 개선하는 것입니다.
2.1 라이트닝 채널의 확장성 제한
실제 시나리오에서 "각 최종 사용자에게 UTXO가 필요하다"는 것은 무엇을 의미합니까? Lightning 채널은 무기한 운영될 수 있으므로 이를 분석하는 한 가지 방법은 연간 얼마나 많은 새로운 채널이 생성될 수 있는지 알아내는 것입니다 [4] . 탭루트 출력을 생성하는 데 드는 한계 비용은 $43vB$입니다. 채널 생성을 분할 상환할 수 있는 경우, 즉 한 트랜잭션에서 많은 채널을 열 수 있는 경우 다른 트랜잭션 오버헤드가 중요하지 않게 되며 많은 수의 새 채널을 열 수 있습니다. 매년 신규 사용자 수용을 위한 다양한 채널을 오픈합니다. 예를 들어, 블록 공간의 90%가 새로운 탭루트 라이트닝 채널을 여는 데 사용된다고 가정합니다.
$$
52{\small,}560\frac{\mathrm{블록}}{\mathrm{연도}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm {블록}} \times 90% \times 1\frac{\mathrm{채널}}{43\mathrm{vB}} = 1.1,\mathrm{billion}\frac{\mathrm{채널}}{\mathrm{연도 }}
$$
(그 결과 매년 11억 개의 새로운 채널이 개설될 수 있습니다)
전 세계 인구의 절반, 즉 43억 명이 스마트폰을 소유한 것으로 추산된다. 따라서 실제로 매년 우리는 라이트닝 네트워크를 잠재적으로 사용할 수 있는 인구의 상당 부분을 라이트닝 네트워크에 온보딩할 수 있습니다.
하지만 채널이 영원히 닫혀 있는 것은 아닙니다. 때때로 사용자는 지갑 전환, 채널 용량 증가 또는 감소 등을 원합니다. 채널 용량을 변경하는 가장 효율적인 방법은 " 채널 스플라이싱 ", 특히 Phoenix Wallet 구현입니다.
채널 열기와 마찬가지로 채널 접합도 효율성을 높이기 위해 분할 상환될 수 있습니다. 여러 접합 작업은 트랜잭션을 공유하여 자금을 추가하고 제거하는 데 필요한 입력 및 출력 수를 줄일 수 있습니다 [5] . 따라서 사용자가 musig 를 사용한다고 가정할 때 각 사용자의 접합 작업에 필요한 증분 블록 공간은 탭루트 출력의 $43vB$와 탭루트 키 경로에 소비된 감시 데이터의 $57.5vB$를 더해 총 $100.5vB$입니다. 블록 공간의 90%가 이 목적으로 사용된다고 다시 가정하면 다음과 같습니다.
$$
52{\small,}560\frac{\mathrm{블록}}{\mathrm{연도}} \times 1{\small,}000{\small,}000\frac{\mathrm{vB}}{\mathrm {블록}} \times 90% \times 1\frac{\mathrm{스플라이스}}{100.5\mathrm{vB}} = 470,\mathrm{백만}\frac{\mathrm{스플라이스}}{\mathrm{연도 }}
$$
(결과적으로 연간 4억 7천만 채널 스플라이스)
마지막으로, 지갑 간 라이트닝 채널 전환은 새 지갑을 신뢰하고 자금이 약속 주소로 전송된 후 약속 거래에 서명하거나 기존 지갑과 새 지갑 간 전환을 통해 한 번의 거래로 수행될 수 있습니다. 협력적인 "새로운 채널 폐쇄 및 개방".
물론 라이트닝 채널 외부의 블록 공간을 두고 경쟁하는 다른 비트코인 사용 사례도 있을 것이며 이것이 수수료로 어떻게 해석될지는 알기 어렵습니다. 그러나 이 수치는 대략적인 추정치를 제공하며, 이는 현재 기술을 사용하면 적어도 기술적으로 수억 명의 자기 관리형 Lightning Network 사용자를 지원할 수 있음을 나타냅니다.
3 L2 개요
L2 정의에 따라 비트코인 개발자 커뮤니티에서 논의한 두 가지 디자인 패턴이 있습니다.
- 통로
- 가상 UTXO
라이트닝 채널이 대표적인 예인 채널 모델에서는 참여자가 채굴 할 수 있는 사전 서명된 트랜잭션을 교환함으로써 상태 발전이 달성됩니다(그러나 "행복한" 결말을 나타내지는 않음). 이러한 사전 서명된 거래는 참여자 간에 UTXO의 가치를 분할합니다. 경제적 거래는 분할 결과를 변경하기 위해 새로운 사전 서명된 거래를 반복적으로 사용하여 수행됩니다. 동일한 UTXO를 사용하는 유효한 거래가 많이 있기 때문에 올바른 거래만 실제로 블록에 의해 확인되도록 보장하는 인센티브 메커니즘이 필요합니다.
"가상 UTXO(V-UTXO)" 디자인 패턴에서 Ark는 가장 중요한 예입니다. V-UTXO는 여러 당사자 간의 제한적인 조건 또는 계약을 통해 생성되며, 이를 통해 가치를 나타내는 트랜잭션이 모든 당사자를 통합 할 수 있습니다. -UTXO는 체인에서 실제 UTXO가 되지만, 그러한 거래가 "행복한" 결말을 의미하지는 않습니다. 이러한 관점에서 보면 V-UTXO도 채널과 유사합니다. 그러나 채널과 달리 V-UTXO 방식은 (개념적으로) 사전 서명 된 단일 트랜잭션인 V-UTXO 자체를 사용하여 트랜잭션을 구현합니다.
"모두가 좋아하는" 디자인 패턴은 N-of-N 다중 서명 설치와 같이 "모든 참가자가 동의하는" 스크립트 경로를 사용하는 것입니다. ) N-of-N 다중 서명 장치가 됩니다. 모든 참가자가 동의한다고 가정하면 이 경로를 통해 자금을 효율적으로(그리고 비공개적으로) 사용할 수 있습니다.
흥미롭게도 가상 UTXO는 여러 면에서 "실제"이기 때문에 채굴 시 가상 UTXO를 사용하여 채널에 필요한 UTXO를 생성함으로써 가상 UTXO에 채널을 설정하는 것이 매우 쉽습니다. 이런 의미에서 가상 UTXO는 채널보다 약간 낮은 수준입니다.
3.1 라이트닝 네트워크
지금까지 프로덕션 환경에 구현된 라이트닝 네트워크는 주로 BOLT 표준을 기반으로 했습니다. 라이트닝 네트워크는 라이트닝 채널 및 HTLC, P2P 라우팅 네트워크, 어니언 라우팅, 송장 발행 표준 등을 포함한 기술의 조합입니다. 중요한 것은 라이트닝 네트워크 는 공개 시스템이 아니기 때문에 "라이트닝 시스템"의 다양한 모듈을 모든 사용자가 정확히 동일한 방식으로 채택할 필요는 없다는 것입니다. 이 문서의 목적에 따라 "라이트닝 네트워크"라고 하면 널리 사용되는 기존(일반적) 라이트닝 네트워크 프로토콜에 대한 쉽게 예측 가능한 업그레이드를 포함하도록 광범위하게 사용됩니다.
앞서 언급했듯이 라이트닝 네트워크의 주요 기능은 각 사용자에게 최소한 하나의 UTXO가 필요하다는 요구 사항으로 인해 발생하는 최종 사용자 확장성 제한입니다. 즉, 라이트닝 네트워크의 "핵심" 라우팅 모듈(공용 트랜잭션 전달 Lightning 노드)의 경우 라우팅 노드보다 최종 사용자가 더 많은 한 이러한 확장성 제한은 문제가 되지 않습니다. 라이트닝 네트워크는 잘 작동할 수 있으며, 사용자 지불 전달을 위한 각 공개 채널은 많은 양의 거래를 즉각적으로 쉽게 처리할 수 있습니다. 새로 제안된 다수의 L2 시스템이 라이트닝 네트워크에 참여할 것으로 예상되는 이유다. 또한 Cashu와 같이 L2 표준을 준수하지 않는 기존 시스템이 진정으로 유용해지기 위해서는 Lightning Network에 크게 의존해야 함을 관찰할 수 있습니다. Cashu의 주요 용도는 Lightning 결제를 보내고 받는 것일 수 있습니다.
3.1.1 비대화형 채널
이 구성은 OP_CTV 사용하여 상호 작용 요구 사항을 줄이고 번개 채널을 최적화합니다. 그러나 "사용자당 하나의 UTXO" 확장성 제한을 최적화하지 않으므로 더 이상 논의하지 않습니다.
3.2 채널 팩토리
이 구조에서는 여러 당사자가 n개의 다중 서명 주소를 입력하도록 조정할 수 있으며, 일치하는 사전 서명된 거래는 이 다중 서명 주소를 사용하고 n개의 다른 UTXO를 생성하여 자금을 분할합니다. 이 n개의 UTXO 각각은 결제 채널로 사용됩니다. 이러한 채널의 보안은 채널 상태를 체인에 게시해야 할 때 자금을 분할하는 거래가 채굴될 수 있기 때문에 체인에서 직접 여는 것과 동일합니다. 이론적으로 $n$ 참가자가 협력하여 모든 $n$ 채널을 한 번에 닫을 수 있기 때문에 채널이 닫힐 때 체인의 공간을 절약할 수 있습니다.
채널 팩토리는 채굴이 가능 하지만 실제로 해피엔딩에서는 채굴될 것으로 예상되지 않는 조정된 UTXO이기 때문에 V-UTXO의 매우 원시적인 예입니다.
채널 팩터리 구현에는 소프트 포크가 필요하지 않습니다. 그러나 위에서 설명한 간단한 채널 팩토리는 참가자가 약간 더 많아지면 실용적이지 않을 수 있습니다. 확장의 이점을 실제로 실현하려면 사용자 협력이 필요하기 때문입니다. 따라서 OP_Evict 또는 CTV(txout 트리를 통해)와 같은 제약 제안이 도움이 될 수 있으며, 보다 세부적인 결과를 게시할 수 있습니다. 모든 사람이 동시에 체인에 있도록 강요하지 않고 단일 당사자를 체인으로 배출할 수 있습니다.
3.3 엘투/LN-대칭
Eltto는 나쁘고 혼란스러운 이름이므로 아래에서는 업데이트된 이름인 "LN-Symmetry"를 사용하겠습니다.
Poon-Dryja 채널은 잘못된 상태 게시를 처벌하여 올바른 상태 게시를 장려하는 반면, LN-Symmetry는 그 반대이며 추가 트랜잭션을 통해 잘못된 상태가 업데이트되도록 허용합니다. 페널티의 복잡성을 제거해 라이트닝패스를 단순화한다는 장점이 있다. 그러나 이를 억제하려면 처벌이 필요하기 때문에 신뢰할 수 없는 환경에서는 단점이 있을 수도 있습니다.
LN-Symmetry에서는 새로운 상태 트랜잭션이 이전 상태 트랜잭션을 다시 사용할 수 있도록 SIGHASH_ANYPREVOUT을 활성화하는 소프트 포크가 필요합니다.
LN-Symmetry는 자체적으로 기존 Lightning 채널에 확장 성능 향상을 제공하지 않습니다. 그러나 후원자들은 접근 플랜트를 구현하기가 더 쉬워질 것이라고 주장합니다 .
3.4 방주
Ark는 트랜잭션 확장을 달성하기 위해 완전히 전송 가능한 가상 UTXO(V-UTXO)라는 새로운 방법을 채택합니다. 이러한 가상 UTXO는 원자적 [7] 오프체인 트랜잭션으로 병합 및 분할될 수 있습니다. Ark에서는 중앙 코디네이터인 "Ark Service Provider(ASP)"가 사용자에게 정해진 시간 제한(예: 4주)으로 V-UTXO를 제공합니다. 이러한 주기를 ' 라운드 '라고 합니다. 이러한 V-UTXO는 자본 풀 거래 출력을 통해 생성되며, 일부 메커니즘(예: CTV)을 통해 단일 온체인 거래 출력이 V-UTXO 트리에 커밋될 수 있습니다. 라운드 만료 메커니즘은 Ark의 확장성 이점의 핵심입니다. 라운드가 끝나면 풀 트랜잭션의 출력이 잠금 해제되어 ASP가 소규모 트랜잭션에서 단일 서명으로 일방적으로 이를 사용할 수 있습니다. 라운드에는 만료 시간이 있기 때문에 자본 풀 거래 출력에 의해 생성된 V-UTXO에도 만료 시간이 있습니다. V-UTXO를 보유한 사용자는 해당 풀 거래 출력이 만료되기 전에 이 V-UTXO를 사용하거나 다음 대상에 게시되어야 합니다. 체인(일방적인 철수).
V-UTXO를 전송하기 위해 Ark 코디네이터는 하나 이상의 V-UTXO가 필요한 트랜잭션에 공동 서명하고, 다른 라운드에서 하나 이상의 다른 V-UTXO가 생성되는 경우에만 트랜잭션을 유효하게 만듭니다. 세심하게 설계된 시간 제한과 결합됩니다. 자세한 내용은 Ark의 문서를 참조하세요. 이러한 종속성은 V-UTXO 지출을 신뢰할 수 없게 만드는 이유입니다. 다른 풀 트랜잭션에서 새 V-UTXO가 생성되지 않는 한, 기존 V-UTXO를 체인에서 제거할 수 없습니다. (풀 트랜잭션 출력이 소비됨에 따라) 이 종속성을 구현하는 몇 가지 방법이 있습니다. 그러나 정확한 세부 사항은 이 기사의 목적과 관련이 없습니다.
이는 ASP가 여러 활성 라운드에서 동시에 작동한다는 것을 의미합니다. 기존 라운드의 자금을 이체할 수 있도록 새로운 라운드가 자주 생성됩니다. 그러나 기존 라운드는 일반적으로 새 라운드(새 풀 트랜잭션)가 생성된 후에 만료되므로 새 라운드와 겹칩니다.
3.4.1 Ark의 경제 모델
V-UTXO가 소비되면 ASP는 새 라운드를 나타내는 풀 트랜잭션 출력에 일치하는 BTC를 제공해야 합니다. 그러나 현재 라운드가 끝날 때까지 소비된 V-UTXO의 가치를 사용할 수 없습니다. 따라서 V-UTXO 지출에는 ASP가 자금을 선지급해야 하기 때문에 돈의 시간 가치라는 비용이 발생합니다.
정확하게 말하면 V-UTXO를 소비할 때 이 비용이 발생합니다. V-UTXO가 사용되지 않으면 사용자가 자신의 자금을 통제하기 위해 일방적으로 자금을 인출하기 위해 체인에 게시될 수 있는 매우 실제적인 잠재적인 UTXO를 나타냅니다. 그러나 이 V-UTXO를 사용하려면 ASP는 다른 곳에서 ASP가 얻은 자금을 사용하여 새로운 풀 거래 출력을 생성해야 하며, 사용된 V-UTXO의 자금은 이 ASP에서 사용되는 라운드가 만료될 때까지 사용할 수 없습니다.
따라서 V-UTXO를 사용하려면 지금부터 라운드 만료까지의 시간을 충당하기 위한 단기 대출이 필요합니다. 이는 V-UTXO가 오래됨에 따라(점차적으로 라운드 만료 시간에 가까워짐) 하나의 V-UTXO를 소비하는 유동성 비용이 이론적으로 점차 감소하고 결국 0에 가까워진다는 것을 의미합니다(즉, 라운드가 끝날 때). 만료 시).
마지막으로, V-UTXO 지출 비용은 수령인에게 전달된 금액 이 아니라 지출된 V-UTXO의 총 크기와 관련이 있다는 점을 기억하세요. 이는 여러 V-UTXO를 직접 전송하는 데 관심이 있는 지갑(예: V-UTXO 기반 라이트닝 채널에 대해 하나의 V-UTXO를 관리하는 지갑과 달리)이 절충을 해야 함을 의미합니다. 펀드 V-UTXO는 몇 개 있나요? V-UTXO를 하나만 유지하면 일방적 인출 비용을 최대한 줄일 수 있지만 유동성에 따라 거래 수수료가 극대화됩니다. 이는 온체인 비트코인 및 라이트닝 거래의 경제 모델과 완전히 다릅니다.
유동성 비용이란 무엇입니까? 이 글을 쓰는 시점에서 Lightning Network 지갑 Phoenix는 1년 동안 지속되는 채널 유동성에 대해 1%의 수수료를 부과합니다. 최악의 경우 Phoenix는 1년 동안 자금을 묶어야 합니다. 그러나 이 유동성은 사용되지 않는다고 가정한다. Phoenix의 경우 실제로 자금 조달 비용이 연간 1%보다 높을 가능성이 있지만 평균 고객이 1년 이내에 이 장부 유동성을 모두 소진할 것이라고 가정합니다. Phoenix는 또한 거래 수수료로 수익을 창출하므로 채널 유동성에도 보조금을 지급합니다. 마지막으로 피닉스가 돈을 벌지 못할 가능성이 있습니다!
미국 재무부 채권 수익률은 우리에게 또 다른 추정치를 제공할 수 있습니다. 이 글을 쓰는 시점에서 3개월 국채 수익률은 연평균 약 5%입니다. 미국 달러의 인플레이션으로 인해 이 수익률이 물렁해지기 때문에 분석 목적으로 BTC 기반 펀드의 유동성 비용을 연간 3%로 가정합니다.
라운드가 4주 동안 진행된다면 거래의 유동성 비용은 $3% / \frac{52}{4} = 0.23%$부터 시작하여 점차 0으로 감소합니다. 현재 라운드가 만료되기 2주 전에 사용자가 자금을 이동한다고 가정하면, 자금의 자율적 보관을 달성하기 위해 지불해야 하는 유동성 비용은 연간 약 1.5%입니다. 반면에 사용자가 마지막 순간까지 기다린다면 [8] , 이 유동성 비용은 0에 가까워지고 만료 시간을 놓칠 위험이 있습니다.
사용자들은 이것이 저렴하다고 생각하지 않을 수도 있습니다. 게다가, 이 가격은 각 라운드의 비용이 고정되어 있고, 거래 수수료 및 기타 비용은 이미 많은 수의 참가자를 통해 상각되어 있어 미미하다고 가정합니다.
그런데 이 고정비용이 적지 않다면 어떻게 될까요? ASP에 1000명의 사용자가 있고 평균적으로 매 시간마다 하나의 풀 트랜잭션을 생성한다고 가정합니다. 4주 안에 672개의 온체인 거래가 이루어질 것입니다. 이는 자금을 유지하기 위해 이 ASP 사용자 전체가 거의 사용자 수만큼의 거래에 대해 수수료를 지불해야 함을 의미합니다! 자신의 라이트닝 채널을 여는 것이 더 저렴할 수 있으며 ASP는 거래를 확인하기 위해 한 시간을 기다리게 합니다.
3.4.2 콜드 스타트 아크
소수의 사용자만 있는 새로운 ASP는 딜레마에 직면하게 됩니다. ASP 라운드가 덜 자주 발생하므로 사용자는 해당 라운드가 유용한 기능을 달성하기 위해 충분한 V-UTXO를 수집할 때까지 오랫동안 기다려야 합니다. 확장성은 거래 수수료 절감에 달려 있습니다. 또는 ASP의 풀 트랜잭션이 자주 발생하므로 각 사용자는 더 높은 트랜잭션 수수료를 지불해야 합니다. 이전 섹션에서 논의한 것처럼 자주 발생하는 라운드와 해당 풀 트랜잭션을 상각하려면 많은 수의 사용자가 필요할 수 있습니다.
이 문제는 만료 시간의 존재로 인해 라이트닝 채널이 직면한 문제보다 훨씬 더 심각합니다. 적어도 라이트닝 채널은 무기한으로 유용할 수 있으며 채널이 열린 후에는 향후 몇 달에 걸쳐 점차적으로 상각될 수 있습니다. 둘째, 라운드가 만료되기 때문에 이러한 라운드를 지원하기 위해 거래 출력을 생성하는 시점 에 유연성이 없습니다. 높은 수수료 상황이 1~2주 동안 지속되면 만료되는 풀 거래 출력의 사용자는 높은 수수료만 지불할 수 없습니다. (총체적으로) 자금의 관리를 유지합니다. 라이트닝 채널에서는 채널을 여는 시점이 훨씬 더 유연해집니다.
Ark의 작성자는 처음에는 매우 낙관적이었고 새로운 라운드를 생성하는 데 몇 초 밖에 걸리지 않을 것이라고 믿었지만, 거래 수수료를 보조할 수 없다면 거래가 확인될 때까지 몇 시간을 기다릴 수 있는 경우에만 Ark의 초기 출시가 발생할 수 있습니다. 응용 시나리오.
3.4.3 상호작용성
비수탁 Akr은 상호 작용 요구 사항이 높은 프로토콜입니다. V-UTXO가 만료되기 때문에 만료되기 전에 ASP와 상호 작용해야 합니다. 그렇지 않으면 ASP가 자금을 빼앗을 수 있습니다. 이 상호 작용 요구 사항은 아웃소싱할 수도 없습니다. 대조적으로, 라이트닝 채널에는 적들이 당신을 속이려는 시도를 저지하는 " 감시탑 "이 있습니다. 노드가 오프라인이고 Ark V-UTXO 보유자가 당신을 속이는 것을 피하려고 하는 경우에도 신뢰를 사용해야 합니다. 자금을 새로 고치기 위한 자체 개인 키. 아크에서 워치타워에 가장 가까운 것은 워치타워가 만료되기 전에 일방적으로 자금을 인출할 수 있도록 하는 서명 거래이며, 이는 높은 거래 수수료를 수반합니다.
펀드 소유자가 오프라인 상태가 되면 V-UTXO에 어떤 일이 발생하는지 생각해 보세요. 라운드가 만료된 후 ASP는 향후 라운드의 유동성 요구를 충족하기 위해 자금을 회수해야 합니다. V-UTXO 보유자가 오프라인 상태가 되면 ASP가 다층 V-UTXO 트리에서 자금을 인출해야 하기 때문에 V-UTXO를 체인에 게시하면 높은 거래 비용에 직면하게 됩니다. ASP는 새로운 라운드에서 사용되지 않은 V-UTXO를 다시 생성할 수 있지만, 이는 새로운 라운드에서 사용되지 않은 V-UTXO를 생성할 수 없기 때문에 V-UTXO 보유자의 관점에서 볼 때 무신뢰가 아닙니다 .[9] 이러한 V-UTXO를 다음에 사용합니다. 전제. ASP는 사용되지 않은 V-UTXO를 에스크로 잔액으로 직접 기록할 수도 있습니다. 자금 몰수 조항도 있을 수 있습니다!
내 개인적인 의견은 Ark의 자율 보관 비용이 저렴하지 않다는 점을 고려하면 많은 사용자가 대신 자동으로 새로운 라운드에 자금을 투입할 수 있는 ASP를 선택하여 각 라운드가 끝날 때 사기 위험을 직접 감수한다는 것입니다. 이는 자금을 안전하게 유지하기 위한 예방적 이체보다 저렴합니다. (예: 제때에 전화를 켜지 않거나 지갑을 제어하지 못해 자금이 이체되지 않습니다.)
3.4.4 더욱 발전된 아크
일반적인 시나리오가 모든 유동성이 한 라운드에 소진되는 경우 Ark의 유동성 요구를 줄이기 위해 보다 진보된 제약 조건을 사용하는 것이 타당할 수 있습니다. 예를 들어, 트랜잭션 풀의 출력에 있는 모든 V-UTXO 총 가치의 50%가 소비된다고 가정해 보겠습니다. ASP가 거래 풀 출력의 일부만 재활용할 수 있다면 자금을 더 빠르게 재활용하고 전반적인 유동성 비용을 줄일 수 있습니다. 아직 구체적인 제안이 공개된 것은 아니지만, 고급 TM 제한이 충분하다면 달성할 수 있을 것으로 보인다. 아마도 여러 개의 유용한 opcode를 한 번에 추가하는 일종의 "스크립트 부활" 소프트 포크를 통해서일 것입니다.
마찬가지로 충분히 발전된 TM 제한 조항을 사용하면 전체 거래 출력 트리 구조를 일종의 롤링 인출 방식으로 대체하여 공간을 절약할 수 있습니다. 이 기술은 다른 시나리오에도 유용할 수 있으므로 다음 섹션에서 이 주제에 대해 논의하겠습니다.
라운드가 끝날 때 안전하게 보관하는 문제는 완전히 발전된 TM 제약 조건이 해결할 수 있는 또 다른 문제입니다. 제약 조건, 특히 영지식 증명(ZK 증명) 제약 조건을 확인할 수 있는 제약 조건은 ASP가 해당 라운드에 다시 들어가도록 강제할 수 있습니다. 다음 라운드에서 ASP에 제공되는 양육권 문제를 제거하기 위해 사용되지 않은 모든 제한 사항을 만듭니다. 비록 이것이 무 신뢰로 만들기에는 충분하지 않을 수 있지만 사용자는 새로운 라운드에서 자신의 V-UTXO를 사용하기 위해 여전히 ASP의 일부 데이터가 필요할 수 있으므로 ASP가 오프라인 사용자를 속이는 것을 방지할 수 있습니다.
3.4.5 일방적 출금 시 온체인 처리 수수료 지급
라이트닝 채널과 유사하게, 온체인 처리 수수료 지불의 경제 원리와 처리 수수료 지불 후 V-UTXO의 실제 가치에 따라 Ark의 사용이 L2 정의를 준수하는지 여부가 결정됩니다(일방적으로 인출 가능, ASP가 허용되지 않음). 사기로 인한 이익). 이에 대해서는 아래에서 트랜잭션 출력 트리 디자인 패턴을 논의할 때 더 자세히 논의합니다.
3.5 유효성 롤업
규칙을 시행하기 위해 어떤 형태의 영지식 증명 기술을 사용하기 위해 사이드체인과 유사한 광범위한 구조가 일반적으로 제안됩니다. 이러한 영지식 증명 기술은 "유효성 롤업"과 다른 형태의 사이드체인 간의 주요 차이점입니다. 관련 영지식 증명 체계가 작동할 수 있다면 거래의 유효성은 제3자를 신뢰할 필요 없이 수학으로 보장됩니다. 파티. 이 사용법에서는 영지식 증명의 "영지식" 특성이 필요하지 않습니다. 증명이 증명하려는 내용에 대한 정보를 "공개"하더라도 완벽하게 괜찮습니다. 이러한 수학적 체계의 대부분은 영지식 증명 체계인 경우가 많습니다.
비트코인 관점에서 볼 때 유효성 롤업 체계에는 제약이 필요합니다. 왜냐하면 우리는 체계의 규칙을 따를 때만 사용할 수 있는 그러한 체계에 대한 UTXO를 생성할 수 있기를 원하기 때문입니다. 이것이 반드시 분산형 시스템일 필요는 없습니다. 많은 효과적인 롤업 계획은 실제로 완전히 중앙 집중화되어 있습니다. 롤업 증거는 중앙 집중식 트랜잭션 주문자가 주문된 트랜잭션 집합에 규칙을 적용했음을 증명하는 데에만 사용됩니다.
어떤 제약을 사용하느냐에 대해서는... 영지식증명 기술은 아직은 아주 새로운 분야이고 발전이 이뤄지는 경우가 많습니다. 따라서 특정 종류의 영지식 증명을 직접 확인하는 opcode가 비트코인에 추가되는 것을 볼 가능성은 거의 없습니다. 대신, 특정 솔루션은 스크립트의 영지식 증명을 확인하기 위해 보다 일반적인 opcode(특히 OP_CAT )를 사용하는 것이 일반적으로 받아들여집니다. 예를 들어 StarkWare는 OP_CAT 채택하기 위해 노력하고 있습니다.
효율성 롤업은 품질이 낮거나 과장된 프로젝트가 많은 매우 큰 분야입니다. 이러한 유형의 설계를 실현하기 위해 어떤 opcode가 필요할 수 있는지 지적하는 것 외에는 이에 대해 더 이상 논의하지 않을 것입니다.
3.6 비트VM
아주 대략적으로 말하면, BitVM은 두 참가자 사이에 라이트닝 채널을 구축하여 라이트닝 채널의 규칙이 영지식 증거로 시행될 수 있도록 하는 방법입니다. 오늘날의 비트코인에서는 제한적인 조건 없이 구현할 수 있고, "사용자당 1 UTXO"보다 확장성이 뛰어난 L2 시스템을 만드는 데 직접 사용할 수 없기 때문에 더 이상 논의하지 않겠습니다.
3.7 계층적 채널
계층적 채널 [10] 은 채널 용량 조정(크기 조정)을 더 빠르고 저렴하게 만들기 위해 노력하고 있습니다. "계층적 채널은 비트코인의 라이트닝 채널과 같은 채널 용량을 의미합니다." 그러나 기본적으로 여전히 UTXO 1개를 초과할 수 없습니다. 사용자당. 또한 비트코인 프로토콜을 변경할 필요도 없습니다. 그래서 우리는 더 이상 논의하지 않을 것입니다. 계층적 채널을 지지하는 사람들은 이를 구현해야 합니다! 이는 우리의 허가가 필요하지 않습니다.
3.8 코인풀
코인풀을 사용하면 여러 사용자가 UTXO를 공유하고, 사용자 간에 자금을 이체할 수 있으며, 사용자는 모두 일방적으로 돈을 인출할 수 있습니다. CoinPool의 서면 제안에서는 세 가지 새로운 소프트 포크 기능을 요구합니다. SIGHASH_ANYPREVOUT , 특정 UTXO에만 서명을 적용할 수 있는 SIGHASH_GROUP , 특정 분기가 Merkle 트리에서 제거되었는지 확인하는 OP_MerkleSub 또는 OP_CAT 사용하여 수행할 수도 있습니다. 이것을 달성하십시오.
현재 CoinPool 개발은 다소 정체된 것으로 보이며 사양을 설명하는 웹페이지의 마지막 업데이트는 2년 전입니다.
3.9 에니그마 네트워크
Enigma Network에 대해 논의해 달라는 요청을 받았지만 이 제안이 실제로 어떤 모습인지에 대한 문서는 없는 것 같습니다. Bitfinex의 블로그 게시물은 일련의 슬로건을 제공했습니다. MIT의 페이지는 비어 있었습니다. 이 블로그 게시물에서는 실제 구성을 실제로 설명하지 않으므로 더 이상 논의하지 않습니다.
4 트레이딩 풀에 대한 고려 사항
Bitcoin Core의 현재 트랜잭션 풀 전략은 L2 시스템에 적합하지 않습니다. 여기서는 가능한 최적화뿐만 아니라 직면한 몇 가지 주요 과제에 대해 설명합니다.
4.1 거래 십자가형
결국 경제적 폭발이었다. "거래 고정 공격"은 충돌하는 다른 거래가 선점되고 채굴 되지 않기 때문에 누군가가 의도적으로( 또는 의도치 않게 ) 대상 거래를 채굴하기 어렵게 만들 수 있는 다양한 상황을 의미합니다. 실제 거래 페그 시나리오에서 대상 거래는 일단 채굴되면 이익을 얻을 수 있는 거래이고, 충돌하는 거래는 오랫동안(아마도 영원히) 사용할 수 없기 때문에 이는 경제적 폭발입니다.
십자가형 공격의 가장 간단한 예는 "전체 RBF"(즉, 노드가 기본적으로 모든 트랜잭션을 교체할 수 있도록 설정)가 없으면 트랜잭션 교체 기능을 끌 수 있다는 사실에서 비롯됩니다. 그러면 우리는 낮은 수수료와 대체 기능을 끈 상태에서 거래를 시작할 수 있으므로 채굴되거나 대체되지 않습니다. 기본적으로 모든 블록 생산자는 전체 RBF를 켜서 이 문제를 해결했으며, 이 글을 쓰는 시점에서 다음 버전의 Bitcoin Core에서는 기본적으로 전체 RBF를 켜야 합니다( 11년 후!). .
이로 인해 BIP-125 규칙 #3과 관련된 십자가형 공격이 다자간 L2 프로토콜과 관련된 유일한 남은 십자가형 공격이 됩니다(비트코인 코어에서는 아직 해결되지 않았습니다). 여기에서 BIP-125 규칙 #3을 인용합니다.
교체 거래에는 교체된 모든 거래소가 지불한 수수료 총액보다 더 높은 절대 수수료(단순 수수료가 아님)가 필요합니다.
이 규칙은 활용될 수 있습니다. 대규모이지만 수수료가 낮은 고정된 거래(또는 그 그룹)가 브로드캐스트되어 다자간 계약과 관련된 출력을 소비할 수 있습니다. 거래 수수료가 너무 낮기 때문에 조만간 채굴되지는 않을 것입니다(아마도 결코 채굴되지 않을 것입니다). 그러나 수수료 금액이 높기 때문에 다른 거래로 대체하는 것은 비경제적입니다.
BIP-125 규칙 #3과 관련된 십자가형 공격은 "RBFR( Replacement of Fee Rates )"에서 쉽게 해결 가능하며 모든 경우에 해결 가능합니다. 안타깝게도 RBFR이 " TRUC/V3 트랜잭션 "( 중국어 번역 )이라는 열악하고 불완전한 솔루션에 많은 시간을 소비했기 때문에 비트코인 코어가 조만간 채택할지 여부는 불분명합니다.
4.2 수수료 지불방법
RBF, CPFP, SIGHASH_ANYONECANPAY , 앵커 출력 및 수수료 자금 조달
처리 수수료는 예측할 수 없기 때문에 거래가 사전 서명된 경우 안정적이고 경제적인 처리 수수료를 달성하기가 매우 어렵습니다. 수수료 지불에 대한 표준은 "저평가된" 가치에서 시작하여 거래가 채굴될 때까지 점차적으로 더 높은 수수료 버전으로 대체하는 RBF(수수료 대체)를 사용하는 것입니다. 예를 들어 OpenTimestamps 캘린더 소프트웨어는 수년 동안 이 접근 방식을 사용해 왔으며 LND는 v0.18에서 " 만료 날짜를 염두에 둔 RBF "도 지원합니다.
RBF는 거의 모든 [11] 시나리오에서 블록 공간에서 가장 효율적이기 때문에 최고의 표준입니다. 처음부터 올바른 수수료를 추측하는 트랜잭션에 비해 교체 트랜잭션에는 추가 입력 또는 출력이 필요하지 않습니다.
수수료 지급의 비효율성은 블랙박스 수수료 지급을 대형 채굴자들의 수익원으로 전환시키기 때문에 효율성이 중요한 반면, 소규모 채굴자들은 지급을 받기 때문에 소규모 분산형 채굴자들은 이익을 얻을 수 없게 됩니다. 거래 확인을 기대하는 것은 비현실적입니다. 그리고 쓸모가 없습니다. 프로토콜 외부 결제는 AML/KYC 문제를 일으킬 수도 있습니다. 현재 대부분의 프로토콜 외부 수수료 결제 시스템에는 어떤 형태로든 AML/KYC 프로세스가 필요합니다. 한 가지 주목할만한 예외는 이 글을 쓰는 시점에서 mempool.space 가속기 입니다. 2024년 8월부터 라이트닝 결제가 가능해지며, 계좌가 필요하지 않습니다.
사전 서명된 거래의 맥락에서 RBF를 직접 사용하려면 가능한 모든 수수료 범위를 포괄하기 위해 서로 다른 수수료를 지닌 동일한 거래의 변형에 사전 서명해야 합니다. 이는 필요한 변형 수가 종종 적기 때문에 많은 시나리오에서 상당히 실현 가능하지만 [12] 현재 프로덕션 중인 라이트닝 네트워크 프로토콜과 기타 제안된 프로토콜은 대신 "CPFP( Son for Father )"를 선택했습니다. , 일반적으로 "앵커 출력"을 통해.
앵커 출력의 기본 개념은 하나 이상의 작은(또는 값이 0인) 출력을 트랜잭션에 추가하여 하위 트랜잭션이 수수료(예: CPFP)를 추가할 때 이러한 출력을 사용할 수 있도록 하는 것입니다. 이는 소규모 온체인 트랜잭션을 사용하는 라이트닝 채널과 같은 프로토콜에 적용하면 당연히 매우 비효율적이므로 임시 앵커 출력을 사용하여 커밋된 트랜잭션의 총량이 거의 두 배로 늘어납니다 . OP_CAT 사용하여 제한 조항을 구현하는 등 더 큰 트랜잭션 볼륨을 사용하는 프로토콜에 적용하면 문제가 덜 발생합니다.
앵커 출력의 덜 분명한 문제는 수수료를 지불하기 위해 추가 UTXO(하위 거래에 사용됨)를 보유해야 한다는 것입니다. 표준 "클라이언트" 애플리케이션에서는 앵커 출력을 사용하지 않을 때 일반적으로 둘 이상의 UTXO를 저장할 필요가 없기 때문에 이는 상당한 오버헤드 부담이 될 수 있습니다. 실제로 일부 기존 소비자 대상 라이트닝 지갑에서는 높은 수수료 환경에서 수수료를 지불할 수 없기 때문에 채널 공격자(및 자금 도난)에 취약해질 수 있습니다.
SIGHASH_ANYONECANPAY 특정 상황에서 처리 수수료를 지불하는 데 사용할 수 있습니다. SIGHASH_SINGLE 사용하면 출력을 추가할 수 있습니다. 라이트닝 네트워크 프로토콜은 HTLC 트랜잭션에서 이를 사용합니다. 현재 주의 깊게 처리하지 않으면 [13] 공격자가 많은 입력 및/또는 출력을 추가하여 높은 수수료/낮은 수수료가 고정된 트랜잭션을 생성할 수 있으므로 이 사용법은 페깅 공격에 취약합니다. RBFR은 이 문제를 해결하지만 TRUC/V3 트랜잭션에 사용되는 방법은 그렇지 않습니다. 이 수수료 지불 방법은 RBF만큼 효율적이지는 않지만 앵커 출력보다 더 효율적일 수 있습니다.
마지막으로, 비트코인 프로토콜에 수수료 자금 조달 시스템을 추가하자고 제안하는 소프트포크가 많이 있습니다. 이를 통해 트랜잭션은 다른 트랜잭션에 대한 종속성을 선언할 수 있으므로 자금 조달 트랜잭션은 자금 조달 트랜잭션이 채굴될 때만(대부분 동일한 블록에서) 채굴될 수 있습니다. 이는 자금 거래가 거래 입력보다 훨씬 적은 바이트를 사용하여 이러한 종속성을 선언할 수 있기 때문에 기존 CPFP보다 훨씬 더 효율적일 수 있습니다.
4.3 대체 트랜잭션 루프 공격
"대체 트랜잭션 루프 공격" [14] 은 덜 좋은 트랜잭션을 마이닝할 수 있을 만큼 충분히 긴 대체 트랜잭션으로 대상 L2 트랜잭션을 차단하려고 시도합니다. 본질적으로 공격자에게 대체 트랜잭션 루프 공격은 트랜잭션 고정 공격의 대안입니다. 공격자의 의도는 훌륭하고 정직한 트랜잭션이 충분히 오랫동안 채굴되는 것을 방지하는 것이기 때문입니다. 이를 통해 덜 가치 있고 부정직한 트랜잭션을 파헤칠 수 있습니다. . 차이점은 대체 트랜잭션 루프 공격이 실수로 발생할 수 없다는 것입니다.
일반적인 예는 라이트닝 채널의 HTLC 거래입니다. HTLC를 계약이라고 생각할 수도 있지만, 트랜잭션이 원본 이미지를 공개하여 이를 소비 하거나 시간 초과가 발생합니다. 그러나 실제로는 비트코인 스크립트의 한계로 인해 원본 이미지를 공개하여 사용할 수 있는 기회가 항상 존재합니다. 시간 초과 후에는 추가 시간 초과 소비 메커니즘이 열립니다 .
대체 트랜잭션 루프 공격은 이를 이용하여 타임아웃 메커니즘을 통해 가치를 상환하려는 트랜잭션을 대체하기 위해 타임아웃 이후에도 사전 이미지 지출 트랜잭션을 계속 사용하려고 시도합니다. 동시에 피해자에게는 사전 이미지에 대한 정보가 제공되지 않습니다. . 성공적인 대체 트랜잭션 루프 공격은 다른 채널의 HTLC가 시간 초과될 때까지 충분히 오래 지속됩니다.
대체 거래 주기를 통해 이익을 얻는 데 있어 어려움 중 하나는 공격의 각 라운드에 자금이 필요하다는 것입니다. 마감일을 인식하는 Lightning 구현에서는 다음 HTLC 출력이 만료되기 전에 현재 HTLC를 사용(상환)하기 위해 점점 더 높은 수수료를 사용합니다. 둘째, 대체 주기가 끝나면 누구나 대체 트랜잭션을 다시 브로드캐스팅하여 이 공격을 물리칠 수 있습니다 [15] .
십자가형 공격과 마찬가지로 대체 거래 루프도 채굴자에게 경제적 폭발입니다. 각 주기가 끝나면 또 다른 거래가 거래 풀에서 제거됩니다. 하지만 이는 완전히 유효하고 채굴자가 거래 풀에 보관하는 한 채굴이 가능합니다.
5 기능 모드 및 소프트 포크
제한 조항에 의존하는 다양한 L2 시스템과 트랜잭션 풀이 직면한 문제에 대한 개요를 제공했으므로 이제 우리는 일련의 잘 알려진 소프트 포크 기능(주로 새로운 opcode)과 이러한 L2 시스템의 공통 기능을 추출하려고 합니다. . 디자인 패턴. 소프트 포크 제안의 경우 이러한 제안과 관련된 기술적 위험과 배포 문제에 대해서도 논의합니다.
5.1 OP_Expire
먼저 이것을 똑바로 알아봅시다. OP_Expire 대체 트랜잭션 루프 공격을 직접 제거하는 방법으로 제안되었습니다 [16] . 이는 곧바로 루트로 진행됩니다. HTLC는 동시에 두 가지 다른 방식으로 사용될 수 있습니다. L2 시스템의 맥락에서 이는 HTLC 및 유사한 메커니즘을 사용하는 모든 시스템과 관련이 있으며 다른 용도도 가능합니다. OP_Expire 특정 시점 이후에는 거래 출력을 더 이상 사용할 수 없도록 하여 HTLC의 지출 조건이 "프로그래머의 OR"이 아닌 진정한 배타적 OR이 되도록 합니다.
실제 OP_Expire 소프트 포크는 2단계 OP_CheckLockTimeVerify 및 OP_CheckSequenceVerify 와 유사한 두 가지 기능으로 구성될 수 있습니다(번역자 참고 사항: 각각 스크립트 수준에서 절대 시간 잠금 및 상대 시간 잠금).
- 거래의 만료 높이 필드는 탭루트 부록을 통해 구현될 가능성이 높습니다.
- 트랜잭션의 만료 높이가 목표 높이보다 낮지 않은지 확인하는
OP_Expireopcode입니다.
OP_Expire 자체는 제한 조항이 아니지만 제한 조항에 의존하는 많은 L2 시스템에 유용한 것으로 보입니다. 그러나 주어진 대체 트랜잭션 루프는 상호 재방송 [15] 을 통해 완화될 수도 있으며 이는 충분히 유용하지 않을 수 있습니다.
OP_Expire 배포 및 사용에 있어 매우 분명한 과제는 블록체인 재구성입니다. Bitcoin 기술 커뮤니티에서는 원래 실수부터 시작하여 [17] Bitcoin 합의 프로토콜이 다음과 같은 특징을 갖도록 노력해 왔습니다. 재구성하면 이전에 채굴된 트랜잭션도 새 블록에 들어갈 수 있습니다. 이 설계 원칙은 합의 오류로 인해 대규모 재구성이 발생하는 경우 강력하게 확인된 UTXO가 하루아침에 영구적으로 무효화되고 UTXO에 의존하는 사람들이 자금을 잃는 악마적인 시나리오를 피하려고 시도합니다.
대규모 재구성의 경우 위에서 설명한 만료 메커니즘을 사용하는 트랜잭션은 만료 높이에 도달하면 채굴이 불가능해질 수 있습니다. OP_Expire 위의 만료 메커니즘을 사용하는 트랜잭션을 코인베이스 트랜잭션으로 처리하여 해당 출력이 100블록 내에서 소비될 수 없도록 제안하여 이 문제를 완화합니다.
트랜잭션 만료 메커니즘을 배포하는 데 있어 상당한 부담은 합의에 도달하는 것입니다. 이 절충안이 허용됩니까? 그게 필요할까요? OP_Expire 작동할 수 있는 거래에는 사용자 자금을 동결시키는 장기 잠금이 이미 포함되어 있습니다. 더 긴 시간 초과를 추가하는 것은 부적절합니다. 또한, 블록 재구성 후 반복 지출은 항상 특정 UTXO를 무효화할 수 있습니다. RBF의 인기와 "키 없는 앵커 출력"의 출현으로 인해 트랜잭션 시간 초과 메커니즘이 여전히 큰 역할을 하게 될까요?
5.3 SIGHASH_ANYPREVOUT
BIP-118은 두 가지 새로운 서명 해시 모드를 제안하는데, 둘 다 특정 UTXO가 소비되도록 커밋하지 않습니다 . SIGHASH_ANYPREVOUT (본질적으로) scriptPubKey (스크립트 공개 키)를 약속합니다. SIGHASH_ANYPREVOUTANYSCRIPT 는 모든 스크립트를 허용합니다. 앞에서 설명한 것처럼 이는 원래 LN 대칭을 지원하여 서명된 각 채널 상태에 대한 전용 응답이 필요할 가능성을 피하기 위해 제안되었습니다.
SIGHASH_ANYPREVOUT RBF 수수료 변형과 함께 사전 서명된 거래를 사용하려는 경우에도 유용할 수 있습니다. 서명이 더 이상 특정 거래 ID에 의존하지 않아수수료 변형의 조합 폭발을 방지하기 때문입니다. 그러나 현재 BIP-118은 이 사용 사례를 나타내지 않습니다. SIGHASH_ANYPREVOUT UTXO의 가치도 약속하기 때문에 호환되지 않을 수도 있습니다.
SIGHASH_ANYPREVOUT 에 대한 초기 반대 의견 중 하나는 부적절한 사용으로 인해 지갑 자체에 문제가 발생할 수 있다는 것입니다. 문제는 SIGHASH_ANYPREVOUT 서명 이 발행되면 동일한 스크립트를 사용하여 모든 트랜잭션 출력을 소비하는 데 사용될 수 있다는 것입니다. 따라서 SIGHASH_ANYPREVOUT 동일한 스크립트를 사용하는 두 번째 출력이 실수로 생성될 때마다 자금을 도난당할 수 있는 간단한 재생 공격을 허용합니다. 하지만 지갑과 L2 구현은 스스로 자멸할 가능성이 많기 때문에 이러한 우려는 많이 사라진 것 같습니다.
현재 광범위한 기술 커뮤니티는 BIP-118 구현에 대해 상당히 낙관적인 것으로 보입니다. 그러나 LN-Symmetry를 논의할 때 말했듯이 사람들은 주요 응용 시나리오인 LN-Symmetry가 좋은 아이디어인지에 대해서도 논쟁을 벌이고 있습니다.
5.3 OP_CheckTemplateVerify
제약 조건에 대해 구체적으로 논의할 첫 번째 제안은 "CTV"라고도 하는 OP_CheckTemplateVerify 입니다. 이는 한 가지 작업만 수행하는 매우 구체적이고 제한된 제약 opcode를 만드는 데 중점을 둡니다. 특정 입력 UTXO를 포함하지 않는 지출 거래를 해시합니다. 그런 다음 결과 해시 다이제스트가 스크립트 스택 상단에 있는 요소와 동일한지 확인하세요. 이를 통해 실제 재귀적 제약을 적용 하지 않고도 출력에 대한 지출 거래를 미리 제한할 수 있습니다.
CTV가 재귀적 제약 조건을 구현할 수 없는 이유는 무엇입니까? 해시 함수: CTV는 템플릿 해시 값을 사용하여 지출 거래를 확인하므로 CTV와 자체 해시 값을 포함할 수 있는 템플릿을 생성할 방법이 없습니다 [18] .
다시 말하지만 이것이 반드시 실제 제한 사항은 아닙니다. 최신 컴퓨터에서는 몇 초 만에 수천만 건의 트랜잭션을 CTV 템플릿 체인으로 쉽게 해시할 수 있습니다. nSeuqunce의 상대적 시간 잠금 및 제한된 블록 공간을 통해 이 체인은 수천 년 동안 자금 합계를 쉽게 잠글 수 있습니다.
BIP-119 의 현재 CTV 제안에는 기본적으로 템플릿 해시에서 트랜잭션의 모든 측면을 소비하는 데 전념하는 DefaultCheckTemplateVerifyHash 라는 하나의 해싱 모드만 있습니다. 실용적인 관점에서 이는 많은 경우 CPFP가 수수료 지불에 사용할 수 있는 유일한 수단이 될 것임을 의미합니다. 앞서 언급한 것처럼 CTV를 활용한 거래량이 적을 경우 블랙박스 결제는 상당한 비용 절감 수단이 되기 때문에 문제가 될 수 있다.
공평하게 말하자면, CTV는 상대적인 단순성과 다양성으로 인해 제한 조항 opcode 제안을 둘러싼 기술 커뮤니티에서 광범위한 지원을 받고 있습니다.
5.3.1 LNHANCE
CTV를 구현하기 위한 한 가지 제안은 이를 두 개의 추가 opcode OP_CheckSigFromStack(Verify) 및 OP_InternalKey 와 결합하는 것입니다. 문제는 이 글을 쓰는 시점에서 관련 PR 및 BIP에 이 제안을 지지하거나 거부할 수 있는 문서가 충분하지 않다는 것입니다. 관련 BIP에는 이러한
