A Brief Introduction To DFBs

Creating A Multiuser Redistribution Machine, Using Deterministic Finite Blockchains.

A group of users will each lock an amount of some token into the deterministic finite blockchain smart contract. A user will trigger one of the smart contract endpoints and will perform an off-chain computation, simulating a deterministic finite blockchain using an automated market maker and synthetic tokens. The resulting distribution of tokens is then returned to the users.

Deterministic Finite Blockchains

A deterministic blockchain, DFB, is a blockchain where every action, like mining or trading, is deterministically automated. This is a horrible way to represent a financial system but a great way to represent a game. Though games need to end, they need to have a winner. An automated blockchain needs the ability to end that does not rely on an outside party turning off the game or some oracle solution to provide an ending state. Thus the solution to this problem is to create a completely deterministic finite blockchain. A chain that is automated and is guaranteed to have an end state that is completely determined by the initial conditions.

DFBs are similar to side chains but are contained within a primary chain block.

Terminology

We are going to describe a DFB with some common terminology about proof of work blockchains. The difference here will be the construction of variables. Below is a table of the terminology and the equation if applicable.

Terminology	Equation / Variable	Terminology	Equation / Variable
base q	$B_{q}(h) = {}_{q}h$	block #	$i$
hash function	$H(i) = h_{i}$	block hash	$h_{i}$
mining order	$\ell_{m} = B_{N}(B_{10}(h_{i}))$	# of users	$N$
miner token	$w_{m} = B_{T}(B_{10}(h_{i}))$	# of tokens	$T$
tx order	$\ell_{t} = B_{N}(B_{10}(H(B_{10}(h_{i}))))$	mining pool	$P$
trade token	$w_{t} = B_{T}(B_{10}(H(B_{10}(h_{i}))))$	halving	$\tau$
trading pairs	$p_{\ell}=[(i,j)$for $(i,j$) in $zip(\ell_{t},\ell_{m})$if $i\neq j ]$	reward rate	$r$
token pairs	$p_{w}=[(i,j)$for $(i,j$) in $zip(w_{t},w_{m})$if $i\neq j ]$	reserve	$R$
wallet	$\omega_{u,t}$	fee	$\gamma$
token amount	$\Delta_{t}$

The hashing function returns the hash of the block number, $i$. The base Q function returns the hash written in base q, i.e. hexadecimal into base 10 into base q. The event order lists and token lists are created by nesting the base Q and hashing function together. Each list is trimmed to the shortest length list due to the length differences of writing numbers on different bases. The other variables are self-explainable with prior knowledge of any proof of work chain. For simplicity the fee is assumed to be zero since its only function inside a DFB is to extend the game.

General Algorithm

$$Mine(\ell_{m},\omega_{u,t},r,P)\rightarrow(\omega_{u,t},r,P)\\ Trade(p_{\ell}, p_{w}, \omega_{u,t}, T, \gamma)\rightarrow\omega_{u,t}\\ if\ Check(r, P)\ is\ False\ then\ Pay(\omega_{u,t})\\ else\ Increment(i)\rightarrow (h_{i},\ell_{m},\ell_{t},w_{m},w_{t},p_{\ell}, p_{w})$$

The algorithm is split into four parts: mining, trading, checking, and incrementing. If the chain were to end then the payout will occur.

The Mine function adds synthetic rewards to participating wallets from the synthetic token pool according to the mining list. The mining rate will be reduced in half upon every halving event in a very similar fashion to other proof of work chains. The mining rate will continue to be halved until it is less than or equal to unity then it remains constant forever. The mining reward is drawn from the mining pool. If there does not exist enough in the pool to pay the miner then the payout is skipped.

The Trade function adds and substracts tokens from pairs of wallets according to the trading and token pairs lists. If one of the traders involved in a trade can not trade due to lack of funds then the trade is skipped and if the AMM calculates a negative value then the trade is skipped.

The Check function returns a boolean state about the mining rate and mining pool. The blockchain will end when the Check function returns false else it will increment the blockchain into the new block.

The increment function takes in the block number and outputs the next block's information to be used in the mining and trading phases. This function interconnects each block into the next, ensuring the next state is determined by the previous state.

Each block will evolve the state of the wallets, $\omega_{u,t}$, into some new state, $\omega_{u,t}^{'}$, until the mining pool goes to zero. Upon depletion of the mining pool, the chain will cease and the participants can choose to redistribute the tokens according to the last wallet state or continue into the next DFB.

The chain is completely deterministic and can be finite if the initial parameters are set correctly. The final wallet state and block number are unknown without computing the blockchain. The blockchain is generalized to an arbitrary amount of users and tokens but only a single synthetic token is used in the mining process.

Initial Conditions

The finiteness of the blockchain is highly dependent upon the initial conditions. If a mining rate is selected to be too small then the mining pool will never be completely depleted which means the chain will not end. This can be easily circumvented by forcing the mining rate into a constant value after some amount of halving events.

If a fee is used then it has to be small enough to not overcome the mining rewards resulting in an infinite chain. This is the primary reason for making the DFB feeless because it will completely circumvent computations that can not be finished.

The input parameters for the system are the number of users participating and the number of tokens involved with the blockchain. These inputs completely determine the other initial conditions, allowing the blockchain to scale to any amount of users and tokens. The consequence of this type of scalability is that as the number of users gets large the computation time required for the chain becomes quite large so games with lots of players will last longer than games with few players.

Simplified Automated Market

Each transaction must satisfy the conservation equation below

$$(\prod_{\substack{i=1 \\ \ell \neq j}}^{T}R_{i}^{w_{i}})(R_{j} + \gamma_{j}\Delta_{j})^{w_{j}}(R_{\ell} -\Delta_{\ell})^{w_{\ell}} = \prod_{i=1}^{T} R_{i}^{w_{i}}$$

The price is determined by a constant mean product automated market. The weights of each reserve are given by the ratios of the amount in the reserve to the total amount of tokens in the system such that the sum of the weights equals unity. The system is conserved and allowed to dynamically evolve. For simplicity, every DFB will be feeless, $\gamma=1$.

Simple Automated Market MakerSimple AMM

An example of a simple automated maker market.

A CPAMM trading mechanism means that the DFB is a model of a decentralized financial ecosystem where every player is their own liquidity pool. It is a perfect match for a DFB because it allows arbitrary assets to be traded in an automatic way without the need to hardcode trading parameters into the code.

Wallet Regulations

Trades are governed by the rules of virtual wallets. Wallets are never allowed to go negative so if a trade requires a forbidden wallet value then the trade is passed. If the AMM calculates a burning, i.e. negative, amount of tokens then the trade will be passed as well. ADA will never be traded nor moved inside a DFB. It is essential to ensure that the minimum required ADA is preserved. A DFB is meant to simulate the exchange of real assets with synthetic assets not drain lovelaces from users.

Type of Tokens

The chain always uses a synthetic token as the mining token. It is not real and only exists inside a DFB. As the token trickles into the system via the mining process, it is traded with all the other tokens already inside the wallets. The trading of synthetic assets for real assets is a unique feature of a DFB. This process can be generalized to have any number arbitrary synthetic assets in a DFB available for trading.

Redistribution of Tokens

When the mining pool is depleted the blockchain will end. The last wallet state will determine the redistribution of the tokens back to their original wallets. Each participant in the system will choose to extract their tokens from the system or continue into the next DFB. It is important to remember that upon completion, the wallet state can not be reversed as it was added into the primary chain ledger. This occurs because a DFB exists inside a single primary chain block.

Incentivized DFB Simulating

A key component of a DFB is incentivizing a user to simulate and submit the outcome. If there is no reason to simulate a DFB then no one will spend their time and energy simulating the chain. This is solved by encouraging users to simulate a DFB in exchange for a token. The simulation will be part of advancing the chain as well as a way to incorporate outside actions onto the DFB. The number of tokens rewarded to the simulators will be reduced in a halving event after some amount of DFBs. This is an attempt to reward the early simulators and encourage usage within the community.

Validating A Potential DFB Outcome

The validation flow involves multiple parties working together to confirm data provided by other simulators. This is meant to prevent bad actors from changing the outcome of a game by simply faking the off-chain component. If many simulators agree to the outcome then the starting wallet state will evolve into the new wallet state.

The agreement process is based upon a total of N simulators agreeing to the existence of a subset of hashes produced inside the DFB. If a subset does not verify as proof of the outcome then that simulation will not be accepted. Upon successful verification, all simulators will be paid their reward from the pool.

Rewarding Simulators

Each simulator will be rewarded MECH tokens for their successful verification. The distribution of mech will follow a path very similar to Bitcoin. Each simulator will initially be rewarded 50 MECHs for their participation in the DFB. This reward will be reduced in half every 210,000 DFBs or approximately two months assuming constant simulation with 20-second blocks. The reward can be used inside the DFB as an additional token or as the participation token for gaming on the DFB.

Token MECH - Cardanoscan

There will only be 21 million Mechanisms.

The tokenomics of MECH need to encourage early adoption since finding simulators during the beginning of the project will be a challenge. The token is primarily designed to be a gaming and utility token but the only way to obtain the token initially is by simulating a DFB.

Summary

A deterministic finite blockchain is designed to take in a collection of wallets, perform a simulation, then return the new state for the collection of wallets. Each DFB can be connected by chaining the outcome of the previous DFB to the initial condition for the following DFB. Simulators attempting to connect all the DFBs together will be incentivized for their work by being rewarded tokens. These tokens can be used to play games with other players that use a chain of DFBs as the game generator.