Scaling Trust and Transparency with Assurety

Published in

[ARCHIVE] Paystand Blog

22 min readAug 1, 2019

It is harder than ever to establish trust on the internet. Today’s systems for verifying records are costly, inefficient, susceptible to corruption, and prone to human-error. The majority of the available solutions today are either labor-intensive or don’t work at scale.

Over the past 5 years, we’ve been building a scalable way to drive trust and transparency in commercial transactions, shifting away from our reliance on third-parties and middlemen. Our goal was to reduce middlemen costs and to guarantee transaction history permanence without the necessity of relying on third parties.

In what follows, we will go over how we solved this problem for our customers with Paystand Assurety and walk through the technology powering our vision for an Open Industry.

What is Assurety?

Paystand Assurety provides technology to generate verifiable, untamperable, and durable proof of existence for any record (mainly transactional records). In particular, Assurety means different things to different parties:

Assurety icon from the Paystand Dashboard

For creators of Assurety, it means that your data is private yet shareable and tamper-proof. You control your own data and you can share it selectively with interested third parties.
For receivers of Assurety, it means you can verify the authenticity of the received data and that it hasn’t been tampered with. There is no need for the creator and receiver of the Assurety records to trust each other or to trust another third party arbitrator or middle man.

In general, the Assurety solution we built, builds on top of already existing technologies (such as Blockchain, fingerprinting and electronic certification) to provide a technology that is both easy to use (i.e. it does not have a steep learning curve to start benefiting from it), but it is also sophisticated enough so that advanced users can make full use of its capabilities.

For Assurety API documentation, visit https://developers.paystand.com

Building Towards An Assurety Solution

At Paystand, we set out to be a blockchain company aiming to solve problems that affect businesses with their cash lifecycle. Over the years we have built several blockchain products intended to meet these needs. At each step we learned a lot about the blockchain ecosystem as well as the unique needs and requirements of our B2B partners. Below is a chronology of our blockchain journey, the issues we addressed, the things we did well, the lessons we learned, and how we improved with each step.

Business payments over Bitcoin

We started our journey enabling Bitcoin [1] payments for some of our earliest customers. We found out quickly how hard it can be to branch into a disruptive technology like the blockchain while maintaining solid relationships with some of our more traditional banking partners.

Traditional bank partners were worried about the direct value transfer between parties using the blockchain technology.

In addition, we found that many of the pain points our business customers were experiencing were related to the interconnections between their business processes.

An invoice could be sent by party A, but how could they know it was received by party B? How can both be sure the terms of the invoice didn’t change over time? If a payment is paid, how are both parties notified, so that the invoice gets reconciled?

These types of problems led us to focus on this unique class of problems faced by B2B companies and how blockchain can play an important role beyond just transfer of value scenarios.

Certifying Business Payments

Our first step into solving these B2B problems was to begin certifying our customers’ payment records on the public Bitcoin blockchain. This sidestepped the issue of direct value transfer between parties while adding real value to our customers.

The certifications were stored on the blockchain as one-way fixed-size cryptographic imprints (SHA-256) [2]. This enabled the payment data to be immutable, small in size, and private while stored on the blockchain. Once the imprint was stored, anyone with access to the original data could then re-perform the cryptographic imprinting and compare it to the imprint stored on the blockchain. Since the imprint on the blockchain is immutable, the only data that could be imprinted and match the blockchain imprint must be the original data.

Paystand: certifying business payments using an enterprise blockchain.

There were a few drawbacks to this original design.

For one, in order to validate any certified data, all of the data was required to be revealed to the verifying parties. Not all use cases, however, call for this level of transparency to a verifier.

Consider a payment that occurs between two parties A and B, where party A pays party B. It is reasonable to assume that both parties should have access to the fully certified data. Suppose now that A wants to prove to party C (maybe an insurance company) that they made the payment to B. It’s not necessarily true that A or B wants C to know all of the details of the payment, such as the payment methods used, or fees paid. Maybe all that C needs to know is who were the parties involved, the amount, the date, and a description of why the payment was made. This was not possible to achieve in a straightforward way with our first Bitcoin-based approach

The drawbacks of using bitcoin to certify payments.

Another drawback was that there really wasn’t any cohesive or unifying grouping of the various things being certified. By this, we mean that given any two certification imprints, there really wasn’t any way to know what the purpose of the imprint was. Was it for an invoice? A payment? If it was for an invoice, what was the format of the data?

From the blockchain’s perspective, there was just a bunch of random imprint data stored on it. It was up to traditional applications to remember where the imprints were stored and what they meant.

Bitcoin offered no way to categorize different imprints.

Though Bitcoin was designed well as a distributed means of value transfer, it wasn’t really designed for storing state (such as imprints) or performing computations based on that state.

Learning from our experience building a Bitcoin blockchain solution for payment certifications, we decided to move our next project to the public Ethereum blockchain. [3]

Powering AP Approval Workflows

We wanted to harness the power of Smart Contracts to store state and design a distributed system that would automate the Accounts Payable (AP) payout approvals flow for our customers.

Smart contracts are bytes of code deployed to a blockchain that are run and verified by every node on the network. Smart contracts have reserved memory space so they can store state that can be referenced by the code of the smart contracts. [4]

A closer look at how smart contracts work

Users in Paystand are able to have one of two roles, admin or clerk. Clerks would create and schedule payouts and then request approval from an admin to activate the payouts. Although seamless to the end-users, behind the scenes the approval request and the approval itself were being securely recorded on the Ethereum blockchain as a permanent audit trail.

How Paystand used the Ethereum blockchain to create a permanent audit trail for customers.

Ethereum wallets were created for each user in the system and securely stored. The wallets allowed us to uniquely identify who was taking each action on the blockchain. Each time a clerk requested approval from an admin, the request would be recorded on a smart contract, detailing who was making the request, the date, which payout was being requested, and an optional requested by date. The data was encrypted to keep it private. When an admin would approve the payout, the data on the smart contract would be updated to include the identity of the approver and the approval date.

The Ethereum smart contracts were a major improvement over the more restrictive Bitcoin blockchain.

One drawback to this design was the speed of confirming transactions on the public Ethereum blockchain. We wanted to try to tie our business logic to the state stored on the smart contract, but given the delays in getting confirmations from other nodes, sometimes the application would not get immediately updated and compensating messaging was required to help the end-user understand what was happening.

Another issue we came across was the operational aspect of funding the contract interactions. Every action on the public Ethereum blockchain requires gas and gas costs Ether. Paystand doesn’t operate in Ether, though; it operates in USD, among other fiat currencies.

So, to fund the necessary wallets with enough Ether, we needed to convert USD to Ether programmatically, wait the necessary amount of time to receive the Ether and then distribute to various wallets as needed.

We needed to monitor the balance on the various wallets to potentially refresh them, which could trigger new USD to ETH conversions and distributions. As the ETH gas prices and the USD to ETH rates would fluctuate, it wasn’t always clear how much ETH we should have on hand at any one time to optimize our value.

Blockchain-Based Assurety

Learning from our Ethereum experience, we wanted to update our Payment certification product into a more mature product that we are calling Payment Assurety and Assurety-as-a-Service. As our first entry into solving some of these B2B use cases, Paystand has implemented a permissioned Proof-of-Authority (PoA) chain we call the Assurety Chain. Its intention is to optimize creating, managing, and verifying non-fungible assets on the blockchain.

Introducing Assurety-as-a-Service. Visit https://paystand.com/assurety

Satisfying B2B Requirements

Consider a large corporation with many divisions. Each division has its own systems and responsibilities, wants to tightly control their own data, but wants a means to securely share some of that data with other divisions in an automated, fast, verifiable, and unalterable way.

They may also want to have business processes automated based on that shared and verifiable data, making the business processes themselves verifiable.

Traditionally, the approach used by companies to store, manage and verify data comprises a centralized IT infrastructure (like a centralized database) which is managed and overseen by a single entity (the IT team) which has to be implicitly trusted not to misuse or tamper with the data. However, news outlets have no shortage of stories of companies falling out because of one or a couple of internal bad actors that tampered with some of the data that they had access to.

For this reason, its undesirable for any one division to completely own the servers, technology, means of communication, or data involved in the process. Forward-thinking companies want all divisions to own and contribute to the health and functioning of the system, get a say in its functioning, ensure that their data is untampered with and that the system survives in the absence of some of these divisions.

This is of course just one example, but additionally, in the Business to Business (B2B) space, there is a desire these days to find ways to build systems that allow businesses to connect to each other with all or most of the properties mentioned above.

No one business owns the system, servers, network, protocol, or means of communication.
Transactions occur quickly.
Finality is reached quickly (ie transactions cannot be reverted)
Data can be shared privately or publicly.
Control over who can connect to the network (ban be open or closed to reading the blockchain)
Control over who can submit transactions to the network (can be open or closed to writing to the blockchain)
Transactions on the network only pertain to the business use cases.
Business processes can be automated.
Cost of transactions should be low.
There can be a limited amount of trust among network members.

In addition, someone outside of the network of participants should not be able to:

Discover the identity of members on the network.
Discover the number of members on the network.
Discover transaction frequency on the network.
Discover private data on the network.

Here, we are using the term network loosely to refer to a group of businesses that are participating in one or more common use cases, and not to the network protocol as a whole that they may be using to accomplish their use cases.

A business network could be embedded in a larger chain network, or they could be communicating with another chain to share information. In both cases, the above four rules regarding the network privacy should be upheld.

Let's see how various blockchain technologies address these B2B concerns.

Public blockchains

When people think about blockchains, they tend to think about Bitcoin or Ethereum. These are examples of public blockchains, meaning that they are open publicly for anyone to write transactions to the blockchain, and they are open publicly for anyone to read transactions from the blockchain.

Public blockchains have a high degree of openness as well as transparency while still allowing untrusted parties to participate. These qualities have allowed public blockchains to solve a large class of problems that were previously out of reach.

For businesses looking to use a public blockchain, the business network of participants would be embedded on the larger public blockchain rather than being a separate chain network themselves.

Public blockchains do enable some of the properties of the B2B use cases:

No one business owns the system, servers, network, protocol, or means of communication.
Data can be shared privately. This can be done using smart contracts and various encryption schemes.
Control over who can submit transactions. This can be controlled on the smart contract level (not the network level). But for B2B use cases this level of access control can get you pretty far.
Business processes can be automated via smart contracts.

Despite these positive properties, they also make difficult other B2B use cases, such as:

It is hard to keep the number of members or their identities private. Blockchains are pseudo-anonymous, and tracking an address’s activity can often lead to discovery of their identity.
The transaction frequency of members is discoverable. Since every transaction is publicly visible on the blockchain and all transactions come from addresses, all member transactions are discoverable.
The cost of transactions are variable and are relatively expensive.
There is no control over who can connect to the network. Controlling who can connect to the network is one way to prevent discovery of member identity and transaction frequency.
To participate all transactions must be downloaded and validated, not just the businesses use case.
Finality is reached probabilistically rather than with certainty.

All of the openness and transparency of public blockchains comes at a cost of efficiency of storage, computation, or time to reach finality. Probably the most cited form of inefficiency on public blockchains is the PoW consensus mechanism.

Proof-of-Work (PoW)

Today, the public Bitcoin and Ethereum blockchains rely on Proof-of-Work (PoW) as a means to resist Sybil attacks and attain Byzantine Fault Tolerance (BFT).

Sybil attacks occur when an attacker can take on multiple identities in order to flood the network with blocks that are indistinguishable from legitimate blocks, likely rewriting the blockchain’s history. Byzantine fault tolerance is the ability of a network to resist malicious actors in the system (such as someone conducting a sybil attack) and continue to correctly propose and verify blocks.

PoW requires that each proposed block has a property called difficulty that equates to a certain amount of expensive work (computations). Since the work required to create a block with the correct amount of difficulty is expensive, it becomes very expensive for any given node to attempt to flood the network with their malicious blocks.

A hash for a block is created by taking the hash of the previous block, a nonce (some random number), and the transactions to be contained in the block and hashing them together.

To prove that work has been accomplished, each node attempting to propose a block is required to attempt to find a number, the nonce, such that when the block hash is created using that nonce, the resulting hash has a predetermined number of leading zeros.

Attempting to find such a number takes an exponential amount of time as the number of zeroes required increases, but attempting to verify that a given nonce has the correct number of leading zeroes is as simple as re-hashing the block and counting the number of leading zeroes.

Since each block must have a certain amount of work associated with it and work takes time and resources, the amount of time to reach probabilistic finality for any given block also takes a non-trivial amount of time.

In a purely trustless system, it appears that you need to pay these types of resource taxes rather than using trusted authorities. In B2B use cases where there is a limited amount of trust that can be tolerated in the system, it is not clear that these resource taxes need to exist at all.

Permissioned blockchains offer alternative solutions.

Permissioned blockchains

Permissioned blockchains are blockchains that have a certain amount of trust built in, while still allowing degrees of openness. They offer the ability to make transactions private, allow permissions for which nodes can connect to the network, and can control which addresses are allowed to submit transactions to the network.

[14*. Include image here of above example]

They typically use consensus protocols that rely on trusted validator nodes to propose and verify transactions on the network. Using validator nodes offers many improvements over more open consensus schemes such as PoW or PoS.

Blocks can be committed to the blockchain at faster intervals
Have non-probabilistic finality guarantees
Allow node-level permissioning
Allow transaction-level permissioning
Supports privacy schemes.
Transactions don’t rely on crypto-economics (ie transactions can be free) as validator nodes are already incentivized to secure the network.
They can be much smaller than public blockchains, as they only need to validate their own transactions.
Unlike PoW, there is no requirement to produce a difficulty property, so the amount of resources required for each validator is far lower.

Since permissioned chains are isolated from other chains by default and have features in place to control access for membership, there are no outside actors that can:

Discover the identity of members.
Discover the number of members.
Discover transaction frequency of members.
Discover private data.

Proof-of-Authority is one type of consensus protocol that can be used to enable permissioned blockchains.

Proof-of-Authority (PoA)

In a PoA chain, a list of validators are chosen to propose and validate new blocks on the network.

In terms of the CAP theorem[5], PoA favors availability over consistency, making PoA an AP systems. In blockchain terms, availability refers to the ability of nodes to validate and approve blocks to the blockchain, and consistency refers to the likelihood of forks occurring on the network or the time taken to reach finality.[6]

Being AP systems then, PoA protocols are highly available and blocks will continue to be generated at consistent rates. This comes at a cost of tolerating potential forks with weak to eventual consistency guarantees, depending on the exact PoA protocol that is chosen.

Permissioned blockchains using a PoA consensus algorithm meet all of the requirements for B2B use cases mentioned above. Two of the requirements deserve further mention, however.

No one business owns the system, servers, network, protocol, or means of communication.

Whereas this is true, the risk in a permissioned blockchain is in the possibly smaller number of total nodes on the network and the number of validator nodes assigned to the network. The task here is to balance trust with openness. Forming consortiums where parties with different interests and incentives are a part of the validator ecosystem is critical.

Finality is reached quickly.

Not all PoA systems have the same finality guarantees. With PoA protocols forks are able to occur which can create uncertainty and leave finality up in the air for a period of time. Some protocols, such as the Clique protocol used by the Ethereum Geth client, fallback to the Ethereum GHOST protocol [7] to resolve forks. This results in finality being eventual. In particular, this means that the finality of a transaction is not immediate, but it is also not probabilistic as it will eventually be certain that a transaction cannot be reverted.

Hybrid Blockchains

Permissioned blockchains offer better performance, faster finality, more privacy, while still being open among participant members. The tradeoff though is in total network size.

As a blockchain network grows, security tends to increase. This is because there are more members of the network that are able to keep the network honest.

In a permissioned blockchain where the only nodes able to write to the ledger are a select few validators, this becomes an important factor.

Public blockchains tend to have a larger number of network nodes in addition to each network node also being a writer. This allows for much better security as collusion on the network becomes much harder.

What we would prefer is to have the best of both worlds.

Anonymous State Pinning

With any solution there are tradeoffs, and with PoA the low latency and predictable times for finality come at a cost: participants in the network must trust the validator nodes not to collude. Validators in a B2B scenario may have a shared interest, for example, in modifying a previous transaction and possibly creating a fork of the chain.

The very idea of Assurety assumes that this very situation should never happen. Once a fact is recorded on the blockchain and reaches finality, all parties who have an interest in that fact should have certainty that the fact can never be undone.

To prevent collusion in a PoA architecture, while still maintaining its performance and finality guarantees, we view the Paystand Assurety chain as a sidechain of the public Ethereum blockchain and use anonymous state pinning to secure the state of the Assurety sidechain.

With anonymous state pinning, a special management contract is deployed to the public Ethereum blockchain. Private and public delegates are selected from the Assurety chain to propose and validate to the management contract the hash of the most current block in the Assurety chain.

The act of recording this block hash on the public Ethereum blockchain is called pinning the state of the Assurety chain.

Once an Assurety chain block hash has been pinned to the management contract, that pin has a period of time in which delegates from the Assurety chain can contest the pin. When the period to contest has passed, the pin is final and cannot be undone. [11]

In a consortium environment, such as the Assurety Chain, where there are fewer total nodes to verify the network and less diversity of interests, it is easier for collusion to occur. To maintain trust in the network, utilizing larger networks such as the public Ethereum blockchain is desirable.

Anonymous state pinning allows facts about the state of the Assurety chain to be recorded in a private and secure way on a network that is much harder to tamper with. It also has several properties that are required to maintain the privacy of the Assurety network from the public network:

It hides the identity of the members of the network.
It hides the transaction rates of members on the network.
It maintains the privacy of data on network.

How Customer Data Gets Assured

We have talked about how Paystand uses permissioned blockchains and PoA consensus to drive the Assurety Chain network. We haven’t yet talked about how we use the Assurety Chain to actually assure customer data.

Assurety uses smart contracts, non fungible tokens, imprints and disclosures to issue, keep track of, disclose, and verify the Assurety of data.

Fungibility, tokens and digital imprints

Fungible tokens are the tokens we typically think of when we think about cryptocurrency. They have no unique identity in the sense that any token can be used in the same way as any other token. If one token has a value, then all tokens of that type carry the same value. These are useful as a store of value and value transfer.

Non-fungible tokens (NFT) are similar to fungible tokens, but differ in that each non-fungible token is unique. A single dollar bill is the same as any other single dollar bill in that any two can be swapped for one another and still used in the same exact way. A single diploma, however, is not the same as any other diploma. A person cannot use their friend’s diploma as their own since their diploma is unique and speaks to the work they put into achieving that diploma. A diploma is an example of a non-fungible token.[8]

Assurety generates a digital imprint of a real-world asset, creates an NFT token containing that digital imprint, and issues the asset to the Assuror.

As mentioned previously, a problem with the design of the Payment Certification product was that in order to verify some of the data, it was required that all of the data be revealed to a verifier. This was a result of the digital imprint in that case being generated from a simple hash of the data.

What we were looking for was a solution where a set of data can be assured on the blockchain, but only a subset of that data would be required to be revealed to a verifier in order for the verifier to be certain that the data that they received was indeed assured on the blockchain.

To satisfy this digital imprinting problem we looked toward a data structure that is already heavily used in blockchain technology and has similar properties to the solution we are after: merkle trees.

Merkle trees and audit proofs

Merkle trees are used heavily in blockchain technologies to structure transactions into blocks. Rather than storing a long list of transactions into a block, each transaction is hashed and then grouped together to form a binary tree structure. Each transaction hash is a leaf of the tree, and each parent node of the tree is formed by hashing the hashes of its two immediate children. The parent of all the nodes is called the root node or the merkle root of the merkle tree. [9]

This type of structure is helpful to blockchains as the hash contained in the merkle root uniquely identifies the set of all transactions contained inside the block. Any change to any transaction would change the merkle root and thus the hash of the block.

Another nice property of merkle trees is that audit proofs can be created that can prove that a transaction exists in the block by only referencing a small number of the total nodes in the merkle tree. The process of generating these proofs has been well documented elsewhere so we won’t reiterate it here but suggest looking at [10] for further details.

In particular, audit proofs allow a subset of data points contained within a merkle tree to be verified to exist within the tree without requiring all of the original data. It is this property that we exploit to enable more advanced digital imprinting and disclosure properties to Assurety.

Merkle roots as digital imprints

Paystand Assurety uses merkle trees to imprint the data to be assured and then uses merkle audit proofs to selectively reveal data to third-party verifiers.

Assurety data can be any valid JSON object. To convert the JSON object to a merkle tree, we flatten the object to an array of data points represented by the data path to the value and the value itself.

We then take a hash of each value and deterministically build the merkle tree.

We call the root node of the generated merkle tree the digital imprint. It’s this imprint that ultimately gets stored on the Assurety chain as a non-fungible token.

Audit proofs as disclosures

In order to disclose data to a third party, the creator of the Assurety record selects a list of data points to reveal. Paystand then builds a list of merkle audit proofs for each value and returns those proofs along with the disclosed values.

Both the disclosed values and the proofs can be sent to a third party.

The third party can then verify:

that the disclosed values are contained in the provided proofs
that the provided proofs lead to a specific merkle root (and thus to a digital imprint)
that the computed imprint is the same imprint that is stored on the Assurety blockchain.

What’s Next

A lot of work and planning went into the blockchain Assurety project but more ideas and additions are planned in the near future.

Consortium Adoption

As adoption of Assurety-as-a-Service grows, we will aim to bring in more business partners as consortium members, enabling more validators to secure the network and reduce the risk of collusion among members as more diverse business interests are added.

IBFT Protocol

Practical byzantine fault tolerance (PBFT) protocols are an alternative to PoA protocols. PBFT is a network protocol that was created to efficiently solve the Byzantine Generals problem before blockchains existed. To apply the ideas of PBFT to the blockchain, the Istanbul BFT (IBFT) protocol was created.

Like PoA, IBFT uses validators to propose and validate blocks. Unlike PoA, IBFT favors consistency over availability, making it a CP system in terms of the CAP theorem. This means the protocol does not allow forks to occur, or put another way, that it offers instant finality once a block is committed to the blockchain. By sacrificing availability, though, it means that under malicious attacks the network is not guaranteed to produce new blocks.

IBFT tends to be slower than PoA protocols (but not always) due to the number of messages required to be communicated between nodes before a block is committed.

For a class of business use cases, such as Assurety, where its critical that data that is committed to the blockchain reach finality as soon as possible, IBFT has a lot to offer.

PoA is an improvement over PoW in the time to reach finality as well as finality being non-probabilistic for PoA protocols. The strong consistency guarantee (instant finality) of IBFT, however, is probably a better fit than PoA in the long run for Assurety. Businesses are likely to accept less availability, Assurety being blocked, in favor of consistency, certainty that things that were Assured can never be undone.

We will be looking to update the Assurety consensus protocol to IBFT in the future.

Hybrid Blockchain

Furthering the security of the Assurety Chain network is critical. The first version of the network contains the core Assurety Chain as a PoA permissioned blockchain. In the near future we will be adding anonymous state pinning to enable the permissioned chain to sync to the public Ethereum blockchain.

Conclusion

We’ve come along way since our initial beginnings with Bitcoin payments. The unique landscape of B2B interactions has shaped and evolved our understanding of the many ways blockchains can be used and has open us up to using a more diverse set of blockchain technologies.