Choosing blockchain validators

Abstract

Choosing blockchain validators includes providing a blockchain in which computing devices are participant devices that act on behalf of associated blockchain accounts that use the blockchain to transact a first type of assets and a second type of assets. Some computing devices are validating computing devices associated with validating blockchain accounts and run a prescribed validating computer program to take actions that include at least one of: validating blocks, validating transactions, or validating blockchain accounts in a given time period. A validating computing devices receives from a participant device a request for an associated blockchain account to become a validating blockchain account for a given period of time, causing the at least one validating computing device to use a cryptographically fair lottery to determine whether the associated blockchain account corresponding to the particular participant device is selected to become a validating blockchain account in the given period of time.

Description

[0001] CHOOSING BLOCKCHAIN VALIDATORS

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. provisional patent application No. 63 / 718,939 titled "FIAT CHAIN", filed on November 11, 2024, and on U.S. provisional patent application No. 63 / 724,656 titled "THE FIAT CHAIN", filed on November 25, 2024, and on U.S. provisional patent application No. 63 / 724,820 titled "FIAT CHAIN", filed on November 25, 2025, all of which are incorporated by reference herein.

[0004] TECHNICAL FIELD

[0005] This application is directed to the field of cryptography and more particularly to the field of using cryptography in connection with blockchain transactions to provide a public ledger of transactions.

[0006] BACKGROUND OF THE INVENTION

[0007] Digital signatures, blockchains, smart contracts, and tokens are used for cryptographic digital transaction systems.

[0008] Digital Signatures. In a digital system, many transactions are executed by public keys via digital signatures. A digital signature of a message (string) m, relative to a public key PK, is a string proving to anyone that m has been authenticated relative to PK. Such a signature of m is denoted by SIGPK(m . Because only the owner of PK — i.e., the entity or the person knowing PK's secret key — can compute SIGPK(m) on input m, in a context in which PK's owner, 0, is clear, it is possible to identify key PK with 0 and write SIG0(m) instead of SIGPK(m). In some contexts, the message m and / or the public key PK may be directly computable from SIGPK(m). In other cases, m and PK may not be computable from SIGPK(m). For example, it is possible to hash m prior to signing m. That is, SIGPK(H(m)) is equated to SIGPK(m), where H is a hash function. For simplicity, SIGPK(m is shorthand for (m, PK, SIGPK(m)), which makes it immediately clear both the signed message m and the public key PK. Blockchains. In a blockchain, transactions are organized in a sequence of blocks. All users in the system may post transactions of assets on the blockchain. In some cases, users that post transactions of assets on a blockchain may be required to separately provide a portion of the assets to one or more third parties that manage the blockchain and / or that provide validation of blocks on the blockchain. Once posted, all users can read all transactions posted in the blocks of the blockchain, but no one is able to alter the blockchain, the transactions in the blockchain, the order of blocks in the blockchain, or the order of transactions within each block of the blockchain. Users of the blockchain post transactions using a pubic / private key pair of a digital signature scheme where transaction are digitally signed by the users using the private key and may be verified by anyone using the public key. In some cases, one or more users may be anonymous or at least not publicly or widely known so that it is the public key and any account corresponding to the public key that distinguishes different users or at least different accounts of users. Thus, it is the public keys / blockchain accounts that transfer assets with other public keys / blockchain accounts in the blockchain. In some instances, a public key and / or the blockchain account associated with the public key may be referred to as a "wallet". Note that that any observer of a blockchain may examine the contents of the blocks of the blockchain to determine which assets are associated with (owned) by each of the public keys / associated blockchain accounts.

[0009] Blockchains may be permission / ess or permissioned. In a permissionless (also called public or open) blockchain, a new public key typically joins the system as soon as a suitable transaction involving the new public key (e.g., a transfer of assets to the new public key / associated blockchain account) is posted on the blockchain. Also, in a public blockchain, anyone is allowed to become a validator (explained below).

[0010] In a permissioned blockchain, typically new public keys / associated blockchain accounts must be approved to be able to post transactions on the blockchain and validators must be approved, too.

[0011] Smart Contracts. A smart contract is, de facto, a public piece of code, posted on a blockchain, whose capabilities include (a) storing information, (b) owning assets and tokens, (c) receiving inputs and generating outputs, and (d) automatically execute transactions, if some proper conditions are satisfied. One such condition may be the transfer of a particular asset to and / or from a particular public key / associated blockchain account. The execution of a smart contract may require the payment of a fee that depends on the smart contract execution.

[0012] Tokens. Blockchain tokens are a type of asset that may be transferred on the blockchain. Blockchain tokens may use the cryptographic mechanisms of the blockchain to assure authenticity. For example, a token may represent a single indivisible asset that is transacted on the blockchain. Tokens may also represent other kinds of tokenized assets. For example, tokens may be digital representations of fiat currency, what is colloquially referred to as central-bank money. Such representations include stablecoins, tokenized bank deposits, digital dollars, digital euros, and central-bank digital currency.

[0013] Cryptochains. A cryptochain is a blockchain having a native cryptocurrency. When conducting a transaction between a first blockchain account (first public key) and a second account (second public key), some of the native cryptocurrency may be also transferred to one or more third party accounts in connection with the transactions. A given transaction between two accounts may require the transfer of a given amount of the chain's cryptocurrency. Similar transfers of the native cryptocurrency may be required in connection to the execution of a smart contract. In some cases, instead of or in addition to cryptocurrency, a native token may be transferred as a result of the one or more smart contract transactions, but the native token may first be obtained by one or both transacting accounts in exchange for cryptocurrency.

[0014] Validators. Validators, also called verifiers, are responsible to perform a variety of blockchain actions. For example, validators may (a) verify the validity of transactions (e.g., in a transaction transferring n given tokens from a first blockchain account (public key) to another blockchain account (public key), a validator may first verify that the first had at least n tokens, as well enough additional native cryptocurrency that need to be transferred to one or more third parties in connection with the transaction), (b) verify the validity of blocks in the blockchain (i.e., that all the transactions in a given block are valid) , (c) may execute smart contracts and verify that appropriate assets / tokens are transferred in connection with execution of the smart contracts, (d) may propose new blocks for the blockchain, and (e) may add new blocks to the blockchain.

[0015] Consensus. As transactions are posted, it is necessary to grow the blockchain by adding new blocks. The process of adding new blocks to the blockchain is referred to as consensus. Consensus is thus a crucial mechanism in any blockchain, and consensus is provided by the chain's validators (or at least a special class of validators). Note that, for the blockchain to be secure, the majority of the validation power must be in honest hands. A validator may be considered honest if the validator executes and plans to continue executing the official consensus algorithm (mechanism) and is considered dishonest (or malicious) otherwise. There are several types of blockchain consensus mechanisms: in particular, proof-of-work (PoW) and proof-of-stake (PoS). The PoW mechanism is considered relatively expensive and slow. The PoS mechanism is the consensus mechanism most adopted.

[0016] Proof-of-Stake (PoS) Blockchain. A PoS blockchain is a blockchain where a blockchain account needs to have at least a given amount of the native cryptocurrency of the blockchain associated with the account to become a validator. The validation power of a validator is proportional to the amount of the native cryptocurrency associated with the blockchain account of the validator. Note that if the majority of the validation power in a PoS blockchain is in the hands of malicious validators that take actions to hurt the blockchain, whether in a public or a covert way, then the malicious validators decrease the value of the blockchain. Also note that, decreasing the value of a blockchain also decreases the value of the native cryptocurrency of the blockchain that is owned by the malicious validators. Of course, malicious validators taking public actions that are contrary to the official consensus algorithm may be punished by a reduction in cryptocurrency in the blockchain accounts of the malicious verifiers. For instance, malicious verifiers may censor all transactions of some blockchain accounts or just some transactions of some blockchain accounts, such as bids by the blockchain accounts in an auction conducted on the blockchain. However, even if the majority of the verifiers were so malicious, to provide such harm the blockchain, it may be impossible to punish any of the malicious verifiers, because each of the malicious verifiers could always credibly claim not to have seen the transactions that the malicious verifiers censor.

[0017] SUMMARY OF THE INVENTION

[0018] A challenge - Cryptocurrencies are relatively volatile, and the volatility may negatively affect the security of a public cryptocurrency blockchain. However, having a public blockchain that does not rely on its own cryptocurrency for the security of its consensus mechanism is not trivial. It is possible to ban native tokens and put consensus and smart-contract execution in the hands of an approved set of verifiers. However, the resulting blockchain would not be permissionless. It is also possible to put consensus and smart-contract execution in the hands of a set of verifiers, each having some untradeable, "verification-only" tokens that may not be a cryptocurrency. However, in such a case, it may be difficult to ensure that verification participation is permissionless given the possibilities for a blockchain account to obtain the verification-only tokens. For example, if a blockchain account needs to request verification-only tokens from current verifiers, the current verifiers could simply refuse, thus making the resulting system neither permissionless nor distributed. Another possibility is to have a blockchain account be able to simply request the verification-only tokens, but this could result in malicious verifiers becoming dominant in a blockchain since there is no cost to becoming a verifier and no inherent mechanism to attract predominantly honest verifiers. Another possibility is requiring aspiring verifiers to purchase verification-only tokens. It is then possible to have the verifiers receive a pro rata fraction of any cryptocurrency that may be transferred to one or more third party accounts by accounts that transact cryptocurrency on the blockchain (described above). That is, when blockchain accounts transfer cryptocurrency between each other, one or more of the blockchain accounts also transfer cryptocurrency to the verifiers for blockchain services provided by the verifiers. While this may be an improvement to giving away verification-only tokens, it may not be sufficient to prevent control of verification of the blockchain from falling into the hands of malicious verifiers; nothing prevents a few malicious verifiers from conspiring and obtaining the vast majority of verification-only tokens given the possibility of conspiring and receiving additional assets improperly through malicious activity. It is possible to create a PoS system in which the native cryptocurrency is replaced by fiat currency, properly represented, such as stablecoins. Validators may even be required to lock (escrow) a large amount of their stablecoin assets to become validators. In such replacement, however, malicious validators who succeed in hurting the chain do not also hurt themselves because, by definition, stablecoins retain value, which solely depends on the actions of the relative central bank and is not affected by what happens to the corresponding blockchain.

[0019] Constructing a permissionless and secure blockchain operating without native tokens is a challenging task. Many governments and institutions, unwilling to handle cryptocurrencies, deprive themselves —and their citizens or customers— of the security, transparency and efficiency of the blockchain. Accordingly, it is desirable to provide a public blockchain that does not rely on cryptocurrencies for operating consensus or smart contracts.

[0020] According to the system described herein, choosing blockchain validators includes providing a blockchain in which at least some computing devices are participant devices that act on behalf of associated blockchain accounts that use the blockchain to transact a first type of assets and a second type of assets, the second type of assets being different from the first type of assets, where some computing devices are validating computing devices associated with at least some validating blockchain accounts and run a prescribed validating computer program to take actions that include at least one of: validating blocks, validating transactions, or validating blockchain accounts in a given time period. Choosing blockchain validators also includes causing at least one of the validating computing devices to receive from at least one participant device an indication that a particular participant device requests that an associated blockchain account become a validating blockchain account for a given period of time, causing the at least one validating computing device to learn an amount of the second type of assets of the particular participant device, causing the at least one validating computing device to use a cryptographically fair lottery and the amount of the second type of asset that is provided in the associated blockchain account of the particular participant device to determine whether the associated blockchain account corresponding to the particular participant device is selected to become a validating blockchain account in the given period of time, and causing the transfer of at least some of the second type of asset of the associated account in response to the associated account being selected by the cryptographically fair lottery to become a validating blockchain account for the given period of time. The cryptographically fair lottery may select the particular participant device only if an amount of second type of asset of the associated blockchain account of the particular participant is at least a predetermined value. A likelihood of being selected by the cryptographically fair lottery may be proportional to an amount of the second asset of the associated blockchain account. A predetermined amount of the second type of assets may be transferred by each of the participants in order to post a transaction of the first type of asset on the blockchain. The at least some of the second type of asset of the associated account may be transferred to an ecosystem account or to a different account. Selection by the cryptographically fair lottery may be random and verifiable based on data available on the blockchain. The second type of assets may correspond to a digital representation of fiat currency. The digital representation of fiat currency may be stablecoins, tokenized bank deposits, digital dollars, digital euros, and / or central-bank digital currency. At least one of: the indication that a particular participant device requests that an associated blockchain account become a validating blockchain account or the amount of the second type of asset of the associated blockchain account of the particular participant device may be made available by being posted in one or more of the blocks of the blockchain.

[0021] According to the system described herein, a non-transitory computer readable storage medium contains software that, when executed, chooses blockchain validators in a blockchain in which at least some computing devices are participant devices that act on behalf of associated blockchain accounts that use the blockchain to transact a first type of assets and a second type of assets, the second type of assets being different from the first type of assets, where some computing devices are validating computing devices associated with at least some validating blockchain accounts and run a prescribed validating computer program to take actions that include at least one of: validating blocks, validating transactions, or validating blockchain accounts in a given time period. The software includes executable code that causes at least one of the validating computing devices to receive from at least one participant device an indication that a particular participant device requests that an associated blockchain account become a validating blockchain account for a given period of time, executable code that causes the at least one validating computing device to learn an amount of the second type of assets of the particular participant device, executable code that causes the at least one validating computing device to use a cryptographically fair lottery and the amount of the second type of asset that is provided in the associated blockchain account of the particular participant device to determine whether the associated blockchain account corresponding to the particular participant device is selected to become a validating blockchain account in the given period of time, and executable code that causes the transfer of at least some of the second type of asset of the associated account in response to the associated account being selected by the cryptographically fair lottery to become a validating blockchain account for the given period of time.

[0022] In the system described herein, validators receive, as a reward for providing validation services, an asset other than the asset transacted on the blockchain (blockchain asset). The asset other than the blockchain asset may be referred to herein as a "different asset". The different asset may also be used in connection with execution of smart contracts. In the system described herein, the totality of the different assets transferred in a given period of time (e.g., a quarter) are used as a proxy for usage of the blockchain in that period of time. In an embodiment herein, the different asset may be a digital representation of a fiat currency, although other types of different assets may be used.

[0023] In the system described herein, consensus and smart-contract execution may be entrusted to a board of verifiers who are required to serve for only a given period of time, but at least some verifiers may continue to serve for subsequent periods of time. For example, and without any limitation intended, a given period of time is referred to herein as a quarter. Those skilled in the art understand that any period of time could be used instead of a quarter. At the start of each quarter (except the first quarter, which is handled differently, as described elsewhere herein), a specific number of board seats are put up for sale via a specific selling mechanism. In a given quarter, a verifier is a blockchain account / public key that has bought one such seat. The cost of a board seat (the amount of the different asset that needs to be transferred) in a given quarter Q is CQ. (For example, the amount CQ could be transferred to given account. Such an account could be an ecosystem fund, used to reward developers which deploy applications and other software products that the assets on the chain make them more valuable, and the chain itself better and more valuable.) In a quarter Q, (a) verifiers, and only verifiers, participate in consensus, transaction validations and smart-contract execution, and (b) at the end of Q, the ones of the verifiers who have properly participated in verification (as explained in more detail elsewhere herein) split among themselves the quarterly revenue RQ, that is, the entirety of the different asset that has been transferred in Q in connection with the blockchains transactions and smartcontract executions. In some embodiments, a different mechanism may be used to choose validators for the first quarter. For example, such validators may be chosen among accounts corresponding to entities that can be trusted to act honestly as validators.

[0024] The system described herein provides two mechanisms for awarding board seats: a first mechanism for specifying the number of board seats put for sale in a quarter Q, BQ, and a second mechanism for selecting which accounts, aspiring to be validators in Q, are actually allowed to pay for board seats (transfer the required amount of the different asset) and be validators during Q. For example, the first mechanism may algorithmically specify BQ as follow: BQ=(3 x RQ-1) / CQ. The second mechanism may use a cryptographically fair lottery to choose which aspiring validators actually become validators. In an embodiment herein, the cryptographically fair lottery may be provided by a smart contract that uses, as inputs, values that are provided on the blockchain.

[0025] The first mechanism may specify BQ so that honest validation work is expected to be well rewarded, though the amount of the second asset that is transferred from quarter to quarter may vary. For example, BQ may be chosen based on the cost CQ and the revenue of the previous quarter, RQ-1. More precisely, BQ may be chosen to be (3 x RQ-1) / CQ.

[0026] Assuming that all holders of the BQ seats diligently run the proper validation algorithm during quarter Q and equally split the different asset that is transferred in the quarter Q, and that RQ=RQ-1, that is, that the total of the different asset that is transferred in the previous quarter Q-l is the same in the new quarter Q. Then, each holder of a board seat in Q, transfers an amount of the different asset corresponding to CQ to become a validator and earns an amount of the different asset corresponding to 3*CQ acting as honest validator. The assumption in the example above is that the total of the different asset that is transferred in the previous quarter Q-l is the same in the new quarter Q (i.e., RQ-1=RQ). As another example, assume that the total of the different asset that is transferred in the current quarter Q is one half of the total of the different asset that is transferred previous quarter Q-l (i.e., RQ=(RQ-l) / 2). In that case, a prospective validator (a) transfers an amount of the different asset corresponding to CQ to become a validator and essentially (b) receives an amount of the different asset corresponding to 1.5*CQ in quarter Q, if the prospective validator becomes an honest validator in quarter Q. Such performance continues to be very attractive, despite the dramatic 50% decrease in the total amount of the different asset transferred in connection with conducting transactions on the blockchain (i.e., RQ) that is a proxy for the usage of the blockchain in quarter Q. Note that (1) a fluctuation of -50% in a single quarter is unlikely, even for a speculative and volatile asset like a cryptocurrency, while (2) the -50% fluctuation in the above example is that of the usage of the chain, that is, the usage of the basic infrastructure. A given cryptocurrency might occasionally depreciate 50% in a quarter. But usage of a basic infrastructure — like the railway system, the cell phone system, etc. — is less likely to experience such a drastic decrease in a single quarter.

[0027] Note that the first mechanism regulates (limits) in a proper algorithmic way the number of validation-board seats of each quarter. It is this regulation that permits honest validation work to be rewarded. By contrast, in a PoS blockchain, if the amount of the different asset transferred in connection with conducting transactions on the blockchain are divided among too many validators, honest validation cannot be adequately rewarded.

[0028] The second mechanism discussed above is designed to provide most (or all) of the BQ board seats of quarter Q to honest blockchain accounts. Note that a first-come-first serve mechanism for selecting actual validators from aspiring validators is not necessarily guaranteed to select honest validators. Similarly, selecting validators based on which blockchain accounts offer to transfer the highest amount of the different asset (highest bidders) arguably favors malicious aspiring validators. Indeed, malicious validators are incentivized to offer more if they expect to gain more than the reward of an honest validator by circumventing the official consensus algorithm in order to secure illicit gains for themselves to the detriment of the good functioning of the chain. Using the cryptographically fair lottery to select validators makes it possible to have a majority of honest validators when the majority of aspiring validators are also honest, especially because becoming a validator is attractive for honest validators based on the expected return of honest validation work.

[0029] Variants

[0030] In a given quarter, the number of board seats in a quarter Q, N, may be an integer and each validator V have an integral number of board seats. For example, assuming that N = 100 and one validator has 2 board seats, then that validator has 2% of the validation power in quarter Q. It is also possible that N and / or the number of board seats be more general numbers. For instance, in quarter Q, it may be the case that N = 100.5 and V has 2.2 board seats. In this case, V has 2.2 / 100.5 of the validation power in Q. To gain a fractional seat in a quarter Q, a validator needs to transfer only the corresponding fraction of the amount CQ.

[0031] An aspiring validator V desiring to be a validator with up to n board seats in a quarter Q — whose number of board seats is determined to be N, where n < N — may commit a proper amount A of the second asset of V, where A > n • CQ. Committing amount A (or any other asset) means to have A be controlled by a smart contract that will dispose of A (or the other asset) according to a precise set of conditions. The amount A will be used (together with other data) by the cryptographically fair lottery to select a number n' (where 0 < n' < n < N) of board seats that V wins. The conditions of l's commitment may include to automatically transfer some portion of A, depending on the number of seats V wins in the cryptographically fair lottery. This way, it is guaranteed that V will transfer the corresponding amount n' ■ CQ of the second asset of V from the amount A.

[0032] Alternatively, V may not commit amount A. For example, V may make available an indication of a willingness to become a validator in a given quarter Q at a first point in time, and the fair lottery is executed at a second point in time. The chance of V winning some seats depends on the amount A of the second digital asset that V has at the second point in time. Assume that V wins n seats. In this case, the system may give V the chance of transferring appropriate assets for all the seats or not. In this case, V gets n seats in quarter Q if V transfers an amount n ■ CQ of the second asset. If V does not, then V gets no seats in quarter Q, and n seats will remain empty. Alternatively, rather than leaving such seats empty, the system may use the same or a new fair cryptographic lottery to offer n seats to other aspiring validators. Alternatively yet, V may be given the chance to buy a number n' of board seats that is less than n, by transferring an amount n' ■ CQ of the second type of asset. If V does so, then the system may leave n — n' seats empty in quarter Q, or use the same or a new lottery to offer any remaining unclaimed seats to other aspiring validators via additional selections.

[0033] BRIEF DESCRIPTION OF DRAWINGS

[0034] Embodiments of the system described herein will now be explained in more detail in accordance with the figures of the drawings, which are briefly described as follows.

[0035] FIG. 1 is a schematic illustration of a blockchain with validators according to the system described herein.

[0036] FIG. 2 is a flow diagram illustrating a blockchain account conducting a transaction according to an embodiment of the system described herein.

[0037] FIG. 3 is a flow diagram illustrating choosing validators for a blockchain according to the system described herein.

[0038] DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

[0039] The system described herein provides a mechanism for choosing validators of a blockchain that increases the likelihood that the majority of the validation power of a set of validators will be in honest hands. This helps maintaining the value of assets transacted on the blockchain.

[0040] Referring to FIG. 1, a blockchain 100 is shown as including a plurality of formed blocks 102- 105 and a prospective block 106. Each of the blocks 102-106 includes a plurality of transactions (not shown in FIG. 1) for transfers of assets between accounts that use the blockchain 100. The asset that is transferred on the blockchain 100 could be any appropriate asset, including a cryptocurrency. A plurality of validators 112-114 create and validate new blocks, like the prospective block 106. The validators 112-114 confirm the consistency of transactions on the prospective block 106 by reviewing past transactions including, for example, transactions on the block 105 that immediately precedes the prospective block 106. If the transactions of the prospective block 106 are consistent and appropriate, the validators 112-114 (or at least a majority of the validators 112-114) validate the prospective block 106, after which the block 106 is fixed and no new transactions may be entered. The block 106 becomes a permanent and arguably irrefutable record of transactions between the accounts of the blockchain.

[0041] Referring to FIG. 2, a flow diagram 200 illustrates processing performed in connection with a blockchain account transferring blockchain assets using the blockchain. Processing begins at a first step 202 where the blockchain account posts the transfer on a pending block of the blockchain. As discussed elsewhere herein, the blockchain asset could be, for example, a cryptocurrency. Following the step 202 is a step 204 where the blockchain account transfers the different asset (e.g., a digital representation of a fiat currency), which will be received by the validators and possibly used in connection with one or more smart contracts in connection with validating the pending block on which the blockchain asset was posted and possibly used in connection with selecting new validators. Following the step 204, processing is complete. Note that the steps 202, 204 may occur simultaneously, at different times, or at partially overlapping times.

[0042] Referring to FIG. 3, a flow diagram 300 illustrates processing performed in connection with choosing validators for a next round (e.g., next quarter). As discussed elsewhere herein, validators may be chosen each quarter. A blockchain account may post a token or other indicator on the blockchain indicating a desire to become a validator. In some embodiments, there may be a built-in preference for blockchain accounts that had been validators in a previous round. In other embodiments, there is no preference and all aspiring validators are treated equally in each round for each selection process.

[0043] Processing begins at a first step 302 where it is determined how many validators will be used in an upcoming round (quarter). As discussed elsewhere herein, the number of validators for a subsequent quarter is based on the amount of the different asset that is transferred in a previous quarter. Following the step 302 is a step 304 where it is confirmed that a blockchain account that aspires to be a validator has enough of the different asset to be able to transfer the different asset if the blockchain account is selected to be a validator. As discussed elsewhere herein, to become a validator, a blockchain account must transfer a certain amount of the second asset (e.g., CQ in the example provided above). In some embodiments, the different asset needs to be escrowed (locked) by the blockchain account in order for the blockchain account to be considered to become a validator. In such a case, if the blockchain account is not selected in the end, the escrow is released (returned). In other embodiments, the different asset does not need to be escrowed. Instead, the aspiring blockchain account only needs to confirm that there is enough of the different asset to be transferred should the blockchain account be selected to be a validator.

[0044] Following the step 304 is a test step 306 where it is determined if there is enough of the different asset for the aspiring blockchain account to become a validator. If not, then control passes from the test step 306 to a step 308 where the aspiring blockchain account is rejected (does not become a validator). Following the step 308, processing is complete. If, on the other hand, it is determined at the step 306 that there is enough of the different asset for the aspiring blockchain account to become a validator, then control passes from the test step 306 to a step 312 where the cryptographically fair algorithm is executed. In an embodiment herein, the cryptographically fair algorithm is implemented with a smart contract that uses data from the blockchain as input. The input data may be, for example, which of the blockchain accounts is an aspiring validator and the balance of the different asset that corresponds to each of the aspiring blockchain accounts. Thus, the results of the cryptographically fair algorithm may be repeated and confirmed.

[0045] Following the step 312 is a test step 314 where it is determined if a particular one of the blockchain accounts has been selected. If not, then control passes from the test step 314 to a step 316, where the aspiring blockchain account is rejected (does not become a validator). Following the step 316, processing is complete. If, on the other hand, it is determined at the test step 314 that the particular one of the blockchain accounts has been selected by the cryptographically fair algorithm, then control passes from the test step 314 to a step 318, where the aspiring blockchain account is selected to become a validator. Following the step 318, processing is complete.

[0046] In some embodiments, the amount of the different asset that needs to be transferred to become a validator is fixed. In other embodiments, the amount may be variable and may depend upon any appropriate parameter, such as an initial amount of an asset normally transferred on the blockchain (e.g., cryptocurrency) that is managed by each of the blockchain accounts.

[0047] In some embodiments, each of the blockchain accounts may hold only a single board seat while in other embodiments, a blockchain account may hold more than one board seat and possibly any number of board seats.

[0048] In the discussion herein, note that transferring assets includes causing assets to be transferred. In addition, making Information available may include causing the information to be known, posting the information in an accessible database (e.g., the blockchain itself), and / or taking no action, if the information is already available. A party X may be deemed to make information available alone or in collaboration with other parties. For instance, if X makes available part of the information and another party makes available the balance of the information, then X has made the information available. A first party may make some information available to a second party via an interactive process monitored by the second party or in which the second party participates.

[0049] Verifying an item includes directly verifying the item, causing another party to verify the item and receiving the result of such indirect verification, and having already verified the item. Similarly, learning information includes learning the information from scratch, learning the information by putting together information, at least some of which already available, and knowing the information already. Providing an item includes providing the item in its entirety, proving a portion of the item, and / or causing another party to provide the item.

[0050] For example, if the item is a blockchain with some characteristics, then someone providing a portion of a smart contract contributing to such characteristics is providing such a blockchain. Various embodiments discussed herein may be combined with each other in appropriate combinations in connection with the system described herein. Additionally, in some instances, the order of steps in the flowcharts, flow diagrams and / or described flow processing may be modified, where appropriate. Subsequently, system configurations may vary from the illustrations presented herein. Further, various aspects of the system described herein may be deployed on any appropriate processing device using one or more use operating system(s) suitable for providing the functionality described herein, including, without limitation, an operating system selected from the group consisting of: iOS, Android OS, Windows, Blackberry OS and Linux OS. Certain components of the system may be cloud based.

[0051] Software implementations of the system described herein may include executable code that is stored in a computer readable medium and executed by one or more processors. The computer readable medium may be non-transitory and include a computer hard drive, ROM, RAM, flash memory, portable computer storage media such as a CD-ROM, a DVD-ROM, a flash drive, an SD card and / or other drive with, for example, a universal serial bus (USB) interface, and / or any other appropriate tangible or non-transitory computer readable medium or computer memory on which executable code may be stored and executed by a processor. The software may be bundled (pre-loaded), installed from an app store or downloaded from a location of a network operator. The system described herein may be used in connection with any appropriate operating system.

[0052] Other embodiments of the invention will be apparent to those skilled in the art from a consideration of the specification or practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

Claims

What is claimed is:

1. A method of choosing blockchain validators, comprising: providing a blockchain in which at least some computing devices are participant devices that act on behalf of associated blockchain accounts that use the blockchain to transact a first type of assets and a second type of assets, the second type of assets being different from the first type of assets, wherein some computing devices are validating computing devices associated with at least some validating blockchain accounts and run a prescribed validating computer program to take actions that include at least one of: validating blocks, validating transactions, or validating blockchain accounts in a given time period; causing at least one of the validating computing devices to receive from at least one participant device an indication that a particular participant device requests that an associated blockchain account become a validating blockchain account for a given period of time; causing the at least one validating computing device to learn an amount of the second type of assets of the particular participant device; causing the at least one validating computing device to use a cryptographically fair lottery and the amount of the second type of asset that is provided in the associated blockchain account of the particular participant device to determine whether the associated blockchain account corresponding to the particular participant device is selected to become a validating blockchain account in the given period of time; and causing the transfer of at least some of the second type of asset of the associated account in response to the associated account being selected by the cryptographically fair lottery to become a validating blockchain account for the given period of time.

2. The method of claim 1, wherein the cryptographically fair lottery selects the particular participant device only if an amount of second type of asset that is associated with the blockchain account of the particular participant is at least a predetermined value.

3. The method of claim 1, wherein a likelihood of being selected by the cryptographically fair lottery is proportional to an amount of the second asset of the associated blockchain account.

4. The method of claim 1, wherein a predetermined amount of the second type of assets is transferred by each of the participants in order to post a transaction of the first type of asset on the blockchain.

5. The method of claim 1, wherein the at least some of the second type of asset of the associated account is transferred to an ecosystem account or to a different account.

6. The method of claim 1, wherein selection by the cryptographically fair lottery is random and verifiable based on data available on the blockchain.

7. The method of claim 1, wherein the second type of assets corresponds to a digital representation of fiat currency.

8. The method of claim 7 , wherein the digital representation of fiat currency is at least one of: stablecoins, tokenized bank deposits, digital dollars, digital euros, or central-bank digital currency.

9. The method of claim 1, wherein at least one of: the indication that a particular participant device requests that an associated blockchain account become a validating blockchain account or the amount of the second type of asset of the associated blockchain account of the particular participant device are made available by being posted in one or more of the blocks of the blockchain.

10. A non-transitory computer readable storage medium containing software that, when executed, chooses blockchain validators in a blockchain in which at least some computing devices are participant devices that act on behalf of associated blockchain accounts that use the blockchain to transact a first type of assets and a second type of assets, the second type of assets being different from the first type of assets, wherein some computing devices are validating computing devices associated with at least some validating blockchain accounts and run a prescribed validating computer program to take actions that include at least one of: validating blocks, validating transactions, or validating blockchain accounts in a given time period, the software comprising: executable code that causes at least one of the validating computing devices to receive from at least one participant device an indication that a particular participant device requests that an associated blockchain account become a validating blockchain account for a given period of time; executable code that causes the at least one validating computing device to learn an amount of the second type of assets of the particular participant device; executable code that causes the at least one validating computing device to use a cryptographically fair lottery and the amount of the second type of asset that is provided in the associated blockchain account of the particular participant device to determine whether the associated blockchain account corresponding to the particular participant device is selected to become a validating blockchain account in the given period of time; and executable code that causes the transfer of at least some of the second type of asset of the associated account in response to the associated account being selected by the cryptographically fair lottery to become a validating blockchain account for the given period of time.

Images