Economic model for future community fraud provers

Governance Proposals Proposal Drafting
1

As requested by Jan, I create the topic to propose an additional economic model for future Turing fraud provers.
To read more about Turing, you can go check https://github.com/omgnetwork/optimism-v2/tree/turing-hybrid-compute/packages/boba/turing#introduction-to-turing

It’s a great feature overall because it will allow to greatly expand the capabilities of blockchain systems, but it also creates a new problem with blockchain immutability. If we execute a program on AWS Lambda for off-chain computations, how can we be sure that it returns the correct output and we don’t save the incorrect output in a block?

Here I’ll quote Jan:
"The revised fraud-detector will allow TCE (Turing compute events) to be verified, too, which addresses part of the issue. But it does not really address a fraudulent DAPP for example that claims to be an efficient stableswap but isn’t in reality. Basically, what is needed is a separate system for (1) DAPPs publishing their Turing code - similar to verifying your contract on Etherscan, and (2) a system for incentivizing people to check the public Turing inputs and outputs (available as events).
The initial call data are public, as are data packed into events - so an independent party can: (1) take the inputs, (2) spin up their own AWS endpoints based on public code, and (3) compare the outputs they get with what is reported in the event data. "

So, the solution here can be as follows:

  1. It can be done by setting up Turing fraud provers from the community, which integrate every dapp with Turing usage, if they provide the code they execute on AWS Lambda.
  2. These fraud provers can run also on AWS Lambda.
  3. They can request a docker file to run it on Lamdba.
  4. However, how can they be rewarded to compensate expenses for running such nodes? Since the network doesn’t receive any fees to the treasury, it could become a problem a bit later, since we can’t expect anyone to spend their resources without getting anything in return. The only suggestion now is to update economics a little bit via DAO voting and send a small percentage of the reward received by stakers (when staking is launched) to such initiatives.
  5. It might not be the best idea from the point of view of future stakers, but actually it’s in everyone’s best interests because a) we allow the network to scale because this feature can attract many developers currently limited by what Ethereum EVM and Solidity has to offer, but at the same time b) we have to make sure that the network stays secure by decentralizing centralized points of failure, c) increased number of running dapps will probably cover this cost with fees.

Actually, it may be hard to predict how many expenses we have to cover because we deal with two unknown parameters: staking rewards (we don’t know yet how it will work, what percentage of network fees will go to stakers) and the amount of operations/calculations (which depends on the network growth, how big it will get and how many dapps will be using this feature). However, we know the pricing of AWS Lambda. You can check https://dashbird.io/blog/aws-lambda-pricing-model-explained/
I took one example from the article.
“You allocated 512 MB of memory to your function and executed it 3 million times during one month. Considering that it ran for 1 second each time, you’d be billed upon monthly compute time (in this case = $18.34) and by monthly requests (in this case = $0.40). Therefore, the total billed sum would be $18.74 per month.”
So, as we see, it’s not that expensive, but we still can’t expect anyone to run an AWS Lambda fraud prover for everyone’s common benefit. So it would be safe to suggest giving 1% of the stakers fee to those who run fraud provers by dividing this fee among them. It will incentivize people to add more fraud provers until it won’t be that profitable, so we’ll reach some kind of equilibrium. The number of 1-2% can be fine-tuned later by DAO voting. But right now, I’m suggesting having this built-in option in case it will be needed, otherwise we’ll have to rely on just one output point for every hybrid-compute dapp.

4 Likes
2

Are a specific number of Boba required to run a fraud detector? I am thinking of 2 scenarios at play here:

  1. Stakers viewing provers as free riders.
  2. Provers seeing stakers as free riders on a network they “secure.”

Is there an easy way for provers to be “bonded”?
Additionally, is there a way for stakers to vote for a prover and the prover to be able to provide a cut of the fees after they cover fees and take profit, if they wish to do so?

1 Like
3

I don’t think there should be any specific amount of BOBA to run it, because in this case, we’ll narrow down the number of people who will be able to set it up and run it. It requires some familiarity with AMS Lambda and with docker files.
I also don’t think there should be any voting, since these provers are related only to one part of the network - to off-chain computing. But I may be wrong, curious to hear other opinions.

1 Like
4

Are they paid with a ETH, I assume the answer is yes, but this is a discussion to flesh out the details.

We are talking about a 500 million dollar network at the moment and the value will likely go up, which will increase the interest in attacks. Do you see any risks associated with provers and malicious code to the network? Presumably the answer is no since the only economic risk involved in running a prover is the cost to run the service, which means there would be zero network risk to allowing a person to run a prover.

1 Like