Skip to main content

Unibright.ONE

Intro​

Unibright ONE makes it possible to notarize the exchange of business objects (such as orders or invoices) between process participants. It is recorded on chain that all participants have reached an agreement that the correct content has been exchanged, i.e. sent, received and understood. Unibright ONE is built as a service-oriented platform enabling secure enterprise process synchronization on various blockchains, between multiple participants, optionally protected by zero- and limited knowledge technology. Key features of Unibright ONE are:

  • A service API for all microservices, callable from all ERP systems (SAP, Microsoft, Oracle, SalesForce, …) and legacy systems via REST services
  • Workgroups with many participants for collaboration supported
  • Baselining, notarization, workgroup management and notifications via service calls
  • Notifications of new notarizations via pull (via REST), PUSH (via MQTT or NATS), email or retrieval via platform dashboard
  • Usage of multiple blockchains (Baseledger, Ethereum, Polygon, Bitcoin) as notarization targets per call
  • Pay-per-use with fiat gateway and/or UBT payment — no proprietary cryptocurrency holdings are required
  • Optional securing of processes and involvement of third parties (such as auditors) through zero- and limited-knowledge technology (“SyncTree”)
  • Finalizing and exiting of any number of single notarizations of one or more processes in arbitrary blockchains, where it is also explicitly possible to combine notarizations from different blockchains (e.g. Baseledger and Bitcoin) for an exit in another blockchain (e.g. Ethereum)
  • Dashboard for configuration and administration

Basic use case​

The simplest use case of Unibright ONE is to notarize "something" - most often a hash of "something" - into a blockchain of choice. Thereby making us of a blockchain as a decentralized, bullet-proof way of storing information to be able to make use of that notarization at a later point in time. For example, one could store the hash (AKA checksum) of a document in a blockchain to later be able to proof that he did know the document - otherwise he could not have created and stored its hash. Using a public/private key pair here - one can come up with a basic document signing use case for exmaple. Certificates of any kind could be another applucation - there respective hask/checksum can be stored on chain using a key pair for signing. This allows for tamper proof test certification management as required in multiple industrial use cases.

Use case outlook mutliple participants exchanging SyncTrees​

Unibright ONE will make it possible to notarize the exchange of business objects (such as orders or invoices) between process participants. It is recorded on chain that all participants have reached an agreement that the correct content has been exchanged, i.e. sent, received and understood. For this purpose, objects will be converted into a “SyncTree”, a Merkle tree which, in addition to the attributes of the object as leaves, also calculates hashes at various levels and displays them to check the correctness of the data. Only the top node of the tree, the “root proof,” is stored in the blockchain. Consensus can then be established via these notarizations, meaning that each participant in a business process verifies (i.e., accepts or disagrees with) the exchanged SyncTrees. SyncTree

A set of individual notarizations including the associated approvals or rejections within a workgroup can be transferred back into a SyncTree of a special kind (the “TrustMesh”) and notarized after the end of the process itself. Among other things, this enables individual steps of a process (e.g., order, delivery notification, receipt confirmation, and invoice) to be stored cheaply and quickly in a highly available blockchain such as Baseledger, but the consensus on the overall process to be recorded afterwards in a blockchain such as Ethereum that is as widely used as possible. TrustMesh

The stored data in the blockchain is meaningful only to the participants in the process, and does not in itself reveal anything about the nature or content of the process or even about the participating parties. It is the immutable and temporally unambiguous recorded evidence that the root of a particular SyncTree was recorded in a blockchain at a particular time.

Uninvolved third parties, such as auditors, can be provided with portions of the SyncTree under Limited or Zero-Knowledge, so that all intermediate evidence can be recalculated and verified without revealing the actual content of the original business object.

The concept of the SyncTree was introduced by Unibright as early as 2021 with the unveiling of the Baseledger Test Network, and is now being applied in a similar form in other cases, e.g., in the “Proof-Of-Reserve” as discussed and proposed right now by prominent figures such as Vitalik Buterin and crypto exchanges such as Binance. With Unibright ONE, it is straightforward to implement a “Proof-Of-Reserve” use case.

Use case example customs clearance (including Zero Knowledge Proof (ZKP))​

A real-world example described for exmaple in (https://github.com/eea-oasis/baseline-blips/issues/1) is customs clearance in Europe. The process includes several documents issued by different parties which all must be consistent. Customs documents 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 blockchain.

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.

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.

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.

UBC​

UBC has a built-in functionality to allow for service-oriented interaction with Unibright ONE. Thereby use-cases of all kind can be implmented via UBC interacting with an account within Unibright ONE. Every account in Unibright ONE comes with an API-Key (Bearer-Token) that can be used by UBC to call all exposed services within Unibright ONE (see swagger page for details: https://unibright.one/swagger/index.html). The respectice account within Unibright ONE can be configured via the web-based frontend. This configuration includes among other things, the blockchain tareget in which notarizations take place (Ethereum , Polygon, Baseledger, Bitcoin,...) and the handling of credits used to pay for notrarizations. Unibright ONE Cockpit