Las cross-contract calls en NEAR Protocol permiten que un contrato inteligente llame a métodos de otro contrato, abriendo la puerta a la escalabilidad, los patrones de diseño y la comunicación asíncrona. Si estás construyendo sobre NEAR, entender este mecanismo te ayuda a diseñar aplicaciones más robustas, modulares y eficientes en gas.

¿Qué es una cross-contract call en NEAR?

Una cross-contract call (XCC) es, en esencia, llamar al método de un contrato desde otro contrato. Suena simple, pero las implicaciones son enormes [2:18].

Imagina un contrato A con un método A que invoca un método B en otro contrato. Cuando termina la ejecución, se dispara un callback hacia el contrato A para saber qué pasó. Ese flujo, aparentemente sencillo, es el que habilita arquitecturas modulares en la blockchain.

¿Qué es una cross-contract call? Es una llamada asíncrona donde un contrato inteligente ejecuta un método de otro contrato y recibe la respuesta mediante un callback.

¿Cómo se determina el éxito de una transacción entre contratos?

El estado de la transacción depende del primer método llamado. Si tu método A logra invocar al método B, la transacción se considera exitosa, aunque el método B falle internamente [4:30].

Por eso necesitas programar un callback que monitoree la respuesta. Sin ese seguimiento, tu contrato no sabrá si debe revertir cambios, registrar errores o continuar con la siguiente operación.

¿Cómo se manejan el gas y los tokens en una cross-contract call?

Los métodos llamados por XCC deben llevar gas adjunto. El gas es el costo del procesamiento que requiere la transacción para completarse [6:10].

Si tu método A es ligero pero llama a un contrato B que es complejo, debes enviar suficiente gas desde el origen para cubrir todo el flujo. Por defecto, una transacción en NEAR lleva 30 teragas, y cualquier sobrante se devuelve a la cuenta que firmó.

• Cada transacción reserva una porción de gas para su propia ejecución.
• El gas no consumido se transfiere de vuelta automáticamente.
• Si un método es payable, debes adjuntar tokens al llamarlo.
• Si no le cobras tokens al usuario, el contrato los pagará de su propio balance.

Esa última parte es clave: cuando diseñas un contrato que ejecuta XCC, cobra al usuario el gas y los tokens necesarios antes de iniciar la transacción. De lo contrario, tu contrato termina financiando las llamadas.

¿Cómo se programa una promise en NEAR con JavaScript?

En el SDK de JavaScript, todo arranca creando una promise. Es el equivalente a una acción asíncrona que la blockchain ejecutará después [13:20].

El flujo básico para transferir un NEAR desde un método se ve así:

1. Crear la promesa con near.promiseBatchCreate(accountId).
2. Adjuntar la acción con near.promiseBatchActionTransfer(promise, amount).
3. Envolver el monto en un BigInt porque los valores en yoctoNEAR son demasiado grandes para enteros normales de JavaScript.

¿Qué es una promise en NEAR? Es una acción asíncrona que un contrato programa para ejecutarse, ya sea transferir tokens, llamar a otro contrato o crear una cuenta.

En Rust el flujo es más compacto: puedes encadenar acciones sobre la misma promesa en una sola línea. En JavaScript trabajas paso a paso, pero la lógica es idéntica.

¿Qué muestra el explorador de NEAR sobre una transacción?

Al ejecutar una llamada con near call, el explorador te entrega una radiografía completa: cuenta firmante, receptor, estado, gas consumido y devoluciones [21:00].

En el ejemplo de la clase, una transacción cobró 0.00118 NEAR y consumió 12 teragas de los 30 enviados. Los 18 teragas restantes regresaron a la cuenta. Además, se observa la transferencia de 1 NEAR al firmante y un reembolso de 0.00305 NEAR por gas sobrante.

Toda la información en el explorador es pública. Cualquier persona puede ver cada transacción de la historia de la blockchain, así que evita guardar datos privados en contratos.

¿Para qué sirven las cross-contract calls más allá de transferir tokens?

El uso más potente está en la escalabilidad. Cuando un contrato inteligente necesita evolucionar, agregar campos nuevos a sus objetos almacenados puede romper la serialización [29:40].

Tienes tres caminos para resolverlo:

• Upgradable contracts: programar funciones que detecten el formato viejo y lo migren al nuevo en tiempo real.
• Migración masiva de datos a un contrato nuevo, costosa cuando hay mucho histórico.
• Crear un contrato nuevo y usar el original como puente que invoque los métodos del nuevo mediante XCC.

La tercera opción es la más eficiente en almacenamiento porque no reescribes nada en la blockchain.

¿Qué patrones de diseño usan cross-contract calls?

Tres patrones destacan en el ecosistema NEAR [33:10]:

• Factory pattern: un contrato genera otros contratos consistentes entre sí. Lo usan Mint Museum, NEAR Staking Pool y Sputnik DAO para crear DAOs.
• Link drop: un contrato guarda un activo (token o NFT) y entrega una llave para reclamarlo después. Útil para premios y airdrops.
• Multisignature: un contrato exige que múltiples cuentas firmen antes de ejecutar una transacción. Es la base de cómo las DAOs aprueban movimientos de fondos.

¿Cómo afecta el sharding a las cross-contract calls en NEAR?

NEAR usa un algoritmo de sharding llamado Nightshade que divide la blockchain en partes para procesar transacciones en paralelo cuando la red se satura [40:15].

El problema aparece cuando dos cuentas viven en shards distintos. Si tú estás en un shard y quieres mandar tokens a alguien en otro, técnicamente están en blockchains separadas en ese instante.

¿Cómo resuelve NEAR las transacciones entre shards distintos? De forma asíncrona: en cuanto el shard origen valida que la transacción es correcta, el shard destino empieza a procesar su parte sin esperar a que la primera termine completamente.

La clave está en la asincronía. Una ejecución síncrona obligaría a esperar que el primer shard termine antes de iniciar el segundo. Con asincronía, ambos avanzan en paralelo apenas se valida la operación, ahorrando tiempo sin comprometer la integridad.

Diseñar contratos pensando en este modelo te obliga a manejar callbacks y estados intermedios con cuidado, pero es lo que hace que NEAR escale sin sacrificar velocidad. ¿Ya estás pensando en qué patrón aplicar a tu próximo proyecto? Cuéntanos en los comentarios cómo planeas usar las XCC.