비트코인은 처음에 사용자들이 미래에 생각해낼 수 있는 모든 잠재적인 안전한 사용 사례를 포괄하고 지원하기 위해 완전히 구체화된 스크립팅 언어로 설계되었습니다. 사토시가 사라지기 전에 이렇게 말했습니다:
“비트코인의 본질은 0.1 버전이 출시된 이후로 핵심 설계가 평생 동안 고정되어 있다는 것입니다. 그래서 저는 생각할 수 있는 모든 가능한 거래 유형을 지원하도록 설계하고 싶었습니다. 문제는, 각 항목이 사용 여부와 관계없이 특별한 지원 코드와 데이터 필드를 요구했고, 한 번에 하나의 특별한 경우만 다룰 수 있었다는 것입니다. 이는 특별한 경우의 폭발이 될 것입니다. 해결책은 스크립트로, 거래 당사자들이 자신의 거래를 노드 네트워크가 평가하는 술어로 설명할 수 있도록 일반화합니다.” – 사토시, 2010년 6월 17일.
전체 의도는 사용자에게 그들이 원하는 대로 자신의 거래 유형을 구성할 수 있는 충분히 일반적인 언어를 제공하는 것이었습니다. 즉, 사용자가 자신의 돈을 프로그래밍하는 방식에 대해 설계하고 실험할 수 있는 여지를 주는 것이었습니다.
사토시는 사라지기 전에 15개의 이러한 연산 코드를 제거하고, 스크립팅 엔진 스택에서 조작할 수 있는 데이터 조각의 크기에 대해 하드 리미트를 추가했습니다(520바이트). 이는 그가 솔직히 실수를 했고, 복잡한 스크립트를 사용하여 전체 네트워크를 서비스 거부 공격에 노출시킬 수 있는 많은 방법을 열어두었기 때문에 이루어진 조치였습니다. 이는 노드를 충돌시키는 크고 검증하기 비용이 많이 드는 거래를 생성했습니다.
이 연산 코드는 사토시가 기능이 위험하다고 생각했거나 사람들이 그것으로 만들 수 있는 것들을 구축하지 말아야 한다고 생각해서 제거된 것이 아니라, 오로지 (적어도 명백히) 네트워크에 대한 위험 때문이었습니다. 자원 제약 없이 사용될 경우 네트워크에 부과할 수 있는 최악의 검증 비용을 제한하기 위해서였습니다.
그 이후 비트코인에 대한 모든 업그레이드는 결국 남겨진 기능을 간소화하고, 사토시가 남긴 다른 덜 심각한 결함을 수정하며, 우리가 남겨진 스크립트의 하위 집합의 기능을 확장하는 것이었습니다.
위대한 스크립트 복원
5월 초 오스틴에서 열린 Bitcoin++에서 Core Lightning 개발자 러스티 러셀은 컨퍼런스 첫 발표 중 꽤 급진적인 제안을 했습니다. 그는 본질적으로 사토시가 2010년에 비활성화한 대부분의 연산 코드를 다시 활성화하자는 아이디어를 제안했습니다.
2021년 Taproot가 활성화된 이후 몇 년 동안 개발 공간은 솔직히 말해 다소 방향이 없었습니다. 우리는 모두 비트코인이 세계 인구의 상당 부분을 자주적으로 서비스할 만큼 충분히 확장 가능하지 않다는 것을 알고 있으며, 아마도 정부의 긴 손길을 피할 수 없는 대규모 수탁자 및 서비스 제공자를 넘어서는 신뢰 최소화 또는 수탁 방식으로도 그렇지 않을 것입니다.
기술적 수준에서 비트코인을 이해하는 사람은 누구나 이것을 이해합니다. 이는 논쟁의 문제가 아닙니다. 논쟁의 문제는, 그리고 매우 논란이 되는 문제는 이 단점을 어떻게 해결할 것인가입니다. Taproot 이후, 모든 사람은 활성화할 수 있는 매우 특정한 사용 사례만을 해결하기 위한 매우 좁은 제안들을 제시해왔습니다.
ANYPREVOUT (APO)는 스크립트와 입력의 양이 동일한 한 다른 거래에서 서명을 재사용할 수 있도록 허용하는 제안으로, Lightning 및 그 다자간 버전을 최적화하기 위해 특별히 맞춤화되었습니다. CHECKTEMPLATEVERIFY (CTV)는 동전이 미리 정의된 거래와 정확히 일치하는 거래에 의해서만 지출될 수 있도록 강제하는 제안으로, 사전 서명된 거래의 체인의 기능을 완전히 신뢰할 수 있도록 확장하기 위해 설계되었습니다. OP_VAULT는 사용자가 키가 손상된 경우 차가운 저장소에서 철회를 “취소”할 수 있도록 하기 위해 차가운 저장소 계획에 대한 “타임아웃 기간”을 활성화하기 위해 특별히 설계되었습니다.
다른 많은 제안이 있지만, 요점을 이해하셨을 것입니다. 비트코인을 근본적으로 확장하는 데 필요한 표현력과 프로그래밍 가능성을 포괄적으로 해결하려고 하기보다는, 지난 몇 년 동안의 각 제안은 소규모 확장이나 바람직하다고 여겨지는 단일 기능을 개선하기 위해 설계되었습니다. 이것이 바로 이러한 대화가 아무데도 가지 않는 이유라고 생각합니다. 아무도 다른 제안에 만족하지 않기 때문에, 그들은 자신이 보고 싶은 사용 사례를 충족하지 않기 때문입니다.
아무것도 제안자 외에는 충분히 포괄적이지 않아서, 그것이 합리적인 다음 단계라고 생각하는 사람은 없습니다.
이것이 위대한 스크립트 복원의 논리입니다. 사토시가 처음 설계한 대로 스크립트의 포괄적인 복원을 추진하고 분석함으로써, 우리는 현재의 기능 확장에 대한 논쟁과 내분을 피하고 우리가 실제로 필요한 기능의 전체 공간을 탐색할 수 있습니다.
연산 코드
- OP_CAT: 스택에서 두 개의 데이터 조각을 가져와서 하나로 합칩니다.
- OP_SUBSTR: 바이트 단위의 길이 인수를 받아 스택에서 해당 바이트 수만큼 제거하고 다시 넣습니다.
- OP_LEFT & OP_RIGHT: 길이 인수를 받아 스택의 데이터 조각의 한쪽 또는 다른 쪽에서 해당 바이트 수만큼 제거합니다.
- OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: 스택에서 데이터 요소를 가져와서 해당 비트 연산을 수행합니다.
- OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: 곱셈, 나눗셈 및 모듈로 연산(나눗셈의 나머지를 반환)을 위한 수학 연산자입니다.
위의 것들은 복원될 연산 코드입니다. 이 외에도 러스티는 다양한 연산 코드의 조합을 단순화하기 위해 세 가지를 더 제안합니다.
- OP_CTV (또는 TXHASH/동등): 거래의 특정 부분이 미리 정의된 대로 정확히 요구되는 세부 사항을 강제할 수 있도록 하는 것입니다.
- CSFS: 전체 거래가 아닌 임의의 데이터에 대해 서명을 검증할 수 있도록 합니다. 이를 통해 스크립트의 일부 또는 사용하는 데이터가 실행되기 위해 서명되어야 함을 요구할 수 있습니다.
- OP_TWEAKVERIFY: 공개 키와 관련된 Schnorr 기반 작업을 검증합니다. 이는 개별 공개 키를 집합에서 추가하거나 빼는 것과 관련됩니다. 이는 한 당사자가 공유 UTXO를 일방적으로 떠날 경우, 다른 모든 당사자의 자금이 협력적으로 지출하기 위해 서명할 필요가 없는 집합 공개 키로 전송되도록 보장하는 데 사용될 수 있습니다.
우리가 이 작업을 수행하고자 하는 이유
Layer 2는 본질적으로 비트코인의 기본 레이어의 확장으로, 기본 레이어의 기능에 의해 본질적으로 기능이 제한됩니다. Lightning은 실제로 구현되기 전에 세 개의 개별 소프트 포크, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), Segregated Witness가 필요했습니다.
더 유연한 Layer 2를 구축하려면 더 유연한 기본 레이어가 필요합니다. 그에 대한 유일한 지름길은 신뢰할 수 있는 제3자입니다. 이는 우리가 가능한 한 비트코인과의 모든 상호작용에서 제거하고자 하는 것입니다.
우리가 안전하게 두 명 이상의 사람을 단일 UTXO에 담을 수 있는 방법이 필요하지만, 현재 비트코인 스크립트는 충분히 유연하지 않습니다. 가장 기본적인 수준에서 우리는 계약이 필요하며, 스크립트가 이를 실행하는 거래에 대한 더 세부적인 사항을 실제로 강제할 수 있는 능력이 필요합니다. 이를 통해 사용자가 자신의 UTXO에서 안전하게 나가는 것이 다른 사용자의 자금을 위험에 빠뜨리지 않도록 보장할 수 있습니다.
높은 관점에서 이것이 우리가 필요한 기능의 종류입니다:
내부 검사: 우리는 스택에서 지출 거래 자체에 대한 특정 세부 사항을 실제로 검사할 수 있어야 합니다. 예를 들어 “이 금액은 특정 출력의 이 공개 키로 간다”와 같은 것입니다. 이를 통해 특정 Taproot 분기를 사용하여 혼자서 내 돈을 인출할 수 있으며, 다른 사람의 돈을 가져갈 수 없도록 보장합니다. 실행되는 스크립트는 합의에 의해 모든 다른 사용자가 소유하는 올바른 금액이 내가 떠날 경우 다른 사용자 공개 키로 구성된 주소로 반환되도록 강제합니다.
전달 데이터 보유: 두 명 이상의 사람이 있는 Lightning 채널의 아이디어를 넘어, 우리는 누구나 자유롭게 출입할 수 있는 대규모 사람들이 있는 단일 UTXO를 구성합니다. 거의 항상 머클 트리와 그 루트를 사용하여, 우리는 누가 얼마의 돈을 가지고 있는지를 추적할 수 있는 방법이 필요합니다. 이는 누군가 떠날 때, “누가 무엇을 받을 자격이 있는지”에 대한 “기록”이 다른 모든 사람의 자금의 변경 UTXO의 일부가 되도록 보장해야 함을 의미합니다. 이는 본질적으로 내부 검사의 특정 사용입니다.
공개 키 수정: 우리는 집합 공개 키에 대한 수정이 스택에서 검증될 수 있도록 보장할 수 있는 능력이 필요합니다. UTXO 공유 계획의 목표는 모든 관련자가 협력적이고 더 효율적인 자금 이동을 허용하는 집합 키를 갖는 것입니다. 누군가가 공유 UTXO를 일방적으로 떠날 때, 우리는 그들의 개별 키를 집합에서 제거해야 합니다. 모든 가능한 조합을 미리 계산하지 않고는, 집합에서 하나의 키를 빼는 것이 나머지 개별 키로 구성된 유효한 키를 생성한다는 것을 검증할 수 있는 방법이 필요합니다.
이것을 안전하게 만드는 방법: Varops
위에서 언급했듯이, 이러한 모든 연산 코드가 비활성화된 이유는 네트워크를 구성하는 노드를 실제로 충돌시킬 수 있는 서비스 거부 공격의 위험을 제거하기 위해서였습니다. 이를 해결하는 방법이 있습니다. 이러한 연산 코드가 사용할 수 있는 자원의 양을 제한하는 것입니다.
우리는 이미 서명 검증과 관련하여 그러한 해결책을 가지고 있습니다. 이는 비트코인 스크립트를 검증하는 데 가장 비싼 부분입니다. 이를 sigops 예산이라고 합니다. 서명 확인 연산 코드를 사용할 때마다 블록당 허용된 서명 작업의 특정 ‘예산’을 소비합니다. 이는 거래가 사용자가 개별 블록을 검증하는 데 부과할 수 있는 비용에 대해 하드 리미트를 설정합니다.
Taproot는 이 방식의 작동 방식을 변경했습니다. 이제는 단일 글로벌 블록 한도를 사용하는 대신, 각 거래는 거래의 크기에 비례하여 자체 sigops 한도를 가집니다. 이는 본질적으로 동일한 글로벌 한도로 작동하지만, 개별 거래가 사용할 수 있는 sigops의 수에 대해 더 쉽게 이해할 수 있도록 합니다.
Taproot가 각 거래에 대한 sigops 한도를 처리하는 방식의 변화는 이를 일반화할 수 있는 방법을 제공합니다. 이는 러스티가 제안하는 varops 한도입니다. 아이디어는 각 재활성화된 연산 코드에 대해 최악의 경우, 즉 검증하는 데 가장 비싼 계산 비용을 고려하여 비용을 할당하는 것입니다. 이를 통해 이러한 모든 연산 코드 각각은 검증에 소비할 수 있는 자원의 양을 제한하는 일종의 “sigops” 한도를 가질 것입니다. 또한 이를 사용하는 거래의 크기에 따라 달라지므로 이해하기 쉬운 방식으로 유지하면서도 블록당 암묵적인 글로벌 한도를 유지합니다.
이는 사토시가 처음에 이러한 모든 연산 코드를 비활성화한 이유인 서비스 거부 위험을 해결할 것입니다.
전진하는 모멘텀
많은 분들이 “그것은 너무 큰 변화다”고 생각하고 있을 것이라고 확신합니다. 저는 그 점에 공감하지만, 이 프로젝트 제안의 중요한 측면은 우리가 모든 것을 해야 하는 것은 아니다라는 것입니다. 이 제안의 가치는 반드시 모든 것을 다시 활성화하는 것이 아니라, 우리가 실제로 기능 측면에서 무엇을 원하는지를 포괄적으로 살펴보는 데 있습니다.
이는 지난 3년간의 작은 변화에 대한 논쟁과 다툼에서 완전히 방향을 전환하는 것입니다. 이는 모든 사람을 한 지붕 아래 모을 수 있는 텐트가 되어, 어디로 나아갈지를 포괄적으로 평가할 수 있게 해줍니다. 어쩌면 우리는 모든 것을 다시 활성화하게 될 수도 있고, 어쩌면 모두가 필요하다고 동의하는 기능을 활성화하기 위해 몇 가지 것만 활성화하게 될 수도 있습니다.
결과가 무엇이든, 이는 우리가 앞으로 나아갈 방향에 대한 전체 대화에서 생산적인 변화가 될 수 있습니다. 우리는 실제로 전체 지형을 매핑하고 포괄적인 시각을 얻을 수 있으며, 다음에 어떤 흐릿하고 반쯤 밝은 길로 나아갈지를 두고 논쟁하는 것이 아닙니다.
이것이 우리가 나아가야 할 길이 되어야 할 필요는 없지만, 우리가 어떤 길을 선택할지 결정하는 데 가장 좋은 기회라고 생각합니다. 다시 생산적인 방식으로 함께 작업을 시작할 때입니다.
비트코인++에서 녹화된 일련의 비디오 인터뷰 중 첫 번째를 찾을 수 있습니다. 여기에서 러스티 자신이 제안한 스크립트 복원에 대해 논의하고 있습니다:
