EntroBeam

Searchâ€¦

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.

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.

`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.$\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.

It is a tough challenge to exactly match the gas fee to the Wei($10^{-18}$) 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[

block.number

];

scheme_blockCount.blockCount++;

â€‹

uint256 _gas = gasleft(); //It stores the gas fee received at the initial stage of the transaction.

â€‹

$n$

= Gas fee assigned to element number in the entropy chain data set.$\mathsf{min\ max \ average}(Z)=\frac{Z_1+Z_2}{2}$

â€‹

$Z_1$

= Minimum gas fee in the entropy chain data set.â€‹

$Z_2$

= 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`

.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.

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.

Last modified 4mo ago

Copy link

On this page

Starts

Gas Mechanism

Mixing Entropy Basic Way

Mixing Entropy Enhanced Way 1

Jumbling chain