Oracle interface

[parkan]

Listens on ethereum network, returns payment addresses. Will need to RPC to concat for now.

Using https://github.com/ethereum/web3.js/

[parkan]

Thinking about the design of this.

aleph needs to know which concat to query for data for particular WKI, this is is a specific case of the general data routing problem but we can likely just solve this (for the moment) by "pairing" an aleph and a concat -- this also holds for many other uses cases and should be a core feature. After that we just remoteQuery by WKI -- @yusefnapora can you confirm that this should work?

[parkan]

Deferring this until a bit later

[parkan]

Needs #132

[denisnazarov]

notes from @parkan

This is our statement structure:

message Statement {
  string id = 1; 
  string publisher = 2;
  string namespace = 3;
  StatementBody body = 4;  
  int64 timestamp = 5;
  bytes signature = 6;
}

message SimpleStatement {
  string object = 1;
  repeated string refs = 2;
  repeated string tags = 3;
  repeated string deps = 4;
}

This is rigid "meta-metadata" and writes need to supply it. Let's break it down (slightly out of order to help clarify):

Statement:

- namespace: Clear, the namespace to store this in
- timestamp: Reasonably clear, can be block time
- publisher: Currently all statements in our system use Ed25519 pubkeys as publisher identities. It should be possible (and elegant) to use the ethereum pubkey of the contract caller here instead, BUT it's the wrong curve (ECDSA)
- id: Internally these are `publisher:timestamp:counter` so can follow that based on above values
- signature: corresponding to the publisher identity, this can be a web3 signature, but again — curve is wrong
- body: see below

Body (currently only considering SimpleStatement):

- object: bson'd actual payload, whatever
- refs: WKIs
- tags/deps: ignore for now

[parkan]

Note that we largely addressed these concerns already and are working to implement the appropriate key algo support.