indexed-finance/circuit-breaker

circuit-breaker's Issues

Makefile Target For Docker Build Uses Incorrect Image Name

The make docker-build target incorrect references my github name, this should be changed to indexed-finance.

Better Gas Price Calculations

At the moment we use a basic method of estimating gas price for circuit break transactions. We do this by using the go-ethereum gas price oracle, and if the reported price is lower than our minimum, overriding it by the minimum, followed by multiplying it by a configurable limit.

A better option would be to poll the etherchain api and if its reported fastest price is higher than what we estimate overriding the estimation to to the one reported by etherchain.

Optimize API Request Counts

Overview

Right now each time a new block is mined we need to gather three different sets of metrics about various index pools. These are the denormalized weights, balances, and total supplies of the basketed assets. At the moment these are done in three requests submitted to the multicall contract. While this works for monitoring a small number of indexes it will scale poorly with each newly monitored index.

Changes

• Write a getBundle function in the multicall contract. This will allow fetching all three sets of information for a given pool in one request returning it as a struct type in a "bundle".
• Write a getBundles function in the multicall contract. This will allow fetching multiple bundles in a single request.

One thing to think about is the maximum number of bundles fetched for getBundles call. APIs like infura typically impose a maximum amount of gas you can retrieve in staticcalls, so at some point attempting to fetch a certain number of bundles will result in an error. Need to do some testing to figure out what average amount of bundles fetched per request can be. I think a safe estimate would be 2.

Monitor Logs For Spot Price Caluculation Errors

Note

This occurred during initial development leveraging sqlite as the database backend. Since testing with production deployments using postgresql and moving to the microservice'sh architecture I have not noticed this issue appear. Logs for the contract-watchershould be periodically reviewed for the following error message:

failed to find record, trying a different block

Issue

Essentially sqlite does a global table lock, whereas postgresql can lock individual rows. This mean that the goroutines responsible for updating the database would occasionally race, and one update operation would fail. It also looks like the underlying disk I/O would fail to flush the newly updated information, which would coincide with a contract-watcher attempting to look this information up, and not finding it.

This lead to occasional issues where the contract-watcher service would fail to correctly calculate spot prices. The solution to this was to lookup the information from the previous block, and if that information wasn't available looking up the block before that, up to a maximum of 10 previous blocks before marking the attempt to calculate the spot price as failed.

As mentioned in the start of the issue, I have not noticed this in around 1.5 weeks of extensive testing, but it is something to keep an eye on nonetheless.

Trigger Circuit Breaking

Everything is in place for triggering circuit breaks, including the ability to sign transactions. All that is needed is for the contracts to be updated. Once this is done I'll need to do the following to trigger circuit breaks:

• Update contract abigen bindings stored in the go-indexed

Investigate GVisor Integration

I'm not entirely certain how useful adding gvisor to the docker integration would be, however anything that could lead to improved security is worth investigating.

Finish Repository Migration

• Migrate existing github issues
• Migrate codebase
  • Update screenshots
  • Update module names
  • Change project name
  • Verify TravisCI integration
    • Update encrypted environment variables

Add Secondary Event Source / Better High Availability

At the moment a highly available deployment of circuit-breaker would be running multiple instances of block-listener and contract-watcher services, each using the same RPC provider.

The best way to improve this would be to have multiple instances of block-listener and contract-watcher, each using a different RPC provider, or perhaps leveraging blocknative. That being said it would still be advisable to have multiple instances of the block-listener and contract-watcher services as this prevents issues with one host causing an outage of the circuit breaker.

Tagged as low-medium as it does not appear to be strictly necessary for correct operation.

Edge Case Bug With Tests

In certain situations smart contract PoolTokensFor function may return tokens as being "current" that have a balance of 0. This may happen when tokens are getting phased into the pool. For example at the time of writing ZRX is being phased into the CC10 pool, but currently has a balance of 0. This is causing tests to fail.

Better Event Watcher Testing

At the moment as there is no deployment on testnets, event watcher testing is done using simulated backend, however due to the nature of simulated backend, and the difficulty in a full deployment of indexed on the simulated backend, testing is a bit brittle. Once there is a deployment on a testnet I can overhaul the event watcher testing to properly test the workflow.

This isn't to be confused with the eventwatcher not being tested, it is just that the testing is a bit awkward.

Add CLI Command

Right now if a circuit break fires enabling swaps afterwards is a bit annoying and requires using metamask + etherscan. A simple CLI command to toggle swaps would be best.

Add Generalized Multicall Capabilities

At the moment I'm using a customized mutlicall contract that exposes view functions for specific functionality. This was due to the complexity of manual abi encoding/decoding with Golang. It is satisfactory, however there is something to be said for having a generalized golang equivalent of multicall.js.

Long Term Goals

Better Price Fluctuation Calculations

At the moment we solely determine price fluctuations based on spot prices as determined by the pool contracts. This is suboptimal because it doesnt consider price fluctuations across the market as a whole. This means that in certain situations prices may fluctuate across the market, and not yet appear within the index contracts.

If we are able to calculate prices by sampling the entire market in general, we could potentially break the circuit before any price fluctuations occur within the index contracts. This would enable a much safer circuit breaking capability.