Comment on page

Off-Chain and On-Chain Storage of Digital Signatures

As previously stated in different segments of this white paper, when a user signs a legally binding contract and creates a digital signature, that signature will be stored on the Interplanetary File System, or IPFS. This section of the white paper will discuss the benefits of storing signatures on IPFS, the security measures taken to store signatures publicly, and how the Phynite Protocol can eventually support the storage of digital legal signatures on the Ethereum blockchain itself.

Benefits of Storing Digital Signatures on IPFS

IPFS is a distributed and immutable peer-to-peer (p2p) storage network, and its permanence and non-centralized functionalities have made it a popular tool in the Web3 space. When a file is added to IPFS, [4] the file is split into smaller chunks, cryptographically hashed, and given a unique fingerprint called a content identifier (CID). The CID acts as a permanent record of your file as it exists at the point in time. This means that to overwrite previously uploaded files on IPFS, new CIDs must be generated, making the file system immutable. Furthermore, a node can pin content in order to keep (and provide) it forever, and the permanence paired with the ability to query the stored files using HTTPS gateway providers have made it the most popular solution for storing large files that are connected to NFTs.
Using IPFS, digital signatures can now serve as permanent digital receipts that can verify the validity of legally binding contracts. Although the hope is that the legally binding contracts used by the Phynite Protocol will never be brought to court, the contracts exist to serve this exact purpose: the legal obligation for both parties to be honest prevents the need for trust and reduces the likelihood of bad actors.

Security Measures for Publicly Storing Digital Signatures

To verify the validity of digital signatures created by users who have signed legally binding contracts, you need the original legally binding contract, the wallet address of the crypto wallet used to sign, and the digital signature. This could impose a security risk however, as the wallet addresses and digital signatures associated with the Phynite Protocol are publicly stored information, and one could theoretically guess the contents of the legally binding contract associated with each digital signature. The contents of the legally binding contracts hold privacy-sensitive legal contact information of users, therefore there must be steps taken to ensure security for users.
This issue can be solved quite simply, however, and it is done by simply requiring a digital signature from companies like Phynite and including it in the message signed by users. When a user generates a legally binding contract so that they can purchase a CBNFT, a secure server holding public and private key pairs of an Ethereum account can automatically sign the legally binding contract prior to the user signing such contract. This will make the contracts legally binding, as it is signed by an authorized server that can sign on behalf of companies like Phynite, and increase the cryptographic security of the Phynite Protocol. For malicious actors to now guess the private contact information of users, they would have to have the original legally binding contract (including users’ private contact information) and the private key of the company’s Ethereum account to generate an identical signature, making it nearly impossible for such events to occur.

Storing Digital Signatures On-Chain

The Ethereum blockchain can be simply thought of as a distributed database that stores immutable history of transactions. Instead of a distributed ledger like Bitcoin, [5] Ethereum is a distributed state machine. Ethereum's state is a large data structure which holds not only all accounts and balances, but a machine state, which can change from block to block according to a predefined set of rules, and which can execute arbitrary machine code. This allows for smart contracts to store data inside the Ethereum blockchain, which is a powerful function if used correctly.
To further solidify the validity of the digital signatures of legally binding contracts, we can use the power of smart contracts to store the signatures on-chain. Although it does come with a small cost in gas fees to write more data onto the blockchain, the feature will add the benefit of decentralizing the storage of the digital signature. Without this feature, companies like Phynite and their users will each have to store the digital signature. However, this data can be securely stored on the blockchain, and the blockchain does not lie.
To address the issue regarding the extra gas fees necessary to store more data on the Ethereum blockchain, we can use a solution that many NFT projects already use: storing data on IPFS and storing the IPFS URI (Uniform Resource Identifier, Ex: ipfs://[CID]) on the blockchain. Although signatures produced by signing with crypto wallets are not too large in terms of character length, the size difference in terms of percentage is quite large when scaled. Such digital signatures are 132 characters, which is 149% longer than IPFS URIs which are 53 characters. Such data will need to be stored as a string type variable (variable type offered by Solidity, the most popular object-oriented programming language for implementing smart contracts on Ethereum), which has a data size dependent on the number of characters.