Skip to content

new contract build and deploy sequence proposal

Nikolai Mushegian edited this page Jul 11, 2015 · 5 revisions

intro

The existing build and test processes are limited and cannot be used for anything beyond very basic contract systems. The main problem comes from the fact that contract types and instances are fundamentally confounded throughout the framework. This is evident from the contract configuration file format: You can only name a contract type, and each type has a single set of constructor arguments.

This document describes data models for a proposed build/test/deploy pipeline to extend or replace the current features.

definitions

TypeInfo
  • typeName: the contract type
  • ABI: the contract's json abi
  • sourceFile: the file this contract originally came from
StaticTypeInfo inherits from TypeInfo
  • codeHash: hash of compiled bytecode
  • address: address static contract is deployed to
  1. A Contract Source Tree is a directory of .sol files, possibly with extra files that we ignore.

  2. A Contract Library Source File is a json (or yaml or cson) file containing an object with the following fields:

  • source: (escaped) string containing a single solidity source file with one or more contracts. This will usually just be all the files in (1) preprocessed and concatenated.
  • typeInfo: A map of TypeInfo, indexed by typeName
  1. A Chain Environment Config File is a config file with the following object:
  • chainID: A chain identifier (genesis hash?) string
  • staticContracts: a map of StaticTypeInfo indexed by typeName
  1. An Deploy Sequence Specification is a file consisting of lines of one of the following formats:

    VARNAME <- deploy TypeName arg1 arg2 arg3 ... VARNAME <- send (VARNAME|0xRawAddress) arg1 arg2 arg3 ... assertEq val1 val2 print VARNAME

Hopefully the function of each is self-evident. The point is that it lets us build entire dependent contract DAGs, with intermediate installation transactions, with multiple contracts of the same type, while testing and logging intermediate results.

Further work

TODO finish schema definitions and define pipeline steps

Solidity needs a proper namespace solution. https://github.com/ethereum/cpp-ethereum/issues/2448