Job Negotiation은 채굴자와 풀이 맞춤 채굴 작업에 관해 합의하는 과정입니다. Stratum V2는 채굴 장비와 풀 사이의 통신 규칙을 정합니다. 그중 자체 제안을 다루는 부분이 Job Declaration Protocol이며, 템플릿 및 작업 전달과 함께 동작합니다. 채굴자가 거래를 고르되 풀은 계속 작업을 기록하고 보상을 지급하도록 하는 것이 목적입니다. 연결 이름보다 실제 구성이 중요합니다.
안나가 Stratum V2로 바꿨는데도 거래 목록을 계속 풀에서 받습니다. 모순은 아닙니다. 작업과 결과를 전달하는 Mining Protocol은 Job Declaration이나 Template Distribution 없이도 동작할 수 있습니다. 뒤의 구성 요소는 블록 템플릿을 제공하고 Job Declaration은 자체 제안을 처리합니다. 안나가 선택하려면 이런 역할도 구성에 포함되어야 하고 풀도 지원해야 합니다. 더 현대적인 전송 방식만으로는 Bitcoin 블록 내용을 누가 정하는지 알 수 없습니다. [1] [4]
선택한 결제로 블록이 꽉 차서 보상 거래 coinbase가 들어가지 못해서는 안 됩니다. 템플릿 제공자인 Template Provider는 얼마를 남겨야 할지 알아야 합니다. 안나 측에서는 JDC, 즉 Job Declarator Client라는 프로그램이 동작합니다. 이용할 풀들의 요구를 파악하고 CoinbaseOutputConstraints라는 데이터 메시지로 템플릿 제공자에게 전달합니다. 데이터 공간과 블록 한도에 포함해 세는 서명 검증 연산인 sigops를 확보합니다. 그렇지 않으면 자금을 배정하는 coinbase 출력을 추가하면서 블록 한도를 넘을 수 있습니다. 거래를 직접 고르더라도 처음부터 전체 결과의 유효성을 고려해야 합니다. [3]
Full-Template 모드에서 JDC는 DeclareMiningJob을 JDS로 보냅니다. JDS는 풀 측이나 풀이 신뢰하는 서비스의 Job Declarator Server입니다. 메시지에는 선택한 거래의 식별자가 들어갑니다. 서버가 모르는 거래가 있으면 ProvideMissingTransactions로 자료를 요청할 수 있습니다. 안나는 자신의 선택을 확인할 수 있는 정보를 공유하는 셈입니다. 선언을 확인하는 것과 풀이 나중에 맞춤 작업을 수락하는 것은 별도 단계입니다. 첫 성공 메시지로 전체 합의가 끝난 것은 아닙니다. [2]
Coinbase-only 모드에서 JDC는 거래 집합을 밝히지 않으며 DeclareMiningJob도 사용하지 않습니다. 풀은 제출된 coinbase를 보고 수입을 추정합니다. 안나의 선택을 풀에 숨길 수 있지만, 숨겨진 거래의 유효성이나 실제 수수료를 그 자체로 증명하지는 않습니다. 명세도 이 위험을 분명히 설명합니다. 전달하는 정보가 줄면 확인 가능한 범위도 바뀝니다. 모드의 이름만으로 모든 보상 조건이 충분히 입증되었다고 볼 수는 없습니다. 여기서 공개하지 않는 것은 채굴 중인 초안입니다. 안나가 유효한 블록을 찾아 네트워크에 전파하면 그 안의 거래는 공개됩니다. [2]
기술적인 대화에는 비슷해 보이는 식별자가 여럿 나옵니다. JDS가 mining_job_token을 발급하고 클라이언트는 SetCustomMiningJob에서 이를 참조합니다. 풀이 작업을 수락하면 SetCustomMiningJob.Success에 자신의 job_id를 담아 돌려줍니다. 토큰은 제안 협의 과정을 연결하고 job_id는 결과를 제출할 때 작업을 식별합니다. 신청 번호와 승인된 작업 번호의 차이와 비슷합니다. 둘을 혼동하면 풀이 결과를 올바른 수락 작업에 연결할 수 없게 됩니다. [1]
모든 통신 단계를 기다리면 장비가 불필요하게 멈추게 됩니다. 필요한 토큰과 템플릿을 확보한 클라이언트는 SetCustomMiningJob.Success 이전에 낙관적 채굴을 시작할 수 있습니다. 찾아낸 shares, 즉 풀의 목표에 따라 작업을 증명하는 부분 결과는 확인이 올 때까지 보관합니다. 작업이 수락되면 배정된 식별자로 전송할 수 있습니다. 그러므로 기계가 돌아간다고 풀이 그 일을 이미 수락하거나 적립했다고 볼 수는 없습니다. 계산 시작과 보상에 대한 동의는 다른 시점입니다. [1] [2]
안나가 SetCustomMiningJob.Error를 받거나 합리적인 시간 안에 답을 받지 못하면, 명세는 다른 풀이나 단독 채굴로 전환할 것을 권합니다. 따라서 버틸 수 있는 능력은 작동하는 fallback, 즉 준비된 대체 경로에 달려 있습니다. 소프트웨어가 거절한 풀의 원래 템플릿으로 조용히 바꾸면 가동은 계속할 수 있어도 안나의 선택은 잃게 됩니다. 거절 시 시스템이 실제로 무엇을 하는지 알아야 하는 이유입니다. 프로토콜에 기능이 적혀 있다고 모든 서비스가 지원하는 것은 아닙니다. [1] [4]
안나는 거래를 직접 고르면서 공동 보상도 받고 싶습니다. 따라서 JDC는 보상 조건을 충족하도록 coinbase에서 풀이 지정한 출력에 금액을 배정해야 합니다. 수입 일부를 다른 곳으로 보내면 풀은 해당 작업의 보상을 비례해 줄일 수 있습니다. Job Declaration이 자동으로 채굴자에게 직접 지급하게 만들거나 서비스의 회계 조건을 없애지는 않습니다. 주로 달라지는 것은 누가 블록 내용을 제안할 수 있느냐입니다. 블록 유효성 규칙과 수입 배분 방식은 따로 살펴야 합니다. [2]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Stratum V2, Mining Pool Centralization.