Bitcoin Development Philosophy

제안에 프로그래밍 오류가 없어도 시스템 전체를 약하게 만들 수 있습니다. 검증 일부를 외부 서비스에 맡겨 사용을 편리하게 만드는 경우가 그렇습니다. 책은 그 교환에서 무엇을 얻고 누구를 신뢰하기 시작하는지 짚도록 돕습니다. 저자들은 설명을 과거 논의와 경험 많은 개발자의 견해에 연결합니다. 유명한 이름을 보고 편을 고르기보다 제안의 이유를 평가하는 법을 배웁니다. [2]

채굴에서 입증하는 작업인 Proof of Work, 블록의 구성, 거래가 전파되어 체인에 포함되기까지의 흐름을 알아야 합니다. 이후 9개 주요 장은 탈중앙화, Trustlessness, 프라이버시, 제한된 공급, 업그레이드, Adversarial thinking, 공개 개발, 확장성, 사고 대응을 다룹니다. 첫 비트코인 구매 안내서가 아니라, 기초 위에서 규칙과 관행이 왜 중요한지 묻는 책입니다. [2] [1]

Trustlessness는 앞으로 아무도 믿지 말라는 뜻이 아닙니다. 책에서 인용하는 Pieter Wuille의 설명처럼 신뢰할 중개자 없이 프로토콜이 작동할 수 있다는 의미입니다. Full Node, 즉 완전한 검증을 수행하는 노드는 받은 블록이 허용되지 않은 코인을 만들거나 같은 금액을 두 번 쓰지 않는지 직접 확인합니다. 직접 검증하지 않으면 그 일을 다른 이에게 맡기는 셈입니다. 다만 노드도 결함이 있을 수 있는 구체적인 소프트웨어와 하드웨어 위에서 작동합니다. [3]

결제가 기록된 블록이 나중에 다른 유효한 체인 분기로 바뀐다고 생각해 보세요. 이런 이력 변경을 재구성이라고 하며 결제 상태도 달라질 수 있습니다. 이 장은 David Harding을 인용해 규칙 검증과 이러한 위험에 대한 보호를 구별합니다. 확인 수가 늘면 해당 블록 뒤에 다른 블록이 더해져 보통은 대체가 어려워집니다. 하지만 자기 노드가 모든 이력 변경을 막는다는 약속은 아닙니다. [3]

결제를 확인하기 전에도 질문이 하나 있습니다. 내려받은 프로그램이 공개된 소스 코드와 일치할까요? 재현 가능한 빌드는 서로 다른 사람이 같은 재료에서 같은 결과 파일을 만들도록 합니다. 비교를 통해 배포 프로그램을 확인할 수 있습니다. 하지만 이 장은 Carl Dong의 설명도 소개합니다. 프로그램을 만든 도구의 출처 역시 중요합니다. 파일이 같다고 코드, 컴파일러, 컴퓨터에 결함이 없다는 사실까지 입증되지는 않습니다. [3]

Adversarial thinking은 상대방의 관점에서 제안을 살피는 사고방식입니다. 정직한 참여자 사이에서 작동하는지만 묻지 않고, 공격자가 악용해 무엇을 얻을 수 있는지도 묻습니다. 이 장은 Andrew Poelstra와 Jameson Lopp의 논의를 통해 보안의 전제를 검토합니다. 노드를 정직한 네트워크에서 격리하거나 공개 협업을 의도적으로 방해하는 사례가 나옵니다. 지금까지 작동했다는 사실만으로 전체 시스템의 안전성이 형식적으로 증명되지는 않습니다. [4]

인용된 Eric Voskuil의 저항 공리는 시스템이 국가의 통제에 저항할 수 있다는 가정에서 출발합니다. 여기서 공리는 사고의 출발점이지 Bitcoin의 무적 상태를 입증한 시험 결과가 아닙니다. 일반 독자에게도 중요한 차이입니다. 견고한 해법을 찾는 데 의미가 있다는 것과 우리가 만든 모든 해법이 모든 위협을 견딘다는 것은 다릅니다. 책은 이런 가정을 찾아 사각지대를 줄일 관점을 제시합니다. [4]

각 주장에 대해 무엇을 검증했는지, 무엇이 여전히 가정인지, 변화로 사용자가 어떤 편의를 얻는지 물어보세요. 저자들은 글과 강연을 연결하고, 글의 사본과 출처를 저장소의 별도 자료 모음에 보관합니다. 이 소개는 전체 서문과 Trustlessness, Adversarial thinking 두 장의 전체 텍스트에 근거합니다. 나머지 장은 목차를 바탕으로 설명하며, 책 전체와 모든 외부 링크의 서평이나 수행한 보안 감사는 아닙니다. [2] [3] [4]