원본 링크:
원본 링크:
https://bitcoinops.org/en/topics/soft-fork-activation/
소프트 포크 활성화비트코인 풀 노드가 하나 이상의 합의 규칙을 추가하기 시작하는 순간을 말합니다. 이 전환으로 인해 노드 간에 조정 위험이 발생합니다. 따라서 개발자는 문제의 가능성을 최소화하기 위해 소프트 포크 활성화 메커니즘을 만들고 개선하기 위해 수년 동안 상당한 노력을 기울였습니다.
역사
역사
보조 제목
[2009] 하드코딩된 높이: 컨센서스 레이어 nLockTime 활성화됨
가장 초기에 알려진 소프트 포크는 비트코인 소프트웨어 버전 0.1.6(2009년 11월 출시)에서 구현되었으며 블록 높이 31000에서 활성화되도록 하드코딩되었으며 실제 시간은 2009년 11월 22일이었습니다. 이 하드코딩된 활성화 높이는 Satoshi Nakamoto가 대부분의 개발 작업을 수행했을 때 적어도 하나의 다른 초기 소프트 포크에서 사용되었습니다.
[2011] 하드코딩된 시간 및 수동 개입: BIP12OP_EVAL 실패
Satoshi Nakamoto가 Bitcoin을 떠난 후 Bitcoin에 병합된 첫 번째 소프트 포크 코드는 BIP12OP_EVAL이었습니다. 원래 계획은 컴퓨팅 성능의 50% 미만이 변경을 지원하는 경우 하드 코딩된 시간과 수동 개입을 사용하는 것이었습니다. BIP12에서 인용:
[...] 새로운 고객과 광부는 OP_EVAL을 2012년 2월 1일까지 작동하지 않는 것으로 해석합니다. 이에 앞서 지원되는 채굴자는 자신이 생산하는 블록에 "OP_EVAL"을 작성할 수 있으므로 지원되는 컴퓨팅 성능의 비율을 계산하는 데 편리합니다. 2012년 1월 15일까지 이 변경 사항에 대한 지원이 50% 이하인 경우 OP_EVAL에 대한 지원이 50% 이상일 때까지 활성화가 지연됩니다(대부분의 지원이 이 업그레이드를 활성화하지 않을 것이 분명한 경우 업그레이드가 취소됩니다).
활성화 코드가 병합된 후 롤아웃되기 전에 OP_EVAL에 치명적인 취약점이 있는 것으로 밝혀졌기 때문에 수동 개입이 필요할 수 있습니다. 버그가 수정되는 동안 일부 개발자는 이 강력한 새 opcode에 다른 문제가 있을 수 있다고 우려하여 사람들이 소프트 포크를 포기했습니다.
[2012] 하드코딩 시간과 수동 개입에 대한 또 다른 시도: BIP16 P2SH
OP_EVAL을 대체하기 위한 몇 가지 단순화된 제안이 있습니다(다른 아이디어 중에서 BIP13/16, 17, 18 및 19 참조). 그리고 BIP13/16 Pay to Script Hash(P2SH)는 대부분의 개발자들의 지원을 받았습니다. P2SH는 OP_EVAL과 동일한 활성화 메커니즘을 사용합니다. 원래 계획된 활성화 시간은 2012년 3월 1일이었지만 청구일인 2월 15일까지 마지막 100개 블록의 채굴자 중 50% 미만이 3월까지 BIP16 규칙을 구현할 것이라고 밝혔습니다. 이로 인해 3월 1일에 여전히 BIP16을 구현하고 있던 일부 채굴자가 대다수 채굴자의 블록을 거부함에 따라 "매우 긴 교체 체인"(체인 분할)이 발생했습니다(새로운 규칙을 구현하지 않음). 두 번째 투표 날짜는 수천 블록 뒤인 3월 15일이었습니다. 이번에는 충분한 지지를 받았습니다. 그래서 개발자는 3월 30일 비트코인 0.6.0을 출시했고 활성화 시간을 4월 1일로 정했습니다.
[2012] 하드코딩된 시간: BIP30이 txid 복사를 거부함
P2SH 활성화가 완료된 후 여러 트랜잭션이 동일한 txid를 공유할 수 있음을 발견했습니다. 자체적으로 이 버그는 단순히 버그를 악용하려는 사용자의 자금을 파괴할 뿐 아니라 비트코인의 Merkle 트리 구성의 일부 이상한 동작과 결합하여 노드 간의 합의를 깨뜨릴 수도 있습니다(CVE-2012-2459 참조). . 이 취약점을 수정한 첫 번째 소프트 포크는 BIP30으로, 이전 트랜잭션에 사용되지 않은 출력이 있는 경우 동일한 txid를 가진 후속 트랜잭션을 유효하지 않은 것으로 표시합니다. 이 수정 사항은 개발팀 사이에서 논란의 여지가 없었기 때문에 P2SH 활성화 매개변수를 포함하는 비트코인 0.6.0에서 하드코딩된 시간으로 활성화되었습니다.
[2012] IsSuperMajority(ISM): BIP34 코인베이스 접두사
BIP30은 txid 중복으로 인한 단기 문제를 수정하지만 비트코인 개발자는 이것이 임시방편이라는 것을 알고 있으며 소프트웨어가 새 트랜잭션을 수신할 때마다 사용되지 않은 출력이 있는 모든 트랜잭션의 인덱스를 검색할 이유가 없습니다. 그래서 txid 복제를 실질적인 공격 벡터로 만드는 약점을 제거하기 위한 두 번째 솔루션이 제안되었습니다. BIP34입니다. 이번 업데이트를 위해 개발자들은 BIP16 P2SH와 유사한 채굴자 투표 방식을 사용했지만 이번에는 EIP34를 지원할 준비가 된 채굴자들은 자신의 블록의 nVersion 값을 높여야 합니다. 게다가 개발자들은 비트코인 코드에서 새로운 규칙의 구현을 자동화하여 채굴자들이 업그레이드를 기다리는 동안 소프트 포크를 지원하는 소프트웨어를 출시할 수 있었습니다. BIP34의 이 규칙은 IsSUperMajority()라는 함수로 구현됩니다. 처음에는 단일 활성화 임계값을 포함했으며 도달했을 때 BIP34의 새로운 합의 규칙이 구현되기 시작했습니다.
75% 규칙: 최근 1000개의 블록 중 75%가 비전2 이상인 경우 잘못된 비전 2 블록 거부 시작
이 기능을 개발하는 동안 BIP34가 해결하려는 문제를 결정적으로 수정하는 두 번째 활성화 임계값을 추가하기로 결정했습니다.
95% 규칙: 최근 1000개 블록 중 950개가 비전 2 이상인 경우 모든 비전 1 블록 거부
이전 버전의 블록을 거부하는 규칙의 알려진 문제는 모든 채굴자가 업그레이드하지 않는 한 하루에 몇 개의 유효하지 않은 블록이 있을 수 있다는 것입니다(정확히 채굴자의 95%가 활성화되면 각 블록은 유효하지 않은 확률이 5%입니다). ISM 규칙을 적용하도록 업그레이드된 노드는 이러한 블록을 거부하지만 이전 노드와 라이트 클라이언트는 규칙을 인식하지 못하고 수락합니다. 이로 인해 네트워크는 유효하지 않은 블록 이후에 채굴을 계속하지 않는 채굴자에게 평소보다 더 의존하게 됩니다.
[2015] ISM 및 무검증 채굴: BIP66 엄격한 DER 활성화
2014년 9월 Pieter Wuille는 OpenSSL이 다양한 플랫폼에 대한 DER 인코딩 서명 처리에서 불일치를 발견했습니다. 예를 들어 이것은 Linux 운영 체제에서는 유효성 검사를 통과하지만 Windows 운영 체제에서는 실패하는 블록을 생성하는 데 악용될 수 있습니다. 공격자는 해당 지점에서 체인 분할을 생성합니다. Wuille과 몇몇 다른 개발자들은 비밀리에 패치를 개발하고 소프트 포크로 활성화하여 모든 서명이 동일한 형식을 사용하도록 했습니다. BIP66은 OpenSSL에 대한 비트코인의 의존성을 제거하기 위한 단계로 공개된 바로 이것을 위해 만들어졌습니다(실제 목표, 마침내 2019년에 달성됨). BIP66이 사용자와 개발자로부터 충분한 지원을 얻은 후(대부분은 보안 허점이 존재한다는 사실조차 몰랐음) BIP34와 동일한 ISM 활성화 메커니즘을 사용하여 블록 버전 번호를 v3으로 높이고 95% 임계값을 요구했습니다. 그러면 버전 번호가 거부됩니다.
75% 임계값은 2015년 7월 4일에 도달했으며 블록 높이 363725에서 95% 임계값에 도달했습니다. 모든 노드는 Bitcoin Core v0.10.0 이상의 소프트웨어(또는 호환 구현) 및 구현 새 규칙을 실행하고 있습니다. 그러나 블록 높이 363731에서 업그레이드되지 않은 채굴자가 현재 버전 번호를 포함하지 않는 블록을 생성했으며, 이는 새로운 ISM 활성화 규칙에 따라 유효한 블록이 아닙니다. 하지만 다른 채굴자들은 이 유효하지 않은 블록 이후에도 계속해서 생산했고, 마침내 6개의 유효하지 않은 블록이 있는 체인을 생산했습니다. 이는 업그레이드되지 않은 노드와 많은 라이트 클라이언트가 해당 시점에 유효한 블록에 대한 확인조차 얻지 못한 경우에도 첫 번째 무효 블록의 96개 트랜잭션을 6개의 블록 확인을 누적한 트랜잭션으로 간주한다는 의미입니다. 결국 개발자는 마이닝 풀 운영자에게 연락하여 수동으로 소프트웨어를 다시 시작하고 활성 체인으로 돌아가도록 할 수밖에 없었습니다. 이러한 이벤트는 다음 날 반복되어 세 번의 잘못된 확인이 있는 일부 거래를 남겼습니다. 다행히 이 6개 블록과 3개 블록의 모든 일반 트랜잭션은 나중에 유효한 블록으로 패키징되어 일반 사용자에게 손실이 없습니다.
높이 363731의 원래 유효하지 않은 블록은 단순히 이전 버전 번호를 사용하기 때문에 유효하지 않게 되는 매일 발생하는 것으로 추정되는 블록의 약 5% 중 하나입니다. 다음 블록이 업그레이드되지 않은 채굴자에 의해 채굴될 확률도 5%이므로 두 개의 연속 블록이 버전 번호 취소된 블록일 확률은 0.25%입니다. 채굴자의 95%가 업그레이드된 것을 감안할 때 6개의 연속 블록이 유효하지 않은 버전 번호가 있는 블록일 확률은 0.000002%이지만 범인은 아직 극심한 불운이 아닙니다. 고려되지 않은 것은 광부가 "검증 없는 채굴"을 할 수 있다는 것입니다. 즉, 광부가 새 블록을 받은 후 검증 없이 계속 생산하여 약간의 효율성을 향상시킬 수 있습니다. 무검증 마이닝 소프트웨어는 유효하지 않은 블록 버전 번호를 이론적으로 쉽게 처리할 수 있지만, 이 기능은 당시 5개 블록을 마이닝한 마이너가 사용하는 소프트웨어에는 아직 구현되지 않았습니다. 결국 충분한 채굴자들이 검증되지 않은 채굴 소프트웨어를 업그레이드하거나 노드를 업그레이드했고 BIP66 활성화와 관련된 우발적인 체인 분할이 사라졌습니다.
2015년 7월 포크로 이어진 이러한 문제에 대응하여 개발자는 검증 없는 채굴의 필요성을 줄이기 위한 노력을 두 배로 늘렸고 결과적으로 BIP152 압축 블록 및 FIBER 소프트웨어의 릴레이와 같은 결과를 얻었습니다. 개발자들은 또한 나중에 언급할 BIP9 프로토콜인 더 나은 활성화 메커니즘에 대해 생각하기 시작했습니다.
[2015] 마지막 ISM: BIP65OP_CHECKLOCKTIMEVERIFY 활성화됨
BIP66 엄격한 DER 소프트 포크 이전에는 비트코인에 새로운 opcode OP_CHECKLOCKTIMEVERIFY(CLTV)를 추가하기 위해 소프트 포크를 사용하는 것이 제안되었지만 OpenSSL 취약점 복구로 인해 연기되었습니다. 이것은 증분 버전 번호를 사용하는 ISM 메커니즘의 또 다른 약점을 보여줍니다. 채굴자가 최신 제안(비전 n)에 대한 지원 신호를 보내는 경우 모든 이전 제안(예: 비전 n-1)을 암묵적으로 지원합니다. 이로 인해 ISM을 사용하여 동시에 여러 업그레이드를 조정하는 기능이 제한됩니다.
그러나 BIP 66의 활성화와 관련된 몇 가지 문제에도 불구하고 ISM은 BIP65의 지연된 활성화에 다시 한 번 사용되었습니다. 이번에는 더 이상 문제가 없었습니다.
[2016] BIP9 버전 비트: BIP68/112/113 상대 잠금 시간 활성화
BIP9는 ISM의 여러 문제를 해결하기 위해 새로운 활성화 메커니즘을 제안합니다.
불필요하게 채굴자에 대한 페널티: ISM 활성화로 인해 블록 버전 번호가 증가하고 버전 번호를 증가시키지 않은 채굴자가 생성한 블록은 블록이 소프트 포크의 다른 규칙을 위반하지 않더라도 유효하지 않은 것으로 간주됩니다. 예를 들어, 2015년 7월 4일 체인 분할에서 모든 거래는 소프트 포크 규칙을 따랐습니다. 이 채굴자들이 $500,000를 잃은 유일한 이유는 업그레이드가 블록 헤더에 3을 포함해야 하고 업그레이드하지 않았기 때문입니다. 채굴자는 2를 사용했습니다. .
병렬화 어려움: ISM을 사용하면 개발자가 필요하다고 판단하더라도 다른 포크가 신호 수집을 시작하기 전에 한 포크가 완료될 때까지 기다려야 합니다.
실패가 허용되지 않음: ISM은 만료 시간을 설정하지 않습니다. 활성화 신호를 기다리는 노드 소프트웨어가 해제되면 새 소프트웨어를 실행하는 노드는 활성화가 완료될 때까지 신호를 모니터링합니다. 사람들이 이 소프트 포크를 전혀 필요로 하지 않는다고 확신할 수 있는 방법은 없습니다.
예측할 수 없는 활성화 시간: 정확한 활성화 시간을 미리 알 수 없기 때문에 프로토콜 개발자, 가맹점 시스템 관리자 및 마이닝 풀 운영자가 신속하게 필요한 긴급 상황이 발생하더라도 활성화 후 즉시 사용하기 어렵습니다. 응답 질문.
BIP9 버전비트는 이러한 문제를 해결하려고 합니다. 블록 헤더 내부의 비전 필드를 비트 필드로 사용합니다. 이 필드의 데이터는 신호용으로만 사용되며 유효하지 않은 블록의 기반으로 사용되지 않으며 병렬로 설정할 수 있습니다. 이 측정은 2016 블록마다 실행되어 해시 파워의 작은 부분이 95% 지지를 넘길 만큼 운이 좋을 가능성을 압축합니다. 마지막으로 95% 신호 임계값에 도달하면 모든 당사자가 업그레이드를 준비할 수 있도록 활성화 전에 추가 2016 블록(약 2주) "잠금 기간"이 있습니다. 만료 시간 전에 활성화 임계값에 도달하지 않으면 전체 소프트 포크 시도가 종료되고 사용되지 않는 코드는 이후 소프트웨어 릴리스에서 제거될 수 있습니다.
이 활성화 방법은 BIP68 합의 적용 시퀀스 번호, BIP112OP_CHECKSEQUENCEVERIFY 및 BIP113에 정의된 nLockTime의 소프트 포크에서 처음 사용되었습니다. 포크는 빠르게 잠금 단계에 들어간 다음 자동으로 활성화 단계에 들어갔습니다.
[2016-7] BIP9, BIP148 및 BIP91: BIP141/143 분리된 증인 활성화
Segregated Witness 소프트 포크는 BIP9 활성화 매개변수와 함께 출시되었습니다. 소수의 채굴자들이 재빨리 지지를 표명했지만 지지율은 95% 임계값보다 훨씬 낮았습니다. 일부 Bitcoin 사용자는 채굴자가 유용한 새 기능을 부당하게 지연시키고 있다고 느꼈기 때문에 BIP148로 알려진 자발적인 활성화가 개발되었습니다. BIP148의 최종 형식은 특정 날짜부터 segwit을 지원하지 않는 모든 블록을 거부하도록 지정합니다.
BIP148을 구현하는 소프트웨어가 등장한 후 네트워크에는 업그레이드하지 않는 노드, BIP9/141 노드 및 BIP148/141 노드의 세 가지 유형의 노드가 있으며 합의 오류에 빠질 확률은 더욱 커집니다. 채굴자가 segwit을 지원하지 않고 대다수의 사용자가 계속해서 이러한 블록을 유효한 것으로 취급하는 경우 BIP148 사용자는 다른 사용자가 유효하지 않다고 생각하는 비트코인을 받을 수 있습니다. 또한 대다수의 사용자가 BIP148을 지원하지만 채굴자가 BIP148에 의해 유효하지 않은 것으로 간주되는 많은 블록을 계속 생성하는 경우 BIP148을 구현하지 않는 사용자는 BIP148 사용자가 유효하지 않은 것으로 간주하는 비트코인을 수락합니다. 업그레이드는 사용자가 동일한 규칙을 따르고 대부분의 컴퓨팅 성능이 BIP148 규칙을 지원하는 경우에만 안전합니다.
위험을 줄이는 한 가지 방법은 사용자가 segwit 활성화를 강제하는 노드로 업그레이드할 수 있는 충분한 시간을 제공하는 것이지만 BIP148은 목표가 기존 BIP9 프로세스를 트리거하는 것이므로 이를 수행할 수 없습니다. 만료일. BIP148에 대한 잠재적으로 인기가 없는 대안으로 BIP149는 사용자에게 업그레이드를 위해 추가 1년을 제공할 것을 제안합니다. BIP149는 대중의 지지를 많이 받지 못했지만 BIP8을 사용하는 첫 번째 제안이었으며 앞으로 몇 년 동안 더 많은 논의를 촉발시켰습니다.
BIP148이 대중의 상당한 지지를 받기 시작하면서 여러 광부, 거래소 및 업계 인사들은 BIP148을 지원하는 노드와 합의를 유지하면서 분리된 증인을 활성화하기 위한 2단계 제안에 대한 지지를 표명했습니다. 첫 번째 단계는 BIP91로 작성되어 BIP9의 규칙을 개선합니다. 채굴자는 BIP9 비트 필드를 사용하여 임시 규칙을 적용할지 여부를 나타낼 수 있습니다. BIP141/143 분리된 증인에 대한 지원을 알리지 않는 모든 블록을 거부합니다. BIP9와 달리 BIP91의 임계값은 95%에서 80%로 낮아졌으며 모니터링 및 잠금 기간은 2016 블록에서 336 블록으로 줄었습니다.
BIP91이 잠기고 활성화되었습니다. 그러면 BIP141/143이 잠기고 활성화됩니다. 잠기면 BIP148의 필수 지원 조치가 만료됩니다.
광부, 거래소 및 업계 인사들의 이 제안의 두 번째 단계에서는 하드 포크가 필요했고, 많은 개인 사용자와 기업이 격렬하게 반대한 후 제안 서명자들이 철회했습니다.
오늘날까지 사람들은 이러한 사건들과 비슷한 시기에 일어난 다른 사건들이 분리된 증인의 활성화에 얼마나 많은 역할을 했는지에 대해 여전히 논쟁하고 있습니다.
비상 활성화
한 번 이상 합의 코드에서 심각한 버그가 발견되었고 개발자는 활성화 프로세스를 거치지 않고 패치를 릴리스했습니다. 그렇게 하면 합의 실패가 발생할 수 있지만 업그레이드된 노드에 대한 취약성을 즉시 제거합니다. 중요한 이벤트는 다음과 같습니다.
체인 작업을 사용하여 높이를 대체(2010년 7월): 비트코인은 처음에 블록이 가장 많은 체인("가장 긴 체인")을 유효한 체인으로 간주했습니다. 모든 블록의 난이도가 동일하다면 가장 긴 체인이 가장 많은 작업 증명을 축적한 체인이 될 것입니다. 하지만 블록마다 난이도가 다르기 때문에 체인워크 소프트 포크는 비트코인 0.3.3에서 출시되었고 작업 증명이 가장 많이 축적된 체인이 유효한 체인으로 간주됩니다.
스크립트를 우회하는 버그 제거(2010년 7월): Bitcoin은 원래 UTXO를 사용하는 스크립트(scriptSig)와 UTXO를 보호하는 스크립트(scriptPubKey)를 결합하여 동시에 평가했습니다. 이 디자인을 사용하면 잠금 메커니즘이 평가되기 전에 스크립트를 종료할 수 있습니다. 예를 들어 서명을 확인하기 위해 OP_CHECKSIG를 실행하기 전에 성공 상태로 종료합니다. 이 버그는 원래 OP_TRUE OP_RETURN을 사용하는 scriptSig가 모든 사람의 비트코인을 사용할 수 있는 것으로 보고되었습니다. 이 버그는 비트코인 0.3.6에서 OP_RETURN이 항상 실패하도록 만들고 스크립트의 다른 디스플레이에 숫자를 할당함으로써 처음 수정되었습니다. 이러한 모든 변경 사항은 소프트 포크였지만 동일한 코드(나중에 특정 제한 사항이 제거됨)에 대한 변경 사항도 하드 포크 스타일 변경으로 이어졌습니다. 이러한 주요 변경 사항에도 불구하고 scriptSig가 scriptPubKeys의 작업을 조작할 수 있는 근본적인 문제가 여전히 존재하므로 두 번째 소프트 포크가 비트코인 0.3.8에서 구현되어 두 가지가 독립적으로 실행될 수 있습니다.
오버플로 버그 수정(2010년 8월): 누군가 0.5 btc를 사용하는 트랜잭션을 생성하고 92,233,720,368.54277039 BTC에 해당하는 두 개의 출력을 생성했습니다. 비트코인은 출력값이 입력값보다 클 수 없도록 요구하지만 탐지 방법은 최대 9,223,372,036,854,776 사토시(약 9200만 btc)까지 표현할 수 있는 64비트 정수에 출력값을 더하는 방식으로 시작됐다. 이는 트랜잭션의 총 비용이 -0.1 btc에 불과한 것으로 나타남을 의미합니다. 이것은 또한 개별적으로 음수 출력을 금지하지만 총 음수 값은 금지하는 또 다른 규칙을 우회합니다. 양수 값의 합이 여전히 양수라고 가정하기 때문입니다. 이를 통해 누군가는 1,840억 btc를 생성할 수 있으며, 이 트릭은 비용 없이 반복되어 수많은 비트코인을 생성할 수 있습니다. 몇 시간 안에 Bitcoin 0.3.10은 출력을 2100만 btc로 제한하는 소프트 포크 패치를 출시했습니다. 또한 트랜잭션이 넘쳐나는 체인을 포기해야 합니다. 이는 의도적인 합의 실패이지만 비트코인이 여전히 의미를 갖기 위해서는 필요합니다.
BDB 잠금 문제에 대한 임시 수정(2013년 3월): 2012년 초 비트코인 개발자는 UTXO 데이터베이스(체인 상태)에 너무 많은 변경이 동시에 수행되면 체인 상태 데이터의 기본 용량 제한 중 하나가 초과했습니다. 당시 비트코인 블록은 상대적으로 작았기 때문에 블록체인이 재구성되어 여러 블록의 트랜잭션을 동시에 처리해야 하는 경우에만 관찰되었습니다. 그 당시 간단한 솔루션이 구현되었습니다. 재구성하는 동안 한 번에 한 블록의 트랜잭션만 처리합니다. 나중에 일부 사람들은 채굴자에게 선택적 기본 블록 크기를 250KB에서 늘리도록 요청하기 시작했습니다. 2013년 3월 12일, 한 채굴자가 1,700개 이상의 거래가 포함된 ~1MB 블록(지금까지 가장 큰 비트코인 블록)을 생성했으며, 이는 많은 노드에서 데이터베이스의 용량을 초과하여 블록이 블록을 완전히 준수함에도 불구하고 유효하지 않은 것으로 간주하게 했습니다. 비트코인의 명시적 합의 규칙. 물을 더욱 진흙탕으로 만들기 위해 이 제한 없이 다른 데이터베이스 엔진을 사용하는 비트코인 코어의 새 버전이 출시되어 이 더 큰 블록을 안전하게 받을 수 있습니다. 상황을 빠르게 분석한 후 개발자는 사용자에게 일시적으로 이전 버전으로 다운그레이드(이 큰 블록이 있는 버전을 거부함)한 다음 블록 크기 제한을 일시적으로 500KB로 낮추는 긴급 버전으로 업데이트하도록 권장합니다. 소프트 포크 , 모든 사용자가 새 데이터베이스 엔진으로 업그레이드할 시간을 허용하고 이 임시 다운그레이드는 몇 달 후에 자동으로 만료됩니다.
향후 활성화
몇 달 동안 Segwit 활성화 문제가 발생한 후 일부 사람들은 BIP8에 대해 생각하기 시작했습니다. BIP8 지지자들은 BIP9의 일부 문제를 해결할 수 있다고 믿습니다.
강제 활성화 허용: BIP8은 BIP148의 일반화이며, 채굴자는 활성화를 기다리는 기간 동안 자발적으로 지원 신호를 보낼 수 있지만, 채굴자가 지원 신호를 보내야 하는 최후통첩 기간도 설정합니다. 그렇지 않으면 생성된 블록이 무효화될 수 있습니다. 나중에 사람들은 이 작업을 트리거하기 위해 LockinOnTimeout(LOT) 매개변수를 설계했습니다. this 이지만 충분한 블록이 신호를 받으면 새 규칙이 계속 적용됩니다.
시간 대신 고도 사용: BIP9는 채굴자가 블록을 쓰는 평균 시간을 기반으로 활성화 신호 모니터링을 시작하고 중지합니다. 따라서 채굴자들이 이 시간을 조작할 수 있으며, 이는 LOT=true의 기능을 방해할 것이므로 BIP8은 시간 대신 블록 높이를 사용할 것을 제안합니다.
BIP8의 유연성은 BIP8을 탭루트 소프트 포크에 대한 많은 후보 활성화 제안 중 하나로 만들었습니다. 다른 그룹이 사용하는 신호 메커니즘을 "캡처"하여 채굴자가 생성된 블록을 약간만 변경하도록 요구하여 겉보기에 개발자에게 합의 규칙에 대한 권한을 부여하고 합의 실패의 위험을 증가시킵니다. 이 글을 쓰는 시점에서 탭루트 활성화 방법에 대한 논의가 계속 진행 중입니다.
"확률적 소프트 포크 활성화(스포크)", "다단계 소프트 포크 활성화(MSFA)", "임계값 감소 활성화(decthresh)", "하드 코딩된 높이 또는 시간 반환 활성화 (플래그 일)" 및 "활성화 지연 후 더 짧은 신호 기간(빠른 평가판)".
메인 코드와 문서
BIP9
BIP8
웹사이트의 Optech 뉴스 및 관련 섹션
(많은, 약간)
또한보십시오
BIP 활성화 고도, 시간 및 임계값
Taproot
