Adding new v2-byzcoin requests

[ineiti]

The previous requests and instances were difficult to use for multi-instruction transactions.
Also, they didn't use the new Observable interface given by ByzCoin.

This PR adds a v2/ directory with some soon-to-be stable version of Darc and Coin instances.
Every instance can now be created as a BehaviorSubject that updates automatically whenever
a new block is available.
This allows to program a much more reactive programming of the user-interface: instead of
polling for new values, the UI can subscribe to the BehaviorSubjects and be updated
whenever something changes.

In the long run, other contracts should also find their way into byzcoin/v2.

Depends on #2392

[tharvik]

• does it make sense to put these in byzcoin/v2?

do you want to keep supporting the "v1" version? otherwise, you can merge the two

• what about the differentiation between Darc, DarcBS, DarcInst? Same for Coin*?

maybe a namespace would make it more readable:

• Darc.Contract which allow for Darc creation
• Darc.BehaviorSubject which listen to new values
• Darc.Instance which are elements generated by the BehaviorSubject, and each can generate new transactions

• does it make sense to have the contraact-commands twice - once as general commands and once instance-specific?

not really, to quote the Zen of Python "There should be one-- and preferably only one --obvious way to do it."

Also please have a look at how multiple instructions are put into a single transaction in coinbs.spec.ts::"transfer coins".

one would need a monad language to make it even nicer :)

[ineiti]

• v1 / v2 -> for the moment I'd like to keep v1, so for making it clearer, change byzcoin/v2 to v2/byzcoin, and add eventual other services to it, like v2/skipchain

[ineiti]

I also prefer not to use the following:

export namespace Coin {
    export class BehaviorSubject {}
    export class Instance {}
    export namespace Contract {}
}

Because of the collision of the names Coin, BehaviorSubject, and Instance. So I build things with the following structure:

export class CoinBS{}
export class CoinInst{}
export namespace CoinContract{}

Again, CoinInstance is already taken in v1, and to avoid unnecessary suffering of the users, I don't want to use the same name.

Another set I see is:

• Always the latest data with: CoinInst extends BehaviorSubject<CoinVersion>
• One version of the data: CoinVersion extends Coin
• Contract interactions: CoinContract

But I don't like the CoinVersion too much.

[tharvik]

Again, CoinInstance is already taken in v1, and to avoid unnecessary suffering of the users, I don't want to use the same name.

So you expect that people mixes v1 & v2? Then, is it really a new version or more of an extension (so in something like byzcoin-bs)?

Another set I see is:

• Always the latest data with: CoinInst extends BehaviorSubject<CoinVersion>

That's weird that a stream of data is an instance; CoinStream maybe or CoinUpdates?
I like to play with Struct & Structs, the first being an element, the second being a stream/list/container of the first.

• One version of the data: CoinVersion extends Coin

CoinUpdate?

[ineiti]

So you expect that people mixes v1 & v2? Then, is it really a new version or more of an extension (so in something like byzcoin-bs)?

Well it all is in the @dedis/cothority package, so if two classes have the same name, but come from a different path, confusion is guaranteed.

That's weird that a stream of data is an instance; CoinStream maybe or CoinUpdates?

That's the ByzCoin terminology: an instance points to data, and the contract defines how this data can be changed.

I like to play with Struct & Structs, the first being an element, the second being a stream/list/container of the first.

OK, mixing it all well:

• CoinStruct - containing Coin and readonly inst byzcoin.Instance
• CoinStream / CoinInst - BehaviorSubject<CoinStruct>
• CoinContract - constants and command-generators

So the CoinInst would be in reference to the byzcoin-instance, which by definition is changeable.

[tharvik]

So you expect that people mixes v1 & v2? Then, is it really a new version or more of an extension (so in something like byzcoin-bs)?

Well it all is in the @dedis/cothority package, so if two classes have the same name, but come from a different path, confusion is guaranteed.

Right, that makes it confusing for some people..

• CoinStruct - containing Coin and readonly inst byzcoin.Instance
• CoinStream / CoinInst - BehaviorSubject<CoinStruct>
• CoinContract - constants and command-generators

So the CoinInst would be in reference to the byzcoin-instance, which by definition is changeable.

That looks more consistent, more readable; good for you?

[ineiti]

yes, starts to look OK for me. However, now it complains about the following:

export namespace CoinContract {

with

ERROR: src/v2/byzcoin/contracts/coinInst.ts:108:1 - 'namespace' and 'module' are disallowed

Perhaps I'll make it a class with only static fields and methods anyway?

[tharvik]

Hum, it seems that when using module, you can't use namespace, you should put any namespace into a new module (ie a new file) and export that you want, which is semantically the same

[ineiti]

Seems to be one of those eternal PRs...

[tharvik]

Why sleep for a second?

[ineiti]

Added a comment.

[tharvik]

Hum, as the test are stopping at the first failed assert, dropping this line would show a test not cleaning correctly or even missing some relevant check. Maybe it was added during developpement and isn't needed now?

[ineiti]

OK, ran it 78 times until travis-timeout without the sleep...