Saltar al contenido
Financial Context Wiki

RPC para transacciones privadas

Un RPC para transacciones privadas dirige una transacción firmada o un bundle a un conjunto limitado de proveedores, relays o builders antes de su difusión por el mempool público; modifica la divulgación inicial, no las garantías de validez, inclusión, precio o finalidad.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un RPC para transacciones privadas envía una transacción firmada o un bundle ordenado por una ruta de servicio limitada antes de que se difunda por el mempool público. La ruta puede incluir un proveedor RPC, un relay, builders seleccionados y, cuando se revelan indicios, searchers. Por tanto, «privado» describe la distribución inicial, no el cifrado, el anonimato ni la invisibilidad frente a intermediarios.

El servicio puede reducir la exposición a copias, front-running o ataques sándwich en el mempool público, pero no garantiza inclusión, éxito en la EVM, mejor ejecución, reembolso de MEV ni finalidad. La confirmación de un proveedor o el hash de transacción devuelto solo demuestra que la solicitud llegó a esa interfaz. La distribución a builders, la selección del payload, la inclusión en un bloque, el status del recibo, la pertenencia a la cadena canónica y la finalidad son estados distintos.

No deben tratarse todos los métodos privados como equivalentes. Una llamada individual a eth_sendPrivateTransaction, un eth_sendBundle heredado y un mev_sendBundle pueden diferir en bloques objetivo, cuerpos ordenados, reverts permitidos, sustitución o cancelación, selección de builders, indicios de privacidad y reglas de reembolso. El resultado depende de la cadena, el endpoint, la versión de la API y el payload firmado exactos.

Cómo funciona

La wallet construye y firma primero una transacción ordinaria de la cadena con chain ID, nonce, destino, valor, calldata, límite de gas y topes de comisiones EIP-1559. El enrutamiento privado cambia dónde se envían esos bytes firmados; no elude el orden de los nonces, las comprobaciones de saldo y allowance, la ejecución del contrato, las reglas de base fee ni la validación por consenso. Retransmitir los mismos bytes firmados conserva el hash de la transacción, mientras que una sustitución con el mismo nonce y comisiones o calldata distintos genera otro hash.

El proveedor puede simular el payload respecto de un estado identificado y distribuirlo a uno o varios builders. La simulación depende de ese estado: los saldos, el almacenamiento, los valores de oráculos, las transacciones competidoras y la base fee pueden cambiar antes de construir el bloque. Un builder puede omitir una transacción válida porque llegó tarde, pagaba demasiado poco, perdió frente a un bloque de mayor valor o nunca alcanzó al builder elegido por el proposer.

Los bundles añaden una política de ejecución ordenada. Un revert obligatorio puede hacer que un bundle no sea admisible, mientras que un revert permitido de forma expresa puede consumir gas y mantener los cambios de estado anteriores del bundle. No se produce automáticamente una reversión atómica de todo el conjunto. Los indicios de privacidad pueden revelar el hash, la dirección del contrato, el selector de función, la calldata o los logs; un modo rápido o con muchos builders amplía el alcance y, por lo general, el conjunto de confianza y divulgación.

La gestión del nonce y de los tiempos de espera exige una máquina de estados explícita. Una transacción privada pendiente puede no aparecer en la vista pending de un RPC público ordinario y bloquear nonces posteriores. La cancelación por parte del proveedor solo detiene futuros envíos por las rutas que controla; no puede retirar una copia ya compartida, difundida públicamente o incluida. Una sustitución con el mismo nonce o un fallback público compite con todas las versiones supervivientes y vuelve a exponer el flujo de órdenes al público.

Utilice este proceso:

  1. Fije el chain ID, el proveedor y la versión de la API; elija el método de transacción privada individual o de bundle y documente las políticas de registros del proveedor, distribución a builders o searchers, indicios de privacidad, revert, reembolso y fallback público.
  2. Decodifique la intención sin firmar y el payload firmado exactos: remitente, nonce, destino, valor, calldata, allowances, límite de gas, topes de comisión, deadline, output mínimo, intervalo de bloques objetivo y cada elemento ordenado del bundle.
  3. Simule respecto de un bloque y estado identificados; pruebe éxito y revert, cambios de estado, slippage, variaciones de saldo, fallos permitidos, gas total y el peor resultado económicamente válido.
  4. Envíe por el endpoint previsto y conserve el hash de la transacción o del bundle, ID de solicitud, identidad de autenticación, marca temporal, bloque objetivo o máximo, builders, indicios y payload original.
  5. Supervise por separado la confirmación del proveedor, la simulación, la distribución a builders, el nonce privado y el vencimiento respecto del recibo canónico; actualice las hipótesis de bloque objetivo y comisión antes de reenviar.
  6. Al llegar al deadline, decida expresamente si esperar, cancelar, sustituir con el mismo nonce o divulgar mediante un fallback público; nunca suponga que la cancelación retira las copias ni envíe versiones incompatibles sin seguir su carrera.
  7. Concilie en la cadena correcta el status del recibo, los logs, saldos, output, precio efectivo del gas y reembolso; espere después al estado safe o finalized requerido e investigue reorgs, filtraciones o diferencias de ejecución sin explicación.

Ejemplos

  • La protección del output no es mejor ejecución. Un swap cotiza una entrada de 100,000 USDC con un output mínimo de 98,800 USDC. La ejecución pública devuelve 98,950 USDC, una diferencia de 1,050 USDC o 1.05% frente a la par, pero solo 150 USDC por encima del mínimo. El enrutamiento privado puede reducir la observación; no garantiza un output mejor que otro mercado público o una RFQ.
  • Límite de inclusión EIP-1559. Una transacción utiliza 180,000 gas, la base fee es de 30 gwei, el tope de prioridad es de 2 gwei y la comisión máxima de 40 gwei. El precio efectivo es min(40, 30 + 2) = 32 gwei, por lo que la comisión asciende a 180,000 x 32 = 5,760,000 gwei = 0.005760 ETH. Si la base fee de un bloque candidato es 42 gwei, la comisión máxima de 40 gwei no puede cubrirla y el enrutamiento privado no hace que la transacción pueda incluirse allí.
  • Carrera del fallback con el mismo nonce. El payload privado A y el fallback público B usan ambos el nonce 42. Existen dos envíos, pero la cadena canónica solo puede consumir una vez el nonce 42. Si A se incluye en el bloque N + 2, B queda obsoleto; si B se incluye primero, A queda obsoleto. La confirmación de una cancelación no deshace la operación y deben seguirse todas las copias supervivientes.
  • Un revert permitido no implica reversión atómica. En un bundle ordenado, la aprobación utiliza 45,000 gas y un swap revierte tras 120,000 gas a un precio efectivo de 25 gwei. Sin una regla que permita el revert, el bundle se excluye con la política indicada. Si se permite el revert del swap y el bundle se incluye, la aprobación puede persistir, el swap tiene status = 0 y el coste de gas es (45,000 + 120,000) x 25 gwei = 0.004125 ETH.

Riesgos

  • La wallet utiliza una cadena, proveedor, endpoint o versión de API incorrectos.
  • El DNS, TLS, una API key o la interfaz RPC sufren phishing o quedan comprometidos.
  • El proveedor correlaciona IP, cuenta, momento y datos del payload firmado.
  • Un relay registra, filtra, copia o retransmite públicamente la transacción completa.
  • Los indicios de privacidad revelan un hash, selector, contrato, calldata o logs.
  • El modo rápido o una amplia distribución a builders aumentan el conjunto de confianza y divulgación.
  • Un builder o searcher censura, copia o explota el flujo de órdenes privado.
  • La simulación usa el bloque equivocado o queda obsoleta antes de construir el bloque.
  • El estado del contrato, los saldos, precios u orden cambian y provocan un revert.
  • La base fee, comisión máxima o prioridad hacen que el payload no resulte atractivo o válido.
  • Un hueco de nonce o una transacción privada pendiente invisible bloquea nonces posteriores.
  • La cancelación o sustitución con el mismo nonce pierde una carrera temporal.
  • Un fallback público silencioso restaura la exposición al MEV del mempool público.
  • Se interpreta mal el bloque objetivo, bloque máximo, timestamp o TTL del servicio.
  • El orden del bundle o la política de reverts permitidos deja un cambio de estado no deseado.
  • La cobertura o censura de builders, relays o proposers impide la inclusión.
  • Una caída, limitación de solicitudes o latencia del proveedor hace perder la ventana válida.
  • El enrutamiento privado se confunde con protección frente al slippage o mejor ejecución.
  • Se concilian de forma incorrecta el estado del recibo, logs, saldos, comisiones o reembolsos.
  • Un reorg, una suposición prematura de finalidad o el límite de un secuenciador L2 invierte la conclusión.

Errores comunes

  • Privado significa cifrado, anónimo e invisible. El proveedor y las partes downstream seleccionadas pueden ver el payload completo o los indicios revelados.
  • Un RPC privado garantiza ausencia de MEV y el mejor precio. Modifica la distribución; los límites contractuales, la comparación de mercados y la calidad de ejecución siguen importando.
  • El éxito del RPC o un hash de transacción implican inclusión, éxito y finalidad. Confirmación, recibo, estado EVM y finalidad son estados diferentes.
  • La cancelación o sustitución con el mismo nonce está garantizada. Las copias y versiones competidoras corren hasta que una se incluye o todas vencen.
  • Una transacción privada es automáticamente un bundle atómico. Las transacciones individuales y los distintos formatos de bundle tienen semánticas de orden y revert diferentes.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...