A draft proposal for using hashing of Omni Protocol balances for testing and validation.
This is a preliminary proposal for using hashing of Omni Protocol consensus information to produce several types of hashes that can be used for Omni Protocol consensus checking.
The Omni project has historically used "Consensus Checking" as a method of validating the correctness of Omni Protocol implementations. Checking consensus for a Omni Protocol currency (such as OMNI, TOMNI, or any user currency) means asking two or more implementations of the Omni Protocol to generate a list of every address that contains a balance in that currency and the balance amount. To check for valid consensus the total balance and the reserved balance at each address containing that currency are compared.
One problem with this method of validation is that it is becoming less useful as we focus our efforts on the Omni Core reference implementation. When a new feature that could affect address balances is added to the reference implementation it is not possible to consensus check against a second implementation until the new feature is added to the second implementation.
A second problem with consensus checking is that a valid comparison requires that both implementations return consensus data for the same block height. If an implementation can only return a consensus snapshot for the current block height and one implementation is lagging behind another in parsing transaction data, then an accurate comparison is not possible unless consensus data from the more up-to-date implementation is saved until the second implementation catches up.
Although it would be possible to save consensus data for each new block as it is processed by an implementation, the amount of storage required quickly becomes prohibited.
It is for these reasons that we propose using a hashing function to create hashes representing consensus data. These hashes can be stored for long periods of time, perhaps indefinitely and can be used for comparison purposes.
-
Create a hash that represents the state of particular currency at specific block height.
-
Create a hash that represents the state of all currencies at a specific block height.
-
Create a hash that represents the changes to balances (deltas) that occurred during a particular block. (This may be hard to calculate and/or of limited use)
-
Chance of hash collision is astronomically low
-
Hash data can be stored for every block height value from a trusted implementation and used to regression test changes to that implementation.
-
Hash data can be used to track an inconsistency to a particular block and currency ID when troubleshooting.
Details forthcoming.
Note that the hash data does not need to be calculate or stored by Omni Core itself, but can be calculated and stored by integration tests and/or Omniwallet. Hashes could be stored in a SQL databases and indexed by block height and currencyID.
Details forthcoming. We need to specify the binary or ascii format of the consensus data that is the input to the hash function.
This is a hash of all consensus data for a particular Currency ID at a specific block height.
This is a hash of all consensus data for all currencies in existence at a specific block height.
A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block. This has may not be very useful and/or may be difficult to compute.
This proposal suggests using the SHA-256 Algorithm for three reasons.
-
It provides the functionality we need
-
It is a well-known algorithm
-
All Bitcoin and Omni Protocol implementations have an implementation available
Because Consensus Hashing is neither used nor required by the specification for determining balances or for validating transactions, it is not strictly necessary to use a cryptographically secure algorithm, nor are there any direct security implications of this proposal.