Comment on page
- When running the command
docker compose --profile fullnode upon Windows, I encounter the error “kroma-geth | /.kroma/entrypoint.sh: set: line 2: illegal option”. How can I resolve this issue?
- When cloning text files from git on Windows, line endings are automatically set to CRLF (\r\n), while Unix/Linux uses LF (\n) as line endings. This difference in line endings can cause a syntax error in the environment file written and committed on Unix/Linux. To fix this error, follow these steps:
git config --global core.autocrlf false
- 2.Clone the kroma-up git repository again:
git clone https://github.com/kroma-network/kroma-up.git
- 3.Change to the kroma-up directory:
- 4.Run startup script:
- 5.Run sync_block script:
- 6.Start the node:
docker compose --profile fullnode up -d
- Does Kroma node work on ARM64 architecture?
- Yes, Kroma node runs in a docker container, so the architecture should not be an issue.
- Do I need to open any inbound ports?
- No, there is no need to open any inbound ports. The P2P connections between a geth and a node run by Kroma Foundation are automatically set up when you first start your nodes.
- I made some mistakes in the configuration, and even after fixing them, my node keeps dying. What should I do?
- After changing any configurations in the
.envfile, make sure to kill and restart the node for the changes to take effect.
- The syncing process takes too long. Are there any snapshots available?
- Yes, the
./sync_block.shcommand is provided in the kroma-up git repository when you clone it. A new snapshot is uploaded daily at 00:00 UTC. If you sync with the snapshot, it should take at most 4 hours with a normal internet connection.
- What are the penalties on Kroma? Are there any downtime penalties or risks of double-signing?
- Double-signing is not possible on Kroma validators since only the sequencer generates the blocks, not the validators, and there is only one sequencer on Kroma currently.
- However, there are penalties for other cases, such as:
- Submitting an invalid checkpoint output: If you submit an invalid checkpoint output, it will be challenged by other validators, and your bonded ETH will be slashed and given to the challenger if they win the challenge.
- Downtime penalties: If you win the assertion priority for a round but do not submit the checkpoint output within 10 minutes, your reward for the output submission linearly decreases over the next 20 minutes. After 30 minutes, your assertion priority is revoked, and any validators can submit the checkpoint output for the round. The first validator to submit the checkpoint output during this public round will receive the reward when the output is finalized. For more information, refer to this medium article.
- Will there be a remote signer system for the validator with an X key split to allow for the possibility of a machine being shut down due to an incident?
- No, there is currently no remote signer system, but it might be considered in the future.
- Could you add a section on the disaster recovery process in the event of an incident on the main machine?
- No, there is no section for the disaster recovery process at the moment, but it might be considered in the future. However, Kroma has its own disaster recovery process for the Kroma’s sequencer node, ensuring block generation on L2 is guaranteed under any circumstances.
- How much ETH should I deposit into the validator node to avoid missing any raffle for the assertion priority?
- The required deposit amount depends on the number of validators on Kroma. For example, if there are 24 running validator nodes:
- 24 checkpoint outputs are required to be submitted daily.
- Assuming it takes 168 hours for a checkpoint output to be finalized.
- In this scenario, the following steps would allow you to run the validator node indefinitely without worrying about missing the assertion priority raffle.
- 1.Deposit ETH of minimum bond amount X 7 + gas fees to the validator wallet address
- 2.Deposit ETH of minimum bond amount X 7 to the validator pool
- The requirements for the machine for kroma-prover are very high. What is the estimation of how long the machine should run per month?
- The machine's runtime per month is dependent on the number of invalid outputs submitted, which, in turn, depends on how many malicious validators participate in the network. As of now, it is challenging to estimate accurately. However, based on similar cases like Arbitrum, we expect few or no invalid outputs as they can be easily detected by honest nodes.