OpenSSL dlopen causes panic on NixOS

[jhvst]

Describe the bug
Running ssvnode on a system which does not have OpenSSL at expected library paths causes a panic. However, this issue is not raised during compile-time. It is thus possible to build ssvnode successfully, but the same environment may not be able to run it.

To Reproduce
Steps to reproduce the behavior:

1. Build ssvnode using the Makefile or e.g. Nix (see: ssvnode: 1.3.8 -> 2.0.0 nix-community/ethereum.nix#547)
2. Run ssvnode in a system which is unassuming of software libraries in the environment, such as NixOS. You will get an error saying that go has panicked because it cannot find OpenSSL. The error originates from here

Expected behavior
If the build succeeds, I expect to be able to run ssvnode as well without additional runtime libraries.

Screenshots
N/A

Node (please complete the following information):
N/A

Additional context
The issue can be fixed by e.g. patching the ELF header of the binary file produced with Go. This can be done with patchelf. For usage in this case, see the usage in my Nix derivation. I'm opening this issue for your consideration of being more particular of what version of OpenSSL is needed at runtime. It seems that as of now, there might be an implicit dependency of OpenSSL, but this is not apparent from any of the build files (Docker or the Makefile). Given the use of ssvnode e.g. in the Lido CSM, it might be worth it to being more particular which version of OpenSSL is required. As it stands now, the behavior of ssvnode in terms of how OpenSSL is used is dependent on the OpenSSL version that the Linux distribution ships with, which may vary and change between operating system upgrades.