# Seatbelt for governance

## Business-problem

In voting systems such as Aragon, EasyTrack etc. it is possible to use **evmscripts**. At the moment, there is no convenient system in order to conveniently view detailed information about the scripts. There is also no way to assess the risks associated with the execution of this **evmscripts**.

## End users

The task of the service will be providing comprehensive information about attached scripts, as well as the result of emulation. Based on these data, telegram and discord bots and a separate dashboard will be created. The user will be able to evaluate the results of a successful vote without programming knowledge and extra work.

## Solution

The service will collect [information](#Information-for-collection) about the evmscript, and emulate its execution on the local Etherium node. The result will be provided in the form of http-api.

### Information for collection

The service will be collect:
> For now this spec handling Aragon only
- voting type
- voting info
- id
- status of execution
- open or closed
- executed
- date of start
- block id
- evmscript
- affected addresses
- type of each address
- validate status from etherscan
- evmscript execution result

## Api-service

### Requirements

- Available for internal use without restrictions
- Available for external teams
- Can handle a large number of concurrent requests
- Has docs and an OpenAPI Specification
- Has versioning of endpoints for backward compatibility
- Provides monitoring and alerting for:
- the application work
- work of third-party services
- data correctness

### Endpoints

There are two **groups** of endpoints available for interaction with the service:

- `/aragon`
- `/easytrack`

In each of the **groups** of endpoints there are three **subgroups**

- `/` detailed information about all votes taken
- `/count` the number of votes and at the same time the list of **id's**
- `/:voteId` get detailed information on a particular vote
:::spoiler URLs example

/v1/aragon/121
/v1/easytrack/121

:::
:::spoiler Response example

{
	type: 'aragon-voting' | 'easy-track-motion',
	data: {
            // result of .getVote()
            id: 121,
            status: 'Passed (enacted)',
            open: false,
            executed: true,
            startDate: 'Thu Mar 24 2022 16:00:21 GMT+0400 (Georgia Standard Time)',
            snapshotBlock: 14448825,
	},
	evmscript: {
		calls: []
	},
	createTx: {
		hash,
		block,
		...,
		events: [],
		calldata: []
	},
	simulationResult: {
		blockNumber,
		events: [],
		result: []
	}
}

:::

### Implementation

The implementation is supposed to be based on the [API template](https://github.com/lidofinance/lido-api-template). The template was designed to our requirements and our infrastructure and already contains most of the necessary modules:

- JSON logs
- Prometheus metrics
- Swagger
- Versioning of endpoints
- Throttling
- CORS headers
- Response caching

#### Design

The service contains four nested services:
- [Cron job runner](#Cron-job-runner)
- [Api Provider](#Api-Provider)
- [Results storage](#Results-storage)
- [Contract runner](#Contract-runner)

##### Cron job runner

The cron job is the main part of this service. On each iterate, the cron job will fetch info about voting and cache it in the database. On each new voting, the cron job will start **evmscript** **simulation**.

The cron job is triggered every **1 minute**.

There are three types of strategies for the cron job:

- fetch
- update
- evmscript simulation

How it works: **Fetch Job** download new votes and put them into the database. Then we initialize a new **Simulation Job** when the job is complete we put the results into the database as `simulationResult`. And we have the **Update job**. The goal of this job is to keep some **dynamic records** in the synced state.

List of dynamic records :

- `status`
- `open`
- `executed`

##### Api Provider

The purpose of this service is to provide **http-api** to interact with the database with these [endpoints](#Endpoints).

##### Results storage

The task of this service is to store **evmscripts**, information about **evmscripts**, as well as storing the results of the **simulation**.

The storage will be implemented with Mongodb.

##### Contract runner

The task of the service will be to copy the voting evmscript, changing the conditions for an accelerated launch. Namely, the launch date and the number of votes. After the script code is executed - all the logs will be placed in the `simulationResult` field.

The service will be based on [ganache](https://github.com/trufflesuite/ganache).

##### Proposed design

    Note over EvmScript runner: Calculating
    EvmScript runner->Database: Store calculating result
    Note over Cron job runner: Fetch contracts info
    Cron job runner->Database: Result
    Note over Cron job runner: Update contracts info
    Cron job runner->Database: Result
    Cron job runner->EvmScript runner: Trigger "simulate" task
    
    EvmScript runner-->Database: Request required data
    Database->Api Provider: Info about voting and evmscripts

#### Networks

It's suggested that the app is integrated into our infrastructure with the standard deploy scheme:

testnet=>operation: Testnet
staging=>operation: Staging
mainnet=>operation: Mainnet

testnet(right)->staging(right)->mainnet

## Next steps

Also, we could create services like this:
- telegram and discord bot for printing reports about new voting
- web interface wich adapted for fast research