Full Pay Per Share

장비는 작업을 증명하는 부분 계산 결과인 shares를 풀에 보냅니다. 보통 완전한 블록을 찾는 더 어려운 조건에는 못 미치지만, 풀은 검증할 수 있습니다. Luxor의 FPPS는 풀이 직접 블록을 발견할 때까지 기다리지 않고 유효하며 수락된 결과를 기준으로 합니다. Braiins는 가중치도 설명합니다. 난이도 d인 결과는 기본 작업 단위 d로 계산합니다. 따라서 보낸 메시지 수만 세면 안 됩니다. 결과마다 계산에 반영되는 가중치가 다르고, 거절된 작업을 수락된 작업에 자동으로 더할 수도 없습니다. [2] [3]

새 블록은 블록 보조금이라 부르는 신규 발행 비트코인과 그 안의 거래 수수료를 가져올 수 있습니다. FPPS는 두 요소에서 에바의 작업이 차지하는 기대 몫을 평가합니다. 매개변수가 일정한 구간의 Braiins 계산식은 R=(S/D)×(C+AF)입니다. S는 난이도로 가중한 수락 작업, D는 네트워크 난이도, C는 보조금, AF는 정해진 방법의 평균 수수료입니다. R은 풀 수수료를 빼기 전 보상입니다. S를 서로 다른 난이도의 단순 메시지 수로 쓰면 양이 다른 작업을 같게 취급하게 됩니다. S/D는 해당 난이도에서 그만큼의 작업으로 평균 몇 개의 블록을 찾을 수 있는지 나타냅니다. 실제 발견한 블록 수나 발견을 보장하는 수치는 아닙니다. [1] [3]

에바의 일일 명세서는 풀이 그날 발견한 블록을 단순히 나눈 결과가 아닙니다. Braiins는 세계 공통 시간 기준인 UTC로 하루를 마감하고, 네트워크 결과를 기대치인 144개 블록으로 정규화합니다. 이는 계산 기준이지 네트워크나 풀이 반드시 달성해야 할 일일 실적이 아닙니다. 블록이 적은 날도 평범한 무작위 변동일 수 있습니다. 따라서 달력상의 하루를 최근 144개 블록과 자동으로 같다고 보면 안 됩니다. 그 구간은 다른 시각에 시작하고 끝날 수 있습니다. [1]

Luxor는 다른 방법을 설명합니다. 체인에서 블록의 위치인 현재 높이 h를 기준으로 최근 144개 블록을 봅니다. 수수료 분포 양 끝의 ≤p5와 ≥p95 값을 제외하고 나머지를 평균내 극단값의 영향을 줄입니다. 해당 높이의 보조금과 난이도도 적용합니다. p5와 p95는 값을 작은 순서대로 나열했을 때의 경곗값입니다. 약 5%가 첫 번째 경곗값보다 작고, 약 95%가 두 번째 경곗값보다 작습니다. 따라서 양 끝의 극단값 대신 가운데 부분을 계산에 사용합니다. 이 필터링은 Bitcoin의 규칙도, 모든 FPPS 풀이 따라야 할 의무도 아닙니다. Luxor는 방법을 바꿀 수 있으므로 에바는 요금표의 같은 약어가 아니라 실제 규칙을 비교해야 합니다. [2]

에바가 네트워크 난이도 조정 전후에 모두 채굴한다고 해 봅시다. 같은 작업의 기대 가치가 달라지므로 Braiins는 해당 시간 구간을 따로 계산합니다. 새로 발행되는 블록 보상이 주기적으로 절반이 되는 Halving도 비슷하게 처리합니다. Halving은 보조금을 바꾸지만 평균 수수료 계산 방식까지 자동으로 바꾸지는 않습니다. 따라서 FPPS는 풀의 운에 대한 의존을 낮추되 매일 받는 비트코인(BTC)의 양을 고정하지 않습니다. 비트코인 가격이나 전기요금 변화도 에바의 경제적 결과를 바꿉니다. [1] [2]

약어는 무엇을 기준으로 지급하는지 나타냅니다. PPS는 Pay Per Share로, 수락된 shares에 대한 지급을 뜻합니다. PPLNS는 Pay Per Last N Shares로, 블록을 찾았을 때 최근 일정 범위의 shares가 나타내는 작업량에 따라 보상을 나눕니다. 그 범위의 크기는 풀이 정합니다. FPPS와 PPS+ 모두 거래 수수료 몫을 제공할 수 있지만 같은 방식으로 계산하지는 않습니다. F2Pool은 모델 수수료를 쓰는 FPPS와 PPS+를 구분합니다. PPS+에서 보조금은 수락된 작업에 지급하는 PPS로 계산하고, 풀이 실제 벌어들인 거래 수수료는 해당 최근 구간의 작업에 따라 PPLNS로 나눕니다. 따라서 수수료 부분은 여전히 풀의 실제 블록 발견에 달립니다. 단순히 수수료도 포함한다는 말만으로는 에바가 어느 부분에서 실제 블록을 기다리는지 알 수 없습니다. [4]

풀이 오랫동안 블록을 찾지 못하면서 계속 보상을 적립한다면 의무를 이행할 자금이 필요합니다. Meni Rosenfeld는 PPS에서 이 문제를 다루며 운영자가 발견 수의 변동을 부담하고 준비금을 확보해야 한다고 설명합니다. 같은 논리로 FPPS의 위험도 이해할 수 있습니다. 다만 역사적 모델은 현재 풀에 대한 감사가 아니며 특정 회사의 자금 규모를 알려 주지 않습니다. 에바가 얻는 것은 서비스에 대한 청구권이지, 운영자가 실패해도 지급되는 프로토콜 보장이 아닙니다. [5]

Braiins와 Luxor 모두 보상 적립과 실제 전송을 구분합니다. 지급에는 예정 시점, 필요한 최소 잔액, 가능한 이체 수수료도 영향을 줍니다. 대시보드의 FPPS 숫자가 에바 지갑으로 도착했다는 증거는 아닙니다. 서비스를 비교할 때 에바는 같은 수락 작업과 기간, 계산 규칙, 실제 수령한 순액을 봅니다. 그다음에야 장비 운영 비용을 빼고 얼마나 남는지 판단할 수 있습니다. [1] [2]