‘Mastering Bitcoin 2nd’ 세미나 17, Chapter 12. Blockchain Applications
Chapter 12. Blockchain Applications
마지막 세미나 입니다. 좀 어려운 주제를 다루는 세미나는 ‘지치지 않고 꾸준히 반복적으로 하는 것’이 답인 것 같습니다. 오래 걸리는 것 같지만 매주 조금씩 진행하다 보면 끝이 보이고, 어렵지만 반복하다보면 이해의 폭이 점점 깊고 넓어집니다.
이번 세미나에서는 이 책의 마지막 장인 12장 Blockchain Applications을 다룹니다. 아래 정리한 내용에 따라 본문 내용을 함께 읽어 가도록 합니다.
Let’s now build on our understanding of bitcoin by looking at it as an application platform. Nowadays, many people use the term “blockchain” to refer to any application platform that shares the design principles of bitcoin. The term is often misused and applied to many things that fail to deliver the primary features that bitcoin’s blockchain delivers.
이 장은 ‘블록체인 기술을 어디에 어떻게 활용할 수 있을가’에 대해 고민하는 사람들을 위한 장입니다. 이 책은 비트코인 시스템을 다루는 책이기 때문에 비트코인 시스템을 전제로 합니다.
비트코인 시스템은 ‘탈중앙화된 환경에서 신뢰를 구축할 필요가 있는 애플리케이션’이 요구하는 대부분의 특징들을 갖추고 있습니다. 하지만 그 시작이 애플리케이션 플랫폼이 아니기 때문에 애플리케이션 플랫폼으로서 여러 한계를 보입니다.
그러한 한계에도 불구하고 비트코인 시스템이 차지하는 위상과 비중이 크기 때문에 좀 더 범용 목적을 갖고 등장한 이더리움이나 이오스 같은 블록체인이 아닌, 비트코인 시스템을 애플리케이션 플랫폼으로 활용하려는 노력은 계속되고 있습니다. 이 장에서 다루는 지불 채널이나 상태 채널도 그러한 노력의 일환입니다.
Building Blocks (Primitives)
The building blocks offered by bitcoin are elements of a trust platform that can be used to compose applications.
비트코인 시스템의 핵심 특징들은 ‘탈중앙화된 디지털 환경에서 가치와 관련된 일을 처리하기 위해 필요로 하는 신뢰 문제를 어떻게 해결할 것인가’에 대한 답으로 제시된 것들입니다.
아래 인용한 본문 내용을 여러 번 반복해서 읽어 봅니다.
When operating correctly and over the long term, the bitcoin system offers certain guarantees, which can be used as building blocks to create applications. These include:
- No Double-Spend
- The most fundamental guarantee of bitcoin’s decentralized consensus algorithm ensures that no UTXO can be spent twice.
- Immutability
- Immutability is underwritten by energy, as rewriting the blockchain requires the expenditure of energy to produce Proof-of-Work.
- Neutrality
- The decentralized bitcoin network propagates valid transactions regardless of the origin or content of those transactions. This means that anyone can create a valid transaction with sufficient fees and trust they will be able to transmit that transaction and have it included in the blockchain at anytime.
- Secure Timestamping
- The consensus rules reject any block whose timestamp is too far in the past or future. This ensures that timestamps on blocks can be trusted. The timestamp on a block implies an unspent-before guarantee for the inputs of all included transactions.
- Authorization
- Digital signatures, validated in a decentralized network, offer authorization guarantees.
- Auditability
- All transactions are public and can be audited. All transactions and blocks can be linked back in an unbroken chain to the genesis block.
- Accounting
- In any transaction (except the coinbase transaction) the value of inputs is equal to the value of outputs plus fees. It is not possible to create or destroy bitcoin value in a transaction. The outputs cannot exceed the inputs.
- Nonexpiration
- A valid transaction does not expire. If it is valid today, it will be valid in the near future, as long as the inputs remain unspent and the consensus rules do not change.
- Integrity
- A bitcoin transaction signed with SIGHASH_ALL or parts of a transaction signed by another SIGHASH type cannot be modified without invalidating the signature, thus invalidating the transaction itself.
- Transaction Atomicity
- Bitcoin transactions are atomic. They are either valid and confirmed (mined) or not. Partial transactions cannot be mined and there is no interim state for a transaction. At any point in time a transaction is either mined, or not.
- Discrete (Indivisible) Units of Value
- Transaction outputs are discrete and indivisible units of value. They can either be spent or unspent, in full. They cannot be divided or partially spent.
- Quorum of Control
- Multisignature constraints in scripts impose a quorum of authorization, predefined in the multisignature scheme. The M-of-N requirement is enforced by the consensus rules.
- Timelock/Aging
- Any script clause containing a relative or absolute timelock can only be executed after its age exceeds the time specified.
- Replication
- The decentralized storage of the blockchain ensures that when a transaction is mined, after sufficient confirmations, it is replicated across the network and becomes durable and resilient to power loss, data loss, etc.
- Forgery Protection
- A transaction can only spend existing, validated outputs. It is not possible to create or counterfeit value.
- Consistency
- In the absence of miner partitions, blocks that are recorded in the blockchain are subject to reorganization or disagreement with exponentially decreasing likelihood, based on the depth at which they are recorded. Once deeply recorded, the computation and energy required to change makes change practically infeasible.
- Recording External State
- A transaction can commit a data value, via OP_RETURN, representing a state transition in an external state machine.
- Predictable Issuance
- Less than 21 million bitcoin will be issued, at a predictable rate.
Applications from Building Blocks
어떤 애플리케이션에서 비트코인 시스템의 어떤 특징을 어떻게 활용하고 있는지에 대한 몇 가지 예들을 제시합니다.
Counterparty
Counterparty는 비트코인 시스템을 애플리케이션 플랫폼으로 확장하기 위한 새롭고 강력한 시도입니다.
Payment Channels and State Channels
트랜잭션 확정 시간과 수수료 등의 문제로 비트코인 시스템으로 ‘둘 사이에서 작은 규모의 가치를 빈번히 거래하는 트랜잭션을 처리하는 것’은 비효율적입니다. 지불 채널은 이 문제를 해결하기 위한 제안입니다.
본문을 먼저 읽고 아래 인용한 본문 내용은 주의를 기울여 다시 한 번 읽습니다.
Payment channels are a trustless mechanism for exchanging bitcoin transactions between two parties, outside of the bitcoin blockchain. These transactions, which would be valid if settled on the bitcoin blockchain, are held off-chain instead. Because the transactions are not settled, they can be exchanged without the usual settlement latency, allowing extremely high transaction throughput, low (submillisecond) latency, and fine (satoshi-level) granularity.
Actually, the term channel is a metaphor. State channels are virtual constructs represented by the exchange of state between two parties, outside of the blockchain. There are no “channels” per se and the underlying data transport mechanism is not the channel. We use the term channel to represent the relationship and shared state between two parties, outside of the blockchain.
Payment channels are part of the broader concept of a state channel, which represents an off-chain alteration of state, secured by eventual settlement in a blockchain. A payment channel is a state channel where the state being altered is the balance of a virtual currency.
State Channels—Basic Concepts and Terminology
상태 채널은 그림 1과 같이 상태를 초기화하는 트랜잭션과 상태를 확정하는 두 개의 온체인 트랜잭션과 상태를 변경하는 다수의 오프체인 트랜잭션들로 구성됩니다. 지불 채널은 상태를 초기화하는 트랜잭션을 funding 트랜잭션이라고 하고, 상태를 변경하는 트랜잭션을 commitment 트랜잭션이라고 하고, 상태를 확정하는 트랜잭션을 settlement 트랜잭션이라고 합니다.
Making Trustless Channels
그림 3과 같이 지불 채널이 정상적으로 동작하려면 다음과 같은 문제가 발생하지 않음이 보장되어야 합니다.
- funding 트랜잭션이 다중서명으로 잠금 스크립트가 서명되었기 때문에 Fabian이 사라진다면 Emma는 돈은 잠겨버리게 됩니다.
- Emma와 Fabian이 모두 서명한 commitment 트랜잭션들 중에서 Emma가 자신에게 유리한 commitment 트랜잭션을 비트코인 네트워크에 보낼 수 있습니다. 그림 2의 예에서 600초 후에 만들어진 commitment 트랜잭션이 아니라 1초 후에 만들어진 트랜잭션을 비트코인 네트워크에 보내는 것입니다.
이들 문제는 트랜잭션 레벨의 타임락(nLocktime)을 사용해서 해결할 수 있습니다.
첫 번째 문제는 funding 트랜잭션을 만들 때, Emma에게 funding 금액을 환불해 주는 트랜잭션을 추가로 만들면 해결 됩니다. 이 트랜잭션은 첫 번째 commitment처럼 사용합니다. 그림 3의 예에서 라면 Emma에게 36mBTC를 Fabian에게 0mBTC를 지급하도록 하도록 하고 채널의 수명주기 중 가장 긴 값으로 타임락을 작성하면 됩니다.
두 번째 문제는 이전 commitment 트랜잭션의 타임락보다 이후 commitment 트랜잭션의 타임락을 짧게 만들어, 이후 commitment 트랜잭션으로 이전 commitment 트랜잭션을 무효화할 수 있도록 하면 해결 됩니다.
타임락은 효과적이지만 몇 가지 단점이 있습니다. 채널이 만들어질 때 최대 타임락이 결정되고, 채널 생애주기가 긴 경우 환불까지 오래 기다려야 합니다. 또한 이전 타임락보다 이후 타임락을 작은 값으로 설정해야 하기 때문에 채널 생애주기에 따라 commitment 트랜잭션의 갯수가 제한됩니다. 타임락의 차이가 적어도 1은 되어야 하고 비트코인 시스템은 매 10분 주기로 블록을 생성해야 합니다.
타임락 차이가 작다면 이전 commitment 트랜잭션을 보내려는 시도를 잡기 위해서 지속적으로 비트코인 네트워크를 감시해야 합니다.
Asymmetric Revocable Commitments
Asymmetric Revocable Commitments는 타임락을 사용하지 않고도 이전 commitment를 사용하려는 시도를 막을 수 있는 방법으로 제안되었습니다.
- 두 당사자가 같은(symmetric) commitment 트랜잭션을 갖는 것이 아니라 그림 5와 같이 서로 다른(asymmetric) 두 개의 commitment 트랜잭션을 갖습니다.
- 이전 commitment 트랜잭션을 사용하려는 시도를 무효화할 수 있는 revocation 키를 사용합니다.
- revocation 키를 두 당사자가 절반씩 나눠 갖습니다. 새로운 commitment 트랜잭션을 생성할 때 이전 commitment 트랜잭션의 revocation 키의 절반을 상대방에게 전달합니다.
- 각자가 갖고 있는 commitment 트랜잭션은 두 개의 출력을 갖는데 하나의 출력은 상대방의 키로 잠금을 해제할 수 있고, 다른 출력은 자신의 키로는 지급이 지연되는 조건만을 활성화 할 수 있고, revocation 키로는 상대방에게 지급되는 조건이 즉각적으로 활성화됩니다.
- 한 상대방이 이전 commitment 트랜잭션을 비트코인 네트워크에 전송해서 사용하려고 시도하면 다른 상대방은 자신의 키와 revocation 키로 트랜잭션 출력을 모두 가질 수 있습니다.
Asymmetric Revocable Commitments는 상대적인 타임락(CSV)을 사용합니다. CSV를 사용함으로 채널을 무제한적으로 열어둘 수 있게 되었고, 수 천만개가 넘는 commitment 트랜잭션들을 사용할 수 있게 되었습니다.
Asymmetric Revocable Commitments는 타임락을 사용하지 않음으로 타임락을 사용할 때의 문제는 회피할 수 있지만, 여전히 이전 commitment 트랜잭션을 사용하려는 상대방의 시도를 감시해야 한다는 문제가 있습니다.
Hash Time Lock Contracts (HTLC)
Payment channels can be further extended with a special type of smart contract that allows the participants to commit funds to a redeemable secret, with an expiration time.
HTLC는 출력의 잠금 스크립트에 해시와 타임 락을 사용하는 방법입니다. 해시를 알고 있거나 타임 락이 풀리면 출력을 사용할 수 있도록 합니다. 해시는 지급을 받아야 하는 쪽에서 만든 비밀 값(R)에 해시 입니다.
Routed Payment Channels (Lightning Network)
하나의 채널은 거래를 원하는 둘 사이에 만들어집니다. 상대가 다르면 상대 마다 채널을 만들어야 합니다. Routed Payment Channels은 이미 만들어진 채널을 경로로 사용해서 채널이 만들어져 있는 경우 다른 상대를 통해서 원하는 상대로 연결하는 방법을 제공합니다.
The Lightning Network is a proposed routed network of bidirectional payment channels connected end-to-end. A network like this can allow any participant to route a payment from channel to channel without trusting any of the intermediaries.
Basic Lightning Network Example
그림 6과 같이 채널들이 구성되었을 때 Alice가 Eric에게 1 비트코인을 지불하려고 합니다. 이를 위해 라이트닝 네트워크에서는 그림7과 같이 진행됩니다.
- Eric의 라이트닝 네트워크 노드는 랜덤 수 생성기를 사용해서 R을 생성합니다. R을 사용해서 H를 구하고 H를 Alice 노드에게 전달합니다. Alice 노드는 자신의 노드에서 Eric의 노드 사이의 경로(route)를 구합니다.
- Alice 노드는 1.003 비트코인 양으로 H와 10 블록 환불 타임아웃을 가진 HTLC를 생성해서 Bob 노드에 전달합니다. 0.003은 지불 경로에 포함된 중간 노드들에 대한 보상을 위한 것입니다.
- The HTLC has the following meaning: “Alice is committing 1.003 of her channel balance to be paid to Bob if Bob knows the secret, or refunded back to Alice’s balance if 10 blocks elapse.”
- The channel balance between Alice and Bob is now expressed by commitment transactions with three outputs: 2 bitcoin balance to Bob, 0.997 bitcoin balance to Alice, 1.003 bitcoin committed in Alice’s HTLC. Alice’s balance is reduced by the amount committed to the HTLC.
- Bob노드는 1.002 비트코인 양으로 H와 9 블록 환불 타임아웃을 가진 HTLC를 생성해서 Carol 노드에 전달합니다.
- The channel balance between Bob and Carol is now: 2 to Carol, 0.998 to Bob, 1.002 committed by Bob to the HTLC.
- Carol 노드는 1.001 비트코인 양으로 H와 8 블록 환불 타임아웃을 가진 HTLC를 생성해서 Diana 노드에 전달합니다.
- The channel balance between Carol and Diana is now: 2 to Diana, 0.999 to Carol, 1.001 committed by Carol to the HTLC.
- Diana 노드는 1 비트코인 양으로 H와 7 블록 환불 타임아웃을 가진 HTLC를 생성해서 Eric 노드에 전달합니다.
- The channel balance between Diana and Eric is now: 2 to Eric, 1 to Diana, 1 committed by Diana to the HTLC.
- Eric 노드는 R을 알고 있기 때문에 H를 구할 수 있기 때문에 자신에게 전달된 HTLC의 출력을 요구할 수 있습니다. R을 Diana 노드에게 전달합니다.
- Eric claims 1 from Diana. The channel balance is now: 1 to Diana, 3 to Eric.
- Diana 노드는 자신에게 전달된 HTLC의 출력을 요구할 수 있게 되고, R을 Carol 에게 전달합니다.
- Now the channel balance between Carol and Diana is: 0.999 to Carol, 3.001 to Diana. Diana has “earned” 0.001 for participating in this payment route.
- Carol 노드는 자신에게 전달된 HTLC의 출력을 요구할 수 있게 되고, R을 Bob에게 전달합니다.
- Carol claims 1.002 from Bob, setting the balance on their channel to: 0.998 to Bob, 3.002 to Carol
- Bob 노드는 자신에게 전달된 HTLC의 출력을 요구할 수 있게 되고, R을 Alice에게 전달합니다.
- Bob claims 1.003 from Alice. Their channel balance is updated as: 0.997 to Alice, 3.003 to Bob.
Lightning Network Transport and Routing
지불 채널들을 사용해서 경로를 구축하려면 노드들과 노드들이 개설한 채널 정보가 공유되어야 합니다. 채널 정보로는 채널을 구성하는 노드 쌍과 채널의 capacity와 수수료가 제공해야 합니다.