합의 규칙

누군가 이전에 받은 같은 자금으로 먼저 당신에게 돈을 보내고 다시 가게에 결제하려 한다고 생각해 보세요. 두 지출이 모두 유효한 기록에 들어갈 수는 없습니다. 노드는 이를 확인하기 위해 금액과 그 금액을 지출할 조건을 기록한 거래 출력을 추적합니다. 노드는 블록을 받으면 누가 추천했는지가 아니라 자신이 적용하는 규칙에 맞는지를 확인합니다. 지출하려는 출력이 사용 가능한지, 필요한 서명을 포함한 Bitcoin Script 조건을 충족하는지, Proof of Work와 채굴자 보상이 허용 범위에 드는지 등을 검증합니다. 규칙을 위반하면 거부합니다. 기업의 지지나 인터넷 투표의 다수 의견도 이 결과를 바꾸지 못합니다. [1]

채굴자는 거래를 고르고 블록을 찾으며, Full Node는 그 결과를 독립적으로 검증합니다. 개발자가 변경안을 제시하고 소프트웨어를 배포할 수는 있지만, 그것만으로 다른 노드의 규칙까지 바뀌지는 않습니다. 어떤 소프트웨어를 실행할지는 운영자가 선택합니다. 그 선택은 자신의 노드가 무엇을 받아들일지를 결정할 뿐, 모두가 무엇을 받아들여야 하는지를 정하지는 않습니다. [2] [1]

노드에는 미확인 거래에 대한 규칙도 있습니다. 어떤 거래를 Mempool, 즉 확인을 기다리는 거래를 임시로 모아 두는 자신의 저장 공간에 보관하고 다른 노드에 전달할지 정하는 규칙입니다. 이를 policy라고 하며, 합의 규칙보다 엄격할 수 있습니다. 따라서 멤풀에서 거부된 거래라고 해서 블록 안에서도 반드시 무효인 것은 아닙니다. 블록을 검증할 때는 거래 중계 정책을 적용하지 않습니다. [3]

Soft Fork는 규칙을 강화합니다. 새로운 규칙에 따라 유효한 블록은 이전 규칙도 충족합니다. 다만 구형 노드는 새 조건을 검증하지 않습니다. 반대로 Hard Fork는 구형 노드가 거부할 블록을 허용할 수 있습니다. 활성화 방식은 변경을 조율하는 데 도움이 되지만, 모두의 동의를 보장하거나 어떤 소프트웨어를 쓸지에 대한 운영자의 결정을 대신하지는 않습니다. [4]

자신의 Full Node를 운영하면 블록 탐색기 웹사이트에 의존하지 않고 받은 블록을 직접 검증할 수 있습니다. 노드가 공통된 기록에서 서로 다르게 이어지는 여러 분기를 알게 될 수도 있습니다. 유효한 분기 중에서는 chainwork, 즉 각 블록의 채굴 난이도에 따라 부여한 작업량의 합을 기준으로 선택합니다. 실제 소비한 전력을 측정하거나 단순히 블록 수를 세는 값이 아닙니다. 작업량이 더 많아도 규칙 위반을 정당화할 수는 없습니다. 노드들이 같은 결과에 도달하려면 드문 상황에서도 규칙을 동일하게 적용해야 합니다. 프로그램 오류가 있으면 받아들이는 블록이 서로 달라질 수 있습니다. [4] [5]

노드는 수수료가 너무 낮은 거래의 중계를 거부할 수 있습니다. 하지만 채굴자가 이를 블록에 넣고 거래와 블록 모두 합의 규칙을 충족한다면 노드는 그 블록을 받아들입니다. 반면 채굴자가 발행이 허용된 새 비트코인인 Block Subsidy와 블록 안의 거래 수수료를 합한 금액보다 많은 보상을 가져가려 하면, Proof of Work가 유효해도 노드는 블록을 거부합니다. 차이는 거부 사유에 있으며 채굴자의 평판에 있지 않습니다. [3] [1]