Description:F O R M 2

THE PATENTS ACT, 1970
(39 of 1970)

COMPLETE SPECIFICATION
(See section 10 and rule 13)

TITLE
A METHOD FOR SECURING TRANSACTIONS RECORDED IN A RECORDCHAIN

INVENTORS:
GUNTHA, Ramesh – US Citizen
Center for Wireless Networks & Applications (WNA),
Amrita Vishwa Vidyapeetham, Amritapuri, Kerala, India

APPLICANT
AMRITA VISHWA VIDYAPEETHAM
Clappana P.O Amritapuri, Vallikavu, Kerala 690525, India

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED:

A METHOD FOR SECURING TRANSACTIONS RECORDED IN A RECORDCHAIN
CROSS-REFERENCES TO RELATED APPLICATION
[1] None.
FIELD OF INVENTION
[2] The present disclosure relates to securing data using recordchain technology, more particularly, it relates to securing recorded transactions in a blockchain database with multi-hash record chaining technique.
DESCRIPTION OF THE RELATED ART
[3] The impact of information technology in enhancing everyday life is unmistakable across various sectors such as education, healthcare, travel, banking, commerce, governance, and security. However, despite three decades of technological progress, the vision of a seamless, interconnected ecosystem that unifies entities within and across domains – such as consolidating medical records from different hospitals or integrating educational, financial, and employment records – remains largely unfulfilled. Data often remains siloed within proprietary systems of corporations and governments, and true integration within even single domains such as education or health within a specific region is uncommon. Blockchain technology, initially heralded as a solution for universal interconnected systems, has predominantly found its niche in the financial sector. Its broader application is hindered by performance limitations that impede its adoption for everyday use.
[4] Private blockchains address some performance issues but raise concerns about inclusivity and transparency. There is also a lack of adoption due to lack of a sufficient number of participants to realize the benefits of data sharing. The reason for this lack of participation are complexity issues in adopting and customizing the private blockchains. Another reason for the non-adoption of private blockchains is that, while offering data privacy, they also cause security concerns among the participants, as they must implement robust security measures to protect against insider threats and vulnerabilities. This causes an additional technical burden on the participants. Because of these complex technical issues in ensuring data protection], private blockchains were not able to enter the threshold of the common man’s daily life, despite being highly scalable compared to public blockchains.
[5] Various publications have tried to address the problems encountered when using blockchains for storing information. PCT publication 2020102246A1 discloses mechanisms to manage permissions to access user data in a distributed ledger trust network. PCT publication 2022238066A1 discloses method of generating a blockchain transaction with each second party associated with a public key and each public key is associated with an index. Chinese publication 116132055A discloses high-efficiency log audit system and method based on a multi-merck hash tree. Sun et. al in “Blockchain-based Secure Storage and Access Scheme For Electronic Medical Records in IPFS” discusses cipher text policy attribute-based encryption system and IPFS storage environment, combined with blockchain technology. In “The Design and Development of Decentralized Digilocker using Blockchain”, Chavan et. al. mentions usage of a file system which is a showcase of ethereum Dapps, where the encryption keys are prolonged and open just to the end client. Hyungmin Cho discusses evaluation of the level of ASIC resistance of the multi-hash PoW mechanisms in “ASIC-Resistance of Multi-Hash Proof-of-Work Mechanisms for Blockchain Consensus Protocols”.
[6] Presently, there is a requirement of for scalable and secure interconnected systems based on collective databases, while maintaining the privacy of users and the integrity of their data.
SUMMARY OF THE INVENTION
[7] The present subject matter relates to recording, securing and viewing transactions in a Recordchain by chaining the records.
[8] In one embodiment of the present subject matter, method for recording, securing and viewing transactions in a Recordchain by chaining records using multi-hashing is disclosed. The method includes recording transactions in the Recordchain, obtaining multi-hash having hash of previous records, wherein the multi-hash maybe in static or dynamic format, encrypting a content in the new record with content owner’s public key for preventing unauthorized access of the record and generating an owner’s lock by signing the encrypted content with owner’s private key. The method further includes generating a record lock by hashing the multi-hash obtained and the owner’s lock for chaining the new record with previous records, creating a table-lock for a table maintaining the records in the Recordchain, the table-lock comprises maintaining a table level private key and generating a table lock by signing the new record lock with the table level private key andviewing recorded transactions from the Recordchain.
[9] In various embodiments, the multi-hash maybe derived from hashing of the record locks of all previous records in a predetermined sequence.
[10] In various embodiments, the Recordchain is access controlled based on roles and wherein the roles include a source, a content owner, a viewer, a main system and a review system.
[11] In various embodiments, recording transactions into the Recordchain includes generating content for the new record by the source, obtaining approval of the content owner for insertion into the database, recording the approved contents by the main system and updating a transaction log with the new record and securing the new record with a new record lock and updating the table-lock based on the new record-lock. It further includes providing the transaction to the content owner for confirmation, sending the confirmed transaction to the review system for storage and used for periodical review or optionally used by the viewer to review andgenerating confirmation for the content owner after review of the transaction.
[12] In various embodiments, viewing the recorded transactions includes communicating a request for viewing recorded transactions from the viewer to the content owner, requesting access to recorded transactions for viewing from the main system and review system by the content owner after approving the communication request by the viewer, determining integrity of recorded transactions using upstream multi-hash checks at the main system and reviewer system and providing requested recorded transactions to the content owner for verification with the content owner’s lock. It further includes decrypting the recorded transactions with content owner’s private key, encrypting the recorded transactions with the viewer’s public key and signing with owner’s private key, providing the encrypted recorded transactions to the main system by the content owner for storage in a temporary table with an expiry date andaccessing of the encrypted recorded transactions from the temporary table by the viewer using the viewer’s private key.
[13] In various embodiments, obtaining approval of the content owner for insertion into the database includes signing the content to be inserted with the source’s private key, encrypting the content with the owner’s public key by the source, decrypting the content by the owner with private key to determine the authenticity of the content by checking the digital signature of the source with the source’s public key and approving the content after verification by encrypting the content using the owner’s private key.
[14] This and other aspects are described herein.

BRIEF DESCRIPTION OF THE DRAWINGS
[15] The invention has other advantages and features, which will be more readily apparent from the following detailed description of the invention and the appended claims, when taken in conjunction with the accompanying drawings, in which:
[16] FIGS. 1A and 1Billustrate the method and flow diagram of securing transactions recorded in a Recordchain, according to an embodiment of the present subject matter.
[17] FIG. 2illustrates recording of transactions in a Recordchain, according to an embodiment of the present subject matter.
[18] FIG. 3 illustrates approval of record to be inserted in a Recordchain, according to an embodiment of the present subject matter.
[19] FIG. 4illustrates theviewing of transactions in a Recordchain, according to an embodiment of the present subject matter.
[20] FIGS. 5A and 5B illustrate the flow diagram of recording transactions for e-wallet and the database for e-wallet respectively, according to an embodiment of the present subject matter.
[21] FIGS. 6A and 6B illustrate the variation in Transactions Per Second (TPS) and Latency relative to the number of concurrent users across three different testing configurations respectively, according to an embodiment of the present subject matter
[22] Referring to the figures, like numbers indicate like parts throughout the various views.

DETAILED DESCRIPTION OF THE EMBODIMENTS
[24] While the invention has been disclosed with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt to a particular situation or material to the teachings of the invention without departing from its scope.
[25] Throughout the specification and claims, the following terms take the meanings explicitly associated herein unless the context clearly dictates otherwise. The meaning of “a”, “an”, and “the” include plural references. The meaning of “in” includes “in” and “on.” Referring to the drawings, like numbers indicate like parts throughout the views. Additionally, a reference to the singular includes a reference to the plural unless otherwise stated or inconsistent with the disclosure herein.
[26] The present subject matter describesa method for securing transactions of a Recordchain. A method of recording and viewing transactions in a Recordchain is also disclosed. Data security is ensured through a multi-hash record lock, owner’s lock, and table-lock, thereby robustly safeguarding against unauthorized modifications. The blockchain is decentralized with a main system functioning as the central hub that processes all incoming requests from client interfacesand a reviewer system that act as independent verifiers of the main system’s data. Further, the Recordchain is access controlled based on roles such as a source, a content owner, a viewer, a main system and a review system
[27] A method 100 for recording, securing and viewing transactions in a Recordchain is illustrated in FIG. 1A. In a first step 102 of the method, transactions are recorded in the Recordchain. Then the recorded transaction is secured by obtaining multi-hash that includes hash of the previous records in step 104. In the third step 106, content in the new record is encrypted with a content owner’s public key to prevent unauthorized access of the record. In the next step 108, an owner’s lock is generated by signing the encrypted content with the owner’s private key. Further, in step 110 a record lock is generated by hashing the multi-hash obtained in step 104 and the owner’s lock to chain the new record with previous records. A table-lock is created for a table for maintaining the records in the Recordchain in step 112. The table lock includes maintaining a table level private key and generating a table lock by signing the new record lock with table level private key as mentioned in step 114 and 116 respectively. In step 118, the secured recorded transactions may be viewed from the Recordchain.
[28] In various embodiments, the multi-hash maybe derived by hashing the record locks of all previous records in a predetermined sequence as illustrated in FIG. 1B. The multi-hash maybe in static or dynamic format, these formats are dynamically generated by incorporating a diverse range of inputs such as passwords, security keys, system IDs, owner IDs, source IDs, table names, record IDs, timestamps, and constraints such as the maximum number of historical records and the multi-hash length. Users may change the multi-hash and inputs based their specific requirements to facilitate both versatility and security in record-linking.The multi-hash, derived from the record locks of preceding records, is amalgamated with the owner's lock of the current record within a hash function to generate the record lock for the current record. This links the content of the current record to that of many previous records, as well as to the owners of all the records. Thusensuring a tight interconnection between the current and historical data, reinforcing the security and integrity of the record chain.
[29] In various embodiments, the table lock safeguards the most recent record in a table from being tampered with by a potentially malicious owner, particularly in the period after insertion and before the addition of a subsequent record. This lock functions as a single, designated record for each table and is managed by the main system. It is created by digitally signing the latest record lock with the table-level private key, Additionally, the table lock is updated concurrently with the insertion of the latest record, ensuring that the two are always in sync. This means that if an owner attempts to alter the most recent record, the table lock, which is an integral part of the table, will no longer match the altered record. This discrepancy serves as a robust safeguard, effectively preventing unauthorized modifications to the latest record and maintaining the integrity of the table's data.
[30] In various embodiments, the Recordchain access is structured through a defined set of user roles, wherein the user roles include a source, a content owner, a viewer, a main system and a review system. A source refers to the authorized entity responsible for providing data that is to be recorded in the Recordchain. The source may include schools or government educational boards that issue grades and certificates, employers who furnish work experience documentation, banks that report account statuses and credit information, and hospitals that supply medical records. A content owner refers to the individual or entity to whom the data, provided by the source, is attributed. This may be a student in the case of academic records, an employee for work experience documents, an account holder for banking information, or a patient for medical records. Although the data is originally generated by the source, the content owner retains control over the access of their data, ensuring personal autonomy and privacy in the management of their information.
[31] In various embodiments, a viewer is any registered user with the Recordchain interested in viewing the data belonging to another user. The viewer requires approval from the respective content owner to access their data and the approval is provided with an expiry date-time. A main system encompasses the core databases and servers, functioning as the central hub that processes all incoming requests from multiple client interfaces used by sources, content owners, and viewers. The client interfaces may include tablets, laptops, mobile devices, desktops etc. The Recordchainutilizes a select number of reviewer systems that act as independent verifiers of the main system’s data. The verification is not conducted during the transaction process unlike traditional Blockchainsbut is carried out periodically or, optionally, by a viewer at the time of data retrieval. The reviewer systems maintain a replicated version of the main system's database, receiving data directly from the Sources. Their primary function is to conduct regular data verification, both with the main system and amongst themselves. This facilitates the viewers in requesting specific records from the reviewer systems for comparison, thereby enhancing the trustworthiness and precision of the data retrieved from recordchain.In various embodiments, the Recordchain can seamlessly integrate with traditional database systems, such as relational or document databases enabling upgrades with minimal modifications. This approach ensures minimal disruption to current system in use asthe tables that require secured transactions are selectively migrating to Recordchain.
[32] In various embodiments, recording transactions into the Recordchain is illustrated in FIG. 2. In step 202, content for the new record is generated by the sources. Approval of the content owner is obtained for the new record before insertion into the Recordchain as mentioned in step 204. In third step 206, the approved contents are recorded by the main system and a transaction log is updated with the new record that has been inserted. Further, the new record is secured with a new record lock and the table lock is updated based on the new record lock in step 208. In step 210, the transaction for a successful record insertion is provided to the content owner for confirmation. The confirmed transaction is sent to the review system for storage and used for periodical review or optionally used by the viewer to review the content in step 212. In step 214, confirmation is generated for the content owner after review of the transaction.
[33] In various embodiments, approval of content by the content owner before insertion of content into the Recordchain is illustrated in FIG. 3. In step 302, the content to be inserted from the source is signed with the source’s private key. Further, the content is encrypted by the source with the owner’s public key in step 304. In step 306, the content to be inserted is decrypted by the content owner using their private key to verify the authenticity of the content by checking the digital signature of the source with the source’s publickey. After verification of the content, approval is provided by the content owner by encrypting the content with owner’s private key in step 308.
[34] In various embodiments, viewing of the recorded transactions from the Recordchain is illustrated in FIG. 4. A request for viewing recorded transactions from the viewer to the content owner is communicated in step 402. In step 404, access to recorded transactions for viewing is requested by the content owner from the main system and review system after approving the communication request by the viewer. Integrity of recorded transactions is determined using upstream multi-hash checks at the main system and reviewer system in step 406. The requested recorded transactions are provided to the content owner for verification with the content owner’s lock in step 408. Further in step 410, the recorded transactions are decrypted with content owner’s private key. The recorded transactions are encrypted with the viewer’s publickey and signed with owner’s private key in step 412. In step 414, the encrypted recorded transactions is provided to the main system by the content owner for storage in a temporary table with an expiry date and in step 416 the encrypted recorded transactions are accessed from the temporary table by the viewer using the viewer’s private key.
[35] The method for recording, securing and viewing transactions in a Recordchain has several advantages over prior art particularly for reduction of computational power and cost. The implementation necessitates the addition of just a few extra columns to the tables needing protection. These columns are used to store the multi-hash record lock, owner-lock, and encrypted content, thereby avoiding extensive modifications to the majority of the system. This computational efficiency is facilitated chaining individual records rather than bunching multiple records into blocks and then chain the blocks as is done in blockchains. Chaining records allows a user to maintain the existing database architecture without any modifications. Furthermore, the extra computing power needed to extend the existing system is also minimal. This is because the additional processing is primarily for computing hashes and encrypting record content, which does not significantly burden the system. Unlike traditional blockchains that group transactions into blocks to mitigate the computational delays inherent in consensus algorithms, this blockchain preserves the efficiency of indexing, querying, visualizing, and analyzing data, which is crucial for the users. Data security is ensured through a multi-hash record lock, owner’s lock, and table-lock, thereby robustly safeguarding against unauthorized modifications. Additionally, the integrity of the data is further reinforced by the reviewer systems, which conduct periodic verifications, ensuring the reliability and accuracy of the stored information.
[36] Although the detailed description contains many specifics, these should not be construed as limiting the scope of the invention but merely as illustrating different examples and aspects of the invention. It should be appreciated that the scope of the invention includes other embodiments not discussed herein. Various other modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the system and method of the present invention disclosed herein without departing from the spirit and scope of the invention as described here, and as delineated in the claims appended hereto.
EXAMPLES
[37] EXAMPLE 1: Implementation of multi-hashing
[38] A sample implementation of a function to generate the sequence of record IDs that will be part of a multi-hash is provided. The inputs are system ID, source ID, owner ID, table name, record ID, maximum number of historical records to consider for the multi hash (maxHistRecs), and the length of the multi-hash (multiHashLength). The multiHash function in JavaScript, utilizing Node.js's crypto module, generates an array of hash-based identifiers for records. It first constructs a unique string from various input parameters such as systemId, sourceId, ownerId, tableName, and recordId, concatenating them with underscores. This string is then hashed using SHA-256 to create a buffer. The function iterates up to a specified multiHashLength, extracting bytes from the hash buffer in a loop. In each iteration, it calculates an index by taking the modulo of the current hash byte with maxHistRecs, a parameter representing the maximum historical records. The function keeps track of its position in the hash buffer, cycling back to the start if it reaches the end. For each iteration, it computes a hash-based record identifier by adjusting the recordId with the calculated index, adding these identifiers to an array. This array, representing a series of historical records, who’s record-locks will be concatenated in that order to derive the combined multi-hash of the current record denoted by the recordId. It shows the example invocation of the multi-hash function and with the corresponding output. The output consists of record IDs that are part of the multi-hash function of current record ID 108. Itmay be noted that a particular record may be included more than once based on the format and the inputs.
[39] EXAMPLE 2: Probability of multi-hash failure
[40] Assuming that the attacker is outsider, who does not have the access to method or the inputs but has information of the Recordchain and wants to hack the data of a record, then the attacker must also modify all the records that use the hash from this record, and keep going till the latest record. The probability P of correctly identifying the set of records involved in a multi-hash of a given record is given below.
Let R be the index of the record under attack.
Let L be the index of the latest record
Let D be the distance of R to L.
D = L - R
Let H be the number of historical records maxHistRecs.
Let M be the length of multi-hash format maxLength.
The probability of correctly identifying the given sequence of records in the multi-hash for single record is given as below.
PR = (1/H)M
[41] The probability of correctly identifying all the hashes up to the latest record is given below.
PD = (PR)D+1
= ((1/H)M)D+1
= (1/H)M*(D+1)
if maxHistRecs = 36, maxLength = 18
D = 0 (latest) PD = (1/36)18 = 9.6951601232x10-29
D = 1 PD = (1/36)36 = 9.3996129814x10-57
D = 2 PD = (1/36)54 = 9.1130752951x10-85
D = 3 PD = (1/36)72 = 8.8352724201x10-113
D = 4 PD = (1/36)90 = 8.5659380845x10-141
D = 5 PD = (1/36)108 = 8.3048141334x10-169
D = 6 PD = (1/36)126 = 8.0516502817x10-197
D = 7 PD = (1/36)144 = 7.8062038737x10-225
D = 8 PD = (1/36)162 = 7.5682396510x10-253
D = 9 PD = (1/36)180 = 7.3375295267x10-281
[42] It can be observed from the above, that the probability for obtaining the correct multi-hash sequence is essentially zero for an attacker who is an outsider, even if they are trying to attack the latest record.
[43] EXAMPLE 3: Implementation of the role based Recordchain across domains.
[44] Recordchain may be implemented within and across multiple domains such as education, employment, medical, finance, chit-fund groups, wallets, energy, etc. TABLE I provides details about the content of the shared database and potential entities in each role.
TABLEI: Examples of Implementations
Domain Content Source Owner Viewer
Education & employment Grades, certificates, awards, skills, experience, and research publications Institutions and organizations Student or staff Institutions, organizations, governments, and other authorities
Medical Medical history, Allergies, Tests, Medication, Vaccination history, Pre-existing conditions, Insurance Hospitals, Pharmacies, Labs, Insurance agencies Patient Hospitals, Pharmacies, Insurance Agencies, Other authorities
Finance Accounts, Fixed deposits, Loans, Credit cards and other transactions Banks Account holder Banks, Government, Other institutions, and organizations
Chit fund groups Account debits, credits, balance, and loans Chit-fund group head Account holder Group members, group head, etc.
e-Wallets & Vouchers Wallet credits, debits, and balance Point of Sale systems for credits and account holder for debits. Account holder Agency, shops, restaurants, and other debtors.
Energy Electricity consumed and generated, periodic bills and payments, account balance Energy providers and Account holders Energy producers and consumers Energy producers and consumers
[45] TABLE II compares the Recordchain with public and private blockchains in the aspects of participation, protection, performance, and implementation.
TABLE II:Comparison of Recordchain with Public and Private blockchains

Aspect Public Blockchain Private Blockchain Recordchain
Participation Open to everyone to maintain nodes, send any transaction, and view all transactions All operations are controlled by central authority and the approved participants Open to any registered institution/organization to send data about the registered Owner. Information viewing is controlled by the registered Owner.
Authenticity of Data Digital signatures Digital signatures, Authentication, and Access control Access control given to authorized institutions
Protection from Updates Hashes, Chained blocks, Decentralization, Consensus mechanisms Hashes, Chained blocks, Decentralization, Consensus mechanisms Multi-hash record lock, owner’s lock, table lock, reviewer system
Privacy of Sender Name anonymization Authentication Authentication
Privacy of Content None Access control Owner’s public key encryption
Performance Transaction recording performance is too slow because of expensive consensus mechanisms such as Proof of Work etc. A payment should be made to the minors or transaction facilitating nodes in crypto currencies Supports high transaction throughputs because fewer number of nodes in private blockchains and inexpensive consensus mechanisms Supports same transaction throughputs as regular database systems because the only overhead is the various hashing and encryption mechanisms. There is no consensus mechanism. The replication cost is also low because there are only a handful of reviewers.
Implementation/Migration Migrating is challenging due to the need for consensus protocols and the bundling of records into blocks. Migrating is challenging due to the need for consensus protocols and the bundling of records into blocks. Since the Recordchain chains records and there are no consensus protocols, it is very easy to migrate an existing system with minimal changes.
[46] The designated interfaces require adequate authentication and authorization protections so that a regular user should not be able to subvert the system inadvertently. TABLE III illustrates the various protection mechanisms of the blockchain against attacks from outsiders and insiders through the means of custom and unauthorized interfaces. Except in the case where the main system and reviewer systems are compromised, and the attackers are modifying their own records, the system is protected against all other attacks
TABLE III:Attacks and Protections
Attacker Data Attack Examples Protection Mechanism
Outsider Earlier records Modify or delete contents of earlier records of Others and Own. Increase the grades of earlier classes attended by self and accordingly changes the owner’s lock of own records.
Reduce or delete the grades of others from earlier classes. Own records: Later records’ multi hash becomes inconsistent.
Others’ records: Without the other user’s SK, the content cannot be modified, if content is modified, apart from multi hash, the owners lock also becomes inconsistent.
Outsider Latest record Modification of latest record owned by the user Increase the deposit of e-Wallet The table-lock becomes inconsistent if the user tries to update the latest record.
Main System Insider Earlier records Modification of earlier records of Others and Own, and change the multi-hash of all the corresponding records Modify or delete the grades of earlier classes Own: Reviewer’s systems are out of reach for the system admin, hence it becomes inconstant with the reviewers’ systems
Others’: Without the access to user’s SK, the content cannot be modified, if the content is modified the owners lock becomes inconsistent.
Main System Insider Latest record Modification of latest record of Others and Own, and change the system lid Modify the deposit of e-Wallet Own: Reviewer’s systems are out of reach for the system admin, hence it becomes inconstant with the reviewers’ systems
Others’: Without the access to user’s SK, the content cannot be modified, if the content is modified the owners lock becomes inconsistent.
Insider of Main System and Reviewer System Earlier records Modification of earlier records of Others and Own, and change the multi-hash of all the corresponding records Modify or delete the grades of earlier classes Own: Vulnerable
Others’: Without the access to user’s SK, the content cannot be modified, if the content is modified the owners lock becomes inconsistent.
Insider of Main System and Reviewer System Latest record Modification of latest record of Others and Own, and change the system lid Modify the deposit of e-Wallet Own: Vulnerable
Others’: Without the access to user’s SK, the content cannot be modified, if the content is modified the owners lock becomes inconsistent
.

[47] EXAMPLE 4: Implementation of Recordchain for e-wallet
[48] To illustrate the simplicity of migrating an existing system to the Recordchain and to study the performance impacts, it was implemented in a simple e-wallet system and upgraded the system to Recordchain. The implications of the throughput of the transactions and latency were studied. Throughput ismeasured as the number of Transactions per Second (TPS), and latency is measured in milliseconds.The system consists of two types of users; the Citizen and the Point of Sale (POS) users. The POS user is the Source of the data and the citizen user is the Owner of the data. The citizen would make credit or debit transactions through the POS users. The system validates the incoming transaction against the account balance creates the transaction records and updates the account balance accordingly.
[49] The system has 3 modes: Regular mode, Recordchain without encryption and digital signatures, and Recordchain with encryption and digital signatures. This is done to assess the impact of various components of Recordchain on performance.With the addition of Recordchain to the system, the client signs, encrypts, and adds the owner-lock, and the content before sending it to the system. The system verifies the signature, validates the transaction, creates the transaction entry, creates a table-lock, and updates the Account table as shown in FIG. 5A. The system database has 4 tables. The User table stores the user registration details and the public key, and the Transaction table stores the transaction details such as amount, credit/debit, the POS user ID, and the owner user ID (by user ID). The Account table has the latest account balance for quick validation of incoming transactions as shown in FIG. 5B. The Transaction-Lock table which stores the table lock of the Transaction table.
[50] The testing was conducted on an M1 MacBook Pro laptop, utilizing server code written in JavaScript on Node.js. Given the laptop's 8-core architecture and Node.js's single-threaded nature, we ran 8 Node.js instances simultaneously to fully utilize all CPU cores. The objective of the test was to isolate and evaluate the server's Transactions Per Second (TPS) and processing-induced latency, excluding any latency caused by network factors. To achieve this, the client code was also executed within the same Node.js environment. Depending on the test configuration, the client simulated multiple concurrently operating user agents. These agents continuously sent credit/debit transaction requests to the server without any breaks, allowing for a focused assessment of the server's performance capabilities.
[51] Testing was conducted across three distinct server modes: first, the regular system mode without Recordchain implementation; second, a partial Recordchain setup featuring multi-hashes, table-lock, record-lock, and owner’s-lock but excluding content encryption, digital signatures, and signature verification; and third, the complete Recordchain implementation, which incorporates digital signatures, signature verification, and content encryption in addition to the aforementioned features.
[52] During testing, each mode was evaluated with a range of concurrent users, varying from 80 to 8000. The Transactions Per Second (TPS) and average latency in milliseconds for each test run was measured, with results presented in FIGS. 6A and 6B.
[53] In the No Recordchain mode, TPS began at approximately 6000 for 80 users, peaking at around 7000 TPS for 560 users, and then stabilized irrespective of the number of users. In contrast, both Recordchain modes (with and without encryption) consistently showed a TPS of around 2500, regardless of user numbers. When comparing the regular system to the full Recordchain implementation with hashing and encryption, there was a notable reduction in TPS to 35% of the original as shown in FIG. 6A. Therefore, to match the TPS of the regular system, Recordchain would require more than triple the server capacity during peak load periods.
[54] Latency demonstrated a linear increase with the rising number of concurrent users. In the regular system without Recordchain, latency varied from 14 milliseconds for 80 users to 1400 milliseconds for 8000 users. For both Recordchain modes, with and without encryption, latency spanned from 36 milliseconds for 80 users to 3500 milliseconds for 8000 users. Notably, at 560 concurrent users, where the TPS in the regular mode reached its saturation point of 7000, the latency in the Recordchain mode was 250 milliseconds. The rate of latency increase was remarkably similar for both regular systems and Recordchains without encryption, as shown in FIG. 6B. This similarity indicates a consistent performance impact in these configurations, highlighting the efficiency of the Recordchain system in managing latency, even under varying user loads.
[55] Analyzing the TPS data in the regular mode without Recordchain, it was observed that TPS reached a saturation point of 7000 at 560 concurrent users on the MacBook Pro M1 laptop. This saturation indicates the hardware's capacity limit for our e-Wallet system implemented in JavaScript/NodeJS. Beyond this user count, TPS remained constant, but latency continued to rise. The introduction of Recordchain and encryption added to the CPU load and increased databaseread/write operations due to additional columns, resulting in lower TPS and higher latency.
[56] Despite this performance drop, the Recordchain modes showed a consistent trajectory without exponential degradation, suggesting that performance could be aligned with the regular system by employing parallel servers and database sharing technologies.
[57] While the latency in the fully implemented Recordchain solution appears higher compared to the regular system, it's important to note that the highest latency recorded was 250 milliseconds for 560 concurrent users, where TPS peaked at 7000 in the regular mode. This latency is considerably lower than many production blockchain implementations. The increased latency primarily stems from intensive CPU computations for hashing, signatures, and encryption, rather than from the additional storage demands of Recordchain data. Therefore, by augmenting the server with more CPUs, the latency could potentially be reduced and brought in line with the regular system's performance. This approach underscores the feasibility of optimizing the Recordchain solution to achieve efficiency comparable to traditional systems, while benefiting from the enhanced security and integrity features of Recordchain technology.
, Claims:WE CLAIM:
1. A method (100) for recording, securing and viewing transactions in a Recordchain by chaining records using multi-hashing, the method comprising:
recording (102) transactions in the Recordchain by chaining the records;
obtaining (104) multi-hash having hash of previous records, wherein the multi-hash maybe in static or dynamic format;
encrypting (106) a content in the new record with content owner’s public key for preventing unauthorized access of the record ;
generating (108) an owner’s lock by signing the encrypted content with owner’s private key.
generating (110) a record lock by hashing the multi-hash obtained and the owner’s lock for chaining the new record with previous records;
creating (112) a table-lock for a table maintaining the records in the Recordchain, the table-lock comprising:
maintaining (114) a table level private key; and.
generating (116) a table lock by signing the new record lock with the table level private key; and
viewing (118) recorded transactions from the Recordchain.

2. The method (100) as claimed in claim 1, wherein the multi-hash maybe derived from hashing of the record locks of all previous records in a predetermined sequence.

3. The method (100) as claimed in claim 1, wherein the Recordchain is access controlled based on roles and wherein the roles include a source, a content owner, a viewer, a main system and a review system.

4. The method (100) as claimed in claim 1, wherein recording (102) transactions into the Recordchain comprises:
generating (202) content for the new record by the source;
obtaining (204) approval of the content owner for insertion into the database;
recording (206) the approved contents by the main system and updating a transaction log with the new record;
securing (208) the new record with a new record lock and updating the table-lock based on the new record-lock;
providing (210) the transaction to the content owner for confirmation;
sending (212) the confirmed transaction to the review system for storage and used for periodical review or optionally used by the viewer to review; and
generating (214) confirmation for the content owner after review of the transaction.

5. The method (100) as claimed in claim 1, wherein viewing (118) the recorded transactions comprises:
communicating (302) a request for viewing recorded transactions from the viewer to the content owner;
requesting (304) access to recorded transactions for viewing from the main system and review system by the content owner after approving the communication request by the viewer;
determining (306) integrity of recorded transactions using upstream multi-hash checks at the main system and reviewer system;
providing (308) requested recorded transactions to the content owner for verification with the content owner’s lock;
decrypting (310) the recorded transactions with content owner’s private key;
encrypting (312) the recorded transactions with the viewer’s public key and signing with owner’s private key;
providing (314) the encrypted recorded transactions to the main system by the content owner for storage in a temporary table with an expiry date; and
accessing (316) of the encrypted recorded transactions from the temporary table by the viewer using the viewer’s private key.
6. The method (100) as claimed in claim 4, wherein obtaining (204) approval of the content owner for insertion into the database comprises:
signing (402) the content to be inserted with the source’s private key;
encrypting (404) the content with the owner’s public key by the source;
decrypting (406) the content by the owner with private key to determine the authenticity of the content by checking the digital signature of the source with the source’s public key; and
approving (408) the content after verification by encrypting the content using the owner’s private key.

Sd.- Dr V. SHANKAR IN/PA-1733
For and on behalf of the Applicants