저자: 앙투안 푸앵소
출처: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
최근에 나는 Matt Corallo의 " 합의 정리 " 제안을 검토해 왔습니다. 나는 알아내는 데 관심이 있습니다:
- 제안서에서 해결하려는 버그가 얼마나 심각한가요?
- 제안된 수정 사항이 최악의 시나리오를 얼마나 개선합니까?
- 5년을 더 경험한 후, 더 잘할 수 있을까요? (역자 주: Matt의 제안은 2019년에 이루어졌습니다.)
- 해결할만한 가치가 있는 것이 또 있습니까?
간단히 말해서 : 내 생각엔 그 버그들은 나쁜 것 같아요. 최악의 경우 블록 검증 시간이 중요합니다. 나는 또한 시간 왜곡 취약성을 수정하는 것이 사람들이 흔히 인정하는 것보다 훨씬 더 중요하다고 생각합니다. 마지막으로, 블록 높이 198 3702 이후에 BIP30 검증을 피하기 위한 수정 사항을 포함할 수 있으며 레거시 트랜잭션 크기에 대한 추가 제한은 블록 검증 시간에 유용한 안전 마진을 제공할 수 있다고 생각합니다.
나는 이 기사를 사용하여 합의 정리 제안이 해결하고자 하는 프로토콜 버그에 대한 토론을 촉진하기를 희망합니다. 제안된 각 완화 조치에 대한 전화 의견과 의견은 물론 더 많은 수정 사항에 대한 잠재적인 제안을 보내주시면 감사하겠습니다. 블록 검증 시간에 관한 섹션이 크게 단축되었습니다. 일부 수치를 공개적으로 공유하겠지만, 블록을 깨는 전략의 세부 사항은 비트코인 코어의 정규 기여자와 소수의 비트코인 프로토콜 개발자에게만 공유됩니다.
시간 왜곡 취약성
시간 왜곡 취약성은 난이도 조정 주기가 겹치지 않는다는 사실을 설명합니다. 채굴자는 목표 조정 기간의 마지막 블록의 타임스탬프를 최대한 앞으로(즉, 지금으로부터 2시간) 이동하는 동시에 다른 모든 블록의 타임스탬프를 최대한 뒤로 이동함으로써 이를 활용할 수 있는 한 가지 기능이 있습니다. 인위적으로 난이도를 낮추는 것입니다. 이 stackexchange 답변에는 더 자세한 설명이 있습니다.
얼마나 나쁜가요?
이것이 상황을 얼마나 악화시키는지, 그리고 그것이 정확히 무엇을 하는지 생각해 보는 것은 흥미롭습니다. 어떤 경우든, 채굴자는 타임워프 취약점을 악용하지 않고도 항상 타임스탬프를 유지하여 타임스탬프가 진행되는 것을 방지할 수 있습니다. 그러나 난이도 조정 주기의 첫 번째 블록의 타임스탬프가 이전 주기의 마지막 블록보다 일찍 설정되지 않은 경우 난이도 조정 메커니즘을 사용하면 필연적으로 채굴 난이도가 증가하게 됩니다. 반대로, 한 주기의 첫 번째 블록의 타임스탬프를 이전 주기의 마지막 블록보다 일찍 설정함으로써 공격자는 낮은 난이도(이 라운드의 결과)를 활용하면서 난이도를 더욱 줄일 수 있습니다.
실제로 공격자는 공격을 시작한 지 한 달 남짓 만에 네트워크에 치명적인 피해를 입힐 수 있다. 시점 t 와 기간 N 부터 시작하여 공격자는 기간 N+1 이 끝날 때까지 공격을 이미 절반으로 줄일 수 있습니다. 이를 통해 일주일 이내에 N+2 기간 동안 모든 블록을 채굴할 수 있어 난이도가 2.5배 더 낮아집니다. 공격자는 40일 이내에 난이도를 1로 낮추고 한 번에 수백만 개의 블록을 채굴할 수 있습니다. 남은 모든 블록 보조금을 없애는 것 외에도 타임록에 의존하는 모든 L2 프로토콜의 보안이 파괴되고 DoS 공격 표면이 악화됩니다(예: UTxO 세트 확장과 결합될 수 있음).
MTP(과거 시간 중앙값)는 기껏해야 공격자에게 사소한 성가심이므로 여기에서는 무시됩니다. 그러나 이는 또한 질문을 제기합니다. 이러한 공격은 대부분의 채굴 해시레이트 제어하는 것을 전제로 하지만 작은 해시레이트 유리한 전략을 활용하려고 할 수 있습니까? 예를 들어 조정 기간의 마지막 블록의 타임스탬프를 최대한 앞으로 이동하고 다른 모든 블록의 타임스탬프(MTP 규칙에서 허용하는 범위 내)를 최대한 뒤로 이동합니다. 기술적으로 이것은 채굴자에게 (상당한) 비용이 들지 않지만 그들(및 다른 채굴자)에게 약간 더 큰 블록 보상을 제공 할 수 있습니다 (미래의 채굴자를 희생하여). 이러한 전략을 사용하면 소량의 채굴 해시레이트 에 대한 한계 이익은 무시할 수 있는 것으로 나타났습니다. 따라서 채굴자가 즉석에서 시간 왜곡 취약점을 악용하려고 시도하지 않을 것이라고 합리적으로 기대할 수 있습니다.
고쳐야 할까요?
어떤 사람들은 광부들이 의도적으로 발에 총을 쏘지 않았다고 주장합니다. 실제로 그들이 채굴하려는 체인을 죽일 것이라고 기대하는 것은 표시되지 않습니다. 대신, 단순히 블록 생성 속도를 X%만큼 증가시키는 균형에 도달할 수도 있습니다. 채굴자가 노드 간 합의 규칙을 변경하지 않고 사용 가능한 블록 공간을 늘릴 수 있다는 정치적 의미를 판단하는 것은 독자의 몫입니다. 그러나 우리는 채굴자 카르텔(연합)이 타임워프 취약점을 이용하여 난이도를 조금이라도 낮출 수 있다면 몇 주 안에 네트워크를 붕괴 직전에 놓을 수 있다는 점을 지적하고 싶습니다.
또 다른 일반적인 주장은 공격이 명백하고 시간이 오래 걸리기 때문에 긴급하지 않다는 것입니다. 나는 사용자가 자신이 살고 있는 합의 규칙을 벗어나 특정 높이에 있는 블록의 유효성을 조정하고 결정하도록 요구하는 주장에 매우 회의적입니다. 게다가 비트코인의 합의 규칙을 조정하고 변경하는 데 한 달은 그리 긴 시간이 아닙니다. 그리고 앞서 언급했듯이, 그렇게 하기 위해 폭넓은 합의가 이루어질 수 있을지도 불확실합니다. 사용자는 낮은 수수료를 좋아하고 채굴자는 더 많은 보조금을 원합니다. 현재 채굴 해시레이트 에 대한 통제권 분포와 기하급수적으로 감소하는 블록 보조금을 고려하면, 시간 왜곡 취약점을 악용하려는 카르텔이 형성될 수 있다고 생각하는 것은 무리가 아닙니다.
마지막으로 공격에는 채굴 해시레이트 의 상당 부분이 참여해야 하기 때문에 긴급하지 않다고 주장하는 사람도 있고 긴급하지 않다고 생각하는 사람도 있습니다. 나는 이것이 너무 과소평가되었다고 생각한다. 이유 Time Warp 취약점은 공격이 가할 수 있는 피해를 51% 크게 증가시킵니다. 원래 51% 공격은 일시적으로 거래를 검열할 수만 있었습니다. 하지만 타임워프 공격을 사용하면 네트워크 전체가 파괴될 수 있습니다.
더 나은 해결책을 찾을 수 있을까요?
어쩌면 그렇지 않을 수도 있습니다. 제안된 수정 사항은 간단합니다. 난이도 조정 주기를 겹치게 만드는 것입니다. Matt가 제안한 변경은 가장 간단하고 가장 중요합니다. 이전 주기의 마지막 블록의 타임스탬프를 사용하여 이 주기의 첫 번째 블록의 타임스탬프를 제한합니다.
최악의 경우 블록 검증 시간
악의적으로 제작된 Segwit 이외의 거래는 검증하기가 매우 어렵다는 것은 잘 알려져 있습니다. 블록 검증 시간이 길어지면 채굴자 공격자에게 불공정한 이점을 제공하고, 네트워크 내 블록 전파(및 일관성)를 방해하며, 심지어 블록 가용성에 의존하는 소프트웨어에 해로운 결과를 초래할 수도 있습니다. 이를 위해 합의 정리 제안에는 기존 스크립트 사용에 대한 몇 가지 추가 제한 사항이 포함되어 있습니다.
얼마나 나쁜가요?
아주 나쁜. 최악의 경우, 최신 노트북의 16코어 CPU와 Raspberry Pi 4의 검증에는 1.5시간이 걸리는 블록을 도출할 수 있습니다. 당연한 이유로 여기서는 그러한 블록에 대한 세부 사항과 유사하게 검증하기 어려운 블록을 생성하는 다양한 방법을 생략했습니다. 델빙의 비공개 워크숍 기능을 활용하여 준 비공개 첨부글로 다른 프로토콜 개발자들과 공유하겠습니다. 당신이 알아야 한다고 생각하는데 내가 당신을 포함시키는 것을 잊었다면, 저에게 연락해주세요.
제안은 최악의 시나리오를 얼마나 개선합니까? 보다 효과적인 완화 조치를 도출할 수 있습니까?
합의 정리 제안에 의해 제안된 완화 조치는 내가 생성한 블록을 무효화했을 것입니다. 새로운 제한 사항에 따라 내 노트북에서는 단 5초 만에 최악의 블록이 검증되었습니다. 안전한 측면을 위해 전통적인 거래량에 대한 제한을 추가로 도입할 수 있다고 생각합니다.
제안된 완화 조치와 관련하여 "몰수"(그렇지 않으면 유효한 스크립트를 사용할 수 없게 되는 경우)에 대한 우려도 있습니다. 나는 이러한 우려가 타당하며 특정 블록 높이 이후에 생성된 스크립트에만 새로운 규칙을 적용함으로써 해결될 수 있다고 생각합니다.
64바이트 트랜잭션을 이용한 머클 트리 공격
비트코인 블록에서 Merkle 루트가 계산되는 방식에 따라 두 가지 (알려진) 공격이 남아 있습니다. 둘 다 두 개의 32바이트 해시 값을 연결하는 것과 관련되어 있으므로 연결한 문자열을 비트코인 트랜잭션으로 성공적으로 역직렬화할 수 있어야 합니다. (아마도 가장 유명한) 방법은 라이트 노드를 속여 블록에 의해 확인되지 않은 거래를 수락하도록 하는 것입니다. 64바이트 거래가 블록에 의해 확인되도록(따라서 머클 트리에 의해 커밋됨) 그 다음은 피해자에게 지불되었지만 블록에 의해 확인되지 않은 거래의 txid에 해당합니다. 또 다른 방법은 유효한 블록을 영원히 금지하도록 노드를 속이는 것입니다. 모두 (잘못된) 64바이트 트랜잭션으로 역직렬화할 수 있는 트리 노드 행을 찾습니다. 자세한 내용은 Suhas Daftuar의 이 기사를 참조하세요.
합의 정리 제안은 64바이트 이하의 거래량을 유효하지 않은 거래로 분류하여 두 가지 문제를 동시에 해결할 수 있습니다.
얼마나 나쁜가요?
라이트 노드(또는 사이드체인과 같이 머클 증명을 허용하는 모든 것)에 대한 공격에는 공격에 사용된 비트코인 양에 따라 61~(대략) 75비트 범위의 무차별 대입 검색이 필요합니다. 이는 비용이 많이 들고 간단한 완화 방법이 있습니다. 예를 들어, 코인베이스 거래에 대한 Merkle 증명을 요청하여 Merkle 트리의 깊이를 확인하면 블록에 포함된 거래 수를 알 수 있습니다.
즉, 이번 공격은 "최신 비트코인 채굴 ASIC 해시레이트 14TH/s에 도달할 때" 100만 달러의 비용이 드는 것으로 추정된다 . 이제 ASIC의 해시레이트 400TH/s까지 상승것 같습니다 . 또한 이 공격은 거래에 대한 확인을 원하는 만큼 위조할 수 있습니다. 비용은 단지 SPV 클라이언트를 속이기 위해 가짜 블록을 채굴하는 것인데, 현재는 조금 더 높습니다(80비트).
Bitcoin 노드를 속이는 공격은 컨텍스트 없이 블록 검사를 캐싱하지 않음으로써( CheckBlock() ) Bitcoin Core에서 완화되었습니다. 유효한 거래 생성은 표시되지 않습니다. 첫 번째 거래는 224비트의 무차별 검색이 필요한 코인베이스 거래여야 합니다.
머클 루트가 블록 단위로 계산되는 방식으로 인해 64바이트 트랜잭션은 비트코인의 핵심 취약점입니다. 이로 인해 발생하는 (알려진) 두 가지 공격 모두 완화될 수 있지만 Bitcoin Core에서 컨텍스트 없는 블록 검사를 캐싱하는 동안 이러한 오작동 리스크 피하는 것이 좋을 것입니다.
더 나은 해결책을 찾을 수 있을까요?
64바이트 방법은 트랜잭션에서 잠금 스크립트(아무도 사용할 수 없고 영구적으로 잠겨 있지 않음)가 포함된 출력을 저장하기에 충분하지 않기 때문에 "안전"하지 않습니다. 이는 알려진 목적이 없으며 5년 동안 네트워크 전반에 걸쳐 비표준 거래로 간주되었습니다. 이로 인해 발생하는 취약점과 쓸모가 없다는 점을 고려하면 이를 무효화하는 것이 합리적입니다.
그러나 BIP는 64바이트보다 작은 거래를 무효화할 것을 제안합니다. 비록 쓸모가 없거나 별로 유용하지 않더라도 그러한 거래는 무해합니다. 저는 거래 유형이 소프트 포크 통해 무효화할 만큼 유용하지 않다고 항상 믿어왔습니다.
AJ는 또한 Bitcoin-inquisition에 대한 PR에서 (정확히) 64바이트 길이의 거래를 무효화했습니다 .
위시 리스트
BIP30 검증
BIP34는 모든 블록 연결에서 상대적으로 비용이 많이 드는 BIP30 검사 실행을 일시적으로 방지합니다. 블록 높이 198 3702부터 시작하면 더 이상 BIP34에만 의존할 수 없습니다. 오랜 프로토콜 버그를 해결하기 위해 소프트 포크 제안된다면 지금부터 모든 코인베이스 거래를 완전히 고유하게 만드는 것이 가장 좋습니다.
간단한 해결책은 코인베이스 트랜잭션의 nLockTime 이 생성된 블록의 높이로 설정하는 것입니다. 그러나 채굴자가 배포하기 더 쉬울 수 있는 보다 우회적인 접근 방식이 있습니다. 즉, 모든 코인베이스 거래에서 증인 약속을 강제하는 것입니다(Greg Sanders를 통해). 이 규칙에 예외가 있는지는 확인하지 못했지만, SegWit 이전 코인베이스 거래의 출력이 32 0x00 바이트로 열린 Witness Commitment 헤더를 푸시하게 된다면 매우 놀랄 것입니다.
당신의 "가장 좋아하는" 버그!
이 단계에서는 가능한 한 많은 정리 제안을 수집하고 이와 같은 소프트 포크 테이블에 올라오면 추가할 수 있는 모든 수정 사항을 최대한 자세히 분석했는지 확인하고 싶습니다.
물론 제안은 합리적이어야 합니다. 예를 들어, "서수 금지"는 흥미롭지 않은 제안이며 많은 사람들이 참여할 것 같지 않습니다. 또한, 장기적이며 논란의 여지가 없는 버그에 중점을 두겠습니다. 예를 들어, "검증하는 데 30분 이상 걸리는 블록은 나쁜 상황을 의미한다", "깨진 머클 트리 계산으로 인해 불발 리스크 발생한다", "코인베이스 거래를 진정으로 고유하게 만드는 것"은 전혀 논란의 여지가 없는 것처럼 보입니다. 반면에 "블록 크기 제한을 낮추자"에는 타당한 이유가 있을 수 있지만 나에게는 훨씬 더 논란의 여지가 있습니다.
예를 들어, 제안할 가치가 있다고 확신할 수 없는 두 가지 사항은 다음과 같습니다.
- Segregated Witness v0 트랜잭션에는 표준 SIGHASH 유형 바이트도 있어야 합니다.
- 최악의 시나리오에서 UTXO 세트의 증가를 줄이기 위해 스크립트 공개 키의 크기를 제한합니다.
