FAQs
Last updated
Was this helpful?
Last updated
Was this helpful?
This page contains answers to common questions about Etn-sc. Source code and README documentation can be found on the Etn-sc . You can also ask questions on server or keep up to date with Electroneum on . Information about Electroneum in general can be found at .
IPC stands for Inter-Process Communications. Etn-sc creates a etn-sc.ipc file on startup that other processes on the same computer can use to communicate with Etn-sc. RPC stands for Remote Procedure Call. RPC is a mode of communication between processes that may be running on different machines. Etn-sc accepts RPC traffic over HTTP or Websockets. Etn-sc functions are invoked by sending requests that are formatted according to the RPC-API to the node via either IPC or RPC.
This may be because your clock has fallen out of sync with other nodes. You can like so:
Etn-sc uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow instructions.
--password command line flag, I get the error "Could not decrypt key with given passphrase" but the password is correct. Why does this error appear?Especially if the password file was created on Windows, it may have a Byte Order Mark or other special encoding that the Etn-sc doesn't currently recognize. You can change this behavior with a PowerShell command like:
Additional details and/or any updates on more robust handling are at .
Many people assume that because they have the blocks, they are in sync. Unfortunately this is not the case. Since no transaction was executed, we do not have any account state available (e.g. balances, nonces, smart contract code, and data). These need to be downloaded separately and cross-checked with the latest blocks. This phase is called the state trie download phase. Snap sync tries to expedite this process by downloading contiguous chunks of state data, instead of doing so one-by-one, as in previous synchronisation methods. Etn-sc downloads the leaves of the trie without the intermediate nodes that connect the leaves to the root. The full trie is regenerated locally. However, while this is happening, the blockchain is progressing, meaning some of the regenerated state trie becomes invalid. Therefore, there is also a healing phase that corrects any errors in the state trie. The state sync has to progress faster than the chain growth otherwise it will never finish.
Etn-sc can also be synced with --syncmode full. In this case, Etn-sc downloads and independently verifies every block since genesis in sequence, including re-executing transactions to verify state transitions. Although Etn-sc verifies every block since genesis, the state of 128 blocks only are stored in memory.
In the Electroneum Smart Chain mainnet, there will be over 4 million accounts already (once everybody in my.electroneum.com has migrated to the smart chain), which will track the balance, nonce, etc of each user/contract. The accounts themselves are however insufficient to run a node, they need to be cryptographically linked to each block so that nodes can actually verify that the accounts are not tampered with.
This cryptographic linking is done by creating a tree-like data structure, where each leaf corresponds to an account, and each intermediary level aggregates the layer below it into an ever smaller layer, until you reach a single root. This gigantic data structure containing all the accounts and the intermediate cryptographic proofs is called the state trie.
The trie data structure is an intricate interlink of hundreds of millions of tiny cryptographic proofs (trie nodes). To truly have a synchronised node, you need to download all the account data, as well as all the tiny cryptographic proofs to verify that no one in the network is trying to cheat you. This itself is already a crazy number of data items.
The part where it gets even messier is that this data is constantly morphing: at every block (roughly 5s), about 1000 nodes are deleted from this trie and about 2000 new ones are added. This means your node needs to synchronise a dataset that is changing more than 200 times per second. Until you actually do gather all the data, your local node is not usable since it cannot cryptographically prove anything about any accounts. But while you're syncing the network is moving forward and most nodes on the network keep the state for only a limited number of recent blocks. Any sync algorithm needs to consider this fact.
Light sync relies on full nodes that serve data to light clients. Historically, this has been hampered by the fact that serving light clients was turned off by default in Etn-sc full nodes and few nodes chose to turn it on. Therefore, light nodes often struggled to find peers.
The current default syncing mode used by Etn-sc is called . Instead of starting from the genesis block and processing all the transactions that ever occurred (which could take weeks), snap sync downloads the blocks, assuming state transitions to be correct. Downloading all the blocks is a straightforward and fast procedure and will relatively quickly reassemble the entire chain.
Read more about Merkle Tries in general and the Electroneum state trie specifically .
Updating Etn-sc to the latest version simply requires stopping the node, downloading the latest release and restarting the node. Precisely how to download the latest software depends on the installation method - please refer to our .
Etn-sc stores the Electroneum Smart Chain state in a . It contains (key,value) pairs with account addresses as keys and and encoded account as the value, where an account is an array containing essential account information, specifically: nonce, balance, StorageRoot and codeHash. Definitions for these parameters are available in the Ethereum whitepaper. However, Etn-sc's state trie does not use the keys directly, instead account information is indexed using the SHA3 hash of the key. This means that looking up the account information for an address can be done by traversing the trie for sha3(address), but querying addresses that contain certain data is not possible - the addresses themselves are not part of the trie. This problem is solved using preimages - these are mappings of addresses to their hashes. Etn-sc generates these preimages during block-by-block sync as information is added to the trie but they are deleted once they reach a certain age (128 blocks by default). To retain the preimages, Etn-sc should be started with --cache.preimages=true.