<div id="readability-page-1" class="page"><p><cite>Kaden Sungbin Cho</cite>
                  <span> 2021. 10. 15. 18:01</span>
                </p><div>
                                <p data-ke-size="size16">비트코인에는 검증과 코인 전송을 처리하기 위해서 다양한 스탠다드 스크립트가 존재합니다. 이러한 스크립트들은 트랜잭션에 대한 요구사항에 따라 간단한 것부터 매우 복잡한 것까지 존재하는데요.&nbsp;</p>

<p data-ke-size="size16">스탠다드 트랜잭션들은 IsStandard()와 IsStandardTx() 테스트를 사용해서 평가되고, 그러한 테스트를 통과한 것들만이 비트코인 네트워크 상에서 브로드캐스트되거나 채굴될 수 있습니다. 그러나, non-스탠다드 트랜잭션들도 유효성 검사를 통과한다면 네트워크 상에서 허용됩니다.&nbsp;</p>

<p data-ke-size="size16">이번 글에서는 그러한 스탠다드 스크립트를 다뤄볼 예정입니다:</p>

<ul data-ke-list-type="disc">
<li>종류</li>
<li>스크립트의 실행 흐름</li>
</ul>

<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style2">
<h2 data-ke-size="size26"><b>종류</b></h2>
<h3 data-ke-size="size23"><b>Pay-to-Public-Key Hash (P2PKH)</b></h3>
<p data-ke-size="size16">P2PKH는 가장 일반적으로 사용되는 트랜잭션 타입으로 비트코인 주소로 트랜잭션을 송신하는 데에 사용됩니다. 해당 타입의 트랜잭션 포맷은 아래와 같습니다:</p>

<pre id="code_1634299792792" data-ke-language="shell" data-ke-type="codeblock"><code>ScriptPubKey: OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: &lt;sig&gt; &lt;pubkey&gt;</code></pre>
<p data-ke-size="size16">ScriptPubKey와 ScriptSig 파라미터는 concatenated되고 실행됩니다.&nbsp;</p>

<h3 data-ke-size="size23"><b>Pay-to-Script Hash (P2SH)</b></h3>
<p data-ke-size="size16">P2SH는 script hash(3으로 시작하는 주소)로 트랜잭션을 송신하기 위해 사용되고 BIP16에서 정규화되었습니다. script를 전달하는 것에 더해서, redeem script 또한 평가되고 유효하여야 합니다. 포맷은 아래와 같습니다:</p>

<pre id="code_1634299964253" data-ke-language="shell" data-ke-type="codeblock"><code>ScriptPubKey: OP_HASH160 &lt;redeemScriptHash&gt; OP_EQUAL
ScriptSig: [&lt;sig&gt;...&lt;sign&gt;] &lt;redeemScript&gt;</code></pre>

<h3 data-ke-size="size23"><b>MultiSig (Pay to MultiSig)</b></h3>
<p data-ke-size="size16">M of N multisignature script는 복잡한 타입의 script로 트랜잭션을 redeem하기 위해서 여러 개의 서명들이 유효해야만 하는 script 구성이 가능합니다. 에크스로나 보증금과 같이 다양하고 복잡한 트랜잭션을 이 script를 사용해 만들 수 있습니다. 포맷을 아래와 같습니다:</p>

<pre id="code_1634300162744" data-ke-language="shell" data-ke-type="codeblock"><code>ScriptPubKey: &lt;m&gt; &lt;pubKey&gt; [&lt;pubKey&gt; . . . ] &lt;n&gt; OP_CHECKMULTISIG
ScriptSig: 0 [&lt;sig&gt; . . . &lt;sign&gt;]</code></pre>
<p data-ke-size="size16">단순 multisig은 무용하며 multisig은 보통 이전에 언급한 P2SH redeem script의 일부로 사용됩니다.</p>

<h3 data-ke-size="size23"><b>Pay to Pubkey</b></h3>
<p data-ke-size="size16">이 script는 매우 간단한 script로 보통 coinbase 트랜잭션에 사용됩니다. 현재 무용하며 이전 버젼의 비트코인에 사용되었었습니다. 공개키가 script 안에 저장되고, 트랜잭션에 비밀키로 서명하기 위해서 unlocking script가 필요합니다. 포맷은 아래와 같습니다:</p>

<pre id="code_1634300336098" data-ke-language="shell" data-ke-type="codeblock"><code>&lt;PubKey&gt; OP_CHECKSIG</code></pre>

<h3 data-ke-size="size23"><b>Null data/OP_RETURN</b></h3>
<p data-ke-size="size16">이 script는 수수료를 위해서 블록체인 상에 임의의 데이터를 저장하기 위해 사용됩니다. 메시지 제한 길이는 40 bytes인데요. 이 script의 아웃풋은 unredeemable한데, OP_RETURN이 어떠한 경우에도 실패하기 때문입니다. 이 경우 ScriptSig는 필요없습니다. 포맷은 아래와 같이 매우 간단합니다:</p>

<pre id="code_1634300443037" data-ke-language="shell" data-ke-type="codeblock"><code>OP_RETURN &lt;data&gt;</code></pre>


<h2 data-ke-size="size26"><b>스크립트의 실행 흐름</b></h2>
<p data-ke-size="size16">P2PKH script의 실행 흐름은 아래와 같습니다:</p>
<figure data-origin-width="951" data-origin-height="438" data-ke-mobilestyle="widthOrigin">
    <span data-url="https://k.kakaocdn.net/dn/cpkfxG/btrhSLUcmcW/DxSbvO6V18OOPGLsHZKyx0/img.png" data-lightbox="lightbox" data-alt="Image from Author inspired by [1]">
        <img src="https://k.kakaocdn.net/dn/cpkfxG/btrhSLUcmcW/DxSbvO6V18OOPGLsHZKyx0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="951" data-origin-height="438" data-ke-mobilestyle="widthOrigin">
    </span>
    <figcaption>Image from Author inspired by [1]</figcaption>
</figure>
<p data-ke-size="size16">위 이미지 상단에서 unlocking(ScriptSig)과 locking(ScriptPubKey)로 구성된 일반적인 P2PKH가 존재합니다.&nbsp;Locking script는 해당 트랜잭션 아웃풋의 비트코인을 지불하기 위해서 필요한 조건을 정의합니다. 트랜잭션은 이 2가지 부분을 같이 실행할 때에 인가됩니다.</p>

<p data-ke-size="size16">위의 script가 어떻게 실행되는지 자세히 살펴보면,</p>

<p data-ke-size="size16">1. 첫 단계에서는 데이터 요소들인 &lt;sig&gt;와 &lt;pubkey&gt;가 스택에 위치하게 됩니다.</p>
<p data-ke-size="size16">2. 스택에 최상위 아이템인 &lt;pubkey&gt;는 OP_DUP으로 연산으로 인해 복사본이 스택에 추가되게 됩니다.</p>
<p data-ke-size="size16">3. 이후 OP_HASH160 연산이 실행되어 &lt;pubkey&gt;의 해시값을 생성하게 됩니다.</p>
<p data-ke-size="size16">4. ScriptPubKey(locking script)의 &lt;pubkeyhash&gt;는 이후 스택에 push되어 2개의 &lt;pubkeyhash&gt;가 존재하게 됩니다. 아래에는 unlocking script로부터 &lt;pubkey&gt;에 OP_HASH160를 실행하여 생성된 것이 있고, 위에는 locking script에서 가져온 것이 존재합니다.</p>
<p data-ke-size="size16">5. 이제 OP_EQUALVERY opcode가 실행되고 스택 상단의 2개 아이템이 동일한지 확인합니다. 동일하다면 script는 계속 실행되고, 아니라면 실패하게 됩니다.</p>
<p data-ke-size="size16">6. 마지막으로 OP_CHECKSIG가 실행되어 스택에 존재하는 상위 2개 요소들의 서명이 유효한지 체크합니다. 유효하면 True인 1을, 아니라면 False인 0을 남깁니다.&nbsp;</p>

<p data-ke-size="size16">모든 트랜잭션은 비트코인 네트워크로 전송되기 전에 hex 포맷으로 인코딩됩니다. 아래 샘플 트랜잭션은 hex 포맷으로 보이며, bitcoin-cli를 사용해 메인넷이 실행되는 비트코인 노드에서 실행할 수 있습니다:</p>

<pre id="code_1634302447161" data-ke-language="shell" data-ke-type="codeblock"><code>$ bitcoin-cli getrawtransaction "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2"
{
    "result": "0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd734d2804fe65fa35779000000008b483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adfffffffff0260e31600000000001976a914ab68025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef8000000000001976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000000",
    "error": null,
    "id": null
,</code></pre>

<p data-ke-size="size16">스크립팅은 꽤나 제한적이고 비트코인을 한 주소에서 다른 주소로 옮길 때에만 사용됩니다. 하지만, 이러한 script 생성 시에 유연하게 적용할 수 있는 부분이 있기에 비트코인의 지불에 대한 특정 조건을 추가할 수 있습니다. 이러한 조건들은 간단한 형태의 파이낸셜 계약으로 생각될 수 있는데요. 그렇기에 비트코인에는 간단한 계약 구성 지원 기능이 존재한다고 할 수 있습니다. 그러나 이러한 것들은 임의의 프로그램을 블록체인에 작성할 수 있는 smart contract와는 다릅니다.</p>

<h3 data-ke-size="size23"><b>Contract</b></h3>
<p data-ke-size="size16">계약은 비트코인 블록체인을 사용하여 금융적인 합의를 강제하는 비트코인 script입니다. 비록 간단한 정의이지만 사용자가 프로그래밍적으로 실제 시나리오에서 사용될 수 있는 복잡한 계약을 생성할 수 있도록 하기에 매우 폭넓은 응용이 가능합니다. 이러한 계약은 프로그래밍적으로 비트코인을 unlocking하기 위한 여러 조건을 강제하여 완전히 탈-중앙화되고, 독립적이며, 리스크가 낮은 플랫폼 개발을 가능하게 합니다. 비트코인 블록체인이 보장하는 보안과 함께, 이러한 계약 이행을 피하고 unlocking하는 것은 불가능합니다.&nbsp;</p>

<p data-ke-size="size16">에스크로, arbitration, 마이크로페이먼트 채널과 같은 다양한 계약들을 비트코인 스크립팅 언어를 사용하여 만들 수 있습니다. 현재 구현체는 작지만, 그러나 다양하고 복잡한 계약을 만드는 것이 가능합니다. 예로, 여러 집단이 트랜잭션에 서명했을 때만 자금이 사용될 수 있도록 하거나, 특정 시간이 지난 후에야 사용이 가능하게 하는 등의 방식이 가능합니다. 이러한 시나리오는 모두 multisig와 lock time을 사용해 구현될 수 있습니다.&nbsp;</p>

<p data-ke-size="size16">다양한 기능을 제공하나, Turing complete 구성체이며 임의의 프로그램 개발이 가능한 smart contract와 비교해 매우 제한적입니다. 그러나 Miniscript라는 비트코인을 위한 smart contract 언어가 개발되며 조금씩 개선이 보이고 있습니다.&nbsp;</p>

<h3 data-ke-size="size23"><b>Miniscript</b></h3>
<p data-ke-size="size16">이 언어는 비트코인 script 작성에 있어서 좀 더 구조화된 접근방법을 제공합니다. 비록 비트코인 script가 다른 지불 조건의 조합을 제공하긴 하나, 존재하는 script를 분석하거나 새롭고 복잡한 script를 만드는 것은 쉬운 일이 아닙니다. Miniscript는 이러한 복잡한 지불 규칙을 작성하는 것을 간단하게 해줍니다.&nbsp;</p>

<p data-ke-size="size16">현재 Miniscript는 P2WSH, P2SH-P2WSH를 지원하고 P2SH에 대한 제한적인 기능 제공을 해주고 있습니다.&nbsp;</p>





<p data-ke-size="size16"><b>Reference</b></p>
<p data-ke-size="size16">[1] Mastering Blockchain</p>
            
            
                </div></div>

Kaden Sungbin Cho

비트코인에는 검증과 코인 전송을 처리하기 위해서 다양한 스탠다드 스크립트가 존재합니다. 이러한 스크립트들은 트랜잭션에 대한 요구사항에 따라 간단한 것부터 매우 복잡한 것까지 존재하는데요. 
 
스탠다드 트랜잭션들은 IsStandard()와 IsStandardTx() 테스트를 사용해서 평가되고, 그러한 테스트를 통과한 것들만이 비트코인 네트워크 상에서 브로드캐스트되거나 채굴될 수 있습니다. 그러나, non-스탠다드 트랜잭션들도 유효성 검사를 통과한다면 네트워크 상에서 허용됩니다. 
 
이번 글에서는 그러한 스탠다드 스크립트를 다뤄볼 예정입니다:
 
종류
스크립트의 실행 흐름
 
종류
Pay-to-Public-Key Hash (P2PKH)
P2PKH는 가장 일반적으로 사용되는 트랜잭션 타입으로 비트코인 주소로 트랜잭션을 송신하는 데에 사용됩니다. 해당 타입의 트랜잭션 포맷은 아래와 같습니다:
 
ScriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: <sig> <pubkey>
ScriptPubKey와 ScriptSig 파라미터는 concatenated되고 실행됩니다. 
 
Pay-to-Script Hash (P2SH)
P2SH는 script hash(3으로 시작하는 주소)로 트랜잭션을 송신하기 위해 사용되고 BIP16에서 정규화되었습니다. script를 전달하는 것에 더해서, redeem script 또한 평가되고 유효하여야 합니다. 포맷은 아래와 같습니다:
 
ScriptPubKey: OP_HASH160 <redeemScriptHash> OP_EQUAL
ScriptSig: [<sig>...<sign>] <redeemScript>
 
MultiSig (Pay to MultiSig)
M of N multisignature script는 복잡한 타입의 script로 트랜잭션을 redeem하기 위해서 여러 개의 서명들이 유효해야만 하는 script 구성이 가능합니다. 에크스로나 보증금과 같이 다양하고 복잡한 트랜잭션을 이 script를 사용해 만들 수 있습니다. 포맷을 아래와 같습니다:
 
ScriptPubKey: <m> <pubKey> [<pubKey> . . . ] <n> OP_CHECKMULTISIG
ScriptSig: 0 [<sig> . . . <sign>]
단순 multisig은 무용하며 multisig은 보통 이전에 언급한 P2SH redeem script의 일부로 사용됩니다.
 
Pay to Pubkey
이 script는 매우 간단한 script로 보통 coinbase 트랜잭션에 사용됩니다. 현재 무용하며 이전 버젼의 비트코인에 사용되었었습니다. 공개키가 script 안에 저장되고, 트랜잭션에 비밀키로 서명하기 위해서 unlocking script가 필요합니다. 포맷은 아래와 같습니다:
 
<PubKey> OP_CHECKSIG
 
Null data/OP_RETURN
이 script는 수수료를 위해서 블록체인 상에 임의의 데이터를 저장하기 위해 사용됩니다. 메시지 제한 길이는 40 bytes인데요. 이 script의 아웃풋은 unredeemable한데, OP_RETURN이 어떠한 경우에도 실패하기 때문입니다. 이 경우 ScriptSig는 필요없습니다. 포맷은 아래와 같이 매우 간단합니다:
 
OP_RETURN <data>
 
 
스크립트의 실행 흐름
P2PKH script의 실행 흐름은 아래와 같습니다:
위 이미지 상단에서 unlocking(ScriptSig)과 locking(ScriptPubKey)로 구성된 일반적인 P2PKH가 존재합니다. Locking script는 해당 트랜잭션 아웃풋의 비트코인을 지불하기 위해서 필요한 조건을 정의합니다. 트랜잭션은 이 2가지 부분을 같이 실행할 때에 인가됩니다.
 
위의 script가 어떻게 실행되는지 자세히 살펴보면,
 
1. 첫 단계에서는 데이터 요소들인 <sig>와 <pubkey>가 스택에 위치하게 됩니다.
2. 스택에 최상위 아이템인 <pubkey>는 OP_DUP으로 연산으로 인해 복사본이 스택에 추가되게 됩니다.
3. 이후 OP_HASH160 연산이 실행되어 <pubkey>의 해시값을 생성하게 됩니다.
4. ScriptPubKey(locking script)의 <pubkeyhash>는 이후 스택에 push되어 2개의 <pubkeyhash>가 존재하게 됩니다. 아래에는 unlocking script로부터 <pubkey>에 OP_HASH160를 실행하여 생성된 것이 있고, 위에는 locking script에서 가져온 것이 존재합니다.
5. 이제 OP_EQUALVERY opcode가 실행되고 스택 상단의 2개 아이템이 동일한지 확인합니다. 동일하다면 script는 계속 실행되고, 아니라면 실패하게 됩니다.
6. 마지막으로 OP_CHECKSIG가 실행되어 스택에 존재하는 상위 2개 요소들의 서명이 유효한지 체크합니다. 유효하면 True인 1을, 아니라면 False인 0을 남깁니다. 
 
모든 트랜잭션은 비트코인 네트워크로 전송되기 전에 hex 포맷으로 인코딩됩니다. 아래 샘플 트랜잭션은 hex 포맷으로 보이며, bitcoin-cli를 사용해 메인넷이 실행되는 비트코인 노드에서 실행할 수 있습니다:
 
$ bitcoin-cli getrawtransaction "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2"
{
    "result": "0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd734d2804fe65fa35779000000008b483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adfffffffff0260e31600000000001976a914ab68025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef8000000000001976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000000",
    "error": null,
    "id": null
,
 
스크립팅은 꽤나 제한적이고 비트코인을 한 주소에서 다른 주소로 옮길 때에만 사용됩니다. 하지만, 이러한 script 생성 시에 유연하게 적용할 수 있는 부분이 있기에 비트코인의 지불에 대한 특정 조건을 추가할 수 있습니다. 이러한 조건들은 간단한 형태의 파이낸셜 계약으로 생각될 수 있는데요. 그렇기에 비트코인에는 간단한 계약 구성 지원 기능이 존재한다고 할 수 있습니다. 그러나 이러한 것들은 임의의 프로그램을 블록체인에 작성할 수 있는 smart contract와는 다릅니다.
 
Contract
계약은 비트코인 블록체인을 사용하여 금융적인 합의를 강제하는 비트코인 script입니다. 비록 간단한 정의이지만 사용자가 프로그래밍적으로 실제 시나리오에서 사용될 수 있는 복잡한 계약을 생성할 수 있도록 하기에 매우 폭넓은 응용이 가능합니다. 이러한 계약은 프로그래밍적으로 비트코인을 unlocking하기 위한 여러 조건을 강제하여 완전히 탈-중앙화되고, 독립적이며, 리스크가 낮은 플랫폼 개발을 가능하게 합니다. 비트코인 블록체인이 보장하는 보안과 함께, 이러한 계약 이행을 피하고 unlocking하는 것은 불가능합니다. 
 
에스크로, arbitration, 마이크로페이먼트 채널과 같은 다양한 계약들을 비트코인 스크립팅 언어를 사용하여 만들 수 있습니다. 현재 구현체는 작지만, 그러나 다양하고 복잡한 계약을 만드는 것이 가능합니다. 예로, 여러 집단이 트랜잭션에 서명했을 때만 자금이 사용될 수 있도록 하거나, 특정 시간이 지난 후에야 사용이 가능하게 하는 등의 방식이 가능합니다. 이러한 시나리오는 모두 multisig와 lock time을 사용해 구현될 수 있습니다. 
 
다양한 기능을 제공하나, Turing complete 구성체이며 임의의 프로그램 개발이 가능한 smart contract와 비교해 매우 제한적입니다. 그러나 Miniscript라는 비트코인을 위한 smart contract 언어가 개발되며 조금씩 개선이 보이고 있습니다. 
 
Miniscript
이 언어는 비트코인 script 작성에 있어서 좀 더 구조화된 접근방법을 제공합니다. 비록 비트코인 script가 다른 지불 조건의 조합을 제공하긴 하나, 존재하는 script를 분석하거나 새롭고 복잡한 script를 만드는 것은 쉬운 일이 아닙니다. Miniscript는 이러한 복잡한 지불 규칙을 작성하는 것을 간단하게 해줍니다. 
 
현재 Miniscript는 P2WSH, P2SH-P2WSH를 지원하고 P2SH에 대한 제한적인 기능 제공을 해주고 있습니다. 
 
 
 
 
 
Reference
[1] Mastering Blockchain

비트코인 스크립트의 종류

댓글