프라이빗 RPC 가 바꾸는 것은 가시성이지 정산이 아니다

목적: 애플리케이션은 곧잘 공개 멤풀 가시성을 제출이 존재한다는 증거로 씁니다. 프라이빗 주문 흐름은 그 가정을 깨고, 공급자 전용 상태와 일반적인 체인 파이널리티를 함께 요구합니다. MEV 보호 RPC 는 트랜잭션을 공개 멤풀에 방송하지 않습니다. 프런트러닝은 줄일 수 있지만, 많은 애플리케이션이 제출 성공의 증거로 조용히 쓰던 공개 관찰 경로도 함께 사라집니다.

동작 방식: 동일한 스왑을 공개 RPC 와 Flashbots Protect 로 제출하고, 각 해시가 어디서 관찰되는지 기록하며, 취소와 타임아웃 동작을 시험하고, 둘을 정규 receipt 기준으로 대사합니다. ### PoC 동일한 소액 스왑을 공개 엔드포인트와 Flashbots Protect 로 제출합니다. 무관한 공개 노드에서 둘을 관찰하고, 공급자 접수와 포함 지연을 기록하며, 취소 또는 대체를 시험하고, 정해진 마감에서 대기를 중단합니다. 두 흐름 모두 정규 receipt 와 파이널리티를 기준으로 대사합니다. ### 무엇을 증명하나 프라이빗 제출은 "서명됨"과 "포함됨" 사이에 공급자 전용 상태를 추가합니다. 드롭, 만료, revert, 리오그 상태를 없애지는 않습니다. UI 는 공급자가 접수함, 멤풀에서 관찰됨, 체인에 포함됨을 구분해야 합니다. 참고: [Flashbots Protect 문서](https://docs.flashbots.net/).

검토 후 보완: ### 숨은 가정: "멤풀에서 보임"이 당신의 존재 증명이었다 대부분의 앱은 입 밖에 내지 않지만, "퍼블릭 멤풀에서 내 tx 해시가 보인다"를 제출 성공의 증거로 씁니다 — 공짜의, 제공자 불문 심장박동. 프라이빗(Flashbots Protect)으로 가면 그 박동이 멈추고, 함정은 이것입니다 — **신호의 부재가 실패의 증거가 아니다.** tx 는 멀쩡히 빌더의 프라이빗 오더플로에 앉아 당신의 폴러에게만 안 보일 수 있습니다. 순진한 UI 는 영원히 "pending"을 돌리거나 실패를 오판합니다 — 트랜잭션의 문제가 아니라 **모니터링 가정이 만들어낸 거짓 음성(false negative)**입니다. 제목의 요점이 정확히 이것입니다 — 프라이버시는 *상태 기계*가 아니라 *모니터링 경로*를 바꿨습니다. ### 프라이버시는 상태를 더할 뿐, 없애지 않는다 정직한 생애주기는 칸 하나를 얻고 관찰 채널 하나를 잃습니다 — 체인이 아니라 당신에게서: | 상태 | 누가 알려주나 | 뜻 | 아닌 것 | | --- | --- | --- | --- | | signed | 당신 | 바이트 존재 | 제출 아님 | | **accepted-by-provider** | Flashbots ack | 수신, 포함을 *시도* | **합의 아님, 포함 아님** | | in public mempool | 아무 노드 | 브로드캐스트(퍼블릭만) | 포함 아님 | | included | 정규 receipt | 블록에 안착 | 파이널 아님 | | final | 파이널리티 | 리오그 안전 | — | 프라이빗 RPC 는 당신에게서 "in public mempool" 줄을 지우고 "accepted-by-provider"를 끼웁니다. 그 새 칸이 정확히 `bundler-paymaster-dependencies` 모양입니다 — 정산이 아니라 가용성·정책인 제공자별 승인. Flashbots 의 "받았다"는 한 당사자의 관점(`rpc-view-not-consensus`)이고, 그래서 카드가 *무관한* 퍼블릭 노드에서 관찰하라고 고집합니다 — 제출한 제공자 자신의 상태가 가장 덜 독립적인 증인이니까요. ### 유일한 그라운드 트루스는 하류에 있고, 그마저 receipt 가 아니다 두 흐름을 **정규 receipt 와 파이널리티**에 대조하십시오 — receipt 는 또다시 `receipt-is-not-settlement`(파이널 전까지 하나의 관점)이니까요. 그래서 규율은 UI 가 절대 뭉개면 안 되는 세 분리입니다 — *accepted-by-provider* ≠ *included-on-chain* ≠ *final*. 이 중 둘을 합치는 것이 바로 PoC 가 드러내려는 버그입니다. ### 고정 데드라인이 하중을 받는 이유 퍼블릭 심장박동이 없으니 tx 의 생존을 지켜볼 수 없고, 명시적 타임아웃과 그 뒤의 *결정*이 필요합니다 — 제공자를 통해 취소(원본을 본 적 없는 멤풀에 대체 tx 를 뿌리는 게 아니라), 리프라이스, 또는 환불. `bundler-paymaster-dependencies`·`x402-settlement-retry` 와 같은 폴백 상태기계이고, 그 지속 실행의 집은 `temporal-durable-execution` 입니다. 취소가 가장 날카로운 함정입니다 — 평소의 replace-by-fee 사고는 여기 없는 퍼블릭 멤풀을 전제합니다. ### 아무도 값을 안 매기는 비용: 공개 적을 프라이빗 의존으로 바꾼 것 프라이빗 오더플로는 프론트러닝을 줄입니다 — 그게 목적 — 하지만 당신의 의도를 먼저 보고 전달 여부·시점을 정하는 한 운영자를 거칩니다. 열린 멤풀 위협을 Flashbots 와의 신뢰·가용성 관계로 맞바꾼 것이죠. 반드시 더 나쁜 건 아니지만 **다른 베팅이고, 베팅으로 적혀야** 합니다 — `bundler-paymaster-dependencies`·`layerzero-default-is-a-choice` 와 같은 "결국 누구에게 의존하게 됐나" 질문. ### 한 법칙의 네 얼굴 이 카드와 `rpc-view-not-consensus`, `receipt-is-not-settlement`, `bundler-paymaster-dependencies` 는 한 법칙의 네 얼굴입니다 — **"클릭했다"에서 "파이널"까지의 모든 단계가 *누가 관찰하고 누가 결정하는가*에 대한 서로 다른 가정을 숨긴다** — 상태 읽기, receipt 신뢰, 승인 받기, 계속 보이기. 이 카드는 *계속 보이기* 얼굴입니다.