e-money journal

Today I started poking around with e-Money. For those who have never heard of it: it is crypto money, and is behind several European stablecoins like eEUR, eCHF, eSEK, eNOK, eDKK. Here’s the project roadmap.

Since this is a largely tech blog, I don’t intend to go into financial & other social aspects of crypto money in general & e-Money in particular. This (forever-WIP) post is only intended as an “informal diary” noting down what I’ve learned while diving into this project. I’ll also be upfront and state that my 1st intention is to successfully run a validator node for the e-Money blockchain.

I also intend to write this post/series for myself and other application developers / DevOps engineers already having basic blockchain knowledge, and so I won’t be explaining terms and definitions from the ground up. I’m happy to point you to resources where you may learn more, so if anything here catches your interest & curiosity, please feel free to leave a comment.

Now without any further ado, I’ll start the (very draft & blunt) journal. From this point on, you’ll find fewer of the English fine-tuned paragraphs, and more of cryptic scripts written in programming languages.

All info below is standing Nov 2021 (except otherwise noted).

cosmovisor

If using cosmovisor, you may also specify the cosmovisor/ directory under the home directory of the cosmos project, e.g. ~/.emd/cosmovisor – read more here

emd config

Assuming we’re using the default emd homedir (~/.emd), then

• The main config file location is at the location: ~/.emd/config/config.toml
• The app config file location is at the location: ~/.emd/config/app.toml
• The client config file location is at the location: ~/.emd/config/client.toml

The cli to show the config: emd config – so yes, if you enter a value for e.g. the chain-id property in the client config file (mentioned above), its value will reflect as such when you run emd config

When running emd with cosmovisor, specifying the homedir for emd itself and for cosmovisor are 2 different things, and should be done separately, e.g.

DAEMON_HOME=/opt/emd/emoney-3/.emd/ cosmovisor config --home /opt/emd/emoney-3/.emd/

As seen from the above command:

• DAEMON_HOME=/opt/emd/emoney-3/.emd/ : this sets the homedir for cosmovisor
• --home /opt/emd/emoney-3/.emd/ : this sets the homedir for emd itself
• cosmovisor config : this is just the command being run (via cosmovisor) and can be anything else (e.g. start or help, so on & so forth)

Gotchas’

emd unsafe-reset-all can be useful when your configuration change doesn’t take effect. Of course, as the name implies, this is a dangerous operation, and should only be used as a last resort.

binary Upgrades in practice

If we install 1.1.3 and then join lilmermaid-16 & sync with its genesis, at some point we’ll run into this panic:

DAEMON_HOME=$HOME/.emd cosmovisor start --x-crisis-skip-assert-invariants --log_level warn
5:35PM ERR BINARY UPDATED BEFORE TRIGGER! UPGRADE "upgrade-plan-1" - in binary but not executed on chain
panic: BINARY UPDATED BEFORE TRIGGER! UPGRADE "upgrade-plan-1" - in binary but not executed on chain

This is because (obviously) our binary was “upgraded” way before it was supposed to be. The trick is to do exactly as instructed: putting the correct binaries in the correct directories managed by cosmovisor. Then start the process again (with cosmovisor – of course) and let things be taken care of automatically for you.

5:45PM ERR Error dialing peer err="dial tcp 3.68.159.237:30656: i/o timeout" module=p2p
5:45PM ERR UPGRADE "upgrade-plan-1" NEEDED at height: 12670:
starting to take backup of data directory at time 2021-11-08 17:45:01.563909605 +0000 UTC m=+5.306000545backup saved at location: /home/ubuntu/.emd/data-backup-2021-11-8, completed at time: 2021-11-08 17:45:02.384214233 +0000 UTC m=+6.126305179
time taken to complete the backup: 820.304634ms5:45PM ERR dialing failed (attempts: 1): dial tcp 45.33.102.106:26656: connect: connection refused addr={"id":"98171ae2eb5d58dfad7d5b504427ab5b6b6d0d26","ip":"45.33.102.106","port":26656} module=pex

So, apparently cosmos blockchain applications have binary version management done on-chain itself. This feature probably was initially introduced to prevent hard forks.

Alternatively, I also succeeded at doing “drop-in replacement” upgrades. This means we may just build out a new binary (or even more conveniently, copy the pre-built binary from emd v1.1.4 onwards) and place it in wherever the existing emd executable is installed. As usual, be very explicit about the DAEMON_HOME and --home options that apply when you run your executable.

beware of gas fees

Now this is generic for most blockchains (I believe), but I stumbled on it while playing around with the e-Money network, so I bundle it in this post.

Say if you’re making a call e.g. emd tx staking create-validator where you want to attach 10 NGM (10ungm) as the initial stake amount, and you only have exactly 10 NGM in your wallet. You’ll expect that the call will fail, because obviously you don’t have enough NGM to cover both the attached money & the gas fee combined, correct?

Yes, the call will definitely fail. But that’s not the only thing. Look at your wallet again. It’s less than 10 NGM now. That means: your call failed, you didn’t get what you wanted, but you still lost some NGM. The gas fee was paid to the “system” just to acknowledge that “hey you don’t have enough money to perform this transaction”.

Moral lesson: if you’re making a call to which you want to attach some amount of NGM, make sure not to attach 100% of all the NGM you currently have in your wallet. The call will fail and you will still lose money.

is that All?

For now, yes. I’ll update this post if/when I find more noteworthy stuff. Hope this helps. Cheers!