Crypto 2.0 Musings - Audit and Assurance

To protect consumer rights in the UK, there are four important acts, directives and laws that you must comply with if you are selling goods or services online: The Electronic Commerce (EC Directive) Regulations 2002, The Data Protection Act 1998, The Distance Selling Act 2000 and ICO Cookie Law.

These regulations require the seller to provide clear and concise information about products before purchase, show clearly postage and packing costs, indicate whether VAT is included on the prices shown, acknowledge and follow up every online order by written communication, stipulate in terms and conditions 14 day returns period whereby a customer can cancel or return their order for a full refund, etc.

Regulation compliance assurance is based on annual audits that generate reports as evidence. This regime is expensive to implement and yet allows companies to go rogue without detection for up to a year, and can miss issues as is sample based. The assurance process is expensive because current e-commerce technology offers little in terms of automated proofs.

Credit card companies offer recourse services to mitigate against some of these and other risks, but charge transaction fees to offer this form of insurance. Overall assurance and insurance costs are significant and are invariably passed on to the consumer. There is also the time and money the buyer has to spend on dispute resolution and the opportunity cost of dispute-locked cash.

Buyer's transactions are not signed, which means they can be faked and altered. Neither the buyer nor nor the seller can prove integrity and non-repudiation. Nor are they linked to agreed upon instructions as to how they should be processed correctly, so buyers have to hope that their transaction is executed faithfully by some opaque process that should match agreed to legal terms but may change under the hood without guaranteed consent; and not only by the system that a buyer interacted with, but by any other third party system that is called during execution. Neither buyer nor seller can easily prove process correctness.

Furthermore, contemporary databases can be altered by any employee or hacker with little in a way of temper detection as long as they have admin rights. Neither buyer nor seller can easily prove that records are correct and have not been mutated since last agreed upon version, in case of dispute. Often the only way to resolve the dispute is via a long and expensive legal recourse route. 

Let's compare this with blockchain systems: 

• Buyers create digitally signed transactions specifying what should be done and how by including smart contract code hash.
• Any tempering can be automatically detected by recalculating the signed hash i.e. integrity guarantees assure everyone that no one including the system operator can alter the transaction without detection, and in doing so protects the system operator from false-positive dispute claims.
• Only private key holders can sign the hash i.e. non-repudiation guarantees assure everyone that no one including the system operator could have created the transaction, assuming private keys have not been leaked, and in doing so protects the system operator from false-positive dispute claims.
• Smart contracts can interact with other smart contract by sending digitally signed transactions that include code hashes of called smart contracts using their own-content-hash as private key material.
• Such a scheme preserves integrity and nonrepudiation guarantees along the entire call chain, from human to machine, and machine to machine.
• Blockchain virtual machines like Ethereum Virtual Machine (EVM) are designed to execute smart contracts in a completely deterministic way by always executing code in the same manner and not being able to fetch outside state i.e. consensus guarantees.
• When auditing a system it is important to ensure that transactions when processed in agreed order should always yield exactly the same outcome i.e. machines with consensus guarantees are required, unfortunately many of today's popular machines process some code in pseudorandom manner and allow external state fetches, which are not deterministic and do not have integrity and non-repudiation guarantees.
• Successfully processed transactions on blockchain are stored in hashed and chain-linked blocks that are either replicated or block hashes are signed and anchored in other databases i.e. offering uniqueness, existence, order and immutability guarantees.
• The seller needs to check a payment transaction's spend existence and order before handing over goods to prevent double-spend or over-spend fraud, so ability by blockchain systems to uniquely identify a transaction by simply hashing its contents and then checking for existence of spend and order, if found, is very important.
• Once the seller is satisfied with their checks, they need immutability guarantees on blockchain to be able to rely on the system going forwards in case of dispute. Whilst it's impossible to change any part of the transaction or order without altering block hashes e.g. it's very quick and cheap to detect tempering using blockchains, it's relatively trivial for someone like a hacker or a fraudster with admin rights to re-write the chain unless all of the transactions, or at least signed block hashes are also stored and anchored by others e.g. users, auditors and regulators - in which case chain re-writes can be quickly detected and proven.
• The seller also wants to make sure that the smart contract code satisfies their needs without always understanding the code e.g. no double-spend, and the regulators want to make sure that the code enforces correct regulation to protect the users e.g. statutory right for refunds. In other words there is a requirement for correctness guarantees.
• Formal proofs can now be applied to smart contracts executed by EVM, as EVM is simple and is easily modelled unlike more complex VMs, thereby proving that the code performs as specified under all circumstances i.e. correctness guarantees.
• A Turing complete system that allows execution of arbitrary complex code can be attacked and ground to a halt by forever looping code, so there is a need for halting guarantees.
• Blockchain VMs like EVM require spend of gas purchased using fuel coins e.g. Ether, which is burned by the EVM for each op-code used i.e. an infinite loop will cost an unlimited amount of Ether, which is in itself limited, as such mitigating the attack vector and providing halting guarantees. That - and a handy automated charging mechanism!
• Since smart contracts can hold assets under escrow, it is therefore possible to lock buyer’s money into an escrow account for 14 days to guarantee returns policy compliance, whilst allowing the seller to collect interest and factor that money for improved cash flow.

As you can see, blockchain systems offer guarantees simply not available in contemporary systems. However, best known blockchain networks introduce privacy, performance, scalability and excessive redundancy penalties because of their public and fully decentralised nature. They are designed as such to remove organisation formation friction, ensure that anyone can always access all data to verify correct execution of smart contract code and participate in consensus process, thus preventing rogue agents from cheating or censoring the process.

For some use cases these trade offs are justifiable, often in the cross-border markets with high degree of distrust and no natural authority. However in circumstances where centralised solutions already exist and users are mostly comfortable with trusting them, or privacy is mandated, it’s possible to adapt centralised systems by adding blockchain characteristics. Such systems would offer blockchain like guarantees and benefits of ditching people, process and technology debt, without the privacy, performance, scalability and excessive redundancy penalties. As trust increases, risk decreases, driving reductions in cost of transactions and reserved capital, to the benefit of the buyer and the seller.

Such systems could rely on contemporary parameter security to execute and store centrally private code and transactions. To reduce the ability of a system operator to snoop on transactions and improve privacy and trust, code could be executed inside a Trusted Execution Environment. Such a scheme can be extended to support fully decentralised operations in the future, see my Autonomous Validators blog. As solutions like zero knowledge proofs and fully homomorphic encryption mature, see my Privacy and Confidentiality blog, further decentralisation, if desired can be achieved without sacrificing privacy.

Immutability without decentralisation and proof-of-work or proof-of-stake consensus algorithms can be achieved by operators signing block hashes and sending them to buyers as digital receipts, and anchoring them on public blockchains and/or with auditors and regulators. Any state i.e. blockchain mutation, would be quickly picked and proven by buyers and auditors. 

Resiliency can be maintained by a single system operator running multiple nodes and either using Paxos or Raft consensus protocols, if parameter security is good enough and performance and scalability are important, or using practical byzantine fault tolerance, proof-of-work, proof-stake or proof-elapsed-time consensus protocols if not.

To ensure that the business logic is correctly executed, auditors could periodically or on demand take a sample transaction and re-execute it on a sterile system they maintain. They can prove correctness if the hash of the auditor’s output state matches that of the operator for the entire population, rather than the small sample we achieve with today’s audits. 

It's possible to not only link transactions to business logic, but also to legal terms and conditions through the use of Ricardian Contracts. In effect, transaction's structured data is embedded as markup in a legal contract, and linked to a smart contract hash. Under normal circumstances the transaction is processed by the smart contract, whilst exceptions are processed by pre-specified humans and organisations. Such a system fits nicely into existing legal and regulatory frameworks.

Since audit is now in effect automated, it can be done on a very frequent basis, or on demand for a fraction of the today’s cost, thanks to blockchain guarantees. Need for expensive legal recourse or at the very least wasted time and illiquidity of assets under dispute is reduced.

In fact, since regulation can be expressed as code, and code can be proven to meet a specification using formal proof techniques, and it’s performance can be proven through automated audits, the entire system automates regulation performance, compliance, audit and assurance. Result is a safer, faster and cheaper system, to the benefit of both the buyer and the seller. 

The downside of this approach is the persistence of data monopolies and opportunity for censorship. In some cases this may be intolerable, but in other cases it may be acceptable. In fact even Bitcoin has a light SPV client that only stores block hashes and relies on full nodes for data access. The upside is that the client can be lightweight and rely on a central services or a decentralised network to do the heavy lifting.

Whilst I have discussed e-commerce in this blog, this same pattern can be applied to any fiduciary system. I think the benefits of both centralised and decentralised blockchains is enormous!