편집자: GaryMa Wu가 블록체인에 대해 이야기합니다

Blockspace에 따르면, 비트코인 ​​기초 커뮤니티가 비트코인의 기반 소프트웨어에 대한 변경을 추진하기 시작했는데, 이는 4년 만에 드문 일입니다(이전에는 주요 기반 변경은 모두 핵심 개발자 그룹이 주도했습니다).

이번에는 두 가지 비트코인 ​​개선 제안(BIP), 즉 BIP-119(CTV)와 BIP-348(CSFS)에 대한 대중적 지지가 나타나고 있습니다. 이 두 가지 제안은 비트코인이 "계약" 기능을 구현할 수 있도록 하는 비트코인 ​​스크립트를 작성하는 새로운 방법을 제안합니다. 두 가지 제안 모두 비트코인의 다음 소프트 포크에서 구현될 가능성이 있습니다.

일부 독자가 Bitcoin Covenants와 이러한 특정 BIP 솔루션 간의 관계를 일시적으로 이해하지 못하는 일이 없도록 여기서 명확히 설명하겠습니다.

간단히 말해서, Covenants는 비트코인 ​​네트워크의 기능적 개념이며, 기사에서 언급된 두 BIP는 이 기능적 개념에 대한 서로 다른 구현 솔루션입니다.

비트코인 언약이란 무엇인가?

정의:

계약은 비트코인 ​​프로토콜에서 제안된 메커니즘으로, 거래에 조건이나 제한을 두어 비트코인을 어떻게 사용하거나 이체할 수 있는지를 지시합니다. 이러한 조건은 여러 거래에 걸쳐 발생할 수 있으므로 향후 지출이 이루어지는 방식을 제한하여 비트코인의 스크립팅 기능을 향상시킵니다.

효과:

더 복잡한 애플리케이션(대출, 분산형 거래소, 금고 등)을 지원하기 위해 비트코인의 스마트 계약 기능을 개선합니다 .

자금 도난이나 오용을 방지하기 위해 보안을 강화했습니다 .

거래 수수료를 낮추거나 개인정보 보호 기능을 강화하는 등 네트워크 성능을 최적화합니다 .

여기서 우리는 언약이 개념이라는 것을 대략적으로 이해할 수 있으며, 이 글에서 언급된 BIP-119(CTV)와 BIP-348(CSFS)는 언약의 기능적 개념을 구체적으로 구현한 것입니다.

현재 상태 :

비트코인 메인넷은 현재 공식적으로 언약 관련 기능을 통합하지 않았지만, 관련 논의와 제안(예: BIP-119)은 수년간 진행되어 왔습니다.

BIP 119: OP_CHECKTEMPLATEVERIFY(CTV)

후속 지출 거래에서 일치해야 하는 "템플릿"을 거래 출력에서 ​​지정할 수 있도록 하는 제안된 비트코인 ​​명령어입니다.

전 비트코인 ​​코어 기여자 제레미 루빈이 제안한 것으로, 5년 넘게 진행되어 왔습니다. 이는 자금을 미리 정의된 방법으로만 사용할 수 있도록 제한함으로써 "국가 부담" 기능을 가능하게 합니다.

적용 시나리오는 다음과 같습니다.

거래 수수료를 줄이려면 일괄 결제를 생성하세요 . 분산형 거래소(DEX) 또는 대출 프로토콜을 구축합니다.

자금 도난을 방지하기 위해 금고를 구현합니다 .

· CTV는 복잡한 논리를 포함하지 않고 출력 형식 제한에 초점을 맞춘 Covenants의 가벼운 구현입니다.

BIP 348: OP_CHECKSIGFROMSTACK(CSFS)

현재 거래의 해시뿐만 아니라 임의의 메시지에 대한 서명이 유효한지 확인할 수 있는 비트코인 ​​명령어가 제안되었습니다. 데이터 스택에서 서명, 공개 키, 메시지를 가져와서 서명이 일치하는지 확인합니다.

2024년 11월 제러미 루빈과 브랜든 블랙이 공식적으로 제안했다.

OP_CSFS는 거래 입력에 대한 "내성 검사", 즉 서명된 거래의 전체 내용이나 상태를 검사할 수 있기 때문에 보다 유연한 계약을 구현하는 데 강력한 도구입니다.

특정 응용 프로그램:

계약 이행: OP_CSFS는 복잡한 조건 논리를 생성하는 데 사용되어 자금이 특정 규칙에 따라서만 지출되도록 할 수 있습니다. 예를 들어, 검증자는 거래 입력이 사전 설정된 템플릿이나 제약 조건을 준수하는지 확인할 수 있습니다.

보안 강화: 서명 검증을 통해 도난이나 무단 지출을 방지하기 위해 Vault 및 분산 프로토콜을 지원합니다.

확장성 : 다른 명령어(예: OP_CAT)와 결합하면 더 복잡한 스마트 계약을 구성할 수 있습니다.

비트코인의 언약과 BIP-119(CTV) BIP-348(CSFS) 제안을 언급할 때, OP_CAT은 꼭 필요합니다.

BIP 347: OP_CAT

역사:

초기 존재: OP_CAT는 비트코인의 원래 스크립팅 언어의 일부였으며, 2009년 비트코인이 출시되었을 때 사토시 나카모토가 포함했습니다. 원래는 스크립트의 유연성을 향상하고 더 복잡한 논리를 지원하기 위해 설계되었습니다.

삭제 이유 (2010):

OP_CAT는 잠재적인 보안 취약점과 리소스 남용을 방지하기 위해 2010년에 제거(비활성화)되었습니다.

· 구체적인 문제: 제한되지 않으면 악의적인 사용자가 OP_CAT을 사용하여 무한 길이의 데이터(재귀 호출을 통해)를 생성할 수 있으며, 비트코인 ​​노드가 이 데이터를 처리해야 하므로 컴퓨팅 및 저장 오버헤드가 증가하여 "서비스 거부 공격"(DoS 공격)이 발생할 수 있습니다.

당시 비트코인 ​​스크립트 언어는 가장 기본적인 기능을 유지하면서 단순화되어 프로토콜의 경량성, 보안성, 분산성을 보장했습니다.

정의 및 기능:

OP_CAT은 Bitcoin Script 언어의 opcode입니다. 직접적인 Covenant 구현은 아니지만 복잡한 Covenant 논리를 구축하기 위한 잠재적인 도구입니다. 위의 두 가지 명령어와 비교해 보면 OP_CAT은 더 일반적이며 데이터 작업에 적합하지만, 복잡한 기능을 구현하려면 다른 명령어와 결합해야 합니다.

현상 유지:

최근 몇 년 동안 비트코인 ​​커뮤니티는 OP_CAT의 복귀에 대해 다시 논의했습니다. 이전에는 커뮤니티 친화적인 BIP-420 제안의 형태로 나타났지만, 이제 BIP-347 번호로 bitcoin/bips 저장소에 공식적으로 병합되었습니다.

어떻게 지내세요?

코인데스크에 따르면, 지난 몇 주 동안 많은 서양 비트코인 ​​개발자가 트위터에서 CTV와 CSFS에 대한 지지를 표명했습니다. 이는 적어도 소셜 미디어계에서 비트코인 ​​커뮤니티의 일부가 이러한 변화를 수용하는 쪽으로 움직이고 있다는 강력한 신호입니다.

또한 개발자들은 일반적으로 이 두 제안의 정의가 비교적 "좁다"고 생각합니다. 쉽게 말해, 이는 한 번 활성화하면 사용자가 실수로 오용할 가능성이 낮아진다는 것을 의미합니다. 비트코인 개발자 커뮤니티는 역사적으로 비트코인의 변화에 ​​신중한 태도를 보였습니다. 예를 들어, BIP 119가 거의 5년 동안 중단된 상태였지만 얼마 전만 해도 CTV는 활성화하기에는 너무 급진적이라고 여겨졌습니다.

두 제안의 공동 후원자인 제러미 루빈이 CTV를 홍보하기 위해 이전에 벌인 캠페인은 강력한 반대에 부딪혔는데, 특히 애덤 백과 지미 송과 같이 많은 팔로워를 보유한 비트코인 ​​인플루언서들의 반대에 부딪혔다. 이러한 비판은 결국 비트코인 ​​커뮤니티 내에서 광범위한 불만으로 이어졌고, 루빈은 결국 비트코인 ​​분야에서 사라지게 되었습니다.

그렇다면 정확히 무엇이 이러한 변화를 촉발했을까요? 최근 OP_CAT 명령어에 대한 옹호는 "수용 가능한" 것으로 간주되는 비트코인 ​​제안의 범위를 넓힌 것으로 보이며, CTV와 CSFS를 비교적 "보수적인" 옵션으로 규정합니다. OP_CAT를 지지하는 대부분의 사람들이 BIP 119와 BIP 348(그리고 대부분의 다른 제안들)도 지지한다는 점은 주목할 만합니다.

다음에는 무슨 일이 일어날까요? 첫째, 토론을 계속하겠습니다. 개발자들은 4월에 예정된 OPNEXT, 7월의 BTC++, 10월의 TABConf 등 여러 기술 컨퍼런스에서 제안을 더욱 심도 있게 탐구할 것으로 예상됩니다. 개발자들이 예비 합의에 도달하면 소프트 포크의 실제 활성화는 최종 확인을 위해 채굴자, 커뮤니티, 투자자에게 인계됩니다.

커뮤니티/소프트 포크 프로세스에서 BIP 논의 진행 상황을 어떻게 추적할 수 있나요?

대답은 매우 어렵네요!

비트코인 기술 커뮤니티는 일반적으로 이러한 제안에 대해 심도 있는 토론을 벌입니다. 하지만 이는 모호하고 순환적인 논의 과정인 듯합니다.

간단히 말해서, 비트코인 ​​소프트 포크 과정에는 개발자, 관리자, 투자자, 채굴자 등 다양한 비트코인 ​​이해 관계자의 지원 수준에 대한 대략적인 추정이 필요합니다. 가장 직접적인 지지의 지표는 채굴자로부터 나오는 경우가 많습니다. 채굴하는 블록에서 신호를 보내 코드베이스 변경에 대한 승인을 표시할 수 있기 때문입니다. 일반적으로 Bitcoin Core는 업데이트를 활성화하기 위해 잠금하기 전에 일정 기간 동안 95%의 블록이 지원 신호를 보내야 합니다.

하지만 "광범위한 지원"을 정의하는 방법에 대한 합의는 없으며 비트코인 ​​합의는 항상 진화하고 있습니다. 채굴자는 비트코인 ​​네트워크에서 "계산 가능한" 개체이기 때문에 중요한 신호 제공자입니다. 즉, 비트코인의 분산화된 구조로 인해 '눈에 보이는' 관점에서 전체적인 합의를 측정하기 어렵다는 것이다.

하지만 비트코인 ​​NFT로 유명한 개발 회사인 Taproot Wizards는 OP_CAT을 예로 들어 비트코인 ​​소프트 포크의 길고 복잡한 과정을 흐름도 형태로 공개합니다. 관심 있는 독자는 https://www.quantumcats.xyz/bip-land에서 직접 확인할 수 있습니다. 여기서 요약해 보겠습니다.

BIP 제안 라이프사이클 | 비트코인 ​​소프트 포크의 길고 복잡한 과정

1. 이 제안은 원래 비트코인 ​​개발자 메일링 리스트에서 제안되고 논의되었습니다.

2. 더 큰 커뮤니티 전체 토론에 들어가고, 제안된 기능의 장단점에 대한 장기 토론 딜레마에 들어갑니다. 더 이상 진전이 없다면 여기서 멈출 것입니다.

3. 기초 커뮤니티는 Github에서 제안에 대한 BIP 초안을 작성합니다.

4. 개발자는 관련 코드 구현을 시작하고 장기적인 감사 버그가 없는 경우에만 계속 진행할 수 있습니다.

5. 비트코인 ​​저장소 BIP 편집자의 검토와 커뮤니티의 초기 승인 후 공식 BIP 번호가 할당됩니다.

6. Signet 테스트 네트워크에 들어가세요. Signet은 개발자가 메인 네트워크에 영향을 주지 않고 새로운 기능이나 코드 변경을 실험할 수 있는 비트코인 ​​테스트 네트워크입니다. (아마도 대부분의 새로운 기능은 이 단계에서 영구적으로 보류될 것입니다)

7. 실험을 위해 Liquid 사이드체인에 진입 가능.

8. Bitcoin Core에 PR을 제출하세요.

9. 매우 불확실한 Bitcoin Core 코드 검토 및 제안 병합 프로세스에 진입합니다. 제안이 대부분의 반대 의견을 피하고 기술적 요구 사항(심각한 버그 없음)을 충족하는 경우에만 병합 단계에 들어갈 수 있습니다. 주요 개발자(예: 피터 윌러)의 의견은 종종 중요하며, 이의 승인 또는 거부는 제안의 운명에 큰 영향을 미칩니다.

10. 코드 검토가 괜찮으면 비트코인 ​​저장소 관리자가 PR을 메인 프로젝트에 병합할 때까지 기다리세요. 현재 유지 관리자는 5명입니다: Michael Ford(fanquake), Hennadii Stepanov(hebasto), Andrew Chow(achow101), Gloria Zhao(glozow), Ryan Ofsky(ryanofsky).

11. 비트코인 ​​개발자와 광부 등 다양한 그룹 간에는 잠재적인 논란과 논의가 계속되고 있습니다.

12. 활성화 메커니즘을 선택하세요:

a. 마이너 주도 소프트 포크(MASF): 새로운 규칙은 BIP-9 또는 BIP-8의 기본 모드와 같은 신호(일반적으로 95% 임계값)를 통해 마이너에 의해 활성화됩니다. 비교적 안정적이지만, 폭넓은 합의와 테스트에 대한 조정이 필요하므로 시간이 더 오래 걸립니다.

b. 사용자 주도 소프트 포크(UASF): 노드 운영자(사용자)가 새로운 규칙(예: BIP-8의 "Lockinontimeout: True")을 강제로 활성화하여 광부 저항을 우회하고, 잠재적인 체인 포크 위험과 커뮤니티 의견 불일치를 초래합니다.

결론

우는 Bitcoin.org 도메인 이름의 유지 관리자인 코브라가 비트코인 ​​네트워크가 2025년에 비트코인 ​​핵심 외부의 익명 개발자가 시작하는 사용자 시작 소프트 포크(UASF)를 가져올 수 있다고 경고한 적이 있다는 보도가 있었다고 말했습니다. 이는 실제로 이 기사에서 언급된 BIP 119에 대한 잠재적 변경 사항입니다. Cobra는 이러한 개선 사항이 풀뿌리 커뮤니티가 주도하고 비트코인 ​​핵심 개발자가 아닌 사람들이 주도하는 "강경파"와 "개선파" 간의 분열을 촉발할 수 있다고 생각합니다.

UASF(User-Initiated Soft Fork)는 비트코인 ​​사용자가 시작한 프로토콜 업그레이드 방법인 것으로 알려져 있습니다. 채굴자나 다른 당사자가 지원하지 않더라도 노드 소프트웨어를 업그레이드하여 프로토콜 업데이트를 시행하는데, 이는 체인 포크의 위험도 의미합니다. 물론, 지금 당장은 지나치게 걱정할 필요는 없습니다. 결국, 아직 해결되지 않은 문제가 많으니까요. 예를 들어, 향후 소프트 포크에는 CTV와 CSFS만 포함됩니까? 이 명령어 세트와 함께 자주 논의되는 OP_CAT을 고려할 것인가? 소프트 포크의 실제 활성화 과정은 어떻게 진행될까요? 다른 이해관계자(비트코인 채굴자 등)가 이를 충분히 심각하게 받아들일까요?

결국, BIP에 대한 합의가 충분히 크다면, 풀뿌리 커뮤니티가 주도하는 제안도 채굴자 주도 소프트 포크(MASF)의 형태로 실행될 수 있습니다. 그리고 UASF도 역사상 성공 사례가 있습니다. UASF는 2017년 SegWit 업그레이드에서 핵심적인 역할을 수행했으며, 사용자들은 하드 포크를 피하고 소프트 포크를 성공적으로 촉진했으며 비트코인 ​​확장을 촉진했습니다.

참조 링크:

https://www.coindesk.com/tech/2025/03/17/개발자 합의가 비트코인 ​​소프트 포크 제안 블록스페이스에서 수렴될 수 있음

https://www.quantumcats.xyz/bip-land

https://github.com/bitcoin/bips