출처: geek web3
비트코인의 핵심 설계 원칙 중 하나인 UTXO 모델은 처음부터 블록체인 분야에서 중요한 기술 패러다임으로 자리 잡았습니다. 이는 거래 보안과 추적성을 보장하는 동시에 기존 계정 잔고 모델에 대한 대안을 제공하는 데 중요한 역할을 합니다. 최근 몇 년 동안 블록체인 기술이 지속적으로 업데이트되고 반복됨에 따라 UTXO 모델 자체도 진화하고 확장되고 있습니다(예: eUTXO, 셀, 엄격한 접근 목록 등).
이 글에서는 UTXO 모델을 배우고 이해하는 것을 목표로 하며, 이해하기 쉽도록 BTC에서 Sui, Cardano, Nervos, Fuel에 이르기까지 UTXO 모델과 그 구현을 간략하게 살펴볼 것입니다.
UTXO란 무엇인가요?
예시를 통해 UTXO 모델을 이해할 수 있습니다.
앨리스와 밥이라는 두 사람이 있다고 가정해봅시다. 두 사람은 원래 각각 5달러를 가지고 있었습니다. 나중에 갈등이 발생하여 앨리스가 밥에게 2달러를 빼앗겼습니다. 두 사람이 가진 돈은 다음과 같습니다:
앨리스는 3달러, 밥은 7달러가 남았다는 것을 쉽게 알 수 있습니다. 이러한 초등학교 수준의 덧셈과 뺄셈은 은행 시스템에서 자주 볼 수 있으며, 이를 "계좌/잔액 모델"이라고 합니다. 이 모델에서 계좌의 잔액은 하나의 값으로 존재합니다.
계좌 모델과 다른 방식으로 앨리스와 밥 사이에서 발생하는 부의 이전을 표현하면 다음과 같이 도식이 달라집니다.
이미지 src="https://img.jinse.cn/7171398_image3.png">
이 시점에서 앨리스와 밥은 여전히 3달러를 가지고 있습니다. 앨리스에게는 여전히 3달러가 남아 있고 밥에게는 여전히 7달러가 남아 있지만, 7달러가 하나의 값으로 표시되는 것이 아니라 '5달러'와 '2달러'로 나뉘어 표시됩니다. 이런 색다른 방식이 불편하게 느껴지지 않나요? 이것이 바로 UTXO라는 특별한 종류의 부기 방식입니다.
UTXO는 영어로 '미사용 거래 출력'을 뜻하며, "미사용 출력"을 의미합니다. 이 부기 방식에서는 각 온체인 트랜잭션이 UTXO의 변경 및 전송으로 표현됩니다. 예를 들어, 위에서 언급한 트랜잭션 이벤트에서 앨리스가 처음에 입력 파라미터로 소유한 "5달러"는 UXTO_0으로 레이블이 지정되고 이후 소멸되며, 동시에 프로그램은 "2달러"(UTXO_1) 및 "3달러"(UTXO_2)를 출력 파라미터로 생성하고, UTXO_1은 밥에게 전송되고, UTXO_2는 다시 앨리스에게 전송되어 앨리스와 밥 간의 자산 전송이 완료됩니다.
실제로 UTXO 모델에서는 '계정'과 '잔액'이라는 개념이 존재하지 않습니다. "UTXO는 거래가 실행되도록 돕는 데이터 구조일 뿐이며, 금액, 연결된 거래의 인덱스 등과 같은 정보를 기록합니다. 각 UTXO는 정의된 소유자와 함께 사용될 수 있지만 사용되지는 않는 트랜잭션 입력을 나타냅니다. 트랜잭션이 발생하면 특정 UTXO를 입력으로 사용할 수 있으며, 해당 UTXO가 소멸되면 트랜잭션 출력으로 새로운 UTXO가 생성됩니다.
이것이 비트코인의 장부작성 방식입니다. 거래가 발생할 때마다 오래된 UTXO가 소멸되고 새로운 UTXO가 생성됩니다. 소멸된 UTXO의 총량은 새로 생성된 UTXO의 총량과 같습니다(이 중 일부는 채굴자에게 수수료로 지급됨). 이런 식으로 누구도 허공에서 추가 자금을 발행할 수 없습니다.
UTXO 모델과 계정/잔고 모델 비교
대량의 트랜잭션 요청을 동시에 시작하는 사용자가 일괄적으로 존재하고, 트랜잭션이 UTXO 모델과 계정/잔고 모델을 사용하여 개별적으로 처리된다고 가정해봅시다. 계정/잔액 모델을 사용하여 트랜잭션을 처리한다면 어떤 상황이 발생할까요?
계정/잔액 모델에서는 각 사용자가 잔액 정보가 기록되는 계정을 가지고 있습니다. 트랜잭션이 발생하면 해당 계정의 잔액이 업데이트되는데, 여기에는 '읽기'와 '쓰기'가 포함됩니다. 그러나 두 개의 트랜잭션이 동일한 계정과 관련된 경우 읽기와 쓰기 간에 충돌, 즉 상태 경합이 발생하는 경우가 종종 있으며 이는 반드시 피해야 하는 상황입니다.
기존 데이터베이스 시스템은 '잠금' 메커니즘을 통해 데이터의 특정 부분에 대한 읽기 및 쓰기 경합을 해결하는 경향이 있습니다. 이 시나리오에서는 데이터 경합 관계를 구성하는 여러 트랜잭션이 대기열에 포함되어 동시에 실행될 수 없는 경우가 많아 트랜잭션 처리 효율성이 떨어질 수 있습니다. 처리해야 할 트랜잭션이 많을 경우 위와 같은 상황은 심각한 성능 병목 현상으로 이어질 수 있으며, 서로 데이터 경합 관계가 있는 트랜잭션은 장시간 대기 상태가 되어 빠르게 처리되지 못할 수 있습니다.
비트코인의 UTXO 모델은 계정 잔고 모델보다 데이터 경합 문제를 더 잘 해결합니다.
이 모델에서는 각 트랜잭션이 더 이상 '계정'에 의해 직접 처리되는 것이 아니라 개별 UTXO에 의해 처리되고, UTXO가 서로 간섭하지 않기 때문에 비트코인 네트워크의 각 트랜잭션은 서로 간섭하지 않기 때문에 계정 잔액 모델보다 데이터 경합 문제를 더 잘 해결합니다. 그 결과, 비트코인 네트워크 노드는 "잠금" 없이도 대기 중인 많은 트랜잭션을 동시에 처리할 수 있으며, 이는 처리량과 통화 성능을 크게 향상시킵니다.
또한, UTXO 모델 암호화폐 지갑은 일반적으로 사용자가 거래를 시작한 후 새 주소를 생성하기 때문에 프라이버시를 보호할 수 있습니다. -고정 주소를 사용하기 때문에 상관관계 분석이 쉬운 계정/잔고 모델과 달리 거래를 특정인과 연관 짓는 것이 더 어려워집니다.
그러나 원래 복잡한 비즈니스 로직을 처리하는 것이 아니라 간단한 통화 이체를 가능하게 하도록 설계된 UTXO에는 한계가 있습니다. 다중 서명 및 시간 잠금과 같은 일부 간단한 기능 구현은 스크립팅 언어로 수행할 수 있지만, 비트코인의 UTXO가 기록할 수 있는 초보적인 상태 정보는 일부 복잡한 작업을 수행하기에는 부적절합니다.
비트코인 UTXO의 한계는 간접적으로 '이더리움'의 탄생으로 이어졌으며, 비트코인 매거진의 초기 기고자 중 한 명인 비탈릭은 이러한 단점을 잘 알고 있었습니다. 계정/잔고 모델은 대부분의 사람들이 이해하기 쉬울 뿐만 아니라, 그가 이더 백서에서 언급한 것처럼 리치 스테이트 애플리케이션을 다루는 UXTO 딜레마도 해결해줍니다.
UTXO는 사용하거나 사용하지 않을 수 있으며, 다른 내부 상태를 저장하기 위한 다단계 컨트랙트나 스크립트가 존재하지 않습니다. 따라서 다단계 옵션 계약, 탈중앙화된 거래 시세 또는 2단계 암호화 약정 프로토콜(바운티를 안전하게 계산하는 데 필요한)을 만들기가 어렵습니다. 또한, 탈중앙화 조직과 같은 복잡한 '상태 저장' 계약이 아닌 단순한 일회성 계약 구축에만 UTXO를 사용할 수 있어 메타 프로토콜을 구현하기가 어렵다는 의미이기도 합니다. 가치 맹목성과 결합된 이진 상태는 또 다른 중요한 애플리케이션인 출금 한도를 구현할 수 없음을 의미합니다.
UXTO 모델의 적용, 최적화 및 확장
UXTO의 다양한 적용과 최적화에 대해 다루기 전에, UXTO의 장점을 유지하면서 어떤 개선점이 있는지 분석해볼 필요가 있습니다. 다음과 같이 간략하게 요약할 수 있는 개선 사항은 다음과 같습니다.
1. UTXO가 저장하는 상태의 의미 추상화.
2. 상태 소유권의 추상화.
3. 공유 UTXO의 상태 경합 문제 해결.
BTC에서 상태의 유일한 의미는 토큰의 수이며 소유권은 일반적으로 공개 키로 정의됩니다. 상태 경합의 경우 BTC는 디앱을 위해 설계되지 않았기 때문에 이를 많이 다루지 않습니다.
수이
수이는 개발자에게 두 가지 유형의 오브젝트를 제공합니다: UTXO(또는 더 구체적으로 UTXO)에 해당하는 소유된 오브젝트와 공유된 오브젝트(SharedObject). 전자는 UTXO(보다 구체적으로는 UTXO의 향상된 버전)에 해당하고 후자는 계정/잔고 모델에 해당하며, 두 가지를 동시에 사용할 수 있습니다.
Sui 기술 문서에 설명된 대로 객체를 공유할 수 있으므로 변경 가능한 소유 객체(작성자 한 명만 있을 수 있는)와 달리 누구나 객체를 읽거나 쓸 수 있습니다. 공유 오브젝트는 읽기 및 쓰기 순서를 정하기 위해 합의가 필요합니다.
다른 블록체인에서는 모든 객체가 공유됩니다. 그러나 Sui 프로그래머는 특정 사용 사례를 구현하기 위해 소유 오브젝트, 공유 오브젝트 또는 이 둘을 조합하여 사용할 수 있습니다. 이러한 선택은 성능, 보안 및 구현 복잡성에 영향을 미칠 수 있습니다.
Sui에서 소유 오브젝트는 소유자인 소유자만 조작할 수 있고, 오브젝트에는 버전 번호가 지정되어 "특정 버전의 오브젝트는 소유자가 한 번만 사용할 수 있다"는 점에서 UTXO와 유사합니다.
카르다노
카르다노는 eUTXO라고 하는 확장 UTXO 모델을 사용하며, eUTXO는 더 높은 수준의 eUTXO는 더 높은 수준의 프로그래밍을 지원하며 비트코인 UTXO 모델의 장점을 가지고 있습니다.
카다노에서는 스크립팅을 통해 상태의 의미가 더욱 확장되고, 상태 경합을 최소화하기 위해 UTXO 세트를 사용하여 상태의 소유권이 보다 일반적인 방식으로 정의됩니다. 요약하면, eUTXO는 두 가지 방식으로 개선되었습니다.
1. eUTXO 모델에는 더 일반적인 주소가 있으며, 이는 공개 키의 해시뿐만 아니라 eUTXO가 사용될 수 있는 조건을 정의하는 임의의 논리를 기반으로 상태 소유권을 프로그래밍할 수 있습니다.
2. 주소와 값 외에도 출력은 (거의) 임의의 데이터를 전달할 수 있습니다. 즉, 스크립트를 통해 상태의 의미를 프로그래밍할 수 있습니다.
특히, eUTXO를 사용하면 사용자가 임의의 데이터를 Datum이라는 JSON과 유사한 형식으로 UTXO에 추가할 수 있습니다. Datum을 사용하면 개발자가 스크립트에 비슷한 형식의 데이터를 제공할 수 있습니다. 개발자는 Datum을 사용하여 특정 UTXO와 연관된 상태와 유사한 기능을 스크립트에 제공할 수 있습니다.
동시에, 카르다노의 트랜잭션은 리디머라고 하는 특정 사용자와 연관된 매개변수를 전달할 수 있습니다. 리디머는 트랜잭션의 개시자가 UTXO의 사용 방법을 정의할 수 있게 해줍니다. 디앱 개발자가 다양한 목적으로 사용할 수 있습니다.
트랜잭션이 검증될 때 검증 스크립트는 데이터텀, 리디머, 트랜잭션 데이터가 포함된 컨텍스트와 함께 작동하며, 해당 스크립트에는 조건이 충족될 때 UTXO를 사용하는 로직이 포함됩니다.
eUTXO는 여전히 스크립트화된 확장이며, 기존의 "스마트 컨트랙트"(설립자 찰스 호스킨슨은 실제로는 "프로그래밍 가능한 검증자"라고 불러야 한다고 생각합니다)와는 매우 다르다는 점을 알아두는 것이 중요합니다. "), "스마트 컨트랙트"라는 용어가 시장에서 더 쉽게 받아들여지고 있습니다.
Nervos
Nervos(즉, CKB)에서 상태의 의미는 타입스크립트로 추상화되고, 상태의 소유권은 락스크립트로 추상화됩니다. 락스크립트 추상화, 간단한 UTXO 최적화 모델 - 셀 코드는 다음과 같습니다.
pub 구조체 CellOutput {
 . pub capacity: Capacity,
pub data: Vec<u8>,
pub lock: Script,
 .
그리고 상태 경합 문제에 대해 현재 CKB 푸시 연구는 오픈 트랜잭션이며, 사용자가 트랜잭션의 목적을 지정하는 UTXO의 일부를 제시할 수 있습니다.
Nervos의 셀 모델은 UTXO의 "일반화된" 버전이며, 이에 대한 자세한 설명은 Nervos 포럼에서 Jan이 설명합니다.
레이어 1은 상태에 관한 것이므로 레이어 1을 염두에 두고 설계된 CKB 설계가 상태에 관한 것이어야 하는 것은 당연합니다. 이더리움은 트랜잭션 기록과 상태 기록을 두 가지 차원으로 나누고 블록과 트랜잭션은 상태 자체보다는 상태 이동을 유발하는 이벤트를 표현하는 반면, 비트코인 프로토콜은 트랜잭션과 상태를 하나의 차원으로 결합하여 트랜잭션이 상태이고 상태가 트랜잭션인 상태 중심 아키텍처라고 할 수 있습니다.
동시에 CKB가 장기적으로 검증하고 보존하고자 하는 상태는 단순한 숫자(nValue)가 아니라 사람들이 가치 있다고 생각하는 모든 합의 데이터입니다. 물론 비트코인의 트랜잭션 출력 구조가 이러한 요구를 충족시키지는 못하지만, 정수를 저장하는 공간에서 임의의 데이터를 저장할 수 있는 공간으로 nValue를 일반화하면 훨씬 더 일반적인 "CTxOut"을 얻을 수 있다는 점에서 충분한 영감을 얻었습니다.
셀 내부에서 nValue는 용량과 데이터가 되어 저장 공간의 일부를 나타냅니다. 용량은 공간의 크기(바이트 단위)를 나타내는 정수이고, 데이터는 상태가 저장되는 곳으로, 어떤 바이트도 쓸 수 있습니다; scriptPubKey는 합의 공간을 소유한 사람을 나타내는 다른 이름을 가진 잠금이 되며, 잠금 스크립트가 성공적으로 실행되도록 매개변수(예: 서명)를 제공할 수 있는 사람만이 셀의 상태를 "업데이트"할 수 있습니다. 전체 셀아웃풋은 용량보다 작거나 같아야 하며, CKB에는 많은 셀이 존재하고, 이 셀의 집합이 CKB의 완전한 현재 상태를 형성하며, 현재 상태는 더 이상 디지털 화폐가 아닌 임의의 일반 지식을 저장합니다.
트랜잭션은 여전히 상태의 변경/이동을 나타냅니다. 상태 변경, 즉 셀 콘텐츠의 '업데이트'는 실제로는 파괴와 생성을 통해 이루어집니다(원래 셀의 콘텐츠를 실제로 수정하는 것은 아님). 각 트랜잭션은 셀의 배치를 파괴하고 새로운 셀 배치를 생성하며, 새로 생성된 셀은 새로운 소유자를 갖게 되고 새로운 데이터를 보유하게 되지만, 파괴된 용량의 합계는 항상 생성된 용량의 합계보다 크므로 용량은 양도할 수 있고 추가할 수 없기 때문에 누구도 용량을 더 추가할 수 없게 됩니다. 용량은 발행이 아닌 양도할 수 있으며, 용량을 소유하는 것은 해당 양의 합의 상태 공간을 소유하는 것과 동일하며, 용량은 CKB 네트워크의 기본 자산입니다. 셀을 파괴하면 비트코인의 UTXO와 유사하게 미사용에서 사용으로 "파괴됨"으로만 표시되며, 블록체인에서 삭제되지 않습니다. 셀은 한 번만 파괴할 수 있습니다. 각 셀은 한 번만 파괴할 수 있으며, 각 UTXO는 한 번만 소비할 수 있습니다.
이러한 모델의 특징은 다음과 같습니다.
1. 상태가 우선입니다.
2. 소유자는 스테이트의 속성이며, 스테이트의 복사본당 소유자는 한 명뿐입니다.
3. 상태는 끊임없이 소멸하고 생성된다.
그렇기 때문에 셀은 UTXO의 일반화된 버전입니다.
Fuel
Fuel은 UTXO 최적화에 기반한 엄격한 접근 목록 모델을 사용합니다.
위에서 설명한 바와 같이 BTC의 UTXO에는 코인 수와 소유자라는 두 가지 속성만 있는 반면, 컨트랙트 UTXO는 코인 수, 컨트랙트 ID, 컨트랙트 코드 해시, 스토리지 루트를 포함한 더 많은 기본 속성을 제공합니다.
상태 비저장 실행 모델의 경우, 컨트랙트 코드 해시와 스토리지 루트는 컨트랙트 UTXO에만 필요합니다. 상태 저장 실행 모델에서 컨트랙트 UTXO는 이러한 필드를 생략할 수 있지만 별도의 저장 요소 UTXO 유형이 필요합니다. UTXO ID(키-값 저장소 데이터베이스에서 키로 사용할 수 있는 각 UTXO의 고유 식별자)는 UTXO가 생성된 출력 지점 또는 그 변형(예: 출력 지점 및 해당 필드의 해시)입니다.
이 모델에서는 스마트 컨트랙트처럼 누구나 컨트랙트 UTXO를 호출할 수 있습니다.
연료가 스크립트보다는 스마트 컨트랙트에 더 가까운 기능을 제공한다는 점과 UTXO 자체 모델의 한계로 인해 VM을 기반으로 애플리케이션을 구축하기 어렵다는 점, 특히 UTXO 경합은 일반적으로 세 가지 방법으로 해결할 수 있는데, 첫째는 롤업과 같이 오프체인에서 처리하는 것, 둘째는 연료처럼 추가 정렬 작업을 미리 수행하는 것, 셋째는 후자처럼 미리 수행하는 것 등이 그것입니다. 연료는 후자를 사용합니다. 세 번째는 방금 CKB 섹션에서 언급한 오픈 트랜잭션으로, 각 사용자가 트랜잭션의 일부를 언급한 다음 애그리게이터(시퀀서와 유사)가 이를 완전한 트랜잭션으로 집계하는 방식이며, BTC의 해당 솔루션은 PBST입니다.
< span mpa-is-is-tpl="t">
종료
UTXO의 기본 원리에 대한 이해를 통해 해당 모델과 이더리움의 계정/잔고 모델의 장단점을 파악하고, UTXO 개념과 관련 확장에 대해 보다 명확하게 이해합니다.
비트코인의 핵심 설계 원칙 중 하나인 UTXO 모델은 거래의 보안과 추적성을 보장하는 데 중요한 역할을 합니다. 블록체인 기술의 지속적인 발전과 함께 UTXO 모델도 진화하고 확장되어(예: EUTXO, 셀, 엄격한 접근 목록 등) 디지털 자산의 거래 및 관리 가능성을 더 많이 제공하고 있습니다. UTXO 개념과 관련 확장에 대한 심도 있는 연구와 이해를 통해 블록체인 기술의 본질을 더 잘 파악하고 향후 혁신과 응용을 위한 더욱 견고한 초석을 마련할 수 있습니다.