Blockchain data providers

[arobsn]

Planned Implementations

• [x] #18
• [ ] Indexed node package

Interface

All packages must implement and extend the following interface and throw a NotSupportedError for not supported operations:

https://github.com/fleet-sdk/fleet/blob/edc2836501504ee7f30d6d41ea7057cd1fcdc75e/packages/common/src/types/chainClients.ts#L40-L65

[aslesarenko]

@arobsn I suggest to have a different set of transaction processing methods

// reduces transaction (doesn't require knowledge of secrets)
// The resulting transaction can be signed using ErgoPay
reduceTransaction(transaction: UnsignedTransaction<Amount>): ReducedTransaction;

// protected by apiKey, signs reduced transaction (requires knowledge of secrets)
// this method can be implemented by Ergo node via embedded wallet
signTransaction(transaction: ReducedTransaction): SignedTransaction

// checks the transaction validity and it's signatures (doesn't require knowledge of secrets)
// runs verifier part of SigmaProtocol (see https://hackernoon.com/sigma-protocols-for-the-working-programmer)
checkTransaction(transaction: SignedTransaction): boolean;

// submits signed transaction to blockchain
submitTransaction(transaction: SignedTransaction): boolean;

[arobsn]

@aslesarenko thanks for your suggestions! That will be certainly implemented for data providers which support such features.

IChainDataClient is a minimal interface that all blockchain data providers have in common, the intention is to enable dependency injection by having a minimal implementation warranty across all client packages.

[aslesarenko]

@arobsn yes, and I propose to make clear distinction between Unsigned, Reduced and Signed transactions. Of all the 4 methods, only one (signTransaction) requires knowledge of secrets and hence some wallet. Others can be implemented by any party, i.e. by Ergo node.

The signatures

checkTransaction(transaction: UnsignedTransaction<Amount>): boolean;
  submitTransaction(transaction: UnsignedTransaction<Amount>): boolean;

imply that you can implicitly sign transaction to verify its validity, which is only possible when the secrets are known, which is big requirement.

[arobsn]

Oh, that's my fault, fixed!

[aslesarenko]

Oh, that's my fault, fixed!

Ah, makes sense. I still suggest to add reduceTransaction as a optional method (i.e. it can throw NotSupportedException). reduceTransaction is important capability for ErgoPay support. For example any wallet, can use it to reduce transactions (which is necessary for ErgoPay) and the wallet don't need to have interpreter implementation available. For example Python, C#, etc.

[arobsn]

For example any wallet, can use it to reduce transactions (which is necessary for ErgoPay) and the wallet don't need to have interpreter implementation available.

That's interesting, definitively worths pushing APIs to provide this endpoint, updated interface and opened an issue on ergo-graphql: https://github.com/nautls/ergo-graphql/issues/74