Cómo funciona Velas: Proof of History, EVM y staking delegado

Para entender Velas hacen falta tres piezas: una forma rápida de ordenar eventos, un mecanismo para que los validadores se pongan de acuerdo y un entorno donde ejecutar contratos inteligentes. Velas toma las dos primeras de Solana y añade una capa de ejecución compatible con Ethereum. Así encajan.

Proof of History: un reloj para la red

En la mayoría de blockchains se pierde tiempo porque los nodos deben discutir qué ocurrió primero. La respuesta de Solana es Proof of History: una cadena de hashes en la que cada paso demuestra que ha pasado cierto tiempo desde el anterior. Piensa en un cronómetro compartido construido con matemáticas. Como cada nodo puede verificar el orden en lugar de negociarlo, los bloques salen en una fracción de segundo. Velas heredó este diseño del código de Solana, y por eso sus bloques son cortos. Puedes ver la altura de bloque y la actividad en el explorador nativo.

Tower BFT y la votación de los validadores

Ordenar no es lo mismo que acordar. Los validadores aún tienen que votar qué bifurcación es la canónica. Tower BFT es el protocolo de votación: una variante de la tolerancia a fallos bizantinos práctica que usa el reloj de Proof of History para que cada voto sea más difícil de revertir con el tiempo. Cada voto compromete al validador con una bifurcación durante un periodo creciente, de modo que cambiar de bando sale caro. Una transacción es más segura cuanto más voto ponderado por stake se acumula sobre su bloque.

Proof of stake delegado

Para validar hace falta stake, pero no necesitas tener un servidor para ganar una parte. Los holders de VLX delegan sus monedas en un validador de confianza. El validador vota con ese peso y se queda una comisión de las recompensas; el resto va a los delegadores. Delegar no transfiere la propiedad: tus monedas siguen en tu cuenta de stake y puedes redelegar más adelante. La web oficial muestra el número de validadores y el total en staking; una red sana tiene muchos validadores sin que ninguno domine. En la página de validadores verás cómo evaluarlos y en la guía de staking, el proceso.

La EVM integrada

La Ethereum Virtual Machine es el entorno que ejecuta el bytecode de Solidity. Velas incluye una junto a su runtime nativo. Una transacción enviada a una dirección EVM la procesa esa parte, con los mismos métodos JSON-RPC que esperan las herramientas de Ethereum, por ejemplo eth_getBalance. Por eso wallets como MetaMask se conectan con solo configurar la red. El RPC de Velas para la parte EVM es público y nuestro rastreador lo consulta directamente desde tu navegador. En compatibilidad EVM tienes los pasos.

Dos mundos de direcciones

Esta dualidad es a la vez la gracia y la curva de aprendizaje. Si solo usas el lado EVM, se comporta como otra red compatible con Ethereum. Los usuarios avanzados y los validadores interactúan con el lado nativo.

Un ejemplo práctico

Imagina que envías VLX desde tu wallet a un amigo. En el lado EVM, la wallet firma la transacción, la envía al RPC, un validador la incluye en un bloque y el resto de la red la confirma con sus votos. Tú la ves en el explorador con su estado, bloque y comisión. En el lado nativo el flujo es el mismo en esencia, pero con direcciones y firmas al estilo Solana. Entender en cuál de los dos lados estás trabajando evita la mayoría de confusiones.

Dónde se menciona la IA

Los materiales de Velas hablan de un delegated proof of stake mejorado con IA. En la documentación se presenta como ayuda de aprendizaje automático en el consenso, por ejemplo para puntuar el comportamiento de los validadores, no como un chatbot dentro de la cadena. Qué es y qué no es verificable lo desgranamos en el artículo de integración de IA.

Qué significa realmente la velocidad

«Hasta 75.000 TPS» aparece en la web oficial. Es un techo de diseño en condiciones ideales, no la carga media diaria. Para el usuario las medidas útiles son otras: cuánto tarda en confirmarse una transacción y cuánto cuesta. Ambas son buenas en Velas en condiciones normales. Para cifras, mira comisiones y velocidad y, para comparaciones, Velas frente a Solana.

Límites que conviene tener presentes

Un código bifurcado tiene que seguir el ritmo de las mejoras originales, y Solana ha avanzado deprisa desde la bifurcación. El equipo de Velas mantiene su propia versión, así que las funciones y los parches de seguridad llegan según su calendario. Además, la vivacidad de la red depende de que los validadores sigan conectados. No son señales de alarma por sí solas, pero sí motivos para revisar la actividad reciente del proyecto en su documentación y en la página de hoja de ruta y noticias antes de depender de él.

Cómo encaja todo en la práctica

Si juntamos las piezas anteriores, el recorrido de una transacción es fácil de seguir. Tu wallet firma la operación, un líder de turno la recoge, la coloca en la secuencia temporal de Proof of History y el resto de validadores la verifican y votan. Cuando hay suficiente respaldo, el bloque se considera confirmado y el resultado se refleja en el explorador correspondiente. Todo esto sucede en un intervalo muy corto, y es lo que permite que la red presuma de rapidez.

Conviene entender que esa rapidez depende de condiciones que el usuario no controla: la calidad del hardware de los validadores, la conexión entre ellos y la cantidad de actividad que haya en cada momento. Una red diseñada para ir muy deprisa exige nodos potentes, y eso plantea una pregunta legítima sobre cuántas personas pueden permitirse operar uno. Es un equilibrio que comparten otras cadenas de alto rendimiento y que no tiene una respuesta única.

Para el usuario medio, lo más práctico es quedarse con una idea: Velas combina un diseño de consenso heredado de Solana con una capa de compatibilidad para herramientas de Ethereum. Las cifras de rendimiento máximo que anuncia el proyecto, como los 75.000 TPS, son un objetivo teórico, y la mejor forma de saber cómo se comporta la red es observar bloques y comisiones reales en los exploradores oficiales.

Preguntas que suelen surgir

Una duda frecuente es si tener dos entornos, el nativo y el EVM, complica la vida al usuario. En la práctica, la mayoría de las personas solo necesitan uno de ellos, y la wallet oficial se encarga de gestionar la conversión cuando hace falta. Aun así, es útil saber que existen, porque explica por qué hay dos exploradores y por qué una misma cuenta puede mostrar direcciones con formatos distintos.

Otra pregunta habitual es qué papel tienen los validadores en la seguridad. Cuanto más repartida esté la delegación entre muchos validadores independientes, más difícil resulta que unos pocos actores condicionen la red. Por eso, al hacer staking, elegir validador también es una decisión sobre la salud del sistema y no solo sobre la rentabilidad.