How to authenticate a smart contract

Question

my Question is, how the identity of a smart contract can be verified, or basically how to authenticate a contract.

As far as I know a contract does not have a private key and also cannot keep one, since all its content is public.

So how could I authenticate and authorize a contract to access some secret data off chain?

Thank you!

Answer 1

I don't think your question is unclear (someone flagged it) but it's pretty far off from the way Ethereum works conceptually. Let's start with the big one.

Everything in Ethereum is deterministic, meaning it is possible to verify correctness. In fact, it must be possible for every node to verify every computation now, and in the future. Consider this function:

function adder(uint x, uint y) public pure return(uint sum) {
 return x+y;
}

There's no problem here because we can say that for any given pair of inputs, the result will always be the same. We can even scribble down the result for later:

uint public z; 

function adder(uint x, uint y) public  {
  z = x + y;     
}

We'll have an immutable history of all transactions sent to the function and the value of z will be the only thing it can possibly be given the transaction history (that all the nodes agree on).

In case that isn't clear, history would look something like:

1. Alice deployed a contract and it got address 0x123...
2. Somebody sent a transaction to 0x123... with (2,3). That has a transaction hash that became part of the canonical chain. Everyone agrees it happened.
3. Someone else decided to inspect z() at 0x123 and the response was 5 and everyone can see that this is the only possible outcome, given the history.

What's not so obvious is that it's fundamentally impossible to create to a function that inspects the outside world. If we did that, say ... to check the response from an API, how could we possibly know that a given API will always return the same value as it does right now? We can't. So that would make it impossible for another node to verify the blockchain in the future. How is that different from the (2,3) in the earlier example? Someone signed the transaction with (2,3).

Hmmm ...kay, but checking the outside world is useful.

One solution to this problem is to use an Oracle pattern. Generally, this means that a trusted account will inject some information (today's weather, a stock quote, something else ...) and sign the message. Importantly, the blockchain does not (cannot) verify the accuracy of that input. The network does verify the signature. Any node (in the future) will be able to verify that the Oracle said it was 37 degrees today. The information finds its way into the contract by way of a signed transaction.

For more on Oracles: How do oracle services work under the hood?

This is a well-established pattern. In your case, the solution might be to give the custodian of the "secret" information privileges in the contract. For example, the priviledge of acting on information no one else has.

Another solution that is admittedly more experimental and not especially easy to grasp is the idea of using Zero-Knowledge Proofs. You can find a simplified description over here to consider if that might be what you're looking for: https://medium.com/@robhitchens/selective-disclosure-with-proof-f6a1ac7be978

Hope it helps.

Answer 2

Contracts cannot access someone else information on their own. They can call other contracts to acces information but only when someone else instructed them to do so.

For example a smart contract cannot move ERC20 tokens that belong to someone else, but if the owner has approved them they can move them.

Is the responsability of the contract holding the information to implement validations. For example ERC20 has the concept of approval.

The identity of a smart contract is its own address, if you receive a transaction from that address you are pretty sure that it was generated from the smart contract (*).

(*) In theory there are private key that generates the same address that of smart contracts. And they can send transaction on behalf of the contract. In practice it is very very unlikely to find a collition of addresses.