﻿---
title: "RPC per transazioni private"
description: "Un RPC per transazioni private instrada una transazione firmata o un bundle verso un insieme limitato di provider, relay o builder prima della propagazione nel mempool pubblico; modifica la divulgazione iniziale, non le garanzie di validità, inclusione, prezzo o finalità."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RPC per transazioni private

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

Un RPC per transazioni private invia una transazione firmata o un bundle ordinato attraverso un percorso di servizio limitato prima della propagazione nel mempool pubblico. Il percorso può includere un provider RPC, un relay, builder selezionati e, quando vengono divulgati hint, searcher. «Privato» descrive quindi la distribuzione iniziale, non la crittografia, l'anonimato o l'invisibilità agli intermediari.

Il servizio può ridurre l'esposizione a copie, front-running o attacchi sandwich dal mempool pubblico, ma non garantisce inclusione, successo nell'EVM, best execution, rimborso MEV o finalità. La conferma di un provider o l'hash restituito dimostra soltanto che la richiesta ha raggiunto quell'interfaccia. Distribuzione ai builder, selezione del payload, inclusione nel blocco, `status` della ricevuta, appartenenza alla catena canonica e finalità sono stati distinti.

I metodi privati non sono intercambiabili. Una singola `eth_sendPrivateTransaction`, una `eth_sendBundle` legacy e una `mev_sendBundle` possono differire per blocchi target, corpi ordinati, revert consentiti, sostituzione o cancellazione, selezione dei builder, hint di privacy e regole di rimborso. Il risultato dipende dalla chain, dall'endpoint, dalla versione API e dal payload firmato esatti.

<a id="mechanism"></a>

## Come funziona

Il wallet costruisce e firma anzitutto una normale transazione della chain con chain ID, nonce, destinazione, valore, calldata, limite di gas e limiti alle commissioni EIP-1559. L'instradamento privato cambia il punto di invio di quei byte firmati; non aggira l'ordine dei nonce, i controlli su saldo e allowance, l'esecuzione del contratto, le regole della base fee o la validazione del consenso. Ritrasmettere gli stessi byte firmati conserva l'hash della transazione; una sostituzione con lo stesso nonce ma commissioni o calldata diverse produce un hash diverso.

Il provider può simulare il payload rispetto a uno stato identificato e distribuirlo a uno o più builder. La simulazione dipende da quello stato: saldi, storage, valori degli oracoli, transazioni concorrenti e base fee possono cambiare prima della costruzione. Un builder può omettere una transazione valida perché è arrivata tardi, ha pagato troppo poco, ha perso contro un blocco di maggior valore o non ha mai raggiunto il builder scelto dal proposer.

I bundle aggiungono una politica di esecuzione ordinata. Un revert obbligatorio può rendere un bundle non idoneo, mentre un revert consentito espressamente può consumare gas e lasciare in vigore le precedenti modifiche di stato riuscite del bundle. Non si tratta di un rollback atomico automatico. Gli hint di privacy possono divulgare hash, indirizzo del contratto, selettore di funzione, calldata o log; una modalità rapida o un ampio fanout ai builder aumenta la portata e, di norma, il perimetro di fiducia e divulgazione.

La gestione di nonce e timeout richiede una macchina a stati esplicita. Una transazione privata pending può non comparire nella normale vista pending di un RPC pubblico e può bloccare nonce successivi. La cancellazione del provider interrompe solo i futuri invii sui percorsi sotto il suo controllo; non può richiamare una copia già condivisa, diffusa pubblicamente o inclusa. Una sostituzione con lo stesso nonce o un fallback pubblico compete con ogni versione superstite e riespone pubblicamente il flusso di ordini.

Utilizzare questo processo:

1. Fissare chain ID, provider e versione API; scegliere il metodo per transazione privata singola o bundle e documentare registrazione del provider, distribuzione a builder o searcher, hint di privacy, revert, rimborso e fallback pubblico.
2. Decodificare l'intento non firmato e il payload firmato esatti: mittente, nonce, destinazione, valore, calldata, allowance, limite di gas, limiti alle commissioni, deadline, output minimo, intervallo di blocchi target e ogni elemento ordinato del bundle.
3. Simulare rispetto a blocco e stato identificati; verificare successo e revert, deriva dello stato, slippage, variazioni dei saldi, errori consentiti, gas totale e il peggior risultato economicamente valido.
4. Inviare tramite l'endpoint previsto e conservare hash della transazione o del bundle, ID richiesta, identità di autenticazione, timestamp, blocco target o massimo, builder, hint e payload originale.
5. Monitorare separatamente conferma del provider, simulazione, distribuzione ai builder, nonce privato e scadenza rispetto alla ricevuta canonica; aggiornare le ipotesi su target e commissioni prima di reinviare.
6. Alla deadline, scegliere espressamente se attendere, cancellare, sostituire con lo stesso nonce o divulgare tramite fallback pubblico; non presumere che la cancellazione richiami le copie e non inviare versioni incompatibili senza seguirne la competizione.
7. Riconciliare sulla chain corretta `status` della ricevuta, log, saldi, output, prezzo effettivo del gas e rimborso; attendere poi lo stato `safe` o `finalized` richiesto e indagare reorg, fughe o differenze di esecuzione inspiegate.

<a id="example"></a>

## Esempi

- **La protezione dell'output non è best execution.** Uno swap quota un input di `100,000 USDC` con output minimo di `98,800 USDC`. L'esecuzione pubblica restituisce `98,950 USDC`, uno scarto di `1,050 USDC` o `1.05%` rispetto alla parità, ma solo `150 USDC` sopra il minimo. L'instradamento privato può ridurre l'osservazione; non garantisce un output migliore rispetto a un'altra sede pubblica o a una RFQ.
- **Limite di inclusione EIP-1559.** Una transazione usa `180,000 gas`, la base fee è `30 gwei`, il limite di priorità è `2 gwei` e la commissione massima è `40 gwei`. Il prezzo effettivo è `min(40, 30 + 2) = 32 gwei`, quindi la commissione è `180,000 x 32 = 5,760,000 gwei = 0.005760 ETH`. Se la base fee di un blocco candidato è `42 gwei`, la commissione massima di `40 gwei` non la copre e l'instradamento privato non rende la transazione includibile in quel blocco.
- **Competizione del fallback con lo stesso nonce.** Il payload privato `A` e il fallback pubblico `B` usano entrambi il nonce `42`. Esistono due invii, ma la catena canonica può consumare il nonce `42` una sola volta. Se `A` viene incluso nel blocco `N + 2`, `B` diventa obsoleto; se `B` arriva per primo, `A` diventa obsoleto. Una conferma di cancellazione non è un annullamento e ogni copia superstite va monitorata.
- **Un revert consentito non è un rollback atomico.** In un bundle ordinato, l'approvazione usa `45,000 gas` e uno swap va in revert dopo `120,000 gas` a un prezzo effettivo di `25 gwei`. Senza una regola che consenta il revert, il bundle viene escluso secondo la politica indicata. Se il revert dello swap è consentito e il bundle viene incluso, l'approvazione può persistere, lo swap ha `status = 0` e il costo del gas è `(45,000 + 120,000) x 25 gwei = 0.004125 ETH`.

<a id="risks"></a>

## Rischi

- Il wallet usa chain, provider, endpoint o versione API errati.
- DNS, TLS, API key o interfaccia RPC subiscono phishing o compromissione.
- Il provider correla IP, account, orario e dati del payload firmato.
- Un relay registra, divulga, copia o ritrasmette pubblicamente l'intera transazione.
- Gli hint di privacy divulgano hash, selettore, contratto, calldata o log.
- Modalità rapida o ampio fanout ai builder aumentano il perimetro di fiducia e divulgazione.
- Un builder o searcher censura, copia o sfrutta il flusso di ordini privato.
- La simulazione usa il blocco sbagliato o diventa obsoleta prima della costruzione.
- Stato del contratto, saldi, prezzi o ordine cambiano e causano un revert.
- Base fee, commissione massima o priorità rendono il payload poco attraente o non valido.
- Un intervallo nel nonce o una transazione privata pending invisibile blocca i nonce successivi.
- Cancellazione o sostituzione con lo stesso nonce perde una competizione temporale.
- Un fallback pubblico silenzioso ripristina l'esposizione MEV del mempool pubblico.
- Blocco target, blocco massimo, timestamp o TTL del servizio vengono fraintesi.
- L'ordine del bundle o la politica dei revert consentiti lascia una modifica di stato indesiderata.
- Copertura o censura di builder, relay o proposer impedisce l'inclusione.
- Indisponibilità, rate limiting o latenza del provider fanno perdere la finestra valida.
- L'instradamento privato viene scambiato per protezione dallo slippage o best execution.
- Stato della ricevuta, log, saldi, commissioni o rimborsi vengono riconciliati male.
- Un reorg, un'ipotesi prematura di finalità o un confine del sequencer L2 ribalta la conclusione.

<a id="misconceptions"></a>

## Errori comuni

- **Privato significa crittografato, anonimo e invisibile.** Il provider e le parti downstream selezionate possono vedere il payload completo o gli hint divulgati.
- **Un RPC privato garantisce assenza di MEV e il prezzo migliore.** Cambia la distribuzione; limiti contrattuali, confronto tra sedi e qualità dell'esecuzione restano rilevanti.
- **Successo RPC o hash della transazione significano inclusione, successo e finalità.** Conferma, ricevuta, stato EVM e finalità sono stati diversi.
- **Cancellazione o sostituzione con lo stesso nonce sono garantite.** Copie e versioni concorrenti competono finché una viene inclusa o tutte scadono.
- **Una transazione privata è automaticamente un bundle atomico.** Transazioni singole e formati di bundle diversi hanno semantiche di ordine e revert differenti.

<a id="related"></a>

## Argomenti correlati

- [Mempool](/it/crypto/mempool/)
- [Attacco sandwich](/it/crypto/sandwich-attack/)
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)

<a id="sources"></a>

## Fonti

- [Settings Guide](https://docs.flashbots.net/flashbots-protect/settings-guide) - Flashbots Docs (consultato: 2026-08-13)
- [JSON-RPC Endpoints](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint) - Flashbots Docs (consultato: 2026-08-13)
- [Nonce Management](https://docs.flashbots.net/flashbots-protect/nonce-management) - Flashbots Docs (consultato: 2026-08-13)
- [Bundle Inclusion Troubleshooting](https://docs.flashbots.net/flashbots-auction/advanced/troubleshooting) - Flashbots Docs (consultato: 2026-08-13)
- [Understanding Bundles](https://docs.flashbots.net/flashbots-mev-share/searchers/understanding-bundles) - Flashbots Docs (consultato: 2026-08-13)
- [MEV-Boost Block Proposal](https://docs.flashbots.net/flashbots-mev-boost/architecture-overview/block-proposal) - Flashbots Docs (consultato: 2026-08-13)
- [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org (consultato: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) - ethereum.org (consultato: 2026-08-13)

Source: https://wiki.fcontext.com/it/crypto/private-transaction-rpc/index.mdx
