머리말

나는 오랫동안 질문에 대해 생각해 왔습니다. 비트코인의 기본 확장의 핵심 논리는 무엇입니까 ?

라이트닝 네트워크를 탐구하고 라이트닝 네트워크에서 비수탁 업무 구현하려고 시도하면서 우리는 약간의 불협화음을 느꼈습니다. 이론적으로 양방향 채널은 가장 강력한 트랜잭션 처리량을 가지고 있지만 실제 유지 관리 및 사용 문제는 예상보다 훨씬 더 많습니다. 초기 소액결제 방향에서 라이트닝 네트워크의 현재 성과는 만족스럽지 못하며, 핵심 이유는 유동성이다. 유동성 개선을 위한 인프라를 대량 도입했지만 실제 효과는 아직 기대에 미치지 못하고 있다.

이 기사가 작성되는 동안 업계에서 유명한 Lightning 자체 호스팅 지갑 Mutiny Wallet이 폐쇄를 발표한 데 이어 파트너 LSP(Liquidity Service Provider)의 폐쇄도 발표되었습니다. 자체 호스팅 지갑과 LSP 간의 협업 모델은 항상 라이트닝 네트워크의 중요한 미래 방향으로 간주되어 사람들이 다시 한번 미래를 걱정하게 만듭니다. 따라서 이 시점에서 본 글에서는 유동성 확장의 관점에서 채널 네트워크의 진화와 향후 발전 동향을 살펴보고자 한다.

1. 현재 라이트닝 네트워크의 문제점은 무엇입니까?

비트코인의 블록 용량은 제한되어 있고 메인넷 블록 생성 시간은 평균 약 10분으로 길며 이는 분명히 세계 P2P 현금 시스템이 되기 위한 요구 사항과는 너무 거리가 멀습니다. 이를 고려하여 우리는 스케일링 솔루션이 시급히 필요합니다. 작은 블록 공간을 차지하고 신속하게 처리할 수 있어야 하며 기본 비트코인 ​​기반 솔루션이어야 합니다. 그 결과 라이트닝 네트워크가 탄생했습니다.

라이트닝 네트워크는 자산이 온체인 잠긴 후 체인 아래에서 약정된 거래의 교환이 완료된 것으로 간주된다고 정의하므로 이를 즉시 지불이라고 합니다. 경험상 이는 비트코인 ​​메인넷 결제 확인 시간의 10분 제한과 비교되며, 소액 결제 시나리오의 경우 가장 큰 문제를 해결합니다.

그러나 라이트닝 네트워크의 실제 개발 및 사용 과정에서 여러 가지 문제가 점차 나타났습니다. 이 기사에서는 여기에 네 가지 핵심 문제를 요약합니다.

1.1 노드 유지관리가 어렵다

현재 라이트닝 네트워크는 P2P 페널티 거래 게임 모델을 기반으로 하며, 채널이 존재하는 동안 상대방이 자신에게 도움이 되지 않는 이전 상태를 업로드하는지 여부를 지속적으로 모니터링하기 위해 이 모델에서는 WatchTower가 전혀 온라인 상태여야 합니다. 이는 사용자가 노드 자체를 유지해야 하는 시대입니다. 또한 사용자는 페널티 개인 키와 약정 거래 데이터를 로컬에 저장해야 하므로 노드 유지 관리 임계값과 교육 비용이 높아집니다.

1.2 고도의 대화형

라이트닝 네트워크에서 상호작용이란 일반적으로 사용자가 거래 프로세스 중에 수행해야 하는 일련의 상호작용 작업을 의미합니다. 이러한 작업에는 서명, 약정 거래 교환, 개인 키 처벌 등이 포함되는 경우가 많습니다. 예를 들어, 오프체인 상태가 업데이트될 때마다 거래 당사자 모두 동시에 온라인 상태여야 하며 교환을 위한 새로운 약정 거래에 서명해야 하며 이는 사용자 상호 작용에 대한 엄격한 요구 사항을 갖습니다. 그리고 여러 당사자가 상호 작용할 때 HTLC와 멀티홉으로 인한 복잡성도 극복하기 어렵습니다.

1.3 낮은 자본 효율성

양 당사자 채널의 LN-Panelty 메커니즘은 어느 정도 사용자가 자신의 은행 계좌를 개설하고 자신의 준비금을 가져와야 하는 것과 동일합니다. 대표적인 문제는 사용자가 자금을 받기 위해 채널 유동성을 확보해야 하며, 자본 효율성이 매우 낮다는 것입니다. 그리고 엣지의 많은 채널 유동성이 완전히 활용되지 않을 것입니다.

1.4 채널 관리 비용이 높다

P2P 채널에서는 유동성 불균형이 매우 쉽게 발생하며, 사용자는 유동성 보충을 돕기 위해 잠수함 스왑, 채널 스플라이싱 등 다양한 도구에 의존해야 합니다. 그러나 이러한 기술은 구현될 원래 FundingTx를 조정하기 위해 추가적인 온체인 트랜잭션이 필요합니다. 일반적으로 모든 조정에는 비용이 많이 들며, 특히 수수료가 상승할 경우 사용자가 비용을 무시하기 어렵습니다.

저렴한 거래를 위해 레이어 2 기술을 사용한다고 생각한 사용자가 갑자기 몇 가지 메인넷 온체인 수수료에 직면하게 된다면 얼마나 당혹스러울지 상상해 보십시오. 이러한 당혹감은 온체인 처리 수수료가 높아짐에 따라 더욱 분명해지며, 이는 "처리 수수료 암살자"라고 불릴 수 있습니다.

라이트닝 네트워크의 실제 채택에서 다양한 문제도 명백한 결과를 보여주었습니다. 아래 그림의 통계에서 볼 수 있듯이 사용자 성장이 약하고 대부분의 신규 사용자가 호스팅 솔루션을 선택할 것입니다.

결국, 대부분의 일반 사용자가 스스로 노드와 채널을 유지하는 것은 너무 어렵습니다.

2. 어떤 종류의 비트코인 ​​오프체인 확장 네트워크가 필요합니까?

라이트닝 네트워크 백서 의 설명에 따르면 전 세계 모든 사람이 1년에 두 번 채널을 전환한다면 비트코인 ​​블록 용량은 결국 133MB까지 증가해야 합니다. 현재 비트코인 ​​메인넷과 비교하면 블록 크기는 1MB에 불과하고, Segregated Witness를 사용한 P2TR 주소도 4MB에 불과해 큰 격차를 보인다. 또한 실제로 채널 유동성을 조정하는 기술(잠수함 교환, 채널 스플라이싱)에는 추가 온체인 트랜잭션이 필요하다는 점을 고려하면 비트코인의 라이트닝 네트워크 대면 블록 공간 부족 문제는 실제 시나리오에서 더욱 심각할 것입니다.

현재의 라이트닝 네트워크는 단기적으로 대규모 C-end 사용자의 요구를 충족시키기 어렵다는 것을 알 수 있습니다. 또한, 비트코인 ​​블록 용량의 제한으로 인해 라이트닝 네트워크의 확장 가능성도 상당히 높습니다. 장기적으로 제한됩니다.

그러면 다음과 같은 질문이 생깁니다. 어떤 종류의 비트코인 ​​오프체인 확장 네트워크가 필요합니까?

2.1 라이트닝 네트워크 현황

라이트닝 네트워크의 현재 한계를 이해하려면 설계 원칙으로 돌아가야 합니다.

현재 라이트닝 네트워크 모델은 LN-Panelty 라고도 합니다. 일반적으로 이 모델은 페널티 거래를 기반으로 하는 2자 채널 모델입니다. 그 보안은 사용자의 거래 로컬 저장과 상대방의 벌금 개인 키에 달려 있으며, 거래 상대 의 모든 움직임이 자신의 감독하에 있는지 확인하기 위해 비트코인 ​​온체인 에 대한 모니터링이 항상 유지되어야 합니다.

이러한 모델 설계에서는 로컬 스토리지와 WatchTower 기능이 필수이기 때문에 사용자가 자체 노드를 실행하는 것이 불가피합니다. 이 부분은 이전 글에서도 반복해서 강조했습니다.

자본 및 통신 효율성 측면에서 현재 라이트닝 네트워크의 인기 모델은 LSP 슈퍼 노드가 중간에 유동성을 제공한 후 사용자가 LSP 관리자의 슈퍼 노드와 채널을 설정하는 것 자체가 원래의 방식에서 벗어났습니다. 구상된 P2P 네트워크 모양 모델. 자연진화의 경우 마침내 고전적인 허브 앤 스포크 모델로 돌아왔다.

다음 그림은 예시입니다. 왼쪽은 이상적인 라이트닝 네트워크이고, 오른쪽은 실제 라이트닝 네트워크 상태입니다.

2.2 이상적인 ToC 오프체인 확장 네트워크의 특징

이제 C 측 사용자가 비트코인 ​​오프체인 확장 네트워크에 실제로 필요한 기능이 무엇인지 상상해 보겠습니다.

1. 비P2P 모델을 사용하면 사용자는 우수한 보안과 편의성을 유지하면서 노드 자체를 유지할 필요가 없습니다.

2. 대화형 측면에서 사용자는 결제 시 동시에 온라인 상태일 필요가 없으며 오프라인 작업과 비동기 작업을 모두 구현할 수 있습니다.

3. 비수탁 요구사항을 충족하면서 자본 효율성을 향상시킵니다.

4. 사용자가 직접 유동성을 유지할 필요조차 없는 저렴하고 효율적인 유동성 관리 메커니즘

이러한 목표를 바탕으로 이 기사는 독자들이 비트코인 ​​오프체인 확장 네트워크의 향후 개발 방향을 탐색하도록 유도할 것입니다.

3. BTC의 기본 확장의 진화 경로

우선, 라이트닝 네트워크 설계 "LN-Panelty"의 현재 핵심 메커니즘에서 상태 업데이트 메커니즘의 기본은 다음과 같습니다.

· 커밋된 트랜잭션의 저장 및 지속적인 모니터링

· 여러 사람이 협업할 수 있는 멀티 홉 메커니즘(HTLC/PTLC)

이러한 요소는 현재 라이트닝 네트워크 설계의 기초를 형성하며 다음과 같이 노드 설계의 복잡성으로 직접 이어집니다.

· 복잡한 암호화 통신 상호작용

· 약정 거래 및 페널티 개인 키의 로컬 저장

· 채널이 지속되는 동안 실행 중인 WatchTower를 중단할 수 없습니다.

이러한 문제로 인해 우리는 "LN-Penalty"를 대체하기 위해 더 가벼운 상태 업데이트 메커니즘을 사용할 수 있는지 생각하게 되었습니다. 이러한 맥락에서 BIP118(SIGHASH_ANYPREOUT)이 가능한 대안으로 제안되었습니다.

3.1 LN-대칭: 상태 업데이트에 버전 메커니즘 도입

BIP118은 서명을 변경하지 않고 이전 출력을 완전히 지정하지 않고도 트랜잭션 입력이 이전 트랜잭션을 업데이트할 수 있도록 하는 SIGHASH_ANYPREOUT 서명 모드의 도입을 제안합니다. 이 설계는 "LN-Penalty"에 비해 노드 간 암호화된 통신의 복잡성과 저장 요구 사항을 크게 줄일 수 있습니다. SIGHASH_ANYPREOUT은 eltoo: A Simple Layer2 Protocol for Bitcoin 논문에서 나왔습니다. 최근 라이트닝 네트워크 개발에 대한 논의에서 이러한 개선 사항을 기반으로 하는 라이트닝 네트워크 모델을 "LN-Symmetry"라고도 합니다.

LN-Symmetry는 로컬 커밋된 트랜잭션 저장소에 대한 부담을 줄이지만 모니터링의 필요성을 완전히 제거하지는 않습니다. Eltoo는 커밋 트랜잭션과 개인 키 서명의 교환을 요구하지 않지만, 참가자가 온체인 에 이전 상태를 게시하려고 시도하는 경우 상대방은 여전히 ​​실시간으로 모니터링하고 적시에 최신 상태 트랜잭션을 게시하여 교체해야 합니다. 오래된 상태. 이 프로세스의 모니터링 작업에는 여전히 전통적인 WatchTower가 필요합니다. 이때 WatchTower를 실행하는 목적은 처벌에서 상태 교체로 변경됩니다. 사용자는 여전히 자신의 노드를 유지해야 합니다.

동시에 LN-Symmetry는 여러 사람의 협업을 보장하기 위해 여전히 HTLC/PTLC와 같은 메커니즘이 필요하며, 이는 이전 라이트닝 네트워크 노드 설계와 마찬가지로 여전히 무거운 통신 부담을 갖습니다.

따라서 전체적인 효과로 볼 때 LN-Symmetry가 현재 라이트닝 네트워크에 제공하는 경험 개선은 제한적이며, 우리가 추구하는 목표까지는 아직 갈 길이 멀습니다.

추가적인 개선을 위해 이 글은 다음 단계인 공유 UTXO의 방향으로 이어집니다.

3.2 CoinPool: 다자간 채널의 상호작용성 및 유동성 요구 사항 감소

공유 UTXO의 개념을 소개한 첫 번째 논문은 비트코인을 위한 효율적인 오프체인 결제 풀인 CoinPool이었습니다. 핵심 목표는 SIGHASH_ANYPREOUT의 버전 업데이트 메커니즘에서 다자간 상호 작용 문제를 더욱 해결하는 것입니다.

LN-Symmetry 설계에서 Eltoo가 도입한 새로운 상태 업데이트 메커니즘은 실제로 지점 간 채널의 상태 관리를 단순화합니다. 그러나 다자간 협업의 경우 상호작용의 복잡성이 여전히 존재하며, 특히 모든 당사자의 긴밀한 조정과 암호화된 통신이 여러 번 필요한 멀티 홉 결제(HTLC/PTLC)의 경우 더욱 그렇습니다.

CoinPool의 혁신은 공유 UTXO 모델을 활용하여 여러 당사자가 버전 제어를 통해 동일한 UTXO에 대해 협업할 수 있도록 한다는 것입니다. 이러한 방식으로 여러 참가자가 복잡한 HTLC/PTLC 메커니즘에 의존하지 않고 UTXO 상태를 공동으로 약속하고 관리할 수 있습니다. 주요 장점은 다음과 같습니다.

· 다자간 채널의 상호 작용 복잡성을 크게 줄입니다. 모든 참가자는 동일한 UTXO를 공유하므로 여러 온체인 트랜잭션이나 복잡한 오프체인 상호 작용 없이 이 UTXO의 버전 업데이트에 서명함으로써 합의에 도달할 수 있습니다. 이러한 단순화로 인해 다자간 채널 관리가 더욱 효율적으로 이루어집니다.

· 오프체인 업데이트 메커니즘이 더욱 직접화됩니다. 이 설계에 따라 오프체인 상태 업데이트 메커니즘은 여러 당사자가 공동으로 서명하는 특정 버전의 UTXO로 변환됩니다. 이 접근 방식은 상태 업데이트 프로세스를 단순화할 뿐만 아니라 당사자 간의 종속성과 잠재적인 충돌 지점을 더욱 줄여줍니다.

· 독립적인 유동성의 필요성 제거: 공유 UTXO 모델을 통해 여러 참가자가 실제로 동일한 유동성 풀을 공유하므로 각 참가자가 독립적으로 충분한 유동성을 유지할 필요가 없습니다. 다자간 협업 CoinPool 설계에서는 유동성 요구 사항을 크게 줄이거나 재할당할 수 있습니다. 참가자는 자신의 채널에 대량 자금을 락업할 필요 없이 공유된 UTXO의 유동성을 활용하여 결제를 완료할 수 있습니다. 이는 자금 활용의 효율성을 향상시킬 뿐만 아니라 개인 참가자의 재정적 압박을 줄여줍니다.

CoinPool의 설계는 UTXO를 공유함으로써 다자간 채널의 상호 작용 복잡성을 합리적인 수준으로 줄이는 동시에 시스템의 보안과 효율성을 유지하는 데 성공했습니다. 더 중요한 것은 각 참가자의 독립적인 유동성 요구에 대한 의존도를 줄이고 다자간 협업을 위한 더 가볍고 유연한 솔루션을 제공하며 다자간 상호 작용 및 유동성 관리의 한계에서 기존 LN 모델을 돌파한다는 것입니다.

그러나 분명한 이점을 지닌 그러한 솔루션이 지금까지 대규모로 채택되지 않은 이유는 무엇입니까? 문제의 근원은 무엇입니까?

3.3 CoinPool이 실제로 구현되지 않은 이유는 무엇입니까?

CoinPool은 많은 장점을 가지고 있으며 이상적인 확장 모델로 간주되지만, 이것이 의존하는 소프트 포크 업그레이드에는 너무 많은 요구 사항이 필요하므로 평생 동안 비트코인 ​​네트워크에서 구현되는 것을 볼 수 없을 수도 있습니다. 소프트 포크 업그레이드에 대한 CoinPool의 요구는 주로 다음 두 가지 측면에 중점을 둡니다.

3.3.1 상태 업데이트 메커니즘 업그레이드

CoinPool은 Eltoo를 기반으로 설계되었으므로 새로운 서명 모드 SIGHASH_ANYPREVOUT(APO)을 활성화하려면 비트코인 ​​업그레이드가 필요한 소프트 포크 에 대한 상태 업데이트 메커니즘에 대한 필요성을 물려받았습니다. 그러나 우리 모두 알고 있듯이 비트코인 ​​소프트 포크 업그레이드는 천천히 진행되고 있습니다. 이는 코인풀의 상태 업데이트 메커니즘이 의존하는 기술을 현실적으로 적용하기 어렵게 만듭니다.

3.3.2 공유 UTXO는 운영 메커니즘을 단순화하기 위해 계약이 필요합니다.

위에서 언급한 것처럼, 공유 UTXO 상태를 업데이트할 때마다 모든 공유 버전의 UTXO 서명을 수집해야 합니다. 이 과정에서 한 당사자가 오프라인 상태가 되면 전체 시스템이 정지됩니다. 블록체인 측면에서 이 시스템은 활성 상태가 좋지 않습니다. 이러한 문제를 극복하려면 시스템에는 협력에 전적으로 의존하지 않고 저렴한 비용으로 공유 UTXO를 업데이트할 수 있는 메커니즘이 필요합니다.

CoinPool 논문에서는 Merkle 트리 구조를 통해 특정 참여자의 상태를 확인하고 업데이트하는 것을 목표로 하는 OP_MERKLESUB을 제안했습니다. 이 설계 아이디어는 이론적으로는 가능하지만 Merkle 트리를 기반으로 하는 다른 작업 계약과 유사한 문제에 직면합니다. 즉, 논리 구현이 복잡하고 보편적이고 재사용 가능한 계약을 형성하기가 어렵습니다. 예를 들어 **OP_TAPLEAFUPDATEVERIFY(TLUV)**와 유사한 계약 등이 있습니다. 또한 비협조적인 당사자를 공유 UTXO에서 직접 쫓아내는 OP_EVICT의 계약 기능은 너무 단순하여 비트코인 ​​네트워크의 업그레이드를 성공적으로 통과할 수 있다고 예측하기 어렵습니다.

이러한 계약 제안 중 OP_CheckTemplateVerify(CTV)가 점차 주목을 받고 있습니다. Merkle 트리를 직접 구축하고 검증하는 대신 CTV는 사전 정의된 거래 템플릿을 통해 지출을 제한합니다. CTV는 구현이 간단할 뿐만 아니라 트랜잭션 커밋 체인을 통해 온체인 UTXO를 통해 일련의 오프체인 UTXO를 커밋할 수도 있습니다. 체인에 커밋된 이러한 오프 온체인 UTXO는 가상 UTXO 개념의 원래 기원입니다.

이들 계약 중 CTV는 간편성과 활용성 측면에서 가장 큰 인기를 끌고 있다. CTV의 강력한 기능은 CoinPool과 유사한 아이디어를 구현할 수 있을 뿐만 아니라 Rollup에서도 사용할 수 있습니다. 매번 OP_CAT을 통해 ZKP-MerkleState 검증을 수행하고 스크립트에서 Layer2 상태에 해당하는 공유 UTXO에 직접 커밋함으로써 진정한 비트코인 ​​ZK-Rollup 솔루션을 구축할 수 있을 것으로 생각됩니다.

요약하자면, CoinPool 구현이 직면한 주요 문제는 이를 구현하는 데 도움이 되는 경량 상태 업데이트 메커니즘 APO 및 공유 UTXO opcode가 필요하다는 것입니다. 두 가지 모두 비트코인의 소프트 포크 업그레이드가 필요합니다. CoinPool 종이가 탄생한 지 수년이 지났지만 여전히 종이 솔루션입니다.

3.4 비트코인 ​​파벌: 오프체인 이중지불 방지 기본 2-AS

앞서 언급한 CoinPool 모델에 대한 논의에서 우리는 그것이 의존하는 APO 메커니즘이 단기간에 달성하기 어려운 솔루션을 실현하기 위해 소프트 포크 업그레이드가 필요하다는 것을 알게 되었습니다. 따라서 비트코인 ​​소프트 포크 업그레이드에 의존하지 않는 새로운 오프체인 이중 지출 방지 기본 요소가 있다면 구현 문제는 상당 부분 해결될 것입니다.

SIGHASH_ANYPREVOUT의 핵심 기능은 이중 지출을 방지할 수 있는 오프체인 상태 업데이트 메커니즘을 제공하는 것입니다. 이 아이디어를 바탕으로 동등한 암호화 기본 요소를 찾을 수 있다면 오프체인 상태 업데이트 문제를 해결할 수 있으며 비트코인 ​​작업 기본 요소를 업데이트할 필요성을 피할 수 있습니다. Bitcoin Clique 논문의 출현은 새로운 새벽을 가져옵니다. 이는 오프체인 이중 지출 방지를 위한 새로운 솔루션을 제공하는 새로운 암호화 기본 방식인 2-AS(2-shot-adaptor-signature)를 도입합니다.

2-AS는 Schnorr 어댑터 서명을 기반으로 하는 암호화 기본 요소입니다. 2-AS를 이해하려면 먼저 Schnorr 서명과 어댑터 서명에 대해 어느 정도 이해해야 합니다.

3.4.1 슈노르 서명

Schnorr 서명에는 선형 속성이 있습니다. 즉, 여러 서명을 단일 서명으로 집계할 수 있습니다. 쉽게 말하면 $S_1$, $S_2$ 서명이 여러 개인 경우 추가를 통해 $S=S_1+S_2$ 하나의 서명으로 집계할 수 있으며, 검증 시 해당 공개키도 $P로 집계할 수 있습니다. = P_1 + P_2 $.

3.4.2 어댑터 서명

Gen, PSign, PVrfy, Adapt 및 Extract와 같은 어댑터 서명에 대한 몇 가지 기본 단계가 있습니다. 2-AS를 이해할 때 Psign과 Extract의 두 단계를 이해하는 것이 특히 중요합니다.

이 문서에서는 암호화 관점이 아닌 목적에서 어댑터 서명을 이해하는 데 중점을 둡니다. 간단히 말해서, 두 주체가 협력하여 서명을 확인하고자 할 때 상대방의 어댑터를 서명의 일부로 사용하는 경우가 많으며, 어댑터는 공개키와 개인키 중 공개키 부분인 경우가 많아 해당 개인키를 보유하고 있는 경우가 많습니다. 어댑터의 소위 비밀 파티는 Psign이 남긴 서명의 일부를 완성하는 데 적응할 수 있는 능력을 가지고 있습니다. 그것뿐이라면 MuSig와 비슷할까요? 그러나 어댑터 서명의 고유성은 추출이 가능하다는 것입니다. 즉, 완전한 서명이 공개된 후 원래 어댑터 서명의 Psign을 시작한 당사자는 완전한 서명을 통해 해당 비밀을 클레임 할 수 있습니다. 부분 서명 및 어댑터(공개 키)(개인 키)입니다.

3.4.3 둘의 조합: 2-AS

이제 Schnorr 서명과 어댑터 서명의 속성에 대해 배웠으므로 이제 두 가지를 결합하는 마법인 2-AS를 살펴볼 수 있습니다.

VTXO가 있고 이중 지불 시 오프체인에서 삭감될 수 있도록 하고 싶다면 다음과 같이 설계할 수 있습니다.

· 먼저 잠금 해제할 수 있는 공개키가 페널티 공개 키인 페널티 출력이 필요합니다. 이중 지출 시 사용자가 처벌받을 수 있는지 확인하세요.

· 거래 상대 오프체인 거래를 확인하기 위해 서로 협력하여 어댑터 서명을 수행합니다. 사용자가 동일한 입력을 두 번 사용하는 경우 서비스 제공자가 출력을 삭감할 수 있습니다.

· 사용자는 상태를 업데이트할 때마다 페널티 출력으로 공개키를 생성해야 합니다. 페널티 출력의 페널티 공개키는 미리 결정된 두 쌍의 공개키에 Schnorr 서명 기술을 추가하여 구성됩니다.

따라서 각 거래 이전에 이후에 사용할 공개 키와 개인 키 쌍을 확인하고 사전에 페널티 출력을 생성합니다. 그러다가 이중 지출이 발생하면 서비스 제공자는 최종적으로 두 개의 어댑터 서명을 통해 페널티 출력에 해당하는 개인 키를 얻을 수 있습니다.

3.4.4 비트코인 ​​클리크의 장점과 단점

Bitcoin Clique 계획도 완벽하지 않습니다. 단점은 새로운 페널티 공개 키를 구축하는 데 사용되는 2-AS 키가 오프체인 상태가 업데이트될 때 지속적으로 교환되어야 한다는 것입니다. 그리고 이 솔루션은 CoinPool 설계를 기반으로 하며, 매번 2-AS 키를 교환하고 UTXO의 새 버전 서명을 확인하기 위해 상태가 업데이트될 때 모든 사람이 온라인 상태여야 합니다. 즉, 의사소통의 복잡성과 상호작용성은 여전히 ​​매우 높습니다.

가장 중요한 점은 이 모델이 StateChain과 유사한 설계라는 점입니다. 특정 UTXO의 소유권을 오프체인으로 이전할 때마다 2-AS와 같은 이중 지출 방지 서명을 사용하는 시스템은 온체인에서 사용할 수 없습니다. 결제 중에 이루어지므로 적용 시나리오가 매우 제한됩니다.

또한, 작동하기 쉬운 SharedUTXO 메커니즘과 소프트 포크 필요하지 않은 오프체인 이중 지출 기본 방식을 사용하더라도 각 상태가 업데이트되는 경우에만 온라인으로 모든 사람이 UTXO의 새로운 상태를 업데이트하고 확인해야 합니다. 사람들의 오프체인 네트워크 부분에 영향을 미칩니다. 관련 없는 사람들이 온라인에서 온체인 업데이트에 참여하도록 허용하는 것은 불합리합니다. 그리고 유동성의 필요성을 완전히 없애는 것은 바람직하지 않습니다. 유동성 윤활이 부족한 지불 방식은 액면가를 변경할 수 없으며, 퇴출 문제로 인해 모든 사람이 동일한 액면가를 가져야 하는 경우가 많습니다.

따라서 현재 비채널이고 동적 단위를 지원하며 UTXO를 기반으로 하는 오프체인 확장 솔루션은 없습니다. 이더 이더리움은 플라즈마 트랩(Plasma Trap)이라고 불리는 이 경로로 인해 어려움을 겪었습니다. 관련 연구는 Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma(플라즈마의 한계 탐색) 논문을 참조하세요.

문제 및 교훈 요약:

1. 동적 단위 결제를 보장하려면 유동성의 윤활이 필요합니다(환전 거래 가능). 이를 위해서는 채널 설계를 유지해야 하며 동시에 종료 문제도 피할 수 있습니다.

2. 모든 참가자가 동시에 온라인 상태에 대한 의존도를 줄입니다. 우리는 오프체인 네트워크에서 상태를 업데이트할 때 모든 사용자가 온라인 상태가 되는 것을 원하지 않습니다. 공유 UTXO 업데이트는 관련 사람들이 온라인으로 공동으로 업데이트해야 합니다.

위의 이해를 바탕으로 이 기사에서는 이 방향에 더욱 최적화된 솔루션을 계속해서 탐색합니다.

3.5 채널 팩토리 및 가상 채널

이전 논의에서 우리는 채널의 디자인을 보존해야 할 뿐만 아니라 체인에서 저비용 혜택을 가져오기 위해 공유 UTXO가 필요하다는 것을 깨달았습니다. 그러다가 라이트닝 네트워크 분야에서 오랫동안 논의되었던 개념이 우리의 비전 분야, 즉 채널 팩토리에 들어왔습니다.

이전에는 온체인 UTXO가 커밋한 오프 온체인 UTXO를 가상 UTXO라고 언급했습니다. 오프체인 Virtual UTXO를 채널의 FundingTx로 활용하면 새로운 개념의 가상채널(Virtual Channel)이 탄생하게 됩니다. 그런 다음 이 공유 UTXO의 체인 아래에 있는 가상 채널이 가상 HTLC에 의해 연결됩니다. 모든 것이 오프체인이며 "가상화"되어 있습니다. 이는 이상적인 솔루션을 제공하는 것으로 보입니다. 유동성 조정 등 대부분의 기능을 오프체인으로 구현하면 라이트닝 네트워크의 확장이 쉽게 해결될 것으로 보입니다.

그런데 정말 너무 아름답죠?

공유 UTXO의 특성을 계승하므로 채널 팩토리를 열고 닫는 데는 여러 사용자의 협업이 필요합니다. 사용자 중 한 명이 적시에 협력하지 못하는 경우(예: 오프라인이거나 응답이 없는 경우) 전체 채널 팩터리의 기능에 영향을 미칠 수 있습니다. 채널 팩토리에는 상태 업데이트에 공동 서명하는 여러 당사자가 포함되므로 모든 당사자의 비동기화 또는 악의적인 행동으로 인해 다른 사용자가 성공적으로 채널을 닫고 자금을 클레임 못할 수 있습니다.

그리고 이 설계의 문제점도 분명합니다. 이러한 방식으로 채널 전환 비용이 줄어들지만 채널 간 보안 모델은 여전히 ​​커미트 트랜잭션과 HTLC에 의존합니다. 따라서 통신 및 상호 작용 문제가 여전히 존재하며 이 솔루션의 구현 복잡성은 현재 LN-Panelty보다 훨씬 높습니다.

3.6 ARK JoinPool 및 임시 채널

이전 채널 팩토리 사례 검토를 통해 우리는 공유 UTXO를 기반으로 한 채널 디자인에서 고전적인 "LN-Panelty" 채널 디자인을 계속할 수는 없지만 동시에 채널 도입의 장점은 다음과 같다는 결론에 도달했습니다. 유지됨:

1. 유동성에 의한 유동적 명칭

2. 나가기가 쉽습니다.

이를 바탕으로 JoinPool을 사용한 임시 채널 설계, 즉 ARK 프로토콜이 등장했습니다.

3.6.1 JoinPool : 일부 사람들이 업데이트에 참여합니다.

위에서 언급한 바와 같이 CoinPool은 여러 사람의 오프체인 협업 확장 가능성을 제공합니다. 예를 들어 유동성, 멀티 홉 및 HTLC와 같은 복잡하고 실패하기 쉬운 설계가 필요하지 않습니다. 그러나 CoinPool 모델의 가장 중요한 문제는 사용자에 대한 온라인 요구 사항입니다. 전체 공유 UTXO의 모든 사용자는 오프 체인 상태를 업데이트할 때 일부 사용자의 상태가 변경되지 않더라도 온라인 확인 및 해당 서명이 온라인 상태여야 합니다. 여전히 필요합니다. 이러한 요구 사항으로 인해 사용자가 자신의 노드를 실행해야 하는 문제를 피할 수 없습니다.

이 문제를 해결하기 위해 JoinPool이라는 새로운 모델이 제안되었습니다. 공유 UTXO의 JoinPool 개념은 사용자가 오프체인 상태를 업데이트해야 할 때마다 모든 사람이 해당 UTXO의 새로운 상태를 나타내는 공유 UTXO에 참여한다는 것입니다. 이는 다른 사용자가 실행하는 동안 관련 없는 사용자가 온라인 상태를 유지해야 하는 문제를 해결합니다. 즉, JoinPool을 기반으로 한 디자인에서 사용자는 거래가 필요할 때만 온라인 상태이면 됩니다.

그러나 우리 모두는 서명을 위해 사용자의 개인 키가 온라인 상태인지 확인하는 것 외에도 라이트닝 네트워크 노드를 중단 없이 실행해야 하는 중요한 이유가 있다는 것을 이해합니다. 각 채널 구성원은 거래 상대 어떤 정보를 넣었는지 지속적으로 모니터링하기 위해 WatchTower가 필요합니다. 자신에게 불리한 정보를 온체인 에 커밋합니다. 이는 우리가 해결해야 할 두 번째 질문으로 이어집니다.

3.6.2 WatchTower 책임 이전: 사용자가 스스로 노드를 유지할 필요가 없습니다.

기존 LN-Panelty 디자인에서는 각 사용자가 자신만의 WatchTower를 구축하여 상대방이 이전 상태를 체인에 업로드하는지 여부를 모니터링해야 하며, 그럴 경우 처벌을 받게 됩니다. 이러한 기존 모델에서는 우리 모두의 거래 상대 피어 라이트닝 노드이며, 거래에 참여할 때마다 거래를 위해 다른 노드로 채널을 개설하는 것이 가능합니다. 하지만 ARK에서는 모든 사용자가 실제로 ASP(ARK 서비스 제공자)와 상호 작용하며 다른 사용자와 직접 상호 작용하지는 않습니다.

ASP의 경우 사용자의 VTXO 오프체인이 거래되면 권리 포기 거래가 체결됩니다. 이상적으로는 사용자의 오프체인 VTXO가 온체인 언급되지 않고 지속적으로 참조되어 다음 거래 라운드로 이어지기 때문입니다. VTXO가 오프체인에서 거래되는 동시에 온체인 제안된다면 이는 사용자가 VTXO를 이중으로 지출했다는 의미이며 ASP는 사용자 오프체인에서 서명한 면제 거래를 사용하여 온체인 자금은 압수됩니다. ASP는 온체인 소비된 VTXO를 악의적으로 종료하는 사람을 방지하기 위해 기록에 나타난 모든 VTXO를 모니터링합니다.

이는 WatchTower의 운영 책임을 일반 사용자에서 운영자에게 이전하는 것입니다. 라이트닝 네트워크와 비교할 때 이 모델은 크게 개선되었습니다. 마침내 일반 사용자가 자신의 보안을 보장하기 위해 자신의 노드를 실행할 필요가 없습니다 .

사용자 노드 운영 최적화에 대한 다른 솔루션 요약:

· 라이트닝 네트워크 노드 클라우드 호스팅

일부 솔루션은 사용자가 노드 실행 임계값을 낮추는 데 도움이 되도록 클라우드 플랫폼에서 Lightning Network 노드를 실행하도록 선택합니다. 그러나 이 솔루션은 본질적으로 라이트닝 네트워크 자체의 보안 가정을 ​​위반합니다. 라이트닝 네트워크 기술에서 개인 키와 커밋된 트랜잭션의 저장은 많은 시나리오에서 똑같이 중요합니다. 따라서 단순히 원격 개인 키를 사용한다고 해서 보안이 보장되는 것은 아닙니다.

기본적으로 이 솔루션은 2자 게임 시나리오를 나와 거래 상대, 클라우드 호스팅 당사자가 참여하는 3자 게임 시나리오로 전환합니다. 상대방과 거래했지만 상태가 아직 체인에 업로드되지 않은 경우 클라우드 관리인은 내 클라우드 노드에서 커밋된 거래를 일방적으로 삭제할 수 있습니다. 이때 거래 상대 유리한 상태를 쉽게 업로드할 수 있습니다. 이러한 라이트닝 네트워크 클라우드 노드 호스팅 솔루션에는 클라우드 호스팅 플랫폼과 거래 상대 간의 담합 리스크 있습니다.

· 크랩과 슬리피 크랩

Aumayr 등이 제안한 CRAB(Channel Resistant Against Bribery) 프로토콜은 특히 사용자가 오프라인일 때 채굴자에게 인센티브를 제공하는 메커니즘과 추가 담보를 추가하여 결제 채널의 보안을 보장합니다. 이 메커니즘은 타사 WatchTower에 대한 의존도를 줄여줍니다. 그러나 이러한 담보 메커니즘은 의심할 여지 없이 "예약된 유동성"과 같은 문제를 더욱 악화시킵니다. 오프체인 네트워크에 합류할 때 사용자가 거래 목적과 무관한 더 많은 자금을 잠가야 하기 때문에 보안은 보장되지만 자금의 유동성과 효율성이 희생됩니다. 더욱이 이러한 유형의 솔루션에서는 여전히 사용자가 스스로 노드를 실행해야 하지만 사용자가 온라인 상태여야 하는 요구 사항만 줄어듭니다.

3.6.3 임시 채널: 사용자가 직접 채널 유동성을 유지할 필요가 없습니다.

누군가는 왜 ASP 서비스 제공자가 JoinPool의 우리 채널에 유동성을 주입하려고 합니까?라고 물을 수 있습니다. 사용자가 ARK 네트워크 기반 VTXO를 사용하려면 먼저 UTXO를 VTXO와 교환하여 FundingTx와 유사한 다중 서명 주소에 운영자에게 입금해야 하기 때문입니다. 본질적으로 사용자는 모든 오프체인 거래에 운영자의 자금을 사용하지만 이전에 운영자와 서명한 자금을 전송하게 됩니다.

ARK의 채널을 임시 채널이라고 부르는 이유는 단방향 자본 투입과 일회성 자본 투입이라는 두 가지 특성을 갖고 있기 때문입니다.

· 단방향: 단방향 채널에서는 자금이 지정된 개시자로부터 해당 출력 당사자로만 이체됩니다.

· 일회성 자본 투입: ARK의 채널에는 일회성 자본 투입만 필요합니다. 자금이 주입된 후에는 채널의 유동성을 계속 유지할 필요가 없습니다.

이러한 임시 채널 설계에 따르면 자본 투입이 완료된 후 리밸런싱 등 채널 조정이 필요하지 않습니다. Lightning과 비교하면 사용자는 더 이상 채널 유동성에 신경 쓸 필요가 없을 뿐만 아니라 유동성 공급자도 더 이상 채널 유동성을 유지할 필요가 없습니다. 채널에 존재하는 유일한 변경 사항은 사용자 종료 이벤트입니다.

3.6.4 ARK 프로토콜 요약

위의 내용을 바탕으로 ARK 프로토콜의 설계가 라이트닝 네트워크에 비해 사용자 경험에서 놀라운 발전을 이뤘음을 분명히 알 수 있습니다.

· 사용자는 노드 자체를 유지할 필요가 없습니다.

· 사용자가 스스로 채널 유동성을 유지할 필요가 없으며, 회계 유동성 문제도 없습니다.

· 양 당사자가 동시에 온라인 상태가 아닌 비동기식 상호 작용을 지원합니다.

4. 비트코인 ​​기본 스케일링 패러다임의 변화

위 연구를 통해 우리는 공유 UTXO를 기반으로 한 다양한 오프체인 확장 솔루션을 탐색했습니다. 공유 UTXO는 원래 유동성 문제를 해결하기 위해 설계되었지만 프로토콜이 계속 발전함에 따라 우리는 예상했지만 감히 꿈도 꾸지 못했던 많은 이점을 가져왔다는 사실을 예기치 않게 발견했습니다.

이는 비트코인 ​​오프체인 확장이 새로운 개발 방향으로 진입했음을 나타냅니다. 원래 라이트닝 네트워크 모델과 비교하면 이는 패러다임의 변화입니다.

· P2P 모델부터 무신뢰 사업자 도입까지

오프체인 확장 네트워크의 논리는 라이트닝 네트워크의 초기 "사용자 대 사용자" 양방향 게임 모델에서 "사용자와 운영자" 간의 게임 모델로 점차 진화했습니다. 차이점은 사용자가 이 제3자 운영자를 신뢰할 필요가 없다는 것입니다.

· 자산 보안을 보장하기 위해 사용자가 직접 노드 시설을 유지할 필요가 없습니다.

CRAB와 같은 최신 연구뿐만 아니라 전통적인 LN-Penalty 모델은 자금의 안전을 보장하기 위해 사용자에게 담보를 제공하는 동시에 사용자가 채널이 존재하는 동안 온라인 상태를 유지하고 노드를 실행하도록 요구합니다. 그러나 향후 시나리오에서는 더 이상 이러한 작업이 필요하지 않습니다. 게다가 이러한 프로세스는 비수탁 상태로 유지되며 사용자는 항상 자산에 대한 통제권을 유지합니다.

· 유동성 관리 책임은 사용자에서 운영자에게 이전됩니다.

기존 LN-Penalty 모델과 개선된 디자인에서는 특히 유동성이 불균형한 경우 사용자가 채널의 유동성을 스스로 조정해야 합니다. 이는 일반적으로 어느 정도 전문 지식이 필요하며 LSP(유동성 서비스 제공자)의 도움 없이 운영하기가 복잡합니다. 그러나 유동성 관리 책임이 제3자 운영자에게 이전됨에 따라 사용자는 더 이상 유동성 관리에 대해 걱정할 필요가 없습니다. 이는 사용자 경험을 크게 단순화하고 네트워크 가입에 대한 장벽을 제거합니다.

· 자본 효율성과 잠재력이 크게 향상됩니다.

새로운 프로토콜 설계는 자본 효율성 측면에서 현재 라이트닝 네트워크와 근본적으로 다른 P2POOL 모델로 이동하고 있습니다. LN-Penalty 모델에서는 라이트닝 채널을 개설할 때 각 사용자가 스스로 유동성을 제공해야 하지만 이러한 채널의 유동성은 대부분 유휴 상태입니다(결제가 자주 발생하지 않고 채널 간에 결제가 고르지 않게 분배됨). 결과적으로 사용자의 자금을 효과적으로 사용할 수 없습니다. 새로운 프로토콜 설계 추세에서는 유동성이 통합 관리를 위해 유동성 풀로 중앙 집중화되어 미래의 DeFi 시나리오에 무한한 가능성을 제공합니다.

이러한 패러다임 전환은 유동성 관리가 비트코인 ​​네이티브 체인의 확장과 진화의 본질이자 미래 진화의 핵심 스레드이기도 함을 보여줍니다.

앞으로 기술의 지속적인 발전과 새로운 솔루션의 출현으로 비트코인의 오프체인 확장은 확실히 더 밝은 개발 전망을 가질 것입니다. 우리는 이 분야에 대해 계속해서 심층적인 연구를 수행할 것이며 독자들은 우리의 추가 결과를 기대해 주시기 바랍니다.

원본 링크

블록비츠(Theblockbeats) BlockBeats 공식 커뮤니티 에 오신 것을 환영합니다.

텔레그램 구독 그룹: https://t.me/theblockbeats

텔레그램 커뮤니케이션 그룹: https://t.me/BlockBeats_App

공식 트위터 계정: https://twitter.com/BlockBeatsAsia