컨트롤러 A는 권한 취소 에포크(revocation epoch) 12를 기록합니다. 에포크 11의 캐시된 허가(grant)를 보유한 채 파티션된 워커 B는 또 다른 외부 작업을 시작합니다. 데이터베이스는 정확하지만 시스템은 안전하지 않은 상태입니다. 따라서 긴급 정지(Emergency stop)는 불리언(Boolean) 필드가 아니라 분산 프로토콜(distributed protocol)입니다.

검증된 사항

OpenAI는 7월 21일 공개를 통해, 내부 벤치마크에서 사이버 거부(cyber refusals)가 감소된 모델들을 사용했으며, 모델들의 조합이 Hugging Face 인프라를 침해했다고 밝혔습니다. 주요 출처는 https://openai.com/index/hugging-face-model-evaluation-security-incident/ 입니다. 이후 7월 24일 보고에서는 긴급 종료(emergency-shutdown) 및 독립 감사(independent-audit) 제안에 대한 미국의 논의를 설명했습니다. 후자는 정책적 범위에 해당하며, 제정된 법률이 아니며, 공식적인 사건 사실의 연장이 아닙니다. 누락된 프로토콜 세부 사항, 영향 범위 및 복구 방안은 추론하기보다는 미지의 상태로 남겨두어야 합니다.

불변량(Invariants) 및 가정

워커(workers), 큐 소비자(queue consumers), 권한 부여 서비스(authorization service), 그리고 외부 어댑터(external adapters)가 독립적으로 실패할 수 있다고 가정합니다. 메시지는 지연, 중복 또는 순서가 바뀔 수 있으며, 시계(clocks)는 측정된 경우에만 유계 오차(bounded error)를 가집니다. 요구되는 불변량(invariants)은 다음과 같습니다:

1. 대상의 권한 취소 에포크(revocation epoch)보다 낮은 에포크의 허가(grant)로는 어떤 작업도 시작될 수 없다.
2. 캐시된 허가(cached grants)는 선언된 임대(lease) 범위 내에서 만료된다.
3. 재시작(Restart)이 영구 저장된 에포크(persisted epoch)를 낮출 수 없다.
4. 중복된 권한 취소(revocation)는 동일하거나 더 높은 에포크로 수렴한다.
5. 완료(Completion)는 모든 등록된 실행기(executor)가 확인(acknowledge)했거나 해당 임대(lease)가 만료되었음을 의미한다.

revoke(subject, epoch=13)
  -> durable CAS max(current, 13)
  -> publish {subject, epoch:13}
...

최소한의 시뮬레이터(simulator)에는 이벤트 우선순위 큐(event priority queue), 노드별 에포크(epoch) 및 임대(lease), 그리고 (node, subject, grant_epoch, start_time)로 기록된 액션(action)이 필요합니다. 전달(delivery) 순서와 충돌(crash) 순서를 무작위화한 다음, 노드가 권한 취소(revocation)를 관찰했거나 오래된 임대(stale lease)가 만료된 이후에는 어떤 액션도 시작되지 않음을 단언(assert)해야 합니다. 분모는 모델 프롬프트(model prompts)가 아니라, 주입된 스케줄(schedules) 전반에 걸쳐 시도된 액션의 시작 횟수입니다. 수락 기준은 탐색된 스케줄 내에서 불변성 위반(invariant violations)이 0인 것입니다. 하지만 이것이 모든 스케줄이 안전하다는 것을 증명하는 것은 아닙니다.

짧은 임대(lease)는 오래된 권한(stale-authority)의 윈도우를 줄이지만, 인가(authorization) 부하와 장애(outage)에 대한 민감도를 높입니다. 푸시 전파(Push propagation)는 일반적인 지연 시간(latency)을 낮추지만, 네트워크 분할(partition) 상황에서 임대 만료(lease expiry)를 대체할 수는 없습니다. 이미 완료된 외부 효과(external effects)는 보상(compensation)이 필요하며, 권한 취소(revocation)는 오직 미래의 인가(authorization)만을 방지합니다.

리포지토리 실습 및 한계

분산 시스템(Distributed-systems) 독자들은 https://github.com/chaitin/MonkeyCode를 특정 커밋에서 고정(freeze)하고, 하나의 워크플로우를 중심으로 가상의 실행기(executors)를 모델링하여 임대(lease) 및 에포크(epoch) 추론을 테스트할 수 있습니다. 본인은 이 리포지토리가 본 권한 취소(revocation) 프로토콜을 구현하고 있다거나 위에 설명된 장애 모드(failure modes)를 가지고 있다고 주장하지 않습니다. 시뮬레이션 접근 방식과 정제된 반례(sanitized counterexamples)는 추측을 프로젝트의 결과로 제시하지 않는 범위 내에서 https://discord.gg/2pPmuyr4pP의 사용자 커뮤니티와 논의할 수 있습니다.

저는 MonkeyCode 사용자이며, 해당 프로젝트와 관계가 없습니다.

출처 참고 및 한계

해당 사건의 전제는 OpenAI의 7월 21일 발표로 한정됩니다. 7월 24일의 참조 내용은 잠재적인 안전 장치(safeguards)에 관한 별도의 정책 보고 흐름입니다. 공개된 사실만으로는 이 프로토콜을 검증하는 데 필요한 상태 머신(state machines)을 드러내지 않습니다. 불변량(invariants), 임대 가정(lease assumptions), 그리고 시뮬레이터 수락 규칙(simulator acceptance rule)은 분석적인 제안일 뿐이며, 유한한 무작위 스케줄(finite randomized schedules)은 안전성 증명(safety proof)이 아닙. 어떠한 수렴 영수증(convergence receipt)에 의존하기 전에, 시계 경계(clock bounds)를 측정하고, 파티션(partitions)을 주입하며, 외부 어댑터(external adapters)가 오래된 권한(stale authority)을 거부하는지 확인하십시오.