¿Katana TGE 31 de diciembre? Ayer en el sitio web de Kaito apareció información sobre el final de S1 para @katana el 31 de diciembre. Personalmente, no pude encontrar ninguna confirmación oficial del equipo, así que dudo que Kaito esté dando información precisa aquí, podría ser solo un error técnico. Porque más de una vez he escuchado sobre la "disponibilidad de transferencia del token $KAT" a más tardar el 20 de febrero de 2026, lo que probablemente apunta a finales de enero de 2026. Además, los anuncios oficiales importan, el tiempo de espera promedio para un TGE después de un anuncio oficial es de alrededor de 10 a 14 días, y nos quedan menos de 6 días sin ninguna noticia oficial en absoluto. El mercado y la Navidad también juegan su parte en retrasar un lanzamiento, en este momento la mayoría de las personas literalmente solo están descansando y pasando tiempo con la familia, y las condiciones del mercado hacen que las cosas sean aún más difíciles para un lanzamiento. Creo que esta es una señal falsa de Kaito, y el verdadero TGE del token $KAT no ocurrirá antes de mediados de enero, o incluso en febrero, tal como estaba planeado originalmente. Solía haber información en un documento oficial de desbloqueo, pero en este momento no pude encontrarlo, todo lo que encontré fue una entrevista en Reddit mencionando finales de febrero.

Tarifas de blobs en la actualización Fusaka. Parte 2 Sigo investigando sobre la actualización de Ethereum y sigo compartiéndolo contigo. cada L2 (por ejemplo @katana) en Ethereum pagó dos tipos de tarifas ◆ por blobs ◆ por ejecución (procesamiento de transacciones) antes de la actualización Fusaka había un punto débil en esta lógica. cuando la ejecución comienza a dominar (la red está muy cargada con el procesamiento de transacciones), la subasta de blobs podría caer a 1 wei, lo que lo hacía básicamente gratis. eso significa que bajo carga de red, L2 podría evitar pagar por blobs y seguir poniendo aún más carga en la red. la actualización EIP-7918 soluciona este problema y establece un precio de reserva proporcional para cada blob. lo que significa que el algoritmo introduce literalmente un costo mínimo para cada blob que refleja lo que se necesita para procesarlo. además de este costo mínimo, el algoritmo también considera las condiciones del gas de ejecución y el número de blobs que se están publicando; cuanto más altos sean estos métricas, mayor será el costo para la ejecución y el procesamiento de blobs.

Ethereum estaba muriendo antes de la actualización Fusaka. Parte 1 durante mi tiempo alejado de web3, Ethereum lanzó una actualización importante para sí mismo, Fusaka, que afecta a gran parte de la mecánica interna del proyecto. los usuarios apenas sentirán alguna diferencia antes y después de esta actualización (excepto por tarifas más bajas), pero juega un papel clave en la escalabilidad de ETH. iré cubriendo gradualmente cada bloque de esta actualización para que cualquiera pueda leer las publicaciones en 5 minutos y entender fácilmente por qué se introdujo esta actualización. antes de sumergirnos en el lado técnico, necesitas entender cómo funciona Ethereum estructuralmente. volvamos a 2021. después del mercado alcista en 2021, cuando las tarifas de gas de ETH podían alcanzar $500 $800 solo para acuñar un NFT, muchos usuarios comenzaron a buscar redes alternativas con tarifas más bajas. alrededor de ese tiempo, comenzaron a surgir soluciones L2, ofreciendo tarifas bajas, transacciones rápidas y seguridad al nivel de Ethereum. la seguridad de Ethereum era una de las principales ventajas de estas soluciones, sin ella, L2 nunca habría alcanzado este nivel de adopción. lograron esto enviando datos a la cadena principal para verificar transacciones. saltemos a 2025. L2 se volvió masivamente popular y literalmente todos las usan para transacciones, ya que son rápidas, seguras y baratas. por ejemplo, @katana fue creado para resolver problemas de fragmentación en ETH. pero apareció un problema que podría empujar a ETH hacia la centralización. cada día, todos los L2 existentes envían una gran cantidad de datos en forma de blobs a Ethereum para su verificación. todos los nodos tenían que descargar cada blob para verificar todas las transacciones, cuanto mayor era el rendimiento, más datos tenían que descargar. esto creó problemas de hardware para los nodos, descargar y procesar grandes cantidades de datos requería equipos potentes. lo cual no todos podían permitirse y con el tiempo esto aumentaría los requisitos de hardware para los nodos y reduciría la descentralización (lo cual no era aceptable). PeerDAS (la actualización Fusaka) resuelve esto utilizando muestreo de disponibilidad de datos. cada nodo solo descargará y verificará 1/8 de los datos del blob. ahora los nodos no necesitan descargar el conjunto completo de datos, solo 1/8 del volumen total. en términos simples, después de que los datos de L2 se envían a Ethereum, el blob se divide en muchos pequeños trozos y se distribuye aleatoriamente para que los nodos los descarguen. lo que en teoría permite que la escalabilidad aumente hasta 8 veces mientras se mantienen bajos los requisitos para los nodos (se resuelven los problemas de hardware y descentralización). los usuarios notarán principalmente tarifas más bajas en las redes L2. otro cambio relacionado con los blobs, antes de aumentar el número de blobs requeridos esperando una actualización importante (como Fusaka), ahora se introdujo un mecanismo para aumentar los blobs sin esperar un ciclo completo de actualización. los clientes pueden acordar aumentar los blobs (similar a cómo funciona el límite de gas), después de eso, los operadores de nodos actualizan su cliente y este proceso se vuelve mucho más rápido que antes.