13줄의 코드로 비트코인에 스마트 계약 구현을 도울 수 있을까? OP_CAT 소프트포크 이해하기
글: Jaleel, BlockBeats
비트코인 코드 저장소에서 오랫동안 사토시 나카모토에 의해 삭제되어 역사 속에 묻혀 있던 오퍼레이션 코드(OPCODE) 'OP_CAT'이 다시 부활할 가능성이 제기되고 있다.
OP_CAT 오퍼레이션 코드를 중심으로 비트코인 NFT 프로젝트 Taproot Wizards는 새로운 NFT 시리즈 Quantum Cats를 출시하며 커뮤니티의 큰 관심을 받았다. OP_CAT이라는 명칭이 우리가 익히 아는 '고양이'를 의미하는 것은 아니지만, Taproot Wizards는 고양이 이미지를 활용해 Quantum Cats라는 새로운 NFT를 발행하고 밈(meme) 문화를 통해 OP_CAT에 대한 홍보 효과를 극대화했다.
한때 비트코인 스크립트 언어에서 제거되었던 OP_CAT은 현재 다시 공론의 장에 올랐다. 일부 비트코인 개발자들은 이 오퍼레이션 코드를 되살려 13줄의 코드로 소프트포크를 구현함으로써 비트코인에 스마트 계약 기능을 도입하려는 움직임을 보이고 있다. 이러한 개발자들의 추진력과 고양이 캐릭터를 활용한 밈 캠페인이 결합되면서 OP_CAT에 대한 관심과 논의 수준은 정점을 찍고 있다.
사토시가 삭제한 오퍼레이션 코드의 '부활'
오퍼레이션 코드(Opcode)는 지령문 또는 함수라고도 하며, 비트코인 스크립트 언어의 기본 구성 요소이다. 과거에는 클라이언트 구현상 취약점 우려로 인해 초기 비트코인 버전에서 일부 오퍼레이션 코드들이 제거되었는데, OP_CAT 역시 그 대상 중 하나였다.
OP_CAT은 원래 비트코인 공식 명령어 집합의 일부로, 두 값을 연결해 하나의 문자열로 만드는 기능을 제공한다. 하지만 OP_LSHIFT 등의 오퍼레이션 코드에서 발견된 심각한 버그로 인해 비트코인 노드 전체가 다운될 위험이 있었으며, OP_CAT 자체도 스택 요소의 지수적 증가를 유발해 메모리 사용량이 스크립트 크기에 따라 지수적으로 증가할 수 있다는 우려가 있었다.
이러한 이유로 사토시 나카모토는 신중을 기해 2010년 8월 15일 OP_CAT을 제거했다. 이러한 제거된 오퍼레이션 코드들은 흔히 '비활성화(disabled)'라고 불리지만, 실제로는 프로토콜에서 완전히 삭제된 것이므로 누구도 해당 코드를 사용할 수 없다.
2023년 10월, Bitcoin Core 개발자인 이단 하일먼(Ethan Heilman)과 Botanix Labs의 수석 소프트웨어 엔지니어 아민 사부리(Armin Sabouri)가 공동으로 비트코인 개선 제안(BIP) 초안을 발표했는데, 이 초안의 이름이 바로 'OP_CAT'이었다. 이로써 관련 논의는 새로운 국면을 맞이하게 되었다.
이 BIP 초안은 단 13줄의 간결한 코드로 이루어져 있으며, tapscript용 새로운 오퍼레이션 코드를 정의하는데, 스택 상의 두 값을 연결하는 명확한 기능을 수행한다. 이 코드의 구현 아이디어는 원래 삭제된 OP_CAT에서 직접 영감을 얻은 것이다.
'부활' 조건이 이미 충족됐다
왜 사토시 나카모토가 삭제했던 오퍼레이션 코드를 지금 와서 복구하려는 것일까? 이 BIP 초안의 동기 부분은 이를 자세히 설명한다. 핵심은 메모리 사용량 문제인데, OP_CAT은 스크립트 생성 시 메모리 사용량이 스크립트 크기와 함께 지수적으로 증가할 수 있기 때문이다. 예를 들어, 단 1바이트 값을 스택에 넣고 OP_DUP로 복제한 후 OP_CAT으로 40번 연결하면, 스택 값이 무려 1TB 이상으로 팽창할 수 있다.
하지만 시간이 흐르고 기술이 발전하면서 이 문제는 더 이상 장애물이 되지 않는다. tapscript 아키텍처 하에서는 스택 요소의 크기를 520바이트 이내로 엄격히 제한하는 규칙이 마련되었다. 이 변화는 OP_CAT이 유발할 수 있는 메모리 문제를 효과적으로 해결했으며, 이로써 OP_CAT의 '부활'과 통합이 현실적인 가능성을 갖게 되었다.
따라서 OP_CAT이 다시 논의되고 복원을 고려하는 주된 이유는 보다 복잡하고 강력한 스크립트를 구성하는 잠재적 가치 때문이며, 다음의 조건들이 이미 충족되었기 때문이다:
1. 고급 스마트 계약 및 프로토콜에 대한 수요: 비트코인 생태계의 발전에 따라 더 고급화되고 복잡한 스마트 계약과 프로토콜에 대한 요구가 증가하고 있다. OP_CAT은 스택 상의 객체를 결합할 수 있게 해 tapscript의 표현력과 기능을 높인다. 예를 들어, 머클 트리 및 기타 해시 데이터 구조의 구성 및 평가, 트리 서명, 양자저항 Lamport 서명, 비부인 계약, 금고(vault) 등 다양한 기능을 지원할 수 있다.
2. 타 체인에서의 성공 사례: 비트코인 캐시(Bitcoin Cash)나 사이드체인 리퀴드(Liquid) 같은 일부 비트코인 포크들은 이미 OP_CAT을 재도입해 토큰 생성 및 관리, 페이먼트 채널, 블록체인에 데이터를 삽입하고 검색하는 방법 등을 구현했다. 이는 적절한 환경과 제한 조건 하에서 OP_CAT이 안전하고 효율적으로 사용될 수 있음을 시사한다.
3. 양자 보안성 탐색: OP_CAT과 같은 오퍼레이션과 Lamport 서명 기술을 결합하면 양자 보안 비트코인 거래 및 프로토콜을 구축할 수 있다는 연구도 존재한다. 이는 비트코인 시스템의 미래 보안성을 강화하는 데 잠재적 가치를 지닌다.
4. 커뮤니티 및 기술 발전: 비트코인 커뮤니티와 기술의 지속적인 발전은 과거의 결정을 재검토하고 평가하도록 유도한다. 비트코인 프로토콜에 대한 이해가 깊어지고 새로운 기술이 등장함에 따라, 과거에는 문제가 있거나 부적절하다 여겨졌던 기능들도 새로운 맥락에서 안전하고 유용하게 활용될 수 있다.
소프트포크, 말처럼 쉬운 일이 아니다
기술적으로 보면 다른 어떤 비트코인 제안보다 OP_CAT은 이해하기 쉽다는 점에서 매우 드물다. 그러나 OP_CAT 오퍼레이션 코드는 OP_SUCCESS126의 재정의를 통해 소프트포크 방식으로 활성화되는데, 이는 결코 쉬운 일이 아니다.
최근 비트코인의 소프트포크는 3년 전 탭루트(Taproot) 활성화 때 발생했으며, 이는 Ordinals의 탄생 기반을 마련했다.
비트코인 커뮤니티는 합의와 투명성을 매우 중요시하며, 중요한 코드 변경 사항은 반드시 커뮤니티 내에서 광범위한 논의와 검토를 거쳐야 한다. 코드가 비트코인 코드베이스에 포함되기 위해서는 엄격하고 상세한 절차를 거쳐야 하며, 이는 제안의 질과 커뮤니티 합의를 보장한다. 주요 단계는 다음과 같다:
1. 제안서 및 코드 작성: 먼저 개발자는 제안의 동기, 기술 세부사항, 영향 평가, 잠재적 문제 등을 명확히 설명하는 상세한 문서를 작성해야 한다.
2. 커뮤니티 논의: 제안이 커뮤니티에 제출되면 개발자, 마이너, 투자자, 사용자 등이 이를 논의하고 검토한다. 이 단계는 제안의 실현 가능성 확보와 피드백 수집에 핵심적이다.
3. 수정 및 개선: 커뮤니티의 피드백을 바탕으로 제안자가 제안 내용을 수정하고 개선할 수 있다.
4. 투표 및 합의 달성: 특히 비트코인 프로토콜 자체를 변경하는 중요한 개선안의 경우, 커뮤니티 구성원 간 일정 수준의 합의가 필요하다. 일반적으로 마이너들이 채굴한 블록에 특정 신호를 포함시켜 제안을 지지한다는 의사를 표시한다.
5. 코드 구현: 일단 합의가 이루어지면, Bitcoin Core 개발팀이 코드를 검토한다. 이 과정은 코드의 품질과 보안성을 보장하기 위한 것이다.
6. 코드베이스 통합: 검토를 통과하면 코드가 비트코인 공식 코드베이스에 통합된다.
7. 배포 및 활성화: 새 코드는 마이너들과 노드 운영자들이 시스템에 배포해야 한다. 프로토콜 수준의 변경의 경우, 일정한 활성화 임계치가 설정되며, 충분한 수의 네트워크 참여자가 새 버전으로 업그레이드해야 개선안이 적용된다.
명백히, OP_CAT 소프트포크는 아직 매우 초기 단계에 있으며, BIP 초안 작성 후 4개월도 채 되지 않았고, BIP 번호조차 할당되지 않은 상태다. 현재는 1단계인 제안서 및 코드 작성과 2단계인 개발자 및 사용자 포함 커뮤니티 논의 단계에 머물러 있다.
비트코인 개발자들의 입장은?
먼저 최근 몇 년간 비트코인 개발자들이 OP_CAT에 대해 어떻게 논의해왔는지 살펴보자.
OP_CAT 오퍼레이션 코드가 삭제되었지만, 고급 계약 지원 및 비트코인 스크립트 언어 강화 측면에서의 잠재적 가치는 개발자들 사이에서 계속해서 논의되어 왔다. 예를 들어, 스택 값을 연결할 수 없는 것은 TumbleBit 같은 일부 비트코인 프로토콜 개발의 장애물이 되었으며, OP_CAT 지원 시 거래 크기를 크게 줄일 수 있다는 주장이 있다.
Optech 뉴스레터 및 다양한 관련 자료를 수집한 후, 시간 순서에 따라 비트코인 개발자들이 OP_CAT 오퍼레이션 코드에 대해 논의한 내용을 정리해본다.
2019년
이번 'OP_CAT' 비트코인 개선 제안(BIP) 초안의 공동 제안자 중 한 명인 이단 하일먼(Ethan Heilman)은 2019년 10월 메일을 통해 OP_CAT이 제거된 이유를 이해한다고 밝혔다. 당시 스크립트 환경이 매우 어려웠기 때문이라고 설명했다. 하지만 그는 OP_CAT이라는 오퍼레이션 코드의 가치를 간과해서는 안 된다고 강조했다. "현재 비트코인 위에서 구축하려는 대부분의 프로토콜은 스택 값을 연결할 수 없다는 제약에 부딪힌다. 연구자로서 내가 이런 한계를 느낀다면, 분명히 다른 사람들도 진보를 저해받고 있을 것이다. 만약 마법 지팡이로 하나의 비활성화된 오퍼레이션 코드를 다시 활성화할 수 있다면, 나는 OP_CAT을 선택할 것이다. 물론 조건이 붙는데, 각 연결 값의 크기는 64바이트 이하로 제한되어야 한다."
OP_CAT 논의에서 결코 빠질 수 없는 인물이 앤드류 필스트라(Andrew Poelstra)다. 그는 2021년 1월 30일 'CAT and Schnorr Tricks I'라는 제목의 글을 발표하며 OP_CAT에 대한 논의를 다시 촉발시켰다. 앤드류 필스트라는 Blockstream 연구 책임자이자 숙련된 비트코인 암호학 스크립트 개발자로, 업계 내 영향력이 막대하다.
그는 글에서 "OP_CAT은 스택의 두 요소를 결합해 하나로 만든 후 다시 스택에 푸시하는 기능을 제공한다. 이 기능은 여러 작은 요소를 하나의 큰 요소로 조립하거나, 큰 요소를 여러 작은 요소로 분해하는 데 사용할 수 있다. 반면 CHECKSIGFROMSTACK(CSFS)은 비트코인에 존재하지 않는 오퍼레이션 코드로, 임의의 데이터에 대한 서명 검증을 가능하게 하며, 거래 서명만 검증 가능한 CHECKSIG과 차별화된다."라고 설명했다.
더욱 중요한 점은, OP_CAT과 CHECKSIGFROMSTACK을 결합하면 거래 내성(introspection)을 위한 교묘한 방법을 제공할 수 있다고 지적한 것이다.
참고: 거래 내성(introspection)이란 비트코인 스크립트 내에서 거래 자체의 구성 요소들을 검사하고 분석할 수 있는 능력을 의미한다. 간단히 말해, 스크립트가 자신이 처리 중인 거래의 출력 내용, 금액, 특정 서명 등을 확인할 수 있도록 하는 것으로, 이를 통해 스크립트는 거래의 구체적 내용에 따라 더욱 지능적이고 세밀한 반응을 할 수 있다.
예를 들어, 사용자가 스택에 전체 거래 데이터를 제공하면, 스크립트는 OP_CAT을 이용해 이를 하나의 항목으로 묶은 후 해시 처리하고, CHECKSIGFROMSTACK에 전달하여 서명을 검증한다. 이후 동일한 서명과 키를 CHECKSIG에 전달한다. 두 검증 모두 통과하면 사용자가 제공한 거래 데이터가 실제 거래 데이터임이 입증된다. 이렇게 하면 스크립트는 해당 데이터를 활용해 계약 실행에 필요한 모든 검사를 수행할 수 있다.
앤드류 필스트라의 영향력과 이 글의 아이디어는 비트코인 개발자들의 주목을 받았으며, 당시 회의에서 이러한 오퍼레이션 코드의 결합과 탭루트 활성화 후 스크립트 언어의 미세한 변경이 계약 유연성에 어떤 영향을 미칠 수 있는지 많은 논의가 이루어졌다.
《CAT and Schnorr Tricks I》 발표 후 약 2주 뒤, 앤드류 필스트라는 두 번째 글인 《CAT and Schnorr Tricks II》를 게시하며 더 많은 세부사항과 자신의 생각을 설명했다.
2019년 5월, 비트코인 개발자 제레미 루빈(Jeremy Rubin)은 기술적·사회적 위험을 피하기 위해 제한적인 스마트 계약을 구현하기 위해 CHECKOUTPUTSHASHVERIFY 오퍼레이션 코드를 제안했다. 이후 이 오퍼레이션 코드는 SECURETHEBAG으로 대체되었고, 이후 다시 CHECKTEMPLATEVERIFY로 대체되었다. CHECKTEMPLATEVERIFY는 2020년 1월 비트코인 개선 제안 BIP 0119으로 공식화되었다.
한편, 러셀 오코너(Russell O'Connor)는 루빈의 제안이 가지는 제약을 벗어난 스마트 계약을 지원하기 위해 비트코인에 CHECKSIGFROMSTACK과 OP_CAT 오퍼레이션 코드를 직접 추가할 것을 제안했다. 그러나 이 제안은 일부 반대에 부딪히며 논의가 점차 줄어들었다. 주된 이유는 CAT+CHECKSIG 유형의 스마트 계약이 비효율적이며, 포괄적인 일반 스마트 계약에 대한 장기적인 부정적 인식 때문이었다.
앤드류 필스트라도 처음에는所谓 비트코인 스마트 계약 기능을 지지하지 않았다. 그러나 2019년 가을, 이단 하일먼과의 비공개 대화를 통해 생각이 바뀌었다. 이단 하일먼은 우려에도 불구하고 CHECKMULTISIG를 통해 해로운 것으로 여겨지는 스마트 계약을 이미 구현할 수 있지만, 이러한 계약은 인정과 접근성 부족으로 지갑이나 사용자에게 받아들여지지 않는다고 지적했다. 이를 입증하기 위해 이단 하일먼은 소셜미디어에서 실현 가능한 '암흑' 스마트 계약을 제안하도록 도전장을 던졌으나, 지금까지 성공한 사례는 없다.
이에 따라 앤드류 필스트라는 스마트 계약에 대한 두려움이 과장되었을 가능성을 고민하게 되었고, 글에서는 우려가 있더라도 스마트 계약은 비트코인 발전 과정에서 피할 수 없다며, 전용 오퍼레이션 코드가 아닌 OP_CAT을 활용한 스마트 계약 가능성 탐색을 권유했다.
2021년
다음은 제레미 루빈이 2021년 7월 6일, 양자 보안 관점에서 OP_CAT에 대해 설명한 글이다. 제레미 루빈은 비트코인 개발자일 뿐 아니라 Sapio라는 비트코인 스마트 계약 프로그래밍 언어 개발에 집중하는 비트코인 연구 조직 Judica의 설립자이기도 하다.
메일과 블로그 포스트에서 제레미 루빈은 OP_CAT 오퍼레이션 코드와 Lamport 서명을 활용해 비트코인의 양자 검증을 수행하는 방법을 논의했다. 먼저 그는 이전 블로그에서 비트코인 스크립트 산술과 Lamport 서명을 이용해 5바이트 값을 등록하는 방법을 설명한 바 있다. 이 방법은 깔끔하지만 한계가 있다. 제레미 루빈은 "더 긴 정보에 서명할 수 있다면 어떨까? 특히 최대 20바이트에 서명할 수 있다면 양자 보안 HASH160 요약에 서명할 수 있다"고 제안했다.
그는 HASH160 요약에 서명하는 의미를 더 깊이 탐구하며, 양자 컴퓨터가 ECDSA를 해킹하더라도 개인키만 유출되고 실제 서명 내용을 변경할 수는 없다고 설명했다. 이를 위해 암호학자 매다스 비르자(Madars Virza)와 상의했고 긍정적인 답변을 받았다.
제레미 루빈은 "ECDSA 서명이 양자 저항 서명 알고리즘으로 서명되도록 요구한다면, 우리는 양자 저항 비트코인을 가질 수 있다"고 지적했다. 이전에 논의된 5바이트 서명 방식은 사실 양자 안전 Lamport 서명이지만, 아쉽게도 이 방법은 최소 20개의 연속 바이트가 필요하다.
따라서 제레미 루빈은 OP_CAT과 유사한 어떤 기능이 필요하다고 제안했다. 글에서는 OP_CAT을 segwit v0에 직접 소프트포크할 수 없다고 설명하며, 스택을 수정하기 때문이라고 했다. 간소화를 위해 저자는 새로운 오퍼레이션 코드 OP_SUBSTRINGEQUALVERIFY를 사용하는 방법을 보여주었는데, 이는 의미론적 검증을 통해 문자열의 특정 부분이 동일한지 확인한다.
2021년 11월 5일 애틀랜타 비트코인 컨퍼런스에서 제레미 루빈과 앤드류 필스트라는 연사로 나서 OP_CAT 오퍼레이션 코드 재도입 제안을 논의하며, 비트코인 맥락에서 OP_CAT의 중요성과 양자 보안, 복잡한 스마트 계약 작성 측면에서의 잠재력을 강조했다. 예를 들어 CAT과 Schnorr 서명 검증 오퍼레이션 코드를 결합하면 이론적으로 비재귀적 스마트 계약을 구현할 수 있다. 이는 거래 데이터의 SHA2 해시를 직접 스택에 넣는 것을 가능하게 하며, 이를 통해 거래의 일부분에 일정한 제약을 가할 수 있다.
논의에서는 OP_CAT 재도입이 비트코인을 일부 측면에서 복잡하게 만들 수 있지만 동시에 새로운 기능과 가능성을 가져올 수 있다고도 언급했다. OP_CAT 재도입은 과거의 메모리 폭발 문제와 같은 문제를 피하기 위해 신중하게 고려되어야 한다.
2022년
2022년 5월 18일 비트코인 개발자 메일링 리스트에서 2010년 비트코인에서 제거된 OP_CAT 오퍼레이션 코드 재도입에 관한 논의에서, 개발자 ZmnSCPxj는 불가피한 재귀적 스마트 계약을 구현하기 위해 OP_CAT을 OP_TX, OP_CHECKSIGFROMSTACK(CSFS) 등 제안된 오퍼레이션 코드와 결합해야 한다고 주장했다. 재귀적 스마트 계약은 비트코인 합의 규칙을 활용해 계약에 수신된 모든 비트코인이 동일한 계약 내에서만 사용될 수 있도록 보장한다.
재귀적 스마트 계약은 거래 내성(transaction introspection) 기술에 의존하는데, 이는 오퍼레이션 코드가 자신을 실행하는 거래의 일부를 분석할 수 있어야 한다는 것이다. 기존 오퍼레이션 코드는 제한된 내성만 제공한다. 재귀적 스마트 계약을 만들기 위해선 이전 출력과 다음 출력이 동일해야 함을 보장해야 한다. 따라서 이전 출력이나 다음 출력, 혹은 둘 다 구성 요소로부터 동적으로 생성되어야 하며, 이것이 바로 CAT 또는 유사 구조가 재귀적 스마트 계약에 필요한 이유다.
나다브 이브기(Nadav Ivgi)는 재귀적 스마트 계약 생성 시 여전히 CAT이 해시 문제 해결에 필요하다고 지적하며, 이는 출력 내성(output introspection)에 초점을 맞춘 CTV 및 APO 기능들도 CAT과 결합해 재귀적 스마트 계약을 만들 수 있음을 의미한다고 말했다. 이브기는 탭루트 기능과 함께 사용할 경우 다음 출력을 통해 이전 출력을 검증함으로써 스마트 계약 스크립트 작성을 용이하게 만들 수 있으며, 두 가지 재귀적 스마트 계약 예시 링크를 제공했다.
ZmnSCPxj는 이브기의 분석에 동의하면서도 비트코인에서 재귀적 스마트 계약을 활성화하는 위험에 대한 우려를 재확인했다. 다만 후속 게시물에서 재귀적 스마트 계약은 실제로 튜링 완전성이 아니기 때문에 안전할 수도 있다고 언급했다. 러셀 오코너(Russell O'Connor)는 앤드류 필스트라의 글을 인용하며, CAT 자체가 기존 비트코인 기능과 결합하면 비재귀적 스마트 계약을 충분히 만들 수 있으며, 이론적으로 비트코인에 다시 추가된다면 스스로 재귀적 스마트 계약도 만들 수 있을 가능성이 있다고 설명했다.
2023년
1월, 앤서니 타운스(Anthony Towns)는 사람들의 소프트포크 및 기타 주요 프로토콜 변경을 테스트하기 위해 Bitcoin Core를 복제한 Bitcoin Inquisition을 출시했다. 이는 기본적으로 signet에서 실행되도록 설계되었다. 2023년 말까지 Bitcoin Inquisition은 여러 제안을 지원했으며, OP_CAT, OP_VAULT 및 64바이트 거래 제한을 위한 PR(풀 리퀘스트)이 코드베이스에 제출되어 테스트 플랫폼의 기능이 추가로 확장될 전망이다.
2023년 8월 23일 Lightning-Dev 메일 리스트에서 토머스 보겔틴(Thomas Voegtlin)은 만료된 백업 상태에 대한 사기 증명(fraud proof) 아이디어를 제안했다. 보겔틴은 비트코인에 OP_CHECKSIGFROMSTACK(CSFS)과 OP_CAT 오퍼레이션 코드를 소프트포크 방식으로 추가하면 체인 상에서 이러한 사기 증명을 사용할 수 있다고 지적했다. 이 제안은 많은 논의를 불러일으켰으며, 피터 Todd는 이 기본 메커니즘이 제한적이지 않고 LN에만 국한되지 않아 다양한 프로토콜에 유용할 수 있다고 말했다. 다만 여기서는 더 간단한 메커니즘에 대해서는 다루지 않는다.
10월이 되자 러스티 러셀(Rusty Russell)은 비트코인 스크립트 언어 변경을 통한 일반적 스마트 계약에 관한 연구를 진행했다. 동시에 매우 중요한 것은, 이단 하일먼과 아민 사부리가 OP_CAT 오퍼레이션 코드 도입을 제안하는 BIP 초안을 공동으로 발표했다. 이 두 주제에 대한 논의는 11월까지 이어졌다.
2024년
2024년 1월, Quantum Cats는 OP_CAT 관련 BIP와 비트코인 프로세스에 대한 논의를 새로운 수준으로 견인하는 데 성공했다.
커뮤니티와의 소통에서 Bitcoin Core 개발자 아바 초우(Ava Chow)는 "나는 CTV가 대략적 합의(ruff consensus)라고 생각하지 않는다. 실제로 txhash나 CAT 같은 다른 더 일반적인 스마트 계약 제안이 더 가깝다고 본다. 하지만 나는 논의를 면밀히 추적하지 않았다"고 말했다.
기여 횟수 기준으로 현재 아바 초우(@achow101)는 Bitcoin Core 코드 기여자 중 5위를 차지하며, 총 1292회의 코드 제출 기록을 보유하고 있으며, 소수의 코드 병합 권한을 가진 인물 중 하나이기도 하다. 따라서 개발자 커뮤니티 내에서도 영향력이 매우 크다.
"나는 OP_CAT 활성화를 제안하는 것이 아니다. 나는 OP_CAT이 합의에 도달할 가능성이 매우 높은 오퍼레이션 코드이기 때문에 지지한다. OP_CAT 상황을 잘 모른다면, 내가 이 이미지에 요약해두었다"고 Taproot Wizard 공동 창립자 에릭 월(Eric Wall, @ercwl)이 말했다.
그러나 아바 초우는 OP_CAT 구현에 대해 절대적인 동의를 표한 것은 아니다. "내가 이미 말했듯이, 어떤 스마트 계약 제안도 대략적 합의에 가깝거나 도달했다고 생각하지 않는다. 그러한 제안을 활성화하려는 시도를 해서는 안 된다"고 말했다.
10줄의 코드로 비트코인에 스마트 계약 구현
Taproot Wizard 공동 창립자 에릭 월(@ercwl)의 말처럼 "사람들은 깨닫지 못하고 있지만, OP_CAT은 실제로 비트코인 상의 zkrollup 구성 요소 중 하나다."
OP_CAT의 재도입은 BitVM과 같은 프로젝트에 강력한 도구를 제공한다. 최근 BitVM이 제시한 개념인 비트코인 상에서 임의의 계산을 검증하는 것은 OP_CAT 덕분에 더 간단하고 효율적으로 구현될 수 있다. 이로써 비트코인 생태계는 더 일반적이고 표현력 있는 스마트 계약을 만들 수 있게 된다.
OP_CAT을 통해 특정 비트코인 출력에 대해 사전 조건을 설정하는所谓 스마트 계약을 구현할 수 있다. 이는 Blockstream의 Ark와 같은 새로운 확장 방법뿐 아니라, 스마트 계약에 의존하는 많은 다른 혁신적 방법들을 가능하게 한다. 또한 이는 비트코인이 단순한 결제 네트워크를 넘어 다기능적이고 확장 가능한 컴퓨팅 플랫폼이 될 수 있음을 의미한다.
비록 Taproot Wizard 공동 창립자 에릭 월은 BitVM의 개념에 대해 열광하지만, 그는 이 제안이 엄청난 오버헤드와 긴 구현 주기로 인해 비트코인의 '기술적 사각길(technical dead end)'이 될 수 있다고 생각한다. 그는 BitVM이 커뮤니티의 주의를 산만하게 하고 진정한 발전을 방해할까 걱정한다. 그럼에도 불구하고 BitVM 제안은 블록체인 기술과 스마트 계약 분야에서의 활발한 탐색과 혁신 정신을 보여준다.
실제로 Taproot Wizard 프로젝트 팀은 자체적으로 비트코인 상에서 레이어2 솔루션을 구현하기 위해 노력하고 있으며, 이전 Space에서 750만 달러의 펀딩을 완료했으며, 이 자금은 비트코인 확장 방안 연구에 사용될 예정이라고 밝혔다.
따라서 OP_CAT의 소프트포크는 그들에게도 중요한 한 걸음이 될 것이다. 에릭 월은 이전에 StarkNet 재단 이사회 멤버였으며, 허가 없이도 사용 가능한 결제 계층 위에서 탈중앙화 금융을 구축하는 데 큰 관심을 가지고 있다. 그래서 2019년 이더리움이 등장하자 자연스럽게 이더리움의 DeFi 분야에 매료되었다.
2019년 zk-Rollups나 낙관적 사기 증명(optimistic fraud proof)을 사용해 이더리움과 다른 블록체인을 확장할 수 있다는 것이 명확해지자, 비트코인의 DeFi 탐색은 거의 완전히 포기된 상태였다. 'zk-Rollup 확장을 비트코인에 적용할 수 있을까?'라는 질문을 연구하던 월은 결국 이더리움의 DeFi를 지지하게 되었다. 하지만 궁극적으로는 이러한 시스템과 기술적 이점을 비트코인으로 가져오기 위해 노력하고 있다.
또한 bitcointalk 포럼의 OP_CAT 관련 토론 글에서 QED 프로젝트 창립자 카터 펠드먼(Carter Feldman, @cmpeq)은 비트코인 스크립트에서 이 오퍼레이션 코드를 어떻게 활용할 계획인지, 그리고 증인 스택의 평균 바이트 수와 비용 산정을 계산했는지 질문받았다.
카터 펠드먼은 이것이 다소 비쌀 수 있음을 인지하고 있지만, 머클 증명은 자신의 프로젝트에서 비트코인 상의 zk 레이어2 일부로 무신뢰 락킹 스크립트 또는 훅 시스템을 구축하는 데 주로 사용된다고 설명했다. 이 시스템은 주어진 인출 트리 루트(제로노울리지 증명의 공개 입력) 하에서 특정 주소로 일정량의 비트코인을 인출할 수 있음을 입증하는 것을 목표로 한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
BlockBeats
