La ruta de entrada
Transacción firmada
Validaciónfirma · formato · estado de la cuenta · ¿puede pagarla el remitente?
Descartada, con motivo devueltono en silencio — quien la envió sabe por qué
Almacén de transacciones
Difusión a pares
Formación de lotes, luego consenso
La validación es barata y local, así que los recursos caros de aguas abajo se gastan solo en transacciones que podrían ejecutarse de verdad.
rechazada
aceptada
Cómo se guardan las transacciones
Las transacciones aceptadas no se guardan en una sola cola plana. El almacén mantiene varias vistas sobre el mismo conjunto, y cada una responde a una pregunta distinta.Un conjunto de transacciones aceptadascinco vistas sobre él, no cinco colas
Orden por cuentaPara este remitente, ¿cuál es la siguiente?
Índice de prioridadEntre todos los remitentes, ¿qué se ofrece antes al consenso?
Índice de caducidad¿Qué ha superado su plazo?
Índice de línea temporal¿De qué no se ha enterado este par?
Zona de espera¿Qué está bien formado pero aún no es elegible?
La zona de espera es donde se ve un fallo de integración: una transacción válida que aún no es la siguiente de su remitente queda en espera, no rechazada — y se vuelve elegible en cuanto se cierra el hueco de delante.
La zona de espera merece la mayor atención, porque es donde se hace visible toda una clase de fallo de integración. Una transacción puede ser perfectamente válida y aun así no ser la siguiente en la cola de su remitente: casi siempre porque una transacción anterior de la misma cuenta no ha llegado o no se ha confirmado. Esa transacción queda en espera en lugar de ser rechazada: sigue disponible y se vuelve elegible en cuanto se cierra el hueco que tiene delante. Un cliente que envía fuera de orden experimenta por tanto un retraso, no un fallo, pero un cliente que nunca rellena el hueco deja trabajo en espera hasta que caduca.
El índice de línea temporal es lo que hace incremental la difusión entre pares. De cada par se registra hasta qué punto de la línea temporal se le ha servido, de modo que una difusión envía lo que a ese par le falta en lugar de reenviar el pool entero. La línea temporal está segmentada en lugar de ser una fila única, lo que impide que un remitente pesado monopolice todos los turnos de difusión.
Difusión y reparto equitativo
Los nodos no se enteran de las transacciones cada uno por su cuenta. Un nodo que acepta una transacción la difunde a sus pares, y no todos los pares reciben el mismo trato: los pares aguas arriba tienen prioridad, para que una transacción avance hacia los validadores que pueden actuar sobre ella en lugar de difundirse de forma uniforme por la red. El reparto equitativo se controla sobre el historial reciente en lugar de imponerse mensaje a mensaje. El mempool mantiene un registro móvil de qué remitentes y qué tipos de tráfico han consumido capacidad recientemente, y lo usa para modelar qué se sirve a continuación. Este es el mecanismo que impide que la tormenta de órdenes y cancelaciones de una sola cuenta desplace al resto de la red, sin necesidad de un límite de solicitudes duro por cuenta que penalizaría al market making legítimo.Entrega al consenso
El consenso no toma las transacciones del mempool de una en una. Las transacciones se reúnen en lotes, los lotes se difunden a los validadores en segundo plano y los validadores acusan recibo de cada lote hasta que su originador puede demostrar que una parte suficiente de la red lo tiene. Solo entonces puede una propuesta de bloque referenciarlo. La consecuencia es que una propuesta de bloque lleva digests de lotes en lugar de cuerpos de transacción, así que el tamaño de los mensajes de consenso se mantiene plano cuando sube el rendimiento, y un bloque confirmado siempre es reejecutable, porque se demostró que los datos que hay detrás estaban disponibles antes de referenciarlos. Consulta IntentionBFT para ver cómo se forma y se usa esa prueba.Por eso también la admisión al mempool no es lo mismo que la inclusión. Una transacción aceptada, almacenada y difundida ha entrado en la cola; no ha sido ordenada. Nada sobre el destino de una transacción queda decidido hasta que el consenso confirma el bloque que la contiene.
Qué significa esto para un cliente
- Un rechazo en el envío es informativo. Ocurrió antes de que la transacción se almacenara, y el motivo describe algo que el cliente puede arreglar.
- El silencio no es un rechazo. Una transacción puede estar en espera detrás de un hueco que el propio cliente ha creado. Lleva la cuenta de lo que has enviado y de lo que se ha confirmado, en vez de dar por supuesto que la falta de acuse de recibo significa un descarte.
- El orden dentro de una cuenta importa; el orden entre cuentas no. Dos transacciones de un mismo remitente tienen una secuencia definida. Dos transacciones de remitentes distintos las ordena el consenso, no quién envió primero.
- Las cancelaciones no tienen privilegio en el mempool. La prioridad de cancelación es una propiedad de la ejecución del kernel, donde las cancelaciones se ejecutan antes que las colocaciones agresivas del mismo bloque, no de las colas.