-
Notifications
You must be signed in to change notification settings - Fork 494
new contract build and deploy sequence proposal
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.
-
typeName
: the contract type -
ABI
: the contract's json abi -
sourceFile
: the file this contract originally came from
-
codeHash
: hash of compiled bytecode -
address
: address static contract is deployed to
-
A Contract Source Tree is a directory of
.sol
files, possibly with extra files that we ignore. -
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 ofTypeInfo
, indexed bytypeName
- A Chain Environment Config File is a config file with the following object:
-
chainID
: A chain identifier (genesis hash?) string -
staticContracts
: a map ofStaticTypeInfo
indexed bytypeName
-
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.
TODO finish schema definitions and define pipeline steps
Solidity needs a proper namespace solution. https://github.com/ethereum/cpp-ethereum/issues/2448