[BLIP-1] Finding measurements for worksteps requiring and not requiring CCSM or ZKP

[humbitious]

[BLIP-1] Adding Support for workflows Not Requiring CCSM

Abstract

Current Baseline core specification – v1.0 – requires commitment of zero-knowledge proof of worksteps on a CCSM [R234]. However, there are business processes and workflows which can be implemented without CCSM interactions. We argue using a CCSM is a MUST when we deal with assets life cycle (DeFi) or necessity of a censorship resistance registry (SSI) but in the absence of any of those two mentioned criteria, we can implement a workflow without using any CCSM.

Motivation

CCSM is a fully replicated peer-to-peer network. Any transaction to a CCSM (e.g., Ethereum mainnet) costs 100s - if not 1000s - of nodes to verify (process), transition to and persist a new state (storage) and exchange their new state with other nodes (network bandwidth). Additionally, the finality of a transaction is highly dependent on the size of the network and/or the consensus algorithm in use. Thus, any alternatives which avoids a CCSM transaction and still holds the correctness and completeness of a business process is more favorable and scalable.

Contributors and Stakeholders

TBD

Specification

As a real-world example, we use customs clearance in Europe. As it’s depicted in Figure 1, the process includes several documents issued by different parties which all must be consistent. We’ve reduced the list of documents to just a few for the sake of simplicity. Other documents follow very similar process of verification. One exception is “Bill of Lading” that “conveys title to the goods, meaning that the bearer of the Bill of Lading is the owner of the goods.” Therefore, its digital form MUST be treated as an asset tracked (through the Zero Knowledge Proof (ZKP) of its ownership when privacy is required) on a CCSM.
Consistency
Other documents when digitized, MUST be issued, and signed by defined issuer and can be linked as nested verifiable credentials (VCs) by including the hash or the full parent document in the child document. Combining nested VC and digital signature ensures the consistency of each digital document. Consistency here means that any change in any document will invalidate the digital signature verification and thus detectable.

Figure 1 - Few simplified documents required for customs clearance in Europe

Versioning

When a new version of a document has been issued, it MUST be signed by all the involved parties. e.g., if a change must be approved by Exporter, Importer and Customs authorities of the exporting country, all three signatures are required on the new version. Please note that there is no double spending problem here and the agreement of few involved parties is sufficient for issuing a new version.

Collusion

When all signatures of the stakeholders are requires, and all the documents are tightly linked using nested VCs, there is no room for collusion.

Verifiable Timestamp

Each document will have an issuance timestamp. If signatories disagree on the timestamp, they won’t sign it. The signatures can also have their own timestamps. A decentralized timestamp (like CCSM) is irrelevant here. Changing one timestamp leads to a new version of the document and inconsistency in its children. Meaning either all the involved parties must sign the new version and agree on the changes, or the new version will be identified and discarded by others. Either way, having it (or its ZKP) on a CCSM doesn’t change the course.

Assuming the ZKP of agreement on a document as an output of a workstep in BPI has been submitted on a CCSM. If all the parties agree, they can discard that ZKP and agree on a new ZKP, even if it means restarting the whole BPI worksteps till now. Therefore, CCSM has no functionality as a verifiable timestamp.
Simple fact: users of BPI are companies who want to trade and if BPI is preventing them to facilitate their trades, they will reject it.

On the other hand, if only one party wants to change the timestamp of a document, no matter if it’s written on any CCSM or not, if other parties disagree, they won’t sign. Again, CCSM has no functionality as a verifiable timestamp.

[GoldenBit0]

Meeting setup for 11/9/2021 to discuss path forward for this. Mehran Shakeri finalizing use case prior to discussion.

[GoldenBit0]

11/12/2021: TSC discussing updates and next steps on BLIP-1.
Next steps: Sonal will schedule Session #2 for discussion and include TSC members

[GoldenBit0]

11/17/2021: Follow up meeting.
Attendees: Mehran Shakeri, Stefan Schmidt, John Wolpert, Luiz Soares, Ryan Fisch, Sonal Patel

Next Steps:

• @mehranshakeri is going to document end-to-end process on complete supply chain use case example to identify which parts CCSM decisions are needed, and why some parties may not need ZK.
  Mehran will post findings/comments under this issue and then will notify team when follow up session should be scheduled to discuss. The objective of his findings is to present evidence for a further discussion from TSC and the community on next steps for this BLIP (updates to doc, specifications, etc).

Notes:

• https://docs.google.com/document/d/13H-3gQdmMWBVOv0Oq-5V89AxyYxdpdZGRnXIp9ojz2I/edit?usp=sharing

[mehranshakeri]

Here is the first draft of an end-to-end supply chain business process. It a simplified version of what you can find in OASIS UBL 2.3 Supply Chain Business Processes

As next steps we can

• Verify and complete the process (tax authority and some detailed attributes are still missing)
• Highlight what information must be visible to which entities?
• Clarify what is the validation process of each participant? (e.g., what an import Customs authority validate?)
• Implement a Baselined supply chain and validate our assumptions

[stefschmidt]

I want to suggest

• to additionally mark process parts which "requires ZKP"
• to add a sequence diagram that shows the flow and the participants of the process (also those that may be interested in limited knowledge)
• to specify Acceptance Criteria towards any potential (reference) implementation to this case, so that they can be a) comparable and b) findings and learnings can be properly accumulated

We can discuss this in the BLIP-call, I volunteer for taking responsibility for these tasks and am happy if we find someone to co-work / pair-contribute.

[mehranshakeri]

Certificate of Origin should be proven to shipper that exists and is valid

[mehranshakeri]

We track our changes here

[mehranshakeri]

[mehranshakeri]

In the swimlane diagram

• Presence of a document in a lane demonstrates visibility of that role on the stated document.
• Documents in CCSM lane implies the required anchoring of that document on CCSM as a MUST.
• Pencil icon represent required signature from the corresponding role.

Identified ZKP relations [incomplete]

• Items and quantities
  • Order, Transportation Order, Dispatch Advice, Bill of Lading, Certificate Of Origin, Export, Import and Transit Customs Clearance, Receipt Advice

User Story - [Draft]

Supplier (Exporter) and Buyer (Importer) have mutually signed a Master Agreement.
The Master Agreement includes a Catalogue containing Line Items, their specifications and prices.

Buyer sets a new Order based on agreed upon Master Agreement. This Order includes ordered Line Items and quantity per each item. It carries both signatures of Supplier and Buyer and implies an agreement where the Supplier provides those Line Items to the Buyer and in return receives the total value of the Order. (i.e. Sum of Line item values time the ordered quantity). For the sake of simplicity, any discounts is ignored. To provide a verifiable timestamp, Order or its workstep will be anchored in CCSM.

Supplier and Carrier sign a Transportation Order which is either the full Order quantity or a subset of that to be picked up by Carrier at the Supplier location and be delivered to the Buyer.

Upon pick up, Dispatch Advice will be issued mutually signed by Supplier and Carrier and a copy is sent to Buyer. Carrier also issues a Bill of Lading titled to Buyer. The history of ownership of Bill of Lading will be anchored in CCSM.

Supplier requests Certificate of Origin for picked up goods based on Bill of Lading from OriginAuthority. As a result, Certificate of Origin will be issued which carries both signatures of Supplier and OriginAuthority. Relevant participants will receive a copy of this document.

Supplier prepares signed Export and Transit Customs Declaration documents and seeks signatures from corresponding Customs Authorities. Export Customs Declaration will be anchored in CCSM to have a verifiable timestamp.

Buyer prepares signed Import Customs Declaration and gets signature of Import Customs authority as a clearance.

Upon arrival of the goods in the Buyer’s side, the Receipt Advice will be created and signed by Carrier and Buyer. Receipt Advice must be anchored in CCSM for future tax purposes.

Later on, Buyer releases a Payment related to the Receipt Advice which will be processed by our Payment Provider.

[stefschmidt]

The "presence of documents in the CCSM lane implying the required anchoring of that document on CCSM as a must", could be extended by a rating/weight indicator, for example:

• CCSM anchoring not needed
• Anchoring on L2 sufficient
• Anchoring on Mainnet needed

This way, we would be able to compare different reference implementations on the described user stories, by having some basic metrics that can be interpreted differently in different reference implementations.

In the same way, we could rate/weigh the need/benefit for identified ZKP relations, for example if ZKP is helpful or needed (e.g. if 3rd parties MUST NOT see specific details of the process up to that point). Again, this would be a good help to get some metrics to compare reference implementations.

[stefschmidt]

Given all that - I'd propose to rework the BLIP title to "Adding support for worksteps not requiring CCSM or ZKP"

[GoldenBit0]

Approved proposal by work group in 1/18/22 session to update BLIP name to 'Finding measurements for worksteps requiring and not requiring CCSM or ZKP'

Meeting Notes Doc w/ Recordings

[GoldenBit0]

Jan 10, 2021 - Slack Discussion on BLIP-1

• Hank Hill Jan 11th at 8:23 PM
  I don’t understand the direction of BLIP-1. In my eyes it goes against the fundamental question of what it even means to baseline. The whole point is for multiple parties to use cryptographic proofs to reach consistency on a record. The heartbeat of baseline is in its provable and tamper resistant timestamp of a CCSM. Allowing parties outside of this principal could result in the expensive back and forths Baseline was trying to solve. If parties want to communicate outside of a CCSM, that’s fine. It’s just not baselining. @andreas Freund explained it best at https://www.youtube.com/watch?v=GBo8_PTpE5s&t=1580s @john Wolpert stated he was presented common sense arguments but what are they? (edited)

• Amit Mathur 20 days ago
  If you are referring to peer-to-peer communication outside of the blockchain, yes, i have often wondered about this. Other protocols also have this as a key part of the solution. Not a big fan of it. (cool backdrop Andreas 🙂)

• Andreas Freund 20 days ago
  @hank Hill... it is a question of trust-deficit, or lack there of. If you trust the other party's digital signature over a message hash, where the message hash contains a chain of hashes about the commercial state, and the party's time stamp than that is enough for bilateral interactions ... however, as soon, as a 3rd party needs to validate anything this breaks down aka there is a reason why auditors make boat loads of money. It gets bad quick e.g. BOFA US does not accept KYC of BOFA India without a 3rd party audit. You know what I mean? (edited)

• Hank Hill 20 days ago
  @andreas Freund Then doesn’t that just prove customs clearance in Europe is a bad example of a workflow not requiring a CCSM? I imagine a BOL containing multiple parties (shipper, receiver, customs) would warrant a ZK proof in contrast to some gutted one use workaround. Wouldn’t a situation of an enterprise wanting to baseline internal records such as HR or workplace management be a better example not requiring a CCSM? Even then why “baseline” at all?

• Andreas Freund 20 days ago
  @hank Hill correct, custom example is not a good example for a process not requiring Baseline. A strictly bilateral process in a high trust environment would be a better example

• Hank Hill 20 days ago
  Thanks @andreas Freund. At the risk of sounding controversial is that even baselining? In a bilateral high trust environment why even go through this and not just use their traditional systems of records. What is the argument for BLIP1? This feels only one step slightly better than trading pdf files again.

• Andreas Freund 20 days ago
  @hank Hill well i have not seen good counter examples to baseline. The traditional methods do not even use signed hashes etc. ... the question is for which use case do u get the biggest benefit with what methods

• Andreas Freund 20 days ago
  My argument is that with baseline it is much easier to build a solution that works for all partners with 1 integration instead of N

• Hank Hill 20 days ago
  Thank you @andreas Freund that makes sense

• Stefan Schmidt (Unibright) 20 days ago
  I think that the title of the Blip does not really match the scope of the BLIP anymore, and it is a bit misleading, which can be clearly seen in this discussion.
  It can be misread like "How to Baseline without CCSM", it should better read "How to make the right decision which workstep in a workflow needs a CCSM or ZKP".
  Therefore, I disagree that the presented use case would NOT be a good example. I think it is a very good example, because just picking an example where you do not need baselining at all, would gain no further learnings.
  In the presented example we have process preparing, bilateral steps that do not necessariliy need a CCSM involved. (And by the way, this includes ALL potential baseline using enterprises that are already doing business now and want to baseline in the future. It would be very bad if baselining is only considered baselining if all processes are fully baselined. This would result in that nothing is ever baselined.)
  We have following worksteps where an "anchoring" on CCSM is needed to prepare the next following worksteps that may include 3rd parties for the first time in the process. Why should we overload a baselined process by making it mandatory to anchor all preparing steps on a CCSM? Why should we overlad a baselined process to fully ZKP a Master Service Agreement, where the two parties signing it already have FULL knowledge of the contents anyway, and they perhaps only want to prepare automated processes that than include anchoring? ZKP can be "plugged in" for those worksteps where 3rd parties are actually involved, and in these worksteps they can benefit from former worksteps being anchored on CCSM, for sure.
  In the last comments on the github discussion the need to rename the BLIP had already been brought up, and I will bring it (and this discussion) to the next meeting with @Mehran Shakeri and others. (edited)

• Stefan Schmidt (Unibright) 20 days ago
  Parts of that discussion heavily remind me of the enterprise blockchain discussions from 2017 and 2018, where there was one "side" that claimed that EVERYTHING has to be on a blockchain and the other "side" that tried to explain that IT system landscapes are not built to be changed overnight, and that therefore it is useful to think of blockchain as a an ADDITIONAL tool to add trustless trust.
  Baseline is the perfect example of such an application, so we should not make the mistake again to only count fully baselined, ZKPed processes valuable. If we made that mistake, we can all be fascinated how great "the pattern" or "the standard" is, but if you look at the background of the BLIP contributors, it may become clear that there is huge interest in make the pattern work in regards to existing ERP landscapes and not only in theory.

• John Wolpert 19 days ago
  Here are my thoughts. To me, baselining has a good shot at focusing attention and prioritization on secure, verified multiparty workflows. All kinds. We began with blockchain and a particular use of a type of token (EY and ConsenSys' original approach) and evolved to the use of ZK. But as this thread points out, there are real-world multiparty (or at least bilateral) workflows (or worksteps in a workflow) that are handled sufficiently with messaging connection, verification of counterparty (or counter-machine) identity, and sigs/hashes. In this case, it becomes merely a convenience to put the hashes on a CCSM -- and only in a world where use of CCSM is widespread and established as a well-worn path for IT people generally. Otherwise, the sigs/hashes stored by each party separately will suffice...just less standardized to run checks...more of a human process of saying, "Hey, I see a problem, can you check your data against your...".
  There are other techniques that are working diligently on multiparty workflows. This week, I had a very nice call with my old friend, Richard Gendal Brown, who recently rolled out Conclave, which doesn't use ZK, but they are focused on the same goal, to make multiparty systems suck less while keeping data very secure and compartmentalized. Who is to say that baselining couldn't absorb this approach?
  By this logic, I'd suggest that we could approach the matter of "to zk or not to zk" with a reasonably liberal view (the operative word there being "reasonably"). You are baselining if you are following a standards-based approach to secure multiparty workflows, as defined by the current specification, and there are different techniques for different circumstances. The ongoing work of our community becomes one of considering new use cases and new approaches over time.
  From this perspective, I should think that the application of sigs/hashes, with or without the use of CCSM, could be considered a technique that -- while certainly not new -- can be embraced as a subset of baselining. (I'm reminded of the math-world's wrestling with things like P, NP, IP, etc...what sets go within other sets.)
  Does this seem reasonable? If so, I think the question before the standards committee is essentially whether or not to use the term MUST, SHOULD or "MUST in cases where xyz is required" when referring to specifications involving ZK.
  We can also consider adding clauses to the standard that explicitly permit -- and specify requirements for security, etc -- the use of sig/hashes (with and without the use of CCSM), using the "When implementing xyz, the following requirements are..." construction we use elsewhere in the document.

• Mehran Shakeri 19 days ago
  Thanks @hank Hill for your feedback. Unfortunately there are lots of context missing in documenting our conversations for BLIP1. That's on us and we try to improve it.
  The first issue is how you look at Baseline? Is it just a solution for ZKP and CCSM worksteps? Or you want to apply it for the whole end-to-end business process/ complete workflow? As I recall, the last consensus was that Baseline is intended to be the solution for complete cross company workflows. I also agree with Andreas and I hate having N integration solutions and that's exactly why we have BLIP1. To clarify if ❤️ Baseline ❤️ is THE solution, how it must be implemented to fulfill its prophecy. 🙂
  That's why we tried to find "real world business processes" and apply our Baseline understandings. We've talked about different use cases and the one we agreed upon by majority of interest was end-2-end supply chain consistency, including Customs Clearance.
  We are not rejecting use of ZKP or CCSM, we want to clarify where and when each MUST be applied. As per specification, it's part of implementation and it's allowed to aggregate several proofs and anchor one/once on CCSM. How you want to decide for your implementation when to aggregate and when not? It could be that we conclude that it's every workstep anchoring to CCSM OR it's done following specific measurable criteria.
  Agree, we need to update BLIP1 title and definition and reflect our points or simply conclude that and create a new one. It's clearly bringing more confusion than clarification.

• John Wolpert 19 days ago
  Right on, Mehran. I'm reminded of a spec I was reading from the litany of ERP standards, and one thing from a more recent spec popped out at me: Adoption generally follows the simplest, minimally viable solution to a problem. ERP specs, it argued, from the past were too bulky and complex, requiring processes that were not unreasonable in a single instance but became onerous at scale and over time. And were often more than was necessary to accomplish a particular objective. They even pointed out that there is often no need for a message confirmation to rise to the level of strong non-repudiation.
  I'm also reminded of XML, which looked really cool in 1998, but, it turns out was just too bulky to use in the end, particularly as things like json came on the scene.
  Good lessons. (edited)

• Amit Mathur 19 days ago
  Early days, long ways to go in terms of improving proof sizes and verification times. Great thread, thank you all for the detailed comments, very insightful.

[GoldenBit0]

Core Dev Update 6/13:

• @mehranshakeri please provide an update on BLIP1.
• Will reserve time during 6/27 Core Devs call for updates from group, and at next GA.

[mehranshakeri]

Core Dev Update 6/13:

• @mehranshakeri please provide an update on BLIP1.
• Will reserve time during 6/27 Core Devs call for updates from group, and at next GA.

Unfortunately we didn't have capacity to continue with this topic from our side and I've not received any updates from others yet. I will ping slack again.

[GoldenBit0]

6/27/22 Core Devs:

• Sonal to ask Martin and Thomas for update.
• Been requested a few times for the group to join a GA

[GoldenBit0]

7/11/22 Core Devs:

• Work is slowly progressing given team bandwidth

[GoldenBit0]

7/25/22 Core Devs:

• Add as TSC item to discuss

[GoldenBit0]

8/25/22

• BLIP-1 touchpoint has taken place since last session
• Work is being moved into bi-weekly research group
• Mehran and team are working on mapping out use case
• Martin, Thomas, Mark are working on mapping out architecture of standard to use case

[GoldenBit0]

9/19/22 Core Devs:

• User story from SAP WG members
• User story being groomed by researchers in WG

[GoldenBit0]

10/31/22 Core Devs:

• Grooming completed for user story
• Discussions on SSI layer in progress
• Tasks in progress for documentation/materials that outline work so far

[GoldenBit0]

12/12/22 Core Devs:

• 1 more meeting left in this year, goal will be to make more progress through Story Journey Advancement Predicate Doc

[GoldenBit0]

1/9/23 Core Devs:

• Meeting invites for 2023 sent out
• Story Journey Advancement Predicate is nearing completion (ETA: 1/12 meeting) then will start on user stories

[GoldenBit0]

2/6/23:

• Next session this week, few other actions (creating hero journey)
• Walk through reqs doc and other collateral in next session

[GoldenBit0]

2/20/23:

• [BLIP-14] International Supply Chain Demo #35 opened to track scope of work taking place in Research Workgroup
• Demonstration will be available in the future demonstrating zero trust under zero knowledge for a supply chain use case