¿Qué es la transacción Solana V1? Explicación de la actualización de 4,096 bytes en mainnet

¿Qué es la transacción Solana V1? Explicación de la actualización de 4,096 bytes en mainnet

Imagen personalizada
Solana ha activado Transaction V1 en mainnet, aumentando el tamaño máximo de transacción serializada de 1,232 bytes a 4,096 bytes. Esta variación proporciona a los desarrolladores aproximadamente 3.3 veces más espacio dentro de una sola transacción, facilitando el manejo de cargas de trabajo intensivas en datos como pruebas de conocimiento cero, operaciones multisig grandes, transferencias confidenciales y interacciones DeFi más complejas. Transaction V1 entró en funcionamiento en el Epoch 1035 el 15 de septiembre de 2026, mientras que los formatos Legacy y V0 existentes siguen siendo compatibles.
 
El número principal, sin embargo, puede ser engañoso. La transacción V1 no hace que Solana sea 3.3 veces más rápida, ni duplica automáticamente las transacciones por segundo. En cambio, la actualización amplía la cantidad de datos serializados que pueden caber en una transacción atómica y rediseña partes del formato de transacción. Esa distinción es importante porque el beneficio más grande no es simplemente “más bytes”, sino la capacidad de completar flujos de trabajo en una sola transacción que anteriormente tenían que fragmentarse en varios pasos.

¿Qué es la transacción Solana V1?

La transacción V1 es el nuevo formato de transacciones versionadas de Solana, introducido a través de SIMD-0385 junto con la propuesta más amplia de tamaño de transacción en SIMD-0296. Su característica más visible es el aumento del tamaño máximo de transacción serializada de 1.232 bytes a 4.096 bytes. V1 también reorganiza el formato de transmisión, elimina las Tablas de Búsqueda de Direcciones y coloca las solicitudes de recursos, como límites de unidades de cómputo y tarifas de prioridad, directamente en la configuración de la transacción, en lugar de depender de las instrucciones tradicionales de Presupuesto de Cómputo.
 
Importante, V1 es un formato optativo en lugar de una sustitución obligatoria. Las aplicaciones que no necesiten espacio adicional en las transacciones pueden seguir utilizando transacciones Legacy o V0. Las transferencias ordinarias de SOL, las transferencias simples de tokens y muchas interacciones existentes de dapp por lo tanto no necesitan de repente consumir 4.096 bytes ni migrar a un nuevo tipo de transacción.
Característica Legado V0 Transacción V1
Tamaño máximo de la transacción 1,232 bytes 1,232 bytes 4,096 bytes
Formato versionado No Sí Sí
Tablas de búsqueda de direcciones No Sí No
Configuración de recursos Instrucciones de presupuesto de cálculo Instrucciones de presupuesto de cálculo Configuración de transacción
Operaciones atómicas más grandes y con muchos datos Limitado Limitado Sí
Se requiere migración No No Optar por participar
La forma más sencilla de entender la actualización es que V1 proporciona a las aplicaciones un sobre de transacción mucho más grande, manteniendo intactos los formatos de transacción anteriores.

¿Por qué se limitó Solana a 1,232 bytes?

El límite original de 1,232 bytes se remonta a la arquitectura de red de Solana, no a una decisión arbitraria sobre la complejidad de las aplicaciones. La red históricamente utilizó un MTU mínimo de 1,280 bytes de IPv6 como punto de referencia. Tras deducir los encabezados de red, quedaban disponibles 1,232 bytes para los datos de la transacción. La documentación de Solana aún identifica 1,232 bytes como el PACKET_DATA_SIZE tradicional, aunque las transacciones V1 ahora pueden exceder ese tamaño de carga útil al transmitirse a través de múltiples marcos QUIC.
 
Una transacción debe incluir mucho más que la instrucción que el usuario desea ejecutar. Incluye firmas, direcciones de cuenta, un blockhash reciente, metadatos de instrucción y datos específicos de la aplicación. Cada firma Ed25519 consume 64 bytes, mientras que una clave pública estándar de Solana es de 32 bytes. Estos números se vuelven significativos cuando una transacción involucra muchos firmantes, cuentas o pruebas criptográficas.
 
El límite de 1,232 bytes se volvió cada vez más restrictivo a medida que las aplicaciones de Solana se volvían más sofisticadas. Rara vez era un obstáculo serio para una simple transferencia de token, pero podía obligar a los desarrolladores que construían aplicaciones financieras o criptográficas avanzadas a rediseñar flujos de trabajo alrededor de un límite de red creado mucho antes en el desarrollo de Solana.

¿Por qué Solana aumentó el límite a 4,096 bytes?

Solana ahora puede relajar la antigua restricción en parte porque su pila de red utiliza QUIC, lo que permite transmitir una transacción más grande que la carga útil original del paquete a través de múltiples tramas. Esto hace que la antigua exigencia de que toda la transacción serializada quepa dentro de una sola carga útil del tamaño del MTU sea menos necesaria. Al mismo tiempo, las transacciones más grandes consumen ancho de banda adicional de los validadores, por lo que eliminar por completo el límite crearía un conjunto diferente de problemas de red y recursos.
 
El nuevo límite de 4.096 bytes, o 4 KiB, es por tanto un compromiso de ingeniería. Brinda a los desarrolladores un espacio de aplicación significativamente mayor sin hacer que el tamaño de la transacción sea ilimitado. Solana señala que las transacciones más grandes pueden consumir más ancho de banda de red y pueden requerir tarifas de prioridad más altas que las transacciones más pequeñas que compiten a un nivel de urgencia similar.
 
Esa matición es importante. La transacción V1 no es Solana abandonando las restricciones de tamaño de transacción; es Solana reemplazando un límite basado en suposiciones anteriores de la red con un techo considerablemente más alto diseñado para las aplicaciones que la red ahora necesita admitir.

Solana V1 frente a V0: ¿Qué cambió realmente?

V1 elimina las tablas de búsqueda de direcciones

V0 introdujo Tablas de Búsqueda de Direcciones, o ALT, como una solución temporal para el antiguo límite de tamaño de transacción. En lugar de colocar cada dirección de cuenta de 32 bytes directamente en una transacción, una aplicación podía referenciar direcciones almacenadas en tablas de búsqueda utilizando índices mucho más cortos. Esta compresión se volvió ampliamente utilizada: el propio análisis de Solana sobre la actividad muestreada encontró que aproximadamente el 62% de las transacciones V0 observadas referenciaban al menos un ALT. V1 elimina el soporte para ALT y coloca directamente las direcciones de cuenta dentro del sobre de transacción más grande.
 
Eliminar los ALT simplifica parte del proceso de ingesta de validadores, ya que los validadores ya no necesitan recuperar y resolver el estado de las tablas de búsqueda antes de conocer el conjunto completo de cuentas de una transacción. Pero también consume parte del espacio adicional que proporciona V1. Solana estimó que, cuando las transacciones existentes se representan bajo V1, la mitad muestra menos de aproximadamente 420 bytes de tamaño serializado adicional, mientras que el 90% muestra menos de aproximadamente 1,400 bytes. Las transacciones que anteriormente comprimían muchas direcciones mediante un pequeño número de ALT pueden experimentar una expansión mucho mayor.

Más bytes no significan cuentas ilimitadas

V1 tampoco triplica el número de cuentas que una transacción puede acceder. Solana actualmente impone un límite de 64 cuentas en tiempo de ejecución, aunque la representación subyacente del índice tiene un techo teórico más alto. Una característica separada podría aumentar eventualmente el límite de bloqueo de cuentas a 128, pero eso no es parte automática de la Transacción V1.
 
Eso significa que algunas rutas DeFi intensivas en cuentas aún pueden alcanzar el límite de cuentas incluso cuando quedan cientos de bytes de transacción sin usar. V1 crea un margen especialmente amplio para cargas de trabajo que reutilizan un conjunto de cuentas existente pero necesitan más datos de instrucciones, firmas o pruebas; es menos transformador para estrategias cuya complejidad proviene principalmente de interactuar con muchos mercados y cuentas adicionales.

Las solicitudes de recursos pasan a la transacción

V1 también cambia cómo las transacciones describen sus requisitos de recursos. Los límites de unidades de cálculo, los límites de datos de cuentas cargadas, el tamaño del heap y las tarifas de prioridad pueden ubicarse en posiciones fijas en la configuración de la transacción en lugar de expresarse mediante instrucciones ComputeBudgetProgram. Esto permite que la infraestructura de la red identifique información importante de programación antes, sin escanear la lista de instrucciones.
 
Para los desarrolladores, esto significa que la actualización es más que un mayor límite de bytes. El software que crea, decodifica, indexa, patrocina o evalúa transacciones debe comprender la nueva estructura V1 en lugar de asumir que cada transacción se comporta como Legacy o V0.

¿Qué puede desbloquear transacciones de 4.096 bytes?

Pruebas de conocimiento cero y transferencias confidenciales

La tecnología de prueba de conocimiento cero es uno de los mayores beneficiarios, ya que las pruebas pueden requerir datos de transacción sustanciales. Bajo el límite anterior, un desarrollador podría tener suficiente capacidad de cómputo para verificar una operación, pero no suficiente espacio serializado en la transacción para incluir la prueba y todas las instrucciones circundantes en una sola transacción. El sobre V1 más grande brinda a las aplicaciones de privacidad y criptografía mucho más espacio sin aumentar sus límites de cómputo o cuenta. Solana destaca específicamente las pruebas ZK y las cargas de trabajo de transferencia confidencial entre las aplicaciones que se benefician.
 
Las transferencias confidenciales de Token-2022 ilustran por qué esto es importante. Dichos flujos de trabajo pueden implicar pruebas más las instrucciones necesarias para establecer el contexto, realizar la transferencia y limpiar el estado asociado. Con una transacción más grande, las operaciones que antes tenían que ensamblarse pueden ejecutarse potencialmente como una acción atómica, reduciendo la cantidad de estados intermedios que un usuario o desarrollador debe gestionar.

Operaciones multisignatura y criptográficas más grandes

Las transacciones multisig también se benefician, ya que las firmas consumen espacio serializado significativo. Una firma Ed25519 de 64 bytes puede ser trivial en aislamiento, pero una transacción que requiere muchas aprobaciones independientes puede perder rápidamente una parte importante del antiguo envoltorio de 1.232 bytes antes de contabilizar las instrucciones del programa y las direcciones. V1 crea más espacio para la gestión de tesorería sofisticada, la custodia institucional y las estructuras de autorización.
 
Solana también ha señalado otros diseños criptográficos intensivos en datos, incluidos los flujos de trabajo relacionados con BLS y esquemas avanzados de firmas en la cadena. Esto es relevante para aplicaciones institucionales porque los requisitos complejos de autorización, custodia y privacidad suelen ser mucho más exigentes que los de un usuario minorista que envía tokens entre dos monederos.

Flujos de trabajo atómicos más complejos

Quizás la ventaja más amplia sea la atomicidad. Una transacción atómica tiene éxito por completo o falla por completo. Si una operación compleja debe dividirse en múltiples transacciones porque la transacción original es demasiado grande, los desarrolladores pueden necesitar estado temporal, confirmaciones adicionales o sistemas de agrupación para coordinar los pasos.
 
Con V1, algunos flujos de trabajo pueden incluir más instrucciones y datos en una sola transacción. Por lo tanto, el valor no radica simplemente en que una transacción contenga más información; sino en que una mayor parte de la lógica de una aplicación pueda compartir potencialmente el mismo límite de ejecución total o nula.

¿Qué significa la Transacción V1 para DeFi?

Las aplicaciones DeFi interactúan frecuentemente con múltiples programas dentro de una sola acción del usuario. Una operación sofisticada podría implicar un router de intercambio, un protocolo de préstamo, un ajuste de garantía y un paso de liquidación, mientras que una estrategia de arbitraje o liquidación puede necesitar coordinar varias acciones antes de que su economía funcione. Bajo el antiguo límite de bytes, la serialización de la transacción podría convertirse en un cuello de botella incluso cuando la red tuviera suficiente capacidad computacional para ejecutar las instrucciones previstas.
 
V1 crea más espacio para rutas de múltiples pasos, lógica de validación adicional e instrucciones ricas en datos. Esto puede reducir la dependencia de flujos de trabajo fragmentados y disminuir el riesgo de ejecución parcial. Los enrutadores y sistemas de trading que puedan integrar más lógica en una sola transacción también pueden ofrecer una experiencia de usuario más limpia, ya que los usuarios necesitan menos firmas y confirmaciones para ciertas acciones complejas. CoinDesk destacó las operaciones de múltiples pasos como una de las categorías de aplicación inmediatas que se benefician de la actualización.
 
Sin embargo, la mejora tiene límites. Los bytes de transacción, las unidades de cómputo y los bloqueos de cuenta son recursos diferentes. Aumentar el límite de bytes no otorga a una aplicación cómputo ilimitado o cuentas adicionales. El análisis de Solana V1 señala específicamente que el límite de 64 cuentas sin cambios puede seguir siendo la restricción vinculante para estrategias amplias de múltiples pools o múltiples plataformas.

¿Hará la Transacción V1 a Solana más rápida o más barata?

¿Aumenta V1 la TPS de Solana?

No por 3.3 veces. La actualización aumenta el tamaño máximo de una transacción individual, no el número de transacciones que Solana puede ejecutar necesariamente cada segundo. El rendimiento de transacciones también depende de los límites de cálculo por bloque, la contención de cuentas, la red, la composición de las transacciones y otras restricciones del protocolo. Describir la V1 como una “actualización de 3.3x TPS” confunde, por tanto, la capacidad de transacciones con el tamaño de las transacciones.
 
Solana ha aumentado por separado su límite de cálculo de bloques de 60 millones a 100 millones de unidades de cálculo, una expansión del 66% que se activó en mainnet en julio de 2026. Esa actualización añade directamente más margen computacional por bloque y es distinta de la V1.
 
V1 aún puede mejorar la eficiencia a nivel de aplicación. Si un flujo de trabajo que antes requería tres transacciones coordinadas ahora puede ejecutarse como una sola, el usuario puede experimentar menos pasos y menor latencia, aunque la TPS principal de la red no se haya triplicado. Esa distinción es la mejor manera de describir el beneficio de rendimiento.

¿Podría la Transacción V1 reducir las tarifas?

Para algunas operaciones complejas, potencialmente. Combinar varios pasos en una sola transacción atómica puede reducir firmas duplicadas, confirmaciones repetidas y otros costos asociados con dividir un flujo de trabajo. Esto podría disminuir el costo total de completar toda la acción.
 
Pero la actualización no reduce la tarifa base de transacción de Solana en 3,3 veces. De hecho, la documentación propia de Solana señala que las transacciones más grandes consumen más ancho de banda de los validadores y pueden requerir tarifas de prioridad más altas para confirmarse que las transacciones más pequeñas que compiten con prioridad similar.
 
Por lo tanto, el beneficio de la tarifa debe evaluarse a nivel de flujo de trabajo: una sola transacción más grande podría costar más que una transferencia sencilla, pero aún así ser más económica o mejor operativamente que varias transacciones más pequeñas necesarias para completar la misma tarea compleja.

Qué necesitan cambiar los desarrolladores y los monederos

Para usuarios comunes, la Transacción V1 debería ser en su mayoría invisible a menos que la aplicación que utilizan comience a aprovecharla. Para proveedores de infraestructura, la transición requiere mucha más atención. Los monederos y los SDK deben comprender el nuevo formato de serialización si desean crear o firmar transacciones V1, mientras que los servicios RPC, los Exploradores y los indexadores deben poder decodificar correctamente la nueva versión.
 
Incluso las aplicaciones que no tienen la intención de enviar transacciones V1 pueden encontrarse con ellas al leer bloques o historiales de transacciones. La guía de migración de Solana advierte a los sistemas que leen transacciones que deben admitir explícitamente la versión 1 de las transacciones. Los sistemas que hacen suposiciones basadas en estructuras V0 o buscan instrucciones tradicionales de Compute Budget podrían fallar o informar información incorrecta sobre los recursos.
 
Este problema de compatibilidad explica por qué la activación se movió a la Epoch 1035 después de que los equipos del ecosistema solicitaran más tiempo para pruebas e integración. La pregunta inmediata tras el lanzamiento no es simplemente cuántos desarrolladores comenzarán a crear transacciones grandes, sino si los monederos, proveedores RPC, indexadores, patrocinadores de tarifas y plataformas de análisis comprenden correctamente V1 a medida que comienza a aparecer en producción.

¿Qué significa la actualización para SOL?

La transacción V1 es fundamentalmente positiva para las capacidades técnicas de Solana porque amplía los tipos de aplicaciones que los desarrolladores pueden construir de manera razonable. Más espacio para pruebas, estructuras multisig institucionales, DeFi sofisticado y flujos de trabajo orientados a la privacidad puede fortalecer el caso de Solana como infraestructura para aplicaciones que van más allá de las transferencias simples de tokens. Ese es un desarrollo fundamental significativo, pero no crea una relación mecánica entre el tamaño de la transacción y el SOL token price.
 
La respuesta inmediata del mercado ha sido relativamente modesta en comparación con el tamaño del titular técnico. SOL se negociaba alrededor de $102 el 15 de septiembre, con datos de precios que mostraban que estaba aproximadamente un 35% por encima de su nivel un mes antes, pero aún sujeto a la volatilidad del mercado de criptomonedas en general.
 
Los inversores pueden obtener por lo tanto información más útil observando la adopción en lugar de la vela de precios del primer día. Las preguntas relevantes son si las transacciones V1 se vuelven comunes, si los desarrolladores lanzan aplicaciones que anteriormente eran impracticables, y si el DeFi, la privacidad, los pagos o el uso institucional se expanden como resultado. El valor económico de los adicionales 2.864 bytes depende en última instancia de lo que los desarrolladores construyan con ellos.

Cómo encaja V1 en la hoja de ruta de actualización más grande de Solana

La transacción V1 es solo una parte de un esfuerzo más amplio para eliminar cuellos de botella en toda Solana. La red ya ha aumentado la capacidad de cómputo de bloque a 100 millones de CUs, está implementando parámetros de alquiler significativamente más bajos y trabaja hacia tiempos de slot más cortos. Se espera que Agave 4.3 traiga otro cambio importante con Alpenglow, la arquitectura de consenso de próxima generación de Solana, que busca una finalidad sustancialmente más rápida.
Actualizar Objetivo principal Dirección actual
100M bloques CU Aumentar el límite de cálculo de bloque de 60M a 100M CU En vivo en mainnet
Transacción V1 Aumentar el tamaño máximo de transacción de 1.232 a 4.096 bytes En vivo en mainnet
Alquiler reducido Reduzca los parámetros de alquiler de almacenamiento en cadena hasta en un 90% Lanzamiento por fases
Tiempo de ranura reducido Mueva de ranuras de 400 ms hacia ranuras de 200 ms Lanzamiento de características
Alpenglow Nuevo sistema de consenso con una finalidad de aproximadamente 150 ms Planificado con Agave 4.3
Estas actualizaciones abordan diferentes limitaciones. Bloques más grandes generan mayor capacidad de cómputo, V1 amplía la flexibilidad de las transacciones, el alquiler más bajo reduce los costos de almacenamiento en cadena, los slots más cortos mejoran la latencia y Alpenglow se enfoca en el consenso y la finalidad. Considerar a Transaction V1 como una parte de esta arquitectura más amplia es más preciso que presentarla como una única actualización que de repente hace que cada aspecto de Solana sea tres veces mejor.
 
La estrategia más amplia es dar a las aplicaciones más espacio en varias capas simultáneamente. Si tiene éxito, Solana no solo procesará más actividad; los desarrolladores deberían tener menos restricciones a nivel de protocolo al diseñar aplicaciones complejas.

¿Qué deberíamos observar después del lanzamiento del mainnet?

La primera métrica para vigilar es simplemente la adopción de V1. Dado que el formato es opcional, la activación en mainnet no nos indica con qué rapidez los monederos, los protocolos DeFi, los proyectos de privacidad o las aplicaciones institucionales lo utilizarán realmente. Los desarrolladores tienen motivos sólidos para mantenerse en los formatos existentes cuando las transacciones ya son pequeñas y sencillas, por lo que la adopción de V1 debería concentrarse inicialmente en aplicaciones donde su capacidad adicional resuelva un problema real.
 
La confiabilidad de la infraestructura también será igual de importante. La decodificación de transacciones, la firma de monederos, la compatibilidad con RPC, la estimación de tarifas y la indexación deben funcionar correctamente a medida que aumente la actividad de V1. También valdrá la pena monitorear si las transacciones más grandes generan una nueva presión medible en el ancho de banda de los validadores o atraen tarifas de prioridad más altas, como anticipa la documentación de diseño de Solana.
 
A largo plazo, los indicadores más interesantes serán específicos de la aplicación: crecimiento en transferencias confidenciales y cargas de trabajo ZK, diseños multisig más sofisticados, rutas DeFi que requieran menos transacciones fragmentadas y flujos de trabajo institucionales que habrían sido impracticables con 1.232 bytes. La pregunta tras el lanzamiento ya no es si Solana can soporta transacciones de 4.096 bytes, sino si los desarrolladores descubren suficientes razones valiosas para usarlas.

🔥 Más allá de las noticias: qué significa KuCoin 5.0 para ti

Las noticias del mercado avanzan rápido — pero donde actúes sobre ellas importa igualmente. Este octubre, KuCoin lanza KuCoin 5.0, transformando KuCoin en una plataforma reconstruida. Aquí está lo que realmente cambia para ti:
  • Una cuenta para todo. Las plataformas antiguas dividían tu dinero entre cuentas separadas de "spot", "margin" y "futures" y esperaban que entendieras por qué. La Cuenta Unificada de KuCoin 5.0 elimina esto por completo: realiza un depósito una vez y todo está simplemente disponible.
  • Acciones, índices y materias primas. KuCoin 5.0 se expande más allá del cripto hacia mercados globales. Cuando el cripto se mueve lateralmente y las acciones suben (o al revés), rotates en minutos en lugar de abrir una cuenta de corretaje y esperar días para que se activen los canales de moneda fiduciaria.
  • Activos del mundo real (RWA). Exposición tokenizada a activos tradicionales como materias primas, directamente en tu cuenta de cripto. Uno de los segmentos de más rápido crecimiento en las finanzas globales ya no está reservado para instituciones: tú lo accedes desde el mismo saldo con el que operas.
  • Gana mientras aprendes. ¿Aún no estás listo para operar? KCUSD permite que tus stablecoins generen intereses diarios con autocomposición. La forma menos estresante de hacer que tus depósitos inactivos trabajen para ti con un rendimiento del 4%.
  • Un asistente de IA en lenguaje sencillo. Haz preguntas, obtén contexto del mercado, entiende lo que estás viendo: integrado en la plataforma, sin necesidad de jerga.
  • Una aplicación que no abruma. Más rápida, más limpia y coherente: intuitiva desde el primer toque, no después de un tutorial.
  • Seguridad que puedes verificar, no solo confiar. Una entidad de la UE con licencia MiCAR, Proof of Reserves que puedes verificar tú mismo, y seguridad certificada internacionalmente (SOC 2 Type II, ISO 27001:2022).
 
Crea tu cuenta en minutos y comienza en la plataforma diseñada para adónde va el cripto, no adónde ha estado.

Conclusión

La transacción de Solana V1 parece sencilla cuando se reduce a una sola estadística: la red ha aumentado su tamaño máximo de transacción de 1,232 bytes a 4,096 bytes. Pero el cambio más importante es lo que esos bytes adicionales pueden permitir. Pruebas, firmas, datos de configuración e instrucciones de múltiples aplicaciones pueden caber dentro de un límite de ejecución atómica más grande, reemplazando potencialmente algunos de los trabajos alternativos que los desarrolladores utilizaban anteriormente para sortear el antiguo límite.
 
V1 no hace que Solana sea 3.3 veces más rápida, no elimina las restricciones de cómputo ni garantiza tarifas más bajas. En cambio, elimina un cuello de botella en el diseño de aplicaciones cada vez más importante, mientras introduce nuevos compromisos en torno a la representación de direcciones, la compatibilidad con la infraestructura y el ancho de banda de la red. Si el nuevo formato ayuda a los desarrolladores a simplificar aplicaciones ZK, flujos de trabajo institucionales y transacciones DeFi complejas, su importancia a largo plazo podría no provenir del titular de 4.096 bytes en sí, sino de las aplicaciones que eran difíciles de construir antes de su existencia.

Preguntas frecuentes

¿Pueden los usuarios enviar aún transacciones heredadas de Solana?

Sí. Las transacciones heredadas y V0 siguen siendo compatibles después de que V1 entre en funcionamiento. La transacción V1 es opcional, por lo que las aplicaciones que no necesiten el sobre de transacción más grande pueden seguir utilizando los formatos existentes.

¿Necesito un nuevo monedero para la transacción V1?

No necesariamente. Los usuarios normales pueden seguir utilizando monederos que dependen de transacciones Legacy o V0. Sin embargo, los monederos que deseen construir, decodificar o firmar transacciones V1 deben agregar soporte explícito para el nuevo formato.

¿Aumenta V1 el número de cuentas por transacción?

No automáticamente. Solana actualmente impone un límite de 64 cuentas en tiempo de ejecución, que permanece separado del nuevo límite de tamaño de transacción de 4.096 bytes. Una función futura podría aumentar el límite de bloqueo de cuentas, pero eso no forma parte del aumento de tamaño de la V1 en sí.

¿Son todas las transacciones V1 de 4.096 bytes?

No. La cifra es un máximo, no un tamaño requerido. Una transacción V1 puede ser mucho más pequeña que 4.096 bytes, y los desarrolladores no tienen ninguna razón para llenar el espacio no utilizado simplemente porque está disponible.

¿Qué son SIMD-0296 y SIMD-0385?

SIMD-0296 es la propuesta de mejora de Solana asociada con el aumento del tamaño máximo de la transacción, mientras que SIMD-0385 especifica el formato de Transacción V1 que admite el sobre más grande y la estructura de transacción rediseñada.

¿Puede la Transacción V1 usar tablas de búsqueda de direcciones?

No. A diferencia de V0, V1 no admite tablas de búsqueda de direcciones. Incluye direcciones de cuenta directamente en la transacción, simplificando la ingesta de transacciones pero consumiendo más espacio serializado para cargas de trabajo intensivas en cuentas.
 
Descargo de responsabilidad: Este artículo tiene fines informativos únicamente y no constituye asesoramiento de inversión. Los activos cripto pueden ser altamente volátiles, y las condiciones del mercado, la liquidez de los tokens y los desarrollos del proyecto pueden cambiar rápidamente. Los lectores deben realizar su propia investigación y evaluar su tolerancia al riesgo antes de tomar decisiones financieras.

Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.