56 / 736CHAN

Payment Channel

결제 채널

결제 채널을 이용하면 두 당사자가 매번 블록체인에 기록하지 않고도 반복해서 돈을 주고받을 수 있습니다. 바뀌는 것은 비트코인을 어떻게 나눌지에 관한 합의입니다. 이를 온체인에서 정산할 수 있다는 점이 합의를 뒷받침합니다. Lightning Network는 이런 채널을 바탕으로 작동합니다.

Payment Channel, 즉 결제 채널은 디지털 서명으로 합의하면서 함께 잠근 비트코인의 몫을 바꾸는 방식입니다. 서명은 새 배분에 동의한다는 뜻이며, 매번 비트코인 거래의 공개 기록인 블록체인에 변경 사항을 넣을 필요는 없습니다. 참여자들은 채널을 닫고 블록체인에서 정산할 수단도 갖고 있습니다. 여기서는 이전 합의를 폐기하고 나중에 그 합의를 사용하면 페널티를 적용할 수 있는 일반적인 양자 Lightning 채널을 설명합니다. 이 방식을 revocation이라고 하며, 다른 채널 설계는 규칙이 다를 수 있습니다.

두 당사자가 함께 잠근 금액에 대한 각자의 몫을 계속 조정한다고 생각해 보세요. 결제마다 별도의 Bitcoin 트랜잭션을 블록에 넣을 필요는 없습니다. 대신 새 상태에 대한 서명을 교환합니다. 단순히 믿고 쓰는 장부가 아닙니다. 합의한 조건에 따라 정산을 강제할 수 있는 트랜잭션을 각자 가지고 있습니다. [1] [2]

자금 조달 트랜잭션은 비트코인을 채널에 넣는 거래입니다. 출력은 누가 쓸 수 있는지 정한 규칙이 붙은 금액이며, 확인은 그 거래가 블록에 포함됐다는 뜻입니다. 일반적인 Lightning 채널에서는 이 출력에 두 당사자의 서명이 모두 필요합니다. 이를 2-of-2라고 합니다. 자금 조달 트랜잭션을 전파하기 전에 참여자들은 일방적으로 채널을 닫을 수 있는 유효한 경로를 확보해야 합니다. 보통 자금 조달의 확인을 기다립니다. 특정 조건에서는 zero-conf를 통해 확인을 기다리지 않고 채널을 사용할 수 있습니다. 이때 수신자는 자금을 제공하는 쪽을 더 신뢰해야 합니다. 아직 확인되지 않은 자금 조달 트랜잭션이 같은 자금을 쓰는 다른 트랜잭션으로 대체될 수 있기 때문입니다. [2] [3]

Commitment 트랜잭션은 현재 합의한 배분대로 정산하기 위해 미리 서명한 거래입니다. 여기서 노드는 채널과 갱신을 관리하는 프로그램을 뜻합니다. 각 당사자는 서로 다른 자신의 commitment 트랜잭션을 가집니다. 업데이트할 때 노드는 commitment_signed와 revoke_and_ack를 통해 서명과 revocation 비밀값을 정해진 순서로 교환합니다. 새 합의가 생겨도 이미 서명한 옛 트랜잭션이 Bitcoin 합의 규칙상 무효가 되지는 않습니다. 따라서 폐기된 상태의 공개에 대한 보호는 출력의 지출 조건에 들어 있어야 합니다. [2] [3]

일반적인 revocation 채널에서 자신의 commitment를 공개한 쪽은 자기 자금을 쓰기 전에 to_self_delay를 기다립니다. 대기 시간은 commitment 트랜잭션이 확인된 시점부터 블록 수로 셉니다. 폐기된 상태를 공개했다면 상대방은 revocation 키로 관련 출력을 지출해 대응할 수 있습니다. 다만 제때 행동하고 트랜잭션 확인을 받아야 합니다. Watchtower는 체인을 감시하고 미리 준비한 정보를 이용해 폐기된 상태의 공개에 대응할 수 있는 서비스입니다. 다만 이 서비스도 성공을 보장하거나 백업을 대신하지는 않습니다. [3] [4]

Sat는 satoshi의 약자로, 비트코인 체인에서 사용하는 가장 작은 단위입니다. 용량은 각 참여자의 잔액이 아니라 채널 전체의 금액입니다. 100000 sat 채널에서 Alice의 몫은 70000 sat, Bob의 몫은 30000 sat이라고 합시다. Alice가 Bob에게 10000 sat을 보내면 배분은 60000 sat과 40000 sat이 됩니다. 이해를 돕기 위해 수수료와 준비금은 제외했습니다. 용량은 그대로지만 Alice가 보낼 수 있는 금액은 줄고 받을 수 있는 금액은 늘었습니다. 실제 한도에는 준비금과 진행 중인 결제도 영향을 줍니다. [6]

Lightning은 여러 연결된 채널을 지나는 경로를 찾습니다. HTLC는 조건부 결제입니다. 자금을 받으려면 preimage라는 비밀값을 공개해야 하며, 그 값의 해시(디지털 지문)가 미리 알려진 값과 일치해야 합니다. 결제가 완료되지 않을 때도 시간 조건에 따라 정산할 경로가 있습니다. 중개자는 유동성, 즉 필요한 방향으로 보낼 수 있는 자금을 확보해야 하며 수수료를 받을 수 있습니다. 모든 상점과 직접 채널을 열 필요는 없지만, 연결되어 있다는 사실만으로 어떤 금액이든 보낼 경로가 보장되지는 않습니다. [2] [4]

상호 합의에 의한 종료인 cooperative close에서는 참여자가 종료 트랜잭션, 자금 배분, 수수료에 합의합니다. 양쪽이 서명해 블록체인에 공개합니다. 대체로 일방적인 정산보다 간단하지만 자동으로 무료이거나 즉시 끝나는 것은 아닙니다. 이 트랜잭션에도 확인과 네트워크 상황에 맞는 수수료가 필요합니다. [2] [4]

일방적인 종료인 force close는 상대방의 새로운 동의 없이 자신의 최신 commitment를 공개하는 방법입니다. 자금을 즉시 쓸 수 있다고 보장되지는 않습니다. 대기 조건과 필요한 HTLC 정산이 적용되고 추가 트랜잭션과 수수료가 들 수 있습니다. 비상구는 있지만 소요 시간과 비용은 채널 상태와 블록체인 상황에 따라 달라집니다. [3] [4]

Seed Phrase는 지갑의 키를 복구할 때 쓰는 백업 단어들입니다. 하지만 이것만으로 열린 채널의 최신 상태까지 복구되지는 않으므로 해당 지갑의 복구 절차를 따라야 합니다. 예를 들어 Lightning 노드 운영 프로그램인 LND는 이 단어들과 Static Channel Backup (SCB)을 함께 사용합니다. 이 정적 백업에는 상대 노드에 연락해 채널 종료를 요청하는 데 필요한 정보가 들어 있습니다. 채널을 되살려 결제를 이어 가는 방식은 아닙니다. 이 방법을 통한 복구는 상대가 응답하는지에도 달려 있습니다. 반면 channel.db는 채널 데이터베이스 파일이며, 오래된 복사본에는 위험할 만큼 낡은 상태가 들어 있을 수 있습니다. 채널을 “수리”한다며 타인의 웹사이트에 실제 백업 단어를 입력하지 마세요. [5]

누가 키를 보관하고 채널을 감시하는지, 기기를 잃으면 어떻게 접근을 복구하는지 확인하세요. 수탁 서비스란 서비스 제공자가 키를 보관하는 방식입니다. 수탁 서비스에 표시된 Lightning 잔액은 자신의 채널을 뜻하지 않을 수 있습니다. 직접 보관한다면 백업, 가용성, 문제 대응도 자신의 책임입니다. 채널은 블록체인 기록을 줄이지만 모든 운영 책임이나 정산 비용을 없애지는 않습니다. [4] [5]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Lightning Network, HTLC, Lightning 유동성, Lightning Watchtower. 다음 항목에서도 이 글을 참조합니다 확인, 이중 지불, Timelock, HTLC.

DOC · 001Lightning Network paper1차 출처 DOC · 002BOLT #2 — Channel lifecycle1차 출처 DOC · 003BOLT #3 — Transaction and script formats1차 출처 DOC · 004BOLT #5 — On-chain handling1차 출처 DOC · 005Lightning Labs — Disaster recovery문서 DOC · 006Lightning Labs — Managing Liquidity문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다