NODE 사양별 기여도와 보상

숫자를 읽는 기준 · 새 단가 제안 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라는 이름이나 화면 설명만 보고 시간당 누적 지급으로 계산하면 안 됩니다. 운영 원장을 읽거나 실제 정산을 실행한 것은 아닙니다.

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

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

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

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

AI NODE · GPU 모델별 숫자 비교

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

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

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

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

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

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

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

고정한 것은 기획안 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의 현재 기반과 추가할 기능

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

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

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

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

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

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

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

PLAIS CHAIN에서 확인한 현재 기반

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

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

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

자원별 사양 평가 방법

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

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

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

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

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 참여와 실제 검증자 운영 자격도 구분합니다.

추가 개발과 통과 조건

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

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