monkeypants
commented
7 years ago 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
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/
Goals
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.