비트코인 스테이킹: 기술 개요 및 보안 분석
최근 Babylon이 Testnet-4에서 비트코인 스테이킹 활동을 시작하면서 커뮤니티 내에서 비트코인 스테이킹에 대한 논의가 활발해지고 있습니다. 오늘 Chakra 리서치 팀은 최신 비트코인 스테이킹 방식에 대해 알아보겠습니다.
Babylon의 최근 Testnet-4에서는 스테이킹 과정이 세 가지 유형의 트랜잭션으로 나뉩니다. 즉, 스테이킹 트랜잭션(Staking Tx), 언바운딩 트랜잭션(Unbonding Tx), 슬래싱 트랜잭션(Slashing Tx)입니다. 각각의 트랜잭션은 세 가지 형태의 비트코인 출력을 생성합니다. 즉, 스테이킹 출력(Staking Output), 언바운딩 출력(Unbonding Output), 슬래싱 출력(Slashing Output)입니다. 전환 과정은 아래 그림과 같습니다.
스테이킹 트랜잭션
스테이킹 트랜잭션은 두 개의 특수한 출력을 포함해야 합니다. 첫 번째는 스테이킹 자산을 보유하는 Taproot 출력이며, 반드시 Babylon에서 정의한 BTC 스테이킹 스크립트를 포함해야 합니다. 두 번째는 OP_RETURN을 통해 Babylon 스테이킹 식별 정보를 저장하는 제로 금액 출력(zero amount output)입니다.
아래 이미지는 스테이킹 트랜잭션의 예시를 보여줍니다. 첫 번째 출력은 스테이킹 출력이며, 두 번째는 OP_RETURN 출력이고, 세 번째는 잔돈 출력(change output)입니다.
스테이킹 출력
스테이킹 출력은 Taproot 출력이며, Chakra가 이전에 작성한 기사에서도 언급했듯이,
Taproot 출력은 키 경로 지불(Key Path Spending)와 스크립트 경로 지불(Script Path Spending)이라는 두 가지 지불 방식을 제공합니다. Babylon은 내부 키를 "Nothing Up My Sleeve"(NUMS) 점으로 설정함으로써 키 경로 지불을 비활성화하고, 스테이킹 출력은 오직 스크립트 경로를 통해서만 사용될 수 있도록 합니다.
스테이킹 출력은 다음 세 가지 스크립트 경로를 통해 사용될 수 있으며, 각각은 위의 프로세스 다이어그램에 대응됩니다:
1. 타임락 경로
타임락 경로는 스테이킹 기능을 구현할 뿐 아니라 활성 보장을 위한 수단이기도 합니다.
<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY
타임락 스크립트는 스테이커의 BTC를 일정 블록 수만큼 잠금 상태로 유지합니다. 타임락 경로는 다른 외부 실체를 필요로 하지 않으므로, 스테이커에게 활성 보장을 제공합니다. 최종성 제공자(Finality Provider)나 커벤티 위원회(Covenant Committee)가 비활동 상태가 되더라도, 스테이커는 잠금 기간 이후에 자신의 BTC 자산을 회수할 수 있습니다.
2. 언바운딩 경로
BTC가 타임락에 의해 잠겨 있는 경우, 사용자는 어떻게 조기에 스테이킹을 종료할 수 있을까요? Babylon은 언바운딩 경로를 도입하여 이를 해결합니다.
<StakerPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_GREATERTHANOREQUAL
이 경로는 스테이커의 서명뿐 아니라, 커벤티 위원회의 구성원 중 CovenantThreshold 이상의 서명도 필요로 합니다. 커벤티 위원회를 도입한 주된 이유는 인위적으로 언바운딩 기간을 만들어, 스테이커가 언바운딩 경로를 이용해 처벌을 회피하는 것을 방지하기 위해서입니다.
3. 처벌 경로 (슬래싱 경로)
PoS의 보안을 확보하기 위해선 처벌 메커니즘이 필수적입니다. 최종성 제공자가 악의적인 행동을 할 경우, 본인 및 위임받은 자금을 몰수하여 경제적 안정성을 제공해야 합니다. Babylon은 처벌 경로를 도입함으로써 이러한 처벌 기능을 제공합니다.
<StakerPk> OP_CHECKSIGVERIFY
<FinalityProviderPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_GREATERTHANOREQUAL
스테이킹 상태가 Active로 전환되기 전, 스테이커는 최종성 제공자의 악의적 행동 시에도 서명을 거부함으로써 BTC 손실을 피하려는 상황을 막기 위해, 미리 처벌 경로 트랜잭션에 서명해야 합니다. 스테이커의 서명을 받은 후, 커벤티 위원회는 먼저 서명을 검증하고 유효하다고 판단되면 자신들의 서명을 공개합니다.
비트코인 스테이킹에서 처벌 가능한 행위란 최종성 제공자가 동일한 높이에서 두 개의 충돌하는 블록에 서명하는 것입니다. 이때 어떤 사용자라도 EOTS를 통해 악의적인 최종성 제공자의 개인 키를 추출할 수 있습니다. 스테이커와 커벤티는 이미 처벌 트랜잭션에 사전 서명을 했기 때문에, 악의적인 최종성 제공자의 개인 키를 얻은 사용자는 해당 트랜잭션에 서명하여 처벌 경로를 통해 일부 스테이킹 자금을 소각 주소(burn address)로 보내 처벌할 수 있습니다.
OP_RETURN 출력
Taproot 출력은 작은 ScriptPubKey로 복잡한 사용 조건을 표현할 수 있지만, 이로 인해 비트코인 네트워크 내에서 스테이킹 트랜잭션과 기타 트랜잭션을 구분하는 것이 어려워집니다. 따라서 사용자가 이러한 정보를 기반으로 처벌 트랜잭션을 식별할 수 있도록, 스테이킹 관련 정보를 다른 방법으로 공개할 필요가 있습니다.
Babylon은 공개해야 할 정보를 직렬화하여 이를 OP_RETURN 스크립트에 삽입하고, 스테이킹 트랜잭션의 다른 출력에 추가합니다. 형식은 아래 그림과 같으며, 데이터는 반드시 Taproot 스크립트의 데이터와 일치해야 합니다.
type V0OpReturnData struct {
MagicBytes []byte
Version byte
StakerPublicKey []byte
FinalityProviderPublicKey []byte
StakingTime []byte
}
이전 트랜잭션 스냅샷에 따르면, OP_RETURN 출력이 담고 있는 유효 데이터는 총 4+1+32+32+2=71바이트입니다. 그림에서 스테이킹 트랜잭션의 FinalityProviderPublicKey는 f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81이며, 이것은 Chakra에 속합니다.
MagicBytes는 스테이킹 트랜잭션을 신속하게 식별하기 위한 용도이며, Version은 향후 업데이트를 위해 예약된 필드로, 서로 다른 버전을 구분하기 위해 사용됩니다.
언바운딩 트랜잭션
스테이커가 자신의 스테이킹된 BTC를 조기에 해제하려는 경우, 스테이킹 출력 내의 언바운딩 경로를 사용하여 언바운딩 트랜잭션을 제출할 수 있습니다. 언바운딩 트랜잭션은 단 하나의 스테이킹 트랜잭션만을 입력으로 받아들이며, 단 하나의 출력만 생성하고, 이 출력은 언바운딩 스크립트로 연결된 Taproot 출력이어야 합니다.
다음은 이전의 스테이킹 출력에 대응하는 언바운딩 트랜잭션의 스크린샷입니다.
여기서 마지막에서 두 번째 필드의 접두사가 '20'으로 시작하는 부분은 언바운딩 경로의 tapscript이며, 접두사가 'c1'로 시작하는 부분은 Taproot 내부 키와 언바운딩 경로의 Merkle Proof입니다. 여기서 NUMS 포인트 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0를 명확히 확인할 수 있습니다. 언바운딩 트랜잭션의 Witness 필드에서는 스테이커의 서명과 커벤티 위원회의 서명을 관찰할 수 있습니다.
언바운딩 출력은 두 가지 조건 하에서 사용될 수 있습니다. 즉, 타임락 경로와 처벌 경로인데, 이 두 경로는 스테이킹 출력의 경로와 동일합니다. 더 높은 수준에서 보면, 언바운딩 출력은 스테이커가 즉시 자금을 인출하여 처벌을 회피하는 것을 방지하기 위한 중간 상태이며, 궁극적으로 인출 트랜잭션으로 가는 안정 상태를 만듭니다.
처벌 트랜잭션
처벌 트랜잭션은 스테이킹 트랜잭션이나 언바운딩 트랜잭션을 입력으로 받아 Taproot 스크립트의 처벌 경로를 통해 사용되며, 두 개의 출력을 생성합니다. 하나의 출력은 일부 스테이킹된 BTC를 소각 주소로 보내고, 다른 출력은 나머지 BTC를 스테이커에게 반환합니다.
더 엄밀히 말하면, Babylon은 스테이커가 스테이킹한 모든 BTC를 한 번에 소각하는 것이 아니라, 부적절한 행동에 대해 부분 몰수를 시행합니다. 이러한 접근법은 더 높은 오류 허용 능력을 제공하며, 스테이커의 이익을 보호합니다.
처벌 트랜잭션은 스테이커, 커벤티 위원회, 최종성 제공자의 공동 서명 하에서만 발생할 수 있습니다. 따라서 개별 참여자가 공격당하더라도 전체 스테이킹 시스템이 붕괴되지 않습니다. 처벌 트랜잭션은 억제 장치 역할을 하며, 경제적으로 참가자들의 악의적 행동을 방지합니다. 부정행위에 대한 처벌이 잠재적 이득보다 크다면, 참가자들은 규칙을 따를 가능성이 높아집니다.
보안 분석
Babylon과 관련된 보안은 두 가지 유형이 있습니다.
첫 번째 보안은 스테이커와 관련되며, 스테이커와 그가 위임한 최종성 제공자가 어떠한 악의적 행동도 하지 않는 한, 스테이킹 자산이 결코 처벌되지 않도록 보장합니다.
두 번째 보안은 PoS 시스템 자체와 관련되며, 참가자가 악의적으로 행동할 경우 프로토콜이 이를 식별하고 처벌할 수 있어야 한다는 것을 보장합니다.
스테이커의 관점
스테이커 입장에서 보면, Babylon의 스테이킹 트랜잭션을 통해 BTC를 스테이킹한 이후, 자금 이전은 세 가지 방식만 존재합니다.
첫 번째는 타임락 경로로, 사용자 본인의 서명만 있으면 자금을 인출할 수 있습니다. 이는 FP와 Babylon이 운영을 중단하더라도 스테이킹 기간 종료 후 스테이커가 원래의 BTC를 회수할 수 있음을 보장합니다.
두 번째는 언바운딩 경로로서 중간 상태를 만들고, 더 짧은 시간 내에 자금을 해제할 수 있게 해줍니다. 이는 스테이커가 조기에 자금을 회수할 수 있는 기능을 제공합니다.
세 번째는 처벌 경로로, 스테이커의 이익을 침해할 수 있는 유일한 경로입니다. 외부 공격자가 처벌 경로를 공격하려면, 스테이커의 서명, 최종성 제공자의 서명, 그리고 커벤티 위원회의 임계값 이상의 서명을 동시에 제공해야 하므로, 매우 어렵습니다. 커벤티 위원회가 악의적이더라도 최종성 제공자가 성실하다면, 스테이커의 BTC는 안전합니다.
PoS 시스템의 관점
PoS 시스템 측면에서 보면, 보안은 최종성 제공자가 악의적인 행동을 할 때 이를 처벌할 수 있는 능력에서 비롯됩니다.
Babylon은 EOTS 메커니즘을 사용하며, 최종성 제공자가 하나의 블록에 대해 이중 서명을 할 경우, 누구든지 두 개의 서로 다른 서명으로부터 최종성 제공자의 개인 키를 추출할 수 있습니다. 이를 통해 처벌 트랜잭션에 서명하고 제출함으로써, 최종성 제공자가 보유한 모든 투표권에 해당하는 BTC의 일부를 처벌할 수 있습니다.
이러한 처벌 조치는 최종성 제공자의 악의적 행동을 억제하며, 그들의 인센티브를 Babylon과 연결된 PoS 합의 서비스에 최종성을 제공하는 것과 일치시킵니다. 이는 많은 스테이킹된 TVL을 보유한 PoS 시스템의 보안을 확보합니다.
앞으로 Chakra는 Babylon과 계속 협력하여 일련의 스테이킹 활동을 진행하며, 사용자들에게 다중 수익을 제공하고 유동성 및 상호 운용성 문제를 해결함으로써, 모든 암호화 생태계에서 비트코인의 거대한 가치를 실현하겠습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@ChakraChain
