AeroNyx

탈중앙화 프라이버시 노드 운영 및 상태 점검

AeroNyx2026년 6월 18일8분 읽기49회 조회

AeroNyx 탈중앙화 프라이버시 노드의 상태, 발견, 블라인드 릴레이, 재시작 복구, 용량, 패킷 런타임, 2홉 증명과 Cargo 캐시를 안전하게 운영합니다.

「탈중앙화 프라이버시 노드 운영 및 상태 점검」은 AeroNyx 문서의 공식 한국어 페이지입니다. AeroNyx는 프로토콜 계층과 제품 경험을 분리합니다. 프로토콜은 지속 가능한 공개 능력을 제공하고, 제품은 App, Nodeboard, 암호화 채팅, 암호화 저장소, 노드 운영 경험을 담당합니다.

개요

이 문서는 「탈중앙화 프라이버시 노드 운영 및 상태 점검」이 AeroNyx 오픈 프라이버시 프로토콜에서 맡는 역할, 구현 범위, 프라이버시 불변식, 개발 및 노드 운영상의 주의점을 한국어로 설명합니다.

AeroNyx 아키텍처에서의 위치

이 주제는 노드 운영자 범주에 속합니다. AeroNyx를 하나의 중앙화 서비스가 아니라 클라이언트, 탈중앙화 프라이버시 노드, 백엔드 조정자, nodeboard가 함께 사용하는 오픈 프라이버시 프로토콜 능력으로 이해해야 합니다.

현재 구현 핵심

  • 사용자 내용과 관련된 모든 기능은 종단 간 암호화 또는 암호문 객체로 전달되어야 합니다.
  • 탈중앙화 프라이버시 노드는 상태, 용량, 연결, 경로 증명, 집계 통계를 보고할 수 있지만 메시지 본문, 접근 자격 증명, 사용자 비밀을 읽을 수 없습니다.
  • nodeboard는 운영 가시성을 위해 노드 상태, peer discovery, 재시작 복구, 용량, 패킷/트래픽, 프로토콜 상태를 보여줍니다.
  • 현재 백엔드는 조정, 정렬, 집계, 공개 문서 API를 담당하며, 일부 책임은 이후 Rust 프로토콜 계층으로 이동할 수 있습니다.

프라이버시 경계

AeroNyx의 핵심은 blind-node invariant입니다. 릴레이 노드와 MemChain 조정자는 암호문, 타임스탬프, 증명, 집계된 상태 신호, 제한된 라우팅 메타데이터만 처리합니다. 평문, DNS 내용, 목적지, 통신 관계를 알 수 없어야 합니다.

노드 운영자가 확인할 항목

운영자는 대역폭, 연결 한도, IP 풀, conntrack, 파일 디스크립터, packet drops, pps, bps, peer store, heartbeat freshness, restart recovery를 확인해야 합니다. 운영 UI는 문제 해결을 돕되 사용자 내용이나 식별 가능한 데이터를 노출해서는 안 됩니다.

개발자 및 제품 연동

클라이언트, App, AI agent, 외부 서비스는 AeroNyx의 암호화 envelope, 서명, blind relay, 익명 자격 증명, healthcheck 규칙을 재사용해야 합니다. 새로운 API는 공개 메타데이터와 E2E payload 내부에 남아야 하는 필드를 명확히 구분해야 합니다.

현재 상태

이 페이지는 현재 공개 가능한 AeroNyx 프로토콜 및 제품 설계 경계를 설명합니다. multi-hop routing, blind-signed vouchers, encrypted media blob, MemChain 동기화, 노드 발견 개선은 같은 translation_key 아래에서 계속 유지되어야 합니다.

<!-- memchain-witness-operations-v1:start -->

Pinned witness 운영

Pinned witness는 MemChain commitment coordinator의 명시적 운영 신뢰 정책입니다. 독립적으로 운영되고 감사되었으며 해당 coordinator의 기록을 보존하는 follower만 설정해야 합니다.

toml
[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64-hex-ed25519-node-id-1>", "<64-hex-ed25519-node-id-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

검증 전에 모든 placeholder를 실제 값으로 바꾸십시오. 최대 세 개의 고유하고 0이 아닌 32-byte Ed25519 ID만 허용되며 coordinator에서만 유효합니다.

안전한 배포 순서는 감사된 follower 두 대 이상을 업그레이드하고, strict를 끈 상태로 정확한 ID를 추가하고, aeronyx-server validate -c /etc/aeronyx/server.toml을 실행하고, 재시작 후 operator_pinned 서명 증거가 수락되는지 반복 확인한 다음 strict를 켜는 것입니다.

strict가 꺼져 있을 때 witness에 연결할 수 없으면 명시적 degraded warning이 발생하지만 가용성은 유지됩니다. 서명된 remote-ahead 또는 divergence는 항상 시작을 차단합니다. strict가 켜져 있으면 검증 증거가 하나도 없어도 시작이 차단됩니다.

Checkpoint는 서명 프로토콜 endpoint이며 익명 브라우저 GET은 health check가 아닙니다. Witness는 rollback 탐지를 강화하지만 그 자체로 consensus, quorum 또는 finality를 만들지 않습니다.

검증된 프로덕션 배포 — 2026년 7월 14일

한 프로덕션 coordinator에 운영자가 고정한 witness ID 세 개가 설정되어 있습니다. 독립적으로 운영되고 감사된 follower 두 대가 호환 checkpoint service를 실행하며, 각각 동일한 33개 block과 8,339개 commitment 기록을 검증하고 저장했습니다. Coordinator는 두 follower가 각각 서명한 converged 응답을 수락한 뒤 commitment_witness_startup_required = true를 활성화했습니다.

검증된 재시작에서 startup guard는 configured=3, eligible=3, attempted=3, verified=2, converged=2를 기록했고 UDP 및 TUN listener는 검사를 통과한 뒤에만 열렸습니다. 이는 운영자가 고정한 node의 rollback evidence이며 consensus, quorum, 공개 체인의 finality 또는 token execution이 아닙니다.

<!-- witness-threshold-enforced-v1:start -->

2-of-3 시작 임계값 강제 — 2026년 7월 14일

프로덕션 coordinator는 이제 commitment_witness_min_verified = 2와 commitment_witness_startup_required = true를 함께 설정합니다. 서로 다른 고정 witness의 유효한 서명 증거가 두 개보다 적으면 시작을 거부합니다. 유효 응답이 없으면 signed_checkpoint_unavailable, 하나뿐이면 signed_checkpoint_threshold_unmet입니다. 최근 프로덕션 재시작에서는 UDP, TUN, 공개 API listener를 열기 전에 설정된 witness 세 개 중 두 개를 검증했습니다.

이는 운영자가 정의한 시작 임계값이며 네트워크 consensus, quorum, finality, leader election 또는 fork choice가 아닙니다. Rust heartbeat는 startup_minimum_verified를 포함한 집계 정책 및 결과만 보고하며 witness ID, endpoint, checkpoint hash 또는 서명을 노출하지 않습니다.

<!-- witness-threshold-enforced-v1:end --> <!-- memchain-witness-operations-v1:end --> <!-- signed-commitment-ledger-related-v1:start -->

관련 프로토콜 사양

서명 커밋 원장과 위트니스 보호

<!-- signed-commitment-ledger-related-v1:end --> <!-- aof-semantic-integrity-v1:start -->

MemChain AOF 무결성 검사

계획된 모든 업그레이드와 재시작에 이 읽기 전용 게이트를 추가하십시오. 출력이 집계 정보뿐이므로 운영 자동화에 안전하게 사용할 수 있습니다.

bash
sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain
결과운영자 조치
status: verified, torn_tail_bytes: 0설정 검증과 guarded restart를 계속합니다.
torn_tail_detected파일을 수동 편집하지 마십시오. 완전한 의미 scan 후 guarded append-open만 불완전한 물리 tail을 제거할 수 있습니다.
무결성 오류 반환중지하고 AOF와 로그를 incident review용으로 보존합니다. 완전 record의 의미 손상은 fail closed입니다.

프라이버시: AOF 자체를 업로드, 붙여넣기 또는 공개하지 마십시오. verifier 집계 출력만 공유하십시오.

전체 무결성 및 증명 경계: 서명 커밋 원장과 위트니스 보호.

<!-- aof-semantic-integrity-v1:end --> <!-- build-cache-maintenance-v1:start -->

보호된 Cargo 빌드 캐시 유지보수

소스 빌드를 반복하면 다시 생성할 수 있는 Cargo 객체가 수십 GB 남을 수 있습니다. 통합 운영 명령은 프로토콜 상태를 삭제하거나 서비스를 재시작하지 않고 공간을 점검하고 회수합니다.

1. 호스트 변경 없이 점검

먼저 읽기 전용 inventory를 실행합니다. 기존 target, 격리된 build root, 고정 Rust 버전, 보호된 binary SHA-256과 집계 파일시스템 용량을 표시합니다.

bash
cd /root/open/AeroNyx
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. 삭제 후보 전체 미리보기

dry-run을 줄마다 검토하십시오. 삭제에는 root와 명시적인 --yes가 필요하며 status나 upgrade가 자동 정리를 실행하지 않습니다.

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. 확인된 정리 실행

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

사용자 지정 build root를 사용하면 세 명령 모두에 AERONYX_BUILD_TARGET_ROOT를 설정해 같은 격리 target을 참조하십시오.

보호 범위와 삭제 가능 범위

  • 보호됨: 실행 중인 target/release/aeronyx-server, 현재 고정 toolchain/service cache, 다른 release 실행 파일과 rollback artifact, /var/lib/aeronyx 프로토콜 데이터, /etc/aeronyx 신원/설정, 다른 서비스의 cache를 보존합니다.
  • 재생성 가능: 기존 debug/교차 target, deps, build, .fingerprint, incremental, .rlib, .rmeta, .d, 동일 서비스의 이전 toolchain target처럼 재생성 가능한 Cargo 출력만 삭제합니다.
  • 실행 보호: 삭제 전에 install/upgrade와 같은 deployment lock을 얻고 systemd MainPID가 보호 binary를 실행하는지 확인합니다. 전후 hash가 달라지면 실패합니다.

유지보수 후 검증

캐시 정리는 노드를 재시작하지 않으며 active session drain도 필요하지 않습니다. 완료 후 서비스 상태, startup readiness, discovery quorum과 2홉 증명 freshness를 확인합니다.

bash
./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

프로덕션 검증 증거 — 2026년 7월 26일

제어된 프로덕션 실행에서 50,649,768 KiB를 회수해 사용률이 90%에서 65%로 감소했습니다. binary SHA-256, MainPID, 재시작 횟수는 그대로였고 startup 실패는 0, 2홉 증명은 ready/stable을 유지했습니다.

프라이버시 경계: inventory는 로컬 경로, 크기, toolchain 버전, binary hash와 집계 용량만 출력합니다. 암호문 payload, MemChain record, 키, peer identity, route, client address, DNS, 목적지, social graph는 읽지 않습니다.

<!-- build-cache-maintenance-v1:end --> <!-- memchain-llm-provider-operations-v1:start -->

선택적 cognitive worker 제공자 운영

SuperNode cognitive worker는 선택 사항이며 기본적으로 꺼져 있습니다. 신뢰 역할이 명확한 처리 노드에서만 활성화하십시오.

최소 로컬 제공자 설정

toml
[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://127.0.0.1:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

api_key = "$ENV_VAR"도 지원합니다. 비밀을 커밋된 설정에 넣지 마십시오.

OpenAI 호환 endpoint 형식

다음 세 형식은 모두 같은 Chat Completions endpoint로 해석됩니다.

  • https://provider.example
  • https://provider.example/v1
  • https://provider.example/v1/chat/completions

type = "anthropic"이면 api_base를 생략할 수 있으며 현재 runtime은 Anthropic 공식 Messages endpoint를 사용합니다.

실패 및 리소스 동작

  • 성공 응답은 JSON 파싱 전 8 MiB, 실패 진단 본문은 64 KiB로 제한됩니다.
  • 전송, API, 파싱, 빈 응답 실패는 제공자를 영구 비활성화하지 않고 단조 시계 기반 30초 cooldown에 둡니다.
  • HTTP 429 Retry-After는 1-300초 범위에서 적용되며 값이 없으면 30초를 사용합니다.
  • router는 다른 정상 제공자를 사용할 수 있고 cooldown이 끝나면 실패한 제공자를 자동으로 다시 고려합니다. 예약 작업은 필요하지 않습니다.

재시작 전에 aeronyx-server validate -c /etc/aeronyx/server.toml을 실행하십시오. 이 동작은 현재 main 소스에 있으며 설치된 노드는 해당 변경이 포함된 릴리스로 재빌드하거나 업그레이드해야 합니다.

프라이버시 경계: 저장 및 relay 노드는 계속 node-blind입니다. 활성화된 cognitive worker와 외부 제공자는 privacy level이 허용한 prompt를 봅니다. default_level = "structured"를 유지하고 전체 내용 처리에 대한 명시적 동의가 없다면 allow_full_for는 비워 두십시오.

<!-- memchain-llm-provider-operations-v1:end -->