Patent Application
20240412281
Aspects of this technology were disclosed at “She Codes 2022,” held at Princess Nourah bint Abdulrahman University on Oct. 12-13, 2022, and are herein incorporated by reference in its entirety.
The present disclosure is directed to a bidding system that is implemented using blockchain technology.
The “background” description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present invention.
Bidding is one process that is used to select a vendor for subcontracting a project, or for purchasing products and services that are required for a project. The project may be formally described in a project specification. A project specification describes the specifications of the project or details of the products and services to be purchased. A bid document describes the specifications and estimated costs of the project. The bid document also contains a list of potential vendors.
Many agencies seeking a Request for Proposal (RFP) or a Request for Quote (RFQ) utilize online portals to submit bid documents. Online submission of bid documents leaves the bidding process vulnerable to information leakage and data manipulation.
Information leakage is a serious problem faced by online bidding systems, as it leads to the unfair selection of the winning bidder. In the case of data manipulation, a bid document may be inappropriately viewed and/or modified by third parties at any point between where it is first submitted to the point where it is opened.
It is one object of the present disclosure to describe a system and method that ensures that the bid is not leaked to and/or modified by third parties. It is a further object of the present disclosure to achieve data integrity and privacy.
An aspect of the present disclosure is a computer-based bidding system for bidding on a project, can include a first computer configured to create a project specification that includes a list of potential bidders; a plurality of second computers for the potential bidders to bid on the project; a blockchain computer system for maintaining a blockchain; at least one of the plurality of second computers configured to execute a first encryption encrypting bid information immediately after creating a bid information file, calculate a first hash value H1for the bid information file, and submit the first hash value H1 for linking as a block B1 in the blockchain; the blockchain computer system configured to perform a second encryption upon receiving the encrypted bid information, calculate a second hash value H2 for a first encrypted bid file C1, and submit the second hash value H2 for linking as a block B2 in the blockchain; the at least one second computer configured to perform a third encryption when the bid information file is opened to generate an encrypted opened bid information file; and the at least one second computer performing a bidding process with the first computer using the bid information file.
A further aspect of the present disclosure is a non-transitory computer-readable storage medium storing program instructions for computer-based bidding system for bidding on a project, the program instructions which when executed by a computer system, perform a method that can include creating, by a first computer, a project specification that includes a list of potential bidders; executing, by at least one of a plurality of second computers, a first encryption encrypting bid information immediately after creating a bid information file, calculating a first hash value H1 for the bid information file, and submitting the first hash value H1 for linking as a block B1 in a blockchain maintained in a blockchain computer system; performing a second encryption in the blockchain computer system upon receiving the encrypted bid information, calculating a second hash value H2 for a second encrypted bid file C2, and submitting the second hash value H2 for linking as a block B2 in the blockchain; performing a decryption in the second computer when the bid information file is opened to generate a decrypted opened bid information file; and performing a bidding process using the bid information file.
The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure, and are not restrictive.
A more complete appreciation of this disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:
In the drawings, like reference numerals designate identical or corresponding parts throughout the several views. Further, as used herein, the words “a,” “an” and the like generally carry a meaning of “one or more,” unless stated otherwise. The drawings are generally drawn to scale unless specified otherwise or illustrating schematic structures or flowcharts.
The disclosure herein describes a blockchain platform configured for project bidding. This platform aims to provide a highly secured process that ensures the security of the bidding files provided by the bidders. Different techniques and security-based methods are used to solve all the matters that might affect the trust and confidentiality of this bidding process. In particular, the blockchain is implemented in a manner that guarantees the data integrity and privacy of each step through three layers of hashed values that securely protect the most important and sensitive parts of the bidding process.
A blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a computer network, which in the present disclosure are bid information files. In the present disclosure, all bidding clients have access to the distributed ledger and its immutable record of transactions. With this shared ledger, transactions are recorded for actions performed on the bid information files. No participant can change or tamper with a transaction after it's been recorded to the shared ledger. If a transaction record includes an error, a new transaction must be added to reverse the error, and both transactions are then visible.
Blockchain workstations 101, 103 verify transactions with a consensus algorithm. Two widely used consensus algorithms include proof of work and proof of stake. The proof of work consensus algorithm uses complex problems for miners to solve using a high-powered blockchain workstation. In proof of stake consensus, miners pledge an investment in digital assets before validating transactions. To validate new blocks, miners put up stake with assets of their own. Miners may also show how long they have been validating transactions. Different from proof of work, the choice for which miner validates each transaction is random using a weighted algorithm, which is weighted based on the amount of stake and the validation experience. Other consensus mechanisms can be used. Other consensus mechanisms, include, but are not limited to, Delegated Proof of Stake, Proof of Activity, Proof of Authority, Proof of Burn, Proof of Capacity, Proof of History, and Proof of Importance.
As each transaction occurs, it is recorded as a “block” of data. Once a transaction is verified, the transaction is added as a new block to a blockchain. Each block is connected to the ones before and after it. Furthermore, the transactions are blocked and related together in an irreversible chain: the blockchain.
The blocks confirm the exact time and sequence of transactions, and the blocks link securely together to prevent any block from being altered or a block being inserted between two existing blocks.
Each block in a blockchain is a structure that includes a header and a body. The header contains a hash of the previous block, a time stamp when the block is created, a nounce, and a Markle root. The body contains one or more transaction hashes and a time stamp associated with the respective hashes.
To perform transactions, a set of rules, called a smart contract, is stored on the blockchain and executed automatically. A smart contract can define conditions for processing of a bid information file.
In some embodiments, the computer system 200 may include a server CPU and a graphics card by NVIDIA, in which the GPUs have multiple CUDA cores. In some embodiments, the computer system 200 may include a machine learning engine 212.
The hash function module 311includes one or more one way hash functions, such as MD5 and SHA-1. A one-way hash function, also known as a message digest, is a mathematical function that takes a variable-length input string and converts it into a fixed-length binary sequence that is computationally difficult to invert, that is, generate the original string from the hash.
The consensus module 315 contains the functions necessary to perform a consensus method/algorithm to verify the addition of a block to the blockchain. As mentioned above, two widely used consensus algorithms include proof of work and proof of stake. Other consensus mechanisms may be used for verifying the addition of blocks to the blockchain. In the case of the proof of work consensus algorithm, the consensus module 315 provides the complex problems for miners to solve. In the case of proof of stake consensus algorithm, the consensus module 315 receives and stores each miner's pledge in digital assets. The consensus module 315 may also receive information from miners that indicates how long they have been validating transactions. The consensus module 315 can perform a weighted algorithm to choose which miner is to verify a transaction, where the weighted algorithm is weighted based on the amount of stake and the validation experience.
A conflict resolution system module 317 can include a function to resolve conflicts such as an invalid block, and attempt to insert an invalid block, and an unknown miner.
A block encoder/decoder module 321 can encode or decode blocks, files and/or documents for sending.
An encryption/decryption module 325 can perform one or more encryption algorithms. The encryption algorithms preferably include an asymmetric encryption method. In such case, each new project and bid will have a private and a public key. Asymmetric cryptography uses two different keys for encryption and decryption. The public key is used to encrypt a message, while the private key is used for decryption. The encryption/decryption module 325 is configured for an asymmetric encryption method, including, but not limited to, an integer-based asymmetric encryption such as RSA, and elliptic curve encryption.
In the case of RSA, encryption is performed such that plaintext is raised to the power of the public key. The public key is the product of two large distinct primes. This value is then divided by a public modulus and the remainder is sent as the ciphertext. Decryption is performed, but using the private key instead of the public key to produce the plaintext.
In the case of elliptic curve cryptography, instead of using integers for its calculations, elliptic curve cryptography uses points on an elliptic curve. A private key is still a random number, but a public key is a point on the elliptic curve.
A message broadcasting/receiver module 327 performs sending of and receiving of messages between the blockchain computer system and the miner workstations.
The smart contract 400 in
In disclosed embodiments, blockchain technology is used to record all bids in order to guarantee that the data will not be modified. To achieve the privacy of information, three layers of protection are applied including encrypting the bid information (bid information file) immediately upon sending it, then making a second encryption upon receiving the bid information file, and then making a third encryption when the bid information file is opened. As such, the blockchain-based bidding system ensures that the information is not leaked or modified by a third party. In addition, each authentic document is stamped by performing a comparison to authorize the authenticity of the bid information file then applying a digital signature to show that this bid information file was tested and is valid to be used in the bidding. After generating the digital signature and validating the bidding process, C2 and C1 are decrypted to get the bid file, then the bid file is sent to the Blockchain to create a fourth block. A reason for saving the bid files in a fourth block instead of the database is to prevent any chance of price modification.
Regarding
In S508, the bidder 105 is presented with a user interface for displaying a new bid form.
In S510, the system receives a new bid information and checks that the bid information is complete. The system continues to accept the bid information until the bid information is completed (YES in S510).
Each new project and bid is provided with a private and a public key. The overall system provides three layers of protection. The first layer is provided on the client-side (bidder client computer 105) by encrypting the bid file and hashing value calculated for the bid file. Then, the hashed bid file is saved in the blockchain (maintained in the blockchain computer system). The second layer is provided on the system side (blockchain computer system), where the encrypted bid file “C1” is received. The encrypted bid file is encrypted again using the project public key. The second encryption “C2” is saved into the system database. Moreover, the second encryption is hashed and added to the blockchain as a new block. The last layer is applied when the deadline for bidding expires. Bidders (Bidder client computer 105) can decrypt their bid files using their private keys.
The blockchain computer system will verify the resulting file hash with the hash saved into the first block, which is added in the first layer. The resulting third block is added to save the date of opening the bid file.
These three layers increase the trust and confidence between the bidders (vendors) and contract managers/auctioneers that each step was recorded in a blockchain and then verified that there is no manipulation to the process has happened.
And if the hash verification process is successful, the bid information file will be given a digital signature to show that this document was tested and is valid to be used in the bidding.
Regarding
In S524, the system invokes an encryption function. In one embodiment, the encryption function is an Open SSL function.
In S526, the encryption function generates a private key. In one embodiment, the private key is a random string. The encryption function may be any string-based asymmetric encryption such as RSA, and elliptic curve encryption.
In S532, the system invokes the encryption function to generate a public key. In the case of the RSA algorithm, the public key is a product of two large distinct prime numbers. In S528, the private key, the public key, and project information are stored in a system database.
Regarding
In S514, the system invokes an encryption function.
In step S518, public and in step S516 private keys can be generated for each bid that has been submitted. The public key will be used for a first encryption only so no need to save it. The private key can be downloaded on a bidder's device 105. All bidders need to keep their bid private key (S542) to use it at the moment of opening the bids. Moreover, the disclosed blockchain system provides two layers of encryption to achieve data privacy. The first encryption C1 (S544) happens using the bid public key when the bidder submits the bid. Then the submitted bid will be combined with the submitting time and hashed using SHA-512 (S544) and stored into the system database. The first hash H1 is also sent to the blockchain with the submitting time to retrieve them later when verifying each bid.
In
When the bidding reaches opening time, each submitted bid will be decrypted using the project private key to get C1 and push notifications to the bidders to open their bids using the bid private key.
Referring to
Each bidder needs to login to his/her account and upload the private key. After decrypting the C1 a bidder should get the actual bid that has been submitted. Then the combined bid and the opening time are hashed and sent as the third block to the blockchain using the “addBid” function.
To verify each bid, the hashing value of the decryption result is matched with hashing that has been stored on the blockchain. The “getBid” smart contract function is used to retrieve blocks from the blockchain.
In
Referring back to
When the bid information file is not verified (No in S554), the bid information file is discarded.
Upon clicking the hash notification click button, the bid information file is decrypted and opened. In S558, the blockchain computer system checks that a hash of the opened bid information file matches the hash H1. If the hash is a match, the bid information file is retrieved successfully, in S560, a hash H3 of the opened bid information file is generated. In the case that the hash of the opened bid information file does not match (No S558), in S564, the bid information file will be discarded.
If the verification goes correctly, then a new hash value will be generated to prove this bid opened correctly without any modifications and send hashing value to the blockchain with the opening time. In particular, referring back to
In S582, a hash is determined using the decrypted second encryption C2 and compared to hash H2. If they match, in S584, the bid information file was received within the time limit. Otherwise (mismatch in S582), the bid information file is determined to not have been added to the block in the time limit in S586.
In S592, a hash of the bid information file is compared to hash H3. If they match, in S594, the bid information file has been securely closed. Otherwise (mismatch in S592), the bid information file is determined to have been previously opened in S596.
The last block will include the actual value of the bid to retrieve it when choosing the winner. This block is added using the “addPrice” smart contract function.
Finally, a digital signature is generated to confirm that the bid went through the three stages correctly and the digital signature is stored in the system database. In S598, after the bid information file was sent within the time limit (S576), the bid information file was received within the time limit (S584), and the bid information file was securely closed (S594), in S598, the Hash H1, Hash H2, Hash H3 is encrypted and signed. The signature is saved in the system database S528.
Bid information files are handled in the above-described manner for each bidder, up until the set date/time in the project. The contract manager will select a bid for a bidder from among the successful bids. In an embodiment, after one day of opening the bids, the blockchain system will retrieve all bids from blockchain using “getPrice” smart contract function and compare them based on the lowest cost, choose the winner, and announce that on the platform.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.
