Exact Data Components That Can Be Kept Secret By Enigma

Generally, I’d like to hear exactly what data (smart contract data, computation, transaction amounts, transaction addresses, etc.) can be concealed on the Engima blockchain. Specifically, I want to see if it can store ERC 721 token metadata on chain that can only be accessed by the token owner.

1 Like

All data with the exception of transaction meta-data (sender, secret contract address and function, transaction and token amounts) are encrypted. More specifically:

  1. Arbitrary inputs
  2. Arbitrary outputs
  3. Secret contract state

It’s hard to understand from your description how you’d like to connect ERC721 to encrypted data, but maybe you can give a concrete example?

2 Likes

Oh ok, so Enigma does not include any of the transactional privacy protocols that Zcash/Monero implement (no zero knowledge proofs)? And when you say the secret contract state is encrypted, that essentially means that state variables stored in the contract can be made private? In that case, how is it different from simply encrypting data to be stored on the Ethereum mainnet (maybe I read computations can be performed on the data without revealing it)?

To make my question more concrete, ERC721 tokens have a function that is currently configured to retrieve a specified token’s metadata from IPFS – and as I see it there is no way to ensure only the owner of the token can view this data (the issuer of the token creates metadata so if it were encrypted it would be with their keys) – and I was wondering if it were possible to store that ERC721 metadata in an Enigma secret contract to the effect that only the owner can view the data.

The Enigma protocol allows coin mixing on Ethereum (and potentially other blockchain platforms), which works like Dash masternodes. (I’m not a team member)

I think that what he wants is some sort of privacy features - RBAC on EVM.

Basically you would try to read an encrypted state by signing a message, and based on the smart contract and encrypted state, it would return you what you are allowed to see.

Yes, RBAC is exactly what I’m looking for! Thanks for the reference. However, I’m still troubled by being unable to send a smart contract generated transaction with the transaction amount concealed. If not on Engima, is there any way to do this today?

I think it would be doable using a pure function.

examples:

function getMyBalance() pure returns (uint) {
 return balances[msg.sender];
}

or

// mapping of balances
mapping(address => uint) private balances;

// mapping of access of balances
mapping(address => mapping(address => bool)) private balanceAccesses;

function giveAccessToBalance(address _toWhom) public {
 balanceAccesses[msg.sender][_toWhom] = true;
}
function removeAccessToBalance(address _toWhom) public {
 balanceAccesses[msg.sender][_toWhom] = false;
}

function getOtherBalance(address _account) pure returns (uint) {
  require(balanceAccesses[_account][msg.sender], "you don't have access to the balance");
 return balances[msg.sender];
}

NOTE: Change balance to NFTData :slight_smile: or diverses rules

I appreciate the help, but my question is more regarding whether a smart contract can transfer value to a function caller with the transaction amount and recipient wallet address concealed. The question is: if not Enigma, are there any other dapp platforms that utilize zero-knowledge proofs to send value anonymously?

Also, I’m fairly certain you cannot read from the blockchain with a pure function – you need to make it constant/view to read balances[msg.sender] in first and last functions you wrote.

You can do that but it would be slightly different than how Ethereum works. In order to interact with Ethereum and do payments on Ethereum you’d initially need to interact with the Enigma registry contract on Ethereum. Say you put 10 ETH there, this can be used for voting, auctions, games, dexs and transactions (as a contract). Essentially, every time you wish to send tokens to another user, you’d interact with a secret contract. The contract inputs would be encrypted sender, signature, receiver, and amount values. All these inputs can be decrypted inside the Enigma network and computation would take place. This means state of the Enigma network would be updated to represent the new balances and settlement can be done on Ethereum at any time. You’d want to submit the task from a one time Ethereum address to create the task record, so it’s harder to correlate the TX task to your deposit account

I’ve been looking into this for ERC721 as well. My use-case was a little different-- to have a “hidden” NFT (with generic metadata), that is then “opened”. In this scenario the “minting” happens on Enigma. In this use-case one of the metadata fields is an attribute generated randomly within enigma. However, after minting it is public.

I got a bit confused about whether you are sending value or rather want some attribute of an NFT to remain encrypted for onlyOwner. Can you tell me more?

Ok, so to clarify the process you’re suggesting, I would first have an Ethereum address (deposit account) that would send funds to the Enigma registry contract, then use one time Ethereum addresses to create task records in an Enigma secret contract (of my making) that would decrypt the sender, signature, receiver, and amount values and send the deposited funds in the Enigma registry to the specified Enigma addresses, at which point the recipient of my funds could cash out through the registry contract and onto the Ethereum network.

If that is all correct, I have a few questions. Are the deposit funds always held in the Enigma registry and thus always visible to the Ethereum network? Or can that value be passed on and live inside the Enigma network? Additionally, can you send any ERC-20 token to the Enigma registry?

1 Like

Interesting – did you find that ERC721 minting could be done on Enigma? That is one important functionality and the other is sending value anonymously. I would like to have some attribute of an NFT remain encrypted for onlyOwner in addition to the NFT being anonymously exchangeable for some other token.

1 Like

It looks like Oasis / Ekiden is working on a Caller-based access-control

Caller-based access control (experimental)

A more ergonomic form of access control can be done with msg.sender , which contains the address of the user that issued the transaction.

contract SecretBallot {

  mapping (bytes32 => uint16) private votesReceived;
  bool public votingEnded;
  address public  ballotCreator;

  constructor(bytes32[] _candidateNames) public {
    ballotCreator = msg.sender;
    candidateNames = _candidateNames;
  }

  /// returns the number of votes issued for the given candidate if and only if
  /// the method is called by the ballotCreator.
  function totalVotesFor(bytes32 candidate) view external returns (uint16) {
    require(msg.sender == ballotCreator);
    return votesReceived[candidate];
  }
}

Notice how the votesReceived data is returned if and only if the sender of the transaction is the ballotCreator .

cf. https://docs.oasiscloud.io/en/latest/confidentiality-develop/

I think this type of access-control is pretty common for smart contracts, no? Is it different from onlyOwner?

No I think that he wants the contract state to be fully encrypted, to the whole world (and the enclave).

And the “read” request would be sign by the caller, the caller would be authenticated by the enclave, and it will return (or not) the requested data if the contract allow him to do so.

1 Like

Yes that’s correct on high level - you use your Ethereum address in Enigma and can use ERC20s for deposits.

Deposit funds will be on Ethereum and visible for the current release. In the future iterations we will receive inputs without relying on Ethereum. I’m sending you a DM let’s talk in more detail

1 Like