DFB Contract Specifications
The specifications for the deterministic finite blockchain smart contract.
Contract Endpoints
There are only four endpoints and one entry for the DFB contract. The entry creates a new DFB and the endpoints allow the user to interact with the DFB. The contract is fairly simple from the viewpoint of the endpoints. A user can create or stop a DFB, join or leave a DFB, or validate a DFB.
Not all endpoints are accessible at all times due to the stateful nature of this contract. For example, join, leave, and stop can only occur when a DFB is not in a validation phase. Whereas the validate endpoint is always available.
Join
A user can join an ongoing DFB if and only if these requirements are satisfied.
The DFB UTxO must continue back into the smart contract.
The game parameter datum must not change.
Only a single DFB can be validated at one time.
A DFB can not have more than the maximum number of users.
A DFB can not be in the validation phase.
The newly added user must sign the tx.
The new user's public key hash and token addition must be appended to the current list of users and tokens.
A user's minimum required ADA is purposely overestimated and fixed at five (5) ADA.
A user can join a DFB if the phase is correct, they are not trying to change any of the values, and there is room for them in the DFB. The minimum ADA requirement is an easy simplification for users in the DFB to get their ADA back no matter what the outcome of the DFB is after some amount of validation rounds. This is supposed to guarantee that a user will never lose the ADA attached to the tokens.
Leave
A user can leave an ongoing DFB if and only if these requirements are satisfied.
The DFB UTxO must continue back into the smart contract.
The game parameter datum must not change.
Only a single DFB can be left at one time.
The user leaving the DFB must sign the tx.
The user leaving can not be the DFB creator.
The user leaving must be in the DFB.
The DFB can not be in the validation phase.
The user leaving the DFB gets their ADA and whatever tokens accrued returned to their payment public key hash address.
Leaving is very similar to joining. A user can leave if the phase is correct, they are not changing any values, and they are getting their tokens back. The user will get their fixed minimum ADA and whatever tokens they have at that moment returned.
Validate
The validation of a DFB is a multi-step process that must take at least 2 validation steps. The validation consists of a suggestion party and a confirmation party. The suggestion party will move the DFB from the default state into the validation state. The validation state is a point in time where the DFB is potentially going to move into a new state of wallets.
The suggestion party will provide the new state of wallets and a subset of hashes from the DFB that created that new state of wallets. If the suggestion party is honest then the confirmation party can confirm their suggestion by running the DFB and providing the block hashes and increment functions required to produce the subset of hashes provided by the suggestion party. Assuming both parties are unique and honest then we can say that the only way these two parties could agree is that they both ran the DFB and confirmed that the new state of wallets is truly the next outcome.
This process becomes interesting when introducing bad actors that wish to fork the DFB. If the suggestion party is dishonest and provides hashes that do not exist inside the DFB then there will be no solutions found by the confirmation party thus the confirmation party will then take over the suggestion party position and provide their own hashes that may or may not exist inside the DFB. At this point in time, a new confirmation party will attempt to provide the solutions to the new subset of hashes, and the process repeats. A DFB will move into a new state of wallets if and only if the suggestion party provides hashes that a confirmation party can create.
The probability to observe a unique suggestion party providing honest hashes and a unique confirmation party confirming those hashes in k validation steps is equivalent to calculating the ratio of numbers between 0 and that contain consecutive ones when written in base two to the total range of numbers. In another way, as the number of validation steps tends towards infinity, the probability of honest confirmations approaches unity.
Upon successful validation, the confirmation party will move the DFB into the new wallet state and will change the validation phase back into the default phase. A DFB must have two consecutive honest actors to progress. In theory, a DFB can remain in the validation state forever due to permanent forking by bad actors.
Phase 1 Validation
UTxO must continue back to the script.
The DFB must be in the default state.
The game parameter datum must not change.
Must provide the subset of hashes from the DFB.
Must provide the new wallet state from the outcome.
A validation deposit of five (5) ADA is required to validate.
The validator must sign the tx.
A successful phase 1 will move the DFB into the validation state.
Phase 2 Validation
UTxO must continue back to the script.
The DFB must be in the validation state.
The game parameter datum must not change.
Must provide the subset of block hashes and increment functions from the DFB that produce the subset of hashes from phase 1.
if the block hashes and increment functions can be found then return a new subset of hashes from the DFB, as if in phase 1.
Must return the phase 1 ADA deposit to the phase 1 validator if successful else keep ADA.
A validation deposit of five (5) ADA is required to validate but is returned immediately if successful.
The validator must sign the tx.
A successful phase 2 will move the DFB to the default state.
Create
A user can create a new DFB with whatever parameters they want inside the chain. A new DFB is defined by the datum. The creator will pick values for the parameters below:
A maximum number of players.
The total amount of synthetic assets inside the mining pool.
The rate at which the synthetic assets are released into the DFB in the mining phase.
The halving rate for the mining rate.
The starting block number.
The starting phrase.
Only a single DFB can be created at one time.
Internal testing has shown that the maximum number of players should be less than 25 for optimal user experience. As the number of players becomes large the time to solve a DFB becomes longer.
A detailed analysis is at:
Stop
The creator of a DFB can stop the DFB if required. This is different than leaving because this endpoint kicks everyone out of the DFB and returns their ADA and tokens. This is a good endpoint to use on bad starting parameters or games that don't have enough players, etc. It is designed to not prematurely end DFBs but rather to help fix mistakes. A user can stop a DFB if and only if these requirements are satisfied.
Only a single DFB can be stopped at one time.
A DFB can not be in the validation phase.
The creator of the DFB must sign the tx.
All users inside the DFB must be returned their ADA and tokens at that current state.
Allowing a user to stop a DFB prevents empty chains from clogging up the smart contract and allows creators to properly destroy their games.
Last updated