No puedo obtener mi transición de estado variable bytes32 dentro de una estructura en Quorum. Lo que hice fue construir un tablero para recorrer la cadena de bloques para buscar un particular y luego enumerar el número de bloque, desde, hasta, etc.
Aunque solo puedo obtener la entrada de transacción que cambió la variable de estado, no puedo obtener la transición de cambio de variable bytes32 en sí. Por ejemplo, NUEVO -> ENVIADO -> CERRADO
Leí en este foro muchos enfoques: usar eventos, agregar a otra matriz. Creo que todas estas son soluciones.
¿Hay alguna solución elegante para lograr esto dentro de Quorum? ¿Para rastrear el cambio de la variable de estado, en lugar de simplemente obtener la entrada de la transacción que cambió el estado de la variable? El linaje de datos es un atributo clave del libro mayor distribuido.
Gracias.
Quorum es una especialización de Ethereum. Mi respuesta y enfoque se aplica a ambas plataformas, ya que no toca asuntos exclusivos de Quorum como privateFor.
La forma en que se enmarca la pregunta sugiere algunas cuestiones conceptuales para aclarar. Comencemos con la fruta madura. El linaje de datos es un hecho en ambos casos. Estos son sistemas de solo agregar donde nada puede existir sin una cadena de transacciones (y entradas) firmadas por cuentas de propiedad externa.
Creo que es justo decir que los detalles son sobre quién/qué necesita información de linaje y con qué propósito. Como ha descrito, no es especialmente fácil para los desarrolladores hurgar en los datos sin procesar. Mi punto es que el linaje está ahí, como un hecho, desde una perspectiva de cadena de bloques. Lo que sea que construyamos estará dirigido a un usuario y propósito específico.
Sugeriría que posiblemente subestime la importancia de los registros. La palabra "Registro" puede sugerir algo informal y sin importancia, pero es una herramienta poderosa. Son más o menos análogas a las tablas con columnas específicas. Se pueden indexar. Se pueden buscar. Son almacenamiento inmutable de bajo costo. Nada puede entrar en el registro a menos que lo emita una función de contrato. Permiten a los clientes interesados "observar" y responder.
Un buen patrón y práctica de diseño predeterminado es emitir un evento para cada cambio de estado que ocurra en el contrato, de modo que sería teóricamente posible reconstruir completamente el historial de estado del contrato usando nada más que registros de eventos leídos en el orden correcto. Si hace eso, el linaje es un hecho, pero también conveniente y organizado en torno a una aplicación específica.
Otro buen hábito predeterminado es hacer que el estado actual sea completamente reconocible. Es decir, un cliente debería poder aprender cada detalle del estado actual sin tener que pasar por los registros para volver a ensamblar todo bloque por bloque.
Con ambos métodos implementados como una especie de procedimiento operativo estándar, el software del cliente tiene dos formas de consultar e incluso puede explorar cómo se vería el estado "actual" en un bloque anterior. Los registros de eventos brindan una forma inmutable y confiable de descubrir las transacciones que cambian de estado, quién las firmó, la carga útil de datos, etc. que hizo que el estado actual fuera como lo encontramos.
Hay una limitación. Los contratos no pueden (fácilmente) explorar registros, aunque he visto algunos trabajos experimentales con ensamblador que afirman hacerlo posible.
Esta limitación normalmente no es una preocupación porque los contratos en sí mismos suelen estar relacionados con el estado actual y lo que viene después. Rara vez necesitan explorar el pasado. Como he tratado de describir, al emitir eventos en los registros, la mayoría de los contratos han completado su tarea, lo que permite a cualquier cliente de software interesado explorar el pasado a su antojo.
Aquí hay algunas heurísticas a considerar.
Si la lógica del contrato depende de una parte de la información de estado, entonces el almacenamiento de registros es insuficiente. Los datos deben almacenarse en el estado del contrato.
La lógica del contrato se ocupa principalmente de considerar los cambios de estado propuestos, en el futuro. Comenzará a ver que cuando la lógica del contrato está involucrada, rara vez se trata del pasado.
No es que no pueda imaginar cómo organizar una estructura de linaje dentro del estado del contrato. Me imagino que no es necesario hacerlo para lograr todos los entregables. Probablemente sería innecesariamente complejo y costoso de operar. O bien, es un caso de uso muy raro.
Espero eso ayude.
Sr_Hmp