Multiple nodes and missing txt file


I was curious if it was still possible to run multiple nodes on the network in the new release, I don’t see any option to do it.

I also had errors concerning the txt file containing the deployed contract address which is supposed to be created at migration. For example :

Deploying Secret Contract “simple_addition.wasm”…
Smart Contract “Sample.Sol” has been deployed at ETH address: 0x4cFB3F70BF6a80397C2e634e5bDd85BC0bb189EE
Completed. Final Task Status is 2
Secret Contract “simple_addition.wasm” deployed at Enigma address: 0x2822d89771ad2e375fcad20340901c716925c343a48e82a864d17274136f8a25
{ [Error: ENOENT: no such file or directory, open ‘…/test/simple_addition.txt’]
errno: -2,
code: ‘ENOENT’,
syscall: ‘open’,
path: ‘…/test/simple_addition.txt’ }

If a line to create the file and write the address within it not added in the deploy script, the tests fails. I’m running the discovery cli from the main directory.

Hi @chancla,

Right now in the current implementation it is not supported to run multiple nodes on the developer testnet because of a technicality with docker-compose and the way the environment is set up. The problem arises in that we are mapping a port from the p2p container to the host here (note that this file belongs to another repo, but that is the one that is fetched by discovery-cli when you run init). This port is the one that is configured in the enigma-js library as the “entrypoint” or “gateway” into the network. As we “scale” up the number of p2p containers, there is a clash in multiple containers trying to map the same port. You can see for yourself if you try something like the following in your project folder:

docker-compose up --scale core=3 --scale p2p=3
enigma_core_1 is up-to-date
enigma_core_2 is up-to-date
enigma_core_3 is up-to-date
enigma_client_1 is up-to-date
enigma_contract_1 is up-to-date
enigma_km_1 is up-to-date
WARNING: The "p2p" service specifies a port on the host. If multiple containers for this service are created on a single host, the port will clash.
Recreating enigma_p2p_1              ... done
Recreating 4564446edbb2_enigma_p2p_2 ... error
Recreating 460eddb0bfff_enigma_p2p_3 ... error

ERROR: for 460eddb0bfff_enigma_p2p_3  Cannot start service p2p: driver failed programming external connectivity on endpoint enigma_p2p_3 (6d2226599b0b3b7d25d5c821849b32141757166f1395dddf4269d26f2c9df280): all ports are allocated

ERROR: for 4564446edbb2_enigma_p2p_2  Cannot start service p2p: driver failed programming external connectivity on endpoint enigma_p2p_2 (909cffd49da8dbc0daf8651ada4e7dbe701a85c0f9ef328b32bbd81a9ced481d): all ports are allocated

ERROR: for p2p  Cannot start service p2p: driver failed programming external connectivity on endpoint enigma_p2p_3 (6d2226599b0b3b7d25d5c821849b32141757166f1395dddf4269d26f2c9df280): all ports are allocated
ERROR: Encountered errors while bringing up the project.

While this is a relatively common setup in docker-compose with scale, the solution is a bit more involved requiring a reverse proxy or a load balancer, as suggested here, but this gets somewhat out of scope of what we envisioned this CLI for, that is to provide a simple, yet fully functional setup aimed primarily at writing, debugging and testing secret contracts, where we limited the network to one node for the sake of simplicity. Given enough interest, we can implement this, but right now it’s not our immediate priority.

I have opened an issue here to track it, and I would propose that if we get say 15 :+1: there (on the Github issue, not on this forum thread) as a sign of community interest, I will make an effort to implement it.

1 Like

Regarding the error that you report of no such file or directory, open ‘…/test/simple_addition.txt’] there must be a misconfiguration in the relative paths.

I just checked and the file should be created here, so I would need to learn more about the specifics of your setup:

  1. Can you confirm that such a line is present in your migrations/2_deploy_contracts.js ?
  2. Can you confirm whether the file test/simple_addition.txt exists after you have run your migrations? or after the migrations run in the first part of your test ?
  3. Can you copy here the contents of your migrations/2_deploy_contracts.js file?


1 Like

Thanks for these clear explanations Victor.
Concerning the other .txt problem :

  1. This line is present however at migration it fails and goes into the error handler. If I remove the “…/” part of " …/test/", it succeeds.
  2. Since the call to fs.writeFile fails the file is not present after migration, after path modification the file is present.
  3. Here’s the content of the file :
    The only modification I made was to add the part to deploy the millionaires problem smart contract at the end.

I also have another error when running multiple times the command “discovery test”, the km_1 container seems to have an error and stop working and I have to restart the network afterwards. I’ve tried to copy the relevant log :

Ok, it seems is “just” a path issue. We did a fair amount of testing, and thought we got the paths right. I will do a bit more testing on my computer to get it working more consistently.

I would ask you that you open different threads for different issues, otherwise it is hard to keep track of them and for others to navigate the forum and find the relevant information.

Yes, there is an error on that file. The relevant line number is 335 and the error is

"Unable to call setWorkerParams: Error(Rpc(Error { code: ServerError(-32000), message: \"VM Exception while processing transaction: revert Invalid signature\",

I believe this error is triggered by an earlier event that brought things out of sync. The signature verification depends on the state being in sync, and that’s why it fails. We have an active issue on this front. For now, I suggest you restart the network when you see this error because at the present moment is unable to recover (but again, we are working on this).

1 Like

FYI, I have same issue and If I remove the “…/”, it succeeds.

I run discovery-cli with macOS X.

1 Like
  1. This line is present however at migration it fails and goes into the error handler. If I remove the “…/” part of " …/test/", it succeeds.

FWIW, I can confirm that I’m also running into this same issue on MacOSX 10.14.4, and the tests pass when I replace ../test/ in that path with test/.

Thank you all for you input on this issue. This issue has been addressed in, and a new version 0.0.20 has been released that includes the above changes. It will be fixed in any future installations.