Blockchain Smart Contracts

[srowlison]

A permanent record is exposed in a transparent and open fashion using an international standards for Blockchains. https://www.iso.org/committee/6266604.html

UBL documents are missing verifiable proofs of existence, digital signing and payment. This proposal seeks individual support for specifications and implementations of Blockchain Smart contracts from UBL document structures/message response objects and types.

High level design
See http://bbiller.com/2017/05/07/smart-contracts-for-accounting/

• The Smart Contract will comprise a set of rules which satisfy approval of an invoice and proof of payment. This may include documents that support the collaborative billing process.
• The smart contract may support Escrow of Funds
• The smart contract may be a tradeable commodity and risk rated.

Goals

• Identify a range of use cases for UBL-ish blockchains including Oracles http://www.oraclize.it/#home
• Develop an implementation model and code base for testing

Related specs: http://bbiller.com/wp-content/uploads/2017/04/Whitepaper-Blockchain-Biller.pdf

Signed Stephen Rowlison
Proposer - Owner bbiller.com
https://www.linkedin.com/company-beta/18029972/

Notes:
Structures affects what is visible to the public in the blockchain.
Structures are used in a transitory fashion inside of the software and out of the view of readers and as are such proprietary or on private blockchains.

[monkeypants]

Implementing invoice semantics into smart contract protocols is one thing (and I agree, you can do all sorts of cool things with trustless payments, escrow and so on). Interfacing those black-boxes with the global EDI network using Smart Contract Oracles is something else (and also potentially very cool). They actually don't strictly depend on each other either.

While UBL documents are missing verifiable proofs of existence, digital signing and payment, it's not the case that the only way to provide these services is to bring the entire traffic into a blockchain ledger.

We have added verifiable proofs of existence with our NRY protocol. If you have a large collection of artefacts, you don't need to put the entire collection into a blockchain to create a verifiable proof of existence. You can publish a Merkle-DAG of the artefacts and place the root into the blockchain (blockchain-pegged Merkle-DAG pattern). With the NRY specification, we do this in a way that allows IPFS to be used transparently for publishing the Merkle-DAG, which is how we implemented the testpoint.io reference service. That allows efficient decentralised data distribution and redundancy. Once notarised traffic reaches large enough scale (billions of message), the combination of IPFS Merkle-DAG + BitCoin peg is vastly cheaper to operate than Etherium or any other on-chain system with comparable Sybil resistance. Basically, the blockchain gazettal cost is a small constant while other costs scale linearly with bandwidth+storage.

Again, digital signing and crypto is done in our current raw specs (v2 in some places, the older DBC draft specs do have very significant security problems) using OpenPGP and modern cyphers. The reference code uses GnuPG. Basically, sender signs and encrypts, receiver decrypts, interested parties are given payload access by receiver and can verify signatures independently. The public key material is published (and revoked) via DCP protocol in a complementary way to RFC4880 keyservers and crucially, the link between published keys and registered identities is managed through protocols at the DCP and IDP layers. Private key material is retained by sending/receiving parties, for example by a trusted ledger platforms or ERP system.

We don't pretend perfect identifiers exist. We adopt "levels of identity assurance" model that maps to KYC-type regulations and contractual practices, then create opportunities to grow identity strength over time by accumulating (blockchain-notarised) evidence of participation in commerce. As soon as you have to link multiple identity schemes, this seems like the only pragmatic approach.

We don't have any proposals for payment channels. I don't think that's come up as a scope item, and suspect payments should remain loose coupled and independent of almost all of the procure-to-pay information lifecycle. But that's just my opinion, others may feel differently about that.

I'd encourage you to look at the current crop of specs, and focus on how an Oracle could interface the off-chain business identities while providing it's own rich internal network. In other words, an on-chain smart contract system with rich identity, trust and value flows, which interfaces the off-chain network as a cluster of one or more off-chain identities. So each smart contract system becomes a ledger platform with blockchain super-powers, which from the outside perspective appears to be a single entity with one or more public identities. You could even have a 1:1 correspondence between your internal identities and off-chain identities, and send traffic through the Oracle only when interacting with off-chain identities.

I think a 1:1 mapping between UBL and Solidity (for example) would be very interesting. You should probably compare for yourself the semantically equivalent but structurally simple JSON UBL dialect proposed here (e.g. BILL Spec), with the semantically equivalent but structurally, em, "XMLish" JSON UBL dialect proposed by OASIS recently. Our simplified schema exists because it's more enjoyable to work with in an OO context, compared to the painful cyclic complexity of XML UBL. The exercise of mapping BILL Spec schemata to something like Solidity would probably help us identify further refinements. If that works out, going forward with a harmonised JSON schema and Solidify abstract base-classes seems both possible and sensible.

[srowlison]

Implementing invoice semantics into smart contract protocols is one thing (and I agree, you can do all sorts of cool things with trustless payments, escrow and so on). Interfacing those black-boxes with the global EDI network using Smart Contract Oracles is something else (and also potentially very cool). They actually don't strictly depend on each other either.
SR>Accepted

While UBL documents are missing verifiable proofs of existence, digital signing and payment, it's not the case that the only way to provide these services is to bring the entire traffic into a blockchain ledger.
SR>After having read more of the specification I can see suitable protocols and messaging behaviour already adopted. In the case of Blockchain there are overlaps but these should not cloud standard development or implementation objectives.

We have added verifiable proofs of existence with our NRY protocol. If you have a large collection of artefacts, you don't need to put the entire collection into a blockchain to create a verifiable proof of existence. You can publish a Merkle-DAG of the artefacts and place the root into the blockchain (blockchain-pegged Merkle-DAG pattern). With the NRY specification, we do this in a way that allows IPFS to be used transparently for publishing the Merkle-DAG, which is how we implemented the testpoint.io reference service. That allows efficient decentralised data distribution and redundancy. Once notarised traffic reaches large enough scale (billions of message), the combination of IPFS Merkle-DAG + BitCoin peg is vastly cheaper to operate than Etherium or any other on-chain system with comparable Sybil resistance. Basically, the blockchain gazettal cost is a small constant while other costs scale linearly with bandwidth+storage.
SR> Yes, there is already a plethora of potential methods. Ethereum would be a smart choice for proving implementation specifics. I'd recommend NRY in decision considerations.

Again, digital signing and crypto is done in our current raw specs (v2 in some places, the older DBC draft specs do have very significant security problems) using OpenPGP and modern cyphers. The reference code uses GnuPG. Basically, sender signs and encrypts, receiver decrypts, interested parties are given payload access by receiver and can verify signatures independently. The public key material is published (and revoked) via DCP protocol in a complementary way to RFC4880 keyservers and crucially, the link between published keys and registered identities is managed through protocols at the DCP and IDP layers. Private key material is retained by sending/receiving parties, for example by a trusted ledger platforms or ERP system.
SR> IDP and IDP could be a bridge to contract protocol?

We don't pretend perfect identifiers exist. We adopt "levels of identity assurance" model that maps to KYC-type regulations and contractual practices, then create opportunities to grow identity strength over time by accumulating (blockchain-notarised) evidence of participation in commerce. As soon as you have to link multiple identity schemes, this seems like the only pragmatic approach.

SR> Accepted.

We don't have any proposals for payment channels. I don't think that's come up as a scope item, and suspect payments should remain loose coupled and independent of almost all of the procure-to-pay information lifecycle. But that's just my opinion, others may feel differently about that.

SR>I think some definition for proof of payment over remittance advice would prove valuable. The design would be loose coupled and allow for blockchain channels at time of payment means decisioning. Commercially the project would break any opinion to achieve a procure-to-pay. In consideration of community standards, the exemplar payment model would be pursued through this specification.
.

I'd encourage you to look at the current crop of specs, and focus on how an Oracle could interface the off-chain business identities while providing it's own rich internal network. In other words, an on-chain smart contract system with rich identity, trust and value flows, which interfaces the off-chain network as a cluster of one or more off-chain identities. So each smart contract system becomes a ledger platform with blockchain super-powers, which from the outside perspective appears to be a single entity with one or more public identities. You could even have a 1:1 correspondence between your internal identities and off-chain identities, and send traffic through the Oracle only when interacting with off-chain identities.

SR>Ideally this goal would be included in the high level scope the objective as a topic.

I think a 1:1 mapping between UBL and Solidity (for example) would be very interesting. You should probably compare for yourself the semantically equivalent but structurally simple JSON UBL dialect proposed here (e.g. BILL Spec), with the semantically equivalent but structurally, em, "XMLish" JSON UBL dialect proposed by OASIS recently. Our simplified schema exists because it's more enjoyable to work with in an OO context, compared to the painful cyclic complexity of XML UBL. The exercise of mapping BILL Spec schemata to something like Solidity would probably help us identify further refinements. If that works out, going forward with a harmonised JSON schema and Solidify abstract base-classes seems both possible and sensible.

SR>Thanks for your review, ideas and comments. Ken Holman and I are working on a 2.4 Payment UBL XML document, but I am also keen to see an implementation example on Ethereum leveraging with JSON work done by this committee and thus call for collaboration participants.

[monkeypants]

One large part of this proposal is covered in #43

What's left seems like a proposal to use EDI semantics within a blockchain / smart contract system. That's fine, but does it need a proposal? seems to me like something you can just go ahead and do, no need for a standard beyond agreement to use standard EDI semantics with standard syntax for interoperability (which proposal #43 pretty much covers).

If #43 goes ahead, I'm also don't see how a standard is needed to build an Oracle between the open world (e.g. REST/JSON) and a walled garden (e.g. Etherium) either. You can just use standard #43 on the inside and TAP, DCL, DCP, etc. on the outside, and how you bridge them is your (Oracle) business.

Maybe I'm wrong about that, but unless a use-case emerges I suggest we close this ticket and focus our energy on #43