Without using contracts, we could extend the Bank and Auth modules to use SGX (like we're extending CosmWasm), thus creating private accounts and payments.

• Review compilation process of helloworld rust program to SGX
  • https://edp.fortanix.com/docs/
• Compile a helloworld rust program/static library to SGX
• find and work around all uses of the filesystem in go-cosmwasm
• Apply to CosmWasm
• Add to Makefile
• Test a simple stateless contract deployment+execution
• Test a simple stateful contract deployment+execution

Initialization logic for the enclave. See the logic described here in Phase 2: https://forum.enigma.co/t/network-key-management-agreement/1324

• Reuven - Docs
• Reuven - High level code review
• Tom - Docs
• Tom - High level code review

So we can deploy nodes easily.

1. Compile the current mainnet release to Mac & Window.
2. Also add this to Makefile
3. Add docs on how to use enigmacli from any host by connecting to a full node

• Deploy faucet service
• Register domain names for faucet and bootstrap nodes (with help of @lacabra )
• Set up SSL certs
• Create a new reCaptcha keys
• Change to test keyring backend Change password to faucet account
• Update all in .env and .env.local
• Fix README and clean comments etc.
• Update dependencies to fix security vulnerabilities
• Upgrade to v0.1.0
• Write blog post

Cc @moonstash

• Write docs on using the docker image
• Build v0.0.2 and push to hub.docker.com

Fix docs to support running a full node behind NAT with port forwarding.
Also check about UPnP support.

Correctly setting laddr in enigmad config doesn't work for this use case.

Cc @moonstash

• Review docs flow from a new Enigma developer perspective

Dup of #64

Hi there,

I am running a seperate fullnode for RPC & LCD purposes

I have added in my SSL .crt & .key and even put them in the /config/ DIR & specified them in the config.toml
(My cert is from a CA - Comodo)

However it seems when there is a value in the cert & key options in the config I get no response on LCD from the https... and on http side i get this error.

http error:
{"error":"Status: error unmarshalling: invalid character 'C' looking for beginning of value"}

you can see on these two links it being reproduced.
https://172.105.11.162/node_info
http://172.105.11.162/node_info

Any info on this would be good. The reason i need SSL working is for swagger to connect over https. As its giving errors because it doesnt want to go from https -> http (lcd)

The SSL works fine for RPC, just not LCD..

Initialization logic for the enclave. See the logic described here in Phase 2: https://forum.enigma.co/t/network-key-management-agreement/1324

Same as #38, but with a contract that has state. This would require defining more in/outs between the enclave, CosmWasm Rust component and Go component.

Below is the user flow for Salad, Enigma's tool for transactional privacy.

1. Alice sends SCRT to be mixed - denomination amounts to be finalized but we can work with the assumption 100 SCRT, 1,000 SCRT, 10,000 SCRT and her locally encrypted recipient address to Salad secret contract
2. Bob and others follow steps 1)

On the Salad secret contract side, the following will happen:
3) check whether a quorum is reached after X blocks (currently 2 hours or ~12,000 block) and secret contract has the right amount of SCRT
4) If 3) is satisfactory, privately decrypt and shuffle all inputs (recipient addresses)
5) Return shuffled plaintext recipient addresses to the deposit contract for distribution of SCRT to new addresses

More details can be found in this post

Initialization logic for the enclave. See the logic described here in Phase 2: https://forum.enigma.co/t/network-key-management-agreement/1324

• CSPRNG
• KDF

When trying to install inside a docker container (ubuntu:18.04) (RUN dpkg -i enigmachain_0.0.2_amd64.deb) a few errors are encountered:

• logname: no login name
• /var/lib/dpkg/info/enigmachain.postinst: line 23: sudo: command not found

• Fork cosmwasm/wasmd, confio/cosmwasm & confio/go-cosmwasm
• Init wasmd as a module in our app
• Bump to v0.7.0
• Test simple deploy & execute
• Rename module from "wasm"
• Create a pre-release for testnet

Currently it's JSON, changing it to MessagePack or COBR could save a lot of gas and shouldn't be too hard to do.

https://forum.enigma.co/t/serialize-format-of-states/1384/2

See the logic described here in Phase 1 (register_validator()): https://forum.enigma.co/t/network-key-management-agreement/1324

The idea is to first develop an encryption free, state-free simple toy contract that runs inside of SGX.

In this task, we don't have to worry about an API of going in/out of the enclave - just to pull the WASM interpreter into the enclave and properly integrate a single in/out point from/to the enclave in CosmWasm.

This task sets the outline/interface of the bootstrap module. It should achieve the following:

• Have a registered validators key-value store. It should allow validators to be in one of (pending, registered) states
• Have a register_validator() tx handler to deal with new validators who join in
• Have a share_seed() tx handler to deal with the sharing of the encrypted seed value for a new validator
• Have a confirm_validator() tx handler to change a new validator from 'pending' state to confirmed state

Verify report signature on-chain (similar to how this worked in the Enigma Contract in Discovery/Ethereum). Needed as part of register_validator().

EDIT: Sorry, duplicate of #36

Initialization logic for the enclave. See the logic described here in Phase 1 (register_validator()): https://forum.enigma.co/t/network-key-management-agreement/1324

https://github.com/cosmos/cosmos-sdk/releases/tag/v0.38.1
cosmos/cosmos-sdk#5579

This will fix the enigmad start --pruning nothing issue we have right now, which can consume a lot of disk space.

While there is documentation on how to join a network as a validator, I have not been able to find information on how to properly stop being a validator. I would like to request adding the proper documentation for it.

Using the following command is supposed to display slashing info for a validator:

enigmacli q distribution slashes [validator-operator-address] [start-height] [end-height]

I tried with an enigmavaloper1... address that had a slashing event, but the command is returning:

null

This should overlay the existing implementation of CosmWasm as much as possible. The complexity lies with actually navigating between doing this inside of the enclave, and actually storing/fetching data that lives outside of the enclave (in the untrusted part of the validator).
We can make the following simplifying assumptions for encrypted state:

• keys are unencrypted - this allows searching in plaintext outside of the enclave. If someone wants to fully encrypt the state, they can have a single key that maps to a single encrypted dictionary
• Decrypting the existing state value with the previous tx_hash. Note: the unencrypted latest tx_hash (or whatever nonce we decide on) needs to be serialized and included with the stored value.

In set_state, need to do the opposite:

• Derive a new state encryption key using the master key and current tx_hash.
• Encrypt the data and serialize it, alongside the tx_hash
• Pass the unencrypted key in the key value store, alongside the encrypted bytes outside of the enclave for CosmWasm to store natively.

Experiment with CosmWasm client library. Integrate into our own tools. NOTE: this is subject to have breaking changes, so we should not spend too much time here right now.

Write docs on using the governance module:

1. How to create proposals
2. How to deposit
3. Deposits burn risk
4. How to vote, modify a vote and validator/delegator dynamic

“Dead-Man’s Switch” is a trigger for an event that occurs when an operator becomes incapacitated. Originally, the term described a physical switch that when released, caused a machine to stop running. Now the term also refers to software that asks a user to periodically “check-in”, and releases some information if the user fails to perform this check-in within a certain amount of time.

Below is the user flow for a deadman switch built on Enigma blockchain.

1. Alice initiates the secret contract that will act as the decentralized deadman switch by:

• storing encrypted secret (input) to the secret contract
• defining the recipient address of the secret (input)to receive the secret when the triggering event takes place
• defining triggering event - i.e. desired check-in interval (1 TX per month, year etc.) defined in number of blocks
• funding a bounty for the deadman switch to be called if desired check-ins don't take place

2. Alice "checks-in" - sends a transaction to the DMS secret contract Enigma network. Alice must repeat this within the specified interval.

3. Bob is able to submit a transaction to the secret contract. If Alice ceases to "check-in" within the specified interval, Bob would submit a transaction to the secret contract to reveal the secret and collect the bounty. Secret contract compares block numbers of Bob's transactions and Alice's last "check-in" transaction to the desired check-in interval.

4. If elapsed time is greater than the interval specified by the user, Bob receives the bounty and secret contract encrypts the secret with the recipient address Alice defined in step 1. (encrypted outputs).

See the logic described here in Phase 1 (register_validator()): https://forum.enigma.co/t/network-key-management-agreement/1324

Gave up after the validate-genesis step, though I might have set it up wrong, who knows. I gave up after trying once and just installed it in WSL instead (though that was also fun)

scrtlabs/enigma-p2p#313
https://github.com/enigmampc/discovery-wiki/wiki/Enigma-P2P

The idea for this task is to prepare a skeleton for the implementation of (register_validator and share_seed) functionalities, as well as any other API we need between a node and its enclave

Initialization logic for the enclave. See the logic described here in Phase 3: https://forum.enigma.co/t/network-key-management-agreement/1324

Initialization logic for the enclave. See the logic described here in Phase 3: https://forum.enigma.co/t/network-key-management-agreement/

A public ground for:

• Testing out new features
• Allowing different stakeholders to get a look and feel of what's going on (e.g., node runners can test their system; developers can test their contracts, etc..)

https://github.com/interchainio/tm-load-test

New nodes should not be able to start syncing blocks UNTIL they are confirmed as a registered node. We should look into InitChainer and EndBlocker.

New node

• register node
  • generate report for enclave
    Get quote - SafeTrace ref
  • using enigmad generate key pair inside of the enclave
  • seal + backup private key
  • handle loading of private key on node init
  • using IAS (proxy node) get report for public key (signed quote)
  • enigmacli send tx with public key as a param + report
  • bootstrap node handling (only happens for the first node)
    Initialization logic for the enclave. See the logic described here in Phase 1 (register_node()): https://forum.enigma.co/t/network-key-management-agreement/1324
    Check whether this can happen automatically inside the global InitChainer (also whether this can listen to new blocks and block execution until the new node is confirmed).

Existing nodes

• confirm node
  • get register_node() tx
  • pass (new_node_public_key, report) to the enclave
  • verify report locally (using hard coded intel's pub key)
    Discovery ref #1
    Discovery ref #2
  • take sk_io with new_node_public_key and derive a new symmetric key (using derive_key https://forum.enigma.co/t/input-output-state-encryption-decryption-protocol/1325)
  • encrypt seed with the new symmetric key from the previous step
  • return from the enclave with the encrypted seed
  • write the encrypted seed to chain
    Initialization logic for the enclave. See the logic described here in Phases 2+3: https://forum.enigma.co/t/network-key-management-agreement/1324

New node again

• register_node()
  • decrypt seed with pk_io and my private key (using derive_key https://forum.enigma.co/t/input-output-state-encryption-decryption-protocol/1325). With the single shared 256-bit seed generated above, we can run the CSPRNG several times to get other 256-bit pseudo-random keys:
  • First 256 bits: used to generate (sk_io, pk_io) --> a key pair whose pubkey can be used by users to derive new symmetric encryption keys for encrypting input/outputs. The protocol above needs to be changed so that the first validator also broadcasts pk_io to the network.
  • Next 256 bits: used to generate master_state_key --> a symmetric key used to encrypt contract state. In practice, this is a seed we can use to derive further keys.
  • Next 256 bits: used to generate master_iv --> this is a seed that can be used to generate fresh IVs for encrypting outputs. That’s how the network can avoid non-determinism and still maintain the security of symmetric ciphers.
  • Next 256 bits: used to generate master_rand_seed --> this is a seed that can be used to generate randomness.
  • check how to pass this to my InitChainer to be able to sync blocks

Used to generate the following initial keys once the seed is shared:

• (sk_io, pk_io) --> shared key for deriving input/output keys. pk_io is available on-chain, and sk_io is shared across all validators’ enclaves.
• master_state_key --> a symmetric master key used to derive other state keys.
• master_iv --> an IV seed used to generate fresh pseudo-random IVs for both encrypted outputs and state encryption.

https://forum.enigma.co/t/network-key-management-agreement/1324