WO2024011917A1 - Modèle délégué pour transactions de chaîne de blocs - Google Patents

Modèle délégué pour transactions de chaîne de blocs Download PDF

Info

Publication number
WO2024011917A1
WO2024011917A1 PCT/CN2023/078548 CN2023078548W WO2024011917A1 WO 2024011917 A1 WO2024011917 A1 WO 2024011917A1 CN 2023078548 W CN2023078548 W CN 2023078548W WO 2024011917 A1 WO2024011917 A1 WO 2024011917A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
transfer
delegate
custodian
tokens
Prior art date
Application number
PCT/CN2023/078548
Other languages
English (en)
Inventor
Ming Zhuang WEI
Xia YONG
Original Assignee
Hsbc Software Development (Guangdong) Limited
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 Hsbc Software Development (Guangdong) Limited filed Critical Hsbc Software Development (Guangdong) Limited
Publication of WO2024011917A1 publication Critical patent/WO2024011917A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the invention relates to transaction processing in distributed ledger systems, for example blockchain systems.
  • Blockchain systems are widely used for transactions of digital assets, such as cryptocurrency and non-fungible tokens.
  • a variety of transaction processing systems, e-wallet systems and the like have arisen to support increasing activity and transaction volumes and support users in managing their digital assets and transactions.
  • a transaction processing system may act as a custodian for asset tokens owned by a user and allow the user to perform transactions.
  • a transaction processing system may act as a custodian for asset tokens owned by a user and allow the user to perform transactions.
  • Such systems can add complexity, for example in moving asset tokens into a service provider’s custody, which requires additional operations. This additional management overhead is exacerbated by the fact that blockchain transactions are generally very slow and computationally expensive compared to conventional centralised transaction processing architectures.
  • the invention seeks to provide improvements to existing transaction processing approaches. Aspects of the invention are set out in the independent claims. Certain preferred features are set out in the dependent claims.
  • a blockchain transaction system for transferring blockchain tokens from source addresses to custodian entities, provided on a blockchain that implements one or more token smart contracts for managing one or more token types, the system comprising:
  • a delegate smart contract implemented on the blockchain identified by a delegate address, and comprising one or more delegate transfer functions for transferring tokens from a source address to custodian entities;
  • each custody smart contract corresponding to a custodian entity and identified by a custodian address;
  • the delegate smart contract is configured to process, using a delegate transfer function, a plurality of transfer requests to transfer custody of tokens of the given token type from a source address associated with a token holder to respective different custodian entities specified by respective custodian addresses;
  • the plurality of transfers are performed in accordance with an approval configured at the token smart contract associated with the given token type, the approval granting token transfer approval by the source address to the delegate address associated with the delegate smart contract.
  • the plurality of transfers are preferably performed in accordance with the same approval, or more specifically in accordance with an approval configured by the token holder in a single approval operation, such that the token holder performs a single approval at the token contract and the multiple transfers are then performed based on the single approval without requiring separate approvals for each custodian address targeted by a transfer.
  • a token transfer approval may also be referred to as a “spending approval” , and grants to a blockchain address /identity permission to transfer ( “spend” ) tokens of a token holder (identified by a source address) on behalf of the token holder, for example for a maximum token value (an “allowance” ) for fungible tokens or one or more specific identified unitary tokens for non-fungible tokens.
  • the system is configured to process, by the token smart contract for the given token type, an approval request for the given token type, the approval request specifying the source address of the token holder and the delegate address for the delegate smart contract as the approved address.
  • the delegate smart contract is preferably configured to process a plurality of requests to transfer custody of tokens of a second token type from the source address to respective custodian entities associated with respective custodian addresses based on a second token transfer approval granted to the delegate address for the delegate smart contract by the source address.
  • the second approval may be processed by a token contract for the second token type, in the manner set out above.
  • The, or each, token transfer approval preferably specifies an approved token quantity (e.g. for a value token) or one or more approved token identifiers (for a unitary token type) .
  • the delegate transfer function is configured, for each transfer, to invoke a transfer function of the token smart contract for the given token type to perform the transfer to the respective custodian address.
  • the tokens being transferred may comprise one or more of: a fungible or value token, wherein a transfer of a value or fungible token is associated with a value quantity of the token to be transferred; a non-fungible or unitary token, wherein a transfer of a non-fungible or unitary token is associated with a token identifier of a token to be transferred; and a multi-token bundle comprising a plurality of fungible and/or non-fungible tokens.
  • any reference herein to tokens may include value tokens /fungible tokens, where token transfers preferably involve transferring a certain amount of token value, and/or unitary tokens /non-fungible tokens, where token transfers may involve transferring one or more distinct unitary tokens (e.g. identified by token identifiers) .
  • Tokens may also comprise multi-token bundles of value and/or unitary tokens. Tokens of any such type may also be referred to as token assets, and a transfer of one or more token asset (s) may involve any such token types.
  • each transfer request may specify a plurality of tokens or token values to be transferred to a respective custodian address in a batch transfer.
  • the delegate smart contract is then preferably configured to invoke a batch transfer function of the token smart contract for the token bundle.
  • the multi-token bundle may be an ERC1155 token bundle (e.g. managed by an ERC1155 compliant token contract) .
  • the delegate smart contract comprises a plurality of delegate transfer functions, each supporting transfer of a respective class of tokens.
  • One or more of the delegate transfer functions may each process transfers of tokens of a respective token standard.
  • the delegate contract may include respective delegate transfer functions for one or more of (or each of) : ERC20 compatible tokens; ERC721 compatible tokens; ERC1155 compatible token bundles; Ether tokens (i.e. Ether cryptocurrency values) .
  • the delegate transfer function is configured, for each transfer to a respective custodian address, to query the custodian smart contract at the custodian address to determine whether the custodian smart contract can accept the transfer, and to perform the transfer in dependence on the determination.
  • the custodian smart contract is preferably configured to determine whether the transfer can be accepted based on one or more of: the token type, a transfer value; and/or the source address for the transfer; and to return a query response indicating the determination.
  • the custodian smart contract may comprise one or more acceptance functions, each acceptance function configured to: receive a query specifying one or more parameters including one or more of: a source address, a token contract address, and a transfer value; determine whether the transfer can be accepted based on the one or more parameters; and return a determination result.
  • Each custodian contract may include respective acceptance functions for one or more of: ERC20 compatible tokens; ERC721 compatible tokens; ERC1155 compatible token bundles; and Ether tokens.
  • the delegate transfer function is preferably configured to check that the custodian address specified for a transfer corresponds to a smart contract on the blockchain and/or corresponds to one of a set of predetermined custodian contracts (or custodian addresses) , and to perform the transfer to the custodian address only in response to a positive determination.
  • Also disclosed is a method of performing transactions comprising:
  • the one or more token assets may comprise one or more of: at least one token amount of a value token or fungible token; at least one unitary or non-fungible token; a bundle of value tokens and/or unitary tokens.
  • the request specifies the source address of a token holder of the token assets and a custodian address of the custodian entity, and further specifies one or more token amounts and/or token identifiers.
  • the querying preferably comprises invoking a function of the custody smart contract, the function configured to determine if the transfer can be accepted.
  • the one or more token assets are transferred in accordance with a transfer allowance granted to the delegate smart contract by the source address, the transfer allowance optionally configured at the token contract by the token holder.
  • the method may comprise receiving and processing multiple requests to transfer token assets associated with the token contract to a plurality of custodian entities based on the transfer allowance.
  • the method in this example may be configured to perform the steps performed by a system set out previously.
  • the disclosure also encompasses a system having means, optionally comprising one or more processors with associated memory, for performing any method as set out herein, and one or more computer programs or computer readable media comprising software code which when executed in a data processing system causes the data processing system to implement a system as set out herein or to perform any method as set herein.
  • Figure 1 illustrates transfer of blockchain tokens to a custodian addresses
  • Figures 2A-2B illustrate blockchain transactions for transferring tokens to targets on a blockchain
  • FIGS 2C-2D illustrate transactions mediated by a delegate smart contract
  • Figures 3A-3B illustrate processing steps for transactions mediated by a delegate smart contract
  • Figure 4 illustrates implementation details of a delegate custody transaction model
  • Figure 5 illustrates a process for transferring a token to a custody address by the delegate smart contract
  • Figure 6 illustrates a system implementing the described delegate transaction model
  • Figure 7 illustrates a processing device for implementing described techniques.
  • Embodiments of the invention provide a system for efficient management of blockchain transactions.
  • the system can reduce the communication overhead when transferring blockchain tokens to custodian entities.
  • the tokens may be value tokens such as electronic currency tokens or other tokens representing digital or real-world assets, such as non-fungible tokens.
  • the following embodiments will be described in the context of the Ethereum blockchain. However, the described approach can be applied to other types of blockchain and distributed ledger systems.
  • Figure 1 illustrates by way of example a scenario in which tokens are to be transferred to various custodian addresses by way of blockchain transactions.
  • a user 110 is associated with a user address or identity 112 on Ethereum blockchain 100.
  • the user owns a set of tokens, including Token A 120, Token B 122 and Token C 124, which are associated with the user’s address 112 on the blockchain, identifying the user as the owner or holder of those tokens.
  • the user wishes to transfer these tokens 120, 122, 124 to custodian entitities 130, 136, represented in the blockchain by a custodian addresses 132 and 134.
  • the custodian entity could, for example, be a cryptocurrency service provider that can hold, buy and sell cryptocurrency (in the form of tokens) for a user, such as a cryptocurrency investment platform or the like.
  • Tokens on the blockchain are managed by one or more token smart contracts, with different token smart contracts managing different token types.
  • Each token smart contract is identified by a smart contract address.
  • Transfers of tokens are effected by invoking transfer functions of the relevant token contracts by the user address of the token holder.
  • a user may also call an “approve” function to set a spending allowance that permits another address (the approved address) to perform transactions to “spend” (transfer) tokens held by the user, up to a certain approved value (the allowance) .
  • One approach for transferring tokens to custodian addresses involves using a custodian smart contract to manage the transfers.
  • users have to first approve the custodian smart contract for each token to be transferred for each custodian so that the custodian smart contract for each custodian is able to “spend” the token (i.e. transfer it on behalf of the user) .
  • users may send a second transaction for each token to ask the custodian to send the token to the custodian address.
  • Figure 2A illustrates a single transaction, in which a user calls an approval function (step 1) of the token smart contract of a particular token, specifying the custodian address of the custodian entity 132 and a token amount that indicates the allowance for that custodian address, i.e. the amount of the user’s tokens the custodian may “spend” on the user’s behalf.
  • This may, for example, be the “approve” function of an ERC20 token contract or similar.
  • the user can then instruct the custodian (by any suitable means, e.g. a web interface provided by the custodian) to transfer a certain value of the token to its custodian address.
  • step 3 the custodian calls a transfer function of the token contract to make the transfer.
  • This may, for example, be the “transferFrom” function of an ERC20 token contract or similar, which allows specification of the source (in this case the address 112 for user 110) and the transfer amount. As long as the transfer amount is less than or equal to the current allowance of the custodian, the transfer will be successful based on the prior approval.
  • the instruction to transfer in step 2 may of course be implicit or given in advance rather than on a transaction-by-transaction basis (e.g. this could be a regular payment transaction) , as long as the transfer amount is within the current allowance.
  • the token contract 204 reduces the allowance for the custodian 130 (or specifically, the custody address 132) by the amount of the transfer, as set by the initial approval. If a transfer exceeds the current allowance it will fail, at which point the user will need to make a further call to the approve function to set a new allowance.
  • This approach can be used, for example, for transferring tokens according in the ERC20 or ERC721 token standard, or the ERC1155 token standard, or any other token type that allows a token owner to set a spending allowance for another entity.
  • the allowance and/or transfer amounts may always (implicitly or explicitly) equal one, and allowances/transfers may specify particular token identifiers (token ID) to which an approval/transfer relates.
  • FIG. 2B shows a user transferring tokens of two types (Token A and Token B) to two target custodians, Target A 132a and Target B 132b.
  • each token transfer involves two stages:
  • Stage 1 –Approval –the user 110 approves the custodian address to spend a given quantity of token X by calling the approve function of the ERC20 smart contract for token X with the custodian address and quantity as parameters –see operations 1a, 1b, 1c and 1d in Figure 2B
  • Stage 2 –Transfer –the custodian performs a transfer operation for the given quantity of token X from the user address to the custodian address, based on the previous approval, e.g. by calling the transferFrom function of the ERC20 smart contract for token X, with the user address 112, custodian address 132a/132b and quantity as parameters –see operations 2a, 2b, 2c and 2d in Figure 2A These steps are repeated for each of the tokens transferred, using the respective smart contracts for those token types. This approach thus involves the user having to approve each token type separately for each target custodian entity.
  • Embodiments of the invention provide a delegate transaction model based on a delegate smart contract that enables transfers of different types of tokens to various target custodians to be managed by a single central entity. This is illustrated in Figure 2C.
  • the user transfers tokens to custody addresses through a delegate smart contract 200 acting as an intermediary.
  • the user approves the delegate contract once for each token type (step 1) .
  • the user requests the delegate contract to transfer on their behalf (step 2) .
  • the delegate contract performs the transfer on behalf of the user (step 3) . Since the approval is given by the user to the delegate contract, the delegate contract can make any number of transfers to different targets (e.g. target A and target B) without requiring separate approvals, as long as the transfers are within the configured allowance.
  • the described approach can thus provide a delegate or proxy model of conventional token types such as ERC20 and ERC721.
  • multi-token smart contract may be based on the ERC1155 multi-token standard, which supports both fungible and non-fungible tokens in accordance with the ERC20 and ERC721 token standards.
  • ERC1155 multi-token standard which supports both fungible and non-fungible tokens in accordance with the ERC20 and ERC721 token standards.
  • Figure 2D An example is illustrated in Figure 2D.
  • the initial approval step involves approving multiple tokens (Token A and Token B) using the ERC1155 batch approval function.
  • the approval approves a specific token quantity as discussed above whereas for non-fungible tokens (unitary tokens) , the approval is unitary (e.g. the approval quantity is exactly 1) .
  • the approval can in that case relate to a specific token (identified by a token ID) or to all tokens of that type held by the user.
  • the user can then instruct the delegate smart contract 200 to transfer multiple tokens of the supported types in a single operation.
  • the delegate contract performs the transfer using a batch transfer function in accordance with the ERC1155 standard. Note that, as in the previous example, transfers can be made to various targets such as Target A and Target B without separate approvals for the different targets.
  • any combination of supported token types can be transferred to any target, as long as the transfers specified in the ERC1155 transaction do not exceed the current approved limit for each token involved in the transaction (which may be the limit set in the initial approval or as subsequently modified by other transactions) . This approach can thus significantly simplify transaction processing and reduce the number of blockchain operations (and hence blockchain transaction volume) .
  • Multi-token bundles can include multiple fungible tokens (e.g. ERC20 tokens) and/or multiple non-fungible tokens (e.g. ERC721 tokens) , in any combination.
  • ERC20 tokens e.g. ERC20 tokens
  • non-fungible tokens e.g. ERC721 tokens
  • Figure 3A illustrates a process flow for using the delegate contract to transfer tokens to multiple targets.
  • step 302 the user invokes an approval function of the token contract for Token A specifying the address of the delegate smart contract ( “DC” ) as the approved entity and the approval amount (allowance) .
  • the user repeats this in step 304 for Token B (and indeed may repeat this step for any other tokens) .
  • step 306 the user instructs the delegate contract to make transfers to various targets on the user’s behalf, specifying the tokens, amounts and transfer targets.
  • the user may use a transaction user interface to request the transactions. The user may request multiple transactions at the same time or at different times. In this example, the user specifies transfers of both token types A and B to Target B and of token type B to Target A.
  • step 310 the Delegate Contract invokes a transfer of Token A in the specified amount at the token contract for Token A, which then performs the token transfer in the specified amount to Target B (step 312) .
  • the Delegate Contract also invokes a transfer of Token B in the specified amount at the token contract for Token B (step 314) , which performs the token transfer in the specified amount to Target B (step 316) .
  • a transfer of token B to Target A is performed in steps 318-320. The same steps may be performed to perform transfers to other targets. Since the approval was granted to the delegate contract, no further approvals from the user are needed to perform such additional transfers.
  • the above process can be performed in the same way for multi-token batch transfers e.g. in accordance with the ERC1155 multi-token standard as illustrated in Figure 3B.
  • the transfer involves the user calling the batch approval function of the multi-token contract, specifying the delegate contract ( “DC” ) as the approved entity and the approved tokens and corresponding token amounts for each token (step 320) .
  • the user then instructs the Delegate Contract to perform one or more batch transfers (322) . These are then executed by the Delegate Contract.
  • the Delegate Contract invokes a batch transfer at the multi-token contract to transfer a set of token with specified transfer amounts (for fungible tokens) to target B in step 324 (executed by the multi-token contract in a batch transfer in step 326) .
  • the Delegate Contract performs a similar transfer to Target A in steps 328-330. As before, only the single approval operation 320 is needed regardless of the number of targets involved.
  • the delegate contract may support various token contract types, including ERC20 and ERC721 token types and ERC1155 multi-token contracts.
  • the delegate contract may also include other token types, including Ether.
  • Figure 4 illustrates elements of an example implementation of the above concepts on a blockchain 400.
  • the blockchain is typically the Ethereum blockchain, but the principles may be adapted to any suitable blockchain implementation.
  • the blockchain 400 includes any number of user addresses 402 corresponding to users of the blockchain that may hold tokens.
  • the tokens are managed by a set of token contracts 450.
  • the blockchain may simultaneously support a variety of different types of tokens managed by respective token contracts and these may include multi-token contracts (e.g. ERC1155 compatible contracts) .
  • Each token contract 450 includes a token address 452 identifying the token contract and smart contract code (e.g. a set of functions) and data 454.
  • a delegate smart contract 410 e.g. corresponding to smart contract 200 discussed above, here named “DelegateCustody” , implements the delegated transfer functions.
  • a custodian smart contract 430 implements functions associated with a custodian (e.g.
  • custodians are represented by dedicated smart contracts rather than just a custodian address.
  • the custody address 440 in this case is the address of the custodian smart contract.
  • the delegate contract 410 includes a set of “custody” functions for transferring custody of various classes of tokens to a custodian contract 430 identified by a custodian address 440.
  • the contract includes a custodyERC20 function 412 for transferring ERC20 compatible tokens, a custodyERC721 function 414 for transferring ERC721 compatible tokens (typically these are NFTs, non-fungible tokens) and a custodyEther function 416 for transferring Ether cryptocurrency.
  • a “custodyERC1155” function 418 is provided for transferring multi-token bundles in accordance with the ERC1155 multi-token standard.
  • This function accepts a collection of multiple tokens and associated transfer amounts and transfers the amounts for the specified tokens to the custody address.
  • the multiple tokens in a batch may include multiple tokens of the same type and/or tokens of different types.
  • the token “type” here may correspond to the smart contract responsible for minting the token and processing transactions for the token.
  • a batch could include:
  • the custodian smart contract includes a corresponding set of “accept” functions used to check whether particular token transfers can be accepted by the delegate smart contract, including an “acceptERC20Custody” function 432, “acceptERC721Custody” function 434, “acceptEtherCustody” function 436 and “acceptERC1155BatchCustody” function 438.
  • the custody smart contract may be extended to support any appropriate token types.
  • Support for individual transfer of additional token classes e.g. those not compatible with the identified token standards
  • additional individual custody functions in the delegate smart contract may be added by way of additional individual custody functions in the delegate smart contract together with corresponding accept functions in the custody smart contracts.
  • custodyERC20 (address to, address token, uint amount) public;
  • custodyERC721 (address to, address token, uint tokenId, bytes memory data) public;
  • custodyERC1155 (address to, address token, uint [] calldata tokenIds, uint [] calldata values, bytes calldata data) public;
  • to is the custodian address
  • token is the address of the smart contract that manages the token to be transferred
  • amount is the value amount of the token to be transferred (in the case of value tokens /fungible tokens)
  • tokenId is the identifier of a specific unitary token to be transferred (in the case of a non-fungible token) .
  • arrays “tokenIds” of token identifiers and “values” of transfer values are passed to the function.
  • FIG. 5 illustrates processing performed by the custody transfer functions 412-418 in more detail.
  • the custody transfer function is invoked.
  • the inputs to the delegate transfer functions include the destination custodian address (address of the custody contract) , address of the token smart contract (the contract managing the token or multi-token bundle) , and a transfer amount (for fungible tokens) or token identifier (for non-fungible tokens) .
  • a transfer operation may transfer a specified quantity of the token.
  • the smart contract managing the token in that case manages user balances for the tokens under its control.
  • the token of the particular type is transferred as distinct, indivisible entity.
  • the transfer amount may simply always be one (since there is only a single token of that type in existence) .
  • the managing smart contract transfers ownership of the token between users without maintaining variable user balances.
  • step 504 the function checks whether the transfer destination address corresponds to a custody address associated with a custody smart contract. For example, the function may check the target address for the transfer is on a list of supported custody smart contracts. Alternatively, the function may merely check that the target address is a smart contract. If the check fails, then the process ends, with the transaction failed (514) .
  • step 506 the function checks whether the token address (the contract address of the contract managing the token) associated with the token to be transferred (or token bundle in case of multi-tokens) is a smart contract supporting the token that is deployed on the Ethereum blockchain. Additionally, the function checks in step 508 whether this token transfer is accepted by the custody smart contract (by calling the relevant “accept” function 432-428 of the custody contract 430, as discussed in more detail below) . If both checks succeed, then processing proceeds to step 510. If either check fails, the processing ends, with the transaction failed (514) .
  • the token address the contract address of the contract managing the token
  • the function checks in step 508 whether this token transfer is accepted by the custody smart contract (by calling the relevant “accept” function 432-428 of the custody contract 430, as discussed in more detail below) . If both checks succeed, then processing proceeds to step 510. If either check fails, the processing ends, with the transaction failed (514) .
  • the function calls the transfer function of the smart contract that manages the token to transfer the token in the specified quantity to the custody address and determines (512) whether the transfer was successful. For example, the transfer might fail in case of an insufficient token quantity being available for transfer, or the transfer amount exceeding the amount approved for use by the delegate contract in the approval operation. If the transfer fails, then the process ends with the whole operation failed (514) . If the transfer succeeds, then the operation as a whole succeeds (516) and processing ends.
  • Step 510 involves invoking the relevant external transfer function for the token in question at the token contract managing the token (specified by the “token” parameter provided to the delegate transfer function) , for example the transferFrom function defined by the ERC20 standard for an ERC20 compatible token or similarly the ERC721 transferFrom or safeTransferFrom function for an ERC721 token.
  • the transferFrom function defined by the ERC20 standard for an ERC20 compatible token or similarly the ERC721 transferFrom or safeTransferFrom function for an ERC721 token.
  • step 510 involves calling the safeBatchTransferFrom function in accordance with the ERC1555 multi-token standard. This essentially performs a looped version of safeTransferFrom, in which the process loops over the tokens specified in the “tokenIds” array parameter, performing the necessary transfers in the amounts as specified in the “values” array parameter.
  • safetyBatchTransferFrom is a looped version of “safeTransferFrom” . “safeTransferFrom” does not return anything, and so there is no need to check return values. However, the system may wait for emitted events, or implement the “_afterTokenTransfer” functions which follow the standard of ERC1155.
  • the delegate contract’s transfer functions perform various checks to confirm that the requested transfer is valid and capable of being performed. This includes a check (step 508 in Figure 5) as to whether the token (s) in question can be accepted by the custody contract. In an embodiment, this check is performed by a set of interface functions (identified above and shown in Figure 4 as the “accept” functions) , as outlined in the following pseudocode. These functions (named acceptZZZCustody, where ZZZ is the token type) are used to control acceptance of custody service by the custody smart contract. Different functions are defined for different token standards, and each function returns a Boolean value indicating whether the custody contract can accept the given token type in the specified amount. The “acceptERC1155BatchCustody” variant performs a batched version for use in batched transfers of token bundles. Example definitions are set out below:
  • the “accept” functions may make the determination based on criteria such as thus originating user address ( “client” ) , the transfer amount, the type of token etc. and may use any combination of such criteria. If the specified transfer does not meet the acceptance criteria, a “False” result is returned, resulting in failure of the transaction at the corresponding delegate function in delegate contract 410. Otherwise a “True” result is returned, allowing the transaction to proceed (see step 508 of Figure 5) .
  • While described in relation to the Ethereum blockchain and more particularly certain classes of Ethereum tokens e.g. ERC20, ERC721
  • the described techniques can also be used with other token types and/or other Ethereum Virtual Machine (EVM) based blockchains and other smart contract blockchains.
  • EVM Ethereum Virtual Machine
  • the described process for custody transfer can improve transaction processing efficiency. From the perspective of the client, only a single “approve” operation needs to be performed to allow transfers of tokens to any number of custodian entities.
  • ERC1155 multi-token transfer only a single approval call and a single transfer transaction needs to be performed to transfer multiple tokens, reducing transaction overheads and hence cost (e.g. in terms of computational cost and/or Ether/gas transaction cost) . For example, since each transaction has a metadata envelope, combining transactions can reduce processing cost.
  • this approach improves the likelihood that the transactions in the batch will be performed within a single block period and hence will be included in the same block of the blockchain. This improves transaction throughput and security since the user does not have to wait multiple block periods for completion of the batch transfer (with the potential for the batch transfer being stalled due to delays in processing one or more of the blocks) . This also means that subsequent transactions (e.g. to withdraw /transfer tokens) can proceed immediately.
  • a custodian in the above scenarios may, for example, be a cryptocurrency wallet service, trading service or other cryptocurrency, NFT, or token-based service.
  • Figure 6 illustrates the architecture of a custody system incorporating the delegate smart contract as described above.
  • the custody system includes the blockchain 400, implemented by a set of network-connected blockchain nodes. In the present examples this is the Ethereum blockchain but the invention is not limited thereto.
  • the various smart contracts 602, including token contracts, delegate contract and custody contracts, are deployed on the blockchain at given addresses (corresponding to the token, delegate and custody addresses discussed above) .
  • the delegate smart contract may not be upgradeable to ensure that the contract itself cannot change and can thus be trusted by system users.
  • the delegate and custody smart contracts implement the various functions for token transfer as described above.
  • An enterprise system 608 is responsible for the enterprise's custody business. It includes an enterprise compliance system 610 and an enterprise wallet 612.
  • the enterprise compliance system is responsible for a compliance process, including, for example, anti-money laundering, criminal investigation, and anti-terrorist financing. This module performs inspection to check whether token assets are compliant.
  • the enterprise wallet system 612 supports enterprise-side storage of token assets. Modules that the enterprise wallet system may use include a hard wallet, hardware security module (HSM) cloud service, and/or a multi-party computing (MPC) security service. Hard wallets directly help enterprises and users manage user private keys offline.
  • the HSM cloud service helps enterprises and users to obtain private keys and complete signatures.
  • the MPC security service helps enterprises and users complete transfer transactions after completing the signature of the individual private key in multi-user applications.
  • a mobile app 606 is provided on a user device (e.g. personal computer, smartphone etc) .
  • a user device e.g. personal computer, smartphone etc.
  • transactions require users to approve access to token assets by the delegate contract.
  • ERC20, ERC721, or ERC1155 type tokens they need to be approved before transferring token assets to the custody token contract account, that is, the approval of the contract needs to be done before the transfer.
  • Approval can be managed by the mobile app. After approval, the mobile app can be used to instruct the delegate contract to perform specific transfers in accordance with the prior approvals.
  • Figure 7 illustrates an example of a processing device 700, such as a server, that may be used to implement the described techniques.
  • the processing device may operate as a node of the Ethereum blockchain.
  • the processing device includes one or more processors 704 together with volatile /random access memory 702 for storing temporary data and software code being executed.
  • a network interface 706 is provided for communication with other system components, such as other blockchain nodes, over one or more networks (e.g. Local and/or Wide Area Networks, including the Internet) .
  • Persistent storage 708 persistently stores software and data for performing the described functions of the custody system.
  • the persistent storage also includes blockchain storage 716 for storing a local copy of some or all of the blockchain.
  • the processing device will include other conventional hardware components as known to those skilled in the art, and the components are interconnected by one or more data buses (e.g. a memory bus and I/O bus) .
  • data buses e.g. a memory bus and I/O bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Economics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Est divulgué un système de transaction de chaîne de blocs servant à transférer des jetons de chaîne de blocs depuis des adresses sources vers des entités de garde. Le système est disposé sur une chaîne de blocs qui met en œuvre un ou plusieurs contrats intelligents de jeton afin de gérer un ou plusieurs types de jetons. Le système comprend un contrat intelligent délégué mis en œuvre sur la chaîne de blocs identifié par une adresse déléguée, qui comprend une ou plusieurs fonctions de transfert déléguées en vue de transférer des jetons d'une adresse source vers des entités de garde, et une pluralité de contrats de garde intelligents mis en œuvre sur la chaîne de blocs, chaque contrat de garde intelligent correspondant à une entité de garde et étant identifié par une adresse de garde. Le contrat intelligent délégué est configuré pour traiter, à l'aide d'une fonction de transfert déléguée, une pluralité de demandes de transfert en vue de transférer la garde de jetons du type de jeton donné depuis une adresse source associée à un détenteur de jeton vers différentes entités de garde respectives spécifiées par des adresses de garde respectives. La pluralité de transferts est effectuée conformément à une approbation configurée au niveau du contrat intelligent de jeton associé au type de jeton donné, l'approbation accordant une approbation de transfert de jeton par l'adresse source vers l'adresse déléguée associée au contrat intelligent délégué.
PCT/CN2023/078548 2022-07-11 2023-02-27 Modèle délégué pour transactions de chaîne de blocs WO2024011917A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210814985.6 2022-07-11
CN202210814985.6A CN117422548A (zh) 2022-07-11 2022-07-11 一种关于区块链资产的托管方法

Publications (1)

Publication Number Publication Date
WO2024011917A1 true WO2024011917A1 (fr) 2024-01-18

Family

ID=89527153

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/078548 WO2024011917A1 (fr) 2022-07-11 2023-02-27 Modèle délégué pour transactions de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN117422548A (fr)
WO (1) WO2024011917A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107835076A (zh) * 2016-09-15 2018-03-23 埃森哲环球解决方案有限公司 用于令牌的安全通信及其聚合的方法和系统
US20190385156A1 (en) * 2018-04-27 2019-12-19 Bing Liu Decentralized Crypto Token Swap Platform on Mobile Device Apps
CN113824561A (zh) * 2021-06-18 2021-12-21 泰安北航科技园信息科技有限公司 基于智能合约和可信计算技术的新型跨链系统
CN114730423A (zh) * 2019-11-15 2022-07-08 富士通株式会社 控制方法、控制程序、信息处理装置以及控制系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107835076A (zh) * 2016-09-15 2018-03-23 埃森哲环球解决方案有限公司 用于令牌的安全通信及其聚合的方法和系统
US20190385156A1 (en) * 2018-04-27 2019-12-19 Bing Liu Decentralized Crypto Token Swap Platform on Mobile Device Apps
CN114730423A (zh) * 2019-11-15 2022-07-08 富士通株式会社 控制方法、控制程序、信息处理装置以及控制系统
CN113824561A (zh) * 2021-06-18 2021-12-21 泰安北航科技园信息科技有限公司 基于智能合约和可信计算技术的新型跨链系统

Also Published As

Publication number Publication date
CN117422548A (zh) 2024-01-19

Similar Documents

Publication Publication Date Title
JP7472333B2 (ja) バリデータノードにより提供されるブロックチェーントランザクションをマイニングする方法及びシステム
US11853291B2 (en) Privacy preserving architecture for permissioned blockchains
JP2022520845A (ja) ブロックチェーンネットワークを介した移転を実施するためのコンピュータで実施されるシステムおよび方法
US10614454B1 (en) Remote population and redaction of high security data
JP2016219014A (ja) リソース転送システム
US11392675B2 (en) Request authorization using recipe-based service coordination
US20220191026A1 (en) Self-sovereign data access via bot-chain
US20220156725A1 (en) Cross-chain settlement mechanism
CN111598575A (zh) 业务流程控制方法、装置、电子设备和可读存储介质
Dinh et al. A blueprint for interoperable blockchains
Garcia Bringas et al. BlockChain platforms in financial services: current perspective
US10326833B1 (en) Systems and method for processing request for network resources
CN105978744A (zh) 一种资源分配方法、装置及系统
US11818206B2 (en) Visibility of digital assets at channel level
WO2024011917A1 (fr) Modèle délégué pour transactions de chaîne de blocs
US11983705B1 (en) Bank-driven model for preventing double spending of digital currency transferred between multiple DLT networks using a trusted intermediary
WO2022206209A1 (fr) Gestion d'actifs basée sur une chaîne de blocs
CN111866171B (zh) 报文处理方法、装置、电子设备和介质
AU2022245375A1 (en) Reducing transaction aborts in execute-order-validate blockchain models
GB2530471A (en) Financial switching engine and messaging
CN114579585A (zh) 区块链选择性世界状态数据库
CN113055401A (zh) 一种企业业务的授权处理方法及装置
Pandolfi et al. Interoperability between DLT following a Gateway-based approach: the Case of Ethereum and Hyperledger Fabric
US20200104228A1 (en) Asynchronous self-proving transactions
CN115456802B (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: 23838419

Country of ref document: EP

Kind code of ref document: A1