Home
The Auditable Accounting component is responsible of registering auditable logs. As such, this component is one of the main tools to enhance the trust in the ecosystem of data marketplaces. Our solution must enforce the Data Services Agreement (DSA) terms, agreed upon all involved parties, by recording them in an auditable, transparent, and immutable way. Smart Contracts are the key part of the proposed solution for auditable accounting. The auditable accounting component is an abstraction layer to access the Smart Contracts and to allow the integration with the rest of the platform. The auditable accounting component is a service which includes an API to automate the process of logging and auditing interactions between components and record the registries in the Blockchain.
-
Name : Auditable Log
Description : i3Market needs to be able to log data and events in blockchain. It is a key component for accounting, billing and conflict resolution. It is also important to control access to sensitive information, and to detect potential data breaches. A public distributed ledger will be used to store non-repudiable and reliable proofs of the required actions.
The solution must be scalable and cost-efficient. In this regard, transaction costs can be a considerable problem if, as it is expected, the number of auditable registries that need to be stored in the blockchain are high. To overcome this problem, it is a requirement to implement a transaction optimizer to efficiently register substantial amounts of data in the Blockchain without incurring in excessive costs. To achieve this, we first store registries in an internal database of the component, then aggregate the registries with a Merkle tree to minimize the number of Blockchain transactions and provide the appropriate data for proving each individual registry.
The Smart Contract managed by the auditable accounting component is used to store the necessary evidence of the aggregated registries from the DSA. Once the registration process is complete, the auditable accounting component will save a copy of all the information needed to verify that the registration was successful in the Blockchain. This information can be consulted and obtained later by the marketplace users. The auditable accounting component provides the functionality to trace registries and obtain “certificates” of them that can be publicly or privately used to prove that a certain registry was performed. Users must be able to download these certificates and validate the registry without further interaction with the auditable accounting component having a proof that can be universally validated without the intervention of any other entity or software component. The certificate of a DSA will provide: the Blockchain that has been used to create the auditable data registration, the address of the Smart Contract used, and the “proof of registry” of the associated data.
The auditable accounting component is a service which includes an API to automate the process of logging and auditing interactions between components and record the registries in the Blockchain. As shown in Figure 8: Auditable Accounting architecture, in general, the API of the AA module is accessed through the Backplane API Gateway. Additionally, the auditable accounting component can be accessed directly from any internal component of the platform.
On the other hand, to allow external parties to check that logs have been properly registered in the blockchain, interested parties need to obtain certain data from the distributed ledger as well as some off-chain data provided by the Auditable Accounting module via an API. This off-chain data are essentially Merkle proofs for each individual record. It is important that the off-chain data is provided with high availability. For this reason, the Auditable Accounting module uses the distributed storage component. In this way, high availability and data replication is provided to the relevant off-chain data required to store the registries and verify auditable logs.
The database model proposed for this component is based on two SQL tables. The first one is the related one with the blockchain. It contains the transactions prepared or sent to the blockchain.
It contains the following columns:
- Id: Primary key to link with the other table.
- Nonce: Nonce from the account to build the transaction
- Txhash: Hash of the transaction.
- Timestamp: Exact date of the creation of the transaction.
-
Registrationstate: Status of the transaction.
- Unregistered: Transaction not created.
- Pending: Transaction created but not sent to the blockchain.
- Mined: Transaction sent with less than 12 block confirmations.
- Confirmed: Transaction sent with more that 12 block confirmations.
On the other hand, the registry table is responsible to store the proofs of the data hashes that wants to be validated against the blockchain.
It contains the following columns:
- Id: Primary key to link with the other table.
- Dateofreception: Date when the data is received.
- Datahash: Cryptographic hash function of the data. It is one of the leafs of the Merkle Tree.
- Merkleroot: Root of the Merkle tree.
- Merkleproof: Concatenated hashes that allows to validate the datahash to the root of the tree.
- Readyforregistration: Boolean to indicate if the tree is built and ready to be deployed in the blockchain.
The smart contract deployed for this component just stores the root of the Merkle tree that summarizes all the data hashes stored in the database. It only allows to modify that value by the owner of the smart contract which shares the same account with the auditable accounting. Also, it includes the capability to subscribe to an event that notify you about a new root released. The Solidity code is the following:
