Eureka

Eureka is a tool for reproducable builds of Ethereum contracts. Think of it like Terraform for Ethereum.

Getting started

Make sure you have Node 13 installed and then run:

yarn install

You can run tests with yarn test.

Running Examples

Simply run:

yarn cli apply -c examples/tick/tick.js -d examples/tick/tick.eureka

Note: this project relies on Node 13+.

Example

An example is worth a thousand words. Let's say we have two simple contracts Tick which keeps track of a time variable, and Clock which prints out the associated day for tick.

We'll create a Eureka spec that specifies the desired set-up:

tick.eureka

Tick#tick{
  time: 1588297301
}

Clock#clock {
  tick: #tick
}

We specify a Eureka configuration for any properties about the contracts that are not available by analyzing the contract and ABI.

tick.js

define('Tick', {
  properties: {
    time: 'number'
  }
});

define('Clock', {
  properties: {
    tick: { 'ref': 'Tick' } // A reference to a Tick contract, i.e. an address
  }
});

From here, we can tell Eureka to deploy this configuration:

yarn cli -n rinkeby -c tick.js tick.eureka

Here, Eureka will tell you the delta it needs to construct the given configuration, e.g.:

Build<Tick#tick, { time: '1588297301' }>
Build<Clock#clock, { tick: { ref: 'tick' } }>

Then, if you decide, you can apply these changes, and the updates will be tracked in state.

State can be synced to a remote (e.g. AWS S3) to track the known state and used in updates.

Updates

The goal of the system is to allow updates, for instance, building on above:

Tick#tick{
  time: 1688297301
}

Clock#clock {
  tick: #tick
}

This would generate an action script:

Update<Tick#tick, { time: '1588297301 -> 1688297301' }>

Once applied, this would keep the state in sync.

Future Areas

Remote Import

eureka import <contract_id>
eureka import <tx_id>

This script would generate eureka config files from a given tx_id and / contract address. This effectively allows you to "import" state that was not deployed through Eureka directly.

Remote Sync

The current code does not discuss "remote sync." That is, when we change tick above- what happens when it changes remotely. Should we sync state changes from remote back to our state system, and then should we apply changes to match our diagram?

Versioning

Tick#tick {
  tag: "#v1.0"
}

Clock#clock {
  tag: "#v1.1"
}

Versioning would allow Eureka to track resources that come from different Solidity builds. This would be difficult (but fun) to try to manage different versions side-by-side, but I think there could be some good and fun strategies to approach this. For instance, we could pull contract.json from Docker builds matching the versions.

Open Questions

There remains a few open questions. First off, how opinionated should we be in "state." For instance, in Terraform, the system tracks a mapping of "local resource" to "remote resource," with the intent of never updating a resource it didn't create. Since we're in permissioned blockchain land, this might not be as important, and it might be more important to get import and sync set-up correctly. In other words, we should be opinionated about what works best for Ethereum. Also, we should question our dependency on saddle.

Notes

This project is just in exploration phase. Look under examples/tick for an example project. Look under src for the core code. We use ES7 modules, which are new, so expect things to be a bit strange. Also compound.md has a thought experiment for how this could apply to Compound.

Also, just for fun, this project uses NodeJS modules without babel, and therefore probably requires Node 13+.