원작자: SHINOBI
원작: 블록 유니콘
제안의 범위가 다소 넓음에도 불구하고 러스티 러셀의 훌륭한 스크립트 복구가 비트코인 개발의 방향이 될 수 있는 이유는 무엇입니까?
블록 유니콘 참고: Rusty Russell은 비트코인 커뮤니티에서 활동적인 개발자이며 커뮤니티에서 매우 존경받고 있습니다. 그는 Linux 커널 개발에서 뛰어난 작업을 수행했으며 많은 Bitcoin Core 개발 프로젝트에도 참여했습니다.
비트코인은 원래 사용자가 미래에 발생할 수 있는 잠재적인 보안 사용 사례를 포괄하고 지원하도록 설계된 완전한 스크립트 언어로 설계되었습니다. 나카모토 사토시가 사라지기 전에 말했듯이:
“비트코인의 특성은 일단 버전 0.1이 출시되면 나머지 수명주기 동안 핵심 설계가 설정된다는 것입니다. 그래서 제가 생각할 수 있는 모든 가능한 거래 유형을 지원하도록 설계하고 싶습니다. 문제는 모든 특별 지원 코드입니다. 및 데이터 필드가 필요하므로 사용 여부에 관계없이 수많은 특수한 경우가 발생합니다. 솔루션은 양 당사자가 특정 조건을 사용하여 노드 네트워크에 대한 트랜잭션을 설명할 수 있도록 문제를 일반화하는 것입니다. 이러한 조건을 바탕으로 평가 또는 검증되었습니다. - Satoshi Nakamoto, 2010년 6월 17일.
그의 목적은 사용자가 원하는 대로 자신의 거래 유형을 구성할 수 있을 만큼 일반적인 언어를 제공하는 것입니다. 즉, 사용자에게 자신의 통화를 코딩하는 방법을 설계하고 실험할 수 있는 여지를 제공하는 것입니다.
Satoshi는 사라지기 전에 이러한 opcode 중 15개를 제거하고 완전히 비활성화했으며, 작동할 수 있는 데이터 블록의 크기(520바이트)를 제한하는 스크립트 엔진 스택에 엄격한 제한을 추가했습니다. 이는 그가 실제로 엉망이 되어 복잡한 스크립트를 사용하여 전체 네트워크에 대해 DOS 공격을 수행하고(많은 스팸 요청을 보내 네트워크를 다운시키는 등) 거대하고 값비싼 트랜잭션을 생성할 수 있는 많은 방법을 남겨두었기 때문입니다. would 노드가 충돌하게 됩니다.
이러한 opcode는 Satoshi Nakamoto가 이러한 기능이 위험하거나 사람들이 이를 사용하여 무언가를 구축할 수 없다고 생각했기 때문에 제거되지 않았지만 단순히 (적어도 표면적으로는) 리소스 제약 없이 사용되었기 때문에 시나리오에 위험을 초래했습니다. 제한 없이 네트워크에 최악의 검증 비용을 부과할 수 있습니다.
그 이후로 비트코인으로의 모든 업그레이드는 결국 나머지 기능의 기능 최적화, Satoshi가 우리에게 남긴 덜 심각한 다른 결함을 수정하고 나머지 스크립트의 하위 집합 기능을 확장하는 것으로 끝났습니다.
복구를 위한 훌륭한 스크립트
5월 초 오스틴에서 열린 비트코인++ 컨퍼런스에서 라이트닝 네트워크의 핵심 개발자 러스티 러셀(Rusty Russell)은 컨퍼런스 첫 강연에서 매우 급진적인 제안을 했습니다. 여기서 그는 기본적으로 나카모토 사토시(Satoshi Nakamoto)를 다시 활성화할 것을 제안했습니다. 아이디어는 2010년에 사라지기 전에 대부분의 opcode를 비활성화하는 것이었습니다.
개인 정보 보호, 보안 및 확장성을 개선하기 위해 설계된 주요 비트코인 업그레이드인 Taproot가 2021년 활성화된 이후 몇 년 동안 개발 환경은 다소 목적이 없었습니다. 우리 모두는 비트코인이 세계의 상당한 규모의 자치 주권 인구에게 진정으로 서비스를 제공할 만큼 충분히 확장성이 없다는 것을 알고 있습니다. 아마도 매우 큰 관리인 및 서비스 제공자, 서비스 이상으로 확장할 수 있도록 신뢰나 관리권을 최소화하는 방식일 수도 있습니다. 확장성을 제공하기 위해 정부의 긴 팔에서 실제로 벗어날 수 없는 공급자입니다.
이 글은 비트코인에 대한 기술적 이해를 지적하고 있는데, 이는 논의할 문제가 아닙니다. 논쟁의 여지가 있는 질문은 이 결함을 어떻게 해결하느냐 하는 것인데, 이는 매우 논란이 많은 주제입니다. Taproot가 도입된 이후 모든 사람들은 특정 사용 사례에서만 가능한 문제 해결을 목표로 매우 좁은 제안을 해왔습니다.
예를 들어 ANYPREVOUT(APO)은 입력 스크립트와 금액이 동일한 한 다른 거래에서 서명을 재사용할 수 있도록 허용하는 제안입니다. 이 제안은 라이트닝 네트워크와 다자간 버전을 최적화하도록 특별히 설계되었습니다. CHECKTEMPLATEVERIFY(CTV)는 사전 정의된 거래와 정확히 일치하는 거래에서만 코인을 사용하도록 요구하는 제안입니다. 이 제안은 사전 서명된 거래 체인을 완전히 신뢰할 수 없도록 만들어 기능을 확장하도록 설계되었습니다. OP_VAULT는 키가 손상되는 것을 방지하기 위해 콜드 스토리지 구성표에 대한 시간 초과 기간을 설정하여 사용자가 콜드 스토리지에서 추출을 더 콜드 다중 서명 설정으로 보내 취소할 수 있도록 특별히 설계되었습니다.
다른 제안도 많이 있지만 요점을 이해하신 것 같습니다. 지난 몇 년 동안의 모든 제안은 확장성을 약간 높이거나 하나의 작은 기능을 개선하는 것이 바람직하다고 간주되었습니다. 이것이 논의가 진전되지 않은 이유이다. 다른 제안은 자신이 원하는 사용 사례를 충족하지 못했기 때문에 누구도 만족하지 않았습니다.
제안 스폰서 외에는 어느 누구도 모든 제안이 합리적인 다음 단계로 간주될 만큼 충분히 포괄적이라고 믿지 않습니다.
이것이 Great Script Recovery의 논리입니다. Satoshi가 원래 설계한 대로 스크립트의 전체 복구를 추진하고 분석함으로써 우리는 실제로 어떤 작은 기능 확장이 지금 충분히 좋은지에 대해 논쟁하고 내분하는 대신 필요한 전체 기능 공간을 탐색하려고 시도할 수 있습니다.
OPCODES(작동 코드)
OP_CAT: 스택에서 두 개의 데이터를 가져와서 추가하여 하나의 데이터를 만듭니다.
OP_SUBSTR: 길이 매개변수(바이트 단위)를 승인하고, 스택에서 데이터 조각을 가져오고, 해당 길이의 바이트를 제거하여 스택에 다시 넣습니다.
OP_LEFT 및 OP_RIGHT: 길이 매개변수를 승인하고, 스택에서 데이터 조각을 가져오고, 한쪽 또는 다른 쪽에서 지정된 길이의 바이트를 제거합니다.
OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT 및 OP_DOWNSHIFT: 데이터 요소를 승인하고 해당 비트 연산을 수행합니다.
OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV 및 OP_MOD: 곱셈, 나눗셈 및 모듈로 연산을 위한 수학 연산자(나눗셈의 나머지 반환).
복구를 위해 위에 나열된 opcode 외에도 Rusty Russell은 다양한 opcode의 조합을 단순화하도록 설계된 세 가지 추가 opcode를 제안했습니다.
OP_CTV(또는 TXHASH/동등한 opcode): 트랜잭션의 특정 부분을 세밀하게 적용하여 해당 부분이 사전 정의된 콘텐츠와 정확히 일치하도록 요구합니다.
CSFS: 전체 트랜잭션뿐만 아니라 서명 확인을 허용하므로 사용된 스크립트나 데이터의 특정 부분을 실행하기 전에 서명해야 합니다.
OP_TWEAKVERIFY: 집계 공개 키에서 단일 공개 키를 추가하거나 빼는 등 공개 키와 관련된 Schnorr 기반 작업을 확인합니다. 이는 한 당사자가 공유된 미사용 거래 출력(UTXO)을 일방적으로 떠날 때 다른 모든 당사자의 자금이 협력적으로 지출하기 위해 떠나는 당사자의 서명이 필요하지 않은 집합 공개로 전송되도록 하는 데 사용할 수 있습니다.
우리는 왜 이런 일을 하는가
레이어 2 네트워크는 본질적으로 비트코인 기본 레이어의 확장이며 기본 레이어의 기능에 의해 기능적으로 제한됩니다. 라이트닝 네트워크를 실제로 구현하려면 CHECKLOCKTIMEVERIFY(CLTV), CHECKSEQUENCEVERIFY(CSV) 및 Segregated Witness라는 세 가지 별도의 소프트 포크가 필요했습니다.
더 유연한 기본 레이어 없이는 더 유연한 레이어 2 네트워크를 구축할 수 없습니다. 유일한 지름길은 제3자를 신뢰하는 것입니다. 이는 매우 간단하고 명백합니다. 저는 우리 모두가 대규모로 비트코인과 상호 작용하는 모든 측면에서 제3자로부터 신뢰를 최대한 제거하기를 열망하기를 바랍니다.
우리는 현재 2개 이상을 하나의 UTXO(미사용 거래 출력)로 안전하게 병합하고 이를 기본 계층에서 무신뢰로 수행할 수 없는 작업을 수행할 수 있어야 합니다. 비트코인 스크립트는 현재 충분히 유연하지 않습니다. 가장 기본적인 수준에서는 계약이 필요하며, 한 사용자가 다른 사용자의 자금을 위험에 빠뜨리지 않고 자신의 UTXO를 안전하게 종료할 수 있도록 트랜잭션 실행에 대한 세부적인 세부 사항을 실제로 적용할 수 있는 스크립트가 필요합니다.
높은 수준에서 우리에게 필요한 기능은 다음과 같습니다.
성찰: 이 금액이 특정 출력의 공개 키로 전달됩니다.와 같이 지출 거래 자체에 대한 스택의 특정 세부 사항을 실제로 검사할 수 있어야 합니다. 이를 통해 다른 사람의 자금을 인출할 수 없도록 하면서 나만의 특정 Taproot 지점을 사용하여 직접 자금을 인출할 수 있습니다. 실행된 스크립트는 다른 소유자의 자금이 다른 사용자의 공개 키로 구성된 주소로 다시 전송되도록 보장하여 다른 참가자의 자금 손실을 방지합니다.
데이터 전달: 다수의 사람이 참여하는 단일 UTXO 개념을 더욱 발전시키고 누구나 마음대로 출입할 수 있다고 가정해 보겠습니다. 이 경우 일반적으로 머클 트리와 그 뿌리를 사용하여 누가 돈을 얼마나 가지고 있는지 추적하는 방법이 필요합니다. 이는 누군가가 떠날 때 다른 모든 사람의 자금 UTXO 변경의 일부로 누가 무엇을 받을 자격이 있는지 기록해야 함을 의미합니다. 이것은 기본적으로 자기 성찰의 특정 용도입니다.
공개 키 수정: 집계 공개 키에 대한 수정 사항을 스택에서 확인할 수 있는지 확인해야 합니다. UTXO(Unspent Transaction Output) 공유 체계에서 우리의 목표는 모든 참가자를 포함하는 집계된 공개 키를 통해 협력과 효율적인 자금 흐름을 촉진하는 것입니다. 누군가 공유된 UTXO를 일방적으로 탈퇴하는 경우, 집계 공개 키에서 개인 공개 키를 제거해야 합니다. 가능한 모든 조합을 미리 계산하지 않은 경우 유일한 옵션은 집계된 공개 키에서 하나의 공개 키를 빼면 나머지 개별 공개 키로 구성된 유효한 공개 키가 나오는지 확인하는 것입니다.
보안을 유지하는 방법: VAROPS 위에서 말했듯이 이러한 모든 opcode를 비활성화하는 이유는 네트워크를 구성하는 노드를 충돌시킬 수 있는 DOS 공격(많은 정크 요청을 보내 네트워크를 충돌하게 함)을 해결하기 위한 것입니다. 이 문제를 해결하는 한 가지 방법은 이러한 opcode가 사용할 수 있는 리소스의 양을 제한하는 것입니다.
비트코인 스크립트에서 가장 비용이 많이 드는 부분인 서명 확인과 관련하여 우리는 이미 이에 대한 솔루션을 보유하고 있으며 이를 서명 작업(sigops) 예산 책정이라고 합니다. 서명 확인 opcode를 사용할 때마다 특정 예산이 소비됩니다. 이는 블록당 허용되는 서명 작업 수이며, 이는 블록을 확인하기 위해 사용자에게 트랜잭션이 발생할 수 있는 비용에 대한 엄격한 제한을 설정합니다.
Taproot는 이것이 작동하는 방식을 변경합니다. 단일 글로벌 블록 제한을 사용하는 대신 각 트랜잭션에는 트랜잭션 크기에 비례하는 자체 sigops(서명 작업) 제한이 있습니다. 이는 본질적으로 동일한 글로벌 한도에 해당하지만 트랜잭션당 사용 가능한 시곱 수를 더 쉽게 이해할 수 있습니다.
각 트랜잭션의 sigops(서명 작업) 제한을 처리하는 방법에 대한 Taproot의 변경 사항은 Rusty Russell이 varops 제한에 대해 제안한 일반화 접근 방식의 가능성을 열어줍니다. 아이디어는 각 opcode가 생성할 수 있는 최악의 시나리오, 즉 검증 시 발생하는 가장 비싼 계산 비용을 고려하기 위해 재활성화된 각 opcode에 비용을 할당하는 것입니다. 이러한 방식으로 각 opcode에는 자체 sigops 제한이 있어 확인 프로세스 중에 소비할 수 있는 리소스의 양이 제한됩니다. 이는 또한 이러한 opcode를 사용하는 모든 트랜잭션의 크기를 기반으로 하므로 블록당 암시적 전역 제한을 계속 발생시키면서 추론이 용이해질 수 있습니다.
이렇게 하면 이러한 스팸 트랜잭션으로 인한 DOS 공격(너무 많은 스팸 요청을 보내 네트워크 충돌을 유발)을 해결할 수 있으며, 이로 인해 Satoshi는 처음에 이러한 모든 opcode를 비활성화하게 되었습니다.
앞으로의 추진력
이건 너무 많이 변한다라고 생각하시는 분들이 많을 거라 생각합니다. 그 생각도 이해는 되지만, 제안서로서 이해해야 할 중요한 점은 전부 다 할 필요는 없다는 점이라고 생각합니다. 이 제안의 가치는 이러한 모든 기능을 완전히 복원하는 데 반드시 필요한 것은 아니지만, 대규모 기본 구성 요소 제품군을 포괄적으로 살펴보고 기능 측면에서 실제로 원하는 것이 무엇인지 자문해 본다는 점입니다.
이는 지난 3년간 특정 기능만 가진 작고 편협한 변화에 대해 논쟁을 벌였던 지난 3년간의 논쟁과 완전히 다른 변화일 것입니다. 이는 모두가 함께 모여 미래의 방향을 검토할 수 있는 광장과도 같습니다. 아마도 우리는 결국 이러한 모든 기능을 복원할 수도 있고, 우리 모두가 활성화해야 한다는 데 동의하는 기능이기 때문에 몇 가지만 활성화하게 될 수도 있습니다.
최종 결과가 무엇이든 이는 우리의 미래 방향에 대한 전체 대화에 긍정적인 영향을 미치는 변화일 수 있습니다. 우리는 다음에 어떤 어두운 길을 택할지 토론하면서 더듬거리기보다는 실제로 상황에 대한 전체 그림을 그려서 얻을 수 있습니다.
이것은 결코 우리가 가야 할 길이 아니지만, 우리가 가고 싶은 길을 결정할 수 있는 가장 좋은 기회라고 생각합니다. 이제 다시 실용적이고 생산적인 방식으로 협력을 시작할 때입니다.
