Escalabilidad en NEAR: Llamadas Entre Contratos y Sharding

Las llamadas entre contratos en NEAR permiten escalar funcionalidades sin reescribir datos ni frenar el desarrollo. Aquí entenderás cómo funcionan las cross contract calls, cómo adjuntar gas y tokens, por qué necesitas un callback, y qué patrones reales habilitan esta técnica junto con el sharding de Nightshade.

¿Qué es una cross contract call en NEAR y por qué importa?

Una cross contract call (XCC) es llamar al método de un contrato desde otro contrato. Aunque suene simple, sus implicaciones son grandes: habilita asincronía, escalabilidad y composición de contratos.

• Ejecución y estado. El “primer método” llamado determina el estado de la transacción. Aunque el método del contrato B falle, si el método A logró invocar la llamada, la transacción se considera exitosa. Por eso es clave programar un callback que verifique el resultado y actúe en consecuencia.
• Asincronía con callback. Como la llamada es asíncrona, necesitas un método que reciba la respuesta: si fue exitosa, si falló y cómo reaccionar.
• Visibilidad pública. Todo queda registrado en el explorer de la testnet: transacciones, costos, parámetros y recibos. La blockchain es pública y auditable.

Claves prácticas que se muestran en el análisis de transacciones: - Comisión total observada: 0.001118 NIR. - Gas enviado a la transacción por defecto: 30 teragás. - Gas consumido en el ejemplo: 12 teragás y reembolso de 18 teragás. - Costos de recibos: 223 gigagás indicados para crear y ejecutar recibos.

¿Cómo se adjuntan gas y tokens en llamadas entre contratos?

Toda XCC debe llevar gas adjunto. Además, si el método del contrato destino es payable, hay que adjuntar tokens.

• Gas adjunto. El gas paga el procesamiento. Si el método destino requiere más cómputo, adjunta gas adicional desde el contrato origen.
• Reembolso automático. El gas y los tokens no usados se reembolsan al final de la transacción. En el ejemplo: se enviaron 30 teragás, se usaron 12 y se reembolsaron 18; también se observaron transferencias de sobrantes al firmante.
• Métodos payable. Si el usuario no adjunta tokens y el método los requiere, el contrato puede pagarlos desde su propia cuenta, pero conviene cobrarlos al usuario antes de abrir la transacción.
• Paralelo con la API de JavaScript. Al invocar métodos desde frontend, también adjuntas gas y tokens; la lógica en el contrato replica este patrón.
• Ciclo de construcción y despliegue. Flujo recordado: construir a WASM y desplegar con near dev deploy para una cuenta dev nueva en testnet.

¿Cómo funciona el reembolso de gas?

• Toda transacción envía gas inicial (típicamente 30 teragás).
• Si sobra gas o tokens, el sistema los transfiere de vuelta al final. Esto aparece desglosado en el explorer por recibos y acciones.

¿Qué pasa con métodos payable sin tokens del usuario?

• El contrato puede cubrirlos, pero asume el costo. Lo recomendable: cobrar al usuario al inicio si el método destino es payable.

¿Cómo programar una transferencia con Promise en JavaScript?

En el SDK de JavaScript, se crea una Promise para la cuenta objetivo y luego se adjunta la acción de transferencia. Se usa BigInt para representar cantidades en yoctoNEAR.

// Crear la promesa para quien firmó la transacción
const p = Near.promiseBatchCreate(context.predecessor);

// Transferir 1 NEAR (en yoctoNEAR) usando BigInt
Near.promiseBatchActionTransfer(p, BigInt("1000000000000000000000000"));

// Nota: la llamada es asíncrona. Programa un callback para manejar el resultado.

Puntos a recordar: - Usa yoctoNEAR para precisión en montos. - Adjunta gas suficiente según la complejidad del método destino. - Implementa el callback para validar éxito o fallo y tomar acciones.

¿Qué patrones y escalabilidad habilitan las XCC?

Las XCC son base para crecer sin migraciones costosas y para componer contratos especializados.

• Escalabilidad sin reescritura. Cuando cambian los requisitos (por ejemplo, nuevos campos en objetos), en lugar de migrar todo el estado, puedes crear un contrato nuevo y hacer que el contrato original lo invoque vía XCC. Así evitas reescribir datos y mantienes compatibilidad.
• Sharding con Nightshade. Si cuentas están en distintos shards, la red ejecuta validaciones y partes de la transacción de forma asíncrona: en cuanto se confirma que la primera parte es válida, se continúa del otro lado. Esto reduce esperas incluso si, temporalmente, operan como “dos blockchains”.

¿Qué patrones prácticos puedo aplicar con XCC?

• Factory pattern. Un contrato crea otros contratos manteniendo consistencia en su interfaz. Ejemplos mencionados: Meme Museum, staking pool de NEAR y Sputnik DAO/AstroDAO.
• Lindrooks. Contratos que “guardan” valor (p. ej., un NFT) para que luego pueda reclamarse con una llave específica.
• Multisig. Contratos que requieren varias firmas antes de ejecutar una acción. Caso típico: DAOs con consejos que aprueban transferencias.

Palabras clave y habilidades desarrolladas: - cross contract calls (XCC), callback, asincronía, gas adjunto, payable, reembolso, yoctoNEAR, BigInt, near dev deploy, WASM, testnet explorer, sharding, Nightshade, factory pattern, multisig, DAO.

¿Tienes dudas sobre gas, callbacks o patrones con XCC en NEAR? Cuéntanos tu caso y qué método quieres integrar: con gusto lo revisamos y te orientamos en los siguientes encuentros.