EP4200780A1 - Systèmes et procédés de commande d'accès basée sur consensus pour des fonctions de contrat intelligent - Google Patents

Systèmes et procédés de commande d'accès basée sur consensus pour des fonctions de contrat intelligent

Info

Publication number
EP4200780A1
EP4200780A1 EP21859060.2A EP21859060A EP4200780A1 EP 4200780 A1 EP4200780 A1 EP 4200780A1 EP 21859060 A EP21859060 A EP 21859060A EP 4200780 A1 EP4200780 A1 EP 4200780A1
Authority
EP
European Patent Office
Prior art keywords
smart contract
blockchain
function
signed
module
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.)
Pending
Application number
EP21859060.2A
Other languages
German (de)
English (en)
Inventor
Peter Jihoon KIM
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coinbase Inc
Original Assignee
Coinbase Inc
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
Priority claimed from US17/331,114 external-priority patent/US20210374731A1/en
Application filed by Coinbase Inc filed Critical Coinbase Inc
Publication of EP4200780A1 publication Critical patent/EP4200780A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • This invention relates generally to the smart contact field, and more specifically to a new and useful system and method for managing security for smart contracts.
  • FIGs. 1A-E are schematic representations of the system, in accordance with various embodiments.
  • Fig. 1F is a schematic representation of a target smart contract, in accordance with various embodiments.
  • Fig. 1G is a schematic representation of an administration smart contract, in accordance with various embodiments.
  • FIGs. 2A-C are representations of the method, in accordance with various embodiments.
  • FIGs. 3A-B are representations of admin system configuration, in accordance with various embodiments.
  • Fig. 4 is a representation of proposal and voting, in accordance with various embodiments.
  • Fig. 5 is a schematic representation of an example of proposal, voting, and voting execution, in accordance with various embodiments.
  • Fig. 6 is a schematic representation of an example method, in accordance with various embodiments.
  • Smart contracts typically implement one or more functions that can be invoked by broadcasting a signed transaction to a blockchain that manages the smart contract.
  • the transaction can identify the function to be invoked, and any function arguments (parameters).
  • the transaction is typically signed by using a private key associated with a blockchain address or account.
  • the private key used to invoke smart contract functions can also be used to sign transactions that transfer assets managed by the blockchain.
  • token contracts e.g., contracts that manage ERC-20 compatible tokens, etc.
  • token management functions it is desirable to restrict access to token management functions to a limited set of trusted participants.
  • the smart contract can require that some function execution transactions be signed using a private key that is accessible by one or more authorized entities.
  • the system and method provide configurable access control for execution of smart contract functions (methods).
  • the system is a smart contract that implements one or more functions, and also implements access control for at least one implemented function (e.g., of a target smart contract).
  • the system functions to proxy smart contract function execution requests received from eligible participants to one or more smart contracts by performing access control.
  • the system itself can be implemented as a smart contract, or otherwise implemented.
  • the method functions to perform access control for execution of smart contract functions.
  • the method can include configuring access control (e.g., identifying participants that can perform function execution) for at least one smart contract function.
  • execution of the function can be restricted to one or more participants, and any one of the allowed participants can invoke the function (without consensus from other participants).
  • consensus-based access control is implemented for at least one smart contract function.
  • the method can include proposing execution of at least one smart contract function, and execution of at least one smart contract function (e.g., if a required number of votes have been received from eligible voters).
  • the system functions to provide access control for execution of smart contract functions (methods).
  • the system itself can be implemented as a smart contract, or otherwise implemented.
  • FIGs. 1A-E are schematic representations of a system 100, in accordance with various embodiments.
  • the system includes a smart contract (e.g., 151-153 of Fig. 1A) that implements one or more functions, and also implements access control for at least one implemented function.
  • a smart contract e.g., 151-153 of Fig. 1A
  • the smart contract can include a smart contract administration system (admin system) no that functions to perform access control (e.g., as shown in Fig. 1E).
  • Participant systems can access the smart contract directly, or indirectly via an interface 111 (e.g., an API, a graphical user interface, a web application, etc.).
  • the system functions to proxy smart contract function execution requests received from eligible participants (e.g., 121-123 shown in Fig. 1A) to one or more target smart contracts (e.g., 151-153 shown in FIG. 1A) by performing access control.
  • target smart contracts are smart contracts for which access control is performed by the system 100.
  • the system can include a smart contract administration system no that functions to perform access control.
  • the smart contract administration system no can be an off-chain system (e.g., as shown in Fig. 1B), an on-chain system (e.g., as shown in Fig. 1C), or a combination of on-chain (e.g., admin smart contract 112) and off-chain (e.g., interface 111) systems (e.g., as shown in Fig. 1D).
  • the smart contract administration system no can provide access control for several smart contracts (e.g., 151-153 in Fig. 1A).
  • the smart contracts can be on a same blockchain network (e.g., 141 as illustrated in Fig. 1B, Fig. 1C, and Fig. 1D) , or included in several different blockchain networks (e.g., Ethereum, EOS, etc.).
  • the smart contract administration system 110 can receive input (e.g., via an interface) from at least one of: a participant system (e.g., 121-123), an owner system (e.g., 125), and an administrator system (e.g., 124). Additionally, or alternatively, one or more of a participant system (e.g., 121-123 of Fig. 1A), an owner system (e.g., 125 of Fig. 1A), and an administrator system (e.g., 124 of Fig. 1A) can sign a transaction that invokes a smart contract function implemented by the smart contract administration system (e.g., in variants in which the system no is implemented as a smart contract).
  • a participant system e.g., 121-123
  • an owner system e.g., 125 of Fig. 1A
  • an administrator system e.g., 124 of Fig. 1A
  • Fig. 1F shows example smart contract functions included in a target smart contract 151.
  • At least one target contract implements at least one function that can only be invoked by a transaction made from a predefined address that corresponds to a specific private key or smart contract address (e.g., as determined from the msg. sender of the transaction).
  • the target contract can be configured such that function can only be invoked by a transaction made by a smart contract address of the smart contract administration system no (e.g., a smart contract address of the admin smart contract 112).
  • the target contract e.g., 151) has a number of roles (addresses) which control different functionality. For example, roles can be assigned to a set of one or more functions implemented by the target contract, and an address (e.g., an externally owned account address, a smart contract address, etc.) can be assigned to each role.
  • target contract is a token smart contract that has the following roles: master, mint er, mint er, pauser, blacklister, owner, and administrator.
  • the master minter adds and removes minters and increases their minting allowance.
  • Minters create and destroy tokens.
  • a pauser pauses the contract, which prevents all transfers, minting, and burning.
  • a backlister prevents all transfers to or from a particular address, and prevents that address from minting or burning.
  • An owner can reassign any of the roles except for admin.
  • An admin can upgrade the contract and reassign itself.
  • the target smart contract implements at least one standard method/ function of the ERC-20 interface.
  • the target smart contract can implement at least one extended method/ function of the ERC-20 interface.
  • a blacklisted address will be unable to call transferQ, transferFromQ, or approveQ, and will be unable to receive tokens; transferQ, transferFromQ, and approveQ, will fail if the contract has been paused.
  • the token smart contract allows multiple entities to create and destroy tokens.
  • Each minter can have a mintingAllowance, which can be configurable.
  • the mintingAllowance identifies how many tokens that a minter may issue, and as a minter issues tokens, its mintingAllownce declines.
  • Minters can be added via the configureMinterQ function.
  • a mintingAllowance is specified, which is the number of tokens that address is allowed to mint. As a minter mints tokens, the mintingAllowance will decline.
  • only the masterMinter role may call configureMinter. When a minter’s allowance is low, configureMinter can be called to reset the mintingAllowance to a higher value.
  • Minters can be removed via the removeMinter function. This will remove the minter from the list of minters and set its mintingAllowance to zero. Once a minter is removed, it will no longer be able to mint or burn tokens. In variants, only the masterMinter role may call removeMinter.
  • a minter mints tokens via the mint function.
  • the minter specifies the amount of tokens to create and a To address which will own the newly created tokens.
  • a minter may only mint an amount less than or equal to its minting allowance.
  • the minting allowance will decrease by the amount of tokens minted; and the balance of the To address and total supply will each increase by amount of tokens minted.
  • only a minter may call the minting function.
  • minting fails when the contract is paused.
  • minting fails when the minter or the To address is blacklisted.
  • the minter emits a Mint event and a Transfer event.
  • a minter burns tokens via the burn function.
  • the minter specifies the amount of tokens to burn, and the minter must have a balance greater than or equal to the amount.
  • Burning tokens is restricted to the minter addresses to avoid accidental burning of tokens by end users.
  • a minter with a mintingAllowance of zero is allowed to burn tokens.
  • a minter can only burn tokens which it owns. When a minter burns tokens, its balance and the totalSupply are reduced by the amount. In variants, burning tokens will not increase the mintingAllowance of the address doing the burning.
  • the token smart contract can blacklist addresses. Blacklisted addresses are unable to transfer tokens, approve tokens, mint tokens, or burn tokens. Addresses can be blacklisted by using the blacklist function of the token smart contract. In variations, only a blacklister role can call the blacklist function.
  • the token smart contract implements an unblacklist function that removes an account from a blacklist.
  • the token smart contract implements an unblacklist function that removes an account from a blacklist.
  • only a blacklister roll can call the unblacklist function.
  • the token smart contract implements a pause function that can be called to pause the token smart contract. Pausing can be performed in cases of a serious bug, or key compromise. Al transfers, minting, burning, and adding minters will be prevented while the contact is paused. Other functionality, such as modifying the blacklist, removing minters, changing roles, and upgrading can remain operational, as those functions might be required to fix or mitigate the issue that caused the pausing of the contract.
  • the token smart contract can implement an unpause function that can be called by the pauser role.
  • the token smart contract implements an upgrade function that can be called to upgrade the token smart contract.
  • only the admin role can call the upgrade function.
  • the target smart contract can be: a distributed application (e.g., DApp, such as CryptokittiesTM), an ERC-20 token smart contract, and/or any other suitable smart contract (e.g., on the Ethereum blockchain or a different blockchain).
  • DApp such as CryptokittiesTM
  • ERC-20 token smart contract e.g., on the Ethereum blockchain or a different blockchain.
  • Fig. 1G shows example smart contract functions included in a smart contract administration system no that is implemented as a smart contract.
  • Participant systems, admin systems, and owner systems can be any suitable type of computing system (e.g., mobile device, laptop, server, embedded computing system, wearable device, etc.).
  • the interface in functions to provide a more user-friendly interface for configuring smart contract administration system no, as compared to configuring smart contract administration system no using a low-level interface (such as a native smart contract interface).
  • the interface ill can include any suitable type of API module for receiving API requests, processing received API requests to generate API responses, and providing generated API responses.
  • the interface ill can include a user interface.
  • the interface ill can be implemented as an on-chain interface, or a combination of on-chain and off-chain interfaces. However, the interface can otherwise be implemented.
  • one or more of the components of the system are implemented as a hardware device that includes one or more of a processor (e.g., a CPU (central processing unit), GPU (graphics processing unit), NPU (neural processing unit), etc.), a display device, a memory, a storage device, an audible output device, an input device, an output device, and a communication interface.
  • a processor e.g., a CPU (central processing unit), GPU (graphics processing unit), NPU (neural processing unit), etc.
  • a display device e.g., a CPU (central processing unit), GPU (graphics processing unit), NPU (neural processing unit), etc.
  • a display device e.g., a display device, a memory, a storage device, an audible output device, an input device, an output device, and a communication interface.
  • one or more components included in a hardware device are communicatively coupled via a bus.
  • one or more components included in the hardware device are communicatively
  • the communication interface functions to communicate data between the hardware device and another device via a network (e.g., a private network, a public network, the Internet, and the like).
  • a network e.g., a private network, a public network, the Internet, and the like.
  • the storage device includes the machine-executable instructions for performing at least a portion of the method 200 described herein.
  • At least one component of the system performs at least a portion of the method 200 described herein.
  • FIGs. 2A-C are representations of the method in accordance with embodiments.
  • the method includes configuring access control S210 (e.g., by invoking functions of a target smart contract, by invoking functions of an administration smart contract, by processing API calls at smart contract administration systems, etc.).
  • the method can optionally include one or more of determining consensus for function execution S220, and executing a function S230.
  • configuring access control S210 can include configuring at least one role of at least one target smart contract S211.
  • the roles of the target smart contract can be configured at any suitable time, and in response to any suitable trigger. In some implementations, only an owner or administrator of the target smart contract can configure the roles. However, roles can be configured in any suitable manner.
  • Configuring a role of a target smart contract can include one or more of: defining one or more roles, assigning a role to one or more smart contract functions, and assigning participant identifiers to one or more roles. Roles can function to provide access control by defining a set of participants that can invoke function calls of the smart contract, and defining which function calls each participant can invoke.
  • the target smart can identify a participant associated with the function call (e.g., by address, digital signature, etc.), and permit the function to be executed only if the identified participant is authorized to execute the function (e.g., as identified by a role definition).
  • a participant associated with the function call e.g., by address, digital signature, etc.
  • roles can include master minter, minter, pauser, blacklister, owner, and administrator.
  • one or more participants can be assigned to each role.
  • participants assigned to a role are identified by a blockchain address.
  • the blockchain address (or account) can be the address of an externally owned account (EOA), or a smart contract address.
  • EOA externally owned account
  • the address can be derived from an elliptic-curve key pair, or otherwise derived.
  • EAO accounts are indistinguishable from smart contracts in terms of address format, and this property allows smart contracts to accept both EOA addresses or smart contract addresses for role assignments.
  • participants assigned to a role can be identified by a signing public key.
  • the target smart contract can require that all function execution blockchain transactions include a digital signature that can be verified by using the signing public key assigned to the role for the corresponding function.
  • participants can otherwise be identified in a role assignment.
  • the smart contract administration system no is assigned to at least one role of the target smart contract as a participant (e.g., by using a smart contract address of smart contract administration system no, by using a signing public key of smart contract administration system no, etc.), example shown in Fig. 5.
  • smart contract administration system 110 can automatically execute target smart contract functions that are assigned the smart contract administration system’s role at the target smart contract. For example, smart contract administration system 110 can execute a function periodically, in accordance with rules, in response to a request, in response to one or more triggers, or at any other suitable time.
  • smart contract administration system no executes target smart contract functions in response to consensus-based approval (e.g., implemented using a multi-signature voting process), an example of which is shown in Fig. 5.
  • target smart contract functions in response to consensus-based approval (e.g., implemented using a multi-signature voting process), an example of which is shown in Fig. 5.
  • smart contract administration system no can provide multi-signature functionality for execution of the target smart contract’s functions, without modifying the target smart contract’s code.
  • configuring access control S210 can include configuring consensus-based access control at the admin system S212.
  • Consensusbased access control can be configured for one or more target smart contracts (e.g., 151-153)-
  • the target smart contracts can be executed by the same blockchain, or executed by a plurality of blockchains.
  • Target smart contracts can implement one or more functions, and consensuses-based access control can be configured for any smart contract function.
  • configuration of consensus-based access control at smart contract administration system no is restricted to authorized participants or roles.
  • smart contract administration system 110 has an owner role, and one or more administrator (admin) roles.
  • the owner is permitted to add or remove admins, and change the owner.
  • changing admins or owners can be subject to consensus-based access control (e.g., by using smart contract administration system no).
  • Each admin is permitted to configure consensusbased access control for one or more smart contract functions.
  • smart contract administration system no functions to provide access control for a single target smart contract, and the owner can add one or more admins that are authorized to configure access control for the target smart contract (e.g., a USDC token contract).
  • smart contract administration system 110 provides a multi -tenant access control platform that provides access control for any number of target smart contracts as discussed in more detail below.
  • Figs. 3A and 3B show exemplary configuration 301 of a multi-tenant admin system no that has several platform accounts, each account managing a respective set of smart contracts.
  • the owner of a target smart contract can create an access control account at smart contract administration system 110, and the owner 303 of smart contract administration system no can add one or more admins for the access control account.
  • Each of these admins can configure access control for the target smart contract associated with the access control account, by using smart contract administration system no.
  • An owner of the access control account can request the owner of smart contract administration system no to add or remove admins as needed (e.g., via a user interface, API, customer service call, etc.).
  • an owner of an access control account can configure access control for one or more smart contracts.
  • the access control account owner can configure access control for one or more functions. Administrators can be assigned to each smart contract, or for individual (or groups of) smart contract functions. An administrator for a function can add or update configuration (e.g., 302) for the function.
  • configuring consensus-based access control at the admin system S212 for a target smart contract function includes defining consensus-based access control configuration information (e.g., 302 shown in Figs. 3A-B).
  • configuration information identifies one or more of: a smart contract function, the associated target smart contract, and consensus-based access control parameters for the function.
  • consensus-based access control parameters include one or more of: identities of eligible consensus voters, and a required number of voters.
  • the target smart contract can be an admin smart contract (e.g., 112) used by smart contract administration system no, and access control can be configured for one or more functions of the admin smart contract.
  • the smart contract administration system 110 (e.g., admin smart contract 112) can include (e.g., store, enforce, enact, etc.) different configurations for: different functions of the admin smart contract, different target smart contracts, different target smart contract functions, different blockchain actions, and/ or other modules or control targets.
  • Different configurations can have: different sets of authorized addresses (e.g., cryptocurrency addresses; eligible voters or approvers; etc.), different acceptance requirements (e.g., different signature thresholds or consensus thresholds, different proposal vote thresholds, different approval vote thresholds, different proposal expiration times, different location requirements, etc.), different execution requirements (e.g., different execution times, different execution schedules, different execution logic, different execution target contracts, different execution target contract functions or function signatures, etc.), and/or otherwise vary.
  • authorized addresses e.g., cryptocurrency addresses; eligible voters or approvers; etc.
  • different acceptance requirements e.g., different signature thresholds or consensus thresholds, different proposal vote thresholds, different approval vote thresholds, different proposal expiration times, different location requirements, etc.
  • different execution requirements e.g., different execution times, different execution schedules, different execution logic, different execution target contracts, different execution target contract functions or function signatures, etc.
  • the smart contract administration system can require a unanimous vote from a first set of approvers before calling a first target contract function (e.g., a sensitive function, such as minting or pausing the target contract), and require a subset of votes from a second set of approvers before calling a second target contract function (e.g., a reversible function, such as blacklisting a cryptocurrency address).
  • the first and second target contract functions can be from the same or different target contract.
  • the first and second set of approvers can be the same or different (e.g., entirely different, include overlapping addresses, etc.).
  • the smart contract administration system e.g., admin smart contract
  • a first schedule e.g., every B mined blocks
  • the configurations for each control target can be: automatically specified, manually specified (e.g., using signed blockchain messages received from a threshold number of addresses authorized to change the configurations), be a default, be specified as a batch (e.g., wherein the configurations for all functions of a target contract can inherit the configurations of the target contract), be specified individually, and/ or otherwise specified.
  • smart contract administration system no receives configuration information for configuring consensus-based access control via an interface (e.g., a user interface, an off-chain API, a smart contract interface, etc.).
  • an interface e.g., a user interface, an off-chain API, a smart contract interface, etc.
  • smart contract administration system no is an off-chain system (e.g., as shown in Fig. 1B), and smart contract administration system no receives configuration information via one of a user interface and an off-chain API.
  • smart contract administration system no is an on-chain smart contract (e.g., as shown in Fig. 1C), and smart contract administration system no receives configuration information via the on-chain smart contract’s interface.
  • smart contract administration system no includes an interface ill, and an on-chain smart contract 112 (e.g., as shown in Fig. 1D).
  • the interface 111 receives the configuration information from a participant system (e.g., 121), and the interface 111 provides the configuration to the smart contract 112 via the smart contract’s on-chain interface.
  • the interface receives the configuration information and generates an unsigned smart contract transaction (example shown in Fig. 5) that can then be downloaded and sent to an air-gapped machine for signing and then broadcasting to a blockchain network.
  • the private key(s) used to sign such transactions can be managed in any suitable secure manner (e.g., using hardware security modules, cold storage, multi-signature, multi-party computation, etc.).
  • the user interface is a graphical user interface that displays smart contracts that can be configured, and functions for each smart contract. By displaying available functions for a smart contract, a participant does not have to query a blockchain, or review smart contract source code, to identify smart contract functions that can be configured for consensusbased access control.
  • the user interface filters the list of smart contracts and functions that are displayed, based on one or more parameters. For example, the user interface can display only smart contracts and functions that can be configured by a user that is currently accessing the user interface.
  • the user interface can perform input validation to validate configuration information input by a user.
  • voters and admins can be different entities, and voters and admins can have different privileges.
  • admins can define configuration information for a smart contract function (for which the admin has admin privileges), which includes identifying eligible voters. While eligible voters can propose function calls, vote on function calls, and trigger execution of function calls, voters cannot define smart contract configuration information (e.g., add or remove voters). In this manner, protection is provided against a threat of voters colluding to add more malicious voters.
  • Configuring consensus-based access control S212 can include specifying configuration information for at least one smart contract function.
  • Specifying configuration information can include one or more of: adding eligible voters for voting for proposals to call a smart contract function, removing eligible voters, and setting a number of eligible votes required to execute a smart contract function.
  • other configuration actions can be performed.
  • Adding an eligible voter for a smart contract function includes identifying at least one participant that can vote for a proposal to execute the function. Participants can be identified by one or more of: a blockchain address, a digital signature, authentication credentials, a security token, etc. However, participants can otherwise be identified. Eligible voters can include smart contracts or applications that can vote for proposals, as well as human individuals. Functions implemented by smart contract voters can themselves be configured for consensus-based access control by using smart contract administration system no.
  • Voters are specific to a given function in a given contract. Adding an eligible voter includes identifying an address of the smart contract, a function identifier for the function, and a list of one or more voter addresses.
  • each function is identified by using a four-byte identifier that is derived by hashing the function’s signature.
  • an Ethereum cryptographic hash function e.g., Keccak256
  • Keccak256 is used to hash the function’s signature.
  • any suitable hash function can be used.
  • functions can otherwise be identified.
  • only an administrator that is authorized to configure the function can add eligible voters for the function.
  • a single voter can be configured for a function, however, several voters are preferably added to provide consensus-based access control.
  • removing an eligible voter for a smart contract function includes identifying at least one blockchain address to be removed as a voter for the function.
  • Removing an eligible voter includes identifying an address of the smart contract, a function identifier for the function, and a list of one or more voter addresses to be removed.
  • only an administrator that is authorized to configure the function can remove eligible voters for the function.
  • Setting a number of eligible votes required to execute a smart contract function can include identifying an address of the smart contract, a function identifier for the function, and the minimum number of eligible votes.
  • the minimum number of eligible votes can be any number greater than zero.
  • only an administrator that is authorized to configure the function can set the number of eligible votes for the function.
  • configuration information for a smart contract function can be queried.
  • smart contract administration system no can query configuration information for a smart contract function to determine if a blockchain address is an eligible voter for the function. Additionally, or alternatively, smart contract administration system no can query configuration information for a smart contract function to identify a minimum number of votes required to execute the function.
  • Determining consensus for function execution S220 can include determining whether a smart contract function can be executed (example shown in Fig. 2C,). In an implementation, consensus is determined individually for each function. Determining consensus can include proposing function execution S221, voting for a proposed function execution S222, and determining if a required number of eligible votes has been received S223. An example of consensus determination is shown in Fig. 4 as discussed further below.
  • Proposal and voting can be performed on-line or off-line, and synchronously or asynchronously.
  • proposal and voting can be performed by using participant devices (e.g., 121-123) that communicate with smart contract administration system no via a public network connection (e.g., the Internet). Additionally, or alternatively, one or more participant systems can communicate with smart contract administration system no via a private network connection.
  • proposals are performed at predetermined times.
  • proposals can be performed at any suitable time, such as when a proposer decides to submit a proposal.
  • participant systems in the secure environment.
  • participants can be located in various geographic locations, and each participant can communicate their vote in an asynchronous manner (e.g., when they are ready to vote, when they are present at their participant system, when they have network access, etc.).
  • a participant e.g., operating or controlling a participant system 121-123 can propose function execution via an interface (e.g., 111).
  • a participant can interface with the admin smart contract 112 directly to propose function execution.
  • the participant’s participant system e.g., 121 can submit a signed transaction that invokes a proposeQ function of the admin smart contract 112.
  • the proposer uses gas to invoke the proposeQ function.
  • Arguments to the proposeQ function can identify the function, the smart contract, and the function arguments to be used during execution of the function.
  • participants can be users operating participant systems, or automated systems (e.g., other smart contracts).
  • Proposing function execution includes identifying an address of the smart contract, a function identifier for the function, and optionally argument (parameter) data for the execution of the function.
  • the argument data is encoded using ABI-Encoding.
  • smart contract administration system no generates a proposal identifier for each proposed function execution.
  • the proposal ID is a unique, sequential identifier.
  • the proposal ID is generated (and emitted) when the proposeQ function of the admin contract 112 is executed.
  • an identifier of the proposer is recorded for the proposal.
  • only an eligible voter for the function is authorized to propose execution of the function.
  • smart contract administration system no performs authentication and/ or validity checks before processing a proposal.
  • smart contract administration system 110 can authenticate the proposer as a valid proposer for the function.
  • smart contract administration system 110 can determine whether the proposal has been submitted during a valid proposal submission period (e.g., during a time window in which proposals can be made). For example, proposals can only be accepted at pre-scheduled times (e.g., during pre-specified administration meetings).
  • a voting proposal notification is sent to each eligible voter.
  • the voting proposal notification can identify the proposal identifier generated for the proposal.
  • the voting proposal notification is preferably an off-chain notification (e.g., email, push notification, app notification, web notification, SMS, etc.), but can alternatively be an on-chain notification (e.g., detection of the blockchain event associated with the proposal, detecting that a transaction associated with a transaction hash for the proposal transaction has been mined, etc.) or other notification.
  • the voting proposal notification can be sent by the smart contract administration system, by an offchain orchestration system, and/ or by any other suitable system.
  • the voters e.g., users
  • the voters can monitor the blockchain (e.g., monitor the admin smart contract’s events, etc.) to determine whether subsequent action (e.g., message generation and signing) is needed from them.
  • subsequent action e.g., message generation and signing
  • the voters can be otherwise notified.
  • the proposer can close a proposal without executing the function. In variants, only the proposer can close a proposal.
  • a request to close a proposal identifies the proposal ID generated for the proposal.
  • a proposal for function execution is a vote for the proposal.
  • a proposal for function execution is not a vote, and the proposer must explicitly vote for the proposal.
  • Voting for a proposed function execution S222 can include receiving votes from one or more eligible voters for the proposed function execution. Votes can be received directly by a smart contract (e.g., 112) of smart contract administration system no, or indirectly via an interface (e.g., 111).
  • each vote is a message (or API call, or signed blockchain transaction, example of which is shown in Fig. 5) that identifies the voter and the proposal ID for the function execution being proposed.
  • a vote is a signed blockchain transaction that invokes a voteQ function of the admin smart contract 112.
  • the voter uses gas to invoke the voteQ function.
  • the proposal ID is the sole argument for the voteQ function.
  • the vote blockchain transaction is signed by using a signing key of the participant that is performing the voting. The signing key can be secured in any suitable manner (e.g., using hardware security modules, cold storage, multi-signature, multi-party computation, etc.).
  • voters can be identified by one or more of: a blockchain address, a digital signature, authentication credentials, a security token, etc. However, voters can be otherwise identified. Smart contract administration system no can determine if a voter is an eligible voter for the proposal by retrieving the configuration information for the function associated with the proposal ID. If a vote is received from an in-eligible participant, then the vote is rejected. In variants, the proposer for the proposal can also be an eligible voter.
  • an eligible voter can rescind their vote by providing a message (or API call, or blockchain transaction) to smart contract administration system no (or a component of the admin system, e.g., 111, 112) that identifies the voter and the proposal ID for the vote being rescinded.
  • smart contract administration system no or a component of the admin system, e.g., 111, 112
  • a vote cannot be rescinded.
  • smart contract administration system no tracks state for each proposal, including one or more of: the proposal ID, whether the proposed function execution has been performed (isExecutedQ), the current number of votes received (numVotesQ), whether the proposal has received the minimum number or required votes (and thus the associated function can be executed) (isExecutableQ), and identities of voters who have voted for the proposal (hasVotedQ).
  • state information can be recorded for each proposal.
  • smart contract administration system no tracks proposals for each eligible voter, such that outstanding proposals awaiting votes from an eligible voter can be identified.
  • a participant can submit a query to smart contract administration system no to identify proposals awaiting their vote.
  • a participant system can periodically poll smart contract administration system no for outstanding proposals requiring a vote from the participant.
  • smart contract administration system no can send voting reminders for proposals awaiting votes. Voting reminders can be sent to respective participant systems in any suitable manner (e.g., through a notification system, via a user interface, via SMS, e-mail, telephone, etc.).
  • Determining if a required number of votes has been received S223 for a proposal includes tracking eligible votes for the proposal, and comparing the number of eligible votes received with the minimum number of required votes configured for the associated smart contract function. If the received votes are equal to or greater than the configured minimum number, then the required number of votes has been received.
  • Executing a function S230 functions to execute a function related to an approved proposal.
  • any suitable component of smart contract administration system no can execute the function.
  • an administration smart contract e.g., 112 executes the function.
  • the admin smart contact executes the function by using a CALL opcode (e.g., a CALL Ethereum opcode).
  • CALL opcode e.g., a CALL Ethereum opcode
  • any eligible voter for the function can initiate execution of the function.
  • only the proposer can initiate execution of the function.
  • function execution can be initiated by submitting a signed transaction that invokes an executeQ function of the admin smart contract 112 (example shown in Fig. 5).
  • the entity executing the function uses gas to invoke the executeQ function.
  • Arguments to the execute() function can identify the proposal ID for the function execution (and optionally arguments for the function).
  • arguments for the function execution received during proposal (at S221).
  • the arguments are stored for use during function execution at S230.
  • the arguments are stored in an admin smart contract 112.
  • the arguments can be deleted from the admin smart contract 112 after function execution.
  • any gas refunded to the admin smart contact 112 after deletion of the arguments is transferred to the proposer.
  • arguments for function execution are not stored prior to function execution, and arguments for the function are provided during function execution.
  • the function for an approved proposal can be executed at any suitable time once the required number of votes has been received.
  • the function can be executed in response to receiving the final vote, in response to receiving a request to execute, or in response to any suitable trigger.
  • the function is executed as soon as the corresponding proposal has been approved.
  • the function is executed at a later time, e.g., after additional execution criteria is satisfied.
  • the function maybe scheduled to be executed at a particular time, after a particular event has been detected, in response to a trigger, etc.
  • the function can be approved for execution after proposal at S221.
  • Function execution can include: optionally verifying that the proposal is open and executable, optionally verifying that the target contract is a smart contract, optionally determining the function signature for the target contract’s function call (e.g., using Keccak256, the target contract’s function call, and the function variables), determining the function selector (e.g., as the selector for the target contract’s function, the first 4 bytes of the function signature), and calling the function at the target contract using the function selector (example shown in Fig. 5).
  • the target contract can verify the admin system’s authority to call the function (e.g., based on the msg.sender variable), and execute the function.
  • smart contract administration system no can not sign the function call.
  • the function can be otherwise called at the target contract.
  • the admin system e.g., admin contract
  • the admin system can emit blockchain events upon successful or failed calls (or transaction receipt) to all or a subset of the admin system’s functions. This event trail can enable the admin system’s activities to be auditable and traceable.
  • configuration S210, consensus determination S220, and function execution S230 performed by smart contract administration system no is logged by smart contract administration system 110 and used to generate auditing information.
  • events can be generated and provided for one or more processes performed by the method 200.
  • Fig. 4 is a representation of proposal and voting, in accordance with various embodiments.
  • an example of consensus determination for a given function provided by a target contract is shown in Fig. 4.
  • configuring access control S210 can include configuring consensus-based access control at the smart contract administration system no.
  • Consensus-based access control can be configured for one or more target smart contracts (e.g., 151-153).
  • the target smart contracts can be executed by the same blockchain, or executed by a plurality of blockchains.
  • Target smart contracts can implement one or more functions, and consensuses-based access control can be configured for any smart contract function.
  • participant system 121 and participant system 122 correspond to eligible voters for a function call of target.fooQ provided by target contract 151, and participant system 121 corresponds to an ineligible voter for the function call of target.fooQ.
  • the smart contract administration system no includes a configuration that a required number of votes for the function call target.fooQ is a threshold number equivalent to 2 votes.
  • the participant system 121 proposes a contract call for the function call of target.fooQ S221, which is sent to the smart contract administration system no.
  • the participant system 122 sends a vote for the function call S222 to the smart contract administration system 110, which is then accepted by the smart contract administration system 110.
  • the participant system 123 also sends a vote for the function call S222 to the smart contract administration system 110, which is then rejected by the smart contract administration system 110.
  • the participant system 121 sends a vote for the function call S222 to the smart contract administration system no, which is then accepted by the smart contract administration system 110.
  • the participant system 121 sends a request to execute the function call of target.fooQ to the smart contract administration system 110, which is then approved by the smart contract administration system 110.
  • the smart contract administration system no then invokes the function call of target.fooQ to the target contract 151, which in turn executes the foo() function.
  • Fig. 5 is a schematic representation of an example of proposal, voting, and voting execution, in accordance with various embodiments.
  • the smart contract administration system 110 is assigned to at least one role of the target smart contract as a participant (e.g., by using a smart contract address of smart contract administration system no, by using a signing public key of smart contract administration system no, etc.).
  • smart contract administration system 110 can automatically execute target smart contract functions that are assigned the admin system’s role at the target smart contract, such as, for example, executing a function periodically, in accordance with rules, in response to a request, in response to one or more triggers, or at any other suitable time.
  • the smart contract administration system no generates a configuration transaction (e.g., by specifying configuration information for at least one smart contract function).
  • a configuration transaction e.g., by specifying configuration information for at least one smart contract function.
  • One or more of user devices e.g., one or more of a participant system corresponding to 121-123 sign the configuration transaction S502.
  • the admin smart contract (e.g., the admin smart contract 112 that is on- chain, also referred to as “first smart contract” further below in Fig. 6) verifies the signature S504.
  • the admin smart contract verifies that the user is an administrator based on the user address S506.
  • the admin smart contract then updates configurations S508.
  • the admin smart contract modifies a particular configuration of a particular smart contract (e.g., the target smart contract), the modifying including one or more of changing authorized addresses, a minimum number of authorized addresses that signatures are needed from, the target smart contract, or the function of the target smart contract.
  • the admin smart contract emits a blockchain event S510 indicating that the configuration was updated.
  • the admin smart contract address is assigned to the target smart contract function’s role S211 (e.g., as part of configuring the role of the target smart contract) in some implementations.
  • the smart contract administration system no generates an unsigned proposal transaction S512 as further shown in Fig. 5.
  • One or more of user devices e.g., one or more of a participant system corresponding to 121- 123) sign the proposal transaction S514.
  • the admin smart contract (e.g., the admin smart contract 112) verifies the signature S516. Next, the admin smart contract verifies that the user is an approver for the given type of contract call based on user address S518. The admin smart contract then adds the proposal transaction S520. The admin smart contract emits a blockchain event S522 indicating that the proposal transaction was added.
  • determining consensus for function execution can include determining whether a smart contract function can be executed. In an implementation, consensus is determined individually for each function. Determining consensus can include proposing function execution as discussed above, voting for a proposed function execution, and determining if a required number of eligible votes has been received, which is discussed further below.
  • the smart contract administration system no generates an unsigned approval transaction for proposal S220.
  • One or more of user devices e.g., one or more of a participant system corresponding to 121-123 sign the approval transaction S524.
  • the admin smart contract (e.g., the admin smart contract 112) verifies the signature S526. Next, the admin smart contract verifies that the user is an approver for the proposal S528. The admin smart contract then adds the approval to the proposal S530. The admin smart contract emits a blockchain event S532 indicating that the approval was added to the proposal.
  • the smart contract administration system no generates an unsigned execute transaction for proposal S534.
  • One or more of user devices e.g., one or more of a participant system corresponding to 121-123) sign the execute transaction S536.
  • the admin smart contract e.g., the admin smart contract 112 verifies the signature S538.
  • the admin smart contract verifies that the user is an approver for the proposal S528.
  • the admin smart contract verifies that a minimum number of approvals met for proposal (e.g., whether a required number of eligible votes has been received) S223.
  • the admin smart contract verifies that the target contract is a smart contract S540.
  • the admin smart contract generates a function signature for the target contract S230.
  • the admin smart contract determines a function selector for the target contract.
  • the target contract in an embodiment, verifies the admin smart contract S544.
  • the target contract executes the function S546.
  • the admin smart contract emits a blockchain event S548 indicating that the function has been executed.
  • Variants of the method can include: deploying a first smart contract to a blockchain network, wherein the first smart contract is configured to execute a first smart contract function when a set of execution conditions, associated with the first smart contract function, are met; orchestrating generation of signed blockchain messages to call the admin smart contract function; and optionally orchestrating signed blockchain message transmission to the blockchain, wherein the first smart contract receives the set of signed blockchain messages, verifies that the set of signed blockchain messages satisfy the execution conditions associated with the first smart contract function, and executes the first smart contract function (e.g., via an on-chain transaction) when the associated execution conditions are satisfied.
  • the first smart contract receives the set of signed blockchain messages, verifies that the set of signed blockchain messages satisfy the execution conditions associated with the first smart contract function, and executes the first smart contract function (e.g., via an on-chain transaction) when the associated execution conditions are satisfied.
  • the first smart contract function is preferably an invocation of a target smart contract function of another smart contract on the blockchain, but can alternatively be an autogenous function (e.g., to change the administrators of the first contract) or other function.
  • the execution conditions can include: receiving a threshold number of signed blockchain messages (e.g., that identify the first smart contract function) from a set of authorized blockchain addresses (e.g., authorized for the first smart contract function) and/or other conditions.
  • Orchestrating generation of signed blockchain messages to call the admin smart contract function can include: generating unsigned blockchain messages calling the admin smart contract function (e.g., for the authorized addresses) and sending the unsigned messages to the users associated with authorized addresses (authorized users), and optionally unauthorized users, for signature with the users’ respective private key(s) associated with the authorized addresses (e.g., wherein the users can access the unsigned messages using user credentials, multifactor authentication, and/or other security or authentication methods); notifying the authorized users to generate and/ or sign blockchain messages calling the admin smart contract function; or otherwise orchestrating signed blockchain message generation.
  • unsigned blockchain messages calling the admin smart contract function (e.g., for the authorized addresses) and sending the unsigned messages to the users associated with authorized addresses (authorized users), and optionally unauthorized users, for signature with the users’ respective private key(s) associated with the authorized addresses (e.g., wherein the users can access the unsigned messages using user credentials, multifactor authentication, and/or other security or authentication methods); notifying the authorized users to generate and/ or sign blockchain
  • Orchestrating signed blockchain message transmission to the blockchain can include: notifying the users to broadcast the signed blockchain messages to the blockchain; aggregating the signed blockchain messages off-chain, then broadcasting the aggregated signed blockchain messages to the blockchain; and/or otherwise orchestrating message transmission.
  • First smart contract processing of the signed blockchain messages, target smart contract function calling, and target smart contract function execution are preferably atomic (e.g., within a single mined block), but can alternatively be distributed across multiple blocks.
  • Target smart contract function execution e.g., verifying that the first smart contract is an authorized caller or address, verifying that sufficient gas or processing fees have been paid, etc.
  • Fig. 6 is a schematic representation of an example 6oo of the method, in accordance with various embodiments.
  • the method 6oo can include one or more of: deploying a first smart contract to a blockchain network S6io, wherein the first smart contract is stored and executed on the blockchain network, and wherein the first smart contract is configured to: aggregate a threshold number of signed blockchain transactions from authorized blockchain addresses associated with a function of a target smart contract S620 (e.g., by receiving a set of signed blockchain transactions calling a function of a target smart contract from a set of blockchain addresses S630; and verifying that each blockchain address of the set of authorized blockchain addresses is authorized to make the call S640); and calling the function of the target smart contract, using an on-chain transaction, when a number of signed blockchain transactions from authorized blockchain addresses calling the function satisfies a threshold number S650.
  • each module e.g., admin smart contract function
  • each module can control a functionality of a target smart contract (e.g., different or the same target smart contract functionality) when signed transactions are received from a threshold number of authorized blockchain addresses from the set of authorized blockchain addresses.
  • each module includes a different configuration related to a particular threshold number to enable execution of a particular function.
  • a first module includes a first configuration comprising a first threshold corresponding to an unanimous vote count based on the authorized blockchain addresses from the set of authorized blockchain addresses (e.g., N signed messages required from the N blockchain addresses authorized for the module), and a second module includes a second configuration comprising a second threshold corresponding to a different number than the unanimous vote (e.g., less than M signed messages required from the M blockchain addresses authorized for the module).
  • the first smart contract controls multiple target smart contracts.
  • the method 6oo further includes: detecting, at a node, a blockchain event associated with the function of the target smart contract; generating a signed blockchain transaction calling a function of the target smart contract, where the signed blockchain transaction is signed with a private key associated with a blockchain address; and broadcasting, by the node, the signed blockchain transaction to the blockchain network.
  • the method 6oo also includes: receiving, by the first smart contract, a signed proposed transaction, the signed proposed transaction including a function call and associated with a first user; and verifying, using the set of authorized blockchain addresses, a blockchain address of a user associated with the signed proposed transaction.
  • the method 6oo includes: emitting a blockchain event indicating an invitation to vote to approve the signed proposed transaction, the blockchain event being received by at least one different blockchain address corresponding to a different user than the first user; receiving, by the first smart contract, an approval transaction to approve the signed proposed transaction, the approval transaction associated with a different blockchain address and the different user, the different user generating and signing the approval transaction; verifying, by the first smart contract, the approval transaction associated with the different blockchain address, the verifying comprising verifying that the different blockchain address associated with the different user is authorized to make the function call, where verifying the approval transaction further comprises: verifying, by the first smart contract, that a first configuration specified in the approval transaction matches a second configuration included in the signed proposed transaction.
  • the method 6oo also includes: generating, by the first smart contract, a blockchain transaction calling a function of the target smart contract; and broadcasting a blockchain transaction to the blockchain network for executing the target smart contract, where executing the target smart contract occurs in an atomic manner within a same block of the blockchain network.
  • the method is performed using a first smart contract including a plurality of modules (e.g., admin smart contract functions), wherein each module is associated with a different configuration.
  • Each configuration can include: a set of authorized blockchain addresses, a threshold number of signed transactions required to execute the respective module, a target smart contract associated with the module, a target smart contract function (e.g., function signature of said function) associated with the module, execution logic (e.g., execution approval logic, such as proposal required before approval is possible; a cancellation period must expire before the module functionality can be executed; etc.), and/ or other parameters.
  • modules e.g., admin smart contract functions
  • Each configuration can include: a set of authorized blockchain addresses, a threshold number of signed transactions required to execute the respective module, a target smart contract associated with the module, a target smart contract function (e.g., function signature of said function) associated with the module, execution logic (e.g., execution approval logic, such as proposal required before approval is possible; a cancellation period must expire before the module functionality
  • the first smart contract can control multiple target smart contracts, or control a single target smart contract.
  • the first smart contract can include different modules for different target smart contracts, different modules for different functions of different target smart contracts, a common module for similar functions of different target smart contracts (e.g., wherein the target smart contract can be identified by the signed transactions calling the module, such as by using a hash of the target smart contract address), and/or otherwise control different target smart contracts.
  • the method can include: at a module of the first smart contract, receiving at least the threshold number of signed transactions from blockchain addresses within the set of authorized blockchain addresses for the module; and executing a function of a target smart contract associated with the module when at least the threshold number of signed transactions is received.
  • the signed transaction can: identify the module (e.g., by a function signature, function hash, etc.), include values for arguments of the function of the target smart contract (e.g., wherein the module uses the values when executing the function), and/ or other information.
  • the method discussed above can be repeated by other modules of the first smart contract, wherein the other modules are associated with different sets of authorized blockchain addresses, different threshold numbers of signed transactions required to execute the second module, and optionally functions for different target smart contracts.
  • the module discussed above can include: a proposal configuration including a first set of authorized blockchain addresses to propose module execution and a first threshold number of signed transactions required to propose module execution; and an authorization configuration including a second set of authorized blockchain addresses to authorize module execution and a second threshold number of signed transactions required to authorize module execution.
  • proposal configuration satisfaction is required to propose module execution
  • authorization configuration satisfaction is required to authorize module execution
  • the function of the target smart contract is executed only after module execution is authorized.
  • the configuration for a given module can be changed by another module (e.g., using a similar execution approval mechanism or different execution approval mechanism), the module itself, or otherwise changed.
  • the method can optionally further include: at a second module of the plurality of modules, receiving at least a second threshold number of secondary signed transactions from a set of authorized blockchain addresses for the second module, wherein the secondary signed transactions are associated with new configurations for the first module; and changing the configuration for the module when at least the second threshold number of secondary signed transactions is received.
  • the method can be otherwise performed.
  • Embodiments of the system and/or method can include every combination and permutation of the various system components and the various method processes, where one or more instances of the method and/or processes described herein can be performed asynchronously (e.g., sequentially), concurrently (e.g., in parallel), or in any other suitable order by and/ or using one or more instances of the systems, elements, and/or entities described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour au moins fournir une commande d'accès pour l'exécution de fonctions de contrat intelligent (procédés) par l'intermédiaire de mécanismes de consensus. Un premier contrat intelligent est stocké sur un réseau à chaîne de blocs. Pendant l'exécution, le premier contrat intelligent exécute des opérations qui consistent à: agréger un nombre seuil de transactions de chaîne de blocs signées à partir d'adresses de chaîne de blocs autorisées, recevoir un ensemble de transactions de chaîne de blocs signées appelant une fonction d'un contrat intelligent cible à partir d'un ensemble d'adresses de chaîne de blocs, vérifier que chaque adresse de chaîne de blocs de l'ensemble d'adresses de chaîne de blocs autorisées est autorisée à effectuer l'appel, et appeler la fonction du contrat intelligent cible lorsqu'un certain nombre de transactions de chaîne de blocs signées appelant la fonction dépasse un nombre seuil.
EP21859060.2A 2020-08-19 2021-08-18 Systèmes et procédés de commande d'accès basée sur consensus pour des fonctions de contrat intelligent Pending EP4200780A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202063067533P 2020-08-19 2020-08-19
US17/331,114 US20210374731A1 (en) 2020-05-26 2021-05-26 Systems and methods for consensus-based access control for smart contract functions
PCT/US2021/046506 WO2022040315A1 (fr) 2020-08-19 2021-08-18 Systèmes et procédés de commande d'accès basée sur consensus pour des fonctions de contrat intelligent

Publications (1)

Publication Number Publication Date
EP4200780A1 true EP4200780A1 (fr) 2023-06-28

Family

ID=80350540

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21859060.2A Pending EP4200780A1 (fr) 2020-08-19 2021-08-18 Systèmes et procédés de commande d'accès basée sur consensus pour des fonctions de contrat intelligent

Country Status (2)

Country Link
EP (1) EP4200780A1 (fr)
WO (1) WO2022040315A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11429960B2 (en) * 2017-05-24 2022-08-30 Nxm Labs, Inc. Network configuration management for networked client devices using a distributed ledger service
US20190050855A1 (en) * 2017-07-24 2019-02-14 William Martino Blockchain-based systems, methods, and apparatus for securing access to information stores
US20200097950A1 (en) * 2018-09-20 2020-03-26 Ca, Inc. Privileged entity consensus for digital asset creation

Also Published As

Publication number Publication date
WO2022040315A1 (fr) 2022-02-24

Similar Documents

Publication Publication Date Title
CN110380858B (zh) 用于处理区块链的游戏共识协议的方法和系统
CN111144881B (zh) 对资产转移数据的选择性访问
CN111164935B (zh) 在基于区块链的私有交易中提供隐私和安全保护的系统和方法
US10985907B2 (en) Identifying faults in a blockchain ordering service
US20200410461A1 (en) Sharded Permissioned Distributed Ledgers
US11170092B1 (en) Document authentication certification with blockchain and distributed ledger techniques
US11296864B2 (en) Identifying faults in a blockchain ordering service
US20210119807A1 (en) Blockchain account migration
AU2020414467B2 (en) Partially-ordered blockchain
CN111797159A (zh) 数据库中的信息管理和访问控制
CN111260398A (zh) 一种广告投放控制方法、装置、电子设备及存储介质
CN110674128B (zh) 区块链的链上治理
EP4216077A1 (fr) Procédé et appareils basés sur un réseau à chaîne de blocs pour le traitement de données, et dispositif informatique
KR20070114801A (ko) 컴퓨터 상태 모니터링 및 지원
CN112868210A (zh) 区块链时间戳协议
CN111241196B (zh) 广告频次控制方法及系统
US11057188B2 (en) Database service token
US11757884B2 (en) Method and system for controlling the release of a resource
US20210374731A1 (en) Systems and methods for consensus-based access control for smart contract functions
CN111600709B (zh) 可验证随机数的生成方法和装置
US20210320797A1 (en) Prevention of majority attacks
CN110807209A (zh) 一种数据处理方法、设备及存储介质
US20130268764A1 (en) Data event authentication and verification system
CN113438082A (zh) 数据库访问方法、装置、设备和存储介质
CN111369277A (zh) 基于区块链的广告数据处理方法、装置、设备及可读介质

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221222

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230725

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)