💍 Promise

Safely blockchainify any puzzle game with Algorand.

See video demo of a game protected by Promise.

Original technology

The protocol combines two new technologies. A paired-content-escrow. A random-sneak-peek. Both were researched for this project.

Community contribution

An unbiased PyTeal randomness library for all.

A lot of lotteries on Algorand and other blockchains are biased. Modulo remainder arithmetics is often used to determine the winner. This is mathematically incorrect. A famous example of modulo bias is Firelotto.

We present a PyTeal library for safe and unbiased random lib_algo_random.py

Though Promise needs unbiased random, this project is not a lottery at all. Promise is a mathematical protocol to solve cheating in games once and for all. Plus a multidtude of other benefits. Read more to understand.

A mathematical protocol

There are games to tell stories. There are games to solve mysteries. If there is only one way to solve a level - only one answer - then Promise works.

Any such game old or new can, actually, be run on-chain. It can be placing mirrors to guide the laser through the labirynth. It can be finding one concept which unites four pictures. It can be guessing which brand is on the logo. We present a general solution to rule them all.

A must

Why should we blockchainify games at all? What does it even mean?

Something never possible before blockchain happens. Let's see what Promise brings in.

Auto payout on win

Before chains: Games often just change the rules in the middle. Out of nowhere, they could drastically cut the payout. There's a whole list of P2E scams that could be easily avoided by using Promise.

After: There is an algorithmic commitment. Promise escrows the money. There is no other way. Users are always auto-payed for the right answer. If the project is protected by Promise, it can be trusted.

That's why with Promise you get what you are Promised. It not only offers protection for the user. Unlike many client-side P2E games, Promise protected games are immune to all sorts of client-side memory hacks.

Auto money back on non-delivery

Before chains: There are a lot of complaints on Google Play. Paid features are often not working.

After: Promise auto-returns escrowed money, if the level was not delivered to the user. There is no other way around.

Auto content quality check

Before chains: The game has inconsistent quality levels. Or examples fall far from actual gameplay. Like in those misleading Candy Crush clone ads. Seems like the devlopers just do not care. Players are disappointed when their expectations meet ugly gameplay in reality.

After: Promise shuffles the levels using Algorand's Verifiable Random Functions. Before payment, every user gets a fair sneak peek of the random levels. Statistically the user gets the same high-quality for paid levels.

Soon, neural networks are going to disrupt the gaming industry. Imagine, auto-generated content tailored for your personality. There has to be a way to safely sell and buy such personal content. Unfortunately there is no guarantee. For example, some apps dumb down generation from GPT-3 to GPT-2 to save costs.

Actually there is a way to ensure quality, without losing funds. It is Promise. In particular its random sneak pick feature.

A content-pair escrow

One half of Promise is an escrow with hashed challenge-response pairs. It deincentivizes lying and non-participation for game company and player, guarantees payouts for right answers. This is not a regular escrow, but has a very particular player / game interaction scheme:

1. The player books a question.
2. The oracle has to reveal question's plain text. It has to match the question hash. The plain text can be a link to ipfs with a picture or a whole level folder.
3. If the oracle does not respond in time, player is eligible to call a money-back method.
4. The player sees the question and has to answer before timeout. Otherwise oracle can take his payment.
5. The oracle has to reveal the true (matching the hash) answer before timeout. Notice that it's salted, so no problems with brutefircing small answer set. Otherwise the player receives a compensation.
6. If player's answer matched the oracle answer then he receives a prize. Otherwise oracle just takes his payment.
7. This question-pair now remains open to everyone. It was a random one, so represents the overall quality of the game. With each play the reputation of the game grows.

This fair scheme is enforced via a state machine implemented in the contract:

# Global state of the contract
# Might be 
Bytes("1_ADD_CHALLENGES")
Bytes("2_RESOLVE_PRNG_SHUFFLE")
Bytes("3_SOLVE_CHALLENGES")

# Each method validates the state before execution
# Like this
Assert(self.status == Bytes("1_ADD_CHALLENGES"))

Individual state of each user matters. It allows to avoid a queue and gracefully serve each person:

# Individual state of each user 
# Saved in a box to avoid local storage opt-in
# Might be 
Bytes("1_NON_BOOKED")
Bytes("2_YES_BOOKED")
Bytes("3_YES_POSTED")
Bytes("4_YES_ANSWED")

# Each external method validates and switches the state
# According to paired-content-escrow and random-sneak-peek logic

A random-sneak-peek

The only seeming caveat after this step: what if levels are bad/dumb/fake? What if pre-loaded question-answer pairs are boring or factually incorrect?

If the question was "Who invented the light bulb?", the malicious answer could be "hahagametrickedyouandtooksomemoney". The other half of Promise got you covered.

Let's say there are 100 question-answer pairs. They are pre-commited. Then after shuffling fairly with VRF, we might reveal a quater of them. Let's call them examples. If the user likes them. Then, statistically, paid levels are likely to be same high-quality.

Algorithmically speaking:

1. A set of N question-answer pair hashes are pre-loaded into the contract.
2. The state is changed, so no new questions can be added. Plus, a future round of random beacon resolution is set.
3. Knuth-Yao array shuffle, utilising random bits from VFR proof, is used to permute an array of $[1, 2, .., N]$. Let's call this permutation $\phi[i]$
4. The state is changed to allow players book challenges. Each next player books $\phi[i + 1]$ question. Which means questions are randomly shuffled. The contract is ready to serve users.