According to some embodiments, the recovery private key 205 is sent by the at least one first computing device 210 to the recovery escrow service 230 for storage, for instance via SSH-FTP. The recovery escrow service 230 may store the recovery private key 205 while the at least one first computing device 210 and the at least one second computing device 220 communicate with the computer network 201 (e.g., carry out a transaction in a blockchain based network). It should be noted that the information stored at the recovery escrow service 230 may be substantially small (as its purpose is not to fully replace the functionality of the at least one first computing device 210), for instance a single decryption private key, while it may be used for the recovery of keys of many users, that in turn may hold many different keys. The stored information may also be static without the need to be updated with respect to changes in user details (e.g., such as adding users, removing users, changing keys, etc.), thereby allowing, for example, an efficient solution in storage and communication by the recovery escrow service 230 (e.g., implemented as a software). It should be noted that the recovery escrow service 230 may not hold the client private keys (e.g., storage of private key may not be static and/or substantially small), for instance the recovery escrow service 230 may not hold private keys of at least one second computing device 220, so that the recovery escrow service 230 may not take advantage of data of the at least one second computing device 220 in order to, for example, block access to private data (or financial assets related to the blockchain network) in case the recovery escrow service 230 goes rogue and/or being maliciously hacked.