A blockchain is an open, distributed ledger that can record transactions between parties in a verifiable manner. The blockchain facilitates transactions in a variety of industries including supply chain management, real estate, media, energy, identity management, and record management.

Typically, most blockchain platforms do not store anything too large in the blockchain itself owing to the low storage capacity of blockchains and the high cost of storage. A common solution these platforms employ to tackle this problem is to store only the hash of a large object in a smart contract and then store the bulk of the object elsewhere.

A smart contract is a self-enforcing computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. The concept of smart contracts was designed by Nick Szabo in 1977. In a blockchain, a smart contract can store a great deal of information about an object's origin, its lineage, and the onboarding process that resulted in the on-chain immortalizing of a certain hash which everyone will recognize as authentic.

A user in possession of an object needs to hash the object and then use the smart contract to confirm its authenticity and inspect other details. Also, a user can commit to his/her smart contract data and then append to his/her transaction the values that he/she wants to update with the associated cryptographic proofs.

Notwithstanding its immense benefits, smart contracts have certain limitations. First of all, a smart contract offers a bounty to anyone who will provide a solution to a mathematical problem, such as the solution to a given Sudoku, without any outline on how it will check whether a given solution is correct. Also, a smart contract defines and implements financial derivatives without any procedure for checking the actual transaction value. For instance, a smart contract can entail that user A will pay user B a premium if the value of a euro coin raises above 1.5 dollars in a month. However, the smart contract does not have an outline to check the actual value of the euro after the given duration. These and other inherent issues limit the scalability of smart contract technology.



To better understand the proof problem, let us consider this scenario;
A given user named Greg has three documents — a driver's license, a passport, and a birth certificate — with each document represented by a JavaScript Object Notation (JSON) that includes all the data fields present. Each JSON object is issued by an authoritative registry with a smart contract that records the hashes of authentic documents. No document gets on the list without following the strict on-boarding process of the smart contract.

Now, let us assume that Greg wants to show another user named Jane his date of birth without disclosing any further personal details. Since each of the three documents contains a date of birth, Greg has three possible ways to reveal his birth date to Jane.

Given each form of the document is easily authenticated by a hash on a blockchain, Jane will be able to consult the appropriate registry which would confirm the authenticity of any document Greg decides to reveal. However, for this to work, Greg would have to give Jane the entire document. Therefore, Greg faces a dilemma. He has three documents to choose from, but each document contains more information than Greg wants to reveal such as his home address, his travel history, and his place of birth depending on which of the documents he chose to reveal.

Although Greg can say these documents contain a certain date of birth, Jane cannot independently prove that Greg is telling the truth unless he reveals one of these documents in detail, which Greg does not want to do. Greg cannot prove anything without selecting one of the documents and disclosing it to Jane in its entirety. Again, Greg does not want to do that

How can Greg prove that he is telling the truth about a single field? How can this be done without revealing the other important personal details or moving the important fields to expensive on-chain storage in the registry contracts? This scenario illustrates the proof problem of smart contracts.



To tackle the smart contract proof problem, several approaches were designed by blockchain developers. To tackle the smart contract proof problem, several approaches were designed by blockchain developers. Prominent amongst these are TownCrier and Merkle Proofs.

TownCrier proposes a system that allows on-chain smart contracts to require external web data, already accessible through TLS and HTTPS. TownCrier architecture is composed of a smart contract that acts as front-end for the other on-chain client contracts, an enclave running in a Software Guard Extensions (SGX) Intel environment, and a relay that handles the communication of the enclave with the blockchain and provides attestation on the guarded execution of the enclave.

A major limitation of the TownCrier approach is that there is a significant form of centralization upon the TownCrier gateway. Hence, there is no security against the attack of the relay on the shutting down of the enclave. Also, an attestation cannot be directly verified by the originating smart contract. Therefore, an incorrect behavior of the enclave due to an attack or other reasons cannot be noticed by the originating smart contract.
Merkle Proofs, on the other hand, proves the existence of a value within a data set. For a Merkle Proof to work, users need a Merkle Tree. A Merkle Tree recursively hashes pairs of values until finally there is only one hash left known as the Merkle Root.

The use of Merkle Trees is the traditional way taken by Ethereum and some other blockchains to commit to a set of data. However, Merkle Trees are known to possess very long proofs. For instance, a user that commits to 1000 values in a smart contract would need to propagate 320 bytes of additional data (cryptographic proof) to change just one of the values. This can eat up a lot of network bandwidth and add substantial costs for nodes participating in the consensus of distributed networks, where every transaction propagates across all nodes. To solve these problems, the Algorand blockchain designed PointProofs.



PointProofs is a new vector commitment scheme that supports non-interactive aggregation of proofs across multiple commitments. These PointProofs enable a user to commit to a sequence of values (V1, V2....Vn) and probably reveal one or more values at specific positions at a later time. With PointProofs, both the commitment and the proof size are just 48-bytes.

Also, PointProofs enable any third party to aggregate a collection of proofs for different, independently computed commitments into a single proof represented by an elliptic curve point of 48-bytes. Cross-commitment aggregation is a brand-new feature which none of the previous approaches achieved. PointProofs also satisfy hiding properties such that commitments and proofs for some values will reveal no information about the remaining values.

When applied to blockchain smart contracts, PointProofs can reduce bandwidth overheads for propagating a block of transactions by at least 60% compared to prior vector commitments. PointProofs are also efficient as it takes 0.08 seconds to generate a proof for 8 values for one commitment on a single thread, 0.25 seconds to aggregate 4000 such points across multiple commitments into one proof, and 23 seconds to verify the aggregate proof.

In conclusion, the Algorand blockchain-designed PointProofs can be used to reduce on-chain storage and minimize network bandwidth requirements. This helps the blockchain to enable more efficient decentralized networks for smart contracts. Developers, especially in countries like Nigeria with a teeming population ready to adopt the blockchain technology, can take advantage of this feature to develop efficient, decentralized and secure smart contract solutions.