Shuffle Entropy
The algorithm that shuffles the entropy may be updated.


Smart contracts have to be executed by all participating nodes in the BlockChain network, the sender of a transaction has to pay for the computational cost of execution in units of gas.
The amount of gas to be paid by the sender of a transaction depends on the complexity of executing a smart contract’s logic. Additionally, the sender is required to specify the gas price, which he will have to pay per unit of consumed gas. The product of the gas cost and price determines the gas fee, which is received by the miner who includes the transaction in a block. Hence, setting an appropriate gas price is critical for having a transaction included in a timely manner.
While hard-coded and transparent gas cost model, there does not exist any embedded mechanism for computing how much a sender of a transaction should pay per unit of gas. The gas price is instead determined by the supply and demand for computational resources.

Gas Mechanism

The total execution cost for a contract consists of two components, namely the gas cost in units and gas price per unit. The gas cost is split into a fixed base cost of 21 000 gas and an execution cost dependent on the instructions executed while running the contract.
Gas Limit: The Gas Limit is your guess at the total amount of work you’re requesting. Due to the Turing-completeness of the EVM, the exact computational cost of a transaction cannot be predetermined. Hence, the sender is required to specify a gas limit or the maximum amount of gas that may be consumed. If your limit is too low, your work won’t be finished when you hit it; your transaction will fail and you’ll lose gas fee. As the computational steps of a transaction are executed, the required gas is subtracted from the paid gas. Once a transaction is completed, any unused gas will be refunded to the sender. Should a transaction try to consume gas in excess of the gas limit, an Out of Gas exception is thrown by the EVM. Even though such a transaction would fail, it would be recorded on-chain, and any used gas will not be refunded to the sender. Note that in addition to the per-transaction gas limit, there is also a block gas limit, which specifies the total amount of gas that may be consumed by all transactions in a block.
Gas Price: Apart from setting a gas limit, a sender will also have to specify the gas price, which refers to the amount of Ether the sender is willing to pay per unit of gas, generally expressed in wei or Gwei. Miners set a cut-off gas price to choose which transactions to include in their memory pool. When constructing a new block, they then choose the transactions with the most lucrative gas prices from their memory pool. A higher gas price will increase the fee which miners receive from a transaction, thereby motivating a miner to include a transaction in a block.
gas fee=gas limit×gas price\mathsf{gas\ fee} = \mathsf{gas\ limit} \times \mathsf{gas\ price}
If you are familiar with gas, you may observe the above formula something off. Rather than 'limit', the expression 'used' is more appropriate. However, EntroBeam calculates the 'limit' value.
So, the gas fee value of each entropy seed transaction is affected by the user-defined value, total transactions per block, block gas limit, hash rate difficulty, and network state, etc. A deep dive reveals that more factors affect the gas than expected.
Therefore, it is a knotty process to predict precisely. Moreover, the gas fee is 10^-18 units.

Mixing Entropy Basic Way

It is a tough challenge to exactly match the gas fee to the Wei(
) unit. By extension, what about completely exactly matching the gas fee of multiple transactions one by one? What's more, transactions can occur at will by anyone without any restrictions.
— From Leon Wesker, EntroBeam dev
Choosing which seeds in the entropy chain to generate secure entropy uses the gas fee item of all elements in the chain.
function EntropyByUsers(bytes32 _usersHexData) public noReentrancy {
struct_blockCount storage scheme_blockCount = struct_block_ID[
uint256 _gas = gasleft(); //It stores the gas fee received at the initial stage of the transaction.
Median calculation: Calculates the median value of all entropy registry gas fees in the entropy chain. The median array count(entropy chain.length) is recommended to be an even number, but entropy chain.length may vary between even and odd numbers depending on the frequency of transactions. Nevertheless, this is the intended architecture.
= List of values sorted order by a Gas fee (gasleft()) in the entropy chain data set.
= Gas fee assigned to element number in the entropy chain data set.
Min Max average calculation: Calculates the average value of the lowest and highest gas fee among the entropy registries in the entropy chain.
min max average(Z)=Z1+Z22\mathsf{min\ max \ average}(Z)=\frac{Z_1+Z_2}{2}
= Minimum gas fee in the entropy chain data set.
= Maximum gas fee in the entropy chain data set.
The method of using all gas fees in the entropy chain causes a kind of Avalanche effect. Even if a user wants to manipulate and predict the secure entropy, the median and average values change due to another user's transaction, Therefore, all security entropy that will be generated in the future becomes unpredictable.
The code for drawing lots using min-max average and median is as follows.
uint256 _modulo = ((_median % (FormationNumber - 1)) +
(_minMaxAvr % (FormationNumber - 1))) % (FormationNumber - 1);
Entropy chain starts at 0 and FormationNumber starts at 1, so match FormationNumber -1. The resulting value becomes the number of elements in the entropy chain that will be part of the secure entropy. The selected element is the entropy registry, but it does not match the entropy registry number. The resulting value becomes the number of elements in the entropy chain that will be part of the secure entropy.
The secure entropy is generated by hashing entropyRegistry.usersEntropy, which is the turn to receive the secure entropy, AND entropyRegistry.usersEntropy drawn by lot from the entropy chain with keccak256.

Mixing Entropy Enhanced Way 1

In addition, users can apply it to various methods. The following figure shows an example of deriving enhanced secure entropy by adding the hash values of all gas as noise to the result. This indicates that it can be applied in various ways. Users can use off-chain oracle services or side chains according to their choice or use data from multiple transactions. It is a knotty process to precisely predict the gas of a single transaction. Moreover, the gas fee is 10^-18 units. Therefore, the more linked transactions, it becomes exponentially harder to predict secure entropy. Users should note that mixing additional noise into the secure entropy in a separate transaction makes the entropy predictable. Users must chain the transactions and have them run simultaneously.
Refer to Get Enhanced Entropy CODE in Getting started.

Jumbling chain

SN No. = Number of elements inthe array. Entropy Chain length (e.g., Ten) / ER No. = Entropy Registry number / Tx = users seed transaction sequence number. Matches ER.
The number used when drawing lots in the Entropy Chain corresponds one-to-one with the array number(SN No) in the Entropy Chain. If the order of the entropy registry is changed, receiving secure entropy is shuffled, which is very unfair to the user, so the order of the entropy registry(ER No) never varies.
In the Entropy Chain, the selected secure entropy seed is removed from the chain, and a new seed from the transaction that performed this process is input into the removed point address. So, until the Entropy Chain is filled, it looks as they are sorted, but as the contracts continue to work, the registry order in the Entropy Chain gets jumbling up.
Copy link
On this page
Gas Mechanism
Mixing Entropy Basic Way
Mixing Entropy Enhanced Way 1
Jumbling chain