Bitcoin Core

파벨은 책을 팔고 비트코인으로 대금을 받습니다. 손님이 휴대전화의 결제 완료 화면을 보여 주지만, 그는 실제로 지급됐는지, 유효한 블록에 들어갔는지 알고 싶습니다. 공개 블록 탐색기에 물어볼 수도 있고, 자신의 노드에 연결한 지갑을 사용할 수도 있습니다. Bitcoin Core는 그런 노드를 실행하는 프로그램입니다. 여기서 노드는 소프트웨어로 Bitcoin 규칙을 독립적으로 검증하는 컴퓨터이고, 블록은 공동 기록에 추가되는 거래 묶음입니다. 데이터는 다른 곳에서 받지만 유효성은 직접 판단합니다. 파벨은 이해를 돕기 위한 사례입니다. 핵심은 남의 안내를 믿기만 하는 대신 스스로 검증하는 데 있습니다. 설치한다고 채굴자가 되거나 BTC를 받거나 다른 사람의 결제를 취소할 수 있는 것은 아닙니다. 소스 코드는 MIT 라이선스로 공개되며, 그 조건에 따라 연구하고 수정하고 배포할 수 있습니다. [1] [16]

Bitcoin Core가 두 역할을 모두 할 수 있어 혼동하기 쉽습니다. 노드는 과거 기록과 새 블록을 검사합니다. 지갑은 관련 자금을 추적하고 주소를 만들고 거래를 준비하며, 개인 키를 관리한다면 그 키로 서명할 수도 있습니다. 개인 키는 해당 비트코인의 지출을 승인하는 디지털 서명을 만드는 데 쓰는 비밀 데이터입니다. 키 자체를 다른 노드에 보내지는 않습니다. 하지만 Core는 지갑 없이도 실행됩니다. 파벨은 다른 호환 앱으로 결제하고 자신의 노드에서 검증된 데이터를 받을 수 있습니다. 연결 방식에 따라 추가 소프트웨어가 필요하기도 합니다. Core를 켰다고 모든 지갑이 자동으로 그 노드를 쓰는 것은 아닙니다. 이름을 구분하면 도움이 됩니다. bitcoin-qt는 그래픽 화면을 제공하고, bitcoind는 백그라운드에서 실행되며, bitcoin-cli는 프로그램에 명령을 보냅니다. [12] [17]

새 노드는 먼저 과거 기록을 따라잡아야 합니다. 이를 Initial Block Download, 줄여서 IBD라고 합니다. 일반적인 동기화에서는 블록을 내려받고 연결 관계, 채굴자의 작업, 거래 규칙을 검사합니다. 그 결과 아직 사용되지 않은 거래 출력인 UTXO의 로컬 기록, chainstate를 만듭니다. 거래 출력에는 금액과 지출 조건, 예를 들어 필요한 서명이 지정됩니다. 다른 거래가 이 출력을 사용하기 전까지 기록에 남아 있습니다. 사람 이름이나 은행 계좌 목록이 아닙니다. 속도는 컴퓨터와 저장 장치, 연결 상태에 따라 다르므로 처음에 느리다고 곧 고장은 아닙니다. 파벨은 현재 결제를 검증하기 전에 동기화가 끝났는지 확인합니다.

정확성을 위해 덧붙이면, assumevalid는 정해진 조건에서 오래된 기록의 스크립트, 즉 지출 조건 검사를 생략할 수 있고 -assumevalid=0은 이 지름길을 끕니다. 별도 기능인 AssumeUTXO는 확인된 상태 스냅샷에서 시작하면서 이전 기록을 백그라운드에서 처리할 수 있게 합니다. 스냅샷은 특정 블록 시점의 UTXO 상태를 저장한 것입니다. 프로그램은 먼저 그 hash, 즉 디지털 지문을 코드에 정해진 값과 비교합니다. 이 비교가 끝나도 과거 전체 기록을 독립적으로 검증한 것은 아닙니다. 전제가 서로 다르므로 모든 설치가 처음부터 똑같은 검사를 마쳤다고 할 수는 없습니다. [9] [10] [12] [17]

동기화가 끝난 뒤에도 Core는 연결된 노드, 즉 peers에서 데이터를 받습니다. 받아들인 미확인 거래는 임시 대기실인 Mempool에 보관합니다. 여기에 있다는 사실은 블록 확인을 받았다는 뜻이 아니며, 노드마다 내용도 다를 수 있습니다. 새 블록이 오면 Core가 검사합니다. 유효한 후보 체인 가운데 누적 작업량이 가장 큰 체인을 선택하지, 컴퓨터의 표 수나 단순한 블록 개수로 고르지 않습니다. 따라서 파벨은 결제를 보았다는 것과 확인됐다는 것을 구분합니다. 자신의 노드도 즉시 포함을 보장하지 않으며, 다른 유효한 분기가 추적 중인 기록 일부를 대체하는 재구성을 없애 주지는 않습니다. [16]

파벨의 노드가 어떤 미확인 거래를 Mempool에 받지 않았다고 합시다. 그렇다고 그 거래가 유효한 블록에 들어갈 수 없다는 뜻은 아닙니다. 합의 규칙은 노드가 인정할 블록과 지출의 유효성을 정합니다. 로컬 relay policy는 과부하로부터 자원을 지키는 등의 이유로 어떤 미확인 거래를 받아 중계할지 조건을 더합니다. 이 정책을 수신한 블록 안의 거래에 똑같이 적용하는 것은 아닙니다. 그때는 합의 규칙에 따른 유효성이 중요합니다. 따라서 Mempool 설정이 다르다는 이유만으로 네트워크가 분리되지는 않습니다. 이 구분을 알아야 Core의 설정 논쟁을 모두 통화 규칙 변경으로 오해하지 않을 수 있습니다. [13]

Core는 블록 데이터, 노드 상태, 필요한 경우 지갑도 저장합니다. Pruning은 처리한 오래된 블록 파일과 그 변경을 되돌리는 데이터를 삭제해 공간을 절약합니다. 노드는 새 블록을 계속 검증하지만 전체 기록을 항상 손에 쥐고 있지는 않게 됩니다. 과거 조회나 이전 결제 재검색에는 다시 다운로드가 필요할 수 있습니다. 인덱스는 조회를 빠르게 하는 보조 기록입니다. 예를 들어 txindex는 pruning과 함께 쓸 수 없으므로 노드 용도에 맞춰 선택해야 합니다. 더 중요한 차이는 공개 블록은 다시 받을 수 있지만 잃어버린 개인 키는 그 안에서 복구할 수 없다는 점입니다. Core 지갑에는 별도의 안전한 백업이 필요합니다. 실행 중에는 backupwallet 같은 백업 기능을 사용하고, 쓰기 중인 데이터베이스를 임의로 복사하지 않는 것이 좋습니다. [11] [12]

파벨은 공식 사이트에서 선택한 릴리스의 안내를 읽습니다. SHA-256 체크섬은 내려받은 파일의 지문으로, 예상한 파일과 다른지 알려 줍니다. 하지만 그 예상 지문을 누가 게시했는지까지 알려 주지는 않습니다. 따라서 디지털 서명과 서명 키의 신원도 확인해야 합니다. 공격자가 프로그램과 자신의 체크섬을 함께 주었다면 둘이 일치한다고 공격이 막히지는 않습니다. 더 깊은 확인을 위해 프로젝트는 재현 가능한 빌드를 사용합니다. 서로 독립적인 사람들이 같은 소스에서 동일한 파일을 만들어 결과를 비교할 수 있습니다. Guix는 빌드 환경을 맞추는 데 도움을 줍니다. 이는 소프트웨어 출처 확인을 강화하지만 코드에 결함이 없다는 증명은 아닙니다. [8] [7]

Core에는 다른 프로그램이 제어할 수 있는 JSON-RPC 인터페이스가 있습니다. 상태 조회와 서비스 연결에 유용하지만, 지갑과 권한에 따라 자금 관련 작업도 가능해집니다. 그러므로 로그인 정보를 도와주겠다는 사람에게 넘겨서는 안 됩니다. 이 인터페이스 자체는 네트워크 통신을 암호화하지 않으며 공개 인터넷에 노출하도록 설계되지 않았습니다. 다른 Bitcoin 노드와의 일반 연결과 이 제어 기능의 공개는 별개입니다. 로컬 접근에는 .cookie 파일의 임시 인증 정보도 사용됩니다. 원격 관리는 문서에 따라 보호된 연결과 제한된 접근으로 구성해야 합니다. 노드를 시험해 보기 위해 관리 인터페이스를 온 세상에 열 필요는 없습니다. [14]

누구나 코드 변경을 제안할 수 있습니다. 다른 기여자들이 읽고 시험하고 토론하며, 저장소를 관리하는 maintainers가 받아들여진 변경을 합칠 수 있습니다. 그렇다고 파벨의 노드를 원격으로 조종할 권한이 생기지는 않습니다. 실행할 소프트웨어는 운영자가 고릅니다. 다만 그 선택도 한 사람이 모두의 규칙을 바꾸는 투표권은 아닙니다. 호환되지 않는 변경은 자신의 노드를 나머지와 분리할 수 있습니다. Bitcoin Core는 중요한 규칙 구현이지, 네트워크 전체를 소유한 회사가 아닙니다. 공지를 읽을 때는 제안, 코드 반영, 릴리스, 실제 사용을 구별해야 합니다. 각 단계 사이에는 긴 과정이 있을 수 있습니다. [15]

개인 키를 저장하지 않고 노드부터 운영할 수 있습니다. 파벨은 파일과 서명을 검증하고 IBD가 끝나기를 기다린 뒤, 선택한 지갑이 정말 자신의 노드 데이터를 쓰는지 확인합니다. 이후 연결 상태, 블록 진행, 빈 공간을 살핍니다. 업데이트 전에는 변경점과 이전 조건을 설명한 release notes를 읽으며, 지갑을 사용한다면 백업과 복구도 확인합니다. 문제를 조사할 때 debug.log가 도움이 되지만 무심코 공개해서는 안 됩니다. Pruning, 인덱스, RPC는 이해하지 못한 안내를 그대로 복사하기보다 실제 용도에 맞춰야 합니다. 개인 노드는 이해할 수 있는 검증 도구여야 합니다. 첫 소액 구매에 필수는 아니지만, 왜 결제를 유효하다고 판단하는지 직접 알고 싶을 때 의미가 있습니다. [12] [14]