# PLAIS Chain 백서 버전 0.4 — 2026-08-04 상태: canonical 메인넷 기술·정책 문서. QBFT 네트워크는 기술적으로 가동 중이며 공개 유통과 외부 전송은 잠금 상태다. 이 문서는 투자설명서, 토큰 판매 또는 거래소 상장 공지, 미래 가치에 대한 약속이 아니다. ## 요약 PLAIS Chain은 PLAI 서비스 생태계의 canonical 결제·감사 네트워크다. AISFOR, AISTALK, AISGROUP, AISMALL 및 향후 승인된 서비스가 이벤트를 인증하고, 증명을 보존하고, 보상을 추적하며, 별도 승인된 온체인 거래를 정산할 수 있는 공통 기반을 제공한다. 현재 구조는 의도적으로 두 영역을 분리한다. - 유일한 canonical 자산 원장인 Besu QBFT 메인넷 - proof, point, wallet, reward, callback 이력을 읽기 전용으로 보존하는 legacy application ledger Canonical 네트워크는 Chain ID `20260718`, 독립성이 증명된 호스트 4대의 validator 4개, 연속적인 QBFT 블록 생성으로 기술 가동 중이다. 2026-08-04 메인넷 기술 gate 11/11을 통과했다. 공개 유통량은 0이고 외부 전송·운영자 서명·point-to-coin 전환은 잠겨 있다. 공개 활성화, 거래소 연동, 법률 검토와 독립 보안감사는 별도 승인 gate로 남아 있다. ## 문제와 목적 PLAI 생태계는 메시징, 그룹, 커머스, 스토리지, 신원, 노드 운영 전반에서 이벤트를 생성한다. 일반 서비스 데이터베이스는 각 이벤트를 효율적으로 처리할 수 있지만, 서비스마다 식별자와 재시도 방식, 이력이 다르면 서비스 간 감사 가능성이 낮아진다. PLAI Chain의 목표는 다음과 같다. - 인증되고 멱등성이 보장된 서비스 이벤트 제출 - 원본 이벤트, 보상, 검토, callback을 잇는 일관된 감사 추적 - 승인된 거래를 위한 canonical EVM 호환 원장 - application point와 canonical native asset의 명확한 분리 - 관찰 가능한 node 및 validator 준비 상태 - 기술 가동 중인 네트워크가 명시적 승인 없이 공개 활성화되는 것을 막는 fail-closed 통제 모든 서비스 payload를 온체인에 저장하는 것이 목적은 아니다. 각 서비스는 운영 데이터와 개인정보를 적절한 데이터베이스에 보관한다. Chain 계층에는 검증과 정산에 필요한 최소한의 식별자, hash, 금액, 상태, 참조만 기록한다. ## 명칭과 자산 경계 프로젝트 용어는 다음과 같다. - PLAI: 서비스 생태계 및 제품 브랜드 - PLAIS Chain: canonical 네트워크의 공개 표시명 - AISFOR-CHAIN: 기술 이력에 유지되는 개발명 및 저장소명 - PLAIS Coin: canonical 네트워크의 native asset - PLAIS: canonical native asset symbol - plais Point: legacy application reward unit Canonical native asset과 legacy point ledger는 서로 교환 가능한 자산이 아니다. Canonical native asset: - 이름: PLAIS Coin - Symbol: PLAIS - Decimals: 18 - Genesis supply: 10,000,000,000 PLAIS - 주소 형식: 표준 EVM `0x` 주소 - 공개 유통량: 0 - 외부 전송: 잠금 - 공개 발행: 미승인 Legacy application unit: - 표시 단위: plais Point - 저장 symbol: 데이터 호환성을 위한 `plais` - 저장 decimals: 6 - 정산: simulation only - canonical PLAIS 전환: 비활성화 이전 Tokenomics v0.1 자료는 PLAI/PLAI Coin을 임시 명칭으로 사용하고 6-decimal simulation ledger를 설명했다. Canonical 메인넷의 권위 있는 기술 자산명은 PLAIS Coin, symbol은 PLAIS, decimals는 18이다. 이 명칭 정리는 공개 유통을 승인하지 않으며 기존 잔액을 전환하지도 않는다. ## 시스템 구조 ### 서비스와 신원 계층 AISFOR는 canonical identity source다. AISFOR user `_id`는 application wallet mapping을 위한 안정적인 생태계 account reference로 사용한다. 현재 승인된 service identity에는 AISFOR, AISTALK, AISGROUP, AISMALL, AISFOR_CHAIN이 포함된다. 서비스는 Express control plane을 통해 proof와 reward event를 제출한다. Security enforcement가 활성화된 경우 `/api/**` 요청은 HMAC v2 인증을 요구한다. Signature는 service name, timestamp, nonce, HTTP method, request path, 정규화된 request body를 결합한다. Timestamp 허용 오차와 nonce replay 방지는 위조 및 중복 제출 위험을 줄인다. Hardened mode에서는 API key만 사용하거나 legacy signature를 사용하는 인증은 충분하지 않다. ### Canonical 원장 Canonical 메인넷 원장은 QBFT consensus를 사용하는 Hyperledger Besu다. - Chain ID: `20260718` - Consensus: QBFT - 목표 block period: 2초 - Validator identity: 4개 - RPC 역할: 별도의 non-validator node - Canonical API namespace: `/api/canonical/**` - Canonical Explorer route: `/explorer/block/:height-or-hash` Canonical status는 Besu RPC에서 읽는다. Readiness check는 chain ID, validator set, block freshness, peer identity, peer connectivity, external-transfer lock, genesis identity를 사용한다. Legacy mock block height나 mock vote는 canonical finality로 취급하지 않는다. QBFT는 정족수 가정 아래 deterministic finality를 제공한다. 그렇다고 운영 위험이 사라지는 것은 아니다. Liveness와 safety는 validator key 보안, network 연결성, 올바른 client 설정, 독립적으로 운영되는 validator topology에 계속 의존한다. ### Legacy Application Archive 이전 Express block ledger는 `legacy-read-only-archive`로 보존한다. Application proof, simulated point reward, mock wallet, callback, 과거 block reference를 유지하며 legacy mining, validator assignment, voting, finalization write는 잠겨 있다. Archive는 감사와 호환 화면에 사용할 수 있지만 validator, consensus, finality source가 아니다. 보관된 point와 wallet balance는 EVM balance가 아니며 향후 별도 승인된 migration policy 없이는 canonical ledger로 이동할 수 없다. ### 데이터 영속성 Application ledger의 JSON-to-MongoDB read migration은 staged backfill, source-hash 비교, monitored promotion, rollback control을 거쳐 완료됐다. MongoDB는 application audit data를 제공하며 Besu canonical ledger를 대체하지 않는다. JSON dataset은 rollback 및 과거 검증 source로 유지된다. 이 경계는 중요하다. Database replication은 서비스 신뢰성을 높일 수 있지만 canonical block 및 transaction history는 QBFT ledger만 결정한다. ## Proof와 감사 흐름 승인된 service proof는 `sourceService + idempotencyKey`로 멱등성을 보장한다. Event type과 활성 정책에 따라 다음 항목을 연결할 수 있다. - 원본 service와 source event - proof-ledger row와 request hash - simulated reward와 operator review - legacy archive reference - 승인된 canonical transaction - callback delivery와 acknowledgement - 관련 address, transaction, block Explorer 화면 Source system은 message body, recovery phrase, private key, 불필요한 개인정보 또는 기타 민감한 내용을 proof payload에 포함해서는 안 된다. Hash가 무결성 증거가 되려면 source data, canonicalization rule, timestamp, retention policy도 함께 통제되어야 한다. ## 지갑과 키 모델 Legacy application wallet은 receive QR, PIN-protected action, recovery setup, application-ledger traceability를 지원한다. 이 잔액은 point 또는 simulation record로 유지된다. Canonical EVM wallet은 표준 secp256k1 key와 `0x` address를 사용한다. User key material은 user PIN과 별도의 server-side vault secret에서 scrypt로 key를 파생해 AES-256-GCM으로 암호화한다. Message signature로 소유권을 확인할 수 있다. Public-value 사용 전에 독립 보안 검토, recovery test, brute-force resistance 평가, secret rotation 절차, 사용자 phishing 방지가 필요하다. Canonical operator address는 보존하지만 private key는 web process에서 제거했다. 임시 offline vault는 Windows DPAPI `CurrentUser`를 사용하고 web signing은 fail-closed 상태다. 이는 운영상 격리 조치이며 최종 public-mainnet custody 설계가 아니다. Public-value 운영에는 hardware wallet, HSM/KMS 또는 remote signer와 함께 다중 승인, transaction simulation, policy limit, immutable audit log, 검증된 disaster-recovery ceremony가 필요하다. ## PoSS 보상 모델 PoSS는 Proof of Service & Storage를 뜻한다. Service usage, content, storage capacity, 검증된 data custody, uptime, commerce, emoticon creation, moderation 및 기타 승인된 활동처럼 측정 가능한 생태계 기여를 인정하기 위한 후보 모델이다. Simulation score 구성은 다음과 같다. ```text rewardScore = serviceScore + contentScore + storageScore + uptimeScore + verificationScore + commerceScore + emoticonScore + ecosystemScore ``` Weight, eligibility, cap은 정책 입력값이며 영구적인 경제적 권리가 아니다. 현재 reward write는 simulation record다. PLAIS를 mint하지 않고, 채무나 allocation 보장 또는 교환가치를 만들지 않는다. 정산 모델 승인 전 PoSS에는 다음 통제가 필요하다. - 안정적인 source-event 정의와 idempotency rule - per-user, per-day, per-category cap - refund, cancellation, self-trading, duplicate-event 제외 - storage challenge와 restore verification - Sybil, fake-commerce, fake-uptime 탐지 - delayed settlement와 operator review - 이의 제기와 정정 절차 - 모든 계산에 대한 재현 가능한 policy versioning ## 노드, 스토리지, Validator Storage 또는 sync client가 자동으로 validator가 되는 것은 아니다. 역할은 다음과 같이 분리한다. - Service client: 인증된 ecosystem event 제출 - Storage 또는 sync node: 승인된 capacity 또는 availability evidence 제공 - Node participant: 승인된 collateral 및 reward program 참여 - Validator: QBFT validator identity를 보유하고 consensus 참여 - RPC node: voting 없이 통제된 read 및 submission interface 제공 Public-value 활성화 전 validator admission, removal, rotation, uptime threshold, penalty, emergency response, 지역·운영자 다양성, 이해상충 규칙을 정식 운영 정책으로 승인해야 한다. Canonical 네트워크의 validator identity 4개는 독립성이 증명된 호스트 4대에서 가동한다. 각 호스트는 결합된 validator identity, canonical height, peer 상태와 최신 서명 runtime evidence를 보고한다. 동일 validator key의 중복 실행은 금지한다. Validator-set 변경과 공동 재시작은 명시적이고 시간 제한된 승인을 요구하며 절차상 가능한 동안 최소 3개의 validator 정족수를 유지해야 한다. ## 임시 TRX 담보 Native PLAIS collateral이 실용화되기 전, 통제된 node-participant rehearsal에서 TRX를 임시 외부 담보 자산으로 사용할 수 있다. 현재 policy rate는 변경 가능하며 승인된 node capacity 1 TB당 100 TRX로 설정돼 있다. TRX 담보는 다음을 의미하지 않는다. - PLAIS mint - Canonical genesis supply 변경 - PLAIS 구매 - Point 또는 coin claim 보장 - Storage client의 validator 자동 전환 Server는 제출된 TRON transaction hash, destination treasury address, native TRX amount, 성공 receipt, required confirmation count를 확인할 수 있다. Confirm 또는 reject 결정은 application audit trail에 기록된다. Custody ownership, refund condition, slashing authority, dispute handling, 필요한 경우의 sanctions 및 source-of-funds review, 회계·세무 처리, incident response, user disclosure가 승인되기 전에는 public collateral intake를 통제 운영 범위 이상으로 확대해서는 안 된다. Mock 또는 test address로 실제 자금을 받아서는 안 된다. Native collateral 도입 전 임시 정책의 명시적인 종료 또는 migration 절차가 필요하다. ## 공급과 경제 정책 10,000,000,000 PLAIS genesis balance는 잠긴 canonical genesis allocation이다. 이는 circulating supply, 판매 또는 자산 배포 승인이 아니다. Candidate distribution policy v0.2의 고정 공급 배분은 다음과 같다. - 생태계·사용자 보상: 32% - Node·storage·validator 보상: 20% - Foundation treasury: 15% - Core team·contributor: 12% - Ecosystem partner·grant: 8% - Market·liquidity infrastructure: 6% - Community launch·eligibility: 5% - Security·user-protection reserve: 2% 향후 public launch가 별도 승인되면 TGE 최대 unlock 상한은 800,000,000 PLAIS, 즉 전체 공급의 8%다. Team allocation은 TGE unlock이 없고 12개월 cliff 후 36개월 선형 vesting한다. Foundation allocation은 12개월 cliff 후 60개월 선형 vesting한다. Ecosystem 및 node reward pool은 120개월 동안 방출한다. Unlock이 자동으로 circulation을 뜻하지는 않으며 실제 유통량은 강제 lock 또는 issuer-controlled wallet 밖으로 이동한 관찰 가능한 수량으로 계산한다. Private-sale allocation은 없다. Legacy point, testnet balance, reward history, node activity는 자동 claim을 만들지 않는다. Allocation wallet은 분리·공개해야 하며 월간 supply report에서 wallet balance, unlock ceiling, actual transfer, market-maker 또는 liquidity balance, burn, circulation을 canonical genesis supply와 reconcile해야 한다. 전체 규칙은 `docs/TOKEN_DISTRIBUTION_POLICY_KO.md`에 있다. 법률·세무 검토, 감사된 vesting enforcement, allocation wallet 공개, custody 승인, circulation reporting, 명시적인 launch approval 전까지 public issuance는 잠긴다. Fee policy와 community eligibility snapshot은 별도 승인이 필요하다. ## 보안과 개인정보 Public Express service는 메인넷 정보·application control plane이며 public Besu RPC endpoint가 아니다. Hardened deployment는 Express와 Besu RPC를 loopback에 bind하고, Nginx를 public ingress로 사용하며, HTTP를 HTTPS로 redirect한다. 보호된 API는 HMAC v2를 요구하고, 민감 경로를 rate limit하며, secure cookie와 browser security header를 활성화하고, external transfer와 legacy mutation path를 잠근다. Security enforcement는 fail-closed 방식이다. Canonical-ledger 선택, 인증 방식, bind address, transfer lock, asset identity, supply consistency, legacy issuance policy에 안전하지 않은 변경이 생기면 정상 시작을 막는다. 남은 보안 작업에는 독립 code 및 infrastructure audit, dependency와 build provenance, penetration test, validator-host hardening, key ceremony review, backup restoration, monitoring과 alerting, denial-of-service 계획, incident classification, disclosure channel, post-incident report가 포함된다. 최소한의 audit data만 보관해야 한다. 구체적이고 적법하게 문서화된 필요가 없는 한 개인 content는 원본 서비스에 남긴다. Blockchain hash도 개인과 연결될 수 있으면 personal 또는 sensitive metadata가 될 수 있으므로 data mapping, retention, erasure handling, access control에 privacy review가 필요하다. ## 거버넌스와 변경 통제 Formal governance model이 승인되기 전까지 canonical-mainnet change는 운영상 통제된 결정이며 decentralized governance가 아니다. 최소한 genesis, validator membership, asset name 또는 symbol, decimals, supply, issuance, conversion, external transfer, reward settlement, collateral, signer availability 변경에는 다음이 필요하다. - 서면 proposal과 risk analysis - 기술, 보안, 운영 및 필요한 법무 담당 검토 - 재현 가능한 test evidence와 rollback step - 권한자가 명시된 explicit approval - Versioned policy 및 configuration change - User-facing economic effect 발생 전 public notice Emergency action은 네트워크 보호를 위해 사용할 수 있지만 범위가 좁고, 기록되며, 기한이 정해져야 하고 사후 검토가 따라야 한다. 어떤 관리자도 일반 dashboard action만으로 point를 coin으로 전환하거나 supply를 바꾸거나 public transfer를 조용히 활성화할 수 없어야 한다. ## 현재 준비 상태 Canonical 메인넷에 구현되거나 강제되는 항목: - Besu QBFT를 유일한 canonical 자산 원장으로 선택 - Chain ID, genesis identity, validator set, liveness, peer check - 최신 runtime evidence로 독립성이 증명된 validator host 4대 - 암호화 validator-key 봉투, 승인 통제된 전달, offline operator custody - 2026-08-04 메인넷 기술 launch gate 11/11 통과 - Canonical PLAIS와 legacy point 분리 - 공개 유통량 0 및 external transfer lock - 읽기 전용 legacy application archive - HMAC v2 기반 authenticated proof 및 reward gateway - Migration control을 갖춘 MongoDB-backed application audit read - Canonical Explorer와 legacy Explorer 분리 - Web process에서 operator signing 제거 - API, session, rate-limit, HTTPS hardening gate - Validator 분산과 key delivery를 위한 script 및 runbook 미완료 public-activation 및 거래지원 blocker: - Production-grade HSM/KMS 또는 remote-signer custody 미승인 - 독립 security 및 smart-contract review 미완료 - 거래소 RPC/WS, 입금, 출금, confirmation, fault, recovery, 장기 test evidence 미완료 - Distribution policy는 정의됐지만 법률 승인, 감사된 vesting enforcement, allocation wallet 공개, fee policy, circulation reporting 미완료 - Reward 및 storage fraud control의 지속적인 production-like evidence 부족 - TRX collateral 법률, custody, refund, dispute policy 승인 필요 - Privacy, consumer, tax, sanctions, jurisdiction review 미완료 - Formal governance, incident response, user terms, risk disclosure 미승인 ## 로드맵과 Launch Gate ### Phase 1 — Canonical 메인넷 기술 Gate — 완료 Validator host 4대 분산, 암호화 validator-key 통제, canonical liveness, canonical/legacy boundary check를 완료했다. 기술 gate는 11/11을 통과했고 public control은 계속 잠겨 있다. ### Phase 2 — 운영 보증 — 진행 중 독립 host 환경에서 sustained load, partition, validator-loss, upgrade, rollback, backup-restore, incident drill을 수행하고 재현 가능한 evidence와 known limitation을 공개한다. ### Phase 3 — 경제·컴플라이언스 승인 Asset naming, allocation, emission, fee, treasury authority, PoSS settlement, collateral policy, user eligibility, privacy, legal, tax, accounting, consumer disclosure를 확정한다. ### Phase 4 — 보안·Custody 승인 독립 audit을 완료하고 finding을 해소한다. Production signer custody를 도입하고 key 및 disaster-recovery ceremony를 수행하며 vulnerability disclosure와 incident response 체계를 마련한다. ### Phase 5 — 명시적 공개 활성화와 거래소 연동 모든 mandatory gate 통과 후 새로운 서면 승인을 받아야 public transfer를 열고 거래소 연동 신청을 승인할 수 있다. Point balance, reward history, node operation, genesis allocation은 circulating PLAIS나 거래소 자격을 자동 부여하지 않는다. 이후 gate가 실패하면 승인된 계획에 따라 activation을 중단하거나 rollback해야 한다. ## 위험과 한계 주요 위험에는 validator concentration, key compromise, software defect, network partition, service-authentication compromise, database inconsistency, reward manipulation, storage-proof fraud, bridge 또는 oracle dependency, privacy leakage, custody loss, regulatory change, treasury misuse, 잘못된 사용자 기대가 포함된다. QBFT finality는 off-chain service event의 사실성을 보장하지 않는다. HMAC은 등록된 어떤 서비스가 event를 제출했는지를 증명할 뿐 실제 사람의 활동이 정당했는지는 증명하지 않는다. 따라서 PoSS와 collateral control에는 암호 기술 외에도 source validation, fraud review, governance, correction procedure가 필요하다. PLAIS의 공개 발행, 전송, 상장, point 전환 또는 금전적 가치는 보장되지 않는다. 사용자와 운영자는 전망이나 비공식 발언이 아니라 현재 공개된 정책과 runtime lock을 기준으로 판단해야 한다. ## 참고 문서 백서는 배포 작업 일지가 아니라 안정적인 구조와 정책을 설명한다. 세부 운영 통제는 다음 문서에서 관리한다. - `docs/CANONICAL_LEDGER.md` - `docs/CANONICAL_ASSET_POLICY.md` - `docs/TOKEN_DISTRIBUTION_POLICY_KO.md` - `docs/CANONICAL_VALIDATOR_MIGRATION.md` - `docs/OPERATOR_KEY_CUSTODY.md` - `docs/PUBLIC_API_HARDENING.md` - `docs/MAINNET_POLICY_DRAFT.md` - `docs/TESTNET_POLICY.md` - `docs/REWARD_SERVICE_INTEGRATION.md` - `docs/AISFOR_TOKENOMICS_V0.1.md` — 과거 simulation-policy 기준선 참고 문서와 활성 fail-closed configuration이 충돌하면 change control로 검토·해결될 때까지 더 엄격한 lock을 적용한다. ## 고지 이 백서는 2026-08-04 기준 canonical 네트워크와 잠긴 public control을 설명한다. 기술 설정과 정책은 문서화된 승인 절차를 통해서만 변경할 수 있다. 이 문서는 금융, 투자, 법률, 세무 조언이 아니며 디지털 자산을 매수, 매도 또는 수령하라는 제안이나 권유가 아니다.