오프체인 트랜잭션 — 지불 채널
오프체인 트랜잭션은 블록체인의 확장성을 위한 방법 중 하나입니다. 일부 트랜잭션을 블록체인에 직접 기록하지 않고 처리하여 트랜잭션 처리량을 간접적으로 증가시키는 효과를 가져옵니다. 간접적이란 말의 의미는 이 방법이 블록체인 자체의 TPS 성능을 높이는 것은 아님을 뜻합니다. 비트코인 라이트닝 네트워크나 이더리움 플라즈마가 이에 해당한다고 볼 수 있습니다.
비트코인 라이트닝 네트워크는 지불 채널(Payment Channel)을 응용하여 오프체인 트랜잭션을 수행하는 기술입니다. 지불 채널은 컨트랙에 보증금(Deposit)을 걸어두고 이 보증금 한도 내의 지불을 즉시 수행할 수 있습니다. 트랜잭션이 블록체인 형태로 기록되지 않고 지갑 소프트웨어끼리 서명만 주고 받으면 지불이 처리됩니다.
이더리움 플라즈마 역시 컨트랙에 보증금을 건 다음에 트랜잭션을 수행하는데,플라즈마는 트랜잭션을 별도의 블록체인에 기록합니다. 이 별도의 블록체인에서는 새로운 합의 알고리즘이나 트랜잭션 구조를 가질 수 있어서 지불 이상의 기능을 할 수 있는 장점이 있습니다.
리플의 지불 채널 살펴보기
컨트랙 프로그래밍이 불가능한 리플에서는 지불 채널을 위한 트랜잭션 타입이 별도로 존재합니다. 간략한 설명을 위해 PaymentChannelCreate과 PaymentChannelClaim에 대해서만 언급하겠습니다. 지불 채널은 최소 2개의 On-chain 트랜잭션이 발생합니다. 하나는 채널을 열기 위한 트랜잭션(Create)과 다른 하나는 채널을 닫기 위한 트랜잭션(Claim)입니다.
전체적인 구조는 이렇습니다. Alice가 Bob에게 빈번하게 지불할 일이 생겼습니다. Alice는 Bob에게 지불하기 위해 우선 100 XRP를 보증금으로 걸고 지불 채널을 생성(Create)하는 트랜잭션을 합니다. 이제 이 100 XRP는 Alice의 마음대로 뺄 수는 없습니다. Bob은 이 지불 채널에 대해 Claim 트랜잭션을 수행하여 100 XRP 중 일부를 자신에게 줄 수 있습니다. 단, 채널을 Claim하게 되는 순간 지불 채널은 종료되며 보증금 중 남은 금액은 Alice에게 돌아가게 됩니다.
Alice가 Bob에게 5 XRP를 지불하려고 한다면, 이를 서명만 해서 Bob에게 전달합니다. PaymentChannelClaim의 파라메터를 보면 Signature가 있는 것을 볼 수 있습니다. 이 시그니처는 Alice가 Bob에게 5 XRP를 지불했다는 사실을 증명합니다. 이 상황에서 5 XRP를 더 지불하려고 한다면, 이전 지불과 합쳐 10 XRP에 대해서 서명하여 Bob에게 전달하면 됩니다. 이 서명을 가지고 Bob이 Claim을 하게 되면 100 중 90은 Alice에게 돌아가고 10은 Bob에게 전달되어 지불 채널이 종료됩니다.
지불 채널의 장점은 채널을 열고 닫는 2개의 On-chain 트랜잭션을 제외하면 그 사이에 지불을 100번을 하여도 수수료가 발생하지 않습니다. 채널이 열리고 난 뒤로는 서명만 전달하면 지불을 한 셈인데, 서명을 몇 번 전달하여도 블록체인과는 무관하기 때문입니다. 또한 Alice와 Bob이 일시적으로 인터넷 접근이 안되는 환경이더라도 Bob은 서명만 검증하고도 지불을 처리해줄 수 있습니다.
단점은 내가 지불할 대상을 특정해서 보증금을 걸어야 한다는 점입니다. 이 보증금은 채널이 닫히기 전까지 사용할 수 없고, 다른 지불 채널의 보증금으로 걸지도 못하기 때문에 무작정 많이 걸어둘 수 없습니다. 이는 지불 채널의 용례를 크게 줄이는 단점입니다.
지불 채널 응용
A가 B에게 지불하는 채널이 있고, B가 C에게 지불하는 채널이 있을 때 A가 B를 거쳐서 C에게 지불하는 방법이 있습니다. 이때 B는 수수료를 챙길 수도 있을 것입니다. 지불 채널을 양방향으로 하고, 채널로 연결된 노드들로 네트워크를 구성해 지불을 Routing 해주는 것이 라이트닝 네트워크의 큰 그림입니다. 비트코인은 지불 채널을 위한 별도의 트랜잭션을 가지고 있진 않지만 비트코인 스크립트로 기능을 온전히 구현할 수 있습니다.
지불 채널의 단점은 라이트닝 네트워크에서도 극복이 되지 않고 부각되기도 합니다. 지불을 Routing하는 과정에서는 보증금 문제가 그대로 있는데, 앞서 언급한 상황에서 A가 C에게 지불하려는 금액만큼 2개 채널의 용량이 받쳐주어야 합니다. 이게 홉(hop)이 늘어나면 늘어나는 만큼 채널의 용량을 사용합니다. 양질의 채널을 확보하는 것은 큰 자본을 요구하므로 중앙화된 큰 허브가 생길 것이라는 비판도 있으며 이에 따라 지불 채널의 장점이었던 수수료 역시 무색하게 될 가능성이 있습니다.
참고
- 라이트닝 네트워크 비주얼라이저: https://lnmainnet.gaben.win/
- 비트코인 Paymant Channel: https://bitcoin.org/en/developer-guide#micropayment-channel
- 리플 PaymentChannel Transaction: https://ripple.com/build/transactions/#paymentchannelclaim
- 리플 Payment Channel Tutorial: https://ripple.com/build/payment-channels-tutorial/
