WO2020258858A1 - 块链式账本中的授权方法、系统、装置及设备 - Google Patents

块链式账本中的授权方法、系统、装置及设备 Download PDF

Info

Publication number
WO2020258858A1
WO2020258858A1 PCT/CN2020/072062 CN2020072062W WO2020258858A1 WO 2020258858 A1 WO2020258858 A1 WO 2020258858A1 CN 2020072062 W CN2020072062 W CN 2020072062W WO 2020258858 A1 WO2020258858 A1 WO 2020258858A1
Authority
WO
WIPO (PCT)
Prior art keywords
ledger
authorization
user
identifier
database server
Prior art date
Application number
PCT/CN2020/072062
Other languages
English (en)
French (fr)
Inventor
闫文远
杨新颖
张渊
李亿泽
俞本权
Original Assignee
创新先进技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/805,649 priority Critical patent/US10789376B2/en
Priority to US16/945,772 priority patent/US10936734B2/en
Publication of WO2020258858A1 publication Critical patent/WO2020258858A1/zh

Links

Images

Classifications

    • 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
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular, to an authorization method, system, device, and equipment in a blockchain ledger.
  • the database server uses a blockchain-style ledger to provide ledger services to users
  • users often add or remove other related business ends in the ledger (the business end includes other business or natural person business ends), so that the business end can also be in the ledger
  • the purpose of the embodiments of this application is to provide a convenient authorization scheme in a blockchain ledger.
  • An authorization method in a blockchain ledger, applied to a system including a client, a database server, and a business, includes:
  • the client terminal receives the user's operation instruction, determines the business terminal to be authorized, generates an authorization request including the business terminal identification and the user identification, and sends the authorization request to the database server;
  • the database server determines the corresponding database authorization instruction and the ledger identifier according to the authorization request, executes the database authorization instruction, and determines the service terminal to be authorized as the user in the ledger corresponding to the ledger identifier, and, Determining the operation authority of the business end in the ledger;
  • the database server sends authorization information including the user ID and the ledger ID to the service side;
  • Any service end that receives the authorization information writes the corresponding relationship between the user ID and the account book ID into the operational account book list in the service end, and stores it.
  • the embodiment of this specification also provides an authorization system in a blockchain ledger, including a client, a database server, and a business end.
  • a blockchain ledger including a client, a database server, and a business end.
  • the client terminal receives the user's operation instruction, determines the business terminal to be authorized, generates an authorization request including the business terminal identifier and the user identifier, and sends the authorization request to the database server terminal;
  • the database server determines the corresponding database authorization instruction and the ledger identifier according to the authorization request, executes the database authorization instruction, and determines the service terminal to be authorized as the user in the ledger corresponding to the ledger identifier, and, Determining the operation authority of the business end in the ledger;
  • the database server sends authorization information including the user ID and the ledger ID to the service side;
  • Any service end that receives the authorization information writes the corresponding relationship between the user ID and the account book ID into the operational account book list in the service end, and stores it.
  • the embodiment of this specification also provides an authorization method in a block chain ledger, which is applied to a database server, including:
  • Execute the database authorization instruction determine the business end corresponding to the business end identifier as a user in the ledger corresponding to the ledger identifier, and determine the operation authority of the business end in the ledger;
  • an embodiment of this specification also provides an authorization device in a block chain ledger, which is applied to a database server, including:
  • the receiving module receives an authorization request sent by the client, where the authorization request includes a service terminal identifier and a user identifier;
  • the determining module determines the corresponding database authorization instruction and ledger identifier according to the authorization request
  • the execution module executes the database authorization instruction, determines the business end corresponding to the business end identifier as the user in the ledger corresponding to the ledger identifier, and determines the operation of the business end in the ledger Permissions
  • the sending module sends the authorization information including the user ID and the account book ID to the service end.
  • the client initiates an authorization request to the database server based on the user's instruction
  • the database server converts the authorization request into the corresponding database command operation, and adds a new user and Determine user permissions, and update the list of user operable accounts on the business side, so that the business party can write the business records related to the user into the account book.
  • the user can also remove the authorization from the related authorized business party in the account book. It is convenient for users to manage the operable members in the ledger.
  • Fig. 1 is a schematic diagram of a process for generating a block chain ledger provided by an embodiment of the specification
  • FIG. 2 is a schematic diagram of a system architecture involved in an embodiment of the specification
  • Figure 3 is an authorization method in a blockchain ledger provided by an embodiment of this specification
  • FIG. 4 is a method for authorization in a block chain ledger applied to a database server provided in an embodiment of the specification
  • FIG. 5 is a schematic structural diagram of an authorization device in a block chain ledger provided by an embodiment of this specification
  • Fig. 6 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.
  • FIG. 1 is a schematic diagram of the process of generating a block chain ledger provided by the embodiment of this specification, including:
  • S101 Receive a data record to be stored, and determine a hash value of each data record.
  • the data records to be stored here may be various consumption records of individual users of the client, or may be business results, intermediate states, and operation records generated when the application server executes business logic based on user instructions.
  • Specific business scenarios can include consumption records, audit logs, supply chains, government supervision records, medical records, and so on.
  • the preset block conditions include: the number of data records to be stored reaches the number threshold, for example, every time one thousand data records are received, a new data block is generated and one thousand data records are written into the block; or , The time interval from the last block formation time reaches the time threshold, for example, every 5 minutes, a new data block is generated, and the data records received within these 5 minutes are written into the block.
  • the N here refers to the serial number of the data block.
  • the data block is in the form of a block chain, which is arranged sequentially based on the order of the block time, and has a strong timing characteristic.
  • the block height of the data block increases monotonically based on the sequence of the block time.
  • the block height can be a serial number, at this time the block height of the Nth data block is N; the block height can also be generated in other ways, for example, the block time symmetric encryption of the data block is converted into monotonically increasing large integer data as a block high.
  • the data block at this time is the initial data block.
  • the current data block (the first data block) can be generated based on the hash value of the previous data block (that is, the N-1th data block). For example, a feasible way is to determine the hash value of each data record to be written in the Nth block, and generate a Merck according to the sequence in the block. In the Er tree, the root hash value of the Merkel tree and the hash value of the previous data block are spliced together, and the hash algorithm is used again to generate the hash value of the current block.
  • the hash value of the corresponding data record and the hash value of the data block can be obtained and saved, and integrity verification can be initiated based on the hash value.
  • the specific verification method is to recalculate the hash value of the data record itself and the hash value of the data block in the database, and compare with the locally stored hash value.
  • each data block is determined by a hash value, and the hash value of the data block is determined by the content and order of the data records in the data block and the hash value of the previous data block.
  • the user can initiate verification based on the hash value of the data block at any time. Any modification of the data block (including the modification of the data record content or sequence in the data block) will cause the hash value of the data block calculated during verification and The hash value of the data block is inconsistent when it is generated, which causes the verification to fail, thus realizing the immutability under centralization.
  • a segment of data block is designated for continuous integrity verification, or continuous integrity verification starts from the initial data block.
  • the verification method is to obtain the hash value of the previous data block, and use the same algorithm as when generating the hash value of the data block, and recalculate its own data based on its own data record and the hash value of the previous data block.
  • the hash value of the block is compared with the hash value of the previous data block.
  • business parties often generate user-related items such as settlement lists and reconciliation lists, as well as some businesses that do not require the user's active operations, such as interest and dividend calculations.
  • users also need business parties to write such data records into their own ledger for storage.
  • FIG. 2 is a schematic diagram of a system architecture involved in an embodiment of this specification.
  • the user can have business transactions with multiple business ends through the client, and at the same time, both the client and the business end can write the generated related information into the database server.
  • the embodiment of this specification provides an authorization scheme in a block chain ledger, so that users can conveniently perform corresponding authorization management on users in their own ledger.
  • Figure 3 is an authorization method in a blockchain ledger provided by an embodiment of this specification, which is applied to a system including a client, a database server, and a business, including:
  • the client receives the user's operation instruction, determines the service end to be authorized, generates an authorization request including the service end identifier and the user identifier, and sends the authorization request to the database server end.
  • the user can confirm it when the ledger is created, or it can confirm after the ledger has been created.
  • An practicable way is that, in the client, by providing a form that includes a plurality of service end lists for the user to select, the user determines the corresponding service end to be authorized in the list.
  • Another practicable way is that after the user has created the ledger, when the user generates a transaction with the business end in the client, the authorization recommendation is initiated, and the user determines whether the business end of the transaction needs to be in the ledger through the authorization recommendation. Authorize in.
  • the client After determining the service end to be authorized, the client can obtain the corresponding user ID and generate a corresponding authorization request.
  • the authorization request includes the user ID and the service end ID, and sends the authorization request to the database server.
  • the client can also provide multiple ledgers for user selection, determine the corresponding account identifier based on the user's selection instruction, and then authorize the request It can also contain the ledger identifier confirmed by the user.
  • the database server determines the corresponding database authorization instruction and the ledger identifier according to the authorization request, executes the database authorization instruction, and determines the service terminal to be authorized as the user in the ledger corresponding to the ledger identifier, And, determine the operation authority of the business end in the ledger.
  • the database server can obtain the ledger identifier in the authorization instruction when the ledger identifier LID exists in the authorization instruction; or, it may determine the ledger identifier corresponding to the user identifier according to the user identifier in the authorization instruction.
  • the database server can convert the authorization request into corresponding database authorization instructions, including corresponding authorization instructions such as CreatRole/CreatMember and Grant.
  • the authorization instruction contains the business end identifier and the corresponding ledger identifier.
  • an exemplary database authorization instruction can be in the form CreatRole(&name,LID), where "name” is the business end identifier, and "LID” is the ledger identifier. In this way, add it to the ledger "LID” User "name”.
  • the business end can also be configured with a corresponding authority value in the ledger, for example, Grant (&name, weight), so that the business end can be configured with a corresponding operation authority "weight” in the ledger.
  • the specific permission value can be read from the permission profile preset by the user. For example, “read-only” permissions are generally given to newly added users.
  • the database After performing an operation on the database through the above authorization instruction, the database can return corresponding execution result information, indicating that the operation is successful.
  • S305 The database server sends authorization information including the user ID and the ledger ID to the service side.
  • the database server can package the foregoing execution result information, user identification, and ledger identification to generate authorization information, and send the authorization information to the business end in the authorization request.
  • the authorization information may also include operation authority.
  • Any service end that receives the authorization information writes the corresponding relationship between the user ID and the account book ID into the operational account book list in the service end, and stores it.
  • a list of operable ledgers is stored locally at any business end, which is used to store the correspondence between the LID and user ID of the ledgers that can be operated by the business end, and indicates which ledger the business end should write to the relevant information of a user.
  • the operation authority granted by the user may also be included.
  • the specific extent to which the business end can operate on the ledgers is limited by the operation authority granted by the user. Generally yes, it can be "write” permission.
  • Table 1 is an exemplary operational ledger list provided by the embodiment of this specification. That is, on the business side, the related reports generated by the user "ID1" can be written in the 2112 account book on the database server side.
  • the client initiates an authorization request to the database server based on the user's instruction
  • the database server converts the authorization request into the corresponding database command operation, and adds a new user and Determine the user authority, and update the user's operable account book list on the business side, so that the business party can write the user-related business records into the account book.
  • the business side in order to ensure the authenticity of the data records in the ledger, when the business side writes the data, it needs to digitally sign the written data (that is, use the private key of the business side to encrypt), at this time the database
  • the server can obtain the public key information of the corresponding business end (the public key information is a string of characters that can symmetrically decrypt the data encrypted by the private key), and write the public key information into the authority profile of the user account book. So that the data written into the ledger by the business end later, the user can obtain the corresponding public key in the ledger for decryption.
  • Table 2 is an exemplary form of a permission configuration table provided in the embodiment of this specification.
  • the key1 and key2 in the table represent the public key information of users ROLE01 and ROLE02, respectively.
  • Table 2 User and weight value system table
  • the database server can obtain a business-side public key information from the business-side at any time, or establish a corresponding business-side public key information table on the database server to obtain a business-side public key from the table at any time information.
  • the database server may also generate a data record containing the database authorization instruction while executing the database authorization instruction, and write the data record into the ledger corresponding to the ledger identifier.
  • the authorization instructions can be stored in the ledger in the form of data records. Since the data records in the ledger cannot be tampered with, this authorization behavior is also permanently stored and can be used as evidence.
  • the database server can also return the hash value of the data record to the client and the business side at the same time, so that the client and the business can query and query the data record based on the hash value. verification.
  • the database server when the database server generates a data record containing a database authorization instruction, it can also include the public key information of the business end in the data record, so that the public key information of the business end is also stored in the form of non-tamperable data. Certificate and ledger.
  • the database server can also digitally sign the data record containing the authorization instruction and/or public key information. , To ensure that the database server does not deceive the client or business side.
  • the business end can also send corresponding prompt information to the client when it needs to write the corresponding information into the ledger, but it does not have permission. For example, at the end of the month, when the XX Fund needs to clear the first interest payment for individuals through the business system, it is found that certain users’ accounts have not yet written permissions. At this time, the fund business side can send the business to this type of user.
  • the client After receiving the authorization prompt information, the client confirms the authorization prompt information of the terminal identifier, and then an authorization request containing the service terminal identifier can be generated.
  • the client can also remove or de-authorize the authorized service end, the specific method is:
  • the client receives the user's operation instruction, determines the service end to be deauthorized, generates a deauthorization request including the service end identifier and the user identifier, and sends the deauthorization request to the database server;
  • the database server determines the corresponding database deauthorization instruction and the ledger identifier according to the deauthorization request, executes the database deauthorization instruction, and cancels the operating authority of the business end on the ledger.
  • the deauthorization instruction here can be realized through the Grant instruction, for example, Grant (&name, 0), that is, the authority of a user in the ledger is set to the lowest, so as to realize that the business end has no access to the ledger. Any operation authority.
  • the database server sends the deauthorization information including the user ID and the ledger ID to the service side;
  • Any service end that receives the de-authorization information deletes the correspondence between the user ID and the account book ID in the list of operable account books of the service end.
  • the embodiment of this specification also provides an authorization system in a blockchain ledger, including a client, a database server, and a business end.
  • a blockchain ledger including a client, a database server, and a business end.
  • the client terminal receives the user's operation instruction, determines the business terminal to be authorized, generates an authorization request including the business terminal identification and the user identification, and sends the authorization request to the database server;
  • the database server determines the corresponding database authorization instruction and the ledger identifier according to the authorization request, executes the database authorization instruction, and determines the service terminal to be authorized as the user in the ledger corresponding to the ledger identifier, and, Determining the operation authority of the business end in the ledger;
  • the database server sends authorization information including the user ID and the ledger ID to the service side;
  • Any service end that receives the authorization information writes the corresponding relationship between the user ID and the account book ID into the operable account book list in the service end, and stores it.
  • the database server obtains the public key information of the business end, and writes the public key information of the business end into the authority configuration file of the ledger.
  • the database server generates a data record containing the database authorization instruction, and writes the data record into the ledger corresponding to the ledger identifier.
  • the database server obtains the public key information of the business end, generates a data record containing the database authorization instruction and the public key information, and writes the data record into the ledger.
  • the client receives the user's confirmation instruction for the authorization prompt information sent by the service end, and generates an authorization request including the service end identifier.
  • the client receives the user's operation instruction, determines the service end to be deauthorized, generates a deauthorization request including the service end identifier and the user identifier, and sends the deauthorization request to the database server
  • the database server determines the corresponding database deauthorization instruction and the ledger identifier according to the deauthorization request, executes the database deauthorization instruction, and cancels the operating authority of the business end in the ledger; correspondingly, the database The server sends deauthorization information including the user ID and account book ID to the service end; any service end that receives the deauthorization information deletes the user ID and the user ID from the list of operable accounts on the service end.
  • ledger identifiers correspondence of ledger identifiers.
  • the data blocks in the blockchain ledger are pre-generated based on the following methods:
  • each data record to be written in the data block is determined, and the Nth data block containing the hash value of the data block and the data record is generated, which specifically includes:
  • the hash value and block height of the initial data block are given based on a preset method
  • the embodiment of this specification also provides an authorization method in the block chain ledger, which is applied to the database server, as shown in FIG. 4, which is the database service provided in the embodiment of the specification.
  • An authorization method in a blockchain ledger at the end including:
  • S401 Receive an authorization request sent by a client, where the authorization request includes a service terminal identifier and a user identifier;
  • S403 Determine a corresponding database authorization instruction and ledger identifier according to the authorization request
  • S407 Send authorization information including the user ID and the account book ID to the service end.
  • the embodiment of this specification also provides an authorization device in the block chain ledger, which is applied to the database server, as shown in FIG. 5, which is a block chain provided by the embodiment of this specification.
  • the structure diagram of the authorization device in the ledgers includes:
  • the receiving module 501 receives an authorization request sent by the client, where the authorization request includes a service terminal identifier and a user identifier;
  • the determining module 503 determines the corresponding database authorization instruction and account book identifier according to the authorization request;
  • the execution module 505 executes the database authorization instruction, determines the business end corresponding to the business end identifier as the user in the ledger corresponding to the ledger identifier, and determines the status of the business end in the ledger Operation authority;
  • the sending module 507 sends the authorization information including the user ID and the account book ID to the service end.
  • the embodiments of this specification also provide a computer device, which includes at least a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the blocks shown in FIG. 4 when the program is executed.
  • a computer device which includes at least a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the blocks shown in FIG. 4 when the program is executed.
  • Authorization method in the chain ledger includes at least a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the blocks shown in FIG. 4 when the program is executed.
  • the device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050.
  • the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050.
  • the processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for execution related Program to implement the technical solutions provided in the embodiments of this specification.
  • CPU Central Processing Unit
  • ASIC Application Specific Integrated Circuit
  • the memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory, random access memory), static storage device, dynamic storage device, etc.
  • the memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, related program codes are stored in the memory 1020 and called and executed by the processor 1010.
  • the input/output interface 1030 is used to connect an input/output module to realize information input and output.
  • the input/output/module can be configured in the device as a component (not shown in the figure), or can be connected to the device to provide corresponding functions.
  • the input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices.
  • the communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 1050 includes a path to transmit information between various components of the device (for example, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).
  • the device may also include the necessary equipment for normal operation.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than all the components shown in the figures.
  • the embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the authorization method in the block chain ledger shown in FIG. 4 is implemented.
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种块链式账本中的授权方法、系统、装置及设备，该方法包括：客户端基于用户的指示，向数据库服务端发起授权请求，而数据库服务端则将授权请求转换为相应的数据库命令操作，通过数据库命令在账本中添加新的用户以及确定用户权限，同时在业务端则更新用户可操作账本列表，以便业务方可以将与用户相关的业务记录写入到账本中。

Description

块链式账本中的授权方法、系统、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及块链式账本中的授权方法、系统、装置及设备。
背景技术
在数据库服务端以块链式的账本对用户提供账本服务时，用户经常在账本中添加或者移出其它相关的业务端(业务端包括其他企业或自然人业务端)，以使得业务端也可以在账本中有相应的操作权限。
基于此，需要在一种在块链式账本中便利的授权方案。
发明内容
本申请实施例的目的是提供一种在块链式账本中便利的授权方案。
为解决上述技术问题，本申请实施例是这样实现的：
一种块链式账本中的授权方法，应用于包括客户端、数据库服务端和业务端的系统中，包括：
客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户标识的授权请求，并发送所述授权请求至数据库服务端；
数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端；
任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务端中的可操作账本列表，并存储。
对应的，本说明书实施例还提供一种块链式账本中的授权系统，包括客户端、数据库服务端和业务端，在所述系统中：
客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户 标识的授权请求，并发送所述授权请求至数据库服务端；
数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端；
任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务端中的可操作账本列表，并存储。
在另一方面，本说明书实施例还提供一种块链式账本中的授权方法，应用于数据库服务端中，包括：
接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识和用户标识；
根据所述授权请求确定对应的数据库授权指令和账本标识；
执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
发送包含所述用户标识和账本标识的授权信息至所述业务端。
与另一方面对应的，本说明书实施例还提供一种块链式账本中的授权装置，应用于数据库服务端中，包括：
接收模块，接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识和用户标识；
确定模块，根据所述授权请求确定对应的数据库授权指令和账本标识；
执行模块，执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
发送模块，发送包含所述用户标识和账本标识的授权信息至所述业务端。
本说明书实施例中的方案，客户端基于用户的指示，向数据库服务端发起授权请求，而数据库服务端则将授权请求转换为相应的数据库命令操作，通过数据库命令在账本中添加新的用户以及确定用户权限，同时在业务端则更新用户可操作账本列表，以便业务方可以将与用户相关的业务记录写入到账本中，此外，用户还可以对于账本中的相关授权业务方移除授权，便于用户对于账本中的可操作成员的管理。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为本说明书实施例所提供的一种生成块链式账本的流程示意图；
图2为本说明书实施例所涉及的一种系统架构的示意图；
图3是本说明书实施例提供的一种块链式账本中的授权方法；
图4为本说明书实施例中所提供的应用于数据库服务端中的一种块链式账本中的授权方法；
图5是本说明书实施例提供的一种块链式账本中的授权装置的结构示意图；
图6是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
首先对本说明书实施例中所涉及的中心化下的块链式的账本予以说明。在中心化的数据库服务提供方，块链式的账本通过如下方式生成，如图1所示，图1为本说明书实施例所提供的一种生成块链式账本的流程示意图，包括：
S101，接收待存储的数据记录，确定各数据记录的哈希值。
此处的待存储的数据记录，可以是客户端个人用户的各种消费记录，也可以是应用服务器基于用户的指令，在执行业务逻辑时产生的业务结果、中间状态以及操作记录等 等。具体的业务场景可以包括消费记录、审计日志、供应链条、政府监管记录、医疗记录等等。
S103，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块。
所述预设的成块条件包括：待存储的数据记录数量达到数量阈值，例如，每接收到一千条数据记录时，生成一个新数据块，将一千条数据记录写入块中；或者，距离上一次成块时刻的时间间隔达到时间阈值，例如，每隔5分钟，生成一个新数据块，将在这5分钟内接收到的数据记录写入块中。
此处的N指的是数据块的序号，换言之，在本说明书实施例中，数据块是以块链的形式，基于成块时间的顺序先后排列，具有很强的时序特征。其中，数据块的块高基于成块时间的先后顺序单调递增。块高可以是序号，此时第N个数据块的块高即为N；块高也可以其它方式生成，例如，将数据块的成块时间对称加密转换为单调递增的大整型数据作为块高。
当N＝1时，即此时的数据块为为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如，初始数据块中不包含数据记录，哈希值则为任一给定的哈希值，块高blknum＝0；又例如，初始数据块的生成触发条件与其它数据块的触发条件一致，但是初始数据块的哈希值由对初始数据块中的所有内容取哈希确定。
当N>1时，由于前一数据块的内容和哈希值已经确定，则此时，可以基于前一数据块(即第N－1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值，例如，一种可行的方式为，确定每一条将要写入第N个块中的数据记录的哈希值，按照在块中的排列顺序，生成一个默克尔树，将默克尔树的根哈希值和前一数据块的哈希值拼接在一起，再次采用哈希算法，生成当前块的哈希值。又例如，还可以按照块中数据记录的顺序进行拼接并取哈希得到整体数据记录的哈希值，拼接前一数据块的哈希值和整体数据记录的哈希值，并对拼接得到的字串进行哈希运算，生成数据块的哈希值。
用户在上传数据成功后，即可以得到对应的数据记录的哈希值以及所处的数据块的哈希值，并保存，并且可以基于该哈希值发起完整性验证。具体的验证方式即为在数据库中重新计算数据记录自身的哈希值以及所处的数据块的哈希值，与本地所保存的进行对比。
通过前述的数据块的生成方式，每一个数据块通过哈希值确定，数据块的哈希值由 数据块中的数据记录的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值发起验证，对于数据块中任何内容(包括对于数据块中数据记录内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致，而导致验证失败，从而实现了中心化下的不可篡改。
在对于块链式的账本进行验证时，一般而言，即指定一段数据块进行连续的完整性验证，或者从初始数据块开始进行连续的完整性验证。验证的方式即为获取前一数据块的哈希值，并采用与生成数据块的哈希值时的同样算法，根据自身的数据记录和前一数据块的哈希值，重新计算一遍自身数据块的哈希值，并与之前的数据块的哈希值进行对比即可。
前述部分对于本说明书实施例所涉及的块链式的账本进行了说明。在实际应用中，用户可以在数据库服务端中创建相应的账本，并写入自身相关的数据记录。例如，在一种应用场景下，用户可以通过客户端与业务方发生诸如购买/卖出基金、保险等与资产相关的行为，由此也会产生相应的资产变更记录。此时，用户可以主动将相应的资产变更记录写入账本中进行存储。
与此同时，业务方还经常会产生于用户相关的诸如交割清单以及对账清单等等，以及还有一些不需要要用户的主动操作的业务，诸如，利息、分红计算等等。此时，用户也有需要业务方将这类数据记录写入到自己的账本中进行存证。
需要说明的是，本说明书实施例中所涉及的块链式账本的用途是用于存证，并不需要涉及对于业务的具体解释。因此，用户通常希望对自己的相关数据记录进行集中式的存储，即，将与不同的业务方所产生的数据记录写入到同一个账本中进行存证。而用户往往可能同时与多个业务方存在业务往来(例如，A基金公司，B证券)，如图2所示，图2为本说明书实施例所涉及的一种系统架构的示意图。用户通过客户端可以与多个业务端存在业务往来，同时，客户端和业务端均可以将产生的相关信息写入到数据库服务端中。
基于此，本说明书实施例提供一种块链式账本中的授权方案，以便用户可以便利的对自己的账本中的用户进行相应的授权管理。
以下结合附图，详细说明本说明书各实施例提供的技术方案。如图3所示，图3是本说明书实施例提供的一种块链式账本中的授权方法，应用于包括客户端、数据库服务端和业务端的系统中，包括：
S301，客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户标识的授权请求，并发送所述授权请求至数据库服务端。
在客户端中，对于需要进行授权的业务端，用户可以在创建账本的时候就进行相应的确认，或者，也可以在账本已经创建之后再进行确认。
一种可实施的方式为，在客户端中，通过提供包含多个业务端列表的形式给用户进行选择，用户在列表中确定出相应的待授权的业务端。
另一种可实施的方式即为，在用户已经创建账本后，当用户在客户端中与业务端产生交易时，即发起授权推荐，用户通过授权推荐确定是否需要给该交易的业务端在账本中进行授权。
在确定待授权的业务端之后，客户端即可以获取相应的用户标识，并生成相应的授权请求，授权请求中包含有用户标识以及业务端标识，并发送所述授权请求至数据库服务端。
在一种实施方式下，如果用户在数据库服务端中创建有多个不同的账本，则客户端还可以提供多份账本提供用户选择，基于用户的选择指令确定相应的账本标识，进而授权请求中还可以包含用户所确认的账本标识。
S303，数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限。
数据库服务端在接收到授权请求后，在授权指令中存在账本标识LID时，即可以获取其中的账本标识；或者，可以根据授权指令中的用户标识确定该用户标识所对应的账本标识。
进一步地，数据库服务端可以将授权请求转换为对应的数据库授权指令,包括CreatRole/CreatMember以及Grant等相应的授权指令。在授权指令中包含有业务端标识以及对应的账本标识。
例如，一种示例性的数据库授权指令可以是如下形式CreatRole(&name,LID)，其中的“name”即为业务端标识，“LID”即为账本标识，通过该方式在账本“LID”中加入用户“name”。
进一步地的，还可以给业务端在账本中配置相应的权限值，例如，Grant(&name， weight)，从而可以给业务端在账本中配置相应的操作权限“weight”。具体的权限值的大小可以从用户预设的权限配置文件中进行读取即可。例如，一般对于新增用户给与“只读”权限。
在通过上述授权指令对数据库执行操作后，数据库即可以返回相应的执行结果信息，表明操作成功。
S305，数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端。
数据库服务端可以将上述执行结果信息、用户标识、账本标识进行打包，生成授权信息，并将授权信息发送至授权请求中的业务端。授权信息中还可以包括有操作权限。
S307，任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务端中的可操作账本列表，并存储。
任一业务端本地保存有可操作账本列表，用于存储业务端可以操作的账本标识LID和用户ID的对应关系，表明业务端对于一名用户的相关信息，应该写入哪个账本。以及，在可操作账本列表中，还可以包括用户授予的操作权限，业务端对于账本可以操作的具体程度，由用户所授予的操作权限限定。一般可以，可以是“写”权限。如表1所示，表1为本说明书实施例所提供的一种示例性的可操作账本列表。即在业务端，对于用户“ID1”所产生的相关报表，可以写入在数据库服务端的第2112号账本中。
表1
UserID LID Weight
ID1 2112 20
ID100 3311 20
…… …… ……
本说明书实施例中的方案，客户端基于用户的指示，向数据库服务端发起授权请求，而数据库服务端则将授权请求转换为相应的数据库命令操作，通过数据库命令在账本中添加新的用户以及确定用户权限，同时在业务端则更新用户可操作账本列表，以便业务方可以将与用户相关的业务记录写入到账本中。
在一种实施方式中，为了保障账本中的数据记录的真实性，业务端在写入数据时，需要对写入的数据进行数字签名(即，使用业务端的私钥进行加密)，此时数据库服务 端则可以获取对应的业务端的公钥信息(公钥信息即为一串字符，可以对称解密私钥加密的数据)，并且将该公钥信息写入用户账本的权限配置文件中。以便以后业务端写入账本中的数据，用户可以在账本中获取相应的公钥进行解密。
如表2所示，表2为本说明书实施例所提供的一种示例性的权限配置表的形式。表中的key1和key2分别表征了用户ROLE01和ROLE02的公钥信息。
表2：用户与权重值系统表
用户名 权重值 Public_Key
SYSADM 100  
ROLE01 50 Key1
ROLE02 25 Key2
对于任一业务端而言，其公钥信息是所有用户公开的，任一用户可以随时获取该公钥信息。因此，数据库服务端可以随时从业务端获取一份业务端的公钥信息，或者，在数据库服务端建立一份相应的业务端公钥信息表，以便随时从该表中获取一份业务端的公钥信息。
在一种实施方式中，数据库服务端还可以在执行数据库授权指令的同时，生成包含所述数据库授权指令的数据记录，并且将数据记录写入账本标识所对应的账本中。通过该方式，即可以将授权指令以数据记录的形式保存在账本中，由于账本中的数据记录是不可篡改的，因此，本次授权行为也就永久性的得以保存，可以作为证据存在。
在这种实施方式下，数据库服务端还可以将该数据记录的哈希值同时返回给客户端和业务端，从而，客户端和业务端可以基于该哈希值对该条数据记录进行查询和验证。
在这种实施方式下，数据库服务端在生成包含数据库授权指令的数据记录时，还可以在数据记录中包含有业务端的公钥信息，从而，业务端的公钥信息也以不可篡改的数据形式存证与账本中。
由于此时将授权指令以及公钥信息写入账本，是由数据库服务端完成的，在这个过程中，还可以由数据库服务端对该包含授权指令和/或公钥信息的数据记录进行数字签名，以保证数据库服务端没有欺骗客户端或者业务端。
在一种实施方式下，在账本已经生成之后。业务端还可以在需要将相应的信息写入 账本，但自己还没有权限时，给客户端发送相应的提示信息。例如，在月末，XX基金需要通过业务系统对个人进行首次付息兑付的清算时，发现对于某些用户的账本还没有写入的权限，此时，基金业务端可以向该类用户发送包含业务端标识的授权提示信息，客户端在接收到授权提示信息之后，进行确认，即可生成包含业务端标识的授权请求。
进一步地，客户端还可以对于已经授权的业务端进行移除或者解除授权，具体的方式即为：
客户端，接收用户的操作指令，确定待解除授权的业务端，生成包含业务端标识和用户标识的解除授权请求，并发送所述解除授权请求至数据库服务端；
相应的，数据库服务端，根据所述解除授权请求确定对应的数据库解除授权指令和账本标识，执行所述数据库解除授权指令，解除所述业务端在所述账本的操作权限。此处的解除授权指令从形式上而言，可以是通过Grant指令来实现，例如，Grant(&name，0)，即将一名用户在账本中的权限设置为最低，从而实现业务端对于该账本没有任何操作权限。
相应的，数据库服务端，发送包含所述用户标识和账本标识的解除授权信息至所述业务端；
任一接收到到解除授权信息的业务端，在所述业务端的可操作账本列表中删除所述用户标识和账本标识的对应关系。
通过上述方式，对于那些不再有业务往来的业务端，用户可以在客户端中方便的对于该类业务端的解除账本权限。
对应的，本说明书实施例还提供一种块链式账本中的授权系统，包括客户端、数据库服务端和业务端，在所述系统中：
客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户标识的授权请求，并发送所述授权请求至数据库服务端；
数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端；
任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务 端中的可操作账本列表，并存储。
进一步地，在所述系统中，数据库服务端获取所述业务端的公钥信息，将所述业务端的公钥信息写入所述账本的权限配置文件。
进一步地，在所述系统中，数据库服务端，生成包含所述数据库授权指令的数据记录，将所述数据记录写入所述账本标识所对应的账本中。
进一步地，在所述系统中，数据库服务端获取所述业务端的公钥信息，生成包含所述数据库授权指令和公钥信息的数据记录，将所述数据记录写入所述账本中。
进一步地，在所述系统中，客户端，接收用户对于业务端所发送的授权提示信息的确认指令，生成包含业务端标识的授权请求。
进一步地，在所述系统中，客户端，接收用户的操作指令，确定待解除授权的业务端，生成包含业务端标识和用户标识的解除授权请求，并发送所述解除授权请求至数据库服务端；相应的，数据库服务端，根据所述解除授权请求确定对应的数据库解除授权指令和账本标识，执行所述数据库解除授权指令，解除所述业务端在所述账本的操作权限；相应的，数据库服务端，发送包含所述用户标识和账本标识的解除授权信息至所述业务端；任一接收到到解除授权信息的业务端，在所述业务端的可操作账本列表中删除所述用户标识和账本标识的对应关系。
进一步地，在所述系统中的数据库服务端，块链式账本中的数据块基于如下方式预先生成：
接收待存储的数据记录，确定各数据记录的哈希值；
当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块。
在另一方面，本说明书实施例还提供一种块链式账本中的授权方法，应用于数据库服务端中，如图4所示，图4为本说明书实施例中所提供的应用于数据库服务端中的一种块链式账本中的授权方法，包括：
S401，接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识 和用户标识；
S403，根据所述授权请求确定对应的数据库授权指令和账本标识；
S405，执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
S407，发送包含所述用户标识和账本标识的授权信息至所述业务端。
与另一方面对应的，本说明书实施例还提供一种块链式账本中的授权装置，应用于数据库服务端中，如图5所示，图5是本说明书实施例提供的一种块链式账本中的授权装置的结构示意图，包括：
接收模块501，接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识和用户标识；
确定模块503，根据所述授权请求确定对应的数据库授权指令和账本标识；
执行模块505，执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
发送模块507，发送包含所述用户标识和账本标识的授权信息至所述业务端。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图4所示的块链式账本中的授权方法。
图6示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储 器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图4所示的块链式账本中的授权方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书 实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (17)

  1. 一种块链式账本中的授权方法，应用于包括客户端、数据库服务端和业务端的系统中，包括：
    客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户标识的授权请求，并发送所述授权请求至数据库服务端；
    数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
    数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端；
    任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务端中的可操作账本列表，并存储。
  2. 如权利要求1所述的方法，数据库服务端在确定所述业务端在所述账本中的操作权限之后，还包括：
    数据库服务端获取所述业务端的公钥信息，将所述业务端的公钥信息写入所述账本的权限配置文件。
  3. 如权利要求1所述的方法，还包括：
    数据库服务端，生成包含所述数据库授权指令的数据记录，将所述数据记录写入所述账本标识所对应的账本中。
  4. 如权利要求3所述的方法，还包括：
    数据库服务端获取所述业务端的公钥信息，生成包含所述数据库授权指令和公钥信息的数据记录，将所述数据记录写入所述账本中。
  5. 如权利要求1所述的方法，客户端接收用户的操作指令，确定待授权的业务端，生成包含业务端标识的授权请求，包括：
    客户端，接收用户对于业务端所发送的授权提示信息的确认指令，生成包含业务端标识的授权请求。
  6. 如权利要求1所述的方法，所述方法还包括：
    客户端，接收用户的操作指令，确定待解除授权的业务端，生成包含业务端标识和用户标识的解除授权请求，并发送所述解除授权请求至数据库服务端；
    相应的，数据库服务端，根据所述解除授权请求确定对应的数据库解除授权指令和账本标识，执行所述数据库解除授权指令，解除所述业务端在所述账本的操作权限；
    相应的，数据库服务端，发送包含所述用户标识和账本标识的解除授权信息至所述 业务端；
    任一接收到到解除授权信息的业务端，在所述业务端的可操作账本列表中删除所述用户标识和账本标识的对应关系。
  7. 如权利要求1所述的方法，在数据库服务端，块链式账本中的数据块基于如下方式预先生成：
    接收待存储的数据记录，确定各数据记录的哈希值；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块。
  8. 一种块链式账本中的授权系统，包括客户端、数据库服务端和业务端，在所述系统中：
    客户端，接收用户的操作指令，确定待授权的业务端，生成包含业务端标识和用户标识的授权请求，并发送所述授权请求至数据库服务端；
    数据库服务端，根据所述授权请求确定对应的数据库授权指令和账本标识，执行所述数据库授权指令，将所述待授权的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
    数据库服务端，发送包含所述用户标识和账本标识的授权信息至所述业务端；
    任一接收到到授权信息的业务端，将所述用户标识和账本标识的对应关系写入业务端中的可操作账本列表，并存储。
  9. 如权利要求8所述的系统，还包括：
    数据库服务端获取所述业务端的公钥信息，将所述业务端的公钥信息写入所述账本的权限配置文件。
  10. 如权利要求8所述的系统，还包括：
    数据库服务端，生成包含所述数据库授权指令的数据记录，将所述数据记录写入所述账本标识所对应的账本中。
  11. 如权利要求10所述的系统，还包括：
    数据库服务端获取所述业务端的公钥信息，生成包含所述数据库授权指令和公钥信息的数据记录，将所述数据记录写入所述账本中。
  12. 如权利要求8所述的系统，在所述系统中，客户端，接收用户对于业务端所发 送的授权提示信息的确认指令，生成包含业务端标识的授权请求。
  13. 如权利要求8所述的系统，在所述系统中，
    客户端，接收用户的操作指令，确定待解除授权的业务端，生成包含业务端标识和用户标识的解除授权请求，并发送所述解除授权请求至数据库服务端；
    相应的，数据库服务端，根据所述解除授权请求确定对应的数据库解除授权指令和账本标识，执行所述数据库解除授权指令，解除所述业务端在所述账本的操作权限；
    相应的，数据库服务端，发送包含所述用户标识和账本标识的解除授权信息至所述业务端；
    任一接收到到解除授权信息的业务端，在所述业务端的可操作账本列表中删除所述用户标识和账本标识的对应关系。
  14. 如权利要求8所述的系统，在所述系统中的数据库服务端，块链式账本中的数据块基于如下方式预先生成：
    接收待存储的数据记录，确定各数据记录的哈希值；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块。
  15. 一种块链式账本中的授权方法，应用于数据库服务端中，包括：
    接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识和用户标识；
    根据所述授权请求确定对应的数据库授权指令和账本标识；
    执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
    发送包含所述用户标识和账本标识的授权信息至所述业务端。
  16. 一种块链式账本中的授权装置，应用于数据库服务端中，包括：
    接收模块，接收客户端所发送的授权请求，其中，所述授权请求中包含业务端标识和用户标识；
    确定模块，根据所述授权请求确定对应的数据库授权指令和账本标识；
    执行模块，执行所述数据库授权指令，将所述业务端标识所对应的的业务端确定为所述账本标识所对应的账本中的用户，并，确定所述业务端在所述账本中的操作权限；
    发送模块，发送包含所述用户标识和账本标识的授权信息至所述业务端。
  17. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求15所述的方法。
PCT/CN2020/072062 2019-06-28 2020-01-14 块链式账本中的授权方法、系统、装置及设备 WO2020258858A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/805,649 US10789376B2 (en) 2019-06-28 2020-02-28 Blockchain authorization
US16/945,772 US10936734B2 (en) 2019-06-28 2020-07-31 Blockchain authorization

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910579351.5 2019-06-28
CN201910579351.5A CN110334153B (zh) 2019-06-28 2019-06-28 块链式账本中的授权方法、系统、装置及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/805,649 Continuation US10789376B2 (en) 2019-06-28 2020-02-28 Blockchain authorization

Publications (1)

Publication Number Publication Date
WO2020258858A1 true WO2020258858A1 (zh) 2020-12-30

Family

ID=68143759

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/072062 WO2020258858A1 (zh) 2019-06-28 2020-01-14 块链式账本中的授权方法、系统、装置及设备

Country Status (2)

Country Link
CN (1) CN110334153B (zh)
WO (1) WO2020258858A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10789376B2 (en) 2019-06-28 2020-09-29 Alibaba Group Holding Limited Blockchain authorization
CN110334153B (zh) * 2019-06-28 2020-09-01 阿里巴巴集团控股有限公司 块链式账本中的授权方法、系统、装置及设备
CN111292082B (zh) * 2020-01-13 2022-12-20 蚂蚁区块链科技(上海)有限公司 一种块链式账本中的公钥管理方法、装置及设备
CN111367446B (zh) * 2020-05-26 2020-09-25 太平金融科技服务（上海）有限公司 业务操作方法、装置、计算机设备和存储介质
CN111506580B (zh) * 2020-06-15 2020-12-22 支付宝(杭州)信息技术有限公司 一种基于中心化块链式账本的交易存储方法
CN112364383B (zh) * 2021-01-12 2021-04-27 支付宝(杭州)信息技术有限公司 一种业务记录真实性验证方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140365347A1 (en) * 2013-06-06 2014-12-11 Intuit Inc. Using commerce networks to facilitate business interactions among entities
CN108632284A (zh) * 2018-05-10 2018-10-09 网易（杭州）网络有限公司 基于区块链的用户数据授权方法、介质、装置和计算设备
CN109002729A (zh) * 2018-07-09 2018-12-14 福建省农村信用社联合社 一种基于金融区块链的客户隐私数据管理方法
CN109146482A (zh) * 2018-08-29 2019-01-04 北京京东尚科信息技术有限公司 基于区块链的用户权益提供方法和装置
CN110334153A (zh) * 2019-06-28 2019-10-15 阿里巴巴集团控股有限公司 块链式账本中的授权方法、系统、装置及设备

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1286022C (zh) * 2002-06-10 2006-11-22 联想(北京)有限公司 用户身份确认和授予操作权限的方法
CN102638473B (zh) * 2012-05-04 2014-12-10 盛趣信息技术（上海）有限公司 一种用户数据授权方法、装置及系统
CN107273760A (zh) * 2017-06-09 2017-10-20 济南浪潮高新科技投资发展有限公司 一种基于区块链多ca应用认证方法
US20190066079A1 (en) * 2017-08-31 2019-02-28 Salesforce.Com, Inc. Methods and systems using a computing platform for routing virtual receipts to customers with a scan-able code generated by the merchant
US20190188706A1 (en) * 2017-12-18 2019-06-20 Apple Inc. Transference tracking
US20190188411A1 (en) * 2017-12-19 2019-06-20 Vladislav Kroutik Systems and Methods for Decentralizing Consumer Preferences, Consent and Permissions Management with Reward and Reputation Network for Enterprises Using a Blockchain Ledger
CN109063169A (zh) * 2018-08-17 2018-12-21 福建省农村信用社联合社 一种基于区块链的客户数据管理系统
CN109583184B (zh) * 2018-10-09 2020-08-04 阿里巴巴集团控股有限公司 身份验证方法及装置和电子设备
CN109522735B (zh) * 2018-11-29 2021-06-22 上海信联信息发展股份有限公司 一种基于智能合约的数据权限验证方法及装置
CN109657486A (zh) * 2018-12-18 2019-04-19 青岛轮子软件科技有限公司 一种基于区块链技术的金融机构用户数据共享方法与系统
CN109729080B (zh) * 2018-12-20 2021-05-11 全链通有限公司 基于区块链域名系统的访问攻击防护方法和系统
CN109660346B (zh) * 2019-01-16 2021-09-17 中钞信用卡产业发展有限公司杭州区块链技术研究院 信息托管方法、装置、设备及计算机存储介质
CN109902086B (zh) * 2019-01-31 2022-12-20 创新先进技术有限公司 一种索引创建方法、装置及设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140365347A1 (en) * 2013-06-06 2014-12-11 Intuit Inc. Using commerce networks to facilitate business interactions among entities
CN108632284A (zh) * 2018-05-10 2018-10-09 网易（杭州）网络有限公司 基于区块链的用户数据授权方法、介质、装置和计算设备
CN109002729A (zh) * 2018-07-09 2018-12-14 福建省农村信用社联合社 一种基于金融区块链的客户隐私数据管理方法
CN109146482A (zh) * 2018-08-29 2019-01-04 北京京东尚科信息技术有限公司 基于区块链的用户权益提供方法和装置
CN110334153A (zh) * 2019-06-28 2019-10-15 阿里巴巴集团控股有限公司 块链式账本中的授权方法、系统、装置及设备

Also Published As

Publication number Publication date
CN110334153B (zh) 2020-09-01
CN110334153A (zh) 2019-10-15

Similar Documents

Publication Publication Date Title
WO2020258858A1 (zh) 块链式账本中的授权方法、系统、装置及设备
TWI727594B (zh) 塊鏈式帳本中的簽名驗證方法、系統、裝置及設備
EP3665857B1 (en) Blockchain architecture with record security
US10958436B2 (en) Methods contract generator and validation server for access control of contract data in a distributed system with distributed consensus
US11057220B2 (en) Signature verification for a blockchain ledger
CN109902086A (zh) 一种索引创建方法、装置及设备
WO2021000578A1 (zh) 一种块链式账本中的用户创建方法、装置及设备
CN113726751B (zh) 一种块链式账本中的权重管理方法、装置及设备
US10791122B2 (en) Blockchain user account data
CN109951290A (zh) 一种链式账本的授时认证方法、装置及设备
US10783277B2 (en) Blockchain-type data storage
WO2020199708A1 (zh) 一种针对授时证书生成请求的监控方法、装置及设备
WO2020233149A1 (zh) 一种块链式账本中的授时认证方法、装置及设备
WO2020199710A1 (zh) 一种账本的验证方法、装置及设备
US10936734B2 (en) Blockchain authorization
US11108573B2 (en) Blockchain ledger authentication
WO2020211493A1 (zh) 一种块链式账本中的数据验证方法、系统、装置及设备
CN110008203A (zh) 一种数据清除方法、装置及设备
CN110347745A (zh) 一种块链式账本的授时认证方法、装置及设备
CN114039733B (zh) 一种针对联盟链的存证业务转移方法、装置及设备
CN110851851B (zh) 一种块链式账本中的权限管理方法、装置及设备
US10979233B2 (en) Monitoring time certificate generation requests
CN110019373A (zh) 一种基于哈希值的数据查询方法、装置及设备
CN110020547A (zh) 一种数据隐匿方法、装置及设备
WO2021057183A1 (zh) 一种块链式账本中的权限移交方法、装置及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20832861

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20832861

Country of ref document: EP

Kind code of ref document: A1