작성자: 798.eth

Lightning Labs 공동 창립자 Olaoluwa Osuntokun이 최근 LayerTree라는 이름의 새로운 비트코인 확장 설계를 발표했다.

이는 상당히 과감한 구상을 제시한다. 수천 명, 심지어 수백만 명의 사용자가 동일한 비트코인 UTXO를 공유하면서도, 각 사용자가 독립적인 자금 소유권과 일방적 출금 능력을 유지하게 하는 것이다.

언뜻 들으면 모순처럼 보인다.

백만 명이 각자 비트코인을 보유한다면, 일반적으로 온체인에 백만 개의 UTXO가 필요하다. 돈을 거래소에 모아두면 소수의 UTXO만 유지할 수 있고 내부 송금도 즉시 처리되지만, 사용자는 거래소의 데이터베이스를 신뢰할 수밖에 없다.

LayerTree는 이 둘 사이에서 새로운 지점을 찾으려 한다.

온체인에는 단 하나의 UTXO만 저장된다. 각자가 얼마의 비트코인을 보유하는지는 오프체인의 Merkle Sum Tree에 기록된다. 운영자는 일상적인 서비스를 유지하지만, 사용자의 잔액을 임의로 수정할 수 없고, 기존 사용자가 자신의 돈을 온체인으로 되찾아가는 것도 막을 수 없다.

하나의 트리가 어떻게 모든 사람의 잔액을 대표하는가

LayerTree에서 각 사용자는 하나의 리프 노드(leaf node)를 보유한다.

리프 노드에는 사용자 잔액, 소유자 공개키, 출금 공개키, 임대 기간, 상태 일련번호가 기록된다. 인접한 리프 노드는 계속 위로 병합되며, 각 부모 노드는 두 자식 노드의 잔액 합계와 해시를 기록하고, 최종적으로 유일한 트리 루트(root)를 형성한다.

트리에 네 명이 있다고 가정해 보자.

Alice는 5 BTC, Bob은 3 BTC, Carol과 David는 각각 1 BTC를 보유한다.

온체인의 공유 UTXO는 총 10 BTC를 보유한다. 트리 루트는 네 사람이 각각 얼마를 보유하는지, 그리고 모든 잔액을 합치면 정확히 10 BTC가 된다는 것을 약속(commit)한다.

누군가 리프 노드 하나를 수정하면 트리 루트가 바뀐다. 누군가 잔액을 허공에서 늘리려 하면 루트 노드의 금액 검증이 실패한다.

비트코인 온체인에는 트리 전체를 저장할 필요가 없다. 이 루트와, 트리 내 총 잔액에 대응하는 UTXO만 저장하면 된다.

이는 곧 대량의 사용자 소유권 기록을 하나의 암호학적 약속(commitment)으로 압축한 셈이다.

사용자가 어떻게 단독으로 출금하는가

Alice가 출금하려 할 때, 운영자의 승인도 필요 없고 다른 사용자가 온라인 상태일 필요도 없다.

그녀는 자신의 리프 노드, 리프 노드에서 트리 루트로 이어지는 Merkle 증명, 그리고 자신의 서명만 제출하면 된다.

비트코인 스크립트는 Alice가 실제로 이 트리에 속해 있음을 검증하고, 그녀가 해당 잔액을 보유하고 있음을 확인한 뒤, 한 건의 트랜잭션에서 두 가지를 완료한다.

첫째, Alice의 잔액을 그녀가 지정한 출금 주소로 지급한다.

둘째, Alice의 리프 노드를 삭제하고, 남은 자금을 새로운 트리 루트를 약속하는 UTXO에 넣는다.

트리에 백 명이 있든 백만 명이 있든, Alice는 출금 트랜잭션 한 건만 브로드캐스트하면 된다.

LayerTree가 말하는 O(1) 출금이란, 출금에 필요한 트랜잭션 수가 항상 한 건이라는 뜻이다. Merkle 증명의 크기는 여전히 구성원 수가 늘어남에 따라 증가하며, 대략 O(log N)으로 커진다.

이 설계는 정상 상태에서의 대량 사용자를 하나의 UTXO로 압축하면서도, 비정상 상태에서의 온체인 탈출 통로를 보존한다.

LayerTree의 두 가지 송금 방식

사용자가 송금할 때마다 트리 루트를 수정한다면, 모든 트랜잭션이 여전히 순차적으로 온체인에 올라가야 하므로 확장 효과는 매우 제한적일 것이다.

따라서 LayerTree는 일상적인 결제를 오프체인에서 처리하며, 주로 channel leaf와 voucher 두 가지 방식을 제공한다.

Channel leaf: Lightning 채널을 리프 노드에 넣기

하나의 리프 노드는 사용자와 운영자 사이의 Lightning 채널을 대표할 수 있다.

채널의 자금 출력은 일시적으로 별도의 UTXO로 온체인에 나타나지 않고, LayerTree 전체의 공유 출력에 포함된다. 사용자 간 결제 시에는 운영자를 통해 일반적인 Lightning HTLC를 전달한다.

결제 과정에서 LayerTree의 트리 루트는 변하지 않으며, 온체인 트랜잭션도 발생하지 않는다.

따라서 channel leaf의 결제 속도는 일반 Lightning에 근접할 수 있으며, 보통 몇 초 안에 완료된다. 운영자는 여기서 라우팅 노드 역할을 맡고, LayerTree는 채널에 필요한 온체인 UTXO를 압축하는 역할을 담당한다.

이는 마치 하나의 대형 Lightning 허브가 온체인에서 출력 하나만 차지하는 것과 비슷하다.

Voucher: 온체인에서 현금화할 수 있는 디지털 수표

LayerTree에서 더 창의적인 부분은 voucher다.

Voucher는 사용자가 발행하고 비트코인 스크립트가 최종 집행 능력을 제공하는 디지털 수표로 이해할 수 있다.

Alice의 리프 노드에 100,000 sats가 있고, 그녀가 Bob에게 10,000 sats를 지급한다고 가정해 보자.

Alice는 즉시 트리 전체를 수정할 필요가 없다. 그녀는 이 voucher가 어느 LayerTree에 속하는지, 자금이 어느 리프 노드에서 나오는지, Bob이 어떤 새 리프 노드를 얻게 되는지, 지급 금액은 얼마인지, 그리고 Alice 리프 노드의 현재 상태 일련번호가 무엇인지를 명시한 메시지에 서명하기만 하면 된다.

Alice가 서명한 voucher를 Bob에게 보내면 오프체인 결제가 완료된다.

이 과정은 서명과 네트워크 전송만 수반하므로, 속도는 거래소 내부 송금에 근접할 수 있다.

핵심적인 차이는, Bob이 받는 것이 단순히 운영자 데이터베이스의 잔액 기록 하나가 아니라는 점이다. 그는 비트코인 스크립트에 넘겨 실행시킬 수 있는 지급 명령을 받는 것이다.

Alice나 운영자가 협력을 중단하면, Bob은 스스로 voucher를 온체인에 제출할 수 있다. LayerTree 컨트랙트는 Alice의 리프 노드에서 해당 금액을 차감하고, 동시에 Bob을 위한 새로운 리프 노드를 생성한다.

이 전체 과정을 CLAIM이라고 부른다.

Alice가 다시 서명할 필요도 없고, 운영자도 Bob의 현금화를 막을 수 없다.

voucher 하나가 왜 한 번만 사용될 수 있는가

각 LayerTree 리프 노드에는 seq라고 불리는 상태 일련번호가 있다.

Alice의 현재 seq가 7이라고 가정하면, 그녀가 발행한 voucher는 명시적으로 seq 7에 바인딩된다.

voucher 하나가 현금화되면 Alice의 잔액은 줄어들고, seq도 7에서 8로 증가한다. seq 7에 바인딩된 모든 이전 voucher는 그에 따라 무효화된다.

이는 같은 수표가 중복 현금화되는 것을 방지한다.

Alice가 Bob에게 자주 지급한다면, 매번 서로 독립적인 voucher를 만들 필요도 없다.

첫 번째로 10,000 sats를 지급할 때, Alice는 누적 금액 10,000 sats의 voucher에 서명할 수 있다. 두 번째로 20,000 sats를 더 지급할 때는 누적 금액 30,000 sats의 voucher를 다시 서명할 수 있다.

Bob은 최신 voucher 하나만 보관하면 된다.

수백, 수천 건의 소액 결제가 최종 누적 잔액을 대표하는 증서 하나로 압축될 수 있다. 양측이 계속 협력하는 한, 모든 결제를 비트코인 블록에 기록할 필요가 전혀 없다.

Voucher는 신용 위험을 제거할 수 없다

Voucher는 실제 서명을 갖고 있고 온체인 현금화 경로도 있지만, 현금화되기 전까지는 여전히 발행인의 신용 위험을 수반한다.

Alice의 리프 노드에 100,000 sats만 있다고 가정해 보자.

그녀는 Bob에게 80,000 sats의 voucher를 발행하는 동시에, Carol에게 또 다른 80,000 sats의 voucher를 발행할 수 있다.

두 voucher의 서명은 모두 진짜지만, Alice의 잔액은 이 둘을 동시에 충당할 수 없다.

비트코인 스크립트는 초과 자금이 현금화되는 것을 막을 수 있지만, Alice가 오프체인에서 잔액을 초과하는 여러 증서에 서명하는 것을 막을 수는 없다. 결국 누가 돈을 받게 되는지는 누가 먼저 현금화를 완료하느냐에 달릴 수 있다.

Alice는 다른 합법적인 작업을 통해 자신의 리프 노드를 갱신하여 seq를 증가시킬 수도 있다. 이전 상태의 voucher는 그 후 무효화된다.

따라서 아직 결제되지 않은 voucher는 전통적인 수표와 매우 비슷하다.

서명은 누가 발행했는지를 증명할 수 있고, 소지자는 현금화를 시도할 수 있지만, 계좌 잔액은 부족할 수 있고, 여러 수표가 같은 잔액을 두고 경쟁할 수도 있다.

수취인은 지급인의 가용 잔액, 현재 seq, 미결제 증서, 리프 노드 임대 기간, 그리고 지급인의 신용 상태를 주시해야 한다. 낯선 사람이나 큰 금액의 결제를 마주하면, 수취인은 즉시 현금화를 선택할 수 있다. 장기 협력 관계 사이의 소액 고빈도 결제는 계속 오프체인에서 누적할 수 있다.

LayerTree 공식 웹사이트도 명시적으로 밝히고 있듯이, 수취인은 voucher가 현금화되거나 다른 방식으로 결제되기 전까지 이를 credit으로 간주해야 한다.

이러한 신용 위험은 voucher가 높은 효율성을 얻는 대가로 치르는 비용이다.

왜 voucher를 설계했는가

신용 위험이 존재하는데 왜 전부 Lightning 채널을 사용하지 않는가?

voucher의 구조가 더 단순하고 더 유연하기 때문이다.

결제 양측이 사전에 독립 채널을 구축할 필요가 없고, 어떤 리프 노드 소유자든 직접 발행할 수 있으며, 여러 번 누적 갱신할 수 있고, LayerTree와 Lightning 사이의 결제 증서로도 사용할 수 있다.

LayerTree는 Lightning으로부터의 결제를 수신하기 위한 credit leaf를 설계했다.

운영자는 Lightning 결제를 받은 뒤, 자신이 자금을 제공한 리프 노드를 사용해 수취인에게 새로운 누적 voucher를 발행할 수 있다. 수취인은 이를 계속 보유할 수도 있고, 필요할 때 스스로 온체인에서 현금화할 수도 있다.

기본 흐름에는 짧은 신뢰 창이 존재한다. 운영자가 이미 Lightning 결제를 받았지만 아직 수취인에게 voucher를 발행하지 않은 상태다. 논문은 pending pair도 설계했는데, 해시 락, 사전 서명된 voucher, 결제 창을 통해 수취인이 먼저 실행 가능한 증서를 확보한 뒤 Lightning 결제의 preimage를 공개하도록 한다.

이 구조에서 voucher는 Lightning 결제와 공유 UTXO 잔액 사이의 다리가 된다.

특히 고빈도 소액 결제, 급여 스트림, 콘텐츠 유료화, 장기 서비스 정산, 그리고 운영자가 주기적으로 일괄 청산하는 시나리오에 적합하다. 일상 상태에서는 서명만 교환하면 되고, 온체인 현금화는 분쟁 처리와 최종 결제 도구로 남겨둔다.

LayerTree는 어떤 비트코인 업그레이드에 의존하는가

LayerTree는 현재 비트코인 메인넷에서 실행될 수 없다.

covenant가 필요한데, 이는 하나의 UTXO가 미래의 사용 방식에 제약을 가하는 것이다. 예를 들어, 스크립트는 사용자가 출금한 뒤 남은 자금이 새로운 트리 루트를 약속하는 출력으로 다시 들어가도록 보장해야 하며, 임의의 주소가 가져갈 수 없게 해야 한다.

프로젝트는 네 가지 오피코드 조합을 설계했다.

FULL 버전은 BIP 441, BIP 440, OP_TX, BIP 348, 그리고 일련의 타원곡선 오피코드에 의존한다.

BIP 441은 초기에 비활성화된 일부 스크립트 기능을 복원하고, 더 유연한 데이터 및 수치 처리를 지원한다. BIP 440은 이러한 가변 비용 연산에 계산 예산을 제공한다.

MID 버전은 BIP 347의 OP_CAT, OP_TX, BIP 348의 OP_CHECKSIGFROMSTACK, 그리고 BIP 449의 OP_TWEAKADD에 의존한다.

OP_CAT은 스크립트 내 데이터를 이어 붙이는 데 사용된다. OP_TX는 스크립트가 현재 트랜잭션을 읽고 제약하도록 한다. OP_TWEAKADD는 새로운 상태를 약속하는 Taproot 공개키를 계산하는 데 사용된다.

그중 BIP 348은 voucher에 특히 중요하다. 비트코인 스크립트가 임의의 데이터에 대한 서명을 검증할 수 있게 해 준다. 이 능력이 없으면, 스크립트가 Alice가 오프체인에서 발행한 그 디지털 수표를 검증하기 어렵다.

MIN 버전은 OP_CAT과 OP_TWEAKADD에만 의존하지만, 출금과 SPLIT만 구현할 수 있고 voucher와 channel leaf는 지원하지 못한다. 이는 LayerTree의 최소 능력 경계를 증명하는 실험에 가깝다.

CCV 버전은 BIP 443의 OP_CHECKCONTRACTVERIFY, OP_TX, 그리고 voucher를 위해 준비된 BIP 348에 의존한다.

BIP 443은 UTXO가 동적 상태 약속을 지니고, 새 출력이 갱신된 상태를 반드시 상속하도록 제약할 수 있게 한다. 이는 LayerTree와 같은 온체인 상태 머신과 매우 잘 맞으며, 네 가지 방안 중 출금 크기가 가장 작은 축에 속한다.

다만, 이 BIP들은 아직 비트코인 메인넷에서 활성화되지 않았다.

"백만 명이 하나의 UTXO를 공유"하려면 추가 전제가 하나 더 있다

LayerTree 홍보에서 성능이 가장 뛰어난 버전은 OP_MERKLESUMUPDATE라는 전용 오피코드에도 의존한다.

이는 Merkle Sum 증명을 검증하고, 리프 노드 하나를 교체한 뒤의 새로운 트리 루트를 직접 계산할 수 있다.

이것이 있으면, 65,536명의 구성원을 포함한 LayerTree에서 한 사람의 출금은 약 540 vB가 필요하다. 구성원 수가 두 배가 될 때마다 출금 트랜잭션은 약 10 vB만 증가한다.

하지만 OP_MERKLESUMUPDATE는 현재 프로젝트 저장소의 설계 및 시뮬레이션 구현일 뿐이며, 아직 정식 BIP가 되지 않았고 비트코인 업그레이드 절차에도 진입하지 않았다.

이미 존재하는 오피코드 제안만 사용한다면, 65,536명 규모에서의 출금 비용은 약 908~1,473 vB다.

따라서 "하나의 트리가 수백만 명을 수용한다"는 것은 암호학적 구조상 성립하지만, 그 효율적인 구현은 여전히 현재 BIP보다 한 단계 더 나아간 비트코인 스크립트 능력에 의존한다.

대규모 뱅크런을 해결할 수 있는가

LayerTree는 정상 상태에서의 온체인 점유를 크게 압축할 수 있지만, 비트코인 블록 자체의 용량을 늘릴 수는 없다.

같은 트리의 모든 상태 갱신은 동일한 공유 UTXO를 사용하고 다시 생성해야 하므로, 개별 출금은 줄을 서서 실행되어야 한다.

프로젝트 자체 측정에 따르면, 65,536명의 사용자가 같은 트리에서 각각 출금한다면 약 2,622개의 블록, 즉 약 18일이 걸린다.

실제 배포에서는 사용자를 여러 개의 더 작은 트리로 분산하고, 동시에 일괄 가입, 일괄 결제, 일괄 출금을 사용해야 한다.

이는 LayerTree의 설계 목표를 보여 준다. 대다수의 정상적인 활동은 오프체인에 남겨 두고, 제한된 온체인 공간은 최종 결제와 비정상 처리에 남겨 두는 것이다.

LayerTree의 의미

LayerTree에는 여전히 명확한 운영자가 존재한다.

운영자는 사용자 수용, 서비스 유지, 결제 라우팅, 일괄 갱신 조직을 담당한다. 신규 사용자를 거부할 수도 있고, 실시간 서비스 제공을 중단할 수도 있다. 따라서 단일 LayerTree는 완전히 탈중앙화된 것은 아니다.

비수탁 공유 UTXO 시스템이라고 부르는 편이 더 적절하다.

운영자는 서비스 진입점을 쥐고 있고, 사용자는 자금 출금 권리를 쥐고 있다. 운영자가 문을 닫을 수도, 서비스를 거부할 수도 있지만, 프로토콜 설계상 사용자 리프 노드의 잔액을 임의로 가져갈 수는 없다.

LayerTree에서 가장 주목할 만한 부분은, 일반 UTXO, Lightning 채널, 수탁 데이터베이스 외에 또 다른 자금 형태를 보여 준다는 점이다.

즉시 유통되고, 지속적으로 누적되며, 최종적으로 비트코인 스크립트에 넘겨 강제 현금화되는 디지털 수표다.

신용 위험을 제거하지도 않았고, 블록 공간의 상한을 돌파하지도 않았다.

신용을 오프체인 결제 단계에 국한시키면서, 수취인에게는 무허가(permissionless) 온체인 집행 경로를 남겨 둔다.

이는 상당히 창의적인 비트코인 확장 아이디어다.