2

Say I want to create a contract that rewards miners with an ERC20 token for discovering solutions to a certain mathematical problem where the following points apply:

  • The problem is well defined and with some moderate effort, one could write some solidity code that can verify solutions to the problem
  • There are many valid solutions to the problem
  • The solutions are valuable to mathematicians interested in the problem
  • Some solutions are bigger in terms of data size than others
  • Some solutions are more interesting than others but all solutions should be kept around for research purposes

As a more concrete example, say I wanted to re-implement prime coin using a Ethereum token (I'll call it PrimeToken). (I am not interested in doing this specifically, but it serves as a good enough example):

uint256 public lastNumber = 1;

function proofOfWork(uint256 number){
    if (number <= lastNumber) throw; //Always have to find a new prime number bigger than the last
    if (!isPrime(number)) throw; // Verify solution is valid
    //If it is valid, reward the miner and set the last solution as the submitted one
    lastNumber = number;
    balanceOf[msg.sender] += number - lastNumber;
}

As bigger and bigger prime numbers are discovered, the uint256 would overflow and I would have to change this to a bytes array to handle very large numbers, and implement some way of handling the byte array like a bigint. Assume I did this from the start and were competent with doing so.

My question is, how does this scale? What happens as the submitted byte array gets larger?

  • Will the miners submitting prime number solutions have to pay more and more ether (in gas fees) to get their PrimeTokens as the IsPrime() function takes more processing power to verify for larger numbers?
  • Is there a similar fee for the size of the data submitted?
  • Is there a limit to the size of the data submitted?
  • Will the blockchain become bloated with the large data storage requirements for the large numbers?
  • How do mathematicians interested in prime numbers find the previously submitted solutions? Can they just use a block explorer?
  • Are there any ways I could mitigate these scalability problems?
F Chopin
  • 123
  • 3

1 Answers1

0

Okay, so a whole bunch of questions but they all orbit around scale, data storage and cost. I'll see if I can start small and scale up the answer.

Fixed sized fields

Using 256-bit integers (or possibly pairs) you can store some pretty big numbers with precision. Don't try to scale up precision as you go. Reach for the biggest val you will ever need so that's a fixed size, fixed cost. This applies to the interface as well. Do everything in fixed-sized chunks.

Large Objects

If instances of the solution are expected to grow in complexity/size then you shouldn't store the data in the chain. Just to be clear, I'm talking about a "solution" that is a collection of data points and those collections are expected to have more and more elements over time.

Any rising cost will certainly hit a hard limit and that will be bad. Instead, consider serializing the data and dropping it into IPFS or Swarm and storing the coordinates and validating data hash in the contract. You can probably accomplish that with two 32-bytes storage slots.

Inverted Responsibilities

I realize the foregoing implies an inversion of some of your structure in that doing the math and validating a solution would almost certainly be pushed out to clients rather than in the Solidity contract that binds it all together. Such inversions happen when designing for blockchain.

A solution to that problem is to add a reportWrongAnswer() function with incentive. Think in terms of game theory and eventual consensus purging out garbage. Clients should be confirming data before they act on it and reporting errant "solutions."

Big Tables

What about large row counts? It's possible to mess this up. You need to ensure a fixed gas cost at any scale. The basic EVM opcodes are flat rate per operation. A "stand-out" cost is SSTORE (20,000). This is scale invariant. You can insert rows and be certain the size of the table is of no concern.

Anti-patterns

You want to watch out for unbounded loops and recursive processes that will lead to rising cost. Have a look over here for some patterns you can use for inspiration. They can be adapted for any sort of table/row/column arrangement and when you know the gas cost of your implementation you can be certain it won't creep up over time.

Are there well-solved and simple storage patterns for Solidity?

Hope it helps.

Rob Hitchens
  • 55,151
  • 11
  • 89
  • 145