Hello folks, this is my first post.
At @pauldaoust suggestion of increasing security by a pre-authorization of a transaction, I had an entire idea about this.
Holochain has a certain level of redundancy with randomly chosen agents, making it hard to trick the network. This level of security is more than enough for social data, traceability, or other data that do not require a global consensus but just a normal validation by others. There are though other types of data that may require a greater level of security, not for financial transactions, where global validation is required, but more data of higher importance or critical.
Starting from the fact that standard validation is enough for most cases, where data is not dependant on others, on data that is not available yet, or where it is not critical, then we can increase in some way the number of standard validations, where the data is more important.
Let’s consider we have critical entries (transactions) really in need of a stronger security level and we want to increase that security level to a much higher level of redundancy than the default 5 (to 20 or even 100).
This can be done at the application level, before developing into Holochain. It would act as a commonly shared history by nominating more than the default number of random witnesses to make extra validations. To nominate more agents for extra validations we need additional entries created, which would trigger many more new validators to act as pre-authorization for the critical entry. For these entries to nominate new different agents distributed in DHT, they need to contain extra data to trigger a cascade effect in their hashes. The way Holochain is built to spread data into DHT by hash will determine the random nomination of agents for storage and validation of entries.
There is no need for a global consensus, but at least it will increase the pre-validation of the transaction, by having a lot more random witnesses.
Sensitive or critical data such as karma-reputation computations and values, product composition which if changed all products can become BIO, or too many changes of that composition, who’s the admin of a group, kicking someone from a group, if someone has too many posts or likes from too few users, and any other critical or sensitive data.
Multiple different entries created, implies having more validations, more specific 5 for each. Additional entries needed, 20 to 100, will already include the default 5 redundant validations for each, thus their total must be divided by 5, to get the amount of created entries needed for the required number of validations.
These 20 to 100 can actually be even more, but still, be way less than the entire global consensus. In my opinion, in the way Holochain is designed, there is no need for more than 100 validations, because it wouldn’t improve the security too much.
This pre-validation process can highly increase Holochain’s security above its standard redundancy of 5, by doing 4 to 20 writes for the same transaction, leading to 5 times more validations (20 to 100 times), at the same time overwhelming the network.
These writes in random positions in DHT, wouldn’t necessarily need random data, but only predefined nonces, in order to easily find them to check the recent history. These nonces will trigger cascade changes in the hash, making it random.
This pre-authorization can be made by both transaction agents, as long as one of them exposes himself with malicious data to others, or pretend to properly validate pre-authorizations.
It’s not about how much we can validate from the transaction history, but how many can validate the current transaction.
It’s not about data forks either, as long as the transaction agents have entries specially created with additional data, which determines a widespread in DHT.
This pre-authorization process also avoids shards, if more witnesses are required to accept the same transaction. Here we must take into consideration the availability and time of eventual consistency, to close the transaction, in the event of increasing too much the number of validators.
It is not about a warrant (or even karma reputation) that could be hacked, because it’s not addressable, as long as any warrant is sent by the validator to everyone and kept locally by them.
Finally, a financial transaction or property right transfer will not avoid double-spending, as long as there is a chance that the ‘doubled’ transaction along with its 100 different validators, intersects with at least one of the 100 witnesses for the other transaction.
This was an exercise of a clear understanding of the entire Holochain architecture: data spread, propagation, eventual consistency, validation, and its security and how to greatly increase security at a more than redundancy factor of 5 at the application level.
