ErgoAuthUtils added for EIP-28

[MrStahlfelge]

Adds ErgoAuthUtils utility methods for ErgoAuth ergoplatform/eips#53

On this occasion, ColdErgoClient was improved so that it does not need to be instantiated by using Explorer API model classes.

[aslesarenko]

I suggest to introduce SigmaProp wrapper (see one of the comments), move related serialization code there and use it where necessary instead of Address.

[MrStahlfelge]

I have made the requested additions, but please note:

• the new Address methods have a very low level of originality, they are only duplications for isP2PK()/getPublicKey()
• ErgoAuthUtils does only hold a very basic check nonw and could be removed completely. The question the dApp developers reviewing the EIP all asked was "What is a SigmaBoolean, we want to check if a user can access a certain address holding a NFT.". The utility class does not help with this problem any more.

[aslesarenko]

• we want to check if a user can access a certain address holding a NFT

In blockchain ownership of a box is proved by showing that "the owner" can spend it.
This can be done in general, without knowledge of specific contract and without the actual spending. Will describe it below. But this is not how ErgoAuthUtils were implemented.

The User and the dApp follow this steps in order to authenticate access to The Box:

1. User creates a special AuthMessage which is like ErgoTransaction, but not quite, it:
   • contains the Box as a single input
   • doesn't contain outputs
   • is serializable to bytes which will be signed
2. The user executes the Box.ergoTree in the current blockchain context, reduces it to SigmaProp and then signs the AuthMessage.bytes with it.
   (this step is similar to signing a transaction in Appkit)
3. The user sends SignedAuthMessage to the dApp
4. The dApp:
   • receives SignedAuthMessage
   • extracts the Box from it
   • reduces Box.ergoTree to SigmaProp
   • extracts SignedAuthMessage.signature
   • verifies signature against SigmaProp and the AuthMessage.bytes
     (this step is similar to what each Ergo node does in verifying a transaction)

If we want to implement this protocol, we can basically clone Transaction and SignedTransaction implementation and simplify it.

But, NOTE, the dApp becomes trusted party. In blockchain the verification is part of consensus, in dApp similar verification will not be part of consensus.

[MrStahlfelge]

User creates a special AuthMessage which is like ErgoTransaction

This would introduce the problem that the AuthMessage is always the same. Hence anyone becoming aware of the signed message can authenticate to any place using the described scheme.

Apart from that, we could do it like described, if I understood everything correctly this adds only a reduction of ErgoTree under the current context (which makes sense). At the moment, this reduction is implemented in AppKitProvingInterpreter and can't be used for Adress.getSigmaBoolean though.

[aslesarenko]

AuthMessage is always the same

This problem can be solved independently by using DHTuple schema, I'm not sure, but @scalahub may suggest some ideas.