Entropy Registry
The entropy registry is a database that stores entropy seeds sent by users and the secure entropy generated by the contract. v1.0.0 has the following attributes:
bytes32 usersEntropy; //end-user entropy seed
bool verifyDuplicate; //check duplicate entropy seeds true=duplicate, false=non-duplicate
bytes32 revealEntropy; //Entropy generated by the Contract and sent to the user
verifyDuplicate is an entity instance that checks whether a transaction occurs with a duplicate value in usersEntropy. So duplicate values will be reverted.
When the end-user initiates the actual transaction in EntroBeam, it enters a 256-bit hexadecimal string into the usersEntropy. Refer to Getting started for details and guides. Registration in usersEntropy is successful, the stored data is not lost or modifying, and a unique sequence number is given starting from 1. The latest sequence number is assigned to numberLatestUsersEntropy.
Entropy Registry is accumulated continuously in Array_EntropyChain. For storage format, refer to Entropy Chain.
The indexing in Entropy Registry is usersEntropy. It's not a number. usersEntropy can use the SHA256 value as it is. Don't forget prefix '0x'.To index by a number, use Array_EntropyChain. Keep that in mind. Array_EntropyChain and Entropy Chain are different concepts. Generally, the Entropy Chain is Assigned_EntropyChain.
usersEntropy is the entropy seed sent directly by the user and will be mixed with other entropy seeds. Other entropy seeds are also entropy seeds sent by other users. revealEntropy is the result of mixing entropy seeds and becoming a secure entropy seed.
usersEntropy = Entropy seeds = User seed (256-bits)
revealEntropy = Secure Entropy by EntroBeam = Reveal seed(256-bits)
If the secure entropy (Reveal or Settle entropy) is not yet its turn to be generated, the secure entropy returns "0" 256 bits.
I.g., Entropy Registry when Entropy Chain.length is 4
Entropy Registry [1] : The first entropy seed sent by the user is stored in Entropy Registry [1]. All subsequent entropy seeds are also stored in sequence. And then combined with the unpredictable entropy registry [6] generated in the future, secure entropy(Reveal seed) generation is complete. It was the Entropy Registry [8] transaction that performed this process.
Entropy Registry [2] : At the time Entropy Registry [2] was created, it is not known which Entropy seed it will be combined with in the future. It was combined with Entropy Registry [4] by Entropy Chain. Registry [9] transaction performed this process, and [9] and [2] are not combined because the process that initiated the transaction is excluded from the entropy chain.
Entropy Registry [3] : The user's transaction created registry 3, but the secure entropy has not yet been created. The secure entropy of [3] will be generated when Entropy Registry [10] is executed. At this time, the entropy registry [9] is included in the entropy chain.
Entropy Registry [4] : When registry [11] is run, a secure entropy (reveal seed) will be generated.
Entropy Registry [5] : Let us suppose the following. Secure entropy generates when it is a turn, regardless of whether it belongs to the entropy chain or not. So, when the algorithm of the entropy chain chooses the registry [5], the entropy of [5] mixes with itself to create a secure entropy. Of course, [5] User Seed and [5] Entropy Seed are different.
The Entropy Registry selected from the Entropy Chain and mixed with other Seeds is removed from the Entropy Chain. And Entropy Chain embeds new seeds inside the chain.
When a user sends a transaction to the entropy seed, each transaction is given a sequence number(Indexable in Array_EntropyChain, but the structure is different.). Then, 'reveal seed' (the secure entropy of the contract) is allocated forward order according to the sequence number. End users can find Reveal Seeds by indexing User Seeds in the contract's Entropy Registry. And user can also see Reveal Seed bits in the event log of inbound transactions. A process is performed whenever a transaction occurs, but the latest transaction only stores the seed and does not participate in seed generation.
Users can find reveal seeds in the Event log of inbound transactions. If there are no inbound transactions, it is not yet its turn. In addition, unless no other user generates a transaction, the user cannot earn Reveal Seeds.
It is possible for the same address to continuously generate user seeds. Therefore, entropy chains can all be generated from one address. In some cases, it may be possible to combine desired seeds and each other seeds.
However, doing so is challenging due to the features of the Entropy Chain. And continuous or reserved transactions and one account generating multiple TXs within one block will be readily reverted 'out of gas.' Moreover, as user participants increases, this becomes impossible.
EntroBeam is inspired by the idea that a blockchain network is a system that gets more robust as the participation of nodes and miners increases. As users' entropy transactions(TXs) participation increases, the EntroBeam contract creates a more robust secure entropy.
Copy link