dapple
dapple copied to clipboard
dapphub
naming issues in dappfile/dapplerc
- in .dapplerc, "ethereum" key name really means "eth_rpc" connection configuration
- in the dappfile, the environments are named after chains not chain connection info. "live" should be "ethereum" in most cases I've seen it
Environments should definitely be named after chains, as they communicate information about chain states. .dapplerc should also allow different chains to have different connection settings so the user can take advantage of multiple chain providers at once. Having connection settings named after chains lets us collapse those two concepts into a single CLI option. Not sure at this point that's the best way to do it, though, as different Dapple projects may also use different chain providers for the same chains. Addressing that potential use case would require splitting the -e flag out into two flags.
What do you think?
as different Dapple projects may also use different chain providers for the same chains.
Not sure this is a degree of freedom worth adding.
How does this read to you: A "chain" is a unique blockchain. We usually identify it by block hash which is its "name", unless it also has an alias like "morden" and "ethereum". This alias map is not defined anywhere yet. In the dapplerc, we map chain names to connection settings for that name (we'll call that eth_rpc info). In the dappfile, we specify environments (sets of objects) for each chain name. So in the context of a dappfile, an environment is named after its chain.
The key is that the "name" is sufficient to determine whether you're talking to the right chain, and the connection info is a dev environment happenstance.
Not sure this is a degree of freedom worth adding.
Agreed.
What do you intend to achieve by using block hashes as chain names? Are the block hashes supposed to indicate the block from which to fork an internal chain? And then connection info associated with a block hash indicates how to pull in the chain state? Or...?
I meant by the genesis block hash, or some other unique chain identifier. The ideal theoretical scenario is for every single chain to just have a name like "morden", which is globally unique and unambiguous but human-readable. The genesis block hash achieves the same thing semantically. Just the first 8 characters could also work.
Point is each environment lives inside just one chain, right now dapple does not have enough information to stop you from somehow using an address for the objectively wrong chain if you configure your connection improperly in dapplerc.
Okay, I understand what you're asking for now. That sounds like a good goal to me.
The map could just consist of setting keys to string values, which is something we already do for aliasing environments in .dapplerc. (I.e., it's possible to have an entry like live: default which makes live an alias for default.) Not sure how I feel about assigning those kinds of semantics to object keys, though. Might be better to have a required genesisHash property instead.
As for what to call the two well-known chains, perhaps it would be better to use the more straightforward terms testnet and mainnet (instead of morden and the obviously ambiguous term ethereum)?
If we want to anticipate the testnet getting replaced by a new testnet in the future, perhaps we could use the term testnet-morden instead of testnet? Maybe even mainnet-ethereum instead of mainnet; then people can use the naming convention testnet-foo and mainnet-foo for other chains as well.
environments:
default:
mainnet-ethereum: internal
testnet-morden:
ethrpc: localhost:8546
ipfs: localhost:5001
mainnet-ethereum:
ethrpc: localhost:8545
ipfs: localhost:5001
Just thinking out loud, basically.
My opinion on this: To make each configuration future and individuality proof, I think we have to abandon the notion of named environments in the context of packages: Imagine a dappfile like this:
...
environments:
test:
objects:
omfgContractSystem:
class: ABC
address: 0x1122..ff
with the current .dapplerc settings:
...
environments:
test:
ethereum:
host: 127.0.0.1
port: '8545'
The current dappfile is submitted as a package as it is. However, your notion of test environment might not be my notion of it and we would have a misconception of which chain we actually mean.
I propose to use the genesis hash + (block-height + block-hash) to identify the current environment in a package.
The genesis hash can be used to locally identify a chain environment in O(1). The block-height + block-hash of the last interaction relevant to the package is needed in case of several forks with the same genesis block and would be used optionally as a security lookup.
The local .dapplerc would then look like this:
environments:
test:
ethereum:
genesishash: 0xffee..00
host: 127.0.0.1
port: '8545'
The dappfile would keep its format. However, the package don't have a notion environments and would look like this:
...
chains:
"0xffee..00":
blockheight: 612345
blockhash: 0xabcd..10
objects:
omfgContractSystem:
class: ABC
address: 0x1122..ff
In case environments on packages are still needed, they can be placed under each chain
It does seem like it would be good to use unambiguous information like what @mhhf suggested (genesis hash, etc.) in the package descriptions that get published to the registry...
I agree that chain identifying info should ship with environments. If anything, the local config should map hashes to aliases and not vice versa.
(also please use eth_rpc instead of ethereum to mean "eth node connection settings", it's much less confusing)
If only the ethereum mainnet had a code name
Something like "midgard" would have been good