블라인드 릴레이 남용 방지
AeroNyx 노드가 암호화된 릴레이 트래픽을 전달하기 전에 적용하는 제한: 이전 홉 속도 제한과 격리, 재시작에도 안전한 경로 재전송 억제, 제한된 재시도와 CPU 입장 제어. 서명된 메타데이터와 집계 카운터만 사용합니다.
블라인드 릴레이 남용 방지(Blind Relay Abuse Guard)는 AeroNyx 노드가 다른 노드를 위해 암호화된 릴레이 트래픽을 전달하기 전에 적용하는 제한의 집합입니다. 서명된 라우팅 메타데이터와 로컬 카운터만 사용하여 남용하거나 불안정한 피어를 억제합니다. 암호문을 파싱하거나, 경로 이력을 보관하거나, 누가 누구와 대화하는지 노출하는 일은 절대 없습니다.
범위
| 통제 | 상태 |
|---|---|
| 불투명한 페이로드 전달 | 구현됨 |
| 서명된 신선도 검사와 경로 재전송 억제 | 구현됨. 노드의 채팅 릴레이 저장소가 활성화되어 있으면 재전송 상태가 재시작 후에도 유지됨 |
| 이전 홉 속도 제한과 격리 | 구현됨 |
| 프로세스 전체 요청 및 암호 연산 입장 제한 | 구현됨 |
| 노드 상태와 Nodeboard의 집계 런타임 증거 | 구현됨 |
| 평문이나 페이로드 검사 | 설계상 하지 않음 |
| 사용자별, 경로별 또는 소셜 그래프 분석 | 설계상 하지 않음 |
블라인드 노드 규칙
릴레이는 라우팅 메타데이터를 인증하고, 제한된 정책을 적용하고, 불투명한 봉투를 전달하고, 서명된 수신 확인을 반환할 수 있습니다. 페이로드를 검사하거나, 경로, 사용자 신원 또는 관계를 재구성할 수 있는 메타데이터를 노출해서는 절대 안 됩니다. 특히 릴레이는 다음을 기록하거나 노출하지 않습니다.
- 메시지, 패킷, 미디어 또는 메모리의 평문
- DNS 쿼리, 목적지, 도메인, URL 또는 브라우징 기록
- 경로 ID, 전체 경로, 엔드포인트 URL 또는 클라이언트 IP 주소
- 전체 공개 키, 수신자 신원, 메시지 ID 또는 소셜 그래프 엣지
- 개인 키, 바우처 비밀 값, 지갑 수준 트래픽 또는 복호화 자료
입장 파이프라인
각 요청은 전달 용량을 사용하기 전에 다음 검사를 통과합니다. 1단계부터 6단계까지는 이 순서대로 실행됩니다. 7단계에서 이 노드를 대상으로 하는 요청은 자체 종단 또는 어니언 처리로 넘어가고, 다른 노드를 위한 요청은 다음 홉이 확인된 후 예약됩니다.
1. request gate: process-wide admission window and in-flight limit (64 requests)
2. crypto admission: a free slot for signature and onion work, or Backpressure
3. authenticate the signed previous hop and envelope
4. previous-hop rate limit and quarantine check
5. envelope metadata: size, age and future-skew limits
6. self-loop check
7. route loop, TTL and next-hop descriptor checks, plus the route replay reservation
8. forward the opaque ciphertext, or peel the terminal layer and deliver
모든 결정은 복호화된 내용이 아니라 서명된 라우팅 메타데이터와 로컬 집계 상태를 사용합니다.
런타임 제한
다음은 노드 소스의 현재 기본값입니다. 이 값들은 운영 값이며, 영구적인 프로토콜 약속이 아닙니다.
| 상수 | 기본값 |
|---|---|
BLIND_RELAY_ROUTE_REPLAY_CAPACITY | 활성 경로 8192개 |
BLIND_RELAY_ROUTE_REPLAY_TTL_SECS | 600초 |
PREVIOUS_HOP_RATE_LIMIT(PREVIOUS_HOP_RATE_WINDOW_SECS당) | 60초당 요청 120개 |
PREVIOUS_HOP_FAILURE_THRESHOLD(PREVIOUS_HOP_FAILURE_WINDOW_SECS당) | 300초당 점수 반영 실패 12회 |
PREVIOUS_HOP_QUARANTINE_SECS | 300초 |
MAX_PREVIOUS_HOP_BUCKETS | 버킷 4096개 |
BLIND_RELAY_MAX_ENVELOPE_AGE_SECS | 600초 |
BLIND_RELAY_MAX_FUTURE_SKEW_SECS | 120초 |
BLIND_RELAY_DELIVERY_RECEIPT_MAX_AGE_SECS | 120초 |
DEFAULT_MAX_ATTEMPTS(전달 재시도) | 3회 시도 |
MAX_IN_FLIGHT_BLIND_RELAY_REQUESTS | 요청 64개 |
이전 홉 속도 제한과 격리
속도 제한은 이전 홉의 서명된 신원을 키로 삼습니다. 하나의 이전 홉에서 60초 안에 120개를 초과하는 요청이 오면, 해당 홉에 대해 5분간의 로컬 격리가 시작됩니다. 별도의 실패 점수는 5분 안에 점수 반영 실패가 12회 발생하면 같은 격리를 시작합니다. 점수에 반영되는 사유는 다음뿐입니다.
invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted
전송 시간 초과, 유실된 확인 응답, 중복 재시도, 재전송 충돌은 점수에 더해지지 않으므로, 정상적인 피어가 네트워크 문제 때문에 격리되지는 않습니다. 버킷 저장소는 크기가 제한되어 있고 유휴 버킷은 제거되므로, 이 장치가 장기적인 통신 그래프로 커질 수 없습니다.
경로 재전송과 재시도
모든 릴레이 요청에는 경로 ID가 있습니다. 노드의 채팅 릴레이 저장소가 활성화되어 있으면([memchain.chat_relay] enabled = true), 경로 예약과 완료된 응답이 해당 SQLite 데이터베이스에 보관되므로 재전송 보호가 재시작 후에도 유지됩니다. 그렇지 않으면 노드는 같은 용량과 기간을 가진 인메모리 레지스트리를 사용합니다. 8192개 슬롯이 모두 활성 경로로 차 있으면, 슬롯이 만료될 때까지 새 경로는 replay_capacity로 거부됩니다.
반복된 경로 ID는 다음 네 가지 결과 중 하나가 됩니다.
| 상황 | 응답 | 이전 홉에 대한 영향 |
|---|---|---|
| 같은 요청이며 첫 시도가 완료됨 | 종단 노드가 서명한 수신 확인을 포함해 저장된 응답을 재생합니다. 아무것도 두 번 전달되거나 전송되지 않습니다(duplicate_route) | 성공으로 집계됨 |
| 같은 요청이며 첫 시도가 아직 진행 중임 | HTTP 503 route_in_flight. 발신자는 재시도할 수 있습니다 | 없음 |
| 같은 경로 ID로 온 다른 요청 | HTTP 400 replay_conflict | 피어 상태에 기록됨. 격리 점수에는 더해지지 않음 |
| 같은 요청이지만 저장된 응답이 120초보다 오래됨 | HTTP 409 replay_response_expired. 경로는 600초 기간의 남은 시간 동안 예약 상태로 유지되므로 다시 실행될 수 없습니다 | 없음 |
마지막 결과는 영구 저장소에 적용됩니다. 서명된 수신 확인은 신선한 증거로서만 유효하므로, 노드는 120초가 지난 수신 확인을 재생하지 않습니다.
다음 홉으로의 전달이 시간 초과, 연결 오류 또는 요청 오류로 실패하면, 노드는 총 3회까지 시도합니다. 각 재시도 전의 짧은 지연은 경로 ID, 다음 홉, 시도 번호에서 산출됩니다. 하위 노드가 확정적인 거부로 보고한 실패는 재시도하지 않습니다.
암호 연산 입장(운영자 용량 참고)
서명 검사, 어니언 계층 벗기기, 수신 확인 서명은 CPU 집약적이므로, 각 노드 프로세스는 이를 제한합니다.
- 총 슬롯: 호스트가 보고하는 CPU 스레드의 절반을 올림한 값이며, 최소 4개, 최대 8개이므로 스레드가 1~2개인 호스트도 4개의 슬롯을 갖습니다.
- 인바운드 요청: 총 슬롯보다 하나 적게 할당되므로, 아웃바운드 경로 생성과 수신 확인 완료는 항상 진행될 수 있습니다. 따라서 가장 작은 호스트에서도 인바운드 요청은 3개의 슬롯을 사용합니다.
- 모든 슬롯이 사용 중일 때: 요청은 HTTP 429와
backpressure사유로 즉시 거부됩니다. 대기열에서 기다리지 않습니다.
따라서 작은 호스트에서는 버스트가 발생하면 릴레이가 일찍 부하를 덜어 냅니다. backpressure_dropped 카운터가 증가한다면 노드에 CPU가 더 필요하거나 릴레이 트래픽을 줄여야 한다는 뜻입니다.
집계 런타임 카운터
노드는 하트비트에서 대략적인 누적 카운터와 신선도 타임스탬프를 다음 위치에 보고합니다.
system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.blind_relay_quality
system_stats.discovery_status.peer_store.peer_health_summary
| 카운터 그룹 | 필드 |
|---|---|
| 수신과 처리 결과 | received, terminal, forwarded, rejected |
| 검증과 보호 | invalid_signature, envelope_too_large, ttl_exhausted, no_route, invalid_endpoint, loop_detected, replay_dropped, timestamp_rejected, rate_limited, quarantined, quarantine_started |
| 전송과 재시도 | backpressure_dropped, forward_failed, retry_attempted, retry_succeeded, retry_exhausted |
| 합성 프로브 | probe_attempted, probe_succeeded, probe_failed, two_hop_probe_attempted, two_hop_probe_succeeded, two_hop_probe_failed |
| 실제 전달과 신선도 | verified_client_onion_deliveries, last_verified_client_onion_delivery_at, last_accepted_at, last_event_at |
이 카운터는 노드 운영을 설명합니다. 메시지 로그나 과금 데이터가 아니며, 특정 대화가 이루어졌다는 것을 증명하지 않습니다.
증거 품질
품질 요약은 네 가지 증거를 구분해 둡니다. 수락된 불투명 릴레이 작업, 합성 도달성 프로브, 합성 2홉 프로브, 그리고 클라이언트가 시작한 전달에 대해 종단 노드가 서명한 수신 확인입니다. real_relay_ready에는 신선하고 인증된 클라이언트 전달 수신 확인이 필요합니다. 합성 증거는 절대 사용자 트래픽으로 보고되지 않습니다.
status | 의미 |
|---|---|
idle | 아직 릴레이나 프로브 활동이 없음 |
observing | 일부 증거가 있지만 준비 상태가 확립되지 않음 |
stale | 이전의 성공 증거가 더 이상 신선하지 않음 |
ready | 신선한 수락 작업 또는 자격을 갖춘 증명이 있으며, 활성 전송 문제가 없음 |
protecting | 릴레이가 계속 작동하는 동안 남용 방지 장치가 작동함 |
degraded | 전달 또는 프로브 실패에 대한 조사가 필요함 |
attention | 백프레셔 또는 소진된 재시도에 대해 운영자의 신속한 조치가 필요함 |
proof_scope는 관찰된 가장 강력한 증거를 나타냅니다: client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted 또는 none.
트래픽 관계 없는 피어 상태
peer_health_summary를 사용하면 운영자는 누가 누구와 통신하는지 보지 않고도 실패 중이거나 격리된 피어를 찾을 수 있습니다.
포함되는 것: 축약된 노드 ID 접두사, 대략적인 상태와 디스크립터 상태, 가십 및 경로 성공의 신선도, 집계된 경로 성공 및 실패 횟수, 격리 상태, 남은 시간, 대략적인 사유 구간.
절대 포함되지 않는 것: 전체 노드 공개 키, 경로 ID, 엔드포인트 목록, 암호화된 블롭 또는 페이로드 해시, 메시지 ID, 수신자 신원, 클라이언트 IP 주소, 목적지, DNS 데이터, 소셜 그래프 엣지.
소스 맵
| 계층 | 노드 저장소의 경로 | 역할 |
|---|---|---|
| 릴레이 오케스트레이션 | crates/aeronyx-server/src/api/chat_peer/blind_relay.rs | 요청 게이트, 암호 연산 입장, 인증, 루프 및 TTL 검사, 재전송 결과, 전달 및 종단 처리 |
| HTTP 인터페이스와 제한 | crates/aeronyx-server/src/api/chat_peer.rs | 라우트, 본문 및 동시 처리 제한, 오류 코드와 사유 구간 |
| 남용 정책 | crates/aeronyx-server/src/api/chat_peer_abuse_guard.rs | 이전 홉 속도 제한, 실패 점수, 격리 |
| 재전송 레지스트리 | crates/aeronyx-server/src/api/chat_peer_replay.rs | 인메모리 레지스트리와 저장된 응답 형식 |
| 영구 재전송 저장소 | crates/aeronyx-server/src/services/chat_relay_blind_route_store.rs | SQLite 경로 예약과 응답 |
| 재시도 정책 | crates/aeronyx-server/src/api/chat_peer_retry.rs | 재시도 가능한 실패와 확정적 실패의 구분, 재시도 타이밍 |
| 카운터와 품질 | crates/aeronyx-server/src/services/peer_store.rs 및 services/peer_store/status.rs | 집계 카운터, 준비 상태, 증명 분류 |
| 상태 보고 | crates/aeronyx-server/src/api/vpn_health.rs 및 management/reporter.rs | 로컬 상태 JSON과 하트비트 페이로드 |
노드 소프트웨어는 AGPL-3.0에 따라 github.com/AeroNyxNetwork/AeroNyx에 오픈소스로 공개되어 있습니다. 경로가 구성되는 방식은 노드 탐색과 암호화된 멀티홉 릴레이를 참고하세요.
<!-- faq:start -->자주 묻는 질문
릴레이 노드가 전달하는 트래픽을 읽거나 기록할 수 있나요?
아니요. 릴레이는 서명된 라우팅 메타데이터를 확인하고 불투명한 봉투를 전달합니다. 집계 카운터만 보관하며, 페이로드, 경로 이력, 수신자 신원은 절대 보관하지 않습니다.
노드가 같은 경로를 재시도하면 어떻게 되나요?
첫 시도가 완료되었다면 노드는 저장된 응답을 재생하며 아무것도 두 번 전달하지 않습니다. 첫 시도가 아직 진행 중이라면 노드는 재시도 가능한 route_in_flight를 반환합니다. 같은 경로 ID로 온 다른 요청은 replay_conflict로 거부됩니다.
재전송 보호는 노드 재시작 후에도 유지되나요?
노드의 채팅 릴레이 저장소가 활성화되어 있으면 유지됩니다. 이 경우 경로 예약과 완료된 응답이 SQLite에 보관됩니다. 이 저장소가 없으면 노드는 재시작 시 초기화되는 인메모리 레지스트리를 사용합니다.
피어는 왜 격리되나요?
피어가 60초 안에 120개를 초과하는 요청을 보내거나, 5분 안에 점수 반영 검증 실패가 12회 발생하면 5분간 격리됩니다. 시간 초과, 유실된 확인 응답, 중복 재시도는 실패로 집계되지 않습니다.
부하가 걸리면 내 노드가 왜 backpressure를 반환하나요?
릴레이 암호 연산 슬롯이 모두 사용 중이었기 때문입니다. 노드는 서명 및 어니언 작업에 CPU 스레드의 약 절반(최소 4개, 최대 8개)을 허용하며, 초과 요청은 대기열에 넣지 않고 즉시 거부합니다.
<!-- faq:end -->