여러 당사자가 공유하는 UTXO: 양식 및 속성

08-30

이 기사는 기계로 번역되었습니다

원문 표시

저자:익명

"다자간 공유 UTXO(공유 UTXO)"(이하 "공유 UTXO"로 약칭)는 이름에서 알 수 있듯이 여러 사용자가 UTXO의 소유권을 공유하고 그들의 자금을 동일한 UTXO에 배치할 수 있도록 합니다. 이 개념의 초점은 권한 관리가 아니라 내부 상태의 표현 및 제어에 있습니다. 즉, 여러 사용자의 자금을 하나의 UTXO에 저장할 수 있도록 허용하면서도 다른 사용자의 소유권 침해 없이 독립적인 보관을 보장합니다.

"공유 UTXO"라는 개념은 오랫동안 주목받고 발전되어 왔습니다. 가장 넓은 관점에서 보면 둘 이상의 당사자가 UTXO를 제어하는 모든 디자인이 이 카테고리로 간주될 수 있습니다. 이 가장 광범위한 정의에는 "Lightning Channel"과 같은 두 당사자 공유 UTXO도 포함됩니다. 두 당사자 간의 UTXO 공유를 의도적으로 배제하고 세 명 이상의 당사자가 UTXO를 공유하는 상황만 포함하더라도 2018년에 제안된 "채널 팩토리" ^[1] 개념은 의심할 여지 없이 공유 UTXO의 하위 집합입니다. 또한 2020년에 제안된 "결제 풀(CoinPool)" 개념 ^[2] 과 "언약" 제안 논의 시 "부수적으로" 제안된 일부 디자인 ^[3] 도 이 주제에 대한 내용을 추가했습니다.

사실, 사람들이 생각해낸 디자인은 너무 다양해서 (적어도 나 자신에게는) 혼란과 혼란에 휩싸였습니다. 이러한 이해 장애로 인해 이러한 디자인의 공통점을 요약하고, 기본 개념을 결정하고, 이러한 기본 개념과 지원 용어를 기반으로 이러한 디자인을 설명해야 합니다.

일부 저자가 이를 명시적으로 시작했다는 점은 언급할 가치가 있습니다(겉보기에 다른 개념을 동일한 개념에 대한 차별화된 디자인으로 취급). ^[4] Optech의 테마 인터페이스도 "결제 풀"과 "결제 풀"을 유사한 의미로 결합합니다. "Joinpool" ^[5] 이라는 이름으로 병합되었습니다(그러나 "Joinpool"과 "채널 팩토리"의 기본 개념은 아직 제안되지 않았습니다).

이러한 노력에 영감을 받아 이 글에서는 "공유 UTXO"를 기본 개념으로 사용하고, 이 개념이 직면한 기본 문제를 논의하고, 몇 가지 일반적인 디자인(예: 채널 팩토리, Statechain, ARK)의 형태와 특징을 설명하려고 합니다.

그 전에, 좀 더 기본적인 개념을 설명해야 합니다.

기본 개념

커밋된 트랜잭션

계약 프로토콜에서 "약정 거래"는 상대방이 서명한(따라서 유효하고 사용 가능한) 거래를 의미하지만 기본적으로 외부에 공개되지는 않습니다. 이러한 거래는 상대방이 제공하는 "신뢰할 수 있는 약속"이자 참가자가 일방적으로 합당한 자금을 인출할 수 있음을 보장하는 보증으로 간주될 수 있습니다.

예를 들어, 라이트닝 채널에서는 채널이 초기화되고 채널 상태가 업데이트될 때마다 양측이 커밋 거래를 상대방에게 넘겨주어야 합니다. 이러한 커밋 거래는 두 당사자의 최신 상태(잔액)를 기록합니다. 채널로 전송되면 온체인 확인되면 채널 자금이 양 당사자에게 분할 됩니다.

여기서 강조되는 것은 계약의 내부 상태를 표현하는 커밋 거래의 능력입니다. 라이트닝 채널은 온체인 UTXO로만 표시되지만 두 명의 사용자 자금을 수용할 수 있습니다. 이는 트랜잭션 커밋 기능에 의존합니다.

TXO

'공유 UTXO' 맥락에서 'vTXO(가상 UTXO)'는 UTXO에 상주하는 사용자 자금의 가장 기본적인 단위 를 의미한다. 이 용어는 분석과 표현의 편의를 위해 제안된 용어이다. 그러나 동시에 이러한 제목은 엄격한 사실 기반도 가지고 있습니다. 즉, 사용자 자금을 약정된 거래(TXO)의 결과로 표현한다는 점을 고려하면 이러한 자금의 활동은 UTXO와 다르지 않습니다.

여기서는 vTXO를 두 가지 유형으로 나눕니다. (1) "코인"이라고 할 수 있는 독점 소유 자금(일반적인 단일 서명 UTXO와 동일), (2) 라이트닝 채널 . 여기서 (라이트닝 채널을 공유 UTXO로 취급하여 전자의 유일한 유형으로 취급하는 것이 아니라) 두 가지 유형으로 나누는 이유는 다음과 같습니다. (1) 라이트닝 채널의 트랜잭션 출력은 모두 구현을 위한 다음 기능: "오프체인 업데이트 메커니즘" 및 특별히 설계된 장치는 코인으로 계산할 수 없습니다. (2) 독점 소유 자금의 사용 경험은 라이트닝 채널의 사용 경험과 매우 다릅니다. 라이트닝 채널을 사용하면 즉시 결제가 시작됩니다. 동시에 라이트닝 네트워크는 이러한 지불 능력을 증폭시킬 수 있으며 지불 규모는 조정될 수 있지만 독점 소유 자금에서는 이 중 어느 것도 불가능합니다. (3) 우리는 다음과 같은 특성에 대해 대량 지식을 축적했습니다. 라이트닝 채널, 이러한 특성을 설명할 수 있는 용어가 있으므로 이를 공유 UTXO로 표현한 후 이를 기본 분석 단위로 바꾸어 설명할 필요가 없습니다.

문자 그대로 받아들인 이 분류는 물론 불완전하지만 유용합니다. 앞으로는 공식적인 관점에서 볼 때 일부 디자인(예: 서비스 제공자와의 단방향 채널)도 라이트닝 채널의 분류 이유를 충족하는 것처럼 보이지만 이 경우 실제 사용량은 코인에 더 가깝습니다. , 나는 아직도 그것을 동전으로 분류합니다.

오프체인 업데이트 메커니즘

단순히 "커밋 거래"를 갖는 것만으로는 라이트닝 채널을 구축하는 데 충분하지 않습니다. 두 명의 사용자 자금만 동일한 UTXO에 저장되도록 허용할 수 있지만 그들이 서로 지불하려고 할 때마다 여전히 온체인 거래를 시작해야 한다면 이 구조의 실용성은 그만한 가치가 있다고 상상해 보십시오. . 라이트닝 채널의 성공은 온체인 거래를 시작하지 않고도 양 당사자가 서로 지불할 수 있도록 오프체인에서 약정 거래를 업데이트하기 위한 사용 가능한 메커니즘("LN-Panelty")의 설계에 있습니다.

공유 UTXO의 맥락에서 오프체인 업데이트 메커니즘은 온체인 확인 없이 vTXO 간에 자금을 전송할 수 있는 메커니즘을 의미합니다.

공유 UTXO

CoinPool ^[2] 기사에서 두 저자는 "비대화형 임의 주문 출금"이라는 중요한 기능을 요약했습니다. 즉, 언제 종료하든 사용자는 항상 합당한 자금을 돌려받을 수 있으며 출금 프로세스는 필요하지 않습니다. 다른 사람의 도움을 위해. 나는 이 속성이 공유 UTXO의 기본 속성이라고 믿습니다. 이 속성이 없으면 보관 솔루션으로 축소될 것입니다. 이 보관 솔루션에 어떤 종류의 내부 설계가 있더라도 "공유 UTXO"라고 할 수 없습니다.

기술적으로 이는 각 당사자(모든 vTXO 보유자)가 공유 UTXO의 상태 변경을 거부하도록 허용해야 함을 의미합니다. 그렇지 않으면 대다수의 참가자가 참가자의 자금 소유권을 침해하는 상황이 발생할 수 있습니다. 즉, 가능한 모든 상태 변경은 각 참가자의 동의를 받아야 합니다(사전 또는 즉시).

예를 들어 UTXO를 공유하는 세 명의 사용자가 있는 경우 A가 자금을 사용하여 외부 결제를 하는지, A가 B에게 결제를 원하는지, 거래가 공유 UTXO를 입력으로 사용하는 한, C의 서명 동의로 인해 거래가 발효되지 않습니다. 그렇지 않으면 A와 B가 공모하여 C의 자금을 횡령할 수도 있습니다.

그러나 실용성 측면에서 이는 문제를 제기합니다. 사용자가 오프라인 상태가 되면 다른 사용자의 상태 업데이트 기능이 영향을 받습니다(단, 돈을 인출하는 기능은 영향을 받지 않습니다). (라이트닝 채널과 유사하게, 상대방이 오프라인 상태가 되면 채널에서 자금을 운용할 수 없게 됩니다.)

공유된 모든 UTXO 디자인은 이러한 도전에 대응하고 있다고 할 수 있습니다.

다음으로, 일련의 예시를 통해 공유 UTXO 내부의 상태를 표현하는 형식과 vTXO 유형, 오프라인 사용자가 공유 UTXO에 미치는 영향을 파악하고 그에 따라 vTXO의 실용성과 사용자 경험에 영향을 미치는 방법을 소개하겠습니다. UTXO를 공유했습니다.

혼잡 제어

먼저 가장 간단한 여러 사람이 공유하는 UTXO를 생각해 보세요. n 당사자는 UTXO에서 모든 자금(vTXO)을 소유하고 이러한 vTXO는 모두 동일한 약정 거래에 커밋됩니다. 그리고 다른 모든 사람이 서명했습니다.) 이러한 커밋 거래가 브로드캐스트되고 블록이 확인되면 이 공유 UTXO는 완전히 분해됩니다. 즉, 내부 상태가 완전히 노출되고 모든 사람이 원래 저장된 자금을 돌려받게 됩니다. UTXO를 공유했습니다. 아래와 같이:

혼잡 제어-s

이는 가장 단순한 설계입니다. vTXO는 가장 단순한 유형을 사용하고, 오프체인 업데이트 메커니즘이 없으며(따라서 세 사람이 체인 외부에서 내부 지불을 시작할 수 없음), 한 사람의 일방적 인출로 인해 모두 인출됩니다. 그러한 구조의 용도는 무엇입니까?

Jeremy Rubin은 사용 시나리오에 따라 이 구조를 "혼잡 제어"라고 명명했습니다. 그 목적은 처리 수수료가 상승할 때 발생해야 하는 많은 지불이 UTXO에 "저장"되고 처리 수수료가 허용 가능한 수준으로 감소할 때까지 기다리는 것입니다. 수준에서 이러한 지불은 온체인 에 분산됩니다. 예를 들어, 수수료가 상승할 때 Alice와 다른 세 사람이 관리 거래소 에서 돈을 인출하려는 경우 거래소 세 당사자를 조정하여 공유 UTXO를 초기화하고 세 사람의 자금을 이 공유 UTXO로 먼저 이체하고 수수료가 발생할 때까지 기다릴 수 있습니다. 이때 세 사람은 다시 협력하거나 손에 든 커밋 거래를 사용하여 자금을 인출합니다.

세 사람이 항상 온라인 상태를 유지할 수 있다면 이 구조의 유용성이 크게 향상될 것입니다. 세 사람은 처리 수수료를 더욱 조정할 수 있으며, 결제 주소를 사용하지 않고 다른 사람에게 직접 결제할 수도 있습니다. 재커밋 거래. 그러나 임의 사용자의 경우에는 이것이 보장되지 않습니다. 비협조적 종료의 경우 커밋 거래가 처리 수수료를 사전에 잠갔기 때문에 확인 속도를 높이려는 사용자는 하위 거래를 사용하여 처리 수수료(예: "CPFP" ^[6] )를 추가할 수 있지만 "수수료 대체"(RBF)"를 사용할 수 없습니다.

이와 관련하여 비판받을 수 있는 또 다른 영역은 집단적 종료 메커니즘입니다. 비협조적인 상황에서 사용자가 다른 사용자보다 종료를 더 열망하고 커밋된 트랜잭션의 미리 설정된 처리 속도를 달성할 수 없는 경우 TA는 이러한 모든 UTXO가 온체인 확인되는 데 따른 추가 처리 수수료는 전적으로 본인의 책임입니다. 이는 혼잡 제어 UTXO의 사용자가 모두 동일한 시간 선호도와 사용 패턴을 갖지 않으면 사용자 경험이 손상되거나 심지어 재앙으로 변할 수도 있음을 의미합니다.

모든 vTXO를 확장하는 대신 vTXO 하나만 팝업하는 방법이 있나요? 분명히 존재합니다. 이는 단지 혼잡 제어 구조를 더 깊이 사용하는 것일 뿐입니다.

향상된 혼잡 제어

아래 그림에 표시된 것처럼 혼잡 제어 UTXO를 다음과 같이 초기화할 수 있습니다. Alice가 일방적으로 돈을 인출하려고 할 때 그녀가 사용할 수 있는 약정 거래는 자신에게 속한 vTXO만 팝업하고 나머지 자금은 다른 자금으로 반환됩니다. 하나는 나머지 참여자에게 속한 혼잡 제어 UTXO(예: 아래 그림의 "혼잡 제어 UTXO-2")로, 이 혼잡 제어 UTXO에도 커밋 트랜잭션이 사전 서명되어 있어 Bob과 Carol이 일방적으로 철회할 수 있습니다. 다른 상황에도 동일하게 적용되므로 아래 그림의 "약정 거래 B"와 "약정 거래 C"에 대해서는 더 자세히 설명하지 않습니다.

높은 혼잡 제어

이러한 구조는 사용자가 출금할 때마다 UTXO를 하나만 더 확인하면 되기 때문에 앞서 언급한 추가 처리 수수료 문제를 크게 완화할 수 있습니다.

또한, Alice가 커밋 트랜잭션 A에 대한 자신의 서명을 모든 사람과 공유한다고 가정하면 이 트랜잭션은 다른 사용자에 의해 "제외된 트랜잭션"으로 사용될 수도 있습니다. Alice가 오랫동안 응답하지 않으면 이 공유된 트랜잭션이 팝업으로 표시됩니다. UTXO. 나머지 사용자가 일반 공유 UTXO가 가져올 수 있는 이점을 누릴 수 있도록 하세요. 이는 Alice의 오프라인이 다른 사용자에게 미치는 영향을 제한할 수도 있습니다.

문제는 이 구조에서 사용자가 한 명씩만 대기열에 입장하고 나갈 수 있다는 것입니다. 여러 사용자가 동시에 나가려고 하면 소위 " 경쟁 조건 " 문제가 발생합니다. 이러한 사용자는 수수료를 부과하게 됩니다. 경주, 대기열 순서(먼저 퇴장 자격)를 놓고 경쟁합니다. 여러 사용자가 동시에 종료할 수 있도록 하는 커밋 트랜잭션을 마련하지 않았기 때문에 이러한 커밋 트랜잭션이 있었다면 경합이 발생하지 않았을 것입니다. 예를 들어, Alice가 종료하려고 하는 것이 관찰되면 Bob은 세 사람이 동시에 종료할 수 있도록 준비된 커밋 트랜잭션을 사용할 수 있으며, RBF 방법을 사용하여 이 트랜잭션에 Alice의 트랜잭션보다 높은 확인 우선순위를 부여할 수 있습니다(이것은 좋은 점은 Alice가 먼저 종료하고 스스로 거래를 시작하기를 기다리는 것보다 저렴합니다. Bob의 거래가 확인되면 세 사람이 동시에 종료할 수 있습니다.

언뜻 보면 여러 사람이 동시에 종료할 수 있도록 이러한 커밋 트랜잭션을 추가해야 한다는 데에는 의심의 여지가 없는 것 같습니다. 그러나 동시에 "공유 UTXO"의 개념은 우리에게 그 경이로움을 보여주기 시작할 것입니다. 위의 단순한 혼잡 제어 구조와 비교하여 개선된 구조에는 초기화 중에 사용자 서명이 필요한 커밋된 트랜잭션 수가 크게 증가합니다. 즉, 사용자 간 상호 작용에 대한 수요가 대량 증가했습니다. 또한 사용자 수에 따라 선형적으로 증가하지 않고 여러 사람을 허용하는 이러한 커밋 거래가 추가되면 소위 "결합 폭발"이 발생합니다. 동시에 나가려면 나가는 횟수가 더 많아질 가능성이 더욱 폭발합니다(3명이 너무 적어서 이것이 확실하지 않다면 독자는 5명이 공유하는 UTXO를 그려볼 수 있습니다).

사용자가 그렇게 많은 상호작용을 완료하려면 어떤 종류의 의사소통 수단이 필요합니까? (물론 인터넷이기 때문에 문제는 이 사용자들이 서로를 어떻게 찾느냐 하는 것입니다.) 초기화 중에 사용자의 연락이 끊어지면 초기화가 완전히 실패하고 처음부터 다시 시작해야 할 가능성이 있다는 점을 고려하면, Sybil어택 반대 메커니즘을 사용할 수 있나요? 이것들은 모두 고려해야 할 문제입니다.

그렇다면 어떤 종류의 황금률이 있습니까?

트리 구조

다음 공유 UTXO를 고려하십시오. Alice가 철회를 원하거나 다른 사람이 Alice를 제외하기를 원할 때 Alice는 공유 UTXO에서 직접 팝업할 수 없지만 원래 공유 UTXO를 대체할 "Commitment Transaction 01"을 먼저 브로드캐스트해야 합니다. UTXO는 두 개의 공유 UTXO로 반으로 분할된 후 Alice는 다음 커밋 트랜잭션을 브로드캐스트하고 자신이 속한 공유 UTXO를 계속 분할....계속해서 vTXO가 종료될 때까지 계속됩니다.

(이 분야에 익숙한 독자라면 아마도 "이건 트리 구조다!"라고 퉁명스럽게 대답할 것입니다. 예, 그렇습니다.)

나무 공유

출구 공정성 측면에서 이 구조는 이전 섹션에서 설명한 것만큼 좋지 않습니다. Alice가 출구 순서에 따라 거의 항상 1개 이상의 UTXO를 확인해야 합니다. 우리의 예에서 그녀가 먼저 나가면 2개의 추가 UTXO를 확인해야 합니다. 8명이 공유한 UTXO라면 추가로 3개의 UTXO를 확인해야 합니다.

그러나 위 그림을 주의 깊게 살펴보면 특히 매개변수 수가 많은 경우 큰 이점을 찾을 수 있습니다.

(1) 서명해야 하는 커밋된 트랜잭션 수가 크게 감소합니다(이 구조에서는 한 명의 사용자가 더 서명해야 하지만 서명해야 하는 커밋된 트랜잭션의 수가 이전 구조보다 적습니다). 이는 여러 사용자 때문입니다. 종료하기 위해 동일한 커밋 트랜잭션을 공유할 수 있습니다.

(2) 공유 UTXO가 분할될 때마다 액세스가 허용되는 UTXO가 하나 더 생기기 때문에 앞서 언급한 상태 경합 문제도 부분적으로 완화됩니다. 즉, 원래 다른 지점에 있던 사용자 작업이 하나 더 늘어나게 됩니다. Alice와 Carol이 모두 종료한다고 가정하면 "Commitment Transaction 01"이 확인된 후 서로 영향을 주지 않고 병렬로 작동할 수 있습니다.

(3) 또한 오프체인 업데이트 메커니즘의 작동이 더 쉬워집니다(가능한 경우). Alice가 오프라인이라고 가정하면 앞서 언급한 단순 차단 제어 구조에서 오프체인 업데이트 메커니즘도 위에서 언급한 개선된 구조에서 중지됩니다. 하지만 다른 사람들은 원래 Alice가 포함되지 않은 커밋 트랜잭션을 업데이트할 수 있습니다. 이 구조에서는 커미트 트랜잭션 수가 크게 줄어들고 Alice가 포함되지 않은 커미트 트랜잭션을 쉽게 찾아 분석할 수 있으므로 업데이트하기가 어렵습니다. 당연히 오프체인 업데이트 메커니즘을 설계하기가 더 쉽습니다.

요약하자면, 이 섹션에서는 공유된 UTXO 내부 상태 표현이 실용성과 사용자 경험에 미치는 영향을 분석했습니다. 이 세 가지 표현은 가칭 "비드 구조", "성-달 구조", "트리 구조"라고 할 수 있다. 이 세 가지 구조가 원래 어떻게 제안되었는지는 알 수 없지만, 이러한 구조에 대해 생각해 본 개발자가 많을 것이라고 생각합니다.

이러한 분석을 통해 우리는 공유 UTXO가 수명주기 동안 직면할 수 있는 많은 문제에 대해서도 배웠습니다.

다음으로 vTXO 유형의 영향을 추가로 분석합니다.

코인 대 라이트닝 채널

공유 UTXO의 다음 형태를 살펴보면, "혼잡 제어" 구조와 특징적으로 어떻게 다른가요?

채널 팩토리 프로토

예, 혼잡 제어와 정확히 동일한 상태 표현 구조를 사용하지만, 이러한 vTXO는 독점적으로 제어되는 코인이 아니라 라이트닝 채널이기 때문에 이 공유 UTXO가 오프체인 업데이트 메커니즘을 구현하지 않더라도(허용될 수 없습니다.) vTXO 간의 자금 이체)는 서로 간에 라이트닝 채널을 열었기 때문에 이러한 사용자가 서로 지불하는 능력에 영향을 미치지 않습니다! 그들은 서로에게 지불하거나 공유 채널의 상대방을 사용하여 라이트닝 지불을 시작하고 받을 수 있습니다. 그들이 할 수 없는 유일한 일은 이 공유 UTXO에서 채널 크기를 조정하는 것입니다. 이를 위해서는 공유 UTXO와 유사한 온체인 트랜잭션을 시작해야 합니다.

이 예는 vTXO 유형이 공유 UTXO의 사용자 경험에 미치는 영향을 보여줍니다. 또한 상태 표현 구조가 변경되지 않더라도 다른 측면에서 사용자 경험이 향상될 수 있음을 보여줍니다. 물론 이를 위해서는 초기화 단계에서 사용자가 서명해야 하는 커밋된 트랜잭션의 수를 늘려야 합니다.

실제로 위 그림은 잘 알려진 공유 UTXO 디자인인 채널 팩토리에서 영감을 받았습니다. 채널 팩토리와는 달리 여기서는 오프체인 업데이트 메커니즘이 없다고 가정합니다(채널 팩토리는 있지만 최소한 그런 것으로 가정합니다). 그러한 메커니즘이 있다면 이 세 명의 사용자는 온체인 트랜잭션을 시작하지 않고도 서로 간의 채널 크기를 조정할 수 있으며 이는 분명한 용도가 있습니다.

다자간 오프체인 업데이트 메커니즘

오프체인 업데이트 메커니즘은 공유 UTXO의 유용성을 크게 높일 수 있습니다. vTXO가 독점적으로 통제되는 자금인 경우, 오프체인 업데이트 메커니즘을 통해 vTXO가 라이트닝 채널인 경우 이러한 사용자가 서로 지불할 수 있으며, 오프체인 업데이트 메커니즘을 통해 이러한 채널을 조정할 수 있습니다. 그들의 크기.

그러나 오프체인 업데이트라 하더라도 변경된 상태에 의해 영향을 받는 모든 참가자가 있어야 사용할 수 있습니다(그렇지 않으면 안전하지 않습니다). 따라서 적절한 상태 표현 구조는 그 작동을 용이하게 합니다.

마지막으로, 오프체인 업데이트 메커니즘은 특정 조건에서 라이트닝 채널 vTXO와 동일한 효과를 가질 수 있지만 이것이 vTXO 유형 분류가 중복된다는 의미는 아니며 오프체인 업데이트 메커니즘을 고려해야 한다는 의미도 아닙니다. 독립적인 요소로서 중복됩니다. 분석 편의성과 완전성 모두 두 가지 독립적인 요소로 식별되어야 합니다.

다음으로, 다양한 다자간 오프체인 업데이트 메커니즘을 소개하겠습니다. (기술적인 세부 사항에 관심이 없다면 다음 장으로 바로 건너뛸 수 있습니다.)

라이트닝 채널에서 오프체인 상태 업데이트 메커니즘은 커밋 트랜잭션의 출력에 특수 장치를 설치하여 구현됩니다. 상태가 업데이트되고 새로운 커밋 트랜잭션이 교환될 때마다 양 당사자는 이전 커밋을 사용합니다. 비밀 거래의 가치는 상대방에게 부여됩니다. 한 당사자가 이러한 오래된 커밋 거래를 방송하면 상대방은 해당 비밀 값을 사용하여 사기(또는 부주의) 당사자에게 속한 출력 값을 선제적으로 빼앗을 수 있습니다. 이는 양 당사자가 오래된 커밋된 트랜잭션을 브로드캐스트하는 것을 방지하는 페널티 메커니즘을 구현합니다.

이러한 메커니즘은 다자간 오프체인 업데이트 메커니즘으로 확장하기가 매우 어렵습니다. 구체적으로, 한 당사자가 오래된 상태를 제출하면 해당 당사자는 실제로 처벌을 받을 수 있지만 다른 당사자도 이전 상태로 롤백되어 최신 상태에 따라 즉시 자금을 나눌 수 없습니다. 해결책은 창 기간 내에 업데이트된 상태를 나타내는 커밋 트랜잭션이 이전 상태를 나타내는 모든 커밋 트랜잭션을 소비할 수 있도록 만들어 자금이 항상 최신 상태에 따라 분할되고 페널티가 적용될 수 있도록 하는 것입니다. 문제는 이로 인해 단일 업데이트를 위해 서명해야 하는 커밋된 트랜잭션 수가 발생한 상태 업데이트 수에 따라 증가하고 저장해야 하는 커밋된 트랜잭션 수가 단계적으로 증가한다는 것입니다. . 아래와 같이:

在第2 次更新状态时：共享UTXO --> 承诺交易#0 --> 承诺交易#01 --> 承诺交易#012共享UTXO --> 承诺交易#1 --> 承诺交易#12共享UTXO --> 承诺交易#2注1：承诺交易#0 表达的是初始状态。注2：纵向同一位置的承诺交易表达的是相同的状态。

이런 방식으로 상태 업데이트의 보안은 보장되지만 참가자의 상호 작용 및 저장 부담은 매우 큽니다. 또한 사용자가 이전 커밋 트랜잭션을 체인에 브로드캐스트하면 최신 상태 결제 채널을 사용하기 위해 전체 트랜잭션 체인이 온체인 에서 확인되어야 합니다(예를 들어 Alice는 트랜잭션 #0을 체인에 커밋하고 다른 사람들은 #01 및 #012를 체인에 계속 브로드캐스트합니다). 이는 확장성이 거의 없습니다.

그래서 우리는 "엘투"를 원합니다. 이 아이디어는 ^2018년 에 제안되었으며, 이 태그를 사용하여 새로운 SIGHASH 태그(예: ANYPREVOUT, 현재 BIP-118 ^[8] 에 의해 정의됨)를 제안했으며 서명은 트랜잭션의 출력만 지정할 수 있으며 입력은 없습니다. 지정되므로 항상 동일한 스크립트를 사용하여 커밋된 트랜잭션의 nLocktime 필드 값을 증가시킬 수 있으며 이러한 효과를 얻을 수 있습니다. ^[9] : 트랜잭션 체인의 나중에 트랜잭션은 자신의 값을 직접 사용할 수 있습니다. 상위 트랜잭션은 서명 당시 둘 사이에 얼마나 많은 트랜잭션이 있었는지에 관계없이 그 반대는 성립할 수 없습니다. 즉, Alice가 체인에 #0을 넣으면 다른 사람들은 중간 #01을 건너뛰고 #012를 직접 브로드캐스트할 수 있습니다(실제로 이 시점에서는 #012가 더 이상 필요하지 않고 #2만 필요합니다). 이는 참가자의 상호 작용 및 저장 부담을 크게 완화하고 확장성을 절약합니다.

그러나 Eltoo에서는 소프트 포크 통해 SIGHASH_ANYPREVOUT을 활성화해야 하므로 현재 이 메커니즘을 사용할 수 없습니다.

2022년에 John Law는 "Tunable-Panelty 프로토콜"이라는 또 다른 오프체인 업데이트 메커니즘을 제안했습니다 ^[10] .

조정 가능한 패널티

이 메커니즘에서 상태(상대 시간 잠금 포함)를 나타내는 커밋 트랜잭션(CT)은 공유된 UTXO를 입력으로 사용할 뿐만 아니라 다른 양의 UTXO를 공유하기 전에 참가자로부터 추가로 작은 입력(Dust)도 받습니다. 자금. Alice와 같은 참가자가 커밋 트랜잭션을 발행하려고 시도하면 먼저 작은 입력이 확인되어야 합니다. 즉, ST("상태 트랜잭션")가 발행되어야 합니다. 그리고 ST에는 실제로 예금(Stake)이라는 또 다른 출력이 있는데, 이는 상태를 업데이트할 때 참가자가 예금의 개인 키를 제공해야 하기 때문입니다.

최종 결과는 참가자가 이전 커밋 트랜잭션을 발행하려고 시도하는 경우 이전 ST를 먼저 체인에 배치해야 하며 이로 인해 예치금이 인출됩니다. 이때 공유 UTXO는 아직 사용되지 않았습니다. 따라서 모든 사용자가 최신 상태를 사용하는 능력에는 영향을 미치지 않습니다. 마찬가지로, TPP는 공유 UTXO를 분할하기 위한 준비 단계를 설계하여 사기를 저지르려는(또는 부주의한) 사용자가 공유 UTXO를 직접 조작할 수 없도록 하여 앞서 언급한 트랜잭션 체인을 재생해야 하는 문제를 방지합니다.

TPP의 가장 큰 장점은 비트코인의 기본 레이어를 변경할 필요가 없으며 지금 구현할 수 있다는 것입니다.

실제로 시간 잠금을 기반으로 하는 커밋 트랜잭션인 매우 간단한 다자간 업데이트 메커니즘이 있습니다. 이는 양당 채널에 대한 연구에서 탄생했습니다 ^[11] .

타임락-ct

이 메커니즘에서 커밋 트랜잭션 자체에는 트랜잭션 수준의 시간 잠금이 있으며 상태가 업데이트될 때마다 참가자는 더 짧은 시간 잠금으로 커밋 트랜잭션에 서명합니다(그래서 더 빠르게 게시하고 확인할 수 있음). 시간 잠금 자체는 커밋 트랜잭션 충돌 문제를 방지하므로 이러한 충돌 가능성을 처리하기 위한 메커니즘을 추가로 설계할 필요가 없습니다(사용자가 이전 상태를 나타내는 커밋 트랜잭션을 해제함).

이 메커니즘은 구현하기가 너무 간단하고 쉽기 때문에 위의 두 가지 메커니즘을 논의하는 것은 의미가 없어 보입니다. 하지만 그렇지 않습니다. 이 메커니즘의 치명적인 결함은 수명이 분명하다는 것입니다. 특정 횟수의 업데이트 후에는 새로운 공유 UTXO가 정착되고 재설정될 수만 있습니다. 완화할 수는 있지만(예를 들어 완화 방법 중 하나는 공유 UTXO와 최종적으로 상태를 표현하는 커밋 트랜잭션 사이에 여러 개의 중간 트랜잭션을 삽입하여 상대 시간 잠금을 곱하는 것임) 근본적으로 해결할 수는 없습니다.

주제 외: UTXO 공유와 관련된 제한 제안

공유 UTXO는 제한적인 용어를 구현하는 다양한 소프트 포크 제안과 관련하여 자주 논의되지만 지금까지는 거의 언급하지 않았습니다. 그 이유는 이러한 제안된 제한 사항이 공유 UTXO의 운영을 지원하는 데 사용될 수 있지만 공유 UTXO의 기본 특성을 결정하지는 않으며 공유 UTXO의 기본 특성을 이해해야만 이러한 제한의 역할을 이해할 수 있기 때문입니다. 시나리오.그것의 용도는 무엇입니까?

여기서는 OP_TLUV ^[12] , OP_CTV ^[13] 및 OP_EVICT ^[14] 의 세 가지 제안을 간략하게 분석합니다.

앞서 언급했듯이 공유 UTXO를 구성할 때 대량 의 상호 작용(보안을 보장하기 위해 대량 의 약정 트랜잭션에 서명)이 필요하므로 실용성과 사용자 경험이 저해됩니다. 이와 관련하여 OP_TLUV의 솔루션은 Taproot의 Merkle 스크립트 트리 구조를 사용하여 사용자의 상태를 스크립트 트리의 잎에 커밋하는 것입니다. 사용자가 일방적으로 종료해야 하는 경우 이 리프를 공개하고 여기에 기록된 자금 금액으로 종료할 수 있습니다. TLUV는 자금 금액을 확인하고 남은 자금이 더 이상 종료를 허용하지 않는 새로운 탭루트 출력으로 이체되도록 보장합니다. . 사용자가 참여했습니다. 그의 공개 키는 탭루트 내부 공개 키에서 제거되었으며 그의 스크립트는 머클 트리에서 제거되었습니다.

Merkle 스크립트 트리 자체는 사용자의 자금 상태를 커밋할 수 있으므로 사용자는 초기화 및 상호 작용 프로세스 중에 탭루트에 의해 출력되는 내부 공개 키 및 스크립트 트리 구성을 완전히 확인하면 됩니다. 이는 상호 작용 요구 사항을 크게 줄여줍니다.

이 분야의 다른 프로토콜 설계에 익숙한 독자라면 다음과 같이 말할 수 있습니다. 이것이 상태 모델 하의 일반적인 "상태 트리" 설계가 아닌가요? 네, 바로 그거예요. 그러나 이전 구조 분류에 따르면 이 디자인은 트리 구조가 아닌 별-달 구조로 분류되어야 합니다. 이는 공유 UTXO를 반으로 분할할 때마다 단일 사용자가 직접 종료하고 다른 사용자에게 영향을 주지 않는 상태로 남겨두는 것입니다. 이에 따라 OP_TLUV를 사용하는 트리 구조를 상상할 수도 있습니다. 스크립트 트리는 참가자 자금의 절반과 전체 공개 키에 할당됩니다.

우연히도 OP_CTV를 사용하여 이 디자인을 지원할 수도 있습니다. 왜냐하면 OP_CTV를 사용하면 출력량 및 스크립트를 포함하여 특정 특성을 가진 트랜잭션에서만 스크립트를 사용하도록 할 수 있기 때문입니다. 따라서 우리는 사용자의 출금 거래를 Merkel 스크립트 트리의 리프에 커밋하여 사용자가 일방적으로 사용할 수 있도록 할 수도 있습니다. 어쨌든 사용 결과는 그의 자금이 출금되고 나머지 자금은 UTXO에 들어가게 됩니다. 또한 적절한 내부 공개 키와 Merkle 스크립트 트리를 사용하여 철회되었으며, 나머지 사용자는 일방적으로 종료할 수 있습니다.

OP_TLUV와 비교하여 OP_CTV를 사용하는 경우 사용자는 더 많은 사항을 확인해야 하지만(각 인출 단계에서 남은 자금이 올바른 스크립트 트리에 전달되는지 확인해야 함) 약정 거래에 서명할 필요도 없습니다( 검증된 수량은 약정 거래만 사용한 경우와 동일합니다.)

OP_EVICT의 아이디어는 다른 접근 방식을 취하는 것입니다. OP_EVICT의 저자인 ZmnSCPxj는 OP_TLUV를 사용하는 star-moon 구조에서 트랜잭션을 종료하려면 자체 리프의 Merkle 트리 경로를 공개해야 하는 반면, 트리 구조를 사용하려면 Merkel 트리 경로와 유사한 여러 트랜잭션도 공개해야 한다는 점에 주목했습니다. . 이러한 오버헤드를 피할 수 있는 방법이 있나요?

OP_EVICT의 아이디어는 사용자가 출력(공개 키 및 금액)에 직접 서명할 수 있도록 하고, 이러한 서명을 OP_EVICT 작업 코드로 이해할 수 있도록 만들고 현재 거래 출력이 서명된 출력과 일치하는지 확인하는 데 사용됩니다. 서명과 해당 출력을 확인한 후 OP_EVICT는 탭루트 내부 공개 키에서 서명 공개 키를 빼고 트랜잭션에 서명하려면 나머지 공개 키가 필요합니다. 이런 방식으로 참여자의 구성을 커밋하는 탭루트 자체의 내부 공개 키와 동일하며, 참가자의 자금은 머클 트리에 의해 커밋될 필요가 없으며 공개 키 자체의 서명만 있으면 됩니다. 다른 사용자의 서명 출력) 보호합니다.

OP_EVICT에는 또한 여러 사용자가 동시에 로그아웃할 수 있다는 큰 장점이 있습니다. 따라서 경쟁 진입 문제 없이 스타-문 구조를 구현할 수 있다. (정확하게 말하면 OP_EVICT의 사고 방식이 다릅니다. 사용자가 일방적으로 탈퇴할 필요가 거의 없다고 가정합니다. 반대로 한(일부) 사용자가 오프라인이고 다른 사용자가 공유된 UTXO를 사용할 수 없다는 것이 해결하기 어려운 문제입니다. 따라서 오프라인 사용자를 효율적으로 제외할 수 있는 도구가 필요하며, 오프라인 사용자를 제외시킨 후 나머지 사용자는 협력을 통해 자신의 상태를 업데이트할 수 있습니다. 따라서 사용자 자체 종료는 이 opcode의 "정상적인" 사용이 아닙니다. .)

이전 두 가지에 비해 상태를 커밋하는 명시적인 방법이 없기 때문에 사용자 간의 상호 작용이 더 많이 필요하지만 커밋 트랜잭션만 사용하는 경우보다 훨씬 적습니다.

요약하면 공유 UTXO 시나리오에서 제약 조건 opcode의 주요 용도는 상호 작용 요구 사항을 줄이는 것입니다. 이는 특정 상태 표현 구조의 실행 오버헤드를 줄일 수 있지만 어떤 구조를 사용할 수 있는지 결정하지는 않습니다. 구조에 대한 연구는 제한 조항의 출현으로 인해 그 의미를 잃지 않을 것입니다.

UTXO 디자인 사례 공유

다자간 채널

다중 사용자 채널-1

위 그림에서 볼 수 있듯이 이는 오프체인 업데이트 메커니즘을 갖춘 혼잡 제어 UTXO입니다(vTXO는 코인과 오프체인 업데이트 메커니즘을 갖춘 비드 구조입니다).

때로는 아래 그림의 구조도 다자간 채널로 간주되기도 합니다.

다중 사용자 채널-1

분산형 라이트닝 채널(그리고 아래에서 소개할 계층형 채널)과 비교했을 때, 다자간 채널의 장점은 "수취 할당량(계산된 유동성)"으로 인한 문제가 적다는 것입니다. 단점은 오프라인 사용자의 영향력에 저항하기가 더 어렵다는 것입니다.

계층화된 채널

"계층적 채널"은 2023년 John Law가 제안한 아이디어입니다 ^[15] . 트리 구조를 사용하며 vTXO는 라이트닝 채널입니다. 동시에 저자는 TPP를 오프체인 업데이트 메커니즘으로 사용할 것을 제안합니다.

계층적 채널

채널 팩토리

채널 팩토리는 비드 구조를 사용하고, vTXO는 라이트닝 채널(UTXO를 공유하는 모든 두 사용자 사이에 라이트닝 채널이 있음)이며, 시간 잠금 감소 커밋 트랜잭션이 오프체인 업데이트 메커니즘으로 사용됩니다.

상태체인

“Statechain” ^[16] 의 기본 아이디어는 UTXO를 제어하는 개인 키를 전송함으로써 온체인 거래 없이도 UTXO를 완전히 전송할 수 있다는 것입니다. 이러한 전송을 용이하게 하기 위해 두 당사자(사용자와 서비스 제공자)는 공개 키를 공동으로 생성하고(양 당사자는 공개 키 뒤에 개인 키의 절반만 보유) 이 공개 키에 자금을 입금해야 합니다(보장하기 위해). 무신뢰 출금의 경우 시간 잠금이 포함된 약정 거래에 사전 서명해야 합니다.) 지불 시 지불인 및/또는 서비스 제공자는 먼저 수신자에게 UTXO 오프체인 소유권의 전송 내역을 보여줍니다. 그런 다음 자금을 지불합니다. 수신자는 지불 의사를 표현하기 위해 서명을 전달하고 서비스 제공자와 협력하여 새로운 개인 키 조각을 생성하고 더 짧은 시간 잠금으로 새로운 약정 거래에 서명합니다. 완전한.

공유 UTXO로 표현하면 시간 잠금 감소 커밋 트랜잭션을 사용하여 상태를 업데이트하는 비드 구조입니다. 그러나 이 공유 UTXO에는 vTXO가 하나만 있으며 vTXO 보유자는 한 번 지불하면 자신의 vTXO를 분할할 수 없습니다. 전체 vTXO를 전송해야 합니다. vTXO의 법적 보유자는 언제든지 단 한 명뿐입니다. 또한 온체인 트랜잭션을 사용하지 않고 새로운 사용자를 소개하려면 사용자는 서비스 제공자가 vTXO와 상호 작용하지 않을 것이라는 점을 신뢰해야 합니다. 사용자 공모(공유 UTXO 개인 키의 유효한 서명을 생성하고 돈을 이체하기 위해 공모할 수 있음) - 이것이 가장 큰 단점이며 사용자가 지불을 받을 때 추가 인증을 수행해야 하는 이유입니다.

사용자가 모든 자금을 한 번에 이체하는 대신 보다 세분화된 결제를 활성화하려는 경우 vTXO를 라이트닝 채널로 이체하고 라이트닝 채널 내에서 결제를 보낼 수 있습니다. ^{[17 ]} .

ARK 및 ARK v2

“ARK” ^[18] 는 오프체인 업데이트 메커니즘이 없는 평면 구조입니다. 그렇다면 "혼잡 제어"와 차이점은 무엇입니까? 그 이유는 vTXO가 순수 코인이 아니기 때문입니다(그러나 라이트닝 채널도 아닙니다). 스크립트 내용 측면에서는 "단방향 채널"에 가깝습니다. 이 단방향 채널에는 두 가지 지출 경로가 있습니다. 하나는 두 참가자의 다중 서명이고 다른 하나는 시간 잠금이 있는 사용자의 단일 서명입니다. 후자는 이 단방향 채널에서 자금의 최종 소유권을 나타내는 데 사용될 수 있으며 특정 참가자에게 조치를 취하도록 촉구하는 데에도 사용될 수 있습니다. 전자는 시간 잠금이 만료되기 전에 다중 서명 장치가 지원하는 기능을 활성화합니다. 아래 단방향 채널을 설명할 때 Timelock 분기를 먼저 사용할 수 있는 행위자를 나열하겠습니다.

ARK에서 사용자의 vTXO는 ARK 서비스 제공자와 사용자 간의 단방향 채널입니다. 사용자의 vTXO는 특별 약정 거래(Redeem TX)를 통해 사용자와 ARK 서비스 제공자 간의 단방향 채널에 자금을 주입합니다.

이 디자인은 "비대화형 원자 코인조인 결제"를 지원하는 데 사용됩니다. Alice가 David에게 비용을 지불하려고 할 때 서비스 제공업체(Alice-Server 코인)와의 단방향 채널을 사용하여 신뢰할 수 있는 약속을 표현할 수 있습니다. 당신이 David에게 돈을 지불하면 내 돈은 당신 것입니다. 그러나 당신이 특정 시간 내에 그것을 지불하지 않으면 나는 내 돈을 가져갈 것입니다. 이는 공유 UTXO로서 Alice의 동의 없이는 ARK를 사용할 수 없기 때문에 실제로 가능합니다. 따라서 서비스 제공자가 서비스를 제공하지 않는 경우, 앨리스는 항상 CT를 발행하고 TX#A를 Redeem한 후 Alice-Server 코인으로 돈을 인출할 수 있습니다.

이에 따라 서비스 제공자는 Alice가 청구서를 불이행할 것을 걱정하지 않습니다. 왜냐하면 TA가 David에게 비용을 지불하면 그는 항상 Alice-Server 코인에 대한 확인을 요청할 수 있고 그런 다음 Alice가 제공한 약정 거래를 사용하여 돈을 인출할 수 있기 때문입니다.

궁극적으로 이상적인 상황은 양측이 협력하는 것입니다. 서비스 제공자는 David와 협력하고 Alice는 서비스 제공자와 협력하여 온체인 ARK의 상태를 변경하는 데 동의합니다. 이 과정에서 Alice는 David에게 직접 지불하지 않았습니다. David가 온체인 지불을 받았다면 외부 관찰자는 ARK에서 그에게 지불한 사람이 누구인지 알 수 없습니다(Alice의 동료만 알 수 있음). 그리고 David도 지불을 받기 위해 다른 ARK를 사용하는 경우 그러면 이 ARK에 있는 Alice의 동료조차도 돈이 누구에게 주어졌는지 알 수 없습니다(이 동료가 두 ARK에 모두 관여하지 않는 한).

또한 여기의 단방향 채널은 이론적으로 세분화된 결제를 지원하지만 ARK는 이 기능을 지원하지 않습니다. 스테이트체인과 마찬가지로 자금은 완전히 이체됩니다.

ARK v2는 기본적으로 동일한 구조를 따르지만 ^[19] 서비스 제공업체가 자금을 보다 효율적으로 회수할 수 있도록 하는 일부 설계를 가능하게 합니다(또한 taproot의 Merkle 스크립트 트리에 의존함). 그러나 공유 UTXO의 구조 측면에서는 두 버전이 기본적으로 동일합니다. 게다가 ARK는 제한 조항 없이도 작동할 수 있지만 ARK v2는 명시적으로 제한 조항에 의존합니다.

공유된 UTXO에 대한 감사와 비판

CoinPool 기사는 공유 UTXO를 연구하는 두 가지 동기를 잘 설명하고 있으며, 이는 UTXO 공유가 사람들에게 가져올 것으로 예상되는 이점이기도 합니다.

은둔. 많은 사람들이 UTXO를 공유하면 결제 개시자가 온체인 숨겨질 수 있으며, 수신자가 공유 UTXO를 사용하는 경우 수신자도 숨겨질 수 있습니다. ARK는 이러한 방향을 수용하는 상징입니다.
확장성. 온체인 UTXO(온체인 상태)의 수를 줄이고 블록 공간에 대한 수요를 줄일 수 있습니다(예를 들어 공유 UTXO 내에서 오프체인 업데이트 메커니즘을 사용하여 서로 비용을 지불할 수 있습니다). 이와 관련하여 담당자는 채널 팩토리에 속해야 합니다.

이 개념에 대한 비판은 주로 실용성 측면에서 이루어집니다. 사용자 수가 증가하면 모든 사용자가 온라인 상태가 되는 경우가 매우 드물기 때문에 상태가 정체되어 업데이트할 수 없는 경우가 많다고 생각됩니다. 그것은 일종의 취약성과 가용성입니다. Peter Todd의 더욱 날카로운 또 다른 비판이 있습니다. 우리는 이 메커니즘이 비트코인의 처리 능력을 확장하는 데 사용될 것이라고 가정합니다. 온체인 의 UTXO와 이를 사용하는 사용자는 실제로 어떤 일이 발생하면 사용자가 적극적으로 체인을 종료하거나 수동적으로 온체인 에 팝업할 것이라고 가정합니다. 어떻게 갑자기 이를 감당할 수 있습니까?

이러한 비판에는 합리적인 답변을 찾기 위해 분명히 더 심층적인 분석이 필요합니다. 적어도 현재로서는 사람들이 몇 가지 이점 때문에 공유 UTXO에 대한 연구를 중단하지는 않을 것입니다. 더욱이 이러한 연구는 이론적(예: TPP)이든 실제적(예: 상태 체인 구현)이든 가치를 창출했습니다.