You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, es-node mixes build-time artifacts (the snarkjs folder) with runtime artifacts (the zkey files). This causes an awkward situation for deterministic builds which produce a read-only folder derivation, such as with the Nix package manager. Here, the zkey files cannot be placed under the snarkjs folder unless the zkeys are downloaded during the build process. Bundling the zkeys with the package would balloon the derivation size by additional 550MB, which makes it hard to distribute.
What are the use-cases?
By allowing the zkeys to reside in some other folder, one could have e.g. a systemd script which ensures that the files are in the directory, while still using the build-time artifacts for snarkjs.
Implementation
Do you have ideas regarding the implementation of this feature?
Separate the --miner.zkey from utilizing --miner.zk-working-dir, and instead of a single file name, allow an absolute or relative path to be configured for it.
Are you willing to implement this feature?
No, I currently do not have the bandwidth to make the changes.
The text was updated successfully, but these errors were encountered:
Rationale
Why should this feature exist?
Currently,
es-node
mixes build-time artifacts (the snarkjs folder) with runtime artifacts (the zkey files). This causes an awkward situation for deterministic builds which produce a read-only folder derivation, such as with the Nix package manager. Here, the zkey files cannot be placed under the snarkjs folder unless the zkeys are downloaded during the build process. Bundling the zkeys with the package would balloon the derivation size by additional 550MB, which makes it hard to distribute.What are the use-cases?
By allowing the zkeys to reside in some other folder, one could have e.g. a systemd script which ensures that the files are in the directory, while still using the build-time artifacts for snarkjs.
Implementation
Do you have ideas regarding the implementation of this feature?
Separate the
--miner.zkey
from utilizing--miner.zk-working-dir
, and instead of a single file name, allow an absolute or relative path to be configured for it.Are you willing to implement this feature?
No, I currently do not have the bandwidth to make the changes.
The text was updated successfully, but these errors were encountered: