Solidity – Storing String Value in Solidity Efficiently

The compiled code doesn't know anything about the names of the enum elements. You can prove this by arbitrarily changing their names and compiling with solc --bin, and you'll see that they make no difference to the compiled code. So no, you can't get them by calling the contract.

You could of course add a separate mapping to the contract hard-coding that if asked for "two" it should return Numbers.two and vice versa, but you'd have to pay gas to carry this extra data when you deployed the contract.

The simplest thing is usually just to maintain a copy of the enum mapping wherever you need to call it, eg if you access the contract from a JavaScript DApp, keep a copy of the enum mappings in your JavaScript.

An IPFS address consists, in reverse order, of a hash of the data, the length of the said hash, and an identifier to tell you what algorithm is being used for the hashing. The algorithms in wide use produce hashes 32 bytes long. This is then encoded into a base58 string.

To store this efficiently you should undo the base58 encoding to get bytes. You shouldn't need to store the data length since it is implied by the version, so you need 32 bytes, plus a way to know the version. 32 bytes fits exactly into an EVM storage slot.

The 32 byte hash is effectively random, so you shouldn't expect to be able to compress it any smaller, and even if you could it may not help you because often you'd still end up using a 32-byte storage slot. If storage is very tight, you may choose to ignore the version identifier and just require that everybody use sha2-256, which is the current de-facto standard. If you need future-proofing, you may need an additional variable for this.