El lanzamiento de go-algorand 3.15 presenta un nuevo modo de interacción para Algorand: simular. Simulate permite que un nodo evalúe las transacciones sin alterar el estado de la cadena de bloques.
Simulate tiene una gran variedad de usos, incluido el acceso de lectura gratuito al estado del contrato, pruebas eficientes y una depuración más sencilla.
Simulate es un nuevo punto final que refleja el punto final de envío de transacciones. Se puede llamar utilizando exactamente el mismo formato en cualquier red, incluida Mainnet.
Simulate evalúa el grupo de transacciones enviado utilizando el estado actual de la red. La respuesta de Simulate incluirá:
tendría éxito: un valor booleano que indica si el grupo de transacciones es válido.mensaje de error: si el grupo de transacciones no es válido, simular devuelve el error.faltan firmas: simular completará la evaluación incluso si faltan firmas en el grupo de transacciones. Este campo indicará si falta alguna firma.txn-resultados: simular devolverá información parcial sobre los efectos que este grupo de transacciones habría tenido en el estado de la cadena de bloques: cualquier nuevo activo o aplicación creada, cambios de estado globales/locales, etc. En versiones futuras de simular, esto también incluirá explícitamente cambios en los saldos de Algo y estados de caja.
Si la evaluación se encontró con un error, simular devolverá la información parcial para ayudar a los esfuerzos de depuración: cualquier cambio que ya se calculó hasta el momento en que falló la evaluación.
Imagine que desea conocer el estado de un contrato inteligente (global, local o box state).
Por ejemplo, eres parte de una DAO y quieres saber si alice.algo ya votó sobre la última propuesta. ¿Cómo puedes averiguarlo?
El contrato inteligente de votación almacenará la información de votación en el estado local de alice.algo. Usando la API para algod o para un indexador, puede obtener los datos del estado local. Sin embargo, es probable que los datos no sean muy útiles para usted: se codificarán de la forma en que los organice el contrato inteligente, por lo que será un galimatías.
Puede leer el contrato inteligente para comprender la codificación, lo que permite decodificar el estado de votación de Alice. Aunque, ¿puedes leer contratos inteligentes en cadena?
En lugar de intentar leer el código del contrato inteligente, ¿por qué el contrato inteligente no puede simplemente decirnos la respuesta, ya que sabe cómo decodificar sus propios datos? Podría tener un método did_they_vote(cuenta)bool que devuelve un valor booleano que representa el estado de votación de la cuenta. Eso lo hace fácil: simplemente emita una transacción para llamar a ese método para obtener su respuesta. Desafortunadamente, llamar a la aplicación cuesta una tarifa de red, a diferencia de la solución de lectura y decodificación.
Simulate nos ofrece lo mejor de ambos mundos. Puedes llamar hicieron_ellos_votaron(alice.algo) usando simulación, que le dará la respuesta sin cobrar una tarifa de red.
Un ejemplo más complejo, en el que el contrato inteligente no solo decodifica su estado para usted, sino que también realiza algunos cálculos, llama a simular en get_current_slippage(trade_size, par) a un AMM.
Otro uso esperado es ejecutar una transacción usando simulación justo antes de enviarla a la red. Esto le permite verificar que la transacción resultó en los cambios esperados en la cadena de bloques. Sin embargo, hay una sutileza importante que debe tener en cuenta: el estado podría cambiar entre el momento en que llama a la simulación y el momento en que la red acepta su transacción.
Hay muchas formas de probar los contratos inteligentes de Algorand. Uno de los más comunes es activar una red local, emitir transacciones para configurar un estado de cadena de bloques conocido para la prueba, llamar a la aplicación y luego confirmar el estado resultante. Esta es una prueba poderosa que es bastante fiel a cómo se comportaría la aplicación en Mainnet, pero es pesada. Puede tomar tiempo (demasiado tiempo) escribir y ejecutar cada prueba, lo que hace que algunos desarrolladores escriban y ejecuten menos pruebas de lo que lo harían de otra manera.
Quizás la parte más lenta de esta prueba es configurar el estado para la prueba. Esta configuración de estado puede consistir en: crear y financiar cuentas, crear activos, habilitar cuentas en los activos, implementar aplicaciones, habilitar cuentas en las aplicaciones y realizar una serie de llamadas iniciales de aplicaciones para configurar estados globales y locales. Todo esto antes de que se realice la llamada de la aplicación de prueba única real y se pueda verificar el estado resultante.
Ejecutar la siguiente prueba requiere restablecer la red local a cero y comenzar de nuevo, repitiendo todo el proceso de configuración de estado.
¿Cómo nos ayuda la simulación con este proceso de prueba costoso e ineficiente? Simulate le permite ejecutar varias pruebas contra el mismo estado. Después de configurar el estado, en lugar de realizar la llamada a la aplicación, alterando así el estado y necesitando restablecerlo para realizar más pruebas, puede usar simular para ver qué sucedería si se enviara la llamada a la aplicación. Por lo tanto, puede ejecutar muchas pruebas contra el mismo estado, llamando a diferentes métodos de contrato, con muchos argumentos diferentes, incluso pruebas de fuzz. También obtendrá una salida más rica de la simulación que la que obtendría de una ejecución normal, por lo que puede ejecutar aserciones de prueba específicas de dapp más detalladas.
Por ejemplo, imagine que María está ejecutando un dapp de subastas y quiere probarlo. María configura su estado de cadena de bloques para que la subasta esté en curso. Luego, la prueba de María ejecuta varias llamadas de simulación:
Una llamada que puja por el artículo en subasta con un precio por encima de la puja anterior más el incremento mínimo de puja (buen camino, debería tener éxito). Una llamada que puja por el artículo con un precio por encima de la puja anterior pero no superior a la puja anterior más el incremento de oferta mínimo (debería fallar). Una llamada que puja por el artículo con un precio inferior al de la oferta anterior (debería fallar). Una llamada que intenta reclamar el artículo (aunque la subasta aún esté en curso, por lo que debería fallar).
Estos son solo algunos ejemplos. Un desarrollador minucioso probablemente incluiría muchos más casos, pero es de esperar que demuestre cómo las pruebas ahora se pueden ejecutar de manera más eficiente.
Como dice John Clarke de Algofi, “Simulate mejorará drásticamente la eficiencia del… desarrollo, permitiendo que se construyan suites de prueba más sólidas para los contratos inteligentes de AVM”.
Como comentó una vez un colaborador externo de github, “la depuración siempre es urgente”. De hecho, la depuración está en el centro del flujo de trabajo de cada desarrollador (a veces escucho de programadores míticos que escriben código perfecto en el primer intento, pero no creo en los cuentos de hadas). La depuración de contratos inteligentes de Algorand ha sido, seamos honestos, una experiencia mediocre hasta ahora. Es hora de mejorar: simular es el primer paso y la clave.
Antes de la simulación, una herramienta central utilizada para la depuración era “ejecución en seco”. En la superficie, dryrun parece similar a simular: evaluará su programa sin comprometer nada con la cadena de bloques.
Sin embargo, dryrun está construido con una arquitectura diferente que lo limita severamente. Dryrun no utiliza el libro mayor real de la cadena de bloques, ni el evaluador de bloques real. Utiliza una versión delgada de la lógica de evaluación contra el estado externo pasado a través del punto final.
Dryrun funciona bien para evaluar una sola llamada de aplicación, pero no puede evaluar correctamente un grupo de transacciones. No puede actualizar el estado de una transacción a la siguiente en el grupo de transacciones, ya que solo usa el estado pasado tal cual.
La mayoría de las dapps usan grupos de transacciones, por lo que esta limitación es bastante problemática. Simulate resuelve la situación manejando transacciones individualmente o como transacciones grupales. Al evaluar un grupo de transacciones, Simular realiza un seguimiento adecuado de los cambios de estado de una transacción a la siguiente en el grupo.
Otra limitación de la arquitectura de dryrun es que debe actualizarse cada vez que hay una actualización de AVM. Dryrun quedó obsoleto cuando se introdujeron las transacciones internas, y nuevamente con las llamadas de contrato a contrato, y nuevamente cuando se agregaron cajas. Simulate, construido junto con la propia lógica de evaluación, nunca requerirá dicho mantenimiento y no debería quedar obsoleto.
Simulate sienta las bases para una gran cantidad de funciones útiles. Ahora que la arquitectura central está en su lugar, el campo está abierto a sugerencias sobre lo que será más útil para la comunidad de desarrolladores. Aquí hay algunas características que esperamos agregar en un futuro cercano:
Permita que la simulación se ejecute sin limitaciones de registro. Informe el presupuesto del código de operación utilizado por la aplicación y por la firma inteligente. Informe el crédito de la tarifa (suponiendo que no haya congestión, cuántas tarifas en exceso se usaron para este grupo de transacciones). Informe el seguimiento de la ejecución: para cada paso de la evaluación , detalla la pila, las ranuras temporales, los cambios en el estado local/global/de la caja, etc. Informe de los recursos externos utilizados. Permita que la simulación se ejecute sin ningún límite de recursos externos (sin verificar las matrices externas). Use diferentes parámetros sugeridos en una ejecución de simulación.
¡Buscamos tus sugerencias! Contáctenos en github o discord (algoanne#5743), como de costumbre.
Los proveedores de API destacados del ecosistema, Algonode y Purestake, tendrán el punto final de simulación disponible para su uso poco después del lanzamiento.
Para obtener detalles técnicos sobre cómo usar simular, consulte nuestro artículo de descripción técnica.
