# NODE 사양별 기여도와 보상

일반 NODE도 AI NODE도, 제공한 사양과 검증된 기여에 맞는 보상.

상태: 검토 중
수정일: 2026-11-02

## 숫자를 읽는 기준 · 새 단가 제안 v0.1

2026-10-26 PLAIS Chain 백서 v0.8은 NODE·저장·검증자 재원 20%·100억 PLAIS·120개월을 정의하지만 GPU 모델별 일당이나 CPU·RAM 단가는 정하지 않았습니다. 아래 NP는 이번에 제안한 기획용 산정점수입니다. 기존 plais Point(P)·PLAIS 코인·원화가 아니며 전환율은 정하지 않습니다. 새로운 권리나 지급 약속을 만들지 않고 승인 전 숫자 설계안으로 표시합니다. 단가는 명확히 정했지만 실제 지급액은 자격·품질·상한·예산·정산 승인의 영향을 받습니다.


## 기존 소스의 정확한 숫자 · 새 NP와 합산하지 않음

AISFOR pointPolicy·pointSettlementWorker와 체인 tokenomicsConfig를 2026-11-02에 확인했습니다. 기존 포인트 산식과 새 사양별 NP 제안은 서로 다른 모델입니다. 특히 onlineHourlyPoint라는 이름이나 화면 설명만 보고 시간당 누적 지급으로 계산하면 안 됩니다. 운영 원장을 읽거나 실제 정산을 실행한 것은 아닙니다.

| 기존 항목 | 소스 수치 | 적용 범위 |
| --- | --- | --- |
| 실제 저장 | usedStorageBytes ÷ 1024³ × 0.5P | 1GiB 유지에 대한 일별 정산 산식 · 제공 허용 용량과 다름 |
| 온라인 | 정산 시점 online이면 1P 기록 | 정책 이름은 시간당이나 worker는 시간 누적을 곱하지 않음 · 24P/일로 단정하지 않음 |
| 청크 저장 | 100개당 5P | 성공 수량 비례 · 정산 게이트·한도 적용 |
| 청크 검증 | 100개당 3P | SHA-256 검증 성공 수량 비례 |
| 복구 기여 | 기여 이벤트당 20P | 성공 복구 및 담당 NODE·이벤트 조건 확인 필요 |
| 상한 | AISFOR 전체 33,333P/일 · 1,000,000P/월 | 개인별 지급 약속이 아닌 기존 전체 정책값 |
| 체인측 상한 기본값 | 사용자 1,000P/일 · 카테고리 100,000P/일 | tokenomicsConfig 기본값 · 운영 환경변수·잔여 예산은 별도 확인 |

## 제안 단가표 · 누구나 같은 숫자로 계산

저장·메모리 단위는 GiB(1,073,741,824바이트), 전송도 GiB로 통일합니다. 제품명 속 16GB·24GB·32GB GPU는 설명 편의상 각각 해당 VRAM 등급 예시로 표시하며, 실제 정산은 장치가 보고하고 검증된 바이트로 계산해야 합니다. CPU·GPU 기본 제공 보상과 수행 보상은 별도 예산의 다른 기여 항목입니다.

| 자원·기여 | 계산 단위 | 제안 점수 | 인정 조건 |
| --- | --- | --- | --- |
| 정상 참여 | 1시간 | 1 NP | 독립 NODE 신원·정상 응답·승인된 제공 시간 |
| 저장 용량 제공 | 100GiB × 24시간 | 1 NP | 실측·승인된 허용 용량 · 시간 비례 |
| 실제 저장 | 100GiB × 24시간 | 4 NP | 유효 암호화 데이터 · 실제 유지 시간 비례 |
| CPU 제공 | 허용 1코어 × 1시간 | 0.25 NP | 코어·시간 예약과 실측 수용 검사 |
| RAM 제공 | 허용 1GiB × 1시간 | 0.01 NP | 중복 예약 없이 제공한 메모리 |
| GPU 기본 기여 | 개별 VRAM 4GiB × 1시간 | 1 NP | 8GiB 이상 장치 · 용량 기반 정책 단가 |
| CPU 수행 | 기준 성능 1의 코어·시간 | 1 NP | 실제 작업 코어·시간 × 실측 성능지수 |
| GPU 수행 | 기준 성능 1의 장치·시간 | 8 NP | 실제 작업 장치·시간 × 실측 성능지수 |
| 유효 전송 | 100GiB | 4 NP | 중복·자전 전송 제외 |
| 파일 복구 성공 | 독립 파일 1건 | 5 NP | 최대 하루 4건 · 동일 파일·장애 중복 제외 |

## 일반 NODE 사양별 일·30일 예시

하루 24시간, 품질 100%, 예산 반영률 100%, 추가 CPU 작업·전송·복구 없음, 같은 사용자의 다른 NODE 없음으로 가정합니다. 허용 저장량의 50%가 실제 데이터로 유지되는 예시입니다. 표의 CPU·RAM은 전체 보유량이 아닌 제공 허용량입니다.

| 사양 예시 | 허용 CPU / RAM | 허용 / 실제 저장 | 하루 제안 점수 | 같은 조건 30일 |
| --- | --- | --- | --- | --- |
| S1 · 소형 저장 | 2코어 / RAM 4GiB | 100 / 50GiB | 39.96 NP | 1,198.80 NP |
| S2 · 일반 저장 | 4코어 / RAM 8GiB | 500 / 250GiB | 64.92 NP | 1,947.60 NP |
| S3 · 확장 저장 | 8코어 / RAM 16GiB | 1000 / 500GiB | 105.84 NP | 3,175.20 NP |
| S4 · 대용량 저장 | 8코어 / RAM 32GiB | 2000 / 1000GiB | 139.68 NP | 4,190.40 NP |

## AI NODE · GPU 모델별 숫자 비교

모두 허용 CPU 4코어·RAM 16GiB·GPU 1개·하루 24시간 제공, 저장 제공 없음, 품질·예산 100%를 가정합니다. 작업 추가 열은 GPU 장치×시간 8시간에 실측 성능지수 1.0을 임의로 넣은 계산 예시입니다. 실제 GPU별 벤치마크가 아니므로 같은 VRAM의 GPU는 기본 점수가 같고 실제 수행 점수는 측정 후 달라집니다.

| GPU 모델 | 개별 VRAM 등급 | GPU 기본 점수/일 | 기본 합계/일 | 8시간 작업 추가/일 | 작업 포함 30일 |
| --- | --- | --- | --- | --- | --- |
| RTX 4060 Ti 16GB | 16GiB | 96.00 NP | 147.84 NP | 211.84 NP | 6,355.20 NP |
| RTX 5060 Ti 16GB | 16GiB | 96.00 NP | 147.84 NP | 211.84 NP | 6,355.20 NP |
| RTX 3090 24GB | 24GiB | 144.00 NP | 195.84 NP | 259.84 NP | 7,795.20 NP |
| RTX 4090 24GB | 24GiB | 144.00 NP | 195.84 NP | 259.84 NP | 7,795.20 NP |
| RTX 5090 32GB | 32GiB | 192.00 NP | 243.84 NP | 307.84 NP | 9,235.20 NP |

## 16GB AI NODE · 211.84 NP가 나오는 계산

RTX 4060 Ti·5060 Ti의 속도를 측정했다는 뜻이 아닙니다. 16GiB GPU 1개를 24시간 제공하고 GPU 작업 8장치·시간, 실측 지수 1.0을 가정하면 아래처럼 계산됩니다. CPU 작업·전송·복구·저장 기여는 0입니다.

| 기여 항목 | 산정점수 |
| --- | --- |
| 정상 참여 시간 | 24.00 NP |
| 허용 CPU 코어 | 24.00 NP |
| 허용 RAM | 3.84 NP |
| GPU 기본 기여 | 96.00 NP |
| GPU 작업 수행 | 64.00 NP |
| 합계 · 하루 | 211.84 NP |
| 동일 조건 30일 | 6,355.20 NP |

## 최종 점수 · 품질·상한·예산을 적용하는 순서

① 단가 × 인정 수량으로 항목별 점수를 소수점 둘째 자리까지 반올림해 합산합니다. ② 품질계수 q(0~1)를 곱해 반올림합니다. q는 challenge 통과율과 결과 검증 통과율 중 작은 값이며 작업이 없으면 결과 검증률은 1로 둡니다. ③ NODE별 하루 1,000 NP 상한을 적용합니다. ④ 같은 사용자의 전체 NODE도 하루 1,000 NP 상한을 공유하며 동일 기간의 검증 이벤트 시각·이벤트 ID 순서로 남은 한도를 적용하는 안입니다. 계산기에는 다른 NODE에 이미 인정한 점수를 입력합니다. ⑤ 전체 예산 반영률 f=min(1, 해당 기간 승인 예산/상한 적용 후 전체 대상 점수 합계)를 곱합니다. 전체 점수가 0이면 지급 합계는 0입니다. 이중 한도에서 남은 예산은 보류합니다. 이는 운영 코드가 아닌 기획안입니다.


## 품질과 예산에 따라 달라지는 숫자



| 동일 16GB AI 예시 | 하루 | 같은 조건 30일 |
| --- | --- | --- |
| 품질 100% · 예산 100% | 211.84 NP | 6,355.20 NP |
| 품질 95% · 예산 100% | 201.25 NP | 6,037.50 NP |
| 품질 100% · 예산 50% | 105.92 NP | 3,177.60 NP |
| 같은 사용자 다른 NODE에 이미 900 NP 인정 | 100.00 NP | 3,000.00 NP · 매일 같은 한도 가정 |

## 숫자의 확정 범위와 백서 연결

고정한 것은 기획안 v0.1의 계산 단가와 계산 순서입니다. 실제 보상 정책 활성화·NP의 기존 포인트 편입·코인 전환율·지급 예산은 확정하지 않았습니다. 백서의 100억 PLAIS를 120개월로 단순 나누어 개인에게 일당을 약속하지 않습니다. 기존 unlock·vesting과 재원 범주를 지키면서 별도 승인 예산을 정해야 합니다. 승인된 계측 입력과 같은 정책 버전으로 재계산하면 사양별 숫자와 상한 적용을 검증 할 수 있다.


## 백서와 Sync-Client도 함께 맞춰야 합니다

Codex 의견: AI NODE 추가는 화면의 보상표뿐 아니라 백서·서버 프로토콜·클라이언트의 정책 버전을 함께 맞추는 변경입니다. 백서에는 통합 NODE 역할, 제공 허용량과 실측, CPU/GPU 작업 증거, 보상 단가·상한·예산·이의제기, 기존 Point 및 canonical PLAIS와의 관계를 정리해야 합니다. 정식 보상은 기존 plais Point 체계의 확장을 우선 검토하고, NP는 그 결정을 위한 산정용 초안으로만 사용합니다. 이번에는 백서 원본·운영 Sync-Client·실제 보상 코드를 변경하지 않았습니다.


## Sync-Client의 현재 기반과 추가할 기능



| 구분 | 확인한 기반 또는 추가 방향 | 상태 |
| --- | --- | --- |
| 기존 인벤토리 | 1.4.176-r5 배포 묶음 sync.js에 CPU 논리 수·전체/여유 RAM·디스크 용량·가동 시간 보고 코드 | 소스 확인 · 모든 설치 PC의 가동 검증은 별도 |
| 새 자원 동의 | 제공 CPU 비율·RAM·GPU·VRAM·가동 시간·전력/대역폭 상한·즉시 중단 | 추가 설계 필요 |
| GPU 측정 | GPU 모델·개수·개별 VRAM·드라이버·엔진·동일 업무 성능 | 추가 설계 필요 |
| 계측 모드 | 원격 작업 없이 먼저 자원 등록과 사양·가용성 검증 | 1차 권고 |
| 수행 모드 | 승인된 단일 NODE 작업·격리·lease·취소·결과 검증 | 서버 규격 이후 단계적 개발 |
| 정산 연결 | 서명된 작업·자원·시간·정책 버전 증거와 기존 포인트 원장 연결 | 실제 지급 전 별도 검증 |

## 권고 순서 · 정책과 프로그램을 같은 버전으로

① 백서의 AI NODE·보상 정책 개정안 작성 → ② 자원/작업/보상 이벤트 규격 확정 → ③ 서버가 계측 보고만 받는 경로 → ④ 기존 Sync-Client에 선택형 계측 기능 추가 → ⑤ 승인된 소수 PC에서 사양·중단·중복·복구 시험 → ⑥ 독립 AI 작업 실행과 포인트 정산 연결 → ⑦ 검증된 설치본으로 단계적 배포를 권고합니다. 정책 버전과 실제 보고·작업 증거를 대조하면 사양별 보상을 검증 할 수 있다.


## Sync-Client 구성안 · 한 프로그램, 세 가지 참여 역할

사용자 요구 방향을 반영해 일반 NODE·AI NODE·복합 NODE를 별도 네트워크나 별도 신원으로 나누지 않고 하나의 Sync-Client와 NODE ID 안에서 구성하는 안입니다. 설치 시 사양 감지 → 사용자 역할 선택 → 제공량·가동 시간 동의 → 서버 실측 검증 → 지원 작업 등록 순서로 진행합니다. GPU가 있어도 일반 NODE만 선택할 수 있고, GPU가 없어도 저장·검증·허용 CPU 작업으로 참여할 수 있습니다. 이번에는 개편 기획만 추가했으며 설치 프로그램은 변경하지 않았습니다.


## 역할별 설치·작업·보상 설정



| 설치 시 선택 | 자원과 구성 | 배정할 수 있는 작업 | 보상 평가 |
| --- | --- | --- | --- |
| 일반 NODE | 저장 폴더·제공 용량·CPU/RAM·전송 상한·가동 시간 | 저장·복제·전송·무결성 검증·허용 CPU 업무 | 선택하고 검증된 저장·CPU·가용성·수행 기여 |
| AI NODE | GPU별 모델·VRAM·드라이버·지원 추론 엔진·허용 모델·자원 한도 | 지원 모델의 단일 NODE AI 작업 | 제공을 허용하고 검증한 GPU·CPU/RAM·AI 수행 기여 |
| 복합 NODE | 위 두 구성을 함께 사용 · 공유 자원 예약 충돌 관리 | 저장과 AI를 한 NODE에서 자원 한도 내 수행 | 자원별 기여 합산 · 동일 장치·같은 작업 중복 제외 |

## 네트워크에 제공한 사양을 보상에 반영합니다

사용자 요구: 일반 NODE와 AI 연산 NODE가 PLAIS 네트워크에 참여하면 제공한 사양에 따라 보상받는 구조를 설계합니다. 같은 네트워크에서 저장·CPU·GPU·RAM·대역폭을 자원별로 평가하며, 한 NODE가 여러 역할을 함께 제공할 수 있습니다. 보유 장비의 정가나 모델명만으로 보상을 확정하지 않고 제공 허용량·실측 능력·가용 시간·작업 검증을 함께 반영합니다.


## PLAIS CHAIN에서 확인한 현재 기반



| 영역 | 코드에서 확인한 내용 | 이번 확인 범위 |
| --- | --- | --- |
| PoSS 정책 | Proof of Service & Storage · storage / uptime / verification 등 점수·상한·출처 정책 | config/tokenomicsConfig.js · services/rewardPolicyService.js 소스 확인 |
| 보상 기록 | Reward Ledger · 출처 검증 · 중복 이벤트 방지 · 일별 상한 · 검토 기록 | services/rewardLedgerService.js · routes/reward.js 소스 확인 |
| NODE 경제 이력 | NODE 보상·차감 이벤트와 참조 이력 구조 | services/nodeParticipantService.js · models/NodeEconomyLedger.js 소스 확인 |
| AISFOR 연결 | 저장·온라인·청크 검증·복구 포인트와 체인측 미러 제출 코드 | AISFOR pointPolicy / pointSettlementWorker / aisforChainClient 소스 확인 |
| 사양별 AI 보상 | GPU·VRAM·CPU 실측을 결합한 보상 산식은 이번 조사에서 확인되지 않음 | 통합 자원 계측·AI 기여 카테고리·정산 연결 추가 설계 필요 |

## 일반 NODE / AI NODE / 복합 NODE 비교



| 구성 | 제공 사양 | 기본 기여 보상 기준 · 제안 | 수행 보상 기준 · 제안 |
| --- | --- | --- | --- |
| 일반 저장 NODE | 허용 저장량·디스크 I/O·대역폭·CPU·RAM | 검증된 제공 용량 × 가용 시간 × 가용성 품질 | 유효 저장·전송·검증·실제 복구 기여 |
| CPU 연산 NODE | 허용 코어·실측 CPU 성능·허용 RAM·가동 시간 | 동일 시험 업무의 기준 대비 능력 × 허용 비율 × 가용 시간 | 검증을 통과한 CPU 작업의 정규화된 수행량 |
| AI 연산 NODE | GPU 모델·장치 수·개별 VRAM·실측 추론 능력 | 지원 작업군별 GPU 실측 점수 × 제공 비율 × 가용 시간 | 검증된 AI 작업량·완료 품질·작업별 정책 |
| 저장 + AI 복합 NODE | 위 자원을 하나의 NODE ID로 등록 | 서로 다른 자원만 합산 · 동일 GPU·디스크 중복 계상 금지 | 저장·CPU·AI의 독립 작업 ID별 유효 기여 합산 |

## 보유량이 아니라 제공 허용량을 기준으로

예: RAM 64GB 중 16GB, 저장 4TB 중 1TB, GPU 사용 시간 중 하루 8시간만 제공한다면 그 범위만 보상 평가에 넣습니다. 같은 장치를 여러 NODE로 등록하거나 같은 시간의 자원을 여러 작업에 중복 약속해 점수를 늘리지 못하도록 설계합니다. 등록 사양과 실측 결과, 자원 예약 기록을 대조하면 실제 제공 범위를 검증 할 수 있다.


## 자원별 사양 평가 방법



| 자원 | 보상용 정규화 기준 · 제안 | 추가 확인 |
| --- | --- | --- |
| 저장 | 검증된 제공 GB·시간 / 실제 저장 GB·시간 | 허위 디스크 용량·유지 기간·복구 가능성 |
| CPU | 동일 기준 업무의 실측 처리 능력 × 허용 사용 비율 | 코어 수·클럭만으로 서로 다른 CPU를 동등 비교하지 않음 |
| GPU | 모델·엔진·양자화·컨텍스트가 같은 작업군별 실측 성능 | 모델명·가격·VRAM 크기만으로 속도나 보상 배수 단정 금지 |
| VRAM / RAM | v0.1에서는 허용 메모리×시간을 기본 기여로, 실측 성능을 작업 수행으로 분리 | 같은 물리 장치·같은 작업 중복 금지 · GPU 기본 등급은 실측 속도를 의미하지 않음 |
| 대역폭 | 실측 허용 전송 능력·유효 전송량·응답 품질 | 자전 전송·중복 바이트·다른 자원의 전송 보상 중복 제외 |
| 가동 시간 | 정상 challenge와 요청 수용이 확인된 제공 시간 | 단순 heartbeat·작업을 거부하는 온라인 상태만으로 확정하지 않음 |

## 보상은 두 부분으로 나누는 안을 권고합니다



### ① 사양·가용성 기여

네트워크가 승인한 자원을 실제로 제공 가능한 상태로 유지한 기여입니다. 필요한 자원 수요와 승인된 예산 안에서만 기본 보상 대상으로 인정합니다.

### ② 검증된 작업 수행

저장·전송·복구·CPU·AI 업무를 수행하고 검증을 통과한 기여입니다. 긴 실행 시간 자체보다 정규화된 유효 작업량으로 평가합니다.

### ③ 품질·한도·검토

가용성·성공률·검증 결과를 반영하고 사용자별·NODE별·작업군별 상한을 적용합니다. 의심 기여는 보류하고 이의제기와 재검증 절차를 둡니다.

## 상대 배분 모델과 수치 단가안의 관계

이전 설계는 자원군 점수를 예산 내에서 상대 배분하는 방식이었습니다. 위 v0.1은 누구나 계산하도록 자원 단가를 먼저 고정하고 품질·NODE/사용자 상한을 적용한 뒤 전체 승인 예산 비율로 조정하는 구체화안입니다. 서로 다른 두 공식을 동시에 적용하지 않습니다. 향후 비교 시험 후 하나의 정책 버전으로 채택해야 합니다.


## 사양이 달라질 때의 비교 예시



| 비교 상황 | 반영 방법 · 예시 | 주의점 |
| --- | --- | --- |
| 저장 500GB와 1,000GB를 같은 시간 제공 | 동일 품질·수요·상한이면 가용성 점수는 제공 용량 비율을 반영 | 최종 보상 2배 보장 아님 · 예산과 다른 참여자의 기여에 따라 달라짐 |
| 16GB와 24GB GPU | 지원 가능한 작업군과 같은 조건에서 측정한 성능을 반영 | VRAM 비율 1.5배를 그대로 보상 배수로 사용하지 않음 |
| 하루 8시간과 24시간 제공 | 검증된 제공 시간과 승인된 가용성 예산을 반영 | 자원 수요·거부율·성공률·점검 시간을 함께 고려 |
| 일반 NODE가 저장·CPU 함께 제공 | 검증된 각 자원군의 기여를 별도 계산해 합산 | 같은 작업·같은 자원 사용을 중복 계산하지 않음 |

## PLAIS CHAIN의 보상 재원과 연결

확인한 tokenDistributionConfig의 후보 정책 v0.3에는 NODE·저장·검증자 보상 범주가 전체 20%, 100억 PLAIS로 정의되어 있고 장기 배분 기간은 120개월입니다. token-distribution-self-test.js의 배분 합계·상한·스케줄 검사도 통과했습니다. 이는 후보 재원 배분 정책이며 현재 개인에게 지급 가능한 잔액·수익·지급 확약을 뜻하지 않습니다. AI 보상을 이 범주에 포함하려면 기존 저장·검증자 몫과의 세부 예산 분리, 정책 버전과 집행 조건을 먼저 정해야 합니다. 이 포털은 총 공급량·기존 배분·락업을 변경하지 않습니다.


## 포인트 원장과 PLAIS 코인 정산은 구분합니다

기존 애플리케이션의 포인트·보상 기록과 Besu QBFT의 canonical PLAIS 자산은 다른 계층입니다. canonicalPointConversionService에는 별도의 전환 요청·서명·worker·수신 지갑·custody 준비 조건을 검사하는 코드도 있습니다. 오래된 문서의 잠금 설명만으로 현재 모든 전환을 비활성이라고 단정하지 않으며, 이번에는 실시간 전환 가능 상태·지갑 잔액·코인 지급을 시험하지 않았습니다. 새 CPU/GPU 기여 점수가 기존 포인트나 코인으로 자동 전환된다고 표시하지 않습니다.


## 참여에서 정산까지의 목표 흐름

NODE 등록 → 소유권·장치 중복 확인 → 제공 허용 사양 등록 → 자원 실측 → 승인된 가용성·작업 이벤트 계측 → challenge·결과 검증 → 정책 버전별 점수 산정 → 중복 방지 키로 원장 기록 → 상한·보류·이의제기 확인 → 정산 승인 → 허용된 수단으로 지급 → 영수증 대조. nodeId·deviceId·resourceId·기간·taskId·attemptId·policyVersion과 증거 해시를 연결하면 같은 기여의 중복 보상 여부를 검증 할 수 있다. 입력 원문이나 민감한 파일을 온체인에 올리는 구조는 기본값으로 두지 않습니다.


## 악용 방지와 기존 운영 조건의 정리

자원 실측 challenge, 제공 시간 확인, 작업 결과 재검증, 같은 물리 자원의 중복 등록 차단과 출처 서명이 필요합니다. NODE를 잘게 나누어 상한을 우회하지 못하도록 사용자·동일 장치군 한도도 함께 둡니다. 기존 AISFOR 정산 worker에는 담보 자격을 확인하는 경로가 있으므로 그 적용 범위와 공개 참여 정책도 별도 점검해야 합니다. 이 포털에서 담보 입금이나 자산 거래를 요구하지 않으며, 담보 납부만으로 보상이 보장된다고 설명하지 않습니다. 저장·AI 참여와 실제 검증자 운영 자격도 구분합니다.


## 추가 개발과 통과 조건



| 추가 항목 | 완료 전에 확인할 것 |
| --- | --- |
| 통합 자원 계측 | 허용량·실측·가용성·버전·중복 장치의 위조 시험 |
| AI 보상 카테고리 | 현재 reward source 허용 목록과 CPU/GPU 점수 필드 확장 · 운영 모드 경계 |
| 기간별 점수 엔진 | 예산 합계·상한·0분모·재시도·동일 이벤트·정책 변경 시험 |
| 체인 연결 | 기존 포인트 미러를 새 지급으로 중복 계산하지 않음 · 지급 영수증 대조 |
| 실제 지급 시험 | 승인된 제한 환경에서 동일 기여의 중복 지급 방지와 실패 복구 확인 |

## Codex 의견 · 먼저 숫자를 공개할 수 있게 만듭니다

보상 예측 화면에는 제공 사양, 실측 버전, 인정 시간, 작업군별 점수, 적용 예산·단가, 보류 사유와 정책 버전을 함께 보여주는 편이 좋습니다. 처음에는 금전적 약속이 없는 기여 점수로 실제 장비를 측정하고 기존 저장 보상과 비교한 뒤 단가와 지급 수단을 정할 것을 권고합니다. 같은 입력과 정책 버전으로 점수를 재계산하면 정산 산식과 상한 적용을 검증 할 수 있다.


## 설계 결정

- 사용자 확정 요구: 일반 NODE와 AI NODE 모두 제공한 사양에 따라 보상 평가 대상이 됩니다.
- 구체 산식·사양계수·가용성/수행 예산·지급 단가는 검토 중인 제안입니다.
- 실측 허용 사양·가용 시간·검증된 작업을 사용하며 물리 자원과 이벤트의 중복 보상을 막습니다.
- 기존 포인트 기록, canonical 코인과 실제 지급 조건을 분리하고 운영 보상 코드는 이번에 변경하지 않습니다.
- NODE-REWARD-DRAFT-0.1의 수치는 기획 제안이며 NP는 기존 P·PLAIS와 별도 단위입니다.

## 검토 과제

- 일반 저장·CPU·AI·검증자 범주별 예산과 가용성/수행 배분 비율
- 자원군별 기준 업무·벤치마크 버전·정산 기간·수요 승인 조건
- 기존 담보 게이트·포인트 카테고리·전환 게이트와 신규 정책의 연결
- 수치 기획안 v0.1의 실측 비교·예산 승인·기존 포인트와의 연결 여부