Todas las discusiones sobre esto mencionan que es imposible obtener un valor devuelto de sendTransaction() ejecutado en una función de contrato, donde se cambia el estado del contrato. No entiendo por qué el valor devuelto no se puede registrar en el registro de transacciones en la cadena de bloques, de manera similar a los eventos, y luego se puede recuperar en la confirmación de la transacción:
web3.eth.sendTransaction(...) .on('confirmation', function(1, receipt){ ... // retrieving value returned by smart contract function here })Los registros se realizan para describir los eventos emitidos desde el contrato, que es la solución actual para obtener datos de las transacciones, por lo que los datos de retorno no pueden entrar allí.
Sin embargo, la inclusión de return_data en el recibo ha sido discutida y aparentemente olvidada. EIP758 , tiene la siguiente solución :
EIP 658 originalmente propuso agregar datos de devolución a los recibos de transacciones. Sin embargo, los datos devueltos no se cobran (ya que no se almacenan en la cadena de bloques), por lo que agregarlos a los recibos de transacciones podría generar DoS y oportunidades de spam. En su lugar, se agregó un campo de
statusbooleano simple a los recibos de transacciones. Esta versión modificada de EIP 658 se incluyó en la bifurcación dura de Byzantium. Si bien el campo destatuses útil, las aplicaciones a menudo también necesitan los datos de devolución.
La principal ventaja de usar la estrategia descrita aquí es la eficiencia: no es necesario almacenar datos adicionales en la cadena de bloques y se impone una carga computacional adicional mínima en los nodos. Dado que los clientes ligeros tienen el estado actual, pueden calcular y enviar notificaciones de devolución de datos sin ponerse en contacto con un servidor. Aunque no se admitirían búsquedas posteriores del valor de retorno, esto es coherente con el uso convencional de los datos de retorno, a los que solo puede acceder la persona que llama cuando la función regresa, y no se almacenan para su uso posterior.
Y esta solicitud de extracción del cliente go , que no se llevó a cabo porque la mejor solución sería, en cambio, una bifurcación dura de Ethereum, a pesar de que teníamos algunos desde entonces y no sucedió.