Edit ganache-cli launch parameters, enigma-contract docker image

I want to give feedback that would really help DApp developers out there.

It would be great to give out a way to launch ganache-cli with a pre-set seed.

As I have found out, you launch ganache-cli via launch_ganache.bash inside enigma-contract docker image. But your default parameters are:

ganache-cli -d -p 9545 -i 4447 -h

Is there some other way to edit these parameters without editing the docker image?



After building a custom docker image from your enigma-contract image using as a dockerfile:

   FROM enigmampc/enigma_contract

   COPY launch_ganache.bash /root/launch_ganache.bash

Pointing to a modified launch_ganache.bash with the following parameter:


And overriding docker-compose.yml files at the root directory of a ‘discovery init’ created folder with the new image name, I get the following error after the successful deployment of the enigma ethereum contracts:

more content above here
contract_1  | Summary
contract_1  | =======
contract_1  | > Total deployments:   10
contract_1  | > Final cost:          0.32704728 ETH
contract_1  | 
contract_1  | root@contract:~# GET / HTTP/1.1
contract_1  | Host: contract:8081
contract_1  | User-Agent: curl/7.58.0
contract_1  | Accept: */*
contract_1  | 
contract_1  | GET / HTTP/1.1
contract_1  | Host: contract:8081
contract_1  | User-Agent: curl/7.58.0
contract_1  | Accept: */*
contract_1  | 
km_1        | [+] Home dir is /root
km_1        | [+] Home dir is /root
km_1        | [-] Create .enigma folder => AlreadyExists
km_1        | [-] Create .enigma/epoch folder => AlreadyExists
km_1        | [-] Create .enigma/state-keys folder => AlreadyExists
km_1        | The current directory is /root/enigma-core/enigma-principal/bin
km_1        | [-] Open token file /root/.enigma/enclave.token error! Will create one.
km_1        | Loading Principal config: "../app/tests/principal_node/config/principal_test_config.json"
km_1        | [+] Home dir is /root
km_1        | Back from Ocall: /root/.enigma
km_1        | Succeeded reading key from file
km_1        | [Mode:] run node NO DEPLOY.
km_1        | Connected to the Enigma contract: "aA6d9E1A1FF7Fb540E3b7B968637dd69a1a02dc3" with account: 0x1df62f291b2e969fb0849d99d9ce41e2f137006e
km_1        | [+] Home dir is /root
km_1        | No existing epoch state, starting with block 0
km_1        | Fetching the signing address for account: 0x1df62f291b2e969fb0849d99d9ce41e2f137006e
contract_1  | eth_call
km_1        | Using SGX_MODE: "SW"
km_1        | Fetching quote with SPID: "B0335FD3BC1CCA8F804EB98A6420592D"
km_1        | Simulation mode, using quote as report: AgAAAAsAAADvAO8A7+/v77AzX9O8HMqPgE65imQgWS14gD/Vn5d1i8F+adCaMZvQSCDzN2rmsvIDTTt6S0ineAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAADAAAAAAAAALWi+zqwTS0baXkBzX1MEM1dW7b/2VK60Uyy7NaRhTHZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACD1xnnferKFHD2uvYqTXdDA8iZ22kCD5xw7h38CMfOngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABM/pz5FwMOp0kYI5njESIMxsLPWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAIAAO7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7o3yo4kfkrJr5rzQVmgBAADu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u5rURzatCe1ty2+7MAHoQNq
km_1        | Registering worker
contract_1  | eth_sendTransaction
km_1        | thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Web3Error { message: "Unable to call register: Error(Rpc(Error { code: ServerError(-32000), message: \"sender account not recognized\"

How do I proceed from here to use a custom mnemonic defined by me?


Hey @joao.l.martins, thanks for the post – what’s the motivation for custom mnemonics in this instance?

Hi @ainsley ! Thanks for answering. In fact that is a great question, I think my motivations were purely security related, as the deterministic mnemonic is known by everyone else, but it is not a great deal at all to use it for test purposes. But I guess I can edit other parameters, such as block time to put it slightly more realistic (e.g. 3 seconds?)

I take this opportunity also to ask another different question. I have looked into your tutorials regarding the millionaires problem secret contract implementation and dapp creation, but I think I am missing the piece on how can a smart contract call a secret contract function or vice-versa.

Imagine at the end of an auction I have an array of encrypted bids in my ethereum smart contract and I need to compute the auction winner. How can the secret contract send the result of the computation (winner and winning bid) to the smart contract? Is this made via enigma.js?


@ainsley & @can any updates regarding the aforementioned tutorial for Smart Contract <-> Secret Contracts calls? The only info I can find is at the end of the voting example here https://enigma.co/discovery-documentation/SecretContractExamples/

    let voting_eth_addr: String = Self::get_voting_eth_addr();
    let c = EthContract::new(&voting_eth_addr);
    c.validateTallyPoll(poll_id, tallied_quorum);


Hey @joao.l.martins
First of all, thanks for your patience. We’ve implemented a new support ticket tracking sysem so hopefully we are more timely in the future :).

To clarify: a secret contract may call a function in a smart contract (but not vice versa, at this time).

As you note, that’s demonstrated in the voting example you selected. We don’t have a tutorial yet for this, but it’s a good idea for something we should have.

To dig into your example a little…

Imagine at the end of an auction I have an array of encrypted bids in my ethereum smart contract and I need to compute the auction winner.

Is this array in the smart contract, or the secret contract? The way I would do this is have users encrypt their bids locally using Enigma-JS, then submit those bids to the secret contract directly.

Then, the secret contract can call an ethereum smart contract function with the winner and the amount, in the same fashion as its shown in the voting example.

How are you thinking of accounting for deposits i.e., that the “winning bidder” is obligated to send funds after winning? A deposit contract on ethereum?

Thanks for answering @ainsley

Yes, in my idea/example I was planning to store the encrypted bid’s array in the Smart Contract until the end of the auction and only at the end send it to the Secret Contract for computation.

This way, I was accounting for deposits in the act of bidding by having users sending a ‘fake’ bid together with their ‘true’ encrypted bid.

This fake bid must be a higher value than the encrypted bid and is deposited within a deposit contract in Ethereum. At the end, the winner would receive the difference between the ‘fake’ and the ‘real’ bid.

I find however your idea of encrypting the bids locally via Enigma-JS and sending them directly to the secret contract more interesting and would solve the impediment of Smart Contract functions not being able to call Secret contract functions right now. The problem is how I would account for the bid deposit at the act of bidding? Making it mandatory too to send a ‘fake’ bid higher than the ‘encrypted’ bid that was sent directly?


I forgot I should add more details about the kind of auction system I am trying to implement.
Essentially it is a reverse auction system, in which buyers commit to a maximum pre-defined value and suppliers have to bid in a price-descent manner, starting at the agreed maximum. The intention of the deposit commitment by the suppliers (the winner) would be a value that binds him to fulfill the buyers’ order, could be let’s say a percentage of the total order’s value (which would be calculated with the winning bid). Only the winner would pay this fee.

Two solutions I was thinking right now:

  • Solution A: No commitment is made by the suppliers before the winner computation. Bids are encrypted n Enigma-Js and sent to the Secret Contract. When the Enigma Secret Contract makes a callback with the list of suppliers and their bid values, there is a timer in which the winner has to commit the ‘winning fee’ to take the buyers’ order, else if he fails to do it on time, the burden passes to the second lowest bidder and so on…

  • Solution B: The suppliers encrypt their ‘participation fee’ with enigma-js and store it both on the smart contract and on the secret contract. At the same time they store it in the smart contract they commit a participation fee calculated with the ‘fake bid’ I explained in the previous reply. When the secret contract makes a callback to the smart contract there is a verification of the equality of the winner’s encrypted bids in both contracts. If this holds true the participation fee is deducted from this supplier. If this check fails in due time the test passes to the second lowest bidder and so on…

Let me know if you would like a better explanation of this system, but I think this gives a better overview than before (it is not a typical price ascending auction).


Hey @joao.l.martins – how is it going? Anything we can help with here?

Hey @ainsley

Internally we have decided to explore the commit-reveal scheme for the blind bids using only Ethereum, as depicted in the example here: https://solidity.readthedocs.io/en/v0.5.14/solidity-by-example.html#id2

We will however re-explore the usage of Enigma to achieve this (and other privacy needs) of our dApp, especially when it achieves mainnet release status, as we start to optimize more finely the transaccional and scalability problems of the dApp.

Thanks for reaching out, i’ll keep in touch via this thread in the future.

1 Like