메시지 교환 규칙을 묶은 공개 프로토콜 모음입니다. 기본인 Mining Protocol은 작업과 결과를 전달하며, 선택 사항인 Template Distribution과 Job Declaration은 자체 블록 초안을 사용할 수 있게 합니다. V2로 연결했다는 사실만으로 이 기능이 보장되지는 않습니다.
에바는 비트코인 채굴 전용 장치인 ASIC을 가지고 있습니다. 여러 채굴자의 작업을 조율하고 보상을 나누는 풀에 연결했습니다. 채굴기는 여러 거래를 묶은 새 블록을 Bitcoin 기록에 추가할 수 있는 계산 결과를 찾습니다. 기계가 올바른 작업을 받고, 결과가 자신이 선택한 풀에 실제로 도착해야 합니다. 나중에는 블록에 넣으려고 시도할 거래도 직접 정하고 싶습니다. Stratum V2는 이 참여자들 사이의 통신을 담당합니다. Mining Protocol이 기본이며, Template Distribution과 Job Declaration은 블록 자료를 전달하고 자체 작업을 협의하는 선택적 부분입니다. 따라서 V2를 내세우는 두 풀도 제공하는 기능은 다를 수 있습니다. [1] [3]
Stratum V1은 채굴자들의 협력을 쉽게 했지만, 일반적인 비암호화 연결에서는 이동 중인 메시지를 읽을 수 있었습니다. 거래도 대개 풀이 골랐습니다. 2019년 Braiins의 Jan Čapek과 Pavel Moravec은 Matt Corallo 및 다른 개발자들과 Stratum V2를 선보였습니다. 목표는 보호되고 효율적인 통신, 그리고 채굴자의 자율성 확대였습니다. 명세는 공개되어 있고 개발도 공개 프로젝트로 계속됩니다. 비트코인 블록의 유효성 규칙을 새로 만들거나 더 높은 수입을 자동으로 약속하는 것은 아닙니다. [8] [6]
에바와 풀 사이의 인터넷 경로에 있는 제삼자가 채굴 메시지를 몰래 읽거나 바꿀 수 없어야 합니다. V2는 그래서 AEAD라고 부르는 메시지 무결성 검증을 갖춘 암호화를 사용합니다. 명세에 따르면 초기 Noise 암호학적 연결 절차는 원격 연결에 필수이며, 로컬 네트워크에서는 사용 여부를 선택할 수 있습니다. 클라이언트는 신뢰할 수 있는 경로로 얻은 풀 인증 주체의 공개키로 서버를 확인합니다. 이 공개키로 서버가 자신의 신원을 증명할 때 사용하는 디지털 서명을 검증합니다. 보호 대상은 전송 과정입니다. 풀은 전달받은 정보를 여전히 볼 수 있으며, 암호화가 펌웨어의 안전성, 회계의 정확성이나 보상 지급 능력을 증명하지는 않습니다. [2] [10]
에바가 항상 채굴 장비를 교체해야 하는 것은 아닙니다. Translation Proxy는 구형 기계의 Stratum V1을 받아 풀 쪽에서는 V2를 사용하는 중간 프로그램입니다. 뒤쪽 구간을 보호해도 ASIC과 프록시 사이의 기존 통신은 바뀌지 않습니다. 그 구간은 여전히 V1이며 별도의 보호가 필요합니다. 프록시는 여러 장치를 함께 처리해 같은 정보를 반복해서 보내는 양도 줄일 수 있습니다. 프로토콜 변환만으로 에바가 거래를 고르는 것은 아닙니다. 추가 기능과 풀의 협력이 필요합니다. [7] [8]
거래를 고르려면 에바는 먼저 어떤 거래가 유효하고 어느 블록 뒤에 다음 블록을 붙여야 하는지 알아야 합니다. 비트코인 규칙을 스스로 검증하는 자신의 풀 노드에서 이 자료를 얻을 수 있습니다. Template Provider는 블록 템플릿을 제공하는 소프트웨어입니다. 템플릿은 미래 블록의 초안이지 완성된 블록이 아닙니다. 필요한 지원을 갖춘 Bitcoin Core나 다른 노드를 사용할 수 있습니다. Template Distribution은 getblocktemplate을 반복 조회하는 대신 갱신 내용을 직접 보냅니다. NewTemplate과 SetNewPrevHash가 초안과 이전 블록과의 연결을 알리고, RequestTransactionData가 거래 데이터를 요청하며, SubmitSolution이 찾은 해답을 돌려보냅니다. [5]
에바는 Job Declarator Client를 사용합니다. 자신의 초안을 받아 Job Declaration을 지원하는 풀과 사용 방법을 협의하는 프로그램입니다. Full-Template 모드에서는 AllocateMiningJobToken으로 작업 식별자를 받고, DeclareMiningJob에 거래 목록을 담으며, 필요하면 ProvideMissingTransactions에 응답합니다. 그런 다음 채굴 서버에 SetCustomMiningJob을 보냅니다. Coinbase-only 모드는 거래 목록을 미리 공개하지 않고 DeclareMiningJob도 사용하지 않습니다. 할당된 식별자와 블록 보상을 담는 특별한 거래인 coinbase의 정보를 이용합니다. 풀은 제안을 거절할 수 있으므로 대체 연결도 중요합니다. 직접 거래를 고르면 결정권을 더 많은 채굴자에게 나눌 수 있지만, 풀의 보상 지급 의무가 없어지지는 않습니다. [4]
앞의 예시는 메시지 이름을 몰라도 이해할 수 있습니다. 하지만 설정하거나 개발할 때는 정확한 형식이 중요합니다. V2는 합의된 기계용 표현인 이진 형식으로 데이터를 보냅니다. 메시지 헤더는 6바이트이며 extension_type, msg_type, msg_length가 확장, 메시지 종류, 내용 길이를 나타냅니다. 암호학적 통신을 수립한 뒤 첫 프로토콜 메시지인 SetupConnection으로 프로토콜과 버전, 필요한 기능을 협의합니다. SetupConnection.Success가 성공을 확인합니다. 서비스의 V2 표시는 실제 프로그램들 사이의 이 협의를 대신하지 못합니다. [1]
채널은 하나의 연결 안에 있는 별도 채굴 세션입니다. 다른 블록체인이나 결제 채널이 아닙니다. Standard Channel은 블록 데이터를 간략히 요약한 헤더에 대한 작업을 배정합니다. Extended Channel은 중간 프로그램이 coinbase 거래의 가변 부분인 extranonce를 이용해 더 넓은 시도 범위를 나누도록 합니다. Group Channel은 여러 채널에 작업을 함께 전달하는 데 도움을 줍니다. OpenStandardMiningChannel과 OpenExtendedMiningChannel이 해당 세션을 엽니다. 실제 이유는 간단합니다. 두 기계가 완전히 같은 후보를 시험하면 같은 일에 전기를 쓰게 됩니다. [3]
풀은 에바의 기여를 계속 측정해야 합니다. Mining share는 배정받은 난이도 기준을 충족한 결과입니다. 대부분의 shares는 블록에 필요한 더 엄격한 네트워크 기준에 미치지 못하지만, 일부는 그 기준도 충족할 수 있습니다. NewMiningJob이나 NewExtendedMiningJob이 작업을 전달하고, SetNewPrevHash가 이전 블록과의 연결을 활성화하며, SetTarget이 채널의 기준을 정합니다. SubmitSharesStandard 또는 SubmitSharesExtended는 작업 식별자, 순서 번호, 바뀐 헤더 데이터를 담아 결과를 보냅니다. 결과가 승인되어도 아직 지갑에 지급된 것은 아닙니다. 풀의 보상 계산과 비트코인 규칙에 따른 블록 유효성은 별개입니다. [3]
먼저 장치와 소프트웨어, 선택한 풀의 지원 여부를 확인합니다. 이어 어느 연결 구간이 보호되는지, 검증 키를 어디서 얻었는지, 더 안전한 전송만 원하는지 직접 거래도 고르고 싶은지 판단합니다. 후자라면 작동하는 Template Provider와 Job Declarator Client, 이에 맞는 풀 지원이 필요합니다. 지연, 거절되거나 오래된 shares, 오류 기록과 장애 시 동작을 살펴봅니다. 안내 문서는 사용하는 버전과 맞아야 합니다. Stratum V2는 채굴 조율을 개선할 수 있지만, 안전한 장치 관리를 대신하거나 풀 노드가 비트코인을 검증하는 규칙을 바꾸지는 않습니다. [6] [7]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin, 채굴, Mining Pool, Braiins, Braiins Pool, ASIC Miner. 다음 항목에서도 이 글을 참조합니다 ASIC Miner, Mining Pool, Nonce, Marek ‘Slush’ Palatinus.