Estoy creando un proyecto en el que necesito usar mi contrato inteligente para agregar datos al almacenamiento, pero de manera programáticamente retrasada:
Estoy usando web3 en mi servidor nodejs, y quiero crear la transacción como de costumbre, usando web3 pero retrasando o deteniendo la transmisión de la transacción hasta que quiera enviarla.
Mi idea es obtener la transacción sin procesar y guardarla en una base de datos fuera de la cadena como la cadena que es. luego, cuando quiero transmitir la transacción, puedo obtenerla de la base de datos y usar web3 para enviarla como una transacción sin procesar.
Entonces, primero quiero saber si mi idea es factible y, de todos modos, puedo guardar transacciones dentro de mi nodo y luego enviarlas programáticamente porque la idea de guardar transacciones en bases de datos relacionales no es realmente atractiva y parece insegura.
Ethereum no admite la función de "retraso de transacción" que está describiendo.
Pero ...
Es una mala idea firmar transacciones y dejarlas (en formato sin formato) fuera de la cadena esperando su envío. Porque una transacción incluye nonceun campo, que es un número consecutivo que pertenece a su cuenta. Es por eso que su primera transacción bloqueará todas las siguientes transacciones. Deberá almacenar las transacciones pendientes sin firmarlas, y solo cuando realmente necesite ejecutarlas, las firmará y las enviará a la cadena de bloques.
Las transacciones sin procesar son perfectamente seguras para almacenarse en cualquier lugar, de hecho, están almacenadas en la base de datos de blockchain en este momento y todos tienen acceso a ellas, es información pública.
rawsignifica que ya están firmadosLo que describes es factible. Haría que los clientes de software formaran transacciones, firmaran y luego su servidor registraría sus acciones firmadas en su base de datos para su posible envío a la red en un momento posterior.
Se me ocurre que tendrá algunas consideraciones adicionales a nivel de la aplicación. Por ejemplo, es probable que los usuarios se resistan a la idea a menos que las cosas estén dispuestas con tiempos de vencimiento definidos en la línea de "bueno hasta el número de bloque n". Ese vencimiento probablemente debería aplicarse a nivel de contrato inteligente para limitar severamente lo que puede hacer el servidor privilegiado.
No habrá un problema de doble gasto, pero ciertamente existe la posibilidad de que se extienda demasiado, en cuyo caso las transacciones fallarán.
Eche un vistazo al protocolo 0x para ver algo que funcione de esta manera.
mikko ohtamaa
kaki maestro del tiempo