Simulación de Transacciones

Huella

Como se menciona en la sección de persistir datos, un contrato solo puede cargar o almacenar entradas CONTRACT_DATA que se declaran en una huella asociada con su invocación.

Una huella es un conjunto de claves de ledger, cada una marcada como de solo lectura o de lectura y escritura. Las claves de solo lectura están disponibles para la transacción para leer; las claves de lectura y escritura están disponibles para leer, escribir o ambos.

Cualquier transacción de Soroban enviada por un usuario debe ir acompañada de esta huella. Una única huella abarca todos los datos leídos y escritos por todos los contratos invocados transitivamente por la transacción: no solo el contrato inicial que llama la transacción, sino también todos los contratos que llama, y así sucesivamente.

Dado que puede ser difícil para un usuario saber qué entradas de ledger intentará leer o escribir una determinada llamada de contrato (especialmente las entradas que son causadas por otros contratos dentro de una transacción), el host proporciona un mecanismo auxiliar simulateTransaction que ejecuta una transacción contra un snapshot temporal, posiblemente desactualizado, del ledger. El mecanismo simulateTransaction no está limitado a solo leer o escribir el contenido de una huella; más bien registra una huella que describe la ejecución de la transacción, descarta los efectos de la ejecución y luego devuelve la huella grabada a su llamador.

Esta huella proporcionada por la simulación puede luego ser utilizada para acompañar una presentación "real" de la misma transacción a la red para una ejecución real. Si el estado del ledger ha cambiado demasiado entre el momento de la simulación y la presentación real, la huella puede estar demasiado desactualizada y ya no identificar con precisión las claves que la transacción necesita leer y/o escribir, en cuyo caso la simulación debe ser reintentada para actualizar la huella.

En cualquier caso (ya sea exitoso o fallido), la transacción real se ejecutará atómicamente, de manera determinista y con semántica de consistencia serializable. Una huella inexacta simplemente provoca un fallo determinista de la transacción, no un error de lectura desactualizada. Todos los efectos de una transacción fallida son descartados, como sucedería ante cualquier otro error.

Autorización

Consulta la documentación de visión general de la autorización y la autorización en transacciones sección para información general sobre la autorización de Soroban.

El mecanismo simulateTransaction de Soroban también puede ser utilizado para computar los árboles de SorobanAuthorizedInvocation que deben ser autorizados por las Address para que todos los chequeos de require_auth pasen.

El host de Soroban proporciona un modo especial de 'grabación' para la autenticación. Cada vez que se llama a require_auth, el host registra su contexto (dirección, id de contrato, función, argumentos), lo atribuye a un árbol de SorobanAuthorizedInvocation y lo marca como exitoso. Luego, después de que la invocación ha finalizado, simulateTransaction puede devolver todos los árboles registrados, así como los valores aleatorios de nonce generados.

Dada esta información de la simulación, el cliente solo necesita proporcionar estos árboles y nonces a las respectivas Address para que firmen y luego construir la transacción final utilizando la salida de la simulación y las firmas correspondientes.

El modo de autenticación de grabación es opcional para simulateTransaction. Por ejemplo, al tratar con contratos de cuentas personalizados, puede ser necesario simular el código __check_auth de la cuenta personalizada (que se omite simplemente en el modo de grabación), por ejemplo, para obtener su huella en el ledger. El modo sin grabación se denomina 'ejecutar'. El modo de ejecución es básicamente equivalente a ejecutar la transacción en on-chain (con un estado de ledger posiblemente ligeramente desactualizado); por lo tanto, requiere que todas las firmas sean válidas.

Ten en cuenta que el modo de autenticación de grabación nunca simula fallos de autorización. La razón de esto es que el fallo de autorización es siempre una situación excepcional (es decir, las Address para las cuales no anticipas una autorización exitosa no deberían usarse en primer lugar). Es similar a cómo, por ejemplo, el mecanismo simulateTransaction no simula fallos causados por una huella incorrecta. simulateTransaction con modo de autenticación de ejecución aún puede ser usado para verificar las firmas antes de ejecutar la transacción en on-chain.