One round of proof reading

smondet commented 4 years ago

Some comments/questions from a first read (will be testing next):

why base off of babylonnet and not a setup like master (multi-network node)?
setting the genesis block hash is useful to have a ≠ chain-id
- and using the multinetwork-node also makes that easier (genesis block in the config file)
- “Also, nodes from different chains shouldn't be able to communicate with each other.”
  → The P2P network id should also be changed (again, it's easier with the MN-node)
OOC why the MPL license?
the dictator key can be kinda forgotten, but the bootstrap bakers may need to redeploy after crash or whatever: key management should be more explicit & documented.
Non-dictators should not need the patched binaries as long as they share the genesis block and use the same protocol hashes (just changing the dictator key does not change the protocol-hash that is exposed to the node by “compiled-in” protocols)
- we ran labnet nodes from the master branch (multi-network)
note that that parameters.json is babylon-specific
it's important to document a bit how the parameters work or not together
- e.g. if bootstrap accounts don't have enough funds to cover all the block and endorsement security deposits before the rewards start kicking in the chain can stop (it's maybe worth giving a few mullion tez to a non-baker bootstrap account for emergencies).

rvem commented 4 years ago

Non-dictators should not need the patched binaries as long as they share the genesis block and use the same protocol hashes

Am I right that genesis key is used only for protocol activation? So that, the non-dictators can simply reuse chain config JSON file provided by a dictator using multinetwork node and --config option?

rvem commented 4 years ago

I've just tested running modified (with custom genesis key) tezos-node and tezos-node built from raw master sources using the same --config (based on carthagenet), and it seems that they cannot communicate as a peers, failing with something like:

Feb 14 12:48:03 - validator.peer: Worker crashed [validator-peer_1]:
Feb 14 12:48:03 - validator.peer: (Invalid_argument "Json_encoding.construct: consequence of bad union")

rvem commented 4 years ago

Also, AFAIU, it is impossible to provide a genesis block hash in the config.json which is not presented in this file. The error is the following:

tezos-node: Error:
              Invalid configuration file: at /network:
              No case matched:
              At /genesis/block:
                Unhandled error (Failure "Unexpected data (block_hash)")
              Unexpected object instead of Sandbox
              Unexpected object instead of Zeronet
              Unexpected object instead of Alphanet
              Unexpected object instead of Mainnet
              Unexpected object instead of Babylonnet
              Unexpected object instead of Carthagenet

gromakovsky commented 4 years ago

OOC why the MPL license?

We feel that this license provides the best balance between Apache 2.0 (“do anything you want, as long as you include the copyright notice” and GPL (“if you use our code, you have to use GPL for your own code too”) as it allows the user to choose any license, including a proprietary one, for the code that they write, but requires them to publish any changes that they make to your code. We usually use this license by default.

Apache License probably is the best choice for wider adoption, as it doesn’t place any limitations on the use of your code other than “include our copyright notice when redistributing”. On the other hand, allows anyone to take your code, make improvements to it and leave them to themselves without contributing back, and thus, arguably, is not ideal for the development of the ecosystem, as companies benefit from what you create without having the responsibility of giving back to the community.

We think this repo is useful for the development of the ecosystem.

gromakovsky commented 4 years ago

why base off of babylonnet and not a setup like master (multi-network node)?

We are updating to master in #6.

vlietz commented 2 years ago

I've just tested running modified (with custom genesis key) tezos-node and tezos-node built from raw master sources using the same --config (based on carthagenet), and it seems that they cannot communicate as a peers, failing with something like:
Feb 14 12:48:03 - validator.peer: Worker crashed [validator-peer_1]:
Feb 14 12:48:03 - validator.peer: (Invalid_argument "Json_encoding.construct: consequence of bad union")

Are there any news regarding this error?

serokell / private-tezos-blockchain

One round of proof reading #5