---
status: LIVE_SYNTHETIC_CANARY_PASSED
completed_at: 2026-08-05T00:04:13.758Z
production_user_data_used: false
production_multi_replica_enabled: false
main_server_outage_continuity_proven: false
---

# 다중 replica 실제 노드 canary 결과

## 결론

2026-08-05에 고정 hostname allowlist 없이 당시 적격한 PC 노드를 동적으로 골라, 4 KiB 합성 plaintext를 일회성 메모리 키로 AES-256-GCM 암호화한 뒤 실제 PC Sync storage 경로에서 다음 흐름을 끝까지 확인했다.

1. ciphertext를 서로 다른 세 PC 노드에 동시에 저장하고 receipt 세 개를 확인했다.
2. replica 하나를 이 canary 범위에서만 논리적으로 상실 처리했다.
3. 기존 세 노드가 아닌 제4 적격 노드가 선택되어 replica가 다시 세 개로 보충됐다.
4. 메인 서버의 canary cache를 의도적으로 보류한 상태에서 PC replica 하나가 ciphertext를 restore-upload했다.
5. 복구 ciphertext hash와 메모리에서 복호화한 plaintext hash가 최초 hash와 모두 일치했다.

판정은 `SYNTHETIC_THREE_REPLICA_REPLENISH_AND_RESTORE_PROVEN`이다. 이는 실제 PC data plane에서 동시 복제, node-loss 이후 보충, PC발 복구가 작동한다는 증거다.

## 비식별 증거

- canary ID: `replica-canary-20260804T235943617Z-9604f4d1`
- ciphertext 크기: 4096 bytes
- 최초 replica receipt: 3
- 전체 replica 이력: 4
- 최종 active/healthy replica: 3/3
- 관찰된 failure domain: 2
- replacement receipt: 확인
- 중앙 cache 보류 상태의 node restore upload: 확인
- plaintext round trip: 확인
- ciphertext SHA-256: `a4e683202d451cf1407e002b294c4b69d7366b0575f7f9c411cf8c6f9bbb30c8`
- plaintext SHA-256: `4ee7600d41dcd6d8c1e085d3f36f9b5d9aae3bddccd95159e1926a22ad1dfcc0`
- 자동 보존 만료: `2026-08-11T23:59:43.617Z`

node ID, device ID, hostname, IP, token, 암호화 키는 증거 파일에 기록하지 않았다. PC에는 ciphertext만 전달했고 일회성 복호화 키는 메모리 밖으로 내보내지 않았다.

## 시험 중 발견하고 수정한 결함

PC가 저장 검증 receipt를 보내는 순간 `cacheRestoreStatus=requested`가 먼저 지워져 restore task를 놓칠 수 있는 race가 드러났다. 검증 route가 대기 중인 restore 요청을 보존하도록 수정한 뒤 같은 canary를 재개했고 PC restore-upload와 양쪽 hash 검증이 성공했다.

또한 동일 node identity에 이미 관찰된 client version보다 낮은 프로세스가 다시 register하여 작업권을 탈취하지 못하도록 monotonic client-version floor를 적용했다. canary node는 `1.4.65` floor와 heartbeat가 일치했다.

## 안전 경계와 남은 한계

- production 사용자 payload, production traffic, DNS, 공개 API, 외부 전송, operator signing, validator set은 변경하지 않았다.
- `AISFOR_NODE_MULTI_REPLICA_ENABLED`는 production `.env`에 선언되지 않아 일반 chunk는 계속 기존 single-replica 경로를 사용한다.
- canary의 초기 배포와 장애 후 보충 판단은 실행 중인 메인 AISFOR control plane이 담당했다.
- 따라서 이번 성공은 **분산 storage data plane**의 증거이지, 메인 서버가 꺼진 뒤에도 새 replica를 스스로 보충하거나 전체 서비스를 지속한다는 증거는 아니다.
- 관찰 failure domain은 2개다. 정책 최소값은 충족했지만 3개 replica가 모두 서로 다른 독립 장애영역에 있다는 증거는 아니다.

다음 gate는 chain commitment로 검증되는 manifest를 PC끼리 교환하고, 메인 없이도 lease와 replica repair 결정을 재현하는 control plane이다.

