CN112364382B - Credible time domain determination method of business record based on credible account book database - Google Patents
Credible time domain determination method of business record based on credible account book database Download PDFInfo
- Publication number
- CN112364382B CN112364382B CN202110033553.7A CN202110033553A CN112364382B CN 112364382 B CN112364382 B CN 112364382B CN 202110033553 A CN202110033553 A CN 202110033553A CN 112364382 B CN112364382 B CN 112364382B
- Authority
- CN
- China
- Prior art keywords
- time
- account book
- record
- credible
- trusted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 238000012795 verification Methods 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 4
- 238000010200 validation analysis Methods 0.000 claims description 4
- 238000012163 sequencing technique Methods 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 13
- 238000004891 communication Methods 0.000 description 11
- 238000013500 data storage Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000005034 decoration Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A method for determining the credible time domain of the business record based on the credible account book database is disclosed. The method comprises the steps that Time service is requested to an authoritative Time-giving party (TSA) server side at intervals on the basis of all service records in a trusted account book database, and a timestamp acquired each Time is used as an anchor point mark for determining a service record stored in the trusted account book database before the Time point and an anchor point between a service record stored in the trusted account book database after the Time point. In this way, for any business record in the trusted account book database, the trusted time domain of the business record can be defined based on the timestamps corresponding to the two anchor points adjacent to the business record respectively.
Description
Technical Field
The embodiment of the specification relates to the technical field of information, in particular to a method for determining a trusted time domain of a business record based on a trusted account book database.
Background
The credible account book database is a novel storage scheme obtained by improvement on the basis of a block chain storage scheme, can overcome the problems of low throughput, long response time and the like of decentralized block chain storage, and can meet the credible storage requirement of a user on data.
The credible account book database is maintained locally by a centralized database server, the service object of the credible account book database is usually an enterprise-level user, the user registers an account at the database server, the business data generated by the business of the user is encapsulated into business records through the registered account, the business records are submitted to the database server, and the database server sequentially writes each business record into the local credible account book database for storage according to the sequence of receiving each business record.
On the basis of the prior art, the credibility of the credible ledger database for a third party needs to be considered.
Disclosure of Invention
The technical scheme of the application aims to solve the technical problem that the existing credible account book database is low in credibility for a third party.
In order to solve the technical problem, the technical scheme of the application is realized as follows:
according to the 1 st aspect of the embodiments of the present specification, there is provided a method for determining a trusted time domain of a business record of a trusted ledger database, which is applied to a database server side that maintains the trusted ledger database, the method including:
at each time point specified by a preset time plan, submitting a time service request to an authoritative time service party TSA server; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: at the time point, the root hash of the global Merck tree constructed based on all the business records in the credible account book database;
acquiring a timestamp returned by the TSA server by taking root hash contained in the timing request as a timing object, and taking the timestamp as an anchor point mark for determining a latest business record stored in the trusted account book database before the time point and an anchor point between the latest business record stored in the trusted account book database after the time point;
and determining time stamps corresponding to two anchor points adjacent to the front and back of the business record respectively aiming at any business record in the credible account book database, and dividing a credible time domain of the business record based on the time stamps corresponding to the two determined anchor point marks respectively.
According to the 2 nd aspect of the embodiments of the present specification, there is provided another method for determining a trusted time domain of a business record of a trusted ledger database, which is applied to a database server side that maintains the trusted ledger database, the method including:
at each time point specified by a preset time plan, submitting a time service request to an authoritative time service party TSA server; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: the record hash of the service record stored in the credible account book database is latest before the time point;
acquiring a timestamp returned by the TSA server by taking root hash contained in the timing request as a timing object, and taking the timestamp as an anchor point mark for determining a latest business record stored in the trusted account book database before the time point and an anchor point between the latest business record stored in the trusted account book database after the time point;
and determining time stamps corresponding to two anchor points adjacent to the front and back of the business record respectively aiming at any business record in the credible account book database, and dividing a credible time domain of the business record based on the time stamps corresponding to the two determined anchor point marks respectively.
According to the 3 rd aspect of the embodiments of the present specification, there is provided a method for verifying authenticity of a business record based on the trusted time domain in the method of the 1 st aspect, including:
aiming at a service record to be verified, acquiring a trusted time domain of the service record;
adopting a TSA public key to respectively carry out validity verification on two timestamps used for demarcating a credible time domain of the business record;
and if the validity verification of the two timestamps passes, performing authenticity verification on the service record based on the trusted time domain.
Through the scheme provided in the embodiment of the present specification, a Time service is requested from a Time Stamp Authority (TSA) server at intervals based on all service records in a trusted account book database, and for a timestamp obtained each Time, the timestamp is used as an anchor point mark for determining a last service record stored in the trusted account book database before the Time point and an anchor point between the last service record stored in the trusted account book database after the Time point. In this way, for any business record in the trusted account book database, the trusted time domain of the business record can be defined based on the timestamps corresponding to the two anchor points adjacent to the business record respectively.
Through the embodiment of the description, the trusted time domain of any service record can be used for verifying whether the position of the service record in the writing sequence queue is real or not, so that an endorsement is provided for the authenticity of the service record, and the credibility of the service record to a third party is improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of embodiments of the invention.
In addition, any one of the embodiments in the present specification is not required to achieve all of the effects described above.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a schematic diagram of a trusted ledger database-based data storage system provided herein;
fig. 2 is a flowchart illustrating a method for determining a trusted time domain of a business record of a trusted ledger database provided in the present specification;
fig. 3 is a schematic diagram of an anchor point between service records according to an embodiment of the present specification;
FIG. 4 is a flow diagram of a business record authenticity verification method;
fig. 5 is a schematic structural diagram of a trusted time domain determination apparatus for business records of a trusted ledger database provided in the present specification;
fig. 6 is a schematic structural diagram of another trusted time domain determination apparatus for business records of a trusted ledger database provided in the present specification;
fig. 7 is a schematic structural diagram of a service record authenticity verification apparatus provided in an embodiment of the present specification;
fig. 8 is a schematic structural diagram of an apparatus for configuring a method according to an embodiment of the present disclosure.
Detailed Description
Fig. 1 is a schematic diagram of a data storage system based on a trusted ledger database provided in the present specification. As shown in fig. 1, the data storage system includes a centralized database server and a plurality of clients. The database server is responsible for maintaining a trusted account book database, each client corresponds to an enterprise-level user (organization), and each enterprise-level user further interfaces with one or more individual users.
For example, the takeout platform and the e-commerce platform are respectively used as users to register on the database server to obtain user accounts, and install clients provided by the database server on own equipment to log in the user accounts in the clients, so that the takeout platform and the e-commerce platform have the capability of performing data interaction with the database server.
And the take-out platform and the e-commerce platform are respectively connected with a large number of individual users. After a certain individual user purchases a takeout food by using a takeout client installed on a mobile phone of the individual user, equipment of the takeout platform generates a takeout order record (namely business data generated by the takeout platform based on business), the takeout platform encapsulates the order record into a record through a user account registered at a database server by the individual user (similar to transactions in the field of block chains, the record is a special data structure suitable for storage of a credible account book database), and submits the record to the database server so that the database server encapsulates the record into the record and writes the record into the credible account book database for storage. Similarly, the e-commerce platform encapsulates each e-commerce order generated based on the e-commerce business into a record and submits the record to the database server.
For convenience of description, the user described hereinafter refers to an enterprise-level user served by the database server, and the user account described hereinafter refers to an account registered by the enterprise-level user at the database server.
Generally, the sequence of business records submitted to a database server by a user reflects the sequence of business data generated by recording the encapsulated business data, and the database server can store all the business records into a credible account book database in sequence according to the sequence of the business records submitted by the same user.
For the way of storing business records in the trusted account book database, the method can be similar to a block chain, that is, according to a certain blocking condition, the received business records are packed into data blocks according to batches, and the arrangement sequence of the business records in the same data block is consistent with the sequence of the business records received by the database server. Each data block calculates the root hash of the merck tree based on all the service records encapsulated in the block, the root hash is written into the block head of the data block, and the block head of the next data block contains the hash value of the previous data block (namely, the hash value obtained by performing hash calculation on the block head). In this case, the trusted account book database actually belongs to a block chain type account book, and it can be ensured that it is difficult to tamper with part of business records in the trusted account book database.
In addition, the credible account book database can also store all business records according to the receiving sequence, all business records in the credible account book database form a global merkel tree, and the root hash of the global merkel tree can ensure that partial business records in the credible account book database are difficult to be tampered.
Due to the storage mode, the existing credible account book database is credible for users, the users usually store the root hash of the Mercker tree returned by the database server, and whether the business records in the credible account book database are tampered or not can be verified by using the root hash.
However, the current trusted account book database is not necessarily trusted for the user and a third party other than the database server, because there may be a case that the user and the database server are in series communication to tamper with the trusted account book database. The third party may be, for example, an auditor, the public, etc.
For example, assuming that a user is a certain enterprise to be listed, at the beginning of enterprise creation, the enterprise opens an account at a database server, and the enterprise forms financial records of financial data generated in the current month according to the month and submits the financial records to the database server to store the trusted account book data. Enterprises worry that financial data generated before have some problems of non-compliance, so that the enterprises communicate with the database server end, all financial records stored before the auditing time point in the trusted account book database are deleted and replaced by temporarily forged financial records, and in this case, the financial records acquired by an auditor from the trusted account book database are not trusted.
In order to solve the above technical problem, in one or more embodiments of the present specification, a Time service is requested from an authoritative Time Authority (TSA) server at intervals based on all business records in a trusted account book database, and for each obtained timestamp, the timestamp is used as an anchor mark for marking a position between a latest business record stored in the trusted account book database before a Time point and a latest business record stored in the trusted account book database after the Time point in a write sequence queue corresponding to the trusted account book database. In this way, for any business record in the trusted ledger database, two timestamps that are adjacent to each other before and after the business record is written into the sequence queue can define the trusted time domain of the business record.
With one or more embodiments of the present description, the trusted time domain of any transaction record can be used to verify whether the location of the transaction record in the write sequence queue is authentic.
In order to make those skilled in the art better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of protection.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
Fig. 2 is a schematic flowchart of a method for determining a trusted time domain of a business record in a trusted ledger database, which includes the following steps:
s200: and at each time point specified by the preset time plan, submitting a time service request to an authoritative time service party TSA server.
The execution subject of the method shown in fig. 2 is a database server. A time interval exists between any two time points specified by the preset time plan, in other words, the database server side submits the time service request to the TSA server side at intervals.
In some embodiments of the present description, the preset time schedule specifies that there is a same time interval between any two time points. In other words, the preset time plan belongs to a periodic time plan, and the database server periodically executes the submission of the time service request to the authoritative time service provider TSA server.
In addition, the preset time plan may also be an aperiodic time plan, and the time intervals between two time points may not be consistent.
For each time point of the preset time plan, the time object included in the time request may be a root hash of a global Merck tree constructed based on all business records in the trusted account book database at the time point. In addition, the time service object included in the time service request may be a record hash of a business record stored in the trusted account book database immediately before the time point.
In some embodiments of the present specification, based on the storage sequence of each business record in the trusted account book database, the records hash of each business record may be sorted to obtain a sorting queue; and constructing a global Merck tree by taking the sequencing queue as a leaf node queue of the Merck tree.
In some embodiments of the present specification, the trusted account book database has a plurality of data blocks, each data block encapsulates a plurality of service records, the plurality of data blocks have a sequence, and the local validation time of a service record in a previous data block is earlier than the local validation time of a service record in a subsequent data block, in this case, for each data block in the trusted account book database, based on all service records encapsulated by the data block, a root hash of a mercker tree corresponding to the data block may be calculated; and determining the root hash of the global Merck tree based on the root hash of the Merck tree corresponding to each data block.
S202: and acquiring a timestamp returned by the TSA server aiming at the time service object, and marking the timestamp as an anchor point.
The anchor mark is used for determining an anchor point between the latest business record stored in the credible account book database before the time point and the latest business record stored in the credible account book database after the time point.
S204: and aiming at any business record in the credible account book database, determining two timestamps which are adjacent to each other in front and back of the business record in the writing sequence queue.
Fig. 3 is a schematic diagram of an anchor point between service records according to an embodiment of the present specification. As shown in fig. 3, the precedence order of the anchor points actually characterizes an absolutely trusted temporal order, due to the existence of the anchor points, which are individually determined based on the authoritative timestamps. For any service record, the latest anchor point (the anchor point adjacent to the front) before the service record represents that the latest authentication time of the service record is not earlier than the time granted by the time stamp corresponding to the anchor point, and the latest anchor point (the anchor point adjacent to the rear) after the service record represents that the latest authentication time of the service record is not later than the time granted by the time stamp corresponding to the anchor point.
S206: and defining a credible time domain of the business record based on the time stamps respectively corresponding to the two determined anchor point marks.
Two timestamps adjacent to each other before and after the service record can be used for defining a trusted time domain (the time of the two timestamps is respectively used as the left and right boundary points of the trusted time domain), and the trusted time range to which the latest certification time of the service record belongs can be represented.
Through the method flow shown in fig. 2, a time service is requested from an authoritative time-giver TSA server based on all business records in the trusted account book database at intervals, and for each acquired timestamp, the timestamp is used as an anchor point mark for determining an anchor point between a business record stored in the trusted account book database before the time point and a business record stored in the trusted account book database after the time point. In this way, for any business record in the trusted account book database, the trusted time domain of the business record can be defined based on the timestamps corresponding to the two anchor points adjacent to the business record respectively.
Through the embodiment of the description, the trusted time domain of any service record can be used for verifying whether the position of the service record in the writing sequence queue is real or not, so that an endorsement is provided for the authenticity of the service record, and the credibility of the service record to a third party is improved.
On the basis of time service of each business record stored in the trusted account book database by adopting the method flow shown in fig. 2, the description also provides a method for verifying the authenticity of the business record. Fig. 4 is a schematic flow chart of a method for verifying authenticity of a service record, which includes the following steps:
s400: and acquiring a credible time domain of the business record aiming at the business record to be verified.
In the case that a third party needs to verify one or more business records in the trusted ledger database, the method flow shown in fig. 4 may be adopted for verification.
S402: and respectively carrying out validity verification on two timestamps for delimiting the credible time domain of the business record by adopting the TSA public key.
S404: and if the validity verification of the two timestamps passes, performing authenticity verification on the service record based on the trusted time domain.
The validity of the two timestamps passes the verification, which shows that the trusted time domain is legal and trusted. The authenticity of the business record is verified based on the trusted time domain, actually, the certificate storing time of the business record declared to a third party by a user or a database server is compared with the trusted time domain, if the certificate storing time of the statement falls into the trusted time domain, the certificate storing time of the business record is very trusted, and the business record can be determined to be real.
If the stated credentialing time does not fall into the trusted time domain, the stated credentialing time of the business record is not trusted, and the business record can be considered to be not verified through authenticity.
In addition, if the validity verification of any timestamp fails, the trusted time domain of the service record is actually not legal and thus actually not trusted, so that the service record can be determined to fail the validity verification.
Fig. 5 is a schematic structural diagram of an apparatus for determining a trusted time domain of a business record of a trusted ledger database provided in this specification, which is applied to a database server side that maintains the trusted ledger database, and the apparatus includes:
the time service request module 501 submits a time service request to an authoritative time service party TSA server at each time point specified by a preset time plan; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: at the time point, the root hash of the global Merck tree constructed based on all the business records in the credible account book database;
an obtaining module 502, configured to obtain a timestamp returned by the TSA server by using a root hash included in the timing request as a timing object, and use the timestamp as an anchor point mark to determine a latest anchor point between a business record stored in the trusted account book database before the time point and a latest anchor point stored in the trusted account book database after the time point;
the defining module 503 determines, for any service record in the trusted account book database, timestamps corresponding to two anchor points adjacent to the service record respectively, and defines a trusted time domain of the service record based on the timestamps corresponding to the two determined anchor point marks respectively.
Fig. 6 is a schematic structural diagram of another trusted time domain determination apparatus for business records of a trusted ledger database provided in this specification, which is applied to a database server side for maintaining the trusted ledger database, and the apparatus includes:
the time service request module 601 is used for submitting a time service request to an authoritative time service party TSA server at each time point specified by a preset time plan; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: the record hash of the service record stored in the credible account book database is latest before the time point;
an obtaining module 602, configured to obtain a timestamp returned by the TSA server by using a root hash included in the timing request as a timing object, and use the timestamp as an anchor point mark to determine a latest one of the service records stored in the trusted account book database before the time point and an anchor point between the latest one of the service records stored in the trusted account book database after the time point;
the defining module 603 determines, for any service record in the trusted account book database, timestamps corresponding to two anchor points adjacent to the service record respectively, and defines a trusted time domain of the service record based on the timestamps corresponding to the two determined anchor point marks respectively.
Fig. 7 is a schematic structural diagram of a service record authenticity verification apparatus provided in an embodiment of the present specification, including:
an obtaining module 701, configured to obtain, for a service record to be verified, a trusted time domain of the service record;
a first verification module 702, which respectively performs validity verification on two timestamps used for demarcating a trusted time domain of the business record by using a TSA public key;
the second verification module 703 determines that the service record passes the authenticity verification if the validity verifications of the two timestamps pass. The present specification also provides a computer device comprising at least a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method shown in fig. 2 or fig. 4 when executing the program.
Fig. 8 is a schematic diagram illustrating a more specific hardware structure of a computing device according to an embodiment of the present disclosure, where the computing device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
Embodiments of the present description also provide a computer-readable storage medium on which a computer program is stored, which when executed by a processor implements the method shown in fig. 2 or 4.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The systems, methods, modules or units described in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to the partial description of the method embodiment for relevant points. The above-described method embodiments are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present specification. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.
Claims (10)
1. A method for determining a credible time domain of a business record of a credible account book database is applied to a database server side for maintaining the credible account book database, and comprises the following steps:
at each time point specified by a preset time plan, submitting a time service request to an authoritative time service party TSA server; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: at the time point, the root hash of the global Merck tree constructed based on all the business records in the credible account book database;
acquiring a timestamp returned by the TSA server by taking root hash contained in the timing request as a timing object, and taking the timestamp as an anchor point mark for determining a latest business record stored in the trusted account book database before the time point and an anchor point between the latest business record stored in the trusted account book database after the time point;
and determining time stamps corresponding to two anchor points adjacent to the front and back of the business record respectively aiming at any business record in the credible account book database, and dividing a credible time domain of the business record based on the time stamps corresponding to the two determined anchor point marks respectively.
2. The method of claim 1, wherein the predetermined time schedule specifies that there is a same time interval between any two time points.
3. The method of claim 1, constructing a global merkel tree based on all business records in the trusted ledger database, comprising:
based on the storage sequence of each business record in the credible account book database, sorting the records Hash of each business record to obtain a sorting queue;
and constructing a global Merck tree by taking the sequencing queue as a leaf node queue of the Merck tree.
4. The method of claim 1, the trusted ledger database having a plurality of data blocks, each data block encapsulating a plurality of business records, the plurality of data blocks having a chronological order therebetween, the local validation time of a business record in a preceding data block being earlier than the local validation time of a business record in a succeeding data block;
constructing a global Merck tree based on all business records in the credible account book database, wherein the method comprises the following steps:
aiming at each data block in the credible account book database, calculating the root hash of the Mercker tree corresponding to the data block based on all business records packaged by the data block;
and determining the root hash of the global Merck tree based on the root hash of the Merck tree corresponding to each data block.
5. A method for verifying authenticity of a transaction record based on a trusted time domain as claimed in any one of claims 1 to 4, comprising:
aiming at a service record to be verified, acquiring a trusted time domain of the service record;
adopting a TSA public key to respectively carry out validity verification on two timestamps used for demarcating a credible time domain of the business record;
and if the validity verification of the two timestamps passes, performing authenticity verification on the service record based on the trusted time domain.
6. The method of claim 5, further comprising:
and if the validity verification of any time stamp is not passed, determining that the business record is not passed the validity verification.
7. A credible time domain determination device for business records of a credible account book database is applied to a database server side for maintaining the credible account book database, and the device comprises:
the time service request module submits a time service request to an authoritative time service party TSA server at each time point specified by a preset time plan; a time interval exists between any two time points specified by the preset time plan; the time service request comprises: at the time point, the root hash of the global Merck tree constructed based on all the business records in the credible account book database;
the acquisition module is used for acquiring a timestamp returned by the TSA server by taking root hash contained in the timing request as a timing object, and taking the timestamp as an anchor point mark for determining a latest business record stored in the trusted account book database before the time point and an anchor point between the latest business record stored in the trusted account book database after the time point;
and the defining module is used for determining timestamps corresponding to two adjacent anchor points before and after the business record aiming at any business record in the credible account book database, and defining a credible time domain of the business record based on the timestamps corresponding to the two determined anchor point marks.
8. A service record authenticity verification device based on the trusted time domain as claimed in any of the methods of claims 1-4, comprising:
the acquisition module is used for acquiring a credible time domain of a business record to be verified;
the first verification module is used for respectively verifying the legality of two timestamps used for demarcating a credible time domain of the business record by adopting a TSA public key;
and the second verification module is used for verifying the authenticity of the service record based on the trusted time domain if the validity verification of the two timestamps passes.
9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1-4 when executing the program.
10. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of claim 5 or 6 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033553.7A CN112364382B (en) | 2021-01-12 | 2021-01-12 | Credible time domain determination method of business record based on credible account book database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110033553.7A CN112364382B (en) | 2021-01-12 | 2021-01-12 | Credible time domain determination method of business record based on credible account book database |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112364382A CN112364382A (en) | 2021-02-12 |
| CN112364382B true CN112364382B (en) | 2021-04-27 |
Family
ID=74534811
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110033553.7A Active CN112364382B (en) | 2021-01-12 | 2021-01-12 | Credible time domain determination method of business record based on credible account book database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112364382B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117914868A (en) * | 2022-10-11 | 2024-04-19 | 抖音视界有限公司 | Data processing method, device, equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9667427B2 (en) * | 2015-10-14 | 2017-05-30 | Cambridge Blockchain, LLC | Systems and methods for managing digital identities |
| CN109951290A (en) * | 2019-01-31 | 2019-06-28 | 阿里巴巴集团控股有限公司 | A kind of time service authentication method, device and the equipment of chain type account book |
| CN111183446A (en) * | 2019-09-02 | 2020-05-19 | 阿里巴巴集团控股有限公司 | Centralized account book system based on block chain management |
| CN111400270A (en) * | 2020-03-16 | 2020-07-10 | 上海简苏网络科技有限公司 | Block chain-based file time service method and device |
-
2021
- 2021-01-12 CN CN202110033553.7A patent/CN112364382B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9667427B2 (en) * | 2015-10-14 | 2017-05-30 | Cambridge Blockchain, LLC | Systems and methods for managing digital identities |
| CN109951290A (en) * | 2019-01-31 | 2019-06-28 | 阿里巴巴集团控股有限公司 | A kind of time service authentication method, device and the equipment of chain type account book |
| CN111183446A (en) * | 2019-09-02 | 2020-05-19 | 阿里巴巴集团控股有限公司 | Centralized account book system based on block chain management |
| CN111400270A (en) * | 2020-03-16 | 2020-07-10 | 上海简苏网络科技有限公司 | Block chain-based file time service method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112364382A (en) | 2021-02-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110188096B (en) | Index creating method, device and equipment for data record | |
| CN110162662B (en) | Verification method, device and equipment for data records in block chain type account book | |
| CN110163006B (en) | Signature verification method, system, device and equipment in block chain type account book | |
| CN110009338B (en) | Accounting method and device based on block chain and electronic equipment | |
| KR20200108513A (en) | Data verification methods and systems using a hash tree, such as a time-oriented Merkle hash tree | |
| CN110162526B (en) | Method, device and equipment for inquiring data records in block chain type account book | |
| CN110474775B (en) | User creating method, device and equipment in block chain type account book | |
| CN110190963B (en) | Monitoring method, device and equipment for time service certificate generation request | |
| CN110266494B (en) | Time service authentication method, device and equipment in block chain type account book | |
| CN111506580B (en) | Transaction storage method based on centralized block chain type account book | |
| CN110019278B (en) | Data verification method, device and equipment | |
| CN112966311A (en) | Intelligent contract checking method and device and electronic equipment | |
| CN110347745B (en) | Time service authentication method, device and equipment for block chain type account book | |
| CN111459948A (en) | Data block deleting method based on centralized block chain type account book | |
| CN112364382B (en) | Credible time domain determination method of business record based on credible account book database | |
| US20200193430A1 (en) | Determining generation time for blockchain data | |
| CN114039733B (en) | Certificate storage service transfer method, device and equipment for alliance chains | |
| CN111464319B (en) | Transaction storage and signature verification method based on centralized block chain type account book | |
| CN111475778A (en) | Music data processing method and device based on block chain | |
| CN110750533A (en) | Data storage method, device and equipment based on multiple service attributes | |
| CN110727679A (en) | Cooperative tracking method, system, device and equipment for court case | |
| CN112291321B (en) | Service processing method, device and system | |
| CN112364389B (en) | Business record time service method based on credible account book database | |
| CN108710658B (en) | Data record storage method and device | |
| CN112364384B (en) | Business record time service method based on credible account book database |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40045955 Country of ref document: HK |