Protocol Walkthrough

Upon running the harmony build, the following logic is triggered:

• getHarmonyConfig initializes the HarmonyConfig with the given flags
• setupNodeAndRun
• Sets the shard schedule based on its respective network (Mainnet, Testnet, etc.)
• Assuming the node type is validator, setupStakingNodeAccount is run
• setupStakingNodeAccount
• Loads BLS keys and set the keys to config
• Retrieve the Shard ID statically determined from the consensus key
• Ensure the keys are all in the same shard
• Append each key to initialAccounts which are the accounts used when the build is initially deployed
• Create nodeconfig.ConfigType which is the configuration variables for a node off of the HarmonyConfig previously configured
• Update each network id to be compatible with the Ethereum chain id (Why?)
• setupConsensusAndNode
• Set up blacklisted addresses, allowed transactions, and local accounts
• Set up database factory
• Set up engine which contains:
• Epoch context cache
• Verified signature cache
• Create a new shard chain collection with the db factory and the engine
• Create the blockchain for the current shard (beacon shard has to be initialized regardless)
• Create a new consensus with the deciders and provided configuration
• Create a new node with all of the above information node.New()
• Creates a node that represents a protocol-participating node in the network
• Instantiate syncing providers by following rules:
• If starting with a localnet or offline, use local sync peers.
• If specified with --dns=false, use legacy syncing which is syncing through self-discover peers.
• Else, use the dns for syncing.
• InitConsensusWithValidators initialize shard state from latest epoch and update committee pub keys for consensus
• Set block verifier, which is a function to verify the block (account model) they are running consensus on