Simulate proposal execution and display execution results

[protinam]

It would be extremely useful for the Wyvern DAO web UI, on the Proposal page (example), to display what the results of executing a proposal would be - which state variables would be changed, which calls would be made, etc. just like an Ethereum transaction receipt. This functionality would lessen the chance of executing the wrong bytecode by accident and make it easy for voters to see exactly what a complicated proposal would cause to happen.

This requires a few complex simulated state changes that I have not found a way to do through Ethereum's web3 API. To simulate proposal execution, the value of now would need to be changed to be past the proposal's voting deadline, and the number of votes changed so that the simulated proposal would pass. We'd need to execute the transaction against that modified copy of the Ethereum state to see what effects it would have (of course, the Ethereum state will change in between when the proposal is simulated and when it is actually executed, but most of those changes won't affect most proposals).

The ideal solution would be completely client-side (using the web3 API as necessary). A solution requiring an external server (say, a modified Geth client) which could easy be run manually by DAO voters to verify the results themselves is an acceptable alternative.

I do not have an accurate estimate of how hard this is and I could be convinced to change the bounty if it will require a substantial amount of work; I think this functionality is quite important.

Please note: this bounty is funded by the Project Wyvern development team, as we're still playing around with the Gitcoin platform, but future ones will likely be funded by the Wyvern DAO directly.

[gitcoinbot]

This issue now has a funding of 0.4 ETH (473.4 USD) attached to it.

• If you would like to work on this issue you can claim it here.
• If you've completed this issue and want to claim the bounty you can do so here
• Questions? Get help on the Gitcoin Slack
• $16923.95 more Funded OSS Work Available at: https://gitcoin.co/explorer

[kamescg]

@protinam I've been attempting to understand, recently, what is the best methods for handling predictable state transitions via a client-side solution. In addition, to testing smart contract execution via a testable private/test chain (most likely using Ganache).

I've had a lot of success managing state predictable state transitions via React, Redux and Sagas - below is an example of asynchronous blockchain interaction, which scans the Ethereum blockchain, finding ENS related transactions and requesting each transaction "receipt". It's a test to easily handle more complex data syncing requirements with the blockchain.

Screencast preview: https://twitter.com/KamesCG/status/952233396477947904

A lot of the async stuff is handled in Redux Store Department Sagas that overlay on top of the ethers module (https://docs.ethers.io/ethers.js/html/)

I monitor smart contract deployment and state changes via a local Ganache blockchain that is spin-up every time the application is booted up. What I'm thinking is we could feed that correct "state" as required by your application and test state changes from there (as a temporary bridge)?

Does that sound like a potential solution to what you're doing?

/* ------------------------- External Dependencies -------------------------- */
import React from 'react'
import { connect } from 'react-redux';
import { compose, lifecycle, withState } from 'recompose'
import { reduxForm } from 'redux-form'
/* ------------------------- Internal Dependencies -------------------------- */
import { createValidator, required } from 'logic/forms/validation'
import EthersContractInformation from 'assimilation/display/ethers/EthersContractInformation'
import { fromEthers } from 'assimilation/symbiosis/selectors'
import ethers from 'assimilation/symbiosis/ethers/actions'
import Form from './form'

// Depreacted Store Department Request Style | fix this @kamescg
import { databaseWriteRequest } from 'store/departments/actions'
/* ---------------------------- Module Package ------------------------------ */

/*-* State Management *-*/
const BlockFetchLifecyle = withState(
  'blockRun',
  'blockRunToggle',
  true
)
const TransactionFetchLifecyle = withState(
  'transactionRun',
  'transactionRunToggle',
  true
)

const TransactionList = withState(
  'transactionList',
  'transactionListAdd',
  []
)

/*-* Recompose *-*/
const QueryLifecycle = lifecycle(
{
  componentDidMount()
  {

    this.props.blockchainBlockNumber()
    if(this.props.blockNumber && this.props.blockRun) {
      this.props.blockchainBlock(this.props.blockNumber)
      this.props.blockRunToggle(toggle=>!toggle)
    }
    this.props.contractCreate(this.props.ethAbi)
    this.props.blockchainBlockNumber()
    if(this.props.ethAddress) {
      this.props.accountTransactionCount(this.props.ethAddress)
    }
  },
  componentDidUpdate(prevProps)
  {
    if(this.props.submitting === true) {
      this.props.reset()
      this.props.blockRunToggle(toggle=>!toggle)
      if(this.props.transactionRun == false) this.props.transactionRunToggle(toggle=>!toggle)
    }

    // Update Multiple Blocks
    if(this.props.blocksAllCalled != prevProps.blocksAllCalled ) {
      if(this.props.transactionList[this.props.blocksAllCalled] ) this.props.transactionListAdd(n=>[...n,   ])

      this.props.blocksAllCalled.map(block=> {
        if( block.data.number && !(this.props.transactionList.indexOf(block.data.number) > -1) ) {
          block.data.transactions.map(tx=>{
            this.props.blockchainTransaction(tx)
          })
          this.props.transactionListAdd(n=>[...n, block.data.number])
        }

      })
      this.props.blockRunToggle(toggle=>!toggle)
      this.props.transactionRunToggle(toggle=>!toggle)
    }
    
    /**
     * Transaction Update
     * @desc Watch for new trasactions added to the list. If a new transaction is filtered,
     * we're going to send a "write" request to Firebase Realtime Database
     */
    if (this.props.transactions != prevProps.transactions) {
      this.props.databaseWriteRequest(this.props.transactions)
    }

  }
})

/*-* Redux *-*/
const mapStateToProps = (state, props) => {
  if(props.blocksAllCalled && props.blocksAllCalled.length > 1) console.log(props.blocksAllCalled)
  return {
    status: props.ensName ? fromEthers.getDeltaStatus(state, props.delta) : fromEthers.getDeltaData(state, props.delta),
    data: props.ensName ? fromEthers.getDeltaData(state, props.delta) : fromEthers.getDeltaData(state, props.delta),
    dataBlock: fromEthers.getDeltaData(state, `block`),
    dataBlockStatus: fromEthers.getDeltaStatus(state, `block`),
    latestBlock: fromEthers.getDeltaStatus(state, `blockLastestNumber`),
    txCount: fromEthers.getDeltaData(state, 'transactionCount'),
    txData: fromEthers.getDeltaData(state, 'transaction|'),
    transactions: fromEthers.getFilter(state, 'to', '0x6090A6e47849629b7245Dfa1Ca21D94cd15878Ef'),
    blocksAllCalled: fromEthers.getStarting(state, 'block'),
  }
}


const mapDispatchToProps = (dispatch, props) => ({
  // Firebase Database
  databaseWriteRequest: (tx)=>dispatch(databaseWriteRequest({
    payload: tx,
    metadata: {
      delta: 'addTx',
      entity: 'mutate',
      branch: [
        'request'
      ],
      writeType: 'patch'
    },
  })),
  // Blockchain
  blockchainBlockNumber: ()=>dispatch(ethers.blockchainBlockNumber('REQUEST')(
    null,
    {
      delta: 'latestBlock'
    }
  )),
  blockchainBlock: (blockNumber)=>dispatch(ethers.blockchainBlock('REQUEST')(
    blockNumber,
    {
      delta: `block`
    }
  )),
  blockchainTransaction: (txHash)=>dispatch(ethers.blockchainTransaction('REQUEST')(
    txHash,
    {
      delta: `${txHash}`
    }
  )),
  accountTransactionCount: (address)=>dispatch(ethers.accountTransactionCount('REQUEST')(
    address,
    {
      delta: 'transactionCount'
    }
  )),
  contractCreate: (ensName)=>dispatch(ethers.contractCreate('REQUEST')(
    {
      ethAddress: props.ethAddress,
      ethAbi: props.ethAbi
    },
    {
      delta: props.delta
    }
    )),
})


/* ----------------------------- Redux Form -------------------------------- */
/*-- Event Handlers ---*/
const onSubmit = (data, dispatch, props) => new Promise((resolve, reject) => {
  const blockEnd = data.ethBlockNumber - data.countBackwards
  if(!data.countBackwards) return null
  for (var index = data.ethBlockNumber; index != blockEnd; index--) {
    dispatch(ethers.blockchainBlock('REQUEST')(
      Number(index),
      {
        delta: `block|${index}`
      }
    ))
  }
})

const validate = createValidator({
  'ethBlockNumber': required,
  'countBackwards': required
})

const config = {
  form: 'FormEnsScan',
  fields: [
    'ethBlockNumber',
    'countBackwards',
  ],
  destroyOnUnmount: true,
  onSubmit,
  validate
}

/* ----------------------------- Export -------------------------------- */
const FormConfiguration = reduxForm(config)
export default compose(
  connect(mapStateToProps, mapDispatchToProps),
  FormConfiguration,
  BlockFetchLifecyle,
  TransactionList,
  TransactionFetchLifecyle,
  QueryLifecycle,
)(Form);

[vs77bb]

@protinam @owocki @kamescg Just wanted to poke my head in here... Kames, you may be looking to make a claim on this bounty depending on response, yes? Curious to hear your thoughts on time to execute if @protinam agrees with approach!

[protinam]

Hi @kamescg @vs77bb, thank you both for your interest.

@kamescg, what you're describing sounds exactly like the kind of solution we'd be looking for. I have a few questions about the functionality of Ganache (that weren't answered by a quick scan of https://github.com/trufflesuite/ganache-core - but I'm not familiar with the internals of that framework):

• Can Ganache easily clone some specified subset of the state of the real Ethereum network, on load? Specifically, we would want to clone the state of the DAO smart contract, including any assets it holds (such as ERC20 tokens), the proposal we're trying to simulate, and the state of whatever other contracts the proposal will interact with. As I understand it, Ganache does support a "fork" option where it will fork the state from another Ethereum client at a specified block, and can do so over web3 - that's exactly what we'd need as long as their implementation is fast enough to run quickly even with network latency (the user will likely be using Metamask, so the other Ethereum client would be remote).
• Does Ganache support manual state modification (like eth_setStorageAt instead of eth_getStorageAt)? We'd need to somehow "fake" the proposal receiving enough votes to be passed, which requires both (a) speeding up time, which Ganache seems to be able to do with evm_increaseTime, and (b) increasing the vote count in favor of the proposal past the quorum threshold, which could be done by manually setting the token balance of a fake user and having the fake user vote for the proposal.

[kamescg]

As I understand it, you would essentially want to maintain the blockchain state, starting at the block number to when the Wyvern DAO was launched, all the way to present block, where state change is being tested. Depending on how often (and by whom) the tests are being run, I might recommend running a "testnet" server, which provides an JSONRpc endpoint, for both Metamask and a distributed application to communicate with.

Ganache probably won't be the right fit, if it's more of an end user running tests, as opposed to a developer.

That being said, Ganache is great for the instance where you described somehow "fake" the proposal, because at the point you basically need to control the state of blockchain, and it only needs to resemble the mainnet "just enough"

It's really a matter of what type of testing is required.

If a testing suite is required for developers and core team I would probably recommend the Ganache approach. Especially if you want to generate mock voting and other state changes, which don't necessarily match the mainchain. A situation, where more refined control is required from a DAO/dApp development perspective.

If testing is required only with the actual state of the mainnet blockchain (no "fake" voting or accounts), and also a broader audience wants to run "tests" against possible "state" changes, then I would recommend a JSON-RPC endpoint, which can be more easily accessed and synced via scripts or other issued commands. Like you said, just essentially just maintaining a geth node, which could be constantly "rewound" or easily reverted from an end user perspective.

@vs77bb Thank you for keeping the conversation going :)

[protinam]

@kamescg Can you expand on what you mean by Ganache not being a good fit for an end-user? As I'm envisioning it, the user would never need to interact with Ganache - it would be run in the background to simulate proposal execution, and then resulting logs from the transaction (e.g. token transfers) would be displayed to the user on the proposal page, just as they would be displayed if the proposal had been executed for real. Is that infeasible for some reason, or were you thinking of some other implementation?

[kamescg]

If you're thinking the ganache-cli vs the Ganache GUI. Yes - that would be a good fit.

Just want to make sure we're referencing the same tool :)

The Ganache GUI client running as JSONRpc API, is not the appropriate tool for providing an end-user access to running blockchain tests. That's suited for local development purposes.

However, the ganache-cli (https://github.com/trufflesuite/ganache-cli) would be the more optimal choice. Since, it's simply a Node Module that uses ethereumjs to simulate full client behavior. It would be much easier to therefore create an API endpoint using an express API that wraps the ethereumjs/ganache-cli functionality.

A browser/distributed application could more succinctly communicate with the testing environment either using a simple REST API. Or if more complicated querying/mutations are required perhaps a GraphQL layer?

I might suggest running the endpoint using serverless architecture, where you could add authentication to prevent abuse and also only pay for what the resources used.

Below is a good example of repo that has a similar setup to what I'm describing. In fact, I might recommend forking the code and building from that.

https://github.com/peerism/peerai-api

[protinam]

Yes, I was referring to ganache-cli, apologies if my terminology was ambiguous.

Your suggestion is to run it remotely, which is certainly possible, but can't ganache-cli just be run in the client's browser directly (via Webpack)? The NPM module claims browser support, and we wouldn't need any private data or keys, all the DAO information is public. Is there a reason you think running a remote server would provide an advantage for our use case?

My other question with ganache-cli remains - does it already support something with functionality like eth_setStorageAt, or could it be easily modified to do so? We need to simulate state changes that cannot be simulated solely through function calls to existing contracts (nothing complicated, just a fake user with enough tokens voting for the proposal we need to simulate).

[kamescg]

Now you are speaking my language! I been wanting a reason to run mini-blockchains in the browser for distributed computing (in this case testing) for a couple of months now. This is the perfect use case :)

The only potential issue I see in this scenario is the amount of blockchain data being stored. But it seems like we won't have tooo much? At any given point in time we'll be just running small segments of the blockchain? If that's the case, we can certainly keep everything in the Browser.

Perhaps even using local storage to quickly/easily restore desired blockchain state for tests. Instead of constantly having to request the same data from the blockchain, we'll save it locally for easily retesting data/information.

A couple of days ago stockroom was launched which offloads data, logic and networking to a WebWorker. Completely removing thread blocking requests with computation heavy requests (like blockchain). Peeeerfect for syncing blockchain data and running these sorts of computations in the Browser, without disrupting the primary Dashboard interface. My first response was joyous, because of a situation just like this :) (https://twitter.com/KamesCG/status/954427711744823298)

Github: https://github.com/developit/stockroom
Example: https://stockroom.surge.sh/

In regards, to eth_setStorageAt I'll more closely examine underlying code... If it's NOT easily implemented, we request blockchain data using ethers and push the blockchain data into the ganache-cli testing module. It might require a few code "bridges" but I can't imagine anything being a show stopper.

I think we might have arrived at a nice conclusion point. Let me just double check everything - dotting the i's and crossing the t's - reviewing in more detail what we've discussed and I'll provide a mini scope of work. This is a relatively large task :) but could definitely help (I think?) a lot of Ethereum projects.

[vs77bb]

@kamescg You're all over the place 🙂 depending on how the final outcome, would you like to make a claim here on Gitcoin?

[kamescg]

@vs77bb I will make a claim shortly. I just wanted to ensure I could deliver on the final intended product, before committing myself.

[protinam]

@kamescg If ganache-cli implements --fork as a storage diff - meaning that it doesn't download the EVM state from the forked client, just keeps track of the differences as transactions are executed - it should be fine; proposals are just single Ethereum transactions and won't change that much state.

Stockroom looks helpful; running this asynchronously off the main render thread would be a good idea, and a second or two for the simulation results to load is just fine.

I agree, this functionality seems like it would be pretty useful generally. If you prefer to implement this in a standalone repository in a format more amenable to general integration, I'm fine with that (it would count for Gitcoin) as long as it covers all the requirements we've discussed; implementing it here directly is fine too.

[kamescg]

After posing the question on Twitter, Kumavis (Metamask) recommended we go straight to ethereumjs-VM and run that in the browser.

https://twitter.com/kumavis_/status/955874660016467968

It was mentioned Metamask does something similar in https://github.com/MetaMask/provider-engine

I'll digest the new information and see how Metamask code might help discern how this can be most effectively built.

[protinam]

@kamescg Any further thoughts on Metamask's provider engine or ethereumjs-vm? I'm not familiar with Metamask's particular implementation, but running the VM directly in the browser sounds like a more direct solution than Ganache (and probably easier to implement a custom eth_setStorageAt call in).

[protinam]

@kamescg @vs77bb Wondering if either of you are still interested in this? Otherwise I might work on it myself, but wanted to give you the chance first.