Por Canuto  

Pod Network abrió una ventana a su arquitectura de alto rendimiento en el episodio “How Pod Network Achieves 300k TPS – Inside the Pod Episode 2”, donde sus voceros desglosaron por qué su protocolo y su ingeniería apuntan a maximizar velocidad: consistencia eventual, ejecución en memoria, modelo de actores, batching de votos, almacenamiento tipo append-only log y una red optimizada sobre UDP con enfoque de cero copias.
***

  • El protocolo de Pod Network busca velocidad con “consistencia eventual”, evitando depender de un orden total inmediato para procesar transacciones.
  • El nodo se diseña como un pipeline con modelo de actores, memoria local por thread, batching agresivo y un registro append-only en lugar de base de datos.
  • En red, Pod prioriza UDP, mensajes en crudo (sin JSON), paquetes ajustados al MTU y lectura por lotes desde buffers del kernel para reducir drops.

 

Un protocolo que prioriza la velocidad: consistencia eventual

Pod Network presentó una explicación técnica de por qué su sistema puede apuntar a un desempeño muy alto desde la capa de protocolo. En “How Pod Network Achieves 300k TPS – Inside the Pod Episode 2”, Alex conversó con Janice y con Yanni sobre el tema de performance, enfocándose primero en la idea de que el consenso, en su naturaleza, no siempre necesita imponer un orden único e inmediato a cada transacción para avanzar.

Según Yanni, el protocolo de Pod permite procesar transacciones en distinto orden entre validadores, y aun así converger hacia un mismo estado después de cierto tiempo. A esa propiedad la describió como “consistencia eventual”. La implicación práctica es clara: si el sistema no obliga a esperar a que todo quede ordenado desde el inicio, puede mantener más trabajo avanzando en paralelo.

Este enfoque no elimina la necesidad de llegar a un estado común, pero cambia el momento en que ese acuerdo total se vuelve crítico. En redes blockchain, la tensión entre seguridad, descentralización y performance suele concentrarse en el consenso y en la propagación de datos. Pod propone que parte del ahorro viene de no bloquear el avance de la ejecución por el requisito de orden estricto desde el primer instante.

En términos de contexto, muchas plataformas de contabilidad distribuida diseñan su pipeline para que cada bloque o lote tenga una secuencia explícita y definitiva antes de ejecutar. Ese patrón ayuda a simplificar razonamiento y auditoría, pero suele costar tiempo, comunicación entre nodos y esperas en momentos de congestión. Pod plantea un camino distinto: procesar antes, y converger después.

De la teoría a la práctica: “ser rápido” también se construye

Yanni enfatizó que un protocolo que permita paralelismo no basta por sí mismo. Para alcanzar desempeño real, el nodo debe estar implementado con decisiones de ingeniería que eviten cuellos de botella típicos. En su descripción, Pod se apoya en cuatro pilares: modelo de actores, UDP en red, un mecanismo de almacenamiento tipo append-only log y batching de votos.

La combinación busca atacar problemas conocidos en sistemas de alto rendimiento: sincronización costosa entre threads, latencias por IO de disco, sobrecarga por serialización, y costos criptográficos en firma y verificación. Pod no presentó cifras nuevas en esa conversación, pero sí organizó la explicación alrededor de lo que midieron como sus principales bottlenecks.

Una de las ideas recurrentes fue evitar el trabajo que obliga a “esperar”. En vez de una arquitectura que se frena por bloqueos o por operaciones de base de datos, el diseño apunta a que cada etapa del pipeline procese y entregue su resultado rápidamente a la siguiente etapa, para iniciar de inmediato con la siguiente tanda.

Ese estilo de diseño, más cercano a sistemas de mensajería y procesamiento por etapas, se ha vuelto común en infra de trading y telemetría. Pod lo adapta a un nodo validador, donde cada milisegundo cuenta porque se multiplican los costos a medida que crece el volumen de transacciones y mensajes de consenso.

Modelo de actores: memoria local, menos bloqueos y más pipeline

El “actor model” fue presentado como una de las bases para escalar el procesamiento. Yanni lo explicó con una analogía simple: cada actor o componente tiene su propia memoria, corre en su propio thread y se comunica con otros actores mediante canales. En vez de compartir estructuras mutables con locks, cada actor recibe “mensajes” con trabajo por hacer.

En un ejemplo, una transacción llega al nodo y la toma un actor que verifica. Luego, ese actor envía el resultado al worker de ejecución. Tras ejecutar, el flujo continúa hacia la creación de un voto, su almacenamiento y finalmente la firma y difusión. Cada actor, al terminar con un elemento, puede comenzar el siguiente sin esperar a que el resto del pipeline concluya.

Esta separación aporta rendimiento por varias razones. Primero, Pod busca mantener “todo en memoria” en el camino caliente, evitando disco o una base de datos como dependencia frecuente. Segundo, la memoria local por thread favorece el uso de caché y reduce penalizaciones por acceso a memoria compartida. Tercero, reduce necesidad de primitivas de sincronización, que suelen ser uno de los mayores cuellos de botella en software multihilo.

Yanni añadió que en su implementación evitan mutexes, locks y hasta read locks. En su lugar, los canales entre threads se convierten en el mecanismo de coordinación, usando operaciones atómicas menos costosas que los bloqueos tradicionales. Además, el pipeline permite “ensanchar” actores donde sea posible, agregando workers si una etapa queda rezagada.

Finalmente, el batching también aparece aquí: si un actor recibe muchos mensajes, puede procesarlos en conjunto y reducir la cantidad de sincronizaciones necesarias para comunicarse con el siguiente actor. Pod lo planteó como una forma de minimizar todavía más los costos de coordinación, que a menudo dominan cuando el resto del trabajo ya se optimizó.

Append-only log: reemplazar queries por escritura secuencial y replay determinista

Otro componente clave fue el “append log”, descrito como alternativa a usar una base de datos para almacenamiento principal. Yanni señaló que, en aplicaciones tradicionales, consultar o actualizar una base de datos para buscar transacciones o estado suele resultar caro. Un append-only log evita ese patrón mediante un archivo binario abierto, al que se le agrega información al final de manera secuencial.

La lógica se centra en almacenar las entradas del sistema, no el estado mutable final. En lugar de actualizar saldos directamente como “quitar a Bob y sumar a Alice”, el sistema registra que “ocurrió una transacción”. Luego, cuando hace falta reconstruir estado tras reiniciar el nodo, se vuelve a reproducir el orden de mensajes desde ese archivo y se reconstruye el estado completo.

El enfoque depende de la determinación: si las entradas son deterministas, el replay produce el mismo estado. Con ello, Pod evita el costo de “random access” típico en bases de datos y privilegia un patrón de IO secuencial. Este patrón suele ser más amigable con el rendimiento de disco y con la predictibilidad del sistema.

En la explicación, el append log aparece como una etapa dentro del pipeline. No funciona como un sistema de consulta complejo, sino como un registro de eventos que luego permite reconstrucción. Para sistemas que priorizan throughput, esa decisión tiende a recortar latencias en el camino crítico, aunque también obliga a diseñar bien las herramientas de lectura, indexación o auditoría fuera de la ruta caliente.

Ejemplo de pipeline: de transacciones a votos firmados en lote

Para aterrizar el flujo, Yanni presentó un ejemplo con dos transacciones: una transferencia de Alice a Bob, y otra de Bob a Charlie. Ambas entran desde la red, se agrupan en un batch y pasan al actor de verificación de firmas. Ese actor valida firmas una por una dentro del lote y genera un nuevo batch como entrada para el worker de ejecución.

En la ejecución, el worker procesa transacciones y, si las considera correctas, crea una “attestation” confirmando validez. Además realiza los cambios de balance en memoria: actualiza el saldo de Bob, de Alice y de Charlie. El punto central es que esta fase ocurre en memoria, lo que reduce esperas por IO y aprovecha la localidad, especialmente cuando una cuenta, como Bob, aparece en más de una transacción.

Después, las salidas del execution worker pasan al actor de append log. Ahí, el lote se almacena en disco, pero solo como anexado secuencial al archivo de log. El flujo sigue hacia el actor “signer”, que firma en nombre del validador, usando su clave privada. Este firmante toma hashes de cada transacción, crea un hash agregado a partir de esos hashes, y firma ese único hash junto con metadatos como timestamp y números de secuencia.

La consecuencia es una firma para todo el batch. Según Yanni, firmar y verificar son operaciones costosas, mientras que hashear suele ser barato. Al firmar el hash agregado, cada nodo reduce el tiempo de firma, y quienes reciben el lote también reducen verificación, porque validan el conjunto en lugar de cada elemento por separado.

Alex vinculó este diseño con mediciones internas: el equipo detectó tres grandes bottlenecks, que Yanni enumeró como IO, verificación y firma. A partir de ese diagnóstico, Pod priorizó batching y el uso del append-only log para minimizar el costo total por unidad procesada, manteniendo la mayor parte del trabajo en memoria y empujando a disco solo operaciones secuenciales.

Red y transporte: UDP, MTU, lectura por lotes y datos binarios

En el plano de networking, Pod describió una apuesta por UDP en lugar de TCP o websockets, junto con varias técnicas para sostener el ritmo de entrada sin que el kernel descarte paquetes. Yanni indicó que buscan evitar fragmentación, asegurando que votos o datos de transacciones “quepan” en un solo paquete UDP, dentro del MTU.

El envío en un solo paquete reduce complejidad en reconstrucción y baja latencias asociadas a fragmentos perdidos. Aun así, UDP tiene el riesgo de drops cuando llegan demasiados mensajes y los buffers se saturan. Para mitigar, el equipo usa funciones del kernel que permiten extraer múltiples mensajes del buffer en una sola operación, mencionando específicamente lotes de 32.

La lectura por lotes viene acompañada de buffers preasignados, y un esquema que evita copias adicionales. Yanni lo describió como “zero allocation” y “zero copy” para mover el contenido lo más rápido posible fuera del kernel y hacia los workers que decodifican la información. Luego, el sistema vuelve de inmediato por el siguiente batch de paquetes.

También destacaron la decisión de transmitir datos como bytes en crudo, sin serialización JSON. En su lugar, utilizan una codificación binaria simple diseñada por el propio equipo, con estructuras fáciles de codificar y decodificar. La motivación incluye velocidad y control: evitar dependencias en librerías que puedan cambiar comportamientos entre versiones o introducir trabajo oculto.

En conjunto, la tesis de Pod es que el rendimiento no depende de un único truco, sino de un stack coherente. Eso implica protocolo con consistencia eventual, un nodo con actores y batching, persistencia secuencial con append-only log, y red optimizada para absorber alto volumen sin sucumbir a la sobrecarga de copias, bloqueos o serialización pesada.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados