Estructura del contrato para almacenar la aplicación del usuario

Tengo una aplicación Nodejs en la que los usuarios completan varios formularios y esos datos se guardan en la base de datos centralizada, es decir, MongoDB. El administrador puede revisar los datos del usuario y puede enviar los datos del usuario a Blockchain para mantener la integridad de los datos para que cualquier tercero pueda ver los datos en el futuro y verificar su integridad.

Ahora, como los datos son grandes, no se pueden almacenar directamente en la cadena de bloques. Entonces, estoy convirtiendo los datos primero a pdf y luego creando el hash de pdf usando el algoritmo Keccack 256 y almacenando el hash en el contrato. Y a cambio, obtengo una identificación de transacción que luego puedo usar para recuperar los datos de la cadena de bloques.

Sugiera si estoy en el camino correcto o si hay un mejor enfoque para esto.

Nota: - Si un usuario actualiza su aplicación, el administrador volverá a enviar los datos del usuario a la cadena de bloques.

Este es el código de contrato que estoy usando:

pragma solidity ^0.4.17;
contract AddUserApplication {
    string public userdata;
    function addUserData(string data) public {
        userdata = data;
    }
}

// Código para recuperar los datos de Block:

    const viewTransaction = async () => {
    let viewData = await web3.eth.getTransaction('0xd819b09a906232a37b6ad102a7616eed6af9d968718b23878e023ccf7f967f8');
    console.log('viewdata: ',viewData.input);
    const decodedData = abiDecoder.decodeMethod(viewData.input);
    console.log('decodedData',decodedData);
}

Respuestas (1)

Entonces, estoy convirtiendo los datos primero a pdf y luego creando el hash de pdf usando el algoritmo Keccack 256 y almacenando el hash en el contrato

¿Por qué no simplemente tomar la salida del documento mongodb (JSON) y hacer un hash en su lugar? La introducción de PDF en el medio parece innecesaria, y las conversiones de PDF tienden a ser bastante irregulares entre convertidores. Sería bastante fácil terminar con diferentes archivos PDF para los mismos datos y, por lo tanto, diferentes hashes.

Y a cambio, obtengo una identificación de transacción que luego puedo usar para recuperar los datos de la cadena de bloques.

El ID de la transacción por sí solo tiene poco que ver con poder recuperar los datos. Simplemente lo ayudará a determinar si pudo incluirlo con éxito en la cadena. Además, nunca podrá recuperar los datos originales de la cadena si todo lo que está confirmando es un hash de los datos.

Su contrato también solo admite una sola cadena. Una mejor idea sería tener un mapeo uint -> bytes32 y confirmar un hash para un ID de usuario, que luego puede leer más tarde usando el ID de usuario.

Hola Raghav, actualicé la pregunta con el método que estoy usando para recuperar los datos del bloque. Y también puedo obtener los datos antiguos con la ayuda de la identificación de la transacción. ¿Puedes explicar por qué está mal?